SQL Server存储过程不能管理数据库级加密密钥（DEK），仅支持列级加密操作；必须显式打开对称密钥，校验密钥存在性，并用TRY...CATCH确保关闭；TDE和证书等服务器级对象不可在存储过程中创建或修改。
存储过程中不能直接管理数据库级加密密钥
SQL Server 的 DATABASE ENCRYPTION KEY（DEK）是数据库级别的资源，由 SQL Server 引擎全权控制，**不能在存储过程中创建、修改或删除**。任何试图在 CREATE PROCEDURE 或 EXEC 中执行 CREATE DATABASE ENCRYPTION KEY 或 ALTER DATABASE ... SET ENCRYPTION ON 的操作都会报错：Msg 155, Level 15, State 1: CREATE DATABASE ENCRYPTION KEY is not allowed in procedures. —— 这是硬性限制，不是权限问题。
存储过程里能安全操作的只有列级加密密钥
如果你需要在存储过程中动态加解密数据，唯一可行路径是使用列级加密（如 ENCRYPTBYKEY / DECRYPTBYKEY），且必须满足以下条件：
-
OPEN SYMMETRIC KEY必须在当前会话中显式执行（不能靠调用者“传入”已打开状态）； - 对称密钥需提前用证书或非对称密钥保护，且该证书/非对称密钥必须存在于当前数据库中；
- 存储过程需有
VIEW DEFINITION权限查看密钥元数据，以及CONTROL或ALTER权限操作密钥（通常授予db_owner角色更实际）； - 避免在存储过程中硬编码密码或密钥名——用参数传入密钥名称（如
@KeyName），但必须校验其是否真实存在（查sys.symmetric_keys）再调用OPEN，否则会静默失败。
示例片段：
CREATE PROCEDURE dbo.usp_EncryptSSN
@SSN nvarchar(11),
@KeyName sysname
AS
BEGIN
IF NOT EXISTS (SELECT 1 FROM sys.symmetric_keys WHERE name = @KeyName)
THROW 50000, 'Symmetric key does not exist', 1;
OPEN SYMMETRIC KEY @KeyName DECRYPTION BY CERTIFICATE MyCert;
SELECT ENCRYPTBYKEY(KEY_GUID(@KeyName), @SSN) AS EncryptedValue;
CLOSE SYMMETRIC KEY @KeyName;
END;
误把 TDE 密钥当“可编程对象”是常见陷阱
很多开发者看到 sys.dm_database_encryption_keys 视图就以为能像普通表一样 CRUD，结果在存储过程中写 DROP DATABASE ENCRYPTION KEY 直接被拒绝。记住：
- TDE 加密开关（
SET ENCRYPTION ON/OFF）只能由sysadmin或db_owner在独立批处理中执行，无法封装进存储过程； - 证书和主密钥（
MASTER KEY、CERTIFICATE）同样不可在存储过程中创建——它们属于服务器/数据库级别安全对象，需 DBA 提前配置； - 若业务逻辑真需要“按需加密某张表”，正确做法是：存储过程只负责触发预定义的作业（
sp_start_job），由 SQL Agent 以高权限上下文执行 TDE 操作，而非自己越权。
Always Encrypted 场景下密钥根本不出现在 SQL Server 中
如果你用的是 Always Encrypted，那存储过程中连“密钥管理”的概念都不存在——列主密钥（CMK）和列加密密钥（CEK）全部由客户端驱动处理，SQL Server 只看到加密后的 varbinary 值。此时所谓“安全管理”其实是：确保连接字符串启用 Column Encryption Setting=Enabled，且应用程序能访问 Azure Key Vault / Windows Certificate Store 等外部密钥存储。任何试图在存储过程中调用 ENCRYPTBY.../DECRYPTBY... 的尝试都会失败，因为这些函数不支持 AE 列。
真正容易被忽略的一点：列级加密密钥一旦打开，会话内所有后续 ENCRYPTBYKEY 都复用它，但密钥不会自动关闭。如果存储过程异常退出，CLOSE SYMMETRIC KEY 可能没执行，导致会话残留密钥句柄——虽然不影响功能，但会增加审计难度。建议统一用 TRY...CATCH 包裹并强制关闭。
