【東東老師 X 思想科技】使用 GCP Service Account 開發程式的注意事項

前面上一篇提到的 GCP Service Account 各項技巧，有些需要時間慢慢建立，如果要立刻可以執行的方法，可以遵守以下防範的各項動作：

一、使用 Service Account 的注意事項

(一) 防範憑證外洩

1. 避免將金鑰保存在臨時位置，例如電腦桌面、共用電腦或共享的網路資料夾。

2. 不要在用戶間直接傳遞 Service Account 金鑰文件，例如存在 Line 群組、Email 或雲端硬碟。

3. 防止將金鑰提交到原始碼儲存庫，例如 GitHub 或 GitLab。

4. 不要將金鑰嵌入程序的二進位檔，如果有人獲取了你的二進位檔，他們可能能夠提取出這些金鑰，而且當你需要更新金鑰時，你必須重新編譯整個程式，不安全也很麻煩。

5. 前面雖然提到使用 Secret Manager 來儲存 Key，但能夠不使用 Service Account Key，就盡量不使用，建議還是使用 Workload Identity Federation、HSM、TPM 或自簽證書的方法。

(二) 防範安全配置問題

你需要特別小心處理那些安全認證文件。這些 X.509 證書檔案（就是那種帶有 .pem 或 .crt 副檔名的檔案），它可能會包含比你想像的更多資訊。

首先，請確保你不要在這些證書中放入敏感資訊。例如，不要在裡面寫你公司的內部系統名稱、伺服器位置或其他機密資料。

其次，當你填寫證書的「Subject」（主體）欄位時，請使用一般性的名稱，像是「GCP服務帳戶」或「應用程式認證」，而不是具體的系統名稱如「公司財務系統主機」。

另外，證書中有些是選填欄位，像是地址、城市、郵遞區號等，建議你不要填寫這些資訊。因為如果駭客取得了這些證書，他們可以利用這些地點資訊來猜測你的實體伺服器位置，或是用來發動更具針對性的釣魚攻擊。

(三) 防範權限提升風險

因為如果金鑰被不當取得，駭客可能利用這些憑證來進行各種破壞。尤其是 Editor 角色可能帶來的安全隱患，它的權限實在是太大，若被濫用可能造成嚴重損害，建議採用最小權限原則，只授予必要的權限，前面提了很多次，但還是再問一次，你真的有確實遵守嗎？

其次，應避免在檔案系統（本機電腦、VM 的某個目錄）中直接存儲金鑰，因為這樣很容易被其他人拿到或在系統備份過程中洩露。真的要用，建議使用 Secret Manager 來安全存儲這些敏感憑證。

最後，在虛擬化環境（如容器或虛擬機）中使用 Service Account 金鑰時，要防止底層安全問題，因為底層主機被入侵的話，可能導致所有虛擬環境的金鑰都被洩露。在這種情況下，可考慮使用臨時憑證或 Workload Identity，來減少金鑰洩露的風險。

二、同場加映：防止呼叫 API 爆量的方法 

GCP 提供了豐富的 API 服務，幾乎所有 GCP 的功能，都是以 API 的形式在運作，讓開發人員可以透過程式來自動化存取各種雲端資源。但如果沒有加以控制，API 可能被過度呼叫，導致成本急劇上升，甚至造成服務異常。

(一) API 爆量的發生情境

這種問題通常發生在以下幾種情境：

1. 開發或測試環境未設限

開發人員可能在測試時，沒有把程式碼寫得完善，不慎觸發大量 API 請求。

2. 系統錯誤或程式 Bug

例如無限迴圈 （For Loop）或非預期的重試機制，導致 API 被頻繁呼叫。

3. 流量暴增

突然的流量高峰，例如 DDoS 攻擊或用戶激增，可能導致 API 配額迅速耗盡。

4. 惡意濫用

如果 API 沒有適當的身份驗證與授權控制，可能會被未授權用戶濫用，如上述 Service Account Key 被盜用，如果這個 Key 具有建立虛擬機器的權限，就會被任意建立大量主機，執行挖礦或作為殭屍電腦，是上述情境中最危險的情況。

(二) 限制 GCP API 呼叫的方法

1. 設定消費預算警報

GCP Cloud Billing 允許設定預算警報，一旦 API 費用達到特定閾值，系統會自動發送通知，提醒使用者注意 API 開銷。像我自己是真的把預算警報用到「極致」，不要說超過 50 美金要通知，我只要每超過 1 美金都要收到通知。

但是 GCP 預算警報要隔一天才知道，在正常使用的情況下，GCP 的費用不會超出太多。但如果是被駭客入侵或攻擊，當你看到警報時，可能已經產生一百萬的 GCP 費用了，所以這是緩不濟急的，請再搭配下面提到的方法。

2. 加強 Service Account 權限控制

像前面提到最基本的要求，就是為 Service Account 設置最小權限原則，限制各個 Service Account 只能呼叫特定的 API 和服務，甚至不同環境都用不同的 Service Account，讓它無法隨意呼叫 GCP 的 API。

3. 設定 API 配額限制

在 GCP 上呼叫 API 有多種方式，包括使用 Service Account 和 API Key，API Key 是一種相對簡單的認證方式，它只是一個字串，例如「AIzaSy………M-O1pNg」。

API Key 主要用於特定 API 的存取控制，你可以設定這個 Key 只能呼叫 Compute Engine API，其他 API 都不能呼叫。有些服務能夠限制 API 請求配額，可以有效確保 API 的呼叫次數，尤其是可以限制一天之內或一分鐘之內的次數上限，甚至能區分每個使用者的呼叫上限。

這可以確保萬一 API Key 被駭客取得，呼叫次數也能限制在某個次數範圍之內。

4. 設定資源配額

除了像 API 可以限制呼叫次數，在 GCP IAM 裡管理的則是資源配額，例如專案內可以建立的 VM 數量、vCPU 核心數、儲存容量等各種資源可被開啟的數量上限。

我個人認為這是更重要的，因為假如駭客盜取你的帳號，或是 Service Account Key，他可以直接在你的 GCP 專案內任意開啟機器，要注意他不是一台一台手動開機器，他是用程式自動化的技術，在每個 Region 把你的機器「開好開滿」，直接開到配額上限。

以 N1 的 vCPU 來說，如果你是以個人信用卡使用 GCP，每個 Region 初期只能用到 24 vCPU，隨著使用時間越長，配額會自動調高。

但是你的專案帳單如果直接綁定在代理商，系統會判定你是等級較高的用戶，你在每個 Region 能使用的 vCPU 就會提高不少，萬一被駭，就會變成每個 Region 的主機、CPU 甚至 GPU，全部開滿。

只要 1~2 天的時間，就可以在一個專案內，開「幾萬台」機器，隔天就會收到「百萬」等級的帳單，等你收到帳單警示已經來不及了。這是確實有發生過的情況，絕非杜撰，這就回到你的 Service Account Key 務必保管好，甚至使用其他驗證方式。

難道沒有其他解決辧法嗎？有的，就是減少配額，建議針對每個型號，例如 N1、N2 的 vCPU，而且每個 Region 都要減少。如果你沒有在用 GPU，就直接把每個 GPU 配額改成 0。

你可能會想，駭客進來也可以提高配額啊？這點不用擔心，減少配額可以改完當下就生效，但是如果要增加配額超過預設值，Google 那邊至少需要兩天的時間人工審核，還要填寫聯絡方式包含電話號碼，所以駭客不會去做的。

5. 設定各個服務的運作上限 

(1) Compute Engine 的配額限制

如前段提到的例子，你可以通過配額限制來控制資源使用。

(2) Google App Engine 必須要調整 app.yaml

很多人都不知道，App Engine 預設沒有設定上限，代表它會無限擴充，重點是，很多人都一直以為他的 App Engine 只有一台機器在跑，直到看到帳單才發現原來它在某個尖峰時間，曾經擴充過多台主機。

你必須要在 app.yaml 設定 Autoscale 的上限數量，才不會一直擴充下去。

(3) Cloud Run 或 Cloud Run Function 

執行個體預設的 Autoscale 數量是 0 到 100，記得把它改成你能接受的上限，例如 5 個。

(4) 設定 BigQuery 每天查詢上限 

要注意，原本 BigQuery 的預設查詢配額，也是「無上限」的，如果你的資料太多又沒整理，或是不小心有程式一直自動查詢大量資料，也會造成非常大的費用。你可以設定 BigQuery 每天的查詢限制，也能設定每天+每個使用者的查詢限制。

6. 節流機制 (Throttling)

(1) Cloud Armor 節流（Rate Limit）

對於外部流量，Cloud Armor 可以設定節流機制，例如每分鐘不能存取超過 1,000 次，超過即停止服務。但要注意，你要先知道你的服務平時的流量，以及假日或活動期間的流量，以免低估流量，反而把真正的用戶阻擋在外面。

(2) 本地節流機制

這裡指的就是你自己開發的應用程式，直接實作 API 請求節流的邏輯，那你就可以彈性地設定各種不同時間間隔，例如每秒不能超過 100 次，每分鐘不能超過 1000 次，每小時不能超過 10,000 次等等。這也是要注意，不要錯估流量。

另一方面，如果程式發生錯誤，例如當 API 回應 429 時，必須要重新存取（Retry），或是被外部呼叫，你可以使用指數退避 (Exponential Backoff) 策略處理重試，自動延遲並逐步增加重試間隔，例如當發生第一次錯誤，休息兩秒，第二次，休息四秒，第三次，休息八秒…等，不要讓程式在出錯時還一直不斷存取，減少無謂資源的消耗。

7. 設定各種指標的監控

Cloud Monitoring 可以監控很多指標，不只監控 API 呼叫次數，你也可以監控例如用戶發出的 Request 數量，或是主機每秒送出的流量大小，並且限制例每分送出超過 10 MB，就發出流量警告，讓你在異常流量發生的當下，就能夠立即發現並阻擋。

三、結論

成功管理 Service Account 需要綜合考慮安全性、方便性和維護成本。通過上述的小技巧，你可以在系統開發過程的各個階段，有效並安全地使用 Service Account。

要記住的是，不是「Service Account 怎麼用」或「Service Account Key 怎麼保管」。因為你「不一定要用 Service Account」，選擇合適的身份驗證方法是最重要的第一步。

你可以優先考慮 GCP 的內建驗證機制，只在非用不可的時候，才使用 Service Account 和 Key，並依照最佳實務來管理。這樣不僅可以降低維護成本，還能大幅提高系統的整體安全性。

另外，各種機制也是需要不少時間規劃流程和制度，以及各部門之間互相配合，遵守規範，這也需要主管大力支持並提供充份的資源，才能有效實施。

四、常見問題

(一) 如何檢查 Service Account 是否有過度授權？

1. GCP 提供 IAM 建議 (IAM Recommender)

可以分析 Service Account 的使用情況，找出是否擁有過多權限。
步驟：

(1) 前往 GCP Console，打開 IAM & Admin > IAM。

(2) 找到 Service Account，查看「建議的角色」(Recommended roles) 欄位。

(3) 如果 GCP 建議降低權限，請根據建議調整角色。

2. 使用 IAM Policy Analyzer 進行分析

你可以在 IAM & Admin > Policy Analyzer 中輸入 Service Account 的電子郵件。查看該帳戶擁有哪些權限，並確認是否有不必要的存取權限，操作方式和上述差不多。

(二) 如何刪除未使用的 Service Account？

可參考以下步驟：

(1)  列出所有 Service Account 並找出未使用的帳戶：

gcloud iam service-accounts list –format=”table(email, disabled)”

可以顯示所有 Service Account 和目前的使用狀態 (是否已停用)。

(2) 停用 Service Account

如果確認某個 Service Account 一直都沒有在用，可先停用：

gcloud iam service-accounts disable [email protected]

這樣可以避免影響現有服務，若發現問題仍可重新啟用。

(3) 刪除 Service Account

停用後，如果確定不再需要，可刪除：

gcloud iam service-accounts delete [email protected]

⚠ 注意：刪除後不可恢復，請確保已經沒有任何應用程式在使用該帳戶。

(三) Service Account 金鑰遺失該怎麼辦？

如果 Service Account 金鑰遺失，應立即執行以下步驟，以確保系統安全：

1. 列出現有的 Service Account 金鑰

gcloud iam service-accounts keys list –[email protected]

這會顯示所有金鑰的 KEY_ID，你可以確認哪個金鑰可能遺失。

2. 立即刪除遺失的金鑰

如果確定某個金鑰已洩露，請使用以下命令刪除：

gcloud iam service-accounts keys delete YOUR_KEY_ID –[email protected]

刪除之後，即使駭客手上擁有你的金鑰檔案，也是無法發運任何作用的。

⚠ 注意：一旦刪除，任何使用該金鑰的應用程式都將失去存取權限，請確保已經準備好替代方案。

3. 生成新的 Service Account 金鑰

如果仍需使用金鑰（不推薦），可以產生新的金鑰：

gcloud iam service-accounts keys create new-key.json –[email protected]

(四) 我可以將 Service Account Key 存放在 GitHub 嗎？

不建議這樣做，因為這可能導致憑證洩漏，應該使用 Secret Manager 來管理。

(五) 如何檢測 Service Account Key 是否外洩？

你可以透過 Cloud Audit Logs 來查詢這個 Service Account Key 異常存取行為，你可以參考這份文件來操作。

(六) Service Account Key 有效期多久？

預設情況下都是永久的，開發人員應該手動輪替金鑰。

(七) 有哪些更安全的替代方案？

Workload Identity Federation 和 OAuth 2.0 是更安全的選擇，能不用 Service Account Key 就盡量不要用。

另一個方法是產生 RSA 2048 金鑰對，透過 HSM 模組、Cloud KMS 或 TPM 方法，在私鑰完全不需要對外分享的情況下，讓應用程式還是可以操作 GCP 的 API。

(八) 如何讓 CI/CD 流程更加安全？

可以使用 Workload Identity Federation，避免直接存放 Service Account Key。

(九) 如何避免因資安事件發生，而造成大量的帳單費用？

1. 設定預算警示
2. 設定 API 配額
3. 設定減少資源配額，例如 CPU 和 GPU
4. 設定 Service Account 和 Key 的監控和快訊
5. 設定流量和資源使用量的監控和快訊
6. 限縮服務本的的自動擴充上限
7. 設定應用程式的存取次數

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