Hantera personliga data i Log Analytics och Application Insights

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 avsnittet GDPR i avsnittet Microsoft Trust Center och GDPR 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 dölja, anonymisera eller justera insamlade data för att utesluta att de betraktas som "personliga". Detta är den överlägset bästa metoden, vilket sparar dig behovet av att skapa en kostsam och effektfull strategi för datahantering.
  • 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 en sökning 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 användaren uppmanas att ta bort sin 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 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: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ändarläsbara användarnamn utan även för GUID:erna 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 som anges 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 systemhändelseloggarna. 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 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: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 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 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.

  • Ögonblicksbildsfelsökare avbildas: Med funktionen Snapshot Debugger i Application Insights kan du samla in ögonblicksbilder av felsökningar när Application Insights identifierar ett undantag för programmets produktionsinstans. Ögonblicksbilder visar 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 standardfrekvensen 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 betraktas som 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 löpande 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. 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 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 all-up-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. Ge 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. Batchkörning av rensningsbegäranden genom att skicka ett enda kommando vars predikat innehåller alla användaridentiteter som kräver rensning. Använd operatorn i för att ange flera identiteter. Kör frågan innan du kör rensningsbegäran för att verifiera förväntade resultat.

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.

  • POST-API:et Hämta rensningsstatus 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. 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 din rensningsåtgärd. 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