Questa applicazione self-hosted lascia una traccia di audit? Una checklist per chi acquista

L'audit logging è un requisito per la scelta dell'applicazione

Un'applicazione self-hosted può essere semplice da distribuire e, al tempo stesso, inadatta a dati che richiedono un utilizzo tracciabile e attribuibile. Se l'applicazione conterrà dati aziendali di clienti, dipendenti, natura finanziaria, operativa o comunque sensibili, poni subito una domanda: il team potrà in seguito stabilire chi ha fatto cosa, su quale oggetto, quando e tramite quale interfaccia?

La questione va oltre la risposta agli incidenti. Una traccia di audit utilizzabile può supportare l'indagine su una modifica inattesa, i flussi di approvazione e gestione delle eccezioni, le revisioni periodiche degli accessi, la responsabilità per le modifiche di configurazione e la raccolta di prove dopo una controversia. Le linee guida NIST sulla consapevolezza degli eventi identificano l'interazione dell'utente e il tempo, le azioni di configurazione e l'accesso e l'utilizzo dei dati archiviati come capacità rilevanti ai fini dell'audit.

Non considerare «ha dei log» una risposta sufficiente. L'auditabilità è una proprietà del prodotto e della distribuzione. L'applicazione deve generare gli eventi necessari, la distribuzione deve conservarli, i revisori autorizzati devono poterli recuperare e interpretare e i controlli devono proteggerli da alterazioni o eliminazioni non autorizzate.

• Rendi l'auditabilità un requisito con punteggio prima di selezionare un'applicazione, anziché rimandarla a dopo il lancio in produzione.
• Formula i requisiti in base alle decisioni che le registrazioni devono supportare, ad esempio: «identificare chi ha assegnato un ruolo» o «esaminare le esportazioni dei record dei clienti».
• Assegna un responsabile per le impostazioni di audit dell'applicazione, le procedure di revisione dei log, le decisioni di conservazione e l'accesso alle prove esportate.

Log operativi, log di audit e cronologia del database rispondono a domande diverse

I log operativi servono principalmente a eseguire il software. I driver di logging di Docker raccolgono informazioni dai container e dai servizi in esecuzione; il driver json-file predefinito di Docker memorizza localmente i log dei container, salvo l'uso di un'altra configurazione. Queste registrazioni possono aiutare a diagnosticare un arresto anomalo, un avviso o un errore di runtime, ma non stabiliscono intrinsecamente che un utente aziendale nominativo abbia modificato un determinato record cliente.

I log del reverse proxy descrivono un livello diverso. Traefik distingue i propri log, che coprono aspetti quali avvio, configurazione, eventi e arresto, dagli access log relativi alle richieste gestite dal proxy. Gli access log possono stabilire che una richiesta abbia raggiunto un endpoint, ma potrebbero non identificare in modo affidabile l'attore aziendale autenticato, l'oggetto aziendale interessato o l'esito dell'azione. Inoltre, i loro campi possono essere intenzionalmente conservati, omessi o sottoposti a redazione.

Anche la cronologia del database è diversa. Il write-ahead logging di PostgreSQL registra le modifiche ai file di dati prima che i file sottostanti vengano modificati, affinché il ripristino possa rieseguire le modifiche dopo un arresto anomalo. La decodifica logica può rendere leggibili dal WAL le modifiche persistenti alle tabelle. Nessuno dei due meccanismi fornisce automaticamente una narrazione aziendale pronta per un'indagine: il contesto applicativo, l'identità dell'utente, il contesto di autorizzazione e il significato di una modifica possono mancare o essere difficili da ricostruire.

Usa ciascuna fonte per il suo scopo appropriato. I log operativi e del proxy restano preziosi per il troubleshooting e le indagini sull'infrastruttura. I meccanismi del database possono essere utili per il ripristino o l'analisi tecnica. Tuttavia, non sostituire nessuno di essi alle registrazioni di audit a livello applicativo senza verificare che soddisfino il requisito effettivo di prova.

• Log operativo: «Che cosa ha segnalato il processo o il container?»
• Access log del proxy: «Quale richiesta ha gestito il perimetro?»
• Cronologia del database: «Quale modifica a livello di archiviazione è avvenuta?»
• Registrazione di audit applicativa: «Quale attore ha eseguito quale azione aziendale o amministrativa significativa, su che cosa, quando e con quale risultato?»

Inizia dalle decisioni che la traccia deve supportare

Un lungo elenco di eventi non è un requisito. Inizia elencando le domande a cui un revisore deve poter rispondere in condizioni realistiche. Questo evita che i team attribuiscano eccessivo valore a logging tecnico ad alto volume trascurando le poche azioni che generano il maggior rischio aziendale.

Ad esempio, una revisione trimestrale degli accessi richiede informazioni affidabili su appartenenze e modifiche dei ruoli. Un'indagine su dati finanziari alterati può richiedere l'entità interessata, i valori prima e dopo ove appropriato, l'identità dell'attore, l'ora e l'esito dell'azione. Un flusso di approvazione può richiedere la prova che una persona designata abbia approvato, respinto o aggirato un passaggio. I campi esatti e il periodo di conservazione dovrebbero derivare da queste domande.

Rendi esplicito l'ambito. Un sistema può sottoporre ad audit l'attività degli amministratori, ma non le modifiche degli utenti ordinari, oppure registrare le autenticazioni riuscite ma non quelle fallite. Nessuna delle due situazioni è intrinsecamente inaccettabile; la questione è se la copertura documentata e testata corrisponda ai casi d'uso dichiarati.

• Indagini: puoi identificare attore, oggetto, azione, orario, esito e contesto rilevante?
• Approvazioni: puoi dimostrare chi ha approvato, respinto, delegato o modificato una regola di approvazione?
• Revisioni degli accessi: puoi identificare appartenenze, ruoli, modifiche delle autorizzazioni e l'attore responsabile?
• Responsabilità delle modifiche: puoi tracciare cambiamenti alla configurazione amministrativa, alle integrazioni e alle impostazioni rilevanti per la sicurezza?
• Revisione dell'uso dei dati: puoi identificare l'accesso a dati sensibili archiviati e azioni ad alto rischio, quali le esportazioni, quando la policy lo richiede?

Eventi da verificare prima dell'adozione

Usa la documentazione ufficiale dell'applicazione per identificare le famiglie di eventi, quindi mappale sui tuoi casi d'uso. Non presumere che un evento descritto nella documentazione sia abilitato, archiviato o disponibile in ogni modalità di distribuzione. Ad esempio, la documentazione di Keycloak indica che gli eventi utente non vengono memorizzati né visualizzati per impostazione predefinita, finché un amministratore non abilita il salvataggio degli eventi.

L'attività di autenticazione e autorizzazione è un punto di partenza: accessi riusciti, accessi non riusciti, recupero dell'account ove rilevante, eventi relativi alle sessioni ove documentati, modifiche a ruoli o gruppi e modifiche ai privilegi. Per l'attività amministrativa, includi le modifiche effettuate nell'interfaccia di gestione e, dove rilevante, nelle API di gestione. Keycloak documenta l'audit delle azioni degli amministratori nella sua Admin Console e delle invocazioni REST utilizzate per tali azioni.

La copertura dei dati aziendali merita un esame separato. Cerca la creazione, l'aggiornamento, l'eliminazione, l'accesso o l'utilizzo dei dati sensibili archiviati quando richiesto, le operazioni in blocco, le esportazioni, le importazioni, le modifiche alla condivisione e le modifiche alle credenziali o ai connettori di integrazione. Un'applicazione può offrire un eccellente audit amministrativo pur fornendo una visibilità limitata sulle singole azioni relative ai record aziendali.

Un evento utile deve contenere contesto sufficiente per essere interpretato in seguito. Lo schema pubblicato da GitLab per gli eventi di audit illustra una solida base di confronto: identità dell'autore, timestamp dell'evento, identificazione e tipo dell'entità, tipo di evento, ID univoco dell'evento e dettagli aggiuntivi. L'applicazione scelta non deve necessariamente usare lo stesso schema, ma le sue registrazioni dovrebbero rispondere a domande equivalenti per i tuoi requisiti.

• Attività di autenticazione riuscita e non riuscita
• Modifiche a utenti, gruppi, ruoli e autorizzazioni
• Creazione, aggiornamento ed eliminazione di record sensibili o regolamentati, ove richiesto
• Accesso o utilizzo dei record quando policy o rischio lo richiedono
• Esportazioni, download, importazioni, modifiche in blocco e azioni di condivisione
• Modifiche alla configurazione amministrativa
• Modifiche a integrazioni, token API, webhook o connettori
• Azioni amministrative effettuate sia tramite interfacce utente sia tramite API, quando applicabile

Verifica la documentazione, la configurazione e il percorso delle prove

Una pagina sulle funzionalità del fornitore non basta. Leggi la documentazione ufficiale per gli amministratori relativa allo specifico modello di distribuzione che stai considerando, quindi verifica in una prova le impostazioni predefinite di configurazione e le registrazioni risultanti. Considera ogni elemento sconosciuto una lacuna finché la documentazione del fornitore o il tuo test non lo chiariscano.

Per prima cosa, stabilisci la copertura degli eventi. Quali azioni generano eventi? Sia le azioni riuscite sia quelle non riuscite vengono registrate dove necessario? Le azioni degli utenti ordinari, le azioni amministrative e le azioni API sono coperte separatamente? Le categorie di eventi possono essere abilitate o disabilitate?

Successivamente, esamina la qualità delle registrazioni. Determina se la registrazione identifica un attore in modo coerente, riporta un timestamp inequivocabile e il fuso orario o standard temporale, identifica l'entità interessata, acquisisce il tipo di azione e l'esito e include un identificatore univoco o informazioni di correlazione. Determina inoltre come il sistema rappresenta gli account di servizio, l'automazione e l'attività anonima. Un evento attribuito soltanto ad «API» o «sistema» può essere insufficiente ai fini della responsabilità, salvo che possa essere correlato a una fonte di identità più solida.

Verifica poi il comportamento di recupero e ciclo di vita. Controlla campi ricercabili, filtri, paginazione, formati di esportazione, accesso API ed eventuali capacità di streaming degli eventi. GitLab documenta il filtro per attore e intervallo di date, ma osserva che la ricerca testuale nei dettagli degli eventi di audit non è supportata nella sua interfaccia; raccomanda lo streaming esterno per una ricerca e un'analisi complete. Per questo «visualizzabile nell'interfaccia utente» e «ricerca pronta per l'indagine» dovrebbero essere righe separate del foglio di lavoro.

Infine, valuta la protezione. NIST AU-9 tratta la protezione delle informazioni di audit e degli strumenti di audit logging dall'accesso, dalla modifica e dall'eliminazione non autorizzati come un obiettivo distinto. Un log che un amministratore ordinario può alterare o cancellare senza lasciare traccia non diventa immutabile soltanto perché esiste.

• Copertura: quali azioni richieste vengono registrate e quali no?
• Attore: l'utente umano, l'account di servizio o l'amministratore è identificato in modo affidabile?
• Tempo: esiste un orario preciso dell'evento e i record possono essere correlati tra sistemi?
• Oggetto: la registrazione identifica il record, l'account, l'impostazione o l'entità interessati?
• Esito e dettagli: registra successo, fallimento e contesto sufficiente per comprendere l'azione?
• Ricerca: i revisori possono filtrare per attore, oggetto, tipo di evento e intervallo temporale? Il testo dei dettagli è ricercabile, se necessario?
• Esportazione: le registrazioni possono essere esportate o recuperate tramite un'interfaccia supportata in un formato utile?
• Conservazione: l'archiviazione è abilitata, per quanto tempo gli eventi sono conservati e chi può modificarli o cancellarli?","Protezione: chi può leggere, modificare o eliminare le registrazioni e quali salvaguardie indipendenti esistono?