3 L’architecture data mesh promet des bénéfices séduisants : donner aux équipes métier la propriété de leurs données, accélérer l’analytique et s’affranchir des plateformes de données monolithiques. Mais pour les responsables de la sécurité en entreprise, le data mesh soulève des défis qui empêchent les RSSI de dormir : comment appliquer des politiques de sécurité cohérentes, conserver la visibilité sur la conformité et garantir la résilience des données lorsque la propriété est volontairement décentralisée ? L’infrastructure de stockage qui sous-tend un data mesh n’est plus un périmètre unique et défendable. Votre organisation exploite désormais plusieurs domaines de données autonomes, chacun avec son propre stockage, sa stratégie de sauvegarde et ses contrôles d’accès. Cette architecture distribuée crée ce que nous appelons une « surface de risque distribuée » : des failles de sécurité qui ne naissent pas des défaillances d’un domaine isolé, mais des interstices entre les domaines. Comprendre la résilience et la sécurité du stockage dans un data mesh est essentiel pour les RSSI et les architectes sécurité qui évaluent ou déploient des architectures de données fédérées. Cet article examine les défis de stockage propres au data mesh, la manière de maintenir une gouvernance de sécurité cohérente entre les domaines, et les stratégies de sauvegarde et de reprise après sinistre qui fonctionnent réellement à grande échelle. La réalité du stockage en data mesh : la décentralisation face à la complexité de la gouvernance L’architecture data mesh confie la propriété des données aux domaines métier au lieu de la centraliser dans un data lake monolithique. Chaque domaine gère ses propres produits de données, ses métadonnées et souvent sa propre infrastructure de stockage. En théorie, cela accélère la prise de décision et réduit les goulots d’étranglement. En pratique, cela multiplie les défis de sécurité et de résilience. Prenons une société de services financiers qui déploie un data mesh dans ses différentes activités : banque de détail, gestion de patrimoine, salle des marchés et conformité. Chaque domaine gère des données clients, des historiques de transactions et des jeux de données analytiques. Au lieu d’une politique de sauvegarde et d’une norme de chiffrement uniques, vous avez désormais quatre systèmes de stockage autonomes (ou plus), chacun avec des configurations de sécurité, des fréquences de sauvegarde et des procédures de restauration potentiellement différentes. Pour un RSSI, les questions sont immédiates : comment auditer les contrôles d’accès entre domaines sans transformer la vie des équipes en cauchemar de surveillance ? Comment s’assurer que les données de sauvegarde, souvent situées hors du périmètre de sécurité principal, conservent le même niveau de conformité que la production ? Comment restaurer des produits de données compromis au-delà des frontières entre domaines, alors que les playbooks de réponse aux incidents supposaient une infrastructure centralisée ? Le problème de fond : le data mesh troque la simplicité opérationnelle contre la flexibilité architecturale. Les bénéfices en matière de sécurité et de résilience doivent être conçus délibérément ; ils ne découlent pas naturellement de la décentralisation. La surface de risque distribuée : là où la sécurité du data mesh se fissure La propriété décentralisée crée des failles de sécurité à trois niveaux critiques : Lignage des données et contrôle d’accès entre domaines. Dans un data lake centralisé, vous auditez qui a accédé à quoi et quand grâce à un système de journalisation unifié. Dans un data mesh, les produits de données franchissent les frontières entre domaines. Le domaine A produit des données consommées par le domaine B, qui les enrichit pour le domaine C. Sans suivi explicite du lignage ni politiques d’accès fédérées, vous perdez la visibilité sur l’usage final de vos données sensibles. Une équipe peut accorder l’accès à un produit de données sans comprendre comment il sera consommé en aval, ni la posture de sécurité des domaines consommateurs. Une gouvernance incohérente de la sauvegarde et de la restauration. Chaque domaine maîtrise sa propre stratégie de sauvegarde. L’un met en place des snapshots quotidiens avec des copies de sauvegarde immuable ; un autre effectue des sauvegardes hebdomadaires avec des copies modifiables. Lorsque les chaînes de dépendance entre domaines sont profondes, la reprise après un incident dans un domaine amont peut exiger une restauration coordonnée de plusieurs domaines. Mais si ces domaines n’ont pas d’objectifs RTO/RPO coordonnés, le temps moyen de restauration s’allonge dangereusement. Si un ransomware franchit les frontières entre domaines, des politiques de sauvegarde incohérentes signifient que certains domaines seront irrécupérables tandis que d’autres seront épargnés. Des pratiques divergentes de chiffrement et de gestion des clés. Chaque domaine prend ses propres décisions en matière de chiffrement au repos, de chiffrement en transit et de gestion des clés. L’un impose le chiffrement AES-256 et une gestion centralisée des clés ; un autre s’en remet aux paramètres par défaut du fournisseur cloud. Si une équipe est compromise ou si un système de stockage est attaqué, les attaquants prennent pied dans les systèmes les moins bien chiffrés, ce qui peut leur permettre un déplacement latéral vers des domaines plus sensibles. Ces failles ne viennent pas d’une incompétence, mais de la séparation délibérée des responsabilités qu’exige le data mesh. Les équipes de domaine se concentrent à juste titre sur leurs résultats métier, et non sur le maintien d’invariants de sécurité à l’échelle de l’entreprise. C’est à la fonction RSSI de combler cet écart. Appliquer des politiques de sécurité cohérentes entre les domaines de données La solution n’est pas de tout recentraliser, ce qui irait à l’encontre de l’objectif du data mesh. Il vous faut plutôt un modèle de gouvernance fédérée qui applique des invariants de sécurité sans entraver l’autonomie des domaines. Définissez et appliquez des socles de sécurité non négociables. Fixez des garde-fous que tous les domaines doivent respecter : normes de chiffrement minimales (AES-256 au repos et en transit), MFA obligatoire pour l’accès administrateur, copies de sauvegarde immuables et objectifs RTO/RPO maximaux acceptables. Ces socles ne sont pas des suggestions : ce sont des prérequis pour participer au mesh. Automatisez leur application grâce à des modèles d’infrastructure-as-code et à des moteurs policy-as-code qui empêchent le provisionnement de configurations non conformes. Mettez en place une politique fédérée d’identité et d’accès. Utilisez un fournisseur d’identité centralisé (Okta, Azure AD ou équivalent) avec des politiques de contrôle d’accès basé sur les attributs (ABAC) couvrant tous les domaines. Plutôt que de gérer les accès domaine par domaine, définissez des politiques qui tiennent compte de la sensibilité des données (niveau de classification), de l’identité du consommateur et de la justification métier. Lorsqu’un utilisateur du domaine B demande l’accès à un produit de données du domaine A, le moteur de règles évalue la demande au regard des politiques de sécurité de l’entreprise, et pas seulement de la politique locale du domaine A. Journalisez toutes les décisions d’accès, acceptations comme refus, dans une piste d’audit centralisée. Des pratiques solides de gestion des identités et des accès (en anglais) à l’échelle de l’ensemble empêchent les silos de domaine de créer des failles de contrôle d’accès. Créez un comité fédéré de gouvernance des sauvegardes. Réunissez les responsables infrastructure et sécurité de chaque domaine ainsi que votre équipe centrale de sauvegarde et de reprise après sinistre. Fixez des objectifs RTO/RPO communs selon les niveaux de classification des données. Définissez la gestion des dépendances entre domaines dans les scénarios de restauration. Créez des modèles d’infrastructure de sauvegarde et de tests de restauration que tous les domaines utilisent. Il ne s’agit pas de contrôle centralisé, mais d’autonomie coordonnée. Imposez des copies de sauvegarde immuables dans tous les domaines. Exigez que chaque domaine conserve des copies de sauvegarde immuables sur un stockage WORM (écriture unique, lectures multiples) ou avec une immuabilité temporelle. Cela protège contre les ransomwares qui tentent de supprimer les sauvegardes et garantit qu’aucun domaine compromis ne peut détruire les points de restauration des autres. Les sauvegardes immuables doivent être stockées séparément des données de production et gérées avec des contrôles d’accès distincts. La gouvernance des sauvegardes dans un mesh : responsabilité distribuée, visibilité unifiée Dans un environnement data mesh, la sauvegarde doit concilier l’autonomie des domaines et la résilience à l’échelle de l’entreprise. Votre approche doit comporter trois niveaux : Sauvegarde et restauration locales au domaine. Chaque domaine dispose d’une infrastructure de sauvegarde suffisante pour restaurer ses propres produits de données. Les équipes de domaine sont responsables de leurs objectifs RTO/RPO, de leurs procédures de validation des sauvegardes et de leurs tests de restauration. Cela préserve la rapidité et l’agilité qu’apporte le data mesh. Dépendances de sauvegarde entre domaines. Lorsque des produits de données dépendent de plusieurs domaines, organisez une coordination explicite des sauvegardes. Si le produit de données du domaine A est indispensable à la restauration du domaine B, les deux domaines doivent s’aligner sur la fréquence et la durée de rétention des sauvegardes. Établissez une cartographie des dépendances indiquant quels domaines sont critiques pour la restauration des autres, et utilisez-la pour orienter les stratégies de sauvegarde. Piste d’audit et conformité centralisées des sauvegardes. Maintenez un système centralisé qui collecte les métadonnées de sauvegarde de tous les domaines (horodatage, statut d’achèvement, date d’expiration de la rétention, résultats des tests de restauration) et les stocke dans un journal immuable. Il ne s’agit pas des données de sauvegarde elles-mêmes, mais de métadonnées prouvant que la gouvernance des sauvegardes est respectée. Auditez ces métadonnées chaque mois pour vérifier que tous les domaines tiennent leurs engagements, et utilisez-les comme preuve de diligence lors des audits de conformité. Protéger une infrastructure de données fédérée contre les menaces Trois menaces spécifiques méritent une attention particulière dans un environnement data mesh : Les attaques par déplacement latéral. Si un attaquant compromet un domaine dont la posture de sécurité est faible, il peut rebondir vers d’autres domaines via une infrastructure partagée (systèmes de messagerie, réseaux de calcul) ou grâce aux identifiants obtenus lors de la compromission initiale. Limitez ce risque en imposant une segmentation réseau stricte, en exigeant une nouvelle authentification pour les opérations entre domaines et en surveillant les accès anormaux aux données au-delà des frontières entre domaines. Les attaques de la chaîne d’approvisionnement visant les produits de données. Si le domaine A produit des données consommées par le domaine B et qu’un attaquant compromet le domaine A, il peut injecter des données malveillantes dans la chaîne. Intégrez une validation de l’intégrité des données dans le pipeline de consommation. Le domaine B doit vérifier les sommes de contrôle ou les signatures cryptographiques des produits de données avant de les consommer, et déclencher une alerte en cas de modification inattendue. L’adoption du stockage objet pour les produits de données permet une vérification cryptographique de l’intégrité au-delà des frontières entre domaines. Les ransomwares qui s’étendent à plusieurs domaines. Les ransomwares modernes cherchent à maximiser leur impact en ciblant plusieurs systèmes. Dans un data mesh, un attaquant peut compromettre l’infrastructure d’un domaine, puis tenter de se déplacer latéralement pour chiffrer le stockage ou les systèmes de sauvegarde d’autres domaines. Protégez-vous en conservant des copies de sauvegarde hors ligne inaccessibles depuis tout système connecté au réseau, en limitant l’accès à l’infrastructure de sauvegarde à un nombre minimal d’opérateurs et en mettant en place des sauvegardes immuables que les attaquants ne peuvent ni supprimer ni chiffrer, même avec des identifiants valides. Ce que votre organisation doit faire dès maintenant Si votre organisation déploie ou exploite un data mesh, votre fonction RSSI doit : Définir des socles de sécurité non négociables pour les domaines de données : normes de chiffrement, exigences de contrôle d’accès, immuabilité des sauvegardes et journalisation d’audit. Intégrez-les à la spécification d’architecture des domaines. Mettre en place une gouvernance fédérée, et non un contrôle centralisé. Créez un comité de sécurité réunissant des représentants de chaque domaine et votre équipe sécurité centrale. Prenez les décisions de gouvernance collectivement, et non de manière descendante. Exiger des sauvegardes immuables dans tous les domaines. C’est votre dernière ligne de défense contre les ransomwares et les suppressions non autorisées. Investissez dans des systèmes de stockage prenant en charge nativement le WORM ou l’immuabilité temporelle. Les exigences de stockage des données au titre du RGPD (en anglais) imposent souvent des copies immuables pour la conformité, ce qui en fait une responsabilité partagée entre les domaines. Mettre en place un audit centralisé des métadonnées de sauvegarde. Collectez la preuve que tous les domaines exécutent leurs procédures de sauvegarde et réussissent leurs restaurations. Utilisez-la comme preuve de conformité et comme système d’alerte précoce en cas de défaillance des sauvegardes. Préparer la réponse aux incidents entre domaines. Vos playbooks doivent prendre en compte les incidents touchant plusieurs domaines. Organisez des exercices sur table associant les équipes de domaine et votre équipe centrale de réponse. Identifiez les défaillances de domaine ayant le plus fort impact métier et priorisez les procédures de restauration pour ces chemins critiques. Le data mesh permet à votre organisation d’aller plus vite et de responsabiliser les équipes métier. Mais une architecture distribuée implique une responsabilité distribuée en matière de résilience et de sécurité. En définissant des socles clairs, une gouvernance fédérée et des pratiques de sauvegarde coordonnées, vous pouvez tirer parti du data mesh sans multiplier votre risque opérationnel. Les investissements consacrés à l’immuabilité des sauvegardes et à des pistes d’audit unifiées porteront leurs fruits en matière de sécurité comme de conformité. Votre avantage concurrentiel ne vient pas du seul choix d’architecture, mais de la discipline et de la visibilité avec lesquelles vous la mettez en œuvre. Commencez dès maintenant. Pour aller plus loin Stockage immuable et défense contre les ransomwares (en anglais) Stratégie de sauvegarde d’entreprise (en anglais) Protéger ses sauvegardes contre les ransomwares : des sauvegardes immuables et restaurables (en anglais) Bonnes pratiques de gestion des identités et des accès (IAM) (en anglais) RTO ou RPO : les principales différences (en anglais) L’architecture zero trust (en anglais) DRaaS : la reprise après sinistre en tant que service (en anglais)
