Sistem Mimarisi logo Sistem Mimarisi Bilişim Blogu
Reklam Alanı
Bulut & DevOps
Bulut & DevOps

Bulut Yanlış Yapılandırmaları: Açık S3 Bucket'lardan Ders Çıkarmak

31 Ağustos 2026 · 3 dk okuma · 18 okunma

Bulut veri ihlallerinin büyük çoğunluğu karmaşık sıfırıncı gün (zero-day) saldırılarından değil, basit ve önlenebilir yanlış yapılandırmalardan kaynaklanır. Bunların başında, herkese açık bırakılan depolama kovaları (S3 bucket, Azure Blob Container) gelir. 2017'de bir askeri istihbarat yükleniciye ait, 2019'da bir pazarlama firmasına ait ve daha pek çok vakada, milyonlarca kayıt sadece bir bucket'ın "public" olarak bırakılması yüzünden internete açık kalmıştır.

Neden Bu Kadar Sık Tekrarlanıyor

Kök neden genellikle üçe ayrılır: geliştiricinin test amacıyla geçici olarak açtığı bir bucket'ı kapatmayı unutması, bucket policy'nin joker karakterlerle ("*") aşırı geniş tanımlanması ve varsayılan erişim ayarlarının farkında olmadan "public" bırakılmasıdır. Bu hataların ortak noktası, hiçbirinin sağlayıcı tarafında bir zafiyet olmaması; hepsi Paylaşılan Sorumluluk Modelinde açıkça müşteriye ait alanda gerçekleşir.

Riskli ve Doğru Bucket Policy Karşılaştırması

Aşağıdaki policy, "Principal": "*" ifadesiyle bucket içeriğini kimliği doğrulanmamış herkese açar; bu genellikle bir CDN veya statik site senaryosunda "işe yarasın diye" eklenip sonra kaldırılmayı unutan bir yapılandırmadır:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::sirket-yedekleri/*"
  }]
}

Bu policy bir yedekleme bucket'ına uygulandığında, veritabanı dökümleri veya müşteri kayıtları arama motorları tarafından bile indekslenebilir hale gelir. Doğru yaklaşım, erişimi belirli bir IAM rolüyle ve mümkünse ek koşullarla (kaynak IP, VPC endpoint) sınırlamaktır:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::123456789012:role/yedekleme-servisi" },
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::sirket-yedekleri/*",
    "Condition": {
      "StringEquals": { "aws:sourceVpce": "vpce-0abc123def456" }
    }
  }]
}

Bu sürümde erişim yalnızca belirli bir IAM rolüne ve belirli bir VPC endpoint'i üzerinden gelen isteklere tanınmıştır; internetten doğrudan erişim mümkün değildir.

Savunmanın İkinci Katmanı: Hesap Düzeyinde Engelleme

Tek tek bucket policy'lerine güvenmek yerine, AWS'nin sunduğu "S3 Block Public Access" ayarı hesap düzeyinde etkinleştirilmelidir; bu, bireysel bir mühendisin yanlışlıkla veya bilinçsizce bir bucket'ı herkese açık hale getirmesini merkezi olarak engeller. Bu tür merkezi koruyucu bariyerlere "guardrail" denir ve insan hatasına karşı en etkili savunma katmanıdır.

Sürekli Denetim Şart

  • AWS Config kuralları veya Security Hub ile açık bucket'ları otomatik tespit edin.
  • Bucket düzeyinde varsayılan şifrelemeyi (SSE-KMS) zorunlu kılın.
  • Erişim loglarını (S3 access logging / CloudTrail) merkezi bir SIEM'e yönlendirerek anormal indirme hacimlerini izleyin.
  • Terraform gibi IaC araçlarıyla bucket policy'lerini kod incelemesinden (code review) geçirerek üretime alın; elle konsoldan yapılan değişiklikleri minimuma indirin.
Açık bir S3 bucket, saldırganın kırması gereken bir kilit değil, sadece bulması gereken açık bir kapıdır.

Sonuç olarak açık depolama kovaları vakalarından çıkarılacak ders açıktır: en yıkıcı ihlaller genellikle en sofistike olmayan hatalardan doğar. Dar kapsamlı bucket policy, hesap düzeyinde guardrail'ler ve sürekli otomatik denetim birlikte uygulandığında bu risk sınıfı büyük ölçüde ortadan kaldırılabilir.

İlgili Yazılar