Kontrola dostępu oparta na rolach w systemach C2 dla obronności: projektowanie i implementacja

Kontrola dostępu w oprogramowaniu C2 dla obronności nie jest funkcją dodawaną pod koniec procesu wytwarzania. Jest fundamentalną decyzją architektoniczną, która określa, kto może widzieć jakie dane, kto może wydawać jakie rozkazy i jak te decyzje są egzekwowane na każdej warstwie systemu — od punktów końcowych API po zapytania do bazy danych i subskrypcje WebSocket. Błąd tutaj oznacza albo ujawnienie niejawnych danych nieautoryzowanym użytkownikom, albo zablokowanie operatorów potrzebujących świadomości sytuacyjnej w czasie rzeczywistym.

Standardowa kontrola dostępu oparta na rolach (RBAC), wdrożona w komercyjnych dostawcach tożsamości takich jak Keycloak czy Azure AD, wystarczająco pokrywa mapowanie ról na uprawnienia dla oprogramowania korporacyjnego. Systemy C2 MON i SZ RP wymagają dodatkowego wymiaru: poziomów klauzuli i przedziałów. Użytkownik może być uwierzytelniony i posiadać poprawną rolę, ale nadal może być pozbawiony dostępu do konkretnego śladu, ponieważ jest oznaczony klauzulą lub przedziałem, do którego użytkownik nie ma poświadczenia. Jest to zasada need-to-know w formie technicznej.

RBAC kontra ABAC: który model pasuje do C2 dla obronności

Czysta RBAC przypisuje uprawnienia rolom, a role użytkownikom. Rola "oficer S2 batalionu" nadaje dostęp do nakładek wywiadowczych; rola "oficer logistyki" — do danych łańcucha dostaw. Model ten jest prosty w implementacji i audycie, ale nie może wyrazić szczegółowych ograniczeń na poziomie danych bez eksplozji ról.

Kontrola dostępu oparta na atrybutach (ABAC) ocenia decyzje o dostępie na podstawie atrybutów podmiotu (użytkownika), zasobu (obiektu danych), akcji i środowiska (czas, kontekst sieciowy). W modelu ABAC dostęp do śladu jest przyznawany jeśli: poziom poświadczenia użytkownika jest większy lub równy poziomowi klauzuli śladu I użytkownik posiada wszystkie tagi przedziałów powiązanych ze śladem I obecny terminal użytkownika jest w autoryzowanym segmencie sieciowym.

W praktyce systemy C2 dla obronności używają podejścia hybrydowego: RBAC do gruboziarnistego egzekwowania ról i ABAC do szczegółowego filtrowania danych, z egzekwowaniem warstwy RBAC przez roszczenia JWT, a warstwy ABAC przez zapytania bazodanowe stosujące bezpieczeństwo na poziomie wierszy.

Poziomy klauzuli i przedziały

Poziomy klasyfikacji NATO w kolejności rosnącej: UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET, TOP SECRET. Większość taktycznych systemów C2 działa na poziomie SECRET lub poniżej. Poziom klasyfikacji obiektu danych to minimalny poziom poświadczenia wymagany do uzyskania do niego dostępu.

Przedziały są ortogonalne do poziomów klasyfikacji. Użytkownik z poświadczeniem SECRET może nie posiadać przedziału SIGINT lub HUMINT, nawet na poziomie SECRET. Ślad pochodzący z czujnika SIGINT jest oznaczony przedziałem SIGINT; tylko użytkownicy posiadający ten przedział widzą ślad w COP, niezależnie od ogólnego poziomu ich poświadczenia. Zasada need-to-know dodaje trzeci wymiar trudniejszy do programowego egzekwowania — połączenie polityki ABAC i ręcznych kontroli opiekuna danych.

Struktura roszczeń JWT dla C2 obronności

JSON Web Token przenosi tożsamość użytkownika i roszczenia atrybutów między dostawcą tożsamości a serwisami aplikacji C2:

{
  "sub": "user-uuid-1234",
  "name": "Kpt. A. Kowalski",
  "roles": ["operator", "s2-officer"],
  "clearance": "SECRET",
  "compartments": ["SIGINT", "HUMINT"],
  "unit": "1-32-ZMECH",
  "network_segment": "SIPRNET",
  "iat": 1746960000,
  "exp": 1746963600,
  "jti": "unique-token-id"
}

Roszczenie clearance przenosi poziom poświadczenia użytkownika jako ciąg mapujący się na wartość liczbową w silniku polityki. Roszczenie compartments to tablica ciągów przedziałów. Roszczenie network_segment przenosi kontekst sieciowy umożliwiając decyzje o dostępie oparte na środowisku. Okresy ważności tokenów dla systemów obronnych są krótsze niż normy komercyjne: tokeny dostępu na 60 minut z rotacją tokenów odświeżania.

Punkty egzekwowania polityki

W architekturze mikrousług C2 kontrola dostępu musi być egzekwowana na wielu warstwach.

Brama API (gruboziarnista RBAC). Weryfikuje podpis i wygaśnięcie JWT. Odrzuca żądania z nieważnymi tokenami. Nie podejmuje decyzji o dostępie na poziomie danych.

Warstwa serwisowa (ocena polityki ABAC). Każdy serwis obsługujący niejawne dane ma wbudowany punkt podejmowania decyzji. Przed zwróceniem obiektu danych serwis ocenia: poświadczenie użytkownika >= poziom klauzuli danych I przedziały użytkownika są nadzbiorem przedziałów danych. Obiekty niespełniające tego testu są odfiltrowywane z odpowiedzi.

Warstwa bazy danych (bezpieczeństwo na poziomie wierszy). Polityki RLS PostgreSQL egzekwują ograniczenia na poziomie danych bezpośrednio w bazie danych, zapewniając głęboką obronę przed błędami logiki aplikacji. Nawet jeśli serwis ma błąd w ocenie polityki, warstwa bazy danych zapobiega dotarciu niefiltrowanych danych do aplikacji — podejście szczególnie istotne dla systemów C2 SZ RP działających w sieciach niejawnych.

Model bezpieczeństwa wielopoziomowego Bell-LaPadula

Model Bella-LaPadula (BLP) formalizuje kontrolę dostępu do informacji niejawnych z dwoma głównymi regułami. Właściwość prostego bezpieczeństwa (bez odczytu w górę): podmiot na poziomie klasyfikacji L nie może odczytać obiektu na poziomie L', gdzie L' > L. Właściwość gwiazdy (bez zapisu w dół): podmiot na poziomie L nie może zapisać do obiektu na poziomie L', gdzie L' < L — zapobiegając kopiowaniu niejawnych danych do rekordu o niższej klauzuli.

W praktyce reguła bez-zapisu-w-dół jest trudniejsza do egzekwowania w architekturach aplikacji webowych. Egzekwowanie wymaga, aby operacje zapisu jawnie ustawiały poziom klauzuli docelowego rekordu na maksimum poziomu klauzuli danych źródłowych, a logika ta była egzekwowana na warstwie serwisowej.

Dzienniki audytu i integracja z SIEM

Każda decyzja o dostępie — zarówno przyznanie jak i odmowa — musi być rejestrowana z wystarczającymi szczegółami do audytu bezpieczeństwa i reakcji na incydenty. Wpis dziennika audytu systemu C2 SZ RP zawiera: znacznik czasu, identyfikator użytkownika, poziom poświadczenia, podjętą akcję, identyfikator zasobu, poziom klauzuli zasobu, decyzję (GRANT/DENY) oraz regułę polityki, która ją wyprodukowała. Dzienniki audytu są przesyłane do systemu SIEM do wykrywania anomalii w czasie rzeczywistym.