Gestion des données à caractère personnel dans les journaux Azure Monitor et Application Insights

  • Article

Log Analytics est une banque de données pouvant contenir des données personnelles. Application Insights stocke ses données dans une partition Log Analytics. Cet article explique où Log Analytics et Application Insights stockent les données à caractère personnel, et comment gérer celles-ci.

Dans cet article, les termes données de journal font référence aux données envoyées à un espace de travail Log Analytics, tandis que les termes données d’application font référence aux données collectées par Application Insights. Si vous utilisez une ressource Application Insights basée sur un espace de travail, les informations sur les données de journal s’appliquent. Si vous utilisez une ressource Application Insights classique, les données d’application s’appliquent.

Notes

Pour plus d’informations sur l’affichage ou la suppression des données personnelles, consultez Requêtes DSR (droits de la personne concernée) Azure pour le RGPD. Pour plus d’informations sur le Règlement général sur la protection des données (RGPD), consultez la section relative au RGPD du Centre de gestion de la confidentialité de Microsoft et la section relative au RGPD du Portail d’approbation de services.

Stratégie de gestion des données personnelles

Même s’il vous incombe, ainsi qu’à votre entreprise, de définir une stratégie de gestion des données à caractère personnel, voici quelques approches, répertoriées dans l’ordre croissant de préférence d’un point de vue technique :

  • Arrêter la collecte de données à caractère personnel, ou obfusquer, anonymiser ou ajuster les données collectées de façon à ce qu’elles ne soient plus considérées comme « à caractère personnel ». Il s’agit de loin de la l’approche préférée, qui vous évite de devoir créer une stratégie de gestion de données coûteuse et impactante.
  • Normaliser les données pour réduire les effets négatifs sur la plateforme de données et les performances. Par exemple, au lieu de journaliser un ID utilisateur explicite, créez une recherche qui établit une corrélation entre, d’une part, le nom d’utilisateur et ses informations détaillées, et d’autre part, un ID interne, qui peuvent ensuite être consignés ailleurs. Ainsi, si un utilisateur vous demande de supprimer ses informations à caractère personnel, vous pouvez supprimer uniquement la ligne de la table de recherche correspondant à cet utilisateur.
  • Si vous devez collecter des données à caractère personnel, créez un processus utilisant le chemin de l’API de vidage et l’API de requête existante pour répondre aux obligations d’exportation et de suppression des données à caractère personnel associées à un utilisateur.

Où rechercher des données à caractère personnel dans Log Analytics ?

Log Analytics prescrit un schéma pour vos données, mais vous permet de remplacer chaque champ par des valeurs personnalisées. Vous pouvez également ingérer des schémas personnalisés. Il est ainsi impossible de dire exactement où les données à caractère personnel se trouvent dans votre espace de travail spécifique. Cependant, les emplacements suivants constituent de bons points de départ pour votre inventaire.

Notes

Certaines des requêtes ci-dessous utilisent la commande search * pour interroger toutes les tables présentes dans un espace de travail. Autant que possible, nous vous recommandons vivement d’éviter d’utiliser la commande search * qui crée une requête très inefficace. Au lieu de cela, interrogez une table spécifique.

Données de journal

  • Adresses IP : Log Analytics collecte différentes informations d’adresses IP dans plusieurs tables. Par exemple, la requête suivante affiche toutes les tables ayant collecté des adresses IPv4 au cours des dernières 24 heures :

    search * 
| where * matches regex @'\b((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.|$)){4}\b' //RegEx originally provided on https://stackoverflow.com/questions/5284147/validating-ipv4-addresses-with-regexp
| summarize count() by $table

  • ID d’utilisateur : vous trouverez des noms et ID d’utilisateur dans différentes solutions et tables. Vous pouvez rechercher un nom ou ID d’utilisateur particulier dans tout votre jeu de données avec la commande de recherche :

    search "<username or user ID>"

    N’oubliez pas de rechercher non seulement des noms d’utilisateur explicites, mais aussi des GUID permettant de remonter directement à un utilisateur particulier.

  • ID d’appareil : comme les ID d’utilisateur, les ID d’appareil sont parfois considérés comme des données à caractère personnel. Utilisez l’approche décrite ci-dessus pour les ID d’utilisateur, afin d’identifier les tables contenant des données à caractère personnel.

  • Données personnalisées : Log Analytics vous permet de collecter des données personnalisées via des journaux personnalisés, des champs personnalisés, l’API Collecte de données HTTP et dans le cadre des journaux d’événements système. Vérifiez toutes les données personnalisées pour voir si elles contiennent des données à caractère personnel.

  • Données capturées par les solutions : comme le mécanisme des solutions est ouvert, nous vous recommandons d’examiner toutes les tables générées par les solutions pour vérifier leur conformité.

Données d'application

  • Adresses IP : si, par défaut, Application Insights obfusque tous les champs d’adresse IP en affichant 0.0.0.0, il est assez courant de remplacer cette valeur par l’adresse IP réelle de l’utilisateur afin de gérer les informations de la session. Utilisez la requête Analytics ci-dessous pour rechercher toute table dont la colonne Adresses IP contient des valeurs autres que 0.0.0.0 au cours des 24 heures :

    search client_IP != "0.0.0.0"
| where timestamp > ago(1d)
| summarize numNonObfuscatedIPs_24h = count() by $table

  • ID d’utilisateur : par défaut, Application Insights utilise des ID générés de manière aléatoire pour le suivi des utilisateurs et des sessions dans des champs tels que session_Id, user_Id, user_AuthenticatedId, user_AccountId et customDimensions. Cependant, il est courant de remplacer ces champs par un ID qui est plus pertinent pour l’application, comme un nom d’utilisateur ou un GUID Microsoft Entra. Ces ID sont souvent considérés comme des données à caractère personnel. Nous vous recommandons d’obfusquer ou d’anonymiser ces ID.

  • Données personnalisées : Application Insights vous permet d’ajouter un ensemble de dimensions personnalisées à n’importe quel type de données. Utilisez la requête suivante pour identifier des dimensions personnalisées collectées au cours des dernières 24 heures :

    search * 
| where isnotempty(customDimensions)
| where timestamp > ago(1d)
| project $table, timestamp, name, customDimensions

  • Données en mémoire et en transit : Application Insights suit les exceptions, requêtes, appels de dépendance et traces. Vous trouverez souvent des données à caractère personnel au niveau d’un code et d’un appel HTTP. Examinez les tables d’exceptions, de requêtes, de dépendances et de traces pour identifier ces données. Utilisez si possible des initialiseurs de télémétrie afin de brouiller ces données.

  • Captures du débogueur de capture instantanée : la fonctionnalité Débogueur de capture instantanée d’Application Insights vous permet de collecter des instantanés de débogage quand Application Insights détecte une exception sur l’instance de production de votre application. Les instantanés exposent la trace de la pile pleine conduisant aux exceptions, ainsi que les valeurs des variables locales à chaque étape de la pile. Malheureusement, cette fonctionnalité ne permet pas une suppression sélective de points d’ancrage, ou l’accès par programme aux données figurant dans l’instantané. Par conséquent, si le taux de rétention des instantanés par défaut ne répond pas à vos exigences de conformité, nous vous recommandons de désactiver cette fonctionnalité.

Exportation et suppression de données à caractère personnel

Nous vous recommandons vivement de restructurer votre stratégie de collecte de données pour arrêter la collecte de données à caractère personnel, obfusquer ou anonymiser celles-ci, ou les modifier jusqu’à ce qu’elles ne soient plus considérées comme présentant un caractère personnel. La gestion de données à caractère personnel occasionne des coûts pour définir et automatiser une stratégie, créer une interface via laquelle vos clients interagissent avec leurs données, et assurer la maintenance continue. Elle est également coûteuse en termes de ressources informatiques pour Log Analytics et Application Insights, et un grand nombre d’appels d’API de requête ou de vidage simultanés peut avoir un impact négatif sur toutes les autres interactions avec la fonctionnalité de Log Analytics. Toutefois, si vous devez collecter des données à caractère personnel, suivez les instructions de cette section.

Important

Si la plupart des opérations de vidage s’accomplissent beaucoup plus rapidement, le contrat SLA formel pour l’accomplissement des opérations de vidage stipule 30 jours en raison de l’impact considérable de ces opérations sur la plateforme de données. Ce contrat SLA répond aux exigences du RGPD. Il s’agit d’un processus automatisé. Il n’existe donc aucun moyen d’accélérer l’opération.

Afficher et exporter

Pour afficher et exporter des requêtes de données, utilisez l’API de requête Log Analytics ou l’API de requête Application Insights.

Vous devez implémenter la logique de conversion des données dans un format approprié pour la livraison à vos utilisateurs. Azure Functions est l’endroit idéal pour héberger cette logique.

Supprimer

Avertissement

Les suppressions dans Log Analytics sont destructrices et non réversibles ! Soyez très prudents quand vous les réalisez.

L’API de suppression définitive d’Azure Monitor vous permet de supprimer des données à caractère personnel. Utilisez l’opération de vidage avec parcimonie afin d’éviter des risques potentiels, un impact sur les performances et la possibilité de fausser toutes les agrégations, mesures et autres aspects de vos données Log Analytics. Pour d’autres approches de la gestion des données à caractère personnel, consultez la section Stratégie de gestion des données à caractère personnel.

Le vidage est une opération hautement privilégiée. Accordez le rôle Purgeur de données avec prudence dans Azure Resource Manager en raison d’un risque de perte de données.

Pour gérer des ressources système, nous limitons les demandes de vidage à 50 par heure. Regroupez l’exécution des demandes de vidage en envoyant une seule commande dont le prédicat comprend toutes les identités des utilisateurs demandant un vidage. Utilisez l’opérateur in pour spécifier plusieurs identités. Exécutez la requête avant d’exécuter la demande de vidage pour vérifier que les résultats sont tels qu’attendus.

Important

L’utilisation de l’API de suppression définitive de Log Analytics ou Application Insights n’affecte pas vos coûts de conservation. Pour réduire les coûts de rétention, vous devez réduire votre période de conservation des données.

Données de journal

  • L’API POST de vidage d’espace de travail prend un objet spécifiant les paramètres des données à supprimer et retourne un GUID de référence.

  • L’API POST pour l’obtention de l’état de vidage retourne un en-tête « x-ms-status-location » qui inclut une URL que vous pouvez appeler pour déterminer l’état de votre opération de vidage. Par exemple :

    x-ms-status-location: https://management.azure.com/subscriptions/[SubscriptionId]/resourceGroups/[ResourceGroupName]/providers/Microsoft.OperationalInsights/workspaces/[WorkspaceName]/operations/purge-[PurgeOperationId]?api-version=2015-03-20

Données d'application

  • L’API POST de vidage de composants prend un objet spécifiant les paramètres des données à supprimer et retourne un GUID de référence.

  • L’API GET pour l’obtention de l’état de vidage de composants retourne un en-tête « x-ms-status-location » qui inclut une URL que vous pouvez appeler pour déterminer l’état de votre opération de vidage. Par exemple :

    x-ms-status-location: https://management.azure.com/subscriptions/[SubscriptionId]/resourceGroups/[ResourceGroupName]/providers/microsoft.insights/components/[ComponentName]/operations/purge-[PurgeOperationId]?api-version=2015-05-01

Étapes suivantes