Bir geliştiriciye üretim veritabanının parolasının nerede durduğunu sorun; dürüst ama rahatsız edici bir cevap alırsınız: birçok yerde. Üç laptoptaki .env dosyasında, iki yıl önce tanımlanmış bir CI/CD değişkeninde, bir deployment script'inde, bir olay anındaki Slack yazışmasında ve — ekip şanssızsa — "silinmiş" ama git geçmişinde hâlâ duran bir commit'te.
Bunların hiçbiri kimse dikkatsiz olduğu için olmadı. Yazılım geliştirmek secret gerektirir ve pipeline'daki her araç onları koymak için kendi pratik yerini sunar. Bu pratikliğin bir adı var: secret dağılması (secrets sprawl). Ve bir şirketin ihlale uğramasının en garantili yollarından biri de bu.
İyi ekiplerde dağılma nasıl başlar
Secret'lar geliştiriciler umursamaz olduğu için sızmaz; en az dirençli yol onları etrafa saçtığı için sızar:
- Environment dosyaları çoğalır.
.envdosyası yerel bir kolaylık olarak başlar; sonra bir ekip arkadaşına kopyalanır, onboarding dokümanına eklenir, bir yedeğin içine zip'lenir. Her kopya, kimsenin denetlemediği ayrı bir kimlik bilgisi deposudur. - CI/CD değişkenleri gölge bir kasaya dönüşür. Pipeline ayarları sessizce cloud anahtarları, registry token'ları ve imzalama bilgileri biriktirir. Pipeline'ı düzenleme yetkisi olan herkes, çoğu zaman pipeline'ın erişebildiği her şeyi okuyabilir — ya da dışarı çıkarabilir.
- Dotfile'lar ve shell geçmişi her şeyi hatırlar. "Sadece bu oturum için" export edilen bir token
.bashrc'ye,.zsh_history'ye ya da kişisel bir not dosyasına düşer ve oturum bittikten çok sonra da orada kalır. - Ortak dokümanlar ekip kasası olur. "Erişim bilgileri" başlıklı bir wiki sayfası ya da tablo; aranabilir, kopyalanabilir ve diğer tüm dokümanlar gibi yetkilendirilmiştir — yani kötü ve kalıcı biçimde.
- Anahtarlar commit'lenir. Pre-commit hook'lara ve tarayıcılara rağmen anahtarlar repolara girer. Bir kez push edilen secret artık herkese açık kabul edilmelidir: geçmişi yeniden yazmak sızıntıyı geri almaz ve otomatik tarayıcılar public repolardaki açık anahtarları dakikalar içinde bulur.
Her konum o anda mantıklıydı. Hepsi bir arada ise envanteri, son kullanma tarihi ve sahibi olmayan bir saldırı yüzeyi oluşturuyor. Kaç secret'ınız olduğunu soran bir denetçiye verilecek dürüst cevap çoğu ekipte aynıdır: bilmiyoruz — ve bilmediğimiz şeyi ne döndürebilir ne de iptal edebiliriz.
İhlaller neden hep buradan başlıyor
Sızan kimlik bilgileri, gerçek ihlallerde en yaygın ilk erişim vektörleri arasında istikrarlı bir yere sahip. Nedeni basit bir ekonomi: çalınmış bir kimlik bilgisi exploit değil, giriş biletidir. Geçerli bir cloud anahtarı bulan saldırganın hiçbir şeyi kırmasına gerek yoktur — o anahtarın yaratıldığı otomasyon gibi oturum açar ve yaptığı her şey loglarda meşru görünür.
Dağılmış secret'lar bu tabloyu belirli bir şekilde ağırlaştırır: uzun ömürlü ve statiktirler. 2023'te bir CI değişkenine yapıştırılan parola büyük olasılıkla bugün hâlâ geçerli. Rotasyon tam da secret birçok yerde yaşadığı için acı vericidir — döndürmek her kopyayı bulmak demektir; bu yüzden ekipler nadiren döndürür ve tek bir eski sızıntı yıllarca kullanılabilir kalır. Dağılma ile bayat kimlik bilgileri, iki farklı kılıkta aynı sorundur.
Araç kutusundaki cevap: tek kasa, kısa lease, makine kimliği
Çıkış yolu, insanlardan dikkatli olmalarını rica eden bir politika yazısı değil; güvenli yolu pratik yol hâline getirmek. Yani merkezi secret yönetimi:
Ekiplerin çalıştığı gibi organize edilmiş tek kasa. Secret'lar proje ve environment'lar hâlinde yaşar — payments / production, payments / staging — ve erişim, kimin hangi parolayı bildiğinin kahramanca ezberine değil, ekibe ve environment'a göre verilir. Uygulamalar ve pipeline'lar secret'ları çalışma anında çeker; hiçbir şeyin yerel kopyaya ihtiyacı kalmaz.
Kendi kendine sona eren dinamik secret'lar. En güçlü secret, var olmayı bırakandır. Dinamik secret'lar talep üzerine üretilir — bir veritabanı kimlik bilgisi, bir cloud erişim anahtarı — ve bir lease ile gelir: tanımlı bir ömür dolduğunda kimlik bilgisi otomatik olarak iptal edilir. Sızan bir dinamik secret yıllarca değil, dakikalarca sorundur; rotasyon da bir proje olmaktan çıkar, çünkü varsayılan davranıştır.
CI/CD için saklanan anahtar yerine makine kimliği. Pipeline'ın kendisi kasaya uzun ömürlü bir API anahtarıyla bağlanmamalı — bu, aynı sorunu bir kat yukarıda yeniden üretir. Bunun yerine pipeline, OIDC'ye bağlı claim'ler taşıyan kendi makine kimliğiyle doğrulanır: kasa, bu workflow'un, bu repoda, bu branch'te çalıştığını kanıtlayan imzalı token'ı doğrular ve tam o bağlama daraltılmış kısa ömürlü erişim verir. Saklanan secret yok; pipeline ayarlarından sızacak bir şey de yok.
İhtiyaç olan yere senkron, gerçeğin kaynağı tek yerde. Gerçek mimariler cloud'un kendi secret depolarını kullanır — AWS Secrets Manager, Azure Key Vault, Kubernetes secret'ları. Cevap onlarla savaşmak değil, onları beslemek: merkezi kasa source of truth olarak kalır ve secret'ları dışarıya senkronlar. Uygulamalar native entegrasyonlarını korur; rotasyon, erişim politikası ve denetim tek yerden yürür.
Neden ayrı bir araç değil, PAM'in içinde
Bağımsız bir secret yöneticisi satın alabilirsiniz. Ama secret yönetimi, makineler için ayrıcalıklı erişim yönetimidir — hangi kimlik bilgisini kim, ne zaman, hangi izle kullanabilir sorusunun ta kendisi; PAM bu soruyu insanlar için zaten cevaplıyor.
Bunu PAM içinde yapmak tek denetim izi demek: sunucu parolasını checkout eden mühendis ile veritabanı kimlik bilgisini çeken pipeline aynı log'da, ilişkilendirilmiş hâlde, tek yerden incelenebilir durur. Tek politika yüzeyi demek: insan ayrıcalıklı erişimi için tanımladığınız onay kuralları, erişim pencereleri ve en az yetki kapsamı makine erişimine de uygulanır; ikinci bir üründe — biraz farklı biçimde — yeniden kurulmaz. Ve entegre edilecek, lisanslanacak, korunacak bir araç eksilir; çünkü secret barındıran her ek depo, kendisi de bir hedeftir.
Ekibinizdeki mühendisler secret'ların nerede olduğunu zaten biliyor; sorun da tam olarak bu. Onları tek yerde toplamak gösterişsiz ama getirisi büyük bir iş — Monopam secret yönetiminin projeleri, lease'leri ve OIDC'ye bağlı makine kimliklerini nasıl ele aldığına ve bunun daha geniş DevOps ayrıcalıklı erişim senaryosuna nasıl oturduğuna bakabilirsiniz.
