階層式安全性政策是一類安全性政策，可將 Google Cloud Armor 網路應用程式防火牆 (WAF) 和 DDoS 防護的範圍，擴展到個別專案以外。這些政策會附加在機構、資料夾或專案層級。這些政策與服務層級安全防護政策不同，後者會直接附加至後端服務或後端值區。
在機構或資料夾層級設定階層式安全性政策後，較低層級的專案會繼承該項政策。透過這樣的繼承機制，您可以設定安全性政策規則，然後套用至組織內的部分或所有專案。這有助於在整個環境中集中且一致地強制執行安全性。 Google Cloud
本頁說明階層式安全政策與服務層級安全政策的差異。繼續操作前，請先閱讀安全性政策總覽，確保瞭解安全性政策的運作方式。此外，我們建議您熟悉資源階層。
用途
在大型機構中，管理多個專案的安全性政策可能相當複雜且耗時。階層式安全政策提供下列優勢，協助您解決這些挑戰：
- 集中控管：讓機構和資料夾層級的管理員，能夠跨多個專案定義及強制執行安全性政策。
- 一致性：為整個機構提供一致的安全狀態，降低設定錯誤和安全漏洞的風險。
- 效率：同時簡化大量資源的安全更新和緩解措施部署作業，例如封鎖特定 IP 位址範圍或解決重大安全漏洞。
- 委派：在階層的適當層級套用政策，將安全防護職責委派給不同團隊或部門。
您可以根據貴機構的需求，套用及組合這些一般原則。請參考下列範例用途：
- 全機構 IP 位址封鎖：您可以封鎖來自已知惡意 IP 位址範圍的流量，適用於機構中的所有專案。
- 以地理位置為基礎的限制：您可以在機構或資料夾層級，限制來自特定地理區域的流量。
- 防範 CVE：您可以快速部署網路應用程式防火牆規則，防範多個專案中的重大安全漏洞。
- 強制執行法規遵循：您可以在整個機構套用一致的安全性政策，強制遵守法規要求。
- 精細的存取權控管：您可以授予特定 IP 位址範圍或地理區域存取特定資料夾內所有資源的權限。
功能
階層式安全性政策支援服務層級安全性政策支援的部分功能。下表比較可搭配階層式安全性政策和服務層級安全性政策使用的 Google Cloud Armor 功能：
| 前端類型 |
|
|
| 附加點 (受保護的資源) | 後端服務 | 資源階層節點 |
| 規則動作 |
|
|
| 來源 IP 位址 | ||
| 來源地理位置 | ||
| 來源 ASN | ||
| 機器人管理 | (僅限
EXTERNAL_302 和要求裝飾) |
|
| 第 7 層篩選 | ||
| WAF | ||
| Google Threat Intelligence | ||
| 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 Armor Enterprise Annual 的 Cloud Billing 帳戶，系統會自動註冊 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，專案繼承的安全性政策可能需要幾小時才會傳播。
- 您可以調整您擁有的階層式安全性政策中預先設定的網頁應用程式防火牆規則，但繼承階層式安全性政策的服務擁有者無法調整規則。