服務帳戶安全性簡介
在 GCP 專業雲端安全工程師 (PSE) 的世界中，服務帳戶 (SA) 是最強大也往往是最脆弱的身分。與人類使用者不同，服務帳戶沒有眼睛來識別釣魚連結，也沒有聲音來回報遺失的憑證。它們是自動化的核心動力，如果管理不當，就會成為攻擊者的沈默後門。
強化服務帳戶需要從「靜態憑證」(JSON 金鑰) 轉向「動態身分」(冒充與短期權杖)。本主題涵蓋了非人類身分的生命週期管理、安全性陷阱以及進階強化技術。
白話文解釋
1. 自動駕駛送貨無人機 (服務帳戶)
想像一架自動駕駛的送貨無人機。它沒有飛行員 (人類)，而是擁有一套預先編寫的指令和一個數位 ID，告訴倉庫它被允許領取特定的包裹。如果無人機被偷 (遭到入侵)，它會繼續執行任務，直到它的 ID 被撤銷。
2. 代客泊車鑰匙 (服務帳戶冒充)
當你把車交給代客泊車員時，你不會給他們可以打開後車廂和手套箱的主鑰匙。你會給他們一把「代客泊車鑰匙」，這把鑰匙只能發動汽車並將其移動到停車場。服務帳戶冒充 (Service Account Impersonation) 就像是車主 (使用者) 暫時使用代客泊車鑰匙的身分來移動車輛，而不是隨身攜帶這把實體鑰匙。
3. 自動銷毀的訊息 (短期憑證)
想像一個關鍵任務密碼，它只在 60 分鐘內有效，然後就會自動更改。即使攻擊者在第 59 分鐘偷走了它，他們也只有 60 秒的存取時間。這就是短期憑證 (Short-lived Credentials) 相對於靜態 JSON 金鑰的力量。
服務帳戶的類型
瞭解帳戶是由誰管理的，對於安全性稽核至關重要。
使用者管理的服務帳戶 (User-Managed Service Accounts)
由你在專案中建立。
- 命名格式：
[email protected]。 - 控制權： 你負責管理金鑰和 IAM 角色。
Google 管理的服務帳戶 (Google-Managed Service Accounts)
由 Google 建立並管理，以便各項服務之間進行互動。
- 命名格式：
[email protected]或服務特定格式，如[email protected]。 - 控制權： 你無法為這些帳戶建立金鑰；Google 會負責更換金鑰。
服務帳戶 (Service Account) 是一種特殊的 Google 帳戶，旨在代表需要進行身分驗證並獲得授權以存取 Google API 資料的非人類使用者。
管理與更換服務帳戶金鑰
JSON 金鑰是主要的安全性風險。如果你「必須」使用它們，更換金鑰 (Rotation) 是強制性的。
靜態金鑰的危險
- 無 MFA： 金鑰會繞過多重身分驗證。
- 難以追蹤： 一旦下載，你不知道金鑰被存放在哪裡 (GitHub、Slack、本地硬碟)。
- 無限效期： 預設情況下，金鑰的有效期長達 10 年。
金鑰更換策略
- 自動化： 使用 Cloud Functions 每 90 天更換一次金鑰。
- 重疊期： 產生新金鑰，更新應用程式，然後在冷卻期過後刪除舊金鑰。
PSE 的建議是完全消除金鑰，轉而使用工作負載身分 (Workload Identity) 或冒充 (Impersonation) 機制。
服務帳戶冒充 (Service Account Impersonation)
冒充機制允許主體 (使用者或另一個服務帳戶) 在不需要金鑰的情況下，以目標服務帳戶的身分執行操作。
運作方式
使用者為服務帳戶請求一個短期的 OAuth 2.0 存取權杖 (Access Token)。
- 必要權限：
iam.serviceAccounts.getAccessToken。 - 角色：
roles/iam.serviceAccountTokenCreator。
優點
- 無需金鑰管理： 沒有 JSON 檔案外洩的風險。
- 可稽核性： 記錄會顯示具體是「誰」請求了權杖來冒充該服務帳戶。
針對地端或多雲工作負載，PSE 情境會優先選擇 Workload Identity Federation 而非下載 JSON 金鑰：外部工作負載提出 OIDC 或 SAML 權杖，GCP Security Token Service (STS) 會將其交換為繫結到 roles/iam.serviceAccountTokenCreator 的短期 OAuth 2.0 存取權杖。搭配 iam.disableServiceAccountKeyCreation 組織政策，便能達成考試始終偏好的無金鑰架構，而非依賴定期更換 JSON 金鑰。
強化服務帳戶權限
嚴格執行最小權限原則 (PoLP)。
常見陷阱
- 使用預設服務帳戶： 「Compute Engine 預設服務帳戶」預設被授予「編輯者 (Editor)」角色。這是一個巨大的安全性漏洞。
- 權限過大： 當服務帳戶只需要讀取一個檔案時，卻授予了
roles/storage.admin。
最佳實務
- 禁用預設服務帳戶： 始終為你的虛擬機器建立自訂服務帳戶。
- 授予資源級別的存取權限： 將服務帳戶角色繫結到特定的儲存桶或資料集，而非整個專案。
服務帳戶使用者 vs. 權杖建立者
這兩個角色在 PSE 考試中經常被混淆。
- 服務帳戶使用者 (
roles/iam.serviceAccountUser)： 允許使用者將服務帳戶「附加」到資源 (如虛擬機器或 Cloud Function)。它不允許他們直接產生權杖。 - 服務帳戶權杖建立者 (
roles/iam.serviceAccountTokenCreator)： 允許使用者「冒充」帳戶並產生權杖。這是一個權限極高的角色。
將 serviceAccountUser 授予開發人員後，他們就可以在虛擬機器上以該服務帳戶的身分執行程式碼，這實際上賦予了他們該服務帳戶的所有權限。
禁用服務帳戶金鑰建立
為了加強安全性，你可以在組織級別阻止使用者建立金鑰。
組織政策限制 (Organization Policy Constraints)
iam.disableServiceAccountKeyCreation： 防止任何人建立新的 JSON 金鑰。iam.disableServiceAccountKeyUpload： 防止使用者將外部金鑰上傳到 Google Cloud。
對所有正式環境專案強制執行這些限制，迫使開發人員使用冒充或工作負載身分機制。
稽核服務帳戶使用情況
誰在使用服務帳戶？
啟用 IAM 的資料存取稽核記錄 (Data Access Audit Logs)。這將記錄每次產生權杖或使用金鑰的操作。
服務帳戶推薦工具 (Service Account Recommender)
與 IAM Recommender 類似，此工具會識別 90 天內未使用的服務帳戶，並建議禁用或刪除它們。
跨專案服務帳戶存取
服務帳戶可以在其建立所在的專案之外獲取角色。
- 集中化身分管理： 在「安全中心 (Security-Hub)」專案中建立所有服務帳戶，並在「正式環境 (Prod)」專案中授予它們角色。
- 信任邊界： 請務必小心！「安全中心」專案若遭到入侵，可能會影響所有相關專案。
預設服務帳戶及其風險
Compute Engine 預設服務帳戶
- 角色： 編輯者 (預設情況下)。
- 風險： 任何擁有「Compute Instance Admin」權限的使用者都可以建立虛擬機器、附加此服務帳戶，並成為整個專案的編輯者。
App Engine 預設服務帳戶
- 角色： 編輯者。
- 強化措施： 切換到權限最小的自訂服務帳戶。
服務帳戶管理的 CLI 指令
建立服務帳戶
gcloud iam service-accounts create my-hardened-sa \
--display-name="Production Web Server SA"
授予冒充存取權限
gcloud iam service-accounts add-iam-policy-binding \
[email protected] \
--member="user:[email protected]" \
--role="roles/iam.serviceAccountTokenCreator"
列出金鑰 (尋找舊金鑰)
gcloud iam service-accounts keys list \
[email protected]
iam.serviceAccounts.actAs 權限是 roles/iam.serviceAccountUser 角色的一部分，是在部署使用服務帳戶的資源時所必需的。
PSE 安全性最佳實務
- 刪除預設服務帳戶： 如果無法刪除，請撤銷其角色。
- 對 GKE 使用工作負載身分： 切勿將 JSON 金鑰掛載到 Pod 中。
- 每月稽核： 識別金鑰效期超過 90 天的服務帳戶。
- 優先考慮身分而非範圍： 不要依賴「存取範圍 (Access Scopes)」(這是虛擬機器權限的舊方法)；請使用 IAM 角色。
故障排除場景
場景：開發人員無法部署 Cloud Function。
診斷： 開發人員擁有 "Cloud Functions Developer" 權限，但在執行階段服務帳戶上缺少 iam.serviceAccounts.actAs 權限。
修正： 為該特定服務帳戶授予開發人員 roles/iam.serviceAccountUser 角色。
場景：在公開的 GitHub 儲存庫中發現了服務帳戶金鑰。
診斷： 帳戶立即遭到入侵。 修正：
- 在 Google Cloud 主控台中刪除該金鑰。
- 撤銷所有作用中的工作階段。
- 稽核過去 24 小時內該服務帳戶執行的所有操作記錄。
- 更換該服務帳戶可存取的所有機密資訊 (例如資料庫密碼)。
PSE 考試場景
場景 1：無金鑰架構
「你的公司希望轉向零信任架構，磁碟上不儲存任何靜態憑證。你如何讓地端伺服器通過 BigQuery 的驗證？」 答案： 使用工作負載身分聯合 (Workload Identity Federation)，將地端 OIDC/SAML 權杖交換為 Google Cloud 的短期權杖。
場景 2：限制服務帳戶建立
「如何確保整個組織中只有安全團隊可以建立服務帳戶？」
答案： 設定組織政策來限制服務帳戶的建立，並從所有其他使用者中移除 roles/iam.serviceAccountAdmin 角色。
常見問題 (FAQ)
Q1：每個專案最多可以有多少個服務帳戶？ A1：預設為 100 個 (可透過配額申請增加)。
Q2：我可以恢復已刪除的服務帳戶金鑰嗎？ A2：不行。一旦金鑰被刪除，它就永久消失了。你必須產生一個新的金鑰。
Q3：服務帳戶有密碼嗎？ A3：沒有。它使用 RSA 金鑰對 (JSON 金鑰) 或權杖進行身分驗證。
總結檢查清單
- 列出使用預設服務帳戶的風險。
- 解釋
服務帳戶使用者與權杖建立者之間的區別。 - 描述服務帳戶冒充的流程。
- 識別兩個有助於強化服務帳戶的組織政策。
- 解釋為什麼短期憑證優於 JSON 金鑰。