
Perché i registri di audit?
Accedere ai registri di audit
Apri Settings > Organization > Audit log nella Console Didit. L’interfaccia mostra un elenco cronologico di tutte le richieste API effettuate all’interno della tua organizzazione. Ogni voce del registro include:Decisioni prese da L’investigatore
Ogni decisione che L’investigatore prende autonomamente viene registrata sotto L’investigatore, non sotto un membro o una chiave API: approvare o rifiutare una sessione o richiedere un nuovo invio, impostare lo stato di una transazione e risolvere un caso, escalarlo o richiedere informazioni al riguardo. La voce rimanda al report dell’investigatore alla base della decisione. Quando una persona accetta o sovrascrive una raccomandazione dell’investigatore, la voce viene registrata a nome di quella persona.Filtri e ricerca
L’interfaccia dei registri di audit offre potenti funzioni di filtro per aiutarti a trovare esattamente ciò che cerchi.Ricerca intelligente
La barra di ricerca rileva automaticamente ciò che stai cercando:Filtri disponibili
Conservazione dei dati
Il tuo piano stabilisce fino a quando puoi consultare il registro di audit e se puoi esportarlo:
Un’esportazione su un piano che non la prevede restituisce
403 con "code": "plan_limit_exceeded".
Sicurezza e privacy
Cosa viene registrato
I registri di audit acquisiscono i metadati delle richieste API:- Marca temporale e durata della richiesta
- Identità dell’utente (email, ID utente) oppure la chiave API che ha effettuato la richiesta (il suo nome e i primi caratteri del suo segreto, mai il segreto completo)
- Percorso della richiesta e parametri della query
- Codici di stato della risposta
- Indirizzo IP del client e user agent
Corpo della richiesta e della risposta per le chiamate con chiave API
Per una chiamata effettuata con una chiave API, il registro di audit conserva anche una copia oscurata del corpo JSON della richiesta di scrittura e della risposta a una scrittura o a un errore, così da poter capire perché una chiamata non è riuscita. La risposta a una lettura riuscita non viene conservata. L’oscuramento segue un principio di negazione predefinita:- La struttura resta: nomi dei campi, annidamento, tipi di valore, lunghezze degli array e lunghezze delle stringhe.
- Un valore resta solo quando è un identificativo, uno stato, un codice, un conteggio o un timestamp di Didit, in un campo definito da Didit, con il formato che quel campo si aspetta.
- Un booleano resta solo in un campo definito da Didit.
- Ogni altro valore viene sostituito da un marcatore che indica il suo tipo e la sua lunghezza, come
[redacted:string:12],[redacted:number:5]o[redacted:boolean], mentrenullrestanull. - Un nome di campo che non è un semplice identificativo, come un indirizzo email o un numero di telefono usato come chiave, viene sostituito da
[redacted:key:23]. - Un corpo che non è JSON, come un modulo o un file caricato, viene sostituito da una nota che indica di cosa si trattava.
- Il risultato è troncato a 4.096 caratteri.
content-type, user-agent e le intestazioni del limite di frequenza; ogni altra intestazione viene eliminata insieme al suo valore.
Un valore inviato dal tuo sistema, ad esempio in metadata o vendor_data, non viene mai conservato, anche quando il suo campo ha lo stesso nome di uno dei campi di Didit.
Cosa NON viene registrato
Per proteggere i dati sensibili, vengono automaticamente esclusi:- Token di autenticazione e credenziali
- Password e segreti
- Dati personali delle sessioni di verifica
Controllo degli accessi
Per consultare il registro di audit servono le autorizzazioni di lettura e di elenco peraudit-logs. I ruoli Reader, Compliance Officer, Developer, Admin e Owner le hanno tutte, mentre un ruolo personalizzato le ottiene selezionando Audit logs nell’editor dei ruoli.
Casi d’uso comuni
Audit di conformità
Audit di conformità
Dimostra agli auditor di avere una visibilità completa su chi ha avuto accesso ai dati di verifica:
- Filtra per intervallo di date corrispondente al periodo di audit
- Filtra per applicazioni o utenti specifici, se necessario
- Esporta o fai uno screenshot dei risultati per la documentazione
Indagine sulla sicurezza
Indagine sulla sicurezza
Se sospetti un accesso non autorizzato:
- Cerca l’email dell’utente interessato o gli indirizzi IP sospetti
- Filtra per intervallo di date intorno al presunto incidente
- Cerca schemi anomali: tentativi di autenticazione falliti, endpoint inattesi, orari insoliti
Debug dell'integrazione
Debug dell'integrazione
Quando risolvi problemi di integrazione API:
- Cerca il percorso dell’endpoint specifico
- Filtra per codici di stato
4xxo5xxper trovare gli errori - Annota i timestamp per correlarli con i log della tua applicazione
Revisione dell'attività del team
Revisione dell'attività del team
Monitora come il tuo team utilizza la piattaforma:
- Filtra per le email dei singoli membri del team
- Verifica a quali sessioni hanno avuto accesso e quali funzionalità hanno utilizzato
- Assicurati che i membri del team seguano le procedure corrette
Buone pratiche
- Revisioni periodiche: verifica periodicamente i registri di audit per individuare tempestivamente le anomalie.
- Restringi la ricerca: usa filtri specifici per ridurre il rumore e trovare più rapidamente le voci pertinenti.
- Intervalli di date: specifica sempre un intervallo di date per migliorare le prestazioni su set di dati di grandi dimensioni.
- Salva le ricerche nei preferiti: salva le combinazioni di filtri più usate come segnalibri del browser per accedervi rapidamente.