Laboratorium 1

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Bezpieczeństwo tożsamości cyfrowej i kryptografia asymetryczna w WebAuthn.

Celem zadania jest zaprojektowanie oraz wdrożenie całościowej polityki zarządzania tożsamością i uwierzytelnianiem wieloskładnikowym (MFA) dla jednostki administracji publicznej szczebla wojewódzkiego. Projekt uwzględnia wytyczne NIST SP 800-63B oraz rekomendacje Pełnomocnika Rządu ds. Cyberbezpieczeństwa, wprowadzając bezwzględny wymóg stosowania drugiego składnika odpornego na phishing (FIDO2/WebAuthn) opartego na kryptografii asymetrycznej (klucze publiczne na krzywych eliptycznych P-256). Studenci analizują wektory ataków socjotechnicznych, przejęcia sesji oraz techniki Adversary-in-the-Middle (AiTM / reverse-proxy phishing).

W ramach laboratorium zespół konfiguruje zaawansowane moduły uwierzytelniania w systemie Linux (Pluggable Authentication Modules: pam_pwquality, pam_faillock, pam_u2f) oraz zasady zabezpieczeń grupy w Active Directory (Password Settings Objects – PSO). Zadanie porządkuje terminologię, odróżniając architekturę modułów systemowych Linux PAM od koncepcji organizacyjnej PAM/PIM (Privileged Access Management) oraz kształtuje umiejętność budowy procedur awaryjnego dostępu (Break-Glass account). Zakres prac zoptymalizowano do realizacji w 180 minut.

Mazowiecki Urząd Wojewódzki w Warszawie zatrudnia ponad 600 urzędników przetwarzających dane wrażliwe obywateli w systemach e-administracji (EZD RP, ePUAP, rejestry stanu cywilnego). W trakcie audytu bezpieczeństwa przeprowadzonego przez CSIRT wykazano, że w urzędzie obowiązywała archaiczna polityka wymuszająca comiesięczną zmianę hasła o minimalnej długości zaledwie 8 znaków, co skutkowało masowym tworzeniem haseł przewidywalnych (np. Wiosna2026!) i incydentami blokad kont po weekendach.

Dodatkowo pracownicy oraz administratorzy infrastruktury uzyskali możliwość hybrydowej pracy zdalnej przez portal VPN i pocztę przeglądarkową. Brak wymuszenia odpornego na phishing MFA doprowadził do incydentu przejęcia poświadczeń jednego z inspektorów w wyniku kampanii spear-phishingowej klonującej panel logowania Microsoft 365 (atak AiTM proxy). Złośliwy podmiot uzyskał dostęp do korespondencji urzędowej zawierającej dokumenty zastrzeżone.

Grupa laboratoryjna przyjmuje rolę zespołu audytorów i inżynierów cyberbezpieczeństwa. Zadaniem zespołu jest sporządzenie formalnego zarządzenia Dyrektora Generalnego, wdrożenie haseł frazowych (min. 16 znaków), konfiguracja modułów Linux PAM i PowerShell AD PSO, przygotowanie wdrożenia tokenów FIDO2 (z opcją wirtualnej emulacji software'owej) oraz opracowanie procedury awaryjnego odzyskiwania dostępu Break-Glass.

• Linux Ubuntu / Debian z pakietami libpam-pwquality, libpam-faillock, pamu2fcfg oraz libpam-u2f
• Środowisko Python 3 z biblioteką fido2 (darmowa biblioteka Yubico) do programowej emulacji tokena WebAuthn/FIDO2 bez konieczności posiadania fizycznego klucza sprzętowego
• Windows Server lub Windows 10/11 z modułem Active Directory PowerShell (New-ADFineGrainedPasswordPolicy) lub lokalnym secpol.msc
• Aegis Authenticator / KeePassXC – aplikacje do weryfikacji tokenów TOTP (RFC 6238) i zarządzania poświadczeniami

1. Analiza wektorów ataków: wyjaśnienie podatności tradycyjnego uwierzytelniania (kody SMS, TOTP) na przechwycenie w atakach typu Adversary-in-the-Middle (AiTM / Evilginx) oraz zasady odporności kryptograficznej protokołu FIDO2/WebAuthn opartego na powiązaniu z domeną (origin binding).
2. Konfiguracja minimalnej długości hasła na 16 znaków w pliku /etc/security/pwquality.conf w systemie Linux oraz weryfikacja entropii polskich haseł frazowych narzędziem pwscore.
3. Wdrożenie mechanizmu ochrony przed atakami brute-force w Linux za pomocą modułu libpam-faillock (parametry: deny=5, unlock_time=900) i przetestowanie procedury resetowania licznika: faillock --user <login> --reset.
4. Konfiguracja obsługi drugiego składnika FIDO2 w systemie Linux z użyciem modułu pam_u2f (z wykorzystaniem tokena fizycznego lub programowego emulatora asercji w Pythonie).
5. Zaprojektowanie obiektu Fine-Grained Password Policy (PSO) w konsoli PowerShell Active Directory (New-ADFineGrainedPasswordPolicy) z blokadą okresowego wygasania haseł i przypisaniem do grupy Domain Admins.
6. Opracowanie procedury konta awaryjnego Break-Glass (konto najwyższych uprawnień w sejfie w kopercie bezpiecznej, procedura dwóch par oczu) oraz protokołu unieważniania zgubionych tokenów sprzętowych.
7. Weryfikacja logów systemowych (Linux /var/log/auth.log oraz Windows Event ID 4625/4624) pod kątem wykrywania anomalii logowania i prób przełamania poświadczeń.

W trakcie realizacji zadania pamiętajcie, że nowoczesna polityka bezpieczeństwa całkowicie odchodzi od wymuszania cyklicznej rotacji haseł, co jednoznacznie podkreśla standard NIST SP 800-63B. Wymuszona rotacja skutkuje tworzeniem przewidywalnych mutacji (np. zmiana cyfry na końcu hasła).

Poniżej przedstawiono konfigurację modułu libpam-pwquality w pliku /etc/security/pwquality.conf oraz testowanie entropii narzędziem pwscore:

Weryfikacja stanu licznika błędnych logowań i odblokowanie konta za pomocą modułu pam_faillock:

W środowisku PowerShell na kontrolerze Windows Server tworzenie obiektu Fine-Grained Password Policy (PSO) dla kont uprzywilejowanych Domain Admins realizuje się poleceniami:

1. Analiza przewagi kryptograficznej standardu FIDO2/WebAuthn (klucze asymetryczne EC P-256 powiązane z domeną) nad podatnymi na ataki AiTM kodami jednorazowymi TOTP i SMS.
2. Rozgraniczenie architektury bibliotek jądra systemu operacyjnego (Linux Pluggable Authentication Modules) od procedur zarządzania tożsamością uprzywilejowaną (Privileged Access Management).
3. Rola obiektów Password Settings Objects (PSO) w Active Directory w różnicowaniu wymagań bezpieczeństwa dla kont zwykłych i administratorów poziomu Tier 0.
4. Znaczenie procedury Break-Glass w zapewnieniu ciągłości działania instytucji publicznej w sytuacjach kryzysowych przy zachowaniu ścisłej rozliczalności (zasada dwóch par oczu).
5. Spełnienie wymogów Krajowych Ram Interoperacyjności (KRI), ustawy o KSC oraz art. 32 RODO w ochronie tożsamości cyfrowej urzędników wojewódzkich.

Wymagania dotyczące sprawozdania: Zespół opracowuje zwięzłe sprawozdanie inżynierskie PDF (objętość 4–5 stron) zawierające matrycę ról i uprawnień, listingi plików konfiguracyjnych, zrzuty poleceń CLI oraz analizę wniosków.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia poufności i autentyczności informacji. Ochrona danych osobowych i medycznych.

Celem zadania jest opracowanie kompleksowej polityki czystego biurka (Clean Desk Policy) oraz czystego ekranu (Clean Screen Policy) dla szpitala klinicznego przetwarzającego szczególną kategorię danych osobowych (dane medyczne pacjentów). Studenci projektują zarówno rygorystyczne procedury organizacyjne, jak i techniczne mechanizmy egzekwowania zasad na stacjach roboczych w dyżurkach pielęgniarskich, gabinetach zabiegowych i na oddziałach ratunkowych. Projekt ma na celu wyeliminowanie ryzyka nieuprawnionego wglądu w dokumentację medyczną przez osoby odwiedzające i pacjentów.

W części technicznej zadanie wymaga skonfigurowania automatycznej blokady sesji, wygaszania ekranu, dynamicznej blokady urządzeń peryferyjnych (porty USB, pamięci masowe) oraz procedur kontrolnych z wykorzystaniem rejestru audytów fizycznych. Studenci zdobywają wiedzę z zakresu zgodności z art. 9 i 32 RODO oraz standardów akredytacyjnych Centrum Monitorowania Jakości w Ochronie Zdrowia (CMJ).

Szpital Kliniczny im. prof. Orłowskiego posiada 18 oddziałów szpitalnych, Szpitalny Oddział Ratunkowy (SOR) oraz poradnie specjalistyczne, w których łącznie pracuje ponad 900 stacji roboczych podłączonych do szpitalnego systemu HIS (Hospital Information System). Na korytarzach i w salach chorych codziennie przebywają setki pacjentów i osób odwiedzających. Rutynowa inspekcja przeprowadzona przez Inspektora Ochrony Danych (IOD) wykazała drastyczne uchybienia w zakresie bezpieczeństwa informacji.

W dyżurkach pielęgniarskich komputery pozostawały stale zalogowane na wspólnych kontach personelu, a monitory były ustawione wprost naprzeciwko drzwi wejściowych, umożliwiając każdemu odczytanie historii chorób i wyników badań. Na biurkach w gabinetach lekarskich leżały niezabezpieczone wydruki kart zleceń lekarskich, recepty z pieczątkami oraz karty zgonów. Dodatkowo stwierdzono stosowanie prywatnych pendrive'ów do przenoszenia plików ze skanera tomografii komputerowej.

Dyrekcja szpitala stanęła w obliczu groźby kary finansowej ze strony Urzędu Ochrony Danych Osobowych (UODO) po tym, jak jeden z pacjentów sfotografował smartfonem otwartą historię leczenia innej osoby i opublikował fragment w mediach społecznościowych. Nakazano natychmiastowe wdrożenie bezwzględnych standardów technicznych i organizacyjnych, które zagwarantują prywatność pacjentów.

Zespół studentów ma opracować szczegółową politykę czystego biurka i ekranu dostosowaną do specyfiki pracy medycznej (gdzie lekarz musi w kilka sekund uzyskać dostęp do komputera w sytuacji zagrożenia życia, ale nie może zostawić otwartej sesji po opuszczeniu stanowiska). Wymaga to wdrożenia kart zbliżeniowych RFID do szybkiego logowania/wylogowywania (tap-in/tap-out), filtrów prywatyzujących oraz zautomatyzowanej blokady stacji roboczej po 90 sekundach bezczynności.

Opracowanie musi zawierać procedury postępowania z dokumentacją papierową w szafach zamykanych na zamek bębenkowy, harmonogram audytów nocnych prowadzonych przez służbę ochrony oraz techniczne szablony GPO i skrypty audytujące blokady portów USB.

• Windows 10/11 Pro & Windows Server Group Policy Management (GPMC / secpol.msc)
• PowerShell 7.x do audytu rejestru systemowego i stanu usług wygaszacza ekranu
• Narzędzie USBDeview (NirSoft) – darmowy audytor historii podłączeń urządzeń USB
• Linux xautolock / slock / swayidle – darmowe narzędzia automatycznej blokady sesji w środowiskach uniksowych
• LibreOffice Writer / Calc – przygotowanie wzorców protokołów audytowych i checklist

1. Identyfikacja stref przetwarzania danych medycznych w szpitalu (strefa publiczna, ograniczona, zamknięta).
2. Analiza prawna wymogów art. 9 RODO (szczególne kategorie danych) oraz ustawy o prawach pacjenta i Rzeczniku Praw Pacjenta.
3. Zaprojektowanie ergonomicznego rozmieszczenia monitorów i mebli medycznych uniemożliwiającego podglądanie ekranów (Shoulder Surfing).
4. Opracowanie wymagań technicznych dla filtrów prywatyzujących (micro-louver technology) o kącie widzenia ograniczonym do 30 stopni.
5. Konfiguracja zasad grupy GPO w Windows: ScreenSaveActive=1, ScreenSaverIsSecure=1, ScreenSaveTimeOut=90 sekund.
6. Konfiguracja blokady urządzeń pamięci masowej USB w rejestrze Windows (StorageDevicePolicies\WriteProtect oraz UsbStor\Start=4).
7. Przygotowanie skryptu PowerShell sprawdzającego na stacjach roboczych zgodność parametrów blokady ekranu z polityką szpitalną.
8. Konfiguracja w systemie Linux menedżera blokady ekranu (np. xautolock -time 2 -locker 'slock') dla stacji diagnostycznych.
9. Zaprojektowanie procedury logowania opartej na kartach zbliżeniowych pracowniczych (wyjęcie karty ze czytnika natychmiast blokuje stację).
10. Opracowanie zasad bezpiecznego przechowywania i niszczenia dokumentacji papierowej (klasyfikacja niszczarek wg DIN 66399 min. poziom P-4).
11. Zdefiniowanie procedury czystego biurka na koniec dyżuru lekarskiego i pielęgniarskiego (chowanie pieczątek, recept, kart pacjentów do szaf).
12. Opracowanie szablonu protokołu niezapowiedzianego nocnego audytu czystych biurek przeprowadzanego przez inspektora ds. bezpieczeństwa.
13. Zdefiniowanie katalogu sankcji dyscyplinarnych za powtarzające się naruszenia zasad czystego ekranu przez personel medyczny.
14. Przygotowanie materiałów szkoleniowych w formie infografiki i procedury jednostronicowej (One-Point Lesson) na tablice informacyjne.
15. Przetestowanie poleceń audytu podłączeń urządzeń USB na stacjach diagnostycznych za pomocą PowerShell.
16. Zaprojektowanie procedury awaryjnego odblokowania stacji w trakcie resuscytacji krążeniowo-oddechowej (konto emergency-view).
17. Wdrożenie harmonogramu kwartalnych przeglądów stanu zabezpieczeń fizycznych gabinetów i dyżurek.

Zasada czystego biurka nie może być traktowana wyłącznie jako martwy przepis regulaminowy. W placówce medycznej kluczowe jest zapewnienie personelowi odpowiednich narzędzi ułatwiających przestrzeganie procedury: szaf zamykanych na klucz systemowy (Master Key), pojemników na dokumenty do zniszczenia oraz automatyzacji wylogowania po odejściu od komputera.

Poniżej przedstawiono konfigurację wymuszenia blokady stacji roboczej po 90 sekundach w systemie Windows za pomocą poleceń rejestru w wierszu poleceń lub PowerShell:

Całkowite zablokowanie nośników pamięci masowej USB (pendrive) za pośrednictwem rejestru systemowego:

Audyt historii podłączanych pamięci USB za pomocą wbudowanego polecenia PowerShell badającego zdarzenia systemowe Plug and Play:

1. Złożoność ochrony fizycznej stacji roboczych i terminali medycznych w środowisku otwartym szpitala klinicznego z ciągłym ruchem pacjentów i personelu.
2. Implementacja automatycznego blokowania sesji za pomocą zbliżeniowych kart identyfikacyjnych RFID/NFC zintegrowanych z systemem Single Sign-On (SSO) typu Imprivata.
3. Konfiguracja obiektów GPO wymuszających wygaszacze ekranu z hasłem, blokadę portów USB oraz wyłączenie buforowania poświadczeń na stacjach w salach zabiegowych.
4. Metodyka przeprowadzania audytów fizycznych (red teaming) i nocnych inspekcji czystego biurka pod kątem pozostawionych kartotek medycznych i receptariuszy.
5. Aspekty ergonomiczne pracy personelu medycznego i unikanie obchodzenia zabezpieczeń (np. myszek wstrząsowych typu Mouse Jiggler).
6. Odpowiedzialność prawna i finansowa podmiotu leczniczego za naruszenie poufności szczególnych kategorii danych medycznych (art. 9 RODO i ustawa o prawach pacjenta).

Przykładowe wnioski (wzór do sprawozdania): Przeprowadzony audyt fizyczny i techniczny w szpitalu klinicznym potwierdził, że rygorystyczne przestrzeganie zasad czystego biurka i ekranu jest fundamentem zachowania tajemnicy lekarskiej w erze cyfrowej. Zastąpienie uciążliwego wpisywania haseł przez lekarzy technologią kart zbliżeniowych RFID powiązanych z mechanizmem automatycznego blokowania stacji (Tap-In / Tap-Out) wyeliminowało powszechne zjawisko pozostawiania otwartych sesji w gabinetach. Zastosowanie filtrów prywatyzujących oraz centralnie dystrybuowanych polis GPO skutecznie zablokowało możliwość podejrzenia wyników badań przez osoby oczekujące na korytarzach. Audyty nocne wykazały konieczność wprowadzenia zamykanych na zamek elektromagnetyczny szaf na dokumentację papierową, co zabezpiecza historię chorób przed personelem pomocniczym i serwisowym. Wdrożone procedury godzą dynamikę ratowania życia z bezwzględnymi wymogami ochrony danych osobowych pacjentów określonymi w art. 9 RODO.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia integralności i dostępności informacji. Ciągłość działania systemów IT.

Celem zadania jest zaprojektowanie zaawansowanej, odpornej na ataki ransomware polityki tworzenia, przechowywania i weryfikacji kopii zapasowych dla polskiej platformy płatniczej (Fintech). Studenci implementują ugruntowaną regułę 3-2-1-1-0 (3 kopie, 2 różne nośniki, 1 kopia offsite, 1 kopia offline/niezmienna WORM, 0 błędów w testach odzyskiwania). Projekt obejmuje kryptograficzne zabezpieczenie archiwów algorytmem AES-256-GCM, wyznaczenie parametrów RPO (Recovery Point Objective) oraz RTO (Recovery Time Objective) dla krytycznych baz danych transakcyjnych.

W części praktycznej studenci konfigurują zautomatyzowane skrypty tworzenia kopii baz danych, ich szyfrowanie z użyciem OpenSSL, przesyłanie przez bezpieczny kanał WireGuard/SSH do odizolowanego repozytorium oraz weryfikację sum kontrolnych SHA-256. Projekt uczy projektowania procedur Disaster Recovery (DR) spełniających restrykcyjne wytyczne Komisji Nadzoru Finansowego (KNF) oraz normy ISO/IEC 27001.

Warszawska spółka technologiczna FinPay Sp. z o.o. obsługuje bramkę płatności internetowych dla ponad 3000 sklepów e-commerce w Polsce. Wolumen transakcji przekracza 50 000 operacji na dobę, a każda minuta niedostępności systemu relacyjnej bazy danych PostgreSQL generuje bezpośrednie straty finansowe i kary umowne. W ostatnim roku sektor fintech stał się głównym celem zorganizowanych grup cyberprzestępczych stosujących wieloetapowe oprogramowanie ransomware (Double Extortion), które w pierwszej kolejności infiltruje sieć, wyszukuje serwery backupu i bezpowrotnie niszczy punkty przywracania danych.

Audyt bezpieczeństwa wykazał, że dotychczasowe kopie zapasowe FinPay były wykonywane prostym skryptem cron na wspólny zasób sieciowy NFS, do którego pełne uprawnienia zapisu posiadały te same poświadczenia administratorskie, co do serwerów produkcyjnych. W przypadku kompromitacji głównego kontrolera domeny lub serwera bazodanowego, napastnik mógł jednym poleceniem usunąć zarówno dane produkcyjne, jak i wszystkie historyczne kopie zapasowe.

W związku z wejściem w życie unijnego rozporządzenia DORA (Digital Operational Resilience Act) oraz rekomendacji D KNF, zarząd spółki zażądał przebudowy architektury backupu. Nowy system musi uniemożliwić skasowanie lub zmodyfikowanie kopii zapasowych przez określony czas (retention lock / WORM - Write Once, Read Many), nawet w przypadku przejęcia uprawnień administratora root na serwerze produkcyjnym.

Zadaniem grupy jest opracowanie kompletnej polityki kopii zapasowych, schematu logicznego przepływu danych oraz zestawu darmowych narzędzi i skryptów realizujących: automatyczny zrzut bazy danych, szyfrowanie symetryczne AES-256 z kluczem zarządzanym poza serwerem produkcyjnym, asynchroniczną replikację do zewnętrznego data center oraz cykliczne, testowe odtwarzanie danych w wyizolowanym środowisku Sandbox.

Polityka musi precyzyjnie definiować harmonogram kopii pełnych, różnicowych i transakcyjnych (Write-Ahead Logging - WAL), dopuszczalny czas odzyskania bazy po awarii (RTO <= 30 minut) oraz dopuszczalny ubytek danych (RPO <= 5 minut).

• Linux Ubuntu Server z bazą danych PostgreSQL / MariaDB
• Narzędzie do zrzutów pg_dump / pg_basebackup oraz rsync / borgbackup / restic
• OpenSSL 3.x do strumieniowego szyfrowania archiwów algorytmem AES-256-CBC / AES-256-GCM
• MinIO Server / Rclone z obsługą mechanizmu Object Lock (WORM / S3 compliance)
• Narzędzie sha256sum / md5sum do weryfikacji integralności kryptograficznej plików

1. Zdefiniowanie krytycznych zasobów danych FinPay: relacyjna baza transakcyjna, klucze API partnerów, logi audytowe.
2. Wyznaczenie metryk ciągłości działania RTO (maksymalny akceptowalny czas niedostępności) oraz RPO (maksymalny ubytek danych) wg normy ISO 22301.
3. Zaprojektowanie architektury 3-2-1-1-0: serwer produkcyjny -> lokalny storage backupu -> niezmienny składnik WORM offsite.
4. Opracowanie procedury bezpiecznego wykonywania gorącego zrzutu bazy PostgreSQL (pg_dump z kompresją i spójnością transakcyjną).
5. Zaimplementowanie potoku szyfrującego dane w locie za pomocą OpenSSL z wykorzystaniem symetrycznego klucza AES-256.
6. Konfiguracja izolowanego użytkownika systemowego backup-operator z ograniczonymi uprawnieniami (sudoers restrict).
7. Konfiguracja repozytorium kopii zapasowych w technologii niezmiennego składowania (WORM / Object Lock z flagą immutability na 30 dni).
8. Zaimplementowanie przesyłania zaszyfrowanych pakietów przez bezpieczny kanał WireGuard do zapasowego centrum danych w Krakowie.
9. Automatyczne generowanie i zapisywanie sum kontrolnych SHA-256 dla każdego wygenerowanego archiwum kopii.
10. Przygotowanie skryptu automatycznego testowego odzyskiwania bazy danych na serwerze testowym (staged recovery).
11. Wdrożenie procedury rotacji i bezpiecznego zarządzania kluczami szyfrującymi backupy (oddzielenie klucza od nośnika).
12. Konfiguracja powiadomień telemetrycznych o statusie kopii zapasowej (sukces, ostrzeżenie, błąd, czas trwania operacji).
13. Opracowanie procedury postępowania w sytuacji katastrofy (Disaster Recovery Plan) krok po kroku dla administratora dyżurnego.
14. Zaprojektowanie scenariusza cyklicznego testu odzyskiwania 'Dry-Run' przeprowadzanego raz na kwartał z udziałem audytora.
15. Zbadanie odporności architektury backupu na przypadek całkowitego zaszyfrowania serwera produkcyjnego przez ransomware.
16. Weryfikacja zgodności procedury z wymaganiami rozporządzenia DORA oraz rekomendacjami KNF dla instytucji płatniczych.
17. Opracowanie wzorca metryki odzyskiwania danych dokumentującej czas i poprawność odtworzenia transakcji.

Prawdziwa ochrona przed nowoczesnym oprogramowaniem ransomware wymaga bezwzględnego odizolowania serwera kopii zapasowych. Serwer backupu powinien pracować w modelu PULL (samodzielnie łączy się do środowiska produkcyjnego i pobiera dane) zamiast modelu PUSH (gdzie serwer produkcyjny ma uprawnienia zapisu na storage backupu).

Poniżej przedstawiono przykładowy potok tworzenia zrzutu bazy danych PostgreSQL, jego natychmiastowego szyfrowania symetrycznego AES-256-CBC i generowania sumy kontrolnej SHA-256 w systemie Linux:

Weryfikacja integralności i testowe odszyfrowanie archiwum w środowisku odizolowanym (sandbox):

Ustawienie atrybutu niezmienności pliku (append-only / immutable) na poziomie systemu plików Linux w celu ochrony przed skasowaniem:

1. Koncepcja architektury kopii zapasowych 3-2-1 rozszerzona o niezmienne repozytoria danych (Immutable Storage / WORM) odporne na manipulacje administratora.
2. Mechanizmy izolacji sieciowej (Air-Gapping) pomiędzy środowiskiem produkcyjnym fintechu a infrastrukturą zapasową.
3. Szyfrowanie archiwów w spoczynku (AES-256) z wykorzystaniem asymetrycznego podziału kluczy oraz sprzętowych modułów bezpieczeństwa (HSM).
4. Zdefiniowanie i matematyczna weryfikacja wskaźników RPO (Recovery Point Objective) i RTO (Recovery Time Objective) dla baz transakcyjnych SQL/NoSQL.
5. Procedury zautomatyzowanego testowania spójności kopii zapasowych w piaskownicy (Sandbox Disaster Recovery) bez wpływu na produkcję.
6. Wymogi regulacyjne Komisji Nadzoru Finansowego (Komunikat Chmurowy KNF, Rekomendacja D) oraz normy ISO/IEC 27031 w zakresie ciągłości działania.

Przykładowe wnioski (wzór do sprawozdania): Opracowanie zaawansowanej architektury kopii zapasowych dla platformy fintech wykazało, że tradycyjny backup bez gwarancji niezmienności (WORM) jest bezbronny wobec nowoczesnych szczepów ransomware ukierunkowanych na niszczenie repozytoriów danych. Zastosowanie technologii 'Object Lock' w chmurze prywatnej z wymuszeniem trybu 'Compliance' uniemożliwiło skasowanie lub zmodyfikowanie punktów przywracania nawet w przypadku kompromitacji konta głównego administratora. Rygorystyczne parametry RPO równe 15 minut oraz RTO poniżej 2 godzin osiągnięto dzięki ciągłej replikacji transakcyjnej z wykorzystaniem mechanizmów 'Changed Block Tracking'. Szyfrowanie wolumenów zapasowych kluczami zarządzanymi w module HSM gwarantuje pełną poufność danych finansowych i wyklucza ich ujawnienie w przypadku fizycznej kradzieży nośników. Wdrożenie zautomatyzowanych testów odtwarzania w izolowanej piaskownicy pozwala na cykliczne poświadczanie gotowości operacyjnej zgodnie z Rekomendacją D KNF.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Modele kontroli dostępu DAC, MAC, RBAC, ABAC.

Celem zadania jest skonstruowanie i wdrożenie zaawansowanej polityki kontroli dostępu w dużej firmie spedycyjno-logistycznej, łączącej model oparty na rolach (Role-Based Access Control - RBAC) z modelem atrybutowym (Attribute-Based Access Control - ABAC). Studenci identyfikują zagrożenia związane z nadmiernymi uprawnieniami (Privilege Creep) oraz brakiem izolacji pomiędzy oddziałami operacyjnymi. Projekt skupia się na praktycznej realizacji zasady najniższych uprawnień (Principle of Least Privilege - PoLP) oraz separacji obowiązków (Separation of Duties - SoD).

W warstwie technicznej zadanie wymaga opracowania formalnej matrycy uprawnień CRUD dla zasobów plikowych i bazodanowych, konfiguracji list kontroli dostępu (POSIX ACL w Linux oraz NTFS ACL w Windows) oraz zaimplementowania mechanizmu dostępu tymczasowego Just-In-Time (JIT) z automatycznym wygasaniem uprawnień. Studenci uczą się audytowania uprawnień za pomocą poleceń systemowych i wykrywania kont osieroconych.

TransLogistics Polska S.A. jest operatorem logistycznym zatrudniającym 1200 pracowników w 8 centrach dystrybucyjnych (Warszawa, Poznań, Katowice, Gdańsk, Wrocław, Łódź, Kraków, Szczecin). W spółce funkcjonują działy: Spedycja Międzynarodowa, Odprawa Celna, Finanse i Księgowość, Kadry i Płace oraz Zarządzanie Flotą. W trakcie audytu wewnętrznego ujawniono rażące nieprawidłowości: większość koordynatorów spedycji posiadała pełne uprawnienia do folderów zawierających dane finansowe klientów, marże oraz umowy handlowe wszystkich pozostałych oddziałów.

Co gorsza, pracownicy zmieniający działy w ramach awansów wewnętrznych kumulowali uprawnienia z poprzednich stanowisk (zjawisko Privilege Creep). Byli spedytorzy przeniesieni do działu floty wciąż mieli dostęp do systemów celnych i danych płacowych. System uprawnień w domenie Windows oparty był na chaotycznym przydzielaniu dostępów bezpośrednio do kont użytkowników zamiast do grup globalnych i domenowych.

Incydent ujawnienia oferty przetargowej konkurencyjnej firmie logistycznej przez byłego pracownika, który zachował aktywny dostęp do folderu ofertowego po przeniesieniu do innego oddziału, wywołał kryzys zarządczy. Zarząd zlecił audytorom natychmiastowe zlikwidowanie obecnego chaosu i wprowadzenie rygorystycznej kontroli dostępu.

Grupa laboratoryjna musi zaprojektować formalną Matrycę Kontroli Dostępu, uwzględniającą podział na role biznesowe i techniczne oraz atrybuty kontekstowe (np. dostęp do danych oddziału dozwolony wyłącznie z podsieci danego centrum logistycznego w godzinach 06:00-22:00). Należy wyeliminować bezpośrednie uprawnienia użytkowników na rzecz modelu AGDLP (Accounts -> Global Groups -> Domain Local Groups -> Permissions).

Sprawozdanie musi zawierać procedurę cyklicznej re-certyfikacji uprawnień (Access Review), procedurę natychmiastowego odbierania uprawnień przy zwolnieniu (Offboarding) oraz skrypty weryfikujące nadmiarowe uprawnienia w systemach Linux i Windows.

• Linux z obsługą zaawansowanych list ACL (pakiety acl, getfacl, setfacl)
• Windows Server / Windows 11 z narzędziami icacls oraz modułem ActiveDirectory PowerShell
• Narzędzie AccessChk / AccessEnum (z pakietu Microsoft Sysinternals)
• Sudoers configuration (/etc/sudoers i visudo z ograniczeniem do konkretnych komend i argumentów)
• Arkusz kalkulacyjny do modelowania matrycy RBAC/ABAC z regułami SoD

1. Zidentyfikowanie grup użytkowników, ról biznesowych i zasobów informacyjnych w TransLogistics Polska.
2. Opracowanie formalnej matrycy uprawnień RBAC w notacji CRUD (Create, Read, Update, Delete) dla wszystkich działów.
3. Zdefiniowanie reguł separacji obowiązków (SoD), np. spedytor tworzący zlecenie nie może samodzielnie zatwierdzać płatności celnej.
4. Zaprojektowanie struktury grup według metodyki AGDLP w środowisku domeny Windows Server Active Directory.
5. Wdrożenie atrybutowej kontroli dostępu (ABAC) uzależniającej dostęp od lokalizacji sieciowej stacji (Oddział) i godzin pracy.
6. Zaimplementowanie restrykcyjnych uprawnień w systemie Linux przy użyciu poleceń setfacl i getfacl na strukturze katalogów /dane/spedycja.
7. Skonfigurowanie dziedziczenia uprawnień (default ACL) w systemie Linux w celu wymuszenia automatycznych praw dla nowych plików.
8. Zastosowanie narzędzia icacls w Windows do precyzyjnego ustawienia uprawnień NTFS bez propagacji niepożądanych praw.
9. Skonfigurowanie uprawnień delegowanych w pliku /etc/sudoers za pomocą visudo (brak uprawnień root bez ograniczeń).
10. Zaprojektowanie procesu dostępu Just-In-Time (JIT) – czasowe dodanie do grupy uprzywilejowanej z automatycznym wygaśnięciem po 2 godzinach.
11. Opracowanie procedury Onboarding (nadawanie uprawnień według szablonu roli) i Offboarding (natychmiastowe zablokowanie w 15 minut).
12. Wdrożenie kwartalnej procedury przeglądu uprawnień (Access Recertification) wymagającej podpisu kierownika działu.
13. Przeprowadzenie audytu nadmiarowych uprawnień za pomocą narzędzia AccessChk z pakietu Sysinternals.
14. Wykrywanie kont nieaktywnych (brak logowania od ponad 60 dni) za pomocą skryptu PowerShell Search-ADAccount.
15. Zaprojektowanie logowania zdarzeń dostępu (Windows Event ID 4663 - próba dostępu do obiektu, Linux auditd).
16. Opracowanie zaleceń dotyczących likwidacji kont współdzielonych na stacjach magazynowych.
17. Przygotowanie sprawozdania z matrycą uprawnień i instrukcją techniczną konfiguracji ACL.

Podczas projektowania kontroli dostępu pamiętajcie o fundamentalnej zasadzie domyślnej odmowy (Default Deny) – każdy użytkownik i proces posiada zerowe uprawnienia, dopóki nie zostaną mu one jawnie i celowo nadane na podstawie pełnionej roli.

Poniżej przedstawiono konfigurację uprawnień POSIX ACL w systemie Linux z użyciem poleceń setfacl, definiujących uprawnienia dla grupy spedytorów oraz domyślne uprawnienia dziedziczone:

Weryfikacja i konfiguracja uprawnień NTFS w systemie Windows za pomocą narzędzia wiersza poleceń icacls:

Wykrywanie kont nieaktywnych od ponad 90 dni w Active Directory za pomocą PowerShell:

1. Hybrydowe połączenie modeli kontroli dostępu opartej na rolach (RBAC) oraz atrybutach (ABAC: geolokalizacja, pora dnia, stan urządzenia).
2. Implementacja zasady najmniejszych uprawnień (Principle of Least Privilege) w celu eliminacji nadmiernych uprawnień w systemach ERP/WMS.
3. Koncepcja dostępu Just-in-Time (JIT) i poświadczeń jednorazowych ważnych wyłącznie przez czas trwania zlecenia serwisowego.
4. Automatyzacja procesów nadawania, certyfikacji oraz natychmiastowego odbierania uprawnień (Joiners-Movers-Leavers / Offboarding) powiązana z systemem HR.
5. Zastosowanie dynamicznych list ACL i ról w bazach danych w celu izolacji danych kontrahentów i dokumentów celnych.
6. Zapewnienie rozliczalności i audytowalności dostępu do informacji zgodnie z wytycznymi normy PN-EN ISO/IEC 27001 oraz przepisami celnymi AEO.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie hybrydowego modelu kontroli dostępu RBAC/ABAC w międzynarodowej korporacji logistycznej skutecznie rozwiązało problem niekontrolowanego rozrostu uprawnień pracowniczych (Privilege Creep). Zastosowanie reguł ABAC uwzględniających geolokalizację stacji roboczej oraz godziny pracy uniemożliwiło realizację operacji magazynowych i celnych poza wyznaczonymi strefami operacyjnymi. Wprowadzenie poświadczeń Just-in-Time (JIT) z automatycznym wygasaniem dostępu po 60 minutach zredukowało okno czasowe potencjalnego nadużycia przez zewnętrznych audytorów i serwisantów oprogramowania ERP. Integracja mechanizmu zarządzania tożsamością z bazą kadr zapewniła natychmiastowe odbieranie wszystkich dostępów domenowych i aplikacyjnych w momencie rozwiązania umowy z pracownikiem. Uzyskany poziom granulacji uprawnień i rozliczalności operacji pozwolił firmie na bezproblemowe odnowienie prestiżowego certyfikatu Upoważnionego Przedsiębiorcy AEO.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia poufności i autentyczności informacji. Ochrona danych w spoczynku (Data at Rest).

Celem zadania jest zaprojektowanie, przetestowanie i wdrożenie polityki pełnego szyfrowania dysków twardych (Full Disk Encryption - FDE) oraz wymiennych nośników USB dla komputerów przenośnych eksploatowanych poza siedzibą firmy. Studenci badają mechanizmy ochrony danych w spoczynku (Data at Rest) w systemach Windows (BitLocker) oraz Linux (dm-crypt / LUKS2), ze szczególnym uwzględnieniem sprzętowej integracji z modułem TPM 2.0 (Trusted Platform Module) oraz bezpiecznego rozruchu Secure Boot. Projekt analizuje podatności na ataki typu Evil Maid, Cold Boot oraz ekstrakcję kluczy z magistrali SPI/LPC.

W ramach laboratorium studenci tworzą bezpieczny protokół postępowania na wypadek utraty (kradzieży lub zagubienia) laptopa służbowego, uwzględniający kryteria oceny ryzyka naruszenia praw osób fizycznych zgodnie z art. 33 i 34 RODO. Przeprowadzają konfigurację depozytu kluczy odzyskiwania (Key Escrow), wymuszanie szyfrowania nośników zewnętrznych oraz weryfikację stanu kryptograficznego wolumenów.

Firma doradcza AuditTax Consulting zatrudnia 150 audytorów finansowych i biegłych rewidentów, którzy większość czasu pracy spędzają u klientów zewnętrznych, w pociągach, hotelach oraz na lotniskach. Na dyskach twardych laptopów przenoszone są kopie baz księgowych, pliki JPK_V7, zestawienia kadrowo-płacowe oraz poufne strategie podatkowe największych spółek giełdowych w Polsce. W ciągu ostatnich 6 miesięcy odnotowano dwa przypadki kradzieży laptopów służbowych z bagażników samochodów oraz jedno zagubienie torby z komputerem w pociągu relacji Kraków-Warszawa.

W jednym ze skradzionych komputerów BitLocker był wyłączony przez pracownika, który skarżył się na spowolnienie działania systemu po włączeniu szyfrowania. Brak pewności co do stanu zaszyfrowania dysku zmusił zarząd AuditTax do zgłoszenia naruszenia ochrony danych osobowych do Prezesa Urzędu Ochrony Danych Osobowych (PUODO) oraz indywidualnego powiadomienia ponad 14 000 pracowników klientów, co spowodowało gigantyczne straty wizerunkowe i finansowe.

Prezes zarządu podjął decyzję o bezwzględnym wdrożeniu zasady, zgodnie z którą żaden komputer przenośny ani nośnik USB nie może zostać dopuszczony do przetwarzania danych bez aktywnego, centralnie monitorowanego szyfrowania opartego na algorytmie AES z kluczem 256-bitowym. Wszelkie próby wyłączenia ochrony przez użytkowników lokalnych muszą być blokowane na poziomie uprawnień i wykrywane przez system monitoringu.

Zadaniem zespołu laboratoryjnego jest skonstruowanie kompleksowej Polityki Ochrony Danych w Spoczynku. Dokument musi obejmować: standardy techniczne szyfrowania BitLocker (tryb XTS-AES 256 z autoryzacją TPM + PIN) i LUKS2 (aes-xts-plain64 z argon2id), procedurę bezpiecznego przechowywania 48-cyfrowych kluczy odzyskiwania w bezpiecznym depozycie, blokadę zapisu na niezaszyfrowanych pendrive'ach oraz procedurę zgłaszania utraty urządzenia w czasie do 2 godzin od zdarzenia.

Projekt musi zawierać analizę prawną wykazującą, w jakich okolicznościach kradzież prawidłowo zaszyfrowanego laptopa nie stanowi wysokiego ryzyka naruszenia praw osób trzecich i zwalnia administratora z obowiązku zawiadamiania osób, których dane dotyczą (art. 34 ust. 3 lit. a RODO).

• System Windows z narzędziem manage-bde oraz modułem BitLocker PowerShell
• Linux z pakietami cryptsetup, tpm2-tools oraz systemd-cryptenroll
• Narzędzie VeraCrypt do bezpiecznego tworzenia zaszyfrowanych kontenerów wolumenowych
• Narzędzie tpm2_pcrread do analizy rejestrów PCR (Platform Configuration Registers)
• Środowisko wirtualne VirtualBox / VMware z emulacją modułu TPM 2.0

1. Identyfikacja wektorów zagrożeń dla danych na urządzeniach mobilnych (kradzież fizyczna, ataki DMA, ataki offline).
2. Analiza artykułu 32 i 34 RODO pod kątem wdrożenia szyfrowania jako środka technicznego minimalizującego ryzyko wycieku.
3. Weryfikacja obecności i stanu modułu TPM 2.0 na stacji roboczej za pomocą tpm.msc lub tpm2-tools.
4. Wybór zaawansowanego algorytmu szyfrowania: zmiana domyślnego AES-128 na XTS-AES-256 w rejestrze Windows GPO.
5. Konfiguracja wymuszenia ochrony BitLocker z dwoma składnikami rozruchu: moduł TPM oraz dodatkowy kod PIN (min. 8 cyfr).
6. Wdrożenie procedury depozytowania kluczy odzyskiwania BitLocker w usłudze Active Directory / Entra ID.
7. Konfiguracja BitLocker To Go z wymuszeniem szyfrowania nośników wymiennych USB (odmowa zapisu na nośnikach niezaszyfrowanych).
8. Partycjonowanie i szyfrowanie dysku w systemie Linux za pomocą cryptsetup luksFormat z algorytmem aes-xts-plain64 i KDF argon2id.
9. Zintegrowanie odblokowywania wolumenu LUKS2 z modułem TPM 2.0 przy użyciu polecenia systemd-cryptenroll.
10. Symulacja procedury awaryjnego odzyskiwania dostępu do dysku za pomocą 48-cyfrowego klucza odzyskiwania (Recovery Key).
11. Opracowanie procedury audytu floty laptopów weryfikującej status szyfrowania za pomocą skryptu PowerShell.
12. Zdefiniowanie formalnego protokołu zgłoszenia utraty lub kradzieży laptopa przez pracownika w podróży służbowej.
13. Opracowanie formularza oceny incydentu przez Inspektora Ochrony Danych (dowód nieczytelności danych w rozumieniu RODO).
14. Przetestowanie poleceń sprawdzających rejestry PCR (Platform Configuration Registers) pod kątem integralności oprogramowania układowego UEFI.
15. Zaprojektowanie procedury zdalnego czyszczenia (Remote Wipe) lub unieważnienia certyfikatów i tokenów powiązanych ze skradzionym urządzeniem.
16. Zdefiniowanie zasad bezpiecznego wycofywania i niszczenia dysków twardych z kluczami TPM (Sanitization).
17. Opracowanie sprawozdania laboratoryjnego wraz z konfiguracją techniczną i wytycznymi wdrożeniowymi.

Stosowanie samego modułu TPM bez dodatkowego kodu PIN (TPM-only) chroni przed prostym wyjęciem dysku i podłączeniem go do innego komputera, lecz nie chroni przed atakiem, w którym napastnik kradnie włączony komputer w stanie uśpienia lub dokonuje podsłuchu magistrali TPM-CPU (LPC/SPI sniffing). Dlatego dla kadry zarządzającej i audytorów obligatoryjne jest wymuszenie trybu TPM + PIN.

Poniżej przedstawiono konfigurację szyfrowania wolumenu systemowego Windows za pomocą narzędzia manage-bde z wymuszeniem TPM + PIN oraz XTS-AES-256:

Konfiguracja wolumenu LUKS2 w systemie Linux z wykorzystaniem algorytmu Argon2id i powiązaniem z TPM 2.0:

Weryfikacja statusu blokady zapisu na niezaszyfrowanych nośnikach wymiennych (BitLocker To Go) w rejestrze PowerShell:

1. Dobór algorytmu szyfrującego AES-XTS z kluczem 256-bitowym dla urządzeń końcowych pod kątem odporności na kryptoanalizę i manipulacje blokowe.
2. Rola układu kryptograficznego TPM 2.0 oraz mechanizmu Secure Boot w zapewnieniu nienaruszalności łańcucha zaufania procesu startowego (Measured Boot).
3. Architektura centralnego escrow kluczy odzyskiwania w Active Directory, Azure AD lub w bezpiecznym repozytorium sieciowym Clevis/Tang w Linux.
4. Procedura natychmiastowego zgłaszania incydentu utraty urządzenia, zdalnego unieważnienia certyfikatów i blokady tokenów sesyjnych.
5. Tworzenie zaszyfrowanych kontenerów VeraCrypt z podwójnym uwierzytelnieniem (hasło frazowe + plik klucza) na nośnikach wymiennych USB.
6. Formalne wykazanie przed organem nadzorczym (UODO) braku wysokiego ryzyka naruszenia praw osób fizycznych zgodnie z motywem 83 i art. 34 RODO.

Przykładowe wnioski (wzór do sprawozdania): Implementacja pełnego szyfrowania wolumenów dyskowych BitLocker i LUKS2 z wykorzystaniem kryptoprocesora TPM 2.0 zapewniła całkowite uodpornienie floty komputerów przenośnych na ataki typu 'Cold Boot' oraz bezpośrednią ekstrakcję pamięci NAND. Zastosowanie algorytmu AES-XTS-256 w połączeniu ze sprawdzaniem integralności rozruchu (Secure Boot) gwarantuje, że próba uruchomienia obcego jądra systemu natychmiast blokuje dostęp do klucza deszyfrującego. Centralny depozyt kluczy odzyskiwania w bezpiecznym katalogu domenowym zabezpieczył ciągłość biznesową organizacji w sytuacjach awarii sprzętowych lub błędnego wprowadzenia kodu PIN przez użytkownika. Opracowana i przećwiczona procedura reagowania na kradzież laptopa pozwala na formalne potwierdzenie zaszyfrowania dysku w protokole incydentu w ciągu pierwszych 2 godzin od zgłoszenia. Z perspektywy prawnej posiadanie udokumentowanego, certyfikowanego szyfrowania w spoczynku zwalnia administratora z obowiązku zawiadamiania tysięcy klientów o incydencie na gruncie art. 34 ust. 3 lit. a RODO.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Bezpieczeństwo protokołów komunikacyjnych i sieci komputerowych. Wirtualne sieci prywatne VPN.

Celem zadania jest zaprojektowanie i wdrożenie nowoczesnej architektury bezpiecznego dostępu zdalnego dla inżynierów i architektów biura projektowego realizującego zamówienia infrastruktury krytycznej. Studenci analizują zagrożenia związane z niezabezpieczonymi sieciami domowymi i publicznymi punktami dostępowymi Wi-Fi, atakami Man-in-the-Middle oraz kompromitacją urządzeń końcowych. Projekt zakłada wdrożenie nowoczesnego protokołu VPN WireGuard opartego na nowoczesnej kryptografii (ChaCha20, Poly1305, Curve25519) w zastępstwie przestarzałych protokołów PPTP/L2TP.

W warstwie sieciowej zadanie obejmuje konfigurację bezpiecznego tunelu VPN z wymuszeniem pełnego tunelowania (Full Tunneling, brak Split Tunneling), eliminację wycieków DNS (DNS Leak Prevention), implementację mikrosegmentacji sieci wewnętrznej w oparciu o zapory ogniowe oraz mechanizmy weryfikacji stanu bezpieczeństwa stacji roboczej (Endpoint Posture Check). Studenci zdobywają praktyczne umiejętności konfiguracji w systemach Linux oraz RouterOS.

Biuro Projektów Inżynieryjnych GeoProjekt Sp. z o.o. zatrudnia 80 inżynierów projektujących mosty, tunele kolejowe oraz węzły gazowe. Ze względu na specyfikę pracy projektanci pracują w modelu hybrydowym z domów oraz z kontenerów biurowych na placach budów. Dotychczas pracownicy łączyli się do sieci firmowej przy użyciu starego protokołu PPTP skonfigurowanego na domowym routerze lub otwartego serwera OpenVPN bez wymuszenia uwierzytelniania dwuskładnikowego i bez izolacji ruchu.

Podczas pracy zdalnej z hotelu jeden z głównych inżynierów padł ofiarą ataku Evil Twin Hotspot – fałszywego punktu dostępowego podszywającego się pod sieć hotelową. W wyniku ataku doszło do zatrucia pamięci podręcznej DNS i przejęcia nieszyfrowanych sesji projektowych oraz infekcji komputera złośliwym oprogramowaniem typu infostealer. Zainfekowany laptop, po ponownym podłączeniu przez VPN, posłużył napastnikom jako brama do przeskanowania i spenetrowania całej sieci wewnętrznej biura projektowego.

Incydent ten uświadomił zarządowi, że koncepcja tradycyjnego VPN dającego pełny dostęp do całej podsieci LAN jest fundamentalnym błędem architektonicznym. Zarząd podjął decyzję o natychmiastowym wdrożeniu paradygmatu Zero Trust Network Access (ZTNA) opartego na zasadzie: 'nigdy nie ufaj, zawsze weryfikuj'.

Zespół studentów ma za zadanie opracować formalną Politykę Bezpiecznej Pracy Zdalnej oraz zaprojektować infrastrukturę dostępową w oparciu o protokół WireGuard na bramie brzegowej (RouterOS / Linux). Nowa architektura musi bezwzględnie wymuszać routing całego ruchu przez tunel (AllowedIPs = 0.0.0.0/0), kierować zapytania DNS wyłącznie do wewnętrznego, filtrującego serwera DNS (eliminacja wycieków DNS), a także separować inżynierów do dedykowanych mikrostref VLAN.

Projekt musi zawierać procedurę weryfikacji stacji roboczej przed zestawieniem tunelu (sprawdzenie obecności aktywnego programu antywirusowego, zainstalowanych poprawek systemowych i włączonego szyfrowania BitLocker) oraz instrukcję konfiguracji klientów dla inżynierów.

• MikroTik RouterOS v7.x z obsługą interfejsów WireGuard oraz reguł Firewall Filter
• Linux Ubuntu / Debian z pakietem wireguard, wireguard-tools oraz iptables / nftables
• WireGuard Client dla systemów Windows i Linux
• Narzędzie tcpdump / Wireshark do analizy pakietów i weryfikacji braku wycieków DNS
• Skrypt PowerShell / Bash do przeprowadzania kontroli stanu stacji (Endpoint Posture Check)

1. Zidentyfikowanie wektorów ataków na pracowników zdalnych (Evil Twin, zatruwanie DNS, ataki z sieci domowej LAN).
2. Zestawienie właściwości kryptograficznych WireGuard (Noise Protocol Framework, Curve25519, ChaCha20-Poly1305, BLAKE2s) z IPsec i OpenVPN.
3. Wygenerowanie asymetrycznych par kluczy kryptograficznych (Private Key, Public Key) dla serwera i stacji inżynierów za pomocą wg genkey.
4. Konfiguracja interfejsu WireGuard na bramie brzegowej (Linux / MikroTik RouterOS) z adresem podsieci tunelowej 10.200.0.1/24.
5. Konfiguracja pliku klienta wg0.conf z wymuszeniem pełnego tunelowania: AllowedIPs = 0.0.0.0/0, ::/0.
6. Konfiguracja bezpiecznego resolvera DNS w tunelu (DNS = 10.200.0.1) uniemożliwiającego wycieki zapytań do publicznych DNS dostawców domowych.
7. Wdrożenie reguł zapory ogniowej nftables / RouterOS Firewall blokujących bezpośrednią komunikację pomiędzy połączonymi klientami zdalnymi (Client Isolation).
8. Zaimplementowanie mikrosegmentacji: zezwolenie na ruch z podsieci zdalnej wyłącznie do serwera plików CAD (port SMB 445) i serwera licencji (port 27000).
9. Zablokowanie dostępu z tunelu VPN do interfejsów zarządzających infrastrukturą (WinBox, SSH, panele webowe switchy i routerów).
10. Opracowanie skryptu Posture Check weryfikującego stan komputera przed nawiązaniem połączenia (status antywirusa, zapory, BitLockera).
11. Zaimplementowanie cyklicznej rotacji kluczy WireGuard oraz procedury natychmiastowego usuwania klucza publicznego zwolnionego pracownika.
12. Przeprowadzenie testu wycieków DNS za pomocą serwisów dnsleaktest.com / wireshark podczas aktywnego połączenia tunelowego.
13. Opracowanie wytycznych dla pracowników dotyczących bezpiecznego korzystania z domowych sieci Wi-Fi (WPA3-Personal, zmiana hasła routera domowego).
14. Zdefiniowanie bezwzględnego zakazu korzystania z prywatnych komputerów (BYOD) do realizacji połączeń z infrastrukturą projektową.
15. Zaprojektowanie logowania aktywności tunelu (adresy IP źródłowe, czasy trwania sesji, wolumen przetransferowanych danych).
16. Przygotowanie procedury awaryjnego odcięcia dostępu zdalnego w przypadku wykrycia anomalii ruchowych.
17. Sformułowanie kompletnego sprawozdania z diagramem topologii sieciowej i plikami konfiguracyjnymi.

Kluczowym elementem bezpiecznej architektury WireGuard jest parametr AllowedIPs w konfiguracji klienta. Ustawienie AllowedIPs = 0.0.0.0/0 przekierowuje cały ruch internetowy pracownika przez tunel firmowy, zapobiegając atakom typu Split Tunneling, w których złośliwy kod z sieci lokalnej pracownika mógłby przedostać się do sieci korporacyjnej.

Poniżej przedstawiono wzorcową konfigurację serwera WireGuard w systemie Linux oraz konfigurację reguł zapory nftables izolujących klientów:

Konfiguracja bezpiecznego klienta WireGuard (wg0.conf na laptopie pracownika) z ochroną przed wyciekami DNS:

Konfiguracja interfejsu WireGuard na routerze brzegowym MikroTik RouterOS z poziomu konsoli CLI:

1. Zaawansowana analiza kryptograficzna protokołu WireGuard (wymiana kluczy Noise IK, szyfr ChaCha20-Poly1305, hasze BLAKE2s) vs OpenVPN/IPsec.
2. Implementacja inspekcji stanu stacji końcowej (Posture Check: weryfikacja aktywnego EDR, włączonej zapory, aktualnych sygnatur i stanu BitLocker) przed zestawieniem tunelu.
3. Mikrosegmentacja sieciowa w oparciu o zapory nowej generacji (NGFW) uniemożliwiająca ruch boczny (Lateral Movement) ze stacji zdalnej do serwerów projektowych CAD/BIM.
4. Konfiguracja tunelu pełnego (Full Tunnel) z ochroną przed wyciekami DNS (DNS Leaks) i blokadą ruchu lokalnego (No Split-Tunneling).
5. Integracja VPN z centralnym serwerem uwierzytelniania RADIUS/MFA wymuszającym klucze FIDO2 podczas każdej inicjalizacji połączenia.
6. Ochrona własności intelektualnej i tajemnicy przedsiębiorstwa (know-how, dokumentacja architektoniczna i konstrukcyjna) w świetle ustawy o zwalczaniu nieuczciwej konkurencji.

Przykładowe wnioski (wzór do sprawozdania): Zbudowanie infrastruktury dostępu zdalnego opartej o nowoczesny protokół WireGuard pozwoliło na osiągnięcie maksymalnej przepustowości łącza przy jednoczesnym zachowaniu bezkompromisowej ochrony kryptograficznej z użyciem algorytmu ChaCha20-Poly1305. Wdrożenie przedpołączeniowej weryfikacji stacji (Posture Check) skutecznie uniemożliwia nawiązanie sesji VPN z urządzeń prywatnych lub stacji służbowych, na których wyłączono oprogramowanie EDR bądź zaporę lokalną. Zastosowanie mikrosegmentacji sieciowej i restrykcyjnych reguł zapory RouterOS bezwzględnie ograniczyło dostęp pracownika zdalnego wyłącznie do dedykowanego serwera licencji i repozytorium CAD, eliminując ryzyko infekcji sieci biurowej. Wymuszenie tunelowania pełnego z wbudowanym mechanizmem 'Kill Switch' całkowicie wykluczyło wycieki zapytań DNS i niekontrolowaną transmisję poza szyfrowanym tunelem w publicznych hotspotach. Opracowana polityka zapewnia kompletną ochronę tajemnicy przedsiębiorstwa i unikatowych projektów inżynierskich przed przechwyceniem przez konkurencję.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia autentyczności i nienaruszalności informacji. Kryptografia asymetryczna w poczcie.

Celem zadania jest zaprojektowanie wielowarstwowej polityki ochrony poczty elektronicznej oraz procedur weryfikacji tożsamości nadawców w przedsiębiorstwie komunalnym narażonym na ataki podszywania się (Spoofing) oraz wyłudzenia finansowe (Business Email Compromise - BEC). Studenci poznają mechanizmy kryptograficzne i domenowe stanowiące fundament współczesnego bezpieczeństwa poczty: rekordy SPF (Sender Policy Framework), podpisy cyfrowe DKIM (DomainKeys Identified Mail) z kluczami RSA/Ed25519 oraz rygorystyczne polityki DMARC (Domain-based Message Authentication, Reporting and Conformance) w trybie odrzucania (p=reject).

Projekt łączy wdrożenie techniczne na serwerach pocztowych i serwerach DNS z opracowaniem procedur organizacyjnych dla działu finansowo-księgowego, w tym obowiązkowej procedury weryfikacji poza pasmem (Out-of-Band Verification) przy zmianie numerów rachunków bankowych kontrahentów. Studenci uczą się analizować nagłówki MIME wiadomości, diagnozować błędy weryfikacji oraz interpretować raporty agregacyjne DMARC RUA/RUF.

Miejskie Przedsiębiorstwo Wodociągów i Kanalizacji (MPWiK) realizuje wielomilionowe inwestycje modernizacji oczyszczalni ścieków, współpracując z dziesiątkami generalnych wykonawców i dostawców technologii. Komunikacja biznesowa, przesyłanie faktur oraz dyspozycji płatniczych odbywa się drogą mailową. W ubiegłym miesiącu przestępcy przeprowadzili wyrafinowany atak Business Email Compromise: zarejestrowali domenę łudząco podobną do domeny głównego wykonawcy robót (atak typosquattingu) i przesłali do księgowości MPWiK sfałszowaną fakturę z informacją o 'zmianie rachunku bankowego ze względu na audyt skarbowy'.

Z powodu braku procedur weryfikacji telefonicznej oraz braku mechanizmów uwierzytelniania poczty przychodzącej, dział finansowy zrealizował przelew na kwotę 850 000 zł na rachunek podstawiony przez cyberprzestępców (tzw. słupa). Środki zostały natychmiast wypłacone w bankomatach i przekonwertowane na kryptowaluty. Dochodzenie policyjne i audyt bezpieczeństwa wykazały, że domena MPWiK nie posiadała skonfigurowanego rekordu DMARC ani kluczy DKIM, co pozwalało każdemu przestępcy wysyłać wiadomości bezpośrednio podszywające się pod zarząd spółki.

W spółce wszczęto postępowanie wyjaśniające, a prezes zarządu powołał komitet kryzysowy ds. cyberbezpieczeństwa. Nakazano natychmiastowe zabezpieczenie infrastruktury pocztowej przed jakimkolwiek podszywaniem się pod domenę przedsiębiorstwa oraz wdrożenie ścisłych procedur antyfraudowych w obrocie finansowym.

Zadaniem grupy laboratoryjnej jest opracowanie kompleksowej Polityki Bezpieczeństwa Poczty Elektronicznej i Transakcji Finansowych. Wymaga to skonfigurowania poprawnych rekordów DNS dla SPF (-all), wygenerowania kluczy kryptograficznych DKIM (min. 2048 bitów) i wdrożenia podpisywania poczty wychodzącej, a także publikacji polityki DMARC w trybie blokowania 'p=reject' wraz z adresem raportowania incydentów.

Równolegle zespół musi stworzyć Procedurę Weryfikacji Poza Pasmem (OOBV): każda dyspozycja zmiany numeru rachunku bankowego kontrahenta lub płatności powyżej 20 000 zł musi wymagać nawiązania kontaktu telefonicznego na zweryfikowany wcześniej numer stacjonarny z bazy kontrahentów i uzyskania autoryzacji drugiego członka zarządu (zasada czterech oczu).

• Serwer DNS BIND9 / dnsmasq lub konsola zarządzania DNS dostawcy domeny
• Serwer pocztowy Postfix z filtrem podpisywania Rspamd / OpenDKIM w środowisku Linux
• Narzędzie dig / drill / nslookup do weryfikacji rekordów DNS TXT
• Narzędzie darmowe online: DMARC Analyzer, MXToolbox, Mail-Tester do audytu nagłówków
• Klient poczty Thunderbird z wtyczką DKIM Verifier do inspekcji kryptograficznej nagłówków

1. Przeprowadzenie analizy ryzyka dla ataków email spoofing, spear-phishing oraz Business Email Compromise.
2. Zbadanie podatności domeny MPWiK na podszywanie się za pomocą narzędzi dig i testerów rekordów MX.
3. Zaprojektowanie rygorystycznego rekordu SPF w formacie TXT: v=spf1 ip4:X.X.X.X -all (z twardym odrzuceniem -all).
4. Instalacja i konfiguracja modułu OpenDKIM na serwerze pocztowym Linux Postfix.
5. Wygenerowanie 2048-bitowej asymetrycznej pary kluczy RSA dla selektora pocztowego mail2026 za pomocą opendkim-genkey.
6. Publikacja klucza publicznego DKIM w strefie DNS domeny pod nazwą mail2026._domainkey.mpwik.pl.
7. Skonfigurowanie serwera pocztowego do automatycznego podpisywania wszystkich wychodzących wiadomości nagłówkiem DKIM-Signature.
8. Opracowanie etapowej strategii wdrażania DMARC: faza 1 (p=none - monitorowanie), faza 2 (p=quarantine), faza 3 (p=reject).
9. Zredagowanie rekordu DNS DMARC: v=DMARC1; p=reject; rua=mailto:dmarc-rua@mpwik.pl; ruf=mailto:dmarc-ruf@mpwik.pl; sp=reject; aspf=r; adkim=r.
10. Skonfigurowanie weryfikacji SPF i DKIM dla poczty przychodzącej przez filtr antyspamowy Rspamd / Postfix.
11. Przeprowadzenie testu wysyłki i weryfikacji nagłówków Authentication-Results (dmarc=pass, dkim=pass, spf=pass).
12. Opracowanie procedury Out-of-Band Verification (OOBV) dla działu księgowości z formularzem weryfikacji kontrahenta.
13. Zdefiniowanie zasady dwóch par oczu (Dual Authorization) w systemie bankowości elektronicznej dla przelewów powyżej 20 000 zł.
14. Wdrożenie oznakowania wiadomości pochodzących z zewnątrz organizacji żółtym banerem ostrzegawczym [ZEWNĘTRZNA].
15. Zaprojektowanie programu cyklicznych szkoleń i kontrolowanych symulacji phishingu dla pracowników administracji.
16. Opracowanie instrukcji zgłaszania podejrzanych wiadomości e-mail do zespołu IT Security za pomocą dedykowanego przycisku.
17. Podsumowanie wdrożenia w sprawozdaniu laboratoryjnym z analizą zrzutów nagłówków e-mail.

Wielu administratorów popełnia błąd, publikując rekord SPF z tagiem ~all (SoftFail). Tag ten informuje serwery odbiorcze, że serwer nie jest autoryzowany, ale wiadomość nie powinna być odrzucana, co w połączeniu z brakiem DMARC umożliwia bezkarne podszywanie się pod domenę. Prawidłowa polityka wymaga stosowania mechanizmu twardego odrzucania -all w SPF oraz polityki DMARC p=reject.

Poniżej przedstawiono konfigurację i weryfikację rekordów SPF, DKIM oraz DMARC za pomocą polecenia dig w systemie Linux:

Analiza nagłówków autentyczności odebranej wiadomości e-mail (Authentication-Results) weryfikującej przejście wszystkich mechanizmów obronnych:

Próba przesłania wiadomości podszywającej się pod domenę przez nieautoryzowany serwer pocztowy kończy się natychmiastowym odrzuceniem:

1. Zrozumienie mechanizmów wielowarstwowego uwierzytelniania domeny pocztowej: rekordy SPF z restrykcyjnym mechanizmem `-all`, podpisy DKIM RSA-2048/Ed25519 oraz DMARC z polityką `p=reject`.
2. Analiza protokołów ARC (Authenticated Received Chain) oraz MTA-STS w celu ochrony przed manipulacją nagłówkami w toku przekazywania wiadomości.
3. Wdrożenie technologii DMARC Reporting (raporty RUA i RUF) i wykorzystanie darmowych narzędzi analitycznych do wykrywania nieautoryzowanych serwerów wysyłających.
4. Organizacyjna procedura 'weryfikacji poza pasmem' (Out-of-Band Verification) przez dedykowany, szyfrowany kanał telefoniczny/komunikator przy modyfikacjach umów i kont bankowych.
5. Automatyczna kwarantanna i piaskownica (Sandboxing) podejrzanych załączników na serwerze pocztowym Linux (Postfix/Rspamd/ClamAV).
6. Skutki finansowe i prawne udanych ataków typu Business Email Compromise (BEC) w świetle odpowiedzialności cywilnej członków zarządu.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie pełnego stosu uwierzytelniania poczty elektronicznej opartego o SPF (-all), klucze DKIM 2048-bit oraz restrykcyjną politykę DMARC p=reject trwale uniemożliwiło przestępcom podszywanie się pod domenę przedsiębiorstwa w kampaniach phishingowych. Uruchomienie zautomatyzowanej analizy raportów telemetrycznych DMARC (RUA) pozwoliło na natychmiastowe zidentyfikowanie i zneutralizowanie prób wykorzystania nazwy firmy w globalnych atakach socjotechnicznych. Zintegrowanie filtra antyspamowego Rspamd z modułem analizy heurystycznej i weryfikacją reputacji odnośników URL radykalnie zredukowało liczbę złośliwych wiadomości docierających do skrzynek pracowników. Formalna procedura obowiązkowej, telefonicznej autoryzacji poza pasmem (Out-of-Band) każdej dyspozycji zmiany konta bankowego kontrahenta skutecznie udaremniła symulowany atak typu Business Email Compromise (BEC). Połączenie rygorystycznych barier kryptograficznych na serwerze pocztowym ze świadomością personelu księgowego tworzy wysoce efektywny system obrony przed wyłudzeniami finansowymi.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Bezpieczeństwo protokołów komunikacyjnych i sieci komputerowych. Segmentacja sieci i ochrona warstwy 2.

Celem zadania jest zaprojektowanie spójnej, bezpiecznej architektury sieci komputerowej dla zespołu placówek oświatowych (szkoła podstawowa, liceum, biblioteka multimedialna), łączącej rygorystyczną mikrosegmentację warstwy 2 i 3 z mechanizmami uwierzytelniania dostępu do medium przewodowego i bezprzewodowego (IEEE 802.1X / WPA3-Enterprise). Studenci analizują zagrożenia wynikające z pracy w środowisku o wysokim poziomie nieufności, w którym użytkownicy (uczniowie) aktywnie podejmują próby podsłuchiwania ruchu, ataków ARP Spoofing, omijania filtrów treści oraz penetracji strefy administracyjnej.

Zadanie obejmuje praktyczną konfigurację wirtualnych sieci lokalnych (VLAN), strefy zdemilitaryzowanej (DMZ) dla publicznych serwerów szkoły, reguł zapory RouterOS / Linux z filtrowaniem międzystrefowym, izolacji klientów bezprzewodowych (Client Isolation / Private VLAN) oraz mechanizmów zabezpieczania warstwy łącza danych (DHCP Snooping, Dynamic ARP Inspection, Port Security).

Zespół Szkół Ogólnokształcących nr 4 w Krakowie dysponuje wspólną infrastrukturą sieciową obsługującą 80 komputerów w pracowniach informatycznych, 45 stacji roboczych kadry pedagogicznej i księgowości, sieć Wi-Fi dla ponad 800 uczniów oraz serwery szkolnego dziennika elektronicznego i monitoringu wizyjnego IP. Dotychczasowa infrastruktura funkcjonowała w ramach jednej płaskiej podsieci IP (192.168.1.0/24) bez jakiejkolwiek separacji VLAN i bez kontroli portów przełączników.

W ubiegłym semestrze uczniowie technikum informatycznego podłączyli w pracowni własnego laptopa z systemem Kali Linux i przeprowadzili atak ARP Cache Poisoning (programem ettercap), przechwytując hasła logowania nauczycieli do poczty elektronicznej oraz arkusza ocen. Dodatkowo wpięcie prywatnego routera z aktywnym serwerem DHCP doprowadziło do paraliżu całej sieci szkolnej (atak Rogue DHCP Server). Dyrekcja szkoły została zobligowana przez kuratorium i audytorów Urzędu Miasta do natychmiastowej modernizacji sieci.

Dyrektor placówki zażądał całkowitego odseparowania ruchu administracyjno-finansowego od ruchu uczniowskiego i gościnnego, zabezpieczenia przełączników przed podsłuchami i atakami na warstwę drugą oraz wdrożenia kontroli rodzicielskiej i filtrowania treści nieodpowiednich dla osób małoletnich.

Zespół laboratoryjny wciela się w rolę projektantów sieci. Zadaniem grupy jest opracowanie całościowej Polityki Bezpieczeństwa Sieci Szkolnej, zdefiniowanie podziału na VLAN (VLAN 10: Administracja i Kadry, VLAN 20: Dydaktyka, VLAN 30: Wi-Fi Uczniowie, VLAN 40: Kamery CCTV i IoT, VLAN 50: DMZ Serwery) oraz stworzenie reguł zapory ogniowej zakazujących jakiegokolwiek ruchu z VLAN 20/30 do VLAN 10.

Projekt musi zawierać konfigurację kontroli dostępu 802.1X (RADIUS) dla nauczycieli, izolację klientów w sieci Wi-Fi (zakaz komunikacji peer-to-peer pomiędzy smartfonami uczniów), mechanizmy DHCP Snooping i DAI na przełącznikach oraz reguły QoS ograniczające pasmo dla sieci uczniowskiej.

• MikroTik RouterOS v7.x (obsługa VLAN, Bridge VLAN Filtering, Firewall Filter)
• Linux z pakietami hostapd, freeradius oraz iptables / nftables
• Symulator sieciowy GNS3 / Cisco Packet Tracer lub fizyczny switch zarządzalny
• Narzędzie darmowe Wireshark do analizy ramek 802.1Q i weryfikacji izolacji
• Narzędzie arping / nmap do weryfikacji szczelności separacji podsieci

1. Inwentaryzacja zasobów i zdefiniowanie stref zaufania w sieci zespołu szkół.
2. Opracowanie planu adresacji IP i tagowania ramek VLAN (standard IEEE 802.1Q).
3. Konfiguracja mostu sieciowego (Bridge) z włączonym filtrowaniem VLAN (Bridge VLAN Filtering) w RouterOS.
4. Utworzenie interfejsów VLAN: VLAN 10 (Admin), VLAN 20 (Dydaktyka), VLAN 30 (Uczniowie Wi-Fi), VLAN 40 (CCTV), VLAN 50 (DMZ).
5. Zaprojektowanie i konfiguracja dedykowanych pul adresowych DHCP dla każdego VLAN z bezpiecznymi serwerami DNS.
6. Wdrożenie ochrony warstwy 2: konfiguracja DHCP Snooping na mostku w celu blokowania fałszywych serwerów DHCP (Rogue DHCP).
7. Wdrożenie mechanizmu Port Security z limitem adresów MAC i opcją sticky-mac na portach gniazd ściennych.
8. Zaimplementowanie izolacji klientów bezprzewodowych (default-forwarding=no / Private VLAN) w sieci Wi-Fi dla uczniów.
9. Konfiguracja reguł Firewall Filter: bezwzględne odrzucenie ruchu z VLAN 20, 30, 40 do podsieci administracyjnej VLAN 10.
10. Konfiguracja strefy DMZ (VLAN 50): udostępnienie serwera WWW na świat z całkowitym zablokowaniem inicjowania połączeń z DMZ do sieci wewnętrznej.
11. Zaprojektowanie uwierzytelniania WPA3-Enterprise z serwerem RADIUS (FreeRADIUS) dla laptopów nauczycieli i dyrekcji.
12. Konfiguracja transparentnego przekierowania zapytań DNS (port 53 UDP) do wewnętrznego serwera filtrującego (Pi-hole / AdGuard Home) z blokadą treści 18+.
13. Wdrożenie mechanizmu Simple Queue w RouterOS ograniczającego pasmo dla pojedynczego ucznia (Fair Queueing).
14. Przetestowanie szczelności separacji VLAN za pomocą skanowania Nmap z poziomu podsieci uczniowskiej.
15. Zdefiniowanie procedury podłączania nowych urządzeń sieciowych (autoryzacja adresu MAC przez administratora).
16. Opracowanie instrukcji bezpiecznej konfiguracji kamer monitoringu IP (VLAN 40 odcięty od dostępu do Internetu).
17. Zredagowanie sprawozdania technicznego z kompletnymi listingami poleceń konfiguracyjnych RouterOS CLI.

W sieciach oświatowych kluczowe jest pamiętanie o zabezpieczeniach warstwy 2 (Data Link Layer). Nawet najlepsze reguły zapory ogniowej warstwy 3 (IP) nie uchronią sieci przed podsłuchem, jeśli uczniowie w ramach tej samej podsieci mogą swobodnie zatruwać tablice ARP przełącznika lub rozsyłać pakiety DHCP Offer.

Poniżej przedstawiono konfigurację Bridge VLAN Filtering oraz ochrony DHCP Snooping w systemie MikroTik RouterOS z poziomu CLI:

Konfiguracja reguł zapory ogniowej Firewall Filter izolującej podsieci w RouterOS:

Weryfikacja braku możliwości przeskanowania sieci administracyjnej z komputera w pracowni uczniowskiej za pomocą Nmap:

1. Projekt bezpiecznej architektury sieci kampusowej z podziałem na warstwy (Access, Distribution, Core) oraz wydzieleniem stref zaufania (Trust Zones).
2. Implementacja protokołu uwierzytelniania portowego IEEE 802.1X z centralnym serwerem FreeRADIUS i dynamicznym przypisywaniem do sieci VLAN.
3. Bezpieczeństwo warstwy 2: mechanizmy DHCP Snooping, Dynamic ARP Inspection (DAI) oraz Port Security chroniące przed atakami typu Man-in-the-Middle i wyczerpaniem puli DHCP.
4. Konfiguracja strefy zdemilitaryzowanej (DMZ) dla publicznych serwerów WWW/LMS i separacja ruchu administracyjnego od sieci uczniowskiej i gościnnej Wi-Fi.
5. Wymuszenie mechanizmu Private VLAN / Client Isolation w sieciach bezprzewodowych dla słuchaczy i gości.
6. Wymogi prawne i standardy bezpieczeństwa danych osobowych uczniów, nauczycieli i dokumentacji egzaminacyjnej (SIO, e-dziennik, RODO).

Przykładowe wnioski (wzór do sprawozdania): Kompleksowa modernizacja infrastruktury sieciowej z wykorzystaniem segmentacji VLAN i protokołu 802.1X wyeliminowała wieloletnie zagrożenie swobodnego podsłuchiwania ruchu i ataków ARP Spoofing w sieci placówek oświatowych. Wdrożenie uwierzytelniania portowego opartego o serwer FreeRADIUS wymusiło na każdym podłączanym urządzeniu konieczność przedstawienia poświadczeń domenowych lub certyfikatu maszynowego przed uzyskaniem dostępu do medium sieciowego. Aktywacja mechanizmów ochrony warstwy łącza danych (DHCP Snooping, Dynamic ARP Inspection) skutecznie zablokowała próby stawiania fałszywych bram domyślnych oraz wyczerpywania adresacji IP przez złośliwe skrypty uczniowskie. Przeniesienie publicznych portali szkolnych i platformy e-learningowej do odseparowanej strefy DMZ zabezpieczyło wewnętrzną sieć administracyjno-finansową przed włamaniem od strony Internetu. Zaprojektowana topologia stanowi bezpieczny i skalowalny model środowiska teleinformatycznego, w pełni chroniący dane osobowe uczniów oraz integralność elektronicznych rejestrów ocen.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Zapewnienie ciągłości działania i obsługa sytuacji awaryjnych. Ramy prawne reagowania na incydenty.

Celem zadania jest zaprojektowanie formalnej procedury zarządzania incydentami bezpieczeństwa informacji dla średniej wielkości przedsiębiorstwa produkcyjnego, zgodnie z międzynarodowym standardem ISO/IEC 27035, wytycznymi CSIRT NASK oraz wymogami prawnymi art. 33 RODO i ustawy o Krajowym Systemie Cyberbezpieczeństwa. Studenci przechodzą przez wszystkie fazy cyklu życia incydentu: przygotowanie (Preparation), wykrywanie i analiza (Detection & Analysis), powstrzymywanie (Containment), usuwanie (Eradication), odzyskiwanie (Recovery) oraz wnioski poincydentalne (Lessons Learned).

W części technicznej zadanie wymaga opracowania procedury First Respondera: zabezpieczenia ulotnych dowodów cyfrowych (zrzut pamięci RAM, tablica połączeń sieciowych, lista aktywnych procesów) przed wyłączeniem komputera, natychmiastowej izolacji hosta na poziomie sieciowym oraz analizy logów systemowych (Linux journalctl, auditd, Windows EventLog). Studenci tworzą kompletny Plan Reagowania na Incydenty (IRP) wraz z algorytmem zgłaszania naruszeń do organu nadzorczego w terminie 72 godzin.

Fabryka Części Maszynowych SilesiaTech Sp. z o.o. w Gliwicach zatrudnia 350 pracowników i posiada zautomatyzowaną linię produkcyjną sterowaną przez serwery przemysłowe SCADA oraz stacje robocze inżynierów. W poniedziałek o godzinie 07:45 pracownik działu logistyki otworzył załącznik w wiadomości e-mail zatytułowanej 'Faktura korygująca PDF.exe'. Po kilku minutach stacja robocza zaczęła wykazywać nienaturalnie wysokie użycie procesora, a na pulpicie pojawił się komunikat z żądaniem okupu w zamian za odszyfrowanie plików (atak ransomware LockBit).

Spanikowany pracownik wyciągnął wtyczkę zasilania z gniazdka, co bezpowrotnie zniszczyło zawartość pamięci operacyjnej RAM, zawierającej klucze deszyfrujące wstrzyknięte do procesu oraz adresy IP serwerów dowodzenia C2 (Command and Control). Następnie komputer został ponownie włączony i podłączony do sieci Wi-Fi, co umożliwiło złośliwemu oprogramowaniu przeskanowanie podsieci biurowej i zainfekowanie dwóch kolejnych komputerów księgowości oraz zablokowanie wspólnego dysku sieciowego z projektami CAD.

W fabryce nie istniała żadna spisana procedura reagowania na incydenty, nikt nie wiedział, do kogo należy zgłosić zdarzenie, a zarząd dowiedział się o paraliżu produkcji dopiero o 14:00, gdy zatrzymała się linia montażowa. Dochodzenie wykazało również wyciek danych osobowych pracowników i kontrahentów, a brak zgłoszenia do UODO w wymaganym prawem terminie 72 godzin naraził firmę na wielomilionowe kary administracyjne.

Zarząd spółki zatrudnił zewnętrznych konsultantów (grupę laboratoryjną) w celu opracowania kompleksowego Planu Reagowania na Incydenty Bezpieczeństwa (Incident Response Plan - IRP) oraz przeszkolenia personelu. Nowa procedura musi precyzyjnie określić skład Zespołu Reagowania (CSIRT wewnętrzny), role i obowiązki, kryteria kategoryzacji incydentów (od incydentu o niskim wpływie do krytycznego) oraz bezwzględne zasady techniczne: zakaz wyłączania zasilania i natychmiastowe odpięcie kabla sieciowego.

Opracowanie musi zawierać procedurę triażu dowodowego (Live Forensics), szablony dokumentacji incydentu, wzorzec zgłoszenia naruszenia do Prezesa UODO i CSIRT NASK oraz plan przeprowadzenia sesji 'Lessons Learned' po zakończeniu działań naprawczych.

• Linux z narzędziami zbierania danych na żywo: LiME (Linux Memory Extractor), dd, ss, netstat, lsof, journalctl
• Windows Sysinternals: Autoruns, Process Explorer, TCPView, WinPmem / FTK Imager Lite
• Narzędzie do analizy logów: grep, awk, auditd oraz darmowy SIEM (Wazuh / Graylog)
• Szablony formularzy zgłoszeniowych UODO (naruszenie ochrony danych osobowych) i CSIRT NASK
• Narzędzie hashdeep / sha256sum do zapewnienia łańcucha dowodowego (Chain of Custody)

1. Sformułowanie definicji incydentu bezpieczeństwa informacji w odniesieniu do specyfiki SilesiaTech.
2. Opracowanie 4-stopniowej skali klasyfikacji powagi incydentów (Niski, Średni, Wysoki, Krytyczny).
3. Zdefiniowanie składu i ról w Zespole Reagowania na Incydenty (Koordynator, Specjalista IT, Prawnik/IOD, PR).
4. Opracowanie złotej zasady First Respondera: natychmiastowe odłączenie medium sieciowego (kabel RJ-45, wyłączenie Wi-Fi) bez wyłączania zasilania hosta.
5. Zaprojektowanie procedury zabezpieczania ulotnych dowodów cyfrowych z pamięci RAM (kolejność ulotności Order of Volatility wg RFC 3227).
6. Zrzut pamięci RAM za pomocą narzędzia WinPmem / LiME na zewnętrzny nośnik tylko do odczytu z natychmiastowym obliczeniem skrótu SHA-256.
7. Zabezpieczenie listy aktywnych połączeń sieciowych, tablicy routingu oraz otwartych portów za pomocą poleceń systemowych.
8. Wykonanie kopii binarnej dysku twardego bit-po-bicie (Forensic Image) narzędziem dd lub FTK Imager.
9. Wypełnienie metryki łańcucha dowodowego (Chain of Custody) z podpisami osób zabezpieczających materiał.
10. Izolacja zainfekowanego hosta w dedykowanym VLAN kwarantanny za pomocą reguły zapory sieciowej na routerze.
11. Przeprowadzenie analizy wektora wejścia (Root Cause Analysis) na podstawie logów systemowych i serwera pocztowego.
12. Zaprojektowanie algorytmu oceny ryzyka naruszenia praw osób fizycznych zgodnie z wytycznymi EROD (Europejska Rada Ochrony Danych).
13. Przygotowanie formalnego formularza zgłoszenia incydentu do Prezesa UODO (art. 33 RODO) w ciągu 72 godzin od wykrycia.
14. Opracowanie procedury bezpiecznego usuwania złośliwego oprogramowania i odtworzenia systemu z czystych, zweryfikowanych kopii zapasowych.
15. Przeprowadzenie warsztatów poincydentalnych (Lessons Learned) i zaktualizowanie procedur obronnych.
16. Opracowanie One-Point Lesson (instrukcja stanowiskowa przy monitorze) dla pracowników: co robić, gdy na ekranie pojawi się ransomware.
17. Skompilowanie kompletnego dokumentu IRP i sprawozdania technicznego.

W przypadku wykrycia aktywnej infekcji ransomware wyłączenie zasilania jest kardynalnym błędem. Wyłączenie niszczy pamięć RAM, w której często znajduje się niewymazany klucz szyfrujący lub fragmenty kodu złośliwego, a po restarcie złośliwe oprogramowanie może dokończyć szyfrowanie plików systemowych. Prawidłowa reakcja to natychmiastowe odłączenie kabla LAN / wyłączenie Wi-Fi przełącznikiem sprzętowym i przejście do procedury zrzutu pamięci.

Poniżej przedstawiono przykładowe polecenia szybkiego zbierania ulotnych danych systemowych (Live Triage) w systemie Linux:

Izolacja zainfekowanego hosta na poziomie zapory RouterOS z natychmiastowym przerwaniem aktywnych sesji TCP:

Analiza dziennika audytu systemowego w celu wykrycia uruchomienia podejrzanego pliku wykonywalnego w Linux (auditd):

1. Cykl życia obsługi incydentu wg standardu ISO/IEC 27035: Przygotowanie, Wykrywanie i analiza, Powstrzymanie, Usunięcie, Przywracanie i Wnioski powdrożeniowe.
2. Techniczne procedury natychmiastowej izolacji sieciowej skompromitowanego hosta za pomocą reguł zapory i komend EDR bez utraty zasilania stacji.
3. Metodyka zabezpieczania materiału dowodowego (Live Forensics): zrzut ulotnej pamięci RAM (narzędzia LiME, WinPmem) oraz zachowanie łańcucha dowodowego (Chain of Custody).
4. Analiza artefaktów systemowych (dzienniki Event Log / journalctl, pliki prefetch, rejestr systemowy, połączenia sieciowe) w celu identyfikacji wektora infekcji.
5. Procedury notyfikacji naruszeń ochrony danych do Prezesa UODO (art. 33 RODO w terminie 72h) oraz raportowanie incydentów do właściwego zespołu CSIRT szczebla krajowego.
6. Przeprowadzenie analizy poincydentowej (Post-Incident Review / Lessons Learned) i aktualizacja planów ciągłości działania (BCP/DRP).

Przykładowe wnioski (wzór do sprawozdania): Zastosowanie międzynarodowego standardu ISO/IEC 27035 w projektowaniu procedury obsługi incydentów pozwoliło na usystematyzowanie działań zespołów technicznych i eliminację chaosu decyzyjnego w obliczu symulowanego cyberataku. Wdrożenie automatycznej izolacji sieciowej skompromitowanej stacji roboczej natychmiast zatrzymało rozprzestrzenianie się złośliwego oprogramowania, zapobiegając zainfekowaniu centralnych serwerów bazodanowych. Pobranie zrzutu ulotnej pamięci RAM za pomocą narzędzi informatyki śledczej przed wyłączeniem zasilania umożliwiło wyekstrahowanie kluczy szyfrujących oraz zidentyfikowanie adresów IP serwerów Command and Control (C2). Precyzyjnie opracowane szablony raportowania zapewniły bezbłędne zgłoszenie naruszenia do Prezesa UODO oraz CSIRT NASK w rygorystycznym terminie 72 godzin, chroniąc organizację przed dotkliwymi karami finansowymi. Warsztaty poincydentowe (Lessons Learned) przełożyły zidentyfikowane słabości na konkretne reguły zapory ogniowej i nowe programy szkoleniowe dla personelu.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia poufności informacji. Cykl życia danych i nośników informatycznych.

Celem zadania jest opracowanie kompleksowej polityki i procedury technicznej bezpiecznego niszczenia danych oraz utylizacji nośników elektronicznych w banku komercyjnym. Studenci poznają międzynarodowe standardy niszczenia danych, ze szczególnym uwzględnieniem wytycznych NIST SP 800-88 Rev. 1 (Media Sanitization) w podziale na poziomy: Clear (logiczne wymazanie), Purge (kryptograficzne/sprzętowe usunięcie uniemożliwiające odtworzenie w warunkach laboratoryjnych) oraz Destroy (fizyczne zniszczenie nośnika). Projekt analizuje odmienne podejście do tradycyjnych dysków magnetycznych HDD oraz nowoczesnych nośników półprzewodnikowych SSD (NVMe/SATA).

W części praktycznej studenci konfigurują i testują darmowe narzędzia do niszczenia danych w środowisku Linux (shred, hdparm ATA Secure Erase, nvme-cli format cryptosecure, blkdiscard), badają zjawisko Wear Leveling w dyskach flash oraz tworzą sformalizowany Wzór Protokołu Komisyjnego Zniszczenia Nośników, spełniający wymogi audytu KNF, Europejskiego Banku Centralnego (EBC) i RODO.

Bank Spółdzielczy Ziemia Mazowiecka przeprowadza gruntowną modernizację infrastruktury serwerowej i wymianę stacji roboczych we wszystkich 12 oddziałach. Wymianie podlega ponad 250 komputerów stacjonarnych, 60 serwerów bazodanowych oraz kilkaset dysków SSD i magnetycznych taśm LTO. Część wycofywanego sprzętu (laptopy i stacje PC) ma zostać przekazana jako darowizna dla lokalnych szkół podstawowych i domów kultury, a uszkodzone dyski z macierzy produkcyjnych mają trafić do utylizacji w zewnętrznej firmie recyklingowej.

W trakcie audytu bezpieczeństwa przeprowadzonego przez audytora KNF ujawniono, że dotychczasowy proces wycofywania sprzętu polegał na wykonaniu standardowego 'szybkiego formatowania' w instalatorze Windows lub usunięciu partycji poleceniem fdisk. Audytor za pomocą darmowego oprogramowania TestDisk / PhotoRec odzyskał ze 'sformatowanego' laptopa ponad 18 000 skanów dowodów osobistych klientów ubiegających się o kredyty hipoteczne oraz pełną bazę historii rachunków bankowych.

Skandal zagroził natychmiastowym cofnięciem licencji bankowej przez KNF oraz nałożeniem maksymalnej kary przez UODO za rażące naruszenie poufności danych osobowych. Zarząd banku natychmiast wstrzymał jakiekolwiek przekazywanie sprzętu na zewnątrz i nakazał opracowanie rygorystycznej procedury czyszczenia nośników, wykluczającej możliwość odzyskania choćby jednego bitu informacji.

Grupa laboratoryjna przyjmuje rolę audytorów i inżynierów bezpieczeństwa. Zadaniem zespołu jest skonstruowanie Polityki Bezpiecznego Wycofywania i Utylizacji Nośników Danych. Dokument musi precyzyjnie rozróżniać metody czyszczenia w zależności od dalszego losu nośnika (ponowne użycie wewnątrz banku, darowizna na zewnątrz, złomowanie) oraz technologii wykonania nośnika (HDD vs SSD z pamięcią 3D TLC/QLC NAND, taśmy magnetyczne).

Projekt wymaga zaimplementowania i opisania komend: ATA Secure Erase dla dysków SATA, Sanitize Block Erase dla dysków NVMe, wielokrotnego nadpisywania shred dla HDD oraz procedury demagnetyzacji (degaussing polem min. 11 000 Gaussów) i mechanicznego niszczenia (mielenie na wióry o frakcji poniżej DIN 66399 E-4) dla dysków uszkodzonych. Całość wieńczy formalny protokół komisyjnego niszczenia.

• Linux LiveCD (Ubuntu Server / SystemRescue / DBAN / ShredOS)
• Narzędzie hdparm do wydawania komend sprzętowych ATA Secure Erase / Enhanced Erase
• Narzędzie nvme-cli do formatowania i sprzętowego czyszczenia dysków NVMe (Sanitize / Crypto Erase)
• Narzędzie shred / dd / blkdiscard do programowego czyszczenia bloków
• Narzędzie hexdump / xxd / strings do weryfikacji skuteczności usunięcia danych z sektorów

1. Analiza prawna i audytowa wymogów KNF, RODO oraz standardu NIST SP 800-88 Rev. 1 w zakresie Media Sanitization.
2. Sklasyfikowanie nośników podlegających utylizacji: magnetyczne HDD, półprzewodnikowe SSD (SATA/NVMe), pamięci flash USB, taśmy LTO.
3. Zbadanie różnic w kasowaniu danych: dlaczego programowe nadpisywanie nie gwarantuje usunięcia danych z SSD (Wear Leveling, Over-provisioning).
4. Przygotowanie nośnika rozruchowego Linux LiveCD (SystemRescue / ShredOS) do operacji sanitization offline.
5. Zbadanie stanu zabezpieczeń dysku SATA za pomocą polecenia hdparm -I /dev/sdX (sprawdzenie flag security: frozen, locked).
6. Opracowanie procedury odblokowania stanu frozen dysku (odpięcie i ponowne wpięcie zasilania SATA w trybie hot-plug).
7. Wydanie polecenia Enhanced Security Erase za pomocą hdparm w celu skasowania wszystkich sektorów fizycznych i kluczy szyfrujących kontrolera.
8. Wykorzystanie pakietu nvme-cli do wykonania komendy NVMe Sanitize (Block Erase lub Crypto Erase) na dysku SSD NVMe.
9. Zastosowanie narzędzia shred z nadpisaniem pseudolosowym i wypełnieniem zerami (shred -n 3 -z -v) dla tradycyjnych dysków HDD.
10. Weryfikacja skuteczności czyszczenia: inspekcja surowych sektorów dysku za pomocą hexdump / xxd (brak jakichkolwiek czytelnych ciągów tekstowych).
11. Zdefiniowanie kryteriów fizycznego niszczenia dla dysków uszkodzonych (demagnetyzacja degausserem impulsowym o natężeniu min. 1,5 Tesli).
12. Opracowanie wymagań dla mechanicznego rozdrabniania nośników (niszczarki dysków DIN 66399 poziom E-4, wielkość cząstki < 160 mm²).
13. Zaprojektowanie składu i trybu pracy 3-osobowej komisji likwidacyjnej (Administrator IT, Inspektor Bezpieczeństwa, Przedstawiciel Księgowości).
14. Sformułowanie wzorca formalnego Protokołu Zniszczenia Nośników Informacji (numer seryjny dysku, model, data, metoda, podpisy członków komisji).
15. Opracowanie zasad bezpiecznego transportu nośników do zewnętrznego utylizatora (plombowane bezpieczne pojemniki, nadzór wideo).
16. Wdrożenie rejestru ewidencji wycofanych środków trwałych i certyfikatów utylizacji przekazywanych do audytu KNF.
17. Podsumowanie procedury w sprawozdaniu laboratoryjnym z listingami komend i wzorcem protokołu.

Pamiętajcie, że w przypadku nowoczesnych dysków półprzewodnikowych SSD używanie narzędzia `dd` lub `shred` jest nieskuteczne i niewskazane. Kontroler dysku SSD stosuje mechanizmy równoważenia zużycia komórek pamięci (Wear Leveling) oraz ukryte bloki zapasowe (Over-provisioning). Oznacza to, że komendy zapisu z poziomu systemu operacyjnego trafiają tylko do logicznych bloków, pozostawiając dane w sektorach fizycznych nienaruszone. Jedyną skuteczną metodą logiczną dla SSD jest sprzętowa komenda ATA Secure Erase lub NVMe Sanitize.

Poniżej przedstawiono procedurę sprzętowego czyszczenia dysku SATA SSD za pomocą polecenia hdparm w systemie Linux:

Sprzętowe czyszczenie dysku SSD NVMe za pomocą pakietu nvme-cli (komenda Sanitize Block Erase):

Weryfikacja usunięcia danych za pomocą hexdump na pierwszych 100 megabajtach dysku:

1. Klasyfikacja metod sanatyzacji nośników wg standardu NIST SP 800-88 Rev. 1: Clear (nadpisywanie logiczne), Purge (ATA Secure Erase / Sanitize Crypto Scramble), Destroy (zniszczenie fizyczne).
2. Różnice w niszczeniu danych na magnetycznych dyskach twardych HDD a pamięciach półprzewodnikowych SSD (mechanizmy Wear Leveling, komórki rezerwowe over-provisioning).
3. Wykorzystanie zjawiska demagnetyzacji (Degaussing) o wysokim natężeniu pola magnetycznego (powyżej 10 000 Gaussów) dla nośników magnetycznych i taśm LTO.
4. Metody mechanicznego niszczenia nośników (niszczarki wielonożowe DIN 66399 poziom H-5/E-4, perforacja talerzy, mielenie).
5. Procedury formalne: komisyjne protokołowanie utylizacji, podwójna weryfikacja numerów seryjnych, plomby zabezpieczające i certyfikaty niszczenia.
6. Rygory zachowania tajemnicy bankowej, normy PN-ISO/IEC 27001 oraz sankcje karne za niedopełnienie obowiązków ochrony tajemnicy zawodowej i danych osobowych.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie kompleksowej procedury wycofywania i sanatyzacji nośników opartej na standardzie NIST SP 800-88 Rev. 1 trwale wyeliminowało ryzyko odzyskania wrażliwych danych finansowych z dysków przekazywanych do utylizacji. W toku badań laboratoryjnych udowodniono, że polecenie ATA Secure Erase oraz niszczenie kryptograficzne (Cryptographic Erase) stanowią jedyne skuteczne metody czyszczenia nośników SSD, uniemożliwiające odczyt danych z ukrytych komórek rezerwowych (Over-Provisioning). Dla dysków magnetycznych i taśm backupowych zawierających dane transakcyjne zastosowano certyfikowaną demagnetyzację impulsową, która trwale niszczy strukturę domen magnetycznych oraz fabryczne ścieżki pozycjonujące serwo. Komisyjne protokołowanie procesu z ewidencją numerów seryjnych i fotograficzną dokumentacją fizycznego rozdrobnienia nośników na cząstki poniżej 2 mm spełnia rygorystyczne wymagania normy DIN 66399 na poziomie H-5. Zapewnienie pełnego łańcucha nadzoru (Chain of Custody) chroni instytucję finansową przed zarzutem naruszenia tajemnicy bankowej oraz karami ze strony organów nadzoru KNF i UODO.