Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Points clés à retenir

• Les architectures souveraines privilégient souvent les audits et les contrôles d’accès au détriment de la préparation à la reprise après sinistre.
• Le personnel chargé de la reprise après sinistre, les systèmes de secours et les modèles de conservation des données clés peuvent entraîner des failles en matière de souveraineté lors d’incidents.
• Il est essentiel de mettre en place des contrôles cohérents entre les environnements de production et de reprise.
• Une résilience adaptée aux exigences de souveraineté nécessite des procédures de reprise testées dans des conditions réalistes.

Imaginez la situation. L’attaque a déjà eu lieu. L’équipe d’intervention en cas d’incident se met en place. Quelqu’un doit décider quels systèmes remettre en service en premier, dans quel ordre, en utilisant les points de restauration appropriés. C’est alors que quelqu’un se rend compte que le personnel ayant accès au système de reprise est basé dans un autre pays. Pire encore, l’environnement de reprise lui-même (hébergé dans une cloud , un centre de données partenaire ou un site secondaire) n’a jamais été soumis aux mêmes contrôles de souveraineté que les données principales.

Cette pratique n’est pas soumise aux mêmes contrôles de souveraineté que les données primaires. L’autorité de régulation demande des informations sur l’état d’avancement. Le temps presse. C’est le scénario pour lequel la plupart des architectures souveraines n’ont pas été conçues… et celui que le rapport le souligne clairement : la plupart des applications souveraines sont conçues pour l’audit, et non pour la gestion des incidents. La plupart des applications de sécurité sont conçues pour l’audit, et non pour la gestion des incidents. C’est au pire moment possible que cette différence se fait sentir.

L’angle mort de la relance dans l’architecture de la dette souveraine

Les programmes de souveraineté s’articulent autour du contrôle d’accès : qui peut accéder aux données, en vertu de quelle autorité, par quel chemin. Cette architecture est nécessaire. Elle n’est pas suffisante. Et elle est directement liée aux lacunes opérationnelles en matière de souverainetéabordées dans le troisième article de cette série :si les personnes qui gèrent votre environnement opèrent en dehors de vos limites de souveraineté, ce problème ne disparaît pas lors d’un incident. Il devient le problème.

Ce que le contrôle d’accès ne permet pas de résoudre, c’est la question la plus épineuse : que se passe-t-il après un incident, lorsque la reprise des activités n’est pas seulement une opération technique, mais aussi une procédure soumise à des contraintes juridiques ?

Ransomware visant une organisation européenne soumise à une réglementation ne se résume pas à un simple problème de restauration. Elle engendre un problème de restauration qui doit être résolu dans le cadre d’une juridiction donnée, par du personnel disposant des autorisations appropriées, à partir de points de restauration dont il peut être démontré qu’ils sont sains et n’ont pas été compromis. L’architecture souveraine conçue pour protéger les données peut compliquer la restauration si la résilience n’a pas été intégrée dès la conception initiale.

Les modes de défaillance spécifiques

Les causes d’échec des architectures de reprise souveraines sont prévisibles – et courantes :

• Recovery personnel hors des frontières territoriales. Les ingénieurs qui maîtrisent les systèmes de Recovery peuvent intervenir dans une autre juridiction. En situation de pression, faire appel à eux est la solution la plus simple. Il s’agit également d’une violation de la souveraineté, précisément au moment où cela est le moins opportun.
• Infrastructure de sauvegarde dépourvue de contrôles adaptés. Les environnements souverains principaux font l’objet d’un contrôle rigoureux. L’infrastructure de sauvegarde — en particulier les environnements plus anciens ou secondaires — n’est souvent pas soumise aux mêmes exigences en matière de souveraineté. Si les points de restauration sont stockés ou traités en dehors du périmètre, il n’est pas possible d’effectuer une restauration conforme à partir d’une infrastructure conforme.
• La gestion des clés en situation de crise. Les dispositifs de gestion des clés par les utilisateurs eux-mêmes sont conçus pour un fonctionnement normal. En situation de crise – lorsque les systèmes principaux sont compromis et que le temps presse –, le modèle de gestion des clés qui fonctionne pendant une fenêtre de maintenance de routine peut devenir un obstacle à la reprise des activités. Si ce modèle n’a pas été testé, il s’agit d’une hypothèse, et non d’un dispositif de contrôle.
• Lacunes de gouvernance entre les environnements. Les organisations opérant à plusieurs niveaux de souveraineté – c’est-à-dire la plupart d’entre elles – disposent souvent de contrôles rigoureux dans leurs environnements principaux, mais de contrôles moins stricts dans leurs environnements secondaires, qui font pourtant également partie du chemin de reprise. Les auditeurs s’attacheront à vérifier la cohérence sur l’ensemble du parc informatique. C’est précisément lorsque cette cohérence est la plus importante que les lacunes dans les environnements secondaires apparaissent au grand jour.

Pourquoi les contrôles de souveraineté peuvent compliquer la reprise

Les mêmes contrôles qui rendent un environnement souverain défendable face à un auditeur peuvent rendre la reprise plus difficile. Les restrictions de circulation des données qui empêchent l’exfiltration non autorisée limitent également l’orchestration de la reprise. Les accords de conservation clés qui garantissent qu’aucun fournisseur ne puisse accéder à vos données sans autorisation ajoutent également des frictions lorsque vous devez effectuer une restauration rapide.

Cela ne signifie pas pour autant que ces contrôles soient inadaptés. Cela signifie simplement qu’ils doivent être conçus dès le départ en tenant compte de la reprise après sinistre, et non pas ajoutés à une architecture où la reprise après sinistre n’a été envisagée qu’après coup. C’est là le cœur du principe de « souveraineté minimale viable » : l’adaptation des contrôles aux besoins réels inclut les exigences en matière de reprise après sinistre, et pas seulement celles relatives au contrôle d’accès.

Ce qu’implique une résilience adaptée à la souveraineté

• Validation des points de récupération propres. Prouver que les points de restauration ne sont pas compromis avant leur restauration en environnement de production — non seulement qu’ils sont récents, mais aussi qu’ils ne sont pas compromis. Dans le cas d’une attaque par ransomware, une sauvegarde récente peut elle-même être compromise. La capacité à identifier et à restaurer à partir d’un point de restauration dont la propreté est avérée, validé avant même d’être nécessaire, relève d’une exigence de souveraineté, et pas seulement d’une exigence de reprise après sinistre.
• Gouvernance inter-environnements. Des contrôles de souveraineté et des preuves d’audit cohérents sur l’ensemble du parc informatique – et pas seulement au niveau du déploiement souverain principal. Chaque environnement du chemin de reprise doit répondre aux mêmes exigences que l’environnement principal.
• Testé dans des conditions réalistes. Des exercices réguliers qui valident la reprise d’activité dans les conditions qui prévaudront réellement lors d’un incident : les contraintes juridiques applicables, le personnel disponible, les points de reprise d’activité opérationnels. Un test annuel de reprise après sinistre qui ne tient pas compte des contraintes liées à la souveraineté n’est pas un exercice adapté à la souveraineté.

La question à ajouter à votre bilan de souveraineté

Il existe un moyen simple de vérifier si votre architecture de reprise répond aux mêmes exigences de souveraineté que votre environnement de données principal : posez la question et exigez une réponse honnête. Êtes-vous en mesure de récupérer vos données souveraines, de manière propre, dans les limites de tolérance définies, en faisant appel à du personnel opérant à l’intérieur de vos frontières souveraines, dès maintenant – dans des conditions réelles, et non pas dans le cadre d’un exercice contrôlé ?

Pour la plupart des organisations, une réponse honnête met en évidence une lacune. Celles qui l’identifient dès maintenant – avant qu’un incident ne se produise – seront les mieux préparées à fournir des preuves lorsque l’autorité de régulation les leur demandera. Celles qui ne le font pas devront les constituer sous pression, devant les personnes qu’elles souhaitent le moins décevoir. Lerapportcomprend une question portant directement sur l’évaluation de l’architecture de reprise après sinistre.

FAQ

Q : Pourquoi la récupération est-elle importante pour la souveraineté numérique ?

R : La souveraineté est incomplète si les organisations ne peuvent pas récupérer les données dans le cadre des mêmes limites juridiques et opérationnelles que celles utilisées pour les protéger.

Q : Quelles sont les causes courantes d’échec des procédures de Recovery souverain ?

R : Parmi les défaillances courantes, on peut citer le fait que le personnel chargé de la reprise après sinistre opère en dehors des limites territoriales, l’absence de contrôles adaptés au niveau des infrastructures de secours, ainsi qu’une gouvernance incohérente d’un environnement à l’autre.

Q : En quoi la garde des clés peut-elle compliquer la Recovery ?

R : Les modèles de gestion autonome des clés renforcent la sécurité en conditions normales d’exploitation, mais ils peuvent ralentir les opérations de reprise en cas d’incident s’ils ne sont pas correctement testés.

Q : Qu’est-ce que la validation d’une récupération « propre » ?

R : La validation de la restauration « Clean Recovery » permet de s’assurer que les points de restauration n’ont pas été compromis avant la restauration des systèmes. Cela revêt une importance particulière dans ransomware .

Q : Comment les organisations devraient-elles tester leur résilience en matière de souveraineté ?

R : Ils devraient mener des exercices réalistes tenant compte des contraintes juridiques, de la disponibilité opérationnelle et des points de reprise validés – et pas seulement des tests standard de reprise après sinistre.

Alex Zinin est vice-président et directeur général de la division « Fournisseurs de services gérés » chez Commvault.