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 organisation 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.
Les autres outils qui peuvent être utilisés pour vérifier 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’organisation 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’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. 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 une obligation légale de s’y conformer, mais également en conservant les données qui sont nécessaires et aussi longtemps que nécessaire permet de 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 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, par exemple, les bases de données, les partages de fichiers, les archives, etc.) ne dépassent pas la stratégie de rétention des données définie. Voici quelques exemples de captures d’écran :
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 montrant les horodatages qui se trouvent dans la période de rétention Remarque : Toutes les données client personnelles/sensibles doivent être expurgées dans la capture d’écran.
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 l’organisation dispose d’un système de sauvegarde automatisé, qui est configuré pour exécuter des sauvegardes à des moments prédéterminés.
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 à Azure Database pour MySQL, qui est une instance managée. 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 des captures instantanées où la première sauvegarde d’instantané est planifiée immédiatement après la création d’un serveur et d’autres sauvegardes d’instantanés 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 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’organisation 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 d’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 l’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 l’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, afin de permettre à l’organisation 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 l’instance de base de données 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 Database 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 ils sont chiffrés 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’une organisation établisse un système d’information sur la confidentialité efficace, elle doit connaître les données personnelles qu’elle détient et la finalité du traitement et du stockage de ces données. Une organisation 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
Votre organisation dispose-t-elle d’un système PIM (Privacy Information Management) établi, implémenté et géré qui :
Maintient l’engagement de la direction par le biais d’une politique ou d’une autre forme de documentation/système informatisé pour la façon dont vos efforts de gestion des informations de confidentialité sont maintenus à des fins de confidentialité et d’intégrité du système.
Détermine les rôles, les responsabilités et les autorités de chaque personne qui gère le système, y compris les processeurs et les contrôleurs d’informations d’identification personnelle.
Intention :
L’objectif de ce point est de s’assurer qu’une « culture de la protection de la vie privée » existe et qu’elle est soutenue par le leadership de l’organisation par le biais d’un programme efficace de gouvernance de la protection de la vie privée. La direction de l’organisation doit démontrer par la documentation et les processus établis qu’il existe un système de gestion de la confidentialité efficace, que les processus sont alignés sur les objectifs stratégiques de l’organisation et sont établis dans le contexte et les circonstances de l’organisation, et s’assurer que le système de gestion de la confidentialité est incorporé dans les processus métier.
Recommandations :
Cela serait démontré en fournissant la documentation établie de l’organisation décrivant la politique et la procédure de gestion des informations de confidentialité (PIM). 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 suivantes montrent des instantanés d’une stratégie PIM.
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.
Intent
La responsabilité est l’un des principes clés du droit sur la protection des données, car elle permet à une organisation de minimiser les risques associés à sa gestion des données personnelles en mettant en œuvre des stratégies, des procédures et des processus appropriés et efficaces. Ces mesures doivent être proportionnelles aux risques, qui peuvent varier en fonction de la quantité de données traitées ou transférées, de leur sensibilité et de la technologie utilisée. Pour ce faire, chaque employé doit savoir qui est responsable des divers éléments du système de gestion de la vie privée afin d’assurer la mise en œuvre réussie. En disposant d’une documentation établie décrivant les rôles, les responsabilités et les pouvoirs d’une manière clairement définie et en leur attribuant ces rôles de manière appropriée, une organisation peut s’assurer que son système de gestion de la confidentialité est efficace.
Recommandations :
Pour ce faire, il faudrait fournir la documentation établie de l’organisation décrivant les rôles, les responsabilités et les pouvoirs de chaque personne concernée. 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 suivantes montrent des instantanés d’une stratégie PIM montrant une section de la stratégie contenant la liste des employés approuvés.
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.
Contrôle n° 11
Fournissez des preuves des processus pour montrer que :
La réduction des informations d’identification personnelle est en cours.
La désidentification et la suppression des informations d’identification personnelles sont effectuées à la fin de la période de traitement.
Des contrôles sont en place pour la transmission des informations d’identification personnelle, y compris toute confidentialité.
L’enregistrement du transfert des informations personnelles d’un pays ou d’une région à un autre existe avec le consentement explicite.
Intention : PII
L’objectif de la réduction des informations d’identification personnelle (PII) est de s’assurer qu’une organisation collecte, utilise et conserve uniquement la quantité minimale de données personnelles nécessaires pour atteindre un objectif spécifique dans le contexte de l’organisation et dans le cadre de la justification métier. Lors de la gestion des données personnelles, une organisation doit identifier la quantité minimale de données requise pour atteindre cet objectif/tâche et s’assurer que les données minimales requises sont stockées. En réduisant le traitement et le stockage des données personnelles inutiles, une organisation garantit que le niveau de risque associé à l’utilisation incorrecte des données, à l’accès non autorisé et aux violations de données est réduit.
Recommandations : Informations d’identification personnelle
Les preuves peuvent être fournies par le biais des paramètres de configuration de la solution utilisée pour réduire l’utilisation des informations personnelles si cela est effectué via une plateforme automatisée, ou si un processus administratif manuel, la preuve du processus de minimisation et la preuve des enregistrements du processus doivent être fournies à l’analyste pour examen.
Exemple de preuve : PII
La capture d’écran suivante montre qu’une réunion mensuelle périodique est planifiée où toutes les nouvelles données reçues au sein de l’organisation au cours de cette période sont examinées et, le cas échéant, toutes les informations personnelles jugées inutiles sont supprimées.
Dans la capture d’écran suivante, vous trouverez un exemple de formulaire d’inscription utilisateur rempli utilisé pour intégrer de nouveaux clients au sein de la plateforme.
La capture d’écran suivante montre qu’en fonction de la réunion et de la révision de la réduction des piI, il a été considéré que certaines des informations sensibles collectées dans le formulaire ne sont plus nécessaires pour fournir le service à l’utilisateur. Dans l’image suivante, les informations d’identification personnelle des arbitres ont été supprimées, ainsi que l’adresse e-mail (on s’attend à ce que chaque organisation ait une justification professionnelle pour conserver ou supprimer ces informations).
Remarque : le précédent est un exemple d’un scénario potentiel. Elle n’est en aucun cas exhaustive et, lors de la fourniture de preuves, le processus de réduction des piI doit être clairement démontré et s’appliquer au contexte spécifique de l’organisation.
Intention : confidentialité des données
L’objectif de ce sous-point est multidimensionnel et couvre plusieurs techniques et différents concepts, mais l’objectif général est qu’une organisation soit conforme aux réglementations en matière de protection des données en s’assurant que la confidentialité des données au sein de l’organisation est améliorée.
En commençant par la désidentification, qui est le processus de suppression d’informations spécifiques qui peuvent être utilisées pour identifier un individu des données, l’objectif est de s’assurer que toute information considérée comme sensible, comme l’adresse de messagerie, la date de naissance, etc., est modifiée/convertie (par le biais de diverses techniques telles que le pseudonyme ou le masquage) dans un format qui rend inutilisable de les lier directement à un individu. L’objectif de ce processus n’est pas seulement de préserver l’utilité des données, mais également de s’assurer que le niveau de risque associé à l’utilisation incorrecte des données, à l’accès non autorisé et aux violations de données est réduit.
Les organisations doivent définir la conservation des données et supprimer les données inutiles à la fin de la période de traitement. 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 pour garantir qu’elles ne peuvent pas être reconstruites ou récupérées. La conservation des données nécessaires et aussi longtemps que nécessaire permet de réduire le risque pour l’organisation en cas de violation de données. Cela garantit que les données ne sont pas conservées pendant une durée excessivement longue ou 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 : confidentialité des données
Les preuves peuvent être fournies par le biais des paramètres de configuration du mécanisme et/ou de la technique utilisés pour garantir que les données d’identification personnelle sont rendues anonymes et supprimées conformément à l’exigence de contrôle.
Exemple de preuve : confidentialité des données
L’exemple présenté dans les captures d’écran suivantes utilise le modèle d’anonymisation des données intégré d’Azure Data Factory, qui fait partie de la galerie de modèles et nous permet de déplacer un ensemble de fichiers texte d’un emplacement à un autre tout en rendant leur contenu anonyme. Il montre qu’une fabrique de données dans Azure existe pour l’anonymisation des informations d’identification personnelle.
La capture d’écran suivante montre la configuration du pipeline d’anonymisation des informations d’identification personnelle. Il tire parti du code permettant d’utiliser Presidio sur Azure App Service pour appeler Presidio en tant que point de terminaison REST HTTP dans le pipeline Azure Data Factory tout en analysant et en stockant chaque fichier en tant que Stockage Blob Azure.
La capture d’écran suivante montre les étapes et la logique du pipeline.
La capture d’écran finale montre une exécution réussie du pipeline pour rendre anonymes les informations d’identification personnelle.
Remarque : le précédent est un exemple d’un scénario potentiel. Il n’est en aucun cas exhaustif et, lorsque vous fournissez des preuves, le processus d’anonymisation des données personnelles doit être clairement démontré et doit s’appliquer au contexte spécifique de l’organisation.
Exemple de preuve : confidentialité des données
La capture d’écran suivante montre un exemple de résolution de la suppression des informations d’identification personnelle à la fin de la période de traitement en activant une stratégie de gestion du cycle de vie pour le compte de stockage dans Azure où les informations d’identification personnelle sont conservées.
La capture d’écran suivante montre que la rétention est définie pour une période prédéfinie après laquelle les données sont automatiquement supprimées.
Remarque : le précédent est un exemple d’un scénario potentiel. Il n’est en aucun cas complet et, lors de la fourniture de preuves, le processus de suppression des données d’identification personnelle et la période de conservation spécifique applicable doivent être clairement démontrés et doivent s’appliquer au contexte spécifique de l’organisation.
Exemple de preuve : confidentialité des données
La capture d’écran finale montre qu’une stratégie de conservation de la gestion du cycle de vie des données est en place pour le transfert et le stockage des données d’identification personnelle dans différents emplacements de l’organisation, tels que SharePoint, OneDrive, les appareils, la boîte aux lettres, etc. Cette stratégie est activée à l’aide de Microsoft Purview. La stratégie de rétention est configurée pour supprimer automatiquement toutes les informations d’identification personnelle une fois la période de rétention prédéfinie écoulée.
Remarque : le précédent est un exemple d’un scénario potentiel. Il n’est en aucun cas complet et, lors de la fourniture de preuves, le processus de suppression des données d’identification personnelle et la période de conservation spécifique applicable doivent être clairement démontrés et doivent s’appliquer au contexte spécifique de l’organisation.
Intention : contrôles
L’objectif de ce sous-point est de s’assurer que les organisations disposent de mesures de protection techniques et administratives/opérationnelles appropriées pour protéger les informations d’identification personnelle pendant le traitement et la transmission. L’accent mis sur la confidentialité fait référence à la sécurisation des données contre les accès non autorisés et les divulgations par le biais de contrôles techniques et administratifs tels que le chiffrement des données au repos et en transit, les listes de contrôle d’accès documentées et l’audit régulier.
Recommandations : contrôles
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 d’identification personnelle sont protégées conformément à l’exigence de contrôle. Ces mécanismes peuvent inclure des contrôles d’accès, RBAC, chiffrement, protection contre la perte de données, etc.
Clause de non-responsabilité : les exemples présentés montrent quelques scénarios potentiels dans lesquels des contrôles sont appliqués pour garantir la protection des informations d’identification personnelles. Notez que le type de mécanismes de protection en place dépend du contexte de votre organisation et de la façon dont les informations d’identification personnelle sont utilisées, stockées, etc.
Exemple de preuve : chiffrement
Les exemples suivants illustrent le chiffrement des informations d’identification personnelle à l’emplacement de stockage où les informations d’identification personnelle sont conservées et le chiffrement pendant le transit via l’application/plateforme web où les utilisateurs entrent des informations personnelles stockées dans le back-end de l’application.
Les captures d’écran 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 votre propre chiffrement
les clés sont en cours d’utilisation, alors l’on s’attend à ce que ces clés soient correctement sécurisées, et des preuves sont fournies pour le démontrer.
La deuxième capture d’écran montre que TLS1.2 est appliqué en transit pour l’application où les informations d’identification personnelle sont collectées.
Exemple de preuve : contrôles d’accès
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/approuvée, qui est le réseau d’entreprise sécurisé, est autorisée à accéder à l’emplacement de stockage des informations d’identification personnelle.
La capture d’écran suivante montre un exemple d’Azure PIM et la liste d’utilisateurs avec les affectations éligibles. En utilisant l’accès juste-à-temps (JIT), il permet aux utilisateurs d’obtenir un accès temporaire à un rôle ou à une ressource privilégié pendant une durée limitée, ce qui réduit le risque de compromission d’un utilisateur privilégié ou d’introduire des modifications dans l’environnement, les emplacements de données, etc.
Exemple de preuve : prévention de la transmission et de la divulgation des informations d’identification personnelle
Ces captures d’écran montrent la protection contre la perte de données (DLP) Microsoft Purview, 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 « Données PII du Royaume-Uni » est activée. Cela permet d’empêcher les utilisateurs de fournir des données sensibles à des sites web spécifiques, notamment les e-mails personnels, les invites d’IA générative, les sites de réseaux sociaux, etc. lorsqu’ils sont accessibles via un navigateur web pris en charge. Cela garantit que le risque de violation potentielle de la confidentialité ou de divulgation non autorisée d’informations d’identification personnelles par l’employé est réduit à mesure que la stratégie de l’organisation est appliquée à tous les appareils/utilisateurs de l’espace de travail.
La ou les captures d’écran suivantes fournissent une vue d’ensemble 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.
La capture d’écran précédente et 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 à leurs comptes de messagerie personnels, chatbots et sites de réseaux sociaux sur les navigateurs pris en charge.
Intention : enregistrements
L’intention de ce sous-point est double : il garantit que la gestion efficace des enregistrements est en place pour faciliter la gouvernance et la protection des données, tout en garantissant la conformité juridique et la responsabilité, car le transfert d’informations d’identification personnelle entre différents pays implique la navigation dans différentes exigences légales. Avant de lancer un transfert d’informations d’identification personnelles, une organisation doit s’assurer qu’elle a le consentement explicite de la ou des personnes à qui il appartient, ces personnes doivent être informées du transfert, de l’objectif du transfert et du risque associé. L’enregistrement du consentement obtenu valide l’autorisation du transfert. L’enregistrement des transferts doit également contenir des détails supplémentaires sur le transfert, l’évaluation des risques, l’impact sur la protection des données et la période de rétention.
Recommandations : enregistrements
Les preuves qui peuvent être fournies pour les enregistrements de transferts d’informations personnelles et les enregistrements de consentement explicite dépendent de la façon dont le processus de transfert et la gestion des dossiers sont mis en œuvre au niveau de l’organisation. Cela peut inclure si le consentement est obtenu par le biais d’une plateforme, des conditions générales du service ou par le biais de formulaires de consentement remplis par chaque utilisateur. Les éléments de preuve fournis doivent démontrer que les enregistrements historiques des transferts effectués au cours d’une période existent et comment ils sont suivis, ainsi que les enregistrements de consentement explicite obtenus.
Exemple de preuve : enregistrements
La capture d’écran suivante montre un exemple de formulaire de consentement rempli par l’un des utilisateurs des services de l’organisation. Nous pouvons voir que le consentement explicite, l’accusé de réception et la compréhension des conditions ont été fournis par l’utilisateur.
La capture d’écran suivante montre qu’un enregistrement historique des transferts d’informations personnelles existe et inclut des détails sur les données personnelles en cours d’échange, l’objectif du transfert, le pays d’origine, le pays de destination, la protection des données en transit, l’approbation, etc.
Remarque : Le précédent est un exemple de scénario potentiel, il n’est en aucun cas complet et, lors de la fourniture de preuves, le processus de transfert des données d’identification personnelle, la gestion des enregistrements, etc. doit être clairement démontré et doit s’appliquer au contexte spécifique de l’organisation.
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 pour aider à obtenir une certaine assurance que l’organisation prend le RGPD au sérieux.
Contrôle n° 12
Fournissez des preuves montrant que :
Les personnes concernées par les données sont en mesure d’émettre des demandes d’accès partagé.
Vérifiez que vous (l’éditeur de logiciels indépendant) êtes en mesure d’identifier tous les emplacements des données des personnes concernées lors de la réponse à une demande de SAP.
Qu’il existe une période de rétention pour les sauvegardes qui permet aux clients qui demandent la suppression de données par le biais de sars à mesure que les sauvegardes propagées sur une période sont supprimées (cycle de vie des suppressions de sauvegarde les plus anciennes/réécriture).
Intention :
Le RGPD inclut des obligations spécifiques qui doivent être respectées par les organisations qui traitent les données des personnes concernées. L’obligation pour les organisations de gérer les demandes d’accès des personnes concernées (RAC) est incluse dans l’article 12 qui, en vertu de l’article 12.3, donne au responsable du traitement des données un mois à compter de la réception du SAR pour répondre à la demande. Une prolongation est autorisée pour une période supplémentaire de deux mois si nécessaire et seulement si cela est justifié. Même si votre organisation agit en tant que responsable du traitement des données, cela sera toujours nécessaire pour aider vos clients (le contrôleur de données) à remplir leurs obligations en matière de SAP.
Recommandations :
Indiquez le processus documenté pour la gestion des demandes d’accès partagé. Exemple de preuve :
L’exemple suivant montre un processus documenté pour la gestion des SAP.
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 :
L’objectif de ce contrôle est de s’assurer que l’organisation dispose d’un mécanisme robuste pour identifier les données de toutes les personnes concernées. Il peut s’agir d’un processus manuel, car tout le stockage des données est bien documenté, ou d’autres outils peuvent être utilisés pour garantir que toutes les données sont localisées dans le cadre du processus des SAP.
Recommandations :
Les preuves peuvent être fournies par le biais d’une liste de tous les emplacements de données et d’un processus documenté pour rechercher des données dans tous les emplacements de données. Cela inclut toutes les commandes nécessaires pour rechercher des données, c’est-à-dire que si des emplacements SQL sont inclus, des instructions SQL spécifiques sont détaillées pour garantir que les données sont trouvées correctement.
Exemple de preuve :
La capture d’écran suivante est un extrait de la procédure sar précédente qui montre comment les données seront trouvées.
Les quatre images suivantes montrent comment les emplacements des données isV ont été interrogés, et l’Explorateur Stockage a été utilisé pour explorer les fichiers ou les objets blob qui devaient être supprimés du stockage pour se conformer à la demande sars.
Remarque : comme ces exemples ne sont pas des captures d’écran en plein écran, vous devez 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.
Cette requête confirme les comptes de stockage en cours d’utilisation. Vous pouvez interroger et supprimer du stockage, des objets blob et/ou des fichiers à l’aide de l’Explorateur Resource Graph (Kusto) ou de PowerShell (voir ci-dessous).
Remarque : - Pour les exemples de cette section, 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 en plein écran montrant l’URL, l’heure et la date de connexion de l’utilisateur et du système.
L’image suivante montre les données qui ont été trouvées dans le conteneur d’objets blob pour le client qui doit être supprimé et l’action suivante montre l’action de suppression ou de suppression réversible des informations dans l’objet blob.
Notez que les exemples ne sont pas des captures d’écran en plein écran. Vous devez 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.
Intention :
L’objectif de ce contrôle est de démontrer qu’il existe une période de rétention formelle pour les sauvegardes, conçue de manière à prendre en charge la suppression des données conformément aux DSA. L’infrastructure de rétention doit permettre l’élimination progressive des sauvegardes plus anciennes sur une période définie, garantissant ainsi que toutes les données supprimées en raison d’un SAR sont finalement effacées de toutes les sauvegardes. Cela est essentiel pour aligner les pratiques de l’organisation en matière de sauvegarde et de conservation des données avec les obligations découlant des racées, ce qui répond aux exigences réglementaires relatives au droit à l’effacement.
Recommandations :
La preuve peut être fournie par le biais d’une capture d’écran montrant les paramètres de configuration de sauvegarde montrant la période et la méthodologie avec lesquelles les sauvegardes sont effectuées. L’accent doit être mis sur la période de fréquence de sauvegarde.
Exemple de preuve :
La capture d’écran suivante est un extrait de code des paramètres de configuration de la base de données Azure pour MySQL, qui est une instance managée.
Nous pouvons voir dans la capture d’écran que la période de rétention des sauvegardes est définie pour 28 jours.
En fonction de la section de sauvegarde, nous savons que les sauvegardes sur les serveurs flexibles sont basées sur un instantané, la première sauvegarde d’instantané est planifiée immédiatement après la création d’un serveur et les sauvegardes d’instantanés supplémentaires sont effectuées une fois par jour.
La conservation des sauvegardes de 28 jours combinée à la fréquence de sauvegarde signifie que lorsqu’une sauvegarde sar est remplie, la sauvegarde propagée continue pendant un maximum de 27 jours de roulement et diminue comme l’applique la période de rétention jusqu’à ce que toutes ces données utilisateur soient supprimées.
Contrôle n° 13
Veuillez fournir l’avis de confidentialité qui doit contenir tous les éléments requis comme suit :
Détails des entités (nom, adresse, etc.)
Détails du type de données personnelles en cours de traitement.
Détails de la durée pendant laquelle les données personnelles seront conservées.
Détails de la licéité du traitement des données personnelles.
Détails des droits de la personne concernée :
Droit d’être informé
Droit d’accès par la personne concernée
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
Intention :
L’article 13 du RGPD inclut des informations spécifiques qui doivent être fournies aux personnes concernées au moment où les données personnelles sont obtenues. L’objectif de ce contrôle est de s’assurer que la déclaration de confidentialité des données des organisations fournit aux personnes concernées certaines des informations clés incluses dans l’article 13.
Recommandations :
Cela est généralement fourni en fournissant l’avis de confidentialité des données. Les analystes de certification examineront ce point pour s’assurer que toutes les informations fournies dans le contrôle sont incluses dans l’avis de confidentialité des données.
Exemple de preuve :
Les captures d’écran suivantes montrent des instantanés d’une politique de confidentialité.
Notez que 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.
Les images d’un avis de confidentialité montrent un exemple de politique de confidentialité en ligne avec l’article 13 du RGPD inclus.
Vous trouverez ci-dessous une politique de protection des données qui peut être utilisée conjointement avec l’avis de confidentialité indiqué précédemment.
L’image précédente d’Azure montre comment Azure a été configuré pour répondre aux exigences de conformité du RGPD pour les données stockées dans un environnement back-end. La stratégie (qui peut être personnalisée ou générée à partir d’Azure Blueprints) permet à l’éditeur de logiciels indépendant de s’assurer que les données du client sont stockées correctement et qu’elles sont accessibles uniquement par les métriques spécifiées. En outre, les alertes sont définies pour garantir la conformité et affichent les données non conformes ou l’accès utilisateur sur le tableau de bord du gestionnaire de conformité.
Notez que les exemples précédents 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 et la date pour l’examen des preuves. Si vous êtes un utilisateur Linux, vous pouvez le faire via l’invite de commandes.
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 de la réglementation, elle traite de certains des éléments clés de HIPAA pour obtenir une certaine assurance que l’organisation répond à l’exigence et que l’organisation protège les informations de santé qu’elle traite.
Contrôle n° 14
Fournissez des preuves démontrables que :
Une stratégie existe pour la gestion HIPAA et HIPAA au sein de votre organisation 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’organisation décrivant la stratégie 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/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 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’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 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 organisation d’effectuer une analyse complète des risques afin de découvrir les risques potentiels et les vulnérabilités à la confidentialité, à l’intégrité et à la disponibilité d’e-PHI. 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° 15
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 des informations médicales protégées (PHI) qui sont couvertes par la loi et interdit les utilisations et les divulgations inappropriées de phi. L’objectif de ce sous-point est qu’une organisation doit limiter l’accès et l’utilisation d’e-PHI aux seules personnes qui en ont besoin à des fins autorisées et qu’elle doit se conformer à la règle minimale nécessaire, qui l’oblige à utiliser ou à divulguer uniquement la quantité minimale d’e-PHI nécessaire pour atteindre l’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 preuves fournies doivent montrer les protections techniques en place, telles que les technologies et les mécanismes utilisés pour protéger e-PHI et la façon dont l’organisation contrôle l’accès et le déplacement de ces données.
Exemple de preuve :
Les captures d’écran suivantes montrent la protection contre la perte de données (DLP) Microsoft Purview, 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 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 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’une organisation doit former son personnel sur la façon de gérer e-PHI 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é avec 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 ne s’agit que d’un exemple et non d’un document/implémentation complet. L’isV doit disposer d’un processus établi applicable à 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 montre un résumé des objectifs du cours. Si la formation est intégrée, les supports de formation doivent être fournis pour révision. Notez 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 Sur la sécurité, la durée totale en minutes, ainsi que l’état d’achèvement. La capture d’écran suivante fournit une vue d’ensemble des utilisateurs auxquels la formation a été attribuée et l’état de l’entraînement 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, si le processus est maintenu via une plateforme en ligne fournissez 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 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 un instantané du 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.
References
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).
/ 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.restore.co.uk/Records/Services/Magnetic-Tape-Storage (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).
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).
https://www.iow.nhs.uk/Downloads/Policies/Business%20Continuity%20Policy.pdf (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).
Principe (c) : Réduction des données | ICO (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 (consulté : 05/03/24).
Gérer et répondre aux alertes de sécurité dans Microsoft Defender pour le cloud (consulté : 05/03/24).
https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (Accès : 09/10/23).
Chiffrement transparent des données pour SQL Database, SQL Managed Instance et Azure Synapse Analytics (accessible : 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 (accessible : 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).