系统常识 SQL ServerAlways Encrypted加密
Always Encrypted 是什么？解决什么问题
Always Encrypted 的加密模型：数据在客户端侧加密、引擎侧只见密文，与 TDE 的分工区别，适用场景（敏感列防内部越权）与代价。
发布于 2026/11/11
所属频道 SQL Server
结论先行
Always Encrypted 解决的是信任边界内的问题：数据库内容对「能进引擎的人」（DBA、运维、有权限的查询）保持密文，只有持有列主密钥的应用侧能解密。数据落盘仍是加密的（叠加 TDE 后更完整），但引擎执行时看到的也是密文——这是它与 TDE（引擎侧透明加解密）的本质分工。
与 TDE 的分工
| 维度 | Always Encrypted | TDE |
|---|---|---|
| 加解密位置 | 客户端/应用侧 | 引擎侧（对应用透明） |
| 防谁 | 防 DBA、运维等「引擎内可见者」 | 防磁盘/备份文件被偷走 |
| 引擎看到什么 | 密文 | 明文 |
| 查询/索引 | 部分列可用确定性加密建索引 | 无限制 |
| 适用版本 | 需要支持该特性的引擎版本（以条目页为准） | 付费版本普遍具备 |
两者不是替代关系而是叠加关系：TDE 保住「介质丢了不泄露」，Always Encrypted 保住「人有权进库也看不到」。敏感列想两头都保就两个都上。
代价与取舍
- 随机加密列：密文不可比较，
WHERE 列 = 值这类过滤基本用不了，只能全量拉回应用侧筛——列选这类加密要掂量查询模式。 - 确定性加密列：可比较、可建索引，但同值同密文会泄露「哪些行相同」。
- 密钥管理：列主密钥（CMK）要放引擎够不到的地方（如 Windows 证书库、HSM），应用负责取用。
配置路径（SSMS）
- SSMS 管理工具条目 中表设计里将列标记为「加密列」（随机/确定性）；
- 建列主密钥（CMK）与列主密钥（CKM）；
- 应用侧驱动开启列加密后写入/读取。
SQL Server 2022 Developer 条目环境可完整演练配置流程；TDE 与加密矩阵的关系另见「透明数据加密 TDE」相关条目，SQL Server 产品族条目 中各版本特性支持以条目页为准。