資料保護

Note

本文包含建議指引，並非作為認證標準、合規證明或所需控制措施的陳述。 該內容最後審查日期為2025年12月1日，可能不反映資料分類、加密及金鑰管理的最新進展。

資料保護可在整個資料生命週期中保護敏感資訊免遭未經授權的存取、外洩和濫用。 實作探索和分類以建立資料清查、加密以保護傳輸中和靜態的資料，以及嚴格的金鑰和憑證管理以維護密碼完整性。 這種分層方法與 零信任 原則及防禦深度策略相符。

如果沒有全面的資料保護，組織將面臨資料外洩、監管處罰以及敏感資訊外洩造成的聲譽損害。

以下是資料保護安全領域的三個核心支柱。

了解並分類您的數據： 探索敏感資訊並套用一致的標籤，以啟用風險型控制。

相關控制項：

使用加密保護資料： 使用現代加密標準對傳輸中和靜態資料實施全面的加密。

相關控制項：

管理加密基礎設施： 透過自動輪換和全面的稽核記錄，為加密金鑰和憑證建立嚴格的生命週期管理。

相關控制項：

DP-1：探索、分類及標記敏感性資料

Azure 原則： 請參閱 Azure內建政策定義：DP-1。

安全原則

透過探索、分類和標記所有儲存庫中的資料，建立和維護敏感資料的全面清單。 這可以實現基於風險的存取控制、加密策略和監控，以防止未經授權的存取和外洩。

需要減輕的風險

威脅行為者利用敏感資料缺乏可見性和處理不一致的情況來竊取或濫用高價值資訊。 當敏感性資料未被探索、分類或標記時：

  • 未追蹤的受管制資料： （PCI、PHI、PII） 儲存在非受管理位置 （影子 IT） 會略過所需的加密、保留或監控控制。
  • 過度特權存取： 廣泛的使用者/服務存取權會持續存在，因為未識別敏感度和商務影響。
  • 複製品增殖： 資料複寫至分析、測試或匯出管線，會將敏感內容分散到信任度較低的環境中。
  • 法醫盲點： 事件回應者由於敏感度中繼資料缺失或不正確，無法快速確定爆炸半徑範圍。
  • 自動化失敗： 治理 （DLP、條件式存取、加密工作流程） 無法在沒有一致標籤的情況下觸發。

缺乏基礎分類會增加停留時間，擴大橫向流動機會，並增加監管和聲譽風險。

MITRE ATTCK(&C)

  • 偵察 （TA0043）：列舉儲存體帳戶、結構描述目錄和分類中繼資料，以分析高價值存放庫，以收集受害者身分識別/資料資產 （T1596）。
  • 探索 （TA0007）：帳戶和權限列舉 （T1087、T1069），以識別過多的角色繫結，從而可能導致水平或垂直資料存取提升。
  • 收集 （TA0009）：從雲端儲存體 （T1530）透過擷取未標記的 Blob 容器或缺少追蹤標籤的非受控匯出來取得資料。
  • 外流（TA0010）：透過 Web 服務（T1567）從無標籤/政策閘道的臨時匯出端點進行外流。
  • 外洩 （TA0010）：自動外洩 （T1020），使用腳本分頁/循環悄悄地收集錯誤分類的數據集。

DP-1.1：探索、分類和標記敏感資料

使用 Microsoft Purview 建立完整的資料地圖，自動發現、分類並標註整個資料資產中的敏感資訊。 通過實施 Microsoft Purview 資訊保護，將保護擴展到不僅限於基礎設施層級的加密，並應用持久的文件層級加密和使用權限，無論數據傳輸到何處，都能隨時提供保護。 這項基礎功能可讓下游安全性控制 （例如資料外洩防護、條件式存取和加密原則） 根據資料敏感度來運作，而不是僅根據位置來運作。

資料發現與分類：

  • 部署 Microsoft Purview 以發現、分類並標註敏感資料，涵蓋Azure、本地部署、Microsoft 365及多雲環境。
  • 使用 Microsoft Purview Data Map 自動掃描並編目包括 Azure 儲存體、Azure SQL Database、Azure Synapse Analytics 及其他支援服務的資料來源。
  • 在 Purview 數據對應中啟用 敏感度標籤 ，以根據數據內容模式和組織原則自動套用分類標籤 （例如機密、高度機密、PII、PHI） 。

文件級加密和保護：

  • 部署 Microsoft Purview 資訊保護，根據敏感性標籤對文件與電子郵件施加持久加密與使用權限。 設定標籤以自動加密檔案、套用浮水印、限制轉寄、設定到期日，以及撤銷存取權限，即使在資料離開您的組織後也是如此。
  • 啟用 Azure 權利管理服務（Azure RMS）作為底層保護技術，以使用政策（僅限檢視、禁止複製、禁止列印）加密文件與電子郵件，這些政策無論資料存放或分享地點皆持續存在。

資料庫分類與整合：

  • 對於Azure SQL資料庫，請啟用 SQL 資料發現與分類用以識別、分類及標註包含敏感資料的欄位，如信用卡號碼、社會安全號碼或健康紀錄。
  • 將分類元資料與下游控制整合：在 Microsoft Purview 中設定資料遺失防護（DLP）政策，在 Entra ID 中套用條件存取規則，並根據敏感性標籤強制執行加密政策。
  • 建立定期掃描排程，以隨著資料資產的發展，持續探索新建立或修改的敏感資料資產。

實作範例

一家全球金融服務機構部署了 Microsoft Purview Data Map，自動發現並分類涵蓋 200+ 個 Azure 儲存體 帳戶、50 個 SQL 資料庫及 Synapse Analytics 工作空間的敏感資料。

Challenge： 組織對於其快速成長的Azure資料資產中敏感資料的所在位置缺乏可視性。 手動資料分類不一致，延遲了治理執行，並造成了合規性差距。 如果沒有自動探索，受管制的資料 （PHI、PII、PCI） 在非受管理位置仍然不受保護，而且資料外洩防護原則也無法適當觸發。

解決方案方法：

  • 部署 Microsoft Purview 資料地圖以進行資料發現：建立 Purview 帳號並註冊資料來源（Azure 儲存體帳號、SQL 資料庫、Synapse Analytics 工作區），設定資料圖以使用管理身份驗證掃描來源，並授予掃描身份的讀取權限（db_datareader角色）以進行目錄架構及偵測敏感欄位。
  • 設定分類和敏感度偵測： 設定掃描規則以偵測敏感型樣 （SSN、信用卡號碼、病歷號碼、SWIFT 代碼）、定義符合資料分類原則的自訂分類規則 （商務敏感資料為「機密 - 內部」、PHI/PCI/PII 資料為「高度機密 - 受管制」）、設定自動標籤臨界值 （當≥在單一資產中偵測到 3 個 PII 模式時套用「高度機密」）、根據資料重要性建立掃描排程 （生產環境每週、 每月封存），設定警示，以便在發現新的高敏感度資料時通知安全團隊。
  • 部署文件層級加密Microsoft Purview 資訊保護：在 Purview 合規入口網站建立敏感性標籤並設定保護（公開：無加密，僅視覺標記;內部：浮水印，無轉寄限制;機密：使用 Azure RMS 加密，僅允許員工查看/編輯，封鎖轉發/列印;高度機密 - 受規範：以 Azure RMS 加密、僅檢視存取、禁止複製/列印/轉寄、90 天有效期、可撤銷存取）、透過標籤政策（範圍：財務、法務、行政部門）向使用者發布敏感標籤，配置自動標籤政策以自動套用標籤（≥10 個社會安全號碼→「高度機密 - 受管制」，≥5 個信用卡號碼→「高度機密 - 受管制」），啟用Azure針對儲存在 SharePoint、OneDrive 和 Azure 儲存體 帳戶的標籤文件的 RMS 保護，並為 Office 應用程式設定用戶端標籤，提醒使用者在儲存/傳送前分類文件。

結果： Purview 數據地圖自動掃描在第一週內識別了超過 15,000 個包含受管制數據的數據資產，將發現時間從幾個月縮短到幾天。 資訊保護 自動標籤在 72 小時內對 8,500 份文件進行加密。 敏感度標籤可啟用持續的數據資產可見度和持續性保護，即使數據移至非受控裝置也一樣。

關鍵性層級

必須具備。

控制映射

  • CIS 控制 v8.1： 3.2、3.7、3.13
  • NIST SP 800-53 修訂版 5： RA-2、SC-28
  • PCI-DSS v4： 3.2.1、12.3.1
  • NIST CSF v2.0： PR.DS-1，PR.DS-5
  • ISO 27001：2022 認證： 答：8.11
  • SOC 2： CC6.1

DP-2：監視以敏感數據為目標的異常和威脅

Azure 原則： 請參見 Azure內建政策定義：DP-2。

安全原則

監控敏感資料存取和傳輸活動，以尋找表明未經授權的外洩、內部威脅或帳戶受損的異常情況。 使用行為基準和資料敏感度上下文來偵測異常模式，例如大型傳輸、異常存取時間或意外的資料移動。

需要減輕的風險

對手和惡意內部人員試圖使用隱蔽或低訊號行為來竊取、暫存或探測敏感資料。 若沒有持續的、與資料敏感度相符的上下文感知異常偵測：

  • 無聲外洩： 大量匯出、大型結果集或增量虹吸會因為缺乏基準而未被偵測到。
  • 內部人員濫用： 合法憑證會執行不尋常的序列（時間、數量、地點），以繞過粗略的監控。
  • 暫存和枚舉： 攻擊者在大規模提取之前映射模式/標籤以優先考慮高價值目標。
  • 離地生活查詢：標準管理工具掩蓋了正常操作噪音中的偵察。
  • 跨存儲規避： 跨多個服務的分散式存取可避免單一存儲閾值和關聯。

異常檢測不充分會削弱事件響應效率，並允許以最小的摩擦從偵察升級到全面滲透。

MITRE ATTCK(&C)

  • 收集 （TA0009）：來自雲端儲存體 （T1530） 的資料，透過跨敏感容器的異常大量或廣泛扇出讀取。
  • 憑證存取 （TA0006）：有效帳戶 （T1078） 濫用遭入侵或內部憑證，以與合法流量基準混合。
  • 外流 （TA0010）：自動外流 （T1020） 使用腳本化、節流的查詢，旨在避免警示閾值。
  • 外流 （TA0010）：外流至雲端儲存體 （T1567.002），在攻擊者控制的區域中暫存資料，或帳戶以供稍後擷取。
  • 命令與控制/資料外洩（TA0011/TA0010）：透過一般 DB/API 呼叫，以應用層協定（T1071）隧道化敏感資料列。
  • 探索 （TA0007）：系統/服務探索 （T1082、T1046） 列舉端點，以繪製較高價值存放區的橫向移動路徑。

DP-2.1：啟用資料服務的威脅偵測

部署 Microsoft Defender 服務，為您的資料儲存與資料庫平台提供即時威脅偵測與異常監控。 這些服務使用行為分析和威脅情報來識別可疑活動，例如 SQL 注入嘗試、異常查詢模式、異常資料存取量以及傳統存取控制無法偵測到的潛在外洩指標。

啟用資料服務的威脅偵測：

DP-2.2：監控和防止資料外洩

實施主動資料外洩防護控制和行為監控，以在未經授權的資料傳輸成功之前偵測並阻止它們。 將原則型 DLP 與內部風險管理、SIEM 關聯和自動化回應相結合，建立深度防禦方法，阻止跨多個管道的外洩嘗試，同時為事件調查提供鑑識證據。

部署 DLP 和內部風險控制：

  • 使用Microsoft Purview 資料外洩防護（DLP）政策，透過監控並阻止跨Azure服務、Microsoft 365及端點的未經授權機密資料傳輸，防止敏感資料外洩。
  • 部署 Microsoft Purview 內部風險管理，利用機器學習與行為分析偵測風險使用者行為。 監控指標，包括異常資料下載、將檔案複製到 USB/個人雲端儲存、在正常工作時間之外存取敏感資源或辭職日期之前的資料存取高峰。 內部風險管理會將來自 Microsoft 365、Azure、人力資源系統及資安工具的訊號關聯起來，以識別潛在的資料竊取或政策違規。

設定監控和回應：

  • 為資料服務設定診斷日誌，並將其路由至Azure 監視器或Microsoft Sentinel，以建立行為基線並偵測與正常存取模式的偏差。
  • 將資料服務日誌與 Microsoft Sentinel整合，建立分析規則，偵測異常資料存取模式，如大量下載、非營業時間存取或可疑查詢行為。
  • 實施自動化事件應變工作流程，使用 Azure Logic Apps 或 Microsoft Sentinel 操作手冊，隔離被入侵的身份，撤銷存取權限，並在偵測到資料外洩企圖時通知資安團隊。

註： 針對主機端的 DLP 需求，部署 Microsoft Purview 端點 DLP 功能或 Azure Marketplace 的第三方解決方案，以強制執行端點層級的資料保護控制。

實作範例

一家醫療服務提供者啟用了 Microsoft Defender for Storage 與 Defender for SQL，以監控針對 Azure 儲存體 帳號及 SQL 資料庫中病患資料的異常與威脅。

挑戰： 該組織在偵測未經授權的資料存取和外洩嘗試方面遇到了盲點。 傳統的邊界防禦無法察覺內部威脅，並不當使用服務主體執行大量下載。 如果沒有行為分析和異常偵測，可疑的存取模式就會長時間被忽視，從而增加違規風險和停留時間。

解決方案方法：

  • 啟用 Microsoft Defender for Storage： 在訂閱層級為儲存帳戶啟用 Defender，以保護包含敏感資料的儲存帳戶，設定惡意軟體掃描以偵測並隔離 blob 儲存中的惡意檔案，啟用 Purview 的敏感資訊類型以識別 PHI（受保護的健康資訊）/PII（個人識別資訊）模式的敏感資料威脅偵測，設定每筆交易掃描上限或每月上限以控制成本，對包含承載醫療影像與電子病歷匯出的生產儲存帳戶的資源群組套用保護。
  • 啟用 Microsoft Defender for SQL： 在訂閱層級啟用 Microsoft Defender for SQL 用於 Azure SQL Database 與 SQL 受管理執行個體，設定漏洞評估並進行定期掃描，並指定儲存帳號以存儲掃描結果，配置電子郵件通知以警示安全團隊識別出的漏洞，啟用 進階威脅防護 偵測 SQL 注入嘗試、異常查詢模式、來自不熟悉地區的異常存取及潛在資料外洩。
  • 整合與 Microsoft Sentinel: 利用資料連接器將 適用於雲端的 Microsoft Defender 連接到 Microsoft Sentinel，設定診斷日誌設定（啟用診斷日誌以支援儲存操作及 SQL 稽核日誌，路由至 Log Analytics 工作空間），建立 Sentinel Analytics 規則以偵測異常（在 1 小時內下載超過 10 GB 的警報、非工作時間存取資料庫、可疑查詢模式），配置自動化回應劇本以隔離被入侵身份，撤銷儲存存取權，並通知資安團隊。
  • 部署 Microsoft Purview 內部風險管理 以偵測行為威脅：啟用內部風險管理並設置策略模板（偵測離職用戶在辭職前30-90天的異常檔案下載、監控一般資料洩漏和USB/雲端儲存的複製、優先用戶的資料洩漏和對高權限角色的強化監控），設定風險指標與門檻（累積檔案下載量警示、非營業時間存取高峰、多個風險信號的序列化偵測）、整合資料來源（Azure 活動日誌、Microsoft 365 稽核日誌、Defender for Cloud Apps、人力資源系統、端點 DLP 事件），配置警報分流工作流程，將中高嚴重性的警報導向專屬調查隊列。

結果： Defender 儲存裝置在 48 小時內偵測到來自被入侵服務主體的異常批量下載活動。 自動回應隔離身分並在幾分鐘內通知 SOC，將偵測時間從幾天縮短到 15 分鐘以內。 內部風險管理部門警告了一名即將離職的員工將大量研究數據下載到個人雲存儲中，其數據量顯著超過個人基線，使得能夠快速干預。

關鍵性層級

必須具備。

控制映射

  • CIS 控制 v8.1： 3.13
  • NIST SP 800-53 修訂版 5： AC-4、SI-4
  • PCI-DSS v4： 3.2.1、10.4.1
  • NIST CSF v2.0： DE.CM-1, PR.DS-5
  • ISO 27001：2022 認證： A.8.11、A.8.16
  • SOC 2： CC6.1、CC7.2

DP-3：加密傳輸中的敏感數據

Azure 原則： 請參見Azure內建政策定義：DP-3。

安全原則

使用強加密 （例如 TLS 1.2 或更新版本） 保護傳輸中的資料，以防止攔截、竄改和未經授權的存取。 定義必須加密的網路邊界和服務範圍，優先考慮外部和公共網路流量，同時根據資料敏感度考慮內部網路保護。

需要減輕的風險

未加密或保護薄弱的網路通道會使敏感資料受到攔截、操縱和降級濫用。 沒有強制執行的新式傳輸加密 （TLS 1.2+）：

  • 被動攔截： 網路觀察者以純文字形式擷取憑證、權杖、API 有效負載或受監管資料。
  • 中間人： 攻擊者更改查詢、注入有效負載或收集會話材料。
  • 協議降級： 舊版後援 （SSL/TLS < 1.2、純文字 HTTP/FTP） 可讓您利用已棄用的密碼套件。
  • 會話劫持： 缺乏通道完整性允許令牌重播或 cookie 竊取以進行橫向移動。
  • 誠信操縱： 竄改會破壞分析或觸發詐欺交易。
  • 隱晦的橫向路徑： 內部的明文流量在獲得立足點後，變為偵察材料。

未能在傳輸過程中強制執行強加密會擴大違規爆炸半徑，加速憑證洩露，並破壞零信任假設。

MITRE ATTCK(&C)

  • 認證存取 （TA0006）：在純文字或降級的 TLS 會話期間截獲的未受保護認證（T1552），暴露了令牌或會話材料。
  • 集合 （TA0009）：網路嗅探 （T1040） 收集穿越弱加密或明文路徑的 API 載荷和機密資訊。
  • 外流 （TA0010）：透過 Web 服務 （T1567） 透過合法 API 端點串流結構化資料的外流。
  • 防禦規避 （TA0005）：中間對手 （T1557） 強制 TLS 降級或插入攔截代理以檢視/修改流量。
  • 命令與控制 （TA0011）：非應用層協定 （T1095） 恢復使用舊版或較少檢查的傳輸方式，以略過監視。

DP-3.1：對資料服務和應用程式強制執行 TLS 加密

在所有面向客戶的服務和資料平台上建立現代傳輸層安全標準，以防止攔截、竄改和中間人攻擊。 在儲存、Web 應用程式、資料庫和 API 閘道中強制執行最低 TLS 1.2 或 1.3，同時停用將資料暴露給加密降級攻擊的舊式通訊協定和弱密碼套件。

對資料服務和應用程式強制執行 TLS：

  • 對Azure 儲存體帳號強制執行安全傳輸（僅限 HTTPS），以確保所有用戶端連線在 blob、檔案、排隊和資料表操作時使用 TLS 1.2 或更新版本。
  • 對於託管於 Azure App 服務 的網頁應用程式，請啟用「僅 HTTPS」設定，並將 minimum TLS 版本設定為 1.2 或 1.3，以防止降級攻擊並確保現代化密碼學標準。
  • 設定 Azure 應用程式閘道，強制執行 TLS 1.2/1.3 的最低版本，適用於前端監聽者及後端連線加密（端對端 TLS）。
  • 對於 Azure SQL Database 及其他 PaaS 資料服務，請確認「要求安全連線」或等效設定是否強制加密連線;拒絕純文字連線。
  • 對於 API 管理、Azure Front Door 及其他閘道服務，設定最低 TLS 版本政策以強制執行 TLS 1.2 或更高版本，並停用弱密碼套件。

註： Azure 會自動加密所有資料中心間Azure的流量，使用 MACsec（第 2 層）與 TLS（第 7 層）進行加密。 大多數 Azure PaaS 服務預設啟用 TLS 1.2+，但對於具備客戶可自訂政策的服務（儲存、應用服務、應用閘道、API 管理、前門）請確認最低 TLS 版本設定。

DP-3.2：安全的遠端存取和檔案傳輸協定

消除在營運活動期間暴露憑證和敏感資料的純文字管理存取和遺留檔案傳輸協定。 用現代加密的替代方案取代不安全的協定（FTP、未加密的 RDP/SSH），並透過集中式堡壘路由特權存取，以消除管理介面的直接網際網路暴露。

安全的遠端管理協定：

  • 對於遠端管理 Azure 虛擬機，請專用安全協定：
    • Linux 虛擬機器： 將SSH（埠22）與基於金鑰的身份驗證一起使用;停用密碼驗證。
    • Windows 虛擬機： 使用 RDP over TLS（埠號 3389），並啟用網路層級驗證（NLA）。
    • 特權存取： 透過 Azure Bastion路由管理連線，以消除公共 IP 暴露，並提供瀏覽器或原生用戶端透過 TLS 存取。

安全檔案傳輸協定：

  • 對於檔案傳輸操作，請使用安全協定並停用舊版替代方案：
    • 在 Azure Blob 儲存體 中使用 SFTP 支援（需要階層命名空間）。
    • 使用 Azure App 服務 和 Azure Functions 的 FTPS。
    • 停用舊版 FTP 通訊協定 （純文字）。
  • 使用 Azure 原則 在您的環境中執行安全的傳輸政策，並監控 TLS 版本的合規性。

實作範例

電子商務平台在所有面向客戶的服務中強制執行 TLS 1.3 最低版本，以滿足 PCI-DSS 4.0 要求。

挑戰： 傳統的 TLS 1.0/1.1 協定和弱密碼套件使客戶支付資料暴露於攔截攻擊之下。 跨應用程式層的不一致 TLS 強制執行造成了安全漏洞，攻擊者可以降級連線。 如果沒有集中式 TLS 策略強制執行，手動配置漂移會允許不安全的協定在生產中持續存在。

解決方案方法：

  • 配置 TLS Azure App 服務 1.3： 將面向客戶的網頁應用程式與 API 設定最低 TLS 版本為 1.3，啟用僅限 HTTPS 模式以自動將所有 HTTP 流量導向至 HTTPS，驗證受管理憑證或自訂憑證是否使用強密碼套件。
  • 配置 Azure 應用程式閘道 的端對端 TLS：配置前端 HTTPS 監聽器，使用 SSL 政策 AppGwSslPolicy20220101（最低 TLS 1.3，並使用 CustomV2 政策），上傳 TLS 憑證或整合至 金鑰保存庫 以管理憑證。設定後端的 HTTPS 連線（將後端協定設為使用 443 埠的 HTTPS，若後端 App Services 使用 Azure 管理的憑證，請啟用「使用廣為人知的 CA 憑證」，並將後端連線的最低 TLS 版本設為 1.2）。接著，建立路由規則，將 HTTPS 監聽器連結至已啟用 TLS 設定的後端池。
  • Enforce secure transfer for Azure 儲存體：啟用「需要安全傳輸」設定，強制 blob、檔案、佇列及資料表操作僅使用 HTTPS，所有儲存連線的最低 TLS 版本為 1.2，確認所有 SAS 憑證與共享金鑰僅能透過 HTTPS 連線運作。
  • 配置Azure Bastion以提供安全的遠端存取： 在 hub VNet 部署 Azure Bastion，透過 TLS 1.2 提供基於瀏覽器的 RDP/SSH 存取，移除虛擬機中的公有 IP，並將所有管理存取專屬於 Bastion 路由。

Outcome： Azure 儲存體 帳號在服務邊界拒絕 HTTP 連線，Application Gateway 對前端連線強制使用 TLS 1.3 並採用 TLS 1.2 後端加密，Azure Bastion 則消除虛擬機管理時的公共 IP 暴露。

關鍵性層級

必須具備。

控制映射

  • CIS 控制 v8.1： 3.10
  • NIST SP 800-53 修訂版 5： SC-8
  • PCI-DSS v4： 4.2.1、4.2.2
  • NIST CSF v2.0： PR.DS-2
  • ISO 27001：2022 認證： 答：8.24
  • SOC 2： CC6.1、CC6.7

DP-4：預設啟用靜態資料加密

Azure 原則： 參見 Azure內建政策定義：DP-4。

安全原則

預設啟用靜態加密，以保護資料免於透過底層儲存、實體媒體竊取、快照暴露或受損的基礎架構存取進行未經授權的存取。 加密透過確保即使在繞過儲存層級安全性時資料仍受到保護來補充存取控制。

需要減輕的風險

未加密或選擇性加密的儲存層允許具有頻外存取（基礎設施洩露、媒體被盜、快照濫用）的攻擊者大規模收集敏感資料。 沒有預設加密：

  • 從原始媒體收集資料： 遭竊的磁碟、備份或未受管理的快照集會公開完整的純文字資料集。
  • 特權邊界侵蝕： 平台管理員或遭入侵的主機代理程式可以在沒有密碼編譯隔離的情況下讀取租戶資料。
  • 靜默複製和洩露： 未加密的複本（測試、分析、匯出）成為低摩擦的外洩通道。
  • 完整性篡改： 攻擊者會修改休眠資料 （惡意 DLL、設定或參考資料） ，以觸發稍後階段的入侵。
  • 監管不合規： 缺乏系統加密破壞了許多行業認證所需的保證。
  • 無金鑰恢復暴露： 災難復原映像和冷封存會無限期地保留可復原的純文字中的敏感內容。

未能強制執行通用靜態加密會增加違規規模，使鑑識範圍界定複雜化，並放大下游營運和法律風險。

MITRE ATTCK(&C)

  • 收集 （TA0009）：從雲端儲存體 （T1530） 擷取未加密的快照集、複本或分離磁碟的資料。
  • 防禦規避 （TA0005）：在離線媒體/快照存取後進行指示器刪除 (T1070)，編輯或清除日誌。
  • 影響 （TA0040）：資料銷毀 （T1485） 會破壞未加密的休眠資產，以中斷下游程序。
  • 影響 （TA0040）：禁止系統復原 （T1490） 刪除或變更未加密的備份和復原型錄。
  • 影響 （TA0040）：資料操作 （T1565） 巧妙地修改儲存的參考或配置資料，以導致後期邏輯故障。

DP-4.1：預設啟用靜態資料加密

確保所有儲存在 Azure 的資料都已靜態加密，以防止基礎設施遭入侵、媒體被竊或未經授權快照的未經授權存取。 雖然大多數 Azure 服務預設啟用加密，但需驗證虛擬機、儲存帳號與資料庫的覆蓋範圍，並為高度敏感的工作負載啟用額外加密層（主機加密、基礎設施加密、機密運算及欄位層級加密），以符合法規與資料主權需求。

啟用 VM 和儲存體的加密：

  • 啟用 encryption-at-host，讓Azure 虛擬機器在資料到達Azure 儲存體前加密臨時磁碟、作業系統磁碟快取、資料磁碟快取及臨時作業系統磁碟。 在訂用帳戶層級註冊 EncryptionAtHost 功能，並使用支援的 VM 大小 （例如 DSv3、Easv4、Dadsv5 系列） 來部署 VM。
  • 啟用基礎設施加密（雙重加密），適用於需要額外加密層的Azure 儲存體帳號。 在服務和基礎結構層級，這提供了兩層使用不同金鑰的 AES-256 加密。必須在儲存體帳戶建立期間進行設定，因為建立之後無法啟用。

部署機密運算和資料行層級加密：

  • 部署Azure機密虛擬機，搭配機密磁碟加密，適用於處理匯出管制或敏感資料的高度管制工作負載。 搭配 vTPM 系結磁碟加密金鑰，使用 DCasv5/DCadsv5 系列 （AMD SEV-SNP） 或 ECasv5/ECadsv5 系列 （Intel TDX），以確保資料在處理期間保持加密狀態。
  • Azure SQL Database方面，實施Always Encrypted，為高度敏感資料（如社會安全號碼、信用卡號碼、醫療紀錄）提供用戶端欄位層級加密，即使資料對資料庫管理員、雲端營運商及高權限但未授權使用者仍保持加密。 使用 Always Encrypted 搭配安全環域（Intel SGX），以便在加密資料行上執行更豐富的查詢。

監控和強制執行加密合規性：

  • 透過在訂閱或管理群組範圍內，透過設定內建政策，例如「虛擬機應在主機啟用加密」、「儲存帳號應啟用基礎設施加密」以及「應啟用 SQL 資料庫的透明資料加密」等內建政策，Azure 原則 來強制執行加密合規。
  • 使用 Azure Resource Graph 查詢並盤點環境中的加密設定，識別未啟用主機加密的虛擬機、未啟用基礎設施加密的儲存帳號，或未啟用 TDE 的資料庫。

註： 許多Azure服務（Azure 儲存體、Azure SQL Database、Azure Cosmos DB）在基礎設施層預設啟用了靜態資料加密，使用服務管理金鑰，這些金鑰會自動每兩年輪替一次。 如果預設未啟用加密，請根據技術可行性和工作負載需求，在儲存體、檔案或資料庫層級啟用加密。

實作範例

一家跨國製造公司在其 Azure 環境中標準化靜態加密，以保護 ERP 資料、供應鏈應用及工程商業機密。

挑戰： 不一致的加密覆蓋範圍使敏感資料容易受到基礎設施洩露和快照盜竊。 臨時磁碟資料和臨時儲存體仍未加密，造成合規性差距。 如果沒有系統化的加密執行，工程商業機密和供應鏈資料可能會透過被盜磁碟、未經授權的快照或受損的主機代理程式而暴露。

解決方案方法：

  • 為 Azure 虛擬機器啟用主機加密：在訂閱層級註冊 EncryptionAtHost 功能，並使用支援的虛擬機器大小（DSv3、Easv4、Dadsv5 系列）啟用主機加密，加密範圍包括臨時磁碟、作業系統磁碟快取、資料磁碟快取及短暫性作業系統磁碟。
  • 啟用基礎設施加密（雙重加密）以啟用Azure 儲存體： 驗證Azure 儲存體服務加密（SSE）已啟用（預設開啟——AES-256加密），敏感儲存帳號在儲存帳號建立時啟用基礎設施加密（建立後無法啟用），結果是：AES-256 加密的兩層，且使用不同的金鑰。
  • 部署Azure機密虛擬機以支援高度管制工作負載：選擇適當的機密虛擬機系列（AMD SEV-SNP 的 DCasv5/DCadsv5 系列或 Intel TDX 的 ECasv5/ECadsv5 系列），啟用使用平台管理金鑰的機密磁碟加密（將磁碟加密金鑰綁定至 VM 的虛擬 TPM），啟用安全開機與 vTPM 作為認證，部署於處理輸出管制技術資料或高度管制的個人資訊（PII）工作負載，且資料必須保留在處理過程中被加密。
  • 為敏感資料庫欄位實作 Always Encrypted： 識別 Azure SQL Database 中需要欄位層級加密的高度敏感欄位（例如：SSN、信用卡號碼、醫療紀錄號碼），產生欄位加密金鑰（CEK）和欄位主金鑰（CMK），將 CMK 儲存在 Azure Key Vault 中，而 CEK 則用於加密資料欄位，CMK 用於加密 CEK。啟用使用具安全區域的 Always Encrypted（Intel SGX），以允許對加密資料進行更豐富的查詢；使用確定性加密（用於等值查詢）或隨機加密（提供最高安全性）來加密敏感欄位；配置應用程式連接字串時，設置 "Column Encryption Setting=Enabled" 以實現透明加密/解密。
  • Inventory 加密配置，Azure Resource Graph： 查詢未加主機加密的虛擬機及未基礎設施加密的儲存帳號的加密狀態，匯出結果為 CSV 並將修復任務指派給資源擁有者。

結果： 主機加密解決了臨時磁碟資料先前未加密的合規性差距。 工程檔案受到具有兩個加密層的基礎架構加密保護。 機密虛擬機確保出口管制的數據保持加密狀態，即便雲管理員也無法查看。 Always Encrypted 技術保護了敏感的資料庫資料行，資料庫系統管理員確認無法從加密的資料行中讀取純文字，符合合規性要求。

關鍵性層級

必須具備。

控制映射

  • CIS 控制 v8.1： 3.11
  • NIST SP 800-53 修訂版 5： SC-28
  • PCI-DSS v4： 3.5.1、3.6.1
  • NIST CSF v2.0： PR.DS-1
  • ISO 27001：2022 認證： 答：8.24
  • SOC 2： CC6.1

DP-5：視需要在待用數據加密中使用客戶自控密鑰選項

Azure 原則： 請參閱 Azure內建政策定義：DP-5。

安全原則

當法規遵從性、合約需求或資料敏感度需要直接控制加密金鑰生命週期 （包括金鑰產生、輪替和撤銷權限） 時，請使用客戶管理的金鑰。 確保有適當的金鑰管理程序來處理營運額外負荷。

需要減輕的風險

在監管、合約或隔離保證要求租用戶控制的情況下，僅依賴服務管理金鑰會引入合規性和集中風險。 如果沒有正確管理客戶管理的金鑰（CMK）：

  • 監管保證不足： 如果無法證明金鑰保管、輪換節奏或撤銷權限，稽核人員可能會拒絕密碼編譯控制的證據。
  • 撤銷延遲： 無法快速撤銷或輪替遭入侵的平台金鑰，會在認證或供應鏈事件之後延長暴露期間。
  • 管轄權風險： 資料主權授權可能需要租用戶操作或 HSM 支援的金鑰，缺席會損害區域部署的可行性。
  • 跨租戶爆炸半徑： 當密碼編譯隔離不足時，多租用戶平台金鑰洩露可能會對廣泛的資料集造成影響。
  • 影子擴散： 沒有生命週期控管的不規則 CMK 部署會導致孤立、過時或弱金鑰。
  • 營運脆弱性： 輪替自動化不良或缺少相依性對應會導致金鑰變換期間應用程式中斷。

不當或遺漏的 CMK 使用會削弱加密保證，並破壞敏感工作負載的策略合規性定位。

MITRE ATTCK(&C)

  • 認證存取 （TA0006）：未受保護的認證 （T1552）因弱保護或不當分段的平台金鑰導致暴露。
  • 影響 （TA0040）：通過濫用 CMK 輪替/撤銷來對影響（T1486）進行加密，以使資料變得無法存取。
  • 影響（TA0040）：資料操作（T1565）修改加密狀態中繼資料以使保護層失去同步。
  • 外洩 （TA0010）：將資料傳輸到雲端帳戶 （T1537），重新加密資料集並將其匯出到攻擊者控制的儲存中。
  • 資料外流 （TA0010）：透過 Web 服務進行資料外流 （T1567），在正常服務模式下協同進行高容量、已啟用金鑰的大批量匯出。

DP-5.1：必要時在待用資料加密中使用客戶管理的金鑰選項

當法規遵從、資料主權要求或合約義務需要直接控制加密金鑰的保管、輪換排程和撤銷權限時，實施由客戶管理的金鑰。 對於需要終極控制、連 Microsoft 都無法解密的資料的工作負載，可以實作雙重金鑰加密（DKE），讓組織在 Azure 外維持第二把加密金鑰。 使用 Azure Key Vault 或 Managed HSM 來維持加密控制，同時平衡金鑰生命週期管理、災難復原規劃及金鑰管理錯誤可能帶來的服務可用性影響。

評估 CMK 需求並佈建關鍵基礎結構：

  • 評估法規、合規性或業務需求，以判斷哪些工作負載需要 客戶管理的金鑰 （CMK）， 而不是平台管理的金鑰。 常見的驅動因素包括資料主權、稽核要求或直接金鑰保管的合約義務。
  • 配置 Azure Key Vault（標準或高級）或 Azure Key Vault 管理式 HSM 以儲存和管理客戶管理的加密金鑰。 將受控 HSM 用於需要 FIPS 140-3 第 3 級驗證硬體保護的工作負載。
  • 可利用金鑰生成功能在Azure Key Vault內產生加密金鑰，或使用自帶金鑰（BYOK）從本地 HSM 匯入金鑰，以達到最大可攜性與控制。

設定 CMK 並建立金鑰階層：

  • 對於極端控制需求，可實作雙重金鑰加密（DKE）敏感文件需要兩把金鑰來解密：一把由Microsoft（Azure RMS）管理，另一把金鑰則由您的組織在本地或外部金鑰管理服務中獨自管理。 使用 DKE 時，即使法律程序強制，Microsoft 也無法解密你的資料，因為你掌控解密所需的第二把金鑰。
  • 配置以下 Azure 服務（Azure 儲存體、Azure SQL Database、Azure Cosmos DB、Azure 磁碟加密 等）以使用 CMK，並引用至 金鑰保存庫 金鑰的 URI。 啟用 自動金鑰輪換 策略，以減輕手動操作負擔。
  • 建立密鑰加密金鑰（KEK）與資料加密金鑰（DEK）階層其中，KEK（儲存在金鑰保存庫）會加密服務使用的DEK，將金鑰輪替對服務可用性的影響降到最低。
  • 記錄金鑰生命週期程序，包括金鑰輪換排程、遭入侵金鑰的撤銷程序、金鑰淘汰工作流程和災難復原程序。 將金鑰管理整合到您的組織變更管理流程中。

便條： 客戶管理的金鑰需要持續的營運投資，包括金鑰生命週期管理、存取控制管理、監控和災難復原規劃。 在採用 CMK 之前，請確保操作準備就緒，因為不正確的金鑰管理可能會導致資料不可用或遺失。

實作範例

一家受監管的金融機構在 Azure 服務中部署了客戶管理金鑰（CMK），以符合對交易資料及客戶財務紀錄進行直接加密控制的監管要求。

挑戰： 監管審計師需要證明加密控制，包括密鑰託管、輪換權限和撤銷能力。 服務管理的金鑰無法提供租用戶對金鑰生命週期所具備的控制證據。 如果沒有客戶管理的金鑰，組織就無法在安全性事件期間快速撤銷存取權，而且無法滿足區域部署的資料主權需求。

解決方案方法：

  • Provision Azure Key Vault Managed HSM：建立管理型 HSM（FIPS 140-3 Level 3 驗證），至少 3 個 HSM 分割區以確保高可用性，透過匯出安全領域與法定人數金鑰（分割成存放於地理分布的離線保險庫中的金鑰片段）來啟動受管型 HSM，產生加密金鑰（RSA-4096，代號 KEK-Prod-2024），並以金鑰操作：Wrap Key， 解開金鑰，加密，解密。
  • 為 Azure 服務配置客戶管理金鑰： 為 Azure 儲存體 設定儲存帳號使用 CMK 加密類型，選擇 金鑰保存庫 受管理 HSM 作為金鑰來源，啟用使用者指派的管理身份和 Managed HSM 加密服務使用者角色；對於 Azure SQL Database，配置 SQL 資料庫以使用客戶管理的金鑰作為 TDE 保護器，選擇來自受管理 HSM 的金鑰，並啟用自動輪替；為 Azure Cosmos DB 啟用 Cosmos DB 帳號的客戶管理金鑰，選擇受管理的 HSM 金鑰，授予 Cosmos DB 受管理身份存取權限。
  • 實作自動金鑰輪替： 配置以 90 天輪替頻率的輪替政策，啟用自動輪替，設定到期通知（到期前 7 天警示），建立 Key Nearly Expiry 指標的Azure 監視器警示以通知資安團隊。
  • 啟用審計日誌以符合法規：啟用受管理型 HSM（AuditEvent 日誌）的診斷日誌，將日誌傳送至具備不可變儲存的 Log Analytics 工作區（90 天保留以保持防篡改稽核軌跡），查詢金鑰存取日誌以監控加密、解密、包裝金鑰及 UnwrapKey 操作。
  • 記錄關鍵生命週期程序： 建立緊急撤銷操作手冊（關鍵撤銷步驟、事件回應聯絡人、使用安全網域多數鑰匙的復原程序）、每季進行桌面演練以測試操作手冊，並將 CMK 操作整合到 IT 服務管理變更批准工作流程中。

成果： RSA-4096 KEKs 在託管 HSM 中加密服務層級 DEK，用於 Azure 儲存體、SQL 資料庫及 Cosmos DB。 每季自動輪換可僅重新加密 DEK，以將停機時間降至最低。 安全領域仲裁可確保災難復原，即使出現整個區域故障。

關鍵性層級

應該有。

控制映射

  • CIS 控制 v8.1： 3.11
  • NIST SP 800-53 修訂版 5： SC-12、SC-28
  • PCI-DSS v4： 3.5.1、3.6.1、12.3.2
  • NIST CSF v2.0： PR.DS-1、ID.AM-3
  • ISO 27001：2022 認證： 答：8.24
  • SOC 2： CC6.1

DP-6：使用安全金鑰管理程式

Azure 原則： 請參見 Azure內建政策定義：DP-6。

安全原則

實作安全的金鑰管理程序，以控管整個金鑰生命週期：產生、分發、儲存、輪替和撤銷。 使用具有強大存取控制的專用金鑰保管庫服務、維護加密標準、強制執行職責分離，並確保金鑰定期輪換並在遭到入侵時立即撤銷。

需要減輕的風險

弱或未受管理的加密金鑰生命週期會降低加密提供的保證，並可能導致系統性入侵。 沒有結構化金鑰產生、輪換、保護和撤銷：

  • 金鑰擴散與孤立： 未被監控的金鑰長期存在，超出業務必要，保留了不必要的解密權限。
  • 過時的密碼學： 輪替不夠頻繁會增加演算法降階、暴力破解或側通道攻擊的風險。
  • 特權越權： 缺乏角色區隔可讓系統管理員管理和使用金鑰，從而導致內部人員濫用。
  • 未偵測到的入侵： 沒有完整性監控或版本譜系可以掩蓋金鑰是否被惡意替換。
  • 撤銷失敗： 事件回應無法在疑似違規後以加密方式包含資料存取。
  • 層次不一致： 缺少 KEK/DEK 分層會增加旋轉爆炸半徑並增加操作停機時間。

金鑰管理不足會將加密變成一種時間點控制，而不是針對不斷變化的威脅的持續緩解。

MITRE ATTCK(&C)

  • 認證存取 （TA0006）：從密碼存放區 （T1555）提取不當儲存或快取的金鑰材料，或者利用有效帳戶 （T1078）中的廣泛金鑰管理 RBAC 角色，以非法存取或更換這些金鑰。
  • 防禦規避 （TA0005）：削弱加密 （T1600），保留已棄用的演算法/金鑰大小不足，以降低加密強度。
  • 影響（TA0040）：資料銷毀（T1485），執行破壞性清除或錯誤處理的撤銷事件。
  • 影響 （TA0040）：資料操作 （T1565） 取代或變更金鑰版本，以重新導向或停用加密流程。

DP-6.1：建立金鑰管理原則和基礎架構

透過建立集中式金鑰儲存、定義加密標準以及根據工作負載敏感度選擇合適的保護等級，建立加密金鑰管理的治理基礎。 部署 Azure Key Vault 作為金鑰操作的唯一真實來源，同時實施全面的稽核日誌，追蹤所有金鑰存取與管理變更，以達成合規與鑑識目的。

建立集中式金鑰管理基礎設施：

  • 使用Azure Key Vault作為集中式密碼金鑰管理服務，控制整個金鑰生命週期：產生、分發、儲存、輪替及撤銷。
  • 定義並強制執行指定最低密碼編譯標準的關鍵 策略 ：
    • 按鍵類型： RSA（建議：最低 4096 位元或 3072 位元）或 EC（P-256、P-384、P-521 曲線）。
    • 關鍵操作： 根據最低權限原則限制允許的作業 （加密、解密、簽署、驗證、包裝、解除包裝）。
    • 有效期限： 設定啟用和到期日，以強制執行有時間限制的金鑰使用。

選擇適當的金鑰保存庫層：

  • 根據您的工作負載的安全與合規需求，選擇合適的 金鑰保存庫 層級：
    • 受軟體保護的金鑰 （標準和進階 SKU）： FIPS 140-2 第 1 級驗證
    • 受 HSM 保護的金鑰 （進階 SKU）： FIPS 140-2 層級 2 驗證 （共用多租用戶 HSM 後端）
    • 受控 HSM： FIPS 140-3 層級 3 驗證 （專用單一租用戶 HSM 集區）
  • 為了增強安全性，請使用 Azure Key Vault Managed HSM 來提供單租戶及符合 FIPS 140-3 級別 3 驗證的 HSM 保護。 受管 HSM 支援用於備份和災難復原的 密碼編譯網域 。
  • 配置 Azure Key Vault logging，並將日誌路由至 Azure 監視器 或 Microsoft Sentinel，以追蹤所有金鑰存取、輪替事件及行政操作，以供稽核與合規使用。

DP-6.2：實施密鑰生命週期自動化

自動化金鑰輪換並建立金鑰層次結構，以減輕營運負擔、最大限度地減少人為錯誤，並在不中斷服務的情況下實現快速金鑰更換。 實作 KEK/DEK 模式，透過重新加密小型金鑰套件 （而不是整個資料集） 來允許有效率的輪換，並整合災難復原程序，以在區域故障或災難性事件中維護金鑰可用性。

實現自動金鑰輪換：

  • 在Azure Key Vault中實作自動金鑰輪換政策：
    • 根據合規性需求設定輪換頻率 （常見間隔：90 天、180 天或每年）。
    • 啟用輪換通知，以在金鑰到期之前提醒營運團隊。
    • 設定自動輪換以產生新的金鑰版本，無需手動介入。

建立金鑰階層和 BYOK：

  • 建立金鑰階層，將金鑰加密金鑰 （KEK） 和資料加密金鑰 （DEK） 分隔開 來：
    • 將 KEKs 儲存在 Azure Key Vault 中，並有限制存取控制。
    • 產生由 KEK 加密的服務層級 DEK，將金鑰輪換的爆炸半徑降到最低。
    • 輪換 KEK 只需要重新加密 DEK（而不是整個資料集），從而實現零停機時間的高效金鑰輪換。
  • 對於自帶金鑰（BYOK）情境，請在本地FIPS 140-2 Level 2+ HSM中產生金鑰，並使用BYOK轉移金鑰機制，安全地將金鑰匯入Azure Key Vault或受管HSM，並維持金鑰來源與保管的密碼學證明。

實施災難恢復程序：

  • 在次要區域中建立異地複寫的金鑰保存庫。
  • 備份和還原金鑰，以維護跨區域的金鑰可用性。
  • 記錄和測試具有定義的 RTO/RPO 目標的災難恢復程序。

DP-6.3：強制金鑰存取的職責分離

透過將金鑰管理角色與加密操作角色分開，確保沒有單一身分可以同時建立金鑰並將其用於資料加密或解密，從而防止內部威脅和權限濫用。 實施持續監控以檢測異常的關鍵訪問模式並維護全面的關鍵庫存，以便在安全事件或合規性審計期間快速評估影響。

強制職責分離：

  • 實作角色型存取控制 （RBAC） 或存取原則，以強制執行職責分離：
    • 金鑰管理員的個別角色 （可以建立/輪替/刪除金鑰，但無法執行密碼編譯作業）。
    • 金鑰使用者的個別角色 （可以執行加密/解密作業，但無法管理金鑰）。
    • 範例職務：金鑰保存庫 加密專員（管理員）、金鑰保存庫 加密用戶（應用程式/使用者）。
  • 確認沒有單一身分識別同時具有管理和操作金鑰存取權，以防止權限濫用。

監控金鑰存取並維護庫存：

  • 將金鑰存取監控整合於 Microsoft Sentinel 以偵測異常：
    • 異常的金鑰存取模式（從不熟悉的 IP 位址或區域存取）。
    • 大量金鑰操作（短時間內的過度操作）。
    • 非工作時間的管理變更 （金鑰刪除或在工作時間之外輪換）。
  • 維護關鍵庫存追蹤金鑰名稱、用途、輪換排程和相依服務。 在安全性審查期間，定期檢閱清單。

實作範例

一家醫療 SaaS 供應商利用 Azure Key Vault Premium SKU 集中管理加密金鑰，並搭配 HSM 保護的金鑰，實現跨多租戶平台的 PHI 加密。

挑戰： 開發團隊之間分散的金鑰管理導致金鑰蔓延、輪換做法不一致，以及在安全事件期間難以追蹤金鑰使用情況。 過於廣泛的 RBAC 權限允許管理員管理和使用金鑰，從而產生內部風險。 如果沒有自動輪換和職責分離，該組織面臨延長的金鑰洩露窗口和審計合規性失敗。

解決方案方法：

  • Provision Azure Key Vault Premium with HSM 保護金鑰： 建立 Azure Key Vault 的高級層以支援 HSM 保護金鑰，啟用清除保護，防止在保留期間永久刪除，並啟用軟刪除功能，設定 90 天的保留期以允許恢復意外刪除的金鑰。產生具有硬體支援金鑰類型的 RSA-3072 HSM 保護加密金鑰（KEK-PHI-Prod）。
  • 實作自動化金鑰輪替政策： 設定輪替政策為180天輪替頻率，啟用自動輪替並設定通知於到期前30天發出警報，建立Azure 監視器動作群組以在金鑰接近到期時通知安全運營團隊，配置輪替動作以自動產生新金鑰版本。
  • 配置 RBAC 職責分離： 將金鑰保存庫加密官角色分配給安全團隊成員（權限：管理金鑰生命週期但無法執行加密/解密操作），將金鑰保存庫加密使用者角色分配給應用程式管理身份（權限：僅執行加密/解密操作，無金鑰管理權限），透過確保沒有身份同時擁有加密密碼來驗證職責分離官員與加密用戶職務。
  • 建立KEK/DEK階層以促進快速金鑰輪替：在應用程式碼（AES-256金鑰）中產生應用層級資料加密金鑰（DEK）以加密病患資料，將加密的DEK與加密資料並存，使用金鑰保存庫 KEK透過WrapKey操作包裝/加密DEK，解密病患資料時使用UnwrapKey操作檢索與解封DEK，享有以下好處： 輪替 KEK 只需重新加密 DEK，而非整個病患資料庫。
  • 整合金鑰保存庫日誌與 Microsoft Sentinel： 啟用金鑰保存庫診斷設定並將日誌傳送Log Analytics至工作區，建立 Sentinel 分析規則以偵測異常金鑰存取模式、大量金鑰操作及非工作時間管理變更。
  • 自帶金鑰（BYOK）從本地 HSM 傳輸： 從 金鑰保存庫 下載 BYOK 傳輸金鑰，從本地 HSM 匯出金鑰，並使用 金鑰保存庫 的 BYOK 傳輸公鑰進行封裝，保持密鑰血統的密碼學證明，將封裝後的金鑰匯入 金鑰保存庫，確保在無明文暴露的情況下以 HSM 保護。

結果： RSA-3072 金鑰每 180 天輪換一次，並具有自動通知。 RBAC 分離可防止權限濫用。 KEK/DEK 階層透過僅重新加密 DEKs 來實現快速旋轉。 誤刪的金鑰可以使用軟刪除功能來復原。 Microsoft Sentinel 能偵測異常，例如不熟悉的 IP 存取或非工作時間的修改。

關鍵性層級

必須具備。

控制映射

  • CIS 控制 v8.1： 不適用
  • NIST SP 800-53 修訂版 5： IA-5、SC-12、SC-28
  • PCI-DSS v4： 3.6.1、8.3.2
  • NIST CSF v2.0： PR.AC-1, PR.DS-1
  • ISO 27001：2022 認證： A.8.24、A.8.3
  • SOC 2： CC6.1、CC6.2

DP-7：使用安全的憑證管理程序

Azure 原則： 參見 Azure內建政策定義：DP-7。

安全原則

透過集中式流程管理憑證生命週期，包括庫存、自動續約、強大的加密標準和及時撤銷。 確保關鍵服務的憑證在到期前得到追蹤、監控和更新，以防止服務中斷並維護安全的加密通訊。

需要減輕的風險

管理不善的憑證生命週期會導致服務中斷、削弱加密通道並允許模擬。 在沒有集中庫存、政策執行和自動續約的情況下：

  • 意外過期： 失效的憑證會觸發生產中斷、中斷 API、身分識別聯合或用戶端信任路徑。
  • 弱密碼學持久性： 舊版金鑰大小/簽章演算法 （例如 SHA-1、RSA < 2048） 在棄用後仍會使用。
  • 萬用字元和自我簽署濫用： 範圍廣泛或未經管理的自我簽署憑證能引發橫向冒充和 TLS 降級風險。
  • 未偵測到的入侵： 被盜的私鑰允許透明的中間人或流量解密，直到輪換。
  • 影子憑證： 未經授權的發行在核准的 CA 之外，會破壞治理並增加撤銷盲點。
  • 手動續費錯誤： 不一致的替換順序會導致信任鏈不匹配和部分環境漂移。

憑證管理不足會降低加密保證，並在關鍵服務中引入可靠性和安全性不穩定性。

MITRE ATTCK(&C)

  • 防禦規避 （TA0005）：破壞信任控制 （T1553），發行或引入欺詐/惡意憑證以繞過驗證。
  • 資源開發 （TA0042）：開發能力 （T1587） 偽造憑證或工具，以備將來入侵階段使用。
  • 防禦規避（TA0005）：削弱加密（T1600）繼續使用過時的簽名演算法，降低驗證保證。
  • 認證存取 （TA0006）：未受保護的認證 （T1552） 從不安全的檔案存放區或進程記憶體擷取私密金鑰。
  • 持續性 （TA0003）：修改驗證程式 （T1556） 重寫憑證型驗證流程，以內嵌長期存取。

DP-7.1：建立憑證原則和 CA 整合

定義憑證控管標準並整合受信任的憑證授權單位，以確保整個基礎架構的加密品質一致和自動發行。 建立強制執行現代金鑰大小、簽章演算法和有效期間的原則，同時消除自我簽署憑證和萬用字元憑證等風險做法，這些做法會在私密金鑰外洩時擴大攻擊面。

建立憑證管理基礎設施：

  • 使用 Azure Key Vault集中管理完整的憑證生命週期：建立、匯入、續約、輪替、撤銷及安全刪除。
  • 在Azure Key Vault中定義憑證政策以強制執行組織安全標準：
    • 按鍵類型和尺寸： RSA 2048 位元起碼 （建議：長存期憑證的 3072 位元或 4096 位元）;EC P-256 或更高版本適用於橢圓曲線證書。
    • 簽名演算法： SHA-256 或更強（禁止 SHA-1 和 MD5）。
    • 有效期限： 公用 TLS 憑證最多 397 天 （根據 CA/瀏覽器論壇基準要求）;建議縮短持續時間（90 天）以減少暴露。
    • 憑證授權單位： 僅使用核准的整合式 CA （DigiCert、GlobalSign） 或您組織的私有 CA。

整合憑證授權單位：

  • 使用與 Azure Key Vault 整合的合作夥伴憑證授權機構來取得公開的 TLS/SSL 憑證：
    • DigiCert： 組織驗證 （OV） TLS/SSL 憑證
    • 環球簽名： 組織驗證 （OV） TLS/SSL 憑證
  • 對於私人/內部服務，請將組織內部憑證授權中心（例如 Active Directory 憑證服務 - ADCS）整合至 Azure Key Vault，以實現自動憑證發放。
  • 避免在生產環境中使用自我簽署憑證和萬用字元憑證：
    • 自我簽署憑證： 缺乏第三方驗證，無法透過公共 CRL/OCSP 撤銷，並且被現代瀏覽器/用戶端拒絕。
    • 萬用字元憑證：如果遭受損害，範圍廣泛會增加風險。請改用具有明確 FQDN 的主體替代名稱（SAN）憑證。

註： 對於簡單的情境，你可以使用 Azure App 服務 Managed Certificates（免費且自動更新的自訂網域憑證）。

DP-7.2：實作自動憑證更新

透過自動化在到期前觸發的續約工作流程，消除因憑證過期而導致的服務中斷，並在相依服務之間無縫更新憑證，而無需手動介入。 配置 Azure 服務，利用管理身份自動從 金鑰保存庫 檢索更新憑證，減少營運負擔，並消除假日或員工交接期間遺忘手動續期的風險。

設定自動續訂：

  • 在Azure Key Vault中啟用自動憑證更新，方法是設定終身操作以憑證存續時間的指定百分比觸發續期：
    • 建議觸發：有效期的 80-90%（例如，397 天證書的有效期約為 318 天）。
    • 操作：自動續約（金鑰保存庫 無需人工介入即可向 CA 申請續約）。
  • 設定通知連絡人，以在自動續約觸發之前提醒系統管理員憑證即將到期。

啟用自動憑證繫結：

  • 對於支援自動憑證輪換的 Azure 服務（Azure App 服務、Azure 應用程式閘道、Azure Front Door），設定這些服務能自動從 金鑰保存庫 取得更新的憑證使用受管理身份或服務主體並搭配適當的 金鑰保存庫 存取政策：
    • Azure 服務在續約時會自動綁定新的憑證版本（通常在 24 小時內，無需重新啟動服務）。
  • 對於無法自動消耗金鑰保存庫憑證的應用程式，應實施手動憑證輪替工作流程，搭配操作手冊與監控警示，以防止因過期相關故障發生。
  • 維護 Azure Key Vault 中所有憑證的清單，追蹤憑證名稱、用途、到期日、受依服務及續期狀態。

DP-7.3：監控憑證生命週期並處理撤銷

透過自動監控、庫存查詢和儀表板來保持憑證健康情況的持續可見性，這些儀表板顯示即將到期的憑證、使用已棄用的密碼編譯或缺乏適當的治理。 為受損的憑證建立快速撤銷程序，並與產業威脅情報整合，以主動阻止受損憑證授權單位頒發的憑證，以免它們啟用中間人攻擊。

設定監控和警示：

  • 設定 Azure 監視器 alerts 以應對憑證過期事件：
    • 在到期前 30 天建立警示 （警告通知）。
    • 在到期前 7 天建立警示 （重大警示，並呈報至安全性小組）。

維護憑證庫存和儀表板：

  • 使用 Azure Resource Graph 查詢憑證清單：
    • 查詢即將到期的憑證 （30/60/90 天內）。
    • 查詢自我簽署憑證。
    • 使用已棄用的演算法 （例如 SHA-1） 查詢憑證。
  • 建立憑證稽核儀表板（例如 Power BI），並附上視覺化：
    • 憑證到期時間表，按時間範疇分類。
    • 按資源群組的自簽憑證數量。
    • 使用已棄用密碼編譯標準的憑證。
  • 在安全性檢閱會議期間定期檢閱憑證稽核儀錶板 （建議：每季一次）。

建立撤銷程序：

  • 建立已受損或已停用憑證的憑證撤銷程序：
    • 文件撤銷程序（在 金鑰保存庫 中停用憑證，通知受依賴服務）。
    • 維護憑證入侵案例的事件回應執行手冊。
    • 監控行業建議是否有受損的根或中間 CA 證書，並及時阻止它們。

實作範例

一個擁有 200+ 個面向公眾的網頁應用程式的企業，使用 Azure Key Vault 集中式憑證生命週期管理，並整合 DigiCert 作為憑證授權機構。

挑戰： 當憑證意外過期時，手動憑證更新程序會導致多次生產中斷。 當私鑰被洩露時，萬用字元證書會產生過大的爆炸半徑。 跨團隊的碎片化憑證管理導致影子憑證、不一致的加密標準以及安全事件期間的延遲撤銷。 如果沒有自動續訂和集中庫存，組織將面臨合規性失敗和服務中斷。

解決方案方法：

  • 配置憑證授權機構與 Azure Key Vault 的整合：新增 DigiCert（或其他合作憑證授權機構）至 金鑰保存庫，使用 API 憑證進行自動化的憑證請求。
  • 建立符合安全標準的憑證政策： 定義憑證政策，包含憑證名稱（www-contoso-com-2024）、發行者（DigiCert）、主題（CN=www.contoso.com）、DNS名稱（SAN：www.contoso.com、api.contoso.com、portal.contoso.com - 避免萬用字憑證）、金鑰類型（RSA 4096位元）、簽章演算法（SHA-256）、有效期（依CA/瀏覽器論壇基準，最大397天），設定自動續期的操作（將觸發設定在憑證有效期的80%，約為397天中的318天），動作：自動續期（金鑰保存庫 不需人工參與即可向 DigiCert 申請續期）。
  • 設定Azure服務的自動憑證綁定： 若要Azure App 服務從金鑰保存庫匯入憑證，請指派使用者指派的管理身份並金鑰保存庫 Secrets 使用者角色，啟用自動憑證更新（App Service 在續約後 24 小時內綁定新憑證版本，無需重新啟動）;對於 Azure 應用程式閘道，設定監聽器從 金鑰保存庫 擷取憑證，並指派使用者指派的管理身份，並以 金鑰保存庫 Secrets User 和 Certificates User 角色分配，Application Gateway 在 金鑰保存庫 更新憑證時自動取得更新後的憑證。
  • 設定憑證過期警示： Azure 監視器建立兩條警示規則——30天過期警告（通知平台工程Slack頻道）、7天到期關鍵警示（開啟Jira工單人工審查並寄信給資安團隊）。
  • 取消萬用符憑證，改用 SAN 憑證： 在 金鑰保存庫 中審核現有的萬用符憑證（*.contoso.com），並以包含明確 DNS 名稱的 SAN 憑證（www.contoso.com、api.contoso.com）取代，優點是：若私鑰被洩漏，僅列出的 FQDN 會受影響（非所有子網域）。
  • 監控憑證到期： 使用Azure Resource Graph查詢憑證清單並識別即將到期的憑證（30 天內）、自簽憑證或使用已淘汰 SHA-1 簽章演算法的憑證，並在安全審查會議期間每季檢視儀表板。

結果： 自動憑證續約會在 80% 有效期觸發。 Azure App 服務 與 Application Gateway 會透過管理身份在 24 小時內取得更新的憑證（無需重啟）。 Azure 監視器 alerts 會在到期前通知平台工程團隊。 SAN 憑證取代萬用字元憑證，減少入侵爆炸半徑。

關鍵性層級

必須具備。

控制映射

  • CIS 控制 v8.1： 不適用
  • NIST SP 800-53 修訂版 5： IA-5、SC-12、SC-17
  • PCI-DSS v4： 3.6.1、8.3.2
  • NIST CSF v2.0： PR.AC-1、ID.AM-3
  • ISO 27001：2022： A.8.3
  • SOC 2： CC6.1、CC6.2

DP-8：確保金鑰和憑證儲存庫的安全性

Azure 原則： 參見 Azure內建政策定義：DP-8。

安全原則

透過深度防禦控制來保護金鑰保存庫服務：最小權限存取、網路隔離、全面的記錄和監控、備份和復原功能，以及必要時提供 HSM 支援的保護。 金鑰保存庫是保護用於加密和驗證的加密金鑰和憑證的重要基礎設施。

需要減輕的風險

金鑰和憑證儲存庫的入侵會使上游加密、簽署和身分保證無效。 如果沒有強化保管庫的存取、監控和隔離：

  • 密鑰外洩： 被盜的 KEK/HSM 材料允許批量解密存儲的數據和流量攔截。
  • 影子管理存取權： 過於廣泛的 RBAC 或原則配置錯誤可能導致非法的金鑰匯出、清除或版本回退。
  • 靜音篡改： 惡意金鑰替換可實現透明的中間人或偽造的程式碼/簽名。
  • 網路曝光： 公用端點濫用（身份憑證填充攻擊、API 探測）會增加暴力破解攻擊或權杖重播攻擊的攻擊面。
  • 意外破壞行為： 缺少軟刪除/清除保護會導致不可逆轉的加密數據丟失。
  • 稽核譜系不足： 缺乏不可變日誌會損害事件回應和監管證據需求。
  • 未分段租用戶： 混合交織的應用程式金鑰在單一身分外洩後增大了橫向移動的風險範圍。

儲存庫弱點會迅速擴散到相依工作負載，導致其系統的機密性、完整性和可用性失效。

MITRE ATTCK(&C)

  • 認證存取 （TA0006）：透過錯誤設定的保存庫角色或網路原則取得的未受保護認證/認證存放區 （T1552/T1555）。
  • 防禦規避 （TA0005）：中間對手 （T1557） 擷取保存庫繫結流量以進行金鑰/憑證攔截，或削弱加密 （T1600），以攻擊者控制的資料取代強式金鑰。
  • 權限提升（TA0004）：有效帳戶（T1078）利用過於廣泛的保管庫操作角色來列舉和變更秘密。
  • 影響 （TA0040）：資料銷毀/禁止復原 （T1485 / T1490） 執行破壞性清除序列，以防止還原。

DP-8.1：為 金鑰保存庫 實施存取控制

藉由強制執行嚴格的身分識別型存取控制來保護基礎結構的密碼編譯基礎，以防止未經授權的金鑰存取、將系統管理許可權限制在合理的時間範圍，以及透過受控識別消除認證儲存體。 在金鑰管理員和金鑰使用者之間實施職責分離，以防止任何單一受損的身分識別同時管理和利用加密材料。

實施 RBAC 和職責分離：

  • 實作 Azure RBAC 以執行最低權限存取控制（金鑰保存庫：
    • 對於 Azure Key Vault 管理型 HSM： 在個別金鑰、秘密與憑證層級使用 本地 RBAC，並內建角色（管理 HSM 加密官、加密用戶、加密稽核員）。
    • 針對 Azure Key Vault標準/高級版： 為每個應用程式或環境建立專用的保險庫，以強制邏輯分離，並指派具有特定應用範圍的 RBAC 角色（金鑰保存庫管理員、機密官、憑證官）。
  • 強制執行職責分離：將金鑰管理的角色 （誰可以建立/輪替金鑰） 與密碼編譯作業 （誰可以使用金鑰進行加密/解密） 分開。

使用受控識別和 JIT 存取：

  • 使用 managed identities來存取Azure資源（App Services、虛擬機、Azure Functions等），以存取金鑰保存庫，而非將憑證儲存在應用程式碼或設定檔中。 受控識別可消除認證儲存體和輪替複雜性。
  • 實施Microsoft Entra Privileged Identity Management （PIM）以適時指派行政權限存取金鑰保存庫：
    • 設定符合資格的 金鑰保存庫 管理員角色指派（非永久指派）。
    • 需要理由、MFA 和核准才能啟用。
    • 設定最長啟動持續時間（例如，8 小時）。
    • 定期進行存取審查，撤銷不必要的常設權限。

DP-8.2：Harden 金鑰保存庫 網路安全

透過將所有 金鑰保存庫 存取路由虛擬網路內的私有端點，消除面向網際網路的攻擊面，防止憑證填充、暴力破解嘗試及外部威脅行為者的偵察。 如果在 CI/CD 情境中無法避免公眾存取，請實作嚴格的 IP 允許清單和防火牆規則，以建立盡可能小的暴露窗口。

部署Private Link並設定防火牆：

  • 利用 Azure Private Link 安全網路存取 Azure Key Vault，從 VNet 建立私密連線，不讓 金鑰保存庫 暴露於公共網際網路。
  • 設定 金鑰保存庫 firewall，限制對特定 IP 範圍或 VNet 的存取，以應對無法Private Link的情況：
    • 盡可能關閉公開存取（金鑰保存庫 只能透過私人端點存取）。
    • 如果需要公開存取 （例如，針對 CI/CD 管道），請僅允許從具有狹窄 IP 允許清單的選取網路存取。
  • 建立 私人 DNS 區域 （例如 privatelink.vaultcore.azure.net） 並將其連結至 VNet，以確保私人端點的正確 DNS 解析。

DP-8.3：啟用 金鑰保存庫 保護與監控

實作深度防禦保護，透過軟刪除和清除保護防止不可逆的加密資料遺失，同時使用 HSM 支援的金鑰，以滿足需要 FIPS 驗證安全性的生產工作負載。 透過 Microsoft Defender for 金鑰保存庫 與 Microsoft Sentinel 部署全面監控，偵測異常存取模式、異常金鑰操作及行政異常，這些都顯示出入侵、內部威脅或針對您的加密基礎設施的偵察活動。

啟用虛刪除和清除保護：

  • 啟用所有Azure金鑰庫的 soft delete 和 purge protection，以防止金鑰、秘密與憑證被意外或惡意刪除：
    • 虛刪除允許在保留期間內復原 （預設值：90 天）。
    • 清除保護可防止在保留期間永久刪除。
    • 透過 Azure 原則 內建的政策強制執行這些設定：「金鑰保險庫應該啟用軟刪除」和「金鑰金庫應該啟用清除保護」（deployIfNotExists 效果）。
  • 實施關鍵生命週期策略以避免加密刪除數據：
    • 清除加密資料之前，請確認加密金鑰已保留所需的資料保留期間。
    • 解除委任金鑰時，請使用 停用 作業而不是 刪除 ，以防止意外資料遺失，同時維護金鑰中繼資料以供稽核之用。
    • 建立並測試金鑰保存庫備份災難復原情境的程序。

使用 HSM 支援的金鑰和自帶金鑰 (BYOK)：

  • 針對需要強大密碼編譯保護的生產工作負載使用 HSM 支援的金鑰 ：
    • Azure Key Vault Premium：由 FIPS 140-2 第二級驗證的 HSM（共享多租戶）保護的 RSA-HSM 和 EC-HSM 金鑰。
    • Azure Key Vault 受管理的 HSM：由 FIPS 140-3 第三級驗證的 HSM（專用單租戶池）保護的 RSA-HSM 和 EC-HSM 金鑰。
  • 在自帶金鑰（BYOK）情境下，請在本地FIPS 140-2 Level 2+ HSM中產生金鑰，並使用BYOK金鑰轉移機制安全地將金鑰匯入Azure Key Vault，同時維持密鑰來源與保管的密碼學證明。

啟用監控和威脅偵測：

  • 啟用診斷記錄以供 Azure Key Vault 使用，並將日誌路由至 Azure 監視器、Log Analytics 或 Microsoft Sentinel，從而捕捉所有管理平面和資料平面的操作。 監控可疑活動，包括異常金鑰存取模式、身份驗證嘗試失敗和管理變更。
  • 啟用 Microsoft Defender 用於 金鑰保存庫偵測異常存取模式、異常金鑰操作，以及潛在威脅，如憑證濫用、可疑金鑰擷取或管理異常。 將 Defender for 金鑰保存庫 警示整合到事件應變工作流程中。
  • 將金鑰保存庫日誌與 Microsoft Sentinel整合，建立分析規則，偵測異常區域存取、潛在暴力破解嘗試或可疑的行政操作。 實作自動回應教戰手冊，以隔離受損的身分並通知安全團隊。

註： 所有金鑰保存庫 SKU 設計上都阻止金鑰匯出;加密操作在安全的 HSM 邊界內執行。 切勿在 Azure Key Vault 之外以明文匯出或儲存金鑰。

實作範例

一家跨國科技公司為其 Azure Key Vault 基礎設施實施了防禦深度安全，保護加密金鑰、API 秘密及 500+ 微服務的 TLS 憑證。

挑戰： 過於廣泛的 RBAC 許可權可讓開發人員直接存取生產 Key Vault，從而產生內部風險和合規性違規。 對公共互聯網的暴露使得撞庫攻擊和偵察嘗試成為可能。 如果沒有全面的監控和自動響應，可疑的密鑰訪問模式就無法被發現。 缺乏軟刪除和清除保護可能會導致事件期間永久遺失加密資料。

解決方案方法：

  • 部署專用的金鑰庫以進行邏輯分段：為每個環境和業務單位建立一個金鑰庫，並遵循命名規則 kv-{businessunit}-{environment}-{region}（例如，kv-finance-prod-eastus2、kv-finance-dev-eastus2），在每個環境中部署於不同的資源群組中以強制隔離（被入侵的開發服務主體無法存取生產金鑰）。
  • 設定 RBAC 以進行最低權限存取：對於非生產的金鑰庫（開發/暫存）請將金鑰保存庫秘密使用者（唯讀）指派給開發者安全群組——開發者可以在開發/暫存中讀取秘密，但對生產的金鑰庫完全沒有存取權;對於生產型金鑰庫，將金鑰保存庫秘密使用者指派給 CI/CD 服務主體（Azure DevOps管線管理身份），限制範圍為特定命名秘密，且無法互動開發者存取生產金鑰。
  • 使用 Azure Private Link 強化網路安全：部署私有端點用於 金鑰保存庫（選擇 VNet 和子網，建立私有 DNS 區域 privatelink.vaultcore.azure.net 並連結到 VNet），配置 金鑰保存庫 防火牆（禁用公眾訪問，僅可通過私有端點訪問。如果需要提供對 CI/CD 的公眾訪問，則僅允許選定網路從經過核准的 Azure VNet 子網和 CI/CD 代理 IP 地址範圍訪問）。
  • 啟用 Microsoft Defender for 金鑰保存庫：在訂閱層級啟用 Microsoft Defender 以保護 金鑰保存庫，Defender 會監控各種異常行為，包括異常的地理位置訪問、可疑的列舉（例如快速清單操作顯示偵察）、異常的管理操作（例如大量刪除秘密）。
  • 整合Microsoft Sentinel以實現自動回應： 為 Sentinel 新增適用於雲端的 Microsoft Defender資料連接器，建立針對異常區域存取、潛在暴力破解、可疑管理操作的 Sentinel Analytics 規則，配置自動回應手冊以停用可疑身份並通知資安團隊。
  • 將診斷日誌串流至 Log Analytics：啟用 金鑰保存庫 的診斷記錄，包括 AuditEvent（所有金鑰/秘密/憑證操作）和 AllMetrics（使用頻率、延遲），並將其傳送至 Log Analytics 工作區，保留兩年。建立自訂 KQL 查詢以偵測異常活動，包括潛在的暴力破解偵測（5 分鐘內超過 10 次未授權嘗試），以及關閉軟刪除操作（作為破壞行為的指標）。
  • 實作即時管理員存取權，Microsoft Entra PIM： 配置符合資格的 金鑰保存庫 管理員角色（將安全團隊成員設為合格而非永久指派，啟用時需提供理由並進行多重身份驗證，設定最長啟用期限為 8 小時，並需資深安全架構師的批准），每季度進行所有 金鑰保存庫 管理員角色指派的存取審查；撤銷不必要的存取權限。

結果： 每個環境的專用金鑰保存庫會強制執行分段。 RBAC 將開發人員限制為唯讀非生產存取。 Private Link 消除了公共網路暴露。 Microsoft Defender 偵測異常。 Sentinel 腳本會自動停用可疑帳號。 PIM 支援即時管理訪問，顯著減少常設權限。

關鍵性層級

必須具備。

控制映射

  • CIS 控制 v8.1： 不適用
  • NIST SP 800-53 修訂版 5： IA-5、SC-12、SC-17
  • PCI-DSS v4： 3.6.1、8.3.2
  • NIST CSF v2.0： PR.AC-1, PR.DS-1
  • ISO 27001：2022 認證： A.8.3、A.8.24
  • SOC 2： CC6.1、CC6.2
  • 上次更新時間：