Yannick LeblancChaque système est livré avec une identité qui peut tout faire. Elle réalise la configuration initiale, rétablit l’environnement après une panne et apporte les changements qu’aucun rôle plus étroit ne peut atteindre. Dans beaucoup d’organisations, c’est aussi le compte avec lequel quelqu’un se connecte un mardi après-midi pour ajouter un utilisateur.
Ce sont deux fonctions différentes. Conserver un compte capable de reconstruire l’environnement lorsque l’administration normale échoue, c’est une capacité de reprise. Donner aux professionnels des TI assez d’accès pour leur travail quotidien, c’est une capacité opérationnelle. Les fusionner dans un seul rôle accorde bien plus d’accès que le travail quotidien n’en exige.
Réservé à la reprise et aux changements exceptionnels
L’identité la plus puissante devrait être réservée à la reprise et aux changements exceptionnels. Une panne du fournisseur d’identité, un compte d’administrateur perdu, un changement de configuration qu’aucun autre rôle ne peut terminer : voilà les moments pour lesquels elle existe. Tout le reste est du travail ordinaire, et le travail ordinaire a des rôles plus étroits. L’accès d’urgence, lorsqu’une organisation le maintient, s’accompagne de règles de stockage, d’alertes et d’un calendrier de tests.
Un compte de bris de glace reste inutilisé jusqu’à ce que l’administration normale soit indisponible.
Pourquoi les rôles sans restriction ne devraient pas servir tous les jours
Un rôle de propriétaire ou de niveau root dépasse en général largement l’administration courante. Selon le système, il peut réécrire les paramètres d’authentification, créer d’autres propriétaires, lire tout le contenu stocké, modifier les contrôles d’audit ou rétablir l’environnement après la panne du fournisseur d’identité.
Des conséquences plus étendues en cas d’erreur
Un changement accidentel fait avec un rôle sans restriction touche tout l’environnement. Un administrateur dont le rôle a une portée restreinte, et qui gère les utilisateurs ou la configuration, n’atteint pas en plus le contenu sensible et les paramètres de reprise.
Des conséquences plus étendues en cas de compromission
Chaque utilisation d’une identité privilégiée est une occasion de plus de voir sa session, ses identifiants ou ses facteurs d’authentification pris. L’utiliser moins souvent produit moins d’occasions.
Une redevabilité plus faible
Quand un seul rôle large couvre chaque tâche administrative, personne ne peut dire pourquoi une personne donnée détenait une capacité donnée. Une attribution à portée restreinte répond à cela d’elle-même, parce que la capacité est arrivée attachée à une responsabilité énoncée.
Un accès au contenu qui n’est pas nécessaire
Administrer de l’information n’exige pas de la lire. Un professionnel des TI peut créer des coffres, gérer les utilisateurs, attribuer des licences et configurer les paramètres sans ouvrir un seul identifiant, document ou session qui y est stocké.
Le principe de moindre privilège s’applique aussi aux administrateurs
Le moindre privilège est souvent présenté comme une règle pour les utilisateurs standards, ce qui transforme discrètement le privilège en titre de poste. Le privilège s’attache au travail. Le même administrateur lit ses courriels, ouvre des billets et navigue sur le Web entre les changements de configuration, et rien de cela n’exige une identité de niveau propriétaire.
Le contrôle AC-6 (moindre privilège) de NIST SP 800-53 exige que les organisations n’accordent que les accès nécessaires pour accomplir les tâches assignées. Le même contrôle restreint les comptes privilégiés à un personnel ou à des rôles définis, et demande des comptes non privilégiés lorsque le travail n’exige pas d’élévation.
Cela vaut aussi à l’intérieur du palier administratif. Une personne qui travaille avec un rôle à portée restreinte reste un administrateur. Ce qui rétrécit, c’est l’autorité attachée à la session, pas le poste.
Les trois fonctions d’un modèle administratif
L’autorité administrative se divise en trois fonctions. Une personne peut en détenir plus d’une.
Propriété et reprise
La propriété est une autorité sans restriction sur l’environnement : configuration initiale, reprise et changements exceptionnels qu’aucun rôle plus étroit ne peut terminer. Rare par conception. Chaque utilisation devrait être visible après coup et explicable à quiconque le demande.
Le bris de glace est cette fonction avec des règles opérationnelles : des facteurs d’authentification stockés, une alerte lorsque le compte est utilisé, et un calendrier de tests pour que la reprise fonctionne le jour où elle compte.
Administration au quotidien
L’administration au quotidien fait fonctionner l’environnement sans hériter de chaque capacité du propriétaire : utilisateurs, groupes, licences, modèles, intégrations et contenants qui détiennent les ressources. Lire ce que ces contenants renferment est une autorisation distincte, et elle suit la fonction plutôt que le contenant.
Administration spécialisée
L’administration spécialisée répartit le reste selon la responsabilité et la portée : administration des utilisateurs, audit, consultation des journaux, propriété des coffres. Chaque attribution lie une capacité à une fonction, et les groupes maintiennent ce lien aligné sur l’appartenance à l’équipe et les processus d’annuaire, plutôt que sur des exceptions individuelles.
Les rôles privilégiés s’accumulent, et les attributions directes se chevauchent avec les attributions de groupe. Une revue utile demande quel rôle une personne détient, ce qu’il peut faire, où il s’applique, comment il a été attribué, et si la fonction derrière existe encore. « Qui est administrateur ? » ne va pas aussi loin.
Appliquer le modèle dans la plateforme Devolutions
La plateforme Devolutions applique cette séparation par des attributions de rôles dans Devolutions Server 2026.3.
Un Workspace owner conserve un accès sans restriction, à l’image de l’ancien Administrator, et relève de la propriété, de la reprise et du bris de glace. Un Workspace administrator gère le Workspace sans recevoir automatiquement l’accès au contenu des coffres, ce qui couvre le travail quotidien. Auditor, Workspace log viewer, Users administrator et les rôles au niveau du coffre portent les fonctions spécialisées.
Les détails de mise en œuvre, y compris la façon dont les rôles apparaissent dans l’interface, sont présentés dans Gérer les accès avec les nouveaux rôles de Devolutions Server 2026.3. Vous pouvez télécharger la dernière version ici.
Conclusion
Une organisation conserve une identité sans restriction parce que la reprise finit par en exiger une. L’administration quotidienne, non. Les rôles à portée restreinte couvrent le travail ordinaire et laissent le compte propriétaire là où il est le plus utile : inactif, surveillé et prêt.