AuditRailsAuditRails

Requisiti di audit logging PCI DSS (10.2) e come soddisfarli

Il Requisito 10.2 di PCI DSS v4.0 impone che i log di audit supportino il rilevamento di anomalie e attività sospette relative ai dati dei titolari di carta. Questa pagina illustra che cosa questo significa per l'audit logging, che cosa un QSA chiede come evidenza durante un Report on Compliance, e come i log a catena di hash di AuditRails lo soddisfano.

Il controllo

PCI DSS v4.0 Requisito 10.2: Implementazione dei log di audit

PCI DSS v4.0

«I log di audit sono implementati per supportare il rilevamento di anomalie e attività sospette.»

L'evidenza del Requisito 10.2 viene verificata insieme al 10.3 (contenuto minimo dei log) e al 10.5 (integrità e conservazione) durante un Report on Compliance: il QSA accerta non soltanto che i log esistano, ma che contengano i campi previsti e non siano alterabili a posteriori.

Cosa chiede un auditor

Il QSA che conduce il Report on Compliance campiona direttamente i log dell'ambiente dati dei titolari di carta: devono esistere per gli eventi elencati dal Requisito 10.2, contenere dettaglio sufficiente a istruire un'anomalia, ed essere accompagnati dalla prova che il registro non sia stato modificato. Una policy che dichiari che la registrazione avviene non supera un ROC; un record campionabile e producibile sì.

Requisito di conservazione

AuditRails conserva i log di audit PCI DSS per un minimo di 1 anno per impostazione predefinita, con gli ultimi 3 mesi immediatamente disponibili per l'analisi, come previsto dal Requisito 10.5.1. La conservazione si estende automaticamente se è attivo anche un framework con un requisito più lungo.

Cosa registra AuditRails

Gli eventi di accesso ai dati dei titolari di carta vengono registrati esclusivamente con riferimenti mascherati o troncati, mai con il numero di conto principale: i dati della carta appartengono al CDE, non al registro di audit.

import { AuditRails } from '@auditrails/node';

const audit = new AuditRails({ apiKey: 'at_live_...' });

await audit.log({
  action: 'cardholder.accessed',
  actor_id: '...', // required
  resource: '...', // required
  metadata: {
    purpose: '...', // optional
    masked: '...', // optional
    pan_truncated: '...', // optional
  }
});

Cosa si consegna all'auditor

Il pacchetto di evidenze generato per la finestra di audit è un archivio che contiene un report riassuntivo in PDF, il registro completo degli eventi in NDJSON e un manifest con i checksum SHA-256 di entrambi i file, oltre alla prova della catena di hash. È materiale consegnabile direttamente al QSA, non una dichiarazione di policy da accettare sulla parola.

Errori comuni su questo controllo

  • Registrare l'accesso ai dati dei titolari di carta memorizzando il PAN in chiaro nei metadati del log: così l'archivio dei log rientra nel perimetro PCI invece di restarne fuori, esattamente il contrario di un CDE ben delimitato.
  • Nessuna distinzione tra accesso amministrativo o privilegiato e accesso applicativo ordinario: il Requisito 10.2 presuppone che le azioni privilegiate siano identificabili nel registro, non confuse nel traffico di routine.
  • Log modificabili dagli stessi amministratori che il controllo dovrebbe rendere responsabili. Il requisito di integrità del 10.5 richiede un record di cui il QSA possa accertare l'inalterabilità, non semplicemente un record che esiste.
  • Conservazione inferiore a 1 anno, oppure ultimi 3 mesi non immediatamente disponibili per l'analisi: sono due requisiti espliciti e verificabili che il QSA campiona.
  • Nessun actor_id stabile tra i sistemi che toccano l'ambiente dati dei titolari di carta, il che rende impossibile ricostruire l'attività di un singolo soggetto in tutto il CDE nel corso di un'indagine.

Domande frequenti

AuditRails ci mette in regola con PCI DSS?

Nessuno strumento da solo lo fa. AuditRails fornisce l'evidenza inalterabile di audit logging richiesta dal Requisito 10. Il resto del perimetro PCI DSS resta separato: segmentazione di rete, gestione delle vulnerabilità, controllo degli accessi, il Report on Compliance nel suo complesso.

AuditRails conserva dati dei titolari di carta?

No. I metadati del log devono contenere soltanto riferimenti mascherati o troncati, mai un numero di conto principale in chiaro: il catalogo di azioni di questo framework è costruito esattamente su questo presupposto. Registrare dati di carta in chiaro riporterebbe l'archivio dei log nel perimetro PCI, vanificandone lo scopo.

Per quanto tempo vanno conservati i log di audit PCI DSS?

Il Requisito 10.5.1 prevede almeno dodici mesi di storico, con gli ultimi tre mesi immediatamente disponibili per l'analisi. È esattamente quanto AuditRails conserva per impostazione predefinita per questo framework.

È possibile verificare che i log non siano stati manomessi, indipendentemente da AuditRails?

Sì. Pubblichiamo una CLI open source che ricalcola in modo indipendente la catena di hash a partire da un export. Non richiama la nostra API e non si affida alla nostra infrastruttura.

Questa pagina descrive obblighi normativi a fini informativi e non costituisce consulenza legale. Il perimetro di applicazione alla vostra organizzazione va verificato con i vostri consulenti.