PAM i konta awaryjne typu „break glass” w ISO 27001 w 2026 r.

O 02:14 w niedzielny poranek kierownik incydentu otrzymuje wiadomość, której obawia się każdy CISO: „Uwierzytelnianie produkcyjne nie działa. Konsola administracyjna jest niedostępna. Przełączenie awaryjne bazy danych utknęło”.

Dyżurny inżynier chmury widzi problem, ale nie może go naprawić. Jego standardowa rola uprzywilejowana zależy od tego samego dostawcy tożsamości, który właśnie działa w trybie zdegradowanym. Osoba odpowiedzialna za operacje prosi o awaryjne dane uwierzytelniające administratora. Menedżer ds. zgodności pyta, czy konto typu „break glass” było kiedykolwiek testowane. DPO pyta, czy dostęp do produkcyjnej bazy danych może ujawnić dane osobowe. CISO zadaje pytanie, które przesądza, czy będzie to kontrolowane przywracanie działania, czy koszmar audytowy:

„Czy potrafimy wykazać, kto użył dostępu awaryjnego, dlaczego, co zrobił oraz że konto zostało potem zresetowane?”

Inna organizacja może mierzyć się z tym samym problemem w znacznie spokojniejszych warunkach. CISO firmy fintech siedzi naprzeciw audytorów zewnętrznych po błędnej konfiguracji chmurowej bazy danych. Incydent został szybko usunięty, ale przyczyna źródłowa nie była uspokajająca. Programista zewnętrzny miał stałe uprawnienia administracyjne. Gdy główny administrator był niedostępny, programista użył konta typu „break glass” opartego na współdzielonym haśle zapisanym w „bezpiecznej” notatce dostępnej dla zespołu DevOps.

Audytorzy nie koncentrowali się wyłącznie na błędnej konfiguracji. Pytali, czy dostęp był ograniczony czasowo, czy istniała indywidualna rozliczalność, czy polecenia były rejestrowane, czy dane osobowe były chronione zgodnie z GDPR Article 32, czy spełniono obowiązki DORA w zakresie ryzyka ICT oraz czy można wykazać spełnienie oczekiwań NIS2 dotyczących cyberhigieny.

To jest rzeczywisty punkt nacisku dla zarządzania dostępem uprzywilejowanym i kont typu „break glass” w 2026 r. PAM nie jest już niszowym projektem bezpieczeństwa tożsamości. To miejsce, w którym zbiegają się ransomware, naruszenia środowisk chmurowych, ryzyko dostawców, ochrona danych, odporność operacyjna i dowody audytowe.

Dostęp uprzywilejowany to obszar, w którym atakujący próbują wygrać. Dostęp typu „break glass” to obszar, w którym obrońcy próbują odzyskać kontrolę. Oba opierają się na tej samej niebezpiecznej zdolności: podwyższonym dostępie, który może omijać kontrole, zmieniać konfiguracje, odczytywać dane wrażliwe, rotować klucze, wyłączać rejestrowanie, odtwarzać kopie zapasowe, wdrażać kod albo niszczyć dowody.

Praktyczne stanowisko Clarysec jest proste: dostęp awaryjny jest potrzebny, ale niezarządzany dostęp awaryjny oznacza niezarządzane ryzyko. Prawidłową odpowiedzią nie jest „żadnych kont typu break glass”. Prawidłową odpowiedzią jest zarządzany model dostępu uprzywilejowanego obejmujący inwentarz, zatwierdzanie, limity czasowe, silne uwierzytelnianie, rejestrowanie sesji, przegląd po użyciu, reset danych uwierzytelniających i dowody audytowe.

Dlaczego dostęp uprzywilejowany jest kwestią zgodności na poziomie zarządu

W środowiskach o niższej dojrzałości dostęp uprzywilejowany jest często traktowany jako zadanie administracji IT. Ktoś potrzebuje uprawnień administratora, otwierane jest zgłoszenie, przyznawana jest rola, a działalność toczy się dalej. Taki model nie wytrzymuje konfrontacji ze współczesnym ransomware, infrastrukturą cloud-native, rozliczalnością NIS2, odpornością operacyjną DORA ani analizą naruszeń w ramach GDPR.

Dyrektywa NIS2 przenosi ład cyberbezpieczeństwa do sali zarządu. Article 20 wymaga, aby organy zarządzające podmiotów kluczowych i ważnych zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorowały ich wdrożenie oraz odbywały szkolenia z cyberbezpieczeństwa. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, w tym analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, skuteczności kontroli, cyberhigieny, bezpieczeństwa HR, kontroli dostępu, zarządzania aktywami oraz MFA lub ciągłego uwierzytelniania, jeżeli jest to właściwe.

W przypadku dostawców SaaS, dostawców usług zarządzanych, dostawców zarządzanego bezpieczeństwa, usług chmurowych, centrów danych i innych organizacji infrastruktury cyfrowej zastosowanie NIS2 zależy od sektora, wielkości, roli, wpływu transgranicznego oraz ustanowienia w UE. Wniosek operacyjny jest bezpośredni: kontrola dostępu nie jest już ukryta w technicznym załączniku. Jest częścią bazowego poziomu cyberhigieny, który kierownictwo musi zatwierdzać, monitorować i korygować.

W przypadku podmiotów finansowych rozporządzenie DORA zmienia język, ale nie ryzyko bazowe. DORA obowiązuje od 17 stycznia 2025 r. i ustanawia jednolite ramy zarządzania ryzykiem ICT, zgłaszania poważnych incydentów związanych z ICT, testowania cyfrowej odporności operacyjnej oraz zarządzania ryzykiem stron trzecich ICT. Article 5 wymaga uzgodnień dotyczących ładu i kontroli ryzyka ICT, w których organ zarządzający definiuje, zatwierdza i nadzoruje uzgodnienia dotyczące ryzyka ICT oraz ponosi za nie odpowiedzialność. Article 6 wymaga udokumentowanych ram zarządzania ryzykiem ICT obejmujących polityki, procedury, protokoły i narzędzia służące ochronie aktywów ICT. Article 17 wymaga procesu zarządzania incydentami związanymi z ICT, który wykrywa, rejestruje, klasyfikuje i eskaluje incydenty oraz przywraca bezpieczne operacje.

GDPR dodaje perspektywę prywatności i rozliczalności. Article 5(1)(f) wymaga, aby dane osobowe były przetwarzane z zachowaniem integralności i poufności. Article 5(2) wymaga rozliczalności. Article 25 wymaga ochrony danych w fazie projektowania i domyślnej ochrony danych. Article 32 wymaga odpowiednich środków technicznych i organizacyjnych dla bezpieczeństwa przetwarzania. Jeżeli użytkownik uprzywilejowany może eksportować rejestry klientów, uzyskiwać dostęp do danych szczególnych kategorii, wyłączać logi audytowe albo zmieniać ustawienia retencji bez przeglądu, organizacja nie popełniła jedynie błędu w IAM. Może nie być w stanie wykazać odpowiedniego poziomu bezpieczeństwa.

ISO/IEC 27001:2022 jest kręgosłupem systemu zarządzania, który pozwala obsłużyć te obowiązki w ramach jednego zintegrowanego programu. Punkt 4.2 wymaga, aby organizacja rozumiała strony zainteresowane oraz ich wymagania, w tym obowiązki prawne, regulacyjne i umowne. Punkt 5.1 wymaga przywództwa i zaangażowania. Punkt 6.1.2 wymaga oceny ryzyka bezpieczeństwa informacji. Punkt 6.1.3 wymaga postępowania z ryzykiem. Punkt 8 wymaga planowania i kontroli operacyjnej.

W przypadku dostępu uprzywilejowanego przesuwa to rozmowę z pytania „które narzędzie PAM powinniśmy kupić?” na pytania: „jakimi ryzykami się zajmujemy, które środki kontrolne wybrano, kto jest ich właścicielem, jak są wykonywane i jakie dowody potwierdzają ich skuteczność?”

PAM nie jest jednym środkiem kontrolnym, lecz łańcuchem dowodowym

Narzędzie PAM może przechowywać hasła w skarbcu, pośredniczyć w sesjach, rejestrować naciśnięcia klawiszy, rotować dane uwierzytelniające i egzekwować dostęp just-in-time. Te możliwości mają znaczenie. Jeżeli jednak organizacja nie zdefiniowała ról uprzywilejowanych, nie zatwierdziła dostępu awaryjnego, nie zmapowała dostępu do aktywów, nie przeglądała praw dostępu, nie chroniła logów i nie szkoliła administratorów, narzędzie staje się częściową kontrolą o słabej możliwości obrony podczas audytu.

Najbardziej użyteczny sposób zarządzania dostępem uprzywilejowanym polega na myśleniu kategoriami rezultatów kontroli, a nie nazw narzędzi.

Zenith Controls: przewodnik po zgodności przekrojowej Zenith Controls traktuje środek kontrolny ISO/IEC 27002:2022 8.2, uprawnienia dostępu uprzywilejowanego, jako punkt ciężkości PAM. Klasyfikuje ten środek kontrolny jako zapobiegawczy, wspierający poufność, integralność i dostępność, powiązany z koncepcją cyberbezpieczeństwa Protect, zdolnością operacyjną zarządzanie tożsamością i dostępem oraz domeną bezpieczeństwa Protection.

Środek kontrolny 8.2 jest istotny, ponieważ łączy się z otaczającymi go środkami kontrolnymi, które czynią dostęp uprzywilejowany możliwym do prześledzenia w audycie:

Dlatego audytor rzadko poprzestaje na pytaniu: „Czy macie system PAM?”. Silniejsze pytania audytowe brzmią: czy istnieje inwentarz kont uprzywilejowanych? Czy role uprzywilejowane są zatwierdzane? Czy prawa są ograniczone czasowo? Czy awaryjne dane uwierzytelniające są zabezpieczone? Czy potraficie wykazać, kto ich użył? Czy polecenia są rejestrowane? Czy administratorzy dostawców są objęci zakresem? Czy prawa dostępu są przeglądane? Czy dane uwierzytelniające zostały zresetowane? Czy wyjątki zostały zaakceptowane w ramach akceptacji ryzyka?

Mapowanie praw dostępu w Zenith Controls wskazuje to wprost: zarządzanie prawami dostępu wdraża zasady kontroli dostępu, takie jak zasada najmniejszych uprawnień, zasada wiedzy koniecznej i autoryzacja, natomiast konta uprzywilejowane wymagają szczególnego nadzoru i szybkiego cofnięcia, gdy nie są już potrzebne.

Wymagania polityki dla wiarygodnego dostępu typu „break glass”

Konto typu „break glass” nie jest współdzielonym hasłem administratora w zapieczętowanej kopercie. W 2026 r. taki model jest zbyt słaby dla chmury, fintechu, SaaS, ochrony zdrowia, usług zarządzanych i regulowanych operacji cyfrowych.

Możliwy do obrony model „break glass” wymaga siedmiu minimalnych zasad polityki:

1. Konto musi być udokumentowane.
2. Konto musi być zatwierdzone.
3. Użycie musi być możliwe do przypisania unikalnej osobie, jeżeli jest to technicznie możliwe.
4. Użycie musi być ograniczone do rzeczywistych sytuacji awaryjnych.
5. Użycie musi być rejestrowane i przeglądane.
6. Dane uwierzytelniające lub czynniki uwierzytelniania muszą być resetowane albo rotowane po użyciu.
7. Konto musi być testowane i objęte zakresem audytu.

Biblioteka polityk Clarysec przekłada te zasady na użyteczny język ładu zarządczego.

Polityka zarządzania kontami użytkowników i uprawnieniami dla MŚP Polityka zarządzania kontami użytkowników i uprawnieniami - MŚP stanowi:

„Dostęp awaryjny (np. konta administratorów typu „break glass”) musi być jasno udokumentowany, zabezpieczony i używany wyłącznie wtedy, gdy jest to bezwzględnie konieczne”.

Z sekcji „Postępowanie z ryzykiem i wyjątki”, klauzula polityki 7.3.1.

Ta sama polityka dla MŚP stanowi dalej:

„Takie konta muszą być rejestrowane, przeglądane po użyciu i resetowane po każdym zdarzeniu awaryjnym”.

Z sekcji „Postępowanie z ryzykiem i wyjątki”, klauzula polityki 7.3.2.

W przypadku codziennego podnoszenia uprawnień polityka dla MŚP wymaga również:

„Podwyższone lub administracyjne uprawnienia wymagają dodatkowego zatwierdzenia przez Dyrektora Generalnego albo osobę odpowiedzialną za IT oraz muszą być udokumentowane, ograniczone czasowo i podlegać okresowemu przeglądowi”.

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

W większych organizacjach zestaw polityk korporacyjnych idzie dalej. Polityka zarządzania kontami użytkowników i uprawnieniami Polityka zarządzania kontami użytkowników i uprawnieniami wymaga, aby:

„Sesje uprzywilejowane były w pełni rejestrowane, w tym wydane polecenia i wykonane działania. Logi muszą być okresowo przeglądane przez wyznaczonych recenzentów”.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.4.2.

Ta sama polityka wymaga, aby tymczasowe albo awaryjne konta dostępu uprzywilejowanego podlegały udokumentowanej procedurze „break glass” w klauzuli 6.2.5, natomiast klauzula 7.4 określa wymagania dla tej procedury.

Polityka kontroli dostępu Polityka kontroli dostępu wzmacnia przechowywanie dowodów audytowych:

„Decyzje zatwierdzające muszą być rejestrowane i przechowywane na potrzeby audytu przez co najmniej 2 lata”.

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.3.2.

Polityka rejestrowania i monitorowania dla MŚP Polityka logowania i monitorowania - MŚP wskazuje oczekiwania dotyczące rejestrowania uwierzytelniania:

„Logi uwierzytelniania: udane i nieudane próby logowania, czas trwania sesji, użycie MFA”

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.4.2.

Łącznie te klauzule zmieniają dostęp awaryjny z bohaterskiego obejścia w kontrolowane zdarzenie. Konto jest wyjątkowe, ale nadzór nad nim nie.

Podejście Zenith Blueprint do wdrożenia PAM

Zenith Blueprint: 30-etapowa mapa drogowa audytora Zenith Blueprint traktuje dostęp uprzywilejowany jako praktyczny problem wdrożeniowy, a nie teoretyczne stwierdzenie kontrolne. W fazie „Kontrole w działaniu”, krok 19, „Kontrole technologiczne I”, wskazuje:

„W każdym systemie informatycznym dostęp uprzywilejowany to władza, a wraz z tą władzą pojawia się ryzyko”.

Z fazy „Kontrole w działaniu”, krok 19: „Kontrole technologiczne I”.

Krok 19 wymaga od organizacji identyfikacji kont uprzywilejowanych w środowiskach infrastruktury lokalnej, chmury, SaaS, rozwoju i infrastruktury. Obejmuje to administratorów domeny, użytkowników root, administratorów tenantów chmurowych, superużytkowników baz danych oraz kontrolerów potoków CI/CD. Podkreśla także minimalizację dostępu uprzywilejowanego poprzez kontrolę dostępu opartą na rolach (RBAC), podnoszenie uprawnień just-in-time oraz ścieżki akceptacji.

Ma to znaczenie, ponieważ wiele poważnych incydentów nie zaczyna się od formalnego konta typu „break glass”. Zaczyna się od stałego uprzywilejowania. Inżynier chmury zachowuje prawa właściciela „na wszelki wypadek”. Administrator bazy danych utrzymuje dostęp do środowiska produkcyjnego po przeniesieniu do innego zespołu. Konto serwisowe CI/CD ma szerokie uprawnienia w wielu środowiskach. Konto dostawcy usług zarządzanych jest zwolnione z MFA, ponieważ „potrzebują szybkiego dostępu”.

Krok 20 Zenith Blueprint rozszerza tę samą logikę na narzędzia uprzywilejowane. Nakazuje organizacjom utworzenie albo aktualizację inwentarza uprzywilejowanych narzędzi, ograniczenie ich uruchamiania do uprawnionych administratorów, weryfikację, że użycie jest rejestrowane i objęte alertami, oraz rozważenie rejestrowania skryptów, np. rejestrowania PowerShell przez zasady grupy. Jest to krytyczne, ponieważ konto uprzywilejowane często jest tylko punktem wejścia. Szkoda powstaje wtedy, gdy atakujący uruchamia narzędzia wyłączające kontrole, zrzucające dane uwierzytelniające albo umożliwiające ruch lateralny.

Krok 22 formalizuje cykl życia kontroli dostępu. Wymaga ustrukturyzowanego nadawania i odbierania dostępu, najlepiej zintegrowanego z HR i wspieranego przez ścieżki wniosków o dostęp, z kwartalnymi udokumentowanymi przeglądami dostępu. Krok 16 wiąże cykl życia z zakończeniem współpracy, wymagając listy kontrolnej zakończenia współpracy z pracownikiem używanej wspólnie przez HR i IT, obejmującej wyłączenie konta, zwrot aktywów i przypomnienia dotyczące NDA.

Zenith Blueprint czyni z PAM powiązany model operacyjny: tożsamość, HR, narzędzia uprzywilejowane, rejestrowanie, reagowanie na incydenty, przeglądy dostępu i dowody audytowe wzajemnie się wzmacniają.

Praktyczny model nadzoru nad „break glass” na 2026 r.

Dobrze zaprojektowany proces „break glass” musi działać podczas awarii. Jeżeli zależy od tego samego dostawcy tożsamości, platformy zgłoszeniowej i usługi czatu, które są niedostępne podczas przerwy, jest tylko pozorem kontroli.

Jednocześnie dostęp awaryjny nie może stać się kanałem obejścia używanym dla wygody. Clarysec zwykle projektuje nadzór nad „break glass” wokół czterech warstw: zapobiegania, aktywacji, obserwacji i odzyskiwania.

W środowiskach chmurowych należy uwzględnić administratorów na poziomie tenanta, konta root w chmurze, awaryjnych administratorów dostawcy tożsamości, uprzywilejowane konta serwisowe, użytkowników głównych baz danych, role Kubernetes cluster-admin, klucze wdrożeniowe CI/CD, administratorów skarbców sekretów oraz konta wsparcia stron trzecich.

W środowiskach hybrydowych należy uwzględnić administratorów domeny, administratorów kopii zapasowych, administratorów hiperwizorów, administratorów zapór sieciowych, administratorów konsoli EDR oraz użytkowników narzędzi uprzywilejowanych.

W środowiskach wrażliwych z perspektywy prywatności należy uwzględnić administratorów, którzy mogą uzyskać dostęp do baz danych zawierających dane osobowe, logów zawierających identyfikatory, rejestrów HR, biometrycznych danych weryfikacji tożsamości, systemów monitorowania oszustw albo narzędzi obsługi klienta.

Stan docelowy jest prosty do opisania i trudny do podrobienia: każda ścieżka awaryjna jest znana, zatwierdzona, zabezpieczona, obserwowalna, odwracalna i przeglądana.

60-minutowe ćwiczenie dowodowe „break glass”

CISO albo menedżer ds. zgodności może przeprowadzić użyteczne ćwiczenie „break glass” jeszcze w tym tygodniu bez zakupu nowego narzędzia. Celem nie jest wyłącznie potwierdzenie, że konto działa. Celem jest wykazanie, że kontrola wytwarza dowody.

Scenariusz

Załóżmy, że podstawowy dostawca tożsamości działa w trybie zdegradowanym. Standardowe podnoszenie uprawnień just-in-time jest niedostępne. Klaster produkcyjnej bazy danych wymaga awaryjnych zmian konfiguracji w celu przywrócenia usługi. Konto administratora chmury typu „break glass” musi zostać aktywowane.

Krok 1: Potwierdź, że konto znajduje się w inwentarzu kont uprzywilejowanych

Użyj Zenith Blueprint, faza „Kontrole w działaniu”, krok 19, aby zweryfikować, że konto widnieje w inwentarzu kont uprzywilejowanych. Zarejestruj nazwę konta i środowisko, właściciela biznesowego, właściciela technicznego, dostępne systemy, wpływ na dane osobowe, metodę uwierzytelniania, lokalizację skarbca, metodę rotacji oraz datę ostatniego testu.

Jeżeli konto nie występuje w inwentarzu, potraktuj to jako lukę kontrolną i dodaj ją do rejestru ryzyk.

Krok 2: Sprawdź zgodność z politykami

Zmapuj zdarzenie na wymagania Polityki zarządzania kontami użytkowników i uprawnieniami dotyczące udokumentowanych procedur „break glass” oraz rejestrowania sesji uprzywilejowanych. Jeżeli jesteś MŚP, użyj klauzul 7.3.1 i 7.3.2 z Polityki zarządzania kontami użytkowników i uprawnieniami dla MŚP jako minimalnego poziomu bazowego: udokumentowane, zabezpieczone, konieczne, rejestrowane, przeglądane i resetowane.

Zmapuj przechowywanie zatwierdzeń na klauzulę 5.3.2 Polityki kontroli dostępu, która wymaga, aby decyzje zatwierdzające były rejestrowane i przechowywane przez co najmniej 2 lata.

Krok 3: Otwórz zapis dostępu awaryjnego

Utwórz zgłoszenie albo zapis incydentu przed aktywacją albo w momencie aktywacji. Uwzględnij:

• Powód awaryjny
• Usługę objętą wpływem
• Żądane konto
• Wnioskującego
• Zatwierdzającego
• Czas rozpoczęcia
• Oczekiwany czas zakończenia
• Wpływ na klientów lub regulacje
• Wpływ na dane osobowe w ramach GDPR
• Oznaczenie do oceny obowiązku zgłoszeniowego NIS2 albo DORA

Nie czekaj do końca, aby odtworzyć przebieg zdarzeń. Wartość audytowa jest największa, gdy zapis zaczyna się przed użyciem dostępu.

Krok 4: Aktywuj i obserwuj

Aktywuj konto typu „break glass”. Potwierdź, że użyto MFA albo kompensacyjnego uwierzytelniania, sesja jest nagrywana, polecenia lub działania administracyjne są rejestrowane, logi są przekazywane do scentralizowanego rejestrowania, synchronizacja czasu wspiera rekonstrukcję osi czasu oraz że generowany jest alert dotyczący użycia konta awaryjnego.

Jest to zgodne z Zenith Controls dla 8.15 Rejestrowanie, które opisuje rejestrowanie jako bazową warstwę danych dla monitorowania i wskazuje, że użytkownicy uprzywilejowani oraz uruchamianie uprzywilejowanych narzędzi muszą być rejestrowane kompleksowo.

Krok 5: Zamknij, zresetuj i przejrzyj

Po wykonaniu zadania awaryjnego wyłącz konto albo przywróć je do statusu zapieczętowanego, zrotuj dane uwierzytelniające albo zresetuj czynnik uwierzytelniania, przejrzyj logi sesji, udokumentuj polecenia i zmiany konfiguracji, potwierdź, że nie doszło do niepotrzebnego dostępu do danych, zaktualizuj zapis incydentu, odnotuj wnioski i zdecyduj, czy zostały uruchomione progi zgłoszeniowe NIS2, DORA albo GDPR.

Jeżeli uzyskano dostęp do danych osobowych, zaangażuj DPO. Jeżeli zdarzenie spowodowało zakłócenie usługi albo mogło spowodować istotny wpływ, zaangażuj właściciela raportowania NIS2 albo DORA. Jeżeli konto typu „break glass” nie zadziałało, udokumentuj to jako ustalenie dotyczące odporności operacyjnej, a nie jedynie problem IAM.

Mapowanie zgodności przekrojowej dla PAM i kontroli „break glass”

Najsilniejszy model ładu zarządczego nie duplikuje kontroli dla każdej regulacji. Buduje jeden łańcuch dowodowy, który wspiera wiele obowiązków.

NIST CSF 2.0 jest szczególnie użyteczny przy przekładaniu PAM na profil bieżący i profil docelowy. Jego metoda profilu zaczyna się od zakresu, następnie gromadzi polityki, priorytety ryzyka, rejestry, wymagania, praktyki i role robocze, a potem tworzy priorytetyzowany plan działań. W przypadku dostępu uprzywilejowanego oznacza to określenie profilu wokół bezpieczeństwa tożsamości, administracji chmurowej, odporności na ransomware, krytycznych systemów finansowych albo dostępu dostawców.

Dla podmiotów finansowych objętych DORA rozporządzenie DORA pełni rolę sektorowego unijnego reżimu odporności cyfrowej dla równoważnych obowiązków NIS2 dotyczących ryzyka i incydentów. Nie czyni to NIS2 nieistotną. Oznacza, że podmiot finansowy powinien stosować DORA jako reżim nadrzędny dla wymagań dotyczących ryzyka ICT i incydentów, utrzymując jednocześnie koordynację z krajowymi strategiami cyberbezpieczeństwa, właściwymi organami i CSIRT tam, gdzie ma to zastosowanie.

Jak audytorzy testują dowody dotyczące dostępu uprzywilejowanego

Audytorzy nie oceniają PAM wyłącznie przez lekturę polityki. Łączą politykę, konfigurację, logi, zgłoszenia, wywiady i obserwowaną praktykę.

Metodyka audytu Zenith Controls dla uprawnień dostępu uprzywilejowanego odwołuje się do praktyk audytowych ISO/IEC 19011:2018. Audytorzy przeglądają polityki definiujące podwyższone uprawnienia, nadawanie dostępu, monitorowanie oraz procedury cofania dostępu. Analizują inwentarze kont użytkowników, zapisy przypisań uprawnień i logi. Potwierdzają dowody poprzez wywiady, narzędzia PAM, usługi katalogowe i próbki logów.

W przypadku praw dostępu Zenith Controls wskazuje, że audytorzy próbkują wnioski o dostęp użytkowników, weryfikują udokumentowane zatwierdzenia i potwierdzają, że IT nadało wyłącznie zatwierdzony dostęp. Porównują również role użytkowników z faktycznymi prawami, sprawdzając, czy egzekwowana jest zasada najmniejszych uprawnień. W przypadku rejestrowania audytorzy sprawdzają zakres rejestrowania, typy zdarzeń, okresy przechowywania, zabezpieczenia i rzeczywiste wpisy w logach. Oceniają, czy nieudane logowania, dostęp do danych wrażliwych i zmiany konfiguracji są przechwytywane i przeglądane.

Dobry pakiet dowodowy „break glass” obejmuje:

• Zatwierdzony wniosek o dostęp awaryjny
• Kontekst incydentu albo niedostępności
• Tożsamość użytkownika aktywującego dostęp
• Tożsamość zatwierdzającego
• Czas rozpoczęcia i zakończenia
• Dowód MFA albo uwierzytelniania
• Nagranie sesji albo log poleceń
• Logi systemowe i alert SIEM
• Wprowadzone zmiany
• Potwierdzenie resetu danych uwierzytelniających
• Przegląd po użyciu
• Ocenę dostępu do danych
• Ocenę obowiązku zgłoszenia regulacyjnego
• Działania korygujące, jeżeli cokolwiek zawiodło

Jeżeli ćwiczenie nie potrafi wygenerować takiego pakietu, kontrola nie jest gotowa do audytu.

Ukryta słabość: uprzywilejowany dostęp stron trzecich

Wiele organizacji lepiej zarządza administratorami będącymi pracownikami niż administratorami dostawców. W środowiskach chmurowych, SaaS, fintech i usług zarządzanych powinno być odwrotnie.

NIS2 Article 21 obejmuje bezpieczeństwo łańcucha dostaw oraz relacje z bezpośrednimi dostawcami i dostawcami usług. DORA Articles 28 to 30 idą dalej w przypadku podmiotów finansowych, wymagając strategii ryzyka stron trzecich ICT, rejestrów umów na usługi ICT, due diligence, oceny ryzyka koncentracji, praw audytu, praw rozwiązania umowy, strategii wyjścia oraz umownych środków bezpieczeństwa.

Uprzywilejowany dostęp dostawców powinien być objęty zakresem PAM, jeżeli dostawca może administrować środowiskiem produkcyjnym, wspierać funkcje krytyczne lub ważne, uzyskiwać dostęp do danych osobowych, modyfikować konfiguracje bezpieczeństwa, zarządzać kopiami zapasowymi, wdrażać kod albo obsługiwać narzędzia monitorowania.

Clarysec zwykle oczekuje, że kontrole uprzywilejowanego dostępu dostawców będą obejmować:

• Imiennych użytkowników dostawcy, a nie współdzielone konta dostawcy
• Umowne wymagania bezpieczeństwa dotyczące dostępu uprzywilejowanego
• MFA i bezpieczny dostęp zdalny
• Ograniczone czasowo okna dostępu
• Zatwierdzenie klienta dla dostępu awaryjnego
• Rejestrowanie sesji albo równoważne ścieżki audytowe
• Natychmiastowe cofnięcie dostępu przy zmianach personelu
• Obowiązki współpracy przy incydentach
• Przechowywanie dowodów dostosowane do potrzeb audytowych klienta
• Plan wyjścia dotyczący usunięcia dostępu dostawcy

Rezultaty NIST CSF 2.0 dotyczące łańcucha dostaw są tutaj silnie zbieżne. Wymagają ról i odpowiedzialności dostawców, priorytetyzacji dostawców według krytyczności, wymagań w umowach, due diligence, ciągłego monitorowania, udziału dostawców w planowaniu incydentowym oraz planów ryzyka po zakończeniu umowy.

Jeżeli konto dostawcy usług zarządzanych jest zwolnione z wewnętrznego przepływu pracy PAM, nie jest to wygoda. To wyjątek wysokiego ryzyka, który powinien znaleźć się w rejestrze ryzyk, rejestrze dostawców i przeglądzie dostępu.

Typowe ustalenia dotyczące PAM i „break glass” w 2026 r.

W projektach Clarysec ustalenia rzadko są zaskakujące. Zwykle są kombinacją dobrych intencji, presji operacyjnej i niekompletnych dowodów.

Najczęstsze ustalenia to:

• Konta typu „break glass” istnieją, ale nie są ujęte w inwentarzu kont uprzywilejowanych.
• Konta awaryjne są wyłączone ze standardowych przeglądów dostępu.
• Organizacja nie potrafi wykazać, kto użył konta awaryjnego.
• Konto nie zostało zresetowane po użyciu.
• Sesje uprzywilejowane są rejestrowane, ale polecenia nie.
• Logi istnieją lokalnie, ale nie są chronione przed użytkownikami uprzywilejowanymi.
• Konta root w chmurze nie są testowane.
• Procesy odzyskiwania MFA są nieudokumentowane.
• Dostęp uprzywilejowany dla potoków CI/CD i kont serwisowych jest ignorowany.
• Dostęp wsparcia stron trzecich omija wewnętrzne zatwierdzanie.
• Zatwierdzenie dostępu istnieje w wiadomościach czatu, ale nie jest przechowywane jako dowód audytowy.
• Zakończenie współpracy usuwa pocztę elektroniczną i VPN, ale nie prawa administratora SaaS.
• DPO nie jest angażowany, gdy dostęp uprzywilejowany może ujawnić dane osobowe.
• Procedury operacyjne reagowania na incydenty nie zawierają punktów decyzyjnych dotyczących zgłoszeń NIS2, DORA albo GDPR.

Każde ustalenie można obsłużyć poprzez postępowanie z ryzykiem zgodnie z ISO/IEC 27001:2022. Zidentyfikuj ryzyko, przypisz właściciela, wybierz środki kontrolne, zaktualizuj Deklarację stosowania, wdroż plan postępowania z ryzykiem i zachowaj udokumentowane dowody. Na tym polega siła wykorzystania SZBI zamiast rozproszonego zestawu zadań bezpieczeństwa.

Jak wygląda dobry model

Dojrzały model operacyjny PAM i „break glass” ma pięć powtarzalnych rutyn.

Po pierwsze, inwentaryzuj dostęp uprzywilejowany co miesiąc albo w sposób ciągły. Uwzględnij administratorów będących ludźmi, konta serwisowe, konta awaryjne, role chmurowe, tożsamości CI/CD, użytkowników baz danych, narzędzia uprzywilejowane oraz administratorów stron trzecich.

Po drugie, egzekwuj zasadę najmniejszych uprawnień poprzez role, podnoszenie uprawnień just-in-time i zatwierdzenia. Stałe uprawnienia powinny być rzadkie, uzasadnione i przeglądane częściej niż standardowy dostęp użytkowników.

Po trzecie, monitoruj zachowanie uprzywilejowane. Rejestruj uwierzytelnianie, czas trwania sesji, użycie MFA, polecenia, zmiany konfiguracji, eksporty danych, nieudane próby, eskalację uprawnień oraz uruchamianie narzędzi uprzywilejowanych.

Po czwarte, testuj konta typu „break glass” przed sytuacją awaryjną. Konto typu „break glass”, które nigdy nie było testowane, jest założeniem, a nie kontrolą.

Po piąte, raportuj do kierownictwa. Zarówno NIS2, jak i DORA podnoszą cyberbezpieczeństwo i ryzyko ICT do odpowiedzialności organu zarządzającego. Zarząd nie potrzebuje każdego logu poleceń, ale potrzebuje metryk: liczby kont uprzywilejowanych, przeterminowanych przeglądów, aktywacji awaryjnych, kont administratorów dostawców, nieudanych testów, krytycznych wyjątków i statusu działań naprawczych.

Tutaj zestaw narzędzi Clarysec staje się praktyczny. Biblioteka polityk dostarcza język ładu zarządczego. Zenith Blueprint dostarcza sekwencję wdrożenia. Zenith Controls dostarcza mapowanie zgodności przekrojowej, relacje między kontrolami, normy wspierające i metodykę audytu.

Kolejne kroki: przekształć dostęp awaryjny w odporność gotową do audytu

Jeżeli Twoja organizacja nie testowała dostępu typu „break glass” w ostatnich 90 dniach, zacznij od tego. Nie zaczynaj od warsztatu wyboru narzędzia. Zacznij od dowodów.

1. Zbuduj albo zaktualizuj inwentarz kont uprzywilejowanych.
2. Zidentyfikuj każde konto typu „break glass” i każdą awaryjną ścieżkę administracyjną.
3. Zmapuj każde konto na właściciela biznesowego, właściciela systemu i wpływ na dane.
4. Potwierdź pokrycie polityką, korzystając z Polityki zarządzania kontami użytkowników i uprawnieniami Polityka zarządzania kontami użytkowników i uprawnieniami Clarysec albo Polityki zarządzania kontami użytkowników i uprawnieniami dla MŚP Polityka zarządzania kontami użytkowników i uprawnieniami - MŚP.
5. Użyj Zenith Blueprint Zenith Blueprint, faza „Kontrole w działaniu”, kroki 19, 20, 22 i 16, aby połączyć dostęp uprzywilejowany, narzędzia uprzywilejowane, przeglądy cyklu życia i zakończenie współpracy.
6. Użyj Zenith Controls Zenith Controls, aby zmapować środki kontrolne ISO/IEC 27002:2022 8.2, 5.18 i 8.15 na oczekiwania dowodowe NIS2, DORA, GDPR i NIST.
7. Przeprowadź ćwiczenie dowodowe „break glass” i zarejestruj wyniki.
8. Dodaj luki do planu postępowania z ryzykiem i śledź działania naprawcze aż do zamknięcia.

Dostęp uprzywilejowany to władza. Dostęp typu „break glass” to władza awaryjna. W 2026 r. organizacje, które sprawnie odzyskają kontrolę po ransomware, awariach chmury i awariach tożsamości, będą tymi, które potrafią wykazać, że dostęp awaryjny był kontrolowany przed kryzysem, w jego trakcie i po nim.

Clarysec może pomóc zbudować ten dowód — od polityki, przez mapowanie kontroli, po dowody gotowe do audytu. Zacznij od Zenith Blueprint, połącz go z Polityką zarządzania kontami użytkowników i uprawnieniami oraz Polityką kontroli dostępu, a następnie użyj Zenith Controls, aby wykazać, jak Twój program PAM wspiera ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 2019.