# Cloud IAM ve CIEM Nedir? AWS IAM, Azure RBAC, Google Cloud IAM ve Yetki Fazlalığı Riskleri

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/kimlik-ve-erisim-yonetimi/cloud-iam-ve-ciem-nedir

![Cloud IAM ve CIEM Nedir? AWS IAM, Azure RBAC, Google Cloud IAM ve Yetki Fazlalığı Riskleri](/images/bilgi-merkezi/covers/cover-pamiam-09.webp)

Cloud ortamlarında kimlik ve yetki yönetimi, geleneksel veri merkezi mimarisinden çok daha karmaşık hale gelmiştir. On-premises sistemlerde kullanıcıların belirli sunuculara, uygulamalara veya network kaynaklarına erişimi çoğu zaman Active Directory grupları, local administrator hesapları ve network seviyesindeki kontroller üzerinden yönetilirken; cloud platformlarında aynı kullanıcı, rol veya machine identity yüzlerce hatta binlerce farklı action permission'a sahip olabilir.

Bu nedenle cloud güvenliğinde asıl problem yalnız “kim login oldu?” sorusu değildir. Daha önemli soru şudur:

**“Bu identity cloud üzerinde tam olarak ne yapabilir?”**

Cloud IAM, yani **Cloud Identity and Access Management**, kullanıcıların, servis hesaplarının, uygulamaların ve workload identities'in cloud resources üzerinde hangi yetkilere sahip olduğunu belirleyen temel güvenlik katmanıdır. Ancak zaman içinde cloud environment büyüdükçe roles, policies ve permissions da büyür. Kullanıcılara geçici olarak verilen yetkiler kalıcı hale gelir, service principals gereğinden fazla privilege alır ve applications ihtiyaç duyduklarından çok daha geniş erişimle çalışmaya başlar.

Bu durum **Excessive Permissions**, **Overprivileged Identity**, **Permission Creep** ve **Cloud Entitlement Risk** gibi güvenlik problemlerini ortaya çıkarır.

CIEM, yani **Cloud Infrastructure Entitlement Management**, bu karmaşıklığı görünür hale getirmeyi ve cloud ortamındaki gereksiz, kullanılmayan veya yüksek riskli yetkileri azaltmayı amaçlayan güvenlik yaklaşımıdır.

Bu nedenle modern cloud identity security şu iki soruyu birlikte ele alır:

**Cloud IAM → Kim hangi yetkiye sahip?**

**CIEM → Bu yetkinin gerçekten gerekli olan kısmı ne kadar?**

Cloud güvenliğinin olgunlaşması, bu iki soruya sürekli ve doğru cevap verebilmekle mümkündür.

### Cloud IAM Nedir?

Cloud IAM, cloud ortamlarındaki users, groups, service accounts, applications ve workloads için authentication ve authorization süreçlerini yöneten yapıdır.

IAM burada yalnız user login anlamına gelmez.

Asıl kritik katman **authorization**, yani identity'nin cloud üzerinde hangi işlemleri gerçekleştirebileceğinin belirlenmesidir.

Örneğin bir user:

virtual machine oluşturabilir,

storage account okuyabilir,

database silebilir,

network configuration değiştirebilir,

IAM role atayabilir

veya security logs'u kapatabilir.

Bu actions permissions üzerinden kontrol edilir.

Cloud provider'lar bu yetkileri farklı isim ve modellerle yönetir ancak temel prensip aynıdır:

**Identity + Role/Policy + Resource + Action**

Cloud authorization modelinin temel yapısını oluşturur.

### AWS IAM Nedir?

AWS IAM, Amazon Web Services ortamında users, roles, policies ve permissions'ın yönetilmesini sağlayan temel identity and access management service'idir.

AWS IAM modelinde bir identity'ye belirli actions için permissions verilebilir.

Örneğin:

EC2 instances üzerinde işlem yapmak,

S3 buckets okumak,

IAM roles yönetmek,

Lambda functions çalıştırmak

gibi actions policy üzerinden tanımlanabilir.

Ancak AWS IAM'in güçlü yanı aynı zamanda karmaşıklık kaynağıdır.

Çok granular permission modeli nedeniyle zaman içerisinde policy'ler genişleyebilir.

Örneğin bir developer yalnız belirli S3 bucket'a read access'e ihtiyaç duyarken:

AmazonS3FullAccess

gibi broad policy verilirse gereğinden fazla yetki oluşabilir.

Bu **Excessive Permission** problemidir.

### AWS Root Account Neden Kritik?

AWS account oluşturulduğunda root user bulunur.

Root user çok geniş yetkiye sahiptir ve günlük operasyonlarda kullanılmamalıdır.

Root account compromise edilirse impact son derece yüksek olabilir.

Bu nedenle root account için:

strong MFA,

restricted usage,

monitoring

uygulanmalı ve normal administration için IAM roles kullanılmalıdır.

Root access yalnız gerçekten gerekli emergency scenarios için saklanmalıdır.

Bu, cloud privileged access güvenliğinin temel prensiplerinden biridir.

### IAM User Yerine IAM Role Kullanmak Neden Daha Güvenlidir?

Traditional yaklaşımda kullanıcı veya application için long-lived access key oluşturulabilir.

Bu credentials yıllarca kullanılabilir.

Attacker access key ele geçirirse cloud environment'a erişebilir.

IAM Role ve temporary credentials modeli ise daha güvenli olabilir.

User veya workload role assume eder.

Temporary credential oluşturulur.

Credential belirli süre sonra expire olur.

Bu yaklaşım:

**Static Credential → Temporary Credential**

dönüşümünü sağlar.

Bu da cloud security'nin en önemli prensiplerinden biridir.

### Azure RBAC Nedir?

Azure RBAC, yani Role-Based Access Control, Azure resources üzerinde hangi identity'nin hangi actions'ı gerçekleştirebileceğini yönetir.

Örneğin roles:

Owner

Contributor

Reader

gibi broad roles olabilir.

Daha granular custom roles da oluşturulabilir.

Problem, kullanıcıya kolaylık nedeniyle sürekli:

Owner

veya:

Contributor

verilmesidir.

Bu durumda Least Privilege prensibi bozulur.

Azure ortamlarında özellikle Subscription Owner ve Global Administrator gibi high-impact permissions minimum sayıda identities üzerinde bulunmalıdır.

### Azure RBAC ile Entra ID Arasındaki İlişki

Microsoft Entra ID identity authentication ve directory services sağlar.

Azure RBAC ise Azure resources üzerindeki authorization'ı yönetir.

Örneğin user Entra ID üzerinden authenticate olur.

Ancak hangi Azure subscription veya resource group üzerinde ne yapabileceği RBAC role assignments ile belirlenir.

Bu nedenle:

#### Authentication ≠ Authorization

ayrımı cloud ortamında özellikle önemlidir.

User güçlü MFA ile doğru şekilde authenticate olmuş olabilir.

Ancak üzerinde gereğinden fazla Azure permissions bulunuyorsa risk devam eder.

### Google Cloud IAM Nedir?

Google Cloud IAM, Google Cloud resources üzerinde users, groups, service accounts ve diğer principals için authorization sağlar.

Permissions roles içerisinde gruplanabilir.

Predefined roles veya custom roles kullanılabilir.

Google Cloud'da da broad roles zaman içerisinde risk oluşturabilir.

Örneğin:

Owner

Editor

gibi çok geniş permissions yerine task-specific roles tercih edilmelidir.

Bu cloud least privilege yaklaşımıdır.

### Cloud IAM'de Least Privilege Neden Zordur?

Teoride Least Privilege basittir:

**Kullanıcıya yalnız ihtiyaç duyduğu permission verilmelidir.**

Ancak pratikte cloud permissions son derece karmaşıktır.

Bir application çalışmak için onlarca API permission kullanabilir.

Developer hangi permission'ın gerekli olduğunu tam bilemeyebilir.

Bu nedenle kolay çözüm:

“Full Access verelim, sistem çalışsın.”

olabilir.

Bu yaklaşım operational problemi çözer ancak security debt oluşturur.

Zaman içinde broad permissions normal hale gelir.

Bu nedenle cloud security'nin temel sorunlarından biri:

**Functionality First → Security Later**

yaklaşımıdır.

CIEM bu biriken security debt'i görünür hale getirmeye yardımcı olur.

### CIEM Nedir?

CIEM, Cloud Infrastructure Entitlement Management, cloud ortamlarında identity'lerin sahip olduğu permissions'ı analiz ederek excessive, unused ve risky entitlements'ı tespit etmeyi amaçlayan security approach'tur.

CIEM yalnız user'ın hangi role sahip olduğunu göstermez.

Aynı zamanda:

hangi permissions gerçekten kullanılıyor,

hangileri hiç kullanılmıyor,

hangi access paths high-risk,

hangi identities overprivileged

sorularına cevap vermeye çalışır.

Bu nedenle CIEM cloud Least Privilege implementation için önemli araçtır.

#### Entitlement Nedir?

Cloud environment'da entitlement, identity'nin resource üzerinde gerçekleştirebildiği action veya permission'dır.

Örneğin:

Read Object

Delete VM

Create IAM Role

Modify Network Rule

Read Secret

birer entitlement olabilir.

Bir role yüzlerce entitlement içerebilir.

User'ın aslında yalnız birkaç tanesini kullanıyor olması yaygın bir durumdur.

#### Excessive Permission Nedir?

Excessive Permission, identity'nin business veya technical need'inden daha fazla privilege'a sahip olmasıdır.

Örneğin developer yalnız log okumaya ihtiyaç duyuyor olabilir.

Ancak Contributor role verilmişse resource değiştirme veya silme yetkisine de sahip olabilir.

Bu attacker için blast radius'u büyütür.

User account compromise olduğunda attacker user'ın bütün permissions'ını kullanabilir.

Bu nedenle identity'nin unused permissions'ı bile attacker's opportunity haline gelir.

#### Permission Creep Cloud Ortamında Nasıl Oluşur?

Cloud environments hızlı değişir.

User yeni project'e katılır.

Role eklenir.

Project biter.

Role kaldırılmaz.

Başka team'e geçer.

Yeni permissions eklenir.

Zaman içerisinde identity'nin entitlement set'i sürekli büyür.

Bu **Permission Creep** olarak adlandırılır.

Traditional IGA bu problemi user lifecycle açısından ele alabilir.

CIEM ise actual cloud permission usage üzerinden daha teknik visibility sağlar.

### Used Permission ve Granted Permission Arasındaki Fark

Cloud security için en değerli analizlerden biri:

#### Granted Permissions

ile

#### Actually Used Permissions

arasındaki farktır.

Örneğin role 200 permission içeriyor.

User son 90 günde yalnız 7 permission kullanmış.

Bu durumda kalan 193 permission potansiyel excessive privilege olabilir.

Elbette kullanılmayan permission her zaman gereksiz değildir.

Emergency operations için gerekli olabilir.

Ancak risk-based review gerektirir.

CIEM bu farkı görünür hale getirir.

#### Permission Gap Nedir?

Permission Gap, identity'nin sahip olduğu toplam privileges ile gerçekten kullandığı privileges arasındaki fark olarak düşünülebilir.

Gap büyüdükçe overprivilege ihtimali artar.

Bu nedenle modern cloud security KPI'larından biri:

#### Unused Permission Ratio

olabilir.

Bu oran cloud least privilege maturity'sini ölçmek için değerlendirilebilir.

### CIEM ve IGA Arasındaki Fark

IGA organization genelinde access governance'a odaklanır.

Access reviews,

approvals,

role lifecycle,

SoD,

entitlement certification

IGA'nın temel alanlarıdır.

CIEM ise cloud infrastructure permissions üzerinde daha teknik analytics sağlar.

Örneğin IGA:

“Ahmet Developer Role'a sahip olmalı mı?”

sorusunu sorar.

CIEM ise:

“Developer Role içerisinde 120 permission var ama Ahmet bunların yalnız 8'ini kullanıyor.”

bilgisini sağlar.

Bu nedenle IGA ve CIEM birbirini tamamlar.

### CIEM ve CSPM Arasındaki Fark

CSPM, yani Cloud Security Posture Management, cloud configuration risklerini analiz eder.

Örneğin:

public storage bucket,

open firewall rule,

unencrypted database

gibi misconfigurations tespit edebilir.

CIEM ise permissions ve identities üzerinde yoğunlaşır.

Basitleştirirsek:

**CSPM → Resource Configuration Risk**

**CIEM → Identity Permission Risk**

Modern CNAPP architectures içerisinde bu capabilities birlikte sunulabilir.

### Cloud IAM ve CNAPP İlişkisi

CNAPP, Cloud-Native Application Protection Platform, cloud security'nin farklı katmanlarını bir araya getiren geniş bir yaklaşım olabilir.

Bu architecture içerisinde:

CSPM,

CWPP,

CIEM,

Kubernetes Security,

Vulnerability Management

gibi capabilities bulunabilir.

Identity permissions cloud attack paths'in önemli kısmını oluşturduğu için CIEM modern CNAPP architecture'ın kritik bileşenlerinden biridir.

### Service Principal Nedir?

Service Principal, application veya automation process tarafından kullanılan machine identity'dir.

Human user gibi interactive login yapmaz.

Application API üzerinden resource access sağlayabilir.

Service principals yüksek privilege taşıyabilir.

Örneğin deployment pipeline'ın Contributor veya Owner access'i olabilir.

Bu nedenle service principal security cloud IAM'in en kritik alanlarındandır.

#### Service Principal Secret Neden Risklidir?

Service principal authentication için client secret kullanılabilir.

Bu secret source code veya CI/CD configuration içerisinde hardcoded olarak tutulursa attacker tarafından ele geçirilebilir.

Bu nedenle:

Secrets Vault,

Certificate-Based Authentication,

Workload Identity,

Managed Identity

gibi daha güvenli models kullanılabilir.

Amaç long-lived static secret kullanımını azaltmaktır.

### Managed Identity Nedir?

Managed Identity, cloud platform tarafından lifecycle'ı yönetilen machine identity modelidir.

Application manuel secret saklamak yerine platform-managed identity kullanabilir.

Bu sayede:

secret creation,

rotation,

storage

gibi operational risks azalabilir.

Bu Non-Human Identity Security açısından önemli avantaj sağlar.

### Workload Identity Nedir?

Workload Identity, application, container, serverless function veya automation process gibi workload'ların authentication için kullandığı identity'dir.

Modern cloud-native architecture içerisinde workload identities human users'dan çok daha fazla olabilir.

Bu nedenle cloud IAM strategy yalnız employees üzerine kurulamaz.

Human ve Machine Identities birlikte yönetilmelidir.

#### Workload Identity Federation Neden Önemlidir?

Workload Identity Federation, external workloads'ın long-lived static cloud credentials tutmadan temporary identity token üzerinden cloud resources'a erişmesini sağlayabilir.

Bu yaklaşım DevOps ve multi-cloud environments için önemlidir.

Örneğin CI/CD platform üzerinde permanent cloud access key saklamak yerine temporary federated identity kullanılabilir.

Bu:

**Stored Credential → Federated Temporary Credential**

dönüşümüdür.

### Cloud Access Key Riski

Long-lived cloud access keys attacker için değerli credentials'dır.

Source code repository,

developer laptop,

CI/CD pipeline,

configuration file

içerisinde sızabilir.

Bu nedenle access key inventory yapılmalıdır.

Unused keys kaldırılmalıdır.

Regular rotation uygulanmalıdır.

Mümkün olduğunda short-lived credentials'a geçilmelidir.

### Temporary Credentials Neden Önemlidir?

Temporary Credentials belirli süre geçerli olur.

Credential compromise edilse bile attacker'ın kullanım süresi sınırlıdır.

Bu security principle şu şekilde özetlenebilir:

**Credential Lifetime = Attack Opportunity Window**

Credential ne kadar kısa süre geçerliyse compromise sonrası attack window o kadar dar olabilir.

Bu nedenle cloud identity architecture long-lived credentials'tan short-lived credentials'a geçmelidir.

### JIT Cloud Access Nedir?

Just-in-Time Cloud Access, user'ın high privilege role'ü sürekli taşımaması, yalnız ihtiyaç anında temporary olarak activate etmesi yaklaşımıdır.

Örneğin Azure Subscription Owner role permanent olmak yerine PIM ile temporary activate edilebilir.

AWS ortamında high-privilege role temporary assume edilebilir.

Bu Zero Standing Privilege yaklaşımının cloud implementation'ıdır.

### Zero Standing Privilege Cloud'da Nasıl Uygulanır?

Cloud identities üzerinde permanent admin rights minimum seviyede tutulur.

User normalde standard access taşır.

İhtiyaç anında:

strong authentication,

approval,

justification

ile temporary privilege alır.

İşlem bitince permission expire olur.

Bu:

#### Always Admin

yerine:

#### Admin When Needed

modelidir.

### Permission Boundaries ve Guardrails Neden Önemlidir?

Cloud IAM yalnız permission vermekle değil, maksimum yetki sınırı belirlemekle de ilgilidir.

Organization-level policies,

permission boundaries,

service control policies

gibi controls broad guardrails oluşturabilir.

Amaç individual administrator'ın yanlışlıkla veya bilinçli şekilde security boundary dışına çıkmasını engellemektir.

Bu defense-in-depth yaklaşımıdır.

### Role Explosion Cloud'da Neden Oluşur?

Least Privilege uygulanırken çok fazla custom role oluşturulabilir.

Her project için ayrı role.

Her application için ayrı role.

Her department için farklı variation.

Zaman içerisinde yüzlerce role oluşur.

Bu **Role Explosion** olarak adlandırılır.

Role sayısı arttıkça governance zorlaşır.

Bu nedenle balance gerekir.

Ne çok broad roles,

ne de yönetilemez kadar granular roles.

### Cloud Role Mining

CIEM ve analytics tools usage patterns üzerinden role optimization önerileri sağlayabilir.

Örneğin 50 developer'ın actual permissions usage'ı analiz edilir.

Ortak pattern üzerinden daha küçük custom role önerilebilir.

Bu traditional IGA Role Mining yaklaşımının cloud infrastructure versiyonudur.

### Cloud IAM Attack Path Nedir?

Cloud permissions doğrudan veya dolaylı privilege escalation path oluşturabilir.

Bir user doğrudan administrator olmayabilir.

Ancak:

new role create,

policy attach,

service account impersonate,

secret read

gibi permissions üzerinden higher privilege elde edebilir.

Bu nedenle yalnız role name'e bakmak yeterli değildir.

Permission relationships analiz edilmelidir.

Bu **Cloud Identity Attack Path Analysis** olarak düşünülebilir.

### Indirect Privilege Escalation

Cloud environment'da bazı permissions dolaylı olarak high privilege verebilir.

Örneğin user doğrudan admin değildir.

Ancak yüksek yetkili function'ın configuration'ını değiştirebilir.

Bu function high privilege identity ile çalışıyorsa attacker dolaylı privilege escalation sağlayabilir.

Bu nedenle CIEM yalnız direct permissions değil effective permissions ve attack paths'i analiz etmelidir.

### Effective Permission Nedir?

Effective Permission, identity'nin inheritance, groups, roles, policies ve resource-level permissions dahil edildiğinde gerçekte sahip olduğu toplam authorization level'dır.

Bir user UI üzerinde yalnız bir role sahip görünebilir.

Ancak nested groups veya inherited policies nedeniyle çok daha fazla privilege'a sahip olabilir.

Security analysis effective permissions üzerinden yapılmalıdır.

### Public Cloud'da Shared Account Kullanılmalı mı?

Hayır.

Cloud administration personal identities üzerinden yapılmalıdır.

Shared:

admin@company

gibi accounts accountability'yi azaltır.

Kim hangi değişikliği yaptı sorusu zorlaşır.

Personal Identity + JIT Role model tercih edilmelidir.

### Break-Glass Cloud Administrator Account

Cloud identity platform tamamen erişilemez olduğunda emergency administrator access gerekebilir.

Bu nedenle limited number of break-glass accounts tutulabilir.

Ancak bunlar:

daily operations'ta kullanılmamalı,

strongly protected,

monitored,

alerted

olmalıdır.

Her kullanım post-incident review gerektirebilir.

### Cloud IAM ve MFA

High privilege cloud roles phishing-resistant MFA ile korunmalıdır.

AWS, Azure veya Google Cloud administrator access yalnız password ile bırakılmamalıdır.

Strong MFA credential theft sonrası attacker's progress'ini zorlaştırır.

Ancak MFA tek başına excessive permission problemini çözmez.

Strong authentication + Least Privilege birlikte gereklidir.

### Cloud IAM ve Conditional Access

Cloud identity access decisions device ve risk context'e göre şekillendirilebilir.

Örneğin privileged cloud access yalnız:

managed device,

trusted identity,

strong MFA

ile mümkün olabilir.

Bu Zero Trust cloud administration yaklaşımıdır.

### Cloud IAM ve PAM

PAM traditional server credentials için kullanılırken cloud IAM daha role-driven olabilir.

Ancak iki yapı birbirine yaklaşmaktadır.

Cloud PAM use cases:

privileged role activation,

JIT access,

session control,

secret management,

third-party privileged access

alanlarını içerebilir.

Modern PAM strategy cloud privileges'ı scope dışı bırakmamalıdır.

### Third-Party Cloud Access Neden Risklidir?

Consultants, managed service providers veya vendors cloud environment'a temporary access alabilir.

Bu identities permanent access ile bırakılırsa risk oluşur.

Vendor access için:

time-bound role,

MFA,

approval,

least privilege,

monitoring

uygulanmalıdır.

Project bittiğinde access otomatik revoke edilmelidir.

### External Identity ve Guest Access

Cloud collaboration nedeniyle external identities organization resources'a erişebilir.

Guest accounts yıllarca aktif kalabilir.

Bu nedenle guest identity lifecycle governance önemlidir.

External user access:

business owner,

expiry date,

access review

ile yönetilmelidir.

### Cloud IAM ve IGA Entegrasyonu

IGA user lifecycle ve approvals yönetebilir.

CIEM actual cloud permissions usage analiz edebilir.

Bu iki data set birleştiğinde daha kaliteli access review yapılabilir.

Örneğin reviewer yalnız:

“User Contributor Role'a sahip.”

bilgisini değil:

“Bu role içerisindeki permissions'ın %92'si son 180 günde kullanılmadı.”

bilgisini de görebilir.

Bu access governance decision'ını güçlendirir.

### Cloud IAM ve ITDR

ITDR cloud identities'in suspicious behavior'ını detect edebilir.

Örneğin:

new admin role,

unusual token use,

service principal anomaly,

privilege escalation

identity threat signal olabilir.

CIEM posture riskini,

ITDR active threat'i

gösterir.

Bu iki katman birlikte önemlidir.

### CIEM ile SIEM/SOC Entegrasyonu

CIEM findings SOC incident prioritization için kullanılabilir.

Örneğin EDR user compromise alert üretiyor.

CIEM aynı identity'nin:

subscription owner,

database admin,

secret reader

permissions taşıdığını gösteriyor.

Bu durumda incident severity çok daha yüksek olmalıdır.

Bu:

**Threat × Entitlement = Impact**

yaklaşımıdır.

### Cloud Identity Risk Nasıl Hesaplanabilir?

Cloud identity risk birkaç faktör üzerinden değerlendirilebilir:

Privilege Level

Unused Permissions

Resource Sensitivity

Credential Type

Authentication Strength

Behavior Risk

örneğin birlikte kullanılabilir.

Bir identity:

high privilege,

long-lived access key,

no MFA,

unused broad permissions

taşıyorsa risk seviyesi yüksektir.

### AI Agent ve Cloud IAM

AI Agents cloud resources üzerinde action almaya başladıkça cloud IAM açısından yeni identity sınıfı ortaya çıkmaktadır.

Agent:

VM oluşturabilir,

storage okuyabilir,

database query yapabilir,

security remediation gerçekleştirebilir.

Bu durumda agent'a broad admin role vermek risklidir.

AI Agent için:

Unique Identity

Scoped Role

Temporary Credential

Task-Based Authorization

Audit Trail

uygulanmalıdır.

Agent yalnız yapması gereken action için permission almalıdır.

Bu modern **Agentic Cloud IAM** yaklaşımının temelidir.

### AI Agent için Owner Benzeri Role Neden Risklidir?

AI Agent hata yapabilir.

Prompt manipulation'a maruz kalabilir.

Yanlış action seçebilir.

Compromise olabilir.

Agent broad Owner role taşıyorsa hatanın blast radius'u çok büyük olur.

Bu nedenle AI Agents için:

#### Maximum Capability

değil:

#### Minimum Necessary Capability

tasarlanmalıdır.

Agent privilege güvenliği geleceğin cloud IAM programlarının önemli alanlarından biri olacaktır.

### Multi-Cloud IAM Neden Daha Zordur?

Birçok organization aynı anda:

AWS,

Azure,

Google Cloud

kullanabilir.

Her provider farklı IAM terminology ve authorization modeline sahiptir.

AWS Policy,

Azure RBAC,

Google Cloud Roles

farklı semantics kullanır.

Bu nedenle centralized visibility zorlaşır.

CIEM'in önemli avantajlarından biri multi-cloud entitlement data'yı ortak risk modelinde analiz edebilmesidir.

### Cloud Identity Fabric Yaklaşımı

Modern organizations'da workforce identity, cloud identity, SaaS access, privileged access ve machine identity farklı systems içerisinde yönetilir.

Identity Fabric yaklaşımı bu siloları daha bütünleşik hale getirmeyi amaçlar.

Cloud IAM bu fabric'in authorization katmanlarından biridir.

CIEM ise cloud entitlement intelligence sağlar.

Bu nedenle geleceğin identity architecture'ı ürün bazlı değil relationship bazlı tasarlanmalıdır.

### Cloud IAM Projesi Nasıl Başlatılmalı?

İlk adım bütün users'ın roles'ünü manuel olarak değiştirmek olmamalıdır.

Öncelikle:

Identity Inventory,

Role Inventory,

Service Account Inventory,

Access Key Inventory,

High-Privilege Role Inventory

oluşturulmalıdır.

Daha sonra high-risk identities belirlenmelidir.

Öncelik:

Root

Owner

Global Admin

IAM Admin

Security Admin

gibi broad privileged identities olabilir.

Sonraki aşamada unused permissions ve static credentials azaltılabilir.

### CIEM Projesi Nasıl Başlatılmalı?

CIEM implementation'ın ilk hedefi görünürlük olmalıdır.

Öncelikle cloud environments connect edilir.

Identities ve effective permissions çıkarılır.

Sonra:

unused permissions,

overprivileged identities,

high-risk combinations,

public exposure + high privilege

gibi findings analiz edilir.

Direkt otomatik permission removal riskli olabilir.

Önce observe,

sonra recommend,

sonra controlled remediation

yaklaşımı daha güvenlidir.

### Permission Remediation Nasıl Yapılmalı?

Bir permission'ın unused görünmesi hemen kaldırılması gerektiği anlamına gelmez.

Örneğin disaster recovery role yılda yalnız bir kez kullanılabilir.

Bu nedenle remediation sırasında:

Business Owner

Usage History

Criticality

Emergency Need

birlikte değerlendirilmelidir.

High-confidence unused permissions automate edilebilir.

Critical roles human approval gerektirebilir.

### Cloud IAM KPI'ları

Cloud identity security maturity şu metrics ile izlenebilir:

Permanent Admin Count

Root Account Usage

MFA Coverage

Phishing-Resistant MFA Coverage

Unused Permission Ratio

Overprivileged Identity Count

Long-Lived Access Key Count

Dormant Service Account Count

JIT Role Adoption

Temporary Credential Usage

Guest Account Expiry Rate

gibi KPI'lar kullanılabilir.

### CIEM KPI'ları

CIEM için daha spesifik metrics:

Effective Permission Reduction

Unused Entitlement Reduction

High-Risk Entitlement Count

Overprivileged Service Account Count

Permission Remediation Rate

Role Optimization Rate

Identity Attack Path Count

gibi göstergeler olabilir.

Amaç yalnız finding üretmek değil:

#### Privilege Surface Reduction

sağlamaktır.

### Cloud IAM ve CIEM'de En Sık Yapılan Hatalar

Kurumlarda şu hatalar sık görülür:

- Her developer'a broad Administrator role vermek
- AWS Root account'u günlük kullanmak
- Azure Owner role'ü permanent bırakmak
- Google Cloud Owner/Editor gibi geniş roles'i yaygın kullanmak
- Long-Lived Access Keys oluşturmak
- Access keys'i source code içinde saklamak
- Service Principal secrets'ı yıllarca değiştirmemek
- Managed Identity kullanma fırsatını değerlendirmemek
- Workload Identity Federation kullanmamak
- Unused permissions'ı analiz etmemek
- Permission Creep'i ölçmemek
- Guest Accounts için expiry belirlememek
- External vendors'a permanent cloud access vermek
- JIT/PIM kullanmamak
- MFA'yı privileged users için zorunlu tutmamak
- CIEM'i yalnız reporting tool olarak görmek
- IGA ile CIEM'i ayrı silolar halinde yönetmek
- Service Accounts ve Machine Identities'i governance dışında bırakmak
- Cloud IAM attack paths'i analiz etmemek
- AI Agent'lara broad admin permissions vermek

### Cloud IAM ve CIEM Güvenlik Kontrol Listesi

Kurumlar aşağıdaki kontrolleri değerlendirebilir:

- AWS Root kullanımı minimum mu?
- Root MFA aktif mi?
- Azure Owner assignments minimum mu?
- Global Administrator roles minimum mu?
- Google Cloud broad roles azaltılıyor mu?
- High-Risk Cloud Roles inventory'de mi?
- Permanent Admin roles azaltılıyor mu?
- JIT role activation kullanılıyor mu?
- Privileged users phishing-resistant MFA kullanıyor mu?
- Long-Lived Access Keys inventory'de mi?
- Unused Access Keys kaldırılıyor mu?
- Service Principal secrets rotate ediliyor mu?
- Managed Identity değerlendiriliyor mu?
- Workload Identity kullanılıyor mu?
- Temporary Credentials yaygınlaştırılıyor mu?
- CIEM kullanılıyor mu?
- Effective Permissions analiz ediliyor mu?
- Unused Permissions tespit ediliyor mu?
- Permission Creep ölçülüyor mu?
- Cloud Attack Paths analiz ediliyor mu?
- External User access expire oluyor mu?
- Vendor access time-bound mı?
- Guest Accounts review ediliyor mu?
- IGA ve CIEM entegre mi?
- CIEM findings SIEM/SOC'a context sağlıyor mu?
- ITDR cloud identities'i izliyor mu?
- Service Accounts behavior monitoring altında mı?
- AI Agents unique identity kullanıyor mu?
- AI Agent privileges scoped ve temporary mi?
- Cloud Identity Incident Response playbook mevcut mu?

### Cloud IAM ve CIEM Olgunluk Modeli

**Seviye 1 – Broad Cloud Access:** Users ve applications geniş permissions taşır. Static access keys yaygındır. Least Privilege sınırlıdır.

**Seviye 2 – Centralized Cloud IAM:** Roles ve policies standardize edilir. MFA uygulanır. High-risk identities inventory'e alınır.

**Seviye 3 – JIT ve Machine Identity Security:** Permanent admin azalır, PIM/JIT kullanılır, service principals ve workload identities kontrol edilir, static credentials azaltılır.

**Seviye 4 – CIEM ve Entitlement Analytics:** Effective permissions, unused access ve attack paths sürekli analiz edilir. Permission remediation programı uygulanır.

**Seviye 5 – Adaptive Cloud Authorization:** Human, Machine ve AI Agent identities context, usage ve real-time risk signals üzerinden dynamic ve short-lived privileges kullanır. Zero Standing Privilege hedeflenir.

Bu dönüşüm:

#### Broad Cloud Roles

↓

#### Controlled IAM

↓

#### JIT Privilege

↓

#### CIEM-Based Least Privilege

↓

#### Adaptive Cloud Authorization

şeklinde ilerler.

### Sık Sorulan Sorular

#### Cloud IAM nedir?

Cloud IAM, cloud resources üzerinde users, groups, applications ve workloads'ın hangi actions'ı gerçekleştirebileceğini yöneten identity and access management yapısıdır.

#### CIEM nedir?

CIEM, Cloud Infrastructure Entitlement Management; cloud identities'in sahip olduğu excessive, unused ve high-risk permissions'ı tespit etmeyi ve Least Privilege uygulamayı amaçlayan güvenlik yaklaşımıdır.

#### AWS IAM nedir?

AWS IAM, Amazon Web Services ortamında users, roles, policies ve permissions'ın yönetilmesini sağlayan identity and access management service'idir.

#### Azure RBAC nedir?

Azure RBAC, Azure resources üzerinde identity'lere role-based authorization sağlayan erişim kontrol modelidir.

#### Google Cloud IAM nedir?

Google Cloud IAM, Google Cloud resources için users, groups, service accounts ve other principals'ın permissions'ını yöneten authorization sistemidir.

#### Excessive Permission nedir?

Identity'nin işini gerçekleştirmek için gerekenden daha fazla access veya privilege'a sahip olmasıdır.

#### Permission Creep nedir?

User veya service account'un zaman içerisinde eski permissions kaldırılmadan yeni permissions alması sonucu privilege set'inin büyümesidir.

#### Effective Permission nedir?

Groups, roles, inherited policies ve resource-level permissions dahil edildiğinde identity'nin gerçekte sahip olduğu toplam authorization seviyesidir.

#### CIEM ile IGA aynı şey midir?

Hayır. IGA enterprise-wide identity governance ve access certification'a odaklanırken CIEM cloud infrastructure entitlements ve actual permission usage üzerinde daha derin analiz sağlar.

#### CIEM ile CSPM arasındaki fark nedir?

CIEM identity permissions'a, CSPM ise cloud resource configurations ve security posture'a odaklanır.

#### Service Principal nedir?

Application veya automation tarafından kullanılan cloud-based Non-Human Identity türüdür.

#### Managed Identity nedir?

Cloud platform tarafından yönetilen ve applications'ın manual secret saklamadan authentication yapmasına yardımcı olan machine identity modelidir.

#### Workload Identity nedir?

Application, container, pipeline veya automation process gibi workload tarafından kullanılan machine identity'dir.

#### Temporary Credential nedir?

Belirli süre geçerli olan ve süresi dolduğunda otomatik olarak kullanılamaz hale gelen authentication credential'dır.

#### JIT Cloud Access nedir?

High privilege role'ün sürekli aktif tutulması yerine yalnız ihtiyaç anında belirli süreyle verilmesidir.

#### Zero Standing Privilege cloud'da ne anlama gelir?

Users ve workloads üzerinde permanent high privilege bırakmadan, privilege'ın yalnız ihtiyaç anında temporary olarak verilmesi yaklaşımıdır.

#### CIEM neden önemlidir?

Cloud roles çok sayıda permission içerdiği için identities zaman içerisinde gereğinden fazla privilege biriktirebilir. CIEM bu excessive access'i görünür hale getirerek Least Privilege uygulanmasına yardımcı olur.

#### AI Agent cloud IAM kapsamında mıdır?

Cloud resources üzerinde işlem yapan AI Agents machine identity olarak değerlendirilip unique identity, scoped permissions ve short-lived credentials ile yönetilmelidir.

### Sonuç: Cloud Güvenliğinin En Büyük Sorunu Yetki Eksikliği Değil, Gereğinden Fazla Yetkidir

Cloud platforms son derece granular authorization capabilities sunmaktadır.

Teorik olarak bir identity'ye yalnız ihtiyacı olan permission verilebilir.

Ancak pratikte operational convenience nedeniyle broad roles kullanılır.

Developer'a Full Access verilir.

Application'a Owner role atanır.

Service Principal'a permanent secret oluşturulur.

Temporary project access unutulur.

Bu decisions birikerek büyük **Cloud Permission Debt** oluşturur.

Attacker açısından bu son derece değerlidir.

Çünkü attacker yeni privilege yaratmak zorunda olmayabilir.

Compromise ettiği identity'nin üzerinde zaten yeterinden fazla privilege bulunabilir.

Bu nedenle modern cloud security yalnız authentication'ı güçlendirmekle tamamlanamaz.

Phishing-resistant MFA kullanabilirsiniz.

Strong passwordless authentication uygulayabilirsiniz.

Ancak identity üzerinde excessive permissions bulunuyorsa attacker's blast radius hâlâ büyüktür.

Bu yüzden modern Cloud Identity Security'nin temel modeli:

**Strong Authentication + Least Privilege + Temporary Credentials + Entitlement Analytics + Continuous Monitoring**

olmalıdır.

CIEM bu modelin Least Privilege intelligence katmanını sağlar.

IGA business governance sağlar.

PAM privileged access'i sınırlar.

ITDR active identity threats'i detect eder.

Bu technologies birlikte kullanıldığında:

#### Identity Security Fabric

oluşmaya başlar.

Cloud environment büyüdükçe challenge daha da artacaktır.

Çünkü artık yalnız human users yoktur.

Service Principals,

Workload Identities,

CI/CD Pipelines,

Automation Bots

ve AI Agents

aynı cloud resources üzerinde action gerçekleştirmektedir.

Bu nedenle geleceğin Cloud IAM programı:

#### Human Identity Management

değil:

#### Universal Identity and Entitlement Management

haline gelecektir.

Modern cloud authorization'ın temel prensibi şu şekilde özetlenebilir:

**Never grant what is not needed, never keep privilege longer than required, and never leave entitlement unobserved.**

Türkçe karşılığıyla:

**Gerekli olmayan yetkiyi verme, gerekli olandan uzun süre açık bırakma ve verilen yetkiyi izlenmeden bırakma.**

Ve bu bölümün en önemli cümlesi:

**Cloud güvenliğinde gerçek Least Privilege, kullanıcıya küçük bir role vermek değil; sahip olduğu yetkiler ile gerçekten kullandığı yetkiler arasındaki farkı sürekli ölçerek gereksiz privilege'ı ortadan kaldırmaktır.**