Laboratorium 1

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Podstawy kryptograficznej ochrony informacji. Warunki zapewnienia poufności i autentyczności informacji. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Asymetryczne algorytmy kryptograficzne i infrastruktura PKI.

Celem zadania jest zaprojektowanie, zaimplementowanie i formalna kryptoanaliza architektury uwierzytelniania odpornej na ataki klasy Adversary-in-the-Middle (AiTM / reverse-proxy phishing) dla krytycznego systemu e-administracji regionalnej. Studenci poznają matematyczne i algorytmiczne podstawy protokołu WebAuthn/FIDO2 (W3C / FIDO Alliance), opartego na kryptografii klucza publicznego (krzywa eliptyczna NIST P-256 / secp256r1 lub Ed25519) oraz kryptograficznym podpisie cyfrowym ECDSA z wiązaniem do tożsamości źródła (origin binding / RP ID).

W części praktycznej studenci implementują w języku Python skrypt weryfikujący asercje kryptograficzne WebAuthn (podpis pod strukturą clientDataJSON i authenticatorData) oraz konfigurują uwierzytelnianie wzajemne w warstwie transportowej (mutual TLS – mTLS) z wykorzystaniem certyfikatów klienta X.509 i narzędzia OpenSSL dla kont administracyjnych Tier 0. W części analitycznej zespół dowodzi matematycznie i protokolarnie, dlaczego kody jednorazowe SMS oraz tokeny TOTP (RFC 6238) poddają się atakom przekaźnikowym w czasie rzeczywistym (np. narzędzia Evilginx, Modlishka), podczas gdy kryptografia klucza publicznego z powiązaniem domenowym gwarantuje pełną niewrażliwość na ten wektor ataku.

Urząd Marszałkowski Województwa Małopolskiego uruchomił system Dziedziczenie Świadczeń (system DS), obsługujący rocznie setki tysięcy wniosków o świadczenia rodzinne, stypendia i dofinansowania dla osób z niepełnosprawnościami. W bazie danych przetwarzane są dane wrażliwe: numery kont bankowych, dokumentacja medyczna oraz numery PESEL. Dostęp do panelu administracyjnego posiada 60 pracowników i 5 administratorów infrastruktury.

W wyniku zaawansowanego testu penetracyjnego Red Team przeprowadził symulowaną kampanię spear-phishingową z wykorzystaniem serwera proxy AiTM (Evilginx), przechwytując hasła oraz jednorazowe kody TOTP pracowników w locie, co umożliwiło kradzież sesyjnych ciasteczek uwierzytelniających i obejście wdrożonego wcześniej mechanizmu 2FA. Incydent wykazał, że tradycyjne uwierzytelnianie dwuskładnikowe oparte na kodach symetrycznych nie chroni urzędu przed nowoczesnymi technikami phishingowymi.

Zespół laboratoryjny przyjmuje rolę architektów bezpieczeństwa i kryptologów. Zadaniem grupy jest wdrożenie bezwzględnego standardu uwierzytelniania odpornego na phishing (Phishing-Resistant MFA): wdrożenie asercji WebAuthn dla użytkowników oraz wzajemnego TLS (mTLS) dla bezpośredniego dostępu do bazy i API zarządczego, a także przygotowanie skryptu weryfikacyjnego i formalnego sprawozdania technicznego w ramach 180-minutowego bloku zajęć.

• Środowisko Linux (Debian, Ubuntu) z interpreterem Python 3 oraz biblioteką cryptography (instalowaną w środowisku wirtualnym venv)
• Pakiet narzędziowy OpenSSL do zarządzania kluczami asymetrycznymi, generowania lokalnego urzędu certyfikacji (Root CA) i wystawiania certyfikatów klienta X.509
• Klient curl z obsługą certyfikatów klienta (opcje --cert, --key, --cacert) do testowania sesji mTLS
• Przeglądarka internetowa z konsolą DevTools (inspekcja obiektów navigator.credentials) lub menedżer haseł KeePassXC z obsługą asercji FIDO2

1. Formalna kryptoanaliza podatności: analiza protokołu TOTP (RFC 6238, HMAC-SHA1) pod kątem podatności na przechwycenie przez serwer proxy AiTM w zestawieniu z protokołem WebAuthn/FIDO2.
2. Wygenerowanie asymetrycznej pary kluczy kryptograficznych na krzywej eliptycznej NIST P-256 (secp256r1) za pomocą biblioteki cryptography w języku Python.
3. Złożenie cyfrowego podpisu ECDSA pod asercją uwierzytelniającą, symulującą działanie tokena sprzętowego (podpis pod skrótem SHA-256 z danych wyzwania challenge i domeny origin).
4. Implementacja funkcji weryfikacji kryptograficznej po stronie serwera: weryfikacja podpisu cyfrowego kluczem publicznym oraz sprawdzenie poprawności identyfikatora relying party (RP ID).
5. Demonstracja odporności na atak AiTM: wykazanie w skrypcie, że asercja wygenerowana w fałszywej domenie phishingu (np. logowanie-malopolska.pl) zostanie natychmiast odrzucona przez serwer urzędowy (malopolska.pl).
6. Utworzenie lokalnego urzędu Root CA za pomocą narzędzia OpenSSL i wygenerowanie pary kluczy oraz certyfikatu klienta X.509 dla administratora bazy danych systemu świadczeń.
7. Konfiguracja i przetestowanie wzajemnego uwierzytelniania w warstwie transportowej (mTLS) za pomocą narzędzia curl z weryfikacją certyfikatu klienta.
8. Opracowanie zwięzłych rekomendacji techniczno-kryptograficznych dotyczących spełnienia wymogów ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC) i dyrektywy NIS2 w zakresie ochrony tożsamości cyfrowej.

Istota kryptograficznej odporności WebAuthn na phishing polega na tym, że przeglądarka internetowa (a nie użytkownik) generuje strukturę clientDataJSON zawierającą dokładny adres URL witryny (origin). Token podpisuje cyfrowo skrót SHA-256 z tych danych swoim prywatnym kluczem asymetrycznym. Nawet jeśli użytkownik zostanie zwabiony na fałszywą domenę proxy AiTM (np. malopolska-login.pl), token podpisze nazwę fałszywej domeny. Kiedy proxy przekaże podpis do prawdziwego serwera (malopolska.pl), serwer relying party natychmiast wykryje niezgodność skrótu origin i odrzuci próbę uwierzytelnienia.

Poniżej przedstawiono kompletny, weryfikowalny skrypt w języku Python demonstrujący mechanizm asymetrycznego podpisu i weryfikacji asercji WebAuthn na krzywej eliptycznej NIST P-256:

Utworzenie lokalnego Root CA i certyfikatu klienta X.509 do uwierzytelniania mutual TLS (mTLS) za pomocą narzędzia OpenSSL:

1. Matematyczny i protokolarny dowód odporności standardu WebAuthn/FIDO2 na ataki Adversary-in-the-Middle (AiTM) oparty na powiązaniu kryptograficznym z domeną (origin binding).
2. Rola asymetrycznych podpisów cyfrowych (ECDSA P-256) w eliminacji współdzielonych sekretów podatnych na wycieki po stronie serwera.
3. Zastosowanie wzajemnego uwierzytelniania w warstwie transportowej (mTLS X.509) w architekturze Zero Trust dla interfejsów zarządczych i komunikacji maszynowej (M2M).
4. Porównanie kosztów organizacyjnych, sprzętowych i ergonomicznych wdrażania kluczy FIDO2 w odniesieniu do potencjalnych strat z tytułu kompromitacji tożsamości.
5. Zgodność projektowanej architektury z wymaganiami ustawy o KSC oraz wytycznymi ENISA w zakresie ochrony tożsamości cyfrowej w administracji publicznej.

Wymagania dotyczące sprawozdania: Zespół przygotowuje profesjonalny raport inżyniersko-kryptologiczny PDF (objętość 5–6 stron) zawierający kod skryptu weryfikacyjnego, analizę kryptograficzną przechwytywania sesji, listingi poleceń OpenSSL/curl oraz wnioski końcowe.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony przed poszczególnymi rodzajami zagrożeń. Kon3 Symetryczne i niesymetryczne algorytmy szyfrowania. Podpisy cyfrowe i funkcje skrótu. Autoryzacja i uwierzytelnianie w systemach komputerowych.

Celem zadania jest zaprojektowanie i częściowe wdrożenie polityki zarządzania tożsamością cyfrową w średniej wielkości instytucji, która przeszła z kilku niezależnych katalogów użytkowników na jeden centralny katalog firmy. Zespół ma zbudować jedno miejsce przechowywania kont, grup i haseł, połączyć je z bramką logowania wspierającą logowanie jednokrotne (SSO) w aplikacjach, oraz opisać procesy zatwierdzania i odbierania uprawnień, które są dziś rozproszone między działami. Wymagania obejmują uwierzytelnianie dwuskładnikowe, automatyczne blokowanie konta po serii nieudanych prób, dostęp uprzywilejowany tylko na czas potrzebny (zasada Just-in-Time) i natychmiastowe odbieranie uprawnień po odejściu pracownika z instytucji.

Ważną częścią zadania jest sprawdzenie, jak tożsamość przechodzi między systemami. Studenci muszą zrozumieć różnicę między klasycznym protokołem SAML 2.0, w którym tożsamość przesyła się w postaci podpisanej dokumentu XML, a protokołem OpenID Connect, który działa na szczycie protokołu autoryzacji OAuth 2.0 i wystawia krótkotrwały token dostępu. Zespół ma prześledzić cały przepływ logowania krok po kroku, od wpisania hasła w przeglądarce, przez zapytanie do katalogu, po wydanie tokenu i wywołanie aplikacji, oraz wskazać miejsca, w których kradzież sesji jest najbardziej prawdopodobna. W sprawozdaniu trzeba udowodnić, że zastosowane rozwiązanie spełnia wymagania z wykładu Kon3 o autoryzacji i uwierzytelnianiu, a nie tylko uruchomione narzędzia.

Zadanie kończy się dokumentem procedur: instrukcją zakładania i blokowania konta, formularzem wniosku o dostęp uprzywilejowany, checklistą czynności wykonywanych przy zwolnieniu pracownika oraz propozycją przeglądu uprawnień raz na kwartał. Każdy z tych dokumentów musi wskazywać, kto zatwierdza, ile trwa zatwierdzenie i co się dzieje, gdy zatwierdzenia nie ma.

Politechnika Krakowska przyjęła w 2025 roku program wdrożenia centralnego zarządzania tożsamością. Wcześniej każdy system (system dziekancki, system biblioteczny, poczta, Moodle, katalog komputerowy w budynku C3) miał własną bazę haseł. Konsekwencją było to, że pracownik zmieniający hasło w jednym systemie utrzymywał stare hasło w trzech pozostałych, a studenci znali dziesiątki loginów różniących się od siebie jedną literą. Wydział informatyczny policzył, że 38 procent kont studenckich powstaje co roku od nowa, a zespół wsparcia dostaje najwięcej zgłoszeń o zapomniane hasła i o blokady konta, których przyczyną są powtarzane próby logowania.

W tym samym czasie uczelnia utrzymuje kilka aplikacji, które wymagają logowania jednokrotnego: system biblioteczny, system kwalifikacji na studia podyplomowe oraz portal pracowniczy. Wdrożenie logowania jednokrotnego zostało zatrzymane, ponieważ administratorzy nie wiedzą, jak połączyć katalog uczelni z bramką logowania, która obsługuje już logowanie przez PIONIER dla pracowników spoza uczelni. Brakuje też procedury dla kont serwisowych, czyli kont aplikacji i urządzeń, które nie mogą poprosić o kod jednorazowy i muszą działać bez interakcji użytkownika.

Kolejnym problemem jest dostęp uprzywilejowany. Konta administratorów systemów mają nierozłączne uprawnienia przez cały rok, choć ich używa się kilka godzin w miesiącu, a 70 procent z nich ma dodatkowo uprawnienia w katalogu, których nie potrzebuje. W 2025 roku jeden z operatorów serwera backupu, korzystając z współdzielonego konta administracyjnego, usunął katalog z rocznymi kopiami danych, po czym nie było wiadomo, kto wykonał operację, bo konto było wspólne dla trzech osób.

Grupa laboratoryjna dostaje środowisko do pracy: maszynę wirtualną Debian 11 z dwiema kartami sieciowymi oraz uruchomione kontenery z klientem usługi katalogowej FreeIPA i bramką logowania Keycloak. Zadaniem zespołu jest skonfigurowanie katalogu z przykładowymi kontami pracowników i studentów, dołączenie bramki logowania do katalogu, włączenie uwierzytelniania dwuskładnikowego metodą jednorazowego kodu (TOTP), przeprowadzenie testu logowania jednokrotnego w dwóch aplikacjach oraz zbudowanie procedury udzielania i odbierania uprawnień z podziałem obowiązków. Grupa ma także udokumentować, co się stanie z dostępem pracownika, który zmieni pracodawcę.

Wynikiem pracy jest komplet procedur, zrzuty ekranu i poleceń z każdego etapu oraz krótki opis przepływu logowania z rozdzieleniem zaufania na poszczególne systemy. Szczególnie ważne jest wyjaśnienie, gdzie w tym przepływie pojawia się hasło w postaci jawnej i dlaczego każdy z systemów powinien przechowywać jedynie informację o sposobie i dacie ważności, a nie samo hasło.

• Linux Debian 11 lub Ubuntu 22.04 w maszynie wirtualnej, najlepiej dwie karty sieciowe i dodatkowa pamięć dyskowa
• FreeIPA (ipa-server) - darmowy katalog użytkowników z uwierzytelnianiem Kerberos i LDAP, dostępny w repozytorium dystrybucji
• Keycloak (darmowy, licencja Apache 2.0) uruchomiony w kontenerze - bramka logowania z obsługą OIDC, SAML 2.0, MFA, scentralizowanymi sesjami i synchronizacją kont z katalogiem
• Moduły PAM: pam_pwquality, pam_faillock, pam_unix, pam_sss, pam_gnome_keyring (w standardowej dystrybucji)
• Narzędzia CLI: ipa, kinit, klist, ldapsearch, getent, passwd, chattr, loginctl, curl, openssl
• Aplikacje testowe do logowania jednokrotnego (na przykład dwie strony demonstracyjne lub Nextcloud w kontenerze)
• Edytor tekstu i LibreOffice Writer do procedur oraz dziennika zmian

1. Zainstaluj serwer katalogu FreeIPA i przeprowadź konfigurację początkową poleceniem ipa-server-install, nadając mu nazwę domenową, np. lab.uj.edu.pl. Zanotuj hasło administratora katalogu w bezpiecznym miejscu, poza dokumentacją laboratoryjną.
2. Utwórz grupy odpowiadające strukturze uczelni: studenci, doktoranci, pracownicy, administracja, kadra. Grupy pozwalają przypisać uprawnienia raz i nie tworzyć listy uprawnień dla każdego użytkownika osobno.
3. Załóż konta testowe: jeden pracownik administracji, jeden zwykły pracownik, jeden doktorant, jeden student, jedno konto serwisowe. Dla konta serwisowego wyjaśnij, dlaczego nie może mieć interaktywnego logowania i jakie są dobre praktyki dla haseł maszynowych.
4. Ustaw politykę haseł w katalogu: minimalna długość 14 znaków, wymaganie złożoności, brak wymuszanej rotacji co 30 dni. Uzasadnij decyzję o rezygnacji z cyklicznej rotacji, powołując się na zalecenia NIST SP 800-63B.
5. Włącz automatyczne blokowanie konta w module PAM pam_faillock: pięć nieudanych prób, blokada na 15 minut, zapis licznika w /var/log/faillock. Zmierz własnym poleceniem, ile czasu trwa odblokowanie.
6. Uruchom Keycloak w kontenerze, utwórz domenę (realm) i połącz ją z FreeIPA jako źródłem użytkowników. W logu importu sprawdź, czy grupy z katalogu zostały przeniesione do Keycloak.
7. Skonfiguruj w Keycloak klienta OIDC typu public (aplikacja bez własnego poufnego klucza) dla aplikacji demonstracyjnej. Zapisz identyfikator klienta i zarejestruj adresy przekierowań, bo to najczęstsza przyczyna błędu pętli przekierowań. W zakładce Authentication włącz Direct Access Grants, żeby dało się pobrać token poleceniem curl, i zanotuj w sprawozdaniu, że jest to tryb zastępczy, a nie standard produkcyjny.
8. Dodaj klienta SAML 2.0 dla drugiej aplikacji, zaimportuj metadane i zapisz identyfikator encji (entityID). Dla uczelni wyjaśnij, kiedy wybiera się SAML, a kiedy OpenID Connect: starsze systemy instytucjonalne częściej używają SAML, nowsze aplikacje zwykle OIDC.
9. Włącz uwierzytelnianie dwuskładnikowe typu OTP i przetestuj cały scenariusz logowania w przeglądarce oraz wierszu poleceń poleceniem curl, który pobiera token z punktu końcowego tokenu.
10. Przetestuj scenariusze negatywne: błędne hasło, niepełny kod jednorazowy, brak dostępu do telefonu, wygaśnięty kod, zbyt wiele prób. Dla każdego scenariusza zapisz komunikat widoczny dla użytkownika i wpis w dzienniku serwera.
11. Sprawdź, co dzieje się w sesji: wygaśnij token, sprawdź czas życia tokenu dostępu i tokenu odświeżania, zdecyduj, jakie wartości są rozsądne i dlaczego zbyt długi czas życia tokenu odświeżania zwiększa ryzyko.
12. Zaprojektuj proces udzielania dostępu uprzywilejowanego: wniosek, zatwierdzenie przez dwie osoby (właściciel procesu i przełożony), automatyczne nadanie uprawnienia na 60 minut, automatyczne cofnięcie i zapis w dzienniku. Opisz, kto może zatwierdzić własny wniosek, i wyjaśnij dlaczego to niedopuszczalne.
13. Zaprojektuj procedurę odejścia pracownika: blokada konta w katalogu, cofnięcie wszystkich grup, przegląd i unieważnienie sesji oraz tokenów, przeniesienie dokumentów, zwrot sprzętu, wyczyszczenie konta serwisowego powiązanego z kontem pracownika.
14. Pokaz brak centralnego zarządzania na przykładzie: opisz, ile baz haseł istniało przed wdrożeniem i jakie ryzyko powodujełaby utrata jednej z nich. Warto tu wrócić do definicji ryzyka i zagrożenia z wykładu Kon1.
15. Przeprowadź kwartalny przegląd uprawnień: wyeksportuj listę członków grup, oznacz konta nieużywane od 60 dni i konta z uprawnieniami sprzecznymi z zakresem obowiązków. Zapisz wynik jako raport z rekomendacjami.
16. Przygotuj diagram przepływu logowania z rozdzieleniem trzech stref zaufania: przeglądarka użytkownika, bramka logowania i aplikacja docelowa. Zaznacz na nim, gdzie pojawia się hasło, gdzie token, a gdzie identyfikator sesji.
17. W sprawozdaniu opisz, gdzie w konfiguracji Keycloak ustawiono czas życia sesji, jak skonfigurowano wymuszenie MFA dla roli administratora i jak wygląda procedura odzyskania dostępu (kto zatwierdza, jak długo trwa, jakie logi powstają).

Najczęstszym problemem przy pierwszym uruchomieniu jest to, że przeglądarka przekierowuje użytkownika z bramki logowania z powrotem do aplikacji w nieskończoność. Dzieje się tak, gdy adres przekierowania w konfiguracji klienta OIDC nie zgadza się z adresem, pod którym otwarto aplikację, najczęściej przez różnicę między adresem localhost a adresem IP maszyny wirtualnej. Sprawdź adres w pasku przeglądarki i popraw go w konfiguracji klienta, a nie w kodzie aplikacji. FreeIPA przechowuje hasła w sposób uniemożliwiający ich odczytanie przez administratora katalogu, w tym przez administratora serwera. Warto to pokazać w sprawozdaniu, bo obiecuje, że hasło właściciela konta nie jest przechowywane w bazie. Sprawdzenie polega na poleceniu wyszukania atrybutu hasła dla dowolnego użytkownika, które zakończy się komunikatem o braku dostępu do atrybutu.

Weryfikacja tożsamości użytkownika po stronie klienta odbywa się w systemie przez Kerberos. Bilet użytkownika ma określony czas życia, a w pamięci podręcznej pozostaje dopóki nie zostanie unieważniony lub nie wygaśnie, dlatego polecenie listujące bilety pokazuje, czy sesja jest jeszcze aktywna.

Dobrym ćwiczeniem jest pobranie tokenu z bramki logowania wierszem poleceń, bo pokazuje, że aplikacja nie musi wiedzieć o haśle użytkownika. Odpowiedź zawiera token dostępu, który w praktyce jest krótkotrwały, oraz token odświeżania, który przechowuje się w bezpiecznym miejscu po stronie klienta uwierzytelniającego. Blokada po nieudanych próbach logowania jest realizowana lokalnie w systemie operacyjnym, a nie w katalogu, dlatego parametry ustawia się w konfiguracji PAM, a stan sprawdza się osobnym poleceniem modułu pam_faillock.

Wreszcie kilka zapytań kontrolnych, które warto wykonać przed oddaniem sprawozdania. Sprawdzają, czy uprawnienia nie rozrosły się poza granice grupy, czy nie ma kont bez właściciela i czy ktoś nie ma uprawnień administracyjnych bez wymaganego uzasadnienia. Polityka zarządzania tożsamością bez przeglądu logów jest polityką deklaratywną. Warto pokazać w sprawozdaniu, jak w kilku poleceniach znaleźć w logach nieudane próby logowania, logowania z nieznanych adresów oraz przypadki użycia kont uprzywilejowanych. System rejestruje te zdarzenia w dzienniku systemowym, a katalog uwierzytelniający dodatkowo w pliku dziennika audytu.

W sprawozdaniu nie zapominajcie o jednym, często pomijanym wątku: hasło użytkownika nie powinno nigdy opuszczać jego przeglądarki w postaci jawnej ani nie powinno być przechowywane przez aplikację docelową. Najlepsza polityka to taka, w której aplikacja widzi tylko token, a hasło zna wyłącznie serwer uwierzytelniania. Ta zasada wynika wprost z warunków zapewnienia poufności i autentyczności informacji omawianych na wykładzie Kon2.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Architektura federacyjna tożsamości: integracja baz LDAP/FreeIPA z brokerem uwierzytelniania Keycloak jako centralnym Identity Providerem.
2. Porównanie protokołów federacyjnych OpenID Connect (OIDC / OAuth 2.0) oraz SAML 2.0 w integracji zróżnicowanych systemów uczelnianych.
3. Wdrożenie adaptacyjnego uwierzytelniania wieloskładnikowego (MFA) z wykorzystaniem aplikacji TOTP oraz sprzętowych kluczy FIDO2.
4. Realizacja koncepcji dostępu uprzywilejowanego na żądanie (Just-in-Time Access) i automatycznego wygaszania uprawnień administracyjnych.
5. Zasady bezpiecznego zarządzania cyklem życia kont studenckich i pracowniczych (Joiners-Movers-Leavers) z pełnym audytem w FreeIPA.
6. Spełnienie wymogów międzynarodowych federacji tożsamości naukowej oraz zaleceń KRI w zakresie centralizacji logowania.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie centralnego brokera tożsamości Keycloak zintegrowanego z katalogiem FreeIPA całkowicie wyeliminowało problem fragmentacji haseł i niespójności uprawnień w systemach uczelnianych. Zastosowanie protokołu OpenID Connect z bibliotekami PKCE zapewniło bezpieczne logowanie jednokrotne do platformy e-learningowej i systemu dziekanatu bez przekazywania poświadczeń użytkowników do aplikacji docelowych. Wymuszenie drugiego składnika uwierzytelnienia dla personelu akademickiego zredukowało ryzyko przejęcia kont profesorskich w wyniku phishingu do zera. Zaimplementowanie mechanizmu dostępu uprzywilejowanego Just-in-Time uniemożliwiło administratorom stałe posiadanie uprawnień roota w podsieciach laboratoryjnych, przydzielając je wyłącznie na czas zgłoszonego okna serwisowego. Wdrożona architektura tożsamości stanowi fundament cyberbezpieczeństwa uczelni i spełnia wymogi Krajowych Ram Interoperacyjności.

Kon2 Podstawy kryptograficznej ochrony informacji. Warunki zapewnienia poufności i autentyczności informacji. Kon3 Symetryczne i niesymetryczne algorytmy szyfrowania. Podpisy cyfrowe i funkcje skrótu. Kon5 Szyfrowanie konwencjonalne; model i klasyczne techniki szyfrowania. Kon6 Algorytmy kryptograficzne.

Celem zadania jest opracowanie klasyfikacji informacji oraz polityki zarządzania kluczami szyfrującymi dla kancelarii notarialnej, w której dokumenty papierowe i elektroniczne powstają, są skanowane, podpisywane i przechowywane przez wiele lat. Zespół musi zdecydować, które kategorie informacji wymagają szyfrowania, jakim kluczem i jak długo klucz ma być przechowywany, zanim zostanie zniszczony. Drugą częścią zadania jest praktyczne zbudowanie kontenera szyfrowanego w standardzie LUKS2 z kilkoma miejscami na klucze, ponieważ pokazuje to, że szyfrowanie dysku i zarządzanie kluczami to dwa osobne problemy: nośnik można zaszyfrować, ale jeśli zgubimy wszystkie klucze, to dane zostaną bezpowrotnie utracone.

Studenci muszą rozróżnić szyfrowanie symetryczne (jednym kluczem w obie strony, szybkie, używane do dużej ilości danych) od szyfrowania asymetrycznego (para kluczy, jeden publiczny i jeden prywatny, używana do wymiany kluczy i podpisów cyfrowych) oraz wyjaśnić rolę funkcji skrótu, która nie szyfruje, a jedynie oblicza skrót danych służący do wykrycia ich zmiany. Zespół ma też zastosować te pojęcia do konkretnych plików: skan akt, wykaz akt, korespondencja z klientem, kopia zapasowa, nośnik wymienny, a następnie opisać, gdzie klucz może się znaleźć i co się stanie, gdy zniknie.

Efektem pracy jest dokument polityki z tabelą klasyfikacji, działający kontener LUKS2 z zapisanymi miejscami na klucze, zestaw zaszyfrowanych plików z kluczami GnuPG, procedura rotacji i zniszczenia kluczy oraz instrukcja odzyskiwania danych, która zadziała także wtedy, gdy pracownik, który pamiętał hasło, odejdzie z kancelarii. Zespół ma przy tym wykazać, że zabezpieczenie kryptograficzne jest jedynie częścią polityki i samo w sobie nie wystarczy, bo dostęp do danych może uzyskać osoba mająca poprawny klucz, ale nieuprawniona do określonego aktu.

Kancelaria notarialna w Krakowie obsługuje rocznie około tysiąca spraw: sprzedaż mieszkań, spółki z ograniczoną odpowiedzialnością, testamenty, pełnomocnictwa i umowy majątkowe małżeńskie. Każda sprawa ma własną teczkę aktową, w której znajdują się oryginały dokumentów, wypisy, wnioski stron i protokoły. Akta notarialne są dokumentami urzędowymi, więc osoby trzecie mają do nich prawo wglądu, ale teczki zawierają też dane osobowe stron: numery PESEL, adresy, dane o nieruchomościach, informacje o rodzinie i często o stanie zdrowia. Kancelaria zatrudnia czterech notariuszy, dwie sekretarki i jednego pracownika administracyjnego, a dokumenty skanuje do wspólnego dysku sieciowego.

Audyt przeprowadzony w kancelarii ujawnił cztery istotne uchybienia. Po pierwsze, dysk z zeskanowanymi aktami nie był zaszyfrowany, a w razie awarii sprzętu wszystkie dokumenty trafiały do serwisu, który wywlekał je w trakcie naprawy. Po drugie, kopie zapasowe robiono na zewnętrznym dysku USB, który leżał w szufladzie biurka i był przenoszony do domu przez pracownika bez żadnego szyfrowania. Po trzecie, hasło do konta na serwerze plików brzmiało „Kancelaria2026” i było zapisane na karteczce przy monitorze. Po czwarte, pracownik, który odszedł z kancelarii, zabrał swojego pendrive'a, a w nim znajdowały się wyeksportowane wykazy akt z ostatnich dwóch lat.

Grupa laboratoryjna dostaje trzy elementy środowiska: obraz pliku o rozmiarze 200 MB, który ma pełnić rolę dysku z dokumentami, zestaw przykładowych plików (skany akt, wykaz akt, korespondencja) oraz drugi nośnik, na którym trzeba przygotować zaszyfrowaną kopię. Zadaniem zespołu jest zaprojektować czteropoziomową klasyfikację informacji, przypisać do każdej kategorii stosowane zabezpieczenia kryptograficzne, a następnie te zabezpieczenia faktycznie zastosować. Trzeba też przygotować zestaw kluczy, który pozwoli zaszyfrować plik, wymienić go z osobą trzecią i później odzyskać, oraz udokumentować, gdzie leży kopia każdego klucza i kto ma do niej dostęp.

Ważna część zadania dotyczy sytuacji kryzysowych. Zespół musi zaplanować, co się stanie, gdy: zgubi się hasło do kontenera, odejdzie pracownik znający hasło, padnie dysk z kluczami, a także gdy trzeba będzie przekazać zaszyfrowane archiwum osobie trzeciej. Dla każdego z tych przypadków trzeba napisać procedurę z wyznaczoną osobą odpowiedzialną i terminem, a także określić, co się dzieje z danymi, których nie da się już odzyskać. Na koniec grupa przygotuje krótką instrukcję dla notariusza i sekretarki opisującą, gdzie trzymać kopie kluczy i dlaczego nie wolno przechowywać ich na tym samym dysku co zaszyfrowane dane.

• Linux Debian 11 lub Ubuntu 22.04 z pakietami cryptsetup (LUKS2), gpg (GnuPG), openssl, coreutils, pv i rsync
• Narzędzie age - prosty program do szyfrowania plików z kluczami (projekt darmowy, licencja Apache 2.0)
• HashiCorp Vault - darmowy do celów edukacyjnych menedżer sekretów (licencja BSL 1.1), opcjonalnie
• LibreOffice Calc do prowadzenia tabeli klasyfikacji informacji i wykazu kluczy
• Edytor tekstu do polityki i procedur, narzędzie sha256sum, gpg, cryptsetup, blkid, lsblk
• Do oceny jakości klucza: program entropy, zliczanie znaków i długości fraz, wskaźnik entropii z dokumentacji programu pwscore
• Darmowe materiały referencyjne: dokumentacja cryptsetup, normy ISO/IEC 27001:2022 (kontrola 5.12 klasyfikacja informacji, 5.17 uwierzytelnianie, 5.24-5.28 zarządzanie incydentami) w wersji skróconej publikowanej przez NASK

1. Zróbcie inwentaryzację informacji w kancelarii: lista typów dokumentów, gdzie są przechowywane (papier, dysk, kopia zapasowa, nośnik przenośny), kto ma do nich dostęp i jak długo są przechowywane. Dopiero na tej podstawie można ustalić klasyfikację, bo klasyfikuje się konkretne zbiory danych, a nie ogólne kategorie.
2. Zaprojektujcie czteropoziomową klasyfikację informacji zgodnie z powszechnie stosowanym wzorem: publiczna, wewnętrzna, poufna, ściśle poufna. Dla kancelarii uzasadnijcie, czy akta notarialne należą do kategorii poufnej czy ściśle poufnej, biorąc pod uwagę, że akta są dokumentem urzędowym, a równocześnie zawierają dane osobowe stron.
3. Dla każdej klasy ustalcie cztery kolumny: gdzie jest przechowywana, kto ma dostęp, jakie zabezpieczenie techniczne obowiązuje (szyfrowanie w spoczynku, w tranzycie, kontrola dostępu) i jak długo jest przechowywana.
4. Wybierzcie szyfrowanie dla każdej kategorii i zapiszcie parametry: rodzaj szyfru (symetryczny lub asymetryczny), algorytm i rozmiar klucza, sposób wymiany klucza oraz sposób przechowywania klucza. Użyjcie wartości, które da się obronić: na przykład AES-256 z kluczem 256-bitowym albo krzywą eliptyczą X25519 dla wymiany klucza.
5. Wróćcie do wykładu Kon5 i Kon6 i wyjaśnijcie w sprawozdaniu różnicę między szyfrowaniem symetrycznym a asymetrycznym oraz dlaczego w praktyce stosuje się ich połączenie: szyfrowanie dużej ilości danych szyfrem symetrycznym, a klucz symetryczny chroniony kluczem publicznym odbiorcy.
6. Utwórzcie plik obrazu dysku i sformatujcie go jako kontener LUKS2 z etykietą, silną frazą hasłową i podniesioną liczbą iteracji funkcji wyprowadzania klucza. Odczytajcie nagłówek kontenera i zapiszcie w sprawozdaniu jego parametry.
7. Dodajcie do kontenera trzy miejsca na klucze: hasło użytkownika, losowy plik klucza przechowywany na osobnym nośniku oraz klucz zapasowy dla właściciela kancelarii. Sprawdźcie, ile miejsc na klucze istnieje i czy każde z nich działa.
8. Utwórzcie system plików wewnątrz kontenera, zamontujcie go i skopiujcie przykładowe dokumenty. Zmierzcie, ile zajmują, i porównajcie z rozmiarem plików przed szyfrowaniem.
9. Wygenerujcie parę kluczy GnuPG dla osoby fizycznej i sprawdźcie, jakie klucze powstały (prywatny, publiczny, podskrót autentykacji). Wyeksportujcie klucz publiczny do pliku, który przekażecie w sprawozdaniu jako załącznik.
10. Zaszyfrujcie każdy rodzaj pliku do osobnego pliku wynikowego, a potem go odszyfrujcie i porównajciec sumy kontrolne pliku pierwotnego i po odszyfrowaniu. Zapiszcie w sprawozdaniu, że deszczurowanie działa, wraz z rzeczywistymi sumami SHA-256.
11. Zaprojektujcie i przetestujcie rotację klucza: dodajcie nowe hasło do kontenera LUKS2, przetestujcie logowanie nowym hasłem, usuńcie stare hasło poleceniem cryptsetup i sprawdźcie, czy stare hasło już nie działa.
12. Zróbcie kopię zapasową nagłówka kontenera LUKS2 na osobny nośnik i przeprowadźcie symulację odtworzenia: usuńcie nagłówek z kopii obrazu, przywróćcie go i sprawdźcie, czy pliki dają się odczytać. Opiszcie, kiedy taka kopia jest ratunkiem, a kiedy zagrożeniem.
13. Przygotujcie klucz zapasowy dla osoby trzeciej w postaci zaszyfrowanej frazą, którą zna wyłącznie kierownik kancelarii, i zapiszcie procedurę wydania tego klucza w trybie awaryjnym (kto, kiedy, po czyim potwierdzeniu).
14. Opiszcie, co robić z kluczami pracownika, który odszedł: czy unieważnić klucz publiczny, czy usunąć hasło z kontenera, jak postępować z kluczami GnuPG oraz kiedy można usunąć dane zaszyfrowane tym kluczem.
15. Ustalcie harmonogram niszczenia kluczy na podstawie okresu przechowywania dokumentów i zapiszcie, kto zatwierdza zniszczenie klucza prywatnego, jak fizycznie je niszczyć i jak udokumentować samo zniszczenie.
16. Opracujcie tabelę wyeksportowaną z kluczy i kontenerów: identyfikator, rodzaj klucza, zastosowanie, data utworzenia, data planowanego zniszczenia, kopia zapasowa, osoba odpowiedzialna. Tabela ma żyć osobno od dokumentów z danymi.
17. W sprawozdaniu wyjaśnijcie, dlaczego funkcja skrótu nie jest szyfrowaniem, do czego służy w tym zadaniu i jakie ma ograniczenia (atak siłowy, złe parametry, brak poufności). Podajcie przykład zastosowania sumy kontrolnej w protokole przekazywania akt.

Technologia LUKS2 nie jest sama w sobie szyfrowaniem danych, tylko standardowym sposobem przechowywania nagłówka z zaszyfrowanymi kluczami w pierwszych megabajtach nośnika. Dzięki temu na jednym dysku może istnieć kilka niezależnych haseł (miejsc na klucze), a system operacyjny widzi zwykły system plików dopiero po podaniu jednego z nich. Warto pokazać w sprawozdaniu, jak wygląda nagłówek i dlaczego jego kopia jest tak ważna: nagłówek przechowuje nie tylko zaszyfrowane klucze, ale też sól, parametry funkcji wyprowadzania klucza i identyfikator kontenera, bez których otwarcie kontenera jest niemożliwe.

Dodawanie kolejnych miejsc na klucze wygląda podobnie, a liczbę miejsc widać w nagłówku. Losowy plik klucza musi mieć prawa tylko do odczytu dla właściciela i nie może leżeć na tym samym nośniku co dane, które chroni. Kolejność poleceń ma znaczenie i jest dobrym tematem na obronę: dopóki system plików jest zamontowany, nie da się zamknąć kontenera, bo system plików wciąż korzysta z urządzenia. Błąd, który popełnia większość studentów za pierwszym razem, brzmi właśnie „Device is still in use”.

Rotacja hasła w kontenerze wygląda tak: najpierw dodajemy nowe hasło, sprawdzamy, czy działa, a dopiero potem usuwamy stare. Gdybyśmy usunęli stare hasło przed sprawdzeniem nowego, moglibyśmy stracić dostęp do danych.

Kopia nagłówka kontenera jest najtańszym zabezpieczeniem przed sytuacją, w której pierwsze kilkaset kilobajtów nośnika zostanie uszkodzonych. Kopię trzymamy na osobnym nośniku, a przywracanie można sprawdzić eksperymentalnie. Na poziomie pojedynczych plików najprościej użyć GnuPG. Klucz publiczny osoby, dla której chcemy zaszyfrować plik, musi znać odbiorca, a klucz prywatny zostaje u nadawcy i nigdy nie opiera się na przesyłaniu go pocztą.

Wreszcie zadanie dla tych, którzy chcą użyć prostszego narzędzia: age szyfruje plik jednym poleceniem, bez rozbudowanej konfiguracji, a plik klucza ma czytelną postać tekstową, którą można wydrukować i zarchiwizować w sejfie. Sprawdźcie w sprawozdaniu, czy wiekowość pliku klucza i sposób jego przechowywania spełniają waszą własną politykę.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Opracowanie trójstopniowego schematu klasyfikacji informacji w zgodzie z prawem o notariacie oraz wytycznymi rozporządzenia RODO.
2. Implementacja pełnego szyfrowania wolumenów archiwalnych LUKS2 z wykorzystaniem algorytmu Argon2id jako odpornego na GPU mechanizmu KDF.
3. Bezpieczne szyfrowanie korespondencji z sądami i księgami wieczystymi za pomocą GnuPG z dedykowanymi podkluczami szyfrującymi.
4. Architektura bezpiecznego escrow i kopii zapasowych kluczy prywatnych z wykorzystaniem podziału sekretu Shamira lub sprzętowych kart kryptograficznych.
5. Procedura cyklicznej rotacji kluczy kryptograficznych i unieważniania certyfikatów bez utraty dostępu do historycznych akt notarialnych.
6. Odpowiedzialność dyscyplinarna i karna notariusza za naruszenie tajemnicy zawodowej a standardy techniczne normy ISO/IEC 27001.

Przykładowe wnioski (wzór do sprawozdania): Zastosowanie restrykcyjnej matrycy klasyfikacji akt w kancelarii notarialnej pozwoliło na precyzyjne odizolowanie danych objętych bezwzględną tajemnicą notarialną od bieżącej korespondencji biurowej. Wdrożenie kontenerów LUKS2 z nowoczesną funkcją wyprowadzania klucza Argon2id skutecznie zabezpieczyło archiwalne rejestry ksiąg wieczystych przed atakami kryptoanalitycznymi w przypadku fizycznej kradzieży dysków. Wykorzystanie oprogramowania GnuPG z kluczami generowanymi na sprzętowych tokenach kryptograficznych wyeliminowało ryzyko wycieku kluczy prywatnych do pamięci RAM stacji roboczych. Opracowana procedura bezpiecznego depozytu kluczy odzyskiwania z wykorzystaniem podziału sekretu uniemożliwiła otwarcie zaszyfrowanych archiwów przez pojedynczego pracownika bez wiedzy notariusza. Wprowadzone zabezpieczenia techniczne gwarantują pełną zgodność z art. 18 Prawa o notariacie oraz wymogami rozporządzenia RODO w zakresie ochrony tajemnic prawnie chronionych.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony przed poszczególnymi rodzajami zagrożeń. Kon2 Podstawy kryptograficznej ochrony informacji. Warunki zapewnienia poufności i autentyczności informacji.

Celem zadania jest zaprojektowanie i przetestowanie polityki segmentacji sieciowej w zakładzie przetwórstwa żywności, w którym produkcyjna sieć komputerowa sterująca urządzeniami linii technologicznej sąsiaduje z siecią biurową, siecią serwerową i dostępem zdalnym dla serwisu producenta. Zespół ma pokazać, dlaczego samo zezwolenie na ruch między sieciami jest groźne, oraz zbudować rozwiązanie oparte na strefach, w którym ruch jest domyślnie zabroniony, a zezwolenia są wymienione pojedynczo i z uzasadnieniem. Zadanie jest praktyczne: reguły zapory muszą zostać wczytane do routera i zapory systemowej oraz sprawdzone skanerem, a nie tylko opisane na kartce.

Studenci muszą rozróżnić segmentację opartą na okablowaniu lub wirtualnych sieciach lokalnych (VLAN) od mikrosegmentacji opartej na tożsamości urządzeń, oraz wyjaśnić, dlaczego proste oddzielenie strefy przemysłowej od biurowej nie wystarcza, skoro do strefy przemysłowej nadal łączą się serwery i stacje serwisowe. Zespół ma zaprojektować strefę zdemilitarizowaną dla usług dostawcy, zasady dostępu czasowego dla zdalnego serwisu oraz reguły, które pozwalają monitorować ruch zamiast go po cichu blokować. Każda reguła musi mieć komentarz wyjaśniający jej cel, bo reguła bez uzasadnienia jest problemem utrzymaniowym i zwykle zostaje usunięta przy pierwszej awarii.

Część praktyczna obejmuje skonfigurowanie szyfrowanego tunelu WireGuard między stacją administracyjną a routerem, tak aby zdalny dostęp nie korzystał z otwartego punktu dostępu w sieci produkcyjnej. Zespół ma także przetestować faktyczną szczelność rozwiązania narzędziem Nmap, udokumentować wyniki przed i po zmianie reguł oraz wskazać, który z wyników pokazuje, że sieć jest podzielona. W sprawozdaniu trzeba opisać model stref i uzasadnić go z punktu widzenia poufności i autentyczności informacji przesyłanej między strefami.

Zakład przetwórstwa mięsa w Małopolsce zatrudnia 180 pracowników i prowadzi dwie linie technologiczne: linię dojrzewania mięsa w komorach chłodniczych oraz linię pakowania. Linie są sterowane sterownikami programowalnymi, do których podłączone są czujniki temperatury, wilgotności i wagi, a nadzór nad nimi prowadzi stacja operacyjna w hali produkcyjnej. W hali jest też druga sieć bezprzewodowa obsługująca skanery kodów i terminale magazynowe. W pomieszczeniu zakładu znajduje się serwer, na którym działa system planowania produkcji i system zarządzania jakością, a w gabinecie kierownika działu technicznego dwa komputery z dostępem do internetu.

W 2025 roku serwis producenta sterowników zgłosił, że podczas zdalnej pomocy technicznej musiał tymczasowo włączyć na swoim laptopie zdalny dostęp do sterownika linii pakowania. Zespół informatyczny zakładu kupił na ten cel osobny router, który był podłączony do sieci biurowej, a przez niego można było dotrzeć do wszystkich urządzeń w hali, w tym do sterowników procesu. W tym samym roku jeden z pracowników podłączył do gniazda w hali produkcyjnej własny router domowy, żeby mieć zasięg sieci bezprzewodowej w socjalarni, nie informując nikogo. Zdarzenia te nie spowodowały awarii, ale pokazały, że sieć zakładu jest jedną płaską domeną, w której każde urządzenie widzi każde inne urządzenie.

Grupa laboratoryjna otrzymuje środowisko z trzema routerami RouterOS w wersji CHR, dwoma maszynami Debian z zainstalowaną zaporą nftables oraz dwoma hostami testowymi udającymi sterowniki. Zadaniem zespołu jest podzielić środowisko na cztery strefy: produkcyjną (sterowniki i stacje operatorskie), serwerową (system planowania i jakości), biurową (komputery kierowników i księgowości) oraz strefę serwisu (dostęp czasowy dostawcy przez szyfrowany tunel). Zespół musi przyjąć zasadę domyślnego blokowania ruchu między strefami, zdefiniować wyjątki, które są rzeczywiście potrzebne, i każdy z nich uzasadnić jednym zdaniem.

Następnie trzeba skonfigurować i sprawdzić rozwiązanie: skanem portów z każdej strefy, zapisem ruchu na brzegu zapór oraz testem tunelu WireGuard dla dostępu zdalnego. Wreszcie zespół ma przygotować krótką instrukcję dla pracowników zakładu o tym, co wolno podłączać do sieci produkcyjnej, oraz procedurę podłączenia nowego urządzenia, która nie pozwala włączyć go do sieci bez wpisu w ewidencji i bez zatwierdzenia przez kierownika zmiany.

• RouterOS CHR w wersji 7.x na maszynach wirtualnych (darmowa licencja P1, ograniczenie przepustowości do 1 Mb/s, wystarczające do laboratorium)
• Linux Debian 11 lub Ubuntu 22.04 z nftables (pakiet nftables) albo iptables
• WireGuard (pakiet wireguard-tools) do zdalnego dostępu
• Nmap do weryfikacji szczelności i rozpoznawania usług
• Wireshark lub tcpdump do analizy ruchu na brzegu stref
• Edytor tekstu i terminal do zapisu reguł oraz ich wersji
• Do dokumentacji: model stref i macierz przepływów (kto z kim może rozmawiać i dlaczego)

1. Narysujcie obecny układ sieci zakładu: które urządzenia gdzie podłączone, które adresy, gdzie routery, które porty są otwarte do internetu. Bez rysunku nie da się zaprojektować segmentacji, bo nie wiadomo, gdzie dziś przechodzi ruch.
2. Zróbcie inwentaryzację usług: dla każdego hosta zapiszcie adres, system operacyjny, uruchomione usługi i kto ma utrzymywać ten host. Narzędziem jest skan portów w obrębie laboratorium, a dla dokumentacji zapasowego wykazu usług.
3. Zdefiniujcie strefy i zasadę domyślnie zabronionego ruchu. Zapiszcie, które strefy muszą się widzieć (na przykład stacja operatorska ze sterownikiem swojej linii), a które nie mogą (księgowość ze sterownikiem).
4. Przygotujcie macierz przepływów: wiersz to źródło, kolumna to cel, w komórce wpisane dozwolone porty i protokoły albo zakaz. Każda dozwolona komórka musi mieć uzasadnienie, a pusta oznacza zakaz.
5. Zdecydujcie, które strefy mają dostęp do internetu, a które nie. Uzasadnijcie wybór i zapiszcie, jakie usługi wymagają dostępu do internetu (aktualizacje, logowanie do usługi producenta).
6. Skonfigurujcie router RouterOS: interfejsy w poszczególnych strefach, listy adresów (listy adresów ułatwiają późniejsze zmiany) i reguły zapory w łańcuchach wejściowym, wyjściowym i przechodzącym. Każdą regułę opatrzcie komentarzem opisującym powód.
7. Wprowadźcie w systemie Linux reguły domyślnie zabraniające ruchu przychodzącego w strefie serwerowej, a następnie dodajcie tylko te wyjątki, które są potrzebne. Reguły zapiszcie w pliku konfiguracyjnym, żeby można je było wersjonować.
8. Skonfigurujcie tunel WireGuard między stacją administracyjną a routerem tak, aby zdalny serwisy nie łączył się z siecią produkcyjną w sposób ogólny, lecz tylko do jednego wybranego hosta. Skonfigurujcie wygaszanie nieaktywnego tunelu, żeby nieużywany dostęp nie zostawał otwarty.
9. Zaplanujcie dostęp czasowy dla serwisu: reguła zapory z warunkiem czasu albo automatyczne wyłączenie reguły po określicie. Wyjaśnijcie, dlaczego stałe reguły dla serwisu są ryzykowne, mimo że są wygodniejsze.
10. Wykonajcie skan bazowy przed i po zmianach: z każdej strefy przeskanujcie wybrane strefy i zapiszcie wyniki. Wyjaśnijcie w sprawozdaniu różnicę i wskażcie port, który zniknął dzięki regule blokującej.
11. Zarejestrujcie ruch na brzegu zapory i porównajcie dwie sytuacje: dozwolone połączenie oraz próbę połączenia zablokowaną. Pokażcie, że zablokowane połączenie jest widoczne w logach, a nie tylko po cichu odrzucone.
12. Przeanalizujcie pojedynczy dozwolony przepływ narzędziem do przechwytywania pakietów i opiszcie, jakie protokoły w nim występują oraz czy dane są przesyłane otwartym tekstem.
13. Sprawdźcie, co się stanie, gdy ktoś podłączy własny router do gniazda w hali: opiszcie, dlaczego strefa bez uwierzytelniania jest problemem, i zaproponujcie dwa środki ograniczenia ryzyka (uwierzytelnianie urządzeń oraz nadzór nad portami).
14. Opracujcie procedurę podłączenia nowego urządzenia do sieci produkcyjnej: zgłoszenie, weryfikacja, wpis do ewidencji, nadzór, wyłączenie po zakończeniu projektu. Wskażcie, kto zatwierdza i co jest warunkiem dopuszczenia.
15. Przygotujcie instrukcję dla pracowników (jedna strona) z zakazem podłączania prywatnych urządzeń, z opisem zgłaszania podejrzenia i z numerem kontaktowym do działu informatycznego.
16. Opracujcie plan wycofania zmian: jak cofnąć reguły, jeśli zablokują proces produkcyjny, kto zatwierdza wyłączenie zabezpieczenia i jak to się odnotowuje. Pokażcie, że zabezpieczenie bez planu wycofania zostanie wyłączone przez pracownika za pierwszym razem, gdy coś nie zadziała.

Reguły zapory w RouterOS pisze się jako łańcuchy: łańcuch wejściowy obsługuje pakiety przychodzące do routera, łańcuch wyjściowy pakiety z routera, a łańcuch przechodzący pakiety między interfejsami. Kolejność ma znaczenie, bo pierwsza pasująca reguła kończy przetwarzanie. Dlatego na początku umieszcza się reguły przepuszczające ruch już nawiązany (odpowiedź na pakiet, który sam wyszedł), a na końcu regułę domyślnie blokującą. Praktyczna zasada: przed każdą zmianą zapiszcie konfigurację poleceniem export, a po zmianie porównajcie pliki, żeby dało się wykazać, co dokładnie zostało dodane.

W zaporze systemowej Linux najprościej zacząć od reguły domyślnej i dodawać wyjątki. Podejście odwrotne, czyli najpierw blokady, potem sprawdzanie, łatwo prowadzi do sytuacji, w której reguła blokująca zostaje przesunięta zbyt wysoko i blokuje wszystko, łącznie z ruchem potrzebnym do zarządzania. Wirtualna sieć prywatna WireGuard jest w tym zadaniu lepszym wyborem niż klasyczna, bo konfiguracja jest krótka, a klucz publiczny można podać dostawcy zamiast hasła. Klucz prywatny musi pozostać u właściciela, a w pliku konfiguracyjnym ustawia się, które podsieci są widoczne w tunelu.

Najlepszym dowodem szczelności jest skan wykonany z wnętrza każdej strefy. Skan z zewnątrza często niczego nie wykazuje, bo router odpowiada sam, a nie chronione urządzenia. W sprawozdaniu pokażcie wynik przed zmianą i po zmianie, a różnicę opiszcie własnymi słowami.

Zablokowane połączenie powinno być widoczne w dzienniku routera, inaczej zespół nie zobaczy prób łamania zabezpieczeń. Logowanie ruchu odrzucanego daje też szybki sygnał, że ktoś skanuje sieć zakładu od zewnątrz. Sam wpis w dzienniku nie wystarczy do obrony wyniku. Warto jednorazowo przechwycić ruch na brzegu zapory i pokazać w sprawozdaniu, że blokada działa na poziomie pakietów, a nie tylko w interfejsie administracyjnym routera.

Wreszcie kilka pytań, które warto zadać sobie przy porządkowaniu dokumentacji. Które reguły dotyczą usług, które mogą zniknąć w kolejnej wersji oprogramowania? Które adresy są zapisane na sztywno w konfiguracji zamiast na liście adresów? Co się stanie, jeśli administrator położy telefon w strefie produkcyjnej? Odpowiedzi na te pytania zamieniają dokumentację w instrukcję, którą da się zastosować w praktyce.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Model stref i przewodów (Zones and Conduits) standardu IEC 62443 w architekturze sieci przemysłowej (Purdue Model poziomy 0–4).
2. Fizyczna i logiczna separacja sieci sterowania przemysłowego (OT) od sieci biurowej (IT) za pomocą dedykowanych zapór ogniowych RouterOS i nftables.
3. Konfiguracja restrykcyjnych reguł filtrowania ruchu przemysłowego: zezwalanie wyłącznie na ściśle zdefiniowane porty protokołów SCADA i Modbus TCP.
4. Bezpieczny dostęp serwisowy zewnętrznych integratorów maszyn za pośrednictwem szyfrowanych tuneli WireGuard z uwierzytelnianiem kluczem.
5. Metodyka bezinwazyjnego audytu i skanowania sieci OT za pomocą skanera Nmap z parametrami chroniącymi przed awariami sterowników PLC.
6. Zgodność z wymogami Ustawy o KSC dla operatorów usług kluczowych w sektorze zaopatrzenia w żywność i wodę.

Przykładowe wnioski (wzór do sprawozdania): Zaprojektowanie i wdrożenie segmentacji sieciowej zgodnej ze standardem IEC 62443 całkowicie odizolowało halę produkcyjną i sterowniki PLC od biurowej sieci korporacyjnej. Konfiguracja zapory ogniowej MikroTik RouterOS wymusiła ścisłą separację stref przemysłowych, blokując wszelki bezpośredni ruch pakietów pomiędzy stacjami księgowości a linią technologiczną chłodni. Wdrożenie tuneli WireGuard dla zewnętrznego serwisu maszyn wyeliminowało niekontrolowane połączenia modemowe i zapewniło pełną kryptograficzną rozliczalność każdej sesji zdalnej. Kontrolowane skanowanie portów narzędziem Nmap z parametrem spowalniającym timing potwierdziło stuprocentową szczelność reguł zapory bez wywołania awarii wrażliwych interfejsów przemysłowych. Osiągnięta architektura skutecznie minimalizuje ryzyko sabotażu produkcji i infekcji ransomware, spełniając najnowsze wymagania dyrektywy NIS2 dla sektora rolno-spożywczego.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych, w szczególności inżynierii społecznej i podszywania się. Metody i środki ochrony: zabezpieczenia poczty elektronicznej, domeny i sesji przeglądarki. Kon2 Podstawy kryptograficznej ochrony informacji. Warunki zapewnienia poufności i autentyczności informacji.

Celem zadania jest sprawdzenie, czy urząd gminy jest w stanie rozpoznać wiadomość podszywającą się pod pracownika samorządu, oraz zaprojektowanie zestawu zabezpieczeń, które utrudnią takie podszywanie. Zadanie jest celowo podzielone na dwie części: techniczną, obejmującą mechanizmy opisane w standardach poczty elektronicznej i DNS, oraz szkoleniową, obejmującą symulację kampanii phishingowej w środowisku laboratoryjnym. Zespół ma nie tylko zebrać wyniki poleceń diagnostycznych, ale też wyjaśnić, co każdy z nich oznacza dla zwykłego użytkownika poczty, a raport ma być zrozumiały dla wójta i dla referenta, a nie tylko dla informatyka.

Studenci muszą rozróżnić cztery mechanizmy, które często są mylone ze sobą. SPF to lista uprawnionych serwerów, z których dana domena może wysyłać pocztę, publikowana w DNS. DKIM to podpis kryptograficzny dokładany do wiadomości przez serwer nadawcy, sprawdzany przez serwer odbiorcy za pomocą klucza publicznego z DNS. DMARC to deklaracja właściciela domeny, co zrobić z wiadomościami, które nie przeszły weryfikacji SPF lub DKIM, wraz z adresem do raportów o próbach podszywania. DNSSEC to podpisywane strefy DNS, które uniemożliwiają podmianę odpowiedzi serwera nazw domen. TLS zabezpiecza kanał transmisji, ale nic nie mówi o autentyczności nadawcy, dlatego sam certyfikat nie chroni przed podszywaniem się.

Efektem pracy jest raport zawierający: stan obecnych zabezpieczeń domeny urzędu, propozycję rekordów SPF, DKIM i DMARC wraz z uzasadnieniem każdego wyboru, ocenę zabezpieczenia kanału STARTTLS, wyniki krótkiej kampanii phishingowej przeprowadzonej wyłącznie na danych laboratoryjnych oraz procedurę reagowania na podejrzaną wiadomość, bo towarzyszy decyzji o wdrożeniu zmian w strefie DNS.

Gmina Podgórze, licząca 11 tysięcy mieszkańców, obsługuje pocztę elektroniczną w domenie gmina-podgórze.pl. Urząd korzysta z poczty na własnej domenie, prowadzi portal mieszkańca, e-skrzynkę papierową (platforma ePUAP) i system obiegu dokumentów. Domena jest obsługiwana przez zewnętrznego operatora, a strefę DNS zmienia firma hostingowa, z którą urząd ma umowę na dwugodzinne okno serwisowe. Główny serwer poczty urzędu działa w biurze, a poczta jest przekierowywana na serwer w chmurze.

W listopadzie 2025 roku do kilku skrzynek pracowników dotarła wiadomość wyglądająca jak z systemu ePUAP, z prośbą o zalogowanie się i potwierdzenie danych w celu „dostępu do wniosku, który wygasa dziś”. Trzech pracowników podało dane logowania na stronie podstawionej pod adresem zaufanej usługi. Jedna z osób zalogowała się później jeszcze raz, gdy przyszła wiadomość z rzekomo zresetowanym haśle, a kolejna wpisała numer karty płatniczej pod pretekstem opłaty za wniosek. W sumie gmina straciła 18 tysięcy złotych, a część danych osobowych trafiła do podmiotu, który udaje firmę windykacyjną.

Analiza wykazała, że domena urzędu nie miała żadnego rekordu SPF ani DKIM, a polityka DMARC nie była opublikowana, więc serwery odbiorcze nie miały podstaw, by odrzucić wiadomość wysłaną w imieniu gminy. Domena nie była podpisana w systemie DNSSEC. Jednocześnie serwer poczty oferował STARTTLS, a portal mieszkańca działał na poprawnym certyfikacie, więc środki transportowe były w porządku, a problem leżał w braku mechanizmów weryfikujących nadawcę.

Grupa laboratoryjna otrzymuje środowisko laboratoryjne z własną strefą DNS, serwerem poczty Postfix, dwoma kontami testowymi oraz publicznym adresem domeny do przeprowadzenia symulacji. Zadaniem zespołu jest zebranie i zaprezentowanie stanu obecnego, przygotowanie kompletu zmian w strefie (SPF, DKIM, DMARC, rozważenie DNSSEC) i przetestowanie ich na domenie laboratoryjnej. Dodatkowo zespół przeprowadzi krótką, jawnie zaplanowaną symulację kampanii phishingowej w środowisku GoPhish, aby zmierzyć, jak szybko i ilu pracowników kliknie w link, oraz przygotuje procedurę reagowania na podejrzaną wiadomość wraz z informacją dla mieszkańców o zagrożeniach.

• Linux Debian 11 lub Ubuntu 22.04 z narzędziami dig (pakiet dnsutils), whois, openssl, curl i python3
• Serwer poczty Postfix (pakiet postfix) z obsługą DKIM
• OpenDKIM (pakiet opendkim-tools) do wygenerowania klucza i podpisywania wiadomości
• GoPhish (licencja MIT) do przeprowadzenia symulacji kampanii phishingowej w sieci lokalnej
• Do badania skonfiguracji serwera pocztowego narzędzie healthcheck z projektu GoPhish (licencja MIT)
• Thunderbird lub dowolny klient poczty do testów, narzędzia dig, openssl s_client, python3 (moduł smtplib)
• Edytor tekstu i arkusz kalkulacyjny do raportu oraz tabeli mechanizmów ochrony

1. Zróbcie inwentaryzację domeny urzędu: jakie usługi (poczta, portal, ePUAP, strona BIP) korzystają z domeny, gdzie są serwery pocztowe, kto i w jakim oknie serwisowym ma prawo zmieniać strefę DNS. Wynik zapiszcie w tabeli, bo bez niej nie da się ustalić, czy proponowane zmiany kolidują z usługami.
2. Wyjaśnijcie w sprawozdaniu, czym różnią się SPF, DKIM, DMARC, DNSSEC i TLS, oraz dlaczego każdy z tych mechanizmów rozwiązuje inny problem. Zespół, który potrafi tylko wymienić nazwy, nie obroni zadania na ocenę 5.0.
3. Zbierzcie stan obecny domeny urzędu i zapiszcie surowe wyniki poleceń: serwery pocztowe (MX), rekordy tekstowe (TXT), polityka DMARC, rekordy podpisu strefy (DS), strefa nadrzędna (SOA) oraz wynik zapytania o podpisany adres.
4. Przeanalizujcie brakujące mechanizmy i przygotujcie projekt zmian: propozycję rekordu SPF z uzasadnieniem każdego mechanizmu, opis klucza DKIM z wyborem selektora i długości klucza oraz projekt polityki DMARC wraz z adresem do raportów.
5. Wyjaśnijcie, dlaczego polityka DMARC powinna być wprowadzana etapami (najpierw obserwacja, potem odrzucanie), i opiszcie, co się stanie, jeśli zostanie ustawiona od razu w najostrzejszym wariancie przy błędnym konfiguracji nadawcy.
6. W środowisku laboratoryjnym wygenerujcie klucz do podpisywania poczty i opiszcie, co znajduje się w wygenerowanych plikach: klucz prywatny pozostaje na serwerze nadawcy, a w strefie DNS publikuje się wyłącznie klucz publiczny w postaci rekordu TXT.
7. Opublikujcie w strefie laboratoryjnej rekord SPF i DKIM, a następnie potwierdźcie ich obecność zapytaniem DNS. Zweryfikujcie, czy rekord SPF mieści się w limicie dziesięciu odpytań do serwerów nazw, o którym mówi specyfikacja.
8. Skonfigurujcie serwer pocztowy tak, aby podpisywał wychodzące wiadomości kluczem z punktu poprzedniego, wyślijcie kilka wiadomości testowych i sprawdźcie w nagłówku obecność podpisu DKIM z właściwą domeną i selektorem.
9. Sprawdźcie, co widzi serwer odbiorcy: wyślijcie jedną wiadomość podpisaną, jedną podpisaną błędnym kluczem i jedną bez podpisu, a następnie porównajcie oznaczenia weryfikacji w nagłówkach wiadomości.
10. Ustawcie politykę DMARC w wariancie obserwacyjnym, wygenerujcie sfałszowaną wiadomość z domeny gminy bez autoryzacji SPF i sprawdźcie, czy raport trafił na wskazany adres. Dopiero po zebraniu raportów przejdźcie do wariantu odrzucającego.
11. Oceńcie zabezpieczenie transportu poczty: sprawdźcie, czy serwer oferuje STARTTLS, jaką wersję protokołu i jakie mechanizmy szyfrowania oferuje, oraz czy certyfikat jest ważny i wystawiony dla właściwej nazwy domeny.
12. Sprawdźcie, czy domena gminy jest podpisana w systemie DNSSEC, a jeśli nie, to wyjaśnijcie, co podpisanie strefy dałoby (ochrona integralności odpowiedzi DNS) i jakie wymaga to procedur (klucz strefy, publikacja DS u operatora domeny nadrzędnej, rotacja klucza).
13. Przygotujcie i przeprowadźcie symulację kampanii phishingowej w środowisku GoPhish: dodajcie domenę nadawczą, wybierzcie szablon wiadomości i strony docelowej, wskażcie grupę odbiorczą złożoną wyłącznie z adresów testowych i uruchomicie kampanię o zdefiniowanym czasie trwania.
14. Zaplanujcie kampanię tak, aby zbierać dane, które da się zinterpretować: kto kliknął, w jakim czasie od wysłania, ile osób podało dane w formularzu, z jakich urządzeń i z jakich adresów. W raporcie podajcie te wartości jako procenty, a nie jako opis.
15. Przeanalizujcie wyniki kampanii i sformułujcie wnioski: które elementy wiadomości zwróciły uwagę odbiorców, jak szybko reagują pracownicy, ile czasu zajęło zgłoszenie podejrzenia. Zaproponujcie konkretne zmiany, nie tylko ogólne hasło o szkoleniach.
16. Opracujcie procedurę reagowania na podejrzaną wiadomość od momentu zgłoszenia przez użytkownika: krok po kroku, kto weryfikuje zgłoszenie, jak zablokować nadawcę, kiedy resetować hasła i w jaki sposób powiadomić pozostałych pracowników.
17. Przygotujcie krótką informację dla mieszkańców o zagrożeniach (artykuł 22 ust. 1 pkt 4 ustawy o krajowym systemie cyberbezpieczeństwa zobowiązuje podmiot publiczny do publikowania informacji pozwalających zrozumieć zagrożenia) z przykładem znaków ostrzegawczych w fałszywej wiadomości.
18. Na koniec przygotujcie plan wdrożenia zmian: lista zmian w strefie DNS, okno serwisowe, osoby odpowiedzialne, testy po wdrożeniu oraz kryteria wycofania zmiany na wypadek błędu.

Większość mechanizmów ochrony poczty opiera się na odpowiedziach serwera nazw domen, dlatego pierwszym krokiem diagnostycznym jest zawsze zebranie surowych wyników i dopiero potem ich interpretacja. Ciekawostką wartą pokazania na obronie jest domena gov.pl: jej rekord SPF to v=spf1 -all, czyli domena jawnie deklaruje, że nie wolno wysyłać z niej poczty, a serwer odbiorczej traktuje każdą wiadomość jako niedozwoloną. Tak restrykcyjna polityka jest możliwa tylko tam, gdzie nie ma poczty wychodzącej, ale pokazuje, że końcówka -all nie jest błędem, tylko najbezpieczniejszym ustawieniem. Klucz DKIM składa się z dwóch części: prywatnej, która pozostaje na serwerze nadawcy i podpisuje wiadomości, oraz publicznej, publikowanej w strefie pod nazwą selektor w domenie kluczy. Selektor to dowolny napis, który pozwala mieć kilka kluczy w jednej domenie, na przykład dla serwera pocztowego i dla systemu wysyłkowego jednocześnie. Usunięcie starego klucza to kwestia bezpieczeństwa, ale przed jego usunięciem trzeba sprawdzić raporty DMARC, bo inaczej podpisy znikną i poczta zacznie wpadać do spamu.

DNSSEC weryfikuje się od góry łańcucha zaufania, czyli od rekordu delegującego strefę, dlatego w zapytaniu potrzebny jest znacznik +dnssec, a w odpowiedzi szukamy flagi ad (authenticated data) oraz rekordów podpisu RRSIG. Brak flagi ad nie musi oznaczać błędu: oznacza, że strefa nie jest podpisana i odpowiedź przyszła bez weryfikacji integralności.

Transport poczty warto sprawdzić dwoma narzędziami. Jedno odpytuje serwer o zdolność do szyfrowania przed wysłaniem danych, drugie pokazuje parametry nawiązanego połączenia. Warto też sprawdzić, czy serwer nie oferuje starych wersji protokołu: jeśli TLS 1.0 jest odrzucane, oznacza to, że kanał jest chroniony nowocześnie. Symulacja kampanii w GoPhish uruchamia się jednym plikiem i od razu podaje porty oraz hasło administratora, więc nie trzeba instalować serwera pocztowego, żeby zmierzyć zachowanie odbiorców. Panel administracyjny działa na porcie 3333, a strony docelowe na porcie 80, co w środowisku laboratoryjnym wystarcza. Pamiętajcie, że kampanię uruchamia się wyłącznie na adresach testowych, których jesteście właścicielami, i zgodnie z wewnętrzną zgodą na badania; w środowisku publicznym takie testy wymagają pisemnego upoważnienia.

Realne rekordy SPF dobrze pokazują, dlaczego limit odpytań do serwerów nazw jest ważny: każdy mechanizm include to dodatkowe zapytanie, a przy limicie dziesięciu mechanizmów domena przestaje być weryfikowalna. Warto w raporcie policzyć mechanizmy w projektowanym rekordzie i pokazać, ile zapytań kosztuje każdy z nich, a także wyjaśnić, dlatego kopiowanie rekordu innej organizacji „na szybko” kończy się błędem weryfikacji. Po stronie transportu warto jeszcze sprawdzić, czy strona wymusza szyfrowanie i czy chroni się przed osadzaniem treści w ramce, bo te nagłówki są darmowe, a często pomijane w dokumentacji gminy. Wartość max-age podaje, jak długo przeglądarka ma pamiętać decyzję o wymuszaniu HTTPS, a słowo preload oznacza, że domena jest zgłoszona do listy w przeglądarce wymuszającej szyfrowanie od pierwszego wejścia.

Dobry raport z tego zadania zawiera trzy liczby, które można sprawdzić: odsetek odbiorców, którzy otworzeli wiadomość, odsetek, którzy kliknęli, oraz średni czas od wysłania do kliknięcia. Do tych liczb warto dodać jedno zdanie interpretacji, na przykład że największy wpływ miała znajomość danych osoby z publicznie dostępnej strony, a nie hasło przycisku. Bez interpretacji zestaw liczb nie jest analizą zagrożeń, a jedynie odczytem statystyk.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Trójfilary uwierzytelniania poczty elektronicznej: SPF, kryptograficzny podpis DKIM oraz nadrzędna polityka i raportowanie DMARC.
2. Wdrożenie restrykcyjnej polityki DMARC p=reject z mechanizmem raportów agregacyjnych RUA i raportów kryminalistycznych RUF.
3. Rola zabezpieczenia DNSSEC w uodpornieniu strefy domenowej gminy na ataki zatruwania pamięci podręcznej DNS.
4. Wymuszenie szyfrowania w locie za pomocą protokołu MTA-STS (RFC 8461) oraz mechanizmu raportowania błędów TLS-RPT.
5. Metodyka przygotowania, przeprowadzenia i etycznej oceny kontrolowanej kampanii phishingowej w platformie GoPhish.
6. Spełnienie wytycznych CSIRT NASK oraz standardów rządowych w zakresie ochrony domen publicznych jednostek samorządu terytorialnego.

Przykładowe wnioski (wzór do sprawozdania): Kompleksowe wdrożenie rekordów SPF, DKIM oraz rygorystycznej polityki DMARC w trybie reject całkowicie wyeliminowało możliwość podszywania się pod oficjalną domenę urzędu gminy przez cyberprzestępców. Podpisanie strefy domeny mechanizmem DNSSEC zabezpieczyło mieszkańców i serwery pocztowe przed atakami typu DNS Spoofing i fałszowaniem rekordów MX. Wprowadzenie standardu MTA-STS wyeliminowało podatność na ataki obniżenia wersji połączenia pocztowego, gwarantując szyfrowaną transmisję TLS dla całej korespondencji urzędowej. Równoległa symulacja kontrolowanego phishingu w środowisku GoPhish ujawniła podatność 28% urzędników na socjotechniczne próby wyłudzenia haseł, wskazując konieczność pilnych szkoleń personelu. Uzyskane wyniki pozwoliły na podniesienie wskaźnika bezpieczeństwa poczty w audycie rządowym do maksymalnego poziomu, chroniąc finanse gminy przed oszustwami typu Business Email Compromise.

Kon4 Pamięci masowe: macierze RAID, pamięci masowe podłączone do sieci SAN oraz NAS, ich budowa, działanie i zastosowanie. Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony przed poszczególnymi rodzajami zagrożeń.

Celem zadania jest oszacowanie skutków awarii magazynu danych w laboratorium medycznym i zaprojektowanie rozwiązania, które skróci czas przestoju do akceptowalnego poziomu. Zespół ma przejść od opisu danych, przez ustalenie dopuszczalnego czasu niedostępności i utraty danych, aż do działającej macierzy z kopiami zapasowymi, której stan można sprawdzić poleceniem. Wartość zadania polega na tym, że dokument BIA powstaje z pomiarów i prób, a nie z wpisania typowych wartości.

Studenci muszą odróżnić trzy warstwy, które w codziennej mowie nazywa się „magazynem danych”. RAID chroni przed awarią pojedynczego nośnika, ale nie przed przypadkowym skasowaniem pliku, uszkodzeniem logicznym ani awarią całego urządzenia. Kopia zapasowa przechowywana poza tym samym urządzeniem chroni przed utratą danych, ale sama potrzebuje kontroli, bo niesprawdzona kopia daje fałszywe poczucie bezpieczeństwa. Magazyn sieciowy (NAS) udostępnia te same dane wielu stacjom, co wygodne, ale zwiększa liczbę miejsc, w których dostęp trzeba kontrolować. Dopiero rozumienie tych warstw pozwala wybrać, której z nich w danym przypadku naprawdę potrzebujemy.

Wynikiem pracy jest dokument analizy wpływu na działanie, macierz RAID zbudowana w środowisku laboratoryjnym wraz z przeprowadzonym testem awarii jednego nośnika, kopia zapasowa wykonana poza macierzą, przeprowadzony test odtworzenia z pomiarem czasu, skrypt monitorujący stan nośników oraz harmonogram kopii z uwzględnieniem ograniczeń wynikających z RODO. Zespół ma podać konkretne wartości czasu i utraty danych, a nie wartości progowe z definicji pojęcia BIA.

Laboratorium diagnostyczne w Małopolsce wykonuje badania hematologiczne, biochemiczne i mikrobiologiczne. Wyniki są wprowadzane do systemu laboratoryjnego (LIMS) przez analityków, a wyniki badań genetycznych i wykrywających patogeny są wrażliwe. Laboratorium działa w systemie dwuzmianowym, a wyniki badań pilnych muszą być dostępne dla lekarza dyżurnego w ciągu kilkunastu minut, także w weekend. Dane pacjentów są przechowywane zgodnie z przepisami o ochronie danych osobowych i szczególnych kategorii danych, a dokumentacja medyczna podlega odrębnym zasadom przechowywania.

W maju 2026 roku, podczas wymiany macierzy w serwerowni, jeden z dysków w macierzy RAID 5 zaczął zgłaszać błędy odczytu. Administrator zauważył to dopiero po tygodniu, ponieważ powiadomienia o awariach przychodziły na adres, z którego nikt nie czytał. W tym czasie macierz pracowała w stanie zdegradowanym, a drugi nośnik tej samej grupy był w 60 procentach zapisany. Gdy podczas nocnej kopii zapasowej jeden z plików okazał się nieczytelny, okazało się, że ostatnia pełna kopia ma dziewięć miesięcy, bo harmonogram kopii zakładał wyłączanie serwera w weekendy, a serwer nie zawsze się wyłączał.

Audyt wykazał trzy problemy: brak aktualnej oceny czasu dopuszczalnego przestoju i utraty danych, brak testowego odtwarzania kopii zapasowej oraz brak monitoringu, którego wynik ktoś realnie ogląda. Dodatkowo kopie przechowywano na dysku podłączonym do tego samego serwera, co dane produkcyjne, a dostęp do magazynu sieciowego mieli wszyscy użytkownicy sieci biurowej.

Grupa laboratoryjna otrzymuje środowisko z trzema plikami obrazów dysków, zestawem przykładowych danych (raporty, wyniki badań, baza słownikowa) oraz dostępem do maszyny z systemem Debian, na której można zbudować macierz, wykonać kopie i przeprowadzić test odtwarzania. Zadaniem zespołu jest udokumentowany pomiar czasu odtworzenia, dobranie poziomu ochrony (RAID 1, macierz z dyskiem zapasowym, kopia poza macierzą) oraz zaprojektowanie monitoringu, który sam zgłasza problem.

• Linux Debian 11 lub Ubuntu 22.04 z pakietami mdadm, cryptsetup, smartmontools i gddrescue
• Restic (licencja BSD-2-Clause, darmowy) do wykonywania kopii zapasowych z szyfrowaniem i weryfikacją
• Narzędzia systemu plików: mkfs, mkswap, blkid, lsblk, df, du, rsync
• Do magazynu sieciowego: Samba (pakiet samba) lub NFS; do wymiany danych między maszynami SSH i rsync
• Do monitoringu: smartmontools, polecenie cat /proc/mdstat, skrypt powłoki uruchamiany cyklicznie przez cron lub systemd timer
• Arkusz kalkulacyjny do dokumentu BIA i harmonogramu kopii

1. Zinwentaryzujcie dane w laboratorium: rodzaje dokumentów, systemy, w których powstają, gdzie są przechowywane, kto z nich korzysta, jak długo muszą być dostępne i czy podlegają obowiązkom szczególnej kategorii danych. Każda pozycja powinna mieć właściciela.
2. Ustalcie dla każdego procesu (przyjęcie pacjenta, wykonanie badania, wydanie wyniku, rozliczenie z ubezpieczycielem) dopuszczalny czas niedostępności systemu (RTO) i dopuszczalny czas utraty danych (RPO). Wartości uzasadnijcie, a nie podawajcie z definicji pojęć.
3. Opiszcie skutki przerwania każdego procesu w skali pojedynczego badania, całego dnia i całego tygodnia, uwzględniając skutki prawne, medyczne i finansowe. Wyznaczcie proces krytyczny, którego przerwanie jest niedopuszczalne.
4. Zbudujcie w środowisku laboratoryjnym macierz lustrzaną (RAID 1) na dwóch nośnikach wraz z systemem plików i plikami testowymi, zgodnie z wcześniej opisanym schematem podziału odpowiedzialności za dane.
5. Zarejestrujcie stan początkowy macierzy poleceniami pokazującymi szczegóły macierzy i stan z katalogu informacyjnego jądra, a następnie zapiszcie te wyniki jako punkt odniesienia dla późniejszego porównania.
6. Zaprogramujcie test awarii: odłączcie jeden nośnik w sposób zbliżony do rzeczywistej awarii (usunięcie urządzenia z tablicy), zaobserwujcie stan zdegradowany i wykonajcie operację odczytu plików, żeby udowodnić, że dane są nadal dostępne.
7. Dodajcie uszkodzony nośnik z powrotem do macierzy i zmierzcie, ile trwa odbudowa oraz jak zmienia się stan macierzy w trakcie odbudowy. Zanotujcie czasy, bo to one decydują o tym, czy okno serwisowe jest wystarczające.
8. Wykonajcie kopię zapasową danych poza macierzą, z szyfrowaniem i kontrolą sum, do osobnego katalogu lub urządzenia. Sprawdźcie, ile zajmuje kopia, ile trwa i jakie parametry bezpieczeństwa kopia zapewnia.
9. Udokumentujcie, dlaczego kopia leżąca na tej samej macierzy lub serwerze nie jest kopią zapasową w rozumieniu tego zadania, i narysujcie schemat rozmieszczenia danych, w którym każda kopia jest na innym urządzeniu lub w innej lokalizacji.
10. Przeprowadźcie test odtwarzania: skasujcie część danych, przywróćcie je z kopii i zmierzcie czas odtworzenia dla dwóch rozmiarów danych. Porównajcie ten czas z wartością RTO przyjętą w punkcie drugim i wyciągnijcie wnioseek, czy cele są osiągalne.
11. Sprawdźcie, czy kopia faktycznie zawiera to, czego wymagacie: wykonajcie kontrolę kopii i wykazanie zawartości, a potem świadomie uszkodźcie kopię w sposób, który da się wykryć, i sprawdźcie, czy kontrola to wykrywa.
12. Przygotujcie harmonogram kopii: częstotliwość, okno czasowe, retencja, szyfrowanie, kopia osobna dla kopii zapasowej, oraz regułę 3-2-1 z podaniem, co dokładnie oznacza każda z trzech cyfr.
13. Napiszcie skrypt monitorujący, który sprawdza stan macierzy, zużycie miejsca, dostępność systemu plików i stan nośników, a w razie problemu zapisuje wpis do pliku dziennika i wysyła powiadomienie na podany w ćwiczeniu adres. Uruchomicie go ręcznie i pokażcie wpisy dla stanu prawidłowego i dla stanu zdegradowanego.
14. Wyjaśnijcie w sprawozdaniu, dlaczego w środowisku wirtualnym nie da się odczytać danych S.M.A.R.T. z nośnika plikowego, i opiszcie, jakie informacje daje test S.M.A.R.T. na fizycznym dysku oraz dlaczego administrator powinien ustawić progi alarmowe dla najważniejszych atrybutów.
15. Uwzględnijcie w dokumencie BIA kwestie podstawy przetwarzania, minimalizacji danych, retencji oraz tego, czy kopia zapasowa zawiera dane, które podlegają odrębnym obowiązkom, i jak zabezpieczyć samą kopię (szyfrowanie, kontrola dostępu, zakaz współdzielenia).
16. Przygotujcie plan rozwoju systemu magazynowego na dwa warianty: minimum, które zamyka luki wykryte w audycie, oraz wariant docelowy z pełną redundancją, z zaznaczeniem, których elementów nie da się osiągnąć tanio i dlaczego.
17. Na koniec przygotujcie stronę podsumowania dla kierownika laboratorium: aktualne ryzyko utraty danych, zmierzone czasy odtworzenia, lista działań naprawczych z terminami i osobami odpowiedzialnymi oraz szacowany koszt roczny utrzymania kopii.

Macierz lustrzana w systemie plików pokazuje dokładnie to, czego uczy zadanie: dwie kopie tego samego nośnika, z których jedna może zniknąć bez utraty danych. Nośnikiem w środowisku laboratoryjnym są pliki obrazów podłączone przez urządzenia loop, a metadane macierzy trzymają się na końcu każdego z nich, dlatego przed rozpoczęciem warto zrobić ich kopię. Odczyt stanu z pliku /proc/mdstat jest najprostszym testem spójności macierzy: dwa wpisy w nawiasie kwadratowym oznaczają dwa działające nośniki, a litera U oznacza nośnik w pełni zsynchronizowany.

Test awarii wykonuje się na działającej macierzy, ale wymaga wcześniejszego odmontowania systemu plików, inaczej jądro odmówi usunięcia nośnika. Stan po usunięciu jednego nośnika to stan zdegradowany, w którym dane są nadal dostępne, ale macierz nie toleruje kolejnej awarii. Ten moment warto opisać w BIA jako granicę bezpieczeństwa, a nie jako awarię zakończoną utratą danych. Podczas odbudowy macierzy widać w szczegółach stan spare rebuilding, a po zakończeniu wraca active sync. Różnica między tymi stanami jest najlepszym dowodem na to, że odbudowa faktycznie się odbyła, a nie tylko zgłoszona przez narzędzie. Warto zanotować czas odbudowy dla dwóch rozmiarów macierzy, bo rośnie on z liczbą nośników i z rozmiarem danych, a okno serwisowe musi go obejmować.

Kopia zapasowa powinna być sprawdzalna, szyfrowana i przechowywana poza macierzą, z którą pracuje system produkcyjny. Restic zapisuje kopie w postaci bloków, więc kolejne wersje tego samego pliku nie zajmują tyle samo miejsca, a każda kopia ma kontrolę integralności, którą można zweryfikować poleceniem kontroli. Kontrola kopii jest tu ważniejsze niż jej szyfrowanie: niesprawdzona kopia daje fałszywe poczucie bezpieczeństwa. Liczbę przechowywanych kopii ustala się schematem GFS, czyli układem dziadek, ojciec, syn: kopie co godzinę, codzienne, tygodniowe i miesięczne. Dzięki temu w oknie serwisowym odzyskujecie dane sprzed godziny, a po awarii sprzed roku nadal macie punkt odniesienia, i to bez przechowywania kopii każdego dnia od początku działania systemu. W restic odpowiadają temu cztery opcje: --keep-hourly, --keep-daily, --keep-weekly i --keep-monthly: polecenie forget kasuje kopie spoza schematu, a prune rzeczywiście zwalnia zajęte miejsce.

Test odtwarzania prowadzi się na odwrotnej stronie procesu: najpierw usuwa się dane, potem odtwarza z kopii i mierzy czas. Najczęstszy błąd to sprawdzenie, czy kopia istnieje, zamiast sprawdzenia, czy da się z niej odtworzyć konkretne pliki; dlatego w BIA warto wpisać wynik ostatniego testu wraz z datą i osobą, która go wykonała. Retencja kopii powinna uwzględniać wymogi prawne dotyczące dokumentacji medycznej, a sama kopia powinna być zaszyfrowana i dostępna dla wyznaczonej, niewielkiej grupy osób. Na koniec monitoring. W środowisku wirtualnym, gdzie nośniki są plikami, atrybuty S.M.A.R.T. są niedostępne, bo mechanizm ten działa na fizycznym dysku; warto to wyjaśnić w sprawozdaniu i oprzeć monitoring na stanie macierzy, zapisach jądra oraz metrykach systemu plików. Prawdziwy test polega na uruchomieniu skryptu w stanie zdegradowanym i sprawdzeniu, czy powstaje czytelny wpis alarmowy.

Wartością dodaną przez zespół jest tabela, w której dla każdego procesu z punktu drugiego podano cztery liczby: RTO przyjęte, RTO zmierzone podczas testu, RPO wynikające z częstotliwości kopii i koszt alternatywy (praca na papierze, przeniesienie placówki, zlecenie badań na zewnątrz). Dopiero takie zestawienie pokazuje, że wybór poziomu ochrony to decyzja ekonomiczna, a nie wybór najdroższego urządzenia.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Metodyka przeprowadzania analizy wpływu na ciągłość działania (Business Impact Analysis) w podmiocie leczniczym zgodnie z normą ISO 22301.
2. Matematyczna i operacyjna definicja wskaźników RTO oraz RPO dla krytycznego systemu laboratoryjnego LIMS.
3. Ograniczenia macierzy RAID 1: ochrona przed fizyczną awarią dysku vs brak ochrony przed logicznym uszkodzeniem danych i ransomware.
4. Architektura kopii zapasowej poza macierzą (Out-of-Band Backup) z fizycznym i logicznym odizolowaniem repozytorium.
5. Procedura cyklicznego, próbnego odtwarzania środowiska bazodanowego (Disaster Recovery Drill) i weryfikacja sum kontrolnych archiwów.
6. Ciągły monitoring kondycji nośników dyskowych za pomocą telemetrii S.M.A.R.T. oraz automatycznych powiadomień w systemie nadzoru.

Przykładowe wnioski (wzór do sprawozdania): Przeprowadzona analiza BIA w laboratorium diagnostycznym dowiodła, że przestój systemu LIMS przekraczający 2 godziny stwarza bezpośrednie zagrożenie dla życia pacjentów na oddziałach intensywnej terapii. Eksperyment awarii wykazał, że sama macierz RAID 1 nie stanowi kopii zapasowej, gdyż logiczne skasowanie bazy lub atak szyfrujący replikuje się natychmiastowo na oba nośniki. Zaimplementowanie zautomatyzowanego potoku tworzenia kopii zapasowych poza macierzą na niezależny serwer NAS z migawkami Btrfs pozwoliło na osiągnięcie RPO równego 15 minut. Praktyczny test odtworzenia środowiska z kopii zapasowej na stacji zastępczej zajął 42 minuty, co z zapasem mieści się w dopuszczalnym progu RTO. Wdrożenie ciągłego monitoringu parametrów S.M.A.R.T. oraz automatycznych testów integralności archiwów zabezpieczyło placówkę przed nieprzewidzianą awarią sprzętową i spełniło wymogi normy ISO 22301.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych, w tym zagrożenia związane z przestępczością komputerową i incydentami. Metody i środki ochrony: wykrywanie, reagowanie i odtwarzanie po incydencie. Kon2 Podstawy kryptograficznej ochrony informacji. Warunki zapewnienia poufności i autentyczności informacji, w tym integralności pozyskanych dowodów cyfrowych.

Celem zadania jest przeprowadzenie pełnej obsługi incydentu w firmie logistycznej: od chwili zgłoszenia, przez zabezpieczenie dowodów, analizę śladów i ustalenie skali, aż po decyzję o obowiązku poinformowania organów i osób, których dane mogły zostać naruszone. Zespół ma zobaczyć, że obsługa incydentu to przewidywalny proces z listą obowiązków, a nie improwizacja, w której najwięcej szkód wyrządza paniczne kasowanie plików i uruchamianie narzędzi na żywym systemie.

Część praktyczna poświęcona jest pozyskaniu i analizie obrazu dysku, który dostarcza środowisko ćwiczeniowe. Studenci muszą zachować kolejność czynności: najpierw zabezpieczenie nośnika i obliczenie sumy kontrolnej, potem kopia robocza, dopiero na niej praca narzędziami. Muszą wyjaśnić, dlaczego każde narzędzie analityczne działa na kopii i dlaczego kolejne operacje na oryginalnym obrazie unieważniają jego wartość dowodową, oraz prowadzić łańcuch dowodowy w formie formularza z datą, godziną, osobą i numerem nośnika.

Wynikiem pracy są: oś czasu zdarzeń, tabela znalezionych śladów z interpretacją, formularz łańcucha dowodowego, ocena skutków i decyzja o zgłoszeniu z podaniem podstawy prawnej i terminu, lista dowodów potrzebnych do pozwolenia na zapytanie o dane oraz plan działań zapobiegawczych po incydencie. Zespół ma też zaproponować zmianę, która w kolejnym podobnym ataku skróciłaby czas wykrycia z godzin do minut.

Firma logistyczna TransMał Sp. z o.o. ma siedzibę w Krakowie i trzy oddziały magazynowe. Pracownicy korzystają z systemu magazynowego, biurka usługowego, poczty firmowej i dysku współdzielonego, na którym księgowość trzyma faktury i dane kontrahentów. Firma obsługuje ponad tysiąc klientów, w tym dwóch dużych sieci handlowych, dlatego w bazie znajdują się adresy dostaw, numery telefonów i dane osobowe kierowców, a w systemie magazynowym zapisywane są godziny przyjazdu i wyjazdu pojazdów.

W sierpniu 2026 roku pracownik działu księgowości zgłosił, że pliki na dysku współdzielonym mają w rozszerzeniu .ransomware i zawierają instrukcję zapłaty w kryptowalutach. Zespół informatyczny odłączył dysk od sieci, zlokalizował pozostałe zainfekowane stacje, zrestartował je i przywrócił system z kopii obrazu systemu, ale nie zrobił nic z nośnikiem zawierającym oryginalne dane, nie zebrał logów i nie ustalił, jak intruz dostał się do sieci. Jedna kopia zapasowa, która powinna była chronić dokumentację księgową, okazała się uszkodzona, bo nikt jej od roku nie sprawdził.

Później okazało się, że atakujący wszedł do sieci przez zdalny dostęp dostawcy usług księgowych, który miał konto zapisane w pliku hasł, współdzielone ze współpracownikiem, który odszedł z firmy. Zdarzenie nie zostało zgłoszone do organów, bo nikt w firmie nie wiedział, czy jest to obowiązkowe, a dokumentacja zdarzenia powstała dopiero kilka tygodni później z notatek rozmów. W tym czasie klienci zaczęli pytać o to, czy ich dane adresowe i numery telefonu mogły trafić do nabywcy kopii zapasowych.

Grupa laboratoryjna otrzymuje środowisko ćwiczeniowe z obrazem dysku serwera plików, zestawem logów (logowanie systemowe, logi firewalla, logi aplikacji), wykazem plików i dokumentacją procesów. Zadaniem zespołu jest przeprowadzić analizę, ustalić sekwencję zdarzeń, określić, jakie dane mogły zostać naruszone, przygotować komplet dokumentów obsługi incydentu oraz odpowiedzieć na pytanie, czy i kiedy należy zgłosić zdarzenie oraz poinformować osoby, których dane dotyczą.

• Linux Debian 11 lub Ubuntu 22.04 z narzędziami dd, ddrescue (pakiet gddrescue), sha256sum, stat i find
• Sleuth Kit (pakiet sleuthkit): mmls, fls, icat, fsstat do analizy obrazów systemów plików
• TestDisk i PhotoRec (pakiet testdisk) do odzyskiwania plików po usunięciu i do analizy tablic partycji
• Logi: journalctl, pliki /var/log, logi firewalla (nftables) i aplikacji w formacie tekstowym
• Arkusz kalkulacyjny do oś czasu zdarzeń, formularza łańcucha dowodowego i oceny skutków
• Do oceny haseł i zabezpieczeń: sha256sum, openssl, zliczanie znaków w słownikach haseł (bez serwisów wymagających płatności)

1. Zajmijcie się najpierw porządkiem, nie dowodami: zapiszcie w oś czasu zdarzeń to, co wiadomo z zgłoszenia pracownika, kiedy zauważono problem, kto co zrobił i o której godzinie. Oś czasu to dokument, który trzeba prowadzić od pierwszej minuty, a nie po fakcie.
2. Zdefiniujcie zakres działań: które systemy i nośniki są potencjalnie zainfekowane, gdzie są kopie zapasowe, kto ma dostęp do sieci zdalnej, oraz czy działają usługi dostępne dla klientów. Zakres zawęża listę dowodów do zabezpieczenia.
3. Ustalcie priorytety: co najpierw zabezpieczyć (nośniki z danymi), co odizolować (systemy działające, żeby nie doszło do dalszego rozprzestrzeniania), a co zostawić do analizy w stanie aktualnym (logi, które znikają po restarcie).
4. Zabezpieczcie nośniki: wykonajcie bit w bit kopie obrazów na osobne, odłączone nośniki, używając narzędzia odpornego na błędy odczytu, a następnie przeliczcie sumy kontrolne obrazu i zapiszcie je w protokole. Suma kontrolna jest podstawą wiarygodności dalszych analiz.
5. Prowadźcie łańcuch dowodowy w formularzu: identyfikator dowodu, opis, kto i kiedy przejął, na jakim nośniku, jaka suma kontrolna, dokąd trafił po przeniesieniu. Każde przeniesienie zmienia właściciela dowodu i musi być odnotowane.
6. Nie uruchamiajcie narzędzi analitycznych na oryginalnym obrazie. Wyjaśnijcie w sprawozdaniu, co by się stało, gdyby na obrazie wykonano montowanie systemu plików z zapisem albo naprawę, i jaki byłby tego skutek dla wartości dowodowej.
7. Ustalcie tablicę partycji obrazu i zidentyfikujcie systemy plików na poszczególnych partycjach, korzystając z wykazu tablicy partycji oraz statystyki systemu plików. Zapiszcie rozmiary i typy, bo to rozróżnia dysk systemowy od katalogu z danymi.
8. Przejrzyjcie katalogi systemu plików i wyodrębnijcie pliki związane z atakiem: zaszyfrowane pliki, notatkę z żądaniem okupu, pliki wykonawcze, skrypty, artefakty zainstalowania. Wyodrębnijcie jeden z nich i porównajcie jego sumę z resztą.
9. Sprawdźcie, czy na nośniku pozostały usunięte pliki, i wyodrębnijcie jeden z nich narzędziem do plików usuniętych, a następnie porównajcie jego zawartość z zawartością pliku po odszyfrowaniu z kopii, jeśli taką posiadacie.
10. Przeanalizujcie logi: uszukajcie nieudanych prób logowania, logowań z nietypowych adresów, zmian w systemie plików, uruchomień zadań o podwyższonych uprawnieniach i odwołań do danych wychodzących na zewnątrz. Uporządkujcie znaleziska w tabeli z czasem, źródłem i znaczeniem.
11. Ustalcie wektor wejścia i sprawdźcie go na przykładach: hasło współdzielone, konto dostawcy, brak uwierzytelniania wieloskładnikowego, brak segregacji stacji roboczych. Każdy z tych punktów ma zostać zamknięty konkretnym działaniem, a nie hasłem „edukacja użytkowników”.
12. Oceńcie skutki: jakie dane osobowe i jakich osób mogły trafić do nabywcy kopii, ile osób jest objętych, czy dane były zaszyfrowane na poziomie kopii zapasowej, jakie są skutki prawne i reputacyjne. Odpowiedź ma być oparta na faktach z analizy, nie na przewidywaniach.
13. Zdecydujcie, czy zdarzenie wymaga zgłoszenia, i zapiszcie uzasadnienie: to, czy firma jest operatorem usługi kluczowej lub dostawcą usługi cyfrowej w rozumieniu ustawy o krajowym systemie cyberbezpieczeństwa, jaki jest charakter naruszenia danych osobowych i jaki termin obowiązuje (siedemdziesiąt dwa godziny od momentu zgłoszenia organowi nadzorczemu).
14. Przygotujcie projekt komunikatu dla osób, których dane mogły zostać naruszone, zgodny z zasadą transparentności: informacja o charakterze zdarzenia, o możliwych konsekwencjach, o podjętych działaniach i o danych, których dotyczy zagrożenie, w języku zrozumiałym dla odbiorcy.
15. Zaplanujcie odtworanie usług: kolejność przywracania systemów, weryfikacja integralności kopii przed użyciem, sposób ochrony przed ponownym zainfekowaniem i kryteria akceptacji (kto i na podstawie czego potwierdza gotowość).
16. Zamknijcie incydent dokumentem podsumowującym: przyczyna źródłowa, zakres, czas trwania, działania podjęte, wnioski, lista zmian z terminami i odpowiedzialnymi, daty kolejnych testów wdrożenia.
17. Zaproponujcie jedną zmianę techniczną, która skróciłaby czas wykrycia kolejnego podobnego ataku (na przykład wysyłanie logów na osobny host z alertem, skanowanie integralności plików, segmentacja sieci), i opiszcie, jak ją zweryfikować testem.

Zabezpieczenie dowodu wygląda prosto tylko wtedy, gdy wie się, po co się je wykonuje. Obraz nośnika tworzy się kopiami bloków, a nie zwykłym kopiowaniem plików, bo kopiowanie plików zmienia metadane i nie odtworzy usuniętych danych. Narzędzie ddrescue czyta blok po bloku, zapisuje postęp w pliku mapy i pozwala przerwać oraz wznowić kopiowanie, co ma znaczenie przy dużych nośnikach i uszkodzonych obszarach.

Tablica partycji i system plików na obrazie są pierwszym miejscem, w którym widać strukturę nośnika. Narzędzia Sleuth Kit działają na kopii i pozwalają określić przesunięcie partycji, a potem listować katalogi i wyodrębniać pliki bez montowania, więc nie zmieniają zawartości obrazu. Warto pokazać w sprawozdaniu różnicę między katalogiem zwykłym a katalogiem usuniętych plików, bo to ona uzasadnia użycie tych narzędzi zamiast zwykłego podłączania dysku. Logi systemowe są najtańszym źródłem osi czasu, pod warunkiem że zapisuje się je z dostateczną szczegółowością i w odpowiednim formacie. Warto pokazać w sprawozdaniu, jak wygląda typowy zapis udanego logowania i jak z niego odczytać nazwę hosta, użytkownika i polecenie, oraz dlaczego rotacja logów kasuje ślady szybciej, niż zespół jest w stanie je przejrzeć.

Decyzja o zgłoszeniu zdarzenia jest częścią obsługi incydentu i musi być udokumentowana, nawet gdy jest odpowiedzią „nie”. W przypadku naruszenia danych osobowych administrator danych ma siedemdziesiąt dwa godziny na zgłoszenie organowi nadzorczemu, licząc od momentu, w którym dowiedział się o naruszeniu, a nie od chwili sporządzenia raportu, dlatego samo wykrycie nie zwalnia z przygotowania informacji. Z kolei obowiązki z ustawy o krajowym systemie cyberbezpieczeństwa dotyczą podmiotów w niej wskazanych, więc w raporcie trzeba najpierw sprawdzić status podmiotu, a dopiero potem wskazywać artykuły.

Oś czasu można zbudować z samych logów, ale wymaga to jednej rzeczy: czytelnego rozdzielenia pól. Zamiast przeglądać plik wiersz po wierszu, warto policzyć zdarzenia w kolejnych godzinach i wyszukać wzorce typowe dla ataku, takie jak nieudane logowania pod nieistniejącym kontem, logowanie kluczem publicznym w porze nocnej, uruchomienie powłoki z katalogu tymczasowego oraz błędy odczytu w systemie plików. Takie zestawienie jest czytelniejsze dla kierownika niż kilkaset linii logu i jest podstawą do rozmowy o tym, co dokładnie się wydarzyło. Metadane plików na obrazie dają drugi, niezależny wątek dowodowy. Wykaz z trybem długim pokazuje trzy znaczniki czasu (utworzenia, modyfikacji i dostępu) oraz rozmiar, a statystyka systemu plików pokazuje, kiedy ostatnio zapisano dane i skąd system plików był montowany. Różnica między czasem modyfikacji pliku a czasem wejścia atakującego potrafi wskazać, które pliki faktycznie zmieniono, a które tylko odczytano, co jest istotne przy ocenie skutków.

Wreszcie kilka zdań o jakości takiego raportu, które odróżniają ocenę 5.0 od 4.0. Raport ma oddzielać ustalenia od interpretacji, każde ustalenie ma wskazywać źródło (plik, polecenie, pozycja w logu, czas), a każda interpretacja ma zawierać poziom pewności. Wnioski po incydencie powinny zawierać zmiany z terminami, a nie hasła typu „szkolić użytkowników”; dobry wniosek brzmi: dostęp dostawcy zostanie wyłączony z listy dozwolonych źródeł, a każde logowanie z nowego urządzenia wymaga potwierdzenia telefonicznego.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Zasady zachowania łańcucha dowodowego (Chain of Custody) w informatyce śledczej: protokoły przekazania, plomby i sumy kontrolne SHA-256.
2. Metodyka bezpiecznego pobierania obrazu binarnego nośnika (Bit-Stream Image) z wykorzystaniem sprzętowego blokera zapisu.
3. Analiza artefaktów systemowych: rejestry Prefetch, dzienniki zdarzeń Windows Event Logs, historia powłoki i pliki tymczasowe.
4. Korelacja logów z wielu źródeł na osi czasu (Timeline Analysis) w celu precyzyjnego odtworzenia ścieżki i wektora ataku.
5. Analiza prawna incydentu: kryteria zgłoszenia naruszenia do Prezesa UODO (art. 33 RODO) oraz do właściwego zespołu CSIRT.
6. Opracowanie zaleceń poincydentowych (Post-Incident Review) zapobiegających ponownemu wykorzystaniu tego samego wektora ataku.

Przykładowe wnioski (wzór do sprawozdania): Profesjonalne zabezpieczenie obrazu binarnego pamięci masowej za pomocą sprzętowego blokera zapisu zagwarantowało nienaruszalność materiału dowodowego i zachowanie pełnego łańcucha dowodowego. Analiza korelacyjna dzienników zdarzeń na osi czasu pozwoliła na precyzyjne odtworzenie wektora infekcji: od phishingu pocztowego pracownika logistyki, aż po wykonanie złośliwego skryptu PowerShell. Wyekstrahowane wskaźniki kompromitacji umożliwiły natychmiastowe zablokowanie ruchu wychodzącego do serwera C2 na zaporze brzegowej i izolację pozostałych hostów w sieci. Ocena ryzyka naruszenia praw osób fizycznych wykazała konieczność formalnego zgłoszenia incydentu do organu nadzorczego UODO w trybie art. 33 RODO ze względu na wyciek baz danych kontrahentów. Wdrożenie zaleceń poincydentowych, w tym wymuszenia polityki AppLocker i blokady makr, skutecznie zamknęło lukę wykorzystaną przez intruza.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony przed poszczególnymi rodzajami zagrożeń. Kon6 Algorytmy kryptograficzne stosowane w uwierzytelnianiu i transmisji danych.

Celem zadania jest zamiana ogólnych zaleceń bezpieczeństwa w mierzalny stan serwera. Zespół wykonuje pomiar „twardy” narzędziem Lynis, odczytuje faktyczną konfigurację demona SSH, sprawdza integralność plików systemowych narzędziem debsums i na tej podstawie projektuje konkretne zmiany konfiguracji wraz z ich uzasadnieniem. Każda zmiana ma zostać sprawdzona poleceniem kontrolnym przed wdrożeniem i po wdrożeniu, a raport musi pokazywać różnicę, którą wprowadził zespół.

Druga część zadania uczy myślenia w kategoriach normy. Zespół przekłada ustalenia z pomiaru na kontrolki załącznika A normy ISO/IEC 27001:2022 (93 kontrolki w czterech tematach: organizacyjnym, personalnym, fizycznym i technologicznym) i uzasadnia, dlaczego dana kontrolka pasuje do konkretnego ryzyka. Ważna jest tu świadomość, że sama lista kontroli nie jest systemem zarządzania bezpieczeństwem informacji: norma wymaga kontekstu, oceny ryzyka, planu postępowania z ryzykiem i decyzji o wdrożeniu, a dopiero potem zabezpieczeń. Zespół ma także rozróżnić utwardzanie serwera (zmniejszenie powierzchni ataku) od zarządzania dostępem i od reagowania na incydenty.

Efektem pracy jest: raport z pomiaru przed i po zmianach, lista wprowadzonych zmian z uzasadnieniem technicznym i biznesowym, tabela mapowania „zabezpieczenie → polecenie kontrolne → kontrolka normy” oraz pięciopunktowe stanowisko dla dyrektora biblioteki. Zadanie jest wykonalne w 180 minut, jeżeli zespół nie traci czasu na próby instalowania narzędzi spoza repozytorium dystrybucji.

Biblioteka miejska im. Cypriana Norwida, licząca 34 tysiące mieszkańców, obsługuje wypożyczalnię samoobsługową, katalog zbiorów cyfrowych, system rezerwacji oraz 11 stanowisk komputerowych w czytelni. Wszystkie usługi działają na jednym serwerze, który w marcu 2026 roku przeszedł na nowy sprzęt, ale konfigurację przeniesiono ze starego serwera w całości, łącznie z listą kont i parametrami SSH. Administrator, który to zrobił, odszedł z pracy i nie pozostawił żadnej dokumentacji konfiguracji ani planu przywracania.

Pierwszy przegląd wykazał cztery problemy, które studenti muszą sami potwierdzić pomiarem. Po pierwsze, serwer loguje się przez SSH z hasłem, a konto root ma zablokowaną metodę logowania hasłem, ale nie jest wyłączone całkowicie, więc dostęp kluczem dla roota pozostaje możliwy. Po drugie, włączone jest przekierowanie X11, które nie jest niczym potrzebne w bibliotece. Po trzecie, na serwerze zainstalowano zestaw pakietów deweloperskich wraz z kompilatorem i narzędziem do zrzutów ekranu, pozostawionymi po testach aplikacji katalogowej. Po czwarte, nikt nie sprawdzał, czy pliki systemowe odpowiadają temu, co zainstalował administrator pakietów.

Biblioteka przechowuje w katalogu cyfrowym materiały o znaczeniu kulturalnym, których nie wolno utracić: cyfrowe kopie prasy lokalnej oraz nagrania spotkań społecznych udostępniane w sieci biblioteki. W katalogu czytelni dostęp do sieci ma kilkanaście terminali publicznych, więc kluczowe znaczenie ma odcięcie środowiska czytelni od zasobów administracyjnych serwera. Dyrektor biblioteki nie rozumie różnicy między „słabym hasłem” a „słabą konfiguracją serwera” i oczekuje raportu, który da się przedstawić na posiedzeniu zarządu.

Grupa laboratoryjna otrzymuje maszynę wirtualną z zainstalowanym Debianem 11, dostępem administracyjnym i skopiowaną konfiguracją serwera biblioteki (nieużywane konta, standardowe narzędzia deweloperskie, domyślne ustawienia SSH). Zadaniem zespołu jest wykonanie pełnego cyklu: pomiar, analiza, zaprojektowanie zmian, wdrożenie, ponowny pomiar i raport wraz z mapowaniem na kontrolki normy. Dodatkowo zespół musi przygotować krótką instrukcję powtarzalnego przeglądu, którą biblioteka będzie wykonywać sama raz na kwartał.

• Debian 11 lub Ubuntu 22.04 z uprawnieniami administracyjnymi (dostęp przez konsolę lub konto z sudo)
• Lynis (pakiet lynis) do audytu konfiguracji i oceny utwardzenia systemu
• ssh-audit (pakiet ssh-audit) do oceny kryptografii oferowanej przez demona SSH
• openssh-server, narzędzia debsums i dpkg do kontroli integralności plików pakietów
• auditd (pakiet auditd) i journald do oceny zbierania dzienników
• Edytor tekstu oraz arkusz kalkulacyjny do tabeli mapowania i raportu
• Dostęp do aktualnej treści załącznika A normy ISO/IEC 27001:2022 (wersja płatna) lub do jej bezpłatnego wykazu kontrolk w serwisie NASK (proszę o udostępnienie wykazu w formie PDF lub drukowanej przed zajęciami)

1. Wykonajcie inwentaryzację serwera: jakie usługi działają, jakie porty nasłuchują, które konta mają dostęp do powłoki i jakie są ich powłoki logowania. Wynik zapiszcie w tabeli, bo bez niej nie da się odróżnić usługi potrzebnej od zbędnego pakietu.
2. Uruchomcie pierwszy pomiar narzędziem Lynis w trybie pełnym i zapiszcie wynik. Zmierzcie czas pomiaru, bo w sprawozdaniu musicie podać realny koszt czasowy przeglądu.
3. Odczytajcie wynik punkt po punkcie: co oznacza indeks utwardzenia, ile testów wykonano, które kategorie testów zostały pominięte. Wyjaśnijcie w sprawozdaniu, czego ten wynik nie mierzy (np. logiki aplikacji i uprawnień w bazie danych).
4. Wydobądźcie z dziennika Lynis listę ostrzeżeń i sugestii (testy, które nie przeszły) i sklasyfikujcie każdą pozycję: dotyczy realnego zabezpieczenia biblioteki czy wynika z nadmiarowego oprogramowania na maszynie deweloperskiej.
5. Wyjaśnijcie w zadaniu różnicę między trzema strategiami: utwardzaniem (mniej atakowalna powierzchnia), ograniczaniem dostępu (mniej uprawnień) i zwiększaniem widoczności (dzienniki, alarmy). Dla każdej z czterech opisanych w scenariuszu usterek wskażcie, którą strategią się ją usuwa.
6. Zbierzcie faktyczną, efektywną konfigurację demona SSH (nie zawartość pliku, tylko parametry po sparsowaniu przez sam demon) i porównajcie ją z polityką, którą sami przygotujecie: brak logowania hasłem, wyłączone logowanie roota, ograniczona liczba prób, wyłączone przekierowanie X11 i tylko potrzebne algorytmy.
7. Uruchomcie ssh-audit wobec własnego serwera i odczytajcie sekcje: algorytmy wymiany klucza, podpisu hosta, szyfrowania i uwierzytelniania wiadomości. Zidentyfikujcie pozycje oznaczone jako błędne i wyjaśnijcie, dlaczego są ryzykowne.
8. Wprowadźcie co najmniej cztery zmiany w konfiguracji SSH, sprawdzając składnię przed przeładowaniem usługi i testując połączenie w oknie awaryjnym, żeby nie zablokować sobie dostępu. Po przeładowaniu uruchomcie ssh-audit ponownie i porównajcie wyniki przed oraz po.
9. Sprawdźcie stan kont: które mają zablokowane hasło, które nie mają hasła w ogóle, które mają powłokę umożliwiającą logowanie, a które są kontami usługowymi. Usuńcie lub zablokujcie nieużywane konta, a dla kont systemowych ustawicie powłokę ograniczającą.
10. Sprawdźcie uprawnienia specjalne plików (SUID i SGID) i wyjaśnijcie, dlaczego uprawnienie SUID zmienia sytuację bezpieczeństwa. Usuńcie uprawnienie SUID tam, gdzie narzędzie nie jest potrzebne przez nikogo poza administratorem.
11. Uruchomcie kontrolę integralności plików dla kilku pakietów bibliotecznych (np. lynis, openssh-server) i wyjaśnijcie, co dokładnie porównuje to narzędzie. Wskażcie, czego ono nie wykryje: zmian w konfiguracji, plików spoza pakietów, modułów jądra i zmian w działających procesach.
12. Przeprowadźcie odwracalną demonstrację wykrycia zmiany: zmodyfikujcie jeden plik należący do pakietu w sposób, który można cofnąć, uruchomcie kontrolę ponownie, pokażcie wykrycie, a następnie przywróćcie plik i potwierdźcie brak zmian. Ten eksperyment jest ważniejszy niż sam wynik kontroli.
13. Oceńcie zbieranie dzienników: trwałość i rozmiar dziennika systemowego, poziom logowania, możliwość wysłania dzienników poza serwer, synchronizację czasu. Podajcie konkretne polecenia kontrolne i wyniki, a nie ogólne zalecenie „włącz logowanie”.
14. Sprawdźcie stan aktualizacji (lista pakietów do aktualizacji, w tym bezpieczeństwa) i zaplanujcie regularne instalowanie poprawek. Wyjaśnijcie, dlaczego serwer z dostępem z sieci biblioteki powinien być aktualizowany częściej niż stacja biurkowa.
15. Opracujcie tabelę mapowania: każde wdrożone zabezpieczenie, polecenie, które je potwierdza, i kontrolka normy ISO/IEC 27001:2022, do której się odnosi. Użyj kontrolek z tematu technologicznego (np. 8.2 uprawnienia uprzywilejowane, 8.5 bezpieczne uwierzytelnianie, 8.8 zarządzanie podatnościami, 8.9 zarządzanie konfiguracją, 8.15 rejestrowanie zdarzeń, 8.24 stosowanie kryptografii) oraz co najmniej jednej z tematu organizacyjnego (np. 5.7 informacje o zagrożeniach).
16. Wybierzcie pięć kontrolk, które da się wdrożyć w ciągu dwóch tygodni, i policzcie dla każdej koszt (czas pracy, ewentualne pakiety) oraz korzyść. Uzasadnijcie kolejność wdrożenia, bo kolejność wynika z ryzyka, a nie z listy kontroli.
17. Wykonajcie pomiar kontrolny po zmianach i porównajcie indeks utwardzenia, liczbę wykrytych problemów oraz wynik ssh-audit przed i po. Wyjaśnijcie w raporcie, dlaczego wzrost indeksu o kilka punktów nie oznacza dużej poprawy bezpieczeństwa, i wskażcie, co wciąż pozostaje otwarte.
18. Przygotujcie raport dla dyrektora biblioteki (maksymalnie jedna strona, sześć punktów) z decyzjami do zatwierdzenia oraz instrukcję przeglądu kwartalnego: kto, jakie polecenia, w jakiej kolejności, gdzie zapisuje wynik i po czym poznać, że wynik się pogorszył.

Audyt utwardzenia daje wynik liczbowy, ale nie ranking zadań. Lynis przyznaje punkty za każdą z setek kontroli i na końcu wypisuje indeks, który można porównać między kolejnymi pomiarami. Warto pokazać na obronie, że indeks jest skalą względną: ten sam wynik 58 oznacza co innego na obrazie systemu z kompilatorem i na serwerze z samym pakietem lynis. Dlatego w sprawozdaniu zawsze podawajcie obok indeksu pełną listę wykrytych problemów, bo to ona jest naprawdę użyteczna dla administratora.

Skutecznym sposobem pracy z Lynis jest numer testu. Każdy komunikat w dzienniku zawiera identyfikator, na przykład HRDN-7222, i ten identyfikator pozwala wypisać szczegóły pojedynczej kontroli, zamiast przeglądać setki linii. Numer testu jest też dobrym kotwiczeniem w raporcie, bo audytor z zewnątrz odtworzy dokładnie tę samą kontrolę. Konfigurację SSH trzeba czytać z demona, a nie z pliku. Plik konfiguracyjny zawiera dyrektywy, komentarze i wartości domyślne, a demon po sparsowaniu pliku pokazuje konfigurację efektywną, wraz z wartościami domyślnymi i wynikiem dopasowania pierwszej dopasowanej reguły. To różnica, o której studenci często zapominają: ktoś dopisuje PasswordAuthentication no na końcu pliku, a wcześniej ustawiona reguła Match lub opcja w konfiguracji globalnej wygrywa, bo pierwsza dopasowana wartość wygrywa.

Drugie narzędzie odpowiada na inne pytanie. Lynis mówi, czy parametr jest włączony, a ssh-audit mówi, jakich algorytmów serwer w ogóle używa i czy któryś z nich jest uznawany za słaby. Oznaczenia [fail] i [warn] odnoszą się do katalogu algorytmów, a nie do wdrożenia na konkretnej maszynie, dlatego każdą pozycję trzeba ocenić w kontekście: algorytm słaby kryptograficznie, który nie jest w ogóle oferowany, nie jest problemem, a pozycja oznaczona jako ostrzeżenie może wynikać z nowej, jeszcze nieopisanej w katalogu nazwy.

Integralność plików systemowych sprawdza się względem sum kontrolnych zapisanych przy instalacji pakietów. Ważne jest zrozumienie granic tej metody: narzędzie porównuje pliki z listą należącą do pakietu, więc wykryje podmieniony plik wykonawczy, ale nie zobaczy zmiany w pliku konfiguracyjnym, w skrypcie umieszczonym w katalogu domowym ani w module jądra. Dlatego debsums traktujemy jako jedną z warstw, a nie jako dowód integralności całego systemu.

Mapowanie na kontrolki normy jest ćwiczeniem dyscypliny myślenia, a nie dekoracją. Norma ISO/IEC 27001:2022 ma 93 kontrolki w czterech tematach i wymaga od organizacji udokumentowanego wyboru, które kontrolki wdraża i dlaczego pozostałe pomija. Zabezpieczenie, które nie ma właściciela, terminu przeglądu i miernika działania, jest w sprawozdaniu audytora zapisane jako „istnieje, ale nie działa”, dlatego w tabeli obok kontrolki podajcie zawsze trzy rzeczy: kto sprawdza, jak często i w jaki sposób potwierdza skuteczność.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Zautomatyzowany audyt podatności serwera Linux za pomocą skanera Lynis: analiza wskaźnika utwardzenia i wdrożenie rekomendacji.
2. Rygorystyczna rekonfiguracja demona OpenSSH: wyłączenie logowania roota, autoryzacji hasłem, wymuszenie kluczy Ed25519 i bezpiecznych KEX.
3. Implementacja monitorowania integralności plików systemowych za pomocą narzędzia AIDE z bazą referencyjną chronioną przed modyfikacją.
4. Redukcja powierzchni ataku: deinstalacja zbędnych pakietów, wyłączenie nieużywanych usług systemowych oraz przestarzałych protokołów.
5. Mapowanie zidentyfikowanych niezgodności na środki bezpieczeństwa Załącznika A normy ISO/IEC 27001:2022 (A.8.8, A.8.9, A.8.20).
6. Wdrożenie mechanizmów automatycznych aktualizacji bezpieczeństwa oraz restrykcyjnych uprawnień systemu plików.

Przykładowe wnioski (wzór do sprawozdania): Zastosowanie audytora bezpieczeństwa Lynis na serwerze biblioteki pozwoliło na podniesienie wskaźnika utwardzenia z wyjściowego poziomu 54 punktów do bezpiecznej wartości 88 punktów. Kluczowym krokiem było całkowite zrekonfigurowanie usługi OpenSSH, w której wyłączono uwierzytelnianie hasłowe na rzecz kluczy asymetrycznych Ed25519 oraz ograniczono dopuszczalne algorytmy wymiany kluczy. Wdrożenie narzędzia AIDE zabezpieczyło krytyczne katalogi systemowe przed potajemną modyfikacją, gwarantując integralność plików konfiguracyjnych i bibliotek współdzielonych. Wyłączenie zbędnych usług sieciowych oraz aktywacja zapory nftables z domyślną polityką drop zredukowało liczbę otwartych portów do absolutnego minimum. Zrealizowane prace utwardzające zostały bezpośrednio powiązane ze środkami kontroli ISO/IEC 27001:2022, zapewniając pełną zgodność instytucji publicznej z wytycznymi cyberbezpieczeństwa.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony przed poszczególnymi rodzajami zagrożeń. Kon5 Szyfrowanie w przechowywaniu danych oraz zarządzanie nośnikami i kluczami szyfrującymi.

Celem zadania jest przejście od zalecenia („szyfruj dane”, „kasuj nośniki”) do procedury, którą da się wykonać dwukrotnie i sprawdzić. Zespół musi zinwentaryzować nośniki używane w sieci handlowej, dobrać metodę ochrony do rodzaju danych, zastosować szyfrowanie na przenośnym nośniku, skonfigurować ograniczenie nośników wymiennych na stacjach z dostępem do płatności, a następnie wykonać utylizację nośnika wraz z dowodem, że dane zniknęły.

Najważniejszą częścią zadania jest pomiar skuteczności. Zespół ma pokazać, czym różni się usunięcie pliku od skasowania danych, dlaczego nadpisanie zawartości pliku na dysku magnetycznym nie gwarantuje zatarcia starej treści z obszarów nieprzydzielonych, oraz dlaczego na dysku typu SSD nadpisywanie jest nieskuteczne z powodu zużywania komórek pamięci. Zamiast przyjmować te twierdzenia, zespół wykonuje eksperyment: tworzy obraz nośnika, zapisuje w nim dane o znaczeniu handlowym, kasuje je metodą z instrukcji, a następnie próbuje odzyskać treść i dokumentuje wynik próby.

Zadanie obejmuje również często pomijany aspekt fizyczny: utylizacja nośnika to proces, a nie jedno polecenie. Powstaje łańcuch dowodowy (kto, kiedy, który nośnik, którą metodą, w obecności świadka) oraz protokół zniszczenia z numerem seryjnym. Zespół ma przygotować oba dokumenty, ponieważ w razie kontroli lub reklamacji to one, a nie fakt, że ktoś „włączył shred”, stanowią dowód należytej staranności.

Sieć handlowa liczbąca 62 sklepy, prowadzona przez spółkę Detail Dom Sp. z o.o., działa od 2011 roku. W każdym sklepie działają kasy fiskalne z systemem sprzedażowym, drukarka etykiet, terminal płatniczy oraz komputer magazynowy. Kasy są połączone z centralnym systemem raportowym przez łącza WAN, a magazyny regionalne mają dostęp do kopii bazy kart płatniczych przechowywanych na dyskach sieciowych. W siedzibie centrali działa dział informatyczny liczący sześć osób, a sprzęt naprawia i modernizuje zewnętrzny serwis, który w 2025 roku zerwał umowę i pozostawił po sobie trzy dyski twarde.

Audyt przeprowadzony w marcu 2026 roku wykazał, że wycofane dyski leżały w magazynie na ogólnodostępnej półce przez cztery miesiące, a w dwóch sklepach serwisant zostawił dysk z systemem kas w śmietniku. W sklepach, które obsługują program lojalnościowy, dane klientów zapisywane są na nośnikach USB przekazywanych między sklepami, bo centralny system raportowy nie działa w trybie offline. W trzech sklepach kupcy przywożyli własnościórkowe pendrive’y, a w jednym serwisowym laptopie z 2018 roku nadal działały zapisane hasła do kas.

Równolegle trwa incydent: jeden z pracowników zgłosił zgubiony telefon służbowy z dostępem do aplikacji magazynowej i do poczty firmowej, a właściciel telefonu nie zgłosił utraty do działu informatycznego przez cztery dni. Polityka informatyczna firmy wymaga zgłoszenia utraty sprzętu w ciągu 24 godzin, a dla nośników zawierających dane osobowe przewiduje zgłoszenie naruszenia ochrony danych. Zespół musi przygotować procedurę, która te wymagania spełnia i która da się przećwiczyć na stanowisku kasowym.

Grupa laboratoryjna otrzymuje stanowisko z Debianem 11, dwa nośniki USB w postaci plików obrazu, dostęp do konta z uprawnieniami administracyjnymi, przykładową bazę CSV z danymi testowymi (imiona, sumy płatności, numery kart zastąpcze) oraz zainstalowane narzędzia cryptsetup, usbguard i shred. Zadaniem zespołu jest przejść pełną ścieżkę: inwentaryzacja, ochrona w użyciu, kontrola nośników wymiennych, utylizacja z dowodem skuteczności oraz procedura dla utraconego urządzenia, a na koniec krótka ocena, które z zabezpieczeń są techniczne, a które organizacyjne.

• Debian 11 lub Ubuntu 22.04 z uprawnieniami administracyjnymi
• cryptsetup i util-linux (cryptsetup, wipefs, lsblk, blkid) do szyfrowania nośników i analizy tablicy partycji
• coreutils (shred, dd, sha256sum) do kasowania danych i wyliczania sum kontrolnych
• usbguard do ograniczania nośników wymiennych (pakiet usbguard, w tym reguły w pliku /etc/usbguard/rules.conf)
• udev (udevadm, lsusb) do rozpoznawania podłączonych urządzeń
• Aparat cyfrowy lub telefon z aplikacją do zrzutu ekranu, własne nośniki USB do testu lub ich pliki obrazu
• Edytor tekstowy, arkusz kalkulacyjny i drukarka do inwentaryzacji nośników, protokołu zniszczenia i ścieżki dowodowej

1. Zbudujcie arkusz inwentaryzacji nośników: typ (dysk, dysk SSD, pendrive, karta pamięci, dysk w laptopie, nośnik sieciowy), numer seryjny, właściciel, lokalizacja, rodzaj danych (dane kart płatniczych, dane osobowe, cennik, monitoring wideo), sposób ochrony. Wyjaśnijcie, dlaczego bez numeru seryjnego utylizacja nośnika jest nieudokumentowana.
2. Sklasyfikujcie dane na każdym nośniku i uzasadnijcie wybór ochrony: nośnik z danymi kart płatniczych wymaga innego traktowania niż nośnik z cennikiem, który można po prostu zniszczyć fizycznie.
3. Sprawdźcie, czy system rozpoznaje nośniki wymienne, i zapiszcie wynik: jakie urządzenia USB są widoczne, jakich reguł używa system, jaki identyfikator ma nośnik testowy (identyfikator producenta i model, numer seryjny).
4. Zróbcie obraz testowego nośnika i zapiszcie w nim dane testowe, a następnie udowodnijcie, że są w nim obecne (np. wyszukiwanie wzmianki w pliku obrazu). Zapiszcie w protokole sumę kontrolną pliku obrazu przed zabiegiem.
5. Zaszyfrujcie nośnik testowy w standardzie LUKS2, utwórzcie w nim system plików i zapiszcie dane. Opiszcie, gdzie przechowywane są klucze, co oznacza sformatowanie kontenera i dlaczego zniszczenie klucza unieważnia wszystkie wcześniej zapisane dane.
6. Zaprojektujcie politykę kluczy do nośników wymiennych: kto generuje klucz, gdzie jest przechowywany, jak często jest wymieniany, co robicie przy utracie nośnika, i dlaczego nie należy przechowywać klucza na tym samym nośniku, który szyfruje.
7. Skonfigurujcie ograniczenie nośników wymiennych na stanowisku kasowym (usbguard lub reguła udev z dopuszczeniem konkretnego urządzenia) i przetestujcie scenariusze: dozwolony pendrive, nieznany pendrive, urządzenie klasy sieciowej (klawiatura, czytnik kart).
8. Wyjaśnijcie w sprawozdaniu różnicę między kontrolą techniczną (system odmawia dostępu) a organizacyjną (polityka, rejestr zatwierdzonych nośników, szkolenie). Wskażcie, co się stanie, gdy pracownik zatrudniony na stanowisku kasowym zainstaluje własne narzędzie omijające zakaz.
9. Przygotujcie procedurę dla nośnika znalezionego (zagubionego, oddanego w sekretariacie, pozostawionego w drukarce). Określcie, kiedy nośnik jest oddawany do zniszczenia, a kiedy zwracany właścicielowi, i jakie dane trzeba z niego odzyskać przed utylizacją.
10. Wykonajcie eksperyment kasowania danych metodą nadpisywania na pliku obrazu nośnika, z zapisaniem wcześniej utworzonej wzmianki tekstowej w losowym miejscu pliku. Zmierzycie, ile trwa operacja dla obrazu o rozmiarze kilkunastu megabajtów, i przeliczcie, ile zajęłaby dla dysku 500 GB.
11. Po nadpisaniu sprawdźcie, czy wzmianka tekstowa nadal występuje w pliku obrazu, i zanotujcie wynik próby. Nasz eksperyment pokazuje, dlaczego nadpisanie pliku nie wystarcza: treść z pozostałych bloków i z kopii w cieniu pozostaje w pliku, dopóki nie zostanie nadpisany cały nośnik.
12. Usuńcie tablicę podziału nośnika (wipefs) i opiszcie, co dokładnie usuwa to polecenie: sygnatury tablicy i systemów plików, ale nie zawartość danych. Wyjaśnijcie, dlaczego usunięcie tablicy jest elementem przygotowania, a nie dowodem zniszczenia danych.
13. Zniszczcie klucze w kontenerze LUKS2, a potem zmierzycie, co dzieje się przy próbie otwarcia kontenera starą frazą. Zapiszcie komunikaty systemu i czas wykonania operacji oraz wyjaśnijcie, dlaczego to jest metoda kryptograficznego zniszczenia danych i dlaczego jest szybsza od pełnego nadpisania.
14. Omówcie różnicę między nośnikiem magnetycznym a dyskiem SSD. Wskażcie, dlaczego na SSD nadpisywanie działa inaczej niż na dysku HDD, dlaczego polecenie bezpiecznego kasowania na SSD działa na poziomie kontrolera, a nie pliku, i jaką rolę odgrywa szyfrowanie całego nośnika (LUKS z automatycznym montowaniem przy starcie systemu).
15. Zastosujcie właściwą metodę do nośnika z systemem plików na dysku: nadpisanie wieloprzebiegowe albo zniszczenie kluczy, jeśli nośnik był szyfrowany. Podajcie w raporcie, którą metodę wybraliście i dlaczego, oraz jakie ryzyko pozostaje przy każdej z nich.
16. Przygotujcie ścieżkę dowodową i protokół zniszczenia: numer nośnika z inwentaryzacji, data i osoba wykonująca, świadek, metoda, wynik próby weryfikacji, podpisy. Wyjaśnijcie, dlaczego protokół powinien wskazywać świadka i dlaczego sam nośnik po zniszczeniu powinien zostać zatrzymany lub zniszczony w sposób nieodwracalny.
17. Opracujcie procedurę utraty urządzenia mobilnego: blokada konta w katalogu firmowym lub usłudze, reset hasła i sesji, unieważnienie tokenów, ocena, czy zdarzenie stanowi naruszenie ochrony danych, i zgłoszenie zgodne z wewnętrzną polityką oraz przepisami o ochronie danych osobowych.
18. Podsumujcie zadanie tabelą: techniczne zabezpieczenia, zabezpieczenia organizacyjne, zabezpieczenia fizyczne, każde z kosztem wdrożenia, prawdopodobieństwem błędu i związanym z nim ryzykiem. Wyjaśnijcie, dlaczego najskuteczniejsze zabezpieczenie w tym zadaniu to szyfrowanie, a nie program antywirusowy.

W tym zadaniu wynik eksperymentu jest ważniejszy niż nazwa polecenia. Zanim zaczniecie, ustalcie jeden nośnik testowy i jeden zapisany w nim znacznik, na przykład nazwę fikcyjnej karty klienta z numerem, którego nie ma w żadnej innej bazie. Cały dowód opiera się na tym, że każdy zespół potrafi wskazać moment, w którym znacznik przestał być odczytywalny, i polecenie, które to spowodowało. Bez znacznika kontrola jest tylko opisem.

Kolejna warstwa to tablica podziału. wipefs usuwa sygnatury, dzięki którym system rozpoznaje na nośniku partycje i systemy plikowe. Operacja jest szybka, ale nie niszczy danych, dlatego w protokole zniszczenia jest wpisywana jako przygotowanie, a nie jako zniszczenie danych. Ten sam plik, po usunięciu tablicy, wciąż zawiera wszystkie bajty danych i wciąż da się je odczytać wyszukiwaniem. Na nośniku szyfrowanym standardem LUKS2 zniszczenie kluczy wslotów jest najszybszą metodą z możliwych, a jej skutek jest jednoznaczny: bez klucza dane są nie do odzyskania, nawet dla producenta dysku. Operacja nadpisuje miejsca, w których zapisano klucze, i trwa ułamki sekundy, niezależnie od pojemności nośnika. Dla procesu zakupowego jest to najlepsza własność, bo czas utylizacji nie rośnie z wielkością dysku.

Na dysku typu SSD powyższy obraz zniekształca obietnicę nadpisywania. Dysk SSD nie nadpisuje istniejącego miejsca, tylko rozważa zapisanie danych w innym wolnym bloku i oznacza poprzedni blok jako nieaktualny, aby dane starej wersji pozostały w komórce pamięci. Z tego względu polecenie shred na SSD nie gwarantuje zatarcia, a polecenie bezpiecznego kasowania na SSD działa na poziomie kontrolera pamięci, nie na pliku. Dlatego w sieci handlowej najskuteczniejszą ochroną jest szyfrowanie całego nośnika z kluczem przechowywanym poza nim, a utylizacja to zniszczenie klucza.

Ograniczenie nośników wymiennych na stanowisku kasowym jest zabezpieczeniem organizacyjnym wzmocnionym techniczną kontrolą systemu. Domyślna polityka większości systemów pozwala na podłączenie dowolnego urządzenia pamięci masowej, a to oznacza, że pracownik może wynieść z serwera kasowego bazę z danymi kart płatniczych na pendrive i zniszczyć ją w koszu albo w domu. Narzędzie usbguard pozwala zdefiniować politykę na poziomie urządzenia: dozwolone identyfikatory, serial, klasa, typ złącza i dodatkowo zasady dla podłączonych urządzeń.

Protokół zniszczenia i ścieżka dowodowa decydują o tym, czy utylizacja będzie wiarygodna. W protokole powinny się znaleźć: numer z inwentaryzacji, identyfikator nośnika, data, osoba wykonująca, świadek, metoda, wynik próby weryfikacyjnej i podpisy. Sama metoda jest jednym z elementów, a nie całością dowodu. Dodatkowo warto ustalić, czy nośnik po zniszczeniu danych zostaje zatrzymany w sejfie, czy jest fizycznie niszczony, bo to inna kategoria dowodu i inny koszt.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Standardy bezpiecznego niszczenia danych (NIST SP 800-88 Rev. 1): metody Clear, Purge oraz Destroy w zależności od nośnika i poziomu ryzyka.
2. Różnice technologiczne w czyszczeniu dysków magnetycznych HDD a nośników półprzewodnikowych SSD (ATA Secure Erase vs Crypto Scramble).
3. Zastosowanie kasowania kryptograficznego (Cryptographic Erasure): zniszczenie klucza nadrzędnego w wolumenach LUKS2/BitLocker.
4. Wdrożenie technologii blokowania nośników wymiennych USB (USBGuard w Linux / polisy GPO) w celu przeciwdziałania wyciekom danych.
5. Procedura formalnego protokołowania utylizacji nośników: ewidencja numerów seryjnych, certyfikaty zniszczenia i świadectwa degaussingu.
6. Postępowanie w przypadku kradzieży sprzętu: weryfikacja zaszyfrowania i zgłaszanie incydentu zgodnie z art. 33 i 34 rozporządzenia RODO.

Przykładowe wnioski (wzór do sprawozdania): Opracowanie i wdrożenie procedury utylizacji pamięci masowych zgodnie ze standardem NIST SP 800-88 Rev. 1 wyeliminowało ryzyko odzyskania danych klientów sieci handlowej z wycofywanych komputerów. Zastosowanie poleceń ATA Enhanced Secure Erase oraz kasowania kryptograficznego w dyskach SSD pozwoliło na nieodwracalne zniszczenie komórek pamięci flash, których tradycyjne nadpisywanie nie było w stanie skutecznie wyczyścić. Wszystkie firmowe laptopy zabezpieczono pełnym szyfrowaniem wolumenów LUKS2 z podwójnym uwierzytelnianiem, co w razie fizycznej utraty urządzenia chroni dane osobowe przed nieuprawnionym odczytem. Zaimplementowanie usługi USBGuard na komputerach magazynowych zablokowało możliwość podłączania prywatnych pendrive'ów, uniemożliwiając niekontrolowany wyciek baz sprzedaży. Formalne protokołowanie każdego wycofanego nośnika wraz z sumami kontrolnymi pozwala firmie na bezdyskusyjne udowodnienie należytej staranności w razie kontroli UODO.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych, w tym zagrożenia związane z łańcuchem dostaw i incydentami. Metody i środki ochrony: zarządzanie ciągłością działania i reagowanie na incydenty. Kon2 Podstawy kryptograficznej ochrony informacji. Warunki zapewnienia poufności i autentyczności informacji.

Celem zadania jest przygotowanie oceny dostawcy usługi, która jest w stanie wytrzymać pytania zarządu, klienta i organu kontroli. Zespół dostaje do oceny przedsiębiorstwo wodociągowo-kanalizacyjne, które przenosi system ewidencji wodomierzy i system zgłoszeń awarii do usługi chmurowej, oraz komplet dokumentów: ofertę, projekt umowy, opis usługi i formularz samooceny bezpieczeństwa dostawcy. Zadaniem jest ocena, czy umowa i organizacja zapewniają ciągłość usługi kluczowej, oraz zaprojektowanie postępowania wyjściowego z dostawcą.

Zadanie jest w dużej mierze analityczne i dlatego wymaga od studentów precyzji prawnej. Trzeba odróżnić operatora usługi kluczowej od podmiotu publicznego, rozróżnić obowiązki wynikające z ustawy o krajowym systemie cyberbezpieczeństwa od zobowiązań umownych, wskazać, gdzie w umowie powinno znaleźć się prawo do audytu, termin powiadamiania o incydencie, obowiązek usuwania danych po zakończeniu współpracy i format eksportu danych. Zespół musi też sprawdzić, czy zakup usługi w formie dostawy cyfrowej podlega przepisom o zamówieniach na dostawy cyfrowe, i wskazać w opisie postępowania te wymagania, które mogłyby ograniczyć swobodę wyboru dostawcy.

Efektem pracy jest pakiet dokumentów: karta oceny dostawcy wraz z wynikiem punktowym i listą zastrzeżeń, wykaz klauzul do umowy z uzasadnieniem każdej, plan wyjścia z dostawcą z osiągalnymi terminami, analiza ryzyka dla łańcucha dostaw oraz stanowisko dla zarządu. W ocenie za najważniejsze uznano zabezpieczenie możliwości wyjścia: dostawca, któremu nie można odebrać danych w otwartym formacie, jest w praktyce dostawcą, z którego nie można zrezygnować.

Przedsiębiorstwo Wodociągi i Kanalizacja Sp. z o.o. obsługuje 78 tysięcy mieszkańców, prowadzi 240 kilometrów sieci wodociągowej i 90 kilometrów kanalizacyjnej oraz dwie oczyszczalnie ścieków. Przedsiębiorstwo zatrudnia 310 pracowników, a system ewidencji wodomierzy, system zgłoszeń awarii oraz system bilingowy działają w jednej infrastrukturze. Przedsiębiorstwo jest spółką prawa handlowego z udziałem gminy, więc nie jest podmiotem publicznym w rozumieniu ustawy o krajowym systemie cyberbezpieczeństwa, ale świadczy usługę kluszkową.

W 2025 roku zarząd zdecydował o wdrożeniu usługi chmurowej. Wybrano dostawcę, który oferuje system jako usługę, z umową na 36 miesięcy, z możliwością przedłużenia, bez gwarancji eksportu danych w formacie otwartym. W umowie przewidziano SLA zapewniające dostępność 99,5%, zgłaszanie incydentów w formie zgłoszenia pocztą, karę umowną w wysokości 1% wartości rocznej opłaty za każdy dzień niedostępności powyżej progu oraz prawo dostawcy do modyfikacji warunków usługi z 60-dniowym uprzedzeniem. Dostawca zlokalizował Centrum Przetwarzania Danych w kraju trzecim spoza Europejskiego Obszaru Gospodarczego i powołał kilku podprzetwarzających, których listy nie udostępnia.

Mimo pozornie dobrej ceny wdrożenie przeciąga się od dziewięciu miesięcy. Powód jest techniczny: system ewidencji wodomierzy wymaga przechowywania historii odczytów i dokumentacji zdjęć wodomierzy, a dostawca zaproponował eksport do pliku, który można odczytać tylko w jego aplikacji. Równolegle przedsiębiorstwo ucierpiało dwukrotnie z powodu niedostępności usługi: w pierwszym przypadku zgłoszenie awarii wodociągowej na terenie osiedla mieszkalnego przyjęto z opóźnieniem 40 minut, w drugim system bilingowy nie wystawił faktur za okres rozliczeniowy, co wymusiło ręczne ich wystawienie.

Grupa laboratoryjna otrzymuje pakiet dokumentów (opis usługi, projekt umowy, projekt umowy powierzenia przetwarzania danych, formularz samooceny dostawcy, ostatni raport dostępności) oraz dostęp do środowiska laboratoryjnego, w którym działa prosta aplikacja webowa z danymi testowymi zaszyfrowanymi nośnikiem. Zadaniem zespołu jest przeprowadzenie oceny dostawcy, wynegocjowanie (na papierze) listy klauzul ochronnych, przygotowanie planu wyjścia i jego próbnego wykonania, w tym eksportu danych, kontroli ich integralności i zniszczenia kopii u dostawcy. Zespół ma również ocenić, czy w tym przypadku zamówienie powinno być prowadzone w trybie ustawy Prawo zamówień publicznych i jakie ma to skutki dla wyboru dostawcy.

• Dokumenty przygotowane przez prowadzącego: opis usługi chmurowej, projekt umowy, formularz samooceny bezpieczeństwa dostawcy, raport dostępności za ostatnie kwartały
• Debian 11 lub Ubuntu 22.04 z narzędziami tar, sha256sum, gnupg (gpg) i openssl do eksportu danych, kontroli integralności i podpisania kopii
• Środowisko laboratoryjne z aplikacją webową i danymi testowymi, z możliwością wykonania eksportu
• Dostęp do aktualnego tekstu ustawy z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa oraz ustawy z dnia 11 września 2019 r. Prawo zamówień publicznych wraz z przepisami wykonawczymi (proszę o udostępnienie wydruków przed zajęciami)
• Dostęp do aktualnego tekstu rozporządzenia Rady Ministrów w sprawie dokumentów o kluczowym znaczeniu dla bezpieczeństwa narodowego, jeśli zajęcia dotyczą oceny dostawcy spoza kraju
• Edytor tekstowy, arkusz kalkulacyjny i szablon karty oceny dostawcy przygotowany przez prowadzącego

1. Ustalcie status podmiotu w rozumieniu ustawy o krajowym systemie cyberbezpieczeństwa: czy przedsiębiorstwo jest podmiotem publicznym, czy operatorem usługi kluczowej, czy świadczy usługę cyfrową, i jaka usługa jest wskazana w wykazie usług kluszkowych. Zapiszcie podstawę prawną każdej kwalifikacji.
2. Zdefiniujcie zakres powierzony dostawcy: które kategorie danych (dane osobowe, dane o zużyciu wody, dokumentacja awarii, dane o lokalizacji), jakie systemy, jaki wolumen i jaka dostępność, oraz które z tych danych są objęte tajemnicą przedsiębiorstwa, a które stanowią dane osobowe.
3. Zbudujcie kartę oceny dostawcy: co najmniej dziesięć obszarów (bezpieczeństwo fizyczne, kontrola dostępu, szyfrowanie, zarządzanie podatnościami, dzienniki i ich dostępność, lokalizacja danych, podprzetwarzający, ciągłość działania, testy i audyty, odpowiedzialność prawna). Dla każdego obszaru podajcie ocenę, dowód i lukę.
4. Przeanalizujcie formularz samooceny dostawcy metodą krytyczną: które pytania nie mają odpowiedzi, które odpowiedzi są deklaracją bez dowodu, a których w ogóle nie zadano, choć powinny być zadane przy usłudze przetwarzającej dane osobowe i dane o lokalizacji infrastruktury krytycznej.
5. Przeanalizujcie klauzule umowne punkt po punkcie i przygotujcie listę klauzul do negocjacji: minimalny poziom usługi, prawo do kontroli (audytu) dostawcy, termin i kanał zgłaszania incydentów oraz ich skutki, obowiązek przekazania dzienników, prawo do eksportu danych w formacie otwartym, okres przechowywania danych po rozwiązaniu umowy, zakaz podprzetwarzania bez zgody, zgoda na podmioty trzecie w państwach spoza Europejskiego Obszaru Gospodarczego, ograniczenie jednostronnej zmiany warunków.
6. Uzasadnijcie każdą proponowaną klauzulę wskazaniem ryzyka, które zamyka, i konsekwencji jej braku. Wyjaśnijcie, dlaczego prawo do audytu jest warunkiem możliwości kontroli faktycznego stanu bezpieczeństwa, a nie elementem formalnym.
7. Opiszcie, dlaczego prawo do eksportu danych w formacie otwartym jest warunkiem realnej możliwości zmiany dostawcy, i wskażcie, które formaty uznać za otwarte, a które nie: plik z danymi eksportowanym wyłącznie do aplikacji dostawcy nie jest formatem otwartym, nawet jeśli ma rozszerzenie pliku tekstowego.
8. Opracujcie plan wyjścia z dostawcą: warunki poprzedzające (rozwiązanie umowy), przeprowadzenie eksportu danych, weryfikacja kompletności i czytelności, test działania na danych, przeniesienie na środowisko zastępcze, okres równoległego działania, usunięcie kopii u dostawcy i potwierdzenie usunięcia, archiwizacja i zabezpieczenie kopii własnej, przegląd i aktualizacja planu.
9. Wykonajcie próbny eksport danych w środowisku laboratoryjnym, zapiszcie wynik w pliku, wyliczcie sumę kontrolną eksportu i utwórzcie podpis kryptograficzny tego pliku. Wyjaśnijcie, po co podpisywać własną kopię danych, skoro źródło jest obce.
10. Zorganizujcie kontrolę integralności eksportu: zmodyfikujcie jeden bajt pliku w sposób odwracalny, wykażcie, że weryfikacja sumy i podpisu to wykrywają, i przywróćcie plik. Wyjaśnijcie różnicę między sumą kontrolną (wykrywa zmianę) a podpisem kryptograficznym (dodatkowo potwierdza, kto podpisał).
11. Przeanalizujcie klauzule SLA pod kątem realnej ochrony: czy przewidziana kara umowna jest porównywalna z kosztem przestoju, czy usługa ma znaczenie dla bezpieczeństwa publicznego, co się dzieje przy przedłużającej się niedostępności, jakie są progi eskalacji i kto po stronie dostawcy ma obowiązek powiadamiania.
12. Opracujcie analizę ryzyka łańcucha dostaw: dostawca usługi, podprzetwarzający, operator łączy telekomunikacyjnej, dostawca oprogramowania antywirusowego, dostawca usług identyfikacyjnych, dostawca sprzętu i podwykonawcy konserwacji. Dla każdego ogniwa wskażcie zagrożenie, prawdopodobieństwo, skutek, zabezpieczenie umowne i zabezpieczenie techniczne.
13. Wskażcie obowiązki przedsiębiorstwa wynikające z ustawy o krajowym systemie cyberbezpieczeństwa w zakresie, którego dotyczy projekt: zapewnienie ciągłości działania, uwzględnienie ryzyka związanego z łańcuchem dostaw i dostawcami, dokumentacja, zgłaszanie poważnych incydentów w ustawowym terminie wraz z przewidywanymi skutkami, obowiązki dostawcy usługi cyfrowej, w tym usługi przetwarzania w chmurze.
14. Ustalcie, czy usługa dostawcy jest usługą przetwarzania w chmurze w rozumieniu ustawy o krajowym systemie cyberbezpieczeństwa, i jakie ma to znaczenie dla obowiązków po obu stronach. Wyjaśnijcie, dlaczego definicja ta obejmuje przetwarzanie na infrastrukturze dostawcy i dlaczego to pozwala odmówić usługi, gdyby dostawca zadeklarował, że „to tylko wirtualne maszyny”.
15. Przeanalizujcie ścieżkę zakupową: czy przedsiębiorstwo podlega ustawie Prawo zamówień publicznych (m.in. z uwagi na udział gminy w spółce i wykonywanie zadania własnego gminy), jaki tryb i podstawę prawną należy przyjąć, oraz jakie ograniczenia nakładają przepisy o dostawach cyfrowych na specyfikację (równy dostęp, ograniczanie konkurencyjności, wymagania dotyczące dostępu do dokumentów i danych po zakończeniu dostawy). Zapiszcie wymagania, które obecnie spełniają tylko jeden dostawca, i zaproponujcie ich przepisanie.
16. Sporządźcie stanowisko dla zarządu: rekomendacja (kontynuować z warunkami, przeprowadzić postępowanie konkurencyjne, przygotować do wyjścia), uzasadnienie, trzy warunki brzegowe poniżej których nie podpisujecie umowy, oraz przewidywany koszt zmiany dostawcy wraz z terminem.

Cała ocena dostawcy krąży wokół jednego pytania: czy przedsiębiorstwo zachowuje kontrolę nad swoim systemem, czy tylko korzysta z cudzego. Odpowiedź jest prawie zawsze w zapisach umowy, a nie w deklaracjach handlowych. Dlatego zacznijcie od tabeli „co chcemy mieć” i sprawdźcie, których z tych rzeczy w ogóle nie ma w projekcie umowy: brak eksportu w formacie otwartym, brak prawa do audytu, brak terminu na usunięcie danych i brak zakazu podprzetwarzania to cztery luki, których każda z osobna wystarcza do odmowy podpisania umowy.

Status podmiotu w ustawie o krajowym systemie cyberbezpieczeństwa zmienia zakres obowiązków, dlatego trzeba go ustalić na początku, a nie w trakcie pisania wniosków. Przedsiębiorstwo wodociągowo-kanalizacyjne prowadzone przez spółkę z udziałem gminy świadczy usługę kluszkową, ale nie jest podmiotem publicznym, więc nie stosuje się do niego bezpośrednio obowiązków z rozdziału dotyczącego podmiotów publicznych. Inaczej wygląda sytuacja gminnego zakładu wodociągowego, który jest podmiotem publicznym i ma obowiązki wynikające z odrębnego artykułu ustawy. Ta różnica bywa źródłem błędnych wniosków, dlatego zawsze zapisujcie podstawę prawną kwalifikacji. Kolejny test, który warto wykonać, to próba odczytania eksportu bez aplikacji dostawcy. Format zapisany w rozszerzeniu pliku nie jest niczym: liczy się to, czy dane da się odczytać standardowymi narzędziami. Jeżeli jedynym sposobem otwarcia eksportu jest uruchomienie aplikacji dostawcy, to nie jest to format otwarty i przedsiębiorstwo nadal nie ma możliwości migracji.

Plan wyjścia działa tylko wtedy, gdy jest wcześniej przetestowany. Dlatego kluczowym ćwiczeniem jest próbny eksport danych wraz z kontrolą integralności. Własny podpis kryptograficzny pliku eksportu chroni przed sytuacją, w której dostawca podważa kompletność danych albo plik został przekazany w uszkodzonej postaci; zespół powinien umieć wykazać, że zmiana jednego bajta jest wykrywana przez zarówno sumę kontrolną, jak i weryfikację podpisu.

Ścieżka zakupowa bywa najczęściej zaniedbywaną częścią takich projektów, a przecież wybór jednego dostawcy na 36 miesięcy to decyzja o charakterze zamówienia, a nie zakupu licencji. Przepisy o dostawach cyfrowych mają na celu zapobieganie sytuacji, w której specyfikacja wymaga dokładnie jednego rozwiązania, przez co konkurencja znika. Typowe uchybienia to żądanie „własności intelektualnej w standardzie”, wymaganie jednego konkretnego formatu danych, nadmierne wymagania dotyczące gwarancji oraz brak postanowienia o udostępnieniu dokumentów i danych po zakończeniu dostawy.

Odpowiedzialność za ciągłość usługi dzieli się między umowę, prawo i własne systemy. Umowa daje narzędzia (sankcje, prawo eksportu, termin usunięcia danych), prawo nakłada obowiązki na obie strony (ciągłość, dokumentacja, zgłaszanie poważnych incydentów, zapewnienie bezpieczeństwa dostawcy), a własne systemy dają punkt odniesienia: bez kopii danych poza dostawcą i bez przetestowanego eksportu żadna umowa nie odsunie ryzyka od przedsiębiorstwa. Dlatego w rekomendacji końcowej podajcie, co kupujecie, a co zabezpiecza własnym kosztem.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Kryteria oceny dostawców usług chmurowych (CSP) dla operatorów infrastruktury krytycznej: certyfikaty ISO/IEC 27001, 27017, 27018 oraz raporty SOC 2.
2. Analiza prawna umowy powierzenia przetwarzania danych (DPA) zgodnie z art. 28 RODO: lokalizacja serwerów w EOG i obowiązki audytowe.
3. Rygory Ustawy o Krajowym Systemie Cyberbezpieczeństwa oraz dyrektywy NIS2 w zakresie zapewnienia odporności łańcucha dostaw ICT.
4. Opracowanie strategii wyjścia (Cloud Exit Strategy): unikanie uzależnienia (Vendor Lock-in) oraz prawo do eksportu danych w otwartych formatach.
5. Warunki gwarancji poziomu świadczenia usług (SLA): wskaźniki dostępności (99,99%), czasy reakcji i kary umowne za przestoje krytycznych aplikacji.
6. Zapewnienie prawa do przeprowadzenia niezależnego audytu fizycznego i logicznego u dostawcy chmury przez inspektorów operatora.

Przykładowe wnioski (wzór do sprawozdania): Szczegółowy audyt oferty dostawcy usług chmurowych dla przedsiębiorstwa wodociągowego wykazał, że powierzenie krytycznych systemów dyspozytorskich wymaga bezwzględnego spełnienia rygorów ustawy o KSC oraz dyrektywy NIS2. Kluczowym warunkiem kontraktowym było wynegocjowanie prawa do przeprowadzania niezależnych audytów bezpieczeństwa w centrach danych dostawcy oraz zagwarantowanie rezydentury danych wyłącznie na terytorium Unii Europejskiej. Wdrożona umowa powierzenia przetwarzania danych osobowych precyzyjnie określiła obowiązki informowania o incydentach w czasie krótszym niż 24 godziny od ich wykrycia. Zdefiniowanie formalnej strategii wyjścia zabezpieczyło przedsiębiorstwo przed zjawiskiem Vendor Lock-in poprzez zapewnienie ciągłego eksportu baz bilingowych do formatów niezależnych od platformy. Wprowadzenie rygorystycznych wskaźników SLA na poziomie 99,99% dostępności zagwarantowało stabilność rozliczeń i ciągłość monitorowania sieci wodociągowej.