3 Un stockage partagé qui sert plusieurs unités métier ou clients exige une isolation forte. L’isolation du stockage multi-locataire (en anglais) n’est pas une option supplémentaire : elle est fondamentale. Elle détermine si une infrastructure partagée contient les menaces ou les propage à tous les locataires. Pour les RSSI et les architectes sécurité qui évaluent un stockage objet en environnement multi-locataire, la question clé est simple : votre couche de stockage peut-elle imposer des frontières strictes entre locataires ? Un poste compromis, un administrateur malveillant ou une vulnérabilité applicative chez un locataire ne doit pas permettre d’atteindre les données d’un autre. Un échec de mise en œuvre se paie en amendes réglementaires, en perte de clients et en incidents qui remontent jusqu’au conseil d’administration. Cet article explique ce que signifie l’isolation, comment fonctionne une isolation forte dans une infrastructure partagée et ce que votre équipe sécurité doit exiger lors de l’évaluation des solutions de stockage. Comprendre le risque multi-locataire et le rayon d’impact Une infrastructure partagée présente de réels avantages opérationnels : efficacité économique, gestion centralisée, audit simplifié. Mais le partage introduit un risque critique : une seule compromission peut affecter tous les locataires de l’organisation ou tous les clients. Prenons un serveur d’application compromis dans une unité métier. Une isolation correcte contient cette compromission. L’attaquant ne peut pas rebondir vers le stockage des autres locataires, lire leurs données ni remonter jusqu’à l’infrastructure sous-jacente. Sans isolation, la compromission tourne au désastre : accès immédiat à toutes les données des locataires, à toute la propriété intellectuelle des unités métier et aux données clients. La prévention exige des mécanismes techniques : politiques, frontières d’espaces de noms, contrôles cryptographiques et application des accès, à la fois robustes et vérifiables. Votre architecture de sécurité doit répondre à trois questions essentielles : Pouvez-vous garantir l’isolation des espaces de noms ? Les locataires doivent être isolés logiquement et physiquement, de sorte qu’aucun ne puisse voir l’espace de noms d’un autre, même avec des identifiants d’administrateur. Cela va au-delà du nommage des buckets : il s’agit de savoir si le système de stockage sous-jacent impose des frontières strictes. Mettre en œuvre la gestion des identités et des accès (en anglais) au niveau de la couche de stockage garantit des frontières robustes. Les contrôles d’accès sont-ils appliqués au niveau du stockage ? Appliquez les contrôles au niveau de la couche de stockage elle-même, et non dans un middleware applicatif. Une application au niveau applicatif peut être contournée ; au niveau du stockage, non. Pouvez-vous vérifier l’isolation de manière indépendante ? Les équipes d’audit et de conformité doivent pouvoir vérifier que l’isolation est réelle. Cela exige des pistes d’audit, des preuves cryptographiques et la démonstration qu’une violation n’en a pas affecté d’autres. Faire de l’isolation des espaces de noms la première ligne de défense L’isolation du stockage multi-locataire commence par la séparation des espaces de noms. Un espace de noms est le conteneur logique — bucket, conteneur ou hiérarchie d’objets — qui héberge les données d’un locataire. Une isolation forte des espaces de noms empêche un locataire de découvrir, lire ou écrire dans l’espace de noms d’un autre, même avec des identifiants de stockage sous-jacents. Il ne s’agit pas d’une simple réponse « accès refusé », mais d’une propriété architecturale qui rend la requête structurellement invalide aux frontières de l’isolation. De nombreux systèmes mettent en œuvre l’isolation des espaces de noms au niveau de l’API ou du compte, ce qui convient aux déploiements mono-locataires ou faiblement isolés. Pour les architectures multi-locataires d’entreprise qui servent des clients externes, appliquez l’isolation au niveau du moteur de stockage. L’isolation persiste ainsi quelle que soit la compromission des identifiants. Concevez-la ainsi : liez chaque espace de noms, de manière cryptographique ou logique, à l’identité du locataire. Ne traitez pas l’accès à un espace de noms comme un privilège réattribuable. Traitez l’identité de l’espace de noms comme indissociable de celle du locataire. Mettre en œuvre des contrôles d’accès en couches Une fois l’isolation des espaces de noms en place, ajoutez de la granularité aux contrôles d’accès. Les contrôles au niveau du bucket appliquent les politiques : qui peut lire, écrire, supprimer et modifier les autorisations. De nombreux incidents ne viennent pas d’un accès non autorisé initial, mais d’une accumulation excessive d’autorisations. Un compte de développeur obtient légitimement un accès en lecture-écriture. Ces autorisations ne sont jamais revues ni révoquées. Des mois plus tard, le compte est compromis, et l’attaquant dispose des droits de lecture, d’écriture, de suppression et de modification des autorisations. Votre architecture doit appliquer le moindre privilège de manière granulaire. Un compte de service qui écrit des données de sauvegarde ne doit pas pouvoir supprimer. Les comptes d’administrateur ne doivent pas disposer d’un accès global à tous les locataires. Limitez les autorisations à des buckets et à des actions précis. Adopter une architecture zero trust (en anglais) renforce encore les frontières. Les contrôles au niveau de l’objet ajoutent une couche supplémentaire. Certaines architectures exigent des autorisations par objet, permettant à un locataire de partager des objets précis avec un autre. Si c’est nécessaire, appliquez-les de manière cryptographique. Les locataires ne doivent pas pouvoir forger des autorisations : celles-ci doivent être vérifiables et révocables. Vos contrôles ne valent que ce que vaut votre gestion des identifiants. Des identifiants de longue durée, largement diffusés ou insuffisamment surveillés affaiblissent les contrôles. Traitez le cycle de vie des identifiants comme un enjeu de sécurité critique. Recourir à la séparation cryptographique pour des garanties applicables L’isolation logique par les espaces de noms et les contrôles d’accès suffit pour certains déploiements. Pour d’autres — en particulier les données réglementées ou les clients externes bénéficiant de garanties contractuelles d’isolation — la séparation cryptographique ajoute une garantie applicable. Dans les architectures à séparation cryptographique, les données de chaque locataire sont chiffrées avec des clés uniques. Le système de stockage est partagé, mais pas les clés de chiffrement. Ainsi, même en cas d’accès physique ou de compromission de la couche de stockage, les données restent inintelligibles sans la clé du locataire. La séparation cryptographique exige plusieurs éléments architecturaux. Gérez les clés séparément du stockage, à l’aide d’un service centralisé de gestion des clés. Journalisez et auditez les accès aux clés. Imposez leur rotation. La compromission du système de gestion des clés devient une compromission multi-locataire : le KMS lui-même doit donc respecter les mêmes principes d’isolation que le stockage. L’avantage : la séparation cryptographique est vérifiable de manière indépendante. Vous pouvez démontrer aux auditeurs, aux équipes de conformité et aux clients que leurs données sont chiffrées avec des clés qu’ils contrôlent. Le système de stockage ne peut pas les déchiffrer sans ces clés. Cela offre une assurance que l’isolation logique seule ne peut égaler. Surveiller l’isolation en continu grâce à l’audit L’isolation multi-locataire doit être vérifiée et auditée en continu. La journalisation d’audit n’est pas qu’une case à cocher pour la conformité : c’est un mécanisme de sécurité qui détecte les violations des frontières d’isolation. Capturez les accès à l’infrastructure partagée avec une granularité permettant de déterminer si un locataire a accédé à l’espace de noms d’un autre. Il ne s’agit pas d’une revue des journaux a posteriori, mais d’un flux d’événements en temps réel que votre équipe sécurité surveille. Les anomalies — accès d’un locataire à des objets hors de son espace de noms, usage inhabituel d’identifiants, modifications d’autorisations — doivent déclencher des alertes. La vérification de la conformité inclut des tests d’isolation indépendants et périodiques. Votre équipe sécurité doit régulièrement vérifier que des identifiants de locataire compromis ne permettent pas d’accéder aux données des autres, que la suppression d’objets dans un espace de noms n’affecte pas les autres et que les identifiants d’administrateur ne permettent pas de contourner les contrôles d’isolation. Évaluer soigneusement les solutions de stockage Lorsque vous choisissez une solution de stockage multi-locataire, testez explicitement ses propriétés d’isolation. Exigez des livres blancs et une documentation d’architecture décrivant la manière dont l’isolation est appliquée. Demandez comment les identifiants sont délimités et s’ils peuvent être révoqués indépendamment. Évaluez la prise en charge de l’isolation cryptographique et si la gestion des clés est découplée du stockage. Testez directement les contrôles d’accès : des identifiants compromis peuvent-ils accéder à des données non autorisées ? Pouvez-vous vérifier l’isolation grâce aux journaux d’audit ? Surtout, évaluez l’historique de sécurité. Si des violations de l’isolation se sont produites, comprenez comment, et vérifiez si des changements d’architecture les empêchent désormais. Bâtir une architecture multi-locataire en toute confiance L’isolation multi-locataire est atteignable, mais elle exige une architecture délibérée et une vérification continue. Votre posture de sécurité dépend de votre compréhension de la manière dont l’isolation est mise en œuvre, maintenue et vérifiée. Les infrastructures multi-locataires les plus fiables sont celles où les RSSI et les architectes stockage définissent les exigences d’isolation dès le premier jour, et où les équipes sécurité maintiennent la discipline d’un audit continu. Ce n’est pas une mise en œuvre ponctuelle, mais un engagement durable à préserver les frontières dans une infrastructure partagée. De solides pratiques de chiffrement des données (en anglais) complètent l’isolation et assurent une défense en profondeur. Traitez l’isolation non comme une amélioration facultative, mais comme une propriété de sécurité fondamentale. Elle détermine si votre infrastructure partagée contient les menaces ou les démultiplie. Cette distinction façonne en profondeur la gestion des risques de l’organisation. Pour aller plus loin Le chiffrement AES pour la sécurité des données d’entreprise (en anglais) Qu’est-ce que le SIEM ? (en anglais) Authentification multifacteur (MFA) (en anglais) Le modèle de responsabilité partagée (en anglais) Qu’est-ce que le NIST Cybersecurity Framework ? (en anglais) Bonnes pratiques de souveraineté des données (en anglais) Exigences du RGPD en matière de stockage des données (en anglais)
