TEE 数据库：EnclaveDB、Oblivious 原语与机密 SQL

原文发布于 quant67.com，转载请保留出处。

这是【数据库研究前沿】系列的第 19 篇。过去几篇讨论的是性能、弹性、硬件------从 CXL 到 Near-Data Processing 再到新型 NVM。本篇换一个轴：当我们把数据库搬到不信任的云上、甚至不信任的内核和 Hypervisor 上时，查询引擎还能不能保持机密性与完整性？

这不是纯学术问题。银行、医院、政府客户越来越频繁地要求"数据出机房但不出明文"，欧盟 GDPR、中国《数据安全法》、美国 HIPAA 都在把加密计算从"合规加分项"变成"合规前置条件"。可信执行环境（Trusted Execution Environment, TEE）是目前唯一同时满足"通用计算性能"与"远程证明（Remote Attestation）"的可商用方案：Intel SGX、AMD SEV-SNP、Intel TDX、ARM CCA 各自给出一套硬件语义，上层数据库论文------EnclaveDB（S&P 2018）、Opaque（NSDI 2017）、ObliDB（VLDB 2020）------在这套语义上叠加访问模式混淆（Oblivious Primitives）来抗侧信道。

本文上半部分做两件事：第一，把四种主流 TEE 的威胁模型和性能特征拉平对比；第二，梳理 EnclaveDB / Opaque / ObliDB 三篇论文各自解决的问题，以及 Foreshadow、ÆPIC Leak 等侧信道攻击如何反过来塑造了它们的设计。下半部分回到工程：Azure Confidential SQL、AWS Nitro Enclaves 上跑 OLAP 实际能到什么性能，哪些查询形态是可行的，哪些是现阶段的禁区。

版本说明 本文以 Intel SGX SDK 2.24、Intel TDX 1.5、AMD SEV-SNP（Milan / Genoa）、ARM CCA（Armv9-A）、Azure Confidential Computing 2024、AWS Nitro Enclaves 2024 为主要参照。TEE 领域演进很快，具体 CVE 与微码版本请以厂商公告为准。

一、四种 TEE 的威胁模型与抽象

1.1 TEE 到底在防什么

TEE 的核心卖点是一行话：把计算过程（代码 + 数据 + 内存）的机密性与完整性，从操作系统内核和 Hypervisor 手里拿回来，只信任 CPU 与一段很薄的固件。

这句话隐含的威胁模型（Threat Model）比想象中严格：

攻击者可以是拥有 root 权限的云管理员；
攻击者可以控制 Hypervisor、BIOS、设备固件（一定程度上）；
攻击者可以抓取主机的物理内存快照（冷启动攻击）；
攻击者可以观察 CPU 对外的总线流量（某些实现下）。

而攻击者不能做的事，按 TEE 实现不同各有差异，但通常包括：

直接读取 Enclave / TD / VM 内的明文内存；
篡改 Enclave 里的代码或数据并不被发现；
伪造 Enclave 的身份（Remote Attestation 的根信任在厂商 CA）。

注意：TEE 不防御 代码本身的漏洞------Enclave 里的缓冲区溢出依然可以被利用；TEE 也不直接防御侧信道攻击，这是 1.5 节的重点。

另外一个经常被忽视的点：TEE 的安全性不是绝对的 ，它是"在给定威胁模型下的可证明最小 TCB"。这意味着每一次 CPU 厂商的硬件漏洞（例如 Intel CSME 2017、AMD CPU ROP 2023）都会重写 TEE 的可信边界。严肃的生产部署应该把 TEE 的承诺定义成一个 Service Level Objective：例如"承诺在 2020 年之后公开已知的攻击面下保持机密性"，而不是"永远机密"。这种谦虚的工程态度，是 TEE 数据库真正走向合规生产的基础。

1.2 Intel SGX：进程内的"飞地"

Intel SGX（Software Guard Extensions）把保护粒度做到了进程内：一个用户态进程可以划出一段Enclave 页面缓存（Enclave Page Cache, EPC） ，CPU 负责对 EPC 的读写进行硬件级加密与完整性校验。Enclave 与外部通信通过 ECALL / OCALL 在特殊指令切换下进行。

关键限制有两个：

EPC 容量。SGX v1 只有约 128 MB EPC，v2（Ice Lake SP 以后的 Scalable SGX）扩展到单 socket 1 TB 量级。早期论文（EnclaveDB 2018）的很多设计，本质上是在"EPC 是稀缺资源"这一假设下做的。
TCB（Trusted Computing Base）很薄。除了 CPU，只需要信任 Intel 签发的 Architectural Enclave 与 SGX SDK。这是 SGX 区别于后几种 TEE 的最大特征------也是它被学术界长期追捧的原因。

SGX 的 Remote Attestation 走 EPID / DCAP 两条路径：DCAP（Data Center Attestation Primitives）在 2019 年后成为云环境主流，允许云租户自己运行 PCCS（Provisioning Certificate Caching Service），不再强制走 Intel 的 IAS。

1.3 AMD SEV-SNP：整个 VM 作为信任域

AMD 的 SEV（Secure Encrypted Virtualization）路线把保护粒度提到整个虚拟机：VM 的内存由 AMD Secure Processor（PSP）管理的密钥加密，Hypervisor 看到的全是密文。SEV-SNP（Secure Nested Paging，2020）在 SEV-ES 基础上加了 RMP（Reverse Map Table）来防止恶意 Hypervisor 的内存重映射、重放等攻击。

对数据库视角下的关键差异：

粒度粗但兼容性好。整台 VM 进 TEE，不需要像 SGX 那样改造应用分成 trusted / untrusted 两部分。MySQL / PostgreSQL 几乎可以原样跑。
TCB 更厚。Guest OS 内核、Guest 固件（OVMF）都进 TCB，攻击面比 SGX 大。
没有 EPC 容量限制。只要 VM 能分多少内存，就能保护多少。

1.4 Intel TDX 与 ARM CCA

Intel TDX（Trust Domain Extensions，2023 起在 Sapphire Rapids 上量产）是 Intel 对 SEV-SNP 路线的回应：同样以 VM 粒度，称为 Trust Domain（TD）。架构细节上，TDX 由 CPU 硬件 + 一段叫 TDX Module 的签名固件共同管理 TD 的生命周期，Hypervisor 看不到 TD 的内存。

ARM CCA（Confidential Compute Architecture，Armv9-A 起）引入"Realm"概念，由 Realm Management Monitor（RMM）在 EL3 下调度，Hypervisor 和 Realm 互相隔离。CCA 目前在 AWS Graviton 4 等芯片上开始落地，但生态（数据库侧的库、证明服务）成熟度仍落后 TDX / SEV。

一张简表汇总：

维度	SGX	SEV-SNP	TDX	ARM CCA
保护粒度	进程内 Enclave	整个 VM	整个 TD（VM）	Realm（VM 或 App）
TCB 厚度	极薄	较厚（Guest OS 在内）	较厚（Guest OS + TDX Module）	较厚
EPC / 内存容量	v1 受限，v2 TB 级	不受限	不受限	不受限
抗回滚 / Memory Integrity	硬件 MAC	RMP 表	硬件 + TDX Module	RMM
Remote Attestation	EPID / DCAP	SNP Attestation	TDX Attestation	RMM Attestation
已知侧信道 CVE	Foreshadow、ÆPIC、SGAxe 等	SEVered、CipherLeaks	TDXDown、少量	研究阶段
生态成熟度	高（学术 + Gramine / Occlum）	中（云厂商普遍支持）	中高（Azure / Google）	早期

1.5 侧信道攻击如何改写 TEE 数据库的设计

2018 年的 Foreshadow（L1TF）让 SGX 的 SEAL 密钥一度近乎"全裸"；2022 年的 ÆPIC Leak 利用 APIC 寄存器的未初始化内存泄漏 SGX 内存内容；SEVered、CipherLeaks 针对 SEV；TDXDown（2024）针对 TDX。攻防节奏大约是：厂商打一个微码补丁，学术界再找一个新路径。

这些攻击对数据库的直接影响不是"TEE 不可用"，而是两条设计规则：

访问模式（Access Pattern）必须被掩盖。即使内存明文被加密，如果 Enclave 对"哪一页"的访问顺序依赖查询值，攻击者可以通过页表、Cache、LRU 等侧信道还原数据。这就是所有 Oblivious 原语的设计出发点。
长期密钥不应只靠 TEE 守护。把主密钥（Master Key）放在 HSM / KMS 里，TEE 只做会话级密钥的派生，出事了可以整体吊销。

二、EnclaveDB、Opaque、ObliDB 三条主线

2.1 EnclaveDB（S&P 2018）：可信执行 + 只证明执行了查询

Priebe 等人在 IEEE S&P 2018 的 EnclaveDB: A Secure Database Using SGX 把 SQL Server 的存储与查询引擎搬进了 SGX Enclave。EnclaveDB 回答的问题是：假设存储是不可信的磁盘 / 云盘，计算在可信 CPU 上进行，怎么在内存开销最小的前提下保证机密性与完整性？

核心做法可以拆成三层：

加密存储 + 完整性树。数据页在磁盘上用 AES-GCM 加密，每页带 MAC；所有页的 MAC 组成一棵 Merkle B+ 树，根节点放在 Enclave 内存里。任何页的篡改都会在校验 root 时被发现。
查询代码同样进 Enclave。SQL Server 的存储引擎 + 查询执行器被裁剪后放进 Enclave，不可信 host 只负责 I/O 调度、网络。
查询证明（Query Attestation）。客户端发出查询，Enclave 返回结果 + 一个基于 Remote Attestation 的签名，证明"这份结果是在 Enclave 里用指定代码计算出来的"。

EnclaveDB 有两个工程侧值得注意的选择：使用预编译的查询计划 ，避免在 Enclave 内跑优化器；以及用主机内存做缓冲池（加密后）来绕过 SGX v1 的 EPC 容量限制。在作者公布的 TPC-C 实验上，开销相比原生 SQL Server 大约是 40% 的吞吐损失------这在 2018 年已经是相当不错的数字。

EnclaveDB 的一个有意思的技术决策是不把日志（WAL）放进 Enclave 。日志只是"操作的序列化记录"，只要操作本身在 Enclave 内执行并产生 MAC，日志本身是否被不可信存储读取并无大碍。这启发了后来一系列"计算 vs 存储"的职责划分：Enclave 做状态转换，存储做持久化 。放到 log is database 的视角看，这其实是"日志即数据库"思想和 TEE 的一次漂亮合流。

EnclaveDB 不防御访问模式侧信道，这是它和 Opaque / ObliDB 的分水岭。

2.2 Opaque（NSDI 2017）：Oblivious 原语搬进 Spark SQL

Zheng 等人在 NSDI 2017 的 Opaque: An Oblivious and Encrypted Distributed Analytics Platform 走了更激进的路线：在 Spark SQL 上做 OLAP 分析，不仅加密，还要访问模式无关。

Opaque 提供三档安全级别，给用户按需选择：

Encryption Mode：只加密，类似 EnclaveDB 的强度，性能开销最小。
Oblivious Mode：加密 + 保证 Enclave 读写模式不依赖数据值，防止页面级侧信道。
Oblivious + Volume-hiding：进一步掩盖每个 task 的输出大小（Volume）。

关键原语有两条：

Oblivious Sort：采用 Bitonic Sort 或 Sorting Network，保证比较序列完全与数据无关。复杂度从 O(N log N) 退化到 O(N log² N)，是性能主要来源。
Oblivious Shuffle：Spark 原生的 partition-based shuffle 会泄漏 key 分布，Opaque 用 oblivious padding + random permutation 隐藏真实 key 分布。

在作者报告的 TPC-H 子集上，Oblivious Mode 相比纯加密模式开销 1.6× ~ 46× 不等，取决于查询里排序 / 聚合的比重。这个数字说明了一个残酷的事实：完全的访问模式无关，对 OLAP 是非常贵的。

2.3 ObliDB（VLDB 2020）：把 oblivious 做进 OLTP 索引

Eskandarian 与 Zaharia 在 VLDB 2020 的 ObliDB: Oblivious Query Processing for Secure Databases 把关注点从 OLAP 挪到了 OLTP 风格的点查 / 范围查 / join。它的核心贡献是为不同查询形态设计不同的 oblivious 物理算子：

Point Query：基于 Path ORAM 的索引遍历；
Range Query：在 B+ 树上做 padded 扫描，加上 dummy 访问填平真实访问；
Small Join / Big Join：分别用 oblivious hash join 与 oblivious sort-merge join。

ObliDB 的"机灵"之处在于为不同基数（Cardinality）的查询自动选择不同强度的 oblivious 算子------它其实把"基于代价的优化器"思想搬到了 oblivious 世界：代价模型里的度量单位从 I/O 变成了"oblivious cost"。

在 ObliDB 的实验里，点查相对明文的开销在 1.2× ~ 2× 量级；小 join 在 3× ~ 10×；大 join 到了 50× 以上。这也是下半部分要强调的结论：点查可行、小 join 勉强、大 join 基本不行。

值得专门点出的是，ObliDB 并不是把 Opaque 做"向下移植"到 OLTP，二者的基本抽象层完全不同：Opaque 是 Spark SQL 的 Rule-based 重写，ObliDB 直接修改了 B+ 树算子；Opaque 假设数据集放得下 shuffle，ObliDB 假设索引可以被 oblivious 访问。所以如果你要真正构建一套混合 OLTP+OLAP 的 TEE 数据库，两篇论文提供的是正交的构件，不是相互替代的方案------这点在读原文时容易被混淆。

2.4 Oblivious 原语速览

上面三篇论文反复用到的 oblivious 原语，可以整理成一张对照表：

原语	明文复杂度	Oblivious 复杂度	典型用途
Linear Scan	O(N)	O(N)	小表全扫
Sort（Bitonic）	O(N log N)	O(N log² N)	ORDER BY、sort-merge join
Sort（AKS）	O(N log N)	O(N log N) 理论	常数极大，工程不用
Hash Join	O(N+M)	O((N+M) log²(N+M))	等值 join
Range Scan	O(log N + k)	O(log N + K) K=paddedSize	范围查询
Path ORAM Access	O(log N)	O(log² N) 有常数	点查、随机访问
Oblivious Shuffle	O(N)	O(N log² N)	Shuffle 阶段

注意：这里的"Oblivious 复杂度"并不总是最坏上界，而是工程实现里稳定达到的阶。学术上还有 Goodrich 的 O(N log N) oblivious sort（2014）、Asharov 等人 OptORAMa（Eurocrypt 2020）的 O(log N) ORAM 等结果，但常数大到难以工程化。

2.5 一份最小的 Oblivious Sort 伪代码

为了让上面的复杂度不停留在抽象层，把 Bitonic Sort 的核心写成伪代码：

python 复制代码

def bitonic_compare(a, i, j, direction):
    # 常数时间：无论 a[i] 与 a[j] 的关系如何，都执行一次 swap 判断
    # 关键是不能用"if a[i] > a[j]: swap"这种有数据依赖的分支
    cond = (a[i] > a[j]) == direction
    x = cond * a[j] + (1 - cond) * a[i]
    y = cond * a[i] + (1 - cond) * a[j]
    a[i], a[j] = x, y

def bitonic_merge(a, lo, n, direction):
    if n > 1:
        k = n // 2
        for i in range(lo, lo + k):
            bitonic_compare(a, i, i + k, direction)
        bitonic_merge(a, lo, k, direction)
        bitonic_merge(a, lo + k, k, direction)

def bitonic_sort(a, lo, n, direction):
    if n > 1:
        k = n // 2
        bitonic_sort(a, lo, k, True)
        bitonic_sort(a, lo + k, k, False)
        bitonic_merge(a, lo, n, direction)

它的"oblivious"体现在：比较顺序完全由 n 决定 ，与数据无关。放在 Enclave 里执行时，只要 bitonic_compare 本身是常数时间（避免条件跳转、避免 cache 不一致），访问模式就不会暴露任何数据信息。工程实现里还要做一步"padding 到最近的 2 的幂"，防止长度本身泄漏信息。

ObliDB 的一个重要优化是：不所有阶段都用 bitonic。当数据量小于某个阈值（例如 EPC 可完整容纳）时，用 oblivious linear scan 其实更快，因为 bitonic 的常数在小数据上占比太大。这种"按规模切换算法"的思路，与传统 CBO 里"hash vs merge join"的切换非常相似。

2.6 侧信道与 Oblivious 的真实关系

一个常被混淆的点：Oblivious 原语本身并不防御所有侧信道，它防的是**访问模式（Access Pattern）**这一类。对于：

时间侧信道（Timing）：需要算法本身常数时间（Constant-Time），与 oblivious 互为补充；
功耗 / 电磁侧信道：需要硬件层面的屏蔽，TEE 与 oblivious 都不直接覆盖；
瞬态执行攻击（Transient Execution）：Foreshadow、Meltdown、Spectre 类，需要微码 + 编译器 mitigation；
架构侧信道（Cache / TLB）：oblivious 设计需要额外把 cache line 粒度也考虑进来，常规 bitonic sort 默认只做到页粒度无关。

所以一个严肃的 TEE 数据库项目，实际上要叠加：TEE 硬件 + 代码常数时间化 + Oblivious 算子 + 补丁后的微码 + 远程证明 + 密钥分离存储，才能拿到真正意义上的安全保证。单独吹任何一层，都是不够的。

三、工程落地：Azure Confidential SQL 与 AWS Nitro Enclaves

3.1 Azure Confidential SQL / Always Encrypted with Secure Enclaves

微软在 SQL Server 2019 起引入 Always Encrypted with Secure Enclaves ，Azure SQL 上对应的是 Azure Confidential SQL。工程上它采用的组合是：

SGX（早期）/ SEV-SNP / TDX（现代）作为 Enclave 底层；
客户端 ADO.NET / JDBC 驱动持有列加密密钥（Column Encryption Key, CEK），Enclave 里只看到 CEK 在 KMS 的派生密钥；
支持的加密计算：相等比较（Equality）、范围比较、LIKE、JOIN 的等值连接、排序；不支持：复杂的 UDF、全文搜索、空间函数。

这一点对工程选型非常关键：Always Encrypted 不是"所有 SQL 都能跑"，它是在明确列出支持的运算集合前提下开放给你。实际生产用法通常是：

sql 复制代码

-- 声明列使用随机加密（Randomized Encryption），只能等值判断
CREATE TABLE Employees (
    EmployeeId INT PRIMARY KEY,
    Name NVARCHAR(200) COLLATE Latin1_General_BIN2
        ENCRYPTED WITH (
            COLUMN_ENCRYPTION_KEY = CEK_Auto1,
            ENCRYPTION_TYPE = Randomized,
            ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
        ),
    Salary DECIMAL(18,2)
        ENCRYPTED WITH (
            COLUMN_ENCRYPTION_KEY = CEK_Auto1,
            ENCRYPTION_TYPE = Randomized,
            ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
        )
);

然后在 WITH (ENCLAVE_COMPUTATIONS = 'ENABLED') 的查询会话里可以做范围 / LIKE。开销方面，微软公开的基准显示：

单点查：10% ~ 30% 延迟开销；
范围扫描：1.5× ~ 3× 开销；
复杂分析（多表 join + 聚合）：官方直接建议"不要这么用"。

3.2 AWS Nitro Enclaves：另一条路线

AWS 没有直接推 SGX，而是用 Nitro Hypervisor 切出独立 vCPU + 独立内存的 Enclave，没有持久化存储、没有网络，只通过 vsock 和父 EC2 通信。和 SGX 比：

优点：EPC 容量就是分多少内存就有多少；TCB 里没有 guest OS（通常跑 EIF------Enclave Image File------类似一个打包好的 mini kernel）；attestation 由 Nitro Security Module（NSM）完成，不依赖第三方 CA。
缺点：没有持久化，数据库本身要跑在外面，Enclave 只做密钥管理 + 敏感片段计算。

所以 AWS 生态上的"TEE 数据库"通常不是把整个 PostgreSQL 塞进 Nitro Enclave，而是：

用 Enclave 做 KMS 的解密代理；
用 Enclave 运行 ML 推理 / 数据脱敏 / 合规审计函数；
数据库本体用 RDS / Aurora 的列级加密。

这条路线的含义是：在 AWS 上做"TEE 数据库"，往往是在应用层拼装，而不是替换数据库内核。对大多数企业用户来说，这反而是个更工程友好的抽象------你不需要修改 PostgreSQL 源码。

一个典型的 Nitro Enclaves 解密代理拓扑是这样的：

text 复制代码

   client --- TLS ---> EC2 host
                       |  vsock (attested channel)
                       v
                   Nitro Enclave
                       |  KMS attestation-bound Decrypt
                       v
                    AWS KMS

KMS 通过 kms:RecipientInfo 字段把解密结果用 Enclave 的公钥包一层，只有该 Enclave 能解出来。这样即便 EC2 host 被攻破，它看到的仍然是密文------Enclave 成了"一次性密钥容器"。这种模式在金融行业做"客户信息解密代理"很常见。

3.3 性能开销量级：给工程师的参考数字

合并前面的论文和厂商公开数据，给一张经验性的开销表（以纯明文为 1×）：

场景	仅加密（EnclaveDB / Always Encrypted）	Oblivious（Opaque / ObliDB）
点查（主键等值）	1.1× ~ 1.5×	1.5× ~ 3×
范围扫描（10k ~ 1M 行）	1.5× ~ 3×	3× ~ 10×
等值 Join（小表 + 大表）	1.5× ~ 4×	5× ~ 20×
聚合（GROUP BY）	2× ~ 4×	10× ~ 30×
复杂 OLAP（多 join + 排序）	3× ~ 8×	30× ~ 100×

这张表不是严格基准，只用于估算可行性。结论很直白："仅加密" 档在 OLTP 和中等 OLAP 上都是可接受的；"Oblivious" 档只推荐在确实需要防侧信道的场景下使用。

一个容易被忽略的维度是尾延迟（Tail Latency） 。Enclave 的 ECALL / OCALL 切换和 attestation 验证都会带来偶发毫秒级延迟，在 p99 / p999 上会比平均值放大 3 倍左右。做 SLA 承诺时要基于 p99，而不是 p50。另外，SGX / TDX 下页面加密会让大页（Huge Page）场景的 TLB miss 成本显著上升，内存密集型分析任务对此尤其敏感------把 OLAP 扫描的 batch 大小调到和 EPC 子页对齐，经常能拿到 20% 以上的吞吐提升。

再一个工程细节：远程证明证据的生命周期。Intel SGX DCAP 签发的 attestation quote 默认有效期较短（常见 24 小时），过期后需要重新走一轮 PCCS → TCB info → quote 的刷新流程。业务峰值期间不小心让证据过期会导致会话全部掉线。最佳实践是在后台提前 6~8 小时刷新、滚动替换，而不是被动等待过期告警。这种"可观测性先行"的姿态，对 TEE 生产化至关重要。

3.4 一个真实的部署参考架构

把上面所有要点串成一张图，一家中等规模银行的"TEE OLTP + OLAP"架构可能是这样：

text 复制代码

  ┌─────────────────────────────────────────┐
  │        客户端（手机 App / 后台服务）          │
  │  - 持有列加密密钥 CEK（从 HSM 下发）           │
  │  - ADO.NET / JDBC 驱动做透明加解密             │
  └───────────────┬─────────────────────────┘
                  │ TLS + Attested Session
                  v
  ┌─────────────────────────────────────────┐
  │  Azure Confidential SQL（TDX VM）         │
  │  ┌───────────────┐  ┌─────────────────┐ │
  │  │ Query Engine  │  │  Secure Enclave │ │
  │  │ (明文索引)    │→→│ (CEK 派生 + 比较) │ │
  │  └───────────────┘  └─────────────────┘ │
  └───────────────┬─────────────────────────┘
                  │ CDC（密文 + MAC）
                  v
  ┌─────────────────────────────────────────┐
  │  Lakehouse（Iceberg on S3）               │
  │  - 列级加密，密钥由 HSM 管理              │
  │  - OLAP 作业在 Nitro Enclave 里解密片段    │
  └─────────────────────────────────────────┘

这个架构的几个刻意选择：

OLTP 用 TDX VM 粒度：兼容性好，不用改 SQL Server 内核。
OLAP 不做全 oblivious：性能接受不了，改为"只在 Nitro Enclave 里解密需要聚合的列片段"。
CEK 双钥策略：每个业务域一把，出事可以精细吊销；MK 永远不离开 HSM。
审计日志走 attested logging：Enclave 对每次解密调用签名，外部审计系统验证签名链。

这类架构通常的 RTO 要求是分钟级，而 attestation 验证本身要几百毫秒到几秒------所以attestation 缓存策略（在有效期内复用 attestation 证据）非常关键，这也是 Intel DCAP 引入 PCCS 的主要动机。

3.5 成本视角

最后把"钱"这件事也带上。与同规格普通 VM 相比：

Azure DCasv5 / DCesv5（SEV-SNP / TDX）相比 Dasv5 贵 5% ~ 15%；
AWS Nitro Enclaves 本身不额外收费，但通常需要更大实例（因为 Enclave 会锁一部分 vCPU 与内存）；
如果上 Oblivious 档，等效的算力需求放大 3× ~ 10×，TCO 会线性放大。

"仅加密"档在多数合规场景下是成本可控的，这是它成为默认方案的真正原因。

想清楚存储层如何做"透明加密"，可以看 LSM-Tree 工程实践里谈到的 block encryption 接口。
想理解远程证明为什么需要分布式共识，可以回到共识协议系列。
想看隐私计算的另一条路径（差分隐私、FHE、PIR），下一篇差分隐私数据库与再下一篇 FHE 与 PIR 会补齐整块拼图。

3.6 踩坑清单

几点实战里反复出现的教训：

不要把 attestation 验证逻辑写成 if-else。一定走厂商提供的 SDK（Intel DCAP、AMD snpguest、AWS NSM），攻击面最小。自己拼接验证流程最常见的坑是漏掉了 TCB Level、漏掉了 CRL 检查，或者没有对比 MRENCLAVE / MRSIGNER 的白名单。
密钥分层。主密钥（MK）放 HSM / KMS；数据加密密钥（DEK）放 Enclave；会话密钥（Session Key）每次 attest 后重新派生。任何一层泄漏，其他层应能独立吊销。
TEE 升级节奏很高。SGX、SEV、TDX 微码补丁几乎每季度一次，生产环境要有滚动升级 + 快速 attestation policy 更新机制，否则某个 CVE 出来后整个集群会拒绝验证。建议在基础设施层维护一张"当前可接受 TCB 等级"的配置表，由安全团队统一更新。
别在 Enclave 里跑优化器。查询优化器需要统计信息、内存开销大、代码复杂度高，EnclaveDB 采用"预编译执行计划"是有原因的。现代实践里更常见的做法：优化器在 Enclave 外跑、最终 plan 带签名进 Enclave。
监控要考虑"加密可观测性"。Enclave 内的日志本身是密文，传统 APM / tracing 基本失效，需要设计一套 attested logging 机制------日志在 Enclave 内签名、外部系统只做收集与存档，告警规则基于密文元数据（如时间、调用次数）而非内容。
侧信道不是 0/1 的问题。除非业务场景明确提出"抗内部管理员"的威胁模型，否则优先选"仅加密" 档；不要因为论文好看就上 oblivious。一个务实的起点：先跑一遍威胁建模（STRIDE / LINDDUN），列出实际需要防御的攻击者，再反推需要哪一档安全级别。
测试流程要覆盖 attestation 失败路径。生产事故中最常见的不是"机密泄漏"，而是"某台机器 TCB 降级了，整批连接被拒绝"。CI 里要能模拟 attestation 失败、过期、TCB 回退三种路径。

四、开放问题与路线判断

4.1 研究侧的开放问题

TEE 数据库领域目前有几个明显的开放问题：

Oblivious 算子的真实可用阈值。当前最好的 oblivious sort 仍是 O(N log² N)，对 10 亿行以上的分析基本不可行。是否存在针对数据库场景的专用 oblivious 算子（带常数优化）是长期研究方向。一个值得关注的思路是"近似 oblivious"：允许泄漏一点点访问信息（例如每 1000 条访问泄漏 1 bit），换取接近明文的性能。这种"可量化泄漏"框架（Differential Obliviousness）开始在 2022 年后出现。
跨 TEE 互操作。SGX 里的 Enclave 要和 SEV VM 互相 attest，目前需要一个 broker。RFC 9334（RATS Architecture）给出了通用框架，但数据库侧没人真正实现过完整的异构 attestation 流。实际业务中"多云 + 多 TEE"会越来越常见------比如 OLTP 在 Azure TDX、OLAP 在 AWS Nitro、冷存储在 GCP CCA------中间的信任链怎么连，至今没有标准答案。
ML / 向量检索 + TEE 。向量索引（HNSW、IVF-PQ）本身访问模式泄漏大量信息，简单塞进 TEE 收益有限。HNSW 的图遍历顺序高度依赖查询向量，观察者几乎可以反推 query embedding。与向量索引的结合方式（oblivious HNSW 是否可行）是个值得追踪的方向。目前已有 ObliCheck、SANNS 等初步尝试，但开销仍在 20× 以上。
后量子密码对 TEE 的冲击。Remote Attestation 里的签名算法（ECDSA）终将迁移到 ML-DSA / SLH-DSA。厂商的 roadmap（Intel、AMD、ARM）都还没有明确时间表。对数据库而言更棘手的是：历史 attestation 证据如果在 2035 年后还想被验证，现在就必须规划"可升级的 attestation 格式"，否则十年后所有审计证据都作废。
TEE 与共识的交互。如果几个 Enclave 之间跑 Paxos / Raft，那么"节点身份"应当绑定到 attestation 而不是静态证书；这涉及到如何在 leader 切换、节点加入 / 退出时重新验证。2023 年前后已有 AttestedRaft 之类论文，但没有进入主流数据库。

4.2 路线判断

路线判断上，作者的个人立场：

未来 3 年，TDX / SEV-SNP 会成为"合规默认项"------大多数云数据库会静默地跑在 confidential VM 里，用户可能根本感知不到。"仅加密"档会标准化。Azure、GCP 已经在部分 region 默认开启 confidential computing，AWS 跟进只是时间问题。
Oblivious 数据库仍会是小众。OLAP 上的开销太大，只有特定行业（医疗联邦分析、央行清算、跨境数据流通）才会用。它的真正价值可能不在"整库 oblivious"，而在"关键列 oblivious"------像 Always Encrypted 那样粒度化。
学术重心从 SGX 向 TDX / CCA 迁移。SGX 的 server 路线基本停在 Ice Lake SP，新 server 芯片只有 TDX；ARM CCA 是开放研究热点。SIGMOD 2024 / VLDB 2024 已经能看到论文主 TEE 切换的趋势。
"可验证计算（Verifiable Computing）" 会补上 TEE 的短板。TEE 给了机密性，但"可审计性"仍然依赖对厂商的信任（Intel / AMD 的签名链）。zk-SNARK、zk-STARK 在小批量数据上逐渐可用，未来可能出现"TEE 做批量计算 + zk 做关键证明"的混合架构，这类似区块链界的"Rollup + Prover"范式被搬到数据库语境。

五、小结

TEE 数据库不是"银弹"，但它把"机密数据 + 不可信云"这个过去只能靠 FHE（见下一篇 FHE 与 PIR）硬扛的问题，压到了一个工程上可接受的开销区间。过去十年的进步是巨大的：SGX 刚出现时，学术界还在争论"EPC 只有 128 MB 的数据库到底有什么用"；而到 2026 年，TDX / SEV-SNP 已经可以把上百 GB 的内存库照搬进机密 VM，而不改一行 SQL 代码。

把本文压成三条可以带走的结论：

先定威胁模型，再选 TEE 粒度。抗云管理员选 VM 粒度（SEV-SNP / TDX）；抗内核且 TCB 要小选进程粒度（SGX / CCA Realm-App）。威胁模型不写清楚就上 TEE，常常做成性能损失真金白银、威胁实际没覆盖的"形式合规"。
先上"仅加密"档。EnclaveDB 路线已经足够覆盖大多数合规需求，Oblivious 档留给确实有侧信道威胁的场景。把 oblivious 做成可选项而不是强制项，在工程上可以保留优化空间。
把 TEE 当成"密钥与小段计算的执行器"，而不是"整个数据库的替代品"。Nitro Enclaves 的路线在工程上更可持续。Azure 的 Always Encrypted 也是"粒度化 TEE 使用"思路的代表。

下一篇差分隐私数据库换一条完全不同的隐私计算路径：不再假设"攻击者看不到数据"，而是允许他看到聚合结果，只保证"看不到个体信息"。再下一篇 FHE 与 PIR 则把加密计算的理论上界摆出来。三篇合在一起，才是完整的数据库隐私工程谱系。

参考文献

Priebe C., Vaswani K., Costa M. EnclaveDB: A Secure Database using SGX. IEEE S&P 2018.
Zheng W., Dave A., Beekman J. G., Popa R. A., Gonzalez J. E., Stoica I. Opaque: An Oblivious and Encrypted Distributed Analytics Platform. NSDI 2017.
Eskandarian S., Zaharia M. ObliDB: Oblivious Query Processing for Secure Databases. VLDB 2020.
Van Bulck J., et al. Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution. USENIX Security 2018.
Borrello P., Kogler A., Schwarzl M., Lipp M., Gruss D., Schwarz M. ÆPIC Leak: Architecturally Leaking Uninitialized Data from the Microarchitecture. USENIX Security 2022.
Kaplan D., Powell J., Woller T. AMD Memory Encryption (SEV) White Paper. AMD, 2021.
Intel. Intel Trust Domain Extensions (TDX) Module Architecture Specification, v1.5. Intel, 2023.
ARM. Arm Confidential Compute Architecture (CCA) Specification. Arm Ltd., 2023.
Microsoft. Always Encrypted with Secure Enclaves in SQL Server 2019+. Microsoft Docs（待核实最新版本号）.
Amazon Web Services. AWS Nitro Enclaves User Guide. AWS Documentation.
Goodrich M. T. Zig-zag Sort: A Simple Deterministic Data-Oblivious Sorting Algorithm Running in O(N log N) Time. STOC 2014.
Asharov G., Komargodski I., Lin W.-K., Nayak K., Peserico E., Shi E. OptORAMa: Optimal Oblivious RAM. EUROCRYPT 2020.

上一篇 ：【数据库研究前沿】新型 NVM 与存储层级重构

下一篇 ：【数据库研究前沿】差分隐私数据库：PINQ、APEx 到生产级 DP-SQL