8.1 Identity & Access Management, RBAC & ABAC

Identity & Access Management, RBAC & ABAC

In modern cloud architecture, Identity and Access Management (IAM) serves as the primary security perimeter. Traditional network-centric security perimeters—such as border firewalls and demilitarized zones (DMZs)—are insufficient in distributed, multi-tenant cloud environments where workloads, serverless functions, and mobile workforces interact across global networks.

For the CompTIA Cloud+ (CV0-004) examination, cloud engineers must possess deep mastery of authorization models, declarative policy structures, access evaluation logic, and enterprise governance guardrails across Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).

---

1. Core Security Principles: Least Privilege, Separation of Duties & Zero Trust

Modern cloud security architecture relies on three interrelated governance principles to minimize the attack surface and mitigate lateral movement:

+-----------------------------------------------------------------------------------------+
|                           CORE CLOUD IAM SECURITY PILLARS                               |
|                                                                                         |
|   +--------------------------+  +--------------------------+  +-----------------------+ |
|   |   LEAST PRIVILEGE (PoLP) |  | SEPARATION OF DUTIES(SoD)|  |      ZERO TRUST       | |
|   | - Exact minimum actions  |  | - Divide critical tasks  |  | - Assume breach       | |
|   | - Specific resource ARNs |  | - Prevent single-person  |  | - Verify explicitly   | |
|   | - Ephemeral time-bounds  |  |   compromise or fraud    |  | - Continuous telemetry| |
|   | - No wildcard (*) admin  |  | - Dual-custody approvals |  | - Contextual identity | |
|   +--------------------------+  +--------------------------+  +-----------------------+ |
+-----------------------------------------------------------------------------------------+

Principle of Least Privilege (PoLP)

The Principle of Least Privilege (PoLP) dictates that every identity—whether a human administrator, an automated deployment pipeline, or an application service—must be granted only the absolute minimum set of permissions necessary to perform its specific job function, for only the duration required.

• Anti-Pattern: Assigning broad administrative privileges (such as AdministratorAccess or *:*) to simplify deployment or troubleshoot access issues.
• Best Practice: Authoring scoped policies specifying explicit API actions (e.g., s3:GetObject, ec2:DescribeInstances) and restricting them to specific resource Amazon Resource Names (ARNs) or Azure Resource IDs, rather than using wildcard asterisks (*).

Separation of Duties (SoD)

Separation of Duties (SoD) is an administrative control that prevents fraud, unauthorized system modifications, and catastrophic operational errors by requiring that critical, high-risk tasks be divided among multiple individuals or distinct roles.

• Infrastructure vs. Security Auditing: The cloud engineer who configures VPC routing and virtual machines must not possess the permissions to disable CloudTrail or delete centralized SIEM audit logs.
• Billing vs. Operational Administration: Financial analysts who require access to cost allocation reports and billing dashboards should have no rights to terminate compute instances or alter network firewalls.
• Dual-Control / Multi-Party Approval: High-impact operations—such as terminating production database clusters or modifying organization-wide root policies—require secondary administrative approval before execution.

Zero Trust Architecture (NIST SP 800-207)

The Zero Trust security model operates on the fundamental premise: "Never Trust, Always Verify." In a Zero Trust architecture, network locality does not confer trust. An internal IP address inside a Virtual Private Cloud (VPC) or corporate VPN is treated with the same skepticism as a request originating from the public internet.

Key Zero Trust tenets enforced through IAM include:

1. Explicit Verification: Every access request is authenticated and authorized using all available data points (identity, location, device health, service classification, and anomaly detection).
2. Least Privilege Access: Access is limited using Just-In-Time (JIT) and Just-Enough-Access (JEA) mechanisms, dynamic risk-based policies, and data protection.
3. Assume Breach: Workloads are micro-segmented, network communication is encrypted end-to-end, and telemetry is continuously analyzed to detect anomalies and limit blast radius.

---

2. Access Control Models: RBAC vs. ABAC

Cloud service providers implement two primary paradigms for granting and restricting access: Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC).

+-----------------------------------------------------------------------------------------+
|                        RBAC VS. ABAC ARCHITECTURAL COMPARISON                           |
|                                                                                         |
|   ROLE-BASED ACCESS CONTROL (RBAC)              ATTRIBUTE-BASED ACCESS CONTROL (ABAC)   |
|   +---------------------------------------+     +-------------------------------------+ |
|   | User: Alice                           |     | User: Bob (Tag: Dept=Dev, Env=Prod) | |
|   | Role: 'DatabaseAdministrator'         |     | Policy: Allow Action on Resource IF | |
|   | Permissions: RDS:* on all instances   |     | PrincipalTag:Dept == ResourceTag:Dept||
|   | Result: Static access across fleet    |     | Result: Dynamic access evaluated on | |
|   |                                       |     |         matching resource tags      | |
|   +---------------------------------------+     +-------------------------------------+ |
|   Scale Limitation: 'Role Explosion'            Scale Advantage: Scales with Metadata  |
+-----------------------------------------------------------------------------------------+

Role-Based Access Control (RBAC)

RBAC assigns permissions to predefined roles, and users or groups are subsequently assigned to those roles based on their organizational job responsibilities.

• Implementation: In Azure, RBAC utilizes built-in roles (e.g., Owner, Contributor, Reader, User Access Administrator) or custom roles scoped to a Management Group, Subscription, Resource Group, or individual Resource.
• Advantage: Simple to understand, straightforward to audit for small teams, and easy to map directly to corporate organizational charts.
• Disadvantage (Role Explosion): As organizations scale across dozens of projects, regions, and environments, administrators must create hundreds of specialized, rigid roles (e.g., DevOps-App1-US-East-Dev, DevOps-App1-EU-West-Prod, DevOps-App2-US-East-Dev), leading to severe management overhead and configuration drift.

Attribute-Based Access Control (ABAC)

ABAC evaluates access dynamically at request runtime by comparing attributes (tags) associated with the calling identity (principal), the target resource, the requested action, and the environment.

• Implementation: Policies use condition keys such as aws:PrincipalTag/Department and aws:ResourceTag/Department. If the tags match, access is granted automatically without modifying IAM role definitions.
• Advantage: Eliminates role explosion. When a developer provisions a new database tagged with Project=Apollo and Environment=Staging, any engineer with matching principal tags automatically gains access without IAM administrative intervention.
• Disadvantage: Requires rigorous, organization-wide tag governance and standardization. If an automated IaC script fails to tag a resource properly, or if tag keys contain case-sensitivity mismatches (Dept vs dept), access is denied by default.

Comparison: RBAC vs. ABAC

---

3. Cloud Policy Evaluation Logic & Precedence

Cloud policy evaluation engines (such as the AWS IAM Policy Evaluation Engine and Azure Policy Engine) follow a strict, deterministic sequence to determine whether an API request is authorized.

+-----------------------------------------------------------------------------------------+
|                         CLOUD POLICY EVALUATION LOGIC FLOW                              |
|                                                                                         |
|   1. INCOMING API REQUEST                                                               |
|      (Principal, Action, Target Resource, Context)                                      |
|                             |                                                           |
|                             v                                                           |
|   2. DEFAULT STATE: [IMPLICIT / DEFAULT DENY]                                           |
|                             |                                                           |
|                             v                                                           |
|   3. IS THERE AN EXPLICIT DENY IN ANY MATCHING POLICY?                                  |
|      (SCP, Permission Boundary, Identity Policy, Resource Policy)                       |
|         |                                 |                                             |
|        YES                                NO                                            |
|         |                                 |                                             |
|         v                                 v                                             |
|   [DENY ACCESS] <============= 4. IS THERE AN EXPLICIT ALLOW?                           |
|                                (Identity Policy OR Resource Policy)                     |
|                                   |                 |                                   |
|                                  YES                NO                                  |
|                                   |                 |                                   |
|                                   v                 v                                   |
|                        5. WITHIN BOUNDARIES?   [DENY ACCESS]                            |
|                           (SCP & Boundary)                                              |
|                              |         |                                                |
|                             YES        NO                                               |
|                              |         |                                                |
|                              v         v                                                |
|                        [ALLOW ACCESS] [DENY ACCESS]                                     |
+-----------------------------------------------------------------------------------------+

Deterministic Policy Evaluation Rules:

1. Default Deny (Implicit Deny): By default, all requests are denied. If no policy explicitly allows an action, the request is blocked.
2. Explicit Deny Overrides Everything: An explicit "Effect": "Deny" in any applicable policy (SCP, Identity Policy, Resource Policy, or Permission Boundary) immediately halts evaluation and denies the request, overriding any and all explicit allows.
3. Explicit Allow Grants Access (Subject to Boundaries): For an access request to succeed, at least one applicable policy must contain an explicit "Effect": "Allow", and the action must fall within the maximum permission envelope defined by applicable Permission Boundaries and Service Control Policies.

Example: ABAC Policy with Explicit Deny and Conditional Allow

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowActionsMatchingDepartmentTags",
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:RebootInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
        }
      }
    },
    {
      "Sid": "ExplicitlyDenyProductionWithoutMFA",
      "Effect": "Deny",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Environment": "prod"
        },
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Analysis: If a user attempts to stop a production EC2 instance (Environment=prod) without active Multi-Factor Authentication (MFA), the second statement triggers an Explicit Deny, immediately overriding the first statement's allow, even if the user's department tag matches.

---

4. Multi-Layered IAM Entities & Guardrails

+-----------------------------------------------------------------------------------------+
|                        MULTI-TIERED IAM AUTHORIZATION ENVELOPE                          |
|                                                                                         |
|   +---------------------------------------------------------------------------------+   |
|   | 1. SERVICE CONTROL POLICIES (SCPs) / AZURE MANAGEMENT GROUP POLICIES            |   |
|   |    Organization-wide maximum allowable guardrails (Filters all child accounts)  |   |
|   |   +-------------------------------------------------------------------------+   |   |
|   |   | 2. PERMISSION BOUNDARIES                                                |   |   |
|   |   |    Maximum permission ceiling applied to an individual User or Role     |   |   |
|   |   |   +-----------------------------------------------------------------+   |   |   |
|   |   |   | 3. IDENTITY-BASED POLICIES (IAM Policies / Roles)               |   |   |   |
|   |   |   |    Actual granted permissions (Must fall within 1 and 2)        |   |   |   |
|   |   |   +-----------------------------------------------------------------+   |   |   |
|   |   +-------------------------------------------------------------------------+   |   |
|   +---------------------------------------------------------------------------------+   |
|                                                                                         |
|   +---------------------------------------------------------------------------------+   |
|   | 4. RESOURCE-BASED POLICIES (S3 Bucket Policies, KMS Key Policies, Key Vaults)  |   |
|   |    Attached directly to the resource; can grant direct cross-account access     |   |
|   +---------------------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------------------+

IAM Entities

• Users: Represent distinct human identities or legacy service accounts. They possess long-lived credentials (console passwords, static API Access Key / Secret Key pairs). In enterprise environments, direct IAM user creation is deprecated in favor of federated identities.
• Groups: Administrative collections used to attach policies to multiple users simultaneously. Groups cannot be referenced as a Principal in policies.
• Roles: Identities that can be assumed by anyone who needs them, including users, cloud services (e.g., EC2, Lambda), or external federated identities. Roles issue temporary, short-lived cryptographic credentials via the cloud Security Token Service (STS).

Policy Types & Guardrails

1. Identity-Based Policies: JSON documents attached directly to users, groups, or roles defining what that identity can do.
2. Resource-Based Policies: JSON documents attached directly to a resource (e.g., Amazon S3 bucket policy, AWS KMS key policy, Azure Key Vault access policy). Unlike identity policies, resource-based policies explicitly define the Principal allowed to access that specific asset and can grant direct cross-account access without requiring the caller to assume an external role.
3. Permission Boundaries: An advanced IAM feature that uses a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM user or role. Even if a delegated administrator attempts to attach AdministratorAccess to a role, the role's effective permissions are capped at the boundary.
4. Service Control Policies (SCPs) / Azure Policy: Centralized governance rules applied at the organizational root, Organizational Unit (OU), or management group level. SCPs do not grant permissions; instead, they define guardrails (the maximum available permissions) for all accounts within that OU, restricting even the account root user.

---

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

[!CAUTION] Exam Trap: SCPs Do Not Grant Access An SCP containing "Effect": "Allow", "Action": "*", "Resource": "*" does NOT give any user administrator access. It merely permits child account administrators to delegate those actions using identity policies. Conversely, an SCP Deny statement blocks that action across all child accounts, regardless of what local IAM policies grant.

[!WARNING] Exam Trap: Identity Policy vs Resource Policy in Cross-Account Access When accessing a resource in Account B from Account A via Identity Policies, Account A's role must assume a role in Account B. However, if Account B attaches a Resource-Based Policy that names Account A's principal, the caller can access the resource directly without assuming a cross-account role.