使用Microsoft Identity搭配Always Encrypted是否安全？

结论是：安全，且是微软官方推荐的敏感数据加密方案，但需要注意适配Always Encrypted的查询限制，避免触发Identity的异常行为。以下是具体分析和建议：

一、安全性层面的确认 #

Always Encrypted是SQL Server（及其他支持的数据库）的内置加密机制，加密/解密操作发生在客户端（EF Core层面），数据库存储的始终是密文，甚至数据库管理员都无法直接获取明文邮箱。这完全符合你防止邮箱泄露的需求，安全性有官方背书，比自行实现ILookupProtector更可靠。

二、与Microsoft Identity的兼容性适配 #

Identity默认的核心操作（登录、邮箱确认、用户查询）大多依赖EF Core的参数化查询，而Always Encrypted支持参数化查询的解密对比，所以只要配置正确，大部分场景可以正常工作：

• 比如UserManager.FindByEmailAsync()方法，EF会自动生成参数化查询，数据库端能正确解密参数并匹配加密列，不会触发查询限制。
• 需要避免的是直接写非参数化的SQL语句（比如自定义的FromSqlRaw调用中硬编码邮箱常量），这类操作会因为数据库无法解密常量而报错。
• 少数受限场景：如果你的业务需要对邮箱列做数据库端的排序、模糊查询（如LIKE '%xxx%'）、创建非聚集索引，这些操作在加密列上无法执行，但Identity的默认流程几乎不会用到这些，所以影响极小。

三、对比自行实现方案的优劣 #

你考虑的完全绕开Identity的方案，虽然能完全控制数据存储和流程，但存在明显短板：

• 需要自行实现密码哈希、令牌生成（邮箱确认、重置密码）、ClaimsPrincipal构建、授权验证等所有Identity已封装的功能，不仅开发成本高，还容易遗漏安全细节（比如密码哈希的迭代次数、令牌的过期验证、防暴力破解机制）。
• 而基于Identity+Always Encrypted的方案，既能复用Identity经过大量验证的安全逻辑，又能满足数据加密需求，是更高效、更安全的选择。

四、具体实施建议 #

1. 先在SQL Server中配置Always Encrypted的主密钥和列加密密钥（可通过SSMS或PowerShell完成）。
2. 修改EF Core的迁移文件，给Email列添加加密配置，确保生成的数据库列使用指定的列加密密钥。
3. 确保应用程序拥有访问主密钥的权限（比如使用Azure Key Vault托管密钥，或配置本地证书）。
4. 测试Identity的核心流程：注册、登录、邮箱确认，验证是否正常执行，排查是否存在非参数化查询的场景并修正。

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