---
title: "Audit a prova di manomissione"
description: "Un log che può essere modificato è un suggerimento, non una prova. Il log di audit di Clavitor è una catena crittografica — testimoniata esternamente e verificabile con un clic."
lang: it
url: https://clavitor.ai/it/audit
markdown: https://clavitor.ai/it/audit.md
translation_of: https://clavitor.ai/en/audit.md
authoritative: false
publisher: Clavitor LLC
---

> This is the Italian translation of [Tamper-evident audit](https://clavitor.ai/en/audit.md). The original English text is authoritative; where the two differ, the English version prevails.

# 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.

umano · estensione · agente

### 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é.

crea · leggi · usa · aggiorna · elimina

### 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.

successo · fallimento · negato + motivo

## 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 →](https://clavitor.ai/it/immutable)

## 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.

### Il disaccordo genera un allarme

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.

### Allineato a SOC 2 / ISO 27001 (autovalutato): 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.
[La cassaforte immutabile →](https://clavitor.ai/it/immutable)
[Come funziona la crittografia](https://clavitor.ai/it/security)
