# Cloud IAM Güvenliği Nedir? Yetki, Rol ve Privileged Access Riskleri Nasıl Yönetilir?

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/sistem-ve-bulut-guvenligi/cloud-iam-guvenligi-yetki-rol-privileged-access

![Cloud IAM Güvenliği Nedir? Yetki, Rol ve Privileged Access Riskleri Nasıl Yönetilir?](/images/bilgi-merkezi/covers/cover-sistembulut-06.webp)

Bulut ortamlarında en kritik güvenlik konusu çoğu zaman bir güvenlik açığı değil, **yetkidir**.

Bir kullanıcıya gereğinden fazla rol verilmiş olabilir.

Bir service account yıllardır kullanılmayan erişimlere sahip olabilir.

Bir uygulama kendi ihtiyacından çok daha geniş API permission'larıyla çalışıyor olabilir.

Bir access key geliştirici bilgisayarında veya repository içinde unutulmuş olabilir.

Bir administrator hesabı sürekli tam yetkiyle aktif tutuluyor olabilir.

Bu örneklerin tamamı **Cloud IAM Security – Bulut Kimlik ve Erişim Yönetimi Güvenliği** kapsamındadır.

Modern cloud mimarisinde saldırganın mutlaka bir sunucuyu exploit etmesi gerekmez.

Geçerli bir kimlik veya access token elde etmesi yeterli olabilir.

Bu nedenle cloud güvenliğinde temel soru:

**“Kim sisteme giriş yapabiliyor?”**

değildir.

Daha doğru soru şudur:

**“Kim, hangi kimlikle, hangi kaynağa, hangi koşulda ve hangi yetki seviyesinde erişebiliyor?”**

İşte Cloud IAM güvenliği bu sorunun cevabını sürekli olarak kontrol altında tutmayı amaçlar.

#### Cloud IAM Nedir?

**Identity and Access Management – IAM**, cloud ortamındaki kullanıcıların, servislerin ve uygulamaların kaynaklara hangi yetkilerle erişebileceğini yöneten sistemdir.

IAM kapsamında;

- kullanıcılar,
- gruplar,
- roller,
- service account'lar,
- application identity'ler,
- access key'ler,
- token'lar,
- permission policy'leri

yer alabilir.

AWS, Microsoft Azure ve Google Cloud farklı IAM modelleri kullanır.

Ancak temel prensip aynıdır:

**Her kimlik yalnızca ihtiyaç duyduğu kaynağa ve ihtiyaç duyduğu işlem kadar erişebilmelidir.**

Bu prensip **Least Privilege – Minimum Yetki** olarak bilinir.

### Cloud IAM Neden Bu Kadar Kritiktir?

Cloud platformlarında birçok işlem API üzerinden yapılır.

Örneğin yetkili bir kimlik;

yeni sanal makine oluşturabilir,

storage okuyabilir,

firewall rule değiştirebilir,

yeni kullanıcı oluşturabilir,

snapshot alabilir,

database'e erişebilir,

logging'i kapatabilir.

Bu nedenle cloud kimliğinin ele geçirilmesi fiziksel bir sunucuya erişmekten daha geniş etki oluşturabilir.

Saldırgan geçerli credential kullanıyorsa birçok güvenlik kontrolüne saldırı gibi görünmeden erişebilir.

Bu yüzden:

**Identity is the control plane.**

Cloud güvenliğinde kimlik aynı zamanda yönetim düzleminin anahtarıdır.

### AWS IAM Nedir?

**AWS Identity and Access Management – AWS IAM**, AWS kaynaklarına erişimin yönetilmesini sağlar.

AWS ortamında;

users,

groups,

roles,

policies,

access keys

gibi nesneler bulunur.

Örneğin bir IAM Role yalnızca belirli S3 bucket'ı okumaya yetkili olabilir.

Başka bir role EC2 yönetme yetkisi verilebilir.

Problem, bu rollerin gereğinden fazla genişletilmesiyle başlar.

### Azure RBAC Nedir?

Microsoft Azure tarafında kaynak erişimleri çoğunlukla **Azure Role-Based Access Control – Azure RBAC** üzerinden yönetilir.

Kullanıcı veya service principal;

Reader,

Contributor,

Owner

veya daha özel roller alabilir.

Özellikle **Owner** ve geniş kapsamlı **Contributor** yetkileri dikkatle yönetilmelidir.

Çünkü subscription veya management group seviyesindeki bir rol çok geniş kaynak setini etkileyebilir.

### Google Cloud IAM Nedir?

Google Cloud IAM;

user,

group,

service account

gibi principal'lara belirli roller verir.

Bu roller;

organization,

folder,

project,

resource

seviyesinde uygulanabilir.

Üst seviyedeki yetkiler alt kaynaklara inheritance ile aktarılabilir.

Bu nedenle GCP'de permission değerlendirmesi yalnızca resource seviyesine bakılarak yapılmamalıdır.

### Cloud IAM ile Active Directory Aynı Şey midir?

Hayır.

Active Directory daha çok klasik on-premise domain kimlik yönetimidir.

Cloud IAM ise cloud provider'ın kaynak ve API erişim modelidir.

Ancak iki sistem entegre olabilir.

Örneğin bir Entra ID kullanıcısı Azure üzerinde Owner olabilir.

Bu nedenle identity riskleri on-premise ve cloud arasında birbirine bağlanabilir.

### Human Identity ve Machine Identity Arasındaki Fark

Cloud ortamında yalnızca insanlar kimlik kullanmaz.

İki temel kategori düşünülebilir:

#### Human Identity

Çalışan,

administrator,

developer,

third-party user.

#### Machine Identity

Application,

service account,

managed identity,

workload identity,

CI/CD pipeline.

Modern cloud ortamlarında machine identity sayısı insan kullanıcı sayısından çok daha fazla olabilir.

Bu nedenle service identity güvenliği kritik hale gelmiştir.

### Least Privilege Nedir?

**Least Privilege**, kullanıcı veya sistemin yalnızca görevini gerçekleştirmek için gerekli minimum yetkiye sahip olması prensibidir.

Örneğin uygulamanın yalnızca belirli storage bucket'a dosya yazması gerekiyorsa:

bütün cloud account üzerinde administrator

olmasına gerek yoktur.

Yalnızca:

write access to specific bucket

verilmelidir.

Bu prensip saldırganın bir identity'yi ele geçirdiğinde oluşturabileceği etkiyi sınırlar.

### Overprivileged Identity Nedir?

**Overprivileged Identity**, ihtiyacından çok daha fazla permission'a sahip kullanıcı veya servis kimliğidir.

Bu cloud ortamlarındaki en yaygın risklerden biridir.

Örneğin developer'a kolaylık amacıyla:

Administrator

verilir.

Developer aslında yalnızca test ortamında birkaç resource yönetmektedir.

Bu durumda kullanılmayan yüzlerce permission saldırı yüzeyi haline gelir.

### Permission Creep Nedir?

Bir kullanıcı projeler arasında ilerledikçe yeni permission'lar alabilir.

Ancak eski yetkileri kaldırılmaz.

Zaman içerisinde kullanıcı;

test,

production,

network,

database,

storage

gibi çok sayıda alana erişebilir.

Bu duruma **Permission Creep veya Privilege Creep** denir.

Periyodik access review ile azaltılmalıdır.

### Role-Based Access Control – RBAC Nedir?

**RBAC**, erişim yetkisinin kullanıcıya tek tek permission vermek yerine role üzerinden yönetilmesidir.

Örneğin:

Database Operator

Network Administrator

Security Reader

gibi roller tanımlanabilir.

Bu yaklaşım yönetimi kolaylaştırır.

Ancak role'lerin kendisi fazla genişse RBAC güvenlik problemini çözmez.

Bu nedenle role design önemlidir.

### ABAC Nedir?

**Attribute-Based Access Control – ABAC**, erişim kararlarını attribute'lara göre verir.

Örneğin;

resource tag,

department,

environment,

project

gibi değerler kullanılabilir.

Bir politika:

“Finance ekibi yalnızca Finance tag'li kaynakları yönetebilir.”

şeklinde tasarlanabilir.

Büyük cloud ortamlarında RBAC ile ABAC birlikte kullanılabilir.

### Cloud Admin Hesapları Neden Ayrı Olmalıdır?

Günlük e-posta ve web browsing hesabıyla cloud administrator işlemi yapmak gereksiz risk oluşturabilir.

Örneğin kullanıcı phishing saldırısına maruz kalırsa privileged credential de etkilenebilir.

Bu nedenle:

normal user account

ve

privileged cloud admin account

ayrıştırılabilir.

Bu yaklaşım Active Directory Tiering mantığına benzer.

### Standing Admin Yetkisi Neden Risklidir?

Kullanıcı 7/24 administrator ise saldırgan hesabı hangi saatte ele geçirirse geçirsin yüksek yetki elde eder.

Bu nedenle modern IAM yaklaşımında sürekli privilege yerine:

#### Just-in-Time – JIT Access

kullanılabilir.

Yetki yalnızca gerektiğinde ve sınırlı süre için aktive edilir.

### Just-in-Time Access Cloud'da Nasıl Çalışır?

Örneğin administrator production üzerinde işlem yapmak istiyor.

Normalde yalnızca read-only yetkisi var.

PIM veya benzeri sistem üzerinden;

1 saatlik admin role talep ediyor.

MFA tamamlıyor.

Gerekirse manager onayı alıyor.

Süre bitince role otomatik kaldırılıyor.

Bu model standing privilege riskini ciddi şekilde azaltabilir.

### Just-Enough-Access Nedir?

**Just-Enough-Access – JEA**, kullanıcıya yalnızca gerçekleştirmesi gereken işlem kadar yetki verilmesini ifade eder.

JIT:

#### Ne kadar süre?

sorusuna odaklanır.

JEA ise:

#### Ne kadar yetki?

sorusuna odaklanır.

İki yaklaşım birlikte güçlü privileged access modeli oluşturabilir.

### PAM Cloud IAM İçin Kullanılır mı?

Evet.

**Privileged Access Management – PAM**, cloud administrator erişimlerini de yönetebilir.

PAM;

approval,

session recording,

credential vault,

temporary access,

password rotation

gibi fonksiyonlar sağlayabilir.

Ancak modern cloud ortamında password'dan çok token ve role tabanlı erişim kullanıldığı için PAM ile cloud-native PIM/JIT çözümleri birlikte değerlendirilebilir.

### PIM Nedir?

**Privileged Identity Management – PIM**, privileged role'lerin gerektiğinde aktif edilmesine yardımcı olan yaklaşımdır.

Özellikle Azure/Entra ortamında bu kavram yaygındır.

Kullanıcı sürekli Global Administrator veya Owner olmak yerine eligible olabilir.

İhtiyaç durumunda role aktive edilir.

### CIEM Nedir?

**Cloud Infrastructure Entitlement Management – CIEM**, cloud ortamındaki identity ve permission'ların analiz edilmesini sağlayan güvenlik yaklaşımıdır.

CIEM şu sorulara odaklanabilir:

Kim hangi yetkiye sahip?

Bu yetkilerin ne kadarını gerçekten kullanıyor?

Hangi hesap overprivileged?

Hangi permission privilege escalation sağlayabilir?

Hangi dormant identity hâlâ aktif?

Bu nedenle CIEM özellikle büyük multi-cloud yapılarda değerlidir.

### Effective Permission Nedir?

Cloud IAM yapılarında bir kullanıcının görünen role'ü gerçek erişimini tam göstermeyebilir.

Örneğin;

direct role,

group membership,

inherited permission,

resource policy

birlikte kullanıcının **Effective Permissions** seviyesini oluşturabilir.

Bu nedenle IAM review sadece role listesini okumaktan ibaret değildir.

Gerçek permission hesaplanmalıdır.

### Inherited Permission Nedir?

Cloud hierarchy içerisinde üst seviyede verilen permission alt kaynaklara aktarılabilir.

Örneğin Azure'da management group veya subscription seviyesindeki role birçok resource'a uygulanabilir.

GCP'de organization veya folder seviyesi yetki project'lere miras kalabilir.

Bu nedenle:

“Bu resource üzerinde kim yetkili?”

sorusuna yalnızca resource-local policy üzerinden cevap verilemeyebilir.

### Cloud Root Account Nedir?

Bazı cloud platformlarında en yüksek kontrol seviyesine sahip root veya tenant owner benzeri kimlikler bulunur.

Bu hesaplar günlük operasyon için kullanılmamalıdır.

Çünkü ele geçirilmesi tüm cloud ortamını etkileyebilir.

Bu hesaplarda;

güçlü MFA,

çok sıkı monitoring,

minimum kullanım

uygulanmalıdır.

### Root Access Key Oluşturmak Doğru mu?

Genellikle günlük otomasyon için root-level static access key oluşturmak yüksek risktir.

En yüksek yetkili credential'ın uzun süre kullanılabilir durumda olması saldırı yüzeyini büyütür.

Mümkün olduğunca role ve temporary credential modelleri tercih edilmelidir.

### Access Key Nedir?

Access Key, özellikle API üzerinden cloud servislerine erişim için kullanılan credential türlerinden biridir.

Genellikle;

access key ID,

secret key

gibi bileşenleri olabilir.

Bu credential;

CLI,

automation,

application

içerisinde kullanılabilir.

Ancak güvenli şekilde saklanması gerekir.

### Static Access Key Neden Risklidir?

Uzun ömürlü static credential;

repository'de kalabilir,

developer laptop'ında unutulabilir,

loglara yazılabilir,

eski sunucuda bulunabilir.

Ele geçirildiğinde saldırgan parolaya veya MFA'ya ihtiyaç duymadan API erişimi elde edebilir.

Bu nedenle temporary credential modelleri tercih edilmelidir.

### Temporary Credential Nedir?

**Temporary Credential**, belirli süre için geçerli olan kısa ömürlü erişim bilgisidir.

Örneğin role assumption sonucunda kısa süreli token üretilebilir.

Süresi dolduğunda credential geçersiz hale gelir.

Bu, uzun ömürlü key riskini azaltır.

### AWS IAM Role Neden Access Key'den Daha İyi Olabilir?

EC2 üzerinde çalışan uygulama AWS servisine erişmek için source code içinde Access Key tutmak zorunda değildir.

Instance Role kullanılabilir.

Uygulama geçici credential alabilir.

Bu şekilde static secret yönetimi azalır.

Aynı prensip Azure Managed Identity ve GCP Workload Identity için de geçerlidir.

### Managed Identity Nedir?

**Managed Identity**, Azure workload'larının statik credential saklamadan Azure kaynaklarına kimlik doğrulaması yapmasına yardımcı olur.

Örneğin VM, Key Vault'a Managed Identity ile erişebilir.

Ancak bu identity'nin permission'ları yine minimum olmalıdır.

Password olmaması identity'yi otomatik olarak düşük riskli yapmaz.

### Workload Identity Nedir?

**Workload Identity**, application veya container gibi iş yüklerinin cloud servislere güvenli kimlik üzerinden erişmesini sağlayan modeldir.

Amaç source code içerisinde uzun ömürlü credential taşımamaktır.

Kubernetes ve CI/CD ortamlarında giderek daha önemli hale gelmektedir.

### Service Account Nedir?

Service Account, insan kullanıcıdan ziyade uygulama veya servis tarafından kullanılan kimliktir.

Özellikle GCP dünyasında bu terim çok yaygındır.

Service account;

database,

storage,

API,

compute

gibi kaynaklara erişebilir.

Yanlış yapılandırılırsa güçlü bir privilege escalation yolu olabilir.

### Service Account Key Neden Risklidir?

Service account için uzun ömürlü key dosyası oluşturulabilir.

Bu dosya çalınırsa saldırgan service account adına işlem yapabilir.

Bu nedenle keyless veya workload identity tabanlı yöntemler tercih edilebilir.

Mevcut key'ler için;

inventory,

rotation,

usage monitoring

yapılmalıdır.

### Machine Identity Inventory Neden Gereklidir?

Kurumlar genellikle çalışan hesaplarını iyi bilir.

Ancak service identity'leri bilmiyor olabilir.

Şu sorular cevaplanmalıdır:

Kaç service account var?

Kim sahibi?

Hangi workload kullanıyor?

Hangi permission'lara sahip?

Son ne zaman kullanıldı?

Static key var mı?

Bu görünürlük olmadan machine identity security yönetilemez.

### Dormant Identity Nedir?

Uzun süredir kullanılmayan kullanıcı veya service identity'ye **Dormant Identity** denilebilir.

Bu hesaplar risklidir.

Çünkü legitimate kullanım olmadığı için saldırgan aktivitesi daha zor fark edilebilir.

Kullanılmayan identity'ler kapatılmalı veya silinmelidir.

### Orphaned Account Nedir?

Sahibi belli olmayan veya artık ilgili çalışan/proje bulunmayan hesap **Orphaned Account** olarak değerlendirilebilir.

Örneğin eski proje için oluşturulan service account hâlâ production erişimine sahip olabilir.

Bu nedenle cloud IAM'de ownership kritik governance konusudur.

### Third-Party IAM Riski Nedir?

Cloud ortamına;

MSP,

vendor,

consultant,

partner

gibi üçüncü taraflar erişebilir.

Bu erişimler sıklıkla geçici başlar ancak kalıcı hale gelir.

Bu nedenle third-party account'lar için;

MFA,

time-limited access,

minimum privilege,

activity monitoring

uygulanmalıdır.

### Federation Nedir?

**Identity Federation**, kurumun kendi identity provider'ı üzerinden cloud servisine authentication yapmasını sağlar.

Örneğin kullanıcı kurumsal Entra ID hesabıyla AWS'e erişebilir.

Bu yaklaşım ayrı cloud parolalarını azaltır.

Ancak merkezi identity provider çok kritik hale gelir.

### SSO Cloud Security'yi Güçlendirir mi?

Doğru yapılandırıldığında evet.

**Single Sign-On – SSO** sayesinde;

merkezi MFA,

Conditional Access,

user lifecycle

uygulanabilir.

Ancak SSO provider compromise olursa birçok cloud servisi aynı anda etkilenebilir.

Bu nedenle merkezi identity güvenliği çok yüksek seviyede tutulmalıdır.

### MFA Cloud Admin Hesaplarında Zorunlu Olmalı mı?

Kritik privileged hesaplarda güçlü MFA temel güvenlik kontrolü olarak değerlendirilmelidir.

Ancak tüm MFA yöntemleri aynı güvenlik seviyesinde değildir.

SMS veya basic push yerine phishing-resistant authentication tercih edilebilir.

Özellikle tenant owner, root ve cloud admin hesaplarında daha güçlü authentication önemlidir.

### MFA Cloud API Credential'ı Korur mu?

Her zaman değil.

Bir saldırgan static access key ele geçirirse interactive MFA sürecine ihtiyaç duymayabilir.

Bu nedenle cloud IAM güvenliği yalnızca kullanıcı login MFA'ına odaklanmamalıdır.

API credential ve machine identity de korunmalıdır.

### Privilege Escalation Cloud'da Nasıl Gerçekleşir?

Saldırganın doğrudan Administrator olması gerekmez.

Bazı permission'lar dolaylı olarak daha yüksek yetkiye ulaşmaya izin verebilir.

Örneğin kullanıcı;

yeni credential oluşturabilir,

role policy değiştirebilir,

yüksek yetkili function'ı değiştirebilir,

service identity impersonate edebilir.

Bu tür zincirler cloud privilege escalation riskidir.

### IAM PassRole Riski Nedir?

AWS ortamında belirli senaryolarda kullanıcı başka bir service'e role atama yetkisine sahip olabilir.

Bu permission aşırı genişse kullanıcı kendi mevcut yetkisinden daha güçlü role sahip bir resource oluşturabilir.

Bu nedenle PassRole benzeri yetkiler dikkatli sınırlandırılmalıdır.

Bu örnek cloud IAM'de permission'ın görünen isminden daha fazla etki yaratabileceğini gösterir.

### Service Account Impersonation Nedir?

Bazı cloud platformlarında kullanıcı belirli bir service account adına işlem yapma yetkisine sahip olabilir.

Eğer service account daha yüksek privilege'a sahipse bu durum privilege escalation'a dönüşebilir.

Bu nedenle impersonation yetkileri kritik olarak değerlendirilmelidir.

### Role Assignment Permission Neden Çok Kritiktir?

Bir kullanıcı yeni role atayabiliyorsa kendisine veya kontrol ettiği identity'ye daha yüksek permission verebilir.

Bu nedenle;

role assignment,

policy modification,

IAM administration

yetkileri en yüksek riskli permission kategorilerindendir.

### Cloud Attack Path Analysis Nedir?

Cloud IAM ortamında tek tek permission'ları değerlendirmek zor olabilir.

Bu nedenle kullanıcıdan kritik varlığa giden yetki zincirleri analiz edilir.

Örneğin:

Compromised Developer

↓

Can Modify Function

↓

Function Uses Privileged Identity

↓

Can Read Secret Vault

↓

Database Admin Credential

↓

Critical Database

Bu zincir bir **Cloud Attack Path**'tir.

### Attack Path Analysis Neden Liste Tabanlı IAM Review'dan Daha İyi Olabilir?

IAM review yüzlerce permission gösterebilir.

Ancak hepsi aynı riskte değildir.

Attack path yaklaşımı şu soruyu sorar:

**“Bu permission gerçek saldırgana ne kazandırıyor?”**

Böylece güvenlik ekipleri en kritik privilege zincirlerine odaklanabilir.

### Choke Point Cloud IAM'de Nedir?

Birden fazla saldırı yolunun ortak geçtiği identity veya permission **Choke Point** olabilir.

Örneğin tek bir service account 40 farklı attack path'in merkezindeyse bu hesabın yetkisini düzeltmek çok büyük risk azaltımı sağlayabilir.

Bu yaklaşım remediation önceliklendirmesinde çok değerlidir.

### Toxic Combination IAM'de Nasıl Oluşur?

Tek başına kritik görünmeyen birkaç bulgu birlikte büyük risk yaratabilir.

Örneğin;

Public VM

Remote Code Execution vulnerability

High Privilege Managed Identity

Secret Vault Access

birlikte kritik cloud compromise path oluşturabilir.

Bu nedenle cloud IAM diğer güvenlik katmanlarından ayrı incelenmemelidir.

### CIEM Overprivilege'ı Nasıl Tespit Eder?

CIEM platformları verilen permission ile kullanılan permission'ları karşılaştırabilir.

Örneğin kullanıcı:

600 permission'a sahip.

Son 90 günde yalnızca 15 permission kullanmış.

Bu durumda role küçültülebilir.

Bu yaklaşıma **Rightsizing Permissions** denebilir.

### Rightsizing Nedir?

**Permission Rightsizing**, kimliğin sahip olduğu yetkileri gerçek kullanım ihtiyacına göre azaltma sürecidir.

Ama otomatik öneriler doğrudan production'a uygulanmamalıdır.

Çünkü bazı yetkiler nadiren kullanılan disaster recovery veya emergency işlemleri için gerekli olabilir.

Business owner doğrulaması gerekir.

### Access Review Cloud IAM'de Nasıl Yapılır?

Periyodik olarak;

kullanıcılar,

roller,

service identities,

third-party access

gözden geçirilir.

Sorular:

Bu kullanıcı hâlâ şirkette mi?

Bu role hâlâ ihtiyacı var mı?

Bu vendor'ın erişimi devam etmeli mi?

Bu service account hâlâ kullanılıyor mu?

Bu kontroller privilege creep'i azaltır.

### Joiner-Mover-Leaver Cloud IAM'de Neden Önemlidir?

Çalışan şirkete geldiğinde doğru access verilmelidir.

Departman değiştirdiğinde eski access kaldırılmalıdır.

Şirketten ayrıldığında bütün cloud erişimleri kapatılmalıdır.

Sadece kurumsal e-posta hesabını kapatmak yeterli değildir.

Ayrı cloud account veya access key bulunabilir.

### Cloud IAM'de Group Kullanımı Neden Tercih Edilir?

Yetkileri tek tek kullanıcılara vermek yönetim karmaşası yaratır.

Bunun yerine;

Finance-ReadOnly,

Cloud-Network-Admins,

DevOps-Production

gibi gruplar kullanılabilir.

Ama group membership sürekli review edilmelidir.

### Nested Groups Risk Oluşturabilir mi?

Grup başka grubun üyesi olduğunda gerçek effective permission'ı anlamak zorlaşabilir.

Büyük identity yapılarda nested group ilişkileri görünürlüğü azaltabilir.

Bu nedenle permission graph analizi önemlidir.

### Resource-Based Policy Nedir?

Bazı cloud servislerinde erişim yalnızca identity policy ile belirlenmez.

Resource'un kendisi de policy içerebilir.

Örneğin storage bucket:

“Şu dış account erişebilir.”

diyebilir.

Bu nedenle IAM assessment hem identity-based hem resource-based policy'leri incelemelidir.

### Cross-Account Access Nedir?

Bir cloud account başka account içerisindeki kaynağa erişebilir.

Bu büyük organizasyonlarda normaldir.

Ancak yanlış yapılandırılmış cross-account trust saldırı yolu oluşturabilir.

Özellikle third-party ve eski account trust'ları düzenli kontrol edilmelidir.

### External Principal Nedir?

Cloud kaynağına kurum dışındaki başka bir account, tenant veya identity erişiyorsa bu external principal olarak değerlendirilebilir.

Her external trust için;

owner,

business justification,

expiration

bulunmalıdır.

### Public Access ile Authenticated External Access Aynı Şey midir?

Hayır.

Public access herkesin kaynağa erişebilmesini sağlayabilir.

External authenticated access ise belirli başka tenant veya account'a erişim verir.

İkincisi daha kontrollüdür ancak yine third-party trust riskine sahiptir.

### Cloud IAM Logging Neden Gereklidir?

IAM değişiklikleri kritik güvenlik olaylarıdır.

Örneğin;

yeni admin role,

new access key,

policy update,

user creation,

MFA disable,

trust policy change

loglanmalıdır.

Bu olaylar SIEM üzerinde yüksek değerli use case'lerdir.

### Yeni Access Key Oluşturulması Alarm Üretmeli mi?

Risk seviyesine göre evet.

Özellikle;

root,

privileged user,

rarely used service account

için yeni access key oluşturulması önemli security event olabilir.

SOC change kaydıyla karşılaştırabilir.

### IAM Policy Değişikliği Neden İzlenmeli?

Saldırgan persistence veya privilege escalation için IAM policy değiştirebilir.

Örneğin kendisine ek permission verir.

Bu nedenle high-risk policy changes alarm üretmelidir.

### Admin Role Assignment Nasıl İzlenmeli?

Yeni Owner, Global Admin veya Administrator role assignment nadir gerçekleşir.

Bu nedenle yüksek priority ile izlenebilir.

SOC şu soruları kontrol edebilir:

Kim atadı?

Kime atandı?

Hangi IP'den?

Change request var mı?

JIT activation mı?

### MFA Disable Olayı Neden Kritik?

Privileged account üzerinde MFA'nın kapatılması çok ciddi alarm olabilir.

Bu işlem saldırganın daha kolay persistence sağlamasına yardımcı olabilir.

Bu nedenle MFA policy değişiklikleri de security monitoring kapsamına alınmalıdır.

### IAM Detection Use Case Örnekleri

SOC tarafında şu use case'ler düşünülebilir:

#### Privileged Role Assigned

#### New Access Key Created

#### MFA Disabled

#### Service Account Key Created

#### IAM Policy Modified

#### Cross-Account Trust Added

#### Dormant Identity Login

#### Unusual Role Assumption

#### High-Risk API Activity

Bu use case'ler kurum bağlamına göre özelleştirilmelidir.

### Unusual Role Assumption Nedir?

Bir kullanıcı normalde hiç kullanmadığı privileged role'ü beklenmeyen lokasyon veya saatten assume ederse anomali olabilir.

Örneğin normalde developer yalnızca test role kullanıyor.

Gece production-admin role aktive edildi.

Bu durum araştırılmalıdır.

### Impossible Travel Cloud IAM'de Kullanılır mı?

Human user login'lerinde coğrafi anomali sinyali kullanılabilir.

Ancak cloud CLI ve automation aktivitelerinde IP'ler farklı cloud egress noktalarından gelebilir.

Bu nedenle machine identity ve human identity detection'ları ayrı tasarlanmalıdır.

### Machine Identity Anomaly Nasıl Tespit Edilir?

Bir service account normalde yalnızca belirli API'yi kullanıyor olabilir.

Bir anda;

IAM,

KMS,

storage

API'lerini kullanmaya başladıysa anomali olabilir.

Bu nedenle behavior baseline machine identity için de uygulanabilir.

### Cloud IAM ile SIEM Entegrasyonu

Cloud audit log'ları SIEM'e gönderildiğinde IAM olayları diğer güvenlik sinyalleriyle korele edilebilir.

Örneğin:

GitHub secret exposure

AWS unusual API login

New IAM role

S3 bulk download

tek saldırı zinciri olabilir.

Bu korelasyon cloud Incident Response için çok değerlidir.

### IAM ile EDR Nasıl Birleştirilir?

Saldırgan developer laptop'ında infostealer çalıştırmış olabilir.

EDR bunu tespit eder.

Ardından aynı cihazdaki cloud access key kullanılabilir.

Eğer EDR ve Cloud IAM logları birlikte görülürse saldırı daha hızlı anlaşılır.

Bu nedenle endpoint ve cloud identity telemetry'si birleştirilmelidir.

### Cloud IAM Incident Response Nasıl Yapılır?

Bir identity compromise olduğunda yalnızca password değişikliği yeterli olmayabilir.

Kontrol edilmesi gerekenler:

aktif session ve token'lar,

access key'ler,

new credentials,

role assignments,

policy changes,

resource changes,

secret access,

data downloads.

Saldırgan yeni persistence yöntemi oluşturmuş olabilir.

### Compromised Access Key Durumunda Ne Yapılır?

Genel olarak;

key disable/revoke,

activity review,

related resources analysis,

new credential search

yapılmalıdır.

Ancak key hemen silinmeden önce investigation için hangi aktivitelerde kullanıldığı kaydedilmelidir.

Incident Response prosedürü kurum tarafından önceden belirlenmelidir.

### Credential Rotation Nedir?

**Credential Rotation**, parola, key veya secret'ın belirli aralıklarla veya olay sonrasında değiştirilmesidir.

Ancak körü körüne sık rotasyon operasyonel problem yaratabilir.

Daha güçlü yaklaşım static credential kullanımını azaltmaktır.

### Secret Rotation Neden Otomatik Olmalıdır?

Yüzlerce service account için manuel rotation sürdürülebilir değildir.

Secret vault ve automation ile;

credential oluşturma,

dağıtım,

rotation

otomatikleştirilebilir.

Ancak uygulamaların yeni credential'a kesintisiz geçebilmesi gerekir.

### Break Glass Cloud Account Nedir?

Cloud identity sistemi veya federation altyapısı başarısız olduğunda emergency erişim için kullanılabilen hesap türüdür.

Bu hesap;

normal operasyon için kullanılmamalı,

çok sıkı korunmalı,

her kullanımında alarm üretmelidir.

Ayrıca düzenli olarak çalıştığı doğrulanmalıdır.

### Federation Failure Durumunda Ne Olur?

Kurum cloud'a yalnızca SSO üzerinden erişiyorsa identity provider kesintisi tüm yönetim erişimini etkileyebilir.

Bu nedenle emergency access planı hazırlanmalıdır.

Security ile availability arasında denge kurulmalıdır.

### Cloud IAM Backup Edilir mi?

IAM yapısının “backup” kavramı klasik dosya backup'ından farklıdır.

Ancak;

policy,

role,

group,

trust configuration

gibi kritik identity konfigürasyonlarının Infrastructure as Code veya configuration export ile versiyonlanması faydalı olabilir.

Bu recovery ve audit açısından değer sağlar.

### Infrastructure as Code IAM Güvenliğini Nasıl Güçlendirir?

Role ve policy'ler Terraform gibi IaC ile tanımlanırsa;

code review,

version control,

security scanning,

approval

uygulanabilir.

Böylece portal üzerinden yapılan kontrolsüz değişiklikler azaltılır.

### IAM Policy as Code Nedir?

Security policy'nin kodla tanımlanmasıdır.

Örneğin:

“Production ortamında wildcard admin policy oluşturulamaz.”

kuralı CI/CD üzerinde kontrol edilebilir.

Bu sayede risk deployment öncesinde yakalanır.

### Wildcard Permission Neden Risklidir?

IAM policy içerisinde:

*

çok geniş resource veya action kapsamını ifade edebilir.

Örneğin bütün resource'larda bütün işlemlere izin vermek yüksek risklidir.

Ancak bazı teknik servislerde belirli wildcard kullanımları operasyonel olarak gerekli olabilir.

Bu nedenle bağlama göre değerlendirilmelidir.

### Deny Policy Neden Önemlidir?

Bazı cloud IAM modellerinde explicit deny mekanizması kritik koruma sağlayabilir.

Örneğin organization seviyesinde:

“Hiçbir kullanıcı security logging'i kapatamaz.”

gibi guardrail uygulanabilir.

Bu, yerel administrator yetkisinin üzerinde koruma sağlayabilir.

### Guardrail Nedir?

**Guardrail**, cloud ekiplerinin hareket alanını güvenli sınırlar içerisinde tutan merkezi politikadır.

Örneğin;

public storage yasak,

belirli region dışı deployment yasak,

root key oluşturulamaz,

logging kapatılamaz.

Guardrail güvenliği developer'ın tek tek doğru karar vermesine bağımlı olmaktan çıkarır.

### AWS Service Control Policies – SCP Nedir?

AWS Organizations içerisinde **Service Control Policies – SCP**, account'lardaki maksimum permission sınırlarını belirlemek için kullanılabilir.

Örneğin child account administrator olsa bile belirli güvenlik servislerini kapatması engellenebilir.

Bu güçlü governance kontrolüdür.

### Azure Management Group Policy Neden Önemlidir?

Azure'da management group ve policy yapılarıyla subscription'lara merkezi guardrail uygulanabilir.

Örneğin;

public IP creation,

allowed region,

encryption

gibi politikalar kontrol edilebilir.

IAM güvenliği cloud governance ile birlikte ele alınmalıdır.

### Organization-Level Policy Nedir?

GCP gibi platformlarda organization seviyesinde policy uygulanarak bütün project'ler için merkezi kısıtlamalar oluşturulabilir.

Bu yapı büyük cloud organizasyonlarında security baseline'ı korur.

### Separation of Duties Cloud IAM'de Nasıl Uygulanır?

Aynı kişinin;

kod geliştirmesi,

production deploy etmesi,

security policy değiştirmesi,

logları silmesi

yüksek risk oluşturabilir.

Görevler ayrılığı ile kritik işlemler farklı roller arasında dağıtılabilir.

Özellikle financial ve regulated sistemlerde önemlidir.

### Maker-Checker Modeli Nedir?

Bir kişi değişiklik yapar.

Başka yetkili kişi onaylar.

Bu yapı **Maker-Checker** veya four-eyes principle olarak bilinir.

Cloud IAM role assignment ve kritik production değişikliklerinde uygulanabilir.

### Cloud IAM Access Certification Nedir?

Periyodik olarak yöneticiler kendi ekiplerinin erişimlerini onaylayabilir.

Örneğin üç ayda bir:

Bu kullanıcı Production Admin olmaya devam etmeli mi?

Bu vendor access'e hâlâ ihtiyaç duyuyor mu?

Bu süreç **Access Certification** veya Access Review olarak bilinir.

### Cloud IAM Security Assessment Nedir?

**Cloud IAM Security Assessment**, cloud ortamındaki kullanıcıların, rollerin, service account'ların, credential'ların ve permission ilişkilerinin sistematik olarak incelenmesidir.

Bu çalışma;

identity inventory,

privilege analysis,

effective permission,

attack path,

credential hygiene,

logging

alanlarını kapsayabilir.

Amaç sadece admin kullanıcı sayısını listelemek değildir.

**Gerçek privilege riskini anlamaktır.**

### Cloud IAM Assessment Nasıl Yapılır?

Genel yaklaşım şöyle olabilir:

#### \1. Identity Discovery

Human ve machine identity'ler çıkarılır.

#### \2. Privileged Role Analysis

Admin roller incelenir.

#### \3. Effective Permission Analysis

Gerçek yetkiler hesaplanır.

#### \4. Credential Review

Static key ve secret'lar değerlendirilir.

#### \5. Dormant Identity Review

Kullanılmayan hesaplar tespit edilir.

#### \6. Cross-Account Trust Review

Harici erişimler incelenir.

#### \7. Attack Path Analysis

Privilege escalation yolları bulunur.

#### \8. Logging Review

IAM olaylarının SOC görünürlüğü kontrol edilir.

#### \9. Remediation

Yetkiler minimuma indirilir.

#### \10. Retest

Yeni yapı tekrar doğrulanır.

### IAM Pentest ile IAM Assessment Arasındaki Fark

IAM Assessment:

**“Hangi permission riskli?”**

sorusuna cevap verir.

Yetkilendirilmiş cloud penetration test ise:

**“Bu permission zinciri gerçekten privilege escalation için kullanılabiliyor mu?”**

sorusunu test edebilir.

Her ikisi birlikte daha doğru cloud identity görünümü sağlar.

### CIEM ile CSPM Arasındaki Fark Nedir?

#### CSPM

Cloud configuration posture'a odaklanır.

Örneğin:

Public storage var mı?

Security Group açık mı?

#### CIEM

Kimlik ve permission'lara odaklanır.

Örneğin:

Kim fazla yetkili?

Hangi role privilege escalation sağlayabilir?

Modern CNAPP platformları bu yetenekleri bir araya getirebilir.

### CNAPP Cloud IAM'i Nasıl Kullanır?

CNAPP;

identity,

configuration,

workload,

vulnerability,

data

bağlamlarını birleştirebilir.

Örneğin:

Internet-facing workload

Critical CVE

Privileged Identity

Sensitive Data Access

birlikte tek yüksek riskli attack path olarak gösterilebilir.

Bu nedenle IAM riskinin gerçek bağlamı daha iyi anlaşılır.

### Cloud IAM KPI'ları Nelerdir?

Örnek metrikler:

#### Privileged Identity Count

#### Standing Admin Count

#### Dormant Account Count

#### Long-Lived Key Count

#### MFA Coverage

#### Phishing-Resistant MFA Coverage

#### Overprivileged Identity Count

#### Unused Permission Ratio

#### Critical Attack Path Count

#### Third-Party Access Count

#### Access Review Completion Rate

Bu değerler IAM programının gelişimini ölçmeye yardımcı olabilir.

### Unused Permission Ratio Nedir?

Bir identity'nin sahip olduğu ancak gerçekte kullanmadığı permission oranıdır.

Örneğin:

200 permission verilmiş.

20 tanesi kullanılıyor.

Bu durumda ciddi rightsizing fırsatı olabilir.

Ancak kullanım süresi doğru seçilmelidir.

Yılda bir kullanılan DR permission yanlışlıkla kaldırılmamalıdır.

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

Evet, yönetim görünürlüğü için farklı alanlar puanlanabilir.

Örneğin:

Privileged Access – 70/100

Credential Hygiene – 85/100

Machine Identity – 60/100

Monitoring – 90/100

Ancak skor gerçek risklerin yerini almamalıdır.

Özellikle tek bir kritik attack path bütün skordan daha önemli olabilir.

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

Profesyonel rapor şu alanları içerebilir:

#### Executive Identity Risk Summary

Yönetim özeti.

#### Identity Inventory

Human ve machine identity'ler.

#### Privileged Access

Admin roller ve standing privileges.

#### Overprivilege Findings

Gereğinden fazla yetkiler.

#### Credential Risks

Static key ve secret'lar.

#### Cross-Account / Third-Party Access

Harici trust ilişkileri.

#### Attack Path Analysis

Privilege escalation yolları.

#### Monitoring Coverage

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

#### Remediation Roadmap

Önceliklendirilmiş iyileştirmeler.

Bu yaklaşım yüzlerce IAM bulgusunu gerçek risk hikâyesine dönüştürür.

### Cloud IAM Güvenliğinde En Büyük Hata Nedir?

En yaygın hata şudur:

**“Bu kullanıcıya admin verelim, işi görülsün.”**

Cloud ortamlarında geniş yetki vermek kolaydır.

Ancak bu yetkiler yıllarca kalabilir.

Sonuçta kurum onlarca sürekli administrator ve yüzlerce overprivileged machine identity ile karşılaşabilir.

Bu nedenle güvenli yaklaşım:

**Default Deny + Least Privilege + Temporary Access**

olmalıdır.

### Cloud IAM için Temel Güvenlik Kontrolleri

Kurumsal IAM stratejisinde şu katmanlar değerlendirilebilir:

#### Central Identity

SSO ve merkezi kullanıcı yönetimi.

#### Strong Authentication

MFA ve phishing-resistant yöntemler.

#### Least Privilege

Minimum permission.

#### JIT / PIM

Geçici privileged access.

#### Machine Identity Security

Service account ve workload identity yönetimi.

#### Credential Hygiene

Static key kullanımının azaltılması.

#### CIEM

Permission visibility.

#### Attack Path Analysis

Privilege zincirlerinin bulunması.

#### IAM Monitoring

SIEM ve SOC use case'leri.

#### Access Review

Yetkilerin periyodik doğrulanması.

Bu kontroller birbirini tamamlar.

### Cloud IAM Güvenliği Nasıl Olgunlaştırılır?

Başlangıç seviyesi:

Admin hesaplarını ve access key'leri listelemek olabilir.

Bir sonraki aşama:

MFA ve Least Privilege.

Daha ileri seviye:

PIM, JIT, access review ve machine identity governance.

Olgun yaklaşım ise:

**Continuous IAM Monitoring + CIEM + Attack Path Analysis + Automated Guardrails**

modelidir.

Amaç kimlik güvenliğini statik audit olmaktan çıkarmaktır.

### Sonuç: Cloud'da En Güçlü Güvenlik Duvarı Kimlik ve Yetki Yönetimidir

Modern cloud saldırganının her zaman exploit kullanması gerekmez.

Geçerli access key.

Çalınmış token.

Overprivileged service account.

Yanlış role assignment.

Geniş cross-account trust.

Bunlardan biri yeterli olabilir.

Bu nedenle Cloud IAM güvenliğinde sadece:

**“Parolalar güçlü mü?”**

sorusunu sormak yetersizdir.

Asıl sorular şunlardır:

#### Kaç kullanıcı sürekli admin?

#### Kaç service account gereğinden fazla yetkili?

#### Kaç static access key hâlâ aktif?

#### Third-party kullanıcılar nereye erişiyor?

#### Privilege escalation sağlayan permission chain var mı?

#### Admin role değişiklikleri SOC tarafından görülüyor mu?

#### Ele geçirilen normal kullanıcı kritik kaynağa hangi yollarla ulaşabilir?

Gerçek Cloud IAM Security;

**Least Privilege + Strong Authentication + JIT + PAM/PIM + CIEM + Credential Security + Attack Path Analysis + Continuous Monitoring**

ile oluşturulur.

Ve burada çok önemli bir başka gerçek ortaya çıkar:

Bir IAM yapısı kusursuz olabilir.

Ama cloud kaynağı yanlış yapılandırılmışsa yine veri sızıntısı veya internet exposure oluşabilir.

Bir storage bucket public olabilir.

Database internete açık olabilir.

Security Group yönetim portunu tüm dünyaya açabilir.

Audit logging kapalı olabilir.

Yani bulut güvenliğinin bir sonraki büyük risk alanı **Cloud Misconfiguration**'dır.