Jeśli Twoja firma podlega NIS2, ścieżka, którą pokonuje każda sesja zdalnego pulpitu, przestaje być szczegółem technicznym i staje się elementem audytu. Większość narzędzi zdalnego dostępu kieruje ruch przez serwery pośredniczące dostawcy – poza Twoją kontrolą, często poza Unią. Własny serwer relay Remotly pozwala zostawić całą komunikację w Twojej infrastrukturze, bez dodatkowej opłaty i bez rezygnacji z jakości połączenia. W tym artykule wyjaśniamy, czego NIS2 wymaga w obszarze zdalnego dostępu i jak własny relay pomaga te wymagania spełnić.
Czym jest NIS2 i kogo dotyczy
NIS2 to dyrektywa (UE) 2022/2555 w sprawie wysokiego wspólnego poziomu cyberbezpieczeństwa w Unii. Zastąpiła pierwszą dyrektywę NIS z 2016 roku i znacząco rozszerzyła listę podmiotów objętych obowiązkami. Państwa członkowskie miały ją wdrożyć do 17 października 2024 roku; w Polsce wdraża ją nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (KSC).
Dyrektywa obejmuje 18 sektorów, podzielonych na podmioty kluczowe i ważne. Wśród nich są między innymi:
- energetyka, transport, bankowość i infrastruktura rynków finansowych,
- ochrona zdrowia, woda pitna i ścieki,
- infrastruktura cyfrowa, dostawcy usług ICT i zarządzane usługi bezpieczeństwa,
- administracja publiczna,
- produkcja (m.in. urządzeń medycznych, elektroniki, maszyn, pojazdów), przemysł chemiczny i spożywczy,
- usługi pocztowe, gospodarka odpadami, badania naukowe.
Kryterium wielkości to zwykle co najmniej 50 pracowników lub 10 mln euro rocznego obrotu, ale w niektórych sektorach obowiązki dotyczą firm niezależnie od rozmiaru. Co ważne dla dostawców IT: nawet firma spoza listy może zostać objęta wymaganiami pośrednio, jako dostawca podmiotu kluczowego, bo NIS2 wprost wymaga zarządzania bezpieczeństwem łańcucha dostaw.
Sankcje są wymierne. Dla podmiotów kluczowych kary administracyjne sięgają 10 mln euro lub 2% globalnego rocznego obrotu, dla podmiotów ważnych 7 mln euro lub 1,4%. Dyrektywa przewiduje też osobistą odpowiedzialność członków zarządu za nadzór nad wdrożeniem środków bezpieczeństwa.
Z perspektywy działu IT najważniejsze są artykuły 21 i 23. Artykuł 21 wymienia minimalne środki zarządzania ryzykiem, w tym:
- polityki bezpieczeństwa systemów i analizy ryzyka,
- obsługę incydentów,
- ciągłość działania i zarządzanie kryzysowe,
- bezpieczeństwo łańcucha dostaw, w tym relacji z dostawcami usług,
- kontrolę dostępu i zarządzanie aktywami,
- stosowanie kryptografii i szyfrowania,
- uwierzytelnianie wieloskładnikowe i bezpieczną komunikację.
Artykuł 23 nakłada obowiązek zgłaszania poważnych incydentów: wczesne ostrzeżenie w ciągu 24 godzin, pełne zgłoszenie w ciągu 72 godzin i raport końcowy w ciągu miesiąca. Żeby to zrobić, trzeba wiedzieć, kto, kiedy i skąd łączył się z systemami – a zdalny pulpit jest jednym z najczęstszych wektorów dostępu do infrastruktury.
Gdzie typowy zdalny pulpit rozmija się z NIS2
Klasyczny model działania narzędzi zdalnego dostępu wygląda tak: klient i host rejestrują się w chmurze dostawcy, a gdy bezpośrednie połączenie nie jest możliwe (NAT, firewall, sieć firmowa), cały ruch sesji przechodzi przez serwery pośredniczące dostawcy. Działa to wygodnie, ale z punktu widzenia audytora NIS2 rodzi cztery pytania, na które trudno odpowiedzieć.
Gdzie fizycznie są dane sesji? Serwery pośredniczące globalnych dostawców stoją w wielu regionach świata. Nawet jeśli ruch jest szyfrowany, metadane połączeń (kto, kiedy, z jakiego adresu, do jakiej maszyny) trafiają do infrastruktury strony trzeciej, nierzadko poza Europejskim Obszarem Gospodarczym. Dla podmiotów z sektora publicznego, zdrowia czy finansów to często problem już na etapie oceny ryzyka.
Kto jest dostawcą w łańcuchu dostaw? Artykuł 21 wymaga oceny bezpieczeństwa dostawców i ich praktyk. Jeśli dostęp do serwerów produkcyjnych zależy od chmury firmy, której umowę SLA i politykę bezpieczeństwa znasz tylko z dokumentu na stronie, audytor zapyta, jak to ryzyko oceniono i ograniczono.
Czy możesz samodzielnie odtworzyć przebieg incydentu? Zgłoszenie w ciągu 24 godzin wymaga logów połączeń, które masz pod ręką, a nie wniosku do dostawcy o eksport danych. Jeśli historia sesji żyje wyłącznie w cudzym panelu, czas reakcji rośnie.
Co się stanie, gdy chmura dostawcy przestanie działać? Ciągłość działania to obowiązek, nie opcja. Awaria lub zablokowanie konta u dostawcy zdalnego pulpitu oznacza utratę dostępu do własnej infrastruktury dokładnie wtedy, gdy jest najbardziej potrzebny.
Do tego dochodzi kwestia znana każdemu administratorowi: popularne narzędzia potrafią ograniczać przepustowość lub czas sesji w tańszych planach i blokować połączenia uznane za użytek komercyjny. Zgodność z NIS2 nie powinna zależeć od tego, czy dostawca uzna Twoje połączenie za legalne.
Jak działa własny serwer relay Remotly
Remotly zawsze próbuje najpierw połączenia bezpośredniego (P2P) między klientem a hostem. Gdy to niemożliwe, ruch potrzebuje serwera pośredniczącego. Różnica polega na tym, kto ten serwer kontroluje: zamiast publicznej chmury Connect Anywhere możesz uruchomić własny Relay Server na swojej infrastrukturze i skierować przez niego wszystkie sesje w organizacji.
Ścieżka sesji: relay dostawcy a własny relay
Górny rząd to model, który audytor musi opisać jako zależność od strony trzeciej. Dolny rząd to ten sam ruch, tyle że przez serwer, który stoi u Ciebie.
Kluczowe cechy tego rozwiązania:
- Pełna suwerenność danych. Ruch sesji nie opuszcza Twojej sieci lub Twojego prywatnego centrum danych. Ty decydujesz, w jakim kraju stoi serwer i kto ma do niego fizyczny dostęp.
- Szyfrowanie end‑to‑end niezależnie od relay. Sesje są szyfrowane między klientem a hostem (TLS 1.2/1.3, RSA‑4096, AES‑256). Serwer relay przekazuje zaszyfrowane pakiety, ale nie ma do nich dostępu – nawet własny relay nie staje się punktem podsłuchu.
- Lekka instalacja. Relay Server dostępny jest na Windows x64 oraz Linux amd64, arm64 i arm7, więc może działać na istniejącym serwerze, maszynie wirtualnej albo nawet na Raspberry Pi w serwerowni.
- Wake‑on‑LAN spoza sieci firmowej. Własny relay umożliwia zdalne wybudzanie komputerów w sieci firmowej z zewnątrz, co pozwala usypiać stacje robocze po godzinach bez utraty dostępu.
- Bez limitów jakości. W planie Ultra‑High Quality przepustowość strumienia przez własny relay jest nielimitowana, co ma znaczenie dla zespołów pracujących z wideo, grafiką 3D i CAD.
W planie Pro organizacja może uruchomić jeden serwer relay, w planach Admin, Support i Ultra‑High Quality liczba serwerów jest nieograniczona. Oznacza to, że można postawić osobny relay na każdą lokalizację lub strefę bezpieczeństwa – na przykład jeden dla sieci biurowej, drugi dla segmentu OT w zakładzie produkcyjnym.
Obowiązki NIS2 a własny relay: co konkretnie zyskujesz
Własny serwer relay nie zapewnia zgodności z NIS2 sam z siebie – zgodność to polityki, procesy i ludzie. Ale usuwa kilka pytań, które przy chmurowym pośredniku są najtrudniejsze do obrony przed audytorem.
Dla audytora liczy się możliwość pokazania dowodów. Z własnym relay odpowiedź na pytanie „którędy idzie ruch zdalnego dostępu i kto go kontroluje” brzmi po prostu: przez nasz serwer, w naszym centrum danych, z naszymi logami.
Wdrożenie w jedno popołudnie
Uruchomienie własnego relay nie wymaga projektu wdrożeniowego. Typowa ścieżka wygląda tak:
- Zarejestruj konto firmowe w Remotly – każdy plan biznesowy ma 30‑dniowy okres próbny bez karty.
- Pobierz Relay Server dla Windows lub Linux i uruchom go na serwerze w sieci firmowej lub w prywatnej chmurze. Instrukcje konfiguracji znajdziesz w sekcji Download.
- W panelu administracyjnym przypisz organizacji własny relay i, jeśli używasz Microsoft 365, połącz logowanie z Entra ID.
- Wdróż agenta QuickHost na stacjach roboczych i serwerach – ręcznie, przez cichą instalację lub masowo przez Microsoft Intune.
- Włącz historię sesji i nagrywanie tam, gdzie wymaga tego Twoja polityka bezpieczeństwa.
Koszt po stronie licencji zaczyna się od planu Pro (29 zł za użytkownika miesięcznie, jeden relay) i rośnie do planu Admin (140 zł za użytkownika, nielimitowane relaye, pełne uprawnienia administracyjne, integracja z AD). Sam serwer relay jest częścią planu, nie dodatkową opłatą. Pełne zestawienie planów znajdziesz w cenniku. Ceny są netto i mogą się zmienić – aktualne wartości zawsze sprawdzaj na stronie.
Remotly rozwija Mirillis Core Sp. z o.o., polska firma znana z programu Action!. Umowę, fakturę VAT i wsparcie techniczne dostajesz od podmiotu z Unii Europejskiej, co upraszcza ocenę dostawcy w ramach łańcucha dostaw.
Lista kontrolna dla IT przed audytem zdalnego dostępu
Zanim audytor zapyta, sprawdź sam:
- ☐ Wiesz, przez jakie serwery przechodzi ruch zdalnego pulpitu i w jakim kraju stoją.
- ☐ Masz pisemną ocenę ryzyka dostawcy narzędzia zdalnego dostępu.
- ☐ Dostęp zdalny jest powiązany z tożsamością firmową (Entra ID / AD), a nie z prywatnymi kontami pracowników.
- ☐ Potrafisz w ciągu godziny wygenerować listę sesji zdalnych do konkretnego serwera z ostatnich 30 dni.
- ☐ Masz plan dostępu do infrastruktury na wypadek awarii chmury dostawcy.
- ☐ Dostęp bezobsługowy jest chroniony (wygaszanie ekranu, blokada klawiatury i myszy, autoryzacja urządzeń).
- ☐ Konta byłych pracowników i wykonawców są odbierane centralnie, z panelu, a nie przez „odinstalowanie programu”.
Jeśli przy którymś punkcie zawahałeś się, to dobry moment, żeby przetestować własny relay. Zarejestruj konto firmowe i uruchom 30‑dniowy okres próbny, albo napisz do nas – pomożemy dobrać plan i konfigurację pod Twoją strukturę sieci.
Zastrzeżenie i źródła
Artykuł ma charakter informacyjny i nie stanowi porady prawnej. Zakres obowiązków Twojej organizacji zależy od sektora, wielkości i krajowych przepisów wdrażających dyrektywę – skonsultuj go z prawnikiem lub audytorem. Stan przepisów i cen: październik 2026.