Identity Security w praktyce: co audytor sprawdza w pierwszej kolejności

Programy bezpieczeństwa często zaczynają od diagramów sieci i agentów EDR. Zewnętrzni audytorzy — ISO 27001, NIS2, DORA lub due diligence klienta — zwykle zaczynają gdzie indziej: kto ma dostęp do czego, którą ścieżką, za jaką zgodą i czy udowodnisz to za ostatni kwartał. Tożsamość to płaszczyzna sterowania, nie podrozdział IT. Gdy tożsamość jest słaba, każda inna kontrola jest mniej wiarygodna: SIEM nie odróżni legalnego admina od nieaktywnego konta vendora, które powinno być wyłączone.

Byliśmy na otwarciach audytu, gdzie CISO prezentował dopracowany ISMS, a lead auditor odpowiadał: „Dziękuję — pokażcie trzech zakończonych kontraktorów i kiedy odebrano im dostęp.” To pytanie ustawia ton tygodnia. Organizacje przechodzące gładko rzadko mają najwięcej narzędzi. Mają zgodność statusu HR, provisioningu IAM i numerów ticketów bez improwizacji.

Trzy pierwsze próbki od audytora

Inwentarz dostępu uprzywilejowanego jest pierwszy. Audytorzy nie akceptują „mamy mało adminów”. Chcą listy kont z podwyższonymi prawami w AD, Entra ID/Azure, rolach IAM chmury, uprawnieniach sysadmin baz i konsolach admina SaaS — z datą ostatniego użycia i nazwanym właścicielem. Stały Global Administrator bez PIM/JIT jest rutynowo flagowany. Jeden klient produkcyjny znalazł czternaście uśpionych kont Global Admin z migracji 2019; trzy logowały się w ostatnim miesiącu bez udokumentowanego powodu.

Pokrycie MFA i wyjątki to druga próbka. „MFA włączone” na poziomie tenantu to nie to samo co wymuszenie na każdej ścieżce logowania. Audytorzy proszą o procent użytkowników z MFA odpornym na phishing tam, gdzie platforma to wspiera, plus każdy udokumentowany wyjątek: legacy protokoły, konta serwisowe, break-glass. Każdy wyjątek potrzebuje kontroli kompensacyjnej, daty wygaśnięcia i approvera. Arkusz „tymczasowych” wyjątków odnawianych kwartalnie przez dwa lata to czekająca poważna niezgodność.

Dowody joiner–mover–leaver zamykają trio. Audytorzy losują trzy zatrudnienia, zmiany ról i odejścia z ostatnich dziewięćdziesięciu dni. Dla każdego śledzą ticket HR → request provisioning → nadany dostęp → odebrany dostęp. Luki między datą offboardingu HR a disable konta — nawet czterdzieści osiem godzin — to jedne z najczęstszych poważnych findings w B2B IT. W jednym przypadku były inżynier sprzedaży zachował VPN przez jedenaście dni, bo „IT czekało na zwrot laptopa”. Laptop nie miał znaczenia dla credential VPN.

Jak wygląda „dobrze” bez kolejnego portalu

Dojrzała identity security jest celowo nudna. Grupy RBAC mapują funkcje, nie wygodę osób. Recertyfikacja dostępu ma kalendarz i nazwanych właścicieli danych, którzy naprawdę klikają approve/revoke — nie auto-approve po mailach. Sesje uprzywilejowane są logowane; konta break-glass są offline, policzone na palcach jednej ręki i ćwiczone kwartalnie w tabletop. Narzędzia się różnią — model dowodowy nie.

Rekomendujemy jedną macierz kontroli tożsamości: cel kontroli, system rejestru, źródło logów, kadencja przeglądu, właściciel. Gdy audytor pyta „jak odbieracie dostęp vendorowi w 24h od końca umowy”, otwierasz jeden wiersz — nie pięć wątków Slack i pamięć managera. Macierz to nie biurokracja; to mapa, dzięki której nowy CISO lub MSP przejmie bez utraty gotowości audytowej.

Dobra tożsamość to też time-to-revoke jako mierzone SLA, nie aspiracja w polityce. Jeśli HR oznacza kogoś jako terminated o 17:00 w piątek, kiedy IAM pokazuje disabled? Wykres miesięczny. Skoki korelują z reorganizacjami i M&A — dokładnie wtedy audytorzy spodziewają się luk.

Typowe błędy B2B

Współdzielone skrzynki jako pseudo-użytkownicy do RDP/VPN pojawiają się w niemal każdym przeglądzie mid-market. Nie trzymają MFA czysto, zacierają odpowiedzialność i przeżywają reorganizacje, bo „wszyscy znają hasło”. Konta vendor bez daty końca umowy w IAM to kolejny standard: integrator API magazynowego z 2021 nadal ma read do produkcyjnej bazy, bo nikt nie przejął offboardingu po zamknięciu projektu.

Lokalny administrator na laptopach „bo helpdesk jest szybszy” podważa zaufanie do urządzeń. Cloud IAM sprawl — Owner na poziomie projektu dla wygody, klucze SA w repozytoriach — w równym stopniu. Każdy błąd da się naprawić, ale nie samym PDF polityki. Automatyzuj disable przy zmianie statusu HR, wymuszaj PIM dla admina chmury, blokuj legacy auth i mierz kurczenie się wyjątków kwartał do kwartału.

Scenariusz: nadzór ISO vs kwestionariusz klienta

Dwa eventy assurance w tym samym miesiącu. Nadzór ISO próbkuje JML i privileged access — ciężko na dowodach i procesie. Kwestionariusz enterprise klienta pyta o SSO, MFA na rolach admin i zarządzanie dostępem third-party do produkcji. Jeśli odpowiedzi się różnią, bo dane tożsamości żyją w trzech systemach, zaprzeczysz sobie pod presją czasu.

Remedium to jedno źródło prawdy: eksporty z IdP, ID ticketów, sign-offy access review. Klient fintech zunifikował to w kwartalny „identity pack” dla audytu wewnętrznego, DD klienta i regulacji. Czas przygotowania spadł z tygodni do dni — nie przez GRC-unicorn, lecz przez przestanie odbudowywać tę samą historię od zera.

Szerokie assurance

Findings tożsamości kaskadują. Słabe JML unieważnia zakres pentestu, gdy tester używa starego konta vendora. Słabe MFA na ścieżkach admin oznacza, że sukces red team przypisuje się „zaawansowanemu atakowi”, gdy przyczyną jest stałe uprzywilejowanie. Silna tożsamość zmniejsza powierzchnię ataku i nadaje sens testom technicznym.

Przy NIS2, DORA lub komitecie ryzyka zacznij od dowodów identity, zanim kupisz kolejny skaner. Skanery znajdują dziury; tożsamość dowodzi, że wiesz, kto przez nie może przejść. Więcej w praktyce Audyt i bezpieczeństwo informacji — mapowanie kontroli na Twój IdP i ticketing oraz runbooki do wykonania, nie prezentacje.

Więcej na ten temat

NIS2 a infrastruktura: co musi być w runbooku

NIS2 to nie folder polityk. Operatorzy potrzebują runbooków: klasyfikacja incydentu, wczesne ostrzeżenie 24h, dowód restore backupu i eskalacja…