Registri controllo operazioni
(Sezione Operazioni e Gestione)
1) Assegnazione e principi
Il registro di verifica è la fonte primaria della verità su chi, cosa, dove, quando e perché ha fatto, con la possibilità di dimostrare l'immutabilità e l'autenticità dei record.
Principi:- Completezza: le azioni di persone, servizi e partner esterni sono coperte.
- Invariabile: i record non possono essere riscritti o eliminati senza traccia visibile.
- Assegnazione: l'azione è associata a un soggetto, un ruolo, un contesto, un artefatto.
- Riproducibile: è possibile riprodurre un evento in un report/discussione.
- Riduzione del PI: solo necessario, con maschera e token.
2) Aree di copertura
Azioni utente: accesso/SSO/MFA, modifica di ruoli/limiti, operazioni PII.
Attività privilegiate: sessioni JIT/PAM, break-glass, console admine.
Finanza: fogli di credito/tasse/FX pubblicazioni, pagamenti/pagamenti, escrow, prelievi/rimborsi.
Configurazioni/rilasci: ficheflagi, migrazioni di schemi, deposito/reimpostazione, chiavi/certificati.
Integrazioni: webhoop, firme, ricevute, chiavi idempotency.
Dati: lettura/esportazione PII, creazione/rimozione di artefatti, modifiche alle regole.
3) Architettura e invariabilità
Gateway Ingest con autenticazione, quote e convalida schema.
Storage WORM (immutabile buckets/append-only) - Versione, Retention Lock, Legale Hold.
Crittoccidenze - Per gli eventi critici, viene generata la firma «receipt _ hash» e DSE.
Catene merkle - Viene creato periodicamente un taglio (checkpoint) e pubblicato un hash radice.
Chain of custody - Traccia lo spostamento degli artefatti (chi ha avuto accesso, quando, su quale base).
Time Sync: NTP/PTP, etichette «event _ time» e «ingest _ time», regolazione «skew».
4) Schema evento (arbitro)
audit_event {
id, event_time, ingest_time, producer, subject {
id, type: human service partner, roles[], mfa?, device_posture?
},
action: CREATE READ UPDATE DELETE EXECUTE PUBLISH APPROVE ROLLBACK,
target { type, id, version?, region?, tenant? },
context { ip/asn, user_agent, env, trace_id, request_id },
policy_version, sod_check: pass fail, justification?, ticket_ref?,
result: success deny error, error_code?,
diff_hash?, payload_hash?, receipt_hash?, dsee_signature?,
pii_classification: none aggregated tokenized sensitive,
retention_class, labels[]
}
Aggiuntivo: per la finanza: 'fx _ variante/tax _ rule _ variante/pricelist _ variante'; per i webhook'webhook _ id ',' idempotency _ key '.
5) Modello di dati e zone
Hot (in linea): 7-30 giorni, richieste rapide/dashboard.
Warm (OLAP): 6-24 mes, analista/ricerca.
Cold (archivio/WORM): fino a 7-10 anni (regolazione).
Le classi di retenza sono «operational», «financial», «security», «legale _ hold».
Versioning criteri: tutti gli eventi sono contrassegnati con «policy _ variante»; Modifica dei criteri - Evento di verifica separato.
6) Accessibilità e privacy
RBAC/ABAC/ReBAC: visibilità per ruolo/tenente/regione/caso (case).
Maschera PII - Tornering degli identificatori, output dei primari solo attraverso i giubbotti approvati.
Solo «tombstone» + Legale Hold; «addominali» esposti con un singolo registro.
Controllo del controllo stesso: chi ha guardato/scaricato i loghi è anche logico.
7) Qualità, consistenza, prese
Data contracts: schema rigoroso e convalida lambda all'ingresso.
Idempotency & deadup: '(event _ id, producer)'; «seen-cache» + KV.
Regolazione temporale: filigrana (watermarks) per eventi recenti.
Controllo completezza: confronto tra i contatori sorgenti e le metriche ingest.
8) Dashboard e richieste
Attività operative: azioni privilegiate, violazioni soD, sollevamenti di diritti JIT, accesso al PII.
: pubblicazioni di , discrepanze di , firme chiave.
Integrazioni: ricevute di webhoot, lega, retrai, prese.
Comunicati/confighi: chi/quando/cosa ha attivato/ricollocato, collegamento con gli incidenti.
Script di ricerca: «trace _ id», «subject». id`, `target. id, tempo/regione/tenante, 'policy _ variante'.
Esporta: download batch su richiesta con ricevuta (manifesto firmato).
9) API e webhook
«POST/audit/ingest» - Accetta eventi (autenticazione, limiti, schema).
«GET/audit/search» - filtri, paginazione, limite per risultato.
«GET/audit/trace/{ trace _ id}» è un collegamento di eventi lungo la catena.
«POST/audit/receipt/verify» è un controllo della ricevuta/DSSE.
Вебхуки: `SoDViolation`, `PrivilegedSession`, `PIIAccess`, `PolicyChanged`, `FinancialArtifactPublished`.
10) SLO/metriche di qualità del controllo
Ingest Availability: ≥ 99. 95%.
Freshness (in linea): ≤ 30 da p95.
Completeness: ≥ 99. Il 5% delle fonti ha inviato i dati alla finestra.
Correctness: la soluzione di controllo ≤ 0. 1%.
Tamper-evidence: il 100% dei periodi sono certificati Merkle-radici/firme.
PII Hygiene: 100% degli eventi con classe sensibile con maschera/token.
11) Playbook e incidenti
Sospetto di sostituzione record: controllo immediato delle radici Merkle, incrociamento delle ricevute DSSE, isolamento dell'accesso, Legale Hold.
Fuoriuscita PII: ricerca degli eventi/esportazioni interessati, controllo degli accessi, notifiche al DPO/Regolatore.
Violazione della SoD: blocco delle operazioni, rimozione temporanea del ruolo, indagine e regolazione della politica.
Guasto ingest: buffer, modalità di degrado, repliche dopo il ripristino, controllo dei duplicati.
12) Estratto legale e compilazione
Recensione per giurisdizione: finanza/tasse - 5-10 anni Sicurezza - Politica i dati personali sono la durata minima necessaria.
Legale Hold: congelamento delle cancellazioni per caso/richiesta del regolatore.
L'indice dei periodi, l'hash radice, la lista dei firmatari, l'inventario delle fonti.
Non dichiarabile: cryptopodpisy, timestamping indipendente (TSA interno).
13) Specificità iGaming/Fintech
Pagamenti/pagamenti: tracciamento completo di autorizzazioni, compensazioni, rifiuti, marceback; mappatura con ricevute bancarie.
RTP/limiti - Pubblicazioni di profili, modifiche monitorate da RTP e soluzioni di limitazione con firme e versione.
Affiliati: ricezione di webhoop, deducibilità di conversione, obiezioni/escrow, solo con manufatti firmati.
Fogli price/tasse/FX: versione del manufatto in ogni ordine; rimborsi con ricevute.
14) RACI
15) Rischi e anti-pattern
I loghi modificabili senza lasciare traccia sono un problema legale.
Nessuna sincronizzazione temporale per le timeline non corrette.
Esportatori Shadow senza ricevute di fuoriuscite/dispute.
I segreti nei → sono compromessi.
Non c'è nessun collegamento con gli SLO/incidenti del cimitero dei dati.
16) Assegno-foglio di implementazione
- Definire le aree di copertura e policy _ vision.
- Espandi ingest con autenticazione, schemi e quote.
- Abilita i tagli WORM, Merkle, DSE, TSA.
- Configura le retenze per classe e Legale Hold.
- Immettere un controllo e un controllo di accesso ai registri.
- Costruire dashboard: privilegi, PII, finanza, comunicati/confighi.
- Abilita playbook: tamper, fuoriuscita PII, guasto ingest, violazione SoD.
- Provare repliche e deducibili sul set di prova.
- Esporta con ricevute e registro delle richieste.
- Eseguire un controllo trimestrale delle metriche di qualità (freshness/completeness/tamper).
17) FAQ
È possibile conservare tutto in un normale database?
Sì, ma i registri critici devono essere duplicati in WORM/append-only con le firme e i tagli Merkle.
È necessario regolare ogni lettura dei dati?
La lettura di PII/finanza è obbligatoria; Il resto è per politica e costo.
Come si prova l'immutabilità?
Hash radice, firme DSE, TSA indipendente e procedure di verifica riproduttive.
Cosa fare con «diritto di eliminazione» (GDPR)?
Rimuovere il primario nei sistemi di elaborazione nei registri di controllo - Memorizza i token/hash senza PII ripristinabile e guida Legale Hold se necessario.
Riepilogo: I registri di verifica non sono «loghi in S3», ma una cronologia crittografica di azioni con regole chiare, memorizzazione invariata, accesso controllato e disponibilità a dispute/controlli regolatori. Costruisci un ingest per contratto, firmi eventi critici, supporti i tagli Merkle e i dashboard, e avrai una base affidabile per la fiducia, la sicurezza e la compliance.