Hantera personliga data i Azure Monitor-loggar 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.
Kommentar
Information om hur du visar eller tar bort personliga data finns i Allmänna begäranden från datasubjekt för GDPR, Azure-datasubjektbegäranden för GDPR eller Begäranden från Windows-datasubjekt för GDPR, beroende på ditt specifika område och behov. Mer information om GDPR finns i avsnittet GDPR i Microsoft Trust Center och GDPR-avsnittet i Service Trust-portalen.
Behörigheter som krävs
Åtgärd | Behörigheter som krävs |
---|---|
Rensa data från en Log Analytics-arbetsyta | Microsoft.OperationalInsights/workspaces/purge/action behörigheter till Log Analytics-arbetsytan enligt den inbyggda rollen Log Analytics-deltagare, till exempel |
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 än0.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.
Kommentar
Du kan inte använda Log Analytics-fråge-API:et för som har tabellplanerna Basic och Auxiliary. Använd i stället Log Analytics/search-API:et.
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