Checklista bezpieczeństwa przed uruchomieniem prywatnej sieci 5G

Automatyzacja hali magazynowej, wdrożenie autonomicznych wózków AGV lub budowa nowoczesnego systemu monitoringu wideo w fabryce często kończą się tą samą decyzją: sieć Wi-Fi nie radzi sobie z opóźnieniami i zagęszczeniem urządzeń, a publiczna sieć komórkowa nie gwarantuje odpowiedniego pasma. Wybór pada na prywatne 5G (P5G). Jednak po zainstalowaniu masztów radiowych, podłączeniu serwerów rdzenia (Core) i włożeniu kart SIM do pierwszych maszyn pojawia się zderzenie z rzeczywistością. Brak odpowiednich zabezpieczeń na styku technologii telekomunikacyjnych (Telco) i klasycznego IT potrafi otworzyć furtkę dla intruzów bezpośrednio do serca infrastruktury przemysłowej.

Wdrożenie prywatnej sieci bezprzewodowej piątej generacji diametralnie różni się od konfiguracji firmowego routera. Łączy w sobie wirtualizację, architekturę chmurową, specyficzne protokoły radiowe oraz fizyczne nośniki tożsamości. Aby instalacja nie stała się najsłabszym ogniwem w firmie, wdrożenie musi przejść przez rygorystyczną weryfikację bezpieczeństwa przed podłączeniem krytycznych systemów produkcyjnych.

Złudne poczucie bezpieczeństwa w prywatnych sieciach komórkowych

Wielu inżynierów zakłada, że standard 5G sam w sobie rozwiązuje wszystkie problemy z bezpieczeństwem cyfrowym. Standard 3GPP wprowadził zaawansowane szyfrowanie transmisji radiowej i ukrywanie identyfikatorów urządzeń (SUPI/SUCI), jednak prywatna sieć to nie tylko fale radiowe. To rozbudowane środowisko serwerowe, w którym błędy konfiguracji mają identyczne skutki jak w tradycyjnej sieci LAN.

Różnica między bezpieczeństwem standardu a bezpieczeństwem implementacji

Standard telekomunikacyjny definiuje, jak protokoły powinny działać, ale nie narzuca sposobu zabezpieczenia serwera, na którym uruchomiono oprogramowanie rdzenia. Jeżeli rdzeń sieci 5G (5GC – 5G Core) działa w kontenerach Docker na niespatchowanym systemie Linux, silne algorytmy szyfrowania radiowego nie obronią infrastruktury przed atakiem z zewnątrz. Zagrożenia nie wynikają z samej technologii 5G, lecz z błędów integracyjnych, słabego zarządzania kluczami kryptograficznymi i braku izolacji poszczególnych warstw systemu.

Dlaczego podejście do Wi-Fi nie sprawdza się w 5G?

W klasycznym Wi-Fi punktem centralnym jest punkt dostępowy powiązany z kontrolerem i serwerem RADIUS. W prywatnym 5G architektura jest zdecentralizowana i oparta na usługach (SBA – Service-Based Architecture). Moduły funkcyjne rdzenia, takie jak AMF (zarządzanie dostępem i mobilnością) czy UPF (przekazywanie pakietów danych użytkownika), komunikują się za pomocą zapytań HTTP/2 i interfejsów REST API. Z punktu widzenia administratora bezpieczeństwa 5G Core przypomina bardziej aplikację mikroserwisową niż klasyczny sprzęt sieciowy. Oznacza to, że podatności znane z webaplikacji automatycznie stają się zagrożeniami dla sieci radiowej.

Bezpieczeństwo warstwy radiowej (RAN) i urządzeń końcowych

Warstwa radiowa (Radio Access Network) to pierwsza linia styku z urządzeniami. Składa się ze stacji bazowych (gNodeB) oraz terminali użytkownika (UE – User Equipment), którymi mogą być roboty przemysłowe, czujniki IoT czy tablety operatorów. Błędy na tym poziomie umożliwiają podsłuch, wstrzykiwanie danych lub odcięcie maszyn od sterowania.

Zarządzanie tożsamością: SIM, eSIM i provisionowanie

Karta SIM/eSIM jest sprzętowym magazynem kluczy kryptograficznych (klucz K i kod operatora OPc). Fizyczne i cyfrowe zarządzanie tymi kartami decyduje o integralności sieci:

• Unikanie domyślnych kluczy dostawców: Wielu dostawców gotowych zestawów P5G dostarcza testowe karty SIM ze znanymi, powtarzalnymi kluczami K i OPc. Przed uruchomieniem produkcyjnym należy wygenerować unikalny zestaw kluczy dla własnej organizacji.
• Ochrona bazy UDM/HSS: Baza danych przechowująca klucze kryptograficzne musi być bezwzględnie odcięta od internetu. Wyciek bazy danych subskrybentów pozwala na pełne klonowanie kart SIM i odszyfrowanie ruchu wstecznego, jeśli nie wdrożono mechanizmu Forward Secrecy.
• Procedura wycofania zgubionego urządzenia: Czas reakcji na kradzież terminala lub czujnika musi być zminimalizowany. Zablokowanie numeru IMSI/SUPI w module UDM powinno odbywać się natychmiastowo poprzez skrypt lub interfejs API, bez konieczności restartu usług rdzenia.

Konfiguracja stacji bazowej gNodeB i ochrona interfejsów

Stacje bazowe często montowane są w miejscach dostępnych fizycznie – na słupach, ścianach magazynów lub zewnętrznych masztach. Fizyczny dostęp do portu ethernetowego anteny gNodeB nie może dawać bezpośredniego wejścia do sieci sterującej.

Interfejs F1 (łączący jednostkę centralną CU z jednostką rozproszoną DU) oraz interfejs N2/N3 (łączące gNodeB z rdzeniem 5G) muszą być chronione protokołem IPsec. Wykorzystanie nieszyfrowanych łączy wewnątrz sieci zakładowej to częsty błąd projektowy, wynikający z chęci obniżenia narzutu na procesor stacji bazowej. W środowiskach przemysłowych kompromitacja przełącznika pośredniczącego pozwala wtedy na podsłuchanie całego strumienia danych użytkownika przesyłanego przez protokół GTP-U (GPRS Tunnelling Protocol User Plane).

Zabezpieczenie przed fałszywymi stacjami bazowymi (Rogue Base Stations)

W sieciach 5G Standalone (SA) wprowadzono mechanizm SUCI (Subscription Concealed Identifier). Chroni on stały identyfikator IMSI/SUPI przed przechwyceniem w powietrzu poprzez asynchroniczne szyfrowanie kluczem publicznym operatora sieci prywatnej przed wysłaniem żądania do stacji bazowej.

Podczas weryfikacji przedstartowej należy upewnić się, że w konfiguracji sieci wyłączono tryb awaryjny typu „null-scheme” (brak szyfrowania identyfikatora) oraz wymuszono stosowanie algorytmów Profile A (X25519) lub Profile B (ECDSA). Niewłaściwa konfiguracja spowoduje, że terminale będą nadawać swój unikalny identyfikator jawnym tekstem, ułatwiając profilowanie i śledzenie urządzeń na terenie zakładu.

Architektura i utwardzanie rdzenia sieci 5G (5GC)

Rdzeń sieci 5G w architekturze autonomicznej (Standalone) to środowisko w pełni programowalne, oparte na mikroserwisach. Za procesy uwierzytelniania, trasowania, naliczania opłat i zarządzania sesjami odpowiadają niezależne funkcje sieciowe (NF – Network Functions). Zabezpieczenie rdzenia wymaga traktowania go jak aplikacji chmurowej o wysokim stopniu krytyczności.

Separacja płaszczyzny sterowania i danych (CUPS)

Architektura 5G rozdziela płaszczyznę sterowania (Control Plane – moduły AMF, SMF, UDM) od płaszczyzny danych (User Plane – UPF). UPF odpowiada za przetwarzanie ruchu z najwyższą przepustowością i najniższym opóźnieniem.

Kluczowe działanie polega na umieszczeniu modułu UPF jak najbliżej urządzeń (Edge/On-Premise), podczas gdy funkcje sterujące mogą znajdować się w centralnym punkcie sieci lub w bezpiecznej chmurze prywatnej. Moduł UPF nie może mieć bezpośredniego dostępu do baz danych użytkowników ani interfejsów konfiguracyjnych innych funkcji sieciowych. Do transmisji danych z płaszczyzną sterowania służy wyłącznie dedykowany, ściśle filtrowany interfejs N4 bazujący na protokole PFCP (Packet Forwarding Control Protocol).

Bezpieczeństwo komunikacji wewnątrzrdzeniowej (Service-Based Architecture)

Wewnątrz rdzenia mikroserwisy komunikują się ze sobą za pośrednictwem zapytań API. Brak kontroli nad tą komunikacją pozwala intruzowi, który przejął jedną mniej istotną funkcję, na swobodne manipulowanie całą siecią:

1. Wdrożenie mTLS (Mutual TLS): Każda funkcja sieciowa (np. SMF rozmawiający z AMF) musi uwierzytelniać się za pomocą certyfikatu x.509. Certyfikaty powinny być wystawiane przez wewnętrzne, dedykowane centrum certyfikacji (Internal CA), a nie publiczne urzędy certyfikacyjne.
2. Bariera NRF (Network Repository Function): NRF działa jako rejestr usług. Nowo uruchomiona funkcja sieciowa rejestruje się w NRF, aby inne moduły mogły ją odnaleźć. Dostęp do NRF musi wymagać autoryzacji z wykorzystaniem tokenów OAuth 2.0. Bez tego złośliwy kontener wpięty do sieci może zarejestrować się jako fałszywy moduł SMF i przechwytywać sesje użytkowników.
3. Wyłączenie nieużywanych interfejsów API: Komercyjne pakiety rdzeni P5G często mają domyślnie włączone interfejsy testowe lub telemetryczne, które nie są potrzebne na produkcji. Wszystkie zbędne endpointy muszą zostać zablokowane na poziomie ingress controllera lub zapory sieciowej.

Segmentacja i ochrona plastrów sieci (Network Slicing)

Plastrowanie sieci (Network Slicing) to jedna z najważniejszych zalet 5G, pozwalająca na uruchomienie wielu logicznie odseparowanych sieci na jednej fizycznej infrastrukturze. W fabryce jeden plaster może obsługiwać krytyczne systemy sterowania maszyn (wymagające minimalnych opóźnień), drugi monitoring wideo wysokiej rozdzielczości, a trzeci sieć biurową gości. Błędna segmentacja prowadzi do przenikania ataków między środowiskami o różnym poziomie zaufania.

Izolacja logiczna a izolacja zasobów

Samo przypisanie urządzeń do innego identyfikatora plastra (S-NSSAI) nie gwarantuje pełnego bezpieczeństwa. Jeżeli dwa plastry współdzielą tę samą instancję UPF oraz ten sam interfejs sieciowy, atak typu Denial of Service (DoS) na plaster gościnny może wysycić pasmo i zablokować ruch w plastrze przemysłowym.

Dla plastrów o znaczeniu krytycznym (Mission-Critical) należy stosować twardą izolację (Hard Slicing). Oznacza to przypisanie dedykowanych instancji UPF, przypisanie stałych zasobów procesora i pamięci RAM na serwerach wirtualizacji oraz wydzielenie osobnych interfejsów fizycznych w przełącznikach sieciowych (SR-IOV, osobne porty 10/25GbE).

Kontrola dostępu między plastrami

Ruch pomiędzy urządzeniami działającymi w różnych plastrach sieciowych nie może być routowany bezpośrednio wewnątrz rdzenia 5G. Wszelka komunikacja międzyplastrowa musi wychodzić przez interfejs N6 do zewnętrznej zapory sieciowej nowej generacji (NGFW), gdzie pakiety są poddawane inspekcji stanowej, filtrowaniu reguł aplikacyjnych oraz skanowaniu pod kątem anomalii.

Zabezpieczenie platformy wirtualizacji i infrastruktury brzegowej (Edge/MEC)

Większość współczesnych instalacji prywatnego 5G działa jako oprogramowanie zwirtualizowane – na maszynach wirtualnych (KVM, VMware) lub w klastrach kontenerów (Kubernetes, OpenShift). Bezpieczeństwo telekomunikacji staje się zależne od bezpieczeństwa platformy hostingowej.

Utwardzanie środowiska Kubernetes dla funkcji sieciowych (CNF)

Wdrożenie kontenerowych funkcji sieciowych (Cloud-native Network Functions) wymaga specyficznych uprawnień jądra systemu operacyjnego (np. do obsługi DPDK i bezpośred

niego dostępu do kart sieciowych). Otwiera to jednak wektory ataku na poziomie systemu operacyjnego hosta, jeśli wdrożenie nie zostanie właściwie ograniczone:

• Ograniczenie kontenerów uprzywilejowanych: Moduły takie jak UPF często wymagają flagi privileged do bezpośredniego zarządzania ruchem sieciowym. Należy odizolować te kontenery w dedykowanych węzłach roboczych (Node Isolation) za pomocą mechanizmów Taints and Tolerations oraz ograniczyć uprawnienia jądra przy użyciu profili AppArmor lub SELinux.
• Skanowanie obrazów kontenerowych i SBOM: Oprogramowanie dostarczane przez vendorów telekomunikacyjnych musi przejść weryfikację pod kątem znanych podatności (CVE) oraz posiadać kompletną listę komponentów (Software Bill of Materials – SBOM). Wdrożenie zautomatyzowanego skanowania w rejestrze obrazów zapobiega uruchomieniu podatnych wersji bibliotek w rdzeniu.
• Separacja sieci węzłów zarządzających: Interfejsy zarządzające klastrem (Kube-apiserver, etcd) muszą być całkowicie odseparowane od interfejsów transmisyjnych 5G (N2, N3, N6) za pomocą dedykowanych sieci fizycznych lub osobnych interfejsów logicznych z restrykcyjnymi polisami NetworkPolicy.

Punkt styku N6: Integracja prywatnego 5G z siecią przemysłową (OT/IT)

Poważnym zagrożeniem operacyjnym podczas uruchamiania sieci P5G jest potraktowanie jej jako „przezroczystej warstwy transmisyjnej” i bezpośrednie spięcie interfejsu N6 z zakładową siecią automatyki (OT). Brak odpowiedniej strefy buforowej (DMZ) naraża sterowniki PLC, systemy SCADA i roboty przemysłowe na niekontrolowany ruch sieciowy.

Przyczyną problemów w tym obszarze jest zderzenie dwóch różnych filozofii bezpieczeństwa: telekomunikacyjnej (skupionej na ciągłości i tożsamości abonenta) oraz przemysłowej (skupionej na determinizmie i integralności poleceń sterujących).

Prawidłowe zabezpieczenie styku N6 wymaga wdrożenia wielowarstwowej kontroli:

• Firewall przemysłowy z inspekcją DPI (Deep Packet Inspection): Zapora sieciowa na styku N6 i strefy OT musi weryfikować nie tylko adresy IP i porty, ale również komendy wewnątrz protokołów przemysłowych (np. Modbus TCP, PROFINET, EtherCAT, OPC UA), blokując nieautoryzowane polecenia zapisu do sterowników.
• Ukrywanie topologii adresowej (Source NAT / Reverse Proxy): Urządzenia końcowe podłączone przez 5G nie powinny bezpośrednio rozgłaszać swoich wewnętrznych adresów IP w podsieciach OT. Zastosowanie translacji adresów oraz kontrolowanych bram proxy ogranicza możliwość skanowania sieci przez zainfekowane terminale.
• Integracja z systemem SIEM/SOC: Logi z interfejsu N6, modułów AMF/SMF oraz zdarzenia z firewalla muszą być korelowane w czasie rzeczywistym. Nagła zmiana wolumenu ruchu lub nietypowa próba inicjalizacji sesji PDU przez terminal musi wywoływać automatyczną reakcję (np. kwarantannę urządzenia w module UDM).

Pułapki i błędy konfiguracyjne: Czego bezwzględnie unikać

Praktyka wdrożeniowa pokazuje, że najczęstsze kompromitacje prywatnych sieci 5G nie wynikają ze skomplikowanych ataków kryptograficznych na protokół radiowy, lecz z zaniedbań na poziomie konfiguracji i procesów:

• Pozostawienie domyślnych haseł i certyfikatów demonstracyjnych: Instalatory systemów 5G typu „All-in-One” często generują domyślne klucze dla interfejsów SBI oraz kont administratorów w panelach webowych. Uruchomienie sieci z fabrycznymi danymi uwierzytelniającymi niweczy wszelkie zabezpieczenia kryptograficzne warstwy radiowej.
• Brak izolacji ruchu diagnostycznego i telemetrii dostawcy: Wielu dostawców oprogramowania P5G konfiguruje domyślne tunele zwrotne do swoich chmur w celach telemetrycznych lub serwisowych. Pozostawienie niesprawdzonych połączeń wychodzących bez kontroli na brzegu sieci stanowi bezpośrednie naruszenie polityki bezpieczeństwa i potencjalny wektor ataku na łańcuch dostaw (Supply Chain Attack).
• Nieweryfikowanie zgodności z modelem zerowego zaufania (Zero Trust): Błędem jest zakładanie, że urządzenie uwierzytelnione na poziomie karty SIM jest w pełni bezpieczne. Karta SIM potwierdza jedynie tożsamość modemu, a nie stan systemu operacyjnego urządzenia końcowego. Każdy terminal musi podlegać inspekcji na poziomie wyższych warstw (warstwy aplikacji i tożsamości użytkownika).
• Pominięcie testów odporności na zagłuszanie (Jamming): Brak procedury awaryjnej (Failover) w przypadku celowego lub przypadkowego zagłuszenia pasma radiowego może doprowadzić do paraliżu procesów logistycznych. Systemy krytyczne muszą posiadać zdefiniowany scenariusz bezpiecznego zatrzymania (Safe Stop) w razie utraty łączności radiowej.

Praktyczna checklista przedstartowa (Gate Go/No-Go)

Przed podjęciem decyzji o skierowaniu ruchu produkcyjnego do prywatnej sieci 5G należy przeprowadzić formalną weryfikację każdego z poniższych punktów kontrolnych:

1. Warstwa tożsamości i RAN:
   • [ ] Unikalne klucze K i OPc wygenerowane we własnym zakresie i bezpiecznie wgrane na karty SIM/eSIM.
   • [ ] Wyłączony tryb null-scheme dla identyfikatora SUCI; wdrożone szyfrowanie tożsamości algorytmem Profile A lub B.
   • [ ] Wymuszone szyfrowanie i integralność płaszczyzny danych (User Plane Encryption) na poziomie gNodeB (algorytmy NEA2/NIA2 lub silniejsze).
   • [ ] Tunele IPsec zestawione i aktywne na wszystkich interfejsach pomiędzy gNodeB a rdzeniem (N2/N3).
2. Rdzeń 5G (5GC) i komunikacja SBI:
   • [ ] Wymuszone uwierzytelnianie wzajemne (mTLS) dla wszystkich wywołań API między funkcjami sieciowymi (SBI).
   • [ ] Włączona autoryzacja tokenami OAuth 2.0 dla rejestracji i zapytań w module NRF.
   • [ ] Wyłączone zbędne porty, protokoły testowe oraz interfejsy debugujące na poziomie kontenerów i kontrolerów ingress.
   • [ ] Interfejs N4 (PFCP) zabezpieczony regułami firewalla i dostępny wyłącznie pomiędzy autoryzowanymi węzłami SMF i UPF.
3. Segmentacja i brzeg sieci (MEC/N6):
   • [ ] Wydzielone dedykowane instancje UPF (Hard Slicing) dla plastrów sieciowych o znaczeniu krytycznym.
   • [ ] Zapora sieciowa NGFW z aktywną inspekcją protokołów przemysłowych wdrożona na styku interfejsu N6 z siecią OT/IT.
   • [ ] Brak bezpośredniego routingu między plastrami wewnątrz rdzenia sieci.
   • [ ] Profile SELinux/AppArmor oraz restrykcyjne NetworkPolicy aktywne w klastrze Kubernetes hostingującym funkcje CNF.
4. Procedury operacyjne i monitoring:
   • [ ] Zdefiniowany i przetestowany proces natychmiastowego blokowania skradzionych kart SIM/urządzeń w module UDM.
   • [ ] Logi audytowe z rdzenia 5G i zdarzenia bezpieczeństwa zintegrowane z centralnym systemem SIEM.
   • [ ] Zweryfikowana procedura bezpiecznego zatrzymania urządzeń autonomicznych (AGV/AMR) w razie zakłóceń radiowych.

Rekomendacja wykonawcza przed wdrożeniem

Bezpieczeństwo prywatnej sieci 5G nie kończy się na etapie odbioru instalacji. W przeciwieństwie do tradycyjnych sieci Wi-Fi, P5G łączy telekomunikacyjny stos protokołów z chmurowym środowiskiem mikrousług i automatyką przemysłową. Z tego względu ostateczna autoryzacja startu produkcyjnego powinna nastąpić wyłącznie po przeprowadzeniu kontrolowanego testu penetracyjnego weryfikującego całą ścieżkę – od fizycznego urządzenia końcowego, przez stację bazową i interfejsy SBI rdzenia, aż po zaporę ogniową chroniącą sieć OT.

W fazie eksploatacji kluczowe jest utrzymanie dyscypliny w zakresie aktualizacji obrazów kontenerowych rdzenia oraz cykliczny audyt konfiguracji parametrów radiowych pod kątem nieautoryzowanych zmian w rejestrach subskrybentów.