共用方式為


設定客戶金鑰

客戶金鑰讓您能控制組織的加密金鑰,並設定 Microsoft 365 使用這些金鑰來加密您在 Microsoft 資料中心的靜態資料。 換句話說,它讓你能新增一層你擁有並管理的加密層。

在使用 Customer Key 之前,你需要先設定所需的 Azure 資源。 本文將帶你了解如何建立與配置這些資源,接著說明啟用客戶金鑰的步驟。 設定好 Azure 資源後,你可以選擇適用哪些政策,進而決定哪些金鑰能在你組織內的 Microsoft 365 工作負載中加密資料。

欲了解一般概述及更多資訊,請參閱 客戶金鑰概覽

重要事項

請務必遵循本文標示為 TIPIMPORTANTNOTE 的最佳實務。 客戶金鑰讓你能控制可能影響整個組織的根加密金鑰。 這些金鑰的錯誤可能導致服務中斷或永久資料遺失。

重要事項

Microsoft 建議您使用權限最少的角色。 以全域管理員角色最小化使用者數量,有助於提升組織的安全。 了解更多關於 Microsoft Purview 角色與權限的資訊。

在你設定客戶金鑰之前

在開始之前,請確保你的組織擁有正確的 Azure 訂閱;以及 Microsoft 365、Office 365 和 Windows 365 授權。 你必須使用付費的 Azure 訂閱。 透過免費、試用、贊助、MSDN 或 Legacy 支援計畫取得的訂閱不符合資格。

重要事項

提供 Microsoft 365 客戶金鑰的 Microsoft 365 與 Office 365 授權包括:

  • Office 365 E5
  • Microsoft 365 E5
  • Microsoft Purview 套件 (前稱為Microsoft 365 E5 合規性)
  • Microsoft 365 E5 資訊保護 & 治理 SKU
  • Microsoft 365 FLW 的安全與合規

現有的 Office 365 進階合規性授權仍被支援。

為了更好地理解本文中的概念與程序,請參考Microsoft Azure 金鑰保存庫文件。 你也應該熟悉 Azure 中的關鍵術語,例如 Microsoft Entra 租戶

如果你需要文件以外的協助,請聯絡 Microsoft 支援服務。 若想對客戶鑰匙或本文件分享回饋或建議,請造訪 Microsoft 365 社群

設定客戶金鑰的步驟概述

要設定客戶金鑰,請依序完成以下任務。 本文其餘部分會詳細說明每個任務,或連結到流程中每個步驟的更多資訊。

請使用 Azure PowerShell 完成以下先決條件。 建議 (v4.4.0 或更高版本) :

重要事項

設定流程會因你使用的是Azure 金鑰保存庫還是管理型 HSM 而有所不同。 共享的前置條件先出現,接著是配置專屬的指示。

所有配置的前提條件

配置專屬設定

最後步驟

建立兩個新的 Azure 訂閱

客戶金鑰需要兩個 Azure 訂閱。 作為最佳實務,Microsoft 建議為客戶金鑰創建新的 Azure 訂閱。

Azure 金鑰保存庫 金鑰只能授權於同一Microsoft Entra租戶中的應用程式。 要為 DEP () 指派資料加密政策,務必在你組織使用的同一Microsoft Entra租戶下建立兩個訂閱。 例如,使用你在組織中擁有適當管理員權限的工作或學校帳號。 如需逐步指引,請參閱「註冊 Azure 作為組織」。

重要事項

客戶金鑰每個 DEP 需要兩把鑰匙。 為了支援這項要求,您必須建立兩個獨立的 Azure 訂閱。 作為最佳實務,讓組織中不同成員在每個訂閱中管理一把金鑰。 這些訂閱僅用於管理 Microsoft 365 的加密金鑰。 此配置有助於保護您的組織,防止有人意外、故意或惡意刪除或管理不當的金鑰。

你的組織能建立多少 Azure 訂閱,實際上沒有限制。 遵循這些最佳實務有助於降低人為錯誤風險,並使管理客戶關鍵資源更為簡便。

註冊所需的服務負責人

要使用客戶金鑰,您的租戶必須註冊所需的服務主體。 以下章節將說明如何檢查服務負責人是否已在您的租戶中註冊。 如果沒有,就執行 「New-AzADServicePrincipal」 這個 cmdlet。

註冊客戶金鑰入職應用程式的服務負責人

要檢查客戶金鑰入職應用程式是否已註冊並取得正確權限,請執行以下指令:

Get-AzADServicePrincipal -ServicePrincipalName 19f7f505-34aa-44a4-9dcc-6a768854d2ea

如果沒有註冊,請執行:

New-AzADServicePrincipal -ApplicationId 19f7f505-34aa-44a4-9dcc-6a768854d2ea
註冊 M365DataAtRestEncryption 應用程式的服務主體

要檢查 M365DataAtRestEncryption 應用程式是否已註冊並取得正確權限,請執行以下指令:

Get-AzADServicePrincipal -ServicePrincipalName c066d759-24ae-40e7-a56f-027002b5d3e4

如果沒有註冊,請執行:

New-AzADServicePrincipal -ApplicationId c066d759-24ae-40e7-a56f-027002b5d3e4
註冊服務負責人以申請Office 365 Exchange Online

要檢查Office 365 Exchange Online應用程式是否已註冊並取得正確權限,請執行以下指令:

Get-AzADServicePrincipal -ServicePrincipalName 00000002-0000-0ff1-ce00-000000000000

如果沒有註冊,請執行:

New-AzADServicePrincipal -ApplicationId 00000002-0000-0ff1-ce00-000000000000

配置專屬設定步驟

重要事項

以下步驟會因你使用的是Azure 金鑰保存庫管理型 HSM 而有所不同。 請使用下方分頁選擇您的配置。

在每個訂閱中建立一個高級Azure 金鑰保存庫

在建立金鑰保險庫之前,請先使用者入門Azure 金鑰保存庫執行這些步驟。 以下步驟引導你安裝與啟動 Azure PowerShell,並連接訂閱。 接著,建立資源群組和金鑰保險庫。

重要事項

建立金鑰保險庫時, 您必須 在初始建立保險庫時啟用 軟刪除清除保護 。 客戶金鑰要求所有保險庫同時啟用這兩個功能,保留期限為 90 天。 這些設定一旦啟用就無法停用,因此從一開始正確設定非常重要。

建立金鑰保險庫時,必須選擇一個 SKU:Standard 或 Premium。 Standard SKU 使用軟體保護的金鑰,無需硬體安全模組 (HSM) ,而高級 SKU 則允許使用 HSM 保護金鑰。 客戶金鑰支援兩個 SKU 中的任一的金鑰庫,但 Microsoft 強烈建議使用高級 SKU。 兩者的營運成本相同;所以,唯一的價格差異來自每個 HSM 保護金鑰的每月費用。 價格詳情請參見金鑰保存庫價格

重要事項

使用Premium SKU金鑰庫和HSM保護金鑰來處理生產資料。 僅用於測試與驗證時,使用 Standard SKU 的金鑰庫與金鑰。

啟用軟刪除與清除保護

當您能快速恢復鑰匙時,因意外或惡意刪除而導致服務中斷的機率較低。 這個恢復功能稱為軟刪除。 它允許你在 90 天內恢復已刪除的金鑰或保險庫,無需從備份還原。 客戶金鑰要求所有保險庫 必須啟用 軟刪除,且保留期限為 90 天。 軟刪除會自動啟用給新的 Azure Key Vault。 如果你用的是沒有開啟的現有保險庫,可以手動啟用。

當清除保護開啟時,處於刪除狀態的保險庫或物件必須在保留期結束前無法被清除。 軟刪除的保險庫與物件仍可恢復,確保保留政策得以遵守。

要啟用軟刪除與清除保護,請參考Azure 金鑰保存庫Azure 金鑰保存庫軟刪除與清除保護的復原管理

針對你使用客戶金鑰的每個 Microsoft 365 工作負載,在你先前設定的兩個 Azure 訂閱中分別建立一個金鑰保險庫。

金鑰保存庫配置

舉例來說,如果你在多個工作負載中使用客戶金鑰,Exchange和SharePoint情境,你需要 三對 金鑰庫,總 共六組。 使用明確的命名規則,反映你所關聯的 DEP 的預期用途。 下表說明如何將每個Azure 金鑰保存庫映射到每個工作負載。

金鑰保存庫名稱 多重 Microsoft 365 工作負載的權限 (M365DataAtRestEncryption) 交換許可 SharePoint 與 OneDrive 的權限
康托索M365AKV01
康托索M365AKV02
ContosoEXOAKV01
康托索EXOAKV02
ContosoSPOAKV01
ContosoSPOAKV02

保險庫配置

建立金鑰保險庫也需要設定 Azure 資源群組。 關鍵保險庫需要少量儲存空間,若啟用日誌 () 也會儲存資料。 作為最佳實務,Microsoft 建議指派不同的管理員來管理每個資源群組。 這些角色應與負責管理相關客戶金鑰資源的管理員保持一致。

對 Exchange 來說,DEP 的範圍是信箱層級。 每個信箱只能指派一項政策,且最多可建立 50 個政策。 SharePoint 政策涵蓋組織地理位置 (或地理) 中的所有資料,而多工作負載政策則涵蓋組織中所有使用者所支援的工作負載。

重要事項

如果你使用 Customer Key for Multiple Workloads、Exchange、SharePoint 和 OneDrive,務必為每個工作負載建立兩個 Azure Key Vault。 這表示你需要總共六個鑰匙庫。

為每個Azure 金鑰保存庫分配權限

利用Azure基於角色的存取控制 (Azure Azure 入口網站中的 RBAC) ,為每個金鑰庫分配所需權限。 本節說明如何使用 RBAC 套用正確的權限。

使用 RBAC 方法分配權限

若要在您的Azure 金鑰保存庫上指派 (wrapKey、 和 getunwrapKey) ,請將金鑰保存庫加密服務使用者角色指定給適當的 Microsoft 365 應用程式。 請參見授權應用程式使用 Azure RBAC 存取Azure 金鑰保存庫

指派角色時,請在租戶中搜尋以下應用程式名稱:

  • 多重工作負載M365DataAtRestEncryption

  • 交換Office 365 Exchange Online

  • SharePoint 與 OneDriveOffice 365 SharePoint Online

如果你找不到你想要的應用程式,務必在 租戶中註冊該應用程式

欲了解更多關於分配角色與權限的資訊,請參閱「使用基於角色的存取控制來管理您對 Azure 訂閱資源的存取」。

指派使用者角色

客戶金鑰需要金鑰保存庫管理員與金鑰保存庫貢獻者共同管理並保障加密金鑰的存取權限。

  • 金鑰保存庫管理員負責日常管理任務,如備份建立取得匯入列出還原。 設計上,他們沒有刪除鍵的權限。 此設計有助於防止永久性資料遺失。 僅暫時且謹慎地使用貢獻者角色授予刪除權限。

  • 金鑰保存庫貢獻者可以管理權限並在金鑰保存庫中指派角色。 利用這個角色來控制團隊成員加入或離開時的存取權限。

關於如何使用 Azure RBAC 指派這些角色的詳細步驟,請參閱 Azure 內建角色用於金鑰保存庫資料平面操作

透過建立或匯入金鑰,為每個金鑰保存庫新增一把金鑰

新增Azure 金鑰保存庫金鑰有兩種方式:你可以直接在保險庫中建立金鑰,或匯入現有金鑰。 在 Azure 建立金鑰比較簡單,但匯入金鑰能讓你完全掌控金鑰的產生方式。 使用RSA金鑰。 客戶金鑰支援RSA金鑰長度最高可達4,096位元。 Azure 金鑰保存庫 不支援用橢圓形曲線 (EC) 鍵進行包裹和展開。

要為每個保險庫新增金鑰,請參見 Add-AzKeyVaultKey。

如果您偏好在本地產生金鑰,然後匯入 Azure,請依照「如何產生及轉移 HSM 保護金鑰以供Azure 金鑰保存庫」中的步驟操作。 使用 Azure 的說明,為每個金鑰保存庫新增一把金鑰。

確認你的鑰匙的有效期限

要檢查你的金鑰是否有過期日期,請執行 Get-AzKeyVaultKey 指令檔。

給Azure 金鑰保存庫:

Get-AzKeyVaultKey -VaultName <vault name>

客戶金鑰無法使用過期的金鑰。 如果金鑰過期,任何使用該金鑰的操作都會失敗,可能導致服務中斷。 我們強烈建議使用客戶金鑰時,金鑰不要有有效期限。

一旦設定好,到期日就無法移除,但你可以更改。 如果你必須使用有過期期限的金鑰,請更新成 12/31/9999 並使用舊有的入門方式。 任何其他到期值都會在客戶金鑰啟動驗證中失敗。

注意事項

客戶金鑰入門服務僅接受無有效期限的金鑰。

要將到期日改為 12/31/9999,請使用 Update-AzKeyVaultKey 指令檔。

Update-AzKeyVaultKey -VaultName <vault name> -Name <key name> -Expires (Get-Date -Date "12/31/9999")

注意

不要在使用客戶金鑰時設定加密金鑰的有效期限。

備份Azure 金鑰保存庫鑰匙

建立或修改金鑰後,務必立即備份。 將備份副本存放於線上與離線位置,以協助防止資料遺失。

要在 Azure 金鑰保存庫 備份金鑰,請使用 Backup-AzKeyVaultKey 指令檔。

重要事項

如果金鑰在沒有備份的情況下被刪除,就無法恢復。 每次更換或建立金鑰後,務必建立備份。

取得每個Azure 金鑰保存庫金鑰的 URI

在你設置好金鑰庫並新增金鑰後,執行以下指令取得每個金鑰的 URI。 建立和指派 DEP 時需要這些 URI;所以,務必將它們保存在安全的地方。

在 Azure PowerShell 中執行以下命令——每個金鑰保存庫一次:

(Get-AzKeyVaultKey -VaultName <vault name>).Id

使用客戶鑰匙入職服務進行上線

Microsoft 365 客戶金鑰導入服務允許您在租戶中啟用客戶金鑰。 此服務會自動驗證所需的客戶金鑰資源。 如果你願意,也可以先驗證資源再進行啟用。

重要事項

此服務目前無法用於以下情境:

用於入職的帳號 必須 具備以下權限:

  1. 服務主體註冊權限:註冊所需的服務主體。
  2. 讀者角色:在入職指令中使用的每個Azure 金鑰保存庫。

安裝 M365CustomerKeyOnboarding PowerShell 模組

  1. 用 Azure PowerShell 登入你的 Azure 訂閱。 如需指引,請參閱「以 Azure PowerShell 登入」。

  2. PowerShell 資源庫安裝最新版本M365CustomerKeyOnboarding模組。

  • 要確認你使用的是最新版本,請查看模組頁面底部的 版本歷史 標籤。
  • 把安裝指令複製貼上到你的工作階段並執行。
  • 如果有提示,請選擇 「是全部」 繼續。

使用兩種不同的入職模式

使用客戶金鑰入職服務時,有兩種不同的入職模式可供選擇: 驗證啟用。 每種模式在入門過程中都有不同的用途。

在依照 建立啟動請求) 中指示執行 cmdlet (時,請使用 -OnboardingMode 參數指定模式。

驗證

使用該 Validate 模式確認您的客戶金鑰資源設定正確。 此模式不會改變你的環境。

重要事項

你可以根據需要多次執行這個模式,尤其是在更改設定後。

啟用

當你準備好讓租戶加入客戶鑰匙時,使用這個 Enable 模式。 此模式啟用您透過參數 -Scenario 指定的工作負載的客戶金鑰。

如果你想同時啟用 Multiple WorkloadExchange 的 Customer Key,請執行 cmdlet 兩次,分別執行一次。

在啟用模式運行前,請確保驗證結果顯示為通過ValidationResult

重要事項

你的資源必須通過所有模式的 Validate 檢查,才能在啟用模式下成功完成入職程序。

建立入職申請

入職流程的第一步是建立一個新的請求。 在 PowerShell 中,你可以用 $ 符號加上變數名稱來將 cmdlet 的結果儲存在變數中。

在此範例中,啟動請求儲存在一個名為 $request

$request = New-CustomerKeyOnboardingRequest -Organization <tenantID> -Scenario <Scenario> -Subscription1 <subscriptionID1> -KeyIdentifier1 <KeyURI1> -Subscription2 <subscriptionID2> -KeyIdentifier2 <KeyURI2> -OnboardingMode <OnboardingMode>
參數 描述 範例
-Organization 你的租戶編號格式為 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx abcd1234-abcd-efgh-hijk-abcdef123456
-Scenario 你即將適應的工作量。 選項: MDEP – 多重工作負載的客戶金鑰, EXO – 交換用的客戶金鑰 MDEPEXO
-Subscription1 第一個訂閱的 Azure 訂閱 ID。 p12ld534-1234-5678-9876-g3def67j9k12
-KeyIdentifier1 第一個 AKV 或 HSM 金鑰的 URI 為客戶金鑰配置。 https://exampleVault1.vault.azure.net/keys/customerKey1
-Subscription2 第二個訂閱的 Azure 訂閱 ID。 21k9j76f-ed3g-6789-8765-43215dl21pbd
-KeyIdentifier2 第二個 AKV 或 HSM 金鑰的 URI 為客戶金鑰配置。 https://exampleVault2.vault.azure.net/keys/customerKey2
-OnboardingMode 要執行的入職操作。 選項: Validate – 驗證你的設定,無需更改。 在入職前確認時很有用。 Enable – 驗證並啟用租戶中的客戶金鑰(若驗證通過)。 ValidateEnable

請用你的租戶管理員憑證登入

當提示時,會開啟一個瀏覽器視窗。 請使用您的租戶管理員帳號登入,並取得完成入職權限。

提示以特權帳號登入

查看驗證與啟用細節

成功登入後,回到你的 PowerShell 視窗。 執行你建立入職請求時使用的變數來查看其輸出:

$request

CKO 請求輸出

你會收到包含 IDCreatedDateValidationResultEnablementResult的輸出。

輸出 描述
ID 與建立的入職申請相關聯的 ID 是必須的。
CreatedDate 申請成立的日期。
ValidationResult 驗證成功/失敗的指標。
EnablementResult 成功/失敗啟用的指標。

一個準備使用 Customer Key 的租戶會顯示兩項ValidationResult都顯示成功EnablementResult如下截圖所示:

CKO 成功表現

若兩個值皆顯示成功,請進入下一步。

故障排除驗證失敗細節

若在入職過程中驗證失敗,請依照以下步驟調查原因。 此過程有助於識別哪些客戶關鍵資源配置錯誤。

  1. 列出所有租客的入職需求,以便找到 RequestID 你想調查的租戶:
Get-CustomerKeyOnboardingRequest -OrganizationID <OrganizationID>
  1. 將特定的入職請求儲存在一個變數中:
$request = Get-CustomerKeyOnboardingRequest -OrganizationID <OrganizationID> -RequestID <RequestID>
  1. 查看驗證失敗的詳細資料:
$request.FailedValidations

PowerShell 驗證失敗輸出的範例

每個驗證規則包含以下欄位:

  • 期望值:資源配置應該是什麼樣子。
  • ActualValue:你在環境中偵測到什麼?
  • 範圍:訂閱ID的前五個字元,幫助你辨識出哪個訂閱 (及其關聯金鑰保存庫) 有問題。
  • 細節:描述根本原因並提供解決問題的指引。

下表總結了常見的驗證規則及失敗解決方法:

規則名稱 描述 解決方案
OrganizationHasRequiredServicePlan 確認您的組織是否持有所需的執照。 請參閱 「確保您的房客持有所需執照」。
KeyNeverExpires 確保金鑰沒有過期日期。 請參閱配置特定設定中的金鑰到期驗證步驟
KeyOperationsSupported 驗證金鑰是否支援該工作負載所需的操作。 請參閱設定專屬設定中的權限分配步驟
RecoveryLevel 檢查金鑰恢復層級是否為 Recoverable 確保軟刪除和清除保護都已啟用。 請參閱啟用軟刪除與清除保護以取得Azure 金鑰保存庫或建立資源群組配置,並為受管理 HSM 啟用受管 HSM
SubscriptionInRequestOrganization 確認你的 Azure 訂閱屬於你的組織。 請確認訂閱是在指定的租戶內建立的。
SubscriptionsCountPerScenario 確認提供了兩次訂閱。 請確保您的入職申請包含 兩份 訂閱。
SubscriptionUniquePerScenario 確保你每個情境使用兩個獨立訂閱。 請再次確認兩個訂閱 ID 是否不同。
VaultExistsinSubscription 確認 AKV/託管 HSM 是該訂閱的一部分。 確認金鑰保存庫/HSM 是否是在正確的訂閱中建立的。

檢查通過驗證

要查看在導入過程中哪些驗證成功,請執行以下步驟:

  1. 將特定的入職請求儲存在變數「$request」中
$request = Get-CustomerKeyOnboardingRequest -OrganizationID <OrganizationID> -RequestID <RequestID>
  1. 執行以下指令以顯示所有通過的驗證:
$request.PassedValidations

此指令會回傳所有成功通過的驗證清單,該請求為所選入職請求。

CKO 通過驗證

使用舊有方法接駁至 Customer Key。

只有在客戶金鑰入職服務不支援租戶情境時,才可使用此方法。

完成所有設定 Azure Key Vault 與訂閱的必要步驟後,請聯絡 Microsoft 支援服務,請求協助客戶金鑰啟用。

針對特殊雲端環境的客戶金鑰內建

如果您的租戶位於 GCC-HDoDM365,由 21Vianet 營運,請先完成所有必要的客戶金鑰設定步驟。

Onboard to Customer Key for SharePoint 與 OneDrive

要啟用 SharePoint 和 OneDrive 的客戶金鑰,您的 Azure Key Vault 必須符合以下先決條件:

  1. 在初始建立保險庫時啟用軟刪除與清除保護。 請參見啟用軟刪除與清除保護以了解Azure 金鑰保存庫。

  2. 保持90天的保留期。

若所有前置條件都已滿足,請依照 建立 DEP 以搭配 SharePoint 和 OneDrive 的步驟操作。

後續步驟

完成本文設定步驟後,您即可建立並指派 DEP。 詳細說明請參閱 「管理客戶金鑰」。