CSPM, CWPP ve CNAPP Nedir? Modern Cloud Security Platformları Nasıl Çalışır?

Cloud ortamları büyüdükçe güvenlik ekiplerinin karşısına yeni bir problem çıkar:

Çok fazla kaynak, çok fazla servis ve çok fazla güvenlik sinyali.

Bir tarafta AWS hesapları.

Bir tarafta Azure subscription'ları.

Başka bir tarafta Google Cloud project'leri.

Bunların üzerinde;

virtual machine'ler,

container'lar,

Kubernetes cluster'ları,

serverless uygulamalar,

storage servisleri,

IAM roller,

secret'lar,

database'ler

çalışabilir.

Her platform kendi güvenlik alarmını üretir.

Her ürün kendi dashboard'unu oluşturur.

Sonuçta kurum şu soruyla karşılaşır:

“Gerçekten kritik olan risk hangisi?”

İşte CSPM, CWPP, CIEM, KSPM, DSPM ve CNAPP gibi modern cloud security kavramları tam olarak bu problemi çözmeye çalışır.

Ama bu terimler çoğu zaman birbirine karıştırılır.

CSPM ne yapar?

CWPP ile EDR arasındaki fark nedir?

CIEM neden gerekir?

CNAPP gerçekten hepsinin yerini alır mı?

Daha da önemlisi:

Bu platformlar yalnızca binlerce alarm mı üretir, yoksa gerçek saldırı yollarını gösterebilir mi?

Modern cloud security yaklaşımının asıl değeri burada ortaya çıkar.

CSPM Nedir?

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

CSPM temel olarak şu soruya cevap verir:

“Cloud kaynaklarımız güvenli şekilde yapılandırılmış mı?”

Örneğin CSPM şu riskleri tespit edebilir:

• Public storage
• İnternete açık RDP veya SSH
• Public database
• Encryption eksikliği
• Audit logging kapalı olması
• MFA eksikliği
• Security Group yanlış yapılandırmaları
• IAM policy problemleri
• Backup veya snapshot riskleri

CSPM'in temel gücü cloud ortamını sürekli olarak değerlendirmesidir.

Çünkü cloud ortamı statik değildir.

Bugün güvenli olan yapı yarın değişebilir.

CSPM Neden Gereklidir?

Geleneksel data center ortamında altyapı nispeten daha yavaş değişir.

Cloud'da ise developer birkaç dakika içinde yeni;

VM,

storage,

database,

load balancer

oluşturabilir.

Manuel güvenlik review bu hıza yetişemez.

CSPM cloud API'lerini analiz ederek yeni oluşan riskleri daha hızlı görünür hale getirebilir.

Bu nedenle CSPM'in temel amacı:

Continuous Cloud Posture Visibility

sağlamaktır.

CSPM Sadece Compliance İçin midir?

Hayır.

CSPM platformları;

CIS Benchmark,

ISO 27001,

PCI DSS,

NIST

gibi standartlarla mapping yapabilir.

Ancak iyi bir CSPM sadece:

“Bu kontrol başarısız.”

dememelidir.

Aynı zamanda:

“Bu başarısızlık gerçek saldırı açısından ne kadar önemli?”

sorusunu cevaplamaya çalışmalıdır.

Bu nedenle modern CSPM araçları risk context eklemeye başlamıştır.

CWPP Nedir?

Cloud Workload Protection Platform – CWPP, cloud üzerinde çalışan workload'ların güvenliğine odaklanan platform kategorisidir.

Workload;

virtual machine,

container,

Kubernetes workload,

serverless function

olabilir.

CWPP temel olarak şu soruya cevap verir:

“Cloud üzerinde çalışan sistemler runtime sırasında güvenli mi?”

Bu nedenle CWPP;

malware,

runtime attack,

process behavior,

vulnerability,

file activity,

container activity

gibi alanlara odaklanabilir.

CSPM ile CWPP Arasındaki Fark Nedir?

Basit şekilde:

CSPM → Konfigürasyona bakar.

CWPP → Çalışan workload'a bakar.

Örneğin:

CSPM:

“Bu VM'in SSH portu internete açık.”

CWPP:

“Bu VM üzerinde şüpheli process çalışıyor.”

Birincisi posture problemidir.

İkincisi runtime davranıştır.

Bu nedenle iki teknoloji birbirinin alternatifi değildir.

CWPP ile EDR Arasındaki Fark Nedir?

Bu iki kavram belirli alanlarda kesişebilir.

EDR – Endpoint Detection and Response

özellikle endpoint ve server üzerinde;

process,

file,

network,

registry,

malware

davranışlarını izler.

CWPP

ise cloud workload dünyasına daha geniş açıdan bakabilir.

Örneğin;

VM,

container,

Kubernetes,

serverless

gibi farklı workload tiplerini kapsayabilir.

Bazı platformlarda EDR ve CWPP fonksiyonları ciddi ölçüde birleşmiştir.

Bu nedenle ürün isimlerinden çok gerçek teknik kapsam değerlendirilmelidir.

CWPP Container Güvenliğinde Nasıl Çalışır?

Container runtime sırasında;

shell açılması,

şüpheli process,

network connection,

privilege escalation,

file modification

gibi davranışları izleyebilir.

Örneğin normalde sadece Java process çalıştırması gereken container içinde:

bash

veya

curl

çalışmaya başlarsa bu anomali olabilir.

Bu runtime detection açısından değerlidir.

CWPP Serverless Ortamları Koruyabilir mi?

Bazı platformlar serverless workload'lar için de visibility sağlayabilir.

Ancak serverless mimarilerde klasik agent yüklemek mümkün olmayabilir.

Bu nedenle;

cloud telemetry,

function behavior,

API activity,

runtime instrumentation

gibi farklı yöntemler kullanılabilir.

Burada platformun gerçek teknik kabiliyeti ayrıca değerlendirilmelidir.

KSPM Nedir?

Kubernetes Security Posture Management – KSPM, Kubernetes cluster'larının güvenlik yapılandırmalarını sürekli analiz eden yaklaşımıdır.

KSPM şu riskleri tespit edebilir:

privileged pod,

root container,

open API server,

weak RBAC,

missing Network Policy,

dangerous hostPath,

overprivileged service account.

KSPM, CSPM'in Kubernetes'e daha detaylı bakan uzantısı gibi düşünülebilir.

Kubernetes Security Neden CSPM'den Ayrı Değerlendiriliyor?

Çünkü Kubernetes'in kendi;

RBAC,

pod,

namespace,

service account,

secret,

network policy

modeli vardır.

Cloud provider güvenli olsa bile cluster içinde ciddi riskler bulunabilir.

Örneğin AWS account tamamen güvenli olabilir.

Ama EKS cluster içerisinde bir developer cluster-admin olabilir.

CSPM bunu tek başına yeterince detaylı yorumlamayabilir.

Bu nedenle KSPM gereklidir.

CIEM Nedir?

Cloud Infrastructure Entitlement Management – CIEM, cloud ortamındaki kimlik ve yetkileri analiz etmeye odaklanan güvenlik yaklaşımıdır.

Temel soru şudur:

“Kim hangi yetkiye sahip ve gerçekten bu yetkilere ihtiyacı var mı?”

CIEM;

human identity,

service account,

role,

workload identity,

permission

ilişkilerini analiz edebilir.

CIEM Neden Ortaya Çıktı?

Cloud IAM son derece karmaşık olabilir.

Bir kullanıcı;

direct role,

group membership,

inherited permission,

resource policy,

cross-account trust

üzerinden çok farklı yetkiler elde edebilir.

Tek tek policy okumak gerçek privilege seviyesini anlamak için yeterli değildir.

CIEM effective permission görünürlüğü sağlar.

CIEM Overprivilege'ı Nasıl Bulur?

Örneğin bir service account:

400 permission'a sahip.

Ama son 90 günde yalnızca 20 permission kullanmış.

CIEM:

“Bu identity ciddi şekilde overprivileged olabilir.”

diyebilir.

Bu yaklaşım Permission Rightsizing için kullanılır.

Ama kritik emergency permission'lar nedeniyle otomatik küçültme dikkatli yapılmalıdır.

DSPM Nedir?

Data Security Posture Management – DSPM, hassas verinin nerede bulunduğunu, kimlerin erişebildiğini ve hangi risk altında olduğunu analiz etmeye odaklanır.

Örneğin DSPM:

Bu storage içerisinde müşteri verisi var.

Bu database kişisel veri içeriyor.

Bu bucket'ta finansal kayıt var.

diyebilir.

Bu bilgi cloud risk önceliklendirmesini ciddi şekilde değiştirir.

CSPM ile DSPM Arasındaki Fark

CSPM:

“Bu storage public.”

der.

DSPM:

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

der.

Birleştirildiğinde:

Public + Sensitive Data

çok daha kritik risk oluşturur.

Bu nedenle modern cloud security data context olmadan eksik kalabilir.

CNAPP Nedir?

Cloud-Native Application Protection Platform – CNAPP, farklı cloud security yeteneklerini tek bir platform altında birleştirmeyi amaçlayan modern güvenlik yaklaşımıdır.

Bir CNAPP içerisinde;

CSPM,

CWPP,

CIEM,

KSPM,

IaC Security,

Container Security,

Attack Path Analysis

gibi yetenekler bulunabilir.

Bazı platformlar buna DSPM veya code security özelliklerini de ekleyebilir.

Temel hedef:

Cloud risklerini parçalı değil, bütünsel görmek.

CNAPP Neden Ortaya Çıktı?

Cloud security başlangıçta farklı ürünlerle yönetiliyordu.

Bir ürün CSPM.

Başka ürün container security.

Başka ürün IAM.

Başka ürün runtime.

Security ekipleri onlarca dashboard kullanmak zorunda kalıyordu.

Daha büyük problem ise bulguların birbirine bağlanamamasıydı.

Örneğin;

CSPM → public VM.

Vulnerability Scanner → kritik CVE.

CIEM → yüksek yetkili role.

DSPM → hassas veri.

Bu bulgular dört farklı yerde görünüyordu.

Oysa saldırgan açısından tek hikâyedir.

CNAPP Bu Bulguları Nasıl Birleştirir?

Örneğin:

Internet-Facing VM

↓

Critical Vulnerability

↓

Privileged Managed Identity

↓

Secret Vault Access

↓

Production Database

↓

Sensitive Customer Data

Bu zincir tek bir Cloud Attack Path olarak görülebilir.

İşte CNAPP'in gerçek potansiyeli burada ortaya çıkar.

Attack Path Analysis Nedir?

Attack Path Analysis, saldırganın düşük yetkili veya dışarı açık bir başlangıç noktasından kritik kaynağa nasıl ulaşabileceğini analiz eder.

Bu yaklaşım tekil bulgular yerine ilişkileri değerlendirir.

Örneğin:

Public asset.

Vulnerability.

Identity.

Permission.

Data.

Hepsi bir saldırı yolu oluşturabilir.

Bu nedenle modern cloud security'de attack path analizi giderek daha önemli hale gelmektedir.

Attack Path ile Vulnerability Aynı Şey midir?

Hayır.

Vulnerability tek bir teknik zayıflıktır.

Attack path ise birden fazla zayıflığın birleşimidir.

Örneğin:

Critical CVE var.

Ama private network'te ve düşük yetkili workload.

Risk sınırlı olabilir.

Başka bir sistemde orta seviye CVE vardır.

Ama;

public,

privileged,

sensitive data access

özelliklerine sahiptir.

Gerçek risk ikinci sistemde daha yüksek olabilir.

Toxic Combination Nedir?

Toxic Combination, tek başına orta veya düşük görünen birden fazla riskin birleşerek kritik saldırı yolu oluşturmasıdır.

Örneğin:

Public VM

Weak Application Configuration

High-Privilege Identity

Secret Access

Sensitive Database

Bu kombinasyon kritik olabilir.

Modern CNAPP sistemleri bu tür ilişkileri görünür hale getirmeye çalışır.

“Public + Vulnerable + Privileged” Modeli Nedir?

Cloud security'de basit ama güçlü risk modeli olabilir.

Bir workload:

Public

internete açık,

Vulnerable

istismar edilebilir güvenlik açığına sahip,

Privileged

yüksek yetkili cloud identity kullanıyorsa

çok yüksek risklidir.

Buna sensitive data context de eklenirse öncelik daha da artar.

Exposure Management CNAPP'in Parçası mıdır?

Modern cloud security platformları giderek Exposure Management yaklaşımına ilerlemektedir.

Amaç sadece bulgu üretmek değil;

hangi varlığın saldırgan tarafından ulaşılabilir olduğunu,

hangi attack path'in kritik varlığa ulaştığını

anlamaktır.

Bu nedenle cloud security ile attack surface management giderek yakınlaşmaktadır.

CNAPP ile ASM Arasındaki Fark

Attack Surface Management – ASM

dışarıdan görünen asset'lere odaklanabilir.

CNAPP

cloud environment içindeki configuration, identity ve workload ilişkilerine daha derin bakar.

Birlikte kullanıldığında:

Outside-In + Inside-Out

görünürlük sağlanabilir.

EASM Nedir?

External Attack Surface Management – EASM, kurumun internetten görünen;

domain,

IP,

cloud service,

application

varlıklarını sürekli keşfetmeye çalışır.

Örneğin unutulmuş bir cloud VM EASM tarafından bulunabilir.

CNAPP daha sonra bu VM'in cloud içindeki privilege ilişkilerini gösterebilir.

CNAPP ile Vulnerability Management Nasıl Birleşir?

CNAPP yalnızca CVE listesi göstermemelidir.

Vulnerability'yi cloud context ile ilişkilendirmelidir.

Örneğin:

CVE Critical.

Ama workload public değil.

Identity düşük privilege.

Sensitive data yok.

Risk orta olabilir.

Başka CVE High.

Public workload.

Admin identity.

Critical database access.

Risk kritik olabilir.

Bu yaklaşım Contextual Vulnerability Management'tır.

Contextual Risk Nedir?

Bir bulgunun riskini sadece kendi severity'si değil, çevresindeki bağlam belirler.

Bağlam;

internet exposure,

asset criticality,

identity privilege,

data sensitivity,

exploitability

olabilir.

Bu yaklaşım güvenlik ekiplerinin yanlış önceliklendirmesini azaltır.

EPSS ve Exploitability Cloud Riskinde Kullanılır mı?

Vulnerability önceliklendirmesinde;

CVSS,

EPSS,

known exploited status,

threat intelligence

gibi faktörler kullanılabilir.

Ancak cloud context de eklenmelidir.

Örneğin aktif exploit edilen vulnerability public workload üzerinde bulunuyorsa öncelik çok yüksektir.

IaC Security CNAPP İçinde Ne İşe Yarar?

Infrastructure as Code dosyaları production öncesinde analiz edilebilir.

Örneğin Terraform:

public database,

open SSH,

unencrypted storage,

wildcard IAM

oluşturacaksa deployment öncesinde tespit edilebilir.

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

Runtime CSPM Neden Hâlâ Gerekli?

IaC güvenli olabilir.

Ama administrator portal üzerinden manuel değişiklik yapabilir.

Bu nedenle production'daki gerçek config ayrıca izlenmelidir.

İdeal model:

IaC Security + Runtime CSPM

şeklindedir.

CNAPP Shift Left ve Shift Right'ı Birleştirir mi?

İdeal CNAPP yaklaşımı cloud security lifecycle'ın tamamını kapsayabilir:

Code

IaC scanning.

↓

Build

Container image security.

↓

Deploy

Admission control.

↓

Cloud Posture

CSPM/KSPM.

↓

Runtime

CWPP.

↓

Identity

CIEM.

↓

Data

DSPM.

Bu nedenle CNAPP yalnızca production security ürünü değildir.

CNAPP DevSecOps İçin Nasıl Kullanılır?

Security findings developer workflow'una entegre edilebilir.

Örneğin;

Pull Request açılır.

IaC risk tespit edilir.

Developer kod seviyesinde remediation alır.

Production'a çıkmadan problem düzeltilir.

Bu şekilde security ekipleri yalnızca ticket üretmek yerine development sürecine dahil olur.

CNAPP Agent Kullanır mı?

Platforma göre değişir.

Bazı yetenekler agentless olabilir.

Cloud API üzerinden konfigürasyon ve asset görünürlüğü alınabilir.

Runtime security için agent, sensor veya eBPF gerekebilir.

Bu nedenle CNAPP değerlendirirken:

Agentless görünürlük mü?

Runtime protection var mı?

ayrımı önemlidir.

Agentless CNAPP Nedir?

Cloud provider API ve snapshot mekanizmaları üzerinden workload ve configuration analiz edebilir.

Avantajları;

hızlı deployment,

düşük operasyonel yük,

geniş asset coverage

olabilir.

Ancak gerçek-time runtime behavior için sınırlı kalabilir.

Agent-Based CWPP Neden Gereklidir?

Runtime'da;

process,

network,

file,

memory

davranışlarını gerçek zamanlı görmek için host/container üzerinde sensor gerekebilir.

Bu daha derin telemetry sağlar.

Ama agent management operasyonel yük oluşturabilir.

Bu nedenle hibrit yaklaşım yaygındır.

eBPF CNAPP İçinde Nasıl Kullanılır?

Container ve Kubernetes runtime activity'sini kernel seviyesinde izlemek için eBPF kullanılabilir.

Örneğin;

process execution,

network connection,

system call

telemetry'si alınabilir.

Bu özellikle container runtime security için değerlidir.

CNAPP Misconfiguration'ı Otomatik Düzeltebilir mi?

Bazı platformlar Auto-Remediation sağlayabilir.

Örneğin public bucket otomatik private hale getirilebilir.

Ancak otomasyon her durumda güvenli değildir.

Yanlış remediation production kesintisine yol açabilir.

Bu nedenle otomasyon:

yüksek güvenli,

iyi test edilmiş,

rollback'li

kontrollerde tercih edilmelidir.

CNAPP Guardrail Nedir?

Riskli yapılandırmanın oluşmasını baştan engelleyen policy'dir.

Örneğin:

Public database oluşturulamaz.

Unencrypted storage yasak.

Privileged container yasak.

Root access key oluşturulamaz.

Bu preventive security yaklaşımıdır.

Policy as Code CNAPP İçinde Nasıl Kullanılır?

Cloud security politikaları kod olarak tanımlanabilir.

Örneğin:

“Production namespace'te privileged container çalışamaz.”

“Database yalnızca private subnet'te olabilir.”

Bu kurallar;

CI/CD,

admission control,

cloud policy

üzerinden enforce edilebilir.

CNAPP ile SIEM Arasındaki Fark Nedir?

CNAPP cloud posture, identity ve workload security'ye odaklanır.

SIEM ise daha geniş kurum telemetry'sini merkezi olarak toplar ve korele eder.

Örneğin CNAPP:

“Cloud service account privilege escalation riski var.”

diyebilir.

SIEM:

“Aynı service account az önce şüpheli API aktivitesi yaptı.”

diyebilir.

Bu nedenle ikisi birbirini tamamlar.

CNAPP ile XDR Arasındaki Fark

XDR;

endpoint,

identity,

email,

network

gibi tehdit telemetry'sini korele eder.

CNAPP daha çok cloud-native risk ve workload context'e odaklanır.

Bazı vendor'lar bu alanları tek platformda birleştirmektedir.

Ancak kurum teknik kapsamı ürün isminden bağımsız değerlendirmelidir.

CNAPP ile SOAR Entegrasyonu Neden Önemlidir?

CNAPP finding oluştuğunda otomatik workflow başlatılabilir.

Örneğin:

Critical public database tespit edildi.

↓

SOAR ticket açtı.

↓

Cloud owner bilgilendirildi.

↓

Security Group geçici sınırlandırıldı.

↓

SOC olay kontrolü yaptı.

Bu remediation süresini azaltabilir.

Cloud Security Finding Owner Nasıl Belirlenir?

En büyük operasyonel problemlerden biri:

“Bu bulguyu kim düzeltecek?”

sorusudur.

Resource metadata ve tag'ler kullanılarak;

application owner,

DevOps,

platform team,

database team

otomatik belirlenebilir.

CNAPP'in operasyonel başarısı burada da ölçülmelidir.

CNAPP Ticket Flood Oluşturabilir mi?

Evet.

Yanlış yapılandırılmış platform binlerce ticket üretirse ekipler sistemi kullanmamaya başlayabilir.

Bu nedenle risk prioritization önemlidir.

Her low severity finding için ticket oluşturmak iyi model değildir.

Alert Fatigue Cloud Security'de Neden Büyük Problemdir?

Bir kurumda;

20.000 misconfiguration,

5.000 vulnerability,

3.000 identity finding

olabilir.

Security ekibinin bunların tamamını düzeltmesi imkânsızdır.

Bu nedenle modern CNAPP:

Finding Management

değil,

Risk Prioritization

platformu olmalıdır.

Risk Prioritization Nasıl Yapılmalıdır?

Örneğin şu faktörler kullanılabilir:

Public Exposure

Known Exploit

Privilege

Sensitive Data

Asset Criticality

Attack Path

Bu faktörler birlikte gerçek risk skorunu oluşturabilir.

Business Context CNAPP'e Eklenmeli mi?

Kesinlikle.

Aynı misconfiguration;

test ortamında düşük risk,

production ödeme sisteminde kritik risk

olabilir.

Bu nedenle;

environment,

business service,

asset owner,

criticality

bilgileri platforma eklenmelidir.

Asset Tagging CNAPP İçin Neden Kritik?

Tag'ler sayesinde CNAPP şunu anlayabilir:

Bu resource:

Production.

Finance.

Critical.

Customer-facing.

Bu bilgi olmadan risk önceliklendirmesi teknik seviyede kalır.

Crown Jewel Mapping Nedir?

Kurumun en kritik varlıklarının platform içerisinde işaretlenmesidir.

Örneğin;

müşteri database'i,

ödeme altyapısı,

identity sistemi,

ERP

Crown Jewel olabilir.

Attack path'lerin bu varlıklara ulaşıp ulaşmadığı ayrıca analiz edilebilir.

Cloud Attack Graph Nedir?

Cloud environment içerisindeki;

identity,

resource,

network,

permission,

data

ilişkilerinin grafik modeliyle gösterilmesidir.

Bu sayede saldırganın hangi yollarla ilerleyebileceği görselleştirilebilir.

Bu yaklaşım Active Directory attack graph mantığına benzerdir.

Blast Radius Nedir?

Bir identity veya resource compromise olduğunda etkilenebilecek alanın büyüklüğüdür.

Örneğin düşük yetkili VM sadece kendi bucket'ına erişiyorsa blast radius küçüktür.

Aynı VM subscription Owner ise blast radius çok büyüktür.

CNAPP bu bağlamı gösterebilir.

Choke Point Nedir?

Birçok attack path'in geçtiği ortak identity veya resource'tur.

Örneğin tek bir overprivileged service account 50 attack path üzerinde bulunabilir.

Bu account'un yetkisini düzeltmek çok büyük risk azaltımı sağlar.

Bu nedenle Choke Point remediation stratejisi oldukça değerlidir.

CNAPP Remediation Roadmap Nasıl Oluşturulmalı?

Bulgu sayısına göre değil risk azaltımına göre.

Örneğin;

Priority 1

Critical Attack Path.

Priority 2

Public + Sensitive Data.

Priority 3

Standing Admin Privilege.

Priority 4

Compliance Drift.

Bu yaklaşım güvenlik yatırımını optimize eder.

Quick Win Cloud Security'de Nedir?

Düşük eforla yüksek risk azaltan aksiyondur.

Örneğin;

public SSH kapatmak,

dormant access key silmek,

MFA açmak,

public bucket private yapmak.

CNAPP bu tür quick win'leri görünür hale getirebilir.

Strategic Cloud Security Improvement Nedir?

Daha uzun vadeli mimari değişikliklerdir.

Örneğin;

Landing Zone kurulması,

PIM/JIT geçişi,

CNAPP deployment,

multi-account logging,

workload identity dönüşümü.

Raporlarda quick win ve strategic action ayrılmalıdır.

CNAPP Security Validation Yapabilir mi?

Bazı platformlar posture ve runtime test yetenekleri sunabilir.

Ancak gerçek güvenlik doğrulaması için;

cloud pentest,

Kubernetes assessment,

Red Team,

Purple Team

gibi çalışmalar yine gerekebilir.

CNAPP:

“Risk var.”

diyebilir.

Yetkilendirilmiş test:

“Bu risk gerçekten exploit edilebilir mi?”

sorusunu doğrulayabilir.

CNAPP Penetrasyon Testinin Yerine Geçer mi?

Hayır.

CNAPP sürekli görünürlük sağlar.

Pentest ise saldırgan perspektifinden aktif doğrulama sağlar.

İkisi birlikte daha güçlüdür.

Örneğin CNAPP attack path bulur.

Pentest kontrollü şekilde path'in gerçek etkisini test eder.

Sonra remediation yapılır.

CNAPP sürekli olarak tekrar oluşup oluşmadığını izler.

Cloud Red Team ile CNAPP Nasıl Birlikte Kullanılır?

Red Team kontrollü cloud attack teknikleri uygular.

CNAPP ve SOC bunları tespit etmeye çalışır.

Örneğin;

credential abuse,

privilege escalation,

secret access,

container compromise.

Tatbikat sonunda detection gap'leri belirlenir.

Bu Purple Team yaklaşımına dönüşebilir.

Purple Team CNAPP İçin Neden Değerli?

Platformun dokümanda “tespit eder” demesi yeterli değildir.

Gerçek senaryoda alarm üretip üretmediği test edilmelidir.

Örneğin controlled privilege escalation yapılır.

CNAPP alert verdi mi?

SIEM'e ulaştı mı?

SOC doğru severity verdi mi?

Bunlar doğrulanabilir.

CNAPP Evaluation Nasıl Yapılmalıdır?

Vendor seçerken yalnızca feature list'e bakılmamalıdır.

Şu sorular sorulabilir:

Kaç cloud provider destekliyor?

CSPM ne kadar derin?

CIEM gerçek effective permission hesaplıyor mu?

Runtime security var mı?

Kubernetes coverage nasıl?

Attack path gösteriyor mu?

DSPM entegrasyonu var mı?

IaC scan var mı?

SIEM/SOAR entegrasyonu nasıl?

False positive oranı nedir?

Bu sorular ürünün gerçek değerini gösterir.

Multi-Cloud CNAPP Neden Önemlidir?

Kurum AWS, Azure ve GCP kullanıyorsa üç ayrı security portalı operasyonu zorlaştırabilir.

CNAPP merkezi risk görünümü sağlayabilir.

Ancak provider-specific detayların kaybolmaması gerekir.

Tek panel kullanmak amacıyla teknik derinlikten vazgeçilmemelidir.

Native Cloud Security mi CNAPP mi?

Cloud provider'ın native security servisleri genellikle platformu çok iyi tanır.

Third-party CNAPP ise multi-cloud merkezi görünürlük sağlayabilir.

Kurum;

mimari,

ekip,

maliyet,

entegrasyon

ihtiyaçlarına göre karar vermelidir.

Çoğu büyük yapıda iki yaklaşım birlikte kullanılabilir.

CNAPP Lisans Maliyeti Nasıl Değerlendirilir?

Lisans modeli;

workload,

resource,

host,

cloud account,

data volume

üzerinden olabilir.

Sadece lisans fiyatına değil;

tool consolidation,

operational efficiency,

risk reduction

etkisine bakılmalıdır.

Ancak kullanılmayan modüller için yüksek maliyet ödenmemelidir.

Tool Consolidation Nedir?

Ayrı ayrı kullanılan;

CSPM,

container scanner,

CIEM,

CWPP

ürünlerinin tek platformda birleştirilmesidir.

Bu operasyonel verimlilik sağlayabilir.

Ancak tek vendor bağımlılığı ve özellik derinliği ayrıca değerlendirilmelidir.

CNAPP Implementation Nasıl Yapılır?

Genel süreç şöyle düşünülebilir:

1. Cloud Inventory

Account ve subscription'lar çıkarılır.

2. Read-Only Discovery

Platform ilk olarak güvenli read-only yetkiyle bağlanır.

3. Baseline

Mevcut posture analiz edilir.

4. Critical Risk Prioritization

Attack path ve exposure değerlendirilir.

5. Workflow Integration

Ticket ve SIEM entegrasyonu yapılır.

6. Runtime Deployment

Gerekli workload sensor'ları kurulur.

7. Policy Tuning

False positive azaltılır.

8. Remediation

Kritik riskler düzeltilir.

9. Validation

Kontroller tekrar test edilir.

Bu, tek günlük ürün kurulumu değildir.

CNAPP'e Hangi Yetkiler Verilmelidir?

Platformun görünürlük için cloud API access'e ihtiyacı olabilir.

Ancak kendisinin de overprivileged olmaması gerekir.

Mümkün olduğunca;

read-only,

least privilege,

separate security account

yaklaşımı tercih edilmelidir.

Auto-remediation kullanılacaksa write permission ayrıca ve kontrollü verilmelidir.

Security Tool Kendisi Risk Olabilir mi?

Evet.

CNAPP bütün cloud ortamını görebilen güçlü entegrasyona sahip olabilir.

Bu nedenle;

platform admin account,

API credential,

SSO,

MFA,

audit

güvenliği kritik öneme sahiptir.

Security tool compromise edildiğinde blast radius büyük olabilir.

CNAPP Administrator Hesapları Nasıl Korunmalı?

Ayrı privileged hesap.

MFA.

PIM/JIT.

SSO.

Access review.

Audit logging.

gibi kontroller uygulanmalıdır.

Ayrıca vendor support erişimleri de kontrollü olmalıdır.

CNAPP Logları SIEM'e Gönderilmeli mi?

Evet.

Özellikle;

critical finding,

attack path,

runtime threat,

policy change,

admin activity

SIEM'e aktarılabilir.

Böylece cloud risk telemetry'si diğer güvenlik olaylarıyla korele edilir.

CNAPP SOC İçin Nasıl Kullanılır?

SOC iki tür sinyal görebilir:

Posture Risk

“Bu workload saldırıya açık.”

Runtime Threat

“Bu workload üzerinde saldırı davranışı başladı.”

Bu ikisini birleştirmek Incident Response açısından çok değerlidir.

Exposure + Threat Birleşimi Neden Önemlidir?

Örneğin CNAPP daha önce:

Public VM + Critical CVE

tespit etmişti.

Daha sonra runtime'da:

şüpheli shell

görüldü.

Bu durumda olay severity'si çok daha yüksek olmalıdır.

Çünkü risk artık teorik değil, aktif olabilir.

CNAPP Incident Response'a Nasıl Yardımcı Olur?

Saldırganın;

hangi workload'dan başladığını,

hangi identity'yi kullandığını,

hangi resource'lara erişebildiğini,

hangi data'ya ulaşabileceğini

gösterebilir.

Bu blast radius analizini hızlandırır.

Blast Radius Analysis Incident Response'ta Neden Kritik?

Bir access key compromise olduğunda:

“Sadece bu VM mi etkilendi?”

sorusu yetersizdir.

Asıl soru:

“Bu identity hangi kaynaklara erişebiliyordu?”

olmalıdır.

CIEM ve attack graph bu cevabı hızlandırabilir.

CNAPP Forensics'in Yerine Geçer mi?

Hayır.

Cloud forensics için;

audit logs,

disk snapshot,

runtime telemetry,

application logs

gibi daha detaylı incelemeler gerekebilir.

CNAPP olayın kapsamını daraltmaya ve başlangıç context'i sağlamaya yardımcı olur.

Cloud Security Posture KPI'ları Nelerdir?

Örnek metrikler:

Critical Attack Path Count

Public Critical Asset Count

Overprivileged Identity Count

Critical Vulnerability Exposure

Sensitive Data Exposure

CSPM Coverage

Runtime Coverage

Kubernetes Security Coverage

Mean Time to Remediate

Policy Compliance

Bu metrikler tekil finding sayısından daha anlamlı olabilir.

Critical Attack Path Count Neden Önemlidir?

Örneğin 50.000 finding olabilir.

Ancak sadece 4 tanesi gerçek Crown Jewel sistemine ulaşan attack path oluşturuyorsa ilk öncelik bu 4 path olmalıdır.

Bu modern risk-based cloud security yaklaşımının temelidir.

Mean Time to Remediate CNAPP İçin Nasıl Kullanılır?

Critical risk bulundu.

Owner'a gitti.

Düzeltildi.

Kaç saat sürdü?

Cloud ortamı hızlı değiştiği için remediation süresi önemlidir.

Özellikle public exposure'larda exposure window minimize edilmelidir.

Cloud Security Debt Nedir?

Zaman içerisinde biriken;

misconfiguration,

unused role,

old image,

unpatched workload,

policy exception

toplamı bir tür Security Debt oluşturur.

Cloud environment büyüdükçe bu borç da büyüyebilir.

CNAPP security debt'i görünür hale getirebilir.

Security Exception Management Neden Önemlidir?

Bazı policy ihlalleri iş için gerekli olabilir.

Örneğin belirli workload root çalışmak zorunda olabilir.

Bu durumda exception;

owner,

business justification,

expiry date,

compensating control

ile kayıt altına alınmalıdır.

Süresiz exception bırakılmamalıdır.

CNAPP Compliance İçin Kullanılır mı?

Evet.

CIS,

ISO,

PCI DSS,

NIST

mapping sağlanabilir.

Ancak compliance raporu cloud security programının tamamı değildir.

Gerçek amaç:

Attackability + Business Impact

değerlendirmektir.

CNAPP Raporunda Neler Olmalıdır?

Profesyonel bir cloud security raporu şu alanları içerebilir:

Executive Cloud Risk Summary

Yönetim görünümü.

Cloud Inventory

AWS, Azure, GCP kapsamı.

CSPM Findings

Konfigürasyon riskleri.

CIEM Findings

Kimlik ve privilege riskleri.

CWPP Findings

Workload ve runtime riskleri.

KSPM

Kubernetes posture.

Data Exposure

Hassas veri riskleri.

Attack Path Analysis

Kritik saldırı yolları.

Crown Jewel Exposure

İş açısından kritik sistemler.

Remediation Roadmap

Önceliklendirilmiş aksiyonlar.

Bu yapı binlerce teknik bulguyu yönetilebilir risk modeline dönüştürür.

Yönetim İçin CNAPP Çıktısı Nasıl Olmalıdır?

Şu ifade:

“14.238 CSPM finding var.”

yönetim için çok anlamlı değildir.

Daha değerli çıktı:

“Cloud ortamında 4 kritik saldırı yolu tespit edildi. Bunlardan 2'si internete açık workload'lardan production müşteri verisine ulaşılmasına imkan verebilecek privilege zincirleri içeriyor. Ayrıca 7 sürekli administrator ve 18 uzun ömürlü access key yüksek riskli olarak değerlendirildi.”

Bu doğrudan karar verilebilir bilgi sağlar.

CNAPP'in En Büyük Yanlış Kullanımı Nedir?

Platformu kurup:

“Cloud security artık tamam.”

demektir.

CNAPP bir görünürlük ve kontrol platformudur.

Ama;

yanlış IAM,

zayıf DevOps süreci,

güncellenmeyen application,

kötü security ownership

problemlerini tek başına çözmez.

İnsan, süreç ve teknoloji birlikte çalışmalıdır.

CNAPP Security Operating Model Nasıl Olmalıdır?

Örneğin:

Security Team

Policy ve risk yönetimi.

Platform Team

Cloud baseline ve landing zone.

DevOps

IaC ve remediation.

SOC

Runtime threat monitoring.

Application Owner

Business risk ownership.

Bu roller net tanımlanmalıdır.

CNAPP Finding'lerini Kim Düzeltmeli?

Security ekibi “problem var” diyebilir.

Ama çözüm çoğu zaman;

DevOps,

Cloud Platform,

Database,

Application

ekiplerinde yapılır.

Bu nedenle CNAPP'in ticket ve ownership workflow'u teknik feature kadar önemlidir.

Continuous Cloud Security Nedir?

Yılda bir assessment yerine cloud risklerinin sürekli;

discover,

prioritize,

remediate,

validate

edilmesidir.

Bu model cloud'un hızına daha uygundur.

Continuous Security Validation Nasıl Yapılır?

CNAPP bulgu oluşturur.

Remediation yapılır.

Sonra;

posture tekrar taranır,

penetration test uygulanabilir,

Purple Team senaryosu çalıştırılabilir.

Amaç bulgunun gerçekten kapandığını doğrulamaktır.

CNAPP ile Threat Intelligence Birleşebilir mi?

Evet.

Örneğin yeni exploit kampanyası aktif.

CNAPP hangi workload'larda ilgili CVE bulunduğunu gösterir.

Public ve privileged olanları önce çıkarır.

Bu threat-informed vulnerability management sağlar.

Threat-Informed Cloud Security Nedir?

Cloud risklerinin yalnızca compliance değil, güncel saldırgan davranışlarına göre önceliklendirilmesidir.

Örneğin aktif istismar edilen CVE public workload'da bulunuyorsa çok yüksek priority verilir.

Bu yaklaşım gerçek saldırı olasılığına daha yakındır.

CNAPP Cloud Security'nin Son Noktası mıdır?

Hayır.

Cloud security sürekli gelişmektedir.

Yeni alanlar;

AI workload security,

SaaS Security Posture Management,

DSPM,

Application Security Posture Management,

Exposure Management

gibi kavramlarla genişlemektedir.

CNAPP bu ekosistemin önemli merkezi parçalarından biridir ama tek çözüm değildir.

Sonuç: Modern Cloud Security'nin Amacı Daha Fazla Alarm Değil, Daha Az Ama Daha Doğru Risk Görünümüdür

Cloud ortamlarında problem çoğu zaman güvenlik verisinin eksikliği değildir.

Tam tersine:

Çok fazla güvenlik verisi vardır.

CSPM binlerce misconfiguration bulabilir.

Vulnerability scanner binlerce CVE gösterebilir.

CIEM yüzlerce overprivileged identity çıkarabilir.

CWPP runtime alarm üretebilir.

KSPM Kubernetes risklerini gösterebilir.

DSPM hassas veriyi işaretleyebilir.

Ancak güvenlik ekibinin ihtiyacı sadece daha fazla finding değildir.

Asıl ihtiyaç:

Bu bulguların hangileri birleştiğinde gerçek saldırı yolu oluşturuyor?

sorusuna cevap vermektir.

Bu nedenle modern CNAPP yaklaşımı şu modele doğru ilerler:

CSPM

Cloud configuration.

CIEM

Identity ve privilege.

CWPP

Workload ve runtime.

KSPM

Kubernetes.

DSPM

Data sensitivity.

Attack Path Analysis

Gerçek saldırı yolu.

Sonuç:

Contextual Cloud Risk.

Ve en değerli çıktı şudur:

Internet'ten hangi kritik veriye hangi saldırı yolu üzerinden ulaşılabilir?

Bu soruya cevap verebilen cloud security programı gerçekten olgunlaşmaya başlamış demektir.

Ancak teknoloji katmanlarını tek tek anlamak kadar önemli bir son konu daha vardır:

Bütün bu güvenlik kontrolleri kurumsal olarak nasıl yönetilecek?

Sunucu hardening.

Active Directory.

Microsoft 365.

AWS, Azure ve Google Cloud.

IAM.

Kubernetes.

Database.

Backup.

CSPM ve CNAPP.

Bu kontroller birbirinden bağımsız projeler haline gelirse güvenlik sürdürülebilir olmaz.