Gestione dei dati personali nei log di Monitoraggio di Azure e in Application Insights

  • Articolo

Log Analytics è un archivio dati in cui sono disponibili i dati personali. Application Insights archivia questi dati in una partizione di Log Analytics. Questo articolo illustra dove Log Analytics e Application Insights archivia i dati personali e come gestire questi dati.

In questo articolo i dati di log fanno riferimento ai dati inviati a un'area di lavoro Log Analytics, mentre i dati dell'applicazione fanno riferimento ai dati raccolti da Application Insights. Se si usa una risorsa di Application Insights basata sull'area di lavoro, si applicano le informazioni sui dati di log. Se si usa una risorsa classica di Application Insights, vengono applicati i dati dell'applicazione.

Nota

Per informazioni su come visualizzare o eliminare dati personali, vedere Richieste del soggetto dei dati per il GDPR in Azure. Per altre informazioni sul GDPR, vedere la sezione GDPR del Centro protezione Microsoft e la sezione GDPR di Service Trust Portal.

Strategia per la gestione dei dati personali

Anche se spetta all'utente e all'azienda definire una strategia per la gestione dei dati personali, ecco alcuni approcci, elencati dalla maggior parte al meno preferibile dal punto di vista tecnico:

  • Interrompere la raccolta di dati personali o offuscare, rendere anonimi o modificare i dati raccolti per escluderli dal essere considerati "personali". Questo è di gran lunga l'approccio preferito, che consente di risparmiare la necessità di creare una strategia di gestione dei dati costosa e interessata.
  • Normalizzare i dati per ridurre gli effetti negativi sulla piattaforma dati e sulle prestazioni. Ad esempio, invece di registrare un ID utente esplicito, creare una ricerca per correlare il nome utente e i relativi dettagli a un ID interno che può quindi essere registrato altrove. In questo modo, se un utente chiede di eliminare le informazioni personali, è possibile eliminare solo la riga nella tabella di ricerca corrispondente all'utente.
  • Se è necessario raccogliere dati personali, creare un processo usando il percorso DELL'API di eliminazione e l'API di query esistente per soddisfare eventuali obblighi di esportazione ed eliminazione di tutti i dati personali associati a un utente.

Dove cercare i dati personali in Log Analytics

Log Analytics prevede uno schema per i dati, ma consente di eseguire l'override di ogni campo con valori personalizzati. È anche possibile inserire schemi personalizzati. Di conseguenza, è impossibile dire esattamente dove si trovano i dati personali nell'area di lavoro specifica. Le posizioni seguenti, tuttavia, sono buoni punti di partenza nell'inventario.

Nota

Alcune delle query seguenti usano search * per eseguire query su tutte le tabelle in un'area di lavoro. È consigliabile evitare di usare search *, che crea una query estremamente inefficiente, quando possibile. Eseguire invece una query su una tabella specifica.

Dati di log

  • Indirizzi IP: Log Analytics raccoglie varie informazioni IP in più tabelle. Ad esempio, la query seguente mostra tutte le tabelle che hanno raccolto gli indirizzi IPv4 nelle ultime 24 ore:

    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

  • ID utente: sono disponibili nomi utente e ID utente in varie soluzioni e tabelle. È possibile cercare un nome utente o un ID utente specifico nell'intero set di dati usando il comando di ricerca:

    search "<username or user ID>"

    Ricordarsi di cercare non solo i nomi utente leggibili, ma anche i GUID che possono essere ricontracciati a un determinato utente.

  • ID dispositivo: come gli ID utente, gli ID dispositivo vengono talvolta considerati dati personali. Usare l'approccio riportato in precedenza per gli ID utente per identificare le tabelle che contengono dati personali.

  • Dati personalizzati: Log Analytics consente di raccogliere dati personalizzati tramite log personalizzati, campi personalizzati, API dell'agente di raccolta dati HTTP e come parte dei registri eventi di sistema. Controllare tutti i dati personalizzati per i dati personali.

  • Dati acquisiti dalla soluzione: poiché il meccanismo della soluzione è aperto, è consigliabile esaminare tutte le tabelle generate dalle soluzioni per garantire la conformità.

Dati dell'applicazione

  • Indirizzi IP: anche se Application Insights offusca tutti i campi degli indirizzi IP in per 0.0.0.0 impostazione predefinita, è piuttosto comune eseguire l'override di questo valore con l'indirizzo IP utente effettivo per mantenere le informazioni sulla sessione. Usare la query seguente per trovare qualsiasi tabella contenente valori nella colonna indirizzo IP diverso dalle 0.0.0.0 ultime 24 ore:

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

  • ID utente: per impostazione predefinita, Application Insights usa ID generati in modo casuale per il rilevamento di utenti e sessioni in campi come session_Id, user_Id, user_AuthenticatedId, user_AccountId e customDimensions. Tuttavia, è comune eseguire l'override di questi campi con un ID più rilevante per l'applicazione, ad esempio nomi utente o GUID di Microsoft Entra. Questi ID sono spesso considerati dati personali. È consigliabile offuscare o rendere anonimi questi ID.

  • Dati personalizzati: Application Insights consente di accodare un set di dimensioni personalizzate per qualsiasi tipo di dati. Usare la query seguente per identificare le dimensioni personalizzate raccolte nelle ultime 24 ore:

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

  • Dati in memoria e in transito: Application Insights tiene traccia di eccezioni, richieste, chiamate di dipendenza e tracce. Spesso si trovano dati personali a livello di codice e di chiamata HTTP. Esaminare le eccezioni, le richieste, le dipendenze e le tabelle delle tracce per identificare tali dati. Usare gli inizializzatori di telemetria laddove possibile per offuscare questi dati.

  • Snapshot Debugger acquisisce: la funzionalità Snapshot Debugger in Application Insights consente di raccogliere snapshot di debug quando Application Insights rileva un'eccezione nell'istanza di produzione dell'applicazione. Gli snapshot espongono l'analisi dello stack completo che porta alle eccezioni e ai valori per le variabili locali in ogni passaggio dello stack. Sfortunatamente, questa funzionalità non consente l'eliminazione selettiva dei punti di ancoraggio o l'accesso a livello di codice ai dati all'interno dello snapshot. Pertanto, se la frequenza di conservazione degli snapshot predefinita non soddisfa i requisiti di conformità, è consigliabile disattivare la funzionalità.

Esportazione ed eliminazione di dati personali

È consigliabile ristrutturare i criteri di raccolta dei dati per interrompere la raccolta di dati personali, offuscare o rendere anonimi i dati personali oppure modificare tali dati fino a quando non sono più considerati personali. Per gestire i dati personali, i dati verranno addebitati per definire e automatizzare una strategia, creare un'interfaccia attraverso cui i clienti interagiscono con i dati e gestire in modo continuativo i dati. È anche costoso dal punto di vista computazionale per Log Analytics e Application Insights e un volume elevato di chiamate api simultanee di query o ripulitura può influire negativamente su tutte le altre interazioni con la funzionalità di Log Analytics. Tuttavia, se è necessario raccogliere dati personali, seguire le linee guida riportate in questa sezione.

Importante

Anche se la maggior parte delle operazioni di eliminazione completa molto più rapidamente, il contratto di servizio formale per il completamento delle operazioni di ripulitura viene impostato su 30 giorni a causa del loro impatto elevato sulla piattaforma dati. Questo contratto di servizio soddisfa i requisiti del GDPR. Si tratta di un processo automatizzato, quindi non è possibile accelerare l'operazione.

Visualizzare ed esportare i dati

Usare l'API query di Log Analytics o l'APIdi query di Application Insights per visualizzare ed esportare le richieste di dati.

È necessario implementare la logica per convertire i dati in un formato appropriato per il recapito agli utenti. Funzioni di Azure è una valida soluzione per ospitare tale logica.

Elimina

Avviso

Le eliminazioni eseguite in in Log Analytics sono distruttive e irreversibili. Eseguile con estrema attenzione.

L'API ripulitura di Monitoraggio di Azure consente di eliminare i dati personali. Usare l'operazione di eliminazione con moderazione per evitare potenziali rischi, impatto sulle prestazioni e il potenziale di asimmetria di aggregazioni, misurazioni e altri aspetti dei dati di Log Analytics. Vedere la sezione Strategia per la gestione dei dati personali per approcci alternativi alla gestione dei dati personali.

Purge è un'operazione con privilegi elevati. Concedere il ruolo Data Purger in Azure Resource Manager con cautela a causa della potenziale perdita di dati.

Per gestire le risorse di sistema, le richieste di eliminazione vengono limitate a 50 richieste all'ora. Eseguire in batch le richieste di eliminazione inviando un singolo comando il cui predicato include tutte le identità utente che richiedono l'eliminazione. Usare l'operatore in per specificare più identità. Eseguire la query prima di eseguire la richiesta di eliminazione per verificare i risultati previsti.

Importante

L'uso dell'API Log Analytics o Application Insights Purge non influisce sui costi di conservazione. Per ridurre i costi di conservazione, è necessario ridurre il periodo di conservazione dei dati.

Dati di log

  • L'API POST di ripulitura dell'area di lavoro accetta un oggetto che specifica i parametri dei dati da eliminare e restituisce un GUID di riferimento.

  • L'API GET Purge Status POST restituisce un'intestazione "x-ms-status-location" che include un URL che è possibile chiamare per determinare lo stato dell'operazione di eliminazione. Ad esempio:

    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

Dati dell'applicazione

  • L'API Components - Purge POST accetta un oggetto che specifica i parametri dei dati da eliminare e restituisce un GUID di riferimento.

  • L'API Get Purge Status GET restituisce un'intestazione "x-ms-status-location" che include un URL che è possibile chiamare per determinare lo stato dell'operazione di eliminazione. Ad esempio:

    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

Passaggi successivi