ABAC: A Simple Guide

TL;DR

Attribute-Based Access Control (ABAC) lets you control access to resources based on who’s asking (user attributes), what they want to do (action attributes), the thing they want to access (resource attributes), and the environment around them (context attributes). It’s more flexible than traditional role-based access control.

What is ABAC?

ABAC moves away from ‘who you are’ (roles) to ‘what is happening’. Instead of saying “Managers can read reports”, it says “Users with a department attribute of Finance AND requesting access during working hours CAN read reports with a confidentiality level of Internal”.

Why use ABAC?

• Granular Control: Fine-grained permissions.
• Dynamic Policies: Rules adapt to changing conditions.
• Scalability: Easier to manage complex access needs than role-based systems.
• Flexibility: Supports diverse applications and data types.

Setting up ABAC – Step by Step

1. Define Attributes: Identify the key attributes you’ll use.
   • User Attributes: Department, job title, location, security clearance.
   • Resource Attributes: Data classification (Confidential, Public), owner, creation date.
   • Action Attributes: Read, write, delete, execute.
   • Context Attributes: Time of day, IP address, network location.
2. Choose a Policy Engine: This is the core component that evaluates policies.
   • Examples include Open Policy Agent (OPA), Axiomatics Policy Server, or cloud provider solutions like AWS IAM Access Analyzer.
3. Write Policies: Express access rules using a policy language (often Rego for OPA).

   package example
   
   # Define the policy.
   policy "access_control" {
     input {
       user_department = string
       resource_classification = string
       action = string
     }
   
     if user_department == "Finance" AND resource_classification == "Confidential" AND action == "read" {
       allow
     } else {
       deny
     }
   }

4. Integrate with Applications: Connect your applications to the policy engine.
   • When a user tries to access a resource, the application sends attribute information to the policy engine.
   • The policy engine evaluates the policies and returns an allow or deny decision.
5. Test Thoroughly: Verify that your policies work as expected.
   • Create test cases covering different attribute combinations.
   • Monitor access logs for unexpected behavior.

Example Scenario

Imagine a document management system.

• User: Alice, Department = Marketing
• Resource: Sales Report, Classification = Internal
• Action: Read
• Context: Time = 9:00 AM (during working hours)

A policy might state: “Users in the Marketing department CAN read Internal documents during working hours”. The policy engine would allow Alice to access the Sales Report.

Key Considerations for cyber security

• Policy Complexity: Keep policies simple and easy to understand.
• Attribute Management: Ensure attributes are accurate and up-to-date.
• Auditing: Log all access decisions for accountability.
• Regular Review: Policies should be reviewed regularly to ensure they remain relevant and effective.