Multi-tenant : un risque partagé – Les dangers cachés de l’hébergement cloud régional pour les données réglementées

Principaux enseignements

1. L’infrastructure partagée crée un destin commun. Les plateformes multi-tenant utilisent les mêmes bases de données, runtimes et systèmes d’exploitation pour des milliers de clients, en séparant les environnements uniquement par une logique logicielle, sans cloisonnement physique.
2. Une seule faille peut toucher tous les clients. Une vulnérabilité ou une mauvaise configuration dans la couche partagée peut exposer tous les clients de la plateforme, élargissant considérablement le périmètre d’impact au-delà du compte initialement concerné.
3. L’hébergement régional ne change rien au partage. Les labels de résidence des données ne modifient pas l’architecture multi-tenant sous-jacente, car les déploiements régionaux continuent généralement de partager bases de données et accès administratifs à l’échelle mondiale.
4. Le modèle single-tenant supprime le risque partagé. Des bases de données, runtimes et accès administrateur dédiés garantissent qu’une exposition chez un client ne peut pas se propager aux autres, éliminant ainsi le risque partagé au niveau de l’infrastructure.

Introduction

Une plateforme cloud multi-tenant héberge des milliers de clients sur les mêmes bases de données, runtimes applicatifs et systèmes d’exploitation, séparés uniquement par la logique logicielle, sans barrière physique. La plupart des entreprises acceptent ce compromis sans l’examiner en détail, car la multi-tenance est l’architecture par défaut de la quasi-totalité des solutions SaaS du marché.

Ce compromis porte un nom rarement mentionné dans le marketing des fournisseurs : le destin commun. Lorsque l’infrastructure est partagée, l’exposition l’est aussi. Une seule vulnérabilité exploitée, une autorisation mal configurée ou un identifiant compromis ne reste pas cantonné aux données d’un seul client. Elle peut toucher tous les clients présents sur la même couche partagée, quel que soit le pays d’hébergement du data center. Cet article analyse ce que la multi-tenance partage réellement sous le discours marketing des fournisseurs, et pourquoi les organisations réglementées doivent évaluer le modèle de tenance avec autant d’attention que la localisation.

Enseignement 1 : Les plateformes multi-tenant partagent bases de données, runtimes et systèmes d’exploitation entre des milliers de clients. La séparation entre les clients repose sur la logique logicielle, non sur une infrastructure physiquement distincte.

Enseignement 2 : Une seule vulnérabilité entre les clients peut exposer de nombreux clients en même temps. L’impact d’une faille multi-tenant s’étend à toutes les organisations partageant cette couche d’infrastructure.

Enseignement 3 : Un label d’hébergement régional ne supprime pas l’exposition multi-tenant. Les déploiements régionaux d’une plateforme mondiale partagent généralement toujours bases de données, consoles d’administration et accès support avec l’ensemble de l’opération du fournisseur.

Enseignement 4 : Les accès administratifs et support constituent une surface d’attaque cachée. Les fournisseurs multi-tenant conservent souvent un accès opérationnel permanent aux environnements clients, un point rarement examiné par les organisations réglementées.

Enseignement 5 : L’architecture single-tenant supprime le risque de destin commun au niveau de l’infrastructure. Des bases de données, systèmes de fichiers et runtimes dédiés empêchent qu’une exposition chez un client ne devienne une faille chez un autre.

Résumé exécutif

La multi-tenance est un modèle efficace pour un fournisseur cloud, mais concentre les risques pour ses clients. Des milliers d’organisations partagent les mêmes bases de données, runtimes et outils d’administration, si bien qu’une seule faille dans cette couche partagée peut avoir des conséquences bien au-delà du client où elle a été détectée. Pour les fonctions de gestion des risques et de conformité, cela signifie que le modèle de tenance mérite autant d’attention que le chiffrement, le contrôle d’accès ou la localisation physique. L’assurance d’un fournisseur selon laquelle les données sont « hébergées régionalement » ne dit rien sur le fait que la plateforme sous-jacente reste fondamentalement partagée. Comprendre où le partage a réellement lieu, et ce qu’il expose, est la première étape pour combler cette lacune.

Ce que la multi-tenance partage réellement en profondeur

Les fournisseurs cloud décrivent rarement la multi-tenance avec les termes utilisés par une équipe de gestion des risques. Leur discours met en avant l’élasticité, la maîtrise des coûts et la rapidité de mise à disposition. En réalité, un seul ensemble de bases de données, de runtimes applicatifs et de systèmes d’exploitation sert tous les clients de la plateforme en même temps, avec des frontières entre clients définies uniquement par logiciel.

La logique d’efficacité derrière le design multi-tenant

L’architecture multi-tenant existe car elle est réellement efficace pour le fournisseur. Une seule infrastructure sert de nombreux clients, ce qui réduit les coûts d’exploitation, simplifie la maintenance et permet une montée en charge rapide sans déployer des ressources dédiées pour chaque compte. C’est un choix commercial rationnel pour le fournisseur. Mais il faut se demander si cette logique d’efficacité répond aussi au profil de risque d’une organisation manipulant des données réglementées, et ne pas confondre les deux simplement parce que le modèle tarifaire du fournisseur en dépend.

Ce que change (ou pas) l’hébergement régional

Une option d’hébergement régional change généralement l’emplacement de stockage des données au repos — une question de résidence des données. Elle ne modifie pas l’architecture de la plateforme sous-jacente. La plupart des déploiements régionaux d’un produit multi-tenant mondial continuent d’utiliser des bases de données partagées, des runtimes applicatifs partagés et des consoles d’administration partagées à l’échelle de l’opération mondiale du fournisseur. Le label régional répond à une question géographique. Il ne répond pas à la question du partage, qui est celle qui détermine réellement l’exposition.

Comment l’infrastructure partagée devient un risque partagé

Concrètement, l’infrastructure partagée fait que les incidents de sécurité ne respectent pas les frontières entre clients comme les contrats le laissent entendre. Dès qu’un attaquant ou une mauvaise configuration atteint la couche partagée, l’exposition suit l’architecture, pas la structure des comptes.

Blast radius : quand une faille touche de nombreux clients

Dans un environnement single-tenant, une vulnérabilité dans l’instance d’un client reste, par définition, confinée à cette instance. Dans un environnement multi-tenant, une faille dans la couche base de données partagée, le runtime partagé ou la gestion des identités et des accès partagée peut potentiellement exposer tous les clients qui reposent sur cette couche au moment de l’attaque. De nombreux incidents de sécurité cloud multi-tenant rapportés publiquement ont démontré ce schéma, avec des failles dans les couches d’infrastructure partagées ayant un impact entre clients bien au-delà du compte initialement touché. Pour une organisation réglementée, cela change la question de « quelle est la probabilité d’une fuite de nos données » à « quelle est la probabilité d’une faille de la plateforme, et quelles en seraient les conséquences pour nous, indépendamment de notre propre posture de sécurité ».

Les accès administratifs et support comme surface d’attaque cachée

L’infrastructure partagée s’accompagne généralement d’outils d’administration partagés, ce qui signifie qu’une catégorie de personnes — qu’il s’agisse du personnel du fournisseur ou de systèmes automatisés opérant pour son compte — conserve un accès permanent à de nombreux environnements clients en même temps. Cet accès est rarement visible lors d’un audit de sécurité centré sur la configuration du client, car il se situe entièrement du côté du fournisseur. Une organisation qui évalue un fournisseur multi-tenant doit donc se demander non seulement comment ses propres données sont protégées, mais aussi qui d’autre, et quoi d’autre, dispose d’un accès permanent à la couche où résident ces données.

Pourquoi le modèle de tenance doit entrer dans le calcul du risque d’entreprise

Assimiler localisation et tenance conduit les équipes risques et conformité à valider un fournisseur après avoir vérifié le pays du data center, sans jamais se demander si ce data center sert un seul client ou des milliers. Les deux questions exigent des preuves différentes. La localisation se prouve par un contrat d’hébergement. La tenance se prouve par une documentation d’architecture montrant si les bases de données, systèmes de fichiers, runtimes et systèmes d’exploitation sont dédiés ou partagés, et si les accès administratifs et support sont limités à un client ou couvrent toute la plateforme du fournisseur. Intégrer le modèle de tenance dans l’évaluation des risques fournisseurs, au même titre que le chiffrement et le contrôle d’accès, comble une faille que l’analyse de la seule localisation laisse systématiquement ouverte.

Comment un data control plane supprime le risque de destin commun dans l’architecture

Éviter le risque de destin commun ne signifie pas qu’une organisation doit construire et exploiter sa propre infrastructure. Il s’agit de choisir une plateforme où l’isolation des clients est une propriété architecturale, et non une couche logicielle ajoutée sur des ressources partagées, et où la gouvernance des données sensibles s’applique systématiquement, quel que soit le canal par lequel ces données circulent. C’est ce que propose un data control plane : une couche de gouvernance couvrant tous les canaux de circulation des données — email, partage de fichiers, API, agents IA — qui définit qui peut accéder, envoyer, partager ou déplacer des données sensibles, dans quelles conditions, sur une infrastructure dont l’organisation contrôle elle-même les limites.

Kiteworks repose sur une architecture single-tenant par conception, sans partage de bases de données, systèmes de fichiers, runtimes applicatifs ou systèmes d’exploitation entre clients. Les organisations déploient sur leur propre infrastructure, que ce soit totalement sur site, en self-hosted dans leur cloud, ou en instance dédiée hébergée, et les accès administratifs et support à cette instance sont limités à ce client, sans s’étendre à une plateforme mondiale partagée. Sur cette base isolée, des contrôles zero trust pilotés par la donnée régissent chaque envoi, partage et accès, tous les événements étant consignés dans un journal d’audit infalsifiable et non limité, directement exploitable par les outils SIEM, offrant ainsi aux équipes sécurité et conformité des preuves concrètes d’application, plutôt qu’une simple assurance du fournisseur sur la partition de l’infrastructure partagée. Ainsi, la tenance devient un contrôle exercé par l’organisation, et non un risque hérité du modèle économique du fournisseur.

Les organisations qui souhaitent évaluer ce que l’architecture single-tenant peut apporter à leurs environnements réglementés peuvent reprendre le contrôle — et comparer un data control plane dédié à la plateforme qu’elles utilisent aujourd’hui.