AWS Authorization Methods: RBAC, ABAC, and TBAC

This study guide focuses on designing and applying authorization mechanisms that align with business needs, specifically highlighting the differences between Role-Based (RBAC), Tag-Based (TBAC), and Attribute-Based (ABAC) access controls within the AWS ecosystem.

Learning Objectives

By the end of this guide, you should be able to:

Differentiate between RBAC, ABAC, and TBAC in the context of IAM and AWS Lake Formation.
Design IAM policies that implement the principle of least privilege using condition keys.
Implement fine-grained access control (row, column, and cell-level) using AWS Lake Formation tags.
Evaluate the best authorization method based on organizational scale and complexity.

Key Terms & Glossary

Principal: An entity (user, group, or role) that can make a request for an action or operation on an AWS resource.
RBAC (Role-Based Access Control): A traditional authorization model where permissions are assigned to roles, and users gain those permissions by assuming the role.
ABAC (Attribute-Based Access Control): An authorization strategy that defines permissions based on attributes (such as tags) of the user and the resource.
TBAC (Tag-Based Access Control): A specific implementation of ABAC where tags are the primary attributes used for evaluation; heavily utilized in AWS Lake Formation (LF-TBAC).
Least Privilege: The security practice of granting only the minimum permissions required to perform a task.
Permissions Boundary: An advanced feature where you use a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity.

The "Big Idea"

In early cloud adoption, RBAC was sufficient: "If you are a Data Engineer, you get the Data Engineer role." However, as organizations grow to thousands of users and resources, managing individual roles for every project becomes an administrative nightmare. The shift toward ABAC/TBAC allows permissions to scale dynamically. Instead of creating new roles, you simply tag resources and users (e.g., Project=Omega). If the tags match, access is granted. This moves security from static "gatekeeping" to dynamic "logic-based" enforcement.

Formula / Concept Box

Element	Purpose	Example
Effect	Allow or Deny	`"Effect": "Allow"`
Action	The specific API call	`"Action": ["s3:GetObject"]`
Resource	The ARN of the target	`"Resource": "arn:aws:s3:::my-bucket/*"`
Condition	Logic for when policy applies	`"StringEquals": {"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"}`

Hierarchical Outline

Role-Based Access Control (RBAC)
- Structure: Identity $\rightarrow$ Role $\rightarrow$ Policy.
- Use Case: Broad departmental access (e.g., all Finance users access Finance bucket).
- Limitation: "Role Explosion" — creating too many roles for specific projects.
Attribute-Based Access Control (ABAC)
- Structure: Policy logic checks for matching attributes on Principal and Resource.
- Benefits: High scalability; permissions update automatically when tags change.
- Mechanism: Uses Condition blocks in IAM JSON policies.
Tag-Based Access Control (TBAC) in Lake Formation
- LF-Tags: Specialized tags for the Data Catalog (Databases, Tables, Columns).
- Inheritance: Tags applied at the Database level can be inherited by Tables and Columns.
- Granularity: Enables row-level (PartiQL filters) and column-level (inclusion/exclusion) security.

Visual Anchors

Authorization Logic Flow

Loading Diagram...

Identity vs. Resource Policy Intersection

\begin{tikzpicture}[thick, fill opacity=0.5] \draw[fill=blue!30] (0,0) circle (1.5cm) node[below=1.6cm] {Identity-Based}; \draw[fill=red!30] (2,0) circle (1.5cm) node[below=1.6cm] {Resource-Based}; \node at (1,0) {\textbf{Access}}; \node at (-0.5,0) {IAM User/Role}; \node at (2.5,0) {S3/KMS/SQS}; \end{tikzpicture}

[!NOTE] For most services, an "Allow" in either an identity-based OR resource-based policy is sufficient. However, for KMS, you must have permission in the Key Policy specifically.

Definition-Example Pairs

Term: Role-Based Access Control (RBAC)
- Definition: Permissions based on job function.
- Example: An AdminRole allows iam:* actions. Any user assigned to this role can manage all IAM settings regardless of which project they belong to.
Term: Attribute-Based Access Control (ABAC)
- Definition: Permissions based on matching metadata between user and resource.
- Example: A developer with the tag Project=Blue can only start EC2 instances that also have the tag Project=Blue. If they move to Project=Red, their tag is updated, and they automatically gain access to Red resources without changing the policy.
Term: Row-Level Security
- Definition: Restricting access to specific records within a table based on data values.
- Example: In a Sales table, a Regional Manager for 'West' is restricted via Lake Formation to only see rows where region_id = 'West'.

Worked Examples

Example 1: Constructing an ABAC Policy

Scenario: Allow developers to manage S3 objects only if the object's Environment tag matches the user's Environment tag.

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::company-data-lake/*",
      "Condition": {
        "StringEquals": {
          "s3:ExistingObjectTag/Environment": "${aws:PrincipalTag/Environment}"
        }
      }
    }
  ]
}

Example 2: Lake Formation Cell-Level Security

Scenario: A data analyst needs access to the Customers table but must not see the SSN column, and can only see customers from the UK.

Step 1: In Lake Formation, create a Data Filter.
Step 2: Define the column filter (Exclude ssn).
Step 3: Define the row filter (PartiQL: country = 'UK').
Step 4: Grant the SELECT permission to the analyst's IAM role using this specific filter.

Checkpoint Questions

Which authorization method is most effective for preventing "Role Explosion" in large, fast-growing organizations?
In Lake Formation, if you apply an LF-Tag to a Database, what happens to the tables within that database by default?
True or False: A Permissions Boundary can be used to grant a user additional permissions they don't already have.
Which AWS service is specifically used to manage fine-grained access (rows/columns) for Amazon S3 data used by Athena and EMR?

Comparison Tables

Feature	RBAC	ABAC / TBAC
Primary Logic	User Role / Job Title	Tags / Attributes
Scalability	Low (requires more roles as it grows)	High (dynamic based on metadata)
Management	Centralized in IAM Roles	Decentralized via Tagging
Granularity	Coarse-grained	Fine-grained (down to rows/columns)
Best For	Internal Admin tasks	Multi-tenant Data Lakes

Muddy Points & Cross-Refs

Policy Evaluation Logic: Remember that an Explicit Deny always wins. Even if an ABAC policy allows access, a Service Control Policy (SCP) or Permissions Boundary that denies it will block the user.
Cross-Account Access: When accessing a resource in another account, you need permissions in both the identity-based policy (Account A) and the resource-based policy (Account B).
Lake Formation vs. IAM: Lake Formation doesn't replace IAM; it works with it. You still need IAM permissions to access the Lake Formation APIs, but Lake Formation handles the data-level permissions (the "Who can see this row?" logic).

[!TIP] For the Exam: If the question mentions "scale," "dynamic," or "frequent project changes," think ABAC. If it mentions "standardized job functions," think RBAC.