Geclassificeerde gegevens zijn historisch gezien beschermd in twee van de drie toestanden. Versleuteling in rust beschermt ze op schijf; versleuteling onderweg beschermt ze op het netwerk. De derde toestand – gegevens in gebruik, ontsleuteld in CPU-registers en RAM zodat ze daadwerkelijk verwerkt kunnen worden – is altijd de zwakke plek geweest. Elke code met voldoende rechten op de host, waaronder het besturingssysteem, de hypervisor en een cloudoperator met fysieke toegang tot de geheugenbus, kan die plaintext uitlezen. Confidential computing sluit deze kloof door de workload uit te voeren in een hardware-geïsoleerde trusted execution environment (TEE), waar de CPU het geheugen versleuteld houdt en onleesbaar maakt voor alles buiten de enclave. Voor geclassificeerde workloads verandert dit wie vertrouwd moet worden – en die verandering is het hele punt.
Het data-in-use-probleem en het dreigingsmodel van confidential computing
De bepalende premisse van confidential computing is een gereduceerde trusted computing base. Bij een conventionele cloudimplementatie is de huurder gedwongen de volledige onderliggende stack te vertrouwen: de gast-OS-kernel, de hypervisor, de hostfirmware, het cloudbeheerplatform en de mensen die het datacenter exploiteren. Elk van die onderdelen vormt een pad naar de plaintext terwijl de workload draait. Voor een Secret of gevoelig gecompartimenteerde workload is dat vertrouwensoppervlak onaanvaardbaar.
Een TEE keert het model om. De CPU zelf handhaaft een isolatiegrens, door het geheugen van de enclave te versleutelen met sleutels die worden gegenereerd en bewaard in de hardware security module van de processor en nooit aan software worden blootgesteld. Het hostbesturingssysteem kan de enclave inplannen, er pagina's aan toewijzen en hem stoppen – maar het kan niet lezen wat erin zit. Een door een aanvaller gecompromitteerde hypervisor, of een kwaadwillende beheerder die een debugger koppelt of fysiek geheugen dumpt, ziet alleen cijfertekst. De vertrouwensgrens krimpt tot twee dingen: de hardware van de siliconleverancier en de code die u bewust in de enclave laadt.
Dit is precies de eigenschap die defensieorganisaties in staat stelt gevoelige workloads te overwegen op infrastructuur die ze niet fysiek beheren. Het maakt op zichzelf een commerciële regio niet geaccrediteerd voor geclassificeerde gegevens – dat vereist de volledige set maatregelen die besproken worden in onze analyse van zero-trust-architectuur voor militaire netwerken – maar het verwijdert de operator uit de vertrouwensgrens voor gegevens in gebruik, wat de risicoberekening wezenlijk verandert.
Trusted execution environments: SGX, SEV-SNP, TDX en CCA
Er zijn twee architecturale families van TEE, en de keuze tussen beide is de eerste en meest bepalende ontwerpbeslissing.
Enclaves op procesniveau (Intel SGX). Software Guard Extensions hakt een klein, door de applicatie gedefinieerd geheugengebied – de enclave – uit een proces en isoleert het van al het andere, inclusief de kernel. De trusted computing base is minimaal: alleen de code die u in de enclave plaatst, wordt vertrouwd, niet het omringende besturingssysteem. De kostprijs is dat de applicatie moet worden opgesplitst in vertrouwde en niet-vertrouwde helften, met een gecontroleerde aanroepinterface ertussen, en enclavgeheugen is beperkt. SGX is het juiste hulpmiddel wanneer u het kleinst mogelijke aanvalsoppervlak wilt rond een specifieke geheimverwerkingsroutine – een sleutelverpakkingsservice, een cryptografische ondertekenaar, een kleine beleidsmotor.
Vertrouwelijkheid op VM-niveau (AMD SEV-SNP, Intel TDX, Arm CCA). Secure Encrypted Virtualization with Secure Nested Paging, Trust Domain Extensions en Arm's Confidential Compute Architecture Realms beschermen allemaal een volledige virtuele machine. Het geheugen van de gast is transparant versleuteld en integriteitsbeschermd, en de hypervisor is verwijderd uit de vertrouwensgrens, maar de workload erin draait ongewijzigd. Een bestaande geclassificeerde applicatie kan worden overgezet naar een confidential VM zonder codewijziging. De trusted computing base is groter – hij omvat het volledige gast-OS – maar de adoptiekosten zijn dramatisch lager. Voor de meeste defensieworkloads die worden gemigreerd in plaats van nieuw geschreven, is vertrouwelijkheid op VM-niveau de pragmatische keuze.
SEV-SNP en TDX voegden een functie toe die de eerste generatie SGX miste en die voor geclassificeerde gegevens van acuut belang is: geheugenintegriteitsbescherming, ter verdediging tegen een aanvaller die versleutelde pagina's herhaalt of hermapt in plaats van ze slechts te lezen. Elke TEE die wordt geselecteerd voor geclassificeerd gebruik moet zowel vertrouwelijkheid als integriteit bieden; vertrouwelijkheid alleen laat de workload open voor actieve geheugenmanipulatieaanvallen vanuit de host.
Remote attestation: de enclave bewijzen voordat u hem vertrouwt
Hardware-isolatie is noodzakelijk maar niet voldoende. De partij die de geclassificeerde gegevens houdt – of de sleutel die ze ontsleutelt – heeft bewijs nodig dat de enclave waarmee zij gaat communiceren echte TEE-hardware is die precies de verwachte code uitvoert, en geen emulator, een gemanipuleerde image of een platform met teruggedraaide microcode dat doet alsof het veilig is. Dat bewijs is remote attestation, en het is het mechanisme dat confidential computing betrouwbaar maakt in plaats van slechts plausibel.
Hoe een attestation-stroom werkt
Wanneer een enclave start, meet de CPU de geladen code en configuratie in een hardwareregister en produceert op verzoek een ondertekend quote: een structuur die die metingen bevat, de beveiligingsversienummers van de TEE en een handtekening die terugloopt naar een sleutel die bij de fabricage in het silicium is ingebrand. De enclave stuurt dit quote naar een verificateur – een service die de gegevenseigenaar beheert of vertrouwt. De verificateur valideert de handtekeningketen terug naar het rootcertificaat van de leverancier, bevestigt dat het platform actuele, niet-ingetrokken microcode heeft en vergelijkt de gerapporteerde metingen met een allow-list van code die hij bereid is te vertrouwen. Alleen als elke controle slaagt, autoriseert de verificateur de volgende stap.
De kritieke technische discipline hier is reproduceerbare meting. De enclave of gastimage moet deterministisch worden gebouwd zodat zijn meting elke keer bit-voor-bit identiek is, omdat het attestation-beleid een allow-list van exacte meetwaarden is. Een niet-reproduceerbare build betekent een voortdurend veranderende meting, wat operators dwingt naar de hoofdzonde van het versoepelen van het beleid totdat het bijna alles accepteert – waarmee het doel teniet wordt gedaan. Behandel de startmeting als een release-artefact, vastgelegd en versiebeheerd naast de firmware- en microcodeversies waarvan het afhankelijk is.
Attestation-beleid als de echte veiligheidsgrens
De hardware doet de cryptografie, maar het beleid neemt de beslissingen, en een zwak beleid maakt sterke hardware ongeldig. Een attestation-beleid op defensieniveau stelt expliciet: welke TEE-typen worden geaccepteerd; de minimale trusted computing base-versie, met beveiligingsversienummercontroles die teruggedraaide microcode weigeren na een kwetsbaarheidsbekendmaking; de exacte set toegestane codemetingen; en verheidssvereisten zodat een oud quote niet kan worden herhaald. De meest voorkomende faalwijze in echte implementaties is niet een defecte enclave – het is een te permissief beleid dat metingen accepteert die het niet zou mogen, of dat de intrekkingsstatus van het platform nooit controleert. Attestation is slechts zo goed als de regels die de verificateur handhaaft.
Sleutelvrijgave: geheimen binden aan een geverifieerde omgeving
Attestation wordt operationeel nuttig wanneer het toegang tot geheimen beheert. Het patroon is door attestation gebonden sleutelvrijgave: de sleutelbeheerservice is zo geconfigureerd dat een geclassificeerde gegevensversleutelingssleutel alleen wordt overhandigd nadat de verificateur een geslaagde attestation bevestigt. De enclave vraagt de sleutel op, presenteert vers bewijsmateriaal en de KMS geeft de ingepakte sleutel vrij in een kanaal dat binnen de TEE wordt beëindigd, zodat de plaintext-sleutel nooit buiten de enclave bestaat. Een niet-geattesteerde host, een gedowngrade platform of een gemanipuleerde image ontvangt eenvoudigweg nooit het materiaal dat nodig is om iets te ontsleutelen.
Dit keert de gebruikelijke relatie tussen identiteit en autorisatie om. In plaats van een sleutel vrij te geven omdat een aanroeper een credential presenteert die gestolen kan worden, wordt de sleutel vrijgegeven omdat de runtime-omgeving cryptografisch haar integriteit heeft bewezen. Voor workloads die gegevens over grenzen moeten verplaatsen, werkt dit naadloos samen met de maatregelen die worden beschreven in ons artikel over cross-domain-oplossingen voor defensie: van de enclave die de overdracht uitvoert, kan worden vereist dat hij attesteert voordat hij ooit wordt toevertrouwd met gegevens van een hoger classificatieniveau.
Kernpunt: De veiligheid van een confidential computing-implementatie schuilt in het attestation-beleid, niet in de siliciumfunctie. Sterke hardware met een permissieve verificateur die verouderde quotes accepteert, intrekkingscontroles overslaat of nooit exacte codemetingen vastlegt, biedt de schijn van bescherming terwijl hij sleutels vrijgeeft aan omgevingen die hij feitelijk niet heeft geverifieerd. Behandel de verificateur en zijn allow-list als het meest gevoelige onderdeel in de architectuur, en beheer versiebeheer even zorgvuldig als de code die het attesteert.
Cloud-implementatiepatronen voor geclassificeerde workloads
Alle grote overheidscloudregio's bieden nu confidential VM-SKU's aan op basis van SEV-SNP of TDX, plus beheerde enclave- en attestation-services. Drie implementatiepatronen komen herhaaldelijk voor bij geclassificeerde en gevoelige programma's.
Vertrouwelijke gegevensverwerking. De workload die geclassificeerde gegevens verwerkt – een analysetool, een fusie-engine, een model-inferentieservice – draait volledig in confidential VMs. Gegevens arriveren versleuteld, sleutels worden alleen vrijgegeven aan geattesteerde enclaves en de ontsleutelde gegevens bestaan alleen in beschermd geheugen. Dit is het lift-and-shift-patroon: bestaande applicaties krijgen data-in-use-bescherming met minimale wijziging, waardoor de cloudoperator uit de vertrouwensgrens wordt verwijderd zonder herarchitectering.
Vertrouwelijk sleutelbeheer en -brokering. Een kleine, SGX-stijl enclave fungeert als vertrouwensanker: hij bewaakt inpaksleutels, voert attestation-verificatie uit voor andere workloads en brokert gegevensversleutelingssleutels naar geattesteerde confidential VMs. Door de meest gevoelige logica te concentreren in een minimale enclave, blijft de trusted computing base voor sleutelverwerking klein, zelfs wanneer de bulkworkloads als volledige confidential VMs draaien.
Vertrouwelijke multi-party en coalitieberekening. Twee organisaties die geen ruwe gegevens kunnen delen – coalitiepartners of instanties op verschillende classificatieniveaus – dragen elk versleutelde invoer bij aan een confidential VM die een gezamenlijk resultaat berekent. Omdat geen enkele partij, inclusief de host, de invoer van de anderen kan lezen, wordt de enclave neutraal terrein. Attestation stelt elke bijdrager in staat precies te verifiëren welke code zijn gegevens zal verwerken voordat hij ze vrijgeeft.
Resterende risico's en operationele discipline
Confidential computing verkleint het dreigingsoppervlak drastisch maar elimineert het niet. Side-channel-aanvallen tegen TEE's zijn een actief onderzoeksgebied en verschillende hebben microcodemitigaties vereist – en dat is waarom handhaving van beveiligingsversienummers in het attestation-beleid niet optioneel is. De enclavecode zelf valt binnen de vertrouwensgrens, dus een kwetsbaarheid daar is een kwetsbaarheid in de beschermde workload; een minimale trusted computing base beperkt de explosiestraal. En de siliconleveringsketen wordt uiteindelijk vertrouwd. Geen van deze factoren weerleggen het model, maar ze definiëren de operationele discipline: patch microcode tijdig, houd de enclave klein, her-attesteer continu in plaats van alleen bij de start en log elke attestationbeslissing naar onveranderlijke opslag voor auditing.
Confidential computing is één sterke maatregel binnen een bredere geaccrediteerde architectuur, geen vervanging voor accreditatie. Het hoort thuis naast gegevensverblijf- en soevereiniteitsmaatregelen, een operatiemachtiging op het juiste impactniveau, gecontroleerd sleutelbeheer en de zero-trust-netwerken en cross-domain-maatregelen die elders in deze reeks worden behandeld. Wat het uniek biedt, is controleerbare bescherming voor gegevens in gebruik – de toestand die tot voor kort eenvoudigweg werd aangenomen blootgesteld te zijn.
Voer geclassificeerde workloads uit met aantoonbare integriteit
Corvus Quantum brengt confidential computing, hardware-attestation en kwantumbestendige sleutelbeheer samen zodat gevoelige workloads beschermd blijven in gebruik, in het geheugen en via niet-vertrouwde infrastructuur. Door attestation beheerde sleutelvrijgave, by design.
Deze analyse is opgesteld door Corvus Intelligence-ingenieurs die missionkritieke veilige cloud en infrastructuur bouwen voor defensie- en overheidsorganisaties. Lees meer over ons team →