Gotowość dostępów do SOC 2: przygotowanie CC6 pod Type II

co testuje cc6, po ludzku

Kryteria dostępu logicznego przekładają się wprost na pracę nad identity i dostępem. Trzy, które ważą najwięcej, to CC6.1, CC6.2 i CC6.3.

CC6.1 brzmi: wdrożyć oprogramowanie, infrastrukturę i architektury zabezpieczające dostęp logiczny do chronionych zasobów informacyjnych. W praktyce audytor patrzy, jak zarządzana jest tożsamość, czy wymuszane jest uwierzytelnianie wieloskładnikowe, jak kontrolowane są granice i punkty wejścia sieci oraz jak chronione są poświadczenia.

CC6.2 brzmi: rejestrować i autoryzować użytkowników przed nadaniem dostępu do systemu oraz modyfikować lub usuwać poświadczenia, gdy dostęp przestaje być autoryzowany. To cykl joiner-mover-leaver w języku audytu, i to tu próbkowanie Type II gryzie najmocniej, bo audytor weryfikuje, że dostęp faktycznie odwołano przy zakończeniu zatrudnienia albo zmianie roli.

CC6.3 brzmi: autoryzować, modyfikować lub usuwać dostęp do danych, oprogramowania, funkcji i innych chronionych zasobów na podstawie ról, odpowiedzialności lub projektu systemu. To tu testowane są dostęp oparty na rolach, least privilege, okresowe udokumentowane przeglądy dostępów i rozdział obowiązków. Jeden nieudany offboarding narusza jednocześnie wymóg deprowizjonowania z CC6.2 i podważa zapewnienie least privilege z CC6.3, więc jedno nieaktualne konto może stać się dwoma ustaleniami.

Reszta CC6 obejmuje ochronę granic, ograniczanie przepływu danych i ochronę przed złośliwym oprogramowaniem, wszystko istotne, ale wyjątki dostępu, które prowadzą do zastrzeżeń w raporcie, niemal zawsze biorą się z pierwszych trzech. Pod spodem tego wszystkiego leży założenie, na którym audytor się opiera, nie wypowiadając go wprost: że masz kompletny, aktualny obraz tego, kto ma dostęp do czego. Jeśli ten obraz jest niekompletny, każda kontrola nad nim jest próbkowana względem złego baseline.

gdzie chowają się wyjątki

Wyjątki dostępu w SOC 2 rzadko mają charakter architektoniczny. Kontrola była zaprojektowana dobrze. Coś się wyślizgnęło gdzieś w trakcie okresu. Typowe źródła, mniej więcej w kolejności, w jakiej się pojawiają: osoba odchodząca zachowała dostęp do narzędzia SaaS, bo offboarding obejmował tylko główny katalog, a aplikacja miała bezpośrednie logowanie poza single sign-on; kontraktor zatrudniony w trakcie okresu dostał dostęp i nigdy nie przeszedł przez przegląd, więc nie ma zapisu pokazującego, że dostęp był zasadny; rola admina została dodana podczas incydentu i nigdy nie usunięta, a audytor znajduje stałe uprawnienia, których nikt nie potrafi uzasadnić; MFA miało wyjątek, którego nikt nie sprawdził ponownie, przy koncie serwisowym, przestarzałym logowaniu albo adminie sprzed wdrożenia polityki; a przegląd dostępów się odbył, ale nie został udokumentowany, bez zapisu, kto co przejrzał, kiedy i co się zmieniło. Wzorzec jest ten sam, który ujawnia każdy framework: luka żyje poza systemami, które IT obserwuje najuważniej, w SaaS i tożsamościach maszynowych, których katalog w pełni nie widzi.

sekwencja przygotowań

Ta praca należy do etapu przed otwarciem okresu obserwacji, nie w jego trakcie, a każdy element zamyka jedną klasę wyjątku. To, co działa, to zbudowanie najpierw kompletnego obrazu dostępu: wypisanie każdego systemu, który przechowuje dane klienta albo wspiera produkt, i każdej tożsamości, która może do niego dotrzeć, ludzkiej i maszynowej, bo nie udokumentujesz dostępu, którego nie widzisz. Napraw pokrycie uwierzytelniania, potwierdzając, że MFA jest wymuszone wszędzie, gdzie powinno, łącznie z kontami admina, kontami serwisowymi tam, gdzie to wspierane, i każdym logowaniem, które omija single sign-on, i udokumentuj wyjątki, których nie da się zamknąć, kontrolą kompensującą i powodem. Zamknij stałe uprawnienia, znajdując dostęp admina i podwyższony, który jest stały, a nie potrzebny, i usuwając go albo ograniczając w czasie, bo stały dostęp admina, z którego nikt nie korzysta, to najczystsze ustalenie, jakie może opisać audytor. Zrób tak, żeby joiner-mover-leaver było udokumentowane: żeby wnioski o dostęp przechodziły przez zatwierdzenie z zapisem, zmiany roli wyzwalały przegląd, a offboarding zamykał każdy system, nie tylko katalog, ze zgłoszeniem albo logiem, który to potwierdza. Przeprowadź realny przegląd dostępów i zachowaj zapis, mając właścicieli zasobów potwierdzających, kto powinien mieć dostęp do czego, zapisując ich decyzje i działając na podstawie usunięć. I ustaw cykliczność tak, żeby przetrwała okres, z lekkim comiesięcznym sprawdzeniem, które nie pozwala dostępowi znów zsunąć się w wyjątki, bo Type II testuje cały okres, a to, co naprawione teraz, musi zostać naprawione na stałe.

dowody, o które poprosi audytor

Każda kontrola mapuje się na artefakt, który ją potwierdza. Zestaw wart trzymania w gotowości, aktualny i kompletny: inwentarz tożsamości i lista dostępów dla każdego systemu w zakresie; konfiguracja MFA pokazująca wymuszanie i udokumentowane wyjątki; zapisy wniosków o dostęp i zatwierdzeń dla próbki nadań; zapisy zakończenia zatrudnienia pokazujące usunięcie dostępu we wszystkich systemach dla próbki osób odchodzących; zapisy przeglądów dostępów pokazujące, kto przeglądał, kiedy i co się zmieniło; oraz lista dostępów uprzywilejowanych pokazująca, kto ma admina i dlaczego. Jeśli potrafisz je przedstawić na żądanie, próbkowanie CC6 się broni. Jeśli musisz je składać z pamięci tydzień wcześniej, właśnie tam rodzą się wyjątki.