Attribute-Based Access Control (ABAC)

Role-Based Access Control (RBAC) is a widely adopted authorization model where permissions are assigned to roles, and users are assigned to those roles. It simplifies management in large organizations by grouping permissions.

• Key Difference from ABAC: RBAC grants access based on a user's static role membership (e.g., 'admin', 'viewer'), while ABAC uses dynamic attributes (user department, resource sensitivity, time of day).
• Common Use: RBAC is effective for enforcing broad, stable job functions but can struggle with complex, context-sensitive policies where ABAC excels.

A Policy Decision Point (PDP) is the core logic engine in a policy-based access control system. It evaluates incoming access requests against a set of authorization policies to render an Allow or Deny decision.

• In ABAC Systems: The PDP is responsible for evaluating the attributes of the subject, resource, action, and environment against ABAC policy rules written in languages like XACML or Rego.
• Architecture: The PDP receives a query from a Policy Enforcement Point (PEP), makes the decision, and returns it for enforcement. It is the 'brain' of the authorization process.

Policy-as-Code is the practice of defining security, compliance, and operational policies using machine-readable definition files. These policies are treated as code: version-controlled, tested, reviewed, and deployed through automated pipelines.

• Connection to ABAC: ABAC policies, with their complex logic, are prime candidates for implementation as code. Tools like Open Policy Agent (OPA) allow policies to be written in Rego, stored in Git, and validated through unit and integration tests.
• Benefits: Ensures consistency, enables audit trails for policy changes, and allows for rapid, safe iteration of authorization rules in agile environments.

Context-Aware Authorization is a dynamic access control paradigm where authorization decisions incorporate real-time, situational factors beyond static user identity. It is a super-set or key characteristic of advanced ABAC implementations.

• Contextual Factors: Includes environmental attributes like geolocation, IP address, time of request, device security posture (e.g., is disk encrypted?), and behavioral patterns.
• Example Policy: 'A user with the analyst role may read a financial_report only if the request originates from the corporate_network AND during business_hours.' This combines RBAC-like roles with rich ABAC context.

Zero-Trust Network Access (ZTNA) is a security framework that mandates strict identity verification and context-based authorization for every access request to an application or service, regardless of whether the request originates inside or outside the corporate network.

• Relationship to ABAC: ZTNA implementations heavily rely on ABAC principles to make granular, context-aware access decisions. Before granting a user session to an application, the ZTNA controller evaluates user identity, device health, location, and other attributes against policy.
• Core Principle: 'Never trust, always verify.' ABAC provides the granular, attribute-driven 'verify' mechanism that makes Zero-Trust operational beyond simple network perimeters.