La gestion de services informatiques partagés implique une tension inhérente. En interne, vous devez avoir une vue d'ensemble de tout : chaque serveur, chaque incident, chaque changement et chaque coût pour tous vos clients. C'est la seule façon de planifier la capacité, de coordonner les interruptions et de gérer les opérations dans leur ensemble. Vos clients attendent justement le contraire. Ils veulent voir leurs propres données et rien d'autre. Ils ne veulent pas que quelqu'un d'autre consulte leur liste d'applications ou leurs coûts mensuels.
Lorsque cette tension est mal gérée, les gens en paient le prix. L'équipe d'opérations envoie des exports de feuilles de calcul aux clients parce qu'elle ne peut pas leur donner un accès direct. Les clients appellent pour demander le statut d'un incident qu'ils auraient pu vérifier eux-mêmes. Et à chaque audit, le responsable de la sécurité demande si un département pourrait un jour avoir accès aux données d'un autre département.
Pourquoi les approches habituelles sont insuffisantes
En pratique, nous voyons souvent deux extrêmes. Le premier est une instance séparée pour chaque client. Les données sont séparées, mais les opérations s'effritent. L'infrastructure partagée par plusieurs clients doit être enregistrée plusieurs fois, personne ne voit les dépendances entre les instances, et chaque mise à niveau doit être répétée.
Le deuxième extrême est une instance unique sans séparation réelle. Soit les clients n'ont pas accès à l'outil du tout, soit la séparation repose sur des filtres et des conventions de dénomination. Cela fonctionne jusqu'à la première erreur de configuration. Les filtres sont faciles à contourner, à oublier ou à copier incorrectement lors de la configuration d'un nouvel utilisateur.
Les deux voies se terminent au même endroit : les clients n'ont pas de vue directe et sécurisée de leurs services, et le fournisseur passe du temps à communiquer manuellement au lieu de gérer les opérations.
Comment penser à la séparation
La séparation des données des clients doit être une propriété de la plate-forme, et non une question de discipline d'administrateur. Quelques principes qui fonctionnent pour nous :
- Séparer au niveau des données, pas au niveau de l'écran. Si un utilisateur n'a pas la permission, les données ne sont jamais renvoyées. Cacher une colonne ne constitue pas une séparation.
- Faire de la portée une partie du rôle. Un rôle définit non seulement ce qu'un utilisateur peut faire, mais également sur quoi : tout, un client, une équipe ou un seul élément.
- Inclure les coûts dans le même modèle. Les données financières sont souvent plus sensibles que les données techniques. La séparation doit également les couvrir.
- Utiliser une seule identité. La connexion via SSO d'entreprise signifie que l'accès est géré en un seul endroit, et qu'un employé qui quitte l'entreprise ne laisse pas un compte oublié derrière lui.
Comment Eywo Stratum gère cela
Nous avons construit Eywo Stratum pour les fournisseurs de services partagés qui desservent de nombreux clients à partir d'une seule plate-forme. La séparation des clients (multi-tenancy) fait partie du modèle de données.
Un utilisateur client ne voit que les données de son propre client. Cela s'applique aux éléments de la CMDB, aux incidents, aux demandes, aux changements et aux coûts. Lorsqu'un département ouvre sa vue d'ensemble des coûts, il voit ses propres services métier et projets, et non les chiffres d'un autre département. L'équipe interne du fournisseur travaille sur l'ensemble de la plate-forme et voit l'infrastructure partagée et les dépendances entre les clients.
Les autorisations sont gérées via des rôles définis. La plate-forme comporte 14 rôles, et chaque rôle est attribué avec une portée définie : tout, client, équipe ou élément. Un responsable des opérations client peut avoir le même rôle qu'un responsable d'équipe interne, simplement limité à son propre client. Une matrice RACI indique qui est responsable de quoi, et la plate-forme vérifie que ces responsabilités correspondent aux autorisations que les personnes ont réellement.
La connexion se fait via SSO (Cloudflare Access), de sorte que l'accès suit l'identité d'entreprise. Les intégrations et les comptes de service utilisent des jetons API qui ne sont pas liés à une personne spécifique. Chaque action, y compris les changements d'autorisation, est écrite dans un journal d'audit conservé pendant cinq ans.
Pour le fournisseur, cela met fin à l'ère des exports manuels. Les clients peuvent vérifier le statut de leurs incidents, de leurs performances SLA ou de leurs coûts mensuels par eux-mêmes. L'équipe d'opérations peut se concentrer sur les opérations, et le responsable de la sécurité a une réponse claire à la question « qui peut voir quoi ? »
Conclusion
Une plate-forme partagée et des données séparées ne sont pas mutuellement exclusives. Mais la séparation doit être intégrée, et non ajoutée. Lorsque la plate-forme elle-même impose qui travaille avec quelles données, un fournisseur peut ouvrir l'outil à ses clients et toujours rentrer chez lui l'esprit tranquille.
La séparation des données des clients est incluse dans l'édition Enterprise.
Eywo Stratum Enterprise
Pour les fournisseurs de services partagés et les grandes organisations.