Rdzeń 5G jako mikroserwisy: SBA, mTLS, OAuth 2.0 i NRF pod lupą

Rdzeń 5G (5G Core) w architekturze SBA to zestaw funkcji sieciowych, które udostępniają sobie usługi przez REST-owe API na HTTP/2 z danymi w JSON. Funkcje rejestrują się i odnajdują przez NRF, autoryzują wywołania tokenami OAuth 2.0 wydawanymi przez NRF i chronią transport wzajemnie uwierzytelnionym TLS. Dla zespołów DevOps oznacza to, że bezpieczeństwo rdzenia 5G opiera się na tych samych filarach co bezpieczeństwo platformy mikroserwisowej: tożsamości usług, PKI, segmentacji sieci i obserwowalności.

Ten artykuł jest częścią serii o bezpieczeństwie 5G. Ogólny obraz sieci, interfejsy N1 do N9 i procedury rejestracji opisuje przewodnik po architekturze sieci 5G. Tutaj skupiamy się na płaszczyźnie sterowania rdzenia: jak działa interfejs SBI, jaką rolę pełni NRF, co dokładnie zawiera token OAuth 2.0, jak rozumieć wymagania TLS z TS 33.501 i jak przełożyć to wszystko na konfigurację klastra Kubernetes, monitoring i proces wydawniczy.

Najważniejsze w skrócie

• SBI to HTTP/2 i JSON opisane w OpenAPI. TS 29.500 wymaga HTTP/2 z serializacją JSON (RFC 8259), a 3GPP publikuje definicje API funkcji sieciowych w formacie OpenAPI 3.0.
• TLS jest obowiązkowy do obsługi, ale nie zawsze do użycia. Wszystkie funkcje sieciowe muszą wspierać wzajemnie uwierzytelniony TLS. Wewnątrz sieci operatora TLS jest wymagany, „chyba że bezpieczeństwo sieci zapewniają inne środki”, np. NDS/IP lub ochrona fizyczna.
• NRF to jednocześnie rejestr usług i serwer autoryzacji. Funkcje rejestrują w nim swoje profile, wysyłają heart-beat, odnajdują inne funkcje i pobierają tokeny dostępu.
• Tokeny OAuth 2.0 są podpisane i nie da się ich odwołać. NRF podpisuje token (JWS) albo zabezpiecza go kodem MAC, a TS 33.501 wprost stwierdza, że odwoływanie tokenów nie jest wspierane. Kluczowa jest więc krótka ważność i ścisły zakres.
• N4 (PFCP) nie jest częścią SBA, ale jest równie krytyczny. TS 33.501 wymaga dla niego poufności, integralności i ochrony przed powtórzeniem, realizowanych przez IPsec, chyba że operator zapewni ochronę innymi środkami.
• Implementacje wymagają dojrzałego procesu aktualizacji. Projekt RANsacked (2025) wykazał 119 podatności i 97 identyfikatorów CVE w otwartych implementacjach rdzeni LTE i 5G.

Czym jest architektura SBA w rdzeniu 5G?

Service-Based Architecture (SBA) to model, w którym każda funkcja sieciowa rdzenia 5G (Network Function, NF) wystawia zestaw usług, a inne funkcje je konsumują. Funkcja wywołująca to NF Service Consumer, a funkcja udostępniająca usługę to NF Service Producer. Ta sama funkcja zwykle pełni obie role: AMF konsumuje usługi AUSF i UDM, a jednocześnie udostępnia własne usługi SMF.

W rdzeniu 4G (EPC) elementy rozmawiały przez interfejsy punkt-punkt z dedykowanymi protokołami, np. Diameter czy GTP-C. W 5GC te same zależności realizują wywołania HTTP/2. Interfejsy referencyjne nadal istnieją w dokumentacji (np. N11 między AMF a SMF, N12 między AMF a AUSF), ale technicznie są realizowane przez SBI.

Przykładowe usługi:

Funkcja (producent)	Usługa	Kto ją wywołuje	Cel
AUSF	Nausf_UEAuthentication	AMF	Uwierzytelnienie UE
UDM	Nudm_SubscriberDataManagement (Nudm_SDM)	AMF, SMF	Pobranie danych subskrypcji
UDM	Nudm_UEContextManagement (Nudm_UECM)	AMF, SMF	Rejestracja obsługującej funkcji
SMF	Nsmf_PDUSession	AMF	Tworzenie i aktualizacja sesji PDU
AMF	Namf_Communication	SMF, inne	Przekazywanie komunikatów N1 i N2
PCF	Npcf_SMPolicyControl	SMF	Polityki sesji
NRF	Nnrf_NFManagement, Nnrf_NFDiscovery, Nnrf_AccessToken	Wszystkie funkcje	Rejestracja, odkrywanie, tokeny

Z perspektywy zespołu platformowego rdzeń 5G to więc kilkanaście współpracujących mikroserwisów z rejestrem usług i serwerem autoryzacji. Różnica polega na skutkach błędu: awaria lub kompromitacja jednej funkcji wpływa na łączność wszystkich urządzeń w sieci.

Jak wygląda stos protokołów interfejsu SBI?

Interfejs SBI opisuje TS 29.500. Najważniejsze elementy stosu:

Warstwa	Specyfikacja	Uwagi dla zespołu IT
Model API	OpenAPI 3.0 (definicje publikowane przez 3GPP)	Gotowy kontrakt do walidacji żądań i testów kontraktowych
Serializacja	JSON (RFC 8259)	Typowe ryzyka parserów JSON i walidacji schematu
Aplikacja	HTTP/2 (RFC 9113)	Multipleksacja strumieni, kompresja nagłówków HPACK, długotrwałe połączenia
Bezpieczeństwo transportu	TLS, wzajemne uwierzytelnienie; profil wg TS 33.210	Obowiązkowe wsparcie; użycie w PLMN, chyba że ochronę zapewniają inne środki
Transport	TCP/IP	Standardowe mechanizmy sieciowe i polityki

API mają przewidywalną strukturę nazw. Na przykład usługa zarządzania profilami w NRF ma nazwę API nnrf-nfm, odkrywanie usług nnrf-disc, a tokeny są wydawane pod ścieżką /oauth2/token. Dzięki publicznym definicjom OpenAPI zespół może walidować ruch względem kontraktu na bramie lub w testach automatycznych, zamiast polegać wyłącznie na walidacji w kodzie funkcji sieciowej.

Jakie zadania pełni NRF i dlaczego jest krytyczny?

NRF (Network Repository Function) to rejestr usług rdzenia 5G i jednocześnie serwer autoryzacji OAuth 2.0. Według TS 29.510 udostępnia cztery usługi:

Usługa NRF	Nazwa API	Rola
Nnrf_NFManagement	nnrf-nfm	Rejestracja, aktualizacja i wyrejestrowanie profili NF, subskrypcje zmian statusu
Nnrf_NFDiscovery	nnrf-disc	Odkrywanie instancji NF spełniających kryteria (typ, wycinek, DNN, lokalizacja)
Nnrf_AccessToken	/oauth2/token	Wydawanie tokenów dostępu OAuth 2.0
Nnrf_Bootstrapping	n/d	Informacje startowe o usługach NRF

Cykl życia funkcji sieciowej w NRF

1. Rejestracja (NFRegister). Instancja NF publikuje swój profil: identyfikator instancji (NF Instance ID), typ, adresy, obsługiwane usługi, wycinki i inne atrybuty.
2. Heart-beat (NFUpdate). Zarejestrowana funkcja okresowo wysyła żądanie PATCH na zasób swojej instancji, ustawiając status REGISTERED. Interwał zależy od wdrożenia i NRF zwraca go po rejestracji.
3. Zawieszenie. Jeśli funkcja nie wyśle heart-beatu w ustalonym czasie, NRF zmienia jej status na SUSPENDED. Funkcja przestaje być widoczna w odkrywaniu usług, a subskrybenci dostają powiadomienie.
4. Odkrywanie (NFDiscovery). Konsumenci pytają NRF o instancje producentów, które spełniają kryteria.
5. Wyrejestrowanie (NFDeregister). Funkcja usuwa swój profil przy wyłączeniu.

Dlaczego NRF wymaga szczególnej ochrony?

NRF decyduje o tym, dokąd trafia ruch (odkrywanie usług) i kto może wywołać daną usługę (tokeny). Jeżeli nieuprawniony podmiot mógłby zarejestrować w NRF własny profil, ruch innych funkcji mógłby zostać do niego skierowany. Jeżeli mógłby uzyskać tokeny, mógłby wywoływać usługi, do których nie ma prawa. Dlatego:

• dostęp do operacji zapisu w nnrf-nfm powinien być ograniczony do znanych tożsamości funkcji (mTLS i, zgodnie z konfiguracją, OAuth 2.0 ze scope nnrf-nfm:nf-instance:write),
• klucz, którym NRF podpisuje tokeny, wymaga ochrony na poziomie najwrażliwszych sekretów platformy (najlepiej HSM lub zewnętrzny KMS),
• rejestracje nowych instancji i zmiany profili powinny trafiać do SIEM jako zdarzenia o wysokiej ważności.

Jak działa autoryzacja OAuth 2.0 w 5G Core?

W rdzeniu 5G NRF jest serwerem autoryzacji OAuth 2.0, konsument usługi jest klientem, a producent usługi jest serwerem zasobów (TS 33.501, klauzula 13.4.1). Konsument pobiera z NRF token dostępu w przepływie client credentials i dołącza go do każdego wywołania usługi. Producent przed obsłużeniem żądania weryfikuje podpis tokenu i jego zawartość.

Przepływ krok po kroku

Według definicji OpenAPI Nnrf_AccessToken żądanie tokenu ma typ application/x-www-form-urlencoded, wymagane pola to grant_type (wartość client_credentials), nfInstanceId i scope, a opcjonalnie m.in. nfType, targetNfType i targetNfInstanceId. Odpowiedź zawiera access_token w postaci JWS Compact Serialization, token_type równy Bearer oraz opcjonalnie expires_in i scope.

Co zawiera token dostępu?

Claim	Znaczenie	Na co zwrócić uwagę
iss	NF Instance ID wystawiającego NRF	Producent akceptuje wyłącznie tokeny od znanego NRF
sub	NF Instance ID konsumenta	Powinien odpowiadać tożsamości z certyfikatu TLS klienta
aud	Typ NF producenta albo lista identyfikatorów jego instancji	Lista konkretnych instancji zawęża użycie tokenu
scope	Nazwy usług (i ewentualnie zasobów lub operacji)	Najmniejszy niezbędny zakres
exp	Czas wygaśnięcia	Krótki, bo tokenów nie można odwołać
consumerPlmnId, producerPlmnId	Identyfikatory sieci w scenariuszach roamingu	Opcjonalne

Przykładowa, poglądowa zawartość tokenu po zdekodowaniu (identyfikatory fikcyjne):

{
  "iss": "6f1c2a7e-0000-4000-8000-000000000001",
  "sub": "0b9d4e12-0000-4000-8000-000000000002",
  "aud": "UDM",
  "scope": "nudm-sdm",
  "exp": 1791993600
}

Jak producent weryfikuje token?

Według TS 33.501 producent:

1. sprawdza, czy wystawca (iss) jest NRF, któremu ufa,
2. weryfikuje integralność tokenu podpisem z użyciem klucza publicznego NRF (albo kodem MAC przy współdzielonym kluczu),
3. sprawdza, czy aud wskazuje jego typ lub instancję, scope obejmuje wywoływaną usługę, a token nie wygasł,
4. może porównać sub z tożsamością z certyfikatu TLS klienta.

Najważniejszy wniosek operacyjny: TS 33.501 stwierdza, że odwoływanie tokenów nie jest wspierane. Skradziony token działa więc do czasu wygaśnięcia. Krótki czas życia, wąski scope, aud ograniczony do konkretnych instancji i powiązanie sub z certyfikatem mTLS to jedyne skuteczne ograniczenia skutków wycieku.

Warto też pamiętać, że TS 29.510 uzależnia użycie OAuth 2.0 dla części API od lokalnej konfiguracji, a alternatywą jest autoryzacja statyczna. Przy odbiorze wdrożenia trzeba więc sprawdzić, czy OAuth 2.0 jest faktycznie włączony, a nie tylko zaimplementowany.

Jak rozumieć wymagania TLS dla SBI?

TS 33.501 (klauzula 13.1) formułuje trzy zasady:

1. Wszystkie funkcje sieciowe muszą wspierać wzajemnie uwierzytelniony TLS i HTTPS, z certyfikatami po stronie klienta i serwera. Tożsamości z certyfikatów służą do uwierzytelniania i kontroli polityk.
2. TLS jest używany do ochrony transportu w PLMN, chyba że bezpieczeństwo zapewniają inne środki. Standard dopuszcza ochronę warstwy sieciowej przez NDS/IP (IPsec), a dla zaufanych, fizycznie chronionych interfejsów decyzję o ochronie kryptograficznej zostawia operatorowi.
3. Profil TLS odpowiada TS 33.210 z ograniczeniami wynikającymi z profilu HTTP/2 w RFC 9113.

Druga zasada to świadoma furtka. W praktyce spotyka się trzy modele:

Model	Jak działa	Zalety	Ryzyka
TLS w funkcjach sieciowych	Każda NF sama zestawia mTLS z certyfikatem swojej instancji	Tożsamość NF w certyfikacie, możliwe powiązanie z sub w tokenie	Złożoność PKI, rotacja certyfikatów w wielu komponentach
mTLS w service mesh	Proxy obok kontenera zestawia mTLS, NF komunikuje się jawnym HTTP/2 lokalnie	Centralne zarządzanie certyfikatami i politykami	Tożsamość dotyczy obciążenia w klastrze, a nie NF Instance ID; konieczne mapowanie tożsamości przy weryfikacji tokenów
Bez TLS, ochrona sieciowa (IPsec, izolacja)	Ruch SBI jawny wewnątrz chronionego segmentu	Najprostsze operacyjnie	Każdy dostęp do segmentu daje wgląd w dane abonentów i tokeny

Niezależnie od modelu warto wymusić TLS 1.2 lub 1.3, zablokować przestarzałe zestawy szyfrów, stosować własne CA dla rdzenia (oddzielne od CA dla systemów biurowych) i automatyzować rotację certyfikatów. O tym, jak zmiany zaufanych urzędów certyfikacji wpływają na systemy, piszemy w artykule Zmiany Root CA w TLS 2026.

Komunikacja bezpośrednia czy przez SCP?

TS 23.501 opisuje dwa sposoby komunikacji między funkcjami:

• Komunikacja bezpośrednia: konsument odnajduje producenta przez lokalną konfigurację lub NRF i wywołuje go bezpośrednio.
• Komunikacja pośrednia: ruch przechodzi przez SCP (Service Communication Proxy). Konsument może sam odnaleźć producenta albo zlecić odkrywanie SCP.

SCP pełni rolę zbliżoną do bramy API lub warstwy routingu w service mesh. Z punktu widzenia bezpieczeństwa to dobre miejsce na centralne logowanie, limity i walidację żądań, ale jednocześnie nowy element o wysokim zaufaniu, który sam wymaga hardeningu i monitorowania.

Gdzie przebiegają granice sieciowe w klastrze z 5G Core?

Rdzeń 5G na Kubernetes ma co najmniej cztery strefy ruchu o różnym poziomie zaufania:

Strefa	Interfejsy	Kto powinien mieć dostęp
SBI (płaszczyzna sterowania rdzenia)	HTTP/2 między NF, NRF, SCP	Wyłącznie funkcje rdzenia
Styk z RAN	N2 (NGAP, SCTP 38412), N3 (GTP-U, UDP 2152)	Wyłącznie adresy stacji gNB, najlepiej przez IPsec
N4	PFCP, UDP 8805	Wyłącznie SMF i UPF
N6 i zarządzanie	Ruch do sieci danych, API zarządzające, panele WWW, bazy danych	N6: ruch użytkowników przez firewall; zarządzanie: tylko sieć administracyjna

PFCP wymaga osobnej uwagi. Protokół nie ma własnego uwierzytelniania, a komunikaty PFCP tworzą, zmieniają i usuwają reguły przekazywania ruchu w UPF. TS 33.501 wymaga dla interfejsów takich jak N4 poufności, integralności i ochrony przed powtórzeniem, z obowiązkową obsługą IPsec ESP i IKEv2 na certyfikatach, chyba że operator zapewni bezpieczeństwo innymi środkami. W klastrze oznacza to co najmniej ścisłą politykę sieciową, a najlepiej szyfrowanie ruchu między węzłami SMF i UPF.

Przykładowa polityka Kubernetes, która dopuszcza ruch PFCP do UPF wyłącznie z podów SMF (nazwy etykiet i przestrzeni nazw są przykładowe):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: upf-allow-pfcp-from-smf-only
  namespace: core-up
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: upf
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: core-cp
          podSelector:
            matchLabels:
              app.kubernetes.io/name: smf
      ports:
        - protocol: UDP
          port: 8805

Analogicznie dla SBI: domyślna polityka „deny all” w przestrzeni nazw rdzenia, a następnie jawne zezwolenia tylko dla par funkcji, które według architektury muszą się komunikować. Usługi SBI i PFCP nie powinny być wystawione jako NodePort ani LoadBalancer dostępny spoza segmentu rdzenia. Jeśli UPF korzysta z dodatkowych interfejsów sieciowych (np. przez Multus i SR-IOV dla wydajności), te interfejsy omijają standardowe polityki CNI i wymagają kontroli na poziomie sieci fizycznej lub firewalla.

Więcej o budowie i utrzymaniu klastrów piszemy w artykule Kubernetes bez bólu: Rancher + K3s na Proxmox z CI/CD.

Jakie błędy wdrożeniowe spotyka się najczęściej?

Błąd	Dlaczego jest groźny	Jak go wykryć	Jak naprawić
SBI bez TLS „bo to sieć wewnętrzna”	Tokeny i dane abonentów są czytelne dla każdego z dostępem do segmentu	Przechwycenie ruchu w środowisku testowym: czy widać jawne ramki HTTP/2	mTLS w NF lub w service mesh, IPsec między węzłami
Certyfikaty i klucze z repozytorium projektu lub obrazu kontenera	Klucze prywatne są publicznie znane	Porównanie odcisków certyfikatów z plikami dostarczonymi w dystrybucji	Własne CA, generowanie kluczy przy wdrożeniu, sekrety poza obrazem
OAuth 2.0 zaimplementowany, ale wyłączony	Każda funkcja z dostępem sieciowym może wywołać każdą usługę	Test negatywny: żądanie bez tokenu powinno skończyć się odmową	Włączenie OAuth 2.0, testy negatywne w CI/CD
Tokeny z długą ważnością i szerokim scope	Wyciek tokenu daje długotrwały, szeroki dostęp (brak odwołania)	Przegląd konfiguracji NRF i przykładowych tokenów w środowisku testowym	Krótkie exp, wąski scope, aud z identyfikatorami instancji
PFCP i SBI osiągalne spoza rdzenia	Możliwość wpływu na reguły ruchu i usługi z innych segmentów	Skan z sieci zarządzania i z sieci biurowej (za zgodą właściciela)	NetworkPolicy, firewall, oddzielne sieci dla N4
Panele WWW i API zarządzające z domyślnymi hasłami	Dostęp do danych abonentów i konfiguracji	Przegląd kont i haseł po wdrożeniu	Zmiana haseł, SSO, dostęp tylko z sieci administracyjnej
Brak procesu aktualizacji	Znane podatności pozostają otwarte	Inwentaryzacja wersji i porównanie z bazami CVE	Proces patch management, środowisko testowe, okna serwisowe
Brak logowania odmów i błędów autoryzacji	Nadużycia pozostają niezauważone	Wygenerowanie kontrolowanych odmów w teście i sprawdzenie SIEM	Centralne logowanie, reguły korelacji

Jak bezpiecznie weryfikować odporność rdzenia 5G?

Testy rdzenia 5G zawsze prowadzimy w izolowanym środowisku, odseparowanym od sieci produkcyjnej i bez emisji radiowej, a testy w środowisku produkcyjnym wyłącznie za pisemną zgodą właściciela, w uzgodnionym zakresie i oknie serwisowym. Dobra praktyka to wbudowanie weryfikacji w proces wydawniczy, tak jak w przypadku każdej innej platformy mikroserwisowej:

1. Testy kontraktowe. Walidacja żądań i odpowiedzi względem definicji OpenAPI publikowanych przez 3GPP wykrywa odstępstwa od standardu, zanim trafią na produkcję.
2. Testy negatywne autoryzacji. Automatyczne sprawdzenie, że żądania bez tokenu, z wygasłym tokenem lub z tokenem o innym scope są odrzucane i logowane.
3. Testy odporności na niepoprawne dane. Automatyczne generowanie zniekształconych komunikatów (fuzzing) w laboratorium pozwala wykryć błędy parserów przed wdrożeniem. Wyniki projektu RANsacked pokazują, że to nie formalność: badacze zidentyfikowali 119 podatności, z czego 36 w AMF, a 25 umożliwiało ataki przed uwierzytelnieniem z dowolnego telefonu.
4. Skanowanie obrazów i zależności. Obrazy kontenerów funkcji sieciowych skanujemy jak każde inne, a wyniki porównujemy z bazami CVE.
5. Testy awarii. Wyłączenie instancji NF lub NRF w laboratorium pokazuje, czy nadmiarowość działa i czy NRF poprawnie oznacza instancje jako SUSPENDED.

Co monitorować i jakie sygnały przesyłać do SIEM?

Architektura rozproszona bez centralnego logowania jest praktycznie niemonitorowalna. Minimalny zestaw sygnałów:

Źródło	Sygnał	Dlaczego jest istotny
NRF	Nowe rejestracje NF, zmiany profili, wyrejestrowania	Nieoczekiwana instancja w rejestrze to zdarzenie wysokiej wagi
NRF	Wydane tokeny: sub, scope, aud, liczba na jednostkę czasu	Nietypowy zakres lub nagły wzrost żądań
Producenci NF	Odpowiedzi 401 i 403, błędy weryfikacji tokenu	Próby wywołań bez uprawnień
Warstwa TLS	Nieudane uzgodnienia TLS, nieznane certyfikaty klienta	Próby połączeń spoza zaufanej PKI
UPF i sieć	Ruch PFCP z adresów innych niż SMF, odrzucenia przez polityki sieciowe	Naruszenie granicy N4
AMF	Nagłe wzrosty rejestracji, odrzuceń i błędów Security Mode	Przeciążenie lub anomalie sygnalizacji
Kubernetes	Zmiany NetworkPolicy, sekretów, obrazów i uprawnień RBAC w przestrzeniach rdzenia	Zmiany konfiguracji wpływające na bezpieczeństwo

Przykład logiki reguły korelacyjnej, opisanej niezależnie od konkretnego SIEM:

JEŻELI źródło = NRF
  ORAZ zdarzenie = NFRegister
  ORAZ nfInstanceId NIE NALEŻY DO listy_zatwierdzonych_instancji
TO alert(ważność = wysoka, opis = "Rejestracja nieznanej funkcji sieciowej w NRF")

Do metryk wydajności i dostępności sprawdzają się standardowe narzędzia monitoringu. O podejściu do monitoringu usług piszemy w artykule Monitoring e-commerce z Zabbix, Docker i Chrome.

Kubernetes jako platforma dla 5G Core: o czym pamiętać?

Funkcje sieciowe rdzenia 5G coraz częściej dostarczane są jako aplikacje kontenerowe (CNF, Cloud-native Network Functions). Na platformie Kubernetes do wymagań 3GPP dochodzą standardowe zasady bezpieczeństwa klastra:

• Izolacja przestrzeni nazw i węzłów. Płaszczyzna sterowania rdzenia, UPF i systemy zarządzania w osobnych przestrzeniach nazw, a UPF najlepiej na dedykowanych węzłach.
• Sekrety poza obrazami. Klucze prywatne certyfikatów, klucz podpisujący tokeny w NRF i klucz prywatny SIDF w UDM przechowywane w menedżerze sekretów, najlepiej z HSM lub KMS.
• RBAC i zasada najmniejszych uprawnień. Ograniczony dostęp do przestrzeni nazw rdzenia, audyt operacji na sekretach.
• Zaufany łańcuch dostaw. Podpisywanie i weryfikacja obrazów, skanowanie podatności, kontrolowane rejestry.
• Pod Security i ograniczenia uprawnień. Kontenery bez trybu uprzywilejowanego tam, gdzie nie jest wymagany; świadoma kontrola wyjątków dla UPF, który bywa wdrażany z dodatkowymi uprawnieniami sieciowymi.
• Dane w spoczynku. Bazy danych subskrybentów (UDR) szyfrowane, z kopią zapasową i kontrolą dostępu. Jeśli rdzeń korzysta z rozproszonej pamięci masowej, obowiązują te same zasady co dla każdego krytycznego systemu (zob. Ceph w Kubernetes i OpenStack).

Checklista hardeningu SBA w 5G Core

Tożsamość i PKI

• Własne CA dla rdzenia, oddzielne od CA systemów biurowych.
• Brak certyfikatów i kluczy domyślnych z dystrybucji lub obrazów.
• Wzajemny TLS (TLS 1.2 lub 1.3) na wszystkich interfejsach SBI albo udokumentowany model ochrony alternatywnej.
• Automatyczna rotacja certyfikatów i monitorowanie dat wygaśnięcia.

NRF i OAuth 2.0

• OAuth 2.0 włączony, nie tylko zaimplementowany.
• Krótki czas życia tokenów, wąskie scope, aud ograniczone do instancji tam, gdzie to możliwe.
• Producenci weryfikują iss, podpis, aud, scope, exp oraz zgodność sub z certyfikatem klienta.
• Klucz podpisujący tokeny w HSM lub KMS.
• Operacje zapisu w NRF ograniczone do zatwierdzonych instancji.

Sieć

• Domyślne „deny all” w przestrzeniach nazw rdzenia i jawne zezwolenia dla wymaganych par funkcji.
• PFCP (UDP 8805) wyłącznie między SMF i UPF; N2 i N3 wyłącznie z adresów gNB.
• Brak wystawienia SBI i PFCP przez NodePort lub LoadBalancer poza segment rdzenia.
• Kontrola interfejsów omijających CNI (Multus, SR-IOV) na poziomie sieci fizycznej.

Proces i monitoring

• Testy kontraktowe względem OpenAPI 3GPP i testy negatywne autoryzacji w CI/CD.
• Testy odporności w izolowanym laboratorium przed każdą nową wersją.
• Inwentaryzacja wersji NF i śledzenie CVE.
• Zdarzenia NRF, odmowy 401 i 403, błędy TLS i naruszenia polityk sieciowych w SIEM.