heygrc
Odpowiedź

Jak dodać rejestrowanie zdarzeń audytowych w odpowiedni sposób dla SOC 2 i ISO 27001?

zespół heygrc

Rejestruj istotne zdarzenia związane z bezpieczeństwem (kto, co i kiedy zrobił), zawsze uwzględniaj aktora, zapisuj je w trwałym miejscu i nie pozwól, aby późniejsze czyszczenie je usunęło. Zarówno SOC 2 (CC7.2), jak i ISO 27001 (A.8.15) oczekują tego i sprawdzają to poprzez próbkowanie zarejestrowanych zdarzeń.

  1. Rejestruj istotne zdarzenia z uwzględnieniem aktora

    Rejestruj działania istotne dla bezpieczeństwa: uwierzytelnianie, zmiany uprawnień i ról, dostęp do wrażliwych danych, zmiany konfiguracji. Każdy rekord musi zawierać wystarczająco informacji, aby odpowiedzieć na pytania: kto to zrobił, do czego i kiedy, dlatego zawsze przechwyć aktora, a nie tylko działanie.

  2. Zapisz dziennik w miejscu, które przetrwa

    Zapisuj w trwałym, odpornym na modyfikacje magazynie, nie tylko do stdout, który może zostać nadpisany, i powiąż zapis z zmianą, którą rejestruje (w tej samej transakcji lub za pomocą outbox), aby zdarzenie nie zostało cicho utracone, jeśli wywołanie logowania się nie powiedzie. Dziennik jest dowodem, że kontrola działała; jeśli zniknie, zniknie też dowód, który audytor próbkuje, oraz ślad potrzebny po incydencie.

  3. Chron dziennik przed czyszczeniem

    Najczęstszym powodem awarii rejestrowania zdarzeń audytowych jest późniejsze pull request usuwające linię dziennika, która wydaje się szumem. Jeśli dziennik jest hałaśliwy, zmień jego poziom lub miejsce docelowe, ale nie usuwaj go. To dokładnie taki rodzaj zmiany, który powinien zostać złapany podczas przeglądu w oparciu o A.8.15.

access/roles.ts+1 -0
async function updateRole(actor, target, role) {  await db.roles.set(target, role)+  await audit.log("role.update", { actor, target, role })  return ok()}
heygrcISO 27001 A.8.15 / SOC 2 CC7.2

Dodana linia rejestruje, kto zmienił rolę komu. To jest zdarzenie, które audytor próbkuje, i to, którego potrzebujesz po incydencie.