Vai al contenuto principale
Gli Audit Logs offrono un registro completo e consultabile di tutta l’attività API all’interno della tua organizzazione. Ogni richiesta inviata alla piattaforma Didit, che provenga dalla Console, dalla tua integrazione o dai membri del team, viene registrata automaticamente per motivi di sicurezza, compliance e risoluzione dei problemi.
Registri di audit nella console Didit

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], mentre null resta null.
  • 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.
I parametri della query seguono lo stesso oscuramento. Vengono conservate solo le intestazioni standard come 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 per audit-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

Dimostra agli auditor di avere una visibilità completa su chi ha avuto accesso ai dati di verifica:
  1. Filtra per intervallo di date corrispondente al periodo di audit
  2. Filtra per applicazioni o utenti specifici, se necessario
  3. Esporta o fai uno screenshot dei risultati per la documentazione
Se sospetti un accesso non autorizzato:
  1. Cerca l’email dell’utente interessato o gli indirizzi IP sospetti
  2. Filtra per intervallo di date intorno al presunto incidente
  3. Cerca schemi anomali: tentativi di autenticazione falliti, endpoint inattesi, orari insoliti
Quando risolvi problemi di integrazione API:
  1. Cerca il percorso dell’endpoint specifico
  2. Filtra per codici di stato 4xx o 5xx per trovare gli errori
  3. Annota i timestamp per correlarli con i log della tua applicazione
Monitora come il tuo team utilizza la piattaforma:
  1. Filtra per le email dei singoli membri del team
  2. Verifica a quali sessioni hanno avuto accesso e quali funzionalità hanno utilizzato
  3. Assicurati che i membri del team seguano le procedure corrette

Buone pratiche

  1. Revisioni periodiche: verifica periodicamente i registri di audit per individuare tempestivamente le anomalie.
  2. Restringi la ricerca: usa filtri specifici per ridurre il rumore e trovare più rapidamente le voci pertinenti.
  3. Intervalli di date: specifica sempre un intervallo di date per migliorare le prestazioni su set di dati di grandi dimensioni.
  4. Salva le ricerche nei preferiti: salva le combinazioni di filtri più usate come segnalibri del browser per accedervi rapidamente.
Ultima modifica il 7 novembre 2026