Hızlı Cevap

Bulut güvenlik denetimi ve sızma testi; AWS, Azure ve Microsoft 365 ortamlarındaki yanlış yapılandırmaları, aşırı geniş IAM yetkilerini ve açık depolama kovalarını yetki dahilinde tespit eder. Geleneksel pentestten farkı, ağ portları yerine kimlik ve yönetim düzlemine (control plane) odaklanmasıdır. CSPM ve CIS Benchmark ile sürekli denetim önerilir.

Bulut Güvenliği Neden Geleneksel Güvenlikten Farklıdır?

Kurumlar iş yüklerini AWS, Microsoft Azure ve Microsoft 365 ortamlarına taşıdıkça, saldırı yüzeyi de kökten değişti. Klasik bir veri merkezinde güvenlik ekibi, fiziksel sunucuları, ağ anahtarlarını ve güvenlik duvarlarını kontrol ederdi. Bulutta ise her şey bir API çağrısıyla yönetilen, kod olarak tanımlanan ve dakikalar içinde oluşturulup yok edilen soyut kaynaklara dönüştü.

Bu dönüşüm yeni bir gerçeği beraberinde getirdi: Bulutta en kritik saldırı yüzeyi artık ağ portları değil, kimliklerdir. Bir saldırgan için açık bir 3389 portu kadar değerli olan şey, aşırı yetkilendirilmiş bir IAM rolü, sızdırılmış bir erişim anahtarı veya yanlış yapılandırılmış bir OAuth uygulamasıdır. Bu nedenle bulut güvenlik denetimi ve bulut sızma testi, geleneksel ağ pentestinden tamamen farklı bir disiplin haline geldi.

DSET olarak 2003'ten bu yana edindiğimiz adli bilişim ve ofansif güvenlik tecrübesini, bulut ortamlarının bu kendine özgü dinamiklerine taşıdık. Bu makalede bulut güvenlik denetiminin temel kavramlarını, sağlayıcı kurallarını, en sık görülen yanlış yapılandırmaları ve modern test araçlarını derinlemesine ele alıyoruz.

Paylaşılan Sorumluluk Modeli: Neyi Kim Korur?

Bulut güvenliğinin kalbinde paylaşılan sorumluluk modeli (shared responsibility model) yatar. Bu modeli anlamadan yapılan her denetim eksik kalır.

Özetle sağlayıcı (AWS, Microsoft) bulutun kendisinin güvenliğinden sorumludur: veri merkezleri, fiziksel donanım, hipervizör katmanı ve temel ağ altyapısı. Müşteri ise bulutun içindekilerin güvenliğinden sorumludur: veriler, kimlik ve erişim yönetimi, ağ yapılandırması, işletim sistemi yamaları ve uygulama güvenliği.

Sorumluluk dağılımı hizmet modeline göre değişir:

  • IaaS (Altyapı Hizmeti, örn. EC2 / Azure VM): Müşteri işletim sistemi, ağ ve uygulama katmanından sorumludur. Saldırı yüzeyi en geniş olan modeldir.
  • PaaS (Platform Hizmeti, örn. App Service, RDS): İşletim sistemi yönetimi sağlayıcıya geçer; müşteri uygulama ve veri konfigürasyonundan sorumludur.
  • SaaS (Yazılım Hizmeti, örn. Microsoft 365): Sağlayıcı uygulamayı yönetir; müşteri kullanıcı kimliklerinden, erişim politikalarından ve veri paylaşım ayarlarından sorumludur.

Microsoft 365 gibi SaaS ortamlarında çoğu kurum "sağlayıcı zaten her şeyi koruyor" yanılgısına düşer. Oysa koşullu erişim politikaları, OAuth uygulama izinleri ve paylaşım ayarları tamamen müşterinin sorumluluğundadır ve en sık ihlal edilen alanlardır.

Bulut Sızma Testi ile Geleneksel Pentest Arasındaki Farklar

Geleneksel bir sızma testi genellikle bir IP aralığına veya web uygulamasına karşı port tarama, servis keşfi ve zafiyet sömürüsü adımlarını izler. Bulut sızma testi ise mimari olarak farklı bir yaklaşım gerektirir.

Boyut Geleneksel Pentest Bulut Pentest
Birincil hedef Ağ portları, servisler Kimlikler, IAM rolleri, API'ler
Keşif Nmap, port tarama Yapılandırma denetimi, izin haritalama
Ayrıcalık yükseltme Yerel exploit, kernel IAM policy zincirleri, rol üstlenme
Yetki kaynağı Müşteri Müşteri + sağlayıcı kuralları
Yönetim düzlemi Yok Control plane sömürüsü kritik
Veri sızması Ağ üzerinden S3/Blob, snapshot, API

Bulut testinde "saldırgan zaten içeride bir kimlik ele geçirdi" varsayımı çok yaygındır. Asıl soru şudur: Bir saldırgan düşük yetkili bir kimlikle başlarsa, control plane üzerinden ne kadar ileri gidebilir? Bu nedenle bulut pentest, kimlik temelli saldırı yollarını (attack path) haritalamaya odaklanır.

Yönetim Düzlemi (Control Plane) vs Veri Düzlemi (Data Plane)

Bu ayrım bulut güvenliğinin en kritik kavramlarından biridir.

  • Yönetim düzlemi (control plane): Kaynakları oluşturan, yapılandıran ve yöneten API katmanıdır. Örneğin bir S3 kovasının erişim politikasını değiştirmek, yeni bir IAM kullanıcısı oluşturmak veya bir VM'in disk anlık görüntüsünü almak control plane işlemleridir.
  • Veri düzlemi (data plane): Asıl veriye erişilen katmandır. Bir S3 kovasındaki dosyaları okumak veya bir veritabanına sorgu atmak data plane işlemidir.

Kritik nokta şudur: Bir saldırgan veri düzlemine doğrudan erişemese bile, control plane üzerindeki yetkilerle bir veritabanı anlık görüntüsünü kendi hesabına kopyalayabilir veya bir kovanın politikasını gevşeterek veriyi dışarı açabilir. DSET denetimlerinde control plane saldırı yollarını her zaman ayrı bir başlık olarak ele alırız.

Sağlayıcı Kuralları ve İzinler: Yetki Dahilinde Test

Bulut sızma testinin geleneksel testten en önemli farklarından biri, sağlayıcının da bir paydaş olmasıdır. Paylaşılan altyapı üzerinde izinsiz test yapmak hem sözleşme ihlali hem de yasal sorun yaratır.

AWS Penetrasyon Testi Politikası

AWS, müşterilerin kendi hesaplarındaki belirli servisler için önceden onay almadan sızma testi yapmasına izin verir. EC2, RDS, CloudFront, API Gateway, Lambda gibi servisler izinli listededir. Ancak DNS zehirleme, DoS/DDoS simülasyonu ve port flooding gibi testler ayrı onay gerektirir veya yasaktır. Testler yalnızca kendi sahip olduğunuz kaynaklara karşı yapılmalıdır.

Azure ve Microsoft 365 Test Kuralları

Microsoft da benzer şekilde bir penetrasyon testi kuralları seti yayınlar. Kendi aboneliğinizdeki kaynaklara karşı test yapabilirsiniz, ancak Microsoft'un paylaşılan altyapısını veya diğer müşterileri etkileyecek testler yasaktır. Microsoft 365 ortamlarında phishing simülasyonları ve hesap ele geçirme testleri özellikle dikkatli bir kapsam tanımı gerektirir.

DSET olarak her bulut denetiminde, test başlamadan önce kapsamı, hedef abonelikleri ve sağlayıcı kurallarına uygunluğu yazılı olarak netleştiririz. KAOS dahil tüm test araçlarımız yalnızca yetki dahilinde ve sağlayıcı kurallarına uygun çalışır. Sürecin nasıl işlediğini sızma testi süreci ve fiyatı yazımızda ayrıntılı bulabilirsiniz.

IAM ve Ayrıcalık Yükseltme: Bulutun Kalbi

Kimlik ve Erişim Yönetimi (IAM), bulut güvenliğinin en kritik ve en sık hatalı yapılandırılan alanıdır. Bir saldırgan için ideal hedef, geniş yetkilere sahip ama zayıf korunan bir kimliktir.

AWS IAM Ayrıcalık Yükseltme Senaryoları

AWS IAM'de ayrıcalık yükseltme genellikle politika zincirlerinin sömürülmesiyle gerçekleşir. Sık görülen senaryolar:

  • iam:PassRole + servis kötüye kullanımı: Düşük yetkili bir kullanıcı, kendisine iam:PassRole ve örneğin lambda:CreateFunction izni verilmişse, yüksek yetkili bir rolü bir Lambda fonksiyonuna geçirerek admin yetkisine ulaşabilir.
  • iam:CreatePolicyVersion: Mevcut bir politikaya yeni bir sürüm ekleme izni olan kullanıcı, kendi yetkilerini sessizce genişletebilir.
  • iam:AttachUserPolicy: Kullanıcı kendisine doğrudan AdministratorAccess politikasını ekleyebilir.
  • sts:AssumeRole zincirleri: Bir rolden diğerine geçişle yetki tırmanışı (role chaining).

Görünüşte zararsız izinlerin birleşimi, çoğu zaman admin yetkisine giden bir yol açar. İşte bu yüzden bulut pentestinde tekil izinler değil, izin grafiği (permission graph) analiz edilir.

Azure RBAC ve Yönetilen Kimlikler

Azure tarafında ayrıcalık yükseltme genellikle RBAC rol atamaları ve yönetilen kimlikler (managed identity) üzerinden olur. Örneğin Owner yerine yanlışlıkla verilen User Access Administrator rolü, bir kullanıcının kendisine başka roller atamasına izin verir. Bir VM'e bağlı aşırı yetkili yönetilen kimlik de saldırgan için bir ayrıcalık yükseltme aracına dönüşür.

Açık Depolama: S3 Kovaları ve Azure Blob

Veri sızıntılarının en bilinen nedeni hâlâ yanlış yapılandırılmış depolamadır. İnternette herkese açık bırakılmış bir S3 kovası veya Azure Blob konteyneri, kurumun en hassas verilerini saniyeler içinde ifşa edebilir.

Sık görülen yanlış yapılandırmalar:

  • Genel okuma/yazma erişimi: Bir S3 kovasının Block Public Access ayarının kapalı olması ve kova politikasının Principal: * içermesi.
  • Listelenebilir Blob konteynerleri: Azure'da konteyner erişim seviyesinin Blob veya Container olarak ayarlanması, anonim erişime kapı açar.
  • Şifrelenmemiş veri: Sunucu tarafı şifrelemenin (SSE) etkin olmaması.
  • Loglanmayan erişim: S3 access log veya Azure Storage Analytics kapalıyken sızıntının fark edilememesi.
  • Önceden imzalı URL'lerin (presigned URL) uzun ömürlü olması: Sızdırılan bir URL'in günlerce geçerli kalması.

DSET denetimlerinde açık depolama bulgularını yalnızca tespit etmekle kalmaz, doğrulanmış zafiyet, yanlış pozitifsiz test yaklaşımımızla kanıt (PoC) ile doğrularız. Böylece müşteriye "belki açık" değil, "şu dosya şu anda dışarıdan okunabiliyor" netliğinde bir bulgu sunarız.

Azure Entra ID Kimlik Saldırıları (Özet)

Azure Entra ID (eski adıyla Azure AD), hibrit bulut ortamlarının kimlik omurgasıdır ve bu nedenle saldırganların öncelikli hedefidir. Token çalma, OAuth onay phishing'i, Golden SAML ve federasyon güveninin kötüye kullanılması gibi teknikler, bir saldırganın bulut kimliklerini ele geçirmesine ve kalıcılık sağlamasına olanak tanır.

Bu makale bulut denetimi ve pentest kapsamına odaklandığı için Entra ID saldırı tekniklerini burada tekrar etmiyoruz. Token tabanlı saldırılar, Golden SAML ve hibrit bulut kalıcılık tekniklerinin derinlemesine analizi için Azure Entra ID saldırı teknikleri ve Golden SAML yazımızı okumanızı öneririz. Denetim açısından önemli olan nokta şudur: Entra ID yapılandırması (koşullu erişim, MFA kapsamı, eski kimlik doğrulama protokolleri) her bulut denetiminin ayrılmaz bir parçasıdır.

Microsoft 365 Güvenlik Denetimi

Microsoft 365, kurumların e-posta, dosya paylaşımı ve iş birliği altyapısını barındırdığı için saldırı yüzeyi son derece geniştir. M365 denetiminde odaklandığımız başlıca alanlar:

E-posta ve Exchange Online

  • SPF, DKIM ve DMARC kayıtlarının doğru yapılandırılması (e-posta sahteciliğini önlemek için).
  • Otomatik iletim (auto-forwarding) kurallarının denetimi, çünkü saldırganlar ele geçirilen kutulardan veriyi dışarı kaçırmak için gizli iletim kuralları oluşturur.
  • Eski kimlik doğrulama protokollerinin (POP3, IMAP, SMTP AUTH) kapatılması.

OAuth Uygulama İzinleri

Microsoft 365'in en sinsi saldırı yüzeyi, üçüncü taraf OAuth uygulamalarına verilen izinlerdir. Bir kullanıcı, zararlı bir uygulamaya "e-postalarımı oku" iznini bir kez onayladığında, saldırgan parolayı bilmeden ve MFA'yı aşmadan kalıcı erişim elde eder. Bu "illicit consent grant" saldırısı, denetimlerde mutlaka taranması gereken bir alandır.

Koşullu Erişim Politikaları

Koşullu erişim (Conditional Access), kimin, nereden, hangi cihazla erişebileceğini belirleyen politika setidir. Sık görülen zafiyetler: MFA istisnaları, eski protokollerin koşullu erişimin dışında kalması ve "break-glass" hesaplarının aşırı geniş yapılandırılması.

CIS Benchmark ve CSPM ile Sürekli Denetim

Tek seferlik bir pentest, bir anlık fotoğraf sunar. Ancak bulut ortamları sürekli değişir; yeni kaynaklar oluşur, politikalar gevşer. Bu yüzden modern bulut güvenliği, sürekli denetimi gerektirir.

CIS Benchmark

CIS (Center for Internet Security) Benchmark'ları, AWS, Azure ve Microsoft 365 için sektör standardı güvenli yapılandırma kılavuzlarıdır. Örneğin "kök hesap için MFA etkin olmalı", "depolama şifreleme zorunlu olmalı" gibi yüzlerce kontrol maddesi içerir. Denetimler bu benchmark'lara göre puanlanır.

CSPM (Cloud Security Posture Management)

CSPM araçları, bulut ortamını sürekli tarayarak yanlış yapılandırmaları otomatik tespit eder. CIS Benchmark uyumsuzluklarını, açık depolamayı ve aşırı yetkili kimlikleri gerçek zamanlı raporlar. DSET'in yapay zeka destekli ofansif güvenlik ajanı KAOS yapay zeka güvenlik motoru, bu sürekli tarama yaklaşımını ofansif bir bakış açısıyla birleştirir: yalnızca yanlış yapılandırmayı listelemekle kalmaz, bunun bir saldırı yolu oluşturup oluşturmadığını yetki dahilinde doğrular.

Bulut Sızma Testi Araçları

Bulut pentestinde kullanılan açık kaynak araçlar, denetimin temelini oluşturur. Başlıca araçlar ve kullanım alanları:

Araç Sağlayıcı Kullanım Alanı
ScoutSuite AWS, Azure, GCP Çok bulutlu yapılandırma denetimi
Prowler AWS, Azure CIS Benchmark uyum taraması
Pacu AWS Ofansif AWS sömürü çerçevesi
ROADtools Azure / Entra ID Entra ID keşif ve veri toplama
AzureHound Azure / Entra ID Saldırı yolu grafiği (BloodHound)

Araçların Rolleri

  • ScoutSuite: Bir ortamın güvenlik duruşunu hızlıca raporlayan, çok bulutlu denetim aracı. Keşif aşaması için idealdir.
  • Prowler: Yüzlerce CIS kontrolünü otomatik çalıştırır ve uyum raporu üretir. Sürekli denetim için sıkça kullanılır.
  • Pacu: Metasploit'in bulut karşılığı sayılabilecek, AWS'ye özgü ofansif çerçeve. IAM ayrıcalık yükseltme modülleri içerir.
  • ROADtools: Entra ID ortamından kullanıcı, grup, uygulama ve izin verilerini toplar; saldırı yüzeyi analizine zemin hazırlar.
  • AzureHound: Azure ve Entra ID'deki ilişkileri grafiğe döker, böylece bir saldırganın hangi yolla yetki tırmanabileceği görselleştirilir.

DSET olarak bu araçları KAOS ile birleştiririz. KAOS keşif çıktısını alır, yanlış yapılandırmaları otomatik tespit eder, zafiyetleri kanıtla doğrular ve yönetici ile teknik ekip için ayrı seviyelerde raporlar üretir. Tüm bu süreç yetki dahilinde ve sağlayıcı kurallarına uygun yürür.

DSET Bulut Denetim Metodolojisi

Bir bulut güvenlik denetimini şu aşamalarla yürütürüz:

  1. Kapsam ve yetkilendirme: Hedef abonelikler, hizmetler ve sağlayıcı kurallarına uygunluk yazılı olarak netleştirilir.
  2. Keşif ve envanter: Tüm kaynaklar, kimlikler ve yapılandırmalar haritalanır.
  3. Yapılandırma denetimi: CIS Benchmark ve CSPM ile uyumsuzluklar tespit edilir.
  4. Saldırı yolu analizi: IAM/RBAC izin grafikleri ile ayrıcalık yükseltme yolları çıkarılır.
  5. Zafiyet doğrulama: Bulgular yetki dahilinde kanıtla (PoC) doğrulanır.
  6. Raporlama ve remediation: Yönetici özeti, teknik detay ve önceliklendirilmiş düzeltme adımları sunulur.

Sıkça Sorulan Sorular

Bulut sızma testi yapmadan önce sağlayıcıdan izin almam gerekir mi?

AWS ve Microsoft, kendi hesabınızdaki çoğu servis için önceden onay gerektirmeyen bir test politikası yayınlar. Ancak DoS, port flooding ve sağlayıcının paylaşılan altyapısını etkileyen testler ayrı onay gerektirir veya yasaktır. DSET her testte önce sağlayıcı kurallarını ve kapsamı netleştirir.

Bulut pentest ile geleneksel pentest aynı şey mi?

Hayır. Geleneksel pentest ağ portları ve servislere odaklanır; bulut pentest ise kimliklere, IAM/RBAC izinlerine ve yönetim düzlemine (control plane) odaklanır. Saldırı yolları ve araçlar tamamen farklıdır.

Microsoft 365 zaten Microsoft tarafından korunmuyor mu?

Paylaşılan sorumluluk modeline göre Microsoft uygulama altyapısını korur, ancak kullanıcı kimlikleri, OAuth uygulama izinleri, koşullu erişim ve veri paylaşım ayarları müşterinin sorumluluğundadır. Bunlar en sık istismar edilen alanlardır.

CSPM bir sızma testinin yerini tutar mı?

Hayır. CSPM sürekli yapılandırma denetimi sağlar ve yanlış yapılandırmaları tespit eder, ancak bunların gerçek bir saldırı yoluna dönüşüp dönüşmediğini doğrulamaz. İkisi tamamlayıcıdır: CSPM sürekli görünürlük, pentest ise derinlemesine doğrulama sunar.

Açık bir S3 kovası ne kadar tehlikeli?

Genele açık bir S3 kovası veya Azure Blob konteyneri, kurumun en hassas verilerini anonim olarak ifşa edebilir. Birçok büyük veri ihlalinin kökeninde bu yanlış yapılandırma yatar. DSET bu bulguları kanıtla doğrular ve önceliklendirilmiş düzeltme adımları sunar.

KAOS bulut testinde tam olarak ne yapar?

KAOS, DSET'in yapay zeka destekli ofansif güvenlik ajanıdır. Yetkili testlerde keşif, IAM yanlış yapılandırma tespiti, açık depolama analizi ve kimlik saldırı yollarının haritalanmasını yapar; zafiyetleri kanıtla (PoC) doğrular ve raporlar. Tüm testler yetki dahilinde ve sağlayıcı kurallarına uygundur.

Kaynaklar

DSET Bilişim ve Siber Güvenlik (kuruluş 2003). Kurumsal bulut güvenlik denetimi ve KAOS ile sürekli tarama için: +90 536 662 38 09.