如果您想要深入瞭解 Azure Rights Management 服務的 運作方式，請使用下列資訊。 您不需要知道此層級的資訊，即可設定或套用加密設定來保護您的資料。
注意事項
當 Azure Rights Management 服務以獨立產品的形式提供，而不是 Microsoft Purview 資訊保護的一部分時，它通常會縮寫為 Azure RMS。 您可以在本文的圖片中看到這個縮寫。
要了解 Azure Rights Management 服務的重要概念是，此服務不會在加密程式中看到或儲存您的資料。 您加密的資訊絕不會傳送至 Azure 或儲存在 Azure 中，除非您將其明確儲存在 Azure 中，或使用其他雲端服務將它儲存在 Azure 中。 Azure Rights Management 服務只會讓授權使用者和服務以外的任何人都無法讀取專案中的資料：
資料會在應用程式層級加密，並包含定義該項目授權使用的原則。
當合法使用者使用加密項目或由授權服務處理時，項目中的資料會解密，並強制執行原則中定義的許可權。
概括而言，您可以在下圖中看到此程式的運作方式。 包含秘密公式的文件會加密，然後由授權使用者或服務順利開啟。 檔會由內容金鑰 (此圖片) 中的綠色金鑰加密。 內容金鑰對於每個檔都是唯一的，並放置在檔案標頭中，其中由您的 Azure Rights Management 租用戶根金鑰 (此圖片) 中的紅色金鑰加密。 您的租用戶金鑰可以由 Microsoft 產生和管理，也可以產生和管理自己的租用戶金鑰。
當 Azure Rights Management 服務加密和解密、授權和強制執行限制時，在整個加密程式中，秘密公式永遠不會傳送至 Azure。
如需所發生情況的詳細描述，請參閱本文中的服務 運作方式逐步解說：首次使用、內容加密、內容取用 一節。
如需服務所使用的演算法和金鑰長度的詳細資訊，請參閱下一節。
密碼編譯控制：演算法和金鑰長度
即使您不需要詳細了解這項技術的工作原理，您也可能會被問到它使用的加密控制項。 例如，確認加密是業界標準。
| 密碼編譯控制項 | 在 Azure Rights Management 服務中使用 |
|---|---|
| 演算法：AES 金鑰長度：128 位元和 256 位元 [1] |
內容加密 |
| 演算法：RSA 金鑰長度：2048 位元 [2] |
金鑰加密 |
| SHA-256 | 憑證簽署 |
註腳 1
在下列案例中，Microsoft Purview 資訊保護用戶端會使用 256 位：
通用加密 (.pfile) 。
當文件已使用 PDF 加密的 ISO 標準進行加密，或產生的加密文件具有 .ppdf 副檔名時，PDF 文件的原生加密。
文字或影像檔案的原生加密 (例如 .ptxt 或 .pjpg) 。
註腳 2
2048 位是啟用 Azure Rights Management 服務時的金鑰長度。 下列選擇性案例支援 1024 位元：
在從內部部署移轉期間，如果 AD RMS 叢集以密碼編譯模式 1 執行。
適用於在移轉之前在內部部署建立的封存金鑰，讓先前由 AD RMS 加密的內容可以在移轉後繼續由 Azure Rights Management 服務開啟。
如何儲存及保護加密金鑰
針對受 Azure Rights Management 服務保護的每個文件或電子郵件，服務會 (「內容金鑰」) 建立單一 AES 金鑰，而該金鑰會內嵌至文件，並在文件的各個版本中持續存在。
內容金鑰會使用組織的 RSA 金鑰 (「Azure Rights Management 租用戶金鑰」進行加密 ) 作為檔中原則的一部分，而且原則也會由檔的作者簽署。 此租用戶金鑰是受組織 Azure Rights Management 服務保護的所有文件和電子郵件的通用，而且只有在組織使用客戶管理 (的租用戶金鑰 （稱為「自備金鑰」或 BYOK) ） 時，只有系統管理員才能變更此金鑰。
此租用戶金鑰在 Microsoft 的線上服務中受到保護，在高度受控的環境中，並受到密切監視。 當您使用 BYOK) (客戶管理的租用戶金鑰時，會藉由使用每個 Azure 區域中) 的 HSM (陣列來增強此安全性，而無法在任何情況下擷取、匯出或共用金鑰。 如需租用戶金鑰和 BYOK 的詳細資訊，請參閱 管理 Azure Rights Management 服務的根金鑰。
傳送至 Windows 裝置的授權和憑證會使用用戶端的裝置私密金鑰進行加密。 此私密金鑰是在裝置上的使用者第一次使用 Azure Rights Management 服務時建立。 此私密金鑰會在用戶端上使用 DPAPI 加密，以使用衍生自使用者密碼的金鑰來保護這些秘密。 在行動裝置上，金鑰只會使用一次，因此由於金鑰不會儲存在用戶端上，因此不需要在裝置上加密這些金鑰。
服務運作方式逐步解羅：首次使用、內容加密、內容取用
若要更詳細地瞭解 Azure Rights Management 服務的運作方式，讓我們逐步解說啟用 Azure Rights Management 服務 之後的一般流程，以及當使用者第一次從其 Windows 電腦使用 Rights Management 服務時， (有時稱為 初始化使用者環境 或啟動載入) 程式的程式，加密文件或電子郵件) (內容 ， 然後 消費 (打開和使用) 已被其他人加密的內容。
初始化使用者環境之後，該使用者就可以在該電腦上加密文件或取用加密文件。
注意事項
如果此使用者移至另一部 Windows 電腦，或另一個使用者使用這部相同的 Windows 電腦，則會重複初始化程式。
起始設定使用者環境
使用者必須先在裝置上加密內容或取用加密內容，才能在裝置上準備使用者環境。 這是一次性程序，當使用者嘗試加密或取用加密內容時，會自動發生，無需使用者介入：
步驟 1 中發生的情況：在電腦上執行的 Azure Rights Management 服務的用戶端會先連線到服務，而服務會使用其 Microsoft Entra 帳戶來驗證使用者。
當使用者的帳戶與 Microsoft Entra ID 同盟時，此驗證會自動進行，而且系統不會提示使用者輸入認證。
步驟 2 中發生的情況：使用者經過驗證之後，連線會自動重新導向至組織的租用戶，該租用戶會發出憑證，讓使用者向 Azure Rights Management 服務進行驗證，以取用加密的內容並離線加密內容。
其中一個憑證是權利帳戶憑證，通常縮寫為 RAC。 此憑證會向 Microsoft Entra ID 驗證使用者，且有效期為 31 天。 憑證會由用戶端自動更新，前提是使用者帳戶仍在 Microsoft Entra ID 中，且帳戶已啟用。 系統管理員無法設定此憑證。
此憑證的複本會儲存在 Azure 中，因此如果使用者移至另一部裝置，則會使用相同的金鑰來建立憑證。
內容加密
當使用者加密文件時，Azure Rights Management 服務的用戶端會對未加密的文件採取下列動作：
步驟 1 中發生的情況：用戶端會 (內容金鑰) 建立隨機金鑰，並使用此金鑰搭配 AES 對稱加密演算法來加密文件。
步驟 2 中發生的情況：然後，用戶端會建立憑證，其中包含文件的原則，其中包含使用者或群組的 使用權限 ，以及其他限制，例如到期日。 這些設定可以使用系統管理員先前設定的敏感度標籤加密設定來定義，或在內容加密時指定， (有時稱為「使用者定義的許可權」或「臨機操作原則」) 。
用來識別所選使用者和群組的主要 Microsoft Entra 屬性是 Microsoft Entra ProxyAddresses 屬性，它會儲存使用者或群組的所有電子郵件地址。 不過，如果使用者帳戶在 AD ProxyAddresses 屬性中沒有任何值，則會改用使用者的 UserPrincipalName 值。
然後，用戶端會使用初始化使用者環境時取得的組織金鑰，並使用此金鑰來加密原則和對稱內容金鑰。 用戶端也會使用初始化使用者環境時取得的使用者憑證來簽署原則。
步驟 3 中發生的情況：最後，用戶端會將原則內嵌到先前加密文件本文的檔案中，這些檔案共同構成加密文件。
此文件可以儲存在任何地方，或使用任何方法共用，且原則一律會保留在加密文件中。
內容消費
當使用者想要取用加密檔時，用戶端會先要求存取 Azure Rights Management 服務：
步驟 1 中發生的情況：已驗證的使用者會將文件原則和使用者的憑證傳送至 Azure Rights Management 服務。 服務會解密並評估原則，並建置使用者對文件擁有的權限清單 (如果有任何) 。 若要識別使用者，Microsoft Entra ProxyAddresses 屬性會用於使用者所屬的使用者帳戶和群組。 基於效能考量，會 快取群組成員資格。 如果使用者帳戶沒有任何 Microsoft Entra ProxyAddresses 屬性值，則會改用 Microsoft Entra UserPrincipalName 中的值。
步驟 2 中發生的情況：然後，服務會從解密的原則中擷取 AES 內容金鑰。 然後，此金鑰會使用透過要求取得的使用者公開 RSA 金鑰進行加密。
然後，重新加密的內容金鑰會內嵌到具有使用者權限清單的加密使用授權中，然後傳回給用戶端。
步驟 3 中發生的情況：最後，用戶端取得加密的使用授權，並使用自己的使用者私鑰解密它。 這可讓用戶端根據需要解密文件的正文，並將其呈現在畫面上。
用戶端也會解密權限清單，並將其傳遞給應用程式，應用程式會在應用程式的使用者介面中強制執行這些權限。
注意事項
當組織外部的使用者取用您已加密的內容時，取用流程是相同的。 此案例的變更是使用者的驗證方式。 如需詳細資訊，請參閱 當我與公司外部的人員共用加密文件時，該使用者如何進行驗證？
Variations
上述逐步解說涵蓋標準案例，但有一些變化：
Email 加密：當使用 Exchange Online 和 Microsoft Purview 郵件加密來加密電子郵件訊息時，取用驗證也可以使用與社交身分識別提供者的同盟，或使用一次性密碼。 然後，流程非常相似，不同之處在於內容使用是在 Web 瀏覽器工作階段中的服務端，透過暫時快取的輸出電子郵件副本進行。
行動裝置：當行動裝置使用 Azure Rights Management 服務加密或取用檔案時，程式流程會更簡單。 行動裝置不會先經過使用者初始化程序，因為相反，每個交易都 (加密或使用內容) 是獨立的。 如同 Windows 電腦，行動裝置會連線到 Azure Rights Management 服務並進行驗證。 若要加密內容，行動裝置會提交原則，而 Azure Rights Management 服務會傳送發佈授權和對稱金鑰來加密文件。 若要取用加密的內容，當行動裝置連線到 Azure Rights Management 服務並進行驗證時，它們會將文件原則傳送至 Azure Rights Management 服務，並要求使用授權來取用文件。 作為回應，Azure Rights Management 服務會將必要的金鑰和限制傳送至行動裝置。 這兩個進程都使用 TLS 來保護金鑰交換和其他通訊。
Rights Management 連接器：當 Azure Rights Management 服務與 Rights Management 連接器搭配使用時，程序流程會保持不變。 唯一的差異是連接器會做為內部部署服務 (（例如 Exchange Server 和 SharePoint Server) ） 與 Azure Rights Management 服務之間的轉送。 連接器本身不會執行任何作業，例如使用者環境的初始化，或加密或解密。 它只會轉送通常會傳送至 AD RMS 伺服器的通訊，處理每一端所使用的通訊協定之間的轉譯。 此案例可讓您搭配內部部署服務使用 Azure Rights Management 服務。
一般加密 (.pfile) ：當 Azure Rights Management 服務一般加密檔案時，內容加密的流程基本上相同，只是用戶端會建立授與所有權限的原則。 取用檔案時，會在傳遞至目標應用程式之前解密檔案。 此案例可讓您加密所有檔案，即使它們原生不支援 Azure Rights Management 服務也一樣。
Microsoft 帳戶：Azure Rights Management 服務可以在使用 Microsoft 帳戶驗證時授權電子郵件地址取用。 不過，當使用 Microsoft 帳戶進行驗證時，並非所有應用程式都可以開啟加密內容。 更多資訊。
後續步驟
如需 Azure Rights Management 服務的較不技術概觀，請參閱 瞭解 Azure Rights Management 服務。
如果您已準備好進行包含加密以保護數據的部署建議步驟，請參閱 使用 Microsoft Purview 部署資訊保護解決方案。