API Anahtarı Yönetimi: Sırrı Saklamak Kadar Değiştirebilmek de Önemli

Anahtarın değerini değil envanterini paylaşın

Hangi servis için oluşturulduğu, sahibi, ortamı, yetki kapsamı ve son değişim bilgisi ekip tarafından görülebilir. Gizli değerin kendisinin aynı genişlikle paylaşılması gerekmez. Bir envanter tablosu, bütün anahtarları açık metin olarak bir dosyada toplamak anlamına gelmemelidir.

OWASP sır yönetiminde merkezî kontrol, en az yetki ve oluşturma, yenileme, iptal ile süre sonunu kapsayan yaşam döngüsünü ele alır. [1] Bu ilkeleri API anahtarlarına uygularken kullanıcı parolaları için aynı periyodik yenileme kuralını körlemesine kullanmayın; sır türlerinin gereksinimleri farklı olabilir.

Ortam ve görev sınırlarını ayırın

Test uygulamasının canlı siparişlere erişmesi gerçekten gerekli mi? Aynı anahtar hem rapor okuyor hem kayıt silebiliyorsa görev ayrımı değerlendirilsin. Uygulamanın ihtiyaç duymadığı izinleri kaldırmak, bir sorun olduğunda etkilenen alanı sınırlamaya yardımcı olur. Yetki değişiklikleri gerçek işlem testleriyle doğrulansın.

Varsayımsal bir kargo bağlantısı yalnızca etiket oluşturmak için çalışıyor olsun. Destek ekibinin rapor aracı aynı yönetici anahtarını kullanmamalıdır. Servis başına izlenebilir kimlikler, hangi erişimin nerede kullanıldığını açıklamayı kolaylaştırabilir. Paylaşılan hesaplar devri ve iptali güçleştirebilir.

Yenileme planını sağlayıcının yeteneklerine göre kurun

Bazı sağlayıcılar eski ve yeni anahtarın kısa bir geçişte birlikte kullanılmasına izin verir, bazıları vermez. İki anahtar yöntemi destekleniyormuş gibi plan yapmayın. Önce yeni anahtarın oluşturulması, uygulamada etkinleştirilmesi ve eski anahtarın iptali sırasını belirleyin. Sır deposu ile uygulamanın ne zaman yeni değeri aldığı açık olsun.

OWASP, manuel yenilemenin hata riski taşıdığını ve mümkün olduğunda otomasyonla desteklenmesini önerir. [1] Otomasyonun kendisi de sınanmalıdır. Yeni anahtar kaydedildiği halde uzun çalışan süreç eski değeri kullanmaya devam ediyorsa geçiş tamamlanmış değildir. Kontrollü deneme ve doğrulama gerekir.

Örnek anahtar rotasyon tablosu

Sızıntı şüphesinde geri dönüş için eski anahtarı yeniden açmak güvenli bir seçenek olmayabilir. Normal planlı geçişle acil iptal prosedürünü ayırın. Hangi ekip karar verecek ve kalan servisler nasıl etkilenecek, önceden belgelensin.

Log ve hata ekranlarını kontrol edin

Anahtar yalnızca kaynak kodundan değil, hata mesajı, destek ekranı veya iş çıktısından da sızabilir. Hassas alanların kaydı ve maskelemesi test edilsin. URL içinde taşınan sırların ara sistemlerde görünmesi ihtimali değerlendirilmelidir. Gizli değeri örnek veri veya ekran görüntüsünde paylaşmayın.

Kabul testinde anahtar süresinin dolması, yetkinin daraltılması ve sır deposunun geçici erişilemezliği bulunsun. Uygulama yanlışlıkla geniş yetkili sabit yedek anahtara dönmemelidir. Devir dosyasında değerler değil erişim yönetim yöntemi, sorumlular ve güvenli işlem adımları yer alsın.

Sık sorulan sorular

Ortam değişkeni kullanmak tek başına yeterli mi?

Kod içine yazmaktan farklı bir saklama yolu sağlar, ancak erişim, log, yenileme ve iptal sorunlarını tek başına çözmez. Yaşam döngüsü birlikte tasarlanmalıdır.

Anahtar sızdıysa depodan silmek yeterli mi?

Hayır. Sağlayıcı tarafındaki erişim iptal edilmeli ve etkilenmiş kullanımlar incelenmelidir. Kopyalanmış değerin depodan silinmesi onu geçersiz yapmaz.