Confidential Computing: Komputasi Rahasia di Era TEE 2026

Pendahuluan

Selama satu dekade terakhir, keamanan data di cloud berfokus pada dua negara bagian: data at-rest (disimpan) dan data in-transit (dikirim). Keduanya sudah terpecahkan dengan enkripsi disk dan TLS. Namun ada celah ketiga yang selama ini menganga: data in-use, yaitu data yang sedang diproses di memori CPU. Saat aplikasi sedang menghitung, data terpaksa didekripsi di RAM dan rentan terhadap serangan memory dump, kompromi hypervisor, hingga insider threat dari penyedia cloud.

Di 2026, Confidential Computing keluar dari tahap eksperimental ke produksi mainstream berkat matangnya Trusted Execution Environment (TEE). Artikel ini membedah konsep, ekosistem, dan cara praktis mengadopsinya.

Apa Itu TEE dan Confidential Computing?

Confidential Computing adalah paradigma di mana komputasi berjalan di dalam enclave terisolasi secara hardware. TEE adalah area prosesor yang terpisah secara kriptografis dari sistem operasi, hypervisor, bahkan BIOS. Data dan kode di dalam enclave terenkripsi saat berada di memori dan hanya didekripsi di dalam core CPU itu sendiri.

Tiga pilar yang dilindungi Confidential Computing:

Perbedaan kuncinya: pada TEE, attestation memungkinkan kita memverifikasi bahwa kode yang berjalan benar-benar versi yang tidak dimanipulasi sebelum mengirim data rahasia.

Dua Tingkat Isolasi: Enclave vs VM

Tidak semua TEE setara, dan memilih yang salah berarti refactor besar:

Intel SGX membatasi aplikasi ke Enclave Page Cache (EPC). Pada platform lama, EPC-nya 128 MB dengan sekitar 93,5 MB yang benar-benar bisa dipakai aplikasi, sehingga melewati batas itu memicu paging enclave yang mahal. Platform Xeon terbaru menaikkan batas ini secara drastis, hingga 512 GB EPC per socket dan 1 TB pada konfigurasi dua socket, setelah SGX beralih dari Merkle tree berbasis on-die ke enkripsi AES-XTS.

AMD SEV dan SEV-SNP mengambil jalan berbeda: seluruh VM terenkripsi, jadi aplikasi bisa memakai seluruh RAM yang dialokasikan VM tanpa batas enclave. Konsekuensinya, SEV-SNP tidak memaksa refactor aplikasi sama sekali, sementara SGX menuntut kamu memisahkan bagian sensitif ke enclave.

Ekosistem 2026

Vendor besar kini menawarkan TEE di level produksi:

Tren 2026 yang paling menarik adalah Confidential Containers di K8s, yaitu developer bisa menjalankan pod di enclave tanpa rewrite kode, cukup via runtime kata-containers + shim TEE.

Cara Kerja Confidential Containers

CoCo memakai Kata Containers sebagai sandbox. Alih-alih berbagi kernel host, setiap pod berjalan di dalam Utility Virtual Machine (UVM) ringan yang hardware-isolated. Komponen utamanya:

Alur singkatnya: enclave boot, mengambil attestation report yang memuat measurement boot, lalu mengirimkannya ke KBS. AS mencocokkan measurement dengan reference value. Kalau cocok dan nonce sesuai, KBS melepas kunci dekripsi. Tanpa langkah itu, tidak ada rahasia yang masuk ke enclave.

Alur Attestation Secara Praktis

Attestation bukan formalitas, ia adalah satu-satunya hal yang membedakan TEE dari enkripsi biasa. Di AWS Nitro Enclaves, Nitro Hypervisor menghasilkan dan menandatangani attestation document saat enclave dibuat. Dokumen itu memuat PCR (Platform Configuration Registers), yaitu pengukuran kriptografis proses boot, ditambah hash image dan aplikasi, public key enclave, dan instance ID.

Nilai-nilai PCR itu bisa dipasang sebagai condition pada key policy KMS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOnlyAttestedEnclave",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:role/cc-app-role" },
      "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
      "Resource": "*",
      "Condition": {
        "StringEqualsIgnoreCase": {
          "kms:RecipientAttestation:PCR0": "abc123...",
          "kms:RecipientAttestation:PCR8": "def456..."
        }
      }
    }
  ]
}

Perhatikan dua detail penting. Pertama, Nitro Enclaves tidak punya persistent storage dan tidak punya jaringan eksternal; seluruh lalu lintas masuk-keluar melewati vsock yang berakhir di instance EC2 induk. Kedua, ketika panggilan KMS dilakukan dengan attestation document, plaintext di response dibungkus di bawah public key enclave, sehingga ciphertext yang dikembalikan hanya bisa dibuka oleh private key di dalam enclave.

Kasus Penggunaan Nyata

Kasus ML layak dikembangkan lebih jauh, karena di 2026 ia yang paling banyak ditanyakan. Pola yang dipakai: bobot model didistribusikan terenkripsi, didekripsi hanya di dalam TEE yang sudah diverifikasi hardware, dan inference dijalankan di sana. Di sisi NVIDIA, perlindungan memori GPU pada H100 dan B200 membuat attestation bisa mencakup CPU dan GPU sekaligus dalam satu quote, sehingga kompromi satu perangkat saja tidak cukup untuk membuka model. Pipeline-nya biasanya dirangkai dari CoCo, KServe, dan vLLM, dengan pelepasan kunci digate oleh Key Broker Service.

Tantangan Adopsi

Meski menjanjikan, ada harga yang dibayar:

Beberapa jebakan tambahan yang sering terlewat:

Implementasi Cepat dengan OpenEnclave

Untuk eksperimen lokal, project Open Enclave (CNCF) menyediakan SDK lintas platform:

#include <openenclave/host.h>

// Inisialisasi enclave dari file signed (.sgxs)
oe_result_t result = oe_create_enclave(
    "enclave.sgxs",
    OE_ENCLAVE_TYPE_SGX,
    OE_ENCLAVE_FLAG_DEBUG,
    0, 0,
    &enclave
);

if (result == OE_OK) {
  // Panggil fungsi terenkripsi di dalam enclave
  process_secret_data(enclave, encrypted_input);
}

Kode di atas memuat enclave ter-signing dan menjalankan fungsi pemrosesan di dalamnya. Data encrypted_input hanya terbuka di dalam core CPU, tidak pernah terlihat OS host.

Contoh yang lebih dekat ke produksi, yaitu pod Kubernetes di dalam TEE:

apiVersion: v1
kind: Pod
metadata:
  name: sensitive-processor
spec:
  runtimeClassName: kata-qemu-tdx   # atau kata-qemu-snp untuk AMD
  containers:
    - name: app
      image: registry.example.com/sensitive-app:v1
      resources:
        limits:
          memory: 4Gi
          cpu: "2"

Untuk melihat kemampuan attestation tiap node:

# Node mana saja yang punya TDX atau SEV-SNP?
kubectl get nodes \
  -L intel.feature.node.kubernetes.io/tdx,amd.feature.node.kubernetes.io/snp

Kesimpulan

Confidential Computing menutup celah terakhir dalam triad keamanan data: in-use. Di 2026, dengan Confidential Containers yang membawa TEE ke Kubernetes secara transparan, adopsi tidak lagi menuntut rewrite aplikasi. Bagi engineer cloud, saatnya mulai mengaudit beban kerja mana yang paling berisiko saat "sedang diproses" dan memindahkannya ke enclave. Keamanan bukan lagi soal di mana data disimpan, tapi seberapa terisolasi saat data itu benar-benar bekerja.