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

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

• Power BI 管理者: 組織の Power BI 監視を担当する管理者。 Power BI 管理者は、情報セキュリティ チームやその他の関連チームと共同で作業する必要があります。
• センター オブ エクセレンス、IT、BI チーム: 組織内の Power BI の監視を担当するその他のチーム。 これらのチームは、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 ワークスペースに発行されたセマンティック モデル内の機密データを検出できます。

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

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 に焦点を当てます。

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 ポリシー ルールには、考慮すべき階層的な優先順位があります。 優先順位は、最初に発生したときに呼び出されるポリシーに影響します。

機密データの種類

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

秘密度ラベル

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

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

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

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

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

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

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

機密性の高い情報の種類

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

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

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

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

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

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

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

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

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

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

ユーザー通知

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ライセンスの要件

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

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

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

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

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

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

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

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

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

ユーザー サポート

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

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

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

実装とテストの概要

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

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

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

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

関連するコンテンツ

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