Domain 5 Β· Lesson 4 of 5

Privileged Access Management

Quản lý Truy cập Đặc quyền

Privileged Account Types & Controls

Type Risk Level Control
Local Admin High Disable default admin accounts; vault-rotate; use named accounts
Domain Admin Critical Use only via PAW; session recording; minimal use; never for email/web browsing
Service Accounts High Vault auto-rotation; least privilege; never interactive login; no shared credentials
Emergency (Break-Glass) Necessary Risk Sealed in Vault; use triggers immediate alert; dual control required; every use reviewed
Shared Accounts Unacceptable Eliminate β€” assign individual named accounts; shared = no individual accountability = audit failure

PAM Controls

JIT

Just-In-Time (JIT) Access

Request β†’ approval β†’ temporary credential granted β†’ auto-revoke after task completes. Limits the exposure window β€” credential only exists when needed.

PAW

Privileged Access Workstation (PAW)

Dedicated hardened workstation used only for admin tasks. No email, no web browsing, no regular user activity allowed. Prevents lateral movement from a compromised admin session.

REC

Session Recording

All privileged sessions are recorded (keystrokes, screen, commands). Prevents abuse by creating accountability and detects anomalous actions after the fact.

VLT

Vault-Managed Credentials

HashiCorp Vault auto-rotates service account passwords on a schedule. Engineers never see plaintext credentials β€” they request a short-lived lease. Rotation happens automatically regardless of staff changes.

BG

Break-Glass Accounts

Emergency admin access for disaster scenarios. Sealed in Vault. Any use triggers an immediate security alert. Dual control required (two-person authorization). Every use is reviewed within 24 hours afterward.

Separation of Duties in Privileged Access

Developer β‰  Deployer β‰  DB Admin β€” different people own different phases of the deployment pipeline to prevent any single person from having end-to-end control.

Developer

Writes code; no prod access

β†’

ArgoCD (automated)

Deploys from approved Git SHA

β†’

DB Admin

Schema changes only; no app logic

Vault policies enforce further SoD β€” who can access what secrets is separate from who can deploy, and separate from who can run DB migrations.

Kerberoasting Attack

The Attack

  1. Attacker gains any domain user account
  2. Requests Kerberos service tickets for service accounts (any domain user can do this)
  3. Takes encrypted tickets offline for password cracking
  4. Cracks weak service account passwords offline
  5. Uses credentials for lateral movement

Defense

  • β€’ Long, complex, randomly generated service account passwords
  • β€’ Automated rotation via Vault (password changes frequently)
  • β€’ Minimize service accounts with Kerberos SPNs
  • β€’ Monitor for unusual Kerberos ticket requests
  • β€’ Prefer Managed Service Accounts (MSA) in Windows environments

Key Terms

PAM JIT Access PAW Session Recording Break-Glass Account Service Account Vault Kerberoasting Least Privilege Separation of Duties
Exam Tips
  1. Shared accounts = no individual accountability = audit failure β€” always eliminate them and assign named individual accounts.
  2. JIT access: provision only when needed, auto-revoke after β€” limits the exposure window vs permanent standing privileges.
  3. Break-glass accounts: any use triggers an immediate alert β€” must be reviewed after every single use.
  4. Vault auto-rotation: service accounts never have long-lived static passwords β€” engineers request short-lived leases.
  5. PAW: dedicated admin workstation β€” no regular user activity (no email, no browsing) β€” prevents admin session compromise via phishing.
Work Application β€” FinTech Company X PAM
  1. Vault secrets: All service-to-service secrets (DB credentials, API keys, TLS certs) in Vault with auto-rotation. No static API keys in environment variables or .env files.
  2. ArgoCD deploy SoD: Engineers do NOT have kubectl exec access to production pods. All production changes go through ArgoCD from an approved Git SHA.
  3. Database access: No individual engineer has direct production DB access. All queries go through the application layer or an approved admin tool with session recording.
  4. Emergency DB access: Break-glass Vault policy β€” requires 2-person approval, session fully recorded, reviewed within 24 hours.
  5. Shared accounts audit: Remove all shared team accounts from admin portals (Bank A admin, eKYC Vendor dashboard, AML Vendor portal) β€” assign individual named accounts to each person.

Practice Quiz

Q1. A shared "admin" account is used by 5 engineers to access the production database. What security property does this violate?

β–Ό Reveal Answer
Accountability β€” there is no individual audit trail. If data is modified or exfiltrated, you cannot determine which of the 5 engineers did it. Shared accounts eliminate non-repudiation.
The 4th A (Accountability) requires that actions be traced to an individual identity. Shared accounts make this impossible β€” any of the 5 users could deny responsibility and you have no way to prove otherwise. This is an automatic audit failure for SOC 2, PCI-DSS, and BSP regulatory reviews. Solution: individual named accounts with individual session recording.

Q2. JIT access vs permanent standing privileges β€” what is the key security advantage of JIT?

β–Ό Reveal Answer
JIT limits the credential exposure window. Permanent standing privileges exist 24/7 β€” if credentials are compromised, an attacker has indefinite access. JIT credentials only exist for the duration of the specific task, then are auto-revoked.
Standing privileges are the norm but represent continuous risk. If an engineer's laptop is compromised, the attacker gains whatever standing privileges that engineer had β€” potentially for weeks until it's detected. JIT limits blast radius: even if credentials leak, they expire in hours or minutes. This is the core principle of Just-In-Time / Zero Standing Privilege.

Q3. An engineer uses the break-glass account at 2am to restore a production database. What MUST happen next?

β–Ό Reveal Answer
The use should have triggered an immediate security alert at the time of use. After the incident: (1) the session recording must be reviewed, (2) the use must be formally documented with justification, (3) reviewed by security/management within 24 hours to confirm it was legitimate.
Break-glass accounts are a necessary risk for disaster recovery, but they must not become a routine bypass. Every use triggers automatic alerts and must be formally reviewed afterward. The review asks: Was this a genuine emergency? Was the minimum necessary access used? Were any anomalous actions taken? If the use was unauthorized, this is a security incident. The password should also be rotated after every use.

Q4. What makes service accounts vulnerable to Kerberoasting, and how does Vault auto-rotation mitigate this?

β–Ό Reveal Answer
Kerberoasting is effective when service accounts have weak, static passwords β€” the attacker takes an encrypted Kerberos ticket offline and cracks it. Vault auto-rotation ensures service account passwords are strong (randomly generated) and change frequently β€” even if a ticket is captured, the cracked password may already be rotated before it can be used.
Kerberoasting doesn't require special privileges β€” any domain user can request service tickets. The attack is offline (no network detection). Long, random passwords make cracking computationally infeasible. Frequent rotation (e.g., every 24 hours via Vault) means even if a ticket is cracked weeks later, the password is no longer valid. Vault also removes the human factor β€” no one knows the plaintext password, so it can't be phished or leaked.

Q5. What is the purpose of a Privileged Access Workstation (PAW), and why can't an admin use their regular laptop for admin tasks?

β–Ό Reveal Answer
A PAW is a dedicated hardened workstation used only for admin tasks β€” no email, no web browsing, no general user activity. A regular laptop used for both email and admin work creates risk: a phishing email or malicious website could compromise the session, granting attackers access to admin credentials and the systems being administered.
The threat model: admins are high-value targets. If an admin browses the web and gets a browser exploit, the attacker has their admin credentials. A PAW mitigates this by complete separation β€” admin tasks only happen on a machine with no attack surface from email/web. The PAW typically has no internet access except to admin-specific systems, no email client, no user-mode software installations. It's expensive in usability but appropriate for domain admins and equivalent privileges.
← Lesson 3: Access Control Models Lesson 5: Identity Lifecycle β†’