Datele clasificate au fost protejate istoric în două din cele trei stări ale lor. Criptarea în repaus le protejează pe disc; criptarea în tranzit le protejează pe fir. A treia stare – datele în utilizare, decriptate în registrele CPU și în RAM pentru a putea fi efectiv procesate – a reprezentat întotdeauna punctul vulnerabil. Orice cod cu privilegii suficiente pe gazdă, inclusiv sistemul de operare, hipervisorul și un operator cloud cu acces fizic la magistrala de memorie, poate citi acel text clar. Calculul confidențial închide acest decalaj prin rularea sarcinii de lucru într-un mediu de execuție de încredere (TEE) izolat hardware, unde CPU menține memoria criptată și ilizibilă pentru tot ceea ce se află în afara enclavei. Pentru sarcinile de lucru clasificate, aceasta schimbă în cine trebuie să se aibă încredere – iar această schimbare reprezintă întreaga esență.

Problema datelor în utilizare și modelul de amenințare al calculului confidențial

Premisa definitorie a calculului confidențial este o bază de calcul de încredere redusă. Într-o implementare cloud convențională, chiriașul este forțat să aibă încredere în întregul stiv de sub aplicație: kernelul OS invitat, hipervisorul, firmware-ul gazdei, planul de control al cloudului și persoanele care operează centrul de date. Fiecare dintre acestea reprezintă o cale spre textul clar în timp ce sarcina de lucru rulează. Pentru o sarcină de lucru Secret sau de compartiment sensibil, această suprafață de încredere este inacceptabilă.

Un TEE inversează modelul. CPU-ul însuși aplică o graniță de izolare, criptând memoria enclavei cu chei care sunt generate și reținute în modulul de securitate hardware al procesorului și nu sunt niciodată expuse software-ului. Sistemul de operare gazdă poate planifica enclava, îi poate aloca pagini și o poate opri – dar nu poate citi ce se află în interior. Un hipervisor compromis de un atacator sau un administrator rău intenționat care atașează un depanator sau descarcă memoria fizică vede doar text cifrat. Granița de încredere se reduce la două lucruri: hardware-ul furnizorului de siliciu și codul pe care îl încărcați deliberat în enclavă.

Aceasta este exact proprietatea care permite organizațiilor de apărare să contemple găzduirea sarcinilor de lucru sensibile pe infrastructuri pe care nu le controlează fizic. Nu face, prin ea însăși, o regiune comercială acreditată pentru date clasificate – aceasta necesită setul complet de controale discutate în analiza noastră despre arhitectura zero-trust pentru rețele militare – dar elimină operatorul din granița de încredere pentru datele în utilizare, ceea ce schimbă în mod semnificativ calculul riscurilor.

Medii de execuție de încredere: SGX, SEV-SNP, TDX și CCA

Există două familii arhitecturale de TEE, iar alegerea dintre ele este prima și cea mai importantă decizie de proiectare.

Enclave la nivel de proces (Intel SGX). Software Guard Extensions delimitează o regiune de memorie mică, definită de aplicație – enclava – din cadrul unui proces și o izolează de orice altceva, inclusiv de kernel. Baza de calcul de încredere este minimă: numai codul pe care îl plasați în enclavă este de încredere, nu OS-ul înconjurător. Costul este că aplicația trebuie să fie partiționată în jumătăți de încredere și neîncredere, cu o interfață de apel controlată între ele, iar memoria enclavei este restricționată. SGX este instrumentul potrivit atunci când doriți cea mai mică suprafață de atac posibilă în jurul unei rutine specifice de gestionare a secretelor – un serviciu de învelire a cheilor, un semnatar criptografic, un motor de politici mic.

Confidențialitate la nivel de VM (AMD SEV-SNP, Intel TDX, Arm CCA). Secure Encrypted Virtualization with Secure Nested Paging, Trust Domain Extensions și Arm's Confidential Compute Architecture Realms protejează toate o întreagă mașină virtuală. Memoria oaspetelui este criptată transparent și protejată ca integritate, iar hipervisorul este eliminat din granița de încredere, dar sarcina de lucru din interior rulează nemodificată. O aplicație clasificată existentă poate fi migrată într-o mașină virtuală confidențială fără nicio modificare de cod. Baza de calcul de încredere este mai mare – include întregul OS invitat – dar costul de adoptare este dramatic mai mic. Pentru majoritatea sarcinilor de lucru de apărare care sunt migrate mai degrabă decât scrise de la zero, confidențialitatea la nivel de VM este alegerea pragmatică.

SEV-SNP și TDX au adăugat o funcție pe care prima generație SGX nu o avea și care contează în mod acut pentru datele clasificate: protecția integrității memoriei, apărând împotriva unui atacator care reproduce sau remapează pagini criptate în loc să le citească pur și simplu. Orice TEE selectat pentru utilizare clasificată trebuie să ofere atât confidențialitate, cât și integritate; confidențialitatea singură lasă sarcina de lucru deschisă atacurilor active de corupție a memoriei de la gazdă.

Atestarea la distanță: dovedirea enclavei înainte de a o face de încredere

Izolarea hardware este necesară, dar nu suficientă. Partea care deține datele clasificate – sau cheia care le decriptează – are nevoie de dovada că enclava cu care urmează să comunice este hardware TEE autentic care rulează exact codul așteptat, și nu un emulator, o imagine alterată sau o platformă cu microcod retrogradat care pretinde că este sigură. Această dovadă este atestarea la distanță, iar ea este mecanismul care face calculul confidențial demn de încredere, nu doar plauzibil.

Cum funcționează un flux de atestare

Când o enclavă pornește, CPU-ul măsoară codul și configurația încărcate într-un registru hardware și, la cerere, produce un citat semnat: o structură care conține acele măsurători, numerele de versiune de securitate ale TEE-ului și o semnătură care se înlănțuie înapoi la o cheie fuzionată în siliciu la producere. Enclava trimite acest citat unui verificator – un serviciu pe care proprietarul datelor îl controlează sau în care are încredere. Verificatorul validează lanțul de semnătură până la certificatul rădăcină al furnizorului, confirmă că platforma se află pe microcodul curent, nerevocat, și compară măsurătorile raportate cu o listă de permisiuni a codului în care este dispus să aibă încredere. Numai dacă fiecare verificare trece, verificatorul autorizează pasul următor.

Disciplina de inginerie critică aici este măsurarea reproductibilă. Enclava sau imaginea invitată trebuie să fie construită determinist, astfel încât măsurătoarea sa să fie identică bit cu bit de fiecare dată, deoarece politica de atestare este o listă de permisiuni cu valori exacte de măsurătoare. O construcție nerepro­ductibilă înseamnă o măsurătoare în continuă schimbare, ceea ce îi forțează pe operatori spre păcatul cardinal de a relaxa politica până când acceptă aproape orice – anulând scopul. Tratați măsurătoarea de lansare ca un artefact de versiune, înregistrat și controlat prin versiune alături de versiunile de firmware și microcod de care depinde.

Politica de atestare ca graniță reală de securitate

Hardware-ul face criptografia, dar politica ia deciziile, iar o politică slabă anulează hardware-ul puternic. O politică de atestare de grad defensiv declară explicit: ce tipuri de TEE sunt acceptate; versiunea minimă a bazei de calcul de încredere, cu verificări ale numărului de versiune de securitate care resping microcodul retrogradat după o dezvăluire de vulnerabilitate; setul exact de măsurători de cod permise; și cerințe de prospețime pentru a preveni reproducerea unui citat vechi. Cel mai frecvent mod de eșec în implementările reale nu este o enclavă defectă – ci o politică prea permisivă care acceptă măsurători pe care nu ar trebui, sau care nu verifică niciodată starea de revocare a platformei. Atestarea este la fel de bună ca regulile pe care verificatorul le aplică.

Eliberarea cheilor: legarea secretelor de un mediu verificat

Atestarea devine operațional utilă atunci când condiționează accesul la secrete. Tiparul este eliberarea cheilor legată de atestare: serviciul de gestionare a cheilor este configurat astfel încât o cheie de criptare a datelor clasificate să fie distribuită numai după ce verificatorul confirmă o atestare reușită. Enclava solicită cheia, prezintă dovezi recente, iar KMS eliberează cheia învelită într-un canal terminat în interiorul TEE-ului, astfel încât cheia în text clar să nu existe niciodată în afara enclavei. O gazdă neatestatată, o platformă retrogradată sau o imagine alterată pur și simplu nu primește niciodată materialul de care are nevoie pentru a decripta ceva.

Aceasta inversează relația obișnuită dintre identitate și autorizare. În loc să elibereze o cheie pentru că un apelant prezintă o acreditare care ar putea fi furată, cheia este eliberată deoarece mediul de rulare și-a dovedit criptografic integritatea. Pentru sarcinile de lucru care trebuie să mute date peste granițe, aceasta se compune curat cu controalele descrise în articolul nostru despre soluții inter-domenii pentru apărare: enclava care efectuează transferul poate fi obligată să atesteze înainte de a i se încredința vreodată date de la un nivel de clasificare superior.

Perspectivă cheie: Securitatea unei implementări de calcul confidențial se află în politica de atestare, nu în funcția de siliciu. Hardware puternic cu un verificator permisiv care acceptă citate vechi, omite verificările de revocare sau nu fixează niciodată măsurători exacte de cod oferă iluzia protecției în timp ce eliberează chei mediilor pe care nu le-a verificat de fapt. Tratați verificatorul și lista sa de permisiuni ca pe cea mai sensibilă componentă din arhitectură și versionați-o la fel de atent ca și codul pe care îl atestă.

Tipare de implementare cloud pentru sarcini de lucru clasificate

Toate regiunile cloud guvernamentale majore expun acum SKU-uri de VM confidențiale bazate pe SEV-SNP sau TDX, împreună cu servicii gestionate de enclavă și atestare. Trei tipare de implementare apar recurent în programele clasificate și sensibile.

Procesare confidențială a datelor. Sarcina de lucru care atinge datele clasificate – o analiză, un motor de fuziune, un serviciu de inferență a modelului – rulează în întregime în VM-uri confidențiale. Datele ajung criptate, cheile sunt eliberate numai enclavelor atestate, iar datele decriptate există numai în memoria protejată. Acesta este tiparul de migrare directă: aplicațiile existente câștigă protecție a datelor în utilizare cu modificări minime, eliminând operatorul cloud din granița de încredere fără o re-arhitecturare.

Gestionarea confidențială a cheilor și brokering. O enclavă mică, de tip SGX, acționează ca ancoră de încredere: deține cheile de învelire, efectuează verificarea atestării pentru alte sarcini de lucru și brokerează cheile de criptare a datelor către VM-uri confidențiale atestate. Concentrarea celei mai sensibile logici într-o enclavă minimă menține mica baza de calcul de încredere pentru gestionarea cheilor chiar și atunci când sarcinile de lucru principale rulează ca VM-uri confidențiale complete.

Calcul confidențial multi-parte și de coaliție. Două organizații care nu pot partaja date brute – parteneri de coaliție sau agenții la niveluri diferite de clasificare – contribuie fiecare cu intrări criptate la o VM confidențială care calculează un rezultat comun. Deoarece nicio parte, inclusiv gazda, nu poate citi intrările celorlalți, enclava devine teren neutru. Atestarea permite fiecărui contributor să verifice exact ce cod va procesa datele sale înainte de a le elibera.

Riscuri reziduale și disciplină operațională

Calculul confidențial reduce dramatic suprafața de amenințare, dar nu o elimină. Atacurile pe canale laterale împotriva TEE-urilor sunt un domeniu activ de cercetare, iar mai multe au necesitat mitigări de microcod – motiv pentru care aplicarea numărului de versiune de securitate în politica de atestare nu este opțională. Codul enclavei în sine se află în granița de încredere, astfel încât o vulnerabilitate acolo este o vulnerabilitate în sarcina de lucru protejată; o bază de calcul de încredere minimă limitează raza de impact. Iar lanțul de aprovizionare cu siliciu este, în ultimă instanță, de încredere. Niciuna dintre acestea nu compromite modelul, dar ele definesc disciplina operațională: corecțați microcodul prompt, mențineți enclava mică, re-atestați continuu mai degrabă decât doar la lansare și înregistrați fiecare decizie de atestare în stocare imuabilă pentru audit.

Calculul confidențial este un control puternic în cadrul unei arhitecturi acreditate mai largi, nu un substitut pentru acreditare. Aparține alături de controalele de rezidență a datelor, o autorizație de operare la nivelul de impact corect, gestionarea auditată a cheilor și controalele de rețea zero-trust și inter-domenii acoperite în altă parte din această serie. Ceea ce oferă în mod unic este protecție auditabilă pentru datele în utilizare – starea care, până de curând, era pur și simplu presupusă a fi expusă.

Rulați sarcini de lucru clasificate cu integritate demonstrabilă

Corvus Quantum reunește calculul confidențial, atestarea hardware și gestionarea cheilor rezistente la cuantum pentru ca sarcinile de lucru sensibile să rămână protejate în utilizare, în memorie și în cadrul infrastructurii neîncrezătoare. Eliberarea cheilor condiționată de atestare, prin proiectare.

Explorați Corvus Quantum → Solicitați o Prezentare

Această analiză a fost pregătită de inginerii Corvus Intelligence care construiesc cloud securizat și infrastructură de misiune critică pentru organizații de apărare și guvernamentale. Aflați mai multe despre echipa noastră →