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

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, il termine dati di log fa riferimento ai dati inviati a un'area di lavoro Log Analytics, mentre dati dell'applicazione fa 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 sulla visualizzazione o l'eliminazione di dati personali, vedere Richieste generali dell'interessato per il GDPR, richieste dell'interessato di Azure per il GDPR o richieste dell'interessato windows per il GDPR, a seconda dell'area e delle esigenze specifiche. Per altre informazioni sul Regolamento generale sulla protezione dei dati (GDPR), vedere la sezione del GDPR del Centro protezione di Microsoft e la sezione del GDPR del Service Trust Portal.

Autorizzazioni obbligatorie

Azione Autorizzazioni obbligatorie
Rimuovere dati da un'area di lavoro Log Analytics Le autorizzazioni Microsoft.OperationalInsights/workspaces/purge/action per l'area di lavoro Log Analytics fornite dal ruolo integrato di Collaboratore Log Analytics, ad esempio

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 oppure offuscare, rendere anonimi o modificare i dati raccolti per escluderli dall'essere considerati "personali". Questo è di gran lunga l'approccio preferito, che evita la necessità di creare una strategia di gestione dei dati costosa e dall'impatto elevato.
  • 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 proprie 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. I percorsi seguenti, tuttavia, sono un punto di partenza ideale per un 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 tracciati nuovamente 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 log eventi di sistema. Controllare tutti i dati personalizzati per i dati personali.

  • Dati acquisiti dalle soluzioni: dato che il meccanismo delle soluzioni è aperto, è consigliabile esaminare tutte le tabelle generate dalle soluzioni per garantire la conformità.

Dati dell'applicazione

  • Indirizzi IP: mentre Application Insights offusca tutti i campi degli indirizzi IP per 0.0.0.0 per 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 da 0.0.0.0 nelle 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 di tracce per identificare tali dati. Usare gli inizializzatori di telemetria laddove possibile per offuscare questi dati.

  • Acquisizioni Snapshot Debugger: 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

È fortemente consigliato 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 ripulitura viene completata 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 di query Log Analytics o l'API di query di Application Insights per visualizzare ed esportare le richieste di dati.

Nota

Non è possibile usare l'API di query di Log Analytics in con i piani di tabella Basic e Ausiliari. Usare invece l'API Log Analytics /search.

È 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 Purge 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.

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

Per gestire le risorse di sistema, le richieste di eliminazione vengono limitate a 50 richieste all'ora. Effettuare l'esecuzione in batch delle richieste di ripulitura inviando un unico comando il cui predicato includa tutte le identità utente che richiedono ripulitura. 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 Workspace Purge POST 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
    

Nota

Non è possibile eliminare i dati dalle tabelle con piani di tabella Basic e Ausiliari.

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 Components - 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