# Kurumsal Sistem ve Bulut Güvenliği Nasıl Yönetilir? Hardening, Monitoring ve Security Validation Stratejisi

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/sistem-ve-bulut-guvenligi/kurumsal-sistem-bulut-guvenligi-nasil-yonetilir

![Kurumsal Sistem ve Bulut Güvenliği Nasıl Yönetilir? Hardening, Monitoring ve Security Validation Stratejisi](/images/bilgi-merkezi/covers/cover-sistembulut-12.webp)

Bir kurumda güvenlik kontrollerinin bulunması ile güvenli bir sistem ve bulut mimarisine sahip olmak aynı şey değildir.

Firewall olabilir.

EDR olabilir.

SIEM olabilir.

CSPM olabilir.

PAM olabilir.

Backup olabilir.

Cloud provider native güvenlik servisleri kullanılabilir.

Ama bu kontroller birbirinden kopuk çalışıyorsa gerçek güvenlik seviyesi beklenenden düşük olabilir.

Çünkü modern saldırılar tek bir katmanda kalmaz.

Bir saldırgan önce kullanıcı hesabını ele geçirebilir.

Ardından Microsoft 365 veya Entra ID üzerinden privilege escalation deneyebilir.

Cloud IAM yetkilerini kullanabilir.

Bir Kubernetes workload'a geçebilir.

Oradan secret elde edebilir.

Database'e ulaşabilir.

Backup sistemini hedefleyebilir.

Bu nedenle **Kurumsal Sistem ve Bulut Güvenliği**, ürün bazlı değil, yaşam döngüsü bazlı yönetilmelidir.

Temel model şu şekilde düşünülmelidir:

**Discover → Harden → Control Access → Monitor → Detect → Respond → Recover → Validate → Improve**

Bu yaklaşım yalnızca teknik güvenlik sağlamaz.

Aynı zamanda sürdürülebilir bir **System & Cloud Security Operating Model** oluşturur.

#### Kurumsal Sistem ve Bulut Güvenliği Nedir?

Kurumsal Sistem ve Bulut Güvenliği; on-premise, hybrid ve cloud altyapılarındaki sistemlerin merkezi güvenlik prensipleriyle yönetilmesini ifade eder.

Bu kapsam;

- Windows ve Linux sistemler,
- Active Directory,
- Microsoft 365 ve Entra ID,
- AWS, Azure ve Google Cloud,
- IAM ve privileged access,
- container ve Kubernetes,
- database,
- backup ve disaster recovery,
- CSPM, CWPP ve CNAPP,
- SIEM, EDR/XDR ve SOC

gibi alanları kapsar.

Amaç bu sistemlerin her birini ayrı ayrı korumak değil, aralarındaki güven ilişkilerini ve attack path'leri birlikte yönetmektir.

### Sistem ve Bulut Güvenliği Neden Merkezi Yönetilmelidir?

Çünkü saldırgan organizasyon şemasına göre hareket etmez.

Security ekibi başka.

Cloud ekibi başka.

Network ekibi başka.

Database ekibi başka.

Ama saldırgan için bunlar yalnızca farklı saldırı adımlarıdır.

Örneğin:

Phishing

↓

Endpoint Compromise

↓

Credential Theft

↓

Active Directory

↓

Cloud SSO

↓

Cloud IAM

↓

Storage

↓

Sensitive Data

Bu zincir beş farklı takımın sorumluluğuna girebilir.

Ancak saldırgan açısından tek saldırıdır.

Bu nedenle kurumun da güvenliği uçtan uca görmesi gerekir.

### İlk Adım: Asset Inventory

Güvenlik programının ilk adımı neye sahip olduğunuzu bilmektir.

Kurum şu sorulara cevap verebilmelidir:

Kaç Windows Server var?

Kaç Linux Server var?

Kaç Domain Controller var?

Kaç cloud account, subscription veya project var?

Kaç public IP var?

Kaç Kubernetes cluster var?

Kaç database var?

Kaç backup repository var?

Kaç privileged account var?

Bu bilgi yoksa güvenlik programı eksik başlar.

### Asset Inventory Neden Zordur?

Modern altyapılar statik değildir.

Yeni VM oluşturulur.

Container birkaç dakika yaşar.

Serverless function deploy edilir.

Yeni SaaS servisi kullanılır.

Yeni cloud account açılır.

Bu nedenle sadece CMDB yeterli olmayabilir.

Cloud API, CSPM, EASM ve discovery mekanizmalarıyla envanter sürekli güncel tutulmalıdır.

### Shadow IT ve Shadow Cloud Nedir?

Merkezi IT'nin bilgisi dışında kullanılan servislerdir.

Örneğin bir ekip kendi kredi kartıyla cloud account açabilir.

Başka ekip farklı SaaS platformu kullanabilir.

Security ekibi bu yapıyı bilmiyorsa;

logging,

MFA,

backup,

security policy

uygulanamaz.

Bu nedenle asset discovery ile cloud governance birlikte yürütülmelidir.

### Asset Ownership Neden Önemlidir?

Bir bulgu tespit edildiğinde şu soru hemen cevaplanmalıdır:

#### Bu sistem kimin?

Owner belli değilse remediation gecikir.

Her kritik varlık için;

application owner,

technical owner,

business owner

tanımlanmalıdır.

Bu bilgi risk yönetimini hızlandırır.

### Asset Criticality Nedir?

Bütün sistemler aynı önemde değildir.

Örneğin:

Test sunucusu.

Kurumsal blog.

ERP.

Ödeme sistemi.

Active Directory.

Bunların iş etkisi farklıdır.

Bu nedenle her varlık;

Critical,

High,

Medium,

Low

gibi sınıflandırılabilir.

Bu sınıflandırma security priority belirler.

### Crown Jewels Nedir?

Kurumun ele geçirilmesi veya kesintisi en yüksek etki oluşturacak kritik sistemleridir.

Örneğin;

Active Directory,

müşteri database'i,

ödeme sistemi,

ERP,

backup management,

identity platformu

Crown Jewel olarak değerlendirilebilir.

Security programı bu varlıklara giden attack path'leri özellikle azaltmalıdır.

### Security Baseline Nedir?

**Security Baseline**, belirli sistem veya platform için minimum güvenlik standardıdır.

Örneğin Windows Server için;

RDP policy,

Windows Firewall,

audit settings,

EDR,

local admin policy

tanımlanabilir.

Cloud için;

MFA,

logging,

encryption,

network exposure,

IAM

kuralları belirlenebilir.

Security baseline standardizasyon sağlar.

### Baseline ile Hardening Arasındaki Fark

Baseline:

**Nasıl olması gerektiğini tanımlar.**

Hardening:

**Sistemi bu güvenlik seviyesine getirir.**

Örneğin baseline:

“SSH yalnızca management network'ten erişilebilir.”

Hardening çalışması:

Mevcut SSH erişimlerini bu kurala uygun hale getirir.

### CIS Benchmark Nasıl Kullanılmalıdır?

CIS Benchmarks güvenli konfigürasyon için önemli referanslardan biridir.

Windows.

Linux.

AWS.

Azure.

Google Cloud.

Kubernetes.

Database.

gibi birçok teknoloji için kullanılabilir.

Ancak benchmark otomatik olarak uygulanmamalıdır.

Her kontrol;

uygulama uyumluluğu,

iş ihtiyacı,

operasyonel etki

açısından değerlendirilmelidir.

### Security Baseline Tek Seferlik midir?

Hayır.

Yeni teknoloji gelir.

Yeni tehdit ortaya çıkar.

Yeni regülasyon çıkar.

Yeni application dependency oluşur.

Bu nedenle baseline versioned olmalı ve düzenli olarak güncellenmelidir.

### Configuration Drift Nasıl Yönetilir?

Sistem bugün baseline'a uygun olabilir.

Yarın administrator geçici firewall rule açar.

Bir ay sonra unutulur.

Bu drift'tir.

Bu nedenle;

configuration management,

CSPM,

policy enforcement,

compliance scanning

kullanılmalıdır.

Amaç baseline ile gerçek ortam arasındaki farkı sürekli ölçmektir.

### Hardening Süreci Nasıl Yönetilmelidir?

Genel yaklaşım:

#### Discover

Sistemleri bul.

#### Classify

Role ve criticality belirle.

#### Baseline

Standart seç.

#### Assess

Mevcut konfigürasyonu ölç.

#### Harden

Düzeltmeleri uygula.

#### Validate

Uygulamanın çalıştığını doğrula.

#### Monitor

Drift'i izle.

Bu döngü sürekli devam eder.

### Patch Management Nasıl Entegre Edilmelidir?

Hardening tek başına yeterli değildir.

Sistem güncel değilse yeni vulnerability'ler saldırı yüzeyi oluşturabilir.

Patch süreci;

asset criticality,

internet exposure,

exploit availability,

business impact

ile birlikte önceliklendirilmelidir.

Bu **Risk-Based Patch Management** yaklaşımıdır.

### Vulnerability Management ile Hardening Nasıl Birlikte Çalışır?

Vulnerability Management:

Bilinen güvenlik açıklarını bulur.

Hardening:

Yanlış veya zayıf konfigürasyonu düzeltir.

Örneğin:

CVE yok.

Ama RDP internete açık.

Bu vulnerability scanner tarafından kritik görülmeyebilir.

Ancak hardening açısından ciddi risktir.

Bu nedenle iki süreç birlikte çalışmalıdır.

### Risk-Based Vulnerability Management Nedir?

Her CVE aynı öncelikte değildir.

Örneğin:

Critical CVE.

Ama test ortamında, private network'te.

Başka bir sistemde High CVE.

Ama public ve production.

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

Bu nedenle;

CVSS,

EPSS,

Known Exploited Vulnerabilities,

Exposure,

Asset Criticality

birlikte değerlendirilmelidir.

### IAM Sistem ve Bulut Güvenliğinin Neden Merkezindedir?

Çünkü modern saldırıların büyük bölümü geçerli kimlikler üzerinden ilerleyebilir.

Admin hesabı.

Service account.

Cloud role.

API key.

Session token.

Bunlardan biri ele geçirilirse saldırgan exploit kullanmadan işlem yapabilir.

Bu nedenle identity security tüm güvenlik mimarisinin merkezindedir.

### Least Privilege Kurum Genelinde Nasıl Uygulanmalıdır?

Her kullanıcı, servis ve workload yalnızca gerekli yetkiye sahip olmalıdır.

Bu;

Windows local admin,

Domain Admin,

Cloud IAM,

Database role,

Kubernetes RBAC,

Backup Admin

için aynı prensiptir.

#### Minimum Privilege, Maximum Accountability

yaklaşımı uygulanmalıdır.

### Privileged Access Management Neden Ortak Katmandır?

Kritik sistemlerin tamamında privileged access vardır.

Domain Admin.

Cloud Owner.

Database DBA.

Kubernetes cluster-admin.

Backup Administrator.

Bu hesaplar farklı teknolojiler olsa da ortak problem aynıdır.

Bu nedenle merkezi PAM/PIM yaklaşımı kurum genelinde uygulanabilir.

### JIT ve JEA Nasıl Kullanılmalıdır?

#### Just-in-Time

Yetki ne kadar süre açık?

#### Just-Enough-Access

Ne kadar yetki veriliyor?

Örneğin administrator'a;

sürekli full admin

yerine

30 dakikalık belirli operasyon yetkisi

verilebilir.

Bu standing privilege riskini azaltır.

### MFA Her Yerde Kullanılmalı mı?

Özellikle;

cloud admin,

Microsoft 365,

VPN,

PAM,

backup,

critical management

erişimlerinde güçlü MFA değerlendirilmelidir.

Ancak sadece MFA yeterli değildir.

Phishing-resistant authentication, Conditional Access ve session security de önemlidir.

### Machine Identity Neden Yeni Büyük Risk Alanıdır?

Cloud ve DevOps ortamlarında insanlardan daha fazla machine identity olabilir.

Service account.

Managed identity.

Kubernetes service account.

CI/CD identity.

API key.

Bu kimlikler çoğu zaman uzun ömürlü ve overprivileged olabilir.

Bu nedenle machine identity inventory zorunlu hale gelmektedir.

### Secret Management Kurum Genelinde Nasıl Yapılmalıdır?

Secret'lar;

source code,

config file,

Excel,

e-posta,

script

içinde tutulmamalıdır.

Merkezi vault veya secret manager kullanılmalıdır.

Ama secret yönetiminin asıl hedefi sadece güvenli saklamak değildir.

**Static secret kullanımını azaltmak** olmalıdır.

### Network Segmentation Neden Ortak Güvenlik Katmanıdır?

Saldırgan bir sistemi ele geçirdiğinde diğer sistemlere doğrudan erişememelidir.

Bu nedenle;

User Network,

Server Network,

Database Network,

Backup Network,

Management Network,

Cloud VPC/VNet

ayrıştırılabilir.

Ama segmentasyon sadece VLAN değildir.

Erişim kuralları minimum tutulmalıdır.

### Zero Trust Sistem ve Cloud Güvenliğinde Nasıl Uygulanır?

Zero Trust:

**Network içinde = güvenilir**

varsayımını reddeder.

Her erişim;

identity,

device,

risk,

resource,

context

üzerinden değerlendirilir.

Bu model on-premise ve cloud güvenliğini ortak prensipte birleştirir.

### Security Monitoring Nasıl Merkezi Hale Getirilir?

Farklı sistemlerden telemetry toplanmalıdır.

Örneğin;

Windows Event Logs,

Linux logs,

Active Directory,

Entra ID,

AWS CloudTrail,

Azure Activity Logs,

GCP Audit Logs,

Kubernetes Audit,

Database Audit,

Backup Logs

SIEM'e gönderilebilir.

Bu merkezi visibility sağlar.

### Her Log SIEM'e Gönderilmeli mi?

Hayır.

Sınırsız log gönderimi;

maliyet,

noise,

storage

problemi oluşturabilir.

Öncelik high-value telemetry olmalıdır.

Örneğin;

privileged change,

authentication,

security configuration,

critical data access

olayları yüksek değer taşır.

### Detection Engineering Nedir?

SIEM'e log göndermek tek başına güvenlik değildir.

Bu loglardan anlamlı detection üretmek gerekir.

Detection Engineering;

use case,

correlation,

threshold,

behavior analysis

tasarımını içerir.

Amaç sadece log toplamak değil saldırıyı görmek olmalıdır.

### System & Cloud Security Use Case Örnekleri

Örneğin:

#### New Domain Admin Created

#### Cloud Owner Assigned

#### MFA Disabled

#### Public Storage Created

#### Privileged Kubernetes Pod Deployed

#### Database Audit Disabled

#### Backup Retention Changed

#### Large Data Export

#### New Access Key Created

Bu use case'ler farklı platformlarda ortak risk davranışlarını gösterir.

### EDR ve XDR Nasıl Konumlandırılmalıdır?

EDR endpoint ve server davranışını izler.

XDR farklı telemetry katmanlarını birleştirebilir.

Örneğin:

Phishing mail.

↓

Endpoint malware.

↓

Credential theft.

↓

Cloud login.

↓

Data access.

XDR saldırı zincirini daha geniş bağlamda gösterebilir.

### NDR Sistem ve Bulut Güvenliğinde Kullanılır mı?

Evet.

Network Detection and Response;

lateral movement,

unusual traffic,

C2,

data transfer

gibi davranışları tespit edebilir.

On-premise ile cloud network telemetry birlikte değerlendirilebilir.

### CSPM Kurumsal Güvenliğe Nasıl Bağlanmalıdır?

CSPM bulduğu misconfiguration'ları sadece cloud ekibine göndermemelidir.

Risk;

asset criticality,

identity privilege,

data sensitivity,

internet exposure

ile ilişkilendirilmelidir.

Bu sayede gerçek remediation priority belirlenir.

### CNAPP Kurumsal Modelde Nerede Durur?

CNAPP cloud güvenlik risklerini merkezi hale getirebilir.

CSPM.

CWPP.

CIEM.

KSPM.

DSPM.

Attack Path.

Bu telemetry SOC ve risk yönetimiyle entegre edilmelidir.

CNAPP ayrı bir güvenlik adası olmamalıdır.

### Attack Path Analysis Neden Ortak Yaklaşımdır?

Active Directory'de attack path vardır.

Cloud IAM'de vardır.

Kubernetes'te vardır.

Database ve backup ortamlarında da privilege zinciri olabilir.

Bu nedenle güvenlik programı bulguları tek tek değil ilişki halinde değerlendirmelidir.

### Attack Path Örneği

Örneğin:

Employee Laptop

↓

Local Admin

↓

Credential Dump

↓

Service Account

↓

Cloud SSO

↓

AWS Role

↓

Kubernetes Cluster

↓

Secret

↓

Database

Bu zincirin her adımı farklı güvenlik ekibine ait olabilir.

Ama attack path tek bir risktir.

### Blast Radius Nedir?

Bir hesap veya sistem compromise olduğunda ne kadar geniş etki oluşturabileceğini ifade eder.

Örneğin;

normal user hesabının blast radius'u düşük olabilir.

Ama Domain Admin veya Cloud Owner çok yüksek blast radius'a sahiptir.

Security architecture blast radius'u mümkün olduğunca azaltmalıdır.

### Choke Point Analizi Neden Değerlidir?

Birçok attack path aynı noktadan geçebilir.

Örneğin tek service account onlarca saldırı yolunda kullanılıyorsa bu hesabı düzeltmek çok yüksek risk azaltımı sağlar.

Bu nedenle remediation yalnızca severity'ye göre değil, attack graph etkisine göre yapılabilir.

### Security Validation Nedir?

**Security Validation**, güvenlik kontrollerinin gerçekten çalışıp çalışmadığının kontrollü şekilde doğrulanmasıdır.

Örneğin;

hardening assessment,

cloud security assessment,

penetration test,

Red Team,

Purple Team,

backup restore test

security validation'ın farklı parçalarıdır.

Temel prensip:

**Kontrolün varlığı yeterli değildir, etkisi test edilmelidir.**

### Security Validation ile Compliance Aynı Şey midir?

Hayır.

Compliance:

Kontrol var mı?

Security Validation:

Kontrol gerçekten çalışıyor mu?

Örneğin policy:

“MFA zorunlu.”

Compliance pass.

Ama eski legacy authentication ile MFA bypass edilebiliyorsa güvenlik eksiktir.

Bu nedenle validation önemlidir.

### Penetration Test Bu Modelde Nerede Durur?

Pentest belirli saldırı yüzeylerini aktif olarak test eder.

Örneğin;

web,

network,

cloud,

Active Directory,

Kubernetes

gibi.

Ama pentest yılda bir yapılır ve sonra unutulursa güvenlik hızlı şekilde eskiyebilir.

Bu nedenle sürekli validation yaklaşımı daha güçlüdür.

### Red Team Neden Gereklidir?

Pentest genellikle belirli scope içerisindeki vulnerability'leri doğrular.

Red Team ise saldırganın gerçek hedefe ulaşma kapasitesini test eder.

Örneğin hedef:

Domain Admin.

Production data.

Cloud admin.

Red Team attack path'i uçtan uca test edebilir.

### Purple Team Neden Daha Değerli Olabilir?

Red Team saldırır.

Blue Team tespit eder.

Sonra birlikte eksikler analiz edilir.

Detection geliştirilir.

Tekrar test edilir.

Bu döngü savunmanın gerçek kalitesini artırır.

### BAS Nedir?

**Breach and Attack Simulation – BAS**, belirli saldırı davranışlarının otomatik ve kontrollü şekilde sürekli test edilmesini sağlayan yaklaşım olabilir.

Örneğin;

EDR detection,

SIEM rule,

network control

periyodik doğrulanabilir.

Bu continuous validation'a katkı sağlar.

### Continuous Security Validation Nedir?

Yılda bir büyük test yerine güvenlik kontrollerinin sürekli veya periyodik olarak doğrulanmasıdır.

Örneğin;

aylık cloud misconfiguration testleri,

çeyreklik AD attack path review,

düzenli restore testleri,

periyodik Purple Team

uygulanabilir.

### Backup Security Validation Nasıl Yapılır?

Backup job “başarılı” olabilir.

Ama gerçek test:

Restore çalışıyor mu?

Immutable backup gerçekten silinemiyor mu?

Domain Admin backup'ı silebiliyor mu?

Recovery süresi RTO'yu karşılıyor mu?

Bunlar kontrollü şekilde test edilmelidir.

### Disaster Recovery Security Validation

DR planı dokümanda çalışabilir.

Ama gerçek tatbikatta;

DNS,

identity,

database,

network,

application dependency

problemleri çıkabilir.

Bu nedenle DR drill yapılmalıdır.

### Cloud Security Validation Nasıl Yapılır?

Örneğin;

CSPM finding doğru mu?

Public storage gerçekten accessible mı?

IAM attack path kullanılabilir mi?

JIT policy çalışıyor mu?

SIEM cloud privilege escalation'ı görüyor mu?

Bu sorular kontrollü şekilde test edilebilir.

### Security Control Testing Nedir?

Her kritik kontrol için şu soru sorulur:

#### Bu kontrol başarısız olursa ne olur?

Örneğin;

EDR disable edilirse SOC alarm alıyor mu?

CloudTrail kapatılırsa alarm var mı?

Backup retention değiştirilirse olay üretiliyor mu?

Bu yaklaşım resilience testidir.

### Security Validation Sonuçları Nasıl Yönetilmelidir?

Her finding için;

owner,

priority,

target date,

business impact,

retest status

tanımlanmalıdır.

Aksi halde assessment raporları raflarda kalır.

Remediation tracking güvenlik programının temel parçasıdır.

### Security Finding SLA Nedir?

Risk seviyesine göre düzeltme süresi tanımlanabilir.

Örneğin:

Critical → 24/48 saat.

High → 7/15 gün.

Medium → 30 gün.

Süreler kurumun risk iştahına göre belirlenmelidir.

### Mean Time to Remediate Neden Önemlidir?

Bulgu sayısının azalmasından daha değerli olabilir.

Örneğin kurum her ay 100 yeni finding üretiyor.

Ama critical bulguları 24 saatte kapatabiliyorsa süreç olgun olabilir.

Bu nedenle remediation velocity ölçülmelidir.

### Risk Acceptance Nasıl Yönetilmelidir?

Her bulgu düzeltilemeyebilir.

Örneğin legacy application nedeniyle eski protocol gerekli olabilir.

Bu durumda risk;

business owner,

security,

management

tarafından bilinçli olarak kabul edilebilir.

Ama risk acceptance süresiz olmamalıdır.

Expiration date olmalıdır.

### Compensating Control Nedir?

Ana güvenlik kontrolü uygulanamıyorsa riski azaltan alternatif kontroldür.

Örneğin eski database TLS desteklemiyor.

Compensating control:

Private network + VPN + strict firewall.

Bu tam çözüm değildir ama riski azaltabilir.

### Security Exception Management Neden Gereklidir?

Kurumda yüzlerce istisna oluşabilir.

Her exception için;

neden,

owner,

risk,

compensating control,

expiry

bulunmalıdır.

Süresi dolan exception yeniden değerlendirilmelidir.

### System & Cloud Security Governance Nedir?

Security programının;

kim karar veriyor,

kim uyguluyor,

kim onaylıyor,

kim izliyor

sorularını cevaplayan yönetim modelidir.

Teknoloji kadar önemlidir.

### RACI Modeli Kullanılabilir mi?

Evet.

Örneğin cloud security policy için:

**Responsible** – Cloud Team.

**Accountable** – CTO/CISO.

**Consulted** – Security.

**Informed** – Application Owner.

Benzer model patch, backup ve IAM için uygulanabilir.

### Security Owner Kim Olmalı?

Security ekibi her sistemin sahibi değildir.

Security risk framework oluşturur.

Teknik owner konfigürasyonu düzeltir.

Business owner ise riskin iş etkisini sahiplenir.

Bu sorumluluk ayrımı net olmalıdır.

### Cloud Center of Excellence Güvenlikte Ne İşe Yarar?

**Cloud Center of Excellence – CCoE**, cloud governance, architecture ve security standartlarını merkezi olarak tanımlayabilir.

Platform Team.

Security.

DevOps.

FinOps.

Architecture.

birlikte çalışabilir.

Bu yaklaşım büyük cloud yapılarda standardizasyon sağlar.

### Security Champion Modeli

Her development veya cloud takımında security konusunda daha yetkin kişi bulunabilir.

Bu kişi merkezi security ekibiyle takım arasında köprü olur.

Ama güvenliği tamamen bu kişiye bırakmak doğru değildir.

Bu ortak sorumluluk modelidir.

### DevSecOps Sistem ve Cloud Güvenliğini Nasıl Güçlendirir?

Security kontrolleri deployment öncesine taşınır.

Örneğin;

IaC scan,

secret scan,

container scan,

policy as code

CI/CD içerisinde çalışır.

Bu hataları production'a çıkmadan azaltır.

### Shift Left Tek Başına Yeterli midir?

Hayır.

Production'da manual değişiklik yapılabilir.

Runtime saldırı gerçekleşebilir.

Bu nedenle;

**Shift Left + Runtime Security + Continuous Validation**

birlikte kullanılmalıdır.

### Infrastructure as Code Neden Stratejik?

IaC sayesinde cloud konfigürasyonu code review ve version control altına alınabilir.

Bu;

standardization,

security,

recovery

avantajı sağlar.

Ama IaC kodunun kendisi de security assessment'tan geçirilmelidir.

### Policy as Code Neden Gereklidir?

Security policy insanın hatırlamasına bağlı kalmaz.

Örneğin:

Public database yasak.

Encryption zorunlu.

Privileged container yasak.

Bu kurallar otomatik enforce edilebilir.

Bu cloud governance'ın en güçlü araçlarından biridir.

### Preventive, Detective ve Corrective Control

Güçlü security programı üç tür kontrol içerir.

#### Preventive

Sorunun oluşmasını engeller.

Örneğin Policy as Code.

#### Detective

Sorunu tespit eder.

Örneğin CSPM/SIEM.

#### Corrective

Sorunu düzeltir.

Örneğin automated remediation.

Bunların üzerine bir dördüncü katman eklenmelidir:

#### Validating

Kontrolün gerçekten çalıştığını doğrular.

### Security Maturity Model Nedir?

Kurumun güvenlik seviyesini aşamalar halinde ölçmeye yardımcı olan modeldir.

System & Cloud Security için örnek olgunluk modeli oluşturulabilir.

### Seviye 1 – Reactive

Bu seviyede güvenlik olay sonrası yürütülür.

Asset inventory eksik olabilir.

Standart hardening yoktur.

Cloud kaynakları manuel yönetilir.

Logging parçalıdır.

Backup vardır ama restore test edilmez.

Temel yaklaşım:

**“Problem olursa bakarız.”**

### Seviye 2 – Controlled

Temel güvenlik kontrolleri uygulanmıştır.

Asset inventory vardır.

EDR kullanılır.

MFA vardır.

Firewall ve backup yönetilir.

Ancak süreçler büyük ölçüde manueldir.

Security review periyodik olabilir.

### Seviye 3 – Standardized

Kurumsal baseline oluşturulmuştur.

CIS hardening uygulanır.

IAM minimum yetkiyle yönetilir.

Central SIEM vardır.

CSPM kullanılır.

Backup restore test edilir.

Security süreçleri standardize edilmiştir.

### Seviye 4 – Integrated

Security sistemleri birlikte çalışır.

EDR + SIEM + IAM + CSPM + CNAPP entegredir.

Attack path analiz edilir.

PAM/JIT kullanılır.

DevSecOps pipeline security içerir.

Security telemetry SOC'a merkezi akar.

Bu seviyede güvenlik artık entegre yapıdadır.

### Seviye 5 – Continuously Validated

En olgun modeldir.

Security controls sürekli test edilir.

Purple Team.

BAS.

Cloud attack path validation.

Automated compliance.

Continuous CSPM/CNAPP.

Restore testing.

Threat-informed validation.

Bu seviyede güvenlik:

**assumed değil, measured**

hale gelir.

### System & Cloud Security Maturity Nasıl Ölçülür?

Farklı alanlar puanlanabilir.

Örneğin:

#### Asset Visibility

#### Hardening

#### Vulnerability Management

#### Identity Security

#### Cloud Security

#### Workload Protection

#### Monitoring

#### Backup & Recovery

#### Security Validation

Her alan 1-5 seviyesinde değerlendirilebilir.

### Management Dashboard Nasıl Olmalıdır?

Yönetim için 50.000 teknik finding göstermek anlamsızdır.

Daha değerli metrikler:

#### Critical Attack Path Count

#### Critical Public Asset Count

#### Privileged Account Count

#### MFA Coverage

#### Critical Vulnerability MTTR

#### Immutable Backup Coverage

#### Restore Test Success

#### Logging Coverage

#### Security Validation Coverage

gibi olabilir.

### Teknik KPI ile Business KPI Nasıl Bağlanır?

Örneğin teknik metrik:

10 critical vulnerability.

Business karşılığı:

3 tanesi ödeme sisteminde.

1 tanesi internet-facing.

Bu bilgi çok daha değerlidir.

Benzer şekilde:

Backup restore success %95.

Ama finans sisteminde %0.

Bu kritik iş riski oluşturur.

### System Security Posture Score Kullanılabilir mi?

Evet.

Ama tek sayı dikkatli kullanılmalıdır.

Örneğin:

System Security Score: 84/100.

Ancak altında:

Domain Admin attack path critical.

varsa bu daha önemlidir.

Bu nedenle score + critical findings birlikte sunulmalıdır.

### Cloud Security Posture Score Kullanılabilir mi?

Benzer şekilde kullanılabilir.

IAM.

Network.

Data.

Workload.

Logging.

Backup.

alanları puanlanabilir.

Ama ortalama skor kritik attack path'leri gizlememelidir.

### Risk Heatmap Nasıl Kullanılır?

Örneğin:

| Alan | Risk |
| --- | --- |
| Active Directory | High |
| Cloud IAM | High |
| Server Hardening | Medium |
| Backup | Low |
| Kubernetes | High |

Bu yönetim için hızlı görünürlük sağlayabilir.

Ancak riskin arkasındaki neden açıklanmalıdır.

### RAG Modeli Nedir?

#### Red

Kritik iyileştirme gerekli.

#### Amber

Risk mevcut, planlı remediation gerekli.

#### Green

Kontroller yeterli.

Management dashboard'larda kullanılabilir.

Ama “Green” sürekli güvenli anlamına gelmez.

Validation devam etmelidir.

### System & Cloud Security Roadmap Nasıl Oluşturulur?

Tüm eksikleri aynı anda düzeltmek mümkün değildir.

Bu nedenle aşamalı roadmap oluşturulabilir.

#### İlk 30 Gün

Critical exposure.

Privileged account.

MFA.

Backup riskleri.

#### 30–90 Gün

Hardening.

CSPM.

Logging.

PAM.

#### 3–6 Ay

CNAPP.

DevSecOps.

Attack path analysis.

#### 6–12 Ay

Continuous validation.

Purple Team.

Maturity improvement.

Bu örnek kurum riskine göre özelleştirilmelidir.

### Quick Wins Neler Olabilir?

Örneğin;

public RDP kapatmak,

unused admin hesabını kaldırmak,

root MFA açmak,

public storage private yapmak,

backup deletion alert oluşturmak,

CloudTrail/audit'i etkinleştirmek

yüksek fayda sağlayabilir.

Quick win'ler ilk risk azaltımı için değerlidir.

### Strategic Security Investments Nelerdir?

Daha uzun vadeli çalışmalar:

PAM dönüşümü.

Zero Trust architecture.

CNAPP.

SIEM modernizasyonu.

Multi-account landing zone.

Immutable backup.

Cloud-native SOC.

Bunlar daha kapsamlı yatırım gerektirebilir.

### Security Architecture Review Ne Zaman Yapılmalı?

Yeni;

cloud migration,

ERP,

Kubernetes,

identity platform,

data center,

backup architecture

öncesinde yapılmalıdır.

Security sonradan eklenen bir katman olmamalıdır.

Design aşamasında değerlendirilmelidir.

### Security by Design Nedir?

Güvenlik kontrollerinin sistem tasarlanırken mimariye dahil edilmesidir.

Örneğin database production'a çıktıktan sonra private yapmak yerine baştan private tasarlanır.

Bu hem daha güvenli hem daha ucuzdur.

### Secure by Default Nedir?

Yeni sistem oluşturulduğunda varsayılan ayarların güvenli olmasıdır.

Örneğin;

public storage disabled,

MFA mandatory,

logging enabled,

private network default.

Kullanıcı güvenliği manuel olarak açmak zorunda kalmaz.

### Default Deny Neden Temel Prensiptir?

Başlangıçta hiçbir erişime izin verilmez.

İş ihtiyacına göre gerekli erişimler tek tek açılır.

Bu prensip;

firewall,

IAM,

RBAC,

Network Policy

için uygulanabilir.

### Assume Breach Nedir?

Zero Trust'ın önemli prensiplerinden biridir.

Bir saldırganın bir sistemi ele geçirebileceğini varsayarak mimari tasarlanır.

Soru:

**“İçeri girerse ne kadar ilerleyebilir?”**

olmalıdır.

Bu nedenle lateral movement, segmentation ve blast radius kritik hale gelir.

### Defense in Depth Nedir?

Tek bir kontrolün başarısız olacağını varsayan katmanlı savunma yaklaşımıdır.

Örneğin:

Firewall.

WAF.

EDR.

PAM.

SIEM.

Backup.

Bir kontrol geçilse bile sonraki katman saldırıyı durdurabilir veya tespit edebilir.

### Cyber Resilience ile System & Cloud Security Arasındaki İlişki

Güvenliğin amacı sadece saldırıyı önlemek değildir.

Kurum;

saldırıyı önlemeli,

tespit etmeli,

sınırlamalı,

yanıt vermeli,

toparlanmalıdır.

Bu **Cyber Resilience** yaklaşımıdır.

Sistem ve cloud security bunun teknik temelini oluşturur.

### Recoverability Neden Security KPI Olmalıdır?

Saldırganı %100 engellemek mümkün değildir.

Bu nedenle şu soru da güvenlik kapsamındadır:

#### Kritik sistem kaç saatte geri döner?

Backup restore.

DR.

Identity recovery.

Clean room.

bunların hepsi security programının parçasıdır.

### Security Programı Ne Sıklıkla Gözden Geçirilmelidir?

Sabit yıllık review yetersiz olabilir.

Özellikle;

cloud migration,

M&A,

yeni application,

büyük identity change,

ransomware incident

sonrasında yeniden değerlendirme gerekir.

Ayrıca düzenli maturity review yapılabilir.

### Threat Intelligence Sisteme Nasıl Bağlanmalı?

Güncel tehdit bilgisi vulnerability ve detection önceliklerini değiştirebilir.

Örneğin aktif olarak istismar edilen yeni CVE varsa;

hangi sistemlerde var?

hangisi public?

hangisi Crown Jewel?

hızla belirlenebilir.

Bu **Threat-Informed Defense** yaklaşımıdır.

### Threat-Informed Security Validation Nedir?

Tatbikat senaryoları gerçek saldırgan davranışlarına göre tasarlanır.

Örneğin sektörde;

cloud credential theft,

MFA bypass,

backup deletion

artıyorsa validation senaryolarına bunlar eklenebilir.

Bu sayede testler gerçek tehditlerle daha uyumlu hale gelir.

### MITRE ATT&CK Kullanılabilir mi?

Evet.

Detection ve Red/Purple Team senaryoları ATT&CK teknikleriyle eşleştirilebilir.

Örneğin;

Valid Accounts,

Remote Services,

Account Manipulation,

Cloud Service Discovery

gibi davranışlar kullanılabilir.

Ama framework amaç değil araçtır.

### Security Controls Nasıl ATT&CK ile Eşleştirilir?

Her kritik saldırı tekniği için:

Preventive control.

Detective control.

Response action.

belirlenebilir.

Örneğin:

Credential Theft.

Prevent → hardening/PAM.

Detect → EDR/ITDR.

Respond → credential revoke.

Bu **Control Mapping** sağlar.

### Detection Coverage Nasıl Ölçülür?

Örneğin kurumun en kritik 50 attack technique'i belirlenir.

Bunların kaçında aktif detection var?

Kaçı test edildi?

Bu iki değer farklıdır.

#### Configured Detection Coverage

ve

#### Validated Detection Coverage

ayrı ölçülmelidir.

### Validated Security Coverage Neden Daha Değerli?

SIEM'de 300 correlation rule olabilir.

Ama hiç test edilmemişse ne kadarının çalıştığı bilinmez.

Bu nedenle:

#### Rule Count

yerine

#### Validated Detection Coverage

daha anlamlı KPI olabilir.

### Security Validation Report Nasıl Olmalıdır?

Profesyonel rapor şu alanları içerebilir:

#### Executive Summary

Genel risk ve maturity.

#### Asset Visibility

Envanter kapsamı.

#### Hardening

Baseline uyumu.

#### Identity Security

AD, Entra ve cloud IAM.

#### Cloud Security

CSPM/CNAPP posture.

#### Workload Security

Server, container, Kubernetes.

#### Data & Database Security

Erişim ve monitoring.

#### Backup & Recovery

Ransomware resilience.

#### Detection

SIEM, EDR/XDR ve SOC.

#### Attack Path Analysis

Kritik saldırı zincirleri.

#### Security Validation

Test edilmiş kontroller.

#### Remediation Roadmap

Aksiyon planı.

### Yönetim Özeti Nasıl Yazılmalıdır?

Örneğin:

**“Yapılan değerlendirmede kritik sistemlerin %92'si merkezi güvenlik monitoring kapsamındadır. Ancak Active Directory'den cloud production ortamına uzanan iki kritik privileged attack path tespit edilmiştir. Cloud tarafında 11 sürekli administrator hesabı ve 4 internete açık management service bulunmuştur. Immutable backup coverage %74, son restore test başarı oranı %96'dır. İlk 90 günlük roadmap'te privileged access reduction, management exposure kapatma ve backup isolation önceliklendirilmiştir.”**

Bu yönetim için anlamlıdır.

### Kurumsal Sistem ve Bulut Güvenliğinde En Büyük Hata Nedir?

En büyük hata güvenliği ürün listesi olarak görmektir.

“EDR var.”

“SIEM var.”

“CSPM var.”

“PAM var.”

Bunlar önemlidir.

Ama asıl sorular şunlardır:

#### EDR bütün kritik sistemlerde aktif mi?

#### SIEM doğru use case'leri görüyor mu?

#### CSPM critical misconfiguration'ı ne kadar sürede kapatıyor?

#### PAM dışında privileged erişim mümkün mü?

#### Backup saldırgan tarafından silinebilir mi?

#### Bunları gerçekten test ettik mi?

Güvenlik seviyesini ürünün varlığı değil, **kontrolün etkinliği** belirler.

### System & Cloud Security Operating Model

Olgun bir yapı şu döngüyü kullanabilir:

#### Discover

Asset ve attack surface.

↓

#### Classify

Criticality ve data.

↓

#### Harden

CIS ve security baseline.

↓

#### Protect

EDR, PAM, segmentation, CSPM.

↓

#### Monitor

SIEM, XDR, CNAPP.

↓

#### Detect

Use case ve behavior analytics.

↓

#### Respond

Incident Response.

↓

#### Recover

Backup ve DR.

↓

#### Validate

Pentest, Purple Team, restore test.

↓

#### Improve

Remediation ve maturity.

Bu model tekrar tekrar çalışmalıdır.

### Kurumsal Sistem ve Bulut Güvenliği İçin Temel Kontrol Alanları

Olgun güvenlik programı en az şu alanları birlikte yönetmelidir:

#### Asset Management

Neyi koruduğunuzu bilin.

#### Secure Configuration

Hardening ve CIS baseline.

#### Vulnerability Management

Risk bazlı patch süreci.

#### Identity Security

AD, Entra, IAM ve machine identity.

#### Privileged Access

PAM, PIM, JIT ve JEA.

#### Network Security

Segmentation ve Zero Trust.

#### Cloud Security

CSPM ve CNAPP.

#### Workload Security

EDR, CWPP ve Kubernetes.

#### Data Security

Database, encryption ve DAM.

#### Monitoring

SIEM, XDR ve SOC.

#### Backup & Recovery

Immutable backup ve DR.

#### Security Validation

Pentest, Red/Purple Team ve continuous validation.

### Sonuç: Sistem ve Bulut Güvenliği Sürekli Ölçülen Bir Dayanıklılık Programıdır

Modern kurumun güvenlik mimarisi artık sadece firewall ve antivirüsten oluşmuyor.

Windows.

Linux.

Active Directory.

Microsoft 365.

AWS.

Azure.

Google Cloud.

Kubernetes.

Database.

Backup.

Hepsi aynı dijital ekosistemin parçalarıdır.

Ve saldırgan bu yapılar arasında rahatlıkla hareket edebilir.

Bu nedenle güvenlik de aynı bütünlükte yönetilmelidir.

Gerçek bir **System & Cloud Security** programı şu sorulara cevap verebilmelidir:

#### Hangi varlıklara sahibiz?

#### Hangileri kritik?

#### Hangileri internete açık?

#### Kimler privileged?

#### Hangi sistemler baseline'dan sapmış?

#### Hangi attack path'ler Crown Jewel sistemlere ulaşıyor?

#### Hangi güvenlik kontrolleri saldırıyı görebiliyor?

#### SOC ne kadar hızlı müdahale ediyor?

#### Backup gerçekten geri dönebiliyor mu?

#### Son güvenlik doğrulaması ne zaman yapıldı?

Bu soruların cevabı sürekli güncel tutulabiliyorsa kurum yalnızca güvenlik ürünü kullanan bir organizasyon olmaktan çıkar.

**Ölçülebilir bir siber dayanıklılık programı yönetmeye başlar.**

Bu nedenle en doğru güvenlik yaklaşımı:

**Hardening ile başlar.**

**Identity ile güçlenir.**

**Monitoring ile görünür hale gelir.**

**Security Validation ile doğrulanır.**

**Backup ve Disaster Recovery ile dayanıklı hale gelir.**

**Sistem ve Bulut Güvenliği** yazı dizisinin en önemli sonucu da şu şekildedir:

**Güvenlik, bir sistemin güvenli olduğunu varsaymak değil; güvenli olduğunu sürekli olarak ölçmek ve doğrulamaktır.**