階層式安全性政策是一類安全性政策，可將 Google Cloud Armor 網頁應用程式防火牆 (WAF) 和 DDoS 防護的範圍擴展至個別專案之外。這些政策會附加在組織、資料夾或專案層級。這與服務層級安全性政策不同，後者會直接附加至後端服務或後端 bucket。
在組織或資料夾層級設定階層式安全性政策之後，較低層級的專案會繼承該項政策。透過這樣的繼承機制，您可以設定安全性政策規則，然後套用至組織內的部分或所有專案。這樣一來，您就能在 Google Cloud 環境中集中且一致地執行安全性措施。
本頁面說明階層式安全性政策與服務層級安全性政策的差異。繼續操作前，請先參閱安全性政策總覽，確保您瞭解安全性政策的運作方式。此外，建議您熟悉資源階層。
用途
在大型組織中，管理多項專案的安全政策可能相當複雜且耗時。階層式安全性政策提供下列優勢，可協助您因應這些挑戰：
- 集中控管：組織和資料夾層級的管理員可以定義及強制執行多項專案的安全性政策。
- 一致性：在整個組織中提供一致的資安態勢，降低設定錯誤和安全漏洞的風險。
- 效率：簡化安全性更新和緩解措施的部署作業，例如同時封鎖大量資源的特定 IP 位址範圍，或解決重大安全漏洞。
- 委派：在階層結構的適當層級套用政策，將安全性責任委派給不同團隊或部門。
您可以根據組織需求，套用及結合這些一般原則。請參考下列應用實例：
- 組織層級 IP 位址封鎖：您可以封鎖組織中所有專案來自已知惡意 IP 位址範圍的流量。
- 地理位置限制：您可以在組織或資料夾層級，限制來自特定地理區域的流量。
- CVE 緩解：您可以快速部署 WAF 規則，緩解多項專案中的重大安全漏洞。
- 法規遵循：在整個組織套用一致的安全政策，強制遵守法規要求。
- 精細的存取控管：您可以授予特定 IP 位址範圍或地理區域存取特定資料夾內所有資源的權限。
功能與特色
階層式安全性政策支援服務層級安全性政策支援的部分功能。下表比較可與階層式安全性政策和服務層級安全性政策搭配使用的 Cloud Armor 功能：
| 前端類型 |
|
|
| 連接點 (受保護的資源) | 後端服務 | 資源階層節點 |
| 規則動作 |
|
|
| 用戶端 IP 位址 | ||
| 用戶端地理位置 | ||
| 用戶端 ASN | ||
| 頻率限制 | ||
| TLS 指紋 (JA3 和 JA4) | ||
| 機器人管理 | (僅限 EXTERNAL_302 和要求裝飾) |
|
| HTTP 篩選 | ||
| 內文篩選 | ||
| WAF | ||
| 代管規則 | ||
| Google Threat Intelligence | ||
| reCAPTCHA | ||
| Adaptive Protection | ||
| 位址群組 | ||
| 組織層級位址群組 | ||
| Security Command Center | ||
| Cloud Monitoring | ||
| 要求記錄 |
階層式安全性政策的運作方式
建立階層式安全性政策時，您是在組織或資料夾層級建立，而該資源擁有階層式安全性政策。建立階層式安全性政策後，安全性政策規則不會套用至任何資源。
接著，將階層式安全性政策與組織、資料夾或專案建立關聯，這些資源可以與擁有政策的資源相同。將階層式安全性政策與資源建立關聯後，系統會將安全性政策規則套用至資源階層中該節點及以下層級的受保護資源。為協助您決定要將階層式安全性政策附加至哪項資源，請參閱下列各項資源的基本用途清單：
- 組織：將組織層級階層式安全性政策視為預設的階層式安全性政策類型。這些政策具有廣泛的身分與存取權管理 (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 狀態。您也會在Google Cloud 控制台中看到新的專案級別。
只有在全域外部負載平衡器的至少一項後端服務使用 HTTP、HTTPS、HTTP2、H2C 或 GRPC 時，專案才會自動註冊。
限制
階層式安全性政策有下列限制：
- 階層式安全性政策不適用於組織外的專案。
- 如果是新專案或最近還原的專案，可能需要幾小時，專案上繼承的安全性政策才會生效。
- 如果專案最近才啟用 Compute Engine API，可能需要幾小時，專案繼承的安全性政策才會生效。
- 您可以調整自有階層式安全性政策中預先設定的 WAF 規則，但繼承階層式安全性政策的服務擁有者無法調整規則。