Bulutta IAM Zayıflıkları ve SSRF: Yeni Perimetre Neden Kimlik?

Eski Perimetrenin Yerini Kimlik Aldı

Bulut-native mimarilerde en tehlikeli güvenlik olaylarının büyük bölümü sofistike zero-day sömürüsünden değil, yapılandırma hatalarından ve kimlik yönetimi aksaklıklarından kaynaklanıyor. Bu durum bu olayları daha az ciddi yapmıyor. Tam tersine daha sinsi kılıyor: her yanlış yapılandırma ayrı ayrı bakıldığında rutin ve önemsiz görünebiliyor — ta ki bir saldırgan bunları yüksek etkili bir ihlal yoluna dönüştürene kadar.

SSRF Neden Hâlâ Kritik?

Server-Side Request Forgery, bulut iş yüklerinde özellikle tehlikeli hale geliyor. Çünkü dışarıdaki saldırganın doğrudan erişim yolu olmadığı iç metadata uç noktalarına, uygulama kendi ağı üzerinden erişebiliyor.

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/WebServerRole

Bir iş yükü IMDSv1 tarzı davranış sergilediğinde — veya oturum odaklı korumalar olmaksızın eşdeğer metadata servisine erişim sağladığında — ve o iş yüküne bağlı IAM rolü geniş izinler taşıdığında, basit görünen bir uygulama açığı bulut kontrol düzlemi ihlaline dönüşüyor. Uygulama, saldırganın hiçbir zaman doğrudan erişemeyeceği altyapının proxy'sine dönüşüyor.

Asıl Risk: Over-Privileged IAM

Instance metadata'dan elde edilen çalınmış geçici kimlik bilgilerinin etkisi, bağlı oldukları IAM rolünün yetkisiyle doğru orantılı. Ne yazık ki pek çok bulut ortamı, kolaylık odaklı sağlama süreçleri yoluyla biriken aşırı yetkili servis rolleriyle çalışmaya devam ediyor. Böyle bir role karşı gerçekleştirilen tek bir başarılı SSRF veya token sızdırma şunları verebiliyor:

diğer servislere ait olanlar dahil S3 bucket'larında geniş okuma ve yazma erişimi.

ek rolleri üstlenme ve daha yüksek ayrıcalıklı kimliklere yükselme imkânı.

IAM politikalarını değiştirme ve kalıcı saldırgan kontrollü erişim yolları oluşturma.

geçerli geçici kimlik bilgileriyle meşru API çağrıları aracılığıyla servisler arası yanal hareket.

SSRF'den Bulut İhlaline: Somut Saldırı Yolu

| Adım | Ne Oluyor | Neden Önemli |

| --- | --- | --- |

| 1 | Saldırgan web uygulamasında SSRF açığı buluyor | Uygulama, saldırganın belirlediği hedeflere HTTP isteği gönderiyor |

| 2 | SSRF, http://169.254.169.254/latest/meta-data/iam/security-credentials/WebServerRole adresine ulaşıyor | IMDSv1, geçici AccessKeyId, SecretAccessKey, Token döndürüyor |

| 3 | Saldırgan kimlik bilgilerini dış altyapıdan AWS API çağrısı yapmak için kullanıyor | Geçerli kimlik bilgileri — brute force yok, malware yok |

| 4 | IAM rolünde s3:* ve iam:PassRole izinleri var | Saldırgan tüm S3 verisini okuyor ve daha yetkili rollere yükselebiliyor |

| 5 | Saldırgan kalıcı backdoor IAM kullanıcısı oluşturuyor | SSRF yamalandıktan sonra da erişim devam ediyor — başlangıç açığı artık önemsiz |

Bu beş adımlı yol teorik değil. IMDSv1 etkin ve aşırı yetkili instance rolleriyle çalışan iş yükü barındıran kurumların belgelenmiş ihlal örüntüleriyle doğrudan örtüşüyor.

CSPM Gerçekte Ne Yapmalı?

Olgun bir Cloud Security Posture Management yaklaşımı yüzeysel bulgularda — "public bucket tespit edildi" veya "izin verici policy bulundu" — durmamalı. Operasyonel açıdan anlamlı soru, üç faktörün kesişimini anlamayı gerektiriyor:

hangi uygulamaların metadata servisine ağ yolu olduğu.

bu uygulamaların harici saldırgan girdisinden nasıl etkilenebileceği.

bağlı IAM rollerinin servis varlığı genelinde nelere yetkilendirildiği.

Bu üç faktör birlikte analiz edildiğinde blast radius gerçekçi bir doğrulukla tahmin edilebiliyor.

IMDSv2 ve Sonrası

AWS'deki IMDSv2 gibi iyileştirmeler, oturum odaklı istek akışı zorunluluğu getirerek SSRF tabanlı metadata sömürüsünün önünü önemli ölçüde yükseltiyor. Ama IMDSv2 tek başına altta yatan problemi çözmüyor. Temel riskler IAM rol tasarımı, gizli bilgi yönetimi pratikleri ve kullanıcı kontrollü girdinin sunucu tarafı ağ davranışını etkilemesine izin veren uygulama katmanı güven varsayımları.

MyVuln Yaklaşımı

MyVuln burada, geleneksel CVE tipi sinyaller ile bulut yanlış yapılandırma bulgularının aynı risk modeli içinde analiz edildiğinde en somut değeri üretiyor. MyVuln'un maruziyet korelasyon görünümü, internet-facing iş yüklerindeki CVE'leri ilişkili IAM rol izinleriyle bağlıyor — ekibinizin kullandığı bir web framework için yeni bir SSRF sınıfı zafiyeti yayımlandığında platform anında hangi dağıtılmış instance'ların sömürüyü çok daha ağır kılacak aşırı yetkili roller taşıdığını gösteriyor. Bir web uygulaması açığı, dışa açık bir metadata servisi yolu ve aşırı yetkili bir IAM rolü tek bir tutarlı saldırı yolu oluşturuyorsa üç ayrı iş akışında yönetilmemeli. Bütünleşik görünürlük, bu zinciri bir saldırgan keşfedip geçmeden önce görünür kılıyor.