Jak przejść audyt SOC 2 CC6 — mechanizmy kontrolne dostępu uprzywilejowanego. Praktyczny przewodnik

Gotowość do SOC 2 Type II to maraton. Większość organizacji przechodzi przez dokumentację polityk, kwestionariusze ryzyka dostawców i diagramy segmentacji sieci bez większych problemów. Potem trafiają na CC6 — Logiczne i Fizyczne Mechanizmy Kontroli Dostępu — i audyt staje się trudny.

CC6 to miejsce, w którym audytorzy spędzają najwięcej czasu i gdzie firmy najczęściej otrzymują wyjątki. Obejmuje kto ma dostęp do Twoich systemów, jak ten dostęp jest kontrolowany, jak jest monitorowany i jak jest przeglądany. Jeśli Twoja odpowiedź w zakresie zarządzania dostępem uprzywilejowanym brzmi „używamy VPN plus RDP ze współdzielonymi poświadczeniami administratora", nie przejdziesz audytu.

Oto dokładnie to, czego wymaga CC6, o co pytają audytorzy i jak dostarczyć dowody.

CC6.1, CC6.2, CC6.3, CC6.6 — co każdy wymaga prostym językiem

CC6.1 — Bezpieczeństwo logicznego dostępu

Wymaganie: logiczny dostęp do Twoich systemów, infrastruktury i danych jest ograniczony do autoryzowanych użytkowników.

W praktyce oznacza to:

• Każdy użytkownik mający dostęp do systemu produkcyjnego ma udokumentowany powód tego dostępu
• Dostęp jest przydzielany przez zdefiniowany proces (nie ad hoc)
• Dostęp jest usuwany niezwłocznie, gdy użytkownik odchodzi lub zmienia rolę
• Dostęp uprzywilejowany (admin, root, DBA) jest śledzony oddzielnie i podlega wyższym standardom

Dowody, których chcą audytorzy: kompletny inwentarz kto ma dostęp uprzywilejowany do czego, jak został przydzielony i kiedy był ostatnio przeglądany.

CC6.2 — Identyfikacja i uwierzytelnianie

Wymaganie: użytkownicy są uwierzytelniani przed dostępem do systemów, a uwierzytelnianie jest wystarczająco silne dla wrażliwości zasobu.

W praktyce oznacza to:

• MFA jest wymagane na wszystkich kontach z dostępem uprzywilejowanym
• Hasła spełniają wymagania złożoności i rotacji
• Współdzielone konta (współdzielony Administrator, współdzielony root) są wyeliminowane lub ściśle kontrolowane
• Konta usługowe są zinwentaryzowane i dostęp jest przeglądany

Dowody, których chcą audytorzy: zrzuty ekranu rejestracji MFA, eksporty inwentarza kont, dowody wyeliminowania współdzielonych kont administratora lub istnienia wyrównawczych mechanizmów kontrolnych.

CC6.3 — Usuwanie dostępu

Wymaganie: dostęp jest usuwany, gdy nie jest już potrzebny (zakończenie zatrudnienia, zmiana roli, koniec projektu).

W praktyce oznacza to:

• Masz udokumentowany proces offboardingu, który obejmuje cofnięcie dostępu uprzywilejowanego
• Cofnięcie dostępu następuje w zdefiniowanych ramach czasowych (24–48 godzin dla dostępu produkcyjnego)
• Możesz wykazać, że zakończeni użytkownicy nie mają już aktywnych sesji ani poświadczeń

Dowody, których chcą audytorzy: zgłoszenia offboardingu pokazujące kroki cofnięcia dostępu, zrzuty ekranu praw dostępu przed i po.

CC6.6 — Ograniczenia logicznego dostępu

Wymaganie: transmisja danych jest szyfrowana, a ograniczenia logicznego dostępu są wdrożone, aby zapobiec nieautoryzowanemu dostępowi.

W praktyce oznacza to:

• Wszystkie połączenia administracyjne są szyfrowane w tranzycie
• Dostęp do wrażliwych systemów jest ograniczony do autoryzowanych punktów końcowych lub sieci
• Aktywność sesji jest monitorowana i rejestrowana

Dowody, których chcą audytorzy: diagramy sieci pokazujące szyfrowane kanały, dzienniki sesji pokazujące aktywność administracyjną.

O co faktycznie pytają audytorzy

Gdy audytor SOC 2 bada CC6, zwykle żąda następujących dowodów:

Dla CC6.1 (inwentarz dostępów):

• Arkusz kalkulacyjny lub eksport systemu pokazujący wszystkich użytkowników z dostępem uprzywilejowanym, systemy do których mają dostęp i uzasadnienie biznesowe
• Dowód zatwierdzenia dostępu (e-mail, zgłoszenie, zrzut ekranu przepływu zatwierdzania)
• Zapisy przeglądów dostępów pokazujące kwartalną lub roczną ponowną certyfikację

Dla CC6.2 (uwierzytelnianie):

• Zrzut ekranu rejestracji MFA dla kont administracyjnych
• Dokumentacja polityki haseł i dowód jej egzekwowania
• Lista kont usługowych i dowód inwentaryzacji

Dla CC6.3 (usuwanie dostępu):

• Przykładowe zgłoszenia offboardingu (zazwyczaj 3–5 przykładów z okresu audytu)
• Dowód cofnięcia dostępu uprzywilejowanego w ramach SLA
• Integracja z systemem HR lub zapisy ręcznej weryfikacji

Dla CC6.6 (monitorowanie sesji):

• Dzienniki sesji pokazujące aktywność administracyjną (kto się zalogował, kiedy, do którego systemu, co zrobił)
• Dowód nagrywania sesji
• Diagram sieci pokazujący szyfrowanie w tranzycie

Dowody muszą obejmować cały okres audytu (zazwyczaj 12 miesięcy dla audytu Type II). Audytorzy pobiorą próbki zdarzeń z całego tego okresu — nie możesz polegać na dowodach z ostatnich dwóch tygodni przed pracami terenowymi audytu.

Typowe niepowodzenia CC6 i jak ich unikać

Współdzielone poświadczenia administratora Najczęstsze odkrycie CC6. „Używamy współdzielonego konta Administrator, ponieważ niektóre systemy nie obsługują kont indywidualnych" nie jest akceptowalnym mechanizmem kontrolnym. VaultPAM rozwiązuje ten problem: użytkownicy łączą się przez sesje pośredniczące bez otrzymywania poświadczenia. Sejf przechowuje hasło; dzienniki audytu pokazują dokładnie, który użytkownik zainicjował każdą sesję.

MFA niewymuszone na wszystkich kontach uprzywilejowanych Organizacje często mają MFA na firmowej poczcie, ale nie na bezpośrednim dostępie do serwerów (RDP, SSH). Audytorzy sprawdzają to konkretnie. Każda uprzywilejowana sesja musi wymagać MFA.

Brak dowodów przeglądu dostępów Wiele organizacji przeprowadza przeglądy dostępów nieformalnie. Audytorzy chcą udokumentowanych dowodów: kto przeglądał, co było przeglądane, kiedy i jakie działania zostały podjęte. „Przeprowadziliśmy przegląd w Q3" bez zgłoszenia, arkusza kalkulacyjnego lub raportu nie jest dowodem.

Dostęp nieodwołany niezwłocznie Luka między odejściem pracownika a cofnięciem jego dostępu jest powtarzającym się odkryciem. Jeśli Twój proces offboardingu trwa tydzień, a dostęp uprzywilejowany jest objęty tym samym kolejką, masz problem z CC6.3.

Dzienniki sesji niekompletne lub niedostępne Przechowywanie dzienników sesji to tylko połowa odpowiedzi. Audytorzy chcą zobaczyć, że możesz pobrać konkretne zdarzenia i że dzienniki są kompletne i odporne na manipulacje. Dzienniki w rozproszonych silosach (Dziennik zdarzeń Windows na każdym serwerze, dzienniki auth SSH na każdym pudełku Linux) bez centralnej agregacji są trudne do zaprezentowania jako dowody.

Jak VaultPAM automatycznie produkuje gotowe na audyt dowody CC6

VaultPAM jest zaprojektowany przy założeniu, że Twój audytor patrzy Ci przez ramię. Dowody, które produkuje, mapują bezpośrednio do tego, czego wymaga CC6:

Mechanizm kontrolny CC6	Co produkuje VaultPAM
CC6.1 — inwentarz dostępów	Kompletny raport wszystkich użytkowników, systemów docelowych, polityk dostępowych i zatwierdzeń — eksportowalny jako CSV lub dostępny przez API
CC6.2 — wymuszanie MFA	TOTP i WebAuthn wymuszane na poziomie sesji — każda uprzywilejowana sesja wymaga uwierzytelnienia; status rejestracji MFA widoczny w panelu administratora
CC6.2 — bez współdzielonych poświadczeń	Pośrednictwo sesji — użytkownicy uzyskują dostęp do celów bez otrzymywania haseł; sejf przechowuje poświadczenie, nie użytkownik
CC6.3 — usuwanie dostępu	Cofnięcie użytkownika w VaultPAM natychmiast kończy jego możliwość inicjowania nowych sesji; aktywne sesje mogą być przymusowo zakończone
CC6.6 — monitorowanie sesji	Pełne nagrywanie sesji (wideo + dziennik aktywności) dla każdej sesji RDP, SSH, VNC i HTTP; odporne na manipulacje przez łańcuch skrótów BLAKE3; przeszukiwalne według użytkownika, celu i zakresu czasu
CC6.6 — szyfrowanie w tranzycie	Wszystkie sesje pośredniczone przez mTLS; brak bezpośrednich przychodzących portów na systemach docelowych

Proces przeglądu dostępów jest wspierany przez eksporty dzienników audytu VaultPAM: możesz wygenerować kompletny raport każdej uprzywilejowanej sesji z ostatniego kwartału, posortowanej według użytkownika i celu, w minutach. Przedstaw to audytorowi razem z konfiguracją polityki dostępowej i zrzutem ekranu rejestracji MFA — to jest Twój pakiet dowodów CC6.

---

Zmierzasz w kierunku gotowości SOC 2 Type II? VaultPAM automatycznie produkuje gotowe na audyt dowody dla mechanizmów kontrolnych CC6 — nagrania sesji, dzienniki dostępów, wymuszanie MFA i konfiguracja polityk są raportowalne z jednego panelu.

Pobierz nasze podsumowanie compliance SOC 2 dla kompletnego mapowania mechanizmów kontrolnych VaultPAM do kryteriów zaufania SOC 2.