Bulut bilişim ve sanallaştırma mimarilerinde verinin güvenliği genellikle iki temel durumda ele alınır veri depolanırken (data at rest) ve ağ üzerinden taşınırken (data in transit). Disk şifreleme teknolojileri depolanan veriyi, TLS/IPsec gibi protokoller ise ağ üzerindeki veriyi korumada uzun süredir kullanılmaktadır.

Ancak üçüncü ve kritik bir alan daha vardır: verinin işlendiği an, yani data in use.

Bir sanal makine çalışırken işletim sistemi, uygulamalar, kriptografik anahtarlar ve işlenen hassas veriler sistem belleğinde bulunur. Geleneksel sanallaştırma mimarisinde hypervisor veya host işletim sistemi, sahip olduğu yüksek ayrıcalıklar nedeniyle sanal makinenin belleğine erişebilir. Bu durum özellikle public cloud ve çok kiracılı altyapılarda önemli bir güven sınırı oluşturur. Confidential Computing, tam olarak bu problemi çözmeyi hedefler.

Intel’in Trust Domain Extensions (TDX) ve AMD’nin Secure Encrypted Virtualization (SEV) ailesi sanal makinelerin yalnızca diğer VM’lerden değil aynı zamanda onları yöneten hypervisor ve host sistemden de korunmasını amaçlayan donanım tabanlı güvenlik teknolojileridir.

Intel, TDX’i donanım tarafından izole edilen Trust Domain adı verilen sanal makineler oluşturmak için kullanırken AMD tarafında bu mimari zaman içerisinde SEV → SEV-ES → SEV-SNP şeklinde gelişmiştir. Günümüzde TDX ile güvenlik modeli açısından daha doğru karşılaştırılması gereken AMD teknolojisi SEV-SNP‘dir.

Geleneksel Sanallaştırmadaki Güven Problemi

Standart bir sanallaştırma mimarisini basitleştirerek aşağıdaki şekilde düşünebiliriz.

+----------------------------------------+
|              Virtual VM                |
|                                        |
|   Application                          |
|   Operating System                     |
|   Sensitive Data / Keys                |
+----------------------------------------+
                 |
+----------------------------------------+
|              Hypervisor                |
+----------------------------------------+
|             Host Operating System      |
+----------------------------------------+
|                 Hardware               |
+----------------------------------------+

Bu yapıda hypervisor altyapının en ayrıcalıklı bileşenlerinden biridir. Dolayısıyla teorik olarak:

• VM belleğini okuyabilir,
• VM’nin CPU durumuna erişebilir,
• bellek eşlemelerini değiştirebilir,
• VM ile fiziksel kaynaklar arasındaki iletişimi yönetebilir.

Bu nedenle geleneksel sanallaştırmada VM sahibi yalnızca fiziksel donanıma değil hypervisor’a ve altyapıyı yöneten operatöre de güvenmek zorundadır. Confidential Computing bu güven modelini değiştirmeye çalışır. Yeni yaklaşım kabaca şöyledir:

          Confidential VM
+----------------------------------+
| Application                      |
| Operating System                 |
| Sensitive Data / Keys            |
+----------------------------------+
          ↕ Protected
+==================================+
| Hardware Security Boundary       |
+==================================+
          ↕ Untrusted
+----------------------------------+
| Hypervisor / Host OS             |
+----------------------------------+
| Cloud Administrator              |
+----------------------------------+

Buradaki önemli değişiklik hypervisor’ın tamamen ortadan kaldırılması değildir. Hypervisor VM’nin CPU, bellek ve I/O kaynaklarının yönetilmesinde hâlâ görev alır. Ancak confidential computing teknolojileri, hypervisor’ın VM içerisindeki gizli verilere doğrudan erişebilmesini engellemeyi amaçlar.

AMD SEV Nedir?

AMD Secure Encrypted Virtualization (SEV), AMD EPYC işlemcilerinde bulunan bellek şifreleme yeteneklerinden yararlanarak sanal makinelerin belleğini donanım seviyesinde şifrelemek için geliştirilmiştir.

Temel fikir oldukça basittir;

Her sanal makinenin belleği kendisine ait bir şifreleme anahtarıyla korunur.

Anahtarlar donanım tarafından yönetildiğinden hypervisor’ın bu anahtarlara doğrudan erişimi bulunmaz. Böylece fiziksel DRAM içerisindeki VM verisi hypervisor açısından kullanılabilir açık veri olmaktan çıkar. Ancak AMD SEV mimarisi tek bir teknolojiden oluşmaz.

Üç önemli gelişim aşaması vardır:

AMD SEV
   │
   ├── Memory Encryption
   │
   ▼
AMD SEV-ES
   │
   ├── Memory Encryption
   ├── CPU Register Protection
   │
   ▼
AMD SEV-SNP
       ├── Memory Encryption
       ├── CPU State Protection
       ├── Memory Integrity / Ownership Protection
       └── Stronger Attestation

Bu evrim, teknolojiyi anlamak açısından oldukça önemlidir.

1. AMD SEV

İlk SEV sürümünün temel amacı VM belleğinin gizliliğini sağlamaktır. Farklı VM’ler farklı şifreleme anahtarları kullanabilir. Bellek denetleyicisi CPU ile DRAM arasındaki veri hareketlerinde şifreleme ve çözme işlemlerini gerçekleştirir. Böylece kötü niyetli veya ele geçirilmiş bir hypervisor’ın guest belleğini doğrudan okuması önemli ölçüde zorlaştırılır. Ancak ilk nesil SEV’in önemli bir sınırlaması bulunmaktadır.

Bellek şifrelenirken CPU register state aynı seviyede korunmamaktadır.

Bu eksiklik AMD SEV-ES ile ele alınmıştır.

AMD SEV-ES

SEV-ES içerisindeki ES, Encrypted State anlamına gelir. SEV-ES, SEV’in bellek şifreleme yeteneklerine ek olarak VM’nin CPU durumunu da korumayı amaçlar. Örneğin VM’den hypervisor’a geçiş gerçekleştiğinde register bilgilerinin doğrudan hypervisor tarafından görülmesi engellenir.

Dolayısıyla:

SEV
-----------------
Memory        ✓
CPU State     -

SEV-ES
-----------------
Memory        ✓
CPU State     ✓

Ancak hâlâ önemli bir problem bulunmaktadır: bellek bütünlüğü ve bellek sayfalarının sahipliği. Kötü niyetli bir hypervisor belleği doğrudan okuyamasa bile bazı bellek eşleme manipülasyonları yapabilir. Bu noktada SEV-SNP devreye girer.

AMD SEV-SNP

Secure Nested Paging (SNP), AMD SEV ailesinin güvenlik modelini önemli ölçüde güçlendiren teknolojidir. SEV-SNP yalnızca belleğin şifrelenmesine odaklanmaz aynı zamanda VM’nin kullandığı bellek sayfalarının sahipliğini ve geçerli eşlemelerini donanım seviyesinde takip eder.

Bunun merkezinde Reverse Map Table — RMP bulunur.

AMD’nin mimarisinde RMP, bellekteki sayfaların hangi güvenlik alanına veya VM’ye ait olduğunu takip eder. Amaç, hypervisor’ın bir guest physical page ile sistem physical page arasındaki eşlemeyi kötü niyetli biçimde değiştirmesini engellemektir. Basitleştirilmiş olarak:

Physical Memory
      │
      ▼
+------------------------+
| Reverse Map Table      |
|        RMP             |
+------------------------+
| Page A → VM-1          |
| Page B → VM-1          |
| Page C → Hypervisor    |
| Page D → VM-2          |
+------------------------+

CPU bir bellek erişimi gerçekleştiğinde yalnızca normal page table bilgilerine bakmaz. SNP güvenlik mekanizmaları ilgili belleğin gerçekten o VM’ye ait olup olmadığının kontrol edilmesine de katkıda bulunur. Bu yaklaşım SEV’in önceki sürümlerine göre kötü niyetli hypervisor saldırılarına karşı çok daha güçlü bir güvenlik modeli oluşturur.

Intel TDX Nedir?

Intel Trust Domain Extensions (TDX) benzer problemi Intel mimarisi üzerinde çözmek için tasarlanmış bir confidential computing teknolojisidir. TDX içerisinde korunan sanal makinelere klasik VM yerine Trust Domain — TD adı verilir. Intel’in tanımına göre bir TD’nin belleği ve CPU state’i, host VMM/hypervisor dahil TD dışındaki yazılımlardan korunacak şekilde tasarlanmıştır.

Mimarinin basitleştirilmiş görünümü şöyledir.

+--------------------------------------+
|          Trust Domain (TD)           |
|                                      |
| Application                          |
| Guest Operating System               |
| Sensitive Memory                     |
+--------------------------------------+
                 |
                 ▼
+--------------------------------------+
|          Intel TDX Module            |
|              SEAM                    |
+--------------------------------------+
                 |
+--------------------------------------+
| Hypervisor / VMM                     |
+--------------------------------------+
                 |
+--------------------------------------+
| Intel Xeon + TME-MK                  |
+--------------------------------------+

Buradaki kritik bileşenlerden biri Intel TDX Module‘dür.

SEAM ve TDX Module

Intel TDX mimarisinde Secure Arbitration Mode — SEAM adı verilen yeni bir CPU çalışma modu bulunur. Intel TDX Module bu korumalı ortamda çalışır.

TDX Module:

• Trust Domain oluşturulmasını,
• TD belleğinin yönetilmesini,
• güvenlik politikalarının uygulanmasını,
• TD giriş ve çıkış işlemlerini,
• ölçüm ve attestation süreçlerinin bazı bölümlerini kontrol eden temel güvenlik bileşenlerinden biridir. Intel, TDX Module’ü hypervisor’ın bir parçası olarak değil, güvenlik açısından hypervisor’dan ayrı ve daha yüksek güven seviyesine sahip bir bileşen olarak konumlandırır. Intel’in güncel mimari dokümantasyonunda TDX’in VMX ve TME-MK teknolojilerini SEAM ve TDX Module ile genişlettiği açıklanmaktadır.

TDX’te Bellek Nasıl Korunur?

Intel TDX’in önemli yapı taşlarından biri Intel Total Memory Encryption – Multi-Key (TME-MK) teknolojisidir. TME-MK, sistem belleğinin farklı şifreleme anahtarları kullanılarak korunabilmesini sağlar. Bir Trust Domain için kullanılan özel bellek alanları TD’ye özgü anahtarlarla korunabilir.

Kabaca:

TD-1
Memory
   │
   │ Key-1
   ▼
Encrypted DRAM


TD-2
Memory
   │
   │ Key-2
   ▼
Encrypted DRAM

Bu anahtarlar donanım tarafından yönetilir ve normal yazılım katmanlarının doğrudan erişebileceği anahtarlar değildir. Intel’in açıklamasına göre TDX/TME-MK bellek şifreleme mekanizmasında şifreleme motoru bellek alt sisteminde bulunur ve veriler DRAM’e çıkarken korunur. Ancak TDX yalnızca şifreleme yapmaz. TDX mimarisindeki Secure EPT, PAMT (Physical Address Metadata Table) ve diğer donanım kontrolleri özel TD belleğinin yönetimini ve izolasyonunu güçlendirmek için birlikte çalışır. Intel’in güncel dokümantasyonu Secure EPT, PAMT, TME-MK, SEAM ve remote attestation’ı TDX mimarisinin temel bileşenleri arasında tanımlar.

Private ve Shared Memory Kavramı

Confidential VM teknolojilerinde kritik noktalardan biri, VM belleğinin tamamının her zaman hypervisor’dan gizlenemeyeceğidir. Bunun nedeni I/O işlemleridir. Örneğin bir sanal ağ kartının veya sanal disk cihazının hypervisor ile veri paylaşması gerekebilir. Bu nedenle confidential VM dünyasında genellikle iki bellek tipi bulunur:

                 Guest VM
                    │
          ┌─────────┴─────────┐
          │                   │
          ▼                   ▼
     Private Memory       Shared Memory
          │                   │
   Hypervisor erişemez   Hypervisor erişebilir

TDX içerisinde guest physical address yapısındaki özel bir shared bit, belleğin private veya shared olarak kullanılmasına yardımcı olur. Benzer mantık AMD SEV-SNP mimarisinde de bulunmaktadır. Bu nedenle confidential computing kullanırken:

“VM içerisindeki her byte hypervisor’dan otomatik olarak gizlidir.”

şeklinde düşünmek doğru değildir. Guest işletim sisteminin private/shared memory yönetimini doğru gerçekleştirmesi kritik öneme sahiptir.

Hypervisor Artık Güvenilir Değil mi?

TDX ve SEV-SNP’nin en önemli mimari değişikliklerinden biri tam olarak budur.

Geleneksel model:

Application
    │
Operating System
    │
Hypervisor      ← TRUSTED
    │
Hardware

Confidential Computing modeli:

Application
    │
Guest OS
    │
Hardware TEE
====================
Hypervisor      ← UNTRUSTED
Host OS         ← UNTRUSTED
Cloud Admin     ← UNTRUSTED

Buradaki untrusted, hypervisor’ın sistemden kaldırıldığı veya hiçbir şey yapamadığı anlamına gelmez.

Hypervisor hâlâ:

• CPU scheduling,
• I/O,
• VM lifecycle,
• kaynak tahsisi,
• bazı interrupt ve virtualization operasyonları

gibi görevleri yönetir. Ancak confidentiality ve integrity açısından guest artık hypervisor’a mümkün olduğunca az güvenecek şekilde tasarlanır. Linux TDX dokümantasyonu da bu farkın operasyonel sonuçlarını açıkça gösterir: host doğrudan guest register’larına veya private belleğine erişemediği için geleneksel olarak hypervisor tarafından yapılan bazı işlemlerin guest tarafında ele alınması gerekir. TDX bunun için örneğin #VE – Virtualization Exception mekanizmasını kullanır.

Remote Attestation Neden Bu Kadar Önemli?

Bellek şifreleme confidential computing’in yalnızca bir bölümüdür. Asıl kritik özelliklerden biri Remote Attestation‘dır. Attestation’ın cevaplamaya çalıştığı soru şudur:

“Göndereceğim hassas verinin gerçekten beklediğim güvenli ortam içerisinde çalıştığını nasıl doğrulayabilirim?”

Örneğin şirketinizin dışındaki bir cloud ortamında confidential VM oluşturduğunuzu düşünelim. VM’ye bir şifreleme anahtarı göndermeden önce aşağıdakileri doğrulamak isteyebilirsiniz:

Bu gerçekten desteklenen bir CPU mu?
              ↓
Confidential Computing aktif mi?
              ↓
VM beklediğim şekilde başlatılmış mı?
              ↓
Güvenlik politikaları doğru mu?
              ↓
TCB seviyesi kabul ettiğim seviyede mi?
              ↓
        EVET
              ↓
KMS → Secret / Key Release

Attestation süreci bu güven zincirini oluşturmaya yardımcı olur.

Intel TDX Attestation

TDX içerisinde guest, TDREPORT adı verilen yerel bir rapor oluşturabilir. Bu ölçüm verileri daha sonra doğrulanabilir bir attestation kanıtının oluşturulmasında kullanılabilir. Linux tarafında /dev/tdx-guest arayüzü üzerinden TDX guest attestation yazılımlarının TDREPORT elde edebilmesi için ilgili API’ler bulunmaktadır. Attestation sonrasında bir Key Management Service (KMS) veya Key Broker Service (KBS) örneğin şu politikayı uygulayabilir:

IF
    Platform = Genuine TDX
AND TCB >= Approved Version
AND VM Measurement = Expected Measurement
THEN
    Release Secret
ELSE
    Reject

Bu yaklaşım özellikle Zero Trust, BYOK ve hassas AI/ML iş yüklerinde oldukça değerlidir.

AMD SEV-SNP Attestation

SEV-SNP de guest’in platform hakkında doğrulanabilir bir attestation report almasına izin verir. Linux içerisindeki SEV guest API’sinde örneğin SNP_GET_REPORT çağrısı kullanılarak SEV-SNP firmware’inden attestation report alınabilir. AMD tarafında doğrulama zincirinde VCEK — Versioned Chip Endorsement Key gibi mekanizmalar kullanılabilir. Attestation raporunun amacı yalnızca “Bu AMD işlemcidir” demek değildir. Rapor içerisinde güvenlik politikaları, measurement ve TCB ile ilişkili bilgilerin doğrulanması sayesinde workload sahibi VM’ye hassas veri göndermeden önce platform hakkında karar verebilir.

Intel TDX ve AMD SEV-SNP Karşılaştırması

Her iki teknoloji de aynı temel probleme yaklaşmaktadır: Cloud altyapısının tamamına güvenmek zorunda kalmadan VM içerisindeki hassas verileri çalıştırabilmek. Ancak mimari uygulamaları farklıdır.

Özellik	Intel TDX	AMD SEV-SNP
Koruma modeli	VM seviyesinde TEE	VM seviyesinde TEE
Korunan VM	Trust Domain (TD)	SEV-SNP Guest
Bellek şifreleme	TME-MK tabanlı	AMD memory encryption
Hypervisor’dan bellek gizliliği	Evet	Evet
CPU state koruması	Evet	Evet
Bellek sahipliği/bütünlük kontrolleri	Secure EPT, PAMT ve TDX kontrolleri	RMP ve Page Validation
Remote Attestation	Evet	Evet
Hypervisor güven modeli	Güvenilmeyen bileşen	Güvenilmeyen bileşen
Guest–host iletişimi	TDCALL / #VE vb.	GHCB / #VC vb.
Temel kullanım alanı	Confidential VM	Confidential VM

Dolayısıyla;

Intel TDX  ≈  AMD SEV-SNP

şeklindeki karşılaştırma kavramsal olarak anlamlıdır.

Ancak:

Intel TDX ≠ İlk nesil AMD SEV

çünkü SEV-SNP, ilk SEV sürümüne göre CPU state, memory integrity/ownership ve attestation açısından çok daha gelişmiş bir güvenlik modeli sunmaktadır.

Confidential Computing Ne Tür Saldırılara Karşı Koruma Sağlar?

TDX ve SEV-SNP özellikle aşağıdaki tehdit modellerinde anlamlıdır:

Kötü niyetli veya ele geçirilmiş hypervisor

Hypervisor’ın guest private belleğini doğrudan okuyabilmesi engellenmeye çalışılır.

Host işletim sisteminin ele geçirilmesi

Host OS’nin yüksek yetkileri tek başına confidential VM’nin gizli belleğine erişmek için yeterli olmamalıdır.

Cloud yöneticilerinden kaynaklanan riskler

Cloud administrator’ın altyapı yönetim yetkisine sahip olması, otomatik olarak guest içerisindeki hassas verilere erişebilmesi anlamına gelmez.

Fiziksel bellek saldırıları

Bellek verisinin şifrelenmesi DRAM üzerinde açık halde bulunan veriye yönelik bazı fiziksel saldırılara karşı da koruma sağlar.

TDX ve SEV-SNP Her Şeyi Çözer mi?

Hayır.

Confidential Computing’in neyi korumadığını anlamak, neyi koruduğunu anlamak kadar önemlidir.

Örneğin TDX veya SEV-SNP kullanılması:

• guest işletim sistemindeki güvenlik açığını düzeltmez,
• uygulamadaki SQL Injection veya RCE açığını engellemez,
• yanlış yapılandırılmış bir servisi güvenli hale getirmez,
• çalınmış uygulama kimlik bilgilerini otomatik olarak korumaz,
• kötü amaçlı yazılım guest içerisinde çalışmaya başlamışsa bunu otomatik olarak ortadan kaldırmaz.

Ayrıca kötü niyetli host bazı durumlarda sistemi çalıştırmayabilir veya kaynakları kesebilir.

Başka bir ifadeyle:

Confidentiality       ✓
Integrity             ✓ / güçlü koruma
Attestation           ✓

Availability          ✗ garanti edilmez
Application Security  ✗ yerine geçmez

Kötü niyetli hypervisor VM’yi kapatabilir, CPU vermeyebilir veya network bağlantısını kesebilir.

Dolayısıyla confidential computing teknolojileri genel olarak availability probleminden ziyade confidentiality ve integrity problemlerine odaklanır.

Attestation da Tek Başına Yeterli Değildir

Bir başka önemli nokta ise attestation’ın doğru yorumlanmasıdır.

Bir VM’nin güvenli biçimde başlatıldığının ölçülmesi:

Boot Measurement = Trusted

olabilir. Ancak VM çalışmaya başladıktan sonra uygulamada bir açık kullanılarak sistem ele geçirilirse ilk boot measurement tek başına bunu göstermeyebilir. Bu nedenle yüksek güvenlik gerektiren ortamlarda:

• measured boot,
• TPM/vTPM,
• runtime integrity measurement,
• workload identity,
• secret management,
• attestation policy

gibi mekanizmaların birlikte kullanılması gerekir. Intel de TDX ortamlarında runtime integrity measurement için Linux IMA – Integrity Measurement Architecture gibi mekanizmaların attestation süreçleriyle birlikte kullanılabildiğini açıklamaktadır.

En Büyük Kullanım Alanlarından Biri: Secret Release

Confidential Computing’in pratikteki en güçlü kullanım modellerinden biri attestation tabanlı secret release mimarisidir.

Örneğin:

             Confidential VM
                    │
                    │ Attestation Evidence
                    ▼
             Attestation Service
                    │
                    │ Verification
                    ▼
              Policy Engine
                    │
       ┌────────────┴────────────┐
       │                         │
    Trusted                   Untrusted
       │                         │
       ▼                         ▼
 Release Secret             Reject Request
       │
       ▼
      KMS

Bu modelde cloud provider’ın VM’yi başlatabilmesi, VM içerisindeki hassas anahtarlara erişebileceği anlamına gelmez. KMS ancak doğru ölçüm, doğru platform ve kabul edilen TCB seviyesi doğrulandığında anahtarı workload’a verir.

Bu yapı:

• veri tabanı şifreleme anahtarları,
• TLS private key’leri,
• API secret’ları,
• yapay zekâ modelleri,
• hassas algoritmalar,
• veri şifreleme anahtarları için güçlü bir güven modeli oluşturabilir.

AI Çağında TDX ve SEV-SNP Neden Daha Önemli Hale Geliyor?

Confidential Computing teknolojilerinin önemi özellikle AI iş yüklerinin yaygınlaşmasıyla daha da artmaktadır. Bir yapay zekâ sistemi çalıştırılırken korunması gereken üç farklı fikrî veya kurumsal varlık bulunabilir:

             AI Workload
                  │
     ┌────────────┼────────────┐
     │            │            │
     ▼            ▼            ▼
 Training      AI Model      Customer
   Data        Weights         Data

Örneğin bir şirket kendi hassas verisini üçüncü taraf cloud ortamındaki bir AI modeline göndermek isteyebilir. Başka bir senaryoda ise model sağlayıcısı milyarlarca dolar değerindeki model ağırlıklarının cloud operatörü tarafından görülmesini istemeyebilir. Confidential VM yaklaşımı bu iki taraf arasındaki güven problemini azaltabilecek önemli teknolojilerden biridir. Bu nedenle confidential computing; yalnızca klasik sanal makine güvenliği açısından değil, Confidential AI mimarilerinin oluşturulması açısından da giderek daha önemli hale gelmektedir.

Intel TDX ve AMD SEV-SNP, sanallaştırma güvenliğinde oldukça önemli bir paradigma değişimini temsil etmektedir.

Geleneksel sanallaştırma mimarisinde:

Hypervisor güven sınırının içerisindedir.

Confidential Computing mimarisinde ise temel hedef:

Hypervisor’ı güven sınırının dışına çıkarmaktır.

Intel bunu Trust Domain, SEAM, TDX Module, TME-MK ve ilgili bellek izolasyon mekanizmalarıyla gerçekleştirirken; AMD tarafında SEV ailesi zaman içerisinde SEV-ES ve özellikle SEV-SNP ile daha güçlü bir bellek sahipliği, bütünlük ve attestation modeline ulaşmıştır.

Her iki yaklaşımda da amaç aynıdır:

Veriyi yalnızca depolanırken ve taşınırken değil, işlendiği sırada da korumak.

Bu nedenle modern veri merkezi güvenliği artık yalnızca:

Encryption at Rest
        +
Encryption in Transit

yaklaşımından ibaret değildir.

Yeni güvenlik modeli:

Data at Rest
     +
Data in Transit
     +
Data in Use
     =
Confidential Computing

şeklinde düşünülmelidir.

Intel TDX ve AMD SEV-SNP özellikle public cloud, finans, sağlık, kritik altyapılar, çok taraflı veri analitiği ve yapay zekâ gibi hassas workload’ların çalıştırıldığı ortamlarda bu yeni güven modelinin en önemli yapı taşları arasında yer almaktadır.

Ancak bu teknolojiler klasik güvenlik kontrollerinin alternatifi değildir. En güçlü mimari; Confidential Computing + güçlü kimlik yönetimi + KMS/HSM + attestation + secure boot + workload security + network security bileşenlerinin birlikte kullanıldığı katmanlı güvenlik yaklaşımıdır.

Kısacası Intel TDX ve AMD SEV-SNP’nin getirdiği en önemli değişiklik yalnızca “belleği şifrelemek” değildir.

Asıl değişiklik şudur:

Altyapıya güvenmek yerine, güveni kriptografik olarak ve donanım seviyesinde doğrulayabilmek.