Isolation Tenant

1.1 La défense en profondeur n'est pas une métaphore

En cybersécurité classique, la défense en profondeur est un principe théorique. Dans une infrastructure mutualisée hébergeant des clients MSP aux intérêts antagonistes, elle devient une nécessité vitale. Un fournisseur de services managés peut héberger simultanément un cabinet d'avocats, une clinique, et un concurrent direct du premier — sur le même serveur physique.

L'approche traditionnelle du multi-tenant repose sur une séparation applicative : l'application filtre les requêtes selon un tenant_id. Cette approche échoue spectaculairement lorsqu'un bug, une faille d'injection, ou une escalade de privilège contourne cette couche unique.

1.2 Le modèle biologique : membrane cellulaire et jonctions serrées

L'épithélium intestinal humain illustre notre paradigme. Chaque cellule possède sa propre membrane phospholipidique — c'est la première barrière. Entre les cellules, des jonctions serrées (tight junctions) forment une seconde barrière, imperméable même aux petites molécules. Une troisième barrière — le glycocalyx — filtre les macromolécules. Aucune de ces barrières n'est suffisante seule ; leur superposition crée une étanchéité proche de l'absolu.

1.3 Les neuf couches

2.1 Row-Level Security (Couche 1)

PostgreSQL Row-Level Security est le mécanisme le plus profond de l'isolation. Chaque ligne de chaque table porte un tenant_id. Une policy RLS appliquée à chaque table garantit que la session PostgreSQL connectée pour le tenant A ne peut physiquement pas lire les lignes du tenant B.

La fonction current_setting lit une variable de session PostgreSQL. Cette variable est positionnée par le pool de connexions au moment de l'authentification du tenant. Aucune requête applicative ne peut la modifier — elle est en lecture seule depuis l'application. Cette couche est inviolable sans accès super-utilisateur PostgreSQL.

2.2 Schéma par tenant (Couche 2)

Au-delà du RLS, chaque tenant dispose d'un schéma logique dédié — non pas un schema PostgreSQL au sens CREATE SCHEMA, mais une projection de données restreinte. Les vues matérialisées, les index partiels, et les séquences sont filtrés par tenant_id. Un tenant ne peut pas énumérer les autres tenants, car la table tenants elle-même est protégée par RLS.

Cette couche empêche les attaques par inférence : même si un tenant parvenait à mesurer le temps d'exécution d'une requête (timing attack), les index partiels garantissent que les données des autres tenants ne sont jamais parcourues.

2.3 Contraintes et triggers (Couche 3)

La troisième couche PostgreSQL utilise des contraintes CHECK et des triggers BEFORE INSERT/UPDATE pour empêcher l'écriture de données qui ne respecteraient pas l'isolation :

Un trigger supplémentaire verrouille toute tentative de modification de la colonne tenant_id après insertion. Cette redondance est volontaire : si la policy RLS est désactivée par erreur (par exemple lors d'une maintenance), les contraintes et triggers maintiennent l'isolation.

3.1 SPINA v2 — Signature par tenant (Couche 4)

SPINA (Signature Protocol for Integrity and Non-repudiation of Assets) est le protocole de signature de 0DATA. En version 2, chaque tenant possède :

• Une clé HMAC-SHA256 locale, générée et stockée dans l'espace du tenant
• Un certificat eIDAS RFC 3161 pour l'horodatage qualifié
• Un keystore isolé, chiffré avec une passphrase dérivée du secret du tenant

Deux tenants ne partagent jamais de matériel cryptographique. Si le tenant A compromise sa clé HMAC, les signatures du tenant B restent valides. L'horodatage eIDAS est fédéré au niveau de l'infrastructure mais le timestamp token est stocké dans le schéma du tenant.

La vérification de signature est exécutée dans le contexte PostgreSQL du tenant. La fonction spina_verify() utilise SECURITY DEFINER avec un SET app.current_tenant_id explicite — elle ne peut pas fuiter hors du tenant.

3.2 NOVA — Instance par tenant (Couche 5)

NOVA est le moteur d'observation du réseau. Chaque tenant MSP possède sa propre instance NOVA, exécutée comme un processus dédié :

• Bind exclusif sur 127.0.0.1, port distinct pour chaque tenant
• Base de données de scan locale (SQLite ou schéma PostgreSQL isolé)
• Aucun partage de mémoire entre instances
• Fichier de configuration distinct (/opt/nova/tenants/<tenant_id>/config.yaml)

Un tenant qui contrôle son réseau local (et donc les cibles scannées par NOVA) ne peut pas influencer l'instance NOVA d'un autre tenant. Les processus sont isolés au niveau du système d'exploitation — kill -9 sur le PID du tenant A n'affecte pas le tenant B.

3.3 ALFA — Moteur commun, mémoire isolée (Couche 6)

ALFA (Analytics Layer for Forensic Assessment) est le moteur décisionnel partagé. Contrairement à NOVA, ALFA utilise un moteur commun pour l'efficacité des ressources, mais avec une isolation mémoire stricte :

• Chaque niveau d'analyse (tenant, site, équipement) est cloisonné
• Les données sont chargées dans des segments mémoire étanches
• Les résultats d'analyse sont écrits dans le schéma PostgreSQL du tenant
• Aucune corrélation inter-tenant n'est effectuée sans consentement explicite

ALFA applique le principe du besoin d'en connaître au niveau algorithmique : un modèle d'analyse exécuté pour le tenant A ne reçoit que les données du tenant A. Les statistiques agrégées multi-tenant (utiles pour le benchmarking) utilisent des données anonymisées avec differential privacy (ε = 1.0).

4.1 Cockpit — Domaine propre et JWT par tenant (Couche 7)

Chaque tenant accède à l'interface Cockpit via un domaine dédié : client.odata.fr. Le certificat SSL (Let's Encrypt) est émis pour ce domaine. Le JWT d'authentification est signé avec une clé secrète propre au tenant, et contient le tenant_id dans ses claims.

Le middleware nginx valide le JWT avant de router la requête. Une tentative d'accès à client-b.odata.fr avec un JWT du tenant A est rejetée au niveau du reverse proxy — avant même que la requête n'atteigne l'API. Le domaine lui-même constitue une frontière d'isolation : un tenant ne peut pas deviner le sous-domaine d'un autre tenant (les noms sont des UUID ou des identifiants opaques).

4.2 DNS wildcard et NATS namespacé (Couche 8)

La couche 8 opère au niveau de la communication inter-service :

DNS wildcard. L'enregistrement *.odata.fr pointe vers l'infrastructure. Chaque sous-domaine est résolu mais le serveur d'application filtre les domaines non enregistrés. Un tenant ne peut pas créer un sous-domaine arbitraire — l'enregistrement DNS est contrôlé par l'infrastructure.

NATS namespacé. Le bus de messages NATS utilise des sujets préfixés par le tenant :

Les ACL NATS sont configurées pour que les credentials du tenant A ne puissent publier ou souscrire qu'aux sujets tenant.a1b2c3d4.*. Le serveur NATS applique ces ACL au niveau du protocole — un client ne peut pas contourner le namespacing.

4.3 Plan de ports — Aucun service sur 0.0.0.0 (Couche 9)

La couche 9 est la plus physique : le plan de ports documenté. Aucun service interne n'écoute sur 0.0.0.0. Chaque service est bindé sur 127.0.0.1 avec un port explicite. Le firewall (UFW, politique default deny) bloque tout le trafic entrant qui n'est pas explicitement autorisé. Cette couche est documentée en détail dans la section 5.