Kontrole dostępu ISO 27001 Annex A: jak wdrożyć klauzule, które sprawdzają audytorzy
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.
- 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.
- Pokrycie uwierzytelniania (A.8.5). Potwierdź wymuszenie MFA i udokumentuj wyjątki, których nie da się zamknąć.
- Dostęp uprzywilejowany (A.8.2). Znajdź stały dostęp administracyjny, uzasadnij go albo usuń i ustaw ciaśniejszy cykl przeglądu.
- Cykl życia praw dostępu (A.5.18). Udowodnij joiner-mover-leaver dowodami i przeprowadź udokumentowany przegląd dostępów.
- Polityka i ograniczenie (A.5.15, A.8.3). Upewnij się, że pisemna polityka odpowiada temu, co katalog faktycznie wymusza.
- 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ą.
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

+48 783 762 997
julian@unshadowit.com

