PAM w banku spółdzielczym – JumpServer, DORA i kontrola dostępu uprzywilejowanego

PAM W BANKU SPÓŁDZIELCZYM

PRAKTYCZNY PORADNIK WDROŻENIA I NADZORU

JumpServer jako rozwiązanie open source oraz zasady stosowane także do komercyjnych platform PAM

Dostęp uprzywilejowany staje się jednym z ważniejszych obszarów bezpieczeństwa ICT w bankach spółdzielczych. Coraz częściej pojawiają się pytania dotyczące systemów PAM – Privileged Access Management, nagrywania sesji administratorów, dostępu serwisów zewnętrznych, kont technicznych oraz możliwości wykazania, kto i w jaki sposób wykonywał czynności administracyjne.

W praktyce banki zadają również bardzo konkretne pytanie:

czy wdrażać własny PAM już teraz, czy czekać na rozwiązanie oferowane przez SOC zrzeszenia?

Odpowiedź zależy od środowiska konkretnego Banku – jego architektury, systemu centralnego, modelu hostowania, organizacji IT, dostawców oraz faktycznych uprawnień użytkowników.

PAM to nie tylko nagrywanie sesji administratora

PAM nie powinien być traktowany wyłącznie jako narzędzie do nagrywania obrazu ekranu.

Prawidłowo zaprojektowany model zarządzania dostępem uprzywilejowanym obejmuje m.in.:

• identyfikację użytkownika,
• silne uwierzytelnianie,
• ograniczenie zakresu uprawnień,
• kontrolę ścieżki dostępu,
• ochronę haseł i innych poświadczeń,
• rejestrowanie czynności,
• nagrywanie sesji tam, gdzie jest to uzasadnione,
• rozdział obowiązków,
• przeglądy uprawnień,
• dostęp awaryjny,
• możliwość zabezpieczenia materiału dowodowego po incydencie.

Dlatego ważniejsze od pytania „czy Bank posiada PAM?” jest pytanie:

czy Bank rzeczywiście kontroluje dostęp uprzywilejowany i potrafi wykazać jego rozliczalność?

JumpServer – open source jako alternatywa dla komercyjnego PAM

Na rynku dostępne są rozbudowane komercyjne platformy PAM, m.in.:

• WALLIX,
• Fudo,
• CyberArk.

Dla części banków spółdzielczych istotną alternatywą może być jednak JumpServer Community – rozwiązanie open source działające w modelu self-hosted.

Może ono realizować podstawowe mechanizmy związane z kontrolowanym dostępem administracyjnym, m.in. obsługę połączeń SSH i RDP, rejestrowanie sesji, audyt aktywności, integrację z usługami katalogowymi czy MFA – zależnie od faktycznie wdrożonej wersji i konfiguracji.

Dla banku spółdzielczego może mieć to istotne znaczenie ekonomiczne, ponieważ edycja Community nie wymaga zakupu klasycznej licencji komercyjnej.

Trzeba jednak pamiętać:

open source nie oznacza braku kosztów.

Bank nadal odpowiada za właściwe wdrożenie, infrastrukturę, aktualizacje, backup, monitoring, bezpieczeństwo samego PAM, testy oraz utrzymanie odpowiednich kompetencji.

Dlatego decyzja powinna uwzględniać nie tylko koszt licencji, ale również całkowity koszt posiadania – TCO.

Czy czekać na PAM SOC BPS lub SOC SGB?

To jedno z częściej pojawiających się pytań.

Jeżeli Bank posiada informację o planowanym uruchomieniu PAM w ramach SOC BPS lub SOC SGB, ale nie ma jeszcze wiążącego terminu, zakresu funkcjonalnego, SLA, modelu integracji lub kosztów, powstaje okres przejściowy.

W takim przypadku warto pamiętać o podstawowej zasadzie:

planowane zabezpieczenie nie jest jeszcze działającym zabezpieczeniem.

Audyt ocenia stan faktyczny istniejący w Banku w dniu badania.

Dlatego oczekiwanie przez nieokreślony czas na przyszłą usługę może oznaczać utrzymywanie luki w zarządzaniu dostępem uprzywilejowanym.

Jednym z możliwych scenariuszy jest wdrożenie lokalnego JumpServer jako rozwiązania przejściowego. Po uruchomieniu PAM SOC BPS lub SOC SGB Bank może porównać oba rozwiązania pod kątem:

• bezpieczeństwa,
• funkcjonalności,
• SLA,
• kosztów,
• dostępu do nagrań i logów,
• integracji,
• odpowiedzialności za utrzymanie,
• możliwości migracji.

Możliwy jest także model hybrydowy.

SoftNet, NOVUM, Asseco – jeden problem, ale różne architektury

PAM nie powinien być projektowany wyłącznie według nazwy producenta systemu.

Kluczowe pytanie brzmi:

która część infrastruktury i administracji pozostaje pod kontrolą Banku, a która po stronie dostawcy?

Inaczej wygląda wdrożenie PAM dla:

• SoftNet EuroBankNet utrzymywanego w serwerowni Banku,
• SoftNet EuroBankNet hostowanego w zewnętrznym CPD,
• NOVUM działającego lokalnie,
• NOVUM świadczonego jako usługa hostingowa,
• Asseco defBank w infrastrukturze Banku,
• Asseco WPI,
• innych systemów SaaS lub środowisk chmurowych.

Jeżeli system znajduje się w Banku, lokalny PAM może objąć wiele ścieżek administracyjnych: serwery, system operacyjny, bazę danych, urządzenia sieciowe czy dostęp dostawców.

Jeżeli natomiast system jest hostowany przez dostawcę, lokalny PAM Banku nie będzie automatycznie widział czynności administratorów wykonywanych wewnątrz infrastruktury dostawcy.

W takim przypadku trzeba zweryfikować m.in.:

• czy dostawca posiada własny PAM,
• jak identyfikuje administratorów,
• czy sesje są rejestrowane,
• jaka jest retencja,
• jakie dowody może otrzymać Bank,
• jakie są prawa audytowe,
• jak wygląda postępowanie przy incydencie.

Dlatego nawet dwa banki posiadające ten sam system centralny mogą potrzebować różnych modeli PAM.

Czy należy nagrywać sesje Zarządu?

Sama nazwa roli „Administrator” nie przesądza jeszcze o konieczności pełnego nagrywania sesji.

Najpierw należy ustalić rzeczywisty zakres uprawnień.

Jeżeli jest to szeroka rola biznesowa, a system zapewnia kompletny i chroniony ślad audytowy, pełne nagrywanie sesji może nie być konieczne.

Jeżeli jednak użytkownik może:

• zarządzać innymi użytkownikami,
• zmieniać uprawnienia,
• modyfikować konfigurację,
• zmieniać parametry bezpieczeństwa,
• wykonywać masowy eksport danych,
• ingerować w logi lub mechanizmy kontrolne,

taki dostęp powinien być traktowany jako uprzywilejowany.

O zastosowaniu PAM powinien decydować zakres uprawnień i ryzyko, a nie stanowisko użytkownika.

Dotyczy to zarówno administratora IT, pracownika biznesowego, członka Zarządu, jak i dostawcy zewnętrznego.

Dostawcy zewnętrzni – nadzór człowieka nie zawsze wystarczy

W wielu bankach nadal funkcjonuje model, w którym serwisant zewnętrzny łączy się do środowiska Banku, a informatyk obserwuje wykonywane przez niego czynności.

Taki nadzór jest ważny, ale w przypadku incydentu Bank może potrzebować znacznie bardziej precyzyjnych informacji:

• kto dokładnie wykonywał sesję,
• kiedy ją rozpoczął,
• do którego zasobu uzyskał dostęp,
• jakie czynności wykonał,
• czy zmieniał konfigurację,
• czy przesyłał pliki,
• czy używał konta technicznego,
• czy możliwe jest późniejsze odtworzenie całej sesji.

Właśnie w takich przypadkach PAM staje się szczególnie istotnym mechanizmem rozliczalności.

Contact Center nagrywa sesję – czy Bank potrzebuje drugiego PAM?

Nie zawsze.

Jeżeli sesje są już kontrolowane i rejestrowane przez PAM podmiotu zewnętrznego, automatyczne wdrażanie drugiego systemu dla tej samej ścieżki może być niepotrzebne.

Ale trzeba odpowiedzieć na bardzo ważne pytanie:

kto kontroluje materiał dowodowy?

Jeżeli jedyną kopię nagrania posiada podmiot zewnętrzny, Bank powinien ustalić:

• w jakim terminie może otrzymać nagranie,
• czy może zażądać jego natychmiastowego zabezpieczenia,
• jaka jest retencja,
• kto może nagranie usunąć,
• jak potwierdzana jest jego integralność,
• czy możliwe jest wstrzymanie usunięcia materiału po incydencie,
• jakie lokalne logi Bank posiada niezależnie od dostawcy.

Samo zapewnienie, że „nagranie zostanie udostępnione na prośbę”, nie powinno zastępować precyzyjnych zasad dostępu do dowodów.

Instrukcja PAM powinna opisywać rzeczywiste środowisko Banku

Można stworzyć uniwersalny wzorzec Instrukcji PAM, ale finalny dokument powinien zostać dostosowany do konkretnego Banku.

Powinien określać m.in.:

• systemy i konta objęte PAM,
• kryteria kwalifikowania dostępu jako uprzywilejowanego,
• role i odpowiedzialności,
• MFA,
• zasady nadawania i odbierania uprawnień,
• dostęp dostawców,
• nagrywanie i logowanie sesji,
• ochronę poświadczeń,
• retencję nagrań,
• dostęp do materiału dowodowego,
• tryb awaryjny,
• integrację z SIEM/SOC,
• przeglądy uprawnień,
• postępowanie w przypadku incydentu.

Szczególne znaczenie ma Segregation of Duties – rozdział obowiązków.

Administrator PAM nie powinien mieć możliwości jednoczesnego:

przyznania sobie dostępu → wykonania sesji → wyłączenia rejestrowania → usunięcia nagrania → zatwierdzenia własnego działania.

W małych zespołach IT pełne rozdzielenie ról może być trudne. Wtedy należy zastosować odpowiednie kontrole kompensacyjne, np. zasadę czterech oczu, niezależny przegląd, raportowanie do kierownictwa lub monitoring zdarzeń przez SOC.

Od czego rozpocząć wdrożenie PAM?

Nie od zakupu produktu.

Najpierw od inwentaryzacji dostępu uprzywilejowanego i analizy ryzyka ICT.

Bank powinien odpowiedzieć m.in. na następujące pytania:

• jakie posiada konta uprzywilejowane,
• które systemy są krytyczne,
• kto administruje serwerami i urządzeniami,
• które dostępy posiadają dostawcy,
• jakie konta techniczne funkcjonują w środowisku,
• które systemy są lokalne, a które hostowane,
• czy można ominąć planowaną ścieżkę PAM,
• gdzie znajdują się logi,
• kto ma dostęp do nagrań,
• jak wygląda dostęp awaryjny.

Dopiero wtedy należy projektować właściwy model PAM.

Najczęściej zadawane pytania o PAM w bankach spółdzielczych

Czy JumpServer może być wykorzystany jako PAM w banku spółdzielczym?

Tak, może stanowić techniczną podstawę rozwiązania PAM. Sama instalacja nie jest jednak wystarczająca. Znaczenie mają konfiguracja, zakres systemów, MFA, wymuszenie ścieżki dostępu, ochrona nagrań, przeglądy i dokumentacja.

Czy Bank musi kupić komercyjny PAM?

Nie automatycznie. Rozwiązania takie jak WALLIX, Fudo czy CyberArk oferują rozbudowane możliwości, ale dla części banków JumpServer Community może być racjonalną alternatywą. Decyzję należy oprzeć na funkcjonalności, ryzyku, kosztach utrzymania i wymaganym poziomie wsparcia.

Czy trzeba nagrywać wszystkie sesje administratorów?

Nie według samej nazwy konta. Kryterium stanowią faktyczne uprawnienia, krytyczność systemu, analiza ryzyka oraz jakość istniejącego śladu audytowego.

Czy można poczekać na PAM SOC BPS lub SOC SGB?

Można podjąć taką decyzję, ale Bank powinien ocenić ryzyko okresu przejściowego. Jeżeli nie ma wiążącego terminu i szczegółów przyszłej usługi, warto przeanalizować rozwiązanie lokalne.

Czy lokalny PAM obejmie administratorów systemu hostowanego?

Nie zawsze. Lokalny PAM kontroluje tylko te ścieżki, które rzeczywiście przechodzą przez infrastrukturę Banku. Działania administratorów dostawcy wykonywane wewnątrz jego CPD lub platformy SaaS wymagają innych mechanizmów kontroli i odpowiednich zapisów umownych.

Czy jedna Instrukcja PAM może być stosowana w każdym banku?

Nie powinna. Dokument musi uwzględniać rzeczywistą architekturę, system centralny, sposób hostowania, strukturę IT, dostawców, SOC oraz faktyczne funkcje wybranego rozwiązania PAM.

Każdy Bank może potrzebować innego modelu PAM

Technologia jest tylko jednym z elementów.

O skuteczności PAM decydują przede wszystkim:

architektura, zakres uprawnień, dostawcy, system centralny, model hostowania, rozdział obowiązków, logi, procedury oraz możliwość zabezpieczenia materiału dowodowego.

Dlatego rozwiązanie poprawne w jednym Banku nie musi być odpowiednie w innym.

Eksperci Servus Comp Kraków wspierają banki spółdzielcze w analizie dostępu uprzywilejowanego, określaniu zakresu PAM, ocenie możliwości wykorzystania JumpServer, projektowaniu ról i kontroli, analizie dostępu dostawców oraz przygotowaniu dokumentacji i procedur PAM.

Jeżeli Państwa Bank:

• otrzymał zalecenie dotyczące braku PAM,
• oczekuje na rozwiązanie SOC BPS lub SOC SGB,
• rozważa wdrożenie JumpServer,
• korzysta z SoftNet, NOVUM, Asseco lub innego systemu centralnego,
• posiada systemy hostowane lub SaaS,
• chce ustalić, które sesje powinny być rejestrowane lub nagrywane,
• potrzebuje Instrukcji zarządzania PAM,

zapraszamy do kontaktu z Servus Comp Kraków.

Najpierw warto przeanalizować rzeczywiste środowisko i ryzyko Banku. Dopiero na tej podstawie można właściwie dobrać technologię, zakres kontroli i dokumentację.

 

 

Zapraszamy Państwa do zapoznania się z innymi wpisami na naszm blogu:

1. Strategia ICT to za mało. KNF pyta o operacyjną odporność cyfrową Banku:

   https://premiumbank.zadbajobezpieczenstwo.pl/strategia-ict-to-za-malo-knf-pyta-o-operacyjna-odpornosc-cyfrowa-banku/

2. Backup jest? To za mało. KNF zapyta, czy Bank potrafi się odtworzyć:
   https://premiumbank.zadbajobezpieczenstwo.pl/backup-jest-to-za-malo-knf-zapyta-czy-bank-potrafi-sie-odtworzyc-strategia-ciaglosci-dzialania-ict-po-ocenie-knf-ryzyka-ict-za-2025-r/

3. Skan to za mało. KNF zapyta, czy Bank naprawdę testuje odporność ICT:
   https://premiumbank.zadbajobezpieczenstwo.pl/skan-podatnosci-to-nie-test-odpornosci-knf-zapyta-czy-bank-naprawde-testuje-ict/

4. Jeden dostawca, wiele systemów, jedno duże ryzyko. KNF pyta o koncentrację ICT:
   https://premiumbank.zadbajobezpieczenstwo.pl/jeden-dostawca-wiele-systemow-jedno-duze-ryzyko-knf-pyta-o-koncentracje-ict/

5. Audyt ZDU — czy wiesz, kogo naprawdę powinien kontrolować Bank?:
   https://premiumbank.zadbajobezpieczenstwo.pl/audyt-zdu-w-banku-spoldzielczym-jak-kontrolowac-dostawcow-zewnetrznych-zgodnie-z-dora/

6. Zarząd musi wiedzieć. KNF zapyta, kto naprawdę nadzoruje ryzyko ICT w Banku:
   https://premiumbank.zadbajobezpieczenstwo.pl/raport-ict-do-zarzadu-knf-pyta-kto-nadzoruje-ryzyko-ict-w-banku/

7. Znalazłeś podatność? KNF zapyta, kiedy ją usunąłeś:
   https://premiumbank.zadbajobezpieczenstwo.pl/znalazles-podatnosc-knf-zapyta-kiedy-ja-usunales-zarzadzanie-podatnosciami-ict-po-ocenie-knf-ryzyka-ict-za-2025-r/

8. Masz procedury DORA? KNF zapyta: kiedy ostatnio naprawdę je przeczytałeś?:
   https://premiumbank.zadbajobezpieczenstwo.pl/coroczny-przeglad-dokumentacji-ict-dora-w-banku-spoldzielczym-po-ocenie-nadzorczej-knf-ryzyka-ict-za-2025-r/

9. DORA nie zna wymówki: pracownik nie miał czasu na szkolenie:
   https://premiumbank.zadbajobezpieczenstwo.pl/szkolenia-ict-dora-po-ocenie-knf-ryzyka-ict-za-2025-r-czy-bank-przeszkolil-wszystkich-czy-tylko-ma-plan-szkolenia/

10. Dokument jest? KNF zapyta o dowód, że działa:
    https://premiumbank.zadbajobezpieczenstwo.pl/dokument-jest-knf-zapyta-o-dowod-ze-dziala/

Zadzwoń lub napisz do Servus Comp, aby omówić temat.

• Strona główna: https://premiumbank.zadbajobezpieczenstwo.pl

Servus Comp Data Security, Świętokrzyska 12/403, 30-015 Kraków

tel. +48 608 407 668, +48 12 631 91 22 • biuro@servus-comp.pl

PODEJMIEMY DLA PAŃSTWA KAŻDE WYZWANIE!

JESTEŚ ZAINTERESOWANY? ZADZWOŃ, NAPISZ DO NAS

#PAM #PrivilegedAccessManagement #JumpServer #BankSpółdzielczy #BankiSpółdzielcze #Cyberbezpieczeństwo #BezpieczeństwoICT #DORA #RTS #DORABank #ZarządzanieDostępem #DostępUprzywilejowany #KontrolaDostępu #MFA #SOC #SOCBPS #SOCSGB #SOZBPS #IPSSGB #AudytICT #AudytBezpieczeństwa #RyzykoICT #SystemyBankowe #SoftNet #NOVUM #Asseco #defBank #WPI #OpenSource #CyberSecurity #Compliance #OperationalResilience #ServusComp #ServusCompKraków