Controllo e registri invariati

Controllo e registri invariati

1) Perché è necessario

L'obiettivo della verifica è quello di fissare «chi, cosa, dove, quando e perché» con un'integrità dimostrabile per mantenere la sicurezza, le indagini, i rapporti finanziari e la conformità.
Il registro invariato è un formato e un archivio in cui gli eventi vengono scritti solo con l'aggiunta (append-only) e la successiva modifica/rimozione non può essere eseguita o rilevata con strumenti e regole di memorizzazione crittografiche.

2) Modello di minacce e obiettivi di controllo

• Modifica/rimozione intenzionale degli eventi con un'insidia.
• Cambio ora/sorgente (replay/backdating).
• Disattivazione silenziosa della logica sul nodo.
• Perdita di una parte del registro in caso di incidenti/migrazioni.
• Eccesso di raccolta di PII e discontinuità.

1. Integrità provata dalla protezione contro le modifiche/rimozioni.

2. Completezza: chiusura dei flussi chiave (control plane, data plane, disponibilità, denaro).

3. Ora riproducibile, ora sincronizzata.

4. Disponibilità: lettura e ricerca all'interno di SLO.

5. Privacy: PI minimo, tornizzazione/crittografia, legittimità di utilizzo.

3) Tassonomia e priorità degli eventi

• Ctrl Plane: autenticazione/autorizzazione, modifiche alle configurazioni, operazioni con chiavi (KMS), gestione dei segreti, modifica dei criteri.
• Data Plane: accesso a oggetti/registri/checkout/pagamenti; lettura/creazione/eliminazione.
• Addin e DevOps: SSH/console, CI/CD, modifiche all'infrastruttura/IaC, escalation dei diritti.
• Prodotti: transazioni, bollo, transazioni dei clienti.
• Sistema/Rete: kernel/agenti/proxy/bilanciatori, broker, database.
• Sicurezza: IDS/IPS/EDR, WAF, anti-DDoS, antifrode, DLP.

Per ciascuna classe è possibile registrare criticità, schema, campi obbligatori, conservazione, requisiti di invariabilità.

4) Campi obbligatori e formato

Gli ID di correlazione sono «trace _ id», «span _ id», «sollest _ id», «attore _ id» (utente/servizio), «tenant _ id», «resource _ id».
Contesto A&A: metodo di autenticazione, ruolo/criteri al momento dell'azione.
Tempo: RFC3339/UTC, millisecondi/nanosecondi; sorgente di sincronizzazione.
L'azione e il risultato sono il tipo di operazione, l'obiettivo, lo stato e il numero di oggetti interessati.
Integrità: record locale HMAC, numero di ordine (sequence), hash-prev.
Schema: JSON con modello stabile (ad esempio, compatibile con dizionari di eventi condivisi).

Proibito: segreti, chiavi, token completi PAN, password, chiavi private. PII - solo per necessità, mascherato/tornizzato.

5) Tempo e sincronizzazione

Sorgente tempo: almeno due sorgenti indipendenti (NTP/PTP) + monitoraggio offset.
Etichette temporali critiche: utilizzare i servizi TSA o il servizio time-sealing interno per i pacchetti di eventi.
Regole: nessun fuso orario locale, solo UTC; logica e sposta/qualità del tempo.

6) Architettura di flusso dei fogli

Agenti Landing-Hash-Catena/Firma Freddo/Archivio-Indice di ricerca.

Raccolta su un nodo: agenti leggeri (daemonset/sidecar) con buffer su disco (back-pressure).
Trasporti: canale protetto (TLS/mTLS), consegna garantita (at-least-once), idempotent-ingest.
Area landing: magazzino di oggetti in «formaggio» (partizioni per data/tenanto/tipo).
Indice: motore di ricerca/analisi per le query online (livello caldo).
Archivio (WORM) - Contenitori/nastri invariati con regole di rettifica e legale hold.
Anchor/Seal - Scorrimento periodico di pacchetti di catene hash (vedere sotto).

7) Invariabilità crittografica

7. 1 Catene di hashtag (append-only)

Ogni voce contiene: 'hash _ curr = H (record)', 'hash _ prev', 'seq'. Ogni modifica rompe la catena.

prev = GENESIS for record in stream:
payload = canonical_json(record_without_integrity_fields)
h = H(payload          prev.hash          record.seq)
store(record + {hash_prev: prev.hash, hash_curr: h})
prev = {hash: h}

7. 2 Firma pacchetti e timbro temporale

Ogni N secondi/MB formiamo la radice di Merkle di tutti gli «hash _ curr».
Firmiamo la chiave di controllo (memorizzata in KMS/HSM).
Aggiungete un valore temporale a TSA e pubblichiamo un catalogo di blocchi.
Opzionale: fissare periodicamente l'hash radice in uno spazio provabile esterno (ad esempio un registro indipendente o un deposito pubblico invariato).

7. 3 Gestione delle chiavi di controllo

Le chiavi di firma sono in KMS/HSM, rotazione grafica, accesso multifattore, dual-control per l'esportazione.
La revoca della chiave → un nuovo ramo di fiducia; le vecchie firme rimangono verificabili.

8) Criteri di conservazione e WORM

WORM/immutability: includiamo contenitori/bidoni invariati con la regola Retention e Legale Hold per le classi P0/P1.
Versioning attivato; rimozione: solo per le procedure di ritardo (disabilitazione del purge istantaneo).
Retenza: caldo (7-30 giorni), caldo (3-6 mesi), freddo/archivio (1-7 anni o più a seconda del regolatore/contratto).
Multiplicità: singoli spazi nomi/account/chiavi di crittografia per locatore; Report sulla disponibilità ai registri.

9) Privacy e minimizzazione

La raccolta è obbligatoria, non è superflua.
Tornizzazione/alias dei campi sensibili, hash con sale per gli identificatori.
Crittografia dei campi sul lato produttore (AEAD) durante l'archiviazione in un archivio oggetti condiviso.
Diritto di rimozione (se applicabile): consente di eseguire la crittografia-cancellazione delle chiavi dei campi/partiture senza compromettere l'immutabilità del contenitore (pianificata per la progettazione).

10) Accesso, ruoli e controllo del controllo stesso

Separazione: producers ≠ readers ≠ admins.
Solo lettura da WORM Modificare i criteri di retensione attraverso ruoli separati e una procedura approvata.
Tutte le operazioni di lettura/esportazione vengono registrate in un registro secondario (meta-controllo).
Esporta per l'indagine/compilation in una vista crittografata con la directory hash e la catena di affidabilità.

11) Osservabilità e SLO

Metriche: velocità di input, lega a indice,% persi/ripetuti, percentuale di tempo non incronizzato, errori di firma/ancoraggio, riempimento buffer.
SLO: ≥99. 9% degli eventi ricevuti con X secondi prima dell'indice caldo; 0 «buchi» inspiegabili nelle sequenze; Il 100% dei blocchi sono firmati e fissati in tempo.
Alert: pausa dell'iniezione> N minuti, altezza invalid-hash, disconnessione della catena, firma/timestamp fallita, spostamento del tempo oltre la soglia.

12) Test e verifica

Test Red/Blue: tentativo di modifica/rimozione di record in diverse fasi; Verifica dei rilevamenti.
Chaos: disattivazione dell'agente sul nodo, interruzione della rete, sovraccarico del buffer, cambio dell'ora.
Crypto-test: validazione regolare delle catene, incrociamento delle radici di Merckle e dei timbri.
Forenzica: riproduce gli script di indagine dai registri end-to-end.

13) Funzionamento e procedure

Runbook Controllo integrità (on-demand e pianificato).
Procedura legale hold e temporanea «congelamento» delle partiture.
Procedura di discovery ed esportazione mantenendo la catena di fiducia.
Piano di rotazione delle chiavi di controllo e risposta alla compromissione (nuovo ramo di fiducia, penne-firma blocchi, notifiche).

14) Mini-ricette

records = read_partition(ts_window)
leaves = [H(canonical_json(r)) for r in records]
root  = merkle_root(leaves)
sig   = KMS.sign(root          ts_now)
tsa   = TSA.timestamp(sig)
store_block({root, sig, tsa, count=len(leaves), window})
append_transparency_log(H(root          sig          tsa))

for i in 1..N:
assert rec[i].hash_prev == rec[i-1].hash_curr assert rec[i].hash_curr == H(canonical_json(rec[i]_no_hash)          rec[i].hash_prev          rec[i].seq)

• Controllo/Data Plane P0: caldo 30 giorni, caldo 6 mes archivio 7 anni (WORM).
• : 14 giorni bollenti, 3 giorni caldi.
• I segnali di sicurezza sono 90 giorni caldi (per le indagini), poi 1-3 anni.

15) Errori frequenti

«I fogli sono testo senza schema». Senza uno schema, non c'è integrità e ricerca determinate; è obbligatorio il JSON canonico e i campi fissi.
Nessuna correlazione. L'assenza dì trace _ id "rompe le indagini.
Ora locale. Solo UTC e controllo di spostamento.
Scrittura nei volumi da modificare. Senza WORM, ogni invincibilità è una fiction.
Non logificheranno la lettura. La lettura dei dati sensibili è importante per registrare quanto una scrittura.
I segreti sono nei reparti. Attivare i servizi igienici prima dell'invio, gli elenchi rossi dei pattern.
Una chiave per tutto. Le chiavi di firma e crittografia sono separate, con ruolo e rotazione.

16) Conformità e regolamentazione

I requisiti di conservazione/invariabilità dipendono dal dominio (finanza, pagamento, TV, ecc.).
Prova: disponibilità di protocolli WORM/Retence, rapporti di convalida delle catene, registri di accesso ai registri, procedure legali hold ed esportazioni.

17) Assegno fogli

Prima di vendere

• Approvata la tassonomia degli eventi e lo schema (campi obbligatori).
• Agenti configurati, buffer, trasporti protetti, back-pressure.
• Incluse: catene di hashtag, firma di blocco, timbro temporale, transparency-logg.
• L'archivio WORM/Retence è abilitato prova di impossibilità di sovrascrivere/eliminare.
• Maschera/tornizza i campi sensibili.
• Sincronizzazione del tempo e monitoraggio dello spostamento.
• Piano di rotazione e memorizzazione delle chiavi di verifica in KMS/HSM.

Utilizzo

• Convalida settimanale di catene e blocchi (+ report).
• Alert per interruzione della catena/errori di firma/offset temporale.
• Test di sostituzione/rimozione di Red team periodici.
• Review regolare delle retene e dei costi.

18) FAQ

C: È sufficiente una semplice aggiunta a livello di database?
Oh, no. Sono necessarie le garanzie crittografiche (catene di hashtag, firme di blocchi, timbri temporali) e i criteri WORM.

C: Come funziona il diritto di eliminazione dei dati?
O: Progetta la crittografia (rimozione delle chiavi) per i campi/partiture, mantenendo l'immutabilità del supporto e la prova dei registri.

C: È necessaria una chiave separata per la firma dei blocchi?
Oh, sì. Separare le chiavi di firma dei blocchi dalle chiavi di crittografia dello storage; memorizzare in KMS/HSM, con rotazione e revisione.

Si può «ancorare» in uno spazio pubblico?
Opzionale. Questo aumenta la validità e ritaglia la cronologia all'interno del tracciato.

• Crittografia At Rest'
• Crittografia in transit
• «Gestione dei segreti»
• Gestione e rotazione delle chiavi
• Firma e verifica query