Offre

Décider au moment où l’agent tente réellement l’action

Un rôle ou un scope peut donner davantage de capacités que la mission réelle d’un agent. Lorsque cette différence devient critique, une politique externalisée évalue l’action précise avant qu’elle atteigne la ressource.

Quand nous appeler

  • Le rôle technique imposé par une application permet davantage d’actions que la mission réelle de l’agent.
  • Un agent agit pour plusieurs utilisateurs avec un seul compte de service.
  • Une décision dépend de la destination, du volume ou de la sensibilité des données, pas seulement du rôle.
  • Les règles d’accès sont dispersées dans le code de plusieurs outils.

Rôle technique large et politique runtime

Le compte de l’agent possède le rôle ADMIN : lire, exporter, modifier, supprimer et administrer sont techniquement possibles. Une politique runtime, placée sur le chemin, ne laisse passer que l’export ; les autres actions sont bloquées.

Un rôle applicatif peut être plus large que la mission de l’agent.

Ce que nous modélisons

  • Subject
  • Agent
  • Human requester
  • Action
  • Resource
  • Parameters
  • Destination
  • Context
  • Data sensitivity
  • Relationship

Démarche

  1. 01Identifier les actions sensibles
  2. 02Identifier le point d’enforcement
  3. 03Déterminer les attributs nécessaires
  4. 04Formaliser les politiques
  5. 05Définir les sources de contexte
  6. 06Tester Permit / Deny
  7. 07Intégrer le PDP
  8. 08Vérifier l’enforcement
  9. 09Organiser les logs et la corrélation

Architectures possibles

Runtime PEP / PDP
La décision est demandée à chaque action, sur le chemin de l’appel.
Token enrichment
Les claims du token sont calculés par politique à l’émission.
Policy-derived provisioning
Les permissions sont calculées puis provisionnées par un orchestrateur.

Le choix dépend de la cible : ce que l’application peut interroger, ce que le fournisseur d’identité peut enrichir, ce qu’un orchestrateur peut provisionner.

Ce que la mission produit

Selon le périmètre, la mission peut produire notamment :

  • Inventaire des actions sensibles
  • Modèle d’attributs
  • Politiques formalisées et testées
  • Emplacement des points d’enforcement
  • Intégration du moteur de décision
  • Journalisation corrélée des décisions
Limitation
Une politique ne protège une action que si le chemin d’exécution impose le passage par le point d’enforcement. L’autorisation ne protège pas non plus les processus, fichiers et réseau du workload.

Technologies mobilisables

Axiomatics est la technologie principalement mobilisée : décision externalisée (PDP), contexte récupéré via des PIP, politiques administrées séparément, trois modes d’intégration documentés.[1] Détail : fonctionnement d’Axiomatics.

Le problème en profondeur : limiter l’action réelle d’un agent.

Contenus associés

Sources

  1. [1]

    Documentation éditeurDocument non public

    Axiomatics

    Axiomatics - Authorization Platform

    Présentation détaillée de la plateforme d'autorisation, de son architecture, de ses composants, de ses modèles de politique et de ses capacités d'intégration.

Partir d’une action sensible

Nous pouvons partir d’un agent existant ou d’un projet en conception pour identifier les ressources, actions et contrôles concernés.

Étudier une décision d’autorisation