DORA dla podmiotów finansowych: playbook kontroli dostępu

kto jest objęty zakresem i kwestia proporcjonalności

DORA to Rozporządzenie (UE) 2022/2554. Obowiązuje bezpośrednio w całej UE od 17 stycznia 2025 r. Ponieważ jest rozporządzeniem, a nie dyrektywą, jego treść stosuje się wprost w każdym państwie członkowskim, bez czekania na transpozycję do prawa krajowego.

Artykuł 2 obejmuje zakresem około dwudziestu kategorii podmiotów finansowych: instytucje kredytowe, instytucje płatnicze i instytucje pieniądza elektronicznego, firmy inwestycyjne, dostawców usług w zakresie kryptoaktywów, zakłady ubezpieczeń i reasekuracji, pośredników, zarządzających funduszami, centralne depozyty papierów wartościowych i inne. Dostawcy usług ICT stron trzecich są objęci zakresem poprzez filar ryzyka stron trzecich i ramy nadzoru. Jeśli prowadzisz technologię dla regulowanego biznesu finansowego w UE, niemal na pewno jesteś objęty zakresem.

DORA skaluje się wraz z wielkością i ryzykiem. Uproszczone ramy zarządzania ryzykiem ICT (Artykuł 16) obejmują wskazane mniejsze podmioty lub podmioty niższego ryzyka, takie jak małe i niepowiązane wzajemnie firmy inwestycyjne, niektóre zwolnione instytucje płatnicze i instytucje pieniądza elektronicznego, małe instytucje pracowniczych programów emerytalnych oraz małych pośredników ubezpieczeniowych działających jako działalność dodatkowa. Reżim uproszczony ma własny artykuł dotyczący kontroli dostępu w RTS, Artykuł 33. Mikroprzedsiębiorstwa otrzymują dodatkowe złagodzenia proporcjonalności w zakresie konkretnych obowiązków. Proporcjonalność przenika całe rozporządzenie, a nie działa jako jedno ogólne zwolnienie, więc pytanie nie brzmi, czy zasady dostępu cię dotyczą, tylko jak szczegółowo musisz je udokumentować, biorąc pod uwagę twój profil.

pięć filarów w skrócie

1. Zarządzanie ryzykiem ICT. Ład organizacyjny i ramy zarządzania ryzykiem: identyfikacja, ochrona, wykrywanie, reagowanie, odzyskiwanie, wyciąganie wniosków. Odpowiedzialność ponosi organ zarządzający. Artykuły 5 do 16.
2. Zarządzanie incydentami ICT, ich klasyfikacja i raportowanie. Proces obsługi incydentów, kryteria klasyfikacji poważnych incydentów oraz obowiązkowe raportowanie do właściwego organu. Artykuły 17 do 23.
3. Testowanie cyfrowej odporności operacyjnej. Program testów dla wszystkich, a dla wskazanych istotnych podmiotów dodatkowo testy penetracyjne oparte na zagrożeniach, przeprowadzane co najmniej raz na trzy lata. Artykuły 24 do 27.
4. Ryzyko stron trzecich ICT. Zarządzanie ryzykiem ICT stron trzecich, kluczowe warunki umowne, rejestr informacji oraz ramy nadzoru nad kluczowymi dostawcami ICT stron trzecich, prowadzone przez Głównego Nadzorcę (Lead Overseer). Artykuły 28 do 44.
5. Wymiana informacji. Dobrowolne porozumienia dotyczące wymiany informacji o cyberzagrożeniach. Zachęcane, nie wymagane. Artykuł 45.

Kontrola dostępu mieści się w filarze pierwszym. Ten przewodnik wchodzi głęboko w ten wycinek, a resztę zostawia na poziomie powyższego skrótu, poza miejscami, gdzie dostęp bezpośrednio łączy się z raportowaniem incydentów i dostępem stron trzecich.

wymogi kontroli dostępu, kontrola po kontroli

Są dwie warstwy. Obowiązek na poziomie 1 zawiera sama DORA, Artykuł 9. Szczegóły znajdują się w standardzie poziomu 2, RTS 2024/1774, Tytuł II, Rozdział II. Artykuł 9(4)(c) wymaga ograniczenia dostępu fizycznego i logicznego do informacji i aktywów ICT wyłącznie do tego, co jest potrzebne do zatwierdzonych funkcji. To jest least privilege. Artykuł 9(4)(d) wymaga silnych mechanizmów uwierzytelniania opartych na odpowiednich standardach. Artykuł 19 dotyczy polityki zasobów ludzkich, Artykuł 20 dotyczy zarządzania tożsamością, a Artykuł 21 to centralny artykuł dotyczący kontroli dostępu. Artykuł 33 odzwierciedla je dla reżimu uproszczonego.

least privilege i need-to-know

Co to znaczy w praktyce. Uprawnienia dostępu przyznaje się na zasadzie need-to-know, need-to-use i least privilege, także dla dostępu zdalnego i awaryjnego. Ludzie mają dostęp, jakiego wymaga ich obecna rola, i nic ponad to. Default-deny, nie default-allow.

Jak to udokumentować. Udokumentowana polityka zarządzania dostępem, która wprost formułuje tę zasadę. Mapowanie ról na uprawnienia. Zapisy provisioningu, które wiążą każde nadanie dostępu z zatwierdzonym wnioskiem i uzasadnieniem biznesowym. Różnica między tym, co ludzie mają, a tym, czego wymaga ich rola, to metryka, którą sprawdzi audytor.

zarządzanie tożsamością oraz nazwane, rozliczalne konta

Co to znaczy w praktyce. Każde działanie da się przypisać do znanej osoby lub systemu. Konta generyczne i współdzielone są ograniczane w miarę możliwości. Użytkowników zawsze da się zidentyfikować po ich działaniach.

Jak to udokumentować. Inwentarz unikalnych tożsamości. Lista pozostałych kont współdzielonych lub generycznych, z uzasadnieniem dla każdego i planem ich ograniczenia. Logi, które przypisują aktywność do nazwanej tożsamości, a nie do etykiety roli takiej jak admin czy service.

rozdzielenie obowiązków

Co to znaczy w praktyce. Dostęp jest zorganizowany tak, że żadna pojedyncza osoba nie ma kombinacji uprawnień, która pozwala jej zarówno wykonać, jak i ukryć wrażliwe działanie. Klasyczny przykład to to samo konto mogące zarówno utworzyć, jak i zatwierdzić płatność.

Jak to udokumentować. Udokumentowana macierz rozdzielenia obowiązków dla wrażliwych procesów. Zestaw reguł toksycznych kombinacji uprawnień. Dowody, że sprzeczne uprawnienia są wykrywane i albo blokowane, albo kompensowane innym mechanizmem kontroli.

zarządzanie kontami: nadanie, zmiana i odebranie

Co to znaczy w praktyce. Jasne role i odpowiedzialności za nadawanie, przeglądanie i odbieranie dostępu: dyscyplina joiner-mover-leaver. RTS wskazuje wprost dwa elementy. Dostęp uprzywilejowany, awaryjny i administracyjny jest nadawany na zasadzie need-to-use lub doraźnie dla wszystkich systemów ICT, a nie na stałe. Uprawnienia dostępu są odbierane bez zbędnej zwłoki, gdy kończy się zatrudnienie lub gdy dostęp przestaje być potrzebny.

Jak to udokumentować. Procedura joiner-mover-leaver ze wskazanymi właścicielami. Zgłoszenia zakończenia zatrudnienia pokazujące znaczniki czasu odebrania dostępu w zestawieniu z datą odejścia, żeby wykazać spełnienie standardu bez zbędnej zwłoki. Rejestr nadań dostępu uprzywilejowanego pokazujący, że były ograniczone czasowo albo zatwierdzane każdorazowo, a nie pozostawione na stałe.

dostęp uprzywilejowany i awaryjny na zasadzie need-to-use

Co to znaczy w praktyce. Dostęp administracyjny jest nadawany, gdy jest potrzebny, wykorzystywany, a następnie odbierany lub wygasa, nigdy nie jest trwałym atrybutem osoby. Dostęp awaryjny, typu break-glass, przebiega według zdefiniowanej procedury, jest logowany i przeglądany po fakcie. RTS wskazuje też na dedykowane konta do zadań administracyjnych oraz, tam gdzie to wykonalne, na zautomatyzowane zarządzanie dostępem uprzywilejowanym.

Jak to udokumentować. Zapisy dostępu uprzywilejowanego typu just-in-time lub check-out, jeśli go stosujesz. Dokumentacja procedury break-glass i log każdego użycia break-glass wraz z przeglądem po fakcie. Rozdzielenie kont administracyjnych od kont używanych na co dzień. Jeśli korzystasz z narzędzia PAM, jego logi sesji i zapisy zatwierdzeń służą jako dowód wprost.

rekertyfikacja dostępu w stałym cyklu

Co to znaczy w praktyce. Osoba odpowiedzialna potwierdza, według harmonogramu, że każda osoba nadal potrzebuje dostępu, który ma. RTS ustala dwa cykle (Art. 21(e)(iv) Rozporządzenia Delegowanego 2024/1774): aktualizacja uprawnień dostępu co najmniej raz w roku dla zwykłych systemów ICT i co najmniej raz na sześć miesięcy dla systemów ICT wspierających funkcje krytyczne lub istotne. Przegląd odbywa się też zawsze, gdy wymaga tego zmiana.

Jak to udokumentować. Harmonogram rekertyfikacji, który przypisuje każdemu systemowi jego cykl i datę ostatniego ukończonego przeglądu. Decyzje audytora dla każdego konta: potwierdzenie, modyfikacja lub odebranie. Dowody, że odebrania dostępu zostały wykonane, a nie tylko zapisane. Cykl sześciomiesięczny dla systemów funkcji krytycznych to szczegół najczęściej pomijany, więc nazwij go wprost w swoim harmonogramie.

silne uwierzytelnianie i uwierzytelnianie wieloskładnikowe

Co to znaczy w praktyce. Uwierzytelnianie jest dopasowane do wrażliwości danych i ryzyka danego aktywa. Silne uwierzytelnianie, w tym wieloskładnikowe (MFA), obejmuje dostęp zdalny, dostęp uprzywilejowany, dostęp do systemów wspierających funkcje krytyczne lub istotne oraz aktywa dostępne publicznie. Częściowe pokrycie to najczęstsza usterka w tym obszarze.

Jak to udokumentować. Mapa pokrycia MFA pokazująca, dla każdej aplikacji i każdej ścieżki dostępu, czy silne uwierzytelnianie jest wymuszone. Szczególna uwaga na ścieżki zdalne i uprzywilejowane. Dowody, że przestarzałe lub zapasowe metody uwierzytelniania są zamknięte, a nie pozostawione jako obejście.

kontrola dostępu fizycznego

Co to znaczy w praktyce. Dostęp fizyczny do aktywów krytycznych rządzi się tą samą logiką least privilege: osoby upoważnione są identyfikowane i logowane, dostęp jest ograniczony, monitorowany i przeglądany.

Jak to udokumentować. Logi dostępu do wrażliwych obiektów. Okresowy przegląd tego, kto ma dostęp fizyczny, i odebranie go, gdy przestaje być potrzebny.

cykle rekertyfikacji wprost

• Co najmniej raz w roku dla zwykłych systemów ICT.
• Co najmniej raz na sześć miesięcy dla systemów wspierających funkcje krytyczne lub istotne.

Do tego przegląd zawsze, gdy wymaga tego zmiana. Twoim pierwszym krokiem w kwestii cyklu jest ustalenie, które systemy wspierają funkcje krytyczne lub istotne, bo to one podlegają obowiązkowi sześciomiesięcznemu. Reszta twojego środowiska mieści się w minimum rocznym.

jak dostęp łączy się z raportowaniem incydentów i dostępem stron trzecich

Raportowanie incydentów. Gdy dojdzie do poważnego incydentu związanego z ICT, DORA wymaga trzyetapowego raportu do właściwego organu: powiadomienia wstępnego, raportu pośredniego i raportu końcowego. Dowody dotyczące dostępu zasilają te raporty. Jeśli incydent dotyczył przejętych danych uwierzytelniających, zalegającego konta osoby odchodzącej lub tożsamości z nadmiernymi uprawnieniami, to zapisy kont, historia rekertyfikacji i logi uwierzytelniania pozwalają odtworzyć, co się stało i do czego mógł dotrzeć atakujący. Dobra higiena dostępu to jednocześnie dobra telemetria do reagowania na incydenty.

Dostęp stron trzecich. Filar ryzyka stron trzecich reguluje dostawców, którzy prowadzą lub dotykają twojego ICT. Tam, gdzie ci dostawcy mają dostęp do twoich systemów, ten dostęp nadal jest twoim dostępem do kontrolowania. Konta dostawców i kontraktorów są objęte zasadą least privilege, rekertyfikacją i szybkim odbieraniem dostępu. Rejestr informacji katalogizuje twoje umowy ICT ze stronami trzecimi; dostęp, jaki te umowy przyznają, powinien być odzwierciedlony w twoich przeglądach dostępów, a nie traktowany jako cudzy problem.

od czego zacząć: checklist kontroli

Jeśli dopiero budujesz to od podstaw, poniższa kolejność to praktyczny porządek działania. Każdy punkt odpowiada wymogowi opisanemu powyżej.

1. Zinwentaryzuj tożsamości. Zrób listę każdego konta ludzkiego i maszynowego (NHI) we wszystkich systemach objętych zakresem. Nie zrekertyfikujesz tego, czego nie widzisz.
2. Sklasyfikuj swoje systemy. Oznacz, które systemy wspierają funkcje krytyczne lub istotne. To ustala cykl sześciomiesięczny i zakres silnego uwierzytelniania.
3. Zmapuj pokrycie MFA. Dla każdej aplikacji i ścieżki dostępu zapisz, czy silne uwierzytelnianie jest wymuszone. Oznacz każdą ścieżkę zdalną i uprzywilejowaną, która nie jest pokryta.
4. Znajdź stały dostęp uprzywilejowany. Wypisz, kto ma uprawnienia administracyjne i czy są one stałe, czy nadawane każdorazowo. Zidentyfikuj konta break-glass i potwierdź, że są logowane.
5. Przetestuj proces offboardingu. Weź próbkę niedawnych odejść i zmierz czas od odejścia do odebrania dostępu. To twój dowód spełnienia standardu bez zbędnej zwłoki.
6. Ogranicz konta współdzielone. Wypisz konta generyczne i współdzielone, uzasadnij te, które pozostają, i przypisz każdemu wskazanego właściciela.
7. Uruchom rekertyfikację. Zbuduj harmonogram, który wskazuje każdy system, jego cykl, audytora i datę ostatniego przeglądu. Przeprowadź pierwszy cykl i zachowaj zapisy jego wykonania.
8. Udokumentuj politykę. Napisz politykę zarządzania dostępem, która spina to wszystko w całość. To właśnie politykę przeczyta jako pierwszą organ nadzoru.

najczęstsze luki

Częściowe MFA. Silne uwierzytelnianie jest wymuszone na głównym dostawcy tożsamości (IdP), ale nie na każdej ścieżce zdalnej czy uprzywilejowanej. Przestarzały protokół, bezpośrednie połączenie z bazą danych czy portal dostawcy zostają poza pokryciem. Wymóg dotyczy silnego uwierzytelniania dla dostępu zdalnego, uprzywilejowanego i do funkcji krytycznych, więc częściowe pokrycie to częściowa zgodność.

Współdzielone konta administracyjne. Garstka generycznych loginów administracyjnych jest używana przez kilka osób. Aktywności nie da się przypisać do konkretnej osoby, co narusza wymóg rozliczalności i utrudnia zarówno rekertyfikację, jak i odtworzenie przebiegu incydentu.

Zalegający dostęp osób odchodzących. Odejścia są przetwarzane w katalogu, ale konta pozostają w aplikacjach SaaS, konsolach chmurowych lub systemach poza centralną ścieżką provisioningu. Standard bez zbędnej zwłoki dotyczy tego wszystkiego, nie tylko katalogu.

Konta serwisowe bez właścicieli. Tożsamości maszynowe (NHI) są tworzone przy konfiguracji, dostają szerokie uprawnienia i nigdy nie zostają przypisane do wskazanego właściciela. Nie pojawiają się w przeglądach opartych na danych HR, bo nie są ludźmi. W typowym środowisku cicho się kumulują i to właśnie one najrzadziej przechodzą rekertyfikację.