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 rétablir en premier, dans quel ordre, en utilisant les points de reprise 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 un 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’était 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 sur l’état de préparation à la souveraineté numérique met directement en évidence : 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 ?
Une attaque par 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 :
- Du personnel de Recovery situé en dehors des limites de la souveraineté. Les ingénieurs qui connaissent les systèmes de Recovery peuvent opérer dans une juridiction différente. Sous pression, faire appel à eux est la solution la plus simple. C’est également une violation de la souveraineté au moment où il est le moins opportun d’en commettre une.
- Une 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 permettent de justifier la souveraineté d’un environnement face à un auditeur peuvent compliquer la reprise. Les restrictions de circulation des données, qui empêchent toute 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 de la restauration propre. Prouver que les points de restauration ne sont pas compromis avant de restaurer l’environnement de production – qu’ils soient non seulement récents, mais aussi intacts. Dans un scénario de rançongiciel, une sauvegarde récente peut elle-même être compromise. La capacité à identifier et à restaurer à partir d’un point de restauration dont l’intégrité est avérée, validée avant d’être utilisé, est une exigence de souveraineté, et pas seulement 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 fiable, 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 leur en fera la demande. Celles qui ne le font pas devront les constituer sous pression, devant les personnes qu’elles souhaitent le moins décevoir. Le rapport sur l’état de préparation à la souveraineté numérique comprend une question portant directement sur l’évaluation de l’architecture de reprise après sinistre.
FAQ
Q : Pourquoi la reprise après sinistre 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 contraintes juridiques et opérationnelles que celles utilisées pour les protéger.
Q : Quelles sont les défaillances courantes en matière de Recovery souveraine ?
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 gestion 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 de la Recovery « 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 en cas d’attaque par ransomware.
Q : Comment les organisations devraient-elles tester leur résilience en matière de souveraineté ?
R : Elles 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.
