Azure RMS 的運作方式為何?How does Azure RMS work? 背後原理Under the hood

*適用于Azure 資訊保護Office 365**Applies to: Azure Information Protection, Office 365*

*適用于AIP 統一標籤用戶端和傳統用戶端。 **Relevant for: AIP unified labeling client and classic client.*

關於 Azure RMS 的運作方式,您必須要了解的是 Azure 資訊保護所提供的這個資料保護服務並不會在保護過程中看到或儲存您的資料。An important thing to understand about how Azure RMS works, is that this data protection service from Azure Information Protection, does not see or store your data as part of the protection process. 您所保護的資訊永遠不會傳送至或儲存在 Azure 中,除非您明確地將它儲存在 Azure 中,或使用將它儲存在 Azure 中的另一項雲端服務。Information that you protect is never sent to or stored in Azure, unless you explicitly store it in Azure or use another cloud service that stores it in Azure. Azure RMS 只是將資料放入文件中,除了授權的使用者和服務外,任何人都無法讀取這個文件:Azure RMS simply makes the data in a document unreadable to anyone other than authorized users and services:

  • 資料會在應用程式層級加密,並包含原則來定義該文件的授權使用。The data is encrypted at the application level and includes a policy that defines the authorized use for that document.

  • 當合法使用者使用受保護的文件或是授權的服務在處理此文件時,系統會將文件中的資料解密,並強制執行原則中所定義的權限。When a protected document is used by a legitimate user or it is processed by an authorized service, the data in the document is decrypted and the rights that are defined in the policy are enforced.

下圖會從高層級的角度,說明此程序的運作方式。At a high level, you can see how this process works in the following picture. 包含祕密公式的文件受到保護,隨後由授權的使用者或服務成功開啟。A document containing the secret formula is protected, and then successfully opened by an authorized user or service. 文件受內容金鑰 (此圖中的綠色鑰匙) 保護。The document is protected by a content key (the green key in this picture). 每份文件都有唯一的內容金鑰,此金鑰放置於檔案標頭中,並由 Azure 資訊保護租用戶根金鑰 (此圖中的紅色鑰匙) 進行保護。It is unique for each document and is placed in the file header where it is protected by your Azure Information Protection tenant root key (the red key in this picture). 租用戶金鑰可由 Microsoft 產生及管理,而您也可以自行產生及管理租用戶金鑰。Your tenant key can be generated and managed by Microsoft, or you can generate and manage your own tenant key.

在整個保護過程中,當 Azure RMS 加密和解密、授權並強制執行限制時,祕密公式永遠不會傳送至 Azure。Throughout the protection process when Azure RMS is encrypting and decrypting, authorizing, and enforcing restrictions, the secret formula is never sent to Azure.

Azure RMS 如何保護檔案

如需事情發生經過的詳細說明,請參閱本文的 Azure RMS 運作方式的逐步解說:首次使用、內容保護、內容取用一節。For a detailed description of what’s happening, see the Walkthrough of how Azure RMS works: First use, content protection, content consumption section in this article.

如需有關於 Azure RMS 所使用之演算法和金鑰長度的技術細節,請參閱下一節。For technical details about the algorithms and key lengths that Azure RMS uses, see the next section.

Azure RMS 所使用的密碼編譯控制:演算法和金鑰長度Cryptographic controls used by Azure RMS: Algorithms and key lengths

即便您不需要詳細了解這項技術的運作方式,但可能會有人向您詢問該技術所使用的密碼編譯控制。Even if you don't need to know in detail how this technology works, you might be asked about the cryptographic controls that it uses. 例如,為了確認安全性保護符合業界標準。For example, to confirm that the security protection is industry-standard.

密碼編譯控制Cryptographic controls Azure RMS 中的用途Use in Azure RMS
演算法:AESAlgorithm: AES

金鑰長度:128 位元和 256 位元 [1]Key length: 128 bits and 256 bits [1]
內容保護Content protection
演算法:RSAAlgorithm: RSA

金鑰長度:2048 位元 [2]Key length: 2048 bits [2]
金鑰保護Key protection
SHA-256SHA-256 憑證簽署Certificate signing
註腳 1Footnote 1

Azure 資訊保護用戶端會在下列情況使用 256 位元:256 bits is used by the Azure Information Protection client in the following scenarios:

  • 一般保護 (.pfile)。Generic protection (.pfile).

  • 當文件受到 PDF 加密的 ISO 保護,或產生的受保護文件具有 .ppdf 副檔名時,PDF 文件的原生保護。Native protection for PDF documents when the document has been protected with the ISO standard for PDF encryption, or the resulting protected document has a .ppdf file name extension.

  • 文字或影像檔 (例如 .ptxt 或 .pjpg) 的原生保護。Native protection for text or image files (such as .ptxt or .pjpg).

註腳 2Footnote 2

2048 位元是 Azure Rights Management 服務啟動時的金鑰長度。2048 bits is the key length when the Azure Rights Management service is activated. 1024 位元則支援用於下列選擇性案例:1024 bits is supported for the following optional scenarios:

  • 在從內部部署移轉期間,如果 AD RMS 叢集是在密碼編譯模式 1 下執行。During a migration from on-premises if the AD RMS cluster is running in Cryptographic Mode 1.

  • 用於移轉前在內部部署所建立的封存金鑰,讓先前由 AD RMS 保護的內容可繼續供 Azure Rights Management 服務的後續移轉作業來開啟。For archived keys that were created on-premises before the migration, so that content that was previously protected by AD RMS can continue to be opened by the Azure Rights Management service post migration.

Azure RMS 密碼編譯金鑰的儲存和保護方式How the Azure RMS cryptographic keys are stored and secured

對於由 Azure RMS 保護的每個文件或電子郵件,Azure RMS 都會建立單一 AES 金鑰 (即「內容金鑰」),該金鑰會內嵌至文件,並持續存留在文件的各個版本中。For each document or email that is protected by Azure RMS, Azure RMS creates a single AES key (the "content key"), and that key is embedded to the document, and persists through editions of the document.

內容金鑰會成為文件原則的一部分,並使用組織的 RSA 金鑰 (即「Azure 資訊保護租用戶金鑰」) 來加以保護,而且此原則也會由文件建立者加以簽署。The content key is protected with the organization’s RSA key (the "Azure Information Protection tenant key") as part of the policy in the document, and the policy is also signed by the author of the document. 由組織的 Azure Rights Management 服務所保護的所有文件和電子郵件會共同使用這個租用戶金鑰,而且如果組織使用的租用戶金鑰是由客戶所管理 (稱為「攜帶您自己的金鑰」,簡寫為 BYOK),則只有 Azure 資訊保護系統管理員能夠變更這個金鑰。This tenant key is common to all documents and emails that are protected by the Azure Rights Management service for the organization and this key can only be changed by an Azure Information Protection administrator if the organization is using a tenant key that is customer-managed (known as "bring your own key", or BYOK).

Microsoft 的線上服務會在受到高度控制的環境中保護此租用戶金鑰,並對其進行嚴密監控。This tenant key is protected in Microsoft’s online services, in a highly controlled environment and under close monitoring. 當您使用由客戶管理的租用戶金鑰 (BYOK) 時,每個 Azure 區域更會使用一批高階硬體安全性模組 (HSM) 來加強此安全性,讓任何人無法在任何情況下擷取、匯出或共用這些金鑰。When you use a customer-managed tenant key (BYOK), this security is enhanced by the use of an array of high-end hardware security modules (HSMs) in each Azure region, without the ability for the keys to be extracted, exported, or shared under any circumstances. 如需租用戶金鑰和 BYOK 的詳細資訊,請參閱規劃及實作 Azure 資訊保護租用戶金鑰For more information about the tenant key and BYOK, see Planning and implementing your Azure Information Protection tenant key.

傳送至 Windows 裝置的授權和憑證會使用用戶端的裝置私密金鑰來加以保護,裝置上的使用者第一次使用 Azure RMS 時便會建立此私密金鑰。Licenses and certificates that are sent to a Windows device are protected with the client’s device private key, which is created the first time a user on the device uses Azure RMS. 而這個私密金鑰又會使用用戶端上的 DPAPI 來加以保護,進而使用衍生自使用者密碼的金鑰來保護這些密碼。This private key, in turn, is protected with DPAPI on the client, which protects these secrets by using a key derived from the user’s password. 在行動裝置上,金鑰只會使用一次,且由於金鑰並非儲存在用戶端上,所以不必在裝置上保護這些金鑰。On mobile devices, the keys are used only one time, so because they are not stored on the clients, these keys don’t need to be protected on the device.

Azure RMS 運作方式的逐步解說:首次使用、內容保護、內容取用Walkthrough of how Azure RMS works: First use, content protection, content consumption

為了深入了解 Azure RMS 的運作方式,讓我們逐步看看 Azure Rights Management 服務啟動之後,以及使用者首次在其 Windows 電腦上使用 Rights Management 服務 (此程序有時稱為 初始化使用者環境 或啟動載入)、保護內容 (文件或電子郵件) 然後 取用 (開啟並使用) 已由其他人所保護的內容時的標準流程。To understand in more detail how Azure RMS works, let's walk through a typical flow after the Azure Rights Management service is activated and when a user first uses the Rights Management service on their Windows computer (a process sometimes known as initializing the user environment or bootstrapping), protects content (a document or email), and then consumes (opens and uses) content that has been protected by somebody else.

在使用者環境初始化之後,該使用者就可保護文件或取用該電腦上的受保護文件。After the user environment is initialized, that user can then protect documents or consume protected documents on that computer.

注意

如果此使用者移至另一部 Windows 電腦,或另一位使用者使用同一部 Windows 電腦時,便會重複進行初始化程序。If this user moves to another Windows computer, or another user uses this same Windows computer, the initialization process is repeated.

初始化使用者環境Initializing the user environment

使用者必須先在裝置上備妥使用者環境,才能保護內容或取用 Windows 電腦上的受保護內容。Before a user can protect content or consume protected content on a Windows computer, the user environment must be prepared on the device. 這個程序只需進行一次,當使用者嘗試保護或取用受保護的內容時便會自動進行此程序,而不需要使用者介入:This is a one-time process and happens automatically without user intervention when a user tries to protect or consume protected content:

RMS 用戶端啟用流程 - 步驟 1,驗證用戶端

步驟 1 中的情況:電腦上的 RMS 用戶端先連線至 Azure Rights Management 服務,並使用其 Azure Active Directory 帳戶驗證使用者。What's happening in step 1: The RMS client on the computer first connects to the Azure Rights Management service, and authenticates the user by using their Azure Active Directory account.

當使用者的帳戶與 Azure Active Directory 同盟時,便會自動進行此驗證,而不會提示使用者輸入認證。When the user’s account is federated with Azure Active Directory, this authentication is automatic and the user is not prompted for credentials.

RMS 用戶端啟用 - 步驟 2,憑證下載到用戶端

步驟 2 中的情況:使用者經過驗證之後,連線會自動重新導向至組織的 Azure 資訊保護租用戶,以發出憑證讓使用者向 Azure Rights Management 服務進行驗證,以便能夠取用受保護的內容及離線保護內容。What's happening in step 2: After the user is authenticated, the connection is automatically redirected to the organization’s Azure Information Protection tenant, which issues certificates that let the user authenticate to the Azure Rights Management service in order to consume protected content and to protect content offline.

這其中一個憑證是權限帳戶憑證,通常縮寫為 RAC。One of these certificates is the rights account certificate, often abbreviated to RAC. 此憑證會驗證使用者的 Azure Active Directory,且有效期為31天。This certificate authenticates the user to Azure Active Directory and is valid for 31 days. RMS 用戶端會自動更新憑證,但前提是使用者帳戶仍在 Azure Active Directory 中且帳戶已啟用。The certificate is automatically renewed by the RMS client, providing the user account is still in Azure Active Directory and the account is enabled. 系統管理員無法設定此憑證。This certificate is not configurable by an administrator.

Azure 會儲存此憑證的複本,如果使用者移至另一個裝置,即可使用相同的金鑰建立憑證。A copy of this certificate is stored in Azure so that if the user moves to another device, the certificates are created by using the same keys.

內容保護Content protection

當使用者保護文件時,RMS 用戶端會對未受保護的文件採取下列動作:When a user protects a document, the RMS client takes the following actions on an unprotected document:

RMS 文件保護 - 步驟 1,將文件加密

步驟 1 中的情況:RMS 用戶端會使用此金鑰與 AES 對稱加密演算法來建立隨機金鑰 (內容金鑰) 和加密文件。What's happening in step 1: The RMS client creates a random key (the content key) and encrypts the document using this key with the AES symmetric encryption algorithm.

RMS 文件保護 - 步驟 2,建立原則

步驟 2 中的情況:RMS 用戶端接著會建立憑證,在其中納入文件原則以包含使用者或群組的 使用權限以及其他限制 (例如到期日)。What's happening in step 2: The RMS client then creates a certificate that includes a policy for the document that includes the usage rights for users or groups, and other restrictions, such as an expiration date. 這些設定可定義於系統管理員先前所設定的範本,或在保護內容時指定 (有時稱為「特定原則」)。These settings can be defined in a template that an administrator previously configured, or specified at the time the content is protected (sometimes referred to as an "ad hoc policy").

用來識別所選使用者和群組的主要 Azure AD 屬性是 Azure AD ProxyAddresses 屬性,此屬性會儲存使用者或群組的所有電子郵件地址。The main Azure AD attribute used to identify the selected users and groups is the Azure AD ProxyAddresses attribute, which stores all the email addresses for a user or group. 不過,如果使用者帳戶在 AD ProxyAddresses 屬性中沒有任何值,則會改為使用使用者的 UserPrincipalName 值。However, if a user account doesn't have any values in the AD ProxyAddresses attribute, the user's UserPrincipalName value is used instead.

RMS 用戶端接著會使用組織在初始化使用者環境時所取得的金鑰,並使用此金鑰來加密原則和對稱內容金鑰。The RMS client then uses the organization’s key that was obtained when the user environment was initialized and uses this key to encrypt the policy and the symmetric content key. RMS 用戶端也會使用使用者在初始化使用者環境時所取得的憑證來簽署金鑰。The RMS client also signs the policy with the user’s certificate that was obtained when the user environment was initialized.

RMS 文件保護 - 步驟 3,原則內嵌到文件中

步驟3中的情況:最後,RMS 用戶端會將原則嵌入具有先前加密之檔本文的檔案中,該檔案會共同組成受保護的檔。What's happening in step 3: Finally, the RMS client embeds the policy into a file with the body of the document encrypted previously, which together comprise a protected document.

這份文件可使用任何方法儲存在任何地方或進行共用,原則則會永遠與加密的文件並存。This document can be stored anywhere or shared by using any method, and the policy always stays with the encrypted document.

內容取用Content consumption

當使用者想要取用受保護的文件時,RMS 用戶端一開始會先要求 Azure Rights Management 服務的存取權:When a user wants to consume a protected document, the RMS client starts by requesting access to the Azure Rights Management service:

RMS 文件取用 - 步驟 1,使用者會進行驗證並取得權限清單

步驟 1 中的情況:已驗證的使用者將文件原則和使用者的憑證傳送至 Azure Rights Management 服務。What's happening in step 1: The authenticated user sends the document policy and the user’s certificates to the Azure Rights Management service. 服務會將原則解密並進行評估,然後建置使用者具有的文件權限清單 (如果有的話)。The service decrypts and evaluates the policy, and builds a list of rights (if any) the user has for the document. 為了識別使用者,系統會將 Azure AD ProxyAddresses 屬性用於使用者的帳戶和使用者所屬的群組。To identify the user, the Azure AD ProxyAddresses attribute is used for the user's account and groups to which the user is a member. 基於效能考量,系統會快取群組成員資格。For performance reasons, group membership is cached. 如果使用者帳戶沒有 Azure AD ProxyAddresses 屬性值,則會改用 Azure AD UserPrincipalName 中的值。If the user account has no values for the Azure AD ProxyAddresses attribute, the value in the Azure AD UserPrincipalName is used instead.

RMS 文件取用 - 步驟 2,使用授權會傳回到用戶端

步驟 2 中的情況:服務接著會從解密的原則中擷取 AES 內容金鑰。What's happening in step 2: The service then extracts the AES content key from the decrypted policy. 然後使用透過要求取得的使用者公開 RSA 金鑰來加密這個金鑰。This key is then encrypted with the user’s public RSA key that was obtained with the request.

之後,重新加密的內容金鑰會內嵌到具有使用者權限清單的加密使用授權中,再傳回給 RMS 用戶端。The re-encrypted content key is then embedded into an encrypted use license with the list of user rights, which is then returned to the RMS client.

RMS 文件取用 - 步驟 3,文件會解密並強制執行權限

步驟 3 中的情況:最後,RMS 用戶端會取得加密的使用授權,並使用它自己的使用者私密金鑰加以解密。What's happening in step 3: Finally, the RMS client takes the encrypted use license and decrypts it with its own user private key. 這可讓 RMS 用戶端視需要將文件的本文解密並呈現在螢幕上。This lets the RMS client decrypt the document’s body as it is needed and render it on the screen.

用戶端也會解密權限清單,並將其傳遞至應用程式,以在應用程式的使用者介面中強制執行這些權限。The client also decrypts the rights list and passes them to the application, which enforces those rights in the application’s user interface.

注意

當組織外部的使用者取用您所保護的內容時,取用流程會相同。When users who are external to your organization consume content that you've protected, the consumption flow is the same. 此案例有所變更之處是使用者的驗證方式。What changes for this scenario, is how the user is authenticated. 如需詳細資訊,請參閱當我與公司外部人員共用受保護的文件時,如何讓該使用者通過驗證?For more information, see When I share a protected document with somebody outside my company, how does that user get authenticated?

變化Variations

前面的逐步解說內容說明了標準案例,但也有一些案例會有所變化:The preceding walkthroughs cover the standard scenarios but there are some variations:

  • 電子郵件保護:當 Exchange Online 和 Office 365 郵件加密新功能用來保護電子郵件訊息,則取用還可以使用與社交身分識別提供者的同盟或者單次密碼進行驗證。Email protection: When Exchange Online and Office 365 Message Encryption with new capabilities is used to protect email messages, authentication for consumption can also use federation with a social identity provider or by using a one-time passcode. 接著,程序流程都很相似,除了會透過暫時快取輸出的電子郵件的副本,在 Web 瀏覽器工作階段中的服務端發生內容取用。Then, the process flows are very similar, except that content consumption happens service-side in a web browser session over a temporarily cached copy of the outbound email.

  • 行動裝置:當行動裝置使用 Azure Rights Management 服務保護或取用檔案時,程序的流程會簡單許多。Mobile devices: When mobile devices protect or consume files with the Azure Rights Management service, the process flows are much simpler. 行動裝置不會先進行使用者初始化程序,因為每項交易 (用於保護或取用內容) 都是獨立的。Mobile devices don’t first go through the user initialization process because instead, each transaction (to protect or consume content) is independent. 和 Windows 電腦的情況一樣,行動裝置會連線至 Azure Rights Management 服務並進行驗證。As with Windows computers, mobile devices connect to the Azure Rights Management service and authenticate. 為了保護內容,行動裝置會提交原則,然後 Azure Rights Management 服務會對行動裝置傳送發佈授權和對稱金鑰以保護文件。To protect content, mobile devices submit a policy and the Azure Rights Management service sends them a publishing license and symmetric key to protect the document. 為了取用內容,行動裝置在連線至 Azure Rights Management 服務並進行驗證時,會將文件原則傳送至 Azure Rights Management 服務,並要求用以取用文件的使用授權。To consume content, when mobile devices connect to the Azure Rights Management service and authenticate, they send the document policy to the Azure Rights Management service and request a use license to consume the document. 作為回應,Azure Rights Management 服務會將必要的金鑰和限制傳送至行動裝置。In response, the Azure Rights Management service sends the necessary keys and restrictions to the mobile devices. 這兩個程序都會使用 TLS 來保護金鑰交換和其他通訊。Both processes use TLS to protect the key exchange and other communications.

  • RMS 連接器:當 Azure Rights Management 服務與 RMS 連接器一起使用時,程序的流程會保持不變。RMS connector: When the Azure Rights Management service is used with the RMS connector, the process flows remain the same. 唯一的差別在於連接器會作為內部部署服務 (例如 Exchange Server 和 SharePoint Server) 和 Azure Rights Management 服務之間的轉送。The only difference is that the connector acts as a relay between the on-premises services (such as Exchange Server and SharePoint Server) and the Azure Rights Management service. 連接器本身不會執行任何作業,例如使用者環境初始化或是加密或解密。The connector itself does not perform any operations, such as the initialization of the user environment, or encryption or decryption. 它只會轉送通常會送至 AD RMS 伺服器的通訊,處理每一端所使用的通訊協定之間的轉譯。It simply relays the communication that would usually go to an AD RMS server, handling the translation between the protocols that are used on each side. 這個案例可讓您搭配內部部署服務來使用 Azure Rights Management 服務。This scenario lets you use the Azure Rights Management service with on-premises services.

  • 一般保護 (.pfile):當 Azure Rights Management 服務以一般方式保護檔案時,內容保護的流程基本上都相同,只差在 RMS 用戶端會建立原則來授與所有權限。Generic protection (.pfile): When the Azure Rights Management service generically protects a file, the flow is basically the same for content protection except that the RMS client creates a policy that grants all rights. 取用檔案時,系統會先將其解密再傳遞至目標應用程式。When the file is consumed, it is decrypted before it is passed to the target application. 此案例可讓您保護所有檔案,即使它們未原生支援 RMS 也是如此。This scenario lets you protect all files, even if they don’t natively support RMS.

  • Microsoft 帳戶:當電子郵件使用 Microsoft 帳戶授權時,Azure 資訊保護可以授權它們進行取用。Microsoft accounts: Azure Information Protection can authorize email addresses for consumption when they are authenticated with a Microsoft account. 不過,當 Microsoft 帳戶用於驗證時,並非所有應用程式都可以開啟受保護的內容。However, not all applications can open protected content when a Microsoft account is used for authentication. 詳細資訊More information.

後續步驟Next steps

若要深入了解 Azure Rights Management 服務,請使用 了解和探索 一節中的其他文章 (例如 應用程式如何支援 Azure Rights Management 服務),以了解現有應用程式要如何與 Azure Rights Management 整合以提供資訊保護解決方案。To learn more about the Azure Rights Management service, use the other articles in the Understand & Explore section, such as How applications support the Azure Rights Management service to learn how your existing applications can integrate with Azure Rights Management to provide an information protection solution.

請檢閱 Azure 資訊保護術語,以熟悉您可能會在設定和使用 Azure Rights Management 服務時遇到的字詞,也請務必要先查看 Azure 資訊保護需求再開始部署。Review Terminology for Azure Information Protection so that you’re familiar with the terms that you might come across as you’re configuring and using the Azure Rights Management service, and be sure to also check Requirements for Azure Information Protection before you start your deployment. 如果您想要直接著手並親自試用,請使用快速入門和教學課程:If you want to dive right in and try it out for yourself, use the quickstart and tutorials:

如果您已準備好開始部署組織的資料保護,請使用 AIP 部署藍圖進行分類、標記和保護 ,以取得部署步驟和作法指示的連結。If you’re ready to start deploying data protection for your organization, use the AIP deployment roadmap for classification, labeling, and protection for your deployment steps and links for how-to instructions.

提示

如需詳細資訊與說明,請使用 Azure 資訊保護的資訊與支援中的資源和連結。For additional information and help, use the resources and links in Information and support for Azure Information Protection.