Requisiti di audit logging ISO 27001 (A.8.15) e come soddisfarli

Il controllo

A.8.15 viene verificato di norma insieme ad A.8.16 (attività di monitoraggio) e A.5.28 (raccolta di evidenze): l'organismo di certificazione non si limita a constatare che i log esistano, ma verifica che qualcuno li esamini e che reggerebbero come evidenza in caso di necessità.

Cosa chiede un auditor

Un auditor di certificazione ISO 27001 campiona direttamente il controllo di logging: i log esistono per gli eventi che la valutazione del rischio considera rilevanti, sono protetti da modifiche, e sono producibili come evidenza su richiesta. Dichiarare genericamente di registrare gli eventi, senza un record protetto e producibile, non supera un audit di Stage 2.

Requisito di conservazione

AuditRails conserva i log di audit ISO 27001 per un minimo di 3 anni per impostazione predefinita. La norma non fissa una durata: il riferimento è la finestra da cui gli organismi di certificazione campionano negli audit di sorveglianza. La conservazione si estende automaticamente se è attivo anche un framework con un requisito più lungo.

Cosa registra AuditRails

Gli eventi di controllo degli accessi registrano il contesto di privilegio e la giustificazione impliciti nel requisito di A.8.15 che i log siano «protetti e analizzati», non un semplice record di concessione e revoca.

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
    privileged: '...', // 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: esattamente il tipo di evidenza producibile e protetta che un audit di Stage 2 o di sorveglianza richiede.

Errori comuni su questo controllo

• Log che esistono ma non vengono mai esaminati né analizzati. A.8.15 dice espressamente «analizzati», e alla domanda su chi li esamini deve corrispondere una risposta documentata.
• Nessuna protezione contro la modifica dei log da parte degli stessi amministratori che la registrazione dovrebbe rendere responsabili. Il requisito che i log siano «protetti» presuppone separazione, non semplice esistenza.
• Registrare le modifiche all'infrastruttura ma non gli eventi di accesso, omettendo proprio il dato (chi ha avuto accesso a che cosa e quando) da cui dipende la maggior parte dei controlli dell'Allegato A.
• Conservazione inferiore a 3 anni, che non copre la finestra di disponibilità dei log da cui la maggior parte degli organismi di certificazione campiona negli audit di sorveglianza.
• Nessun actor_id stabile né precisione temporale omogenea tra i sistemi, il che rende impossibile correlare un evento tra le diverse fonti di logging comprese nel perimetro del SGSI.

Domande frequenti

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.