管理服務帳戶金鑰的最佳做法

服務帳戶沒有密碼，這點與使用者帳戶不同。服務帳戶會改用 RSA 金鑰組進行驗證。如果您知道服務帳戶金鑰組的私密金鑰，可以使用該私密金鑰建立 JWT 持有人權杖，並使用該權杖要求存取權杖。產生的存取權杖會反映服務帳戶的身分，您可以使用該權杖代表服務帳戶與Google Cloud API 互動。

由於私密金鑰可讓您以服務帳戶的身分進行驗證，因此存取私密金鑰就如同知道使用者的密碼。私密金鑰又稱為服務帳戶金鑰。服務帳戶使用的金鑰組分為兩類：Google 代管和使用者代管。

如果管理不當，服務帳戶金鑰可能會帶來安全風險。因此請盡可能選用更安全的驗證替代方案。服務帳戶金鑰的主要威脅包括：

  • 憑證外洩：服務帳戶金鑰可能會不慎儲存在不應儲存的位置。不肖人士可能會使用外洩的服務帳戶金鑰進行驗證，並在您的環境中取得立足點。
  • 權限升級：如果惡意行為人取得安全防護不佳的服務帳戶金鑰，他們可能會使用該金鑰升級權限。
  • 資訊揭露：服務帳戶金鑰可能會不慎揭露機密中繼資料。
  • 不可否認性：透過服務帳戶金鑰進行驗證，並讓服務帳戶代表使用者執行作業，惡意行為者可能會隱藏自己的身分和動作。
  • 惡意憑證設定：惡意行為人可能會提供惡意憑證設定，藉此規避安全防禦措施。

如要盡量降低這些威脅，最佳做法是避免使用使用者管理的服務帳戶金鑰，並盡可能採用其他方法驗證服務帳戶。您也可以使用 IAM 條件和 VPC Service Controls，限制遭入侵的服務帳戶可能存取的資源。

如果無法使用服務帳戶金鑰的更安全替代方案，請參閱本指南，瞭解管理、使用及保護服務帳戶金鑰的最佳做法。

防範憑證外洩

服務帳戶金鑰與使用者名稱和密碼類似，都是一種憑證。如果使用者可以存取有效的服務帳戶金鑰，就能使用該金鑰進行驗證，並存取獲授權的服務帳戶資源。

對不肖人士而言，服務帳戶金鑰的價值甚至高於外洩的密碼。如果使用者帳戶已設定兩步驟驗證和登入身分確認問題，即使有人嘗試使用外洩密碼登入，也不太可能成功。相較之下，使用外洩的服務帳戶金鑰進行驗證可能就會成功，因為服務帳戶不受任何額外的登入驗證限制。

不肖份子可能會在各種位置尋找服務帳戶金鑰，包括：

  • 開放原始碼專案的原始碼存放區
  • 公開 Cloud Storage bucket
  • 遭入侵服務的公開資料傾印

除了公開位置外，不肖人士也可能會在他們入侵的私人位置尋找服務帳戶金鑰。相關例子包括：

  • 電子郵件收件匣
  • 檔案共用區
  • 備份儲存空間
  • 暫時性檔案系統目錄

降低服務帳戶金鑰外洩風險的有效方法，是減少流通的金鑰數量，並避免建立新金鑰。下列各節說明如何限制流通中的服務帳戶金鑰數量，以及其他有助於降低服務帳戶外洩風險的措施。

最佳做法：

提供服務帳戶金鑰的替代方案。
使用機構政策限制，限制哪些專案可以建立服務帳戶金鑰。
請勿將服務帳戶金鑰留在暫時位置。
請勿在使用者之間傳遞服務帳戶金鑰。
請勿將服務帳戶金鑰提交至原始碼存放區。
請勿將服務帳戶金鑰嵌入程式二進位檔。
使用洞察資料和指標找出未使用的服務帳戶金鑰。
輪替服務帳戶金鑰，降低金鑰外洩造成的安全性風險。
使用到期時間，讓金鑰自動到期。
使用機構政策限制，自動停用外洩的金鑰。

提供建立服務帳戶金鑰的替代方案

請確保貴機構使用者瞭解替代方案，並能證明使用服務帳戶金鑰的額外風險和管理負擔合理：

  • 向開發人員說明比服務帳戶金鑰更安全的替代方案
  • 建立程序，協助開發人員在建立新的服務帳戶金鑰前，為自己的用途決定適當的驗證方法。
  • 使用機構政策限制，禁止建立新的服務帳戶金鑰，並僅允許已證明無法使用更安全替代方案的專案例外。

使用機構政策限制，限制哪些專案可以建立服務帳戶金鑰

由於有比服務帳戶金鑰更安全的替代方案，因此最好將使用服務帳戶金鑰視為例外狀況，而非常態。

為避免不必要地使用服務帳戶金鑰，請使用機構政策限制：

  • 在機構的資源階層根層級，套用「停用服務帳戶金鑰建立功能」和「停用服務帳戶金鑰上傳功能」限制，建立禁止使用服務帳戶金鑰的預設設定。

  • 如有需要，請覆寫所選專案的其中一項限制，重新啟用服務帳戶金鑰建立或上傳功能。

如要修改機構政策限制，必須具備 orgpolicy.policy.set 權限。由於「擁有者」(roles/owner) 和「編輯者」角色 (roles/editor) 都不包含這項權限，因此限制條件在非正式環境中也能發揮效用，即使部分主體可能擁有專案的「擁有者」或「編輯者」存取權，也不會受到影響。

請勿將服務帳戶金鑰留在暫時位置

使用 Google Cloud 控制台建立服務帳戶金鑰時，大多數瀏覽器會立即下載新金鑰，並儲存至電腦的下載資料夾。您應立即將金鑰移至要儲存的位置。 請確認您沒有不小心將副本留在電腦的下載資料夾或資源回收筒。

使用 Google Cloud CLI，即可降低服務帳戶金鑰副本意外留在暫時位置的風險：gcloud iam service-accounts keys create 指令可讓您將服務帳戶金鑰檔案直接寫入所需位置。此外，在大多數作業系統上，gcloud CLI 會自動調整檔案權限，確保只有您能存取檔案。

請勿在使用者之間傳遞服務帳戶金鑰

部署需要服務帳戶金鑰的應用程式時，您可能沒有權限自行建立服務帳戶金鑰。您可能需要請其他人為您建立服務帳戶金鑰。

如果有多位使用者參與建立及部署服務帳戶金鑰，金鑰副本就可能留在信箱、即時通訊記錄或其他位置，風險也會隨之提高。如有必要在使用者之間移交存取權，上傳服務帳戶金鑰會更安全：

  1. 以應用程式部署者的身分，在目標電腦上建立使用 RSA 2048 位元金鑰組的自行簽署憑證。如要建立憑證，可以使用 openssl、certutil、New-SelfSignedCertificate 或其他作業系統工具。
  2. 將憑證檔案傳送給有權上傳憑證的使用者，同時將私密金鑰保留在目標電腦上。傳遞憑證時，請確保憑證無法替換或竄改，但不必保密。
  3. 您必須具備管理服務帳戶金鑰的必要權限，才能上傳憑證，並將其與服務帳戶建立關聯。

按照這個程序操作，即可避免傳遞私密金鑰，只在使用者之間交換公開資訊。

請勿將服務帳戶金鑰提交至原始碼存放區

服務帳戶金鑰是憑證，必須防止未經授權的存取。如果將服務帳戶金鑰提交至原始碼存放區，金鑰遭未經授權的使用者和惡意行為者存取的風險就會提高：

  • 惡意行為者可能會掃描公開原始碼存放區的原始碼，找出外洩的金鑰。
  • 日後您可能會決定將私人來源存放區設為公開存放區，但未先檢查是否有金鑰。
  • 其他團隊成員可能會將原始碼副本儲存在工作站。

使用服務帳戶金鑰處理程式碼時，請務必將服務帳戶金鑰與原始碼分開儲存，以免不小心將金鑰提交至原始碼存放區。在許多情況下，您可以在開發期間完全不使用服務帳戶金鑰，並改用個人憑證，進一步降低這項風險。

此外，請設定來源控制系統，偵測服務帳戶金鑰是否遭人意外提交：

請勿在程式二進位檔中嵌入服務帳戶金鑰

服務帳戶金鑰是符合特定模式的字串，即使內嵌在其他檔案或二進位檔中，也能識別出來。如果惡意行為人有權存取二進位檔，就能擷取內嵌在二進位檔中的任何服務帳戶金鑰。

伺服器端應用程式的程式二進位檔可能存放在構件存放區，也可能複製到開發人員工作站，以利進行偵錯。將服務帳戶金鑰與程式二進位檔分開，有助於確保可存取二進位檔的使用者不會間接取得服務帳戶憑證。

  • 如果是工具、電腦程式或行動應用程式等用戶端應用程式，請勿使用服務帳戶。請改為讓使用者透過自己的憑證進行驗證。 舉例來說，您可以使用 OAuth 同意流程。
  • 如果是伺服器端應用程式，請勿將服務帳戶金鑰嵌入二進位檔。請改為將金鑰與應用程式二進位檔分開。

使用指標找出未使用的服務帳戶金鑰

為盡量減少流通的有效服務帳戶金鑰數量，最好在不再需要金鑰時立即停用，並在確定不再需要金鑰時刪除。

如果不確定金鑰是否仍在使用中，可以透過服務帳戶洞察資料和驗證指標檢查金鑰用量：

由於服務帳戶屬於 Google Cloud 專案，因此必須分別追蹤每個專案的洞察資料和指標。

輪替服務帳戶金鑰，降低金鑰外洩造成的安全性風險

雖然您可以降低服務帳戶金鑰遭意外洩漏的機率，但很難完全消除風險。

金鑰輪替是指以新金鑰取代現有金鑰，然後使取代的金鑰失效。建議您定期輪替管理的所有金鑰，包括服務帳戶金鑰。

輪替服務帳戶金鑰有助於降低金鑰外洩或遭竊帶來的風險。如果金鑰外洩，惡意行為者可能要過幾天或幾週才會發現。定期輪替服務帳戶金鑰，可提高遭外洩金鑰失效的機率，避免遭到惡意人士利用。

建立服務帳戶金鑰輪替程序，也有助於在懷疑服務帳戶金鑰遭盜用時迅速採取行動。

如果您自行產生公開/私密金鑰組、將私密金鑰儲存在硬體安全模組 (HSM)，並將公開金鑰上傳至 Google Cloud，則可能不需要定期輪替金鑰。如果您認為金鑰可能遭盜用，可以輪替金鑰。

使用到期時間讓金鑰自動過期

根據預設，您從 IAM 建立及下載的服務帳戶金鑰沒有到期時間，在您刪除金鑰前都會保持有效。為服務帳戶金鑰設定到期時間，可縮短永久憑證的生命週期，進而降低安全性風險。不過，設定到期時間也會帶來其他風險，例如金鑰到期時，工作負載可能會失敗。

需要暫時存取需要服務帳戶金鑰的系統時，請使用有效時間。舉例來說，在執行下列操作時，請使用到期時間：

  • 在非正式環境中開發程式碼，以供只能使用服務帳戶金鑰驗證的應用程式使用
  • 使用只能透過服務帳戶金鑰驗證的第三方工具

在下列情況請避免使用有效期限：

  • 正式環境工作負載。在正式環境中，過期的服務帳戶金鑰可能會導致意外中斷。請改用不會過期的金鑰，並透過金鑰輪替管理金鑰生命週期。
  • 需要永久存取權的非正式環境工作負載，例如持續整合 (CI) 管道。
  • 金鑰輪替系統，可防止金鑰在指定時間後繼續使用。如要瞭解建議的金鑰輪替策略，請參閱服務帳戶金鑰輪替。

如要限制服務帳戶金鑰的有效期限，您可以在專案、資料夾或機構中，為新建立的金鑰設定到期時間。到期時間不適用於現有金鑰。

或者，您也可以上傳服務帳戶金鑰，並在 X.509 憑證檔案中指定「有效期限」。過期後，金鑰就無法用於驗證。不過，在您刪除前，這項設定仍會與服務帳戶建立關聯。

使用機構政策限制自動停用外洩的金鑰

即使您遵循服務帳戶金鑰的所有最佳做法，服務帳戶金鑰仍有可能外洩。

為協助管理外洩的憑證，請確保服務帳戶金鑰外洩因應措施限制設為 DISABLE_KEY。如果將限制設為這個值， Google Cloud系統會自動停用偵測到的任何外洩金鑰。

如果金鑰因外洩而遭到停用，金鑰的中繼資料會新增下列欄位：

  • "disable_reason": "SERVICE_ACCOUNT_KEY_DISABLE_REASON_EXPOSED"： 表示金鑰因外洩而遭到停用。
  • "extended_status": "SERVICE_ACCOUNT_KEY_EXTENDED_STATUS_KEY_EXPOSED""： 表示金鑰曾公開曝光。即使重新啟用金鑰，這個值仍會保留。
  • "extended_status_message": "LINK_TO_EXPOSURE"：如果有的話，中繼資料會包含偵測到金鑰的位置連結，可用於補救。

如果需要減輕服務中斷的影響，可以重新啟用這些金鑰。不過，我們建議您盡快再次停用這些金鑰，因為公開的金鑰會造成安全風險，即使初始公開的金鑰已移除，仍有風險。

如要瞭解管理遭盜用憑證的其他最佳做法，請參閱「處理遭盜用的憑證 Google Cloud」。

防範權限提升

如果服務帳戶金鑰的安全性低於授權存取的資源，使用這類金鑰可能會導致權限提升攻擊。

舉例來說，假設惡意行為人已在您的環境中站穩腳步，現在嘗試存取特定 Google Cloud 資源。他們可能仍缺少存取這些資源的權限，但或許有足夠的權限存取儲存在 VM、檔案共用或其他安全性較低位置的服務帳戶金鑰。如果使用服務帳戶金鑰進行驗證，惡意行為者就能冒用服務帳戶身分。服務帳戶可能會讓惡意行為人存取先前無法存取的資源，進而提升惡意行為人的權限。

由於服務帳戶金鑰會間接授予 Google Cloud資源的存取權，因此您必須將金鑰視為與資源本身同等重要，並盡力保護。

以下各節將說明保護服務帳戶金鑰的最佳做法，以及如何降低未經授權存取和權限提升的風險。

最佳做法：

避免將金鑰儲存在檔案系統中。
使用 HSM 或 TPM 儲存金鑰。
使用軟體式金鑰儲存空間。
請勿將金鑰儲存在 Secret Manager 或其他雲端密鑰儲存空間。
請勿在允許建立或上傳服務帳戶金鑰的專案中使用「編輯者」角色。
避免使用服務帳戶金鑰執行全網域委派功能。

避免將金鑰儲存在檔案系統中

使用 Google Cloud 控制台或 gcloud CLI 建立的服務帳戶金鑰是 JSON 檔案，您可以將這些檔案複製到需要金鑰的電腦檔案系統。但將服務帳戶金鑰儲存為檔案系統中的檔案，可能會導致多種風險，包括：

  • 部分檔案系統 (例如 NTFS) 預設會使用繼承的權限。除非停用，否則新增至上層資料夾的權限可能會導致重要檔案意外開放存取，未經授權的使用者也能查看。
  • 在虛擬化環境中，惡意行為人可能會存取基礎虛擬磁碟，藉此破壞檔案系統安全性。
  • 檔案系統存取權和權限變更通常不會記錄在稽核記錄中。如果檔案權限遭到誤改，導致未經授權的使用者看到金鑰，您可能難以分析這些變更的發生時間和執行者。
  • 惡意人士一旦取得存取權，就能輕易複製檔案並竊取資料。

請盡量避免將服務帳戶金鑰儲存在檔案系統中。如果無法避免將金鑰儲存在磁碟上，請務必限制金鑰檔案的存取權、設定檔案存取稽核，並加密基礎磁碟。

使用 HSM 或 TPM 儲存金鑰

使用 Google Cloud 控制台或 gcloud CLI 建立服務帳戶金鑰時，系統會產生私密金鑰，然後向您顯示。 Google Cloud 服務帳戶金鑰的許多安全風險，都源自於私密金鑰會暫時或永久以純文字形式提供，因此難以保護。

您可以改用硬體安全模組 (HSM) 或可信任平台模組 (TPM) 建立及管理金鑰，不必讓 Google Cloud 產生金鑰配對：

  1. 使用 HSM 或 TPM 產生 RSA 金鑰組。
  2. 使用金鑰組建立自行簽署的憑證。
  3. 上傳憑證做為服務帳戶金鑰。
  4. 允許應用程式使用 HSM 或 TPM 的簽署 API，簽署 JWT 來驗證服務帳戶。

使用 HSM 或 TPM 時，您不必以明文揭露私密金鑰，就能使用該金鑰。因此，使用 HSM 或 TPM 管理服務帳戶金鑰，有助於強制執行存取權控管，同時降低金鑰複製到其他系統的風險。

部分平台提供抽象化功能，讓您不必直接與 TPM 互動，即可善用 TPM。舉例來說，Windows 可讓您搭配使用 CryptoNG API 和 Microsoft Platform Crypto Provider，管理受 TPM 保護的金鑰。

由 TPM 管理的服務帳戶金鑰是實體或虛擬機器的專屬金鑰。您仍可將每部機器的金鑰與共用服務帳戶建立關聯，讓多部機器共用服務帳戶。

使用軟體型金鑰儲存區

如果無法使用硬體式金鑰儲存區，請改用軟體式金鑰儲存區管理服務帳戶金鑰。與硬體式選項類似，軟體式金鑰儲存區可讓使用者或應用程式使用服務帳戶金鑰，而不必揭露私密金鑰。軟體型金鑰儲存解決方案可協助您精細控管金鑰存取權，並確保系統會記錄每次金鑰存取作業。

軟體金鑰儲存空間的安全性通常取決於主金鑰的保護程度。使用軟體型金鑰儲存區前，請務必先查看下列事項：

  • 如何確保主金鑰在閒置時的安全，
  • 解除密封程序的運作方式，以及誰可以啟動程序
  • 如何防止金鑰從記憶體中擷取，
  • 如果惡意行為人取得基礎系統的殼層存取權或管理程序存取權，如何防止金鑰儲存區遭到破壞。

請勿將金鑰儲存在 Secret Manager 或其他雲端密鑰儲存庫

我們不建議使用 Google Cloud的 Secret Manager 儲存及輪替服務帳戶金鑰。這是因為應用程式需要Google Cloud 可辨識的身分，才能存取 Secret Manager 密鑰。如果應用程式已有可辨識的身分，應用程式即可使用該身分進行驗證，而不必使用服務帳戶金鑰。 Google Cloud Google Cloud

其他雲端密鑰管理服務 (例如 Azure KeyVault 和 AWS Secret Manager) 也適用相同概念。如果應用程式已有這些雲端供應商可辨識的身分，應用程式就能使用該身分向 Google Cloud 進行驗證，而不必使用服務帳戶金鑰。

請勿在允許建立或上傳服務帳戶金鑰的專案中使用「編輯者」角色

「編輯者」roles/editor和「擁有者」roles/owner基本角色的主要差異在於，「編輯者」角色無法變更 IAM 政策或角色。因此，您無法輕易擴充自己的存取權，也無法授予其他使用者專案資源的存取權。

如果專案包含服務帳戶，編輯者角色的限制可能會遭到破壞。由於編輯者角色授予建立或上傳服務帳戶金鑰的權限，惡意行為者可以為現有服務帳戶建立新金鑰，並使用這些金鑰提升自己的存取權，或將金鑰交給其他使用者，以取得專案資源的存取權。

建議您使用定義更明確的預先定義角色，或建立只授予必要權限的自訂角色，而不要使用「編輯者」或其他基本角色。

如需使用「編輯者」角色，請停用服務帳戶金鑰上傳和金鑰建立功能，方法是使用組織政策限制，確保「編輯者」角色不會遭到濫用，導致權限提升。

避免使用服務帳戶金鑰執行全網域委派功能

全網域委派功能可讓您模擬使用者身分，存取使用者資料，不必經過使用者手動授權。 雖然說明全網域委派功能使用方式的範例通常會建議使用服務帳戶金鑰，但執行全網域委派功能時無須使用服務帳戶金鑰。

使用全網域委派功能時，請避免使用服務帳戶金鑰，改用 signJwt API：

  1. 請先使用附加服務帳戶、Workload Identity Federation for GKE 或 Workload Identity Federation 驗證服務帳戶。
  2. 建構 JWT，並使用 sub 憑證附加資訊指定要要求委派存取權的使用者電子郵件地址。
  3. 使用 signJwt API 簽署 JWT。
  4. 將簽署的 JWT 傳遞至 OAuth2 權杖資源，以取得存取權杖。

採用這種做法可避免管理服務帳戶金鑰，因此設定程序更簡單安全。

防範資訊揭露威脅

最佳做法：

避免在上傳的 X.509 憑證中揭露機密資訊。

避免在上傳的 X.509 憑證中揭露機密資訊

對於每個服務帳戶金鑰，IAM 可讓您從端點 https://www.googleapis.com/service_accounts/v1/metadata/x509/ACCOUNT_EMAIL 下載 X.509 憑證。這個端點是公開的，不需要驗證。

如果是使用 Google Cloud 控制台或 gcloud CLI 建立的 Google-owned and managed keys 和使用者管理金鑰，系統會自動建立 X.509 憑證，且只包含電子郵件地址和到期日等基本中繼資料。

如果是上傳的服務帳戶金鑰，公開端點提供的 X.509 憑證與您上傳的憑證相同。如果您上傳的憑證包含任何選用屬性 (例如內嵌在通用名稱中的地址或位置資訊)，這些資訊也會公開。詐騙者可能會利用這些資訊進一步瞭解您的環境。

為避免揭露機密資訊，請勿在上傳的 X.509 憑證中新增任何選用屬性，並使用一般 Subject。

防範不可否認性威脅

當您發現可疑活動影響 Google Cloud資源，並想分析其來源時，需要有助於重構導致可疑活動的事件鏈的資料。執行這類分析時，主要資料來源通常是稽核記錄。

如果涉及服務帳戶，分析稽核記錄可能會更加困難。如果活動是由服務帳戶發起，記錄檔項目會包含服務帳戶的電子郵件地址，但您也需要找出當時使用服務帳戶的使用者或應用程式。

以下各節將介紹使用服務帳戶金鑰的最佳做法，協助您追蹤金鑰的使用情況。

最佳做法：

為每個應用程式使用專屬服務帳戶。
為執行應用程式的每部機器使用專屬金鑰。

為每個應用程式使用專屬服務帳戶

所有稽核記錄都包含 principalEmail 欄位，可識別啟動活動的主體。如果您在多個應用程式之間共用服務帳戶金鑰，稽核記錄會包含相同的 principalEmail 值，因此很難判斷是哪個應用程式執行了活動。

請為每個應用程式建立專用服務帳戶，不要在多個應用程式之間共用金鑰。這樣一來，您就能透過 principalEmail 欄位找出與服務帳戶相關聯的應用程式，進而重構導致可疑活動的事件鏈。

為執行應用程式的每部機器使用專屬金鑰

如果您在多部電腦上執行同一個應用程式的多個副本，則 principalEmail 欄位可能可讓您識別應用程式，但無法識別特定活動的來源電腦。

為協助您縮小可疑活動的潛在來源範圍，請為每個應用程式副本建立個別金鑰。這樣一來，您就能使用許多服務新增至稽核記錄的 serviceAccountKeyName 欄位，區分活動的來源機器。

防範惡意憑證設定

部分憑證設定含有網址和檔案路徑，如果工作負載未適當驗證，可能會導致工作負載使用惡意端點。

最佳做法：

請先驗證從外部來源取得的金鑰，再用來向 Google API 進行驗證。

從外部來源取得金鑰後，請先驗證金鑰，再使用金鑰向 Google API 進行驗證

從外部來源接受服務帳戶金鑰時，您必須先驗證金鑰，才能使用。如果您未驗證金鑰，惡意人士可能會使用金鑰，導致工作負載存取惡意端點。

如果系統只接受服務帳戶金鑰，請確認 type 欄位的值為 service_account。

詳情請參閱「使用外部來源的憑證設定時的安全規定」。

後續步驟