Hoe voeg ik audit logging op de juiste manier toe voor SOC 2 en ISO 27001?
het heygrc team
Log de beveiligingsrelevante gebeurtenissen (wie heeft wat gedaan en wanneer), voeg altijd de actor toe, schrijf ze ergens duurzaam op en laat een latere opschoning ze niet verwijderen. SOC 2 (CC7.2) en ISO 27001 (A.8.15) verwachten dit allebei en controleren het door steekproeven te nemen van de gebeurtenissen die je daadwerkelijk hebt geregistreerd.
Log de relevante gebeurtenissen, met de actor
Registreer de beveiligingsrelevante acties: authenticatie, wijzigingen in rechten en rollen, toegang tot gevoelige gegevens, configuratiewijzigingen. Elke registratie moet voldoende informatie bevatten om te beantwoorden wie dit heeft gedaan, op wat en wanneer, dus captureer altijd de actor, niet alleen de actie.
Plaats de log op een plek waar deze blijft bestaan
Schrijf naar een duurzame, manipulatiebestendige opslag, niet alleen naar stdout die wordt overschreven, en koppel de schrijfactie aan de wijziging die wordt geregistreerd (in dezelfde transactie of een outbox), zodat de gebeurtenis niet stilletjes verloren gaat als de logaanroep mislukt. De log is het bewijs dat de controle heeft gewerkt; als deze verdwijnt, verdwijnt ook het bewijs dat een auditor steekproefsgewijs controleert en het spoor dat je nodig hebt na een incident.
Bescherm het tegen opschoning
De meest voorkomende manier waarop audit logging faalt, is een latere pull request die een logregel verwijdert die als ruis wordt gezien. Als een log te veel ruis maakt, verander dan het niveau of de bestemming, maar verwijder deze niet. Dit is precies het soort wijziging dat een review tegen A.8.15 moet opvangen.
async function updateRole(actor, target, role) { await db.roles.set(target, role)+ await audit.log("role.update", { actor, target, role }) return ok()}De toegevoegde regel registreert wie de rol van wie heeft gewijzigd. Dit is de gebeurtenis die een auditor steekproefsgewijs controleert en die je nodig hebt na een incident.