你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
用于数据加密的推荐
适用于架构良好的框架安全性检查列表建议：
| 标准版：07 | 使用现代行业标准方法来加密数据，以保护机密性和完整性。 使加密范围与数据分类保持一致;确定本机平台加密方法的优先级。 |
|---|
如果数据不受保护，可能会受到恶意修改，从而导致完整性和机密性丢失。
本指南介绍了加密和保护数据的建议。 加密是使用加密算法 使数据不可读并用密钥锁定数据的过程。 在加密状态下，无法对数据进行解码。 只能使用与加密密钥配对的密钥来解密它。
定义
| 条款 | 定义 |
|---|---|
| Certificates | 保存用于加密或解密的公钥的数字文件。 |
| 密码套件 | 一组用于加密和解密信息的算法，用于通过传输层安全性（TLS）保护网络连接。 |
| 机密计算 | 机密计算是通过在基于硬件的、经证明的受信任执行环境中执行计算来保护正在使用的数据。 |
| 解密 | 使用机密代码解锁加密数据的过程。 |
| 双重加密 | 使用两个或更多独立加密层来加密数据的过程。 |
| 加密 | 数据不可读和锁定的机密代码的过程。 |
| 哈希 | 将数据转换为具有隐藏信息意图的文本或数字的过程。 |
| “键” | 用于锁定或解锁加密数据的机密代码。 |
| Signature | 对数据进行身份验证的加密标记。 |
| 签名 | 使用签名验证数据的真实性的过程。 |
| X.509 | 定义公钥证书格式的标准。 |
关键设计策略
组织授权或法规要求可能会强制实施加密机制。 例如，可能要求数据必须仅保留在所选区域中，并且数据的副本将保留在该区域中。
这些要求通常是最低要求。 努力提高保护水平。 你负责 防止机密性泄露和篡改敏感数据，无论是外部用户数据还是员工数据。
加密方案
加密机制可能需要在三个阶段保护数据：
静态 数据是存储在存储对象中的所有信息。
保护静态数据的示例是使用 BitLocker 加密保存到磁盘上的存储的数据。
传输 中的数据是在组件、位置或程序之间传输的信息。
保护传输中的数据的一个示例是使用 TLS 加密数据，以便通过公共和专用网络移动的数据包是安全的。
正在使用 的数据是内存中正在积极处理的数据。
保护正在使用的数据的一个示例是使用机密计算进行加密，以在处理数据时保护数据。
上述选项不是相互排斥的。 它们通常在整个解决方案的上下文中一起使用。 一个阶段可能充当补偿控制。 例如，在从内存中读取数据时，可能需要隔离数据以防止篡改。
加密范围
按其用途和敏感度级别 对数据进行分类，以确定需要加密的数据。 对于应加密的数据，请确定所需的保护级别。 是否需要传输中的所有数据的端到端 TLS 加密？ 对于静态数据，哪些 Azure 功能可以满足你的要求？ 是否需要在每个存储点对数据进行双重加密？ 如何实现信息保护？
平衡加密决策非常重要，因为存在重大权衡。
权衡：每个加密跃点都可能导致性能延迟。 与故障排除和可观测性相关的操作复杂性可能会发生。 恢复可能是一项挑战。
确定这些利弊的范围。 预测分类为敏感数据的数据的权衡。 要求甚至可能确定权衡，例如，某个类型的数据必须加密并存储在特定阈值内。
在某些情况下，由于技术限制、投资或其他原因，无法进行加密。 确保这些原因清晰、有效且已记录。
强加密机制不应是唯一的防御形式。 实施数据盗窃防护过程、适当的测试方法和异常情况检测。
有关分类的信息，请参阅数据分类推荐。
本机加密机制
大多数 Azure 服务提供基本级别的加密。 探索平台提供的加密选项。
强烈建议不要禁用平台功能来开发自己的功能。 平台加密功能使用现代行业标准，由专家开发，经过高度测试。
在极少数情况下，如果需要替换平台提供的加密，请评估优缺点，并使用行业标准加密算法。
开发人员应使用操作系统中内置的加密 API，而不是非平台加密库。 对于 .NET，请遵循 .NET 加密模型。
加密密钥
默认情况下，Azure 服务使用 Microsoft 管理的加密密钥来加密和解密数据。 Azure 负责密钥管理。
可以选择 客户管理的密钥。 Azure 仍使用密钥，但要负责密钥操作。 如果需要，可以灵活地更改密钥 。 解密是使用客户管理的密钥的令人信服的理由。
应 将强加密与强解密配对。 从安全角度来看，保护解密密钥非常重要，因为轮换是控制爆炸半径（如果密钥遭到入侵）的常见方法。 监视访问以检测异常访问和活动。
存储独立于加密数据的密钥。 这种分离有助于确保一个实体的泄露不会影响另一个实体。 如果使用客户管理的密钥，请将它们存储在密钥存储中。 在托管硬件安全模块（HSM）中存储高度敏感的数据。
这两个存储都受基于标识的访问保护。 此功能允许你拒绝访问，甚至允许访问平台。
标准加密算法
使用已建立良好且遵循行业标准 的加密算法，而不是创建自定义实现。
算法的行业标准要求加密方案具有某种级别的熵。 加密期间会注入熵源。 Entropy 使算法变得强大，并使攻击者难以提取信息。 确定可容忍的 entropy 阈值。 加密过程是处理器密集型的。 找到适当的平衡，以便最大化在加密上花费的计算周期，相对于计算请求的总体性能目标。
哈希和检查和
通常，哈希是错误检测技术。 还可以使用哈希进行安全性处理，因为它 会检测因篡改而导致的数据更改。 哈希函数基于加密，但它们不使用密钥。 哈希函数使用算法生成检查和。 校验和可以比较数据，以验证数据的完整性。
应用程序应使用 SHA-2 系列哈希算法，例如 SHA-256、SHA-384 或 SHA-512。
静态数据
根据内部和外部符合性要求对信息存储对象进行分类和保护。 请参阅以下建议：
使用为存储服务、数据存储和其他用于保存数据的资源的本机选项 加密数据。 即使仅暂时将这些存储服务或资源中的数据存储在这些存储服务或资源中，也会加密此数据。 此外，请加密备份数据，以保持与原始源相同的安全级别。
有关详细信息，请参阅 静态数据保护。
使用双重加密。 如果业务需求要求要求提高保证，则可以执行双重加密。 使用独立的客户管理的密钥加密两个或更多层中的数据。 将数据存储在托管 HSM 中。 若要读取数据，需要访问这两个密钥。 如果一个密钥遭到入侵，另一个密钥仍会保护数据。 此方法旨在增加攻击者的成本。
还可以使用平台提供的加密来双重加密数据。 平台提供的加密可在基础结构级别保护存储媒体，并在数据级别应用另一层加密。 例如，消息代理服务通过 Microsoft 管理的密钥提供平台加密，以保护消息管道。 此方法允许使用客户管理的密钥加密消息。
使用多个加密密钥。 使用密钥加密密钥（KEK）来保护数据加密密钥（DEK）。
使用基于标识的访问控制来控制对数据的访问。 添加网络防火墙以提供额外的安全层，阻止意外和不安全的访问。
有关详细信息，请参阅标识和访问管理建议。
将密钥存储在具有最低特权访问控制的托管 HSM 中。 将数据与数据键分隔开来。
存储有限的数据 量，以便仅加密必要的数据。 数据生存期不应超过加密周期。 不再需要数据时，无需花费解密周期即可删除加密数据。
传输中的数据
使用安全协议进行客户端-服务器通信。 传输协议具有内置的安全层。 TLS 是用于在客户端终结点和服务器终结点之间交换数据的行业标准。
不要使用低于 TLS 1.2 的版本。 迁移解决方案以支持 TLS 1.2，并默认使用此版本。 所有 Azure 服务在公共 HTTPS 终结点上都支持 TLS 1.2。
风险：如果不支持向后兼容性，不支持 TLS 1.2 的旧客户端可能无法正常工作。无论传输的数据的敏感度如何，所有网站通信都应使用 HTTPS。 在客户端-服务器握手期间，协商使用 HTTP 严格传输安全 （HSTS） 策略，以便维护 HTTPS 传输，并且不会在通信期间丢弃到 HTTP。 此策略可防范中间人攻击。
对 HSTS 的支持适用于较新版本。 可能会中断与旧浏览器的向后兼容性。
注意
还可以加密协议，为数据库建立安全连接。 例如，Azure SQL 数据库支持表格数据流（TDS）协议，该协议集成了 TLS 握手。
密码套件是一组算法，用于标准化客户端和服务器之间的握手。 密码可确保对交换进行加密和身份验证。 密码的选择取决于服务器使用的 TLS 版本。 对于某些服务（例如Azure 应用程序网关），可以选择要支持的 TLS 版本和密码套件。 实现使用高级加密标准（AES）作为对称块密码的密码套件。 AES-128、AES-192 和 AES-256 是可接受的。
管理证书的生命周期。 证书具有预先确定的生命周期。 不要保留长期证书，不要让他们自行过期。 实现以可接受的频率续订证书的过程。 可以自动执行短间隔发生的续订过程。
注意
如果使用 证书固定，请熟悉敏捷性和证书管理限制。
工作流不应允许在环境中接受无效证书。 证书固定过程应验证证书并强制检查验证。 应监视访问日志，以确保签名密钥与适当的权限一起使用。
如果密钥被盗，则必须立即吊销证书。 证书颁发机构（CA）提供证书吊销列表（CRL），该列表指示过期前失效的证书。 验证检查应考虑到 CRL。
权衡：认证验证过程可能比较繁琐，通常涉及 CA。 确定必须使用证书加密的数据。 对于其他类型的通信，请确定是否可以实现本地化补偿控件来添加安全性。本地化控件的一种方法是使用相互 TLS （mTLS）。 它在客户端和服务器之间的两个方向建立信任。 客户端和服务器都有其自己的证书，并且每个证书都使用其公钥或私钥对进行身份验证。 使用 mTLS 时，你不依赖于外部 CA。 权衡是管理两个证书的复杂性增加。
如果需要，请双重加密 VPN 连接。 执行双重加密，以将防御深度添加到 VPN 隧道。 使用两个 VPN 服务器时，可以在服务器之间隐藏 IP 地址，并隐藏服务器和目标之间的 IP 地址。 在此过程中，传输中的数据也会加密两次。
权衡：与单个 VPN 设置相比，双 VPN 设置通常更昂贵，连接通常较慢。实现日志记录和监视过程。 跟踪存储有关客户端的信息（例如其源 IP、端口和协议）的访问登录资源。 使用此信息检测异常。
正在使用中的数据
对于高安全性工作负荷，建议采用分段、隔离和最低特权设计模式。
在正在使用保护的上下文中，硬件边界可能需要加密数据，同时它在物理 CPU 和内存中使用，以确保 VM、主机管理代码和其他组件的隔离。 加密和解密数据只能在这些隔离边界内完成。
更严格的安全或法规要求可能还需要基于硬件的加密签名证据，证明数据在使用时正在加密，这可以通过证明获得。 机密计算 是支持要求的此类技术之一。 Azure 中的特定服务提供在计算数据时保护数据的功能。 有关详细信息，请参阅 Azure 便利化：Azure 机密计算。
请考虑保护数据的 端到端生命周期，数据在其生存期内经常在多个系统中移动，请注意确保解决方案的所有组件部分可以提供所需的保护级别，或确保数据管理策略提供适当的分段或掩码。
Azure 便利化
以下部分介绍可用于加密数据的 Azure 服务和功能。
客户管理的密钥
将客户管理的密钥存储在 Azure 密钥库或密钥库托管的 HSM 中。
密钥库将密钥视为任何其他机密。 Azure 基于角色的访问控制（RBAC）通过权限模型访问密钥。 此基于标识的控制必须与密钥库访问策略一起使用。
有关详细信息，请参阅使用 RBAC 提供对密钥库密钥、证书和机密的访问权限。
Azure 密钥库 高级版和 Managed-HSM 通过包括机密计算功能和支持策略的安全密钥发布来进一步增强产品/服务，以确保密钥仅发布到可以加密证明它在受信任的执行环境（T企业版）内执行的工作负荷。
静态数据保护
Azure 存储将数据保存到存储帐户时，使用块密码自动加密数据。 对于Azure Blob 存储和 Azure 队列存储，存储还通过库提供客户端加密。
有关详细信息，请参阅存储加密。
Azure 虚拟机具有充当虚拟存储卷的磁盘文件。 可以加密虚拟磁盘文件，以便无法访问内容。
可以从门户导出托管磁盘。 主机的服务器端加密和加密只能在导出数据后保护数据。 但是，应在导出过程中保护数据。 可以在导出过程中使用Azure 磁盘加密来保护数据。
Azure 为托管磁盘提供了多个加密选项。 有关详细信息，请参阅托管磁盘加密选项概述。
SQL 数据库提供透明数据加密功能，用于在页面级别加密数据库文件。
传输中的数据保护
使用 密钥库，可以预配、管理和部署公共和专用安全套接字层（SSL）或 TLS 证书。 可以将证书用于 Azure 和内部连接资源。
使用中的数据保护
Azure 中的特定服务提供使用 Azure 机密计算在主机的物理 CPU 和内存中计算数据的功能。
机密虚拟机提供在 T企业版 内运行的整个虚拟机，虚拟机的内存和执行 CPU 内容经过加密，提供简单的“直接迁移”方法，用于将具有高安全性要求的未修改的应用程序移动到 Azure。 每个 Azure 机密 VM 都有自己的专用虚拟信任平台模块 （TPM）。 在操作系统组件安全启动时执行加密。
机密 AKS 工作节点、AKS 上的机密容器或 Azure 容器实例 （ACI） 上的机密容器提供在 T企业版 内运行和管理未修改的容器的功能，使客户能够受益于使用中的保护。 容器产品/服务基于机密虚拟机并受益于相同的保护。
应用程序 Enclave 解决方案是专门构建的应用程序，利用支持 Intel Software Guard Extensions （SGX）的虚拟机 SKU 提供的特定 CPU 扩展，这些扩展提供非常精细 的受信任计算基础（TCB）， 但需要专门编码应用程序才能利用这些功能。
安全密钥发布可以与这些技术相结合，以确保加密的数据仅在 T企业版 内解密，这证明它通过称为证明的过程提供所需的保护级别。
机密管理
可以使用密钥库安全地存储和控制对令牌、密码、证书、API 密钥和其他机密的访问。 使用密钥库作为密钥和证书管理解决方案。 高级版 SKU 支持 HSM。
示例
以下示例显示了可用于管理密钥、证书和机密的加密解决方案。
相关链接
- .NET 加密模型
- Azure 磁盘加密
- 静态数据的存储加密
- Azure 服务中的证书固定
- 使用 RBAC 提供对密钥库密钥、证书和机密的访问权限
- 托管磁盘加密选项概述
- 透明数据加密
- 信任平台模块概述
- Azure 机密计算
社区链接
安全清单
请参阅完整的建议集。
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈