Cloud Security Review Neyi Kapsar?

Temel Değerlendirme

Cloud security review; IAM, network exposure, storage permissions, Kubernetes/container kontrolleri, logging, secret yönetimi, CI/CD deploy yetkileri ve saldırı yollarını birlikte inceleyen teknik güvenlik değerlendirmesidir. Sadece "yanlış ayar var mı?" taraması değildir. İyi bir review, hangi misconfiguration'ın gerçekten istismar edilebilir olduğunu, hangi identity'nin hangi kaynağa ulaşabildiğini ve bir saldırganın cloud ortamında nasıl privilege escalation yapabileceğini kanıtlar.

Cloud Ortamında Risk Neden Farklıdır?

Cloud sistemlerinde güvenlik sınırı fiziksel ağdan çok identity ve policy üzerinden kurulur. Bir IAM rolü, yanlış storage policy veya fazla yetkili CI/CD tokenı, dışarı açık porttan daha kritik hale gelebilir.

Modern cloud riskleri genellikle şu birleşimlerden doğar:

Fazla geniş IAM policy
Public storage bucket
Yanlış security group veya firewall kuralı
Metadata endpoint exposure
Kubernetes secret ve service account hataları
CI/CD pipeline'ın production üzerinde fazla yetkili olması
Logların incident response için yetersiz kalması

Cloud Security Review Katmanları

| Katman | İncelenen risk | Neden önemli? | |---|---|---| | IAM | Fazla yetki, privilege escalation, unused access | Cloud güvenliğinin ana sınırı identity'dir. | | Network | Public exposure, inbound/outbound kurallar | İnternete açık yüzey ve lateral movement etkilenir. | | Storage | Public bucket, yanlış object policy | Veri sızıntılarının yaygın nedenidir. | | Compute | VM, container, serverless runtime | Workload compromise etkisini belirler. | | Kubernetes | RBAC, admission, secret, network policy | Cluster içi privilege escalation riskini azaltır. | | CI/CD | Deploy identity, secret, runner isolation | Supply chain ve production erişimi buradan geçer. | | Logging | Audit coverage, alert, retention | Olay anında neyin görüleceğini belirler. |

Misconfiguration Taraması Yetmez

Cloud scanner size yüzlerce uyarı verebilir. Asıl zor olan, bunları risk zinciri içinde okumaktır.

Örneğin tek başına "S3 bucket policy geniş" bulgusu önemlidir. Fakat şu zincir çok daha kritiktir:

Public endpoint SSRF'e açık.
Workload metadata endpointine erişebiliyor.
Instance role fazla yetkili.
Role storage bucket içindeki backup dosyalarını okuyabiliyor.
Backup içinde database credential bulunuyor.

Bu artık tekil misconfiguration değil, cloud compromise path'tir.

Yanlış Bilinenler

| Yanlış varsayım | Gerçek durum | |---|---| | "Cloud provider güvenli, biz güvendeyiz." | Provider altyapıyı korur; sizin IAM, data ve workload ayarlarınız sizin sorumluluğunuzdur. | | "CSPM tool var, review gerekmez." | Tool sinyal verir; attack path ve iş etkisi manuel analiz ister. | | "Private subnet içindeyse risk yok." | IAM ve outbound path varsa private kaynaklar da compromise zincirine girebilir. | | "Kubernetes sadece platform ekibinin konusu." | Cluster yetkileri application, secret ve CI/CD güvenliğini doğrudan etkiler. |

Pratik Review Akışı

Cloud security review genellikle şu sırayla yürür:

Account/subscription/project envanteri çıkarılır.
IAM principal ve role ilişkileri analiz edilir.
Public exposure ve DNS/IP yüzeyi kontrol edilir.
Storage ve database erişimleri incelenir.
Kubernetes ve container runtime kontrolleri değerlendirilir.
CI/CD deploy kimlikleri ve secret akışı test edilir.
Logging ve alert görünürlüğü ölçülür.
En kritik attack path'ler kanıtlanır.

Profesyonel Destek Ne Zaman Gerekir?

Şu durumlarda cloud security review yüksek değer üretir:

Production cloud ortamı hızlı büyüdü ve ownership belirsizleşti.
Çok sayıda IAM role, service account veya access key var.
Kubernetes, serverless veya multi-cloud kullanılıyor.
CI/CD pipeline doğrudan production'a deploy ediyor.
Müşteri veya compliance cloud güvenlik kanıtı istiyor.
Daha önce scanner çıktısı alındı ama önceliklendirme yapılamadı.

Review İçin Gerekli Kanıtlar

Cloud review başlamadan önce şu veriler hazırlanırsa analiz daha güçlü olur:

Account, subscription veya project listesi.
IAM role ve service account envanteri.
Public IP, domain ve load balancer listesi.
Kubernetes cluster ve namespace listesi.
CI/CD deploy workflow'ları.
Secret store ve key rotation politikası.
Audit log kaynakları ve retention süresi.
Son cloud scanner veya CSPM çıktıları.

Bu bilgiler, review sürecini "liste kontrolü" olmaktan çıkarıp attack path analizine taşır.

İçerik Yükseltme Önerisi

Bu yazının en doğal PDF'i Kubernetes Exposure Checklist veya daha geniş haliyle Cloud Security Review Prep Sheet olur. Okuyucuya review öncesi hangi kanıtları hazırlaması gerektiğini gösterir.

Eresus Yaklaşımı

Eresus Security cloud security review çalışmalarında yalnızca checklist çalıştırmaz. IAM, network, workload, Kubernetes, secret ve CI/CD katmanlarını saldırı yolu olarak birlikte inceler. Amacımız "kaç misconfiguration var?" sorusundan çok "hangisi gerçekten compromise'a götürür?" sorusunu teknik kanıtla cevaplamaktır. Cloud ve Kubernetes ortamınız için istismar edilebilir yolları birlikte çıkarmak üzere Cloud Security Review planlayabiliriz.

SSS

Cloud security review pentest midir?

Kısmen örtüşür. Review daha çok configuration, identity, architecture ve attack path analizine odaklanır; gerektiğinde kontrollü istismar doğrulaması içerir.

CSPM aracı yeterli mi?

CSPM güçlü bir başlangıçtır. Fakat bulguların iş etkisi, exploitability ve remediation önceliği için uzman review gerekir.

Kubernetes review cloud review içinde olmalı mı?

Cluster production workload çalıştırıyorsa evet. Kubernetes RBAC, secret, image trust ve network policy cloud riskini doğrudan etkiler.

Ek Kontrol Soruları

Bu risk hangi varlıkları etkiliyor?
Hangi kullanıcı rolleri bu akışa erişebiliyor?
Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
Bulgunun müşteri verisine etkisi var mı?
Loglardan olayın izi sürülebiliyor mu?
Düzeltme sonrası retest nasıl yapılacak?
Geçici önlem ile kalıcı çözüm ayrıldı mı?
İş etkisi teknik ekibin dışında da anlaşılır mı?
Benzer hata için önleyici kontrol eklenebilir mi?
Ekip bu kontrolü release sürecine bağlayabilir mi?
Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?