Laboratorium 4

Głównym celem zadania na ocenę 4.0 jest wykształcenie u studentów zaawansowanych umiejętności audytu systemów zarządzania tożsamością i dostępem (IAM) w podmiocie leczniczym o statusie podmiotu kluczowego w rozumieniu dyrektywy NIS2 i ustawy o KSC. Zadanie wymaga przeanalizowania wielopoziomowego ekosystemu szpitalnego (HIS, PACS, LIS, aparatura IoMT), zidentyfikowania krytycznych luk rozliczalności (konta generyczne personelu pielęgniarskiego i lekarzy dyżurnych), przeprowadzenia matrycowej analizy ryzyka 3x3 dla bezpieczeństwa pacjentów i tajemnicy medycznej, sformalizowania kart niezgodności (NC1/NC2/OFI), dochodzenia przyczyn źródłowych metodą 5 Why oraz opracowania Planu Działań Korygujących (CAP) obejmującego wdrożenie kart zbliżeniowych PKI/RFID, mechanizmu szybkiej zmiany użytkownika (Fast User Switching) oraz procedury dostępu awaryjnego w stanach nagłych (Break-Glass).

Powiązanie z sylabusem i treściami programowymi na ocenę 4.0:

• U2 Profesjonalna identyfikacja i formalna gradacja niezgodności (NC1 - Niezgodność Duża, NC2 - Niezgodność Mała, OFI - Szansa na doskonalenie) w obszarze IAM z referencją do normy ISO/IEC 27001:2022 oraz regulacji sektorowych.
• U1 Opracowanie zaawansowanej architektury uwierzytelniania dwuskładnikowego i ergonomicznego przełączania ról dla personelu medycznego z zachowaniem ciągłości ratowania życia.
• U3 Przeprowadzenie analizy ryzyka w podejściu risk-based audit z użyciem matrycy prawdopodobieństwa i skutku 3x3 dla wektorów fałszerstwa dokumentacji medycznej i nieautoryzowanego wglądu do danych onkologicznych.
• U4 Skonstruowanie Planu Działań Korygujących (CAP) opartego na analizie 5 Why, z mierzalnymi wskaźnikami KPI i harmonogramem wdrożenia.
• W1W2W3 Dogłębna znajomość normy PN-EN ISO/IEC 27001:2022 (A.5.15-A.5.18, A.8.5), RODO (art. 9 i 32), Ustawy o prawach pacjenta, dyrektywy NIS2 oraz Standardów Jakości Centrum Monitorowania Jakości w Ochronie Zdrowia (CMJ).
• K1K2K3 Niezależność oceny audytorskiej, etyka zawodowa, zrozumienie presji czasu personelu medycznego i umiejętność godzenia ergonomii z rygorystycznym bezpieczeństwem danych pacjentów.
• Powiązanie z wykładem: Wyk1 (ISMS w ochronie zdrowia), Wyk3 (Kontrole A.5 i A.8 ISO 27001), Wyk4 (NIS2 i RODO w placówkach medycznych), Wyk5 (Matrycowa analiza ryzyka 3x3), Wyk6 (Analiza logów zdarzeń logowania Event 4624/4625), Wyk7 (Metodyka CAP i 5 Why).

Wojewódzki Szpital Zespolony i Centrum Onkologii prowadzi 26 oddziałów stacjonarnych (w tym Szpitalny Oddział Ratunkowy, 3 Oddziały Intensywnej Terapii, Blok Operacyjny z 12 salami, Oddział Onkologii Klinicznej i Radioterapii), dysponując bazą 850 łóżek i hospitalizując rocznie ponad 60 000 chorych. Szpital zatrudnia 1 650 pracowników (320 lekarzy specjalistów i rezydentów, 720 pielęgniarek i położnych, 110 diagnostów laboratoryjnych i techników elektroradiologii, 180 ratowników medycznych oraz personel administracyjny). Dodatkowo w ramach nocnej i świątecznej opieki zdrowotnej dyżuruje ponad 80 lekarzy kontraktowych.

Infrastruktura teleinformatyczna i stan zarządzania dostępem:

• Głównym systemem operacyjnym jest Szpitalny System Informacyjny (HIS) zintegrowany z systemem archiwizacji i dystrybucji obrazów PACS (tomografia, rezonans, PET), laboratoryjnym LIS oraz siecią 300 telemetrycznych kardiomonitorów i pomp infuzyjnych (IoMT).
• W trakcie audytu wstępnego na stacjach roboczych w dyżurkach pielęgniarskich, gabinetach zabiegowych i na SOR zidentyfikowano powszechne stosowanie kont współdzielonych w domenie Active Directory (np. konta: "sor_pielegniarki", "onkologia_zabiegowy", "oiom_dyzur"). Hasła do tych kont są uniwersalne w skali oddziału, nie były zmieniane od 3 lat i są zapisane na obudowach monitorów.
• W samym systemie HIS personel loguje się na konta imienne, jednak logowanie trwa od 40 do 60 sekund ze względu na wolne skrypty logowania. W efekcie stacje pozostają permanentnie odblokowane na koncie jednej pielęgniarki lub lekarza przez całą 12-godzinną zmianę. Wszyscy dyżurujący pracownicy wpisują zlecenia leków, dawki cytostatyków, morfiny i parametry życiowe pacjentów na konto osoby aktualnie otwartej w systemie.
• Na salach operacyjnych i na SOR lekarze chirurdzy i anestezjolodzy korzystają z konta "blok_operacyjny_lekarz", tłumacząc to faktem, że podczas reanimacji lub operacji w jałowych rękawiczkach chirurgicznych nie ma możliwości wpisywania 14-znakowego hasła na klawiaturze.
• Szpital nie posiada procedury awaryjnego dostępu ratunkowego (Break-Glass). W sytuacji nagłego zatrzymania krążenia pacjenta z innego oddziału lekarz konsultujący zmuszony jest dzwonić do ordynatora macierzystego oddziału z prośbą o podyktowanie hasła lub zlecać procedury papierowo, co opóźnia podanie leków ratujących życie.
• Wykryto 48 aktywnych kont lekarzy rezydentów i stażystów, którzy zakończyli pracę w szpitalu ponad 6 miesięcy temu, z których 3 konta logowały się zdalnie przez szpitalny portal VPN w godzinach nocnych.
• W rejestrach logów systemowych Event Log kontrolerów domeny (Event ID 4624 - logowanie udane, Event ID 4672 - przydzielenie uprawnień specjalnych) brak jest możliwości jednoznacznego ustalenia tożsamości fizycznej osoby wprowadzającej zmiany w dawkowaniu leków onkologicznych, co rodzi bezpośrednie ryzyko błędów medycznych i odpowiedzialności karnej.

Rzecznik Praw Pacjenta oraz Narodowy Fundusz Zdrowia wszczęły postępowanie kontrolne w związku z podejrzeniem podania pacjentce niewłaściwej chemioterapii na koncie innej pielęgniarki. Dyrekcja Szpitala zleca zespołowi audytorów pilne przeprowadzenie zaawansowanego audytu IAM, wyliczenie ryzyk w matrycy 3x3, sformułowanie kart NC i planu CAP.

Praca w zespole 2-3 osobowym polega na wszechstronnym zbadaniu procesów uwierzytelniania i autoryzacji w szpitalu oraz zaproponowaniu rozwiązań eliminujących anonimowość pracy personelu:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Lead Auditor): Odpowiada za relacje z Dyrekcją, Kierownikiem Działu Kadr Medycznych i IOD, weryfikację regulaminu pracy i zgodności z NIS2, koordynację matrycy ryzyka oraz moderację referatu.

  Student 2 (Audytor Techniczny IAM/AD / Inżynier Systemów Medycznych): Bada konfigurację kontrolera domeny AD, zasady blokowania stacji roboczych, logi zdarzeń Event 4624/4625/4672, protokoły Kerberos/NTLM, architekturę kart zbliżeniowych PKI/RFID i mechanizmy Fast User Switching.

  Student 3 (Audytor Zgodności Regulacyjnej RODO, Ryzyka i Jakości CAP): Przeprowadza ocenę skutków braku rozliczalności (DPIA dla EDM), klasyfikację niezgodności (NC1/NC2/OFI), prowadzi analizę przyczyn źródłowych metodą 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP). W grupie 2-osobowej zadania te dzielą Studenci 1 i 2.

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zidentyfikowanych Luk IAM):

  Oceńcie ryzyka dla 4 kluczowych obszarów luki:

  • Skala prawdopodobieństwa (P): 1 - Niskie (mało prawdopodobne), 2 - Średnie (możliwe w ciągu roku), 3 - Wysokie (bardzo prawdopodobne lub ciągłe w codziennej pracy).
  • Skala skutku (S): 1 - Niski (zakłócenie bez wpływu na zdrowie), 2 - Średni (opóźnienie leczenia, naruszenie tajemnicy medycznej), 3 - Krytyczny (zgon pacjenta w wyniku błędu lekowego, masowy wyciek EDM, paraliż szpitala).
  • Poziom ryzyka (R = P x S): 1-2 (Ryzyko Akceptowalne), 3-4 (Ryzyko Średnie - wymagana kontrola), 6-9 (Ryzyko Krytyczne - natychmiastowe działanie).

  Wyliczcie ryzyko inherentne dla:

  1. Błędu w podaniu leku cytostatycznego z powodu pracy na cudzej sesji HIS (P=3, S=3 -> R=9).

  2. Nieuprawnionego wglądu i wycieku dokumentacji onkologicznej znanych osób przez konta martwe (P=3, S=2 -> R=6).

  3. Opóźnienia w reanimacji pacjenta na SOR z powodu braku procedury Break-Glass (P=2, S=3 -> R=6).

  4. Zdalnego ataku ransomware przez kompromitację nieaktywnego konta rezydenta na VPN (P=2, S=3 -> R=6).

• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):

  Sformułujcie karty niezgodności zawierające treść uchybienia, dowód audytowy i powołanie na konkretne punkty normy ISO/IEC 27001:2022 oraz akty prawne:

  • NC1 (Niezgodność Duża): Całkowite zniesienie rozliczalności personelu medycznego w systemie HIS i Active Directory poprzez powszechne stosowanie kont współdzielonych (naruszenie art. 5 ust. 2 i art. 32 RODO, kontroli A.5.15, A.5.16, A.8.5 ISO 27001:2022 oraz standardów CMJ).
  • NC1 (Niezgodność Duża): Brak procedury awaryjnego dostępu do dokumentacji medycznej w stanach nagłego zagrożenia życia (Break-Glass), stwarzający bezpośrednie ryzyko dla pacjentów (naruszenie art. 21 dyrektywy NIS2 i ustawy o KSC).
  • NC2 (Niezgodność Mała): Pozostawienie aktywnych kont i poświadczeń VPN dla 48 byłych lekarzy rezydentów po ustaniu stosunku zatrudnienia (naruszenie kontroli A.5.18 ISO 27001).
  • OFI (Szansa na doskonalenie): Brak wdrożenia bezprzewodowych czytników biometrycznych lub kart FIDO2 zintegrowanych z odzieżą chirurgiczną na bloku operacyjnym.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (powszechne współdzielenie sesji pielęgniarskich w HIS) przeprowadźcie dochodzenie 5 Why:

  1. Dlaczego pielęgniarki dokonują wpisów na cudzej sesji? Bo poprzednia użytkowniczka nie wylogowała się po odejściu od komputera.

  2. Dlaczego się nie wylogowała? Bo każdorazowe logowanie do systemu HIS trwa blisko minutę, a personel musi obsłużyć kilkunastu pacjentów w ciągu godziny.

  3. Dlaczego logowanie trwa tak długo i wymaga wpisywania skomplikowanych haseł na klawiaturze? Bo Dział IT wdrożył standardową politykę domenową bez uwzględnienia specyfiki ergonomicznej oddziału szpitalnego i bez mechanizmów szybkiego logowania.

  4. Dlaczego IT nie wdrożyło szybkiego logowania kartami zbliżeniowymi RFID/PKI? Bo w budżecie szpitala nie przewidziano środków na czytniki i licencje Fast User Switching, traktując wymogi bezpieczeństwa czysto biurokratycznie.

  5. Dlaczego Dyrekcja Szpitala nie sfinansowała ergonomicznych narzędzi IAM? (PRZYCZYNA ŹRÓDŁOWA): Brak w szpitalu zintegrowanej strategii bezpieczeństwa informacji (ISMS/NIS2) łączącej analizę ryzyka klinicznego z budżetowaniem technologii ochronnych, co skutkowało traktowaniem cyberbezpieczeństwa w oderwaniu od ergonomii pracy personelu medycznego.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP: Nr zadania | Działanie korygujące | Właściciel biznesowy | Mierzalny wskaźnik sukcesu (KPI) | Termin realizacji (14-90 dni).

• Krok 6 (Projekt Rozwiązania Technicznego i Procedury Break-Glass):

  Zaprojektujcie:

  • Architekturę uwierzytelniania zbliżeniowego z kartami mikroprocesorowymi PKI/RFID i technologią "Tap-in / Tap-out" (czas zmiany użytkownika poniżej 3 sekund).
  • Sformalizowaną procedurę "Dostępu Awaryjnego Break-Glass do Danych Medycznych w Stanach Nagłego Zagrożenia Życia" z automatycznym powiadomieniem IOD i pełnym logowaniem zdarzenia.

Struktura zaawansowanego referatu seminaryjnego (15 minut):

• Wprowadzenie i specyfika podmiotu kluczowego NIS2 (3 min): Rola szpitala onkologicznego, waga ochrony danych medycznych i paradoks bezpieczeństwo vs ergonomia pracy personelu (Student 1).
• Wyniki audytu IAM i matryca ryzyka 3x3 (4 min): Zestawienie dowodów ze stacji roboczych, logów Event 4624, ryzyko pomyłki chemioterapii (R=9) oraz luki w kontach rezydentów (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie pierwotnej przyczyny oporu personelu (brak ergonomii) i kwalifikacja prawno-normatywna uchybień (Student 3).
• Plan Działań Korygujących (CAP) i procedura Break-Glass (4 min): Prezentacja technologii Fast User Switching, kart PKI/RFID, procedury dostępu ratunkowego oraz bilansu wad i zalet (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Wyczerpujące odpowiedzi na pytania problemowe i diagnozę systemową:

• W jaki sposób stosowanie kont współdzielonych narusza zasadę rozliczalności (art. 5 ust. 2 RODO) oraz wymogi dyrektywy NIS2, i jakie niesie konsekwencje procesowe w przypadku wystąpienia błędu w sztuce lekarskiej (trudność w przypisaniu winy konkretnej osobie)?
• Czym charakteryzuje się zjawisko "oporu ergonomicznego" personelu medycznego wobec tradycyjnych haseł domenowych i dlaczego wymuszenie 14-znakowych haseł bez narzędzi szybkiej autoryzacji (SSO / Smartcard) w 100% przypadków prowadzi do powstawania kont współdzielonych lub zapisywania haseł na monitorach?
• W jaki sposób zaprojektować procedurę dostępu awaryjnego (Break-Glass), aby zagwarantować natychmiastowy dostęp do historii choroby pacjenta w stanie wstrząsu lub zatrzymania krążenia, nie naruszając wymogów nadzoru i rozliczalności po zakończeniu akcji ratunkowej?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Błąd w dawkowaniu leków onkologicznych na wspólnej sesji HIS -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Fast User Switching + karty RFID/PKI -> P_rez=1, S_rez=3, R_rez=3 (Ryzyko zredukowane).
  • Ryzyko 2: Wyciek danych wrażliwych przez konta byłych rezydentów -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Automatyczna integracja HR-AD z blokadą w dniu rozwiązania umowy -> P_rez=1, S_rez=2, R_rez=2.
  • Ryzyko 3: Zgon pacjenta z powodu braku dostępu do danych o uczuleniach w stanie nagłym -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Dedykowana procedura Break-Glass z natychmiastowym odblokowaniem i audytem -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 4: Nieuprawniony dostęp zdalny przez VPN bez MFA -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Wdrożenie wymuszonego MFA (FIDO2/TOTP) na bramie dostępowej -> P_rez=1, S_rez=3, R_rez=3.
• Zestawienie Kart Niezgodności: Pełne karty dla 2 Niezgodności Dużych (NC1), 1 Niezgodności Małej (NC2) oraz 1 Szansy na doskonalenie (OFI).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla zjawiska współdzielenia sesji pielęgniarskich.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Wdrożenie middleware Fast User Switching oraz czytników kart zbliżeniowych RFID/PKI na 350 stacjach pielęgniarskich i lekarskich (Właściciel: Kierownik Działu IT, Termin: 45 dni, KPI: czas zmiany użytkownika poniżej 3 sekund, zero otwartych sesji współdzielonych).
  • Zadanie CAP-2: Wdrożenie i zatwierdzenie Procedury Dostępu Ratunkowego Break-Glass w systemie HIS (Właściciel: Dyrektor ds. Medycznych i CISO, Termin: 21 dni, KPI: 100% personelu przeszkolonego, generowanie automatycznego alertu do IOD w 5 minut od użycia trybu).
  • Zadanie CAP-3: Skonfigurowanie automatycznej synchronizacji skryptowej systemu kadrowego z Active Directory wygaszającej konta i certyfikaty VPN w dniu rozwiązania umowy (Właściciel: Główny Administrator AD, Termin: 14 dni, KPI: zero aktywnych kont byłych pracowników).
  • Zadanie CAP-4: Wdrożenie uwierzytelniania dwuskładnikowego MFA na zewnętrznym portalu VPN szpitala (Właściciel: Kierownik Sekcji Bezpieczeństwa IT, Termin: 14 dni, KPI: 100% połączeń zdalnych autoryzowanych z MFA).
• Projekt Procedury Operacyjnej: "Załącznik nr 3 do Polityki Bezpieczeństwa Informacji: Zarządzanie Dostępem do Systemu HIS, Uwierzytelnianie Kartami Smartcard oraz Procedura Awaryjna Break-Glass".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Pełna, bezwzględna rozliczalność każdego wpisu i zlecenia leku w dokumentacji medycznej; drastyczne skrócenie czasu uwierzytelniania personelu (z 60 do 2-3 sekund), co eliminuje opór personelu; zagwarantowanie ciągłości ratowania życia poprzez kontrolowany tryb Break-Glass; pełna zgodność z RODO, NIS2 i standardami CMJ.
• Wady i trudności: Wysokie koszty zakupu kilkuset czytników kart i kart kryptograficznych; konieczność rekonfiguracji oprogramowania HIS we współpracy z dostawcą; konieczność rygorystycznego karania dyscyplinarnego za pożyczanie kart identyfikacyjnych innym pracownikom.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.5.15 (Zarządzanie tożsamością), A.5.16 (Uwierzytelnianie tożsamości), A.5.17 (Prawa dostępu), A.5.18 (Prawa dostępu do informacji i innych powiązanych aktywów), A.8.5 (Bezpieczne uwierzytelnianie).
• Norma PN-EN ISO/IEC 27002:2022: Bezpieczeństwo informacji, cyberbezpieczeństwo i ochrona prywatności - Wytyczne dotyczące kontroli bezpieczeństwa.
• Norma ISO 27799:2016: Health informatics - Information security management in health using ISO/IEC 27002.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - art. 21 (Środki zarządzania ryzykiem w cyberbezpieczeństwie).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 5 ust. 2 (rozliczalność), art. 9 (dane wrażliwe), art. 32 (bezpieczeństwo przetwarzania).
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2024 r. poz. 1077).
• Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta (Dz.U. z 2023 r. poz. 1545 z późn. zm.).
• Centrum e-Zdrowia (CeZ): "Standardy cyberbezpieczeństwa dla podmiotów leczniczych w zakresie EDM", Warszawa 2023.
• NIST Special Publication 800-63B: Digital Identity Guidelines - Authentication and Lifecycle Management.

• U2 Student bezbłędnie klasyfikuje uchybienia IAM w placówce medycznej do kategorii NC1/NC2/OFI z referencją do normy ISO 27001 i RODO.
• U1 Student projektuje ergonomiczny system uwierzytelniania Fast User Switching oraz bezpieczną procedurę Break-Glass dla podmiotu leczniczego.
• U3 Student wykonuje ilościowo-jakościową matrycową analizę ryzyka 3x3 dla procesów klinicznych.
• U4 Student przeprowadza dochodzenie przyczyn źródłowych metodą 5 Why i sporządza wykonalny Plan Działań Korygujących (CAP).
• W1W2W3 Student wykazuje dogłębną znajomość norm ISO 27001, ISO 27799, dyrektywy NIS2 oraz wymogów prawnych ochrony danych medycznych.
• K1K2K3 Student wykazuje postawę etyczną, odpowiedzialność za bezpieczeństwo pacjenta oraz zdolność do rozwiązywania konfliktów między wymogami bezpieczeństwa a presją ratowania życia.

Głównym celem zadania na ocenę 4.0 jest wykształcenie u studentów zaawansowanych umiejętności audytu rozdziału obowiązków (Segregation of Duties - SoD), kontroli dostępu opartej na rolach (RBAC) oraz procedur podwójnej autoryzacji transakcyjnej w banku komercyjnym podlegającym reżimowi rozporządzenia DORA oraz Rekomendacji D Komisji Nadzoru Finansowego (KNF). Zadanie wymaga zbadania konfiguracji uprawnień w systemie bankowości centralnej (Core Banking) oraz module płatności międzynarodowych SWIFT Alliance, zidentyfikowania toksycznych kombinacji uprawnień umożliwiających dokonanie oszustw finansowych (fraud), wyliczenia ryzyka operacyjnego i reputacyjnego w matrycy 3x3, sformułowania kart niezgodności (NC1/NC2/OFI), przeprowadzenia analizy 5 Why oraz opracowania Planu CAP wprowadzającego automatyczne blokady "Self-Approval" oraz procedurę centralnego poolingu autoryzacji.

Powiązanie z sylabusem i treściami programowymi na ocenę 4.0:

• U2 Wykrywanie i formalna gradacja krytycznych konfliktów SoD oraz uchybień w realizacji zasady czterech oczu w bankowości transakcyjnej.
• U1 Opracowanie zaawansowanej matrycy rozdziału obowiązków dla systemu bankowości centralnej wraz z technicznymi regułami blokad systemowych.
• U3 Przeprowadzenie analizy ryzyka nadużyć wewnętrznych i kradzieży aktywów finansowych w ujęciu inherentnym i rezydualnym z użyciem matrycy 3x3.
• U4 Opracowanie Planu Działań Korygujących (CAP) z analizą przyczyn źródłowych (5 Why), mierzalnymi wskaźnikami KPI i terminami 14-90 dni.
• W1W2W3 Biegła znajomość Rekomendacji D KNF (Rekomendacje 9, 10, 11), rozporządzenia DORA (art. 9, 10), normy ISO/IEC 27001:2022 (A.5.3, A.5.15, A.5.17, A.8.5) oraz Prawa bankowego (tajemnica bankowa art. 104).
• K1K2K3 Bezwzględna dociekliwość audytorska, bezstronność, odporność na argumenty optymalizacji kosztowej banku kosztem bezpieczeństwa oraz wysoka etyka zawodowa.
• Powiązanie z wykładem: Wyk1 (Audyt w instytucjach finansowych), Wyk3 (Kontrole A.5.3 SoD), Wyk4 (DORA i Rekomendacja D KNF), Wyk5 (Risk-based audit i matryca 3x3), Wyk6 (Sampling transakcji i analiza logów finansowych), Wyk7 (Procedura CAP i raportowanie do Komitetu Audytu).

Ogólnopolski Bank Komercyjny "Vistula Bank S.A." obsługuje 1,2 miliona klientów detalicznych i korporacyjnych, posiadając centralę w Warszawie oraz sieć 140 oddziałów w całej Polsce. Bank przetwarza dziennie ponad 800 000 transakcji płatniczych za pośrednictwem systemu bankowości centralnej (Core Banking - Oracle FLEXCUBE) oraz węzła SWIFT Alliance Access połączonego z siecią płatności międzybankowych.

Stan zastały w obszarze zarządzania tożsamością i uprawnieniami transakcyjnymi:

• W banku obowiązuje ogólna "Polityka Zarządzania Uprawnieniami", lecz nie zdefiniowano w niej formalnej tabeli toksycznych kombinacji ról (tzw. SoD Conflict Matrix). Role użytkowników w systemie Core Banking są tworzone w sposób agregacyjny przez lokalnych kierowników placówek.
• W małych placówkach partnerskich (zatrudniających 2-3 pracowników) zidentyfikowano 38 pracowników, którzy posiadają jednocześnie uprawnienia do: (1) modyfikacji danych rachunku i adresu klienta w module CRM, (2) wprowadzania dyspozycji kredytowych lub debetowych, oraz (3) ostatecznego zatwierdzania wypłaty środków bez konieczności udziału drugiego pracownika.
• Zgodnie z procedurą wewnętrzną transakcje powyżej kwoty 50 000 PLN oraz wszystkie przelewy zagraniczne SWIFT podlegają obowiązkowej autoryzacji drugiego stopnia ("zasada 4 oczu" - wprowadzający i zatwierdzający). Audyt logów systemowych wykazał jednak, że w systemie FLEXCUBE nie wdrożono twardej blokady uniemożliwiającej zatwierdzenie własnej dyspozycji (tzw. blokada Self-Approval), o ile użytkownik posiada profil o uprawnieniach kierowniczych.
• W Departamencie Skarbu i Operacji Zagranicznych zidentyfikowano 4 starszych dealerów walutowych, którzy na wypadek awarii sieci lub zastępstw otrzymali uprawnienia administratorskie do definiowania szablonów komunikatów SWIFT MT103/MT202 oraz jednocześnie uprawnienia operacyjne do ich uwalniania (SWIFT Releaser).
• W trakcie analizy zdarzeń logowania i autoryzacji z ostatnich 6 miesięcy wykryto 17 przypadków, w których przelew powyżej kwoty 200 000 PLN został wprowadzony i zatwierdzony w odstępie 3 sekund z tego samego adresu IP i tego samego identyfikatora sesji przeglądarki, co wskazuje na przekazywanie tokenów sprzętowych lub wykonywanie obu czynności przez tę samą osobę fizyczną.
• W jednostkach IT banku główny administrator bazy danych Oracle posiada bezpośrednie uprawnienia zapisu do tabeli sald kont (tabela `GL_BALANCES`), bez mechanizmu rejestracji zapytań SQL przez narzędzie klasy Database Activity Monitoring (DAM).

Komitet Audytu Rady Nadzorczej, w związku z nakazem UKNF po kontroli problemowej w obszarze Rekomendacji D, zleca audytorom przeprowadzenie pełnego audytu SoD, wyliczenie ryzyk w matrycy 3x3 oraz przygotowanie Planu CAP z analizą 5 Why.

Praca w zespole 2-3 osobowym polega na wszechstronnym zbadaniu procesów uwierzytelniania i autoryzacji w szpitalu oraz zaproponowaniu rozwiązań eliminujących anonimowość pracy personelu:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Ekspert Bankowości Transakcyjnej): Odpowiada za analizę regulaminów bankowych, zgodności z rozporządzeniem DORA i Prawem bankowym, relacje z Departamentem Compliance i koordynację referatu.

  Student 2 (Audytor Techniczny IAM/Core Banking): Analizuje konfigurację ról w Oracle FLEXCUBE i SWIFT, wyciąga logi autoryzacji, bada konfigurację mechanizmów podwójnego zatwierdzania i możliwości wdrożenia blokad programistycznych.

  Student 3 (Audytor Ryzyka Operacyjnego i Jakości CAP): Tworzy matrycę konfliktów SoD, prowadzi analizę ryzyka 3x3 dla nadużyć finansowych, realizuje dochodzenie przyczyn źródłowych metodą 5 Why i konstruuje tabelę Planu CAP. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zidentyfikowanych Luk SoD):

  Oceńcie ryzyka w skali prawdopodobieństwa (1-Niskie, 2-Średnie, 3-Wysokie) i skutku finansowo-prawnego (1-Niski <100 tys. PLN, 2-Średni 100 tys.-2 mln PLN, 3-Krytyczny >2 mln PLN, utrata licencji, sankcje KNF):

  • Ryzyko 1: Wewnętrzne oszustwo finansowe (wyprowadzenie środków) przez kumulację ról wprowadzania i zatwierdzania w placówce (P=3, S=3 -> R=9).
  • Ryzyko 2: Nieautoryzowany transfer zagraniczny przez manipulację szablonami SWIFT przez dealera (P=2, S=3 -> R=6).
  • Ryzyko 3: Ręczna modyfikacja salda księgi głównej bezpośrednio w bazie Oracle przez DBA (P=2, S=3 -> R=6).
  • Ryzyko 4: Nałożenie kary finansowej przez UKNF za brak realizacji Rekomendacji 9 i 10 Rekomendacji D (P=3, S=2 -> R=6).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):

  Sformułujcie karty niezgodności z powołaniem na punkty norm i przepisów:

  • NC1 (Niezgodność Duża): Brak technicznej blokady Self-Approval w systemie Core Banking oraz kumulacja uprawnień wprowadzania i zatwierdzania przelewów u pracowników placówek (naruszenie kontroli A.5.3 ISO 27001:2022, Rekomendacji 9.1 i 10.2 Rekomendacji D KNF oraz art. 9 rozporządzenia DORA).
  • NC1 (Niezgodność Duża): Połączenie uprawnień tworzenia szablonów i zatwierdzania płatności w module SWIFT Alliance u dealerów walutowych (naruszenie SWIFT Customer Security Programme - CSP control 1.2 i 5.1).
  • NC2 (Niezgodność Mała): Dostęp bezpośredni administratora baz danych do tabel sald bez monitorowania sesji uprzywilejowanych narzędziem DAM (naruszenie kontroli A.8.5 i A.8.18 ISO 27001).
  • OFI (Szansa na doskonalenie): Brak wdrożenia zautomatyzowanego modułu analizy konfliktów SoD w czasie rzeczywistym w potoku wnioskowania o uprawnienia (np. SAP GRC / SailPoint IdentityIQ).
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (brak blokady Self-Approval i kumulacja uprawnień transakcyjnych w małych oddziałach) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego pracownicy placówek posiadali uprawnienia pozwalające na samodzielne zatwierdzenie dyspozycji? Bo kierownicy placówek nadali im profile z uprawnieniem zatwierdzania, aby zapewnić ciągłość obsługi podczas urlopów.

  2. Dlaczego system Core Banking pozwolił na zatwierdzenie przelewu przez tę samą osobę, która go wprowadziła? Bo funkcja wymuszenia rozbieżności tożsamości wprowadzającego i zatwierdzającego była wyłączona w parametrach konfiguracyjnych modułu płatności.

  3. Dlaczego funkcja ta była wyłączona? Bo wdrożenie blokady powodowało zablokowanie pracy w placówkach 2-osobowych, gdy jeden pracownik przebywał na zwolnieniu lekarskim.

  4. Dlaczego bank nie wdrożył alternatywnego mechanizmu autoryzacji dla małych placówek (np. zatwierdzanie przez pracowników z innych placówek lub z centrali)? Bo Departament Sieci Placówek sprzeciwił się temu z obawy o wydłużenie czasu obsługi klienta przy okienku.

  5. Dlaczego obawy biznesowe przeważyły nad rygorami bezpieczeństwa i wytycznymi KNF? (PRZYCZYNA ŹRÓDŁOWA): Brak w banku nadrzędnego komitetu architektury bezpieczeństwa o prawie weta wobec procesów biznesowych oraz brak formalnej polityki rozdziału obowiązków (SoD Policy) sankcjonującej nadrzędność Rekomendacji D nad celami sprzedażowymi.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.

• Krok 6 (Projekt Rozwiązania Technicznego i Matrycy SoD):

  Zaprojektujcie:

  • Kompleksową Matrycę SoD Banku (tabela 8x8 operacji transakcyjnych z gradacją: Zakazane Bezwzględnie, Dozwolone Warunkowo z Rejestracją, Dozwolone).
  • Architekturę "Centralnego Poolingu Zadań Autoryzacyjnych": automatyczne przekierowywanie dyspozycji powyżej progów kwotowych z małych placówek do ogólnobankowej kolejki zadań w centrali.

Struktura zaawansowanego referatu seminaryjnego (15 minut):

• Wprowadzenie i ramy regulacyjne bankowości (3 min): Rola Rekomendacji D KNF, rozporządzenia DORA oraz architektury SWIFT CSP (Student 1).
• Wyniki audytu IAM i analiza matrycy ryzyka 3x3 (4 min): Przedstawienie wykrytych toksycznych kumulacji ról, anomalii w logach 4-oczu i wyliczenie ryzyka fraudu (R=9) (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Omówienie dochodzenia przyczyn źródłowych (konflikt sprzedaży z bezpieczeństwem) i kwalifikacja prawna (Student 3).
• Plan CAP i architektura Centralnego Poolingu Autoryzacji (4 min): Prezentacja blokad systemowych, matrycy SoD oraz bilansu korzyści i kosztów operacyjnych (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Wyczerpujące odpowiedzi na pytania problemowe i diagnozę systemową:

• W jaki sposób zasada rozdziału obowiązków (Segregation of Duties - SoD) zapobiega zjawisku zmowy (collusion) oraz błędom operacyjnym i dlaczego stanowi fundament kontroli wewnętrznej w sektorze finansowym wg Rekomendacji D KNF?
• W jaki sposób należy poprawnie skonfigurować zasadę "czterech oczu" w systemie płatności międzybankowych (np. SWIFT Alliance / ELIXIR), aby wykluczyć możliwość jej technicznego obejścia za pomocą współdzielenia sesji lub pożyczania kart kryptograficznych?
• Jak rozwiązać problem braku personelu w małej 2-osobowej placówce bankowej (zastępstwa urlopowe), nie łamiąc zakazu łączenia ról operacyjnych i nie dopuszczając do powstawania uprawnień toksycznych?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Oszustwo finansowe w placówce przez brak blokady Self-Approval -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Twarda blokada kodowa w FLEXCUBE + centralny pooling -> P_rez=1, S_rez=3, R_rez=3 (Ryzyko pod kontrolą).
  • Ryzyko 2: Nieautoryzowany transfer zagraniczny SWIFT przez dealera -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Bezwzględna separacja ról tworzenia i autoryzacji szablonów -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Niekontrolowana zmiana sald kont przez administratora baz danych -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Wdrożenie systemu DAM i odcięcie bezpośredniego zapisu do tabel produkcyjnych -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 4: Sankcje regulacyjne UKNF i kary DORA -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Pełne wdrożenie Planu CAP i zgłoszenie do UKNF -> P_rez=1, S_rez=2, R_rez=2.
• Zestawienie Kart Niezgodności: Pełne karty dla 2 Niezgodności Dużych (NC1), 1 Niezgodności Małej (NC2) oraz 1 Szansy na poprawę (OFI).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla braku separacji funkcji transakcyjnych.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Wdrożenie bezwzględnej blokady programistycznej Self-Approval w systemie Core Banking FLEXCUBE uniemożliwiającej zatwierdzenie dyspozycji przez jej twórcę (Właściciel: Dyrektor Departamentu Rozwoju Systemów IT, Termin: 21 dni, KPI: 100% transakcji testowych zablokowanych przy próbie samoakceptacji).
  • Zadanie CAP-2: Wdrożenie procedury i silnika Centralnego Poolingu Autoryzacji dla placówek filialnych (Właściciel: Dyrektor Departamentu Operacji Bankowych, Termin: 45 dni, KPI: eliminacja super-profili w oddziałach, średni czas autoryzacji z centrali < 90 sekund).
  • Zadanie CAP-3: Przeprowadzenie pełnego przeglądu i rekultywacji ról w module SWIFT Alliance Access z odebraniem uprawnień operatorskich dealerom walutowym (Właściciel: CISO i Kierownik Wydziału Płatności Zagranicznych, Termin: 14 dni, KPI: pełna separacja ról potwierdzona audytem technicznym).
  • Zadanie CAP-4: Wdrożenie rozwiązania Database Activity Monitoring (DAM) dla produkcyjnych baz danych banku (Właściciel: Kierownik Sekcji Bezpieczeństwa Infrastruktury, Termin: 60 dni, KPI: rejestracja 100% zapytań modyfikujących tabele finansowe).
• Projekt Dokumentu: "Matryca Rozdziału Obowiązków (SoD Control Matrix) oraz Regulamin Autoryzacji Zadań Transakcyjnych w Vistula Bank S.A.".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Wyeliminowanie wektora wewnętrznych kradzieży środków bankowych; pełna zgodność z Rekomendacją D KNF i rozporządzeniem DORA; ochrona reputacji banku i uniknięcie dotkliwych kar finansowych nakładanych przez UKNF; przejrzystość procesowa i pełna rozliczalność transakcji.
• Wady i trudności: Potencjalne wydłużenie czasu autoryzacji skomplikowanych przelewów w małych oddziałach o 1-2 minuty; koszty licencyjne i wdrożeniowe systemu monitorowania baz danych DAM; konieczność przeszkolenia pracowników sieci sprzedaży.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.5.3 (Rozdział obowiązków), A.5.15 (Zarządzanie tożsamością), A.5.17 (Prawa dostępu), A.8.5 (Bezpieczne uwierzytelnianie).
• Komisja Nadzoru Finansowego (KNF): "Rekomendacja D dotycząca zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach" (Rekomendacje 9, 10, 11), Warszawa.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA) - art. 9 i 10.
• Ustawa z dnia 29 sierpnia 1997 r. - Prawo bankowe (Dz.U. z 2023 r. poz. 2488 z późn. zm.) - art. 104 i 105a.
• SWIFT Customer Security Controls Framework (CSCF) v2024 - Mandatory Controls 1.2, 5.1.
• ISACA: "Segregation of Duties - Audit and Control Guidelines", Information Systems Audit and Control Association, 2023.
• European Banking Authority (EBA): "Guidelines on ICT and security risk management" (EBA/GL/2019/04).

• U2 Student wykrywa i klasyfikuje uchybienia w rozdziale obowiązków transakcyjnych do kategorii NC1/NC2/OFI.
• U1 Student projektuje matrycę SoD oraz schemat centralnego poolingu autoryzacji dla instytucji finansowej.
• U3 Student szacuje ryzyko nadużyć wewnętrznych i strat finansowych w matrycy 3x3 w ujęciu inherentnym i rezydualnym.
• U4 Student realizuje procedurę 5 Why i konstruuje Plan Działań Korygujących (CAP) spełniający standardy audytu bankowego.
• W1W2W3 Student zna wytyczne Rekomendacji D KNF, DORA, Prawa bankowego oraz standardów SWIFT w zakresie kontroli uprawnień.
• K1K2K3 Student cechuje się bezkompromisowością wobec naruszeń kontroli wewnętrznej, etyką bankową i odpornością na presję operacyjną.

Głównym celem zadania na ocenę 4.0 jest wykształcenie umiejętności przeprowadzenia kompleksowego audytu procesów cyklu życia tożsamości użytkowników (ang. Joiner, Mover, Leaver - JML) oraz federacji tożsamości w wielopodmiotowej administracji samorządowej. Zadanie dotyczy Samorządowego Centrum Usług Wspólnych Informatyki (CUW IT) obsługującego Urząd Marszałkowski oraz 35 podległych wojewódzkich jednostek organizacyjnych. Zadanie wymaga przeanalizowania mechanizmów zakładania, modyfikacji i odbierania uprawnień, wykrycia zjawiska "kont widm" (zombie/dormant accounts) w usługach katalogowych Active Directory / Entra ID, zbadania bezpieczeństwa uwierzytelniania federacyjnego (SAML 2.0 / OIDC) w systemie Elektronicznego Zarządzania Dokumentacją (EZD RP), wyliczenia ryzyka w matrycy 3x3, sformułowania kart niezgodności (NC1/NC2/OFI), przeprowadzenia analizy 5 Why oraz opracowania Planu CAP wprowadzającego automatyczną synchronizację kadr z systemem tożsamości (SCIM/PowerShell).

Powiązanie z sylabusem i treściami programowymi na ocenę 4.0:

• U2 Identyfikacja i formalna gradacja niezgodności w procesach cyklu życia kont, retencji poświadczeń i federacji tożsamości z odniesieniem do par. 20 KRI i RODO.
• U1 Opracowanie zintegrowanego modelu procesu Joiner-Mover-Leaver (JML) oraz bezpiecznej architektury federacji tożsamości dla jednostek samorządu terytorialnego.
• U3 Przeprowadzenie analizy ryzyka nieautoryzowanego dostępu do rejestrów publicznych i akt spraw administracyjnych z użyciem matrycy prawdopodobieństwa i skutku 3x3.
• U4 Opracowanie Planu Działań Korygujących (CAP) z analizą przyczyn źródłowych (5 Why), mierzalnymi wskaźnikami KPI i harmonogramem wdrożenia.
• W1W2W3 Dogłębna znajomość Rozporządzenia w sprawie Krajowych Ram Interoperacyjności (KRI - par. 20 ust. 2 pkt 7, 8, 14), RODO (art. 5 ust. 1 lit. f, art. 32), ustawy o KSC oraz normy ISO/IEC 27001:2022 (A.5.16, A.5.18, A.8.2, A.8.5).
• K1K2K3 Obiektywizm audytorski, zrozumienie realiów biurokracji samorządowej, zdolność do identyfikacji luk na styku kadr i IT oraz promowanie kultury cyberodpowiedzialności w sektorze publicznym.
• Powiązanie z wykładem: Wyk1 (Audyt w administracji), Wyk3 (Kontrole A.5.16 i A.5.18 ISO 27001), Wyk4 (KRI, RODO i KSC w samorządzie), Wyk5 (Risk-based audit i matryca 3x3), Wyk6 (Konfrontacja baz danych HR z Active Directory), Wyk7 (Procedura CAP i raportowanie do Marszałka).

Samorządowe Centrum Usług Wspólnych Informatyki (SCUWI) świadczy scentralizowane usługi poczty elektronicznej, sieci WAN, hostingu aplikacji oraz systemu EZD RP dla Urzędu Marszałkowskiego oraz 35 wojewódzkich jednostek samorządowych (m.in. Zarząd Dróg Wojewódzkich, Wojewódzki Urząd Pracy, 4 szpitale wojewódzkie, 6 instytucji kultury, parki krajobrazowe). W całym ekosystemie pracuje 3 800 urzędników i pracowników samorządowych.

Stan zastały w obszarze zarządzania cyklem życia tożsamości i uprawnieniami:

• Proces wnioskowania o uprawnienia (Joiner) opiera się na papierowych "Wnioskach o utworzenie konta", które po podpisaniu przez dyrektora jednostki są przesyłane do SCUWI pocztą wewnętrzną lub w skanie e-mail. Czas zakładania konta wynosi średnio 7 dni, co powoduje, że nowi pracownicy przez pierwszy tydzień pracują na kontach swoich kolegów z pokoju.
• Przy zmianie stanowiska lub wydziału (Mover) urzędnicy zachowują wszystkie dotychczasowe uprawnienia, a nowe role są do nich dopisywane w Active Directory. W rezultacie po kilku latach urzędnik posiada dostęp do danych finansowych, rejestrów nieruchomości oraz postępowań dyscyplinarnych z poprzednich wydziałów (drastyczne zjawisko akumulacji uprawnień - privilege creep).
• Proces wygaszania uprawnień przy odejściu pracownika (Leaver) funkcjonuje w oparciu o tzw. papierową kartę obiegową. W jednostkach terenowych kadry powiadamiają SCUWI o zwolnieniu pracownika z opóźnieniem wynoszącym od 2 do 8 tygodni.
• Zespół audytorów dokonał konfrontacji aktualnych wykazów zatrudnienia z 35 działów kadr z bazą użytkowników Active Directory (skrypt PowerShell odpytujący kontroler domeny o atrybuty `Enabled -eq $True`, `LastLogonTimestamp` oraz `WhenCreated`). Wyniki porównania:
  • Zidentyfikowano 62 aktywne konta osób, które nie są zatrudnione w strukturach samorządowych od co najmniej 3 miesięcy (w tym 8 kont osób zwolnionych dyscyplinarnie).
  • Z 62 "kont widm" aż 11 kont wykazało udane logowania przez samorządowy serwer VPN oraz do portalu webowego EZD RP w okresie po dacie rozwiązania stosunku pracy.
• W centralnym systemie EZD RP wdrożono federację tożsamości SAML 2.0 opartą na serwerze ADFS. Jednak tokeny SAML generowane dla sesji użytkowników mają ustawiony czas ważności na 30 dni bez wymuszenia reautoryzacji, co pozwala na dostęp do dokumentacji urzędowej z prywatnych komputerów nawet po zablokowaniu konta domenowego.

W związku z wyciekiem poufnych planów zagospodarowania przestrzennego do mediów, Marszałek Województwa powołuje zespół audytorski w celu pilnego zbadania procedur JML, wyliczenia ryzyka w matrycy 3x3 oraz wdrożenia Planu CAP.

Praca w zespole 2-3 osobowym polega na wszechstronnym zbadaniu procesów uwierzytelniania i autoryzacji w szpitalu oraz zaproponowaniu rozwiązań eliminujących anonimowość pracy personelu:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Ekspert Prawa Administracyjnego): Bada obieg dokumentacji kadrowo-płacowej w 35 jednostkach, zgodność z KRI i RODO, regulaminy organizacyjne oraz koordynuje wystąpienie referatowe.

  Student 2 (Audytor Techniczny IAM/Active Directory / ADFS): Analizuje atrybuty kont domenowych, logi kontrolera domeny (Event ID 4720 - utworzenie konta, Event ID 4726 - usunięcie konta, Event ID 4738 - modyfikacja konta), konfigurację tokenów SAML/ADFS oraz możliwości integracji skryptowej HR-AD.

  Student 3 (Audytor Ryzyka Publicznego, RODO i Jakości CAP): Przeprowadza kwalifikację naruszeń RODO (art. 33/34 - zgłoszenie naruszenia do UODO), szacuje ryzyka w matrycy 3x3, prowadzi analizę przyczyn źródłowych 5 Why i konstruuje tabelę Planu CAP. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zidentyfikowanych Luk JML):

  Oceńcie ryzyka w matrycy 3x3:

  • Ryzyko 1: Dostęp byłego pracownika do poufnych akt spraw w EZD RP przez aktywne "konto widmo" (P=3, S=3 -> R=9).
  • Ryzyko 2: Nieuprawniony transfer danych osobowych obywateli przez 30-dniowe tokeny SAML (P=3, S=2 -> R=6).
  • Ryzyko 3: Kumulacja uprawnień po awansach wewnętrznych skutkująca naruszeniem tajemnicy postępowań (P=3, S=2 -> R=6).
  • Ryzyko 4: Kary finansowe nakładane przez Prezesa UODO za brak rozliczalności i kontroli dostępu w jednostce publicznej (P=2, S=3 -> R=6).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):

  Sformułujcie karty niezgodności z powołaniem na punkty norm i przepisów:

  • NC1 (Niezgodność Duża): Obecność 62 aktywnych kont byłych pracowników w Active Directory oraz brak procedury natychmiastowego blokowania dostępów po ustaniu zatrudnienia (naruszenie par. 20 ust. 2 pkt 7 i 8 KRI, art. 5 ust. 1 lit. f oraz art. 32 RODO, kontrola A.5.18 ISO 27001:2022).
  • NC1 (Niezgodność Duża): Długożyjące tokeny federacyjne SAML w systemie EZD RP umożliwiające ominięcie blokady konta domenowego (naruszenie kontroli A.8.5 ISO 27001:2022 oraz par. 20 ust. 2 pkt 14 KRI).
  • NC2 (Niezgodność Mała): Brak okresowego przeglądu uprawnień urzędników przy zmianie stanowiska (Mover) prowadzący do zjawiska privilege creep (kontrola A.5.18 ISO 27001).
  • OFI (Szansa na doskonalenie): Brak wdrożenia protokołu SCIM (System for Cross-domain Identity Management) do zautomatyzowanego provisioningu tożsamości z systemów kadrowych do chmury samorządowej.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (istnienie 62 aktywnych kont byłych urzędników z udanymi logowaniami po zwolnieniu) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego konta zwolnionych urzędników pozostawały aktywne w Active Directory? Bo administratorzy SCUWI nie otrzymali powiadomienia o rozwiązaniu umów o pracę.

  2. Dlaczego kadry jednostek podległych nie powiadomiły SCUWI? Bo procedury w jednostkach opierały się na tradycyjnej papierowej obiegówce zanoszonej przez odchodzącego pracownika.

  3. Dlaczego polegano na papierowej obiegówce zanoszonej przez pracownika? Bo regulaminy pracy w 35 jednostkach nie były ujednolicone i nie narzucały obowiązku elektronicznego zgłaszania odejść przez kierownika kadr.

  4. Dlaczego nie zintegrowano systemów kadrowo-płacowych jednostek z systemem katalogowym SCUWI? Bo każda z 35 jednostek korzysta z innego, autonomicznego oprogramowania kadrowego różnych dostawców i SCUWI uznało integrację za zbyt skomplikowaną technicznie.

  5. Dlaczego dopuszczono do autonomii oprogramowania kadrowego bez centralnych standardów integracji? (PRZYCZYNA ŹRÓDŁOWA): Brak nadrzędnego zarządzenia Marszałka Województwa powołującego scentralizowaną architekturę zarządzania tożsamością oraz brak procedury SLA narzucającej bezwzględny termin 2 godzin na zgłoszenie odejścia pracownika do SCUWI.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.

• Krok 6 (Projekt Rozwiązania Technicznego i Nowej Procedury JML):

  Zaprojektujcie:

  • Architekturę zautomatyzowanego cyklu życia tożsamości: cyfrowy formularz JML w EZD RP zintegrowany ze skryptami PowerShell/SCIM automatycznie wyłączającymi konto w AD w dniu rozwiązania umowy o godz. 16:00.
  • Konfigurację parametrów tokenów federacyjnych SAML w ADFS: skrócenie czasu życia tokena sesyjnego do 8 godzin oraz wymóg sprawdzania statusu konta w czasie rzeczywistym.

Struktura zaawansowanego referatu seminaryjnego (15 minut):

• Wprowadzenie i kontekst samorządowych Centrów Usług Wspólnych (3 min): Skala obsługi 35 jednostek, waga ochrony rejestrów publicznych i wymogi KRI (Student 1).
• Wyniki audytu IAM i analiza matrycy ryzyka 3x3 (4 min): Prezentacja dowodów obecności 62 kont widm, analiza logów logowań po zwolnieniu (R=9) i luk w SAML (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie dochodzenia przyczyn źródłowych (rozproszenie systemów kadr) i kwalifikacja prawna RODO/KRI (Student 3).
• Plan CAP i nowa zautomatyzowana procedura JML (4 min): Prezentacja integracji SCIM/PowerShell, rekonfiguracji ADFS oraz bilansu korzyści organizacyjnych (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Wyczerpujące odpowiedzi na pytania problemowe i diagnozę systemową:

• W jaki sposób par. 20 Rozporządzenia Rady Ministrów w sprawie Krajowych Ram Interoperacyjności reguluje kwestię weryfikacji i odbierania uprawnień użytkowników w podmiotach publicznych?
• Dlaczego brak korelacji między działem kadr a działem IT jest uznawany za jeden z najpoważniejszych wektorów ataku wewnętrznego i jakie zagrożenia stwarza zjawisko akumulacji uprawnień (privilege creep)?
• W jaki sposób protokół SAML 2.0 zarządza sesją użytkownika w architekturze federacyjnej i jak zapobiec sytuacji, w której zablokowanie konta w Active Directory nie powoduje natychmiastowego zerwania sesji w aplikacji zewnętrznej?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Naruszenie poufności spraw w EZD RP przez byłego pracownika -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Automatyczna blokada w dniu odejścia + unieważnienie tokenów SAML -> P_rez=1, S_rez=3, R_rez=3 (Pod kontrolą).
  • Ryzyko 2: Nieuprawniony dostęp przez długożyjące tokeny SAML z prywatnych stacji -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Skrócenie tokena do 8h + wymuszenie ponownej atestacji -> P_rez=1, S_rez=2, R_rez=2.
  • Ryzyko 3: Kumulacja uprawnień po awansach (privilege creep) -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Polityka czyszczenia ról przy każdej zmianie stanowiska w EZD -> P_rez=1, S_rez=2, R_rez=2.
  • Ryzyko 4: Kara Prezesa UODO za brak rozliczalności (art. 5 ust. 2 RODO) -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Wdrożenie zintegrowanego rejestru tożsamości i logowania zdarzeń -> P_rez=1, S_rez=2, R_rez=2.
• Zestawienie Kart Niezgodności: Pełne karty dla 2 Niezgodności Dużych (NC1), 1 Niezgodności Małej (NC2) oraz 1 Szansy na doskonalenie (OFI).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla zjawiska obecności kont widm.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Natychmiastowe zablokowanie 62 zidentyfikowanych kont widm w Active Directory oraz unieważnienie certyfikatów VPN (Właściciel: Kierownik Sekcji Serwerowej SCUWI, Termin: 24 godziny, KPI: 100% kont widm zablokowanych).
  • Zadanie CAP-2: Wdrożenie zautomatyzowanego skryptu PowerShell odpytującego systemy kadrowe jednostek i synchronizującego status zatrudnienia z Active Directory (Właściciel: Główny Programista SCUWI, Termin: 30 dni, KPI: czas blokady konta po dacie zwolnienia < 2 godziny).
  • Zadanie CAP-3: Rekonfiguracja farmy ADFS: skrócenie czasu życia tokenów SAML do 8 godzin oraz wdrożenie mechanizmu token revocation przy blokadzie konta (Właściciel: Architekt Bezpieczeństwa IT, Termin: 14 dni, KPI: natychmiastowe unieważnienie sesji w EZD RP).
  • Zadanie CAP-4: Nowelizacja Zarządzenia Marszałka w sprawie jednolitej procedury JML dla wszystkich 35 jednostek samorządowych (Właściciel: Dyrektor Generalny Urzędu Marszałkowskiego, Termin: 45 dni, KPI: wejście w życie uchwały i przeszkolenie kierowników kadr).
• Projekt Procedury: "Regulamin Zarządzania Cyklem Życia Tożsamości Urzędniczych (Joiner-Mover-Leaver) w Środowisku Samorządowych Usług Wspólnych".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Wyeliminowanie niekontrolowanego dostępu byłych pracowników do wrażliwych danych obywateli; pełna zgodność z KRI i RODO; automatyzacja procesu zakładania i usuwania kont skracająca czas obsługi kadr; wzmocnienie ładu cyberbezpieczeństwa w skali całego województwa.
• Wady i trudności: Konieczność wyegzekwowania dyscypliny organizacyjnej od kierowników 35 autonomicznych jednostek; koszty integracji różnorodnych systemów kadrowych; ryzyko przypadkowego zablokowania konta w przypadku błędów w danych kadrowych.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.5.15 (Zarządzanie tożsamością), A.5.16 (Uwierzytelnianie tożsamości), A.5.18 (Prawa dostępu do informacji), A.8.2 (Uprzywilejowane prawa dostępu), A.8.5 (Bezpieczne uwierzytelnianie).
• Rozporządzenie Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2024 r. poz. 773) - par. 20.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 5 ust. 1 lit. f, art. 5 ust. 2, art. 32.
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2024 r. poz. 1077).
• Urząd Ochrony Danych Osobowych (UODO): "Wskazówki dotyczące zarządzania uprawnieniami do danych osobowych w jednostkach sektora publicznego", Warszawa 2023.
• OASIS: "Security Assertion Markup Language (SAML) V2.0 Technical Overview", Standardy federacji tożsamości.

• U2 Student wykrywa i klasyfikuje uchybienia w cyklu życia tożsamości publicznej do kategorii NC1/NC2/OFI.
• U1 Student opracowuje zautomatyzowaną procedurę JML oraz bezpieczną architekturę federacji tożsamości SAML.
• U3 Student szacuje ryzyka nieautoryzowanego dostępu do rejestrów publicznych w matrycy 3x3.
• U4 Student realizuje procedurę 5 Why i sporządza Plan Działań Korygujących (CAP) dostosowany do sektora publicznego.
• W1W2W3 Student zna przepisy KRI, RODO, ustawy o KSC oraz standardy federacji tożsamości.
• K1K2K3 Student rozumie odpowiedzialność urzędniczą za powierzone dane obywateli oraz potrafi wdrażać ład bezpieczeństwa w strukturach wielopodmiotowych.

Głównym celem zadania na ocenę 4.0 jest wykształcenie zaawansowanych umiejętności audytu zarządzania dostępem uprzywilejowanym (Privileged Access Management - PAM) oraz tożsamościami maszynowymi w chmurowym przedsiębiorstwie technologicznym (FinTech Cloud Software House) przetwarzającym dane kart płatniczych w reżimie standardu PCI DSS v4.0 oraz raportu atestacyjnego SOC 2 Type II. Zadanie koncentruje się na zbadaniu uprawnień administratorskich w środowisku chmury Amazon Web Services (AWS) oraz produkcyjnych klastrach Kubernetes (EKS). Zadanie wymaga zidentyfikowania zjawiska "stałych uprawnień administratorskich" (Standing Privileges), audytu logów AWS CloudTrail i Kubernetes Audit Logs, wyliczenia ryzyka kompromitacji środowiska w matrycy 3x3, zakwalifikowania niezgodności (NC1/NC2/OFI), przeprowadzenia analizy 5 Why oraz opracowania Planu CAP wprowadzającego paradygmat Zero Standing Privileges (ZSP), sesje dostępowe Just-In-Time (JIT), sejf sekretów z automatyczną rotacją poświadczeń oraz nagrywanie i analizę sesji uprzywilejowanych.

Powiązanie z sylabusem i treściami programowymi na ocenę 4.0:

• U2 Profesjonalna identyfikacja i formalna gradacja niezgodności w zarządzaniu kontami uprzywilejowanymi, sekretami API i dostępem do kontenerów produkcyjnych.
• U1 Opracowanie nowoczesnej architektury PAM opartej na modelu Zero Standing Privileges (ZSP) oraz dostępie Just-In-Time (JIT) zintegrowanym z bramą bastionową i sejfem sekretów.
• U3 Przeprowadzenie analizy ryzyka kompromitacji kluczy administratorskich i wycieku danych posiadaczy kart płatniczych (PAN/CVV) w matrycy 3x3.
• U4 Opracowanie Planu Działań Korygujących (CAP) opartego na analizie 5 Why, z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.
• W1W2W3 Dogłębna znajomość wymogów standardu PCI DSS v4.0 (Wymagania 7 i 8), wytycznych SOC 2 (Trust Services Criteria - Security and Confidentiality), normy ISO/IEC 27001:2022 (A.8.2, A.8.5) oraz NIST SP 800-207 (Zero Trust Architecture).
• K1K2K3 Wysoka kultura inżynierska, bezkompromisowość wobec praktyk "skrótów administratorskich", zdolność do argumentacji biznesowej na rzecz bezpieczeństwa w dynamicznym środowisku programistycznym (DevSecOps).
• Powiązanie z wykładem: Wyk1 (Audyt w FinTech), Wyk3 (Kontrole A.8.2 i A.8.5 ISO 27001), Wyk4 (PCI DSS i SOC 2 w audycie zgodności), Wyk5 (Risk-based audit w chmurze i matryca 3x3), Wyk6 (Analiza logów AWS CloudTrail i Kubernetes), Wyk7 (Metodyka CAP i raportowanie do CISO).

FinTech "PayCloud Solutions Sp. z o.o." dostarcza bramkę płatniczą online oraz usługi portfela cyfrowego dla ponad 4 000 sklepów internetowych w Unii Europejskiej, przetwarzając miesięcznie 15 milionów transakcji kartowych. Cała infrastruktura produkcyjna jest hostowana w chmurze publicznej AWS w regionie Frankfurt (eu-central-1), obejmując 8 klastrów Kubernetes (Amazon EKS), bazy danych Amazon RDS PostgreSQL oraz bezserwerowe funkcje AWS Lambda. W firmie pracuje 65 inżynierów oprogramowania, inżynierów DevOps oraz administratorów systemowych.

Stan zastały w obszarze zarządzania dostępem uprzywilejowanym (PAM):

• W organizacji nie wdrożono dedykowanego rozwiązania PAM ani sejfu poświadczeń (takiego jak HashiCorp Vault, CyberArk czy AWS Secrets Manager). Dostęp do infrastruktury chmurowej opiera się na stałych kontach użytkowników IAM (IAM Users) z przypisanymi na stałe uprawnieniami `AdministratorAccess`.
• Audyt konfiguracji AWS IAM ujawnił, że 22 programistów i inżynierów DevOps posiada stałe klucze dostępowe API (`AWS_ACCESS_KEY_ID` i `AWS_SECRET_ACCESS_KEY`) zapisane w plikach konfiguracyjnych na prywatnych laptopach. Wiek 14 z tych kluczy przekracza 400 dni, bez jakiejkolwiek procedury rotacji poświadczeń.
• Dostęp do produkcyjnych węzłów i kontenerów Kubernetes (EKS) realizowany jest za pośrednictwem bezpośredniego połączenia SSH z użyciem jednego wspólnego klucza prywatnego RSA (`prod-eks-master.pem`), który jest współdzielony na wewnętrznym kanale komunikatora firmowego Slack.
• W trakcie analizy logów AWS CloudTrail stwierdzono, że konto główne root (`AWS Root Account`) było wykorzystywane 8-krotnie w ciągu ostatnich 3 miesięcy do rutynowych zadań wdrożeniowych, a logowanie to nie było chronione sprzętowym tokenem MFA (używano pojedynczego hasła zapisanego w menedżerze haseł przeglądarki).
• Sesje powłoki terminalowej (SSH/kubectl) na serwerach produkcyjnych przetwarzających dane kart płatniczych nie są rejestrowane ani nagrywane w formie wideo lub logów sesji tekstowych (brak rozliczalności poleceń powłoki Bash).

Przed zbliżającym się corocznym audytem certyfikacyjnym PCI DSS v4.0 prowadzonym przez Qualified Security Assessor (QSA), Zarząd Spółki zleca zewnętrznemu zespołowi audytorów przeprowadzenie audytu PAM, wyliczenie ryzyka w matrycy 3x3 oraz przygotowanie Planu CAP z analizą 5 Why.

Praca w zespole 2-3 osobowym polega na wszechstronnym zbadaniu procesów uwierzytelniania i autoryzacji w szpitalu oraz zaproponowaniu rozwiązań eliminujących anonimowość pracy personelu:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Architekt Chmurowy FinTech): Odpowiada za analizę ładu chmurowego, wymogów PCI DSS v4.0 i SOC 2 Type II, relacje z CISO i CTO oraz koordynację wystąpienia referatowego.

  Student 2 (Audytor Techniczny PAM / Inżynier Bezpieczeństwa Chmury i Kubernetes): Bada uprawnienia AWS IAM, logi CloudTrail, mechanizmy RBAC w Kubernetes, audytuje wiek kluczy API, analizuje podatności wspólnych kluczy SSH oraz konfigurację sesji Just-In-Time.

  Student 3 (Audytor Zgodności Standardów Płatniczych, Ryzyka i Jakości CAP): Przeprowadza szacowanie ryzyka w matrycy 3x3 dla utraty danych kartowych, kwalifikuje niezgodności wg PCI DSS, prowadzi analizę 5 Why i konstruuje tabelę Planu CAP. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zidentyfikowanych Luk PAM):

  Oceńcie ryzyka w matrycy 3x3:

  • Ryzyko 1: Wyciek bazy danych kart płatniczych przez kompromitację stałych kluczy AWS API na laptopie inżyniera (P=3, S=3 -> R=9).
  • Ryzyko 2: Przejęcie konta AWS Root i zniszczenie infrastruktury przez brak MFA i stałe logowania (P=2, S=3 -> R=6).
  • Ryzyko 3: Niekontrolowana modyfikacja kodu przetwarzającego płatności w kontenerze EKS przez wspólny klucz SSH (P=3, S=3 -> R=9).
  • Ryzyko 4: Utrata certyfikatu PCI DSS v4.0 i nałożenie kar przez organizacje płatnicze Visa/Mastercard (P=3, S=2 -> R=6).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):

  Sformułujcie karty niezgodności z powołaniem na punkty norm i standardów:

  • NC1 (Niezgodność Duża): Stosowanie stałych uprawnień administracyjnych (Standing Privileges), brak rotacji kluczy API oraz używanie wspólnego klucza SSH do środowiska produkcyjnego przetwarzającego dane kart (naruszenie Wymagań 7.2, 7.3, 8.2, 8.3 oraz 8.6 normy PCI DSS v4.0 oraz kontroli A.8.2 i A.8.5 ISO 27001:2022).
  • NC1 (Niezgodność Duża): Wykorzystywanie konta Root w AWS bez sprzętowego tokena MFA do bieżących operacji (rażące naruszenie AWS Well-Architected Security Pillar oraz Wymagania 8.4 PCI DSS).
  • NC2 (Niezgodność Mała): Brak rejestrowania i monitorowania komend powłoki wykonywanych w sesjach uprzywilejowanych w klastrach Kubernetes (kontrola A.8.15 ISO 27001).
  • OFI (Szansa na doskonalenie): Brak wdrożenia mechanizmu automatycznego wykrywania wycieków poświadczeń w repozytoriach kodu (narzędzia klasy Secret Scanning).
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (stosowanie stałych kluczy administratorskich i wspólnego klucza SSH do produkcji) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego programiści posiadali stałe klucze administratora i współdzielili klucz SSH? Bo potrzebowali natychmiastowego dostępu do środowiska w celu debugowania awarii produkcyjnych.

  2. Dlaczego nie wdrożono procedury wnioskowania o dostęp tymczasowy? Bo organizacja nie posiadała narzędzi umożliwiających dynamiczne przydzielanie uprawnień w czasie rzeczywistym.

  3. Dlaczego nie zakupiono i nie wdrożono rozwiązania PAM (np. CyberArk, HashiCorp Vault)? Bo uznano, że wdrożenie PAM spowolni proces wytwórczy oprogramowania (potoki CI/CD) i utrudni pracę zespołowi programistów.

  4. Dlaczego zespół DevSecOps nie zaprojektował bezpiecznego potoku Just-In-Time zintegrowanego z narzędziami deweloperskimi? Bo w firmie panowała kultura "szybkiego dostarczania funkcji biznesowych" (Speed to Market), w której cele bezpieczeństwa były spychane na drugi plan.

  5. Dlaczego kierownictwo FinTechu akceptowało tak wysokie ryzyko operacyjne? (PRZYCZYNA ŹRÓDŁOWA): Brak w firmie sformalizowanego ładu zarządzania tożsamością uprzywilejowaną (PAM Governance) powiązanego z wymogami certyfikacji PCI DSS v4.0 oraz brak świadomości Zarządu co do skali kar finansowych grożących za kompromitację środowiska płatniczego.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.

• Krok 6 (Projekt Architektury PAM i Procedury Just-In-Time):

  Zaprojektujcie:

  • Architekturę Zero Standing Privileges: eliminacja stałych kluczy IAM, logowanie inżynierów przez federację tożsamości (AWS IAM Identity Center) z wymuszeniem kluczy FIDO2, czasowe przyznawanie ról IAM Role (maks. 2 godziny) na wniosek z automatycznym zatwierdzeniem.
  • Wdrożenie sejfu HashiCorp Vault z modułem SSH Secrets Engine (dynamiczne generowanie jednorazowych kluczy certyfikowanych SSH ważnych 15 minut) oraz rejestracją sesji przez Teleport / AWS Systems Manager Session Manager.

Struktura zaawansowanego referatu seminaryjnego (15 minut):

• Wprowadzenie i rygory branży FinTech (3 min): Wymagania PCI DSS v4.0, raport SOC 2 Type II oraz anatomia ataków na chmurę publiczną (Student 1).
• Wyniki audytu IAM i matryca ryzyka 3x3 (4 min): Zestawienie dowodów ze skanów AWS CloudTrail, analiza stałych kluczy API i ryzyka wycieku danych kartowych (R=9) (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie dochodzenia przyczyn źródłowych (presja na Time-to-Market) i kwalifikacja prawna (Student 3).
• Plan CAP i architektura Zero Standing Privileges (4 min): Prezentacja sesji Just-In-Time, sejfu HashiCorp Vault, protokołu FIDO2 oraz bilansu korzyści operacyjnych (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Wyczerpujące odpowiedzi na pytania problemowe i diagnozę systemową:

• Czym różni się paradygmat Zero Standing Privileges (ZSP) od tradycyjnego modelu zarządzania kontami uprzywilejowanymi i w jaki sposób realizuje wytyczne PCI DSS v4.0 w zakresie minimalizacji dostępu (Least Privilege)?
• W jaki sposób technologia Just-In-Time (JIT) powiązana z dynamicznymi certyfikatami SSH / rolami chmurowymi eliminuje ryzyko związane z kradzieżą stałych poświadczeń administratorskich?
• Jakie rygorystyczne wymagania nakłada standard PCI DSS v4.0 (Wymaganie 8) w zakresie uwierzytelniania wieloskładnikowego (MFA) dla wszystkich dostępów do środowiska danych posiadaczy kart (CDE)?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Wyciek danych kartowych PAN przez skradziony klucz AWS API inżyniera -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Eliminacja kluczy statycznych, wdrożenie AWS IAM Identity Center + FIDO2 -> P_rez=1, S_rez=3, R_rez=3 (Pod kontrolą).
  • Ryzyko 2: Kompromitacja klastra Kubernetes przez współdzielony klucz SSH -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Dostęp przez AWS Session Manager / Teleport z jednorazowymi certyfikatami -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Przejęcie konta Root w AWS -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Zablokowanie konta Root, sejf sprzętowy z kluczami FIDO2, alarm w SIEM przy każdym logowaniu -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 4: Utrata zgodności z PCI DSS v4.0 -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Wdrożenie zaleceń Planu CAP przed audytem QSA -> P_rez=1, S_rez=2, R_rez=2.
• Zestawienie Kart Niezgodności: Pełne karty dla 2 Niezgodności Dużych (NC1), 1 Niezgodności Małej (NC2) oraz 1 Szansy na doskonalenie (OFI).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla stałych kluczy administratorskich.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Natychmiastowe unieważnienie stałych kluczy API starszych niż 90 dni i wymuszenie logowania przez AWS IAM Identity Center z kluczami FIDO2 (Właściciel: Główny Inżynier Bezpieczeństwa Chmury, Termin: 7 dni, KPI: zero aktywnych kluczy statycznych IAM).
  • Zadanie CAP-2: Wdrożenie rozwiązania PAM (Teleport Community / AWS SSM) dla klastrów EKS z rejestracją sesji powłoki i eliminacją kluczy SSH `.pem` (Właściciel: Kierownik Zespołu DevOps, Termin: 30 dni, KPI: 100% sesji powłoki logowanych i nagrywanych).
  • Zadanie CAP-3: Zabezpieczenie konta AWS Root fizycznym kluczem sprzętowym YubiKey zdeponowanym w sejfie pancernym Spółki i konfiguracją alarmów CloudWatch (Właściciel: CISO, Termin: 3 dni, KPI: aktywacja sprzętowego MFA, wdrożenie reguły alarmowej w SIEM).
  • Zadanie CAP-4: Wdrożenie polityki i procedury Zero Standing Privileges oraz czasowych wniosków dostępowych JIT (Właściciel: CISO i Dyrektor Operacyjny, Termin: 45 dni, KPI: średni czas ważności uprawnień uprzywilejowanych < 60 minut).
• Projekt Dokumentu: "Standard Zarządzania Dostępem Uprzywilejowanym (PAM) i Architekturą Zero Standing Privileges w Środowisku Chmurowym PayCloud".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Całkowita eliminacja ryzyka wycieku stałych poświadczeń administratorskich; 100% zgodność z wymogami PCI DSS v4.0 i SOC 2 Type II; pełna audytowalność i rozliczalność każdej komendy wpisanej na serwerach produkcyjnych; podniesienie cyberodporności organizacji do standardu Zero Trust.
• Wady i trudności: Konieczność zmiany nawyków inżynierów DevOps i odejścia od tradycyjnego połączenia SSH na rzecz sesji portalowych PAM; narzut czasowy związany z wnioskowaniem o dostępy awaryjne JIT; konieczność utrzymania wysokiej dostępności klastra PAM/Vault.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.8.2 (Uprzywilejowane prawa dostępu), A.8.5 (Bezpieczne uwierzytelnianie), A.8.15 (Rejestrowanie zdarzeń).
• Payment Card Industry Security Standards Council (PCI SSC): "Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures v4.0", Requirement 7 and 8, 2022.
• American Institute of CPAs (AICPA): "SOC 2 - Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy".
• NIST Special Publication 800-207: Zero Trust Architecture, National Institute of Standards and Technology, 2020.
• Amazon Web Services: "AWS Well-Architected Framework - Security Pillar: Identity and Access Management", AWS Whitepapers, 2023.
• Center for Internet Security (CIS): "CIS Amazon Web Services Foundations Benchmark v2.0.0".

• U2 Student identyfikuje luki w konfiguracji IAM w chmurze i klasyfikuje uchybienia do NC1/NC2/OFI wg PCI DSS v4.0.
• U1 Student projektuje architekturę Zero Standing Privileges oraz model sesji Just-In-Time z sejfem sekretów.
• U3 Student przeprowadza analizę ryzyka kompromitacji tożsamości uprzywilejowanych w matrycy 3x3.
• U4 Student realizuje procedurę 5 Why i sporządza profesjonalny Plan Działań Korygujących (CAP).
• W1W2W3 Student zna wymogi PCI DSS v4.0, SOC 2, ISO 27001 oraz paradygmaty Zero Trust i DevSecOps.
• K1K2K3 Student promuje kulturę bezpieczeństwa w środowisku programistycznym, wykazując wysoki profesjonalizm i dbałość o poufność danych klientów.

Głównym celem zadania na ocenę 4.0 jest wykształcenie umiejętności przeprowadzenia zaawansowanego audytu zarządzania tożsamością i dostępem (IAM) w heterogenicznym i otwartym środowisku uczelni wyższej oraz powiązanego z nią Centrum Superkomputerowego (HPC). Zadanie wymaga zbadania skomplikowanych relacji tożsamości wielorolowych (np. doktorant będący jednocześnie studentem studiów III stopnia, zatrudnionym pracownikiem naukowo-dydaktycznym oraz administratorem laboratorium), audytu federacji tożsamości (Eduroam 802.1X, centralny system USOS, LDAP/Active Directory, Shibboleth SAML), weryfikacji kontroli dostępu do zasobów klastra obliczeniowego dużej mocy (HPC) przetwarzającego wrażliwe dane badawcze i technologie podwójnego zastosowania (dual-use), wyliczenia ryzyka w matrycy 3x3, zakwalifikowania niezgodności (NC1/NC2/OFI), przeprowadzenia analizy 5 Why oraz opracowania Planu CAP wprowadzającego separację ról akademickich i pracowniczych oraz wieloskładnikowe uwierzytelnianie odporne na phishing.

Powiązanie z sylabusem i treściami programowymi na ocenę 4.0:

• U2 Wykrywanie i precyzyjna kwalifikacja uchybień w zakresie nakładania się uprawnień studenckich i pracowniczych oraz braku zabezpieczenia infrastruktury badawczej.
• U1 Opracowanie zaawansowanego modelu RBAC/ABAC dla uczelni wyższej, rozdzielającego tożsamość studenta od roli pracownika i badacza, wraz z zasadami bezpiecznego dostępu do klastrów HPC.
• U3 Przeprowadzenie analizy ryzyka sabotażu obliczeń naukowych, wycieku danych z badań o znaczeniu strategicznym (dual-use) oraz naruszenia danych osobowych w matrycy 3x3.
• U4 Opracowanie Planu Działań Korygujących (CAP) opartego na analizie 5 Why, z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.
• W1W2W3 Dogłębna znajomość normy ISO/IEC 27001:2022 (A.5.15-A.5.18, A.8.5), Prawa o szkolnictwie wyższym i nauce, RODO (art. 9 i 32), dyrektywy NIS2 (sektor badań naukowych i edukacji) oraz przepisów o kontroli obrotu technologiami o znaczeniu strategicznym.
• K1K2K3 Zdolność do wyważenia tradycyjnej akademickiej kultury otwartości z rygorami bezpieczeństwa informacji, wysoka etyka naukowa i rzetelność audytorska.
• Powiązanie z wykładem: Wyk1 (Audyt w sektorze akademickim), Wyk3 (Kontrole dostępowe ISO 27001), Wyk4 (NIS2 w badaniach naukowych i RODO w dydaktyce), Wyk5 (Matrycowa analiza ryzyka 3x3), Wyk6 (Analiza logów RADIUS i zarządców zadań Slurm), Wyk7 (Procedura CAP i raportowanie do Rektora).

Politechnika kształci 14 000 studentów na 9 wydziałach i zatrudnia 2 200 pracowników (w tym 1 400 nauczycieli akademickich i badaczy). Przy uczelni funkcjonuje Regionalne Centrum Superkomputerowo-Sieciowe dysponujące klastrem obliczeniowym HPC o mocy 4 PFLOPS (600 węzłów obliczeniowych, zarządzanych przez system kolejkowania Slurm), połączonym z ogólnoeuropejską siecią naukową GÉANT. Na klastrze realizowane są granty badawcze Narodowego Centrum Nauki, analizy genomowe oraz projekty z zakresu aerodynamiki i kryptografii objęte klauzulami technologii podwójnego zastosowania (dual-use).

Stan zastały w obszarze zarządzania tożsamościami i uprawnieniami:

• Podstawowym repozytorium tożsamości jest uczelniany OpenLDAP połączony z bazą systemu USOS (Uniwersytecki System Obsługi Studiów). W strukturze katalogowej każdy użytkownik posiada jeden uniwersalny identyfikator (konto UID).
• W przypadku 140 doktorantów, którzy prowadzą zajęcia laboratoryjne ze studentami, a jednocześnie sami uczestniczą w modułach dydaktycznych, konto UID łączy uprawnienia studenckie i pracownicze. W USOSweb doktoranci mają wgląd do protokołów ocen i egzaminów z przedmiotów, których sami są słuchaczami, co prowadzi do konfliktów interesów i możliwości samowolnej modyfikacji ocen.
• Dostęp do klastra HPC oraz serwerów badawczych realizowany jest przez protokół SSH z wykorzystaniem haseł domenowych lub statycznych kluczy SSH, bez wymuszenia uwierzytelniania wieloskładnikowego (MFA). Co więcej, konta studenckie tworzone na potrzeby zajęć z programowania równoległego mają ten sam poziom uprawnień sieciowych w klastrze co konta zespołów badawczych realizujących projekty dual-use.
• W uczelnianej sieci bezprzewodowej Eduroam (opartej na protokole 802.1X i serwerach FreeRADIUS) nie zaimplementowano segmentacji ruchu: uwierzytelniony student ma bezpośrednią widoczność sieciową stacji roboczych w dziekanacie oraz interfejsów zarządzających IPMI/iDRAC węzłów klastra superkomputerowego.
• W trakcie audytu wykryto 320 aktywnych kont byłych pracowników i absolwentów studiów doktoranckich, którzy opuścili uczelnię ponad rok temu. Z 12 takich kont odnotowano aktywne sesje obliczeniowe na klastrze HPC, wykorzystujące zasoby uczelni do wydobywania kryptowalut (cryptojacking).

Rektor Politechniki, w związku z wymogami dyrektywy NIS2 obejmującej instytucje badawcze oraz incydentem wycieku danych z projektu strategicznego, powołuje zespół audytorski w celu pilnego audytu IAM, wyliczenia ryzyka w matrycy 3x3 i sporządzenia Planu CAP.

Praca w zespole 2-3 osobowym polega na wszechstronnym zbadaniu procesów uwierzytelniania i autoryzacji w szpitalu oraz zaproponowaniu rozwiązań eliminujących anonimowość pracy personelu:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Ekspert Bezpieczeństwa Akademickiego): Analizuje regulaminy studiów, procedury nadawania ról w USOS, relacje z Rektorem i Dziekanami, zgodność z Prawem o szkolnictwie wyższym i NIS2 oraz koordynuje referat.

  Student 2 (Audytor Techniczny IAM / Inżynier HPC i Sieci): Bada strukturę OpenLDAP/AD, konfigurację RADIUS/Eduroam, konfigurację zarządcy kolejkowego Slurm, podatności statycznych kluczy SSH oraz brak segmentacji sieciowej VLAN.

  Student 3 (Audytor Zgodności Regulacyjnej RODO, Ryzyka i Jakości CAP): Przeprowadza szacowanie ryzyka w matrycy 3x3 dla manipulacji ocenami i wycieku badań dual-use, klasyfikuje niezgodności, prowadzi analizę 5 Why i konstruuje tabelę Planu CAP. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zidentyfikowanych Luk IAM):

  Oceńcie ryzyka w matrycy 3x3:

  • Ryzyko 1: Wyciek wyników badań o znaczeniu strategicznym (dual-use) z klastra HPC z powodu braku MFA i separacji kont (P=3, S=3 -> R=9).
  • Ryzyko 2: Nieautoryzowana modyfikacja ocen w systemie USOS przez doktorantów z rolami wielokrotnymi (P=3, S=2 -> R=6).
  • Ryzyko 3: Nieuprawniony dostęp do zasobów dziekanatu z sieci Eduroam przez brak segmentacji (P=3, S=2 -> R=6).
  • Ryzyko 4: Nielegalne wykorzystanie mocy obliczeniowej HPC do cryptojackingu przez konta byłych doktorantów (P=3, S=2 -> R=6).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):

  Sformułujcie karty niezgodności z powołaniem na punkty norm i przepisów:

  • NC1 (Niezgodność Duża): Brak separacji tożsamości i uprawnień wielorolowych (student vs nauczyciel) w systemie USOS oraz brak kontroli dostępu do projektów badawczych o znaczeniu strategicznym (naruszenie kontroli A.5.15, A.5.17 ISO 27001:2022 oraz art. 32 RODO).
  • NC1 (Niezgodność Duża): Dostęp do produkcyjnych zasobów klastra superkomputerowego HPC przez pojedyncze hasło SSH bez uwierzytelniania wieloskładnikowego MFA (naruszenie kontroli A.8.5 ISO 27001 oraz wymogów dyrektywy NIS2 dla sektora badań).
  • NC2 (Niezgodność Mała): Pozostawienie aktywnych kont i dostępu do sieci Eduroam/HPC dla byłych pracowników i doktorantów (naruszenie kontroli A.5.18 ISO 27001).
  • OFI (Szansa na doskonalenie): Brak wdrożenia centralnego portalu do zarządzania kluczami SSH i certyfikatami użytkowników klastra HPC.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (brak separacji tożsamości doktorantów w USOS i nakładanie się uprawnień) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego doktoranci posiadali dostęp do modyfikacji ocen z przedmiotów, w których sami uczestniczyli? Bo w bazie USOS przypisano im pojedyncze konto łączące atrybuty studenta i pracownika dydaktycznego.

  2. Dlaczego nie utworzono dwóch odrębnych kont? Bo uczelniany system OpenLDAP narzucał regułę "jeden numer PESEL = jedno konto UID" w całej uczelni.

  3. Dlaczego architektura LDAP narzucała taką regułę? Bo została wdrożona 15 lat temu wyłącznie na potrzeby poczty studenckiej i nigdy nie została zmodernizowana pod kątem ról wielokrotnych.

  4. Dlaczego Dział IT nie zmodernizował architektury tożsamości po reformie studiów doktoranckich (utworzeniu Szkół Doktorskich)? Bo uznano, że wymagałoby to modyfikacji integracji z zewnętrznym systemem USOS, na co brakowało środków i zgody władz uczelni.

  5. Dlaczego władze uczelni nie podjęły decyzji o restrukturyzacji IAM? (PRZYCZYNA ŹRÓDŁOWA): Brak na uczelni formalnego Systemu Zarządzania Bezpieczeństwem Informacji (ISMS) oraz CISO o umocowaniu decyzyjnym, co powodowało traktowanie kontroli dostępu jako problemu informatycznego, a nie strategicznego ryzyka prawnego i wizerunkowego.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.

• Krok 6 (Projekt Rozwiązania Technicznego i Nowego Modelu IAM):

  Zaprojektujcie:

  • Nowy model tożsamości wielokontekstowej: rozdzielenie konta prywatnego studenta (`s123456@student.politechnika.pl`) od konta służbowego asystenta/doktoranta (`jan.kowalski@politechnika.pl`) z odrębnymi poświadczeniami i profilami uprawnień w USOS.
  • Architekturę bezpieczeństwa HPC: brama dostępowa Bastion SSH z wymuszonym MFA (FIDO2 / TOTP), dynamiczny przydział węzłów w Slurm z izolacją pamięci i sieci dla projektów dual-use, segmentacja sieci Eduroam (izolacja stacji studenckich w prywatnym VLAN z odcięciem od infrastruktury zarządzającej).

Struktura zaawansowanego referatu seminaryjnego (15 minut):

• Wprowadzenie i specyfika sektora akademicko-badawczego (3 min): Otwartość uczelni a rygory NIS2, waga badań strategicznych i klastrów HPC (Student 1).
• Wyniki audytu IAM i matryca ryzyka 3x3 (4 min): Przedstawienie dowodów konfliktu ról w USOS, cryptojackingu na klastrze HPC (R=9) i luk w Eduroam (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie ścieżki dochodzenia do pierwotnej przyczyny (zastarzały schemat LDAP) i kwalifikacja prawna (Student 3).
• Plan CAP i nowy model tożsamości wielorolowej (4 min): Prezentacja separacji kont, bramy Bastion MFA dla HPC, izolacji VLAN oraz bilansu wad i zalet (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Wyczerpujące odpowiedzi na pytania problemowe i diagnozę systemową:

• W jaki sposób zorganizować kontrolę dostępu opartą na rolach (RBAC) w uczelni wyższej, aby skutecznie zapobiec konfliktowi interesów wynikającemu z pełnienia przez tę samą osobę roli studenta i nauczyciela akademickiego?
• Jakie specyficzne wymagania w zakresie bezpieczeństwa informacji i kontroli dostępu nakłada dyrektywa NIS2 na sektor szkolnictwa wyższego i jednostki prowadzące badania naukowe o znaczeniu krytycznym?
• W jaki sposób zabezpieczyć dostęp do klastrów obliczeniowych dużej mocy (HPC) przed nieautoryzowanym wykorzystaniem (np. cryptojacking) oraz kompromitacją danych badawczych podlegających przepisom o technologiach podwójnego zastosowania (dual-use)?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Wykradzenie danych z projektów dual-use z klastra HPC przez brak MFA -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Bastion SSH z MFA (FIDO2) + separacja zadań Slurm -> P_rez=1, S_rez=3, R_rez=3 (Pod kontrolą).
  • Ryzyko 2: Sfałszowanie protokołów ocen w USOS przez doktoranta -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Rozdzielenie kont studenckich i pracowniczych w LDAP/USOS -> P_rez=1, S_rez=2, R_rez=2.
  • Ryzyko 3: Nieuprawniony dostęp do węzłów zarządzających z sieci Eduroam -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Dynamiczny VLAN na kontrolerze Wi-Fi + blokada portów IPMI -> P_rez=1, S_rez=2, R_rez=2.
  • Ryzyko 4: Utrata mocy obliczeniowej HPC przez cryptojacking byłych doktorantów -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Automatyczna dezaktywacja kont po obronie doktoratu -> P_rez=1, S_rez=2, R_rez=2.
• Zestawienie Kart Niezgodności: Pełne karty dla 2 Niezgodności Dużych (NC1), 1 Niezgodności Małej (NC2) oraz 1 Szansy na doskonalenie (OFI).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla nakładania się uprawnień w USOS.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Wdrożenie rozdzielenia tożsamości (konto studenckie vs pracownicze) w strukturze LDAP i systemie USOS dla 140 doktorantów (Właściciel: Kierownik Centrum Informatycznego Uczelni, Termin: 30 dni, KPI: zero kont łączonych w USOS).
  • Zadanie CAP-2: Uruchomienie bramy bastionowej SSH z wymuszeniem uwierzytelniania dwuskładnikowego MFA dla dostępu do węzłów klastra HPC (Właściciel: Główny Administrator HPC, Termin: 21 dni, KPI: 100% połączeń badawczych autoryzowanych z MFA).
  • Zadanie CAP-3: Wdrożenie dynamicznego przypisywania VLAN w sieci Eduroam (izolacja ruchu studenckiego od sieci administracyjnej i serwerowej) (Właściciel: Kierownik Sekcji Sieciowej, Termin: 14 dni, KPI: całkowita blokada dostępu z Wi-Fi do podsieci IPMI/dziekanatu).
  • Zadanie CAP-4: Przeprowadzenie audytu i dezaktywacji 320 martwych kont byłych pracowników i doktorantów (Właściciel: Dział Kadr i Administrator LDAP, Termin: 14 dni, KPI: usunięcie kont, eliminacja cryptojackingu).
• Projekt Procedury: "Polityka Zarządzania Tożsamościami Akademickimi, Dostępem do Systemu USOS oraz Bezpieczeństwa Obliczeń w Regionalnym Centrum Superkomputerowym".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Wyeliminowanie możliwości manipulacji ocenami w USOS; zabezpieczenie strategicznych projektów badawczych przed szpiegostwem przemysłowym i kradzieżą własności intelektualnej; spełnienie rygorów NIS2; odzyskanie zasobów klastra HPC marnotrawionych na cryptojacking.
• Wady i trudności: Konieczność posługiwania się przez doktorantów dwoma odrębnymi kontami i poświadczeniami; początkowy opór części kadry naukowej przed wymogiem logowania wieloskładnikowego do klastra obliczeniowego; nakład pracy administracyjnej związany z przebudową schematu LDAP.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.5.15 (Zarządzanie tożsamością), A.5.16 (Uwierzytelnianie tożsamości), A.5.17 (Prawa dostępu), A.5.18 (Prawa dostępu do informacji), A.8.5 (Bezpieczne uwierzytelnianie).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - sektor badań naukowych i edukacji wyższej.
• Ustawa z dnia 20 lipca 2018 r. - Prawo o szkolnictwie wyższym i nauce (Dz.U. z 2023 r. poz. 742 z późn. zm.).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 9 i 32.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2021/821 ustanawiające unijny system kontroli wywozu, pośrednictwa, pomocy technicznej, tranzytu i transferu produktów podwójnego zastosowania (Dual-Use).
• GÉANT Association: "Eduroam Compliance Statement and Security Guidelines", 2023.
• Slurm Workload Manager: "Security and Multi-Tenancy Architecture Guide", SchedMD.

• U2 Student wykrywa i klasyfikuje niezgodności w zarządzaniu tożsamościami akademickimi i klastrami obliczeniowymi.
• U1 Student projektuje schemat separacji tożsamości wielorolowych oraz bezpieczny dostęp MFA do zasobów HPC.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla naruszenia integralności danych dydaktycznych i badawczych.
• U4 Student realizuje procedurę 5 Why i sporządza Plan Działań Korygujących (CAP) spełniający standardy ISMS.
• W1W2W3 Student zna regulacje NIS2 dla badań, RODO w szkolnictwie, Prawo o szkolnictwie wyższym oraz zasady ochrony technologii dual-use.
• K1K2K3 Student łączy poszanowanie dla akademickiej kultury dialogu z rygoryzmem technicznym i dbałością o bezpieczeństwo państwa.

Głównym celem zadania na ocenę 4.0 jest wykształcenie zaawansowanych umiejętności audytu kontroli dostępu i zarządzania tożsamościami użytkowników tymczasowych w podmiocie logistycznym o statusie podmiotu kluczowego w rozumieniu dyrektywy NIS2 (sektor usług pocztowych i logistycznych). Zadanie koncentruje się na specyfice pracy w magazynach centralnych i centrach przeładunkowych (cross-dock), gdzie występuje wysoka rotacja pracowników agencyjnych (pracownicy tymczasowi z 4 różnych agencji pracy). Zadanie wymaga zbadania mechanizmów uwierzytelniania na mobilnych terminalach kodów kreskowych (skanery Android Enterprise w systemie WMS), zidentyfikowania patologii stosowania kont współdzielonych i anonimowych kart RFID, wyliczenia ryzyka strat magazynowych i wycieku danych adresowych w matrycy 3x3, zakwalifikowania niezgodności (NC1/NC2/OFI), przeprowadzenia analizy 5 Why oraz opracowania Planu CAP wprowadzającego automatyczny provisioning tożsamości agencyjnych przez API, logowanie kodem dynamicznym/FIDO2, geofencing logowań oraz pełną rozliczalność skanowania paczek.

Powiązanie z sylabusem i treściami programowymi na ocenę 4.0:

• U2 Profesjonalne wykrywanie i gradacja niezgodności w zarządzaniu tożsamościami pracowników tymczasowych oraz braku rozliczalności operacji magazynowych.
• U1 Opracowanie nowoczesnej architektury IAM dla terminali mobilnych WMS łączącej ergonomię szybkiego skanowania z indywidualną odpowiedzialnością materialną.
• U3 Przeprowadzenie analizy ryzyka kradzieży towarów o wysokiej wartości (elektronika), podmiany paczek oraz wycieku danych osobowych odbiorców w matrycy 3x3.
• U4 Opracowanie Planu Działań Korygujących (CAP) z analizą przyczyn źródłowych (5 Why), mierzalnymi wskaźnikami KPI i terminami 14-90 dni.
• W1W2W3 Biegła znajomość wymogów RODO (art. 5 ust. 1 lit. f, art. 5 ust. 2, art. 32), dyrektywy NIS2 (sektor logistyki i dostaw), Prawa pocztowego (tajemnica pocztowa) oraz normy ISO/IEC 27001:2022 (A.5.16, A.5.18, A.8.5).
• K1K2K3 Zdolność do analizy procesów masowych, asertywność wobec presji operacyjnej kierownictwa magazynu oraz poszanowanie praw pracowników tymczasowych.
• Powiązanie z wykładem: Wyk1 (Audyt w logistyce), Wyk3 (Kontrole dostępowe A.5 i A.8 ISO 27001), Wyk4 (NIS2 i RODO w łańcuchu dostaw), Wyk5 (Matrycowa analiza ryzyka 3x3), Wyk6 (Analiza logów skanowania terminali WMS), Wyk7 (Metodyka CAP i raportowanie do Zarządu).

LogiXpress S.A. jest jednym z największych operatorów logistycznych w Europie Środkowej, obsługującym sieć 18 000 automatycznych maszyn paczkowych oraz 12 wielkich centrów dystrybucyjnych. W głównym magazynie centralnym pod Warszawą o powierzchni 75 000 m2 przetwarzanych jest dobowo ponad 650 000 przesyłek. W magazynie na 3 zmianach pracuje 1 200 pracowników magazynowych, z czego aż 70% stanowią obcokrajowcy zatrudniani przez 4 zewnętrzne agencje pracy tymczasowej o rotacji sięgającej 40% miesięcznie.

Stan zastały w obszarze kontroli dostępu do mobilnego systemu zarządzania magazynem (WMS):

• Podstawowym narzędziem pracy magazynierów są przenośne terminale skanujące Zebra z systemem Android Enterprise, połączone z centralnym systemem WMS przez sieć Wi-Fi.
• Ze względu na ogromną rotację pracowników i brak czasu na codzienne tworzenie kont imiennych w Active Directory, brygadziści logują wszystkie terminale na jedno wspólne konto domenowe: "magazyn_skaner_ogolny".
• W samej aplikacji WMS magazynierzy logują się za pomocą kart zbliżeniowych przypisanych nie do osoby, lecz do numeru skanera (np. karta "Skaner_44"). Karty te leżą w ogólnodostępnych skrzynkach przy wejściu do hali. Każdy pracownik wchodzący na zmianę bierze dowolny skaner i dowolną kartę.
• W toku audytu bezpieczeństwa wewnętrznego stwierdzono ubytek towarów luksusowych (smartfony, laptopy) o łącznej wartości 1,4 mln PLN w okresie ostatnich 4 miesięcy. W trakcie analizy logów WMS okazało się, że skanowanie statusu "Paczka uszkodzona / brak zawartości" było wykonywane z terminala zalogowanego na generyczne konto "Skaner_44", z którego w ciągu jednej zmiany korzystało 6 różnych pracowników agencyjnych, co uniemożliwiło pociągnięcie sprawców do odpowiedzialności materialnej i karnej.
• Co więcej, terminale WMS wyświetlają pełne dane osobowe odbiorców przesyłek (imię, nazwisko, dokładny adres doręczenia, numer telefonu oraz zadeklarowaną wartość towaru), co przy braku rozliczalności doprowadziło do procederu wycieku danych klientów zamawiających drogi sprzęt elektroniczny (zorganizowana grupa przestępcza typowała adresy do włamań).
• Wykryto również, że sieć Wi-Fi dla terminali magazynowych nie posiada geofencingu ani izolacji: sygnał sieci wykracza poza teren ogrodzenia centrum logistycznego, a poświadczenia WPA2-Enterprise do sieci magazynowej były powszechnie znane i wykorzystywane przez byłych pracowników do pobierania baz zamówień z parkingu przed centrum.

Zarząd LogiXpress S.A., w obliczu kontroli UODO oraz audytu certyfikacyjnego na podmiot kluczowy NIS2, powołuje zespół audytorski w celu pilnego opracowania planu likwidacji anonimowości w magazynie, wyliczenia ryzyka w matrycy 3x3 oraz sporządzenia Planu CAP.

Praca w zespole 2-3 osobowym polega na wszechstronnym zbadaniu procesów uwierzytelniania i autoryzacji w szpitalu oraz zaproponowaniu rozwiązań eliminujących anonimowość pracy personelu:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Ekspert Logistyki i NIS2): Bada umowy z agencjami pracy tymczasowej, regulamin odpowiedzialności materialnej, zgodność z dyrektywą NIS2 i Prawem pocztowym oraz koordynuje wystąpienie referatowe.

  Student 2 (Audytor Techniczny IAM / Inżynier Bezpieczeństwa Mobilnego i WMS): Bada konfigurację MDM/Android Enterprise na terminalach Zebra, analizuje logi systemu WMS, konfigurację kontrolerów Wi-Fi i geofencingu oraz architekturę szybkiego logowania kodem PIN/kodem 2D.

  Student 3 (Audytor Prawno-Regulacyjny RODO, Ryzyka i Jakości CAP): Ocenia naruszenia tajemnicy pocztowej i RODO (masowy wyciek danych adresowych), przeprowadza szacowanie ryzyka w matrycy 3x3, prowadzi analizę 5 Why i konstruuje tabelę Planu CAP. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zidentyfikowanych Luk IAM):

  Oceńcie ryzyka w matrycy 3x3:

  • Ryzyko 1: Masowe kradzieże towarów bez możliwości ustalenia sprawcy z powodu kont anonimowych (P=3, S=3 -> R=9).
  • Ryzyko 2: Wyciek danych adresowych odbiorców paczek do grup przestępczych (P=3, S=3 -> R=9).
  • Ryzyko 3: Nieuprawniony podsłuch sieci Wi-Fi magazynowej z parkingu z powodu braku geofencingu (P=2, S=2 -> R=4).
  • Ryzyko 4: Kara Prezesa UODO za brak rozliczalności i niezachowanie tajemnicy pocztowej (P=3, S=2 -> R=6).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):

  Sformułujcie karty niezgodności z powołaniem na punkty norm i przepisów:

  • NC1 (Niezgodność Duża): Całkowity brak rozliczalności użytkowników terminali WMS poprzez stosowanie wspólnych kont i anonimowych kart RFID (naruszenie art. 5 ust. 2 i art. 32 RODO, kontroli A.5.15, A.5.16 ISO 27001:2022 oraz przepisów Prawa pocztowego).
  • NC1 (Niezgodność Duża): Wyświetlanie pełnych danych osobowych odbiorców bez potrzeby biznesowej (naruszenie zasady minimalizacji danych art. 5 ust. 1 lit. c RODO oraz kontroli A.5.18 ISO 27001).
  • NC2 (Niezgodność Mała): Emisja sygnału sieci Wi-Fi poza granice fizyczne magazynu bez ograniczeń geofencingowych (kontrola A.7.4 ISO 27001).
  • OFI (Szansa na doskonalenie): Brak wdrożenia logowania do terminali za pomocą biometrii odcisku palca wbudowanej w skanery Zebra nowej generacji.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (stosowanie kont anonimowych i kart przypisanych do skanerów) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego pracownicy magazynu używają wspólnych kart "Skaner_44"? Bo agencje pracy przesyłają listy pracowników rano w dniu rozpoczęcia zmiany i IT nie nadąża z tworzeniem kont imiennych.

  2. Dlaczego IT nie nadąża z tworzeniem kont? Bo proces zakładania konta wymagał ręcznego wprowadzania danych przez administratora w systemie domenowym.

  3. Dlaczego nie zintegrowano systemów agencji pracy tymczasowej z systemem tożsamości LogiXpress? Bo uznano, że koszt wdrożenia API z 4 różnymi agencjami przewyższa korzyści przy tak dużej rotacji personelu.

  4. Dlaczego kierownictwo operacyjne magazynu nie domagało się rozliczalności pracowników? Bo priorytetem dyrekcji logistyki była przepustowość paczek na godzinę (KPI operacyjne), a straty z tytułu kradzieży były wpisywane w koszty ryzyka biznesowego.

  5. Dlaczego dopuszczono do przedkładania wskaźników operacyjnych nad bezpieczeństwo i prawo? (PRZYCZYNA ŹRÓDŁOWA): Brak w Spółce ładu bezpieczeństwa wymuszonego przez normę ISO 27001 i NIS2, uzależniającego dopuszczenie pracownika do operacji magazynowych od posiadania unikalnej, zweryfikowanej tożsamości cyfrowej.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.

• Krok 6 (Projekt Rozwiązania Technicznego i Nowej Procedury IAM w Magazynie):

  Zaprojektujcie:

  • Zautomatyzowany provisioning tożsamości przez API REST: agencja pracy przesyła listę pracowników z 2-godzinnym wyprzedzeniem; system IAM automatycznie generuje imienny kod QR/kod kreskowy drukowany na identyfikatorze pracowniczym przy bramce wejściowej.
  • Szybkie logowanie do terminala Zebra: pracownik skanuje swój imienny kod QR z identyfikatora i wpisuje 4-cyfrowy PIN ustalany przy pierwszym wejściu (czas logowania < 3 sekundy); wdrożenie maskowania danych osobowych w WMS (widoczne tylko pierwsze litery nazwiska i miasto doręczenia, pełne dane odblokowywane wyłącznie w momencie pakowania).
  • Geofencing Wi-Fi: ograniczenie mocy nadajników AP przy ścianach zewnętrznych i blokada logowań spoza strefy operacyjnej magazynu.

Struktura zaawansowanego referatu seminaryjnego (15 minut):

• Wprowadzenie i wyzwania branży kuriersko-logistycznej (3 min): Rola LogiXpress, skala rotacji pracowników agencyjnych i rygory dyrektywy NIS2 (Student 1).
• Wyniki audytu IAM i matryca ryzyka 3x3 (4 min): Przedstawienie strat magazynowych (1,4 mln PLN), anonimowości skanerów, ryzyka wycieku danych adresowych (R=9) (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie ścieżki dochodzenia do pierwotnej przyczyny (brak automatyzacji z agencjami) i kwalifikacja prawna (Student 3).
• Plan CAP i nowoczesna architektura IAM dla WMS (4 min): Prezentacja logowania kodami QR/PIN, maskowania danych w WMS, geofencingu Wi-Fi oraz bilansu wad i zalet (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Wyczerpujące odpowiedzi na pytania problemowe i diagnozę systemową:

• W jaki sposób zasada rozliczalności (art. 5 ust. 2 RODO) musi być interpretowana w odniesieniu do pracowników agencyjnych i podwykonawców wykonujących czynności fizyczne w systemach informatycznych administratora?
• Dlaczego maskowanie danych osobowych (Data Masking) na ekranach urządzeń mobilnych magazynierów jest koniecznym środkiem technicznym w myśl zasady Privacy by Design i jak je zaimplementować w systemie WMS?
• W jaki sposób zaprojektować bezpieczny, a zarazem ultra-szybki proces uwierzytelniania na terminalach magazynowych, aby zmiana pracownika przy urządzeniu nie obniżała wydajności sortowania paczek?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Kradzieże paczek przez pracowników agencyjnych bez możliwości identyfikacji -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Imienne logowanie kodem QR/PIN generowanym przez API -> P_rez=1, S_rez=3, R_rez=3 (Pod kontrolą).
  • Ryzyko 2: Wyciek danych adresowych klientów z ekranów terminali WMS -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Wdrożenie maskowania danych osobowych w aplikacji mobilnej -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Nieuprawniony dostęp do sieci Wi-Fi magazynu z parkingu -> P_inh=2, S_inh=2, R_inh=4 -> Kontrola: Strojenie mocy anten Wi-Fi + uwierzytelnianie certyfikatami 802.1X -> P_rez=1, S_rez=2, R_rez=2.
  • Ryzyko 4: Kary UODO i utrata reputacji operatora logistycznego -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Wdrożenie zintegrowanego Planu CAP i procedury rozliczalności -> P_rez=1, S_rez=2, R_rez=2.
• Zestawienie Kart Niezgodności: Pełne karty dla 2 Niezgodności Dużych (NC1), 1 Niezgodności Małej (NC2) oraz 1 Szansy na doskonalenie (OFI).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla anonimowości pracy magazynierów.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Uruchomienie bramki API REST integrującej systemy 4 agencji pracy z modułem provisioningu tożsamości WMS (Właściciel: Kierownik Działu Integracji IT, Termin: 30 dni, KPI: 100% pracowników tymczasowych z zarejestrowanym kontem przed wejściem na halę).
  • Zadanie CAP-2: Wdrożenie mechanizmu logowania imiennym kodem QR + PIN na 400 terminalach Zebra (Właściciel: Administrator Systemu WMS, Termin: 21 dni, KPI: całkowita likwidacja kont generycznych, czas logowania < 3 sekundy).
  • Zadanie CAP-3: Zmiana w interfejsie aplikacji WMS wprowadzająca maskowanie danych osobowych odbiorców (Właściciel: Lead Developer WMS, Termin: 14 dni, KPI: brak widoczności pełnych danych adresowych na terminalach).
  • Zadanie CAP-4: Rekonfiguracja kontrolerów Wi-Fi Cisco: optymalizacja zasięgu fal radiowych w obrysie hali i wdrożenie certyfikatów maszynowych (Właściciel: Inżynier Sieci Bezprzewodowych, Termin: 14 dni, KPI: brak sygnału Wi-Fi WMS poza terenem obiektu).
• Projekt Procedury: "Regulamin Bezpieczeństwa Tożsamości i Kontroli Dostępu do Urządzeń Mobilnych i Systemu WMS w Centrach Dystrybucyjnych LogiXpress S.A.".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Całkowite wyeliminowanie bezkarności i anonimowości kradzieży towarów na hali; redukcja strat magazynowych o ponad 90%; pełna zgodność z RODO i NIS2; ochrona danych adresowych klientów przed zorganizowaną przestępczością.
• Wady i trudności: Koszt prac programistycznych przy integracji API z agencjami pracy; konieczność przeszkolenia obcojęzycznych pracowników w obsłudze logowania kodem QR i PIN; narzut czasu przy drukowaniu identyfikatorów przy bramkach.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.5.15 (Zarządzanie tożsamością), A.5.16 (Uwierzytelnianie tożsamości), A.5.18 (Prawa dostępu do informacji), A.7.4 (Monitorowanie bezpieczeństwa fizycznego), A.8.5 (Bezpieczne uwierzytelnianie).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - sektor usług pocztowych i logistycznych.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO) - art. 5 ust. 1 lit. c, art. 5 ust. 2, art. 32.
• Ustawa z dnia 23 listopada 2012 r. - Prawo pocztowe (Dz.U. z 2023 r. poz. 1640 z późn. zm.) - tajemnica pocztowa.
• Ustawa z dnia 9 lipca 2003 r. o zatrudnianiu pracowników tymczasowych (Dz.U. z 2023 r. poz. 1110 z późn. zm.).
• Zebra Technologies: "Best Practices for Securing Android Enterprise Mobile Computers in Warehouse Environments", 2023.

• U2 Student wykrywa i klasyfikuje uchybienia w rozliczalności i uwierzytelnianiu pracowników tymczasowych.
• U1 Student projektuje ergonomiczny proces szybkiego provisioningu tożsamości agencyjnych i logowania QR/PIN.
• U3 Student szacuje ryzyka kradzieży magazynowych i wycieku danych w matrycy 3x3.
• U4 Student realizuje procedurę 5 Why i konstruuje Plan Działań Korygujących (CAP) spełniający standardy NIS2.
• W1W2W3 Student zna przepisy RODO, NIS2, Prawa pocztowego oraz standardy bezpieczeństwa mobilnego.
• K1K2K3 Student potrafi łączyć wymagania rygorystycznego bezpieczeństwa z realiami dynamicznej pracy logistycznej.

Głównym celem zadania na ocenę 4.0 jest wykształcenie umiejętności przeprowadzenia zaawansowanego audytu kontroli dostępu w jednostce wymiaru sprawiedliwości (Sąd Apelacyjny wraz z podległymi Sądami Okręgowymi i Rejonowymi) przetwarzającej informacje o najwyższym stopniu wrażliwości prawnej i społecznej (sprawy karne z udziałem świadków koronnych, sprawy lustracyjne, tajemnice handlowe w sporach gospodarczych, sprawy rozwodowe i opiekuńcze z wyłączeniem jawności). Zadanie koncentruje się na zbadaniu hybrydowego modelu kontroli dostępu łączącego role użytkowników z atrybutami kontekstowymi (ang. Attribute-Based Access Control - ABAC z RBAC). Zadanie wymaga zidentyfikowania patologii dostępu horyzontalnego asystentów i sekretarzy do akt spraw spoza ich referatu, zbadania ochrony tajemnicy narady sędziowskiej w systemie Elektronicznego Zarządzania Sprawami, wyliczenia ryzyka w matrycy 3x3, zakwalifikowania niezgodności (NC1/NC2/OFI), przeprowadzenia analizy 5 Why oraz opracowania Planu CAP wprowadzającego ścisłe reguły ABAC oraz detekcję anomalii logowań poza godzinami urzędowania.

Powiązanie z sylabusem i treściami programowymi na ocenę 4.0:

• U2 Profesjonalne wykrywanie i gradacja niezgodności w zakresie nadmiarowości uprawnień, naruszenia tajemnic sądowych i braku kontroli atrybutowej (ABAC).
• U1 Opracowanie zaawansowanego modelu ABAC dla wymiaru sprawiedliwości uwzględniającego atrybuty: identyfikator sądu, wydział, numer referatu, funkcja w składzie orzekającym, status jawności sprawy.
• U3 Przeprowadzenie analizy ryzyka dekonspiracji świadków koronnych, wycieku projektów wyroków przed ogłoszeniem oraz naruszenia dóbr osobistych stron procesu w matrycy 3x3.
• U4 Opracowanie Planu Działań Korygujących (CAP) opartego na analizie 5 Why, z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.
• W1W2W3 Dogłębna znajomość Ustawy - Prawo o ustroju sądów powszechnych, Kodeksu postępowania cywilnego i karnego (tajemnica narady sędziowskiej), Ustawy o ochronie informacji niejawnych, par. 20 KRI oraz normy ISO/IEC 27001:2022 (A.5.15, A.5.18, A.8.2).
• K1K2K3 Bezwzględna dbałość o praworządność, niezawisłość sędziowską, dyskrecję i etykę zawodową w kontakcie z wrażliwymi informacjami procesowymi.
• Powiązanie z wykładem: Wyk1 (Audyt w wymiarze sprawiedliwości), Wyk3 (Kontrole A.5.18 i A.8.2 ISO 27001), Wyk4 (KRI i ochrona informacji niejawnych), Wyk5 (Risk-based audit w sądownictwie i matryca 3x3), Wyk6 (Analiza logów dostępu do repertoriów sądowych), Wyk7 (Metodyka CAP i raportowanie do Prezesa Sądu).

Sąd Apelacyjny wraz z podległą apelacją (4 Sądy Okręgowe i 22 Sądy Rejonowe) zatrudnia łącznie 450 sędziów i asesorów, 380 asystentów sędziów oraz 1 100 pracowników sekretariatów i protokolantów. Wszystkie jednostki korzystają ze zintegrowanego systemu teleinformatycznego obsługi biurowości sądowej (Currenda / Sędzia2) oraz Centralnego Portalu Informacyjnego Sądów Powszechnych.

Stan zastały w obszarze zarządzania tożsamościami i prawami dostępu:

• Wdrożony model uprawnień w systemie biurowości opiera się na uproszczonym modelu RBAC, w którym zdefiniowano zaledwie 4 ogólne profile: "Sędzia", "Asystent", "Kierownik Sekretariatu", "Sekretarz/Protokolant".
• Profil "Asystent sędziego" posiada domyślne uprawnienia wglądu i edycji do wszystkich spraw zarejestrowanych we wszystkich wydziałach danego sądu (Wydział Karny, Cywilny, Gospodarczy, Pracy i Ubezpieczeń Społecznych, Rodzinny). W efekcie asystent pracujący w Wydziale Pracy może bez żadnych przeszkód i bez alertowania przełożonych przeglądać akta rozwodowe swoich sąsiadów, akta spraw karnych o przestępstwa seksualne czy dokumenty z wycenami majątkowymi w sporach biznesowych.
• W sprawach karnych o przestępczość zorganizowaną, w których występują świadkowie koronni i materiały niejawne, pliki uzasadnień wyroków oraz protokoły zeznań są zapisywane w systemie biurowości sądowej bez oznaczenia klauzulowego, co umożliwia dostęp do nich ponad 80 osobom z personelu pomocniczego sądu.
• W module edycji wyroków brak jest mechanizmu technicznej ochrony "tajemnicy narady sędziowskiej" (art. 108 Kodeksu postępowania karnego): projekt wyroku sporządzany przez sędziego sprawozdawcę lub asystenta na kilka dni przed terminem publikacji orzeczenia jest dostępny w folderze współdzielonym dla wszystkich protokolantów wydziału, co stwarza ryzyko spekulacji giełdowych lub nacisków na skład orzekający.
• Analiza logów dostępowych z ostatnich 3 miesięcy wykazała 410 przypadków logowania się pracowników sekretariatów w godzinach między 23:00 a 04:00 rano z prywatnych adresów IP za pośrednictwem sądowego serwera dostępu zdalnego, podczas których pobierano hurtowe ilości dokumentów procesowych w formatach PDF i DOCX (brak modułu detekcji anomalii zachowań użytkowników - UEBA).

Prezes Sądu Apelacyjnego, po anonimowym doniesieniu o oferowaniu odpłatnego wglądu do akt głośnego procesu gospodarczego, zarządza pilny audyt kontroli dostępu, wyliczenie ryzyk w matrycy 3x3 oraz wdrożenie Planu CAP z modelem ABAC.

Praca w zespole 2-3 osobowym polega na wszechstronnym zbadaniu procesów uwierzytelniania i autoryzacji w szpitalu oraz zaproponowaniu rozwiązań eliminujących anonimowość pracy personelu:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Prawnik - Ekspert Ustroju Sądów): Bada ramy prawne (Prawo o ustroju sądów, KPK, KPC), procedury obiegu akt sądowych, tajemnicę narady sędziowskiej, relacje z Prezesem Sądu i koordynuje referat.

  Student 2 (Audytor Techniczny IAM / Inżynier Systemów Sądowych): Analizuje strukturę bazy danych systemu Currenda/Sędzia2, konfigurację ról RBAC, projektuje model ABAC (atrybuty kontekstowe), bada logi dostępu i procedury szyfrowania projektów orzeczeń.

  Student 3 (Audytor Zgodności KRI, Ochrony Danych i Jakości CAP): Przeprowadza ocenę naruszeń par. 20 KRI i RODO w sądownictwie, szacuje ryzyka w matrycy 3x3, prowadzi analizę 5 Why i konstruuje tabelę Planu CAP. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zidentyfikowanych Luk IAM):

  Oceńcie ryzyka w matrycy 3x3:

  • Ryzyko 1: Ujawnienie danych świadka koronnego i dekonspiracja skutkująca zamachem na życie (P=2, S=3 -> R=6).
  • Ryzyko 2: Wyciek projektu wyroku gospodarczego przed publikacją (insider trading, korupcja) (P=3, S=3 -> R=9).
  • Ryzyko 3: Nieuprawniony wgląd w akta spraw rozwodowych/rodzinnych przez pracowników sądu (P=3, S=2 -> R=6).
  • Ryzyko 4: Masowe nocne pobieranie akt przez skompromitowane poświadczenia zdalne (P=3, S=3 -> R=9).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):

  Sformułujcie karty niezgodności z powołaniem na punkty norm i przepisów:

  • NC1 (Niezgodność Duża): Płaski model uprawnień RBAC w systemie biurowości sądowej umożliwiający nieograniczony dostęp asystentów i sekretarzy do akt spraw z innych wydziałów i spraw niejawnych (naruszenie par. 20 ust. 2 pkt 7 KRI, art. 32 RODO, kontroli A.5.15 i A.5.18 ISO 27001:2022).
  • NC1 (Niezgodność Duża): Brak technicznej ochrony tajemnicy narady sędziowskiej i projektów orzeczeń przed personelem pomocniczym (naruszenie art. 108 KPK, art. 325 KPC oraz kontroli A.8.2 ISO 27001).
  • NC2 (Niezgodność Mała): Brak reguł geofencingu i ograniczeń czasowych dla sesji zdalnych oraz brak analizy anomalii w logach dostępowych (kontrola A.8.16 ISO 27001).
  • OFI (Szansa na doskonalenie): Brak wdrożenia znakowania wodnego (watermarking) z numerem PESEL użytkownika pobierającego akta sądowe do przeglądania.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (dostęp asystentów do wszystkich spraw w sądzie i wycieki projektów wyroków) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego asystenci sędziów mieli dostęp do akt spraw ze wszystkich wydziałów? Bo przypisano im jedną uniwersalną rolę "Asystent" w systemie biurowości sądowej.

  2. Dlaczego rola nie ograniczała dostępu wyłącznie do spraw przypisanych danemu sędziemu? Bo system biurowości został wdrożony w architekturze RBAC opartej na funkcjach ogólnych, a nie na przypisaniu referatowym.

  3. Dlaczego Sądowe Centrum Informatyki nie wdrożyło granulacji uprawnień powiązanej ze składem orzekającym? Bo obawiano się, że przy częstych zastępstwach sędziów i zmianach składów orzekających sekretariaty będą sparaliżowane oczekiwaniem na nadanie uprawnień.

  4. Dlaczego nie zaimplementowano dynamicznej kontroli dostępu opartej na atrybutach sprawy i zarządzeniach Prezesa Sądu? Bo dostawca oprogramowania nie oferował w standardzie silnika ABAC, a Ministerstwo Sprawiedliwości nie wpisało takiego wymogu do specyfikacji zamówienia.

  5. Dlaczego dopuszczono do odbioru systemu bez zaawansowanej kontroli dostępu do akt prawnie chronionych? (PRZYCZYNA ŹRÓDŁOWA): Brak w sądownictwie powszechnym ujednoliconych Standardów Architektury Cyberbezpieczeństwa Wymiaru Sprawiedliwości wymuszających zasadę Need-to-Know i Security by Design w przetargach na systemy teleinformatyczne.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.

• Krok 6 (Projekt Zaawansowanego Modelu ABAC i Procedury Tajemnicy Narady):

  Zaprojektujcie:

  • Macierz polityki ABAC: reguła zezwalająca na dostęp do akt wyłącznie wtedy, gdy: `User.Department == Case.Department` ORAZ (`User.ID IN Case.AssignedJudges` LUB `User.ID IN Case.AssignedAssistants` LUB `User.Role == HeadOfClerks`).
  • Dedykowany "Skarbiec Orzeczeń" (Judicial Vault): izolowana strefa kryptograficzna dla projektów orzeczeń i protokołów narad sędziowskich, szyfrowana kluczem prywatnym członków składu orzekającego, z automatycznym odblokowaniem dla sekretariatu dopiero w chwili ogłoszenia wyroku na sali rozpraw.
  • Wdrożenie reguł UEBA: alert w czasie rzeczywistym i natychmiastowe zablokowanie konta przy pobraniu więcej niż 5 akt spraw poza godzinami 07:00-19:00.

Struktura zaawansowanego referatu seminaryjnego (15 minut):

• Wprowadzenie i powaga informacji w wymiarze sprawiedliwości (3 min): Rola Sądu Apelacyjnego, tajemnice procesowe i rygory ochrony świadków koronnych (Student 1).
• Wyniki audytu IAM i matryca ryzyka 3x3 (4 min): Zestawienie dowodów płaskiego RBAC, nocnego pobierania akt (R=9) i luk w ochronie projektów wyroków (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie ścieżki dochodzenia do pierwotnej przyczyny (brak ABAC w zamówieniach publicznych) i kwalifikacja prawna (Student 3).
• Plan CAP i architektura ABAC ze Skarbcem Orzeczeń (4 min): Prezentacja reguł atrybutowych, kryptograficznej ochrony narady sędziowskiej, modułu UEBA oraz bilansu korzyści (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Wyczerpujące odpowiedzi na pytania problemowe i diagnozę systemową:

• Czym różni się model kontroli dostępu opartej na atrybutach (Attribute-Based Access Control - ABAC) od tradycyjnego modelu RBAC i dlaczego w wymiarze sprawiedliwości model RBAC jest niewystarczający do zagwarantowania zasady Need-to-Know?
• W jaki sposób przepisy prawa procesowego (art. 108 KPK, art. 325 KPC) definiujące bezwzględną tajemnicę narady sędziowskiej wpływają na architekturę systemów IT w sądach i jakie środki kryptograficzne muszą chronić projekty orzeczeń?
• W jaki sposób systemy klasy User and Entity Behavior Analytics (UEBA) mogą wykrywać nadużycia uprawnień przez pracowników instytucji publicznych posiadających formalne uprawnienia do przeglądania danych (detekcja anomalii wolumetrycznych i czasowych)?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Wyciek projektu wyroku przed ogłoszeniem -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Kryptograficzny Skarbiec Orzeczeń dostępny tylko dla składu -> P_rez=1, S_rez=3, R_rez=3 (Pod kontrolą).
  • Ryzyko 2: Nieuprawniony dostęp asystenta do akt spraw z innego wydziału -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Wdrożenie reguł ABAC powiązanych z referatem -> P_rez=1, S_rez=2, R_rez=2.
  • Ryzyko 3: Nocne masowe pobieranie akt sądowych przez VPN -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Blokada transferów nocnych + reguły UEBA z odcięciem sesji -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 4: Ujawnienie danych świadków koronnych i spraw niejawnych -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Dedykowana strefa z klauzulami bezpieczeństwa niejawnego -> P_rez=1, S_rez=3, R_rez=3.
• Zestawienie Kart Niezgodności: Pełne karty dla 2 Niezgodności Dużych (NC1), 1 Niezgodności Małej (NC2) oraz 1 Szansy na doskonalenie (OFI).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla braku separacji referatowej w sądzie.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Wdrożenie modułu kontroli dostępu ABAC w oprogramowaniu biurowości sądowej ograniczającego dostęp do spraw do członków składu orzekającego i wyznaczonego asystenta (Właściciel: Kierownik Sądowego Centrum Informatyki, Termin: 45 dni, KPI: 100% spraw chronionych regułami ABAC).
  • Zadanie CAP-2: Wdrożenie modułu kryptograficznego "Skarbiec Orzeczeń" uniemożliwiającego wgląd do projektów wyroków osobom spoza składu przed datą publikacji (Właściciel: Główny Architekt Systemów Sądowych, Termin: 30 dni, KPI: eliminacja dostępu sekretariatu do projektów orzeczeń).
  • Zadanie CAP-3: Wdrożenie reguł behawioralnych UEBA oraz automatycznego blokowania sesji zdalnych przy próbie pobrania ponad 5 akt w nocy (Właściciel: Oficer Bezpieczeństwa IT Sądu, Termin: 14 dni, KPI: wdrożenie reguł alarmowania w SIEM).
  • Zadanie CAP-4: Nowelizacja Regulaminu Bezpieczeństwa Informacji Sądu Apelacyjnego i przeprowadzenie szkoleń dla kadry urzędniczej (Właściciel: Prezes Sądu i IOD, Termin: 30 dni, KPI: 100% pracowników przeszkolonych z odpowiedzialności karnej).
• Projekt Dokumentu: "Polityka Bezpieczeństwa Informacji i Dostępów do Zasobów Orzeczniczych w Sądzie Apelacyjnym w oparciu o Model ABAC".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Całkowite wyeliminowanie ryzyka przecieków projektów wyroków; zabezpieczenie najwrażliwszych spraw karnych i rodzinnych przed ciekawością osób postronnych; pełna zgodność z KRI i przepisami procedur sądowych; przywrócenie zaufania obywateli do bezstronności wymiaru sprawiedliwości.
• Wady i trudności: Zwiększony nakład pracy przy wyznaczaniu zastępstw sędziowskich (konieczność natychmiastowej aktualizacji atrybutów w systemie); koszty modyfikacji oprogramowania u zewnętrznego dostawcy; konieczność rekonfiguracji uprawnień dla setek użytkowników.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.5.15 (Zarządzanie tożsamością), A.5.18 (Prawa dostępu do informacji), A.8.2 (Uprzywilejowane prawa dostępu), A.8.16 (Monitorowanie aktywności).
• Ustawa z dnia 27 lipca 2001 r. - Prawo o ustroju sądów powszechnych (Dz.U. z 2024 r. poz. 334 z późn. zm.).
• Ustawa z dnia 6 czerwca 1997 r. - Kodeks postępowania karnego (Dz.U. z 2024 r. poz. 37 z późn. zm.) - art. 108 (tajemnica narady).
• Ustawa z dnia 17 listopada 1964 r. - Kodeks postępowania cywilnego (Dz.U. z 2023 r. poz. 1550 z późn. zm.) - art. 325.
• Rozporządzenie Ministra Sprawiedliwości z dnia 18 czerwca 2019 r. - Regulamin urzędowania sądów powszechnych (Dz.U. z 2024 r. poz. 867).
• Rozporządzenie Rady Ministrów w sprawie Krajowych Ram Interoperacyjności (KRI) - par. 20 (Dz.U. z 2024 r. poz. 773).
• NIST Special Publication 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations.

• U2 Student wykrywa i klasyfikuje uchybienia w architekturze kontroli dostępu do informacji procesowych.
• U1 Student projektuje zaawansowany model ABAC oraz architekturę kryptograficznej ochrony tajemnicy narady sędziowskiej.
• U3 Student wykonuje analizę ryzyka wycieku informacji procesowych w matrycy 3x3 w ujęciu inherentnym i rezydualnym.
• U4 Student realizuje procedurę 5 Why i konstruuje Plan Działań Korygujących (CAP) spełniający standardy sektora sprawiedliwości.
• W1W2W3 Student zna przepisy ustroju sądów, procedur cywilnych i karnych, KRI oraz standardy kontroli atrybutowej ABAC.
• K1K2K3 Student cechuje się wysoką kulturą prawną, etyką i zrozumieniem fundamentów niezawisłości sędziowskiej i ochrony praw obywatelskich.

Głównym celem zadania na ocenę 4.0 jest wykształcenie u studentów umiejętności zaawansowanego audytu zarządzania tożsamością, kontroli dostępu zdalnego oraz uwierzytelniania w infrastrukturze krytycznej państwa i automatyce przemysłowej (strefa SCADA/OT w przedsiębiorstwie przesyłu gazu ziemnego). Zadanie wymaga zbadania zgodności architektury sieciowej z modelem Purdue (poziomy 3 i 2), oceny wdrożenia mechanizmów uwierzytelniania wieloskładnikowego (MFA) dla zewnętrznych integratorów automatyki oraz własnych inżynierów dyspozycji mocy, wykrycia podatności na ataki socjotechniczne (phishing poświadczeń i zmęczenie MFA - MFA fatigue), wyliczenia ryzyka katastrofy przemysłowej w matrycy 3x3, sformułowania kart niezgodności (NC1/NC2/OFI), dochodzenia przyczyn źródłowych metodą 5 Why oraz opracowania Planu CAP wprowadzającego klucze sprzętowe FIDO2 (odporne na phishing), bramę bastionową PAM z separacją protokołową (protocol break) oraz nagrywanie i nadzór nad sesjami serwisowymi w czasie rzeczywistym.

Powiązanie z sylabusem i treściami programowymi na ocenę 4.0:

• U2 Profesjonalne wykrywanie i kwalifikacja krytycznych luk w zdalnym dostępie do sieci sterowania przemysłowego SCADA/OT z odniesieniem do ustawy o KSC i normy IEC 62443.
• U1 Opracowanie bezpiecznej architektury zdalnego dostępu serwisowego (Secure Remote Access) łączącej model Purdue, strefę demilitaryzowaną przemysłową (IDMZ), bramę PAM oraz MFA oparte na FIDO2/WebAuthn.
• U3 Przeprowadzenie analizy ryzyka sabotażu sieci przesyłowej gazu, rozszczelnienia rurociągów lub niekontrolowanego wzrostu ciśnienia w matrycy 3x3.
• U4 Opracowanie Planu Działań Korygujących (CAP) opartego na analizie 5 Why, z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.
• W1W2W3 Biegła znajomość Ustawy o krajowym systemie cyberbezpieczeństwa (art. 8-10), dyrektywy NIS2 (sektor energetyczny), normy IEC 62443-3-3 (Bezpieczeństwo systemów sterowania), normy ISO/IEC 27001:2022 (A.5.15, A.8.5, A.8.20) oraz wytycznych NIST SP 800-82.
• K1K2K3 Świadomość krytycznej odpowiedzialności inżynierskiej za bezpieczeństwo publiczne państwa, odporność na argumenty wygody serwisowej dostawców zewnętrznych i rzetelność audytorska.
• Powiązanie z wykładem: Wyk1 (Audyt w infrastrukturze krytycznej), Wyk3 (Kontrole A.8.5 i A.8.20 ISO 27001), Wyk4 (KSC i NIS2 w energetyce), Wyk5 (Risk-based audit wg ISO 27005 i matryca 3x3), Wyk6 (Analiza logów VPN, firewalli i połączeń RDP do strefy SCADA), Wyk7 (Metodyka CAP i raportowanie do Rządowego Zespołu CSIRT).

Przedsiębiorstwo "PolGaz Przesył S.A." jest operatorem krajowej sieci gazociągów przesyłowych wysokiego ciśnienia o łącznej długości 11 000 km, zarządzającym 14 tłoczniami gazu, 60 węzłami rozdzielczymi oraz podziemnymi magazynami gazu. Spółka posiada status Operatora Infrastruktury Krytycznej oraz Podmiotu Kluczowego w myśl dyrektywy NIS2 i ustawy o KSC. Sterowanie przepływem gazu odbywa się z Krajowej Dyspozycji Gazu za pośrednictwem rozproszonego systemu SCADA (Schneider Electric / Telvent OASyS) współpracującego ze sterownikami PLC (Siemens S7-1500) i systemami zabezpieczeń ESD (Emergency Shutdown).

Stan zastały w obszarze kontroli zdalnego dostępu i uwierzytelniania w sieci SCADA:

• Do celów diagnostyki i usuwania awarii automatyki przemysłowej w tłoczniach gazu przedsiębiorstwo korzysta z usług 8 zewnętrznych dostawców aparatury i integratorskich firm automatyki.
• Dostęp zdalny serwisantów zewnętrznych został zrealizowany poprzez zestawienie stałych tuneli VPN typu Site-to-Site lub indywidualnych kont VPN (OpenVPN) logujących się bezpośrednio do sieci zakładowej.
• Uwierzytelnianie serwisantów opiera się na tradycyjnej parze: login i hasło statyczne, bez wymuszenia uwierzytelniania wieloskładnikowego (MFA). W trakcie wywiadów audytowych serwisanci przyznali, że hasła do kont VPN są zapisane w plikach tekstowych na komputerach serwisowych firm zewnętrznych i współdzielone przez wielu inżynierów.
• Po zestawieniu tunelu VPN komputer zewnętrznego serwisanta ma bezpośredni, nieograniczony dostęp sieciowy (brak przemysłowej strefy demilitaryzowanej - IDMZ na poziomie 3.5 modelu Purdue) do stacji operatorskich HMI (Poziom 3) oraz bezpośrednio do portów komunikacyjnych sterowników PLC (Poziom 2 - porty 102/TCP ISO-TSAP i 502/TCP Modbus), bez skakania protokołowego (protocol break) i bez pośrednictwa serwera bastionowego.
• W trakcie analizy zdarzeń zapory sieciowej i logów serwera VPN z ostatnich 6 miesięcy wykryto:
  • 14 sesji połączeniowych zrealizowanych z nietypowych geolokalizacji (adresy IP z Azji i Ameryki Południowej), z których wysyłano zapytania diagnostyczne do sterowników PLC tłoczni gazu w godzinach nocnych.
  • Próbę ataku typu Password Spraying na konta serwisowe VPN, która nie wywołała żadnego alertu w wewnętrznym zespole SOC ze względu na brak korelacji logów VPN z systemem SIEM.
• W organizacji nie wdrożono rejestracji wideo ani logowania komend przesyłanych w trakcie sesji zdalnego pulpitu (RDP) do stacji dyspozytorskich SCADA, co uniemożliwia ustalenie, jakie zmiany parametrów ciśnienia i nastaw zaworów były wprowadzane przez zewnętrznych wykonawców.

Pełnomocnik Rządu ds. Strategicznej Infrastruktury Energetycznej oraz CSIRT GOV, w związku z podwyższonym stopniem alarmowym CHARLIE-CRP, nakazują pilny audyt kontroli dostępu do strefy OT, wyliczenie ryzyk w matrycy 3x3 oraz wdrożenie Planu CAP.

Praca w zespole 2-3 osobowym polega na wszechstronnym zbadaniu procesów uwierzytelniania i autoryzacji w szpitalu oraz zaproponowaniu rozwiązań eliminujących anonimowość pracy personelu:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Ekspert Infrastruktury Krytycznej i KSC): Bada zgodność z ustawą o KSC, wymogami Rządowego Centrum Bezpieczeństwa (RCB), procedury współpracy z CSIRT GOV i koordynuje wystąpienie referatowe.

  Student 2 (Audytor Techniczny Cyberbezpieczeństwa OT / SCADA): Bada architekturę sieci wg modelu Purdue, konfigurację bram VPN, zapór IDMZ, analizuje logi połączeń do sterowników PLC oraz techniczne możliwości wdrożenia kluczy FIDO2 i bram bastionowych PAM.

  Student 3 (Audytor Ryzyka Przemysłowego, Normy IEC 62443 i Jakości CAP): Przeprowadza szacowanie ryzyka katastrofy przemysłowej w matrycy 3x3, klasyfikuje niezgodności wg IEC 62443 i ISO 27001, prowadzi analizę 5 Why i konstruuje tabelę Planu CAP. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zidentyfikowanych Luk SCADA/OT):

  Oceńcie ryzyka w matrycy 3x3 w skali prawdopodobieństwa (1-Niskie, 2-Średnie, 3-Wysokie) i skutku (1-Niski, 2-Poważny, 3-Katastrofalny - wybuch gazu, ofiary śmiertelne, paraliż energetyczny państwa):

  • Ryzyko 1: Przejęcie kontroli nad sterownikami tłoczni gazu przez wrogie służby w wyniku kradzieży hasła VPN i sabotaż ciśnienia (P=3, S=3 -> R=9).
  • Ryzyko 2: Infekcja stacji dyspozytorskiej SCADA oprogramowaniem ransomware poprzez bezpośredni tunel z zainfekowanego laptopa serwisanta (P=3, S=3 -> R=9).
  • Ryzyko 3: Niekontrolowane i nierozliczalne zmiany parametrów zaworów przez integratorów bez rejestracji sesji (P=3, S=2 -> R=6).
  • Ryzyko 4: Utrata zaufania CSIRT GOV i sankcje administracyjne za brak adekwatnych zabezpieczeń podmiotu kluczowego (P=3, S=2 -> R=6).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):

  Sformułujcie karty niezgodności z powołaniem na punkty norm i przepisów:

  • NC1 (Niezgodność Duża): Zdalny dostęp do sieci dyspozytorskiej SCADA za pomocą pojedynczego hasła statycznego bez wymuszenia uwierzytelniania wieloskładnikowego MFA odpornego na phishing (naruszenie art. 8 i 9 ustawy o KSC, dyrektywy NIS2, kontroli A.8.5 ISO 27001:2022 oraz wymagań normy PN-EN IEC 62443-3-3 poziom SL-3).
  • NC1 (Niezgodność Duża): Brak przemysłowej strefy demilitaryzowanej (IDMZ) i bezpośrednie łączenie stacji zewnętrznych z poziomem sterowników PLC bez separacji protokołowej i inspekcji PAM (naruszenie modelu Purdue, kontroli A.8.20 i A.8.2 ISO 27001).
  • NC2 (Niezgodność Mała): Brak rejestracji sesji wideo i logowania komend RDP/SSH wykonywanych przez wykonawców zewnętrznych w systemie SCADA (naruszenie kontroli A.8.15 ISO 27001).
  • OFI (Szansa na doskonalenie): Brak wdrożenia mechanizmu automatycznego odcinania zasilania zaworów gazowych w oparciu o fizyczną diodę danych (Data Diode) dla strumieni telemetrycznych.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (brak MFA i bezpośredni dostęp VPN do sterowników PLC tłoczni gazu) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego integratorzy łączyli się ze sterownikami PLC bezpośrednio przez zwykłe hasło VPN? Bo dział automatyki skonfigurował tunele VPN w trybie transparentnym, aby umożliwić działanie oprogramowania inżynierskiego producentów sterowników.

  2. Dlaczego nie wdrożono uwierzytelniania wieloskładnikowego (MFA)? Bo producenci oprogramowania SCADA twierdzili, że ich aplikacje diagnostyczne nie wspierają mechanizmów MFA i wymagają stałego dostępu warstwy 2/3.

  3. Dlaczego Dział IT/Cyberbezpieczeństwa zaakceptował te twierdzenia i nie wymusił bramy pośredniczącej (Jump Host)? Bo w strukturze organizacyjnej spółki pion automatyki przemysłowej (OT) funkcjonował w całkowitej izolacji od pionu bezpieczeństwa IT i nie podlegał procedurom audytowym ISMS.

  4. Dlaczego piony IT i OT nie współpracowały w zakresie standardów dostępu zdalnego? Bo Zarząd traktował cyberbezpieczeństwo wyłącznie jako domenę sieci biurowej, nie dostrzegając zagrożeń hybrydowych dla infrastruktury przemysłowej.

  5. Dlaczego dopuszczono do braku jednolitego ładu bezpieczeństwa IT/OT? (PRZYCZYNA ŹRÓDŁOWA): Brak w Spółce Zintegrowanego Systemu Zarządzania Bezpieczeństwem Informacji obejmującego środowisko OT (zgodnie z normą IEC 62443 i KSC) oraz brak formalnego wymogu odbioru bezpieczeństwa dostępu zdalnego przez CISO.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.

• Krok 6 (Projekt Rozwiązania Technicznego i Nowej Architektury Secure Remote Access):

  Zaprojektujcie:

  • Nową architekturę dostępu zdalnego zgodną z modelem Purdue: wdrożenie Przemysłowej DMZ (IDMZ Poziom 3.5); całkowity zakaz bezpośrednich tuneli VPN do sterowników PLC; ruch serwisowy zatrzymywany na serwerze bastionowym PAM w IDMZ (skakanie protokołowe).
  • Uwierzytelnianie wieloskładnikowe odporne na phishing: wymuszenie logowania z użyciem sprzętowych kluczy kryptograficznych FIDO2 (YubiKey) przypisanych imiennie do każdego inżyniera serwisu zewnętrznego; sesje RDP/SSH rejestrowane w postaci wideo i logów tekstowych z zatwierdzaniem każdego połączenia przez Dyspozytora Mocy (zasada czterech oczu w dostępie zdalnym).

Struktura zaawansowanego referatu seminaryjnego (15 minut):

• Wprowadzenie i powaga infrastruktury krytycznej (3 min): Rola PolGaz Przesył S.A., zagrożenia sabotażem hybrydowym i wymogi KSC/NIS2 (Student 1).
• Wyniki audytu IAM i matryca ryzyka 3x3 (4 min): Przedstawienie podatności bezpośrednich tuneli VPN, brak MFA, obce adresy IP w logach i wyliczenie ryzyka katastrofy (R=9) (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie ścieżki dochodzenia do pierwotnej przyczyny (silosy IT/OT) i kwalifikacja prawna IEC 62443 (Student 3).
• Plan CAP i architektura Secure Remote Access w modelu Purdue (4 min): Prezentacja kluczy FIDO2, bramy bastionowej PAM w IDMZ, nadzoru dyspozytorskiego oraz bilansu korzyści operacyjnych (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Wyczerpujące odpowiedzi na pytania problemowe i diagnozę systemową:

• W jaki sposób norma PN-EN IEC 62443 definiuje strefy (Zones), kanały komunikacyjne (Conduits) oraz poziomy bezpieczeństwa (Security Levels - SL) w odniesieniu do zdalnego dostępu do sieci sterowania przemysłowego?
• Dlaczego tradycyjne metody MFA oparte na kodach SMS lub powiadomieniach mobilnych Push są podatne na przełamanie (ataki SIM-swapping, phishing w czasie rzeczywistym z użyciem narzędzi typu Evilginx, zmęczenie powiadomieniami MFA fatigue) i dlaczego w infrastrukturze krytycznej dopuszcza się wyłącznie standard FIDO2/WebAuthn?
• W jaki sposób zaprojektować Przemysłową Strefę Demilitaryzowaną (IDMZ Poziom 3.5) oraz mechanizm skakania protokołowego (protocol break) w systemie PAM, aby całkowicie wykluczyć bezpośrednią łączność pakietową IP między siecią zewnętrzną a sterownikami PLC?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Przejęcie sterowników PLC tłoczni gazu przez wrogie służby przez skradzione hasło VPN -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Sprzętowe klucze FIDO2 + brama PAM w IDMZ + autoryzacja dyspozytora -> P_rez=1, S_rez=3, R_rez=3 (Pod kontrolą).
  • Ryzyko 2: Atak ransomware z laptopa serwisanta na stację HMI -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Skakanie protokołowe na serwerze bastionowym bez współdzielenia dysków -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Nierozliczalne błędy konfiguracyjne parametrów ciśnienia gazu przez integratorów -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Pełne nagrywanie sesji RDP i komend z audytem video -> P_rez=1, S_rez=2, R_rez=2.
  • Ryzyko 4: Kary CSIRT GOV i sankcje administracyjne z ustawy o KSC -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Wdrożenie zintegrowanego Planu CAP i zgłoszenie do organu właściwego -> P_rez=1, S_rez=2, R_rez=2.
• Zestawienie Kart Niezgodności: Pełne karty dla 2 Niezgodności Dużych (NC1), 1 Niezgodności Małej (NC2) oraz 1 Szansy na doskonalenie (OFI).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla braku zabezpieczeń zdalnego dostępu do OT.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Natychmiastowe zablokowanie bezpośrednich tuneli VPN do sieci SCADA i uruchomienie tymczasowej procedury dostępu pod stałym nadzorem dyspozytora (Właściciel: Kierownik Działu Teleinformatyki OT, Termin: 48 godzin, KPI: odcięcie bezpośredniego dostępu do portów 102/502).
  • Zadanie CAP-2: Wdrożenie bramy bastionowej PAM w wydzielonej Przemysłowej DMZ (IDMZ Poziom 3.5) z nagrywaniem sesji wideo (Właściciel: CISO i Architekt Bezpieczeństwa OT, Termin: 30 dni, KPI: 100% sesji serwisowych przechodzących przez barierę PAM).
  • Zadanie CAP-3: Zakup i wdrożenie sprzętowych kluczy FIDO2 YubiKey dla wszystkich inżynierów i integratorów zewnętrznych z wymuszeniem autoryzacji sprzętowej (Właściciel: Kierownik Sekcji IAM, Termin: 21 dni, KPI: zero dostępów zdalnych bez klucza FIDO2).
  • Zadanie CAP-4: Zintegrowanie logów zdarzeń PAM, firewalli i połączeń SCADA z centralnym systemem SIEM w SOC z regułami korelacji w czasie rzeczywistym (Właściciel: Kierownik SOC, Termin: 14 dni, KPI: automatyczny alert o każdej nieautoryzowanej próbie połączenia).
• Projekt Procedury: "Standard Bezpiecznego Zdalnego Dostępu Serwisowego (Secure Remote Access) do Systemów Automatyki Przemysłowej SCADA w PolGaz Przesył S.A.".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Wyeliminowanie najgroźniejszego wektora ataków na infrastrukturę krytyczną państwa; odporność uwierzytelniania na zaawansowany phishing i socjotechnikę; pełna rozliczalność i możliwość natychmiastowego przerwania sesji serwisanta przez dyspozytora gazu; 100% zgodność z ustawą o KSC, dyrektywą NIS2 i normą IEC 62443.
• Wady i trudności: Wysoki koszt zakupu i wdrożenia wyspecjalizowanych licencji PAM dla środowisk OT; narzut organizacyjny związany z dystrybucją i zarządzaniem kluczami kryptograficznymi dla dziesiątek podwykonawców; konieczność asysty dyspozytorskiej przy każdej sesji serwisowej.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.5.15 (Zarządzanie tożsamością), A.8.5 (Bezpieczne uwierzytelnianie), A.8.20 (Bezpieczeństwo sieci), A.8.2 (Uprzywilejowane prawa dostępu).
• Norma PN-EN IEC 62443-3-3: Sieci komunikacji przemysłowej - Bezpieczeństwo systemów i sieci - Wymagania dotyczące bezpieczeństwa systemu i poziomy bezpieczeństwa (SL).
• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. z 2024 r. poz. 1077) - obowiązki operatorów usług kluczowych (art. 8-16).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - sektor energetyczny.
• NIST Special Publication 800-82 Rev. 3: Guide to Operational Technology (OT) Security, National Institute of Standards and Technology, 2023.
• FIDO Alliance: "FIDO2: Moving Beyond Passwords in Critical Infrastructure", Biała Księga, 2023.
• Agencja Bezpieczeństwa Wewnętrznego (ABW / CSIRT GOV): "Zalecenia dotyczące zabezpieczenia systemów automatyki przemysłowej (SCADA/ICS)", Warszawa.

• U2 Student wykrywa i klasyfikuje uchybienia w architekturze dostępu zdalnego do sieci automatyki SCADA/OT.
• U1 Student projektuje bezpieczną architekturę Secure Remote Access w oparciu o model Purdue, IDMZ, PAM i FIDO2.
• U3 Student przeprowadza analizę ryzyka sabotażu przemysłowego w matrycy 3x3 w ujęciu inherentnym i rezydualnym.
• U4 Student realizuje dochodzenie przyczyn źródłowych 5 Why i sporządza Plan Działań Korygujących (CAP) dla infrastruktury krytycznej.
• W1W2W3 Student zna regulacje KSC, NIS2, normę IEC 62443, wytyczne NIST SP 800-82 oraz standardy FIDO2.
• K1K2K3 Student cechuje się bezkompromisowością w ochronie bezpieczeństwa państwa, etyką inżynierską i odpornością na presję dostawców automatyki.

Głównym celem zadania na ocenę 4.0 jest wykształcenie zaawansowanych umiejętności audytu procesów certyfikacji uprawnień i okresowych przeglądów dostępu użytkowników (ang. User Access Review - UAR / Access Certification) w międzynarodowym Centrum Usług Wspólnych (BPO/SSC). Podmiot ten przetwarza księgi rachunkowe, sprawozdania finansowe i płatności dla globalnych spółek giełdowych notowanych na New York Stock Exchange (NYSE), podlegając rygorom amerykańskiej ustawy Sarbanes-Oxley (SOX sekcja 404) oraz standardowi atestacyjnemu ISAE 3402 / SOC 1 Type II. Zadanie wymaga przeanalizowania mechanizmów przeglądów ról w systemie ERP (SAP S/4HANA Finance), zidentyfikowania patologii "zatwierdzania bez weryfikacji" (ang. rubber-stamping), zbadania zjawiska powolnej akumulacji uprawnień (privilege creep) w wyniku awansów i rotacji projektowej, wyliczenia ryzyka zniekształcenia sprawozdań finansowych w matrycy 3x3, zakwalifikowania niezgodności (NC1/NC2/OFI), przeprowadzenia analizy 5 Why oraz opracowania Planu CAP wprowadzającego platformę Identity Governance and Administration (IGA) z atestacją opartą na kontekście biznesowym i analizą odstępstw (Outlier Analysis).

Powiązanie z sylabusem i treściami programowymi na ocenę 4.0:

• U2 Profesjonalna identyfikacja i formalna gradacja uchybień w procesach okresowej recertyfikacji dostępu użytkowników, zjawiska rubber-stampingu i kumulacji uprawnień transakcyjnych.
• U1 Opracowanie zintegrowanego modelu procesu User Access Review (UAR) opartego na narzędziach klasy IGA (np. SailPoint / SAP GRC) z mierzalnymi punktami kontrolnymi dla właścicieli biznesowych.
• U3 Przeprowadzenie analizy ryzyka oszustw bilansowych, kar finansowych komisji nadzoru (SEC / KNF) oraz utraty atestu ISAE 3402 w matrycy 3x3.
• U4 Opracowanie Planu Działań Korygujących (CAP) opartego na analizie 5 Why, z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.
• W1W2W3 Dogłębna znajomość normy ISO/IEC 27001:2022 (A.5.18 - Przegląd praw dostępu), ustawy Sarbanes-Oxley Act (SOX Section 404 - Internal Controls over Financial Reporting), standardu ISAE 3402 / SSAE 18 oraz Rekomendacji D KNF.
• K1K2K3 Obiektywizm, wysoka kultura audytu finansowo-technologicznego, zdolność do demaskowania pozornych procedur kontrolnych oraz promowanie rzeczywistej odpowiedzialności menedżerskiej.
• Powiązanie z wykładem: Wyk1 (Audyt w korporacjach międzynarodowych), Wyk3 (Kontrola A.5.18 ISO 27001), Wyk4 (SOX i ISAE 3402 w audycie zgodności), Wyk5 (Risk-based audit i matryca 3x3), Wyk6 (Analiza logów kampanii UAR i atrybutów ról SAP PFCG), Wyk7 (Metodyka CAP i raportowanie do Komitetu Audytu).

Globalne Centrum Usług Finansowo-Księgowych "Apex Financial Services SSC" w Krakowie zatrudnia 850 księgowych, analityków finansowych i specjalistów ds. płac, świadcząc usługi prowadzenia ksiąg głównych (General Ledger), rozliczeń zobowiązań (Accounts Payable), należności (Accounts Receivable) oraz raportowania podatkowego dla 16 spółek z sektora farmaceutycznego i technologicznego z USA i Europy Zachodniej. Prace realizowane są na dedykowanej instancji systemu ERP SAP S/4HANA Cloud.

Stan zastały w obszarze okresowych przeglądów dostępu (User Access Review):

• Zgodnie z nadrzędną procedurą bezpieczeństwa Apex SSC przeglądy uprawnień użytkowników mają odbywać się raz w roku. Proces jest realizowany manualnie za pomocą arkuszy kalkulacyjnych Excel generowanych z modułu SAP Basis przez administratorów IT i rozsyłanych pocztą elektroniczną do 45 menedżerów zespołów operacyjnych.
• W trakcie ostatniej kampanii rocznej menedżer zespołu ds. rozliczeń należności (AP) otrzymał arkusz zawierający 280 wierszy z nazwami technicznymi ról SAP (np. role typu `Z_FI_AP_INVOICE_POST_02`, `Z_BC_USER_CHANGE_ALL`, `Z_SD_ORDER_CREATE`). Menedżer, nie posiadając wiedzy technicznej na temat zawartości poszczególnych ról i działając pod presją zbliżającego się terminu zamknięcia miesiąca, zaznaczył opcję "Zatwierdź wszystkie" dla wszystkich 280 pozycji po zaledwie 3 minutach od otwarcia pliku (podręcznikowy przypadek rubber-stampingu).
• Zespół audytorów dokonał szczegółowej analizy profili uprawnień losowej próby 40 pracowników o stażu pracy powyżej 3 lat. Wyniki badania:
  • U 32 z 40 badanych pracowników (80% próby) zidentyfikowano zjawisko drastycznej akumulacji uprawnień (privilege creep): pracownicy, którzy awansowali ze stanowisk młodszych księgowych na stanowiska analityków lub liderów projektów, zachowali wszystkie role transakcyjne ze swoich poprzednich ról operacyjnych.
  • 14 pracowników posiadało jednocześnie uprawnienia do: wprowadzania nowego dostawcy do bazy (transakcja `FK01`), rejestracji faktury zakupowej (transakcja `FB60`) oraz generowania propozycji płatności i zatwierdzania przelewu bankowego (transakcja `F110`).
  • Wykryto 9 aktywnych kont pracowników, którzy przebywali na długotrwałych urlopach macierzyńskich lub bezpłatnych (powyżej 180 dni), dla których menedżerowie w arkuszu UAR bezrefleksyjnie potwierdzili "pełną zasadność posiadania uprawnień".
• Niezależny audytor finansowy badający zgodność procedur kontroli wewnętrznej ze standardem SOX 404 zgłosił "Istotną Słabość Kontroli Wewnętrznej" (Material Weakness in Internal Control over Financial Reporting), co stawia pod znakiem zapytania możliwość wydania pozytywnego raportu ISAE 3402 Typ II i grozi zerwaniem kontraktów z klientami z USA.

Zarząd Apex Financial Services SSC powołuje zespół audytorów w celu przeprowadzenia audytu jakości kampanii UAR, wyliczenia ryzyka w matrycy 3x3 oraz wdrożenia Planu CAP.

Praca w zespole 2-3 osobowym polega na wszechstronnym zbadaniu procesów uwierzytelniania i autoryzacji w szpitalu oraz zaproponowaniu rozwiązań eliminujących anonimowość pracy personelu:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Ekspert Audytu Finansowego SOX): Analizuje wymogi SOX 404, standardu ISAE 3402, umowy SLA z klientami giełdowymi, relacje z Komitetem Audytu i koordynuje referat.

  Student 2 (Audytor Techniczny IAM / Specjalista SAP Security): Bada strukturę ról w SAP PFCG, transakcje SU01/SUIM, analizuje logi kampanii UAR, bada możliwości integracji narzędzi IGA/GRC oraz automatyczną detekcję anomalii uprawnień (Outlier Analysis).

  Student 3 (Audytor Ryzyka Biznesowego, Zgodności i Jakości CAP): Przeprowadza szacowanie ryzyka w matrycy 3x3 dla fałszerstwa sprawozdań i utraty klientów, klasyfikuje niezgodności, prowadzi analizę 5 Why i konstruuje tabelę Planu CAP. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zidentyfikowanych Luk UAR):

  Oceńcie ryzyka w matrycy 3x3 w skali prawdopodobieństwa (1-Niskie, 2-Średnie, 3-Wysokie) i skutku finansowo-reputacyjnego (1-Niski, 2-Średni, 3-Krytyczny - odmowa wydania opinii SOX 404, utrata kluczowych kontraktów, sankcje SEC):

  • Ryzyko 1: Wyprowadzenie środków finansowych przez fikcyjnego dostawcę na skutek kumulacji ról FK01/FB60/F110 (P=3, S=3 -> R=9).
  • Ryzyko 2: Wydanie negatywnej opinii audytora SOX 404 (Material Weakness) i zerwanie umów przez klientów giełdowych z USA (P=3, S=3 -> R=9).
  • Ryzyko 3: Błędy księgowe i zniekształcenie bilansu kwartalnego z powodu nieuprawnionych księgowań (P=3, S=2 -> R=6).
  • Ryzyko 4: Utrata atestacji ISAE 3402 Typ II i kary umowne SLA (P=3, S=2 -> R=6).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):

  Sformułujcie karty niezgodności z powołaniem na punkty norm i standardów:

  • NC1 (Niezgodność Duża): Fikcyjny i nieskuteczny proces okresowego przeglądu uprawnień (UAR) oparty na zjawisku rubber-stampingu w arkuszach Excel, skutkujący powszechną kumulacją uprawnień transakcyjnych (naruszenie kontroli A.5.18 ISO 27001:2022, sekcji 404 ustawy Sarbanes-Oxley oraz zasad kontroli wewnętrznej COSO).
  • NC1 (Niezgodność Duża): Pozostawienie aktywnych profili uprawnień transakcyjnych pracownikom na długotrwałych urlopach oraz po transferach między działami (naruszenie kontroli A.5.18 i A.5.3 ISO 27001).
  • NC2 (Niezgodność Mała): Prezentowanie menedżerom biznesowym czysto technicznych nazw ról SAP bez opisu ich funkcji biznesowej i powiązanego ryzyka (naruszenie wytycznych ISACA w zakresie recertyfikacji dostępu).
  • OFI (Szansa na doskonalenie): Brak wdrożenia uczenia maszynowego (ML) do automatycznego rekomendowania odebrania ról nieużywanych przez użytkownika przez ponad 90 dni.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (powszechne zjawisko rubber-stampingu i akumulacji ról toksycznych w SAP) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego menedżerowie operacyjni zatwierdzali wszystkie uprawnienia w arkuszach Excel bez ich weryfikacji? Bo arkusze zawierały setki wierszy z niezrozumiałymi nazwami technicznymi ról SAP i menedżerowie nie wiedzieli, co faktycznie zatwierdzają.

  2. Dlaczego menedżerowie otrzymywali nazwy techniczne zamiast opisów ról biznesowych? Bo Dział IT pobierał surowe tabele z SAP (`AGR_USERS`) bez zmapowania ich na role biznesowe i procesy księgowe.

  3. Dlaczego nie wdrożono zautomatyzowanego narzędzia IGA (np. SailPoint IdentityIQ, SAP GRC Access Control) prezentującego uprawnienia w języku biznesowym? Bo Zarząd SSC uznał zakup licencji za zbędny koszt, twierdząc, że "Excel wystarczy do spełnienia wymogów formalnych".

  4. Dlaczego Dział Kontroli Wewnętrznej i Compliance nie zakwestionował manualnego procesu w Excelu? Bo kampanie UAR były traktowane przez kierownictwo jako czysta formalność pod audyt, a nie jako realny mechanizm redukcji ryzyka nadużyć finansowych.

  5. Dlaczego w korporacji wykształciła się kultura pozornej zgodności (Check-the-box Compliance)? (PRZYCZYNA ŹRÓDŁOWA): Brak powiązania wskaźników jakości zarządzania dostępem i bezpieczeństwa informacji z celami premiowymi (KPI) kadry zarządzającej wyższego i średniego szczebla, co skutkowało priorytetyzacją bieżącej produkcji księgowej nad kontrolą wewnętrzną.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.

• Krok 6 (Projekt Nowego Procesu UAR i Architektury IGA):

  Zaprojektujcie:

  • Przejście z corocznej weryfikacji manualnej na kwartalną, zautomatyzowaną recertyfikację w portalu IGA: tłumaczenie technicznych ról SAP na zrozumiałe role biznesowe; automatyczne oznaczanie ról nieużywanych przez 60 dni z sugerowaną decyzją "Odbierz dostęp".
  • Wdrożenie reguły "Zero Rubber-Stamping": wprowadzenie minimalnego czasu przeglądu (blokada przycisku "Zatwierdź" proporcjonalna do liczby pozycji), wymóg indywidualnego zatwierdzenia każdej roli zidentyfikowanej jako potencjalny konflikt SoD; natychmiastowe zawieszanie kont pracowników przebywających na urlopach powyżej 30 dni.

Struktura zaawansowanego referatu seminaryjnego (15 minut):

• Wprowadzenie i rygory audytu SOX 404 w centrach SSC (3 min): Rola Apex Financial Services, waga raportu ISAE 3402 i konsekwencje statusu Material Weakness (Student 1).
• Wyniki audytu UAR i matryca ryzyka 3x3 (4 min): Przedstawienie dowodów rubber-stampingu w 3 minuty, wykrycie kumulacji ról u 80% pracowników (R=9) (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie ścieżki dochodzenia do pierwotnej przyczyny (kultura pozornej zgodności i brak IGA) i kwalifikacja prawna (Student 3).
• Plan CAP i nowoczesny proces Access Certification (4 min): Prezentacja kwartalnej atestacji IGA, blokad anty-rubber-stamping, ról biznesowych oraz bilansu korzyści zarządczych (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Wyczerpujące odpowiedzi na pytania problemowe i diagnozę systemową:

• W jaki sposób sekcja 404 amerykańskiej ustawy Sarbanes-Oxley (SOX) definiuje pojęcia "Znaczącego Niedostatku" (Significant Deficiency) oraz "Istotnej Słabości" (Material Weakness) kontroli wewnętrznej w odniesieniu do procesów zarządzania tożsamością i dostępem (IAM)?
• Czym charakteryzuje się patologiczne zjawisko "rubber-stampingu" w kampaniach User Access Review i jakie techniczne mechanizmy w systemach klasy IGA (Identity Governance and Administration) pozwalają mu skutecznie zapobiegać?
• W jaki sposób poprawnie zaprojektować proces atestacji uprawnień w systemie ERP SAP, aby menedżer biznesowy dokonywał oceny w oparciu o zrozumiałe procesy biznesowe, a nie hermetyczne nazwy techniczne obiektów autoryzacyjnych?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Nadużycie finansowe (fraud bilansowy) przez kumulację uprawnień w SAP -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Natychmiastowa rekultywacja ról + kwartalny UAR w IGA -> P_rez=1, S_rez=3, R_rez=3 (Pod kontrolą).
  • Ryzyko 2: Negatywna opinia SOX 404 (Material Weakness) i odpływ klientów korporacyjnych -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Wdrożenie Planu CAP i prezentacja postępów audytorom zewnętrznym -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Błędy operacyjne wynikające z privilege creep po awansach -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Automatyczne czyszczenie ról z poprzednich stanowisk przy awansie -> P_rez=1, S_rez=2, R_rez=2.
  • Ryzyko 4: Utrata atestu ISAE 3402 Typ II -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Udokumentowanie skuteczności kontroli kompensacyjnych -> P_rez=1, S_rez=2, R_rez=2.
• Zestawienie Kart Niezgodności: Pełne karty dla 2 Niezgodności Dużych (NC1), 1 Niezgodności Małej (NC2) oraz 1 Szansy na doskonalenie (OFI).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla pozornego procesu przeglądu uprawnień.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Natychmiastowe odebranie uprawnień toksycznych u 14 zidentyfikowanych księgowych (rozdzielenie ról tworzenia dostawcy i autoryzacji płatności) (Właściciel: Dyrektor Operacyjny Finansów, Termin: 48 godzin, KPI: 100% konfliktów krytycznych usuniętych).
  • Zadanie CAP-2: Wdrożenie dedykowanego modułu Access Certification w portalu IGA z mapowaniem ról technicznych SAP na role biznesowe (Właściciel: Kierownik Zespołu IAM, Termin: 45 dni, KPI: przejście 100% menedżerów na platformę IGA).
  • Zadanie CAP-3: Wdrożenie reguł automatycznej blokady kont pracowników przebywających na urlopach dłuższych niż 30 dni (Właściciel: Kierownik Działu Kadr, Termin: 14 dni, KPI: zero aktywnych kont na długich urlopach).
  • Zadanie CAP-4: Wprowadzenie wskaźnika jakości recertyfikacji dostępu do karty celów rocznych i premiowych dla kadry menedżerskiej (Właściciel: Zarząd Spółki i Dyrektor HR, Termin: 30 dni, KPI: uzależnienie premii od terminowego i rzetelnego UAR).
• Projekt Procedury: "Standard Okresowego Przeglądu i Recertyfikacji Uprawnień Użytkowników (User Access Review Policy) w Apex Financial Services SSC".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Odzyskanie zaufania audytorów finansowych i usunięcie zarzutu Material Weakness w SOX 404; wyeliminowanie ryzyka defraudacji środków klientów; automatyzacja procesu przeglądów oszczędzająca setki godzin pracy menedżerów; pełna zgodność z ISO 27001 i ISAE 3402.
• Wady i trudności: Koszt zakupu licencji zaawansowanego oprogramowania IGA/GRC; nakład pracy analitycznej związany z opisaniem setek ról technicznych SAP na język procesów biznesowych; początkowy sprzeciw menedżerów wobec likwidacji prostego zatwierdzania jednym kliknięciem.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrola A.5.18 (Prawa dostępu do informacji i innych powiązanych aktywów - okresowy przegląd praw dostępu).
• Sarbanes-Oxley Act of 2002 (SOX): Section 404 - Management Assessment of Internal Controls over Financial Reporting.
• International Auditing and Assurance Standards Board (IAASB): ISAE 3402 - Assurance Reports on Controls at a Service Organization.
• Committee of Sponsoring Organizations of the Treadway Commission (COSO): "Internal Control - Integrated Framework", 2013.
• ISACA: "Auditing User Access Management and Access Certification Reviews", Information Systems Audit and Control Association, 2023.
• SAP SE: "Security and Authorizations in SAP S/4HANA Finance - Best Practices Guide", Walldorf 2023.

• U2 Student demaskuje pozorny proces kontrolny i klasyfikuje uchybienia UAR do kategorii NC1/NC2/OFI wg SOX i ISO 27001.
• U1 Student projektuje zaawansowany proces recertyfikacji dostępu IGA oparty na rolach biznesowych i zwalczaniu rubber-stampingu.
• U3 Student wykonuje analizę ryzyka defraudacji finansowych i utraty atestów w matrycy 3x3.
• U4 Student realizuje procedurę 5 Why i konstruuje Plan Działań Korygujących (CAP) spełniający standardy audytu międzynarodowego.
• W1W2W3 Student zna regulacje SOX 404, ISAE 3402, normę ISO 27001 oraz architekturę uprawnień SAP ERP.
• K1K2K3 Student cechuje się bezkompromisowością wobec fikcyjnych procedur korporacyjnych, dociekliwością i wysokimi standardami etyki zawodowej.

Głównym celem zadania na ocenę 4.0 jest wykształcenie zaawansowanych umiejętności audytu tożsamości nieludzkich (ang. Non-Human Identities - NHI), kont technicznych, serwisowych oraz botów zautomatyzowanej robotyzacji procesów (Robotic Process Automation - RPA) w dużej instytucji ubezpieczeniowo-finansowej podlegającej nadzorowi Komisji Nadzoru Finansowego (KNF) oraz rozporządzeniu DORA. Zadanie koncentruje się na zbadaniu hybrydowej infrastruktury domenowej Active Directory oraz Azure Entra ID, identyfikacji kont serwisowych z nadmiernymi uprawnieniami administracyjnymi (Domain Admins), audycie kont z zarejestrowaną główną nazwą usługi (Service Principal Name - SPN) podatnych na ataki typu Kerberoasting, wykryciu haseł zapisanych jawnym tekstem w konfiguracjach skryptów i botów RPA, wyliczeniu ryzyka całkowitej kompromitacji domeny w matrycy 3x3, zakwalifikowaniu niezgodności (NC1/NC2/OFI), przeprowadzeniu analizy 5 Why oraz opracowaniu Planu CAP wprowadzającego konta zarządzane grupowo (Group Managed Service Accounts - gMSA), tożsamości zarządzane w chmurze (Managed Identities) oraz bezpieczny sejf sekretów z dynamiczną rotacją poświadczeń.

Powiązanie z sylabusem i treściami programowymi na ocenę 4.0:

• U2 Profesjonalna identyfikacja i formalna gradacja krytycznych luk w zarządzaniu tożsamościami maszynowymi, kontami serwisowymi i podatnościami protokołu Kerberos.
• U1 Opracowanie kompleksowej strategii zarządzania tożsamościami nieludzkimi (NHI Governance) obejmującej migrację na konta gMSA, eliminację uprawnień Domain Admins dla usług oraz wdrożenie sejfu poświadczeń.
• U3 Przeprowadzenie analizy ryzyka przejęcia kontrolera domeny (Golden Ticket / Kerberoasting), wycieku bazy polis ubezpieczeniowych i paraliżu likwidacji szkód w matrycy 3x3.
• U4 Opracowanie Planu Działań Korygujących (CAP) opartego na analizie 5 Why, z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.
• W1W2W3 Dogłębna znajomość Rekomendacji D KNF (obszar zarządzania kontami uprzywilejowanymi i technicznymi), rozporządzenia DORA (art. 9, 10), Ustawy o działalności ubezpieczeniowej i reasekuracyjnej (tajemnica ubezpieczeniowa) oraz normy ISO/IEC 27001:2022 (A.5.15, A.8.2, A.8.5).
• K1K2K3 Wysokie kompetencje inżynierskie, dociekliwość techniczna w badaniu ukrytych wektorów ataku, bezkompromisowość wobec długu technologicznego i rzetelność audytorska.
• Powiązanie z wykładem: Wyk1 (Audyt w ubezpieczeniach), Wyk3 (Kontrole A.5.15 i A.8.2 ISO 27001), Wyk4 (DORA i Rekomendacja D KNF), Wyk5 (Matrycowa analiza ryzyka 3x3), Wyk6 (Ekstrakcja kont SPN przez PowerShell i analiza logów Kerberos Event 4769), Wyk7 (Metodyka CAP i raportowanie do Zarządu).

Grupa Ubezpieczeniowo-Finansowa "Aegis Polska S.A." obsługuje 3,5 miliona ubezpieczonych w zakresie polis komunikacyjnych, majątkowych i na życie, zarządzając aktywami o wartości 12 miliardów PLN. Infrastruktura IT składa się z centralnego systemu polisowego, hurtowni danych, platformy likwidacji szkód oraz ponad 120 wirtualnych botów robotyzacji procesów (UiPath RPA), które automatycznie pobierają dane o szkodach, weryfikują polisy w Ubezpieczeniowym Funduszu Gwarancyjnym (UFG) i zlecają wypłaty odszkodowań.

Stan zastały w obszarze zarządzania kontami serwisowymi i tożsamościami maszynowymi:

• W domenie Active Directory funkcjonuje 180 domenowych kont użytkowników wykorzystywanych jako konta serwisowe do uruchamiania usług Windows, pul aplikacji IIS, zadań harmonogramu zadań oraz botów RPA. Organizacja nie posiada centralnego rejestru tożsamości nieludzkich (brak przypisanego właściciela biznesowego, brak informacji o krytyczności i powiązanych systemach).
• Audyt techniczny z użyciem skryptów PowerShell odpytujących kontrolery domeny ujawnił, że:
  • 52 konta serwisowe posiadają członkostwo w grupie `Domain Admins` lub `Schema Admins`. Administratorzy tłumaczyli to faktem, że "aplikacje nie chciały działać poprawnie na zwykłych kontach i był to najszybszy sposób na uruchomienie usług".
  • Wszystkie 180 kont serwisowych posiada włączony atrybut `PasswordNeverExpires` (hasło nigdy nie wygasa). Średni wiek hasła dla tej grupy kont wynosi 5,5 roku, a hasła nigdy nie były zmieniane od momentu wdrożenia systemów.
  • 38 kont serwisowych posiada zarejestrowany atrybut `ServicePrincipalName` (SPN), z czego 26 kont posiada słabe hasła (poniżej 12 znaków, podatne na ataki słownikowe) i korzysta z przestarzałego szyfrowania Kerberos RC4-HMAC. Audytorzy przeprowadzili kontrolowany test Kerberoasting: zażądali biletów TGS dla tych usług jako zwykły użytkownik domeny, a następnie w ciągu 18 minut odzyskali hasła w trybie offline dla 11 kont serwisowych, w tym konta z uprawnieniami Domain Admins.
• W strukturze procesów RPA (boty UiPath) hasła do baz produkcyjnych i interfejsów bankowych są zapisane jawnym tekstem w plikach konfiguracyjnych `.xml` i `.config` umieszczonych na współdzielonych zasobach sieciowych dostępnych dla wszystkich pracowników pionu likwidacji szkód.
• W logach zdarzeń kontrolerów domeny (Event ID 4769 - zażądanie biletu Kerberos TGS) brak jest jakiegokolwiek monitorowania zapytań o bilety szyfrowane RC4, co oznacza, że ataki Kerberoasting mogą być przeprowadzane w sieci Aegis całkowicie niezauważenie dla personelu SOC.

Zarząd Spółki, w związku z wymogami audytu odporności operacyjnej DORA oraz inspekcją UKNF, zleca audytorom pilną diagnozę tożsamości maszynowych, wyliczenie ryzyk w matrycy 3x3 i sporządzenie Planu CAP.

Praca w zespole 2-3 osobowym polega na wszechstronnym zbadaniu procesów uwierzytelniania i autoryzacji w szpitalu oraz zaproponowaniu rozwiązań eliminujących anonimowość pracy personelu:

• Krok 1 (Podział ról w zespole audytorskim):

  Student 1 (Audytor Wiodący / Ekspert DORA i Ładu Ubezpieczeniowego): Bada zgodność z rozporządzeniem DORA, Rekomendacją D KNF, Ustawą o działalności ubezpieczeniowej, relacje z CISO i koordynuje referat.

  Student 2 (Audytor Techniczny IAM/AD / Specjalista Bezpieczeństwa Tożsamości Maszynowych): Analizuje konfigurację kont serwisowych przez PowerShell, bada atrybuty SPN, logi Event 4769/4768, podatności Kerberoasting, szyfrowanie AES-256 vs RC4 oraz projektuje migrację na konta gMSA.

  Student 3 (Audytor Ryzyka Teleinformatycznego i Jakości CAP): Przeprowadza szacowanie ryzyka w matrycy 3x3 dla kompromitacji kontrolera domeny i kradzieży bazy polis, klasyfikuje niezgodności, prowadzi analizę 5 Why i konstruuje tabelę Planu CAP. W zespole 2-osobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zidentyfikowanych Luk NHI):

  Oceńcie ryzyka w matrycy 3x3 w skali prawdopodobieństwa (1-Niskie, 2-Średnie, 3-Wysokie) i skutku (1-Niski, 2-Średni, 3-Krytyczny - przejęcie całej domeny AD, paraliż wypłat odszkodowań, sankcje KNF):

  • Ryzyko 1: Całkowite przejęcie Active Directory w ataku Kerberoasting na konto serwisowe z Domain Admins (P=3, S=3 -> R=9).
  • Ryzyko 2: Wykradzenie poświadczeń bazodanowych zapisanych jawnym tekstem w konfiguracji botów RPA (P=3, S=3 -> R=9).
  • Ryzyko 3: Wyciek bazy danych 3,5 mln ubezpieczonych przez skompromitowane konto serwisowe (P=3, S=3 -> R=9).
  • Ryzyko 4: Dotkliwe kary finansowe nakładane przez KNF za brak realizacji Rekomendacji D (P=3, S=2 -> R=6).
• Krok 3 (Formalna Kwalifikacja Niezgodności NC1/NC2/OFI):

  Sformułujcie karty niezgodności z powołaniem na punkty norm i przepisów:

  • NC1 (Niezgodność Duża): Przypisanie uprawnień Domain Admins kontom serwisowym oraz podatność kont z atrybutem SPN na ataki Kerberoasting (naruszenie kontroli A.8.2 i A.8.5 ISO 27001:2022, Rekomendacji 9 i 10 Rekomendacji D KNF oraz art. 9 rozporządzenia DORA).
  • NC1 (Niezgodność Duża): Przechowywanie haseł do produkcyjnych baz danych jawnym tekstem w plikach konfiguracyjnych botów RPA (naruszenie kontroli A.8.5 ISO 27001, art. 32 RODO oraz tajemnicy ubezpieczeniowej).
  • NC2 (Niezgodność Mała): Brak centralnego rejestru tożsamości nieludzkich (NHI) i brak procedury okresowej rotacji poświadczeń kont serwisowych (kontrola A.5.15 i A.5.18 ISO 27001).
  • OFI (Szansa na doskonalenie): Brak wdrożenia tożsamości zarządzanych Microsoft Entra Workload Identities dla komponentów chmurowych.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (nadawanie kontom serwisowym uprawnień Domain Admins i brak rotacji haseł od 5 lat) przeprowadźcie sekwencję 5 Why:

  1. Dlaczego konta serwisowe posiadały uprawnienia Domain Admins? Bo podczas instalacji aplikacji dochodziło do błędów uprawnień i administratorzy nadawali najwyższe uprawnienia, aby aplikacja działała bez problemów.

  2. Dlaczego nikt nie zredukował tych uprawnień po pomyślnym uruchomieniu aplikacji? Bo Dział IT obawiał się, że próba odebrania uprawnień zepsuje krytyczne procesy biznesowe likwidacji szkód.

  3. Dlaczego nie wdrożono kont zarządzanych grupowo (gMSA) ani sejfu haseł? Bo w zespole administratorów brakowało wiedzy na temat technologii gMSA w Windows Server oraz brakowało czasu na przeprowadzenie migracji.

  4. Dlaczego Dział Cyberbezpieczeństwa nie wymusił audytu uprawnień kont technicznych? Bo polityki bezpieczeństwa w firmie koncentrowały się wyłącznie na kontach użytkowników ludzkich (pracowników), ignorując tożsamości maszynowe.

  5. Dlaczego ignorowano zagrożenia ze strony tożsamości maszynowych? (PRZYCZYNA ŹRÓDŁOWA): Brak w Spółce kompleksowej Strategii Zarządzania Tożsamościami Nieludzkimi (Non-Human Identity Governance) oraz brak narzędzi do automatycznego wykrywania nadmiernych uprawnień kont maszynowych w potokach automatyzacji RPA.

• Krok 5 (Opracowanie Planu Działań Korygujących - CAP):

  Zestawcie tabelę CAP z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.

• Krok 6 (Projekt Rozwiązania Technicznego i Nowej Architektury Kont Serwisowych):

  Zaprojektujcie:

  • Program migracji na Group Managed Service Accounts (gMSA): eliminacja tradycyjnych kont użytkownika dla 180 usług; przypisanie kont gMSA z automatyczną, 128-znakową rotacją haseł realizowaną przez kontrolery domeny co 30 dni; wymuszenie szyfrowania Kerberos AES-256 i wyłączenie RC4.
  • Wdrożenie sejfu poświadczeń PAM (CyberArk / HashiCorp Vault) zintegrowanego z botami UiPath: usunięcie haseł jawnych z plików konfiguracyjnych; dynamiczne pobieranie poświadczeń przez API sejfu w czasie wykonywania zadania; monitoring Event ID 4769 w SIEM pod kątem ataków Kerberoasting.

Struktura zaawansowanego referatu seminaryjnego (15 minut):

• Wprowadzenie i wyzwania tożsamości nieludzkich (NHI) (3 min): Rola Aegis Polska S.A., skala automatyzacji botami RPA i rygory rozporządzenia DORA (Student 1).
• Wyniki audytu IAM i matryca ryzyka 3x3 (4 min): Przedstawienie dowodów uprawnień Domain Admins dla kont usługowych, testu Kerberoasting (R=9) i haseł jawnych w RPA (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Przedstawienie ścieżki dochodzenia do pierwotnej przyczyny (pomijanie tożsamości maszynowych) i kwalifikacja prawna (Student 3).
• Plan CAP i architektura gMSA z sejfem poświadczeń (4 min): Prezentacja migracji na gMSA, integracji sejfu z UiPath, monitoringu Kerberos w SIEM oraz bilansu korzyści (cały zespół).

Raport seminaryjny (objętość 8-12 stron A4) musi zawierać:

A. Wyczerpujące odpowiedzi na pytania problemowe i diagnozę systemową:

• Na czym polega wektor ataku Kerberoasting na konta z zarejestrowaną główną nazwą usługi (SPN) w usłudze Active Directory i dlaczego konta serwisowe o słabych hasłach stanowią dla napastnika najprostszą drogę do przejęcia uprawnień Domain Admins?
• W jaki sposób technologia Group Managed Service Accounts (gMSA) w systemach Windows Server eliminuje ryzyko związane z zarządzaniem hasłami kont serwisowych i jakie są techniczne wymagania jej wdrożenia?
• W jaki sposób zorganizować bezpieczne zarządzanie poświadczeniami dla botów automatyzacji procesów (RPA) i potoków skryptowych, aby wyeliminować przechowywanie haseł otwartym tekstem w kodzie i plikach konfiguracyjnych?

B. Wzorcowe rozwiązanie problemu (Raport audytowy, Matryca Ryzyka, Karty NC i Plan CAP):

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Przejęcie kontrolera domeny w wyniku ataku Kerberoasting na konto SPN -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Migracja na gMSA + wymuszenie AES-256 + reguły SIEM -> P_rez=1, S_rez=3, R_rez=3 (Pod kontrolą).
  • Ryzyko 2: Kradzież poświadczeń bazodanowych z plików konfiguracyjnych botów RPA -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Integracja UiPath z sejfem HashiCorp Vault przez API -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Wyciek bazy polis ubezpieczeniowych i tajemnicy ubezpieczeniowej -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Odebranie uprawnień Domain Admins kontom serwisowym (Least Privilege) -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 4: Sankcje regulacyjne KNF i kary z tytułu rozporządzenia DORA -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Wdrożenie zintegrowanego Planu CAP przed inspekcją UKNF -> P_rez=1, S_rez=2, R_rez=2.
• Zestawienie Kart Niezgodności: Pełne karty dla 2 Niezgodności Dużych (NC1), 1 Niezgodności Małej (NC2) oraz 1 Szansy na doskonalenie (OFI).
• Raport z Analizy Przyczyn Źródłowych metodą 5 Why dla braku kontroli nad tożsamościami maszynowymi.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Natychmiastowe usunięcie 52 kont serwisowych z grup Domain Admins i Enterprise Admins oraz przypisanie uprawnień minimalnych (Właściciel: Główny Administrator AD, Termin: 7 dni, KPI: zero kont serwisowych w Domain Admins).
  • Zadanie CAP-2: Przeprowadzenie migracji 120 kont serwisowych na konta zarządzane grupowo gMSA z automatyczną rotacją haseł (Właściciel: Kierownik Sekcji Infrastruktury Systemowej, Termin: 45 dni, KPI: 100% kwalifikujących się usług na gMSA).
  • Zadanie CAP-3: Wdrożenie sejfu poświadczeń HashiCorp Vault i migracja sekretów ze 120 botów UiPath RPA do sejfu (Właściciel: Kierownik Zespołu Automatyzacji i RPA, Termin: 30 dni, KPI: zero haseł w plikach `.config`).
  • Zadanie CAP-4: Wdrożenie reguły analitycznej w systemie SIEM wykrywającej anomalne żądania biletów TGS z szyfrowaniem RC4 (Event ID 4769) (Właściciel: Kierownik Security Operations Center, Termin: 7 dni, KPI: generowanie alertu wysokiego priorytetu w czasie rzeczywistym).
• Projekt Dokumentu: "Polityka Zarządzania Tożsamościami Nieludzkimi (Non-Human Identities Policy) oraz Standard Bezpieczeństwa Kont Serwisowych i Botów RPA w Aegis Polska S.A.".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Całkowite uodpornienie domeny Active Directory na ataki Kerberoasting; automatyzacja zarządzania poświadczeniami eliminująca błędy ludzkie; pełna ochrona tajemnicy ubezpieczeniowej i danych klientów; 100% zgodność z Rekomendacją D KNF i rozporządzeniem DORA.
• Wady i trudności: Złożoność techniczna wdrożenia kont gMSA w środowiskach wieloserwerowych; konieczność modyfikacji kodu kilkudziesięciu botów RPA w celu pobierania haseł przez API sejfu; ryzyko chwilowych przestojów aplikacji podczas migracji kont serwisowych.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - Kontrole A.5.15 (Zarządzanie tożsamością), A.8.2 (Uprzywilejowane prawa dostępu), A.8.5 (Bezpieczne uwierzytelnianie).
• Komisja Nadzoru Finansowego (KNF): "Rekomendacja D dotycząca zarządzania obszarami IT i bezpieczeństwa środowiska teleinformatycznego" (Rekomendacje 9, 10, 11), Warszawa.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA) - art. 9 i 10 (Zarządzanie tożsamościami i uprawnieniami ICT).
• Ustawa z dnia 11 września 2015 r. o działalności ubezpieczeniowej i reasekuracyjnej (Dz.U. z 2023 r. poz. 656 z późn. zm.) - art. 35 (tajemnica ubezpieczeniowa).
• Microsoft Corporation: "Group Managed Service Accounts (gMSA) Overview and Security Architecture", Microsoft Learn, 2023.
• Center for Internet Security (CIS): "CIS Microsoft Windows Server 2022 Benchmark - Service Account Hardening Guide".

• U2 Student wykrywa podatności protokołu Kerberos i uchybienia w konfiguracji tożsamości maszynowych (NHI).
• U1 Student projektuje architekturę kont gMSA oraz model integracji sejfu sekretów z botami RPA.
• U3 Student szacuje ryzyka kompromitacji kontrolera domeny w matrycy 3x3 w ujęciu inherentnym i rezydualnym.
• U4 Student przeprowadza dochodzenie przyczyn źródłowych 5 Why i konstruuje Plan Działań Korygujących (CAP) spełniający standardy sektora finansowego.
• W1W2W3 Student zna wytyczne Rekomendacji D KNF, rozporządzenia DORA, normy ISO 27001 oraz mechanizmy protokołu Kerberos.
• K1K2K3 Student cechuje się techniczną dociekliwością, bezkompromisowością wobec długu technologicznego i dbałością o odporność cyfrową sektora finansowego.
• ================================================================================