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

Ce domaine de sécurité est conçu pour garantir que toutes les données consommées à partir de Microsoft 365 sont correctement protégées en transit et au repos. Ce domaine garantit également que les préoccupations de confidentialité des consommateurs (personnes concernées par les données) sont satisfaites par l’ÉDITEUR de logiciels indépendants, conformément au RGPD (Règlement général sur la protection des données) et HIPAA (Health Insurance Portability and Accountability Act of 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 correctement protégées. Cette section traite de la protection des communications de données sur Internet.

Contrôle n° 1

Fournissez des preuves pour tous les éléments suivants :

• Vérifiez que votre configuration TLS est TLS 1.2 ou version ultérieure.

• Un inventaire des clés et certificats approuvés est conservé et tenu à jour.

Intention : TLS

L’objectif de ce sous-point est de s’assurer que les données Microsoft 365 consommées par votre organization sont transmises en toute sécurité. La configuration du profil TLS est utilisée pour définir des exigences spécifiques au protocole TLS qui permettent de garantir que le trafic est sécurisé contre les attaques de l’intercepteur.

Recommandations : TLS

Le moyen le plus simple d’en faire la preuve consiste à exécuter l’outil de test qualys SSL Server sur TOUS les écouteurs web, y compris ceux qui s’exécutent 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 des preuves de vérifications individuelles. Pour fournir des preuves 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 examinent la sortie complète de l’analyse pour confirmer que toutes les exigences de configuration du profil TLS sont remplies. On s’attend à ce que des analyses soient fournies pour tous les points de terminaison exposés publiquement (adresses IP et URL) à l’environnement principal qui est dans l’étendue. Selon les preuves fournies, les analystes peuvent exécuter 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 s’assurer qu’un inventaire complet des clés et certificats approuvés est maintenu, ce qui implique l’identification de différents systèmes, services et applications qui dépendent de ces éléments de chiffrement.

Recommandations : clés et certificats

La preuve doit démontrer qu’un inventaire des clés et certificats approuvés existe et est maintenu. En outre, les preuves applicables des outils utilisés pour stocker les clés et les certificats réels peuvent être fournies, telles qu’Azure Key Vault, HashiCorp Vault Secrets, Confluence Cloud, etc.

Exemple de preuve : clés et certificats

La capture d’écran suivante montre qu’une clé et un inventaire de certificats sont conservés 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 cyphers 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 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 en ligne.

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

Exemple de preuve : clés et certificats

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

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

Remarque : ces exemples ne sont pas des captures d’écran en plein écran. Vous devrez envoyer 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.

Contrôle n° 2

Veuillez fournir des preuves pour tous les éléments suivants :

• Montre que la compression TLS est désactivée pour tous les services publics qui gèrent les requêtes web afin d’empêcher CRIME (Compression Ratio Info-leak Made Easy).

• Vérifie que TLS HSTS est activé et configuré sur 180 jours sur tous les sites.

Intention : TLS

• L’attaque CRIME (Compression Ratio Info-leak Made Easy (CVE-2012-4929)) est une vulnérabilité dans la compression des protocoles SSL (Secure Sockets Layer)/Transport Layer Security (TLS). Pour cette raison, les recommandations du secteur sont 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 via un champ d’en-tête de réponse HTTPS nommé « Strict-Transport-Security ».

Recommandations : TLS

Cela peut être démontré par le biais de 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 examine la sortie complète pour confirmer que toutes les exigences de configuration du profil TLS sont remplies (veuillez fournir des captures d’écran de la sortie d’analyse complète). Selon les preuves fournies, les analystes peuvent exécuter leur propre analyse Qualys.

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

securityheaders.com comme indiqué dans les exemples suivants. Preuve supplémentaire

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 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 le scanneur SSL Qualys ou les en-têtes de sécurité sont utilisés, on s’attend à ce que le rapport complet soit fourni pour une révision.

Données au repos

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

Contrôle n° 3

Fournissez des preuves démontrables 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 AES, Blowfish, TDES et des tailles de clé de chiffrement de 128 bits et 256 bits.

Intention :

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

Recommandations :

Des preuves peuvent être fournies au moyen de captures d’écran, montrant le chiffrement utilisé pour protéger les données M365 dans les bases de données et d’autres emplacements de stockage. La preuve doit 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 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 transparent des données 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, les captures d’écran complètes n’ont pas été utilisées, mais toutes les captures d’écran de preuve envoyées par l’éditeur de logiciels indépendant doivent être des captures d’écran complètes montrant l’URL, l’heure et la date de connexion de l’utilisateur et du système.

Exemple de preuve :

La capture d’écran suivante montre le stockage Azure configuré avec le chiffrement pour les objets blob et les fichiers. La capture d’écran suivante montre la page de documentation Microsoft Azure Storage encryption pour les données au repos montrant que Le Stockage Azure utilise AES-256 pour le chiffrement.

Conservation, sauvegarde et suppression des données

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 de menace compromet l’environnement des éditeurs de logiciels indépendants. Pour réduire ce risque, les organisations doivent conserver uniquement les données dont elles ont besoin pour fournir des services, et non les données qui « pourraient » être utilisées à l’avenir. En outre, les données ne doivent être conservées que le temps nécessaire pour fournir les services pour 20000. 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 rétention définie, elles doivent être supprimées de manière sécurisée afin que les données ne puissent pas être reconstruites ou récupérées.

Contrôle n° 4

Fournissez la preuve qu’une période de conservation des données approuvée est formellement établie et documentée.

Intention :

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, comme, 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 liés à l’organisation. En comprenant les exigences en matière de données des organisations et la durée pendant laquelle les données sont nécessaires pour que l’entreprise puisse remplir ses fonctions, les organisations peuvent s’assurer que les données sont correctement supprimé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, car il est agréable d’avoir juste au cas où. Toutefois, si l’organization n’a pas besoin des données pour exécuter son service ou sa fonction métier, les données ne doivent pas être stockées, car cela augmente inutilement le risque de l’organization.

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

Recommandations :

Fournissez la stratégie de conservation complète des données qui détaille clairement la durée pendant laquelle les données (qui doivent couvrir tous les types de données) doivent être conservées pour permettre à l’entreprise d’exécuter ses fonctions métier.

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. Les éditeurs de logiciels indépendants doivent partager la documentation réelle sur la stratégie/procédure de prise en charge et ne pas simplement fournir une capture d’écran.

Contrôle n° 5

Démontrez que les données sont conservées uniquement pendant la période de rétention définie, comme indiqué dans le contrôle 4.

Intention :

L’objectif de ce contrôle est simplement de valider que les périodes de conservation des données définies sont respectées. Comme nous l’avons déjà vu, les organisations peuvent avoir l’obligation légale de s’y conformer, mais également en conservant les données nécessaires et aussi longtemps que nécessaire permet de réduire le risque pour le organization en cas de violation de données. Cela garantit que les données ne sont ni conservées pendant une durée excessive ni supprimées prématurément, ce qui peut présenter des risques de nature variable (juridique, opérationnelle ou liée à 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 différents 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 rétention des données définie. Voici quelques exemples de captures d’écran acceptables :

• Enregistrements de base de données avec un champ de date, recherchés dans l’ordre d’enregistrement le plus ancien et/ou
• Emplacements de stockage de fichiers affichant les horodatages qui se trouvent dans la période de rétention. Remarque : Toutes les données client personnelles ou sensibles doivent être rédigées dans la capture d’écran.
• Enregistrements de sauvegarde indiquant 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 montrant le contenu de la table de base de données classé par ordre croissant sur le champ « DATE_TRANSACTION » pour afficher les enregistrements les plus anciens dans la base de données. Cela montre que les données datent de moins de deux mois, ce qui ne dépasse pas la période de rétention définie.

Remarque : Il s’agit d’une base de données de test. Par conséquent, elle ne contient pas beaucoup de données historiques.

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 envoyées par l’éditeur de logiciels indépendant doivent être des captures d’écran complètes montrant l’URL, l’heure et la date de connexion de l’utilisateur et du système.

Contrôle n° 6

Démontrer que des processus sont en place pour supprimer en toute sécurité les données après leur période de rétention.

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 de manière sécurisée. 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 au sein d’un partage de fichiers peut être configuré en tant que travail CRON. Capture d’écran du travail CRON montrant la planification et le script 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 -WHERE DateAdd est -30 jours, ce qui vide tous les enregistrements conservés antérieurs à 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, les captures d’écran complètes n’ont pas été utilisées, mais toutes les captures d’écran de preuve envoyées par l’éditeur de logiciels indépendant doivent être des captures d’écran complètes montrant l’URL, l’heure et la date de connexion de l’utilisateur et du système.

Exemple de preuve :

La capture d’écran suivante a été extraite de la stratégie de rétention des données Contoso (à partir du contrôle 4) : elle montre les procédures utilisées pour la destruction des données.

Remarque : cette capture d’écran montre un instantané d’un document de stratégie/processus. Les éditeurs de logiciels indépendants doivent partager la documentation réelle sur la stratégie/procédure de prise en charge et ne pas simplement fournir 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 a été créée à partir des 30 jours suivant l’expiration de la stratégie de conservation des enregistrements de données. Ce travail est défini pour s’exécuter tous les mois le dernier jour du mois.

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

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

Ces captures d’écran ne sont que des exemples des différentes façons d’aborder cette approche.

Contrôle n° 7

Fournissez des preuves démontrant que :

• Un système de sauvegarde automatisé est en place et configuré pour effectuer des sauvegardes à des heures planifiées.

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

• Des contrôles d’accès et des mécanismes de protection appropriés (par exemple, des sauvegardes immuables) sont implémentés pour garantir que les sauvegardes/captures instantanées système sont sécurisées contre les accès non autorisés et pour garantir la confidentialité, l’intégrité et la disponibilité des données de sauvegarde.

Intention :

L’objectif de ce contrôle est de vérifier que le organization dispose d’un système de sauvegarde automatisé, configuré pour exécuter des sauvegardes à des heures prédéterminées.

Recommandations :

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 de la sauvegarde est effectuée automatiquement par la solution, cela peut être pris en charge en fournissant la documentation du fournisseur.

Exemple de preuve :

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

La capture d’écran suivante est effectuée une fois qu’un délai est écoulé 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 instantané est planifiée immédiatement après la création d’un serveur et d’autres sauvegardes instantané sont effectuées une fois par jour.

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

Intention :

L’objectif de ce contrôle est de démontrer que les informations de sauvegarde sont non seulement générées conformément à la planification, mais qu’elles sont également fiables et qu’elles conservent leur intégrité au fil du temps. Pour atteindre cet objectif, des tests périodiques seront effectués sur les données de sauvegarde.

Recommandations :

Les preuves permettant de respecter ce contrôle dépendent du processus et de la procédure de l’organization pour tester les données de sauvegarde. Des preuves peuvent être fournies montrant que les sauvegardes ont été testées avec succès, ainsi que les enregistrements de l’historique d’achèvement des tests.

Exemple de preuve :

La capture d’écran suivante montre qu’une procédure de planification et de restauration de sauvegarde existe et est conservée, 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 montre une page d’enregistrements historiques des tests de sauvegarde pour chacun des systèmes applicables. Notez que sur le côté droit de la table, les tickets JIRA sont référencés pour chacun des tests.

Les quatre captures d’écran suivantes montrent le processus de restauration de bout en bout de l’Azure Database pour MySQL à partir d’un instantané. À l’aide de l’option « Restauration rapide », 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 les instantané à partir desquels la base de données sera restaurée sont sélectionnés, nous pouvons lancer le déploiement. Notez que notre instance de base de données est maintenant appelée « test ».

Après un total de cinq minutes, la base de données SQL a été restaurée avec succès et entièrement à partir de la instantané de sauvegarde, comme le montre l’exemple suivant.

Une fois le test terminé, conformément au processus, un ticket JIRA a été créé pour enregistrer le test de sauvegarde et les détails de la restauration effectuée. Cela garantit que les données historiques sont disponibles à des fins de conformité ainsi que des enregistrements complets à examiner en cas d’incident ou de sinistre pour permettre au organization d’effectuer une analyse de la cause racine.

Intention :

À partir du contrôle précédent, les contrôles d’accès doivent être implémentés pour limiter l’accès aux seuls utilisateurs individuels responsables des données de sauvegarde. En limitant l’accès, vous limitez le risque que des modifications non autorisées soient effectuées et que vous introduisez ainsi des modifications non sécurisées. Une approche avec des privilèges minimum doit être adoptée pour protéger les sauvegardes.

Pour protéger correctement les données, les organisations doivent savoir quelles données leur environnement/systèmes consomment et où les données sont stockées. Une fois que cela est entièrement compris et documenté.

Les organisations sont alors en mesure non seulement d’implémenter une protection des données adéquate, mais également de consolider l’emplacement des données pour implémenter la protection plus efficacement. En outre, lorsque les données sont consolidées à aussi peu d’emplacements que possible, il est beaucoup plus facile d’implémenter un RBAC (contrôle d’accès en fonction du rôle) approprié pour limiter l’accès à aussi peu d’employés que nécessaire.

Recommandations :

Des preuves doivent être fournies à partir du système/de la technologie utilisée, montrant les autorisations d’accès aux sauvegardes et solutions de sauvegarde avec la documentation de la liste d’accès approuvée.

Exemple de preuve :

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

Exemple de preuve :

les sauvegardes automatisées Azure SQL base de données et Azure SQL Managed Instances sont gérées par Azure et leur intégrité est une 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. Elles sont également répliquées 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é à aussi peu 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 doit être limité aux utilisateurs ayant un besoin professionnel légitime d’accès pour remplir leur rôle professionnel. Un processus bien documenté et bien établi pour demander l’accès doit être implémenté. L’accès aux données et aux clés de chiffrement doit suivre le principe du moindre privilège.

Contrôle n° 8

Fournir des preuves pour démontrer qu’une liste d’individus ayant accès aux données et/ou aux clés de chiffrement :

• est conservé, y compris la justification métier pour chaque individu.

• ont été officiellement approuvés en fonction des privilèges d’accès requis pour leur fonction de travail.

• sont configurés avec les privilèges décrits dans l’approbation.

Intention :

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 garantir que l’accès des employés aux données et/ou aux clés de chiffrement est limité aux employés qui ont clairement besoin d’un tel accès.

Recommandations :

Documentation ou captures d’écran de 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 métier de la raison pour laquelle ces personnes doivent avoir accès. 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 stratégie/processus, dont l’attente est que les éditeurs de logiciels indépendants partagent la documentation réelle sur la stratégie/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 de travail. Cela garantit que les employés dépourvus d’une véritable raison d’accès n’obtiennent pas d’accès inutile.

Recommandations :

En règle générale, les preuves fournies pour le contrôle précédent peuvent aider à prendre en charge 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 déclenchée et approuvée pour l’accès au sein d’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) pour accorder ou refuser l’accès aux données sensibles et/ou aux clés de chiffrement. Cette image montre qu’une demande a été créée dans Jira pour obtenir l’approbation quotidienne de Sam pour les clés de chiffrement sur l’environnement principal des systèmes. Il s’agit de l’étape suivante où l’autorisation écrite a été obtenue.

Cela montre que la demande d’accorder l’accès quotidien à Sam a été approuvée par Jon Smith une personne de la direction. (Notez que l’approbation doit provenir d’une personne disposant d’une autorité suffisante 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 Terminé, sauf si le processus d’approbation est automatisé et ne peut donc pas être contourné.

Le tableau du projet montre maintenant qu’une approbation a été donnée pour l’accès de Sam Daily aux clés de chiffrement. Le backlog suivant montre l’approbation de la demande de Sam Daily et la personne affectée pour effectuer le travail.

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

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 de preuve envoyées par l’éditeur de logiciels indépendant doivent être des captures d’écran complètes montrant l’URL, l’heure et la date de connexion de l’utilisateur et du système.

Exemple de preuve :

Dans l’exemple suivant, l’accès administrateur et les autorisations de contrôle total ont été demandés pour un utilisateur sur la base de données de production. La demande a été envoyée pour approbation, comme indiqué à droite de l’image, comme indiqué à gauche.

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

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 de preuve envoyées par l’éditeur de logiciels indépendant doivent être des captures d’écran complètes montrant l’URL, l’heure et la date de connexion de l’utilisateur et du système.

Intent

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

Recommandations :

La preuve peut être fournie par le biais d’une capture d’écran montrant les privilèges d’accès aux données et/ou à la clé de chiffrement accordés aux personnes échantillonnées. Les preuves doivent couvrir tous les emplacements de données.

Exemple de preuve :

Cette capture d’écran montre les autorisations accordées à l’utilisateur « John Smith » qui seraient croisées

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

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

Contrôle n° 9

Fournissez la preuve que :

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

• Des contrats de partage de données sont en place avec tous les tiers qui consomment 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 développer un bon processus de diligence et de gestion tiers pour s’assurer que ces tiers stockent/traitent les données de manière sécurisée et qu’ils respectent toutes les obligations légales qu’elles peuvent avoir, par exemple en tant que sous-traitant de 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 éléments suivants :

• quel(s) service(s) est(sont) fournis

• quelles données sont partagées

• pourquoi les données sont partagées

• informations de contact clés (par exemple, contact principal, contact de notification de violation, DPO, etc.)

• renouvellement/expiration du contrat

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

Recommandations :

Fournissez une documentation détaillant toutes les parties tierces avec lesquelles les données Microsoft 365 sont partagées.

Remarque : Si des tiers ne sont pas utilisés, cela doit être confirmé par écrit (e-mail) 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 de preuve envoyées par un éditeur de logiciels indépendant doivent être des captures d’écran complètes montrant l’URL, l’heure et la date de connexion de l’utilisateur et 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, les captures d’écran complètes n’ont pas été utilisées, mais toutes les captures d’écran des preuves envoyées par l’éditeur de logiciels indépendant doivent être des captures d’écran complètes montrant l’URL, l’heure et la date de connexion de l’utilisateur et du système.

Intention :

Lorsque les données M365 sont partagées avec des tiers, il est important que les données soient gérées de manière appropriée et sécurisée. Des accords de partage de données doivent être en place pour s’assurer que les tiers traitent les données uniquement en fonction des besoins et qu’ils comprennent leurs obligations en matière de sécurité. La sécurité d’une organisation est aussi forte que le lien 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.

Recommandations :

Fournissez les accords 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’un contrat de partage de données.

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

Confidentialité

La conformité de la confidentialité et la gestion des informations sont essentielles pour protéger les droits des individus et garantir une gestion responsable des données. Pour qu’un organization d’établir un système d’information sur la confidentialité efficace, ils doivent être conscients des données personnelles qu’ils détiennent et de la finalité du traitement et du stockage de ces données. Un organization doit mapper 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

Indiquez que votre organization :

A) Tient à jour un inventaire de toutes les données personnelles collectées, traitées et stockées, y compris l’objectif de chaque élément de données. 

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

C) Développe et applique des stratégies qui spécifient les types de données personnelles pouvant être collectées et les objectifs pour lesquels elles peuvent être utilisées. 

D) Permet aux utilisateurs de refuser le traitement ou l’exposition générale de leurs données personnelles et non essentielles à l’entreprise. 

Intention :

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

Recommandations :

Ce contrôle peut être démontré comme suit :

A) Fournissez une version actuelle de l’enregistrement des activités de traitement (RoPA) du organization (voir l’article 30 du RGPD) ou un document similaire détaillant les éléments de données et les objectifs 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 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 donné de données, qui peut être partiellement expurgée tant que la preuve peut fournir l’assurance que la RoPA est en place. 

Non conforme : les enregistrements n’existent pas, sont très anciens/obsolètes ou ne contiennent pas de champs clés. 

B) À des fins de « réduction des données » (voir l’article 5.1.c du RGPD), fournissez tous les formulaires utilisés pour obtenir des données, qu’il s’agisse d’une connexion en ligne, à l’aide de tablettes ou d’appareils similaires (par exemple, dans le cadre d’une conférence) ou d’un papier. Il peut s’agir de modèles/vides. 

Non conforme : les formulaires ont des champs obligatoires qui ne sont pas nécessaires à l’objectif de traitement prévu. 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 disponible publiquement sur le site web de l’organization.  

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

Éléments clés :

Politique/Avis de confidentialité : collecte et utilisation des informations, éléments de données traités, objectifs du traitement, licéité 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 d’annulation (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-il facile à trouver ?). 

Non conforme : aucune fonctionnalité d’annulation claire ou « générique », sans granularité. 

Exemple de preuve :

Pour A) :

Pour B) :

Pour C) :

Pour D) :

Contrôle n° 11 – Sensibilisation de l’utilisateur

Fournissez la preuve que les utilisateurs sont conscients des éléments suivants :

A) qui a accès à ses données

B) qui a accès aux espaces dans lesquels ils travaillent

C) qui peuvent accéder à leurs données par le biais du partage ou des flux de données afin de pouvoir prendre des décisions éclairées.

Intention :

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

Recommandations :

Pour démontrer que cela est en place, dans l’idéal, une forme d’accusé de réception de l’utilisateur (par exemple, pour avoir lu la Politique de confidentialité) doit être en place et enregistrée.

Dans la pratique, il suffit que la Politique de confidentialité (pour les employés) et l’Avis de confidentialité (pour les utilisateurs et les clients) fournissent suffisamment de détails sur les points suivants :

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

Non conforme : il n’existe aucun accusé de réception, ou la politique de confidentialité/avis de confidentialité n’existe pas.

Exemple de preuve :

OR

Contrôle n° 12 – Contrats de traitement des données (DPA)

Fournir une preuve du Contrat de traitement des données, qui doit avoir une liste de tous les tiers/sous-traitants approuvés.

Intention :

Pour vous assurer que vous êtes transparent avec les personnes concernées, en vous assurant qu’elles sont informées sur les tiers/sous-traitants qui pourraient avoir accès à leurs données, le rôle qu’elles jouent dans le traitement (contrôleur de données, processeur de données), leurs responsabilités respectives et les 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 est disponible ici : Adéquation de la protection des données pour les pays non membres de l’UE

À compter du^{13 juin} 2025 :

- Faire partie du Data Privacy Framework (DPF) et listé ici : Data Privacy Framework

- Mettre en place des règles d’entreprise contraignantes (BCR).

- Avoir Standard clauses contractuelles (SCC) en place.

Recommandations :

Les preuves peuvent être effectuées par échantillonnage de deux contrats de traitement des données (DPA) avec des sous-traitants existants. Dans certains cas, les organisations peuvent ne pas avoir de DPA, mais disposeraient d’addendums aux contrats, ou de « clauses de confidentialité ».

Non conforme :

- La liste des 3^{sous-processeurs} /sous-traitants est manquante.

- Aucun détail n’est fourni sur les pays destinataires.

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

Exemple de preuve :

Cet exemple montre un exemple de DPA d’IAPP, ou la preuve peut être un document connexe répertoriant les parties avec lesquelles les données sont partagées.

En outre, case activée les mécanismes de transfert de données en dehors de l’UE.

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

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

     OR

Indiquez le nom de l’évaluation liée à la confidentialité et à la protection des données auxquelles cette révision de confidentialité est liée.

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 individus, en particulier en ce qui concerne l’introduction de nouvelles technologies ou les nouvelles utilisations des technologies existantes. (Voir l’article 35 du RGPD)

Recommandations :

Ce contrôle serait évalué en examinant une DPIA récente ou une documentation d’évaluation connexe.

Non conforme :

Une DPIA doit avoir les éléments suivants :

- Identification de la nécessité d’une DPIA.

- Description du traitement envisagé, y compris l’étendue, le contexte et la ou les objectifs.

- Évaluation de la nécessité et de la proportionnalité.

- Identification et évaluation des risques.

- Identification des mesures de réduction des risques.

- Résultats enregistrés.

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

Exemple de preuve :

Le modèle complet d’une DPIA est disponible sur le site web de l’ICO icidpia-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 fait l’objet d’un contrôle juridique, qu’elles sont protégées et que les utilisateurs sont informés et qu’ils ont la possibilité d’accepter/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 , est classée comme une catégorie spéciale de données.  L’utilisation de données biométriques a fait l’objet d’une analyse de légalité.

Recommandations :

L’utilisation de données biométriques doit faire l’objet d’un contrôle juridique de sorte que ces données doivent être fournies dans le cadre de la collecte de preuves. S’il n’en existe pas, demandez le modèle qui serait utilisé (pour case activée leur préparation).

Non conforme :

Le contrôle juridique sur le traitement des données biométriques doit contenir les éléments suivants :

- Base juridique du traitement (un ou plusieurs des éléments suivants) :

- Répertorier une condition valide pour le traitement des données biométriques (une ou plusieurs des conditions suivantes) :

- Prise en compte de l’utilisation d’alternatives, au lieu des données biométriques.

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

Exemple de preuve :

Sources :

- Article 9 du RGPD – Traitement de catégories spéciales de données : art. 9 RGPD – Traitement de catégories spéciales de données personnelles – Règlement général sur la protection des données (RGPD)

- ICO « Comment traiter les données biométriques de manière légale ? » : Comment traiter les données biométriques de manière légale ? | ICO

Contrôle n° 15 – Insights sur les données

Fournissez la preuve que les métriques n’affichent que des données agrégées et anonymisées sans données identifiables individuellement. Le locataire doit être en mesure de configurer sa limite inférieure de niveau d’agrégation préférée, avec un minimum absolu de 5 autorisé par le produit.

Intention :

L’objectif de ce contrôle est de vous assurer que vous avez implémenté et que vous maintenez le status de données anonymisées et pseudonymes tout au long du cycle de vie des données. (Voir

Recommandations :

Pour vous aider à démontrer que ce contrôle est en place, la preuve via l’interface utilisateur graphique ou l’interface CLI doit fournir pour illustrer :

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

- Exemple de métriques.

Évaluez si l’utilisateur peut configurer un seuil pour ses niveaux d’agrégation préférés à un minimum de 5. La preuve doit démontrer que seul l’élément anonymisé est présent dans l’échantillon de métriques.

Non conforme :

- Les utilisateurs ne sont pas en mesure de personnaliser leurs niveaux d’agrégation à un minimum de 5, ou les compétences techniques requises pour le faire ne peuvent pas être attendues de l’utilisateur standard.

- Les données personnelles sont présentes dans l’exemple de métrique ; par exemple : nom, nom, ID, numéro de client, numéro de téléphone, adresse e-mail, adresse postale, coordonnées bancaires, proches, 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 d’obtention de l’anonymisation.

RGPD

La plupart des organisations traiteront des données potentiellement des données de citoyens européens (personnes concernées). Lorsque les données d’une 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 aux contrôleurs de données (vous capturez directement ces données) ou aux processeurs de données (vous traitez ces données pour le compte d’un contrôleur de données). Bien que cette section ne couvre pas l’ensemble du règlement, elle traite de certains des éléments clés du RGPD afin d’obtenir l’assurance que le organization prend le RGPD au sérieux.

Contrôle n° 16

Fournir des preuves démontrant le respect des droits des personnes concernées en montrant :

A) Facilitation de la demande d’accès (SAR) de l’objet :

Documentation qui confirme que les personnes concernées sont informées de leur droit d’accéder à leurs données personnelles et peuvent soumettre des demandes d’accès aux personnes concernées (RAC) à votre organization.

B) Découverte des données et réalisation sar :

Preuve de la capacité de votre organization à localiser et à récupérer toutes les données personnelles relatives à une personne concernée sur tous les systèmes et dépôts en réponse à un SAR.

Intention :

L’objectif de ce contrôle est de s’assurer que des mécanismes appropriés sont en place pour permettre aux personnes concernées d’effectuer des demandes concernant leurs données personnelles détenues par le organization, et que la réalisation des demandes légitimes est complète. (Voir l’article 15 du RGPD).

Recommandations :

A) L’avis de confidentialité doit contenir des détails sur la façon d’effectuer un sar, qui peut utiliser les méthodes suivantes :

- Utilisation d’un formulaire web fourni par le organization

- Utilisation d’une adresse e-mail fournie par le organization

- Utilisation d’un numéro de téléphone/webchat fourni par le organization

- Utilisation d’une autorité de surveillance (par exemple, l’ICO au Royaume-Uni)

Demander la preuve de la méthode en place ; les captures d’écran doivent être suffisantes.

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).

Les exercices de découverte électronique peuvent également obtenir le même résultat.

Demandez une preuve du processus/flux de travail qui serait utilisé pour répondre à un SAR, ainsi qu’une explication sur la façon dont il a été déterminé que le processus est approfondi et qu’il ne manque aucune donnée personnelle relative à la personne concernée.

Non conforme :

R) Aucune information n’est fournie sur le site web de l’organization (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 de l’objet - Police Care UK

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

Source : Laquelle ? Politique de confidentialité - Laquelle ?

- Webchat :

Source : Effectuer une demande d’accès du sujet à HMRC - GOV.UK

- Via une autorité de surveillance (par exemple, l’ICO) :

Source : Effectuer votre demande d’accès à l’objet | ICO

B) Artefacts de preuve fournis Détaillant les flux de travail ou les descriptions de processus avec des détails techniques suffisants, qui pourraient être utilisés de manière plausible pour répondre à la R-S.

Contrôle n° 17

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

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

B) Les types de données personnelles que votre organization gère (nom, nom, numéro de client, adresse e-mail, numéro de téléphone, etc.). En outre, les sources de données personnelles (par exemple, d’où proviennent les données personnelles), si le organization ne les a pas obtenues directement auprès des personnes concernées.

C) Les objectifs du traitement des données personnelles.

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

E) Parties avec lesquelles votre organization partage des données personnelles.

F) Détails de la durée pendant laquelle les données personnelles seront conservées.

G) Détails des droits des personnes concernées :

• Droit d’être informé

• Droit d’accès

• Droit de rectification

• Droit à l’effacement

• Droit à la restriction du traitement

• Droit à la portabilité des données

• Droit à l’objet

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

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

I) 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).

Intention :

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

Recommandations :

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 les principes mis en évidence ci-dessus.

Non conforme :

Reportez-vous à Control 10.c.

Exemple de preuve :

Reportez-vous à Control 10.c.

HIPAA (Health Insurance Portability and Accountability Act)

La Health Insurance Portability and Accountability Act of 1996 (HIPAA) est une législation fédérale applicable aux citoyens américains et aux organisations 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 loi a chargé le secrétaire du département américain de la Santé et des Services humains (HHS) d’élaborer des règlements protégeant la confidentialité et la sécurité de certaines informations médicales. Certaines organisations peuvent traiter des données potentiellement protégées sur la santé (ePHI), c’est-à-dire des informations médicales identifiables individuellement transmises par des médias électroniques, conservées dans des médias électroniques, ou transmises ou conservées sous toute autre forme ou support. Lorsque les données de santé d’une personne concernée sont traitées, les organisations devront respecter la loi HIPAA.

La loi HIPAA comporte deux lois qui doivent être prises en compte : « La règle de confidentialité » ou « Standards for Privacy of Individually Identifiable Health Information », qui décrit les normes nationales pour la protection de certaines informations de santé, et « The Security Standards » for the Protection of Electronic Protected Health Information également appelée « Règle de sécurité ». Ce dernier établit un ensemble national de normes de sécurité pour la protection de certaines informations médicales qui sont conservées ou transférées sous forme électronique.

D’après une vue d’ensemble générale, « 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 couvertes » doivent mettre en œuvre pour assurer la sécurité des « renseignements médicaux électroniques protégés » (e-PHI). Bien que cette section ne couvre pas l’ensemble du règlement, elle traite de certains des éléments clés de HIPAA pour aider à obtenir une certaine assurance que le organization répond à l’exigence et que le organization protège les informations de santé qu’il traite.

Contrôle n° 18

Fournissez des preuves démontrables que :

• Une stratégie existe pour la gestion HIPAA et HIPAA au sein de votre organization pour le personnel, les sous-traitants, etc.

• L’éditeur de logiciels indépendants garantit la confidentialité, l’intégrité et la disponibilité des ePHI qu’il crée, reçoit, gère ou transmet.

• Protégez-vous contre les menaces et les dangers raisonnablement anticipés pour la sécurité ou l’intégrité de l’ePHI.

Intention :

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

Recommandations :

Cela serait démontré en fournissant la documentation établie de l’organization décrivant la politique et la procédure HIPAA. Les analystes de certification examineront ce point pour s’assurer que toutes les informations fournies dans le contrôle sont traitées.

Exemple de preuve :

Les captures d’écran montrent des instantanés d’une stratégie HIPAA. Remarque : Les éditeurs de logiciels indépendants doivent partager la documentation réelle sur la stratégie/procédure de prise en charge et ne pas simplement fournir une capture d’écran.

Remarque : Il est prévu qu’un éditeur de logiciels indépendant partage la documentation complète sur la stratégie/procédure de prise en charge et ne fournisse pas simplement une capture d’écran.

Intention :

Pour comprendre l’intention de ce sous-point et garantir 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 sous l’article 164.304 :

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

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

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

L’objectif de cette exigence est que les organisations implémentent des mesures de protection/mesures techniques telles que l’accès, l’audit, l’intégrité et les contrôles de transmission au sein de l’infrastructure informatique pour garantir la confidentialité de l’ePHI tout en conservant son intégrité et sa disponibilité pour les utilisateurs autorisés.

Recommandations :

Des preuves peuvent être fournies par le biais des paramètres de configuration des mécanismes de protection utilisés pour garantir que les données ePHI sont sécurisées conformément aux exigences de contrôle. Ces mécanismes peuvent inclure des contrôles d’accès, des procédures d’accès d’urgence, RBAC, le chiffrement, etc.

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

La capture d’écran suivante montre qu’une liste d’accès autorisé des personnes disposant d’autorisations pour gérer les emplacements de stockage ePHI existe et est conservée dans le document de stratégie HIPAA. En outre, dans les captures d’écran qui suivent la liste d’inventaire approuvé, vous pouvez observer que l’accès en écriture est limité sur le cluster, seul l’administrateur et l’analyste de maintenance de base de données pouvant lire et é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 ID utilisateur uniques pour garantir la responsabilité.

La première capture d’écran montre l’emplacement de stockage main/cluster de base de données 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 précise 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é a un ensemble d’autorisations et d’étendue d’accès.

Enfin, la capture d’écran suivante montre du point de vue de la mise en réseau que seule la plage d’adresses IP autorisée, qui est 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. Notez que l’on s’attend à ce que les preuves fournies montrent également les règles d’alerte qui ont été définies en fonction du besoin/de l’implémentation de l’organization. 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 les alertes soient définies et basées sur les journaux d’audit, et que 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 que les journaux peuvent être exportés à des fins d’analyse.

Notez que l’on s’attend à ce qu’il y ait un processus en place pour que les journaux d’audit générés soient analysés, et qu’une preuve du processus d’examen doit également être fournie. Si cette opération est effectuée par programmation, des captures d’écran des paramètres de configuration de l’ingestion du journal dans la plateforme/la solution de journalisation utilisée, ainsi que des captures d’écran des règles doivent être fournies pour révision.

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

Les captures d’écran suivantes montrent que l’emplacement de stockage a des données au repos chiffrées par défaut. 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 en cours d’utilisation, vous vous attendez à 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 l’emplacement de stockage contient des données en transit chiffrées par défaut. La première capture d’écran montre qu’une API de données est activée avec les autorisations « lecture et écriture ».

Une analyse SSL du point de terminaison 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 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).

L’exemple suivant indique qu’il existe une stratégie de rétention pour les instantanés et la restauration à un point dans le temps (PIT).

Intention :

L’intention de ce sous-point s’aligne sur la règle de sécurité qui a été développée pour garantir la flexibilité et la scalabilité afin qu’une « entité couverte » puisse implémenter des stratégies, 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épendent de la nature de l’activité de l'« entité couverte », ainsi que de sa taille et de ses ressources.

Il est essentiel pour chaque organization d’effectuer 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 PHI électroniques. Grâce à cette analyse des risques, les organisations peuvent ensuite implémenter des contrôles de sécurité appropriés pour atténuer ces risques identifiés.

Recommandations :

Les données probantes peuvent être fournies au moyen d’un résultat d’analyse des risques. Lorsque l’analyse des risques est effectuée et gérée via une plateforme en ligne, des captures d’écran de la sortie entière 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 correctement implémentés et fonctionnent comme prévu pour protéger l’ePHI. La deuxième capture d’écran montre une analyse des risques pour les risques identifiés dans l’évaluation des risques et les contrôles de compensation et les atténuations implémentés pour réduire le niveau de risque.

Exemple 1 : Instantané du processus d’évaluation des risques dans l’analyse des risques et de la stratégie HIPAA effectuée

Remarque : cette capture d’écran montre un instantané d’un document d’analyse des risques, il s’agit simplement d’un exemple, et l’attente est 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 l’analyse de la stratégie HIPAA et des risques effectuée (conservée dans confluence Cloud Platform)

La deuxième capture d’écran montre une analyse des risques pour les risques identifiés dans l’évaluation des risques et les contrôles de compensation et les atténuations implémentés pour réduire le niveau de risque. Nous pouvons voir que cela existe et est conservé dans la plateforme cloud Confluence.

Contrôle n° 19

Indiquez que vous (ISV) :

• Protège contre les utilisations ou divulgations raisonnablement anticipées de ces informations qui ne sont pas autorisées par la Règle de confidentialité ; et

• Garantir la conformité à la règle de sécurité par son personnel.

• Plan de sauvegarde et de récupération d’urgence des données sous 164..308 (a)(7)(ii)(A) et 164.308 (a)(7)(ii)(B).

Intent

La règle de confidentialité définit les éléments d’informations médicales protégées (PHI) qui sont couverts par la loi et interdit les utilisations et divulgations inappropriées de PHI. L’objectif de ce sous-point est qu’un organization doit limiter l’accès et l’utilisation des PHI électroniques uniquement à ceux qui en ont besoin à des fins autorisées et qu’ils doivent se conformer à la règle minimale nécessaire, qui leur impose d’utiliser ou de divulguer uniquement la quantité minimale de PHI électroniques nécessaires pour atteindre leur objectif prévu.

Une combinaison de mesures de protection techniques et administratives doit être en place pour restreindre l’utilisation de l’ePHI et faire en sorte que le risque de divulgation de l’ePHI soit réduit.

Recommandations :

Les éléments de preuve fournis doivent montrer les garanties techniques en place telles que les technologies et les mécanismes utilisés pour protéger les PHI électroniques et la façon dont le organization contrôle case activée l’accès et le déplacement de ces données.

Exemple de preuve :

Les captures d’écran suivantes montrent Protection contre la perte de données Microsoft Purview (DLP), qui est une plateforme intégrée qui permet aux organisations de gérer leurs stratégies DLP à partir d’un emplacement centralisé unique.

Vous pouvez observer ci-dessous qu’une stratégie « États-Unis HIPAA améliorée » est activée, ce qui permet d’empêcher les utilisateurs de coller des données sensibles à des sites web spécifiques, notamment des e-mails personnels, des invites d’IA générative, des sites de réseaux sociaux, etc. lorsqu’ils y accèdent 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 l’étendue à laquelle elle est appliquée. 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 précise des configurations spécifiques disponibles s’affiche.

Les deux captures d’écran suivantes montrent la définition de 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 montre les actions configurées pour être effectuées 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 leurs utilisateurs de copier et coller des informations sensibles telles que des informations d’identification personnelle (PII) provenant des bases de données internes du organization dans leurs comptes de messagerie personnels, chatbots et sites de réseaux sociaux sur les navigateurs pris en charge.

Enfin, les notifications utilisateur sont configurées pour notifier et fournir des conseils aux utilisateurs lors de la gestion des données ePHI.

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

Intention :

L’objectif de ce sous-point est qu’un organization doit former son personnel sur la façon de gérer les PHI électroniques de manière sécurisée et appropriée, et qu’il doit appliquer des stratégies et des procédures pour garantir la conformité à la règle de sécurité.

Recommandations :

Les preuves fournies doivent démontrer que la formation HIPAA est effectuée sur la façon de gérer l’ePHI et qu’il existe des enregistrements de présence et d’achèvement de la formation. Le cas échéant, cela peut être pris en charge par la documentation de stratégie et les supports de formation utilisés.

Exemple de preuve :

Les exemples suivants montrent les preuves potentielles qui peuvent être soumises pour démontrer que l’entraînement HIPAA approprié se produit conformément à la stratégie.

La capture d’écran suivante montre un instantané de la stratégie HIPAA avec une section spécifique décrivant la configuration requise pour la formation. Notez qu’il s’agit simplement d’un exemple et non d’un document/implémentation complet. L’on s’attend à ce que les éditeurs de logiciels indépendants disposent d’un processus établi qui s’applique à leur organization.

Exemple 1 : Formation des utilisateurs HIPAA via un processus administratif

Dans la capture d’écran suivante, la diapositive de présentation du cours montre un résumé des objectifs du cours. Si la formation est construite en interne, les supports de formation doivent être fournis pour révision. Veuillez noter que le matériel complet doit être envoyé et pas seulement une capture d’écran du résumé.

La capture d’écran suivante montre l’enregistrement de présence des employés qui ont participé à la formation. L’enregistrement indique également le score de réussite ainsi que la prochaine date prévue de l’entraînement.

Le deuxième exemple montre comment Microsoft 365 Defender peut être utilisé 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 HIPAA Security, la durée totale en minutes, ainsi que l’achèvement status. La capture d’écran suivante fournit une vue d’ensemble des utilisateurs auxquels la formation a été affectée et le status de formation qui illustre la réussite de l’exécution.

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 mettait l’accent sur la démonstration que tous les utilisateurs ont terminé la campagne de formation annuelle, le dernier exemple montre des preuves ciblées démontrant l’achèvement d’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 employé a reçu un e-mail confirmant l’affectation et la date d’échéance de la formation, 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 Affectations de formation pour l’utilisateur et les deux modules qui sont maintenant terminés.

Intention :

En vertu de la règle de sécurité HIPAA, un plan de sauvegarde des données et un plan de récupération d’urgence sont obligatoires pour toute « entité couverte » qui gère les informations d’intégrité électroniques protégées (ePHI). Ces plans font partie de la stratégie d’urgence qui vise à assurer la disponibilité et la sécurité de l’ePHI en cas d’urgence ou d’autre événement qui endommage les systèmes qui contiennent des ePHI.

L’objectif du plan de sauvegarde des données est de créer et de gérer des copies identiques récupérables d’ePHI. Cela doit é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 récupération d’urgence est de restaurer toutes les données potentiellement perdues en cas de sinistre, et cela doit spécifier les étapes à suivre pour restaurer l’accès aux données, y compris la façon dont les fichiers doivent être restaurés à partir des sauvegardes.

Recommandations :

Fournissez la version complète du plan/procédure de récupération d’urgence qui doit couvrir le plan de sauvegarde et le plan de récupération. Fournissez le document PDF/Word réel si dans une version numérique, ou si le processus est géré via une plateforme en ligne, fournissez une exportation PDF ou si vous ne pouvez pas exporter en raison de limitations de la plateforme. Veuillez fournir des captures d’écran couvrant l’ensemble de la stratégie.

Exemple de preuve :

La capture d’écran suivante montre des captures instantanées de la stratégie de sécurité HIPAA contenant une vue d’ensemble de la procédure de sauvegarde générale et générale et du plan de récupération d’urgence.

Remarque : Cette capture d’écran montre une instantané de document de stratégie/processus, il s’agit simplement d’un exemple, et l’attente est que les éditeurs de logiciels indépendants partagent la documentation complète sur la stratégie/procédure de prise en charge et ne fournissent pas simplement une capture d’écran.

Livres

Murdoch D. (2018) Blue Team Handbook: Incident Response Edition: A condensed field guide for the Cyber Security Incident Responding Responder. 2e édition, Éditeur : CreateSpace Independent Publishing Platform.

Références

• Signalement de cyberdéfense sur action fraud Disponible à l’adresse : https://www.actionfraud.police.uk/ (Consulté : 10/12/2023).

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

• Microsoft. (2018) Journalisation des événements (Windows Installer) Disponible à l’adresse : Journalisation des événements (consulté : 05/03/2024).

• Technologies positives. (2020) Guide pratique pour aborder le développement logiciel sécurisé Disponible à l’adresse : https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Consulté : 10/12/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é : 12/10/2023).

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

• Williams J. OWASP Risk Ranking Disponible à l’adresse : https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (consulté : 10/12/2023).

• Qualys. (2014) Ssl Labs : New Grades for Trust (T) and Mismatch (M) Issues disponibles à : 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é : 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 récupération d’urgence à l’adresse : https://www.sans.org/white-papers/1164/ (Accessible : 10/10/2023).

• https://github.com/ (Accès : 10/10/23).

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

• https://www.openedr.com/ (Accès : 02/10/23).

• https://www.atlassian.com/software/confluence (Accès : 10/10/23).

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

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

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

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

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

• Qu’est-ce qui est considéré comme PHI sous HIPAA ? Mise à jour 2023 (hipaajournal.com) (Consulté : 18/10/2023).

• Stratégies et procédures HIPAA (hipaajournal.com) (accessible : 18/10/2023).

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

• 45 CFR § 164.304 - Définitions. | Electronic Code of Federal Regulations (e-CFR) | Loi américaine | LII

• / Legal Information Institute (cornell.edu) (consulté : 18/10/2023).

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

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

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

• SP 800-66 Rev. 1, An Introduction Resource Guide for Implementing the Health InsurancePortability and Accountability Act (HIPAA) Security Rule | CSRC (nist.gov) (consulté le : 18/10/2023).

• Règle de sécurité | HHS.gov (accessible : 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é : 19/10/2023).

• Configurer le chiffrement — Manuel MongoDB (accessible : 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

• Microsoft Community Hub (accessible : 24/10/2023).

• 45 CFR § 164.308 - Protections administratives. | Electronic Code of Federal Regulations (e-CFR)

• | Loi américaine | LII / Legal Information Institute> (cornell.edu) (consulté : 24/10/2023).

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

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

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

• Iso 27001 Condition 5.1 - Leadership & Commitment | ISMS.online (consulté : 11/08/2023).

• Plateforme de navigation en ligne (OBP) (iso.org) (accessible : 11/08/2023).

• Clause 5.3 Rôles, responsabilités et autorités de l’organisation - Formation ISO (accessible : 11/08/2023).

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

• Désidentification et réidentification des informations d’identification personnelle dans des jeux de données à grande échelle à l’aide de la protection des données sensibles| Centre des architectures cloud | Google Cloud (consulté : 11/08/2023).

• Dés-identification des données sensibles | Documentation sur la protection des données sensibles | Google Cloud (consulté : 11/08/2023).

• Guide sur la sécurité des données | ICO (accessible : 11/08/2023).

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

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

• ISO 27701 - Gestion des informations de confidentialité (consulté : 11/08/2023).

• Iso 27701 Privacy Information Management System (PIMS) | ISMS.Online (consulté : 11/08/2023).

Images/texte extraits de Documents Microsoft

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

• Obtenir l’analyse comportementale et la détection des anomalies (accessible : 05/03/24).

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

• Obtenir l’analyse comportementale et la détection des anomalies

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

• Gérer et répondre aux alertes de sécurité dans Microsoft Defender pour le cloud (accessible : 05/03/24).

• Gérer et répondre aux alertes de sécurité dans Microsoft Defender pour le cloud (accessible : 05/03/24).

• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (Accès : 09/10/23).

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

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

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

• Configurer Advanced Threat Protection pour Azure SQL Database (consulté : 05/03/24).

• Sauvegarde et restauration dans Azure Database pour MySQL - Serveur flexible (accessible : 05/03/24).

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

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

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

En savoir plus

• Exemple de guide de preuve - Vue d’ensemble
• Exemple de guide de preuve - Opérations