Trusted Execution Environment & Mô Hình Mối Đe Dọa
Ba Trạng Thái Của Dữ Liệu Và Khoảng Trống Bị Bỏ Quên
Trong bất kỳ kiến trúc bảo mật nào, dữ liệu tồn tại ở ba trạng thái: đang lưu trữ (at-rest), đang truyền (in-transit), và đang được xử lý (in-use). Hai trạng thái đầu đã có giải pháp trưởng thành từ hàng chục năm nay — TLS/mTLS cho in-transit, AES-256 với Cloud KMS/CMEK cho at-rest. Nhưng trạng thái thứ ba gần như luôn bị bỏ ngỏ trong các mô hình threat truyền thống, vì lý do rất thực tế: để một CPU thực thi được lệnh trên dữ liệu, dữ liệu đó phải nằm ở dạng plaintext trong thanh ghi và bộ nhớ RAM. Không có cách nào để một ALU (Arithmetic Logic Unit) cộng hai số đã mã hóa mà không giải mã trước — trừ khi dùng homomorphic encryption, một kỹ thuật hiện vẫn quá chậm cho hầu hết workload thực tế.
Hệ quả là: bất kỳ ai có quyền đọc bộ nhớ vật lý của máy chủ — hypervisor, hệ điều hành host, một kỹ sư vận hành trung tâm dữ liệu với quyền truy cập debug, hoặc một kẻ tấn công đã khai thác được lỗ hổng ở tầng hypervisor — đều có thể đọc trực tiếp dữ liệu đang được ứng dụng của bạn xử lý, bất kể dữ liệu đó đã được mã hóa kỹ đến đâu khi lưu trên đĩa. Đây chính là khoảng trống mà Confidential Computing giải quyết: mã hóa dữ liệu ngay cả khi nó đang nằm trong RAM và đang được CPU thao tác, bằng cách đưa quyền kiểm soát khóa mã hóa vào tận phần cứng, tách biệt khỏi mọi tầng phần mềm bên trên — kể cả hypervisor.
Trusted Computing Base (TCB) — Khái Niệm Cốt Lõi Cần Nắm Trước Tiên
Để hiểu Confidential Computing thay đổi điều gì, phải hiểu khái niệm Trusted Computing Base (TCB): tập hợp mọi thành phần phần cứng và phần mềm mà, nếu bị xâm phạm, sẽ khiến toàn bộ đảm bảo bảo mật của hệ thống sụp đổ. Trong một VM thông thường trên bất kỳ nền tảng cloud nào (bao gồm cả Compute Engine VM tiêu chuẩn), TCB bao gồm:
- Guest OS và kernel bên trong VM
- Hypervisor (KVM trên Compute Engine)
- Host OS/firmware của máy chủ vật lý
- Toàn bộ chuỗi cung ứng phần cứng (BIOS/UEFI, BMC)
Nếu hypervisor bị lỗi bảo mật, hoặc một quản trị viên nội bộ với quyền truy cập host bị compromise, toàn bộ dữ liệu trong mọi VM chạy trên host đó về lý thuyết đều có thể bị đọc. Đây không phải là một giả định phi thực tế — nó là lý do các tổ chức tài chính, y tế, chính phủ có yêu cầu compliance nghiêm ngặt (ví dụ FedRAMP High, PCI DSS ở mức cao) thường coi "cloud provider insider access" là một mục trong threat model chính thức của họ, chứ không phải một rủi ro lý thuyết bỏ qua được.
Confidential Computing thu hẹp TCB xuống chỉ còn phần cứng CPU và firmware được ký số của chính CPU đó. Hypervisor, host OS, và thậm chí cả Google với tư cách nhà cung cấp cloud, đều bị loại ra khỏi TCB. Đây là một thay đổi kiến trúc, không phải một tính năng bổ sung: hypervisor vẫn quản lý việc lập lịch CPU, phân bổ tài nguyên, I/O — nhưng nó không còn khả năng đọc được nội dung bộ nhớ của guest VM nữa.
Theo tài liệu chính thức của Google Cloud, nguyên tắc cốt lõi xuyên suốt mọi công nghệ Confidential VM là: "encryption keys are generated by — and reside solely in — dedicated hardware, inaccessible to the hypervisor" (Confidential VM overview).
Ba Trụ Cột Của Một Trusted Execution Environment
Mọi công nghệ Confidential Computing — dù là AMD SEV, Intel TDX, hay các implementation khác trên thị trường — đều được xây từ ba trụ cột kỹ thuật độc lập nhưng bổ trợ lẫn nhau. Hiểu rõ ba trụ cột này quan trọng hơn nhiều so với việc thuộc lòng tên gọi từng thế hệ công nghệ, vì nó cho phép bạn đánh giá đúng bất kỳ giải pháp confidential computing nào, kể cả những công nghệ chưa xuất hiện trên GCP.
Trụ cột 1 — Isolation (Cô lập thực thi)
CPU phải đảm bảo rằng không một thành phần phần mềm nào bên ngoài guest VM — kể cả hypervisor chạy ở mức đặc quyền cao nhất (ring -1 hoặc VMX root mode) — có thể đọc hoặc ghi vào không gian địa chỉ bộ nhớ vật lý được gán cho guest đó, ngoại trừ các vùng được guest chủ động chia sẻ (ví dụ buffer I/O). Cơ chế isolation này được thực thi ở tầng silicon thông qua các cấu trúc phần cứng mới: AMD dùng Reverse Map Table (RMP) trong SEV-SNP để kiểm soát ai sở hữu trang bộ nhớ nào; Intel dùng một chế độ CPU đặc quyền mới gọi là SEAM (Secure Arbitration Mode) để chạy TDX Module tách biệt hoàn toàn khỏi VMX root mode nơi hypervisor vận hành.
Trụ cột 2 — Encryption (Mã hóa bộ nhớ transparent)
Mọi dữ liệu ghi từ CPU xuống RAM vật lý đều được mã hóa on-the-fly bằng một bộ mã hóa tích hợp ngay trong memory controller của CPU (không phải phần mềm), và được giải mã ngược lại khi CPU đọc nó vào cache/thanh ghi để thực thi. Vì việc mã hóa/giải mã diễn ra hoàn toàn trong suốt đối với guest OS và ứng dụng, không cần thay đổi bất kỳ dòng code nào để tận dụng bảo vệ này — đây chính là lý do Google mô tả cách tiếp cận của họ là cho phép "effortless lift and shift" các ứng dụng hiện có lên Confidential GKE Nodes mà không cần sửa đổi (Confidential GKE Nodes now available). Điểm mấu chốt: khóa mã hóa này không phải là một khóa do người dùng quản lý qua Cloud KMS — nó được sinh ngẫu nhiên bởi chính phần cứng CPU tại thời điểm VM khởi tạo, không rời khỏi CPU, và không ai — kể cả Google — có quyền truy xuất nó.
Trụ cột 3 — Attestation (Khả năng kiểm chứng từ xa)
Đây là trụ cột thường bị đánh giá thấp nhất nhưng lại quan trọng bậc nhất về mặt vận hành production. Isolation và encryption chỉ cho bạn biết "nếu đây đúng là một Confidential VM thật, dữ liệu của nó được bảo vệ". Nhưng làm sao một hệ thống bên ngoài — ví dụ một dịch vụ nắm giữ khóa giải mã dữ liệu nhạy cảm — biết được rằng nó đang giao tiếp với một workload thực sự chạy trong TEE hợp lệ, với đúng image code đã được audit, chứ không phải một VM giả mạo hoặc một TEE đã bị hạ cấp bảo mật? Câu trả lời là remote attestation: một quy trình mật mã học cho phép phần cứng CPU tạo ra bằng chứng (attestation report) được ký số bởi khóa riêng gắn cứng trong silicon, chứng minh trạng thái khởi động, cấu hình phần cứng, và firmware của TEE đó. Chi tiết cơ chế attestation được trình bày sâu ở file 05 của chương này, nhưng cần nhấn mạnh ngay từ đầu: không có attestation, Confidential Computing chỉ là mã hóa mù — bạn tin tưởng một cách vô căn cứ rằng "chắc là nó chạy trong TEE thật", điều này vô nghĩa trong bất kỳ mô hình bảo mật nghiêm túc nào.
Mô Hình Mối Đe Dọa: Confidential Computing Bảo Vệ Khỏi Cái Gì, Và Không Bảo Vệ Khỏi Cái Gì
Một sai lầm phổ biến — và nguy hiểm — là coi Confidential Computing như một "tường lửa toàn năng" chống mọi loại tấn công. Thực tế threat model của nó rất cụ thể và có ranh giới rõ ràng.
Confidential Computing BẢO VỆ khỏi:
- Kẻ tấn công đã chiếm quyền hypervisor, cố gắng dump bộ nhớ vật lý của guest VM để đọc dữ liệu plaintext hoặc thanh ghi CPU.
- Truy cập vật lý tới DRAM (cold boot attack, bus snooping trên đường truyền RAM) — đặc biệt được Intel TDX nhấn mạnh trong tài liệu chính thức: TDX "specifically addresses physical access threats, defending against DRAM-based attacks including memory capture and modification" (Confidential VM overview).
- Malicious hypervisor tấn công tính toàn vẹn (không chỉ đọc trộm mà còn chủ động sửa đổi bộ nhớ, replay các trang bộ nhớ cũ, hoặc ánh xạ lại địa chỉ bộ nhớ để đánh lừa VM) — đây là lớp bảo vệ bổ sung riêng của AMD SEV-SNP, được trình bày kỹ ở file 02.
- Nhân viên vận hành trung tâm dữ liệu hoặc chính nhà cung cấp cloud cố tình hoặc vô tình truy cập dữ liệu qua các công cụ quản trị mức thấp (live debugging, memory introspection).
Confidential Computing KHÔNG bảo vệ khỏi:
- Lỗ hổng ở tầng ứng dụng hoặc guest OS. Nếu ứng dụng của bạn có SQL injection, hoặc container image chứa mã độc, TEE không giúp gì — nó chỉ bảo vệ ranh giới giữa guest và hypervisor, không phải bảo vệ nội bộ bên trong guest.
- Side-channel attack dựa trên timing, cache, hoặc power analysis. Đây là một lớp tấn công lý thuyết vẫn tồn tại với mọi thế hệ TEE hiện tại (bao gồm cả SGX, SEV, TDX) — kẻ tấn công có quyền truy cập host vật lý về lý thuyết vẫn có thể suy luận thông tin gián tiếp qua các kênh phụ như thời gian truy cập cache, dù không đọc trực tiếp được nội dung mã hóa.
- Workload tự nguyện rò rỉ dữ liệu qua network hoặc log. TEE mã hóa bộ nhớ, không kiểm soát những gì ứng dụng chủ động ghi ra ngoài (log ra Cloud Logging, gửi qua API không mã hóa).
- Truy cập trái phép nếu attestation bị bỏ qua. Nếu hệ thống của bạn cấp quyền truy cập tài nguyên nhạy cảm mà không verify attestation report, thì việc chạy trên phần cứng confidential không mang lại giá trị bảo mật thực chất nào — kẻ tấn công chỉ cần deploy một workload giả mạo lên một Confidential VM (thật) và vẫn vượt qua được kiểm soát truy cập nếu logic ứng dụng không kiểm tra identity/measurement của workload.
Điểm cuối cùng này là lý do vì sao attestation không phải một tính năng "nice-to-have" — nó là điều kiện cần để threat model của Confidential Computing thực sự có ý nghĩa trong một hệ thống production.
Vì Sao Không Thể "Chuyển Đổi" Một VM Thường Thành Confidential VM
Một hệ quả kỹ thuật trực tiếp từ mô hình khóa-nằm-trong-phần-cứng là: không thể bật Confidential VM cho một instance đang chạy sẵn. Tài liệu chính thức nêu rõ: "You must create a new VM instance to enable Confidential VM. Existing instances can't be converted" (Supported configurations). Lý do nằm ở chính cơ chế sinh khóa: khóa mã hóa bộ nhớ được CPU (AMD Secure Processor hoặc TDX Module) sinh ra tại thời điểm khởi tạo VM, gắn với một Address Space Identifier (ASID) hoặc TD ID duy nhất cho phiên làm việc đó. Việc "bật" tính năng này sau khi VM đã chạy — tức là bộ nhớ đã tồn tại ở dạng plaintext trong một không gian không được cách ly — là vô nghĩa về mặt bảo mật, vì tại thời điểm đó dữ liệu đã có thể bị đọc trước khi mã hóa được kích hoạt. Đây cũng chính là lý do trên GKE, việc bật Confidential GKE Nodes ở cấp cluster là quyết định không thể đảo ngược khi tạo cluster — không phải giới hạn hành chính tùy tiện, mà là hệ quả tất yếu từ cách khóa được gắn vào vòng đời phần cứng của từng node.
Chi Phí Không Miễn Phí: TEE Đổi Lấy Gì
Việc mã hóa/giải mã transparent mọi truy cập bộ nhớ không phải là phép màu — nó đòi hỏi thêm một bước xử lý trong đường dẫn memory controller cho mỗi lần đọc/ghi cache line. Với hầu hết workload CPU-bound, chi phí này gần như không đo được (dưới 1%) vì memory controller hiện đại xử lý mã hóa AES ở tốc độ line-rate bằng mạch chuyên dụng. Nhưng với các workload I/O-heavy, đặc biệt là hệ quản trị cơ sở dữ liệu với tần suất page fault và context switch cao, overhead có thể lên tới hai chữ số phần trăm do chi phí phụ trội trong quản lý bảng ánh xạ bộ nhớ mã hóa và các thao tác liên quan tới quản lý ASID/TD. Chi tiết số liệu benchmark cụ thể và cách ra quyết định dựa trên loại workload được trình bày ở file 06.
Điểm Khác Biệt Cơ Bản So Với Shielded VM
Một nhầm lẫn thường gặp ở kỹ sư mới tiếp cận là đánh đồng Confidential VM với Shielded VM — một tính năng bảo mật khác của Compute Engine đã được trình bày ở Chương 12. Shielded VM (Secure Boot, vTPM đo lường tiến trình boot, Integrity Monitoring) bảo vệ tính toàn vẹn của quá trình khởi động — đảm bảo bootloader, kernel, driver không bị rootkit/bootkit can thiệp trước khi guest OS chạy. Nhưng Shielded VM không mã hóa bộ nhớ đang sử dụng — hypervisor vẫn có khả năng đọc trực tiếp RAM của một Shielded VM thông thường. Confidential VM là một lớp bảo vệ hoàn toàn khác, bổ sung thêm (không thay thế) — trên thực tế, vTPM dùng trong attestation của AMD SEV chính là kế thừa hạ tầng vTPM vốn được xây dựng cho Shielded VM, chỉ khác là giờ đây nó còn tham gia vào chuỗi đo lường tính toàn vẹn của bộ nhớ được mã hóa. Hai tính năng này kết hợp với nhau, không loại trừ nhau: một Confidential VM mặc định vẫn kế thừa các bảo vệ boot-integrity của Shielded VM.
Vì Sao Không Dùng Homomorphic Encryption Thay Vì TEE
Một câu hỏi hợp lý xuất hiện khi lần đầu tiếp cận bài toán "bảo vệ dữ liệu đang xử lý": tại sao không dùng Fully Homomorphic Encryption (FHE) — một kỹ thuật mật mã học cho phép thực hiện phép toán trực tiếp trên dữ liệu đã mã hóa mà không cần giải mã trước? Về lý thuyết, FHE giải quyết đúng bài toán data-in-use mà không cần tin tưởng vào bất kỳ phần cứng nào — độ tin cậy hoàn toàn dựa trên độ khó của bài toán toán học (lattice-based cryptography), không phụ thuộc vào việc nhà sản xuất chip có làm đúng hay không. Nhưng trên thực tế, FHE hiện tại chậm hơn phép tính thông thường từ hàng nghìn tới hàng triệu lần tùy loại phép toán, khiến nó chỉ khả thi cho một số bài toán tính toán rất hẹp (ví dụ cộng/nhân đơn giản trên tập dữ liệu nhỏ), hoàn toàn không thực tế cho khối lượng công việc production thông thường như chạy một web service, một database, hay một pipeline xử lý dữ liệu quy mô lớn.
TEE (Trusted Execution Environment) là một điểm cân bằng thực dụng khác trên cùng trục đánh đổi: chấp nhận tin tưởng vào phần cứng CPU (một bề mặt tin cậy nhỏ hơn nhiều so với tin tưởng toàn bộ hypervisor và host OS, nhưng vẫn lớn hơn zero) để đổi lấy hiệu năng gần như nguyên bản — chạy code bình thường, không cần viết lại thuật toán theo ngữ nghĩa mã hóa đặc biệt. Đây chính là lý do Google Cloud nhấn mạnh khả năng "lift and shift" ứng dụng hiện có mà không cần sửa code khi dùng Confidential Computing — một lợi thế thực dụng mà FHE ở trạng thái công nghệ hiện tại chưa thể mang lại cho phần lớn workload doanh nghiệp.
Bề Mặt Tấn Công Vi Kiến Trúc: Giới Hạn Thực Sự Của Mọi TEE
Cần nhấn mạnh thêm một điểm đã đề cập ngắn gọn ở phần threat model, vì đây là nguồn gốc của phần lớn các lỗ hổng TEE từng được công bố trên thị trường (không riêng gì AMD hay Intel): side-channel attack dựa trên đặc tính vi kiến trúc dùng chung. Dù dữ liệu trong RAM đã được mã hóa và cách ly, CPU vẫn phải chia sẻ một số tài nguyên vi kiến trúc giữa các luồng thực thi khác nhau trên cùng lõi vật lý hoặc cùng cache — bao gồm cache L1/L2/L3, bộ dự đoán rẽ nhánh (branch predictor), và các bộ đệm nội bộ khác. Một kẻ tấn công chạy trên cùng phần cứng vật lý (dù không đọc trực tiếp được bộ nhớ mã hóa) về lý thuyết vẫn có thể quan sát thời gian truy cập hoặc mẫu hình sử dụng cache để suy luận gián tiếp thông tin về dữ liệu hoặc luồng điều khiển bên trong TEE — đây là lớp tấn công timing/cache side-channel đã được nghiên cứu rộng rãi trong giới học thuật bảo mật với nhiều biến thể trên cả SGX, SEV, và TDX.
Hệ quả thực tế cho platform engineer: Confidential Computing không phải là "giải pháp một lần cho tất cả" — nó cần được kết hợp với các biện pháp giảm thiểu bổ sung khi mức độ nhạy cảm của workload đủ cao (ví dụ tránh chia sẻ vật lý CPU với tenant không tin cậy qua sole-tenant node, dù như đã nói sole-tenant lại không tương thích với Confidential Computing trên GCP hiện tại — một đánh đổi kiến trúc thực sự cần cân nhắc kỹ chứ không có giải pháp hoàn hảo tuyệt đối). Điều quan trọng là không quảng cáo quá mức (over-promise) về mức độ bảo vệ của TEE khi trình bày kiến trúc bảo mật cho stakeholder không chuyên sâu kỹ thuật — luôn gắn nó với threat model cụ thể mà nó thực sự giải quyết (insider threat ở tầng hypervisor/host), không phải "bảo mật tuyệt đối chống mọi hình thức tấn công".
Mental Model Tổng Kết
Trước khi đi vào chi tiết từng công nghệ cụ thể (AMD SEV ở file kế tiếp, Intel TDX ở file sau đó), hãy khắc sâu mental model sau — nó sẽ định hướng cách bạn đọc và phản biện mọi thông tin về Confidential Computing sau này:
- TCB thu hẹp, không phải TCB biến mất. CPU và firmware của chính nó vẫn nằm trong TCB. Nếu CPU có lỗ hổng vi kiến trúc (như các lớp tấn công Spectre/Meltdown-class trong quá khứ), Confidential Computing không miễn nhiễm tự động — nó phụ thuộc vào nhà sản xuất chip vá lỗi kịp thời.
- Khóa nằm trong phần cứng, không nằm trong Cloud KMS. Đừng nhầm lẫn cơ chế khóa của Confidential VM với CMEK/Cloud KMS — chúng giải quyết hai bài toán khác nhau (data-in-use vs data-at-rest) và không thể hoán đổi cho nhau.
- Không attestation, không có giá trị bảo mật thực chất trong hệ thống phân tán. Mã hóa bộ nhớ chỉ hữu ích khi có một bên thứ ba có thể kiểm chứng từ xa rằng workload thực sự chạy trong TEE hợp lệ trước khi cấp quyền truy cập tài nguyên nhạy cảm.
- Đây là quyết định kiến trúc tại thời điểm tạo tài nguyên, không phải cấu hình runtime. Từ việc không thể convert VM hiện có, tới việc không thể đổi công nghệ confidential computing của một cluster GKE sau khi tạo — mọi quyết định đều phải được đưa ra sớm trong vòng đời hạ tầng.
Với nền tảng này, phần tiếp theo sẽ đi sâu vào cách AMD hiện thực hóa ba trụ cột trên qua ba thế hệ SEV, SEV-ES, và SEV-SNP — mỗi thế hệ giải quyết một lớp tấn công cụ thể mà thế hệ trước để lại.