Comment ajouter correctement la journalisation d'audit pour SOC 2 et ISO 27001 ?
l'équipe heygrc
Journalisez les événements liés à la sécurité (qui a fait quoi et quand), incluez toujours l'acteur, écrivez-les dans un stockage durable et empêchez une suppression ultérieure de les effacer. SOC 2 (CC7.2) et ISO 27001 (A.8.15) exigent tous deux cela et vérifient par échantillonnage des événements effectivement enregistrés.
Journalisez les événements pertinents, avec l'acteur
Enregistrez les actions liées à la sécurité : authentification, modifications de privilèges et de rôles, accès aux données sensibles, changements de configuration. Chaque enregistrement doit permettre de répondre à qui a fait cela, sur quoi et quand, donc capturez toujours l'acteur, pas seulement l'action.
Stockez le journal dans un endroit durable
Écrivez dans un stockage durable et résistant aux altérations, pas seulement dans stdout qui est supprimé par rotation, et liez l'écriture au changement qu'elle enregistre (la même transaction ou une file d'attente) pour que l'événement ne soit pas perdu silencieusement si l'appel de journalisation échoue. Le journal est la preuve que le contrôle a fonctionné ; s'il disparaît, la preuve que l'auditeur échantillonne et la trace nécessaire après un incident disparaissent aussi.
Protégez-le contre le nettoyage
La manière la plus courante pour que la journalisation d'audit échoue est qu'une pull request ultérieure supprime une ligne de journal considérée comme du bruit. Si un journal est bruyant, modifiez son niveau ou sa destination, ne le supprimez pas. C'est exactement le type de changement qu'une revue contre A.8.15 doit détecter.
async function updateRole(actor, target, role) { await db.roles.set(target, role)+ await audit.log("role.update", { actor, target, role }) return ok()}La ligne ajoutée enregistre qui a modifié le rôle de qui. C'est l'événement qu'un auditeur échantillonne et celui dont vous avez besoin après un incident.