AWS Güvenlik Temelleri: S3 ve IAM Yanlış Yapılandırmalarından Korunma

Son yılların büyük veri sızıntılarının önemli bir kısmı sofistike bir sıfırıncı günden değil, basit bir bulut yanlış yapılandırmasından çıktı. "Açık S3 bucket" artık neredeyse bir klişe. Bu rehberde AWS'de en sık karşılaşılan iki hata alanını, S3 ve IAM'i, savunma gözüyle ele alıyorum. Amaç saldırmak değil, kendi hesabınızı güvenli kurmak.

Konuda anlatılacaklar

1. Bulutta paylaşımlı sorumluluk modeli
   
2. S3 neden sızıyor?
   
3. S3 sertleştirme adımları
   
4. IAM: en az yetke ilkesi
   
5. Tehlikeli IAM desenleri
   
6. Tespit ve izleme
   
7. Yasal uyarı
   

Paylaşımlı Sorumluluk Modeli

AWS güvenliğinin temeli bu kavramı anlamaktan geçer: AWS bulutun kendisinin güvenliğinden (donanım, veri merkezi, altyapı) sorumludur; siz ise buluttaki her şeyin güvenliğinden (verileriniz, erişim politikaları, yapılandırma) sorumlusunuz. Açık kalan bir bucket AWS'nin değil, sizin hatanızdır.

S3 Neden Sızıyor?

S3 (Simple Storage Service), dosya depolama hizmetidir. Sızıntıların tipik sebepleri:

• Bucket veya nesnelerin yanlışlıkla herkese açık (public) yapılması.
  
• Aşırı geniş bucket politikaları (Principal "*").
  
• "Herkes okuyabilsin ama yazamaz" sanılan ama aslında listeleme/indirmeye açık ayarlar.
  
• Yedeklerin/logların ayrı ve korumasız bir bucket'ta tutulması.
  

S3 Sertleştirme Adımları

1. Block Public Access özelliğini hesap ve bucket seviyesinde açık tutun (varsayılan böyledir, kapatmayın).
   
2. Gerçekten herkese açık olması gereken içerik dışında hiçbir bucket'ı public yapmayın; statik web sitesi gibi durumlar için bile CloudFront + OAC tercih edin.
   
3. Varsayılan şifrelemeyi (SSE-S3 veya SSE-KMS) etkinleştirin.
   
4. Erişim için bucket politikası yerine mümkünse IAM rolleri ve en dar kapsamı kullanın.
   
5. Nesne sürümleme ve silme koruması ile fidye/kaza senaryolarına karşı dayanıklılık ekleyin.
   

Hızlı kontrol fikri (yetkiliyseniz kendi hesabınızda):


IAM: En Az Yetki İlkesi

IAM (Identity and Access Management), kimin neye erişebileceğini yönetir. Altın kural: en az yetki (least privilege). Her kimliğe yalnızca işini yapması için gereken izinleri verin.

• Kök (root) hesabı günlük işler için kullanmayın; MFA ile kilitleyip kenara kaldırın.
  
• İnsanlar için mümkünse uzun ömürlü erişim anahtarları yerine geçici kimlik (SSO/rol) kullanın.
  
• Uygulamalara anahtar gömmek yerine IAM rolleri atayın (EC2 instance profile gibi).
  

Tehlikeli IAM Desenleri

Politikalarda şu kalıplardan kaçının:


"Her şeye izin" demek olan bu kalıp, tek bir kimliğin sızması halinde tüm hesabı tehlikeye atar. Ayrıca:

• iamassRole ile aşırı geniş rol geçişi, yetki yükseltmeye yol açar.
  
• "Principal": "*" içeren kaynak politikaları (S3, KMS) dikkatle incelenmeli.
  
• Kullanılmayan eski erişim anahtarları düzenli olarak devre dışı bırakılmalı.
  

Tespit ve İzleme

• CloudTrail'i tüm bölgelerde açın; kim ne yaptı kaydı budur.
  
• AWS Config ile yanlış yapılandırmaları (public bucket, şifresiz volume) otomatik yakalayın.
  
• GuardDuty ile anormal API çağrılarını ve bilinen kötü IP'leri izleyin.
  
• IAM Access Analyzer ile hesap dışına açılan kaynakları tespit edin.
  

Sonuç

Bulut güvenliğinde haberlere düşen çoğu olayın kökeni basit bir ayar hatası. S3'te Block Public Access'i koruyun, IAM'de en az yetki ilkesini uygulayın, CloudTrail/Config/GuardDuty üçlüsünü açın; bu temel adımlar riskin büyük kısmını kapatır. Siz bulut tarafında hangi otomatik kontrolü olmazsa olmaz görüyorsunuz, yorumlarda konuşalım.

Yasal Uyarı

Bu rehberdeki komut ve kontroller yalnızca kendi AWS hesabınızda veya yetkilendirildiğiniz ortamlarda çalıştırılmalıdır. Başkasının bulut kaynaklarını izinsiz taramak/erişmek TCK 243-245 kapsamında suçtur.

Görsel: TurkTeam özgün kapak görseli