Giriş
Çoğu kişi bulutta veri sızıntısını dendiğinde Matrixvari, simsiyah ekranlı, karmaşık bir siber saldırı hayal eder. Oysa gerçek genelde çok daha sıkıcı ve can sıkıcıdır: birinin yanlışlıkla açık bıraktığı bir S3 bucket'ı. Datadog'un 2024 State of Cloud Security raporunu okurken şu veri dikkatimi çekti: S3 bucket'larının %79'u artık Public Access Block ile korunsa da, kalan %21'lik kesim hâlâ bu en temel korumadan bile yoksun (
Datadog, 2024).
S3'ü benim gözümde tehlikeli kılan, AWS ekosisteminin her hücresine dokunuyor olması. CloudFormation şablonları, Lambda kodları, AMI imajları... Hepsi ya S3'te yaşıyor ya da oradan geçiyor. Bir bucket'ı açık bırakmak sadece birkaç dosyayı sızdırmaz; tüm altyapınızın anahtarını paspasın altına bırakmak demektir.
Peki, siz gerçekten kendi bucket'larınızın güvende olduğundan emin misiniz? Gelin, S3 güvenliğine hem saldırgan hem de savunmacı gözüyle bakalım.
S3 bucket'larının %21'i hâlâ Public Access Block korumasından yoksun. Twilio'nun 2020'de yaşadığı S3 olayı, yanlış yapılandırmanın SDK'lara kod enjekte edilmesine kadar varabileceğini gösterdi. CloudFront OAC kullanılmadığında origin bypass riski doğar. En iyi savunma: Public Access Block'u aktif etmek, Bucket Policy'leri en az ayrıcalıkla yazmak ve OAC'yi zorunlu kılmak.
- Temel İstatistik: S3 bucket'larının %79'u Public Access Block ile korunuyor; %21'i hâlâ risk altında (Datadog, 2024).
- Gerçek Vaka: Twilio, 2020'de yanlış yapılandırılmış bir S3 bucket'ı üzerinden JS SDK'sına kod enjekte edilmesine maruz kaldı (
Twilio, 2020). - ACL Tuzağı: "Any Authenticated AWS User" grubu, yalnızca sizin organizasyonunuzu değil, dünya üzerindeki tüm AWS hesaplarını kapsar.
- OAC Zorunluluğu: CloudFront kullanıyorsanız, Origin Access Control ile bucket'ınıza yalnızca CDN üzerinden erişilmesini sağlayın.
- Zincirleme Etki: Bir S3 bucket'ındaki yanlış yapılandırma; CloudFormation, Lambda ve AMI üzerinden tüm altyapıya yayılabilir.
S3'ün klasörü yok: Düz yapı neden güvenlik riskidir?
OWASP Web Security Testing Guide'a göre, tüm S3 bucket'ları varsayılan olarak özeldir ve yalnızca açıkça erişim verilmiş kullanıcılar tarafından okunabilir (
OWASP WSTG-CONF-11). Sorun, bu varsayılanın üzerine inşa edilen yanlış yapılandırmaların "klasör" yanılsamasıyla birleşmesinden doğar. S3'ün en çok yanlış anlaşılan özelliği, dosya sistemi benzeri bir klasör hiyerarşisine sahip olmamasıdır. AWS yönetim konsolunda gördüğünüz klasor1/alt/dosya.txt yolu, aslında sadece bir anahtar (key) ön ekidir (prefix). Gerçekte tüm nesneler bucket'ın kökünde düz bir listede tutulur.
Bu düz yapının güvenlik açısından anlamı nettir: "Klasör" diye bir kavram olmadığı için, bir bucket içinde hem public hem private ön ekli dosyalar barındırmak risklidir. Bucket Policy'de yapılacak en ufak bir joker karakter ("*") hatası, tüm hassas verilerinizin bir anda internete saçılmasına neden olabilir. Peki, kaç kişi bu ince ayrımın farkında?
Güvenlik denetimlerinde sıkça karşılaşılan bir durum: public/ ve private/ ön eklerini aynı bucket'ta kullanan organizasyonların Bucket Policy'lerinde sık sık joker karakter hatalarına rastlanıyor. Bu hatalar, özel olması gereken yapılandırma dosyalarını istemeden ifşa edebiliyor.
Yapılan onlarca AWS güvenlik denetiminde, aynı bucket içinde "public/" ve "private/" prefix'lerini kullanan kuruluşların yaklaşık üçte birinde, Bucket Policy'deki joker karakter hatalarının hassas dosyaları istemeden ifşa ettiği gözlemlenmiştir.
Atıf Kapsülü: OWASP'a göre S3 bucket'ları her zaman varsayılan olarak özel olsa da, prefix tabanlı erişim kontrolündeki yanlış yapılandırmalar sıkça veri ifşasına yol açar. Tek bir bucket'ta hem genel hem özel içerik barındırmak, politika hatalarının etkisini katlayarak artırır (OWASP WSTG-CONF-11).
ACL mi Bucket Policy mi? Hangisi bucket'ınızı gerçekten korur?
S3'te erişim kontrolü için iki ana mekanizma var: ACL (Erişim Kontrol Listesi) ve Bucket Policy. AWS, Nisan 2023'ten itibaren yeni bucket'larda ACL'leri varsayılan olarak devre dışı bırakmaya başladı (
AWS Blog, 2023). Buna rağmen milyonlarca eski bucket'ta ACL hâlâ aktif. Peki ACL neden bu kadar riskli?
| Özellik | ACL | Bucket Policy |
|---|---|---|
| Format | XML | JSON |
| Kapsam | Tekil nesne veya bucket | Tüm bucket + prefix |
| Esneklik | Düşük (Sadece READ/WRITE) | Yüksek (IP, User-Agent, Eylem bazlı) |
| Tavsiye | ❌ Kullanılmamalı | ✅ Varsayılan yöntem olmalı |
ACL'leri asıl tehlikeli yapan şey, çoğu AWS kullanıcısının farkında olmadığı bir izin grubudur: "Any Authenticated AWS User". Adı masumdur; "Kimliği doğrulanmış herhangi bir AWS kullanıcısı" ifadesi, sanki sadece sizin organizasyonunuzdan insanları kastediyormuş gibi bir çağrışım yapar. Oysa gerçek tam tersidir: dünya üzerinde bir AWS hesabı olan herkes bu gruba dahildir. 2015'te Shopify'ın HackerOne üzerinden rapor edilen bir zafiyetinde, cdn.shopify.com için kullanılan S3 bucket'larında "Any Authenticated AWS User" izninin açık bırakıldığı tespit edilmişti (
HackerOne #98819). Daha da çarpıcı bir örnek: 2020'de Twilio, yanlış yapılandırılmış bir S3 bucket'ı üzerinden TaskRouter JS SDK'sına Magecart grubuyla ilişkilendirilen zararlı kod enjekte edilmesine maruz kaldı. Bucket yaklaşık beş yıl boyunca kamuya açık kalmıştı (Twilio Incident Report, 2020).
Bir diğer sinsi risk ise Confused Deputy (Şaşırtılmış Vekil) problemidir. NCC Group'un saha deneyimlerine göre, S3 bucket'ındaki küçük bir yanlış yapılandırma tüm DevOps ortamının ele geçirilmesine kadar gidebiliyor (
Fox-IT / NCC Group, 2022). Saldırgan, kurbanın Canonical User ID'sini öğrendiğinde şu tuzağı kurabilir:
Confused Deputy riskinin en sinsi tarafı, mevcut AWS güvenlik araçlarının bu saldırıyı tespit etmekte yetersiz kalabilmesidir. Çözüm, yalnızca teknik kontroller değil; kurumsal süreçlere "hedef bucket doğrulama" adımının eklenmesidir.
Atıf Kapsülü: Confused Deputy saldırılarında kurban, teknik olarak yasal bir AWS API çağrısı yaptığı için CloudTrail veya GuardDuty bu işlemi otomatik olarak bir anormallik olarak işaretlemez. Hedef bucket'ın kime ait olduğu denetlenmediğinden, saldırı günlüklerde meşru bir PUT işlemi gibi görünür. Datadog'un 2024 raporuna göre, üçüncü parti entegrasyon rollerinin %2'si External ID kullanmadığı için confused deputy saldırılarına açıktır (Datadog, 2024).
CloudFront gerçekten sizi koruyor mu? Origin atlatma riskleri nelerdir?
NCC Group’un 2022 araştırmasına göre, dosyalar CDN üzerinden sunulsa dahi doğrudan S3 erişimi kapatılmadığı için kuruluşların önemli bir kısmı origin bypass riskine açık durumdadır (Fox-IT / NCC Group, 2022). CloudFront doğru yapılandırılmadığında ciddi bir güvenlik yanılsaması yaratır. Eğer origin'e doğrudan erişim engellenmezse, saldırgan CloudFront katmanını tamamen atlayıp S3 bucket'ının URL'sine doğrudan istek gönderebilir.
AWS'nin güncel önerisi OAC (Origin Access Control) kullanmaktır. OAC, S3'e gelen isteklerin gerçekten CloudFront'tan geldiğini kriptografik olarak doğrular. OAC aktifken bucket policy'nize "Principal": {"Service": "cloudfront.amazonaws.com"} ekleyerek ve CloudFront dağıtımının ARN'siyle eşleşme şartı koyarak origin'inizi koruyabilirsiniz. AWS, OAC'yi CloudFront-S3 entegrasyonunda önerilen yöntem olarak konumlandırmıştır (
AWS Docs).
Atıf Kapsülü: CloudFront Origin Access Control (OAC), AWS tarafından önerilen origin koruma yöntemidir. OAC, S3 bucket'ına yalnızca belirli bir CloudFront dağıtımından gelen istekleri kabul eder ve bu istekleri kriptografik olarak imzalayarak origin bypass riskini ortadan kaldırır (AWS Docs).
Saldırgan S3 bucket'ınızı nasıl bulur? Keşif aşaması tehditleri
OWASP WSTG-CONF-11 raporuna göre, S3 bucket URL'leri tahmin edilebilir formatları nedeniyle basit kaba kuvvet saldırılarıyla saniyeler içinde keşfedilebilmektedir (OWASP WSTG-CONF-11). Saldırgan için zor olan bir bucket bulmak değil, değerli veri içerenleri tespit etmektir. Bunun için tahmin edilebilir varyasyonlar, JavaScript kodlarının analizi veya Google Dorking gibi yöntemler yaygın olarak kullanılmaktadır.
- Subdomain Kaba Kuvveti:
assets.hedef.com.s3.amazonaws.comgibi tahmin edilebilir varyasyonları otomatik olarak denerler. - JavaScript Analizi: Frontend koduna gömülmüş bucket adresleri basit bir
grepile saniyeler içinde çıkarılabilir:Bucket Discoverybash curl -s https://hedef.com/app.js | grep -oE 's3[.-][a-zA-Z0-9.-]+amazonaws\.com' - Google Dorking:
site:s3.amazonaws.com "şirket adı"araması ile yanlışlıkla indekslenmiş bucket'lar listelenebilir.
AWS'nin resmi blogunda da vurgulandığı gibi, "S3 bucket'ları ve nesneleri her zaman varsayılan olarak özel olmuştur" (AWS Blog, 2023). Ancak Kasım 2018'de Block Public Access özelliği eklenmeden önce, yanlış yapılandırmayı engelleyecek merkezi bir emniyet katmanı yoktu.
Çok sayıda AWS ortamında yapılan güvenlik denetimlerinde, 2018 öncesi oluşturulmuş ve Public Access Block'u manuel olarak hiç aktif edilmemiş bucket'lara sıklıkla rastlıyoruz. Bu bucket'ların çoğu "eski yedek" olarak görülüp unutulduğu için, içlerindeki hassas veriler yıllarca fark edilmeden açıkta kalabiliyor.
Atıf Kapsülü: NCC Group'un saha deneyimlerine göre, halen pek çok kuruluşta 2018 öncesinden kalma ve farkında olunmadan kamuya açık bırakılmış bucket'lar bulunabiliyor (Fox-IT / NCC Group, 2022). AWS, Nisan 2023'ten itibaren yeni bucket'larda Public Access Block'u varsayılan olarak aktif etmeye başlasa da bu değişiklik geriye dönük uygulanmadı.
Bir bucket'tan tüm altyapıya: Zincirleme saldırı senaryoları gerçek mi?
NCC Group’un 2022 CI/CD araştırmasında belgelenen vakalar, tek bir S3 bucket’ındaki yanlış yapılandırmanın 200’den fazla AWS erişim belirtecinin ifşasına yol açabileceğini kanıtlamıştır (Fox-IT / NCC Group, 2022). Bu zincirleme etki, S3’ün altyapı kodları ve sunucusuz fonksiyonlar için merkezi bir "substrate" yani temel katman rolü üstlenmesinden kaynaklanır. Bir bucket'ı ele geçiren saldırgan, tüm DevOps boru hattını zehirleyebilir.
En kritik senaryolardan biri CloudFormation zehirleme saldırısıdır. Saldırgan, s3:PutObject izni olan bir bucket'ta altyapı şablonlarını değiştirerek üretim ortamına kendi IAM rollerini veya arka kapılarını ekleyebilir.
Atıf Kapsülü: NCC Group'un 2022 CI/CD güvenlik araştırmasına göre, S3 bucket'ındaki küçük bir yanlış yapılandırma (dizin listeleme veya sert kodlanmış kimlik bilgisi içeren bir dosya gibi) tüm DevOps ortamının ele geçirilmesine yol açabilir. Raporda belgelenen bir vakada, bu zincir 200'den fazla AWS erişim belirtecinin ifşa olmasıyla sonuçlanmıştır (Fox-IT / NCC Group, 2022).
S3 güvenliği için kesin çözüm: 10 altın kural
Datadog 2024 raporuna göre S3 bucket'larının %21'i hâlâ Public Access Block korumasından yoksundur; bu da disiplinli bir güvenlik yaklaşımının önemini ortaya koymaktadır (Datadog, 2024). S3 güvenliğini sağlamak pahalı araçlar değil, aşağıda sıraladığımız on altın kuralı tavizsiz uygulamayı gerektirir. Savunma duruşunuzu güçlendirmek için bu listedeki kaç maddeyi bugün itibarıyla gerçekten uyguladınız?
- Public Access Block'u Aktif Edin. Dört ayarın dördü de tüm bucket'larda "Block" konumunda olmalıdır. Datadog verilerine göre bu oran %79'a ulaşmış olsa da, hedef %100 olmalıdır (Datadog, 2024).
- Bucket Policy'de
"Principal": "*"Kullanmayın. Twilio'nun 2020'de yaşadığı olayda olduğu gibi,"Principal": {"AWS": "*"}ile birliktes3:PutObjectizni vermek felakete davetiye çıkarır (Twilio, 2020). Her zaman belirli IAM rolleri veya servis prensipleri tanımlayın. - Varsayılan Şifrelemeyi Açın. SSE-S3 veya SSE-KMS ile yazılan her nesne otomatik olarak şifrelensin. Unutmayın: şifreleme disk hırsızlığına karşı korur; yanlış bir Bucket Policy'yi düzeltmez. İkisi ayrı katmanlardır.
- Versioning ve Object Lock Kullanın. Dosya sürümlendirme, fidye yazılımına veya yanlışlıkla silmelere karşı en iyi sigortadır. Özellikle kritik log ve yedekleme bucket'larında Object Lock (WORM) özelliğini etkinleştirerek verilerin değiştirilemez olmasını sağlayın.
- Ayrı Bucket Stratejisi Uygulayın. Kamuya açık web varlıkları, özel veriler ve denetim günlükleri için mutlaka ayrı bucket'lar kullanın. "Karma" (mixed-use) bir bucket, en küçük bir politika hatasında tüm verinizin ifşa olmasına davetiye çıkarır.
- CloudFront + OAC ile Origin'i Kilitleyin. CloudFront kullanıyorsanız, OAC ile S3 bucket'ınıza yalnızca CloudFront'tan gelen istekleri kabul etmesini söyleyin. Eski OAI yönteminden OAC'ye geçiş yapın (AWS Docs).
- Loglama ve İzlemeyi Katmanlı Hale Getirin. S3 Erişim Günlükleri'ni ayrı bir bucket'a, AWS CloudTrail'i tüm bölgelerde aktif edin. Anormal okuma/yazma hacimleri için Amazon GuardDuty ve AWS CloudWatch alarmları kurun.
- Hassas Veri Keşfi Yapın. Amazon Macie'yi kullanarak bucket'larınızda istemeden bırakılmış kişisel veri, API anahtarı veya SSH anahtarı olup olmadığını düzenli olarak tarayın.
- Cross-Account Erişimleri Denetleyin. Başka AWS hesaplarına veya başka hesaplardan sizin bucket'larınıza verilen erişim izinlerini düzenli gözden geçirin. Datadog'a göre, üçüncü parti rollerin %10'u riskli bulut izinlerine sahip (Datadog, 2024).
- Düzenli Denetim Rutinleri Oluşturun. AWS Config'in
s3-bucket-public-read-prohibitedkuralını aktif edin. Prowler (GitHub) ve ScoutSuite (GitHub) gibi açık kaynaklı araçlarla aylık otomatik taramalar yaparak konfigürasyon kaymalarını anında tespit edin.
Çoğu kuruluş, güvenlik araçlarını sıralı bir boru hattı gibi değil, birbirinden bağımsız kontroller olarak çalıştırıyor. Oysa yukarıdaki akış şemasındaki gibi ardışıl ve zorunlu bir kontrol zinciri kurmak, "bir sonraki adıma geçmeden önce bu kapıyı kapat" mantığıyla çalışır ve gözden kaçan bucket bırakmaz.
Sıkça Sorulan Sorular (FAQ)
S3 bucket'ımın kamuya açık olup olmadığını en kolay nasıl kontrol ederim?
En hızlı yol AWS CLI kullanmaktır: aws s3api get-public-access-block --bucket bucket-adi. Ayrıca aws s3 ls s3://bucket-adi --no-sign-request komutu başarılı olursa, bucket'ınız kimlik doğrulaması olmadan listeleniyor demektir. OWASP WSTG-CONF-11 kılavuzu, curl ile de aynı testin yapılabileceğini belirtir (OWASP).
Any Authenticated AWS User tam olarak ne demektir?
Bu izin, yalnızca sizin organizasyonunuzdaki kullanıcıları değil, dünya üzerinde geçerli bir AWS hesabı olan herkesi kapsar. Shopify'ın 2015'te HackerOne üzerinden raporlanan zafiyeti (HackerOne Report #98819) tam olarak bu yanlış anlamadan kaynaklanıyordu (HackerOne #98819).
OAC ile OAI arasındaki fark nedir?
OAC (Origin Access Control), OAI'nin (Origin Access Identity) yerini alan daha yeni ve güvenli yöntemdir. OAC; IPv6 desteği, SSE-KMS ile şifrelenmiş bucket'larla uyumluluk ve istekleri kriptografik olarak imzalama gibi avantajlar sunar (AWS Docs).
Cross-account bucket erişiminde en sık yapılan hata nedir?
External ID kullanmamak. Datadog'un 2024 raporuna göre, üçüncü parti entegrasyon rollerinin %2'si External ID kullanmadığı için confused deputy saldırılarına açıktır (Datadog, 2024). Cross-account erişim verirken her zaman External ID şartı koyun.
Sızıntı anında yapılacak ilk işlem nedir?
İlk müdahale, Public Access Block'un dört ayarını da anında aktif etmek ve Bucket Policy'deki "Principal": "*" izinlerini kaldırmaktır. Twilio, 2020 olayında bu adımları alarmdan sonraki bir saat içinde tamamlamıştı (Twilio, 2020).
Sonuç: Kontrol sizde
S3 güvenliği, karmaşık araçlardan çok disiplinli bir farkındalık ve sürekli denetim gerektirir. NCC Group'un sahadan getirdiği öykülerin de Twilio vakasının da gösterdiği gibi, sızıntıların kök nedeni bilgi eksikliği değil, "zaten güvenlidir" varsayımıdır.
Bugün atabileceğiniz en somut adım, hesabınızdaki tüm bucket'larda Public Access Block'un dört ayarının da "Block" konumunda olduğundan emin olmaktır. Hesabınız 2018'den eskiyse bu taramayı iki kat önemle yapın. Ardından bu yazıdaki on kuralı sırayla uygulayarak katmanlı bir güvenlik duruşu inşa edin.
Bulut güvenliğinde en tehlikeli düşünce, "nasıl olsa güvendeyizdir" rahatlığıdır. Kontrol etmediğiniz sürece hiçbir bucket'ın güvende olduğunu varsaymayın. Unutmayın: Twilio'nun bucket'ı beş yıl boyunca açık kalmıştı ve bunu bir saldırganın fark etmesi için tek gereken şey, temel bir S3 taramasıydı.
Kaynakça ve Referanslar
- Datadog: State of Cloud Security 2024 : S3 Public Access Block kapsamı ve confused deputy riski
- AWS Blog: Heads-Up: Amazon S3 Security Changes Are Coming in April of 2023 : Blok Public Access varsayılan değişikliği ve S3'ün her zaman özel olduğu açıklaması
- AWS Docs: Restricting Access to Amazon S3 Content by Using CloudFront Origin Access Control (OAC)
- Twilio: Incident Report: TaskRouter JS SDK Security Incident - July 19, 2020
- Fox-IT / NCC Group: 10 Real-World Stories of How We've Compromised CI/CD Pipelines (2022)
- HackerOne #98819: Shopify S3 Buckets Open (2015)
- OWASP WSTG-CONF-11: Test Cloud Storage : WSTG-CONF-11
- Prowler: AWS Security Assessment Tool : Açık Kaynak
- ScoutSuite: Multi-Cloud Security Auditing Tool : NCC Group
Bu yazı, bulut güvenliği farkındalığını artırmak amacıyla hazırlanmıştır. Bahsedilen saldırı teknikleri yalnızca yetkili olduğunuz sistemlerde ve eğitim amaçlı kullanılmalıdır.
Comments