RGPD et HDS sur Azure : résidence, transferts, santé

Ce que le RGPD exige réellement d’une architecture

L’essentiel du règlement relève de la gouvernance. Une poignée d’articles retombe directement sur le parc.

Article 25, protection des données dès la conception et par défaut. La seconde moitié est la plus exigeante : les réglages par défaut doivent être les plus restrictifs, en collecte, en conservation et en accès, sauf décision explicite de les élargir. Dans un parc Azure, cela signifie que le jeu de politiques est le défaut, et non la procédure d’exception.

Article 30, registre des traitements. Activités, finalités, catégories, destinataires, transferts, durées de conservation. Il ne peut être exact sans un inventaire réel, et un registre inexact est la première chose qu’une autorité de contrôle remarque.

Article 32, sécurité du traitement. Pseudonymisation et chiffrement, confidentialité, intégrité, disponibilité et résilience, capacité à rétablir l’accès dans des délais appropriés, et une procédure pour tester et évaluer régulièrement l’efficacité des mesures. Cette dernière clause est une obligation, et c’est celle dont presque personne ne garde de trace.

Articles 33 et 34, notification. 72 heures à l’autorité de contrôle à compter de la prise de connaissance. La question d’architecture est le temps que prend cette prise de connaissance.

Articles 15, 17 et 20. Accès, effacement et portabilité, chacun avec un délai, chacun exigeant un chemin à travers tous les systèmes qui détiennent la donnée, sauvegardes et copies analytiques comprises.

Chapitre V, transferts. Adéquation, clauses contractuelles types, et une analyse d’impact du transfert lorsque le régime juridique de destination compte. Le Canada bénéficie d’une décision d’adéquation partielle visant les organisations commerciales assujetties à la LPRPDE, ce qui simplifie beaucoup de montages sans rien retirer à l’article 32.

Article 28, sous-traitants. Autorisation des sous-traitants ultérieurs et chaîne documentée. Concrètement, cela suppose de connaître chaque service qui touche la donnée, ce qui ramène à l’inventaire.

Ce que nous concevons et imposons dans Azure

La région comme politique héritée. Une assignation de régions autorisées au groupe d’administration, couvrant les régions européennes ou les régions françaises précises lorsque la portée santé l’exige. Toute souscription future en hérite, et la procédure d’exception est visible.

La frontière des données de l’Union, configurée et comprise. Nous activons ce qu’elle couvre et nous écrivons ce qu’elle ne couvre pas, plutôt que de la traiter comme une réponse générale. Un engagement que vous ne savez pas décrire précisément n’est pas un engagement défendable devant une autorité de contrôle.

Les quatre choses qui cassent réellement la résidence. Les paramètres de diagnostic acheminés vers un espace Log Analytics dans une autre région. La supervision ou la billetterie hors Union. Les chemins de support et d’administration. Et les déploiements de modèles : un type de déploiement global peut traiter l’invite là où la capacité existe, donc pour une charge de travail européenne le type de déploiement est une décision de résidence, pas une note de bas de page.

Un chiffrement dont vous maîtrisez l’histoire des clés. Chiffrement de plateforme comme base, clés gérées par le client dans Key Vault ou Managed HSM lorsque vous devez détenir la clé, rotation documentée, et minimums TLS imposés par politique.

Aucun chemin public, et l’identité comme point de contrôle. Points de terminaison privés sur les services de données et d’IA, zones DNS privées, cloisonnement hub-and-spoke comme décrit sur la page landing zone Azure, Microsoft Entra ID avec accès conditionnel et Privileged Identity Management, et revues d’accès planifiées.

Effacement, export et rétention comme procédures testées. Rétention par catégorie, règles de cycle de vie sur le stockage, un chemin d’export produisant un format structuré pour une personne donnée, et un chemin de suppression exécuté en test, y compris contre les sauvegardes.

Le test de restauration comme mesure de l’article 32. Politiques de sauvegarde en code, objectifs de reprise écrits, restaurations planifiées et consignées, parce que le règlement demande la capacité de rétablir dans des délais appropriés et la preuve que vous la testez.

Une détection calibrée sur 72 heures. Microsoft Defender for Cloud pour la posture, des règles Microsoft Sentinel sur l’exfiltration et les accès anormaux, et un chemin d’escalade nommant qui évalue le risque et qui saisit l’autorité.

Ce que vous gardez

• Le dossier d’intrants du registre des traitements : flux, catégories, destinataires, régions, rétention.
• Un dossier d’intrants d’analyse de transfert, incluant les décisions de région et de type de déploiement, et leur justification.
• Le jeu de politiques en code, assignation de régions comprise, dans votre dépôt.
• Des runbooks testés d’effacement, d’export et de restauration.
• L’analyse écrite du périmètre HDS, pour que la question soit réglée avant qu’un client la pose.

Pour qui ce n’est pas

Nous ne sommes pas hébergeur certifié HDS, nous n’hébergeons pas, et nous n’émettons aucun certificat. Nous n’agissons pas comme votre délégué à la protection des données, et nous ne sommes pas avocats : les analyses de transfert et les analyses d’impact sont signées par des personnes imputables chez vous. Si vos renseignements personnels sont québécois sans rattachement européen, c’est la page Loi 25 qui s’applique, et la question du transfert s’y règle autrement.