Domaine de sécurité : gestion des données Sécurité et confidentialité

Ce domaine de sécurité est conçu pour garantir que toutes les données consommées à partir de Microsoft 365 sont protégées de manière adéquate, tant en transit qu’au repos. Ce domaine garantit également que les préoccupations des consommateurs (personnes concernées) en matière de confidentialité sont satisfaites par l’ISV, conformément au RGPD (Règlement général sur la protection des données) et à l’HIPAA (Health Insurance Portability and Accountability Act de 1996).

Données en transit

Les exigences de connectivité des applications/compléments développés par Microsoft 365 nécessitent une communication sur les réseaux publics, en particulier Internet. Par conséquent, les données en transit doivent être protégées de manière appropriée. Cette section couvre la protection des communications de données sur Internet. 

Commande n° 1

ÉCHEC DUR

Fournir la preuve que :

• Toutes les configurations TLS sont TLS1.2 ou supérieure, comme indiqué dans les exigences de configuration du profil TLS. 

• Un inventaire des clés et certificats fiables est conservé et mis à jour.

Configuration requise pour les profils

Intention : TLS

L’objectif de ce sous-point est de garantir que les données Microsoft 365 consommées par votre organisation sont transmises en toute sécurité. La configuration du profil TLS sert à définir les exigences spécifiques au protocole TLS pour garantir la sécurité du trafic contre les attaques d’intercepteur. 

Directives : TLS

Le moyen le plus simple de le prouver est d’exécuter l’outil de test du serveur SSL Qualys sur TOUS les écouteurs Web, y compris ceux qui fonctionnent sur des ports non standard. 

N’oubliez pas de cocher l’option « Ne pas afficher les résultats sur les tableaux », ce qui empêche l’ajout de l’URL au site web. 

Les exigences de configuration du profil TLS peuvent être démontrées en fournissant la preuve de vérifications individuelles. Pour fournir la preuve de paramètres spécifiques, tels que la désactivation de la compression TLS, les paramètres de configuration, les scripts et les outils logiciels peuvent être utilisés. 

Exemple de preuve : TLS

La capture d’écran suivante montre les résultats de l’analyse SSL par Qualys pour le byendbagh6a0fcav.z01.azurefd.net webappfrontdoor. 

La section Protocoles indique que TLS1.2 est le seul protocole pris en charge/activé.

Remarque : Les analystes de certification examineront les résultats complets de l’analyse pour confirmer que toutes les exigences de configuration du profil TLS sont satisfaites. Nous nous attendons à ce que des analyses soient fournies pour tous les points de terminaison exposés publiquement (adresses IP et URL) à l’environnement principal concerné. En fonction des preuves fournies, les analystes peuvent effectuer leur propre analyse Qualys. 

Exemple de preuve : TLS

La capture d’écran suivante montre les paramètres de configuration de TLS dans Azure App Service, suivis de l’énumération TLS via PowerShell. 

Intention : clés et certificats

L’objectif de ce sous-point est de garantir la tenue à jour d’un inventaire complet des clés et des certificats approuvés, ce qui implique l’identification des différents systèmes, services et applications qui dépendent de ces éléments de chiffrement. 

Recommandations : clés et certificats

Les preuves doivent démontrer qu’un inventaire des clés et des certificats de confiance existe et est maintenu. En outre, des preuves applicables des outils utilisés pour stocker les clés et les certificats réels peuvent être fournies, telles que le coffre de clés Azure, les secrets du coffre HashiCorp, Confluence Cloud, etc. 

Exemple de preuve : clés et certificats

La capture d’écran suivante montre qu’un inventaire de clé et de certificat est conservé dans Confluence Cloud. 

La capture d’écran suivante montre la liste approuvée des clés et certificats approuvés. Il inclut des détails tels que le certificat, les clés, les chiffres et les systèmes sur lesquels ils sont installés. 

La capture d’écran suivante provient de HashiCorp Vault. Les certificats qui sont décrits et enregistrés dans la liste d’inventaire sont stockés dans ce coffre-fort en ligne. HashiCorp Vault est un outil open source pour la gestion des secrets, le chiffrement en tant que service et la gestion des accès privilégiés.

La capture d’écran suivante est un extrait du certificat réel et des clés stockées dans le coffre-fort en ligne.

Remarque : On s’attend à ce que l’emplacement de stockage des clés dispose de contrôles d’accès appropriés. Si la clé privée est compromise, quelqu’un peut usurper le serveur avec un certificat légitime. 

Exemple de preuve : clés et certificats

La capture d’écran suivante montre un exemple de preuve de certificats stockés dans Azure KeyVault.  

Exemple de preuve : clés et certificats

Un inventaire des clés et certificats de confiance peut également être conservé avec Microsoft 365 Defender, qui propose une fonction d’inventaire, comme illustré dans la capture d’écran suivante.

La capture d’écran suivante présente les détails du certificat.

Remarque : Ces exemples ne sont pas des captures d’écran en plein écran, vous devrez soumettre des captures d’écran en plein écran avec n’importe quelle URL, l’utilisateur connecté et l’heure et la date pour l’examen des preuves. Si vous êtes un utilisateur Linux, vous pouvez le faire via l’invite de commandes. 

Commande n° 2

Fournir la preuve que :

La compression TLS est désactivée pour tous les services publics traitant les requêtes web afin d’éviter la fuite d’informations sur le taux de compression simplifiée (CRIME). 

TLS HTTP Strict Transport Security (HSTS) est activé et configuré sur un âge minimum de 180 jours sur tous les sites. 

Intention : TLS

L’attaque CRIME (CVE-2012-4929)) est une vulnérabilité dans la compression des protocoles SSL (Secure Sockets Layer)/TLS (Transport Layer Security). C’est pourquoi le secteur recommande de désactiver la compression SSL. 

HTTP Strict Transport Security (HSTS) est un mécanisme de sécurité conçu pour protéger les sites web contre les attaques de l’intercepteur en forçant les connexions TLS au moyen d’un champ d’en-tête de réponse HTTPS appelé « Strict-Transport-Security ». 

Directives : TLS

Cela peut être mis en évidence par l’outil Qualys SSL Labs. Exemple de preuve : TLS

La capture d’écran suivante montre que la compression SSL/TLS est désactivée. 

La capture d’écran suivante montre que HSTS est activé.

Remarque : L’analyste de certification examinera la sortie complète pour confirmer que toutes les exigences des exigences de configuration du profil TLS sont satisfaites (veuillez fournir des captures d’écran de la sortie de l’analyse complète). En fonction des preuves fournies, les analystes peuvent effectuer leur propre analyse Qualys. 

Les autres outils qui peuvent être utilisés pour case activée que HSTS est activé sont « HTTP Header Spy » et

securityheaders.com comme illustré dans les exemples suivants. Preuves supplémentaires

Des captures d’écran telles que les paramètres de configuration des en-têtes de sécurité, en particulier HSTS, peuvent être fournies pour illustrer davantage la posture de sécurité de l’empreinte publique. 

Les captures d’écran suivantes montrent la configuration d’Azure Front Door et l’ensemble de règles implémenté pour la réécriture des en-têtes. 

La capture d’écran suivante montre l’analyse des en-têtes de sécurité effectuée et que tous les en-têtes de sécurité sont implémentés, pas seulement HSTS.

Remarque : si Qualys SSL Scanner ou des en-têtes de sécurité sont utilisés, on s’attend à ce que le rapport complet soit fourni pour examen. 

Données au repos

Lorsque les données consommées à partir de la plateforme Microsoft 365 sont stockées par des éditeurs de logiciels indépendants, les données doivent être protégées de manière appropriée. Cette section décrit les exigences de protection des données stockées dans les bases de données et les magasins de fichiers. 

Commande n° 3

ÉCHEC DUR

Fournir la preuve que :

Les données au repos sont chiffrées conformément aux exigences du profil de chiffrement, à l’aide d’algorithmes de chiffrement tels que ; Advanced Encryption Standard (AES), Blowfish et XChaCha20. 

Tailles de clé de chiffrement d’au moins 128 bits. 

Exigences relatives au profil de chiffrement 

Intention : Certains algorithmes de chiffrement plus anciens sont connus pour contenir des faiblesses cryptographiques, ce qui augmente les chances qu’un acteur malveillant puisse déchiffrer les données sans connaître la clé. Pour cette raison, l’objectif de ce contrôle est de s’assurer que seuls les algorithmes de chiffrement acceptés par l’industrie sont utilisés pour protéger les données M365 stockées. 

Lignes directrices : Les preuves peuvent être fournies au moyen de captures d’écran, montrant le cryptage utilisé pour protéger les données M365 dans les bases de données et autres emplacements de stockage. Les preuves doivent démontrer que la configuration du chiffrement est conforme aux exigences de configuration du profil de chiffrement de la certification Microsoft 365. 

Exemple de preuve : la capture d’écran suivante montre que le chiffrement TDE (Transparent Data Encryption) est activé sur la base de données Contoso. La deuxième capture d’écran montre la page de documentation Microsoft Chiffrement de données transparent pour SQL Database, SQL Managed Instance et Azure Synapse Analytics montrant que le chiffrement AES 256 est utilisé pour Azure TDE. 

Remarque : dans les exemples précédents, aucune capture d’écran complète n’a été utilisée, mais TOUTES les captures d’écran des preuves soumises par l’ISV doivent être des captures d’écran complètes montrant l’URL, l’utilisateur connecté et l’heure et la date du système. 

Exemple de preuve : la capture d’écran suivante montre Stockage Azure configuré avec le chiffrement pour les blobs et les fichiers. La capture d’écran suivante montre la page de documentation Microsoft Chiffrement Stockage Azure pour les données au repos, montrant que Stockage Azure utilise AES-256 pour le chiffrement. 

Conservation des données, sauvegarde et destruction

Lorsque les éditeurs de logiciels indépendants consomment et stockent des données Microsoft 365, il existe un risque de compromission des données si un acteur malveillant compromet l’environnement des éditeurs de logiciels indépendants. Pour minimiser ce risque, les organisations ne doivent conserver que les données dont elles ont besoin pour fournir des services et non les données qui « pourraient » être utiles à l’avenir. En outre, les données ne doivent être conservées que le temps nécessaire pour fournir les services pour lesquels les données ont été capturées. La conservation des données doit être définie et communiquée aux utilisateurs. Une fois que les données dépassent la période de conservation définie, elles doivent être supprimées de manière sécurisée afin qu’elles ne puissent pas être reconstruites ou récupérées. 

Commande n° 4

Fournir la preuve que :

Une période de conservation des données approuvée est formellement établie et documentée. 

Objectif : Une politique de conservation documentée et suivie est importante non seulement pour respecter certaines obligations légales, par exemple la législation sur la confidentialité des données telles que, mais sans s’y limiter, le Règlement général sur la protection des données (RGPD de l’UE) et la Loi sur la protection des données (DPA du Royaume-Uni 2018), mais aussi pour limiter les risques d’une organisation. En comprenant les besoins en données de l’organisation et le temps nécessaire aux données nécessaires à l’entreprise pour remplir ses fonctions, les organisations peuvent s’assurer que les données sont correctement éliminées une fois leur utilité expirée. En réduisant les volumes de données stockées, les organisations réduisent la quantité de données qui seraient exposées en cas de compromission des données. Cela limitera l’impact global. 

Souvent, les organisations stockent des données parce qu’elles les ont au cas où. Cependant, si l’organisation n’a pas besoin des données pour exécuter son service ou sa fonction commerciale, les données ne doivent pas être stockées car cela augmente inutilement le risque de l’organisation. 

L’objectif de ce contrôle est de confirmer que l’organisation a officiellement établi et documenté une période de conservation des données approuvée pour tous les types de données pertinents. Il s’agit non seulement de spécifier la durée pendant laquelle les différents types de données seront stockés, mais aussi de décrire les procédures de suppression ou d’archivage des données après leur expiration.  

Lignes directrices : Fournir la politique de conservation complète des données qui détaille clairement la durée pendant laquelle les données (doivent couvrir tous les types de données) doivent être conservées afin que l’entreprise puisse exécuter ses fonctions commerciales. La politique de rétention doit clairement couvrir toutes les données client stockées dans l’environnement backend de l’application en cours de certification. 

Exemple de preuve : la capture d’écran suivante montre la stratégie de rétention des données de Contoso. 

Remarque : ces captures d’écran montrent un instantané d’un document de stratégie/processus. On s’attend à ce que les éditeurs de logiciels indépendants partagent la documentation réelle des politiques/procédures de soutien et ne fournissent pas simplement une capture d’écran. 

Contrôle n° 5

Fournir la preuve que :

Les données ne sont conservées que pendant la période de conservation définie, comme indiqué dans le contrôle 4. 

Intention : L’objectif de ce contrôle est de valider simplement le respect des périodes de conservation des données définies. Comme nous l’avons déjà mentionné, les organisations peuvent avoir l’obligation légale de respecter cette obligation, mais aussi en conservant les données nécessaires et aussi longtemps que nécessaire contribue à réduire le risque pour l’organisation en cas de violation de données. Cela garantit que les données ne sont ni conservées pendant une durée excessivement longue, ni supprimées prématurément, ce qui peut présenter des risques de nature variable, juridiques, opérationnelles ou liées à la sécurité. 

Recommandations : fournissez une preuve de capture d’écran (ou via un partage d’écran) montrant que les données stockées (dans tous les emplacements de données, y compris les bases de données, les partages de fichiers, les archives et les sauvegardes) ne dépassent pas la stratégie de conservation des données définie. Voici quelques exemples de captures d’écran acceptables :

les enregistrements de base de données contenant un champ de date, recherchés dans l’ordre des enregistrements les plus anciens et/ou

Emplacements de stockage de fichiers indiquant les horodatages compris dans la période de rétention. Remarque : Toutes les données client personnelles ou sensibles doivent être caviardées dans la capture d’écran. 

Enregistrements de sauvegarde montrant que les données de sauvegarde sont conservées pendant la période de rétention définie et correctement supprimées après cette période. 

Exemple de preuve : la preuve suivante montre une requête SQL affichant le contenu de la table de la base de données, ordonné par ordre croissant sur le champ « DATE_TRANSACTION » pour afficher les enregistrements les plus anciens de la base de données. Cela montre que les données datent de moins de deux mois, ce qui n’excède pas la période de conservation définie. 

Remarque : Il s’agit d’une base de données de test, il n’y a donc pas beaucoup de données historiques dedans. 

Remarque : Dans les exemples précédents, aucune capture d’écran complète n’a été utilisée, mais TOUTES les captures d’écran des preuves soumises par l’ISV doivent être des captures d’écran complètes montrant l’URL, l’utilisateur, l’heure et la date du système.

Commande n° 6

Fournir la preuve que :

Des processus sont en place pour supprimer en toute sécurité les données après leur période de conservation. 

Intention : L’objectif de ce contrôle est de s’assurer que le mécanisme utilisé pour supprimer les données qui dépassent la période de rétention le fait en toute sécurité. Les données supprimées peuvent parfois être récupérées ; Par conséquent, le processus de suppression doit être suffisamment robuste pour garantir que les données ne peuvent pas être récupérées une fois supprimées. 

Recommandations : Si le processus de suppression est effectué par programmation, fournissez une capture d’écran du script utilisé pour effectuer cette opération. S’il est exécuté selon une planification, fournissez une capture d’écran montrant la planification. Par exemple, un script pour supprimer des fichiers dans un partage de fichiers peut être configuré comme un travail CRON, capture d’écran du travail CRON montrant la planification et le script qui est exécuté ; et fournissez le script montrant la commande utilisée. 

Exemple de preuve : Il s’agit d’un script simple qui peut être utilisé pour supprimer tous les enregistrements de données conservés en fonction de la date -OÙ DateAdd est -30 jours, ce qui purgera tous les enregistrements conservés de plus de 30 jours après la date de conservation des données sélectionnée. Veuillez noter que nous aurons besoin du script ; preuve de l’exécution du travail et des résultats. 

Remarque : dans les exemples précédents, aucune capture d’écran complète n’a été utilisée, mais TOUTES les captures d’écran des preuves soumises par l’ISV doivent être des captures d’écran complètes montrant l’URL, l’utilisateur connecté et l’heure et la date du système. 

Exemple de preuve : la capture d’écran suivante a été tirée de la stratégie de conservation des données Contoso (du contrôle 4) – Elle montre les procédures utilisées pour la destruction des données.

Remarque : cette capture d’écran affiche un instantané d’un document de stratégie/processus. On s’attend à ce que les éditeurs de logiciels indépendants partagent la documentation réelle des politiques/procédures de soutien et ne fournissent pas simplement une capture d’écran. 

Exemple de preuve : dans cet exemple, un runbook a été créé et une planification correspondante dans Azure pour supprimer en toute sécurité les enregistrements dont la date de fin est créée à partir des 30 jours suivant l’expiration de la stratégie de rétention des enregistrements de données. Ce travail est défini pour s’exécuter chaque mois le dernier jour du mois. 

La capture d’écran suivante montre que le runbook a été modifié pour rechercher des enregistrements et comporte des commandes de suppression qui ne sont pas affichées comme le script.

Remarque : l’URL complète et le nom d’utilisateur doivent être visibles pour ces captures d’écran et les éditeurs de logiciels indépendants devront afficher une capture d’écran du nombre d’enregistrements avant suppression et une capture d’écran du nombre d’enregistrements après la suppression. 

Ces captures d’écran sont purement des exemples des différentes façons d’aborder ce problème.

Commande n° 7

Fournir la preuve que :

Un système de sauvegarde automatisé est en place et configuré pour effectuer des sauvegardes à des heures planifiées conformément à une procédure de sauvegarde documentée. 

Les informations de sauvegarde sont régulièrement restaurées pour confirmer la fiabilité et l’intégrité des données conformément à la procédure de sauvegarde documentée. 

Des contrôles d’accès et des mécanismes de protection appropriés (c.-à-d. des sauvegardes immuables) sont mis en œuvre pour garantir que les sauvegardes/instantanés système sont protégés contre tout accès non autorisé et pour garantir la confidentialité, l’intégrité et la disponibilité des données de sauvegarde. 

Objectif :

L’objectif de ce contrôle est de confirmer que l’organisation dispose d’un système de sauvegarde automatisé configuré pour exécuter des sauvegardes à des moments prédéterminés. 

Lignes directrices :

Fournissez des captures d’écran des paramètres de configuration de votre solution de sauvegarde montrant que les sauvegardes sont effectuées à des périodes/intervalles de temps planifiés. Si la planification des sauvegardes est effectuée automatiquement par la solution, vous pouvez fournir la documentation du fournisseur. 

Exemple de preuve :

La capture d’écran suivante s’applique au Azure Database pour MySQL, qui est un instance géré. Il indique qu’une première sauvegarde automatisée a été effectuée.

La capture d’écran suivante est prise après qu’une période se soit écoulée et montre que d’autres sauvegardes complètes ont été effectuées. Les sauvegardes sur des serveurs flexibles sont basées sur instantané où la première sauvegarde de instantané est planifiée immédiatement après la création d’un serveur et les sauvegardes instantané ultérieures sont effectuées une fois par jour. 

La capture d’écran suivante montre un instantané de la documentation en ligne qui décrit la fréquence des sauvegardes et la fonctionnalité de sauvegarde automatisée. 

Objectif : L’objectif de ce contrôle est de démontrer que l’information de sauvegarde est non seulement produite selon le calendrier, mais qu’elle est également fiable et qu’elle maintient son intégrité au fil du temps. Pour atteindre cet objectif, des tests périodiques seront effectués sur les données de sauvegarde. 

Lignes directrices : Les preuves pour respecter ce contrôle dépendront du processus et de la procédure de test des données de sauvegarde de l’organisation. Des preuves peuvent être fournies montrant que les sauvegardes sont testées avec succès ainsi que les enregistrements de l’achèvement des tests historiques. 

Exemple de preuve : La capture d’écran suivante montre qu’un calendrier de sauvegarde et une procédure de restauration existent et sont maintenus et qu’une configuration de sauvegarde est définie pour tous les systèmes applicables, y compris la fréquence des sauvegardes effectuées dans la plateforme Confluence.

La capture d’écran suivante présente une page d’enregistrements historiques des tests de sauvegarde pour chacun des systèmes applicables. Observez que sur le côté droit du tableau les tickets JIRA sont référencés pour chacun des tests. 

Les quatre captures d’écran suivantes montrent le processus de bout en bout de restauration d’Azure Database pour MySQL à partir d’un instantané. En utilisant l’option 'Fast Restore', nous pouvons lancer le processus de restauration de la base de données SQL. 

La capture d’écran suivante montre la page de configuration dans laquelle nous pouvons personnaliser la restauration.

Une fois que l’emplacement cible, la mise en réseau et l’instantané à partir desquels la base de données sera restaurée sont sélectionnés, nous pouvons lancer le déploiement. Remarquez que notre instance de base de données s’appelle maintenant « test ».

Après un total de cinq minutes, la base de données SQL a été entièrement restaurée à partir de l’instantané de sauvegarde, comme illustré ci-dessous.

Une fois les tests terminés, conformément au processus, un ticket JIRA a été créé pour enregistrer les tests de sauvegarde et les détails de la restauration effectuée. Cela garantit que les données historiques sont disponibles à des fins de conformité et que des dossiers complets existent pour examen en cas d’incident ou de catastrophe afin de permettre à l’organisation d’effectuer une analyse des causes profondes. 

Intention : Dans le prolongement du contrôle précédent, des contrôles d’accès doivent être mis en œuvre pour limiter l’accès aux seuls utilisateurs individuels responsables des données de sauvegarde. En limitant l’accès, vous limitez le risque d’exécution de modifications non autorisées, introduisant ainsi des modifications non sécurisées. Une approche de moindre privilège doit être adoptée pour protéger les sauvegardes. 

Pour protéger correctement les données, les organisations doivent être conscientes des données consommées par leur environnement / système et de l’endroit où les données sont stockées. Une fois que cela sera pleinement compris et documenté. 

Les organisations sont alors en mesure non seulement de mettre en œuvre une protection adéquate des données, mais aussi de consolider l’emplacement des données pour mettre en œuvre la protection plus efficacement. De plus, lorsque les données sont consolidées dans le moins d’endroits possible, il est beaucoup plus facile de mettre en œuvre un RBAC (contrôle d’accès basé sur les rôles) adéquat pour limiter l’accès à aussi peu d’employés que nécessaire. 

Lignes directrices : Le système ou la technologie utilisé doit fournir des preuves démontrant les autorisations d’accès aux sauvegardes et aux solutions de sauvegarde, ainsi que les documents à l’appui de la liste d’accès approuvée. 

Exemple de preuve : Nous pouvons voir dans les captures d’écran suivantes présentées que des contrôles d’accès sont implémentés au niveau de l’instance de la base de données pour restreindre l’accès aux seules personnes autorisées en fonction du poste. 

Exemple de preuve :

Les sauvegardes automatisées de base de données Azure SQL et d’instances gérées Azure SQL sont gérées par Azure et leur intégrité relève de la responsabilité de la plateforme Azure ; aucun utilisateur n’y a accès et elles sont chiffrées au repos sans possibilité d’attaques par ransomware. Ils sont également répliqués dans d’autres régions à des fins de protection. 

Gestion de l’accès aux données

L’accès aux données doit être limité à autant de personnes que nécessaire pour réduire les risques de compromission malveillante ou accidentelle des données. L’accès aux données et aux clés de chiffrement devrait être limité aux utilisateurs ayant un besoin professionnel légitime d’accès pour remplir leur rôle. Un processus bien documenté et bien établi pour demander l’accès devrait être mis en œuvre. L’accès aux données et aux clés de chiffrement doit suivre le principe du moindre privilège. 

Commande n° 8

Fournir la preuve que :

Une liste des utilisateurs ayant accès aux données et/ou aux clés de chiffrement est conservée, y compris la justification opérationnelle de chaque personne. 

Cette liste d’utilisateurs a été officiellement approuvée en fonction des privilèges d’accès requis pour leur fonction. 

Les utilisateurs sont configurés avec les privilèges indiqués dans les approbations. 

Remarque : Un échantillon d’utilisateurs sera sélectionné pour illustrer les points B et C.

Objectif :

Les organisations doivent limiter l’accès aux données et aux clés de chiffrement au moins d’employés possible. L’objectif de ce contrôle est de s’assurer que l’accès des employés aux données et/ou aux clés de chiffrement est limité aux employés qui en ont clairement besoin. 

Lignes directrices :

La documentation ou les captures d’écran des systèmes internes qui documentent tous les employés ayant accès aux données et/ou aux clés de chiffrement, ainsi que la justification commerciale de la raison pour laquelle ces personnes ont accès, doivent être fournies. Cette liste sera utilisée par l’analyste de certification pour échantillonner les utilisateurs pour les contrôles suivants. 

Exemple de preuve :

Le document suivant présente la liste documentée des utilisateurs ayant accès aux données et la justification métier.

Remarque : cette capture d’écran montre un document de politique/processus, dans lequel on s’attend à ce que les éditeurs de logiciels indépendants partagent la documentation de politique/procédure de prise en charge. 

Intention : Le processus d’octroi de l’accès aux données et/ou aux clés de chiffrement doit inclure l’approbation, ce qui garantit que l’accès d’une personne est requis pour sa fonction. Cela permet de s’assurer que les employés sans véritable raison d’accès n’obtiennent pas d’accès inutile. 

Lignes directrices : En règle générale, les preuves fournies pour le contrôle précédent peuvent aider à appuyer ce contrôle. S’il n’y a pas d’approbation formelle sur la documentation fournie, la preuve peut consister en une demande de modification levée et approuvée pour l’accès dans un outil tel qu’Azure DevOps ou Jira. 

Exemple de preuve : cet ensemble d’images montre les tickets Jira créés et approuvés pour le contrôle (i) afin d’accorder ou de refuser l’accès aux données sensibles et/ou aux clés de chiffrement. Cette image démontre qu’une requête a été créée dans Jira pour obtenir l’approbation de Sam Daily pour les clés de chiffrement dans l’environnement principal du système. Il s’agit de la prochaine étape au cours de laquelle une autorisation écrite a été obtenue. 

Cela montre que la demande d’accès à Sam Daily a été approuvée par Jon Smith, une personne de la direction. (Veuillez noter que l’approbation doit provenir de quelqu’un ayant suffisamment d’autorité pour autoriser la demande de modification, il ne peut pas s’agir d’un autre développeur).

Le précédent montre un workflow dans Jira pour ce processus. Notez que rien ne peut être ajouté comme Fait à moins qu’il n’ait été suivi par le processus d’approbation qui est automatisé et ne peut donc pas être contourné.

Le conseil d’administration du projet montre maintenant que l’approbation a été donnée pour l’accès de Sam Daily aux clés de cryptage. L’arriéré suivant montre l’approbation de la demande de Sam Daily et la personne affectée au travail.

Pour répondre aux exigences de ce contrôle, vous devez montrer toutes ces captures d’écran ou preuves similaires/équivalentes applicables avec une explication démontrant que vous avez satisfait à l’exigence de contrôle. 

Remarque : dans les exemples précédents, aucune capture d’écran complète n’a été utilisée, mais TOUTES les captures d’écran des preuves soumises par l’ISV doivent être des captures d’écran complètes montrant l’URL, l’utilisateur connecté et l’heure et la date du système. 

Exemple de preuve : Dans l’exemple suivant, des autorisations d’accès administrateur et de contrôle total ont été demandées pour un utilisateur de la base de données de production. La demande a été envoyée pour approbation comme on peut le voir à droite de l’image et cela a été approuvé comme indiqué à gauche. 

L’image suivante indique que l’accès a été approuvé et approuvé comme effectué.

Remarque : dans les exemples précédents, aucune capture d’écran complète n’a été utilisée, mais TOUTES les captures d’écran des preuves soumises par l’ISV doivent être des captures d’écran complètes montrant l’URL, l’utilisateur connecté et l’heure et la date du système. 

Objectif L’objectif de ce sous-point est de confirmer que l’accès aux données et/ou aux clés de chiffrement est configuré conformément au document. 

Lignes directrices : Les preuves peuvent être fournies au moyen d’une capture d’écran montrant les privilèges d’accès aux données et/ou aux clés de chiffrement accordés aux personnes échantillonnées. Les preuves doivent couvrir tous les emplacements des données. 

Exemple de preuve : Cette capture d’écran montre les autorisations accordées à l’utilisateur « John Smith » qui seraient cross

référencé par rapport à la demande d’approbation pour ce même utilisateur, selon la preuve du contrôle précédent. 

Remarque : l’exemple suivant n’est pas une capture d’écran en plein écran, vous devrez soumettre des captures d’écran en plein écran avec n’importe quelle URL, l’utilisateur connecté et l’horodatage pour l’examen des preuves. Si vous êtes un utilisateur Linux, vous pouvez le faire via l’invite de commandes. 

Commande n° 9

Fournir la preuve que :

Une liste de tous les tiers avec lesquels les données sont partagées est conservée. 

Des accords de partage de données sont en place avec tous les tiers consommant des données. 

Intention : Lorsque des tiers sont utilisés pour le stockage ou le traitement des données Microsoft 365, ces entités peuvent présenter un risque important. Les organisations doivent mettre en place un bon processus de diligence raisonnable et de gestion des tiers pour s’assurer que ces tiers stockent/traitent les données en toute sécurité et pour s’assurer qu’ils respecteront leurs obligations légales, par exemple en tant que sous-traitant des données en vertu du RGPD. 

Les organisations doivent tenir à jour une liste de tous les tiers avec lesquels elles partagent des données avec tout ou partie des entités suivantes :

quels services sont fournis

quelles données sont partagées

Pourquoi les données sont partagées

les principales informations de contact (c.-à-d. contact principal, contact de notification d’atteinte, DPD, etc.)

renouvellement/expiration de contrat

obligations légales/de conformité (RGPD, HIPAA, PCI DSS, FedRAMP, etc.)

Recommandations : fournissez une documentation détaillant TOUS les tiers avec lesquels les données Microsoft 365 sont partagées. 

Remarque : Si des tiers ne sont pas utilisés, cela devra être confirmé par écrit (courriel) par un membre de l’équipe de direction. 

Exemple de preuve :

Remarque : - Dans les exemples précédents, les captures d’écran complètes n’ont pas été utilisées, mais TOUTES les captures d’écran des preuves soumises par les éditeurs de logiciels indépendants doivent être des captures d’écran complètes montrant l’URL, tout utilisateur connecté et l’heure et la date du système. 

Exemple de preuve :

La capture d’écran suivante montre un exemple d’e-mail d’un membre de l’équipe de direction confirmant qu’aucun tiers n’est utilisé pour traiter les données Microsoft 365. 

Remarque : - Dans ces exemples, aucune capture d’écran complète n’a été utilisée, mais TOUTES les captures d’écran des preuves soumises par l’ISV doivent être des captures d’écran complètes montrant l’URL, l’utilisateur connecté et l’heure et la date du système. 

Objectif : Lorsque les données M365 sont partagées avec des tiers, il est important que les données soient traitées de manière appropriée et sécurisée. Des accords de partage de données doivent être en place pour garantir que les tiers ne traitent les données qu’en cas de besoin et qu’ils comprennent leurs obligations en matière de sécurité. La sécurité d’une organisation est aussi forte que le maillon le plus faible. L’objectif de ce contrôle est de s’assurer que les tiers ne deviennent pas un maillon faible de l’organisation. 

Lignes directrices : Fournir les ententes de partage de données qui sont en place avec les tiers. 

Exemple de preuve : la capture d’écran suivante montre un exemple simpliste d’accord de partage de données. 

Remarque : l’accord complet doit être partagé et non une capture d’écran.

Confidentialité

La confidentialité, la conformité et la gestion des informations sont essentielles pour protéger les droits des individus et garantir un traitement responsable des données. Pour qu’une organisation puisse mettre en place un système d’information efficace sur la protection de la vie privée, elle doit connaître les données personnelles qu’elle détient et la finalité de leur traitement et de leur stockage. Une organisation doit cartographier le flux d’informations et la façon dont il est traité, en reconnaissant que plusieurs types de traitement différents peuvent se produire. 

Contrôle n° 10 – Données personnelles

Fournissez la preuve que votre organisation :

Tenir à jour un inventaire de toutes les données personnelles collectées, traitées et stockées, y compris la finalité de chaque élément de données.  

Conçoit les formulaires de collecte de données pour inclure uniquement les champs nécessaires à l’objectif commercial et implémente les champs obligatoires et facultatifs de manière appropriée.  

Élaborer et appliquer des politiques qui spécifient les types de données personnelles pouvant être collectées et les finalités pour lesquelles elles peuvent être utilisées.  

Permet aux utilisateurs de refuser le traitement ou l’exposition étendue de leurs données personnelles non essentielles à l’entreprise.  

Intention : L’objectif de ce contrôle est de vous assurer que vous respectez la confidentialité des données concernées par la collecte de données, de vous assurer qu’il y a une justification pour les données capturées et d’être transparent avec quelles données sont collectées et pourquoi. Il est également important que les utilisateurs (personnes concernées) aient la possibilité de refuser le traitement.   

Lignes directrices : Ce contrôle peut être mis en évidence comme suit :

A) Fournir une version à jour du registre des activités de traitement (RoPA) de l’organization (voir l’article 30 du RGPD) ou un document similaire détaillant les éléments de données et la ou les finalités du traitement (voir l’article 5.1.b) du RGPD).  

Dans la plupart des cas, il s’agit d’une feuille de calcul Excel (qui peut être extraite à partir d’outils tels que OneTrust).  

Si le fichier est trop volumineux ou contient des données sensibles, un extrait peut être fourni, montrant tous les champs de données pour un échantillon de données donné, qui peut être partiellement expurgé tant que les preuves peuvent fournir l’assurance que la RoPA est en place.  

Non conformes : Les enregistrements n’existent pas, sont très anciens/obsolètes ou comportent des champs clés manquants.  

B) Aux fins de la « minimisation des données » (voir l’article 5.1.c du RGPD), fournir tous les formulaires utilisés pour obtenir des données, que ce soit en ligne, à l’aide de tablettes ou d’appareils similaires (par exemple, lors d’une conférence) ou sur papier. Il peut s’agir de blancs/modèles.  

Non conforme : Les formulaires comportent des champs obligatoires qui ne sont pas nécessaires aux fins de traitement prévues. Par exemple, demander des numéros de téléphone, l’âge ou le sexe, pour envoyer une brochure par e-mail ou à une adresse postale.   

C) À des fins de « licéité, d’équité et de transparence » (voir l’article 5.1.a) du RGPD), la politique de confidentialité (destinée aux employés), la déclaration de confidentialité (destinée aux utilisateurs/clients) doit être en place. En règle générale, l’avis de confidentialité doit être accessible au public sur le site web de l’organisation.   

Non conforme : les stratégies n’existent pas ou des éléments clés sont manquants.  

Éléments clés :

Politique de confidentialité/Avis : collecte et utilisation des informations, éléments de données traités, finalité(s) du traitement, légalité du traitement, transferts de données vers d’autres pays, droits de la personne concernée, stockage et conservation des données.   

D) Pour le mécanisme de désinscription (voir l’article 4.11 du RGPD, l’article 6 du RGPD et l’article 7 du RGPD), généralement sur une page web. Vérifiez la navigation que l’utilisateur doit suivre pour accéder à cette page (par exemple, est-elle facile à trouver ?).  

Non conforme : Aucune fonctionnalité de refus claire, ou refus « générique », sans granularité.  

Exemple de preuve :

Pour a) :

Pour B) :

Pour c) :

Pour d) :

Contrôle n° 11 – Sensibilisation des utilisateurs

Fournissez la preuve que les utilisateurs ont connaissance des éléments suivants :

Qui a accès à leurs données. 

Qui a accès aux espaces dans lesquels ils travaillent. 

Qui pourrait accéder à leurs données par le biais du partage ou de flux de données afin de pouvoir prendre des décisions éclairées. 

Objectif : L’objectif de ce contrôle est de démontrer que le principe de « transparence » de la protection des données (voir l’article 5.1.a) du RGPD) est respecté. 

Lignes directrices : Pour démontrer que cela est en place, idéalement, une certaine forme de reconnaissance de l’utilisateur (par exemple, avoir lu la politique de confidentialité) devrait être en place et enregistrée. 

En pratique, il suffit que la Politique de confidentialité (pour les employés), la Déclaration de confidentialité (pour les utilisateurs et les clients) fournissent suffisamment de détails sur les points suivants :

- Avec lesquels les données personnelles sont partagées (sous-traitants, sous-traitants, tiers, sous-traitants, etc.). 

Non conforme : Aucune reconnaissance n’existe ou la politique de confidentialité/l’avis de confidentialité n’existe pas. 

Exemple de preuve :

OR

Contrôle n° 12 – Accords de traitement des données (APD)

Fournir la preuve de l’accord de traitement des données, qui doit contenir une liste de tous les tiers ou sous-traitants ultérieurs approuvés. 

Objectif : assurer la transparence avec les personnes concernées en veillant à ce qu’elles soient informées des tiers/sous-traitants ultérieurs pouvant avoir accès à leurs données, du rôle qu’elles jouent dans le traitement (responsable du traitement, sous-traitant), de leurs responsabilités respectives et des mécanismes de sécurité en place. 

En outre, lorsque le partage de données implique des transferts de données vers des territoires en dehors de l’UE (en vertu du RGPD), les détails du mécanisme permettant de garantir la légalité des transferts. (Voir l’article 5 du RGPD et l’article 44-50 du RGPD)

Pour le RGPD, les territoires de traitement doivent remplir l’une des conditions suivantes :

- Être un État membre de l’Union européenne. 

- Être considéré par la Commission européenne comme fournissant des « garanties adéquates ». La liste actuelle peut être consultée ici : Adéquation de la protection des données pour les pays tiers 

Au 13 juin 2025 :

• Faire partie du Cadre de protection des données (DPF) et être répertorié ici : Cadre de protection des données 

• Mettez en place des règles d’entreprise contraignantes (BCR). 

• Mettez en place des clauses contractuelles Standard (CCS). 

Lignes directrices : Les preuves pourraient être par le biais de l’échantillonnage de quelques accords de traitement des données (DPA) avec des sous-traitants existants. Dans certains cas, les organisations peuvent ne pas avoir d’APD, mais auraient des addendums aux contrats, ou des « clauses de confidentialité ». 

Non conforme :

• La liste des tiers/sous-traitants ultérieurs est manquante. 

• Aucune information n’est donnée sur les pays bénéficiaires. 

• Les pays ne sont pas répertoriés comme « pays adéquats » et il n’y a pas de BCR ou de SCC en place. 

Exemple de preuve : Cet exemple montre un exemple d’APD de l’IAPP, ou la preuve peut être un document connexe énumérant les parties avec lesquelles les données sont partagées. 

En outre, vérifiez les mécanismes de case activée pour les transferts de données en dehors de l’UE.

Contrôle n° 13 – Analyses d’impact sur la protection des données (AIPD)

Fournir la preuve que votre organisation effectue une évaluation d’impact sur la protection des données (AIPD)

     OR

Indiquez le nom de l’évaluation relative à la confidentialité et à la protection des données à laquelle cet examen de la confidentialité est connecté. 

Intention : L’objectif de ce contrôle est de s’assurer que vous effectuez des évaluations sur les risques potentiels pour les droits et libertés des personnes, en particulier en ce qui concerne l’introduction de nouvelles technologies ou de nouvelles utilisations des technologies existantes. (Voir l’article 35 du RGPD)

Lignes directrices : Ce contrôle serait évalué en examinant une AIPD récente ou les documents d’évaluation connexes. 

Non conforme :

Une AIPD doit comporter les éléments suivants :

• Identification de la nécessité d’une AIPD. 

• Description du traitement envisagé, y compris l’étendue, le contexte et le(s) final(s). 

• Appréciation de la nécessité et de la proportionnalité. 

• Identification et évaluation des risques. 

• Identification des mesures pour réduire les risques. 

• Résultats enregistrés. 

Si l’un des éléments ci-dessus est manquant ou n’est effectué qu’à un niveau superficiel, ce contrôle peut être marqué comme non conforme. 

Exemple de preuve :

Le modèle complet d’une AIPD peut être trouvé sur le site Web de l’ICO ici dpia-template.docx

Contrôle n° 14 – Données biométriques

L’application interagit-elle avec les données biométriques ? Si oui,

Fournir la preuve que les données biométriques ont passé un examen juridique, qu’elles sont protégées et que les utilisateurs sont informés et ont la possibilité de refuser la collecte de données biométriques. 

Intention : Ce contrôle vise à assurer une protection adéquate des données biométriques, qui, en vertu de l’article 9 du RGPD , sont classées comme une catégorie spéciale de données.  L’utilisation des données biométriques a fait l’objet d’une analyse de légalité. 

Lignes directrices : L’utilisation des données biométriques doit faire l’objet d’un examen juridique, elles doivent donc être fournies dans le cadre de la collecte de preuves. S’il n’en existe pas, demandez le modèle qui sera utilisé (pour case activée leur préparation). 

Non conforme :

L’examen juridique du traitement des données biométriques devrait contenir les éléments suivants :

• Base légale du traitement (une ou plusieurs des clauses suivantes) :

• Lister une condition valide pour le traitement des données biométriques (un ou plusieurs des éléments suivants) :

• Considération accordée à l’utilisation d’alternatives, au lieu de données biométriques.

Si l’un des éléments ci-dessus est manquant ou n’est effectué qu’à un niveau superficiel, ce contrôle peut être marqué comme non conforme.

Exemple de preuve :

Sources :

- Article 9 du RGPD – Traitement de catégories particulières de données : art. 9 du RGPD – Traitement de catégories particulières de données à caractère personnel – Règlement général sur la protection des données (RGPD)

- ICO « Comment traitons-nous les données biométriques légalement ? » : Comment traitons-nous les données biométriques légalement ? | ICO

Contrôle n° 15 – Data Insights

Fournir la preuve que les mesures n’affichent que des données agrégées et anonymes sans données d’identification individuelle. Le client doit être en mesure de configurer sa limite inférieure de niveau d’agrégation préféré, avec un minimum absolu de cinq niveaux autorisés par le produit. Fournir la preuve que les données biométriques ont passé un examen juridique, qu’elles sont protégées et que les utilisateurs sont informés et ont la possibilité de refuser la collecte de données biométriques. 

Intention : L’objectif de ce contrôle est de s’assurer que vous avez mis en œuvre et maintenez le status des données anonymisées et pseudonymisées tout au long du cycle de vie des données. (Voir

Lignes directrices : Pour aider à démontrer que ce contrôle est en place, des preuves via l’interface graphique ou l’interface de ligne de commande doivent être fournies pour démontrer :

• Configuration au niveau de l’utilisateur pour les limites les plus basses des niveaux d’agrégation. 

• Un échantillon de métriques. 

Évaluez si l’utilisateur peut configurer un seuil pour ses niveaux d’agrégation préférés jusqu’à un minimum de 5. Les preuves doivent démontrer que seuls les anonymes sont présents dans l’échantillon de mesures. 

Non conforme :

• Les utilisateurs ne peuvent pas personnaliser leurs niveaux d’agrégation à un minimum de 5, ou les compétences techniques requises pour ce faire ne peuvent pas être attendues de l’utilisateur type. 

• Les données personnelles sont présentes dans l’échantillon de métriques ; par exemple : nom, prénom, pièce d’identité, numéro de client, numéro de téléphone, adresse e-mail, adresse postale, coordonnées bancaires, proches parents, etc. 

Exemple de preuve : captures d’écran des paramètres de configuration, montrant les détails spécifiques. 

Exemple de métriques collectées. Peut-être poser des questions sur le processus pour parvenir à l’anonymisation. 

RGPD

La plupart des organisations traiteront des données qui sont potentiellement celles d’un citoyen européen (personnes concernées). Lorsque les données de N’IMPORTE QUELLE personne concernée sont traitées, les organisations devront respecter le Règlement général sur la protection des données (RGPD). Cela s’applique à la fois aux responsables du traitement (vous capturez directement lesdites données) ou aux sous-traitants (vous traitez ces données pour le compte d’un responsable du traitement). Bien que cette section ne couvre pas l’ensemble du règlement, elle aborde certains des éléments clés du RGPD afin d’obtenir l’assurance que l’organisation prend le RGPD au sérieux. 

Commande n° 16

Fournissez des preuves démontrant le respect des droits de la personne concernée en montrant :

• Facilitation des demandes d’accès des sujets (SAR) : documentation qui confirme que les personnes concernées sont informées de leur droit d’accès à leurs données personnelles et peuvent soumettre des demandes d’accès des sujets (SAR) à votre organisation. 

• Découverte de données et exécution du SAR : Preuve de la capacité de votre organisation à localiser et à récupérer toutes les données personnelles relatives à une personne concernée dans tous les systèmes et référentiels en réponse à un SAR. 

Intention : L’objectif de ce contrôle est de s’assurer que des mécanismes adéquats sont en place pour permettre aux personnes concernées d’effectuer des demandes concernant leurs données personnelles détenues par l’organisation, et que le traitement des demandes légitimes est complet. (Voir l’article 15 du RGPD). 

Lignes directrices : A) L’avis de confidentialité doit contenir des détails sur la façon d’effectuer un DAS, qui pourrait être en utilisant les méthodes suivantes :

• Utilisation d’un formulaire web fourni par l’organisation

• Utilisation d’une adresse e-mail fournie par l’organisation

• Utilisation d’un numéro de téléphone/conversation web fourni par l’organisation

• Recours à une autorité de contrôle (par exemple, l’ICO au Royaume-Uni)

Demander une preuve de la méthode en place ; Les captures d’écran devraient suffire. 

B) Un RoPA ou un document similaire peut être utilisé pour identifier les emplacements où résident les données personnelles relatives à la personne concernée, qu’elles soient numériques ou dans le cadre de systèmes de classement (physiques). 

Alternativement, les exercices d’e-discovery peuvent atteindre le même résultat. 

Demander des preuves du processus/flux de travail qui serait utilisé pour effectuer un DAS, et une explication sur la façon dont il a été déterminé que le processus est minutieux et qu’aucune donnée personnelle liée à la personne concernée ne manquerait. 

Non conforme :

A) Aucune information n’est fournie sur le site Web de l’organisation (généralement dans l’avis de confidentialité). 

B) Les preuves indiquent que le processus de collecte des données personnelles n’est pas approfondi ou peut manquer de détails techniques (par exemple, aucun nom/emplacement donné pour les bases de données). 

Exemple de preuve :

A) Voici des exemples de preuves qui pourraient être fournies pour couvrir le point A). 

• Formulaire Web :

Source : Demande d’accès du sujet - Police Care UK

• Email adresse/numéro de téléphone :

Source : Lequel ? Politique de confidentialité - Laquelle ?

• Discussion web :

Source : Faire une demande d’accès au HMRC - GOV.UK

• Via une autorité de contrôle (par exemple, l’ICO) :

Source : Faire une demande d’accès de votre sujet | ICO 

B) Artefacts de preuve fournis Détaillant les flux de travail ou les descriptions de processus avec suffisamment de détails techniques, qui pourraient être utilisés de manière plausible pour remplir le SAR.    La capture d’écran suivante montre un exemple de preuve de la capacité d’une organisation à localiser et à récupérer toutes les données personnelles relatives à une personne concernée spécifique à partir d’une base de données Azure SQL en réponse à une demande d’accès des personnes concernées (SAR). L’exemple montre un administrateur exécutant une procédure stockée prédéfinie dans le Azure SQL Éditeur de requête pour récupérer des enregistrements associés à un identificateur unique de la personne concernée dans plusieurs tables de base de données de production. 

La capture d’écran suivante montre un exemple de preuve de la capacité d’une organisation à localiser et à récupérer toutes les données personnelles relatives à une personne concernée spécifique à partir d’un compte de stockage Azure en réponse à une demande d’accès des personnes concernées (SAR). L’exemple montre un administrateur localisant tous les documents associés à un identificateur unique de la personne concernée dans Stockage Blob Azure, ce qui démontre la capacité de l’organization à identifier et à récupérer les données personnelles non structurées stockées dans l’environnement.

Contrôle n° 17

ÉCHEC DUR

Fournissez la déclaration de confidentialité qui doit contenir tous les éléments requis comme suit :

• L’identité et les coordonnées de l’organisation, et le délégué à la protection des données (DPO), le cas échéant. 

• Les types de données personnelles que votre organisation traite (nom, prénom, numéro de client, adresse e-mail, numéro de téléphone, etc.). De même, les sources de données personnelles (par exemple, d’où proviennent les données personnelles), au cas où l’organisation ne les aurait pas obtenues directement auprès des personnes concernées. 

• La ou les finalités du traitement des données personnelles. 

• Base légale du traitement des données personnelles (y compris les intérêts légitimes, le cas échéant). 

• Parties avec lesquelles votre organisation partage des données personnelles. 

• Détails sur la durée de conservation des données personnelles. 

• Détails des droits des personnes concernées :

• Droit d’être informé

• Droit d’accès

• Droit de rectification

• Droit à l’effacement

• Droit à la limitation du traitement

• Droit à la portabilité des données

• Droit d’opposition

• Droits relatifs à la prise de décision automatisée, y compris le profilage

• Les détails concernant tout transfert de données personnelles vers un pays tiers et les garanties prises. 

• Le droit de déposer une plainte auprès d’une autorité de contrôle, en fournissant les coordonnées de l’autorité de contrôle (par exemple, l’ICO au Royaume-Uni). 

Objectif : L’objectif est de s’assurer que l’avis de confidentialité publié contient suffisamment de détails en incluant les éléments et principes ci-dessus, conformément au chapitre 3 du RGPD. 

Lignes directrices : Conformément au contrôle 10.c, vous devez publier un avis de confidentialité qui couvre le service inclus dans la certification Microsoft 365. Cet avis de confidentialité doit contenir les éléments et principes mis en évidence ci-dessus. 

Non conforme :

Reportez-vous au contrôle 10.c. 

Exemple de preuve :

Remarque : Votre propre avis de confidentialité doit refléter fidèlement votre application et votre site Web réels. L’avis doit être publié et mis à la disposition du public sur le site web de votre entreprise.  

HIPAA (Health Insurance Portability and Accountability Act)

La loi américaine sur la portabilité et la responsabilité en matière d’assurance maladie de 1996 (HIPAA) est une loi fédérale applicable aux citoyens américains et aux organismes de santé. Il est important de noter que cette législation couvre également toutes les organisations en dehors des États-Unis qui traitent les données de santé des citoyens américains. L’introduction de la législation a mandaté le secrétaire du département américain de la Santé et des Services sociaux (HHS) pour élaborer des réglementations protégeant la confidentialité et la sécurité de certaines informations de santé. Certaines organisations peuvent traiter des données qui sont des informations de santé potentiellement protégées (ePHI), c’est-à-dire des informations de santé identifiables individuellement transmises par des supports électroniques, conservées dans des supports électroniques ou transmises ou conservées sous toute autre forme ou support. Lorsque les données de santé de N’IMPORTE QUELLE personne concernée sont traitées, les organisations devront se conformer à la loi HIPAA. 

La loi HIPAA comporte deux textes législatifs qui doivent être pris en compte : « La règle de confidentialité », ou normes de confidentialité des informations de santé identifiables individuellement, qui décrit les normes nationales de protection de certaines informations de santé, et « Les normes de sécurité » pour la protection des informations de santé protégées électroniques, également appelées « règle de sécurité ». Ce dernier établit un ensemble national de normes de sécurité pour protéger certains renseignements de santé détenus ou transférés sous forme électronique. 

D’un point de vue d’ensemble général, « la règle de sécurité » est une implémentation pratique des protections offertes par la « règle de confidentialité ». Il décrit les mesures techniques et non techniques que les « entités visées » doivent mettre en œuvre pour assurer la sécurité des « informations de santé protégées électroniques » (e-PHI) des individus. Bien que cette section ne couvre pas l’ensemble de la réglementation, elle aborde certains des éléments clés de la HIPAA afin d’obtenir l’assurance que l’organisation respecte l’exigence et que l’organisation protège les informations relatives à la santé qu’elle traite. 

Commande n° 18

Fournir des preuves qui vérifient la conformité de votre organisation à la loi américaine HIPAA (Health Insurance Portability and Accountability Act) en fournissant des preuves que :

• Avis sur les pratiques en matière de protection de la vie privée (NPP) et formation de la main-d’œuvre : Un avis sur les pratiques en matière de protection de la vie privée est en place et un programme de formation de la main-d’œuvre sur le traitement des informations de santé protégées (PHI) en vertu de la loi HIPAA est établi pour les employés, les sous-traitants, les fournisseurs et les autres parties concernées. 

• Protection des informations de santé protégées électroniques (ePHI) : Votre organisation a mis en œuvre des mesures de protection administratives, physiques et techniques, comme l’exige la règle de sécurité HIPAA, afin de garantir la confidentialité, l’intégrité et la disponibilité de toutes les PHI électroniques (ePHI) qu’elle crée, reçoit, conserve ou transmet. 

• Politiques de gestion des risques : Votre organisation a mis en place des politiques et des mesures de gestion des risques pour se protéger contre les menaces ou les dangers raisonnablement prévus pour la sécurité ou l’intégrité des RPS. 

Objectif : L’objectif de ce sous-point est de s’assurer que les organisations ont établi des protocoles qui servent de procédures normalisées pour la gestion de l’information sur la santé, la gestion des urgences et des interruptions de service, ainsi que l’accès du personnel à l’information et à la formation en matière de santé. En outre, les organisations sont censées maintenir et décrire ces mesures de protection administratives dans le cadre de leur programme de sécurité HIPAA. Il s’agit d’un aspect crucial de la conformité aux réglementations HIPAA. 

Lignes directrices : Cela serait mis en évidence en fournissant la documentation établie par l’organisation décrivant la politique et la procédure HIPAA. Les analystes de certification examineront cette question pour s’assurer que toute l’information fournie dans le cadre du contrôle est traitée. 

Exemple de preuve : les captures d’écran montrent des instantanés d’une politique HIPAA. Remarque : les éditeurs de logiciels indépendants sont censés partager la documentation de la politique/procédure de prise en charge réelle et ne pas simplement fournir une capture d’écran. 

Remarque : On s’attend à ce qu’un éditeur de logiciels indépendants partage la documentation complète de la politique/procédure et ne fournisse pas simplement une capture d’écran. 

Objectif :

Afin de comprendre l’intention de ce sous-point et d’assurer la conformité avec la règle de sécurité, les « entités couvertes » doivent d’abord savoir comment les termes de confidentialité, d’intégrité et de disponibilité sont définis en vertu de l’article 164.304 :

Confidentialité : « la propriété que les données ou les informations ne sont pas mises à la disposition ou divulguées à des personnes ou à des processus non autorisés ». 

Intégrité : « la propriété que les données ou les informations n’ont pas été modifiées ou détruites de manière non autorisée ». 

Disponibilité : « la propriété dont les données ou les informations sont accessibles et utilisables à la demande d’une personne autorisée ». 

L’objectif de cette exigence est que les organisations mettent en œuvre des mesures de protection techniques telles que des contrôles d’accès, d’audit, d’intégrité et de transmission au sein de l’infrastructure informatique afin d’assurer la confidentialité des ePHI tout en maintenant son intégrité et sa disponibilité pour les utilisateurs autorisés. 

Lignes directrices :

La preuve peut être fournie par le biais des paramètres de configuration des mécanismes de protection utilisés pour s’assurer que les données ePHI sont sécurisées conformément à l’exigence de contrôle. Ces mécanismes peuvent inclure des contrôles d’accès, des procédures d’accès d’urgence, le RBAC, le cryptage, etc. 

Exemple de preuve : contrôles de l’accès et de l’intégrité

La capture d’écran suivante montre qu’une liste d’accès autorisé des personnes autorisées à gérer les emplacements de stockage ePHI existe et est conservée dans le document de politique HIPAA. En outre, dans les captures d’écran qui suivent la liste d’inventaire approuvée, on peut observer que l’accès en écriture est limité sur le cluster, seuls l’administrateur et l’analyste de maintenance de la base de données étant en mesure de lire et d’écrire sur le cluster. 

La capture d’écran suivante prise à partir de l’une des bases de données de stockage ePHI dans Atlas Mongo montre que seuls les utilisateurs autorisés ont l’accès documenté et que tous les comptes ont des identifiants d’utilisateur uniques pour garantir la responsabilité. 

La première capture d’écran montre l’emplacement de stockage/cluster de base de données principal pour ePHI. 

La deuxième capture d’écran montre que les utilisateurs approuvés ont uniquement les rôles et l’accès documentés.

Les deux captures d’écran suivantes montrent une vue plus granulaire de chacun des rôles attribués et de toutes les autorisations associées qui sont conformes à l’approbation d’accès ci-dessus.

Chaque rôle personnalisé dispose d’un ensemble d’autorisations et d’une étendue d’accès.

Enfin, la capture d’écran suivante démontre, d’un point de vue réseau, que seule la plage d’adresses IP autorisées, c’est-à-dire le réseau d’entreprise sécurisé, est autorisée à accéder au cluster.

Exemple de preuve : contrôles d’audit

Ces captures d’écran montrent que la journalisation et les alertes sont implémentées pour le cluster de base de données. La première capture d’écran montre que les alertes sont activées. Veuillez noter que l’on s’attend à ce que les preuves fournies montrent également les règles d’alerte qui ont été établies en fonction du besoin ou de la mise en œuvre de l’organisation. La deuxième capture d’écran montre que l’audit de base de données est activé. 

La capture d’écran suivante montre l’historique d’accès au cluster de base de données en cours d’enregistrement. On s’attend à ce que des alertes soient définies et, en fonction des journaux d’audit, tout accès non autorisé ne répondant pas aux conditions prédéfinies déclenche une alerte.

Les deux dernières captures d’écran montrent que les journaux d’audit sont générés pour le cluster de base de données et qu’ils peuvent être exportés à des fins d’analyse.

Veuillez noter qu’il existe un processus en place pour l’analyse des journaux de vérification générés, des preuves du processus d’examen doivent également être fournies. Si cela est réalisé par programmation, des captures d’écran des paramètres de configuration de l’ingestion de journal dans la plate-forme/de la solution de journalisation utilisée, ainsi que des captures d’écran des règles doivent être fournies pour examen. 

Exemple de preuve : contrôles de cryptage et de transmission

Les captures d’écran suivantes montrent que les données au repos sont chiffrées par défaut à l’emplacement de stockage. Notez que si le chiffrement n’est pas effectué par la plateforme utilisée par défaut et que vos propres clés de chiffrement sont utilisées, on s’attend à ce que ces clés soient correctement sécurisées, et des preuves sont fournies pour le démontrer. 

Les deux captures d’écran suivantes montrent que les données en transit sont chiffrées par défaut à l’emplacement de stockage. La première capture d’écran montre qu’une API de données est activée avec des autorisations de « lecture et écriture ».

Une analyse SSL du point de terminaison démontre que les données en transit sont chiffrées via TLS 1.2.

Exemple de preuve : contrôles de disponibilité et de récupération

La capture d’écran suivante montre que le cluster de base de données est répliqué dans trois régions pour garantir la disponibilité. Cette opération est effectuée par défaut par Mongo Atlas. En outre, la sauvegarde est activée et est active.

La capture d’écran suivante montre le tableau de bord de sauvegarde du cluster, qui montre également qu’un instantané a déjà été créé.

Les deux captures d’écran suivantes montrent qu’une stratégie de sauvegarde est en place pour effectuer des sauvegardes planifiées à différents moments dans le temps (PIT).

Ce qui suit indique qu’il existe une stratégie de rétention pour les instantanés et la restauration d’un point antérieur (PIT).

Intention : L’intention de ce sous-point s’aligne sur la règle de sécurité qui a été élaborée pour assurer la flexibilité et l’évolutivité afin qu’une « entité visée » puisse mettre en œuvre des politiques, des procédures et des solutions technologiques adaptées à la taille de l’entité, à sa structure organisationnelle, à ses risques spécifiques ainsi qu’à son appétit pour le risque. D’un point de vue pratique, cela signifie que les mesures de sécurité appropriées mises en œuvre dépendront de la nature de l’activité de l'« entité visée », ainsi que de sa taille et de ses ressources. 

Il est essentiel pour chaque organisation de mener une analyse complète des risques afin de découvrir les risques et les vulnérabilités potentiels à la confidentialité, à l’intégrité et à la disponibilité des e-PHI. Grâce à cette analyse des risques, les organisations peuvent ensuite mettre en œuvre des contrôles de sécurité appropriés pour atténuer ces risques identifiés. 

Lignes directrices : Des données probantes peuvent être fournies au moyen d’une analyse des risques. Lorsque l’analyse des risques est effectuée et conservée via une plateforme en ligne, des captures d’écran de l’ensemble des résultats doivent être fournies. 

Exemple de preuve : Les captures d’écran suivantes montrent des instantanés du processus d’évaluation des risques, suivis de l’analyse des risques qui a été effectuée pour déterminer dans quelle mesure les contrôles sont mis en œuvre correctement et fonctionnent comme prévu pour protéger l’ePHI. La deuxième capture d’écran montre une analyse des risques identifiés dans l’évaluation des risques et les contrôles compensatoires et les mesures d’atténuation mis en œuvre pour réduire le niveau de risque. 

Exemple 1 – Aperçu du processus d’évaluation des risques dans le cadre de la politique HIPAA et analyse des risques effectuée

Remarque : Cette capture d’écran montre un instantané d’un document d’analyse des risques, il ne s’agit que d’un exemple, et l’on s’attend à ce que les éditeurs de logiciels indépendants partagent la documentation réelle et ne fournissent pas simplement une capture d’écran.

Exemple 2 – Captures d’écran du processus d’évaluation des risques dans le cadre de la politique HIPAA et de l’analyse des risques effectuée (conservés dans la plateforme Confluence Cloud)

La deuxième capture d’écran montre une analyse des risques identifiés dans l’évaluation des risques et les contrôles compensatoires et les mesures d’atténuation mis en œuvre pour réduire le niveau de risque. Nous pouvons voir que cela existe et est maintenu dans la plateforme cloud Confluence.

Contrôle n° 19

Fournir la preuve que :

Votre organisation a établi et mis en œuvre un plan de sauvegarde des données et un plan de reprise après sinistre dans le cadre de son plan d’urgence, conformément aux mesures de protection administratives de la règle de sécurité HIPAA en vertu des articles 45 CFR §164.308(a)(7)(ii)(A) (plan de sauvegarde des données) et 45 CFR §164.308(a)(7)(ii)(B) (plan de reprise après sinistre). 

Objectif : La règle de confidentialité définit quels éléments d’informations de santé protégées (PHI) sont couverts par la loi et interdit les utilisations et divulgations inappropriées des PHI. L’objectif de ce sous-point est qu’une organisation doit limiter l’accès et l’utilisation des RPS électroniques aux seules personnes qui en ont besoin à des fins autorisées et qu’elle doit se conformer à la règle minimale nécessaire, qui exige qu’elle n’utilise ou ne divulgue que la quantité minimale de RPS électroniques nécessaire pour atteindre son objectif prévu. 

Une combinaison de mesures de protection techniques et administratives doit être mise en place pour restreindre l’utilisation des RPS et réduire le risque de divulgation des RPS. 

Lignes directrices : Les preuves fournies doivent montrer les garanties techniques en place, telles que les technologies et les mécanismes utilisés pour protéger les e-PHI et la façon dont l’organisation contrôle la case activée l’accès et le mouvement de ces données. 

Exemple de preuve : les captures d’écran suivantes montrent Protection contre la perte de données Microsoft Purview (DLP), une plateforme intégrée qui permet aux organisations de gérer leurs politiques DLP à partir d’un emplacement centralisé. 

Vous pouvez observer ci-dessous qu’une stratégie « HIPAA Enhanced » est activée, ce qui permet d’empêcher les utilisateurs de coller des données sensibles sur des sites web spécifiques, notamment des e-mails personnels, des requêtes d’IA générative, des sites de réseaux sociaux, etc. lorsque vous y accédez via un navigateur web pris en charge. 

La capture d’écran suivante fournit une vue d’ensemble plus complète de la stratégie, y compris de l’étendue à laquelle elle s’applique. La stratégie est définie sur tous les comptes dans des emplacements tels que SharePoint, Appareils, OneDrive, etc.

Lorsque vous sélectionnez l’option « Modifier la stratégie », une vue plus granulaire des configurations spécifiques disponibles s’affiche.

Les deux captures d’écran suivantes montrent la définition du contenu et les conditions qui doivent être remplies pour que la stratégie soit appliquée.

La stratégie couvre différents types de données sensibles ainsi qu’un ensemble de classifieurs.

La section suivante présente les actions configurées pour être entreprises lorsque les conditions affichées dans les captures d’écran précédentes sont remplies.

La capture d’écran suivante montre que la stratégie DLP est définie pour empêcher les utilisateurs de copier et coller des informations sensibles telles que des informations d’identification personnelle (PII) des bases de données internes de l’organisation dans leurs comptes de messagerie personnels, chatbots et sites de réseaux sociaux sur les navigateurs pris en charge.

Enfin, les notifications aux utilisateurs sont configurées pour notifier et fournir des conseils aux utilisateurs lorsqu’ils traitent des données ePHI.

La capture d’écran suivante montre le panneau de configuration pour la génération d’alertes lorsqu’un incident se produit.

Objectif : L’objectif de ce sous-point est qu’une organisation doit former son personnel sur la façon de gérer les RPS électroniques de manière sûre et appropriée, et qu’elle doit appliquer des politiques et des procédures pour assurer la conformité à la règle de sécurité. 

Lignes directrices : Les preuves fournies doivent démontrer qu’une formation HIPAA est dispensée sur la façon de gérer les ePHI et qu’il existe des registres de présence et d’achèvement de la formation. Le cas échéant, cela peut être appuyé par la documentation sur les politiques et le matériel de formation utilisé. 

Exemple de preuve : Les exemples suivants montrent les preuves potentielles qui peuvent être soumises pour démontrer qu’une formation HIPAA appropriée est dispensée conformément à la politique. 

La capture d’écran suivante montre un instantané de la politique HIPAA avec une section spécifique décrivant l’exigence de formation. Veuillez noter qu’il ne s’agit que d’un exemple et non d’un document/mise en œuvre complet, on s’attend à ce que l’éditeur de logiciels indépendants dispose d’un processus établi qui s’applique à son organisation. 

Exemple 1 – Formation des utilisateurs HIPAA via un processus administratif

Dans la capture d’écran suivante, la diapositive de présentation du cours présente un résumé des objectifs du cours. Si la formation est construite en interne, le matériel de formation doit être fourni pour révision, veuillez noter que le matériel complet doit être soumis et pas seulement une capture d’écran du résumé.

La capture d’écran suivante montre le registre de présence des employés qui ont participé à la formation. Le dossier indique également le score de passage ainsi que la date prévue de la prochaine formation.

Le deuxième exemple montre comment utiliser Microsoft 365 Defender pour définir et lancer des campagnes de formation.

Exemple 2 : formation des utilisateurs HIPAA via la plateforme de simulation d’attaque Microsoft 365 Defender (tous les utilisateurs)

La capture d’écran précédente montre la campagne de formation à la sécurité HIPAA, la durée totale en minutes, ainsi que le status d’achèvement. La capture d’écran suivante fournit une vue d’ensemble des utilisateurs auxquels la formation a été affectée et du status de formation qui démontre la réussite.

Exemple 3 – Formation des utilisateurs HIPAA via la plateforme de simulation d’attaque Microsoft 365 Defender (utilisateur individuel)

Alors que l’exemple précédent visait à démontrer que tous les utilisateurs ont terminé la campagne de formation annuelle, le dernier exemple montre des preuves ciblées démontrant l’achèvement pour un employé.

Vous pouvez observer dans les deux captures d’écran précédentes que dès le lancement de la campagne de formation, chaque collaborateur a reçu un e-mail confirmant le devoir de formation et la date d’échéance, ainsi que les modules attribués, la durée, etc.

À l’aide du lien disponible dans la notification par e-mail, la capture d’écran suivante montre la page Devoirs de formation pour l’utilisateur et les deux modules qui ont maintenant été terminés.

Objectif : En vertu de la règle de sécurité HIPAA, un plan de sauvegarde des données et un plan de reprise après sinistre sont obligatoires pour toute « entité couverte » qui traite des informations de santé protégées électroniques (ePHI). Ces plans font partie de la stratégie d’urgence qui vise à assurer la disponibilité et la sécurité des ePHI en cas d’urgence ou d’autre événement qui endommage les systèmes contenant des ePHI. 

L’objectif du plan de sauvegarde des données est de créer et de maintenir des copies identiques récupérables d’ePHI, ce qui devrait également inclure des tests périodiques des sauvegardes pour s’assurer que la récupération des données est possible. L’objectif du plan de reprise après sinistre est de restaurer les données potentiellement perdues en cas de sinistre, ce qui doit préciser les étapes à suivre pour restaurer l’accès aux données, y compris la manière dont les fichiers doivent être restaurés à partir des sauvegardes. 

Lignes directrices : Veuillez fournir la version complète du plan/de la procédure de reprise après sinistre qui doit couvrir le plan de sauvegarde et le plan de récupération. Fournissez le document PDF/Word réel s’il s’agit d’une version numérique, si le processus est maintenu via une plateforme en ligne, fournir une exportation PDF ou si vous ne pouvez pas exporter en raison des limitations de la plateforme, veuillez fournir des captures d’écran couvrant l’ensemble de la politique. 

Exemple de preuve : la capture d’écran suivante montre des instantanés de la politique de sécurité HIPAA contenant une vue d’ensemble de la procédure de sauvegarde générale et de haut niveau et du plan de reprise après sinistre. 

Remarque : cette capture d’écran montre un instantané du document de politique/processus, il s’agit simplement d’un exemple, et l’on s’attend à ce que les éditeurs de logiciels indépendants partagent la documentation complète de la politique/procédure de prise en charge réelle et ne fournissent pas simplement une capture d’écran.

Livres

Murdoch D. (2018) Manuel de l’équipe bleue : Édition de la réponse aux incidents : Un guide de terrain condensé pour le répondant aux incidents de cybersécurité. 2e édition, éditeur : CreateSpace Independent Publishing Platform.

Références

• Rapports sur la cybercriminalité de lutte contre la fraude Disponible à l’adresse : https://www.actionfraud.police.uk/ (Consulté le 10/12/2023).

• UE. (2021) Liste de contrôle du RGPD pour les responsables du traitement des données Disponible à l’adresse : https://gdpr.eu/checklist/ (Consulté : 10/12/2023).

• Microsoft. (2018) Journalisation des événements (Windows Installer) Disponible sur : Journalisation des événements (Consulté : 05/03/2024).

• Technologies positives. (2020) Comment aborder le développement de logiciels sécurisés Disponible sur : https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Consulté le 12/10/2023).

• Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/46/CE (Règlement général sur la protection des données) (Texte présentant de l’intérêt pour l’EEE) (2016) Disponible à l’adresse : https://www.legislation.gov.uk/eur/2016/679/contents (Consulté le 12/10/2023).

• Métriques de sécurité. (2020) Guide des métriques de sécurité pour la conformité PCI DSS. Disponible à l’adresse : https://info.securitymetrics.com/pci-guide-2020(Consulté le : 10/12/2023).

• Williams J. Classement des risques OWASP Disponible à l’adresse : https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (Consulté : 10/12/2023).

• Qualys. (2014) SSL Labs : Nouvelles notes pour les problèmes de confiance (T) et d’incompatibilité (M) Disponible sur : https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues (Consulté : 10/12/2023).

• NIST SP800-61r2 : Guide de gestion des incidents de sécurité informatique Disponible à l’adresse : https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (Consulté le : 10/12/2023).

• Création d’un pipeline CI/CD avec Azure Pipelines et Google Kubernetes Engine | .NET

• Google Cloud (consulté : 10/10/2023).

• Le plan de reprise après sinistre à l’adresse : https://www.sans.org/white-papers/1164/ (Consulté : 10/10/2023).

• https://github.com/ (Consulté : 10/10/23).

• Modèles de stratégie de sécurité à : https://www.sans.org/information-security-policy/ (Consulté le : 10/10/23).

• https://www.openedr.com/ (Consulté : 10/02/23).

• https://www.atlassian.com/software/confluence (Consulté : 10/10/23).

• https://www.atlassian.com/software/jira (Consulté le 28/09/23).

• Modèle d’exercice de table du plan de continuité des activités (PCA) à l’adresse suivante : https://www.pivotpointsecurity.com/services/business-continuity-management/table-top-exercise-template/ (Consulté le 10/10/23).

• Résumé de la règle de sécurité HIPAA | HHS.gov (consulté le 18/10/2023).

• Lois sur la confidentialité des informations de santé à l’ère numérique : HIPAA ne s’applique pas – PMC (nih.gov) (consulté le 18/10/2023).

• Quel est l’objectif de la loi HIPAA ? Mise à jour 2023 (hipaajournal.com) (Consulté le 18/10/2023).

• Qu’est-ce qui est considéré comme des RPS en vertu de la loi HIPAA ? Mise à jour de 2023 (hipaajournal.com) (Consulté le 18/10/2023).

• Politiques et procédures HIPAA (hipaajournal.com) (consulté le 18/10/2023).

• Conception de stratégies HIPAA & de stratégies d’administration | Dash Solutions (dashsdk.com) (consulté le 18/10/2023).

• 45 CFR § 164.304 - Définitions. | Code électronique des réglementations fédérales (e-CFR) | Droit américain | LII

• / Institut d’information juridique (cornell.edu) (consulté le 18/10/2023).

• Qu’est-ce que la conformité HIPAA ? Lois & règles HIPAA | Proofpoint Royaume-Uni (Consulté le 18/10/2023).

• Règles, réglementations et normes de sécurité HIPAA (training-hipaa.net) (consulté le 18/10/2023).

• Résumé de la règle de sécurité HIPAA | HHS.gov (consulté le 18/10/2023).

• SP 800-66 Rev. 1, Un guide de ressources d’introduction pour la mise en œuvre de larègle de sécurité de la loi sur la portabilité et la responsabilité de l’assurance maladie (HIPAA) | CSRC (nist.gov) (Consulté le 18/10/2023).

• La règle de sécurité | HHS.gov (consulté le 18/10/2023).

• https://www.hipaajournal.com/hipaa-encryption-requirements (Consulté : 19/10/2023).

• https://www.hipaajournal.com/hipaa-privacy-rule/ (Consulté : 19/10/2023).

• https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html (Consulté : 19/10/2023).

• https://www.tausight.com/the-ultimate-guide-to-electronic-protected-health-information- ephi/ (Consulté le 19/10/2023).

• Configurer le chiffrement – Manuel MongoDB (consulté le 19/10/2023).

• https://its.ucsc.edu/policies/docs/hipaa-risk-analysis.doc (Consulté : 19/10/2023).

• Protection contre la perte de données Microsoft Purview : Annonce de la disponibilité générale de plusieurs fonctionnalités

• Hub de la communauté Microsoft (consulté : 24/10/2023).

• 45 CFR § 164.308 - Garanties administratives. | Code électronique des réglementations fédérales (e-CFR)

• | Droit américain | LII / Institut> d’information juridique (cornell.edu) (consulté le 24/10/2023).

• Quand devons-nous fournir des informations sur la confidentialité ? | ICO (Consulté : 11/08/2023).

• Comment devons-nous rédiger nos informations de confidentialité ? | ICO (Consulté : 11/08/2023).

• Cadre de responsabilisation | ICO (Consulté : 11/08/2023).

• ISO 27001 Exigence 5.1 - Leadership & Engagement | ISMS.online (Consulté : 11/08/2023).

• Plateforme de navigation en ligne (OBP) (iso.org) (consulté le 11/08/2023).

• Clause 5.3 Rôles, responsabilités et pouvoirs organisationnels - Formation ISO (Consulté le 08/11/2023).

• 5.3 Rôles, responsabilité et autorité (iso9001help.co.uk) (consulté le 08/11/2023).

• Dépersonnalisation et réidentification des informations personnelles dans les ensembles de données à grande échelle à l’aide de la protection des données sensibles| Centre d’architecture cloud | Google Cloud (consulté le 11/08/2023).

• Dépersonnalisation des données sensibles | Documentation sur la protection des données sensibles | Google Cloud (consulté le 11/08/2023).

• Un guide sur la sécurité des données | ICO (Consulté : 11/08/2023).

• Transferts internationaux de données | ICO (Consulté : 11/08/2023).

• Gestion et sécurité des enregistrements | ICO (Consulté : 11/08/2023).

• ISO 27701 - Gestion des informations relatives à la confidentialité (Consulté : 11/08/2023).

• Système de gestion des informations relatives à la confidentialité (PIMS) ISO 27701 | ISMS.Online (consulté le 11/08/2023).

Images/textes extraits de documents Microsoft

• https://www.sans.org/information-security-policy/ (Consulté le 18/02/21).

• Obtenir des analyses comportementales et la détection d’anomalies (consulté le 05/03/24).

• Que sont les alertes Azure Monitor ? (Consulté le 05/03/24).

• Obtenir des analyses comportementales et la détection d’anomalies

• (Consulté le 05/03/24).

• Gérer les alertes de sécurité et y répondre dans Microsoft Defender pour le cloud (consulté le 24/03/03).

• Gérer les alertes de sécurité et y répondre dans Microsoft Defender pour le cloud (consulté le 24/03/03).

• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (Consulté le 10/09/23).

• Qu'est-ce qu'Azure Information Protection ?

• Chiffrement transparent des données pour SQL Database, SQL Managed Instance et Azure Synapse Analytics (consulté le 05/03/24).

• Démarrage rapide : créer une affectation de stratégie pour identifier les ressources non conformes (Accès : 05/03/24).

• Configure Protection avancée contre les menaces pour la base de données Azure SQL (consulté le 05/03/24).

• Sauvegarde et restauration dans Azure Database pour MySQL - Serveur flexible (consulté le 05/03/24).

• Inventaire des certificats (consulté le 05/03/24).

• Sauvegarde et restauration dans Azure Database pour MySQL (consulté le 24/03/03).

• https://github.com/microsoft/presidio/blob/main/docs/samples/deployments/data- factory/presidio-data-factory-template-gallery-http.md (consulté le 11/08/2023).

En savoir plus

• Exemple de guide des preuves - Vue d’ensemble
• Exemple de guide des données probantes - Opérations