Décision et enforcement doivent former un même chemin de contrôle

Policy

Définit la règle : qui peut faire quoi, sur quelle ressource, dans quel contexte.

Decision

Évalue une requête précise au regard de la politique et renvoie Permit ou Deny.

Enforcement

Applique Permit ou Deny sur le flux, avant la ressource.

Resource

Ne reçoit l’action que si le chemin l’a laissée passer.

L’architecture Zero Trust du NIST distingue les fonctions de décision (Policy Decision Point) et d’application (Policy Enforcement Point), ce dernier contrôlant la connexion à la ressource protégée.^[1] Le guide ABAC du NIST décrit la même séparation entre PDP, qui rend la décision, et PEP, qui l’applique.^[2]

Si l’agent dispose d’un second chemin vers la même ressource, par exemple un token direct sur l’API ou un outil générique capable d’exécuter une requête HTTP, et que ce chemin porte des privilèges suffisants, la politique du premier chemin ne garantit plus que l’action est bloquée. C’est une conclusion d’architecture : la politique est correcte, mais elle n’est pas obligatoire.

OWASP recommande d’implémenter l’autorisation dans les systèmes en aval et d’appliquer une médiation complète, afin que chaque requête soit validée au regard des politiques de sécurité.^[3]

01

Placer l’enforcement avant la ressource

Sur le passage obligé : passerelle, serveur d’outils ou service cible, pas dans le raisonnement de l’agent.

02

Inventorier les chemins parallèles

Tokens directs, outils génériques, accès réseau sortant : chacun peut contourner le point de contrôle.

03

Conserver la preuve de la décision

Journaliser Permit ou Deny avec la requête évaluée et l’action effectivement exécutée.

Toutes les lectures à faible risque ne justifient pas un appel externe à un moteur de décision. L’architecture doit tenir compte de la latence, de la disponibilité et de la criticité de chaque action, et définir le comportement attendu si le point de décision ne répond pas.