Bulut Güvenliği: Paylaşılan Sorumluluk ve Kontrol Listesi

Büyük bulut sağlayıcılarının veri merkezleri, çoğu işletmenin kendi sistem odasında sağlayabileceğinden çok daha güçlü fiziksel ve altyapı güvenliğine sahiptir. Buna rağmen bulutta yaşanan güvenlik olaylarının büyük kısmı sağlayıcının altyapısındaki açıklardan değil, müşteri tarafındaki yapılandırma hatalarından, zayıf kimlik yönetiminden ve izleme eksikliğinden kaynaklanır. Bu yazıda paylaşılan sorumluluk modelini, denetimlerde en sık karşılaştığımız riskleri ve Azure, AWS veya Microsoft 365 kullanan her işletmenin uygulayabileceği somut bir kontrol listesini paylaşıyoruz.

Paylaşılan Sorumluluk Modeli: Sağlayıcı Neyi Korur, Siz Neyi?

Paylaşılan sorumluluk modeli, güvenlik görevlerinin bulut sağlayıcısı ile müşteri arasında nasıl bölündüğünü tanımlar. Temel ilke basittir: Sağlayıcı bulutun kendisinin güvenliğinden, müşteri ise buluta koyduklarının güvenliğinden sorumludur. Sınırın nereden geçtiği ise kullanılan hizmet modeline göre değişir.

• IaaS (Altyapı olarak hizmet): Sanal makine ve sanal ağ gibi hizmetlerde sağlayıcı fiziksel veri merkezini, donanımı, ağ altyapısını ve sanallaştırma katmanını korur. İşletim sistemi güncellemeleri, uygulamalar, güvenlik duvarı kuralları, erişim yetkileri ve veri tamamen müşterinin sorumluluğundadır.
• PaaS (Platform olarak hizmet): Yönetilen veritabanları, uygulama hizmetleri ve sunucusuz işlevlerde işletim sistemi ve platform yamaları sağlayıcıya geçer. Uygulama kodu, yapılandırma, ağ erişimi, kimlikler ve veri müşteride kalır.
• SaaS (Yazılım olarak hizmet): Microsoft 365 gibi hizmetlerde uygulamanın kendisini sağlayıcı işletir. Ancak kullanıcı hesapları, erişim yetkileri, paylaşım ayarları, cihaz güvenliği ve verinin kendisi yine müşterinin sorumluluğundadır.

Hizmet modeli ne olursa olsun üç alan hiçbir zaman sağlayıcıya devredilmez: veri, kimlikler ve bu kimliklerin kullandığı cihazlar. Sık karşılaştığımız bir yanılgı, Microsoft 365 verilerinin sağlayıcı tarafından her senaryoya karşı yedeklendiği varsayımıdır. Sağlayıcı hizmetin sürekliliğini ve altyapı yedekliliğini sağlar; ancak bir kullanıcının yanlışlıkla sildiği ya da fidye yazılımıyla zarar gören verinin, yerleşik saklama sürelerinin ötesinde geri getirilmesi müşterinin kendi yedekleme planına bağlıdır.

En Yaygın Bulut Güvenlik Riskleri ve Yanlış Yapılandırmalar

Bulut ortamı birkaç tıkla kaynak oluşturmayı kolaylaştırır; aynı kolaylık, tek bir yanlış ayarın veriyi internete açmasına da yol açabilir. Denetimlerde en sık karşılaştığımız bulgular şunlardır:

• Herkese açık depolama alanları: Paylaşım kolaylığı için anonim erişime açılan blob kapsayıcıları veya S3 kovaları. İçlerinde yedek, rapor veya müşteri verisi bulunabilir.
• İnternete açık yönetim portları: Uzak masaüstü (RDP) ve SSH erişiminin tüm internete açık bırakılması. Bu portlar kaba kuvvet ve parola deneme saldırılarının en sık hedefidir.
• Aşırı geniş yetkiler: Herkesin sahip veya yönetici rolüyle çalışması, en az yetki ilkesinin uygulanmaması.
• MFA olmayan yönetici hesapları: Özellikle genel yönetici ve kök hesaplarda çok faktörlü doğrulamanın bulunmaması.
• Uzun ömürlü erişim anahtarları: Kod depolarına, betiklere veya yapılandırma dosyalarına gömülmüş ve hiç değiştirilmeyen API anahtarları ve parolalar.
• Kapalı veya kısa tutulan loglar: Bir olay yaşandığında kimin ne yaptığının geriye dönük olarak izlenememesi.
• Yama eksikliği: IaaS üzerinde çalışan sanal makinelerin işletim sistemi ve uygulama güncellemelerinin sağlayıcı tarafından yapıldığının varsayılması. Bu sorumluluk müşteridedir ve düzenli bir yama sürecine bağlanmalıdır.
• Sahipsiz kaynaklar: Kimsenin sahiplenmediği eski sanal makineler ve unutulmuş test ortamları.

Bu risklerin ortak noktası, hepsinin tespit edilebilir ve düzeltilebilir olmasıdır. Bulut güvenlik duruşu yönetimi (CSPM) araçları, yapılandırmaları sürekli tarayıp bu tür sapmaları raporlar. Microsoft Defender for Cloud ve AWS Security Hub, sağlayıcıların kendi platformlarında sunduğu CSPM yeteneklerine örnektir; birden fazla bulut kullanan işletmeler üçüncü taraf çözümleri de değerlendirebilir.

Kimlik ve Erişim Yönetimi: Bulutta İlk Savunma Hattı

Şirket içi ağda güvenlik duvarı bir sınır oluşturur; bulutta ise asıl sınır kimliktir. Yönetim portalına internetin her yerinden erişilebildiği için, ele geçirilen tek bir yönetici hesabı tüm ortamın kontrolünü kaybettirebilir. Bu nedenle kimlik güvenliği bulut güvenliğinin temelidir.

1. Tüm hesaplarda MFA: Başta yöneticiler olmak üzere tüm kullanıcılar için çok faktörlü doğrulamayı zorunlu tutun ve mümkün olduğunda oltalamaya dayanıklı yöntemleri tercih edin. Ayrıntılar için MFA ve şifre güvenliği rehberimize göz atabilirsiniz.
2. En az yetki ilkesi: Rol tabanlı erişim denetimiyle (RBAC) herkese yalnızca işini yapmaya yetecek yetkiyi verin. Geniş yetkileri abonelik düzeyinde değil, kaynak grubu veya kaynak düzeyinde tanımlayın.
3. Tam zamanında yetki: Yönetici rollerini kalıcı olarak atamak yerine Microsoft Entra Privileged Identity Management gibi araçlarla ihtiyaç anında, onaylı ve süreli olarak etkinleştirin.
4. Koşullu erişim: Oturum açmayı konum, cihaz uyumluluğu ve risk seviyesine göre sınırlandırın. Bu yaklaşım Zero Trust mimarisinin de temel parçasıdır.
5. Acil durum hesapları: Kimlik altyapısında sorun yaşandığında erişimi tamamen kaybetmemek için sıkı korunan, izlenen ve düzenli test edilen acil erişim hesapları tanımlayın.
6. Uygulama kimlikleri: Uygulamaların ve betiklerin parolayla değil, yönetilen kimlikler (managed identity) veya kısa ömürlü kimlik bilgileriyle kaynaklara erişmesini sağlayın.
7. Düzenli erişim gözden geçirmesi: İşten ayrılan personelin, eski tedarikçi hesaplarının ve kullanılmayan yetkilerin periyodik olarak temizlenmesini bir rutine bağlayın.

Kimlik güvenliğinin insan tarafı da unutulmamalıdır. Oltalama e-postaları, sahte oturum açma sayfaları ve art arda MFA onayı isteyerek kullanıcıyı yoran saldırılar doğrudan bulut hesaplarını hedefler. Çalışanların bu saldırıları tanıması ve dosya paylaşım ayarlarını bilinçli kullanması için düzenli farkındalık eğitimleri planlayın; konuyu oltalama saldırıları yazımızda ayrıntılı olarak ele aldık.

Veri Şifreleme, Anahtar Yönetimi ve Ağ İzolasyonu

Büyük bulut sağlayıcıları depolanan veriyi varsayılan olarak şifreler. Ancak varsayılan şifreleme tek başına yeterli değildir; anahtarların kimin kontrolünde olduğu, verinin nasıl taşındığı ve kaynaklara hangi ağlardan erişilebildiği de belirleyicidir.

Şifreleme ve anahtar yönetimi

• Aktarım halindeki tüm veri için güncel TLS sürümlerini zorunlu kılın, şifrelenmemiş protokolleri kapatın.
• Hassas veriler için sağlayıcı yönetimli anahtar yerine müşteri yönetimli anahtar kullanımını değerlendirin. Bu anahtarlar Azure Key Vault veya AWS KMS gibi hizmetlerde tutulur ve erişimleri ayrıca denetlenir.
• Parolaları, bağlantı dizelerini ve sertifikaları uygulama koduna veya yapılandırma dosyalarına yazmak yerine anahtar kasalarında saklayın.
• Anahtar döndürme (rotation) ve yanlışlıkla silinmeye karşı koruma ayarlarını etkinleştirin.

Ağ izolasyonu

• Veritabanı ve depolama gibi hizmetleri genel internet uç noktası yerine özel uç noktalar (private endpoint) üzerinden erişilebilir yapın.
• Sanal ağları iş yüküne ve ortama göre ayırın; üretim ile test ortamlarını aynı ağda tutmayın.
• Ağ güvenlik gruplarında yalnızca gerekli port ve kaynak adreslerine izin verin, geri kalan her şeyi varsayılan olarak reddedin.
• Yönetim erişimini doğrudan internete açmak yerine Azure Bastion gibi yönetilen atlama hizmetleri, VPN veya tam zamanında erişim yöntemleriyle sağlayın.
• Şirket içi ağ ile bulut arasındaki bağlantıyı şifreli tüneller veya özel bağlantı hizmetleriyle kurun.

İzleme, Loglama ve Uyumluluk (KVKK, ISO 27001)

Önleyici kontroller ne kadar iyi olursa olsun, bir gün bir şeylerin ters gideceğini varsaymak gerekir. O gün kimin, ne zaman, neyi yaptığını gösteren kayıtlar yoksa olayı anlamak ve kapsamını belirlemek mümkün olmaz.

• Etkinlik logları: Azure Activity Log veya AWS CloudTrail gibi yönetim düzlemi loglarını tüm abonelik ve hesaplarda açın, merkezi ve değiştirilemez bir depoda saklayın.
• Oturum açma logları: Kimlik sağlayıcısındaki başarısız ve riskli oturum açma denemelerini izleyin.
• Merkezi analiz: Logları Microsoft Sentinel gibi bir SIEM çözümünde toplayarak şüpheli davranışlar için alarm kuralları tanımlayın.
• Tehdit tespiti: Sağlayıcının tehdit algılama hizmetlerini etkinleştirin ve üretilen alarmların gerçekten biri tarafından takip edildiğinden emin olun.

Loglar ve alarmlar, ancak ne yapılacağı önceden belli olduğunda işe yarar. Bulut ortamına özgü bir olay müdahale planında ele geçirilen bir hesabın nasıl devre dışı bırakılacağı, sızdırılan anahtarların nasıl döndürüleceği, etkilenen kaynakların nasıl izole edileceği, delillerin nasıl korunacağı ve sağlayıcının destek ekibiyle nasıl iletişime geçileceği yazılı olarak tanımlanmalı, plan masa başı tatbikatlarla düzenli olarak denenmelidir.

Uyumluluk tarafında, bulutta tutulan kişisel veriler de 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamındadır. Verinin hangi ülkedeki veri merkezinde tutulduğu önemlidir; yurt dışındaki bir bölgenin kullanılması, kanunun yurt dışına aktarım hükümlerinin karşılanmasını gerektirir. Bölge seçimi, veri envanteri ve teknik tedbirler bu nedenle hukuk birimiyle birlikte ele alınmalıdır; genel çerçeveyi KVKK uyum rehberimizde bulabilirsiniz. ISO 27001 hedefleyen kuruluşlar ise şunu bilmelidir: Bulut sağlayıcısının sahip olduğu belgeler yalnızca sağlayıcının sorumluluk alanını kapsar. Kendi sorumluluk alanınızdaki kontrolleri ayrıca tasarlamanız, uygulamanız ve kanıtlamanız gerekir.

Bulut Güvenliği Kontrol Listesi

Aşağıdaki soruları mevcut ortamınız için bir öz değerlendirme aracı olarak kullanabilirsiniz:

1. Tüm yönetici ve kullanıcı hesaplarında MFA zorunlu mu?
2. Kalıcı yönetici rolü atanmış hesap sayısı en aza indirildi mi?
3. Acil erişim hesapları tanımlı, korunuyor ve izleniyor mu?
4. Tüm depolama alanları anonim ve herkese açık erişime kapalı mı?
5. RDP ve SSH erişimi internete kapalı mı?
6. Veritabanlarına özel uç noktalar üzerinden mi erişiliyor?
7. Parolalar ve anahtarlar kod yerine anahtar kasasında mı saklanıyor?
8. Yönetim ve oturum açma logları açık, merkezi ve yeterince uzun süre saklanıyor mu?
9. CSPM aracı etkin mi ve bulguları düzenli olarak ele alınıyor mu?
10. Bulut verilerinin sağlayıcıdan bağımsız ve düzenli test edilen bir yedeği var mı?
11. Kişisel verilerin hangi bölgede tutulduğu belgelenmiş mi?
12. Bulut ortamına özgü bir olay müdahale planı var mı?
13. Kaynak sahipliği ve etiketleme kuralları tanımlı mı?
14. Erişim yetkileri periyodik olarak gözden geçiriliyor mu?

Bu sorulardan birine net bir şekilde evet diyemiyorsanız, o madde önceliklendirilmesi gereken bir risktir. İlk olarak kimlik, genel erişime açık kaynaklar ve loglama ile ilgili maddeleri ele almanızı öneririz; çünkü bu alanlardaki bir açık, diğer tüm kontrolleri etkisiz bırakabilir.

Ne Zaman Uzman Desteği Almalısınız?

Bulut güvenliği, ürünlerin açılıp kapatılmasından çok doğru tasarım ve sürekli takip meselesidir. Şu durumlarda dışarıdan destek almak zaman ve risk açısından avantaj sağlar:

• Buluta yeni geçtiniz veya geçiş planlıyorsunuz ve güvenlik mimarisini baştan doğru kurmak istiyorsunuz.
• Birden fazla abonelik, hesap veya sağlayıcı kullanıyor ve tutarlı bir politika uygulayamıyorsunuz.
• CSPM aracınız çok sayıda bulgu üretiyor, ancak hangisinin gerçekten kritik olduğunu ayırt edemiyorsunuz.
• Denetim, müşteri talebi veya ISO 27001 hazırlığı nedeniyle kontrollerinizi belgelemeniz gerekiyor.
• Alarmları mesai dışında takip edecek bir ekibiniz yok.

Ümraniye Bilişim olarak bulut çözümleri kapsamında mevcut ortamınızın güvenlik değerlendirmesini yapıyor, bulguları risk sırasına göre önceliklendiriyor ve düzeltmeleri ekibinizle birlikte uyguluyoruz.

Sonuç

Bulut sağlayıcısı altyapıyı korur; kimlikleri, yapılandırmaları ve veriyi korumak ise sizin görevinizdir. Paylaşılan sorumluluk modelini doğru anlayıp kimliği MFA ve en az yetki ilkesiyle sağlamlaştırdığınızda, genel erişime açık kaynakları kapattığınızda, şifreleme ve ağ izolasyonunu uyguladığınızda ve logları gerçekten izlediğinizde bulut, pek çok şirket içi ortamdan daha güvenli bir altyapıya dönüşebilir. Ortamınızın bu kontrol listesine göre nerede durduğunu birlikte görmek için ücretsiz bir ön görüşme planlayabilirsiniz.