次の方法で共有

Power BI 実装計画: Power BI のデータ損失防止

  • [アーティクル]

注意

この記事は、Power BI 実装計画 シリーズの記事の一部です。 このシリーズでは、主に Microsoft Fabric 内での Power BI のエクスペリエンスに焦点を当てます。 シリーズの概要については、「Power BI 実装計画」を参照してください。

この記事では、Power BI でのデータ損失防止 (DLP) の実装に関連する計画アクティビティについて説明します。 対象ユーザーは次のとおりです。

  • Power BI 管理者: 組織の Power BI 監視を担当する管理者。 Power BI 管理者は、情報セキュリティ チームやその他の関連チームと共同で作業する必要があります。
  • センター オブ エクセレンス、IT、BI チーム: 組織内の Power BI の監視を担当するその他のチーム。 これらのチームは、Power BI 管理者、情報セキュリティ チーム、その他の関連チームと共同で作業することが必要な場合があります。

重要

データ損失防止 (DLP) は、組織規模で行う重要な作業です。 その範囲と影響は、Power BI だけに留まりません。 このような種類のイニシアティブには、資金、優先順位付け、計画が必要です。 計画、使用、監視の作業には、部門を超えた複数のチームが関与する必要があります。

Power BI の DLP をロールアウトするには、段階的なアプローチに従って徐々に進めていくことをお勧めします。 考慮する必要があるロールアウト フェーズの種類については、Power BI の情報保護 (展開の段階)に関するページを参照してください。

DLP の目的

データ損失防止 (DLP) とは、組織のデータを保護するアクティビティとプラクティスを指します。 DLP の目標は、承認されていないユーザーと機密データを共有する場合に発生する可能性があるデータ漏えいのリスクを軽減することです。 ユーザーの責任ある行動は、データを保護する上できわめて重要ですが、DLP は通常、自動化されたポリシーを指します。

DLP を使用すると、次のことができます。

  • 機密データの危険、不注意、または不適切な共有が行われた場合、それを検出して管理者に通知します。 具体的には、次のことができます。
    • 自動化と情報を使用して、Power BI テナントの全体的なセキュリティ設定を改善する。
    • 機密データを対象とする分析ユース ケースを有効にする。
    • 監査情報をセキュリティ管理者に提供する。
  • ユーザーにコンテキスト通知を提供します。 具体的には、次のことができます。
    • ユーザーが通常のワークフローで適切な意思決定を行うのを支援する。
    • 生産性を低下させることなくデータ分類と保護ポリシーに従うようにユーザーを指導する。

DLP サービス

大まかに言うと、データ損失防止を実装できるサービスには、次の 2 つがあります。

  • Power BI の Microsoft Purview DLP ポリシー
  • Microsoft Defender for Cloud Apps

Power BI の Microsoft Purview DLP ポリシー

Power BI の DLP ポリシーは、Microsoft Purview コンプライアンス ポータルで設定されます。 Power BI サービスの Premium ワークスペースに発行されたセマンティック モデル内の機密データを検出できます。

重要

この記事では、Power BI Premium またはその容量サブスクリプション (P SKU) に言及することがあります。 現在、Microsoft は購入オプションを統合し、容量あたりの Power BI Premium SKU を廃止していることに注意してください。 新規および既存のお客様は、代わりに Fabric 容量サブスクリプション (F SKU) の購入をご検討ください。

詳細については、「Power BI Premium ライセンスに関する重要な更新」と「Power BI Premium のよく寄せられる質問」を参照してください。

この種の DLP ポリシーの目的は、機密データが格納されている場所をユーザーに認識させ、管理者に通知することです。 DLP ポリシーでは、機密情報の種類または秘密度ラベルに基づいてユーザー通知と管理者アラートを生成できます。 たとえば、クレジット カードの情報または個人を特定できる情報 (PII) がセマンティック モデルに格納されているかどうかを確認できます。

Note

この記事では、Power BI の DLP に焦点を当てています。

Microsoft Defender for Cloud Apps

Microsoft Defender for Cloud Apps は、多くの機能を備えたツールです。 Microsoft Defender for Cloud Apps で設定できる一部のポリシー (Microsoft Entra ID との統合) には DLP が含まれます。 これらのポリシーは、特定のユーザー アクティビティが発生したときに、ブロック、ログ記録、またはアラートの生成を行うことができます。 たとえば、ユーザーが、"高制限" の秘密度ラベルが割り当てられているレポートを Power BI サービスからダウンロードしようとすると、そのダウンロード アクションがブロックされます。

記事「Defender for Cloud Apps for Power BI」では、Power BI サービスを監視するために Defender for Cloud Apps を使用する方法について説明しています。 この記事の残りの部分では、Power BI の DLP に焦点を当てます。

重要

Microsoft Purview コンプライアンス ポータルで設定される Power BI の DLP ポリシーは、Power BI Premium ワークスペースに格納されているコンテンツに対してのみ適用できます。 ただし、Defender for Cloud Apps で設定されるポリシーに、同様の Power BI Premium 前提条件はありません。 2 つのツールセットの機能、目的、使用可能なアクションが異なることに注意してください。 最大の効果を得るために、両方のツールセットの使用を検討することをお勧めします。

Power BI の DLP の前提条件

ここまでで、記事「Power BI の情報保護」で説明されている組織レベルの計画手順を完了しているはずです。 先に進む前に、以下を明確にする必要があります。

  • 現在の状態: 組織内の DLP の現在の状態。 DLP が既に使用されている範囲と、それを管理する担当者を理解している必要があります。
  • 目標と要件: 組織で DLP を実装するための戦略的目標。 目標と要件を理解することは、実装作業のガイドとして役立ちます。

通常、DLP を実装する前に、情報保護 (記事「Power BI の情報保護」で説明) を実装します。 ただし、これは、Power BI の DLP を使用するための前提条件ではありません。 秘密度ラベルが発行されている場合は、Power BI の DLP で使用できます。 また、機密情報の種類も Power BI の DLP で使用できます。 この記事では、両方の種類について説明します。

主な決定事項とアクション

DLP ポリシーの目的は、保護対象のコンテンツに対し、ルールと規則に基づいて、自動化されたアクションを設定することです。 目標と要件をサポートするルールと条件についていくつかの意思決定を行う必要があります。

1 つの DLP ポリシー内で個別のルールを定義する利点は、カスタマイズされたアラートまたはユーザー通知を有効にできることです。

DLP ポリシーの一覧と DLP ポリシー ルールには、考慮すべき階層的な優先順位があります。 優先順位は、最初に発生したときに呼び出されるポリシーに影響します。

注意事項

このセクションは、考えられるすべてのアプリケーションで DLP について行う可能性のあるすべての決定事項をまとめた完全な一覧ではありません。 必ず他の利害関係者やシステム管理者と協力して、すべてのアプリケーションとユース ケースに適した意思決定を行ってください。 たとえば、OneDrive または SharePoint に格納されているソース ファイルとエクスポートされたファイルを保護するための追加の DLP ポリシーを調査することをお勧めします。 この一連の記事では、Power BI サービスのコンテンツのみに焦点を当てています。

機密データの種類

Microsoft Purview コンプライアンス ポータルで設定される Power BI の DLP ポリシーは、秘密度ラベルまたは機密情報の種類に基づくことができます。

重要

Power BI のほとんどの種類の項目に秘密度ラベルを割り当てることができますが、この記事で説明する DLP ポリシーは特にセマンティック モデルに重点を置きます。 セマンティック モデルは Premium ワークスペースに発行する必要があります。

秘密度ラベル

秘密度ラベルを使用して、機密性の低いコンテンツから機密性の高いコンテンツまで、コンテンツを分類できます。

Power BI の DLP ポリシーが呼び出されると、"秘密度ラベル ルール" により、(Power BI サービスに発行されている) セマンティック モデルがチェックされ、特定の秘密度ラベルが存在するかどうかを確認します。 記事「Power BI の情報保護」で説明されているように、ラベルは、ユーザーまたは自動化されたプロセス (継承されたラベルや既定のラベルなど) によって割り当てることができます。

秘密度ラベルに基づいて DLP ルールを作成する場合の例をいくつか次に示します。

  • 規制コンプライアンス: 特定の規制要件の対象となるデータ用に予約された秘密度ラベルがあります。 ユーザーによって Power BI サービス内のセマンティック モデルにその秘密度ラベルが割り当てられた場合、セキュリティ管理者に対してアラートを生成する必要があります。
  • 機密データに関するコンテンツ作成者向けのリマインダー: 機密データに使用される秘密度ラベルがあります。 ユーザーが Power BI サービスの[データ ハブ] で [セマンティック モデルの詳細] ページを表示した場合、ユーザー通知を生成する必要があります。 たとえば、機密データを適切に処理する方法をユーザーに通知できます。

ユーザー通知とアラートに関するその他の考慮事項については、この記事の次のセクションで説明します。

チェックリスト - 秘密度ラベル ルールのニーズを検討する際の主な決定事項とアクションは次のとおりです。

  • 情報保護の現在の状態を確認する: 秘密度ラベルが組織にデプロイされていること、および DLP ポリシーで使用する準備ができていることを確認します。
  • 秘密度ラベルに基づいて DLP のユース ケースをまとめる: DLP ポリシーを設定することが有効な秘密度ラベルを決定します。 目標、規制、内部要件を検討します。
  • 秘密度ラベルに基づいて DLP のユース ケースの一覧に優先順位を付ける: 最優先事項についてチームと話し合います。 プロジェクト計画で優先する項目を特定します。

注意

通常、DLP ポリシーは自動化されます。 ただし、ユーザーの責任ある行動も、データを保護する上で重要な役割を果たします。

詳細については、「Power BI の情報保護 (データの分類と保護のポリシー)」を参照してください。 特定の秘密度ラベルに割り当てられたコンテンツに対してユーザーが実行できることとできないことに関するガイダンスを提供する内部ガバナンス ポリシーについて説明しています。

機密性の高い情報の種類

すべての種類のデータが同じであるわけではありません。特定の種類のデータは本質的に他のデータよりも機密性が高くなります。 さまざまな機密情報の種類 (SIT) があります。 業界とコンプライアンス要件によっては、一部の SIT のみが組織に適用されます。

SIT の一般的な例をいくつか次に示します。

  • パスポート、社会保障、運転免許証の番号
  • 銀行の口座番号と支店コード
  • クレジット カードとデビッド カードの番号
  • 納税者番号と国民識別番号
  • 健康保険番号と医療情報
  • 実際の住所
  • アカウント キー、パスワード、データベース接続文字列

ヒント

機密データに分析値がない場合、機密データが分析システム内に存在する必要があるかどうかを検討します。 Power BI に格納するデータについて適切な意思決定を行えるように、コンテンツ作成者を教育することをお勧めします。

SIT は、パターンベースの分類子です。 テキスト内の既知のパターンの検出には、正規表現が使用されます。

Microsoft Purview コンプライアンス ポータルには、事前構成された SIT が多数あります。 事前構成された SIT が要件を満たす場合、それを使用すると時間を節約できます。 クレジット カード番号の事前構成された SIT について考えてみましょう。これは、すべての主要なカード発行者の正しいパターンを検出し、チェックサムの有効性を確認し、クレジット カード番号に近い範囲内で関連するキーワードを検索します。

事前構成された SID がニーズを満たしていない場合、または独自のデータ パターンがある場合は、カスタム SIT を作成できます。 たとえば、従業員 ID 番号のパターンに一致するカスタム SIT を作成できます。

SIT を設定すると、セマンティック モデルがアップロードまたは更新されたときに Power BI の DLP ポリシーが呼び出されます。 その時点で、機密情報の種類のルールにより、(Power BI サービス内の) セマンティック モデルがチェックされ、機密情報の種類が存在するかどうかが確認されます。

機密データの種類に基づいて DLP ルールを作成する場合の例をいくつか次に示します。

  • 規制コンプライアンス: 規制要件の対象となる機密情報の種類があります。 その種類のデータが Power BI サービス内のセマンティック モデル内で検出された場合、セキュリティ管理者に対してアラートを生成する必要があります。
  • 内部要件: 特別な処理を必要とする機密情報の種類があります。 内部要件を満たすために、ユーザーが (Power BI サービスの) [データ ハブ]で [セマンティック モデルの設定] または [セマンティック モデルの詳細] ページを表示したときに、ユーザー通知を生成する必要があります。

チェックリスト - 機密情報の種類のニーズを検討する際の主な決定事項とアクションは次のとおりです。

  • 機密情報の種類に基づいて DLP のユース ケースをまとめる: DLP ポリシーを設定することが有効な機密情報の種類を決定します。 目標、規制、内部要件を検討します。
  • 既存の機密情報の種類をテストする: 情報セキュリティ チームと協力して、事前構成された SIT がニーズを満たしていることを確認します。 テスト データを使用して、パターンとキーワードが正しく検出されていることを確認します。
  • カスタムの機密情報の種類を作成する: 該当する場合は、情報セキュリティ チームと協力して、Power BI の DLP で使用できるように、SIT を作成します。
  • ユース ケースの一覧に優先順位を設定する: 最優先事項についてチームと話し合います。 プロジェクト計画で優先する項目を特定します。

ユーザー通知

秘密度ラベルと SIT を使用して DLP のユース ケースを特定したら、次に DLP ルールとの一致が発生した場合のアクションを検討する必要があります。 通常、ユーザー通知が必要です。

DLP ポリシーのユーザー通知は、"ポリシー ヒント"とも呼ばれます。 これは、通常のワークフロー中にユーザーにより多くのガイダンスを提供し、ユーザーの認識を高める場合に役立ちます。 ユーザー通知が次の場合、ユーザーがそれを読み、その意味を理解する可能性が高くなります。

  • 具体的: メッセージをルールに関連付けると、理解しやすくなります。
  • 実践的: ユーザーが何を行う必要があるか、またはより多くの情報を見つける方法について提案を提供します。

Power BI の DLP の場合、ユーザー通知はセマンティック モデル設定に表示されます。 また、次のスクリーンショットに示すように、[データ ハブ] の [セマンティック モデルの詳細] ページの上部にも表示されます。 この例の通知は、"このデータにはクレジット カードが含まれています。この種類のデータは、データ分類、保護、利用ポリシーに従って、Power BI では許可されていません" になります。

[データ ハブ] ページの上部に表示された DLP のユーザー通知を示すスクリーンショット。

DLP ポリシーごとに 1 つ以上のルールを定義できます。 各ルールには、必要に応じて、ユーザーに表示するための異なるポリシー ヒントを含めることができます。

Power BI サービスのセマンティック モデル内に格納されている財務データを検出するための DLP ポリシーを定義する方法を示す次の例について考えてみましょう。 この DLP ポリシーでは、SIT が使用され、次の 2 つのルールが定義されています。

  • ルール 1: 最初のルールでは、クレジット カード番号を検出します。 カスタマイズされたポリシー ヒントのテキストは、"このデータにはクレジット カードが含まれています。この種類のデータは、データ分類と保護ポリシーに従って、Power BI では許可されていません" です。
  • ルール 2: 2 番目のルールでは、財務口座を検出します。 カスタマイズされたポリシー ヒントのテキストは、"このデータには機密の財務情報が含まれています。これには、高制限ラベルを使用する必要があります。財務データを格納する場合の要件については、「データの分類と保護のポリシー」を参照してください" です。

ルール 1 は、ルール 2 よりも緊急度が高くなります。 ルール 1 は、アクションを必要とする問題があることを通知するためのものです。 2 番目のルールは、より多くの情報を提供します。 緊急の問題については、アラートを設定することをお勧めします。 管理者に対するアラートについては、次のセクションで説明します。

ユーザーが受け取る通知を決定する場合、重要性の高い通知のみを表示することに重点を置くことをお勧めします。 ポリシーからの通知が多すぎると、ユーザーはそれらに圧倒されてしまう可能性があります。 その結果、一部の通知は見過ごされる場合があります。

ユーザーは、擬陽性である (誤って識別された) と思う場合、アクションとして 問題を報告することができます。 また、ポリシーのオーバーライドをユーザーに許可することもできます。 これらの機能は、Power BI ユーザーと、Power BI の DLP を管理するセキュリティ管理者との間でコミュニケーションを取れるようにすることを目的としています。

チェックリスト - DLP のユーザー通知を検討する際の主な決定事項とアクションは次のとおりです。

  • ユーザー通知が必要な状況を決定する: 作成する DLP ルールごとに、カスタム ユーザー通知が必要かどうかを判断します。
  • カスタマイズされたポリシー ヒントを作成する: 通知ごとに、ユーザーに表示する必要があるメッセージを定義します。 メッセージを DLP ルールに関連付けて、具体的で実践的なメッセージになるように計画します。

管理者のアラート

アラートは、ポリシー違反が発生したときにインシデントを追跡する場合に、特定の DLP ルールに役立ちます。 DLP ポリシー ルールを定義する場合、アラートを生成する必要があるかどうかを検討します。

ヒント

アラートは、特定の状況に対して管理者の注意を喚起するように設計されています。 これは、重要なアラートを積極的に調査して解決する場合に最適です。 すべての DPS ルールの一致は、Microsoft Purview コンプライアンス ポータルのアクティビティ エクスプローラーで確認できます。

アラートは、次の場合に役立ちます。

  • DLP アラート管理ダッシュボードを介して、何かが発生したことをセキュリティ管理者とコンプライアンス管理者に認識させる。 必要に応じて、特定のユーザー セットに電子メールを送信することもできます。
  • 発生したイベントの詳細を確認する。
  • イベントの調査担当者にイベントを割り当てる。
  • イベントの状態を管理するか、それにコメントを追加する。
  • アクティビティに対して同じユーザーによって生成された他のアラートを表示する。

各アラートは、重大度レベル (低、中、高) で定義できます。 重大度レベルは、開いているアラートのレビューに優先順位を付けるのに役立ちます。

アラートを使用する方法の 2 つの例を次に示します。

例 1: Power BI サービス内のセマンティック モデルに格納されている財務データを検出するための DLP ポリシーを定義しました。 この DLP ポリシーでは、機密情報の種類が使用されます。 定義されているルールは、次の 2 つです。

  • ルール 1: このルールは、クレジット カードの番号を検出します。 アラートは、重大度が高い場合に有効になります。 電子メールも生成されます。
  • ルール 2: このルールは、財務口座を検出します。 アラートは、重大度が高い場合に有効になります。

例 2: 高制限、執行委員会、または取締役会役員の秘密度ラベルが Power BI サービスのセマンティック モデルに割り当てられるときに呼び出される DLP ポリシーを定義しました。 ユーザー通知は生成されません。 この場合、発生をログに記録するだけなので、アラートを生成する必要はない可能性があります。 必要に応じて、アクティビティ エクスプローラーから詳細情報を取得できます。

電子メール通知が必要な場合は、メールが有効なセキュリティ グループを使用することをお勧めします。 たとえば、Security and Privacy Admin Alerting という名前のグループを使用します。

ヒント

Power BI の DLP ルールは、セマンティック モデルがアップロードまたは更新されるたびに確認されます。 つまり、セマンティック モデルが更新されるたびにアラートが生成される可能性があります。 データが定期的または頻繁に更新されると、圧倒的な数のイベントがログに記録されて、アラートが生成される可能性があります。

チェックリスト - 管理者に対する DLP アラートを検討する際の主な決定事項とアクションは次のとおりです。

  • アラートが必要な状況を決定する: 作成する DLP ルールごとに、アラートを使用する必要がある状況を決定します。
  • 役割と責任を明確にする: 期待値と、アラートが生成されたときに実行する必要がある特定のアクションを決定します。
  • アラートを受け取るユーザーを決定する: 開いているアラートに対処するセキュリティ管理者とコンプライアンス管理者を決定します。 Microsoft Purview コンプライアンス ポータルを使用する各管理者について、アクセス許可とライセンス要件が満たされていることを確認します。
  • 電子メール グループを作成する: アラートに対処するために、必要に応じて、メールが有効な新しいセキュリティ グループを作成します。

スコープ内のワークスペース

Microsoft Purview コンプライアンス ポータルで設定される Power BI の DLP ポリシーは、セマンティック モデルを対象とすることを目的としています。 具体的には、Premium ワークスペースに発行されたセマンティック モデルのスキャンがサポートされます。

すべての Premium ワークスペースをスキャンするように DLP ポリシーを設定できます。 必要に応じて、特定のワークスペースを含めるか除外するかを選択できます。 たとえば、リスクが低いと見なされる特定の開発またはテスト ワークスペースを除外できます (特に、実際の運用データが含まれていない場合)。 または、特定の開発またはテスト ワークスペースに対して個別のポリシーを作成することもできます。

ヒント

DLP 用に Premium ワークスペースのサブセットのみを含めることを決定した場合、保守レベルを検討します。 すべての Premium ワークスペースが含まれている場合は、DLP ルールを簡単に保守できます。 Premium ワークスペースのサブセットのみを含める場合は、新しいワークスペースが DLP ポリシーに含まれていないかどうかを迅速に特定できるように、監査プロセスが用意されていることを確認してください。

ワークスペースの詳細については、ワークスペースの計画に関する記事を参照してください。

チェックリスト - DLP のスコープに含めるワークスペースを検討する際の主な決定事項とアクションは次のとおりです。

  • DLP を適用する必要がある Premium ワークスペースを決定する: DLP ポリシーがすべての Power BI Premium ワークスペースに影響を与えるか、それらのサブセットにのみ影響するかを検討します。
  • ワークスペースの割り当てに関するドキュメントを作成する: 該当する場合は、DLP の対象となるワークスペースを文書化します。 ワークスペースが含まれるまたは除外される条件と理由を含めます。
  • DLP の決定をワークスペース ガバナンスと関連付ける: 該当する場合は、DLP の処理方法に関する詳細を含むようにワークスペース ガバナンスのドキュメントを更新します。
  • その他の重要なファイルの場所を検討する: Power BI サービスに加えて、OneDrive または SharePoint に格納されているソース ファイルとエクスポートされたファイルを保護するために、他の DLP ポリシーを作成する必要があるかどうかを決定します。

ライセンスの要件

DLP を使用するには、いくつかの ライセンス要件があります。 DLP を設定、管理、監視する管理者には、Azure Purview 情報保護 ライセンスが必要です。 これらの機能は、Microsoft 365 E5 などの一部のライセンス スイートに含まれているため、既に保持している可能性があります。 または、Microsoft 365 E5 Compliance 機能をスタンドアロン ライセンスとして購入することもできます。

また、Power BI の DLP ポリシーには Power BI Premium も必要です。 この ライセンス要件は、Premium 容量または Premium Per User (PPU) ライセンスで満たすことができます。

ヒント

ライセンス要件について明確にする必要がある場合は、Microsoft アカウント チームにお問い合わせください。 Microsoft 365 E5 Compliance ライセンスには、この記事の範囲外であるその他の機能が含まれています。

チェックリスト - DLP ライセンスを評価する際の主な決定事項とアクションは次のとおりです。

  • 製品のライセンス要件を確認する: DLP のすべてのライセンス要件を確認します。
  • Premium ライセンス要件を確認する: DLP 用に構成するワークスペースが Premium ワークスペースであることを確認します。
  • 追加のライセンスを調達する: 必要に応じて、ライセンスをさらに購入して、使用する機能のロックを解除します。
  • ライセンスを割り当てる: ライセンスを必要とする各セキュリティおよびコンプライアンス管理者にライセンスを割り当てます。

ユーザーのドキュメントとトレーニング

Power BI の DLP をロールアウトする前に、ユーザー ドキュメントを作成して公開することをお勧めします。 一元化されたポータルの SharePoint ページまたは Wiki ページは、保守が容易になるため有用です。 共有ライブラリまたは Teams サイトにアップロードされたドキュメントも適切なソリューションです。

ドキュメントの目的は、シームレスなユーザー エクスペリエンスを実現することです。 ユーザー ドキュメントを準備することは、すべてを考慮したことを確認するためにも役立ちます。

ユーザーに質問や技術的な問題が生じた場合の連絡先に関する情報を含めます。 情報保護は組織規模のプロジェクトであるため、多くの場合、サポートは IT 部門によって提供されます。

FAQ と例は、ユーザー ドキュメントに特に役立ちます。

ヒント

詳細については、「Power BI の情報保護 (データの分類と保護のポリシー)」を参照してください。 この記事では、ユーザーが秘密度ラベルでできることとできないことを理解できるように、データ分類と保護ポリシーを作成するための提案について説明しています。

チェックリスト - ユーザーのドキュメントとトレーニングを準備する際の主な決定事項とアクションは次のとおりです。

  • コンテンツ作成者とコンシューマー向けのドキュメントを更新する: FAQ と例を更新して、DLP ポリシーに関する関連ガイダンスを含めます。
  • ヘルプを取得する方法を公開する: ユーザーが予期しない、または理解できない問題が発生した場合にユーザーがヘルプを取得する方法を確実に知ることができるようにします。
  • 特定のトレーニングが必要かどうかを判断する: ユーザー トレーニングを作成または更新して、特に規制要件がある場合に役立つ情報を含めます。

ユーザー サポート

ユーザー サポートの担当者を確認することが重要です。 一元化された IT ヘルプ デスクで DLP がサポートされるのが一般的です。

ヘルプ デスクのガイダンス (Runbook とも呼ばれます) を作成することが必要な場合があります。 ヘルプ デスクがサポート リクエストに確実に対応できるように、ナレッジ転送セッションを実施することが必要な場合もあります。

チェックリスト - ユーザー サポート機能を準備する際の主な決定事項とアクションは次のとおりです。

  • ユーザー サポートを提供する担当者を特定する: ロールと責任を定義する場合、DLP に関連する問題についてユーザーがサポートを受ける方法を必ず説明します。
  • ユーザー サポート チームの準備を確実に整える: ドキュメントを作成し、ナレッジ転送セッションを実施して、ヘルプ デスクが DLP をサポートする準備を確実に整えます。
  • チーム間のコミュニケーション: サポート チームだけでなく、Power BI 管理者やセンター オブ エクセレンスと共に、ユーザー通知と、DLP を解決するプロセスについて話し合います。 Power BI ユーザーからの潜在的な質問に対して、関係者全員の準備が整っていることを確認します。

実装とテストの概要

決定が行われ、前提条件が満たされたら、Power BI の DLP の実装とテストを開始します。

Power BI の DLP ポリシーは、Microsoft 365 管理センターの Microsoft Purview コンプライアンス ポータル (旧称 Microsoft 365 コンプライアンス センター) で設定されます。

ヒント

Microsoft Purview コンプライアンス ポータルで Power BI の DLP を設定するプロセスには、ポリシーを設定するための 2 つの手順ではなく、1 つの手順だけが含まれます。 このプロセスは、Microsoft Purview コンプライアンス ポータルで情報保護を設定する場合 (記事「Power BI の情報保護」で説明しています) とは異なります。 その場合は、ラベルを設定する手順とラベル ポリシーを発行する手順の 2 つがあります。 DLP の場合、実装プロセスの手順は 1 つのみです。

次のチェックリストには、エンド ツー エンドの実装手順を要約した一覧が含まれています。 これらの手順の多くについては、この記事の前のセクションで詳細に説明しています。

チェックリスト - Power BI の DLP を実装する際の主な決定事項とアクションは次のとおりです。

  • 現在の状態と目標を確認する: 必ず、Power BI で使用する DLP の現在の状態を明確にします。 DLP を実装するためのすべての目標と要件を明確にして積極的に使用し、意思決定プロセスを推進する必要があります。
  • 決定を行う: 必要なすべての決定事項を確認し、それらについて話し合います。 この作業は、運用環境で何かを設定する前に行う必要があります。
  • ライセンス要件を確認する: 製品ライセンスとユーザー ライセンスの要件を確実に理解します。 必要に応じて、より多くのライセンスを調達して割り当てます。
  • ユーザー ドキュメントを公開する: ユーザーが質問に回答し、期待を明確にするために必要な情報を公開します。 ユーザーが準備できるように、ガイダンス、コミュニケーション、トレーニングをユーザーに提供します。
  • DLP ポリシーを作成する: Microsoft Purview コンプライアンス ポータルで、各 DLP ポリシーを作成して設定します。 DLP ルールを設定するために以前に行ったすべての決定を参照します。
  • 初期テストを実行する: 初期テストのセットを実行して、すべてが正常に動作していることを確認します。 一部のサンプル データでテスト モードを使用して、ユーザーへの影響を最小限に抑えながら、すべてが期待どおりに動作するかどうかを確認します。 最初は Premium ワークスペースの小さなサブセットを使用します。 非運用テナントにアクセスできる場合は、それを使用することを検討します。
  • ユーザーのフィードバックを収集する: プロセスとユーザー エクスペリエンスに関するフィードバックを取得します。 混乱の領域、または機密情報の種類に関する予期しない結果、およびその他の技術的な問題を特定します。
  • 反復的なリリースを続行する: すべて含まれるまで Premium ワークスペースを DLP ポリシーに徐々に追加します。
  • 監視、調整、改良する: リソースを投資して、ポリシー一致アラートと監査ログを頻繁に確認します。 偽陽性を調査し、必要に応じてポリシーを調整します。

ヒント

これらのチェックリスト項目は、計画目的でまとめられています。 これらのチェックリスト項目の詳細については、この記事の前のセクションを参照してください。

初期ロールアウト以降のその他の手順については、「Defender for Cloud Apps for Power BI」を参照してください。

継続的な監視

実装が完了したら、使用に基づいて DLP ポリシーの監視、適用、調整に注意を向ける必要があります。

Power BI 管理者とセキュリティおよびコンプライアンス管理者は、随時共同作業を行う必要があります。 Power BI コンテンツの場合、監視対象ユーザーは次の 2 名です。

  • Power BI 管理者: DLP ルールが一致するたびに、Power BI アクティビティ ログのエントリが記録されます。 Power BI アクティビティ ログのエントリには、ユーザー、日付と時刻、項目名、ワークスペース、容量など、DLP イベントの詳細が記録されます。 また、ポリシー名、ルール名、重大度、一致した条件など、ポリシーに関する情報も含まれます。
  • セキュリティおよびコンプライアンス管理者: 組織のセキュリティおよびコンプライアンス管理者は、通常、Microsoft Purview のレポート、アラート、監査ログを使用します。

警告

Power BI の DLP ポリシーの監視は、DLP ログとアラートが生成されるまでに時間がかかるため、リアルタイムでは発生しません。 リアルタイムで適用することを目標とする場合は、「Defender for Cloud Apps for Power BI (リアルタイム ポリシー)」を参照してください。

チェックリスト - Power BI の DLP を監視する際の主な決定事項とアクションは次のとおりです。

  • ロールと責任を確認する: 必ず、どのアクションに対して誰が責任を負うのかを明確にします。 Power BI 管理者またはセキュリティ管理者が DLP の監視の一部の側面を直接担当する場合は、その管理者を教育し、コミュニケーションをとります。
  • アクティビティを確認するためのプロセスを作成または検証する: アクティビティ エクスプローラーを定期的に確認する必要性について、セキュリティ管理者とコンプライアンス管理者が明確に理解していることを確認します。
  • アラートを解決するためのプロセスを作成または検証する: セキュリティ管理者とコンプライアンス管理者が、開かれているアラートを調査して解決するプロセスを用意していることを確認します。

ヒント

監査の詳細については、「Power BI の情報保護とデータ損失防止の監査」を参照してください。

関連するコンテンツ

このシリーズの次の記事では、Power BI での Defender for Cloud Apps の使用について説明します。