SQL Server数据加密：为何需用证书保护对称密钥

首先纠正一个常见误解：SQL Server不支持创建无任何保护的明文对称密钥，你以为的“直接用对称密钥加解密”，本质上是创建对称密钥时选择了密码作为加密保护器，把密码硬编码在调用脚本里而已，这恰恰是安全层面的反模式。

用证书（或者非对称密钥）保护对称密钥是SQL Server加密分层设计的标准实践，核心原因有三个：

• 从根源减少密钥泄露风险。如果用密码直接加密对称密钥，每次调用密钥加解密数据前，必须手动执行OPEN SYMMETRIC KEY ... DECRYPTION BY PASSWORD = 'xxx'，意味着你必须把密码写在业务代码、存储过程或者调度脚本里，只要代码仓库泄露、配置文件泄露，整个加密体系直接失效。而用证书保护对称密钥时，证书的私钥受数据库主密钥、服务主密钥的两层自动保护，只要调用账号有对应证书和密钥的权限，SQL Server会自动完成密钥的解密加载，全程不需要在业务层传递、存储任何密钥相关的密码，攻击面小很多。
• 密钥管理成本更低、风险更小。你可以给同一个对称密钥绑定多个加密保护器（比如同时绑定证书、密码），后续做密钥轮换、权限调整的时候，只需要新增新的保护器绑定、删除旧的保护器即可，不需要重新加密所有已经用该对称密钥加密过的业务数据。如果是用密码直接保护对称密钥，修改密码就需要重新解密、加密整个对称密钥，操作过程中一旦出问题，所有加密数据都可能无法恢复。
• 满足合规审计要求。等保、PCI DSS、GDPR这类通用合规规范都明确要求加密密钥必须分层存储，数据加密密钥（也就是你用来加解密业务数据的对称密钥）不能和加密数据存放在同一个安全域内。证书属于非对称加密载体，私钥由数据库内置的安全存储区单独管控，和业务数据、对称密钥逻辑隔离，完全符合合规要求；直接用密码保护对称密钥的模式，密钥保护凭据和业务数据存放在同一个库内，无法通过合规审计。

你贴的示例代码就是标准的三层加密层级结构，每层的作用如下：

USE SOMEDB
GO

-- 数据库级主密钥：是数据库内所有证书、非对称密钥的保护根，本身受实例级的服务主密钥（安装SQL Server时自动生成、和当前实例绑定）和你设置的管理员密码双重保护
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '***';  
GO  

-- 证书：作为密钥加密密钥，专门用来保护下层的对称密钥，不直接参与业务数据加解密
CREATE CERTIFICATE [some_cert] WITH SUBJECT = 'Key Protection';  
GO  

-- 对称密钥：实际用来加解密业务数据的密钥，本身的密文由上一层的证书加密存储，不会以明文形式落盘
CREATE SYMMETRIC KEY [some_sem_key] WITH  
    KEY_SOURCE = 'My key generation bits. This is a shared secret!',
    ALGORITHM = AES_256,   
    ENCRYPTION BY CERTIFICATE [some_cert];  
GO 

两种使用方式的差异可以直观对比：

用密码直接保护对称密钥的调用方式（不推荐）：

-- 必须把硬编码的密码写在代码里，泄露风险极高
OPEN SYMMETRIC KEY [some_sem_key] DECRYPTION BY PASSWORD = 'HardcodedPassword123!';
-- 执行数据加解密操作
INSERT INTO EncryptedTable(EncryptedCol) VALUES (EncryptByKey(Key_GUID('some_sem_key'), '敏感数据'));
-- 手动关闭密钥
CLOSE SYMMETRIC KEY [some_sem_key];

用证书保护对称密钥的调用方式（推荐）：

-- 不需要手动打开密钥、不需要写任何密码，只要账号有权限就可以直接调用
INSERT INTO EncryptedTable(EncryptedCol) VALUES (EncryptByKey(Key_GUID('some_sem_key'), '敏感数据'));

内容的提问来源于stack exchange，提问作者Dimash