你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
有关构建分段策略的建议
适用于架构良好的框架安全清单建议：
| SE：04 | 在体系结构设计和平台上的工作负荷占用空间中创建有意的分段和外围。 分段策略必须包括网络、角色和职责、工作负荷标识和资源组织。 |
|---|
段是解决方案的逻辑部分，需要作为一个单元进行保护。 分段策略定义应如何将一个单元与其他单元分离，以及其自己的一组安全要求和措施。
本指南介绍了有关 构建统一分段策略的建议。 在工作负荷中使用外围和隔离边界，可以设计适合你的安全方法。
定义
| 术语 | 定义 |
|---|---|
| 遏制 | 如果攻击者获得对段的访问权限，则包含爆炸半径的技术。 |
| 最低特权访问 | 一个零信任原则，旨在最大程度地减少一组完成作业功能的权限。 |
| 外围 | 段周围的信任边界。 |
| 资源组织 | 按段内的流对相关资源进行分组的策略。 |
| 角色 | 完成作业函数所需的一组权限。 |
| Segment | 与其他实体隔离并受一组安全措施保护的逻辑单元。 |
关键设计策略
分段的概念通常用于网络。 但是，可以在解决方案中使用相同的基本原则，包括将资源分段用于管理目的和访问控制。
分段有助于设计基于零信任模型原则深入应用防御的安全方法。 确保违反一个网段的攻击者无法通过使用不同的标识控制对工作负荷进行分段来访问另一个网段。 在安全系统中，标识和网络属性会阻止未经授权的访问，并隐藏要公开的资产。 下面是段的一些示例：
- 隔离组织的工作负荷的订阅
- 隔离工作负荷资产的资源组
- 按阶段隔离部署的部署环境
- 隔离与工作负荷开发和管理相关的作业功能的团队和角色
- 按工作负荷实用工具隔离的应用程序层
- 将一个服务与另一个服务隔离的微服务
请考虑分段的以下关键要素，以确保要构建全面的深度防御策略：
边界 或外围 是应用安全控件的段的入口边缘。 除非显式允许，否则外围控件应阻止对段的访问。 目标是防止攻击者突破外围并控制系统。 例如，应用程序层在处理请求时可能会接受最终用户的访问令牌。 但是， 数据 层可能需要具有特定权限的不同访问令牌，只有应用程序层才能请求该令牌。
包含 是阻止系统中横向移动的段的退出边缘。 遏制的目标是最大程度地减少违规的影响。 例如，Azure 虚拟网络可用于配置路由和网络安全组，以仅允许预期的流量模式，避免流量流向任意网段。
隔离 是将具有类似保证的实体组合在一起，以使用边界保护实体的做法。 目标是在环境中轻松管理和遏制攻击。 例如，可以将与特定工作负荷相关的资源分组到一个 Azure 订阅中，然后应用访问控制，以便只有特定的工作负荷团队可以访问订阅。
请务必注意外围与隔离之间的区别。 外围是指应检查的位置点。 隔离与分组有关。 通过结合使用这些概念主动包含攻击。
隔离并不意味着在组织中创建孤岛。 统一分段策略在技术团队之间提供一致，并设置明确的责任线。 清晰度可降低人为错误和自动化故障的风险，这可能导致安全漏洞、操作停机时间或两者兼有。 假设在复杂企业系统的组件中检测到安全漏洞。 重要的是，每个人都了解谁负责该资源，以便适当的人员包含在会审团队中。 组织和利益干系人可以通过创建和记录良好的分段策略来快速确定如何响应不同类型的事件。
权衡：分段引入了复杂性，因为管理存在开销。 成本也有利弊。 例如，在对并行运行的部署环境进行分段时，会预配更多资源。
风险：超出合理限制的微分段会失去隔离的好处。 创建过多段时，很难识别通信点或允许段内的有效通信路径。
将标识建立为主要安全外围
各种标识，例如人员、软件组件或设备访问工作负荷段。 标识是一个外围，应是主要防线，用于 跨隔离边界进行身份验证和授权访问，而不管访问请求源自何处。 将标识用作外围，以便：
按角色分配访问权限。 标识只需要访问执行其作业所需的段。 通过了解请求标识的角色和职责来最大程度地减少匿名访问，以便知道请求访问段的实体以及出于什么目的。
标识在不同段中可能具有不同的访问范围。 请考虑一个典型的环境设置，每个阶段都有单独的段。 与开发人员角色关联的标识对开发环境具有读写访问权限。 随着部署转移到暂存，这些权限将得到限制。 在将工作负荷提升到生产环境时，开发人员的范围将减少为只读访问权限。
单独考虑应用程序和管理标识。 在大多数解决方案中，用户的访问权限级别不同于开发人员或操作员。 在某些应用程序中，可能会对每种标识使用不同的标识系统或目录。 请考虑使用访问范围并为每个标识创建单独的角色。
分配最低特权访问权限。 如果允许标识访问，请确定访问级别。 从每个段的最低特权开始，并仅在需要时才扩大该范围。
通过应用最小特权，如果标识遭到入侵，则会限制负面影响。 如果访问受时间限制，则攻击面会进一步减少。 限时访问特别适用于关键帐户，例如具有已泄露标识的管理员或软件组件。
基于角色的访问控制（RBAC）也会导致管理开销。 跟踪标识及其访问范围可能会变得复杂的角色分配。 解决方法是将角色分配给安全组而不是单个标识。
有关标识控制的信息，请参阅 标识和访问管理。
与网络访问控制相比，标识在访问时验证访问控制。 强烈建议定期进行访问评审，并要求审批工作流获取对关键影响帐户的特权。 例如，请参阅 标识分段模式。
使用网络作为外围进行增强
标识外围与网络无关，而网络外围会增强标识，但永远不会替换它。 建立网络外围，用于控制爆炸半径、阻止意外、禁止和不安全的访问，以及模糊处理工作负荷资源。
虽然标识外围的主要焦点是最低特权，但设计网络外围时，应假定会出现漏洞。
使用 Azure 服务和功能在网络占用空间中创建软件定义的外围。 将工作负荷（或给定工作负荷的一部分）放入单独的段时，可以 控制来自或传往这些段的流量，以保护通信路径。 如果某个段遭到入侵，则会包含该段，并阻止其横向传播到网络的其余部分。
像攻击者一样在工作负荷中实现立足点，并建立控制措施，以最大程度地减少进一步扩展。 控件应检测、包含和阻止攻击者访问整个工作负荷。 下面是网络控件作为外围的一些示例：
- 定义公共网络与放置工作负荷的网络之间的边缘外围。 尽可能多地将视线从公共网络限制为网络。
- 在应用程序前面实现非军事区域（外围网络），并通过防火墙进行适当的控制。
- 通过将工作负荷的各个部分分组到单独的段，在专用网络中创建微分段。 在它们之间建立安全通信路径。
- 基于意向创建边界。 例如，将工作负荷功能网络从操作网络分段。
有关与网络分段相关的常见模式，请参阅 网络分段模式。
专用连接会改变体系结构设计，通常添加更多组件，例如用于专用访问计算节点的跳线框。
由于网络外围基于控制点或跃点，因此在网络上，每个跃点可以是潜在的故障点。 这些点可能会影响系统的可靠性。
有关网络控制的信息，请参阅 网络和连接。
定义角色并明确责任线
通过 明确定义工作负荷团队内的责任 线，可以实现防止混淆和安全风险的分段。
记录和共享角色和功能，以创建一致性并促进通信。 指定负责关键功能的组或单个角色。 在为对象创建自定义角色之前，请考虑 Azure 中的内置角色。
在为细分分配权限时考虑一致性，同时容纳多个组织模型。 这些模型的范围可以是单个集中式 IT 组，以及大部分无关的 DevOps 团队。
组织资源以提升分段
分段使你可以 将工作负荷资源与组织 的其他部分隔离，甚至可以在团队中隔离。 Azure 构造（例如管理组、订阅、环境和资源组）是组织促进分段的资源的方法。 下面是资源级隔离的一些示例：
- Polyglot 持久性涉及数据存储技术的组合，而不是单一数据库系统来支持分段。 使用 polyglot 持久性通过各种数据模型分离、数据存储和分析等功能分离，或按访问模式进行分隔。
- 组织计算时，为每个服务器分配一个服务。 这种隔离级别可最大程度地降低复杂性，并有助于遏制攻击。
- Azure 为某些服务提供内置隔离，例如将计算与存储分离。 有关其他示例，请参阅 Azure 公有云中的隔离。
Azure 便利化
某些 Azure 服务可用于实施分段策略，如以下部分所述。
标识
Azure RBAC 通过按作业函数隔离访问支持分段。 仅允许某些角色和作用域执行某些操作。 例如，仅需要观察系统的作业函数可以分配读取者权限与允许标识管理资源的参与者权限。
有关详细信息，请参阅 RBAC 的最佳做法。
网络
虚拟网络：虚拟网络提供资源的网络级包含，而无需在两个虚拟网络之间添加流量。 虚拟网络是在订阅中的专用地址空间中创建的
网络安全组（NSG）：用于控制虚拟网络和外部网络（如 Internet）中的资源之间的流量的访问控制机制。 实现用户定义的路由（UDR），控制流量的下一跃点。 NSG 可以通过为子网、虚拟机（VM）或一组 VM 创建外围，将分段策略提升到粒度级别。 有关 Azure 中子网的可能操作的信息，请参阅 “子网”。
应用程序安全组（ASG）：ASG 允许在应用程序标记下对一组 VM 进行分组，并定义随后应用于每个基础 VM 的流量规则。
Azure 防火墙：可在虚拟网络或 Azure 虚拟 WAN 中心部署中部署的云原生服务。 使用Azure 防火墙筛选云资源、Internet 和本地资源之间的流量。 使用Azure 防火墙或Azure 防火墙管理器创建允许或拒绝使用第 3 层到第 7 层控制流量的规则或策略。 通过使用Azure 防火墙和第三方筛选 Internet 流量，通过第三方安全提供程序定向流量，以便进行高级筛选和用户保护。 Azure 支持网络虚拟设备部署，这有助于从第三方防火墙进行分段。
示例
下面是在 Azure 中分段工作负荷的一些常见模式。 根据需求选择模式。
此示例基于安全基线（SE：01）中建立的 信息技术（IT）环境。 下图显示了组织在管理组级别进行的分段。
标识分段模式
模式 1：基于职务的分组
组织安全组的一种方法是职称，如软件工程师、数据库管理员、站点可靠性工程师、质量保证工程师或安全分析师。 此方法涉及 基于工作负荷团队的角色为工作负荷团队 创建安全组，而无需考虑需要完成的工作。 根据他们在工作负荷中的职责，授予安全组 RBAC 权限、保持或实时（JIT）。 根据安全组的所需访问权限将人工和服务原则分配给安全组。
成员身份在角色分配级别高度可见，因此可以轻松查看角色有权访问的内容。 每个人通常是一个安全组的成员，这使得载入和卸载变得容易。 但是，除非职务与职责完全重叠，否则基于职务的分组对于最低特权实现并不理想。 你最终可能会将实现与基于函数的分组组合在一起。
模式 2：基于函数的分组
基于函数的分组是一种安全组组织方法，反映需要完成的离散工作，而不考虑团队结构。 使用此模式，可以根据 工作负荷中所需的功能授予安全组 RBAC 权限、站立或 JIT 权限。
根据安全组的所需访问权限将人工和服务原则分配给安全组。 如果可能，请使用现有的同质组作为基于函数的组的成员，例如模式 1 中的这些组。 基于函数的组的示例包括：
- 生产数据库运算符
- 预生产数据库运算符
- 生产证书轮换运算符
- 预生产证书轮换运算符
- 生产实时站点/会审
- 预生产所有访问权限
此方法维护最严格的最低特权访问，并提供范围显而易见的安全组，这使得审核成员身份相对于执行的工作职责变得容易。 通常存在与此作业函数匹配的内置 Azure 角色。
但是，成员身份至少抽象化了一层，强制你转到标识提供者，了解从资源角度查看组中的人员。 此外，一个人需要保留多个成员身份才能完全覆盖。 重叠安全组的矩阵可能比较复杂。
建议使用模式 2 使访问模式成为焦点，而不是组织结构图。 组织结构图和成员角色有时会更改。 从功能角度捕获工作负荷的标识和访问管理，可以从工作负荷的安全管理中抽象化团队组织。
网络分段模式
模式 1：工作负荷内的分段（软边界）
在此模式中，工作负荷放置在使用子网标记边界的单个虚拟网络中。 分段是使用两个子网实现的，一个子网用于数据库，一个用于 Web 工作负荷。 必须配置允许子网 1 仅与子网 2 和子网 2 通信的 NSG，以仅与 Internet 通信。 此模式提供第 3 层级别控制。
模式 2：工作负荷中的分段
此模式是平台级分段的示例。 工作负荷 component 分布在多个网络中，而无需在它们之间进行对等互连。 所有通信都通过充当公共接入点的中介进行路由。 工作负荷团队拥有所有网络。
模式 2 提供包含，但增加了虚拟网络管理和大小调整的复杂性。 这两个网络之间的通信通过公共 Internet 进行，这可能会造成风险。 公共连接也有延迟。 但是，可以通过连接两个网络来创建更大的段来对等互连，从而中断分段。 不需要其他公共终结点时，应执行对等互连。
| 注意事项 | 模式 1 | 模式 2 |
|---|---|---|
| 连接和路由：每个段的通信方式 | 系统路由提供与工作负荷组件的默认连接。 任何外部组件都无法与工作负荷通信。 | 在虚拟网络中，与模式 1 相同。 在网络之间，流量通过公共 Internet 传输。 网络之间没有直接连接。 |
| 网络级别流量筛选 | 默认情况下允许段之间的流量。 使用 NSG 或 ASG 筛选流量。 | 在虚拟网络中，与模式 1 相同。 在网络之间，可以通过防火墙筛选入口和出口流量。 |
| 意外的开放公共终结点 | 网络接口卡（NIC）不会获得公共 IP。 虚拟网络不会向 Internet API 管理公开。 | 与模式 1 相同。 一个虚拟网络上预期的开放公共终结点，可能配置错误，以接受更多流量。 |
资源组织
根据所有权责任组织 Azure 资源
请考虑包含多个工作负载和共享服务组件的 Azure 资产，例如中心虚拟网络、防火墙、标识服务和安全服务，例如 Microsoft Sentinel。 整个资产中的组件应根据其功能区域、工作负载和所有权进行分组。 例如，共享网络资源应分组到单个订阅中，并由网络团队管理。 专用于单个工作负荷的组件应位于自己的细分中，并且可能会根据应用程序层或其他组织原则进一步划分。
通过创建 RBAC 角色分配授予管理各个段内资源的权限。 例如，云网络团队可能被授予对包含其资源的订阅的管理访问权限，但不能授予对单个工作负荷订阅的管理访问权限。
良好的分段策略使你能够轻松识别每个细分的所有者。 请考虑使用 Azure 资源标记向所有者团队批注资源组或订阅。
配置和查看访问控制
通过明确定义资源的段，根据需求授予适当的访问权限。
定义访问控制策略时，请考虑最低特权原则。 必须区分控制平面操作（管理资源本身）和数据平面操作（对资源存储的数据的访问）。 例如，假设你有一个工作负荷，其中包含包含有关员工的敏感信息的数据库。 你可以向某些需要配置设置（如数据库备份）或监视数据库服务器性能的用户授予管理访问权限。 但是，这些用户不应能够查询数据库中存储的敏感数据。 选择授予用户执行其职责所需的最低范围的权限。 定期查看每个段的角色分配，并删除不再需要的访问权限。
注意
某些高特权角色（如 RBAC 中的所有者角色）使用户能够向其他用户授予对资源的访问权限。 限制分配所有者角色的用户或组数，并定期查看审核日志，以确保他们仅执行有效的操作。
相关链接
安全清单
请参阅完整的建议集。