# Cloud Security Nedir? AWS, Azure ve Google Cloud Güvenliği Nasıl Sağlanır?

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/sistem-ve-bulut-guvenligi/cloud-security-nedir-aws-azure-google-cloud

![Cloud Security Nedir? AWS, Azure ve Google Cloud Güvenliği Nasıl Sağlanır?](/images/bilgi-merkezi/covers/cover-sistembulut-05.webp)

Bulut altyapıları kurumlara hız, ölçeklenebilirlik ve operasyonel esneklik sağlar.

Yeni bir sunucu dakikalar içinde oluşturulabilir.

Yeni bir veritabanı birkaç tıklamayla devreye alınabilir.

Yeni bir uygulama dünyanın farklı bölgelerine kısa sürede dağıtılabilir.

Ancak bu kolaylık yeni bir güvenlik problemine de yol açar:

**Bulut ortamları çok hızlı büyür ve aynı hızla yanlış yapılandırılabilir.**

Bir Security Group yanlış açılabilir.

Bir storage bucket internete açık kalabilir.

Bir IAM role gereğinden fazla yetki alabilir.

Bir API key repository içerisinde unutulabilir.

Bir test sunucusu production bittikten sonra internette açık kalabilir.

Bir admin hesabına sürekli yüksek yetki verilebilir.

İşte **Cloud Security – Bulut Güvenliği**, tam olarak bu riskleri yönetmeyi amaçlar.

Cloud Security; AWS, Microsoft Azure ve Google Cloud gibi platformlarda bulunan kimliklerin, verilerin, ağların, workload'ların, uygulamaların ve yönetim düzlemlerinin siber tehditlere karşı korunmasına yönelik bütünsel güvenlik yaklaşımıdır.

Ancak bulut güvenliği yalnızca bir firewall veya antivirus konusu değildir.

Modern cloud security yaklaşımı;

**IAM + Network Security + Data Protection + Workload Protection + Logging + CSPM + Vulnerability Management + DevSecOps + Incident Response**

katmanlarını birlikte ele alır.

Temel prensip şudur:

**Cloud provider güvenli olabilir; ancak sizin cloud konfigürasyonunuz yine de güvensiz olabilir.**

#### Cloud Security Nedir?

**Cloud Security**, bulut ortamlarında çalışan kaynakların ve verilerin gizlilik, bütünlük ve erişilebilirliğini korumaya yönelik teknik ve operasyonel kontrollerin bütünüdür.

Bu kapsamda;

- AWS Security,
- Microsoft Azure Security,
- Google Cloud Security,
- Cloud IAM,
- Cloud Network Security,
- Cloud Storage Security,
- Cloud Workload Protection,
- Cloud Logging,
- Cloud Security Posture Management

gibi alanlar değerlendirilir.

Cloud security sadece “cloud'u dışarıdan korumak” değildir.

Aynı zamanda cloud içerisinde;

kim hangi kaynağa erişebiliyor,

hangi servis internete açık,

hangi role hangi permission verilmiş,

hangi veriler şifreli,

hangi değişiklikler loglanıyor

sorularına cevap verebilmek gerekir.

### Shared Responsibility Model Nedir?

Bulut güvenliğinin en temel kavramlarından biri **Shared Responsibility Model – Paylaşılan Sorumluluk Modeli**'dir.

Bu model, güvenlik sorumluluğunun cloud provider ile müşteri arasında paylaşıldığını ifade eder.

Genel olarak:

#### Cloud Provider

Fiziksel data center,

donanım,

temel network,

hypervisor,

altyapı güvenliği

gibi katmanlardan sorumlu olabilir.

#### Müşteri

Kimlik,

erişim,

konfigürasyon,

veri,

uygulama,

workload,

network policy

gibi alanlarda sorumluluk taşır.

Bu sınır kullanılan servis modeline göre değişir.

IaaS, PaaS ve SaaS arasında müşterinin sorumluluğu farklılaşır.

### IaaS Güvenliği Nasıl Sağlanır?

**Infrastructure as a Service – IaaS** modelinde sanal makineler, network ve storage gibi temel kaynaklar sağlanır.

Örneğin AWS EC2 veya Azure Virtual Machine gibi servislerde kurum genellikle;

işletim sistemi,

patch,

EDR,

local firewall,

user account,

application,

network rule

gibi alanlardan sorumludur.

Bu nedenle IaaS ortamında klasik server security prensipleri devam eder.

Cloud'da çalışmak Windows veya Linux hardening ihtiyacını ortadan kaldırmaz.

### PaaS Güvenliği Nasıl Farklıdır?

**Platform as a Service – PaaS** modelinde işletim sistemi ve bazı altyapı katmanları provider tarafından yönetilir.

Ancak kurum hâlâ;

IAM,

application security,

data access,

network exposure,

logging,

encryption

konularından sorumlu olabilir.

Örneğin managed database kullanıldığında işletim sistemi patch'i provider tarafından yapılabilir.

Ama database'in internete açık olması müşterinin yanlış konfigürasyonu olabilir.

### SaaS Güvenliği Cloud Security'nin Parçası mıdır?

Evet.

Microsoft 365, Salesforce veya benzeri SaaS platformlarında fiziksel altyapıyı kullanıcı yönetmez.

Ancak;

MFA,

access control,

data sharing,

OAuth,

user lifecycle

gibi konular yine müşterinin sorumluluğundadır.

Cloud Security bu nedenle yalnızca IaaS sistemlerini değil SaaS ekosistemlerini de kapsar.

### AWS Security Nedir?

**AWS Security**, Amazon Web Services ortamındaki kimlik, network, compute, storage ve uygulama kaynaklarının güvenli şekilde yönetilmesidir.

AWS tarafında kritik güvenlik alanları arasında;

IAM,

EC2,

S3,

VPC,

Security Groups,

CloudTrail,

KMS,

GuardDuty,

AWS Config

gibi servis ve kavramlar bulunur.

Ancak güvenli AWS kullanımı sadece bu servisleri açmak değildir.

Önemli olan doğru mimari ve minimum yetki modelidir.

### Azure Security Nedir?

**Microsoft Azure Security**, Azure üzerinde çalışan;

Virtual Machines,

Storage Accounts,

VNets,

Azure SQL,

Key Vault,

Entra ID,

AKS,

Application Gateway

gibi kaynakların korunmasını kapsar.

Azure güvenliğinde özellikle Entra ID ile kaynak yetkilerinin birleşmesi kimlik güvenliğini kritik hale getirir.

Yanlış role assignment birçok kaynağa geniş erişim verebilir.

### Google Cloud Security Nedir?

**Google Cloud Security – GCP Security**, Google Cloud üzerindeki compute, storage, IAM, network ve managed servislerin güvenliğini kapsar.

Örneğin;

Compute Engine,

Cloud Storage,

VPC,

IAM,

Cloud Logging,

Cloud KMS,

GKE

gibi servisler güvenlik değerlendirmesine dahil olabilir.

AWS ve Azure'dan servis isimleri farklı olsa da temel güvenlik prensipleri aynıdır:

**Minimum yetki, minimum exposure ve maksimum görünürlük.**

### Multi-Cloud Security Nedir?

Bir kurum aynı anda AWS, Azure ve Google Cloud kullanabilir.

Bu yapıya **Multi-Cloud** denir.

Multi-cloud esneklik sağlar.

Ancak güvenlik açısından;

farklı IAM modelleri,

farklı log formatları,

farklı network kuralları,

farklı security tooling

operasyonel karmaşıklık oluşturur.

Bu nedenle multi-cloud security merkezi görünürlük gerektirir.

### Cloud IAM Neden En Kritik Konulardan biridir?

Cloud ortamlarında birçok yönetim işlemi API üzerinden gerçekleştirilir.

Bir identity doğru permission'a sahipse yüzlerce kaynağı değiştirebilir.

Bu nedenle **Identity and Access Management – IAM**, cloud güvenliğinin merkezindedir.

Yanlış IAM permission;

data access,

resource deletion,

network change,

new credential creation

gibi ciddi etkiler yaratabilir.

### Least Privilege Cloud'da Nasıl Uygulanır?

Bir kullanıcı veya role yalnızca ihtiyaç duyduğu permission verilmelidir.

Örneğin developer'ın sadece belirli storage bucket'a read access ihtiyacı varsa bütün account üzerinde administrator olması gereksizdir.

Ancak cloud IAM sistemlerinde permission sayısı çok yüksek olabilir.

Bu nedenle zamanla privilege creep oluşabilir.

Periyodik access review yapılmalıdır.

### Overprivileged IAM Nedir?

**Overprivileged IAM**, kullanıcı veya servis kimliğinin iş ihtiyacından çok daha geniş yetkilere sahip olmasıdır.

Örneğin:

*:*

benzeri aşırı geniş permission yapıları ciddi risk olabilir.

Aynı şekilde bir application service sadece belirli database'e erişmesi gerekirken bütün subscription veya project üzerinde owner olabilir.

Bu tür geniş yetkiler saldırı etkisini büyütür.

### Cloud Role Nedir?

Cloud provider'larda kullanıcıya doğrudan permission vermek yerine role kullanılabilir.

Role;

belirli görevler için permission set

sağlar.

Örneğin;

read-only,

database operator,

network administrator

gibi.

Ancak role tasarımı yanlışsa yine privilege escalation yolları oluşabilir.

### Cloud Privilege Escalation Nedir?

Bir kullanıcı doğrudan admin olmayabilir.

Ama sahip olduğu permission sayesinde;

yeni role oluşturabilir,

kendine permission verebilir,

service account credential oluşturabilir,

policy değiştirebilir.

Bu sayede daha yüksek yetkiye ulaşabilir.

Bu nedenle cloud security assessment sadece mevcut role'lere değil, **permission chaining** risklerine de bakmalıdır.

### Cloud Attack Path Nedir?

**Cloud Attack Path**, düşük yetkili kimlikten kritik cloud kaynağına veya yüksek privilege'a giden saldırı yoludur.

Örneğin:

Developer User

↓

Application Owner

↓

Secret Access

↓

Service Account

↓

Subscription Admin

gibi bir zincir olabilir.

Bu nedenle modern cloud security ürünlerinde attack path analysis giderek daha önemli hale gelmektedir.

### Service Account Güvenliği Neden Önemlidir?

Cloud ortamlarında uygulamalar genellikle service identity kullanır.

AWS tarafında role,

Azure tarafında managed identity,

GCP tarafında service account

benzeri modeller bulunabilir.

Bu kimliklerin credential'ları saldırgan için yüksek değerli olabilir.

Özellikle uzun ömürlü static key kullanımı risklidir.

### Long-Lived Access Key Neden Risklidir?

Access key yıllarca değişmeden kullanılıyorsa;

repository,

developer laptop,

log,

config file

üzerinden sızabilir.

Bu nedenle mümkün olduğunca temporary credential veya workload identity kullanılmalıdır.

Eğer static key gerekiyorsa rotation ve monitoring yapılmalıdır.

### Cloud Secret Management Nedir?

Application'ların;

password,

API key,

token,

certificate

gibi hassas verilere ihtiyacı olabilir.

Bu bilgiler kod içerisinde tutulmamalıdır.

Cloud provider'ların secret manager veya key vault servisleri kullanılabilir.

Ancak secret vault'un kendisine verilen erişimler de minimum tutulmalıdır.

### Public IP Cloud'da Neden Kritik?

Bir cloud workload'a public IP atanması onu doğrudan internet saldırı yüzeyine çıkarabilir.

Örneğin;

SSH,

RDP,

database,

management interface

public IP üzerinden erişilebilir hale gelebilir.

Bu nedenle cloud ortamında:

**“Bu resource gerçekten public olmak zorunda mı?”**

sorusu her zaman sorulmalıdır.

### Security Group Nedir?

Security Group, cloud workload'lara hangi network trafiğinin ulaşabileceğini belirleyen kontrol mekanizmasıdır.

Yanlış security group;

22,

3389,

3306,

5432,

1433

gibi kritik portları internete açabilir.

Bu nedenle Security Group review cloud security assessment'ın temel parçalarından biridir.

### 0.0.0.0/0 Her Zaman Güvenlik Açığı mıdır?

Hayır.

Örneğin public web server'ın 443 portunun tüm internetten erişilebilir olması normaldir.

Ancak SSH veya database portunun tüm internete açık olması çoğu senaryoda ciddi risk olabilir.

Bu nedenle geniş erişim:

**port + resource + business purpose**

bağlamında değerlendirilmelidir.

### Network ACL ile Security Group Arasındaki Fark

Cloud provider'a göre detaylar değişse de genel olarak;

Security Group workload seviyesinde,

Network ACL subnet veya network seviyesinde

erişim kontrolü sağlayabilir.

İki mekanizma katmanlı network security oluşturmak için kullanılabilir.

Ama gereksiz karmaşıklık da operasyonel hata riskini artırabilir.

### VPC ve VNet Güvenliği

AWS'te **VPC**, Azure'da **VNet** gibi yapılar cloud network isolation için kullanılır.

Güvenli cloud architecture;

public subnet,

private subnet,

management subnet,

database subnet

gibi ayrımlar kullanabilir.

Ama subnet oluşturmak tek başına segmentation değildir.

Network rule'ların da doğru sınırlandırılması gerekir.

### Private Endpoint Nedir?

Managed cloud servislerine public internet üzerinden değil özel network bağlantısıyla erişim sağlanmasını mümkün kılan mekanizmalardan biridir.

Örneğin database veya storage private endpoint üzerinden erişilebilir olabilir.

Bu sayede public exposure azaltılabilir.

Ancak DNS ve routing doğru yapılandırılmalıdır.

### Cloud Firewall Neden Kullanılır?

Security Group çoğu durumda temel erişim kontrolü sağlar.

Ancak merkezi policy, gelişmiş inspection veya outbound filtering ihtiyacı olduğunda cloud firewall kullanılabilir.

Cloud Firewall;

L3/L4 filtering,

application control,

threat prevention

gibi özellikler sağlayabilir.

### Egress Filtering Cloud'da Neden Önemli?

Cloud network güvenliğinde inbound trafik kadar outbound trafik de önemlidir.

Ele geçirilmiş workload;

C2 bağlantısı,

malware download,

data exfiltration

için internet çıkışı kullanabilir.

Bu nedenle her workload'un internette her yere bağlanmasına izin vermek gereksiz risk oluşturabilir.

### NAT Gateway Güvenlik Kontrolü müdür?

NAT Gateway private subnet'teki kaynakların internete çıkmasını sağlarken doğrudan inbound erişimi azaltabilir.

Ancak tek başına güvenlik ürünü değildir.

Outbound trafik yine kontrol edilmelidir.

Ayrıca NAT maliyet ve kapasite açısından da izlenmelidir.

### Public Storage Nedir?

Cloud storage kaynaklarının yanlış permission nedeniyle internetten erişilebilir olması **Public Storage Exposure** olarak değerlendirilir.

Örneğin;

backup,

müşteri verisi,

rapor,

source code,

log

public olabilir.

Bu cloud security'nin en sık bilinen misconfiguration örneklerinden biridir.

### AWS S3 Bucket Güvenliği Nasıl Sağlanır?

S3 bucket'larda;

public access,

bucket policy,

IAM permission,

encryption,

logging,

versioning

değerlendirilebilir.

Bir bucket'ın public olması her zaman yanlış olmayabilir.

Public web asset yayınlayan bucket için meşru olabilir.

Ancak hassas veri için ciddi risk oluşturur.

### Azure Storage Security Nasıl Sağlanır?

Azure Storage hesaplarında;

public access,

SAS token,

network restriction,

private endpoint,

encryption,

access key

kontrolleri değerlendirilebilir.

Özellikle uzun süre geçerli SAS token'lar hassas veri erişimi açısından risk oluşturabilir.

### Google Cloud Storage Güvenliği

GCP Cloud Storage üzerinde;

IAM,

public access,

service account,

signed URL,

encryption

gibi alanlar kontrol edilmelidir.

Temel prensip yine aynıdır:

**Veriye yalnızca ihtiyacı olan kimlik erişmelidir.**

### Encryption at Rest Cloud'da Nasıl Sağlanır?

Cloud provider'lar birçok serviste varsayılan encryption sağlayabilir.

Ancak kurum;

provider-managed key,

customer-managed key,

HSM-backed key

gibi seçenekler arasında karar verebilir.

Burada önemli olan sadece şifreleme olması değil, key management sürecidir.

### Customer-Managed Key Nedir?

**Customer-Managed Key – CMK**, encryption key'in yaşam döngüsünün daha fazla müşteri kontrolünde olduğu modeldir.

Kurum;

key rotation,

access,

disable,

audit

işlemlerini yönetebilir.

Bu özellikle regülasyon ve yüksek hassasiyetli sistemlerde önemli olabilir.

### KMS Nedir?

**Key Management Service – KMS**, encryption key'lerin merkezi şekilde yönetilmesini sağlayan cloud servis kategorisidir.

KMS güvenliğinde;

key permission,

rotation,

logging,

separation of duties

önemlidir.

Encryption key'e erişim veren IAM permission'lar ayrıca kritik kabul edilmelidir.

### Cloud Logging Neden Kritik?

Cloud ortamlarındaki birçok yönetim işlemi API çağrısı şeklindedir.

Bu nedenle loglar saldırı analizi açısından çok değerlidir.

Örneğin;

new user,

new key,

security group change,

storage policy change,

role assignment,

resource deletion

gibi işlemler audit loglarda görülebilir.

### AWS CloudTrail Nedir?

**AWS CloudTrail**, AWS account içerisindeki birçok API aktivitesinin kaydını sağlar.

Kim hangi işlemi yaptı?

Hangi IP'den yaptı?

Hangi resource üzerinde yaptı?

gibi bilgiler incident response için değerlidir.

CloudTrail'in doğru kapsam ve retention ile yapılandırılması önemlidir.

### Azure Activity Log Nedir?

Azure Activity Log, subscription düzeyinde gerçekleştirilen birçok management işlemini izlemeye yardımcı olur.

Örneğin;

resource creation,

role change,

network change

gibi işlemler görülebilir.

Bu kayıtların SIEM'e aktarılması SOC görünürlüğünü artırır.

### Google Cloud Audit Logs Nedir?

GCP Audit Logs, cloud kaynaklarına yapılan yönetim ve erişim aktivitelerinin izlenmesine yardımcı olur.

Özellikle privileged ve administrative aktiviteler Incident Response açısından değerlidir.

### Cloud Logları Değiştirilebilir mi?

Eğer saldırgan yüksek yetki elde ederse loglama ayarlarını kapatmaya veya logları silmeye çalışabilir.

Bu nedenle logların;

ayrı security account,

central logging project,

immutable storage

gibi mimarilerle korunması değerlendirilebilir.

### Centralized Cloud Logging Nedir?

Farklı cloud account ve subscription'lardaki logların merkezi bir security account veya SIEM'e aktarılmasıdır.

Bu yapı saldırganın lokal log kaynaklarını manipüle etmesi durumunda geçmiş telemetry'nin korunmasına yardımcı olabilir.

### CSPM Nedir?

**Cloud Security Posture Management – CSPM**, cloud ortamlarındaki güvenlik konfigürasyonlarını sürekli analiz eden teknoloji ve süreç kategorisidir.

CSPM;

public storage,

open network port,

MFA eksikliği,

logging kapalı olması,

encryption eksikliği,

overprivileged identity

gibi riskleri tespit edebilir.

Cloud ortamlarının sürekli değişmesi CSPM'i özellikle değerli hale getirir.

### CSPM Neden Manuel Kontrolden Daha Etkilidir?

Cloud ortamında yüzlerce veya binlerce resource olabilir.

Yeni kaynaklar her gün oluşturulabilir.

Manuel güvenlik review kısa sürede güncelliğini kaybeder.

CSPM ise sürekli tarama yaparak configuration drift'i tespit edebilir.

Ancak bulgular mutlaka risk bazlı önceliklendirilmelidir.

### Cloud Misconfiguration Nedir?

**Cloud Misconfiguration**, cloud resource'un güvenli olmayan şekilde yapılandırılmasıdır.

Örneğin;

public database,

open SSH,

public storage,

admin IAM role,

audit logging disabled,

encryption disabled

gibi.

Cloud security olaylarının önemli bir bölümü konfigürasyon hatalarıyla ilişkilidir.

### Configuration Drift Cloud'da Nasıl Oluşur?

Terraform ile güvenli kaynak oluşturulmuş olabilir.

Ancak administrator portal üzerinden geçici bir rule açar.

Bu değişiklik Infrastructure as Code içerisinde yer almaz.

Aylar sonra unutulur.

Bu **Cloud Configuration Drift** örneğidir.

Bu nedenle IaC ile runtime configuration arasında sürekli karşılaştırma yapılmalıdır.

### Infrastructure as Code Security Nedir?

Terraform, CloudFormation, Bicep gibi araçlarla cloud kaynakları kod üzerinden oluşturulabilir.

Bu model güvenlik için büyük avantaj sağlar.

Çünkü konfigürasyon production öncesinde analiz edilebilir.

Örneğin CI/CD pipeline:

“Bu Security Group SSH'yi internete açıyor.”

uyarısı verebilir.

Bu yaklaşıma **IaC Security Scanning** denir.

### Policy as Code Nedir?

**Policy as Code**, güvenlik ve uyum kurallarının kod olarak tanımlanmasıdır.

Örneğin:

Public database yasak.

Encryption zorunlu.

Admin portları internete açılamaz.

Bu kurallar otomatik olarak deployment sürecinde kontrol edilebilir.

Bu şekilde güvenlik yalnızca insan kontrolüne bağlı kalmaz.

### Shift Left Cloud Security Nedir?

Security kontrolünün production sonrasından development ve deployment öncesine taşınmasıdır.

Örneğin;

Terraform scan,

container image scan,

secret scan,

dependency scan

CI/CD pipeline içerisinde yapılabilir.

Bu yaklaşım hatayı production'a çıkmadan düzeltmeyi amaçlar.

### Cloud Workload Protection Nedir?

Cloud workload;

virtual machine,

container,

Kubernetes node,

serverless

olabilir.

Bu workload'ların runtime güvenliği **Cloud Workload Protection – CWP/CWPP** kapsamında değerlendirilir.

Amaç;

malware,

vulnerability,

runtime attack,

unexpected process

gibi davranışları izlemektir.

### CWPP Nedir?

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

VM,

container,

Kubernetes,

serverless

gibi farklı workload türlerini kapsayabilir.

CSPM konfigürasyona bakarken CWPP runtime davranışa daha fazla odaklanır.

### CNAPP Nedir?

**Cloud-Native Application Protection Platform – CNAPP**, cloud güvenliğinin farklı alanlarını tek platform altında birleştirmeyi amaçlar.

Örneğin;

CSPM,

CWPP,

CIEM,

container security,

IaC security,

vulnerability management

özelliklerini birlikte sunabilir.

Ama CNAPP satın almak tek başına güvenli cloud mimarisi oluşturmaz.

Süreç ve sorumluluklar yine gereklidir.

### CIEM Nedir?

**Cloud Infrastructure Entitlement Management – CIEM**, cloud IAM permission'larını ve gereğinden fazla yetkileri analiz etmeye odaklanır.

Örneğin kullanıcı 500 permission'a sahip olabilir ancak son 90 günde yalnızca 10'unu kullanmış olabilir.

Bu analiz privilege reduction için değerli olabilir.

### Cloud Vulnerability Management Nasıl Yapılır?

Cloud workload'lar da CVE ve patch risklerine sahiptir.

VM,

container image,

Kubernetes node

taratılabilir.

Ancak cloud vulnerability management sadece CVSS puanına bakmamalıdır.

Örneğin:

Critical CVE

Publicly exposed VM

Known exploit

çok yüksek öncelikli olabilir.

Bu yaklaşım **Risk-Based Vulnerability Management**'tır.

### Exposure Context Neden Önemlidir?

Aynı vulnerability iki farklı sunucuda bulunabilir.

Birinci sunucu private subnet'te.

İkinci sunucu internete açık.

Risk aynı değildir.

Bu nedenle cloud security'de vulnerability + exposure + privilege birlikte değerlendirilmelidir.

### Toxic Combination Nedir?

Tek tek düşük veya orta risk görünen cloud bulguları birlikte ciddi risk oluşturabilir.

Örneğin:

Public VM

Critical vulnerability

High privilege service account

Sensitive storage access

birlikte kritik saldırı yolu oluşturabilir.

Bu tür kombinasyonlar modern CNAPP platformlarında **toxic combination** olarak değerlendirilebilir.

### Attack Path Analysis Cloud Security'yi Nasıl Değiştiriyor?

Eskiden cloud security raporunda binlerce ayrı bulgu gösterilebilirdi.

Modern yaklaşım ise:

**“Hangileri birlikte gerçekten kritik varlığa ulaşılmasını sağlıyor?”**

sorusunu sorar.

Bu sayede güvenlik ekibi en kritik attack path'leri önce kapatabilir.

Bu, alarm sayısından daha anlamlı bir güvenlik yaklaşımıdır.

### Cloud Asset Inventory Neden Zordur?

Cloud kaynakları çok hızlı oluşturulup silinebilir.

Bir developer bugün VM oluşturup yarın silebilir.

Serverless function veya container dakikalar içerisinde ortaya çıkabilir.

Bu nedenle geleneksel CMDB tek başına yeterli olmayabilir.

Cloud API tabanlı asset discovery gerekir.

### Shadow Cloud Nedir?

Takımlar merkezi IT'nin bilgisi dışında ayrı cloud account, project veya subscription kullanabilir.

Bu **Shadow Cloud** riskidir.

Security ekibi bu account'u bilmiyorsa;

logging,

MFA,

CSPM,

budget,

security policy

uygulanmayabilir.

Bu nedenle cloud organization yapısı merkezi yönetilmelidir.

### AWS Organizations Neden Önemlidir?

AWS'de birden fazla account merkezi organizasyon altında yönetilebilir.

Bu sayede;

policy,

billing,

security,

logging

daha merkezi hale getirilebilir.

Benzer şekilde Azure management group/subscription ve GCP organization/project yapıları da governance açısından önemlidir.

### Landing Zone Nedir?

**Cloud Landing Zone**, yeni cloud account veya subscription'ların standart güvenlik ve network kurallarıyla oluşturulmasını sağlayan başlangıç mimarisidir.

Örneğin yeni account açıldığında otomatik olarak;

central logging,

security monitoring,

network baseline,

IAM policy

uygulanabilir.

Bu yaklaşım cloud governance'ın temelidir.

### Cloud Governance Nedir?

Cloud Governance;

kimlerin resource oluşturabileceğini,

hangi region'ların kullanılabileceğini,

hangi security baseline'ın uygulanacağını,

hangi tag'lerin zorunlu olduğunu,

maliyetlerin nasıl yönetileceğini

tanımlar.

Cloud Security yalnızca teknik koruma değil, yönetişim konusudur.

### Tagging Güvenlik İçin Neden Önemli?

Cloud resource'lar;

owner,

environment,

criticality,

data classification

gibi tag'lerle işaretlenebilir.

Örneğin bir public IP bulunduğunda bunun production ödeme sistemine mi yoksa test sunucusuna mı ait olduğu anlaşılabilir.

Bu risk önceliklendirmeyi kolaylaştırır.

### Cloud Asset Owner Neden Belli Olmalıdır?

Bir güvenlik bulgusu tespit edildiğinde:

**“Bu resource kimin?”**

sorusunun cevabı bilinmiyorsa remediation gecikir.

Bu nedenle her resource veya application için owner tanımlanmalıdır.

Cloud security teknik olduğu kadar organizasyonel sorumluluk problemidir.

### Kubernetes Cloud Security'nin Parçası mıdır?

Evet.

AWS EKS,

Azure AKS,

Google GKE

gibi managed Kubernetes servisleri yaygın şekilde kullanılır.

Cloud provider control plane'in bazı bileşenlerini yönetebilir.

Ancak;

RBAC,

workload,

secret,

container image,

network policy

gibi alanlarda kurumun sorumluluğu devam eder.

### Container Registry Güvenliği

Container image'lar registry üzerinde saklanır.

Registry'de;

vulnerability scan,

image signing,

access control,

immutable tag

gibi kontroller uygulanabilir.

Zafiyetli veya değiştirilmiş image production'a çıkarsa cloud workload risk altında kalabilir.

### Serverless Security Nedir?

Serverless servislerde işletim sistemi yönetimi provider'a kayar.

Ancak;

function code,

IAM permission,

secret,

event trigger,

dependency

müşterinin sorumluluğunda olabilir.

Serverless security'de özellikle overprivileged function role kritik risk oluşturabilir.

### Cloud Database Güvenliği Nasıl Sağlanır?

Managed database'lerde;

public exposure,

authentication,

IAM integration,

encryption,

backup,

audit logging,

network access

değerlendirilmelidir.

Database'in managed olması içindeki veriyi otomatik olarak güvenli hale getirmez.

### Public Database Neden Kritik?

Database portunun doğrudan internetten erişilebilir olması;

brute force,

credential attack,

vulnerability exploitation

riskini artırabilir.

Mümkün olduğunca application subnet veya private endpoint üzerinden erişim tercih edilmelidir.

### Cloud Backup Güvenliği

Cloud backup ve snapshot'lar da hassas veri içerir.

Yanlış IAM permission ile saldırgan backup'ları;

okuyabilir,

silebilir,

kopyalayabilir.

Bu nedenle backup resource'ları da production kadar sıkı korunmalıdır.

### Snapshot Sızıntısı Nedir?

Bir VM veya database snapshot başka account ile yanlışlıkla paylaşılabilir veya public hale getirilebilir.

Snapshot içerisinde;

database,

credential,

configuration,

sensitive data

bulunabilir.

Bu nedenle snapshot sharing de CSPM kontrollerine dahil edilmelidir.

### Immutable Cloud Backup Nedir?

Bazı cloud servisleri backup'ın belirli süre silinmesini veya değiştirilmesini zorlaştıran immutability özellikleri sağlayabilir.

Bu ransomware ve account compromise risklerine karşı önemlidir.

Ancak backup admin kimliklerinin korunması yine gereklidir.

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

Cloud monitoring farklı katmanları içermelidir:

#### IAM Events

Role ve permission değişiklikleri.

#### Network Events

Security Group ve firewall değişiklikleri.

#### Storage Events

Public access değişiklikleri.

#### Compute Events

Yeni VM ve workload oluşumu.

#### Audit Logs

Administrative işlemler.

#### Threat Detection

Şüpheli davranışlar.

Bu telemetry merkezi SOC'a aktarılmalıdır.

### SIEM Cloud Security'de Neden Gereklidir?

AWS, Azure ve GCP'nin her biri farklı log sistemlerine sahiptir.

SIEM bu kayıtları tek yerde korele edebilir.

Örneğin:

Git repository → secret leak

Cloud → yeni API login

IAM → role escalation

Storage → yüksek miktarda download

aynı saldırının parçaları olabilir.

Bu nedenle cloud telemetry diğer güvenlik verileriyle birlikte analiz edilmelidir.

### Cloud-Native Threat Detection Nedir?

Cloud provider'lar şüpheli cloud davranışlarını tespit eden native servisler sunabilir.

Bu sistemler;

unusual API activity,

malicious IP,

crypto mining,

credential abuse

gibi davranışları algılayabilir.

Ancak native detection'ların SOC süreçlerine entegre edilmesi gerekir.

Portalda duran alarm tek başına yeterli değildir.

### Crypto Mining Cloud Ortamlarında Neden Görülür?

Saldırgan cloud credential ele geçirdiğinde hesap içerisindeki compute kaynaklarını cryptocurrency mining amacıyla kullanabilir.

Bu hem güvenlik hem maliyet problemidir.

Ani;

GPU instance,

compute usage,

cost increase

anomalileri bu nedenle güvenlik açısından da takip edilmelidir.

### Cloud Cost Anomaly Güvenlik Sinyali Olabilir mi?

Evet.

Normalde günlük 500 USD harcayan account bir anda 8.000 USD harcıyorsa;

crypto mining,

abuse,

DDoS/EDoS,

yanlış deployment

olabilir.

Bu nedenle FinOps verileri Cloud Security Monitoring'e değer katabilir.

### Cloud Incident Response Neden Farklıdır?

Cloud ortamında saldırgan fiziksel sunucuya erişmek zorunda değildir.

Bir API credential ile yüzlerce değişiklik yapabilir.

Bu nedenle Incident Response;

audit log,

IAM,

snapshot,

API activity,

resource history

üzerinden yürütülebilir.

Ayrıca compromised resource silinmeden önce forensic snapshot alınması gerekebilir.

### Cloud Forensics Nedir?

**Cloud Forensics**, cloud ortamındaki güvenlik olaylarının adli olarak incelenmesidir.

Örneğin;

disk snapshot,

cloud audit logs,

network flow logs,

IAM activities,

object access logs

kullanılabilir.

Cloud ortamında veri volatilitesi yüksek olabileceği için log retention önceden planlanmalıdır.

### Cloud Isolation Nasıl Yapılır?

Compromised VM tespit edildiğinde sistemi tamamen kapatmak her zaman ilk adım olmayabilir.

Örneğin;

network isolation,

security group change,

snapshot,

credential revoke

gibi aksiyonlar değerlendirilebilir.

Ama Incident Response prosedürü önceden hazırlanmalıdır.

### Credential Rotation Cloud Incident'ta Neden Önemli?

Saldırgan access key veya secret ele geçirmiş olabilir.

Resource'u düzeltmek yetmez.

Compromised credential rotate veya revoke edilmelidir.

Ayrıca aynı secret'ın başka yerde kullanılıp kullanılmadığı araştırılmalıdır.

### Root Account veya Tenant Owner Hesapları Nasıl Korunmalı?

En yüksek yetkili cloud hesapları günlük operasyon için kullanılmamalıdır.

Güçlü MFA,

minimum kullanım,

alerting,

break-glass prosedürü

uygulanmalıdır.

Bu hesapların aktivitesi son derece nadir ve görünür olmalıdır.

### Cloud Security Assessment Nedir?

**Cloud Security Assessment**, cloud ortamındaki;

IAM,

network,

storage,

compute,

logging,

encryption,

backup,

workload,

governance

risklerinin sistematik şekilde değerlendirilmesidir.

Bu çalışma yalnızca vulnerability scan değildir.

Cloud güvenliğinin en büyük riskleri genellikle konfigürasyon ve identity tabanlıdır.

### AWS Security Assessment Nasıl Yapılır?

AWS değerlendirmesinde örneğin;

organization/account structure,

IAM,

CloudTrail,

S3,

EC2,

VPC,

Security Groups,

KMS,

GuardDuty,

backup

kontrolleri incelenebilir.

Ayrıca attack path ve privilege escalation riskleri analiz edilmelidir.

### Azure Security Assessment Nasıl Yapılır?

Azure tarafında;

tenant/subscription yapısı,

Entra ID,

RBAC,

Storage,

VM,

VNet,

NSG,

Key Vault,

AKS,

logging

değerlendirilebilir.

Azure cloud security ile Entra identity security özellikle birlikte ele alınmalıdır.

### Google Cloud Security Assessment Nasıl Yapılır?

GCP tarafında;

organization/project,

IAM,

service account,

VPC,

Cloud Storage,

Compute Engine,

GKE,

KMS,

Audit Logs

analiz edilebilir.

Yine temel hedef yalnızca compliance değil, gerçek attack path'leri anlamaktır.

### CIS Cloud Benchmark Nedir?

CIS, AWS, Azure ve Google Cloud için güvenli configuration önerileri yayınlar.

Örneğin;

MFA,

logging,

network,

IAM,

storage

kontrolleri içerebilir.

Bu benchmark'lar cloud security baseline için değerlidir.

Ancak her kurumun mimarisine göre özelleştirilmelidir.

### Cloud Security Baseline Nedir?

Kurumun tüm cloud account'larında minimum olarak bulunması gereken güvenlik kontrolleridir.

Örneğin:

Root/Admin MFA zorunlu.

Central logging aktif.

Public storage yasak.

Security Group admin portları internetten kapalı.

Encryption zorunlu.

Cloud threat detection aktif.

Bu baseline otomatik policy ile enforce edilebilir.

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

Hayır.

Bir cloud environment compliance kontrol listesinden yüksek puan alabilir.

Ama gerçek bir attack path'e sahip olabilir.

Örneğin tüm kaynaklar şifreli olabilir.

Ama developer hesabı yüksek privilege'a sahip olabilir.

Bu nedenle compliance güvenliğin bir parçasıdır; tamamı değildir.

### Cloud Penetration Testi ile Cloud Security Assessment Arasındaki Fark

#### Cloud Security Assessment

Konfigürasyon, IAM, mimari ve governance risklerini inceler.

#### Cloud Penetration Test

Yetkilendirilmiş saldırı teknikleriyle bu risklerin ne kadar istismar edilebilir olduğunu test eder.

İkisi birlikte daha güçlü cloud security görünümü sağlar.

### Cloud Security Posture Nasıl Ölçülür?

Örnek KPI'lar;

#### Public Asset Count

#### Critical Misconfiguration Count

#### Overprivileged Identity Count

#### MFA Coverage

#### Logging Coverage

#### Encryption Coverage

#### Critical Vulnerability Exposure

#### Attack Path Count

#### Mean Time to Remediate

şeklinde olabilir.

Ama KPI'lar yalnızca sayı üretmemeli, gerçek risk azaltımını göstermelidir.

### Mean Time to Remediate – MTTR Neden Önemlidir?

Cloud ortamı çok hızlı değiştiği için bulgunun bulunması kadar düzeltilme hızı da önemlidir.

Örneğin public storage tespit edildi.

Ama 45 gün açık kaldı.

Bu süre exposure window'dur.

Bu nedenle kritik cloud misconfiguration'ların remediation süresi ölçülmelidir.

### Cloud Security'de Continuous Monitoring Neden Şarttır?

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

Yeni developer gelir.

Yeni Security Group açılır.

Yeni storage oluşturulur.

Yeni role atanır.

Bu nedenle yılda bir cloud security assessment tek başına yeterli değildir.

Sürekli posture monitoring gerekir.

### Continuous Cloud Security Validation Nedir?

Cloud güvenlik kontrollerinin yalnızca izlenmesi değil, düzenli olarak test edilmesidir.

Örneğin;

CSPM public exposure tespit ediyor mu?

SIEM role escalation alarmı üretiyor mu?

EDR workload saldırısını görüyor mu?

Backup restore çalışıyor mu?

Bu kontroller periyodik olarak doğrulanmalıdır.

### Cloud Security Operating Model Nasıl Olmalıdır?

Cloud güvenliği yalnızca security ekibinin görevi değildir.

Örneğin;

#### Platform Team

Landing Zone ve cloud altyapısını yönetir.

#### DevOps

Deployment süreçlerini yönetir.

#### Security

Policy ve monitoring sağlar.

#### SOC

Threat detection yürütür.

#### Application Teams

Kendi workload güvenliğinden sorumludur.

Bu görev dağılımı açık olmalıdır.

### Cloud Security Champion Modeli

Büyük development ekiplerinde her takım içerisinde güvenlik konusunda yetkin bir kişi bulunabilir.

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

Bu yaklaşım güvenlik kontrollerinin daha erken uygulanmasına yardımcı olabilir.

Ancak nihai risk sahipliği kurum genelinde tanımlanmalıdır.

### Cloud Security'de En Büyük Hatalar Nelerdir?

En yaygın örnekler arasında;

gereğinden fazla IAM yetkisi,

public storage,

public management portları,

static credential,

logging eksikliği,

root/admin hesabının günlük kullanımı,

shadow cloud,

açık secret,

zayıf backup politikaları,

manual configuration drift

bulunabilir.

Bu hataların çoğu yüksek teknoloji eksikliğinden değil, yönetişim ve konfigürasyon probleminden kaynaklanır.

### Kurumsal Cloud Security İçin Temel Kontroller

Güçlü bir cloud security programında genel olarak şu katmanlar bulunmalıdır:

#### Cloud Governance

Account ve subscription yapısı.

#### IAM Security

Least Privilege ve MFA.

#### Network Security

Segmentation ve private access.

#### Data Security

Encryption ve access control.

#### Workload Protection

VM, container ve serverless güvenliği.

#### CSPM / CNAPP

Sürekli posture görünürlüğü.

#### DevSecOps

IaC ve pipeline güvenliği.

#### Logging & SOC

Merkezi threat detection.

#### Backup & Recovery

Siber dayanıklılık.

#### Security Validation

Periyodik assessment ve test.

Bu katmanlar birbirinden bağımsız düşünülmemelidir.

### Cloud Security Raporunda Neler Olmalıdır?

Profesyonel rapor şu alanları içerebilir:

#### Executive Cloud Risk Summary

Yönetim özeti.

#### Cloud Architecture

Account, subscription ve project yapısı.

#### IAM Findings

Yetki riskleri.

#### Network Exposure

Public servisler ve Security Group'lar.

#### Storage & Data Exposure

Hassas veri riskleri.

#### Logging & Detection

SOC görünürlüğü.

#### Workload Security

VM, container ve serverless riskleri.

#### Attack Path Analysis

Bulguların birbirine bağlantısı.

#### Compliance Posture

CIS ve kurum baseline'ı.

#### Remediation Roadmap

Öncelikli aksiyonlar.

Bu sayede rapor yalnızca yüzlerce misconfiguration maddesinden oluşmaz.

Gerçek iş ve saldırı riski görünür hale gelir.

### Sonuç: Cloud Güvenliği Provider'a Bırakılabilecek Bir Konu Değildir

AWS, Azure ve Google Cloud dünyanın en gelişmiş teknoloji altyapılarından bazılarını sunar.

Ancak provider'ın güvenli olması müşterinin konfigürasyonunun da güvenli olduğu anlamına gelmez.

Bir administrator yanlışlıkla database'i internete açabilir.

Developer API key'i repository'ye koyabilir.

IAM role gereğinden fazla permission alabilir.

Storage public olabilir.

Audit log kapatılabilir.

Backup yanlış account tarafından silinebilir.

Bu nedenle cloud güvenliğinin temel sorusu:

**“Cloud platformumuz güvenli mi?”**

değildir.

Daha doğru soru:

**“Cloud platformunu güvenli şekilde kullanıyor muyuz?”**

olmalıdır.

Gerçek Cloud Security;

**Shared Responsibility + IAM + Least Privilege + Network Segmentation + Data Protection + CSPM + Workload Protection + Logging + DevSecOps + Incident Response**

katmanlarının birlikte uygulanmasıyla oluşur.

Ve modern cloud saldırılarında en kritik bileşenlerden biri çoğu zaman sunucunun kendisi değildir.

**Kimliktir.**

Çünkü bir saldırgan geçerli bir cloud identity ele geçirdiğinde herhangi bir exploit kullanmadan API üzerinden kaynak oluşturabilir, veri okuyabilir veya güvenlik politikalarını değiştirebilir.

Bu nedenle bir sonraki kritik soruya geçiyoruz:

**Cloud ortamındaki kullanıcılar, roller, service account'lar ve workload identity'ler gerçekten minimum yetkiye mi sahip?**