2019 yılında Capital One'ın AWS altyapısında yaşanan veri sızıntısı, 100 milyon Amerikalı ve 6 milyon Kanadalının kredi başvurusu bilgilerini ifşa etti. Saldırı, yazılım güvenlik açığından değil, yanlış yapılandırılmış bir IAM rolünden kaynaklanıyordu. Bu olay, bulutun ne kadar güçlü bir platform olduğunu değil; ne kadar kolay hatalı kullanılabileceğini gösterdi.
Kurumlar her yıl bulut güvenliğine milyarlarca dolar harcıyor. Peki gerçekten güvende misiniz?
Paylaşılan Sorumluluk Modeli: Kim Ne Yapar?
AWS, Azure ve Google Cloud gibi sağlayıcıların sunduğu "paylaşılan sorumluluk modeli" kavramını anlamak, her şeyin başlangıç noktasıdır. Bulut sağlayıcısı fiziksel altyapıyı, hipervizörü ve ağ omurgasını korur. Ama veri güvenliği, erişim yönetimi ve uygulama konfigürasyonu sizin sorumluluğunuzdadır.
"Buluta aldım, onlar halleder" düşüncesi yanlış. Veri sızıntılarının büyük çoğunluğu altyapı zafiyetlerinden değil, müşteri tarafındaki yanlış yapılandırmalardan kaynaklanıyor.
| Katman | AWS/Azure/GCP Sorumluluğu | Müşteri Sorumluluğu |
|---|---|---|
| Fiziksel güvenlik | ✅ Tam | — |
| Ağ altyapısı | ✅ Tam | — |
| Hipervizör / VM izolasyonu | ✅ Tam | — |
| İşletim sistemi (IaaS) | — | ✅ Müşteri |
| Uygulama konfigürasyonu | — | ✅ Müşteri |
| Veri şifreleme | Araç sağlar | ✅ Yapılandırma müşteride |
| Kimlik ve erişim yönetimi | Servis sağlar | ✅ Politika müşteride |
Şifreleme: Durağan ve Hareket Halinde Veri
Bulutta depolanan verilerin iki kritik güvenlik noktası var: durağan veri (at-rest) ve iletim halindeki veri (in-transit).
At-rest şifreleme için tüm büyük bulut sağlayıcıları varsayılan olarak AES-256 sunuyor. Ancak "varsayılan" ile "yeterli" aynı şey değil. Kritik veriler için müşteri tarafında şifreleme (CSE) uygulamak gerekir; yani veriler buluta gönderilmeden önce siz şifrelersiniz. Bu durumda bulut sağlayıcısı bile verinizi okuyamaz.
In-transit şifreleme için TLS 1.3 standardı artık zorunlu kabul edilmeli. Eski TLS 1.0 ve 1.1 sürümleri ciddi açıklar taşıyor; bunları devre dışı bırakın.
Şifreleme anahtarlarını verinin yanında saklamak kasanın anahtarını kasanın üstüne koymak gibidir. AWS KMS, Azure Key Vault veya Google Cloud KMS gibi çözümler anahtarları veriden ayrı yönetir. HSM (Hardware Security Module) seçenekleri ise kurumsal düzeyde ek güvenlik katmanı sağlar.
Kimlik ve Erişim Yönetimi: En Sık İhmal Edilen Alan
AWS'deki Capital One saldırısı, yanlış yapılandırılmış bir IAM rolü üzerinden gerçekleşti. Benzer vakalar her yıl onlarca kurumu etkiliyor. IAM (Identity and Access Management) güvenliğinin temel prensibi en az ayrıcalık (least privilege)'dir: her kullanıcı ve servis, yalnızca işini yapabilmesi için gereken minimum izinlere sahip olmalı.
- Root hesabını günlük işlemler için hiçbir zaman kullanmayın
- Tüm kullanıcı hesaplarına MFA (çok faktörlü doğrulama) zorunlu kılın
- Servis hesaplarına geniş kapsamlı politikalar atamaktan kaçının
- Periyodik erişim denetimleri yapın; kullanılmayan izinleri temizleyin
- Geçici kimlik bilgilerini (temporary credentials) uzun süreli erişim anahtarlarına tercih edin
Yanlış Yapılandırma: En Yaygın Veri Sızıntısı Nedeni
Gartner'ın tahminine göre 2025 yılına kadar bulut güvenlik ihlallerinin %99'u müşteri kaynaklı yanlış yapılandırmalardan kaynaklanacaktı. Tahmin doğru çıktı.
En yaygın hata: AWS S3 bucket'larının, Azure Blob Storage'ın veya GCP Cloud Storage'ın yanlışlıkla herkese açık (public) bırakılması. 2017-2023 yılları arasında milyonlarca kişinin kişisel verisini ifşa eden yüzlerce olay bu şekilde gerçekleşti. Accenture, Verizon, Pentagon askeri kayıtları… liste kabarık.
2019'da bir araştırmacı, kamuya açık bir AWS S3 bucket'ında 100'den fazla Amerikalı belediyesine ait 2 milyonun üzerinde mahkeme dosyasını buldu. Hiçbiri şifrelenmemişti, erişim kontrolü yoktu. Dosyalar aylarca açıkta kalmış olabilirdi.
Bu riski azaltmak için Cloud Security Posture Management (CSPM) araçlarını kullanın. AWS Security Hub, Azure Defender for Cloud, Google Security Command Center ve bağımsız çözümler (Wiz, Prisma Cloud) yanlış yapılandırmaları otomatik olarak tespit eder.
Zero Trust Mimarisi
Geleneksel güvenlik anlayışı "ağ içindeysen güvenlisin" mantığına dayanıyordu. Zero Trust bu varsayımı tamamen reddeder: kimseye, hiçbir şeye, varsayılan olarak güvenme.
Google'ın BeyondCorp modeli bu yaklaşımın öncüsüdür. VPN'e ihtiyaç duymadan, konumdan bağımsız olarak her erişim isteği ayrı ayrı doğrulanır. Kimlik, cihaz sağlığı ve bağlam bilgisi birlikte değerlendirilerek erişim kararı verilir.
Zero Trust'ı uygulamak için: mikro-segmentasyon yapın, her API çağrısını doğrulayın, sürekli izleme (continuous monitoring) uygulayın ve anomali tespiti için SIEM çözümleri entegre edin.
KVKK ve Bulut Uyumu
Türkiye'deki Kişisel Verilerin Korunması Kanunu (KVKK), kişisel verilerin yurt dışına aktarılmasında açık rıza veya yeterli korumanın varlığını şart koşuyor. Birçok uluslararası bulut sağlayıcısı Türkiye'de veri merkezi açmış olsa da KVKK uyumu tek başına bunu gerektirmiyor.
Kritik noktalar: hangi verilerin işlendiğini belirleyin, veri işleme envanteri oluşturun, çalıştığınız bulut sağlayıcısıyla DPA (Data Processing Agreement) imzalayın ve veri aktarım mekanizmalarını belgeleyin.
Bulut güvenliğine nereden başlayacağınızı bilmiyorsanız: (1) CIS Benchmarks'ı referans alın, (2) cloud provider'ın built-in güvenlik araçlarını (Security Hub, Defender) aktif edin, (3) tüm S3/Blob/GCS bucket'larını public erişime kapalı hale getirin, (4) MFA'yı tüm hesaplara zorunlu kılın. Bu dört adım sizi ciddi risklerden korur.