分层安全政策是一种安全政策类别，可将 Cloud Armor Web 应用防火墙 (WAF) 和 DDoS 防护的范围扩展到单个项目之外。它们在组织、文件夹或项目级进行附加。这些政策与直接附加到后端服务或后端存储桶的服务级安全政策不同。
在组织级或文件夹级配置分层安全政策时，层次结构中较低级别的项目会继承该安全政策。通过这种继承，您可以设置要应用于组织内所有项目或多个项目的安全政策规则。这使您可以在整个 Trusted Cloud by S3NS 环境中集中且一致地强制执行安全措施。
本页面介绍了分层安全政策与服务级安全政策的区别。在继续之前，请先阅读安全政策概览，确保您了解安全政策的运作方式。此外，我们还建议您熟悉资源层次结构。
使用场景
在大型组织中，跨众多项目管理安全政策可能既复杂又耗时。分层安全政策具有以下优势，可帮助您应对这些挑战：
- 集中式控制：使组织级和文件夹级管理员能够跨多个项目定义和强制执行安全政策。
- 一致性：在整个组织内提供统一的安全状况，降低出现配置错误和安全漏洞的风险。
- 效率：同时在大量资源中简化安全更新和缓解措施（例如屏蔽特定 IP 地址范围或解决严重漏洞）的部署。
- 委托：通过在层次结构的适当层级应用政策，可以将安全职责委托给不同的团队或部门。
您可以应用并结合使用这些一般原则，以满足组织的需要。请参考以下使用应用场景示例：
- 组织范围 IP 地址屏蔽：您可以在组织中的所有项目内屏蔽来自已知恶意 IP 地址范围的流量。
- 基于地理位置的限制：您可以在组织级或文件夹级限制来自特定地理区域的流量。
- CVE 缓解：您可以跨多个项目快速部署 WAF 规则以缓解严重漏洞。
- 合规性强制执行：您可以在整个组织中应用一致的安全政策，以强制遵守法规要求。
- 精细访问权限控制：您可以向特定 IP 地址范围或地理区域授予对特定文件夹中所有资源的访问权限。
功能
分层安全政策支持服务级安全政策所支持的部分功能。下表比较了可以与分层安全政策和服务级安全政策搭配使用的 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。如需详细了解分层安全政策的运作方式，请参阅以下列表：
- 当分层安全政策与某个资源层次结构节点相关联时，层次结构中低于该节点的所有受保护资源都会继承相应政策。
- 您可以查看项目中应用于每个受保护资源的安全政策，包括所有分层安全政策和服务级安全政策。如需了解详情，请参阅查看适用于受保护资源的所有有效 Cloud Armor 规则。
- 您可以将分层安全政策从一个资源层次结构节点移动到另一个节点。如果您打算重新整理文件夹结构，可以执行此操作。
- 删除某个资源层次结构节点（例如文件夹或项目）时，只会删除在该资源层次结构节点下创建的附加到该节点的分层安全政策。
- 如果您是在其他位置创建了安全政策，然后将其移到该节点下，则不会删除相应政策。
- 为避免意外删除分层安全政策，我们建议您在删除现有节点之前，将打算保留的所有分层安全政策移至其他资源层次结构节点。
规则评估顺序
Cloud Armor 按以下顺序评估安全政策：
- 组织级分层安全政策
- 文件夹级分层安全政策（从父文件夹开始，然后依次处理每个子文件夹）
- 项目级分层安全政策
- 服务级安全政策
这种规则评估顺序意味着，您可能有一个低优先级的分层安全政策，该政策会在高优先级的服务级安全政策之前进行评估。请仔细考虑您现有的高优先级服务级安全政策规则，并考虑如果 Cloud Armor 未根据这些规则评估被某个分层安全策略允许或拒绝的请求，会发生什么情况。
goto_next 操作
Cloud Armor 有一个专用于分层安全政策的规则操作：goto_next 操作。当 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，请参阅 Cloud Armor Standard 与 Cloud Armor Enterprise。
- 如果您在某个项目自动在 Cloud Armor Enterprise 中注册之后更新分层安全政策以排除该项目，则该项目不会自动取消注册。如需手动取消注册项目，请参阅从 Cloud Armor Enterprise 中移除项目。
- 如果项目具有任何继承的分层安全政策，您无法从 Cloud Armor Enterprise 中移除项目。
自动注册最多可能需要一周时间才能完成。在此期间，您的分层安全政策有效，并且不会产生 Cloud Armor Enterprise 费用。项目注册后，审核日志会更新以反映项目的 Cloud Armor Enterprise 状态，并且您会在 Trusted Cloud 控制台中看到新的项目层级。
限制
分层安全政策具有以下限制：
- 分层安全政策不适用于不属于组织的项目。
- 对于新项目或最近恢复的项目，项目上继承的任何安全政策可能需要几个小时来进行传播。
- 对于最近启用了 Compute Engine API 的项目，此项目上继承的任何安全政策可能需要几个小时来进行传播。
- 您可以调整自己拥有的分层安全政策中的预配置 WAF 规则，但继承分层安全政策的服务的所有者无法执行规则调整。