Geofencing et résidence des données : prouver d’où l’on a accédé à vos données, et pas seulement où elles sont stockées

Les exigences de résidence sont généralement mises en œuvre comme une décision de stockage. Les régulateurs s’intéressent de plus en plus à une seconde question, à laquelle l’emplacement du stockage ne répond pas.

AuteurROOTKey
7 min de lectureConformité · Sécurité · Entreprises

Deux questions différentes

Lorsqu’une organisation affirme avoir réglé la question de la résidence des données, elle veut presque toujours dire une chose : les données sont stockées dans une région précise et la garantie régionale du fournisseur cloud les couvre. C’est un contrôle réel, et il répond à une vraie question.

Il ne répond pas à la seconde question, celle de savoir d’où l’on a accédé aux données. Un jeu de données peut se trouver entièrement dans une région de l’UE et être lu chaque jour par une équipe d’exploitation située dans un pays tiers, via un outil de support, une console partagée ou un identifiant d’accès d’urgence (break-glass). Rien dans l’emplacement du stockage ne l’empêche et, dans de nombreuses architectures, rien ne l’enregistre sous une forme que la fonction conformité puisse interroger.

Pour l’analyse des transferts au titre du RGPD, pour les régimes de localisation des données des pays du Golfe et, de plus en plus, pour les attentes des autorités de supervision propres à chaque secteur, c’est la question de l’accès qui détermine la réponse.

Pourquoi la question de l’accès devient plus difficile

Trois évolutions ont aggravé la situation ces dernières années, et aucune n’est une défaillance de sécurité.

Avec des équipes distribuées, les fonctions de support et d’ingénierie couvrent réellement plusieurs juridictions. Avec les services managés, le personnel d’un prestataire peut intervenir sur votre environnement depuis n’importe quel lieu où ce prestataire opère. Et avec les systèmes d’IA, les données sont de plus en plus lues par des processus dont le lieu d’exécution est un détail d’implémentation de la plateforme de quelqu’un d’autre.

Chacun de ces choix opérationnels est légitime. Ensemble, ils font que l’ensemble des lieux depuis lesquels vos données réglementées sont accessibles est plus large que celui que vous citeriez si on vous le demandait, et plus large que celui que décrivait votre analyse d’impact relative à la protection des données.

Appliquer et prouver sont deux problèmes distincts

Il s’agit ici de deux capacités distinctes, et les organisations en achètent souvent une en croyant avoir acheté les deux.

L’application (enforcement) signifie que le système refuse l’accès depuis des origines extérieures à un ensemble approuvé. Elle est préventive, elle se teste, et c’est ce que la plupart des gens entendent par geofencing.

La preuve signifie que vous pouvez démontrer, des mois plus tard, qu’aucun accès depuis des origines non approuvées n’a eu lieu, ou qu’il a eu lieu à des dates précises, pour des raisons précises qui étaient autorisées à ce moment-là. Elle est rétrospective, et c’est ce que demande réellement une autorité de supervision ou une autorité de protection des données.

L’application sans la preuve vous laisse affirmer qu’un contrôle a fonctionné. La preuve sans l’application vous laisse documenter un problème que vous n’avez pas empêché. Un programme de résidence a besoin des deux, et c’est en général la moitié « preuve » qui manque, car elle impose de conserver les enregistrements d’origine des accès pendant toute la période réglementaire, et non sur une fenêtre opérationnelle glissante.

Concevoir des contrôles de résidence qui produisent des preuves

  1. Définissez l’ensemble des origines approuvées par niveau de classification des données plutôt qu’à l’échelle de l’organisation - la plupart des organisations ont légitimement besoin d’un accès plus large aux données peu sensibles qu’aux données restreintes
  2. Enregistrez chaque tentative d’accès avec son origine et la décision appliquée, y compris les tentatives autorisées, car prouver une absence exige un enregistrement complet et non une liste d’exceptions
  3. Journalisez explicitement la procédure d’accès d’urgence (break-glass), avec la personne qui l’a autorisée et le motif, car un accès transfrontalier non planifié est un événement opérationnel normal et prétendre le contraire rend l’enregistrement moins crédible, pas plus
  4. Conservez les enregistrements d’origine pendant la période réglementaire applicable aux données sous-jacentes, et non pendant la durée de conservation par défaut de votre plateforme de journalisation
  5. Rendez l’enregistrement vérifiable de manière indépendante, car les preuves relatives à l’origine des accès sont précisément la catégorie qu’un régulateur a des raisons d’accueillir avec scepticisme lorsque l’organisation les produit sur elle-même

L’enjeu des pays du Golfe

Pour les organisations qui se développent aux Émirats arabes unis et en Arabie saoudite, la question de l’accès a souvent plus de conséquences que celle du stockage. Dans la région, les attentes en matière de localisation tendent à être formulées en termes de contrôle et de juridiction plutôt que de seul emplacement physique, et le test pratique qu’applique un régulateur porte souvent sur qui peut atteindre les données et depuis où, et pas seulement sur le centre de données qui les héberge.

Les organisations qui arrivent avec un discours sur la résidence fondé uniquement sur la région de stockage voient la conversation se déplacer vers un terrain auquel elles ne se sont pas préparées. Celles qui arrivent avec des preuves de l’origine des accès la voient avancer rapidement. Notre analyse par juridiction figure dans La PDPL des EAU et le cadre de risque cyber de l’ADGM et La PDPL saoudienne et la SDAIA.

  • Demandez à votre équipe d’où votre jeu de données le plus sensible a été consulté le mois dernier, et voyez combien de temps prend la réponse
  • Vérifiez si vos enregistrements d’accès incluent les tentatives autorisées ou seulement les tentatives bloquées
  • Comparez la durée de conservation des données d’origine des accès à l’obligation de conservation qui s’applique aux données elles-mêmes
  • Rattachez l’ensemble des origines approuvées au niveau de classification plutôt que d’appliquer une seule politique partout

Les règles d’accès fondées sur l’origine, avec une portée par niveau de classification et un enregistrement complet des tentatives autorisées et bloquées, sont dès à présent disponibles dans ROOTKey. Vous pouvez configurer une liste de pays autorisés sur un coffre et consulter la vue du trafic, ou découvrir comment les contrôles s’articulent sur la page ROOTKey consacrée au RGPD.

Partager LinkedIn X
Tous les articles

Restez informé

Recevez des analyses de
cyber-résilience dans votre boîte mail.

Des conseils pratiques et prêts pour l’audit sur l’intégrité des données, la conformité et la continuité, au fil de nos publications.