Kontrole dostępu ISO 27001 Annex A: jak wdrożyć klauzule, które sprawdzają audytorzy

by
Dawid Winiarski
Last update:
July 17, 2026

ISO 27001 certyfikuje system zarządzania bezpieczeństwem informacji. Większość standardu to proces: ocena ryzyka, Statement of Applicability, przegląd zarządzania, ciągłe doskonalenie. Zestaw kontroli mieszka w Annex A, który w wersji 2022 ma 93 kontrole w czterech tematach: 37 organizacyjnych, 8 dotyczących ludzi, 14 fizycznych i 34 technologicznych.

Znacząca część tych kontroli to kontrole dostępu i skupiają się w dwóch tematach: organizacyjnym (kontrole A.5) i technologicznym (kontrole A.8). Są też wśród tych kontroli, które audytor może przetestować bezpośrednio. Możesz napisać mocną politykę kontroli dostępu i nadal wywołać niezgodność, jeśli katalog jej nie odzwierciedla w momencie, gdy audytor go próbkuje.

Certyfikacja działa w trzyletnim cyklu: wstępny dwuetapowy audyt (Stage 1 przegląda dokumentację i gotowość, Stage 2 ocenia wdrożenie na miejscu), coroczne audyty nadzorcze w pierwszym i drugim roku oraz pełna recertyfikacja co trzy lata. Dowody dostępu muszą więc być prawdziwe cały czas między audytami, a nie składane naprędce w tygodniu przed każdą wizytą nadzorczą.

  • Znacząca część kontroli ISO 27001 Annex A:2022 to kontrole dostępu, skupione w tematach organizacyjnym (A.5) i technologicznym (A.8), i są wśród tych, które audytor może przetestować bezpośrednio.
  • Możesz napisać mocną politykę kontroli dostępu i nadal wywołać niezgodność, jeśli katalog jej nie odzwierciedla w momencie próbkowania przez audytora.
  • Certyfikacja działa w trzyletnim cyklu z corocznymi audytami nadzorczymi, więc dowody dostępu muszą być prawdziwe cały czas między audytami, a nie składane naprędce w tygodniu przed każdą wizytą.
  • A.5.18 (prawa dostępu) to kontrola, która ma największą szansę nie przejść próbkowania, zwykle dlatego, że osoba odchodząca zachowała dostęp do aplikacji spoza katalogu.
  • Czytane razem, kontrole dostępu wymagają tego samego, czego wymaga każdy framework: znanej populacji tożsamości, silnego uwierzytelniania, least privilege, kontrolowanego dostępu administracyjnego i procesu przeglądu i usuwania, który da się udowodnić.
  • Praktyczna kolejność pracy zaczyna się od inwentarza tożsamości i idzie dalej, bo wszystko inne jest próbkowane względem niego.

kontrole dostępu, jedna po drugiej

A.5.15 kontrola dostępu

Ustanów i stosuj zasady przyznawania i ograniczania dostępu, oparte na wymaganiach biznesowych i bezpieczeństwa. To twoja polityka kontroli dostępu: kto dostaje dostęp do czego, na jakiej podstawie i jak jest to autoryzowane. Wdrożenie: pisemna polityka powiązana z rolami i wrażliwością danych, z least privilege jako domyślnym ustawieniem. Dowód: sama polityka plus dowód, że jest stosowana: dostęp, który mapuje się na udokumentowane role, a nie granty ad hoc.

A.5.16 zarządzanie tożsamością

Zarządzaj pełnym cyklem życia tożsamości, ludzkich i maszynowych, we wszystkich systemach. Wdrożenie: jeden, aktualny inwentarz każdej tożsamości, w tym kont serwisowych i tożsamości maszynowych, każda powiązana z właścicielem. Dowód: inwentarz tożsamości pokazujący, że obejmuje więcej niż główny katalog. Konta serwisowe udokumentowane gdzie indziej niż w czyjejś pamięci to częsta luka w tym miejscu.

A.5.17 informacje uwierzytelniające

Kontroluj przydzielanie i zarządzanie informacjami uwierzytelniającymi, czyli danymi logowania i sekretami. Wdrożenie: zarządzane wydawanie danych logowania, bezpieczne przechowywanie, brak współdzielonych haseł dla indywidualnej rozliczalności i rotacja tam, gdzie ma to znaczenie. Dowód: proces zarządzania danymi logowania i brak współdzielonych loginów tam, gdzie działania muszą być przypisywalne do konkretnej osoby.

A.5.18 prawa dostępu

Przyznawaj, przeglądaj i usuwaj prawa dostępu zgodnie z polityką kontroli dostępu, także wtedy, gdy ludzie zmieniają role albo odchodzą. Wdrożenie: proces joiner-mover-leaver, który wiarygodnie przyznaje, dostosowuje i cofa dostęp, oraz okresowe przeglądy dostępów. Dowód: zapisy przyznawania i zakończenia dostępu dla próbki osób oraz zapisy przeglądów dostępów pokazujące, kto co przejrzał i co się zmieniło. To kontrola, która ma największą szansę nie przejść próbkowania, zwykle dlatego, że osoba odchodząca zachowała dostęp do aplikacji spoza katalogu.

A.8.2 uprzywilejowane prawa dostępu

Ogranicz i kontroluj podniesiony dostęp. Wdrożenie: ogranicz, kto ma prawa administracyjne, preferuj eskalację just-in-time albo ograniczoną czasowo zamiast stałego przywileju, i przeglądaj dostęp uprzywilejowany częściej niż standardowy. Dowód: aktualna lista osób z dostępem uprzywilejowanym wraz z uzasadnieniem oraz zapisy przeglądów.

A.8.3 ograniczenie dostępu do informacji

Ogranicz dostęp do informacji zgodnie z polityką kontroli dostępu. Wdrożenie: least privilege na poziomie danych i aplikacji, nie tylko przy logowaniu. Dowód: listy dostępu dla każdego wrażliwego systemu pokazujące ograniczenie według roli.

A.8.5 bezpieczne uwierzytelnianie

Stosuj silne technologie i procedury uwierzytelniania. Wdrożenie: uwierzytelnianie wieloskładnikowe (MFA) dla wszystkich użytkowników i systemów, z udokumentowanymi, skompensowanymi wyjątkami tam, gdzie naprawdę nie da się go wymusić. Dowód: konfiguracja MFA pokazująca wymuszenie i pokrycie, włącznie z niewygodnymi obszarami: adminami, dostępem zdalnym i logowaniami poza single sign-on.

A.8.15 logowanie i A.8.16 monitorowanie działań

Rejestruj zdarzenia, w tym dostęp, i monitoruj anomalie. Wdrożenie: logowanie zdarzeń uwierzytelniania i dostępu dla systemów objętych zakresem, przechowywanie ich i obserwowanie anomalii, które mają znaczenie. Dowód: próbki logów i dowód, że ktoś je przegląda.

Czytane razem, te kontrole wymagają tego samego, czego wymaga każdy framework: znanej populacji tożsamości, silnego uwierzytelniania, least privilege, kontrolowanego dostępu administracyjnego i procesu przeglądu i usuwania, który da się udowodnić.

gdzie firmom brakuje

Porażki dostępowe w ISO zwykle biorą się z kontroli, które istnieją na papierze, ale nie przetrwają próbkowania. Polityka mówi, że przeglądy odbywają się co kwartał, ale nie ma zapisu z ostatnich dwóch. A.5.18 mówi, że dostęp jest usuwany, kiedy ludzie odchodzą, ale audytor znajduje byłego kontraktora nadal aktywnego w podpiętej aplikacji. A.8.5 mówi, że silne uwierzytelnianie jest wymuszone, ale garstka kont administracyjnych powstała przed polityką. A.5.16 zakłada kompletny obraz tożsamości, ale konta serwisowe siedzą w czyjejś głowie. Każda z tych rzeczy to niezgodność czekająca na wykrycie, i każda zostałaby złapana wcześniej przez aktualną mapę dostępu.

praktyczna kolejność pracy

Przechodzenie przez kontrole w tej kolejności sprawia, że część audytu dotycząca dostępu przechodzi próbkowanie bez zarzutu, bo kontrole są prawdziwe, a nie dlatego, że akurat wyszedł dobry moment.

  1. Inwentarz tożsamości (A.5.16). Zbuduj jedną kompletną, posiadaną listę każdej tożsamości. Wszystko inne jest próbkowane względem niej.
  2. Pokrycie uwierzytelniania (A.8.5). Potwierdź wymuszenie MFA i udokumentuj wyjątki, których nie da się zamknąć.
  3. Dostęp uprzywilejowany (A.8.2). Znajdź stały dostęp administracyjny, uzasadnij go albo usuń i ustaw ciaśniejszy cykl przeglądu.
  4. Cykl życia praw dostępu (A.5.18). Udowodnij joiner-mover-leaver dowodami i przeprowadź udokumentowany przegląd dostępów.
  5. Polityka i ograniczenie (A.5.15, A.8.3). Upewnij się, że pisemna polityka odpowiada temu, co katalog faktycznie wymusza.
  6. Logowanie (A.8.15, A.8.16). Potwierdź, że zdarzenia dostępu są rejestrowane, przechowywane i przeglądane.

Wspólnym wątkiem jest to, że aktualny, dokładny obraz każdej tożsamości i dostępu, jaki trzyma, to dane wejściowe, od których zależy każda z tych kontroli. Zbuduj ten obraz raz, utrzymuj go w zgodzie z prawdą między audytami, a kontrole dostępu przestaną być gonitwą przed każdą wizytą nadzorczą.

Subscribe to unshadowed.

Subscribe to receive the latest blog posts to your inbox and stay up to date with

By subscribing you agree to with our Privacy Policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

let's start with a conversation

Most first conversations start with not quite knowing what you have or where to begin. That's normal, and it's exactly where we're useful.

Tell us what prompted this. An upcoming audit, an incident, a client's security questionnaire, or just a sense that things have gotten messy.

We'll take it from there

Julian Machowski
Head of Technical Sales
+48 783 762 997
julian@unshadowit.com
Let's connect on LinkedIn
Message received. We'll be in touch soon.
Something failed. Try again or call us directly.