Ghid de Implementare a Interoperabilității NATO, Partea 3: Clasificarea și Releasabilitatea STANAG 4774/4778

Legăturile de date din Partea 2 mișcă mesaje. Mașinăria de clasificare și releasabilitate decide care mesaje se mișcă la cine. STANAG 4774 definește formatul pentru etichetele de confidențialitate; STANAG 4778 definește legarea criptografică care previne detașarea etichetelor de datele pe care le etichetează. Împreună ele sunt fundația tehnică a tuturor partajărilor de date în coaliția NATO. O platformă care le face corect se implementează în rețele clasificate; o platformă care le tratează ca o mască UI eșuează acreditarea în primul ciclu de revizuire. Partea 3 acoperă disciplina de implementare.

Cadrul la nivel pillar se află în Ghidul Complet al Interoperabilității NATO; tiparele mai largi de partajare în coaliție în Provocările Partajării Datelor în Coaliție; fundațiile RBAC în Controlul Accesului Bazat pe Roluri în Sistemele C2 de Apărare; propagarea din partea fuziunii în Construirea unui Pipeline de Fuziune pentru Apărare, Partea 3.

Pasul 1: Etichetele Sunt Date Structurate, Nu Șiruri

Cel mai comun eșec de implementare este tratarea clasificării ca un câmp de șir — „SECRET", „NATO RESTRICȚIONAT" — atașat la înregistrările de date. Modelul STANAG 4774 este mai bogat și structural diferit.

O etichetă de confidențialitate STANAG 4774 este un obiect structurat cu:

• Identificator de politică. Politica de clasificare sub care a fost atribuită eticheta (NATO, națională, FVEY, UE). O politică definește nivelurile valide de clasificare și compartimentele.
• Nivel de clasificare. O valoare ordonată în cadrul politicii — pentru NATO: NECLASIFICAT, RESTRICȚIONAT, CONFIDENȚIAL, SECRET, COSMIC TOP SECRET.
• Compartimente. Caveate numite care restricționează accesul — semnificative operațional, specifice programului, adesea clasificate ele însele.
• Etichete de releasabilitate. Căror națiuni sau organizații li se pot transmite datele etichetate — FVEY, REL TO NATO, REL TO națiuni specifice.
• Caveate. Restricții suplimentare (NOFORN, ORCON, altele în funcție de politică).
• Originator. Entitatea producătoare, pentru audit și responsabilitate.
• Marcaj temporal de creare. Când a fost atribuită eticheta.

Implementați acestea ca tipuri structurate cu validare. Un șir „SECRET REL FVEY" parsat la rulare prin potrivire de șiruri este tiparul ingineresc care eșuează acreditarea. Tipurile structurate, validate prin schemă la fiecare limită, sunt tiparul care trece.

Pasul 2: Legarea Criptografică STANAG 4778

STANAG 4778 definește legarea criptografică care asigură că o etichetă nu poate fi detașată de datele pe care le etichetează. Legarea este calculată de producător și verificată de fiecare consumator; fără verificare, eticheta poate fi eliminată, schimbată sau manipulată.

Tiparul de implementare:

Calculați legarea la serviciul producător. Când un adaptor, serviciu de fuziune sau altă componentă produce date, calculează legarea peste tuplul (etichetă, date) folosind cheia sa de semnare. Cheia este ancorată într-un magazin de încredere cu rădăcini hardware; operația de semnare este logată.

Verificați la fiecare citire. Consumatorii (COP-ul, analizele downstream, gateway-urile externe API) verifică legarea înainte de propagarea datelor. Eșecurile de verificare sunt logare puternic și datele sunt respinse — nu degradate tăcut.

Păstrați legarea prin serializări. Când datele curg pe bus-ul de mesaje, la baza de date, prin fir la un partener de coaliție, legarea se mișcă cu ea. Formatele de stocare acomodează legarea; protocoalele de comunicare o poartă. Eliminarea pentru „comoditate" este genul de scurtătură pe care evaluatorii de acreditare îl caută specific.

Legare per atribut unde este necesar. Unele obiecte de date au atribute la clasificări diferite. O urmărire poate avea poziție NECLASIFICATĂ dar identitate SECRET. STANAG 4778 acomodează legarea per atribut; platforma o implementează unde modelul de clasificare o necesită.

Pasul 3: Propagarea Clasificării Prin Fuziune și Derivare

Platformele de apărare produc date derivate. O urmărire este derivată din mai multe observații sursă; un produs fuzionat este derivat din mai multe rapoarte de informații. Clasificarea datelor derivate este calculată din clasificarea surselor — nu atribuită independent.

Regulile de propagare (recapitulare din seria de fuziune și pillar):

• Nivel de clasificare: maxim. O derivare din surse SECRET și NECLASIFICAT este SECRET.
• Compartimente: uniune. O derivare din surse compartiment-A și compartiment-B poartă ambele compartimente.
• Releasabilitate: intersecție. O derivare din surse numai FVEY și numai NATO este releasabilă numai la intersecție.
• Caveate: cele mai restrictive. NOFORN pe orice sursă face derivarea NOFORN.

Regulile sunt mecanice. Implementați-le ca o bibliotecă pe care fiecare serviciu de fuziune, adaptor și punct de derivare o apelează. Propagarea hand-rolled per serviciu deviază și produce inconsistențe pe care evaluatorii de acreditare le prind. O bibliotecă partajată, generată din cod pe care fiecare componentă o folosește este disciplina care scalează.

Pasul 4: Motorul de Politici

Etichetele pe date sunt necesare dar nu suficiente. Deciziile de acces necesită un motor de politici care cunoaște autorizarea utilizatorului, cetățenia, rolul și clasificarea, compartimentele și releasabilitatea datelor solicitate. Fiecare interogare față de platformă trece prin acest motor.

Tiparul de implementare:

Politica ca cod. Regulile de releasabilitate exprimate într-un limbaj de politici versionizat. Rego al Open Policy Agent este implicit-ul defensibil; alternative precum Cedar sau DSL-uri hand-rolled există dar introduc overhead de mentenanță. Modificările de politică curg prin revizuirea codului, nu modificări de configurație.

Evaluarea deciziei la limita interogării. Când un consumator interoghează platforma, motorul de politici evaluează care înregistrări sunt vizibile și care atribute sunt vizibile per înregistrare. Rezultatul este o vedere filtrată, calculată la momentul interogării. Filtrarea numai în UI — trimiterea datelor complete la client și ascunderea cu CSS sau JavaScript — este o violare Common Criteria și un eșec imediat de acreditare.

Jurnal de audit per decizie. Fiecare decizie de acces — utilizator, date solicitate, clasificare, rezultat — este logat imutabil. Jurnalul de audit este baza de dovezi pentru revizuire post-acțiune, analiză forensică și revizuire periodică de acreditare.

Bugete de performanță. Motorul de politici se află pe calea critică COP. Latența deciziei trebuie să fie sub milisecundă. Strategii de caching, pachete de politici pre-compilate, amprente de politici per utilizator — toate contează. Un motor de politici naiv este cea mai comună cauză a lentoarei COP în implementările clasificate.

Decizii per atribut unde este necesar. Motorul evaluează nu numai dacă o înregistrare este vizibilă, ci care dintre atributele sale sunt. O urmărire ar putea fi vizibilă unui utilizator de coaliție cu poziția eliberată dar identitatea reținută.

Pasul 5: Fluxuri de Date Cross-Enclave

Rețelele de apărare nu sunt enclave singulare. O platformă care operează în rețelele NATO RESTRICȚIONAT, NATO SECRET și clasificate naționale trebuie să mute datele adecvate între ele prevenind fluxurile inadecvate.

Tiparele:

Instanțe de platformă per enclavă. Fiecare enclavă clasificată rulează propria instanță de platformă cu propriul magazin de date, motor de politici și jurnal de audit. Instanțele sunt fizic separate; platforma nu presupune că împart stare.

Punți cross-domain. Unde datele se mișcă legitim între enclave — AIS NECLASIFICAT care curge în sus la o enclavă SECRET, produs scrubbat de releasabilitate care curge în jos la o enclavă de coaliție — mișcarea trece printr-o soluție cross-domain acreditată. Puntea aplică regulile de clasificare la limită.

Diode unidirecționale unde este necesar. Pentru mișcarea datelor de la înalt la jos, diodele de date unidirecționale aplică direcția la stratul de rețea. Platforma se integrează cu infrastructura de diodă mai degrabă decât să o implementeze propria.

Eliberare manuală unde automatizarea nu poate ajunge. Unele decizii de clasificare nu pot fi automatizate în siguranță. Eliberarea per produs a datelor HUMINT sau compartimentate poate necesita aprobarea umană. Platforma surfasează candidatul, capturează decizia umană cu atribuire și propagă eliberarea aprobată cu audit.

Tratarea inginerească detaliată a partajării datelor în coaliție se află în Provocările Partajării Datelor în Coaliție.

Pasul 6: Releasabilitate Specifică Coaliției

Diferite coaliții au reguli diferite de releasabilitate. Platforma care dorește să se implementeze în mai multe contexte de coaliție trebuie să acomodeze:

Releasabilitatea NATO. Setul standard de niveluri de clasificare NATO și marcajul REL TO NATO. Cele mai multe platforme operaționale vizează mai întâi această linie de bază.

Numai FVEY. Aranjamentul de partajare a informațiilor Five Eyes (AUS, CAN, NZ, UK, SUA) folosește politici de clasificare care nu se mapează curat la nivelurile NATO. O platformă vizând contextele FVEY implementează politica FVEY alături de NATO.

Aranjamente bilaterale. Multe platforme au aranjamente bilaterale de partajare a datelor cu parteneri specifici. Ucraina, Israel, Coreea, Japonia au toate aranjamente specifice programului. Motorul de releasabilitate le acomodează ca marcaje specifice REL TO plus acces compartiment specific partenerului.

Releasabilitate UE. Programele finanțate de UE au propria politică de clasificare (EU CONFIDENTIAL, EU SECRET) care nu colapsează la nivelurile NATO. Platformele finanțate EDF trebuie să acomodeze atât clasificarea NATO cât și UE.

Disciplina: implementați un motor de clasificare multi-politică, nu o singură politică. Motorul cunoaște despre NATO, FVEY, UE și politicile bilaterale ca entități numite; datele poartă politica sub care au fost clasificate; motorul de politici evaluează accesul față de autorizarea utilizatorului sub fiecare politică aplicabilă.

Pasul 7: Generarea Dovezilor de Acreditare

Evaluatorii de acreditare nu vor lua cuvântul platformei pentru nimic din aceasta. Vor cere dovezi. Dovezile sunt generate ca efect secundar al mașinăriei de clasificare corect inginerizate.

Dovezile pe care evaluatorii de acreditare le găsesc credibile:

• Referințe de cod arătând unde sunt implementate regulile de propagare a clasificării, cu trasabilitate de la politică la cod.
• Mostre din jurnalul de audit demonstrând logarea per decizie pe spectrul scenariilor de acces.
• Rezultate testare din suita de testare automatizată a platformei acoperind propagarea clasificării, filtrarea releasabilității și verificarea legării sub intrări adversariale.
• Dovezi de implementare operațională — luni sau ani de operare în producție cu răspuns documentat la incidente, prevenirea scurgerii clasificării și treceri de revizuire periodică de acreditare.
• Jurnale de transfer cross-domain demonstrând că mișcarea între enclave a fost justificată, aprobată și înregistrată.
• Rapoarte de testare penetrare din exerciții red-team vizând specific mașinăria de clasificare.

Disciplina DevSecOps care generează automat aceste dovezi este acoperită în DevSecOps pentru Conductele de Apărare. Cadrele de acreditare suportive (ISO 27001, AQAP-2110, NIST) sunt acoperite în ISO 27001 în Software-ul de Apărare și NATO AQAP-2110 pentru Furnizorii de Software.

Ce Urmează

Partea 3 a implementat mașinăria de clasificare. Etichetele STANAG 4774 ca date structurate, legarea STANAG 4778 verificată la fiecare limită, propagarea prin fuziune și derivare, motorul de politici care aplică releasabilitatea la momentul interogării, fluxurile cross-enclave acomodate, releasabilitatea multi-coaliție suportată, generarea dovezilor integrată.

Partea 4 închide seria cu disciplinele de validare și achiziție: testarea conformității, pregătirea CWIX, calea de conformitate FMN, acreditarea națională și disciplina de mentenanță pe termen lung care menține platforma implementabilă pe parcursul ciclurilor de viață operaționale de mai mulți ani.