Richt lijnen voor persoons gegevens die zijn opgeslagen in Log Analytics en Application InsightsGuidance for personal data stored in Log Analytics and Application Insights

Log Analytics is een gegevens archief waar persoons gegevens waarschijnlijk worden gevonden.Log Analytics is a data store where personal data is likely to be found. Application Insights worden de gegevens opgeslagen in een Log Analytics partitie.Application Insights stores its data in a Log Analytics partition. In dit artikel wordt beschreven waar in Log Analytics en Application Insights dergelijke gegevens doorgaans worden gevonden, evenals de mogelijkheden die beschikbaar zijn voor het afhandelen van dergelijke gegevens.This article will discuss where in Log Analytics and Application Insights such data is typically found, as well as the capabilities available to you to handle such data.

Notitie

Voor de doel einden van dit artikel verwijzen gegevens naar gegevens die naar een log Analytics werkruimte worden verzonden, terwijl toepassings gegevens verwijzen naar gegevens die worden verzameld door Application Insights.For the purposes of this article log data refers to data sent to a Log Analytics workspace, while application data refers to data collected by Application Insights.

Notitie

Voor meer informatie over persoonsgegevens bekijken of verwijderen, raadpleegt u AVG-verzoeken van betrokkenen voor Azure.For information about viewing or deleting personal data, see Azure Data Subject Requests for the GDPR. Raadpleeg AVG-gedeelte van de Service Trust Portal voor meer informatie over de AVG.For more information about GDPR, see the GDPR section of the Service Trust portal.

Strategie voor het afhandelen van persoonlijke gegevensStrategy for personal data handling

Hoewel het aan u is en uw bedrijf uiteindelijk de strategie wil bepalen waarmee u uw privé gegevens gaat verwerken (in alle), zijn de volgende mogelijke benaderingen van toepassing.While it will be up to you and your company to ultimately determine the strategy with which you will handle your private data (if at all), the following are some possible approaches. Deze worden weer gegeven in volg orde van voor keur van een technisch oogpunt van het grootste voor deel:They are listed in order of preference from a technical point of view from most to least preferable:

  • Indien mogelijk, stopt u het verzamelen van, het afschermen, anoniem maken of anderszins aanpassen van de gegevens die worden verzameld om deze uit te sluiten van als ' privé '.Where possible, stop collection of, obfuscate, anonymize, or otherwise adjust the data being collected to exclude it from being considered "private". Dit is de aanbevolen benadering en bespaart u de nood zaak om een zeer kost bare strategie voor gegevens verwerking te maken.This is by far the preferred approach, saving you the need to create a very costly and impactful data handling strategy.
  • Als dat niet mogelijk is, probeert u de gegevens te normaliseren om de impact op het gegevens platform en de prestaties te verminderen.Where not possible, attempt to normalize the data to reduce the impact on the data platform and performance. In plaats van een expliciete gebruikers-ID te registreren, maakt u bijvoorbeeld een opzoek gegevens waarmee de gebruikers naam en de details ervan worden gecorreleerd aan een interne ID die vervolgens ergens anders kan worden geregistreerd.For example, instead of logging an explicit User ID, create a lookup data that will correlate the username and their details to an internal ID that can then be logged elsewhere. Op die manier is het mogelijk dat als een van uw gebruikers u vraagt om zijn of haar persoonlijke gegevens te verwijderen, de rij in de opzoek tabel die overeenkomt met de gebruiker, voldoende wordt verwijderd.That way, should one of your users ask you to delete their personal information, it is possible that only deleting the row in the lookup table corresponding to the user will be sufficient.
  • Ten slotte, als er persoonlijke gegevens moeten worden verzameld, moet u een proces maken rond het pad van de API voor opschonen en het bestaande query-API-pad om te voldoen aan eventuele verplichtingen die u mogelijk hebt voor het exporteren en verwijderen van persoonlijke gegevens die aan een gebruiker zijn gekoppeld.Finally, if private data must be collected, build a process around the purge API path and the existing query API path to meet any obligations you may have around exporting and deleting any private data associated with a user.

Waar moet u zoeken naar privé gegevens in Log Analytics?Where to look for private data in Log Analytics?

Log Analytics is een flexibele Store, waarmee u een schema voor uw gegevens voorschrijft, kunt u elk veld overschrijven met aangepaste waarden.Log Analytics is a flexible store, which while prescribing a schema to your data, allows you to override every field with custom values. Daarnaast kan elk aangepast schema worden opgenomen.Additionally, any custom schema can be ingested. Het is dus niet mogelijk om precies te zeggen waar privé gegevens worden gevonden in uw specifieke werk ruimte.As such, it is impossible to say exactly where Private data will be found in your specific workspace. De volgende locaties zijn echter goede start punten in uw inventaris:The following locations, however, are good starting points in your inventory:

LogboekgegevensLog data

  • IP-adressen: log Analytics verzamelt diverse IP-gegevens over diverse tabellen.IP addresses: Log Analytics collects a variety of IP information across many different tables. Met de volgende query worden bijvoorbeeld alle tabellen weer gegeven waarin IPv4-adressen zijn verzameld in de afgelopen 24 uur:For example, the following query shows all tables where IPv4 addresses have been collected over the last 24 hours:
    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
    
  • Gebruikers-id's: gebruikers-id's zijn te vinden in een groot aantal verschillende oplossingen en tabellen.User IDs: User IDs are found in a large variety of solutions and tables. U kunt met behulp van de zoek opdracht zoeken naar een bepaalde gebruikers naam in uw hele gegevensset:You can look for a particular username across your entire dataset using the search command:
    search "[username goes here]"
    
    Zoek niet alleen naar gebruikers namen met een lees bare naam, maar ook GUID'S die rechtstreeks naar een bepaalde gebruiker kunnen worden getraceerd.Remember to look not only for human-readable user names but also GUIDs that can directly be traced back to a particular user!
  • Apparaat-id's: zoals gebruikers-id's, worden apparaat-id's soms als ' privé ' beschouwd.Device IDs: Like user IDs, device IDs are sometimes considered "private". Gebruik dezelfde methode als hierboven hierboven voor gebruikers-Id's om tabellen te identificeren waarin dit probleem kan optreden.Use the same approach as listed above for user IDs to identify tables where this might be a concern.
  • Aangepaste gegevens: met log Analytics kunt u de verzameling op diverse manieren toestaan: aangepaste logboeken en aangepaste velden, de http-gegevens verzamelaar-API en aangepaste gegevens die zijn verzameld als onderdeel van systeem gebeurtenis Logboeken.Custom data: Log Analytics allows the collection in a variety of methods: custom logs and custom fields, the HTTP Data Collector API , and custom data collected as part of system event logs. Al deze zijn gevoelig voor persoonlijke gegevens en moeten worden onderzocht om te controleren of dergelijke gegevens bestaan.All of these are susceptible to containing private data, and should be examined to verify whether any such data exists.
  • Door oplossingen vastgelegde gegevens: omdat het oplossings mechanisme een open-end is, raden we u aan alle tabellen te controleren die zijn gegenereerd door een oplossing om te voldoen aan de vereisten.Solution-captured data: Because the solution mechanism is an open-ended one, we recommend reviewing all tables generated by solutions to ensure compliance.

ToepassingsgegevensApplication data

  • IP-adressen: Hoewel Application Insights alle IP-adres velden standaard van elkaar maakt op ' 0.0.0.0 ', is dit een redelijk gebruikelijk patroon om deze waarde te overschrijven met de werkelijke gebruikers-IP om sessie gegevens te onderhouden.IP addresses: While Application Insights will by default obfuscate all IP address fields to "0.0.0.0", it is a fairly common pattern to override this value with the actual user IP to maintain session information. De onderstaande Analytics-query kan worden gebruikt om een tabel te vinden die waarden bevat in de kolom IP-adres in plaats van ' 0.0.0.0 ' in de afgelopen 24 uur:The Analytics query below can be used to find any table that contains values in the IP address column other than "0.0.0.0" over the last 24 hours:
    search client_IP != "0.0.0.0"
    | where timestamp > ago(1d)
    | summarize numNonObfuscatedIPs_24h = count() by $table
    
  • Gebruikers-id's: standaard worden door Application Insights wille keurig gegenereerde id's gebruikt voor het bijhouden van gebruikers en sessies.User IDs: By default, Application Insights will use randomly generated IDs for user and session tracking. Het is echter gebruikelijk dat deze velden worden overschreven voor het opslaan van een ID die relevant is voor de toepassing.However, it is common to see these fields overridden to store an ID more relevant to the application. Bijvoorbeeld: gebruikers namen, AAD-GUID'S, enzovoort. Deze Id's worden vaak beschouwd als persoonlijke gegevens en moeten daarom op de juiste wijze worden afgehandeld.For example: usernames, AAD GUIDs, etc. These IDs are often considered to be in-scope as personal data, and therefore, should be handled appropriately. Onze aanbeveling is altijd om deze Id's te veranoniem makenen.Our recommendation is always to attempt to obfuscate or anonymize these IDs. Velden waarin deze waarden vaak worden gevonden, zijn onder andere session_Id, user_Id, user_AuthenticatedId, user_AccountId, en customDimensions.Fields where these values are commonly found include session_Id, user_Id, user_AuthenticatedId, user_AccountId, as well as customDimensions.
  • Aangepaste gegevens: met Application Insights kunt u een set aangepaste dimensies toevoegen aan elk gegevens type.Custom data: Application Insights allows you to append a set of custom dimensions to any data type. Deze dimensies kunnen alle gegevens zijn.These dimensions can be any data. Gebruik de volgende query om alle aangepaste dimensies te identificeren die in de afgelopen 24 uur zijn verzameld:Use the following query to identify any custom dimensions collected over the last 24 hours:
    search * 
    | where isnotempty(customDimensions)
    | where timestamp > ago(1d)
    | project $table, timestamp, name, customDimensions 
    
  • In-Memory en in-transit gegevens: Application Insights worden uitzonde ringen, aanvragen, afhankelijkheids aanroepen en traceringen bijgehouden.In-memory and in-transit data: Application Insights will track exceptions, requests, dependency calls, and traces. Persoonlijke gegevens kunnen vaak worden verzameld op het niveau van code en HTTP-aanroepen.Private data can often be collected at the code and HTTP call level. Bekijk de tabellen met uitzonde ringen, aanvragen, afhankelijkheden en traceringen om dergelijke gegevens te identificeren.Review the exceptions, requests, dependencies, and traces tables to identify any such data. Gebruik de initialisatie functies voor telemetrie waar mogelijk deze gegevens kunnen worden verborgen.Use telemetry initializers where possible to obfuscate this data.
  • Snapshot debugger Capture: met de functie Snapshot debugger in Application Insights kunt u moment opnamen van fout opsporing verzamelen wanneer er een uitzonde ring wordt gedetecteerd op het productie-exemplaar van uw toepassing.Snapshot Debugger captures: The Snapshot Debugger feature in Application Insights allows you to collect debug snapshots whenever an exception is caught on the production instance of your application. Met moment opnamen wordt de volledige Stack tracering voor de uitzonde ringen en de waarden voor lokale variabelen bij elke stap in de stack beschikbaar gemaakt.Snapshots will expose the full stack trace leading to the exceptions as well as the values for local variables at every step in the stack. Helaas is deze functie niet toegestaan voor selectieve verwijdering van magnetische punten of programmatische toegang tot gegevens in de moment opname.Unfortunately, this feature does not allow for selective deletion of snap points, or programmatic access to data within the snapshot. Als de standaard retentie tijd van de moment opname niet voldoet aan uw nalevings vereisten, is de aanbeveling daarom de functie uit te scha kelen.Therefore, if the default snapshot retention rate does not satisfy your compliance requirements, the recommendation is to turn off the feature.

Privé gegevens exporteren en verwijderenHow to export and delete private data

Zoals vermeld in de sectie strategie voor het afhandelen van persoonlijke gegevens , wordt het ten zeerste aangeraden om het beleid voor gegevens verzameling te herstructureren om het verzamelen van persoonlijke gegevens uit te scha kelen, te maken of op te Anoniemen, of anderszins te wijzigen om het te verwijderen als ' privé '.As mentioned in the strategy for personal data handling section earlier, it is strongly recommended to if it all possible, to restructure your data collection policy to disable the collection of private data, obfuscating or anonymizing it, or otherwise modifying it to remove it from being considered "private". Het afhandelen van de gegevens leidt ertoe dat de kosten voor u en uw team een strategie definiëren en automatiseren, een interface bouwen voor uw klanten om te communiceren met hun gegevens via en continue onderhouds kosten.Handling the data will foremost result in costs to you and your team to define and automate a strategy, build an interface for your customers to interact with their data through, and ongoing maintenance costs. Verder is het kostenbesparend voor Log Analytics en Application Insights en is een groot volume van gelijktijdige query's of API-aanroepen voor het opschonen van api's de mogelijkheid om alle andere interactie met Log Analytics functionaliteit negatief te beïnvloeden.Further, it is computationally costly for Log Analytics and Application Insights, and a large volume of concurrent query or purge API calls have the potential to negatively impact all other interaction with Log Analytics functionality. Dit heeft te maken met inderdaad enkele geldige scenario's waarin privé gegevens moeten worden verzameld.That said, there are indeed some valid scenarios where private data must be collected. In dergelijke gevallen moeten gegevens worden verwerkt, zoals beschreven in deze sectie.For these cases, data should be handled as described in this section.

Notitie

Dit artikel bevat stappen voor als u persoonlijke gegevens van het apparaat of de service wilt verwijderen. Bovendien kunt u het gebruiken om uw verplichtingen met betrekking tot de AVG na te komen.This article provides steps for how to delete personal data from the device or service and can be used to support your obligations under the GDPR. Zie het gedeelte AVG van de Service Trust Portal als u op zoek bent naar algemene informatie over de AVG.If you’re looking for general info about GDPR, see the GDPR section of the Service Trust portal.

Weer geven en exporterenView and export

Voor beide gegevens aanvragen weer geven en exporteren moet de log Analytics query-API of de Application INSIGHTS query-API worden gebruikt.For both view and export data requests, the Log Analytics query API or the Application Insights query API should be used. Logica voor het converteren van de vorm van de gegevens naar een geschikte shape om aan uw gebruikers te leveren, is aan u toe te passen.Logic to convert the shape of the data to an appropriate one to deliver to your users will be up to you to implement. Azure functions is een goede plaats om deze logica te hosten.Azure Functions makes a great place to host such logic.

Belangrijk

Hoewel het meren deel van de opschoon bewerkingen veel sneller kan worden uitgevoerd dan de SLA, wordt de formele sla voor het volt ooien van de opschoon bewerking 30 dagen ingesteld als gevolg van de zware impact van het gebruikte gegevens platform.While the vast majority of purge operations may complete much quicker than the SLA, the formal SLA for the completion of purge operations is set at 30 days due to their heavy impact on the data platform used. Dit is een geautomatiseerd proces. u kunt niet aanvragen dat een bewerking sneller wordt verwerkt.This is an automated process; there is no way to request that an operation be handled faster.

VerwijderenDelete

Waarschuwing

Verwijderingen in Log Analytics zijn destructief en niet-omkeerbaar.Deletes in Log Analytics are destructive and non-reversible! Wees uiterst voorzichtig bij de uitvoering ervan.Please use extreme caution in their execution.

We zijn beschikbaar gesteld als onderdeel van een privacy-verwerkings -API- pad.We have made available as part of a privacy handling a purge API path. Dit pad moet spaarzaam worden gebruikt vanwege het risico dat eraan is gekoppeld, de potentiële invloed op de prestaties en de kans om alle aggregaties, metingen en andere aspecten van uw Log Analytics gegevens te scheef trekken.This path should be used sparingly due to the risk associated with doing so, the potential performance impact, and the potential to skew all-up aggregations, measurements, and other aspects of your Log Analytics data. Zie de sectie strategie voor het verwerken van persoonlijke gegevens voor alternatieve benaderingen voor het afhandelen van persoonlijke gegevens.See the Strategy for personal data handling section for alternative approaches to handle private data.

Opschonen is een zeer beschermde bewerking die geen enkele app of gebruiker in azure (inclusief zelfs de resource-eigenaar) toestemming heeft om uit te voeren zonder expliciet een rol in Azure Resource Manager te krijgen.Purge is a highly privileged operation that no app or user in Azure (including even the resource owner) will have permissions to execute without explicitly being granted a role in Azure Resource Manager. Deze rol is gegevens verzamelaar en moet voorzichtig worden gedelegeerd vanwege het mogelijke verlies van gegevens.This role is Data Purger and should be cautiously delegated due to the potential for data loss.

Belangrijk

Voor het beheren van systeem bronnen worden opschoon aanvragen beperkt tot 50 aanvragen per uur.In order to manage system resources, purge requests are throttled at 50 requests per hour. U moet een batch uitvoeren voor het opschonen van aanvragen door één opdracht te verzenden waarvan het predicaat alle gebruikers-id's bevat die moeten worden opgeschoond.You should batch the execution of purge requests by sending a single command whose predicate includes all user identities that require purging. Gebruik de operator in om meerdere identiteiten op te geven.Use the in operator to specify multiple identities. U moet de query uitvoeren voordat u de opschoon aanvraag uitvoert om te controleren of de resultaten worden verwacht.You should run the query before executing the purge request to verify that the results are expected.

Zodra de Azure Resource Manager rol is toegewezen, zijn er twee nieuwe API-paden beschikbaar:Once the Azure Resource Manager role has been assigned, two new API paths are available:

LogboekgegevensLog data

  • Bericht opschonen : Hiermee wordt een object opgegeven met de para meters voor het verwijderen van de gegevens en wordt een verwijzings-GUID geretourneerdPOST purge - takes an object specifying parameters of data to delete and returns a reference GUID

  • Status van leegmaken ophalen: de aanroep ' x-MS-status-location ' wordt door het aanroepen van de POST geretourneerd en bevat een URL die u kunt aanroepen om de status van uw opschoon API te bepalen.GET purge status - the POST purge call will return an 'x-ms-status-location' header that will include a URL that you can call to determine the status of your purge API. Bijvoorbeeld:For example:

    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
    

Belangrijk

Hoewel we verwachten dat het overgrote deel van de opschoon bewerking veel sneller is dan onze SLA, vanwege hun zware impact op het gegevens platform dat wordt gebruikt door Log Analytics, wordt de formele sla voor het volt ooien van de opschoon bewerking ingesteld op 30 dagen.While we expect the vast majority of purge operations to complete much quicker than our SLA, due to their heavy impact on the data platform used by Log Analytics, the formal SLA for the completion of purge operations is set at 30 days.

ToepassingsgegevensApplication data

  • Bericht opschonen : Hiermee wordt een object opgegeven met de para meters voor het verwijderen van de gegevens en wordt een verwijzings-GUID geretourneerdPOST purge - takes an object specifying parameters of data to delete and returns a reference GUID

  • Status van leegmaken ophalen: de aanroep ' x-MS-status-location ' wordt door het aanroepen van de POST geretourneerd en bevat een URL die u kunt aanroepen om de status van uw opschoon API te bepalen.GET purge status - the POST purge call will return an 'x-ms-status-location' header that will include a URL that you can call to determine the status of your purge API. Bijvoorbeeld:For example:

    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
    

Belangrijk

Hoewel het meren deel van de opschoon bewerkingen veel sneller kan worden uitgevoerd dan de SLA Application Insights, wordt de formele sla voor het volt ooien van de opschoon bewerking op 30 dagen ingesteld.While the vast majority of purge operations may complete much quicker than the SLA, due to their heavy impact on the data platform used by Application Insights, the formal SLA for the completion of purge operations is set at 30 days.

Volgende stappenNext steps