Trois rôles ne font pas un modèle d'accès.
Beaucoup de plateformes de delivery proposent une liste courte — administrateur, opérateur, lecture seule — et tout ce qui n'y entre pas devient administrateur. L'équipe certificats obtient les pleins droits sur le trafic parce que les certificats vivent sous le trafic. L'intégration de supervision obtient un jeton administrateur parce qu'il n'existe pas de jeton plus restreint.
Le résultat est prévisible : un audit demande qui aurait pu effectuer une modification, et la réponse honnête est « presque toute la console ». La séparation des tâches existe sur l'organigramme, pas dans le produit.
La seconde défaillance est la dérive entre surfaces. Un droit appliqué dans l'interface mais pas dans l'API n'est pas un droit, c'est une suggestion.
Notre approche
Le rôle nomme la fonction. La portée nomme le rayon d'impact. Les deux s'appliquent sur chaque surface.
Seize rôles, pas trois
Les rôles suivent les lignes selon lesquelles les équipes se répartissent réellement : trafic, WAF, réseau, GTM, certificats et supervision, avec une variante gestionnaire et une variante utilisateur là où la distinction compte, plus des rôles en lecture seule et frontend seul pour ceux qui doivent voir sans toucher.
La portée par-dessus le rôle
Le rôle dit quel type d'objet un utilisateur peut toucher. La portée dit lesquels : adresses frontend autorisées, réseaux backend autorisés, vServices et vDevices assignés. Deux Traffic Managers administrent deux parcs distincts sur un même équipement sans voir les services de l'autre.
Un modèle de droits pour l'interface, la CLI et l'API
La CLI interactive applique le même rôle que l'interface — un Network Manager voit les commandes réseau et rien d'autre — et l'accès REST est filtré par domaine et par champ selon le même modèle. Les jetons d'API persistants sont liés au rôle.
Chaque surface écrit dans la même piste d'audit
Une modification faite par clic, par commande ou par appel d'API atterrit dans une seule piste d'audit avec des diffs avant/après sans perte. La question de l'auditeur — qui a modifié cela, depuis où, et à quoi cela ressemblait-il avant — n'a qu'une réponse.
Fonctionnalités
Ce que couvre le modèle de rôles et ce qui s'y ajoute.
Seize rôles d'administration nommés
L'ensemble complet : Admin (super-admin) · Traffic Manager · Traffic User · Traffic+WAF Manager · Traffic+WAF User · WAF Manager · WAF User · WAF Read-Only · Network Manager · Network User · GTM User · Certificate Manager · Monitor User · Read-Only User · Frontend User · Client. Les variantes gestionnaire et utilisateur séparent le droit de configurer du droit d'exploiter.
Portée réseau — adresses frontend et réseaux backend autorisés
La portée d'un utilisateur est bornée par adresse, pas seulement par type d'objet, de sorte qu'une erreur reste dans le segment dont il a la charge.
Portée ressources — vServices et vDevices assignés
Les utilisateurs se voient assigner les services publiés et les vDevices qui leur appartiennent. Le reste n'est pas en lecture seule pour eux : il est invisible.
Droits sur les certificats : gestion et sélection séparées
Le droit de choisir un certificat pour un service et celui de gérer la bibliothèque de certificats sont distincts. Une équipe applicative publie sur le bon certificat sans pouvoir exporter, remplacer ou supprimer la clé.
Accès shell en interrupteur par utilisateur
CLI par SSH et CLI dans le navigateur sont deux interrupteurs indépendants, chacun avec un nombre maximal de sessions. Un opérateur peut recevoir la console navigateur sans qu'un compte SSH existe pour lui.
Quotas par utilisateur : bande passante, CPU et connexions
Un rôle peut porter un plafond de ressources en plus d'un jeu de droits, pour qu'un administrateur de locataire ne consomme pas l'équipement au nom de tous.
Autorisation d'API au niveau des champs
L'accès REST est filtré par domaine et par champ avec le même modèle que l'interface. Un rôle qui ne voit pas un champ dans la console ne le lit pas non plus via l'API.
Administrateurs adossés à l'annuaire, authentification forte
Les administrateurs s'authentifient sur des comptes locaux, LDAP et Active Directory, RADIUS ou TACACS+ avec accounting. Double facteur par code à usage unique SMS ou e-mail, jetons de récupération et connexion par certificat client mTLS émis par la PKI interne de TR7.
Les préférences de poste suivent l'utilisateur
Langue, thème et disposition de la barre d'en-tête sont stockés par utilisateur : la console est identique quel que soit le nœud du cluster.
Profondeur opérationnelle
Les éléments qui décident si un modèle d'accès survit à un audit.
Une séparation des tâches exprimée, non promise
WAF, trafic, réseau, GTM et certificats étant des familles de rôles distinctes, l'exigence classique des secteurs régulés — celui qui change la politique de sécurité n'est pas celui qui change le chemin du trafic — devient une configuration plutôt qu'une procédure à mémoriser.
Des rôles en lecture seule réellement en lecture seule
Read-Only User, WAF Read-Only et Monitor User existent pour que les auditeurs, le NOC et les tableaux de bord n'aient pas besoin d'un rôle capable de modifier quoi que ce soit.
Rôles Frontend User et Client pour l'accès délégué
Frontend User couvre les personnes qui travaillent avec les services publiés sans toucher à la plateforme. Client couvre le cas du client cloud, où le compte appartient au consommateur du service et non à son exploitant.
Défense contre la force brute sur le plan de gestion
La complexité des mots de passe est imposée et les échecs de connexion sont limités par des budgets expirants par IP et par IP+nom d'utilisateur, appuyés par le CAPTCHA intégré.
Services de gestion liés et délimités individuellement
HTTPS, SSH, FTP et SNMP se lient chacun à une adresse et un port choisis et portent leur propre liste de réseaux autorisés, leur certificat et leurs versions TLS minimale et maximale. La console peut exiger TLS 1.3 pendant qu'une intégration plus ancienne atteint un autre service en TLS 1.2.
Comptes de transfert de fichiers à usage dédié
Le transfert de fichiers ne passe pas par un compte partagé. Des comptes distincts couvrent l'export des journaux, la sauvegarde de configuration, la livraison hors ligne de la base de réputation IP et les paquets de mise à jour hors ligne, chacun ne voyant que son répertoire.
Quand l'utiliser
Séparation des tâches en environnement régulé
Une banque doit distinguer le responsable de la politique WAF et celui du trafic, et le prouver. WAF Manager et Traffic Manager sont des rôles distincts avec des pistes d'audit distinctes : la preuve est un rapport, pas un entretien.
Équipes applicatives qui publient leurs propres services
Chaque équipe reçoit un rôle Traffic User délimité à ses propres vServices et réseaux backend. Elles publient et exploitent sans demande de changement et sans atteindre les services des autres.
Jetons de pipeline et de supervision
Un pipeline CI/CD reçoit un jeton d'API persistant lié à un rôle étroit, un système de supervision un jeton lié à Monitor User. Aucun ne porte de droits administrateur : une fuite reste un incident borné.
Une équipe certificats qui ne possède pas le trafic
Certificate Manager administre la bibliothèque de clés et les renouvellements ; les équipes applicatives y puisent. La clé privée n'a jamais à être remise à l'équipe qui publie le service.
Questions fréquentes
Combien de rôles d'administration TR7 fournit-il ?
La CLI est-elle soumise aux mêmes droits que l'interface ?
Deux administrateurs peuvent-ils gérer des services différents sur un même équipement sans se voir ?
Un jeton d'API peut-il être limité à moins qu'un administrateur ?
Le RBAC nécessite-t-il une licence supplémentaire ?
Comment les administrateurs s'authentifient-ils ?
Seize rôles, délimités par utilisateur, appliqués sur chaque surface
Passons en revue le modèle de rôles au regard de vos propres exigences de séparation des tâches.