Audit a prova di manomissione
Un record che non può essere riscritto silenziosamente.
Un log che può essere modificato non è una prova — è un suggerimento. Il log di audit di Clavitor è una catena crittografica: ogni evento viene sottoposto ad hash in quello precedente, la posizione della catena viene testimoniata su un'infrastruttura separata e un singolo passaggio ripercorre l'intero processo per dimostrare che nulla è stato modificato, cancellato o riordinato. Non "promettiamo di non averlo toccato". Lo verifichi Lei stesso.
Ogni azione è registrata.
Una cassaforte di credenziali è affidabile solo quanto il registro di chi l'ha utilizzata. Clavitor registra ogni lettura di credenziali, ogni autofill, ogni richiesta TOTP, ogni accesso, ogni modifica amministrativa — e ogni negazione. Ogni evento riporta chi, cosa, quando, da dove e come è terminato.
Chi e di che tipo
Ogni evento è attribuito a un attore specifico e contrassegnato dal tipo di attore — umano, estensione del browser o agente IA. L'attività dell'agente si distingue dall'attività umana sulla stessa riga, quindi un'abilità di raccolta non può nascondersi nel rumore dell'uso normale.
L'intero ciclo di vita
Crea, leggi, aggiorna, elimina — e ogni uso. L'autofill e l'iniezione proxy vengono registrati allo stesso modo di una lettura manuale. Nulla tocca una credenziale silenziosamente; non esiste un percorso verso un segreto che non lasci una riga dietro di sé.
Risultati, non solo successi
Ogni evento registra come è terminato — successo, fallimento o negato — con un codice motivo. Un agente bloccato, un burst limitato dalla frequenza, un IP rifiutato, un accesso fallito: tutto registrato. Gli auditor si preoccupano più di ciò che è stato fermato che di ciò che è riuscito.
La catena
Sottoposto ad hash nella cronologia.
Ogni riga di audit è legata alla precedente da un hash. Modifichi una riga precedente — modifichi un campo, elimini un evento, riordini due righe — e ogni hash successivo smetterà di corrispondere. La manomissione non è nascosta; è strutturale ed è evidente.
# every row carries the hash of the row before it row_hash = SHA256( prev_hash | event_id | created_at | data ) # any edit, delete, or reorder breaks the recomputation # rows are append-only — never UPDATEd, never DELETEd
Questo è lo stesso principio di sola aggiunta su cui si basa l'intera cassaforte — il log di audit non ottiene una versione più debole di esso. Perché nulla viene mai sovrascritto →
Testimoniato esternamente
Riscriverlo localmente non è sufficiente.
Una catena da sola difende dalle modifiche all'interno del log. Ma l'operatore che possiede il disco potrebbe, in teoria, ricalcolare l'intera catena da un punto di partenza contraffatto. Quindi la catena non vive solo sulla macchina che la scrive.
La testa di ogni catena della cassaforte è ancorata a un'infrastruttura separata — un testimone unidirezionale che registra dov'era la catena ad ogni intervallo. Per riscrivere la cronologia in modo convincente, dovrebbe sconfiggere il log e il testimone, in sincronia, senza mai disaccordarsi.
Un secondo sistema ricorda la posizione
Il POP che scrive il log invia la sua testa di catena — sequenza e hash — al sistema centrale come testimone nel miglior sforzo possibile. Il sistema centrale non è mai nel percorso di scrittura, quindi non può mai rallentare la cassaforte; ricorda solo ciò che gli è stato detto l'ultima volta che la catena appariva.
Se il log locale diventa più corto della posizione testimoniata, si tratta di un riavvolgimento. Se una posizione testimoniata ritorna con un hash diverso, si tratta di un fork. Entrambi sono un tentativo di troncamento o riscrittura — e entrambi attivano un allarme operatore nel momento in cui vengono rilevati.
Verifica su richiesta
Un passaggio. Intatto o rotto.
Non ci creda sulla parola per nessuna di queste cose. La cassaforte ripercorre la catena dalla prima riga, ricalcola ogni hash e le comunica il risultato — un badge di verifica che indica intatto o, se un singolo byte si è spostato, rotto. Non c'è giallo, non c'è "probabilmente a posto". Un controllo di sicurezza che fallisce deve fallire in modo evidente; questo accade.
Crittografato e ancora interrogabile
Il registro dimostra chi ha agito — senza esporre cosa ha toccato.
Il log di audit è crittografato a riposo con lo stesso schema a livello di campo delle credenziali che traccia. Solo le colonne strutturali — ID evento, ID voce, timestamp — rimangono in chiaro, perché è tutto ciò di cui una query ha bisogno. Un disco rubato produce token opachi, non una mappa dei suoi IP, attori e schemi di accesso.
I pivot funzionano ancora senza cedere. Ogni riga contiene token di bucket con hash indicizzati, quindi "tutto ciò che questo IP ha fatto" o "ogni lettura negata" viene eseguito come una ricerca indicizzata e decrittografa solo le righe corrispondenti — mai l'intero corpus, mai un indice in chiaro che un ladro di dischi potrebbe leggere. Lei ottiene la query. L'attaccante ottiene rumore.
Il report
Prove di conformità, a portata di mano.
Il log di audit è una pagina di prima classe nella cassaforte — non un'esportazione che si ricostruisce dopo i fatti. Filtra per attore, voce, IP o intervallo di date. Clicca su qualsiasi cella per eseguire il pivot. Ordina per qualsiasi colonna. Raggruppa per giorno, azione, risultato o attore. I chip di facet mostrano conteggi in tempo reale mentre si restringe. Esporta il risultato in CSV per il Suo SIEM o il Suo revisore.
CMMC LIVELLO 2
Prove di audit e responsabilità
I controlli NIST SP 800-171 3.3.1 (registra ciò che è necessario), 3.3.2 (collega all'identità) e 3.3.8 (protegge l'integrità del log) richiedono identità per evento, IP e timestamp, archiviati in modo protetto e a prova di manomissione. Clavitor registra tutti e tre, crittografa il log e lo concatena.
SOC 2 · ISO 27001
Prove di monitoraggio, interrogabili
Il criterio dei Trust Services CC7.2 e ISO/IEC 27001 A.8.15 richiedono log di autenticazione e azioni privilegiate. Ogni accesso alle credenziali è un evento di questo tipo — tipizzato per attore, con esito registrato, crittografato, filtrabile ed esportabile.
HIPAA · GDPR
Responsabilità, per progettazione
I controlli di audit HIPAA §164.312(b) e gli obblighi di responsabilità del GDPR Articolo 32 sono soddisfatti dallo stesso log. Nessun modulo di conformità separato, nessun costo aggiuntivo — il log di audit fa parte del prodotto. I piani Enterprise aggiungono l'esportazione cross-vault al Suo SIEM.
La policy diventa prova.
Senza un registro affidabile, ogni affermazione sul controllo degli accessi è solo una policy — "non guardiamo", "gli agenti sono con ambito limitato", "nulla trapela". Con un log concatenato, testimoniato e verificabile, queste affermazioni diventano cose che può verificare. Questa è la differenza tra chiederle di fidarsi di noi e permetterle di verificarci.
Vedi l'altra metà del registro.
Il log di audit dimostra chi ha agito. L'immutabilità dimostra che i dati su cui hanno agito non sono mai stati modificati silenziosamente sotto di loro.