EN

TYPE D’ACTION · DONNER UN ACCÈS

Des accès accordés en secondes et révisés au trimestre.

Attributions de rôles, appartenances à des groupes, clés d’API, élévations temporaires. Les agents de soutien et les scripts de provisionnement accordent déjà des accès ; la révision censée attraper un mauvais accès arrive souvent longtemps après son usage.

Qui l’exécute aujourd’hui : Agents de soutien TI, scripts de provisionnement, flux d’identité, comptes de service d’intégration continue.

Les règles qui l’encadrent d’habitude

  • Un demandeur ne peut pas accorder un rôle supérieur au sien
  • Un accès élevé est limité dans le temps
  • Les rôles sensibles exigent un approbateur autre que le demandeur
  • Certaines conditions doivent tenir au moment de la demande, comme l’authentification multifacteur ou une plage réseau

Des formes de règles typiques, pas une affirmation sur une organisation en particulier. Un pilote part des vôtres.

Où ce genre de règles casse

  1. Les accès s’enchaînent.

    Un rôle autorisé à accorder des rôles peut en donner un qui en accorde davantage. Chaque étape respecte la politique ; l’état final, non.

  2. Le temporaire s’additionne.

    Des accès limités dans le temps, renouvelés bout à bout, deviennent un accès permanent, alors que chaque renouvellement passe seul.

Ce que fait la barrière

  1. 01

    Vérifie chaque demande contre la politique prouvée avant son exécution. Ce qui échoue n’atteint jamais le système.

  2. 02

    Refuse quand une fenêtre ou une population dont dépend la règle manque ou ne concorde pas, au lieu de deviner.

  3. 03

    Scelle chaque décision, autorisée ou bloquée, pour qu’elle soit revérifiable sans nous.

Ce que vous pouvez vérifier aujourd’hui

SUR DEMANDE

Des bancs de décision scellés sur des politiques d’accès publiées mot pour mot par AWS et Microsoft, décidées selon notre lecture de leur sémantique documentée. Les moteurs d’AWS et d’Azure n’ont pas été exécutés. Montrés en appel, non publiés.

DÉMARRER UN PILOTE