Yıllarca Aktif Kalan 9.300 AWS Anahtarı, 768 Şirket Hesabını Tamamen Açıkta Bıraktı

Bir anahtarın depoda görünmesi tek başına onun hâlâ tehlikeli olduğu anlamına gelmez. Ancak anahtar iptal edilmemişse, AWS tarafından kabul ediliyorsa ve anlamlı yetkilere sahipse risk aktif hâle gelir. Bu incelemede bu üç koşulun sık sık bir araya geldiği görüldü.

768 anahtar şirket hesaplarında tam yetki veriyordu

Kurumsal hesaplarla ilişkilendirilen aktif anahtarların 817’si şirketlere aitti. Bu grubun içinde:

• 526 AWS kök hesap anahtarı,
• AWS’nin AdministratorAccess politikasına bağlı 242 IAM kullanıcı anahtarı,
• toplamda şirket AWS hesaplarında tam yönetici kontrolü sağlayan 768 anahtar bulunuyordu.

Kök kullanıcı kimlik bilgileri, bir AWS müşterisinin sahip olabileceği en yüksek yetki seviyesini temsil eder. AdministratorAccess politikasına sahip bir IAM kimliği de AWS servislerinin büyük bölümünde kapsamlı işlemler yapabilir.

Bu düzeyde yetkiye sahip geçerli bir anahtar; hesabın ele geçirilmesi, yetkisiz kaynak oluşturulması, verilerin okunması, altyapının kötüye kullanılması veya beklenmedik bulut faturalarının çıkarılması için kullanılabilir.

Bulgular, sorunun yalnızca kaynak kodu temizleme meselesi olmadığını ortaya koyuyor. Bir anahtarı dosyadan silmek ya da Git geçmişini yeniden yazmak, daha önce kopyalanmış kimlik bilgisini geçersiz kılmaz. Anahtarın mutlaka iptal edilmesi veya yenilenmesi gerekir.

Hugging Face en büyük tekil kaynak oldu

Hugging Face, tespit edilen 8.482 AWS kimlik bilgisi sızıntısıyla en büyük tekil kaynak olarak öne çıktı. Truffle Security, bu AWS kimlik bilgilerinin yüzde 17,9’unun kök kullanıcı kimlik bilgisi olduğunu bildirdi.

Bu sonuç, platformdaki herkese açık veri kümelerine yönelik daha geniş bir taramanın parçasıydı. Truffle Security, 7,6 petabayt büyüklüğündeki kamuya açık Hugging Face verisini incelediğini ve binlerce veri kümesine dağılmış canlı kimlik bilgileri bulduğunu açıkladı. Bu durum, sırların yalnızca yazılım depolarında değil, herkese açık olarak dağıtılan veri kümelerinde de uzun süre yaşayabildiğini gösteriyor.

Güvenlik ekipleri açısından mesaj açık: yalnızca güncel kaynak kodunu taramak yeterli değil. Git geçmişleri, derleme çıktıları, konteyner imajları, kayıt depoları, yayımlanmış veri kümeleri ve CI çıktıları, geliştiriciler sırrı sildiklerini düşündükten sonra bile kimlik bilgilerini koruyabilir.

Anahtarların ortanca yaşı yaklaşık beş yıldı

Raporlanan kimlik bilgilerinin ortanca yaşı yaklaşık 1.831 gün, yani beş yıl civarındaydı. En eski anahtarın yaşı ise 17,4 yıl olarak verildi. Kayıtların yalnızca yüzde 13,7’si, aynı kullanıcıyla ilişkilendirilmiş daha yeni bir anahtara sahipti. Bu da anahtarların büyük bölümünün olağan bir yenileme süreciyle değiştirilmediğine işaret ediyor.

Uzun süre kullanılan erişim anahtarları, yetkisiz kullanım için daha geniş bir zaman aralığı yaratır. Ayrıca çalışan değişiklikleri, uygulama geçişleri, depo temizliği ve sorumlulukların ekipler arasında devredilmesi sonrasında bile kullanılmaya devam edebilir.

Bu nedenle anahtarın yaşı başlı başına bir risk sinyali olarak ele alınmalı. Yıllar önce açığa çıkmış bir anahtarın artık geçersiz olduğu varsayılmamalı; sahibi bunun artık kullanılamadığını kanıtlayamıyorsa anahtar doğrulanmalı, iptal edilmeli ve olası kötüye kullanım araştırılmalı.

Bütçe uyarıları nadiren açıktı

Truffle Security, hesap bilgilerini okuyabildiği 2.754 AWS hesabının yalnızca 262’sinde AWS bütçe uyarılarının etkin olduğunu belirtti.

Bütçe uyarıları, sızmış bir kimlik bilgisinin kötüye kullanılması sonucu kripto madenciliği gibi maliyetli kaynakların oluşturulması durumunda erken uyarı sağlayabilir. Ancak bu uyarılar, anahtar iptalinin veya tehdit tespitinin yerini tutmaz. Bildirimleri alıp müdahale edebilecek bir ekip yoksa olağan dışı harcama, hesap ele geçirildikten sonra da sürebilir.

AWS bildirimleri sorunu tek başına çözmüyor

Bulgulara göre AWS’nin açığa çıktığı tespit edilen erişim anahtarlarını belirleyebilen, etkilenen müşterilere bildirim gönderebilen ve kısıtlama ya da karantina önlemleri uygulayabilen korumaları bulunuyor. Ancak test edilen çok sayıdaki anahtarın hâlâ geçerli olması, bildirim veya tespitin müşteri tarafında her zaman hızlı iptal ve yenilemeyle sonuçlanmadığını gösteriyor.

Tespit, kimlik bilgisi müdahalesinin yalnızca ilk adımı. Eksiksiz bir müdahalede anahtarın sahibi belirlenmeli, erişebildiği kaynaklar ve yetkiler incelenmeli, kötüye kullanım kontrol edilmeli ve anahtar geçersiz kılınmalı.

Truffle Security, doğrulama sürecinin yalnızca okuma işlemlerinden oluştuğunu; kimlik bilgilerinin çalışıp çalışmadığının ve hesap ya da yetki bilgilerinin kontrol edildiğini, müşteri kaynaklarının değiştirilmediğini belirtiyor. Bu yöntem açıklaması Truffle Security’nin kendi beyanına dayanıyor; burada sunulan kaynaklar metodolojinin her operasyonel ayrıntısını bağımsız olarak doğrulamıyor.

AWS anahtarı sızdığında kuruluşlar ne yapmalı?

1. Anahtarı hemen iptal edin veya yenileyin

Herkese açık hâle gelen kimlik bilgisini silin ya da devre dışı bırakın. Erişim gerçekten gerekiyorsa yeni bir anahtar oluşturun. Sırrı depodan kaldırmak, dosyayı silmek veya Git geçmişini yeniden yazmak, daha önce alınmış kopyaları geçersiz kılmaz.

2. Kök kullanıcı erişim anahtarlarını ortadan kaldırın

AWS kök kullanıcı erişim anahtarları rutin programatik erişim için kullanılmamalı. Kök anahtarları silin ve iş yüklerini, yetkileri kontrol edilen ve mümkün olduğunca sınırlı kimliklere taşıyın.

3. Yetkiyi ve sahipliği kontrol edin

Anahtarın hangi hesaba, kullanıcıya, servise ve kaynaklara bağlı olduğunu belirleyin. Kök yetkisine, AdministratorAccess politikasına, geniş veri erişimine veya altyapı oluşturma yetkisine sahip anahtarlara öncelik verin.

4. İptal öncesini ve sonrasını araştırın

Kimlik doğrulama hareketlerini, CloudTrail kayıtlarını, IAM değişikliklerini, yeni oluşturulan kaynakları ve faturalandırma verilerini şüpheli etkinlik açısından inceleyin. Anahtarın iptal edilmesi gelecekteki kullanımı durdurur; anahtarın daha önce kullanılıp kullanılmadığını göstermez.

5. Uzun ömürlü anahtarlar yerine kısa ömürlü kimlikler kullanın

Mümkün olan yerlerde kalıcı erişim anahtarları yerine kısa ömürlü IAM rolleri ve iş yükü kimlikleri tercih edin. En az ayrıcalık ilkesi, sızdırılmış bir kimliğin verebileceği zararı azaltır.

6. Bütçe uyarılarını ve müdahale sürecini yapılandırın

AWS Budgets uyarılarını ve maliyet anomali izlemeyi etkinleştirin. Bildirimleri, hızlı karar alıp işlem yapabilecek kişilere yönlendirin. Finansal izleme bir güvenlik ağıdır; sır tarama, anahtar yenileme ve erişim incelemesinin yerine geçmez.

Daha geniş güvenlik dersi

İncelemenin en önemli sonucu yalnızca bulunan sırların sayısı değil; kamuya açık olma, geçerliliğini koruma, yüksek yetki, aşırı yaş ve yetersiz izleme koşullarının aynı anda görülmesiydi.

Kamuya açık veri depoları, bir kuruluşun nerede kullandığını unuttuğu kimlik bilgilerini yıllarca saklayabilir. Kopyalanmış bir anahtar da açıkça iptal edilene kadar kullanılabilir durumda kalabilir.

Bulut ekipleri için en güvenli yaklaşım şu: Açığa çıkan her AWS kimlik bilgisini ele geçirilmiş kabul edin, erişebildiği kaynakları kontrol edin, hemen yenileyin veya iptal edin ve uzun ömürlü anahtarları kısa ömürlü, en az ayrıcalıkla çalışan kimliklerle değiştirin.