Hantera personliga data i Azure Monitor-loggar och Application Insights

  • Artikel

Log Analytics är ett datalager där personuppgifter sannolikt kommer att hittas. Application Insights lagrar sina data i en Log Analytics-partition. Den här artikeln förklarar var Log Analytics och Application Insights lagrar personliga data och hur du hanterar dessa data.

I den här artikeln refererar loggdata till data som skickas till en Log Analytics-arbetsyta, medan programdata refererar till data som samlas in av Application Insights. Om du använder en arbetsytebaserad Application Insights-resurs gäller informationen om loggdata. Om du använder en klassisk Application Insights-resurs gäller programdata.

Kommentar

I Azure-begäranden från registrerad person för GDPR finns det information om att visa eller ta bort personuppgifter. Mer information om GDPR finns i avsnittet GDPR i Microsoft Trust Center och GDPR-avsnittet i Service Trust-portalen.

Strategi för hantering av personuppgifter

Det är upp till dig och ditt företag att definiera en strategi för hantering av personuppgifter, men här är några metoder som listas från de flesta till minst att föredra ur teknisk synvinkel:

  • Sluta samla in personuppgifter, eller fördunkla, anonymisera eller justera insamlade data så att de inte betraktas som "personliga". Detta är den överlägset bästa metoden, vilket sparar dig behovet av att skapa en kostsam och effektfull datahanteringsstrategi.
  • Normalisera data för att minska negativa effekter på dataplattformen och prestanda. I stället för att till exempel logga ett explicit användar-ID skapar du ett uppslag för att korrelera användarnamnet och deras information med ett internt ID som sedan kan loggas någon annanstans. På så sätt kan du bara ta bort raden i uppslagstabellen som motsvarar användaren om en användare ber dig att ta bort deras personliga information.
  • Om du behöver samla in personuppgifter skapar du en process med hjälp av sökvägen för rensnings-API:et och det befintliga fråge-API:et för att uppfylla eventuella skyldigheter att exportera och ta bort personliga data som är associerade med en användare.

Var du kan söka efter personuppgifter i Log Analytics

Log Analytics föreskriver ett schema för dina data, men gör att du kan åsidosätta varje fält med anpassade värden. Du kan också mata in anpassade scheman. Därför är det omöjligt att säga exakt var personliga data kommer att hittas på din specifika arbetsyta. Följande platser är dock bra utgångspunkter i ditt lager.

Kommentar

Några av frågorna nedan används search * för att köra frågor mot alla tabeller på en arbetsyta. Vi rekommenderar starkt att du undviker att använda search *, vilket skapar en mycket ineffektiv fråga när det är möjligt. Fråga i stället en specifik tabell.

Loggdata

  • IP-adresser: Log Analytics samlar in olika IP-information i flera tabeller. Följande fråga visar till exempel alla tabeller som har samlat in IPv4-adresser under de senaste 24 timmarna:

    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

  • Användar-ID: Du hittar användarnamn och användar-ID:t i olika lösningar och tabeller. Du kan söka efter ett visst användarnamn eller användar-ID i hela datauppsättningen med hjälp av sökkommandot:

    search "<username or user ID>"

    Kom ihåg att leta inte bara efter användarnamn som kan läsas av människor utan även för GUID:er som kan spåras tillbaka till en viss användare.

  • Enhets-ID:n: Precis som användar-ID:n betraktas enhets-ID:n ibland som personliga data. Använd metoden ovan för användar-ID för att identifiera tabeller som innehåller personliga data.

  • Anpassade data: Med Log Analytics kan du samla in anpassade data via anpassade loggar, anpassade fält, HTTP Data Collector API och som en del av systemhändelseloggarna. Kontrollera alla anpassade data för personuppgifter.

  • Lösningssamlade data: Eftersom lösningsmekanismen är öppen rekommenderar vi att du granskar alla tabeller som genereras av lösningar för att säkerställa efterlevnad.

Programdata

  • IP-adresser: Application Insights fördunklar alla IP-adressfält till 0.0.0.0 som standard, men det är ganska vanligt att åsidosätta det här värdet med den faktiska användar-IP-adressen för att underhålla sessionsinformation. Använd frågan nedan för att hitta en tabell som innehåller värden i kolumnen IP-adress än 0.0.0.0 under de senaste 24 timmarna:

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

  • Användar-ID: Som standard använder Application Insights slumpmässigt genererade ID:er för användar- och sessionsspårning i fält som session_Id, user_Id, user_AuthenticatedId, user_AccountId och customDimensions. Det är dock vanligt att åsidosätta dessa fält med ett ID som är mer relevant för programmet, till exempel användarnamn eller Microsoft Entra GUID. Dessa ID:er anses ofta vara personuppgifter. Vi rekommenderar att du fördunklar eller anonymiserar dessa ID:er.

  • Anpassade data: Med Application Insights kan du lägga till en uppsättning anpassade dimensioner till valfri datatyp. Använd följande fråga för att identifiera anpassade dimensioner som samlats in under de senaste 24 timmarna:

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

  • Minnesintern och data under överföring: Application Insights spårar undantag, begäranden, beroendeanrop och spårningar. Du hittar ofta personuppgifter på kod- och HTTP-anropsnivå. Granska undantag, begäranden, beroenden och spårningstabeller för att identifiera sådana data. Använd telemetriinitierare där det är möjligt för att dölja dessa data.

  • Ögonblicksbildsfelsökare avbildas: Med funktionen Snapshot Debugger i Application Insights kan du samla in felsökningsögonblicksbilder när Application Insights identifierar ett undantag på programmets produktionsinstans. Ögonblicksbilder exponerar den fullständiga stackspårningen som leder till undantagen och värdena för lokala variabler i varje steg i stacken. Tyvärr tillåter den här funktionen inte selektiv borttagning av snappunkter eller programmatisk åtkomst till data i ögonblicksbilden. Om standardnivån för kvarhållning av ögonblicksbilder inte uppfyller dina efterlevnadskrav rekommenderar vi därför att du inaktiverar funktionen.

Exportera och ta bort personliga data

Vi rekommenderar starkt att du omstrukturerar din datainsamlingsprincip för att sluta samla in personuppgifter, dölja eller anonymisera personliga data eller på annat sätt ändra sådana data tills de inte längre anses vara personliga. När du hanterar personliga data medför du kostnader för att definiera och automatisera en strategi, skapa ett gränssnitt genom vilket dina kunder interagerar med sina data och kontinuerligt underhåll. Det är också beräkningsmässigt kostsamt för Log Analytics och Application Insights, och en stor mängd samtidiga fråge- eller rensnings-API-anrop kan påverka alla andra interaktioner med Log Analytics-funktioner negativt. Men om du måste samla in personuppgifter följer du riktlinjerna i det här avsnittet.

Viktigt!

De flesta rensningsåtgärder slutförs mycket snabbare, men det formella serviceavtalet för slutförande av rensningsåtgärder anges till 30 dagar på grund av deras stora inverkan på dataplattformen. Det här serviceavtalet uppfyller GDPR-kraven. Det är en automatiserad process, så det finns inget sätt att påskynda åtgärden.

Visa och exportera

Använd Log Analytics-fråge-API:et eller Application Insights-fråge-API:et för att visa och exportera databegäranden.

Du måste implementera logiken för att konvertera data till ett lämpligt format för leverans till dina användare. Azure Functions är ett bra ställe att hantera sådan logik på.

Delete

Varning

Borttagningar i Log Analytics är destruktiva och går inte att häva! Var mycket försiktig när du utför borttagningar.

Med Azure Monitors rensnings-API kan du ta bort personliga data. Använd rensningsåtgärden sparsamt för att undvika potentiella risker, prestandapåverkan och möjligheten att förvränga aggregeringar, mätningar och andra aspekter av dina Log Analytics-data. Se avsnittet Strategi för hantering av personuppgifter för alternativa metoder för hantering av personuppgifter.

Rensning är en mycket privilegierad åtgärd. Bevilja datarensningsrollen i Azure Resource Manager försiktigt på grund av risken för dataförlust.

För att hantera systemresurser begränsar vi rensningsbegäranden till 50 begäranden i timmen. Batch-körningen av rensningsbegäranden genom att skicka ett enda kommando vars predikat innehåller alla användaridentiteter som kräver rensning. Använd in-operatorn för att ange flera identiteter. Kör frågan innan du kör rensningsbegäran för att verifiera förväntade resultat.

Viktigt!

Användningen av Log Analytics- eller Application Insights Purge-API:et påverkar inte dina kvarhållningskostnader. Om du vill sänka kvarhållningskostnaderna måste du minska datakvarhållningsperioden.

Loggdata

  • POST-API:et för rensning av arbetsyta tar ett objekt som anger dataparametrar som ska tas bort och returnerar ett referens-GUID.

  • POST-API:et hämta rensningsstatus returnerar ett "x-ms-status-location"-huvud som innehåller en URL som du kan anropa för att fastställa statusen för din rensningsåtgärd. Till exempel:

    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

Programdata

  • API :et Components – Purge POST tar ett objekt som anger dataparametrar för att ta bort och returnerar ett referens-GUID.

  • Get-API:et Components – Get Purge Status returnerar huvudet "x-ms-status-location" som innehåller en URL som du kan anropa för att fastställa status för din rensningsåtgärd. Till exempel:

    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

Nästa steg