有关安全隔离的 Azure 指南

Microsoft Azure 是一个超大规模公共多租户云服务平台，可让你访问功能丰富的环境，其中包含最新的云创新，例如人工智能、机器学习、IoT 服务、大数据分析、智能边缘等，帮助你提高效率并解锁对运营和性能的见解。

多租户云平台意味着多个客户应用程序和数据存储在同一物理硬件上。 Azure 使用逻辑隔离将应用程序和数据与其他客户隔离开来。 这种方法提供了多租户云服务的规模和经济优势，同时严格帮助防止其他客户访问您的数据或应用程序。

Azure 通过提供值得信赖的基础来确保使用一组通用原则确保多租户、加密确定、逻辑隔离的云服务，从而解决了资源共享的感知风险：

1. 具有身份验证和身份分离的用户访问控制
2. 用于处理的计算隔离
3. 网络隔离，包括传输中的数据加密
4. 静态数据加密的存储隔离
5. 服务设计中嵌入的安全保障流程，以正确开发逻辑隔离的服务

公有云中的多租户通过以低成本在不同客户之间共享资源来提高效率；然而，这种方法引入了与资源共享相关的潜在风险。 Azure 通过使用图 1 中所述的多层方法为隔离云服务提供可信基础来解决此风险。

图 1。 Azure 隔离方法

下面提供了隔离方法的简要摘要。

• 身份验证和标识分离的用户访问控制 – 无论类型或存储位置如何，Azure 中的所有数据都与订阅相关联。 在注册 Microsoft 云服务时，可以将云租户视为组织接收和拥有的 Microsoft Entra ID 的专用实例。 标识和访问堆栈有助于在订阅之间强制隔离，包括限制对订阅中资源的访问仅对授权用户的访问权限。

• 计算隔离 – Azure 提供用于处理的逻辑计算和物理计算隔离。 逻辑隔离的实现途径有：

  • 虚拟机监控程序隔离：通过使用单独的虚拟机和 Azure 虚拟机监控程序隔离来为服务提供密码学确定的隔离。
  • 使用 Drawbridge 提供的隔离为在同一虚拟机上运行的工作负荷提供加密特定隔离的服务中的 Drawbridge 隔离。 这些服务使用客户的代码提供小型处理单元。
  • 不允许对仅由 Microsoft 控制的代码和客户代码组成的服务进行用户上下文隔离。
    

  除了设计为所有 Azure 租户提供的可靠逻辑计算隔离之外，如果需要物理计算隔离，还可以使用专用于单个客户的服务器硬件上部署的 Azure 专用主机或隔离虚拟机。

• 网络隔离 – Azure 虚拟网络（VNet）有助于确保专用网络流量在逻辑上与属于其他客户的流量隔离。 服务可以使用公共 IP 或专用 （VNet） IP 进行通信。 VM 之间的通信在 VNet 中保持私密。 可以根据连接选项（包括带宽、延迟和加密要求）通过 VNet 对等互连 或 VPN 网关连接 VNet。 可以使用 网络安全组（NSG） 在访问具有公共终结点的 Azure 服务时实现网络隔离和保护 Azure 资源免受 Internet 保护。 可以使用虚拟网络 服务标记 定义 网络安全组 或 Azure 防火墙上的网络访问控制。 服务标记表示给定 Azure 服务中的一组 IP 地址前缀。 Microsoft管理服务标记包含的地址前缀，并在地址发生更改时自动更新服务标记，从而减少对网络安全规则的频繁更新的复杂性。 此外，可以使用 专用链接 通过 VNet 中的专用终结点访问 Azure PaaS 服务，确保 VNet 和服务之间的流量通过Microsoft全局主干网络传输，从而无需向公共 Internet 公开该服务。 最后，Azure 为加密传输中的数据提供了多个选项，包括采用终端到终端传输层安全性 (TLS) 加密的网络流量，通过 Key Vault 证书的 TLS 终止，使用 IPsec 的 VPN 加密，以及客户管理密钥 (CMK) 支持的 MACsec 启用的 Azure ExpressRoute 加密。

• 存储隔离 – 为了确保逻辑数据隔离的加密确定性，Azure 存储依赖于使用具有多个密码的高级算法进行静态数据加密。 此过程依赖于多个加密密钥和服务（例如 Azure Key Vault 和 Microsoft Entra ID），以确保安全密钥访问和集中密钥管理。 Azure 存储服务加密可确保在将数据保存到 Azure 存储之前自动加密，并在检索之前解密数据。 写入 Azure 存储的所有数据 都通过经过 FIPS 140 验证的 256 位 AES 加密进行加密 ，可以将 Key Vault 用于客户管理的密钥（CMK）。 Azure 存储服务加密会加密存储 Azure 虚拟机磁盘的页面 Blob。 此外，还可以选择使用 Azure 磁盘加密来加密 Azure Windows 和 Linux IaaS 虚拟机磁盘，以提高存储隔离，并确保 Azure 中存储数据的加密确定性。 此加密包括托管磁盘。

• 安全保证流程和做法 – Microsoft内部使用 安全开发生命周期（SDL） 和其他强大的安全保证流程进一步强制实施 Azure 隔离保证，以保护攻击面并缓解威胁。 Microsoft建立了行业领先的流程和工具，为 Azure 隔离保证提供高度信心。

根据云计算中的 共同责任 模型，将工作负载从本地数据中心迁移到云时，你与云服务提供商之间的责任划分因云服务模型而异。 例如，在基础设施即服务（IaaS）模型中，Microsoft 的责任在 Hypervisor（虚拟机监控程序）层结束，而您负责超出虚拟化层的所有层级，包括维护客户机 VM 中的基础操作系统。 可以使用 Azure 隔离技术实现云中部署的应用程序和数据所需的隔离级别。

在本文中，提示框列出了作为您责任一部分的重要事项或行动。 例如，可以使用 Azure Key Vault 来存储机密，包括保留在控制之下的加密密钥。

本文提供技术指南，以解决与云采用相关的常见安全性和隔离问题。 它还探讨了 Azure 中可用的设计原则和技术，以帮助实现安全隔离目标。

基于身份的隔离

Microsoft Entra ID 是一个标识存储库和云服务，它为用户、组和对象提供身份验证、授权和访问控制。 Microsoft Entra ID 可用作独立云目录，也可以用作具有现有本地 Active Directory 的集成解决方案，以启用关键企业功能，例如目录同步和单一登录。

每个 Azure 订阅 都与 Microsoft Entra 租户相关联。 可以使用 Azure 基于角色的访问控制（Azure RBAC）、来自该目录的用户、组和应用程序来访问 Azure 订阅中的资源。 例如，存储帐户可以放置在资源组中，以使用 Microsoft Entra ID 控制对该特定存储帐户的访问。 Azure 存储定义一组 Azure 内置角色，其中包含用于访问 Blob 或队列数据的常见权限。 可以使用 Microsoft Entra 帐户或存储帐户密钥对 Azure 存储的请求进行授权。 通过这种方式，只能向特定用户提供访问 Azure 存储中的数据的能力。

零信任体系结构

无论类型或存储位置如何，Azure 中的所有数据都与订阅相关联。 在注册 Microsoft 云服务时，可以将云租户视为组织接收和拥有的 Microsoft Entra ID 的专用实例。 使用在 Microsoft Entra ID 中创建的标识或与本地 Active Directory 联合创建的标识，通过 Microsoft Entra ID 执行对 Azure 门户的身份验证。 标识和访问堆栈有助于在订阅之间强制隔离，包括限制对订阅中资源的访问仅对授权用户的访问权限。 此访问限制是 零信任模型的首要目标，该模型假定网络遭到入侵，并且需要从外围安全模型进行根本转变。 评估访问请求时，所有请求的用户、设备和应用程序都应被视为不受信任，直到其完整性符合零信任 设计原则进行验证。 Microsoft Entra ID 提供零信任框架中所需的强、自适应、基于标准的标识验证。

Microsoft Entra ID

用于管理云应用程序的帐户分离对于实现逻辑隔离至关重要。 Azure 中的帐户隔离是使用 Microsoft Entra ID 及其支持精细 Azure 基于角色的访问控制 （Azure RBAC）的功能实现的。 每个 Azure 帐户都与一个Microsoft Entra 租户相关联。 目录中的用户、组和应用程序可以管理 Azure 中的资源。 可以使用 Azure 门户、Azure 命令行工具和 Azure 管理 API 分配适当的访问权限。 每个Microsoft Entra 租户都是不同的，与其他 Azure AD 不同。 Microsoft Entra 实例在逻辑上是隔离的，它使用安全边界来防止客户数据和标识信息传入，从而确保一个Microsoft Entra ID 的用户和管理员无法访问或泄露另一个Microsoft Entra 实例中的数据，无论是恶意的还是意外的。 Microsoft Entra ID 物理隔离地运行在专用服务器上，在逻辑上隔离到专用网段，并通过主机级数据包过滤和 Windows 防火墙服务，为不受信任的流量提供额外的保护。

Microsoft Entra ID 实现广泛的 数据保护功能，包括租户隔离和访问控制、传输中的数据加密、机密加密和管理、磁盘级别加密、各种Microsoft Entra 组件使用的高级加密算法、内部访问的数据作注意事项等。 有关详细信息，请参阅白皮书 Microsoft Entra 数据安全注意事项。

Microsoft Entra ID 中的租户隔离涉及两个主要元素：

• 防止跨租户的数据泄露和访问，这意味着属于租户 A 的数据不能以任何方式由租户 B 中的用户获取，而无需租户 A 的显式授权。
• 跨租户的资源访问隔离，这意味着租户 A 执行的操作绝不会以任何方式影响对租户 B 资源的访问。

如图 2 所示，通过 Microsoft Entra ID 进行访问需要通过安全令牌服务（STS）进行用户身份验证。 授权系统使用目录服务 API 和 Azure RBAC 提供的信息，关于用户的存在性和启用状态，以确定会话中用户请求访问目标 Microsoft Entra 实例的权限是否被授权。 除了直接绑定到用户的基于令牌的身份验证之外，Microsoft Entra ID 通过以下方法进一步支持 Azure 中的逻辑隔离：

• Microsoft Entra 实例是离散容器，它们之间没有关系。
• Microsoft Entra 数据存储在分区中，每个分区都有一组预先确定的副本，这些副本被视为首选主副本。 使用副本可提供 Microsoft Entra 服务的高可用性，以支持标识分离和逻辑隔离。
• 除非 Microsoft Entra 实例管理员通过联合身份验证或从其他 Microsoft Entra 实例预配用户帐户授予访问权限，否则不允许跨 Microsoft Entra 实例进行访问。
• 对构成 Microsoft Entra 服务的服务器的物理访问以及直接访问 Microsoft Entra ID 的后端系统仅限于使用实时 (JIT) 特权访问管理系统正确授权 Microsoft 操作角色。
• Microsoft Entra 用户无权访问物理资产或位置，因此他们不可能绕过逻辑 Azure RBAC 策略检查。

图 2。 Microsoft Entra 逻辑租户隔离

总之，Azure 的逻辑租户隔离方法使用通过 Microsoft Entra ID 管理的标识，作为第一个逻辑控制边界，用于通过 Azure RBAC 提供对资源和授权的租户级访问。

数据加密密钥管理

Azure 广泛支持使用数据加密来保护数据，包括各种加密模型：

• 使用服务管理的密钥、Azure 中的客户管理的密钥或客户控制的硬件上的客户管理的密钥的服务器端加密。
• 客户端加密，使你能够在本地或另一个安全位置管理和存储密钥。

数据加密提供与加密（加密）密钥访问直接关联的隔离保证。 由于 Azure 对数据加密使用强密码，因此只有有权访问加密密钥的实体才能访问数据。 删除或撤销加密密钥会使相应的数据无法访问。 有关 传输中的数据加密 的详细信息，请参阅 “网络隔离 ”部分，而静态 数据加密 在 “存储隔离 ”部分介绍。

Azure 允许对静态数据和传输中的数据强制 实施双重加密 。 使用此模型，启用两个或更多层加密，以防止任何加密层的泄露。

Azure Key Vault

对加密密钥的适当保护和管理对于数据安全至关重要。 Azure Key Vault 是一项云服务，用于安全地存储和管理机密。 Key Vault 服务支持本部分其余部分所述的两种资源类型：

• 保管库 支持受软件保护和硬件安全模块（HSM）保护的机密、密钥和证书。
• 托管 HSM 仅支持受 HSM 保护的加密密钥。

如果需要对存储在 Azure 服务中的最敏感的客户数据提供额外的安全性，则可以使用在 Key Vault 中控制的自己的加密密钥对其进行加密。

Key Vault 服务提供对底层硬件安全模块（HSM）的抽象。 它提供 REST API，通过 Microsoft Entra ID 启用云应用程序和身份验证的服务使用，使你能够集中和自定义身份验证、灾难恢复、高可用性和弹性。 Key Vault 支持各种类型的 加密密钥 、大小和曲线，包括 RSA 和椭圆曲线密钥。 使用托管 HSM 时，还支持使用 AES 对称密钥。

使用 Key Vault，可以在 HSM 中导入或生成加密密钥，确保密钥永远不会离开 HSM 保护边界以支持 自带密钥（BYOK） 方案，如图 3 所示。

图 3。 Azure Key Vault 支持自带密钥（BYOK）

Key Vault HSM 内部生成的密钥不可导出 - HSM 外部没有密钥的明文版本。 此绑定由基础 HSM 强制实施。 密钥保管库和托管 HSM 均提供 BYOK 功能。 联机文档中所述，将受 HSM 保护的密钥传输到 Key Vault 的方法因基础 HSM 而异。

Key Vault 为加密密钥生命周期管理提供了可靠的解决方案。 创建后，每个密钥保管库或托管 HSM 都会自动与拥有订阅的 Microsoft Entra 租户相关联。 尝试从密钥保管库或托管 HSM 中管理或检索内容的任何人员都必须经过正确身份验证和授权：

• 身份验证将建立调用方（用户或应用程序）的标识。
• 授权根据 Azure 基于角色的访问控制 (Azure RBAC) 和密钥保管库访问策略或托管 HSM 本地 RBAC 的组合来确定调用方可以执行的操作。

Microsoft Entra ID 强制实施租户隔离，并实施可靠的措施，防止未经授权的参与方进行访问，如Microsoft Entra ID 部分所述。 通过两个接口或平面（管理平面和数据平面）控制对密钥保管库或托管 HSM 的访问，这两个平面使用 Microsoft Entra ID 进行身份验证。

• 使用管理平面 可以管理密钥保管库或托管 HSM 本身，例如创建和删除密钥保管库或托管 HSM、检索密钥保管库或托管 HSM 属性以及更新访问策略。 在授权方面，管理平面将 Azure RBAC 与密钥保管库和托管 HSM 结合使用。
• 使用数据平面 可以处理密钥保管库和托管 HSM 中存储的数据，包括添加、删除和修改数据。 对于保管库，存储的数据可以包括密钥、秘密和证书。 对于托管 HSM，存储的数据仅限于加密密钥。 对于授权，数据平面使用 Key Vault 访问策略和 Azure RBAC 来管理与密钥保管库相关的数据平面操作，或使用托管 HSM 的本地 RBAC 进行托管 HSM 的管理。

在 Azure 订阅中创建密钥保管库或托管 HSM 时，它会自动与订阅的 Microsoft Entra 租户相关联。 这两个平面中的所有调用方都必须在此租户中注册，并进行身份验证才能访问密钥保管库或托管 HSM。

你可以控制访问权限，并且可以从 Azure Key Vault 服务中提取详细的活动日志。 Azure Key Vault 记录以下信息：

• 所有经过身份验证的 REST API 请求，包括失败的请求
  • 对密钥保管库的操作，例如创建、删除、设置访问策略等。
  • 对密钥保管库中的密钥和秘文进行操作，包括 a）创建、修改或删除密钥或秘文，以及 b）对密钥进行签名、验证、加密等。
• 未经身份验证的请求（如没有持有者令牌的请求、格式不正确或已过期）或令牌无效。

还可以使用 Azure Monitor 中的 Azure Key Vault 解决方案 来查看 Key Vault 日志。 若要使用此解决方案，需要启用 Key Vault 诊断日志记录并将诊断定向到 Log Analytics 工作区。 使用此解决方案，无需将日志写入 Azure Blob 存储。

保管库

保管库 提供一个多租户、低成本、易于部署、区域复原（如果可用）和高度可用的密钥管理解决方案，适用于最常见的云应用程序方案。 保管库可以存储和保护 机密、密钥和证书。 它们可以受软件保护（标准层）或受 HSM 保护（高级层）。 有关标准层和高级层之间的比较，请参阅 Azure Key Vault 定价页。 Azure 使用行业标准算法和密钥长度来保护受软件保护的机密、密钥和证书。 如果需要额外的保证，您可以选择将机密、密钥和证书存放在由多租户 HSM 保护的保管库中。 相应的 HSM 根据 FIPS 140 标准进行验证，并具有总体安全级别 2 分级，其中包括物理篡改证据和基于角色的身份验证的要求。

保管库支持 客户管理的密钥 （CMK），可在其中控制 HSM 中的自己的密钥，并使用这些密钥对 许多 Azure 服务静态数据进行加密。 如前所述，可以在 HSM 中 导入或生成加密密钥 ，确保密钥永远不会离开 HSM 边界以支持 自带密钥（BYOK） 方案。

Key Vault 可以处理保管库中请求和续订证书（包括传输层安全性（TLS）证书，使你能够注册和自动续订受支持的公共证书颁发机构颁发的证书。 Key Vault 证书支持提供 X.509 证书的管理，这些证书基于密钥构建，并提供自动续订功能。 证书所有者可以通过 Azure Key Vault 或导入现有证书 来创建证书 。 支持自签名证书和证书颁发机构生成的证书。 此外，Key Vault 证书所有者无需与私钥交互即可实现 X.509 证书的安全存储和管理。

在资源组中创建密钥保管库时，可以使用 Microsoft Entra ID 来管理访问权限 ，这样就可以通过分配相应的 Azure 角色来授予特定范围级别的访问权限。 例如，若要授予对用户管理密钥保管库的访问权限，可以将预定义的密钥保管库参与者角色分配给特定范围内的用户，包括订阅、资源组或特定资源。

托管的 HSM

托管 HSM 提供单租户、完全托管、高度可用、具有区域弹性（如果可用）HSM 作为服务来存储和管理加密密钥。 它非常适用于处理重要密钥的应用程序和使用方案。 它还有助于满足最严格的安全、合规性和法规要求。 托管 HSM 使用 经过验证的 3 级 FIPS 140 HSM 来保护加密密钥。 每个托管 HSM 池都是独立的单租户实例，由你控制自己的 安全域 ，并从属于其他客户的实例中隔离加密。 加密隔离依赖于 Intel Software Guard Extensions （SGX） 技术，提供加密代码和数据，以帮助确保对加密密钥的控制。

创建托管 HSM 时，请求者还提供数据平面管理员列表。 仅这些管理员能够访问托管 HSM 数据平面来执行关键操作并管理数据平面角色分配（托管 HSM 本地 RBAC）。 管理和数据平面的权限模型使用相同的语法，但在不同级别强制执行权限，角色分配使用不同的范围。 管理平面 Azure RBAC 由 Azure 资源管理器强制执行，而数据平面托管 HSM 本地 RBAC 由托管 HSM 本身强制执行。

如前所述，托管 HSM 支持导入在本地 HSM 中 生成的密钥 ，确保密钥永远不会离开 HSM 保护边界，也称为 自带密钥（BYOK） 方案。 托管 HSM 支持与 Azure 存储、 Azure SQL 数据库、 Azure 信息保护等 Azure 服务集成。 有关使用托管 HSM 的 Azure 服务的完整列表，请参阅 数据加密模型。

通过托管 HSM，可以使用已建立的 Azure Key Vault API 和管理接口。 无论密钥管理解决方案如何：多租户保管库或单租户托管 HSM，都可以对所有应用程序使用相同的应用程序开发和部署模式。

计算隔离

Microsoft Azure 计算平台基于 计算机虚拟化。 此方法意味着代码（无论是部署在 PaaS 辅助角色中还是 IaaS 虚拟机）在由 Windows Server Hyper-V 虚拟机监控程序托管的虚拟机中执行。 在每个 Azure 物理服务器上（也称为节点）上，有一个 类型 1 虚拟机监控程序 直接在硬件上运行，并将节点划分为可变数量的来宾虚拟机（VM），如图 4 所示。 每个节点都有一个特殊的主机 VM，也称为根 VM，该 VM 运行主机 OS – 最新 Windows Server 的自定义和强化版本，该版本被剥离以减少攻击面，并仅包括管理节点所需的组件。 从来宾 VM 隔离根 VM 和来宾 VM 彼此隔离是 Azure 安全体系结构中构成 Azure 计算隔离基础的关键概念，如 Microsoft 联机文档中所述。

图 4。 虚拟机监控程序、根 VM 和来宾 VM 的隔离

托管 VM 的物理服务器分组到群集中，它们由名为 Fabric 控制器 （FC）的横向扩展和冗余平台软件组件独立管理。 每个 FC 管理在其群集中运行的 VM 的生命周期，包括预配和监视其控制下硬件的运行状况。 例如，FC 负责在确定服务器失败时在正常运行的服务器上重新创建 VM 实例。 它还将基础结构资源分配给租户工作负荷，并管理从主机到虚拟机的单向通信。 将计算基础结构划分为群集，在 FC 级别隔离故障，并防止某些类错误影响群集以外的服务器。

FC 是 Azure 计算平台的大脑，主机代理是其代理，将服务器集成到平台中，以便 FC 可以部署、监视和管理你和 Azure 云服务使用的虚拟机。 虚拟机监控程序/主机操作系统的配对利用 Microsoft 在操作系统安全性方面数十年的经验，包括对 Microsoft Hyper-V 的安全性投资，以提供来宾虚拟机的强隔离。 本节稍后将讨论虚拟机监控程序隔离，包括虚拟机监控程序强制实施的强定义的安全边界、深层防御攻击缓解和强大的安全保证流程。

管理网络隔离

每个计算硬件群集中有三个虚拟局域网（VLAN），如图 5 所示：

• 主 VLAN 互连不受信任的客户节点，
• 结构控制器 (FC) VLAN，其中包含受信任的 FC 和支持系统，以及
• 包含受信任网络和其他基础设施设备的 VLAN 设备。

允许从 FC VLAN 到主 VLAN 的通信，但无法从主 VLAN 向 FC VLAN 发起通信。 从 FC VLAN 到主 VLAN 的网桥用于降低整体复杂性并提高网络的可靠性/复原能力。 可通过多种方式保护连接，以确保命令受信任且已成功路由：

• 从 FC 到 Fabric 代理（FA）的通信是单向的，需要通过证书进行相互身份验证。 FA 实现一个受 TLS 保护的服务，该服务仅响应 FC 发出的请求。 它无法启动与 FC 或其他特权内部节点的连接。
• FC 将代理服务的响应视为不受信任。 与代理的通信进一步受限于使用防火墙规则和边界网关路由规则控制的授权 IP 地址集合，这些规则应用于每个物理节点。
• 限制用于确保客户 VM 无法使网络和管理命令饱和，无法路由。

还会阻止从主 VLAN 到设备 VLAN 的通信。 这样，即使运行客户代码的节点遭到入侵，它也无法攻击 FC 或设备 VLAN 上的节点。

这些控制可确保管理控制台对虚拟机监控程序的访问始终有效且可用。

图 5. VLAN 隔离

虚拟机监控程序和主机 OS 提供网络数据包筛选器，这有助于确保不受信任的 VM 无法生成欺骗流量或接收未发送到它们的流量、将流量定向到受保护的基础结构终结点，或发送/接收不适当的广播流量。 默认情况下，创建 VM 时会阻止流量，然后 FC 代理将数据包筛选器配置为添加规则和例外以允许授权流量。 有关网络流量隔离和租户流量分离的更多详细信息，请参阅 “网络隔离 ”部分。

管理控制台和管理平面

Azure 管理控制台和管理平面遵循最低特权的严格安全架构原则来保护和隔离租户处理过程。

• 管理控制台 （MC） - Azure 云中的 MC 由 Azure 门户 GUI 和 Azure 资源管理器 API 层组成。 他们都使用用户凭据对所有作进行身份验证和授权。
• 管理平面 （MP） - 此层执行实际管理作，由计算资源提供程序（CRP）、构造控制器（FC）、构造代理（FA）和基础虚拟机监控程序组成，后者具有其自己的虚拟机监控程序代理来服务通信。 这些层都使用被授予最低权限以执行操作的系统上下文。

Azure FC 将基础结构资源分配给租户，并管理从主机 OS 到来宾 VM 的单向通信。 Azure FC 的 VM 放置算法非常复杂，几乎无法预测。 FA 驻留在主机 OS 中，它管理租户 VM。 Azure 虚拟机监控程序、主机 OS 和 FA 以及客户 VM 的集合构成了计算节点，如图 4 所示。 尽管 FC 存在于计算节点之外，但它们仍负责管理 FA - 分别有独立的 FC 来管理计算和存储群集。 如果在 MC 中运行时更新应用程序的配置文件，MC 会通过 CRP 与 FC 通信，FC 与 FA 通信。

CRP 是适用于 Azure 计算的前端服务，通过 Azure 资源管理器公开一致的计算 API，使你能够通过简单的模板创建和管理虚拟机资源和扩展。

各种组件之间的通信（例如，Azure 资源管理器与 CRP 之间、CRP 与 FC 之间、虚拟机监控程序代理到 FC 和从 FC 到虚拟机监控程序代理之间的通信）都在各自不同的通信通道上进行，这些通道具有不同的身份和不同的权限集。 此设计遵循常见的最小特权模型，以确保任何单层的妥协都能防止进一步操作。 单独的通信通道可确保通信不能绕过链中的任何层。 图 6 展示了用户使用 Microsoft Entra ID 进行 OAuth 2.0 身份验证而发起虚拟机监控程序后，MC 和 MP 如何在 Azure 云中与其进行安全通信。

图 6。 安全管理流的管理控制台和管理平面交互

所有管理命令都通过 RSA 签名证书或 JSON Web 令牌（JWT）进行身份验证。 身份验证和命令通道通过传输层安全性 （TLS） 1.2 进行加密，如 传输节中的数据加密 中所述。 服务器证书用于提供与使用单独授权机制的身份验证提供程序的 TLS 连接，例如，Microsoft Entra ID 或数据中心安全令牌服务（dSTS）。 dSTS 是一个令牌提供程序，类似于 Microsoft Entra ID，它独立于 Microsoft 数据中心，用于服务级别通信。

图 6 说明了与用于停止虚拟机的用户命令对应的管理流。 表 1 中枚举的步骤同样适用于其他管理命令，并使用相同的加密和身份验证流。

表 1. 涉及各种 MC 和 MP 组件的管理流程

通过本节中标识并发送到每个节点上 FC 和 FA 的过程的所有步骤生成的命令将写入本地审核日志，并分发到多个分析系统进行流处理，以便监视系统运行状况并跟踪安全事件和模式。 跟踪包括已成功处理的事件和无效的事件。 入侵检测系统处理无效的请求以检测异常。

逻辑隔离实现选项

Azure 通过多层方法提供计算处理的隔离，包括：

• 虚拟机监控程序隔离：通过使用单独的虚拟机和 Azure 虚拟机监控程序隔离来为服务提供密码学确定的隔离。 示例： 应用服务、Azure 容器实例、Azure Databricks、Azure Functions、Azure Kubernetes 服务、Azure 机器学习、云服务、数据工厂、Service Fabric、虚拟机、虚拟机规模集。
• 使用 Drawbridge 提供的隔离为同一虚拟机上运行的工作负荷提供加密特定隔离的服务中的 Drawbridge 隔离。 这些服务使用客户的代码提供小型处理单元。 为了提供安全隔离，Drawbridge 会在 pico 进程内运行用户进程以及 Windows 内核（库 OS）的轻量版本。 pico-process 是一个安全进程，不直接访问主机系统的服务或资源。 示例： 自动化、Azure Database for MySQL、Azure Database for PostgreSQL、Azure SQL 数据库、Azure 流分析。
• 不允许对仅由 Microsoft 控制的代码和客户代码组成的服务进行用户上下文隔离。 示例： API 管理、应用程序网关、Microsoft Entra ID、Azure 备份、Azure Redis 缓存、Azure DNS、Azure 信息保护、Azure IoT 中心、Azure Key Vault、Azure 门户、Azure Monitor（包括 Log Analytics），Microsoft Defender for Cloud、Azure Site Recovery、容器注册表、内容分发网络、事件网格、事件中心、负载均衡器、服务总线、存储、虚拟网络、VPN 网关 流量管理器。

本部分的其余部分将讨论这些逻辑隔离选项。

虚拟机监控程序隔离

Azure 中的虚拟机监控程序隔离基于 Microsoft Hyper-V 技术，它使基于 Azure 虚拟机监控程序的隔离能够受益于 Microsoft 数十年来在操作系统安全性和对 Hyper-V 技术进行虚拟机隔离投资方面的经验。 你可以查看有关 Hyper-V 安全功能的独立第三方评估报告，包括 国家信息保障伙伴关系（NIAP）共同标准评估和验证方案（CCEVS）报告， 如 本文中讨论的2021年2月发布的报告 。

评估目标（TOE）由 Microsoft Windows Server、Microsoft Windows 10 版本 1909（2019 年 11 月更新）和 Microsoft Windows Server 2019（版本 1809）Hyper-V（“Windows”）组成。 TOE 强制实施以下安全策略，如报告中所述：

• 安全审核 – Windows 能够收集审核数据、查看审核日志、防止审核日志溢出，以及限制对审核日志的访问。 系统生成的审核信息包括事件的日期和时间、导致生成事件的用户标识以及其他事件特定的数据。 经授权的管理员可以查看、搜索和排序审核记录。 授权管理员还可以配置审核系统，以包含或排除根据许多特征审核的潜在可审核事件。 在此评估的上下文中，保护配置文件要求包括生成审核事件、对存储的审核记录进行授权评审，以及为审核事件条目提供安全存储。
• 加密支持 – Windows 提供经过验证的加密函数，支持加密/解密、加密签名、加密哈希和随机数生成。 Windows 实现这些函数以支持 IPsec、TLS 和 HTTPS 协议实现。 Windows 还确保其来宾 VM 有权访问熵数据，从而虚拟化操作系统能够实现强大的加密功能。
• 用户数据保护 – Windows 使某些计算服务可供来宾 VM 使用，但实施措施，以确保适当地授予对这些服务的访问权限，并且这些接口不会导致来宾 VM 和 Windows 之间或多个来宾 VM 之间未经授权的数据泄露。
• 标识和身份验证 – Windows 提供了多种用户身份验证方法，其中包括受信任的协议所需的 X.509 证书。 Windows 实现密码强度机制，并确保使用受暴力破解猜测（密码，PIN）的方法进行过多失败的身份验证尝试会导致锁定行为。
• 安全管理 – Windows 包含多个用于管理安全策略的功能。 管理功能的访问权限是通过管理角色来实施的。 Windows 还能够支持管理网络与运营网络的分离，并禁止来宾 VM 之间的数据共享。
• 保护 TOE 安全功能 （TSF） - Windows 实现了各种自我保护机制，以确保它不能用作平台来未经授权访问存储在来宾 VM 上的数据，维护 TSF 及其来宾 VM 的完整性，并且来宾 VM 只能通过记录良好的接口进行访问。
• TOE Access – 在此评估上下文中，Windows 允许授权管理员将系统配置为在登录对话框之前显示登录横幅。
• 受信任的路径/通道 – Windows 实现 IPsec、TLS 和 HTTPS 受信任的通道和路径，用于远程管理、将审核数据传输到作环境以及管理和作网络的分离。

可从 第三方认证报告获取详细信息。

关键虚拟机监控程序隔离通过：

• 由虚拟机监控程序强制执行的严密安全边界
• 深层防御漏洞缓解措施
• 强大的安全保证流程

本部分的其余部分介绍了这些技术。 它们使 Azure 虚拟机监控程序能够在多租户云中为租户分离提供强大的安全保证。

强定义的安全边界

代码在虚拟机监控程序 VM 中执行，并受益于虚拟机监控程序强制实施的安全边界，如图 7 所示。 Azure 虚拟机监控程序基于 Microsoft Hyper-V 技术。 它将 Azure 节点划分为可变数量的来宾虚拟机（VM），这些 VM 具有独立的地址空间，可以加载操作系统（OS）和应用程序，并与在节点根分区中执行的 Host OS 并行运行。

图 7。 使用 Azure 虚拟机监控程序进行计算隔离（请参阅联机 术语表）

Azure 虚拟机监控程序的行为类似于微内核，使用虚拟化服务客户端（VSC）将来宾虚拟机的所有硬件访问请求传递给主机操作系统，通过名为 VMBus 的共享内存接口进行处理。 主机 OS 使用虚拟化服务提供程序（VSP）代理硬件请求，防止用户获取对系统的原始读/写/执行访问权限，并降低共享系统资源的风险。 特权根分区（也称为主机 OS）可以直接访问系统上的物理设备/外围设备，例如存储控制器、GPU、网络适配器等。 主机 OS 允许来宾分区通过向每个来宾分区公开虚拟设备来共享这些物理设备的使用。 因此，在来宾分区中执行的作系统可以访问在根分区中执行的 VSP 提供的虚拟化外围设备。 这些虚拟设备表示形式可以采用以下三种形式之一：

• 模拟设备 – 主机 OS 可能会公开一个虚拟设备，其接口与相应物理设备提供的接口相同。 在这种情况下，客户机分区中的操作系统将使用与在物理系统上运行时相同的设备驱动程序。 主机 OS 将模拟物理设备到来宾分区的行为。
• 参数虚拟化设备 – 主机 OS 可以使用主机 OS 与来宾之间的 VMBus 共享内存接口公开具有特定于虚拟化的接口的虚拟设备。 在此模型中，来宾分区使用专用于实现虚拟化接口的设备驱动程序。 这些准虚拟化设备有时称为“合成”设备。
• 硬件加速设备 – 主机 OS 可能会直接向来宾分区公开实际的硬件外围设备。 此模型允许来宾分区中的高 I/O 性能，因为来宾分区可以直接访问硬件设备资源，而无需通过主机 OS。 Azure 加速网络 是硬件加速设备的示例。 此模型中的隔离是使用输入输出内存管理单元（I/O MMU）实现的，以便为每个分区提供地址空间和中断隔离。

主机 CPU 中的虚拟化扩展使 Azure 虚拟机监控程序能够在分区之间强制隔离。 以下基本 CPU 功能提供虚拟机监控程序隔离的硬件构建基块：

• 二级地址转换 – 管理程序使用 CPU 内存管理单元（MMU）提供的二级页表来控制允许分区访问的内存资源。 CPU 的 MMU 在虚拟机监控程序控制下使用二级地址转换对以下操作执行的内存访问强制执行保护：
  • 在分区上下文中运行的 CPU。
  • 来宾分区直接访问的 I/O 设备。
• CPU 上下文 – 虚拟机监控程序使用 CPU 中的虚拟化扩展来限制在来宾分区运行时可以访问的特权和 CPU 上下文。 虚拟机监控程序还使用这些设施在多个分区之间共享 CPU 时保存和还原状态，以确保隔离分区之间的 CPU 状态。

Azure 虚拟机监控程序利用这些处理器设施来提供分区之间的隔离。 投机端通道攻击的出现已经确定了其中一些处理器隔离功能的潜在弱点。 在多租户体系结构中，跨不同租户的任何跨 VM 攻击都涉及两个步骤：将攻击者控制的 VM 放置在与某个受害者 VM 相同的主机上，然后违反逻辑隔离边界来执行侧通道攻击。 Azure 使用先进的 VM 放置算法强制执行内存和进程隔离来实现逻辑隔离，并使用虚拟机监控程序中的加密确定性保护网络流量路由，从而抵御这两种威胁向量。 如本文后面的标题为 利用虚拟化技术中的漏洞 部分所述，Azure 虚拟机监控程序已构建为直接在虚拟机监控程序内部提供可靠的隔离，以帮助缓解许多复杂的侧通道攻击。

Azure 虚拟机监控程序定义的安全边界提供了基本级别的隔离基元，用于在共享硬件上潜在的恶意多租户之间对代码、数据和资源进行强分段。 这些隔离基元用于创建多租户资源隔离方案，包括：

• 潜在恶意来宾之间的网络流量隔离 - 虚拟网络（VNet）作为其基本设计的一部分，虚拟网络（VNet）提供租户之间的 网络流量 隔离，如租户网络流量分离部分后面所述。 VNet 形成隔离边界，其中 VNet 中的 VM 只能相互通信。 从 VNet 或外部发送方中发往 VM 且未配置正确策略的任何流量都将由主机删除，而不会传递到 VM。
• 加密密钥和加密材料的隔离 – 可以使用 硬件安全管理器或专用密钥存储进一步增强隔离功能，例如，通过 Azure Key Vault 将加密密钥存储在 FIPS 140 验证的硬件安全模块（HSM）中。
• 系统资源计划 – Azure 设计包括保证计算、内存、存储以及直接和准虚拟化设备访问的可用性和分段。

Azure 虚拟机监控程序满足表 2 中显示的安全目标。

表 2. Azure 虚拟机监控程序安全目标

深层防御攻击缓解措施

为了进一步降低安全泄露的风险，Microsoft在 Azure 系统软件、硬件和固件中投入了大量防御深度缓解措施，为 Azure 客户提供强大的真实隔离保证。 如前所述，Azure 虚拟机监控程序隔离基于 Microsoft Hyper-V 技术，使 Azure 虚拟机监控程序能够受益于 Microsoft 数十年来在操作系统安全性和虚拟机隔离方面的投资经验。

下面列出了Microsoft用于保护 Hyper-V 的一些关键设计原则：

• 防止设计级别问题影响产品
  • 进入 Hyper-V 的每个更改都需进行设计评审。
• 消除具有更安全编码的常见漏洞类
  • 某些组件（如 VMSwitch）使用经过正式验证的协议分析程序。
  • 许多组件使用 gsl::span 而不是原始指针，从而消除了缓冲区溢出和/或超出边界内存访问的可能性。 有关详细信息，请参阅 指南支持库（GSL） 文档。
  • 许多组件使用智能指针来消除释放后使用 bug 的风险。
  • 大多数 Hyper-V 内核模式代码使用一个堆分配器，该分配器在分配时为零，以消除未初始化的内存 bug。
• 通过编译器缓解消除常见漏洞类
  • 所有 Hyper-V 代码都是使用 InitAll 编译的，这将 消除未初始化的堆栈变量。 此方法已实现，因为 Hyper-V 中的许多历史漏洞是由未初始化的堆栈变量引起的。
  • 所有 Hyper-V 代码都使用 堆栈 canaries 进行编译，以大幅降低堆栈溢出漏洞的风险。
• 查找产品中出现的问题
  • 所有 Windows 代码都要经过一组静态分析规则的检查。
  • 所有 Hyper-V 代码都经过代码审查和模糊处理。 有关模糊处理的详细信息，请参阅本文后面的 安全保证流程和做法 部分。
• 使利用剩余漏洞变得更加困难
  • VM 工作进程应用了以下缓解措施：
    • 任意代码防护 – 动态生成的代码无法在 VM 辅助角色进程中加载。
    • 代码完整性防护 – 只能在 VM 辅助进程中加载Microsoft签名代码。
    • 控制流防护 (CFG) - 为间接呼叫和跳跃提供课程粒度的控制流保护。
    • NoChildProcess – 工作进程无法创建子进程（适用于绕过 CFG）。
    • NoLowImages / NoRemoteImages – 工作进程无法加载通过网络传输的 DLL 或由沙盒进程写入磁盘的 DLL。
    • NoWin32k – 工作进程无法与 Win32k 通信，这使得沙盒逃逸更加困难。
    • 堆随机化 – Windows 附带了任何操作系统最安全的堆实现之一。
    • 地址空间布局随机化 （ASLR） - 随机化地址空间中的堆、堆栈、二进制文件和其他数据结构的布局，以降低利用的可靠性。
    • 数据执行防护 （DEP/NX） - 仅包含代码的内存页是可执行的。
  • 内核应用了以下缓解措施：
    • 堆随机化 – Windows 附带了任何操作系统最安全的堆实现之一。
    • 地址空间布局随机化 （ASLR） - 随机化地址空间中的堆、堆栈、二进制文件和其他数据结构的布局，以降低利用的可靠性。
    • 数据执行防护 （DEP/NX） - 仅包含代码的内存页是可执行的。

Microsoft 对 Hyper-V 安全的投资直接惠及 Azure 虚拟机管理程序。 深层防御缓解措施的目标是使攻击者对漏洞进行武器化利用的代价尽可能高，限制其影响，并最大限度地延长检测窗口。 所有攻击缓解措施都通过对攻击者可能采用的方法对 Azure 虚拟机监控程序攻击面进行彻底的安全审查来评估有效性。 表 3 概述了一些旨在保护虚拟机监控程序隔离边界和硬件主机完整性的缓解措施。

表 3. Azure 虚拟机监控程序深层防御

此外，Azure 还采用了通过 Red Teaming 实现的假设泄露安全策略。 此方法依赖于一个专门的安全研究人员和工程师团队，他们使用与实际攻击者相同的策略、技术和程序对实时生产基础结构进行持续测试，而无需了解 Azure 基础结构和平台工程或运营团队。 此方法测试安全检测和响应功能，并帮助识别 Azure 虚拟机监控程序和其他系统中的生产漏洞，包括配置错误、无效假设或其他安全问题（以受控方式）。 Microsoft对这些创新安全措施进行大量投资，以便持续缓解 Azure 威胁。

强大的安全保证流程

在 Hyper-V 中，攻击面已经被很好地了解。 它已经是 正在进行的研究 和彻底的安全审查的主题。 Microsoft 一直对 Hyper-V 攻击面和其基础的安全体系结构保持透明，正如其在 2018 年 Black Hat 大会 上的公开演讲中所演示的那样。 Microsoft 对 Hyper-V 隔离的稳健性和质量充满信心，因此针对在 Hyper-V 中报告的关键远程代码执行（RCE）、信息泄露和拒绝服务（DOS）漏洞，推出了 250,000 美元的 bug 赏金计划。 通过在 Windows Server 和 Azure 云平台中使用相同的 Hyper-V 技术，公开的文档和 Bug 赏金计划确保所有 Microsoft 产品和服务的用户都能获得安全性的改进。 表 4 总结了 Black Hat 演示文稿的关键攻击面点。

表 4. Hyper-V 攻击面详细信息

为了保护这些攻击面，Microsoft建立了行业领先的流程和工具，为 Azure 隔离保证提供高可信度。 如本文后面部分中 的“安全保障流程和做法” 所述，该方法包括专门构建的模糊测试、渗透测试、安全开发生命周期、强制性安全培训、安全评审、基于来宾-主机威胁指标的安全入侵检测，以及攻击面变化的自动构建警报。 此成熟的多维保障过程通过缓解安全漏洞的风险，帮助增强 Azure 虚拟机监控程序提供的隔离保证。

升降桥隔离

对于使用客户代码提供小型处理单元的服务，来自多个租户的请求在单个 VM 中执行，并使用 Microsoft Drawbridge 技术进行隔离。 为了提供安全隔离，Drawbridge 会在 pico 进程内同时运行用户进程和 Windows 内核（Library OS）的轻型版本。 pico 进程是一个轻型安全隔离容器，其内核 API 图面最少，并且无法直接访问主机系统的服务或资源。 pico 进程可以进行的唯一外部调用是通过 Drawbridge 应用程序二进制接口（ABI）对 Drawbridge 安全监视器，如图 8 所示。

图 8。 使用 Drawbridge 进行进程隔离

安全监视器分为系统设备驱动程序和用户模式组件。 ABI 是库 OS 和主机之间的接口。 整个接口由小于 50 个无状态函数调用的封闭集合组成。

• 从 pico 进程到主机 OS 的向下调用支持线程、虚拟内存和 I/O 流等抽象。
• 上层调用到 pico 进程执行初始化、返回异常信息，并在新线程中运行。

接口的语义是固定的，并支持应用程序在任何操作系统中所需的一般抽象。 此设计使库 OS 和主机能够单独发展。

ABI 在两个组件中实现：

• 平台适应层（PAL）作为 pico 进程一部分运行。
• 主机实现作为主机的一部分运行。

Pico 进程分组为称为 沙盒的隔离单元。 沙盒定义可用于 pico 进程的应用程序、文件系统和外部资源。 当在 pico 进程内运行的进程创建新的子进程时，它将在同一沙盒内的单独 pico 进程中使用自己的库 OS 运行。 每个沙盒都能与安全监视器通信，并且无法与其他沙盒进行通信，除非通过已显式允许的 I/O 通道（如套接字、命名管道等）。根据服务需求，配置默认采用选择加入的方式来允许这些通道。 结果是，在 pico 进程内运行的代码只能访问其自己的资源，并且不能直接攻击主机系统或任何共置沙盒。 它只能影响其自己的沙盒中的对象。

当 pico 进程需要系统资源时，它必须调用 Drawbridge 主机以请求它们。 虚拟用户进程的正常路径是调用库 OS 来请求资源，然后库 OS 将调用 ABI。 除非在驱动程序本身中设置了资源分配策略，否则安全监视器会通过检查策略来处理 ABI 请求，以查看请求是否允许，然后为请求提供服务。 此机制用于所有系统基元，因此确保 pico 进程中运行的代码不能滥用主机计算机中的资源。

除了在沙盒中被隔离之外，pico 进程之间也基本上是相互隔离的。 每个 pico 进程驻留在其自己的虚拟内存地址空间中，并使用自己的用户模式内核运行自己的库 OS 副本。 每次在 Drawbridge 沙盒中启动用户进程时，都会启动一个新的库 OS 实例。 尽管与在 Windows 上启动非隔离进程相比，此任务更耗时，但它比在完成逻辑隔离的同时启动 VM 要快得多。

正常的 Windows 进程可以调用超过 1200 个函数，从而能够访问 Windows 内核；然而，Pico 进程的完整接口中到宿主的调用次数不超过 50 次。 大多数应用程序对操作系统服务的请求由库操作系统在 pico 进程的地址空间内进行处理。 通过向内核提供明显较小的接口，Drawbridge 创建了一个更安全且独立的操作环境。在这一环境中，应用程序对主机系统的更改以及新操作系统版本引入的不兼容性更具抵抗力。 更重要的是，Drawbridge pico 进程是一个强隔离的容器，在该容器中，即使是最恶意源的不受信任的代码也可以运行，而不会危及主机系统。 主机假定在 pico-进程 中运行的任何代码都不可信。 主机使用安全检查验证来自 pico 进程的所有请求。

与虚拟机一样，pico 过程比传统的 OS 接口更安全，因为它明显更小、无状态且具有固定且易于描述的语义。 小型 ABI/driver syscall 接口的另一个附加优势是能够审核/模糊驱动程序代码，但工作量很少。 例如，syscall 模糊测试工具可以在相对较短的时间内以高覆盖率进行 ABI 的模糊测试。

基于用户上下文的隔离

如果 Azure 服务由Microsoft控制的代码组成，并且不允许客户代码运行，则用户上下文会提供隔离。 这些服务仅接受用户配置输入和数据进行处理 - 不允许任意代码。 对于这些服务，会提供用户上下文来建立可以访问的数据以及允许执行哪些 Azure 基于角色的访问控制（Azure RBAC）操作。 此上下文由 Microsoft Entra ID 建立，如前面 在“基于标识的隔离 ”部分中所述。 标识和授权用户后，Azure 服务会创建一个应用程序用户上下文，该上下文在请求执行过程中附加到请求上，从而确保用户操作被分离并正确隔离。

物理隔离

除了设计为所有 Azure 租户提供的可靠逻辑计算隔离外，如果需要物理计算隔离，还可以使用专用于单个客户的 Azure 专用主机或独立虚拟机。

Azure 专用主机

Azure 专用主机提供物理服务器，这些服务器可以托管一个或多个 Azure VM，并专用于一个 Azure 订阅。 你可以在区域、可用性区域和容错域中预配专用主机。 然后，可以将 Windows、 Linux 和 SQL Server 直接放入预配的主机上，使用最能满足你的需求的任何配置。 专用主机在物理服务器级别提供硬件隔离，使你能够将 Azure VM 放置在仅运行组织的工作负载的隔离专用物理服务器上，以满足公司合规性要求。

可以通过选择服务器和 CPU 类型、核心数和额外功能，将 Windows 和 Linux 虚拟机同时部署到专用主机。 专用主机允许您选择加入特定维护窗口，以减少对已配置服务的潜在影响，从而控制平台维护事件。 大多数维护事件对 VM 没有什么影响;但是，如果你处于高度管控的行业或具有敏感工作负荷，则可能需要控制任何潜在的维护影响。

Microsoft使用 Azure 门户、Azure PowerShell 和 Azure CLI 提供有关 Windows 和 Linux Azure 虚拟机预配的详细客户指南。 表 5 总结了 Azure 中预配的虚拟机的可用安全指南。

表 5. Azure 虚拟机的安全指南

独立虚拟机

Azure 计算提供与特定硬件类型隔离并专用于单个客户的虚拟机大小。 这些 VM 实例允许在专用物理服务器上部署工作负荷。 使用独立 VM 实质上可确保 VM 是唯一在该特定服务器节点上运行的 VM。 还可以选择使用 Azure 对嵌套虚拟机的支持进一步细分这些独立 VM 上的资源。

网络隔离

公共多租户云中租户基础结构的逻辑隔离 是维护安全性的基础。 虚拟化解决方案的首要原则是仅允许该虚拟化解决方案运行所需的连接和通信，默认阻止所有其他端口和连接。 Azure 虚拟网络 （VNet）有助于确保专用网络流量在逻辑上与属于其他客户的流量隔离。 一个 VNet 中的虚拟机（VM）无法直接与不同 VNet 中的 VM 通信，即使这两个 VNet 都是由同一客户创建的。 网络隔离 可确保 VM 之间的通信在 VNet 中保持私密。 可以根据连接选项（包括带宽、延迟和加密要求）通过 VNet 对等互连 或 VPN 网关连接 VNet。

本部分介绍 Azure 如何隔离租户之间的网络流量，并强制实施加密确定性隔离。

租户网络流量分离

虚拟网络（VNet）在基本设计过程中提供租户之间的网络流量隔离。 Azure 订阅可以包含多个逻辑隔离的专用网络，并包括防火墙、负载均衡和网络地址转换。 默认情况下，每个 VNet 与其他 VNet 隔离。 订阅中的多个部署可以放置在同一 VNet 上，然后通过专用 IP 地址相互通信。

对 VM 的网络访问受网络边缘、负载均衡器和主机 OS 级别的数据包筛选的限制。 此外，可以将主机防火墙配置为进一步限制连接，并为每个侦听端口指定是接受来自 Internet 的连接还是仅接受来自同一云服务或 VNet 中的角色实例的连接。

Azure 为每个部署提供网络隔离，并强制实施以下规则：

• VM 之间的流量始终通过可靠的数据包筛选器。
  • 使用速率限制和反欺骗保护来控制来自 VM 的协议（例如地址解析协议（ARP）、动态主机配置协议（DHCP）和其他 OSI 层 2 流量。
  • VM 无法捕获网络上不属于它们的任何流量。
• VM 无法将流量发送到 Azure 专用接口和基础结构服务，也无法将流量发送到属于其他客户的 VM。 VM 只能与你拥有或控制的其他 VM 以及用于公共通信的 Azure 基础结构服务终结点通信。
• 将 VM 置于 VNet 上时，该 VM 将获取其自己的地址空间，该空间不可见，因此无法从部署或 VNet 外部的 VM 访问（除非配置为通过公共 IP 地址可见）。 你的环境仅通过你为公共访问指定的端口打开;如果 VM 定义为具有公共 IP 地址，则所有端口都开放供公共访问。

数据包流和网络路径保护

Azure 的超大规模网络旨在提供：

• 服务器之间的统一高容量。
• 服务（包括客户）之间的性能隔离。
• 以太网第 2 层语义。

Azure 使用多个网络实现来实现以下目标：

• 平面寻址，允许将服务实例放置在网络中的任何位置。
• 负载均衡，以在网络路径之间统一分散流量。
• 终端系统的地址解析可以扩展到大型服务器池，而不会增加网络控制平面的复杂性。

这些实现使每个服务都认为，分配给它的所有服务器（仅限这些服务器）是通过一个不干扰的以太网交换机（虚拟第 2 层（VL2））连接在一起的，并且，即使每个服务的规模从一台服务器到数十万台服务器不等，这种错觉仍然得以保持。 此 VL2 实现可实现流量性能隔离，确保一个服务的流量不可能受到任何其他服务的流量的影响，就像每个服务都由单独的物理交换机连接一样。

本部分介绍数据包如何流经 Azure 网络，以及拓扑、路由设计和目录系统如何组合以虚拟化基础网络结构，从而创建服务器连接到大型非推断数据中心范围的第 2 层交换机的错觉。

Azure 网络使用 两个不同的 IP 地址系列：

• 客户地址（CA） 是客户定义的/选择的 VNet IP 地址，也称为虚拟 IP（VIP）。 网络基础结构使用可外部路由的 CA 运行。 所有交换机和接口都分配了 CA，交换机运行基于 IP 的（第 3 层）链接状态路由协议，该协议仅传播这些 CA。 此设计允许交换机获取并了解完整的交换机级拓扑，并沿着最短路径转发封装有 CA 的数据包。
• 提供程序地址（PA） 是 Azure 分配的内部构造地址，对用户不可见，也称为动态 IP（DIP）。 没有流量直接从 Internet 流向服务器;来自 Internet 的所有流量都必须通过软件负载均衡器（SLB）进行封装，以便仅将数据包路由到有效的 Azure 内部 IP 地址和端口来保护内部 Azure 地址空间。 网络地址转换 （NAT） 将内部网络流量与外部流量分开。 内部流量使用 RFC 1918 地址空间或专用地址空间（提供程序地址 (PA)（不能外部路由））。 转换在 SLB 上执行。 外部可路由的客户地址（CA）将转换为仅可在 Azure 中路由的内部提供商地址（PA）。 无论服务器的位置因虚拟机迁移或重新预配而更改，这些地址都保持不变。

每个 PA 都与 CA 相关联，CA 是服务器连接到的机架顶部（ToR）交换机的标识符。 VL2 使用可缩放的可靠目录系统来存储和维护 PA 到 CA 的映射，并在将服务器预配到服务和分配的 PA 地址时创建此映射。 在每个服务器（称为 VL2 代理）的网络堆栈中运行的代理调用目录系统的解析服务，以了解目标的实际位置，然后将原始数据包隧道传送到该处。

Azure 分配单独充当名称的服务器 IP 地址，且没有拓扑意义。 Azure 的 VL2 寻址方案将这些服务器名称（PA）与其位置（CA）分开。 提供第 2 层语义的症结在于，服务器认为它们与同一服务中的其他服务器共享单个大型 IP 子网（即整个 PA 空间），同时消除困扰大型以太网部署的地址解析协议（ARP）和动态主机配置协议（DHCP）缩放瓶颈。

图 9 描绘了一个示例数据包流，其中发送方 S 使用 IP-in-IP 封装通过随机选择的中间交换机将数据包发送到目标 D。 PA 来自 20/8，CA 来自 10/8。 H（ft） 表示 5 元组的哈希，该哈希由源 IP、源端口、目标 IP、目标端口和协议类型组成。 ToR 将 PA 转换为 CA，发送到中间交换机，该交换机发送到目标 CA ToR 交换机，后者转换为目标 PA。

图 9。 示例数据包流

如果目录服务拒绝提供用于路由数据包的 CA，服务器就无法将数据包发送到 PA，这意味着目录服务在强制执行访问控制策略。 此外，由于目录系统知道处理查找时哪个服务器正在发出请求，因此它可以 强制实施精细隔离策略。 例如，它可以强制实施一个策略，只有属于同一服务的服务器才能相互通信。

流量流模式

在知道 CA 地址路由的基础网络上，为在服务器之间使用 PA 地址进行流量路由， 每台服务器上的 VL2 代理会捕获来自宿主机的数据包，并用目标 ToR 交换机的 CA 地址对它们进行封装。 数据包到达 CA（即目标 ToR 交换机）后，目标 ToR 交换机将解封数据包，并将其传送到内部标头中携带的目标 PA。 数据包首先传递到中间交换机之一，由交换机解封，传递到 ToR 的 CA，再次解封，最后发送到目标。 图 10 使用两种可能的流量模式来描述此方法：1）通过 Azure ExpressRoute 或 Internet 遍历到 VNet 的外部流量（橙色线），以及两个 VNet 之间的 2）内部流量（蓝线）。 这两个流量流遵循类似的模式来隔离和保护网络流量。

图 10。 使用 VNet 分离租户网络流量

外部流量 （橙色行） - 对于外部流量，Azure 提供多层保证，以便根据流量模式强制隔离。 在 VNet 网关上放置公共 IP 时，来自公共 Internet 或发往该 IP 地址的本地网络的流量将路由到 Internet 边缘路由器。 或者，通过 ExpressRoute 连接建立专用对等互连时，它通过 VNet 网关连接到 Azure VNet。 此设置使物理线路的连接保持一致，并使本地位置的专用 IP 地址空间可寻址。 然后，Azure 使用边界网关协议（BGP）与本地网络共享路由详细信息，以建立端到端连接。 当通信从 VNet 中的资源开始时，网络流量会像平常一样遍历，直到到达 Microsoft ExpressRoute Edge （MSEE） 路由器。 在这两种情况下，VNet 都为 Azure VM 充当本地网络的一部分提供了手段。 Azure 与内部网络（例如，通过 Azure VPN 网关或 Azure ExpressRoute 专用对等互连）建立了加密保护的 IPsec/IKE 隧道，使 VM 能够安全地连接到本地资源，就像它直接在该网络上一样。

在 Internet Edge 路由器或 MSEE 路由器上，数据包使用通用路由封装（GRE）封装。 此封装使用特定于 VNet 目标的唯一标识符和目标地址，该地址用于适当地将流量路由到标识的 VNet。 到达 VNet 网关（一种特殊的 VNet，仅用于接受来自 Azure VNet 外部的流量）时，封装由 Azure 网络构造验证，以确保：a） 接收数据包的终结点与用于路由数据的唯一 VNet ID 匹配，并且 b） 请求的目标地址存在于此 VNet 中。 验证后，数据包将作为内部流量从 VNet 网关路由到 VNet 中最终请求的目标地址。 此方法可确保来自外部网络的流量仅传输到其目标 Azure VNet，从而实现隔离。

内部流量（蓝线） - 内部流量还使用 GRE 封装/隧道。 当 Azure VNet 中的两个资源尝试建立彼此之间的通信时，Azure 网络结构会伸出 Azure VNet 路由目录服务，该服务是 Azure 网络构造的一部分。 目录服务使用客户地址（CA）和请求的目标地址来确定提供商地址（PA）。 此信息（包括 VNet 标识符、CA 和 PA）随后用于使用 GRE 封装流量。 Azure 网络使用此信息通过 PA 将封装的数据正确路由到相应的 Azure 主机。 封装由 Azure 网络结构审核，以确认：

1. PA 是匹配项，
2. CA 位于此 PA，并且
3. VNet 标识符是匹配项。

一旦这三者都经过验证，封装将被删除，并作为正常流量路由到 CA，例如，将流量路由到 VM 终结点。 此方法基于云服务之间的正确流量路由提供 VNet 隔离保证。

Azure VNet 实现多种机制，以确保租户之间的流量安全。 这些机制符合现有的行业标准和安全做法，并防止已知的攻击途径，包括：

• 防止 IP 地址欺骗——每当 VNet 传输封装的流量时，服务会重新验证有关传输接收端的信息。 流量在传输开始时进行独立查找和封装，并在接收端点重新验证，以确保传输正确进行。 此验证是通过名为 SpoofGuard 的内部 VNet 功能完成的，该功能验证源和目标是否有效且允许通信，从而防止预期封装模式中的不匹配，否则可能允许欺骗。 GRE 封装过程阻止欺骗，因为 Azure 网络构造未完成的任何 GRE 封装和加密都被视为丢弃的流量。
• 在具有重叠网络空间的客户之间提供网络分段 - Azure VNet 的实现依赖于已建立的隧道标准（例如 GRE），进而允许在整个云中使用特定于客户的唯一标识符（VNet ID）。 VNet 标识符用作范围标识符。 此方法可确保始终在自己唯一的地址空间内操作，在租户与 Azure 网络结构之间重叠地址空间。 未使用有效 VNet ID 封装的任何内容都被阻止在 Azure 网络构造中。 在前面所述的示例中，将丢弃 Azure 网络构造未执行的任何封装流量。
• 防止流量在 VNet 之间互通 – 防止 VNet 之间流量互通，是通过处理地址重叠和防止欺骗的相同机制来实现的。 通过为每个租户建立唯一的 VNet ID 以及源和目标上所有流量的验证，使 VNet 之间交叉的流量交互无法实现。 用户无法访问依赖于这些 ID 来执行封装的基础传输机制。 因此，任何封装和模拟这些机制的尝试都会导致流量下降。

除了这些密钥保护之外，默认情况下会删除源自 Internet 的所有意外流量。 进入 Azure 网络的任何数据包将首先遇到边缘路由器。 边缘路由器有意允许所有入站流量进入 Azure 网络，但欺骗流量除外。 此基本流量筛选可保护 Azure 网络免受已知恶意流量的侵害。 Azure 还在网络层实现 DDoS 防护，收集日志以基于实时和历史数据分析限制或阻止流量，并按需缓解攻击。

此外，Azure 网络结构会阻止来自 Azure 网络结构空间的任意被欺骗的 IP 的流量。 Azure 网络构造使用 GRE 和虚拟可扩展 LAN（VXLAN）来验证所有允许的流量是否为 Azure 控制的流量，并阻止所有非 Azure GRE 流量。 通过使用 GRE 隧道和 VXLAN 通过客户唯一密钥对流量进行分段，Azure 满足 RFC 3809 和 RFC 4110 的要求。 将 Azure VPN 网关与 ExpressRoute 结合使用时，Azure 满足 RFC 4111 和 RFC 4364。 借助包含外部和内部网络流量的综合隔离方法，Azure VNet 可确保 Azure 成功路由 VNet 之间的流量，为具有重叠地址空间的租户提供适当的网络分段，并防止 IP 地址欺骗。

还可以使用 Azure 服务进一步隔离和保护资源。 使用 Azure 虚拟网络的 网络安全组（NSG）功能，可以通过多个入站和出站安全规则按源和目标 IP 地址、端口和协议来筛选流量，这基本上充当分布式虚拟防火墙和基于 IP 的网络访问控制列表（ACL）。 可以将 NSG 应用到虚拟机中的每个 NIC，将 NSG 应用到 NIC 或其他 Azure 资源连接到的子网，并直接应用到虚拟机规模集，从而更好地控制基础结构。

在基础设施层，Azure 部署虚拟机管理程序防火墙，以保护运行在虚拟机管理程序之上的虚拟机内的所有租户免受未经授权的访问。 此虚拟机监控程序防火墙作为部署到主机、在虚拟机监控程序中实现并由 Fabric 控制器代理配置的 NSG 规则的一部分分发，如图 4 所示。 主机 OS 实例使用内置的 Windows 防火墙以比路由器 ACL 更精细的方式实现精细 ACL - 它们由预配租户的相同软件维护，因此永远不会过期。 细粒度的 ACL 使用计算机配置文件（MCF）应用到 Windows 防火墙。

操作系统堆栈的顶部是客操作系统，您使用它作为您的操作系统。 默认情况下，此层不允许与云服务或虚拟网络进行任何入站通信，实质上是使其成为专用网络的一部分。 对于 PaaS Web 角色和工作角色，默认情况下不允许远程访问。 可以启用远程桌面协议（RDP）访问作为显式选项。 对于使用 Azure 门户创建的 IaaS VM，默认情况下会打开 RDP 和远程 PowerShell 端口;但是，端口号是随机分配的。 对于通过 PowerShell 创建的 IaaS VM，必须显式打开 RDP 和远程 PowerShell 端口。 如果管理员选择将 RDP 和远程 PowerShell 端口保持打开到 Internet，则允许创建 RDP 和 PowerShell 连接的帐户应使用强密码进行保护。 即使端口已打开，也可以根据需要在公共 IP 上定义 ACL 进行额外保护。

服务标记

可以使用虚拟网络 服务标记 来实现网络隔离，并在访问具有公共终结点的 Azure 服务时从 Internet 保护 Azure 资源。 使用服务标记，可定义网络安全组或 Azure 防火墙上的网络访问控制。 服务标记表示给定 Azure 服务中的一组 IP 地址前缀。 Microsoft管理服务标记包含的地址前缀，并在地址发生更改时自动更新服务标记，从而减少对网络安全规则的频繁更新的复杂性。

Azure 专用链接

可以使用 专用链接 通过 VNet 中的 专用终结点 访问 Azure PaaS 服务和 Azure 托管的客户/合作伙伴服务，确保 VNet 和服务之间的流量通过Microsoft全局主干网络传输。 此方法无需向公共 Internet 公开服务。 还可以在自己的 VNet 中创建自己的 专用链接服务 ，并将其交付给客户。

Azure 专用终结点是一个网络接口，可将你专用且安全地连接到由专用链接提供支持的服务。 专用终结点使用 VNet 中的专用 IP 地址将服务有效接入 VNet 中。

从网络隔离的角度来看，专用链接的主要优势包括：

• 可以在源或目标处将 VNet 连接到 Azure 中的服务，而无需公共 IP 地址。 专用链接通过Microsoft全局主干网络处理服务与其使用者之间的连接。
• 可以使用专用终结点通过 Azure ExpressRoute 专用对等互连、VPN 隧道和对等互连虚拟网络从本地访问 Azure 中运行的服务。 专用链接无需设置 Microsoft 对等互连或通过 Internet 才能访问服务。
• 可以以私密方式连接到在其他 Azure 区域中运行的服务。

传输中数据加密

Azure 提供了许多用于加密传输中的数据的选项。 传输中的数据加密可将网络流量与其他流量隔离开来，并帮助防止数据拦截。 传输中的数据适用于涉及数据在以下之间传输的方案：

• 最终用户和 Azure 服务
• 本地数据中心和 Azure 区域
• Microsoft 数据中心和 Microsoft 数据中心（预期的 Azure 服务运营的一部分）

最终用户与 Azure 服务的连接

传输层安全性 （TLS） - Azure 使用 TLS 协议来帮助保护最终用户和 Azure 服务之间的数据。 大多数终端用户将通过 Internet 连接到 Azure，网络流量的精确路由将取决于构成 Internet 基础设施的众多网络服务提供商。 如Microsoft产品和服务 数据保护附录（DPA）中所述，Microsoft不会控制或限制你或最终用户可以访问或移动客户数据的区域。

在 Azure 服务中，传入和传出服务的流量 受 TLS 1.2 保护 ，使用 RSA-2048 进行密钥交换，使用 AES-256 进行数据加密。 相应的加密模块在 Microsoft Windows FIPS 验证程序中验证 FIPS 140。

TLS 提供强身份验证、消息隐私和完整性。 完美转发保密（PFS） 通过为每个启动的会话生成唯一会话密钥来保护客户端系统和Microsoft云服务之间的连接。 PFS 可保护过去会话免受潜在的未来关键威胁。 这种组合使得截获和访问传输中的数据更加困难。

VM 的传输中加密 – 可以通过协议对 Azure 中部署的 Windows 和 Linux VM 进行远程会话，以确保传输中的数据加密。 例如，从客户端计算机到 Windows 和 Linux VM 发起的 远程桌面协议（RDP） 为传输中的数据启用 TLS 保护。 还可以使用 安全外壳 （SSH）连接到在 Azure 中运行的 Linux VM。 SSH 是默认可用的加密连接协议，用于远程管理 Azure 中托管的 Linux VM。

Azure 存储事务 – 通过 Azure 门户与 Azure 存储交互时，所有事务都通过 HTTPS 进行。 此外，可以通过为存储帐户设置“需要安全传输”属性，将存储帐户配置为仅接受来自安全连接的请求。 在 Azure 门户中创建存储帐户时，默认启用“需要安全传输”选项。

Azure 文件提供云中完全托管的文件共享，这些共享项可通过行业标准的服务器消息块 (SMB) 协议进行访问。 默认情况下，所有 Azure 存储帐户 都启用了传输中的加密。 因此，当通过 SMB 装载共享或通过 Azure 门户（或 Azure PowerShell、Azure CLI 和 Azure SDK）访问共享时，只有在使用 SMB 3.0+ 加密或通过 HTTPS 进行连接时，Azure 文件才会允许连接。

数据中心连接到 Azure 区域

VPN 加密 – 虚拟网络 （VNet）为 Azure 虚拟机（VM）提供一种充当内部（本地）网络的一部分的方法。 使用 VNet，可以选择要分配给 VM 的非全局可路由 IP 地址的地址范围，以便它们不会与你在其他地方使用的地址相冲突。 可以选择从本地基础结构或远程位置安全地连接到 VNet。

• 站点到站点 （IPsec/IKE VPN 隧道） - 在 Azure 与内部网络之间建立加密保护的“隧道”，允许 Azure VM 连接到后端资源，就像它直接位于该网络上一样。 这种类型的连接需要位于本地的 VPN 设备 ，该设备分配有一个面向外部的公共 IP 地址。 可以使用 Azure VPN 网关 通过公共 Internet 在 VNet 和本地基础结构之间发送加密流量，例如， 站点到站点 VPN 依赖于 IPsec 进行传输加密。 VPN 网关支持许多经过 FIPS 140 验证的加密算法。 此外，可以将 VPN 网关配置为使用具有特定加密算法和密钥强度的 自定义 IPsec/IKE 策略 ，而不是依赖于默认 Azure 策略。 IPsec 在 IP 级别（网络第 3 层）加密数据。
• 点到站点（通过 SSTP、OpenVPN 和 IPsec 实现的 VPN） - 使用安全套接字隧道协议 (SSTP)、OpenVPN 或 IPsec 从单个客户端计算机到 VNet 建立安全连接。 作为 点到站点 VPN 配置的一部分，需要安装证书和 VPN 客户端配置包，使客户端计算机能够连接到 VNet 中的任何 VM。 点到站点 VPN 连接不需要 VPN 设备或面向公众的 IP 地址。

除了控制 VPN 连接支持的算法类型外，Azure 还能够强制实施离开 VNet 的所有流量只能通过 VNet 网关（例如 Azure VPN 网关）进行路由。 通过此强制措施，可以确保流量不得在未加密的情况下离开 VNet。 VPN 网关可用于 VNet 到 VNet 连接，同时通过 IPsec/IKE 提供安全隧道。 Azure VPN 使用 预共享密钥（PSK）身份验证， Microsoft在创建 VPN 隧道时生成 PSK。 可以将自动生成的 PSK 更改为您自己的。

Azure ExpressRoute 加密 – Azure ExpressRoute 允许在Microsoft数据中心与本地基础结构或托管设施之间创建专用连接。 ExpressRoute 连接不会超过公共 Internet，并且比受 IPsec 保护的 VPN 连接低延迟和可靠性。 ExpressRoute 位置 是Microsoft全球网络主干的入口点，它们可能与 Azure 区域的位置不匹配。 一旦网络流量进入微软主干网，确保会通过专用网络基础结构，而不是通过公共互联网。 可以将 ExpressRoute 与多个数据 加密选项一起使用，包括 MACsec ，使你能够在 Azure Key Vault 中存储 MACsec 加密密钥。 MACsec 在媒体访问控制 (MAC) 级别加密数据，即数据链路层（网络第 2 层）。 支持使用 AES-128 和 AES-256 分组加密进行加密。 通过 ExpressRoute Direct 连接到Microsoft时，可以使用 MACsec 加密网络设备和Microsoft网络设备之间的物理链接。 ExpressRoute Direct 允许从您的边缘到对等位置的 Microsoft 企业边缘路由器进行直接的光纤连接。

除了 ExpressRoute Direct 端口上的 MACsec 之外，还可以启用 IPsec，如图 11 所示。 使用 VPN 网关，可以通过本地网络与 Azure VNet 之间 ExpressRoute 线路的 Microsoft 对等互连设置 IPsec 隧道。 MACsec 保护本地网络与Microsoft之间的物理连接。 IPsec 保护本地网络与 Azure 中的 VNet 之间的端到端连接。 可以独立启用 MACsec 和 IPsec。

图 11。 传输中数据的 VPN 和 ExpressRoute 加密

跨 Microsoft 全球网络主干的流量

可将存储和 SQL 数据库等 Azure 服务配置为异地复制，以帮助确保持久性和高可用性，尤其是灾难恢复方案。 Azure 依靠配对区域来提供异地冗余存储（GRS），并且在为 Azure SQL 数据库配置活动异地复制时，也建议使用配对区域。 配对区域位于同一地理位置;但是，不保证网络流量始终遵循从一个 Azure 区域到另一个 Azure 区域相同的路径。 为了提供 Azure 云所需的可靠性，Microsoft 提供了许多物理网络路径，这些路径可以自动绕过故障进行路由以获得最佳可靠性。

此外，Microsoft 使用 MACsec 加密在区域内或区域之间传输的所有 Azure 流量，其中 MACsec 依赖于 AES-128 块密码进行加密。 此流量完全停留在Microsoft 全球网络主干 中，永远不会进入公共 Internet。 这个骨干网是世界上最大的之一，拥有超过25万公里的点亮光纤和海底电缆系统。

第三方网络虚拟设备

Azure 提供了许多功能来帮助实现安全性和隔离目标，包括 Microsoft Defender for Cloud、 Azure Monitor、 Azure 防火墙、 VPN 网关、 网络安全组、 应用程序网关、 Azure DDoS 防护、 网络观察程序、 Microsoft Sentinel 和 Azure Policy。 除了 Azure 提供的内置功能外，还可以使用第三方 网络虚拟设备 来满足特定的网络隔离要求，同时应用现有的内部技能。 Azure 支持许多设备，包括 F5、Palo Alto Networks、Cisco、Check Point、Barracuda、Citrix、Fortinet 等产品/服务。 网络设备以虚拟网络和部署中的 VM 的形式支持网络功能和服务。

网络隔离限制的累积影响是，每个云服务都如同位于一个隔离网络上，云服务中的 VM 可以自信地通过其源 IP 地址相互识别和通信，确信没有其他方可以模拟其对等 VM。 还可以将其配置为通过特定端口和协议接受来自 Internet 的传入连接，并确保离开虚拟网络的所有网络流量始终加密。

存储隔离

Microsoft Azure 将其基于 VM 的计算资源与存储分开，作为其 基本设计的一部分。 分离使得计算和存储能够独立扩展，从而更轻松地实现多租户和隔离。 因此，Azure 存储在单独的硬件上运行，且没有与 Azure 计算建立网络连接，从逻辑上讲时例外。

每个 Azure 订阅 可以有一个或多个存储帐户。 Azure 存储支持各种 身份验证选项，包括：

• 共享对称密钥 – 创建存储帐户后，Azure 会生成两个 512 位存储帐户密钥，用于控制对存储帐户的访问。 之后，可以随时轮换和重新生成这些密钥，而无需与应用程序协调。
• 基于Microsoft Entra ID 的身份验证 - Microsoft Entra ID 可以控制对 Azure 存储的访问；这一身份验证方式强制实施租户隔离并实施可靠的措施，以防止未经授权的参与方（包括Microsoft内部人员）的访问。 有关 Microsoft Entra 租户隔离的详细信息，请参阅白皮书 Microsoft Entra 数据安全注意事项。
• 共享访问签名 （SAS） - 可以从共享对称密钥创建共享访问签名或“预签名 URL”。 这些 URL 在范围内可以显著限制，以减少可用的攻击面，但同时允许应用程序向其他用户、服务或设备授予存储访问权限。
• 用户委托 SAS – 委派身份验证类似于 SAS，但 基于 Microsoft Entra 令牌 而不是共享对称密钥。 此方法允许使用 Microsoft Entra ID 进行身份验证的服务创建具有有限范围的预签名 URL，并授予对其他用户、服务或设备的临时访问权限。
• 匿名公共读取访问 – 可以允许一小部分存储在未经身份验证或授权的情况下公开访问。 如果需要更严格的控制，可以在订阅级别禁用此功能。

Azure 存储为各种工作负荷提供存储，包括：

• Azure 虚拟机（磁盘存储）
• 大数据分析（HDInsight、Azure Data Lake Storage 的 HDFS）
• 存储应用程序状态、用户数据（Blob、队列、表存储）
• 长期数据存储（Azure 存档存储）
• 云中的网络文件共享（文件存储）
• 在 Internet 上提供网页（静态网站）

虽然 Azure 存储支持许多不同的面向外部的客户存储方案，但在内部，上述服务的物理存储由一组常见的 API 管理。 为了提供持久性和可用性，Azure 存储依赖于在租户之间共享的存储资源的数据复制和数据分区。 为了确保逻辑数据隔离的加密确定性，Azure 存储依赖于静态数据加密，使用具有多个密码的高级算法，如本部分所述。

数据复制

始终 复制 Azure 存储帐户中的数据，以帮助确保持久性和高可用性。 Azure 存储通过复制数据来保护原始数据，以抵御暂时性硬件故障、网络或电力中断，甚至大规模自然灾害的影响。 通常可以选择在同一数据中心内、 跨同一区域中的可用性区域或跨地理分隔区域复制数据。 具体而言，创建存储帐户时，可以选择以下 冗余选项之一：

• 本地冗余存储（LRS） 复制单个数据中心内数据的三个副本（或擦除编码的等效副本，如稍后所述）。 仅当数据写入到所有三个副本后，LRS 存储帐户的写入请求才会成功返回。 每个副本分别驻留在规模单元（数据中心中的一组存储机架）内的不同容错域和升级域中。
• 区域冗余存储（ZRS） 跨单个 区域中的三个存储群集同步复制数据。 每个存储群集在物理上与其他群集分开，并且位于其自己的 可用性区域 （AZ）。 只有在数据已写入到三个群集中的所有副本后，发送到 ZRS 存储帐户的写入请求才会成功返回。
• 异地冗余存储（GRS） 将数据复制到离主要区域数百公里的 次要（配对）区域 。 GRS 存储帐户即使在发生整个区域故障或主要区域不可恢复的灾难时也具有持久性。 对于启用了 GRS 或 RA-GRS 的存储帐户，首先使用 LRS 复制所有数据。 首先将更新提交到主位置，并使用 LRS 进行复制。 然后，使用 GRS 以异步方式将更新复制到次要区域。 将数据写入次要位置后，还会使用 LRS 在该位置复制数据。
• 读取访问异地冗余存储（RA-GRS） 基于 GRS。 除了在两个区域之间进行地理复制之外，它还提供对辅助位置中数据的只读访问权限。 如果使用 RA-GRS，无论 Microsoft 是否发起从主要区域到次要区域的故障转移，都能从次要区域读取数据。
• 异地区域冗余存储（GZRS）将 ZRS 的高可用性与 GRS 提供的区域中断保护相结合。 GZRS 存储帐户中的数据在主要区域中的三个 AZ 之间复制，并复制到次要地理区域，以防御区域灾难。 每个 Azure 区域与同一地理位置中的另一个区域配对，组成一个区域对。
• 读取访问异地区域冗余存储（RA-GZRS） 基于 GZRS。 如果你的应用程序需要在主要区域中发生灾难后读取数据，则可以选择使用 RA-GZRS 启用对次要区域中数据的读取访问权限。

高级 Azure 存储体系结构

Azure 存储生产系统由存储戳和位置服务（LS）组成，如图 12 所示。 存储单元是存储节点的机架群集，其中每个机架都构建为具有冗余网络和电源的独立容错域。 LS 跨所有标记管理所有存储单元和帐户命名空间。 它将帐户分配给存储单元，并在存储单元中管理这些帐户，以便进行负载均衡和灾难恢复。 LS 本身被分布在两个地理位置，以便进行自身的灾难恢复（Calder 等，2011）。

图 12。 高级 Azure 存储体系结构（源： Calder，et al.， 2011）

存储戳中有三个层：前端、分区和流。 本部分的其余部分将介绍这些层。

前端层

前端 （FE） 层由一组无状态服务器组成，这些服务器采用传入请求、对请求进行身份验证和授权，然后将其路由到分区层中的分区服务器。 FE 层知道要转发每个请求的分区服务器，因为每个前端服务器缓存分区映射。 分区映射跟踪要访问的服务的分区，以及哪些分区服务器正在控制对系统中每个分区的访问（服务）。 FE 服务器还直接从流媒体层流式传输大型对象。

通过 Internet 传输大量数据本质上是不可靠的。 使用 Azure 块 Blob 服务，可以通过将大型文件分解为较小的数据块来有效地上传和存储大型文件。 通过这种方式，块 Blob 允许将数据分区为单个块，以实现大型上传的可靠性，如图 13 所示。 每个块的大小最多可为 100 MB，块 Blob 中最多可以有 50,000 个块。 如果块无法正确传输，则只有该特定块需要重新发送，而无需重新发送整个文件。 此外，使用块 Blob 类型，可以并行发送多个块以缩短上传时间。

图 13.将数据块 Blob 分区成单个块

可以按任意顺序上载块，并确定这些块在最终块列表提交步骤中的顺序。 也可以上载新块来替换具有相同的块 ID 的现有未提交块。

分区层

分区层负责：

• 管理更高级别的数据抽象（Blob、表、队列），
• 提供可缩放的对象命名空间，
• 为对象提供事务排序和高度一致性，
• 将对象数据存储在流层的顶部，以及
• 缓存对象数据以减少磁盘 I/O。

此层还提供数据的异步异地复制，并侧重于跨标记复制数据。 在后台进行跨印章复制，以便在两个位置保留数据副本，以实现灾难恢复。

在 FE 层引入 Blob 后，分区层负责跟踪和存储将数据放置在流层中的位置。 每个存储租户可以有大约 200 - 300 个单独的分区层节点，每个节点负责跟踪和提供存储在该存储租户中的数据的分区。 高吞吐量块 Blob （HTBB） 功能允许在单个 Blob 中分片数据，从而允许在多个分区层服务器之间共享大型 Blob 的工作负荷（图 14）。 在多个分区层服务器之间分配负载可大大提高可用性、吞吐量和持久性。

图 14。 高吞吐量块 Blob 将流量和数据分布到多个分区服务器和数据流中

流层

流层将位存储在磁盘上，负责跨多个服务器分发和复制数据，以在存储戳中持久保存数据。 它充当印章中的分布式文件系统层。 它处理称为流的文件，这些文件是称为盘区的数据块的有序列表，这些块类似于物理硬盘驱动器上的盘区。 大型 Blob 对象可以存储在多个区中，可能存储在多个物理区节点上（EN）。 数据存储在流层中，但可从分区层访问。 分区服务器和流服务器在标记中的每个存储节点上并置。

流层跨不同容错域中的不同节点提供同步复制（存储单元内），以确保存储单元内的数据持久性。 它负责创建每个区段的三个本地复制副本。 流层管理器确保所有三个副本分布在不同容错域和升级域上的不同物理机架和节点上，使副本能够抵抗各个磁盘、节点和机架的故障，以及由于升级而计划内的停机。

擦除编码 – Azure 存储使用一种称为擦除编码的技术，即使由于磁盘故障丢失了一些数据，也能够重建数据。 此方法类似于单个磁盘的 RAID 条带化概念，其中数据分布在多个磁盘上，以便如果磁盘丢失，则可以使用来自其他磁盘上的数据的奇偶校验位重新构造缺失的数据。 擦除编码将范围拆分为存储在单独的 EN 上的相同数据和奇偶校验片段，如图 15 所示。

图 15.擦除跨 EN 服务器进一步分片区数据，以防止故障

存储在流区节点中的所有数据块都具有64位循环冗余检查（CRC）和受哈希签名保护的标头，以提供流区节点（EN）数据完整性。 在每次磁盘写入、磁盘读取和网络接收之前，都会检查 CRC 和签名。 此外，清理器会定期读取所有数据，以验证 CRC 并查找位腐烂。 如果发现某个错误的盘区，则会创建该盘区的新副本来替换错误的盘区。

Azure 存储中的数据依赖于静态数据加密来提供逻辑数据隔离的加密确定性。 可以在Microsoft管理的加密密钥（也称为平台管理的加密密钥）或客户管理的加密密钥（CMK）之间进行选择。 如下一部分所述，对客户而言，数据加密和解密的处理是透明的。

静止状态下的数据加密

Azure 提供了广泛的 静态数据加密 选项，可帮助保护数据，并在使用Microsoft管理的加密密钥和客户管理的加密密钥时满足合规性需求。 有关详细信息，请参阅数据加密模型。 此过程依赖于多个加密密钥和服务（例如 Azure Key Vault 和 Microsoft Entra ID），以确保安全密钥访问和集中密钥管理。

一般情况下，控制密钥访问并确保通过以下类型的加密密钥（如图 16 所示）实现数据高效批量加密和解密，但其他加密密钥可以如 存储服务加密 部分中所述使用。

• 数据加密密钥（DEK） 是对称 AES-256 密钥，用于对分区或数据块进行批量加密和解密。 加密模块作为 Windows FIPS 验证程序的一部分进行 FIPS 140 验证。 资源提供程序或应用程序实例需要访问 DEK，该实例负责加密和解密特定数据块。 单个资源可能有多个分区和多个 DEK。 当 DEK 替换为新密钥时，必须使用新密钥重新加密其关联块中的数据。 DEK 始终由密钥加密密钥 (KEK) 加密存储。
• 密钥加密密钥（KEK） 是可选的非对称 RSA 密钥，由你选择提供。 此密钥加密密钥用于使用 Azure Key Vault 或托管 HSM 加密数据加密密钥（DEK）。 如数据 加密密钥管理 部分所述，Azure Key Vault 可以使用 FIPS 140 验证的硬件安全模块（HSM）来保护加密密钥;托管 HSM 始终使用 FIPS 140 验证的硬件安全模块。 这些密钥不可导出，并且 HSM 外部没有 KEK 的明文版本 – 绑定由基础 HSM 强制实施。 KEK 永远不会直接公开给资源提供程序或其他服务。 对 KEK 的访问由 Azure Key Vault 中的权限控制，并且必须通过 Microsoft Entra ID 对 Azure Key Vault 的访问进行身份验证。 可以撤销这些权限以阻止对此密钥的访问，从而阻止通过此密钥作为密钥链根密钥加密的数据的访问。

图 16 中的密钥加密的。使用存储在 Azure Key Vault 中的密钥对数据加密密钥进行加密

因此，加密密钥层次结构涉及 DEK 和 KEK。 DEK 使用 KEK 进行加密，并单独存储，供资源提供程序在批量加密和解密作中高效访问。 但是，只有有权访问 KEK 的实体才能解密 DEK。 具有 KEK 访问权限的实体可能不同于需要 DEK 的实体。 由于需要 KEK 来解密 DEK，因此 KEK 实际上是一个单一点，可通过删除 KEK 来删除 DEK。

联机文档中提供了有关许多 Azure 平台服务的密钥管理的各种 数据加密模型 和细节的详细信息。 此外，某些 Azure 服务提供其他 加密模型，包括客户端加密，以使用更精细的控制进一步加密其数据。 本部分的其余部分介绍关键 Azure 存储方案的加密实现，例如 IaaS 虚拟机的存储服务加密和磁盘加密。

存储服务加密

静态数据的 Azure 存储服务加密 可确保在将数据保存到 Azure 存储之前自动加密，并在检索之前解密数据。 写入 Azure 存储的所有数据都通过 FIPS 140 验证的 256 位 AES 加密进行加密，存储服务加密中的加密、解密和密钥管理对客户是透明的。 默认情况下，Microsoft控制加密密钥，并负责密钥轮换、使用情况和访问。 密钥安全地存储在 Microsoft 密钥存储中并受到保护。 鉴于所有 Azure 存储服务都受支持，此选项提供最方便的方式。

但是，还可以通过指定以下内容选择使用自己的密钥管理加密：

• 用于管理 Azure 存储加密的客户管理的密钥，其中密钥存储在 Azure Key Vault 中。 此选项为创建、轮换、禁用和撤销对客户管理的密钥的访问权限提供了很大的灵活性。 必须使用 Azure Key Vault 来存储客户管理的密钥。 如前所述，在 Azure Key Vault 部分中，支持密钥保管库和托管 HSM。
• 客户提供的密钥 用于加密和解密 Blob 存储，密钥可以存储在 Azure Key Vault 或您本地的密钥存储中，以满足合规性要求。 通过客户提供的密钥，您可以在读取或写入操作中使用 Blob API 将加密密钥传递给存储服务。

默认情况下，所有新的和现有的存储帐户都启用存储服务加密， 并且无法禁用。 如图 17 所示，加密过程使用以下密钥来帮助确保静态数据隔离的加密确定性：

• 数据加密密钥（DEK） 是一个对称 AES-256 密钥，用于批量加密，并且每个存储帐户在 Azure 存储中是唯一的。 它由 Azure 存储服务作为存储帐户创建的一部分生成，用于为每个数据块派生唯一密钥。 如果客户配置了客户管理的密钥加密，存储服务始终使用 Stamp 密钥或密钥加密密钥（Key Encryption Key）加密 DEK。
• 密钥加密密钥（KEK） 是由客户管理的非对称 RSA （2048 或更高版本）密钥，用于使用 Azure Key Vault 或托管 HSM 加密数据加密密钥（DEK）。 它绝不会直接暴露给 Azure 存储服务或其他服务。
• 印章密钥（SK） 是由 Azure 存储管理的对称 AES-256 密钥。 不使用客户管理的密钥时，此密钥用于保护 DEK。

这些密钥保护写入 Azure 存储的任何数据，并为 Azure 存储中的逻辑数据隔离提供加密确定性。 如前所述，Azure 存储服务加密默认处于启用状态，并且无法禁用。

图 17。 存储服务加密的加密流

不管存储帐户的性能层（标准或高级）或部署模型（Azure 资源管理器或经典）是什么，都会将其加密。 所有 Azure 存储 冗余选项 都支持加密，并且已加密存储帐户的所有副本。 所有 Azure 存储资源（包括 Blob、磁盘、文件、队列和表）都会加密。 所有对象元数据也会加密。

由于数据加密由存储服务执行，使用客户管理密钥（CMK）的服务器端加密使您能够为虚拟机使用任何操作系统类型和映像。 对于 Windows 和 Linux IaaS VM，Azure 还提供 Azure 磁盘加密，使你能够使用来宾 VM 或 EncryptionAtHost 中的 CMK 加密托管磁盘，以加密主机上的磁盘数据，如后续部分所述。 Azure 存储服务加密还提供 对静态磁盘数据的双重加密。

Azure 磁盘加密

Azure 存储服务加密会加密存储 Azure 虚拟机磁盘的页面 Blob。 此外，还可以选择使用 Azure 磁盘加密 来加密 Azure Windows 和 Linux IaaS 虚拟机磁盘，以提高存储隔离，并确保 Azure 中存储数据的加密确定性。 此加密包括 托管磁盘，如本节稍后所述。 Azure 磁盘加密使用 Windows 的行业标准 BitLocker 功能和 Linux 的 DM-Crypt 功能来提供与 Azure Key Vault 集成的基于 OS 的卷加密。

通过 BitLocker 和 DM-Crypt 进行驱动器加密是一项数据保护功能，它与操作系统集成，可解决数据被盗或泄露、丢失、被盗或不当解除授权计算机的威胁。 当与受信任的平台模块 （TPM） 版本 1.2 或更高版本一起使用时，BitLocker 和 DM-Crypt 提供最大的保护。 TPM 是一种微控制器，旨在通过集成加密密钥保护硬件 - 它通常预安装在较新的计算机上。 BitLocker 和 DM-Crypt 可以使用这项技术来保护用于加密磁盘卷的密钥，并为计算机启动过程提供完整性。

对于托管磁盘，Azure 磁盘加密允许加密 IaaS 虚拟机使用的 OS 和数据磁盘;但是，如果不首先加密 OS 卷，则无法加密数据。 解决方案依赖于 Azure Key Vault 来帮助控制和管理密钥保管库中的磁盘加密密钥。 可以提供自己的加密密钥，这些加密密钥在 Azure Key Vault 中受到保护，以支持 自带密钥（BYOK） 方案，如 数据加密密钥管理 部分前面所述。

Azure 磁盘加密不支持托管 HSM 或本地密钥管理服务。 只有 Azure Key Vault 服务管理的密钥保管库可用于保护 Azure 磁盘加密的客户管理的加密密钥。 有关涉及托管 HSM 的其他选项，请参阅 主机加密 。

Azure 磁盘加密依赖于两个加密密钥实现，如前所述：

• 数据加密密钥（DEK） 是一种对称 AES-256 密钥，用于通过 BitLocker 或 DM-Crypt 加密 OS 和数据卷。 DEK 本身已加密并存储在靠近数据的内部位置。
• 密钥加密密钥（KEK） 是用于加密数据加密密钥的非对称 RSA-2048 密钥。 KEK 保留在 Azure Key Vault 中，由你控制，包括通过 Microsoft Entra ID 授予访问权限。

使用 KEK 加密的 DEK 单独存储，只有有权访问 KEK 的实体才能解密 DEK。 Azure Key Vault 可保护对 KEK 的访问，可在其中选择将密钥存储在 FIPS 140 验证的硬件安全模块中。

对于 Windows VM，Azure 磁盘加密根据 Windows 版本在 BitLocker 中选择加密方法，例如，XTS-AES 256 位（对于 Windows Server 2012 或更高版本）。 这些加密模块经过 FIPS 140 验证，作为 Microsoft Windows FIPS 验证计划的一部分。 对于 Linux VM，Azure 磁盘加密使用 aes-xts-plain64 的解密默认值，该密钥的 256 位卷主密钥通过了 FIPS 140 认证，这一认证是 Linux IaaS VM 映像供应商在 Microsoft Azure 市场中获得的 DM-Crypt 验证的一部分。

托管磁盘的服务器端加密

Azure 托管磁盘 是 Azure 管理的块级存储卷，用于 Azure Windows 和 Linux 虚拟机。 它们通过以透明方式处理存储帐户管理来简化 Azure IaaS VM 的磁盘管理。 默认情况下，Azure 托管磁盘使用经过 FIPS 140 验证的 256 位 AES 加密自动加密 数据。 对于加密密钥管理，可以选择以下选项：

• 平台管理的密钥 是默认选择，它为托管磁盘提供静态透明数据加密，通过Microsoft管理密钥。
• 通过客户管理的密钥 ，你可以控制自己的密钥，这些密钥可以导入或生成到 Azure Key Vault 或托管 HSM 中。 此方法依赖于前面所述的两组密钥：DEK 和 KEK。 DEK 使用基于 AES-256 的加密来加密数据，并由存储在 Azure Key Vault 或托管 HSM 中的 RSA KEK 进行加密。

通过客户管理的密钥（CMK），你可以 完全控制 加密密钥。 可以授予对 Azure Key Vault 中托管磁盘的访问权限，以便密钥可用于加密和解密 DEK。 还可以随时禁用密钥或撤销对托管磁盘的访问权限。 最后，可以通过 Azure Key Vault 监视对密钥使用情况进行完全审核控制，以确保只有托管磁盘或其他授权资源才能访问加密密钥。

主机加密

主机加密适用于服务器端加密，以确保存储在 VM 主机上的数据静态加密，并将流加密到存储服务。 托管 VM 的服务器使用配置为服务器端加密的密钥来加密数据，且不会对来宾 VM 中运行的代码造成性能影响或要求，并且加密的数据会流入 Azure 存储。 有关详细信息，请参阅 主机加密 - VM 数据的端到端加密。 使用 CMK 的主机加密可以使用托管 HSM 或 Key Vault 中存储的密钥，就像托管磁盘的服务器端加密一样。

您始终可以控制 Azure 中的 客户数据。 你可以随时访问、提取和删除存储在 Azure 中的客户数据。 终止 Azure 订阅时，Microsoft采取必要的步骤来确保继续拥有客户数据。 数据删除或订阅终止的一个常见问题是，另一个客户或 Azure 管理员可以访问已删除的数据。 以下部分介绍了数据删除、保留和销毁在 Azure 中的工作原理。

数据删除

存储是稀疏分配的，这意味着在创建虚拟磁盘时，不会为其整个容量分配磁盘空间。 而是会创建一个表格，用于将虚拟磁盘上的地址映射到物理磁盘上的区域中，且该表最初为空。 首次在虚拟磁盘上写入数据时，将分配物理磁盘上的空间，并将指向该磁盘的指针放置在表中。 有关详细信息，请参阅 Azure 数据安全性 - 数据清理和泄露。

删除 Blob 或表实体时，它将立即从用于查找和访问主位置上的数据的索引中删除，然后在数据异地复制副本（如果预配 异地冗余存储）上异步完成删除。 在主要位置，可以立即尝试访问 Blob 或实体，并且不会在索引中找到它，因为 Azure 为删除提供了很强的一致性。 因此，可以直接验证数据是否已删除。

在 Azure 存储中，所有磁盘写入都是顺序的。 此方法可最大程度地减少磁盘“查找”的次数，但是每次写入对象时，都需要更新指向这些对象的指针，同时，指针的新版本也会按顺序写入。 此设计的副作用是，无法确保磁盘上的机密通过用其他数据覆盖它而消失。 原始数据将保留在磁盘上，新值将按顺序写入。 指针将更新，这样便无法再找到已删除的值。 但是，一旦磁盘已满，系统必须将新日志写入通过删除旧数据释放的磁盘空间。 在运行 NTFS 的文件系统中创建日志文件，而不是直接从磁盘扇区分配日志文件。 在 Azure 存储节点上运行的后台线程通过浏览最早的日志文件、将仍从最早日志文件引用的块复制到当前日志文件以及更新所有指针来释放空间。 然后，它会删除最早的日志文件。 因此，磁盘上有两类可用磁盘空间：（1）NTFS 识别为可用的空间，新日志文件从这部分空间中分配；（2）Azure 存储识别的日志文件中的可用空间，因为没有指向这些空间的当前指针。

与已删除数据关联的物理磁盘上的扇区将立即可供重复使用，并在重复使用相应的存储块以存储其他数据时被覆盖。 覆盖时间因磁盘利用率和活动而异。 此过程与日志结构化文件系统的作一致，其中所有写入都按顺序写入磁盘。 此过程不是确定性的，并且无法保证特定数据何时从物理存储中消失。 但是，完全删除的数据何时被覆盖，或相应物理存储何时被分配给另一个客户，与密钥隔离保证在删除后无法恢复任何数据无关：

• 客户无法读取另一个客户的已删除数据。
• 如果有人尝试读取尚未写入到的虚拟磁盘上的区域，则不会为该区域分配物理空间，因此只返回零。

客户不提供对基础物理存储的直接访问。 由于客户软件仅处理虚拟磁盘，因此，其他客户无法请求读取或写入分配给你的物理地址或未被分配的物理地址。

从概念上讲，无论跟踪读取和写入的软件如何，此理由都适用。 对于 Azure SQL 数据库，是 SQL 数据库软件在强制执行这一点。 对于 Azure 存储，它是 Azure 存储软件。 对于 VM 的非持久驱动器，这是宿主操作系统的 VHD 处理代码。 从虚拟到物理地址的映射发生在客户 VM 之外。

最后，如静态 数据加密 部分中所述，加密密钥层次结构依赖于密钥加密密钥（KEK），密钥加密密钥（KEK）可以保留在 Azure Key Vault 中（即客户管理的密钥 - CMK），并用于加密数据加密密钥（DEK），后者又使用 AES-256 对称加密对静态数据进行加密。 默认情况下，Azure 存储中的数据是静态加密的，可以选择自己控制加密密钥。 通过这种方式，还可以阻止访问存储在 Azure 中的数据。 此外，由于 KEK 需要解密 DEK，因此 KEK 实际上是一个单一点，可通过删除 KEK 来删除 DEK。

数据保留期

在 Azure 订阅期间，始终能够访问、提取和删除存储在 Azure 中的数据。

如果订阅过期或终止，Microsoft将客户数据保留 90 天保留期，以允许提取数据或续订订阅。 在此保留期之后，Microsoft将在另外 90 天内删除所有客户数据，也就是说，客户数据将在到期或终止后的 180 天内永久删除。 根据数据保留程序，您可以通过决定何时终止与 Microsoft 的服务来控制数据的存储时长。 建议在提取所有数据之前不要终止服务，以便初始的 90 天保留期可以充当安全缓冲区（如果以后意识到错过了某些内容）。

如果错误地删除了整个存储帐户，则应及时联系 Azure 支持部门 以获取有关恢复的帮助。 可以在 Azure 门户中 创建和管理支持请求 。 在订阅中删除的存储帐户将保留两周，以允许从意外删除中恢复，之后会永久删除该帐户。 但是，当存储对象（例如 blob、文件、队列、表）本身被删除时，删除作是即时且不可逆的。 除非进行了备份，否则无法恢复已删除的存储对象。 对于 Blob 存储，可以通过启用 软删除来实现对意外或错误修改或删除的额外保护。 如果为存储帐户启用了软删除，则该存储帐户中的 Blob、Blob 版本和快照被删除后可以在指定的保留期内恢复。 若要避免在存储帐户或订阅删除后保留数据，可以在删除存储帐户或订阅之前单独删除存储对象。

对于涉及 Azure SQL 数据库的意外删除，应检查服务自动执行的备份并使用时间点还原。 例如，完整数据库备份每周完成，差异数据库备份每小时完成一次。 此外，单个服务（例如 Azure DevOps）可以有自己的策略来 意外删除数据。

数据销毁

如果用于存储的磁盘驱动器出现硬件故障，则会在退役之前安全地 擦除或销毁。 擦除驱动器上的数据，以确保无法以任何方式恢复数据。 当此类设备停用时，Microsoft遵循 NIST SP 800-88 R1 处置过程，并将数据分类与 FIPS 199 Moderate 保持一致。 根据 NIST SP 800-88 R1 中确定的要求，清除或销毁磁介质、电子介质或光学介质，其中术语的定义如下：

• 清除 – “一种媒体清理过程，旨在防止信息在实验室攻击下的泄密”，该过程涉及“利用非标准系统进行数据恢复尝试”的“资源和知识”，并使用“信号处理设备和专门培训的人员”。 注意：对于硬盘驱动器（包括 ATA、SCSI、SATA、SAS 等），可以接受固件级安全擦除命令（单一传递），或者软件级三通覆盖和验证（一个、零、随机），包括恢复区域（如果有）。 对于固态磁盘（SSD），需要固件级安全擦除命令。
• 销毁 - “使用多种方法，包括解体、焚烧、粉粹、破碎和融化”，之后媒体“将无法再按照原来的用途使用”。

必须使用Microsoft安全性批准的工具和流程执行清除和销毁作。 必须保留资产的擦除和销毁记录。 未能成功完成清除的设备（仅适用于磁介质）必须被消磁或销毁。

除了支持 Azure 计算、网络和存储隔离技术的具体实现细节外，Microsoft 还大力投入到安全保障流程和实践中，以正确开发逻辑隔离的服务和系统，详见下一节内容。

安全保障流程和做法

Azure 隔离保证通过 Microsoft 内部使用 安全开发生命周期（SDL） 和其他强大的安全保证流程来进一步实施，以保护攻击面并缓解威胁。 Microsoft建立了行业领先的流程和工具，为 Azure 隔离保证提供高度信心。

• 安全开发生命周期 （SDL） - Microsoft SDL 在整个开发过程的各个阶段都引入了安全和隐私注意事项，帮助开发人员构建高度安全的软件、满足安全合规性要求并降低开发成本。 Microsoft SDL 中的指南、最佳做法、 工具和流程是内部用于生成所有 Azure 服务并创建更安全的产品和服务 的做法 。 此过程也被公开记录，以与更广泛的行业分享Microsoft的学习，并整合行业反馈，以创建更强大的安全开发过程。
• 工具和进程 – 所有 Azure 代码都受一组广泛的静态和动态分析工具的约束，这些工具可识别潜在的漏洞、无效的安全模式、内存损坏、用户特权问题和其他严重安全问题。
  • 目的构建模糊 - 用于查找软件产品和服务中的安全漏洞的测试技术。 它包括反复向软件输入馈送修改或模糊的数据，以触发挂起、异常和崩溃，这是攻击者可能用来中断或控制应用程序和服务的故障条件。 MICROSOFT SDL 建议模糊软件产品的所有攻击面，尤其是那些向不受信任的数据公开数据分析器的攻击面。
  • 实时站点渗透测试 – Microsoft进行 持续实时站点渗透测试 ，以提高云安全控制和流程，这是本部分后面介绍的红队计划的一部分。 渗透测试是对熟练的安全专业人员执行的软件系统的安全分析，模拟黑客的行为。 渗透测试的目的是发现编码错误、系统配置错误或其他作部署弱点导致的潜在漏洞。 这些测试针对 Azure 基础结构和平台以及Microsoft自己的租户、应用程序和数据进行。 Azure 中托管的租户、应用程序和数据永远不会成为攻击目标；但是，您可以对部署在 Azure 上的应用程序进行自主渗透测试。
  • 威胁建模 – Microsoft SDL 的核心元素。 它是一种工程技术，用于帮助识别可能影响应用程序和服务的威胁、攻击、漏洞和对策。 威胁建模 是 Azure 例程开发生命周期的一部分。
  • 自动化构建提醒攻击面区域更改 - 攻击面分析器 是微软开发的开源安全工具，用于分析目标系统的攻击面，并报告在安装软件或系统配置错误过程中引入的潜在安全漏洞。 攻击面分析器的核心功能是能够在安装软件组件之前和之后比较操作系统的安全配置的差异。 此功能很重要，因为大多数安装过程都需要提升的权限，并且一旦授予权限，它们可能会导致意外的系统配置更改。
• 强制性安全培训 – Microsoft Azure 安全培训和意识计划要求负责 Azure 开发和运营的所有人员都根据个人工作要求接受基本培训和任何额外培训。 这些过程提供了一种标准方法、工具和技术，用于实现和维护意识计划。 Microsoft实施了一个名为 STRIKE 的安全意识计划，该计划每月向所有 Azure 工程人员发送关于安全意识的电子邮件通信，并允许员工注册参加现场或在线的安全意识培训。 STRIKE 全年提供一系列安全培训活动以及 STRIKE Central，这是一种集中的在线资源，用于安全意识、培训、文档和社区参与。
• Bug 赏金计划 – Microsoft强烈认为，与学术和行业研究人员的密切合作关系为你和数据提供了更高的安全保证。 安全研究人员通过发现在软件开发过程中错过的漏洞，在 Azure 生态系统中发挥着不可或缺的作用。 Microsoft Bug 赏金计划旨在补充和鼓励对相关技术（例如加密、欺骗、虚拟机监控程序隔离、特权提升等）的研究，以更好地保护 Azure 的基础结构和数据。 例如，对于 Azure 虚拟机监控程序中确定的每个关键漏洞，Microsoft向安全研究人员提供高达 250,000 美元的补偿，这大大可以激励参与和漏洞泄露。 Azure 服务漏洞报告的赏金范围高达 60,000 美元。
• 红队活动 – Microsoft使用Red Teaming，这是一种针对Microsoft托管的基础结构、服务和应用程序的现场渗透测试方法。 Microsoft模拟实际泄露、持续监视安全性和实践安全事件响应，以测试和改进 Azure 安全性。 红队作战是基于假设入侵安全策略进行的，由两个核心小组执行：红队（攻击者）和蓝队（防御者）。 此方法旨在使用与实际攻击者相同的策略、技术和程序来测试 Azure 系统和操作，而无需预知基础结构和平台工程或运营团队。 此方法测试安全检测和响应功能，并帮助以受控方式识别生产漏洞、配置错误、无效假设或其他安全问题。 每个红队违规行为随后在红队和蓝队之间全面披露，以确定差距、解决发现问题，并显著改善违规响应。

如果习惯于传统的本地数据中心部署，通常会进行风险评估来衡量威胁暴露，并在迁移到云时制定缓解措施。 在这些情况下，传统本地部署的安全注意事项往往可以很好地理解，而相应的云选项往往是新的。 下一部分旨在帮助你进行此比较。

逻辑隔离注意事项

多租户云平台意味着多个客户应用程序和数据存储在同一物理硬件上。 Azure 使用 逻辑隔离 将应用程序和数据与其他客户隔离。 此方法提供多租户云服务的规模和经济效益，同时严格帮助实施旨在防止其他客户访问数据或应用程序的控制措施。 如果要从传统的本地物理隔离基础结构迁移到云，本部分将介绍可能感兴趣的问题。

物理与逻辑安全注意事项

表 6 概述了物理隔离的本地部署（裸机）与逻辑隔离的基于云的部署（Azure）的关键安全注意事项。 在检查确定为特定于共享云环境的风险之前，查看这些注意事项非常有用。

表 6. 物理与逻辑隔离的关键安全注意事项

下面列出了在容纳敏感数据和工作负载时可能需要解决的共享云环境特有的关键风险。

利用虚拟化技术中的漏洞

与传统的本地托管系统相比，Azure 通过使用锁定的 Windows Server 核心，为构建在虚拟化程序之上的主机操作系统提供了显著减少的攻击面。 此外，默认情况下，来宾 PaaS VM 没有任何用户帐户接受传入远程连接，默认的 Windows 管理员帐户处于禁用状态。 默认情况下，PaaS VM 中的软件被限制为在低特权帐户下运行，这有助于保护服务免受其自身最终用户的攻击。 可以修改这些权限，还可以选择将 VM 配置为允许远程管理访问。

PaaS VM 比传统的物理服务器解决方案更高级 地保护持久性恶意软件 感染，如果攻击者入侵，即使漏洞得到纠正，也很难清理。 攻击者可能已经对允许重新输入的系统进行了修改，并且发现所有这些更改是一个挑战。 在极端情况下，系统必须从头开始重新映像，并重新安装所有软件，有时会导致应用程序数据丢失。 使用 PaaS VM 时，重新映像是作业的一个常规部分，它可以帮助清除尚未被检测到的入侵。 此方法使妥协更加难以持久化。

侧通道攻击

Microsoft 一直处于缓解推理执行端通道攻击的最前沿，这些攻击利用使用超线程处理的新式处理器中的硬件漏洞。 在许多方面，这些问题类似于 Spectre （变体 2） 侧通道攻击，这是在 2018 年披露的。 Intel 和 AMD 在 2022 年都披露了多个新的推测性执行侧信道问题。 为了解决这些漏洞，Microsoft开发了并优化了 HyperClear Hyper-V，这是一种全面且高性能的侧通道漏洞缓解体系结构。 HyperClear 依赖于三个主要组件来确保强大的 VM 间隔离：

• 用于避免共享 CPU 核心的专用缓冲区和其他资源的核心计划程序。
• 虚拟处理器地址空间隔离 ，以避免对另一个虚拟机内存或其他虚拟 CPU 核心的专用状态进行推理访问。
• 敏感数据清理以避免将专用数据保留在虚拟机监控程序内存中，而不是虚拟处理器的专用地址空间中的任意位置，以便将来无法以推理方式访问此数据。

这些保护已部署到 Azure，可在 Windows Server 2016 及更高版本中使用。

属于不同客户的 VM 在同一物理服务器上运行时，虚拟机监控程序的工作可确保他们无法了解其他客户的 VM 正在执行的操作。 Azure 有助于通过设计阻止未经授权的直接通信;但是，有一些细微的影响，其中一个客户可能能够描述另一个客户正在完成的工作。 其中最重要的这些影响是不同虚拟机在争用相同资源时的时间效应。 通过仔细比较 CPU 上的操作计数和经过时间，VM 可以了解同一服务器上其他 VM 正在执行的操作。 在学术媒体中，这些攻击得到了很多关注，研究人员一直在寻求了解有关对等 VM 中发生了什么情况的更具体的信息。

特别感兴趣的是，通过测量特定内存访问的时间并推断受害者 VM 正在读取和更新哪些缓存行来了解 对等 VM 的加密密钥 。 在使用超线程的 VM 的受控条件下，已针对加密算法的商业可用实现演示了成功的攻击。 除了前面提到的 Hyper-V Azure 正在使用的 HyperClear 缓解体系结构之外，Azure 中还有一些额外的缓解措施可以降低此类攻击的风险：

• 标准 Azure 加密库旨在通过不具有缓存访问模式来抵制此类攻击，具体取决于所使用的加密密钥。
• Azure 使用一种高级 VM 主机放置算法，该算法非常复杂且几乎不可能预测，这有助于减少将攻击者控制的 VM 放置在与目标 VM 相同的主机上的可能性。
• 所有 Azure 服务器至少有 8 个物理核心，有些服务器还有更多。 增加共享负载的 VM 核心数会给本已微弱的信号添加干扰。
• 可以使用 Azure 专用主机 或 独立 VM 在专用于单个客户的硬件上预配 VM，如 物理隔离 部分所述。 但是，鉴于 Azure 提供的强逻辑隔离保证，物理租户隔离会增加部署成本，在大多数情况下可能不需要。

总的来说，PaaS 或任何自动创建 VM 的工作负荷都会导致 VM 放置中的变动，从而导致随机 VM 分配。 VM 的随机放置使得攻击者更难访问同一主机。 此外，通过显著减少攻击面来强化主机访问，使得这些类型的攻击难以实施。

概要

多租户云平台意味着多个客户应用程序和数据存储在同一物理硬件上。 Azure 使用逻辑隔离将应用程序和数据与其他客户隔离开来。 这种方法提供了多租户云服务的规模和经济优势，同时严格帮助防止其他客户访问您的数据或应用程序。

Azure 通过提供值得信赖的基础来确保使用一组通用原则确保多租户、加密确定、逻辑隔离的云服务，从而解决了资源共享的感知风险：

• 使用Microsoft Entra ID 和 Azure 基于角色的访问控制（Azure RBAC）进行身份验证和标识分离的用户访问控制。
• 用于处理的计算隔离，包括逻辑和物理计算隔离。
• 网络隔离，包括网络流量的隔离和传输中数据的加密。
• 存储隔离通过静态数据加密实现，采用具有多种密码算法和加密密钥的高级算法，并支持在 Azure Key Vault 中由你控制的客户管理密钥 (CMK)。
• 嵌入在服务设计中的安全保障流程，以正确开发逻辑隔离的服务，包括安全开发生命周期（SDL）和其他强大的安全保障流程，以保护攻击面并降低风险。

根据云计算中的共享责任模型，本文提供了有关属于你责任的活动的指导。 它还探讨了 Azure 中可用的设计原则和技术，以帮助实现安全隔离目标。

后续步骤

了解有关以下方面的详细信息：

• Azure 安全基础知识文档
• Azure 基础结构安全性
• Azure 平台完整性和安全性
• Azure 政府版概述
• Azure 政府安全性
• Azure 政府合规性
• Azure 和其他 Microsoft 服务合规性产品