API anahtarı ve secret yönetimi nasıl kurulur?

Secret yalnız parola değildir; makine kimlikleri de aynı yaşam döngüsüne tabidir

Kurumsal ortamlarda API anahtarı, OAuth client secret, erişim tokenı, veritabanı parolası, SSH anahtarı, TLS özel anahtarı, imzalama anahtarı, webhook secret’ı, şifreleme anahtarı ve servis hesabı bilgileri secret kapsamına girer. Sertifika public olabilir; fakat özel anahtarı kritik sırdır. Her secret’ın koruma gereksinimi, sağlayabildiği yetki ve ele geçirilmesi halinde oluşacak etkiyle belirlenir.

En büyük risk, secret’ın kopyalanabilir ve görünmez biçimde yayılmasıdır

Secret’lar kaynak koduna, Git geçmişine, konteyner imajına, CI loguna, ekran görüntüsüne, destek kaydına veya geliştirici cihazına girebilir. Bir değer silinse bile geçmiş commit, yedek ve loglarda kalabilir. Uzun ömürlü ve geniş yetkili secret, ele geçirildiğinde saldırgana uzun süreli ve zor fark edilen erişim sağlar.

• Kaynak kod ve yapılandırmada düz metin secret
• Üretim ve testte aynı anahtarın kullanılması
• Paylaşılan servis hesapları
• Sahibi ve son kullanma tarihi olmayan anahtarlar
• Secret değerinin log veya hata mesajında görünmesi
• Rotasyonun uygulamayı kesmesi nedeniyle ertelenmesi
• Alt yüklenici ve CI/CD sistemlerinin gereğinden fazla secret görmesi
• Sızıntı sonrası yalnız parolayı değiştirmek, token ve oturumları açık bırakmak

Envanter, secret değerini değil kimlik ve kullanım bağlamını kaydetmelidir

Merkezi envanterde secret’ın kendisi değil; benzersiz kimliği, türü, sahibi, kullanan uygulama, ortam, yetki kapsamı, saklandığı kasa, oluşturma–son kullanma tarihi, rotasyon yöntemi, bağımlılıklar ve acil iptal prosedürü tutulur. Sahipsiz ve kullanılmayan secret’lar kapatılmalıdır.

Merkezi secrets manager erişimi sınırlar, ancak tek başına güvenliği garanti etmez

CISA, secrets manager kullanımının parolalar, API anahtarları ve diğer kimlik bilgilerinin merkezi yönetimini desteklediğini belirtir. Merkezi kasa; şifreleme, erişim politikası, audit logu, sürüm, rotasyon ve uygulama entegrasyonu sağlar. Ancak kasanın yönetici yetkisi, kök anahtarları, yedekleri ve erişim politikaları da korunmalıdır. Secret’ların tamamını okuyabilen tek hesap yeni bir yoğunlaşma riski yaratır.

Secret mümkünse çalışma anında ve kısa ömürlü verilmelidir

Bir secret’ı ortam değişkenine koymak, kaynak koddan daha iyi olabilir; fakat süreç listesi, crash dump veya yanlış loglama yoluyla sızabilir. Mümkün olduğunda uygulama kimliğiyle kasa erişimi, kısa ömürlü token, dinamik veritabanı kullanıcısı, iş yükü kimliği veya sertifika tabanlı doğrulama tercih edilir. Secret yalnız gerektiği anda alınmalı, bellekte ve logda gereksiz tutulmamalıdır.

1. Uygulamaya kalıcı master secret vermeyin.
2. İş yükünü platform kimliğiyle doğrulayın.
3. Görev süresi kadar geçerli token üretin.
4. Secret değerini uygulama loglarından maskeleyin.
5. Hata mesajlarında bağlantı dizesini göstermeyin.
6. Cache süresini ve bellek temizliğini tanımlayın.
7. Secret erişimi başarısızsa güvenli duruş belirleyin.

Ortam, uygulama ve işlem yetkileri birbirinden ayrılmalıdır

Geliştirme anahtarı üretimde geçerli olmamalı; okuma için kullanılan anahtar yazma veya yönetim yetkisi taşımamalıdır. Paylaşılan anahtar yerine uygulama veya iş yükü başına kimlik, gerektiğinde tenant veya müşteri ayrımı kullanılmalıdır. Scope, IP, ağ, kaynak, işlem sayısı ve zaman koşulları ek sınır oluşturabilir.

Rotasyon planlı, test edilmiş ve kesintisiz uygulanabilir olmalıdır

Rotasyon takvimsel olabilir; ancak rol değişikliği, tedarikçi ayrılığı, sızıntı şüphesi, algoritma değişikliği veya sistem geçişi de rotasyonu tetikler. Güvenli süreç yeni secret üretme, iki değerin kısa süre birlikte geçerli olması, bağımlılıkların güncellenmesi, eski değerin iptali ve kullanımın doğrulanmasını içerir.

CI/CD ve geliştirici akışı secret sızıntısını baştan önlemelidir

CISA yazılım tedarik zinciri rehberleri, parola, API anahtarı ve özel sertifika gibi secret’ların pipeline ve kaynak kodda korunmasını vurgular. Pre-commit tarama, repository secret scanning, build log maskeleme, imaj katmanı inceleme, branch koruma ve ayrılmış deploy kimlikleri birlikte kullanılmalıdır.

• Örnek `.env` dosyasında gerçek değer bulunmamalı.
• Fork ve pull request süreçleri üretim secret’ına erişmemeli.
• Build işi yalnız gerekli ortam secret’ını görmeli.
• Üçüncü taraf action/plugin sürümleri sabitlenmeli ve incelenmeli.
• Artifact ve konteyner imajı secret kalıntısı için taranmalı.
• Geliştiriciye break-glass erişimi süreli ve kayıtlı verilmeli.

Sızıntı şüphesinde önce iptal, sonra kök neden ve kapsam analizi yapılmalıdır

Secret’ın public repository, log, e-posta veya kötü amaçlı paket tarafından görülmüş olabileceği durumda yalnız dosyadan silmek yeterli değildir. Değer derhal iptal edilmeli veya döndürülmeli; onunla üretilen token ve oturumlar sonlandırılmalı; kullanım logları incelenmeli; yetki kapsamındaki kaynaklar kontrol edilmeli ve aynı değerin kopyaları aranmalıdır.

1. İlgili secret ve türetilmiş oturumları iptal edin.
2. Geçici yeni değer ve sınırlı yetki uygulayın.
3. İlk sızıntı zamanı ve kullanım kapsamını belirleyin.
4. Repository geçmişi, imaj, log ve yedekleri tarayın.
5. Yetkisiz işlem veya veri erişimini inceleyin.
6. Kök nedeni; süreç, araç ve yetki düzeyinde düzeltin.
7. Benzer secret’lar için toplu risk taraması yapın.

Olay metriği yalnız sızan anahtar sayısı değil; tespit süresi, iptal süresi, otomatik rotasyon kapsamı ve yetkisiz işlem etkisiyle ölçülmelidir.