Microsegmentare zero trust pentru rețelele de apărare: politică și aplicare

Securitatea perimetrală a fost construită în jurul unei presupuneri simple: traficul care provine din interiorul graniței putea fi considerat de încredere. Într-o rețea de apărare această presupunere nu a fost niciodată pe deplin valabilă, iar într-un mediu modern de cloud hibrid sau cu mai multe enclave este de nesusținut din punct de vedere arhitectural. Atacatorul care a compromis un singur punct final sau a furat credențiale de serviciu nu se oprește la perimetru – se deplasează lateral, escaladând de la sarcini de lucru de valoare scăzută către ținte de valoare mare. Microsegmentarea în cadrul unei arhitecturi zero trust este controlul care limitează mișcarea laterală la singura sarcină de lucru compromisă, în loc de întreaga enclavă. Acest articol examinează cum să proiectați, aplicați și mențineți politica de microsegmentare bazată pe identitate în rețelele de apărare, cu atenție specifică acordată sarcinilor de lucru găzduite pe Kubernetes, aprovizionării identității sarcinilor de lucru și mecanismelor de aplicare est-vest.

De ce eșuează controalele exclusiv perimetrale în mediile de apărare

Securitatea de rețea tradițională în mediile de apărare se bazează pe segmentare fizică și logică la o granularitate mare: rețele separate pentru diferite niveluri de clasificare, granițe VLAN între zonele funcționale și reguli de firewall la perimetrul fiecărui segment. Acest model are două slăbiciuni structurale pe care microsegmentarea este concepută să le abordeze.

Trafic est-vest plat. În interiorul unui VLAN sau al unei subrețele, sarcinile de lucru comunică de obicei fără restricții. Un server de aplicații compromis poate ajunge la baza de date, la serviciul de autentificare, la sistemul de gestionare a cheilor și la orice alt serviciu din aceeași subrețea – nu pentru că există o politică care permite acest lucru, ci pentru că nu există o politică care să-l interzică. Costul mișcării laterale a atacatorului în interiorul unui segment plat este scăzut.

Compromiterea bazată pe credențiale traversează perimetrele. Firewall-urile perimetrale inspectează anteturile pachetelor, nu identitatea sarcinii de lucru. Un token de cont de serviciu sau un certificat furat care era valid pentru comunicarea între două servicii este la fel de valid pentru comunicarea din procesul atacatorului care rulează ca acel serviciu. Firewall-ul permite traficul deoarece provine de la adresa IP sursă corectă. Microsegmentarea cu identitate criptografică a sarcinii de lucru abordează acest lucru: principalul politicii nu este o adresă IP, ci o identitate de sarcină de lucru atestată criptografic pe care atacatorul nu o poate imita fără acces la materialul cheii private – care este efemer și legat de sarcina de lucru.

Arhitectura de microsegmentare: domenii de încredere și granițe de politică

Un design de microsegmentare pentru o rețea de apărare începe cu cartografierea fluxurilor de comunicare și gruparea sarcinilor de lucru în domenii de încredere. Un domeniu de încredere este un set de sarcini de lucru care împărtășesc o graniță de autorizare comună și comunică liber în cadrul grupului, dar care necesită o politică explicită pentru a comunica în afara acestuia. Într-un context de apărare, granițele naturale ale domeniilor de încredere se aliniază atât cu nivelul de clasificare, cât și cu rolul funcțional.

Pentru o aplicație de apărare tipică găzduită pe un cluster Kubernetes clasificat, domeniile de încredere ar putea fi:

Domenii la nivel de clasificare. Fiecare enclavă de clasificare – neclasificat, CUI, SECRET – este un domeniu de încredere separat. Nicio comunicare est-vest nu traversează granițele de clasificare în cadrul planului de microsegmentare. Comunicarea inter-domenii este direcționată exclusiv printr-o soluție cross-domain acreditată care efectuează inspecția conținutului și reetichetarea.

Domenii de rol funcțional în cadrul unui nivel de clasificare. În cadrul enclavei SECRET, o segmentare suplimentară după funcție: servicii de ingestie (care acceptă date de la senzori externi), servicii de procesare (analitică și îmbogățire), servicii de stocare (baze de date și depozite de obiecte), servicii command-plane (orchestrare și planificare) și servicii de audit (înregistrare imuabilă). Fiecare domeniu funcțional poate primi trafic doar de la domeniile partenere specifice ale căror fluxuri de comunicare sunt documentate și aprobate de politică.

Harta fluxurilor de comunicare care rezultă din acest exercițiu – fiecare domeniu sursă, domeniu destinație, port și protocol justificat de afaceri – devine intrarea autoritativă pentru elaborarea politicii. Orice flux care nu se află pe hartă este refuzat în mod implicit.

Identitatea sarcinii de lucru: SPIFFE/SPIRE în medii Kubernetes

Microsegmentarea bazată pe identitate necesită ca fiecare sarcină de lucru să posede o identitate verificabilă pe care planul de aplicare a politicii o poate autentifica. Identitatea bazată pe adresa IP este insuficientă în mediile dinamice de containere unde podurile sunt efemere și IP-urile sunt reciclate. Standardul SPIFFE (Secure Production Identity Framework For Everyone) definește un model portabil, criptografic de identitate a sarcinii de lucru, independent de infrastructura subiacentă.

Identitatea SPIFFE este exprimată ca un URI: spiffe://trust-domain/path. Într-o implementare Kubernetes care folosește SPIRE (implementarea de referință a SPIFFE), fiecare pod primește un SVID X.509 (SPIFFE Verifiable Identity Document) – un certificat de scurtă durată care conține identitatea sa SPIFFE ca Subject Alternative Name. Domeniul de încredere corespunde clusterului Kubernetes sau graniței de federație. Calea codifică spațiul de nume Kubernetes și contul de serviciu, de ex. spiffe://defense.cluster/ns/analytics/sa/enrichment-worker.

Proprietatea critică pentru implementările de apărare este TTL-ul scurt. SVID-urile sunt emise cu o durată de viață de 1 oră (sau mai puțin, configurabilă) și rotite automat de agentul SPIRE care rulează pe fiecare nod. Dacă un certificat este compromis, fereastra de expunere este limitată de TTL. Cheia privată nu părăsește niciodată memoria sarcinii de lucru – nu este scrisă pe disc și nu este accesibilă altor procese de pe același nod, chiar și într-un context de cluster Kubernetes partajat.

Atestarea nodului în clustere clasificate

Atestatorul de nod al SPIRE este mecanismul prin care un nod nou care se alătură clusterului își dovedește identitatea înainte de a i se permite să emită SVID-uri sarcinilor de lucru. Într-un mediu Kubernetes clasificat, atestatorul de nod trebuie ales pentru a se potrivi modelului de încredere. Pentru hardware-ul clasificat on-premises, atestarea bazată pe TPM – folosind modulul Trusted Platform Module al nodului pentru a dovedi identitatea hardware – este modelul preferat. Serverul SPIRE validează cheia de endorsement TPM în raport cu un manifest cunoscut ca fiind bun înainte de a autoriza nodul să acționeze ca emitent de SVID. Aceasta înseamnă că un atacator care provizionează un nod neautorizat nu poate obține SVID-uri valide de la serverul SPIRE, chiar dacă are acces de rețea la serverul API al clusterului.

Aplicarea est-vest: rețeaua de servicii și eBPF

Aprovizionarea identității sarcinii de lucru este necesară, dar nu suficientă – planul de aplicare trebuie să folosească efectiv aceste identități pentru a permite sau refuza traficul. Într-un mediu Kubernetes întărit, aplicarea est-vest este de obicei stratificată pe trei mecanisme complementare.

Kubernetes NetworkPolicy: baza L3/L4

Resursele Kubernetes NetworkPolicy oferă o modalitate declarativă de a specifica ce poduri pot comunica, folosind selectoare de etichete de pod și selectoare de spațiu de nume pentru a identifica sursa și destinația. Aplicarea NetworkPolicy este gestionată de plugin-ul CNI (Container Network Interface). Limitarea cheie a NetworkPolicy standard este că operează la L3/L4 – poate permite sau refuza traficul între grupuri de poduri pe baza IP-ului și portului, dar nu poate inspecta identitatea sarcinii de lucru care stabilește conexiunea, metoda HTTP apelată sau conținutul cererii. Pentru un model de microsegmentare de apărare care necesită identitate criptografică, NetworkPolicy este o bază necesară, dar nu controlul complet.

Rețeaua de servicii cu TLS reciproc: aplicare L7 conștientă de identitate

O rețea de servicii instalată în modul TLS reciproc strict adaugă verificarea criptografică a identității fiecărei conexiuni est-vest. Fiecare apel serviciu-la-serviciu este autentificat la nivelul stratului de transport: clientul prezintă SVID-ul său, serverul prezintă SVID-ul său, și fiecare îl verifică pe celălalt în raport cu pachetul de încredere SPIFFE. Politica de autorizare a rețelei de servicii evaluează apoi principalul autentificat (identitatea SPIFFE verificată) în raport cu o regulă de politică înainte de a permite cererea.

Pentru implementările de apărare, rețeaua de servicii trebuie configurată cu biblioteci criptografice validate FIPS 140-2 sau FIPS 140-3. Atât Istio, cât și Linkerd pot fi compilate cu BoringCrypto (validat FIPS) sau echivalent. Suitele de cifrare negociate pentru mTLS trebuie restricționate la setul aprobat – TLS 1.3 cu AES-256-GCM-SHA384 ca minim pentru mediile clasificate. Lista completă a suitelor permise trebuie documentată ca parte a configurației de securitate de referință a sistemului.

Aplicarea bazată pe eBPF: politică la nivelul nucleului

Aplicarea rețelei de servicii operează la nivelul proxy-ului sidecar, care rulează în interiorul spațiului de nume de rețea al containerului. Un atacator suficient de privilegiat care poate compromite mediul de execuție al containerului sau podul însuși poate fi capabil să ocolească proxy-urile sidecar. Aplicarea de rețea bazată pe eBPF (implementată de plugin-uri CNI precum Cilium) operează sub mediul de execuție al containerului, la nivelul stivei de rețea a nucleului Linux. Programele eBPF atașate la hook-urile nucleului evaluează politica de rețea înainte ca pachetele să fie livrate oricărui proces din spațiul utilizatorului – inclusiv proxy-ului sidecar. O sarcină de lucru care ocolește proxy-ul său sidecar tot nu poate ajunge la destinații neautorizate deoarece stratul de aplicare eBPF refuză pachetul la nivelul nucleului.

Combinația dintre NetworkPolicy + mTLS-ul rețelei de servicii + aplicarea eBPF creează o stivă de microsegmentare de tip apărare în adâncime în care fiecare strat aplică politica în mod independent. O eșuare a oricărui singur strat nu duce la mișcare laterală nelimitată.

Ciclul de viață al politicii: elaborarea, testarea și menținerea regulilor de microsegmentare

Politica de microsegmentare nu este o configurație unică. Aplicațiile de apărare evoluează, sarcinile de lucru sunt adăugate și eliminate, iar tiparele de comunicare se schimbă pe măsură ce funcționalitățile sunt dezvoltate. Un model de microsegmentare care este corect la implementarea inițială se degradează în timp dacă nu este menținut activ.

Politică-ca-cod. Politica de microsegmentare ar trebui versionată alături de codul aplicației. Fiecare resursă NetworkPolicy, AuthorizationPolicy și CiliumNetworkPolicy ar trebui să se afle în depozitul de implementare al aplicației. Modificările politicii urmează același proces de revizuire și aprobare ca modificările de cod – inclusiv o revizuire de securitate pentru orice regulă care extinde o graniță de permitere. Acest lucru previne acumularea excepțiilor de firewall ad-hoc în afara controlului versiunilor.

Testare în mod umbră. Înainte de a aplica o politică nouă sau modificată în modul de aplicare, testați-o în modul umbră (doar înregistrare). Atât rețeaua de servicii, cât și planul de aplicare eBPF pot opera într-un mod de audit în care încălcările politicii sunt înregistrate, dar nu blocate. Rularea în modul umbră pentru o perioadă definită (de obicei una până la două săptămâni într-un mediu de staging care reflectă tiparele de trafic de producție) scoate la iveală fluxurile nedocumentate pe care politica le-ar bloca înainte de a cauza întreruperi de producție. Fluxurile nedocumentate descoperite în testarea umbră trebuie revizuite – fluxurile legitime declanșează adăugiri de politică, în timp ce fluxurile ilegitime sunt dovada unei probleme de securitate existente.

Detectarea automată a derivei politicii. Telemetria fluxurilor rețelei de servicii (Hubble al Istio, Viz al Linkerd) oferă o vedere în timp real a întregului trafic est-vest. Instrumentele automate care compară traficul observat cu harta fluxurilor aprobate și alertează asupra abaterilor reprezintă o cerință operațională standard pentru o implementare de microsegmentare de apărare. Fluxurile noi care apar fără o actualizare corespunzătoare a politicii sunt candidați imediați la alertă – fie aplicația s-a schimbat fără a-și actualiza documentația politicii, fie un actor neautorizat generează trafic neașteptat.

Microsegmentarea în medii cu mai multe enclave și izolate (air-gapped)

Rețelele de apărare se întind frecvent pe mai multe enclave la diferite niveluri de clasificare, dintre care unele sunt complet izolate (air-gapped) de rețelele externe. Politica de microsegmentare trebuie să fie coerentă în toate enclavele chiar și atunci când nu există un plan de gestionare partajat.

Într-un cluster clasificat air-gapped, serverul SPIRE trebuie să opereze complet on-premises. Rădăcina PKI care ancorează încrederea SVID nu se poate baza pe nicio autoritate de certificare externă. CA-ul rădăcină și CA-urile intermediare ale serverului SPIRE sunt generate și gestionate pe HSM-uri (Hardware Security Modules) izolate în cadrul mediului clasificat. Listele de revocare a certificatelor și serviciile OCSP trebuie de asemenea să opereze în cadrul izolării – apelurile de rețea către infrastructura externă pentru operațiunile PKI nu sunt permise în arhitecturile de rețea clasificate.

Coordonarea microsegmentării inter-enclave – asigurarea că o politică ce permite un flux de la enclava CUI la enclava neclasificată este oglindită în seturile de politici ale ambelor enclave – este un proces manual și auditabil în majoritatea programelor. Soluția cross-domain care mediază traficul inter-enclave este sursa autoritativă a fluxurilor permise peste graniță; politicile de microsegmentare de pe ambele părți trebuie să fie consecvente cu configurația CDS și revizuite ca o unitate în timpul controlului modificărilor politicii.