Bulut Güvenliği (Cloud Security) Temel İlkeleri

Bulut güvenliği, veri ve altyapıyı koruyan teknoloji ve politikalar bütünüdür. Veri şifreleme, kimlik doğrulama ve sıfır güven (zero trust) mimarisi temel ilkeleri oluşturur.

Modern kurumsal altyapıların bulut ortamlarına taşınması, geleneksel çevre güvenliği (perimeter security) modellerini geçersiz kılmaktadır. Verilerin, uygulamaların ve iş yüklerinin genel, özel veya hibrit bulut platformlarına dağılması, saldırı yüzeyini genişletirken güvenlik operasyonlarının da merkezi ve dinamik bir yapıya evrilmesini zorunlu kılar. Bulut Güvenliği (Cloud Security) Temel İlkeleri, kurumsal verilerin gizliliğini (confidentiality), bütünlüğünü (integrity) ve erişilebilirliğini (availability) garanti altına almak üzere tasarlanan stratejik standartları kapsar. Bu rehber; teknik karar vericiler ve işletme sahipleri için ortak sorumluluk modellerini, kimlik yönetimini, uçtan uca şifreleme standartlarını ve mevzuat uyumluluğunu teknik gereksinimleriyle ele almaktadır.

Bulut Güvenliği Nedir? Kurumsal Altyapılarda Güvenlik Mimarisi

Bulut güvenliği; genel bulut (public cloud), özel bulut (private cloud) ve hibrit bulut (hybrid cloud) ortamlarında barındırılan sanal sunucuları, veri tabanlarını, ağ altyapılarını, kapsayıcıları (containers) ve mikro hizmetleri dış ve iç tehditlere karşı korumayı amaçlayan kurallar, kontroller, prosedürler ve teknolojiler bütünüdür. Bulut bilişimde sınır hatları fiziksel ağ kabloları veya şirket içi güvenlik duvarları (firewall) ile çizilemez; güvenlik sınırı doğrudan kimlik ve veri katmanına indirgenmiştir.

Kurumsal organizasyonların bulut altyapılarını benimserken karşılaştığı en temel zorluk, şirket içi (on-premise) sistemlerdeki statik güvenlik kontrollerinin dinamik, hızla ölçeklenen mikro hizmet mimarilerinde yetersiz kalmasıdır. AWS, Microsoft Azure ve Google Cloud Platform (GCP) gibi bulut hizmeti sağlayıcıları (CSP), altyapının fiziksel ve sanallaştırma katmanını korurken, bu platformlar üzerinde koşan yazılımların, yapılandırmaların ve hassas verilerin güvenliği doğrudan kurumun sorumluluğundadır.

Güvenli bir bulut mimarisi kurmak, yalnızca üçüncü taraf güvenlik yazılımlarını devreye almaktan ibaret değildir. Altyapı kodlama süreçlerinden (IaC - Infrastructure as Code) sürekli entegrasyon ve dağıtım (CI/CD) hatlarına kadar her aşamada güvenlik ilkelerinin işletilmesi gerekir. Bu yaklaşım, güvenlik açıklarının henüz geliştirme aşamasında tespit edilmesini sağlayan "Shift-Left" felsefesiyle birleştiğinde operasyonel riskleri minimize eder.

Geleneksel Veri Merkezi Güvenliği ile Bulut Güvenliği Arasındaki Mimari Farklar

Geleneksel veri merkezi güvenliği, "kale ve hendek" (castle-and-moat) yaklaşımına dayanır. Bu modelde, şirket ağı güvenli bir kale olarak kabul edilir; çevresine yerleştirilen fiziksel güvenlik duvarları, saldırı tespit sistemleri (IDS/IPS) ve VPN tünelleri hendek görevi görür. Ağın içine girmeyi başaran herhangi bir kullanıcı veya cihaz, varsayılan olarak güvenilir kabul edilir.

Bulut mimarisinde ise fiziksel bir çevre bulunmaz. Kaynaklar coğrafi olarak dağıtık veri merkezlerinde çalışır, çalışanlar farklı konumlardan erişim sağlar ve uygulamalar API'ler aracılığıyla birbiriyle haberleşir. Bu durum, çevre güvenliği modelini tamamen işlevsiz hale getirir. Bulut güvenliği mimarisi, ağ sınırlarına değil; her bir iş yükünün, kullanıcının ve veri paketinin bağımsız olarak doğrulandığı mikro segmentasyon ve kimlik odaklı güvenlik ilkelerine dayanır.

İş Sürekliliği, Veri Mahremiyeti ve Maliyet Optimizasyonu Boyutu

Bulut güvenliği standartlarının eksiksiz uygulanması, doğrudan iş sürekliliği (business continuity) ve felaket kurtarma (disaster recovery) hedefleriyle bağlantılıdır. Dağıtık mimarilerde yedeklilik (redundancy), yüksek erişilebilirlik (high availability) bölgeleri üzerinden yapılandırılır. Ancak güvenli olmayan bir replikasyon mekanizması, bir veri merkezindeki güvenlik ihlalinin saniyeler içinde tüm yedekleme havuzlarına yayılmasına neden olabilir.

Veri mahremiyeti açısından bakıldığında, uluslararası pazarlarda faaliyet gösteren işletmelerin verinin saklandığı coğrafi konumu (data residency) ve egemenliğini (data sovereignty) denetlemesi yasal bir gerekliliktir. Verinin yanlış yapılandırılmış depolama alanlarında (örneğin herkese açık Amazon S3 Bucket veya Azure Blob Storage) barındırılması, KVKK ve GDPR kapsamında milyonlarca liralık idari para cezalarıyla sonuçlanabilir.

Finansal açıdan bakıldığında, bulutta güvenlik açıkları yalnızca veri kaybına değil, doğrudan altyapı maliyetlerinin kontrolsüz artışına yol açar. Kötü niyetli aktörlerin yetkisiz erişim sağlayarak altyapıda kripto para madenciliği (cryptojacking) yapması, işletmelere saatler içinde on binlerce dolarlık beklenmedik faturalar çıkarabilmektedir. Güvenlik kontrollerinin erken aşamada optimize edilmesi, bu tür maliyet risklerini ortadan kaldırır.

Ortak Sorumluluk Modeli (Shared Responsibility Model) ve Sınırların Belirlenmesi

Bulut güvenliğinin temel yapı taşı Ortak Sorumluluk Modeli'dir (Shared Responsibility Model). Bu model, bulut ortamındaki güvenlik görevlerinin bulut hizmet sağlayıcısı (CSP) ile hizmeti alan kurum arasında nasıl paylaşıldığını kesin çizgilerle tanımlar. Bulut sağlayıcıları "bulutun güvenliğinden" (Security OF the Cloud) sorumlu iken, müşteriler "bulutun içindeki güvenlikten" (Security IN the Cloud) sorumludur.

Gartner tarafından yayımlanan bulut güvenliği raporları, gerçekleşen bulut güvenlik ihlallerinin %99'unun bulut sağlayıcısının açıklarından değil, müşteri tarafındaki yanlış yapılandırmalar ve yetkilendirme hatalarından kaynaklanacağını ortaya koymaktadır. Bu istatistik, kurumların ortak sorumluluk matrisini doğru anlamasının ne denli kritik olduğunu açıkça göstermektedir.

+-------------------------------------------------------------------------+
|                    ORTAK SORUMLULUK MODELİ MATRİSİ                      |
+----------------------+-------------------+-------------------+----------+
| Katman / Bileşen     | IaaS (Örn: EC2)   | PaaS (Örn: App Engine)| SaaS (Örn: M365) |
+----------------------+-------------------+-------------------+----------+
| Veri & Sınıflandırma | Müşteri           | Müşteri           | Müşteri  |
| Kimlik ve Erişim IAM | Müşteri           | Müşteri           | Müşteri  |
| Uygulama Mantığı     | Müşteri           | Müşteri           | Sağlayıcı|
| İşletim Sistemi (OS) | Müşteri           | Sağlayıcı         | Sağlayıcı|
| Ağ Yapılandırması    | Müşteri / Sağlayıcı| Sağlayıcı        | Sağlayıcı|
| Sanallaştırma        | Sağlayıcı         | Sağlayıcı         | Sağlayıcı|
| Fiziksel Donanım/Ağ  | Sağlayıcı         | Sağlayıcı         | Sağlayıcı|
| Fiziksel Veri Merkezi| Sağlayıcı         | Sağlayıcı         | Sağlayıcı|
+----------------------+-------------------+-------------------+----------+

Hizmet Modellerine Göre Görev Dağılımı: IaaS, PaaS ve SaaS Karşılaştırması

Bulut mimarileri Altyapı Hizmeti (IaaS), Platform Hizmeti (PaaS) ve Yazılım Hizmeti (SaaS) olmak üzere üç temel modelde sunulur. Seçilen her model, sorumluluk çizgisini yukarı veya aşağı taşır:

• IaaS (Infrastructure as a Service): AWS EC2, Azure VM veya Google Compute Engine gibi modellerde kontrolün en büyük kısmı müşteridedir. Sağlayıcı fiziksel sunucuları, depolama disklerini ve hipervizör katmanını güvenceye alır. Müşteri ise işletim sisteminin kurulması, güvenlik yamalarının (patching) yapılması, ağ güvenlik gruplarının (security groups) yapılandırılması, veritabanı güvenliği ve kimlik yönetiminden tamamen sorumludur.

• PaaS (Platform as a Service): AWS Elastic Beanstalk, Azure App Service veya Google Cloud Run gibi platformlarda sorumluluk dengesi sağlayıcıya kayar. Sağlayıcı işletim sistemini, çalışma zamanı ortamını (runtime) ve donanımı yönetir, yamaları otomatik uygular. Müşterinin sorumluluğu yalnızca kaynak kodun güvenliği, uygulama düzeyi yapılandırmalar ve veri erişim yetkileriyle sınırlıdır.

• SaaS (Software as a Service): Microsoft 365, Salesforce veya Google Workspace gibi yazılımlarda altyapı, işletim sistemi ve uygulama kodunun güvenliği tamamen sağlayıcıya aittir. Ancak bu modelde dahi verinin sınıflandırılması, kullanıcı kimlik doğrulama politikaları (MFA zorunluluğu) ve hangi verinin kiminle paylaşıldığının denetimi müşterinin sorumluluğundadır.

Bulut Sağlayıcısının Yükümlülükleri ve Müşteri Tarafındaki Sorumluluk Alanları

Bulut servis sağlayıcıları, dünya genelindeki veri merkezlerini ISO/IEC 27001, SOC 1/2/3 ve PCI-DSS gibi küresel güvenlik standartlarına göre sertifikalandırır. Sağlayıcının yükümlülükleri; biyometrik erişim kontrolleriyle donatılmış fiziksel binaları, kesintisiz güç kaynaklarını, donanım arızalarına karşı yedekleme ünitelerini ve hipervizör düzeyindeki izolasyon protokollerini kapsar.

Müşteri tarafındaki sorumluluk alanları ise operasyonel kararlara odaklanır. Bir kurum, bulut üzerinde barındırdığı sanal sunucunun SSH (Port 22) veya RDP (Port 3389) portunu internete herkese açık (0.0.0.0/0) biçimde açarsa veya kök kullanıcı (root account) hesaplarında çok faktörlü kimlik doğrulamayı (MFA) devre dışı bırakırsa, oluşacak veri ihlalinden (data breach) sağlayıcı sorumlu tutulamaz.

Sorumluluk Sınırlarında Yapılan Kritik Hatalar

Kurumsal karar vericilerin en sık düştüğü yanılgı, buluta geçildiğinde yedekleme ve güvenlik operasyonlarının otomatik olarak "sağlayıcı tarafından halledildiği" varsayımıdır. Örneğin, bir fidye yazılımı (ransomware) saldırısında veritabanı şifrelendiğinde, müşteri düzenli anlık görüntü (snapshot) ve felaket kurtarma planlaması yapmadıysa veri geri döndürülemez.

Bir diğer yaygın hata, SaaS uygulamalarında paylaşılan belgelerin erişim izinlerinin denetlenmemesidir. Şirket içi çalışanların herkese açık bağlantı linkleriyle hassas finansal tabloları dış ağlarla paylaşması, SaaS sağlayıcısının güvenlik açığı değil, kurumun veri kaybı önleme (DLP - Data Loss Prevention) politikalarındaki eksikliğidir.

Bulut Güvenliğini Oluşturan 3 Temel İlke

Kurumsal bir bulut güvenlik stratejisi; kimlik yönetimi, kriptografik veri koruması ve dinamik doğrulama protokolleri üzerine inşa edilmelidir. Bu üç ilke bağımsız katmanlar olarak değil, birbirini sürekli besleyen ve doğrulayan entegre bir savunma hattı olarak çalışır.

1. Kimlik ve Erişim Yönetimi (IAM) ve Doğrulama Protokolleri

Bulut altyapılarında kimlik, yeni güvenlik çevresidir (Identity is the new perimeter). Kimlik ve Erişim Yönetimi (IAM - Identity and Access Management), hangi kullanıcının, servisin veya uygulamanın hangi kaynaklara, ne zaman ve hangi koşullarda erişebileceğini belirleyen merkezi denetim mekanizmasıdır.

Etkili bir IAM mimarisinin uygulanmasında aşağıdaki teknik prensipler zorunludur:

• En Az Yetki İlkesi (Principle of Least Privilege - PoLP): Kullanıcılara ve rollere yalnızca görevlerini yerine getirebilecekleri minimum yetki tanımlanmalıdır. Bir geliştiriciye tüm AWS hesabını kapsayan AdministratorAccess vermek yerine, sadece ilgili S3 bucket'ına yazma izni sağlayan ayrıntılı (granular) IAM politikaları yazılmalıdır.

• Çok Faktörlü Kimlik Doğrulama (MFA): Yönetici hesapları, konsol erişimleri ve API anahtarları için donanımsal (FIDO2/WebAuthn güvenlik anahtarları) veya zamana dayalı tek kullanımlık parola (TOTP) tabanlı MFA zorunlu tutulmalıdır. SMS tabanlı doğrulamalar SIM takası (SIM swapping) riskleri nedeniyle kurumsal kritik hesaplarda tercih edilmemelidir.

• Rol Tabanlı Erişim Denetimi (RBAC) ve Öznitelik Tabanlı Erişim Denetimi (ABAC): Yetkiler bireysel kullanıcılara değil, kurumsal rollere veya bağlamsal özniteliklere (cihaz konumu, IP adresi, zaman aralığı) göre atanmalıdır.

• Geçici Kimlik Bilgileri (Temporary Credentials): Kod tabanları veya sanal sunucular içine statik erişim anahtarları (Access Key / Secret Key) gömülmemelidir. Bunun yerine AWS IAM Roles, Azure Managed Identities veya GCP Service Account Impersonation mekanizmaları kullanılmalıdır.

2. Kesintisiz Veri Şifreleme (Data Encryption)

Veri, bulut ortamındaki en değerli kurumsal varlıktır. Veri sızıntılarına ve yetkisiz erişimlere karşı koruma sağlamak için şifreleme mekanizmaları tüm veri yaşam döngüsüne uygulanmalıdır:

• Beklemedeki Veri Güvenliği (Data at Rest): Veritabanlarında, blok depolama birimlerinde (AWS EBS, Azure Managed Disks) ve nesne depolama alanlarında (S3, Blob) saklanan tüm veriler endüstri standardı olan AES-256 (Advanced Encryption Standard 256-bit) ile şifrelenmelidir. Şifreleme anahtarları müşteri tarafından yönetilen donanımsal güvenlik modüllerinde (HSM) veya bulut anahtar yönetim servislerinde (AWS KMS, Azure Key Vault, Google Cloud KMS) saklanmalı; düzenli anahtar rotasyonu (key rotation) otomatikleştirilmelidir.

• Aktarımdaki Veri Güvenliği (Data in Transit): Kullanıcı ile bulut sunucuları arasındaki ve mikro hizmetlerin kendi aralarındaki (inter-service) tüm ağ trafiği TLS 1.3 (Transport Layer Security) protokolü ile şifrelenmelidir. Zayıf şifreleme paketleri (cipher suites) sunucu düzeyinde devre dışı bırakılmalıdır.

• Kullanım Sırasındaki Veri Güvenliği (Data in Use - Gizli Bilişim): Veriler bellek (RAM) üzerinde işlenirken de korunmalıdır. Intel SGX ve AMD SEV teknolojilerini kullanan Gizli Bilişim (Confidential Computing) altyapıları, sanallaştırma katmanı veya sistem yöneticisi dahi bellekteki ham veriyi okuyamayacak şekilde donanım tabanlı izole yürütme ortamları (TEE - Trusted Execution Environments) sağlar.

3. Sıfır Güven (Zero Trust) Mimarisi

NIST SP 800-207 standardı ile çerçevesi çizilen Sıfır Güven Mimarisi (Zero Trust Architecture), "asla güvenme, her zaman doğrula" (never trust, always verify) prensibine dayanır. Bu mimaride ağın içinden veya dışından gelen her istek eşit derecede şüpheli kabul edilir.

Sıfır güven yaklaşımının operasyonel bileşenleri şunlardır:

1. Açıkça Doğrula (Verify Explicitly): Kullanıcı kimliği, konumu, cihaz sağlığı, hizmet türü ve veri sınıflandırması her erişim talebinde anlık olarak doğrulanır.

2. Mikro Segmentasyon (Micro-Segmentation): Bulut iş yükleri, sanal özel ağlar (VPC) içinde küçük, izole segmentlere bölünür. Bir web sunucusu ele geçirilse bile saldırganın aynı ağdaki veritabanı sunucusuna yatay geçiş (lateral movement) yapması güvenlik grupları ve ağ erişim kontrol listeleri (NACL) ile engellenir.

3. İhlal Varsayımı (Assume Breach): Sistemin her an saldırı altında olduğu ve bir katmanın aşıldığı varsayılarak hareket edilir. Bu doğrultuda tüm oturumlar şifrelenir, erişim süreleri sınırlandırılır ve anormallikler sürekli olarak davranışsal analiz araçlarıyla izlenir.

Kurumsal Bulut Altyapılarını Bekleyen Başlıca Güvenlik Riskleri

Bulut altyapıları, doğası gereği yüksek otomasyon ve geniş internet erişilebilirliği sunduğundan, saldırganların hedefleme yöntemleri de geleneksel yöntemlerden farklılaşmıştır. Güvenlik liderlerinin karşılaştığı tehditler donanım açıklarından ziyade yazılım, API ve mimari seviyesindeki konfigürasyon zafiyetlerinde yoğunlaşmaktadır.

Yanlış Yapılandırmalar (Misconfigurations) ve Yetkisiz Erişim Zafiyetleri

Bulut Güvenliği İttifakı (Cloud Security Alliance - CSA) tarafından yayımlanan "Top Threats to Cloud Computing" raporlarında yanlış yapılandırmalar, buluttaki bir numaralı güvenlik riski olarak listelenmektedir. Hızlı geliştirme döngüleri ve karmaşık altyapı kodları, küçük bir parametre hatasının devasa güvenlik açıklarına dönüşmesine yol açmaktadır.

En sık karşılaşılan yanlış yapılandırma türleri şunlardır:

• Herkese Açık Depolama Alanları: Hassas müşteri verilerini, veritabanı yedeklerini veya log dosyalarını içeren S3 bucket'larının yanlış erişim politikaları nedeniyle internete açık bırakılması.

• Geniş Güvenlik Grubu (Security Group) Kuralları: Yönetim portlarının (SSH, RDP, veritabanı portları olan 3306, 5432) tüm internete (0.0.0.0/0) açık tanımlanması.

• Aşırı Yetkili Hizmet Hesapları: Uygulamaların kullandığı servis hesaplarına @@CODE0@@ veya @@CODE1@@ rollerinin verilmesi sonucu, uygulamadaki bir kod enjeksiyonu zafiyetinin tüm bulut ortamının ele geçirilmesine yol açması.

Güvensiz API Tasarımları, Entegrasyon Açıkları ve Üçüncü Taraf Riskleri

Bulut ortamlarında sistemlerin birbiriyle iletişimi API'ler (Uygulama Programlama Arayüzleri) üzerinden yürütülür. Kimlik doğrulaması yetersiz olan, hız sınırlaması (rate limiting) bulunmayan veya hassas verileri yanıt gövdelerinde maskelemeden döndüren API'ler doğrudan saldırı vektörüdür.

OWASP API Security Top 10 listesinde yer alan BOLA (Broken Object Level Authorization) zafiyetleri, saldırganların yalnızca parametrelerdeki ID değerlerini değiştirerek diğer kullanıcılara ait verilere yetkisiz erişim sağlamasına imkan tanır. Ayrıca, bulut ortamlarına entegre edilen üçüncü taraf SaaS araçlarının aşırı izinlerle yetkilendirilmesi, tedarik zinciri saldırılarına (supply chain attacks) zemin hazırlar.

Gelişmiş Kalıcı Tehditler (APT), Fidye Yazılımları (Ransomware) ve Veri Sızıntıları

Siber saldırganlar bulut sistemlerine sızdıktan sonra geleneksel zararlı yazılımlar yerine sistemin kendi araçlarını kullanarak iz bırakmadan ilerlemeyi (Living off the Cloud) hedefler. Gelişmiş kalıcı tehdit (APT) grupları, elde ettikleri düşük yetkili bir kullanıcı kimliği üzerinden IAM yetki yükseltme (privilege escalation) açıklarını kullanarak yönetici seviyesine ulaşır.

Fidye yazılımları bulut ortamında farklı bir biçim almıştır. Saldırganlar sunucuları şifrelemek yerine, doğrudan nesne depolama alanlarındaki verileri dışarı sızdırmakta (data exfiltration), ardından kaynak veriyi silip şifreli bir kopyasını bırakarak fidye talep etmektedir. Eğer depolama alanlarında versiyonlama (versioning) ve nesne kilitleme (Object Lock / WORM - Write Once, Read Many) etkinleştirilmemişse, yedeklerin kurtarılması imkansız hale gelir.

Güvenli Bulut Geçişi (Cloud Migration) ve Sürekli Uyumluluk Yönetimi

Buluta geçiş süreci (Cloud Migration), güvenlik kontrollerinin sistem mimarisine entegre edildiği kritik bir dönüm noktasıdır. Geçişin başarılı ve güvenli olması, statik denetimler yerine sürekli çalışan otomatik izleme ve uyumluluk mekanizmalarının kurulmasına bağlıdır.

Bulut Güvenlik Duruşu Yönetimi (CSPM) ve SIEM/SOAR Entegrasyonu

Bulut ortamlarının dinamik yapısı nedeniyle manuel güvenlik denetimleri yetersiz kalır. Bu noktada özelleşmiş bulut güvenliği araçları devreye girer:

• CSPM (Cloud Security Posture Management): Bulut hesaplarını sürekli tarayarak CIS Benchmarks, NIST ve PCI-DSS standartlarına göre yanlış yapılandırmaları tespit eden ve otomatik düzeltme (auto-remediation) aksiyonları alan araçlardır.

• CWPP (Cloud Workload Protection Platform): Sanal makineler, kapsayıcılar (Kubernetes, Docker) ve sunucusuz fonksiyonlar düzeyinde çalışma zamanı (runtime) tehdit koruması sağlar.

• CIEM (Cloud Infrastructure Entitlement Management): IAM izinlerini analiz ederek kullanılmayan veya aşırı tanımlanmış yetkileri tespit eder ve en az yetki ilkesini dinamik olarak uygular.

• SIEM ve SOAR Entegrasyonu: Bulut günlükleri (AWS CloudTrail, Azure Monitor, VPC Flow Logs), merkezi bir Güvenlik Bilgileri ve Olay Yönetimi (SIEM) platformuna aktarılmalıdır. Güvenlik Düzenleme, Otomasyon ve Yanıt (SOAR) sistemleri sayesinde, şüpheli bir IP'den gelen yetkilendirme denemesi algılandığında ilgili IAM kullanıcısı insan müdahalesine gerek kalmadan saniyeler içinde askıya alınabilir.

Yasal Mevzuata Uyum: KVKK, GDPR ve ISO/IEC 27017 Standartları

Bulut üzerinde işlenen verilerin yasal mevzuatlara uygunluğu, kurumsal sürdürülebilirlik açısından hayati önem taşır. Türkiye'de Kişisel Verilerin Korunması Kanunu (KVKK) ve Avrupa Birliği Genel Veri Koruma Tüzüğü (GDPR), veri sorumlularına teknik ve idari tedbirleri alma zorunluluğu getirmektedir.

Uyumluluk yönetiminde dikkat edilmesi gereken temel standartlar:

• Veri Yerelliği ve Transferi: KVKK kapsamında kişisel verilerin yurt dışındaki bulut sunucularına aktarımı açık rıza veya Kurul tarafından onaylanan taahhütname/yeterlilik kararlarına tabidir. Hibrit bulut mimarileri kullanılarak hassas verilerin yerel veri merkezlerinde, işleme yüklerinin ise genel bulutta tutulması stratejik bir çözümdür.

• ISO/IEC 27017 ve ISO/IEC 27018: ISO/IEC 27001 standardının bulut güvenliği (27017) ve bulutta kişisel verilerin korunması (27018) için özelleştirilmiş ek kontrolleridir. Kurumlar, bulut sağlayıcılarının bu sertifikasyonlara sahip olduğunu doğrulamalıdır.

Güvenli Bulut Mimarisi İçin Operasyonel Kontrol Adımları

Kurumsal bulut operasyonlarında riskleri minimize etmek ve denetimlere hazır olmak için teknik ekiplerin belirli bir kontrol çerçevesini düzenli işletmesi gerekir. Aşağıdaki kontrol listesi, kurumsal düzeyde uygulanması gereken asgari adımları sıralamaktadır.