情報バリアの使用を開始する

  • [アーティクル]

この記事では、組織の情報バリア (IB) ポリシーを構成する方法について説明します。 いくつかの手順が含まれているため、IB ポリシーの構成を開始する前に、プロセス全体を確認してください。

組織では、 Microsoft Purview ポータル、 Microsoft Purview コンプライアンス ポータル、または Office 365 セキュリティとコンプライアンス PowerShell を使用して IB を構成します。 初めて IB を構成する組織の場合は、コンプライアンス ポータルで情報バリア ソリューションを使用することをお勧めします。 既存の IB 構成を管理していて、PowerShell の使用に慣れている場合は、このオプションを引き続き使用できます。

IB のシナリオと機能の詳細については、「情報バリアについての詳細情報」を参照してください。

ヒント

計画の準備に役立つように、この記事には「シナリオ例」が含まれています。

ヒント

E5 のお客様でない場合は、90 日間の Microsoft Purview ソリューション試用版を使用して、Purview の追加機能が組織のデータ セキュリティとコンプライアンスのニーズの管理にどのように役立つかを確認してください。 Microsoft Purview コンプライアンス ポータルのトライアル ハブで今すぐ開始してください。 サインアップと試用期間の詳細については、こちらをご覧ください。

必要なサブスクリプションとアクセス許可

IB の使用を開始する前に、Microsoft 365 サブスクリプションおよびアドオンを確認する必要があります。 IB にアクセスして使用するには、組織にサポート サブスクリプションまたはアドオンが必要です。 詳細については、情報バリアの サブスクリプション要件 に関するページを参照してください。

IB ポリシーを管理する場合は、次のいずれかのロールが割り当てられている必要があります。

  • Microsoft 365 グローバル管理者
  • Office 365 グローバル管理者
  • コンプライアンス管理者
  • IB コンプライアンス管理

重要

Microsoft では、アクセス許可が最も少ないロールを使用することをお勧めします。 グローバル管理者ロールを持つユーザーの数を最小限に抑えることで、組織のセキュリティを向上させることができます。 Microsoft Purview のロールとアクセス許可の詳細については、こちらをご覧ください。

構成の概念

IB を構成するときは、複数のオブジェクトと概念を操作します。

  • ユーザー アカウント属性 は、Microsoft Entra ID (または Exchange Online) で定義されます。 これらの属性には、部署、役職、場所、チーム名、およびその他のジョブ プロファイルの詳細を含めることができます。 こうした属性によってユーザーまたはグループをセグメントに割り当てます。

  • セグメント は、Microsoft Purview ポータル、コンプライアンス ポータル、または選択したグループまたはユーザー アカウント属性を使用する PowerShell を使用して定義されたグループまたはユーザーのセットです。

    組織は最大 5,000 個のセグメントを保持できます。また、ユーザーは最大 10 個のセグメントに割り当てることができます。 詳細については、IB でサポートされる属性の一覧を参照してください。

    重要

    5,000 個のセグメントのサポートと複数のセグメントへのユーザーの割り当ては、組織が Legacy モードでない場合にのみ使用できます。 ユーザーを複数のセグメントに割り当てるには、組織の情報バリア モードを変更するための追加操作が必要です。 詳細については、「情報バリアで複数セグメントのサポートを使用する」を参照してください。

    Legacy モードの組織の場合、サポートされるセグメントの最大数は 250 個であり、ユーザーは 1 つのセグメントにのみ割り当てられるように制限されます。 Legacy モードの組織は、将来、情報バリアの最新バージョンにアップグレードする資格があります。 詳細については、情報バリアのロードマップを参照してください。

  • IB ポリシーでは、通信の限度または制限を決定します。 IB ポリシーを定義する際は、次の 2 種類のポリシーから選択します:

    • 禁止ポリシーは、あるセグメントと別のセグメントとの通信を禁止します。

    • 許可ポリシーは、あるセグメントが他の特定のセグメントとのみ通信することを許可します。

      注:

      Legacy モードの組織の場合: IB セグメントと許可ポリシーのポリシーに含まれるユーザーには、IB 以外のグループとユーザーが表示されなくなります。 IB 以外のグループとユーザーを IB セグメントとポリシーに含まれたユーザーに表示する必要がある場合は、ブロック ポリシーを使用する必要があります。

      SingleSegment または MultiSegment モードの組織の場合: IB 以外のグループとユーザーが、IB セグメントとポリシーに含まれたユーザーに表示されます。

      IB モードを確認するには、「組織の IB モードを確認する」を参照してください。

  • ポリシーの適用は、すべての IB ポリシーの定義後に実行され、そのポリシーはすぐに組織に適用できるようになります。

  • IB 以外のユーザーとグループの可視性: IB 以外のユーザーとグループは、IB セグメントとポリシーから除外されたユーザーとグループです。 組織の IB ポリシーを構成する時期と IB ポリシーの種類 (ブロックまたは許可) に応じて、これに該当するユーザーとグループの動作は、Microsoft Teams、SharePoint、OneDrive、およびグローバル アドレス一覧で異なるようになります。

    • Legacy モードの組織の場合: 許可ポリシーで定義されているユーザーの場合、IB 以外のグループとユーザーは、IB セグメントとポリシーに含まれるユーザーには表示されません。 ブロック ポリシーで定義されているユーザーの場合、IB 以外のグループとユーザーは、IB セグメントとポリシーに含まれるユーザーに表示されます。
    • SingleSegment または MultiSegment モードの組織の場合: IB 以外のグループとユーザーが、IB セグメントとポリシーに含まれたユーザーに表示されます。

  • グループのサポート。 現在、IB では最新のグループのみがサポートされていて、配布リスト/セキュリティ グループは IB 以外のグループとして扱われます。

  • 非表示/無効のユーザーおよびゲストのアカウント。 組織内で非表示/無効のユーザー アカウントとゲスト アカウントの場合、ユーザー アカウントが非表示または無効にされたとき、またはゲストが作成されたときに、HiddenFromAddressListEnabled パラメーターが自動的に True に設定されます。 IB 対応組織では組織のモードが Legacy の場合に、こうしたアカウントは他のすべてのユーザー アカウントと通信できなくなります。 管理者は、HiddenFromAddressListEnabled パラメーターを手動で False に設定することで、この既定の動作を無効にすることができます。

構成の概要

手順 内容
手順 1: 前提条件が満たされていることを確認する - 必要なサブスクリプションとアクセス許可があることを確認する
- ディレクトリにユーザーをセグメント化するためのデータが含まれていることを確認する
- Microsoft Teams の名前による検索を有効にする
- 監査ログの記録をオンにしてあることを確認する
- 組織の IB モードを確認する
- Exchange アドレス帳ポリシーの実装方法を構成する (組織で IB を有効にした時期によって異なります)
- Microsoft Teams の管理者の同意を提供する (手順が含まれる)
手順 2: 組織内のユーザーをセグメント化する - 必要なポリシーを決定する
- 定義するセグメントのリストを作成する
- 使用する属性を特定する
- ポリシー フィルターの観点からセグメントを定義する
手順 3: 情報バリアのポリシーを作成する - ポリシーを作成する (まだ適用しない)
- 2 つの種類から選択します (ブロックまたは許可)
手順 4: 情報バリアのポリシーを適用する - ポリシーをアクティブな状態に設定する
- ポリシー アプリケーションを実行する
- ポリシーの状態を表示する
手順 5: SharePoint と OneDrive の情報バリアを構成する (省略可能) - SharePoint と OneDrive 用に IB を構成する
手順 6: 情報バリアのモード (省略可能) - 該当する場合は IB のモードを更新する
手順 7: 情報バリアのユーザー検出可能性を構成する (省略可能) - 該当する場合は、[ユーザー ピッカー] を使用して IB でのユーザーの検出可能性を有効または制限します。

手順 1: 前提条件が満たされていることを確認する

IB を構成する前に、必要なサブスクリプションとアクセス許可に加えて、次の要件が満たされていることを確認してください:

  • ディレクトリ データ: 組織の構造がディレクトリ データに反映されていることを確認してください。 このアクションを実行するには、ユーザー アカウント属性 (グループ メンバーシップ、部署名など) が Microsoft Entra ID (または Exchange Online) に正しく設定されていることを確認します。 詳細については、次のリソースを参照してください。

  • スコープ付きディレクトリ検索: 組織の最初の IB ポリシーを定義する前に、Microsoft Teams のスコープ付きディレクトリ検索を有効にする必要があります。 IB ポリシーを設定または定義する前に、スコープ付きディレクトリ検索を有効にして、少なくとも 24 時間待ちます。

  • 監査ログが有効になっていることを確認する: IB ポリシー適用の状態を検索するには、監査ログを有効にする必要があります。 Microsoft 365 の組織では、監査が既定で有効になっています。 組織によっては、特定の理由で監査を無効にしている場合があります。 組織の監査が無効になっている場合は、別の管理者が無効にしている可能性があります。 この手順を完了する場合は、監査を再びオンにしても問題ないか確認することをお勧めします。 詳細については、「監査ログの検索を有効または無効にする」をご覧ください。

  • 組織の IB モードを確認する: 複数セグメントのサポート、ユーザー検出可能性のオプション、Exchange ABP などの機能は、組織の IB モードによって決定されます。 組織の IB モードを確認するには、「組織の IB モードを確認する」を参照してください。

  • 既存の Exchange Online アドレス帳ポリシーを削除する (省略可能):

    • Legacy モードの組織の場合: IB ポリシーを定義して適用する前に、組織内の既存の Exchange Online アドレス帳ポリシーをすべて削除する必要があります。 IB ポリシーはアドレス帳ポリシーに基づいていて、既存の ABP ポリシーは IB によって作成された ABP との互換性がありません。 既存のアドレス帳ポリシーを削除するには、「Exchange Online でアドレス帳ポリシーを削除する」を参照してください。 IB ポリシーと Exchange Online の詳細については、「情報バリアと Exchange Online」を参照してください。
    • SingleSegment または MultiSegment モードの組織の場合: 情報バリアは、Exchange Online アドレス帳ポリシー (ABP) に基づかなくなっています。 ABP を使用している組織は、情報バリアを有効にするときに既存の ABP には影響がありません。

  • PowerShell を使用して管理する (省略可能): IB セグメントとポリシーはコンプライアンス ポータルで定義および管理できますが、必要に応じて Office 365 セキュリティ & コンプライアンス PowerShell を使用することもできます。 この記事ではいくつかの例を示しますが、IB セグメントとポリシーの構成と管理に PowerShell を使用する場合は、PowerShell コマンドレットとパラメーターについて理解している必要があります。 この構成オプションを選択した場合は、Microsoft Graph PowerShell SDK も必要になります。

すべての前提条件が満たされたら、次の手順に進みます。

手順 2: 組織内のユーザーをセグメント化する

この手順では、必要になる IB ポリシーを決定し、定義するセグメントの一覧を作成して、セグメントを定義します。 セグメントの定義はユーザーに影響しません。定義して適用する IB ポリシーのステージを設定するだけです。

必要なポリシーを決定する

組織のニーズを考慮して、IB ポリシーが必要になる組織内のグループを決定します。 次の点について理解しているかどうかを確認します。

  • 組織内のグループとユーザーの間で通信とコラボレーションを制限する必要がある内部、法律、または業界の規制がありますか?
  • 別のユーザー グループとの通信を防止する必要があるグループまたはユーザーがありますか?
  • 1 つまたは 2 つの別のユーザー グループとの通信のみを許可する必要があるグループまたはユーザーがありますか?

必要なポリシーは、次の 2 種類のいずれかに属すると考えてください:

  • ブロック ポリシーは、あるグループと別のグループの通信を禁止します。
  • 許可ポリシーは、あるグループが特定のグループのみと通信することを許可します。

必要なグループとポリシーの初期リストがある場合は、IB ポリシーに必要なセグメントの特定に進みます。

セグメントを特定する

ポリシーの初期のリストに加えて、組織に応じたセグメントのリストを作成します。 IB ポリシーに含めるユーザーは、少なくとも 1 つのセグメントに属している必要があります。 ユーザーは、必要に応じて複数のセグメントに割り当てることができます。 組織には最大 5,000 個のセグメントを保持できます。また、それぞれのセグメントに適用できる IB ポリシーは 1 つだけです。

重要

ユーザーは、Legacy モードまたは SingleSegement モードの組織の場合は 1 つのセグメントにのみ存在できます。 IB モードを確認するには、「組織の IB モードを確認する」を参照してください。

セグメントの定義に使用する組織のディレクトリ データ内の属性を決定します。 Department や MemberOf などのサポートされている IB 属性のいずれかを使用できます。 ユーザーに選択する属性には値があることを確認します。 詳細については、IB でサポートされている属性を参照してください。

重要

次のセクションに進む前に、ディレクトリ データに、セグメントの定義に使用できる属性の値があることを確認してください。 ディレクトリ データに使用する属性に値がない場合は、IB の構成を進める前に、その情報が含まれるようにユーザー アカウントを更新する必要があります。 これについてのヘルプは、次の記事を参照してください:

- Office 365 PowerShell でユーザー アカウント プロパティを構成する
- Microsoft Entra ID を使用してユーザーのプロファイル情報を追加または更新する

ユーザーに対する複数セグメントのサポートを有効にする (省略可能)

ユーザーを複数のセグメントに割り当てるサポートは、組織が Legacy モードでない場合にのみ利用できます。 複数セグメントへのユーザーの割り当てをサポートする場合は、「情報バリアで複数セグメントのサポートを使用する」を参照してください。

Legacy モードの組織では、ユーザーは 1 つのセグメントにのみ割り当てられるように制限されています。 レガシー モードの組織は、将来、情報バリアの最新バージョンにアップグレードする資格があります。 詳細については、情報バリアのロードマップを参照してください。

ポータルを使用してセグメントを定義する

現在使用しているポータルに該当するタブを選択してください。 Microsoft Purview ポータルの詳細については、Microsoft Purview ポータルを参照してください。 コンプライアンス ポータルの詳細については、「Microsoft Purview コンプライアンス ポータル」を参照してください。

セグメントを定義するには、次の手順を実行します:

  1. 組織の管理者アカウントの資格情報を使用して、Microsoft Purview ポータルにサインインします。
  2. [情報バリア] ソリューション カードを選択します。 [情報バリア] ソリューション カードが表示されていない場合は、[すべてのソリューションを表示] を選択し、[リスクとコンプライアンス] セクションから [情報バリア] を選択します。
  3. [ セグメント] を選択します。
  4. [セグメント] ページで [新しいセグメント] を選択し、新しいセグメントを作成して構成します。
  5. [名前] ページで、セグメントの名前を入力します。 セグメント名は、セグメントの作成後には変更はできません。
  6. [次へ] を選択します。
  7. [ユーザー グループ フィルター] ページで、[追加] を選択して、このセグメント用のグループとユーザーの属性を構成します。 使用可能な属性の一覧からセグメント用の属性を選択します。
  8. 選択した属性に対して、[等しい] または [等しくない] のどちらかを選択し、属性の値を入力します。 たとえば、属性として [部署] を選択し、[等しい] を選択した場合は、このセグメント条件に定義した [部署] として「マーケティング」と入力できます。 属性に別の条件を追加するには、[条件の追加] を選択します。 属性または属性条件の削除が必要な場合は、その属性または条件の削除アイコンを選択します。
  9. [ユーザー グループ フィルター] ページで必要に応じて属性を追加し、[次へ] を選択します。
  10. [設定の確認] ページで、セグメントに選択した設定と、選択内容に対する提案または警告を確認します。 [編集] を選択して、セグメントの属性と条件を変更します。または、[送信] を選択してセグメントを作成します。

PowerShell を使用してセグメントを定義する

PowerShell でセグメントを定義するには、次の手順を実行します:

  1. New-OrganizationSegment コマンドレットを UserGroupFilter パラメーターと共に使用します。このパラメーターは使用する属性に対応します。

    構文 例
    New-OrganizationSegment -Name "segmentname" -UserGroupFilter "attribute -eq 'attributevalue'" New-OrganizationSegment -Name "HR" -UserGroupFilter "Department -eq 'HR'"

    この例では、HR というセグメントを定義するために、Department 属性の値である HR を使用しています。 このコマンドレットの -eq の部分は、"等しい" を表しています (または、-ne を使用して "等しくない" を表すこともできます。セグメント定義での "等しい" と "等しくない" の使用方法を参照してください)。

    各コマンドレットの実行後には、新しいセグメントに関する詳細の一覧が表示されます。 詳細には、セグメントの種類、セグメントを作成または最終変更したユーザーなどが含まれます。

  2. 定義するセグメントごとに、このプロセスを繰り返します。

セグメントを定義したら、「手順 3: IB ポリシーを作成する」に進みます。

PowerShell セグメント定義で "等しい" と "等しくない" を使用する

次の例では、PowerShell を使用して IB セグメントを構成し、"Department が HR と等しい" セグメントを定義しています。

例 注:
New-OrganizationSegment -Name "HR" -UserGroupFilter "Department -eq 'HR'" この例では、セグメント定義に -eq として示される "等しい" パラメーターが含まれていることに注意してください。

次の表に示すように、-ne として示される "等しくない" パラメーターを使用してセグメントを定義することもできます。

構文 例
New-OrganizationSegment -Name "NotSales" -UserGroupFilter "Department -ne 'Sales'" この例では、Sales に存在していないすべてのユーザーを含める NotSales というセグメントを定義しました。 コマンドレットの -ne の部分は、"等しくない" を表します。

"等しい" または "等しくない" を使用してセグメントを定義するだけでなく、"等しい" パラメーターと "等しくない" パラメーターの両方を使用してセグメントを定義することもできます。 論理演算子の AND と OR を使用して、複雑なグループ フィルターを定義することもできます。

構文 例
New-OrganizationSegment -Name "LocalFTE" -UserGroupFilter "Location -eq 'Local'" -and "Position -ne 'Temporary'" この例では、LocalFTE というセグメントを定義しました。このセグメントには、ローカルに配置されていて、その位置が Temporary としてリストされないユーザーが含まれます。
New-OrganizationSegment -Name "Segment1" -UserGroupFilter "MemberOf -eq 'group1@contoso.com'' -and MemberOf -ne 'group3@contoso.com'" この例では、group1@contoso.com のメンバーであり、group3@contoso.com のメンバーでないユーザーが含まれる Segment1 というセグメントを定義しました。
New-OrganizationSegment -Name "Segment2" -UserGroupFilter "MemberOf -eq 'group2@contoso.com' -or MemberOf -ne 'group3@contoso.com'" この例では、group2@contoso.com のメンバーであり、group3@contoso.com のメンバーでないユーザーが含まれる Segment2 というセグメントを定義しました。
New-OrganizationSegment -Name "Segment1and2" -UserGroupFilter "(MemberOf -eq 'group1@contoso.com' -or MemberOf -eq 'group2@contoso.com') -and MemberOf -ne 'group3@contoso.com'" この例では、group3@contoso.com のメンバーではない group1@contoso.com と group2@contoso.com のユーザーが含まれる Segment1and2 というセグメントを定義しました。

ヒント

可能であれば、"-eq" または "-ne" が含まれたセグメント定義を使用します。 複雑なセグメント定義を定義しようとしないでください。

手順 3: IB ポリシーを作成する

情報バリア ポリシーを作成するときには、特定のセグメント間の通信を防止する必要があるか、または特定のセグメントへの通信を制限する必要があるかを判断します。 理想としては、最小限の IB ポリシーを使用して、組織が内部、法的、および業界の要件に準拠するようにします。 Microsoft Purview ポータル、コンプライアンス ポータル、または PowerShell を使用して、IB ポリシーを作成して適用できます。

ヒント

ユーザー エクスペリエンスの一貫性を確保するために、可能であれば、ほとんどのシナリオにブロック ポリシーを使用することをお勧めします。

定義するユーザー セグメントと IB ポリシーの一覧を使用して、シナリオを選択し、手順を実行します。

重要

ポリシーを定義するときには、1 つのセグメントに複数のポリシーを割り当てないようにしてください。 たとえば、Sales というセグメントに対して 1 つのポリシーを定義する場合は、その Sales セグメントには追加のポリシーを定義しないでください。

さらに、IB ポリシーを定義するときには、それらのポリシーを適用する準備ができるまで、それらを非アクティブ状態に設定しておいてください。 ポリシーの定義 (または編集) は、これらのポリシーがアクティブな状態に設定された後に適用されるまで、ユーザーには影響しません。

シナリオ 1: セグメント間の通信をブロックする

セグメント間の通信をブロックするには、それぞれの方向に 1 つずつ 2 つのポリシーが必要です。 各ポリシーでは、一方向の通信のみをブロックします。

たとえば、セグメント A とセグメント B の間の通信をブロックするとします。この場合は、次の 2 つのポリシーを定義します。

  • セグメント A がセグメント B と通信できないようにする 1 つのポリシー
  • セグメント B がセグメント A と通信できないようにする 2 つ目のポリシー

シナリオ 1 のポータルを使用してポリシーを作成する

現在使用しているポータルに該当するタブを選択してください。 Microsoft Purview ポータルの詳細については、Microsoft Purview ポータルを参照してください。 コンプライアンス ポータルの詳細については、「Microsoft Purview コンプライアンス ポータル」を参照してください。

次の手順を使用して、ポリシーの作成を実行します:

  1. 組織の管理者アカウントの資格情報を使用して、Microsoft Purview ポータルにサインインします。

  2. [情報バリア] ソリューション カードを選択します。 [情報バリア] ソリューション カードが表示されていない場合は、[すべてのソリューションを表示] を選択し、[リスクとコンプライアンス] セクションから [情報バリア] を選択します。

  3. [ポリシー] を選択します。

  4. [ポリシー] ページで [ポリシーの作成] を選択し、新しい IB ポリシーを作成して構成します。

  5. [名前] ページで、ポリシーの名前を入力して、[次へ] を選択します。

  6. [割り当て済みセグメント] ページで、[セグメントを選択する] を選択します。 検索ボックスを使用して名前でセグメントを検索するか、スクロールすると表示される一覧からセグメントを選択します。 [追加] を選択して、選択したセグメントをポリシーに追加します。 選択できるセグメントは 1 つだけです。

  7. [次へ] を選択します。

  8. [コミュニケーションとコラボレーション] ページにある [コミュニケーションとコラボレーション] フィールドでポリシーの種類を選択します。 ポリシーのオプションは、[許可] または [ブロック] のどちらかです。 この例のシナリオでは、最初のポリシーに [ブロック] を選択します。

    重要

    ポリシーの作成後には、セグメントの許可とブロックの状態を変更することはできません。 ポリシーの作成後に状態を変更するには、ポリシーを削除してから新しいポリシーを作成する必要があります。

  9. [セグメントを選択する] を選択して、ターゲット セグメントのアクションを定義します。 この手順では、複数セグメントの割り当てができます。 たとえば、Sales というセグメントのユーザーが Research というセグメントのユーザーと通信できないようにブロックする場合は、手順 5 で Sales セグメントを定義して、この手順の [セグメントを選択する] オプションで Research を割り当てます。

  10. [次へ] を選択します。

  11. [ポリシーの状態] ページで、アクティブなポリシーの状態を [オン] に切り替えます。 [次へ] を選んで続行します。

  12. [設定の確認] ページで、ポリシーに選択した設定と、選択内容に対する提案または警告を確認します。 [編集] を選択してポリシーのセグメントと状態を変更するか、[送信] を選択してポリシーを作成します。

この例では、前の手順を繰り返して 2 つ目のブロック ポリシーを作成し、Research というセグメント内のユーザーが Sales というセグメント内のユーザーと通信できないように制限します。 手順 5 で Research セグメントを定義し、[セグメントを選択する] オプションで Sales (または複数のセグメント) を割り当てます。

PowerShell を使用してシナリオ 1 のポリシーを作成する

PowerShell でポリシーを定義するには、次の手順を実行します:

  1. 最初のブロック ポリシーを定義するには、New-InformationBarrierPolicy コマンドレットを SegmentsBlocked パラメーターと共に使用します。

    構文 例
    New-InformationBarrierPolicy -Name "policyname" -AssignedSegment "segmentAname" -SegmentsBlocked "segmentBname" New-InformationBarrierPolicy -Name "Sales-Research" -AssignedSegment "Sales" -SegmentsBlocked "Research" -State Inactive

    この例では、Sales というセグメントに対して Sales-Research というポリシーを定義しました。 このポリーがアクティブになっていて適用されると、Sales のユーザーは Research というセグメント内のユーザーと通信できなくなります。

  2. 2 つ目のブロック セグメントを定義するには、New-InformationBarrierPolicy コマンドレットを SegmentsBlocked パラメーターと共にもう一度使用しますが、今回はセグメントが逆になります。

    例 注:
    New-InformationBarrierPolicy -Name "Research-Sales" -AssignedSegment "Research" -SegmentsBlocked "Sales" -State Inactive この例では、Research-Sales というポリシーを定義して、Research が Sales と通信できないようにしました。

  3. 次のいずれかの手順を実行します:

シナリオ 2: セグメントが別のセグメント 1 つとだけ通信できるようにする

あるセグメントにもう一方のセグメントとの通信のみを許可する場合は、方向ごとに 1 つの 2 つのポリシーを定義します。 各ポリシーでは、1 方向のみの通信を許可します。

この例では、次の 2 つのポリシーを定義します:

  • セグメント A がセグメント B と通信できるようにする 1 つのポリシー
  • セグメント B がセグメント A と通信できるようにする 2 つ目のポリシー

シナリオ 2 のポータルを使用してポリシーを作成する

現在使用しているポータルに該当するタブを選択してください。 Microsoft Purview ポータルの詳細については、Microsoft Purview ポータルを参照してください。 コンプライアンス ポータルの詳細については、「Microsoft Purview コンプライアンス ポータル」を参照してください。

次の手順を使用して、ポリシーの作成を実行します:

  1. 組織の管理者アカウントの資格情報を使用して、Microsoft Purview ポータルにサインインします。

  2. [情報バリア] ソリューション カードを選択します。 [情報バリア] ソリューション カードが表示されていない場合は、[すべてのソリューションを表示] を選択し、[リスクとコンプライアンス] セクションから [情報バリア] を選択します。

  3. [ポリシー] ページで [ポリシーの作成] を選択し、新しい IB ポリシーを作成して構成します。

  4. [名前] ページで、ポリシーの名前を入力して、[次へ] を選択します。

  5. [割り当て済みセグメント] ページで、[セグメントを選択する] を選択します。 検索ボックスを使用して名前でセグメントを検索するか、スクロールすると表示される一覧からセグメントを選択します。 [追加] を選択して、選択したセグメントをポリシーに追加します。 選択できるセグメントは 1 つだけです。

  6. [次へ] を選択します。

  7. [コミュニケーションとコラボレーション] ページにある [コミュニケーションとコラボレーション] フィールドでポリシーの種類を選択します。 ポリシーのオプションは、[許可] または [ブロック] のどちらかです。 この例のシナリオでは、ポリシーに [許可] を選択します。

    重要

    ポリシーの作成後には、セグメントの許可とブロックの状態を変更することはできません。 ポリシーの作成後に状態を変更するには、ポリシーを削除してから新しいポリシーを作成する必要があります。

  8. [セグメントを選択する] を選択して、ターゲット セグメントのアクションを定義します。 この手順では、複数セグメントの割り当てができます。 たとえば、Manufacturing というセグメントのユーザーが HR というセグメントのユーザーと通信できるようにする場合は、手順 5 で Manufacturing セグメントを定義して、この手順の [セグメントを選択する] オプションで HR を割り当てます。

  9. [次へ] を選択します。

  10. [ポリシーの状態] ページで、アクティブなポリシーの状態を [オン] に切り替えます。 [次へ] を選んで続行します。

  11. [設定の確認] ページで、ポリシーに選択した設定と、選択内容に対する提案または警告を確認します。 [編集] を選択してポリシーのセグメントと状態を変更するか、[送信] を選択してポリシーを作成します。

  12. この例では、前の手順を繰り返して 2 つ目の許可ポリシーを作成し、Research というセグメント内のユーザーが Sales というセグメント内のユーザーと通信できるようにします。 手順 5 で Research セグメントを定義して、[セグメントを選択する] オプションで Sales (または複数のセグメント) を割り当てます。

PowerShell を使用してシナリオ 2 のポリシーを作成する

PowerShell でポリシーを定義するには、次の手順を実行します:

  1. あるセグメントがもう一方のセグメントとのみ通信できるようにするには、New-InformationBarrierPolicy コマンドレットを SegmentsAllowed パラメーターと共に使用します。

    構文 例
    New-InformationBarrierPolicy -Name "policyname" -AssignedSegment "segmentAname" -SegmentsAllowed "segmentBname","segment1name" New-InformationBarrierPolicy -Name "Manufacturing-HR" -AssignedSegment "Manufacturing" -SegmentsAllowed "HR","Manufacturing" -State Inactive

    この例では、Manufacturing というセグメントに Manufacturing-HR というポリシーを定義しました。 このポリーがアクティブになっていて適用されると、Manufacturing のユーザーは HR というセグメント内のユーザーと通信できるようになります。 この場合、Manufacturing は HR に属していないユーザーと通信できません。

    必要に応じて、次の例に示すように、このコマンドレットに複数のセグメントを指定できます。

    構文 例
    New-InformationBarrierPolicy -Name "policyname" -AssignedSegment "segmentAname" -SegmentsAllowed "segmentBname", "segmentCname","segmentDname" New-InformationBarrierPolicy -Name "Research-HRManufacturing" -AssignedSegment "Research" -SegmentsAllowed "HR","Manufacturing","Research" -State Inactive

    この例では、Research セグメントが HR および Manufacturing のみと通信できるようにするポリシーを定義しました。

    この手順を定義するポリシーごとに繰り返して、特定のセグメントが特定の別のセグメントのみと通信できるようにします。

  2. 2 つ目の許可セグメントを定義するには、New-InformationBarrierPolicy コマンドレットを SegmentsAllowed パラメーターと共にもう一度使用しますが、今回はセグメントが逆になります。

    例 注:
    New-InformationBarrierPolicy -Name "Research-Sales" -AssignedSegment "Research" -SegmentsAllowed "Sales" -State Inactive この例では、Research-Sales というポリシーを定義して、Research が Sales と通信できるようにします。

  3. 次のいずれかの手順を実行します:

手順 4: IB ポリシーを適用する

IB ポリシーは、アクティブ状態に設定してから、ポリシーを適用するまで有効になりません。

ポータルを使用してポリシーを適用する

現在使用しているポータルに該当するタブを選択してください。 Microsoft Purview ポータルの詳細については、Microsoft Purview ポータルを参照してください。 コンプライアンス ポータルの詳細については、「Microsoft Purview コンプライアンス ポータル」を参照してください。

ポリシーを適用するには、次の手順を実行します:

  1. 組織の管理者アカウントの資格情報を使用して、Microsoft Purview ポータルにサインインします。

  2. [情報バリア] ソリューション カードを選択します。 [情報バリア] ソリューション カードが表示されていない場合は、[すべてのソリューションを表示] を選択し、[リスクとコンプライアンス] セクションから [情報バリア] を選択します。

  3. [ ポリシー アプリケーション] を選択します。

  4. [ポリシーの適用] ページで、[すべてのポリシーを適用] を選択して、組織のすべての IB ポリシーを適用します。

    注:

    システムがポリシーの適用を開始するまで 30 分待ちます。 システムは、ユーザーごとにポリシーを適用します。 システムは、1 時間に約 5,000 のユーザー アカウントを処理します。

PowerShell を使用してポリシーを適用する

PowerShell を使用してポリシーを適用するには、次の手順を実行します:

  1. Get-InformationBarrierPolicy コマンドレットを使用して、定義されているポリシーの一覧を表示します。 各ポリシーの状態と ID (GUID) をメモします。

    構文: Get-InformationBarrierPolicy

  2. ポリシーをアクティブな状態に設定するには、Set-InformationBarrierPolicy コマンドレットを Identity パラメーターと、Active に設定した State パラメーターと共に使用します。

    構文 例
    Set-InformationBarrierPolicy -Identity GUID -State Active Set-InformationBarrierPolicy -Identity 43c37853-ea10-4b90-a23d-ab8c93772471 -State Active

    この例では、GUID 43c37853-ea10-4b90-a23d-ab8c93772471 の IB ポリシーをアクティブな状態に設定しました。

    この手順を必要に応じてポリシーごとに繰り返します。

  3. IB ポリシーをアクティブな状態に設定したら、Security & Compliance PowerShell の Start-InformationBarrierPoliciesApplication コマンドレットを使用します。

    構文: Start-InformationBarrierPoliciesApplication

    Start-InformationBarrierPoliciesApplication を実行した後、システムがポリシーを適用を開始するまで 30 分待ちます。 システムは、ユーザーごとにポリシーを適用します。 システムは、1 時間に約 5,000 のユーザー アカウントを処理します。

ユーザー アカウント、セグメント、ポリシー、またはポリシー適用の状態を表示する

PowerShell を使用すると、次の表に示すように、ユーザー アカウント、セグメント、ポリシー、ポリシー適用の状態を表示できます。

この情報を表示する場合 実行するアクション
ユーザー アカウント Get-InformationBarrierRecipientStatus コマンドレットを Identity パラメーターと共に使用します。

構文: Get-InformationBarrierRecipientStatus -Identity <value> -Identity2 <value>

名前、エイリアス、識別名、正規ドメイン名、電子メール アドレス、GUID など、各ユーザーを一意に識別する任意の値を使用できます。

例: Get-InformationBarrierRecipientStatus -Identity meganb -Identity2 alexw

この例では、Office 365 の 2 つのユーザー アカウント Megan の meganb と Alex の alexw を参照しています。

(このコマンドレットは単一のユーザーに対しても使用できます: Get-InformationBarrierRecipientStatus -Identity <value>)

このコマンドレットは、属性値や適用されているすべての IB ポリシーなど、ユーザーに関する情報を返します。
セグメント Get-OrganizationSegment コマンドレットを使用します。

構文: Get-OrganizationSegment

このコマンドレットは、組織に対して定義されているすべてのセグメントの一覧を表示します。
IB ポリシー Get-InformationBarrierPolicy コマンドレットを使用します。

構文: Get-InformationBarrierPolicy

このコマンドレットは、定義された IB ポリシーとその状態の一覧を表示します。
最近の IB ポリシー適用 Get-InformationBarrierPoliciesApplicationStatus コマンドレットを使用します。

構文: Get-InformationBarrierPoliciesApplicationStatus

このコマンドレットは、ポリシー適用が完了したか、失敗したか、進行中かどうかに関する情報を表示します。
すべての IB ポリシー適用 Get-InformationBarrierPoliciesApplicationStatus -All を使う

このコマンドレットは、ポリシー適用が完了したか、失敗したか、進行中かどうかに関する情報を表示します。

ポリシーの削除または変更が必要な場合はどうすればよいですか?

IB ポリシーの管理に役立つ参照資料があります。

手順 5: SharePoint と OneDrive の情報バリアを構成する

SharePoint と OneDrive に対応する IB を構成する場合は、それらのサービスで IB を有効にする必要があります。 また、Microsoft Teams に対応する IB を構成する場合も、それらのサービスで IB を有効にする必要があります。 Microsoft Teams でチームを作成すると、SharePoint サイトが自動的に作成され、ファイル エクスペリエンスのために Microsoft Teams に関連付けられます。 既定では、情報バリア ポリシーは、この SharePoint サイトとファイルには適用されません。

SharePoint と OneDrive で IB を有効にするには、「SharePoint で情報バリアを使用する」のガイダンスと手順に従います。

手順 6: 情報バリアのモード (省略可能)

モードは、Microsoft 365 リソースのアクセス、共有、メンバーシップをリソースの IB モードに基づいて強化するのに役立ちます。 モードは、Microsoft 365 グループ、Microsoft Teams、OneDrive、および SharePoint サイトでサポートされ、新規または既存の IB 構成で自動的に有効になります。

Microsoft 365 リソースでは、次の IB モードがサポートされています:

Mode 説明 例
Open Microsoft 365 リソースに関連付けられている IB ポリシーまたはセグメントはありません。 誰でもリソースのメンバーに招待できます。 組織のピクニック イベント用に作成されたチーム サイト。
所有者モデレート Microsoft 365 リソースの IB ポリシーは、リソース所有者の IB ポリシーから決定されます。 リソース所有者は、自分の IB ポリシーに基づいて任意のユーザーをリソースに招待できます。 このモードは、所有者がモデレートする互換性のないセグメント ユーザー間のコラボレーションを会社が許可する場合に便利です。 IB ポリシーに従って新しいメンバーを追加できるのは、リソース所有者だけです。 HR の VP は、営業と調査の VP と共同作業したいと考えています。 IB モードの所有者モデレートが設定された新しい SharePoint サイトで、営業と調査の両方のセグメント ユーザーを同じサイトに追加します。 適切なメンバーがリソースに追加されていることを確認するのは所有者の責任です。
暗黙的 Microsoft 365 リソースの IB ポリシーまたはセグメントは、リソース メンバーの IB ポリシーから継承されます。 所有者は、リソースの既存のメンバーとの互換性がある限り、メンバーを追加できます。 このモードは、Microsoft Teams の既定の IB モードです。 営業セグメント ユーザーは、Microsoft Teams チームを作成して、組織内の別の互換性のあるセグメントと共同作業します。
Explicit Microsoft 365 リソースの IB ポリシーは、リソースに関連付けられているセグメントに従います。 リソース所有者または SharePoint 管理者は、リソースのセグメントを管理できます。 そのサイトに営業セグメントを関連付けることで、営業セグメントのメンバーが共同作業するためにのみ作成されたサイト。
Mixed OneDrive にのみ適用されます。 OneDrive の IB ポリシーは、OneDrive に関連付けられているセグメントに従います。 リソース所有者または OneDrive 管理者は、リソースのセグメントを管理できます。 営業セグメントのメンバーが共同作業のために作成した OneDrive は、セグメント化されていないユーザーと共有できます。

暗黙的モードの更新

組織で IB を有効にした時期に応じて、組織は Legacy、SingleSegment、または MultiSegment 組織モードになります。 モードを確認するには、「組織の IB モードを確認する」を参照してください。

組織が SingleSegment または MultiSegment モードで、Teams グループの情報バリア モードが暗黙的になっている場合、Teams に接続されたグループ/サイトにはセグメントが関連付けられません。

IB のモードとサービス間での構成方法の詳細については、次の記事を参照してください:

手順 7: 情報バリアのユーザー検出可能性を構成する (省略可能)

情報バリアのポリシーを使用すると、管理者はユーザー ピッカーで検索制限を有効または無効にすることができます。 既定では、IB ポリシーに対してユーザー ピッカーの制限が有効になっています。 たとえば、2 人の特定のユーザーの通信をブロックする IB ポリシーでは、それらのユーザーがユーザー ピッカーを使用するときに相互に表示されないように制限することもできます。

重要

検索制限の有効化または無効化のサポートは、組織が Legacy モードでない場合にのみ使用できます。 Legacy モードの組織では、検索制限を有効または無効にすることはできません。 検索制限を有効または無効にするには、組織の情報バリア モードを変更するための追加操作が必要です。 詳細については、「情報バリアで複数セグメントのサポートを使用する」を参照してください。

Legacy モードの組織は、将来、情報バリアの最新バージョンにアップグレードする資格があります。 詳細については、情報バリアのロードマップを参照してください。

PowerShell を使用してユーザー ピッカーの検索制限を無効にするには、次の手順を実行します:

  1. Set-PolicyConfig コマンドレットを使用して、ユーザー ピッカーの制限を無効にします。
Set-PolicyConfig -InformationBarrierPeopleSearchRestriction 'Disabled'

シナリオ例: Contoso の部門、セグメント、ポリシー

組織がセグメントとポリシーの定義に取りかかる方法を確認するために、次のシナリオ例を考えてみましょう。

Contoso の部門とプラン

Contoso には、HR、Sales、Marketing、Research、および Manufacturing の 5 つの部門があります。 業界の規制に準拠するために、次の表に示すように、一部の部門は別の部門と通信してはいけないことになっています:

セグメント 通信できる相手 通信できない相手
HR すべてのユーザー (制限なし)
営業 HR、Marketing、Manufacturing 研究
マーケティング すべてのユーザー (制限なし)
リサーチ HR、Marketing、Manufacturing 営業
製造 HR、Marketing HR または Marketing 以外のユーザー

この構造に応じて、Contoso の計画には次の 3 つの IB ポリシーが含まれています:

  1. Sales が Research と通信できないように設計された IB ポリシー
  2. Research が Sales と通信できないようにするためのもう 1 つの IB ポリシー。
  3. Manufacturing が HR および Marketing とだけ通信できるように設計されたポリシー。

このシナリオでは、HR または Marketing の IB ポリシーを定義する必要はありません。

Contoso の定義済みセグメント

Contoso は、次のように、Microsoft Entra ID の Department 属性を使用してセグメントを定義します。

部署 セグメントの定義
人事 New-OrganizationSegment -Name "HR" -UserGroupFilter "Department -eq 'HR'"
営業 New-OrganizationSegment -Name "Sales" -UserGroupFilter "Department -eq 'Sales'"
マーケティング New-OrganizationSegment -Name "Marketing" -UserGroupFilter "Department -eq 'Marketing'"
リサーチ New-OrganizationSegment -Name "Research" -UserGroupFilter "Department -eq 'Research'"
製造 New-OrganizationSegment -Name "Manufacturing" -UserGroupFilter "Department -eq 'Manufacturing'"

セグメントを定義したところで、Contoso はポリシーの定義に進みます。

Contoso の IB ポリシー

Contoso は、次の表で示すように 3 つのポリシーを定義します。

ポリシー ポリシー定義
ポリシー 1: 営業部門がリサーチ部門と通信できないようにする New-InformationBarrierPolicy -Name "Sales-Research" -AssignedSegment "Sales" -SegmentsBlocked "Research" -State Inactive

この例では、この IB ポリシーを Sales-Research と呼びます。 このポリシーが適応されると、営業セグメント内のユーザーがリサーチセグメント内のユーザーと通信できなくなります。 これは一方向ポリシーで、Research からの Sales との通信が防止されることはありません。 そのため、ポリシー2が必要です。
ポリシー 2: リサーチ部門が営業部門と通信できないようにする New-InformationBarrierPolicy -Name "Research-Sales" -AssignedSegment "Research" -SegmentsBlocked "Sales" -State Inactive

この例では、この IB ポリシーを Research-Sales と呼びます。 このポリシーが適応されると、リサーチセグメント内のユーザーが、営業セグメント内のユーザーと通信できなくなります。
ポリシー 3: Manufacturing が HR および Marketing とだけ通信できるようにする New-InformationBarrierPolicy -Name "Manufacturing-HRMarketing" -AssignedSegment "Manufacturing" -SegmentsAllowed "HR","Marketing","Manufacturing" -State Inactive

この場合、この IB ポリシーを Manufacturing-HRMarketing と呼びます。 このポリシーが適応されると、製造部門は人事およびマーケティング部門とだけ通信を行えます。 HR と Marketing は、その他のセグメントとの通信が制限されていません。

セグメントとポリシーを定義したところで、Contoso は Start-InformationBarrierPoliciesApplication コマンドレットを実行してポリシーを適用します。

コマンドレットが完了時には、Contoso は業界の要件に準拠しています。

リソース