> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Registro di audit: tracciamento attività API e compliance > Didit registra tutte le attività API in registri di audit ricercabili. Filtra per utente, metodo, stato e date per audit di compliance e debugging. 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](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-audit-logs.jpg?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=bcd436f764486143268f5c5ca67d9d14) *** ## Perché i registri di audit? | Esigenza | Soluzione | | - | - | | Requisiti di compliance normativa | Traccia di audit completa di tutte le attività, per il periodo previsto dal tuo piano | | Indagine su incidenti di sicurezza | Ricostruisci con precisione chi ha fatto cosa e quando | | Debug di problemi di integrazione | Visualizza il percorso, lo stato e il corpo oscurato di ogni richiesta | | Responsabilità del team | Monitora quali membri del team hanno acceduto a quali dati | | Monitoraggio dell'utilizzo | Comprendi i modelli di consumo dell'API | *** ## 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: | Campo | Descrizione | | - | - | | **Marca temporale** | Quando è stata effettuata la richiesta | | **Utente** | Chi l'ha effettuata: l'email del membro del team autenticato; il nome della chiave API che ha effettuato la richiesta, contrassegnato come **Chiave API**; oppure **L’investigatore**, per una decisione che ha preso autonomamente | | **Metodo** | Metodo HTTP (GET, POST, PUT, DELETE) | | **Percorso** | L'endpoint API che è stato chiamato | | **Stato** | Codice di stato della risposta HTTP | | **Indirizzo IP** | IP di origine della richiesta | | **Applicazione** | L'applicazione a cui era associata la richiesta | ### Decisioni prese da L’investigatore Ogni decisione che [L’investigatore](https://docs.didit.me/it/console/investigator.md) 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: | Tipo di ricerca | Esempio | Comportamento | | - | - | - | | **Percorso esatto** | `/v1/organization/.../sessions/` | Trova i log con questo percorso di richiesta esatto | | **Email esatta** | `admin@company.com` | Trova i log di questo utente specifico | | **IP esatto** | `192.168.1.100` | Trova i log di questo indirizzo IP | | **Carattere jolly** | `/v1/*/analytics/*` | Trova corrispondenze con schemi che usano caratteri jolly | | **Testo generico** | `sessions` | Ricerca approssimata in tutti i campi | ### Filtri disponibili | Filtro | Descrizione | Esempio | | - | - | - | | **Applicazione** | Filtra per applicazione specifica | Seleziona dal menu a tendina | | **Membri e chiavi API** | Filtra per la chiave API che ha effettuato le richieste | Seleziona una chiave dell'applicazione scelta | | **Attore** | Mostra solo ciò che hanno fatto membri, chiavi API o L’investigatore | **L’investigatore** | | **Metodo** | Filtra per metodo HTTP | `GET`, `POST`, `PUT`, `DELETE` | | **Codice di stato** | Filtra per codice di stato della risposta | `200`, `401`, `500` | | **Intervallo di date** | Filtra per periodo di tempo | Ultimi 7 giorni, intervallo personalizzato | *** ## Conservazione dei dati Il tuo piano stabilisce fino a quando puoi consultare il registro di audit e se puoi esportarlo: | Piano | Periodo di conservazione | Esportazione | | - | - | - | | Free | 30 giorni | No | | Growth | 1 anno | No | | Scale | 3 anni | Sì | | Enterprise | Definita dal tuo contratto | Sì | 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](https://docs.didit.me/it/console/roles-permissions.md) le ottiene selezionando Audit logs nell'editor dei ruoli. *** ## Casi d'uso comuni > [accordion] Audit di conformità > > 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 > [accordion] Indagine sulla sicurezza > > 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 > [accordion] Debug dell'integrazione > > 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 > [accordion] Revisione dell'attività del team > > 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.