8.3 Multi-Factor Authentication, PAM & Machine Identities

Multi-Factor Authentication, PAM & Machine Identities

Compromised credentials remain the leading initial attack vector in enterprise cloud security breaches. Securing modern cloud environments requires layered authentication controls that protect human administrators, enforce contextual verification, and eliminate static, unrotated credentials for automated machine workloads.

For the CompTIA Cloud+ (CV0-004) examination, cloud professionals must master the authentication factor hierarchy, Privileged Access Management (PAM) workflows, Conditional Access engines, and Managed Identities for non-human workloads.

---

1. Multi-Factor Authentication (MFA) Factors & Security Hierarchy

According to NIST SP 800-63B (Digital Identity Guidelines), Multi-Factor Authentication requires the presentation of two or more independent authentication factors from different categories:

+-----------------------------------------------------------------------------------------+
|                           THE THREE AUTHENTICATION FACTORS                              |
|                                                                                         |
|   1. KNOWLEDGE (Something You Know)                                                     |
|      - Passwords, passphrases, PIN codes, secret security questions                     |
|                                                                                         |
|   2. POSSESSION (Something You Have)                                                    |
|      - FIDO2 / WebAuthn hardware security keys (YubiKey), smart cards                   |
|      - Time-based One-Time Password (TOTP) software apps (RFC 6238)                     |
|      - Out-of-band mobile push notifications with number matching                       |
|      - SMS / Voice OTP (Deprecated by NIST due to telecom intercept risks)              |
|                                                                                         |
|   3. INHERENCE (Something You Are)                                                      |
|      - Biometrics: Fingerprint scan, facial recognition, iris/retina scan, voice print  |
+-----------------------------------------------------------------------------------------+

[!IMPORTANT] Critical Exam Distinction: Two of the Same Factor is NOT MFA. Requiring a password and a PIN is two-step single-factor authentication (both are Knowledge factors). True Multi-Factor Authentication requires combining distinct categories (e.g., a Knowledge password + a Possession hardware token).

MFA Vulnerability Analysis & Phishing Resistance

Not all MFA implementations provide equal security strength:

+-----------------------------------------------------------------------------------------+
|                             MFA SECURITY STRENGTH SPECTRUM                              |
|                                                                                         |
|   LOW SECURITY                  MODERATE SECURITY             MAXIMUM (PHISHING-PROOF)  |
|   +--------------------------+  +--------------------------+  +-----------------------+ |
|   | SMS / Voice Call OTP     |  | TOTP App / Mobile Push   |  | FIDO2 / WebAuthn Keys | |
|   | - SIM Swapping attacks   |  | - AiTM Proxy Phishing    |  | - Domain-bound crypto | |
|   | - SS7 Telecom snooping   |  | - MFA Fatigue / Bombing  |  | - Origin validation   | |
|   | - NIST Deprecated        |  | - Mitigated by Number-Match | - Immune to Replay | |
|   +--------------------------+  +--------------------------+  +-----------------------+ |
+-----------------------------------------------------------------------------------------+

1. SMS & Voice OTP (Weakest): Transmitted unencrypted across public cellular networks. Highly susceptible to SIM swapping (socially engineering telecom carriers to redirect phone numbers), SS7 network interception, and malware on mobile devices.
2. Mobile Push Notifications & TOTP Authenticator Apps (Moderate):
   • MFA Fatigue (Push Bombing): Attackers repeatedly trigger push notifications until a frustrated user blindly taps "Approve." Mitigated by Number Matching (requiring the user to enter a two-digit code displayed on the login screen into the authenticator app).
   • Adversary-in-the-Middle (AiTM) Phishing: Reverse proxies (e.g., Evilginx) intercept session cookies and TOTP codes in real time.
3. FIDO2 / WebAuthn / Passkeys (Strongest - Phishing Resistant): Utilizes public-key cryptography (asymmetric key pairs). The hardware security key validates the exact cryptographic domain origin (e.g., login.microsoftonline.com or aws.amazon.com) during the challenge-response handshake. Even if a user visits a fraudulent lookalike phishing domain, the token refuses to sign the authentication challenge, providing complete immunity to AiTM phishing.

---

2. Privileged Access Management (PAM) & Privileged Identity Management (PIM)

Traditional IT environments assigned static, permanent administrative rights ("Standing Access") to engineers. In the cloud, permanent administrative accounts present an unacceptable blast radius if compromised.

+-----------------------------------------------------------------------------------------+
|                      JUST-IN-TIME (JIT) PRIVILEGE ELEVATION FLOW                        |
|                                                                                         |
|   [Standard Developer Identity] (Base state: Zero administrative permissions)            |
|                                 |                                                       |
|   1. Incident / Change Ticket   v                                                       |
|   Developer requests role elevation via Microsoft Entra PIM / Cloud PAM                |
|   - Specifies Business Justification & Incident Ticket ID                                |
|   - Requests duration (e.g., 2 Hours)                                                   |
|                                 |                                                       |
|   2. Verification & Approval    v                                                       |
|   - Enforces Step-Up MFA (FIDO2 Hardware Key)                                           |
|   - Automated Manager / On-Call Lead Approval Workflow                                  |
|                                 |                                                       |
|   3. Dynamic Activation         v                                                       |
|   [Role Activated: 'Cloud Infrastructure Administrator' (TTL: 2 Hours)]                 |
|   - Full Session Audit Recording & API Telemetry Logged to SIEM                         |
|                                 |                                                       |
|   4. Automated Expiration       v                                                       |
|   [Timer Expires (2:00:00)] ===> System revokes permissions automatically               |
+-----------------------------------------------------------------------------------------+

Privileged Identity Management (PIM) Mechanics

• Eligible vs. Active Roles: Users are designated as Eligible for administrative roles rather than permanently Active. Eligible assignments confer zero standing privileges until explicitly activated.
• Just-In-Time (JIT) Elevation: Role activation is strictly time-bound (e.g., 1 to 8 hours), requiring business justification, ticket correlation, manager approval, and step-up MFA.
• Access Reviews: Automated periodic governance campaigns where resource owners must re-certify whether employees still require eligible role assignments, automatically revoking dormant access.

Emergency Access ("Break-Glass") Accounts

Cloud architectures require emergency break-glass accounts to remediate catastrophic identity lockouts (e.g., when a misconfigured Conditional Access policy blocks all standard admins or external IdP federation fails):

• Configuration: Cloud-native accounts created directly in the cloud directory (e.g., .onmicrosoft.com root global admins) excluded from federation and standard Conditional Access policies.
• Storage: Complex credentials split into multiple physical parts stored in separate fireproof corporate safes under dual-custody access.
• Monitoring: Monitored by high-priority automated alerts (AWS CloudWatch/EventBridge, Azure Monitor Log Analytics) that immediately notify the security operations center (SOC) whenever a break-glass account is used.

---

3. Conditional Access & Context-Aware Security

Conditional Access is an intelligent policy engine that evaluates real-time contextual signals before granting, restricting, or blocking access to cloud resources.

+-----------------------------------------------------------------------------------------+
|                        CONDITIONAL ACCESS EVALUATION ENGINE                             |
|                                                                                         |
|   CONTEXTUAL SIGNALS                                ENFORCEMENT DECISIONS               |
|   +------------------------------------+            +---------------------------------+ |
|   | User / Group: Dev, HR, Contractor  |            | [BLOCK ACCESS]                  | |
|   | IP Location: Trusted Office / Tor  | ===[POLICY]===> | (Tor exit node, high risk)  | |
|   | Device State: Intune Compliant?    |   ENGINE   |                                 | |
|   | Client App: Browser vs Legacy Mail |            | [REQUIRE STEP-UP MFA]           | |
|   | Risk Score: 'Impossible Travel'    |            | (Unfamiliar IP, medium risk)    | |
|   +------------------------------------+            |                                 | |
|                                                     | [REQUIRE COMPLIANT DEVICE]      | |
|                                                     | (Corporate laptop required)     | |
|                                                     +---------------------------------+ |
+-----------------------------------------------------------------------------------------+

Key Contextual Signals:

• Device Compliance: Verified through Mobile Device Management (MDM / Intune / Jamf) ensuring the endpoint has BitLocker/FileVault encryption enabled, active endpoint detection and response (EDR), and updated OS patches.
• Named / Trusted Locations: Whitelisted public egress IP ranges belonging to corporate headquarters or secure software-defined perimeters (SD-WAN).
• Risk-Based Intelligence (Impossible Travel): Automated detection of mathematically impossible geographic movements (e.g., a user authenticates from London at 09:00 AM and from Singapore at 09:30 AM), indicating compromised session tokens or credential stuffing.

---

4. Machine Identities: Managed Identities vs. Static Access Keys

Non-human identities—such as virtual machines, microservices, container pods, and serverless functions—require access to back-end cloud databases, storage buckets, and key vaults. Storing static API keys in application code or configuration files represents an immense security vulnerability.

+-----------------------------------------------------------------------------------------+
|                      STATIC ACCESS KEYS VS. MANAGED IDENTITIES                          |
|                                                                                         |
|   STATIC CREDENTIALS (Vulnerable / Anti-Pattern)                                         |
|   +---------------------------------------------------------------------------------+   |
|   | App Config file -> contains 'AWS_ACCESS_KEY_ID=AKIA...' & SecretKey             |   |
|   | Vulnerabilities: Hardcoded in Git repo, embedded in Docker images, never rotated|   |
|   +---------------------------------------------------------------------------------+   |
|                                                                                         |
|   NATIVE CLOUD MANAGED IDENTITIES (Zero-Trust Standard)                                 |
|   +---------------------------------------------------------------------------------+   |
|   | [Cloud Virtual Machine / Kubernetes Pod]                                        |   |
|   |       |                                                                         |   |
|   |       v (Queries Local Link-Local Address: 169.254.169.254 IMDSv2)              |   |
|   | [Instance Metadata Service (IMDS)]                                              |   |
|   |       |                                                                         |   |
|   |       v (Fetches Short-Lived STS Token: Rotated Automatically Every 6 Hours)    |   |
|   | [Backend Cloud Database / Object Storage / Vault]                               |   |
|   +---------------------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------------------+

Multi-Cloud Managed Identity Implementations:

1. AWS IAM Roles for EC2 & EKS IRSA:
   • EC2 Instance Profiles: Attaches an IAM role to an EC2 instance. Applications running on the host query the Instance Metadata Service Version 2 (IMDSv2) via the link-local IP 169.254.169.254 to obtain temporary STS credentials.
   • EKS IAM Roles for Service Accounts (IRSA): Injects OIDC JSON Web Tokens into individual Kubernetes pods, mapping each microservice pod to an isolated IAM role.
2. Azure Managed Identities:
   • System-Assigned Managed Identity: Tied directly to the lifecycle of a specific Azure resource (e.g., VM, App Service). Created and destroyed automatically with the resource.
   • User-Assigned Managed Identity: Created as a standalone Azure resource that can be assigned to multiple VMs or container instances.
3. Google Cloud Platform (GCP) Workload Identity:
   • Associates Kubernetes service accounts in Google Kubernetes Engine (GKE) directly with Google Service Accounts, eliminating static private key JSON downloads.

---

5. CompTIA Cloud+ Exam Traps & Real-World Pitfalls

[!CAUTION] Exam Trap: IMDSv1 vs. IMDSv2 and SSRF Vulnerabilities Legacy Instance Metadata Service Version 1 (IMDSv1) uses simple HTTP GET requests vulnerable to Server-Side Request Forgery (SSRF) attacks, allowing web application exploits to extract temporary host credentials. IMDSv2 mitigates SSRF by requiring a session-oriented PUT request with an X-aws-ec2-metadata-token-ttl-seconds header before requesting metadata.

[!WARNING] Exam Trap: Exclude Break-Glass Accounts from Conditional Access If an administrator creates a Conditional Access policy requiring MFA from a corporate-managed device and mistakenly enforces it on all directory accounts, a lost mobile device or MDM sync failure could lock out every administrator. Always explicitly exclude emergency break-glass accounts from automated conditional access policies.