GitHub Güvenlik ekibi, yıllar önce başlayan bir girişimle projelerindeki gizli anahtar yönetimini baştan aşağı yeniledi. Geliştirilen Secret Scanning aracının erken versiyonlarını test ederken, 15 binden fazla depoda 20 bini aşkın gizli anahtar tespit edildi. Bu sayı, beklenenden oldukça yüksekti — ancak asıl zorluğun, uyarıların hangilerinin gerçek tehdit olduğunu ayırt etmek, sorumluları belirlemek ve bu verileri güvenle temizlemek olduğu anlaşıldı. Sadece dokuz ay içinde, tüm açık uyarılar sıfırlandı.
Peki, GitHub bu süreci nasıl yönetti? Gizli anahtarların izini nasıl sürdü ve bu riskli verileri sistemlerinden nasıl kaldırdı? Şirketin kendi deneyiminden yola çıkarak, bu sürecin ardındaki stratejileri ve alınan dersleri paylaşıyoruz.
Gizli anahtar uyarılarında gürültüyü azaltma
Başlangıçta, 20 binden fazla uyarının tamamının eşit derecede riskli olduğu düşünülüyordu. Ancak veriler incelendiğinde, bu uyarıların büyük çoğunluğunun aslında sahte veya kullanılmayan gizli anahtarlar olduğu ortaya çıktı. Sadece beş depo, tüm uyarıların yaklaşık %90’ını oluşturuyordu ve bu gizli anahtarların tamamı test ortamlarında kullanılan sahte kimlik bilgileriydi. (GitHub’ın kendisi gizli anahtar taraması geliştirdiğinden, test depo dolulukları normaldi.)
Geriye kalan 2 binden fazla uyarı ise dikkat gerektiren gerçek risklerdi: aktif kimlik bilgileri, rotasyon gerektiren veriler ve acil müdahale gerektiren durumlar.
Gizli anahtarlar yalnızca kodda değil
Gizli anahtar temizliği, yalnızca kaynak koduyla sınırlı kalmadı. Şirket, destek taleplerinde, hata ödül programı raporlarında, olay müdahale notlarında ve dahi wiki sayfalarında gizli anahtarlar keşfetti. Müşteri destek ekipleriyle, güvenlik olay müdahale ekipleriyle ve hata ödül programıyla işbirliği yapılarak ortak prosedürler geliştirildi. Bu süreçte, gizli anahtarları temizlerken yeni sorunlar yaratmamak — örneğin, gizli anahtarı içeren yeni sorunlar açmamak veya yeni commitler atmamak — büyük önem taşıyordu.
Üç aşamalı temizlik stratejisi
GitHub, 20 bin uyarıyı elle temizlemeye çalışmak yerine, bu süreci operasyonel bir borçtan arınma projesi olarak ele aldı. Hedef, yeni gizli anahtarların eklenmesini durdurmak, ardından var olanları sistematik şekilde temizlemekti. Bu yaklaşım, tekrarlanabilir, ölçülebilir ve bireysel bilgiye bağımlı olmayan bir süreç gerektiriyordu.
Aşama 1: Her yere tarama kurulumu ve yeni gizli anahtarları engelleme
Temizlik başlamadan önce, yeni gizli anahtarların depolara eklenmesini engellemek gerekiyordu. Bunun için GitHub Advanced Security’in kuruluş düzeyindeki ayarları kullanılarak, tüm depolarda gizli anahtar taraması ve push koruması devreye alındı. Bu sayede, bireysel ekiplerin ya da depoların gizli anahtar korumasından kaçınması engellendi.
Push koruması, yeni gizli anahtarların sisteme eklenmesini anında bloke etti. Bu, temizlik sürecine başlamadan önce borcun daha da artmasını önledi.
Aşama 2: Uyarıları sınıflandırma ve önceliklendirme
20 binden fazla uyarı, depo, gizli anahtar tipi ve yaşlarına göre sınıflandırıldı. Böylece, gürültü oluşturan uyarılarla gerçek tehditler birbirinden ayrıldı.
Yüksek hacimli ancak düşük riskli uyarılar için toplu kapatma kriterleri belirlendi. Örneğin:
- Test depolarında bulunan gizli anahtarlar
- Hiçbir zaman aktif olmayan kimlik bilgileri
- Bilinen test desenlerine uyan veriler
Bu kriterler doğrultusunda, yaklaşık 18 bin uyarı sadece birkaç gün içinde kapatıldı.
Ancak bazı kritik kararlar almak gerekiyordu. Örneğin:
- Bir gizli anahtar bir sorun açıklamasında bulunuyorsa, bu metni düzenlemek ya da revizyon geçmişini silmek mi gerekir?
- Gizli anahtar bir repoya commit edilmişse, Git geçmişini yeniden yazmak mı gerekiyor?
- Bir depo artık kullanılmıyorsa, onu tamamen silmek güvenlik açısından doğru mu?
Cevap genellikle hayır oldu. Silinen bir depo, aynı zamanda olası bir soruşturma sırasında ihtiyaç duyulabilecek denetim kayıtlarını da ortadan kaldırır. Bunun yerine, gizli anahtarın rotasyonu ya da deponun arşivlenmesi tercih edildi. Git geçmişini yeniden yazmak yerine, gizli anahtarın önce revoke edilmesi ve ardından gerekiyorsa deponun arşivlenmesi önerildi.
Aşama 3: Aktif gizli anahtarları doğrulama
Bir gizli anahtarın bir repoda bulunması, onun hala geçerli olduğu anlamına gelmez. Bu anahtar yıllar önce rotasyona uğramış olabilir veya hala üretim sistemlerine erişim sağlıyor olabilir. Riskleri doğru şekilde önceliklendirmek için, hangi gizli anahtarların hala aktif olduğunu bilmek kritiktir.
O dönemde, gizli anahtar taramasının yerleşik bir doğrulama özelliği bulunmuyordu. Bunun üzerine GitHub, kendi doğrulama yaklaşımını geliştirdi. Amaç, bir gizli anahtarın hala çalışıp çalışmadığını belirlemekti. Bu sayede, riskli gizli anahtarlar için acil müdahale planı yapılabildi.
GitHub’ın gizli anahtar yönetimini baştan aşağı yenileme süreci, yalnızca şirketin kendi güvenlik standartlarını yükseltmekle kalmadı, aynı zamanda diğer organizasyonlara da sistematik ve ölçülebilir bir temizlik stratejisi sundu. Bu süreç, yalnızca gizli anahtarların değil, aynı zamanda şirketlerin genel güvenlik kültürünün de sürekli iyileştirilmesi gerektiğine dair önemli bir ders niteliğinde. Gelecekte, gizli anahtar yönetimi yalnızca bir güvenlik zorunluluğu değil, aynı zamanda operasyonel mükemmellik için de bir fırsat olmaya devam edecek.
Yapay zeka özeti
GitHub, 15 binden fazla depoda 20 bin gizli anahtar bulunca nasıl sıfır risk noktasına ulaştı? Üç aşamalı strateji ve alınan dersler burada.
