Azure RMS 的運作方式為何？ 背後原理

瞭解 Azure RMS 運作方式的重要事項是，此 Azure 資訊保護 資料保護服務不會在保護程式中看到或儲存您的數據。 除非您明確地將它儲存在 Azure 中，或使用另一個將它儲存在 Azure 中的雲端服務，否則您保護的資訊永遠不會傳送至 Azure 或儲存在 Azure 中。 Azure RMS 只會讓授權的使用者和服務以外的任何人無法讀取檔案中的數據：

• 數據會在應用層級加密，並包含定義該文件授權用途的原則。

• 當合法使用者或授權服務處理受保護的檔時，會解密檔中的數據，並強制執行原則中定義的許可權。

概括而言，您可以查看此程式在下圖中的運作方式。 包含秘密公式的檔受到保護，然後由授權的使用者或服務成功開啟。 檔會受到內容金鑰的保護（此圖片中的綠色索引鍵）。 它對於每個檔而言都是唯一的，並且會放在檔案標頭中，其中會受到 Azure 資訊保護 租使用者根密鑰的保護（此圖片中的紅色密鑰）。 您的租使用者金鑰可由 Microsoft 產生和管理，也可以產生和管理您自己的租使用者金鑰。

當 Azure RMS 正在加密和解密、授權及強制執行限制時，一律不會將秘密公式傳送至 Azure。

如需所發生狀況的詳細描述，請參閱 本文中的 Azure RMS 運作方式逐步解說：第一次使用、內容保護、內容取用 一節。

如需 Azure RMS 所使用的演算法和金鑰長度的技術詳細數據，請參閱下一節。

Azure RMS 所使用的密碼編譯控件：演算法和密鑰長度

即使您不需要詳細瞭解這項技術的運作方式，您可能也會被問及其使用的密碼編譯控件。 例如，若要確認安全性保護是業界標準。

密碼編譯控件	在 Azure RMS 中使用
演算法：AES 金鑰長度：128 位和 256 位 [1]	內容保護
演算法：RSA 金鑰長度：2048 位 [2]	金鑰保護
SHA-256	憑證簽署

腳注 1

Azure 資訊保護 用戶端會在下列案例中使用 256 位：

• 一般保護 （.pfile） 。

• 當檔受到 PDF 加密的 ISO 標準保護，或產生的受保護檔擴展名為 .ppdf 時，PDF 檔的原生保護。

• 文字或圖像檔案的原生保護（例如 .ptxt 或 .pjpg）。

腳注 2

啟用 Azure Rights Management 服務時，2048 位是密鑰長度。 下列選用案例支援 1024 位：

• 如果 AD RMS 叢集是在密碼編譯模式 1 中執行，則從內部部署移轉期間。

• 針對在移轉前於內部部署建立的封存密鑰，讓先前受 AD RMS 保護的內容可以在移轉後繼續由 Azure Rights Management 服務開啟。

Azure RMS 密碼編譯密鑰的儲存和保護方式

針對受 Azure RMS 保護的每個檔或電子郵件，Azure RMS 會建立單一 AES 金鑰（內容金鑰），而該密鑰會內嵌至檔，並透過檔版本保存。

內容密鑰會以組織的 RSA 金鑰（「Azure 資訊保護 租使用者金鑰」作為檔中原則的一部分受到保護，而且原則也會由檔作者簽署。 此租使用者金鑰適用於所有受組織 Azure Rights Management 服務保護的檔和電子郵件，而且如果組織使用客戶管理的租使用者密鑰（稱為「攜帶您自己的金鑰」或 BYOK，則此金鑰只能由 Azure 資訊保護 系統管理員變更。

此租使用者金鑰會在 Microsoft 的 線上服務、高度控制的環境中以及密切監視中受到保護。 當您使用客戶管理的租使用者密鑰 （BYOK）時，此安全性會透過在每個 Azure 區域中使用高端硬體安全性模組 （HSM） 陣列來增強，而不需要在任何情況下擷取、導出或共用密鑰。 如需租使用者密鑰和 BYOK 的詳細資訊，請參閱規劃和實作 Azure 資訊保護 租使用者密鑰。

傳送至 Windows 裝置的授權和憑證會受到用戶端裝置私鑰的保護，這是裝置上使用者第一次使用 Azure RMS 時建立的。 接著，此私鑰會使用用戶端上的 DPAPI 保護，其會使用衍生自使用者密碼的金鑰來保護這些秘密。 在行動裝置上，金鑰只會使用一次，因此因為它們不會儲存在用戶端上，因此這些密鑰不需要在裝置上受到保護。

Azure RMS 運作方式的逐步解說：第一次使用、內容保護、內容取用

若要深入瞭解 Azure RMS 的運作方式，讓我們在 Azure Rights Management 服務啟動後逐步解說一般流程，以及當使用者第一次在其 Windows 計算機上使用 Rights Management 服務時（有時稱為初始化用戶環境或啟動載入的程式），保護內容（檔或電子郵件），然後取用其他人已保護的內容（開啟和使用）。

在用戶環境初始化之後，該使用者可以接著保護檔，或使用該計算機上的受保護檔。

注意

如果使用者移至另一部 Windows 計算機，或另一位使用者使用同一部 Windows 計算機，則會重複初始化程式。

初始化用戶環境

用戶必須先在裝置上準備使用者環境，使用者才能保護內容或取用Windows 電腦上的受保護內容。 這是一次性程式，當使用者嘗試保護或取用受保護的內容時，不需使用者介入，就會自動進行：

步驟 1：計算機上的 RMS 用戶端會先連線到 Azure Rights Management 服務，並使用其 Microsoft Entra 帳戶來驗證使用者。

當使用者的帳戶與 Microsoft Entra ID 同盟時，此驗證是自動的，而且不會提示使用者輸入認證。

步驟 2：驗證使用者之後，聯機會自動重新導向至組織的 Azure 資訊保護 租使用者，這會發出憑證，讓使用者向 Azure Rights Management 服務進行驗證，以取用受保護的內容並脫機保護內容。

其中一個憑證是許可權帳戶憑證，通常縮寫為 RAC。 此憑證會向 Microsoft Entra ID 驗證使用者，且有效期為 31 天。 RMS 用戶端會自動更新憑證，前提是用戶帳戶仍在 Microsoft Entra ID 中，且帳戶已啟用。 系統管理員無法設定此憑證。

此憑證的複本會儲存在 Azure 中，如此一來，如果使用者移至另一個裝置，就會使用相同的密鑰來建立憑證。

內容保護

當使用者保護檔案時，RMS 用戶端會在未受保護的檔案上採取下列動作：

步驟 1：RMS 用戶端會建立隨機金鑰（內容金鑰），並使用此金鑰搭配 AES 對稱加密演算法來加密檔。

步驟 2：RMS 用戶端接著會建立憑證，其中包含包含使用者或群組使用權的文件原則，以及其他限制，例如到期日。 這些設定可以在系統管理員先前設定的範本中定義，或在內容受到保護時指定（有時稱為「臨機操作原則」）。

用來識別所選使用者和群組的主要 Microsoft Entra 屬性是 Microsoft Entra ProxyAddresses 屬性，它會儲存使用者或群組的所有電子郵件位址。 不過，如果用戶帳戶在 AD ProxyAddresses 屬性中沒有任何值，則會改用使用者的 UserPrincipalName 值。

RMS 用戶端接著會使用組織密鑰，在用戶環境初始化時取得，並使用此金鑰來加密原則和對稱內容金鑰。 RMS 用戶端也會使用用戶環境初始化時取得的用戶憑證簽署原則。

步驟 3 發生的情況：最後，RMS 用戶端會將原則內嵌到檔案中，其中包含先前加密的文件主體，其中一起組成受保護的檔。

此檔可以使用任何方法儲存在任何地方或共用，而原則一律會保留加密的檔。

內容耗用量

當使用者想要取用受保護的檔案時，RMS 用戶端會從要求存取 Azure Rights Management 服務開始：

步驟 1：已驗證的使用者會將文件原則和用戶的憑證傳送至 Azure Rights Management 服務。 服務會解密並評估原則，並建置使用者針對檔擁有的許可權清單（如果有的話）。 為了識別使用者，Microsoft Entra ProxyAddresses 屬性會用於使用者所屬的用戶帳戶和群組。 基於效能考慮，會 快取群組成員資格。 如果使用者帳戶沒有 Microsoft Entra ProxyAddresses 屬性的值，則會改用 Microsoft Entra UserPrincipalName 中的值。

步驟 2：服務接著會從解密的原則擷取 AES 內容密鑰。 接著，此金鑰會使用透過要求取得的使用者公用 RSA 金鑰進行加密。

然後，重新加密的內容密鑰會內嵌到具有用戶權力清單的加密使用授權中，然後傳回 RMS 用戶端。

步驟 3：最後，RMS 用戶端會取得加密的使用授權，並使用自己的使用者私鑰解密它。 這可讓 RMS 用戶端視需要解密檔的本文，並在畫面上轉譯。

用戶端也會解密許可權清單，並將其傳遞至應用程式，以在應用程式的使用者介面中強制執行這些許可權。

注意

當組織外部的用戶取用您保護的內容時，取用流程會相同。 此案例有哪些變更，就是使用者如何進行驗證。 如需詳細資訊，請參閱 當我與公司外部的人員共享受保護的檔時，該使用者如何獲得驗證？

變化

上述逐步解說涵蓋標準案例，但有一些變化：

• 電子郵件保護：使用具有新功能的 Exchange Online 和 Office 365 郵件加密來保護電子郵件訊息時，取用的驗證也可以使用與社交識別提供者的同盟，或使用一次性密碼。 然後，進程流程非常類似，不同之處在於內容耗用量會在網頁瀏覽器會話中透過暫時快取的輸出電子郵件複本在服務端發生。

• 行動裝置：當行動裝置使用 Azure Rights Management 服務保護或取用檔案時，程式流程會更簡單。 行動裝置不會先通過使用者初始化程式，因為每個交易（保護或取用內容）都是獨立的。 如同 Windows 計算機，行動裝置會連線到 Azure Rights Management 服務並進行驗證。 為了保護內容，行動裝置會提交原則，而 Azure Rights Management 服務會傳送發佈授權和對稱密鑰來保護檔。 若要取用內容，當行動裝置連線到 Azure Rights Management 服務並進行驗證時，他們會將文件原則傳送至 Azure Rights Management 服務，並要求使用授權來取用檔。 作為回應，Azure Rights Management 服務會將必要的密鑰和限制傳送至行動裝置。 這兩個程式都會使用 TLS 來保護金鑰交換和其他通訊。

• RMS 連接器：當 Azure Rights Management 服務與 RMS 連接器搭配使用時，程式流程會維持不變。 唯一的差別在於連接器會作為內部部署服務（例如 Exchange Server 和 SharePoint Server）與 Azure Rights Management 服務之間的轉接。 連接器本身不會執行任何作業，例如用戶環境的初始化，或加密或解密。 它只會轉譯通常會移至 AD RMS 伺服器的通訊，處理每一端所使用的通訊協定之間的轉譯。 此案例可讓您搭配內部部署服務使用 Azure Rights Management 服務。

• 一般保護 （.pfile）：當 Azure Rights Management 服務一般保護檔案時，除了 RMS 用戶端建立授與所有許可權的原則以外，內容保護流程基本上是相同的。 取用檔案時，它會在傳遞至目標應用程式之前解密。 此案例可讓您保護所有檔案，即使它們原生不支援 RMS 也一樣。

• Microsoft 帳戶：Azure 資訊保護 可以在使用 Microsoft 帳戶進行驗證時授權電子郵件位址供取用。 不過，並非所有應用程式都可以在 Microsoft 帳戶用於驗證時開啟受保護的內容。 更多資訊。

下一步

若要深入瞭解 Azure Rights Management 服務，請使用瞭解與探索一節中的其他文章，例如應用程式如何支援 Azure Rights Management 服務，以瞭解現有應用程式如何與 Azure Rights Management 整合以提供資訊保護解決方案。

檢閱 Azure 資訊保護 術語，讓您熟悉您在設定和使用 Azure Rights Management 服務時可能會遇到的詞彙，而且請務必在開始部署之前檢查 Azure 資訊保護 需求。 如果您想要深入瞭解並自行試用，請使用快速入門和教學課程：

• 快速入門：部署統一卷標用戶端
• 教學課程：安裝 Azure 資訊保護 （AIP） 統一卷標掃描器
• 教學課程：使用 Azure 資訊保護 （AIP） 掃描器尋找您的敏感性內容
• 教學課程：使用 Azure 資訊保護 防止 Outlook 中的過度共用 （AIP）

如果您已準備好開始為組織部署數據保護，請使用 AIP部署藍圖來分類、標記和保護 部署步驟，以及操作說明的連結。