Come aggiungere il logging di audit nel modo corretto per SOC 2 e ISO 27001?
il team heygrc
Registra gli eventi rilevanti per la sicurezza (chi ha fatto cosa e quando), includi sempre l'attore, scrivili in un luogo durevole e non permettere che una pulizia successiva li elimini. SOC 2 (CC7.2) e ISO 27001 (A.8.15) si aspettano entrambi questo e lo verificano campionando gli eventi effettivamente registrati.
Registra gli eventi che contano, con l'attore
Registra le azioni rilevanti per la sicurezza: autenticazione, modifiche dei privilegi e dei ruoli, accesso a dati sensibili, modifiche della configurazione. Ogni record deve contenere abbastanza informazioni per rispondere a chi ha eseguito l'azione, su cosa e quando, quindi cattura sempre l'attore, non solo l'azione.
Salva il log in un luogo che sopravviva
Scrivi in un archivio durevole e resistente alle manipolazioni, non solo su stdout che viene ruotato e perso, e lega la scrittura alla modifica che registra (nella stessa transazione o in un outbox) in modo che l'evento non venga perso silenziosamente se la chiamata di log fallisce. Il log è la prova che il controllo ha funzionato; se scompare, scompare anche la prova che un revisore campiona e la traccia di cui hai bisogno dopo un incidente.
Proteggilo dalla pulizia
Il modo più comune in cui il logging di audit fallisce è una pull request successiva che elimina una riga di log considerata rumore. Se un log è rumoroso, cambia il suo livello o la sua destinazione, non rimuoverlo. Questo è esattamente il tipo di modifica che una revisione contro A.8.15 dovrebbe rilevare.
async function updateRole(actor, target, role) { await db.roles.set(target, role)+ await audit.log("role.update", { actor, target, role }) return ok()}La riga aggiunta registra chi ha modificato il ruolo di chi. Questo è l'evento che un revisore campiona e quello di cui hai bisogno dopo un incidente.