Bulut güvenliği kimin sorumluluğunda? Yapılandırma hataları ve paylaşılan sorumluluk modeli

Bulut sağlayıcısı bulutun kendisini korur, siz bulutun içine koyduğunuz şeyi korursunuz. AWS bu ayrımı "bulutun güvenliği" ile "buluttaki güvenlik" diye adlandırıyor: veri merkezleri, donanım, hipervizör ve küresel ağ sağlayıcının işidir; kimlikler, erişim yetkileri, ağ kuralları, uygulama kodu, şifreleme ayarları, loglar ve yedekler sizin işinizdir. Bulut ihlallerinin büyük bölümü sağlayıcının altyapısı çöktüğü için olmaz; müşteri tarafında yanlış bırakılmış bir ayar yüzünden olur. Gartner'ın yaygın olarak alıntılanan tahmini bunu net söylüyordu: bulut güvenliği başarısızlıklarının neredeyse tamamı müşteri kaynaklı olacak. Yani sorunuz "sağlayıcım güvenli mi?" değil, "ben kendi tarafımı doğru yapılandırdım mı?" olmalı.

Sınır tam olarak nerede

Paylaşılan sorumluluk modeli sabit bir çizgi değil, seçtiğiniz hizmet tipine göre kayan bir çizgidir. Bir sanal makine (IaaS) kiralarsanız işletim sistemi yamalarından, güvenlik duvarı kurallarından ve üzerine kurduğunuz her şeyden siz sorumlusunuz. Yönetilen bir veritabanı (PaaS) alırsanız sağlayıcı motoru yamalar, siz erişim yetkilerini ve şemayı yönetirsiniz. Bir SaaS ürününde bile veri sınıflandırması, kullanıcı yönetimi ve paylaşım ayarları sizde kalır.

Buradaki en yaygın yanılgı şu: bulut sunucuları kendi kendini güncellemez. Yamasız bir işletim sistemi çalıştıran EC2 ya da Azure VM, aynı durumdaki fiziksel bir sunucu kadar açıktır. Sağlayıcının SOC 2 raporu ya da ISO 27001 sertifikası sizin sunucunuzdaki altı aylık yamayı kapatmaz. Yama yönetimi buluta taşındıktan sonra da sizin sorumluluğunuzdur.

En sık hata: depolamayı internete açık bırakmak

Bulut sızıntılarının klasik senaryosu hâlâ aynı: bir nesne depolama kovası (bucket) yanlışlıkla herkese açık bırakılır ve içindeki dosyalar kimlik doğrulaması olmadan indirilebilir hale gelir. Bunun kötü tarafı sessiz olmasıdır. Ne bir alarm çalar ne bir kilit kırılır; dosyalar sadece oradadır ve internet taramaları onları saatler içinde bulur. Güvenlik araştırmacılarının 2025'te yayımladığı bir çalışma, yanlış yapılandırılmış yüz binlerce bulut kovasında milyarlarca dosyanın dışarıya açık durduğunu ortaya koydu; içlerinde kaynak kodu, kimlik bilgileri ve gizli olarak işaretlenmiş belgeler vardı.

Sağlayıcılar bu konuda varsayılanları sıkılaştırdı. Amazon, Aralık 2022'de duyurduğu değişikliği Nisan 2023'te devreye alarak yeni oluşturulan tüm S3 kovalarında Block Public Access'i açık, ACL'leri kapalı hale getirdi. Microsoft da Ağustos 2023'ten itibaren yeni depolama hesaplarında anonim blob erişimini varsayılan olarak kapattı. Ama dikkat: iki değişiklik de yalnızca yeni kaynaklar için geçerli. 2019'da açılmış bir kova hâlâ eski ayarlarıyla duruyor olabilir ve kimse ona bakmıyorsa öyle kalır.

İkinci hata: fazla yetkili kimlikler

Depolamadan sonra en büyük kategori kimlik ve erişim yönetimidir. Pratikte hep aynı kalıpları görüyoruz: her şeye izin veren joker (*) politikalar, yıllardır dönmemiş kalıcı erişim anahtarları, root ya da global yönetici hesabında MFA'nın kapalı olması, bir uygulamanın ihtiyacı sadece tek bir kovaya yazmak olduğu halde ona proje sahibi rolünün verilmesi.

Bu hataların ortak sonucu, ihlalin yayılma alanını büyütmesidir. Bir saldırgan bir kimlik bilgisini ele geçirdiğinde ne kadar ilerleyebileceğine karar veren şey, o kimliğe verdiğiniz yetkidir. Doğru yaklaşım en az ayrıcalık ilkesi, kalıcı anahtar yerine kısa ömürlü rol tabanlı erişim ve yönetici hesaplarında istisnasız MFA'dır. Sıfır güven yaklaşımı tam olarak bunu bulut ortamına taşıma çabasıdır.

Capital One: hatalar nasıl zincirlenir

Bu konunun en öğretici örneği 2019'daki Capital One olayıdır. Zincir tek bir hatadan oluşmuyordu: yanlış yapılandırılmış bir web uygulama güvenlik duvarı üzerinden SSRF açığı kullanıldı, bu açıkla EC2 örneğinin metadata servisine istek yaptırıldı, oradan geçici IAM kimlik bilgileri alındı ve o kimliğin yetkisi S3'teki verilere erişmeye yetiyordu. Sonuç yaklaşık 106 milyon kişinin verisiydi. Banka, ABD'li düzenleyici OCC'ye 80 milyon dolar ceza ödedi ve sınıf davası 190 milyon dolarlık uzlaşmayla kapandı.

Olaydan çıkan mühendislik dersi kalıcı oldu. AWS, metadata servisinin token tabanlı ikinci sürümünü (IMDSv2) bu tür SSRF istismarına karşı savunma katmanı olarak öne çıkardı; Mart 2024'te hesap düzeyinde "yeni tüm örnekler IMDSv2 kullansın" ayarını kullanıma açtı ve 2024 ortasından itibaren yeni çıkan örnek tipleri yalnızca IMDSv2 destekliyor. Yani sağlayıcı varsayılanı iyileştirdi, ama eski hesaplarda ayarı açmak yine müşterinin işi.

Üçüncü hata: gereksiz açık kapılar ve kapalı loglar

Ağ tarafında en sık rastlanan iki şey, yönetim portlarının (SSH 22, RDP 3389) tüm internete 0.0.0.0/0 olarak açılması ve kimlik doğrulaması olmadan dışarıya bakan veritabanları. İkisi de genelde "geçici olarak açtım, sonra kapatırım" diye başlar.

Log tarafı ise daha sinsi. Bulut denetim kayıtları (AWS CloudTrail, Azure activity log, GCP audit log) kapalıysa ya da tek bir hesapta saldırganın silebileceği yerde tutuluyorsa, olay sonrası "ne oldu, ne kadar veri gitti?" sorusuna yanıt veremezsiniz. KVKK bildirimi hazırlarken kapsamı belirleyemeyen kurumların çoğu bu yüzden zorlanır. Kayıtları ayrı ve yazma korumalı bir hesapta biriktirmek, olay anında elinizdeki tek somut delil olur.

Yedek de sizin sorumluluğunuz

Sık atlanan bir nokta: sağlayıcının verinizi birden fazla kopyayla saklaması yedekleme değildir, dayanıklılıktır. Yanlışlıkla silinen bir tablo, şifrelenen bir dosya sistemi ya da bir hesabın ele geçirilmesi durumunda sizi kurtaracak şey kendi yedekleme politikanızdır. SaaS uygulamalarında da durum aynı: çoğu üründe varsayılan saklama süresi sınırlıdır ve süre geçtikten sonra geri dönüş yoktur. 3-2-1 kuralı bulutta da geçerli, sadece "tesis dışı kopya"nın tanımı değişir: aynı sağlayıcının aynı bölgesindeki ikinci bir kova, tesis dışı sayılmaz.

Yapılandırma bir kez yapılıp bitmiyor

Bulut ortamları kayar. Bir mühendis sorunu çözmek için konsoldan geçici bir kural ekler, test ortamı üretim verisinin kopyasıyla ayağa kalkar, bir ekip kendi kredi kartıyla ayrı bir abonelik açar. Altı ay sonra ortada kimsenin envanterinde olmayan kaynaklar olur.

Bu yüzden kontrol tek seferlik denetimden çok sürekli bir kontrol düzeneği olmalı. Altyapıyı kodla (Terraform, Bicep) tanımlayıp değişiklikleri kod incelemesinden geçirmek, sağlayıcı politikalarıyla (AWS SCP, Azure Policy, GCP organization policy) "kimse herkese açık kova oluşturamaz" gibi kuralları teknik olarak zorunlu kılmak ve sapmaları düzenli taramak işe yarar. Kod içine gömülmüş kimlik bilgileri de bu resmin parçası; sır yönetimi olmadan bulut yapılandırması güvenli olmaz.

Durumunuzu nasıl ölçersiniz

İyi haber şu ki bu alan iyi tanımlanmış. CIS, üç büyük sağlayıcı için Foundations Benchmark yayımlıyor (AWS, Azure ve GCP sürümleri düzenli güncelleniyor) ve bunlar madde madde kontrol edilebilir bir başlangıç listesi verir. Sağlayıcıların kendi araçları da yerleşik puanlama sunuyor: AWS Security Hub, Microsoft Defender for Cloud'un güvenlik puanı, Google Security Command Center. Açık kaynak tarafında Prowler ve ScoutSuite gibi araçlarla ortamınızı bu kıstaslara göre dışarıdan tarayabilirsiniz. Bu araç sınıfının genel adı CSPM, yani bulut güvenlik duruş yönetimi.

Bir uyarı: tarama aracı size uyumsuz ayarların listesini verir, hangisinin gerçekten önemli olduğunu söylemez. Yüzlerce bulgunun içinde iş riskini belirleyen genellikle birkaç tanesidir; internete açık depolama, fazla yetkili kimlik, kapalı log. Önceliklendirme hâlâ insan işi.

KVKK açısından sorumluluk devredilmez

Türkiye'deki hukuki tabloyu da netleştirmek gerekir. Verinizi bir bulut sağlayıcısında tutmanız sizi veri sorumlusu olmaktan çıkarmaz; sağlayıcı genellikle veri işleyen konumundadır ve teknik ile idari tedbirleri almak yine sizin yükümlülüğünüzdür. Yanlış yapılandırma yüzünden veri sızarsa muhatap sağlayıcı değil sizsiniz. Buna ek olarak sunucuların yurt dışında olması durumunda yurt dışına veri aktarımı kurallarının ayrıca sağlanması gerekir.

Nereden başlamalı

Somut bir sıra öneriyoruz. Önce envanter: hangi hesaplar, abonelikler ve projeler var, hangisi kimin sorumluluğunda? Ardından herkese açık kaynakları tarayın ve gerçekten açık olması gerekenler dışındakileri kapatın. Yönetici hesaplarında MFA'yı zorunlu kılın, kalıcı erişim anahtarlarını kısa ömürlü rollerle değiştirin. Denetim loglarını açıp ayrı bir yerde toplayın. Yedekleme ve geri dönüş senaryosunu test edin. Sonra CIS Benchmark'a göre bir taban ölçüm alın ve bunu düzenli tekrarlayın.

Wedevit olarak bulut ortamlarında bu tabloyu bağımsız gözle çıkarıyor, yapılandırma bulgularını iş riskine göre sıralıyor ve düzeltme planını ekiplerinizle birlikte kuruyoruz. Ortamınızın dışarıdan nasıl göründüğünü görmek istiyorsanız bir sızma testi bunu yapılandırma denetiminin üstüne iyi oturur.