💡 先搞懂問題
假設你在虛構公司「晴空食品」負責訂單系統。資料庫密碼一開始寫在 appsettings.json，後來為了「安全一點」改放環境變數，再後來為了部署方便又複製到 CI/CD 的變數設定裡。半年後稽核問三個問題：這組密碼現在存在幾個地方？誰看過？上次換密碼是什麼時候？沒有人答得出來。另一個團隊把資料加密金鑰和加密後的資料放在同一台伺服器，等於把鑰匙插在鎖上；還有一次，網站的 TLS 憑證過期，客戶連不上，才發現沒人記得續約日。
Azure Key Vault（金鑰保存庫）就是為了把這些東西集中管理：你建立一個保存庫（vault），裡面放三種物件。機密（secret）是密碼、連線字串、API 金鑰這類「要拿回原值」的字串；金鑰（key）是做加解密與簽章用的密碼學金鑰，私密部分不會離開保存庫，你只能把資料送進去請它運算；憑證（certificate）是 X.509 憑證，可以設定自動續約。每一次存取都要先通過 Microsoft Entra ID 驗證、再通過授權檢查，並可以記錄到記錄檔裡。
新手最常卡在兩個地方。第一，以為「我是訂用帳戶的 Owner，當然看得到機密」，結果入口網站顯示沒有權限；這是因為 Key Vault 把管理保存庫和使用保存庫裡的東西分成兩套權限。第二，以為刪掉就沒了，或者以為刪掉一定救得回來；實際上刪除會先進入虛刪除（soft delete，Learn 上也寫作軟刪除）狀態，保留一段天數，而能不能提早永久清除，取決於有沒有開清除保護（purge protection）。
生活比喻：銀行的保管箱服務
想像晴空食品在銀行租了一個保管箱，放公司印章、重要合約和幾份密碼信封。銀行櫃台人員可以幫你辦租約、換大一點的箱子、調整營業時間內誰能進金庫區，但櫃台人員打不開你的箱子；能開箱的是持有授權書的人，而且授權書可以寫得很細：「只能取出密碼信封」或「只能請行員代蓋印章」。印章很特別，它從來不會被交到你手上，你把文件交給行員，行員在金庫裡蓋好再還你。
如果有人辦了退租，箱子裡的東西不會馬上被銷毀，而是移到待銷毀區保留一段期間，期間內原本的承租人可以申請取回。有些客戶擔心內鬼或誤操作，會在合約裡加一條：保留期滿前，任何人都不能提前銷毀，連銀行經理也不行。這一條一旦簽下，就沒辦法再改回來。
這個比喻有三個地方和實際不同。第一，銀行櫃員會認人，Key Vault 只看 Entra 權杖與授權設定；權限給錯人，它照樣把機密交出去，所以「最小權限」要靠你設定，不是靠保存庫判斷。第二，比喻裡的櫃台人員永遠打不開箱子，但在舊的存取原則（access policy）模型下，擁有 Contributor 這類能修改保存庫的角色，就能替自己加一條存取原則，自己把箱子打開；改用 Azure RBAC 模型才能把兩邊真正分開。第三，銀行的待銷毀區只放被退租的東西，Key Vault 的虛刪除同時適用於整個保存庫和裡面的單一機密、金鑰、憑證，而且在保留期內，名稱還被占用，不能拿同一個名稱建立新的保存庫或物件。
🎮 互動實驗室一：誰能做什麼？權限模型模擬器
晴空食品有一個金鑰保存庫，裡面放著訂單資料庫的密碼和一把 RSA 金鑰。上方每張任務卡描述一個人或一支程式要做的事；請在左邊勾選要指派給他的角色（可複選，權限會累加），右邊會即時顯示七種操作能不能成功，以及原因。按「檢查這個指派」看看是否剛好符合最小權限。最上面可以切換保存庫的權限模型，比較 Azure RBAC 和舊的存取原則差在哪裡。為了簡化，所有角色都假設指派在保存庫所在的資源群組，往下繼承到保存庫。
指派的角色（可複選）
七種操作的結果
🎮 互動實驗室二：刪掉之後，哪一天前還救得回來？
這個實驗室分兩段。先在左邊替新保存庫設定虛刪除的保留天數（7～90 天）和是否啟用清除保護，按「建立保存庫」；建立後，裡面會有一個名為 db-password 的機密。接著按「刪除機密」，再拖動「刪除後經過的天數」，在不同時間點試試「復原」「清除」「用同名建立新機密」，看哪些會成功。時間軸上的日期以 2026-10-07 刪除為例，是示意；天數規則依 Microsoft Learn 的虛刪除說明（2026 年 10 月查證）。
🛠️ 操作教學：建立保存庫、放入機密，讓應用程式用受控識別讀取
左邊是簡化的入口網站，右邊是做同一件事的 Azure CLI 與 Bicep。照著步驟填欄位，右邊的指令會即時換成你填的名稱、區域與設定，目前步驟對應的那幾行會用黃色底標出來。不需要登入 Azure，也不會真的建立任何資源。
自己動手時要注意
權限：建立保存庫需要在資源群組上有寫入 Key Vault 資源的權限，例如 Contributor 或 Key Vault Contributor；替自己或應用程式指派角色，則需要 Owner、User Access Administrator 或 Key Vault Data Access Administrator 這類能寫入角色指派的角色。只有 Contributor 的人可以建好保存庫，卻沒辦法替自己加上 Key Vault Secrets Officer，這時要請有權限的人幫忙指派。角色指派生效可能需要幾分鐘，剛指派完就出現權限錯誤時，稍等再試。
費用：Key Vault 依操作次數計費，Premium 層的 HSM 保護金鑰另有金鑰費用，練習用量通常很小，但仍會計費；App Service 依方案計費。價格以 Azure 定價頁為準。
清理：練習完刪除整個資源群組：az group delete --name <名稱> --yes --no-wait。要記得保存庫刪除後會進入虛刪除狀態，保存庫名稱在保留期內仍被占用；如果練習時啟用了清除保護，這個名稱要等保留期滿才釋放，所以練習用的保存庫建議把保留天數設短一點，而且名稱不要和正式環境預定的名稱相同。
不要寫進範例的東西：任何真實的密碼、金鑰、連接字串與訂用帳戶 ID 都不要寫進指令、範本或截圖，請用 <your-subscription-id>、<your-secret-value> 這種佔位字。CLI 用 --value 傳機密值會留在 shell 歷史與螢幕上，改用 --file 從檔案讀取，讀完把檔案刪除；Bicep 則把機密宣告成 @secure() 參數，部署時再傳入，不要寫成預設值或放進版本控制。
📘 原理補完
1. 三種物件：拿回原值、送進去運算、自動續約
機密、金鑰、憑證看起來都是「放在保存庫的東西」，用法卻不同。機密是一段字串，應用程式取回原值後自己使用，例如拿資料庫密碼去連線，所以機密的值一定會離開保存庫、進到應用程式的記憶體。金鑰剛好相反：RSA 或 EC 金鑰的私密部分不會被取出，你把要加密、簽章或包裝（wrap）的資料送進去，保存庫算好把結果傳回來；這也是 Azure Storage 等服務用客戶管理金鑰（customer-managed key，CMK）時，只需要被授權「包裝／解包裝」而不需要拿到金鑰本身的原因。憑證則把 X.509 憑證、對應的私密金鑰與可匯出的機密綁在一起，可以設定到期前自動續約，並在快到期時發出事件通知。
保存庫本身有兩個定價層：Standard 的金鑰由軟體保護，Premium 另外支援 HSM 保護的金鑰（FIPS 140-3 Level 3）。如果法規要求單一租用戶、由你完全掌控的 HSM，Key Vault 家族還有 Managed HSM；而要把地端用 PKCS#11 等介面呼叫 HSM 的應用程式搬上 Azure VM，則是 Azure Cloud HSM。
| 選項 | 放什麼 | 金鑰保護 | 租用模式 | 適合情境 |
|---|---|---|---|---|
| Key Vault Standard | 機密、金鑰、憑證 | 軟體保護 | 多租用戶服務 | 應用程式的密碼、連線字串、TLS 憑證；大多數情境的起點 |
| Key Vault Premium | 機密、金鑰、憑證 | 可選 HSM 保護金鑰（FIPS 140-3 Level 3） | 多租用戶服務 | 要求金鑰在 HSM 內產生與使用，但仍用一般 Key Vault API |
| Managed HSM | 金鑰 | HSM（FIPS 140-3 Level 3） | 單一租用戶 HSM 集區 | 高合規要求、當 Azure PaaS 服務的客戶管理金鑰來源 |
| Azure Cloud HSM | 金鑰（PKCS#11 等介面） | HSM（FIPS 140-3 Level 3） | 單一租用戶 HSM 叢集 | 從地端搬上 VM 的 CA、TLS 卸載、資料庫 TDE；不能當 PaaS 的 CMK |
2. 兩種權限模型：為什麼官方建議 Azure RBAC
控制平面一律由 Azure RBAC 授權，這點沒有選擇。資料平面則由保存庫的設定決定：Azure RBAC 模型把「讀機密」「用金鑰加密」也變成角色指派，和其他 Azure 資源用同一套範圍與繼承規則，能搭配 Privileged Identity Management（PIM）做即時啟用，也能用拒絕指派；存取原則（access policy）是 Key Vault 專屬的舊模型，在保存庫上列出「哪個主體可以對機密做 Get、List、Set……」。
存取原則的關鍵弱點在於：存取原則本身是保存庫屬性的一部分，誰能修改保存庫，誰就能改存取原則。Microsoft Learn 明確提醒，擁有控制平面 Contributor 權限的使用者，可以替自己加一條存取原則而取得資料平面存取。改用 Azure RBAC 後，資料平面權限要透過角色指派授與，而能寫入角色指派的只有 Owner、User Access Administrator、Key Vault Data Access Administrator 這類角色，Contributor 就沒辦法自己開門了。根據 Learn 的 Key Vault RBAC 指南，從 API 版本 2026-02-01 起，新建保存庫的預設存取控制模型是 Azure RBAC；Azure CLI 2.91 的 az keyvault create 也預設啟用。不過舊版 API 或既有範本的預設可能不同，所以範本裡最好明確寫出 enableRbacAuthorization: true。
| 比較 | Azure RBAC（建議） | 存取原則（舊） |
|---|---|---|
| 授權方式 | 角色指派：安全性主體＋角色＋範圍 | 保存庫上的原則清單：主體＋權限（Get、List、Set…） |
| 誰能授權 | 能寫入角色指派的角色（Owner、User Access Administrator、Key Vault Data Access Administrator） | 任何能修改保存庫的角色，包括 Contributor |
| 範圍與繼承 | 可指派在管理群組、訂用帳戶、資源群組或保存庫，往下繼承 | 只在單一保存庫上設定 |
| 進階管控 | PIM 即時啟用、拒絕指派、統一的稽核方式 | 沒有 |
| 什麼時候還會看到 | 新設計與官方建議 | 既有保存庫、相依於存取原則的舊應用程式或範本 |
3. Key Vault 內建角色：先分平面，再分物件
挑角色時先問兩件事：這個人要動的是保存庫本身，還是裡面的東西？如果是裡面的東西，是機密、金鑰還是憑證？Key Vault 的資料角色命名很規律：Officer 能對該類物件做所有操作（管理權限除外），User 只能使用（讀機密內容、用金鑰運算），Administrator 涵蓋所有物件的資料平面操作，Reader 只讀中繼資料。以下說明依 Microsoft Learn 的內建角色定義整理（2026 年 10 月查證）。
| 角色 | 平面 | 可以 | 不可以 |
|---|---|---|---|
| Owner | 控制 | 管理保存庫、指派角色 | 直接讀寫機密（沒有資料動作） |
| Contributor | 控制 | 管理保存庫 | 指派角色；在 RBAC 模型下讀機密 |
| Key Vault Contributor | 控制 | 只管理金鑰保存庫資源 | 存取金鑰、機密、憑證 |
| Key Vault Data Access Administrator | 控制 | 新增或移除特定的 Key Vault 資料角色指派 | 指派其他角色、讀機密 |
| Key Vault Administrator | 資料 | 所有物件的所有資料平面操作 | 管理保存庫資源、指派角色 |
| Key Vault Secrets Officer | 資料 | 對機密做任何操作（管理權限除外） | 用金鑰運算、管理保存庫 |
| Key Vault Secrets User | 資料 | 讀取機密內容 | 新增、修改、刪除機密 |
| Key Vault Reader | 資料 | 讀取保存庫與物件的中繼資料 | 讀取機密內容或金鑰材料 |
| Key Vault Crypto User | 資料 | 用金鑰做密碼學運算 | 讀機密、管理金鑰 |
除了表上這些，還有 Key Vault Crypto Officer、Key Vault Certificates Officer、Key Vault Certificate User、Key Vault Crypto Service Encryption User（給 Azure 服務做 CMK 包裝／解包裝用）等角色，命名規則相同。注意這些資料角色只在保存庫採用 Azure RBAC 模型時才有效。
4. 受控識別：解決「第一把鑰匙」
把密碼搬進 Key Vault 之後，新的問題是：應用程式要用什麼證明自己的身分去讀 Key Vault？如果答案是另一組寫在設定檔的用戶端密碼，那只是把問題往後推一格。受控識別（managed identity）讓 Azure 替資源在 Entra ID 建立一個身分，憑證由 Azure 自動建立與輪替，程式只要向平台內部的端點要權杖。實驗室一的第一張任務卡就是這個情境：App 的受控識別只拿 Key Vault Secrets User，在保存庫範圍授權。
5. 虛刪除與清除保護：時間軸上的兩道防線
虛刪除讓「刪除」先變成可逆的動作。依 Microsoft Learn 的說明（2026 年 10 月查證）：虛刪除在新保存庫預設開啟，啟用後無法停用；保留期間可設 7～90 天，預設 90 天，而且只能在建立保存庫時設定，之後不能修改；保留期內可以復原，期滿由服務自動永久清除；保留期內，已刪除保存庫與物件的名稱都不能重複使用。清除保護預設不啟用，一旦啟用就不能關閉；啟用後，保留期滿以前沒有人能清除，只能等服務在期滿時執行。
什麼時候一定要開清除保護？當保存庫裡的金鑰被當成其他服務的客戶管理金鑰時，例如 Azure Storage、受控磁碟或資料庫的加密金鑰，一旦金鑰被永久刪除，被它加密的資料也就再也讀不出來，所以這類整合通常要求保存庫同時開啟虛刪除與清除保護。反過來，開發測試用、經常建立又刪除的保存庫，開了清除保護會讓名稱長時間無法重用，可以考慮不開並把保留天數設短。另外要分清楚：清除保護防的是「永久刪除」，不防「刪除」；有刪除權限的人仍然能把東西刪進虛刪除狀態，只是你救得回來。
6. 網路與監視：權限之外的兩層
權限管的是「誰可以」，網路管的是「從哪裡可以」。Key Vault 有防火牆，可以只允許特定 IP 範圍或虛擬網路，並可設定是否讓受信任的 Microsoft 服務略過；更嚴格的做法是建立私人端點（private endpoint），讓保存庫在你的子網路有私人 IP，再把公用網路存取停用。要注意，停用公用存取後，你從自己電腦的入口網站或 CLI 也連不到資料平面，管理流程要一起規劃。監視方面，可以把診斷記錄送到 Log Analytics，查誰在什麼時候讀了哪個機密；Microsoft Defender for Cloud 的 Defender for Key Vault 方案則偵測異常存取，例如從不尋常的位置大量讀取機密。
遇到 Key Vault 題目時的判斷步驟
- 先分清楚要放的是什麼：要拿回原值的字串是機密，要在不外流的前提下加解密或簽章的是金鑰，要自動續約的 TLS 憑證是憑證。
- 再看動作屬於哪個平面：建立、刪除、網路、標籤、指派角色是控制平面；讀寫機密、用金鑰運算是資料平面。
- 資料平面權限：新設計選 Azure RBAC，找名稱裡有 Secrets、Crypto、Certificates 的對應角色，能讀就給 User、要寫才給 Officer，只要清點給 Reader。
- 應用程式讀機密：受控識別＋Key Vault Secrets User，範圍盡量指派在單一保存庫。
- 怕被誤刪或惡意永久刪除：虛刪除已是預設，再加清除保護；保留天數在建立時就要決定。
- 法規要求 HSM 或單一租用戶：Premium（HSM 保護金鑰）、Managed HSM，或給 IaaS 應用程式用的 Cloud HSM。
容易考錯的地方
相關考試：SC-900 把 Key Vault 列在 Azure 基礎安全服務；SC-500 考 Key Vault 防火牆、以 Defender CSPM 掃描機密與 Defender for Key Vault；AI-200 考 Key Vault 與輪替；AZ-400 與 SC-100 也點名 Key Vault（依各考試 2026 年的技能大綱）。
✅ 自我檢測
以下 6 題都是原創題，選完會立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6
🎯 重點整理
- Key Vault 保存機密、金鑰、憑證：機密取回原值，金鑰的私密部分不離開保存庫，憑證可自動續約。
- 控制平面（管理保存庫）一律用 Azure RBAC；資料平面（使用裡面的東西）新設計也用 Azure RBAC，舊的存取原則會讓 Contributor 自己開門。
- Owner、Contributor 沒有資料平面動作；應用程式讀機密給 Key Vault Secrets User，要寫入才給 Secrets Officer，清點給 Key Vault Reader。
- 應用程式用受控識別取得身分，再在保存庫授權，程式碼與設定檔裡就不必有任何密碼。
- 虛刪除預設開啟、不能停用，保留 7～90 天（預設 90），只能在建立時設定；清除保護預設關閉，開了不能關，期滿前誰都不能清除。
- 網路上可用防火牆與私人端點限制來源，再以診斷記錄與 Defender for Key Vault 監視存取。