Controlul Accesului Bazat pe Roluri Г®n Sistemele C2 de ApДѓrare: Design И™i Implementare

Controlul accesului în software-ul C2 de apărare nu este o funcție adăugată la sfârșitul dezvoltării. Este o decizie arhitecturală fundamentală care determină cine poate vedea care date, cine poate emite care comenzi și cum sunt aplicate aceste decizii la fiecare strat al sistemului — de la endpoint-urile API la interogările de baze de date și abonamentele WebSocket. Greșind înseamnă fie expunerea datelor clasificate utilizatorilor neautorizați, fie blocarea operatorilor care au nevoie de conștientizare a situației în timp real pentru a lua decizii critice în timp.

Controlul accesului bazat pe roluri standard (RBAC), implementat în furnizorii de identitate comerciali precum Keycloak sau Azure AD, acoperă maparea rol-la-permisiune adecvat pentru software-ul enterprise. Sistemele C2 de apărare necesită o dimensiune suplimentară: niveluri de clasificare și compartimente. Un utilizator poate fi autentificat și deține rolul corect (de ex., „operator") dar să i se refuze în continuare accesul la o urmă specifică deoarece acea urmă este marcată cu o clasificare sau un compartiment pentru care utilizatorul nu deține autorizare. Acesta este principiul need-to-know în formă tehnică.

RBAC vs ABAC: Ce Model se PotriveИ™te C2 de ApДѓrare

RBAC pur atribuie permisiuni rolurilor și roluri utilizatorilor. Un rol „S2 de Batalion" acordă acces la straturile de informații; un rol „Ofițer de Logistică" acordă acces la datele lanțului de aprovizionare. Acest model este simplu de implementat și auditat, dar nu poate exprima restricții fine-grained la nivel de date fără explozia rolurilor — creând un rol separat pentru fiecare combinație posibilă de clasificare a datelor.

Controlul Accesului Bazat pe Atribute (ABAC) evaluează deciziile de acces pe baza atributelor subiectului (utilizator), resursei (obiect de date), acțiunii și mediului (timp, context de rețea). Într-un model ABAC, accesul la o urmă este acordat dacă: nivelul de autorizare al utilizatorului este mai mare sau egal cu nivelul de clasificare al urmei ȘI utilizatorul deține toate etichetele de compartiment asociate urmei ȘI terminalul curent al utilizatorului se află pe un segment de rețea aprobat.

ГЋn practicДѓ, sistemele C2 de apДѓrare folosesc un hibrid: RBAC pentru aplicarea grosierДѓ a rolurilor (cine poate accesa ce modul de aplicaИ›ie) И™i ABAC pentru filtrarea fine-grained a datelor (ce Г®nregistrДѓri dintr-un modul poate vedea un utilizator). Stratul RBAC este aplicat la momentul autentificДѓrii prin claim-urile JWT; stratul ABAC este aplicat la momentul interogДѓrii de stratul de date care aplicДѓ securitatea la nivel de rГўnd pe baza setului de atribute al utilizatorului.

Niveluri de Clasificare И™i Compartimente

Nivelurile de clasificare NATO Г®n ordine ascendentДѓ: NECLASIFICAT, RESTRICИљIONAT, CONFIDENИљIAL, SECRET, TOP SECRET. Majoritatea sistemelor C2 tactice opereazДѓ la SECRET sau mai jos, cu unele sisteme gestionГўnd date TOP SECRET / SCI Г®n enclave separate. Nivelul de clasificare al unui obiect de date este nivelul minim de autorizare necesar pentru a-l accesa.

Compartimentele sunt ortogonale faИ›Дѓ de nivelurile de clasificare. Un utilizator autorizat la SECRET poate sДѓ nu deИ›inДѓ compartimentul SIGINT sau HUMINT, chiar la nivelul SECRET. O urmДѓ derivatДѓ dintr-un senzor SIGINT este etichetatДѓ cu compartimentul SIGINT; numai utilizatorii care deИ›in acel compartiment vДѓd urma Г®n COP, indiferent de nivelul lor general de autorizare. ГЋn software, compartimentele sunt implementate ca un set de etichete string atГўt pe Г®nregistrarea de date cГўt И™i pe setul de atribute al utilizatorului; accesul este acordat numai cГўnd setul de compartimente al Г®nregistrДѓrii de date este un subset al setului de compartimente al utilizatorului.

Need-to-know adaugДѓ o a treia dimensiune: chiar И™i un utilizator cu nivelul de autorizare corect И™i apartenenИ›a la compartiment poate fi restricИ›ionat de la accesarea datelor nerelate cu atribuirea sa curentДѓ de misiune. Aceasta este mai dificil de aplicat programatic И™i este adesea implementatДѓ ca o combinaИ›ie de politicДѓ ABAC И™i controale manuale ale custodelui de date.

Structura Claim-ului JWT pentru C2 de ApДѓrare

Jetonele Web JSON (JWT) transportДѓ identitatea utilizatorului И™i claim-urile de atribute Г®ntre furnizorul de identitate И™i serviciile aplicaИ›iei C2. O structurДѓ de payload JWT orientatДѓ spre apДѓrare:

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

Claim-ul clearance poartДѓ nivelul de autorizare al utilizatorului ca un И™ir care se mapeazДѓ la o valoare numericДѓ Г®n motorul de politicДѓ (NECLASIFICAT=0, RESTRICИљIONAT=1, CONFIDENИљIAL=2, SECRET=3, TOP SECRET=4). Claim-ul compartments este un array de И™iruri de compartiment. Claim-ul network_segment poartДѓ contextul de reИ›ea — SIPRNET, NIPRNET sau un identificator de reИ›ea specific misiunii — permiИ›Гўnd decizii de acces bazate pe mediu.

Perioadele de valabilitate ale token-urilor pentru sistemele de apДѓrare sunt mai scurte decГўt normele comerciale: token-uri de acces de 60 de minute cu rotaИ›ia token-ului de reГ®mprospДѓtare. Fiecare reГ®mprospДѓtare a token-ului re-valideazДѓ faИ›Дѓ de depozitul curent de atribute al furnizorului de identitate, asigurГўnd cДѓ autorizДѓrile revocate intrДѓ Г®n vigoare Г®n decurs de un ciclu de reГ®mprospДѓtare.

Punctele de Aplicare a Politicii

Într-o arhitectură C2 cu microservicii, controlul accesului trebuie aplicat la mai multe straturi — nu doar la gateway-ul API. Un sistem C2 de apărare are de obicei trei puncte de aplicare a politicii:

Gateway API (RBAC grosier). ValideazДѓ semnДѓtura JWT И™i expirarea. Respinge cererile cu token-uri invalide. RuteazДѓ cererile la serviciul corespunzДѓtor pe baza claim-urilor de rol. Nu ia decizii de acces la nivel de date.

Stratul de Servicii (evaluarea politicii ABAC). Fiecare serviciu care gestionează date clasificate are un punct de decizie a politicii încorporat. Înainte de returnarea unui obiect de date, serviciul evaluează: autorizarea utilizatorului >= nivelul de clasificare al datelor ȘI compartimentele utilizatorului superset al compartimentelor datelor. Obiectele care eșuează această verificare sunt filtrate din răspuns, nu returnate cu o eroare 403 — deoarece existența înregistrărilor clasificate este ea însăși adesea clasificată.

Stratul Bazei de Date (securitate la nivel de rГўnd). Politicile de securitate la nivel de rГўnd (RLS) PostgreSQL aplicДѓ restricИ›iile la nivel de date la baza de date Г®n sine, furnizГўnd apДѓrare Г®n profunzime faИ›Дѓ de erorile de logicДѓ a aplicaИ›iei. Chiar dacДѓ un serviciu are un bug Г®n evaluarea politicii sale, stratul bazei de date previne datele nefiltrate sДѓ ajungДѓ la aplicaИ›ie.

Modelul de Securitate Multi-Nivel Bell-LaPadula

Modelul Bell-LaPadula (BLP) formalizează controlul accesului pentru informații clasificate cu două reguli primare. Proprietatea de Securitate Simplă (fără citire în sus): un subiect la nivelul de clasificare L nu poate citi un obiect la nivelul de clasificare L' unde L' > L. Proprietatea Stea (fără scriere în jos): un subiect la nivelul de clasificare L nu poate scrie la un obiect la nivelul de clasificare L' unde L' < L — prevenind un utilizator autorizat să copieze date clasificate într-o înregistrare neclasificată.

ГЋn practicДѓ, regula fДѓrДѓ-scriere-Г®n-jos este cea mai dificil de aplicat Г®n arhitecturile aplicaИ›iilor web. Un operator cu autorizare SECRET care lucreazДѓ Г®ntr-o aplicaИ›ie C2 ar putea, prin defecte de logicДѓ a aplicaИ›iei, sДѓ copieze datele de urmДѓ SECRET Г®ntr-un raport NECLASIFICAT. Aplicarea necesitДѓ cДѓ operaИ›iunile de scriere seteazДѓ explicit nivelul de clasificare al Г®nregistrДѓrii И›intДѓ la maximul nivelului de clasificare al datelor sursДѓ, И™i cДѓ aceastДѓ logicДѓ sДѓ fie aplicatДѓ la stratul de servicii, nu lДѓsatДѓ operatorului.

Integrarea Furnizorului IAM

Keycloak este cel mai frecvent utilizat furnizor de identitate open-source Г®n programele C2 de apДѓrare datoritДѓ suportului sДѓu pentru federarea LDAP/Active Directory, politici de autorizare fine-grained И™i deployment on-premises fДѓrДѓ dependenИ›Дѓ cloud. Poate fi implementat air-gapped, ceea ce este o cerinИ›Дѓ pentru deployment-urile Г®n reИ›ele clasificate.

Keycloak Authorization Services suportДѓ evaluarea politicii ABAC nativ. Politicile sunt definite ca reguli bazate pe JavaScript sau folosind limbajul de politicДѓ JSON Г®ncorporat. ГЋntr-o integrare tipicДѓ C2, Keycloak emite JWT-uri conИ›inГўnd claim-urile de autorizare И™i compartiment ale utilizatorului, derivate din apartenenИ›a la grupul Active Directory sincronizatДѓ din serviciul de director al reИ›elei clasificate.

TrasabilitДѓИ›i de Audit И™i Integrarea SIEM

Fiecare decizie de acces — atât acorduri cât și refuzuri — trebuie înregistrată cu suficient detaliu pentru auditul de securitate și răspunsul la incidente. O intrare în jurnalul de audit C2 de apărare include: timestamp, identificatorul utilizatorului, nivelul de autorizare al utilizatorului, acțiunea tentată, identificatorul resursei, nivelul de clasificare al resursei, decizia (ACORDAT/REFUZAT) și regula de politică care a produs decizia.

Jurnalele de audit sunt transmise la un sistem de Management al Informațiilor și Evenimentelor de Securitate (SIEM) — IBM QRadar sau Splunk Enterprise Security în cele mai multe contexte de programe NATO — pentru detectarea anomaliilor în timp real. Un utilizator care accesează un număr neobișnuit de înregistrări în afara zonei sale operaționale normale, sau o secvență de tentative de acces refuzate urmată de acces reușit, declanșează o alertă pentru revizuire de securitate.