Przewodnik po dowodach audytowych dla kontroli dostępu w ISO 27001

Jest 09:10 w dniu audytu. Maria, CISO szybko rosnącej platformy fintechowej działającej w chmurze, ma otwartą politykę kontroli dostępu. Osoba odpowiedzialna za IT eksportuje ustawienia dostępu warunkowego od dostawcy tożsamości. HR szuka zgłoszenia zakończenia współpracy analityka finansowego, który odszedł sześć tygodni wcześniej. Audytor wewnętrzny podnosi wzrok i zadaje pytanie, którego wszyscy się spodziewali:

„Proszę pokazać, w jaki sposób dostęp jest wnioskowany, zatwierdzany, egzekwowany, przeglądany i odbierany użytkownikowi z uprzywilejowanym dostępem do danych osobowych”.

To jedno zdanie potrafi ujawnić, czy program kontroli dostępu jest gotowy do audytu, czy jedynie gotowy na poziomie dokumentacji polityk.

Zespół Marii miał dojrzały system zarządzania bezpieczeństwem informacji (SZBI), coroczny cykl recertyfikacji ISO/IEC 27001:2022, wdrożone uwierzytelnianie wieloskładnikowe, kontrolę dostępu opartą na rolach w kluczowych systemach oraz kwartalne arkusze przeglądów dostępu. Ten audyt był jednak inny. Lista żądań audytora obejmowała gotowość na nowe wymagania regulacyjne. Dla organizacji Marii oznaczało to NIS2, DORA i GDPR, oceniane przez ten sam operacyjny pryzmat: tożsamość, dostęp, uwierzytelnianie, uprawnienia uprzywilejowane i dowody.

Problem wielu CISO nie polega na tym, że kontrola dostępu nie istnieje. Problem polega na tym, że dowody są rozproszone. Zatwierdzenia onboardingu znajdują się w Jira lub ServiceNow. Ustawienia MFA są w Microsoft Entra ID, Okta lub u innego dostawcy tożsamości. Uprawnienia AWS, Azure i Google Cloud są w osobnych konsolach. Działania uprzywilejowane mogą być rejestrowane w narzędziu PAM albo nie być rejestrowane wcale. Status HR znajduje się w BambooHR, Workday lub arkuszach kalkulacyjnych. Przeglądy dostępu mogą być zatwierdzane e-mailem.

Gdy audytor łączy IAM, MFA, PAM, zdarzenia Joiner-Mover-Leaver, dane osobowe, administrację środowiskami chmurowymi i oczekiwania regulacyjne, rozproszone dowody szybko przestają się bronić.

Audyty kontroli dostępu ISO/IEC 27001:2022 nie są wyłącznie przeglądami konfiguracji technicznej. To testy systemu zarządzania. Sprawdzają, czy ryzyka związane z tożsamością i dostępem są rozumiane, objęte postępowaniem z ryzykiem, wdrożone, monitorowane i doskonalone. Gdy istotne są również NIS2, DORA i GDPR, te same dowody muszą potwierdzać oparty na ryzyku nadzór nad dostępem, silne uwierzytelnianie, identyfikowalne zatwierdzenia, terminowe cofnięcie dostępu, ograniczenie uprawnień uprzywilejowanych, ochronę danych osobowych i rozliczalność kierownictwa.

Praktyczną odpowiedzią nie jest większy segregator. Jest nią jeden model dowodów kontroli dostępu, który zaczyna się od zakresu SZBI i ryzyka, przechodzi przez politykę i projekt zabezpieczeń, trafia do narzędzi IAM i PAM oraz jednoznacznie mapuje się na ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST i COBIT.

Dlaczego kontrola dostępu jest regulacyjnym punktem krytycznym

Kontrola dostępu stała się tematem dla zarządu i organów regulacyjnych, ponieważ kompromitacja tożsamości jest obecnie powszechną ścieżką prowadzącą do zakłóceń operacyjnych, naruszeń ochrony danych, oszustw i ekspozycji łańcucha dostaw.

NIS2 Articles 2 i 3, odczytywane łącznie z Annex I i Annex II, obejmują zakresem wiele średnich i większych podmiotów z wymienionych sektorów jako podmioty kluczowe lub ważne. Dotyczy to infrastruktury cyfrowej oraz dostawców zarządzania usługami ICT, takich jak dostawcy usług chmurowych, dostawcy usług centrów danych, dostawcy usług zarządzanych oraz dostawcy zarządzanych usług bezpieczeństwa. Państwa członkowskie miały obowiązek transponować NIS2 do października 2024 r. i stosować środki krajowe od października 2024 r., a listy podmiotów miały zostać przygotowane do kwietnia 2025 r. Article 20 nakłada na organy zarządzające odpowiedzialność za zatwierdzanie środków zarządzania ryzykiem cyberbezpieczeństwa oraz nadzorowanie ich wdrożenia. Article 21 wymaga środków technicznych, operacyjnych i organizacyjnych, w tym polityk kontroli dostępu, zarządzania aktywami, cyberhigieny, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw oraz MFA lub ciągłego uwierzytelniania tam, gdzie jest to właściwe.

DORA dodaje sektorową warstwę odporności operacyjnej dla podmiotów finansowych i zewnętrznych dostawców usług ICT. Articles 1, 2 i 64 ustanawiają DORA jako jednolite ramy stosowane od 17 stycznia 2025 r. Articles 5 i 6 wymagają ładu zarządczego oraz udokumentowanych ram zarządzania ryzykiem ICT. Article 9 dotyczy ochrony i zapobiegania, w tym polityk, procedur, protokołów i narzędzi bezpieczeństwa ICT. Articles 24 do 30 dodają testowanie cyfrowej odporności operacyjnej oraz zarządzanie ryzykiem ICT stron trzecich. Dla podmiotów finansowych dowody kontroli dostępu stają się dowodami odporności, a nie tylko dowodami administracji IT.

GDPR wnosi perspektywę danych osobowych. Articles 2 i 3 definiują szerokie zastosowanie do przetwarzania w UE i oddziaływania na rynek UE. Article 5 wymaga integralności, poufności i możliwej do wykazania rozliczalności. Article 25 wymaga ochrony danych w fazie projektowania oraz domyślnej ochrony danych. Article 32 wymaga odpowiednich środków technicznych i organizacyjnych. W praktyce oznacza to kontrolowany dostęp, bezpieczne uwierzytelnianie, rejestrowanie, przegląd i terminowe usuwanie dostępu w systemach przetwarzających dane osobowe.

ISO/IEC 27001:2022 daje organizacjom mechanizm systemu zarządzania służący do ujednolicenia tych obowiązków. Clauses 4.1 do 4.3 wymagają od organizacji zrozumienia kontekstu, stron zainteresowanych, wymagań prawnych i umownych, interfejsów, zależności oraz zakresu SZBI. Clauses 6.1.1 do 6.1.3 wymagają oceny ryzyka bezpieczeństwa informacji, postępowania z ryzykiem, porównania z Annex A, Deklaracji stosowania oraz zatwierdzenia planów postępowania z ryzykiem i ryzyka szczątkowego. Clause 8.1 wymaga sterowania operacyjnego, udokumentowanych informacji potwierdzających, że procesy przebiegły zgodnie z planem, kontroli zmian oraz kontroli nad procesami dostarczanymi zewnętrznie.

Pytanie audytowe nie brzmi więc: „Czy macie MFA?”. Brzmi ono: „Czy potraficie wykazać, że dla tożsamości i systemów objętych zakresem ryzyko dostępu jest nadzorowane, objęte postępowaniem z ryzykiem, wdrożone, monitorowane i doskonalone?”.

Zbuduj szkielet dowodowy od zakresu SZBI do dowodów IAM

Clarysec rozpoczyna przygotowanie do audytu kontroli dostępu od zapewnienia identyfikowalności dowodów względem kontekstu biznesowego. ISO/IEC 27001:2022 oczekuje, że SZBI będzie zintegrowany z procesami organizacji i skalowany do jej potrzeb. Dostawca SaaS zatrudniający 30 osób i międzynarodowy bank nie będą miały takiej samej architektury dostępu, ale oba podmioty potrzebują spójnego łańcucha dowodowego.

ISO/IEC 27005:2022 jest przydatna, ponieważ zaleca konsolidację wymagań prawnych, regulacyjnych, umownych, sektorowych i wewnętrznych we wspólnym kontekście ryzyka. Clauses 6.4 i 6.5 podkreślają kryteria ryzyka uwzględniające cele organizacji, przepisy, relacje z dostawcami i ograniczenia. Clauses 7.1 i 7.2 dopuszczają scenariusze oparte na zdarzeniach i aktywach. W przypadku kontroli dostępu oznacza to ocenę scenariuszy strategicznych, takich jak „uprzywilejowany administrator SaaS eksportuje dane klientów z UE”, obok scenariuszy aktywowych, takich jak „osierocony klucz AWS IAM przypisany do magazynu produkcyjnego”.

W Zenith Blueprint: 30-etapowej mapie drogowej audytora Clarysec ten szkielet dowodowy powstaje w fazie Controls in Action. Krok 19 koncentruje się na zabezpieczeniach technicznych dla punktów końcowych i zarządzania dostępem, natomiast krok 22 formalizuje organizacyjny cykl życia dostępu.

Zenith Blueprint wskazuje zespołom, aby sprawdziły, czy nadawanie i odbieranie dostępu są ustrukturyzowane, zintegrowane z HR tam, gdzie jest to możliwe, wspierane przez ścieżki wniosków o dostęp i przeglądane kwartalnie. Instruuje też organizacje, aby dokumentowały typy tożsamości, egzekwowały kontrole dla tożsamości indywidualnych, współdzielonych i serwisowych, stosowały silne polityki haseł i MFA, eliminowały uśpione konta oraz utrzymywały bezpieczne skarbce lub dokumentację dla poświadczeń serwisowych.

Dokładnie tak audytorzy testują kontrolę dostępu: jedna tożsamość, jeden system, jedno zatwierdzenie, jedno uprawnienie, jeden przegląd i jedno cofnięcie dostępu naraz.

Co zebrać jako gotowe do audytu dowody kontroli dostępu

Pakiet dowodów kontroli dostępu powinien pozwalać audytorowi pobrać próbkę dowolnego użytkownika i prześledzić cykl życia: wniosek, zatwierdzenie, przypisanie, uwierzytelnianie, podniesienie uprawnień, monitorowanie, przegląd i cofnięcie dostępu.

Silny pakiet dowodowy obejmuje:

1. Politykę kontroli dostępu i politykę kont użytkowników
2. Procedurę Joiner-Mover-Leaver
3. Macierz ról lub macierz kontroli dostępu
4. Wykaz aplikacji, platform i repozytoriów danych objętych zakresem
5. Konfigurację MFA u dostawcy tożsamości
6. Polityki dostępu warunkowego i listę wyjątków
7. Inwentarz kont uprzywilejowanych
8. Dowody przepływu pracy PAM, w tym zatwierdzenia i logi sesji
9. Wyniki najnowszej kampanii przeglądu uprawnień
10. Przykładowe potwierdzenia przeglądu przez menedżerów i działania naprawcze
11. Raport zakończeń współpracy HR uzgodniony z logami dezaktywacji
12. Inwentarz kont serwisowych, właścicieli, zapisy rotacji i dowody ze skarbca
13. Procedurę kont awaryjnych typu „break glass” i log testowy
14. Dowody incydentów lub alertów obejmujące nieudane logowania, eskalację uprawnień lub uśpione konta
15. Wpisy w Deklaracji stosowania dla zabezpieczeń Annex A związanych z dostępem

Polityki Clarysec formułują to oczekiwanie wprost. W polityce dla MŚP Polityka kontroli dostępu dla MŚP wymaganie jest proste i ukierunkowane na audyt:

„Dla każdego nadania, zmiany i odebrania dostępu musi być prowadzony bezpieczny zapis”.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, pkt 6.1.1.

Ta sama polityka dla MŚP bezpośrednio łączy RBAC i MFA z odpowiedzialnościami ról:

„Wdraża kontrolę dostępu opartą na rolach (RBAC) i egzekwuje silne uwierzytelnianie (np. uwierzytelnianie wieloskładnikowe (MFA)).”

Z sekcji „Role i odpowiedzialności”, pkt 4.2.3.

W przypadku większych organizacji korporacyjna Polityka onboardingu i zakończenia współpracy wymaga, aby system IAM rejestrował utworzenie konta, przypisania ról i uprawnień oraz zdarzenia dezaktywacji, wspierał szablony dostępu opartego na rolach i integrował się z systemami HR w celu obsługi wyzwalaczy Joiner-Mover-Leaver. Ten zapis pomaga przedstawić historię audytową w jednym miejscu: standaryzowany onboarding, cykl życia tożsamości inicjowany przez HR i identyfikowalne zdarzenia IAM.

Zmapuj IAM, MFA, PAM i przeglądy na zabezpieczenia ISO/IEC 27001:2022

Zenith Controls: przewodnik zgodności między ramami Clarysec traktuje kontrolę dostępu jako powiązaną rodzinę kontroli, a nie element listy kontrolnej. W przypadku ISO/IEC 27001:2022 najbardziej istotne zabezpieczenia obejmują:

• Zabezpieczenie 5.15, kontrola dostępu
• Zabezpieczenie 5.16, zarządzanie tożsamością
• Zabezpieczenie 5.17, informacje uwierzytelniające
• Zabezpieczenie 5.18, prawa dostępu
• Zabezpieczenie 8.2, uprzywilejowane prawa dostępu
• Zabezpieczenie 8.3, ograniczenie dostępu do informacji
• Zabezpieczenie 8.5, bezpieczne uwierzytelnianie
• Zabezpieczenie 8.15, rejestrowanie
• Zabezpieczenie 8.16, działania monitorujące

Dla informacji uwierzytelniających Zenith Controls mapuje zabezpieczenie 5.17 jako kontrolę zapobiegawczą wspierającą poufność, integralność i dostępność, z operacyjną zdolnością zarządzania tożsamością i dostępem. Łączy je bezpośrednio z zarządzaniem tożsamością, bezpiecznym uwierzytelnianiem, rolami i odpowiedzialnościami, dopuszczalnym użytkowaniem oraz zgodnością z politykami. Bezpieczeństwo poświadczeń obejmuje cykl życia uwierzytelniacza, bezpieczne wydawanie, przechowywanie, resetowanie, unieważnianie, tokeny MFA, klucze prywatne i poświadczenia serwisowe.

Dla praw dostępu Zenith Controls mapuje zabezpieczenie 5.18 na formalne nadawanie, przegląd, modyfikację i cofnięcie dostępu. Łączy je z kontrolą dostępu, zarządzaniem tożsamością, rozdzieleniem obowiązków, uprzywilejowanymi prawami dostępu i monitorowaniem zgodności. To zabezpieczenie zamienia zasadę najmniejszych uprawnień w dowody.

Dla uprzywilejowanych praw dostępu Zenith Controls mapuje zabezpieczenie 8.2 na szczególne ryzyko kont podwyższonych, w tym administratorów domeny, użytkowników root, administratorów dzierżaw chmurowych, superużytkowników baz danych i kontrolerów CI/CD. Przewodnik łączy dostęp uprzywilejowany z zarządzaniem tożsamością, prawami dostępu, ograniczeniem dostępu do informacji, bezpiecznym uwierzytelnianiem, pracą zdalną, rejestrowaniem i monitorowaniem.

Jeden dobrze zaprojektowany raport z przeglądu dostępu może wspierać ISO/IEC 27001:2022, NIS2, DORA i GDPR, jeżeli obejmuje zakres, właściciela systemu, osobę dokonującą przeglądu, listę kont, uzasadnienie roli, oznaczenie uprawnień uprzywilejowanych, decyzje, usunięcia, wyjątki i datę zakończenia.

Dowód MFA to więcej niż zrzut ekranu

Częstym błędem audytowym jest przedstawienie zrzutu ekranu z informacją „MFA włączone”. Audytorzy potrzebują więcej. Muszą wiedzieć, gdzie MFA ma zastosowanie, kto jest wyłączony, jak zatwierdza się wyjątki, czy konta uprzywilejowane są objęte zakresem oraz czy konfiguracja techniczna odpowiada polityce.

Zgodnie z Zenith Blueprint, faza Controls in Action, krok 19, audytorzy zapytają, w jaki sposób egzekwowane są polityki haseł i MFA, które systemy są chronione, do kogo stosuje się MFA oraz czy krytyczne aplikacje można przetestować na przykładowym koncie. Dowody mogą obejmować konfigurację dostawcy tożsamości, polityki dostępu warunkowego, statystyki rejestracji MFA i procedury resetowania haseł.

Dla środowisk korporacyjnych Polityka zarządzania kontami użytkowników i uprawnieniami Clarysec stanowi:

„Tam, gdzie jest to technicznie możliwe, uwierzytelnianie wieloskładnikowe (MFA) jest obowiązkowe dla: 6.3.2.1 Kont administracyjnych i kont na poziomie root 6.3.2.2 Dostępu zdalnego (VPN, platformy chmurowe) 6.3.2.3 Dostępu do danych wrażliwych lub regulowanych”

Z sekcji „Wymagania dotyczące wdrożenia polityki”, pkt 6.3.2.

Tworzy to bezpośredni pomost audytowy. Jeśli MFA jest obowiązkowe dla kont administratorów, dostępu zdalnego i danych regulowanych, pakiet dowodowy powinien obejmować listy kont administracyjnych i kont root, konfigurację dostępu zdalnego, polityki dostępu warunkowego platform chmurowych, listy aplikacji z danymi wrażliwymi, raporty rejestracji MFA, zatwierdzenia wyjątków, środki kompensujące oraz najnowsze dowody przeglądu alertów dotyczących nieudanych logowań lub prób obejścia MFA.

W przypadku NIST SP 800-53 Rev. 5 jest to zgodne z IA-2 Identyfikacja i uwierzytelnianie, IA-5 Zarządzanie uwierzytelniaczami, AC-17 Dostęp zdalny i AU-2 Rejestrowanie zdarzeń. Dla COBIT 2019 wspiera DSS05.04 Zarządzanie tożsamością użytkowników i dostępem logicznym oraz powiązane praktyki monitorowania bezpieczeństwa.

Normy ISO wspierające ten obszar poszerzają perspektywę. ISO/IEC 27018:2020 rozszerza oczekiwania dotyczące uwierzytelniania dla chmury publicznej przetwarzającej dane osobowe. ISO/IEC 24760-1:2019 wspiera wiązanie uwierzytelniacza i zarządzanie cyklem życia. ISO/IEC 29115:2013 wprowadza poziomy zapewnienia uwierzytelniania, przydatne przy decyzji, gdzie wymagane są tokeny sprzętowe lub MFA odporne na phishing. ISO/IEC 27033-1:2015 wspiera silne uwierzytelnianie sieciowe dla dostępu zdalnego lub międzysieciowego.

Dowody PAM to najszybsza droga do istotnego ustalenia albo czystego audytu

Dostęp uprzywilejowany to obszar, w którym audytorzy stają się szczególnie sceptyczni, ponieważ konta uprzywilejowane mogą omijać zabezpieczenia, wydobywać dane, tworzyć trwały dostęp i modyfikować logi. W Zenith Blueprint, krok 19 stwierdza:

„W każdym systemie informatycznym dostęp uprzywilejowany oznacza władzę, a z tą władzą wiąże się ryzyko”.

Wytyczne koncentrują się na tym, kto ma dostęp uprzywilejowany, co ten dostęp umożliwia, jak jest zarządzany i jak jest monitorowany w czasie. Zalecają aktualny inwentarz, zasadę najmniejszych uprawnień, RBAC, czasowe lub just-in-time podniesienie uprawnień, ścieżki zatwierdzania, unikalne imienne konta, unikanie kont współdzielonych, rejestrowanie kont awaryjnych typu „break glass”, systemy PAM, rotację poświadczeń, skarbce, rejestrowanie sesji, tymczasowe podniesienie uprawnień, monitorowanie i regularny przegląd.

Korporacyjna Polityka kontroli dostępu Clarysec przekształca to w wymaganie kontrolne:

„Dostęp administracyjny musi być ściśle kontrolowany poprzez: 5.4.1.1 Oddzielne konta uprzywilejowane 5.4.1.2 Monitorowanie i rejestrowanie sesji 5.4.1.3 Uwierzytelnianie wieloskładnikowe 5.4.1.4 Czasowe podniesienie uprawnień lub podniesienie uruchamiane przepływem pracy”

Z sekcji „Wymagania ładu zarządczego”, pkt 5.4.1.

Ten cytat jest niemal scenariuszem testu audytowego. Jeśli polityka mówi o oddzielnych kontach administracyjnych, należy pokazać listę kont uprzywilejowanych i udowodnić, że każde z nich jest przypisane do imiennej osoby. Jeśli mówi o monitorowaniu sesji, należy pokazać nagrania sesji lub logi PAM. Jeśli mówi o MFA, należy wykazać egzekwowanie dla każdej ścieżki dostępu uprzywilejowanego. Jeśli mówi o czasowym podniesieniu uprawnień, należy pokazać znaczniki czasu wygaśnięcia i zgłoszenia zatwierdzeń.

Wersja dla MŚP jest równie bezpośrednia. Polityka zarządzania kontami użytkowników i uprawnieniami dla MŚP stanowi:

„Podwyższone lub administracyjne uprawnienia wymagają dodatkowej akceptacji Dyrektora Generalnego lub osoby odpowiedzialnej za IT oraz muszą być udokumentowane, ograniczone czasowo i objęte okresowym przeglądem”.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, pkt 6.2.2.

W mniejszych organizacjach to często różnica między „ufamy naszemu administratorowi” a „kontrolujemy ryzyko uprzywilejowane”. Audytor nie wymaga narzędzi korporacyjnych w każdym MŚP, ale wymaga dowodów proporcjonalnych do ryzyka. Zgłoszenie, zatwierdzenie, tymczasowe przypisanie do grupy, egzekwowanie MFA i zapis przeglądu mogą wystarczyć, gdy zakres jest ograniczony, a ryzyko niższe.

Przeglądy dostępu potwierdzają działanie zasady najmniejszych uprawnień

Przeglądy dostępu pokazują, czy uprawnienia nie kumulują się po cichu. Pokazują też, czy menedżerowie rozumieją dostęp, który faktycznie posiadają ich zespoły.

Korporacyjna Polityka zarządzania kontami użytkowników i uprawnieniami wymaga:

„Kwartalne przeglądy wszystkich kont użytkowników i powiązanych uprawnień muszą być przeprowadzane przez IT Security we współpracy z kierownikami działów”.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, pkt 6.5.1.

Dla MŚP Polityka zarządzania kontami użytkowników i uprawnieniami dla MŚP określa proporcjonalny cykl:

„Przegląd wszystkich kont użytkowników i uprawnień musi być przeprowadzany co sześć miesięcy”.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, pkt 6.4.1.

Wiarygodny przegląd dostępu obejmuje nazwę systemu, zakres, imię i nazwisko osoby dokonującej przeglądu, datę eksportu, datę przeglądu, właściciela tożsamości, dział, menedżera, status zatrudnienia, rolę lub uprawnienie, oznaczenie uprawnień uprzywilejowanych, oznaczenie wrażliwości danych, decyzję, zgłoszenie działań naprawczych, datę zamknięcia, właściciela wyjątku i datę wygaśnięcia wyjątku.

W Zenith Controls prawa dostępu 5.18 są miejscem, w którym staje się to dowodem zgodności w wielu ramach. Przewodnik mapuje prawa dostępu na GDPR Article 25, ponieważ dostęp powinien być ograniczany już w projekcie i domyślnie. Mapuje je na NIS2 Article 21(2)(i), ponieważ polityki kontroli dostępu i zarządzanie aktywami wymagają przypisania opartego na ryzyku, terminowego usuwania zbędnego dostępu i formalnego cofnięcia dostępu. Mapuje je na DORA, ponieważ finansowe systemy ICT wymagają dostępu opartego na rolach, monitorowania i procesów cofania dostępu.

Audytorzy zorientowani na NIST często testują ten obszar przez AC-2 Zarządzanie kontami, AC-5 Rozdzielenie obowiązków i AC-6 Najmniejsze uprawnienia. Audytorzy COBIT 2019 odwołują się do DSS05.04 Zarządzanie tożsamością użytkowników i dostępem logicznym oraz DSS06.03 Zarządzanie rolami, odpowiedzialnościami, uprawnieniami dostępu i poziomami upoważnień. Audytorzy ISACA ITAF koncentrują się na tym, czy dowody są wystarczające, wiarygodne i kompletne.

Zakończenie współpracy i unieważnianie tokenów łatwo objąć próbą

Osoby odchodzące to jedno z najłatwiejszych miejsc do wykazania, czy cykl życia działa. Audytorzy często wybierają niedawno zwolnionego pracownika i proszą o zapis zakończenia współpracy HR, zgłoszenie, log wyłączenia konta, dowód dezaktywacji SaaS, usunięcie VPN, unieważnienie MFA, usunięcie tokenu API i zwrot aktywów.

W Polityce onboardingu i zakończenia współpracy dla MŚP Clarysec stwierdza:

„Konta zakończone muszą zostać zablokowane lub usunięte, a powiązane tokeny dostępu muszą zostać unieważnione, w tym dostęp zdalny (VPN), powiązania z aplikacjami MFA i tokeny API”.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, pkt 6.3.3.

Ma to znaczenie, ponieważ współczesny dostęp to nie tylko nazwa użytkownika i hasło. Dostęp może utrzymywać się przez tokeny odświeżania, klucze API, klucze SSH, uprawnienia OAuth, konta serwisowe, lokalne uprawnienia administratora, sesje mobilne i portale stron trzecich. Zdezaktywowany zapis HR bez unieważnienia tokenów jest dowodem niekompletnym.

Zenith Blueprint, faza Controls in Action, krok 16, wskazuje organizacjom, aby przygotowały udokumentowaną listę kontrolną zakończenia współpracy, dowody dotyczące niedawno odchodzącej osoby, log wyłączenia konta użytkownika z AD lub MDM, podpisany formularz zwrotu aktywów oraz dokumentację offboardingu obejmującą obowiązki dotyczące poufności.

Audytor Marii poprosił o odchodzącego starszego programistę, który miał uprzywilejowany dostęp do produkcyjnych baz danych. Jej zespół przedstawił Politykę onboardingu i zakończenia współpracy dla MŚP, listę kontrolną zakończenia współpracy zbudowaną na podstawie Zenith Blueprint krok 16, zgłoszenie ITSM wyzwolone przez HR, log wyłączenia konta w katalogu, unieważnienie certyfikatu VPN, usunięcie z organizacji GitHub, usunięcie klucza AWS IAM oraz zamknięte zgłoszenie weryfikacyjne podpisane przez menedżera IT. Dowody były kompletne, terminowe i bezpośrednio powiązane z polityką.

Przeprowadź sprint dowodowy na trzech próbkach, zanim zrobi to audytor

Praktycznym ćwiczeniem gotowości jest wybranie trzech próbek przed audytem:

1. Nowy pracownik, który dołączył w ciągu ostatnich 90 dni
2. Użytkownik uprzywilejowany z dostępem administracyjnym do chmury, bazy danych, produkcji lub IAM
3. Osoba odchodząca albo pracownik ze zmienioną rolą z ostatnich 90 dni

Następnie należy powiązać każdą próbkę z zapisami SZBI: scenariuszem ryzyka, decyzją dotyczącą postępowania z ryzykiem, wyborem zabezpieczenia w Deklaracji stosowania, klauzulą polityki, konfiguracją techniczną, zapisem przeglądu i działaniem korygującym, jeśli istnieje luka.

To przekształca przygotowanie do audytu z gromadzenia dokumentów w weryfikację kontroli.

Przygotuj się na różne perspektywy audytowe

Różne doświadczenia audytorów prowadzą do różnych pytań, nawet gdy dowody są te same.

Przygotowanie dowodów spełniających wszystkie te perspektywy pokazuje dojrzały program zgodności i ogranicza powielanie pracy.

Typowe ustalenia i działania zapobiegawcze

Ustalenia dotyczące kontroli dostępu są przewidywalne. Działania zapobiegawcze również.

Korporacyjna Polityka kontroli dostępu dodaje wymaganie przechowywania, które zapobiega jednej z najczęstszych awarii dowodowych:

„Decyzje zatwierdzające muszą być rejestrowane i przechowywane do celów audytowych przez okres co najmniej 2 lat”.

Z sekcji „Wymagania ładu zarządczego”, pkt 5.3.2.

Jeśli zatwierdzenia znikają po czyszczeniu poczty, kontrola mogła działać, ale audyt nie może na niej polegać. Okres przechowywania jest elementem projektu kontroli.

Rozliczalność kierownictwa wymaga metryk dostępu

NIS2 Article 20 oraz DORA Articles 5 i 6 czynią kontrolę dostępu kwestią zarządczą, ponieważ kompromitacja tożsamości może przekształcić się w zakłócenie operacyjne, zgłoszenie regulacyjne, naruszenie ochrony danych i szkodę dla klienta. ISO/IEC 27001:2022 Clauses 5.1 do 5.3 wymagają również, aby najwyższe kierownictwo dostosowało SZBI do strategii biznesowej, zapewniło zasoby, komunikowało znaczenie, przypisało odpowiedzialności i wspierało ciągłe doskonalenie.

Przydatne metryki kontroli dostępu obejmują:

• Odsetek systemów krytycznych objętych SSO
• Odsetek kont uprzywilejowanych z MFA
• Liczba stałych kont uprzywilejowanych w porównaniu z kontami JIT
• Wskaźnik ukończenia przeglądów dostępu
• Liczba cofniętych nadmiernych uprawnień
• Zgodność z SLA dezaktywacji osób odchodzących
• Liczba uśpionych kont
• Pokrycie właścicieli kont serwisowych
• Pokrycie rejestrowania sesji PAM
• Liczba i wiek wyjątków MFA

Te metryki pomagają kierownictwu zatwierdzać postępowanie z ryzykiem i wykazać nadzór. Zwiększają też wiarygodność audytu, ponieważ organizacja może pokazać, że kontrola dostępu jest monitorowana jako żywe ryzyko, a nie odkrywana ponownie przed każdym audytem.

Zamień rozproszone dowody w pewność audytową

Jeżeli dowody kontroli dostępu ISO/IEC 27001:2022 są rozproszone między HR, ITSM, IAM, PAM, konsolami chmurowymi i arkuszami kalkulacyjnymi, następnym krokiem nie jest kolejne przepisywanie polityki. Następnym krokiem jest architektura dowodowa.

Zacznij od tej sekwencji:

1. Zdefiniuj systemy, tożsamości i dane objęte zakresem.
2. Zmapuj wymagania NIS2, DORA, GDPR i wymagania umowne do kontekstu SZBI.
3. Wykorzystaj scenariusze ryzyka w stylu ISO/IEC 27005:2022, aby priorytetyzować IAM, MFA, PAM i przeglądy dostępu.
4. Zaktualizuj Deklarację stosowania i plan postępowania z ryzykiem.
5. Dopasuj klauzule polityk do rzeczywistych przepływów pracy IAM i PAM.
6. Przeprowadź sprint dowodowy na trzech próbkach.
7. Usuń luki, zanim znajdzie je audytor.
8. Utrzymuj wielokrotnego użytku pakiet dowodowy na potrzeby certyfikacji, due diligence klientów i przeglądów regulacyjnych.

Clarysec może pomóc we wdrożeniu tego podejścia dzięki Zenith Blueprint: 30-etapowej mapie drogowej audytora, mapowaniu wymagań między ramami z użyciem Zenith Controls: przewodnika zgodności między ramami oraz operacjonalizacji wymagań za pomocą właściwego zestawu polityk Clarysec, w tym Polityki kontroli dostępu, Polityki zarządzania kontami użytkowników i uprawnieniami oraz Polityki onboardingu i zakończenia współpracy.

Gotowość kontroli dostępu do audytu nie polega na udowodnieniu, że kupiono narzędzie IAM. Polega na udowodnieniu, że procesy tożsamości, uwierzytelniania, uprawnień uprzywilejowanych i przeglądów ograniczają realne ryzyko biznesowe oraz spełniają normy i regulacje istotne dla organizacji.

Pobierz zestawy narzędzi Clarysec, przeprowadź sprint dowodowy na trzech próbkach i zamień dowody kontroli dostępu z rozproszonego chaosu w przejrzysty, powtarzalny i możliwy do obrony portfel audytowy.