Integrator systemu transakcyjnego, firma utrzymująca bazy danych, serwis macierzy i sieci — każdy z nich loguje się do systemów, za które przed nadzorcą odpowiada Twoja instytucja, a nie on. Dostęp dostawców zewnętrznych do systemów krytycznych zwykle powstaje w umowie: konto na start projektu, VPN dla całego zespołu, hasło w wiadomości od kierownika projektu. Potem nikt go nie odbiera, bo nikt go formalnie nie posiada.
DORA nie pozwala przerzucić odpowiedzialności na dostawcę, a rozporządzenie delegowane (UE) 2024/1774 schodzi do poziomu konta: własna tożsamość każdego technika, dostęp uprzywilejowany tylko w razie potrzeby, przegląd praw co pół roku. O umowach z dostawcami ICT i rejestrze informacji piszemy w przeglądzie rozporządzenia DORA. Tutaj zajmujemy się tym, czego umowa nie wykaże: kto konkretnie się loguje, na jak długo, z czyją zgodą i co zostaje jako dowód.
Dlaczego dostawca z uprawnieniami administratora to ryzyko, którego umowa nie zamyka?
Bo umowa reguluje relację z firmą, a system widzi konto — i to konto, a nie klauzula, decyduje o tym, co stanie się w bazie danych o drugiej w nocy. Umowa zobowiąże dostawcę do przestrzegania polityk i zgłaszania incydentów, ale nie powie, który z jego dwudziestu inżynierów zalogował się wczoraj na serwer rozliczeń i dlaczego.
W praktyce dostęp dostawcy ma trzy typowe słabości. Konto współdzielone — jedno „vendor_admin” dla całego zespołu wsparcia, z hasłem, które zna każdy, kto kiedykolwiek pracował przy projekcie. Dostęp stały — VPN aktywny przez cały okres umowy, choć realne prace zajmują kilka dni w kwartale. Brak właściciela — po stronie instytucji nikt nie odpowiada za to konto, więc nikt nie zauważa, że technik odszedł od dostawcy pół roku temu.
Art. 28 ust. 1 lit. a) DORA zamyka temat odpowiedzialności: podmiot finansowy korzystający z usług ICT na podstawie umowy przez cały czas ponosi pełną odpowiedzialność za wypełnianie obowiązków z rozporządzenia. Incydent z konta dostawcy jest więc incydentem instytucji — w raportowaniu, w ocenie nadzorcy i w rozmowie z zarządem.
Czego DORA wymaga od kontroli dostępu dostawców do systemów ICT?
Samo rozporządzenie (UE) 2022/2554 formułuje zasadę, a rozporządzenie delegowane 2024/1774 (regulacyjne standardy techniczne dla ram zarządzania ryzykiem ICT) zamienia ją w listę kontrolną. Art. 9 ust. 4 lit. c) DORA każe ograniczać fizyczny i logiczny dostęp do zasobów ICT „do tego, co jest wymagane jedynie do uzasadnionych i zatwierdzonych funkcji i działań”. Lit. d) wymaga polityk silnego uwierzytelniania.
Rozporządzenie delegowane dopowiada szczegóły, które dotyczą dostawców wprost:
| Przepis (rozporządzenie delegowane 2024/1774) | Co oznacza dla konta dostawcy |
|---|---|
| art. 20 ust. 2 lit. a) | każdy pracownik zewnętrznego dostawcy usług ICT ma unikalną tożsamość i własne konto |
| art. 21 lit. a) | prawa według zasady minimalnych uprawnień, także przy dostępie zdalnym i awaryjnym |
| art. 21 lit. c) | jak najmniej kont generycznych i współdzielonych, każde działanie przypisane osobie |
| art. 21 lit. e) pkt (ii) | dostęp uprzywilejowany i administratora na zasadzie potrzeby lub ad hoc |
| art. 21 lit. e) pkt (iii) | niezwłoczne cofnięcie, gdy dostęp przestaje być potrzebny |
| art. 21 lit. e) pkt (iv) | przegląd praw co najmniej co 6 miesięcy dla systemów wspierających krytyczne lub istotne funkcje |
| art. 21 lit. f) pkt (ii) | silne uwierzytelnianie przy dostępie zdalnym i uprzywilejowanym |
Art. 21 dodaje, że podmioty finansowe w miarę możliwości korzystają ze specjalnych kont do zadań administracyjnych, a w miarę możliwości i w stosownych przypadkach wprowadzają zautomatyzowane rozwiązania do zarządzania dostępem uprzywilejowanym. Art. 19 lit. b) wymaga z kolei, by pracownicy dostawców korzystający z zasobów instytucji znali i przestrzegali jej polityk bezpieczeństwa.
W skrócie: DORA nie wymaga konkretnego produktu, ale wymaga wyniku, którego bez narzędzia nie da się pokazać — imiennego, czasowego, zatwierdzonego i zarejestrowanego dostępu każdej osoby po stronie dostawcy. Zakres: podmioty objęte pełnymi ramami zarządzania ryzykiem ICT; uproszczone ramy z art. 16 DORA mają osobne przepisy.
Jakie konta i sekrety ma dostawca i gdzie powinny się znajdować?
Więcej, niż wynika z umowy — dlatego inwentaryzację zaczyna się od systemów, a nie od listy dostawców. Na serwerach i w aplikacjach szuka się wszystkiego, czym dostawca może się uwierzytelnić:
- konta imienne techników w systemach operacyjnych, bazach danych i konsolach aplikacji,
- konta techniczne i serwisowe zakładane przy wdrożeniu (często z pełnymi prawami „na wszelki wypadek”),
- klucze SSH i certyfikaty wgrane na serwery przez zespół projektowy,
- klucze API i tokeny używane przez narzędzia monitoringu lub integracje dostawcy,
- konta w konsolach chmurowych i u operatorów usług zarządzanych, z których dostawca administruje zasobami instytucji.
Zasada porządkująca jest prosta: dostawca powinien znać swoje dane logowania do bramy dostępu, ale nie hasła do systemów docelowych. Poświadczenia uprzywilejowane trzyma sejf haseł, który wstrzykuje je do sesji i zmienia po jej zakończeniu. Technik nie widzi hasła administratora bazy, więc nie może go zanotować, przekazać ani użyć po zakończeniu współpracy.
Konta techniczne, których nie da się przenieść do sejfu, dostają właściciela po stronie instytucji i datę przeglądu; konto bez właściciela wyłącza się jako pierwsze.
Jak przyznawać dostawcy dostęp na czas zadania, a nie na czas umowy?
Przez wniosek powiązany z konkretną pracą: dostęp powstaje, gdy jest zgłoszenie, i wygasa sam, gdy mija okno. Tak rozumiemy wymóg art. 21 lit. e) pkt (ii) rozporządzenia delegowanego — dostęp uprzywilejowany „na zasadzie potrzeby koniecznej lub ad hoc”, a nie przez cały okres obowiązywania umowy.
Wniosek dostawcy powinien zawierać cztery elementy: numer zgłoszenia lub zmiany, system docelowy, zakres prac i okno czasowe. Akceptuje go właściciel systemu po stronie instytucji, a nie sam dział bezpieczeństwa — bo to właściciel wie, czy w czwartek o 22:00 system rozliczeń może przyjąć zmianę. Przy pracach o wysokim ryzyku (zmiana konfiguracji systemu core, operacje na danych produkcyjnych) warto wymagać dwóch akceptacji, czyli zasady czterech oczu.
Osobno trzeba zaprojektować ścieżkę awaryjną. Awaria o trzeciej w nocy nie może czekać na podpis kierownika, ale nie może też omijać kontroli. Sprawdza się wariant „najpierw dostęp, potem uzasadnienie”: dyżurny otrzymuje dostęp od razu, sesja jest nagrywana i obowiązkowo przeglądana następnego dnia. Art. 21 lit. a) rozporządzenia delegowanego obejmuje zasadą minimalnych uprawnień także dostęp awaryjny, więc jego zakres też ogranicza się do potrzeby.
Jak nadzorować sesję dostawcy i co z niej rejestrować?
Nadzór ma dwie warstwy: zapis każdej sesji i podgląd na żywo tam, gdzie ryzyko jest wysokie. Oglądanie wszystkich sesji w czasie rzeczywistym jest nierealne; podgląd z możliwością przerwania ma sens przy zmianach w systemach krytycznych i przy pierwszych pracach nowego dostawcy.
Zapis musi odtworzyć to, co się stało, a nie tylko potwierdzić, że ktoś się połączył. Nagrywanie sesji uprzywilejowanych obejmuje obraz lub strumień poleceń, a także metadane: kto, skąd, do jakiego systemu, na jakim koncie docelowym, w jakim oknie i na podstawie którego wniosku. Bez tych metadanych nagranie jest filmem, z którego audytor niczego nie wyczyta.
Rozporządzenie delegowane 2024/1774 w art. 12 opisuje, jak powinno wyglądać rejestrowanie:
- rejestrowane są zdarzenia dotyczące kontroli dostępu i zarządzania tożsamością (ust. 2 lit. c pkt i),
- rejestry chroni się przed manipulacją, usunięciem i nieuprawnionym dostępem (lit. d),
- zegary systemów synchronizuje się z wiarygodnym źródłem czasu (lit. f), więc sesję da się zestawić z logami systemu docelowego.
Okres przechowywania nagrań ustala sama instytucja na podstawie oceny ryzyka ICT — przepis nie podaje liczby. Uzasadnienie powinno uwzględniać czas wykrycia incydentu, okres odpowiedzialności dostawcy za wykonane prace i fakt, że nagranie zawiera dane osobowe technika.
Jak zamienić zapis sesji w dowód dla audytu i nadzorcy?
Łącząc trzy rejestry, które zwykle leżą w różnych miejscach: wniosek o dostęp, zapis sesji i wynik przeglądu uprawnień. Audytor nie pyta, czy instytucja „ma PAM”, tylko kto z dostawcy miał dostęp do systemu krytycznego w wybranym kwartale, kto go zatwierdził i czy dostęp wygasł.
Dobrze przygotowany materiał dowodowy odpowiada na cztery pytania bez ręcznego składania arkuszy:
- Kto — lista tożsamości pracowników dostawcy z datą nadania i odebrania dostępu. Art. 20 rozporządzenia delegowanego wymaga rejestru wszystkich przydzielonych tożsamości, przechowywanego także po rozwiązaniu stosunku umownego.
- Na jakiej podstawie — wniosek z akceptacją powiązany z każdą sesją.
- Co zrobił — nagranie i metadane sesji, spójne czasowo z logami systemu docelowego.
- Czy ktoś to sprawdził — protokół przeglądu praw co najmniej raz na sześć miesięcy dla systemów krytycznych, z decyzjami „zostaje / odbieramy”.
Ten sam materiał przydaje się po incydencie — analiza zaczyna się od listy sesji dostawców w oknie zdarzenia — i w sporze z dostawcą, gdy nagranie z zatwierdzonym zakresem prac chroni obie strony.
Czy dostawca musi łączyć się przez VPN i instalować agenta?
Nie musi, a często nie powinien. VPN do sieci wewnętrznej daje dostawcy widoczność całego segmentu, choć zadanie dotyczy jednego serwera, a agent na jego stacji to oprogramowanie, którego instytucja nie kontroluje.
Alternatywą jest pośrednik sesji: dostawca łączy się z bramą, która po uwierzytelnieniu i sprawdzeniu wniosku otwiera sesję tylko do wskazanego systemu, na wskazanym koncie docelowym. Z punktu widzenia sieci dostawca nie „jest w środku” — widzi pojedynczą sesję. Część rozwiązań idzie dalej i odwraca kierunek połączenia: tunel zestawia strona instytucji, jako połączenie wychodzące, więc brama nie przyjmuje ruchu z internetu.
VPN nie znika jednak z każdego scenariusza. Dostawca usług zarządzanych, który administruje całą infrastrukturą sieciową, może potrzebować szerszej łączności niż pojedyncze sesje. Decyzję podejmuje się więc osobno dla każdego rodzaju dostępu, a kryterium jest zakres potrzebny do zadania, zgodnie z art. 9 ust. 4 lit. c) DORA.
Jak odebrać dostęp po zakończeniu współpracy z dostawcą?
Jednym ruchem w jednym miejscu — to najmocniejszy argument za centralną bramą. Art. 21 lit. e) pkt (iii) rozporządzenia delegowanego wymaga niezwłocznego cofnięcia praw, gdy dostęp przestaje być potrzebny. Przy dostępie rozproszonym (konta lokalne, osobny VPN, klucze SSH w wielu miejscach) „niezwłocznie” oznacza tygodnie szukania.
Odebranie dostępu ma dwa warianty i oba trzeba mieć opisane w procedurze:
- odejście pojedynczego technika — dostawca zgłasza je w terminie z umowy, a instytucja blokuje konkretną tożsamość; pozostali pracownicy dostawcy pracują dalej,
- zakończenie umowy — blokada całej organizacji dostawcy, zmiana wszystkich poświadczeń, które jego ludzie mogli poznać, przegląd kont technicznych założonych w czasie współpracy i zachowanie rejestru tożsamości oraz nagrań.
Dla usług ICT wspierających krytyczne lub istotne funkcje art. 28 ust. 8 DORA wymaga strategii wyjścia i planów przejściowych. Plan wyjścia opisuje zwykle migrację danych i usług, a pomija pytanie, jak odciąć ludzi dostawcy bez przerywania pracy systemu. Warto dopisać do niego listę kont, kluczy i kanałów do zamknięcia, z właścicielem każdej pozycji.
Jak wygląda kontrola dostępu dostawców na przykładzie Fudo ShareAccess i Fudo Enterprise?
Fudo ShareAccess to przeglądarkowa platforma do udostępniania zasobów stronom trzecim, zaprojektowana tak, by dostawca nie potrzebował VPN, agentów ani zmian w infrastrukturze. Działa razem z Fudo Enterprise — platformą PAM, która pełni rolę bramy do zasobów instytucji. To przykład implementacji wzorca z poprzednich sekcji; fakty pochodzą z publicznej dokumentacji producenta.
Kierunek połączenia. ShareAccess nie potrzebuje bezpośredniego dostępu do sieci instytucji. Połączenie inicjuje Fudo Enterprise, zestawiając odwrócony tunel SSH, i wymaga wyłącznie połączeń wychodzących — do API przez HTTPS na porcie 443 i do zestawienia tunelu na porcie 65522. Producent zastrzega, że ShareAccess ogranicza zależność od VPN w określonych scenariuszach, ale nie zastępuje wszystkich funkcji VPN.
Tożsamość i zaufanie. Rejestracja wymaga uwierzytelniania dwuskładnikowego (TOTP). Użytkownik zewnętrzny widzi zasoby dopiero ze statusem zaufanego, a przed jego nadaniem administrator może porównać odcisk klucza, który przekazał mu użytkownik. Opcja zaproszenia z natychmiastowym zaufaniem istnieje, ale producent ostrzega, że oznacza nienadzorowane udostępnienie zasobów — w instytucji finansowej warto ją wyłączyć polityką.
Dostęp na czas zadania. Dostęp natychmiastowy trwa zadany czas, maksymalnie 24 godziny; dostęp planowany obejmuje wskazane okno od–do. Uzasadnienie wniosku jest obowiązkowe, a decyzję podejmuje właściciel organizacji. Użytkownik widzi wyłącznie zasoby przypisane do jego sejfu (grupy zasobów).
Zapis i odebranie. Sesje zewnętrzne można monitorować na żywo i nagrywać w całości. Sesje SSH, RDP i VNC są przechowywane w Fudo Enterprise w sieci instytucji, a ani ShareAccess, ani jego operator nie mają dostępu do ich treści. Zablokowanie użytkownika w Fudo Enterprise automatycznie wyłącza jego dostęp do zasobów udostępnionych w ShareAccess.
W naszej ocenie to zestaw dobrze dopasowany do instytucji finansowych, które mają wielu dostawców z dostępem do systemów krytycznych: jedno miejsce odebrania dostępu i zapis przechowywany w sieci instytucji odpowiadają na dwa pytania audytora z poprzednich sekcji: kto miał dostęp i czy go odebrano. Szczegóły opisuje strona Fudo ShareAccess.
Jak ocenić dojrzałość kontroli dostępu dostawców w instytucji finansowej?
Sprawdzając, na którym poziomie są cztery elementy: tożsamość, czas dostępu, zapis i odebranie.
| Poziom | Tożsamość dostawcy | Czas dostępu | Zapis i dowód | Odebranie dostępu | Kolejny krok |
|---|---|---|---|---|---|
| 1. Umowny | konta współdzielone, hasła znane zespołowi dostawcy | stały przez okres umowy | logi systemowe, jeśli są | ręcznie, gdy ktoś przypomni | inwentaryzacja kont i kanałów |
| 2. Uporządkowany | konta imienne w najważniejszych systemach | stały, ale z przeglądem | logi logowań bez treści sesji | lista kont do zamknięcia w procedurze | brama dostępu dla dostawców z prawami administratora |
| 3. Kontrolowany | tożsamość w bramie, hasła docelowe w sejfie | na wniosek, z oknem czasowym | nagranie z metadanymi wniosku | blokada w jednym miejscu | przegląd praw co 6 miesięcy powiązany z rejestrem tożsamości |
| 4. Wykazywalny | jak wyżej plus weryfikacja przy nadaniu zaufania | na wniosek, z akceptacją właściciela systemu | raport „kto, kiedy, na jakiej podstawie” gotowy dla audytora | wpisane w plan wyjścia z umowy | testowanie ścieżki awaryjnej i planu wyjścia |
Poziom ocenia się osobno dla każdego dostawcy: kluczowy integrator może być na poziomie 3, a firma serwisująca sprzęt nadal na poziomie 1. Priorytet wyznacza krytyczność funkcji, którą dostęp danego dostawcy może zakłócić.
Od czego zacząć porządkowanie dostępu dostawców zewnętrznych?
Od listy dostawców, którzy mają dostęp uprzywilejowany do systemów wspierających krytyczne lub istotne funkcje — ta lista jest krótsza niż rejestr wszystkich umów ICT, a zależy od niej najwięcej. Kolejność, która porządkuje pracę:
- Inwentaryzacja — dostawca, system, konta, kanał połączenia, podstawa w umowie i właściciel po stronie instytucji.
- Zamknięcie kanałów pobocznych — stałe VPN, narzędzia zdalnego pulpitu i konta lokalne bez właściciela.
- Brama i sejf dla pierwszej grupy — dostawcy z prawami administratora do systemów krytycznych przechodzą na dostęp przez pośrednika sesji, z hasłami docelowymi w sejfie.
- Wniosek i akceptacja — okna czasowe, właściciele systemów jako akceptujący, ścieżka awaryjna.
- Pierwszy przegląd praw i próba audytu — raport z jednego kwartału dla jednego systemu krytycznego, zanim zapyta o niego nadzorca.
Jeśli chcesz przejść tę drogę z zespołem, który łączy wdrożenia PAM z wymaganiami sektora finansowego, zobacz nasze wdrożenie PAM oraz audyt gotowości i zgodności z rozporządzeniem DORA. Więcej materiałów znajdziesz w hubach DORA oraz zarządzanie tożsamością i PAM.
