決定 Google Cloud 登陸區的安全性

本文將介紹設計 Google Cloud 登陸區時的重要安全決策和建議選項。這是登陸區系列文章之一，適用於安全專家、資訊安全長和架構師，協助他們瞭解在 Google Cloud中設計登陸區時需要做出的決策。

本文假設由中央團隊 (例如安全團隊或平台團隊) 執行這些登陸區安全控管措施。本文著重於企業規模環境的設計，因此文中描述的部分策略可能不太適合小型團隊。

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

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

架構圖

本文說明的範例架構採用常見的安全設計模式。具體控制項可能因貴機構的產業、目標工作負載或其他法規遵循需求等因素而異。下圖顯示您按照本文建議在登陸區套用的安全控管措施架構。

資安控制架構範例。

上圖顯示下列項目：

  • 管理服務帳戶金鑰有助於降低長期服務帳戶憑證帶來的風險。
  • VPC Service Controls 會在機密資源周圍定義 perimeter，有助於限制從 perimeter 外部存取資源。
  • 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 具有公開端點，所有客戶都能使用。雖然環境中的每個 API 資源都受到 IAM 存取權控管，但資料仍可能因憑證遭竊、惡意內部人員或遭入侵的程式碼外洩，或因 IAM 政策設定錯誤而暴露風險。 Google Cloud

VPC Service Controls 解決方案可因應這些風險。不過，VPC Service Controls 也會為存取模式帶來複雜性，因此您必須設計 VPC Service Controls，以符合獨特的環境和用途。

以下各節說明如何透過 Google API 減少資料外洩風險。我們建議在大多數情況下使用選項 1。如果選項 1 不適用於您的特定用途，可以考慮以下各節討論的其他選項。

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

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

符合下列條件時，請使用這個選項：

  • 您打算使用的服務支援 VPC Service Controls，且工作負載不需要不受限制的網際網路存取權。
  • 您在 Google Cloud 儲存機密資料，如果遭外洩，可能會造成重大損失。
  • 您擁有開發人員存取權的屬性一致，可設定為 perimeter 的例外狀況，讓使用者存取所需資料。

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

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

選項 2：為部分環境設定 VPC Service Controls

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

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

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

符合下列任一條件時請採用此做法：

  • 只有有限且明確定義的專案包含機密資料。其他專案包含風險較低的資料。
  • 部分工作負載僅供內部使用，但有些工作負載需要存取公開網際網路，或依附於虛擬私有雲服務控管功能不支援的服務。
  • 在所有專案中設定 VPC Service Controls 會造成過多負擔，或需要太多變通方法

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

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

選項 3：不設定 VPC Service Controls

除了在環境中廣泛設定 VPC Service Controls 之外，您也可以選擇不使用 VPC Service Controls，特別是當運作負擔超過 VPC Service Controls 的價值時。

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

以下情況適用這個選項：

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

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

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

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

以下各節說明持續監控的選項。在大多數情況下，我們建議使用選項 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)，因為 Cloud External Key Manager (Cloud EKM) 支援更多服務，可用性也更高，因此過去 CSEK 解決的案例，現在更適合使用 Cloud EKM 解決。

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

如果符合下列一或多項條件，請使用這個選項：

  • 您必須管理自有金鑰的生命週期。
  • 您必須使用通過 FIPS 140-2 第 3 級認證的 HSM，產生密碼編譯金鑰材料。
  • 您必須將加密金鑰內容儲存在Google Cloud 外部，並使用 Cloud EKM。

如果符合下列任一條件，請避免使用這個選項：

  • 您對資料加密方式或加密金鑰管理方式沒有特定要求。
  • 您偏好使用代管服務，而非自行管理加密金鑰，以免產生相關費用和營運負擔。

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

選項 3：在應用程式層將資料權杖化，然後再儲存

除了 Google 提供的預設加密功能外，您也可以開發自己的解決方案，在資料儲存至 Google Cloud前進行權杖化。

舉例來說，資料科學家必須分析含有 PII 資訊的資料集，但不得存取某些敏感欄位的原始資料。如要限制對原始資料的控制存取權，您可以開發擷取管道，並使用 Sensitive Data Protection 擷取及權杖化機密資料，然後將權杖化資料保留在 BigQuery 中。

您無法在登陸區集中強制執行資料權杖化。這個選項會將責任轉移給應用程式開發人員，由他們自行設定加密，或是轉移給平台團隊，由他們開發加密管道，做為應用程式開發人員可使用的共用服務。

如果特定工作負載含有高度機密資料，且不得使用原始形式的資料，請選用這個選項。

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

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

決定如何符合傳輸中加密的法規遵循規定

Google Cloud 採用多種安全防護措施，協助確保傳輸中資料的真實性、完整性和隱私性。根據您的安全性和法規遵循要求，您也可以設定應用程式層級加密。

以下各節說明流動資料加密選項。在大多數情況下，我們建議使用選項 1。如果選項 1 無法滿足特定用途，您可以考慮使用下列章節討論的其他選項，這些都是額外功能。

方法 1：評估 Google Cloud 流動資料加密是否足夠

登陸區中的許多流量模式都受益於 Google Cloud 預設的流動資料加密機制。

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

  • 從網際網路到 Google 服務的流量，以及從虛擬私有雲網路到 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，做為登陸區的一部分。

如果您使用高可用性 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

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

後續步驟