Dostęp to decyzja biznesowa, nie ustawienie systemu

NIS 2 i ENISA o polityce dostępu oraz zarządzaniu uprawnieniami

W poprzednich wpisach tej serii przechodziliśmy przez ryzyko, incydenty, ciągłość działania, kryptografię i bezpieczeństwo ludzi w organizacji. Teraz wchodzimy w jeden z najbardziej praktycznych i jednocześnie najbardziej zaniedbywanych obszarów bezpieczeństwa.

Dostęp.

Nie w znaczeniu technicznym, jako pojedyncze konto czy uprawnienie nadane w systemie.
Tylko w znaczeniu organizacyjnym, operacyjnym i regulacyjnym.

Bo z perspektywy NIS 2 pytanie nie brzmi już:
czy użytkownik ma dostęp?

Pytanie brzmi:
dlaczego go ma, kto go zatwierdził, jak długo powinien go mieć i czy organizacja potrafi to wykazać?

Wytyczne ENISA poświęcają temu cały rozdział. I bardzo wyraźnie pokazują, że kontrola dostępu nie jest ustawieniem systemowym. Jest decyzją biznesową opartą na ryzyku, klasyfikacji aktywów i jasno określonych zasadach odpowiedzialności.

Ten tekst otwiera 3-częściowy blok o kontroli dostępu w NIS 2.
W tej części skupiamy się na dwóch fundamentach:

• polityce kontroli dostępu,
• zarządzaniu uprawnieniami.

W kolejnych wpisach przejdziemy do:

• kont uprzywilejowanych i systemów administracyjnych,
• identyfikacji, uwierzytelniania i MFA.

Kontrola dostępu zaczyna się od polityki

ENISA wychodzi z prostego założenia: dostęp do systemów i informacji nie może być wynikiem przyzwyczajenia, wygody albo „tak się u nas robi od lat”.

Musi wynikać z polityki.

Organizacja powinna ustanowić, udokumentować i wdrożyć politykę logicznej i fizycznej kontroli dostępu do sieci i systemów informacyjnych. Taka polityka ma być oparta zarówno na wymaganiach biznesowych, jak i na wymaganiach bezpieczeństwa.

To bardzo ważne rozróżnienie.

Dostęp nie jest przyznawany wyłącznie dlatego, że ktoś „go potrzebuje do pracy”.
Musi być przyznawany w sposób, który uwzględnia także ryzyko dla organizacji.

ENISA podkreśla, że polityka kontroli dostępu powinna:

• być udokumentowana,
• być komunikowana odpowiednim interesariuszom,
• zawierać jasne zasady korzystania z uprawnień.

To oznacza, że kontrola dostępu nie może istnieć jedynie w konfiguracji systemu albo w głowie administratora. Musi być opisana, zrozumiała i powiązana z odpowiedzialnością.

Polityka dostępu nie dotyczy tylko pracowników

Jednym z cenniejszych elementów wytycznych ENISA jest to, że polityka dostępu nie jest ograniczana wyłącznie do etatowych użytkowników.

Powinna obejmować:

• pracowników,
• gości,
• dostawców,
• usługodawców,
• podmioty zewnętrzne,
• a także procesy systemowe.

To ważne, bo wiele organizacji porządkuje uprawnienia pracowników, ale jednocześnie pozostawia obszary zewnętrzne w modelu „jakoś to działa”.

Tymczasem ENISA wymaga, aby polityka dostępu obejmowała również dostęp realizowany przez procesy sieciowe i systemowe. Oznacza to, że nie chodzi wyłącznie o człowieka logującego się do systemu, lecz także o usługi, urządzenia i mechanizmy komunikujące się między sobą.

Każdy z tych bytów powinien mieć określone zasady dostępu, odpowiedni poziom ograniczeń oraz właściwą autoryzację.

Dostęp ma być zgodny z rolą, ryzykiem i klasyfikacją aktywów

ENISA wyraźnie wskazuje, że reguły dostępu powinny być projektowane z uwzględnieniem:

• wymagań biznesowych,
• wyników oceny ryzyka,
• klasyfikacji aktywów,
• potrzeb bezpieczeństwa fizycznego i logicznego,
• rodzaju połączeń i środowiska, w którym dostęp jest realizowany.

To oznacza, że polityka dostępu nie może być uniwersalna i płaska.

Inne wymagania będą dotyczyć:

• zwykłego użytkownika biurowego,
• administratora,
• zewnętrznego serwisanta,
• aplikacji systemowej,
• procesu integracyjnego między systemami,
• użytkownika pracującego zdalnie,
• osoby łączącej się z innej lokalizacji lub przez inny typ sieci.

Wytyczne zwracają też uwagę na możliwość stosowania bardziej dynamicznych modeli dostępu, uwzględniających np. kontekst połączenia, środowisko lub zachowanie użytkownika. To pokazuje, że polityka dostępu nie musi być wyłącznie statycznym zbiorem uprawnień. Może być mechanizmem reagującym na realne warunki.

Need-to-know i least privilege to nie slogany

W części praktycznej ENISA wskazuje dwa podstawowe filary kontroli dostępu:

Need-to-know

Użytkownik powinien mieć dostęp wyłącznie do tych informacji, które są mu rzeczywiście potrzebne do wykonania zadań.

Need-to-use

Użytkownik powinien mieć dostęp tylko do tej infrastruktury i tych usług, dla których istnieje realna potrzeba użycia.

Wytyczne odnoszą się także do zasady najmniejszych uprawnień, czyli podejścia:

wszystko jest co do zasady zabronione, chyba że zostało wyraźnie dopuszczone

To bardzo istotna różnica wobec modelu odwrotnego, w którym wszystko jest dostępne, dopóki ktoś czegoś nie zablokuje.

W praktyce właśnie tutaj organizacje najczęściej przegrywają kontrolę nad dostępem.
Nie dlatego, że nie mają procedur.
Tylko dlatego, że przez lata uprawnienia narastają szybciej niż są porządkowane.

Dostęp „na wszelki wypadek”, dostęp pozostawiony po zmianie roli, dostęp odziedziczony po poprzednim projekcie, dostęp zachowany po zakończeniu współpracy z dostawcą — to właśnie z takich drobnych wyjątków powstaje realne ryzyko.

Zarządzanie uprawnieniami to proces, nie jednorazowa czynność

Druga część tego obszaru dotyczy samego zarządzania prawami dostępu.

ENISA wymaga, aby organizacja nie tylko nadawała, ale również:

• modyfikowała,
• odbierała,
• dokumentowała
  uprawnienia zgodnie z polityką dostępu.

Brzmi prosto, ale w praktyce oznacza to konieczność zbudowania pełnego procesu lifecycle access management.

Ten proces powinien obejmować zarówno moment wejścia użytkownika do organizacji, jak i każdą zmianę jego roli, zakresu obowiązków, rodzaju współpracy albo zakończenia zatrudnienia.

Dostęp nie może być przydzielany ad hoc.
Powinien wynikać z procesu.

Kto zatwierdza dostęp i na jakiej podstawie?

ENISA bardzo mocno akcentuje, że dostęp musi być autoryzowany przez odpowiednie osoby.

To niezwykle ważne, bo samo techniczne utworzenie konta nie jest jeszcze prawidłowym nadaniem uprawnień.

Proces przyznawania praw dostępu powinien:

• opierać się na potrzebie biznesowej,
• uwzględniać politykę kontroli dostępu,
• być zgodny z zasadą need-to-know,
• respektować zasadę least privilege,
• brać pod uwagę rozdział obowiązków.

Wytyczne wskazują również, że warto oddzielać role zatwierdzania i wdrażania uprawnień. To ważny element ograniczania ryzyka błędów, nadużyć i konfliktu ról.

W dobrze działającym modelu nadanie dostępu nie jest po prostu czynnością administracyjną. Jest decyzją, którą można uzasadnić, zatwierdzić i odtworzyć.

Trzeci podmiot też jest użytkownikiem ryzyka

Jednym z najbardziej praktycznych elementów tego rozdziału jest podejście do dostępu stron trzecich.

Dostawcy, serwisanci, integratorzy czy usługodawcy bardzo często mają szeroki dostęp do systemów organizacji, a jednocześnie pozostają poza codzienną kontrolą operacyjną.

ENISA wskazuje bardzo wyraźnie, że dostęp stron trzecich powinien być:

• ograniczony co do zakresu,
• ograniczony w czasie,
• przeglądany,
• odpowiednio dokumentowany.

To podejście jest bardzo konkretne: jeżeli dostęp jest potrzebny tymczasowo, powinien być czasowy. Jeżeli dotyczy określonego działania, nie powinien obejmować całego środowiska. Jeżeli jest aktywny, powinien podlegać regularnej weryfikacji.

Dodatkowo strony trzecie powinny rozumieć swoje obowiązki i potwierdzać odpowiedzialność za korzystanie z nadanych uprawnień.

Rejestr uprawnień to nie biurokracja. To dowód kontroli

ENISA wymaga prowadzenia rejestru przyznanych praw dostępu.

Taki rejestr powinien obejmować m.in.:

• użytkowników,
• role,
• poziomy dostępu,
• daty zmian,
• historię przyznań i odebrania uprawnień.

To nie jest formalność. To podstawa dowodowa.

Bez centralnego, aktualnego rejestru organizacja nie jest w stanie odpowiedzieć na podstawowe pytania:

• kto ma dziś dostęp,
• kto ten dostęp zatwierdził,
• kiedy został nadany,
• kiedy powinien wygasnąć,
• czy nadal jest uzasadniony.

Wytyczne podkreślają też znaczenie logowania działań związanych z zarządzaniem dostępem. Organizacja powinna rejestrować:

• kto nadał dostęp,
• kto go zmienił,
• kiedy to nastąpiło,
• jaki był zakres zmiany.

W praktyce to właśnie ten poziom śladu audytowego odróżnia kontrolę nad dostępem od samego utrzymywania kont.

Uprawnienia trzeba regularnie przeglądać

ENISA nie zostawia wątpliwości: prawa dostępu powinny być przeglądane regularnie i aktualizowane w odpowiedzi na zmiany organizacyjne.

Wytyczne wskazują na konieczność przeglądów co najmniej raz w roku, a także zwracają szczególną uwagę na dwie sytuacje:

• zmianę zatrudnienia lub roli użytkownika,
• uprawnienia uprzywilejowane.

To bardzo sensowne podejście.
Najwięcej nieprawidłowości w dostępie nie wynika z pierwotnego błędu przy nadaniu konta, tylko z braku aktualizacji po zmianie.

Użytkownik, który zmienił dział, projekt albo odpowiedzialność, nie powinien automatycznie zachowywać wszystkich wcześniejszych uprawnień. Podobnie pracownik odchodzący z organizacji albo dostawca kończący współpracę.

Przeglądy dostępu nie są więc przeglądem dla audytu.
Są mechanizmem utrzymywania realnej kontroli nad tym, kto może zrobić co w systemie.

Gdzie organizacje najczęściej tracą kontrolę

Choć wytyczne ENISA są formalne, ich praktyczne przesłanie jest bardzo czytelne.

Organizacje najczęściej tracą kontrolę nad dostępem wtedy, gdy:

• polityka istnieje tylko w dokumencie,
• uprawnienia narastają szybciej niż są przeglądane,
• dostawcy otrzymują za szeroki dostęp,
• proces autoryzacji jest niejasny,
• nie istnieje centralny rejestr,
• logi są niepełne albo nie są wykorzystywane,
• nikt nie weryfikuje, czy dostęp nadal jest potrzebny.

A to oznacza, że problem kontroli dostępu nie jest zwykle problemem technologicznym.

Jest problemem organizacyjnym.

Co ten rozdział oznacza w praktyce

W świecie NIS 2 dostęp przestaje być sprawą administratora.
Staje się jednym z podstawowych mechanizmów zarządzania ryzykiem.

To właśnie dlatego ENISA tak mocno wiąże politykę dostępu z:

• oceną ryzyka,
• klasyfikacją aktywów,
• potrzebami biznesowymi,
• odpowiedzialnością organizacyjną,
• dokumentowaniem decyzji.

Dobrze zaprojektowany model dostępu odpowiada na pięć prostych pytań:

• kto ma dostęp,
• do czego,
• dlaczego,
• na jak długo,
• i kto to zatwierdził.

Jeżeli organizacja nie umie na nie odpowiedzieć, to nie ma kontroli dostępu.
Ma jedynie aktywne konta.

Co dalej w serii NIS 2

W tej części zajęliśmy się fundamentem, czyli polityką dostępu i zarządzaniem uprawnieniami.

W kolejnym wpisie przejdziemy do najbardziej wrażliwego obszaru całego rozdziału:

kont uprzywilejowanych i systemów administracyjnych

Czyli do pytania, co się dzieje wtedy, gdy użytkownik ma nie tylko dostęp, ale realną władzę nad systemem.

Twoje bezpieczeństwo to nasza pasja! 🌐 Jeśli interesuje Cię ochrona danych osobowych, bezpieczeństwo informacji czy cyberbezpieczeństwo, zajrzyj na stronę CAB oraz Platformę Cyberbezpieczeństwa. Szukasz informacji o ochronie sygnalistów? 📢 Sprawdź stronę Kanału Zgłoszeniowego. Czekają tam praktyczne porady i ekspercka wiedza!