# IAM Nedir? Identity and Access Management, SSO, MFA ve Kullanıcı Yaşam Döngüsü

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/kimlik-ve-erisim-yonetimi/iam-nedir-sso-mfa-kullanici-yasam-dongusu

![IAM Nedir? Identity and Access Management, SSO, MFA ve Kullanıcı Yaşam Döngüsü](/images/bilgi-merkezi/covers/cover-pamiam-02.webp)

Kurumsal bilgi sistemlerinde güvenliğin en temel sorularından biri şudur:

**“Hangi kullanıcı, hangi sisteme, hangi yetkiyle ve hangi koşullarda erişebilir?”**

Bu sorunun cevabı modern kurumlarda artık yalnız kullanıcı adı ve parola ile verilemez.

Çünkü bir çalışanın eriştiği kaynaklar tek bir Active Directory sunucusuyla sınırlı değildir. Kullanıcı aynı gün içerisinde Microsoft 365, CRM, ERP, cloud console, file sharing platform, VPN, SaaS application ve çeşitli business services kullanabilir.

Bir başka kullanıcı ise contractor olabilir.

Bir diğeri privileged administrator olabilir.

Bir application başka bir service'e API üzerinden erişebilir.

Bu nedenle modern **IAM – Identity and Access Management**, yalnız account oluşturup kapatan bir teknoloji değil, kurumun dijital kimliklerinin tamamını yöneten bir güvenlik mimarisidir.

IAM'in amacı:

**Doğru kimliği doğrulamak, doğru erişimi vermek, erişimi yaşam döngüsü boyunca yönetmek ve gereksiz yetkileri zamanında kaldırmaktır.**

Bunu yaparken şu teknolojiler birlikte çalışabilir:

**Identity Provider + Directory + SSO + MFA + Federation + SCIM + Conditional Access + Access Policies + Identity Lifecycle Management**

Bu yapı modern Zero Trust güvenlik yaklaşımının da temelini oluşturur.

### IAM Nedir?

IAM, yani **Identity and Access Management**, kullanıcıların ve diğer digital identities'in sistemlere erişimini yöneten teknoloji, süreç ve politikaların bütünüdür.

IAM üç temel güvenlik işlevini yerine getirir:

#### Identity Management

#### Authentication

#### Authorization

Identity Management, kullanıcının kimliğinin oluşturulması ve yaşam döngüsünün yönetilmesini sağlar.

Authentication, kullanıcının gerçekten iddia ettiği kişi olup olmadığını doğrular.

Authorization ise doğrulanmış kullanıcının hangi kaynaklara ve hangi yetkiyle erişebileceğini belirler.

Bu üç süreç birlikte çalışmadığında kurum içerisinde ciddi security gaps oluşabilir.

### IAM Neden Gereklidir?

Kurum büyüdükçe identities ve access rights hızla karmaşıklaşır.

Küçük bir şirkette birkaç kullanıcı ve birkaç application manuel olarak yönetilebilir.

Ancak enterprise ortamında:

binlerce employee,

yüzlerce SaaS application,

cloud platforms,

external users,

contractors,

service accounts

bulunabilir.

Manuel yönetim sürdürülemez hale gelir.

Bu durumda IAM şu riskleri azaltmaya yardımcı olur:

Orphaned Accounts

Dormant Accounts

Excessive Permissions

Password Reuse

Weak Authentication

Delayed Offboarding

Uncontrolled SaaS Access

Permission Creep

Dolayısıyla IAM yalnız operational efficiency değil aynı zamanda security ve compliance yatırımıdır.

### Identity Provider Nedir?

Identity Provider, yani **IdP**, kullanıcıların kimliğini doğrulayan ve diğer applications'a authentication bilgisi sağlayan merkezi sistemdir.

Modern IAM architecture içerisinde IdP merkezi rol oynar.

Örneğin user tek bir corporate identity ile farklı SaaS applications'a login olabilir.

Identity Provider authentication'ı gerçekleştirir ve application'a user identity hakkında güvenilir bilgi gönderir.

Bu sayede her application'ın ayrı password database tutmasına gerek kalmayabilir.

### Identity Provider Örnekleri

Modern IAM dünyasında yaygın kullanılan platformlar arasında:

Microsoft Entra ID

Okta

Ping Identity

Google Cloud Identity

Oracle Identity

gibi çözümler bulunabilir.

Bu platformlar farklı seviyelerde:

SSO

MFA

Federation

Application Integration

Conditional Access

Identity Lifecycle

capabilities sunabilir.

Ürün seçimi kurumun mevcut infrastructure, cloud strategy ve integration requirements'ına göre yapılmalıdır.

### Directory ile Identity Provider Arasındaki Fark

Directory kullanıcı ve group information'ı saklayan yapı olarak düşünülebilir.

Identity Provider ise authentication ve federation işlemlerini yönetir.

Örneğin Active Directory bir directory platformudur.

Microsoft Entra ID ise cloud identity ve access platformu olarak daha geniş authentication ve access capabilities sunar.

Bu iki yapı hybrid environments'da birlikte çalışabilir.

### Hybrid Identity Nedir?

Hybrid Identity, on-premises directory ile cloud identity platformunun birlikte kullanıldığı mimaridir.

Örneğin organization Active Directory kullanırken aynı identities Microsoft Entra ID ile synchronize edilebilir.

Bu sayede user aynı corporate identity ile hem local resources hem SaaS applications kullanabilir.

Ancak hybrid identity architecture identity attack surface'i de genişletebilir.

On-premises compromise cloud access'i etkileyebilir veya cloud identity compromise local systems için risk oluşturabilir.

Bu nedenle hybrid identity security ayrı değerlendirilmelidir.

### SSO Nedir?

SSO yani **Single Sign-On**, kullanıcıların tek authentication işlemiyle birden fazla application'a erişmesini sağlar.

Örneğin user sabah corporate account ile login olur.

Daha sonra:

CRM

HR System

Cloud Storage

Collaboration Platform

gibi applications'a yeniden password girmeden erişebilir.

Bu user experience açısından önemli avantaj sağlar.

Ancak asıl security avantajı passwords'ların merkezi yönetilebilmesidir.

### SSO Güvenliği Artırır mı?

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

Çünkü user her application için ayrı password oluşturmak zorunda kalmaz.

Password reuse azalabilir.

Centralized MFA uygulanabilir.

Account disable edildiğinde birçok application access'i aynı anda kesilebilir.

Ancak SSO hesabı compromise edilirse attacker çok sayıda application'a erişebilir.

Bu nedenle SSO:

**Strong MFA + Conditional Access + Identity Monitoring**

ile birlikte kullanılmalıdır.

### SSO ve MFA Birlikte Nasıl Çalışır?

SSO convenience sağlar.

MFA ise authentication güvenliğini artırır.

Örneğin user corporate account ile authentication yaptığında:

Password

Authenticator

kontrolü yapılabilir.

Başarılı authentication sonrasında SSO session oluşturulur.

User tekrar tekrar MFA yapmak zorunda kalmayabilir.

Ancak sensitive application veya high-risk action için **Step-Up Authentication** uygulanabilir.

### Step-Up Authentication Nedir?

Step-Up Authentication, user zaten login olmuş olsa bile daha yüksek riskli işlem için ek authentication istenmesidir.

Örneğin user e-mail'e normal login ile erişebilir.

Ancak payroll system'e girdiğinde phishing-resistant MFA istenebilir.

Bu risk-based security sağlar.

### MFA Nedir?

Multi-Factor Authentication, farklı authentication factors'ın birlikte kullanılmasını sağlar.

Authentication factors genel olarak üç kategoriye ayrılır:

#### Something You Know

Password veya PIN

#### Something You Have

Phone, security key, smart card

#### Something You Are

Fingerprint veya Face Recognition

İki farklı category kullanılması security level'ı artırır.

### MFA ile 2FA Arasındaki Fark

2FA yani Two-Factor Authentication tam olarak iki authentication factor kullanır.

MFA ise iki veya daha fazla factor içerebilir.

Pratikte iki terim çoğu zaman birbirinin yerine kullanılabilir.

Ancak teknik olarak MFA daha geniş kavramdır.

### SMS MFA Güvenli mi?

SMS MFA password-only authentication'dan daha güçlüdür.

Ancak SIM Swap ve phishing gibi risks nedeniyle en güçlü MFA yöntemi değildir.

High-value identities için stronger authentication methods tercih edilebilir.

### Push MFA Nedir?

Push MFA kullanıcıya mobile application üzerinden approve/deny notification gönderir.

User login attempt'i doğrular.

Ancak attacker repeated requests göndererek user'ı yanlışlıkla approve etmeye zorlayabilir.

Bu attack **MFA Fatigue** veya MFA Bombing olarak bilinir.

### MFA Fatigue Nedir?

Attacker password'u ele geçirdikten sonra sürekli MFA requests oluşturur.

User eventually:

“Belki sistem istiyordur.”

düşüncesiyle request'i approve edebilir.

Number Matching ve context information bu riski azaltabilir.

Ancak phishing-resistant MFA daha güçlü çözüm olabilir.

### Phishing-Resistant MFA Nedir?

Phishing-resistant MFA, fake login pages veya adversary-in-the-middle attacks karşısında authentication credential'ın attacker-controlled site'a verilmesini zorlaştırır.

FIDO2

WebAuthn

Security Keys

Passkeys

bu kategori için önemli teknolojilerdir.

### FIDO2 Nedir?

FIDO2 passwordless ve phishing-resistant authentication için kullanılan modern standard ekosistemidir.

Public-key cryptography kullanır.

Private key user device üzerinde tutulur.

Server tarafında reusable password secret bulunmaz.

Bu credential phishing riskini önemli ölçüde azaltabilir.

### WebAuthn Nedir?

WebAuthn web applications'ın public-key based authentication kullanmasını sağlayan standarddır.

Browser ve authenticator arasında secure authentication flow oluşturur.

FIDO2 ecosystem'inin önemli bileşenidir.

### Passkey Nedir?

Passkey traditional password yerine public-key based authentication kullanan modern kimlik doğrulama yöntemidir.

User login sırasında password yazmak yerine:

device unlock,

biometric,

PIN

kullanabilir.

Ama asıl authentication cryptographic key ile gerçekleştirilir.

Passkey reusable password olmadığı için credential phishing ve credential stuffing riskini azaltabilir.

### Passwordless Authentication Nedir?

Passwordless Authentication kullanıcının traditional password girmeden login olmasını sağlar.

Yöntemler arasında:

Passkeys

FIDO2 Keys

Certificates

Smart Cards

Device-Based Authentication

bulunabilir.

Passwordless transformation kullanıcı deneyimini iyileştirirken attack surface'i de azaltabilir.

### Passwordless Her Şeyi Çözer mi?

Hayır.

Password attack surface'ini azaltır.

Ancak:

Session Theft

Device Compromise

Account Recovery Abuse

OAuth Abuse

gibi risks devam edebilir.

Bu nedenle passwordless da broader Identity Security architecture'ın parçasıdır.

### Account Recovery Neden Kritik?

Strong authentication kullanan account'un en zayıf noktası account recovery process olabilir.

Attacker:

“Telefonumu kaybettim.”

“MFA cihazım değişti.”

gibi social engineering ile help desk'i kandırmaya çalışabilir.

Bu nedenle recovery process primary authentication kadar güçlü olmalıdır.

### MFA Reset Güvenliği

MFA device kaybolduğunda reset gerekebilir.

Ancak help desk attacker tarafından hedeflenebilir.

Bu nedenle MFA reset için:

Strong Identity Verification

Approval

Audit Logging

Risk Assessment

uygulanabilir.

High-privilege users için daha güçlü process gerekir.

### Authentication Strength Nedir?

Authentication Strength, hangi authentication methods'ın belirli application veya access scenario için kabul edildiğini tanımlar.

Örneğin general application:

Any MFA

kabul edebilir.

Critical application:

Phishing-Resistant MFA

gerektirebilir.

Bu granular security sağlar.

### Federation Nedir?

Federation, farklı identity domains arasında trust kurulmasını sağlar.

Örneğin employee corporate Identity Provider üzerinden external SaaS application'a login olabilir.

SaaS application password'u kendi sisteminde saklamak zorunda kalmaz.

Bu centralized identity security sağlar.

### SAML Nedir?

SAML yani **Security Assertion Markup Language**, enterprise federation ve SSO'da yaygın kullanılan standarddır.

Architecture genellikle:

User

↓

Identity Provider

↓

SAML Assertion

↓

Service Provider

şeklinde çalışır.

Application authentication'ı Identity Provider'a bırakır.

### Service Provider Nedir?

Service Provider user'ın erişmek istediği application'dır.

Örneğin HR SaaS platformu bir Service Provider olabilir.

Identity Provider authentication gerçekleştirir.

Service Provider gelen assertion'a göre user'a access verir.

### SAML Security Riskleri

Yanlış federation configuration ciddi security risk oluşturabilir.

Örneğin:

weak certificate management,

improper trust configuration,

overly broad attribute mapping

problems oluşturabilir.

Bu nedenle federation design güvenlik review'undan geçmelidir.

### OAuth 2.0 Nedir?

OAuth 2.0, bir application'ın user adına başka bir service'e limited access almasını sağlayan delegated authorization framework'üdür.

Örneğin calendar application:

#### Read Calendar

permission isteyebilir.

User password'unu application'a vermek zorunda değildir.

Application access token kullanır.

### OAuth Authentication mı Authorization mı?

OAuth esas olarak authorization framework'üdür.

Authentication için doğrudan OAuth kullanmak doğru conceptual model değildir.

Authentication için OpenID Connect kullanılabilir.

### OpenID Connect Nedir?

OpenID Connect, OAuth 2.0 üzerine authentication layer ekler.

Identity Token sayesinde application user'ın kim olduğunu öğrenebilir.

Modern cloud-native applications içerisinde yaygın kullanılır.

### ID Token Nedir?

ID Token user authentication hakkında information taşıyan token'dır.

Application user identity hakkında claims alabilir.

Örneğin:

User ID

Issuer

Authentication Time

gibi information bulunabilir.

### Access Token Nedir?

Access Token application'ın API veya resource'a access için kullandığı token'dır.

Access Token kimlik doğrulama amaçlı değil resource authorization için kullanılır.

Token'ın scope ve lifetime değerleri security açısından önemlidir.

### Refresh Token Nedir?

Refresh Token yeni Access Token almak için kullanılan uzun ömürlü credential olabilir.

Attacker refresh token ele geçirirse uzun süre access sağlayabilir.

Bu nedenle token protection ve session security önemlidir.

### Token Theft Neden Önemlidir?

Modern authentication password ve MFA sonrasında token-based session oluşturur.

Attacker token ele geçirirse authentication'ı yeniden gerçekleştirmeden access sağlamaya çalışabilir.

Bu nedenle security yalnız login event'e odaklanmamalıdır.

### Session Security Nedir?

Session Security, authentication sonrası user session'ın güvenliğini yönetir.

Örneğin:

Session Lifetime

Token Protection

Continuous Evaluation

Risk-Based Revocation

uygulanabilir.

Bu cloud identity security'nin kritik alanlarından biridir.

### Continuous Access Evaluation Nedir?

User session aktifken yeni risk oluşabilir.

Örneğin:

Account disabled.

Device compromised.

Password changed.

Risk level increased.

Continuous Access Evaluation session'ın yeniden değerlendirilmesini ve gerektiğinde access'in hızlı revoke edilmesini sağlar.

### SCIM Nedir?

SCIM yani **System for Cross-domain Identity Management**, user provisioning ve deprovisioning automation için kullanılan standarddır.

SCIM sayesinde Identity Provider veya HR system SaaS application'a:

Create User

Update User

Disable User

gibi işlemleri otomatik gönderebilir.

Bu Joiner-Mover-Leaver süreçlerini hızlandırır.

### Provisioning Nedir?

Provisioning yeni identity için gerekli accounts ve permissions'ın oluşturulmasıdır.

Örneğin yeni Finance employee başladığında:

Corporate Account

E-mail

Finance Application

File Share Access

otomatik oluşturulabilir.

Manual provisioning yerine policy-driven automation tercih edilebilir.

### Deprovisioning Nedir?

Deprovisioning user'ın artık ihtiyaç duymadığı accounts ve access rights'ın kaldırılmasıdır.

Security açısından provisioning'den daha kritik olabilir.

Çünkü forgotten access attacker tarafından kullanılabilir.

### Joiner-Mover-Leaver Nedir?

JML modeli employee lifecycle'ın üç ana aşamasını ifade eder.

#### Joiner

Organization'a katılan user.

#### Mover

Role veya department değiştiren user.

#### Leaver

Organization'dan ayrılan user.

IAM programının başarısı bu üç aşamanın ne kadar otomatik ve doğru yönetildiğiyle doğrudan ilişkilidir.

### Joiner Sürecinde IAM

Yeni employee HR system'a kaydedildiğinde identity automation başlayabilir.

HR System

↓

IAM

↓

Directory Account

↓

E-mail

↓

Required Applications

↓

Role-Based Permissions

Bu yaklaşım manual errors'ı azaltır.

### Birthright Access Nedir?

User'ın role veya employment type nedeniyle otomatik aldığı temel access rights'tır.

Örneğin her employee:

E-mail

Intranet

Collaboration Platform

erişimi alabilir.

Ancak birthright access minimum seviyede tutulmalıdır.

### Mover Sürecinde IAM

Employee role değiştirdiğinde hem yeni permissions verilmeli hem eski permissions kaldırılmalıdır.

Sadece yeni permissions eklemek **Access Accumulation** oluşturur.

Bu zaman içerisinde ciddi security riskine dönüşebilir.

### Permission Creep Nedir?

User yıllar boyunca farklı roles aldıkça permissions birikir.

Eski accesses kaldırılmaz.

Sonuç:

user ihtiyaç duyduğundan çok daha fazla resource'a erişebilir.

Bu Permission Creep veya Privilege Creep olarak adlandırılır.

IGA ve Access Review processes bu riski azaltır.

### Leaver Sürecinde IAM

Employee ayrıldığında yalnız Active Directory account disable edilmesi yeterli olmayabilir.

Çünkü user'ın:

SaaS Accounts

Cloud Sessions

OAuth Grants

VPN Access

API Tokens

Local Accounts

External Collaboration Access

gibi başka access points'i olabilir.

Bu nedenle comprehensive deprovisioning gerekir.

### Active Session Nedir?

User account disable edilse bile bazı applications'ta previously authenticated session belirli süre aktif kalabilir.

Bu nedenle offboarding sırasında:

Session Revocation

Token Revocation

gerekebilir.

### OAuth Consent Risk

User third-party application'a OAuth permissions vermiş olabilir.

Employee ayrıldıktan sonra application token'ı access sağlamaya devam edebilir.

Bu nedenle OAuth grants de identity lifecycle kapsamında yönetilmelidir.

### Shadow Account Nedir?

Central IAM dışında application üzerinde ayrı oluşturulan user account shadow account olarak düşünülebilir.

Bu account corporate lifecycle process'ten etkilenmeyebilir.

Employee ayrıldığında account açık kalabilir.

Bu nedenle SaaS discovery önemlidir.

### Shadow IT IAM'i Nasıl Etkiler?

Users approved olmayan SaaS applications kullanabilir.

Bu applications corporate SSO'ya bağlı olmayabilir.

Personal credentials kullanılabilir.

Bu durumda security team:

hangi users'ın access'i var,

hangi data tutuluyor,

offboarding nasıl yapılacak

bilmeyebilir.

CASB ve SaaS discovery bu visibility'yi artırabilir.

### Just-in-Time Provisioning Nedir?

User application'a ilk kez access ettiğinde account otomatik oluşturulabilir.

Bu JIT Provisioning olarak adlandırılır.

Operational convenience sağlar.

Ancak lifecycle ve deprovisioning process'in ayrıca yönetilmesi gerekir.

### RBAC Nedir?

Role-Based Access Control, permissions'ın job role üzerinden yönetilmesidir.

Örneğin:

Sales Representative

Finance Analyst

HR Specialist

rolleri tanımlanabilir.

Bu role assignment access management'i standardize eder.

### Role Explosion Nedir?

Organization her küçük access variation için ayrı role oluşturursa binlerce role oluşabilir.

Bu Role Explosion olarak bilinir.

RBAC management zorlaşır.

Bu nedenle role design dikkatli yapılmalıdır.

### ABAC Nedir?

Attribute-Based Access Control access decisions için attributes kullanır.

Örneğin:

Department

Employment Type

Device Compliance

Location

Data Sensitivity

gibi context kullanılabilir.

ABAC daha dynamic access sağlar.

### RBAC ve ABAC Birlikte Kullanılabilir mi?

Evet.

Role baseline access belirleyebilir.

Attributes additional conditions uygulayabilir.

Örneğin:

Role = Finance Manager

Device = Compliant

Location = Allowed

↓

Payment Application Access

Bu hybrid authorization modelidir.

### Conditional Access Nedir?

Conditional Access login veya application access sırasında security context'i değerlendirir.

Policy örneği:

User = Employee

Application = Financial System

Device = Managed

MFA = Phishing-Resistant

↓

Allow

Başka durumda:

Device = Unmanaged

↓

Block

Bu modern Zero Trust access control'ün önemli bileşenidir.

### Location-Based Access

Access decision source location üzerinden değerlendirilebilir.

Ancak location tek security signal olmamalıdır.

VPN veya proxy location'ı değiştirebilir.

Bu nedenle identity, device ve risk context ile birlikte kullanılmalıdır.

### Device-Based Access

User doğru password ve MFA kullansa bile unmanaged device'tan login olabilir.

Conditional Access device compliance kontrol ederek access'i sınırlandırabilir.

Bu Identity + Endpoint integration sağlar.

### Risk-Based Authentication

Login event unusual görünüyorsa stronger authentication istenebilir.

Örneğin:

New Device

Unusual Location

Suspicious IP

gibi signals risk score'u artırabilir.

High-risk login block edilebilir.

### Adaptive Authentication

Adaptive Authentication user behavior ve context'e göre authentication requirement'ı dinamik değiştirir.

Low Risk:

Normal MFA

Medium Risk:

Step-Up MFA

High Risk:

Block

Bu static authentication modelinden daha güçlüdür.

### Identity Analytics Nedir?

Identity Analytics user login ve access behavior'ını analiz ederek anomalies tespit etmeye çalışır.

Örneğin:

unusual application access,

impossible travel,

sudden privilege use

signals oluşturabilir.

Bu ITDR ve UEBA ile ilişkilidir.

### Identity-Based Attack Nedir?

Attacker malware kullanmadan legitimate credential ile access sağlayabilir.

Examples:

Credential Stuffing

Password Spraying

MFA Fatigue

OAuth Abuse

Token Theft

Session Hijacking

Bu nedenle IAM security yalnız authentication success loglarına bakmamalıdır.

### Credential Stuffing Nedir?

Attacker başka data breach'lerden ele geçirilen username-password combinations'ı farklı services üzerinde dener.

Password reuse varsa account compromise olabilir.

Passwordless ve MFA bu riski azaltabilir.

### Password Spraying Nedir?

Attacker birçok account üzerinde birkaç yaygın password dener.

Traditional brute force'tan farklı olarak account lockout thresholds'u aşmamaya çalışır.

Identity monitoring bu pattern'i detect edebilir.

### Impossible Travel Nedir?

Aynı user kısa süre içerisinde birbirinden çok uzak geographic locations'dan login olmuş görünür.

Bu potential account compromise signal olabilir.

Ancak VPN ve cloud infrastructure false positive oluşturabilir.

Context gerekir.

### Legacy Authentication Neden Risklidir?

Eski authentication protocols modern MFA veya Conditional Access controls desteklemeyebilir.

Attacker legacy protocol üzerinden password-only authentication yapmaya çalışabilir.

Bu nedenle legacy authentication mümkün olduğunca azaltılmalıdır.

### Basic Authentication ve Modern Authentication

Basic Authentication çoğunlukla reusable username-password gönderimine dayanır.

Modern Authentication OAuth-based token mechanisms ve MFA integration sağlayabilir.

Bu yüzden modern protocols tercih edilir.

### Application Integration Neden IAM Projesinin Zor Kısmıdır?

SSO platform almak kolay olabilir.

Ancak hundreds of applications'ın IAM'e entegrasyonu zaman alabilir.

Applications:

SAML

OIDC

SCIM

desteklemeyebilir.

Legacy applications için additional gateways veya custom integrations gerekebilir.

Bu nedenle IAM projesi yalnız product deployment değildir.

### Legacy Application IAM Entegrasyonu

Old applications modern federation desteklemeyebilir.

Bu durumda:

Reverse Proxy

Identity-Aware Gateway

Password Vaulting

gibi approaches kullanılabilir.

Ama uzun vadede modernization değerlendirilmelidir.

### IAM ve PAM Nasıl Birlikte Çalışır?

IAM normal workforce access'i yönetir.

PAM privileged access'i daha sıkı kontrol eder.

Örneğin user IAM üzerinden authenticated olur.

Daha sonra PAM platformunda privileged access request yapar.

MFA uygulanır.

Approval alınır.

Temporary session başlatılır.

Session kaydedilir.

Bu integrated identity architecture'dır.

### IAM ve IGA Nasıl Birlikte Çalışır?

IAM access'i technical olarak uygular.

IGA access'in business olarak gerekli olup olmadığını govern eder.

Örneğin IGA manager'a:

“Bu employee hâlâ financial database access'e ihtiyaç duyuyor mu?”

sorusunu sorar.

Manager revoke kararı verirse IAM permission'ı kaldırır.

### IAM ve ITDR Nasıl Birlikte Çalışır?

IAM access policy uygular.

ITDR identity threats'i detect eder.

Örneğin:

user normal authentication yaptı.

Ama kısa süre sonra:

New MFA Registration

Privilege Escalation

Unusual Session

görüldü.

ITDR incident oluşturabilir.

IAM veya SOAR session'ı revoke edebilir.

### IAM ve SIEM Entegrasyonu

Identity Provider logs SIEM'e gönderilmelidir.

Önemli events:

Login Success

Login Failure

MFA Failure

MFA Registration

Password Reset

New Application Consent

Privilege Assignment

Account Disable

gibi olaylardır.

SIEM bunları endpoint ve network events ile correlate edebilir.

### IAM ve XDR Entegrasyonu

XDR identity signals'ı endpoint, e-mail ve cloud telemetry ile birleştirebilir.

Örneğin:

Phishing Email

↓

User Click

↓

Risky Login

↓

Suspicious Endpoint Activity

aynı incident içerisinde görülebilir.

Bu Attack Chain visibility sağlar.

### Entra ID Modern IAM İçerisinde Nerede Konumlanır?

Microsoft Entra ID cloud-based identity and access platform olarak:

Workforce Identity

SSO

MFA

Conditional Access

Application Integration

Identity Governance

gibi capabilities sunabilir.

Microsoft-heavy environments için natural integration avantajı bulunabilir.

Ancak architecture requirements her kurum için ayrı değerlendirilmelidir.

### Okta IAM İçerisinde Nerede Konumlanır?

Okta cloud-based Identity Provider ve access platform sınıfında değerlendirilir.

Multi-application ve heterogeneous environments içerisinde SSO, MFA ve lifecycle management use cases için kullanılabilir.

Vendor-neutral application ecosystem bazı organizations için avantaj sağlayabilir.

### Ping Identity Nerede Konumlanır?

Ping Identity özellikle federation, enterprise IAM ve customer identity use cases'inde kullanılan platformlardan biridir.

Complex enterprise ve hybrid identity architectures içerisinde değerlendirilebilir.

Her ürünün technical strengths ve deployment model'i farklıdır.

### IAM Ürünü Nasıl Seçilir?

Yalnız feature listesine bakmak doğru değildir.

Şu sorular değerlendirilmelidir:

Kaç user var?

Kaç application var?

On-premises environment var mı?

Cloud strategy nedir?

SAML/OIDC support oranı nedir?

MFA requirements neler?

Customer identity gerekiyor mu?

IGA gerekiyor mu?

PAM integration gerekiyor mu?

Compliance requirements neler?

Product seçimi architecture'a göre yapılmalıdır.

### IAM Projesine Nereden Başlanmalı?

İlk adım product deployment değil identity discovery olmalıdır.

Organization şu soruları cevaplamalıdır:

Kaç active identity var?

Kaç privileged identity var?

Kaç external identity var?

Kaç SaaS application var?

Hangi applications SSO kullanıyor?

Hangi accounts MFA kullanmıyor?

Hangi users excessive permissions'a sahip?

Bu visibility olmadan IAM roadmap eksik kalır.

### IAM Roadmap Nasıl Oluşturulur?

Örnek yol haritası:

#### \1. Identity Inventory

Human ve Non-Human identities'i belirle.

#### \2. Application Inventory

Applications ve authentication methods'ı belirle.

#### \3. Central Identity Provider

Authentication'ı merkezi hale getir.

#### \4. SSO

Applications'ı federation'a al.

#### \5. MFA

Strong authentication yaygınlaştır.

#### \6. Lifecycle Automation

SCIM ve JML automation uygula.

#### \7. Conditional Access

Device ve risk context ekle.

#### \8. Governance

IGA ve Access Review ekle.

#### \9. Privileged Security

PAM entegrasyonu yap.

#### \10. Detection

ITDR ve SOC visibility oluştur.

### IAM KPI'ları

IAM programı metrics ile ölçülmelidir.

Önemli KPI'lar:

SSO Coverage

MFA Coverage

Phishing-Resistant MFA Coverage

Automated Provisioning Coverage

Deprovisioning Time

Dormant Account Count

Orphaned Account Count

Application Federation Coverage

Legacy Authentication Usage

Access Review Completion

Bu metrics maturity'yi gösterir.

### SSO Coverage Nedir?

SSO üzerinden erişilen corporate applications'ın toplam applications'a oranıdır.

SSO coverage yükseldikçe centralized identity control artabilir.

### MFA Coverage Nedir?

MFA ile korunan users veya applications'ın toplam içindeki oranıdır.

Özellikle:

Admin Accounts

Remote Access

Critical Applications

için coverage %100'e yakın hedeflenebilir.

### Deprovisioning Time Neden Önemlidir?

Employee ayrıldığında access ne kadar hızlı kapanıyor?

Minutes?

Hours?

Days?

Leaver account günlerce açık kalıyorsa identity risk artar.

Bu nedenle Mean Time to Deprovision önemli KPI olabilir.

### IAM'de En Sık Yapılan Hatalar

Kurumlarda sık görülen hatalar:

- IAM'i yalnız Active Directory olarak görmek
- SSO kullanmamak
- Password-only authentication bırakmak
- MFA'yı yalnız VPN'e uygulamak
- Privileged users için stronger MFA kullanmamak
- Passkey/FIDO2 roadmap'i oluşturmamak
- Legacy authentication'ı açık bırakmak
- SaaS applications'ı SSO dışında bırakmak
- Shadow accounts'ı inventory'ye almamak
- Manual provisioning kullanmak
- Leaver process'i geciktirmek
- Active sessions'ı revoke etmemek
- OAuth grants'i offboarding dışında bırakmak
- SCIM kullanmamak
- Permission creep'i kontrol etmemek
- Access Reviews yapmamak
- Conditional Access uygulamamak
- Unmanaged devices'a unrestricted access vermek
- Identity logs'u SIEM'e göndermemek
- Authentication success'i güvenli session olarak kabul etmek
- Token theft riskini göz ardı etmek
- Account Recovery süreçlerini zayıf bırakmak

### IAM Security Checklist

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

- Merkezi Identity Provider var mı?
- SSO uygulama kapsamı yeterli mi?
- MFA kritik applications için zorunlu mu?
- Privileged users phishing-resistant MFA kullanıyor mu?
- FIDO2/Passkey desteği değerlendirildi mi?
- Passwordless roadmap mevcut mu?
- Legacy authentication kapatılıyor mu?
- Conditional Access uygulanıyor mu?
- Risk-Based Authentication kullanılıyor mu?
- Device Compliance access kararına dahil mi?
- SAML/OIDC integrations inventory'de mi?
- Federation trusts düzenli review ediliyor mu?
- OAuth application permissions kontrol ediliyor mu?
- SCIM provisioning uygulanıyor mu?
- Joiner process automated mı?
- Mover process eski permissions'ı kaldırıyor mu?
- Leaver process bütün systems'ı kapsıyor mu?
- Active Sessions revoke ediliyor mu?
- OAuth Tokens revoke ediliyor mu?
- SaaS shadow accounts tespit ediliyor mu?
- Dormant accounts kapatılıyor mu?
- Orphaned accounts temizleniyor mu?
- External users expiry policy kullanıyor mu?
- Access Reviews yapılıyor mu?
- IAM logs SIEM'e gönderiliyor mu?
- MFA registration events izleniyor mu?
- Password reset events izleniyor mu?
- ITDR integration mevcut mu?
- IAM incident response playbook var mı?

### IAM Olgunluk Modeli

#### Seviye 1 – Directory ve Password

Users local veya directory accounts kullanır.

Applications ayrı passwords ile çalışır.

Lifecycle mostly manual'dır.

#### Seviye 2 – Merkezi SSO ve MFA

Central Identity Provider kullanılır.

SSO ve MFA critical applications'a yaygınlaştırılır.

Account lifecycle daha merkezi hale gelir.

#### Seviye 3 – Automated Identity Lifecycle

SCIM, Joiner-Mover-Leaver automation ve Conditional Access uygulanır.

Access Reviews başlamıştır.

Legacy authentication azaltılır.

#### Seviye 4 – Adaptive Identity Security

Risk-Based Authentication, phishing-resistant MFA ve device-aware access uygulanır.

Identity analytics ve ITDR entegre edilir.

#### Seviye 5 – Passwordless ve Continuous Identity

Passkeys ve passwordless authentication yaygınlaşır.

Sessions continuous risk signals ile değerlendirilir.

Human ve Non-Human Identity lifecycle birlikte yönetilir.

Identity architecture:

**Automated + Adaptive + Context-Aware + Continuously Verified**

hale gelir.

### Sık Sorulan Sorular

#### IAM nedir?

Identity and Access Management, kullanıcı ve diğer digital identities'in applications ve systems'a erişimini yöneten teknoloji, süreç ve politikaların bütünüdür.

#### SSO nedir?

Single Sign-On, kullanıcıların tek authentication ile birden fazla application'a erişmesini sağlar.

#### SSO güvenli midir?

Strong MFA, Conditional Access ve monitoring ile kullanıldığında security ve user experience avantajları sağlayabilir. Ancak centralized identity compromise geniş impact oluşturabilir.

#### MFA nedir?

Multi-Factor Authentication, authentication sırasında farklı türde birden fazla factor kullanılmasıdır.

#### Passkey nedir?

Public-key cryptography kullanan ve traditional reusable passwords ihtiyacını azaltan modern authentication yöntemidir.

#### Passwordless Authentication nedir?

Traditional password girmeden passkey, FIDO2, certificate veya benzeri methods ile authentication yapılmasıdır.

#### SAML nedir?

Enterprise SSO ve federation scenarios'ında kullanılan identity assertion standardıdır.

#### OAuth 2.0 nedir?

Applications'ın user adına limited permissions ile resources'a erişmesini sağlayan delegated authorization framework'üdür.

#### OpenID Connect nedir?

OAuth 2.0 üzerine authentication layer ekleyen modern identity protocol'dür.

#### SCIM nedir?

Users'ın applications arasında automated provisioning ve deprovisioning işlemlerini standardize eden protokoldür.

#### Joiner-Mover-Leaver nedir?

Employee'ın organization'a katılması, role değiştirmesi ve ayrılması aşamalarında identity lifecycle'ın yönetilmesidir.

#### Conditional Access nedir?

Identity, device, location, application ve risk context'e göre access kararının dinamik verilmesidir.

#### Risk-Based Authentication nedir?

Login risk seviyesine göre additional authentication, access restriction veya blocking uygulanmasıdır.

#### Employee işten ayrıldığında AD account kapatmak yeterli mi?

Her zaman değil. SaaS accounts, active sessions, OAuth grants, cloud roles, VPN access, local accounts ve external collaboration access ayrıca kontrol edilmelidir.

#### Active Session nedir?

User authentication sonrasında application üzerinde belirli süre devam eden authenticated session'dır.

#### OAuth Token neden offboarding sırasında önemlidir?

Third-party application user adına access token veya refresh token kullanıyor olabilir. Bu access ayrıca revoke edilmelidir.

#### Legacy Authentication neden risklidir?

Bazı eski protocols MFA ve Conditional Access gibi modern controls'ü desteklemeyebilir ve password-only attack surface oluşturabilir.

#### Entra ID, Okta ve Ping Identity ne tür ürünlerdir?

Workforce identity, SSO, MFA, federation ve access management gibi IAM capabilities sağlayan identity platformlarıdır. Architecture ve use case'e göre tercih edilirler.

### Sonuç: IAM Hesap Açıp Kapatmaktan İbaret Değildir

Modern IAM programının başarısı yalnızca:

**“Kullanıcı sisteme giriş yapabildi mi?”**

sorusuyla ölçülemez.

Asıl sorular şunlardır:

Kullanıcı doğru şekilde doğrulandı mı?

Doğru application'a erişiyor mu?

Gereğinden fazla access'i var mı?

Device güvenilir mi?

Login riski normal mi?

Role değiştiğinde eski permissions kaldırıldı mı?

İşten ayrıldığında bütün sessions kapandı mı?

Third-party OAuth access devam ediyor mu?

Bu nedenle modern IAM lifecycle:

#### Identity Created

↓

#### Authenticated

↓

#### Authorized

↓

#### Provisioned

↓

#### Monitored

↓

#### Reviewed

↓

#### Deprovisioned

şeklinde düşünülmelidir.

SSO bu architecture'ın merkezi authentication katmanını sağlar.

MFA authentication security'sini güçlendirir.

Passkeys ve Passwordless reusable password riskini azaltır.

SCIM lifecycle automation sağlar.

Conditional Access context-aware security uygular.

ITDR ise identity abuse gerçekleştiğinde detection sağlar.

Modern IAM'in temel formülü bu nedenle:

**Central Identity + SSO + Strong MFA + Automated Lifecycle + Conditional Access + Governance + Continuous Monitoring**

şeklindedir.

Fakat en önemli nokta lifecycle'dır.

Bir user organization'a katıldığında access hızlı verilmelidir.

Role değiştirdiğinde permissions yeniden değerlendirilmelidir.

Ayrıldığında ise access yalnız bir directory üzerinde değil tüm digital ecosystem genelinde kaldırılmalıdır.

Çünkü günümüz kurumlarında identity tek bir yerde yaşamaz.

Identity:

Directory'dedir.

SaaS'tadır.

Cloud'dadır.

VPN'dedir.

OAuth token'dadır.

Active session'dadır.

Bu nedenle bu bölümün en önemli cümlesi şudur:

**Modern IAM'in gerçek başarısı kullanıcıya erişim vermekle değil; doğru erişimi doğru anda verebilmek ve ihtiyaç ortadan kalktığında bütün dijital ekosistemden güvenli şekilde kaldırabilmekle ölçülür.**