這篇要處理的是「另一種金鑰」

Day8 談的是 Service Account 的長效憑證管理，這篇要處理的是另一類同樣常被隨意存放的敏感資訊：API Key、資料庫連線字串、第三方模型供應商的憑證，以及用來加密資料本身的加密金鑰。這兩類問題經常一起出現在同一個專案裡——SA 金鑰亂丟的團隊，通常 API Key 也是明碼寫在 config 檔案裡。

Secret Manager：集中管理應用程式機密

Secret Manager 是用來存放 API Key、資料庫密碼、第三方憑證這類機密資訊的集中式服務。核心價值不只是「加密存放」，而是：

• 版本控制：每次更新機密都是新版本，可以隨時回溯或輪替，不會覆蓋掉舊版本導致無法追溯
• 細緻的存取控制：透過 IAM 決定哪個 Service Account 能存取哪個機密，搭配 Day7 的最小權限設計原則
• 存取稽核：每次讀取機密都會留下 Cloud Audit Logs 記錄，回答「誰在什麼時候讀取了這個 API Key」

企業常見的反模式是把第三方模型供應商（例如非 Google 的 LLM API）的金鑰直接寫進環境變數的明碼設定檔，這樣做完全繞過了版本控制與存取稽核，一旦環境變數被意外印到 log 裡，機密就直接外洩。

Cloud KMS：管理「加密資料本身」的金鑰

Secret Manager 管的是機密內容本身，Cloud KMS（Key Management Service）管的是用來加密其他資料的金鑰。例如訓練資料存在 Cloud Storage，你可能希望用自己管理的加密金鑰（Customer-Managed Encryption Key, CMEK）而非 Google 預設的加密金鑰，這樣即使底層儲存服務發生問題，沒有你手上的 KMS 金鑰，資料依然無法解密。

對高敏感的 AI 訓練資料或模型權重檔案，用 CMEK 加密是額外一層防線，尤其對需要證明「加密金鑰由客戶自行掌控」的合規場景（例如部分金融監理要求）特別重要。

兩者怎麼配合使用

實務上兩個服務經常一起出現在同一個架構裡：Secret Manager 存放「呼叫外部服務的憑證」，Cloud KMS 管理「加密內部資料的金鑰」，兩者都透過 IAM 做細緻的存取控制，並且都跟 Day8 提到的「絕不落地明碼儲存」原則一致——差別只在於一個管的是機密內容，一個管的是加密金鑰本身。

# 把一組 API Key 存進 Secret Manager

gcloud secrets create third-party-llm-api-key \

--replication-policy="automatic"

echo -n "YOUR_API_KEY" | gcloud secrets versions add third-party-llm-api-key --data-file=-

# 建立一組 CMEK 用於加密 Cloud Storage 上的訓練資料

gcloud kms keys create training-data-key \

--keyring=ai-workload-keyring \

--location=asia-east1 \

--purpose=encryption

待實測提醒：以上為概念性指令，實際部署前請對照 Secret Manager 與 Cloud KMS 官方文件確認語法與參數，並評估 CMEK 對效能與成本的影響（CMEK 加密的資料在讀寫時會有額外的金鑰呼叫開銷）。

這篇的檢查清單

• [ ] 第三方模型供應商的 API Key 是否已從明碼設定檔搬進 Secret Manager？
• [ ] 高敏感的訓練資料或模型權重是否評估過使用 CMEK？
• [ ] Secret Manager 與 KMS 的存取權限是否也遵循 Week 2 建立的最小權限原則？