La pista di audit

01In una frase #sec_311beda8

La pista di audit registra ciò che è accaduto in REVIEWIT — chi ha fatto cosa, quando, su cosa e con quale risultato — in una forma di cui si può dimostrare che non è stata modificata a posteriori.

02Una precisione di vocabolario #sec_fbdaf12f

In REVIEWIT, la parola audit designa sempre la pista di audit: la traccia degli atti compiuti nel prodotto.

L'acquisizione dei dati presso il cliente — l'inventario dei siti, dei gruppi, degli accessi — si chiama la raccolta. Le due non hanno nulla a che vedere, e confonderle porta a cercare prove dove c'è solo inventario.

03Il problema #sec_9df23eaa

Uno strumento di ricertificazione produce prove sul sistema informativo del cliente. Una domanda si pone allora immediatamente, ed è la prima che pone un auditor serio:

E lo strumento stesso, cosa prova ciò che ha fatto?

Senza risposta, tutto il dispositivo si basa sulla fiducia accordata all'operatore. Ora, i gesti che contano di più sono precisamente quelli che un operatore malintenzionato avrebbe interesse a cancellare: aver escluso una risorsa dal perimetro, aver messo in atto una delegazione, aver annullato una campagna, aver modificato una regola appena prima di una scadenza.

Ne derivano tre esigenze, e sono più dure di quanto sembri:

Registrare i fallimenti tanto quanto i successi. Una pista che registra solo le azioni riuscite prova solo ciò che ha funzionato. I tentativi rifiutati, gli accessi respinti, gli errori di sicurezza sono spesso l'informazione più utile.

Resistete a colui che tiene la base. Una traccia protetta da un meccanismo che l'operatore controlla non è una prova contro l'operatore.

Non sopravvalutare mai la propria garanzia. Una pista che annuncia più protezione di quella che offre è peggio di una pista modesta: produce una fiducia ingiustificata.

04Il partito preso #sec_19917edd

L'integrità della pista non deve dipendere né da un motore di base di dati, né da un hoster.

È la decisione strutturante, ed è stata presa contro diverse soluzioni più facili.

Le funzionalità di immutabilità offerte dai motori di base di dati moderni, le tabelle temporali e i servizi gestiti di timestamping sono stati tutti scartati. Funzionano, ma spostano la fiducia verso un terzo — l'editore del motore, il fornitore di cloud — e intrappolano il prodotto: una pista di audit che non sopravvive a un cambio di hoster non è un asset del cliente.

La garanzia è quindi interamente applicativa, portata dal prodotto stesso, e verificabile ovunque giri. È coerente con il resto della piattaforma, che si dispiega nella regione scelta dal cliente.

Tre principi completano questa scelta:

1. Il socle non si disattiva. Non esiste alcuna impostazione che permetta di spegnere la pista di audit — altrimenti si disattiverebbe l'audit dall'audit. Ciò che è configurabile è la finezza di alcuni eventi di lettura, mai la registrazione degli atti.

2. Un atto sconosciuto si scrive comunque. Il catalogo delle azioni vive in base e conta oggi quasi duecentoquaranta voci. Ma se una versione del prodotto emette un codice che il catalogo non conosce ancora, l'evento viene scritto nonostante tutto. Rifiutare di registrare ciò che non si sa nominare sarebbe il modo migliore per creare un angolo morto.

3. Si annuncia ciò che è realmente garantito. Il rapporto di verifica indica il livello di protezione effettivamente in atto — mai quello previsto.

05Come funziona #sec_e77f0329

Due percorsi di acquisizione

Questo è il punto architetturale più importante e deriva direttamente dal requisito "registrare i fallimenti".

Il percorso transazionale serve gli atti compiuti. L'evento viene depositato nella stessa transazione dell'atto aziendale che descrive. La conseguenza è assoluta: se l'atto fallisce e la transazione viene annullata, non rimane alcuna traccia orfana; se l'atto ha successo, la sua traccia esiste necessariamente. Non può esserci alcun divario tra ciò che il prodotto ha fatto e ciò che la traccia racconta.

Il percorso autonomo serve tutto il resto: tentativi rifiutati, fallimenti di autenticazione, accessi respinti, errori di sicurezza. Questi eventi, per natura, non hanno alcuna transazione aziendale a cui aggrapparsi - l'atto non ha avuto luogo. Senza questo secondo percorso, la traccia proverebbe solo i successi.

Il collegamento

Ogni evento riceve un identificatore, una posizione di sequenza assegnata alla scrittura e un'impronta crittografica che include quella dell'evento precedente. La traccia forma così una catena: modificare un evento passato invalida tutti i successivi.

Ogni catena si apre con un evento di genesi posizionato in prima posizione. Senza di esso, si potrebbero eliminare i primi eventi di una catena e presentarla come completa.

La forma esatta dei dati sottoposti all'impronta è normalizzata e versionata: due sistemi che verificano la stessa traccia ottengono lo stesso risultato, oggi come tra cinque anni.

Il meccanismo è stato testato contro sette forme di alterazione distinte - modifica del contenuto, eliminazione, inserimento, riordinamento - tutte rilevate.

I tre livelli di garanzia

Il prodotto distingue esplicitamente ciò che garantisce e non pretende mai il livello superiore.

Il rapporto di verifica è datato e annuncia il livello reale. Finché la sigillatura non è in atto, indica "collegamento solo" - e soprattutto non N1. Questa disciplina è deliberata: un rapporto che sopravvaluta la sua garanzia non vale nulla davanti a un revisore che sa leggere.

La chiave di sigillatura è dedicata

La chiave che sigilla la traccia di audit non è mai quella che firma i documenti prodotti dal cliente.

La ragione è semplice: chi può firmare un rapporto non deve poter sigillare la traccia che dimostra come è stato prodotto quel rapporto. Separare i due - e separare la base di audit dal firmatario - è la condizione perché la sigillatura voglia dire qualcosa.

06Ciò che viene registrato e ciò che non lo è #sec_548db5ca

Gli atti. Tutto ciò che modifica lo stato del dispositivo: campagne create, lanciate, annullate; decisioni prese; esclusioni poste e revocate; deleghe messe in atto e revocate; regole modificate; ruoli assegnati; richieste di eliminazione emesse e trattate; configurazione modificata.

I tentativi e i rifiuti. Attraverso il percorso autonomo, come spiegato sopra.

Le letture - in modo graduale. Tracciare ogni visualizzazione dello schermo produrrebbe un volume che sommerebbe le informazioni utili. Le consultazioni correnti sono quindi campionate, con tre eccezioni sistematicamente registrate:

• le esportazioni, perché fanno uscire i dati dal sistema;
• le consultazioni di dati personali nominati;
• le consultazioni di prova, perché sapere chi ha guardato il fascicolo prima di una scadenza ha un valore di audit.

Le conversazioni con RITA - solo tramite impronta. La traccia registra che è stata posta una domanda e cosa ne è risultato, mai il testo della domanda. Conservare il contenuto degli scambi equivarrebbe a costituire una cronologia di ciò che gli utenti si chiedono, che non è l'oggetto di una traccia di audit.

I dati di dimostrazione - contrassegnati come tali. I set di dati sintetici rimangono possibili, ma la loro provenienza è contrassegnata e questo contrassegno si propaga a tutto ciò che ne deriva. Una dimostrazione non deve mai poter essere confusa con la produzione.

07Chi vede cosa #sec_1be12c7e

La visibilità è discendente: l'amministratore di un workspace vede gli eventi di livello sottoscrizione che designano il suo workspace - la creazione del suo perimetro, l'attribuzione delle sue funzionalità, la modifica della sua allocazione.

Questo è il complemento necessario della governance delegata: un'entità a cui si affida l'autonomia deve poter constatare le decisioni prese al di sopra di essa che la riguardano. Non vede invece nulla delle altre entità.

Il revisore dispone di un accesso in lettura stretto all'intera traccia del suo perimetro e di un motore di ricerca per navigare al suo interno.

08Una scelta assunta: l'avvio a zero #sec_c32441da

La nuova traccia di audit non riprende la cronologia della precedente.

Questo non è un rinuncia tecnica. Il vecchio registro non offriva alcuna garanzia di integrità, la sua copertura era parziale e il suo vocabolario ambiguo. Riprenderlo equivarrebbe a far entrare in una catena sigillata dati di cui non si può affermare nulla - e quindi a far credere che beneficiano di una garanzia che non hanno mai avuto.

Meglio una traccia breve e solida che una lunga traccia di cui la prima metà non prova nulla. Lo stesso ragionamento si applica alla sostituzione del dispositivo di autenticazione.

09Cosa può aspettarsi l'auditore #sec_7f268117

• Un rapporto di verifica datato, che afferma che la catena è intatta — o designa precisamente dove non lo è.
• La certezza che nessuna azione completata sia assente, per costruzione transazionale.
• La traccia dei rifiuti, e non solo dei successi.
• L'origine di ogni atto: l'autore, la superficie, il momento, l'oggetto, e lo stato prima/dopo quando ha senso.
• Un export incrementale, per versare la pista nel proprio strumento di analisi o nel proprio SIEM.

10Da ricordare #sec_cc1ba3dd

Un prodotto di conformità che non può rendere conto delle proprie azioni richiede che gli si creda sulla parola. La pista di audit di REVIEWIT è costruita per non doverlo fare.

È indissociabile dal prodotto — non disattivabile, alimentata nella stessa transazione delle azioni che descrive, anche quando queste azioni falliscono. È indipendente dall'infrastruttura, quindi portabile e verificabile ovunque. Ed è onesta sulla propria forza: annuncia il livello di garanzia che realmente offre, mai quello che mira a raggiungere.