Risque des sauvegardes des fournisseurs

Un fournisseur de services de paie a subi une violation que les enquêteurs ont fait remonter à un compartiment de sauvegarde Amazon S3. Le compartiment contenait une sauvegarde complète de la base de données datant de quatorze mois, soit une copie intégrale des dossiers de paie des employés, des informations fiscales et des coordonnées bancaires de tous les clients. La base de données de production bénéficiait de contrôles solides : chiffrée avec des clés gérées par le client, accessible uniquement par une couche applicative dotée d’un accès fondé sur les rôles, journalisée à des fins d’audit et revue chaque trimestre. Le compartiment de sauvegarde avait été créé par un ingénieur d’infrastructure lors d’un exercice trimestriel de vérification des sauvegardes. La politique du compartiment avait été configurée pour autoriser l’accès depuis le rôle IAM de l’ingénieur, qui disposait d’un large accès à l’infrastructure. L’ingénieur avait quitté l’organisation six mois plus tôt. Son rôle IAM avait été désactivé pour l’accès à la production, mais la politique du compartiment référençait directement ce rôle et n’avait jamais été mise à jour. Une analyse des erreurs de configuration menée par un chercheur en sécurité a révélé que le contenu du compartiment pouvait être listé publiquement en raison d’une configuration ACL distincte, appliquée par erreur et jamais corrigée. La base de données de production était sécurisée. La sauvegarde était une copie vieille de quatorze mois des mêmes données, accessible en raison d’une erreur de configuration présente depuis que l’ingénieur l’avait mise en place.

Qu’est-ce que le problème du risque lié aux données de sauvegarde des fournisseurs, concrètement ?

Les données de sauvegarde contiennent les mêmes informations que les données de production au moment où la sauvegarde a été effectuée. Elles présentent la même sensibilité, la même classification réglementaire et les mêmes implications en matière de notification des violations en cas d’exposition. Ce qui leur manque généralement, c’est la continuité de gouvernance dont bénéficient les données de production : les revues d’accès, la rotation des clés, les audits d’autorisations et la surveillance de la sécurité appliqués aux systèmes de production par des processus opérationnels qui n’ont jamais été étendus à l’infrastructure de sauvegarde. Les sauvegardes sont créées par des processus opérationnels. Elles sont gouvernées par des processus qui, souvent, n’ont jamais existé.

Le problème de dégradation de la gouvernance est structurel et dépend du temps. Une sauvegarde créée il y a dix-huit mois a été configurée avec les contrôles d’accès, les clés de chiffrement et les politiques de stockage appropriés à ce moment-là. Depuis, le paysage des accès de l’organisation a changé : des employés sont partis, des rôles ont été restructurés, des politiques de rotation des clés ont été appliquées à la production mais pas aux sauvegardes historiques, et des configurations de politiques de stockage correctes lors de la création peuvent ne plus convenir au modèle de menace actuel. Les contrôles de la base de données de production sont maintenus en continu. Ceux de la sauvegarde reflètent un instantané de la posture de gouvernance au moment de sa création, et rien ne les a mis à jour depuis.

Le volume de données de sauvegarde dans l’environnement d’un fournisseur d’entreprise type est bien plus important que ne le laisse supposer l’empreinte de production. Un fournisseur entretenant une relation client depuis trois ans peut détenir des sauvegardes quotidiennes remontant à plusieurs mois, des sauvegardes hebdomadaires remontant à un an, des sauvegardes mensuelles remontant à plusieurs années et des sauvegardes trimestrielles de vérification du DR à différents moments de la relation. Chaque sauvegarde contient l’intégralité des données du client à un instant donné. Chacune a sa propre configuration de stockage, ses propres contrôles d’accès et sa propre clé de chiffrement. La base de données de production est un système gouverné. Le parc de sauvegardes représente des dizaines de copies réparties sur plusieurs emplacements de stockage, chacune dotée d’une gouvernance qui reflète ce qui a été configuré lors de sa création et qui n’a peut-être jamais été revue.

Le risque lié aux données de sauvegarde des fournisseurs se concentre autour de cinq schémas précis de défaillance de la gouvernance :

• Dérive des contrôles d’accès au stockage des sauvegardes : rôles IAM, politiques des compartiments de stockage et identifiants d’accès configurés lors de la création des sauvegardes et jamais réexaminés au regard des besoins d’accès actuels
• Lacunes dans la gestion des clés de chiffrement : données de sauvegarde chiffrées avec des clés retirées de l’usage en production mais toujours appliquées aux sauvegardes historiques, ce qui crée un cycle de vie des clés distinct qui n’est pas maintenu selon la gouvernance des clés de production
• Mauvaise configuration du stockage des sauvegardes : compartiments de stockage cloud ou référentiels de sauvegarde dotés de politiques trop permissives, d’une accessibilité publique ou d’un accès intercomptes non voulu et jamais corrigé
• Défaillances des politiques de conservation : sauvegardes conservées au-delà des durées de conservation définies en raison de défaillances des processus manuels ou de l’absence de suppression automatisée, ce qui accumule une exposition des données historiques
• Chiffrement des sauvegardes au repos ou en transit : sauvegardes chiffrées au repos dans le stockage, mais transmises en clair lors de leur création, des tests de restauration ou des transferts entre emplacements de stockage

Pourquoi c’est important

Le risque lié aux données de sauvegarde des fournisseurs est important pour le TPRM, car les systèmes de sauvegarde constituent le principal point d’accumulation de données historiques dans l’environnement d’un fournisseur : ils conservent des copies de données clients remontant à plusieurs années, avec une gouvernance qui reflète l’état de l’organisation au moment de la création de chaque sauvegarde plutôt que les normes de sécurité actuelles. Une violation du système de sauvegarde d’un fournisseur peut exposer un ensemble de données plus volumineux et plus ancien que n’importe quelle violation en production, car les sauvegardes s’accumulent au fil du temps sans la gouvernance de minimisation et de conservation des données appliquée aux systèmes de production.

La difficulté forensique et réglementaire est aggravée par le caractère historique des données de sauvegarde. Lorsqu’une violation de sauvegarde est découverte, le périmètre de la notification doit décrire les données que contenait la sauvegarde, ce qui peut exiger de reconstituer l’état de la base de données au moment de la sauvegarde, des mois ou des années auparavant. Des enregistrements supprimés depuis de la production peuvent figurer dans des sauvegardes historiques. Des enregistrements ayant fait l’objet de demandes d’effacement peuvent exister dans des sauvegardes créées avant l’exécution de l’effacement. La sauvegarde contient les données telles qu’elles existaient à un moment antérieur à la posture de gouvernance actuelle, y compris, le cas échéant, des données que le fournisseur ne détient plus en production et dont il ignore peut-être même la présence dans les sauvegardes.

Pour les praticiens TPRM, la préoccupation précise est de savoir si le programme de gouvernance des sauvegardes du fournisseur couvre l’ensemble du parc de sauvegardes (non seulement la sauvegarde la plus récente, mais l’intégralité des archives conservées) avec la même rigueur que la gouvernance des données de production. La base de données de production est la partie visible de l’iceberg de la sécurité des données. Le parc de sauvegardes en constitue le reste.

Là où la plupart des équipes se trompent

La défaillance la plus constante consiste à évaluer la sécurité des sauvegardes comme une capacité de continuité d’activité plutôt que comme une capacité de sécurité des données. Les évaluations des sauvegardes portent généralement sur le RTO et le RPO, le chiffrement des données de sauvegarde et la fréquence des tests de sauvegarde, autant de questions de résilience opérationnelle. Elles interrogent rarement sur les contrôles d’accès au stockage des sauvegardes, la gestion du cycle de vie des clés de chiffrement des données de sauvegarde, la gouvernance de la conservation des sauvegardes ou la question de savoir si les contrôles d’accès aux sauvegardes historiques reflètent les besoins d’accès actuels. Les questions de résilience et les questions de sécurité relèvent d’évaluations différentes, et la plupart des programmes TPRM mènent la première sans la seconde.

La deuxième défaillance consiste à considérer la confirmation du chiffrement des sauvegardes comme équivalente à la gouvernance de la sécurité des sauvegardes. Les sauvegardes chiffrées au repos dans le stockage cloud sont protégées contre un accès direct au stockage : la mauvaise configuration de la politique du compartiment S3 dans le scénario d’introduction a exposé les métadonnées de sauvegarde qui ont permis la découverte, après quoi il aurait fallu venir à bout du chiffrement. Mais le chiffrement des sauvegardes ne traite ni la dérive des contrôles d’accès, ni les lacunes dans la rotation des clés, ni les défaillances des politiques de conservation, autres dimensions de la sécurité des sauvegardes aux conséquences tout aussi importantes.

• Considérer la sécurité des sauvegardes comme équivalente à leur maturité opérationnelle : évaluation de la résilience ou évaluation de la sécurité des données
• Contrôles d’accès aux sauvegardes historiques jamais revus : rôles IAM et politiques de stockage configurés lors de la création et jamais mis à jour
• Cycle de vie des clés de chiffrement des sauvegardes non évalué : la rotation des clés de production n’est pas appliquée aux clés de chiffrement des sauvegardes historiques
• Gouvernance de la conservation des sauvegardes non vérifiée : des sauvegardes s’accumulent au-delà des durées de conservation définies en raison de défaillances des processus
• Mauvaise configuration du stockage des sauvegardes non évaluée : les politiques des compartiments et les configurations d’accès ne sont pas examinées pour détecter des paramètres trop permissifs

À quoi ressemblent les bonnes pratiques

Les programmes matures de sécurité des sauvegardes appliquent aux données de sauvegarde les mêmes normes de gouvernance qu’aux données de production, notamment la revue des accès, la gestion des clés de chiffrement, l’application des durées de conservation et la surveillance de la sécurité. Le parc de sauvegardes est inventorié, les contrôles d’accès sont revus à la même fréquence que les accès de production, et les politiques de conservation sont appliquées par une suppression automatisée plutôt que par des processus manuels.

• Revues des contrôles d’accès aux sauvegardes à la fréquence de la production : autorisations d’accès au stockage des sauvegardes revues chaque trimestre, conformément au calendrier des revues d’accès de production
• Gestion du cycle de vie des clés de chiffrement des sauvegardes : rotation des clés de chiffrement des sauvegardes selon le même calendrier que les clés de production, ou rechiffrement des sauvegardes lors de la rotation des clés de production
• Application automatisée des durées de conservation sur le stockage des sauvegardes : suppression des sauvegardes déclenchée automatiquement à l’expiration de la durée de conservation, sans dépendre d’un processus manuel
• Analyse de sécurité du stockage des sauvegardes : analyse régulière des erreurs de configuration du stockage des sauvegardes à la recherche de politiques trop permissives, d’une accessibilité publique et de chemins d’accès non autorisés
• Inventaire des sauvegardes tenu à jour : tous les emplacements de stockage des sauvegardes sont documentés avec leurs contrôles d’accès, la référence de la clé de chiffrement et l’état de conservation

Outils

La gouvernance des données de sauvegarde exige à la fois les outils opérationnels de sauvegarde et les outils de gouvernance de la sécurité appliqués au stockage où se trouvent les sauvegardes.

Sécurité du stockage cloud : AWS S3 Security Hub, Azure Policy, GCP Security Command Center

Les outils de gestion de la posture de sécurité du cloud analysent en continu les configurations de stockage cloud à la recherche de problèmes de sécurité, en identifiant les politiques de compartiment trop permissives, l’accessibilité publique, les accès intercomptes et les paramètres de chiffrement mal configurés. AWS Security Hub assure une évaluation automatisée des configurations des compartiments S3 au regard des bonnes pratiques de sécurité. Pour les praticiens TPRM, demander si le fournisseur analyse régulièrement les configurations de son stockage de sauvegardes à la recherche d’erreurs permet de savoir si l’erreur de politique de compartiment à l’origine du scénario d’introduction serait détectée avant d’être exploitée.

Gestion des clés pour le chiffrement des sauvegardes : AWS KMS, Azure Key Vault

Les services KMS cloud permettent une gestion distincte des clés pour les données de sauvegarde, avec des calendriers de rotation, des politiques d’accès et une journalisation d’audit différents pour les clés de chiffrement des sauvegardes et pour les clés de production. Pour les praticiens TPRM, demander si le fournisseur gère les clés de chiffrement des sauvegardes séparément des clés de production, avec leur propre calendrier de rotation, permet de savoir si la gouvernance des clés de chiffrement s’étend au parc de sauvegardes.

Gouvernance des données de sauvegarde : Cohesity DataHawk, Rubrik Security Cloud

Les plateformes modernes de protection des données comme Cohesity et Rubrik offrent des fonctionnalités de gouvernance de la sécurité des données de sauvegarde, notamment la gestion des contrôles d’accès, la détection des anomalies dans les schémas d’accès aux sauvegardes et des rapports de conformité pour les données de sauvegarde. Ces plateformes traitent les données de sauvegarde comme un patrimoine de données gouverné plutôt que comme une simple capacité opérationnelle. Pour les praticiens TPRM, demander si le fournisseur utilise une plateforme moderne de protection des données dotée de fonctionnalités de gouvernance de la sécurité permet de savoir si la sécurité des sauvegardes a été rendue opérationnelle ou laissée à une gestion d’infrastructure improvisée.

Enjeux de gouvernance

La difficulté de gouvernance des données de sauvegarde tient au vide de responsabilité. Les systèmes de sauvegarde relèvent généralement des équipes d’infrastructure ou d’exploitation, dont la responsabilité première porte sur la disponibilité et la capacité de restauration : veiller à ce que les sauvegardes soient créées, stockées de manière fiable et restaurables en cas de besoin. La gouvernance de la sécurité des données (contrôles d’accès, rotation des clés, application des durées de conservation) relève des équipes de sécurité et de gouvernance des données. Dans la plupart des organisations, les processus de gouvernance de l’équipe de sécurité couvrent les systèmes de production et n’atteignent pas l’infrastructure de sauvegarde gérée par les équipes d’exploitation, ce qui crée un parc de production gouverné et un parc de sauvegarde non gouverné pour les mêmes données sous-jacentes.

Combler cette lacune exige d’inclure explicitement le stockage des sauvegardes dans les programmes de gouvernance de la sécurité des données, en étendant à l’infrastructure de sauvegarde la fréquence des revues d’accès, la gestion des clés de chiffrement et l’analyse de sécurité, avec la même responsabilité organisationnelle que pour les systèmes de production. Ce lien fait généralement défaut, et l’établir exige à la fois des changements de processus et un alignement organisationnel entre les équipes d’exploitation et de sécurité que la plupart des programmes TPRM ne peuvent pas impulser de l’extérieur, mais qu’ils peuvent rendre visibles grâce à des questions d’évaluation ciblées.

• Interroger précisément sur la fréquence des revues des contrôles d’accès aux sauvegardes : quand l’accès au stockage des sauvegardes a été revu pour la dernière fois, et pas seulement si l’accès de production est revu
• Interroger sur la rotation des clés de chiffrement des données de sauvegarde, distincte de la rotation des clés de production et appliquée aux sauvegardes historiques
• Exiger une application automatisée des durées de conservation : suppression déclenchée par la politique de conservation, et non par un processus manuel
• Interroger sur l’analyse de sécurité du stockage des sauvegardes : détection des erreurs de configuration appliquée au stockage des sauvegardes selon un calendrier régulier
• Inclure l’infrastructure de sauvegarde dans le périmètre de l’évaluation de sécurité, sans l’exclure au titre d’infrastructure opérationnelle

Si vous êtes une petite équipe

Posez à vos fournisseurs les plus à risque deux questions que la plupart des évaluations n’abordent jamais. Premièrement : quand la politique d’accès à votre stockage de sauvegardes a-t-elle été revue pour la dernière fois, et la configuration d’accès actuelle reflète-t-elle les besoins actuels des rôles ? Plus précisément, d’anciens employés ou des rôles obsolètes ont-ils accès au stockage des sauvegardes ? Deuxièmement : les clés de chiffrement des sauvegardes font-elles l’objet d’une rotation selon le même calendrier que les clés de chiffrement de production, ou les sauvegardes historiques conservent-elles les clés utilisées lors de leur création ? Ces deux questions mettent au jour la dérive des contrôles d’accès et les lacunes de gestion des clés qui donnent lieu aux scénarios de violation des sauvegardes.

• Demander quand les politiques d’accès au stockage des sauvegardes ont été revues pour la dernière fois
• Demander si d’anciens employés ou des rôles obsolètes ont accès au stockage des sauvegardes
• Interroger sur la rotation des clés de chiffrement des sauvegardes historiques
• Demander si l’analyse des erreurs de configuration couvre le stockage des sauvegardes

Ce qu’il faut exiger

Demandez directement :

« Quand les contrôles d’accès à votre stockage de sauvegardes ont-ils été revus pour la dernière fois, et des rôles IAM, des comptes de service ou des utilisateurs ayant accès aux sauvegardes appartiennent-ils à d’anciens employés ou à des fonctions obsolètes ? »

« Les clés de chiffrement des sauvegardes font-elles l’objet d’une rotation selon le même calendrier que les clés de chiffrement de production et, lorsque les clés de production changent, les sauvegardes historiques sont-elles rechiffrées avec les nouvelles clés ou conservent-elles les clés d’origine ? »

« Votre stockage de sauvegardes est-il inclus dans votre analyse régulière des erreurs de configuration, et quel est le constat le plus récent concernant les autorisations d’accès au stockage des sauvegardes ? »

Preuves attendues

• Historique des revues d’accès aux sauvegardes : date de la dernière revue et population actuelle disposant d’un accès
• Cycle de vie des clés de chiffrement des sauvegardes : calendrier de rotation et politique de rechiffrement des sauvegardes historiques
• Historique des analyses de sécurité du stockage des sauvegardes : analyse la plus récente et constats éventuels
• Confirmation de l’application automatisée des durées de conservation

Un fournisseur qui répond à la question sur la revue des accès aux sauvegardes par « nos sauvegardes sont chiffrées » a confirmé une fois de plus le chiffrement. Demandez précisément quand les politiques des compartiments de stockage, ou les configurations d’accès équivalentes, ont été revues pour la dernière fois au regard des besoins actuels des rôles. Le chiffrement protège ce qui se trouve dans le compartiment. La politique d’accès détermine qui peut l’ouvrir.

Comment le prouver

La sécurité des données de sauvegarde est abordée à l’article 32 du GDPR dans le cadre des mesures techniques et organisationnelles appropriées, dans l’exigence 9 et l’exigence 10 de la norme PCI-DSS pour la sécurité des supports de sauvegarde, et dans les mesures de protection techniques de la loi HIPAA pour la sauvegarde des PHI. Démontrer la diligence requise exige de prouver que la gouvernance de la sécurité des sauvegardes a été évaluée au-delà de la capacité opérationnelle de sauvegarde.

• Dossiers d’évaluation des fournisseurs consignant les questions sur le contrôle d’accès aux sauvegardes, la gestion des clés et la gouvernance de la conservation
• Preuves d’analyse de sécurité du stockage des sauvegardes
• Historique des revues d’accès pour l’infrastructure de sauvegarde
• Confirmation de l’automatisation de l’application des durées de conservation

À retenir

La sauvegarde, ce sont vos données de production. Elle présente la même sensibilité, la même classification réglementaire et les mêmes implications en matière de notification des violations. Ce qui lui manque, c’est la gouvernance continue dont bénéficient les données de production : les revues d’accès, les rotations de clés, les audits d’autorisations et les analyses de sécurité qui maintiennent les contrôles de production à jour. Une sauvegarde créée il y a dix-huit mois possède les contrôles d’accès, les clés de chiffrement et les politiques de stockage appropriés il y a dix-huit mois. Rien ne les a mis à jour depuis. Le scénario de violation de la base de production exige de compromettre une infrastructure bien gouvernée. Le scénario de violation des sauvegardes exige de trouver le compartiment de stockage configuré par un ingénieur parti il y a six mois, dont les politiques n’ont jamais été revues. Les données sont les mêmes. La gouvernance, non.