分层安全政策是一种安全政策，可将 Google Cloud Armor Web 应用防火墙 (WAF) 和 DDoS 攻击防护的范围扩展到单个项目之外。它们附加在组织、文件夹或项目级层。这些政策与直接附加到后端服务或后端存储分区的服务级安全政策不同。
在组织级或文件夹级配置分层安全政策时，层次结构中较低级别的项目会继承该安全政策。通过这种继承，您可以设置要应用于组织内所有项目或多个项目的安全政策规则。这样一来，您就可以在整个 Google Cloud 环境中集中且一致地强制执行安全措施。
本页面介绍了分层安全政策与服务级安全政策的区别。在继续操作之前，请先阅读安全政策概览，确保您了解安全政策的运作方式。此外，我们还建议您熟悉资源层次结构。
使用场景
在大型组织中，跨众多项目管理安全政策可能既复杂又耗时。分层安全政策具有以下优势，可帮助您应对这些挑战：
- 集中控制：使组织级和文件夹级管理员能够跨多个项目定义和强制执行安全政策。
- 一致性：在整个组织内提供统一的安全状况，从而降低配置错误和安全漏洞的风险。
- 效率：同时在大量资源中简化安全更新和缓解措施（例如阻止特定 IP 地址范围或解决严重漏洞）的部署。
- 委托：通过在层次结构的适当层级应用政策，将安全职责委托给不同的团队或部门。
您可以应用并结合使用这些一般原则，以满足组织的需要。请参考以下使用场景示例：
- 组织范围内的 IP 地址屏蔽：您可以屏蔽组织中所有项目内来自已知恶意 IP 地址范围的流量。
- 基于地理位置的限制：您可以在组织级层或文件夹级层限制来自特定地理区域的流量。
- CVE 缓解：您可以快速部署 WAF 规则，以缓解多个项目中的严重漏洞。
- 强制执行合规性：您可以在整个组织中应用一致的安全政策，以强制执行法规要求。
- 精细的访问权限控制：您可以向特定 IP 地址范围或地理区域授予对特定文件夹中所有资源的访问权限。
特性
分层安全政策支持服务级安全政策支持的部分功能。下表比较了可与分层安全政策和服务级安全政策搭配使用的 Google Cloud Armor 功能：
| 前端类型 |
|
|
| 连接点（受保护的资源） | 后端服务 | 资源层次结构节点 |
| 规则操作 |
|
|
| 来源 IP 地址 | ||
| 来源地理位置 | ||
| 来源 ASN | ||
| 聊天机器人管理 | （仅限 EXTERNAL_302 和请求装饰） |
|
| 第 7 层过滤 | ||
| WAF | ||
| Google 威胁情报 | ||
| reCAPTCHA | ||
| Adaptive Protection | ||
| 地址组 | ||
| 组织级地址组 | ||
| Security Command Center | ||
| Cloud Monitoring | ||
| 请求日志记录 |
分层安全政策的工作原理
创建分层安全政策时，您需要在组织级或文件夹级创建该政策，并且相应资源拥有该分层安全政策的所有权。创建分层安全政策后，您的安全政策规则不会应用于任何资源。
接下来，将分层安全政策与组织、文件夹或项目（可以是政策的所有者资源）相关联。将分层安全政策与资源相关联后，系统会将安全政策规则应用于资源层次结构中相应节点及其下方的受保护资源。为帮助您确定要将分层安全政策附加到哪个资源，请参阅以下列表，其中列出了每个资源的基本使用情形：
- 组织：将组织级分层安全政策视为默认类型的分层安全政策。这些政策具有广泛的 Identity and Access Management (IAM) 权限，并且适用于组织下的所有节点。在关联期间使用
--organization标志指定这些资源。 - 文件夹：如果您想在多个项目（而非整个组织）中应用相同的安全政策规则，请使用这些分层安全政策。在关联期间使用
--folder标志指定这些资源。 - 项目：如果您需要跨项目中的所有资源应用相同的安全政策规则，请使用这种分层安全政策，例如跨多个后端服务应用 IP 地址拒绝名单。在关联期间使用
--project标志指定这些资源。 - 服务级：如果您需要为每项服务制定不同的独特安全政策规则，请使用服务级安全政策。每个服务级安全政策仅将其规则应用于其所附加的后端政策。使用
--project-number标志指定这些资源。
每个分层安全政策只能使用其中一个标志。您可以像配置服务级安全政策时一样，指定其余标志，例如 --name 或 --type。如需详细了解分层安全政策的工作原理，请参阅以下列表：
- 当分层安全政策与资源层次结构节点相关联时，层次结构中低于该节点的所有受保护资源都会继承该政策。
- 您可以查看项目中适用于每个受保护资源的安全政策，包括所有分层安全政策和服务级安全政策。如需了解详情，请参阅查看受保护资源的所有有效 Google Cloud Armor 规则。
- 您可以将分层安全政策从一个资源层次结构节点移动到另一个节点。如果您打算重新整理文件夹结构，可以执行此操作。
- 删除资源层次结构节点（例如文件夹或项目）时，只有当您在该资源层次结构节点下创建了附加到该节点的分层安全政策时，该政策才会被删除。
- 如果您在其他位置创建了安全政策，然后将其移到节点下，则该政策不会被删除。
- 为避免意外删除层次安全政策，我们建议您在删除现有节点之前，将打算保留的所有层次安全政策移至其他资源层次结构节点。
规则评估顺序
Google Cloud Armor 按以下顺序评估安全政策：
- 组织级分层安全政策
- 文件夹级分层安全政策（从父文件夹开始，然后依次处理每个子文件夹）
- 项目级分层安全政策
- 服务级安全政策
这种规则评估顺序意味着，您可能有一个低优先级的分层安全政策，该政策会在高优先级的服务级安全政策之前进行评估。请仔细考虑您现有的高优先级服务级安全政策规则，并考虑如果 Google Cloud Armor 不根据层次安全政策评估允许或拒绝的请求，会发生什么情况。
goto_next 操作
Google Cloud Armor 有一项规则操作专用于分层安全政策：goto_next 操作。当 Google Cloud Armor 应用此操作时，它会停止评估当前安全政策中的规则，并开始评估下一个安全政策中的规则。
不妨考虑一个示例，假设您在组织级层拥有一个分层安全政策，其中包含许多规则，您希望使用这些规则来限制整个组织中的请求。您希望允许来自特定 IP 地址范围的请求跳过对这些组织级规则的评估。因此，您需要创建一个最高优先级的规则，该规则与该 IP 地址范围匹配，并具有 goto_next 操作。来自该 IP 地址范围的请求会先根据此规则进行评估，并且由于它们满足匹配条件，因此不会根据此组织级分层安全政策中的任何其他规则进行评估。
在同一示例中，如果您使用 allow 或 deny 操作而不是 goto_next 操作，则在满足匹配条件后，系统会立即允许或拒绝相应请求。这种分层评估意味着，系统不会针对该请求评估任何其他安全政策。
Google Cloud Armor Enterprise 注册和结算行为
附加分层安全政策时，继承该分层安全政策的每个项目都必须注册到 Cloud Armor Enterprise。这包括组织或文件夹中具有分层安全政策的所有项目（明确排除的项目除外），以及直接附加了分层安全政策的所有项目。
- 如果项目关联的 Cloud Billing 账号订阅了 Cloud Armor Enterprise Annual，则这些项目会自动注册到 Cloud Armor Enterprise Annual（如果尚未注册）。
- 如果没有 Cloud Armor Enterprise Annual 订阅，项目在继承分层安全政策时会自动注册到 Cloud Armor Enterprise Paygo。如果您在项目自动注册到 Cloud Armor Enterprise Paygo 后让结算账号订阅 Cloud Armor Enterprise Annual，则项目不会自动注册到 Annual。如需详细了解 Cloud Armor Enterprise Paygo，请参阅 Google Cloud Armor Standard 与 Cloud Armor Enterprise。
- 如果您在项目自动注册到 Cloud Armor Enterprise 后更新分层安全政策以排除该项目，则该项目不会自动取消注册。如需手动取消注册项目，请参阅从 Cloud Armor Enterprise 中移除项目。
- 如果项目具有任何继承的层次结构安全政策，您就无法从 Cloud Armor Enterprise 中移除该项目。
限制
分层安全政策具有以下限制：
- 分层安全政策不适用于不属于组织的项目。
- 对于新项目或最近恢复的项目，项目上继承的任何安全政策可能需要几个小时才能传播。
- 对于最近启用了 Compute Engine API 的项目，此项目上继承的任何安全政策可能需要几个小时才能传播。
- 您可以调整自己拥有的分层安全政策中的预配置 WAF 规则，但继承分层安全政策的服务的所有者无法执行规则调整。