Isolation tenant : comment un MSSP mutualisé peut faire fuiter vos logs chez votre concurrent

TL;DR — La plupart des MSSP fonctionnent en multi-tenant : la même infrastructure technique sert plusieurs clients, distinguée par un identifiant logique (

tenant_id

). C'est efficace économiquement — c'est aussi structurellement risqué. 5 patterns d'architecture distinguent un MSSP qui isole vraiment ses tenants d'un MSSP qui prie pour qu'aucun bug ne fasse fuiter les données croisées. Cas concrets, audit pratique, et comment UniSOC est conçu.

Pourquoi le multi-tenant est une bombe à retardement quand mal conçu

Imaginez 200 entreprises clientes d'un MSSP. Chacune envoie ses logs (DPI, EDR, AD, mail, threat intel) au MSSP. Le MSSP stocke tout dans une seule base de données avec une colonne

tenant_id

.

C'est le design "naïf" : simple à coder, simple à scaler, simple à maintenir. C'est aussi un accident en attente d'arriver. Quelques scénarios :

Scénario 1 — Bug applicatif

Un développeur ajoute une feature de "comparaison sectorielle anonymisée". Il oublie un filtre

WHERE tenant_id = ?

dans une requête. Pendant 3 jours, tous les clients voient les statistiques de tous les autres. Avant qu'un client le remarque et alerte. Selon la nature des stats, ça peut révéler qui s'est fait attaquer par quoi — information confidentielle critique.

Scénario 2 — Compromission interne

Un analyste mécontent (ou un attaquant qui a phishé un analyste) dump la table principale d'incidents. Sans isolation forte, il récupère tous les incidents de tous les clients en une requête. C'est exactement ce qui arrive aux MSSP régulièrement, et c'est rarement publié.

Scénario 3 — Side-channel

Le MSSP héberge tous les tenants sur le même cluster Kubernetes. Un attaquant qui exploite une vulnérabilité runtime container (escape) peut lire les fichiers d'autres pods (autres tenants). Cas réels documentés : Hertzbleed, Spectre, plusieurs CVE Kubernetes 2022-2024.

Scénario 4 — Mauvaise tenancy SaaS sous-jacent

Le MSSP utilise un SaaS multi-tenant lui-même (par exemple Splunk Cloud) avec une mauvaise configuration de namespace. Les buckets S3 sont mal cloisonnés. Un client peut lire les indexes d'un autre via des URL devinables.

Scénario 5 — Threat intel qui leak

Le MSSP enrichit ses détections en utilisant les patterns observés chez tous ses clients ("on a vu cette IP attaquer d'autres clients chez nous"). Si l'attribution n'est pas anonymisée, les noms des autres clients fuitent dans vos rapports. Ça arrive plus souvent qu'on ne le croit.

Les 5 patterns d'architecture qui font la différence

Pattern 1 — Isolation au niveau base de données (pas au niveau colonne)

Mauvais design : une seule base, une colonne

tenant_id

partout. Tout repose sur la discipline du code applicatif.

Bon design : une base (ou schéma) par tenant. Chaque connexion au SGBD est limitée à la base du tenant en cours. Une requête mal écrite ne peut physiquement pas atteindre les données d'un autre tenant — même si le développeur oublie le filtre.

Compromis pragmatique pour MongoDB / NoSQL : collections séparées par tenant_id (

alerts_tenant1

,

alerts_tenant2

...) avec un user MongoDB ayant un rôle qui restreint l'accès aux collections du tenant connecté.

Pattern 2 — Authentification analyste scopée par tenant

Mauvais design : un analyste se connecte au portail interne, voit tous les tenants dans une dropdown, switch d'un tenant à l'autre librement.

Bon design : un analyste se connecte avec un contexte tenant explicite (par ticket d'investigation). L'audit trail enregistre chaque switch avec justification. Pour les opérations cross-tenant (rare : analyses sectorielles), une procédure de dual-control est exigée (deux analystes valident).

Pattern 3 — Threat intel partagée mais anonymisée

Mauvais design : "On a vu cette IP attaquer ACME Corp la semaine dernière." Le nom du client précédent est partagé. Information confidentielle commerciale critique.

Bon design : "On a vu cette IP utilisée dans une campagne ciblant le secteur retail européen la semaine dernière." Pas de nom client, secteur + zone géographique seulement. Threat intel utile mais non identifiante.

Pattern 4 — Compute isolé par criticité de tenant

Mauvais design : un seul pool Kubernetes pour tous les tenants. Une CVE container escape = compromis transverse.

Bon design : pool dédié pour les tenants "critiques" (santé, défense, OIV/OSE). Pour le reste, mutualisation acceptable avec patches CVE prioritaires + audit trimestriel.

Excellent design : enclaves matérielles (Intel TDX, AMD SEV-SNP) pour les tenants ultra-critiques, où même le sysadmin du MSSP ne peut pas voir les données en clair. Solution émergente, déployée par quelques acteurs en 2026.

Pattern 5 — Audit trail tenant-side accessible

Mauvais design : seul l'admin MSSP peut voir qui a accédé à ce qui. Le client tenant doit faire confiance.

Bon design : le client tenant a accès à un audit trail dédié : "Le 15 mai à 14h32, l'analyste M. Dupont (UniSOC) a accédé à l'incident #4521 dans le cadre de l'investigation Ticket-2025-0892. Justification : suivi du faux positif rapporté par le client le 14 mai."

Cet audit trail est partagé avec le client en lecture, donc immutable et auditable de l'extérieur. C'est le standard de souveraineté de 2026.

Comment auditer l'isolation tenant de votre MSSP en 5 questions

Question A — « Pouvez-vous me donner un test de séparation logique ? »

Demandez au MSSP de créer deux tenants de test sur leur plateforme, puis de prouver qu'un compte du tenant A ne peut physiquement pas récupérer une donnée du tenant B même en cas de bug applicatif. Idéalement par un rapport de pentest interne ou par un démonstration live.

Question B — « Quel est votre RBAC analyste ? »

L'analyste senior peut-il, par défaut, voir tous les tenants ? Ou seulement le tenant de son ticket actif ? Comment l'audit trail est-il consultable ?

Question C — « Comment la threat intel est-elle anonymisée ? »

Demandez à voir un rapport threat intel anonymisé concret. Cherchez : noms d'autres clients, identifiants techniques d'autres clients (IP internes, hostnames spécifiques), nombre exact d'autres victimes pouvant identifier un client par déduction.

Question D — « Avez-vous une politique de pool dédié pour les clients critiques ? »

Si vous êtes santé, OIV/OSE, défense, c'est non négociable. Si la réponse est « tous les clients sont sur le même pool », c'est insuffisant pour vous.

Question E — « Puis-je avoir un export de mon audit trail tenant ? »

Si oui, à quelle fréquence, format, complétude ? Si non, pourquoi ?

Les bonnes pratiques d'isolation tenant — la grille de référence

Voici la grille technique que tout MSSP sérieux devrait pouvoir cocher. Vous pouvez l'utiliser pour évaluer votre prestataire actuel ou un futur prestataire — qu'il s'agisse de la plateforme SOC managé UniSOC ou d'un concurrent. Aucune de ces pratiques n'est un secret industriel : ce sont les fondamentaux d'une architecture multi-tenant défendable.

Niveau base de données

• Le

  tenant_id

  est porté par toutes les collections opérationnelles sans exception : alertes, incidents, findings EDR, assets, IoCs, jobs cron tenant-scopés, logs d'audit. Une collection sans

  tenant_id

  est une collection mutualisée — donc une fuite latente.
• Les indexes uniques sont compound avec le

  tenant_id

  en première position (ex :

  (tenant_id, fingerprint)

  ,

  (tenant_id, event_id, rule_id)

  ). Un index unique global (sans

  tenant_id

  ) crée une dépendance croisée : un tenant peut accidentellement bloquer ou supprimer une donnée d'un autre.
• La résolution du

  tenant_id

  est centralisée dans un wrapper qui lit le JWT et rejette toute requête sans contexte tenant explicite. Pas de discipline applicative : une garde structurelle.
• Sur les bases relationnelles, la Row-Level Security (RLS) native est activée sur toutes les tables par tenant. Les tables réellement partagées (CVE publique, MITRE, géoloc) sont identifiées et documentées comme telles.

Niveau analyste

• Authentification admin séparée du portail client (deux émetteurs JWT distincts, deux pools d'utilisateurs). Pas de mélange compte client / compte analyste.
• Hiérarchie RBAC formelle côté analyste : un rôle "lecture seule un seul tenant", un rôle "investigation un seul tenant", un rôle "cross-tenant" réservé aux opérations sectorielles, et un rôle "actions destructives" (isolate host, kill process, quarantine, TCP reset) avec dual-control obligatoire.
• Le scope tenant est explicite sur chaque session analyste, pas dérivé d'une dropdown libre. Un changement de scope laisse une trace.
• Les actions destructives nécessitent une justification (numéro de ticket, motif), enregistrée et exposable au client.

Niveau threat intel

• Pas de fuite par enrichissement. Lorsqu'on enrichit un IoC en disant "vu sur d'autres clients", on n'expose jamais l'identifiant des autres clients. Format anonymisé : "vu sur N autres clients du secteur retail FR semaine 18".
• K-anonymity sur les statistiques cross-tenant : si un IoC n'a été vu que sur 1 ou 2 autres clients, on n'expose pas le détail sectoriel — sinon, par déduction, le client peut deviner de qui il s'agit. Seuil minimal recommandé : k ≥ 3.
• Source publique vs observation interne séparées dans la réponse d'enrichissement. La CTI publique (OpenCTI, NVD, OSV, feeds payants) est exposable telle quelle ; les observations internes sont systématiquement agrégées et anonymisées.

Niveau compute

• Hébergement souverain documenté (juridiction, certifications applicables : HDS, SecNumCloud, ISO 27001). La localisation des données et le droit applicable doivent être contractuels, pas verbaux.
• Patches CVE container runtime appliqués sous SLA contractualisé (7 jours max recommandé pour les CVE haute sévérité). Audit accessible.
• Pools dédiés pour les tenants à criticité élevée (santé HDS, OIV/OSE, défense). Pas de mutualisation côté compute pour ces profils.
• Accès admin via bastion MFA, pas d'accès SSH direct aux nœuds. Logs d'accès bastion conservés et auditables.
• Roadmap enclaves matérielles (Intel TDX, AMD SEV-SNP) pour les tenants ultra-critiques — solution émergente, à demander en évaluation à votre MSSP.

Niveau audit trail

• Le client tenant peut consulter son audit trail depuis son portail, sans demande au MSSP, en lecture immédiate.
• Export programmable (CSV, JSON, plage de dates) sans intervention humaine côté MSSP.
• Le log inclut les accès des analystes du MSSP au tenant (qui, quand, quoi, dans quel cadre) — pas seulement les actions du client lui-même. C'est le test décisif : si le MSSP ne peut pas vous montrer qui de chez lui a consulté votre dernier incident, il n'a pas de vrai audit trail.
• TTL long (12 mois minimum) pour permettre les audits a posteriori et les enquêtes en cas d'incident.
• Couverture des actions destructives en priorité (active response, isolation, suppression). Les consultations en lecture peuvent être agrégées si le volume est trop élevé, mais les mutations doivent être tracées exhaustivement.

Le test ultime : demandez à voir un breach interne réel et son post-mortem

Tout MSSP a eu, ou aura, une compromission interne (rappel : 87 % en 12 mois). Le bon MSSP en a tiré des leçons et publie un post-mortem anonymisé que vous pouvez lire. Le mauvais MSSP nie ou cache.

Demandez : « Avez-vous un post-mortem public d'un incident interne des 24 derniers mois ? Sur l'isolation tenant ? Sur n'importe quel sujet ? ».

Si la réponse est « non rien », c'est soit qu'ils n'ont rien à dire (trop petits ou trop chanceux), soit qu'ils cachent.

Conclusion

L'isolation tenant n'est pas un sujet sexy. Aucun directeur commercial ne le met en page une de sa plaquette. C'est pourtant la seule chose qui sépare un MSSP qui peut survivre à un compromis interne d'un MSSP qui amène 200 clients dans sa chute.

Les 5 patterns ci-dessus sont la grille pour évaluer. Aucun MSSP n'est parfait sur les 5 — mais un MSSP qui n'en a aucun n'est pas un MSSP, c'est un risque concentré. Pour les RSSI d'ETI qui veulent vérifier ces patterns sur un cas concret, notre offre entreprises détaille notre grille point par point.

À lire aussi : MSSP piratés en 2024-2026 et Audit MSSP : 12 questions.

---

Vous voulez un audit indépendant de l'isolation tenant de votre MSSP actuel ? Demandez notre exercice "Tenant Boundary Audit" → — 5 jours, livrable rapport technique avec scénarios d'évasion testés sur votre instance.