設計存取層級

本文說明存取層級的實作方式,並提供相關建議,協助您根據許可清單啟動 service perimeter 強制執行作業。

完成工作負載的模擬測試執行作業後,您會取得需要加入許可清單的 IP 位址和身分識別清單。您也可能會發現某些工作負載需要裝置許可清單。如要授予受保護 Google Cloud 資源的受控存取權,請使用 VPC Service Controls 存取層級。您可以根據 IP 位址、身分或裝置,以實用的方式導入存取層級。

詳情請參閱「含有輸入規則的情境感知存取權」一文。

根據來源 IP 授予存取權

您只能在 IP 許可清單的存取層級中使用公開 IP CIDR 範圍。由於這個方法允許來自此 IP 範圍的所有受保護 API,因此這些 IP 背後的環境必須受到信任和控管。這份許可清單的典型用途是允許從地端部署網路存取 perimeter。下圖顯示 IP 位址許可清單如何封鎖及允許存取 perimeter:

VPC Service Controls 網路和 service perimeter 可阻擋不受信任網路有效身分的存取嘗試。

在上圖中,有效身分嘗試存取 perimeter。如果存取嘗試來自任何網際網路 IP 位址,會遭到拒絕。不過,如果存取要求來自公司的公開 IP 位址,則會獲得允許。

另一種情況是,允許從部署在不同專案或組織中的非公開資源存取 perimeter。在本使用案例中,來源專案必須要有 Cloud NAT 閘道。Cloud NAT 已與 Private Google Access 整合,可自動為資源的子網路啟用 Private Google Access,並將 Google API 和服務的流量保留在內部,而不是使用 Cloud NAT 閘道的外部 IP 位址將流量傳送到網際網路。由於流量是在 Google 內部網路傳送,AuditLog 物件的 RequestMetadata.caller_ip 欄位會修訂為 gce-internal-ip。如要在這種情況下允許存取 perimeter,您需要設定輸入規則,根據專案或服務帳戶等其他屬性允許存取,而不是根據外部來源 IP 位址設定存取層級。

根據呼叫端身分授予存取權

如要實作以身分為依據的許可清單,請將服務帳戶和組織超級管理員新增至許可清單。這些身分可從任何 IP 位址存取 perimeter,因此您必須確保身分受到妥善保護。此外,請務必避免為已加入許可清單的服務帳戶建立金鑰。將使用者身分加入 perimeter 的許可清單並不常見 (群組無法新增至許可清單)。

您可以透過 perimeter 內的 VM、信任的地端部署網路或信任的裝置,存取 perimeter 內的資源。建議您使用 Cloud Workstations 存取 perimeter 內的資源,因為 VPC Service Controls 不支援 Cloud Shell

根據呼叫端裝置屬性授予存取權

裝置信任 (也稱為「信任的端點」) 的運作方式,是讓有效的組織使用者登入 Chrome 瀏覽器或 Chromebook。信任適用於已登入作業系統的工作階段。舉例來說,已登入並執行 Chrome 工作階段的 Windows 使用者 (不一定要開啟瀏覽器),可以對受保護的 perimeter API 成功呼叫 gcloud CLI 指令。不過,同一部電腦上的其他 Windows 使用者工作階段,無法對受保護的 perimeter API 呼叫指令。

下列裝置條件有助於建立裝置信任:

  • 已驗證的 ChromeOS 是一種經過加密驗證的高度安全狀態,表示有效組織使用者已登入安全啟動的 Chromebook。這是建議的第 1 層信任條件。

    已啟用「已驗證的 ChromeOS」選項的作業系統政策。

  • 裝置存取權須經管理員核准:可讓 Cloud Identity 管理員先核准裝置,再授予存取權。根據預設,有效組織使用者登入的裝置會自動獲得核准。不過,建議您關閉自動核准選項。

  • 需要公司自有裝置:透過 Chrome 代理從 OS 擷取序號,序號通常來自 BIOS。這個編號必須與輸入 Cloud Identity 的現有序號相符。

    由於序號在非 ChromeOS 裝置中不具授權性,因此具備較高管理員權限的使用者或許可以偽造序號。建議只將這項條件做為第 2 層檢查。

如要查看根據上述清單中討論的條件授予受控存取權的追蹤器範本,請參閱 VPC Service Controls 上線範本 - 許可清單 (PDF)

開始強制執行

設計許可清單並更新存取層級後,建議您再次執行工作負載,確認沒有任何違規情況。如果工作負載執行時沒有違規行為,您就可以啟動 VPC Service Controls 強制執行功能,而不影響應用程式。

規劃違規處置時,請納入下列事項:

  • 選擇強制執行日期,並將該日期告知所有相關團隊。
  • 確保資安營運和事件應變團隊瞭解部署作業。此外,請確保具備適當權限的人員會檢查記錄,並視需要核准其他許可清單。
  • 確保情況應變團隊可以開啟 Google Cloud客服案件,以利解決任何問題或疑問。
  • 使用 Terraform 等自動化工具建立或修改 perimeter 和存取層級。建議不要手動執行這些工作。

啟動強制執行作業時,請先將與單一工作負載相關聯的專案,從 dry run perimeter 移至有效 perimeter邊界。請務必預留時間,讓應用程式正確執行,同時觀察違規記錄。針對其餘工作負載逐一重複上述程序。

如要顯示遭封鎖的違規事項,請設定匯總記錄檔接收器,將 perimeter 內所有專案的稽核記錄傳送至 BigQuery,然後執行下列查詢:

SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
WHERE JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') is null #exclude logs from a dry-run perimeter

後續步驟