Hantera personliga data i Log Analytics och Application Insights

  • Artikel
  • 6 minuter för att läsa

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.

Anteckning

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 GDPR-avsnittet i Microsoft Trust Center och GDPR-avsnittet i Service Trust Portal.

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örvränga, anonymisera eller justera insamlade data så att de inte betraktas som "personliga". Det här är den absolut bästa metoden, vilket gör att du slipper 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, om en användare ber dig att ta bort deras personliga information, kan du bara ta bort raden i uppslagstabellen som motsvarar användaren.
  • 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 alla 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 finns på din specifika arbetsyta. Följande platser är dock bra utgångspunkter i inventeringen.

Anteckning

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 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 inte bara leta 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: Precis som användar-ID:n betraktas enhets-ID:n ibland som personliga data. Använd metoden ovan för användar-ID:t 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:et och som en del av systemets händelseloggar. Kontrollera alla anpassade data för personliga data.

  • 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 döljer 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 ip-adresskolumnen förutom 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:t 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 Azure Active Directory-GUID:er. Dessa ID:t anses ofta vara personuppgifter. Vi rekommenderar att du döljar eller anonymiserar dessa ID:er.

  • Anpassade data: Med Application Insights kan du lägga till en uppsättning anpassade dimensioner till alla datatyper. 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 data och data under överföring: Application Insights spårar undantag, begäranden, beroendeanrop och spårningar. Du hittar ofta personliga data 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.

  • Snapshot Debugger captures: Med funktionen Snapshot Debugger i Application Insights kan du samla in ögonblicksbilder av felsökning 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 inte den här funktionen selektiv borttagning av snappunkter eller programmatisk åtkomst till data i ögonblicksbilden. Om standardkvarhållningsfrekvensen för ö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 betraktas som personliga. Vid hantering av 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

Även om de flesta rensningsåtgärder slutförs mycket snabbare, anges det formella serviceavtalet för slutförande av rensningsåtgärder till 30 dagar på grund av deras stora inverkan på dataplattformen. Detta serviceavtal 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 vara värd för sådan logik.

Ta bort

Varning

Borttagningar i Log Analytics är destruktiva och går inte att ångra! Var mycket försiktig när de körs.

Med rensnings-API:et i Azure Monitor kan du ta bort personliga data. Använd rensningsåtgärden sparsamt för att undvika potentiella risker, prestandapåverkan och potentialen att förvränga aggregeringar, mått 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. Program och Azure-användare, inklusive resursägaren, kan inte köra en rensningsåtgärd utan att uttryckligen beviljas rollen Datarensning i Azure Resource Manager. Bevilja den här rollen 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 operatorn in för att ange flera identiteter. Kör frågan innan du kör rensningsbegäran för att verifiera det förväntade resultatet.

Anteckning

När du har initierat en rensningsbegäran kan du inte komma åt relaterade data medan rensningsåtgärdens statusär väntande.

Loggdata

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

  • API:et Get Purge Status POST returnerar huvudet "x-ms-status-location" som innehåller en URL som du kan anropa för att fastställa status för rensningsåtgärden. 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

  • Components – Purge POST API 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 rensningsåtgärden. 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