Cloud Misconfiguration Nedir? Yanlış Bulut Yapılandırmaları Nasıl Tespit Edilir?

Bulut güvenliği olaylarının önemli bir bölümü karmaşık zero-day açıklarından başlamaz.

Çok daha basit bir şey yeterli olabilir:

Yanlış açılmış bir Security Group.

Public bırakılmış bir storage bucket.

İnternete açık database.

Yetkisiz erişime açık snapshot.

Logging'i kapatılmış bir cloud account.

Gereğinden geniş IAM policy.

Kod içerisinde unutulmuş bir secret.

İşte bu tür hatalar genel olarak Cloud Misconfiguration – Bulut Yanlış Yapılandırması olarak adlandırılır.

Cloud ortamları çok hızlı değiştiği için bu risk klasik veri merkezi ortamlarına göre daha görünür hale gelebilir.

Bir developer birkaç dakika içerisinde yeni resource oluşturabilir.

Terraform ile yüzlerce kaynak deploy edilebilir.

Bir test ortamı kısa süreli açılabilir.

Bir firewall rule “geçici” olarak genişletilebilir.

Ancak bu geçici değişiklikler aylarca sistemde kalabilir.

Bu nedenle modern cloud security yaklaşımında en kritik konulardan biri:

Cloud ortamındaki güvenli olmayan yapılandırmaları sürekli olarak tespit etmek, önceliklendirmek ve mümkün olduğunca otomatik şekilde düzeltmektir.

Bu noktada Cloud Misconfiguration, CSPM, CNAPP, Cloud Security Posture Management, Configuration Drift, Policy as Code, Public Cloud Exposure ve Cloud Compliance kavramları önem kazanır.

Cloud Misconfiguration Nedir?

Cloud Misconfiguration, AWS, Microsoft Azure, Google Cloud veya diğer cloud platformlarındaki bir kaynağın güvenli olmayan, gereğinden fazla açık veya kurumun güvenlik politikasına aykırı şekilde yapılandırılmasıdır.

Örnekler şunlar olabilir:

• Public storage
• İnternete açık SSH veya RDP
• Public database
• Gereğinden geniş Security Group
• Logging'in kapalı olması
• Encryption'ın kapalı olması
• Aşırı yetkili IAM policy
• Public snapshot
• Açık secret
• Yanlış cross-account trust
• Kullanılmayan ama açık cloud resource

Bu hataların önemli bir kısmı teknik olarak “vulnerability” olmayabilir.

Ancak saldırgan için doğrudan erişim yolu oluşturabilir.

Cloud Misconfiguration Neden Bu Kadar Yaygındır?

Cloud altyapıları hızlıdır.

Bu hız operasyonel avantaj sağlar.

Ama aynı zamanda insan hatasını da hızlandırır.

Örneğin bir developer test yapmak için:

SSH → 0.0.0.0/0

açar.

Test biter.

Rule kapatılmaz.

Bir süre sonra bu kaynak unutulur.

Benzer şekilde storage paylaşımı geçici olarak public yapılabilir.

Ama daha sonra private'a çevrilmeyebilir.

Bu nedenle cloud security'nin önemli problemi:

Geçici değişikliğin kalıcı riske dönüşmesidir.

Configuration Drift Nedir?

Configuration Drift, bir sistemin başlangıçta belirlenen güvenli yapılandırmadan zaman içerisinde sapmasıdır.

Örneğin Terraform ile güvenli infrastructure deploy edilmiş olabilir.

Sonra administrator portal üzerinden manuel olarak:

Security Group rule ekler.

Bu değişiklik IaC kodunda yoktur.

Artık production konfigürasyonu ile deklaratif yapı birbirinden farklıdır.

Bu durum Configuration Drift'tir.

Cloud security için oldukça kritik bir problemdir.

Drift Neden Güvenlik Riski Oluşturur?

Çünkü security ekipleri güvenli baseline'ın hâlâ geçerli olduğunu düşünebilir.

Ancak gerçek ortam değişmiştir.

Örneğin;

database public olmuş,

encryption kapatılmış,

logging devre dışı bırakılmış,

IAM role genişletilmiş

olabilir.

Bu nedenle cloud ortamında güvenlik yalnızca deployment anında kontrol edilmemelidir.

Runtime posture sürekli izlenmelidir.

Cloud Security Posture Management – CSPM Nedir?

CSPM, cloud ortamındaki güvenlik yapılandırmalarını sürekli analiz eden yaklaşım ve teknoloji kategorisidir.

CSPM şu tür riskleri tespit edebilir:

public storage,

open Security Group,

MFA eksikliği,

logging disabled,

encryption disabled,

public database,

overprivileged access.

Amaç cloud ortamını sürekli olarak güvenlik baseline'ına karşı değerlendirmektir.

CSPM Nasıl Çalışır?

Genellikle cloud provider API'lerine bağlanarak kaynakların konfigürasyonlarını analiz eder.

Örneğin:

AWS account

↓

S3 bucket policy

↓

Public access detected

↓

Finding generated

CSPM sadece anlık scan yapmak yerine periyodik veya sürekli görünürlük sağlayabilir.

Bu nedenle büyük cloud ortamlarında manuel review'dan daha sürdürülebilirdir.

CSPM ile Vulnerability Scanner Arasındaki Fark Nedir?

Vulnerability scanner daha çok;

CVE,

software version,

patch

risklerine odaklanır.

CSPM ise;

configuration,

identity,

cloud policy,

exposure

risklerine bakar.

Örneğin database yazılımında hiç CVE olmayabilir.

Ama database public IP üzerinden internete açıksa ciddi güvenlik riski vardır.

Vulnerability scanner bunu her zaman doğru bağlamda göstermez.

Public Cloud Exposure Nedir?

Bir cloud resource'un doğrudan internetten erişilebilir olması Public Exposure olarak değerlendirilir.

Örneğin;

VM,

database,

storage,

management panel,

API

public olabilir.

Public exposure her zaman hata değildir.

Bir web sitesi zaten public olmak zorundadır.

Ancak kritik olan:

Doğru servis mi public?

Doğru port mu açık?

Doğru authentication var mı?

sorularıdır.

Public S3 Bucket Nedir?

AWS S3 bucket yanlış access policy ile herkese açık hale getirilebilir.

Bu durumda saldırgan;

dosyaları listeleyebilir,

indirebilir,

bazı durumlarda yazabilir

hale gelebilir.

Bucket içerisinde;

backup,

müşteri verisi,

doküman,

source code,

log

bulunabilir.

Bu nedenle public storage cloud security'nin en kritik klasik risklerinden biridir.

Azure Blob Storage Public Access Riski

Azure Blob Storage üzerinde container public access yanlış yapılandırılırsa veriler authentication olmadan erişilebilir hale gelebilir.

Bu durum özellikle;

backup,

export,

log,

müşteri dosyaları

için ciddi veri sızıntısı riski oluşturur.

Bu nedenle Storage Account policy ve container-level access birlikte değerlendirilmelidir.

Google Cloud Storage Public Exposure

GCP Cloud Storage üzerinde yanlış IAM veya public access policy nedeniyle object'ler internetten erişilebilir olabilir.

Örneğin;

allUsers

veya geniş external principal erişimleri kritik olabilir.

Ancak public website asset için bu yapı meşru olabilir.

Yine bağlam önemlidir.

Public Storage Nasıl Tespit Edilir?

CSPM araçları veya cloud-native security servisleri;

bucket policy,

ACL,

IAM,

public access settings

üzerinden analiz yapabilir.

Ancak sadece:

Public = Critical

mantığı yeterli değildir.

Resource içerisinde hassas veri var mı?

Production mı?

Public olması iş gereksinimi mi?

Bu bağlamlar önemlidir.

Data Classification Cloud Misconfiguration Analizini Nasıl Güçlendirir?

Bir public bucket içerisinde sadece public marketing görselleri varsa risk düşüktür.

Ama aynı bucket'ta;

müşteri bilgisi,

finans dosyası,

kişisel veri

bulunuyorsa risk çok daha yüksektir.

Bu nedenle modern cloud security:

Exposure + Data Sensitivity

birlikte değerlendirilmelidir.

DSPM Nedir?

Data Security Posture Management – DSPM, cloud ve diğer ortamlardaki hassas verilerin nerede bulunduğunu, kimlerin erişebildiğini ve nasıl korunduğunu analiz etmeye odaklanır.

CSPM:

“Bu bucket public.”

der.

DSPM:

“Bu bucket içinde kişisel veri var.”

diyebilir.

İki bilgi birleştirildiğinde risk çok daha doğru önceliklendirilir.

Public Database Nedir?

Cloud database'in public network üzerinden erişilebilir olması ciddi saldırı yüzeyi oluşturabilir.

Örneğin;

PostgreSQL,

MSSQL,

MySQL,

MongoDB

internet üzerinden erişilebilir olabilir.

Authentication olsa bile saldırgan;

brute force,

credential stuffing,

vulnerability scanning

yapabilir.

Mümkün olduğunda database private network'te tutulmalıdır.

Managed Database Güvenli Olduğu İçin Public Olabilir mi?

Hayır.

Managed olması sadece belirli altyapı sorumluluklarını provider'a taşır.

Network exposure ve access control yine müşterinin sorumluluğunda olabilir.

Bu nedenle:

Managed ≠ Safe by Default

olarak düşünmek gerekir.

Open Security Group Nedir?

Security Group veya benzeri cloud firewall kuralının çok geniş kaynak aralığına izin vermesidir.

Örneğin:

0.0.0.0/0 → 22

veya

0.0.0.0/0 → 3389

yüksek riskli olabilir.

Çünkü internet üzerindeki herkes yönetim servisine ulaşabilir.

Neden SSH ve RDP Public Olmamalı?

SSH ve RDP doğrudan administrator erişimi sağlayabilir.

Bu servislerin internetten açık olması;

brute force,

password spraying,

credential attack,

vulnerability exploitation

riskini artırır.

Daha güvenli yaklaşım:

VPN,

Bastion,

PAM,

JIT Access

üzerinden erişim sağlamaktır.

Bastion Host Cloud'da Nasıl Kullanılır?

Cloud Bastion hizmeti veya merkezi Jump Server üzerinden administrator erişimi sağlanabilir.

Örneğin:

Admin Laptop

↓

MFA

↓

Bastion

↓

Private VM

Bu durumda VM'nin SSH veya RDP portunun internete açılması gerekmez.

JIT Network Access Nedir?

Just-in-Time Network Access, yönetim portunun sürekli açık tutulması yerine yalnızca gerektiğinde kısa süre için açılmasıdır.

Örneğin SSH portu:

30 dakika

belirli administrator IP'sine

açılır.

Süre sonunda otomatik kapatılır.

Bu yaklaşım public management exposure riskini azaltabilir.

Public Snapshot Nedir?

Cloud snapshot'lar VM veya database verisinin kopyasını içerebilir.

Yanlış sharing policy nedeniyle snapshot başka account veya public erişime açılabilir.

Bu durumda saldırgan production sistemine girmeden veriyi snapshot üzerinden elde edebilir.

Bu nedenle snapshot'lar da data asset olarak değerlendirilmelidir.

Snapshot Neden Hassastır?

Snapshot içerisinde;

database,

password hash,

configuration,

application secret,

customer data

bulunabilir.

Bu nedenle snapshot access policy production sistemden daha az önemli değildir.

Hatta bazen saldırgan açısından daha kolay hedeftir.

Backup Misconfiguration Nedir?

Cloud backup service yanlış yapılandırılırsa;

backup public olabilir,

encryption kapalı olabilir,

retention yetersiz olabilir,

her administrator silebilir.

Bu durum ransomware ve data loss riskini artırır.

Backup güvenliği ayrı bir güvenlik domain'i olarak ele alınmalıdır.

Encryption Disabled Neden Misconfiguration Sayılır?

Hassas data içeren storage veya database'in encryption olmadan tutulması risk oluşturabilir.

Cloud provider birçok serviste default encryption sunabilir.

Ancak bazı servislerde config kontrol edilmelidir.

Ayrıca sadece encryption değil, key access de önemlidir.

KMS Permission Misconfiguration Nedir?

Veri şifrelenmiş olabilir.

Ama KMS key herkes tarafından kullanılabiliyorsa güvenlik zayıflar.

Örneğin attacker:

encrypted storage

ve

encryption key

ikisine de erişebiliyorsa veri korunmamış olur.

Bu nedenle KMS IAM policy kritik öneme sahiptir.

Logging Disabled Neden Kritik?

Cloud audit log'larının kapalı olması saldırgan aktivitelerinin görünürlüğünü azaltır.

Örneğin saldırgan;

resource oluşturur,

IAM değiştirir,

data indirir

ama audit trail bulunmaz.

Bu Incident Response'u ciddi şekilde zorlaştırır.

Bu nedenle logging cloud security baseline'ın temel kontrollerinden biri olmalıdır.

CloudTrail Disabled Riskli midir?

AWS ortamında CloudTrail veya ilgili audit mekanizmalarının eksik olması administrative activity görünürlüğünü azaltabilir.

Ayrıca logların sadece local account'ta tutulması risklidir.

Saldırgan yüksek yetki elde ettiğinde logları silmeye çalışabilir.

Bu nedenle merkezi ve ayrı log account mimarisi değerlendirilebilir.

Central Logging Neden Güçlüdür?

Örneğin production account compromised olabilir.

Ancak loglar ayrı security account'a aktarılıyorsa saldırgan production yetkisiyle geçmiş logları kolayca silemeyebilir.

Bu yaklaşım Incident Response ve forensic için değerlidir.

MFA Eksikliği Cloud Misconfiguration Sayılır mı?

Evet, özellikle privileged kullanıcılar için.

Cloud security posture assessment sırasında;

root,

tenant owner,

administrator

hesaplarında MFA eksikliği kritik bulgu olabilir.

Ama tüm kullanıcılar için aynı severity uygulanmayabilir.

Role ve risk seviyesi dikkate alınmalıdır.

Root Account Günlük Kullanımda Olursa Ne Olur?

En yüksek yetkili hesap sürekli kullanılırsa;

phishing,

credential leak,

session compromise

risklerinin etkisi büyür.

Root veya tenant-level emergency hesaplar günlük operasyon için kullanılmamalıdır.

IAM Wildcard Permission Misconfiguration Nedir?

Örneğin:

Action: *

ve

Resource: *

gibi çok geniş permission'lar ciddi risk oluşturabilir.

Ancak bazı service role'lerde teknik nedenlerle belirli wildcard'lar gerekebilir.

Bu nedenle context-based IAM analysis yapılmalıdır.

Cross-Account Trust Misconfiguration Nedir?

Bir account başka account'a erişim verebilir.

Bu normal olabilir.

Ancak eski vendor veya test account'a hâlâ trust varsa saldırgan bu yolu kullanabilir.

Bu nedenle cross-account trust envanteri sürekli gözden geçirilmelidir.

External Sharing Cloud Security Riski

Cloud resource veya storage başka organization veya tenant ile paylaşılmış olabilir.

Bu paylaşım business için gerekli olabilir.

Ama bitiş tarihi yoksa yıllarca açık kalabilir.

Bu nedenle third-party access lifecycle kritik bir konudur.

Anonymous Access Nedir?

Authentication olmadan kaynağa erişim sağlanmasıdır.

Örneğin public object link.

Bu bazı use case'lerde gerekli olabilir.

Ancak hassas sistemlerde ciddi exposure riskidir.

Cloud security sistemi anonymous access'i hızlı şekilde görünür hale getirmelidir.

Cloud Secret Exposure Nedir?

Secret;

API key,

database password,

private key,

token

olabilir.

Yanlış konfigürasyon nedeniyle;

repository,

VM metadata,

environment variable,

log,

storage

içerisinde açığa çıkabilir.

Bu nedenle secret scanning ve secret management birlikte uygulanmalıdır.

Environment Variable İçinde Secret Tutmak Güvenli mi?

Bazı uygulamalarda kullanılır.

Ancak process inspection, loglama veya debug sırasında secret açığa çıkabilir.

Daha güçlü yaklaşım secret vault ve workload identity kullanmaktır.

Secret'ın runtime'a nasıl verildiği ayrıca değerlendirilmelidir.

Instance Metadata Service Nedir?

Cloud VM'ler kendi metadata servislerinden geçici credential veya instance bilgisi alabilir.

Bu servis yanlış network veya application yapılandırmalarıyla kötüye kullanılabilir.

Örneğin SSRF zafiyeti üzerinden metadata erişimi bazı saldırı senaryolarında ciddi sonuç oluşturabilir.

Bu nedenle metadata service güvenliği önemlidir.

SSRF ile Cloud Misconfiguration Nasıl Birleşir?

Bir web application SSRF zafiyetine sahip olabilir.

Tek başına application vulnerability'dir.

Ancak VM yüksek yetkili identity ile çalışıyorsa saldırgan metadata üzerinden credential elde edebilir.

Sonuç:

SSRF + Overprivileged Identity = Critical Cloud Attack Path

Bu nedenle bulgular tek tek değil birlikte analiz edilmelidir.

Toxic Combination Nedir?

Tek başına farklı severity'lerde görünen cloud problemlerinin birleşerek kritik saldırı yolu oluşturmasıdır.

Örneğin:

Public Web Application

SSRF

Metadata Access

Privileged IAM Role

Sensitive Storage

birlikte kritik risk oluşturur.

Modern cloud security'nin amacı bu tür kombinasyonları bulmaktır.

CSPM Toxic Combination'ı Görebilir mi?

Gelişmiş CSPM/CNAPP platformları;

asset,

identity,

network,

vulnerability,

data

bağlamlarını birleştirerek saldırı yollarını analiz edebilir.

Bu klasik compliance listesine göre daha değerlidir.

Çünkü:

1.000 misconfiguration

yerine

3 gerçek kritik attack path

önceliklendirilebilir.

Cloud Attack Path Analysis Nedir?

Saldırganın düşük yetkili veya internet-facing bir noktadan kritik veriye ulaşabileceği ilişki zincirlerini analiz eder.

Örneğin:

Internet

↓

Public VM

↓

Critical CVE

↓

Managed Identity

↓

Key Vault

↓

Database Credential

↓

Production Database

Bu zincir gerçek risk hikâyesidir.

Cloud Misconfiguration ile Cloud Vulnerability Arasındaki Fark

Vulnerability

Yazılım veya sistemde teknik güvenlik açığıdır.

Misconfiguration

Güvenlik ayarının yanlış veya zayıf yapılmasıdır.

Örneğin:

Apache CVE → vulnerability.

SSH 0.0.0.0/0 → misconfiguration.

İki risk birlikte bulunabilir.

Cloud Compliance Nedir?

Cloud configuration'ların belirli;

CIS Benchmark,

ISO 27001,

PCI DSS,

kurum policy'si

gibi standartlara göre değerlendirilmesidir.

CSPM araçları bu mapping'i otomatik yapabilir.

Ancak compliance pass etmek gerçek güvenlik garantisi değildir.

CIS AWS Foundations Benchmark Nedir?

AWS account için temel güvenlik kontrolleri önerir.

Örneğin;

IAM,

logging,

monitoring,

network

alanlarında kontroller bulunabilir.

Benzer şekilde Azure ve Google Cloud için de CIS benchmark'ları kullanılabilir.

Bu yapılar security baseline oluşturmak için değerlidir.

Benchmark'a %100 Uyum Gerekir mi?

Her zaman değil.

Bazı kontroller kurumun mimarisine uygun olmayabilir.

Önemli olan her istisnanın gerekçeli ve risk kabulüyle yönetilmesidir.

Bu nedenle:

Blind Compliance

yerine

Risk-Based Compliance

daha sağlıklı olabilir.

Security Baseline Nedir?

Kurumun cloud kaynakları için minimum güvenlik standardıdır.

Örneğin:

Logging zorunlu.

Encryption zorunlu.

Public storage yasak.

SSH/RDP internetten yasak.

Root MFA zorunlu.

Unmanaged admin account yasak.

Bu baseline cloud governance'ın temelidir.

Policy as Code Misconfiguration'ı Nasıl Önler?

Security policy kod olarak tanımlanır ve deployment sırasında kontrol edilir.

Örneğin Terraform pipeline:

Public database tespit etti.

Deployment başarısız.

Böylece risk production'a çıkmadan engellenir.

Bu Shift Left Cloud Security yaklaşımıdır.

IaC Security Scanning Nedir?

Terraform, CloudFormation, Bicep gibi Infrastructure as Code dosyalarının güvenlik açısından taranmasıdır.

Örneğin;

public port,

unencrypted storage,

wildcard IAM

deployment öncesinde tespit edilebilir.

Bu cloud misconfiguration'ların en erken aşamada yakalanmasını sağlar.

Pre-Deployment ve Runtime Security Arasındaki Fark

Pre-Deployment

IaC veya pipeline aşamasında kontrol edilir.

Runtime

Production ortamında gerçek configuration izlenir.

İkisi de gereklidir.

Çünkü IaC güvenli olsa bile administrator sonradan manuel değişiklik yapabilir.

Drift Detection Nasıl Yapılır?

Current cloud configuration ile desired state karşılaştırılır.

Örneğin Terraform'a göre:

RDP closed.

Gerçek Azure NSG:

RDP public.

Drift alert oluşturulur.

Bu durum güvenlik ekibine hızlı şekilde bildirilebilir.

Auto-Remediation Nedir?

Bazı misconfiguration'lar otomatik düzeltilebilir.

Örneğin public storage tespit edildiğinde policy otomatik olarak public access'i kapatabilir.

Ancak otomatik remediation dikkatli kullanılmalıdır.

İş servisini kesintiye uğratabilir.

Bu nedenle severity ve resource context'e göre uygulanmalıdır.

Auto-Remediation Her Bulguya Uygulanmalı mı?

Hayır.

Örneğin public 443 erişimi web uygulaması için gereklidir.

Sistem bunu yanlışlıkla kapatırsa hizmet kesilir.

Bu nedenle otomasyon;

yüksek güvenli,

iyi tanımlanmış,

geri alınabilir

kontroller için daha uygundur.

Preventive Control ile Detective Control Arasındaki Fark

Preventive Control

Riskli konfigürasyonun oluşmasını engeller.

Örneğin Policy as Code.

Detective Control

Risk oluştuktan sonra tespit eder.

Örneğin CSPM.

İdeal model her ikisini birlikte kullanır.

Corrective Control Nedir?

Bulgu tespit edildikten sonra sistemi güvenli hale getiren kontroldür.

Örneğin;

public bucket private yapılır,

IAM role küçültülür,

logging açılır.

Bu üç yaklaşım birlikte düşünülebilir:

Prevent → Detect → Correct

Cloud Misconfiguration Alert Fatigue Nedir?

CSPM binlerce bulgu üretebilir.

Örneğin 20.000 adet low-severity finding.

Security ekipleri bunların tamamıyla ilgilenemez.

Bu durum Alert Fatigue oluşturur.

Bu nedenle findings risk bazlı önceliklendirilmelidir.

Risk-Based Prioritization Nasıl Yapılır?

Bir misconfiguration için şu faktörler birlikte değerlendirilebilir:

Internet Exposure

Public mi?

Asset Criticality

Production mı?

Identity Privilege

Workload yüksek yetkili mi?

Data Sensitivity

Hassas veri var mı?

Exploitability

Aktif saldırı yolu var mı?

Bu bilgiler risk skorunu daha anlamlı hale getirir.

“Public + Privileged + Sensitive” Modeli

Cloud security için basit ama güçlü bir önceliklendirme modeli düşünülebilir.

Bir resource aynı anda:

Public

internete açık,

Privileged

yüksek yetkili identity'ye sahip,

Sensitive

hassas veriye erişebiliyor

ise çok yüksek risklidir.

Bu üçlü modern cloud attack path analizinin temel mantıklarından biridir.

Shadow Cloud Misconfiguration Riskini Nasıl Artırır?

Security ekibinin bilmediği account veya subscription'da security baseline uygulanamaz.

Logging olmayabilir.

MFA olmayabilir.

Public kaynaklar bulunabilir.

Bu nedenle cloud organization envanteri çıkarılmalıdır.

Cloud Asset Discovery Nasıl Yapılır?

Organization/account API'leri,

CSPM,

ASM/EASM,

CMDB integration

kullanılabilir.

Amaç şu soruya cevap vermektir:

“Kurumun sahip olduğu tüm cloud kaynaklarını gerçekten biliyor muyuz?”

Bu cevap hayırsa misconfiguration yönetimi eksik kalır.

Ephemeral Resource'lar Neden Zor?

Container, serverless function veya kısa ömürlü VM birkaç dakika içerisinde oluşturulup silinebilir.

Geleneksel aylık vulnerability taraması bunları göremeyebilir.

Bu nedenle cloud-native güvenlik sürekli ve API tabanlı olmalıdır.

Serverless Misconfiguration Örnekleri

Serverless function;

public trigger'a sahip olabilir,

yüksek privilege role kullanabilir,

secret environment variable içerebilir,

logging kapalı olabilir.

İşletim sistemi yönetilmiyor olsa bile configuration riski devam eder.

Kubernetes Misconfiguration Cloud Security'nin Parçası mı?

Kesinlikle.

Managed Kubernetes kullanılsa bile;

public API server,

overprivileged RBAC,

open dashboard,

privileged container,

missing network policy

gibi riskler bulunabilir.

Kubernetes ayrıca kendi security posture değerlendirmesini gerektirir.

Container Misconfiguration Örnekleri

Container;

root user ile çalışabilir,

privileged mode kullanabilir,

host filesystem mount edebilir,

gereksiz capability alabilir.

Bu yanlış konfigürasyonlar runtime saldırı etkisini artırabilir.

Secrets in Kubernetes Neden Kritik?

Kubernetes Secrets belirli uygulama credential'larını saklayabilir.

Yanlış RBAC nedeniyle çok sayıda pod veya kullanıcı secret okuyabilir.

Bu durumda cloud IAM güvenli olsa bile cluster içerisinden sensitive credential erişimi oluşabilir.

Public API Misconfiguration

API Gateway veya public endpoint;

authentication olmadan,

rate limit olmadan,

gereğinden geniş CORS ile

çalışabilir.

Bu durum abuse veya data exposure oluşturabilir.

Cloud misconfiguration yalnızca infrastructure katmanında değildir.

Application edge konfigürasyonları da değerlendirilmelidir.

CORS Misconfiguration Nedir?

Cross-Origin Resource Sharing – CORS, browser tabanlı cross-origin erişimi kontrol eder.

Aşırı geniş CORS policy bazı uygulamalarda veri erişimi riskini artırabilir.

Ancak CORS tek başına authentication mekanizması değildir.

Bu nedenle application context içinde değerlendirilmelidir.

Cloud Load Balancer Misconfiguration

Load balancer;

backend'i yanlışlıkla public bırakabilir,

TLS policy zayıf olabilir,

management endpoint açabilir,

health endpoint hassas bilgi verebilir.

Bu nedenle edge bileşenleri de CSPM veya architecture review kapsamına alınmalıdır.

TLS Misconfiguration Cloud'da Nasıl Görülür?

Eski TLS version,

zayıf cipher,

yanlış certificate,

expired certificate

cloud load balancer veya gateway üzerinde bulunabilir.

Bu nedenle cloud posture yalnızca IAM ve network'ten oluşmaz.

Cryptographic configuration da önemlidir.

DNS Misconfiguration Cloud Security'yi Etkiler mi?

Evet.

Örneğin stale DNS record eski cloud resource'a işaret edebilir.

Resource silinmiş ama DNS kaydı kalmış olabilir.

Bu durum bazı senaryolarda Subdomain Takeover riskine yol açabilir.

Bu nedenle cloud lifecycle ile DNS lifecycle senkron yönetilmelidir.

Dangling DNS Record Nedir?

DNS kaydı artık var olmayan cloud kaynağına işaret ediyorsa Dangling DNS Record oluşabilir.

Saldırgan aynı cloud resource isminden yeniden sahiplik alabiliyorsa subdomain'i ele geçirebilir.

Bu nedenle resource silinirken DNS kaydı da temizlenmelidir.

Subdomain Takeover Neden Cloud Misconfiguration Sayılabilir?

Sorun çoğu zaman cloud provider açığından kaynaklanmaz.

Resource lifecycle yönetimindeki hatadan kaynaklanır.

Cloud service silinir.

DNS kalır.

Bu nedenle configuration ve asset lifecycle security birlikte ele alınmalıdır.

Resource Lifecycle Nedir?

Cloud resource'un;

oluşturulması,

kullanılması,

değiştirilmesi,

kapatılması,

silinmesi

süreçlerini kapsar.

Güvenlik bu yaşam döngüsünün tamamında uygulanmalıdır.

Özellikle kullanılmayan resource'ların kaldırılması saldırı yüzeyini azaltır.

Zombie Resource Nedir?

Artık kullanılmayan ancak hâlâ çalışan cloud kaynağına bazen Zombie Resource denir.

Örneğin eski test VM.

Kimse sahibi değil.

Patch almıyor.

Public IP'si var.

Bu tür kaynaklar saldırgan için ideal hedef olabilir.

Orphaned Cloud Resource Nedir?

Sahibi veya business purpose'u belli olmayan cloud kaynağıdır.

Security bulgusu oluştuğunda kimin düzeltmesi gerektiği bilinmez.

Bu nedenle tagging ve ownership cloud governance açısından kritik öneme sahiptir.

Cloud Tagging Security'yi Nasıl Güçlendirir?

Resource'lar;

owner,

environment,

criticality,

data classification,

application

ile tag'lenebilir.

Böylece CSPM finding risk bağlamıyla birlikte değerlendirilir.

Örneğin:

Public VM + Production + Payment

çok daha yüksek öncelik alabilir.

Misconfiguration SLA Nedir?

Kritik yapılandırma hatalarının ne kadar sürede düzeltilmesi gerektiği tanımlanabilir.

Örneğin:

Critical → 24 saat

High → 7 gün

Medium → 30 gün

gibi.

Ancak süreler kurumun kendi risk modeline göre belirlenmelidir.

Exposure Window Nedir?

Bir güvenlik probleminin oluşması ile düzeltilmesi arasında geçen süredir.

Örneğin:

Public bucket açıldı → 1 Ağustos

Tespit edildi → 3 Ağustos

Düzeltildi → 10 Ağustos

Exposure window 9 gündür.

Bu süre risk açısından önemli KPI olabilir.

Mean Time to Remediate Nedir?

MTTR – Mean Time to Remediate, güvenlik bulgularının ortalama düzeltme süresini ölçer.

Cloud ortamında değişim hızlı olduğu için özellikle değerlidir.

Ancak yalnızca ortalama MTTR yerine critical finding MTTR ayrıca takip edilmelidir.

CSPM Finding Owner Kim Olmalı?

Security ekibi bütün bulguları kendisi düzeltemez.

Resource sahibi;

Cloud Team,

DevOps,

Application Team,

Database Team

olabilir.

Bu nedenle CSPM finding'lerinin otomatik olarak doğru owner'a atanması remediation sürecini hızlandırır.

Security ile DevOps Arasında Sorumluluk Nasıl Paylaşılmalı?

Security policy ve risk kriterlerini belirleyebilir.

DevOps veya platform ekipleri teknik remediation yapabilir.

Application owner riskin iş etkisini doğrulayabilir.

Bu model Shared Security Responsibility şeklinde düşünülebilir.

Cloud Misconfiguration Incident Response Gerektirir mi?

Her misconfiguration incident değildir.

Ancak kritik exposure uzun süre açık kalmışsa:

Saldırgan erişmiş olabilir mi?

sorusu araştırılmalıdır.

Örneğin public storage tespit edildi.

Sadece private yapmak yeterli olmayabilir.

Access logs incelenmelidir.

Public Bucket Bulunduğunda Ne Yapılmalı?

Genel süreç:

Exposure doğrulanır.

Business requirement kontrol edilir.

Gerekirse public access kapatılır.

Access loglar incelenir.

Hassas veri olup olmadığı belirlenir.

Unauthorized download araştırılır.

Gerekirse Incident Response başlatılır.

Yani remediation ile investigation birlikte düşünülmelidir.

Access Log Yoksa Ne Olur?

Bu durumda exposure'ın kötüye kullanılıp kullanılmadığını belirlemek zorlaşır.

Bu da logging misconfiguration'ın neden ciddi olduğunu gösterir.

Cloud security'de:

Prevention + Detection + Forensics

birlikte düşünülmelidir.

Cloud Misconfiguration Assessment Nedir?

Cloud Misconfiguration Assessment, cloud kaynaklarının güvenlik baseline'larına ve gerçek risk bağlamına göre sistematik değerlendirilmesidir.

Bu çalışma;

IAM,

network,

storage,

logging,

encryption,

backup,

DNS,

workload

alanlarını kapsayabilir.

Ama sadece compliance checklist değildir.

Attack path ve business impact de incelenmelidir.

Cloud Configuration Assessment Nasıl Yapılır?

Genel akış şöyle olabilir:

1. Cloud Asset Discovery

Kaynaklar çıkarılır.

2. Baseline Selection

CIS ve kurum policy'si belirlenir.

3. Configuration Scan

Yanlış ayarlar bulunur.

4. Exposure Analysis

Public kaynaklar tespit edilir.

5. Identity Context

Resource'un permission'ları incelenir.

6. Data Context

Hassas veri olup olmadığı belirlenir.

7. Attack Path Analysis

Bulgular ilişkilendirilir.

8. Risk Prioritization

Gerçek risk sıralanır.

9. Remediation

Düzeltmeler yapılır.

10. Retest

Kontroller yeniden doğrulanır.

Cloud Misconfiguration Pentest ile Aynı Şey midir?

Hayır.

Misconfiguration Assessment;

konfigürasyonları analiz eder.

Cloud Penetration Test ise bu yanlış yapılandırmaların gerçek saldırı yoluna dönüşüp dönüşmediğini kontrollü şekilde test edebilir.

Örneğin assessment:

Public VM + privileged identity buldu.

Pentest:

Bu VM üzerinden cloud credential elde edilip kritik storage'a ulaşılabiliyor mu?

sorusunu test edebilir.

Cloud Misconfiguration Raporunda Neler Olmalıdır?

Profesyonel rapor şu bölümleri içerebilir:

Executive Summary

Yönetim için risk görünümü.

Cloud Inventory

Account, subscription ve resource yapısı.

Critical Misconfigurations

En önemli yanlış yapılandırmalar.

Public Exposure

İnternete açık kaynaklar.

Identity Context

IAM ve privilege bağlantıları.

Data Exposure

Hassas veri riski.

Configuration Drift

Baseline'dan sapmalar.

Attack Paths

Birleşik saldırı yolları.

Compliance Mapping

CIS ve kurum policy'si.

Remediation Roadmap

Önceliklendirilmiş aksiyonlar.

Bu yapı binlerce finding'i yönetilebilir hale getirir.

Cloud Misconfiguration KPI'ları Nelerdir?

Örneğin;

Critical Misconfiguration Count

Public Resource Count

Public Sensitive Resource Count

Configuration Drift Count

Policy Violation Count

Mean Time to Remediate

Critical Exposure Window

Auto-Remediation Rate

CSPM Coverage

gibi metrikler kullanılabilir.

Ancak hedef “bulgu sayısını sıfırlamak” değil, gerçek riskli exposure'ları azaltmak olmalıdır.

Cloud Misconfiguration Security Score Kullanılabilir mi?

Evet.

Örneğin:

IAM Configuration – 82/100

Network Exposure – 65/100

Storage Security – 91/100

Logging – 76/100

Ancak tek bir kritik public database bütün ortalama skordan daha önemli olabilir.

Bu nedenle skor mutlaka kritik findings ile birlikte gösterilmelidir.

Cloud Misconfiguration'da En Büyük Hata Nedir?

En yaygın hata:

Yılda bir kere cloud audit yapmak.

Cloud ortamı her gün değişebilir.

Bugün güvenli olan account yarın;

yeni public IP,

yeni IAM role,

yeni bucket,

yeni database

içerebilir.

Bu nedenle cloud configuration security sürekli olmalıdır.

Continuous Cloud Posture Management Nedir?

Cloud security posture'un periyodik değil sürekli izlenmesidir.

Yeni resource oluşturulduğu anda security policy kontrol edilir.

Yeni public exposure anında alarm üretir.

Yeni admin role görünür hale gelir.

Bu model cloud'un dinamik yapısına daha uygundur.

Prevent, Detect, Respond Modeli

Cloud misconfiguration yönetimi üç aşamalı düşünülebilir:

Prevent

Policy as Code ve guardrail.

Detect

CSPM ve CNAPP.

Respond

Auto-remediation veya ticket workflow.

Ancak bunun üzerine bir katman daha eklenmelidir:

Validate

Düzeltmenin gerçekten riski kapattığı doğrulanmalıdır.

Cloud Security Guardrail Nedir?

Developer'ın güvenli olmayan konfigürasyon oluşturmasını baştan engelleyen merkezi kuraldır.

Örneğin:

Production database public olamaz.

Public storage oluşturulamaz.

Root access key oluşturulamaz.

Security logging kapatılamaz.

Bu yaklaşım insan hatasının etkisini azaltır.

Cloud Misconfiguration ile DevSecOps Arasındaki İlişki

Misconfiguration'ların önemli bir bölümü deployment sırasında oluşabilir.

Bu nedenle DevSecOps pipeline içerisinde;

IaC Scan,

Policy as Code,

Secret Scan,

Container Scan

çalıştırılabilir.

Amaç problemi production'a çıktıktan sonra değil, commit veya deployment öncesinde görmek olmalıdır.

Shift Left Tek Başına Yeterli mi?

Hayır.

Kod güvenli olabilir.

Ama production'da manuel değişiklik yapılabilir.

Bu nedenle:

Shift Left + Runtime CSPM

birlikte kullanılmalıdır.

Birisi problemi oluşmadan engeller.

Diğeri production'daki gerçek durumu izler.

Sonuç: Cloud Güvenliğinde En Tehlikeli Açık Bazen Bir CVE Değil, Tek Bir Yanlış Ayardır

Cloud ortamlarında güvenlik problemi her zaman karmaşık değildir.

Bazen tek bir checkbox yeterlidir.

Public Access: Enabled

Bazen tek bir rule:

0.0.0.0/0 → SSH

Bazen tek bir policy:

Administrator Access

Bazen tek bir seçim:

Audit Logging: Disabled

Bu nedenle Cloud Misconfiguration modern bulut güvenliğinin en kritik risk alanlarından biridir.

Ancak asıl problem yanlış konfigürasyonun oluşması değildir.

İnsanlar hata yapabilir.

Asıl problem:

Hatanın fark edilmeden uzun süre production'da kalmasıdır.

Bu nedenle güçlü cloud posture yaklaşımı;

Security Baseline

↓

Policy as Code

↓

IaC Security

↓

CSPM

↓

CNAPP

↓

Attack Path Analysis

↓

Risk-Based Remediation

↓

Continuous Validation

döngüsüyle yönetilmelidir.

Ve en önemli soru sadece:

“Kaç misconfiguration var?”

olmamalıdır.

Daha değerli sorular şunlardır:

Hangisi internete açık?

Hangisi kritik production sisteminde?

Hangisi yüksek yetkili identity ile çalışıyor?

Hangisi hassas veriye erişiyor?

Hangileri birleştiğinde gerçek saldırı yolu oluşturuyor?

Bu yaklaşım cloud security'yi binlerce compliance maddesinden çıkarıp gerçek risk yönetimine dönüştürür.

Ancak modern cloud altyapılarının önemli bir bölümü artık klasik sanal makinelerden oluşmuyor.

Uygulamalar;

Docker container'ları,

Kubernetes cluster'ları,

managed container servisleri

üzerinde çalışıyor.

Bu da sistem ve bulut güvenliğinin bir sonraki önemli alanını oluşturuyor:

Container ve Kubernetes Security.