Bulut Güvenliği: AWS, Azure ve GCP'de Zafiyet Yönetimi

Kısaca

• Bulut ortamlarında güvenlik sorumluluğu sağlayıcı ile müşteri arasında paylaşılır; paylaşılan sorumluluk modelini anlamak, doğru güvenlik stratejisinin temelidir.
• Bulut zafiyetlerinin %65-70'i yanlış yapılandırma (misconfiguration) kaynaklıdır; geleneksel zafiyet taraması tek başına yeterli değildir.
• Multi-cloud ortamları, her sağlayıcının farklı güvenlik araçları ve terminolojisi nedeniyle zafiyet yönetimini karmaşıklaştırır; merkezi bir platform gereklidir.
• SİTEY'in 17 tarayıcı entegrasyonu ve AI destekli önceliklendirme özelliği, AWS, Azure ve GCP ortamlarından gelen bulguları tek panelde birleştirir.
• Bulut güvenliğinde sürekli uyumluluk (continuous compliance) yaklaşımı, KVKK, GDPR ve PCI DSS gereksinimlerinin proaktif olarak karşılanmasını sağlar.
• Serverless ve konteyner mimarilerinin yaygınlaşması, zafiyet yönetimi kapsamının uygulama katmanından orkestrasyon katmanına kadar genişlemesini gerektirir.
• Bulut sızma testleri, geleneksel testlerden farklı metodoloji ve araçlar gerektirir; IAM yetki yükseltme ve metadata service istismarı gibi bulut-spesifik saldırı vektörleri test edilmelidir.
• IAM güvenliği, bulut ortamlarındaki ihlallerin %80'inden fazlasının kaynağıdır; en az yetki ilkesi, MFA ve JIT erişim temel savunma kontrolleridir.

Bu rehberde AWS, Azure ve GCP güvenlik servislerini, multi-cloud zafiyet yönetimi stratejilerini ve SİTEY'in bulut entegrasyon yeteneklerini detaylı olarak inceliyoruz.

Bulut Güvenliği Neden Farklı?

Bulut bilişim, organizasyonların altyapıyı yönetme biçimini kökten değiştirmiştir. Geleneksel on-premise veri merkezlerinde güvenlik ekipleri tüm altyapıyı - ağ, sunucu, depolama, uygulama - kontrol eder. Bulut ortamlarında ise altyapının bir kısmı sağlayıcıya aittir ve müşterinin doğrudan kontrolü dışındadır. Bu paradigma değişikliği, siber güvenlik stratejilerinin yeniden tasarlanmasını zorunlu kılar.

Bulutun dinamik yapısı, güvenlik yönetimini daha karmaşık hale getirir. Geleneksel ortamlarda sunucular haftalarca veya aylarca değişmeden çalışırken, bulut ortamlarında kaynaklar dakikalar içinde oluşturulup yok edilebilir. Auto-scaling grupları, serverless fonksiyonlar ve container orchestrator'lar sürekli olarak yeni kaynaklar yaratır. Bu efemeral (geçici) yapı, anlık fotoğraf niteliğindeki güvenlik taramalarını yetersiz kılar; sürekli görünürlük ve tarama gerektirir.

Bulut güvenliğinin bir diğer ayırt edici özelliği API-first yaklaşımıdır. Bulut sağlayıcılarında her işlem - sunucu oluşturma, ağ yapılandırma, kullanıcı yönetimi - API üzerinden gerçekleştirilir. Bu API'lerin yanlış yapılandırılması veya kötüye kullanılması, geleneksel altyapıda karşılaşılmayan saldırı vektörleri oluşturur. Ayrıca bulut ortamlarında paylaşılan altyapı (multi-tenancy) nedeniyle yanal hareket riskleri farklı boyutlarda ortaya çıkar.

Son olarak bulut ortamlarında zafiyet yönetimi kapsamı genişler. Yalnızca yazılım zafiyetleri değil, IAM politikaları, ağ yapılandırmaları, depolama izinleri, logging ayarları ve şifreleme yapılandırmaları da zafiyet kapsamına girer. Bu geniş yüzeyin etkili bir şekilde yönetilmesi, bulut-spesifik araçlar ve süreçler gerektirir.

Bulut güvenliğinin bir diğer önemli boyutu compliance (uyumluluk) gereksinimleridir. KVKK, PCI DSS, ISO 27001, SOC 2 ve HIPAA gibi düzenlemeler, bulut ortamlarında veri güvenliği, erişim kontrolü ve denetim izlerinin sağlanmasını zorunlu kılar. Her bulut sağlayıcısı, bu uyumluluk çerçevelerine yönelik araçlar ve sertifikasyonlar sunar; ancak uyumluluk sorumluluğu büyük ölçüde müşteridedir. SİTEY'in uyumluluk raporlama modülü, farklı çerçevelerin gereksinimlerini otomatik olarak kontrol eder ve denetim için gerekli kanıtları üretir.

Paylaşılan Sorumluluk Modeli

Paylaşılan sorumluluk modeli, bulut güvenliğinin temel kavramlarından biridir. Bu modele göre bulut sağlayıcısı "bulutun güvenliğinden" (security of the cloud), müşteri ise "buluttaki güvenlikten" (security in the cloud) sorumludur. Ancak sorumluluk sınırları, kullanılan hizmet modeline (IaaS, PaaS, SaaS) göre değişir.

IaaS (Infrastructure as a Service) modelinde - örneğin EC2, Azure VM, Compute Engine - sağlayıcı fiziksel altyapıyı, hipervisor'ı ve ağ katmanını güvence altına alır. Müşteri ise işletim sistemi yamaları, uygulama güvenliği, ağ yapılandırması, kimlik yönetimi ve veri şifrelemesinden sorumludur. Zafiyet yönetimi açısından bu, en geniş sorumluluk alanını temsil eder.

PaaS (Platform as a Service) modelinde - örneğin AWS Lambda, Azure App Service, Cloud Functions - sağlayıcı işletim sistemi ve runtime ortamının güvenliğini de üstlenir. Müşteri, uygulama kodu, yapılandırma ve veri güvenliğinden sorumlu kalır. Zafiyet taraması burada uygulama seviyesine ve yapılandırma kontrollerine odaklanır.

SaaS (Software as a Service) modelinde müşterinin sorumluluğu en daraltılmış halidir: erişim yönetimi, veri sınıflandırması ve yapılandırma ayarları. Ancak bu, SaaS uygulamalarının güvenli olduğu anlamına gelmez; yanlış yapılandırılmış SaaS uygulamaları (örneğin herkese açık SharePoint siteleri) veri sızıntılarına yol açabilir.

Her üç büyük bulut sağlayıcısının - AWS, Azure, GCP - paylaşılan sorumluluk modeli, kavramsal olarak benzer olmakla birlikte terminoloji ve uygulama detaylarında farklılıklar gösterir. Organizasyonların, kullandıkları her hizmet için sorumluluk sınırlarını net olarak belirlemesi ve buna göre zafiyet yönetimi kapsamını tanımlaması gerekir.

Paylaşılan sorumluluk modelinin en sık yanlış anlaşılan yönü, güvenlik ve uyumluluk sorumluluğunun müşteriye ait olduğudur. Bulut sağlayıcısının SOC 2 veya ISO 27001 sertifikasına sahip olması, müşterinin de otomatik olarak uyumlu olduğu anlamına gelmez. Müşteri, kendi sorumluluk alanındaki kontrolleri bağımsız olarak uygulaması ve denetlemesi gerekir. SCI tipi denetimler (SOC 2 Type II), şeffaf raporlama gerektirir ve müşterinin "buluta güveniyoruz" demesi yeterli değildir.

Pratik bir öneri olarak, bulut altyapınıza geçmeden veya yeni bir hizmet kullanmaya başlamadan önce, sorumluluk matrisi (responsibility matrix) oluşturun. Bu matris; ağ güvenliği, veri şifreleme, yedekleme, yama yönetimi, erişim kontrolü ve loglama gibi temel güvenlik alanlarının hangilerinden sağlayıcının, hangilerinden müşterinin sorumlu olduğunu açıkça belgelendirir.

Paylaşılan sorumluluk modelinin etkin uygulanması için bulut güvenlik mimarı rolünün tanımlanması da son derece önemlidir. Bu rol, sağlayıcı tarafındaki güvenlik servislerini yapılandırmak, müşteri tarafındaki kontrolleri tasarlamak ve iki taraf arasındaki boşlukları kapatmakla sorumludur. Organizasyonların en az bir kişiyi bu rolle görevlendirmesi veya danışmanlık hizmeti alması şiddetle tavsiye edilir.

Paylaşılan sorumluluk modelinde dikkat edilmesi gereken bir diğer konu da supply chain (tedarik zinciri) güvenliğidir. Bulut sağlayıcıları üzerinde çalışan üçüncü parti çözümler (SaaS uygulamaları, marketplace AMI'lar, container imajları) ek güvenlik riskleri getirir. Marketplace'ten alınan bir AMI veya container imajının güvenilirliği, müşterinin sorumluluğundadır. Bu nedenle üçüncü parti kaynakların güvenlik taramasından geçirilmesi ve düzenli olarak güncellenmesi gerekir.

AWS Güvenlik Servisleri ve Zafiyet Taraması

Amazon Web Services (AWS), en geniş pazar payına sahip bulut sağlayıcısı olarak kapsamlı bir güvenlik servis ekosistemi sunar. AWS'ın güvenlik servisleri, tespit, koruma, yanıt ve uyumluluk kategorilerinde organize edilmiştir. AWS, güvenlik konusunda “güvenlik 0. önceliktir” (security is job zero) felsefesini benimser ve müşterilerine geniş bir güvenlik araç yelpazesi sunar.

Amazon Inspector, EC2 instance'ları, container imajları ve Lambda fonksiyonlarında otomatik zafiyet taraması yapan yönetilen bir servistir. Inspector, CVE veritabanını kullanarak bilinen yazılım zafiyetlerini tespit eder ve bulguları CVSS puanıyla puanlar. Inspector'ın en önemli avantajı, sürekli tarama yapabilmesidir; yalnızca ilk kez değil, her yeni CVE yayınlandığında veya kaynak yapılandırması değiştiğinde yeniden tarar.

Amazon GuardDuty, VPC Flow Logs, CloudTrail ve DNS loglarını analiz ederek gerçek zamanlı tehdit algılama sağlar. Kripto madenciliği, brute force, veri sızıntısı ve olağandışı API çağrıları gibi şüpheli aktiviteleri makine öğrenmesi ile tespit eder. GuardDuty bulguları, zafiyet yönetimi bağlamında tehdit istihbaratı olarak değerlidir.

AWS Security Hub, çoklu güvenlik servislerinden gelen bulguları merkezi bir panelde birleştirir. GuardDuty (tehdit algılama), Macie (veri keşfi), Config (yapılandırma uyumluluğu) ve Inspector bulgularını tek bir görünümde sunar. CIS AWS Foundations Benchmark ve PCI DSS gibi uyumluluk çerçevelerine karşı otomatik kontrol yapabilir.

AWS Config, AWS kaynaklarının yapılandırma geçmişini kaydeder ve tanımlanan kurallara uyumluluğu otomatik kontrol eder. Örneğin, "tüm S3 bucket'ları şifrelenmiş olmalı" veya "güvenlik grupları 0.0.0.0/0 gelen erişime izin vermemeli" gibi kurallar tanımlanabilir. Uyumsuzluk tespit edildiğinde otomatik düzeltme (remediation) eylemi tetiklenebilir.

AWS ortamında sızma testi yaparken dikkat edilmesi gerekenler: AWS, kendi kaynaklarınız üzerinde belirli test türlerine izin verir ancak bazı testler için önceden bildirim gereklidir. DDoS simülasyonu, DNS zone walking ve port flooding gibi testler AWS politikalarına aykırıdır. SİTEY platformu, AWS tarayıcılarıyla (Inspector, Security Hub) doğrudan entegre çalışarak bulguları merkezi zafiyet yönetimi paneline aktarır.

AWS ortamında etkili bir güvenlik stratejisi için AWS Organizations ile multi-account mimarisi kullanılması önerilir. Her iş yükü, ortam (geliştirme, staging, üretim) ve güvenlik fonksiyonu için ayrı hesaplar oluşturularak izolasyon sağlanır. Service Control Policies (SCP) ile organizasyon genelinde güvenlik kuralları zorunlu tutulur. Bu mimari yaklaşım, hem güvenliği hem de zafiyet yönetimi kapsamını netleştirir.

Ek olarak, AWS CloudTrail ve VPC Flow Logs gibi loglama servislerinin tüm hesaplarda etkinleştirilmesi, olay müdahale ve adli analiz için vazgeçilmezdir. Log verileri, merkezi bir güvenlik hesabında toplanarak SIEM ile entegre edilmelidir.

Azure Güvenlik Merkezi ve Defender

Microsoft Azure, Microsoft Defender for Cloud (eski adıyla Azure Security Center) ile kapsamlı bir bulut güvenlik yönetimi platformu sunar. Defender for Cloud, hem Azure hem de multi-cloud (AWS, GCP) ve hibrit (on-premise) ortamları tek bir panelden yönetebilir.

Defender for Cloud'un temel bileşenleri:

• Cloud Security Posture Management (CSPM): Bulut kaynaklarının güvenlik yapılandırmasını sürekli değerlendirir ve Secure Score ile güvenlik duruşunu puanlar. Azure Security Benchmark, CIS ve NIST çerçevelerine göre kontroller yapar.
• Cloud Workload Protection (CWP): VM'ler, container'lar, SQL veritabanları, depolama hesapları ve App Service uygulamaları için gelişmiş koruma ve zafiyet taraması sağlar.
• Defender for Servers: Qualys tabanlı entegre zafiyet tarayıcısı ile sunucu ve VM'lerdeki yazılım zafiyetlerini otomatik olarak tarar.
• Defender for Containers: Container imajlarını ve Kubernetes kümelerini tarar, runtime anomalilerini tespit eder.

Azure'nun Azure Policy servisi, organizasyonun bulut kaynaklarına uygulanacak güvenlik politikalarını tanımlama ve zorlama imkânı sağlar. Örneğin, "tüm depolama hesapları yalnızca HTTPS üzerinden erişilebilir olmalı" veya "Premium tier olmayan Key Vault kaynakları oluşturulamaz" gibi politikalar tanımlanabilir. Bu politikalar, yanlış yapılandırmaları oluşmadan önce engeller.

Azure ortamında zafiyet yönetimi stratejisi oluştururken, Defender for Cloud'un ürettiği bulguları SİTEY ile birleştirmek önerilir. SİTEY, Azure Defender bulgularını diğer tarayıcı ve sızma testi sonuçlarıyla tek platformda toplayarak bütünsel bir risk görünümü sağlar. Secure Score'un düşük olduğu alanlar, zafiyet önceliklendirmesinde bağlam bilgisi olarak kullanılır.

Azure'un Microsoft Sentinel (bulut-native SIEM) entegrasyonu ile Defender for Cloud bulguları, güvenlik olaylarıyla korelasyonda değerlendirilebilir. Bu sayede sadece zafiyet değil, aktif tehditler de görünür hale gelir. Azure hibrit ortamlarda on-premise sunucuları da Azure Arc ile Defender for Cloud kapsamına alarak tutarlı güvenlik yönetimi sağlanabilir.

GCP Security Command Center

Google Cloud Platform (GCP), Security Command Center (SCC) ile merkezi güvenlik yönetimi sunar. SCC, GCP kaynaklarındaki güvenlik bulgularını, zafiyetleri ve tehditleri tek bir panelde gösterir.

SCC'nin temel yetenekleri:

• Security Health Analytics: GCP kaynaklarının güvenlik yapılandırmasını CIS Benchmark ve GCP en iyi uygulamalarına göre otomatik olarak değerlendirir. Açık güvenlik duvarı kuralları, şifrelenmemiş diskler, herkese açık Cloud Storage bucket'ları gibi yanlış yapılandırmaları tespit eder.
• Web Security Scanner: App Engine, Compute Engine ve GKE üzerinde çalışan web uygulamalarını otomatik olarak tarayan entegre DAST aracıdır. XSS, mixed content, güvensiz kitaplıklar ve outdated server yazılımı gibi zafiyetleri keşfeder.
• Event Threat Detection: Bulut günlüklerini gerçek zamanlı olarak analiz ederek şüpheli aktiviteleri (brute force, kripto madenciliği, veri sızıntısı) tespit eder.
• Container Threat Detection: GKE kümelerinde çalışan container'larda kötü amaçlı script çalıştırma, ters shell açma ve yetki yükseltme gibi tehditleri algılar.

GCP'nin Organization Policy Service'i, Azure Policy'ye benzer şekilde organizasyon genelinde güvenlik kısıtlamaları tanımlamaya olanak tanır. Belirli bölgelerde kaynak oluşturulmasını engelleme, IAM politikalarını zorlama ve API erişimini sınırlandırma gibi kontroller yapılabilir.

GCP ortamında sızma testi yapılırken, Google'ın kabul edilebilir kullanım politikalarına dikkat edilmelidir. Google, müşterilerin kendi GCP kaynaklarını test etmesine izin verir ancak Google'ın altyapısına zarar verecek testler (DDoS vb.) yasaktır. SİTEY, GCP SCC bulgularını API aracılığıyla çekerek diğer platformlardan gelen verilerle birleştirme ve bağlamsal zafiyet yönetimi imkânı sunar.

GCP'nin güvenlik avantajlarından biri, BeyondCorp zero-trust modelini kendi altyapısında yıllardır uygulaması ve bunu müşterilere de BeyondCorp Enterprise olarak sunmasıdır. Bu model, güvenliğin ağ perimetresine değil, kimliğe ve cihaz güvenliğine dayandığı bir yaklaşımdır. GCP'nin bu alandaki deneyimi, zero-trust mimarisi uygulamak isteyen organizasyonlar için önemli bir referans noktasıdır.

GCP'nin Chronicle güvenlik operasyonları platformu, petabayt ölçeğinde güvenlik verisini depolayabilir ve analiz edebilir. Chronicle'ın Google ölçeğindeki tehdit istihbaratı (VirusTotal, Mandiant) entegrasyonu, bulut güvenlik olaylarının daha hızlı ve doğru bir şekilde değerlendirilmesini sağlar.

GCP'nin bir diğer önemli güvenlik özelliği, Binary Authorization servisidir. Bu servis, yalnızca imzalı ve doğrulanmış container imajlarının GKE kümelerinde çalıştırılmasını zorunlu kılar. Yazılım tedarik zinciri saldırılarına karşı güçlü bir koruma katmanı sağlayan Binary Authorization, DevSecOps pipeline'ındaki imaj imzalama adımıyla birlikte kullanıldığında, üretim ortamına yalnızca güvenlik taramalarından geçmiş imajların dağıtılmasını garanti eder.

Multi-Cloud Ortamlarda Zafiyet Yönetimi

Bugün birçok kuruluş birden fazla bulut sağlayıcısını aynı anda kullanmaktadır. Gartner'ın 2025 verilerine göre, büyük kuruluşların %75'inden fazlası multi-cloud stratejisi benimsemiştir. Bu durum genellikle bilinçli bir tercih olabileceği gibi, farklı departmanların veya satın alınan şirketlerin farklı bulut sağlayıcılarını kullanmasından da kaynaklanabilir. Her sağlayıcının farklı güvenlik araçları, API'leri, terminolojisi ve yapılandırma modelleri, zafiyet yönetimini önemli ölçüde karmaşıklaştırır.

Multi-cloud yaklaşımı güvenlik açısından hem avantajlar hem de zorluklar getirir. Tek bir sağlayıcıya bağımlılığın azalması ve failover imkânı avantaj iken, güvenlik yönetiminin karmaşıklaşması, tutarsız politikalar ve artan insan kaynağı ihtiyacı önemli zorluklardır.

Multi-cloud ortamlarında karşılaşılan temel güvenlik zorlukları:

• Parçalı görünürlük: Her sağlayıcının kendi güvenlik paneli vardır ancak ortamlar arası bütünsel bir risk görünümü oluşturmak zordur. AWS Security Hub, Azure Defender ve GCP SCC farklı formatlar kullanır.
• Tutarsız politikalar: Aynı güvenlik politikası farklı sağlayıcılarda farklı şekillerde uygulanır. Bir sağlayıcıda sıkı olan bir kontrol, diğerinde gevşek kalabilir.
• Kimlik federasyonu: Çoklu bulut ortamlarında kimlik yönetimi karmaşıklaşır. SAML/OIDC federasyonu yanlış yapılandırıldığında, bir sağlayıcıdaki ele geçirilmiş kimlik bilgileri diğer sağlayıcılara yayılabilir.
• Yetenek açığı: Her sağlayıcının kendine özgü güvenlik uzmanlığı gerektirmesi, teknik yetenek ihtiyacını artırır.

Bu zorlukların üstesinden gelmek için Cloud Security Posture Management (CSPM) ve Cloud-Native Application Protection Platform (CNAPP) çözümleri kullanılır. Bu araçlar, çoklu bulut ortamlarını tek panelden yöneterek tutarlı güvenlik politikaları uygulamayı mümkün kılar.

SİTEY, multi-cloud zafiyet yönetiminde merkezi bir entegrasyon noktası olarak çalışır. AWS Inspector, Azure Defender ve GCP SCC gibi yerel güvenlik araçlarının yanı sıra Prisma Cloud, Wiz ve Orca gibi üçüncü parti CSPM araçlarından gelen bulguları da tek platformda toplar. AI destekli tekilleştirme ve önceliklendirme, farklı sağlayıcılardaki aynı zafiyet türlerini birleştirerek toplam risk görünümü sağlar.

Kimlik ve Erişim Yönetimi (IAM) Zafiyetleri

Kimlik ve Erişim Yönetimi (IAM), bulut güvenliğinin en kritik katmanıdır. Bulut ortamlarındaki güvenlik ihlallerinin %80'inden fazlası, IAM yapılandırma hatalarından veya kimlik bilgilerinin ele geçirilmesinden kaynaklanmaktadır. IAM zafiyetleri, geleneksel yazılım zafiyetlerinden farklı bir yaklaşımla değerlendirilmeli ve yönetilmelidir.

Bulut ortamlarında en yaygın IAM zafiyetleri:

• Aşırı yetkili roller (over-privileged): "Hızlı çözüm" amacıyla verilen geniş yetkilerin (Admin, *:*) kalıcı hale gelmesi. En az yetki (least privilege) ilkesinin ihlali, saldırganların ele geçirdikleri bir hesapla tüm altyapıya erişmesini sağlar.
• Uzun süreli erişim anahtarları: Programatik erişim anahtarlarının (AWS access key, Azure service principal secret) oluşturulup rotate edilmemesi. Sızan bir anahtar, aylarca fark edilmeden kötüye kullanılabilir.
• MFA eksikliği: Özellikle yönetici hesaplarında çok faktörlü kimlik doğrulamanın etkinleştirilmemesi. Credential stuffing ve phishing saldırılarına karşı MFA, en etkili savunma katmanıdır.
• Cross-account erişim hataları: Farklı AWS hesapları veya Azure subscription'lar arasındaki güven ilişkilerinin yanlış yapılandırılması, yetkisiz erişimlere kapı açar.
• Servis hesabı anahtar sızıntısı: CI/CD pipeline'larında veya uygulama kod deposunda bırakılan servis hesabı anahtarları.

IAM zafiyetlerinin yönetimi, geleneksel CVE tabanlı zafiyet yönetiminden farklıdır. IAM risk değerlendirmesinde CVSS puanı yerine erişim kapsamı, etkilenen kaynaklar ve istismar edilebilirlik dikkate alınır. Örneğin, tüm S3 bucket'larına okuma/yazma erişimi olan bir servis hesabı anahtarının sızması, tek bir EC2 instance'daki yazılım zafiyetinden çok daha yüksek risk oluşturabilir.

SİTEY, IAM güvenlik bulgularını yazılım zafiyet bulgularıyla aynı platformda yöneterek bütünsel bir risk değerlendirmesi sağlar. AI destekli önceliklendirme motoru, bir IAM zafiyetinin hangi kritik kaynaklara erişim sağladığını analiz ederek iş etkisi bazlı sıralama yapar.

IAM güvenliğinde sürekli izleme ve denetim vazgeçilmezdir. Yetkiler zamanla genişleme eğilimindedir (privilege creep); proje kapsamında verilen geçici yetkiler kalıcı hale gelir, ayrılan çalışanların hesapları aktif kalır, test amaçlı oluşturulan geniş yetkili roller unutulur. AWS Access Analyzer, Azure AD Access Reviews ve GCP IAM Recommender gibi araçlar, kullanılmayan yetkilerin tespit edilmesine yardımcı olur.

IAM güvenliğinde uygulanması gereken temel ilkeler: just-in-time (JIT) erişim ile yetkilerin yalnızca gerektiğinde ve sınırlı süreliğine verilmesi, privileged access workstation (PAW) ile yönetim işlemlerinin izole cihazlardan yapılması ve break-glass prosedürleri ile acil durumlar için güvenli yetki yükseltme mekanizmaları oluşturulması.

Bulut IAM güvenliğinde federasyon ve SSO (Single Sign-On) entegrasyonu da kritik öneme sahiptir. Yerel bulut kullanıcı hesapları yerine kurumsal kimlik sağlayıcısı (IdP) üzerinden SAML 2.0 veya OIDC federasyonu kurulmalıdır. Bu sayede merkezi kimlik yönetimi, şifre politikaları ve MFA zorunluluğu tüm bulut hesaplarına tutarlı bir şekilde uygulanır. Azure AD (Entra ID), Okta ve Google Workspace gibi IdP çözümleri tüm büyük bulut sağlayıcılarıyla entegre çalışır.

Bulut IAM zafiyetlerinin tespitinde attack path analysis (saldırı yolu analizi) modern bir yaklaşımdır. Bireysel IAM bulgularına bakmak yerine, bir saldırganın mevcut yetkilerle hangi yolu takip ederek kritik kaynaklara ulaşabileceğini analiz eden bu yaklaşım, gerçek güvenlik riskini çok daha doğru şekilde değerlendirir. Wiz, Orca ve Prisma Cloud gibi CNAPP çözümleri bu yeteneği sunarken, SİTEY bu araçların bulgularını kendi zafiyet yönetimi iş akışına entegre eder.

Yanlış Yapılandırma (Misconfiguration) Riskleri

Bulut güvenliği ihlallerinin büyük çoğunluğu yazılım zafiyetlerinden değil, yanlış yapılandırmalardan kaynaklanır. Cloud Security Alliance (CSA) raporlarına göre, bulut veri ihlallerinin %65-70'i misconfiguration kaynaklıdır. Bu durum, klasik zafiyet taraması yaklaşımının bulut ortamlarında tek başına yetersiz kaldığını gösterir.

Bulut ortamlarında karşılaşılan en yaygın yanlış yapılandırmalar:

• Açık depolama: Herkese açık S3 bucket'ları, Azure Blob Storage container'ları veya GCS bucket'ları. Milyonlarca hassas kaydın sızdığı pek çok büyük veri ihlali, yanlış yapılandırılmış depolama izinlerinden kaynaklanmaktadır.
• Açık güvenlik grupları: 0.0.0.0/0 gelen kuralıyla tüm port ve protokollere izin veren güvenlik grupları. Özellikle SSH (22), RDP (3389) ve veritabanı portlarının (3306, 5432) internete açılması ciddi risk oluşturur.
• Şifreleme eksikliği: Aktarılan ve durağan verinin şifrelenmemesi. EBS volume'ları, RDS instance'ları ve S3 bucket'larında varsayılan şifrelemenin etkinleştirilmemesi.
• Günlük kaydı eksikliği: CloudTrail, VPC Flow Logs, Azure Activity Logs veya GCP Audit Logs'un etkinleştirilmemesi. Loglama olmadan güvenlik olaylarının tespiti ve soruşturması imkânsızlaşır.
• Varsayılan ayarlar: Bulut kaynaklarının varsayılan (default) güvenlik ayarlarıyla bırakılması. Birçok bulut servisi, varsayılan olarak "açık" yapılandırmayla oluşturulur.

Yanlış yapılandırmaların tespit edilmesi için Cloud Security Posture Management (CSPM) araçları kullanılır. Bu araçlar, bulut API'lerini sürekli sorgulayarak kaynakların tanımlanmış güvenlik politikalarına uyumunu kontrol eder. CIS Benchmark, NIST 800-53 ve PCI DSS gibi çerçevelere göre otomatik değerlendirme yapar.

Sızma testi sırasında yapılandırma zafiyetleri sıklıkla istismar edilir. Bir pentester, açık bir S3 bucket'ı üzerinden hassas verilere erişebilir veya aşırı yetkili bir IAM rolü üzerinden tüm altyapıyı ele geçirebilir. SİTEY, yapılandırma bulgularını yazılım zafiyetleriyle entegre ederek gerçek saldırı yollarını (attack paths) görselleştirir.

Yapılandırma hatalarının önlenmesinde preventive controls (önleyici kontroller) büyük önem taşır. Her üç büyük sağlayıcı da kaynak oluşturma anında güvenlik kısıtlamaları uygulayabilecek politika araçları sunar (AWS SCP + Config Rules, Azure Policy, GCP Organization Policy). Bu kontroller, yanlış yapılandırılmış bir kaynağın hiç oluşturulamamasını sağlayarak sorunun kaynağında çözülmesine yardımcı olur.

Infrastructure as Code (IaC) yaklaşımıyla bulut kaynakları Terraform veya CloudFormation gibi araçlarla kod olarak tanımlanır ve yapılandırma hataları kod incelemesi aşamasında tespit edilebilir. Checkov, tfsec ve KICS gibi IaC tarama araçları, CI/CD pipeline'ına entegre edilerek yapılandırma güvenliğini otomatik olarak kontrol eder.

Yapılandırma hatalarının izlenmesinde drift detection (sapma tespiti) mekanizmalarının kullanılması da son derece önemlidir. IaC ile tanımlanmış olsa bile, operasyon ekiplerinin konsoldan yaptığı manuel değişiklikler zamanla yapılandırmanın koddan sapmasına yol açar. AWS Config Rules, Azure Change Tracking ve Terraform Cloud'un drift detection özellikleri bu tür sapmaları tespit eder ve uyarı üretir.

Bulut yanlış yapılandırmalarının ölçeklenme riski de göz ardı edilmemelidir. On-premise ortamda bir sunucunun yanlış yapılandırılması yalnızca o sunucuyu etkilerken, bulut ortamında bir IaC şablonundaki hata yüzlerce kaynağa otomatik olarak yayılabilir. Bu nedenle yapılandırma değişikliklerinin merkezi bir değişiklik yönetimi (change management) sürecinden geçmesi ve güvenlik incelemesine tabi tutulması kritik önemdedir.

Veri Güvenliği ve Şifreleme

Bulut ortamlarında veri güvenliği, hem yasal uyumluluk hem de iş sürekliliği açısından kritik öneme sahiptir. KVKK, GDPR ve PCI DSS gibi düzenlemeler, hassas verilerin bulut ortamlarında nasıl depolanması, işlenmesi ve aktarılması gerektiğine dair katı kurallar belirler.

Bulutta veri güvenliği stratejisinin üç temel bileşeni:

• Durağan veri şifrelemesi (encryption at rest): Depolama servislerinde (S3, EBS, Azure Disk, Cloud Storage), veritabanlarında ve yedeklerde verinin şifrelenmesi. Her üç büyük sağlayıcı da sunucu taraflı şifreleme (SSE) ve müşteri tarafından yönetilen anahtarlarla (CMK) şifreleme seçenekleri sunar.
• Aktarılan veri şifrelemesi (encryption in transit): Verinin ağ üzerinden aktarılırken TLS/SSL ile şifrelenmesi. Bulut servisleri arasındaki iç trafik de dahil olmak üzere tüm veri akışlarında şifreleme zorunlu tutulmalıdır.
• Kullanımdaki veri koruması (encryption in use): Confidential Computing teknolojileriyle verinin işleme sırasında bile korunması. AWS Nitro Enclaves, Azure Confidential Computing ve GCP Confidential VMs bu alanda çözümler sunar.

Anahtar yönetimi (Key Management), veri şifreleme stratejisinin en kritik bileşenidir. AWS KMS, Azure Key Vault ve GCP Cloud KMS gibi yönetilen anahtar servisleri kullanılmalıdır. Anahtarların düzenli rotasyonu, erişim politikalarının en az yetki ilkesine göre düzenlenmesi ve anahtar kullanım loglarının izlenmesi gerekir.

SİTEY'in zafiyet yönetimi platformu, veri güvenliği yapılandırmalarını da tarama kapsamına dahil eder. Şifrelenmemiş depolama, zayıf anahtar politikaları ve açık veri erişim izinleri gibi bulgular, yazılım zafiyetleriyle aynı önceliklendirme ve takip sürecinden geçer.

Bulut veri güvenliği stratejisinde sıklıkla göz ardı edilen bir konu da veri sınıflandırmasıdır. Hangi verilerin hassas (kişisel veri, finansal bilgi, ticari sır) olduğu belirlenmeden, etkili bir şifreleme ve erişim kontrolü politikası oluşturulamaz. AWS Macie, Azure Purview ve GCP DLP gibi servisler, bulut depolama alanlarındaki hassas verileri otomatik olarak keşfeder ve sınıflandırır. SİTEY, veri sınıflandırma bulgularını zafiyet verileriyle birleştirerek hassas veriye erişim sağlayan zafiyetleri daha yüksek önceliğe taşır.

Veri güvenliğinde bir diğer kritik nokta veri yaşam döngüsü yönetimidir. Artık gerekli olmayan verilerin güvenli bir şekilde silinmesi veya arşivlenmesi, hem güvenlik risklerini azaltır hem de KVKK ve GDPR gereksinimlerini karşılar. Bulut sağlayıcılarının sunduğu lifecycle policy ve retention konfigürasyonları, bu sürecin otomatikleştirilmesine yardımcı olur.

Veri yedekleme stratejisi de veri güvenliğinin vazgeçilmez bir parçasıdır. 3-2-1 yedekleme kuralı (3 kopya, 2 farklı medya türü, 1 offsite) bulut ortamına uyarlanmalıdır: en az iki farklı bulut bölgesinde yedek tutulmalı ve yedeklerin immutable (değiştirilemez) olarak saklanması sağlanmalıdır. AWS S3 Object Lock, Azure Immutable Blob Storage ve GCP Bucket Lock özellikleri, yedeklerin ransomware saldırıları dahil herhangi bir manipülasyona karşı korunmasını sağlar. Yedeklerden geri yükleme testleri düzenli olarak yapılmalı ve geri yükleme süresi (RTO) ile veri kaybı toleransı (RPO) hedefleri doğrulanmalıdır.

Bulut ortamında log yönetimi ve güvenlik izleme, veri güvenliğinin operasyonel boyutunu oluşturur. CloudTrail, Azure Activity Log ve GCP Audit Logs verilerinin merkezi bir SIEM (Security Information and Event Management) çözümüne aktarılması, güvenlik olaylarının hızlı tespiti ve müdahalesi için zorunludur. SİTEY, bu log verilerini zafiyet bulguları ile ilişkilendirerek, aktif olarak istismar edilen zafiyetlerin derhal önceliklendirilmesini sağlar.

Bulut Ortamında Sızma Testi

Bulut ortamlarında sızma testi, geleneksel on-premise testlerden önemli farklılıklar gösterir. Paylaşılan altyapı modeli nedeniyle test kapsamı ve yöntemleri, bulut sağlayıcısının politikalarıyla sınırlandırılır. Ayrıca bulut-spesifik saldırı vektörleri (metadata service istismarı, IAM yetki yükseltme, cross-account erişim vb.) geleneksel pentest metodolojilerinde yeterince kapsanmaz.

Bulut sızma testinin kapsaması gereken alanlar:

• IAM ve yetki yükseltme: Mevcut erişim yetkileriyle hangi kaynaklara ulaşılabildiğinin ve yetkilerin nasıl yükseltilebileceğinin test edilmesi. PACU (AWS), ScoutSuite ve CloudGoat gibi araçlar kullanılır.
• Metadata service istismarı: SSRF zafiyetleri üzerinden instance metadata service'ine erişim ve IAM credential çalma senaryolarının test edilmesi (IMDSv2 zorunluluğu kontrol edilmelidir).
• Cross-service saldırılar: Bir servisteki zafiyetin diğer servislere etkisinin değerlendirilmesi. Örneğin, bir Lambda fonksiyonundaki RCE ile DynamoDB verilerine erişim.
• Yapılandırma denetimi: Güvenlik grupları, IAM politikaları, depolama izinleri ve ağ yapılandırmalarının manuel olarak incelenmesi.
• Veri sızıntısı testleri: Hassas verilerin bulut ortamından dışarı çıkarılabilirliğinin test edilmesi (DLP kontrolleri, ağ çıkış kuralları).

Bulut sızma testi sonuçları, SİTEY platformuna aktarılarak otomatik zafiyet yönetimi sürecine dahil edilir. Pentest bulgularının CSPM ve otomatik tarama sonuçlarıyla korelasyonu, risk değerlendirmesini güçlendirir ve düzeltme önceliklerini netleştirir.

Bulut sızma testi planlanırken, test kapsamının yalnızca altyapıyla sınırlı kalmaması gerekir. Bulut ortamındaki serverless fonksiyonlar (Lambda, Azure Functions, Cloud Functions), API Gateway'ler, message queue'lar ve event-driven mimariler de test kapsamına dahil edilmelidir. Bu modern bulut bileşenlerinin güvenlik testleri, geleneksel pentest araçlarıyla yapılamayabilir ve bulut-spesifik test metodolojileri gerektirir.

Ayrıca bulut sızma testleri, düzenli olarak tekrarlanmalıdır. Bulut ortamları sürekli değiştiğinden, altı ay önceki test sonuçları güncelliğini kaybetmiş olabilir. En az yılda iki kez, tercihen çeyreklik periyotlarla kapsamlı sızma testi yapılması önerilir. SİTEY, bu testlerin bulgularını zaman serileri halinde takip ederek güvenlik duruşundaki değişimi görselleştirir.

SİTEY ile Bulut Zafiyet Yönetimi

Bulut güvenliği ekosisteminin karmaşıklığı - çoklu sağlayıcılar, onlarca güvenlik aracı, binlerce bulgu - merkezi bir zafiyet yönetimi platformunu zorunlu kılar. SİTEY, bulut ortamlarındaki güvenlik bulgularını yönetmek için özel olarak tasarlanmış özellikler sunar.

SİTEY'in bulut güvenliği yetenekleri:

• Multi-cloud entegrasyon: AWS Security Hub, Azure Defender, GCP SCC ve üçüncü parti CSPM araçlarından (Prisma Cloud, Wiz, Orca) gelen bulguları tek panelde birleştirir.
• AI destekli tekilleştirme: Farklı araçların ve farklı sağlayıcıların aynı zafiyeti farklı şekilde raporlaması sorununu çözer. Bulgu sayısını tipik olarak %30-60 oranında azaltır.
• Bağlam bazlı önceliklendirme: Zafiyetin bulunduğu kaynağın iş kritikliği, internet maruziyeti, veri hassasiyeti ve EPSS skoru gibi faktörleri birleştirerek gerçek risk sıralaması yapar.
• Otomatik atama: Bulut kaynağının sahibine veya ilgili ekibe otomatik ticket atanması. Jira, ServiceNow ve Slack entegrasyonları.
• SLA takibi ve raporlama: Kritik, yüksek, orta ve düşük seviyeli bulgular için farklı SLA'lar tanımlanır. SLA ihlali yaklaştığında otomatik eskalasyon yapılır.
• Uyumluluk raporları: CIS Benchmark, SOC 2, PCI DSS ve KVKK uyumluluk durumunu gösteren hazır rapor şablonları.

17 farklı tarayıcı entegrasyonu ile SİTEY, bulut güvenlik araçlarının çıktılarını standart bir modele dönüştürür. Bu sayede ekiplerin farklı araçların farklı konsollarında çalışması yerine, tek bir platform üzerinden tüm bulguları yönetmesi mümkün olur.

Sık Yapılan Hatalar

Bulut güvenliği yolculuğunda organizasyonların sıklıkla düştüğü tuzaklar:

• On-premise güvenliği buluta taşımak: Geleneksel güvenlik duvarı ve IDS/IPS yaklaşımlarını bulut ortamına birebir taşımaya çalışmak. Bulut, cloud-native güvenlik araçları ve yaklaşımları gerektirir.
• Paylaşılan sorumluluk modelini yanlış anlamak: "Bulut sağlayıcısı her şeyi güvence altına alır" varsayımı. Müşteri sorumluluğundaki alanlar (yapılandırma, IAM, veri) ihmal edilir.
• Yapılandırma driftini izlememek: Bulut kaynakları sürekli değişir. İlk yapılandırma güvenli olsa bile, sonraki değişiklikler güvenliği bozabilir. Sürekli izleme gereklidir.
• Logging'i ihmal etmek: Maliyet tasarrufu gerekçesiyle bulut günlük kayıtlarını devre dışı bırakmak. Olay müdahalesinde log olmadan soruşturma yapılamaz.
• Root/admin hesaplarını günlük kullanım için kullanmak: Yönetici hesaplarını MFA olmadan, günlük operasyonlar için kullanmak. Bu hesapların ele geçirilmesi tüm altyapıyı riske atar.
• Çoklu araçtan gelen bulguları birleştirmemek: Her güvenlik aracının kendi konsolunda ayrı ayrı çalışmak, bütünsel risk görünürlüğünü engeller ve alarm yorgunluğuna yol açar.
• Geliştirici erişimlerini denetlememek: Geliştirme ve test ortamlarındaki geniş erişim yetkilerinin üretim ortamına taşınması.
• Eski servis anahtarlarını temizlememek: Proje bitiminde veya çalışan ayrılışında oluşturulan API anahtarlarının ve servis hesaplarının aktif bırakılması. Düzenli hesap ve anahtar denetimi yapın.
• Tek bölgede çalışmak: Tüm kaynakları tek bir bulut bölgesinde tutarak felaketten kurtarma (disaster recovery) kapasitesini sınırlandırmak. En azından yedeklerin farklı bölgelerde tutulması önerilir.
• Bulut maliyet optimizasyonunun güvenlik etkisini göz ardı etmek: Maliyet tasarrufu amacıyla güvenlik servislerini devre dışı bırakmak veya daha düşük katmanlara geçmek, uzun vadede çok daha yüksek maliyetli güvenlik olaylarına yol açabilir.
• Test ortamlarını güvence altına almamak: Geliştirme ve test ortamlarının üretim verileri içermesine rağmen düşük güvenlik kontrolleriyle çalıştırılması. Birçok büyük veri ihlali, güvenliği zayıf test ortamları üzerinden gerçekleştirilmiştir.
• Incident response planını bulut ortamına uyarlamamak: On-premise olay müdahale planını bulut ortamına doğrudan uygulamaya çalışmak. Bulut ortamındaki olay müdahale, sağlayıcıyla koordinasyonu, bulut-spesifik forensic teknikleri ve farklı veri erişim yöntemlerini gerektirir.

Bu hataların her biri, gerçek dünyada yaşanan büyük güvenlik olaylarının kök nedenlerini yansıtmaktadır. Capital One (2019, yanlış yapılandırılmış WAF), Uber (2022, hardcoded credentials in code) ve Twitch (%100 kaynak kodu sızıntısı, misconfigured server) gibi vakalar, bulut güvenliği hatalarının ne kadar yıkıcı sonuçlar doğurabileceğini göstermiştir.