Zdalny dostęp do systemów ICS - zasady bezpieczeństwa

W maju 2021 roku operator rurociągu Colonial Pipeline zapłacił 4,4 mln USD okupu grupie DarkSide. Wektor wejścia? Jedno skompromitowane hasło do VPN bez uwierzytelniania wieloskładnikowego. W grudniu 2025 skoordynowany atak na polską infrastrukturę OZE wykorzystał podatne urządzenia brzegowe z dostępem do internetu, uszkadzając firmware kontrolerów RTU w ponad 30 instalacjach (CISA Alert, luty 2026). Oba incydenty łączy wspólny mianownik - źle zabezpieczony zdalny dostęp do sieci OT.

Zdalny dostęp jest niezbędny - serwis, diagnostyka, aktualizacje firmware, monitorowanie procesu wymagają łączności. Ale każde połączenie zdalne to dodatkowa powierzchnia ataku.

Źródło: Forescout 2026, CISA ICS Advisories, Claroty CPS Security 2025, SANS ICS/OT 2025

Poniżej przedstawiamy 17 zasad bezpiecznego zdalnego dostępu do systemów ICS, opracowanych na podstawie normy IEC 62443, NIST SP 800-82 Rev. 3, rekomendacji CISA i doświadczeń z projektów dla infrastruktury krytycznej.

Fundamenty - architektura i zagrożenia

Dlaczego zdalny dostęp do OT jest trudniejszy niż do IT

W sieciach IT zdalny dostęp przez VPN jest standardem od lat - i naturalną reakcją wielu organizacji jest przeniesienie tych samych wzorców do OT. Stąd biorą się problemy: sterowniki PLC wystawione do internetu, prosty VPN + RDP jako jedyne zabezpieczenie, współdzielone konta serwisowe bez MFA. Środowiska OT mają jednak inne priorytety i ograniczenia:

Aspekt	IT	OT
Priorytet	Poufność danych	Dostępność i bezpieczeństwo fizyczne (safety)
Tolerancja przestojów	Minuty-godziny	Sekundy (procesy ciągłe nie mogą być przerywane)
Aktualizacje	Regularne, automatyczne	Rzadkie, wymagające okna serwisowego i testów
Protokoły	HTTP/S, SSH, RDP (z uwierzytelnianiem)	Modbus, OPC, S7comm (często bez uwierzytelniania)
Cykl życia	3-5 lat	15-25 lat
Skutek ataku	Utrata danych, przerwa w usługach	Uszkodzenie urządzeń, zagrożenie życia, katastrofa ekologiczna

Te różnice oznaczają, że proste przeniesienie rozwiązań z IT (VPN + RDP + hasło) nie wystarczy. W OT nie można przerwać sesji w dowolnym momencie, nie można automatycznie aktualizować urządzeń na drugim końcu połączenia, a protokoły sterowania (Modbus, S7comm) nie oferują własnych mechanizmów uwierzytelniania. Zabezpieczenia muszą być realizowane na poziomie architektury sieciowej - jako element strategii defense in depth - stąd 17 zasad opisanych poniżej.

Incydenty związane ze zdalnym dostępem

Źle zabezpieczony zdalny dostęp jest jednym z najczęstszych wektorów ataków na systemy OT. Poniższe incydenty pokazują różne scenariusze i ich konsekwencje.

Incydent	Rok	Wektor zdalnego dostępu	Konsekwencje
Colonial Pipeline	2021	VPN bez MFA, skompromitowane hasło	Wyłączenie rurociągu na 6 dni, 4,4 mln USD okupu
Oldsmar Water	2021	TeamViewer na stacji HMI - dostęp z internetu	Próba zwiększenia stężenia NaOH z 100 do 11 100 ppm
Dharma ransomware	2019-2020	RDP wystawiony do internetu	Szyfrowanie systemów SCADA przez skompromitowany terminal server
Atak na OZE w Polsce	2025	Podatne urządzenia brzegowe (edge devices)	Wiper malware, uszkodzenie firmware RTU, utrata łączności
Volt Typhoon	2024	Exploity VPN i edge devices (Fortinet, Ivanti)	Prepozycjonowanie w infrastrukturze krytycznej USA

Źródła: CISA advisories, FBI/DOE joint fact sheet, CERT Polska, Mandiant Threat Research.

Segmentacja jako fundament zdalnego dostępu

Każde rozwiązanie zdalnego dostępu do OT musi opierać się na prawidłowej segmentacji sieci. Według IEC 62443-3-2 sieć przemysłowa dzieli się na strefy (zones) o wspólnych wymaganiach bezpieczeństwa, połączone korytarzami (conduits) z kontrolowaną komunikacją.

Zdalny dostęp to korytarz w rozumieniu normy - i musi być traktowany z taką samą rygorystycznością jak każdy inny przepływ danych między strefami. Punkt dostępu zdalnego powinien znajdować się w dedykowanej strefie DMZ, nie bezpośrednio w sieci OT.

---

17 zasad bezpiecznego zdalnego dostępu do OT

Zasady pogrupowaliśmy w pięć kategorii odpowiadających głównym obszarom ryzyka:

Kategoria	Zasady	Czego dotyczy
Architektura	1-4	Jak zbudować ścieżkę dostępu - DMZ, dwuskokowa architektura, kierunek połączeń
Uwierzytelnianie i autoryzacja	5-8	Kto może wejść i na jakich warunkach - MFA, konta, uprawnienia
Monitoring i rejestracja	9-12	Co widać w aktywnych sesjach - logi, nagrywanie, inspekcja protokołów OT
Ograniczanie działalności	13-15	Co powinno być w ogóle dostępne zdalnie - SIS, transfer plików, okna czasowe
Hardening	16-17	Ochrona samej infrastruktury dostępowej i gotowość na incydent

Architektura

Zasada 1: Unikaj kaskadowego przenoszenia ryzyka NIST SP 800-53: SC-7 (Boundary Protection), SC-7(5) (Deny by Default)

Architektura zdalnego dostępu nie powinna umożliwiać przechodzenia jednym protokołem z internetu przez DMZ do sieci OT. Jeśli łańcuch dostępu to: VPN -> serwer terminali (RDP) -> stacja inżynierska (RDP), to kompromitacja jednej podatności RDP otwiera drogę do OT. Dharma ransomware (2019-2020) wykorzystywał dokładnie ten scenariusz - propagacja przez skompromitowane serwery terminali RDP do systemów SCADA.

Zasada 2: Połączenia inicjowane ze strony chronionej NIST SP 800-53: SC-7(5) (Deny by Default, Allow by Exception)

Reguły firewalla powinny blokować wszystkie połączenia przychodzące do sieci OT. Zamiast tego, połączenie powinno być inicjowane z sieci OT na zewnątrz (do strefy DMZ). Dzięki temu porty wejściowe nie są stale eksponowane, a sesja jest dostępna tylko tymczasowo.

Zasada 3: Strefa DMZ jako bufor NIST SP 800-53: SC-7(4) (External Telecommunications Services - DMZ)

Między siecią korporacyjną a OT musi istnieć strefa DMZ z firewallami po obu stronach. Serwery pośredniczące (jump servery, terminale) powinny znajdować się w DMZ, nie w sieci OT. Żadne dane produkcyjne nie powinny być przechowywane na serwerach w DMZ.

Zasada 4: Brak bezpośredniego dostępu z internetu do OT NIST SP 800-53: AC-17 (Remote Access), SC-7 (Boundary Protection)

Żadne urządzenie OT nie powinno być dostępne bezpośrednio z internetu - ani przez port forwarding, ani przez wystawienie VPN endpoint bezpośrednio na urządzeniu OT. Dotyczy to również urządzeń brzegowych (edge devices), VPN concentratorów i modemów LTE. CISA w rekomendacjach z maja 2025 explicite zabrania eksponowania interfejsów zarządzania OT do internetu, nawet pośrednio.

Uwierzytelnianie i autoryzacja

Architektura tworzy ramy - uwierzytelnianie decyduje, kto może wejść i na jakich warunkach.

Zasada 5: Uwierzytelnianie wieloskładnikowe (MFA) NIST SP 800-53: IA-2(1) (MFA - Network Access), IA-2(2) (MFA - Non-privileged Access)

Każdy zdalny dostęp do sieci OT musi wymagać uwierzytelniania wieloskładnikowego. MFA powinno być wymagane na każdym skoku: przy logowaniu do VPN, przy wejściu na jump server i przy dostępie do stacji inżynierskiej.

IEC 62443-3-3 SR 1.1 RE 2 wymaga MFA dla dostępu przez sieci niezaufane od SL 3. W praktyce każdy zdalny dostęp przechodzi przez sieć niezaufaną.

Wybór metody MFA dla środowisk OT ma specyficzne ograniczenia:

Metoda MFA	Zalety w OT	Ograniczenia	Kiedy stosować
Hardware TOTP (YubiKey, Token2)	Nie wymaga smartfona (często zabronione w fabrykach), działa offline, standard OATH RFC 6238	Wymaga dystrybucji fizycznych tokenów	Większość środowisk OT
FIDO2 / WebAuthn (YubiKey 5)	Najsilniejsze zabezpieczenie, odporne na phishing, nie wymaga łączności	Nie kompatybilne ze starszymi klientami VPN	Środowiska wysokiego bezpieczeństwa (SL 3-4)
Smart card / PIV	Standard w sektorze energetycznym (NERC CIP)	Wymaga czytnika kart na stacji	Utilities, infrastruktura krytyczna
TOTP aplikacja (Google Auth, MS Authenticator)	Niski koszt, łatwa dystrybucja	Wymaga smartfona	Tylko gdy smartfony dozwolone na obiekcie
SMS OTP	-	NIST SP 800-63B nie rekomenduje, zależność od telekomu	Nie stosować

Zasada 6: Akceptacja połączenia po stronie chronionej NIST SP 800-53: AC-17(1) (Monitoring and Control of Remote Access)

Połączenie zdalne nie powinno być automatycznie zestawiane. Osoba z uprawnieniami po stronie OT (np. inżynier utrzymania ruchu) powinna świadomie zaakceptować sesję - np. generując jednorazowy link lub zatwierdzając request w aplikacji. Dedykowane systemy SRA realizują to jako workflow: serwisant składa request, inżynier po stronie OT zatwierdza, system generuje jednorazowy token z oknem czasowym.

W instalacjach bezzałogowych (podwodne, niestrzeżone, zdalne farmy) akceptacja może być realizowana za pośrednictwem środków technicznych - np. dedykowany kanał komunikacji out-of-band, zatwierdzenie przez aplikację mobilną lub preautoryzowany harmonogram okien serwisowych.

Zasada 7: Indywidualne konta, nie współdzielone NIST SP 800-53: IA-2 (Identification and Authentication), AC-2 (Account Management)

Każdy użytkownik zdalny musi mieć indywidualne konto. Współdzielone konta (“serwis_vendor1”) uniemożliwiają audyt i przypisanie odpowiedzialności. IEC 62443-3-3 SR 1.1 RE 1 wymaga unikalnej identyfikacji każdego użytkownika od SL 2 - dotyczy to także kont maszynowych i skryptów automatyzacji.

Konta serwisowe dostawców powinny być powiązane z konkretnym zleceniem - patrz Zasada 15 dotycząca JIT access. CISA rekomenduje blokadę kont po wielokrotnych nieudanych próbach logowania i usuwanie nieaktywnych kont serwisowych.

Zasada 8: Zasada minimalnych uprawnień NIST SP 800-53: AC-6 (Least Privilege), AC-6(1) (Authorize Access to Security Functions)

Użytkownik zdalny powinien mieć dostęp tylko do tych systemów i funkcji, które są niezbędne do wykonania konkretnego zadania. IEC 62443-3-3 SR 2.1 RE 1 wymaga autoryzacji opartej na rolach (RBAC) - inżynier serwisu ma inny zestaw uprawnień niż operator, administrator sieci czy audytor.

W praktyce oznacza to oddzielenie roli “może czytać parametry PLC” od “może zmieniać program PLC” i “może uruchomić/zatrzymać proces”. SR 2.1 RE 3 (od SL 4) wymaga dual approval - krytyczne operacje wymagają zatwierdzenia przez dwie osoby.

Monitoring i rejestracja

Nawet poprawna architektura i silne uwierzytelnianie nie wystarczą, jeśli nie widać co się dzieje w aktywnych sesjach.

Zasada 9: Monitoring i identyfikacja ruchu NIST SP 800-53: SI-4 (System Monitoring), AU-2 (Event Logging)

Cały ruch zdalnego dostępu powinien być monitorowany i logowany - z timestampem, identyfikatorem użytkownika, adresem źródłowym i docelowym, protokołem i wynikiem (sukces/porażka). System powinien generować alerty na: połączenia w nietypowych godzinach, połączenia z nieznanych lokalizacji, anomalie w protokołach OT (nietypowe function codes Modbus, próby zapisu do rejestrów PLC, zmiany programu) i próby dostępu poza zakresem uprawnień.

Inspekcja głęboka pakietów (DPI - Deep Packet Inspection) wymaga firewalli, które rozumieją protokoły przemysłowe - nie tylko adresy IP i porty, ale treść komend sterujących. Modbus TCP (port 502) to najszerzej stosowany protokół sterowania w instalacjach przemysłowych. Każda komenda ma kod funkcji (Function Code, FC) - poniższa tabela klasyfikuje je według ryzyka:

Function code	Operacja	Ryzyko	Rekomendacja
FC 01-04	Read Coils / Discrete Inputs / Holding Registers / Input Registers	Niskie (rekonesans)	Dozwolone z SCADA/HMI, logowane
FC 05, 06	Write Single Coil / Single Register	Wysokie (zmiana stanu)	Tylko z autoryzowanych stacji inżynierskich, z oknem czasowym
FC 15, 16 (0x0F, 0x10)	Write Multiple Coils / Multiple Registers	Wysokie	Jak FC 05/06 - ograniczyć do okien serwisowych
FC 08	Diagnostics (loopback, reset counters)	Średnie	Blokować z sieci niezaufanych
FC 43 (0x2B)	Read Device Identification	Średnie (ujawnia informacje)	Blokować z sieci niezaufanych

Firewalle z obsługą DPI dla protokołów OT: Fortinet FortiGate (80+ protokołów OT, 3000+ typów komend), Palo Alto Networks NGFW (App-ID dla Modbus, DNP3, IEC 104, OPC), Cisco IE4010/IR8340 (natywne filtrowanie Modbus TCP), Moxa EDR-G9010 (DPI dla Modbus, EtherNet/IP, PROFINET, OPC UA). Pasywny monitoring (bez ryzyka wpływu na proces): Claroty, Nozomi Networks, Dragos - pracują w trybie tap/span port.

Zasada 10: Terminuj ruch w DMZ, nie tuneluj do OT NIST SP 800-53: SC-7(7) (Prevent Split Tunneling), SI-4 (System Monitoring)

Szyfrowany tunel end-to-end między serwerem zdalnym a urządzeniem OT uniemożliwia inspekcję ruchu. Ruch powinien być terminowany na firewallu lub urządzeniu pośredniczącym w DMZ, gdzie można go inspekcjonować (DPI), a następnie przekierowany do OT w oddzielnej sesji.

Zasada 11: Nagrywanie sesji NIST SP 800-53: AU-3 (Content of Audit Records), AU-12 (Audit Record Generation)

Sesje zdalnego dostępu do systemów OT powinny być nagrywane (screen recording, keystroke logging). Nagrania służą jako dowód w przypadku incydentu oraz jako narzędzie audytu.

Narzędzia do nagrywania sesji w kontekście OT:

Narzędzie	Protokoły	Funkcje kluczowe	Specyfika OT
CyberArk PSM	RDP, SSH, VNC	Transparent proxy, keystroke indexing, Zero Standing Privileges	Integracje z Rockwell, Schneider Electric
BeyondTrust PRA	RDP, SSH, VNC, HTTPS	Command allowlist/blocklist w SSH, ruggedized appliance	Jump technology bez bezpośredniej łączności IP
Wallix Bastion PAM4OT	RDP, SSH, VNC	OCR na nagraniach (searchable text), agentless	Wersja dedykowana OT, zgodność z IEC 62443-2-4
ManageEngine PAM360	RDP, SSH, Telnet, VNC, SQL	Session shadowing, live takeover	Routing przez jump server do PLC/SCADA

Kluczowe wymaganie: nagrania muszą być przechowywane w lokalizacji niedostępnej dla nagrywanych użytkowników (immutable audit log).

Zasada 12: Zarządzanie sesjami NIST SP 800-53: SC-10 (Network Disconnect), AC-12 (Session Termination)

Administrator po stronie OT powinien mieć możliwość podglądu aktywnych sesji w czasie rzeczywistym, zakończenia sesji w przypadku wykrycia nieprawidłowości i ustawiania limitów czasowych (auto-disconnect po timeout - NIST rekomenduje 15-30 minut nieaktywności).

Ograniczanie działalności

Zasady 1-12 dotyczą tego, jak budować i kontrolować dostęp. Zasady 13-15 odpowiadają na pytanie: co i kiedy powinno być w ogóle dostępne zdalnie.

Zasada 13: Ograniczenie dostępu do komponentów OT NIST SP 800-53: AC-3 (Access Enforcement), PE-3 (Physical Access Control)

Systemy realizujące funkcje bezpieczeństwa (SIS - Safety Instrumented Systems) nie powinny być dostępne przez zdalny dostęp. Zdalna modyfikacja logiki SIS to ryzyko niedopuszczalne w większości środowisk - IEC 62443-3-3 SR 5.1 wymaga oddzielenia SIS od reszty sieci OT. NIST SP 800-82 Rev. 3 sekcja 5.5 explicite adresuje ochronę systemów safety.

Zasada 14: Kontrola transferu plików NIST SP 800-53: SI-3 (Malware Protection), MA-4 (Nonlocal Maintenance)

Pliki przesyłane do sieci OT (firmware, konfiguracje, patche) muszą przechodzić przez skanowanie malware w strefie DMZ. NIST MA-4 wymaga autoryzacji i monitoringu zdalnej konserwacji, w tym transferu plików. Dedykowane systemy SRA oferują skanowanie w locie.

Zasada 15: Ograniczenie czasowe dostępu (JIT) NIST SP 800-53: AC-2(2) (Automated Temporary and Emergency Account Management)

Zdalny dostęp powinien być aktywny tylko na czas wykonywania prac - model Just-In-Time (JIT). Konto aktywowane na wniosek, z określonym oknem czasowym, automatycznie dezaktywowane po upływie czasu. NIST AC-2(2) wymaga automatycznego zarządzania kontami tymczasowymi i awaryjnymi - łącznie z automatycznym wyłączaniem.

Zapomniane konto serwisowe aktywne miesiące po zakończeniu prac to typowy wektor ataku. JIT eliminuje to ryzyko strukturalnie - narzędzia takie jak CyberArk Alero czy BeyondTrust JIT access generują poświadczenia na żądanie i rewokują je automatycznie.

Hardening i ochrona infrastruktury dostępowej

Każde urządzenie w łańcuchu zdalnego dostępu jest potencjalnym celem - od VPN concentratora po jump server.

Zasada 16: Hardening urządzeń dostępowych NIST SP 800-53: CM-7 (Least Functionality), SI-2 (Flaw Remediation)

Serwery terminali, jump servery, VPN concentratory - każde urządzenie w łańcuchu zdalnego dostępu musi być hardenowane zgodnie z CIS Benchmarks. NIST CM-7 wymaga ograniczenia funkcji do minimum niezbędnego - co w praktyce oznacza:

Zasada 17: Plan awaryjny i procedura odcięcia NIST SP 800-53: IR-4 (Incident Handling), IR-8 (Incident Response Plan)

Musi istnieć udokumentowana i przećwiczona procedura natychmiastowego odcięcia zdalnego dostępu w przypadku wykrycia incydentu. NIST IR-4 rozkłada obsługę incydentu na sześć faz - od przygotowania po odtworzenie. Procedura odcięcia powinna być zdefiniowana dla każdej z nich.

Matryca decyzyjna - wybór rozwiązania zdalnego dostępu

Wybór rozwiązania zależy od wymaganego Security Level według IEC 62443, budżetu i specyfiki środowiska. Poniższa matryca pomaga ocenić dostępne opcje.

Kryterium	VPN + RDP (typowe IT)	Dedykowane SRA (Honeywell, Claroty, Dispel)	Zero Trust OT (Zscaler, Secomea)
Zgodność z IEC 62443	Częściowa - wymaga dodatkowej konfiguracji	Pełna - projektowane pod OT	Pełna - wbudowane strefy i korytarze
MFA	Do dodania	Wbudowane	Wbudowane
Nagrywanie sesji	Do dodania (np. CyberArk)	Natywne	Natywne
Inspekcja protokołów OT	Brak	DPI Modbus, OPC, S7	Zależne od rozwiązania
JIT access	Manualne	Wbudowane workflow	Wbudowane
Inicjacja ze strony chronionej	Trudna do wdrożenia	Standardowa funkcja	Standardowa funkcja
Skanowanie plików	Do dodania	Wbudowane	Zależne
Koszt	Niski (istniejąca infrastruktura)	Średni-wysoki (licencja + wdrożenie)	Średni-wysoki (subskrypcja)
Złożoność wdrożenia	Niska	Średnia	Średnia-wysoka
Rekomendacja	Tymczasowe, niskie SL	SL 2-3, produkcja, energetyka	SL 3-4, infrastruktura krytyczna

SL = Security Level według IEC 62443. SL 1: ochrona przed przypadkowym naruszeniem. SL 2: ochrona przed celowym atakiem z prostymi środkami. SL 3: ochrona przed zaawansowanym atakiem. SL 4: ochrona przed atakiem APT.

Checklist audytu zdalnego dostępu do OT

Poniższa lista kontrolna pozwala ocenić aktualny stan zabezpieczeń i zidentyfikować luki wymagające naprawy. Można ją wykorzystać jako punkt wyjścia do przeglądu kwartalnego lub jako zakres audytu IEC 62443. Jeśli potrzebujesz wsparcia w zaprojektowaniu architektury zdalnego dostępu do OT - skontaktuj się z nami.

Kategoria	Element	Opis	Status
Architektura	DMZ	Zdalny dostęp przechodzi przez strefę DMZ z firewallami po obu stronach
	Brak bezpośredniego dostępu	Żadne urządzenie OT nie jest bezpośrednio osiągalne z internetu
	Różne protokoły na skokach	Połączenie do DMZ i z DMZ do OT używa różnych protokołów
	Inicjacja ze strony chronionej	Połączenia inicjowane z OT do DMZ, nie odwrotnie
Uwierzytelnianie	MFA na każdym skoku	Wieloskładnikowe uwierzytelnianie na VPN, jump serwerze i stacji docelowej
	Indywidualne konta	Każdy użytkownik ma unikalne konto z przypisaną tożsamością
	JIT access	Konta serwisowe aktywne tylko na czas prac
	Akceptacja po stronie OT	Osoba po stronie chronionej zatwierdza każdą sesję
Monitoring	Logi sesji	Wszystkie sesje logowane z timestampem, użytkownikiem, źródłem
	Nagrywanie ekranu	Sesje do systemów krytycznych nagrywane
	Alerting anomalii	Alerty na nietypowe godziny, lokalizacje, działania
	Inspekcja ruchu OT	Ruch terminowany na firewallu/DPI, nie tunelowany end-to-end
Ograniczenia	SIS niedostępne zdalnie	Systemy Safety Instrumented Systems niedostępne przez remote access
	Skanowanie plików	Pliki przesyłane do OT skanowane na malware
	Limity czasowe	Sesje z auto-disconnect po timeout
	Minimalne uprawnienia	Użytkownicy mają dostęp tylko do niezbędnych systemów
Hardening	Aktualizacje urządzeń dostępowych	Jump servery, VPN, edge devices aktualne
	Procedura odcięcia	Udokumentowana procedura awaryjnego zamknięcia zdalnego dostępu
	Przegląd kwartalny	Regularna rewizja kont, uprawnień i reguł firewalla

Mapowanie zasad na IEC 62443 i NIST SP 800-82

Każda z 17 zasad mapuje się na konkretne wymagania norm. Poniższa tabela pozwala wykazać zgodność z wymaganiami regulacyjnymi.

Zasada	IEC 62443	NIST SP 800-82 Rev. 3	NIST SP 800-53
1. Brak kaskadowego ryzyka	62443-3-3 SR 5.1 (segmentacja)	Sekcja 5.1 (architektura)	SC-7 (ochrona granic)
2. Inicjacja ze strony chronionej	62443-3-3 SR 5.2 (kontrola stref)	Sekcja 5.3 (firewall)	SC-7(5) (deny by default)
3. DMZ	62443-3-3 SR 5.1	Sekcja 5.1, 5.3	SC-7(4) (DMZ)
4. Brak bezpośredniego dostępu	62443-3-3 SR 5.1, SR 5.2	Sekcja 5.3	SC-7, AC-17
5. MFA	62443-3-3 SR 1.1, SR 1.2	Sekcja 6.2 (uwierzytelnianie)	IA-2(1), IA-2(2)
6. Akceptacja po stronie OT	62443-3-3 SR 2.1	Sekcja 6.2	AC-17(1)
7. Indywidualne konta	62443-3-3 SR 1.1	Sekcja 6.2	IA-2, AC-2
8. Minimalne uprawnienia	62443-3-3 SR 2.1	Sekcja 6.2	AC-6 (least privilege)
9. Monitoring ruchu	62443-3-3 SR 6.1	Sekcja 6.4 (monitoring)	SI-4, AU-2
10. Brak tuneli end-to-end	62443-3-3 SR 5.2, SR 3.1	Sekcja 5.3	SC-7, SI-4
11. Nagrywanie sesji	62443-3-3 SR 6.1, SR 6.2	Sekcja 6.4	AU-3, AU-12
12. Zarządzanie sesjami	62443-3-3 SR 2.5	Sekcja 6.2	SC-10, AC-12
13. Ograniczenie dostępu SIS	62443-3-3 SR 5.1	Sekcja 5.5 (safety)	PE-3, AC-3
14. Kontrola plików	62443-3-3 SR 3.2	Sekcja 6.3	SI-3 (malware protection)
15. JIT access	62443-3-3 SR 2.1	Sekcja 6.2	AC-2(2) (temporary accounts)
16. Hardening	62443-3-3 SR 7.1, SR 7.2	Sekcja 6.5	CM-7, SI-2
17. Procedura odcięcia	62443-3-3 SR 6.2	Sekcja 6.6 (IR)	IR-4, IR-8

Mapowanie kontroli NIST SP 800-53

Kluczowe kontrole NIST SP 800-53 Rev. 5 dla bezpiecznego zdalnego dostępu do OT:

Kontrola	Nazwa	Znaczenie dla zdalnego dostępu
AC-17	Remote Access	Polityka zdalnego dostępu, autoryzacja, szyfrowanie, monitoring
IA-2	Identification and Authentication	Uwierzytelnianie użytkowników z MFA
SC-7	Boundary Protection	Firewall, DMZ, kontrola przepływu między strefami
SC-10	Network Disconnect	Automatyczne rozłączanie po timeout sesji
AU-2	Event Logging	Logowanie zdarzeń zdalnego dostępu
AU-12	Audit Record Generation	Nagrywanie sesji, keystroke logging
AC-6	Least Privilege	Minimalne uprawnienia dla użytkowników zdalnych
SI-4	System Monitoring	Monitoring anomalii w ruchu sieciowym
IR-4	Incident Handling	Procedury reagowania na incydenty zdalnego dostępu

Źródło: NIST SP 800-53 Rev. 5, NIST SP 800-82 Rev. 3, IEC 62443-3-3.

Architektura referencyjna

Poniższy schemat tekstowy ilustruje rekomendowaną architekturę zdalnego dostępu do sieci OT:

Internet
    |
[Firewall zewnętrzny]
    |
=== Strefa DMZ ===
    |-- VPN Gateway (MFA, terminacja tunelu)
    |-- Jump Server / SRA Portal (nagrywanie sesji, DPI)
    |-- Kiosk plików (skanowanie malware)
    |
[Firewall wewnętrzny] (połączenia inicjowane z OT)
    |
=== Sieć OT ===
    |-- Stacja inżynierska (akceptacja sesji)
    |-- HMI / SCADA
    |-- PLC / RTU
    |
=== Sieć SIS === (brak zdalnego dostępu)
    |-- Safety PLC
    |-- Emergency Shutdown

Źródła

• NIST SP 800-82 Rev. 3 “Guide to OT Security” (2023)
• IEC 62443-3-3 “System Security Requirements and Security Levels”
• NIST SP 800-53 Rev. 5 “Security and Privacy Controls”
• CISA “Configuring and Managing Remote Access for ICS” (2023)
• CISA/FBI/DOE “Primary Mitigations to Reduce Cyber Threats to OT” (maj 2025)
• CISA Alert “Poland Energy Sector Cyber Incident” (luty 2026)
• CISA Cybersecurity Performance Goals 2.0 (CPG 2.0) (grudzień 2025)
• Forescout - ICS Cybersecurity in 2026
• Dragos 2026 OT Cybersecurity Year in Review