ABAC (Attribute-Based Access Control)

ABAC (Attribute-Based Access Control) est un modèle d'autorisation où les décisions d'accès sont basées sur les attributs combinés du subject (user), resource, action, et environment, plutôt que sur des rôles statiques (RBAC). Permet policies dynamiques fines impossibles avec RBAC pur. NIST formalize ABAC 2014.

Attributs typiques :
(1) **Subject (user)** — id, role, department, clearance, manager, location, employment_status.
(2) **Resource** — type, owner, classification, project, sensitivity, creation_date.
(3) **Action** — read, write, delete, share, download.
(4) **Environment** — time, location, device_type, network_zone, mfa_status, risk_score.

Policies exemple :
- "Allow read on document if user.department == document.department"
- "Allow modify if user.role == 'editor' AND time between 9am-6pm AND mfa == true"
- "Deny delete on records older than 90 days unless user.role == 'archivist'"
- "Allow access if user.location == document.location_restriction"

Forces vs RBAC :
(1) **Fine-grained** — express conditions impossible RBAC ("only own records", "only during business hours", "only from corporate network").
(2) **Dynamic context** — adapt based on environment (suspicious login from new country → require step-up auth).
(3) **Less role explosion** — instead 1000s of roles (each combo), few policies.
(4) **Decoupled from org structure** — changes in org not require role rewrites.

Faiblesses :
(1) **Complexity** — policies harder reason about than "X has role Y".
(2) **Performance** — evaluating multiple attributes per request can be slower (caching, optimization needed).
(3) **Audit complexity** — "who has access to X?" harder to answer (depends on attribute combinations).
(4) **Testing** — combinatorial explosion test cases.
(5) **Tooling maturity** — RBAC mature in all systems, ABAC requires policy engines.

Standards et engines :
(1) **XACML** (eXtensible Access Control Markup Language) — XML-based, OASIS standard. Mature but verbose.
(2) **OPA/Rego** — modern ABAC engine.
(3) **Cedar** — AWS Cedar policies.
(4) **AWS IAM** — ABAC via tags policies (`PrincipalTag/Department`).
(5) **Azure** — ABAC role assignments avec conditions (preview/GA selon resource).
(6) **PERMIT.io, Auth0 FGA, Oso, SpiceDB, OpenFGA** — modern authorization platforms supporting ABAC.

Hybrid : la plupart real-world systems combine RBAC + ABAC — RBAC for coarse grouping, ABAC for fine conditions. "User in 'editor' role can edit documents IF document.owner == user.id". Best of both worlds. Compétences SC-300, AZ-500, CISSP.