Qu'est-ce qu'un SOC multi-tenant pour MSP ?

Un SOC multi-tenant surveille les environnements de plusieurs clients sur une même plateforme, chaque client disposant d’un espace strictement cloisonné : ses données, ses alertes, ses règles et ses rapports. Pour un infogérant, il offre une vue consolidée de tous ses clients, avec des droits différenciés selon les intervenants. C’est l’architecture qui rend le SOC pour MSP possible.

Cet article fait partie de notre série sur le SOC managé. Pour le principe général, voir SOC pour MSP : qu’est-ce que c’est et comment ça fonctionne ?.

Le principe

Le terme « tenant » désigne un espace isolé dans une plateforme partagée, comme un locataire dans un immeuble. Dans un SOC multi-tenant :

• chaque client est un tenant : ses sources (EDR, Microsoft 365, pare-feux) remontent dans son espace, et nulle part ailleurs ;
• l’infogérant voit l’ensemble de ses tenants depuis une seule console ;
• le SOC opère tous les tenants avec les mêmes analystes et les mêmes outils.

Pourquoi c’est indispensable pour un infogérant

Sans plateforme multi-tenant, un infogérant qui protège 30 clients devrait jongler avec 30 consoles, 30 jeux d’alertes et 30 formats de rapports. Le multi-tenant apporte :

• une vue d’ensemble : quels clients ont des incidents en cours, lesquels sont stables ;
• des rapports par client, que l’infogérant transmet à ses clients ;
• un démarrage rapide de chaque nouveau client, sans nouvelle infrastructure ;
• une détection qui profite à tous : une technique d’attaque vue chez un client renforce la détection pour les autres.

Pour le modèle de consommation qui va avec, voir Qu’est-ce que le SOC as a service ?.

Les deux points à vérifier en priorité

1. Le cloisonnement entre clients

Les données d’un client ne doivent jamais être visibles dans l’espace d’un autre. Cela concerne les événements collectés, les alertes, les rapports, mais aussi les comptes : un intervenant ne doit voir que les clients qui le concernent. Demandez comment ce cloisonnement est assuré et contrôlé.

2. La sécurité de l’accès à la console

Une console qui donne accès à tous les clients d’un infogérant est une cible de choix : la compromettre, c’est toucher tous les clients d’un coup. C’est le scénario d’attaque par rebond via la chaîne d’approvisionnement : l’article 21 de NIS2 cite la sécurité de la chaîne d’approvisionnement parmi les mesures de gestion des risques. Les protections attendues :

• authentification multifacteur obligatoire ;
• droits limités au strict nécessaire pour chaque intervenant ;
• traçabilité des actions dans la console.

Nous avons développé ce risque dans Directive NIS2 : obligations, risques et leviers de croissance.

Ce que propose la plateforme Cyna

La plateforme Cyna est conçue pour les infogérants :

• une seule console pour tous les clients, toutes les alertes, tous les engagements de service ;
• un cloisonnement strict, avec des permissions granulaires par intervenant : chaque client, son périmètre ;
• des rapports mensuels d’activité et de vulnérabilités, exportables en CSV ou PDF, en marque blanche.

Pour la répartition des rôles au quotidien, voir SOC managé et infogérant : qui fait quoi ?.

Les questions à poser à un fournisseur

1. Comment les données de chaque client sont-elles séparées, techniquement et dans les droits d’accès ?
2. Peut-on attribuer des droits différents selon les intervenants de l’infogérant ?
3. L’authentification multifacteur est-elle obligatoire pour accéder à la console ?
4. Les actions réalisées dans la console sont-elles tracées ?
5. Les rapports peuvent-ils être produits par client, aux couleurs de l’infogérant ?
6. Combien de temps faut-il pour ajouter un nouveau client ?
7. Que deviennent les données d’un client qui quitte la plateforme : export, durée de conservation, suppression ?

Cette dernière question est souvent oubliée. Les clients évoluent : certains sont rachetés, d’autres changent de prestataire. Une réponse claire sur la fermeture d’un tenant, les données exportables et la durée de conservation des journaux après le départ évite des discussions délicates plus tard, et aide l’infogérant à répondre aux questions de ses propres clients sur leurs données. C’est aussi l’occasion de vérifier qui, chez l’infogérant, peut demander la fermeture d’un tenant.

Multi-tenant ne veut pas dire uniforme

Partager une plateforme ne signifie pas surveiller tous les clients de la même façon. Un bon SOC multi-tenant applique un socle commun, puis s’adapte à chaque client : un client dont les salariés voyagent n’aura pas les mêmes alertes de connexion qu’un client qui ne travaille qu’en France ; un client qui utilise un outil d’administration particulier le verra déclaré comme légitime. Cet ajustement fait partie du démarrage et se poursuit dans le temps.

Faire le point avec un expert

Vous êtes infogérant et vous voulez voir la console multi-clients en action ? Contactez-nous pour une démonstration, ou consultez la page Programme partenaire.

Questions fréquentes

Mes clients peuvent-ils accéder à la plateforme ?

Cela dépend de la plateforme et du choix de l'infogérant. Dans un modèle où l'infogérant porte la relation client, il transmet en général les rapports à son client plutôt que de lui ouvrir la console.

Les règles de détection sont-elles les mêmes pour tous les clients ?

Un socle commun s'applique à tous, puis des ajustements par client tiennent compte de son contexte : outils utilisés, horaires, pays d'activité, exceptions légitimes.

Un incident chez un client profite-t-il aux autres ?

C'est un des intérêts du modèle mutualisé : une technique d'attaque observée chez un client peut servir à renforcer la détection pour les autres, sans que les données du client concerné soient partagées.