【東東老師 X 思想科技】使用 GCP Service Account 開發程式的小技巧

上次在 《GCP 的 Cloud IAM – 角色與權限控管介紹》有提到 Service Account ，這次我們從開發人員的角度，來分享在開發程式過程當中，使用 Service Account 的一些技巧和注意事項。

一、Service Account 簡介

在 GCP 各種底層運作當中，有很多會代替我們人類執行的服務，例如 Compute Engine 的虛擬機器，這些服務要動起來，就要給它們一個身份，就是  Service Account，並且要讓它們有權限存取其他服務，例如 Cloud Storage 或 BigQuery，就要在 IAM 授予角色給 Service Account。

從開發的角度來說，Service Account 就是程式專用的帳戶，代表程式本人的身份。重點是，程式是 24 小時全年無休在跑的，它操作 GCP 的次數遠遠超過我們人類，所以管理好 Service Account 很明顯是更為重要的。

和人類的帳號不同的是，Service Account 是沒有密碼的，它是放在程式裡使用，典型的方法就是產生 Service Account Key，它是一個 Json 文字檔，上面記錄 Service Account 所在的 GCP 專案、Key 的 ID、Key 本身 RSA 2048 的值（可視為密碼）等等。

我們會在程式碼裡指定 Key 的存取位置，但通常我們不會把 Key 直接放在程式碼當中（太危險了），而是去外部某個安全的地方讀取到 Key，就可以去呼叫 GCP 上的各項服務。

重點就在這裡，一個 Service Account 可以生成很多 Key，而這些 Key 都被使用者下載到各處，或直接存到主機的某個地方，反而增加了帳戶被盜的風險。

萬一權限設定太大，而 Key 又被拿走，就像你的帳戶被盜，駭客可以在你的專案環境建立大量機器做為殭屍電腦，或是挖礦，一開就是幾千幾萬台，導致你在幫駭客支付 GCP 的費用。

因此 Service Account 和 Key 務必好好保管，以免遭有心人士濫用。

二、使用 Service Account 的小技巧

以下我們依照系統開發的流程，來逐步說明使用 Service Account 的小技巧。

(一) 系統設計階段的最佳安全實務

1. 充分利用 GCP 內建的身份驗證機制 

(1) 在 GCP 內部運行的資源

針對運作應用程式的服務如 Compute Engine、App Engine 和 Cloud Run，一定要為它們設定專屬的 Service Account。

首先 Service Account 在這些服務當中運作，不需要產生 Service Account Key 去跟其他 GCP 服務互動，光是這一點，就直接免除了金鑰外洩的風險。

而由於像 Compute Engine 和 App Engine 預設的 Service Account 具有 Editor 角色，權限非常大，所以才要另外設定專屬的 Service Account，並且給它們設定「最小且必要的權限」，就是所謂最小權限原則 （Principle of Least Privilege），即使該服務被盜用，也能透過權限來限制它的活動範圍，降低駭客入侵帶來的破壞。

而且每個服務用各自的 Service Account ，可以確保每一支程式都是隔離運作的，萬一有個服務遭到入侵，也不會影響到其他服務的正常運作，避免「牽一髮而動全身」的風險。

(2) 容器化環境的解決方案

Google Kubernetes Engine (GKE) 提供 Workload Identity Federation for GKE。讓 Kubernetes 服務帳號能夠無縫地對應到 GCP 服務帳號，帶來極大便利。

透過這種方式，容器化應用程式可以直接使用 GCP 的各種服務，而不需要在系統中儲存 Service Account Key。簡化了權限管理流程，也顯著提升了系統的安全性，為開發者和維運人員提供了一個更加方便且安全的雲端運算環境。

(3) 在 GCP 外部的系統中的創新方法

同上 Workload Identity Federation 不只用於 GKE，也能讓不在 GCP 內部的系統也能輕鬆存取 GCP 資源。

這項功能讓在 AWS、Azure 或是公司自己機房的應用程式，可以使用它們原本的身份認證機制來存取 GCP 的各種服務，不需要額外管理和儲存 GCP 的 Service Account Key。

這樣的設計大幅減少了在多雲環境下管理憑證的複雜度，讓跨雲服務的整合變得更加簡單安全。

綜合以上三種解決方法，你可以看出來，就是盡量不使用到 Service Account Key，間接地減少金鑰外洩的風險。

2. 建立清晰的 Service Account 策略

(1) 了解各種身份驗證選項的優缺點

A. 從應用程式連接 GCP 各項服務

你可以設定「應用程式預設憑證」(Application Default Credentials；ADC)，然後使用對應的程式語言函式庫，這是最常見的開發方式，適合大多數應用程式開發。

B. 需要使用 ID Token 的情況

ADC 主要是證明「這個應用程式有權限使用 Google Cloud 資源」，但不知道身份，ID Token：主要是證明「這個人/使用者是誰」，包含使用者身分資訊。當你需要使用者層級的身分驗證，不只是「應用程式有權限」而已。

C. 實作使用者身份驗證

當你需要讓你的應用程式的使用者能夠登入並存取 Google 服務，可以查看這份文件，裡面有不同方式的比較。

D. 在本機環境試用命令列（Command Line）工具

你可以在自己電腦上安裝 gcloud CLI，輸入驗證的指令並確認身份後，就可以輸入各種指令來操作各項 GCP 的服務和資源。

E. 在本機環境測試 API

你不需要特別準備一個寫程式的環境，你可以直接用像是 curl 的指令來呼叫 REST API。

F. 測試 GCP 官網提供的範例程式碼

你可以在本機設定 ADC 憑證，並安裝相關的客戶端函式庫（ Client Library），客戶端函式庫會自動找到你的憑證，讓你能直接執行程式碼。

在 GCP 的官方文件中，已經整理好各種身分驗證的相關說明，你會發現有很多情況不一定要使用 Service Account 和 Key。

(2) 建立評估流程

為特定情境選擇最合適的身份驗證方式，可以參考這個流程，你一樣會發現，在判斷的過程當中，很多情境都不一定要用到 Service Account，真的是沒有其他辦法了，才用 Service Account。

(3) 使用機構政策 (Organization Policy) 

Organization Policy 提供了管理 Service Account 和 Key 的多種政策控制如下：

• iam.disableServiceAccountCreation – 禁止在專案中創建新的 Service Account
• iam.disableServiceAccountKeyCreation – 禁止為服務帳戶創建新的 Service Account Key
• iam.disableServiceAccountKeyUpload – 禁止上傳外部生成的 Service Account Key
• iam.serviceAccountKeyExpiryHours – 強制設定 Service Account Key 到期時間
• iam.allowedPolicyMemberDomains – 限制可以被授予 IAM 角色的帳號所屬的網域，包括服務帳戶的網域。

使用機構政策做到了幾件重要的事情：它們防止人們亂建立沒人監控的服務帳戶，這樣可以避免資源使用混亂。

它們也限制 Key 的建立，並要求定期更換 Key，大幅降低了 Key 被盜用的風險。這些工具還讓管理員能清楚看到誰在用什麼服務帳戶、有什麼權限，確保公司符合各種規定。

最重要的是，這些政策幫助確保只有真正需要的服務帳戶會被建立，減少了可能被攻擊的地方。你可以根據不同部門或專案的需求，靈活設定這些規則的嚴格程度，既保障安全又不會妨礙正常工作。

(二) 開發與測試階段技巧

1. 使用專屬的 Service Account 提高可觀察性

為每個應用程式建立獨立的服務帳戶，並分配最小權限。

你甚至可以在不同環境的應用程式中，都使用不同的服務帳號，讓環境的隔離做得更為徹底，就不會發生一台機器中毒，然後感染整個環境的狀況。 

另外一個好處是，當你查看稽核記錄（Audited Logs）時，可以通過「principalEmail」欄位追蹤到每一個 Service Account 到底訪問過哪些資源，或是操作過哪些 API，確保他們沒有濫用權限，或訪問不該訪問的地方，大為提高了 Troubleshooting 的效率。

這樣做有幾個重要好處，首先它能幫助您清楚區分不同應用程式的活動，讓監控和管理變得更加簡單。

此外，還能幫助你進行更精確的權限控制，讓每個服務只擁有它所需的最小權限，從而減少安全風險。如果一個服務帳戶被入侵，受影響的範圍也會被限制在該服務的權限內，不會危及整個系統。

2. 安全地建立與傳送金鑰

(1) 使用命令列工具創建金鑰的技巧 

在 GCP 中建議使用命令列工具來提高安全性，就是下達 gcloud 指令，直接將 Key 檔案寫入指定的位置：

gcloud iam service-accounts keys create 

這種方法的好處是，系統會自動設置適當的檔案權限，提高了金鑰的安全性。這比手動下載金鑰檔案更安全可靠，也減少了人為錯誤的可能性，像是 Key 到處亂放、甚至被盜取的情況。

(2) 在團隊間安全傳送憑證的新方法 

傳統上，我們是直接把 JSON 金鑰檔案通過電子郵件、聊天工具（如 Line 或Slack）或雲端硬碟分享等方式將檔案傳送給別人。

這樣會增加了洩露的風險，同一個金鑰檔案可能同時存在多個地方，甚至大家傳來傳去，過程中複製越多份，存放的地方越多，越有可能被有心人士取得。

萬一金鑰被盜，你也沒有辦法追蹤到底是誰手上的那一個金鑰被盜。這樣的話，管理員只能直接停用這個金鑰，這樣也會導致要使用同一個金鑰的人全部都不能用，相關的程式全部都停止運作，你必須重新建立金鑰，然後再次發送給各位，非常麻煩。

你可以採用一種創新的自簽證書方法，這比傳統方式更安全。

具體做法是：首先在需要使用 Service Account 的目標主機上創建 RSA 2048 位的金鑰對和自簽證書。

建立私鑰：

openssl genrsa -out private-key.pem 2048

使用私鑰創建公鑰證書請求： 

openssl req -new -key private-key.pem -out cert-request.csr

根據系統提示來填寫國家名稱、城市、公司名稱、單位名稱、服務名稱和電子郵件地址。

生成自簽證書（有效期 365 天）：

openssl x509 -req -days 365 -in cert-request.csr -signkey private-key.pem -out public-cert.pem

開發人員只需要傳遞公開的證書檔案（public-cert.pem）給 GCP 管理員，這部分無需保密，可以透過一般的溝通管道分享。

然後，管理員將這個公開證書上傳並綁定到對應的 Service Account：

gcloud iam service-accounts keys upload public-cert.pem –iam-account=[email protected]

運作流程如下圖：

這種方法的最大優點是完全不需要傳遞私鑰，因為私鑰始終保留在原始機器上，大幅降低了憑證洩露的風險，同時保證了開發人員和主機能夠安全地使用 Service Account。

到這裡你可能會想到一個問題，上面提到的原始機器，不就是 Compute Engine 的虛擬機器嗎？Compute Engine 在呼叫 GCP 服務時，本來就不需要使用 Service Account Key 啊，這樣做有什麼意義嗎？不是多此一舉？

對的， Compute Engine 本來就不用 Service Account Key，這個自簽證書的機制主要是針對「外部環境」設計的，例如：

• 本機開發環境：開發人員在自己的電腦上進行開發時需要存取 GCP 資源
• 其他雲端平台的機器：例如在 AWS、Azure 或阿里雲上運行但需要存取 GCP 服務的應用
• 自有機房中的主機：公司內部數據中心的機器需要與 GCP 服務整合
• CI/CD 管道：在 Jenkins、GitHub Actions 等持續整合 (Continuous Integration) 環境中需要存取 GCP
• 第三方服務：需要整合到 GCP 的外部 SaaS 解決方案

(3) 善用過期時間設置

前面提到的 Organizatino Policy，設定的是「所有 Service Account Key」統一的有效時間，而每一個 Service Account Key 本身，都可以單獨設定到期時間。

前者會設定長一點，例如三個月或六個月，做為所有 Key 的最低要求，後者則是會視情況設定較短的到期時間，可能只有 7~30 天，因為它的掌控程度較高，萬一到期再建立新的 Key 就好了。

我們可以為開發和測試環境的 Service Account Key 設定合理的過期時間，自動讓不再需要的 Key 失效，減少後續管理工作，即使金鑰被有心人士取得，它也失去了作用。

(三) 部署與生產環境技巧

1. 優化 Service Account Key 的存儲方式

(1) 硬體安全解決方案

使用硬體安全模組（Hardware Security Module；HSM）或可信平台模組（Trusted Platform Module；TPM）來管理您的金鑰可以大幅提升安全性。

A. 硬體安全模組

關於 HSM，你可以購買專用的設備，價格為幾千到幾萬元不等，然後將此設備連接到伺服器上（不一定是 GCP 的虛擬機器）。 HSM 設備通常會提供的管理工具，使用跟上述類似的方法建立 RSA 金鑰對和公開的自簽證書，再上傳到 GCP 綁定 Service Account Key。

程式要準備呼叫 GCP 的 API 時，會先呼叫 HSM 廠商提供的 API，發送資料跟 HSM 索取簽名，簽名就是要向 GCP 證明這個 Request 是合法的，簽名結果再返回程式，程式再將原始資料和簽名結果一起發送到 Google Cloud API。

其實，你不一定要額外購買 HSM 設備，Cloud Key Management Service (Cloud KMS) 也有 HSM 的功能，這是一種由 Google 管理的硬體安全模組服務，符合 FIPS 140-2 Level 3 安全標準，這樣你就不需要購買實體 HSM 設備。

GCP 使用之前儲存的公鑰，來驗證簽名是否真的由對應的私鑰生成。只有當簽名驗證成功時，GCP 才會認為這是來自授權 Service Account 的合法請求。

這樣做有幾個好處：

• 即使有人攔截了請求和簽名，也無法使用這些資訊生成新的有效請求，就是駭客無法產生新的並且合法的 Request 來呼叫 GCP 的 API。
• 只有 HSM 中的私鑰才能生成 GCP 可以驗證的有效簽名，是一個唯一可以信任的來源。
• 主機和應用程式不一定都要在 GCP 內，但如果都在 GCP 內部，必定更為安全。
• 每個請求的簽名都是獨特的，防止重放攻擊（Replay Attack），指的是駭客使用一模一樣的資料去操作 GCP。

B. 可信任平台模組 (TPM)

大多數電腦（特別是 2016 年後製造的）通常已內建 TPM 2.0 晶片在主機板上。如果沒有內建 TPM，你就要購買一個 TPM 模組並安裝到主機板上。

這些模組通常是小型電路板，可以插入主機板上專門的 TPM 插槽。然後在 Linux 上，使用 tpm2-tools 工具集來產生金鑰。

以 Debian 為例，您可以安裝 tpm2-tools 後執行：

ls /dev/tpm*

如果顯示 /dev/tpm0 或 /dev/tpmrm0，通常表示系統已識別到 TPM 設備：

安裝 tpm2-tools 的相關指令如下（不同作業系統版本，指令可能會有所不同）：

更新套件列表：

sudo apt update

安裝 TPM2 工具和資源庫：

sudo apt install tpm2-tools tpm2-abrmd libtss2-dev

安裝後重啟電腦，進入 BIOS/UEFI 設定，尋找 「Security」或「Advanced」選項，啟用 「TPM」，然後重啟電腦。

接下來建立「主要金鑰」（Primary Key），它是 TPM 中所有其他金鑰的根源。

tpm2_createprimary -C o -g sha256 -G rsa -c primary.ctx

然後使用之前創建的主要金鑰來創建一個子金鑰對：

tpm2_create -C primary.ctx -u key.pub -r key.priv

將金鑰載入 TPM：

tpm2_load -C primary.ctx -u rsa.pub -r rsa.priv -c rsa.ctx

將公鑰轉換為 PEM 格式（是 GCP 可接受的格式）：

tpm2_readpublic -c rsa.ctx -o rsa.pem -f pem

使用 OpenSSL 指令創建自簽名證書：

openssl req -new -x509 -key tpmkey -out cert.pem

接下來就可以將 rsa_cert.pem 上傳到 GCP Service Account。

最後程式在運作時，就可以使用以下指令，對要簽名的資料（例如 data.txt）來執行「簽名」：

tpm2_sign -c rsa.ctx -g sha256 -o signature.bin data.txt

另外注意程式需要能夠呼叫 TPM 指令，這需要使用 tpm2-tss 等程式庫進行開發。而且電腦必須保持開機狀態才能使用這些金鑰，因為私鑰無法從 TPM 中導出。

這樣一來，應用程式只需要使用 HSM/TPM 提供的簽名 API，而不必直接接觸私鑰。這種方法提供了硬體層級的安全保障，有效防止金鑰被複製或提取，大幅降低了資安風險。

(2) 軟體金鑰庫的實用技巧

如果你要使用軟體金鑰庫來儲存 GCP Service Account Key，在 GCP 中可以使用 Secret Manager 來儲存，以下是幾個具體的實作方法：

A. 設定精細的存取控制

• 為 Secret Manager 的使用者，設定最小 IAM 角色權限。
• 建立 Secret，然後把 Service Account 放在 Secret 裡面。
• 為不同團隊或服務建立專用的存取群組，例如讓開發團隊只能存取開發環境的 Secret。

• 為不同環境創建不同的 Key，例如 service-account-key-dev 和 service-account-key-prod，然後為每個 Key 設定不同的存取權限，你也可以或使用不同專案隔離環境，每個專案中有各自的 Secret Manager 和 Key。

B. 詳細記錄所有使用情況：

為了追蹤每個 Key 在 Secret Manager 被存取的狀況，你可以啟用 Cloud Audit Logs 來追蹤，因為根據預設，Secret 的存取是不會主動記錄的。你要去稽核記錄把它打開：

我們可以故意測試一下，在 Secret Manager 建立一個 Secret 之後，再用 gcloud 指令去讀取它。

你看到我執行了兩次讀取 Secret 的指令，因為當我第一次執行完後，出了「Hello」這個值，但我還沒馬上截圖，結果「Hello」這個值就消失了，所以我又再執行了一次，並且馬上截圖，可見 Secret 即使透過 gcloud 指令操作，也會顧及安全性，只顯示幾秒鐘。

接著就可以在 Cloud Logging 的「已稽核的資源」看到 Secret 被存取的時間和操作人員。

因為稽核記錄的儲存是有期限的，如果想要長期保存 Secret 的存取記錄，你可以設定 Log Export 到 BigQuery 或 Cloud Storage。

另外，你也可以針對 Secret 的存取記錄，建立 Log-Based Metric 監控指標，這樣就可以把 Secret 的存取次數畫在儀表板上，如果有存取異常，例如某個 Secret 平均一分鐘大概存取 5 次，突然變成 500 次，很明顯就是異常，就可以再設定快訊，來及時通知管理員。

C. 加再一層 Cloud KMS 確保主金鑰的安全

你可以在建立 Secret 時，選擇 CMEK (Customer-Managed Encryption Keys) 功能，使用 Cloud KMS 來的金鑰來加密你建立的 Secret，這樣你的金鑰，除了要有 Secret Manager 的權限角色，又同時要有 KMS 的權限角色，才能夠存取到 Secret 裡的金鑰，等於是雙重保護。

你還可以定期輪換加密金鑰，建議每 90 天一次。這樣除了你的 Service Account Key 能夠定期輪換，KMS 的 Key 也定期輪換，這樣能讓金鑰被竊取所造成的風險降到最低。

D. 實施防止未授權存取的機制

VPC Service Control 是 GCP 中最嚴格的安全功能，能夠限制哪些 API，只能從哪裡進來存取，以及資料只能輸出到哪裡。 例如你可以設定 Service Controls 限制只有公司網路才能存取 Secret Manager。

即使 Secret Manager 是軟體功能，但是當它與其他 GCP 安全功能結合使用時，還是可以在各種資安功能互相搭配之下，給予完善的保護，有效降低憑證洩漏的風險。

2. 高效追蹤 Service Account 使用情況

你可以使用 Cloud Logging 設定查詢語法，來識別過去 90 天是否有未使用的 Service Account。

在 Cloud Monitoring 中設置監控金鑰身份驗證事件指標，然後針對指標設定快訊，例如某一個 Service Account 每天不會用來呼叫某 API 超過 1000次，若超過就發出快訊通知。這能幫助您了解 Service Account 的使用模式和頻率，從而識別異常行為。

每個 Service Account 都有一個「指標」分頁，可以快速查看基本用量資訊，你可以直接從這裡找到要監控的指標，然後設定快訊，就不用去 Metrics Explorer 大海撈針尋找指標。

3. 外部整合的最佳實務建議

(1) 安全使用外部來源的憑證

當您需要從外部來源取得 Service Account Key 時，建立一個嚴謹的驗證流程非常重要。首先，您應該確保憑證的來源是可信的，例如大家統一都從 Secret Manager 取得 Key，而非透過 Line 或 Email 來傳送，避免使用來歷不明的金鑰檔案。

因為駭客雖然沒那麼容易偽造 Key，但 Key 被駭客取得後，修改其中某些欄位（如重新導向或添加惡意程式碼）但保留核心加密部分，都有可能對你的系統或 GCP 環境造成破壞。

所以每次收到或使用 Service Account Key 檔案時，都應該檢查其 JSON 格式中的 “type” 欄位值是否確實為 “service_account”，並且確認 Service Account 的電子郵件是否具有正當的權限，再確認這個 Key 是否能夠從 GCP 獲取令牌。這些檢查步驟都能幫助您確認您使用的是正確的憑證類型，而非其他類型的金鑰或偽造的檔案。

(2) 全網域授權的高效方法

GCP 提供了一種更安全、更簡潔的方式來進行服務授權，不需要使用傳統的 Service Account 金鑰。這種方法利用 signJwt API，可以為全網域提供高效的授權機制。

什麼是 signJwt？

想像你需要寄一封非常重要的信，你想確保收信人知道這封信確實是你寄的，而且信的內容沒有被人竄改。在數位世界中，signJwt 就像是一種特殊的「數位簽名」服務，幫你在重要文件上蓋上無法偽造的印章。

首先使用 Service Account 或 Workload Identity Federation 進行身份驗證。就像在公司大樓，你不用自己帶鑰匙，而是在前台登記後由保全確認你的身分。這樣可以避免直接管理和存儲敏感的金鑰文件。

然後建立一個 JSON Web Token (JWT) 做為「數位通行證」，它包含實際的資訊，例如誰可以讀取特定資料、這個權限何時過期等，這個 JWT 將作為授權請求的基礎。

接著把這封「未簽名」的 JWT 內容送到 Google 的 signJwt 服務，說：「請幫我在這份文件上簽名。」

Google 會確認你有權請求這項簽名服務，使用只有 Google 知道的特殊私鑰，再依據你信件的內容產生一個獨特的數學計算結果（簽名），然後把這個簽名附在你的信件上，形成一個完整的已簽名 JWT。

最後把它送給 Google 的授權服務，換取一個臨時的「存取令牌」，其他 Google 服務看到這個令牌時，會使用 Google 的公鑰驗證簽名。如果簽名有效，且內容顯示你有權限，服務就會允許存取。

這種方法減少了安全風險，因為你不需要下載、發佈或管理 Service Account Key 的檔案。同時簡化了授權流程，使整個過程更加高效和易於維護。對於需要在多個服務或整個網域中進行授權的場景，這是一個特別有價值的解決方案。

你可能會擔心，看起來流程很長，會不會來回很花時間或吃效能？

其實 GCP 的這些服務都經過高度優化，大部分步驟在 GCP 的基礎設施上執行得非常快速。而且這個流程只有在第一次次建立連接或每次令牌過期時才需要執行。

存取令牌一旦獲取，通常可以使用幾個小時（典型設定為 1 小時），不需要每次請求都重新執行整個流程。整個步驟加起來通常只需數百毫秒完成，所以在實際執行時，效能影響是很有限的，卻因此提升很高的安全性。

(四) 維護與治理技巧

1. 金鑰輪替的最佳策略

(1) 制定有效的輪替計劃

如上述提到，就像定期更換家中門鎖一樣，即使目前沒有安全問題，定期的更新也能防範潛在威脅。建議每隔 90 天進行一次金鑰輪替，這樣即使某個金鑰被洩露，其可用時間也會受到限制。在實際操作中，可以通過 GCP 控制台或使用 gcloud 指令來創建新金鑰並廢棄舊金鑰。

為了減少人為錯誤並確保輪替流程的一致性，建立自動化的金鑰輪替機制非常重要。您可以利用 Cloud Functions 配合 Cloud Scheduler 來定期觸發金鑰輪替流程，或者使用 CI/CD Pipeline 來管理這一過程。自動化不只是輪替，還能將新的金鑰自動部署到相關服務，減少服務中斷或人為操作錯誤。

對於儲存在 HSM 中的高敏感度金鑰，需要制定更嚴格的輪替策略。這些金鑰通常用於加密重要資料或簽署關鍵交易，因此建議為 HSM 金鑰設定更短的輪替周期，例如 30～60 天。

(2) 高效管理未使用的金鑰

如前面提到，你可以用 Cloud Logging 設定查詢語法，來識別過去 90 天是否有未使用的 Service Account，並且設定 Cloud Monitoring 監控指標， 顯示各金鑰的使用頻率，幫助您快速發現那些閒置的金鑰。

這個動作最好建立成一個 SOP，每月或每季度對所有 Service Account Key 進行全面審查。你可以使用標籤系統來標記不同狀態的金鑰，如「活躍」、「待觀察」或「待刪除」。同時，確保審查結果有明確的記錄和後續行動，避免重複工作或遺漏重要金鑰。

在移除未使用的金鑰時，不要急於刪除，而是先將其停用。停用後，觀察一段時間（通常為 7～14 天），確保沒有任何系統依賴這些金鑰。等到確認都沒問題，再執行刪除操作。這種「先停用再刪除」的方法能夠減少因誤刪而導致的系統中斷。

2. 機構層級（Organization Level）的管理建議

(1) 有效利用機構政策

管理員應在機構層級設定預設的限制條件，同時也為特殊需求的設定例外政策。例如「iam.disableServiceAccountKeyCreation」，預設禁止所有專案建立 Service Account 金鑰，但為開發環境或特定整合需求的專案設置例外。

還有透過條件表達式，如「resource.name.startsWith(“projects/dev-“)」，可以僅允許名稱以「dev-」開頭的開發專案建立金鑰，實現更靈活的控制機制，確保安全政策既嚴謹又不妨礙業務運作。

(2) 角色與權限的最佳配置

盡量避免使用過於寬鬆的 Editor 角色，而改用更精細的預定義角色（Predefined Roles）。例如為負責 CI/CD 的 Service Account 分配「Cloud Build Service Agent」和「Storage Object Viewer」角色，共允許只能執行部署工作和讀取必要的物件。

對於需要監控資源的 Service Account，可以建立包含「monitoring.timeSeries.list」和「logging.logEntries.list」等極小權限的自訂角色，而不是授予權限範圍過大的「Monitoring Viewer」角色，避免意外刪除資源或未授權訪問敏感資料等問題。

文章轉載自《東東GCP 教學》網站