Azure Information Protection 向けのユーザーとグループの準備
Note
Microsoft Purview Information Protection をお探しですか? (以前の Microsoft Information Protection (MIP))
Azure Information Protection アドインは廃止され、Microsoft 365 アプリとサービスに組み込まれているラベルに置き換えられています。 詳細については、「他の Azure Information Protection コンポーネントのサポート状況」を参照してください。
新しい Microsoft Information Protection クライアント (アドインなし) は現在プレビュー段階であり、一般提供が予定されています。
組織に Azure Information Protection を展開する前に、組織のテナント用にMicrosoft Entra ID のユーザーとグループのアカウントが用意されていることを確認してください。
ユーザーとグループのアカウントは次のようなさまざまな方法で作成できます。
Microsoft 365 管理センターのユーザーとExchange Online 管理センターのグループを作成します。
Azure Portal でユーザーとグループを作成します。
Azure AD PowerShell と Exchange Online のコマンドレットを利用し、ユーザーとグループを作成します。
オンプレミスの Active Directory でユーザーとグループを作成し、それを Microsoft Entra ID に同期します。
別のディレクトリでユーザーとグループを作成し、それを Microsoft Entra IDに同期します。
この一覧の最初の 3 つの方法でユーザーとグループを作成すると、1つの例外を除いて、ユーザーとグループが Microsoft Entra ID で自動的に作成され、そのアカウントを Azure Information Protection は直接利用できます。 ただし、多くの企業ネットワークではオンプレミスのディレクトリを利用し、ユーザーとグループを作成し、管理しています。 Azure Information Protection はそのようなアカウントを直接利用できません。Microsoft Entra IDに同期させる必要があります。
前の段落で説明した例外は、Exchange Online 用に作成できる動的配布リストです。 静的配布リストとは異なり、これらのグループは Microsoft Entra ID に複製されないため、Azure Information Protection では使用できません。
Azure Information Protection でのユーザーとグループの利用方法
Azure Information Protection でユーザーとグループを使用するための 3 つのシナリオ:
ラベルを文書やメールに適用できるように Azure Information Protection ポリシーを構成するとき、ラベルをユーザーに割り当てる。 管理者だけがこれらのユーザーとグループを選択できます。
- 既定の Azure Information Protection ポリシーは、テナントの Microsoft Entra ID のすべてのユーザーに自動的に割り当てられます。 ただし、スコープ付きポリシーを利用し、指定のユーザーまたはグループに追加ラベルを割り当てることもできます。
使用権限とアクセス制御を割り当て、Azure Rights Management サービスを構成する場合。 管理者とユーザーはこれらのユーザーとグループを選択できます。
使用権限では、ユーザーが文書やメールを開くことができるかが決められ、その利用方法が決められます。 たとえば、読み取り専用か、読み取りと印刷か、読み取りと編集などです。
アクセス制御には、有効期限日に加え、アクセスのためにインターネット接続が必要かどうかが含まれます。
特定のシナリオをサポートするように Azure Rights Management サービスを構成する。そのため、管理者のみがこれらのグループを選択できます。 たとえば、次を構成します。
スーパー ユーザー。電子情報開示やデータ復旧に必要であれば、指名されたサービスまたはユーザーが暗号化されているコンテンツを開くことができます。
Azure Rights Management サービスの委任管理。
段階的デプロイをサポートするオンボード コントロール。
Azure Information Protection の要件
ラベルを割り当てる:
- Microsoft Entra ID のすべてのユーザー アカウントを使用して、追加ラベルをユーザーに割り当てるスコープ付きポリシーを構成できます。
使用権限とアクセス制御を割り当て、Azure Rights Management サービスを構成する:
ユーザーに権限を与えるには、Microsoft Entra ID では、proxyAddresses と userPrincipalName という 2 つの属性が利用されます。
Microsoft Entra proxyAddresses 属性は、あるアカウントのすべてのメール アドレスを保存し、さまざまな方法で反映できます。 たとえば、Exchange Online メールボックスを持つ Microsoft 365 内のユーザーにば、この属性に格納されている電子メール アドレスが自動的に指定されます。 代替電子メール アドレスを Microsoft 365 ユーザーに割り当てると、それもこの属性に保存されます。 オンプレミス アカウントから同期しているメール アドレスでも反映できます。
Azure Information Protection は、ドメインがテナントに追加されていれば ("検証済みドメイン")、このMicrosoft Entra proxyAddresses 属性のあらゆる値を使用できます。 ドメイン検証の詳細については、次をご覧ください。
Microsoft Entra ID の場合: カスタム ドメイン 名を Microsoft Entra ID に追加します
Office 365 の場合: Office 365 にドメインを追加する
Microsoft Entra userPrincipalName 属性は、テナントのアカウントにMicrosoft Entra proxyAddresses 属性に値がないときにのみ利用されます。 たとえば、Azure Portal でユーザーを作成するか、メールボックスを持たない Microsoft 365 のユーザーを作成する場合です。
使用権限とアクセス制御を外部ユーザーに割り当てる
自分のテナントのユーザーに Microsoft Entra proxyAddresses とMicrosoft Entra userPrincipalName を使用するだけでなく、Azure Information Protection ではまた、同じようにこれらの属性を利用し、別のテナントからのユーザーに権限を与えます。
他の許可方法:
Microsoft Entra ID に含まれていない電子メール アドレスの場合、Azure Information Protection はMicrosoft アカウントで認証されたときにこれらを承認できます。 ただし、Microsoft アカウントが認証に使用されている場合、すべてのアプリケーションは保護されたコンテンツを開けるわけではありません。 詳細情報
Microsoft Entra IDにアカウントを持たないユーザーに新しい機能を備えた Office 365 Message Encryption を利用してメールを送信すると、ユーザーは最初にフェデレーションとのソーシャル ID プロバイダーを利用するか、ワンタイム パスコードを利用して認証されます。 その後、保護されたメールに指定されているメール アドレスを利用し、ユーザーに権限を与えます。
グループ アカウントの Azure Information Protection 要件
ラベルを割り当てる:
追加ラベルをグループ メンバーに割り当てるスコープ付きポリシーを構成するには、ユーザーのテナントにドメインが検証されているメール アドレスが与えられたあらゆる種類のMicrosoft Entra ID グループを利用できます。 メール アドレスが与えられているグループはしばしば、メールが有効なグループと呼ばれています。
たとえば、メールが有効なセキュリティ グループ、静的な配布グループ、および Microsoft 365 グループを使用できます。 セキュリティ グループ (動的または静的) は利用できません。この種類のグループにはメール アドレスが与えられていないためです。 このグループは Micros1oft Entra ID に複製されないため、Exchange Online からの動的配布リストを使用することもできません。
使用権限とアクセス制御を割り当てる:
- ユーザーのテナントにドメインが検証されているメール アドレスが与えられたあらゆる種類の Microsoft Entra ID グループを利用できます。 メール アドレスが与えられているグループはしばしば、メールが有効なグループと呼ばれています。
Azure Rights Management サービスを構成する:
テナントでドメインが検証されているメール アドレスが与えられたあらゆる種類の Microsoft Entra ID グループを利用できるが、例外が 1 つあります。 その例外は、グループを利用するためにオンボード コントロールを構成する場合に、そのグループは自分のテナントのMicrosoft Entra ID のセキュリティ グループにする必要があります。
Azure Rights Management サービスの委任管理には、テナントでドメインが検証されているあらゆる Microsoft Entra IDの グループを利用できます (メール アドレスの有無は関係ありません)。
使用権限とアクセス制御を外部グループに割り当てる
自分のテナントのグループにMicrosoft Entra proxyAddresses を使用するだけでなく、Azure Information Protection ではまた、同じようにこれらの属性を利用して別のテナントからのグループに権限を与えます。
Azure Information Protection にオンプレミス Active Directory アカウントを利用する
オンプレミスで管理しているアカウントに Azure Information Protection で使用したいアカウントがあれば、それを Microsoft Entra IDに同期する必要があります。 デプロイを簡単にするには、Microsoft Entra Connect の利用をお勧めします。 ただし、同じ結果が得られるあらゆるディレクトリ同期方法を利用できます。
アカウントを同期するとき、すべての属性を同期する必要はありません。 同期が必要な属性の一覧については、Microsoft Entra ドキュメントからの Azure RMS セクションをご覧ください。
Azure Rights Management の属性一覧から、ユーザーの場合、mail、proxyAddresses、userPrincipalName のオンプレミス AD 属性が同期に必要になることがわかります。 mail と proxyAddresses の値がMicrosoft Entra proxyAddresses 属性に同期します。 詳細については、「Microsoft Entra ID に proxyAddresses 属性を反映する方法」を参照してください。
Azure Information Protection のためにユーザーとグループが用意されていることを確認する
Azure AD PowerShell を利用し、ユーザーとグループを Azure Information Protection で利用できることを確認できます。 また、PowerShell を利用し、承認に利用できる値を確認できます。
Note
Azure AD および MSOnline PowerShell モジュールは、2024 年 3 月 30 日の時点で非推奨となります。 詳細については、非推奨の最新情報を参照してください。 この日以降、これらのモジュールのサポートは、Microsoft Graph PowerShell SDK への移行支援とセキュリティ修正プログラムに限定されます。 非推奨になるモジュールは、2025 年 3 月 30 日まで引き続き機能します。
Microsoft Entra ID (旧称 Azure AD) を使用するには、Microsoft Graph PowerShell に移行することをお勧めします。 移行に関する一般的な質問については、「移行に関する FAQ」を参照してください。 注: バージョン 1.0.x の MSOnline では、2024 年 6 月 30 日以降に中断が発生する可能性があります。
たとえば、PowerShell セッションで Microsoft Entra IDの向け V1 PowerShell モジュール、MSOnline を利用し、最初にサービスに接続し、全体管理者の資格情報を提供します。
Connect-MsolService
注: このコマンドでうまくいかない場合、Install-Module MSOnline を実行して MSOnline モジュールをインストールできます。
次に、値が切り詰められないように PowerShell セッションを設定します。
$Formatenumerationlimit =-1
ユーザー アカウントが Azure Information Protection で使えることを確認する
ユーザー アカウントを確認するには、次のコマンドを実行します。
Get-Msoluser | select DisplayName, UserPrincipalName, ProxyAddresses
最初に、Azure Information Protection で使用するユーザーが表示されていることを確認します。
次に、ProxyAddresses 列にデータが入力されているかどうかを確認します。 入力されている場合、Azure Information Protection でこの列のメール値を利用し、ユーザーに権限を付与できます。
ProxyAddresses 列にデータが入力されていない場合、UserPrincipalName is の値を利用してユーザーに 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.com と ankur.roy@onmicrosoft.contoso.com で承認されます。ankurroy@contoso.com は利用されません。
ほとんどの場合、UserPrincipalName の値が ProxyAddresses フィールドの値の 1 つと一致します。 これは推奨構成ですが、メール アドレスに合わせて UPN を変更できない場合、次の手順を行う必要があります。
UPN 値のドメイン名が自分のMicrosoft Entra テナントに検証済みのドメインであれば、Microsoft Entra ID の別のメール アドレスとして UPN 値を追加します。それにより、UPN 値を利用してAzure Information Protection にユーザー アカウントに権限を与えられる。
UPN 値のドメイン名が自分のテナントで検証されているドメインではない場合、Azure Information Protection で使用できません。 ただし、グループのメール アドレスで検証済みのドメイン名が使用されていれば、ユーザーにグループのメンバーとして承認できます。
UPN がルーティング可能ではない場合 (ankurroy@contoso.local など)、ユーザーの代替ログイン ID を設定し、その代替ログインで Office にサインインする方法を指示してください。 Office のレジストリ キーを設定する必要もあります。
ユーザーの UPN を変更すると、24 時間以上、または UPN の変更がシステムに適切に反映されるまでは、ビジネス継続性が失われます。
詳細については、「代替ログイン ID を構成する」および「SharePoint、OneDrive、Lync Online の資格情報の Office アプリケーションによる定期的な請求」を参照してください。
ヒント
Export-Csv コマンドレットを利用し、結果をスプレッドシートにエクスポートできます。検索やインポートのための一括編集などで管理が簡単になります。
例: Get-MsolGroup | select DisplayName, ProxyAddresses | Export-Csv -Path UserAccounts.csv
Note
ユーザーの UPN を変更すると、24 時間以上、または UPN の変更がシステムに適切に反映されるまでは、ビジネス継続性が失われます。
グループ アカウントが Azure Information Protection で使えることを確認する
グループ アカウントを確認するには、次のコマンドを使用します。
Get-MsolGroup | select DisplayName, ProxyAddresses
Azure Information Protection で使用するグループが表示されていることを確認します。 表示されているグループについては、ProxyAddresses 列のメール アドレスを利用し、Azure Rights Management サービスのためにグループ メンバーに承認できます。
次に、Azure Information Protection で使用するユーザー (または、その他のグループ) がグループに含まれていることを確認します。 PowerShell を利用してこれを実行できます (Get-MsolGroupMember など)。あるいは、管理ポータルを利用できます。
セキュリティ グループを利用する 2 つの Azure Rights Management サービス構成シナリオについては、次の PowerShell コマンドを利用し、それらのグループの識別に利用できるオブジェクト ID と表示名を見つけることができます。 Azure Portal を利用してこれらのグループを見つけ、オブジェクト ID と表示名の値をコピーすることもできます。
Get-MsolGroup | where {$_.GroupType -eq "Security"}
メール アドレスが変更された場合の Azure Information Protection の考慮事項
ユーザーまたはグループのメール アドレスを変更する場合、使用していないメール アドレスを第 2 メール アドレス (プロキシ アドレス、エイリアス、代替メール アドレスと呼ばれることもあります) としてユーザーまたはグループに追加することをお勧めします。 この作業を行う場合、古いメール アドレスは Microsoft Entra proxyAddresses 属性に追加されます。 このようにアカウントを管理することで、使用していないメール アドレスが使われていたときに保存された使用権限やその他の構成もビジネスで引き続き利用できます。
使用していないメール アドレスを第 2 メール アドレスにしない場合、新しいメール アドレスが与えられたユーザーまたはグループは、使用していないメール アドレスで以前に保護した文書やメールに対するアクセスを拒否されることがあります。 その場合、保護設定を改めて行い、新しいメール アドレスを保存する必要があります。 たとえば、ユーザーまたはグループにテンプレートまたはラベルの使用権限が与えられた場合、そのテンプレートまたはラベルを編集し、使用していないメール アドレスに与えたものと同じ使用権限を付けて新しいメール アドレスを指定します。
グループの場合、そのメール アドレスを変更することはまれです。個々のユーザーではなく、グループに使用権限を割り当てた場合、ユーザーのメール アドレスを変更しても特別な対処は必要ありません。 このシナリオでは、使用権限が個々のユーザーのメール アドレスではなく、グループのメール アドレスに割り当てられます。 これは、文書やメールを保護する使用権限を管理者が設定するとき、最も頻繁に採用される (そして推奨される) 手法です。 ただし、ユーザーが個々のユーザーに独自のアクセス許可を割り当てることの方がより一般的です。 あるユーザー アカウントまたはグループがアクセス付与に使われているかどうかは常に確認できるわけではないため、使用していないメール アドレスを第 2 メール アドレスとして常に追加しておくと安心です。
Azure Information Protection のグループ メンバーシップ キャッシュ
パフォーマンス上の理由から、Azure Information Protection はグループ メンバーシップをキャッシュします。 つまり、Microsoft Entra ID でグループ メンバーシップへの変更は、そのグループを Azure Information Protection で使用した場合に有効になるまでに最大 3 時間かかることがあり、この期間は変更される可能性があります。
使用権限を与えたり、Azure Rights Management サービスを構成したりするためにグループを使用するときに、あるいはスコープ付きポリシーを構成するときに変更やテストを行う場合、この遅延を必ず考慮してください。
次のステップ
ユーザーやグループを Azure Information Protection で使用できることを確認し、ドキュメントやメールの保護を始める用意ができたら、 Azure Rights Management サービスをアクティブ化する必要があるかどうかを確認します。 このサービスは、組織のドキュメントと電子メールを保護する前にアクティブ化する必要があります:
2018 年 2 月以降: Azure Rights Management または Azure Information Protection を含むサブスクリプションが今月中またはそれ以降に取得された場合、サービスは自動的にアクティブ化されます。
サブスクリプションが 2018 年 2 月以前に取得された場合: サービスを自分でアクティブ化する必要があります。
アクティブ化の状態の確認を含む詳細については、「Azure Information Protection からの保護サービスのアクティブ化」を参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示