Isolation multi-locataire dans le SaaS de défense : séparer des clients classifiés sur une infrastructure partagée

Les plateformes SaaS de défense font face à une tension structurelle que les logiciels civils multi-locataires ne connaissent pas. Un éditeur SaaS commercial se préoccupe de la séparation logique des données entre clients afin d'éviter toute exposition accidentelle. Un éditeur SaaS de défense doit atteindre une garantie bien plus forte : que les données appartenant à un locataire classifié soient prouvablement inaccessibles à un autre locataire, même si un attaquant a compromis le code de la couche applicative ou obtenu des identifiants d'administrateur. Le langage réglementaire est strict : une divulgation non autorisée de données SECRET à un locataire non habilité n'est pas un incident de confidentialité, c'est un événement de fuite (spillage) aux conséquences juridiques et opérationnelles. Cet article examine comment l'isolation multi-locataire est conçue, mise en œuvre et démontrée dans les plateformes SaaS de défense qui desservent des locataires de niveaux de classification différents, avec des exigences de résidence des données différentes et des frontières d'accréditation indépendantes, sur une infrastructure cloud classifiée fondée sur Kubernetes.

Pourquoi la multi-location est complexe lorsque les locataires ont des niveaux de classification différents

L'architecture multi-locataire dans les logiciels commerciaux est avant tout une décision économique : le partage du calcul, de la base de données et de la charge opérationnelle entre clients réduit le coût de livraison par client. Dans le SaaS de défense, l'économie reste pertinente, mais les exigences d'isolation imposées par la classification introduisent des contraintes que les modèles multi-locataires commerciaux ne peuvent satisfaire d'emblée. Lorsque deux locataires opèrent à des niveaux de classification différents (par exemple, l'un en SECRET et l'autre en UNCLASSIFIED), ils ne peuvent pas partager un moteur de base de données, un pool de planification de conteneurs ou un espace de noms de clés cryptographiques, car chacune de ces couches partagées pourrait devenir un canal de transfert non autorisé de données, que ce soit par une mauvaise configuration de requête directe, des attaques temporelles par canal auxiliaire ou un outillage d'opérateur compromis.

L'écart de niveau de classification n'est pas le seul facteur de complication. Même des locataires de même niveau de classification peuvent avoir des exigences incompatibles qui imposent une isolation forte : des lois nationales de résidence des données différentes, des règles différentes de conservation des journaux et d'accès aux audits, des populations d'utilisateurs autorisés différentes et des suites de chiffrement approuvées différentes. Un locataire du ministère de la Défense du Royaume-Uni et un locataire du département de la Défense des États-Unis peuvent tous deux opérer au niveau RESTRICTED/SENSITIVE tout en étant interdits par accord bilatéral de voir leurs données traitées sur le même matériel physique. Le modèle d'isolation doit donc être conçu face à une matrice d'attributs de locataire (niveau de classification, juridiction nationale, autorité d'audit et matériel cryptographique approuvé) plutôt qu'un simple binaire haut/bas.

Les cadres réglementaires amplifient les enjeux. Sous des cadres tels que le Cloud Computing Security Requirements Guide du département de la Défense des États-Unis et les orientations Secure by Design du Royaume-Uni, un système qui prétend isoler des locataires classifiés doit démontrer cette isolation par des contrôles documentés, des tests indépendants et une surveillance continue, et non se contenter de l'affirmer. Une autorité d'homologation exigera des preuves : des captures de trafic réseau montrant l'absence de flux inter-locataires, des journaux du service de gestion des clés montrant l'absence d'usage de clés inter-locataires, et des journaux de requêtes de base de données ne montrant aucun ensemble de résultats inter-locataires. Les choix d'architecture qui rendent ces preuves difficiles à produire ne sont pas seulement techniquement gênants ; ils sont des obstacles à l'accréditation.

Stratégies d'isolation de base de données : schéma par locataire, base de données par locataire et instance par locataire

La couche base de données est l'endroit où naissent la plupart des défaillances d'isolation multi-locataire. Trois modèles existent, et le bon choix dépend des exigences de classification et d'audit de la population de locataires. Le schéma par locataire place les tables de chaque locataire dans un schéma distinct au sein d'une seule instance de moteur de base de données. Le contrôle d'accès est appliqué par des rôles de base de données à portée de schéma, et les politiques de sécurité au niveau des lignes constituent une seconde couche d'application. Ce modèle présente le plus faible coût opérationnel (un seul moteur de base de données à corriger, surveiller et sauvegarder) et convient lorsque tous les locataires partagent le même niveau de classification et que l'exigence d'isolation est logique plutôt que physique. Sa faiblesse est qu'un rôle mal configuré, une vulnérabilité d'élévation de privilèges dans la base de données ou une requête qui contourne la politique de sécurité au niveau des lignes peut exposer des données inter-locataires. Pour les environnements classifiés où un événement de fuite a de graves conséquences, s'appuyer uniquement sur une isolation logique au niveau du schéma est une position difficile à défendre devant une autorité d'homologation.

La base de données par locataire alloue une instance de base de données dédiée à chaque locataire mais autorise ces instances à s'exécuter sur une infrastructure de calcul partagée. Le processus du moteur de base de données est isolé au niveau du système d'exploitation, de sorte qu'un schéma mal configuré ou un identifiant d'application compromis ne peut atteindre les données d'un autre locataire sans une élévation de privilèges distincte au niveau du système d'exploitation. Ce modèle réduit considérablement la surface d'attaque inter-locataire et constitue le modèle d'isolation minimal viable pour un SaaS de défense desservant des locataires de niveaux de classification différents. Le coût opérationnel est proportionnel au nombre de locataires : chaque instance de base de données requiert son propre calendrier de sauvegarde, sa configuration de surveillance, son flux de migration de schéma et son pool de connexions. À une dizaine de locataires, cela reste gérable avec une automatisation de plateforme bien conçue ; à des centaines, cela exige une couche d'abstraction de base de données en tant que service pour maintenir l'effort opérationnel borné.

L'instance par locataire pousse la séparation plus loin en dédiant non seulement le processus de base de données mais l'intégralité du nœud de calcul aux charges de travail d'un seul locataire. Cela est requis lorsque la documentation d'accréditation du locataire exige une séparation physique, lorsque les canaux auxiliaires temporels inter-locataires constituent un modèle de menace crédible, ou lorsque les données du locataire ne doivent jamais transiter par une infrastructure réseau partagée avec d'autres locataires. Le coût est la facture complète d'infrastructure par locataire : nœuds dédiés, stockage dédié, matériel réseau dédié dans certaines configurations. Pour les locataires de plus haute classification, ce coût n'est pas négociable : c'est l'exigence de sécurité qui détermine l'architecture, et non l'économie. Les plateformes qui desservent un mélange de niveaux de classification mettent souvent en œuvre un modèle à paliers : schéma par locataire pour UNCLASSIFIED, base de données par locataire pour SECRET, instance par locataire pour TS/SCI, avec des pipelines de provisionnement automatisés qui construisent le bon palier à partir d'un fichier de configuration d'intégration de locataire.

Isolation par espace de noms Kubernetes : RBAC, politiques réseau et quotas de ressources par locataire

L'orchestration de conteneurs introduit son propre ensemble de vecteurs d'exposition inter-locataire que l'isolation de base de données seule ne traite pas. Dans un cluster Kubernetes, un pod d'un espace de noms peut, par défaut, envoyer du trafic réseau vers des pods de n'importe quel autre espace de noms, lister des ressources à l'échelle du cluster si son compte de service dispose de permissions excessives, et consommer le CPU et la mémoire à l'échelle du cluster jusqu'à affamer les charges de travail voisines. Pour une plateforme SaaS de défense, aucun de ces comportements par défaut n'est acceptable. La posture d'isolation doit être appliquée comme référence obligatoire au moment du provisionnement du cluster, imposée par des contrôleurs d'admission qui rejettent les définitions de charge de travail non conformes, et validée en continu par un moteur de politiques qui alerte en cas de dérive de configuration.

La politique RBAC pour un Kubernetes de défense multi-locataire part du principe que les comptes de service de chaque locataire n'ont par défaut aucune visibilité inter-espaces de noms. Les rôles à portée d'espace de noms sont préférés aux rôles de cluster ; les liaisons cluster-admin sont interdites en dehors de l'espace de noms de gestion dédié à l'opérateur de la plateforme. Les ressources NetworkPolicy mettent en œuvre une posture de refus par défaut dans chaque espace de noms locataire : aucune entrée ni sortie sauf si explicitement autorisée par une règle de politique. Les flux autorisés sont étroits : le pod applicatif d'un locataire peut communiquer avec son propre pod de base de données, le contrôleur d'entrée partagé et le point de terminaison du service de gestion des clés, et rien d'autre. Les principes d'architecture réseau zero trust se transposent directement sur ce modèle : chaque flux de trafic est vérifié, rien n'est implicitement digne de confiance du simple fait qu'il provient de l'intérieur de la frontière du cluster.

Les objets ResourceQuota empêchent un seul locataire de déclencher une condition de déni de service contre d'autres locataires en consommant des ressources de cluster disproportionnées. Chaque espace de noms reçoit des quotas sur la demande et la limite de CPU, la demande et la limite de mémoire, le stockage des revendications de volume persistant et le nombre de pods en cours d'exécution. Les objets LimitRange fixent des demandes de ressources par défaut sur les pods qui ne les déclarent pas explicitement, empêchant les charges de travail non contraintes de contourner le système de quotas. Pour les charges de travail classifiées, les taints de nœuds et les tolérations de pods étendent l'isolation jusqu'à la couche de planification physique : les nœuds dédiés à un locataire de niveau SECRET portent un taint qui empêche les pods UNCLASSIFIED d'y être planifiés, et les spécifications de pod du locataire SECRET portent la tolérance correspondante. La combinaison de RBAC d'espace de noms, de NetworkPolicy, de ResourceQuota et de taints de nœuds offre un modèle d'isolation en couches qui est auditable : chaque couche est documentée, testable et vérifiable indépendamment.

Isolation des clés de chiffrement : des hiérarchies de clés séparées pour chaque locataire classifié

Le chiffrement est le contrôle qui fait tenir l'isolation des données même si l'isolation au niveau de l'infrastructure échoue. Si les données d'un locataire SECRET sont chiffrées avec une clé à laquelle seuls les processus autorisés de ce locataire peuvent accéder, alors une politique réseau mal configurée ou un processus de conteneur échappé ne peut lire les données même s'il accède aux octets bruts de stockage. Cette garantie exige que les clés de chiffrement de chaque locataire soient gérées dans un espace de noms cryptographique inaccessible aux autres locataires, non pas seulement par une politique au niveau applicatif, mais par l'application des contrôles d'accès propres au service de gestion des clés.

La mise en œuvre pratique utilise une structure de clés hiérarchique. À la racine se trouve une clé de chiffrement de clés (KEK) spécifique au locataire, stockée dans une partition de module matériel de sécurité (HSM) ou dans un espace de noms du service de gestion des clés à portée des comptes de service de ce locataire. La KEK enveloppe un ensemble de clés de chiffrement de données (DEK) utilisées par l'application pour chiffrer des catégories de données spécifiques : une DEK pour les enregistrements opérationnels, une pour les journaux d'audit, une pour les pièces jointes, et ainsi de suite. Les DEK sont stockées chiffrées aux côtés des données qu'elles protègent ; elles ne peuvent être désenveloppées que par un processus qui s'est vu accorder l'accès à la KEK du locataire. Si un attaquant compromet une DEK isolément, il peut déchiffrer cette catégorie de données. S'il compromet la KEK, il peut potentiellement déchiffrer toutes les données du locataire, mais il ne peut s'en servir pour accéder aux données d'un autre locataire, car la KEK de l'autre locataire se trouve dans une partition HSM ou un espace de noms de gestion des clés séparé, doté de politiques d'accès entièrement indépendantes. Les environnements d'informatique confidentielle étendent ce modèle en protégeant l'opération de désenveloppement de la DEK elle-même à l'intérieur d'un environnement d'exécution de confiance vérifié par le matériel.

La politique de rotation des clés est aussi importante que la structure des clés. Un locataire dont la KEK n'a pas été tournée depuis deux ans présente un rayon d'impact croissant : tout identifiant compromis à un moment quelconque des deux dernières années accorde potentiellement encore l'accès à toutes les données chiffrées sous cette KEK. Les plateformes SaaS de défense devraient imposer une rotation automatisée de la KEK selon un calendrier défini par l'autorité de classification du locataire (généralement annuelle pour SECRET, plus fréquente pour les classifications supérieures) et fournir une piste d'audit de rotation visible lors des examens d'accréditation. L'événement de rotation lui-même doit être journalisé dans le flux d'audit du locataire, horodaté et attribué à la politique de rotation automatisée ou au compte d'opérateur spécifique qui l'a déclenché.

Application de la résidence des données : maintenir les données du locataire au sein des juridictions autorisées

Les exigences de résidence des données pour les locataires de défense sont souvent des obligations juridiques contraignantes plutôt que des préférences. Un locataire opérant sous une législation de sécurité nationale peut être interdit de voir ses données traitées ou stockées sur une infrastructure située en dehors de sa juridiction nationale, indépendamment des assurances contractuelles du fournisseur cloud. Faire respecter ces exigences dans une plateforme SaaS multi-locataire demande plus que d'étiqueter les données avec un libellé de juridiction : cela exige des contrôles architecturaux qui empêchent les données de quitter physiquement la région autorisée, combinés à des preuves d'audit que ces contrôles ont fonctionné correctement sur toute la période de conservation des données.

Le contrôle principal est la topologie d'infrastructure : les instances de base de données, les buckets de stockage et les pools de nœuds de calcul spécifiques au locataire sont provisionnés exclusivement dans la région cloud de la juridiction autorisée. La réplication inter-régions est désactivée au niveau des couches de stockage et de base de données pour les locataires contraints par la résidence, même à des fins de reprise après sinistre : une réplique dans une juridiction non autorisée est une violation de résidence quel qu'en soit le but. Le modèle de reprise après sinistre de ces locataires doit utiliser une redondance intra-juridiction : des déploiements multi-zones de disponibilité au sein d'une seule région cloud nationale, avec une réplication synchrone entre zones. Cette contrainte force les architectes de SaaS de défense à traiter les locataires contraints par la résidence comme des partitions d'infrastructure distinctes plutôt que comme des paramètres d'un modèle de déploiement mondial unifié.

Les contrôles secondaires traitent les chemins de données moins manifestement liés à la résidence : le transfert de journaux, la télémétrie de surveillance et l'outillage de support. Une plateforme qui contraint correctement le stockage des données à une région autorisée mais transfère les journaux applicatifs vers un SIEM exploité dans un autre pays présente une lacune de résidence. De même, les sessions d'administration à distance qui transitent par le poste de travail d'un ingénieur de support dans une juridiction non autorisée peuvent transporter des fragments de données dans l'état de session. Les plateformes SaaS de défense doivent tracer chaque chemin de données (pas seulement le chemin de données applicatif principal) et appliquer des contrôles de résidence à chacun d'eux. Cela exige généralement une infrastructure de surveillance séparée par zone de résidence et des contrôles stricts sur les comptes d'opérateur autorisés à initier des sessions d'administration contre quels environnements de locataires.

Gestion des frontières d'accréditation : qui détient l'ATO lorsque des locataires partagent l'infrastructure

Les frontières d'autorisation d'exploitation (ATO) deviennent structurellement ambiguës dans une plateforme SaaS de défense multi-locataire. Le fournisseur de la plateforme exploite l'infrastructure partagée (le plan de contrôle Kubernetes, le service de gestion des clés, l'infrastructure réseau, le fournisseur d'identité) et détient une ATO qui couvre ces composants. Chaque locataire exploite des charges de travail applicatives et des données qui reposent sur cette infrastructure et peut détenir une ATO distincte pour sa propre frontière de système. La question de savoir où s'arrête l'ATO de la plateforme et où commence l'ATO du locataire n'est pas une préoccupation théorique : elle détermine qui est responsable de chaque contrôle de sécurité, qui est l'autorité d'homologation pour les changements à ce contrôle, et qui assume la responsabilité en cas de défaillance d'un contrôle.

Le modèle standard est une matrice de responsabilité en couches. L'ATO du fournisseur de la plateforme couvre tous les contrôles au niveau de l'infrastructure : sécurité physique des installations de centre de données, correctifs de l'hyperviseur et du runtime de conteneurs, configuration des groupes de sécurité réseau, disponibilité du service de gestion des clés et journalisation des accès, et les contrôles d'isolation documentés ci-dessus. Le programme de surveillance continue du fournisseur de la plateforme doit produire des preuves que ces contrôles fonctionnent correctement pour tous les locataires simultanément, sans exposer les données de surveillance d'un locataire à un autre. L'ATO de chaque locataire hérite des contrôles de la plateforme par référence (le plan de sécurité du système du locataire cite le dossier d'ATO de la plateforme comme preuve que les contrôles d'infrastructure sont satisfaits) et ne documente que les contrôles spécifiques au locataire : configuration de sécurité au niveau applicatif, marquages de classification des données, population d'utilisateurs autorisés et politique de clés de chiffrement spécifique au locataire.

La gestion des changements au niveau de la plateforme déclenche des obligations de réaccréditation qui se répercutent sur les locataires. Lorsque le fournisseur de la plateforme modifie un composant partagé (met à niveau la version de Kubernetes, change le mécanisme d'application de la politique réseau, modifie le modèle de politique d'accès du service de gestion des clés), l'autorité d'homologation de chaque locataire doit examiner le changement et confirmer que les contrôles hérités du locataire sont toujours valides. Cela crée une charge de coordination qui croît avec le nombre de locataires : une seule mise à niveau de plateforme peut nécessiter de notifier des dizaines d'autorités d'homologation indépendantes et d'en obtenir l'accusé de réception. Les plateformes SaaS de défense qui gèrent bien cela investissent dans un processus formel de communication des changements, des délais de notification préalablement convenus et un libellé type que les autorités d'homologation des locataires peuvent utiliser pour documenter leurs décisions de réaccréditation avec un minimum de retravail.

Journalisation d'audit par locataire : des pistes d'audit ségrégées pour la criminalistique inter-locataire

La journalisation d'audit dans un environnement classifié multi-locataire doit satisfaire deux exigences apparemment contradictoires. Les journaux d'audit de chaque locataire doivent être isolés (accessibles aux auditeurs autorisés de ce locataire et à aucun autre locataire) et l'opérateur de la plateforme doit conserver l'accès à tous les journaux des locataires pour la réponse aux incidents et l'investigation criminalistique au niveau de la plateforme. Résoudre cette tension requiert un modèle de données clair : les journaux d'audit d'un locataire sont des données détenues par le locataire, et leur accès par l'opérateur de la plateforme est lui-même une action journalisée et responsabilisée, soumise aux mêmes exigences d'audit que tout autre événement d'accès privilégié.

Le modèle architectural est un puits de journaux par locataire assorti de contrôles d'immuabilité et d'une journalisation des accès au niveau du puits. Les événements applicatifs et d'infrastructure de chaque locataire sont acheminés vers un groupe de journaux ou une partition de stockage objet dédié, avec une politique d'écriture seule pour la couche applicative et une politique de lecture seule pour les auditeurs autorisés du locataire. Les politiques d'object-lock empêchent la suppression ou la modification des enregistrements de journaux pendant toute la durée de la période de conservation. L'opérateur de la plateforme détient un rôle administratif distinct qui accorde un accès en lecture à tous les puits de journaux des locataires, mais chaque exercice de ce rôle génère un événement d'accès qui est ajouté au flux d'audit propre du locataire, visible par les auditeurs du locataire lors de leur prochain examen. Cette conception signifie qu'un locataire peut toujours répondre à la question « quelqu'un en dehors de notre organisation a-t-il lu nos journaux d'audit ? » en examinant son propre flux d'audit.

L'investigation criminalistique inter-locataire (reconstituer un incident qui peut avoir impliqué plusieurs locataires) exige que l'opérateur de la plateforme corrèle des événements à travers plusieurs puits de journaux isolés. Cette corrélation doit être réalisée à l'aide d'un outillage à privilèges d'opérateur de plateforme qui génère lui-même des enregistrements d'audit, plutôt qu'en fusionnant les flux de journaux des locataires dans une couche de stockage partagée. Une base de données d'audit partagée qui stockerait des événements de plusieurs locataires recréerait le problème de mélange de données inter-locataires que l'architecture de puits de journaux isolés était conçue pour empêcher. À la place, l'outillage criminalistique interroge le puits de journaux de chaque locataire indépendamment et assemble la chronologie inter-locataire en mémoire, dans un environnement d'opérateur isolé de tous les environnements de locataires et lui-même soumis à la journalisation d'audit. Ce modèle préserve l'isolation des journaux des locataires tout en permettant la capacité criminalistique au niveau de la plateforme dont les équipes des opérations de sécurité ont besoin.