Securitatea centrată pe date – ideea că protecția urmează obiectul de date mai degrabă decât perimetrul rețelei – nu este nouă, dar implementarea sa practică în sistemele militare de coaliție a fost istoric dificilă. STANAG 4774 și STANAG 4778 sunt răspunsul formal al NATO: două standarde interdependente care definesc modul în care sunt structurate etichetele de confidențialitate, modul în care sunt legate de date și modul în care motoarele de politică le evaluează. Acest articol acoperă ingineria practică a unei implementări de etichetare conforme: sintaxa etichetei, mecanismul de legare, proiectarea punctului de aplicare a politicii, gestionarea agregării și disciplina de păstrare a etichetelor care determină dacă arhitectura dvs. supraviețuiește revizuirii de acreditare. Pentru contextul politicii de clasificare și eliberare care încadrează această muncă de inginerie, consultați articolul însoțitor despre clasificarea STANAG 4774/4778 și eliberarea de coaliție.

Modelul de securitate centrat pe date: de ce etichetele călătoresc cu datele

Securitatea tradițională centrată pe rețea se bazează pe nivelul de clasificare al enclavei: odată ce o bucată de date se află într-o rețea SECRET, fiecărui sistem din acea rețea i se acordă încredere să o manipuleze. Acest model se prăbușește în mediile de coaliție unde datele se mută între enclave cu niveluri de acreditare diferite, politici naționale diferite și seturi de destinatari autorizați diferite. Un document SECRET dintr-o rețea comună nu este neapărat eliberabil fiecărei națiuni partenere cu acces la acea rețea.

Securitatea centrată pe date rezolvă acest lucru făcând eticheta o proprietate inseparabilă a obiectului de date. Fiecare obiect poartă o etichetă de confidențialitate care poate fi citită de mașină și care specifică nivelul său de clasificare, restricțiile de manipulare care îi guvernează utilizarea și marcajele de eliberare care identifică ce organizații sunt autorizate să-l primească. Deciziile de politică – dacă să transmită, să afișeze, să stocheze sau să tipărească un obiect – sunt luate prin evaluarea etichetei obiectului față de autorizarea subiectului solicitant și nivelul de acreditare al sistemului de destinație, mai degrabă decât prin a avea încredere că rețeaua aplică granița corectă.

STANAG 4774 definește structura etichetei. STANAG 4778 definește mecanismul de legare. Împreună oferă substratul tehnic pentru partajarea datelor de coaliție care respectă politica națională de divulgare a fiecărei națiuni fără a necesita revizuirea manuală a fiecărui schimb de date. Înțelegerea ambelor standarde ca o pereche – nu izolat – este premisa unei implementări conforme.

Sintaxa etichetei STANAG 4774: structură și codificare

O etichetă de confidențialitate STANAG 4774 este un document XML conform cu schema XML STANAG 4774. Elementul său de nivel superior este <ConfidentialityLabel>, care poartă trei copii obligatorii și mai multe extensii opționale.

Identificatorul de politică. Elementul <PolicyIdentifier> conține un Object Identifier (OID) care referă documentul de politică de etichetare care guvernează această etichetă. OID-ul este înregistrat la o autoritate recunoscută – de obicei biroul național C3 sau Agenția NATO C3 – și este cheia care permite sistemelor receptoare să caute definiția completă a politicii și să evalueze corect eticheta. O etichetă fără un OID de politică rezolvabil nu poate fi evaluată de un motor de politică conform și trebuie tratată ca neverificată.

Clasificare. Elementul <Classification> specifică nivelul de clasificare ca o valoare enumerată: UNCLASSIFIED, RESTRICTED, CONFIDENTIAL sau SECRET. Codificarea este sensibilă la majuscule și trebuie să se potrivească exact cu valorile string definite în documentul de politică referit de OID. O etichetă care folosește "Secret" în loc de "SECRET" va eșua la validarea schemei într-o implementare conformă – o eroare comună de integrare la generarea etichetelor din biblioteci XML de uz general care nu impun enumerarea.

Restricții de manipulare și eliberare. Elementul <CategoryData> poartă restricții de manipulare precum ATOMAL, CRYPTO, EYES ONLY sau restricții specifice misiunii definite de politică. Elementul <PermittedCountryCodes> poartă marcajul de eliberare ca un set de coduri de țară ISO 3166-1 alpha-3. Marcajul de eliberare este partea cea mai importantă operațional a etichetei în mediile multinaționale: determină ce sisteme ale națiunilor partenere sunt autorizate să primească datele etichetate, indiferent de nivelul de clasificare.

Generarea etichetelor: cerințe de validare

Fiecare etichetă generată de un sistem conform trebuie validată față de schema XML STANAG 4774 înainte de a fi legată de orice obiect de date. Validarea schemei detectează erorile structurale – OID-uri malformate, șiruri de clasificare invalide, elemente obligatorii lipsă – dar nu validează corectitudinea semantică față de documentul de politică. Un pas separat de validare la nivel de politică trebuie să verifice că fiecare restricție și marcaj de eliberare din etichetă este definit în documentul de politică referit și că combinația de nivel de clasificare și restricții este permisă de acea politică. O implementare care omite validarea la nivel de politică va genera etichete care trec validarea schemei, dar care sunt respinse de motoarele de politică din aval cu erori greu de diagnosticat ulterior. Construiți pasul de validare la nivel de politică în generatorul de etichete, nu într-un audit separat post-generare.

Mecanismele de legare STANAG 4778: aserțiune și încapsulare

STANAG 4778 definește două mecanisme pentru legarea unei etichete STANAG 4774 de un obiect de date: legarea prin aserțiune și legarea prin încapsulare. Acestea servesc cazuri de utilizare diferite și au proprietăți de securitate diferite, iar alegerea dintre ele trebuie făcută în momentul proiectării arhitecturii.

Legarea prin aserțiune produce o aserțiune XML semnată care include eticheta, o referință la obiectul de date (de obicei un hash criptografic al încărcăturii utile) și o semnătură digitală de la autoritatea de etichetare. Semnătura este calculată folosind XML Digital Signature (XMLDSig) peste XML-ul canonizat al etichetei. Obiectul de date și aserțiunea semnată sunt transmise împreună – fie în același plic de mesaj, fie ca o pereche referință-și-aserțiune. Sistemul receptor verifică aserțiunea verificând semnătura față de certificatul de cheie publică al autorității de etichetare, apoi verifică hash-ul obiectului de date față de hash-ul din aserțiune. Dacă ambele verificări trec, eticheta este verificată ca autentică și nemodificată, iar legarea dintre etichetă și obiectul de date este confirmată criptografic.

Legarea prin aserțiune este obligatorie pentru datele care traversează granițele de clasificare printr-o soluție cross-domain (CDS). Acreditatorul trebuie să verifice că CDS-ul aplică etichetele corect, iar aserțiunea semnată furnizează dovada de audit necesară pentru această verificare. Fără legarea prin aserțiune la granița CDS, acreditatorul nu poate confirma că etichetele prezentate sistemului de pe partea joasă sunt reprezentări autentice ale deciziei autorității de etichetare de pe partea înaltă – iar CDS-ul nu va fi acreditat.

Legarea prin încapsulare încorporează eticheta direct în structura obiectului de date – într-un antet de mesaj, un bloc de metadate sau un câmp de extensie definit. Nu există o semnătură criptografică separată; legarea se bazează pe integritatea canalului de transport. Legarea prin încapsulare este mai simplă de implementat și este utilizată pe scară largă pentru datele care rămân într-un singur domeniu de securitate. Pentru un sistem C2 care operează în întregime într-o enclavă SECRET, legarea prin încapsulare în schema de mesaj este suficientă și evită supraîncărcarea PKI a legării prin aserțiune pentru fiecare mesaj intern.

Amestecarea mecanismelor de legare în cadrul aceluiași sistem – utilizarea legării prin încapsulare pentru mesajele interne și a legării prin aserțiune doar la granița CDS – este corectă și frecventă, dar granița trebuie definită clar și aplicată în implementare. Ambiguitatea cu privire la care mecanism de legare se aplică la care graniță a sistemului este o sursă de constatări de acreditare.

Proiectarea punctului de aplicare a politicii

Un Policy Enforcement Point (PEP) este componenta software care interceptează cererile de acces și schimb de date și evaluează eticheta obiectului solicitat față de autorizarea subiectului solicitant și nivelul de acreditare al sistemului solicitant. Într-o arhitectură conformă STANAG 4774/4778, PEP-ul nu este opțional: este mecanismul prin care eticheta produce un control de acces real, mai degrabă decât să fie doar o adnotare de metadate care nu este niciodată evaluată.

Algoritmul de evaluare al PEP trebuie să implementeze corect dominanța. Un subiect poate accesa un obiect dacă și numai dacă autorizarea subiectului domină eticheta obiectului: nivelul de clasificare al subiectului este cel puțin la fel de înalt ca al obiectului, subiectul deține toate restricțiile cerute de marcajele de manipulare ale obiectului, iar setul de eliberare autorizat al subiectului acoperă toate marcajele de eliberare de pe obiect. Fiecare dintre aceste trei condiții trebuie evaluată independent; trecerea a două din trei este o încălcare a politicii, nu o acordare parțială a accesului.

Condiția cel mai frecvent implementată greșit este eliberarea. O comparație corectă de eliberare verifică că setul de eliberare autorizat al sistemului receptor este o supermulțime a marcajului de eliberare al obiectului. Un sistem autorizat pentru REL TO DEU GBR USA poate primi un obiect marcat REL TO DEU GBR, deoarece setul autorizat conține toate națiunile marcate. Un sistem autorizat pentru REL TO GBR USA nu poate primi un obiect marcat REL TO DEU GBR, chiar dacă GBR apare în ambele seturi, deoarece DEU nu este în setul autorizat al sistemului receptor. Implementarea unei verificări de supermulțime în loc de o verificare de intersecție este logica corectă; verificarea de intersecție este eroarea comună și produce un sistem care acordă acces la obiecte pe care nu este autorizat să le primească.

Concluzie cheie: Cel mai frecvent eșec de acreditare în implementările STANAG 4774/4778 nu este generarea sau legarea etichetelor – este gestionarea agregării. Sistemele care etichetează corect obiectele de date individuale eșuează frecvent să escaladeze etichetele atunci când acele obiecte sunt combinate în produse derivate. Un motor de fuziune care îmbină un raport de urmărire CONFIDENTIAL cu o fixare de poziție RESTRICTED trebuie să producă o ieșire CONFIDENTIAL; middleware-ul care moștenește doar eticheta unui singur obiect de intrare va produce ieșiri etichetate incorect care ajung pe partea joasă prin CDS, constituind o scurgere.

Agregarea și escaladarea etichetelor

Agregarea – combinarea a două sau mai multe obiecte etichetate într-un produs derivat – este cea mai dificilă problemă într-o implementare practică STANAG 4774/4778. Produsul derivat trebuie să poarte o etichetă care este cel puțin la fel de restrictivă ca cea mai restrictivă intrare, pe toate cele trei componente ale etichetei: nivelul de clasificare, restricțiile de manipulare și eliberarea.

Pentru nivelul de clasificare, regula este simplă: clasificarea de ieșire este maximul clasificărilor de intrare. Un produs derivat din intrări RESTRICTED și CONFIDENTIAL este CONFIDENTIAL. Pentru restricțiile de manipulare, ieșirea trebuie să includă reuniunea tuturor restricțiilor de intrare: dacă o intrare poartă ATOMAL și alta poartă CRYPTO, ieșirea trebuie să le poarte pe ambele. Pentru eliberare, ieșirea trebuie să poarte intersecția seturilor de eliberare de intrare: dacă o intrare este eliberabilă către DEU GBR USA și alta către GBR FRA, ieșirea este eliberabilă doar către GBR, deoarece doar GBR este autorizat pentru ambele intrări.

Această logică de agregare trebuie implementată în fiecare componentă care produce date derivate: motoare de fuziune, generatoare de rapoarte, servicii de rezumare și orice conductă de analiză care combină intrări din mai multe surse. Calculul de agregare a etichetelor trebuie să se producă înainte ca obiectul de ieșire să fie scris în orice buffer sau coadă, nu ca un pas de post-procesare. O ieșire care există fără o etichetă corectă chiar și pentru o scurtă perioadă – înainte ca un pas de post-procesare să se declanșeze – reprezintă o fereastră de neconformitate cu politica pe care un acreditator o va identifica în timpul revizuirii proiectării.

Păstrarea etichetelor în schimbul de coaliție

Păstrarea etichetelor este disciplina de a asigura că o etichetă STANAG 4774 și legarea sa STANAG 4778 supraviețuiesc întregului traseu de tranzit de la sistemul de origine la fiecare destinatar autorizat, inclusiv prin middleware, brokeri de mesaje, gateway-uri de federare și componente de traducere a formatelor care pot să nu fie conștiente de etichete.

Într-o infrastructură de schimb conformă Federated Mission Network (FMN), păstrarea etichetelor este integrată în profil: stratul de servicii FMN este obligat să poarte etichetele STANAG 4774 în plicurile de mesaje și să verifice legăturile la ingestie. În practică, multe sisteme implementate includ componente care preced conformitatea FMN sau care au fost integrate fără conștientizarea etichetelor – relee de mesaje vechi, routere CoT neconforme, middleware de baze de date care elimină metadatele la inserare. Fiecare astfel de componentă reprezintă un potențial punct de pierdere a etichetei care trebuie identificat și atenuat în proiectarea sistemului.

Mitigarea standard pentru riscul de pierdere a etichetei este utilizarea legării prin aserțiune în loc de legarea prin încapsulare pentru datele care traversează infrastructura neîncredere. Deoarece aserțiunea face parte din corpul încărcăturii utile, mai degrabă decât un antet de transport, ea supraviețuiește tranzitului prin componente care elimină sau rescriu anteturile de mesaje. La capătul receptor, verificarea legării prin aserțiune confirmă că eticheta este autentică și intactă, chiar dacă metadatele de transport au fost modificate în tranzit.

Pentru sistemele care trebuie să se alinieze mai larg cu standardele de interoperabilitate NATO, testarea păstrării etichetelor ar trebui integrată în planul de testare a interoperabilității CWIX ca un obiectiv de testare de prim rang, nu ca o adăugare în etapă târzie. Un sistem care trece toate testele funcționale de interoperabilitate, dar elimină în mod silențios etichetele în tranzit, va eșua la revizuirea de acreditare de securitate chiar dacă nu eșuează niciodată la un singur test funcțional. Suita de testare a păstrării etichetelor trebuie să injecteze obiecte cu etichete cunoscute la fiecare punct de intrare, să capteze și să inspecteze obiectele la fiecare punct de ieșire și să verifice că atât conținutul etichetei, cât și semnătura de legare sunt identice între injectare și recepție.

Aplicați etichetele de confidențialitate în fluxurile de date ale coaliției dvs.

Interoperability Dashboard oferă vizibilitate în timp real asupra conformității etichetelor, verificării legării și aplicării politicii în schimbul de date federat – construit pentru complexitatea de clasificare a mediilor C2 multinaționale unde conformitatea STANAG 4774/4778 trebuie să fie demonstrabilă acreditatorilor.

Explorați Interoperability Dashboard → Rezervați o sesiune de informare

Această analiză a fost pregătită de ingineri Corvus Intelligence care construiesc sisteme de interoperabilitate și securitate a datelor critice pentru misiune destinate organizațiilor de apărare și guvernamentale. Aflați despre echipa noastră →