Remote Attestation, Confidential Space & Quản Lý Khóa
Vì Sao Mã Hóa Bộ Nhớ Chưa Đủ: Bài Toán "Làm Sao Tin Tưởng Từ Xa"
Ở file 01, chúng ta đã nhấn mạnh: không có attestation, Confidential Computing chỉ là mã hóa mù. Hãy cụ thể hóa vấn đề này bằng một tình huống thực tế: giả sử bạn có một dịch vụ giữ khóa Cloud KMS dùng để giải mã dữ liệu bệnh án bệnh nhân, và bạn muốn chỉ cấp khóa đó cho một workload cụ thể đang chạy trên Confidential GKE Node, đã được audit code kỹ lưỡng. Câu hỏi đặt ra: dịch vụ giữ khóa đó, chạy trên một máy chủ hoàn toàn khác, làm sao biết được rằng request đang gọi tới nó thực sự tới từ workload đã audit, đang chạy trong TEE hợp lệ, chứ không phải một kẻ tấn công đã giả mạo request đó, hoặc thậm chí đã deploy một workload độc hại lên chính một Confidential VM thật (phần cứng thật, nhưng code sai)?
Đây chính xác là bài toán remote attestation giải quyết: cung cấp một cơ chế mật mã học để một bên ở xa (remote) có thể xác minh (attest) rằng một hệ thống đang ở trạng thái đáng tin cậy, dựa trên bằng chứng do chính phần cứng của hệ thống đó sinh ra và ký số — không dựa vào lời tự khai của phần mềm chạy bên trong hệ thống đó (vì nếu phần mềm đã bị compromise, nó có thể nói dối).
Ba Bên Trong Mọi Giao Dịch Attestation
Theo mô hình RATS (Remote ATtestation procedureS) mà Google Cloud Attestation triển khai theo, mọi quy trình attestation gồm ba vai trò độc lập:
Attester — chính là workload chạy trên Confidential VM cần chứng minh danh tính để truy cập tài nguyên. Bản thân VM và host của nó ghi lại các phép đo (measurement) về trạng thái phần cứng ảo hóa và phần mềm trong quá trình khởi động — chính là các giá trị MRTD/RTMR (với TDX) hoặc PCR trong vTPM (với SEV) đã trình bày ở file 02 và 03.
Verifier — hệ thống bên ngoài xác thực bằng chứng do attester cung cấp. Nếu bằng chứng vượt qua các kiểm tra (chữ ký hợp lệ, measurement khớp với giá trị kỳ vọng), verifier trả về một kết quả xác minh đã được ký số (attestation token). Verifier có thể là dịch vụ do Google vận hành (Google Cloud Attestation) hoặc một bên thứ ba độc lập (như Intel Trust Authority đã đề cập ở file 03), hoặc theo tài liệu, thậm chí "một thứ bạn đã tự xây dựng" (Remote attestation overview).
Relying Party — hệ thống kiểm soát quyền truy cập vào tài nguyên được bảo vệ (trong ví dụ trên, chính là dịch vụ giữ khóa Cloud KMS). Sau khi nhận kết quả xác minh từ verifier, relying party đối chiếu giá trị đó với chính sách truy cập (access policy) đã định nghĩa trước, rồi quyết định cấp hay từ chối quyền truy cập.
Sự tách biệt rõ ràng ba vai trò này quan trọng vì nó cho phép relying party không cần tự thực hiện việc verify mật mã học phức tạp (giải mã chữ ký AMD-SP/TDX Module, so khớp measurement) — nó chỉ cần tin tưởng verifier (một service chuyên trách, được audit kỹ) và áp policy đơn giản lên kết quả token nhận về.
Passport Model Và Background Check Model
RATS Architecture RFC định nghĩa hai mô hình luồng dữ liệu chính cho attestation, khác nhau ở việc ai giữ kết quả xác minh và chuyển nó đi đâu:
| Mô hình | Luồng dữ liệu | Đặc điểm |
|---|---|---|
| Passport model | Attester → Verifier → Attester → Relying Party | Attester tự đi xin "hộ chiếu" (attestation token) từ verifier trước, rồi mang token đó (giống hộ chiếu) trình cho relying party. Verifier không cần biết relying party là ai. |
| Background check model | Attester → Relying Party → Verifier → Relying Party | Attester gửi bằng chứng thô trực tiếp cho relying party; relying party tự chuyển tiếp bằng chứng đó cho verifier để kiểm tra ("background check"), rồi verifier trả kết quả về cho relying party. |
Google Cloud Attestation, khi dùng kết hợp với Confidential Space, sử dụng passport model: workload (attester) chủ động lấy attestation token từ Google Cloud Attestation trước, sau đó dùng token này để xác thực trực tiếp với relying party (ví dụ IAM của Cloud KMS) — mô hình này phù hợp tự nhiên với cách Google Cloud vốn đã dùng OIDC token cho Workload Identity Federation (đã trình bày ở Chương 13), vì attestation token ở đây thực chất chính là một dạng mở rộng của OIDC token.
Vai Trò Của vTPM Trong Attestation: Root Of Trust Kép
Với các công nghệ dùng vTPM trong chuỗi đo lường (SEV, SEV-ES, và một phần của SEV-SNP), vTPM đảm nhận hai vai trò kép theo đúng chuẩn TPM 2.0:
- Root of trust for storage: lưu trữ các giá trị đo lường vào Platform Configuration Registers (PCR) — mỗi PCR là một chuỗi hash được "extend" tuần tự (hash mới = hash(hash cũ || dữ liệu mới)), đảm bảo không thể sửa đổi retroactively một giá trị PCR mà không làm sai lệch toàn bộ chuỗi hash sau đó.
- Root of trust for reporting: ký số các báo cáo xác minh (attestation report) bằng một khóa riêng gắn với chính vTPM đó (Attestation Identity Key), cho phép verifier xác nhận báo cáo thực sự tới từ vTPM hợp lệ, không bị giả mạo trên đường truyền.
Khác Biệt Attestation Theo Từng Công Nghệ: Tổng Hợp Lại
Kết hợp thông tin đã trình bày rải rác ở file 02 và 03, đây là bảng tổng hợp về bản chất attestation của từng công nghệ — kiến thức nền tảng để hiểu vì sao quy trình verify khác nhau giữa chúng:
| Công nghệ | Loại xác minh | Nơi lưu measurement | Đặc điểm |
|---|---|---|---|
| AMD SEV | Software attestation | vTPM (phần mềm, đo chính firmware ảo) | Firmware ảo tự đo lường chính nó |
| AMD SEV-SNP | Kết hợp phần cứng + phần mềm | AMD Secure Processor (early boot) + vTPM (boot muộn) | Attestation report có thể sinh on-demand trực tiếp từ AMD-SP |
| Intel TDX | Hardware attestation thuần túy | TDX Module (MRTD + RTMR) | Không qua vTPM, toàn bộ measurement nằm trong module phần cứng |
Cấu Trúc Một Attestation Report
Attestation report là "bằng chứng cho thấy VM đang chạy trong TEE" — chứa các phép đo liên quan tới hoạt động bootloader, tính toàn vẹn kernel, cấu hình phần cứng, cấu hình firmware, và các sự kiện được ghi log tại thời điểm khởi động, giúp xác thực trạng thái và danh tính của instance Confidential VM (Confidential VM attestation). Nguồn ký số của báo cáo phụ thuộc vào công nghệ: vTPM do Google quản lý (software-based) cho phần đo bootloader/kernel, hoặc trực tiếp từ AMD Secure Processor / Intel TDX Module (hardware TSM — Trusted Security Module) cho phần đo cấu hình phần cứng/firmware.
Với các VM dùng AMD SEV, mỗi lần VM khởi động sẽ sinh ra một launch attestation report — một sự kiện riêng biệt được ghi lại như một phần của chuỗi sự kiện xác minh tính toàn vẹn cho VM đó, đánh dấu chính xác thời điểm và trạng thái của lần boot cụ thể này.
Launch Endorsement: Xác Minh Firmware Genuine
Đã trình bày chi tiết ở file 03, nhưng cần nhắc lại ở đây trong bối cảnh quy trình attestation tổng thể: với SEV-SNP hoặc TDX, bạn có thể lấy thêm một launch endorsement — measurement đã được Google tính toán trước và ký số cho phiên bản firmware chính hãng — để so sánh với measurement thực tế trong attestation report, xác nhận rằng VM đang chạy trên firmware Google build thật, không bị can thiệp ở tầng cung ứng.
Công Cụ Thực Hiện Verify
Việc lấy và verify attestation report trong thực tế thường thông qua bộ công cụ go-tpm-tools (phiên bản 0.4.4 trở lên) — thư viện Go chính thức cho phép request attestation quote từ vTPM, AMD Secure Processor, hoặc Intel TDX Module, tùy công nghệ đang chạy. Với AMD, công cụ sev-guest gửi các cryptographic challenge và cache lại chứng chỉ VCEK (Versioned Chip Endorsement Key — khóa xác thực cấp chip riêng của từng CPU vật lý AMD) cục bộ để tăng tốc các lần verify sau. Với Intel, công cụ tdx-guest đảm nhận vai trò tương đương cho attestation của TDX.
Confidential Space: Nâng Attestation Lên Thành Nền Tảng Multi-Party
Trong khi Confidential GKE Nodes/Confidential VM tập trung vào việc bảo vệ dữ liệu-đang-sử-dụng cho một workload đơn lẻ do một chủ thể (bạn) kiểm soát toàn bộ, Confidential Space giải quyết một bài toán khác: cho phép nhiều bên không tin tưởng lẫn nhau cùng xử lý dữ liệu nhạy cảm trên một workload chung, mà không ai (kể cả người vận hành workload) có thể truy cập dữ liệu của bên khác. Theo tài liệu, Confidential Space là "một môi trường thực thi đáng tin cậy cho phép xử lý dữ liệu nhạy cảm từ nhiều bên mà không tiết lộ thông tin cho các bên khác" (Confidential Space overview).
Ba Thành Phần Kiến Trúc
- Workload: một container image chứa code xử lý dữ liệu được bảo vệ, chạy trên nền một hệ điều hành đã được "hardened" (Confidential Space image) và bên trong một Confidential VM.
- Attestation Service: verifier từ xa cung cấp bằng chứng danh tính. Google Cloud hỗ trợ Google Cloud Attestation (cho cả AMD SEV lẫn Intel TDX) và Intel Trust Authority (riêng cho Intel TDX).
- Protected Resources: tài nguyên được bảo vệ bằng hệ thống xác thực dựa trên attestation — có thể là một key trong Cloud KMS, một bucket Cloud Storage, hoặc thậm chí một tài nguyên nằm ngoài Google Cloud hoàn toàn.
Ba Vai Trò Tách Biệt Trách Nhiệm
Điểm khác biệt cốt lõi khiến Confidential Space hữu ích cho các kịch bản đa bên không tin tưởng lẫn nhau là mô hình phân tách rõ ba vai trò:
- Data Collaborators: sở hữu dữ liệu nhạy cảm được bảo vệ; không thể truy cập dữ liệu của các collaborator khác.
- Workload Author: tạo ra ứng dụng xử lý dữ liệu; không có quyền truy cập dữ liệu thực tế khi nó chạy.
- Workload Operator: triển khai và vận hành workload trên hạ tầng; không thể can thiệp hoặc sửa đổi code workload đang chạy (attestation sẽ phát hiện nếu image bị thay đổi, vì measurement sẽ khác giá trị kỳ vọng).
Đây là lý do Confidential Space phù hợp tự nhiên cho các use case như phân tích dữ liệu tài chính đa ngân hàng, học liên kết (federated learning) trong y tế đa bệnh viện, hoặc bất kỳ tình huống nào nhiều tổ chức cần cùng tính toán trên tập dữ liệu gộp mà không ai muốn (hoặc được phép, vì lý do pháp lý) để lộ dữ liệu thô của mình cho bên còn lại.
Bảo Vệ Tính Toàn Vẹn Ở Tầng Image: dm-verity
Confidential Space image sử dụng các phân vùng đĩa mã hóa với bảo vệ tính toàn vẹn: một phân vùng root-fs và một phân vùng OEM, cả hai đều bất biến (immutable) và được bảo vệ bởi dm-verity — một cơ chế kernel Linux cho phép xác minh mật mã học từng block dữ liệu khi đọc từ đĩa, phát hiện ngay lập tức nếu bất kỳ byte nào trên đĩa bị thay đổi so với trạng thái được ký số ban đầu. Launcher (thành phần khởi chạy workload) sử dụng TLS để xác thực với Google Cloud Attestation và bảo vệ các kênh giao tiếp liên quan.
Attestation Policy Và Cấp Quyền Truy Cập
Sau khi tạo một Workload Identity Pool provider (đã trình bày ở Chương 13 cho bối cảnh external IdP tổng quát), bạn có thể cấp một IAM role cho một federated identity dựa trên việc identity đó có khớp với các assertion mong đợi hay không — ví dụ, cấp quyền giải mã một Cloud KMS key cụ thể chỉ khi container image digest của workload khớp chính xác với digest đã audit và whitelist trước. Đây chính là pattern secure key release: khóa mã hóa dữ liệu nhạy cảm chỉ được cấp phát (release) sau khi code chứng minh (qua attestation) rằng nó đang chạy đúng image đã được duyệt, bên trong một TEE hợp lệ.
Attestation token do Google Cloud Attestation cấp có thời hạn một giờ và tự động refresh khi workload còn đang chạy hợp lệ — thiết kế này cân bằng giữa việc giảm thiểu rủi ro token bị đánh cắp và sử dụng lại (do TTL ngắn) với chi phí vận hành của việc phải refresh liên tục.
Vì Sao Confidential Computing Không Thay Thế Cloud KMS
Một nhầm lẫn cần tránh: Confidential Computing và Cloud KMS/CMEK (đã trình bày sâu ở Chương 32) giải quyết hai bài toán khác nhau và bổ trợ lẫn nhau, không thay thế nhau. Khóa mã hóa bộ nhớ do AMD-SP/TDX Module sinh ra chỉ bảo vệ dữ liệu đang nằm trong RAM của chính VM đó, có vòng đời gắn chặt với VM đó — khi VM tắt, khóa đó biến mất vĩnh viễn. Nó không phải là một khóa dùng để mã hóa dữ liệu ghi xuống đĩa lâu dài, không thể export, không có API để ứng dụng của bạn chủ động dùng nó cho mục đích mã hóa nghiệp vụ (ví dụ mã hóa một file trước khi lưu vào Cloud Storage).
Với các bài toán như "mã hóa persistent disk", "mã hóa secret trong Secret Manager", "mã hóa dữ liệu trong BigQuery" — bạn vẫn cần Cloud KMS như bình thường. Giá trị thực sự khi kết hợp hai công nghệ này nằm ở pattern secure key release đã mô tả: dùng attestation (từ Confidential Computing) làm điều kiện tiên quyết để Cloud KMS cấp quyền sử dụng một khóa CMEK cụ thể, thay vì cấp quyền tĩnh dựa trên IAM identity đơn thuần. Nói cách khác: Confidential Computing trả lời câu hỏi "workload này có đáng tin để nhận khóa hay không", còn Cloud KMS vẫn là nơi khóa thực sự được quản lý, xoay vòng (rotation, xem Chương 32 phần key rotation), và audit.
Mối Quan Hệ Với Workload Identity Federation: Attestation Token Như Một Loại Federated Identity
Với kỹ sư đã quen thuộc với Workload Identity Federation trên GKE (đã trình bày sâu ở Chương 13), cách nhanh nhất để nắm bắt attestation token của Confidential Space là nhìn nó như một mở rộng tự nhiên của mô hình OIDC token đã có sẵn, chỉ khác ở nguồn gốc của các claim bên trong token. Với Workload Identity thông thường, claim trong token JWT phản ánh danh tính Kubernetes ServiceAccount (namespace, tên KSA, cluster issuer) — một thông tin do control plane Kubernetes tự khai báo, dựa trên việc Pod nào đang gọi tới metadata server. Với attestation token của Confidential Space, các claim bổ sung phản ánh kết quả xác minh phần cứng thực tế — công nghệ confidential computing đang chạy (SEV/SEV-SNP/TDX), digest của container image, trạng thái đo lường của TEE — những thông tin này không thể bị giả mạo bởi chính workload đang chạy, vì chúng bắt nguồn từ phần cứng CPU, không phải từ một API call mà ứng dụng tự thực hiện.
Sự khác biệt này giải thích vì sao attestation token mạnh hơn đáng kể so với chỉ dùng KSA identity đơn thuần để kiểm soát truy cập tài nguyên nhạy cảm: một KSA identity chỉ chứng minh "request này tới từ một Pod mang ServiceAccount X" — nhưng không chứng minh được rằng Pod đó đang chạy đúng code đã audit, hay đang chạy trên phần cứng bảo vệ dữ liệu-đang-sử-dụng. Kết hợp cả hai — KSA identity qua Workload Identity Federation cho việc phân quyền theo tổ chức/namespace, và attestation token qua Confidential Space cho việc xác minh tính toàn vẹn phần cứng và code — tạo ra một mô hình phòng thủ theo lớp (defense-in-depth) hoàn chỉnh hơn nhiều so với chỉ dùng một trong hai.
Chi Tiết Attribute Mapping Trong Attestation Policy
Khi thiết lập Workload Identity Pool provider cho Confidential Space, attribute mapping — cơ chế đã giới thiệu tổng quát ở Chương 13 phần external IdP — được dùng để trích xuất các claim cụ thể từ attestation token thành các thuộc tính có thể dùng trong điều kiện IAM. Ví dụ điển hình: một điều kiện dựa trên attribute.image_digest khớp chính xác với digest đã được audit và ghi vào allowlist, kết hợp với attribute.hwmodel hoặc claim tương đương xác nhận công nghệ confidential computing cụ thể (loại trừ khả năng workload vô tình hoặc cố ý được deploy trên node non-confidential mà vẫn cố gắng xin token). Việc dùng biểu thức CEL (Common Expression Language, cũng chính công cụ đã dùng trong RBAC conditions và admission policy ở các chương trước) để định nghĩa các điều kiện này cho phép attestation policy trở nên chặt chẽ và có thể audit được, thay vì dựa vào logic kiểm tra tùy biến rải rác trong code ứng dụng.
Mental Model Tổng Kết
Ba khái niệm attester/verifier/relying party không phải thuật ngữ hàn lâm trừu tượng — chúng ánh xạ trực tiếp vào các thành phần cụ thể bạn sẽ thiết kế trong một kiến trúc secure key release thực tế trên GCP: attester là Pod/workload của bạn chạy trên Confidential GKE Node, verifier là Google Cloud Attestation (hoặc Intel Trust Authority), và relying party là chính sách IAM gắn trên Cloud KMS key hoặc Cloud Storage bucket bạn muốn bảo vệ. Việc thiết kế đúng attestation policy — chỉ khớp digest image đã audit, chỉ chấp nhận công nghệ confidential computing cụ thể (loại trừ trường hợp workload vô tình chạy trên node non-confidential) — quan trọng ngang với việc chọn đúng công nghệ phần cứng ở các file trước. Một attestation policy quá lỏng lẻo (ví dụ chỉ kiểm tra "chạy trên bất kỳ Confidential VM nào" mà không kiểm tra digest image cụ thể) sẽ vô hiệu hóa gần như toàn bộ giá trị bảo mật của toàn bộ chuỗi, vì bất kỳ ai có thể deploy một workload (thậm chí độc hại) lên một Confidential VM hợp lệ và vẫn vượt qua được policy.
Phần cuối của chương sẽ chuyển từ câu hỏi "làm sao chứng minh workload đáng tin" sang câu hỏi thực dụng nhất khi ra quyết định production: chi phí hiệu năng thực sự của toàn bộ cơ chế này là bao nhiêu, và khi nào nó thực sự xứng đáng để đánh đổi.