Identity and Access Management — MFA, RBAC, and Privileged Access

Identity is the new perimeter. In modern enterprise environments, the majority of breaches begin with a compromised credential — not a firewall bypass or a zero-day exploit. The 2024 Verizon DBIR found that credentials were involved in 86% of web application breaches. Attackers do not hack in — they log in.

Identity and Access Management (IAM) is the set of processes, policies, and technologies that control who can do what in an organisation's systems. Getting IAM right — proper authentication, least-privilege authorisation, privileged access controls, and identity lifecycle management — eliminates the most common attack vectors at their root.

Authentication Factors and Their Attack Resistance

Authentication proves identity. The strength of authentication depends on what factors are used and how resistant they are to the attacks we have studied throughout this course.

The key distinction: TOTP codes can be phished in real time — an AiTM (Adversary-in-the-Middle) proxy captures the code as the victim types it and replays it to the real site before it expires. FIDO2/WebAuthn hardware keys and passkeys cannot be phished because they perform a cryptographic origin verification — the key refuses to respond to a phishing site because the origin URL does not match.

The CISA recommendation: all organisations handling sensitive data should migrate critical account authentication to phishing-resistant MFA (FIDO2, passkeys) and treat TOTP as an interim control only.

Authorisation Models — RBAC, ABAC, and ReBAC

Authentication proves who you are. Authorisation determines what you can do. Three primary models dominate enterprise authorisation:

# RBAC implementation example (AWS IAM):

# Define roles with minimum necessary permissions:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOnlyS3ForReports",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::reports-bucket", "arn:aws:s3:::reports-bucket/*"],
      "Condition": {
        "StringEquals": {"s3:prefix": "public/"}
      }
    }
  ]
}

# Permission boundary — caps the maximum permissions even if broader policy attached
# Prevents privilege escalation via role assumption


# ABAC implementation example (OPA — Open Policy Agent):
package app.authz

# Allow access only if user's department matches resource's department
# AND user has the required action in their role

allow {
  input.user.department == input.resource.department
  input.user.role == "manager"
  input.action == "approve"
}

# OPA is used by: Kubernetes admission control, Envoy sidecar, custom apps
# Declarative policy — version controlled, testable, auditable

Single Sign-On and Federation

Single Sign-On (SSO) allows a user to authenticate once to a central identity provider (IdP) and access multiple applications without re-authenticating. Beyond convenience, SSO has a security advantage: it centralises authentication enforcement — MFA policies, account lockout, and session management are all handled in one place.

SSO / Federation architecture:

  User → [Browser] → Application (Service Provider / SP)
                          │
                          │ "Who is this user?" (SAML/OIDC redirect)
                          ▼
                 Identity Provider (IdP)
                  (Okta / Entra ID / Google)
                          │
                          │ "User authenticated — here are their claims"
                          │ (SAML assertion or OIDC ID token)
                          ▼
                     Application grants access


# SAML 2.0 — enterprise standard (XML-based)
# Used by: Salesforce, AWS, legacy enterprise apps
# IdP-initiated vs SP-initiated SSO
# Assertion signing (IdP signs with X.509 cert) — SP verifies signature
# Common vulnerability: XML signature wrapping attacks

# OIDC (OpenID Connect) — modern, REST-based (built on OAuth 2.0)
# Used by: Google, GitHub, modern web apps
# Returns ID token (JWT) with user claims: sub, email, name, groups

# SCIM (System for Cross-domain Identity Management)
# Automates user provisioning/deprovisioning across systems
# When user is created in Okta → SCIM creates account in Salesforce, GitHub, etc.
# When user is terminated → SCIM deactivates all accounts automatically
# Closes the "orphaned accounts" problem

# Identity federation — connecting multiple organisations
# Partner companies federate their IdPs
# User from partner org logs in with their credentials → IdP-to-IdP trust
# Used in M&A scenarios, contractor access

Privileged Access Management (PAM)

Privileged accounts — domain admins, cloud root accounts, database admins, service accounts — are the highest-value targets for attackers. Privileged Access Management is the set of controls specifically for these accounts.

Just-in-Time (JIT) access is one of the most impactful PAM controls. Instead of permanent domain admin access, an engineer requests elevation, a manager approves it, the engineer gets admin rights for 2 hours, and then the rights are automatically removed. An attacker who compromises the engineer's account outside the approval window has no elevated access.

# JIT access workflow:

Engineer requests: "I need domain admin for DB migration — 2 hours"
                              │
              ┌───────────────┴────────────────┐
              │ PAM system checks:              │
              │ - Is this a known maintenance   │
              │   window?                       │
              │ - Does the request match the    │
              │   engineer's job function?      │
              │ - Is a second approver present? │
              └───────────────┬────────────────┘
                              │ Approval via Slack / PagerDuty
              ┌───────────────┴────────────────┐
              │ PAM creates temporary account:  │
              │ - Added to "Domain Admins" group│
              │ - Session recorded              │
              │ - Time limit: 2 hours           │
              │ - Alert sent to SIEM            │
              └───────────────┬────────────────┘
                              │ 2 hours later (or manual revoke)
              ┌───────────────┴────────────────┐
              │ PAM automatically:              │
              │ - Removes from Domain Admins    │
              │ - Rotates any credentials used  │
              │ - Archives session recording    │
              └────────────────────────────────┘

Tools: CyberArk Privileged Access Manager, Delinea (formerly Thycotic),
       BeyondTrust Password Safe, HashiCorp Vault SSH secrets engine,
       AWS IAM Identity Center, Microsoft PIM (Privileged Identity Management)

Identity Governance — Lifecycle Management

Identity governance ensures that access is correct throughout the entire user lifecycle — from onboarding to role changes to offboarding. Access accumulation (users gaining permissions over time without losing old ones) and orphaned accounts (active accounts for former employees) are two of the most common findings in security audits.

# ━━ JOINER-MOVER-LEAVER LIFECYCLE ━━━━━━━━━━━━━━━━━━━━━━━━━

JOINER (new employee):
  1. HR system creates employee record
  2. SCIM auto-provisions accounts in: SSO IdP, email, Slack, GitHub org
  3. RBAC role assigned based on job title + department
  4. Manager receives onboarding checklist confirming access granted
  5. First-login forces password change and MFA enrolment

MOVER (role change / promotion / transfer):
  1. HR system updates role/department
  2. SCIM triggers access change: new role's permissions added
  3. Old role's permissions removed (role swapped, not accumulated)
  4. Access review triggered for any retained non-standard permissions

LEAVER (termination):
  1. HR system marks employee inactive
  2. IMMEDIATE actions (within 1 hour):
     - SSO session terminated and account disabled
     - All OAuth tokens revoked
     - All active sessions killed
     - Privileged access revoked
  3. SAME DAY: corporate device remotely wiped (MDM command)
  4. 30 DAYS: account archived; access removed from all systems via SCIM
  5. LONG TERM: email forwarded to manager for 90 days


# ━━ ACCESS REVIEWS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# Quarterly access reviews — required by SOC 2, ISO 27001, PCI-DSS
# Manager reviews all direct reports' access:
# "Does Alice still need access to the production database? Yes / No"
# Certify or revoke

# Tools:
# Saviynt, SailPoint — enterprise IGA platforms
# Microsoft Entra Identity Governance — access reviews in Entra P2
# Okta Lifecycle Management — automated joiner/mover/leaver

# What to audit:
SELECT username, last_login, created_date, role
FROM users
WHERE last_login < NOW() - INTERVAL '90 days'  -- dormant accounts
   OR role IN ('admin', 'superadmin', 'dbadmin'); -- privileged accounts

# Service account inventory:
# Every service account should have:
# - An owner (person, team)
# - A documented purpose
# - A rotation schedule for its credentials
# - A minimum-privilege permission set
# Accounts with no owner or no last-use date should be disabled

IAM for Cloud Environments

Cloud IAM has unique challenges: the attack surface is entirely API-based, misconfigured permissions grant instant access to data at scale, and the blast radius of a single compromised role can span thousands of resources.

# AWS IAM best practices

# 1. Lock the root account
aws iam create-virtual-mfa-device ...      # enable MFA on root
aws iam update-account-password-policy ... # strong password policy
# Never use root for daily operations — create admin IAM users

# 2. Use IAM roles, not IAM users, for applications
# Users have static credentials (access key + secret) — they leak
# Roles have temporary credentials that expire automatically

# 3. Enforce MFA for console access
aws iam put-user-policy --policy-document '{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "NotAction": ["iam:CreateVirtualMFADevice", "iam:EnableMFADevice",
                  "iam:GetUser", "iam:ListMFADevices", "iam:ListVirtualMFADevices",
                  "sts:GetSessionToken"],
    "Resource": "*",
    "Condition": {
      "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
    }
  }]
}'

# 4. Detect over-privileged permissions with Access Analyzer
aws accessanalyzer create-analyzer --analyzer-name MyAnalyzer --type ACCOUNT
aws accessanalyzer list-findings --analyzer-arn <arn>
# Flags: public S3 buckets, externally accessible roles, unused permissions

# 5. Use IAM Access Advisor to right-size permissions
# Shows last service access date for each permission
# Remove permissions unused for 90+ days

# 6. Service Control Policies (SCPs) — preventive guardrails in AWS Orgs
# Even with full admin in child account, SCP limits what is possible:
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideUS",
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {"aws:RequestedRegion": ["us-east-1", "us-west-2"]}
    }
  }]
}

Interview Questions — Identity and Access Management

Common Mistakes — Identity and Access Management