案例14｜金鑰與模型憑證不能寫死在程式碼裡

一、案例定位

本案例處理生成式人工智慧（Generative Artificial Intelligence, GenAI）系統中的祕密管理、資料保留選項與最小權限原則。

本案例依原書第 8 章的最佳實務、範例或情境重組，並非原書正式案例研究。

二、學習目標

辨識需要由 secrets manager 管理的敏感設定。
理解「不得硬編碼」的安全理由。
注意模型端點的資料保留設定與最小權限。

三、案例情境

原書要求金鑰、權杖、連線字串與模型憑證使用祕密管理服務保存，例如 Azure Key Vault，並明確要求不得把這些資訊硬編碼在程式碼中。選擇模型端點時，應使用適當的「no data retention」選項，例如 Azure OpenAI 的「no-log」端點；同時各層只授予最低必要權限，服務之間不可預設彼此可信。

四、開始資料

項目	原書做法
金鑰／權杖	交由 secrets manager 管理
連線字串／模型憑證	交由 secrets manager 管理
程式碼	不得硬編碼敏感資訊
模型端點	選擇適當的 no data retention／no-log 選項
各層權限	最低必要權限，不預設服務彼此可信

五、Excel／AI 分析方法

建立敏感設定清冊，欄位包括「類型、儲存位置、是否硬編碼、端點保留設定、權限範圍」；AI 可協助標出違反原書原則的項目。

六、計算結果

原書沒有提供可直接計算的數據，因此不補造結果。

七、結果分析與管理解讀

祕密管理、資料保留與最小權限是同一個目標：降低憑證、資料與服務信任關係被過度暴露的風險。

八、AI 提問詞

請依敏感設定清冊，找出硬編碼的金鑰、權杖、連線字串或模型憑證，以及未標示 no data retention／no-log 或權限過寬的項目。