PaaS mono-locataire ou multi-locataire : changements au niveau de l'infrastructure pour les secteurs réglementés

Les équipes soumises à une réglementation se voient souvent imposer l’exigence du « single-tenant », généralement par le service des achats, un auditeur ou l’équipe de sécurité d’un prospect, sans aucune explication sur son utilité. C’est une contrainte coûteuse à accepter telle quelle.

Le terme « single-tenant » correspond rarement à ce dont on a réellement besoin. Ce qu’un auditeur vérifie, c’est si tu peux prouver un ensemble de garanties : que tes données sont isolées, qu’un « voisin bruyant » ne peut pas paralyser ta charge de travail, que les données se trouvent là où la réglementation l’exige, que tu peux fournir des preuves de tes contrôles, et qu’une défaillance à un endroit reste confinée à cet endroit. Seules quelques-unes de ces garanties nécessitent véritablement une infrastructure dédiée. La plupart n’en ont pas besoin.

Les équipes qui l’acceptent sans réfléchir ont tendance à acheter la version la plus chère et à ne toujours pas satisfaire l’auditeur, car les questions qui comptaient portaient sur l’isolation et les preuves plutôt que sur le matériel. La question la plus utile est de savoir quelles garanties tu dois prouver, et où, sur l’éventail allant du partagé au dédié, chaque charge de travail doit se situer. Cet article aborde ces deux aspects, au niveau de l’infrastructure.

Que signifient « mono-locataire » et « multi-locataire » au niveau de l’infrastructure ?

Un modèle de location décrit comment la charge de travail d’un client est séparée de celle d’un autre. 

1. Le modèle « single-tenant » offre à chaque client une stack dédiée : sa propre puissance de calcul, souvent sa propre base de données, parfois son propre matériel. Rien n’est partagé avec un autre client. Le principe d’isolation est simple à expliquer, mais c’est aussi la solution la plus coûteuse et la plus lente à mettre en place.
2. Le modèle multi-locataires héberge de nombreux clients sur une infrastructure partagée, séparés par des logiciels plutôt que par du matériel dédié. Il est efficace et rapide à mettre en place, et sa sécurité dépend de la façon dont le fournisseur assure la séparation entre les locataires. De nombreux systèmes conformes et réglementés fonctionnent de cette manière.

Les modèles mono-locataire et multi-locataire décrivent les deux extrémités d’un spectre, et la plupart des plateformes actuelles se situent entre les deux plutôt qu’à l’une ou l’autre extrémité. Ce juste milieu, c’est la troisième option, et c’est celle qu’on oublie le plus souvent dans les discussions.

3. L’isolation stricte par projet sur un cloud partagé, c’est là où se situent la plupart des plateformes-en-service modernes, et c’est ce que les gens oublient souvent. Chaque projet tourne dans son propre environnement isolé, au-dessus d’une infrastructure cloud partagée, avec une option de cluster dédié pour les charges de travail qui ont besoin de ressources physiquement séparées. Ça offre la plupart des avantages de l’isolation du « single-tenant » sans imposer le coût du « single-tenant » à chaque charge de travail. 

Il est important de nommer ces trois options, car une exigence formulée en termes de « locataire unique » est souvent satisfaite par la troisième option, pour un coût bien moindre.

Compromis : coût, exploitation et vitesse à tous les niveaux

Avant de déterminer celle dont tu as besoin, il est utile de connaître le coût de chacune, car les différences sont importantes et ne sont pas uniquement financières.

• Le mode « single-tenant » complet offre l’isolation la plus solide et la plus simple, ce qui est parfois exigé par contrat. Il entraîne également le coût d’infrastructure le plus élevé, la charge opérationnelle la plus importante et le provisionnement le plus lent, car la stack de chaque client est mise en place et maintenue séparément.
• Le modèle multi-locataires est le plus efficace et le plus rapide à mettre en place, mais il t’oblige à faire confiance au fournisseur tout en vérifiant la séparation qu’il assure entre les locataires. Pour les charges de travail dont les exigences réglementaires sont satisfaites par une forte séparation logique, c’est souvent le choix le plus judicieux.
• Un isolement strict avec une option dédiée là où c’est nécessaire vise un juste milieu : la plupart des avantages de l’isolement par défaut, avec des ressources dédiées réservées aux charges de travail qui nécessitent vraiment une séparation physique. Ça permet de garder les coûts et la charge opérationnelle proportionnels aux besoins réels, plutôt que d’appliquer le modèle le plus cher à tout.

L'erreur à éviter, c’est de payer le coût d’un environnement mono-locataire sur l’ensemble de ton parc pour répondre à une exigence qui ne s’applique qu’à une seule charge de travail.

Pourquoi les secteurs réglementés exigent-ils un modèle « single-tenant » ?

« On a besoin d’une architecture à locataire unique », c’est souvent une formule toute faite, transmise par une équipe de sécurité, une liste de contrôle des achats ou un auditeur. Derrière ça, il y a tout un ensemble d’exigences réelles, et chacune d’entre elles est une garantie que tu dois prouver, plutôt qu’un modèle d’hébergement que tu achètes.

• L’isolation des données. Un client ne doit jamais avoir accès aux données d’un autre. C’est la préoccupation principale, et elle est satisfaite par une isolation vérifiable, que le matériel dédié permet d’assurer, mais ce n’est pas la seule solution.
• Pas de conflit entre « voisins bruyants ». Les performances d’une charge de travail réglementée ne doivent pas être dégradées par un pic de trafic provenant d’un autre locataire. Ça nécessite des ressources dédiées ou garanties pour les charges de travail qui en ont besoin, pas forcément une stack entièrement dédiée pour tout ce que tu exécutes.
• Résidence des données. La réglementation impose souvent le pays ou la région où les données sont physiquement stockées. Il s’agit ici de savoir où tu peux placer une charge de travail, ce qui relève de la couverture cloud de la plateforme, et non du modèle de location.
• Droit d’audit et preuve des contrôles. Tu dois pouvoir montrer quels sont tes contrôles, quand ils ont changé et qui a approuvé le changement. Ça concerne les preuves fournies par la plateforme, et ça est indépendant du modèle de location.
• Confinement de la propagation des incidents. Un incident survenant à un endroit ne doit pas se propager. Ça concerne l’isolation et la segmentation, que permet une isolation stricte par projet sans qu’il soit nécessaire d’avoir une stack dédiée par client.

Seuls deux de ces cinq critères nécessitent réellement une infrastructure dédiée : les ressources garanties et la séparation physique lorsqu’un contrat l’exige spécifiquement. Les trois autres peuvent être satisfaits sur une infrastructure partagée strictement isolée.

Pourquoi la réponse se trouve au niveau de l’infrastructure

Reviens sur cette liste d’exigences et remarque ce qu’aucune d’entre elles ne mentionne : combien de clients partagent une machine. L’isolation des données est assurée par la segmentation du réseau et le contrôle d’accès. La localisation est déterminée par la région dans laquelle une charge de travail s’exécute. La preuve des contrôles provient de ce que la plateforme enregistre lors du déploiement. Le confinement de la zone d’impact est une propriété de la segmentation. Chacune de ces exigences correspond à un contrôle au niveau de l’infrastructure, et un modèle de location n’est, au mieux, qu’un indicateur approximatif de leur présence.

C’est pourquoi la question « mono-locataire ou multi-locataire ? » est un point de départ si peu utile. Elle porte sur l’emballage plutôt que sur le contenu. Deux plateformes peuvent toutes deux se qualifier de mono-locataires tout en différant énormément sur la façon dont elles segmentent les réseaux, ce qu’elles enregistrent et les régions qu’elles peuvent atteindre. Deux autres peuvent toutes deux être multi-locataires et ne rien avoir en commun sur ces mêmes critères.

La décision se situe donc à un niveau inférieur. Au lieu de choisir un modèle de location en espérant que les contrôles suivent, tu détermines quels contrôles tu dois mettre en place, tu vérifies qu’une plateforme les fournit, et tu laisses le modèle de location être ce qu’il est. Le reste de cet article porte sur ce niveau : les questions qu’il faut se poser et les changements qu’il vaut la peine d’apporter.

Les questions à poser à une plateforme PaaS au niveau de l’infrastructure

Voici les questions qu’il vaut la peine de poser à n’importe quelle plateforme envisagée. Chacune cible un contrôle plutôt qu’une étiquette, et les réponses sont généralement plus révélatrices que tout ce qu’on peut lire sur une page de présentation des fonctionnalités.

Comment les données des locataires sont-elles isolées ?

Demande-leur le mécanisme, pas le terme marketing. La séparation est-elle assurée par une infrastructure dédiée, par une segmentation du réseau, par un isolement par projet ou par une combinaison de ces éléments ? Un modèle d’isolement clair et documenté compte plus que le label qui y est associé.

Les ressources de calcul et de données sont-elles dédiées ou partagées, et peux-tu en obtenir des dédiées quand tu en as besoin ?

Pour la plupart des charges de travail, des ressources garanties sur une infrastructure isolée suffisent. Pour celles qui ont véritablement besoin d’une puissance de calcul physiquement séparée, la question est de savoir si la plateforme propose une option dédiée sans t’obliger à adopter une autre façon de travailler.

Où se trouvent physiquement les données ?

Vérifie quelles régions et quels fournisseurs de cloud sont disponibles, et si tu peux placer une charge de travail là où une règle de résidence l’exige. Une plateforme à fournisseur unique limite tes options dès le départ.

La conformité s’applique-t-elle à tous les environnements ou uniquement à la production ?

C’est là que de nombreuses équipes se font piéger. Si les certifications et les contrôles ne s’appliquent qu’à la production, alors tes environnements de staging et d’environnement de test, qui contiennent souvent des copies de données réelles, se trouvent en dehors du périmètre de conformité. Demande si la conformité s’applique à tous les environnements.

Quelles preuves d’audit la plateforme peut-elle fournir, et comment ?

La meilleure réponse, c’est que ces preuves soient générées automatiquement, en tant que résultat de ton déploiement, plutôt que d’être rassemblées à la main avant chaque audit. Demande si l’historique des modifications, les journaux d’accès et les enregistrements de déploiement existent par défaut et couvrent tous les environnements.

Qui est responsable de quoi ?

Chaque plateforme partage la responsabilité avec le client. Demande le modèle de responsabilité partagée par écrit : quels contrôles d’infrastructure relèvent de la plateforme, et quels contrôles au niveau des applications restent à ta charge. Une clarté sur ce point évite à la fois les doublons et les lacunes dangereuses.

Les changements au niveau de l’infrastructure dont les équipes soumises à la réglementation ont besoin

Savoir quoi demander, c’est déjà la moitié du chemin. L’autre moitié, c’est ce que tu changes de ton côté, car les contrôles ci-dessous font de la conformité une propriété de ta manière de déployer, plutôt qu’un élément que tu mets en place avant chaque audit. Ce sont ces changements que le titre de cet article met en avant.

• Des environnements recréés à l’identique à partir d’une définition. La cause la plus fréquente des constatations d’audit, c’est la dérive : un serveur de préproduction configuré différemment de celui de production, un port ouvert pour un test et jamais refermé. Quand chaque environnement est construit à partir de la même définition gérée par contrôle de version, la dérive n’est plus possible, et « prouver que la préproduction correspond à la production » devient un jeu d’enfant. 
• Des garde-fous imposés par la plateforme. Les règles de sécurité qui figurent dans un document sont souvent contournées. Celles qui sont intégrées à la plateforme ne le peuvent pas. Une base de données sans route publique définie, par exemple, ne peut pas être exposée par accident. Ça donne aux développeurs une autonomie à l’intérieur de limites sûres et élimine d’emblée toute une catégorie de risques.
• Des preuves d’audit générées automatiquement. L’historique des modifications, les journaux d’accès et les enregistrements de déploiement, qui existent par défaut, transforment la collecte de preuves d’un projet en une simple requête. La discussion autour de l’audit passe de l’assemblage de captures d’écran à la simple indication d’enregistrements qui existaient déjà. 
• Une répartition claire des responsabilités. Savoir exactement quelles mesures de contrôle relèvent de la plateforme et lesquelles restent de ta responsabilité te permet de bénéficier des contrôles au niveau de l’infrastructure et de concentrer tes efforts sur la couche applicative, là où se situent réellement tes risques spécifiques.

Aucun de ces quatre changements ne relève d’une décision relative à la location. Ensemble, ils offrent l’essentiel de ce que le modèle « mono-locataire » était censé garantir.

Comment Upsun gère l’isolation et la conformité pour les équipes soumises à une réglementation

Upsun se situe délibérément à plusieurs endroits du spectre, ce qui lui permet de répondre à une exigence réglementaire sans surdimensionner la solution.

• Un isolement strict des projets par défaut. Chaque projet s’exécute dans son propre environnement cloisonné. Rien ne peut y pénétrer, sauf via trois ports approuvés, et les services ne peuvent pas communiquer entre eux à moins que tu ne les connectes explicitement. Techniquement, cet isolement est assuré par les espaces de noms, seccomp et les cgroups, ce qui correspond exactement au mécanisme que les auditeurs s’attendent à voir documenté.
• Résidence multicloud. Upsun se déploie sur AWS, GCP, Azure, IBM Cloud ou OVHcloud à partir d’un seul processus ; ainsi, une charge de travail peut être placée là où une règle de résidence ou un contrat l’exige, tandis que le déploiement et la configuration de sécurité restent identiques d’un fournisseur à l’autre. 
• Conformité dans tous les environnements. Upsun est certifié ISO 27001, SOC 2 Type 2, PCI DSS Niveau 1, HIPAA et TX-RAMP, et applique ses contrôles à tous les environnements et pas seulement à la production, ce qui est important car les environnements de test et de staging contiennent souvent des copies de données sensibles. 
• Un modèle de responsabilité partagée bien défini. Upsun gère les couches d’infrastructure, notamment les correctifs du système d’exploitation, l’isolation et la segmentation du réseau, le renforcement des conteneurs, la sécurité physique et la disponibilité de la plateforme. Le client gère la couche applicative : logique métier, classification des données et décisions d’accès. 
• Des preuves d’audit générées automatiquement par ton mode de déploiement. Comme l’ensemble de la pile de l’environnement est défini dans un fichier .upsun/config.yaml sous contrôle de version et que chaque déploiement et chaque modification de configuration sont consignés, l’historique des modifications et les enregistrements d’accès existent par défaut dans chaque environnement. La collecte des preuves se résume à une requête sur des enregistrements déjà générés, et non plus à un projet à mener avant chaque audit. 

Upsun n’est pas une plateforme à locataire unique et n’a pas besoin de l’être. Elle offre par défaut un isolation stricte, une infrastructure dédiée là où une charge de travail l’exige, un contrôle de la résidence des données, la conformité entre les environnements et des preuves automatiques, soit l’ensemble des garanties que l’on cherche généralement à obtenir avec une exigence de « locataire unique ».

Tu peux adapter ses contrôles à tes propres exigences grâce à la solution de conformité et de gouvernance et au Trust Center.

Quel modèle convient à quelle situation ?

• Opte pour le mode « single-tenant » complet : si un contrat spécifique, une autorité de régulation ou une exigence matérielle impose véritablement une pile dédiée par client, et que le coût et les frais opérationnels sont acceptables et prévus.
• La multi-location convient : si tes exigences réglementaires sont satisfaites par une séparation logique solide et vérifiable, et que tu privilégies l’efficacité et un provisionnement rapide. De nombreux systèmes conformes fonctionnent ainsi.
• Une isolation stricte avec une option dédiée là où c’est nécessaire correspond au cas le plus courant dans la pratique : tu as besoin d’une isolation prouvable, d’un contrôle de la résidence des données et de preuves d’audit dans chaque environnement, avec une infrastructure dédiée réservée aux charges de travail spécifiques qui l’exigent. C’est là que se retrouvent la plupart des équipes soumises à une réglementation une fois que l’exigence est recadrée au-delà de la simple notion de « location ».

Foire aux questions

L’hébergement multi-locataires est-il sûr pour les données réglementées ?

Ça peut l’être. De nombreux systèmes conformes et soumis à une réglementation fonctionnent sur une infrastructure multi-locataires. La sécurité dépend d’un isolement vérifiable et de preuves de contrôles, pas de l’étiquette « multi-locataires ». La question à se poser est de savoir comment la séparation est appliquée et quelles preuves la plateforme peut fournir, plutôt que de savoir si la plateforme est multi-locataires.

La norme PCI DSS ou la loi HIPAA exigent-elles un hébergement mono-locataire ?

Non. Ni la norme PCI DSS ni la loi HIPAA n’imposent une infrastructure à locataire unique. Les deux exigent des contrôles spécifiques en matière d’isolation, d’accès et de preuves, qui peuvent être respectés sur une infrastructure strictement isolée. Vérifie tout contrôle spécifique auprès de ton auditeur plutôt que de partir du principe qu’un modèle de location est obligatoire. 

Quelle est la différence entre l’hébergement mono-locataire et l’hébergement dédié ?

Ces concepts se recoupent mais ne sont pas identiques. Le « mono-locataire » décrit la séparation au niveau du client ; l’hébergement « dédié » décrit des ressources physiquement séparées. Une plateforme peut proposer des ressources dédiées pour une charge de travail, comme un cluster dédié, sans pour autant faire tourner une stack entièrement séparée pour chaque partie de l’environnement d’un client.

Peut-on bénéficier de la résidence des données sans location unique ?

Oui. La résidence des données dépend de la région et du fournisseur dans lesquels une charge de travail s’exécute ; c’est une caractéristique de la couverture cloud de la plateforme plutôt que de son modèle de location. Une plateforme multicloud te permet de placer une charge de travail dans la région souhaitée sans avoir besoin d’une pile dédiée.

Upsun est-il mono-locataire ou multi-locataire ?

Aucune de ces deux étiquettes ne rend compte de la réalité. Upsun exécute chaque projet dans un isolement strict par défaut sur une infrastructure cloud partagée, et propose des clusters dédiés certifiés PCI pour les charges de travail qui nécessitent des ressources physiquement séparées. Concrètement, ça offre les garanties d’isolement, de résidence et de conformité dont une équipe soumise à une réglementation a besoin, au bon niveau pour chaque charge de travail.