Laboratorium 5

Głównym celem zadania na ocenę 4.0 jest wykształcenie u studentów zaawansowanych umiejętności audytu systemów tworzenia kopii zapasowych oraz planów odtwarzania awaryjnego (Disaster Recovery Plan - DRP) w podmiocie leczniczym posiadającym status podmiotu kluczowego w rozumieniu dyrektywy NIS2 i ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC). Zadanie wymaga zbadania wielopoziomowej architektury IT szpitala (HIS, PACS, LIS, aparatura IoMT na salach operacyjnych), zidentyfikowania krytycznych luk odporności na złośliwe oprogramowanie szyfrujące (ransomware), przeprowadzenia matrycowej analizy ryzyka 3x3 w podejściu risk-based audit, formalnej kwalifikacji uchybień do kategorii Niezgodności Dużych (NC1), Niezgodności Małych (NC2) i Szans na doskonalenie (OFI), dochodzenia przyczyn źródłowych metodą 5 Why oraz skonstruowania Planu Działań Korygujących (CAP) wprowadzającego utwardzone repozytoria z blokadą czasową (Hardened Linux Repository z Immutability), zautomatyzowane testy restore w sandboxie oraz urealnione parametry RTO i RPO.

Powiązanie z sylabusem i treściami programowymi:

• U2 Profesjonalna identyfikacja i formalna gradacja uchybień w środowisku backupu i DRP (NC1/NC2/OFI) z precyzyjną referencją do normy ISO/IEC 27001:2022 (A.8.13, A.5.29, A.5.30), ISO 22301:2020 oraz art. 32 RODO.
• U1 Opracowanie zaawansowanego projektu architektury kopii zapasowych odpornej na ransomware (Hardened Repository, izolacja VLAN, brak relacji zaufania z domeną Active Directory) oraz procedury cyklicznych testów restore.
• U3 Przeprowadzenie analizy ryzyka w matrycy 3x3 dla wektorów ataku ransomware niszczącego kopie i paraliżu bloku operacyjnego w ujęciu ryzyka inherentnego i rezydualnego.
• U4 Opracowanie kompleksowego Planu Działań Korygujących (CAP) opartego na analizie 5 Why z mierzalnymi wskaźnikami KPI i terminami wdrożenia (14-90 dni).
• W1W2W3 Dogłębna znajomość wymogów dyrektywy NIS2 dla sektora ochrony zdrowia, art. 32 ust. 1 lit. b i c RODO, normy PN-EN ISO 22301, PN-EN ISO/IEC 27001:2022 oraz wytycznych Centrum e-Zdrowia (CeZ).
• K1K2K3 Niezależność oceny audytorskiej, wysoka etyka zawodowa, zrozumienie priorytetu ratowania życia ludzkiego oraz odporność na presję minimalizacji kosztów IT kosztem bezpieczeństwa pacjentów.
• Powiązanie z wykładem: Wyk1 (Audyt ISMS w sektorze zdrowia), Wyk3 (Kontrole A.8.13 i A.5.30 ISO 27001), Wyk4 (RODO i NIS2), Wyk5 (Matrycowa analiza ryzyka 3x3), Wyk6 (Sampling logów backupu i badanie integralności VSS), Wyk7 (Metodyka CAP i 5 Why).

Wojewódzki Szpital Zespolony i Centrum Onkologii posiada 26 oddziałów stacjonarnych (w tym Szpitalny Oddział Ratunkowy, 3 Oddziały Intensywnej Terapii, Blok Operacyjny z 12 salami, Oddział Onkologii Klinicznej, Radioterapię oraz Bank Krwi), dysponując 850 łóżkami i hospitalizując rocznie ponad 60 000 pacjentów. Szpital przetwarza dokumentację medyczną 400 000 chorych w systemie HIS (bazy Oracle Database Enterprise Edition), przechowując ponad 40 TB badań obrazowych w systemie PACS oraz monitorując pacjentów przez 300 telemetrycznych kardiomonitorów i pomp infuzyjnych (sieć IoMT).

Stan faktyczny w obszarze tworzenia kopii zapasowych i planów awaryjnych:

• Do tworzenia kopii zapasowych wykorzystywany jest centralny serwer backupowy pod kontrolą systemu Windows Server, zintegrowany z główną domeną Active Directory ("szpital.local"). Dane zrzucane są na macierz NAS po protokole SMB/CIFS.
• Udział sieciowy z plikami kopii na macierzy NAS posiada pełne uprawnienia zapisu i modyfikacji dla grupy "Domain Admins". Co więcej, hasło do konsoli oprogramowania backupowego jest identyczne z hasłem administratora domeny szpitala.
• W szpitalu nie wdrożono technologii niezmienności danych (Immutability / WORM). Pliki kopii mogą zostać skasowane lub nadpisane bezpośrednio z poziomu wiersza poleceń PowerShell lub z konsoli oprogramowania backupowego.
• Audyt techniczny logów systemowych za ostatnie 90 dni wykazał, że zrzuty bazy danych Oracle były realizowane bez wykorzystania dedykowanego modułu spójności Oracle RMAN (zastosowano zwykły snapshot wolumenu bez zamrażania transakcji VSS). W rezultacie 28 zadań backupowych zakończyło się ostrzeżeniem "Inconsistent Database State", co oznacza, że pliki bazy danych w kopii są w stanie niespójnym i nie pozwalają na uruchomienie instancji bez skomplikowanego, ręcznego odzyskiwania z plików redo log.
• W szpitalu NIGDY nie przeprowadzono pełnego próbnego odtworzenia baz danych HIS ani archiwum PACS w odizolowanym środowisku (brak testów restore). Administratorzy nie dysponują zapasowym środowiskiem serwerowym ani zautomatyzowanym sandboxem wirtualnym.
• W formalnym dokumencie DRP z 2019 roku zadeklarowano wskaźniki: RTO = 4 godziny i RPO = 1 godzina dla całego szpitala. W trakcie wywiadów z ordynatorem Bloku Operacyjnego i kierownikiem Apteki Szpitalnej ustalono, że dla zleceń chemioterapii i operacji onkologicznych akceptowalny czas niedostępności danych nie może przekraczać 30 minut (RTO = 30 min, RPO = 15 min), a 4-godzinny przestój oznacza wstrzymanie operacji ratujących życie i odwołanie naświetlań onkologicznych.
• Szpital nie posiada procedury pracy w trybie papierowym (Emergency Paper Fallback) dla Bloku Operacyjnego i SOR na wypadek paraliżu systemów HIS/PACS przez atak ransomware.

Dyrektor Szpitala, po otrzymaniu ostrzeżenia z CSIRT NASK o nasileniu skoordynowanych ataków ransomware na europejskie szpitale onkologiczne, zleca audytorom pilną i wszechstronną kontrolę gotowości DRP na poziomie oceny 4.0.

Zadanie wymaga przeprowadzenia wnikliwego audytu odporności na ransomware, matrycowej oceny ryzyka 3x3, formalnej klasyfikacji uchybień, analizy przyczyn źródłowych 5 Why oraz opracowania Planu CAP:

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

  Student 1 (Audytor Wiodący / Lead Auditor): Odpowiada za analizę ładu korporacyjnego, wywiady z Dyrekcją i ordynatorami, spójność planu DRP z dyrektywą NIS2 i wymogami CeZ, koordynację matrycy ryzyka oraz moderację referatu seminaryjnego.

  Student 2 (Audytor Techniczny ds. Systemów Backupowych i Storage): Bada konfigurację serwera backupu, uprawnienia domenowe, logi błędów VSS/RMAN, strukturę udziałów SMB, podatność na ransomware, parametry techniczne Immutability na systemie Linux oraz konfigurację środowiska testowego (Sandbox).

  Student 3 (Audytor Zgodności Regulacyjnej RODO, Ryzyka i Jakości CAP): Przeprowadza ocenę skutków dla pacjentów (art. 32 RODO), formalną gradację niezgodności (NC1/NC2/OFI), prowadzi sekwencję 5 Why dla kluczowej niezgodności oraz konstruuje tabelę Planu Działań Korygujących (CAP). W zespole dwuosobowym zadania te dzielą Studenci 1 i 2.

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zidentyfikowanych Luk Backup/DRP):

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

  • Skala prawdopodobieństwa (P): 1 - Niskie (mało prawdopodobne), 2 - Średnie (możliwe w horyzoncie roku), 3 - Wysokie (bardzo prawdopodobne lub występujące permanentnie).
  • Skala skutku (S): 1 - Niski (krótkotrwałe utrudnienie bez wpływu na zdrowie), 2 - Średni (opóźnienie zabiegów, naruszenie tajemnicy medycznej), 3 - Krytyczny (zagrożenie życia pacjentów na bloku operacyjnym, zgon w wyniku braku danych o lekach, wielomilionowe straty).
  • Poziom ryzyka (R = P x S): 1-2 (Ryzyko Akceptowalne), 3-4 (Ryzyko Średnie - wymagana kontrola), 6-9 (Ryzyko Krytyczne - natychmiastowe działanie mitygujące).

  Wyliczcie ryzyko inherentne dla:

  1. Całkowitego zaszyfrowania bazy produkcyjnej HIS i udziału backupowego NAS przez ransomware z uprawnieniami Domain Admin (P=3, S=3 -> R=9).

  2. Braku możliwości odtworzenia bazy Oracle z niespójnych zrzutów snapshotowych bez RMAN (P=3, S=3 -> R=9).

  3. Zgonu pacjenta lub powikłań z powodu 4-godzinnego braku dostępu do historii choroby na Bloku Operacyjnym przy zadeklarowanym nierealnym RTO (P=2, S=3 -> R=6).

  4. Paraliżu izby przyjęć i SOR z powodu braku procedur papierowego fallbacku przy awarii HIS (P=3, S=2 -> R=6).

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

  Sformułujcie karty niezgodności z powołaniem na konkretne punkty normy ISO/IEC 27001:2022 oraz akty prawne:

  • NC1 (Niezgodność Duża): Przechowywanie kopii zapasowych w tej samej domenie Active Directory na udziale SMB z prawami zapisu dla Domain Admins oraz brak technologii niezmienności danych (Immutability/WORM), co stwarza bezpośrednie ryzyko jednoczesnego zniszczenia danych produkcyjnych i kopii przez ransomware (naruszenie art. 32 ust. 1 lit. c RODO, kontroli ISO 27001:2022 A.8.13, A.5.30 oraz art. 21 dyrektywy NIS2).
  • NC1 (Niezgodność Duża): Wykonywanie kopii baz danych Oracle bez zapewnienia spójności transakcyjnej (brak integracji z Oracle RMAN) oraz całkowity brak weryfikacji odtwarzalności kopii w testach restore (naruszenie kontroli ISO 27001 A.8.13 i normy ISO 22301 p. 8.4).
  • NC2 (Niezgodność Mała): Niedostosowanie zadeklarowanych wskaźników RTO/RPO w planie DRP do krytycznych wymagań Bloku Operacyjnego i Oddziału Onkologii (brak aktualizacji analizy BIA).
  • OFI (Szansa na doskonalenie): Brak wdrożenia zapasowego łącza satelitarnego dla wymiany danych telemedycznych z Narodowym Instytutem Onkologii na wypadek odcięcia światłowodów miejskich.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (brak niezmienności kopii i obecność udziału NAS w domenie Active Directory) przeprowadźcie dochodzenie 5 Why:

  1. Dlaczego udział sieciowy z kopiami zapasowymi znajduje się w domenie Active Directory i nie posiada blokady kasowania? Ponieważ informatycy skonfigurowali go jako standardowy zasób sieciowy SMB na istniejącej macierzy biurowej NAS.

  2. Dlaczego wykorzystano standardowy udział SMB zamiast dedykowanego, odizolowanego repozytorium kopii? Ponieważ nie zakupiono dedykowanego serwera z systemem Linux i pamięcią masową obsługującą niezmienność danych.

  3. Dlaczego nie zakupiono dedykowanego sprzętu pod bezpieczny backup? Ponieważ Dział IT zgłaszał wniosek inwestycyjny, lecz został on odrzucony przez Dyrekcję Finansową podczas prac nad budżetem rocznym.

  4. Dlaczego Dyrekcja Finansowa odrzuciła wniosek o bezpieczną infrastrukturę backupową? Ponieważ uznała wydatek za zbędny, opierając się na zapewnieniu, że szpital "posiada już macierz NAS i oprogramowanie do kopii".

  5. Dlaczego Dyrekcja Finansowa nie zrozumiała krytycznego zagrożenia ransomware dla kopii w domenie? (PRZYCZYNA ŹRÓDŁOWA): Brak w szpitalu sformalizowanego systemu zarządzania bezpieczeństwem informacji (ISMS wg ISO 27001) oraz brak interdyscyplinarnego Komitetu ds. Ciągłości Działania, który tłumaczyłby ryzyka cybernetyczne na wymiar finansowy i prawny, co skutkowało podejmowaniem decyzji budżetowych bez znajomości realiów nowoczesnych cyberzagrożeń.

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

  Skonstruujcie tabelę CAP zawierającą: 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 Awaryjnej):

  Zaprojektujcie:

  • Architekturę Hardened Linux Repository z systemem plików XFS i atrybutem niezmienności na 30 dni, odciętą od domeny Active Directory, z dostępem wyłącznie po dedykowanym protokole z portami blokowanymi na zaporze ogniowej.
  • Zintegrowaną procedurę tworzenia kopii bazy Oracle z wykorzystaniem Oracle RMAN w trybie archivelog i backupów logów transakcyjnych co 15 minut (zapewnienie RPO = 15 min).
  • Standardową Procedurę Operacyjną (SOP) "Postępowanie personelu Bloku Operacyjnego i SOR w warunkach całkowitej niedostępności systemu HIS (Emergency Paper Fallback)" z predefiniowanymi formularzami papierowymi zleceń krwi i leków.

Zaawansowane wystąpienie seminaryjne (15 minut) przed audytorium:

• Wprowadzenie i specyfika podmiotu kluczowego NIS2 w ochronie zdrowia (3 min): Struktura szpitala onkologicznego, rygory dostępności danych w ratowaniu życia, rola wskaźników RTO/RPO na sali operacyjnej (Student 1).
• Diagnoza techniczna podatności na ransomware i błędy VSS (4 min): Przedstawienie dowodów z analizy udziału SMB w domenie, braku immutability, 28 niespójnych zrzutów Oracle oraz prezentacja matrycy ryzyka 3x3 (Student 2).
• Kwalifikacja uchybień (karty NC1/NC2/OFI) oraz analiza 5 Why (4 min): Uzasadnienie prawne naruszeń art. 32 RODO i NIS2 oraz prezentacja przyczyny źródłowej w procesie budżetowania IT (Student 3).
• Prezentacja Planu Działań Korygujących (CAP) i architektury Hardened Repository (4 min): Demonstracja działania linuksowego repozytorium WORM, zautomatyzowanego sandboxu testowego, procedury papierowej dla chirurgów oraz bilansu zysków i strat (cały zespół).

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

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

• W jaki sposób zorganizowane grupy cyberprzestępcze (Ransomware-as-a-Service) przeprowadzają rekonesans w sieci szpitalnej, lokalizują serwery kopii zapasowych i dlaczego brak immutability prowadzi do wymuszenia wielomilionowych okupów?
• Dlaczego wykonywanie kopii zapasowej bazy danych Oracle/MSSQL na poziomie snapshotu dyskowego bez wykorzystania interfejsów aplikacyjnych (VSS Writer / Oracle RMAN) generuje pliki w stanie niespójnym transakcyjnie i czym grozi próba odzyskania danych z takiej kopii w warunkach awarii krytycznej?
• W jaki sposób pogodzić rygorystyczne wymagania bezpieczeństwa teleinformatycznego z ergonomią i szybkością działania personelu medycznego na Bloku Operacyjnym podczas wstrząsu krwotocznego pacjenta?

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

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Całkowite zaszyfrowanie backupów na udziale SMB przez ransomware -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Hardened Linux Repository z blokadą WORM na 30 dni, odcięcie od AD -> P_rez=1, S_rez=3, R_rez=3 (Ryzyko akceptowalne).
  • Ryzyko 2: Niespójność bazy danych Oracle w plikach kopii -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Wdrożenie wtyczki Oracle RMAN z weryfikacją bloków i backupem logów redo co 15 min -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Śmierć pacjenta z powodu 4-godzinnego braku danych na sali operacyjnej -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Reklasyfikacja RTO do 30 min, wdrożenie Instant Recovery i procedury Paper Fallback -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 4: Paraliż rejestracji i brak rozliczeń z NFZ w wyniku awarii -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Kwartalne testy restore w wirtualnym sandboxie z certyfikatem spójnoś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 Dochodzenia Przyczyn Źródłowych metodą 5 Why dla braku izolacji i niezmienności kopii.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Wdrożenie serwera Hardened Linux Repository (Ubuntu LTS + XFS) z niezmiennym systemem plików na 30 dni i odseparowanym VLAN-em (Właściciel: Kierownik Działu IT, Termin: 30 dni, KPI: 100% kopii z flagą Immutable, zero praw zapisu dla kont domenowych).
  • Zadanie CAP-2: Konfiguracja modułu Oracle RMAN dla baz danych HIS z backupem logów archiwalnych co 15 minut i automatycznym testem spójności (Właściciel: Administrator Bazy Danych, Termin: 14 dni, KPI: status RMAN Validate Successful dla 100% zadań, RPO poniżej 15 min).
  • Zadanie CAP-3: Wdrożenie zautomatyzowanego środowiska testowego (Virtual Sandbox) z cotygodniowym próbnym podnoszeniem maszyn HIS/PACS (Właściciel: Inżynier Systemowy, Termin: 45 dni, KPI: cotygodniowy automatyczny raport z testu uruchomienia bazy w czasie poniżej 25 minut).
  • Zadanie CAP-4: Opracowanie, zatwierdzenie i wdrożenie procedury Emergency Paper Fallback dla Bloku Operacyjnego i SOR (Właściciel: Dyrektor ds. Medycznych i Pielęgniarka Naczelna, Termin: 21 dni, KPI: 100% sal operacyjnych wyposażonych w teczki procedur awaryjnych, przeprowadzenie ćwiczeń symulacyjnych).
• Projekt Procedury Operacyjnej: "Standardowa Procedura Operacyjna DRP-MED-01: Zarządzanie Kopiami Bezpieczeństwa w Standardzie Hardened Repository, Cykliczne Testy Odtwarzania oraz Procedura Fallbacku Klinicznego".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Całkowita odporność kopii na ransomware (nawet przy pełnej kompromitacji kontrolera domeny atakujący nie usunie punktów przywracania); zagwarantowanie spójności transakcyjnej baz Oracle; skrócenie wskaźnika RTO dla bloku operacyjnego do 30 minut; zapewnienie ciągłości leczenia dzięki procedurze papierowej; pełna zgodność z RODO i dyrektywą NIS2.
• Wady i trudności: Koszt zakupu nowego serwera fizycznego pod linuksowe repozytorium; konieczność przeszkolenia zespołu IT w administracji systemami Linux i narzędziem Oracle RMAN; konieczność dyscyplinowania personelu medycznego do comiesięcznych ćwiczeń procedur papierowych.

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO): art. 32 (Bezpieczeństwo przetwarzania - w szczególności lit. b i c dotyczące ciągłości i przywracania dostępności danych).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - art. 21 (Środki zarządzania ryzykiem w cyberbezpieczeństwie dla sektora ochrony zdrowia).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - A.8.13 (Tworzenie kopii zapasowych informacji), A.8.14 (Redundancja), A.5.29 (Gotowość w czasie zakłóceń), A.5.30 (Gotowość ICT do ciągłości działania).
• Norma PN-EN ISO 22301:2020: Bezpieczeństwo i odporność - Systemy zarządzania ciągłością działania - Wymagania (punkt 8.4 Gotowość i reagowanie na incydenty).
• Centrum e-Zdrowia (CeZ): "Standardy cyberbezpieczeństwa dla podmiotów leczniczych w zakresie EDM i systemów szpitalnych", Warszawa 2023.
• CSIRT NASK / CERT Polska: "Zalecenia dotyczące budowy odpornych na ransomware architektur kopii zapasowych", Warszawa 2023.

• U2 Student bezbłędnie klasyfikuje uchybienia w architekturze backupu szpitalnego do kategorii NC1/NC2/OFI z referencją do normy ISO 27001, ISO 22301 i RODO.
• U1 Student projektuje schemat utwardzonego repozytorium Linux z immutability oraz procedurę zautomatyzowanych testów restore w sandboxie.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 w ujęciu inherentnym i rezydualnym dla procesów ratowania życia.
• U4 Student przeprowadza analizę przyczyn źródłowych 5 Why i sporządza wykonalny Plan Działań Korygujących (CAP).
• W1W2W3 Student wykazuje dogłębną znajomość norm ISO 27001, ISO 22301, dyrektywy NIS2 oraz wymogów prawnych ochrony danych medycznych.
• K1K2K3 Student przejawia odpowiedzialność za bezpieczeństwo pacjentów, etykę zawodową oraz zdolność merytorycznej obrony inwestycji w cyberodporność przed dyrekcją szpitala.

Celem zadania na ocenę 4.0 jest wykształcenie u studentów zaawansowanych kompetencji audytu środowiskowego, fizycznego i logicznego procesu składowania kopii zapasowych w jednostce samorządu terytorialnego (JST) i Samorządowym Centrum Usług Wspólnych (SCUW). Zadanie skupia się na weryfikacji wdrożenia nowoczesnej reguły 3-2-1-1-0 (3 kopie, 2 różne nośniki, 1 kopia off-site, 1 kopia offline/immutable, 0 błędów w testach weryfikacyjnych), ocenie odporności serwerowni na katastrofy naturalne (zalanie, pożar), audycie certyfikacji sejfów ognioodpornych na nośniki cyfrowe (norma PN-EN 1047-1 klasa DIS), wdrożeniu kryptograficznej ochrony AES-256 oraz analizie zgodności z Krajowymi Ramami Interoperacyjności (KRI). Studenci przeprowadzają matrycową analizę ryzyka 3x3, gradację niezgodności (NC1/NC2/OFI), analizę 5 Why oraz konstruują Plan Działań Korygujących (CAP).

Powiązanie z sylabusem i treściami programowymi:

• U2 Profesjonalna identyfikacja i formalna kwalifikacja uchybień w zakresie fizycznego i logicznego składowania kopii zapasowych rejestrów publicznych (NC1/NC2/OFI) z odniesieniem do par. 20 KRI i ISO 27001.
• U1 Opracowanie zaawansowanego projektu infrastruktury składowania kopii off-site z wykorzystaniem dedykowanego łącza światłowodowego do jednostki podległej, sejfu klasy S 120 DIS oraz procedury depozytowej.
• U3 Przeprowadzenie analizy ryzyka jednoczesnego zniszczenia rejestrów publicznych (EGiB, ewidencja pojazdów) w wyniku awarii hydraulicznej lub pożaru w zabytkowym budynku urzędu z użyciem matrycy 3x3.
• U4 Opracowanie Planu Działań Korygujących (CAP) opartego na analizie przyczyn źródłowych 5 Why z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.
• W1W2W3 Dogłębna znajomość par. 20 ust. 2 pkt 11 i 12 KRI, normy PN-EN ISO/IEC 27001:2022 (kontrole A.7.10, A.8.13), normy PN-EN 1047-1 oraz art. 32 RODO.
• K1K2K3 Skrupulatność audytorska przy inspekcji warunków fizycznych serwerowni, poszanowanie mienia publicznego i bezstronność w ocenie ryzyk samorządowych.
• Powiązanie z wykładem: Wyk1 (Audyt w administracji samorządowej), Wyk3 (Kontrole środowiskowe i nośnikowe ISO 27001), Wyk4 (Zgodność z KRI i RODO), Wyk5 (Matrycowa analiza ryzyka 3x3), Wyk6 (Metodyka inspekcji fizycznej i samplingu nośników), Wyk7 (Procedura CAP i 5 Why).

Starostwo Powiatowe w Jędrzejowie oraz utworzone przy nim Samorządowe Centrum Usług Wspólnych IT (SCUW) obsługują 85 000 mieszkańców oraz 14 podległych jednostek organizacyjnych (w tym Powiatowy Urząd Pracy, Zarząd Dróg, 4 zespoły szkół ponadpodstawowych, dom pomocy społecznej i poradnię psychologiczno-pedagogiczną). W starostwie prowadzony jest system Elektronicznego Zarządzania Dokumentacją (EZD RP), rejestr ewidencji gruntów i budynków (EGiB - 140 000 działek ewidencyjnych i ksiąg), rejestr pojazdów i kierowców (system CEPiK/Pojazd) oraz powiatowy zasób geodezyjny o wolumenie ponad 18 TB danych rastrowych i wektorowych.

Stan zastały w obszarze przechowywania kopii zapasowych:

• Główna serwerownia mieści się w piwnicy XIX-wiecznego gmachu starostwa. Bezpośrednio pod stropem, nad szafami rackowymi z serwerami i macierzami produkcyjnymi, biegną rury miejskiej magistrali centralnego ogrzewania oraz rury odpływowe kanalizacji deszczowej. W pomieszczeniu brak jest instalacji wczesnej detekcji dymu (VESDA), brak systemu gaszenia gazem (jest tylko proszkowa gaśnica ręczna) oraz brak czujników wycieku wody na podłodze.
• Kopie zapasowe baz danych systemów dziedzinowych wykonywane są codziennie na lokalną macierz backupową w tej samej serwerowni piwnicznej.
• W celu realizacji wymogu posiadania kopii zewnętrznej, młodszy informatyk urzędu w każdy piątek kopiuje zrzuty baz na przenośne dyski twarde USB (dyski 2,5 cala bez mechanizmu szyfrowania sprzętowego).
• Dyski te są przechowywane w biurku informatyka na parterze budynku lub odkładane na wierzch szafy serwerowej w piwnicy. Od ponad 8 miesięcy żaden dysk nie był deponowany w kasie pancernej w gabinecie Skarbnika z powodu zbiurokratyzowanej procedury kwitowania w księdze depozytowej.
• Żaden egzemplarz kopii nie opuszcza budynku starostwa (brak lokalizacji off-site). W urzędzie nie ma szafy ognioodpornej z atestem dla nośników cyfrowych (klasa DIS wg PN-EN 1047-1). Informatycy używają zwykłej metalowej szafy na akta papierowe (klasa P), nie rozumiejąc, że w temperaturze powyżej 52°C dyski ulegają nieodwracalnemu rozmagnesowaniu i deformacji mechanicznej.
• Dyski USB nie posiadają włączonego szyfrowania BitLocker ani VeraCrypt. W przypadku włamania do pokoju informatyków lub zgubienia dysku w transporcie dojdzie do ujawnienia danych osobowych, numerów PESEL i stanu posiadania wszystkich mieszkańców powiatu.
• Zespół IT nigdy nie zweryfikował odtwarzalności kopii z dysków USB (brak weryfikacji sum kontrolnych i brak próbnych odtworzeń na czystym sprzęcie).

Sekretarz Powiatu, po kontroli Państwowej Straży Pożarnej wskazującej na ryzyko pożarowe w zabytkowym gmachu oraz po lekturze zaleceń NIK w zakresie cyberbezpieczeństwa samorządów, powołuje zespół audytorów do przeprowadzenia zaawansowanego audytu na poziomie oceny 4.0.

Zadanie wymaga oceny warunków środowiskowych serwerowni, weryfikacji wdrożenia reguły 3-2-1-1-0, matrycowej oceny ryzyka 3x3, formalnej klasyfikacji uchybień, analizy 5 Why oraz opracowania Planu CAP:

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

  Student 1 (Audytor Wiodący / Lead Auditor): Odpowiada za relacje ze Starostą, Sekretarzem Powiatu i IOD, weryfikację polityk bezpieczeństwa, regulaminów depozytowych, koordynację matrycy ryzyka oraz moderację referatu.

  Student 2 (Audytor Techniczny ds. Infrastruktury Fizycznej i Pamięci Masowych): Przeprowadza inspekcję serwerowni (instalacje hydrauliczne, klimatyzacja, zasilanie, czujniki), bada stan techniczny dysków USB, brak szyfrowania, konfigurację zadań backupu oraz projektuje bezpieczną architekturę replikacji off-site.

  Student 3 (Audytor Zgodności z KRI, RODO i Jakości CAP): Analizuje par. 20 KRI, art. 32 RODO, normę PN-EN 1047-1, dokonuje formalnej klasyfikacji niezgodności (NC1/NC2/OFI), prowadzi procedurę 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP).

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zidentyfikowanych Luk Składowania):

  Oceńcie ryzyka w matrycy 3x3 (P: 1-3, S: 1-3, R = P x S):

  1. Zniszczenie wszystkich kopii rejestrów EGiB w wyniku zalania piwnicy przez pękniętą rurę magistrali CO (P=3, S=3 -> R=9).

  2. Masowy wyciek numerów PESEL i danych majątkowych mieszkańców w wyniku kradzieży niezaszyfrowanych dysków USB z biurka (P=2, S=3 -> R=6).

  3. Zniszczenie nośników USB w zwykłej szafie metalowej podczas pożaru budynku (temperatura powyżej 52°C) (P=2, S=3 -> R=6).

  4. Brak możliwości odtworzenia systemu EZD RP z powodu błędów na dyskach USB niepoddawanych testom weryfikacyjnym (P=3, S=2 -> R=6).

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

  Sformułujcie karty niezgodności z odniesieniem do KRI, RODO i ISO 27001:

  • NC1 (Niezgodność Duża): Przechowywanie wszystkich egzemplarzy kopii zapasowych rejestrów publicznych w jednym budynku urzędu w pomieszczeniu bezpośrednio zagrożonym zalaniem i pożarem bez lokalizacji zapasowej (off-site), co uniemożliwia realizację reguły 3-2-1-1-0 (rażące naruszenie par. 20 ust. 2 pkt 11 KRI oraz kontroli ISO/IEC 27001:2022 A.8.13).
  • NC1 (Niezgodność Duża): Przenoszenie i przechowywanie kopii zapasowych zawierających dane osobowe mieszkańców na niezaszyfrowanych nośnikach zewnętrznych USB bez ścisłej ewidencji depozytowej (naruszenie art. 32 RODO i kontroli ISO 27001 A.7.10).
  • NC2 (Niezgodność Mała): Stosowanie szafy metalowej na dokumenty papierowe zamiast atestowanego sejfu ognioodpornego klasy DIS na nośniki cyfrowe (naruszenie normy PN-EN 1047-1 i zaleceń KRI).
  • OFI (Szansa na doskonalenie): Brak wdrożenia systemu monitoringu środowiskowego IoT z powiadomieniami SMS/e-mail o temperaturze i wilgotności w szafach serwerowych.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (brak kopii zapasowej poza siedzibą urzędu - off-site) przeprowadźcie dochodzenie 5 Why:

  1. Dlaczego dyski z kopiami zapasowymi pozostają w budynku starostwa? Ponieważ informatyk nie odnosi ich do zewnętrznej lokalizacji depozytowej.

  2. Dlaczego informatyk nie wynosi dysków do innej lokalizacji? Ponieważ nie wyznaczono żadnej oficjalnej lokalizacji zapasowej dla starostwa ani nie zawarto umowy z bankiem lub archiwum depozytowym.

  3. Dlaczego nie wyznaczono lokalizacji zapasowej dla kopii starostwa? Ponieważ Dział IT zgłaszał potrzebę utworzenia punktu zapasowego w Powiatowym Zarządzie Dróg, lecz wniosek nie został sformalizowany.

  4. Dlaczego wniosek IT nie został sformalizowany i wdrożony przez kierownictwo? Ponieważ w starostwie brakowało osoby odpowiedzialnej za całościowe zarządzanie ciągłością działania (brak roli CISO/Oficera Bezpieczeństwa), a informatycy byli traktowani wyłącznie jako serwis techniczny sprzętu.

  5. Dlaczego w strukturze starostwa nie powołano osoby odpowiedzialnej za bezpieczeństwo informacji i BCP? (PRZYCZYNA ŹRÓDŁOWA): Brak świadomości kierownictwa urzędu co do bezwzględnych wymogów prawnych Krajowych Ram Interoperacyjności (KRI) oraz brak audytów zgodności w jednostkach samorządowych, co doprowadziło do wieloletniego tolerowania pozornych zabezpieczeń i lekceważenia ryzyka katastrof fizycznych.

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

  Skonstruujcie 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 Architektury 3-2-1-1-0 i Procedury Depozytowej):

  Zaprojektujcie:

  • Schemat 3-2-1-1-0: 3 kopie danych (produkcja, lokalny backup, zdalna replikacja), 2 różne nośniki (macierz SSD i taśma LTO/chmura), 1 kopia off-site w Powiatowym Zarządzie Dróg (oddalonym o 3 km), 1 kopia offline/immutable (taśma w sejfie), 0 błędów w comiesięcznych testach automatycznych.
  • Zakup i posadowienie atestowanego sejfu ognioodpornego w klasie S 120 DIS (gwarantującego temperaturę wewnątrz poniżej 52°C przez 120 minut w temperaturze pożaru 1090°C).
  • Sformalizowaną procedurę "Zarządzanie Informatycznymi Nośnikami Danych, Obowiązkowe Szyfrowanie AES-256 oraz Elektroniczna Księga Depozytowa".

Zaawansowana prezentacja seminaryjna (15 minut):

• Ramy prawne KRI i specyfika zasobów geodezyjnych powiatu (3 min): Waga rejestrów EGiB i EZD, odpowiedzialność Starosty i wymogi par. 20 KRI (Student 1).
• Wyniki inspekcji fizycznej serwerowni i matryca ryzyka 3x3 (4 min): Przedstawienie zagrożeń hydraulicznych w piwnicy, analiza błędu szafy papierowej vs sejfu DIS, brak szyfrowania dysków USB (Student 2).
• Kwalifikacja uchybień (karty NC1/NC2/OFI) oraz dochodzenie 5 Why (4 min): Prezentacja przyczyny źródłowej (brak roli CISO w samorządzie) i naruszeń KRI oraz RODO (Student 3).
• Plan Działań Korygujących (CAP) i architektura 3-2-1-1-0 (4 min): Demonstracja działania światłowodowej replikacji do PZD, parametrów sejfu S 120 DIS, procedury BitLocker z centralnym escrow kluczy oraz bilansu kosztów (cały zespół).

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

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

• Czym różni się fizycznie i konstrukcyjnie sejf ognioodporny na dokumentację papierową (klasa P) od sejfu na cyfrowe nośniki danych (klasa DIS wg PN-EN 1047-1) i dlaczego zamknięcie dysku USB w kasie pancernej na akta papierowe podczas pożaru kończy się całkowitą utratą danych?
• Jakie są fundamentalne założenia nowoczesnej reguły kopii zapasowych 3-2-1-1-0 i dlaczego jej realizacja jest kluczowa dla spełnienia wymagań par. 20 Krajowych Ram Interoperacyjności w administracji publicznej?
• Jakie ryzyka prawne, finansowe i dyscyplinarne rodzi dla kierowników jednostek samorządowych utrata rejestrów ewidencji gruntów i budynków w świetle Ustawy o informatyzacji podmiotów publicznych i RODO?

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

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Zniszczenie wszystkich kopii rejestrów EGiB w wyniku zalania piwnicy przez rury CO -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Replikacja off-site do PZD światłowodem + przeniesienie racka poza strefę rur -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 2: Masowy wyciek numerów PESEL z zagubionych dysków USB -> P_inh=2, S_inh=3, R_rez=6 -> Kontrola: Bezwzględne szyfrowanie BitLocker AES-256 z kluczem w centralnym sejfie -> P_rez=1, S_rez=2, R_rez=2.
  • Ryzyko 3: Rozmagnesowanie dysków USB w szafie metalowej podczas pożaru -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Wdrożenie atestowanego sejfu klasy S 120 DIS z certyfikatem Instytutu Mechaniki Precyzyjnej -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 4: Brak możliwości odtworzenia EZD RP z powodu błędów nośnika -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Comiesięczne automatyczne testy restore na maszynie wirtualnej z weryfikacją sum kontrolnych SHA-256 -> 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 Dochodzenia Przyczyn Źródłowych metodą 5 Why dla braku kopii off-site.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Uruchomienie bezpiecznego łącza światłowodowego i zdalnego serwera NAS w Powiatowym Zarządzie Dróg z automatyczną nocną replikacją kopii (Właściciel: Dyrektor SCUW, Termin: 45 dni, KPI: 100% zsynchronizowanych danych w lokalizacji PZD, RPO poniżej 24h).
  • Zadanie CAP-2: Zakup, montaż i certyfikacja atestowanego sejfu ognioodpornego klasy S 120 DIS w wydzielonej strefie pożarowej starostwa (Właściciel: Kierownik Wydziału Organizacyjnego, Termin: 30 dni, KPI: certyfikat IMP/ECB-S, audyt posadowienia).
  • Zadanie CAP-3: Wdrożenie centralnej polityki GPO wymuszającej szyfrowanie BitLocker XTS-AES-256 dla wszystkich pamięci przenośnych podłączanych w sieci urzędu (Właściciel: Administrator Sieci SCUW, Termin: 14 dni, KPI: blokada zapisu na nośnikach nieszyfrowanych na 100% stacji).
  • Zadanie CAP-4: Wdrożenie czujników zalania i temperatury zintegrowanych z centralą alarmową w serwerowni piwnicznej (Właściciel: Inspektor ds. BHP i Ppoż., Termin: 21 dni, KPI: 100% pokrycia strefy rackowej czujnikami, test powiadamiania SMS).
• Projekt Procedury Operacyjnej: "Instrukcja Bezpieczeństwa Nr 4: Obieg, Przechowywanie i Depozyt Informatycznych Nośników Danych oraz Replikacja Archiwalna w Starostwie Powiatowym".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Pełna zgodność z regułą 3-2-1-1-0 i Krajowymi Ramami Interoperacyjności; całkowita eliminacja ryzyka zniszczenia rejestrów publicznych przy pożarze lub zalaniu serwerowni; bezpieczeństwo kryptograficzne danych mieszkańców; wykorzystanie istniejącego budynku PZD bez ponoszenia kosztów komercyjnej kolokacji.
• Wady i trudności: Konieczność wygospodarowania środków budżetowych na zakup atestowanego sejfu klasy DIS oraz urządzeń sieciowych; konieczność bieżącego nadzoru nad procedurą rotacji nośników offline i okresowej wymiany taśm/dysków.

• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności (Dz.U. z 2024 r. poz. 733) - par. 20 (zasady tworzenia i przechowywania kopii bezpieczeństwa).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - A.7.10 (Nośniki pamięci), A.8.13 (Tworzenie kopii zapasowych informacji), A.8.14 (Redundancja).
• Norma PN-EN 1047-1: Pomieszczenia i urządzenia do przechowywania wartości - Klasyfikacja i metody badań odporności ogniowej - Część 1: Szafy na nośniki danych i dyskietki (klasy S 60 DIS i S 120 DIS).
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO): art. 32 (Bezpieczeństwo przetwarzania).
• Urząd Ochrony Danych Osobowych (UODO): "Wytyczne dotyczące zabezpieczenia danych na nośnikach wymiennych w jednostkach publicznych", Warszawa 2022.
• Ministerstwo Cyfryzacji: "Standardy cyberbezpieczeństwa i ciągłości działania w jednostkach samorządu terytorialnego", Warszawa 2023.

• U2 Student poprawnie identyfikuje i klasyfikuje uchybienia w składowaniu kopii zapasowych rejestrów samorządowych do kategorii NC1/NC2/OFI.
• U1 Student projektuje schemat bezpiecznej replikacji off-site i procedurę depozytu nośników w atestowanym sejfie DIS.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla zagrożeń środowiskowych i katastrof budowlanych w obiekcie publicznym.
• U4 Student realizuje procedurę 5 Why i opracowuje wykonalny Plan Działań Korygujących (CAP).
• W1W3 Student zna szczegółowe przepisy KRI i RODO dotyczące archiwizacji i zabezpieczania rejestrów publicznych.
• K1K2 Student przejawia odpowiedzialność za ciągłość usług publicznych dla obywateli oraz rzetelność audytorską.

Głównym celem zadania na ocenę 4.0 jest wykształcenie u studentów zaawansowanych umiejętności audytu analizy wpływu na działalność biznesową (Business Impact Analysis - BIA), weryfikacji adekwatności wskaźników RTO (Recovery Time Objective), RPO (Recovery Point Objective) oraz procedur przełączania awaryjnego na zapasowe centrum danych (Disaster Recovery Center - DRC) w instytucji finansowej. Zadanie osadzone jest w realiach banku podlegającego rygorystycznemu nadzorowi Komisji Nadzoru Finansowego (Rekomendacja D, obszar G) oraz europejskiemu rozporządzeniu DORA (Digital Operational Resilience Act). Studenci uczą się weryfikować mechanizmy replikacji transakcyjnej, analizować logi opóźnień (replication lag) w godzinach sesji rozliczeniowych KIR (ELIXIR/Express ELIXIR) i komunikatów SWIFT, badać brak procedur powrotnych (failback), przeprowadzać matrycową analizę ryzyka 3x3, klasyfikować uchybienia (NC1/NC2/OFI), prowadzić analizę 5 Why oraz konstruować Plan Działań Korygujących (CAP).

Powiązanie z sylabusem i treściami programowymi:

• U2 Profesjonalna identyfikacja i formalna kwalifikacja uchybień w procesach replikacji, parametrach BIA oraz gotowości DRC (NC1/NC2/OFI) z referencją do rozporządzenia DORA, Rekomendacji D KNF i ISO 22301.
• U1 Opracowanie zaawansowanego programu dorocznych testów operacyjnych DRC (testy stolikowe, testy symulacyjne oraz pełny test przełączenia ruchu transakcyjnego w oknie serwisowym) z procedurą failback.
• U3 Przeprowadzenie analizy ryzyka przerwy w rozliczeniach międzybankowych, kar nadzorczych UKNF i utraty płynności finansowej banku w matrycy 3x3.
• U4 Opracowanie kompleksowego Planu Działań Korygujących (CAP) opartego na analizie przyczyn źródłowych 5 Why z mierzalnymi wskaźnikami KPI i terminami 14-90 dni.
• W1W2W3 Dogłębna znajomość art. 11 i 12 rozporządzenia DORA, Rekomendacji D KNF (obszar G: Ciągłość działania), normy PN-EN ISO 22301:2020 oraz Prawa bankowego.
• K1K2K3 Bezwzględna rzetelność audytorska, odporność na argumenty biznesowe usprawiedliwiające brak testów ryzykiem zakłócenia pracy oraz etyka zawodowa w sektorze zaufania publicznego.
• Powiązanie z wykładem: Wyk1 (Audyt w instytucjach finansowych), Wyk3 (Kontrole ciągłości działania i redundancji ISO 27001), Wyk4 (Zgodność z DORA i KNF), Wyk5 (Metodyka BIA i matryca ryzyka 3x3), Wyk6 (Analiza logów replikacji i sampling transakcji), Wyk7 (Procedura CAP i raportowanie do Komitetu Audytu).

Spółdzielcza Grupa Bankowa "Mazovia Bank" zrzesza centralę w Warszawie oraz 35 oddziałów operacyjnych, obsługując 120 000 klientów indywidualnych, przedsiębiorstw i jednostek samorządu terytorialnego. Bank przetwarza dziennie ponad 250 000 operacji księgowych, uczestniczy w trzech sesjach rozliczeniowych KIR ELIXIR, obsłudze płatności natychmiastowych Express ELIXIR oraz realizuje transfery dewizowe przez węzeł SWIFT.

Infrastruktura podstawowa, zapasowa i mechanizmy replikacji:

• Bank posiada Podstawowe Centrum Przetwarzania Danych (PDC) w Warszawie oraz wynajmuje Zapasowe Centrum Danych (DRC typu Warm-Site) w komercyjnym obiekcie kolokacyjnym w Radomiu (oddalonym o 105 km).
• W dokumencie BIA i Polityce Ciągłości Działania zatwierdzonej przez Zarząd zadeklarowano wskaźniki dla systemu bankowości centralnej (Oracle FlexCube): RTO = 2 godziny, RPO = 15 minut, a MTPD = 4 godziny. Dla modułu rozliczeń Express ELIXIR i BLIK zadeklarowano RTO = 30 minut, RPO = 0 minut (wymóg zerowej utraty transakcji).
• Audyt techniczny łączy telekomunikacyjnych i logów replikacji bazodanowej Oracle Data Guard pomiędzy Warszawą a Radomiem ujawnił kardynalne rozbieżności:
  • Replikacja realizowana jest w trybie asynchronicznym za pośrednictwem pojedynczego łącza dzierżawionego o przepustowości 150 Mbps, współdzielonego z wewnętrznym ruchem biurowym i pocztą.
  • W godzinach szczytu operacyjnego (10:30 - 15:30), gdy zbiegają się sesje rozliczeniowe KIR oraz intensywny ruch w bankowości internetowej, łącze ulega nasyceniu w 98%.
  • W rezultacie kolejka opóźnień replikacji (Data Guard Apply Lag) narasta w sposób ciągły, osiągając opóźnienie rzędu 2 godzin i 45 minut. Oznacza to, że w przypadku awarii PDC o godzinie 14:00, przełączenie na ośrodek zapasowy w Radomiu wiązałoby się z bezpowrotną utratą transakcji finansowych z blisko 3 godzin (RPO rzeczywiste = 165 minut zamiast deklarowanych 15 minut).
• Ponadto w ciągu ostatnich 2 lat do systemu centralnego dołączono obsługę bramki płatności mobilnych BLIK oraz zintegrowano węzeł SWIFT Alliance z nowymi modułami zapobiegania praniu pieniędzy (AML). Żadna z tych zmian nie została uwzględniona w konfiguracji serwerów aplikacyjnych w ośrodku DRC w Radomiu (brak zarządzania zmianą w DRP).
• Ostatni pełny test przełączenia systemów (failover test) do DRC odbył się 3 lata temu. Bank nie posiada opracowanej ani przetestowanej procedury powrotnego przełączenia (failback) z Radomia do Warszawy. Administratorzy przyznali, że "boją się wykonać test przełączenia, bo nie wiedzą, jak potem bezpiecznie zsynchronizować narosłe transakcje z powrotem do bazy głównej bez przestoju".

Zarząd Banku, stając w obliczu kontroli UKNF weryfikującej dostosowanie do rozporządzenia DORA, powołuje zespół audytorów do przeprowadzenia zaawansowanej inspekcji BIA, DRP i DRC na poziomie oceny 4.0.

Zadanie wymaga oceny spójności BIA z architekturą IT, analizy logów replikacji Data Guard, wyliczenia ryzyka w matrycy 3x3, formalnej klasyfikacji uchybień, analizy 5 Why oraz opracowania Planu CAP:

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

  Student 1 (Audytor Wiodący / Lead Auditor): Odpowiada za relacje z Zarządem Banku, Departamentem Ryzyka Operacyjnego i IOD, weryfikację dokumentacji BIA, spełnienie wymagań DORA i Rekomendacji D KNF, koordynację matrycy ryzyka oraz moderację referatu.

  Student 2 (Audytor Techniczny ds. Systemów DRC i Klastrów Bazodanowych): Bada konfigurację technologii Oracle Data Guard, logi opóźnień Apply Lag, przepustowość łączy WAN, konfigurację węzła SWIFT i modułu BLIK w DRC oraz opracowuje scenariusz techniczny procedury failover i failback.

  Student 3 (Audytor Zgodności Regulacyjnej KNF, Ryzyka i Jakości CAP): Dokonuje oceny ryzyka utraty płynności finansowej i naruszenia Prawa bankowego, klasyfikuje niezgodności (NC1/NC2/OFI), prowadzi dochodzenie 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP).

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zidentyfikowanych Luk DRP/DRC):

  Oceńcie ryzyka w matrycy 3x3 (P: 1-3, S: 1-3, R = P x S):

  1. Utrata transakcji finansowych z 3 godzin sesji KIR w wyniku rzeczywistego wskaźnika RPO=165 min przy awarii PDC (P=3, S=3 -> R=9).

  2. Paraliż rozliczeń banku w DRC z powodu niekompatybilności modułów BLIK i SWIFT (brak zarządzania zmianą w DRP) (P=3, S=3 -> R=9).

  3. Brak możliwości powrotu do ośrodka głównego (failback) skutkujący wielodniowym zatrzymaniem operacji po awarii DRC (P=2, S=3 -> R=6).

  4. Nałożenie dotkliwych kar finansowych przez UKNF za brak regularnych testów DRC wymaganych przez rozporządzenie DORA (P=3, S=2 -> R=6).

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

  Sformułujcie karty niezgodności z odniesieniem do DORA, Rekomendacji D KNF i ISO 22301:

  • NC1 (Niezgodność Duża): Krytyczne rozbieżności między wskaźnikami BIA a rzeczywistymi możliwościami technicznymi (lag replikacji sięgający 2h 45min przy wymaganym RPO=15min) oraz brak testów operacyjnych DRC od 3 lat (rażące naruszenie art. 11 i 12 rozporządzenia DORA, Rekomendacji 21 i 22 Rekomendacji D KNF oraz ISO 22301 p. 8.4).
  • NC1 (Niezgodność Duża): Brak spójności konfiguracyjnej środowiska DRC z produkcją PDC (brak modułów BLIK i SWIFT) oraz całkowity brak udokumentowanej i przetestowanej procedury powrotu (failback) do ośrodka głównego (naruszenie art. 12 ust. 2 DORA i kontroli ISO 27001 A.5.30).
  • NC2 (Niezgodność Mała): Współdzielenie łącza replikacyjnego z ruchem biurowym bez mechanizmu priorytetyzacji ruchu QoS gwarantującego pasmo dla bazy danych.
  • OFI (Szansa na doskonalenie): Brak wdrożenia architektury Active-Active dla systemów bankowości elektronicznej z automatycznym geodystrybuowanym równoważeniem obciążenia GSLB.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (brak przeprowadzania testów przełączania do DRC i opóźnienia replikacji) przeprowadźcie dochodzenie 5 Why:

  1. Dlaczego bank nie przeprowadza pełnych testów przełączania awaryjnego do DRC w Radomiu? Ponieważ Zarząd obawia się, że test w oknie nocnym wywoła niespójność danych i awarię rozliczeń w poniedziałek rano.

  2. Dlaczego istnieje ryzyko niespójności danych podczas testu? Ponieważ w banku nie ma opracowanej ani przetestowanej procedury powrotnego przełączenia (failback) synchronizującej zmiany z DRC do PDC.

  3. Dlaczego nie opracowano procedury failback i nie zmodernizowano replikacji? Ponieważ Dział IT traktował ośrodek zapasowy wyłącznie jako wymóg formalny do odhaczenia w ankiecie KNF, a nie jako realne środowisko produkcyjne.

  4. Dlaczego Dział IT traktował wymogi DRP czysto formalnie? Ponieważ w banku proces BIA i DRP nie był powiązany z odpowiedzialnością dyrektorów biznesowych, a Departament Ryzyka nie weryfikował technicznych dowodów replikacji.

  5. Dlaczego Departament Ryzyka nie weryfikował stanu technicznego DRP? (PRZYCZYNA ŹRÓDŁOWA): Brak wdrożenia zintegrowanych ram operacyjnej odporności cyfrowej wymaganych przez rozporządzenie DORA, co skutkowało brakiem niezależnego nadzoru nad parametrami technicznymi ICT i tolerowaniem fikcyjnych testów stolikowych przez kierownictwo banku.

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

  Skonstruujcie 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 Architektury Replikacji i Procedury Failover/Failback):

  Zaprojektujcie:

  • Wydzielenie dedykowanego, szyfrowanego łącza światłowodowego 1 Gbps wyłącznie dla Oracle Data Guard z konfiguracją QoS oraz wdrożenie trybu Maximum Availability (replikacja synchroniczna dla transakcji krytycznych, gwarantująca RPO = 0 dla sesji KIR i BLIK).
  • Zsynchronizowanie konfiguracji serwerów aplikacyjnych w DRC z systemami BLIK i SWIFT.
  • Sformalizowaną procedurę "Standardowa Procedura Operacyjna DRP-BANK-02: Przełączenie Awaryjne (Failover) oraz Powrót Operacyjny (Failback) Systemu Bankowości Centralnej".

Zaawansowana prezentacja seminaryjna (15 minut):

• Ramy regulacyjne DORA i Rekomendacji D KNF w bankowości (3 min): Waga odporności cyfrowej, harmonogram sesji rozliczeniowych KIR i odpowiedzialność Zarządu Banku (Student 1).
• Wyniki audytu technicznego: fikcja RPO, 3-godzinne opóźnienia i brak failbacku (4 min): Przedstawienie wykresów Data Guard Apply Lag, brak modułów BLIK w Radomiu, prezentacja matrycy ryzyka 3x3 (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz dochodzenie 5 Why (4 min): Uzasadnienie naruszeń art. 11 i 12 DORA oraz przedstawienie przyczyny źródłowej w nadzorze nad ryzykiem operacyjnym (Student 3).
• Plan Działań Korygujących (CAP) i procedura testów operacyjnych (4 min): Demonstracja działania łącza dedykowanego, konfiguracji Data Guard Maximum Availability, etapów procedury failback oraz bilansu kosztów (cały zespół).

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

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

• W jaki sposób rozporządzenie DORA (Digital Operational Resilience Act) redefiniuje podejście do testowania ciągłości działania ICT w bankach, przechodząc od deklaratywnych testów stolikowych do obowiązkowych testów operacyjnych w warunkach zbliżonych do rzeczywistych?
• Dlaczego brak przetestowanej procedury powrotu (failback) z ośrodka zapasowego DRC do ośrodka podstawowego PDC w praktyce uniemożliwia podjęcie bezpiecznej decyzji o przełączeniu awaryjnym w czasie kryzysu?
• Czym różni się replikacja synchroniczna od asynchronicznej w technologii Oracle Data Guard i jakie wymagania narzuca ona na parametry łączy telekomunikacyjnych (przepustowość, opóźnienia RTT, jitter) w celu uniknięcia degradacji wydajności systemu produkcyjnego?

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

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Utrata transakcji z 3 godzin sesji KIR w wyniku lagów replikacji -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Dedykowane łącze 1 Gbps + Data Guard Maximum Availability -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 2: Paraliż operacji w DRC z powodu braku modułów BLIK i SWIFT -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Wdrożenie zarządzania zmianą w DRC i synchronizacji konfiguracji IaC -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Brak możliwości wykonania procedury failback po awarii -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Opracowanie i przetestowanie procedury powrotu z mechanizmem Data Guard Flashback Database -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 4: Kary nadzorcze KNF i utrata zaufania rynku za brak testów DORA -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Zatwierdzenie 3-letniego programu testów operacyjnych DRC w oknach nocnych -> 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 Dochodzenia Przyczyn Źródłowych metodą 5 Why dla zaniechania testów DRC.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Uruchomienie dedykowanego łącza światłowodowego 1 Gbps z tunelem MACsec między PDC a DRC oraz wdrożenie QoS (Właściciel: Dyrektor Departamentu Infrastruktury IT, Termin: 45 dni, KPI: przepustowość 1 Gbps, zerowy lag replikacji w szczycie).
  • Zadanie CAP-2: Aktualizacja i instalacja modułów BLIK, SWIFT oraz AML w ośrodku DRC w Radomiu (Właściciel: Główny Architekt Systemów Bankowych, Termin: 30 dni, KPI: identyczność wersji oprogramowania na obu ośrodkach potwierdzona sumami kontrolnymi).
  • Zadanie CAP-3: Opracowanie i zatwierdzenie przez Zarząd Procedury Failover i Failback z mechanizmem Flashback Database (Właściciel: Kierownik Sekcji Ciągłości Działania, Termin: 21 dni, KPI: kompletna procedura operacyjna, zatwierdzenie przez Departament Ryzyka).
  • Zadanie CAP-4: Przeprowadzenie pełnego testu przełączenia ruchu transakcyjnego do DRC w nocnym oknie serwisowym (sobota 23:00 - niedziela 05:00) (Właściciel: Dyrektor Pionu IT i Członek Zarządu ds. Operacji, Termin: 60 dni, KPI: pomyślne przetworzenie próbnych transakcji w DRC i powrót do PDC w czasie poniżej 2 godzin).
• Projekt Procedury Operacyjnej: "Procedura Przełączania Awaryjnego i Powrotnego Ośrodków Przetwarzania Danych Banku (DRC Failover & Failback SOP)".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Pełna zgodność z rygorystycznymi wymogami rozporządzenia DORA i Rekomendacji D KNF; eliminacja utraty danych finansowych (RPO = 0 dla transakcji krytycznych); pełna kompatybilność usług BLIK i SWIFT w ośrodku zapasowym; ugruntowane bezpieczeństwo psychologiczne i operacyjne zespołu IT w czasie katastrofy.
• Wady i trudności: Wysoki koszt dzierżawy dedykowanego łącza światłowodowego 1 Gbps; konieczność zaangażowania kilkunastoosobowego zespołu bankowego i integratora w nocne testy weekendowe; ryzyko wystąpienia błędów synchronizacji podczas pierwszego testu wdrożeniowego.

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA): art. 11 (Plany i procedury ciągłości działania ICT), art. 12 (Procedury i plany przywracania danych i procedury DR), art. 13 (Uczenie się i doskonalenie).
• Komisja Nadzoru Finansowego (KNF): Wytyczne dotyczące zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach (Rekomendacja D) - Obszar G: Ciągłość działania, Warszawa.
• Norma PN-EN ISO 22301:2020: Bezpieczeństwo i odporność - Systemy zarządzania ciągłością działania - Wymagania.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - A.5.29, A.5.30, A.8.14.
• Krajowa Izba Rozliczeniowa (KIR): "Wymagania operacyjne i standardy ciągłości działania dla banków uczestników systemów ELIXIR i Express ELIXIR", Warszawa 2023.
• SWIFT Customer Security Programme (CSP): "SWIFT Customer Security Controls Framework (CSCF) v2023", SWIFT Standards 2023.

• U2 Student bezbłędnie klasyfikuje uchybienia w architekturze DRC i procedurach BIA do kategorii NC1/NC2/OFI w świetle regulacji finansowych.
• U1 Student projektuje zaawansowany program testów operacyjnych failover i failback do zapasowego centrum danych.
• U3 Student przeprowadza matrycową analizę ryzyka 3x3 dla zakłóceń płynności finansowej i rozliczeń międzybankowych.
• U4 Student realizuje procedurę 5 Why i konstruuje Plan Działań Korygujących (CAP) spełniający standardy nadzorcze KNF.
• W2W3 Student wykazuje dogłębną znajomość rozporządzenia DORA, Rekomendacji D KNF oraz normy ISO 22301.
• K1K2 Student wykazuje profesjonalizm, bezstronność oraz dbałość o zaufanie publiczne do stabilności sektora bankowego.

Celem zadania na ocenę 4.0 jest opanowanie przez studentów zaawansowanej metodyki audytu ciągłości działania (BCP) oraz systemów archiwizacji i wersjonowania oprogramowania w środowisku technologii operacyjnych (OT/ICS/SCADA) w przedsiębiorstwie użyteczności publicznej o statusie Operatora Usługi Kluczowej (OUK) w rozumieniu ustawy o KSC i dyrektywy NIS2. Zadanie wymaga przeanalizowania wielopoziomowej architektury automatyki przemysłowej zgodnie z modelem Purdue (stacje uzdatniania wody, pompownie, dyspozytornia SCADA), zidentyfikowania zagrożeń związanych z brakiem aktualnych kopii kodu sterowników PLC i projektów inżynierskich, przeprowadzenia matrycowej analizy ryzyka 3x3 dla ciągłości zaopatrzenia ludności w wodę, 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 centralnego repozytorium kodu OT z detekcją nieautoryzowanych zmian w sterownikach oraz ustrukturyzowanej procedury awaryjnego sterowania ręcznego (Manual Fallback).

Powiązanie z sylabusem i treściami programowymi:

• U2 Profesjonalna identyfikacja i formalna kwalifikacja uchybień w zarządzaniu oprogramowaniem sterowników PLC i planach BCP (NC1/NC2/OFI) z referencją do standardu IEC 62443, ISO 27001 i ustawy o KSC.
• U1 Opracowanie projektu centralnego systemu automatycznej archiwizacji i kontroli wersji oprogramowania OT w strefie DMZ przemysłowej oraz procedury awaryjnego sterowania manualnego.
• U3 Przeprowadzenie analizy ryzyka zatrzymania dostaw wody pitnej dla 200-tysięcznego miasta oraz skażenia sieci chemicznymi środkami uzdatniania w matrycy 3x3.
• U4 Opracowanie Planu Działań Korygujących (CAP) opartego na analizie 5 Why z mierzalnymi wskaźnikami KPI i terminami wdrożenia (14-90 dni).
• W1W2W3 Dogłębna znajomość Ustawy o Krajowym Systemie Cyberbezpieczeństwa (art. 8, 15), dyrektywy NIS2, standardu ISA/IEC 62443 (części 2-1 i 4-2) oraz normy PN-EN ISO/IEC 27001:2022 (A.8.13, A.5.29).
• K1K2K3 Świadomość krytyczności infrastruktury zaopatrzenia w wodę dla zdrowia i życia obywateli, postawa dociekliwa w konfrontacji ze środowiskiem przemysłowym oraz etyka zawodowa.
• Powiązanie z wykładem: Wyk1 (Audyt infrastruktury krytycznej), Wyk3 (Kontrole A.8.13 i A.5.29 w sieciach przemysłowych), Wyk4 (Zgodność z Ustawą o KSC i NIS2), Wyk5 (Matrycowa analiza ryzyka 3x3 w OT), Wyk6 (Zbieranie dowodów w automatyce przemysłowej), Wyk7 (Procedura CAP i 5 Why).

Miejskie Przedsiębiorstwo Wodociągów i Kanalizacji (MPWiK) w Kielcach zaopatruje w wodę 200 000 mieszkańców oraz odbiera i oczyszcza ścieki komunalne i przemysłowe. Infrastruktura technologiczna obejmuje 3 główne ujęcia głębinowe, stację uzdatniania wody, 45 przepompowni sieciowych oraz nowoczesną oczyszczalnię ścieków. MPWiK jest Operatorem Usługi Kluczowej wpisanym do rejestru OUK.

Stan infrastruktury automatyki przemysłowej i procesów ciągłości działania:

• Sterowanie procesami technologicznymi (dozowanie koagulantów, chlorowanie, praca pomp głębinowych, utrzymywanie ciśnienia w magistralach) realizowane jest przez 85 sterowników PLC (Siemens Simatic S7-1200/1500, Schneider Modicon M340, Allen Bradley ControlLogix) połączonych siecią telemetryczną z nadrzędnym systemem SCADA w Centralnej Dyspozytorni.
• W trakcie audytu ustalono, że jedyna oficjalna archiwizacja programów sterowników PLC oraz projektów wizualizacyjnych SCADA została przeprowadzona 5 lat temu przez integratora podczas odbioru instalacji.
• Przez 5 lat automatycy zakładowi wprowadzili ponad 120 modyfikacji w kodzie logicznym sterowników (zmieniono progi alarmowe, czasy płukania filtrów pośpiesznych, algorytmy sterowania falownikami), wgrywając programy bezpośrednio na obiektach z przenośnego laptopa serwisowego.
• Żadna z tych modyfikacji nie została zarchiwizowana centralnie. Wszystkie aktualne projekty inżynierskie (pliki TIA Portal, EcoStruxure) znajdują się wyłącznie na dysku twardym jednego wyeksploatowanego laptopa inżynierskiego, który nie posiada kopii zapasowej, nie jest zarządzany przez domenę i jest przechowywany w szafce warsztatowej.
• Brak jest weryfikacji sum kontrolnych (hash SHA-256) programów działających w pamięci sterowników PLC. W przypadku uszkodzenia sterownika na ujęciu wody lub ataku złośliwego oprogramowania typu wiper/ransomware na sieć OT, wgranie 5-letniej kopii doprowadzi do natychmiastowego uderzenia hydraulicznego i rozszczelnienia rurociągów lub podania do sieci wody ze zbyt wysokim stężeniem chloru.
• Co więcej, w planie BCP spółki brakuje sformalizowanej i przećwiczonej procedury awaryjnego sterowania ręcznego (Manual Fallback). Operatorzy dyspozytorni nie potrafią sterować ujęciami wody bez wsparcia wizualizacji SCADA, a technicy pogotowia wodociągowego nigdy nie brali udziału w ćwiczeniach ręcznego rozruchu pomp i nastawiania zasuw na szafach elektrycznych.

Prezes Zarządu MPWiK, w obliczu zbliżającego się obowiązkowego audytu cyberbezpieczeństwa OUK wynikającego z art. 15 Ustawy o KSC, powołuje zespół audytorów do przeprowadzenia zaawansowanego audytu obszaru OT na poziomie oceny 4.0.

Zadanie wymaga oceny architektury przemysłowej wg modelu Purdue, audytu spójności oprogramowania PLC, wyliczenia ryzyka w matrycy 3x3, kwalifikacji uchybień, analizy 5 Why oraz opracowania Planu CAP:

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

  Student 1 (Audytor Wiodący / Lead Auditor): Odpowiada za relacje z Zarządem, Głównym Dyspozytorem i Pełnomocnikiem ds. Cyberbezpieczeństwa OUK, weryfikację spełnienia wymagań Ustawy o KSC i NIS2, koordynację matrycy ryzyka oraz moderację referatu.

  Student 2 (Audytor Techniczny ds. Systemów Automatyki Przemysłowej i SCADA): Przeprowadza inspekcję laptopa inżynierskiego, środowisk programistycznych PLC, weryfikuje sumy kontrolne kodu w sterownikach, analizuje sieć telemetryczną pod kątem modelu Purdue oraz projektuje centralny system archiwizacji i kontroli wersji OT.

  Student 3 (Audytor Zgodności z Normami Przemysłowymi, Ryzyka i Jakości CAP): Analizuje standard ISA/IEC 62443, normę ISO 27001 (A.8.13, A.5.29), szacuje ryzyka skażeń chemicznych i przerw w dostawie wody w matrycy 3x3, prowadzi analizę 5 Why i konstruuje tabelę Planu Działań Korygujących (CAP).

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zagrożeń Ciągłości OT/SCADA):

  Oceńcie ryzyka w matrycy 3x3 (P: 1-3, S: 1-3, R = P x S):

  1. Brak możliwości odtworzenia sterowania pompownią z powodu utraty laptopa z jedyną wersją kodu PLC (P=3, S=3 -> R=9).

  2. Skażenie wody pitnej chlorem w wyniku wgrania nieaktualnego programu sprzed 5 lat po cyberataku (P=2, S=3 -> R=6).

  3. Paraliż dostaw wody dla miasta w wyniku awarii SCADA i braku umiejętności sterowania ręcznego przez operatorów (P=3, S=3 -> R=9).

  4. Kary finansowe nakładane przez Ministra z Ustawy o KSC za brak systemu zarządzania ciągłością działania OUK (P=3, S=2 -> R=6).

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

  Sformułujcie karty niezgodności z powołaniem na Ustawę o KSC, IEC 62443 i ISO 27001:

  • NC1 (Niezgodność Duża): Całkowity brak aktualnych kopii zapasowych oprogramowania sterowników PLC i projektów SCADA oraz przechowywanie jedynej wersji roboczej na niezarządzanym laptopie serwisowym bez kopii zapasowej, uniemożliwiające odtworzenie instalacji uzdatniania wody po awarii (rażące naruszenie art. 8 pkt 1 i 2 Ustawy o KSC, standardu IEC 62443-4-2 oraz kontroli ISO/IEC 27001:2022 A.8.13).
  • NC1 (Niezgodność Duża): Brak udokumentowanej i przećwiczonej procedury awaryjnego sterowania ręcznego (Manual Fallback) dla ujęć wody i pompowni w warunkach paraliżu nadrzędnego systemu SCADA (naruszenie art. 8 pkt 4 Ustawy o KSC, ISO 22301 p. 8.4 oraz ISO 27001 A.5.29).
  • NC2 (Niezgodność Mała): Brak automatycznego systemu wykrywania nieautoryzowanych modyfikacji kodu w sterownikach PLC (brak porównywania sum kontrolnych firmware i logiki sterowania).
  • OFI (Szansa na doskonalenie): Brak wdrożenia bezpiecznych przenośnych nośników inżynierskich z kryptograficzną autoryzacją dostępu na poziomie szaf sterowniczych.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (brak centralnego repozytorium kopii PLC i trzymanie kodu na jednym laptopie) przeprowadźcie dochodzenie 5 Why:

  1. Dlaczego aktualne kody sterowników PLC znajdują się wyłącznie na jednym laptopie inżynierskim? Ponieważ automatycy zgrywają projekty lokalnie na dysk laptopa podczas wizyt na obiektach technologicznych.

  2. Dlaczego automatycy nie synchronizują projektów z serwerem centralnym? Ponieważ w przedsiębiorstwie nie zainstalowano żadnego centralnego serwera kontroli wersji i archiwizacji dla sieci automatyki przemysłowej.

  3. Dlaczego nie zainstalowano centralnego repozytorium dla automatyki? Ponieważ Dział IT i Dział Automatyki działają jako całkowicie odrębne silosy organizacyjne; IT zarządzało serwerami biurowymi, a automatycy traktowali swoje sterowniki jako urządzenia czysto mechaniczno-elektryczne.

  4. Dlaczego nie nastąpiła integracja procesów IT i OT w zakresie cyberbezpieczeństwa? Ponieważ kierownictwo spółki nie wdrożyło jednolitych zasad zarządzania bezpieczeństwem informacji obejmujących technologię operacyjną (OT), ograniczając cyberbezpieczeństwo wyłącznie do sieci biurowej.

  5. Dlaczego kierownictwo nie objęło sieci OT jednolitym nadzorem cyberbezpieczeństwa? (PRZYCZYNA ŹRÓDŁOWA): Brak w MPWiK zintegrowanej struktury zarządzania bezpieczeństwem informacji i ciągłością działania (ISMS/BCMS) łączącej kompetencje IT i OT, co skutkowało całkowitym ignorowaniem specyfiki cyberzagrożeń w automatyce przemysłowej i traktowaniem sterowników PLC poza systemem zarządzania ryzykiem.

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

  Skonstruujcie 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 Architektury Repozytorium OT i Procedury Manual Fallback):

  Zaprojektujcie:

  • Centralny serwer archiwizacji i wersjonowania oprogramowania przemysłowego (np. klasy Octoplant / Versiondog) w Poziomie 3 modelu Purdue (strefa DMZ przemysłowa) z automatycznym cotygodniowym cyklem sprawdzania zgodności kodu w 85 sterownikach PLC (funkcja disaster recovery upload & compare).
  • Sformalizowaną procedurę operacyjną "Manual Fallback SOP: Instrukcja Awaryjnego Ręcznego Sterowania Tłoczeniem Wody i Dozowaniem Środków Chemicznych na Obiektach MPWiK".

Zaawansowane wystąpienie seminaryjne (15 minut):

• Rola MPWiK jako Operatora Usługi Kluczowej w świetle KSC i NIS2 (3 min): Znaczenie ciągłości dostaw wody dla aglomeracji, model Purdue i rygory prawne nałożone na infrastrukturę krytyczną (Student 1).
• Diagnoza technologiczna: "jeden laptop i 85 sterowników bez kopii" (4 min): Przedstawienie dowodów ze stacji inżynierskich, analiza 5-letnich braków archiwizacji, brak kontroli wersji i prezentacja matrycy ryzyka 3x3 (Student 2).
• Kwalifikacja uchybień (karty NC1/NC2/OFI) oraz dochodzenie 5 Why (4 min): Uzasadnienie naruszeń art. 8 Ustawy o KSC, standardu IEC 62443 i prezentacja przyczyny źródłowej w podziale silosowym IT/OT (Student 3).
• Plan Działań Korygujących (CAP) i procedura Manual Fallback (4 min): Demonstracja platformy archiwizacji OT Octoplant, kart sterowania ręcznego przy szafach elektrycznych oraz bilansu korzyści (cały zespół).

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

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

• Dlaczego standardowe narzędzia backupowe stosowane w korporacyjnym IT (np. agenci backupu na systemach operacyjnych, snapshoty dysków) są całkowicie nieprzydatne w środowisku programowalnych sterowników logicznych (PLC) i systemów RTU?
• W jaki sposób model Purdue (strefowa segmentacja sieci przemysłowej) definiuje bezpieczne umiejscowienie stacji inżynierskich oraz serwerów archiwizacji kodu automatyki, aby zapobiec przenikaniu infekcji malware z sieci biurowej do sterowników?
• Na czym polega i jakie elementy musi zawierać procedura "Manual Fallback" (sterowanie ręczne) w przedsiębiorstwie wodociągowym, aby zagwarantować bezpieczeństwo biologiczne i chemiczne wody przy całkowitej awarii sieci telemetrii SCADA?

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

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Brak możliwości odtworzenia kodu sterownika PLC po awarii sprzętowej -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Centralny serwer archiwizacji OT Octoplant z automatycznym backupem -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 2: Skażenie wody w wyniku wgrania nieaktualnej wersji programu sprzed 5 lat -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Ścisła kontrola wersji z podpisem cyfrowym i weryfikacją sum kontrolnych SHA-256 -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Paraliż dyspozytorni przy awarii telemetrii i brak procedury manualnej -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Laminowane karty Manual Fallback na obiektach i kwartalne ćwiczenia operatorów -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 4: Kary administracyjne nakładane przez CSIRT/Ministra z Ustawy o KSC -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Formalizacja systemu BCP zgodnego z KSC i przeprowadzenie audytu certyfikującego -> 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 Dochodzenia Przyczyn Źródłowych metodą 5 Why dla braku centralnego backupu PLC.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Wdrożenie przemysłowego serwera kontroli wersji i archiwizacji Octoplant w strefie DMZ przemysłowej dla 85 sterowników PLC (Właściciel: Główny Automatyk i Kierownik IT, Termin: 60 dni, KPI: 100% sterowników objętych automatycznym backupem, zero różnic między kodem w sterowniku a repozytorium).
  • Zadanie CAP-2: Wykonanie pełnego odczytu i inwentaryzacji bieżącego oprogramowania ze wszystkich 85 sterowników na obiektach (Właściciel: Zespół Automatyków, Termin: 30 dni, KPI: kompletna baza projektów inżynierskich ze zweryfikowanymi sumami SHA-256).
  • Zadanie CAP-3: Opracowanie, zalaminowanie i umieszczenie w 45 szafach sterowniczych Kart Procedury Sterowania Ręcznego (Manual Fallback) (Właściciel: Główny Dyspozytor, Termin: 21 dni, KPI: 100% szaf wyposażonych w karty, instrukcja nastaw awaryjnych).
  • Zadanie CAP-4: Przeprowadzenie praktycznych ćwiczeń zgrywających z ręcznego załączania pomp i dawkowania koagulantów w warunkach symulowanego odcięcia SCADA (Właściciel: Dyrektor Techniczny, Termin: 45 dni, KPI: 100% dyspozytorów i monterów przeszkolonych, raport z ćwiczeń).
• Projekt Procedury Operacyjnej: "Standardowa Procedura Operacyjna SOP-OT-01: Zarządzanie Zmianą i Archiwizacją Oprogramowania Sterowników PLC oraz Procedura Awaryjnego Sterowania Ręcznego Ujęciami Wody".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Pełna kontrola nad kodem i konfiguracją 85 sterowników PLC w aglomeracji; automatyczne wykrywanie nieautoryzowanych modyfikacji w sterownikach; skrócenie czasu wymiany uszkodzonego sterownika z 4 dni do 45 minut; gwarancja ciągłości zaopatrzenia miasta w wodę nawet przy całkowitym paraliżu systemów teleinformatycznych; pełna zgodność z KSC, NIS2 i IEC 62443.
• Wady i trudności: Wysoki koszt zakupu licencji dedykowanego oprogramowania do archiwizacji automatyki przemysłowej; konieczność przełamania barier mentalnych i silosów kompetencyjnych między zespołem automatyków a zespołem IT.

• Ustawa z dnia 5 lipca 2018 r. o Krajowym Systemie Cyberbezpieczeństwa (Dz.U. z 2024 r. poz. 1077) - art. 8 (obowiązki operatora usługi kluczowej) oraz art. 15 (audyt bezpieczeństwa).
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - sektor ścieków i wody pitnej.
• Standard ISA/IEC 62443: Security for industrial automation and control systems - Część 2-1 (Security program requirements for IACS asset owners) oraz Część 4-2 (Technical security requirements for IACS components).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - A.8.13 (Tworzenie kopii zapasowych informacji), A.5.29 (Gotowość bezpieczeństwa informacji w czasie zakłóceń), A.5.30 (Gotowość ICT do ciągłości działania).
• Zespół CERT Polska / CSIRT NASK: "Dobre praktyki i wytyczne cyberbezpieczeństwa w systemach sterowania przemysłowego i automatyki wodociągowej", Warszawa 2023.

• U2 Student bezbłędnie klasyfikuje uchybienia w architekturze backupu automatyki przemysłowej do kategorii NC1/NC2/OFI w oparciu o Ustawę o KSC i standard IEC 62443.
• U1 Student projektuje schemat centralnego systemu archiwizacji i wersjonowania kodu OT oraz procedurę Manual Fallback dla obiektów technologicznych.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla zagrożeń ciągłości zaopatrzenia w wodę i skażeń chemicznych.
• U4 Student realizuje procedurę 5 Why i konstruuje Plan Działań Korygujących (CAP) integrujący działy IT i OT.
• W2W3 Student zna Ustawę o KSC, dyrektywę NIS2, model Purdue oraz standard ISA/IEC 62443 w odniesieniu do infrastruktury krytycznej.
• K1K2 Student przejawia postawę odpowiedzialności za bezpieczeństwo publiczne oraz zdolność przełamywania barier organizacyjnych między inżynierią automatyki a IT.

Głównym celem zadania na ocenę 4.0 jest opanowanie przez studentów zaawansowanej metodyki audytu strategii tworzenia i ochrony kopii zapasowych w architekturze chmury publicznej (Cloud Native IaaS/PaaS na przykładzie Amazon Web Services - AWS) w przedsiębiorstwie e-commerce przetwarzającym miliony transakcji płatniczych i podlegającym standardowi PCI DSS v4.0 oraz RODO. Zadanie koncentruje się na zbadaniu podatności na zagrożenia wewnętrzne (Rogue Admin / skompromitowane poświadczenia root), wdrożeniu dedykowanego, odizolowanego konta kopii zapasowych (Isolated Backup Account) w ramach AWS Organizations z blokadami Service Control Policies (SCP), audycie mechanizmów niezmienności danych (AWS Backup Vault Lock w rygorystycznym trybie Compliance Mode), weryfikacji procedur Disaster Recovery opartych na Infrastructure as Code (Terraform), przeprowadzeniu matrycowej analizy ryzyka 3x3, kwalifikacji uchybień (NC1/NC2/OFI), analizie 5 Why oraz opracowaniu Planu CAP.

Powiązanie z sylabusem i treściami programowymi:

• U2 Profesjonalna identyfikacja i formalna kwalifikacja uchybień w architekturze chmurowej (NC1/NC2/OFI) z odniesieniem do standardu PCI DSS v4.0, ISO 27001 i wytycznych CIS AWS Benchmark.
• U1 Opracowanie zaawansowanego projektu odseparowanego konta kopii zapasowych (Cross-Account & Cross-Region Backup) z blokadą SCP oraz szablonami Terraform do automatycznego odtworzenia środowiska.
• U3 Przeprowadzenie analizy ryzyka całkowitej destrukcji infrastruktury e-commerce przez złośliwego administratora lub ransomware w matrycy 3x3 w ujęciu ryzyka inherentnego i rezydualnego.
• U4 Opracowanie Planu Działań Korygujących (CAP) opartego na analizie przyczyn źródłowych 5 Why z mierzalnymi wskaźnikami KPI i terminami wdrożenia (14-90 dni).
• W1W2W3 Dogłębna znajomość normy PN-EN ISO/IEC 27001:2022 (kontrole A.8.13, A.8.14, A.8.2, A.8.5), standardu PCI DSS v4.0 (wymóg 10 i 12), CIS AWS Foundations Benchmark oraz art. 32 RODO.
• K1K2K3 Obiektywizm audytorski w konfrontacji z zespołem inżynierów DevOps, dociekliwość przy analizie polityk JSON/IAM oraz etyka zawodowa.
• Powiązanie z wykładem: Wyk1 (Audyt środowisk nowoczesnych technologii chmurowych), Wyk3 (Kontrole A.8.13 i A.8.2 w chmurze), Wyk4 (Zgodność z RODO i standardami płatniczymi PCI DSS), Wyk5 (Matrycowa analiza ryzyka 3x3 w architekturze cloud), Wyk6 (Analiza logów AWS CloudTrail), Wyk7 (Procedura CAP i 5 Why).

MebleSklep S.A. jest wiodącą polską platformą handlu elektronicznego branży wnętrzarskiej, osiągającą roczny obrót na poziomie 180 milionów PLN i obsługującą w okresach kampanii promocyjnych (Black Friday) do 40 000 zamówień na dobę. W bazie danych zarejestrowanych jest 1,8 miliona klientów. Platforma przetwarza płatności kartowe, leasingi online oraz płatności odroczone, podlegając corocznej atestacji PCI DSS na poziomie Merchant Level 2.

Architektura chmurowa AWS i stan faktyczny zarządzania kopiami:

• Całość platformy e-commerce działa w regionie AWS eu-central-1 (Frankfurt). Główne komponenty to: klastry kontenerowe Amazon EKS (Kubernetes), bazy transakcyjne PostgreSQL w usłudze Amazon Aurora Serverless (Multi-AZ) oraz ponad 25 TB plików produktowych i faktur w zasobnikach Amazon S3.
• W trakcie audytu bezpieczeństwa chmury ujawniono krytyczną wadę architektoniczną: CAŁOŚĆ środowiska produkcyjnego, developerskiego oraz magazyny kopii zapasowych (Backup Vaults) znajdują się wewnątrz JEDNEGO konta chmurowego AWS (Single AWS Account).
• Czterech inżynierów DevOps posiada stałe uprawnienia AdministratorAccess w politykach IAM, co pozwala każdemu z nich na wywołanie poleceń: aws rds delete-db-instance, aws s3 rb --force oraz aws backup delete-recovery-point.
• Funkcja AWS Backup Vault Lock (mechanizm uniemożliwiający usunięcie kopii przed upływem retencji) NIE została włączona. Zespół DevOps uzasadnił to chęcią "zachowania elastyczności kosztowej i możliwości ręcznego czyszczenia niepotrzebnych migawek".
• Ponadto zasobniki Amazon S3 z fakturami nie posiadają aktywnej funkcji S3 Object Lock ani wersjonowania (Versioning).
• Zdarzenia logów CloudTrail wykazały, że konto główne root właściciela spółki nie posiadało klucza sprzętowego U2F/FIDO2, a jego hasło i klucze API były zapisane w menedżerze haseł współdzielonym w dziale IT.
• Oznacza to, że w przypadku kompromitacji pojedynczego laptopa inżyniera DevOps, ataku ukierunkowanego z użyciem infostealera lub wrogiego działania zwolnionego pracownika, atakujący może w czasie poniżej 60 sekund usunąć wszystkie bazy produkcyjne, wszystkie migawki Aurora i wyczyścić magazyny AWS Backup, trwale unicestwiając całą działalność gospodarczą spółki bez możliwości ratunku.
• Spółka posiada kod infrastruktury w Terraform, lecz nigdy nie przetestowała odtworzenia całego sklepu w innym regionie geograficznym AWS (np. eu-west-1 Irlandia) w scenariuszu całkowitej niedostępności regionu frankfurckiego.

Komitet Audytu i Zarząd MebleSklep S.A., po analizie raportu ryzyk ubezpieczeniowych cyber-insurance, zleca zespołowi audytorów zaawansowany audyt architektury kopii chmurowych na poziomie oceny 4.0.

Zadanie wymaga przeprowadzenia audytu architektury chmurowej, uprawnień IAM/SCP, wyliczenia ryzyka w matrycy 3x3, kwalifikacji uchybień, analizy 5 Why oraz opracowania Planu CAP:

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

  Student 1 (Audytor Wiodący / Lead Auditor): Odpowiada za relacje z Zarządem, CTO i audytorem PCI DSS (QSA), weryfikację kosztów przestoju e-commerce (utrata 150 tys. PLN/h w szczycie), koordynację matrycy ryzyka oraz moderację referatu.

  Student 2 (Audytor Techniczny ds. Bezpieczeństwa Chmury AWS i DevOps): Bada konfigurację konta AWS, uprawnienia IAM, role assumowalne, logi CloudTrail, analizuje konfigurację AWS Backup, S3 Bucket Policies, parametry KMS oraz projektuje architekturę Isolated Backup Account i skrypty Terraform DR.

  Student 3 (Audytor Zgodności z PCI DSS, CIS Benchmark i Jakości CAP): Analizuje wymogi PCI DSS v4.0, CIS AWS Foundations Benchmark, normę ISO 27001 (A.8.13, A.8.2), klasyfikuje niezgodności (NC1/NC2/OFI), prowadzi procedurę 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP).

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Środowiska Chmurowego):

  Oceńcie ryzyka w matrycy 3x3 (P: 1-3, S: 1-3, R = P x S):

  1. Całkowite i nieodwracalne skasowanie baz i kopii przez złośliwego administratora lub ransomware w pojedynczym koncie AWS (P=3, S=3 -> R=9).

  2. Usunięcie lub modyfikacja faktur w Amazon S3 z powodu braku S3 Object Lock w sporze podatkowym (P=2, S=3 -> R=6).

  3. Przejęcie konta root z powodu braku sprzętowego klucza FIDO2 i kradzieży poświadczeń API (P=2, S=3 -> R=6).

  4. Wielodniowy przestój platformy handlowej w przypadku regionalnej awarii data center AWS Frankfurt z powodu braku przetestowanego DR w regionie Irlandia (P=2, S=3 -> R=6).

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

  Sformułujcie karty niezgodności z odniesieniem do ISO 27001, PCI DSS i CIS Benchmark:

  • NC1 (Niezgodność Duża): Przechowywanie kopii zapasowych w tym samym pojedynczym koncie AWS wraz z zasobami produkcyjnymi oraz brak blokady AWS Backup Vault Lock w trybie Compliance Mode, stwarzające bezpośrednie ryzyko zniszczenia wszystkich aktywów cyfrowych spółki przez pojedynczy skompromitowany klucz administratorski (naruszenie kontroli ISO/IEC 27001:2022 A.8.13, A.8.2, standardu PCI DSS v4.0 wymóg 10.5 oraz art. 32 RODO).
  • NC1 (Niezgodność Duża): Brak wymuszenia sprzętowego uwierzytelniania wieloskładnikowego (klucz FIDO2) dla konta root oraz brak blokad Service Control Policies (SCP) uniemożliwiających kasowanie magazynów backupu (naruszenie zaleceń CIS AWS Foundations Benchmark p. 1.1 oraz ISO 27001 A.8.5).
  • NC2 (Niezgodność Mała): Wyłączenie wersjonowania i blokady S3 Object Lock na zasobnikach z dokumentacją transakcyjną i fakturami klientów.
  • OFI (Szansa na doskonalenie): Brak wdrożenia automatycznych testów odtwarzania całego środowiska z wykorzystaniem narzędzia Terraform w potoku CI/CD raz w miesiącu.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (przechowywanie kopii w pojedynczym koncie AWS bez Vault Lock) przeprowadźcie dochodzenie 5 Why:

  1. Dlaczego magazyn kopii zapasowych znajduje się w tym samym koncie AWS i nie posiada blokady kasowania? Ponieważ zespół DevOps utworzył go z poziomu tej samej konsoli produkcyjnej za pomocą domyślnych kreatorów AWS Backup.

  2. Dlaczego DevOps nie wdrożył osobnego konta chmurowego pod backup? Ponieważ inżynierowie chcieli uniknąć dodatkowej pracy związanej z konfigurowaniem uprawnień Cross-Account i trasowania sieciowego.

  3. Dlaczego inżynierowie DevOps samodzielnie decydowali o architekturze kont i ignorowali zasady separacji? Ponieważ w firmie obowiązywała kultura "szybkiego wdrażania funkcji biznesowych" (Speed to Market), a zespół IT nie podlegał nadzorowi architekta bezpieczeństwa chmury.

  4. Dlaczego w spółce nie zatrudniono Cloud Security Engineera ani nie zdefiniowano standardów Landing Zone? Ponieważ Zarząd traktował chmurę AWS jako środowisko "domyślnie bezpieczne", nie rozumiejąc Modelu Współdzielonej Odpowiedzialności (Shared Responsibility Model).

  5. Dlaczego Zarząd nie rozumiał zasad współdzielonej odpowiedzialności w chmurze? (PRZYCZYNA ŹRÓDŁOWA): Brak wdrożenia w spółce formalnego systemu ISMS dla środowisk chmurowych oraz brak audytów architektonicznych Well-Architected Framework, co skutkowało błędnym założeniem, że dostawca chmury (Amazon) zabezpiecza dane przed skasowaniem przez uprawnionego użytkownika.

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

  Skonstruujcie 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 Architektury Isolated Backup Account i Procedury IaC):

  Zaprojektujcie:

  • Architekturę AWS Organizations z wydzielonym kontem: "MebleSklep-Isolated-Backup-Account".
  • Politykę kontroli usług (SCP) uniemożliwiającą operacje kasowania (Deny backup:DeleteRecoveryPoint) dla wszystkich użytkowników bez wyjątku.
  • Aktywację AWS Backup Vault Lock w trybie Compliance Mode z minimalną retencją 14 dni i okresem ochronnym 3 dni.
  • Zautomatyzowany potok Terraform podnoszący środowisko ze zreplikowanych migawek w regionie eu-west-1 (Irlandia) w czasie poniżej 45 minut.

Zaawansowane wystąpienie seminaryjne (15 minut):

• Model biznesowy e-commerce i mit "bezpiecznej chmury" (3 min): Obroty MebleSklep.pl, koszty minuty przestoju, Model Współdzielonej Odpowiedzialności i wymogi PCI DSS (Student 1).
• Diagnoza techniczna: pułapka Single Account i zagrożenie Rogue Admin (4 min): Przedstawienie uprawnień AdministratorAccess dla 4 inżynierów, brak Vault Lock, analiza logów CloudTrail i matryca ryzyka 3x3 (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Uzasadnienie naruszeń normy ISO 27001, CIS Benchmark oraz przedstawienie przyczyny źródłowej w braku nadzoru nad architekturą Landing Zone (Student 3).
• Plan Działań Korygujących (CAP) i architektura Isolated Account (4 min): Demonstracja działania polityki SCP, blokady Vault Lock Compliance, potoku Terraform DR do Irlandii oraz bilansu kosztów (cały zespół).

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

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

• Czym charakteryzuje się wektor ataku typu "Rogue Admin" (złośliwy lub skompromitowany administrator) w chmurze publicznej i dlaczego tradycyjne zabezpieczenia oparte na rolach IAM wewnątrz jednego konta są całkowicie nieskuteczne bez mechanizmu Service Control Policies (SCP) na poziomie organizacji?
• Jakie są techniczne i prawne różnice między trybem Governance Mode a trybem Compliance Mode w technologii AWS Backup Vault Lock oraz dlaczego po upływie okresu ochronnego (Grace Period) nawet pomoc techniczna firmy Amazon nie ma możliwości usunięcia zablokowanych danych?
• W jaki sposób podejście Infrastructure as Code (IaC) oparte na skryptach Terraform / OpenTofu pozwala zrealizować strategię Disaster Recovery Multi-Region i jakie wyzwania niesie replikacja danych bazodanowych między regionami chmury?

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

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Całkowite zniszczenie baz produkcyjnych i backupów przez Rogue Admin w pojedynczym koncie -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Utworzenie Isolated Backup Account z blokadą SCP Deny Delete -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 2: Skasowanie faktur w S3 z powodu braku immutability -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Wdrożenie S3 Object Lock w trybie Compliance Mode z retencją 5 lat -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Przejęcie konta root z powodu braku klucza FIDO2 -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Sprzętowy klucz YubiKey FIDO2 zdeponowany w sejfie Zarządu, usunięcie kluczy API root -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 4: Wielodniowy paraliż przy awarii regionu Frankfurt -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Skrypty Terraform DR podnoszące klaster w Irlandii w 45 minut -> 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 Dochodzenia Przyczyn Źródłowych metodą 5 Why dla braku separacji kont chmurowych.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Wdrożenie dedykowanego konta "MebleSklep-Backup-Account" w strukturze AWS Organizations z automatyczną replikacją Cross-Account i Cross-Region (Właściciel: Główny Inżynier Chmury, Termin: 30 dni, KPI: 100% migawek replikowanych do odizolowanego konta, zerowa dostępność konta dla ról developerskich).
  • Zadanie CAP-2: Wdrożenie i zablokowanie polityki Service Control Policy (SCP) bezwzględnie odrzucającej akcje kasowania backupu w odizolowanym koncie (Właściciel: CISO / Administrator Organizacji, Termin: 14 dni, KPI: aktywna reguła SCP Deny backup:Delete*, test odmowy dostępu z poziomu konta administratora).
  • Zadanie CAP-3: Aktywacja AWS Backup Vault Lock w trybie Compliance Mode z retencją minimalną 14 dni na produkcyjnych bazach danych (Właściciel: Lead DevOps, Termin: 14 dni, KPI: zablokowany skarbiec backupowy w konsoli AWS Backup, status Compliance).
  • Zadanie CAP-4: Przeprowadzenie pełnego testu Disaster Recovery z odtworzeniem sklepu w regionie Irlandia (eu-west-1) za pomocą Terraform (Właściciel: Dyrektor Technologii - CTO, Termin: 60 dni, KPI: czas uruchomienia platformy poniżej 45 minut, pomyślne wykonanie 10 zamówień testowych).
• Projekt Procedury Operacyjnej: "Procedura Bezpieczeństwa Chmurowego CLOUD-DRP-01: Zarządzanie Niezmiennymi Kopiami Zapasowymi w AWS, Separacja Kont i Awaryjne Odtwarzanie Infrastruktury IaC".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Odporność na najbardziej destrukcyjne ataki ransomware ukierunkowane na chmurę oraz sabotaż wewnętrzny administratorów; kryptograficzna gwarancja nienaruszalności kopii (WORM); automatyzacja procesu odzyskiwania dzięki Terraform; pełna zgodność z PCI DSS v4.0 i standardami CIS.
• Wady i trudności: Sztywny koszt magazynowania danych w trybie Compliance Mode bez możliwości zwolnienia miejsca przed upływem terminu retencji; konieczność zarządzania architekturą wielu kont chmurowych (Multi-Account Strategy); konieczność utrzymywania aktualności szablonów Terraform wraz z rozwojem aplikacji e-commerce.

• PCI Security Standards Council: "Payment Card Industry Data Security Standard (PCI DSS) Requirements and Testing Procedures v4.0", Wymóg 10 (Rejestrowanie i monitorowanie) oraz Wymóg 12 (Wspieranie bezpieczeństwa informacji), 2022.
• Center for Internet Security (CIS): "CIS Amazon Web Services Foundations Benchmark v2.0.0", CIS Security 2023.
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - A.8.13 (Tworzenie kopii zapasowych informacji), A.8.14 (Redundancja), A.8.2 (Prawa dostępu uprzywilejowanego), A.8.5 (Bezpieczne uwierzytelnianie).
• Amazon Web Services: "AWS Well-Architected Framework - Reliability Pillar: Backup and Recovery Strategy", AWS Documentation 2023.
• Cloud Security Alliance (CSA): "Security Guidance for Critical Areas of Focus in Cloud Computing v4.0", CSA 2021.

• U2 Student bezbłędnie klasyfikuje uchybienia w architekturze chmury publicznej do kategorii NC1/NC2/OFI w oparciu o normę ISO 27001, PCI DSS i CIS Benchmark.
• U1 Student projektuje zaawansowany schemat odseparowanego konta backupowego z blokadami SCP oraz procedurę odtworzenia IaC.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla zagrożeń typu Rogue Admin i destrukcji zasobów cloud.
• U4 Student realizuje procedurę 5 Why i konstruuje Plan Działań Korygujących (CAP) spełniający standardy PCI DSS.
• W2W3 Student zna standard PCI DSS v4.0, CIS AWS Benchmark oraz normę ISO 27001 w odniesieniu do środowisk chmurowych.
• K1K2 Student wykazuje asertywność zawodową w konfrontacji z zespołem inżynierów DevOps oraz dbałość o rygory bezpieczeństwa biznesu e-commerce.

Głównym celem zadania na ocenę 4.0 jest wykształcenie u studentów zaawansowanych umiejętności audytu kryptograficznej ochrony kopii zapasowych danych szczególnych kategorii (dane genetyczne, profile DNA i historia leczenia onkologicznego pacjentów wg art. 9 RODO) oraz weryfikacji pełnego cyklu życia nośników wymiennych (taśmy magnetyczne LTO). Zadanie wymaga zbadania konfiguracji szyfrowania sprzętowego napędów taśmowych (AES-256), scentralizowanego zarządzania kluczami w oparciu o standard KMIP (Key Management Interoperability Protocol) z wykorzystaniem modułów HSM, audytu łańcucha logistycznego transportu kopii, weryfikacji procedur bezpiecznej demagnetyzacji (degaussingu) i mechanicznego niszczenia zużytych nośników zgodnie z normą DIN 66399 (klasa bezpieczeństwa T-5 / H-5), przeprowadzenia matrycowej analizy ryzyka 3x3, formalnej kwalifikacji uchybień (NC1/NC2/OFI), analizy przyczyn źródłowych 5 Why oraz opracowania Planu Działań Korygujących (CAP).

Powiązanie z sylabusem i treściami programowymi:

• U2 Profesjonalna identyfikacja i formalna kwalifikacja uchybień w procesach kryptograficznych i niszczenia nośników (NC1/NC2/OFI) z referencją do art. 9 i 32 RODO, normy ISO 27001 (A.7.10, A.7.14, A.8.24) oraz normy DIN 66399.
• U1 Opracowanie zaawansowanego projektu infrastruktury zarządzania kluczami szyfrującymi taśm z procedurą Key Escrow oraz certyfikowanej procedury demagnetyzacji i zniszczenia nośników.
• U3 Przeprowadzenie analizy ryzyka masowego wycieku danych genetycznych, kar nakładanych przez Prezesa UODO (do 20 mln EUR) oraz odpowiedzialności odszkodowawczej w matrycy 3x3 w ujęciu inherentnym i rezydualnym.
• U4 Opracowanie Planu Działań Korygujących (CAP) opartego na analizie przyczyn źródłowych 5 Why z mierzalnymi wskaźnikami KPI i terminami wdrożenia (14-90 dni).
• W1W2W3 Dogłębna znajomość normy PN-EN ISO/IEC 27001:2022 (kontrole A.7.10, A.7.14, A.8.13, A.8.24), standardu DIN 66399, specyfikacji OASIS KMIP oraz rygorów art. 9 RODO i Ustawy o prawach pacjenta.
• K1K2K3 Bezwzględna etyka zawodowa w ochronie tajemnicy lekarskiej i prywatności pacjentów, dociekliwość przy weryfikacji dowodów niszczenia sprzętu oraz niezależność audytorska.
• Powiązanie z wykładem: Wyk1 (Audyt ochrony tajemnic prawnie chronionych), Wyk3 (Kontrole A.7 i A.8 ISO 27001), Wyk4 (Zgodność z RODO w medycynie), Wyk5 (Matrycowa analiza ryzyka 3x3), Wyk6 (Metodyka inspekcji fizycznej i weryfikacji łańcucha dostaw), Wyk7 (Procedura CAP i 5 Why).

Diagno-Med Sp. z o.o. zarządza ogólnopolską siecią 40 laboratoriów medycznych oraz 250 punktów pobrań, wykonując rocznie ponad 5 milionów badań diagnostycznych, w tym specjalistyczne analizy genetyczne predyspozycji do chorób nowotworowych oraz sekwencjonowanie DNA. W centralnym systemie LIS przechowywana jest dokumentacja medyczna ponad 3 milionów pacjentów.

Stan faktyczny w obszarze tworzenia kopii zapasowych, kryptografii i nośników:

• Centralna baza danych LIS oraz repozytorium wyników badań backupowane są za pomocą biblioteki taśmowej z napędami LTO-8 (pojemność kasety 12 TB). Zgodnie z harmonogramem co wtorek taśmy z kopiami pełnymi są przekazywane zewnętrznemu kurierowi w celu przewiezienia do komercyjnego magazynu depozytowego.
• Audyt techniczny biblioteki taśmowej wykazał, że funkcja sprzętowego szyfrowania danych AES-256 w napędach LTO została trwale wyłączona 2 lata temu. Administratorzy wyjaśnili, że po awarii kontrolera biblioteki utracono hasło do lokalnego pliku kluczy oprogramowania backupowego i "przez tydzień nie można było odczytać taśmy testowej, więc zrezygnowano z szyfrowania, aby nie ryzykować utraty dostępu do kopii".
• W konsekwencji każdego tygodnia kilkadziesiąt nieszyfrowanych taśm z danymi genetycznymi i medycznymi milionów Polaków jest transportowanych zwykłym busem kurierskim, w plastikowych skrzyniach zabezpieczonych jedynie jednorazową plombą zaciskową, bez konwoju i bez monitoringu trasy GPS.
• W trakcie inspekcji zaplecza technicznego audytorzy ujawnili partię 120 zużytych taśm magnetycznych LTO-5 wycofanych z eksploatacji, które zostały wyrzucone bezpośrednio do ogólnodostępnego kontenera na odpady komunalne za budynkiem centrali. Taśmy nie zostały poddane demagnetyzacji degausserem ani mechanicznemu zniszczeniu. W dokumentacji działu IT odnaleziono fikcyjny "Protokół utylizacji", podpisany przez kierownika IT bez przeprowadzenia jakiejkolwiek procedury niszczenia.
• Przedsiębiorstwo nie posiada serwera zarządzania kluczami kryptograficznymi (KMS) zgodnego ze standardem KMIP ani modułu HSM, a procedura bezpiecznego depozytu kluczy odzyskiwania (Key Escrow) nigdy nie została opracowana.

Zarząd Spółki, powiadomiony o uchybieniach mogących skutkować katastrofalnym wyciekiem danych i gigantyczną karą finansową od Prezesa UODO, zleca zespołowi audytorów pilne przeprowadzenie zaawansowanego audytu na poziomie oceny 4.0.

Zadanie wymaga oceny konfiguracji biblioteki taśmowej, weryfikacji łańcucha transportowego, wyliczenia ryzyka w matrycy 3x3, formalnej klasyfikacji uchybień, analizy 5 Why oraz opracowania Planu CAP:

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

  Student 1 (Audytor Wiodący / Lead Auditor): Odpowiada za relacje z Zarządem, Głównym Diagnostą i IOD, weryfikację umów powierzenia przetwarzania danych z firmą kurierską i magazynem archiwalnym, koordynację matrycy ryzyka oraz moderację referatu.

  Student 2 (Audytor Techniczny ds. Kryptografii i Bezpieczeństwa Fizycznego): Przeprowadza inspekcję kontrolera biblioteki LTO, weryfikuje status szyfrowania AES-256, bada standard KMIP, architekturę sprzętowych modułów HSM, parametry techniczne degausserów oraz procedurę podwójnego sekretu Key Escrow.

  Student 3 (Audytor Zgodności z RODO, DIN 66399 i Jakości CAP): Analizuje art. 9 i 32 RODO, normę DIN 66399 (klasy T-5 i H-5), normę ISO 27001 (A.7.10, A.7.14, A.8.24), klasyfikuje niezgodności (NC1/NC2/OFI), prowadzi sekwencję 5 Why i konstruuje tabelę Planu Działań Korygujących (CAP).

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Obszaru Kryptografii i Nośników):

  Oceńcie ryzyka w matrycy 3x3 (P: 1-3, S: 1-3, R = P x S):

  1. Kradzież lub zagubienie nieszyfrowanych taśm LTO w transporcie kurierskim skutkujące ujawnieniem profili genetycznych pacjentów (P=3, S=3 -> R=9).

  2. Odzyskanie danych medycznych przez osoby niepowołane z taśm LTO wyrzuconych na śmietnik bez demagnetyzacji (P=3, S=3 -> R=9).

  3. Brak możliwości odczytu zaszyfrowanych kopii w razie awarii z powodu braku procedury Key Escrow (P=2, S=3 -> R=6).

  4. Nałożenie maksymalnej kary finansowej przez UODO (do 20 mln EUR) za rażące zaniedbanie ochrony danych wrażliwych (P=3, S=3 -> R=9).

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

  Sformułujcie karty niezgodności z powołaniem na RODO, normę DIN 66399 i ISO 27001:

  • NC1 (Niezgodność Duża): Przewożenie nieszyfrowanych nośników taśmowych zawierających dane szczególnych kategorii (genetyczne i medyczne) przez zewnętrznego kuriera oraz wyrzucenie zużytych nośników LTO do odpadów komunalnych bez uprzedniej demagnetyzacji i zniszczenia mechanicznego (rażące naruszenie art. 9 i art. 32 ust. 1 lit. a RODO, kontroli ISO/IEC 27001:2022 A.7.10, A.7.14, A.8.24 oraz normy DIN 66399).
  • NC1 (Niezgodność Duża): Całkowity brak scentralizowanego systemu zarządzania kluczami kryptograficznymi (KMS) zgodnego ze standardem KMIP oraz brak procedury bezpiecznego depozytu kluczy odzyskiwania (Key Escrow), co stało się bezpośrednią przyczyną samowolnego wyłączenia szyfrowania przez administratorów (naruszenie kontroli ISO 27001 A.8.24 oraz zasad rozliczalności).
  • NC2 (Niezgodność Mała): Podpisywanie fikcyjnych protokołów utylizacji nośników bez udziału komisji likwidacyjnej i bez certyfikatu niszczenia wydanego przez uprawniony podmiot.
  • OFI (Szansa na doskonalenie): Brak wdrożenia bezpiecznych walizek transportowych z czujnikami sabotażowymi i modułem lokalizacji satelitarnej GPS/GSM dla konwojów nośników archiwalnych.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (wyłączenie szyfrowania taśm LTO z danymi medycznymi) przeprowadźcie dochodzenie 5 Why:

  1. Dlaczego wyłączono szyfrowanie sprzętowe w napędach taśmowych biblioteki LTO? Ponieważ po awarii kontrolera biblioteki informatycy nie potrafili odczytać taśmy testowej z powodu utraty hasła.

  2. Dlaczego informatycy utracili hasło do klucza szyfrującego? Ponieważ hasło było zapisane w pojedynczym pliku konfiguracyjnym na serwerze backupu, który uległ uszkodzeniu podczas awarii.

  3. Dlaczego klucz szyfrujący nie był zarządzany przez centralny serwer KMS z bezpieczną kopią zapasową? Ponieważ spółka nie wdrożyła architektury zarządzania kluczami zgodnej ze standardem KMIP ani modułu HSM.

  4. Dlaczego nie wdrożono profesjonalnego systemu KMS i procedury Key Escrow? Ponieważ projekt wdrożenia szyfrowania taśm potraktowano jako czysto lokalną funkcję oprogramowania backupowego bez opracowania formalnej polityki kryptograficznej.

  5. Dlaczego w spółce przetwarzającej dane genetyczne milionów osób nie wdrożono polityki kryptograficznej? (PRZYCZYNA ŹRÓDŁOWA): Brak w Diagno-Med formalnego ładu bezpieczeństwa informacji (ISMS wg ISO 27001) oraz brak nadzoru Inspektora Ochrony Danych nad technicznym cyklem życia nośników wymiennych, co doprowadziło do pozostawienia decyzji o wyłączeniu zabezpieczeń kryptograficznych w rękach techników działu IT.

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

  Skonstruujcie 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 Architektury KMS KMIP i Procedury Utylizacji DIN 66399):

  Zaprojektujcie:

  • Wdrożenie klastra serwerów zarządzania kluczami KMS zgodnego ze standardem KMIP zintegrowanego ze sprzętowym modułem bezpieczeństwa HSM (FIPS 140-2 Level 3) oraz procedurę podziału klucza Master Key algorytmem Shamira (Key Escrow) zdeponowanego w sejfie bankowym.
  • Sformalizowaną procedurę niszczenia nośników wg normy DIN 66399: demagnetyzacja w degausserze o polu min. 11 000 Gaussów + pocięcie mechaniczne w niszczarce do frakcji T-5 / H-5 w obecności dwuosobowej komisji i z rejestracją wideo.

Zaawansowane wystąpienie seminaryjne (15 minut):

• Waga danych genetycznych w świetle art. 9 RODO i skutki wycieku (3 min): Specyfika działalności Diagno-Med, nieodwracalność naruszenia profilu DNA człowieka i rygory prawne (Student 1).
• Diagnoza techniczna: jawne taśmy w transporcie i nośniki w śmietniku (4 min): Przedstawienie dowodów ze stacji LTO, fikcyjnych protokołów, braku degaussingu, prezentacja matrycy ryzyka 3x3 (Student 2).
• Kwalifikacja uchybień (karty NC1/NC2/OFI) oraz dochodzenie 5 Why (4 min): Uzasadnienie naruszeń normy ISO 27001 i DIN 66399 oraz prezentacja przyczyny źródłowej w braku polityki kryptograficznej (Student 3).
• Plan Działań Korygujących (CAP) i architektura KMIP/Key Escrow (4 min): Demonstracja działania protokołu KMIP, procedury podziału sekretu Shamira, procedury niszczenia nośników wg DIN 66399 oraz bilansu kosztów (cały zespół).

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

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

• Dlaczego dane genetyczne (np. profile sekwencjonowania DNA) podlegają najsurowszemu reżimowi ochronnemu w świetle art. 9 RODO i jakie nieodwracalne skutki prawne, ubezpieczeniowe i społeczne rodzi ich bezprawny wyciek do sieci publicznej?
• W jaki sposób standard protokołu KMIP (Key Management Interoperability Protocol) powiązany ze sprzętowym modułem HSM eliminuje ryzyko utraty dostępu do zaszyfrowanych taśm LTO i dlaczego procedura Key Escrow jest niezbędnym elementem ciągłości działania?
• Jakie procesy fizyczne zachodzą podczas demagnetyzacji taśmy LTO w degausserze o natężeniu pola powyżej 10 000 Gaussów i dlaczego zwykłe nadpisanie logiczne lub pocięcie nośnika nożycami nie spełnia wymogów normy DIN 66399 dla klasy T-5/H-5?

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

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Wyciek danych genetycznych z kradzionych taśm w transporcie -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Sprzętowe szyfrowanie AES-256 w bibliotece taśmowej + serwer KMIP -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 2: Odzyskanie danych z porzuconych taśm LTO na śmietniku -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Procedura DIN 66399 (degausser 11 000 Gs + niszczarka T-5) z rejestracją wideo -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Utrata dostępu do kopii w wyniku awarii serwera kluczy -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Procedura Key Escrow (podział sekretu Shamira w skrytkach bankowych) -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 4: Nałożenie kary 20 mln EUR przez Prezesa UODO -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Wdrożenie certyfikowanego cyklu życia nośników i audyt powdrożeniowy IOD -> 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 Dochodzenia Przyczyn Źródłowych metodą 5 Why dla wyłączenia szyfrowania taśm.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Wdrożenie klastra serwerów zarządzania kluczami KMIP (Thales CipherTrust / Vault) z modułem HSM i włączenie szyfrowania AES-256 na napędach LTO-8 (Właściciel: Kierownik Sekcji Bezpieczeństwa IT, Termin: 30 dni, KPI: 100% taśm szyfrowanych sprzętowo, test odczytu z użyciem klucza KMIP).
  • Zadanie CAP-2: Opracowanie i wykonanie procedury Key Escrow zdeponowania części klucza odzyskiwania w bezpiecznych depozytach bankowych (Właściciel: Pełnomocnik Zarządu ds. Bezpieczeństwa i IOD, Termin: 14 dni, KPI: podpisany protokół depozytowy z 3 niezależnymi instytucjami).
  • Zadanie CAP-3: Podpisanie umowy z certyfikowaną firmą utylizacyjną posiadającą certyfikat DIN 66399 na poziomie min. T-5/H-5 oraz zakup stacjonarnego degaussera laboratoryjnego (Właściciel: Dyrektor Administracyjny, Termin: 30 dni, KPI: 100% wycofywanych taśm demagnetyzowanych i niszczonych komisyjnie).
  • Zadanie CAP-4: Wdrożenie procedury bezpiecznego konwoju nośników archiwalnych w atestowanych walizkach z zamkami szyfrowymi i plombami elektronicznymi (Właściciel: Kierownik Logistyki Medycznej, Termin: 21 dni, KPI: zero transportów w zwykłych pojemnikach, 100% protokołów zdawczo-odbiorczych).
• Projekt Procedury Operacyjnej: "Procedura Bezpieczeństwa Nośników Medycznych SOP-KRYPTO-01: Szyfrowanie Kopii Zapasowych, Zarządzanie Kluczami KMIP, Bezpieczny Transport i Utylizacja Nośników wg DIN 66399".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Całkowite zabezpieczenie poufności danych medycznych i genetycznych milionów pacjentów; eliminacja ryzyka wielomilionowych kar od Prezesa UODO; uodpornienie organizacji na wypadek kradzieży nośnika w transporcie; certyfikowany, bezdyskusyjny proces likwidacji sprzętu IT.
• Wady i trudności: Wysoki koszt zakupu klastra KMS, modułu HSM oraz stacjonarnego degaussera; konieczność rygorystycznego przestrzegania procedur podwójnej kontroli przy zarządzaniu kluczami kryptograficznymi.

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO): art. 9 (Przetwarzanie szczególnych kategorii danych), art. 32 (Bezpieczeństwo przetwarzania), art. 33 i 34 (Zgłaszanie naruszeń), art. 83 (Kary administracyjne).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - A.7.10 (Nośniki pamięci), A.7.14 (Bezpieczne usuwanie lub ponowne użycie sprzętu), A.8.13 (Tworzenie kopii zapasowych), A.8.24 (Stosowanie kryptografii).
• Norma DIN 66399: Niszczenie nośników danych - Wymagania dla urządzeń i procesów niszczenia (części 1, 2 i 3, klasy ochrony 1-3, poziomy bezpieczeństwa T-1 do T-7, H-1 do H-7).
• OASIS Standard: "Key Management Interoperability Protocol (KMIP) Profiles Version 2.1", OASIS Open 2021.
• 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.).
• NIST Special Publication 800-88 Revision 1: "Guidelines for Media Sanitization", NIST 2015.

• U2 Student bezbłędnie klasyfikuje uchybienia w procedurach kryptograficznych i cyklu życia nośników wymiennych do kategorii NC1/NC2/OFI w oparciu o RODO i normę DIN 66399.
• U1 Student projektuje schemat bezpiecznego zarządzania kluczami KMIP z mechanizmem Key Escrow oraz procedurę niszczenia nośników magnetycznych.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla wektorów wycieku danych genetycznych i kar finansowych nakładanych przez organy nadzorcze.
• U4 Student realizuje procedurę 5 Why i konstruuje Plan Działań Korygujących (CAP) spełniający standardy ochrony danych medycznych.
• W1W2W3 Student wykazuje dogłębną znajomość normy DIN 66399, specyfikacji KMIP, kontroli ISO 27001 oraz rygorów art. 9 RODO.
• K1K3 Student przejawia bezwzględną etykę zawodową, bezstronność audytorską oraz dbałość o poszanowanie intymności i praw pacjentów.

Głównym celem zadania na ocenę 4.0 jest wykształcenie u studentów zaawansowanych umiejętności audytu odporności technicznej i infrastruktury zasilania gwarantowanego (systemy zasilaczy UPS z monitoringiem poszczególnych ogniw BMS, automatyka Samoczynnego Załączania Rezerwy - SZR, stacjonarne zespoły prądotwórcze), weryfikacji testów obciążeniowych z użyciem opornicy (Load Bank), badania jakości i degradacji biologicznej paliwa (zjawisko "diesel bug"), dywersyfikacji łączy telekomunikacyjnych oraz audytu procedur awaryjnego funkcjonowania procesów logistycznych w trybie ręcznym (Paper Fallback SOP). Zadanie dotyczy fabryki motoryzacyjnej działającej w rygorystycznym reżimie Just-In-Time (JIT) / Just-In-Sequence (JIS), gdzie każda godzina przestoju generuje gigantyczne kary kontraktowe. Studenci przeprowadzają matrycową analizę ryzyka 3x3, kwalifikację uchybień (NC1/NC2/OFI), dochodzenie przyczyn źródłowych 5 Why oraz opracowują Plan Działań Korygujących (CAP).

Powiązanie z sylabusem i treściami programowymi:

• U2 Profesjonalna identyfikacja i formalna kwalifikacja uchybień w instalacjach zasilania awaryjnego, automatyce SZR i procedurach BCP (NC1/NC2/OFI) z referencją do normy ISO/IEC 27001:2022 (A.7.11, A.8.14), ISO 22301:2020 oraz wytycznych TIA-942.
• U1 Opracowanie zaawansowanego programu dorocznych testów zasilania gwarantowanego pod 100% obciążeniem rezystancyjnym (Load Bank), umowy ramowej na dostawę paliwa kryzysowego oraz procedury awaryjnego wydania wyrobów gotowych.
• U3 Przeprowadzenie analizy ryzyka finansowego i kontraktowego paraliżu linii produkcyjnej OEM w matrycy 3x3 w ujęciu ryzyka inherentnego i rezydualnego.
• U4 Opracowanie Planu Działań Korygujących (CAP) opartego na analizie przyczyn źródłowych 5 Why z mierzalnymi wskaźnikami KPI i terminami wdrożenia (14-90 dni).
• W1W2W3 Dogłębna znajomość normy PN-EN ISO 22301:2020, PN-EN ISO/IEC 27001:2022 (A.7.11, A.8.14), standardu TIA-942 (wymagania dla centrów danych klasy Rated 3) oraz przepisów Prawa energetycznego.
• K1K2K3 Zdolność weryfikacji dowodów z badań inżynieryjnych, odporność na powierzchowne deklaracje działu utrzymania ruchu oraz profesjonalizm audytorski.
• Powiązanie z wykładem: Wyk1 (Audyt infrastruktury przemysłowej), Wyk3 (Kontrole A.7.11 i A.8.14 ISO 27001), Wyk5 (Matrycowa analiza ryzyka 3x3 i analiza BIA), Wyk6 (Inspekcja techniczna i metodyka prób obciążeniowych), Wyk7 (Procedura CAP i 5 Why).

Auto-Components Polska Sp. z o.o. w Gliwicach produkuje moduły zawieszenia i systemy hamulcowe dla wiodących koncernów motoryzacyjnych w Europie. Fabryka zatrudnia 800 pracowników, produkując na 3 zmiany w reżimie Just-In-Time. Ciężarówki z komponentami wyjeżdżają z doków co 90 minut, a jakakolwiek przerwa w dostawach skutkuje karami umownymi w wysokości 50 000 EUR za każdą rozpoczętą godzinę zatrzymania taśmy montażowej klienta OEM.

Stan techniczny infrastruktury zasilania i łączności:

• Serwerownia główna fabryki zasila systemy SAP S/4HANA, system realizacji produkcji MES oraz automatyczny magazyn wysokiego składowania WMS.
• Serwerownia zasilana jest z transformatora zakładowego, a ochronę gwarantowaną stanowi centralny UPS o mocy 80 kVA oraz stacjonarny agregat prądotwórczy z silnikiem wysokoprężnym o mocy 150 kW ze zbiornikiem na 1000 litrów oleju napędowego.
• Szczegółowy audyt inżynieryjny wykazał krytyczne uchybienia:
  • Baterie kwasowo-ołowiowe VRLA w centralnym UPS mają ponad 8 lat (nigdy nie były wymieniane). Test rozładowania wykazał degradację pojemności do 15% wartości nominalnej - rzeczywisty czas podtrzymania wynosi zaledwie 2 minuty i 40 sekund zamiast projektowanych 30 minut.
  • Agregat prądotwórczy od 18 miesięcy nie był uruchamiany w warunkach przejęcia realnego obciążenia fabrycznego przez układ automatyki SZR (Samoczynnego Załączania Rezerwy). Informatycy raz na kwartał uruchamiali agregat na biegu jałowym na 5 minut bez obciążenia (tzw. dry run), co nie daje żadnej gwarancji, że prądnica utrzyma napięcie pod skokowym obciążeniem serwerów i sprężarek klimatyzacji precyzyjnej.
  • Badanie laboratoryjne próbki paliwa pobranej z dna zbiornika agregatu wykazało zaawansowane zakażenie mikrobiologiczne (zjawisko "diesel bug" - rozwój bakterii i grzybów żerujących na estrach biopaliw, tworzących gęsty szlam organiczny i wodę), co gwarantuje natychmiastowe zatkanie filtrów paliwa i zatarcie pompy wtryskowej po kilkunastu minutach ciągłej pracy silnika.
  • Spółka nie posiada zawartej umowy ramowej z dostawcą paliwa gwarantującej dowóz interwencyjny w warunkach kryzysowych (gwarancja SLA do 4 godzin).
  • Łączność telekomunikacyjna fabryki opiera się na pojedynczym kablu światłowodowym podwieszonym na słupach napowietrznych biegnących przez las (brak redundancji i pojedynczy punkt awarii - SPOF).
  • W procedurach BCP fabryki brak jest jakichkolwiek instrukcji dotyczących awaryjnej, papierowej obsługi przyjęć i wydań towarów z magazynu WMS (brak procedury Paper Fallback) na wypadek braku zasilania i łączności.

Dyrektor Operacyjny, po otrzymaniu od koncernu motoryzacyjnego ostrzeżenia audytowego dotyczącego ciągłości dostaw, zleca zespołowi audytorów zaawansowany audyt zasilania i BCP na poziomie oceny 4.0.

Zadanie wymaga oceny technicznej układów zasilania, badania parametrów paliwa, wyliczenia ryzyka w matrycy 3x3, kwalifikacji uchybień, analizy 5 Why oraz opracowania Planu CAP:

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

  Student 1 (Audytor Wiodący / Lead Auditor): Odpowiada za relacje z Dyrekcją Operacyjną, Dyrektorem Logistyki i audytorami koncernów motoryzacyjnych, analizę kontraktów JIT i kar finansowych, koordynację matrycy ryzyka oraz moderację referatu.

  Student 2 (Audytor Techniczny ds. Infrastruktury Energetycznej i Automatyki Budynkowej): Przeprowadza inspekcję UPS, baterii, układu automatyki SZR, analizuje wyniki badań paliwa agregatu, weryfikuje trasy kablowe światłowodów oraz projektuje testy pod opornicą Load Bank i zapasowe łącze satelitarne.

  Student 3 (Audytor Zgodności z ISO 22301, TIA-942 i Jakości CAP): Analizuje normę ISO 22301, kontrolę ISO 27001 A.7.11 i A.8.14, standard TIA-942, klasyfikuje niezgodności (NC1/NC2/OFI), prowadzi dochodzenie 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP).

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Ciągłości Zasilania i Łączności):

  Oceńcie ryzyka w matrycy 3x3 (P: 1-3, S: 1-3, R = P x S):

  1. Nagłe zatrzymanie serwerowni i taśmy montażowej w wyniku wyczerpania baterii UPS w czasie 2 minut przy zaniku napięcia (P=3, S=3 -> R=9).

  2. Zgaśnięcie agregatu prądotwórczego po kilkunastu minutach z powodu zatkania filtrów zakażonym paliwem (P=3, S=3 -> R=9).

  3. Zerwanie pojedynczego kabla światłowodowego przez upadające drzewo i wielogodzinny brak łączności ze światem (P=2, S=3 -> R=6).

  4. Kary umowne rzędu 50 000 EUR/h za zatrzymanie linii montażowej koncernu OEM z powodu braku procedury papierowej (P=3, S=3 -> R=9).

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

  Sformułujcie karty niezgodności z odniesieniem do ISO 27001, ISO 22301 i standardu TIA-942:

  • NC1 (Niezgodność Duża): Całkowity brak sprawności technicznej infrastruktury zasilania gwarantowanego (baterie UPS o czasie podtrzymania 2,5 minuty, agregat z zanieczyszczonym biologicznie paliwem nieuruchamiany pod obciążeniem od 18 miesięcy), stwarzający bezpośrednie ryzyko zatrzymania fabryki przy zaniku napięcia zewnętrznego (rażące naruszenie kontroli ISO/IEC 27001:2022 A.7.11, normy ISO 22301 p. 8.4 oraz wytycznych TIA-942 dla Rated 3).
  • NC1 (Niezgodność Duża): Brak redundancji łączy telekomunikacyjnych (pojedynczy kabel napowietrzny) oraz całkowity brak udokumentowanej i przećwiczonej procedury awaryjnego, papierowego funkcjonowania magazynu i wysyłki towarów (naruszenie kontroli ISO 27001 A.8.14 i ISO 22301).
  • NC2 (Niezgodność Mała): Brak zawartej umowy ramowej z dostawcą paliwa gwarantującej dowóz interwencyjny w czasie do 4 godzin (SLA) w warunkach kryzysowych.
  • OFI (Szansa na doskonalenie): Brak wdrożenia systemu automatycznego monitorowania parametrów każdego pojedynczego ogniwa akumulatorowego (BMS) z pomiarem rezystancji wewnętrznej.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (brak sprawności baterii UPS i zanieczyszczone paliwo w agregacie) przeprowadźcie dochodzenie 5 Why:

  1. Dlaczego baterie UPS mają 8 lat, a w agregacie znajduje się zanieczyszczone paliwo? Ponieważ Dział Utrzymania Ruchu nie wymienił akumulatorów ani nie poddał paliwa filtracji i uzdatnieniu.

  2. Dlaczego Utrzymanie Ruchu nie zrealizowało wymiany baterii i serwisu paliwa? Ponieważ Dział IT i Dział Utrzymania Ruchu wzajemnie przerzucały na siebie odpowiedzialność za infrastrukturę zasilania serwerowni; IT uważało, że agregat to domena elektryków, a elektrycy uznawali serwerownię za domenę IT.

  3. Dlaczego nie określono jasnego podziału odpowiedzialności za zasilanie gwarantowane? Ponieważ w spółce brakowało zintegrowanej Polityki Ciągłości Działania (BCMS) definiującej macierz odpowiedzialności RACI dla urządzeń wspierających serwerownię.

  4. Dlaczego nie wdrożono zintegrowanej polityki BCMS? Ponieważ dyrekcja fabryki traktowała audyty ciągłości dostaw powierzchownie, skupiając się wyłącznie na parametrach wydajnościowych linii produkcyjnej.

  5. Dlaczego dyrekcja ignorowała ryzyka infrastrukturalne na zapleczu IT? (PRZYCZYNA ŹRÓDŁOWA): Brak w przedsiębiorstwie sformalizowanego procesu zarządzania ryzykiem operacyjnym zgodnego z ISO 22301, co skutkowało brakiem świadomości, że awaria 8-letniego akumulatora w serwerowni paraliżuje produkcję o wartości kilkudziesięciu milionów euro.

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

  Skonstruujcie 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 Modernizacji Zasilania, Łączności i Procedury Paper Fallback):

  Zaprojektujcie:

  • Wymianę baterii na akumulatory LiFePO4 z systemem Battery Management System (BMS) gwarantujące 45 minut podtrzymania; oczyszczenie zbiornika agregatu i wdrożenie cyklicznej filtracji paliwa z biocydem.
  • Doroczny test obciążeniowy generatora z użyciem mobilnej opornicy (Load Bank) pod 100% obciążeniem znamionowym przez 4 godziny.
  • Instalację zapasowego łącza satelitarnego Starlink Business z priorytetowym pasmem oraz procedurę "Logistyka JIT Fallback SOP: Awaryjne Ręczne Wydawanie Komponentów z Użyciem Kart Papierowych".

Zaawansowana prezentacja seminaryjna (15 minut):

• Reżim Just-In-Time i mechanizm kar umownych 50 000 EUR/h (3 min): Zależność łańcucha dostaw OEM, waga ciągłości pracy fabryki w Gliwicach, wymagania ISO 22301 (Student 1).
• Diagnoza techniczna: zużyte baterie, bakterie w ropie i wiszący kabel w lesie (4 min): Przedstawienie dowodów ze stacji UPS, wyników próbki laboratoryjnej paliwa, braku prób pod obciążeniem i prezentacja matrycy ryzyka 3x3 (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Uzasadnienie naruszeń normy ISO 27001 i standardu TIA-942 oraz prezentacja przyczyny źródłowej w konflikcie kompetencyjnym IT vs Utrzymanie Ruchu (Student 3).
• Plan Działań Korygujących (CAP) i procedura JIT Fallback (4 min): Demonstracja technologii LiFePO4 z BMS, prób pod opornicą Load Bank, łącza satelitarnego, procedury papierowej wysyłki oraz bilansu kosztów (cały zespół).

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

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

• Dlaczego próba rozruchu agregatu prądotwórczego bez obciążenia (na biegu jałowym) nie stanowi żadnego dowodu jego gotowości operacyjnej i dlaczego tylko test z użyciem opornicy rezystancyjnej (Load Bank) pozwala wykryć wady układu chłodzenia, wtryskiwaczy i prądnicy?
• Na czym polega biologiczne zanieczyszczenie oleju napędowego (zjawisko "diesel bug"), dlaczego współczesne biopaliwa z dodatkiem estrów FAME są szczególnie podatne na ten proces i jak zorganizować procedurę cyklicznej filtracji i uzdatniania paliwa w zbiornikach kryzysowych?
• W jaki sposób zaprojektować procedurę awaryjnego funkcjonowania magazynu wysokiego składowania (Paper Fallback), aby załadunek ciężarówek w reżimie Just-In-Sequence odbywał się bez przestojów przy całkowitym braku zasilania serwerów i braku sieci WiFi?

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

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Zatrzymanie serwerowni w 2 minuty po zaniku zasilania z powodu zużytych baterii UPS -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Wymiana na baterie LiFePO4 z systemem BMS (czas podtrzymania 45 min) -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 2: Zgaśnięcie agregatu po 15 minutach z powodu zatkania filtrów paliwa osadem -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Czyszczenie zbiornika, filtracja magnetyczna, dodatek biobójczy i test Load Bank -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Zerwanie kabla światłowodowego w lesie i odcięcie fabryki od SAP -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Zapasowe łącze satelitarne Starlink Business z automatycznym przełączeniem SD-WAN -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 4: Kary 50 000 EUR/h od koncernów motoryzacyjnych za wstrzymanie dostaw JIT -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Wdrożenie procedury JIT Paper Fallback z awaryjnymi kartami załadunku -> 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 Dochodzenia Przyczyn Źródłowych metodą 5 Why dla awaryjności zasilania serwerowni.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Wymiana pakietu baterii UPS na nowoczesny zestaw akumulatorów LiFePO4 z systemem monitoringu BMS dla każdego ogniwa (Właściciel: Kierownik Działu Utrzymania Ruchu, Termin: 45 dni, KPI: gwarantowany czas podtrzymania min. 45 minut przy pełnym obciążeniu).
  • Zadanie CAP-2: Czyszczenie zbiornika paliwa agregatu, uzdatnienie oleju napędowego i podpisanie umowy ramowej na dostawę paliwa kryzysowego z SLA do 4 godzin (Właściciel: Dyrektor Operacyjny, Termin: 21 dni, KPI: certyfikat czystości paliwa, podpisana umowa z dostawcą paliw).
  • Zadanie CAP-3: Przeprowadzenie 4-godzinnego testu obciążeniowego agregatu pod opornicą Load Bank pod 100% obciążeniem znamionowym (Właściciel: Główny Energetyk Fabryki, Termin: 30 dni, KPI: protokół pomiarowy stabilności napięcia i częstotliwości, brak przegrzewania silnika).
  • Zadanie CAP-4: Wdrożenie zapasowego łącza satelitarnego Starlink Business z routerem SD-WAN oraz wdrożenie procedury JIT Paper Fallback w magazynie (Właściciel: Kierownik IT i Kierownik Logistyki, Termin: 30 dni, KPI: automatyczny failover WAN poniżej 10 sekund, 100% magazynierów przeszkolonych z obsługi ręcznej).
• Projekt Procedury Operacyjnej: "Procedura Ciągłości Infrastruktury Technicznej BCMS-POW-01: Nadzór nad Zasilaniem Gwarantowanym, Testy Obciążeniowe Agregatów oraz Procedura Fallbacku Logistycznego JIT".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Zapewnienie niewzruszonej ciągłości zasilania i telekomunikacji fabryki; wyeliminowanie ryzyka kar umownych od koncernów samochodowych; wydłużenie żywotności baterii dzięki technologii LiFePO4 z 3-4 lat do ponad 10 lat; redundancja łączności uniezależniona od infrastruktury naziemnej.
• Wady i trudności: Wysoki koszt zakupu nowoczesnych baterii litowych i wynajęcia opornicy Load Bank; konieczność cyklicznego wykonywania uciążliwych testów zasilania w weekendowych oknach serwisowych.

• Norma PN-EN ISO 22301:2020: Bezpieczeństwo i odporność - Systemy zarządzania ciągłością działania - Wymagania (punkt 8.4 Gotowość i reagowanie na incydenty).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - A.7.11 (Urządzenia zasilające i wspierające), A.8.14 (Redundancja urządzeń przetwarzania informacji).
• Standard Telecommunications Industry Association TIA-942: Telecommunications Infrastructure Standard for Data Centers (wymagania dla poziomu Rated 3).
• Standard NFPA 110: Standard for Emergency and Standby Power Systems, National Fire Protection Association 2022.
• Ustawa z dnia 10 kwietnia 1997 r. Prawo energetyczne (Dz.U. z 2024 r. poz. 266 z późn. zm.).
• Polskie Sieci Elektroenergetyczne (PSE): "Wytyczne dotyczące zabezpieczenia zasilania awaryjnego w obiektach przemysłowych o strategicznym znaczeniu", Warszawa 2023.

• U2 Student bezbłędnie klasyfikuje uchybienia w infrastrukturze zasilania gwarantowanego i łączności do kategorii NC1/NC2/OFI w oparciu o ISO 27001, ISO 22301 i TIA-942.
• U1 Student projektuje zaawansowany program testów obciążeniowych z opornicą Load Bank oraz procedurę logistycznego fallbacku manualnego w reżimie JIT.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla zagrożeń zatrzymania produkcji przemysłowej i kar kontraktowych.
• U4 Student realizuje procedurę 5 Why i konstruuje Plan Działań Korygujących (CAP) integrujący działy IT, Utrzymania Ruchu i Logistyki.
• W2W3 Student zna normę ISO 22301, standard TIA-942 oraz kontrolę ISO 27001 A.7.11 w odniesieniu do obiektów przemysłowych.
• K1K2 Student przejawia odpowiedzialność inżynierską, dociekliwość techniczną oraz dbałość o realną sprawność infrastruktury krytycznej.

Celem zadania na ocenę 4.0 jest wykształcenie u studentów zaawansowanych umiejętności audytu procesów długoterminowej archiwizacji cyfrowej, wielopoziomowej polityki retencji w schemacie Dziadek-Ojciec-Syn (Grandfather-Father-Son - GFS), zapobiegania cichej korupcji danych (Silent Data Corruption / Bit Rot) oraz weryfikacji integralności kryptograficznej cyfrowych dowodów procesowych. Zadanie osadzone jest w strukturach sądownictwa powszechnego, gdzie cyfrowe nagrania rozpraw (system ReCourt) stanowią wyłączny protokół elektroniczny posiedzenia sądu w sprawach cywilnych i karnych, podlegający wieloletniej (10-25 lat) retencji prawnej. Studenci uczą się weryfikować mechanizmy samo-naprawy danych (Data Scrubbing w systemie plików ZFS/Btrfs), badać zjawisko cichej degradacji bloków magnetycznych, przeprowadzać matrycową analizę ryzyka 3x3 dla postępowań sądowych, klasyfikować uchybienia (NC1/NC2/OFI), prowadzić analizę 5 Why oraz opracowywać Plan Działań Korygujących (CAP).

Powiązanie z sylabusem i treściami programowymi:

• U2 Profesjonalna identyfikacja i formalna kwalifikacja uchybień w politykach retencji, braku weryfikacji sum kontrolnych i korupcji danych archiwalnych (NC1/NC2/OFI) z odniesieniem do KPC, KPK, KRI i ISO 27001.
• U1 Opracowanie matematycznego modelu zapotrzebowania na pamięć masową GFS, architektury pamięci masowej ZFS z automatycznym procesem scrubbingu oraz procedury weryfikacji hashy SHA-256.
• U3 Przeprowadzenie analizy ryzyka uchylenia wyroków sądowych, nieważności postępowań karnych i odszkodowań Skarbu Państwa w matrycy 3x3 w ujęciu inherentnym i rezydualnym.
• U4 Opracowanie Planu Działań Korygujących (CAP) opartego na analizie przyczyn źródłowych 5 Why z mierzalnymi wskaźnikami KPI i terminami wdrożenia (14-90 dni).
• W1W2W3 Dogłębna znajomość przepisów Kodeksu postępowania cywilnego i karnego w zakresie protokołu elektronicznego, par. 20 KRI, normy PN-EN ISO/IEC 27001:2022 (A.8.13, A.8.14) oraz technologii odpornych na Bit Rot.
• K1K2K3 Poszanowanie powagi wymiaru sprawiedliwości, skrupulatność w badaniu dowodów cyfrowych oraz wysoka kultura prawna i rzetelność audytorska.
• Powiązanie z wykładem: Wyk1 (Audyt w wymiarze sprawiedliwości), Wyk3 (Kontrola A.8.13 i integralność danych), Wyk4 (Zgodność z KRI i przepisami procesowymi), Wyk5 (Matrycowa analiza ryzyka 3x3), Wyk6 (Zaawansowane techniki badania integralności danych i hashowanie), Wyk7 (Procedura CAP i 5 Why).

Sąd Apelacyjny wraz z podległym Sądowym Centrum Informatyki nadzoruje 8 sądów okręgowych i 42 sądy rejonowe w okręgu apelacyjnym, w których we wszystkich salach rozpraw zainstalowany jest zintegrowany system cyfrowej rejestracji posiedzeń sądowych ReCourt. System rejestruje obraz Full HD oraz wielokanałowy dźwięk z sal sądowych. W skali apelacji generowanych jest rocznie ponad 120 000 godzin nagrań, co oznacza comiesięczny przyrost danych na poziomie 65 TB (blisko 800 TB rocznie).

Zgodnie z przepisami KPC i KPK oraz rozporządzeniem Ministra Sprawiedliwości nagranie rozprawy stanowi nadrzędny protokół elektroniczny. Utrata lub uszkodzenie nagrania przed prawomocnym zakończeniem postępowania i upływem okresu archiwizacji skutkuje bezwzględną nieważnością postępowania i koniecznością powtórzenia procesu sądowego.

Stan infrastruktury archiwalnej i procesów tworzenia kopii:

• Zgodnie z oficjalną Polityką Retencji Sądu wdrożono schemat rotacji GFS: kopie codzienne przyrostowe (Syn - retencja 14 dni), kopie cotygodniowe (Ojciec - retencja 8 tygodni) oraz kopie comiesięczne (Dziadek - retencja 10 lat, a dla spraw o zbrodnie - 25 lat).
• W trakcie audytu ujawniono, że z powodu braku środków finansowych na rozbudowę macierzy dyskowej, administratorzy sądu 8 miesięcy temu samowolnie zmodyfikowali reguły retencji w oprogramowaniu backupowym: kopie dzienne są usuwane po 3 dniach, kopie cotygodniowe po 14 dniach, a kopie comiesięczne są nadpisywane po 90 dniach.
• Sąd całkowicie zaniechał tworzenia kopii na trwałych nośnikach WORM (taśmy/dyski optyczne). Wszystkie dane przechowywane są na 6-letnich macierzach dyskowych z tanimi dyskami SATA pracującymi pod kontrolą standardowego systemu plików ext4 bez kontroli sum kontrolnych na poziomie bloków.
• Audyt techniczny integralności wykazał, że oprogramowanie backupu weryfikuje jedynie obecność pliku w systemie plików, ale NIE SPRAWDZA sumy kontrolnej zawartości nagrań wideo (pliki MP4).
• Audytorzy przeprowadzili sampling i zweryfikowali losową próbkę 100 plików nagrań z lat 2021-2023. Próba odtworzenia 7 plików zakończyła się błędem "uszkodzony nagłówek kontenera MOOV / uszkodzone bloki wideo". W wyniku cichej degradacji danych (zjawisko Bit Rot na starych dyskach SATA bez mechanizmu parity scrub) doszło do nieodwracalnego uszkodzenia protokołów rozpraw w dwóch wielotomowych procesach gospodarczych o wartości sporów przekraczających 80 milionów PLN, co uniemożliwia sądowi rozpoznanie apelacji.

Prezes Sądu Apelacyjnego, zaalarmowany przez Przewodniczącego Wydziału Gospodarczego, zleca audytorom pilne przeprowadzenie zaawansowanego audytu retencji i integralności na poziomie oceny 4.0.

Zadanie wymaga oceny matematycznej schematu GFS, audytu zjawiska Bit Rot, wyliczenia ryzyka w matrycy 3x3, formalnej klasyfikacji uchybień, analizy 5 Why oraz opracowania Planu CAP:

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

  Student 1 (Audytor Wiodący / Lead Auditor): Odpowiada za relacje z Prezesem Sądu, Dyrektorem Sądu i Wizytatorami, analizę przepisów prawa procesowego (KPC, KPK) i instrukcji archiwalnej Ministerstwa Sprawiedliwości, koordynację matrycy ryzyka oraz moderację referatu.

  Student 2 (Audytor Techniczny ds. Systemów Storage i Danych Multimedialnych): Bada architekturę macierzy dyskowych, strukturę systemu plików ext4 vs ZFS, konfigurację schematu GFS, przeprowadza analizę występowania Bit Rot, weryfikuje sumy kontrolne SHA-256 oraz projektuje repozytorium ZFS z mechanizmem Data Scrubbing i WORM.

  Student 3 (Audytor Zgodności z KRI, Retencją Prawną i Jakości CAP): Analizuje par. 20 KRI, normę ISO 27001 (A.8.13), ocenia ryzyka prawne uchylenia orzeczeń i odszkodowań Skarbu Państwa w matrycy 3x3, prowadzi dochodzenie 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP).

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Procesu Archiwizacji Sądowej):

  Oceńcie ryzyka w matrycy 3x3 (P: 1-3, S: 1-3, R = P x S):

  1. Uchylenie wyroków sądowych i unieważnienie procesów z powodu uszkodzenia protokołów elektronicznych przez Bit Rot (P=3, S=3 -> R=9).

  2. Bezpowrotne skasowanie nagrań rozpraw sprzed 4 miesięcy w wyniku samowolnego skrócenia retencji GFS do 90 dni (P=3, S=3 -> R=9).

  3. Wypłata wielomilionowych odszkodowań przez Skarb Państwa za przewlekłość postępowań i utratę dowodów (P=2, S=3 -> R=6).

  4. Kary i negatywne wystąpienia pokontrolne Najwyższej Izby Kontroli (NIK) za naruszenie Krajowych Ram Interoperacyjności (P=3, S=2 -> R=6).

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

  Sformułujcie karty niezgodności z odniesieniem do KPC, KPK, KRI i ISO 27001:

  • NC1 (Niezgodność Duża): Samowolne skrócenie okresu retencji kopii comiesięcznych z wymaganych 10 lat do 90 dni oraz brak trwałego repozytorium archiwalnego, co doprowadziło do bezpowrotnego zniszczenia nagrań stanowiących nadrzędne protokoły elektroniczne (rażące naruszenie art. 157 KPC, art. 147 KPK, par. 20 ust. 2 pkt 11 KRI oraz kontroli ISO/IEC 27001:2022 A.8.13).
  • NC1 (Niezgodność Duża): Przechowywanie cyfrowych protokołów sądowych na systemach plików podatnych na cichą degradację danych (Bit Rot) oraz całkowity brak automatycznej weryfikacji sum kontrolnych SHA-256 plików wideo w repozytorium (naruszenie kontroli ISO 27001 A.8.13 i zasad rozliczalności dowodowej).
  • NC2 (Niezgodność Mała): Ukrywanie krytycznego braku przestrzeni dyskowej przez administratorów i brak sformalizowanego wniosku inwestycyjnego do Dyrektora Sądu.
  • OFI (Szansa na doskonalenie): Brak wdrożenia automatycznej transkrypcji mowy (Speech-to-Text) jako dodatkowego tekstowego protokołu pomocniczego zintegrowanego z metadanymi nagrania.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (samowolne skrócenie retencji i brak ochrony przed Bit Rot) przeprowadźcie dochodzenie 5 Why:

  1. Dlaczego administratorzy skrócili retencję kopii comiesięcznych do 90 dni? Ponieważ na macierzy dyskowej zabrakło miejsca na nowe nagrania z bieżących rozpraw.

  2. Dlaczego na macierzy zabrakło miejsca? Ponieważ wolumen nagrań wideo rósł o 65 TB miesięcznie, a pojemność macierzy nie była rozbudowywana od 4 lat.

  3. Dlaczego macierz nie została rozbudowana pomimo lawinowego przyrostu danych? Ponieważ informatycy nie przedstawili kierownictwu matematycznego modelu zapotrzebowania na pamięć w oparciu o schemat GFS, zgłaszając jedynie doraźne prośby o zakup pojedynczych dysków.

  4. Dlaczego Dział IT nie opracował wieloletniego planu pojemnościowego (Capacity Planning)? Ponieważ w sądzie zadania IT były realizowane w modelu reaktywnym, bez wyznaczonego architekta systemów pamięci masowej i bez wdrożonej normy ISO 27001.

  5. Dlaczego w sądownictwie nie wdrożono normy ISO 27001 i profesjonalnego planowania pojemności? (PRZYCZYNA ŹRÓDŁOWA): Brak w strukturach sądownictwa centralnego nadzoru architektonicznego nad cyfrowymi archiwami dowodowymi oraz brak powiązania planów budżetowych Ministerstwa Sprawiedliwości z realnymi parametrami retencji prawnej rejestrów publicznych.

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

  Skonstruujcie 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 Architektury ZFS z Mechanizmem Data Scrubbing i WORM):

  Zaprojektujcie:

  • Wdrożenie macierzy dyskowych opartych na systemie plików ZFS z podwójną parzystością (RAID-Z2) oraz włączonym mechanizmem sum kontrolnych Fletcher4/SHA-256 dla każdego bloku danych.
  • Zautomatyzowany harmonogram procesu Data Scrubbing (comiesięczne sprawdzanie poprawności każdego bloku na dyskach i automatyczne samoleczenie wykrytych uszkodzeń Bit Rot z danych parzystości bez przerw w dostępie).
  • Sformalizowaną procedurę "Procedura Archiwizacji ReCourt-SOP-01: Weryfikacja Integralności Sum Kontrolnych SHA-256 i Wieloletnia Retencja Cyfrowych Protokołów Sądowych".

Zaawansowana prezentacja seminaryjna (15 minut):

• Rewolucja protokołu elektronicznego w sądownictwie i rygory prawne (3 min): Waga nagrań wideo w procesie cywilnym i karnym, skutki procesowe utraty dowodu, wymogi KRI (Student 1).
• Diagnoza techniczna: cicha korupcja Bit Rot i samowolne cięcie retencji (4 min): Przedstawienie uszkodzonych plików MP4, brak miejsca na macierzach, analiza logów ext4 i prezentacja matrycy ryzyka 3x3 (Student 2).
• Kwalifikacja uchybień (karty NC1/NC2/OFI) oraz dochodzenie 5 Why (4 min): Uzasadnienie naruszeń KPC, KPK i ISO 27001 oraz prezentacja przyczyny źródłowej w braku planowania pojemnościowego (Capacity Planning) (Student 3).
• Plan Działań Korygujących (CAP) i architektura ZFS Self-Healing (4 min): Demonstracja działania mechanizmu scrubbingu w ZFS, wyliczeń pojemnościowych GFS na 5 lat, potoku hashowania SHA-256 oraz bilansu kosztów (cały zespół).

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

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

• W jaki sposób zjawisko cichej korupcji danych (Silent Data Corruption / Bit Rot) uszkadza kontenery multimedialne (pliki MP4/MKV) na tradycyjnych systemach plików (NTFS, ext4) bez zgłaszania błędów przez kontrolery sprzętowe RAID?
• W jaki sposób system plików ZFS dzięki architekturze Copy-on-Write (CoW), 64-bitowym sumom kontrolnym każdego bloku danych oraz procesowi Data Scrubbing realizuje funkcję "samoleczenia danych" (Self-Healing Storage)?
• Jakie są konsekwencje procesowe dla Skarbu Państwa i stron procesu, gdy w toku postępowania apelacyjnego okazuje się, że zapis dźwięku z kluczowego przesłuchania świadka uległ bezpowrotnemu uszkodzeniu?

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

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Unieważnienie procesów z powodu uszkodzenia nagrań przez Bit Rot -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Migracja do macierzy ZFS RAID-Z2 z comiesięcznym procesem Data Scrubbing -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 2: Skasowanie nagrań sprzed kilku miesięcy z powodu cięcia retencji GFS -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Rozbudowa storage'u do 1,5 PB zgodnie z modelem GFS i blokada retencji WORM -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Podważenie autentyczności nagrania w procesie sądowym -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Hashowanie SHA-256 w chwili rejestracji i zapis w nienaruszalnej bazie metadanych -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 4: Negatywne wystąpienie NIK i zarzuty naruszenia dyscypliny finansów -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Wdrożenie zintegrowanego ISMS i audytów zgodności z KRI -> 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 Dochodzenia Przyczyn Źródłowych metodą 5 Why dla braku planowania pojemności i Bit Rot.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Zakup i wdrożenie macierzy ZFS o pojemności 1,5 PB brutto z podwójną parzystością RAID-Z2 i automatycznym procesem scrubbingu (Właściciel: Dyrektor Sądowego Centrum Informatyki, Termin: 60 dni, KPI: migracja 100% nagrań, harmonogram scrubbingu w każdą pierwszą niedzielę miesiąca).
  • Zadanie CAP-2: Przywrócenie i zablokowanie pełnej polityki retencji GFS (Syn: 14 dni, Ojciec: 8 tygodni, Dziadek: 10/25 lat) w konsoli backupowej (Właściciel: Kierownik Sekcji Pamięci Masowych, Termin: 14 dni, KPI: zgodność reguł retencji z zarządzeniem Ministra Sprawiedliwości).
  • Zadanie CAP-3: Wdrożenie automatycznego modułu hashowania SHA-256 w kodekach sal rozpraw i comiesięcznego audytu integralności (Właściciel: Administrator Systemu ReCourt, Termin: 30 dni, KPI: 100% nagrań z przypisanym i zweryfikowanym hashem SHA-256).
  • Zadanie CAP-4: Przeprowadzenie weryfikacji integralności i naprawy uszkodzonych nagrań z lat 2021-2023 z wykorzystaniem zachowanych kopii cząstkowych (Właściciel: Główny Analityk Danych Cyfrowych, Termin: 45 dni, KPI: raport ze stanu integralności archiwum sądowego).
• Projekt Procedury Operacyjnej: "Procedura Bezpieczeństwa Archiwum Multimedialnego SOP-SĄD-01: Wieloletnia Retencja GFS, Weryfikacja Integralności SHA-256 i Samoleczenie Danych w Pamięciach Masowych ZFS".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Absolutna gwarancja nienaruszalności i integralności protokołów elektronicznych przez 25 lat; pełna eliminacja zjawiska Bit Rot dzięki mechanizmowi scrubbingu w ZFS; uniezależnienie procesu orzeczniczego od awarii fizycznych nośników; stuprocentowa zgodność z prawem procesowym i KRI.
• Wady i trudności: Znaczący wydatek budżetowy na macierze pamięci masowej o pojemności 1,5 PB; dodatkowe obciążenie procesorów kontrolerów macierzy podczas comiesięcznego procesu scrubbingu danych w weekendy.

• Ustawa z dnia 17 listopada 1964 r. Kodeks postępowania cywilnego (Dz.U. z 2023 r. poz. 1550 z późn. zm.) - art. 157 i 158.
• Ustawa z dnia 6 czerwca 1997 r. Kodeks postępowania karnego (Dz.U. z 2024 r. poz. 37 z późn. zm.) - art. 147.
• Rozporządzenie Rady Ministrów w sprawie Krajowych Ram Interoperacyjności (Dz.U. z 2024 r. poz. 733) - par. 20 (tworzenie i przechowywanie kopii bezpieczeństwa).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - A.8.13 (Tworzenie kopii zapasowych informacji), A.8.14 (Redundancja).
• Ministerstwo Sprawiedliwości: "Standardy techniczne dla cyfrowych protokołów sądowych w sądach apelacyjnych i okręgowych", Warszawa 2023.
• Matthew Ahrens (OpenZFS Co-Founder): "ZFS Architecture: Self-Healing Data, Merkle Trees, and Scrubbing", OpenZFS Publications 2022.

• U2 Student bezbłędnie klasyfikuje uchybienia w archiwizacji danych sądowych do kategorii NC1/NC2/OFI w oparciu o KPC, KPK i ISO 27001.
• U1 Student projektuje schemat retencji GFS, wylicza model pojemnościowy storage'u oraz opracowuje architekturę samoleczenia danych ZFS.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla zagrożeń unieważnienia procesów sądowych i roszczeń odszkodowawczych.
• U4 Student realizuje procedurę 5 Why i konstruuje Plan Działań Korygujących (CAP) spełniający standardy wymiaru sprawiedliwości.
• W1W3 Student zna przepisy KPC, KPK, KRI oraz architekturę zaawansowanych systemów plików z integralnością blokową.
• K1K3 Student przejawia odpowiedzialność za powagę i wiarygodność instytucji państwa prawa oraz etykę zawodową.

Celem zadania na ocenę 4.0 jest wykształcenie u studentów zaawansowanych kompetencji audytu środowisk zwirtualizowanych o wysokiej gęstości maszyn (klaster VMware vSphere / Microsoft Hyper-V podłączony do macierzy SAN). Zadanie skupia się na zdemaskowaniu powszechnego, krytycznego błędu metodycznego: traktowania migawek maszyn wirtualnych (Snapshots / Checkpoints) jako kopii zapasowych (Backups), analizie zjawiska degradacji wydajności operacji dyskowych I/O i blokad wolumenów VMFS wywołanych wielomiesięcznymi łańcuchami migawek (tzw. snapshot sprawl), audycie wdrożenia technologii śledzenia zmienionych bloków (Changed Block Tracking - CBT), technologii błyskawicznego odzyskiwania maszyn (Instant VM Recovery) oraz procedur odtwarzania fizycznych hiperwizorów na czystym sprzęcie (Bare-Metal Restore). Studenci przeprowadzają matrycową analizę ryzyka 3x3, kwalifikację uchybień (NC1/NC2/OFI), analizę 5 Why oraz opracowują Plan Działań Korygujących (CAP).

Powiązanie z sylabusem i treściami programowymi:

• U2 Profesjonalna identyfikacja i formalna kwalifikacja uchybień w architekturze wirtualizacji i pamięci masowych (NC1/NC2/OFI) z referencją do normy ISO 27001 (A.8.13, A.8.14) oraz oficjalnych wytycznych VMware Best Practices.
• U1 Opracowanie zaawansowanego projektu dedykowanego systemu backupu wirtualizacji z bezpośrednim dostępem do sieci SAN (Direct SAN Access), deduplikacją blokową oraz procedurą Instant VM Recovery.
• U3 Przeprowadzenie analizy ryzyka bezpowrotnej utraty wyników symulacji fizyki reaktorowej i grantów badawczych w przypadku awarii kontrolera macierzy produkcyjnej SAN w matrycy 3x3.
• U4 Opracowanie Planu Działań Korygujących (CAP) opartego na analizie przyczyn źródłowych 5 Why z mierzalnymi wskaźnikami KPI i terminami wdrożenia (14-90 dni).
• W1W2W3 Dogłębna znajomość normy PN-EN ISO/IEC 27001:2022 (A.8.13, A.8.14), Ustawy o instytutach badawczych, par. 20 KRI oraz architektury hiperwizorów ESXi i systemów plików VMFS.
• K1K2K3 Zdolność demistyfikacji pozornych zabezpieczeń technologicznych, dociekliwość inżynierska przy badaniu metadanych vSphere oraz odpowiedzialność za mienie naukowo-badawcze państwa.
• Powiązanie z wykładem: Wyk1 (Audyt w jednostkach naukowych), Wyk3 (Kontrole A.8.13 i redundancja A.8.14), Wyk5 (Matrycowa analiza ryzyka 3x3), Wyk6 (Analiza logów hiperwizorów ESXi i samplingu plików VMDK), Wyk7 (Procedura CAP i 5 Why).

Państwowy Instytut Badawczy Energetyki Jądrowej w Otwocku prowadzi strategiczne badania w zakresie termonuklearnej syntezy jądrowej, bezpieczeństwa reaktorów wysokotemperaturowych (HTGR) oraz produkcji radiofarmaceutyków dla onkologii. Instytut zatrudnia 450 pracowników naukowych i inżynierów, realizując projekty badawcze o wielomilionowych budżetach finansowane przez Narodowe Centrum Badań i Rozwoju (NCBR) oraz programy europejskie Euratom.

Infrastruktura wirtualna, storage SAN i procesy "kopii bezpieczeństwa":

• Środowisko obliczeniowe i serwerowe instytutu składa się z klastra 8 dwuprocesorowych serwerów kasetowych pod kontrolą VMware vSphere 8.0 Enterprise Plus, zarządzanych przez centralną aplikację vCenter Server Appliance (VCSA).
• W klastrze uruchomionych jest 65 maszyn wirtualnych (VM), w tym serwery bazodanowe aparatury pomiarowej reaktora badawczego, klastry numeryczne symulacji Monte Carlo, system ERP oraz repozytorium grantów naukowych. Wszystkie pliki dysków wirtualnych (pliki *.vmdk) spoczywają na centralnej macierzy dyskowej SAN połączonej z serwerami za pośrednictwem sieci Fiber Channel (FC) 16 Gbps.
• W trakcie badania audytowego główny administrator wirtualizacji oświadczył, że "instytut posiada bezbłędny system backupu, ponieważ codziennie o godzinie 01:00 skrypt PowerShell tworzy migawkę (snapshot) każdej maszyny wirtualnej".
• Szczegółowy audyt inżynieryjny magazynów datastore VMFS ujawnił katastrofalny stan faktyczny:
  • Na 42 maszynach wirtualnych zidentyfikowano głębokie drzewa migawek sięgające wstecz od 4 do 9 miesięcy (zjawisko snapshot sprawl).
  • Pliki delta (pliki różnicowe *-00000X-delta.vmdk) osiągnęły gigantyczne rozmiary (na niektórych maszynach po 3-4 TB), co doprowadziło do załamania wydajności operacji wejścia/wyjścia (I/O) - latencja dyskowa wzrosła z 3 ms do ponad 85 ms, a przestrzeń na wolumenach VMFS została zapełniona w 98%.
  • Instytut NIE POSIADA ŻADNEJ niezależnej kopii zapasowej maszyn wirtualnych na zewnętrznym serwerze lub innej fizycznej pamięci masowej poza tą samą macierzą SAN.
  • Administratorzy nie rozumieją, że migawka jest jedynie plikiem różnicowym i w przypadku awarii kontrolera macierzy SAN lub uszkodzenia metadanych VMFS, wszystkie maszyny wirtualne wraz ze wszystkimi migawkami ulegną jednoczesnej i bezpowrotnej zagładzie.
  • Ponadto instytut nie archiwizuje bazy vCenter (VCSA) na zewnętrzny serwer SFTP ani nie posiada wyeksportowanych profili hostów (Host Profiles) do odtworzenia hiperwizorów ESXi na czystym sprzęcie (brak procedury Bare-Metal Restore).

Dyrektor Naukowy Instytutu, zaalarmowany zawieszaniem się symulacji reaktorowych i ostrzeżeniami o braku miejsca na macierzy SAN, powołuje zespół audytorów do przeprowadzenia zaawansowanego audytu wirtualizacji na poziomie oceny 4.0.

Zadanie wymaga oceny konfiguracji klastra vSphere, analizy zjawiska snapshot sprawl, wyliczenia ryzyka w matrycy 3x3, formalnej klasyfikacji uchybień, analizy 5 Why oraz opracowania Planu CAP:

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

  Student 1 (Audytor Wiodący / Lead Auditor): Odpowiada za relacje z Dyrekcją Naukową, Kierownikami Zakładów Badawczych i IOD, weryfikację wartości grantów NCBR/Euratom i odpowiedzialności prawnej, koordynację matrycy ryzyka oraz moderację referatu.

  Student 2 (Audytor Techniczny ds. Wirtualizacji i Architektury SAN): Przeprowadza inspekcję klastra vSphere za pomocą skryptów PowerCLI, bada strukturę plików delta na wolumenach VMFS, analizuje latencję i IOPS macierzy SAN, projektuje bezpieczną architekturę backupu z modułem CBT, Instant VM Recovery i Bare-Metal Restore.

  Student 3 (Audytor Zgodności z KRI, Standardami Wirtualizacji i Jakości CAP): Analizuje normę ISO 27001 (A.8.13, A.8.14), oficjalne wytyczne VMware Best Practices, szacuje ryzyka utraty grantów w matrycy 3x3, prowadzi dochodzenie 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP).

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Środowiska Wirtualizacji):

  Oceńcie ryzyka w matrycy 3x3 (P: 1-3, S: 1-3, R = P x S):

  1. Bezpowrotna utrata 65 maszyn wirtualnych instytutu przy pojedynczej awarii macierzy SAN z powodu utożsamiania migawek z backupem (P=3, S=3 -> R=9).

  2. Załamanie pracy klastra i uszkodzenie wolumenów VMFS w wyniku wyczerpania przestrzeni dyskowej przez pliki delta (P=3, S=3 -> R=9).

  3. Wielotygodniowy przestój instytutu w wyniku awarii hostów ESXi i braku procedury Bare-Metal Restore (P=2, S=3 -> R=6).

  4. Utrata wielomilionowych grantów NCBR z powodu niemożności przedstawienia wyników badań reaktorowych (P=2, S=3 -> R=6).

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

  Sformułujcie karty niezgodności z powołaniem na ISO 27001, KRI i VMware Best Practices:

  • NC1 (Niezgodność Duża): Błędne traktowanie migawek maszyn wirtualnych (snapshots) jako pełnych kopii zapasowych oraz całkowity brak niezależnego repozytorium kopii poza produkcyjną macierzą SAN, stwarzające bezpośrednie ryzyko całkowitej likwidacji środowiska IT instytutu (rażące naruszenie kontroli ISO/IEC 27001:2022 A.8.13, A.8.14, par. 20 KRI oraz oficjalnych zaleceń VMware Best Practices KB 1025279).
  • NC1 (Niezgodność Duża): Utrzymywanie łańcuchów migawek przez okres do 9 miesięcy (snapshot sprawl) skutkujące krytycznym zapełnieniem wolumenów VMFS (98%) oraz wzrostem latencji dyskowej do 85 ms (naruszenie kontroli ISO 27001 A.8.9 Zarządzanie konfiguracją i zaleceń producenta wirtualizacji).
  • NC2 (Niezgodność Mała): Brak wyeksportowanych profili konfiguracyjnych hostów (Host Profiles) oraz brak zewnętrznej archiwizacji bazy danych vCenter Server Appliance (VCSA) na serwer SFTP uniemożliwiające wykonanie procedury Bare-Metal Restore.
  • OFI (Szansa na doskonalenie): Brak wdrożenia automatycznego potoku testowego weryfikującego stan kopii zapasowych maszyn numerycznych z uruchomieniem próbnej symulacji testowej.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (brak dedykowanego backupu i traktowanie snapshotów jako kopii) przeprowadźcie dochodzenie 5 Why:

  1. Dlaczego instytut opiera się wyłącznie na snapshotach maszyn zamiast na dedykowanym backupie? Ponieważ informatycy uznali tworzenie migawek skryptem za w pełni wystarczające i bezpłatne rozwiązanie ochronne.

  2. Dlaczego informatycy nie rozumieli różnicy między migawką a właściwą kopią zapasową? Ponieważ zespół IT nie przeszedł profesjonalnych szkoleń certyfikacyjnych VMware (VCP) i bazował na potocznej, błędnej wiedzy internetowej.

  3. Dlaczego kierownictwo instytutu nie wysłało administratorów na certyfikowane szkolenia i nie zakupiło oprogramowania backupu? Ponieważ w budżecie IT brakowało dedykowanej pozycji na rozwój kompetencji i oprogramowanie narzędziowe, a wnioski były redukowane podczas planowania budżetu.

  4. Dlaczego wnioski IT były redukowane? Ponieważ w instytucie nie powołano Oficera Bezpieczeństwa Informacji (CISO), który przedstawiłby Zarządowi analizę ryzyka technologicznego dla infrastruktury serwerowej.

  5. Dlaczego w strategicznym instytucie badawczym nie powołano CISO i nie wdrożono ISMS? (PRZYCZYNA ŹRÓDŁOWA): Brak w instytucie wdrożonego systemu zarządzania bezpieczeństwem informacji opartego na normie ISO 27001, co doprowadziło do traktowania infrastruktury wirtualizacji w sposób amatorski i nieświadomego ryzykowania dorobku naukowego o wartości dziesiątek milionów złotych.

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

  Skonstruujcie 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 Architektury Dedykowanego Backupu i Instant VM Recovery):

  Zaprojektujcie:

  • Dedykowany serwer backupu wirtualizacji (np. Veeam / Commvault) z bezpośrednim dostępem do macierzy (Direct SAN Access przez sieć Fiber Channel), zapisujący skompresowane i deduplikowane kopie na niezależny serwer pamięci masowej w osobnym budynku instytutu.
  • Rygorystyczną politykę Snapshot Policy: maksymalny czas życia migawki = 72 godziny, bezwzględny zakaz utrzymywania drzew wielopoziomowych, automatyczny alert po 24 godzinach i automatyczne scalenie po 72 godzinach.
  • Procedurę Instant VM Recovery (uruchomienie krytycznej maszyny wirtualnej bezpośrednio ze skompresowanego pliku kopii w czasie poniżej 90 sekund) oraz procedurę Bare-Metal Restore dla klastra ESXi.

Zaawansowane wystąpienie seminaryjne (15 minut):

• Strategiczne znaczenie badań jądrowych i rygory grantów badawczych (3 min): Misja instytutu w Otwocku, specyfika obliczeń reaktorowych i odpowiedzialność za środki publiczne (Student 1).
• Diagnoza techniczna: mit "snapshot to backup" i anatomia snapshot sprawl (4 min): Przedstawienie dowodów z wolumenów VMFS, plików delta o wielkości 35 TB, wykresów latencji 85 ms i prezentacja matrycy ryzyka 3x3 (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz dochodzenie 5 Why (4 min): Uzasadnienie naruszeń normy ISO 27001 i zaleceń VMware Best Practices oraz przedstawienie przyczyny źródłowej w braku certyfikacji personelu i ISMS (Student 3).
• Plan Działań Korygujących (CAP) i architektura Instant VM Recovery (4 min): Demonstracja działania mechanizmu Direct SAN Access, procedury scalania starych migawek, uruchomienia maszyny z backupu w 90 sekund oraz bilansu kosztów (cały zespół).

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

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

• Dlaczego migawka maszyny wirtualnej (Snapshot w VMware vSphere / Checkpoint w Hyper-V) pod żadnym pozorem NIE JEST kopią zapasową i jak mechanizm przekierowania zapisu do pliku delta powoduje, że uszkodzenie dysku bazowego niszczy bezpowrotnie wszystkie migawki zależne?
• W jaki sposób zjawisko "snapshot sprawl" degraduje wydajność macierzy SAN, dlaczego scalanie (konsolidacja) migawki o rozmiarze kilkuset gigabajtów może unieruchomić maszynę wirtualną na wiele godzin (zjawisko stun) i jak bezpiecznie przeprowadzić ten proces w środowisku produkcyjnym?
• Na czym polega technologia Instant VM Recovery (błyskawiczny start maszyny z pliku backupu poprzez emulację datastore NFS) i jak w połączeniu z mechanizmem Storage vMotion pozwala osiągnąć wskaźnik RTO poniżej 5 minut bez przerywania pracy użytkowników?

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

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Bezpowrotna utrata 65 maszyn instytutu przy awarii macierzy SAN -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Dedykowany serwer backupu Direct SAN z repozytorium w osobnym budynku -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 2: Blokada wolumenów VMFS i awaria z powodu zapełnienia przez pliki delta -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Konsolidacja migawek i wdrożenie Snapshot Policy (max 72h) -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Wielotygodniowy przestój po awarii hiperwizorów ESXi -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Wdrożenie Host Profiles i backupu VCSA na serwer SFTP (Bare-Metal SOP) -> P_rez=1, S_rez=2, R_rez=2.
  • Ryzyko 4: Utrata dofinansowania grantów NCBR/Euratom z powodu utraty danych symulacji -> P_inh=2, S_inh=3, R_inh=6 -> Kontrola: Comiesięczne automatyczne testy odtwarzania z procedurą Instant VM Recovery -> 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 Dochodzenia Przyczyn Źródłowych metodą 5 Why dla braku niezależnego backupu wirtualizacji.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Bezpieczna, etapowa konsolidacja (scalenie) przeterminowanych plików delta dla 42 maszyn wirtualnych w weekendowych oknach serwisowych (Właściciel: Główny Administrator VMware, Termin: 21 dni, KPI: odzyskanie min. 35 TB przestrzeni na datastore, zero aktywnych migawek starszych niż 72h).
  • Zadanie CAP-2: Zakup i wdrożenie dedykowanego serwera backupu wirtualizacji z niezależnym repozytorium dyskowym z deduplikacją w osobnym budynku (Właściciel: Kierownik Działu IT, Termin: 45 dni, KPI: 100% maszyn wirtualnych objętych codziennym backupem CBT z bezpośrednim odczytem SAN).
  • Zadanie CAP-3: Opracowanie, zatwierdzenie i wdrożenie Polityki Cyklu Życia Migawek (Snapshot Policy) z automatycznymi skryptami nadzorczymi w PowerCLI (Właściciel: CISO / Architekt Systemowy, Termin: 14 dni, KPI: automatyczne alerty po 24h, automatyczne scalanie po 72h).
  • Zadanie CAP-4: Opracowanie procedury Bare-Metal Restore dla klastra ESXi oraz wdrożenie automatycznego backupu vCenter (VCSA) na serwer SFTP (Właściciel: Inżynier Systemów Wirtualnych, Termin: 14 dni, KPI: pomyślny test odtworzenia czystego hosta ESXi w czasie poniżej 45 minut).
• Projekt Procedury Operacyjnej: "Standardowa Procedura Operacyjna SOP-VIRT-01: Polityka Zarządzania Migawkami (Snapshot Lifecycle), Dedykowany Backup Maszyn VM, Procedura Instant VM Recovery oraz Bare-Metal Restore Klastra vSphere".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Całkowite wyeliminowanie ryzyka utraty maszyn wirtualnych przy awarii macierzy SAN; odzyskanie ponad 35 TB przestrzeni dyskowej na macierzy produkcyjnej; spadek latencji dyskowej z 85 ms do 3 ms; skrócenie czasu odtworzenia kluczowych symulacji do 90 sekund dzięki Instant VM Recovery; pełna zgodność z normą ISO 27001 i zaleceniami VMware.
• Wady i trudności: Koszt zakupu dedykowanego serwera pamięci masowej i licencji oprogramowania backupu; konieczność niezwykle ostrożnego, wieloetapowego scalania starych migawek pod nadzorem inżynierów, aby nie doprowadzić do przepełnienia bufora macierzy.

• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - A.8.13 (Tworzenie kopii zapasowych informacji), A.8.14 (Redundancja urządzeń przetwarzania informacji), A.8.9 (Zarządzanie konfiguracją).
• VMware Corporation: "Best practices for using and maintaining virtual machine snapshots in the VMware vSphere environment (KB 1025279)", VMware Documentation 2023.
• VMware Corporation: "vSphere Storage Guide - Managing VMFS Datastores and Virtual Disk Redo Logs", VMware Knowledge Base 2023.
• Rozporządzenie Rady Ministrów w sprawie Krajowych Ram Interoperacyjności (Dz.U. z 2024 r. poz. 733) - par. 20.
• Ustawa z dnia 30 kwietnia 2010 r. o instytutach badawczych (Dz.U. z 2024 r. poz. 534 z późn. zm.).
• Veeam Software: "Veeam Backup & Replication Best Practices - VMware vSphere Infrastructure Guide", Veeam Guides 2023.

• U2 Student bezbłędnie klasyfikuje uchybienia w architekturze wirtualizacji do kategorii NC1/NC2/OFI w oparciu o ISO 27001 i wytyczne VMware.
• U1 Student projektuje dedykowany system backupu maszyn VM z modułem CBT, architekturę Instant VM Recovery oraz procedurę Bare-Metal Restore.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla zagrożeń utraty centralnej pamięci masowej SAN i dorobku instytutu badawczego.
• U4 Student realizuje procedurę 5 Why i konstruuje Plan Działań Korygujących (CAP) spełniający standardy inżynierii systemów wirtualnych.
• W2W3 Student wykazuje dogłębną znajomość architektury VMware vSphere, zaleceń producenta oraz normy ISO 27001 w obszarze ciągłości działania.
• K1K2 Student przejawia dociekliwość inżynierską, krytycyzm wobec amatorskich praktyk IT oraz dbałość o bezpieczeństwo infrastruktury badawczej.

Głównym celem zadania na ocenę 4.0 jest opanowanie przez studentów zaawansowanej metodyki audytu strategicznej, organizacyjnej i dowódczej części Planu Ciągłości Działania (BCP) oraz Zarządzania Kryzysowego (Crisis Management) w przedsiębiorstwie o fundamentalnym znaczeniu dla bezpieczeństwa państwa. Zadanie dotyczy Operatora Systemu Dystrybucyjnego (OSD) energii elektrycznej będącego obiektem infrastruktury krytycznej i podmiotem kluczowym dyrektywy NIS2 / ustawy o KSC. Zadanie skupia się na audycie struktury łańcucha dowodzenia (Incident Command System - ICS), formalnych reguł sukcesji decyzyjnej pod nieobecność członków Zarządu, systemów masowego ostrzegania i autonomicznej łączności kryzysowej (TETRA / telefony satelitarne Iridium) odpornych na blackout i zalanie stacji bazowych, procedur komunikacji zewnętrznej i przeciwdziałania dezinformacji (fake news) oraz programu cyklicznych ćwiczeń symulacyjnych typu Tabletop z udziałem Rządowego Centrum Bezpieczeństwa (RCB) i Wojewody. Studenci przeprowadzają matrycową analizę ryzyka 3x3, kwalifikację uchybień (NC1/NC2/OFI), analizę 5 Why oraz opracowują Plan Działań Korygujących (CAP).

Powiązanie z sylabusem i treściami programowymi:

• U2 Profesjonalna identyfikacja i formalna kwalifikacja krytycznych luk dowódczych, łącznościowych i organizacyjnych (NC1/NC2/OFI) z referencją do Ustawy o zarządzaniu kryzysowym, dyrektywy NIS2, ISO 22301 i ISO 27001.
• U1 Opracowanie zaawansowanego regulaminu pracy Sztabu Kryzysowego OSD opartego na modelu Incident Command System (ICS), schematu sukcesji decyzyjnej oraz procedury powiadamiania alarmowego.
• U3 Przeprowadzenie analizy ryzyka paraliżu decyzyjnego, chaosu dowodzenia, dezinformacji i paniki społecznej w warunkach katastrofy powodziowej i regionalnego blackoutu w matrycy 3x3.
• U4 Opracowanie kompleksowego Planu Działań Korygujących (CAP) opartego na analizie przyczyn źródłowych 5 Why z mierzalnymi wskaźnikami KPI i terminami wdrożenia (14-90 dni).
• W1W2W3 Dogłębna znajomość Ustawy o zarządzaniu kryzysowym, Ustawy o Krajowym Systemie Cyberbezpieczeństwa, dyrektywy NIS2, normy PN-EN ISO 22301:2020 (punkt 8.4) oraz wytycznych RCB i FEMA.
• K1K2K3 Postawa przywódcza, odporność na presję czasu i stresu w warunkach symulowanej katastrofy, wysoka etyka odpowiedzialności publicznej oraz rzetelność audytorska.
• Powiązanie z wykładem: Wyk1 (Audyt w spółkach o znaczeniu strategicznym), Wyk3 (Kontrole A.5.29 i A.5.30 w zarządzaniu incydentami), Wyk4 (Zgodność z NIS2 i Ustawą o zarządzaniu kryzysowym), Wyk5 (Matrycowa analiza ryzyka 3x3 dla sytuacji kryzysowych), Wyk6 (Weryfikacja procedur dowodzenia i dowodów z ćwiczeń), Wyk7 (Procedura CAP i 5 Why).

Pol-Energia Dystrybucja S.A. jest regionalnym Operatorem Systemu Dystrybucyjnego (OSD) dostarczającym energię elektryczną do 1,2 miliona odbiorców w południowo-wschodniej Polsce, zarządzając siecią 35 000 km linii energetycznych, 180 Głównymi Punktami Zasilania (GPZ) oraz Centralnym Ośrodkiem Dyspozytorskim (COD). Spółka jest wpisana do jednolitego wykazu obiektów infrastruktury krytycznej prowadzonego przez Dyrektora RCB.

Centralny Ośrodek Dyspozytorski oraz główna serwerownia mieszczą się w zabytkowej dzielnicy nadrzecznej w pobliżu wałów przeciwpowodziowych dużej rzeki nizinnej.

Stan faktyczny procedur ciągłości działania i zarządzania kryzysowego:

• Spółka posiada "Plan Ciągłości Działania i Reagowania Kryzysowego na Wypadek Klęsk Żywiołowych" zatwierdzony w 2018 roku, który nigdy nie był nowelizowany.
• Szczegółowy audyt organizacyjny i procedur kryzysowych ujawnił przerażający stan faktyczny:
  • Księga Zarządzania Kryzysowego zawiera nieaktualną listę kontaktową członków Sztabu Kryzysowego: 4 z 7 osób (w tym Główny Dyspozytor Mocy i Pełnomocnik ds. Bezpieczeństwa) już nie pracuje w spółce, a podane numery telefonów są nieaktywne.
  • W strukturze dowodzenia brak jest jakiejkolwiek procedury sukcesji (kto przejmuje dowodzenie w razie nieobecności Prezesa Zarządu). W planie zapisano, że decyzję o wyłączeniu zalewanych stacji transformatorowych i ewakuacji serwerowni podejmuje wyłącznie Prezes Zarządu. Podczas ostatniej fali wezbraniowej Prezes przebywał na urlopie za granicą i nikt w spółce nie posiadał formalnego pełnomocnictwa do wydania polecenia wyłączenia zasilania zalewanej podstacji, co o mały włos nie doprowadziło do porażenia prądem strażaków układających worki z piaskiem.
  • Procedura alarmowego powiadamiania członków sztabu opiera się wyłącznie na wysyłaniu SMS z prywatnego telefonu dyspozytora przez publiczną sieć komórkową GSM. W warunkach katastrofalnej powodzi lub huraganu, gdy stacje bazowe telefonii komórkowej zostaną zalane lub pozbawione prądu, powiadomienie kluczowego personelu jest całkowicie niemożliwe.
  • Spółka nie posiada dedykowanych środków łączności kryzysowej (brak radiotelefonów TETRA/DMR z buforowym zasilaniem na masztach, brak telefonów satelitarnych dla sztabu).
  • W planie brakuje wyznaczonego oficera prasowego ds. kryzysowych: podczas lokalnej awarii brak oficjalnych komunikatów spółki wywołał lawinę fałszywych informacji (fake news) w mediach społecznościowych o rzekomym "skażeniu transformatorów i wielotygodniowym braku prądu", co doprowadziło do paniki ludności i paraliżu stacji benzynowych.
  • W spółce od 6 lat nie przeprowadzono żadnych ćwiczeń zgrywających Sztabu Kryzysowego (ani ćwiczeń symulacyjnych Tabletop, ani ćwiczeń terenowych) z udziałem Wojewody, PSP, Policji, WOT czy Rządowego Centrum Bezpieczeństwa.

Rada Nadzorcza Spółki, stając w obliczu wzrastającego ryzyka powodziowego i zaostrzenia przepisów dyrektywy NIS2, zleca zespołowi audytorów zaawansowany audyt łańcucha dowodzenia i BCP na poziomie oceny 4.0.

Zadanie wymaga oceny procedur dowódczych, łączności alarmowej, wyliczenia ryzyka w matrycy 3x3, formalnej klasyfikacji uchybień, analizy 5 Why oraz opracowania Planu CAP:

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

  Student 1 (Audytor Wiodący / Lead Auditor): Odpowiada za relacje z Radą Nadzorczą, Zarządem, Rządowym Centrum Bezpieczeństwa (RCB) i Wojewodą, weryfikację Ustawy o zarządzaniu kryzysowym i NIS2, koordynację matrycy ryzyka oraz moderację referatu.

  Student 2 (Audytor Techniczny ds. Systemów Łączności Kryzysowej i Ostrzegania): Przeprowadza audyt systemów telekomunikacyjnych, analizuje podatność sieci GSM na blackout, bada standardy cyfrowej łączności radiowej (TETRA/DMR Tier III), systemy satelitarne Iridium Push-to-Talk, systemy masowego powiadamiania (IVR/SMS) i projektuje architekturę łączności sztabowej.

  Student 3 (Audytor Zgodności z ISO 22301, Prawem Energetycznym i Jakości CAP): Analizuje normę ISO 22301 (p. 8.4), wytyczne RCB i FEMA ICS, klasyfikuje niezgodności (NC1/NC2/OFI), prowadzi procedurę 5 Why oraz konstruuje tabelę Planu Działań Korygujących (CAP).

• Krok 2 (Konstrukcja Matrycy Ryzyka 3x3 dla Zarządzania Kryzysowego):

  Oceńcie ryzyka w matrycy 3x3 (P: 1-3, S: 1-3, R = P x S):

  1. Śmiertelne porażenie prądem ratowników i ludności z powodu paraliżu decyzyjnego i braku sukcesji pod nieobecność Prezesa (P=3, S=3 -> R=9).

  2. Całkowita niemożność zwołania Sztabu Kryzysowego przy powodzi z powodu awarii sieci publicznych GSM (P=3, S=3 -> R=9).

  3. Masowa panika społeczna i paraliż regionu wywołane brakiem oficjalnych komunikatów i fałszywymi wiadomościami w mediach (P=3, S=2 -> R=6).

  4. Kary finansowe i odpowiedzialność karna członków Zarządu za niedopełnienie obowiązków ochrony infrastruktury krytycznej (P=3, S=3 -> R=9).

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

  Sformułujcie karty niezgodności z odniesieniem do Ustawy o zarządzaniu kryzysowym, NIS2 i ISO 22301:

  • NC1 (Niezgodność Duża): Posiadanie całkowicie nieaktualnego planu zarządzania kryzysowego (brak aktualnych kontaktów, brak procedury sukcesji decyzyjnej pod nieobecność Prezesa), co stwarza bezpośrednie zagrożenie życia ludzkiego i paraliżu dowodzenia w obiekcie infrastruktury krytycznej (rażące naruszenie art. 6 Ustawy o zarządzaniu kryzysowym, art. 8 Ustawy o KSC oraz normy PN-EN ISO 22301:2020 p. 8.4).
  • NC1 (Niezgodność Duża): Oparcie systemu powiadamiania i łączności alarmowej wyłącznie na publicznej sieci GSM bez redundancji radiowej TETRA i łączności satelitarnej, co uniemożliwia dowodzenie akcją ratunkową w warunkach klęski żywiołowej (naruszenie kontroli ISO/IEC 27001:2022 A.5.29, A.5.30 i wytycznych RCB).
  • NC2 (Niezgodność Mała): Całkowity brak przeprowadzania ćwiczeń symulacyjnych typu Tabletop od 6 lat oraz brak procedury komunikacji medialnej i zwalczania dezinformacji.
  • OFI (Szansa na doskonalenie): Brak wdrożenia mobilnego kontenerowego punktu dyspozytorskiego (Mobile Command Post) na podwoziu samochodu ciężarowego z napędem 4x4.
• Krok 4 (Analiza Przyczyn Źródłowych metodą 5 Why):

  Dla niezgodności krytycznej (brak aktualnych procedur dowodzenia i sukcesji w Sztabie Kryzysowym) przeprowadźcie dochodzenie 5 Why:

  1. Dlaczego w Księdze BCP znajdowały się nieaktualne kontakty, a plan nie przewidywał sukcesji stanowisk? Ponieważ dokument leżał na półce od 2018 roku i nie był poddawany corocznym przeglądom.

  2. Dlaczego plan nie był poddawany corocznym przeglądom? Ponieważ po odejściu poprzedniego Pełnomocnika ds. Bezpieczeństwa nikt nie otrzymał formalnego polecenia nadzoru nad planem BCP.

  3. Dlaczego Zarząd nie wyznaczył nowego koordynatora ds. ciągłości działania? Ponieważ Zarząd traktował zarządzanie kryzysowe jako zagadnienie czysto teoretyczne, skupiając się wyłącznie na bieżących wskaźnikach finansowych i inwestycjach w sieć.

  4. Dlaczego Zarząd ignorował wymogi zarządzania kryzysowego pomimo statusu infrastruktury krytycznej? Ponieważ w spółce nie funkcjonował system zarządzania ryzykiem operacyjnym, a audyty wewnętrzne nie obejmowały procedur kryzysowych.

  5. Dlaczego audyty wewnętrzne nie obejmowały gotowości kryzysowej? (PRZYCZYNA ŹRÓDŁOWA): Brak w Pol-Energia OSD dojrzałego ładu korporacyjnego w obszarze ciągłości działania opartego na normie ISO 22301 oraz brak egzekwowania przez Radę Nadzorczą odpowiedzialności za bezpieczeństwo strategiczne państwa, co doprowadziło do całkowitego oderwania planów BCP od realiów operacyjnych spółki.

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

  Skonstruujcie 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 Struktury ICS, Łączności TETRA/Iridium i Ćwiczeń Tabletop):

  Zaprojektujcie:

  • Strukturę Sztabu Kryzysowego zgodną ze standardem Incident Command System (ICS): jednoosobowy łańcuch dowodzenia z automatyczną sukcesją (Kierownik Akcji: Prezes -> Wiceprezes ds. Technicznych -> Główny Dyspozytor Mocy) z pełnymi pełnomocnictwami prawnymi.
  • Wdrożenie autonomicznej łączności radiowej TETRA/DMR z buforowanym zasilaniem masztów na min. 72 godziny oraz wyposażenie członków sztabu w terminale satelitarne Iridium Extreme.
  • Sformalizowaną procedurę operacyjną "Regulamin Pracy Sztabu Kryzysowego OSD-BCP-01: Łańcuch Dowodzenia ICS, Łączność Awaryjna, Polityka Komunikacji Medialnej oraz Scenariusz Ćwiczeń Tabletop Potop-2026".

Zaawansowane wystąpienie seminaryjne (15 minut):

• Rola Operatora Systemu Dystrybucyjnego jako infrastruktury krytycznej (3 min): Odpowiedzialność strategiczna Pol-Energia, uzależnienie szpitali i pompowni od prądu, rygory NIS2 i Ustawy o zarządzaniu kryzysowym (Student 1).
• Diagnoza patologii dowódczych: "sztab-widmo", martwe telefony i brak sukcesji (4 min): Przedstawienie dowodów z przeterminowanej księgi BCP, uzależnienie od sieci GSM, brak oficera prasowego i prezentacja matrycy ryzyka 3x3 (Student 2).
• Karty niezgodności NC1/NC2/OFI oraz analiza 5 Why (4 min): Uzasadnienie naruszeń prawa, normy ISO 22301 oraz prezentacja przyczyny źródłowej w braku nadzoru korporacyjnego Rady Nadzorczej (Student 3).
• Plan Działań Korygujących (CAP) i model Incident Command System (4 min): Demonstracja działania schematu sukcesji ICS, terminali satelitarnych Iridium, procedury prostowania fake news oraz scenariusza ćwiczeń z RCB (cały zespół).

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

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

• Dlaczego w sytuacji kryzysu o charakterze katastrofalnym (np. przerwanie wałów i powódź stulecia) kolegialne zarządzanie spółką i tradycyjna hierarchia korporacyjna muszą zostać bezwzględnie zastąpione jednoosobowym łańcuchem dowodzenia (Incident Command System - ICS) z precyzyjnie określoną linią sukcesji stanowisk?
• W jaki sposób zaprojektować system łączności alarmowej dla Sztabu Kryzysowego i brygad pogotowia energetycznego, aby zapewnić niezawodną łączność głosową i przesyłanie danych telemetrycznych w sytuacji, gdy maszty publicznych operatorów GSM zostaną pozbawione zasilania lub zalane?
• W jaki sposób brak profesjonalnej polityki informacyjnej i oficera prasowego ds. kryzysowych prowadzi do powstawania fałszywych wiadomości (fake news) w mediach społecznościowych i jakie procedury przeciwdziałania dezinformacji powinien posiadać Operator Usługi Kluczowej?

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

• Tabela Matrycy Ryzyka 3x3:
  • Ryzyko 1: Porażenie prądem ratowników i ludności z powodu paraliżu dowodzenia pod nieobecność Prezesa -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Schemat sukcesji ICS z automatycznym przejęciem dowodzenia przez Wiceprezesa/Dyspozytora -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 2: Brak łączności ze sztabem z powodu awarii publicznych sieci GSM -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Wdrożenie sieci TETRA z zasilaniem 72h + terminale satelitarne Iridium dla sztabu -> P_rez=1, S_rez=3, R_rez=3.
  • Ryzyko 3: Wybuch paniki społecznej z powodu fake news o skażeniu i blackoutu -> P_inh=3, S_inh=2, R_inh=6 -> Kontrola: Dedykowany Oficer Prasowy, komunikaty co 60 minut i współpraca z Alert RCB -> P_rez=1, S_rez=2, R_rez=2.
  • Ryzyko 4: Kary administracyjne i odpowiedzialność karna Zarządu z Ustawy o KSC -> P_inh=3, S_inh=3, R_inh=9 -> Kontrola: Wdrożenie certyfikowanego BCMS wg ISO 22301 i ćwiczenia Tabletop -> 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 Dochodzenia Przyczyn Źródłowych metodą 5 Why dla zaniechania przeglądów BCP.
• Tabela Planu Działań Korygujących (CAP):
  • Zadanie CAP-1: Opracowanie i zatwierdzenie przez Radę Nadzorczą nowego Regulaminu Sztabu Kryzysowego opartego na modelu ICS z jednoznaczną linią sukcesji (Właściciel: Prezes Zarządu i Dyrektor Prawny, Termin: 21 dni, KPI: formalne pełnomocnictwa sukcesyjne, jednoosobowa decyzyjność).
  • Zadanie CAP-2: Zakup i konfiguracja 15 terminali satelitarnych Iridium Extreme PTT oraz modernizacja zasilania buforowego masztów sieci TETRA do 72h (Właściciel: Dyrektor Departamentu Teleinformatyki, Termin: 45 dni, KPI: 100% członków sztabu wyposażonych w terminale, test łączności satelitarnej).
  • Zadanie CAP-3: Wdrożenie wielokanałowego systemu masowego powiadamiania (IVR, SMS, PTT) zintegrowanego z bazą kadr i automatyczną weryfikacją potwierdzeń kodem PIN (Właściciel: Kierownik Sekcji Bezpieczeństwa Fizycznego, Termin: 30 dni, KPI: czas powiadomienia sztabu poniżej 15 minut, 100% potwierdzonych odbiorów).
  • Zadanie CAP-4: Przygotowanie i przeprowadzenie całodniowych ćwiczeń symulacyjnych typu Tabletop "Potop-2026" z udziałem Wojewody, PSP i RCB (Właściciel: Pełnomocnik ds. Zarządzania Kryzysowego, Termin: 60 dni, KPI: pełny raport poćwiczeniowy z wnioskami, ocena pozytywna obserwatorów RCB).
• Projekt Procedury Operacyjnej: "Regulamin Zarządzania Kryzysowego i Łańcucha Dowodzenia OSD-ICS-01: Procedura Zwoływania Sztabu, Sukcesja Stanowisk, Łączność Autonomiczna oraz Komunikacja Medialna w Stanach Klęski Żywiołowej".

C. Analiza zalet i wad proponowanego rozwiązania:

• Zalety: Natychmiastowa, jednoosobowa sprawność decyzyjna w sytuacjach zagrożenia życia; wyeliminowanie paraliżu prawnego i decyzyjnego dzięki precyzyjnej sukcesji; całkowita niezależność łączności od publicznych operatorów GSM dzięki terminalom Iridium i TETRA; skuteczna ochrona przed dezinformacją i paniką społeczną; pełna zgodność z dyrektywą NIS2 i wytycznymi RCB.
• Wady i trudności: Wysokie koszty zakupu i utrzymania abonamentów satelitarnych oraz infrastruktury TETRA; konieczność cyklicznego angażowania najwyższego kierownictwa spółki w wielogodzinne ćwiczenia symulacyjne.

• Ustawa z dnia 26 kwietnia 2007 r. o zarządzaniu kryzysowym (Dz.U. z 2023 r. poz. 122 z późn. zm.) - ochrona infrastruktury krytycznej i plany zarządzania kryzysowego.
• Ustawa z dnia 5 lipca 2018 r. o Krajowym Systemie Cyberbezpieczeństwa (Dz.U. z 2024 r. poz. 1077) - obowiązki podmiotów kluczowych i incydenty krytyczne.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (Dyrektywa NIS2) - sektor energetyczny.
• Norma PN-EN ISO 22301:2020: Bezpieczeństwo i odporność - Systemy zarządzania ciągłością działania - Wymagania (punkt 8.4 Gotowość i reagowanie na incydenty).
• Norma PN-EN ISO/IEC 27001:2022: Załącznik A - A.5.29 (Gotowość bezpieczeństwa informacji w czasie zakłóceń), A.5.30 (Gotowość ICT do ciągłości działania).
• Rządowe Centrum Bezpieczeństwa (RCB): "Krajowy Plan Zarządzania Kryzysowego - Zasady powiadamiania i reagowania w infrastrukturze krytycznej", Warszawa 2023.
• Federal Emergency Management Agency (FEMA): "Incident Command System (ICS) Review Document - ICS 100/200 Principles", Washington 2022.

• U2 Student bezbłędnie klasyfikuje uchybienia w procedurach dowódczych i planach BCP do kategorii NC1/NC2/OFI w świetle Ustawy o zarządzaniu kryzysowym i normy ISO 22301.
• U1 Student projektuje schemat łańcucha dowodzenia (ICS), regulamin pracy Sztabu Kryzysowego oraz scenariusz ćwiczeń symulacyjnych Tabletop.
• U3 Student wykonuje matrycową analizę ryzyka 3x3 dla zagrożeń paraliżu decyzyjnego, dezinformacji i powodzi w infrastrukturze krytycznej.
• U4 Student realizuje procedurę 5 Why i konstruuje Plan Działań Korygujących (CAP) spełniający standardy Rządowego Centrum Bezpieczeństwa.
• W1W2W3 Student wykazuje dogłębną znajomość Ustawy o zarządzaniu kryzysowym, dyrektywy NIS2, modelu FEMA ICS oraz normy ISO 22301.
• K1K2K3 Student przejawia postawę przywódczą, wysokie poczucie odpowiedzialności za bezpieczeństwo publiczne oraz etykę zawodową.