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

注意

您是否正在尋找先前Microsoft 資訊保護 ( MIP) Microsoft Purview 資訊保護?

Azure 資訊保護統一標籤用戶端現在處於維護模式。 建議您使用內建在Office 365應用程式和服務的標籤。 瞭解更多資訊

為貴組織部署 Azure 資訊保護之前,請確定在 Azure AD 中擁有貴組織租用戶的使用者和群組帳戶。

有不同的方式可以建立這些使用者和群組帳戶,包括:

  • 在 Microsoft 365 系統管理中心建立使用者,然後在 Exchange Online 系統管理中心建立群組。

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

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

  • 您在內部部署 Active Directory 中建立使用者和群組,並且將它們同步處理至 Azure AD。

  • 您在其他目錄中建立使用者和群組,並且將它們同步處理至 Azure AD。

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

上一個段落中所指的例外是您可以為 Exchange Online 建立的動態通訊群組清單。 與靜態通訊群組清單不同,這些群組不會複寫到 Azure AD,因此無法由 Azure 資訊保護使用。

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

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

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

  • 預設的 Azure 資訊保護原則會自動指派給您的租用戶 Azure AD 中的所有使用者。 不過,您也可以使用有範圍的原則,將額外標籤指派給指定的使用者或群組。

針對指派使用權限和存取控制,當您使用 Azure Rights Management 服務保護文件和電子郵件時。 系統管理員和使用者可以選取這些使用者和群組:

  • 使用權限會決定使用者是否可以開啟文件或電子郵件,以及如何使用它。 例如,他們是否只能讀取它、讀取和列印它,或讀取並加以編輯。

  • 存取控制包括到期日,以及是否需要連線到網際網路才能存取。

針對設定 Azure Rights Management 服務以支援特定案例,因此只有系統管理員可以選取這些群組。 範例包括設定下列項目:

  • 進階使用者,如此指定的服務或人員可以在電子文件探索或資料探索需要時開啟加密內容。

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

  • 上架控制以支援分階段的部署。

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

針對指派標籤:

  • Azure AD 中的所有使用者帳戶都可以用來設定有範圍的原則,這些原則會將額外的標籤指派給使用者。

針對指派使用權限和存取控制,並且設定 Azure Rights Management 服務:

  • 若要授權使用者,請使用 Azure AD 中的兩個屬性:proxyAddressesuserPrincipalName

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

    Azure 資訊保護可以使用這個 Azure AD proxyAddresses 屬性中的任何值,前提是網域已新增至您的租用戶 (「已驗證網域」)。 如需有關驗證網域的詳細資訊:

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

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

除了為您租用戶中的使用者使用 Azure AD proxyAddresses 和 Azure AD userPrincipalName 以外,Azure 資訊保護也會以相同的方式使用這些屬性來授權來自其他租用戶的使用者。

其他授權方法:

  • 對於不在 Azure AD 中的電子郵件地址,Azure 資訊保護可以在他們使用 Microsoft 帳戶驗證之後,授予它們這些權限。 不過,當 Microsoft 帳戶用於驗證時,並非所有應用程式都可以開啟受保護的內容。 詳細資訊

  • 當電子郵件是透過 Office 365 郵件加密傳送,且具有在 Azure AD 中沒有帳戶之使用者的新功能時,使用者首先會透過具有社交識別提供者的同盟,或使用一次密碼來驗證使用者。 然後,會使用在受保護電子郵件中指定的電子郵件地址來授權使用者。

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

針對指派標籤:

  • 若要設定會將額外標籤指派給群組成員之有範圍的原則,您可以在 Azure AD 中使用任何類型的群組,其中具有電子郵件地址,包含使用者租用戶的已驗證網域。 具有電子郵件地址的群組通常會稱為擁有郵件功能的群組。

    例如,您可以使用已啟用郵件功能的安全性群組、靜態通訊群組和 Microsoft 365 群組。 您無法使用安全性群組 (動態或靜態),因為這種群組類型沒有電子郵件地址。 您也可以使用來自 Exchange Online 的動態通訊群組清單,因為此群組不會複寫到 Azure AD。

針對指派使用權限和存取控制:

  • 您可以在 Azure AD 中使用任何類型的群組,其中具有電子郵件地址,包含使用者租用戶的已驗證網域。 具有電子郵件地址的群組通常會稱為擁有郵件功能的群組。

針對設定 Azure Rights Management 服務:

  • 您可以在 Azure AD 中使用任何類型的群組,其中具有使用者租用戶之已驗證網域的電子郵件地址,但是有一個例外狀況。 例外狀況是當您設定上架控制以使用群組時,它必須是 Azure AD 中您租用戶的安全性群組。

  • 您可以在 Azure AD 中將來自租用戶中已驗證網域的任何群組 (不論是否具有電子郵件地址),用於 Azure Rights Management 服務的委派系統管理。

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

除了為您租用戶中的群組使用 Azure AD proxyAddresses 以外,Azure 資訊保護也會以相同的方式使用此屬性來授權來自其他租用戶的群組。

針對 Azure 資訊保護使用來自 Active Directory 內部部署的帳戶

如果您受控內部部署的帳戶想要與 Azure 資訊保護搭配使用,您必須將它們同步處理至 Azure AD。 為了方便部署,我們建議您使用 Azure AD Connect。 不過,您可以使用可達到相同結果的任何目錄同步處理方法。

當您同步處理您的帳戶時,您不需要同步處理所有屬性。 如需必須同步處理的屬性清單,請參閱 Azure Active Directory 文件的 Azure RMS一節。

您會從 Azure Rights Management 的屬性清單中,看到針對使用者需要 mailproxyAddressesuserPrincipalName 的內部部署 AD 屬性,以便進行同步處理。 mailproxyAddresses 的值會重步處理至 Azure AD proxyAddresses 屬性。 如需詳細資訊,請參閱 Azure AD 中 proxyAddresses 屬性的填入方式

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

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

例如,在 PowerShell 工作階段中針對 Azure Active Directory 使用 V1 PowerShell 模組,MSOnline,首先連線至服務並且提供您的全域管理員認證:

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
Jagannath Reddy jagannathreddy@contoso.com {}
Ankur Roy ankurroy@contoso.com {SMTP: ankur.roy@contoso.com , smtp: ankur.roy@onmicrosoft.contoso.com }

在此範例中:

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

  • Ankur Roy 的使用者帳戶可以使用 ankur.roy@contoso.comankur.roy@onmicrosoft.contoso.com 來授權,但是無法使用 ankurroy@contoso.com 授權。

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

  1. 如果 UPN 值中的網域名稱是 Azure AD 租用戶的已驗證網域,請在 Azure AD 新增 UPN 值作為另一個電子郵件地址,讓 UPN 值現在可以用來為 Azure 資訊保護授權使用者帳戶。

    如果 UPN 值中的網域名稱不是您租用戶的已驗證網域,它就無法用於 Azure 資訊保護。 不過,當群組電子郵件地址使用已驗證網域名稱時,使用者仍然可以授權為群組的成員。

  2. 如果 UPN 不是可路由 (例如,ankurroy@contoso.local),為使用者設定替代登入 ID,並且指示他們如何使用此替代登入來登入 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 命令來尋找可以用於識別這些群組的物件 ID 和顯示名稱。 您也可以使用 Azure 入口網站來尋找這些群組,並且複製物件 ID 和顯示名稱的值:

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

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

如果您變更使用者或群組的電子郵件地址,我們建議您將舊的電子郵件地址新增至使用者或群組,作為第二個電子郵件地址 (也稱為 Proxy 地址、別名或替代電子郵件地址)。 當您這樣做時,舊的電子郵件地址會新增至 Azure AD proxyAddresses 屬性。 此帳戶系統管理可確保任何使用權限,或使用舊電子郵件地址時儲存之其他設定的業務持續性。

如果無法這麼做,使用新電子郵件地址的使用者或群組就會有被拒絕存取先前以舊電子郵件地址保護之文件和電子郵件的風險。 在此情況下,您必須重複保護設定,以儲存新的電子郵件地址。 例如,如果使用者或群組被授與在範本或標籤中的使用權限,使用與您被授與舊電子郵件地址的相同使用權限,來編輯這些範本或標籤並指定新的電子郵件地址。

請注意,群組鮮少變更其電子郵件地址,而且如果您將使用權限指派給群組而不是個別使用者,那麼使用者電子郵件地址變更與否就無關緊要。 在此案例中,使用權限是指派給群組電子郵件地址而不是個別使用者電子郵件地址。 這是系統管理員設定保護文件和電子郵件之使用權限的最可行 (且最建議) 方法。 不過,使用者通常會為個別使用者指派自訂權限。 因為您不一定會知道使用者帳戶或群組是否已用來授與存取權,最安全的方式是一律將舊的電子郵件地址新增為第二個電子郵件地址。

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

基於效能原因,Azure 資訊保護會快取群組成員資格。 這表示當這些群組是由 Azure 資訊保護使用而且這段時間受限於變更時,在 Azure AD 中群組成員資格的任何變更可能需要最多三個小時才會生效。

當您使用群組來授與使用權限或設定 Azure Rights Management 服務,或是當您設定有範圍的原則時,請記得將這項延遲列入您所執行之任何變更或測試的因素。

後續步驟

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

  • 從 2018 年 2 月起:如果您包含 Azure Rights Management 或 Azure 資訊保護的訂用帳戶在當月期間或之後取得,服務就會為您自動啟用。

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

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