Requisiti di audit logging SOC 2 (CC7.2) e come soddisfarli
In preparazione di un audit SOC 2 Type II, l'auditor verifica se l'attività di sistema sia effettivamente registrata e monitorata, non se sia dichiarato che lo sia. Questa pagina illustra che cosa CC7.2 richiede, quali evidenze gli auditor chiedono, e come i log a catena di hash di AuditRails lo soddisfano.
Il controllo
SOC 2 CC7.2: Rilevamento anomalie e monitoraggio
Trust Services Criteria 2017
«L'entità monitora i componenti del sistema e il funzionamento di tali componenti per rilevare anomalie indicative di atti dolosi, disastri naturali ed errori che compromettono la capacità dell'entità di raggiungere i propri obiettivi; le anomalie vengono analizzate per determinare se rappresentano eventi di sicurezza.»
Nella pratica gli auditor SOC 2 verificano anche i controlli di identità e accesso da cui questo monitoraggio dipende. CC6.1 presuppone la registrazione di login, logout, autenticazioni fallite, concessioni e revoche di accesso, non soltanto delle anomalie segnalate a posteriori.
Cosa chiede un auditor
Un auditor SOC 2 non si limita alla dichiarazione che il monitoraggio esiste. Campiona un intervallo di date e chiede i record effettivi: chi ha effettuato l'accesso, a chi l'accesso è stato concesso o revocato, quale configurazione è stata modificata, e se ogni voce sia dimostrabilmente inalterata. Un registro continuo e inalterabile per l'intero periodo di audit risponde a questa richiesta; un archivio di log generico no.
Requisito di conservazione
AuditRails conserva i log di audit SOC 2 per un minimo di 1 anno per impostazione predefinita: durata sufficiente a coprire un intero periodo di osservazione Type II e la finestra retrospettiva che l'auditor campiona. La conservazione si estende automaticamente se è attivo anche un framework con un requisito più lungo.
Cosa registra AuditRails
Ogni evento di controllo degli accessi che l'auditor campiona per CC6.1 e CC7.2 corrisponde a una singola chiamata di logging: non serve costruire una separata integrazione di audit log.
import { AuditRails } from '@auditrails/node';
const audit = new AuditRails({ apiKey: 'at_live_...' });
await audit.log({
action: 'access.granted',
actor_id: '...', // required
resource: '...', // required
metadata: {
role: '...', // optional
granted_by: '...', // optional
justification: '...', // 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 all'auditor a supporto delle evidenze, non uno screenshot da accettare sulla parola.
Errori comuni su questo controllo
- Registrare che un utente dispone di un accesso, ma non quando quell'accesso sia stato concesso o revocato, né da parte di chi. CC6.1 presuppone la coppia access.granted e access.revoked, non una fotografia dei permessi a una certa data.
- Tentativi di accesso falliti mai registrati, ma soltanto quelli riusciti: è precisamente il modello di anomalia che CC7.2 richiede di monitorare.
- Log conservati in un sistema modificabile o cancellabile da chiunque abbia accesso alla base dati. Alla domanda «come si dimostra che non sia stato alterato» non c'è una risposta accettabile.
- Nessun actor_id stabile tra i sistemi, per cui l'auditor che campiona un evento non può ricostruire l'attività della stessa persona nel resto del registro.
- Conservazione più breve del periodo di audit sommato alla finestra retrospettiva: al momento dell'audit l'evidenza relativa a parte dell'intervallo campionato non esiste più.
Domande frequenti
AuditRails ci mette in regola con SOC 2?
Nessuno strumento da solo lo fa. AuditRails fornisce l'evidenza inalterabile di audit logging richiesta da CC6.1 e CC7.2, tipicamente uno dei controlli più onerosi da costruire da zero. Il resto del perimetro SOC 2 resta separato: policy, altri Trust Services Criteria, l'incarico di audit.
AuditRails stesso è certificato SOC 2?
Non ancora. Ci stiamo preparando a un audit SOC 2 Type II e il processo formale non è stato ancora avviato. La pagina dedicata alla sicurezza riporta lo stato attuale, per intero.
Per quanto tempo vanno conservati i log di audit SOC 2?
Un minimo di 1 anno è il riferimento comunemente atteso dagli auditor, ed è quanto AuditRails conserva per impostazione predefinita per questo framework: sufficiente a coprire un periodo di osservazione Type II e la finestra retrospettiva campionata.
È 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.