Açık kova sorunu

Bulut sızıntısı haberlerinin çoğunun altında aynı cümle yatar: yapılandırması yanlış bir depolama kovası. Ortada ne sıfırıncı gün açığı vardır ne karmaşık bir saldırı zinciri. Bir ayar yanlış konumdadır ve veri, adresini bilen herkese açıktır. Saldırganın yaptığı tek şey doğru adrese imzasız bir istek göndermektir.

Önce kovanın erişimini belirleyen katmanları tek tek açacaksın. Sonra açık bir kovayı komut satırından okuyup kapatacaksın. Kovayı açmadan statik site yayımlamayı ve dosya paylaşmayı da göreceksin. En sonda değişikliği yakalayan kayıtlara ve fidye yazılımına karşı üç ayara bakacaksın.

Kova (bucket) basit bir nesne deposudur. İçine dosya koyarsın, her dosyanın bir anahtarı (key) olur ve dosya HTTP üstünden çekilir. AWS'de bu servisin adı S3'tür.

Genel amaçlı bir kovanın adı bütün AWS hesapları arasında tektir ve adrese doğrudan girer: önce kova adı, sonra servis ve bölge, en sonda nesnenin anahtarı. Azure'da aynı yapı depolama hesabı, kapsayıcı (container) ve blob olarak kurulur. Google Cloud'da yine kova ve nesne vardır.

Adlar değişir, kavram değişmez. Yedekler, günlükler, müşteri yüklemeleri ve derleme çıktıları çoğu zaman bir kovada durur. Yanlış bir ayar bu yüzden bütün bu veriyi birden açar.

Bir isteğin kabul edilip edilmeyeceği birkaç katmanda birden belirlenir. İlki kimlik politikasıdır: IAM kullanıcısına ya da role bağlı izinler. İkincisi kova politikasıdır; kovanın üstüne yazılır ve kime ne izin verildiğini söyler. Üçüncüsü erişim denetim listesidir (ACL).

Eski bir mekanizmadır ve Nisan 2023'ten beri yeni kovalarda kapalı gelir. Bu ayarın adı BucketOwnerEnforced'dur: kovadaki her nesne kova sahibinindir ve ACL'ler izin hesabına girmez. Dördüncüsü genel erişim engelidir (Block Public Access). Diğerlerinin üstünde bir tavan gibi çalışır.

Değerlendirmenin kuralı sadedir. Herhangi bir politikadaki açık Deny her izni yener. İzin politikadan ya da ACL'den gelebilir. Engel ise genel erişimi hangi katmandan gelirse gelsin keser.

Politikadaki Principal alanı, kuralın kime uygulandığını belirler. Değer yıldız olduğunda kimlik doğrulaması yapmayan her istemci kurala girer ve nesne dünyaya açılır. S3 bir politikanın genel olup olmadığına kendisi karar verir ve işe politikayı genel sayarak başlar.

Politika ancak izni sabit değerlere bağlarsa genel olmaktan çıkar. Sabit değer belirli bir hesap, rol, VPC uç noktası, kaynak ARN'si ya da dar bir IP aralığıdır. Joker taşıyan bir koşul bu şartı sağlamaz.

Örneğin aws:SourceVpc değeri vpc-* ise politika hâlâ geneldir. IPv4'te /8'den geniş bir genel IP aralığı da genel sayılır. Denetim aracı bu yüzden önce Principal alanına, sonra koşullara bakar.

Genel erişim engeli dört ayrı ayardan oluşur. İkisi erişim listelerini, ikisi politikaları hedefler. BlockPublicAcls, genel izin veren yeni bir ACL yazma isteğini reddeder. IgnorePublicAcls, var olan genel ACL'leri yok sayar ama silmez.

BlockPublicPolicy, genel izin veren bir kova politikası yazma isteğini reddeder. RestrictPublicBuckets ise önceden yazılmış genel bir politikanın etkisini daraltır. O kovaya artık yalnız AWS servisleri ve kova sahibinin hesabındaki yetkili kimlikler erişir. Bu ayar, genel politikadan doğan hesaplar arası erişimi de keser.

Dört ayar birbirinden bağımsızdır. AWS'nin önerisi dördünü birden, hem hesap hem kova düzeyinde açmaktır.

Engel dört düzeyde tanımlanır: AWS Organizations, hesap, kova ve erişim noktası. Düzeyler çelişirse S3 en kısıtlayıcı birleşimi uygular. Hesapta engel açıksa kova düzeyinde kapatmak kovayı açmaz.

Organizasyon düzeyindeki politika seçtiğin üye hesaplara kendiliğinden iner ve dört ayarı tek parça uygular. Nisan 2023'ten beri her yeni kova engel açık ve ACL kapalı doğar. Yani bugün açık bir kova çoğu zaman bilerek yapılmış bir değişikliğin sonucudur.

Eski kovalar bu varsayılandan yararlanmaz. Bir nokta daha var: engel var olan politikayı ve ACL'yi değiştirmez. Engeli kaldırdığın an, genel politika taşıyan kova yeniden açılır. Bu yüzden engel açık olsa da politikayı temizlersin.

Saldırgan işe kova adını bulmakla başlar. Ad sanıldığı kadar gizli değildir. Mobil uygulama paketlerinde, ön yüz JavaScript dosyalarında, kod depolarında ve eski belgelerde düz metin durur. Bir alt alan adının CNAME kaydı doğrudan kovayı gösterebilir.

Statik site kovasının adı çoğu zaman alan adının kendisidir ve o ad sertifika şeffaflık günlüklerinde görünür. Tahmin de işe yarar: şirket adına yedek, log ya da test eklenir. Tarayıcı botları bu adları toplar ve sürekli dener. MITRE ATT&CK kovadaki nesneleri sıralamayı T1619 (Cloud Storage Object Discovery), içlerindeki veriyi toplamayı T1530 (Data from Cloud Storage) olarak tanımlar.

Adı bulduktan sonra saldırganın tek ihtiyacı imzasız bir HTTP isteğidir. Anahtar, parola ya da hesap gerekmez. Aşağıda aynı kovaya önce saldırgan, sonra denetçi gözüyle bakıyorsun. Bu denemeyi yalnız kendi lab hesabında ya da yazılı iznin olan bir hesapta yap.

# Saldırgan gözü: kimlik bilgisi yok, istek imzasız
$ curl -s -o /dev/null -w '%{http_code}\n' https://lab-yedekler.s3.amazonaws.com/musteri-2026.csv
200

# Denetçi gözü: S3'ün kendi değerlendirmesi ve politikanın kendisi
$ aws s3api get-bucket-policy-status --bucket lab-yedekler
{
    "PolicyStatus": {
        "IsPublic": true
    }
}
$ aws s3api get-bucket-policy --bucket lab-yedekler --query Policy --output text
{"Version":"2012-10-17","Statement":[{"Sid":"HerkeseOku","Effect":"Allow","Principal":"*","Action":"s3:GetObject","Resource":"arn:aws:s3:::lab-yedekler/*"}]}

Çıktıyı satır satır oku. curl komutu hiçbir kimlik bilgisi taşımaz, yine de 200 alır. Kova kapalı olsaydı yanıt 403 ve AccessDenied gövdesi olurdu. get-bucket-policy-status komutu S3'ün kendi kararını verir: IsPublic değeri true ise politika genel sayılmıştır.

get-bucket-policy politikayı döndürür; --query Policy --output text kısmı onu kaçış karakterleri olmadan basar. Politikada üç ayrıntı önemlidir. Principal yıldızdır, yani herkes. Eylem s3:GetObject'tir, yani okuma var ama listeleme yok.

Kaynak sonu /* ile biten ARN'dir, yani kovadaki her nesne. Listelemenin olmaması teselli değildir. musteri-2026.csv gibi adlar tahmin edilir ya da eski bir sayfadaki bağlantıda durur.

# 1) Genel ifadeyi taşıyan politikayı kaldır (ya da daraltılmış politikayı yaz)
$ aws s3api delete-bucket-policy --bucket lab-yedekler

# 2) Kova düzeyinde dört engeli birden aç
$ aws s3api put-public-access-block --bucket lab-yedekler \
    --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# 3) Hesap düzeyinde aynı dört engeli aç
$ aws s3control put-public-access-block --account-id 111122223333 \
    --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Düzeltme üç adımdır. Önce genel ifadeyi politikadan çıkarırsın; kovaya başka bir izin gerekmiyorsa politikayı tümden silersin. Sonra kova düzeyinde dört engeli açarsın.

En son hesap düzeyinde aynı dört ayarı açarsın. Dikkat et, hesap düzeyi s3api ile değil s3control ile yazılır. Her adımdan sonra curl isteğini yinelersin; beklenen yanıt artık 403'tür.

Düzeltmeyi bir değişiklik kaydına yazmak da işin parçasıdır. Kovayı kimin, ne zaman ve neden açtığını CloudTrail kayıtlarından çıkarırsın. Arkada bilinçli bir statik site ihtiyacı varsa onu bir sonraki bölümdeki doğru yola taşırsın.

Kovalar çoğu zaman gerçek bir iş ihtiyacı yüzünden açılır. En yaygını statik sitedir. Kovayı herkese açıp site barındırmayı etkinleştirmek çalışır ama yanlış yoldur.

Doğru kurulumda kova özel kalır ve önüne bir CloudFront dağıtımı konur. Dağıtım, kovaya giden her isteği Origin Access Control (OAC) ile imzalar.

Kova politikası okumayı yalnız CloudFront servisine verir ve aws:SourceArn koşuluyla bu izni tek bir dağıtıma bağlar. Sonuçta içerik yayımlanır ama kova doğrudan çekilmez. Eski yöntem olan Origin Access Identity (OAI) hâlâ karşına çıkar. AWS yeni kurulumlarda OAC'yi önerir, çünkü OAC KMS ile şifreli nesneleri ve bütün bölgeleri destekler.

Başka ihtiyaçlar için de kovayı açmak gerekmez. Ön imzalı adres (presigned URL), tek bir nesneye süreli erişim verir. Adresi üreten kimliğin yetkisiyle çalışır ve süre dolunca geçersiz olur. CLI ile en fazla yedi gün verilir.

Geçici kimlikle üretilen adres, o kimliğin süresi bitince erken ölür. Ama adres bir taşıyıcı jetondur: eline geçen herkes kullanır. Bu yüzden kısa süre verirsin ve adresi günlüklere yazdırmazsın.

Erişim noktası (access point) ise kovaya kendi politikası olan ayrı bir kapı açar. VPC kökenli bir erişim noktası yalnız o ağdan gelen isteği kabul eder. Her uygulamaya kendi kapısını verirsin ve kova politikası tek bir dev belgeye dönüşmez.

Bir de hesaplar arası paylaşım vardır. Kova politikası belirli bir iş ortağı hesabına okuma verebilir. Politika sabit bir hesaba bağlandığı için genel sayılmaz, yani genel erişim engeli bu paylaşımı durdurmaz. Bu tasarım gereğidir ama denetimde kör nokta yaratır.

IAM Access Analyzer burada işe yarar: kuruluşun dışına ya da internete açılan her kovayı bulgu olarak listeler. Hesap dışına açılan her kaynağın yazılı bir gerekçesi ve bir bitiş tarihi olur.

Gerekçesi olmayan paylaşım kapatılır. Gerekçesi olan bulgu arşivlenir ve kayda geçer. Böylece bir sonraki denetimde aynı soruyu yeniden sormazsın.

Önleme bir gün delinir, tespit bu yüzden ayrı kurulur. Kova politikasını, ACL'yi ya da engeli değiştiren her çağrı CloudTrail'e yönetim olayı olarak düşer: PutBucketPolicy, PutBucketAcl, PutPublicAccessBlock ve DeletePublicAccessBlock. Nesne okuma ise veri olayıdır (data event) ve varsayılan izde kaydedilmez. Hassas kovalarda veri olaylarını ayrıca açarsın, yoksa kimin neyi indirdiğini sonradan göremezsin.

GuardDuty bu kayıtları okur. Bir kovayı internete açan değişikliği Policy:S3/BucketAnonymousAccessGranted bulgusuyla bildirir. Bir kimliğin alışılmadık okuma davranışını Exfiltration:S3/AnomalousBehavior bulgusuyla bildirir. İkinci bulgu veri olaylarına dayanır, bu yüzden GuardDuty'nin S3 koruması açık olmalıdır.

Büyük hesaplarda elle denetim mümkün değildir. Prowler ve ScoutSuite yüzlerce kovayı tarar, genel politikaları ve eksik ayarları listeler. Security Hub CSPM'deki S3.8 denetimi de kova düzeyinde engelin açık olup olmadığına bakar.

İlk taramanın listesi uzun çıkar. Hepsini aynı gün kapatmaya çalışmak yerine veri sınıfına göre sıralarsın. Macie burada işe yarar: kovalardaki nesneleri örnekler ve kişisel veri bulduğunda bulgu üretir.

Kişisel veri taşıyan açık kova listenin başına geçer, derleme çıktısı taşıyan kova sona kalır. Sahipsiz kovalar ayrı bir sorundur. Proje biter, kova kalır. Sahip ve veri sınıfı etiketi olmayan her kova ilk gözden geçirmede listeye düşer.

Denetimde yalnız açıklığa bakmak eksiktir. Kimliği çalınmış bir hesap veriyi okumakla kalmaz, siler ya da üstüne yazar. Üç ayar buna karşı durur.

Sürümleme (versioning), silinen ya da üstüne yazılan nesnenin eski sürümünü saklar. Nesne kilidi (Object Lock), sürümü belirli bir süre bir kez yaz, çok oku (WORM) modunda tutar ve sürümlemesiz çalışmaz. Uyum modunda (compliance) bu süre boyunca kök kullanıcı bile sürümü silemez.

Yönetişim modunda (governance) ise özel izni olan kimlik kilidi aşabilir. Yaşam döngüsü kuralı eski sürümleri belirli bir sürede temizler ve maliyeti dengeler. Bu kuralı değiştirme yetkisini de dar tutarsın, çünkü saldırgan yaşam döngüsüyle veriyi toplu siler.