決定 Google Cloud 登陸區的安全性

Last reviewed 2025-06-07 UTC

本文件將介紹設計 Google Cloud 登陸區時，應考量的安全性重要決策和建議選項。本系列文章將說明登陸區，適用對象為安全專家、資訊安全長和架構師，他們希望瞭解在 Google Cloud中設計登陸區時，需要做出哪些決策。

在本文件中，我們假設安全團隊或平台團隊等中央團隊會強制執行這些目標區安全控管措施。由於本文件著重於企業規模環境的設計，因此其中描述的部分策略可能與小型團隊無關。

確保 Google Cloud 登陸區安全的決策點

如要為貴機構選擇最佳安全性設計，您必須做出下列決定：

架構圖

本文件所述的架構範例採用常見的安全性設計模式。具體的控制項可能會因貴機構所屬產業、目標工作負載或其他法規遵循要求等因素而異。下圖顯示在遵循本文件建議的情況下，您在目標區中套用的安全控制架構。

安全控管架構範例。

上圖顯示以下內容：

  • 管理服務帳戶金鑰有助於降低長期服務帳戶憑證的風險。
  • VPC Service Controls 會在機密資源周圍定義範圍，以便限制範圍外的存取權。
  • Security Command Center 會監控環境，找出不安全的設定和威脅。
  • 集中式記錄檔接收器會收集所有專案的稽核記錄。
  • Google 的預設靜態資料加密功能會加密所有儲存在磁碟的資料。
  • Google 預設的傳輸中加密功能適用於第 3 層和第 4 層網路路徑。
  • 資料存取透明化控管機制可讓您全面瞭解及控管 Google 如何存取您的環境。

決定如何限制服務帳戶的永久憑證

服務帳戶是機器身分，可用於將 IAM 角色授予工作負載，並允許工作負載存取 Google Cloud API。服務帳戶金鑰是永久憑證，任何永久憑證都可能帶來高風險。我們不建議您讓開發人員隨意建立服務帳戶金鑰。

舉例來說，如果開發人員不小心將服務帳戶金鑰提交至公開 Git 存放區，外部攻擊者就能使用這些憑證進行驗證。舉另一個例子來說，如果服務帳戶金鑰儲存在內部存放區，惡意內部人員可以讀取金鑰，並使用憑證提升自身的 Google Cloud 權限。

如要定義管理這些永久憑證的策略，您必須提供可行的替代方案、限制永久憑證的擴散情形，並管理其使用方式。如要瞭解服務帳戶金鑰的替代方案，請參閱「選擇合適的驗證方法」。

以下各節將說明限制永久性憑證的選項。我們建議在大多數用途中採用選項 1。如果選項 1 不適用於您的機構，請考慮以下各節所述的其他選項。

在 2024 年 5 月 23 日後建立的所有機構，都會在首次建立機構資源時強制執行Google Cloud 安全基準限制。這項變更會將選項 1 設為預設選項。

選項 1：限制使用永久性服務帳戶金鑰

建議您不要允許任何使用者下載服務帳戶金鑰，因為公開金鑰是常見的攻擊途徑。限制使用永久服務帳戶金鑰，可降低手動管理服務帳戶金鑰的風險和額外負擔。

如要導入這個選項，請考慮下列事項：

  • 如要防止開發人員建立及下載持續性憑證，請設定組織政策限制 constraints/iam.disableServiceAccountKeyCreation。
  • 請向團隊說明比服務帳戶金鑰更安全的替代方案。舉例來說，如果Google Cloud 環境以外的使用者和應用程式需要使用服務帳戶，他們可以使用服務帳戶模擬或工作負載身分聯盟進行驗證，而非使用服務帳戶金鑰。
  • 請設計一個程序，讓團隊在下載服務帳戶金鑰是唯一可行選項時，可以要求例外狀況。舉例來說，第三方 SaaS 產品可能需要服務帳戶金鑰，才能讀取您 Google Cloud 環境中的記錄。

如果您已準備好工具，可為服務帳戶產生短期 API 憑證，請避免使用這個選項。

如要瞭解詳情，請參考下列資源：

選項 2：使用其他存取管理工具產生短期憑證

除了限制持續性服務帳戶金鑰的使用權限，您也可以產生服務帳戶的短期憑證。相較於服務帳戶金鑰等持續性憑證，短期憑證的風險較低。您可以自行開發工具，或使用 Hashicorp Vault 等第三方解決方案來產生短期存取憑證。

如果您已投資第三方工具，用於產生存續時間較短的憑證來控管存取權，或是有足夠的預算和能力自行開發解決方案，請使用這個選項。

如果您沒有現有的工具可授予短期憑證，或無法自行建構解決方案，請避免使用這個選項。

詳情請參閱「建立短期服務帳戶憑證」。

決定如何透過 Google API 降低資料外洩風險

Google API 提供公開端點，所有客戶皆可使用。雖然 Google Cloud 環境中的每個 API 資源都受到 IAM 存取控制項的管制，但仍有可能有人使用遭竊的憑證存取資料，或是遭到惡意內部人士或遭到入侵的程式碼竊取，或是透過設定錯誤的 IAM 政策洩漏資料。

VPC Service Controls 是解決這些風險的解決方案。不過，VPC Service Controls 也會使存取模型變得複雜，因此您必須設計 VPC Service Controls，以符合您的獨特環境和用途。

以下各節將說明如何透過 Google API 減少資料外洩。我們建議在多數用途中採用選項 1。如果選項 1 不適用於您的特定用途，請考慮以下各節所述的其他選項。

選項 1：在環境中廣泛設定 VPC Service Controls

建議您在限制所有支援 API 的一或多個 VPC Service Controls 範圍內設計環境。使用存取層級或輸入政策設定範圍的例外狀況，讓開發人員可以存取所需的服務，包括在需要時存取控制台。

在下列情況下使用此選項：

  • 您要使用的服務支援 VPC Service Controls，且工作負載不需要無限制的網際網路存取權。
  • 您儲存的機密資料 Google Cloud 如果遭到竊取，可能會造成重大損失。
  • 您可以為開發人員存取權設定一致的屬性，並將其設為邊界例外狀況，讓使用者存取所需的資料。

如果工作負載需要不受限制的網際網路存取權，或 VPC Service Controls 不支援的服務，請避免使用這個選項。

如要瞭解詳情，請參考下列資源：

選項 2：為環境的子集設定 VPC Service Controls

您可以在環境中廣泛設定 VPC Service Controls，也可以只針對包含機密資料和僅限內部工作負載的專案子集設定 VPC Service Controls。這個選項可讓您為大多數專案使用更簡單的設計和作業，同時仍可為含有機密資料的專案優先保護資料。

舉例來說，如果只有少數專案含有含有機密資料的 BigQuery 資料集，您可以考慮採用這個替代做法。您可以針對這些專案定義服務範圍，並定義輸入和輸出規則，為需要使用這些資料集的分析師設定例外狀況。

舉例來說，在採用三層式架構的應用程式中，部分元件可能位於外圍之外。允許使用者流量進入的呈現層，可能是範圍外專案，而包含機密資料的應用程式層和資料層，則可能是服務範圍內的個別專案。您可以為邊界定義輸入和輸出規則，讓各層級可透過邊界進行精細存取。

在下列情況下使用此選項：

  • 只有少數明確定義的專案會包含機密資料。其他專案則包含風險較低的資料。
  • 部分工作負載僅限於內部，但部分工作負載需要存取公開網際網路，或依賴 VPC 服務控制項不支援的服務。
  • 在所有專案中設定 VPC Service Controls 會造成過多額外負擔，或需要太多因應措施

如果許多專案可能含有機密資料，請避免使用這個選項。

詳情請參閱啟用 VPC Service Controls 的最佳做法。

選項 3：不要設定 VPC Service Controls

除了在環境中廣泛設定 VPC Service Controls，您也可以選擇不使用 VPC Service Controls，尤其是當營運額外成本超過 VPC Service Controls 的價值時。

舉例來說，貴機構可能沒有一致的開發人員存取模式，無法做為入站政策的依據。您的 IT 作業可能會外包給多個第三方，因此開發人員沒有受管理的裝置，或無法從固定 IP 位址存取裝置。在這種情況下，您可能無法定義輸入規則，以便在開發人員需要完成日常作業時，允許例外狀況。

請在下列情況下使用這個選項：

  • 您使用不支援 VPC Service Controls 的服務。
  • 工作負載面向網際網路，且不含機密資料。
  • 您沒有一致的開發人員存取權屬性，例如受管理的裝置或已知的 IP 範圍。

如果 Google Cloud環境中含有機密資料，請避免使用這個選項。

決定如何持續監控不安全的設定和威脅

與使用內部服務相比，採用雲端服務會帶來新的挑戰和威脅。您現有的監控長期伺服器的工具，可能不適合用於自動調度或暫時性服務，甚至可能完全無法監控無伺服器資源。因此，您應評估安全性工具是否可與您可能採用的所有雲端服務搭配使用。您也應持續監控雲端標準，例如 Google Cloud的 CIS 基準。

以下各節將說明持續監控的選項。我們建議在大多數用途中採用選項 1。如果選項 1 不適用於您的特定用途，請考慮以下各節所述的其他選項。

方法 1：使用 Security Command Center

建議您在機構層級啟用 Security Command Center，以便透過下列方式強化安全防護機制：

  • 評估安全性和資料受攻擊面
  • 提供資產清點和探索功能
  • 找出設定錯誤、安全漏洞和威脅
  • 協助您降低風險並加以改善

在建立登錄區時啟用 Security Command Center，貴機構的安全團隊就能即時掌握不安全的設定、威脅和改善選項。這項資訊可協助安全團隊評估指定區域是否符合其需求，以及是否已準備就緒，可供開發人員開始部署應用程式。

在下列情況下使用此選項：

  • 您希望安全防護機制管理和威脅偵測工具可與所有 Google Cloud 服務整合，而無須額外整合作業。
  • 您希望使用 Google 用於保護自家服務的威脅情報技術、機器學習和其他進階方法。
  • 現有的安全作業中心 (SOC) 沒有能力或技能，無法從大量雲端記錄產生威脅洞察資料。

如果現有的安全性工具可以完全處理暫時性或無伺服器雲端資源、監控不安全的設定，以及在雲端環境中識別大規模威脅，請避免使用這個選項。

方法 2：使用現有安全性工具管理雲端安全防護機制並偵測威脅

除了使用 Security Command Center，您也可以考慮其他雲端安全狀態管理工具。市面上有許多第三方工具，功能與 Security Command Center 相似，而且您可能已投資使用以雲端為主的工具，專注於多雲環境。

您也可以同時使用 Security Command Center 和第三方工具。舉例來說，您可以將 Security Command Center 的發現通知擷取至其他工具，或是在 Security Command Center 資訊主頁中新增第三方安全性服務。舉另一個例子來說，您可能需要在現有的 SIEM 系統中儲存記錄，以便 SOC 團隊分析威脅。您可以將現有的 SIEM 設為只擷取 Security Command Center 產生的發現通知，而非擷取大量記錄，並要求 SOC 團隊分析原始記錄以取得洞察資料。

如果現有的安全性工具可以完全處理暫時性或無伺服器雲端資源、監控不安全的設定，以及在雲端環境中識別大規模威脅，請使用這個選項。

請避免在下列情況下使用這個選項：

  • 現有的 SOC 沒有技能或能力，無法從大量的雲端記錄產生威脅洞察資料。
  • 將多個第三方工具與多項 Google Cloud服務整合，會帶來比價值更高的複雜性。

如要瞭解詳情，請參考下列資源：

決定如何集中匯總必要的記錄

大部分的稽核記錄都會儲存在產生記錄的 Google Cloud 專案中。隨著環境規模擴大，稽核人員可能無法檢查每個專案中的記錄。因此，您必須決定如何集中和匯總記錄，以利內部稽核和安全性作業。

以下各節將說明匯總記錄的選項。我們建議在大多數用途中採用選項 1。如果選項 1 不適用於您的特定用途，請考慮下列各節所述的其他選項。

方法 1：使用匯總記錄匯出端，保留 Google Cloud 中的記錄

建議您為稽核記錄和安全團隊所需的其他記錄，設定機構層級的集中式記錄接收器。您可以參考記錄範圍工具，找出安全性團隊需要的記錄，以及這些記錄類型是否需要明確啟用。

舉例來說，安全性團隊希望您為使用者建立的所有資源建立集中記錄，以便監控及調查可疑變更。安全性團隊也要求針對特定高度機密工作負載，建立不可變更的資料存取記錄。因此，安全性團隊會設定一個記錄匯入端，將所有專案的管理員活動稽核記錄匯總至中央專案中的 Log Analytics 桶，以便他們隨時查看進行調查。接著，他們會設定第二個記錄匯出地點，將含有敏感工作負載的專案資料存取稽核記錄匯入 Cloud Storage 值區，以便長期保留。

在下列情況下使用此選項：

  • 安全性團隊希望能集中記錄所有稽核記錄或其他特定記錄類型。
  • 安全團隊需要將記錄儲存在存取權受限的環境中，不受產生記錄的工作負載或團隊控制。

請避免在下列情況下使用這個選項：

  • 貴機構沒有針對跨工作負載的稽核記錄一致性訂定中央規定。
  • 個別專案擁有者須負起管理自身稽核記錄的全部責任。

如要瞭解詳情，請參考下列資源：

方法 2：將必要的稽核記錄匯出至 Google Cloud以外的儲存空間

除了僅在 Google Cloud 中儲存記錄，您也可以考慮將稽核記錄匯出至 Google Cloud以外的位置。將必要的記錄類型集中到 Google Cloud中的匯總記錄接收器後，請將該接收器的內容匯入Google Cloud 以外的其他平台，以便儲存及分析記錄。

舉例來說，您可以使用第三方 SIEM 匯總及分析多個雲端供應商的稽核記錄。這項工具具備足夠的功能，可搭配無伺服器雲端資源使用，而您的 SOC 團隊擁有相關技能和能力，可從大量記錄中產生洞察資料。

Google Cloud中的網路輸出成本，以及其他環境中的儲存空間成本和容量，都可能讓這個選項的費用非常昂貴。建議您不要匯出所有可用的記錄，而是選擇外部環境中需要的記錄。

如果您需要將所有環境和雲端供應商的記錄儲存在單一集中位置，請使用這個選項。

請避免在下列情況下使用這個選項：

  • 現有系統沒有足夠的容量或預算來擷取大量額外的雲端記錄。
  • 您現有的系統需要針對每種記錄類型和格式進行整合。
  • 您收集記錄時，未明確說明記錄的用途。

詳情請參閱企業基礎架構藍圖中的「偵測控制項」。

決定如何遵守靜態資料加密適用的法規

Google Cloud 會使用一或多種加密機制，自動為儲存在系統中的所有內容加密。視法規遵循要求而定，您可能需要自行管理加密金鑰。

以下各節將說明靜態資料加密的選項。我們建議在大多數用途中採用選項 1。如果選項 1 不適用於您的特定用途，請考慮以下各節所述的其他選項。

方法 1：接受使用預設靜態資料加密

對於許多用途而言，只要使用預設靜態資料加密功能即可，除非該用途有特定的加密金鑰管理法規要求。

舉例來說，線上遊戲公司的安全團隊要求所有靜態客戶資料都必須加密。他們沒有關於金鑰管理的法規要求，在查看 Google 的預設靜態資料加密功能後，他們認為這項功能足以滿足他們的需求。

在下列情況下使用此選項：

  • 您沒有關於如何加密資料或管理加密金鑰的特定要求。
  • 您偏好使用代管服務，不想自行管理加密金鑰，以免產生相關費用和營運開銷。

如果您有法規遵循要求，必須自行管理加密金鑰，請避免使用這個選項。

詳情請參閱「 Google Cloud中的靜態資料加密」。

選項 2：使用 Cloud KMS 管理加密金鑰

除了預設的靜態資料加密功能，您可能還需要進一步控管用於在 Google Cloud 專案中加密靜態資料的金鑰。Cloud Key Management Service (Cloud KMS) 可讓您使用客戶管理的加密金鑰 (CMEK) 保護資料。舉例來說，金融服務業可能會要求您向外部稽核人員報告，您如何管理機密資料的加密金鑰。

如要提供額外的控管層級，您可以使用 CMEK 設定硬體安全性模組 (HSM) 或外部金鑰管理 (EKM)。我們不建議使用客戶提供的加密金鑰 (CSEK)，因為過去由 CSEK 處理的情況，現在可由 Cloud External Key Manager (Cloud EKM) 更妥善地處理，因為 Cloud EKM 支援更多服務，可提供更高的可用性。

這個選項會將部分責任轉移給應用程式開發人員，要求他們遵循安全性團隊規定的金鑰管理方式。安全性團隊可以透過 CMEK 機構政策，禁止建立不符合規定的資源，藉此強制執行這項規定。

在下列一或多項條件成立時，請使用這個選項：

  • 您必須管理自己的金鑰生命週期。
  • 您必須使用 FIPS 140-2 第 3 級認證 HSM 產生密碼編譯金鑰素材。
  • 您需要使用 Cloud EKM 將密碼金鑰內容儲存在Google Cloud 外。

請避免在下列情況下使用這個選項：

  • 您沒有關於如何加密資料或管理加密金鑰的特定要求。
  • 您偏好使用代管服務，不想自行管理加密金鑰，以免產生相關費用和營運開銷。

如要瞭解詳情，請參考下列資源：

選項 3：在儲存空間中持久化前，先在應用程式層中將資料轉為權杖

除了 Google 提供的預設加密功能外，您也可以自行開發解決方案，在將資料儲存在 Google Cloud之前將其轉為符記。

舉例來說，數據資料學家必須分析含有 PII 資訊的資料集，但不應有權存取某些敏感欄位的原始資料。如要限制對原始資料的存取權，您可以使用 機密資料保護功能開發擷取管道，擷取及將機密資料轉為符記，然後將轉為符記的資料儲存至 BigQuery。

您無法在到達區中集中強制執行資料代碼化控管機制。相反地，這個選項會將責任轉移給應用程式開發人員，讓他們自行設定加密功能，或是轉移給平台團隊，由他們開發加密管道，做為應用程式開發人員可使用的共用服務。

如果特定工作負載含有極機密資料，且不得以原始格式使用，請使用此選項。

如果 Cloud KMS 足以滿足您的需求，請勿使用這個選項，詳情請參閱「使用 Cloud KMS 管理加密金鑰」一文。透過額外的加密和解密管道移動資料，會增加應用程式的成本、延遲和複雜性。

詳情請參閱「Sensitive Data Protection 總覽」。

決定如何遵守傳送中資料加密法規

Google Cloud 採用多項安全措施，協助確保資料在傳輸過程中的真實性、完整性和隱私性。視安全性和法規遵循要求而定，您也可以設定應用程式層加密功能。

以下各節將說明流動資料加密選項。我們建議在大多數用途中採用選項 1。如有需要，您可以考慮在下列各節中討論的其他選項，這些選項是額外功能。

方法 1：評估是否已 Google Cloud 充分加密傳輸中的資料

您網域中的許多流量模式都會受益於 Google Cloud 預設的流動資料加密機制。

  • 位於 Google 實際工作環境網路中的虛擬私有雲網路，以及對等互連虛擬私有雲網路中的所有 VM 對 VM 連線都會經過完整性保護和加密。

  • 從網際網路傳送至 Google 服務的流量，以及從 VPC 網路傳送至 Google 服務的流量，會在 Google Front End (GFE) 終止。GFE 也會執行下列操作：

    • 提供 DDoS 攻擊的對應措施
    • 將流量以負載平衡的方式轉送到 Google Cloud 服務

  • Google 基礎架構會使用 ALTS 驗證 GFE 與 Google Cloud 服務之間的連線，以及Google Cloud 服務與 Google Cloud 服務之間的連線，並確保這些連線的完整性和加密機制。

如果 Google Cloud 預設的流動資料加密機制足以滿足內部工作負載的需求，請使用這個選項。

在下列情況下，請新增額外保護措施：

  • 允許網際網路輸入流量進入虛擬私有雲網路。
  • 您正在連線至內部部署環境。

在這種情況下，您應設定其他控制項，如選項 2：要求應用程式在傳輸期間設定第 7 層加密功能和選項 3：為內部部署環境設定額外的加密功能所述。

如要進一步瞭解 Google Cloud 傳輸中資料的預設加密功能，請參閱「Google Cloud中的傳輸中資料加密」。

選項 2：為客戶應用程式流量設定額外加密功能

除了傳輸中的預設加密，您還可以為客戶應用程式的應用程式層加密，設定第 7 層加密。Google Cloud 提供代管服務，支援需要在傳輸中進行應用程式層加密的應用程式，包括代管憑證和 Cloud Service Mesh。

舉例來說，開發人員正在建構可接受來自網際網路的入站流量的新應用程式。他們使用外部應用程式負載平衡器，搭配 Google 代管的 SSL 憑證，在單一 IP 位址後方執行及調整服務。

應用程式層加密功能並非可在指定區域中集中強制執行的控管措施。相反地，這個選項會將部分責任轉移給應用程式開發人員，由他們設定流動資料加密功能。

如果應用程式需要在元件之間傳送 HTTPS 或 SSL 流量，請使用這個選項。

當您將運算工作負載遷移至雲端時，如果該工作負載先前在應用程式在內部部署時，並未要求內部流量在傳輸期間進行加密，建議您為此選項允許有限的例外狀況。在大規模遷移期間，如果在遷移前強制將舊版應用程式改為新版，可能會導致計畫延遲，這是不可接受的。

如要瞭解詳情，請參考下列資源：

選項 3：為內部部署環境設定額外的加密功能

如果您需要從 Google Cloud 連線至內部部署環境，可以設定 Cloud Interconnect，這項服務會在 Google Cloud 和資料中心之間建立直接的實體連線。使用 Cloud Interconnect 時，內部部署環境傳送至 Google Cloud的流量預設不會在傳輸期間加密。因此，如果您使用 Cloud Interconnect，建議您在目標區中啟用 Cloud Interconnect 適用的 MACsec。

如果您使用 HA VPN 連結Google Cloud 與資料中心之間的私人流量，流量預設會使用 IPsec 加密。

詳情請參閱「選擇 Network Connectivity Center 產品」。

決定管理雲端服務供應商存取權所需的額外控管機制

在採用雲端服務時，需要稽核雲端服務供應商 (CSP) 存取權，這可能會成為一大問題。 Google Cloud 提供多層控管機制，可驗證雲端服務供應商的存取權。

以下各節將說明管理 CSP 存取權的選項。我們建議在大多數用途中採用選項 1。在下文中討論的其他選項是額外功能，如果選項 1 無法滿足您的特定用途，不妨考慮使用這項功能。

選項 1：啟用資料存取透明化控管機制記錄檔

資料存取透明化控管機制記錄檔會記錄 Google Cloud 人員在貴機構環境中採取的動作，例如排解支援案件時的動作。

舉例來說，開發人員向 Cloud Customer Care 提出疑難排解問題，並請支援專員協助排解環境問題。系統會產生資料存取透明化記錄，顯示支援團隊採取的動作，包括相關的支援案件編號。

在下列情況下使用此選項：

  • 您必須確認 Google Cloud 人員僅基於正當業務理由 (例如修正服務中斷問題或處理您的支援要求) 存取您的內容。
  • 您有遵循法規的要求，必須追蹤機密資料的存取權。

方法 2：啟用資料存取透明化控管機制記錄檔和供應商存取權管理

如果貴機構有法規遵循要求，必須先核准 CSP 才能存取環境，除了選項 1 之外，您也可以使用資料存取透明化控管機制搭配其他控制項，明確核准或拒絕存取資料。

Access Approval 是一種手動解決方案，可確保客戶服務團隊和 Google 工程團隊在需要存取您的內容時，必須先徵求您的明確核准 (透過電子郵件或 webhook)。

金鑰存取依據是一種程式輔助解決方案，可在使用 Cloud EKM 設定的加密金鑰要求中，新增理由欄位。

在下列情況下使用此選項：

  • 您希望由中央團隊直接管理 Google 人員對內容的存取權。
  • 針對存取權核准功能，您可以接受風險，即核准或拒絕每項存取權要求的中央功能比營運權衡更重要，因為這可能會導致支援案件的解決速度變慢。
  • 關於金鑰存取權的理由，您的公司已在加密策略中使用 Cloud External Key Manager，並希望以程式輔助方式控管所有類型的加密資料存取權 (而非僅限於 Google 人員對資料的存取權)。

請避免在下列情況下使用這個選項：

  • 對於需要高可用性和 Customer Care 團隊快速回應的工作負載而言，當有存取權核准權的中央團隊必須回應時，可能會導致作業延遲，這項風險是不可接受的。

如要瞭解詳情，請參考下列資源：

Google Cloud 到達網頁的安全性最佳做法

除了本文件中介紹的決策之外，請考慮採用下列安全性最佳做法：

後續步驟