Evidenze di audit da consegnare a chi non si fida di voi
Aggiornato
In breve
Come si dimostra che un record non è stato alterato a posteriori?
Kelvyn appone agli eventi di audit marche temporali RFC 3161 ottenute da un’autorità di marcatura temporale esterna e li concatena per tenant, così che qualsiasi modifica successiva invalidi la verifica della catena. L’approvazione del Consiglio genera pacchetti di archivio sigillati: un file ZIP con i checksum, a sua volta marcato temporalmente, con un endpoint che ne verifica l’integrità. L’evidenza è verificabile da soggetti esterni alla vostra organizzazione: è l’unico tipo di evidenza che chiude una discussione sull’integrità di un record.
Marche temporali che vengono da fuori
Una marca temporale interna non dimostra nulla a chi sospetta del sistema che l’ha scritta. Le marche RFC 3161 sono richieste a un’autorità di marcatura temporale esterna e verificate alla ricezione, così che l’affermazione secondo cui un record esisteva in un dato momento non dipenda dal nostro orologio né dalla nostra parola.
È il meccanismo che sostiene gli obblighi di conservazione che richiedono un’integrità dimostrabile e non semplicemente asserita.
Una catena, non un registro
Gli eventi di audit sono scritti in una hash chain ordinata e distinta per tenant. La verifica ricalcola la catena: qualsiasi modifica successiva a una voce precedente la invalida. La proprietà garantita non è che i record non possano essere modificati, ma che una modifica non possa restare nascosta.
Il registro di audit di sicurezza è inoltre immutabile a livello di database, garantito da un trigger e non da codice applicativo che una modifica futura potrebbe dimenticare di richiamare.
Pacchetti sigillati, generati all’approvazione
All’approvazione del Consiglio viene generato automaticamente un pacchetto di archivio: le evidenze, i relativi checksum e una marca RFC 3161 apposta sul risultato. Un endpoint di verifica ricontrolla il pacchetto, così che il destinatario possa accertarlo direttamente anziché ricevere una rassicurazione.
Le versioni dei business plan sono conservate in forma immutabile per dieci anni; versioni di portafoglio, di curva e di file mantengono la propria tracciabilità.
Perimetro
Che cosa non fa
Gli accessi in lettura non sono tracciati. Il registro raccoglie scritture, approvazioni ed eventi di autenticazione; non esiste una registrazione generale di chi abbia consultato che cosa.
Non esiste un’esportazione del registro di audit a disposizione dell’utente. Il registro è consultabile e filtrabile nel prodotto, ma i pacchetti di archivio esportano le evidenze di governance, non l’audit trail in quanto tale.
I valori di dettaglio precedenti e successivi a una modifica sono registrati nei punti che li registrano, e non da un trigger di database su ogni tabella. La copertura è ampia ma non è universale per costruzione, ed è corretto dichiararlo.
Domande
- Chi emette le marche temporali?
- Un’autorità di marcatura temporale RFC 3161 esterna. La risposta è verificata alla ricezione, così che la garanzia non dipenda dall’orologio di Kelvyn.
- Che cosa accade se qualcuno modifica un record direttamente sul database?
- La verifica della catena fallisce. L’obiettivo di progetto non è rendere impossibili le modifiche, ma rendere impossibile una modifica non rilevabile.
- Un terzo può verificare un pacchetto di archivio senza accedere a Kelvyn?
- Il pacchetto contiene i propri checksum e la propria marca temporale, ed esiste un endpoint che lo verifica. È ciò che lo rende utilizzabile come evidenza e non come semplice report.
Correlati