【How-to Guides】GCP Security —使用政策引擎 Access Context Manager（ACM）制定組織安全策略

18 min readNov 26, 2023

--

前言

Access Context Manager（ACM）是 Google Cloud Platform（GCP）提供的一種存取管理的服務，控制策略是在「機構（組織）」層次，可統一集中設定，不會散在各個專案裡，用於增強雲端環境中的資源安全性。ACM 主要目標是允許按照組織特定的條件和 context，進行精細控制使用者對 GCP 資源的存取權限，例如：

IP子網路（IP子網路）：檢查請求是否來自指定 IPv4 / IPv6 CIDR（Classless Inter-Domain Routing，CIDR）位址（一個或多個）
地區（Regions）：檢查請求是否來自於特定地區
主體（Principals）：檢查請求是否來自特定使用者或服務帳號（IAM）
裝置政策（Device Policy）：檢查存取的裝置是否符合裝置政策，例如是否啟用螢幕鎖定、是否有儲存加密、是否為公司裝置等。設定時，會引用由端點驗證建立的裝置清單，這對於使用雲端服務並又有需符合使用端末設備的要求行業特別有效。

當 Access Context Manager（ACM）與其他 GCP 安全性解決方案結合時，可以創建更全面的存取控制策略。包括可以將 ACM 整合到 VPC Service Controls（VPCSC）和 BeyondCorp，例如：

整合 VPC Service Controls（VPCSC）

VPCSC 提供了一個可在 Google Cloud 中保護數據的有效方法，特別是當這些數據需要在多個專案之間進行共享時。透過整合 ACM 和 VPCSC，可以確保只有符合 ACM 規則的授權實體可以訪問特定的 VPCSC 專案
範例： 在 VPCSC 中定義的存取控制規則可以與 ACM 中的 IP 子網、地區和主體條件進行結合，以實現更細緻的存取控制。即使在受信任 VPCSC 網路內，只有符合 ACM 條件的實體才能夠存取特定的資源。

2. 整合 BeyondCorp

BeyondCorp 是一種零信任安全模型，它將存取控制從傳統的基於網路的方法轉移到基於身份的方法。通過將 ACM 與 BeyondCorp 模型結合，你可以建立更加動態和基於身份的存取控制策略。
範例： 使用 BeyondCorp 的身份驗證概念，ACM 可以應用在不同環境中，如公司內部網路、遠端訪問或設備。這表示不僅可以根據 IP 和地區進行存取控制，還可以基於用戶身份進行更細緻的控制，使得存取權限更符合實際業務需求。

個人使用下來覺得 ACM 的設計與其他 Google Cloud 安全性解決方案相輔相成，只要制定好政策後，在藉由其他 GCP 的整合機制，可以在多個層面上建立安全性，從而確保數據和資源受到有效的保護。

深入了解 Access Context Manager

Access Context Manager 中定義的條件設定稱為存取等級，存取等級可以根據以下元素進行調整

[1] IP 位址範圍
[2] 地區
[3] 設備策略
[4] Principle

[1] IP位址範圍

以 CIDR 格式 x.x.x.x/x 指定 IPv4 和 IPv6 IP 位址，限制只能指定公共 IP

[2] 地區

地理位置由來源 IP 位址決定，僅允許來自指定區域的存取。如果條件中指定了多個區域，則將使用 OR 來確定它們。
註：由於確定是基於公用 IP 位址，因此如果您指定區域作為條件，則使用 Private Google Access 等從私人 IP 位址進行的存取將被拒絕。

[3] 設備策略

您可以將其設為與透過下述端點驗證所取得的裝置策略相符的條件。

強制螢幕鎖定
儲存加密
該設備已獲得管理員批准
必須是公司指定的設備
必須是公司指定的作業系統

這可防止非公司的設備連接到該服務，防止不安全的設備連接到該服務

[4] Principle

用於存取的主體（Google 帳戶或服務帳戶）。IAM 策略是透過連結到 Google 帳戶、群組和服務帳戶來建立，因此在條件中指定主體可能會受到限制。當您想要根據綁定到同一組的 IAM 策略中的委託人稍微更改條件時，可以使用它

[範例] ops-lab@fubar.com <=> 有一個 IAM 策略允許 IAP 存取系統 A。策略條件「tom@fubar.com 允許在 09:00–18:00 存取」
註：無法從控制台將新增至 IAM 條件，這需要使用 gcloud 命令

**資安單位可以先檢查 Cloud Identity, BeyondCorp + ACM 有沒有設定好裝置管理，避免不是公司的裝置也能溜入公司的雲端環境**

實際應用案例

有時候看實際可落地的場景會比較容易理解，ACM 與 BeyondCorp, VPCSC 可以怎麼一起使用

案例一

如何使用 BeyondCorp 並結合 Access Context Manager（ACM）以確保員工存取 Google Cloud 資源時，確保員工於受信任的網路、裝置、存取 Google 資源

**從 Beyond Corp 引入 Cloud Identity 從組織層級去管理使用者；再引入 ACM 你想要套用的存取等級**

案例二

當你在雲端環境中擁有多個敏感資源時，你可能會面臨到如何有效管理和控制這些資源存取的挑戰。VPC Service Controls（VPCSC）提供了一個強大的網路層次存取控制解決方案，而 Access Context Manager（ACM）則進一步擴展了這個控制，使你能夠根據更豐富的條件和 context，更細緻地管理使用者對 GCP 資源的存取權限。

案例一

Step 1：Cloud Identity 將使用者加入 Groups
Step 2：Access Context Manager 建立訪問級別（Access Level）
Step 3：Security 中設定 BeyondCorp Enterprise
Step 4：驗證

Step 1：Cloud Identity 將使用者加入 Groups

**登入 admin.google.com > Directory > Groups > 並建立新群組**

Tips：至少排除一位 Admin 或 Owner 放置在 All User，一方面避免設定錯誤無法存取，一方面是讓管理員可以有更高的管理權進行緊急處理

Step 2：Access Context Manager 建立訪問級別（Access Level）

有留意到嗎？因 Access Context Manager 為 Organization 層級服務，Console 上方需切換至 Org 層級

Step 3：Security 中設定 BeyondCorp Enterprise

**Security > BeyondCorp Enterprise > Manage access to cloud console and API(管理 Cloud 控制台和 API 的存取權)**

**Cloud Identity — All User 引入；regionIP 則是剛剛設定好的**

Step 4：驗證

BeyondCorp 是 Google 內部採用十年的安全架構和方法論，可以用簡單方式來管理公有雲、私有雲，或地端時，透過 BeyondCorp 搭配 ACM 的功能，對資安上來說這無疑是十分好用的工具！也特別推薦有要處理支付卡行業（PCI）資料安全標準（DSS）、（Information Security Management System, ISMS）標準等企業，將設備、IP、主體或地區納管

**設定 Japan 地區，結果什麼也不行；回到 Taiwan 地區則正常！**

Cloud Shell 下指令 gsutil ls

ServiceException: 401 Anonymous caller does not have storage.buckets.list access to the Google Cloud project. Permission ‘storage.buckets.list’ denied on resource (or it may not exist).

案例二：限制公司網路上的存取權限

本範例說明如何建立僅允許從指定範圍 IP 位址、地區（例如公司網路中的 IP 位址）存取的存取權限等級條件。限制取得存取權限的 IP 位址範圍，假設要建立的存取權限等級將允許一組內部稽核員存取名為 sensitive-data 的專案的 Cloud Storage 服務。這些審核人員的所有設備的IP 屬於 203.0.113.0 到203.0.113.127 此子網路範圍。您知道，除了審核人員使用的設備之外，不會有任何設備分配給該子網路（Creating a basic access level）

VPC Service Controls（VPCSC）是Google Cloud Platform（GCP）提供的一種安全性功能，用於強化雲端環境中的資源存取控制。VPCSC 的核心理念是提供一個多層次的防禦，以確保敏感資源僅受到授權實體的存取。

VPC Service Controls (VPCSC) 提供Ingress/Engress 策略，此次將嘗試使用它與 ACM 搭配，VPCSC 專注於強化網路層次的存取控制，而 ACM 則提供了更靈活的存取管理手段。
註：VPC SC 是一種組織資源，需要有組織的權限才能測試喔！

Step1. ACM 政策設定（ACM Policy）

這個指令的目的是在指定的組織（ORGANIZATION_ID）下創建一個名為 "Default Policy" 的新策略。ACM 策略用於定義存取控制的規則和條件，以管理對 Google Cloud 資源的存取權限

$ gcloud access-context-manager policies create \
    --organization=<ORGANIZATION_ID> --title="Default Policy"

Create request issued
complete...done.
Created.


$ gcloud access-context-manager policies list \
  --organization=<ORGANIZATION_ID>

NAME: 1160293221
ORGANIZATION: <ORGANIZATION_ID>
SCOPES: 
TITLE: default policy
ETAG: 2e235f80174cecc0

Step2. 建立 ACM 存取級別（ACM levels）

只想允許來自特定 IP 位址的訪問

# 存一個叫 file name = access-level.yaml 的檔案

- ipSubnetworks:
  - 203.0.113.0/25

access levels 為 allow_from_authyorized_ips，或使用 UI 設定，可以參考案例一的 Step2. 步驟

$ gcloud access-context-manager levels create "allow_from_authorized_ips" \
    --basic-level-spec=access-level.yaml \   # 定了存取等級的基本規格
    --combine-function=AND \                 # 存取等級的組合函數
    --title="Allow from authorized IPs" \
    --policy=<PolicyID>    # 存取等級所屬的 ACM 政策 ID。可以將存取等級與特定的政策關聯起來

**另外測試以地區來作為存取級別，level name 取名為 regionIP，可加上 AND OR，再增設一個 IP 條件可能是來自公司 IP**

Step3. 設定 ACM Service Perimeter

最後，建立 Service Perimeter。將您先前建立的存取等級連結到 Cloud Storage API。輸入目標 GCS Bucket 所在的 GCP 專案編號（非專案ID）
注意：服務邊界不能包含來自不同組織的項目。

$ gcloud access-context-manager perimeters create restrict_contents_access \
    --title="Restrict Contents Access" \
    --resources=projects/<PROJECT-ID> \
    --restricted-services=storage.googleapis.com \
    --access-levels=regionip \
    --policy=<ACM Policy-ID>
API [accesscontextmanager.googleapis.com] not enabled on project [furbarlab]. 

Enabling service [accesscontextmanager.googleapis.com] on project [furbarlab]...
Create request issued for: [restrict_contents_access]
Created perimeter [restrict_contents_access].

accessPolicies/1160293221/accessLevels/regionip

切換至 VPC Service Control 查看

**套用 regionIP 的存取級別，加上他是歸屬那個 Policy 項下**

如果您到目前為止執行此操作，您將能夠從連接來源 IP 使用 Cloud Storage，但從 Cloud Shell 等存取將被拒絕。

Step4. 引入 VPCSC Ingress/Egress Policy

文檔參考這邊 🔗 Ingress and egress rules

# file ingress-policy.yaml 
- ingressFrom:
    identityType: ANY_IDENTITY
    sources:
    - accessLevel: accessPolicies/<PolicyID>/accessLevels/allow_from_authorized_ips
      # accessLevel: accessPolicies/<PolicyID>/accessLevels/regionip  # 使用地區
  ingressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: "*"
    resources:
    - projects/<ProjectID>

這表示如果滿足相應的存取等級並獲得授權，則允許所有 Cloud Storage API 操作。此設定只是一個示範，權限沒有差異。但可以定義存取等級以允許對 Cloud Storage API 進行特定存取，且使用上也比較彈性

$ gcloud access-context-manager perimeters create restrict_contents_access \
    --title="Restrict Contents Access" \
    --ingress-policies=ingress-policy.yaml \
    --access-levels=allow_from_authorized_ips \
    --resources=projects/<ProjectID> \
    --restricted-services=storage.googleapis.com \
    --policy=<PolicyID>

接下來要考慮的是上面 Ingress Policy 設定method可以調整（參考文檔）
您需要在此處描述您希望在 Cloud Storage API 中允許的內容。找到受支援的 APImethod列表，例如調整成 google.storage.buckets.list

允許來自特定 IP 位址的所有操作
即使 IP 位址不允許，也允許 GCS Bucket 清單

使用下來 Ingress Policy 簡化了邊界的設置，因此在設置跨多個專案的設定時使用它似乎更方便。

Summary

在大型企業尤其實像是金融產業對於資訊安全的要求一向很高，盡可能減少受攻擊面向是一直在努力的方向。ACM 的設計理念在於集中化管理，確保只有經過授權的使用者和符合條件的設備能夠存取敏感的的雲端資源。

而透過 VPC 服務控制項 (VPC Service Controls)，管理員能設定精細的安全範圍控管政策並且套用到數個 GCP 專案與服務，而且這些控管政策是在「機構(organization)」層級統一集中設定的，不會散佈在各個專案裡面，的確方便管理員能夠統一管理。

FAQ

建立服務邊界或更新現有服務邊界後，更改最多可能需要30 分鐘才能傳播完畢並生效。在此期間，邊界可能會阻止請求，並顯示錯誤訊息：Error 403: Request is prohibited by organization's policy.
設定了 BeyondCorp 之後 Cloud Shell 就無法使用了，主要 Cloud Shell 是使用 Google 提供的機器與網路，所以會被 BeyondCorp 擋下來 •͈⌔•͈⑅
怎麼建立組織 (¬_¬)
🔗【How-to Guides】GCP Security — 透過 Cloud Identity Free 幫你以組織方式實現多人安控機制
ACM 存取權限等級不能包含專用 IP 範圍（例如192.168.0.0/16 或172.16.0.0/12），建立的時候會報錯 Level create failed

https://cloud.google.com/access-context-manager/docs/create-basic-access-level

私有 IPv4 地址範圍通常是根據 RFC 1918 定義的，包括以下三個區段
(1) 10.0.0.0 到 10.255.255.255（10.0.0.0/8）
(2) 172.16.0.0 到 172.31.255.255（172.16.0.0/12）
(3) 192.168.0.0 到 192.168.255.255（192.168.0.0/16）