Azure RMS 如何運作? 在面罩下

若要瞭解 Azure RMS 的運作方式,請注意,此來自 Azure 資訊保護 的資料保護服務不會在保護程式中看到或儲存您的資料。 除非您明確地將它儲存在 Azure 中,或使用另一個儲存在 Azure 中的雲端服務,否則您保護的資訊永遠不會傳送至 Azure 或儲存在 Azure 中。 Azure RMS 只會讓授權使用者和服務以外的任何人無法讀取檔中的資料:

  • 資料會在應用程式層級加密,並包含定義該檔授權使用的原則。

  • 當合法使用者使用受保護的檔,或由授權服務處理時,檔中的資料會解密,並強制執行原則中定義的權利。

您可以在下圖中查看此程式的運作方式。 包含私人公式的檔會受到保護,然後由授權的使用者或服務成功開啟。 此圖片中綠色按鍵 () 保護檔。 這是每份檔的唯一,並放置在檔案標題中,其中受到 Azure 資訊保護租使用者根鍵保護, (此圖片中的紅色金鑰) 。 您的租使用者金鑰可由 Microsoft 產生和管理,也可以產生和管理您自己的租使用者金鑰。

在整個保護程式中,當 Azure RMS 加密和解密、授權和強制執行限制時,私人公式永遠不會傳送至 Azure。

How Azure RMS protects a file

如需目前情況的詳細描述,請參閱本文的 Azure RMS 運作方式逐步解說:第一次使用、內容保護、內容使用 一節。

如需有關 Azure RMS 所使用的演算法和金鑰長度的技術詳細資料,請參閱下一節。

Azure RMS 使用的密碼編譯控制項:演算法和金鑰長度

即使您不需要詳細瞭解此技術的運作方式,系統仍可能會詢問您該技術所使用的密碼編譯控制項。 例如,確認安全性保護是業界標準。

密碼編譯控制項 在 Azure RMS 中使用
演算法:AES

機碼長度:128 個位和 256 個位 [1]
內容保護
演算法:RSA

機碼長度:2048 位 [2]
金鑰保護
SHA-256 憑證簽署
註腳 1

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

  • 一般保護 (.pfile) 。

  • 當檔已受 ISO 標準 PDF 加密保護,或產生的受保護檔副檔名為 .ppdf 時,PDF 檔的原生保護。

  • 文字或影像檔 (的原生保護,例如 .ptxt 或 .pjpg) 。

註腳 2

2048 位是啟用 Azure 版權管理服務時的關鍵長度。 下列選用案例支援 1024 個位:

  • 從內部部署移轉期間,如果 AD RMS 叢集以密碼編譯模式 1 執行。

  • 對於在移轉之前于內部部署建立的封存金鑰,讓先前受 AD RMS 保護的內容可以在移轉之後繼續由 Azure 版權管理服務開啟。

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

針對受 Azure RMS 保護的每一份檔或電子郵件,Azure RMS 會建立單一 AES 鍵 (「內容鍵」) ,該按鍵會內嵌至檔,並會持續使用檔的各個版本。

內容金鑰會受到組織 RSA 金鑰的保護, (「Azure 資訊保護租使用者金鑰」) 做為檔中原則的一部分,而且該原則也會由檔的作者簽署。 此租使用者金鑰適用于組織 Azure 版權管理服務保護的所有檔和電子郵件,而且只有組織使用客戶管理 (稱為「攜帶您自己的金鑰」或 BYOK) 的租使用者金鑰時,Azure 資訊保護系統管理員才能變更此金鑰。

這個租使用者金鑰在 Microsoft 的線上服務、高度控管的環境中,在嚴密監視下受到保護。 當您使用由客戶管理的租使用者金鑰 (BYOK) 時,在每個 Azure 區域中使用高階硬體安全性模組陣列 (HSM) ,在任何情況下都無法擷取、匯出或共用金鑰,藉此增強此安全性。 如需有關租使用者金鑰和 BYOK 的詳細資訊,請參閱規劃及實作您的 Azure 資訊保護租使用者金鑰

傳送到Windows裝置的授權和憑證會受到用戶端裝置私密金鑰的保護,這是裝置上使用者第一次使用 Azure RMS 時建立的。 而這個私密金鑰則會受到用戶端上的 DPAPI 保護,藉此使用從使用者密碼衍生出的金鑰來保護這些機密。 在行動裝置上,金鑰只會使用一次,因此因為這些金鑰不會儲存在用戶端上,所以不需要在裝置上受到保護。

Azure RMS 運作方式的逐步解說:首次使用、內容保護、內容使用

若要深入瞭解 Azure RMS 的運作方式,讓我們逐步瞭解Azure 版權管理服務啟動之後的一般流程,以及當使用者第一次在Windows電腦上使用版權管理服務時, (稱為初始化使用者環境或啟動) 、保護檔或電子郵件) (內容的程式。 然後取用 (開啟並使用) 受他人保護的內容。

初始化使用者環境之後,該使用者就可以保護檔或取用該電腦上受保護的檔。

注意

如果此使用者移至另一部Windows電腦,或是其他使用者使用相同的Windows電腦,則會重複初始化程式。

初始化使用者環境

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

RMS Client activation flow - step 1, authenticating the client

步驟 1 中發生的情況:電腦上的 RMS 用戶端會先連線至 Azure 版權管理服務,並使用使用者的Azure Active Directory帳戶驗證使用者。

當使用者的帳戶與Azure Active Directory同盟時,此驗證會自動進行,且不會提示使用者輸入認證。

RMS Client activation - step 2, certificates are downloaded to the client

步驟 2 中發生的情況:驗證使用者之後,連線會自動重新導向到組織的 Azure 資訊保護 租使用者,這會向 Azure 版權管理服務發出憑證,讓使用者驗證以取用受保護的內容,以及離線保護內容。

其中一個憑證是版權帳戶憑證,通常縮寫為 RAC。 此憑證會驗證使用者Azure Active Directory,有效期為 31 天。 RMS 用戶端會自動更新憑證,提供使用者帳戶仍在Azure Active Directory且帳戶已啟用。 系統管理員無法設定此憑證。

此憑證的複本會儲存在 Azure 中,這樣一來,如果使用者移至另一部裝置,憑證就會使用相同的金鑰建立。

內容保護

當使用者保護檔時,RMS 用戶端會對未受保護的檔採取下列動作:

RMS document protection - step 1, document is encrypted

步驟 1 中發生的情況:RMS 用戶端會建立隨機鍵 (內容鍵) ,並使用此金鑰搭配 AES 對稱加密演算法來加密檔。

RMS document protection - step 2, policy is created

步驟 2 中發生的情況:RMS 用戶端接著會建立一個憑證,其中包含檔的原則,其中包含使用者或群組的 使用權 ,以及其他限制,例如到期日。 您可以在系統管理員先前設定的範本中定義這些設定,或是在內容受到保護時指定, (有時稱為「臨機操作原則」) 。

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

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

RMS document protection - step 3, policy is embedded in the document

步驟 3 中發生的情況:最後,RMS 用戶端會將原則內嵌至先前加密檔本文的檔案中,該檔案會一起組成受保護的檔。

此檔可以儲存在任何位置或使用任何方法共用,而且原則永遠會保留在加密的檔中。

內容使用

當使用者想要使用受保護的檔時,RMS 用戶端會從要求存取 Azure 版權管理服務開始:

RMS document consumption - step 1, user is authenticated and gets the list of rights

步驟 1 中發生的情況:已驗證的使用者會將檔原則和使用者憑證傳送至 Azure 版權管理服務。 服務會解密並評估原則,並在使用者擁有的檔) 任何) ,建立權利 (清單。 若要識別使用者,Azure AD ProxyAddresses 屬性會用於使用者的帳戶和使用者所屬群組。 基於效能的原因,系統會 快取群組成員資格。 如果使用者帳戶沒有 Azure AD ProxyAddresses 屬性的值,則會改用 Azure AD UserPrincipalName 中的值。

RMS document consumption - step 2, use license is returned to the client

步驟 2 中發生的情況:服務接著從解密原則中擷取 AES 內容金鑰。 然後,系統會將此金鑰與使用者透過要求取得的公用 RSA 金鑰加密。

然後,重新加密的內容金鑰會內嵌到具有使用者許可權清單的加密使用授權中,然後傳回至 RMS 用戶端。

RMS document consumption - step 3, document is decrypted and rights are enforced

步驟 3 中發生的情況:最後,RMS 用戶端會取得加密的使用授權,並以自己的使用者私密金鑰解密。 這可讓 RMS 用戶端視需要解密檔的本文,並在螢幕上呈現。

用戶端也會解密版權清單,並將它們傳遞給應用程式,以強制執行應用程式使用者介面中的這些權利。

注意

當組織外部的使用者使用您保護的內容時,消費流程會是相同的。 此案例的變更,就是使用者的驗證方式。 如需詳細資訊,請參閱 當我與公司外部人員共用受保護的檔時,該使用者如何獲得驗證?

變化

前述逐步解說涵蓋標準案例,但有一些變化:

  • 電子郵件保護:當Exchange Online和Office 365使用新功能的郵件加密來保護電子郵件訊息時,消費驗證也可以使用與社交身分識別提供者同盟或使用一次性密碼。 然後,程式流程非常類似,只是內容使用會在網頁瀏覽器會話中透過暫時快取的輸出電子郵件複本進行服務端處理。

  • 行動裝置:當行動裝置透過 Azure 版權管理服務保護或取用檔案時,程式流程會簡單得多。 行動裝置不會先完成使用者初始化程式,因為保護或取用內容) 的每個交易 (都是獨立的。 與Windows電腦一樣,行動裝置會連線至 Azure 版權管理服務並進行驗證。 為了保護內容,行動裝置會提交原則,而 Azure 版權管理服務會傳送發佈授權和對稱金鑰給他們以保護檔。 若要取用內容,當行動裝置連線至 Azure 版權管理服務並進行驗證時,裝置會將檔原則傳送至 Azure 版權管理服務,並要求使用授權以取用檔。 為了回應,Azure 版權管理服務會將必要的金鑰和限制傳送至行動裝置。 這兩個程式都使用 TLS 來保護金鑰交換和其他通訊。

  • RMS 連接器:當 Azure 版權管理服務與 RMS 連接器搭配使用時,程式流程會保持不變。 唯一的差異在於連接器會做為內部部署服務 (之間的轉送,例如 Exchange Server 和 SharePoint Server) 和 Azure 版權管理服務。 連接器本身不會執行任何作業,例如初始化使用者環境,或加密或解密。 它只會轉送通常會移至 AD RMS 伺服器的通訊,處理每一端所使用通訊協定之間的翻譯。 此案例可讓您搭配內部部署服務使用 Azure 版權管理服務。

  • 一般保護 (.pfile) :當 Azure 版權管理服務一般保護檔案時,內容保護的流程基本上是相同的,但 RMS 用戶端建立的原則會授與擁有權利。 當檔案被使用時,檔案會先解密,然後再傳遞到目標應用程式。 此案例可讓您保護所有檔案,即使它們不是原生支援 RMS。

  • Microsoft 帳戶:Azure 資訊保護可以在經過 Microsoft 帳戶驗證時,授權電子郵件地址以供使用。 不過,當 Microsoft 帳戶用於驗證時,並非所有應用程式都可以開啟受保護的內容。 詳細資訊

後續步驟

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

檢閱Azure 資訊保護術語,讓您熟悉在設定和使用 Azure 版權管理服務時可能會遇到的詞彙,並且在開始部署之前,請務必先檢查Azure 資訊保護的需求。 如果您想要直接深入瞭解並親自試用,請使用快速入門和教學課程:

如果您已準備好開始為組織部署資料保護,請使用 AIP 部署藍圖來分類、標籤和保護 您的部署步驟和連結,以取得使用方法指示。

提示

如需其他資訊和說明,請使用Azure 資訊保護資訊及支援中的資源和連結。