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

    Évalue chaque demande au regard de la politique avant son exécution. Ce qu’elle bloque ou refuse 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, PROCEED, BLOCK ou REFUSE, 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. Sur 57 politiques IAM d’exemple publiées par AWS, 185 garanties : 160 tiennent sous Z3 et sous cvc5, 5 sous cvc5 seulement, 16 tombent, 3 tombent sous cvc5 seulement sans témoin, 1 reste inconnue. 11 constats réels, chacun confirmé dans le simulateur de politiques IAM d’AWS : dans 8, la prose de la page et sa politique se contredisent ; 3 viennent de notre lecture. Les services AWS et Azure eux-mêmes n’ont pas été sollicités. Montrés en appel, non publiés.