PAM Mimarisi Nasıl Kurulur? Vault, Session Management, JIT Access ve Zero Standing Privilege

Privileged Access Management projesinde en sık yapılan hatalardan biri, PAM ürününü kurmanın PAM mimarisi oluşturmakla aynı şey olduğunu düşünmektir. Oysa kurumsal bir PAM yapısı yalnızca administrator parolalarının saklandığı merkezi bir Password Vault'tan ibaret değildir. Gerçek bir PAM mimarisi; kimlik doğrulama, yetki yönetimi, privileged credential güvenliği, session kontrolü, approval süreçleri, Just-in-Time Access, service account yönetimi, monitoring, SIEM entegrasyonu, high availability ve disaster recovery gibi birçok güvenlik katmanının birlikte çalışmasını gerektirir.

Özellikle büyük kurumlarda privileged access tek bir teknoloji üzerinde gerçekleşmez. Windows administrator Active Directory üzerinde işlem yapabilir, Linux administrator SSH ile sunucuya bağlanabilir, database administrator Oracle veya PostgreSQL üzerinde yüksek yetki kullanabilir, network administrator firewall ve switch yapılandırmasını değiştirebilir, cloud administrator ise Azure, AWS veya Google Cloud üzerinde kritik IAM permissions yönetebilir. Bunların yanında applications tarafından kullanılan service accounts, API keys, secrets ve automation identities bulunur.

Bu nedenle modern PAM mimarisinin temel amacı yalnızca:

“Administrator parolalarını nerede saklayacağız?”

sorusuna cevap vermek değildir.

Asıl soru şudur:

“Kurum içerisindeki bütün ayrıcalıklı erişimleri nasıl keşfedecek, doğrulayacak, sınırlandıracak, geçici hale getirecek, izleyecek ve gerektiğinde anında sonlandıracağız?”

Başarılı bir PAM architecture bu soruya uçtan uca cevap verebilmelidir.

Kurumsal PAM Mimarisi Nasıl Çalışır?

Basitleştirilmiş bir traditional privileged access modelinde administrator doğrudan hedef sisteme bağlanır:

Administrator → Critical Server

Bu modelde administrator target system'in password'unu bilir. Credential endpoint üzerinde kullanılabilir, administrator'ın workstation'ında credential artifacts oluşabilir ve target system'e doğrudan network connectivity bulunabilir. Aynı credential birden fazla administrator tarafından biliniyorsa accountability problemi de ortaya çıkar.

Modern PAM architecture bu doğrudan ilişkiyi değiştirmeyi amaçlar.

Daha kontrollü bir model:

Administrator → Identity Verification → MFA → PAM → Approval/JIT → Session Proxy → Target System

şeklinde çalışabilir.

Administrator önce kendi kişisel corporate identity'siyle authentication yapar. PAM platformu user'ın kimliğini doğrular, gerekirse phishing-resistant MFA uygular ve hangi privileged resource'a erişmek istediğini belirler. Access policy veya approval workflow değerlendirilir. Uygun görülürse PAM target system için gerekli privileged credential'ı kullanıcıya göstermeden kullanabilir veya geçici privilege oluşturabilir.

Session PAM infrastructure üzerinden geçirilir ve gerekli security policies uygulanır.

Böylece privileged access merkezi olarak:

Authenticate → Authorize → Elevate → Connect → Monitor → Revoke

yaşam döngüsüne alınır.

Bu, modern PAM architecture'ın temelidir.

PAM Mimarisi Kurulmadan Önce Privileged Access Discovery Yapılmalıdır

PAM projesinin teknik deployment aşamasından önce kurumun privileged access landscape'i anlaşılmalıdır. Çünkü bilinmeyen administrator account, service account veya privileged application identity PAM tarafından korunamaz.

Discovery yalnız Active Directory içerisindeki Domain Admin group'una bakmak değildir. Kurum genelinde Windows local administrators, Linux root ve sudo accounts, database administrator accounts, network device administrators, firewall administrators, virtualization administrators, backup administrators, application administrators, cloud privileged roles ve service accounts incelenmelidir.

Özellikle legacy systems içerisinde yıllardır kullanılan ve owner'ı artık bilinmeyen privileged accounts bulunabilir. Bazı accounts yalnız belirli scheduled tasks veya applications tarafından kullanıldığı için kimse tarafından aktif olarak takip edilmiyor olabilir.

Bu nedenle PAM öncesinde bir Privileged Identity Inventory oluşturulmalıdır.

Her identity için en azından:

account owner,

target system,

privilege level,

business purpose,

authentication method,

credential rotation durumu,

interactive login yetkisi,

criticality

gibi bilgiler belirlenmelidir.

Bu çalışma sonucunda PAM onboarding öncelikleri oluşturulabilir.

Her şeyi aynı anda PAM'e almak yerine önce en yüksek riskli identities ile başlanması genellikle daha kontrollü bir yaklaşım sağlar.

Risk Tabanlı PAM Onboarding Nasıl Yapılır?

PAM implementation sırasında yüzlerce veya binlerce privileged account aynı anda onboarding edilmeye çalışılırsa operasyonel sorunlar yaşanabilir. Özellikle service accounts ve legacy applications credential rotation sonrasında çalışmayı durdurabilir.

Bu nedenle risk-based onboarding uygulanabilir.

İlk dalgada:

Domain Admin,

Enterprise Admin,

Cloud Global Administrator,

Backup Administrator,

Security Administrator

gibi yüksek impact oluşturabilecek identities alınabilir.

İkinci aşamada:

Database Administrators,

Network Administrators,

Virtualization Administrators,

Application Administrators

kapsama dahil edilebilir.

Sonraki aşamalarda:

Service Accounts,

Local Administrators,

DevOps Secrets,

Machine Identities

ve diğer privileged credentials programa eklenebilir.

Bu model PAM projesini tek seferlik deployment yerine sürekli genişleyen bir Privileged Access Security Program haline getirir.

Credential Vault PAM Mimarisinin Temel Katmanlarından Biridir

Credential Vault privileged credentials'ın merkezi ve güvenli şekilde saklandığı bileşendir. Ancak Vault'un amacı yalnız passwords'ı encrypted database içerisinde tutmak değildir.

İdeal modelde administrator target system password'unu doğrudan bilmez.

Örneğin database administrator production database'e bağlanmak istediğinde PAM platformuna kendi personal identity'siyle giriş yapar. PAM gerekli policy controls'ü uyguladıktan sonra target database credential'ını Vault'tan alır ve session'ı kullanıcı adına oluşturur.

Administrator credential'ı görmeden sisteme erişebilir.

Bu yaklaşım:

Credential Disclosure

riskini azaltır.

Çünkü password administrator tarafından bilinmiyorsa notebook, password manager, text file, ticket veya e-mail içerisinde tutulması ihtiyacı da azalır.

Bu nedenle modern PAM'de önemli prensiplerden biri:

Know the identity, not the privileged password.

şeklinde düşünülebilir.

Kurum kimin eriştiğini bilmelidir; ancak kullanıcının privileged password'u bilmesi gerekmeyebilir.

Password Checkout ile Passwordless Privileged Session Arasındaki Fark

Bazı PAM implementations kullanıcıya Vault içerisindeki password'u belirli süreyle gösterebilir. Bu Password Checkout modelidir.

Örneğin administrator password'u 30 dakika için checkout eder, işlemini gerçekleştirir ve süre sonunda password rotate edilir.

Bu traditional model hâlâ bazı systems için gerekli olabilir.

Ancak mümkün olduğunda daha güçlü yaklaşım password'u kullanıcıya hiç göstermemektir.

PAM session'ı kendisi oluşturabilir.

Bu durumda:

User → PAM → Target

modeli uygulanır.

Password target system için hâlâ mevcut olabilir ancak administrator tarafından bilinmez.

Bu yaklaşım credential theft riskini önemli ölçüde azaltabilir.

Automated Password Rotation Nasıl Çalışır?

Privileged credentials uzun süre aynı kaldığında compromise durumunda attacker'ın credential'ı kullanabileceği süre artar.

Bu nedenle PAM platforms privileged passwords'ı otomatik olarak rotate edebilir.

Rotation farklı policies ile uygulanabilir:

periyodik,

her kullanımdan sonra,

risk event sonrasında,

administrator değişikliğinde,

incident sonrasında.

Örneğin root password PAM üzerinden kullanıldıktan sonra otomatik olarak değiştirilebilir.

Böylece administrator daha önce gördüğü password'u tekrar kullanamaz.

Ancak password rotation özellikle service accounts için dikkatli tasarlanmalıdır. Bir application database'e belirli password ile bağlanıyorsa PAM'in password'u değiştirmesi application connection'ını bozabilir.

Bu nedenle service account rotation dependency-aware olmalıdır.

PAM önce credential'ı target system üzerinde değiştirmeli, ardından bu credential'ı kullanan application veya service configuration'ını güvenli şekilde güncellemelidir.

Privileged Session Management PAM Mimarisinde Neden Kritik?

Credential Vault privileged password'u korur.

Ancak doğru administrator doğru credential ile sisteme bağlandıktan sonra yanlış veya riskli işlem gerçekleştirebilir.

Bu nedenle privileged access security yalnız credential security ile bitmez.

Privileged Session Management – PSM, administrator ile target system arasındaki session'ın PAM tarafından kontrol edilmesini sağlar.

Örneğin RDP connection:

Administrator → PAM RDP Proxy → Windows Server

veya SSH connection:

Administrator → PAM SSH Proxy → Linux Server

şeklinde kurulabilir.

Administrator'ın workstation'ı target system'e doğrudan erişmek zorunda kalmayabilir.

Bu architecture aynı zamanda network segmentation açısından da avantaj sağlayabilir.

Target systems yalnız PAM Session Gateway'den gelen administrative connections'a izin verebilir.

Böylece compromised workstation'ın critical server'a doğrudan RDP veya SSH bağlantısı kurması zorlaştırılabilir.

Direct Administrative Access Neden Kapatılmalıdır?

PAM kurulmuş olmasına rağmen administrators target systems'a doğrudan bağlanabiliyorsa PAM controls kolaylıkla bypass edilebilir.

Örneğin user:

PAM üzerinden bağlanmak yerine doğrudan:

mstsc → server

veya:

ssh root@server

kullanabiliyorsa Session Recording, approval workflow ve PAM auditing devre dışı kalır.

Bu nedenle mature PAM architecture içerisinde network-level enforcement önemlidir.

Firewall veya network ACL:

Administrator VLAN → Critical Server RDP/SSH = Deny

PAM Gateway → Critical Server RDP/SSH = Allow

şeklinde tasarlanabilir.

Bu durumda privileged access teknik olarak PAM üzerinden geçmek zorunda kalır.

PAM böylece yalnız policy değil enforced security control haline gelir.

Session Recording ve Privileged Activity Monitoring

PAM Session Proxy üzerinden geçen privileged sessions kayıt altına alınabilir.

Windows RDP sessions visual recording şeklinde, Linux SSH sessions ise command-level veya terminal activity şeklinde izlenebilir.

Bu özellikle:

incident investigation,

forensic analysis,

audit,

accountability

açısından değerlidir.

Ancak kayıtların yalnız oluşturulması yeterli değildir.

Binlerce saatlik administrator session recording bulunabilir ve security team bunları manuel olarak izleyemez.

Bu nedenle modern PAM yaklaşımı privileged session analytics ile birleşmektedir.

Örneğin:

unusual command,

unexpected system access,

suspicious file transfer,

privilege escalation attempt

gibi activities risk signal oluşturabilir.

Bu signals SIEM veya SOC'a gönderilebilir.

Böylece PAM yalnız recording platformu değil, identity threat visibility sağlayan security sensor haline gelir.

Just-in-Time Access PAM Mimarisi Nasıl Değiştirir?

Traditional PAM'de user'ın administrator account'u sürekli mevcut olabilir ancak password Vault tarafından korunur.

JIT yaklaşımı daha ileri gider.

User'ın privileged permission'ı sürekli aktif tutulmaz.

Örneğin administrator production environment üzerinde işlem yapacaksa access request oluşturur.

Policy engine:

user identity,

target resource,

requested privilege,

time,

device,

risk level

gibi context'i değerlendirebilir.

Approval gerekiyorsa ilgili manager veya resource owner onay verir.

Sonrasında privilege örneğin 60 dakika için aktif edilir.

Süre tamamlandığında permission otomatik kaldırılır.

Bu model:

Standing Admin

yerine:

Eligible / Temporary Admin

yaklaşımını oluşturur.

Attacker user account'u compromise ettiğinde üzerinde sürekli administrator privilege bulunmadığı için attack impact azalabilir.

Just-Enough-Access ile Yetki Seviyesini Azaltmak

JIT erişimin süresini sınırlar.

Ancak user temporary olarak full administrator oluyorsa hâlâ gereğinden fazla privilege verilmiş olabilir.

Bu nedenle JEA – Just-Enough-Access uygulanabilir.

Örneğin administrator'ın ihtiyacı yalnız:

service restart

ise ona full root access vermek gerekmeyebilir.

Belirli command veya administrative task için privilege sağlanabilir.

Bu model:

Maximum Access

yerine:

Task-Based Access

yaklaşımıdır.

JIT ve JEA birlikte uygulandığında:

Minimum Time + Minimum Privilege

elde edilir.

Bu Least Privilege prensibinin privileged access ortamındaki en güçlü uygulamalarından biridir.

Zero Standing Privilege Modern PAM'in Hedefi Olabilir

Zero Standing Privilege, yani ZSP, privileged access üzerinde kalıcı yetkileri mümkün olduğunca ortadan kaldırmayı amaçlar.

Traditional model:

User = Permanent Administrator

Modern model:

User = Standard Identity

↓

Need Privilege

↓

Policy Evaluation

↓

Temporary Privilege

↓

Perform Task

↓

Privilege Removed

Bu yaklaşım attacker's opportunity window'u ciddi şekilde daraltabilir.

Bir account günün 24 saati administrator olmak yerine yalnız 30 dakika administrator olabilir.

Matematiksel olarak bile privilege exposure süresi önemli ölçüde azalır.

Ancak Zero Standing Privilege her system için aynı kolaylıkla uygulanamaz.

Legacy systems, network devices veya bazı applications permanent privileged accounts gerektirebilir.

Bu nedenle ZSP çoğu organization için tek seferde uygulanacak binary hedef değil, zaman içerisinde artırılacak bir maturity direction olarak değerlendirilmelidir.

PAM, PIM ve JIT Arasındaki İlişki

PAM daha geniş privileged access security architecture'ıdır.

PIM – Privileged Identity Management ise özellikle privileged roles ve identities'in lifecycle, eligibility ve activation süreçleriyle ilişkilidir.

Örneğin cloud administrator sürekli Global Administrator olmayabilir.

User role için eligible olabilir.

İhtiyaç anında role activate edilir.

Activation sırasında:

MFA,

justification,

approval,

limited duration

uygulanabilir.

Microsoft Entra Privileged Identity Management bu yaklaşımın cloud identity tarafındaki örneklerinden biridir.

Ancak enterprise PAM'in scope'u daha geniştir.

PAM:

Password Vault,

Credential Rotation,

RDP/SSH Session Proxy,

Session Recording,

Service Account Management,

Endpoint Privilege Management,

Secrets Management

gibi use case'leri de kapsayabilir.

Bu nedenle:

PIM ⊂ Privileged Identity Security

şeklinde düşünmek birçok architecture için daha açıklayıcı olabilir.

Endpoint Privilege Management PAM Mimarisine Nasıl Dahil Edilir?

Privileged access yalnız servers ve cloud consoles üzerinde gerçekleşmez.

Employee endpoints üzerinde local administrator rights da ciddi risk oluşturabilir.

Bir user local administrator ise malicious application:

security tools'ı değiştirmeye,

system configuration üzerinde işlem yapmaya,

additional software yüklemeye

çalışabilir.

Bu nedenle modern PAM programs Endpoint Privilege Management – EPM/PEDM katmanını da içerebilir.

User local administrator olmaktan çıkarılır.

Belirli application veya process gerektiğinde elevated privilege ile çalıştırılır.

Örneğin:

User = Standard

Application A = Allow Elevation

Unknown Installer = Block

PowerShell = Policy Controlled

Bu yaklaşım ransomware ve endpoint privilege abuse riskini azaltmaya yardımcı olabilir.

Active Directory PAM Mimarisi Nasıl Tasarlanmalıdır?

Active Directory privileged access açısından en kritik systems'dan biridir.

Domain Admin, Enterprise Admin ve benzeri accounts Tier 0 identities olarak değerlendirilebilir.

Bu accounts günlük kullanım için kullanılmamalıdır.

Administrator e-mail okumak veya internete erişmek için Domain Admin identity kullanmamalıdır.

Daha güvenli architecture içerisinde:

Normal User Account

ve

Privileged Administrative Identity

ayrıştırılır.

Privileged access PAM üzerinden sağlanır.

Administrative workstation veya PAW kullanılabilir.

Network segmentation privileged management traffic'i sınırlandırabilir.

PAM session'ları SIEM'e gönderilebilir.

Böylece Domain Admin credential'ın normal endpoint üzerinde exposure riski azaltılır.

Database PAM Entegrasyonu

Database administrator accounts son derece yüksek risk taşıyabilir.

Oracle, PostgreSQL, Microsoft SQL Server veya diğer database platforms üzerinde privileged accounts:

schema değiştirebilir,

data okuyabilir,

user oluşturabilir,

audit settings değiştirebilir.

Bu nedenle database privileged access PAM kapsamına alınmalıdır.

Administrator database password'unu bilmeden PAM üzerinden connection kurabilir.

Session audit uygulanabilir.

Ayrıca database tarafında Database Activity Monitoring – DAM ile PAM logs correlate edilebilir.

Örneğin:

PAM:

Kim bağlandı?

DAM:

Database üzerinde hangi query çalıştırıldı?

sorusuna cevap verebilir.

Bu iki telemetry birlikte güçlü accountability sağlar.

Firewall, Switch ve Network Device PAM Entegrasyonu

Network infrastructure administrator credentials da privileged identity kapsamındadır.

Firewall, router, switch, wireless controller ve load balancer gibi systems'ın compromise edilmesi attacker'a network architecture üzerinde büyük kontrol sağlayabilir.

Bu nedenle network devices için:

centralized privileged access,

password rotation,

SSH session management,

command auditing

uygulanabilir.

Özellikle shared:

admin

accounts yerine personal identity → PAM → device modelinin kullanılması accountability açısından önemlidir.

Backup Sistemleri PAM Kapsamına Alınmalı mı?

Kesinlikle değerlendirilmelidir.

Ransomware attackers için backup infrastructure önemli hedeftir.

Attacker production systems'ı encrypt etmeden önce backup repositories veya backup management console üzerinde işlem yapmaya çalışabilir.

Bu nedenle Backup Administrator credentials normal Domain Admin credentials'dan ayrıştırılmalıdır.

Backup infrastructure için:

dedicated privileged identities,

MFA,

PAM,

network segmentation,

immutable backup

gibi controls birlikte kullanılmalıdır.

PAM burada cyber resilience architecture'ın önemli parçası haline gelir.

Cloud PAM Mimarisi

Cloud environments privileged access modelini önemli ölçüde değiştirmiştir.

AWS, Azure ve Google Cloud gibi environments içerisinde administrator access yalnız passwords ile yönetilmez.

Roles, policies, service principals, temporary credentials ve workload identities kullanılabilir.

Bu nedenle cloud PAM architecture:

Credential Vault

merkezli olmaktan çok:

Identity + Entitlement + Temporary Privilege

merkezli hale gelir.

Örneğin cloud administrator permanent Owner role taşımak yerine ihtiyaç anında temporary role activation kullanabilir.

Bu JIT ve Zero Standing Privilege yaklaşımıdır.

Cloud PAM ayrıca CIEM ile birlikte excessive permissions'ı tespit etmek için kullanılabilir.

DevOps ve PAM Entegrasyonu

DevOps environments traditional PAM için önemli challenge oluşturur.

CI/CD pipeline production deployment yapabilir.

Automation script database migration çalıştırabilir.

Infrastructure-as-Code platform cloud resources oluşturabilir.

Bu processes interactive human administrator değildir ancak privileged operations gerçekleştirir.

Dolayısıyla DevOps identities de PAM veya Secrets Management scope'una alınmalıdır.

Pipeline içerisinde static administrator password tutmak yerine:

Secrets Vault,

Workload Identity,

Short-Lived Token,

Dynamic Credential

kullanılabilir.

Bu DevSecOps ve PAM'in kesiştiği noktadır.

Dynamic Secrets ve Short-Lived Credentials

Traditional credential:

username + password → aylarca geçerli

olabilir.

Modern secrets architecture ise credential'ı ihtiyaç anında oluşturabilir.

Örneğin application database'e bağlanacağı zaman Vault temporary credential üretir.

Credential:

15 dakika,

30 dakika,

1 saat

geçerli olabilir.

Sonrasında otomatik expire olur.

Bu Dynamic Secrets yaklaşımıdır.

Attacker credential'ı ele geçirse bile usable lifetime sınırlıdır.

Bu nedenle modern PAM ve Secrets Management architecture'ın önemli yönlerinden biri:

Static Privilege → Ephemeral Privilege

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

Non-Human Identity ve PAM

Modern kurumlarda privileged access yalnız humans tarafından kullanılmaz.

Service Accounts,

Applications,

APIs,

Automation Bots,

CI/CD Pipelines,

Cloud Workloads,

AI Agents

privileged operations gerçekleştirebilir.

Bu identities Non-Human Identities – NHI olarak değerlendirilir.

NHI sayısı cloud ve automation arttıkça human identities'in çok üzerine çıkabilir.

Bu nedenle PAM architecture artık yalnız administrator passwords üzerine kurulamaz.

Modern architecture:

Human Privileged Identity

ve

Machine Privileged Identity

birlikte yönetmelidir.

AI Agent PAM Mimarisi Nasıl Olmalı?

Agentic AI adoption privileged access açısından yeni bir architecture requirement oluşturur.

AI Agent'ın infrastructure üzerinde autonomous action gerçekleştirmesine izin veriliyorsa agent'a identity verilmelidir.

Ancak agent'a static root password vermek modern security principles ile çelişir.

Daha güvenli model:

AI Agent Identity

↓

Requested Action

↓

Policy Engine

↓

Human Approval / Automated Risk Decision

↓

Short-Lived Privilege

↓

Action

↓

Audit

↓

Privilege Revocation

şeklinde olabilir.

Örneğin AI-based SOC Agent compromised endpoint tespit etti.

Agent network isolation action gerçekleştirmek istiyor.

Agent'ın bütün EDR platformunda permanent administrator olması yerine yalnız:

isolate_endpoint

permission'ı temporary olarak verilebilir.

Bu geleceğin PAM architecture'ında Agentic Privilege Management olarak gelişebilecek önemli alanlardan biridir.

PAM ve SIEM/SOC Entegrasyonu

PAM architecture monitoring olmadan tamamlanmış sayılmamalıdır.

PAM events SIEM'e gönderilebilir.

Özellikle:

Failed Privileged Authentication

New Vault Account

Password Checkout

JIT Activation

Privilege Elevation

Break-Glass Access

Suspicious Session

Blocked Command

gibi events SOC için yüksek değer taşır.

Ancak PAM loglarını yalnız toplamak yeterli değildir.

Correlation rules oluşturulmalıdır.

Örneğin:

EDR Malware Alert

Same User PAM Login

JIT Domain Admin Request

aynı zaman aralığında görülüyorsa critical incident oluşturulabilir.

Bu Identity + Endpoint + Privilege correlation modern SOC architecture'ın güçlü use case'lerinden biridir.

ITDR ile PAM Birlikte Nasıl Çalışır?

ITDR identity attacks'ı detect etmeye odaklanırken PAM privileged access'i enforce eder.

Örneğin ITDR user'ın account takeover riski taşıdığını tespit etti.

PAM bu identity'nin privileged request'lerini otomatik block edebilir veya additional approval isteyebilir.

Bu durumda:

Detect Risk → Adjust Privilege

modeli oluşur.

Geleceğin Identity Security architecture'ında PAM policies static olmaktan çıkıp real-time risk signals'a göre dinamik hale gelebilir.

PAM Sisteminin Kendisi Nasıl Korunmalıdır?

PAM architecture'ın en kritik konularından biri budur.

Çünkü PAM platformu kurumun en değerli privileged credentials ve administrative access paths'ını yönetebilir.

Bu nedenle PAM'in kendisi Tier 0 / Critical Security Infrastructure olarak değerlendirilmelidir.

PAM administrator accounts sıradan administrator accounts ile aynı olmamalıdır.

PAM infrastructure için:

Network Segmentation

Strong MFA

Dedicated Administration

Least Privilege

Hardened Operating Systems

Restricted Internet Access

EDR

SIEM Monitoring

Secure Backup

High Availability

Disaster Recovery

uygulanmalıdır.

PAM database ve Vault backup'ları da yüksek güvenlikle korunmalıdır.

Çünkü attacker PAM infrastructure'ı compromise ederse çok sayıda privileged system'e ulaşmak için merkezi bir avantaj elde edebilir.

Bu nedenle PAM:

Security Tool

olduğu kadar:

High-Value Target

olarak da düşünülmelidir.

PAM High Availability Neden Önemlidir?

PAM bütün administrative access'in merkezi noktası haline geldiğinde platform outage operasyonları etkileyebilir.

Örneğin production server arızalandı ancak PAM platformu erişilemiyor.

Administrator critical system'e bağlanamıyor.

Bu nedenle enterprise PAM architecture High Availability gerektirir.

Components redundancy ile çalışabilir.

Vault, Session Gateway ve application components için failover tasarlanabilir.

Amaç PAM'in Single Point of Failure haline gelmesini engellemektir.

PAM Disaster Recovery Nasıl Planlanmalıdır?

High Availability aynı datacenter içerisindeki failures'a karşı koruma sağlayabilir.

Ancak site-level disaster durumunda ayrı DR architecture gerekebilir.

PAM Disaster Recovery planında:

Vault replication,

configuration backup,

credential consistency,

encryption keys,

recovery procedures,

DNS/network dependencies

dikkate alınmalıdır.

En önemli konu ise DR planının yalnız dokümanda bulunmamasıdır.

Periyodik PAM DR testleri yapılmalıdır.

Çünkü gerçek incident sırasında:

“PAM çalışmıyor, administrator password'larını bilmiyoruz.”

durumu kritik operasyonel probleme dönüşebilir.

Emergency Access ve Break-Glass Architecture

PAM tamamen erişilemez olduğunda critical systems için emergency access mekanizması gerekebilir.

Bu amaçla Break-Glass accounts kullanılabilir.

Ancak Break-Glass PAM'i bypass ettiği için yüksek risk taşır.

Credential:

offline secure storage,

physical security,

dual control

gibi yöntemlerle korunabilir.

Kullanım sonrasında:

alert,

incident review,

credential rotation

uygulanmalıdır.

Break-Glass access normal operational shortcut haline gelmemelidir.

PAM Network Segmentation Nasıl Yapılmalı?

PAM infrastructure critical network zone içerisinde konumlandırılabilir.

User networks target servers'a doğrudan administrative ports üzerinden erişmemelidir.

Örnek architecture:

Admin Workstation

↓

PAM Access Layer

↓

PAM Session Gateway

↓

Management Network

↓

Critical Servers

Target servers yalnız PAM Gateway'den gelen management traffic'i kabul edebilir.

Bu model lateral movement riskini azaltabilir.

Aynı zamanda attacker'ın compromised endpoint üzerinden doğrudan server administration yapmasını zorlaştırır.

PAM ile Privileged Access Workstation Birlikte Kullanılmalı mı?

High-security environments içerisinde Privileged Access Workstation – PAW veya Secure Administrative Workstation kullanılabilir.

Administrator normal laptop üzerinden privileged operations gerçekleştirmez.

Dedicated hardened workstation kullanır.

Bu device:

internet browsing,

personal e-mail,

unapproved software

için kullanılmaz.

PAW + PAM birlikte kullanıldığında:

Trusted Admin Device + Controlled Identity + Controlled Session

modeli oluşur.

Bu özellikle Tier 0 infrastructure için güçlü security architecture sağlar.

PAM Ürün Seçiminde Mimari Kriterler

CyberArk, BeyondTrust, Delinea, One Identity Safeguard, WALLIX, ManageEngine PAM360, Keycyte ve diğer PAM platforms değerlendirilirken yalnız product feature listesine bakılmamalıdır.

Kurumun gerçek architecture requirements'ı belirlenmelidir.

Örneğin şu sorular sorulabilir:

On-premises mı cloud PAM mi kullanılacak?

Kaç privileged account var?

Kaç concurrent session var?

RDP ve SSH proxy gerekli mi?

Database access desteklenmeli mi?

Network devices onboarding yapılacak mı?

Service account rotation gerekli mi?

DevOps secrets yönetilecek mi?

Endpoint Privilege Management gerekiyor mu?

JIT/ZSP support ne kadar önemli?

SIEM/SOC integration nasıl yapılacak?

HA/DR architecture nasıl olacak?

Bu soruların cevapları product selection'ı yönlendirmelidir.

PAM ürünü architecture'ı belirlememeli; PAM architecture hangi ürünün uygun olduğunu belirlemelidir.

PAM Mimarisinde En Sık Yapılan Hatalar

Kurumsal PAM projelerinde aşağıdaki hatalar sık görülür:

• PAM'i yalnız Password Vault olarak konumlandırmak
• Privileged Account Discovery yapmamak
• PAM dışındaki administrator accounts'ı gözden kaçırmak
• Direct RDP/SSH access'i açık bırakmak
• Users'ın passwords'ı görmesine izin vermek
• Password Rotation uygulamamak
• Service Account dependencies'i analiz etmeden rotation yapmak
• JIT Access kullanmamak
• Standing Privileges'ı azaltmamak
• Local Admin Rights'ı PAM dışında bırakmak
• Cloud Privileges'ı kapsam dışında tutmak
• DevOps Secrets'ı PAM/NHI programına almamak
• PAM Session Recording yapıp kayıtları analiz etmemek
• PAM logs'u SIEM'e göndermemek
• Break-Glass accounts'ı izlememek
• PAM infrastructure'ı Tier 0 olarak korumamak
• PAM HA tasarlamamak
• PAM DR testlerini yapmamak
• Network Segmentation uygulamamak
• PAM'i tek seferlik teknoloji projesi olarak görmek

Kurumsal PAM Mimarisi Kontrol Listesi

PAM architecture değerlendirmesinde aşağıdaki kontroller kullanılabilir:

• Privileged Identity Inventory mevcut mu?
• Privileged Account Discovery yapılıyor mu?
• Risk-based PAM onboarding uygulanıyor mu?
• Domain Admin accounts PAM kapsamında mı?
• Cloud Administrator roles PAM/PIM kapsamında mı?
• Database administrators PAM üzerinden erişiyor mu?
• Network administrators PAM üzerinden erişiyor mu?
• Backup administrators ayrı yönetiliyor mu?
• Service Accounts inventory'de mi?
• Credential Vault kullanılıyor mu?
• Password Checkout minimum seviyede mi?
• Passwordless privileged session destekleniyor mu?
• Automated Password Rotation aktif mi?
• Direct RDP/SSH erişimleri engelleniyor mu?
• Privileged Session Proxy kullanılıyor mu?
• Session Recording aktif mi?
• JIT Access uygulanıyor mu?
• JEA uygulanıyor mu?
• Zero Standing Privilege roadmap'i var mı?
• Endpoint Privilege Management kullanılıyor mu?
• Local Admin Rights azaltılıyor mu?
• DevOps Secrets merkezi yönetiliyor mu?
• Dynamic Secrets değerlendiriliyor mu?
• Non-Human Identities PAM kapsamına alınıyor mu?
• AI Agent privileges kontrol ediliyor mu?
• PAM logs SIEM'e gönderiliyor mu?
• ITDR ile entegrasyon değerlendiriliyor mu?
• PAM network segment ayrı mı?
• PAM administrator identities ayrıştırılmış mı?
• PAM için Strong MFA uygulanıyor mu?
• PAM High Availability mevcut mu?
• PAM Disaster Recovery mevcut mu?
• DR düzenli test ediliyor mu?
• Break-Glass accounts kontrol altında mı?
• Emergency Access kullanımı alert üretiyor mu?

PAM Olgunluk Seviyeleri

Seviye 1 – Direct Privileged Access: Administrators target systems'a doğrudan bağlanır. Shared passwords ve permanent privileges yaygındır. Privileged activity visibility düşüktür.

Seviye 2 – Vault-Centric PAM: Administrator credentials Vault'a alınmıştır. Password Rotation uygulanır ancak direct access veya standing privilege devam edebilir.

Seviye 3 – Session-Centric PAM: Administrative access PAM Session Gateway üzerinden geçirilir. MFA, Session Recording ve approval workflows uygulanır.

Seviye 4 – JIT Privilege Architecture: Permanent administrator permissions azaltılır. JIT, JEA, PIM ve Endpoint Privilege Management kullanılır. PAM, SIEM ve ITDR ile entegre edilir.

Seviye 5 – Zero Standing Privilege Architecture: Human, Machine ve AI Agent identities için privileged access ihtiyaç anında ve policy-driven olarak oluşturulur. Short-lived credentials, dynamic secrets ve continuous risk evaluation kullanılır.

Bu dönüşüm:

Password Management

↓

Session Management

↓

Privilege Management

↓

Identity-Based Privilege

↓

Zero Standing Privilege

şeklinde ilerler.

Sık Sorulan Sorular

PAM mimarisi nedir?

PAM mimarisi, privileged identities, credentials ve administrative sessions'ın güvenli şekilde yönetilmesini sağlayan Vault, Session Management, MFA, JIT, JEA, credential rotation, monitoring ve governance bileşenlerinin birlikte çalıştığı güvenlik yapısıdır.

PAM Vault nedir?

Privileged passwords, secrets ve diğer sensitive credentials'ın merkezi ve encrypted şekilde saklandığı güvenlik bileşenidir.

PAM Session Proxy nedir?

Administrator ile target system arasındaki RDP, SSH veya benzeri privileged connection'ın PAM üzerinden geçirilmesini sağlayan ara katmandır.

JIT Access nedir?

Administrator privilege'ın sürekli aktif tutulması yerine yalnız ihtiyaç duyulan süre boyunca geçici olarak verilmesidir.

JEA nedir?

Just-Enough-Access, user'a yalnız gerçekleştireceği işlem için gereken minimum privilege'ın verilmesini amaçlar.

Zero Standing Privilege nedir?

Identities üzerinde permanent privileged permission bırakmak yerine privilege'ın ihtiyaç anında temporary olarak oluşturulması ve işlem sonrasında kaldırılması yaklaşımıdır.

PAM ile PIM arasındaki fark nedir?

PIM çoğunlukla privileged roles ve role activation süreçlerine odaklanırken PAM credential, session, password rotation, service account ve endpoint privilege gibi daha geniş privileged access security capabilities içerebilir.

PAM'de direct RDP neden kapatılmalıdır?

Administrator target server'a PAM dışında doğrudan bağlanabiliyorsa Session Recording, approval ve other PAM controls bypass edilebilir.

PAM için High Availability gerekli midir?

PAM critical administrative access'in merkezi haline geliyorsa availability son derece önemlidir. PAM outage durumunda administrators critical systems'a erişemeyebilir.

PAM için Disaster Recovery gerekli midir?

Evet. PAM'in credentials ve privileged access infrastructure'ı kritik olduğundan site-level failure ve disaster scenarios için recovery planı bulunmalıdır.

PAM sunucusu ele geçirilirse ne olur?

PAM yüksek değerli security infrastructure olduğu için compromise ciddi risk oluşturabilir. Bu nedenle PAM systems Tier 0 seviyesinde korunmalı; network segmentation, MFA, dedicated administration, EDR, SIEM monitoring, secure backup ve strong hardening uygulanmalıdır.

PAM cloud ortamında gerekli midir?

Evet. Ancak cloud privileged access yalnız passwords üzerinden yönetilmez. Cloud roles, JIT activation, temporary credentials, PIM, workload identities ve entitlement management modern cloud PAM architecture'ın parçalarıdır.

PAM DevOps için kullanılabilir mi?

Evet. CI/CD pipelines, applications ve automation systems tarafından kullanılan secrets ve privileged credentials PAM, Secrets Management veya Workload Identity technologies ile yönetilebilir.

AI Agent PAM'e dahil edilmeli mi?

AI Agent privileged action gerçekleştirebiliyorsa identity, authorization ve privilege lifecycle açısından PAM principles uygulanmalıdır. Agent'ın permanent administrator credential ile çalışması yerine scoped ve short-lived privileges tercih edilmelidir.

Sonuç: Güçlü PAM Mimarisi Vault'tan Değil, Privileged Access Akışından Başlar

PAM projesinde Password Vault önemli bir bileşendir.

Ancak Vault tek başına PAM architecture değildir.

Gerçek security value administrator'ın target system'e nasıl ulaştığı, privilege'ın nasıl verildiği, ne kadar süre aktif kaldığı, session'ın nasıl izlendiği ve işlem sonrasında yetkinin nasıl kaldırıldığıyla ortaya çıkar.

Traditional architecture:

Administrator → Password → Server

modeline dayanıyordu.

Modern PAM architecture ise:

Identity → Strong Authentication → Policy → JIT/JEA → Controlled Session → Monitoring → Automatic Revocation

modeline doğru ilerlemektedir.

Bu değişim son derece önemlidir.

Çünkü ilk modelde güvenlik:

credential'a

dayanır.

İkinci modelde ise güvenlik:

identity + context + privilege + time + behavior

üzerinden sağlanır.

Cloud ve automation adoption arttıkça bu architecture daha da değişmektedir.

Static passwords yerini short-lived credentials'a bırakmaktadır.

Permanent administrator roles yerini JIT role activation'a bırakmaktadır.

Human administrators'ın yanına service accounts, workloads ve AI Agents eklenmektedir.

Bu nedenle geleceğin PAM architecture'ı yalnız administrator passwords'ı koruyan bir sistem olmayacaktır.

Modern PAM:

Human Privileged Access + Machine Privileged Access + Cloud Privilege + AI Agent Privilege

katmanlarını ortak policy ve audit modeli içerisinde yönetmek zorunda kalacaktır.

Ancak bütün teknolojik dönüşümlerin merkezinde aynı prensip bulunur:

Least Privilege.

Kullanıcıya veya machine identity'ye ihtiyacından daha fazla privilege verilmemeli ve bu privilege ihtiyacından daha uzun süre açık tutulmamalıdır.

Bu nedenle modern PAM'in temel formülü:

Discover → Verify → Authorize → Elevate → Monitor → Expire

şeklinde özetlenebilir.

Daha güçlü güvenlik hedefi ise:

No Direct Access + No Shared Credentials + No Permanent Admin + No Unmonitored Privileged Session

yaklaşımıdır.

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

Modern PAM mimarisinin amacı administrator parolasını daha iyi saklamak değil; administrator yetkisinin nerede, neden, kim tarafından, ne kadar süreyle ve hangi işlem için kullanılabileceğini kontrol altına almaktır.