Jak wymusić MFA dla dostępu uprzywilejowanego (SOC 2)?
zespół heygrc
Ograniczenie dostępu do wrażliwych funkcji to sedno SOC 2 CC6.1 (kontrole dostępu logicznego), a w przypadku działań uprzywilejowanych aktywna sesja zwykle nie wystarcza. Wymagaj drugiego czynnika w momencie wykonania działania uprzywilejowanego, odmawiaj dostępu, jeśli go brakuje, i rejestruj sprawdzenie, aby dotarcie do ścieżki administracyjnej wymagało więcej niż skradzionej lub nieaktywnej sesji.
Zdefiniuj uprzywilejowane ścieżki
Określ, które działania uznać za uprzywilejowane: punkty końcowe administracyjne, zmiany ról i uprawnień, masowy dostęp do danych lub ich eksport oraz zmiany ustawień bezpieczeństwa. To ścieżki, na których pojedyncza skompromitowana sesja może spowodować największe szkody, a drugie czynniki autoryzacji uzasadniają tam swoje koszty.
Wymagaj drugiego czynnika przy działaniu, odmawiaj domyślnie
Sprawdź, czy drugi czynnik został zweryfikowany (lub niedawno użyty) przed wykonaniem działania uprzywilejowanego, a nie tylko przy pierwszym logowaniu. Domyślnie odmawiaj dostępu, jeśli go brakuje, zamiast zezwalać. Sprawdzenie powinno odbywać się na serwerowej ścieżce wykonującej działanie, aby nie można było go pominąć, wywołując punkt końcowy bezpośrednio.
export async function setRole(session, target, role) {+ if (!session.mfaVerified) return deny("step-up required") await db.roles.set(target, role) return ok()}Zmiana uprzywilejowanej roli wymaga teraz zweryfikowanego drugiego czynnika i domyślnie odmawia dostępu bez niego, wzmacniając kontrole dostępu logicznego, o których mowa w CC6.1.
Powiązane