Une clé distincte pour l’automatisation au lieu d’un mot de passe partagé : les jetons et leurs limites

Un script de sauvegarde, un outil de supervision ou une tâche de provisionnement doit se connecter au système. Le premier réflexe est de lui donner un mot de passe, et le plus souvent celui du compte le plus privilégié. C’est là que les ennuis commencent.

Ce que donne un mot de passe donné

Un mot de passe appartient à une personne. En le donnant à un script, vous lui avez donné tout ce que cette personne détient, et en clair dans un fichier de surcroît. Quand le mot de passe change, l’automatisation s’arrête, et quand la personne part, on change le mot de passe, mais on se souvient en général le jour même que l’automatisation en dépendait.

Ce que fait un jeton

Un jeton est une clé distincte rattachée à un compte. Il sépare trois choses : il se révoque seul, il peut porter sa propre date de fin, et comme il a un nom on sait quel travail l’utilise. Pouvoir couper une automatisation sans changer un mot de passe ressemble à un détail ; plus l’installation grandit, plus c’est ce qui sert le plus.

La vraie question : ce que le jeton a le droit de faire

Le réglage le plus important d’un jeton est de savoir s’il porte tel quel l’autorité du compte. Si oui, le jeton est aussi puissant que son propriétaire. Si ce propriétaire est pleinement privilégié, le jeton l’est aussi, et il réside désormais dans un fichier sur une machine.

Avec la séparation active, le jeton ne détient que l’autorité accordée au jeton lui-même. Vous donnez à un script de sauvegarde juste de quoi sauvegarder, et même si ce script est compromis, c’est tout ce qui part. Choisissez par défaut le côté étroit et n’ouvrez le large que délibérément.

Le secret n’est montré qu’une fois

À la création d’un jeton, vous voyez son secret une fois. Ce n’est pas un caprice d’interface : le système ne conserve pas cette valeur sous forme lisible. Si vous la perdez, vous en créez un nouveau, et c’est le bon comportement. Si elle pouvait être relue quelque part, ce serait cela, le vrai problème.

Où la clé finit par vivre

L’endroit où la clé se trouve compte davantage que sa force. Un script commité dans un dépôt, une configuration entrée dans un fichier de sauvegarde, une fenêtre prise dans une capture d’écran : tous transportent la clé. Décidez où elle sera écrite avant de la créer.

Date de fin et renouvellement

Une clé avec une date de fin cesse un jour d’être un risque, même si personne ne s’en occupe. Une clé sans date vit des années et survit en général à celui qui l’a créée. Mettez une note sur chaque clé : quel travail l’utilise, qui en répond.

Ce que fait Atlas

Atlas gère les jetons par compte. À la création, garder l’autorité du jeton séparée de celle du compte est activé par défaut : le côté étroit est le point de départ et l’élargir est un geste délibéré. Le secret est montré une fois au moment de la création et n’est pas conservé dans le panneau. Les jetons existants sont listés avec leur note et leur date de fin, si bien que la question « quelle automatisation se connecte avec quelle clé sur cette machine » se répond en lisant.