6.1 Identity & Access Management (IAM) Architecture

Identity & Access Management (IAM) Architecture

Quick Summary: Identity and Access Management (IAM) establishes the security boundary for modern enterprise systems by ensuring that authenticated entities obtain only the precise permissions required to perform their authorized duties. For CPA auditors evaluating IT General Controls (ITGCs) and SOC engagements, IAM encompasses the entire user identity lifecycle, multi-factor authentication (MFA) architectures, access control models (RBAC, ABAC, MAC, DAC), privileged access safeguards, and periodic entitlement recertifications.

---

1. The Core IAM Framework: Identification, Authentication, Authorization, and Accounting (AAA)

The security posture of any financial system or cloud computing environment rests upon the foundational tenets known as the AAA Framework (often expanded to treat Identification as a discrete preliminary phase). Auditors must clearly differentiate among these mechanisms when evaluating internal controls:

1. Identification: The assertion of an identity by a subject (e.g., entering a username, presenting an employee badge number, or submitting an API client identifier). Identification alone carries no proof of veracity—it merely claims who the entity purports to be.
2. Authentication: The cryptographic or mechanical verification of the claimed identity. The system challenges the subject to validate their claim by presenting credentials (e.g., verifying a password hash, prompting for a time-based one-time passcode, or scanning a biometric fingerprint). Once successfully authenticated, the entity is issued an authenticated session identifier.
3. Authorization: The determination and enforcement of operational privileges granted to the authenticated subject. Authorization defines what data, transactions, files, or execution paths the identity is permitted to access (e.g., granting read-only access to general ledger tables while restricting journal entry posting privileges to authorized senior accountants).
4. Accounting (and Auditing): The continuous tracking, timestamping, and immutable logging of all subject actions within the system. Accounting produces an unbroken audit trail establishing non-repudiation—guaranteeing that a specific identity executed a specific transaction or configuration change at an exact point in time.

---

2. User Identity Lifecycle Management

A robust IAM program governs the full lifecycle of enterprise identities from initial provisioning to ultimate deactivation. Control deficiencies across any lifecycle phase expose organizations to unauthorized data disclosure, data tampering, and regulatory compliance failure.

Onboarding (Provisioning)

When an employee or contractor joins an organization, the Human Resources Information System (HRIS) acts as the authoritative identity source.

• Automated Provisioning: Leading organizations utilize System for Cross-domain Identity Management (SCIM) connectors to automatically generate directory accounts when HR marks an employee as active.
• Birthright Access vs. Elevated Roles: Birthright access refers to baseline entitlements granted to all personnel (e.g., corporate email, self-service HR portal, corporate intranet). Any role-specific or elevated application access (e.g., SAP ERP, Salesforce CRM, production database access) requires formal, documented manager approval and application owner sign-off prior to provisioning.

Role Modifications and Transfers (Privilege Creep)

When employees change departments—such as an accounts payable clerk transferring to the internal audit team—organizations face the severe risk of privilege creep (also termed permissions accumulation).

• If IT provisions the new role's permissions without explicitly stripping the legacy permissions, the employee accumulates excessive, conflicting privileges over time.
• This accumulation frequently creates toxic Segregation of Duties (SoD) combinations (e.g., retaining the ability to create vendors while gaining the ability to approve disbursements).
• Audit Control: The IAM system must enforce delta provisioning—automatically revoking all prior departmental entitlements upon transfer, requiring full reauthorization of required access by the receiving business unit manager.

Offboarding and Deprovisioning (Termination)

Timely revocation of access upon employee resignation or involuntary termination is among the most heavily scrutinized ITGC controls in financial statement and SOC audits.

• Deprovisioning SLAs: Enterprise security policies must mandate definitive Service Level Agreements (SLAs). Involuntary terminations require immediate revocation (coordinated with HR during the termination interview). Voluntary departures must be fully deprovisioned within 24 hours or by the end of the business day.
• Orphan Accounts: An orphan account is an active account in an IT system that no longer corresponds to a valid, employed individual. Attackers actively seek out orphan accounts because they rarely generate login anomalies. Automated reconciliation between HR active employee rosters and Active Directory / cloud IdP directories is mandatory to identify and disable orphan accounts.
• Disabling vs. Deleting: Best practice dictates that accounts should be disabled (suspending login and revoking session tokens) rather than immediately deleted. Immediate deletion can corrupt historical transaction audit trails, break scheduled batch jobs, or orphan encryption keys associated with the identity.

---

3. Multi-Factor Authentication (MFA): Factors, Architectures, and Vulnerabilities

Multi-Factor Authentication (MFA) requires a user to present two or more distinct credential categories before granting access. MFA mitigates the catastrophic risks of password reuse, brute-force cracking, and credential harvesting.

The Three Classic Authentication Factors

To qualify as true multi-factor authentication, the credentials presented must originate from at least two different categories:

1. Knowledge Factor (Something You Know): Passwords, passphrases, PINs, or pre-configured security question answers.
2. Possession Factor (Something You Have): Physical hardware tokens (e.g., YubiKey, RSA SecurID fobs), smart cards, software-based authenticator apps generating Time-Based One-Time Passwords (TOTP), or mobile devices receiving push notifications.
3. Inherence Factor (Something You Are): Biometric identifiers, including fingerprints, facial recognition geometry, retinal scans, or behavioral biometrics (keystroke dynamics, gait analysis).

[!IMPORTANT] The "Two-Step" vs. "Multi-Factor" Exam Trap: Presenting a password and a memorized PIN does not constitute multi-factor authentication. Both credentials belong to the knowledge factor category. This configuration is merely two-step verification. If an attacker compromises the user's password file or keylogs their input, both credentials can be stolen simultaneously. True MFA requires crossing categorical boundaries (e.g., a password [knowledge] plus a hardware security key [possession]).

Modern Contextual / Adaptive Factors

Enterprise zero-trust architectures augment the three classic factors with contextual attributes:

• Location Factor (Somewhere You Are): GPS geolocation, corporate IP address subnet, or geofencing.
• Time / Context Factor: Time-of-day restrictions or device health posture (e.g., checking for endpoint disk encryption, patched OS, and active EDR agents).

Managing the Credentials Themselves

Beyond factor categories, the blueprint names specific identification and authentication technologies a candidate should be able to select among — password management, single sign-on, multi-factor authentication, personal identification number (PIN) management, digital signatures, smart cards and biometrics.

PIN management deserves separate treatment because its control set differs from password management. A PIN is short and drawn from a tiny character space, so its security comes from the surrounding controls rather than from the secret itself:

• Never a standalone factor for remote access. A PIN is paired with a physical possession factor — a smart card, a hardware token, or an enrolled device — so that a guessed PIN alone is useless.
• Retry lockout. Because a four- or six-digit PIN is trivially brute-forced, the card or device enforces a hard lockout after a small number of failed attempts, and the lockout is enforced on the device rather than by the server.
• Never transmitted or stored in the clear. In payment environments the PIN is encrypted at the point of entry inside a tamper-resistant PIN entry device and travels as an encrypted PIN block; the clear PIN never exists outside the secure module.
• Weak-PIN rejection and no derivation from personal data. Sequences, repeats and dates of birth are rejected at enrollment.
• Separate delivery. A new PIN is delivered through a channel separate from the card or device it unlocks, so intercepting one does not yield both.

Digital signatures and smart cards bind authentication to a private key held in hardware, which is what makes them phishing-resistant; biometrics bind it to the person but cannot be reissued if compromised, which is why a biometric is used to unlock a local key rather than transmitted as a credential.

Implementing an Authorization Model: The Enforcement Controls

Selecting an access control model is only half the blueprint task; the other half is the controls used to implement it:

• Access control lists (ACLs) attached to a file, directory, database object, network device or cloud resource, enumerating which subjects hold which permissions on that object.
• Account restrictions that bound an otherwise valid credential — time-of-day and day-of-week windows, source IP or geography restrictions, concurrent session limits, account expiration dates for contractors, and mandatory password or certificate rotation.
• Physical barriers that enforce the model in the physical world, because logical access controls are meaningless if a person can reach the hardware: perimeter fencing, locked and badge-controlled doors, mantraps and turnstiles that defeat tailgating, server cages and locking racks within a shared colocation floor, visitor escort requirements, and secured media storage. A data center that grants any badge holder access to every cage has implemented role-based access logically and abandoned it physically.

Comparative Vulnerability of MFA Implementations

Not all MFA implementations provide equal protection. Attackers have developed sophisticated tactics targeting legacy second-factor mechanisms:

---

4. Access Control Models Comparison Matrix

Access control models define how operating systems, directories, and applications grant or restrict user permissions. Auditors must assess whether the chosen model matches the organization's regulatory obligations and operational complexity.

Discretionary Access Control (DAC)

In DAC, the data owner (the creator or designated custodian of a file or resource) possesses complete discretion over who is granted access and what permissions are assigned.

• Implementation: Traditional Unix file permissions (chmod 777) and Windows New Technology File System (NTFS) access permissions.
• Audit Risk: DAC is inherently unscalable and vulnerable to decentralized mismanagement. Users frequently grant excessive read/write permissions to unauthorized colleagues without central oversight or logging.

Mandatory Access Control (MAC)

In MAC, access decisions are enforced by the operating system kernel based on security clearance levels assigned to users and classification labels attached to data objects (e.g., Top Secret, Secret, Confidential, Unclassified).

• Implementation: Multi-Level Security (MLS) environments, SELinux, and military/intelligence systems implementing models such as Bell-LaPadula (confidentiality: "no read up, no write down") and Biba (integrity: "no read down, no write up").
• Audit Risk: Highly rigid and administratively costly. Changes require formal reclassification and central administrator intervention.

Role-Based Access Control (RBAC)

In RBAC, permissions are assigned to predefined organizational roles based on job functions, and users are subsequently assigned to one or more roles. Users never receive permissions directly.

• Implementation: Enterprise Resource Planning (ERP) systems like SAP and Oracle Financials; Active Directory security groups.
• Audit Value: Aligns directly with the principle of least privilege and facilitates automated Segregation of Duties (SoD) enforcement. When an employee leaves a role, revoking role membership instantly revokes all associated permissions across thousands of objects.

Attribute-Based Access Control (ABAC)

ABAC is a next-generation dynamic access control model governed by standards such as eXtensible Access Control Markup Language (XACML). Access decisions are evaluated at runtime by evaluating four attribute sets:

1. Subject Attributes: User role, department, clearance level, citizenship, employment type.
2. Resource / Object Attributes: Data classification, owner, document type, creation date.
3. Action Attributes: Read, write, update, delete, approve, export, print.
4. Environment / Context Attributes: Current time of day, request origin IP, device compliance status, threat level.

• Audit Value: Provides unmatched granularity and enables Zero Trust dynamic policies (e.g., "Allow payroll managers to view employee salaries ONLY during business hours from an enterprise-managed, encrypted laptop connected to the corporate VPN").

Enterprise Access Control Matrix

---

5. Privileged Access Management (PAM)

Privileged accounts—such as local administrator, domain administrator, database schema owner (sa, root), and cloud root tenant accounts—possess elevated capabilities to alter system configurations, disable security logs, create unmonitored backdoors, and access unencrypted financial data. Mismanaged privileged accounts represent the primary vector for enterprise ransomware deployment and advanced persistent threats (APTs).

Core Technical Architecture of PAM

A comprehensive PAM solution introduces an intermediary security boundary between administrators and critical target systems:

• Credential Vaulting: High-privilege administrative passwords are encrypted inside a tamper-resistant digital vault (e.g., CyberArk, HashiCorp Vault, BeyondTrust). Administrators do not know the actual passwords to production servers.
• Just-in-Time (JIT) Elevation: Rather than granting static, 24/7 administrative rights, administrators request temporary access for an approved maintenance window. Entitlements automatically expire upon task completion.
• Session Brokering and Recording: The PAM gateway brokers the RDP or SSH connection to the target server. The gateway records complete video sessions and indexes keystroke logs. If an administrator enters an unauthorized command (e.g., attempting to export a customer database), the PAM system can terminate the session in real time.
• Automated Password Rotation: Immediately upon session checkout completion (or after a fixed time limit, such as 4 hours), the PAM system automatically resets the password on the target system to a random, 64-character string.

Break-Glass (Emergency Access) Procedures

When a catastrophic outage occurs and normal identity systems or SSO directories are offline, organizations must retain break-glass accounts (also called emergency firecall accounts):

1. Dual Custody Storage: Break-glass credentials must be secured under dual custody (e.g., two halves of a passphrase stored in separate physical safes, or requiring dual authorization in the PAM console).
2. Immediate Alerting: Any invocation of a break-glass account must immediately trigger high-priority alerts to the Chief Information Security Officer (CISO) and Internal Audit.
3. Retrospective Review: Management must conduct a mandatory, documented post-incident review reconciling every command executed under the break-glass identity against the incident timeline.

---

6. Federated Identity and Single Sign-On (SSO) Protocols

Modern enterprise ecosystems span multi-cloud environments (AWS, Azure, GCP) and hundreds of Software-as-a-Service (SaaS) applications. Federated identity frameworks decouple identity authentication from individual service providers.

Core Roles in Identity Federation

• Identity Provider (IdP): The centralized authoritative system that authenticates users and issues digitally signed security tokens (e.g., Okta, Microsoft Entra ID, Ping Identity).
• Service Provider (SP) / Relying Party (RP): The third-party application or resource (e.g., Salesforce, Workday, ServiceNow) that trusts the IdP and grants access based on validated tokens without ever seeing user passwords.

Enterprise Federation Protocols

[!TIP] Exam Distinction (OAuth vs. OIDC): OAuth 2.0 is purely an authorization framework designed for delegated resource access (it issues access tokens). OAuth alone does not authenticate the user. OpenID Connect (OIDC) adds an identity and authentication layer directly on top of OAuth 2.0 by introducing the standardized ID Token (a cryptographically signed JWT containing user profile claims).

---

7. Auditor Testing Procedures: User Access Reviews and Recertifications

For CPA auditors conducting SOC 1, SOC 2, or Sarbanes-Oxley (SOX) Section 404 evaluations, testing logical access ITGCs centers on the Periodic User Access Review (UAR). The objective is to verify that user access rights are periodically reviewed and validated by management to prevent unauthorized access and enforce least privilege.

Audit Procedure Walkthrough for User Access Reviews

1. Obtain and Validate Population Completeness: The auditor must obtain a direct system-generated report of all active user accounts (including employees, contractors, service accounts, and administrators) for the target in-scope application. The auditor must test report completeness by reconciling the user list to database tables or directory records.
2. Evaluate Review Cadence and Thresholds: Security policy must define review frequencies: quarterly for privileged, administrative, and financially significant systems; annually or semi-annually for standard business applications.
3. Assess Reviewer Competence and Objectivity: The access review must be performed by the business process owner or data asset owner who understands the operational responsibilities of the individuals. An IT helpdesk technician or system administrator does not possess the business context to determine whether an accountant needs ledger posting authority. Auditors cite a control deficiency if reviews are conducted solely by IT administrators.
4. Sample Testing of Entitlement Revocation:
   • Identify users flagged for modification or revocation during the review.
   • Inspect ticketing system records to verify that unauthorized access was revoked within policy SLAs (e.g., within 5 business days of review completion).
   • Query current system permission tables to confirm the revoked entitlements were physically removed.
5. Testing Terminated Employees (Leavers Sample):
   • Select a statistical sample of employees terminated during the audit period from the master HR termination report.
   • Compare the official HR termination date against system access deactivation timestamps across all in-scope systems.
   • Verify that all logical access was revoked within established policy SLAs (e.g., same day / within 24 hours).

Common ITGC Audit Deficiencies in IAM

• Rubber-Stamping: Business managers blindly clicking "Approve All" on quarterly access reviews without reviewing individual entitlements or job duties.
• Orphan Service Accounts: Legacy service accounts configured with static domain admin rights whose original purpose, creators, and dependencies are undocumented.
• Segregation of Duties Conflicts: Users holding incompatible roles (e.g., vendor creation and payment approval) due to unmanaged lateral department transfers.