AuditRails vs costruire da soli il log di audit
«Basta scrivere su Postgres e aggiungere un timestamp»: è da qui che parte la maggior parte dei progetti interni di log di audit, ed è qui che si nasconde la maggior parte del costo reale. Segue un quadro realistico di che cosa serve per costruire internamente un log a prova di manomissione e accettato dagli auditor, e di dove il percorso interno di norma si rompe.
Il costo reale di costruirlo da soli
Questo è il costo tipico di una costruzione da zero per un piccolo team platform o security, in base agli elementi che un auditor verifica davvero.
| Voce di costo | Costruirlo da soli |
|---|---|
| Tempo di ingegneria (costruzione iniziale) | Da 4 a 8 settimane per un ingegnere di livello medio, per progettare uno schema a catena di hash o append-only, collegare l'ingestione e costruire un percorso di query ed export. Di più se anche la conservazione WORM e l'isolamento per tenant sono nuovi per il team. |
| Configurazione dello storage WORM | S3 Object Lock (o equivalente) deve essere configurato in modalità compliance con il periodo di conservazione corretto prima che arrivino i dati, poiché non può essere allentato retroattivamente su oggetti già bloccati. Impostare correttamente fin da subito la policy del bucket, le regole di lifecycle e i confini IAM è un progetto a sé. |
| Politica di conservazione per framework | SOC 2, HIPAA, PCI DSS e SOX specificano ciascuno finestre di conservazione minima diverse. Una politica generica «conserviamo i log per un anno» non regge in presenza di più framework, e correggere a posteriori la conservazione su dati già scritti non è semplice con lo storage WORM. |
| Strumenti di verifica | Un auditor, o la funzione sicurezza interna, ha bisogno di un modo per dimostrare che il log non è stato alterato in un secondo momento, non soltanto che è archiviato in modo durevole. Questo significa costruire e mantenere un verificatore di catena di hash, indipendente dal sistema che ha scritto i log, in grado di ricalcolare e controllare ogni voce. |
| Manutenzione continua | Modifiche allo schema, nuovi tipi di evento, scalare il percorso di query oltre qualche milione di righe, e rispiegare l'intero sistema a un nuovo auditor a ogni ciclo. È un costo permanente, non una costruzione una tantum. |
Dove il log di audit fai-da-te di solito si rompe
La parte di base dati è quella semplice. Le obiezioni degli auditor nascono da ciò che i team saltano sotto la pressione delle scadenze: nessuno strumento di verifica indipendente, per cui l'affermazione «è una catena di hash» non è dimostrabile; una conservazione non bloccata prima di conoscere il requisito del framework; e nessuna separazione netta tra il sistema che scrive i log e quello che li archivia, che è una domanda diretta in sede di audit.
Quando costruirlo internamente è la scelta giusta
Con esattamente un framework di conformità, un volume di eventi basso e un ingegnere di sicurezza che possa presidiarlo come responsabilità continua e non come progetto secondario, la costruzione interna può funzionare. È una scelta ragionevole per un team platform ben dotato che voglia il controllo completo su schema e livello di query. Diventa più difficile quando occorre rispondere ad auditor su più framework o consegnare uno strumento di verifica alla funzione sicurezza di un cliente.
Domande frequenti
Quanto tempo serve davvero per costruire il log di audit internamente?
Per una versione minima, una tabella append-only con riferimento temporale, pochi giorni. Per qualcosa che superi un audit SOC 2 o HIPAA, quindi a prova di manomissione, con conservazione WORM corretta e verifica indipendente, il conto realistico è di 4-8 settimane di lavoro dedicato, più la manutenzione continua.
Una catena di hash è eccessiva per i log di audit?
Non se un auditor chiederà come si fa a sapere che un log non è stato modificato in un secondo momento. Una semplice tabella append-only non dimostra nulla sulla manomissione; una catena di hash, dove l'hash di ogni voce dipende dalla precedente, rende qualsiasi alterazione rilevabile matematicamente. AuditRails la integra di default, quindi non è un progetto separato.
È sufficiente S3 Object Lock, senza catena di hash?
Object Lock (WORM) è necessario ma non sufficiente. Impedisce che un oggetto sia eliminato o sovrascritto entro il periodo di conservazione, ma non dimostra che ciò che è stato scritto inizialmente fosse completo e non alterato prima di arrivare nel bucket. AuditRails combina la conservazione WORM con una catena di hash per tenant, così che entrambe le proprietà valgano.
E se dopo la costruzione interna si aggiunge un secondo framework di conformità?
È di norma il momento in cui la decisione di costruire internamente viene rivista: uno schema e una politica di conservazione pensati per un framework spesso richiedono modifiche per un secondo, con requisiti di conservazione o di campi diversi. I toggle dei framework di AuditRails, sui piani Framework Trails e Compliance Trails, esistono proprio per questo, dato che il formato di log sottostante non cambia da un framework all'altro.