Persoonlijke gegevens beheren in Azure Monitor-logboeken en Application Insights

  • Artikel

Log Analytics is een gegevensarchief waarin persoonlijke gegevens waarschijnlijk worden gevonden. Application Insights slaat de gegevens op in een Log Analytics-partitie. In dit artikel wordt uitgelegd waar Log Analytics en Application Insights persoonlijke gegevens opslaan en hoe u deze gegevens beheert.

In dit artikel verwijzen logboekgegevens naar gegevens die naar een Log Analytics-werkruimte worden verzonden, terwijl toepassingsgegevens verwijzen naar gegevens die zijn verzameld door Application Insights. Als u een Application Insights-resource op basis van een werkruimte gebruikt, is de informatie over logboekgegevens van toepassing. Als u een klassieke Application Insights-resource gebruikt, zijn de toepassingsgegevens van toepassing.

Notitie

Voor meer informatie over persoonsgegevens bekijken of verwijderen, raadpleegt u AVG-verzoeken van betrokkenen voor Azure. Zie de AVG-sectie van het Microsoft Trust Center en de AVG-sectie van de Service Trust Portal voor algemene informatie over de AVG.

Strategie voor het verwerken van persoonlijke gegevens

Hoewel het aan u en uw bedrijf is om een strategie voor het verwerken van persoonsgegevens te definiëren, zijn er een paar benaderingen, die van de meeste tot het minst geschikt zijn vanuit technisch oogpunt:

  • Stop met het verzamelen van persoonlijke gegevens, of verdoof, anoniem maken of aanpassen van verzamelde gegevens om deze uit te sluiten van "persoonlijk". Dit is veruit de voorkeursbenadering, die u bespaart op het maken van een dure en impactvolle strategie voor het verwerken van gegevens.
  • Normaliseer de gegevens om negatieve gevolgen voor het gegevensplatform en de prestaties te verminderen. In plaats van een expliciete gebruikers-id te registreren, maakt u bijvoorbeeld een zoekopdracht om de gebruikersnaam en de bijbehorende gegevens te correleren met een interne id die vervolgens ergens anders kan worden geregistreerd. Als een gebruiker u vraagt om zijn persoonlijke gegevens te verwijderen, kunt u alleen de rij in de opzoektabel verwijderen die overeenkomt met de gebruiker.
  • Als u persoonlijke gegevens wilt verzamelen, maakt u een proces met behulp van het opschonings-API-pad en de bestaande query-API om te voldoen aan alle verplichtingen voor het exporteren en verwijderen van persoonsgegevens die zijn gekoppeld aan een gebruiker.

Waar te zoeken naar persoonlijke gegevens in Log Analytics

Log Analytics schrijft een schema voor uw gegevens voor, maar stelt u in staat om elk veld met aangepaste waarden te overschrijven. U kunt ook aangepaste schema's opnemen. Als zodanig is het onmogelijk om precies te zeggen waar persoonsgegevens worden gevonden in uw specifieke werkruimte. De volgende locaties zijn echter goede uitgangspunten in uw inventaris.

Notitie

Sommige van de onderstaande query's worden gebruikt search * om query's uit te voeren op alle tabellen in een werkruimte. We raden u ten zeerste aan het gebruik search *te vermijden, waardoor een zeer inefficiënte query wordt gemaakt, indien mogelijk. Voer in plaats daarvan een query uit op een specifieke tabel.

Logboekgegevens

  • IP-adressen: Log Analytics verzamelt verschillende IP-gegevens in meerdere tabellen. De volgende query toont bijvoorbeeld alle tabellen die in de afgelopen 24 uur IPv4-adressen hebben verzameld:

    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: U vindt gebruikersgebruikersnamen en gebruikers-id's in verschillende oplossingen en tabellen. U kunt zoeken naar een bepaalde gebruikersnaam of gebruikers-id in uw hele gegevensset met behulp van de zoekopdracht:

    search "<username or user ID>"

    Vergeet niet alleen te zoeken naar door mensen leesbare gebruikersnamen, maar ook voor GUID's die kunnen worden teruggezet naar een bepaalde gebruiker.

  • Apparaat-id's: net als gebruikers-id's worden apparaat-id's soms beschouwd als persoonlijke gegevens. Gebruik de hierboven vermelde benadering voor gebruikers-id's om tabellen te identificeren die persoonlijke gegevens bevatten.

  • Aangepaste gegevens: Met Log Analytics kunt u aangepaste gegevens verzamelen via aangepaste logboeken, aangepaste velden, de HTTP-gegevensverzamelaar-API en als onderdeel van systeemlogboeken. Controleer alle aangepaste gegevens op persoonsgegevens.

  • Door de oplossing vastgelegde gegevens: omdat het oplossingsmechanisme open is, raden we u aan alle tabellen te bekijken die door oplossingen worden gegenereerd om ervoor te zorgen dat de naleving wordt gegarandeerd.

Toepassingsgegevens

  • IP-adressen: Hoewel Application Insights standaard alle IP-adresvelden 0.0.0.0 verdoezelt, is het redelijk gebruikelijk om deze waarde te overschrijven met het werkelijke IP-adres van de gebruiker om sessiegegevens te onderhouden. Gebruik de onderstaande query om een tabel te zoeken die waarden bevat in de kolom IP-adres , behalve 0.0.0.0 in de afgelopen 24 uur:

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

  • Gebruikers-id's: Application Insights maakt standaard gebruik van willekeurig gegenereerde id's voor het bijhouden van gebruikers en sessies in velden zoals session_Id, user_Id, user_AuthenticatedId, user_AccountId en customDimensions. Het is echter gebruikelijk om deze velden te overschrijven met een id die relevanter is voor de toepassing, zoals gebruikersnamen of Microsoft Entra-GUID's. Deze id's worden vaak beschouwd als persoonsgegevens. We raden u aan deze id's te verdoezelen of anoniem te maken.

  • Aangepaste gegevens: Met Application Insights kunt u een set aangepaste dimensies toevoegen aan elk gegevenstype. Gebruik de volgende query om aangepaste dimensies te identificeren die in de afgelopen 24 uur zijn verzameld:

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

  • In-memory en in-transit gegevens: Application Insights houdt uitzonderingen, aanvragen, afhankelijkheidsaanroepen en traceringen bij. U vindt vaak persoonlijke gegevens op code- en HTTP-aanroepniveau. Bekijk uitzonderingen, aanvragen, afhankelijkheden en traceringen van tabellen om dergelijke gegevens te identificeren. Gebruik waar mogelijk telemetrie-initialisatiefuncties om deze gegevens te verdoezelen.

  • Snapshot Debugger legt vast: met de functie Snapshot Debugger in Application Insights kunt u foutopsporingsmomentopnamen verzamelen wanneer Application Insights een uitzondering detecteert op het productie-exemplaar van uw toepassing. Momentopnamen maken de volledige stacktracering beschikbaar die leidt tot de uitzonderingen en de waarden voor lokale variabelen bij elke stap in de stack. Helaas staat deze functie selectief verwijderen van snappunten of programmatische toegang tot gegevens in de momentopname niet toe. Als de standaardretentiepercentage voor momentopnamen niet voldoet aan uw nalevingsvereisten, raden we u aan de functie uit te schakelen.

Persoonlijke gegevens exporteren en verwijderen

We raden u ten zeerste aan om uw beleid voor gegevensverzameling te herstructureren om te stoppen met het verzamelen van persoonlijke gegevens, persoonlijke gegevens te verdoezelen of anoniem te maken, of om dergelijke gegevens op een andere manier te wijzigen totdat deze niet langer als persoonlijk worden beschouwd. Bij het verwerken van persoonlijke gegevens worden kosten in rekening gebracht bij het definiëren en automatiseren van een strategie, het bouwen van een interface waarmee uw klanten communiceren met hun gegevens en doorlopend onderhoud. Het is ook rekenkundig kostbaar voor Log Analytics en Application Insights, en een groot aantal gelijktijdige query- of opschonings-API-aanroepen kan negatieve gevolgen hebben voor alle andere interacties met Log Analytics-functionaliteit. Als u echter persoonsgegevens moet verzamelen, volgt u de richtlijnen in deze sectie.

Belangrijk

Hoewel de meeste opschoningsbewerkingen veel sneller zijn voltooid, wordt de formele SLA voor het voltooien van opschoningsbewerkingen ingesteld op 30 dagen vanwege hun zware impact op het gegevensplatform. Deze SLA voldoet aan de AVG-vereisten. Het is een geautomatiseerd proces, dus er is geen manier om de bewerking te versnellen.

Weergeven en exporteren

Gebruik de Log Analytics-query-API of de Application Insights-query-API voor het weergeven en exporteren van gegevensaanvragen.

U moet de logica implementeren voor het converteren van de gegevens naar een geschikte indeling voor levering aan uw gebruikers. Azure Functions is een uitstekende plek om dergelijke logica te hosten.

Delete

Waarschuwing

Verwijderingen in Log Analytics zijn schadelijk en onomkeerbaar! Wees uiterst voorzichtig bij de uitvoering ervan.

Met de Opschonings-API van Azure Monitor kunt u persoonlijke gegevens verwijderen. Gebruik de opschoningsbewerking spaarzaam om potentiële risico's, prestatie-impact en het potentieel om aggregaties, metingen en andere aspecten van uw Log Analytics-gegevens scheef te maken. Zie de sectie Strategie voor het verwerken van persoonlijke gegevens voor alternatieve methoden voor het verwerken van persoonsgegevens.

Leegmaken is een bewerking met hoge bevoegdheden. Verleen de rol Data Purger in Azure Resource Manager voorzichtig vanwege het potentieel voor gegevensverlies.

Om systeembronnen te beheren, beperken we opschoningsaanvragen tot 50 aanvragen per uur. Batchgewijs uitvoeren van opschoningsaanvragen door één opdracht te verzenden waarvan het predicaat alle gebruikersidentiteiten bevat waarvoor opschoning is vereist. Gebruik de operator in om meerdere identiteiten op te geven. Voer de query uit voordat u de opschoonaanvraag uitvoert om de verwachte resultaten te controleren.

Belangrijk

Het gebruik van de Log Analytics- of Application Insights Purge-API heeft geen invloed op uw retentiekosten. Als u de retentiekosten wilt verlagen, moet u de bewaarperiode voor gegevens verlagen.

Logboekgegevens

  • De POST-API voor het opschonen van werkruimten gebruikt een object waarin parameters van gegevens worden opgegeven die moeten worden verwijderd en een referentie-GUID wordt geretourneerd.

  • De GET Purge Status POST API retourneert een 'x-ms-status-location' header die een URL bevat die u kunt aanroepen om de status van uw opschoningsbewerking te bepalen. Voorbeeld:

    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

Toepassingsgegevens

  • De Onderdelen - POST-API leegmaken maakt gebruik van een object waarin parameters van gegevens worden opgegeven die moeten worden verwijderd en een referentie-GUID wordt geretourneerd.

  • De onderdelen - Get Purge Status GET API retourneert een 'x-ms-status-location' header die een URL bevat die u kunt aanroepen om de status van uw opschoningsbewerking te bepalen. Voorbeeld:

    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

Volgende stappen