準備 Azure 資訊保護 的使用者和群組

  • 發行項

注意

您要尋找 Microsoft Purview 資訊保護，前身為 Microsoft 資訊保護 （MIP）？

Azure 資訊保護 載入宏已淘汰，並以 Microsoft 365 應用程式和服務內建的標籤取代。 深入瞭解其他 Azure 資訊保護元件的支持狀態。

新的 Microsoft 資訊保護 用戶端（不含載入宏）目前處於預覽狀態，並排程正式運作。

在您為組織部署 Azure 資訊保護 之前，請確定您有組織租使用者 Microsoft Entra 標識碼中的使用者和群組帳戶。

為使用者和群組建立這些帳戶的方式有不同，包括：

  • 您可以在 Microsoft 365 系統管理中心 中建立使用者，以及 Exchange Online 系統管理中心中的群組。

  • 您可以在 Azure 入口網站 中建立使用者和群組。

  • 您可以使用 Azure AD PowerShell 和 Exchange Online Cmdlet 來建立使用者和群組。

  • 您可以在 內部部署的 Active Directory 中建立使用者和群組，並將其同步處理至 Microsoft Entra ID。

  • 您會在另一個目錄中建立使用者和群組，並將其同步處理至 Microsoft Entra ID。

當您使用此清單中的前三種方法來建立使用者和群組時，除了一個例外，它們會自動在 Microsoft Entra ID 中建立，而 Azure 資訊保護 可以直接使用這些帳戶。 不過，許多企業網路會使用內部部署目錄來建立和管理使用者和群組。 Azure 資訊保護 無法直接使用這些帳戶;您必須將它們同步處理至 Microsoft Entra ID。

上一段所參考的例外狀況是您可以為 Exchange Online 建立的動態通訊組清單。 與靜態通訊組清單不同，這些群組不會復寫到 Microsoft Entra ID，因此 Azure 資訊保護 無法使用。

Azure 資訊保護 如何使用使用者和群組

使用使用者和群組搭配 Azure 資訊保護 有三種案例：

當您設定 Azure 資訊保護 原則時，將標籤指派給使用者，以便將標籤套用至文件和電子郵件。 只有系統管理員可以選取這些使用者和群組：

  • 默認的 Azure 資訊保護 原則會自動指派給租使用者 Microsoft Entra 識別碼中的所有使用者。 不過，您也可以使用範圍原則，將其他標籤指派給指定的使用者或群組。

當您使用 Azure Rights Management 服務來保護檔和電子郵件時，指派許可權和訪問控制 。 管理員 istrators 和使用者可以選取下列使用者和群組：

  • 許可權會決定使用者是否可以開啟檔或電子郵件，以及其使用方式。 例如，無論是只能讀取或讀取和列印，還是讀取和編輯它。

  • 訪問控制包括到期日，以及是否需要連線到因特網才能存取。

若要設定 Azure Rights Management 服務 以支援特定案例，因此只有系統管理員選取這些群組。 範例包括設定下列專案：

  • 進階使用者，讓指定的服務或人員可以視需要開啟加密的內容進行電子檔探索或數據復原。

  • 委派的 Azure Rights Management 服務管理。

  • 上線控制項以支持階段式部署。

用戶帳戶的 Azure 資訊保護 需求

用於指定標籤：

  • Microsoft Entra ID 中的所有用戶帳戶都可以用來設定將其他標籤指派給使用者的範圍原則。

用於指派許可權和訪問控制，以及設定 Azure Rights Management 服務：

  • 若要授權使用者，會使用 Microsoft Entra ID 中的兩個屬性： proxyAddresses 和 userPrincipalName。

  • Microsoft Entra proxyAddresses 屬性會儲存帳戶的所有電子郵件位址，而且可以透過不同的方式填入。 例如，Microsoft 365 中具有 Exchange Online 信箱的用戶會自動擁有儲存在此屬性中的電子郵件位址。 如果您指派 Microsoft 365 使用者的替代電子郵件位址，它也會儲存在此屬性中。 也可以由從內部部署帳戶同步處理的電子郵件位址填入。

    Azure 資訊保護 可以使用此 Microsoft Entra proxyAddresses 屬性中的任何值，前提是網域已新增至您的租使用者（已驗證的網域）。 如需驗證網域的詳細資訊：

  • 只有當租使用者中的帳戶沒有 Microsoft Entra proxyAddresses 屬性中的值時，才會使用 Microsoft Entra userPrincipalName 屬性。 例如，您會在 Azure 入口網站 中建立使用者，或為沒有信箱的 Microsoft 365 建立使用者。

將使用權限和存取控制指派給外部使用者

除了針對租使用者中的使用者使用 Microsoft Entra proxyAddresses 和 Microsoft Entra userPrincipalName 之外，Azure 資訊保護 也會以相同方式使用這些屬性來授權來自另一個租用戶的使用者。

其他授權方法：

  • 對於不在 Microsoft Entra ID 中的電子郵件位址，Azure 資訊保護 可以在使用 Microsoft 帳戶進行驗證時授權這些位址。 不過，並非所有應用程式都可以在 Microsoft 帳戶用於驗證時開啟受保護的內容。 詳細資訊

  • 使用 Office 365 郵件加密將電子郵件與新功能傳送給沒有 Microsoft Entra 識別符帳戶的使用者時，使用者會先使用與社交識別提供者的同盟或使用一次性密碼進行驗證。 然後，受保護的電子郵件中指定的電子郵件位址會用來授權使用者。

群組帳戶的 Azure 資訊保護 需求

用於指定標籤：

  • 若要設定將其他標籤指派給群組成員的範圍原則，您可以在 Microsoft Entra ID 中使用任何類型的群組，該群組具有包含使用者租用戶已驗證網域的電子郵件位址。 具有電子郵件地址的群組通常稱為已啟用郵件的群組。

    例如，您可以使用已啟用郵件功能的安全組、靜態通訊群組和 Microsoft 365 群組。 您無法使用安全組（動態或靜態），因為此群組類型沒有電子郵件位址。 您也無法從 Exchange Online 使用動態通訊組清單，因為此群組不會復寫至 Microsoft Entra ID。

指定指定權限與存取控制：

  • 您可以在 Microsoft Entra ID 中使用任何類型的群組，其電子郵件位址包含使用者租使用者的已驗證網域。 具有電子郵件地址的群組通常稱為已啟用郵件的群組。

設定 Azure Rights Management 服務：

  • 您可以在 Microsoft Entra ID 中使用任何類型的群組，該群組具有來自租使用者中已驗證網域的電子郵件位址，但有一個例外。 例外狀況是當您將上線控件設定為使用群組時，該群組必須是租使用者 Microsoft Entra 標識符中的安全組。

  • 您可以從租使用者中已驗證的網域使用 Microsoft Entra ID 中任何群組（含或不含電子郵件位址），以委派 Azure Rights Management 服務的系統管理。

將許可權和訪問控制指派給外部群組

除了針對租使用者中的群組使用 Microsoft Entra proxyAddresses 之外，Azure 資訊保護 也會以相同方式使用此屬性來授權來自另一個租使用者的群組。

使用 Active Directory 內部部署的帳戶進行 Azure 資訊保護

如果您有要與 Azure 資訊保護 搭配使用的內部部署受控帳戶，您必須將這些帳戶同步處理至 Microsoft Entra ID。 為了方便部署，建議您使用 Microsoft Entra 連線。 不過，您可以使用任何達到相同結果的目錄同步處理方法。

當您同步處理帳戶時，不需要同步處理所有屬性。 如需必須同步處理的屬性清單，請參閱 Microsoft Entra 檔案中的 Azure RMS 一節 。

從 Azure Rights Management 的屬性清單中，您會看到對於使用者而言，同步處理需要郵件、proxyAddresses 和 userPrincipalName 的內部部署 AD 屬性。 郵件和 proxyAddresses 的值會同步處理至 Microsoft Entra proxyAddresses 屬性。 如需詳細資訊，請參閱 ProxyAddresses 屬性如何在 Microsoft Entra ID 中填入

確認您的使用者和群組已針對 Azure 資訊保護 做好準備

您可以使用 Azure AD PowerShell 來確認使用者和群組可與 Azure 資訊保護 搭配使用。 您也可以使用 PowerShell 來確認可用來授權的值。

注意

自 2024 年 3 月 30 日起，Azure AD 和 MSOnline PowerShell 模組已被淘汰。 若要深入了解，請參閱淘汰更新。 在此日期之後，這些模組的支援僅限於 Microsoft Graph PowerShell SDK 和安全性修正的移轉協助。 已淘汰的模組將繼續在 2025 年 3 月 30 日運作。

建議移轉至 Microsoft Graph PowerShell，以與 Microsoft Entra ID (先前稱為 Azure AD) 互動。 如需常見的移轉問題，請參閱移轉常見問題。 注意：MSOnline 1.0.x 版可能會在 2024 年 6 月 30 日之後發生中斷。

例如，在 PowerShell 會話中使用適用於 Microsoft Entra ID、 MSOnline 的 V1 PowerShell 模組，先連線到服務並提供全域管理員認證：

Connect-MsolService

注意：如果此命令無法運作，您可以執行 Install-Module MSOnline 來安裝 MSOnline 模組。

接下來，設定 PowerShell 工作階段，使其不會截斷值：

$Formatenumerationlimit =-1

確認用戶帳戶已準備好用於 Azure 資訊保護

若要確認使用者帳戶，請執行下列命令：

Get-Msoluser | select DisplayName, UserPrincipalName, ProxyAddresses

您的第一個檢查是確定您想要與 Azure 資訊保護 搭配使用的使用者隨即顯示。

然後檢查 ProxyAddresses 數據行是否已填入。 如果是，此數據行中的電子郵件值可用來授權用戶進行 Azure 資訊保護。

如果未填入 ProxyAddresses 數據行，則會使用 UserPrincipalName 中的值來授權 Azure Rights Management 服務的使用者。

例如：

顯示名稱 UserPrincipalName ProxyAddresses
賈根納思·雷迪 jagannathreddy@contoso.com {}
安庫爾·羅伊 ankurroy@contoso.com {SMTP：ankur.roy@contoso.com， smtp： ankur.roy@onmicrosoft.contoso.com}

在此範例中：

  • Jagannath Reddy 的用戶帳戶將由 授權 jagannathreddy@contoso.com。

  • Ankur Roy 的使用者帳戶可以使用 和 ankur.roy@onmicrosoft.contoso.com來授權，但不能ankurroy@contoso.com授權 ankur.roy@contoso.com 。

在大部分情況下，UserPrincipalName 的值符合 ProxyAddresses 欄位中的其中一個值。 這是建議的設定，但如果您無法變更 UPN 以符合電子郵件位址，您必須採取下列步驟：

  1. 如果 UPN 值中的功能變數名稱是 Microsoft Entra 租使用者的已驗證網域，請在 Microsoft Entra ID 中將 UPN 值新增為另一個電子郵件位址，讓 UPN 值現在可用來授權 Azure 資訊保護 的用戶帳戶。

    如果UPN值中的功能變數名稱不是租使用者的已驗證網域，就無法與 Azure 資訊保護 搭配使用。 不過，當群組電子郵件位址使用已驗證的功能變數名稱時，使用者仍然可以獲得群組成員的授權。

  2. 如果 UPN 無法路由傳送（例如 ankurroy@contoso.local），請設定使用者的替代登入標識碼，並指示他們如何使用這個替代登入來登入 Office。 您也必須設定 Office 的登錄機碼。

    透過使用者的 UPN 變更，至少 24 小時或直到 UPN 變更正確反映在系統中，才會遺失商務持續性。

    如需詳細資訊，請參閱設定替代登入標識符和 Office 應用程式 數據，定期提示輸入 SharePoint、OneDrive 和 Lync Online 的認證。

提示

您可以使用 Export-Csv Cmdlet 將結果匯出至電子錶格，以方便管理，例如搜尋和大量編輯以匯入。

例如：Get-MsolGroup | select DisplayName, ProxyAddresses | Export-Csv -Path UserAccounts.csv

注意

透過使用者的 UPN 變更，至少 24 小時或直到 UPN 變更正確反映在系統中，才會遺失商務持續性。

確認組帳戶已準備好進行 Azure 資訊保護

若要確認組帳戶，請使用下列命令：

Get-MsolGroup | select DisplayName, ProxyAddresses

請確定您想要與 Azure 資訊保護 搭配使用的群組隨即顯示。 針對顯示的群組，可以使用 ProxyAddresses 數據行中的電子郵件地址來授權 Azure Rights Management 服務的群組成員。

然後，檢查群組是否包含您想要用於 Azure 資訊保護 的使用者（或其他群組）。 您可以使用PowerShell來執行此動作（例如 Get-MsolGroupMember），或使用您的管理入口網站。

針對使用安全組的兩個 Azure Rights Management 服務組態案例，您可以使用下列 PowerShell 命令來尋找可用來識別這些群組的物件識別符和顯示名稱。 您也可以使用 Azure 入口網站 來尋找這些群組，並複製物件識別碼和顯示名稱的值：

Get-MsolGroup | where {$_.GroupType -eq "Security"}

Azure 資訊保護 電子郵件地址變更時的考慮

如果您變更使用者或群組的電子郵件地址，建議您將舊的電子郵件位址新增為第二個電子郵件位址（也稱為 Proxy 位址、別名或替代電子郵件位址）至使用者或群組。 當您這樣做時，舊的電子郵件位址會新增至 Microsoft Entra proxyAddresses 屬性。 此帳戶管理可確保在舊電子郵件位址使用時儲存的任何許可權或其他設定的商務持續性。

如果您無法這麼做，具有新電子郵件地址的使用者或群組可能會拒絕存取先前使用舊電子郵件地址保護的檔和電子郵件。 在此情況下，您必須重複保護設定，以儲存新的電子郵件位址。 例如，如果使用者或群組在範本或標籤中授與許可權，請編輯這些範本或標籤，並指定與您授與舊電子郵件位址相同許可權的新電子郵件位址。

請注意，群組很少變更其電子郵件位址，而且如果您將許可權指派給群組，而不是個別使用者，則使用者的電子郵件地址變更並不重要。 在此案例中，許可權會指派給群組電子郵件位址，而不是個別的使用者電子郵件位址。 這是系統管理員設定保護檔和電子郵件的許可權時，最可能（且建議的）方法。 不過，使用者通常會為個別使用者指派自定義許可權。 因為您無法永遠知道使用者帳戶或群組是否曾用來授與存取權，所以請務必將舊的電子郵件位址新增為第二個電子郵件位址。

Azure 資訊保護 的群組成員資格快取

基於效能考慮，Azure 資訊保護 會快取群組成員資格。 這表示當 Azure 資訊保護 使用這些群組時，Microsoft Entra ID 中群組成員資格的任何變更最多可能需要三個小時才會生效，而此時段可能會變更。

請記住，當您使用群組來授與許可權或設定 Azure Rights Management 服務，或設定範圍原則時，請將此延遲納入您所做的任何變更或測試。

下一步

當您確認您的使用者和群組可與 Azure 資訊保護 搭配使用，且您已準備好開始保護檔和電子郵件時，請檢查是否需要啟用 Azure Rights Management 服務。 您必須先啟用此服務，才能保護貴組織的檔案和電子郵件：

  • 從 2018 年 2 月開始：如果您的訂用帳戶包含 Azure Rights Management 或 Azure 資訊保護，則此服務會自動為您啟用。

  • 如果您的訂用帳戶是在 2018 年 2 月之前取得的：您必須自行啟用服務。

如需詳細資訊，包括檢查啟用狀態，請參閱從 Azure 資訊保護 啟用保護服務。