你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

有关构建分段策略的建议

适用于 Well-Architected Framework 安全清单建议:

SE:04 在体系结构设计以及工作负载在平台上的占用空间中创建有意的分段和外围。 分段策略必须包括网络、角色和职责、工作负载标识和资源组织。

段是解决方案的逻辑部分,需要作为一个单元进行保护。 分段策略定义应如何使用自己的一组安全要求和措施将一个单元与其他单元分开。

本指南介绍有关 构建统一分段策略的建议。 在工作负载中使用外围和隔离边界,可以设计适合你的安全方法。

定义 

术语 定义
Containment 一种技术,用于在攻击者获得对段的访问权限时包含爆炸半径。
最小特权访问 一个零信任原则,旨在最大程度地减少一组完成工作职能的权限。
外围 段周围的信任边界。
资源组织 按段内的流对相关资源进行分组的策略。
角色 完成作业功能所需的一组权限。
Segment 与其他实体隔离并受一组安全措施保护的逻辑单元。

关键设计策略

分段的概念通常用于网络。 但是,可以在整个解决方案中使用相同的基本原则,包括出于管理目的和访问控制对资源进行分段。

分段有助于设计一种安全方法,该方法根据零信任模型的原则深度应用防御。 通过使用不同的标识控制对工作负载进行分段,确保入侵一个网段的攻击者无法访问另一个网段。 在安全系统中,标识和网络属性会阻止未经授权的访问,并隐藏资产不被公开。 下面是段的一些示例:

  • 隔离组织的工作负载的订阅
  • 隔离工作负荷资产的资源组
  • 按阶段隔离部署的部署环境
  • 隔离与工作负载开发和管理相关的工作职能的团队和角色
  • 按工作负载实用工具隔离的应用程序层
  • 将一个服务与另一个服务隔离的微服务

请考虑分段的以下关键要素,以确保构建全面的深层防御策略:

  • 边界或外围是应用安全控制的段的入口边缘。 除非明确允许,否则外围控制应阻止对段的访问。 目标是防止攻击者突破外围并获取系统的控制权。 例如,应用程序层在处理请求时可能会接受最终用户的访问令牌。 但 数据 层可能需要具有特定权限的不同访问令牌,只有应用程序层可以请求该令牌。

  • 包含 是段的退出边缘,可防止系统中的横向移动。 遏制的目标是最大程度地减少违规的影响。 例如,Azure 虚拟网络可用于将路由和网络安全组配置为仅允许预期的流量模式,从而避免流量流向任意网段。

  • 隔离 是将具有类似保证的实体分组在一起以使用边界保护它们的做法。 目标是易于管理,并在环境中遏制攻击。 例如,可以将与特定工作负荷相关的资源分组到一个 Azure 订阅中,然后应用访问控制,以便只有特定工作负荷团队可以访问该订阅。

请务必注意外围和隔离之间的区别。 外围是指应检查的位置点。 隔离与分组有关。 通过结合使用这些概念来主动遏制攻击。

隔离并不意味着在组织中创建孤岛。 统一的分段策略在技术团队之间提供一致性,并设定明确的责任线。 Clarity可降低人为错误和/或导致安全漏洞和/或操作停机的自动化故障的风险。 假设在复杂企业系统的组件中检测到安全漏洞。 每个人都必须了解谁负责该资源,以便将相应的人员纳入会审团队。 组织和利益干系人可以通过创建和记录良好的分段策略,快速确定如何响应不同类型的事件。

权衡:分段会带来复杂性,因为管理存在开销。 成本也有权衡。 例如,当并行运行的部署环境分段时,会预配更多资源。

风险:超出合理限制的微分段将失去隔离的好处。 创建太多段时,很难识别通信点或允许段内的有效通信路径。

标识用作外围

各种标识(如人员、软件组件或设备)访问工作负载段。 标识是一个外围,应该成为 跨隔离边界进行身份验证和授权访问的主要防线,无论访问请求来自何处。 使用标识作为外围,可以:

  • 按角色分配访问权限。 标识只需要访问完成其工作所需的段。 通过了解请求标识的角色和职责来最大程度地减少匿名访问,以便了解请求访问段的实体及其用途。

    标识在不同的段中可能具有不同的访问范围。 请考虑一个典型的环境设置,每个阶段都有单独的段。 与开发人员角色关联的标识对开发环境具有读写访问权限。 随着部署移动到过渡阶段,这些权限将受到限制。 将工作负载提升到生产环境时,开发人员的范围将缩小到只读访问。

  • 单独考虑应用程序和管理标识。 在大多数解决方案中,用户的访问权限级别与开发人员或操作员不同。 在某些应用程序中,可能会对每种类型的标识使用不同的标识系统或目录。 请考虑使用访问范围并为每个标识创建单独的角色。

  • 分配最小特权访问权限。 如果允许标识访问,请确定访问级别。 从每个段的最低特权开始,仅在需要时才扩大该范围。

    通过应用最小特权,可以限制标识遭到入侵时产生的负面影响。 如果访问受时间限制,则攻击面会进一步减少。 限时访问特别适用于关键帐户,例如标识已泄露的管理员或软件组件。

权衡:工作负载的性能可能会受到标识外围的影响。 显式验证每个请求需要额外的计算周期和额外的网络 IO。

基于角色的访问控制 (RBAC) 也会导致管理开销。 在角色分配中,跟踪标识及其访问范围可能会变得复杂。 解决方法是将角色分配给安全组,而不是单个标识。

风险:标识设置可能比较复杂。 配置错误可能会影响工作负载的可靠性。 例如,假设有一个配置错误的角色分配,拒绝访问数据库。 请求开始失败,最终导致在运行时之前无法检测到的可靠性问题。

有关标识控制的信息,请参阅 标识和访问管理

与网络访问控制相比,标识在访问时验证访问控制。 强烈建议定期进行访问评审,并要求审批工作流获取关键影响帐户的权限。 例如,请参阅 标识分段模式

网络作为外围

标识外围与网络无关,而网络外围会增强标识,但永远不会替换它。 建立网络外围以控制爆炸半径、阻止意外、禁止和不安全的访问,以及模糊处理工作负载资源。

虽然标识外围的主要重点是最低特权,但你应该假设在设计网络外围时会出现漏洞。

使用 Azure 服务和功能在网络占用空间中创建软件定义的外围。 当工作负荷 (或给定工作负荷) 的一部分放置在单独的段中时,可以 控制来自或流向这些段的流量,以保护通信路径。 如果某个段遭到入侵,则会包含该段,并阻止其横向传播到网络的其余部分。

像攻击者一样思考,以在工作负载中立足,并建立控制措施,以尽量减少进一步的扩展。 这些控件应检测、包含和阻止攻击者获取对整个工作负载的访问权限。 下面是将网络控件作为外围的一些示例:

  • 定义公用网络与工作负载放置网络之间的边缘外围。 尽可能限制从公共网络的视线到你的网络。
  • (外围网络) 应用程序前实施非军事区域,并通过防火墙进行适当的控制。
  • 通过将工作负载的各个部分分组到单独的段,在专用网络中创建微分段。 在它们之间建立安全通信路径。
  • 基于意向创建边界。 例如,将工作负载功能网络与操作网络分段。

有关与网络分段相关的常见模式,请参阅 网络分段模式

权衡:网络安全控制通常成本高昂,因为它们包含在高级 SKU 中。 在防火墙上配置规则通常会导致巨大的复杂性,需要广泛的例外。

专用连接会更改体系结构设计,通常会添加更多组件,例如用于对计算节点进行专用访问的跳转盒。

由于网络外围基于控制点或跃点,因此在网络上,每个跃点都可能是一个潜在的故障点。 这些点可能会影响系统的可靠性。

风险:网络控制是基于规则的,并且配置错误的可能性很大,这是一个可靠性问题。

有关网络控制的信息,请参阅 网络和连接

角色和职责

通过明确定义工作负载团队中 的责任线 来实现防止混淆和安全风险的分段。

记录并共享角色和函数,以创建一致性和促进通信。 指定负责关键功能的组或单个角色。 在为对象创建自定义角色之前,请考虑 Azure 中的内置角色。

在为细分分配权限时,考虑一致性,同时适应多个组织模型。 这些模型的范围可以是单个集中式 IT 组,以及大部分无关的 DevOps 团队。

风险:随着员工加入、离开团队或更改角色,组成员身份可能会随着时间而变化。 跨段管理角色可能会导致管理开销。

资源组织

分段使你可以 将工作负载资源与组织的其他部分 甚至团队内部隔离开来。 Azure 构造(例如管理组、订阅、环境和资源组)是组织资源以提升分段的方式。 下面是资源级隔离的一些示例:

  • 多语言持久性涉及数据存储技术的组合,而不是单一数据库系统来支持分段。 使用多语言持久性按各种数据模型进行分离,分离数据存储和分析等功能,或按访问模式进行分离。
  • 组织计算时,为每个服务器分配一个服务。 这种隔离级别可最大程度地降低复杂性,并有助于遏制攻击。
  • Azure 为某些服务提供内置隔离,例如将计算与存储分离。 有关其他示例,请参阅 Azure 公有云中的隔离

权衡:资源隔离可能会导致总拥有成本增加, (TCO) 。 对于数据存储,灾难恢复期间可能会增加复杂性和协调性。

Azure 简化

某些 Azure 服务可用于实现分段策略,如以下部分所述。

标识

Azure RBAC 通过按作业功能隔离访问支持分段。 仅允许对某些角色和范围执行某些操作。 例如,只需观察系统的作业函数可以分配读取者权限,而不是参与者权限(允许标识管理资源)。

有关详细信息,请参阅 RBAC 的最佳做法

网络

显示分段的网络选项的关系图。

虚拟网络:虚拟网络提供网络级别的资源遏制,而无需在两个虚拟网络之间添加流量。 虚拟网络是在订阅中的专用地址空间中创建的

网络安全组 (NSG) :一种访问控制机制,用于控制虚拟网络中的资源与外部网络(如 Internet)之间的流量。 (UDR) 实现用户定义的路由,以控制流量的下一跃点。 NSG 可以通过为子网、虚拟机 (VM) 或一组 VM 创建外围,将分段策略提升到粒度级别。 有关 Azure 中子网的可能操作的信息,请参阅 子网

应用程序安全组 (ASG) :ASG 允许将一组 VM 分组到应用程序标记下,并定义流量规则,然后应用于每个基础 VM。

Azure 防火墙:云原生服务,可在虚拟网络或 Azure 虚拟 WAN中心部署中部署。 使用 Azure 防火墙 筛选在云资源、Internet 和本地资源之间流动的流量。 使用 Azure 防火墙 或 Azure 防火墙 Manager 创建使用第 3 层到第 7 层控件允许或拒绝流量的规则或策略。 通过第三方安全提供商将流量定向到Azure 防火墙和第三方来筛选 Internet 流量,以便进行高级筛选和用户保护。 Azure 支持网络虚拟设备部署,这有助于从第三方防火墙进行分段。

示例

下面是在 Azure 中对工作负荷进行分段的一些常见模式。 根据需要选择模式。

此示例基于在 安全基线 (SE:01 ) 中建立的信息技术 (IT) 环境。 下图显示了组织在管理组级别进行的分段。

显示组织针对各种工作负载的分段策略示例的示意图。

标识分段模式

模式 1:基于职务的分组

组织安全组的一种方法是按职称(如软件工程师、数据库管理员、站点可靠性工程师、质量保证工程师或安全分析师)。 此方法涉及基于 工作负荷团队的角色为其创建安全组 ,而不考虑需要完成的工作。 根据安全组在工作负载中的职责, (JIT) 向安全组授予 RBAC 权限,使其保持状态或恰时。 根据安全组所需的访问权限,将人工和服务原则分配给安全组。

成员身份在角色分配级别高度可见,因此可以轻松查看 角色 有权访问的内容。 每个人通常只有一个安全组的成员,这使得加入和卸载变得容易。 但是,除非职务与职责完全重叠,否则基于职务的分组并不是最低特权实现的理想选择。 最终,你可能会将实现与基于函数的分组相结合。

模式 2:基于函数的分组

基于函数的分组是一种安全组组织方法,它反映需要完成的离散工作,而不考虑你的团队结构。 使用此模式时,可以根据安全组在工作负载中所需的功能,根据需要 授予安全组 RBAC 权限(身份或 JIT)。

根据安全组所需的访问权限,将人工和服务原则分配给安全组。 尽可能使用现有的同质组作为基于函数的组的成员,例如模式 1 中的那些组。 基于函数的组的示例包括:

  • 生产数据库运算符
  • 预生产数据库运算符
  • 生产证书轮换运算符
  • 预生产证书轮换运算符
  • 生产实时站点/会审
  • 预生产所有访问权限

此方法维护最严格的最低特权访问,并在范围明显的情况下提供安全组,这使得与所执行的工作职责相关的成员资格审核变得容易。 通常存在一个内置 Azure 角色来匹配此作业功能。

但是,成员身份至少抽象化了一个层,迫使你在从资源角度查看时转到标识提供者以了解组中的人员。 此外,一个人需要维护多个成员身份才能完全覆盖。 重叠安全组的矩阵可能比较复杂。

建议使用模式 2,使访问模式成为焦点,而不是组织结构图。 组织结构图和成员角色有时会更改。 从功能角度捕获工作负载的标识和访问管理,使你能够将团队组织从工作负载的安全管理中抽象化。

网络分段模式

模式 1:工作负载内分段 (软边界)

显示单个虚拟网络的示意图。

在此模式中,工作负载放置在单个虚拟网络中,使用子网来标记边界。 使用两个子网实现分段,一个子网用于数据库,一个用于 Web 工作负载。 必须将 NSG 配置为允许子网 1 仅与子网 2 通信,子网 2 仅与 Internet 通信。 此模式提供第 3 层控制。

模式 2:工作负载中的分段

显示多个虚拟网络的示意图。

此模式是平台级分段的示例。 工作负载跨多个网络分布,无需在它们之间建立对等互连。 所有通信都通过充当公共接入点的中介进行路由。 工作负荷团队拥有所有网络。

模式 2 提供包含,但增加了虚拟网络管理和大小调整的复杂性。 两个网络之间的通信通过公共 Internet 进行,这可能会带来风险。 公共连接也存在延迟。 但是,这两个网络可以对等互连,通过连接它们来创建更大的网段来中断分段。 无需其他公共终结点时,应进行对等互连。

注意事项 模式 1 模式 2
连接和路由:每个段的通信方式 系统路由提供与工作负载组件的默认连接。 任何外部组件都无法与工作负载通信。 在虚拟网络中,与模式 1 相同。
在网络之间,流量通过公共 Internet。 网络之间没有直接连接。
网络级别流量筛选 默认情况下允许段之间的流量。 使用 NSG 或 ASG 筛选流量。 在虚拟网络中,与模式 1 相同。
在网络之间,可以通过防火墙筛选入口和出口流量。
意外的开放公共终结点 网络接口卡 (NIC) 不获取公共 IP。 虚拟网络不会向 Internet API 管理公开。 与模式 1 相同。 一个虚拟网络上的预期开放公共终结点,该终结点可能配置错误,以接受更多流量。

资源组织

根据所有权责任组织 Azure 资源

包含多个工作负载的 Azure 资产示意图。

考虑一个 Azure 资产,其中包含多个工作负载和共享服务组件,例如中心虚拟网络、防火墙、标识服务和安全服务(如 Microsoft Sentinel)。 应根据其功能区域、工作负载和所有权对整个资产中的组件进行分组。 例如,共享网络资源应分组到单个订阅中,并由网络团队管理。 专用于单个工作负载的组件应位于其自己的细分市场中,并可能根据应用层或其他组织原则进一步划分。

通过创建 RBAC 角色分配授予管理单个段内资源的访问权限。 例如,可能会向云网络团队授予对包含其资源的订阅的管理访问权限,但无权访问单个工作负荷订阅。

良好的分段策略可以轻松识别每个细分的所有者。 请考虑使用 Azure 资源标记对所有者团队的资源组或订阅进行批注。

配置和查看访问控制

通过为资源明确定义段,根据需要授予适当的访问权限。

定义访问控制策略时,请考虑最小特权原则。 必须区分 控制平面操作 (管理资源本身) 和数据平面操作 (访问资源) 存储的数据。 例如,假设你有一个工作负载,其中包含一个数据库,其中包含有关员工的敏感信息。 可以向某些需要配置设置(如数据库备份)的用户或监视数据库服务器性能的用户授予管理访问权限。 但是,这些用户不应能够查询数据库中存储的敏感数据。 选择授予用户执行其职责所需的最小范围的权限。 定期查看每个段的角色分配,并删除不再需要的访问权限。

注意

某些高特权角色(例如 RBAC 中的所有者角色)使用户能够向其他用户授予对资源的访问权限。 限制分配了所有者角色的用户或组数,并定期查看审核日志,以确保他们仅执行有效的操作。

安全清单

请参阅完整的一组建议。