Autorisation : qui peut faire quoi, et comment vous le prouvez

Control Center répond à deux questions d’autorisation, et elles sont véritablement différentes. « Cette personne peut-elle appeler cette opération ? » porte sur les personnes, les rôles et les dépôts. « Cet agent peut-il causer cet effet ? » porte sur les actions, les arguments et le rayon d’impact — cette question relève des Garde-fous.

Cette page traite de la première question, ainsi que du registre que les deux laissent derrière elles.

Un seul point de décision

Toute décision d’autorisation du côté humain passe par une seule fonction :

can(principal, permission, resource) → allow | deny + why

Une permission s’écrit <domain>:<tier> — tickets:write, members:administer, repos:read. Le catalogue est dérivé, et non écrit à la main : il est calculé à partir de la surface d’opérations elle-même (le préfixe du nom de l’opération donne le domaine, le rôle minimal que celle-ci impose déjà donne le palier), de sorte que les quelque 550 opérations portent une permission sans que personne n’en tape une seule.

Cette dérivation est la propriété qui vaut la peine d’être protégée. Elle signifie qu’une NOUVELLE opération est soumise à un contrôle par défaut — le mode de défaillance d’un modèle annoté à la main, c’est que quelqu’un oublie, et ce qu’il oublie, c’est le contrôle. Un test de cliquet verrouille l’ensemble de domaines résultant, de sorte qu’ajouter une opération sous un nouveau préfixe est une décision de nomenclature qu’une personne prend plutôt qu’un accident.

Les quatre paliers correspondent exactement aux rôles intégrés :

Palier	Rôle minimal	Exemple
read	Invité	tickets:read
write	Membre	tickets:write
administer	Admin	members:administer
own	Propriétaire	workspace:own

Rôles

Cinq rôles intégrés — Propriétaire, Admin, Membre, Lecteur, Invité — sont des préréglages appliqués à ce catalogue. La propriété correspond à un seul siège par espace de travail, cédé explicitement avec Transférer la propriété (un propriétaire qui part est autrement impossible à retirer : le déprovisionnement SCIM refuse tout propriétaire d’espace de travail — transférez d’abord).

Les rôles personnalisés sont soustractifs. Un rôle personnalisé nomme un préréglage de base (admin, member, viewer ou guest — jamais owner) et un ensemble de permissions RETIRÉES de celui-ci : « admin, mais ne peut pas gérer les membres ». Il ne peut jamais accorder plus que sa base, et c’est ce qui les rend sûrs à introduire dans une installation existante : toute vérification existante demeure une borne supérieure valide. Les membres les détiennent sous la forme custom:<id>, et un client trop ancien pour comprendre cette valeur retombe sur Invité plutôt que de deviner.

Sous les rôles se trouvent les autorisations par dépôt (none / read / review / write) : l’appartenance à un espace de travail ne confère jamais silencieusement plus de privilèges que l’hébergeur de code. Toutes les surfaces qui exposent du code les vérifient — y compris celles qui atteignent le code de biais, comme un terminal ou une session d’éditeur ouverte sur l’arbre de travail d’un espace.

Autorité du serveur

Certaines opérations ne concernent pas du tout un espace de travail : les paramètres de toute l’installation, la configuration SSO, les identifiants des fournisseurs, la gestion des modèles, les sauvegardes de toute l’installation. Celles-ci déclarent une autorité du serveur et sont refusées à tout le monde, sauf à l’opérateur de l’installation (le propriétaire du serveur enregistré). Il existe délibérément une seule identité d’opérateur et une seule définition de celle-ci.

Le journal d’audit

Chaque décision d’autorisation — autorisée ou refusée — est ajoutée à un journal d’audit par espace de travail, chaîné par hachage.

Un journal qui ne consigne que les refus répond à « qu’avons-nous bloqué ? », mais pas à « qu’a réellement fait cet agent, et qui l’a autorisé ? », la question par laquelle commence l’analyse d’un incident. Chaque entrée consigne donc toute la chaîne d’attribution : le principal qui agit, la personne pour le compte de qui il agit, la délégation par laquelle il est arrivé, l’action et ses arguments (sous forme d’empreinte), la décision, et la règle qui l’a déterminée.

Les entrées sont chaînées : le hachage de chacune couvre celui de la précédente, de sorte que modifier, supprimer ou réordonner une ligne brise tous les hachages qui suivent. Vérifier la chaîne recalcule l’ensemble et nomme le premier maillon qui ne tient pas. Un journal d’audit que vous ne pouvez pas vérifier est un journal ; celui que vous pouvez recalculer est une preuve.

Deux conséquences qu’il vaut la peine de connaître :

• La table d’audit est exemptée de la purge selon l’âge. Une chaîne de hachage ne peut pas être tronquée par le milieu. La rétention se fait par exportation puis troncature, et la troncature laisse un point de contrôle portant le hachage terminal du segment supprimé, de sorte que ce qui survit se vérifie encore jusqu’au début.
• Il se trouve à côté de la chronologie d’activité, et non au-dessus. La chronologie montre ce que les gens ont fait ; le journal montre ce qui a été autorisé et refusé. Un même identifiant de corrélation permet de lire un appel dans les deux.

Il s’exporte en JSON délimité par des sauts de ligne et peut être transmis en flux vers un SIEM (Splunk, Elastic, Sentinel — un point de terminaison HTTP avec un jeton porteur). La transmission en flux est offerte au mieux, par choix de conception : un SIEM hors service ne doit jamais bloquer l’appel d’outil d’un agent, et la copie durable et vérifiable se trouve sur disque dans tous les cas.

Sessions

Une installation peut définir une durée de vie maximale de session et un délai d’inactivité. Les deux sont appliqués au contrôle des identifiants d’appareil par lequel passe chaque canal authentifié — une limite de session qu’un client pourrait ignorer répond à un questionnaire, pas à un attaquant. Une installation peut aussi exiger le SSO, ce qui désactive l’appairage manuel des nouveaux appareils (avec une protection contre le verrouillage : elle refuse tant qu’aucune connexion SSO fonctionnelle n’existe).

Ce que ce n’est pas

• Ce ne sont pas des ACL par objet. Il n’existe délibérément aucune permission par ticket ni par message. La séparation au niveau des dépôts est ce que les équipes demandent réellement, et elle existe ; le partage par objet est une surface combinatoire dont la demande n’est pas démontrée ici.
• Ce n’est pas un moteur de politiques que vous configurez dans un DSL. Le vocabulaire est fermé à dessein, de sorte que toute la politique peut être représentée, expliquée et énumérée.
• Ce n’est appliqué nulle part ailleurs que sur le serveur. Les vérifications côté client n’existent que pour éviter d’offrir un contrôle qui sera refusé. La décision faisant autorité est toujours celle du serveur.