Attribute-Based Access Control (ABAC)

The PDP is the brain of the ABAC architecture. It is the logical component that evaluates access requests against applicable policies and attribute data to issue an authorization decision (Permit or Deny).

• Evaluation Engine: Computes the intersection of user attributes, resource attributes, and environmental conditions against a policy set.
• Separation of Concerns: Decouples the authorization logic from the application code, allowing security teams to update rules without redeploying apps.
• Contextual Verdicts: Returns not just a boolean, but often enriched claims or obligations (e.g., 'Permit, but mask PII fields').

The PEP is the gatekeeper that intercepts a user's request to a protected resource. It acts as the physical or logical barrier that enforces the decision made by the PDP.

• Interception Layer: Usually implemented as an API gateway, reverse proxy, or interceptor in application code.
• Duty of Enforcement: If the PDP returns 'Deny', the PEP blocks the request and returns a 403 Forbidden status.
• Data Passing: Responsible for forwarding the subject's credentials and the requested resource identifier to the PDP for evaluation.

Policy-as-Code is the practice of writing and managing authorization rules (like ABAC policies) as version-controlled code, rather than clicking through a UI. It brings software development best practices to security operations.

• Declarative Logic: Policies are expressed in a high-level language (e.g., Rego for OPA, CEDAR for AWS) that defines the desired state.
• CI/CD Integration: Policies are unit-tested and automatically deployed through GitOps pipelines, preventing configuration drift.
• Auditability: Every change to an access rule is tracked via commit history, providing a clear audit trail for compliance.

Zero Trust is a security model that assumes breach and verifies every request as if it originates from an open network. ABAC is the ideal policy engine for ZTA because it moves beyond static network location to dynamic, risk-based attributes.

• 'Never Trust, Always Verify': Access is not granted based on network perimeter (e.g., corporate VPN) but on real-time identity and device posture.
• Attribute-Centric: ZTA relies on ABAC to evaluate user identity, device health, geolocation, and data sensitivity simultaneously.
• Micro-Segmentation: ABAC policies enable fine-grained lateral movement protection between workloads, not just at the perimeter.

Security Trimming is the application of ABAC principles to search and retrieval systems. It ensures that a user's query only returns results they are explicitly authorized to see, preventing information leakage via the search index.

• Pre-Retrieval Filtering: Applies a restrictive ACL or attribute filter before the semantic search executes, ensuring unauthorized vectors are never scored.
• Post-Retrieval Filtering: Executes the query broadly, then strips out unauthorized results. This is simpler but can lead to empty result pages if the top-k results are all unauthorized.
• RAG Authorization: Critical for AI pipelines to ensure a language model doesn't summarize a document the user can't access.

The Principle of Least Privilege mandates that a subject be granted only the minimum necessary access rights to perform a specific task. ABAC enables true dynamic least privilege by scoping access to the exact moment of need.

• Just-In-Time (JIT) Access: ABAC can evaluate temporal attributes to grant access for a 1-hour window, then automatically revoke it.
• Session-Specific Permissions: Unlike static RBAC roles, ABAC can grant 'read-only' access to a specific record based on a current case assignment.
• Risk Reduction: Minimizes the blast radius of compromised credentials by ensuring stolen accounts have no standing, broad privileges.