Jak 5G zmienia podejście do szyfrowania danych w ruchu i w spoczynku

Gdy „stare” szyfrowanie spotyka prywatną sieć 5G

Operator zakładowej sieci przemysłowej włącza pilotaż prywatnej sieci 5G w fabryce – roboty AGV, czujniki, tablety serwisantów, wszystko śmiga po nowym radiu. Po tygodniu okazuje się jednak, że stare polityki szyfrowania z czasów Wi‑Fi i VPN‑ów nie nadążają: opóźnienia w sterowaniu rosną, logi bezpieczeństwa puchną, a część urządzeń IoT zwyczajnie nie radzi sobie z narzuconymi protokołami.

W jednym miejscu łączą się dwa światy: dawny, dość statyczny model „kilka centralnych systemów + VPN do biura”, oraz architektura 5G, gdzie funkcje sieciowe, przetwarzanie danych i punkty dostępu są rozproszone po całym kampusie, w chmurze i na brzegu sieci. To, co kiedyś dało się „załatwić” dwoma tunelami IPsec i szyfrowaniem dysków w serwerowni, nagle rozlewa się na dziesiątki mikro‑lokalizacji i setki tysięcy strumieni danych.

Główny problem nie polega na tym, że szyfrowanie danych w ruchu i w spoczynku stało się mniej potrzebne. Wręcz przeciwnie – jest bardziej krytyczne. Zmieniło się natomiast to, że proste podejście „zaszyfrujmy wszystko tak samo, wszędzie” zaczyna boleć: obciąża urządzenia, zwiększa opóźnienia i komplikuje zarządzanie kluczami. Szyfrowanie przestaje być pojedynczą decyzją, a staje się zestawem precyzyjnych wyborów dopasowanych do konkretnych scenariuszy 5G.

Nowe podejście polega na warstwowym projektowaniu ochrony: osobno myśli się o bezpieczeństwie warstwy radiowej 5G, o segmentacji i szyfrowaniu w 5G core, o szyfrowaniu end‑to‑end w aplikacjach oraz o ochronie danych w spoczynku w wielu rozproszonych lokalizacjach – od chmury operatora, przez edge computing, aż po pojedynczy czujnik na linii produkcyjnej.

Co w 5G tak naprawdę się zmienia z perspektywy bezpieczeństwa

Różnice między 4G a 5G, które wpływają na szyfrowanie

4G zostało zaprojektowane głównie z myślą o smartfonach i mobilnym internecie. 5G od początku celuje w przemysł, pojazdy, miasta, systemy krytyczne. Z tej zmiany wynikają bardzo konkretne konsekwencje dla szyfrowania danych w ruchu i w spoczynku.

Najważniejsze różnice to:

• gęstość urządzeń – w 5G liczba podłączonych elementów (massive IoT) rośnie o rzędy wielkości, co wpływa na skalę zarządzania kluczami i certyfikatami;
• prędkości i przepustowości – szyfrowanie musi radzić sobie z wielkimi strumieniami danych (np. wideo 4K z wielu kamer) bez wąskich gardeł po stronie CPU;
• opóźnienia – scenariusze URLLC (ultra‑reliable low latency communications) wymagają, by czas „stracony” na szyfrowanie i uwierzytelnianie był ułamkiem milisekundy;
• różnorodność zastosowań – od wideokonferencji, przez telemetrykę, po sterowanie robotami i zdalną chirurgię, każde z innymi wymaganiami bezpieczeństwa.

Do tego dochodzi zjawisko prywatnych sieci 5G (kampusowe, przemysłowe, uczelniane), które przestają być domeną tylko wielkich operatorów. W takich środowiskach decyzje o politykach szyfrowania często podejmują działy IT/OT organizacji, a nie tylko dostawca usług telekomunikacyjnych – i to właśnie tam błędy architektoniczne bolą najbardziej.

Nowe klocki układanki 5G: core, slicing, edge, chmura

Architektura 5G jest znacznie bardziej modularna i chmurowa niż w 4G. Z punktu widzenia szyfrowania danych pojawiają się nowe elementy i koncepcje:

• 5G core (5GC) – rdzeń sieci zbudowany z funkcji sieciowych (NF), często jako mikroserwisy w kontenerach. Komunikują się one po IP, zwykle za pomocą protokołów typu HTTP/2 i gRPC, co wymusza szerokie użycie TLS między funkcjami.
• Network slicing – logiczne „plasterki” sieci, wydzielone dla różnych zastosowań (np. IoT, krytyczne sterowanie, biuro). Każdy slice może mieć inne wymagania dot. szyfrowania, integralności i retencji danych.
• Edge computing / MEC – przetwarzanie i przechowywanie danych blisko użytkownika, często w wielu małych „mini‑data‑center” na brzegu sieci. Tam trafia część danych w spoczynku, które wcześniej kończyły w jednym centralnym DC.
• Wirtualizacja funkcji sieciowych (NFV) i chmura natywna – funkcje, które kiedyś działały na dedykowanym sprzęcie, teraz uruchamiają się na wspólnej infrastrukturze chmurowej. Szyfrowanie staje się obowiązkowe nie tylko na zewnątrz, ale także pomiędzy komponentami wewnątrz „wnętrza” sieci.

Każdy z tych elementów dodaje nowe punkty styku i nowe miejsca, w których dane mogą być w ruchu lub w spoczynku. To bezpośrednio zwiększa powierzchnię, jaką trzeba objąć kontrolą szyfrowania.

Więcej punktów przechowywania i krótsze ścieżki danych

Tradycyjnie dane miały dość przewidywalną drogę: urządzenie – stacja bazowa – core – data center. W 5G dane mogą być zatrzymywane, przetwarzane i przechowywane w wielu punktach pośrednich: w lokalnym edge, w cache operatora, w dedykowanym slice, w chmurze publicznej, czy nawet w gatewayu IoT w zakładzie.

To oznacza, że szyfrowanie danych w spoczynku nie może ograniczać się do jednego centralnego magazynu. Konieczne staje się projektowanie spójnych polityk szyfrowania obejmujących:

• centralne magazyny danych (hurtownie, bazy operacyjne),
• lokalne repozytoria na brzegu (cache, bazy w edge),
• pamięci urządzeń końcowych (telefony, sterowniki PLC, czujniki),
• urządzenia pośrednie (bramy IoT, koncentratory danych).

Mini‑wniosek z tego zestawienia jest prosty: szyfrowanie przestaje być dodatkową warstwą na brzegu sieci, a staje się „tkanką łączną” pomiędzy każdym odcinkiem trasy danych w 5G.

Podstawy: szyfrowanie danych w ruchu i w spoczynku w realiach 5G

Dane w ruchu w 5G – od radia po aplikację

W 5G dane w ruchu mogą być chronione na kilku poziomach jednocześnie. Dobrze jest mieć w głowie prosty model warstwowy:

• warstwa radiowa – szyfrowanie i integralność między urządzeniem (UE) a stacją bazową (gNB), realizowane przez mechanizmy 3GPP (algorytmy jak 128‑NEA, 128‑NIA itp.);
• warstwa sygnalizacji i transportu w sieci operatora – ochrona kanałów NAS, RRC, interfejsów wewnątrz 5G core, zwykle IPsec, TLS, MACsec;
• warstwa IP/transportowa między sieciami – tunele IPsec, VPN‑y korporacyjne, zabezpieczone łącza między data center, edge i chmurami;
• warstwa aplikacyjna – TLS 1.2/1.3, QUIC, DTLS, a także szyfrowanie end‑to‑end na poziomie aplikacji (np. komunikatory, systemy IoT z własnym szyfrowanym payloadem).

To, że warstwa radiowa w 5G oferuje wbudowane szyfrowanie, nie eliminuje potrzeby stosowania szyfrowania wyżej. Wręcz przeciwnie – dane powinny być traktowane jak podróżujące przez wiele stref zaufania, a każda z nich wymaga własnych mechanizmów ochrony, zależnych od ryzyka i wymagań opóźnień.

Dane w spoczynku: gdzie fizycznie lądują informacje w 5G

W architekturze 5G dane w spoczynku znajdują się nie tylko w klasycznych bazach danych. Typowe miejsca przechowywania to:

• magazyny w 5G core – np. bazy z profilami abonentów, logi sygnalizacyjne, metadane sesji;
• pamięć w edge/MEC – dane telemetryczne, tymczasowe bufory wideo, dane analityczne używane lokalnie;
• chmury (prywatne/publiczne) – systemy OSS/BSS, analityka big data, aplikacje wykorzystujące 5G jako medium transmisyjne;
• urządzenia końcowe – smartfony, tablety, sterowniki, sensory, które przechowują klucze, konfiguracje, wyniki pomiarów;
• urządzenia pośrednie – gatewaye IoT, controllery Wi‑Fi z integracją 5G, urządzenia agregujące dane z wielu czujników.

W każdym z tych punktów dane mogą wymagać innego poziomu szyfrowania w spoczynku: od pełnego szyfrowania nośnika (FDE – Full Disk Encryption), przez szyfrowanie na poziomie bazy danych lub tabel, aż po szyfrowanie pojedynczych pól (np. dane osobowe).

„Ruch” i „spoczynek” przenikają się w 5G

W tradycyjnych systemach różnica między danymi w ruchu a w spoczynku była dość klarowna. W 5G, zwłaszcza przy edge computingu i masowym IoT, granica zaczyna być rozmyta. Dane często:

• są buforowane na bardzo krótko w pamięci lokalnej (co dla atakującego i tak może być interesujące),
• zmieniają lokalizację przechowywania dynamicznie w zależności od obciążenia i topologii sieci,
• są kopiowane między instancjami mikroserwisów, które powstają i znikają na żądanie.

To prowadzi do wniosku, że polityki szyfrowania nie mogą opierać się tylko na klasycznym podziale „w tranzycie” vs „w spoczynku”. Trzeba opisywać wymagania także według typu danych oraz ich cyklu życia: inne zasady dla danych tymczasowych i logów, inne dla danych użytkownika, jeszcze inne dla danych sterujących w systemach przemysłowych.

Różne klasy danych, różne strategie szyfrowania

Dla porządku przydatny jest prosty podział, który często stosuje się przy projektowaniu bezpieczeństwa w sieciach 5G:

• dane użytkownika (payload) – treść połączeń, pliki, wideo, dane aplikacji;
• dane sterujące i sygnalizacyjne – sygnalizacja NAS, RRC, wiadomości sterujące urządzeniami;
• dane telemetryczne i logi – metryki, logi z urządzeń i usług, dane analityczne;
• dane referencyjne i konfiguracyjne – klucze kryptograficzne, konfiguracje, definicje slice.

Każda z tych kategorii będzie inaczej traktowana przy wyborze mechanizmów szyfrowania w ruchu i w spoczynku. Przykładowo: dane sterujące w URLLC mogą wymagać lekkiego, szybkiego szyfrowania i minimalnej liczby pośredników, natomiast dane analityczne mogą być silniej szyfrowane w spoczynku, ale akceptują większe opóźnienia przy dostępie.

Jak 5G wzmacnia i rozszerza szyfrowanie w warstwie radiowej i sygnalizacji

Bezpieczeństwo warstwy radiowej 5G – co daje 3GPP

Standardy 3GPP dla 5G wprowadzają szereg usprawnień w porównaniu z LTE w zakresie uwierzytelniania, szyfrowania i integralności. Najważniejsze elementy to:

• ulepszone uwierzytelnianie UE – procedury AKA (Authentication and Key Agreement) zostały wzmocnione, a zarządzanie kluczami odbywa się bardziej granularnie dla różnych usług i slice;
• szyfrowanie i integralność sygnalizacji – kanały NAS (Non‑Access Stratum) i RRC (Radio Resource Control) są chronione zarówno pod kątem poufności, jak i spójności danych, co utrudnia manipulacje sygnalizacją;
• nowe algorytmy bezpieczeństwa – zestaw algorytmów NEA (Encryption Algorithm) i NIA (Integrity Algorithm) jest bardziej elastyczny, z możliwością wyboru zależnie od profilu bezpieczeństwa;
• lepsze zarządzanie kluczami – wywodzenie kluczy z głównego materiału (K_AMF, K_gNB itp.) jest lepiej odseparowane dla różnych połączeń i scenariuszy.

To wszystko sprawia, że sama warstwa radiowa w 5G jest trudniejsza do podsłuchania i manipulowania niż w poprzednich generacjach, co stanowi solidny fundament dla dalszych warstw szyfrowania danych w ruchu.

SUCI: ochrona tożsamości abonenta przed IMSI catcherami

W LTE dużym problemem były ataki z wykorzystaniem fałszywych stacji bazowych (IMSI catcher), które przechwytywały identyfikatory abonentów. 5G odpowiada na to mechanizmem SUCI (Subscription Concealed Identifier).

SUCI to zaszyfrowany identyfikator abonenta, wyliczany w urządzeniu przy użyciu klucza publicznego operatora. W efekcie:

• rzeczywisty identyfikator (SUPI) nie jest transmitowany w formie jawnej w warstwie radiowej,
• atakujący nie może łatwo identyfikować i śledzić abonenta tylko na podstawie ruchu sieciowego,
• znacznie utrudnia się budowę pasywnych baz śledzenia użytkowników.

Integracja szyfrowania z network slicingiem

Na warsztacie stoi linia produkcyjna, obok niej niewielka szafa z urządzeniami sieciowymi. Jeden operator, jedna fizyczna infrastruktura, ale trzy różne slice: dla robotów, kamer i biura. Ten sam kabel światłowodowy, a zupełnie inne wymagania szyfrowania i opóźnień – i tu właśnie zaczyna się prawdziwe wyzwanie 5G.

Network slicing wymusza myślenie o szyfrowaniu nie tylko „per sieć”, ale „per slice”. Każdy wycinek może mieć własną politykę bezpieczeństwa, a więc również inny profil kryptograficzny:

• slice przemysłowy (URLLC) – minimalne opóźnienia, wąsko zdefiniowane urządzenia, proste i szybkie algorytmy z restrykcyjnym zarządzaniem kluczami;
• slice multimedialny (eMBB) – wysoki wolumen danych, akceptowalne opóźnienia, mocniejsze szyfrowanie na poziomie aplikacyjnym i magazynów;
• slice IoT masowy (mMTC) – setki tysięcy czujników, niska moc obliczeniowa urządzeń, lekkie protokoły z centralnym zarządzaniem kluczami.

Praktycznie oznacza to konieczność zintegrowania systemów zarządzania bezpieczeństwem z orkiestracją slice (np. NFV/SDN). Tworzenie nowego slice nie powinno sprowadzać się tylko do przydzielenia pasma i priorytetów QoS, ale również do zdefiniowania:

• jakie protokoły szyfrowania w ruchu są obowiązkowe wewnątrz i na brzegu slice,
• w których punktach przechowywania danych w spoczynku szyfrowanie jest wymagane i jakiego rodzaju,
• jak wyglądają cykle rotacji kluczy i separacja materiału kryptograficznego między slice.

Mini‑wniosek: slice bez własnego „profilu kryptograficznego” jest tylko logicznym VLAN‑em o podwyższonym ryzyku. Prawdziwa izolacja przychodzi dopiero wtedy, gdy logika sieciowa idzie w parze z odseparowanym szyfrowaniem i kluczami.

Ochrona sygnalizacji wewnątrz 5G core i między domenami

Operator uruchamia nową funkcję sieciową w chmurze publicznej, a część sygnalizacji N2/N3 zaczyna płynąć przez łącza dzierżawione między data center. Schemat na diagramie wygląda dobrze, ale pojawia się pytanie: które kanały sygnalizacyjne są faktycznie zaszyfrowane, a które wciąż jadą „po zaufanej szynie”, która zaufana jest tylko na papierze?

W 5G core kluczowe interfejsy (N2, N3, N4, N8, N10 i inne) mogą być realizowane jako połączenia IP między funkcjami VNFs/CNFs ulokowanymi w różnych strefach, a nawet u różnych dostawców chmury. Szyfrowanie sygnalizacji wymaga więc konsekwentnego stosowania:

• TLS między funkcjami control plane (np. AMF, SMF, UDM, PCF),
• IPsec lub MACsec na odcinkach między data center i strefami bezpieczeństwa,
• segmentacji sieciowej takiej, by ruch sygnalizacyjny był izolowany od ruchu użytkownika, nawet jeśli współdzielą fizyczny transport.

Sygnalizacja w 5G zawiera nie tylko parametry techniczne, ale także dane o lokalizacji, profilach abonentów czy konfiguracjach slice. Jeżeli takie informacje „wyciekną” z warstwy control plane, napastnik zyskuje mapę sieci dużo bardziej użyteczną niż sam odszyfrowany payload użytkownika. Dlatego w praktyce często stosuje się zasadę, że sygnalizacja core jest zawsze traktowana jak dane wrażliwe i szyfrowana niezależnie od fizycznego medium.

Rozszerzona powierzchnia zarządzania kluczami

W tradycyjnej sieci mobilnej KMS operatora żył sobie spokojnie w centralnym data center. W 5G nagle klucze muszą „dotrzeć” do chmur, edge, prywatnych sieci kampusowych i milionów urządzeń, przy jednoczesnym zachowaniu separacji między usługami i slice.

Zarządzanie kluczami staje się jednym z krytycznych punktów architektury szyfrowania. Kluczowe elementy to:

• hierarchia kluczy – oddzielenie kluczy abonentów, kluczy infrastruktury sieciowej, kluczy dla slice i kluczy aplikacyjnych (np. dla konkretnych usług IoT);
• rozproszone HSM – sprzętowe moduły bezpieczeństwa nie tylko w core, ale również w wybranych węzłach edge i chmurze, aby uniknąć przesyłania „gołego” materiału kryptograficznego przez pół świata;
• automatyzacja rotacji i odwoływania kluczy – integracja KMS z orkiestracją 5G, tak aby zamknięcie slice lub usługi automatycznie odcinało również powiązane z nimi klucze.

Warstwa zarządzania kluczami jest tu równie ważna jak same algorytmy. Nawet najlepsze szyfrowanie AES‑256 nie pomoże, jeśli ten sam klucz jest używany latami w kilku slice i aplikacjach, a jego kopie leżą w starych backupach bez pełnego szyfrowania.

Szyfrowanie danych w ruchu w 5G: od sieci operatora po aplikację

Kaskadowe szyfrowanie – kiedy pomaga, a kiedy przeszkadza

Administrator korporacyjny konfiguruje VPN site‑to‑site między zakładem a chmurą. Operator dostarcza prywatny APN z szyfrowaniem w sieci rdzeniowej, a samo urządzenie IoT komunikuje się z chmurą po HTTPS. Na papierze wygląda to imponująco: trzy warstwy szyfrowania. W realnym monitoringu opóźnień pojawiają się jednak skoki, a debugowanie problemów staje się koszmarem.

Kaskadowe szyfrowanie (równoczesne szyfrowanie tych samych danych w kilku warstwach) jest w 5G częste. Typowy łańcuch może wyglądać tak:

1. szyfrowanie radiowe między UE a gNB,
2. szyfrowany tunel w sieci operatora (np. GTP‑U w IPsec),
3. VPN korporacyjny (IPsec/SSL VPN),
4. TLS/QUIC na poziomie aplikacji.

Nie zawsze jest to złe – poszczególne warstwy mogą być zarządzane przez różne podmioty (operator, integrator, dział IT klienta, zespół aplikacyjny) i zapewniać ochronę w odmiennych strefach zaufania. Problem zaczyna się wtedy, gdy:

• każda warstwa używa własnego, kosztownego kryptograficznie zestawu parametrów,
• brak jest jasnej odpowiedzialności za którykolwiek poziom,
• diagnozowanie problemów wydajności lub incydentów wymaga „przebijania się” przez kolejne zaszyfrowane warstwy.

Przy projektowaniu łańcucha transmisji w 5G praktycznym podejściem jest określenie minimalnej liczby niezależnych stref zaufania i przypisanie do nich warstw szyfrowania. Tam, gdzie operator i klient są tą samą organizacją (np. prywatne 5G kampusowe), można uprościć stos: oprzeć się na mocnym szyfrowaniu radiowym i aplikacyjnym, a zrezygnować z niektórych pośrednich tuneli.

End‑to‑end między urządzeniem a chmurą – rola szyfrowania aplikacyjnego

Deweloper systemu telemetrycznego dostaje od operatora gwarancję: „Ruch z czujników będzie chroniony w sieci 5G”. Mimo to decyduje się na dodatkowe szyfrowanie payloadu w aplikacji. Dzięki temu nawet osoba z dostępem administracyjnym do infrastruktury operatora widzi tylko zaszyfrowane paczki.

Szyfrowanie end‑to‑end na poziomie aplikacji jest jednym z najskuteczniejszych sposobów na ograniczenie zaufania do pośredników, których w 5G jest po prostu więcej. Typowe rozwiązania to:

• szyfrowanie wiadomości MQTT/CoAP z użyciem lekkich algorytmów na urządzeniu i pełnego odszyfrowania dopiero w backendzie,
• szyfrowanie pól w protokołach REST/gRPC, nawet jeśli cała sesja jest objęta TLS,
• stosowanie bibliotek, w których klucze aplikacyjne nie są znane systemowi operacyjnemu urządzenia, tylko np. bezpiecznemu elementowi (Secure Element, TEE).

Warstwa aplikacyjna pozwala też różnicować poziomy szyfrowania w zależności od typu danych. Ten sam kanał TLS może nieść zarówno dane krytyczne (np. parametry sterowania), jak i nieszkodliwe metadane. Zaszyfrowanie wyłącznie wrażliwych fragmentów payloadu równocześnie podnosi bezpieczeństwo i redukuje narzut kryptograficzny.

Szyfrowanie ruchu w prywatnych i hybrydowych sieciach 5G

W zakładzie produkcyjnym dział IT wdraża prywatną sieć 5G, ale jednocześnie część aplikacji działa w chmurze operatora. Część ruchu nigdy nie opuszcza kampusu, inna część przechodzi przez publiczną infrastrukturę mobilną. W obu przypadkach te same roboty i sensory muszą mieć spójny model szyfrowania.

Prywatne 5G (non‑public networks, NPN) zmienia logikę: organizacja staje się jednocześnie klientem i częściowo operatorem. To wymusza świadome decyzje, gdzie kończy się domena zaufania lokalnej sieci, a gdzie zaczyna „świat zewnętrzny”. Konsekwencje dla szyfrowania danych w ruchu są następujące:

• wewnątrz kampusu często stosuje się uproszczony model – mocne szyfrowanie radiowe + segmentacja sieciowa + TLS w kluczowych aplikacjach,
• na styku z chmurą lub siecią publiczną dochodzą tunele IPsec/SSL z dodatkowymi wymaganiami rotacji kluczy,
• ruch między prywatnymi a publicznymi slice może wymagać translacji polityk bezpieczeństwa (np. inny zestaw algorytmów, inne czasy życia kluczy).

Jeśli prywatne 5G jest projektowane jako część większej architektury Zero Trust, szyfrowanie ruchu staje się domyślne nie tylko między UE a siecią, ale także między mikrosegmentami w samej sieci kampusowej. Granice „wewnątrz/zewnątrz” przestają być wtedy geograficzne – są wyznaczane przez polityki kryptograficzne i tożsamości.

URLLC i mMTC – szyfrowanie a rygory opóźnień i wydajności

Operator wdraża usługę zdalnego sterowania pojazdami w kopalni. Każda dodatkowa milisekunda opóźnienia to wyższe ryzyko operacyjne. Jednocześnie regulator oczekuje szyfrowania danych sterujących i rejestrowania ruchu dla potrzeb audytu.

W usługach URLLC i mMTC kompromis między stopniem „obudowania” ruchu szyfrowaniem a wymaganiami wydajnościowymi jest szczególnie widoczny. Kilka praktycznych zasad, które często się sprawdzają:

• maksymalne wykorzystanie wbudowanych mechanizmów warstwy radiowej 5G i minimalizacja dodatkowych tuneli na krytycznym odcinku (UE <–> edge),
• offload części operacji kryptograficznych do sprzętu (karty sieciowe z akceleracją IPsec/TLS, HSM w edge),
• podział ruchu na strumienie: krytyczny sterujący (lekko „opakowany”, minimalne opóźnienia) i mniej krytyczny monitoring/analityka (mocniej szyfrowany, może przechodzić przez centralne DC).

W masowym IoT ograniczeniem jest za to moc obliczeniowa i energia. Małe sensory nie uciągną złożonych protokołów kryptograficznych. W praktyce często stosuje się model, w którym urządzenie realizuje tylko podstawowe szyfrowanie (np. lekkie TLS/DTLS, OSCORE), a pełne „dociążenie” kryptograficzne (np. dodatkowe szyfrowanie pól, podpisy) odbywa się dopiero w bramie lub w edge.

Widoczność i inspekcja ruchu przy pełnym szyfrowaniu

Zespół SOC próbuje analizować anomalie w sieci 5G dla klienta przemysłowego. Niestety, większość ruchu aplikacyjnego jest zaszyfrowana od końca do końca. Standardowe sondy DPI widzą jedynie nagłówki i statystyki przepływów, ale nie mają dostępu do zawartości.

Pełne szyfrowanie ruchu komplikuje monitorowanie bezpieczeństwa. W 5G można z tym pracować na kilka sposobów:

• korzystanie z metadanych ruchu (czas, wielkość, kierunki, wzorce połączeń) jako głównego źródła detekcji anomalii,
• wdrażanie sond i proxy w punktach, gdzie ruch jest odszyfrowany „z natury” (np. granica aplikacji w edge lub chmurze),
• wykorzystanie mechanizmów typu TLS visibility/termination w ściśle kontrolowanych domenach – ale tylko tam, gdzie jest to zgodne z wymaganiami poufności (często nie do przyjęcia przy prawdziwym E2E).

Coraz ważniejsza staje się też korelacja logów z warstw aplikacyjnych i infrastrukturalnych. Skoro nie można „zajrzeć” do środka pakietu, trzeba łączyć: logi z funkcji sieciowych 5G, dane z load balancerów, logi aplikacji oraz informacje z KMS, który rejestruje operacje na kluczach. Szyfrowanie nie może być ślepe – musi iść w parze z dobrze zaprojektowaną obserwowalnością.

Projektowanie polityk szyfrowania w 5G w oparciu o cykl życia danych

Architekt bezpieczeństwa siada z zespołem biznesowym i rysuje prostą tabelę: skąd dane pochodzą, dokąd trafiają, jak długo żyją i kto ich dotyka. Dopiero na tej podstawie powstaje plan szyfrowania – nie odwrotnie.

W realiach 5G najlepsze efekty daje podejście, w którym polityki szyfrowania w ruchu i w spoczynku są powiązane z cyklem życia danych, a nie tylko z techniczną warstwą sieci. Propracowniczy sposób myślenia to m.in.:

• klasyfikacja danych według wrażliwości i czasu przydatności,

Łączenie szyfrowania w ruchu i w spoczynku jednym modelem kluczy

Podczas audytu kampusowej sieci 5G wychodzi na jaw, że ruch z robotów jest szyfrowany czterema różnymi zestawami kluczy, a dane archiwalne – jeszcze dwoma innymi. Każdy zespół wdrażał „swoje” szyfrowanie, nikt nie patrzył na całość. Gdy dochodzi do incydentu, nikt nie potrafi odpowiedzieć, które klucze trzeba unieważnić, by zatrzymać potencjalny wyciek.

5G przyspiesza rotację danych i kluczy. Strumienie telemetryczne są agregowane na edge, potem kompresowane, filtrowane, częściowo anonimizowane i wysyłane dalej do chmury. Jeśli szyfrowanie w ruchu i w spoczynku opiera się na zupełnie innych domenach kluczy, łatwo zgubić ciągłość kontroli. Praktyczniejsze jest podejście, w którym cykl życia klucza jest powiązany z cyklem życia danych – od punktu powstania aż po usunięcie archiwum.

Spójny model może wyglądać tak:

• klucz tożsamościowy przypisany do urządzenia lub aplikacji (długoterminowy, chroniony w Secure Element/KMS),
• krótkotrwałe klucze sesyjne negocjowane z wykorzystaniem klucza tożsamościowego (szyfrowanie w ruchu, rotacja minutowa lub godzinowa),
• klucze magazynowania danych powiązane z klasą danych i horyzontem retencji (szyfrowanie w spoczynku, rotacja dzienna/tygodniowa, możliwość selektywnego niszczenia).

W takim modelu korelacja „który klucz chroni które dane” nie jest efektem ręcznego śledzenia arkuszy, ale wynika z projektu KMS i metadanych. Gdy trzeba unieważnić dane z konkretnego okresu lub z konkretnej linii produkcyjnej, można to zrobić przez kontrolowane wycofanie odpowiednich kluczy, bez wstrzymywania całej infrastruktury 5G.

Im bardziej spójny model kluczy, tym łatwiej połączyć szyfrowanie w ruchu i w spoczynku w jedną, zrozumiałą politykę – zamiast zestawu niezależnych, nieprzejrzystych „zamków”.

Szyfrowanie danych w spoczynku w ekosystemie 5G – od UE po archiwa w chmurze

Operator uruchamia analitykę wideo z kamer 5G w logistyce. Strumień wideo jest szyfrowany aż do edge, tam częściowo przetwarzany, a wybrane fragmenty trafiają do długoterminowego archiwum w chmurze. Z punktu widzenia prywatności i zgodności regulacyjnej, kluczowe jest nie tylko to, jak chroniony jest strumień, lecz także jak zabezpieczone są zrzuty klatek, metadane i modele uczenia maszynowego szkolone na tych danych.

Szyfrowanie w spoczynku w świecie 5G rozciąga się na kilka warstw przechowywania:

• pamięć lokalna urządzenia (UE, gateway, router kampusowy),
• pamięć masowa i cache na edge (serwery MEC, lokalne klastry),
• centralne systemy IT operatora i klienta (bazy, hurtownie danych, obiekty w chmurze),
• długoterminowe archiwa i backupy (często w innych regionach, a nawet u innych dostawców).

Kluczowe pytania, które zwykle padają przy projektowaniu szyfrowania w spoczynku w 5G, dotyczą granic kontroli: gdzie kończy się odpowiedzialność operatora, a gdzie zaczyna klienta? Czy dane w cache na edge są szyfrowane kluczami klienta, czy operatora? Kto technicznie może wykonać snapshot dysku i co musi zrobić, by go odszyfrować?

Praktyczny kompromis często sprowadza się do zasady: im bliżej źródła danych i im wyżej ich wrażliwość, tym większa presja, by klucz był w domenie klienta. Oznacza to m.in.:

• lokalne szyfrowanie krytycznych logów i konfiguracji w urządzeniu UE (także po stronie SIM/eSIM i pamięci aplikacyjnej),
• szyfrowanie danych tymczasowych na edge kluczami zarządzanymi przez klienta (np. KMS federowany z chmurą korporacyjną),
• wykorzystanie mechanizmów „customer-managed keys” i „hold your own key” w chmurach operatora do ochrony magazynów długoterminowych.

Ochrona w spoczynku musi być zsynchronizowana z logiką archiwizacji i anonimizacji. W 5G źródła danych generują ogromne wolumeny, więc nie da się polegać wyłącznie na „szyfrowaniu wszystkiego jednym kluczem”. Segmentacja na klasy danych, regiony, a nawet konkretne linie produktowe znacząco ułatwia późniejsze zarządzanie retencją i prawa do bycia zapomnianym.

Granularne szyfrowanie na poziomie pól i rekordów

W systemie obsługującym inteligentne liczniki energii część danych jest potrzebna działowi rozliczeń, część zespołom analitycznym, a najmniejszy fragment – tylko zespołowi bezpieczeństwa. Trzymanie wszystkiego w jednym, jednolicie zaszyfrowanym zbiorze ogranicza elastyczność, a zbyt swobodny dostęp otwiera drzwi do nadużyć.

5G sprzyja granularnemu szyfrowaniu – nie tylko całych plików czy wolumenów, lecz także pojedynczych pól lub rekordów, zgodnie z zasadą minimalnego ujawniania. Dzięki temu:

• dane identyfikujące użytkownika mogą być zaszyfrowane innym kluczem niż dane operacyjne,
• konkretne kolumny w bazie (np. PESEL, numer konta, współrzędne GPS) mogą być odsłaniane tylko wybranym mikroserwisom,
• część danych w strumieniu może być dostępna w postaci niezaszyfrowanej na potrzeby lokalnego sterowania, a część pozostaje zaszyfrowana end‑to‑end aż do centralnego backendu.

W praktyce wykorzystuje się różne techniki:

• szyfrowanie na poziomie kolumn / pól w bazach danych (np. z użyciem kluczy sprzężonych z tożsamością aplikacji korzystającej),
• szyfrowanie selektywne w protokołach wiadomości (np. tylko fragment JSON/CBOR zawierający dane wrażliwe),
• szyfrowanie oparte na atrybutach (ABE) w scenariuszach, gdzie dostęp zależy od roli, projektu, lokalizacji lub typu urządzenia.

Granularność ma swoją cenę: rośnie złożoność zarządzania kluczami i uprawnieniami. Z drugiej strony pozwala lepiej dopasować zabezpieczenia do ryzyka, bez „betonowania” całego ekosystemu jednym, zbyt ciężkim mechanizmem szyfrowania.

Tożsamość urządzeń i użytkowników jako punkt startowy dla szyfrowania

Administrator zakładu przemysłowego dostaje zgłoszenie: „Robot ramię‑3 wykonuje nieautoryzowane ruchy”. Po analizie okazuje się, że ktoś podmienił konfigurację na jednym z kontrolerów, podszywając się pod zaufane urządzenie. Szyfrowanie samego ruchu nie zadziałało, bo sieć przyjęła fałszywą tożsamość jako legalną.

W 5G szyfrowanie jest nierozerwalnie związane z tożsamością – zarówno urządzenia (UE), jak i użytkownika czy aplikacji. Bez silnego uwierzytelniania i autoryzacji, szyfrowane kanały chronią głównie przed podsłuchem, ale już nie przed podszywaniem się.

Elementy, które spina się w całość:

• tożsamość sieciowa UE (SUPI/SUCI, profil w UDM/UDR),
• certyfikaty TLS/mTLS przypisane do urządzeń i usług (często zarządzane przez wewnętrzne PKI),
• tożsamości aplikacyjne (np. OAuth2/OIDC, SPIFFE, tokeny JWT podpisywane przez centralny IdP),
• atrybuty kontekstowe: lokalizacja, typ sieci (publiczna / prywatna / slice), poziom zaufania środowiska wykonawczego.

Praktyczny model wygląda tak, że każde istotne połączenie w 5G ma dwa poziomy kontroli: warstwę sieciową (autoryzacja UE do korzystania z danej usługi/slice) oraz warstwę aplikacyjną (autoryzacja usługi do korzystania z danych). Szyfrowanie w ruchu i w spoczynku jest osadzone w tym podwójnym modelu tożsamości.

Tożsamość wpływa też na wybór algorytmów i siłę szyfrowania. Urządzenia z ograniczoną mocą obliczeniową mogą uzyskiwać inne profile kryptograficzne niż potężne serwery w edge. Kluczem jest, by te różnice były świadomym elementem polityki, a nie efektem przypadkowych decyzji podczas wdrożeń.

Automatyzacja zarządzania kluczami i certyfikatami w gęstym środowisku 5G

W kampusowej sieci 5G działa kilkanaście tysięcy urządzeń: sensory, AGV, kamery, panele operatorskie. Certyfikaty TLS dla bram i usług są ważne 90 dni, klucze sesyjne rotują co kilka minut. Ręczne śledzenie tego wszystkiego w arkuszach jest nierealne – a każde opóźnienie w odnowieniu certyfikatu zatrzymuje produkcję.

W 5G automatyzacja zarządzania kluczami przestaje być „miłym dodatkiem”, a staje się warunkiem funkcjonowania sieci. Dotyczy to zarówno certyfikatów dla usług, jak i kluczy aplikacyjnych czy kluczy szyfrujących dane w spoczynku.

Najczęściej stosowane praktyki:

• centralny KMS z API, obsługujący generowanie, rotację i unieważnianie kluczy dla różnych domen (edge, chmura, on‑prem),
• automatyczne odnawianie certyfikatów mTLS z użyciem protokołów typu ACME lub dedykowanych agentów w klastrach Kubernetes / platformach edge,
• policy‑driven KM – polityki w kodzie (np. GitOps dla polityk KMS), które definiują, jakie algorytmy, długości kluczy i czasy życia są dopuszczalne w danej klasie systemów,
• ścisłe logowanie wszystkich operacji na kluczach (audit trail) i korelacja ich z logami sieci 5G oraz aplikacji.

Automatyzacja nie zwalnia z myślenia – wręcz przeciwnie, wymusza precyzyjne zdefiniowanie zasad. Gdy uda się je ułożyć, skala 5G przestaje być wrogiem szyfrowania, a staje się powodem, by robić je w sposób powtarzalny i kontrolowany.

Edge computing w 5G jako „półka pośrednia” dla szyfrowania

Deweloper aplikacji AR dla serwisu maszyn przenosi część logiki do edge, żeby zejść z opóźnieniem. Nagle okazuje się, że krytyczne dane, które wcześniej trafiały wyłącznie do centralnego DC, teraz bywają przetwarzane i cache’owane w kilkunastu rozproszonych lokalizacjach. Każda z nich staje się nowym miejscem, w którym trzeba dobrze ułożyć szyfrowanie w ruchu i w spoczynku.

Edge w ekosystemie 5G pełni podwójną rolę: jest punktem terminacji części szyfrowanych kanałów i jednocześnie miejscem, w którym dane na chwilę „siadają” w spoczynku. To rodzi kilka typowych wyzwań:

• gdzie kończy się szyfrowanie end‑to‑end (np. UE ↔ edge), a gdzie zaczyna się „nowa” sesja z edge do chmury,
• jak zabezpieczyć dane tymczasowe na dyskach i w pamięci edge (szczególnie przy awarii, snapshotach, migracjach VM/kontenerów),
• jak pogodzić różne domeny zaufania: operatora, klienta i dostawcy aplikacji działających na tym samym węźle.

Praktyczny punkt ciężkości często przesuwa się w stronę silnego, aplikacyjnego szyfrowania danych już po stronie UE lub najbliższej bramy. Edge staje się wtedy „przekaźnikiem z możliwością optymalizacji”, który widzi tylko tyle, ile jest niezbędne do działania usługi. Dane składowane lokalnie są zabezpieczone kluczami, które – w idealnym scenariuszu – pozostają pod kontrolą właściciela danych, a nie operatora infrastruktury edge.

Im bardziej rozproszony edge, tym ważniejsze staje się powiązanie jego polityk szyfrowania z centralnym KMS i systemem zarządzania tożsamością. Bez tego łatwo wpaść w pułapkę wielu „małych wysp” z własnymi, ręcznie obsługiwanymi kluczami, które po kilku latach nikt już dobrze nie rozumie.

Szyfrowanie a zgodność regulacyjna w świecie transgranicznego 5G

Globalny producent sprzętu medycznego wdraża rozwiązanie oparte na 5G jednocześnie w kilku krajach. Ten sam typ urządzenia wysyła dane telemetryczne do różnych regionów chmurowych, podlegających innym przepisom o ochronie danych. Architekt bezpieczeństwa nagle odkrywa, że „jednolite” szyfrowanie musi uwzględniać różne wymagania prawne co do lokalizacji kluczy i danych.

5G naturalnie przekracza granice państw – zarówno na poziomie roamingu, jak i usług chmurowych. Szyfrowanie danych w ruchu i w spoczynku staje się więc narzędziem nie tylko technicznym, ale też regulacyjnym. Kluczowe zagadnienia to:

• gdzie fizycznie przechowywane są klucze szyfrujące dane (region, jurysdykcja),
• czy operator lub dostawca chmury może jednostronnie uzyskać dostęp do kluczy,
• jak wygląda przepływ danych zaszyfrowanych między regionami i kto w którym miejscu może je odszyfrować,
• jak uwzględnić wymogi lokalnych regulatorów dotyczące długości kluczy, dopuszczalnych algorytmów i okresów przechowywania.

W praktyce często stosuje się modele, w których:

• klucze do najbardziej wrażliwych danych (np. zdrowotnych, finansowych) są generowane i przechowywane wyłącznie w infrastrukturze kontrolowanej przez klienta,
• dostawcy 5G i chmur oferują mechanizmy „bring your own key” lub „hold your own key”, umożliwiające użycie zewnętrznych HSM/KMS,

Najczęściej zadawane pytania (FAQ)

Na czym polega różnica w szyfrowaniu danych między 4G a 5G?

W 4G większość ruchu pochodziła ze smartfonów i stosunkowo prostego modelu: kilka centralnych systemów, kilka tuneli VPN i szyfrowanie w jednym data center. W 5G dane krążą między setkami tysięcy urządzeń, wieloma slice’ami sieci, edge computingiem i chmurą, więc „jeden schemat szyfrowania dla wszystkich” przestaje działać.

W praktyce oznacza to większy nacisk na warstwowe szyfrowanie (radio, core, transport, aplikacja) i na zarządzanie kluczami w skali massive IoT. Im bardziej krytyczna aplikacja (np. sterowanie robotem), tym precyzyjniej trzeba dobrać algorytmy i miejsce, w którym dochodzi do szyfrowania i deszyfrowania.

Dlaczego stare polityki VPN i Wi‑Fi nie sprawdzają się w prywatnych sieciach 5G?

Gdy ktoś próbuje przenieść „kopiuj–wklej” politykę z czasów Wi‑Fi i klasycznego VPN do prywatnej sieci 5G, szybko widzi skutki: rosnące opóźnienia w sterowaniu, przeciążone logi i IoT, które dławi się zbyt ciężkimi protokołami. To, co działało przy kilkuset tunelach VPN, nie skaluje się do setek tysięcy krótkich połączeń 5G.

W 5G trzeba projektować szyfrowanie bliżej aplikacji i scenariusza: inaczej dla ruchu biurowego, inaczej dla krytycznego sterowania, jeszcze inaczej dla transmisji wideo. Często oznacza to lżejsze mechanizmy dla małych urządzeń, a jednocześnie mocniejsze szyfrowanie wyżej w stosie (np. TLS między usługami w core i w chmurze).

Jakie warstwy szyfrowania danych w ruchu są typowe dla sieci 5G?

Najprościej wyobrazić to sobie jak kilka „pięter” ochrony. Pierwsze to warstwa radiowa między urządzeniem a stacją bazową, gdzie 3GPP zapewnia wbudowane szyfrowanie i integralność. Wyżej pojawia się ochrona sygnalizacji i transportu w sieci operatora (NAS, RRC, interfejsy core), często z użyciem IPsec, TLS czy MACsec.

Kolejne piętro to szyfrowanie na poziomie IP między sieciami – klasyczne tunele IPsec między data center, edge i chmurami. Na samym wierzchu leży warstwa aplikacyjna: TLS 1.2/1.3, QUIC, czasem własne szyfrowanie w protokołach IoT. Wniosek jest prosty: szyfrowanie radia nie zwalnia z używania TLS w aplikacji czy IPsec między lokalizacjami.

Co oznacza szyfrowanie danych w spoczynku w architekturze 5G?

W 5G dane nie „leżą” już tylko w jednej hurtowni w centrali. Fragmenty trafiają do magazynów core (profile abonentów, logi), do edge/MEC (telemetria, bufor wideo), do chmur publicznych i prywatnych, a nawet do pamięci małych czujników i bram IoT w fabryce. Każde takie miejsce to potencjalny punkt ataku.

Szyfrowanie w spoczynku obejmuje więc pełne szyfrowanie nośników (FDE), szyfrowanie na poziomie baz danych lub konkretnych tabel oraz szyfrowanie wybranych pól, np. danych osobowych. Kluczowe jest to, by polityki były spójne – ten sam typ danych (np. logi z linii produkcyjnej) powinien być chroniony w podobny sposób w core, na edge i w chmurze.

Jak network slicing wpływa na wymagania dotyczące szyfrowania w 5G?

Gdy operator lub firma wydziela osobny slice dla IoT, inny dla krytycznego sterowania, a jeszcze inny dla ruchu biurowego, każdy z nich może (i powinien) mieć własne zasady szyfrowania. Slice od robotów AGV będzie wymagał minimalnych opóźnień, więc szyfrowanie musi być lekkie i dobrze zoptymalizowane, natomiast slice biurowy może stosować „cięższe” algorytmy bez szkody dla użytkownika.

Praktyczny efekt jest taki, że politykę szyfrowania warto planować razem z projektem slicing’u: jakie algorytmy i długości kluczy, gdzie kończy się tunel, gdzie przechowywane są klucze i jak długo trzymane są zaszyfrowane logi. Inaczej skończy się na jednym, kompromisowym profilu, który nikogo w pełni nie chroni i wszystkim przeszkadza.

Jak 5G zmienia podejście do zarządzania kluczami i certyfikatami?

Przy kilkuset użytkownikach VPN dało się ręcznie „ogarnąć” certyfikaty i klucze. W środowisku massive IoT, z tysiącami czujników i setkami usług w 5G core i na edge, ręczne podejście zamienia się w chaos. Klucze rotują częściej, są rozmieszczone w wielu lokalizacjach, a część urządzeń ma bardzo ograniczone zasoby sprzętowe.

Dlatego w 5G rośnie rola zautomatyzowanych systemów zarządzania kluczami (KMS), integracji z PKI oraz lekkich mechanizmów uwierzytelniania dla małych urządzeń. Mini‑wniosek: bez automatyzacji (np. automatyczne odnawianie certyfikatów TLS między funkcjami core) szyfrowanie szybko staje się wąskim gardłem, a nie pomocą.

Czy w prywatnej sieci 5G trzeba nadal używać VPN i TLS w aplikacjach?

Wiele osób zakłada, że skoro prywatna sieć 5G jest „zamknięta”, to wystarczy szyfrowanie na warstwie radiowej. Tymczasem dane często wychodzą poza kampus: do chmury operatora, publicznej chmury aplikacyjnej lub do zdalnego centrum serwisowego. Po drodze mijają różne strefy zaufania, więc brak dodatkowego szyfrowania jest ryzykowny.

VPN i TLS nadal mają swoje miejsce, ale używa się ich rozsądniej: VPN raczej między lokalizacjami lub segmentami sieci niż „wszędzie dla każdego”, a TLS konsekwentnie w usługach aplikacyjnych i API. Dobrą praktyką jest założenie, że każde połączenie wychodzące poza konkretny slice lub kampus powinno być chronione dodatkową warstwą szyfrowania end‑to‑end.

Co warto zapamiętać

• Wprowadzenie prywatnej sieci 5G obnaża ograniczenia „starych” polityk szyfrowania z czasów Wi‑Fi i VPN – jednolite tunelowanie wszystkiego generuje opóźnienia, przeciąża słabsze urządzenia IoT i pompuje zbędne logi.
• 5G drastycznie zwiększa skalę i złożoność szyfrowania: rosnąca gęstość urządzeń, skrajnie niskie wymagane opóźnienia i różnorodność zastosowań wymuszają bardziej precyzyjne, scenariuszowe podejście do ochrony danych.
• Architektura 5G (core oparty na mikroserwisach, network slicing, edge computing, chmura) tworzy dziesiątki nowych punktów styku, w których dane są w ruchu i w spoczynku – każdy z nich musi być objęty spójną polityką szyfrowania.
• Network slicing oznacza koniec jednej, „uniwersalnej” polityki bezpieczeństwa: różne plastry sieci (np. sterowanie krytyczne vs. biuro) wymagają innych poziomów szyfrowania, integralności i retencji danych.
• Rozproszone przetwarzanie (edge, cache operatora, lokalne gatewaye IoT) sprawia, że szyfrowanie danych w spoczynku nie może być ograniczone do centralnego data center – ochrona musi objąć także mini‑magazyny i pamięci urządzeń końcowych.
• Szyfrowanie w 5G przestaje być jednorazową decyzją „włącz/wyłącz” i staje się warstwowo projektowaną „tkanką łączną” między radiem, 5G core, aplikacją i magazynami danych, z różnymi technikami dopasowanymi do wymagań opóźnień i mocy obliczeniowej.

Źródła informacji

• 3GPP TS 33.501: Security architecture and procedures for 5G system. 3rd Generation Partnership Project (3GPP) (2024) – Specyfikacja bezpieczeństwa 5G, algorytmy szyfrowania i integralności
• 3GPP TS 23.501: System architecture for the 5G System (5GS). 3rd Generation Partnership Project (3GPP) (2024) – Architektura 5G core, funkcje sieciowe, punkty ochrony danych
• Security Considerations for 5G Networks. European Union Agency for Cybersecurity (ENISA) (2020) – Analiza ryzyk i dobrych praktyk bezpieczeństwa w sieciach 5G
• NIST SP 800-207: Zero Trust Architecture. National Institute of Standards and Technology (2020) – Model warstwowej ochrony i segmentacji, przydatny dla 5G i edge