Bulut Güvenliğinde Yanlış Yapılandırmalar (Cloud Misconfigurations) ve Önleme Yolları

Bulut ihlallerinin büyük kısmı sofistike saldırılardan değil, açık bırakılmış bir depolama alanından ya da fazla yetkili bir anahtardan kaynaklanır. En sık görülen hataları ve kalıcı çözümlerini adım adım ele alıyoruz.

Bulut Güvenliğinde Yanlış Yapılandırmalar (Cloud Misconfigurations) ve Önleme Yolları

Bulut sağlayıcıları altyapının fiziksel güvenliğini üstlenir; ancak sizin yapılandırdığınız her şey sizin sorumluluğunuzdadır. Buna "paylaşılan sorumluluk modeli" denir ve bulut ihlallerinin büyük bölümü tam da bu çizginin sizin tarafınızda gerçekleşir: herkese açık bırakılmış bir depolama alanı, yıllardır dönmeyen bir erişim anahtarı ya da "şimdilik" verilmiş bir yönetici yetkisi.

Bu yazıda AWS, Azure ve Google Cloud ortamlarında sahada en sık karşılaşılan yanlış yapılandırmaları, bunların nasıl istismar edildiğini ve kalıcı olarak nasıl kapatılacağını ele alıyoruz.

Paylaşılan sorumluluk: çizgi nerede?

KatmanSağlayıcıSiz
Fiziksel veri merkezi, donanım✓
Sanallaştırma katmanı✓
Kimlik ve erişim yönetimi (IAM)✓
Ağ kuralları, güvenlik grupları✓
Depolama erişim politikaları✓
Uygulama, veri, şifreleme anahtarları✓

Tablodaki "Siz" sütunu, bu yazının konusudur.

1. Herkese açık depolama alanları

En bilinen ve hâlâ en yaygın hata. Bir geliştirici statik dosyaları sunmak için bir S3 bucket'ını, Azure Blob kapsayıcısını veya GCS bucket'ını herkese açık yapar; zamanla aynı alana yedekler, dışa aktarılmış veritabanları veya log dosyaları da düşer.

Gerçekçi senaryo

Bir e-ticaret şirketi ürün görsellerini sirket-assets adlı açık bir bucket'tan sunuyor. Bir gün bir çalışan müşteri listesini analiz için aynı bucket'a export/musteriler-2026.csv olarak yüklüyor. Bucket adları tahmin edilebilir olduğu için otomatik tarayıcılar bu dosyayı saatler içinde buluyor.

Nasıl önlenir?

  • Hesap düzeyinde genel erişimi engelleyin. AWS'de S3 Block Public Access ayarını hesap seviyesinde açın; Azure'da depolama hesabında Allow Blob public access seçeneğini kapatın; GCP'de Public access prevention politikasını zorunlu kılın.
  • Genel içeriği CDN üzerinden sunun. Bucket'ı açmak yerine CloudFront Origin Access Control, Azure Front Door veya Cloud CDN ile yalnızca CDN'in erişebildiği özel bir kaynak kullanın.
  • Veriyi sınıflandırın. Kişisel veri içeren bucket'ları etiketleyin ve bunlar için ayrı, daha katı politikalar uygulayın.
# AWS: hesap genelinde herkese açık erişimi kapat
aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

2. Aşırı geniş IAM yetkileri

"Çalışsın da sonra düzeltiriz" mantığıyla verilen AdministratorAccess, Owner veya *:* yetkileri, bir anahtar sızdığında saldırgana tüm hesabın kapısını açar.

Gerçekçi senaryo

Bir CI/CD hattı yalnızca tek bir bucket'a dosya yüklemek için kullanılıyor, ama ona tam yönetici yetkili bir erişim anahtarı verilmiş. Bu anahtar yanlışlıkla herkese açık bir Git deposuna commit ediliyor. Saldırgan anahtarla yeni kullanıcılar oluşturuyor, kalıcılık sağlıyor ve kripto madenciliği için pahalı sunucular başlatıyor.

Nasıl önlenir?

  • En az yetki ilkesi: Her kimliğe yalnızca işini yapması için gereken eylemleri ve kaynakları verin.
  • Kullanılmayan yetkileri temizleyin: AWS IAM Access Analyzer, Azure'daki erişim incelemeleri ve GCP IAM Recommender gerçekte kullanılmayan izinleri gösterir.
  • Uzun ömürlü anahtarlardan kaçının: CI/CD için GitHub Actions OIDC gibi kısa süreli, kimlik federasyonu tabanlı erişim kullanın.
  • Kök/sahip hesaplarını kilitleyin: Donanım anahtarıyla MFA zorunlu olsun, günlük işlerde asla kullanılmasın.
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:PutObject"],
    "Resource": "arn:aws:s3:::sirket-deploy/releases/*"
  }]
}

Yukarıdaki politika, "her şeye izin ver" yerine tek bir eylem ve tek bir klasörle sınırlıdır. Anahtar sızsa bile hasar bu klasörle sınırlı kalır.

3. İnternete açık yönetim portları

SSH (22), RDP (3389) veya veritabanı portlarının (3306, 5432, 27017) güvenlik grubunda 0.0.0.0/0 ile açılması, sunucuyu dakikalar içinde kaba kuvvet denemelerinin hedefi yapar.

  • Yönetim erişimini AWS Systems Manager Session Manager, Azure Bastion veya GCP IAP gibi port açmayı gerektirmeyen hizmetlerle yapın.
  • Veritabanlarını her zaman özel alt ağlarda tutun; uygulama sunucusu dışında hiçbir kaynaktan erişime izin vermeyin.
  • Güvenlik grubu değişikliklerini izleyen bir alarm kurun.

4. Kapalı veya eksik kayıt (logging)

Bir olay yaşandığında ilk soru "ne oldu?" olur. CloudTrail, Azure Activity Log veya GCP Cloud Audit Logs kapalıysa bu soruya yanıt veremezsiniz.

  • Yönetim olaylarını tüm bölgelerde kaydedin ve logları ayrı, silinemez bir depolamaya gönderin.
  • Kök hesap girişi, MFA'nın kapatılması, yeni erişim anahtarı oluşturulması gibi kritik olaylara alarm tanımlayın.
  • Logların saklama süresini hem yasal gereklilikleri hem de olay müdahalesi ihtiyacını karşılayacak şekilde belirleyin.

5. Kod ve imajlara gömülü sırlar

Veritabanı parolaları, API anahtarları ve bağlantı dizeleri kaynak koda, Docker imajlarına veya ortam dosyalarına gömüldüğünde, depoya erişen herkes bu sırlara da erişir.

  • Sırları AWS Secrets Manager, Azure Key Vault veya GCP Secret Manager gibi kasalarda tutun.
  • Commit öncesi gitleaks veya trufflehog ile tarama yapın; CI hattına da ekleyin.
  • Sızdığından şüphelenilen her anahtarı hemen döndürün; silmek tek başına yetmez, Git geçmişinde kalır.

Kalıcı çözüm: yapılandırmayı kod olarak yönetin

Tek tek hataları düzeltmek bir sonraki hatayı engellemez. Kalıcı çözüm, altyapıyı Terraform veya benzeri araçlarla kod olarak tanımlamak ve bu kodu dağıtımdan önce otomatik olarak denetlemektir.

  1. Altyapıyı Terraform/Bicep/CloudFormation ile tanımlayın; konsoldan elle değişikliği istisna hâline getirin.
  2. Pull request aşamasında checkov, tfsec (Trivy) gibi araçlarla yanlış yapılandırmaları otomatik yakalayın.
  3. Canlı ortamı sürekli izleyen bir CSPM (bulut güvenlik duruşu yönetimi) çözümü kullanın: AWS Security Hub, Microsoft Defender for Cloud veya Security Command Center.
  4. CIS Benchmark kontrollerini temel alın ve sapmaları haftalık olarak raporlayın.
Hızlı başlangıç kontrol listesi

Genel erişim engeli açık mı? Kök hesapta donanım MFA var mı? 90 günden eski erişim anahtarı var mı? 22/3389 portları internete açık mı? Denetim logları tüm bölgelerde açık mı? Bu beş sorunun yanıtı, bulut güvenliğinizin yarısını anlatır.

Sonuç

Bulut güvenliğinde en tehlikeli açıklar çoğu zaman en basit olanlardır. İyi haber şu ki bu hataların neredeyse tamamı otomatik araçlarla bulunabilir ve bir kez kod olarak düzeltildiğinde tekrar etmez. Bulut ortamınızın bir saldırganın gözünden nasıl göründüğünü öğrenmek isterseniz, siber güvenlik hizmetlerimiz kapsamında yapılandırma denetimi ve sızma testi yapabiliriz.

  • #bulut güvenliği
  • #AWS
  • #Azure
  • #GCP
  • #S3
  • #IAM
  • #yanlış yapılandırma

Sistemleriniz gerçekten güvende mi?

Ücretsiz ön görüşme için bugün yazın. İhtiyacınızı birlikte değerlendirelim.

Teklif Al

İlgili yazılar