Documentation

Rôles et multi-tenant

Une même console peut servir plusieurs organisations sans qu'elles ne se voient jamais. Dans VIGIL-MESH, l'unité d'isolation est le workspace : il est le tenant. Toute ressource — réseau, device, règle, invitation, journal d'audit — est rattachée à une organisation et ne franchit pas cette frontière : il n'y a pas d'accès croisé entre tenants. À l'intérieur d'un workspace, les responsabilités sont découpées par des rôles séparés, de l'exploitant d'infrastructure à l'auditeur en lecture seule, pour que chacun n'ait que ce dont il a besoin.

Le workspace = le tenant

Le multi-tenant n'est pas une option ajoutée après coup : c'est la ligne de séparation autour de laquelle tout est organisé. Le workspace est le tenant. Chaque ressource gérée dans la console appartient à une organisation et une seule, et cette appartenance détermine qui peut la voir et l'administrer. Deux clients hébergés sur la même plateforme évoluent dans des espaces disjoints, sans fenêtre de l'un vers l'autre.

Concrètement, l'absence d'accès croisé signifie qu'un membre d'une organisation ne peut ni lister, ni lire, ni modifier les ressources d'une autre. Les réseaux, les devices enrôlés, les politiques d'accès, les invitations en attente, le journal d'audit : tout est scoppé à l'organisation. Il n'existe pas de vue « globale » qui traverserait les tenants par commodité — la commodité s'arrête là où commence l'isolation.

Chaque ressource est rattachée à une organisation : son tenant d'origine est la frontière de sa visibilité.
Pas d'accès croisé : un membre d'un workspace ne voit pas et n'agit pas sur les ressources d'un autre.
Le journal d'audit lui-même est scoppé : chaque organisation tient sa propre chaîne, décrite dans /docs/console-audit.
L'isolation est structurelle, pas déclarative : elle ne dépend pas du fait que chacun « reste chez soi », mais du cloisonnement du modèle.

Les rôles

À l'intérieur d'un workspace, tout le monde n'a pas à tout faire. VIGIL-MESH sépare les responsabilités en rôles distincts, pour appliquer le moindre privilège : on donne à chacun la capacité d'agir sur ce qui le concerne, et rien de plus. Trois rôles structurent l'usage courant de la console.

Rôle	Portée	Ce qu'il peut faire
Exploitant d'infrastructure	La plateforme et les organisations qu'il héberge	Opère l'infrastructure sous-jacente et l'hébergement des tenants, sans se substituer à l'administration interne du réseau d'un client.
Administrateur réseau d'un client	Le réseau de sa propre organisation	Gère les devices, les règles d'accès et les membres de son organisation : enrôlements, révocations, publication des politiques.
Auditeur en lecture seule	Les ressources de son organisation, en consultation	Consulte l'état du réseau et le journal d'audit sans pouvoir modifier quoi que ce soit : un droit de regard, pas d'action.

La séparation entre l'exploitant d'infrastructure et l'administrateur réseau du client est importante : opérer la plateforme n'est pas la même chose qu'administrer le réseau d'un tenant. De même, l'auditeur en lecture seule matérialise le principe selon lequel on peut avoir besoin de tout voir sans avoir le droit de rien changer — c'est le rôle qui accompagne naturellement le journal d'audit de /docs/console-audit.

Bonnes pratiques d'attribution

Attribuer les rôles n'est pas un geste anodin : c'est là que se décide, en pratique, l'écart entre un accès sain et un accès trop large. Quelques principes gardent le modèle lisible dans la durée.

1
Partir du besoin, pas du confortDonnez le rôle le plus étroit qui permet à la personne de faire son travail. Un droit d'administration « au cas où » est un droit de trop.
2
Distinguer voir et agirQuand quelqu'un a besoin de contrôler sans intervenir — conformité, supervision, tiers de confiance — l'auditeur en lecture seule est le bon choix.
3
Nommer les accèsDes identités individuelles plutôt que des comptes partagés : c'est ce qui rend le journal d'audit capable d'attribuer chaque action à une personne.
4
Revoir régulièrementLes besoins évoluent ; les rôles hérités d'un ancien projet ne devraient pas survivre à leur raison d'être. Passez les accès en revue périodiquement.

Le découpage exploitant / administrateur client / auditeur prend tout son sens dans les scénarios à plusieurs parties — un opérateur qui héberge le réseau de plusieurs clients, chacun administrant le sien, avec un tiers en observation. Ce cas d'usage et son articulation avec le modèle Zero Trust sont développés dans /docs/cas-entreprise.

Lire ensuiteWebhooks →

In English

In VIGIL-MESH the workspace is the tenant. Every resource — network, device, rule, invitation, audit log — is scoped to a single organization, and there is no cross-tenant access: even the most powerful role in one workspace has no reach into another.

Inside a workspace, responsibilities are split into separate roles: an infrastructure operator, a customer's network administrator, and a read-only auditor. Grant the narrowest role that fits the need, use named identities so actions can be attributed, and review access over time.