Bulut Depolama Güvenliği: Yanlış Yapılandırılmış Depolama Alanları

Bulut depolama hizmetleri (AWS S3, Azure Blob Storage, Google Cloud Storage), kolay kullanımı sayesinde inanılmaz derecede popülerdir — ama tam da bu kolaylık, en sık YAPILAN güvenlik hatalarından birinin de kaynağıdır: yanlışlıkla herkese açık bırakılan depolama alanları.

Neden Bu Kadar Sık Oluyor?

Bir depolama alanı (bucket/container) oluştururken, erişim izinleri genelde ÜÇ seviyede tanımlanabilir:

1. Özel (private): Sadece yetkilendirilmiş hesaplar erişebilir — GÜVENLİ varsayılan.
2. Hesap içi paylaşım: Aynı bulut hesabındaki/organizasyondaki diğer kullanıcılar erişebilir.
3. Herkese açık (public): İnternetteki HERKES, doğrudan URL ile erişebilir.

Sorun, geliştiricilerin genelde "hızlıca test edeyim" diye BİR ANLIK olarak bucket'ı public yapıp SONRA bunu private'a geri almayı UNUTMASINDAN kaynaklanır — ya da bir CI/CD script'i, yanlışlıkla PRODUCTION bucket'ını public olarak DEPLOY eder.

Tespit Araçları: Otomatik Tarama Şart

Büyük bulut sağlayıcıların HEPSİ, kendi otomatik tarama araçlarını sunar:

• AWS: S3 bucket'ları için "Block Public Access" ayarı VE AWS Config/Trusted Advisor ile sürekli izleme.
• Azure: Microsoft Defender for Cloud, herkese açık storage account'ları otomatik işaretler.
• Üçüncü parti araçlar: ScoutSuite, Prowler gibi açık kaynaklı CSPM (Cloud Security Posture Management) araçları, TÜM bulut ortamını tarayıp yanlış yapılandırmaları raporlar.

Bu tarama, TEK SEFERLİK değil, SÜREKLİ olmalıdır — çünkü bir bucket bugün private olsa bile, yarın bir geliştirici (kasıtsız) onu public yapabilir.

Şifreleme: İkinci Bir Savunma Katmanı

Bucket erişimini doğru yapılandırmak TEK BAŞINA yeterli DEĞİLDİR — Kriptografi kütüphanemizdeki ilkelere göre, VERİNİN KENDİSİNİ de şifrelemek (encryption at rest), bir yapılandırma hatası olsa bile ek bir koruma katmanı sağlar:

• Sağlayıcı tarafından yönetilen anahtarlar (SSE-S3 gibi): Kolay, ama anahtar yönetimi tamamen sağlayıcıdadır.
• Müşteri tarafından yönetilen anahtarlar (SSE-KMS gibi): Müşteri, anahtarın KİMİN kullanabileceğini AYRICA kontrol edebilir — bu, bucket YANLIŞLIKLA public olsa bile, veriyi OKUYABİLMEK için AYRI bir anahtar iznine de ihtiyaç duyulmasını sağlar.

Pratik Senaryo

Bir güvenlik araştırmacısı, internette rastgele bulduğu bir bulut depolama URL'sinin aslında herkese açık olduğunu ve içinde BİNLERCE müşteri belgesi (kimlik fotoğrafları, sözleşmeler) bulunduğunu keşfediyor. İncelemede ortaya çıkan gerçek: bir geliştirici, TEST ortamı için bir bucket'ı geçici olarak public yapmış, sonra bu ayarı GERİ ALMAYI unutmuş — ve zamanla bu "test" bucket'ı, GERÇEK müşteri verilerinin depolandığı PRODUCTION sistemine bağlanmış. Bucket'ın adı GİZLİ (tahmin edilmesi zor) olsa da, arama motorları veya otomatik tarama araçları tarafından ZAMANLA keşfedilebiliyor — "gizlilikle güvenlik sağlamak" (security through obscurity) YETERLİ bir strateji değildir.

Nasıl Önlenir?

• Bucket'ları VARSAYILAN olarak private oluşturmak, public erişimi SADECE açıkça gerektiğinde, BİLİNÇLİ bir kararla açmak.
• CSPM araçlarıyla SÜREKLİ otomatik tarama yapmak.
• Hassas veriler için MUTLAKA şifreleme uygulamak (ek koruma katmanı).
• CI/CD pipeline'larına, deploy ÖNCESİ yapılandırma kontrolü (policy-as-code, örneğin Open Policy Agent) eklemek.

Bu makale, bulut depolama güvenliğinin orta-ileri seviye teknik bir özetidir; siber-arsiv ekibi tarafından hazırlanmış özgün içeriktir.