Registri di revisione e tracce di accesso
1) Assegnazione e ambito di applicazione
Obiettivo: garantire che gli utenti/servizi siano provati, trasparenza investigativa, conformità ai regolatori e agli standard interni (GDPR/AML, contratti con i fornitori PSP/KYC, ISO/PCI se applicabili).
Copertura: tutti i sistemi prod, servizi di piattaforma (account, pagamenti, antifrode, CUS/sanzioni, RG), dashboard, API gateway, DWH/BI, infrastruttura (K8s/cloud), integrazione con i vendor.
2) Cosa logica (classi di eventi)
1. Identificazione e accesso: login/logout, MFA, cambio password/chiavi, accesso SSO, «break-glass».
2. Azioni amministrative: modifiche a ruoli/diritti, configurazioni, regole antifrode/sanzioni, flag fich.
3. Operazioni PII/find: lettura/esportazione/rimozione, caricamento, accesso a KYC, visualizzazione dei profili VIP.
4. Transazioni e denaro: cache/depositi, cancellazioni, rimborsi, soluzioni di charjbeek.
5. Compilazione/AML/KYC: risultati di screening (sanzioni/PEP/Adverse Media), soluzioni (TP/FP), EDD/STRR/SAR.
6. Incidenti e sicurezza: escalation, modifiche alle regole WAF/IDS, isolamento dei servizi, rotazione dei segreti.
7. Integrazioni/venditori: chiamate API, errori, timeout, esporti, conferma rimozione/restituzione dati.
3) Campi evento obbligatori (minimo)
`event_id` (UUID), `ts_utc`, `ts_local`, `source_service`, `trace_id`/`span_id`
«attore _ tipo» (user/service/vendor), «attore _ id», «attore _ org» (se B2B)
`subject_type` (account/tx/document/dataset), `subject_id`
`action` (e. g., `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `WITHDRAWAL_APPROVE`)
`result` (success/deny/error) и `reason`/`error_code`
«ip», «device _ fingerprint», «geo» (paese/regione), «auth _ text» (MFA/SSO)
«fields _ accessed »/« scope» (quando si lavora con PII/find) - mascherato
«purpose »/« ticket _ id» (base: DSAR, incidente, richiesta di controllo, attività operativa)
4) Immutabile e dimostrabile
Archivio WORM per «oro» (immutabile buckets/retence policies).
Cryptode/catena hash: firma periodica di pacchetti di eventi e/o creazione di una catena di hash (hash chaining) per identificare le modifiche.
Registro delle modifiche a diagrammi/regole: versioniamo gli schemi e i criteri di loging. Tutte le modifiche vengono effettuate con il CAV.
Archiviazione a due contorni: indice online (ricerca) + archivio/immutabilità.
5) Sincronizzazione del tempo e traccia
Un unico NTP/Chrony in tutti gli ambienti «ts _ utc» come fonte di verità.
Ogni login è «trace _ id »/« span _ id» per tracciare tutte le richieste (correlazione tra servizi, vendor e fronte).
6) Privacy e segreti
Le password, i token completi PAN/CSC, i numeri completi dei documenti, la biometria cruda.
Maschera predefinita: e-mail/telefono/BAN/PAN → token/visualizzazione parziale.
Alias: 'user _ id', token stabile nell'analisi; il riferimento all'ID reale è solo in un tracciato protetto.
Compatibilità DSAR: possibilità di estrarre i fogli per soggetto in modo selettivo senza rivelare i PII estranei.
7) Tempi di conservazione e livelli (retensioni)
8) Accesso e controllo (RBAC/ABAC)
I ruoli di lettura dei logi di revisione sono separati dai ruoli di amministrazione.
Accesso MFA e Just-in-Time (break-glass) automatizzato/logico delle cause.
Criterio minimo: accesso ai campi PII/Find solo se necessario e con fissaggio purpose.
Esportazione/caricamento: elenchi bianchi di destinatari e formati; firma obbligatoria/hash, registro di carico.
9) Integrazione con SIEM/SOAR/ETL
Il flusso degli eventi di auditing viene inviato a SIEM per le correlazioni (e. g., di massa «READ _ PII» + accesso dal nuovo dispositivo).
Playbook SOAR: tessuti automatici in caso di violazione di regole (nessun «purpose», volume anomalo, accesso fuori dalla finestra).
ETL/DWH - Vetrine «audit _ access», «pii _ exports», «emmin _ changes» con controllo della qualità e della versionabilità degli schemi.
10) Qualità dei dati e validatori
Schemi come codice (JSON/Protobuf/Avro): campi obbligatori, tipi, dizionari; Validatori CI.
Scollatura e quarantine-code per gli eventi con errori di schema; Le metriche del matrimonio.
Deduplicazione/idampotenza per '(event _ id, trace _ id, ts)'; Controllo dell'invio di nuovo.
11) RACI
12) SOP: indagine sull'accesso ai dati
1. Trigger: alert SIEM (anomale'READ _ PII '/esportazione), reclamo, segnale da un venditore.
2. Raccolta di artefatti: caricamento di eventi per «attore _ id »/« subject _ id »/« trace _ id», registro «purpose», loghi associati (WAF/IdP).
3. Controllo di legittimità: presenza di basi (DSAR/incidente/servizio), concordanza, finestre di accesso.
4. Valutazione dell'impatto: quantità/categorie di PII, giurisdizione, rischio per i soggetti.
5. Soluzione: incidente bridge (High/Critical), containment (recensione, rotazione delle chiavi).
6. Report e CAPE: cause, regole violate, misure (mascheramento, apprendimento, modifiche RBAC), tempi.
13) SOP: Esporta dati (regolatore/partner/DSAR)
1. La richiesta di verifica di base e identità (DSAR) consente di generare una query in DWH.
2. Impersonalizzazione/minimizzazione predefinita; includere il PII solo per motivi legali.
3. Generazione di caricamento (CSV/JSON/Parket) la firma/hash nel registro di carico (chi/quando/cosa/a/base).
4. Trasmissione tramite il canale approvato (sFTP/Secure link); Data di conservazione della copia per criteri.
5. Post-controllo: conferma ricevimento, eliminazione dei file temporanei.
14) Metriche e KRIS/KPIS
Coverage: la percentuale di sistemi critici che inviano eventi di verifica è del 95%.
Errori DQ: gli eventi respinti dal validatore sono 0. Il 5% del flusso.
MTTD perdita flusso: ≤ 15 min (alert in silenzio).
Disponibilità anomale senza «purpose»: = 0 (KRI).
Il tempo di risposta all'indagine è di 4 ore, P95, 24 ore.
Esportazioni firmate/hash al 100%.
Rimozione/archiviazione entro la data di scadenza del 99%.
15) Requisiti per venditori e sottoprocessori
DPA/SLA - Descrizione dei loghi di controllo (schemi, scadenze, geografia, formato di esportazione), WORM/immutabilità, SLA notifiche di incidenti.
Accesso al venditore: account di servizio denominati, registri delle loro azioni, controllo selettivo.
Off-board: ritiro delle chiavi, esportazione/rimozione dei registri, atto di chiusura, conferma di cancellazione dei backup.
16) Sicurezza e protezione contro la manipolazione
Separazione dei ruoli: admine di origine admine di
Firma agenti/raccoglitori, mTLS tra i componenti.
Controllo anti-tamper: confronto hash, controlli regolari di integrità, alert su discrepanze.
Geo-replica delle copie WORM e test di ripristino regolari.
17) Errori tipici e anti-pattern
La logica dei valori sensibili (PAN/segreti) consente di attivare immediatamente la redaction-middleware.
Nessun «purpose »/« ticket _ id» durante l'accesso al PII.
Caricamento locale sul desktop e invio via e-mail.
L'assenza di un unico schema e la validazione → i campi «muti», l'impossibilità di correlazione.
Un unico super account senza collegamento con una persona o un servizio.
18) Assegno fogli
18. 1 Avvia/ruota criteri
- Schemi e dizionari approvati; campi obbligatori inclusi
- Maschera e proibizioni dei segreti abilitate
- NTP configurato, 'trace _ id' ovunque
- Livelli Hot/Warm/Cold/WORM creati
- RBAC/ABAC e break-glass sono decorati
- SIEM/SOAR integrati, gli alert testati
18. 2 Controllo mensile
- Campione di esportazioni: le firme/i registri sono corretti
- Controllo retensico/rimozione/Legale Hold
- Le metriche DQ sono normali, quarantine analisi
- Logni venditori disponibili/pieni
19) Road map di implementazione
Settimane 1-2: inventario dei sistemi, allineamento degli schemi e dei campi obbligatori, impostazione del tempo e del tracciato.
Settimane 3-4: abilitazione del masking, livello WORM, integrazione con SIEM/SOAR, avvio dei registri di esportazione.
Mese 2: automazione dei validi/alert, playbook investigativo, formazione dei comandi.
Mese 3 +: verifiche regolari, stress test integrità, ottimizzazione dei costi (tering), revisione dei vendor/contratti.
TL; DR
Registri di revisione forti = eventi completi e strutturati + immutabilità (WORM) e firme + maschera PII + accesso rigido e registro di carico + integrazione con SIEM/SOAR. Questo accelera le indagini, riduce i rischi e rende la compliance dimostrabile.