Di quali log di accesso e prove di audit hai bisogno per la certificazione ISO 27001, e come si integrano con il SIEM

Per la certificazione ISO/IEC 27001 non serve "avere i log": serve poter dimostrare, per ciascun controllo dell'Annex A che riguarda gli accessi, quale evento ne costituisce l'evidenza, con quali campi, per quanto tempo è conservato e chi non può modificarlo. Il nucleo minimo è composto da autenticazioni riuscite e fallite, eventi del secondo fattore, ciclo di vita delle sessioni, modifiche ai diritti di accesso e azioni amministrative — ciascuno con attore, oggetto, orario in UTC, origine, esito e contesto di tenant e progetto.

Passo 1 — Dai controlli agli eventi

I controlli dell'Annex A della revisione 2022 non elencano eventi di log: descrivono obiettivi. Il lavoro consiste nel tradurre ogni obiettivo nell'evidenza che lo dimostra, e questa tabella è il documento che conviene portare in audit.

Passo 2 — I campi che ogni record deve avere

Un log privo di uno di questi campi non è inutile, ma non è correlabile: e la correlazione è ciò che distingue un archivio da un controllo.

{
  "id": "evt_7c1e2f",
  "type": "subject.authentication_failed",
  "createdAt": "2026-09-10T09:24:00Z",
  "tenant": "https://tenant.example.com",
  "data": {
    "subjectId": "sub_9f2a7c",
    "project": "prj_12ab",
    "outcome": "failed",
    "reason": "invalid_second_factor",
    "sourceIp": "203.0.113.42",
    "sessionId": "ses_1a9c4d"
  }
}

Il soggetto è un riferimento opaco, non un nome: l'associazione con la persona vive nel tenant del cliente. È una proprietà utile anche per il SIEM, perché consente di correlare senza replicare dati personali in un secondo sistema.

Passo 3 — La conservazione, senza leggende

Una precisazione che fa risparmiare discussioni: ISO 27001 non impone una durata di conservazione dei log. Impone che la durata sia definita in base ai requisiti di business, legali e contrattuali, che sia documentata e che i log siano protetti per tutto quel periodo. Le durate che circolano come obbligatorie derivano da altri quadri normativi o da prassi settoriali.

La colonna centrale sono valori di riferimento, non prescrizioni: il punto è che la tua organizzazione ne scelga di propri, li motivi e li rispetti. Un auditor accetta 6 mesi motivati; non accetta 24 mesi dichiarati e 30 giorni effettivi.

Passo 4 — Integrità: il controllo che si dimentica

Il controllo 8.15 chiede che i log siano protetti da manomissione e accesso non autorizzato. Tradotto in requisiti verificabili:

• Scrittura in sola aggiunta: nessun percorso applicativo modifica o cancella un evento già registrato.
• Separazione dei ruoli: chi amministra il sistema non amministra l'archivio dei log.
• Inoltro immediato verso un sistema terzo, così che una compromissione della sorgente non cancelli la storia.
• Sincronizzazione oraria via NTP, altrimenti la ricostruzione temporale di un incidente non regge.
• Tracciamento degli accessi ai log stessi: anche consultarli è un evento.

L'inoltro verso un sistema terzo è il requisito più efficace e il più spesso trascurato: se i log restano solo nel sistema che li produce, chi ottiene il controllo di quel sistema controlla anche le prove.

Un caso particolare: le azioni che il sistema non consente

In architetture in cui certe operazioni non esistono — in LoginMaster nessun amministratore può resettare la password o disattivare il secondo fattore di un utente — il controllo corrispondente si dimostra in modo diverso e più forte: non con il log dell'azione autorizzata, ma con l'assenza della funzione nel sistema. All'auditor si porta la descrizione architetturale, e la domanda "chi ha resettato questa credenziale?" non ha bisogno di una risposta perché non ha casi possibili. Il dettaglio è su i fornitori dove nemmeno il vendor legge le password.

Passo 5 — Portare gli eventi nel SIEM

LoginMaster registra tutte le categorie di eventi rilevanti per la sicurezza — autenticazione, verifica del secondo fattore, sessioni, amministrazione, sicurezza — e le rende disponibili alle applicazioni tramite webhook firmati HMAC-SHA256 e REST API. Il connettore nativo verso i SIEM enterprise, con Syslog CEF su TLS e selezione delle categorie da inviare, è sul roadmap: lo stato aggiornato è sulla pagina integrazione SIEM. Nel frattempo l'inoltro si realizza consumando i webhook e inoltrando gli eventi al collector, che è comunque il pattern usato dalla maggior parte delle integrazioni personalizzate.

POST /v1/projects/prj_12ab/webhooks HTTP/1.1
Host: api.loginmaster.it
Authorization: Bearer ak_live_••••••••
Content-Type: application/json

{
  "url": "https://collector.example.com/hooks/loginmaster",
  "events": [
    "subject.authenticated",
    "subject.role_changed",
    "subject.deactivated"
  ]
}

La normalizzazione dei campi è il passo che rende gli eventi utilizzabili insieme alle altre sorgenti. La mappatura minima verso gli schemi più diffusi:

Passo 6 — Le regole di correlazione da attivare

Il controllo 8.16 riguarda il monitoraggio, non l'archiviazione: un SIEM che riceve eventi e non li correla soddisfa il logging, non il monitoraggio. Queste sono le regole che coprono gli scenari di accesso più rilevanti e che un auditor si aspetta di trovare attive.

Ogni regola va provata con un test controllato e il risultato va archiviato: la prova che la regola funziona è più convincente della regola stessa.

Il giorno dell'audit: cosa viene chiesto

1. 1«Mostrami tutti gli accessi di questo utente negli ultimi 90 giorni.» Deve essere una query, non un'estrazione manuale.
2. 2«Chi ha assegnato questo ruolo amministrativo, e quando?» Serve l'attore, non solo la modifica.
3. 3«Come dimostri che nessuno ha alterato questi log?» Sola aggiunta, separazione dei ruoli, inoltro esterno.
4. 4«Fammi vedere l'ultima revisione periodica dei diritti di accesso.» Il report di riconciliazione datato.
5. 5«Cosa succede quando qualcuno tenta un attacco a forza bruta?» Regola attiva, allarme generato, esito del test.
6. 6«Per quanto conservate questi eventi e dove è scritto?» La policy, e la verifica che sia rispettata.
7. 7«Chi può resettare le credenziali di un utente?» Se la risposta è 'nessuno, la funzione non esiste', l'intera famiglia di domande successive decade.

Il report di riconciliazione citato al punto quattro si produce automatizzando il ciclo di vita: la procedura è in Provisioning e ciclo di vita degli utenti via REST API e SDK. Il quadro di conformità complessivo, incluse NIS2 e GDPR, è su conformità.

Confronto fra approcci alla raccolta

Chi ha scritto questa guida

LoginMaster è la piattaforma IAM di CDBKR S.r.l., società italiana che progetta e gestisce infrastruttura di autenticazione per software house, MSP e organizzazioni enterprise europee, con attenzione specifica ai requisiti europei di conformità. Le categorie di eventi citate sono quelle pubblicate su integrazione SIEM, e il quadro normativo completo è su conformità. Per discutere un percorso di certificazione: contatti.