次の方法で共有

Power BI の実装計画: Power BI の情報保護

  • [アーティクル]

注意

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

この記事では、Power BI での情報保護の実装に関連する計画アクティビティについて説明します。 対象ユーザーは次のとおりです。

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

重要

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

ラベル付けと分類のアクティビティは、Power BI、さらにはデータ資産以外にも拡張されます。 この記事で説明する決定事項は、Power BI だけでなく、ファイルや電子メールを含む組織全体の資産にも適用されます。 Power BI でのデータ損失防止を成功させるために適切な組織上の決定を行うことが重要であるため、この記事ではラベル付けと分類全般に適用されるトピックについて説明します。

この記事には、秘密度ラベル構造の定義に関する入門ガイダンスも含まれています。 技術的には、秘密度ラベル構造は、Power BI で秘密度ラベルを実装するための前提条件です。 この記事に基本的な情報を含める目的は、関係しているものを理解するのに役立つからです。 組織内の情報保護を計画および実装するために、IT 部門と協力することが重要です。

秘密度ラベルの目的

Microsoft Purview Information Protection の秘密度ラベルの使用は、コンテンツの分類に関係します。 機密ラベルは、項目、ファイル、サイト、データ資産に適用するタグと同じように考えてください。

情報保護を使用すると、多くの利点があります。 コンテンツの分類とラベル付けは、組織が次を実施するのに役立ちます。

  • 機密データが存在する場所を理解する。
  • 外部および内部のコンプライアンス要件を追跡する。
  • 認可されていないユーザーからコンテンツを保護する。
  • 責任を持ってデータを処理する方法についてユーザーを教育する。
  • リアルタイム制御を実装して、データ漏えいのリスクを軽減する。

情報保護のその他のユース ケースについては、情報保護と DLP (一般的なユース ケース) に関するページを参照してください。

ヒント

Microsoft Purview Information Protection が製品であることに留意すると役立ちます。 秘密度ラベルは、その製品の特定の機能です。

秘密度ラベルは、クリア テキストの簡単な説明です。 概念的には、秘密度ラベルをタグのように考えることができます。 各項目 (Power BI サービスの Power BI セマンティック モデルなど) または各ファイル (Power BI Desktop ファイルなど) に割り当てることができるラベルは 1 つだけです。

ラベルには次の目的があります。

  • 分類: 秘密度レベルを説明するための分類を提供します。
  • ユーザーの教育と認識: ユーザーがコンテンツを適切に操作する方法を理解するのに役立ちます。
  • ポリシー: ポリシーと DLP を適用および強制するための基礎が形成されます。

Power BI 情報保護の前提条件

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

  • 現在の状態: 組織内の情報保護の現在の状態。 秘密度ラベルが Microsoft Office ファイルに既に使用されているかどうかを理解しておく必要があります。 この場合、Power BI を追加する作業の範囲は、組織に初めて情報保護を導入する場合よりもはるかに小さくなります。
  • 目標と要件: 組織で DLP を実装するための戦略的目標。 目標と要件を理解することは、実装作業のガイドとして役立ちます。

情報保護が組織で使用されていない場合、このセクションの残りの部分では、他のユーザーと共同作業して組織に情報保護を導入するのに役立つ情報を提供します。

組織内で情報保護が積極的に使用されている場合は、この記事を使用して前提条件が満たされていることを確認することをお勧めします。 秘密度ラベルが積極的に使用されている場合は、ロールアウト フェーズ 1 から 4 (次のセクション) のほとんどの (またはすべての) アクティビティが既に完了しています。

展開の段階

情報保護を実装およびテストするための段階的なロールアウト計画を策定することをお勧めします。 段階的なロールアウト計画の目的は、自分自身で取り組みを進めながら学習、調整、反復を行えるようにすることです。 利点は、情報保護が最終的に組織内のすべてのユーザーにロールアウトされるまで、初期段階 (変更の可能性が高い段階) に影響を受けるユーザーが少なくなる点です。

情報保護の導入は重要な取り組みです。 組織レベルの情報保護計画に関する記事で説明されているように、組織が Microsoft Office ドキュメントの情報保護を既に実装している場合、これらのタスクの多くは既に完了済みです。

このセクションでは、段階的なロールアウト計画に含めることが推奨されるフェーズの概要を示します。 どのようなことが予測されるかについて、感覚が得られます。 この記事の残りの部分では、Power BI に最も直接的に影響を与える重要な側面に関する、その他の意思決定基準について説明します。

フェーズ 1: 計画、決定、準備

最初のフェーズでは、計画、意思決定、準備アクティビティに焦点を当てます。 この記事の残りの部分のほとんどは、この最初のフェーズに焦点を当てています。

できるだけ早く、最初のテストがどこで行われるかを明確にします。 この選択は、最初に設定、発行、テストする場面に影響します。 最初のテストでは、非運用テナント (アクセス権がある場合) を使用できます。

ヒント

ほとんどの組織では、アクセスできるテナントは 1 つであるため、切り離した方法で新機能を確認するのは困難な場合があります。 個別の開発テナントまたはテスト テナントを持つ組織の場合は、最初のテスト フェーズに使用することをお勧めします。 テナントの管理の詳細と、試用版テナントを作成して新しい機能をテストする方法については、テナントのセットアップに関するページを参照してください。

フェーズ 2: サポート ユーザー リソースを設定する

2 番目のフェーズには、ユーザーをサポートするためのリソースを設定する手順が含まれています。 リソースには、データ分類と保護ポリシーおよびカスタム ヘルプ ページが含まれます。

ユーザー ドキュメントの一部を早期に公開することが重要です。 また、ユーザー サポート チームに早い段階で準備してもらうことも重要です。

フェーズ 3: ラベルを設定して発行する

3 番目のフェーズでは、秘密度ラベルの定義に重点を置きます。 すべての決定が行われた場合、設定は難しくなく、時間もかかりません。 秘密度ラベルは、Microsoft 365 管理センターの Microsoft Purview コンプライアンス ポータルで設定されます。

フェーズ 4: ラベル ポリシーを発行する

ラベルを使用するには、ラベル ポリシーの一部として発行する必要があります。 ラベル ポリシーは、特定のユーザーがラベルを使用できるようにします。 ラベル ポリシーは、Microsoft 365 管理センターの Microsoft Purview コンプライアンス ポータルで発行されます。

注意

ここまでのすべてが、Power BI の情報保護を実装するための前提条件です。

フェーズ 5: Power BI テナント設定を有効にする

Power BI 管理ポータルには、いくつかの情報保護テナント設定があります。 Power BI サービスで情報保護を有効にするために必要です。

重要

Microsoft Purview コンプライアンス ポータルでラベルを設定して発行した "後" で、テナント設定を設定する必要があります。

フェーズ 6: 初期テスト

6 番目のフェーズでは、初期テストを実行して、すべてが期待どおりに動作することを確認します。 初期テストのためには、実装チームに対してのみラベル ポリシーを発行する必要があります。

このフェーズでは、必ず次のテストを行ってください。

  • Microsoft Office ファイル
  • Power BI サービスの Power BI 項目
  • Power BI Desktop ファイル
  • Power BI サービスからのファイルのエクスポート
  • Teams サイトや SharePoint など、構成に含まれるその他のスコープ

Web ブラウザーと一般的に使用されるモバイル デバイスを使用して、機能とユーザー エクスペリエンスを確認してください。 それに応じてユーザー ドキュメントを更新します。

重要

秘密度ラベルを設定する権限が与えられているのは、チームの少数のメンバーだけであっても、すべてのユーザーがコンテンツに割り当てられているラベルを表示できます。 運用テナントを使用している場合、ユーザーは、Power BI サービスのワークスペース内の項目に割り当てられたラベルが表示される理由を疑問に思うかもしれません。 サポートと、ユーザーの質問に回答する準備を整えます。

フェーズ 7: ユーザーのフィードバックを収集する

このフェーズの目標は、重要なユーザーの少数のグループからフィードバックを取得することです。 フィードバックでは、混乱の領域、ラベル構造のギャップ、または技術的な問題を特定する必要があります。 また、ユーザー ドキュメントを改善する理由が見つかる場合もあります。

そのためには、フィードバックを提供する意思のある少数のユーザーにラベル ポリシーを発行 (または再発行) する必要があります。

ヒント

プロジェクト計画に十分な時間を織り込んでください。 ラベルとラベル ポリシー設定について、製品ドキュメントでは、変更を有効にするために 24 時間を割り当てることをお勧めしています。 この時間は、すべての変更が関連するサービスに反映されるようにするために必要です。

フェーズ 8: 反復的にリリースする

実装フェーズは通常、反復的なプロセスです。

多くの場合、最初の目的は、すべての Power BI コンテンツに秘密度ラベルが割り当てられている状態に到達することです。 この目的を達成するために、必須ラベル ポリシーまたは既定ラベル ポリシーを導入できます。 情報保護管理者 API を使用して、プログラムによって秘密度ラベルを設定または削除することもできます。

組織全体が含まれるまで、より多くのユーザー グループを徐々に含めることができます。 このプロセスでは、徐々に大きなユーザーのグループに対して、各ラベル ポリシーを再発行します。

このプロセス全体を通して、ユーザーがプロセスと期待される内容を理解できるように、ユーザーにガイダンス、コミュニケーション、トレーニングを提供することを優先してください。

フェーズ 9: 監視、監査、調整、統合

最初のロールアウト後に実行する手順は他にもあります。 情報保護アクティビティを監視し、時間の経過に伴って調整するプライマリ チームが必要です。 ラベルが適用されると、その有用性を評価し、調整が必要な部分を特定できるようになります。

情報保護の監査には多くの側面があります。 詳細については、Power BI の情報保護とデータ損失防止の監査に関するページを参照してください。

情報保護の設定に対する投資は、Microsoft Purview コンプライアンス ポータルで設定される Power BI の DLP ポリシーで使用できます。 DLP 機能の説明など、詳細については、Power BI のデータ損失防止に関するページを参照してください。

情報保護を使用して、Microsoft Defender for Cloud Apps でポリシーを作成することもできます。 役に立つ機能の説明など、詳細については、Defender for Cloud Apps for Power BI に関するページを参照してください。

チェックリスト - 情報保護のロールアウト フェーズを準備する際の主な決定事項とアクションは次のとおりです。

  • 段階的なロールアウト計画を作成する: ロールアウト計画のフェーズを定義します。 各フェーズの具体的な目標を明確にします。
  • テストを実行する場所を特定する: 最初のテストを実行できる場所を決定します。 ユーザーへの影響を最小限に抑えるには、可能であれば、非運用テナントを使用します。
  • プロジェクト計画を作成する: すべての主要なアクティビティ、推定タイムライン、責任者を含むプロジェクト計画を作成します。

秘密度ラベルの構造

秘密度ラベル構造は、Power BI で秘密度ラベルを実装するための前提条件です。 このセクションには、ラベル構造の作成に関与する場合に、関係項目を理解するのに役立つ基本的な情報が含まれています。

このセクションは、考えられるすべてのアプリケーションでの、考えられるすべての秘密度ラベルの考慮事項の完全な一覧ではありません。 代わりに、Power BI コンテンツの分類に直接影響を与える考慮事項とアクティビティに重点を置きます。 必ず他の利害関係者やシステム管理者と協力して、すべてのアプリケーションとユース ケースに適した意思決定を行ってください。

情報保護を実装するための基盤は、一連の秘密度ラベルから始まります。 最終的な目標は、ユーザーが操作できる明確で簡単な秘密度ラベルのセットを作成することです。

組織で使用される秘密度ラベル構造は、"ラベルの分類構造" を表します。 また、目的はデータの分類であるため、一般的に "データ種別分類構造" とも呼ばれます。 "スキーマ定義" と呼ばれることもあります。

標準または組み込みのラベルのセットはありません。 各組織は、ニーズに合わせてラベルのセットを定義およびカスタマイズする必要があります。 適切なラベルセットに到着するプロセスには、広範なコラボレーションが含まれます。 ラベルが目標と要件を満たしていることを確認するには、慎重な計画が必要です。 ラベルは Power BI コンテンツ以外にも適用されることに注意してください。

ヒント

ほとんどの組織では、まず Microsoft Office ファイルにラベルを割り当てます。 その後、Power BI の項目やファイルなど、他のコンテンツの分類に発展します。

ラベル構造には、次のものが含まれます。

  • ラベル: ラベルは階層を形成します。 各ラベルは、項目、ファイル、またはデータ資産の機密レベルを示します。 3 から 7 個のラベルを作成することをお勧めします。 ラベルが変更されることはほとんどありません。
  • サブラベル: サブラベルは、特定のラベル内の保護またはスコープのバリエーションを示します。 異なるラベル ポリシーに含めることで、サブラベルのスコープを特定のユーザー セットまたは特定のプロジェクトに関連するユーザーに設定できます。

ヒント

サブラベルは柔軟性を提供しますが、重要な要件を満たすためだけに適度に使用する必要があります。 サブラベルを作成すると、管理内容が増加します。 また、多すぎるオプションでユーザーを圧倒する可能性もあります。

ラベルは、最も機密性の低い分類から最も機密性の高い分類まで、階層を形成します。

Power BI コンテンツには、複数のラベルにまたがるデータが含まれている場合があります。 たとえば、セマンティック モデルには、製品在庫情報 (''一般内部使用'') と現在の四半期の売上高 (''制限あり'') が含まれている場合があります。 Power BI セマンティック モデルに割り当てるラベルを選択するときは、最も制限の厳しいラベルを適用するようにユーザーに教える必要があります。

ヒント

次のセクションでは、各ラベルを使用するタイミングに関するガイダンスをユーザーに提供できる "データ分類と保護ポリシー" について説明します。

重要

ラベルまたはサブラベルを割り当てても、Power BI サービス内の Power BI コンテンツへのアクセスには直接影響しません。 代わりに、ラベルには、ユーザーの行動をガイドできる便利なカテゴリが用意されています。 また、データ損失防止ポリシーも、割り当てられたラベルに基づくようにすることができます。 ただし、ファイルが暗号化されている場合を除き、Power BI コンテンツへのアクセスの管理方法については何も変更されません。 詳細については、「暗号化保護の使用」を参照してください。

最初のテスト フェーズを超えて作業を進めたら、ラベルを除去または削除するのは難しいため、作成するラベルを慎重に検討してください。 サブラベルは (必要に応じて) 特定のユーザーセットに使用できるため、ラベルよりも頻繁に変更できます。

ラベル構造を定義するためのベスト プラクティスをいくつか次に示します。

  • 直感的で明確な用語を使用する: ユーザーがデータを分類するときに選択する内容を確実に把握するために、明確さが重要です。 たとえば、"トップ シークレット" ラベルと "極秘" ラベル があるとあいまいです。
  • 論理的な階層的順序を作成する: ラベルの順序は、すべてが正常に機能するために重要です。 リスト内の最後のラベルが最も機密性が高い点に注意してください。 階層的な順序は、適切に選択された用語と組み合わせて、ユーザーが扱えるように論理的かつ直感的である必要があります。 明確な階層を使用すると、ポリシーの作成と保守も容易になります。
  • 組織全体に適用されるラベルを少数作成する: ユーザーが選択できるラベルが多すぎると、混乱を招きます。 また、ラベルの選択の精度が低下します。 初期セットには、少数のラベルのみを作成することをお勧めします。
  • 意味のある汎用名を使用する: ラベル名に業界用語や頭字語を使用しないでください。 たとえば、"個人を特定できる情報" という名前のラベルを作成するのではなく、"機密" や "極秘" のような名前を使用します。
  • 他の言語に簡単にローカライズできる用語を使用する: 複数の国/地域で事業を展開するグローバル組織では、他の言語に翻訳するときに混乱したり、あいまいになったりしないラベル用語を選択することが重要です。

ヒント

非常に具体的なラベルを多数計画している場合は、一歩引いてアプローチを再評価します。 複雑さが原因で、ユーザーの混乱、採用の減少、情報保護効果の低下につながる可能性があります。 最初の一連のラベルから始める (または既に持っているものを使用する) ことをお勧めします。 より多くの経験を積んだら、必要に応じてより具体的なものを追加することで、ラベルのセットを慎重に拡張します。

チェックリスト - 秘密度ラベルの構造を計画する場合、主な決定事項とアクションには次のものが含まれます。

  • 秘密度ラベルの初期セットを定義する: 3 から 7 個からなる秘密度ラベルの初期セットを作成します。 幅広いコンテンツに対して汎用的であることを確認します。 データの分類と保護ポリシーの完了に向けて作業する中で、最初のリストに繰り返し取り組みます。
  • サブラベルが必要かどうかを判断する: いずれかのラベルにサブラベルを使用する必要があるかどうかを決定します。
  • ラベル用語のローカライズを確認する: ラベルが他の言語に翻訳される場合は、ネイティブ スピーカーに、ローカライズされたラベルで意図した意味が伝わることを確認します。

秘密度ラベルのスコープ

秘密度ラベルのスコープで、ラベルの使用が制限されます。 Power BI を直接指定することはできませんが、さまざまなスコープにラベルを適用できます。 可能なスコープは次などです。

  • 項目 (Power BI サービスに発行された項目、ファイル、電子メールなど)
  • グループとサイト (Teams チャネルや SharePoint サイトなど)
  • スキーマ化されたデータ資産 (Purview Data Map に登録されたサポートされているソース)

重要

Power BI のスコープのみを使用して秘密度ラベルを定義することはできません。 特に Power BI に適用される設定はありますが、スコープはそうではありません。 "項目" のスコープは、Power BI サービスに使用されます。 秘密度ラベルは、一部の種類の DLP ポリシーを Power BI 専用に定義できるという点で、Power BI のデータ損失防止計画に関する記事で説明されている DLP ポリシーとは異なる方法で処理されます。 Power BI でデータ ソースからの秘密度ラベルの継承を使用する場合は、ラベル スコープに固有の要件があります。

秘密度ラベルに関連するイベントは、アクティビティ エクスプローラーに記録されます。 これらのイベントのログに記録された詳細情報は、スコープが広い場合に大幅に豊富になります。 また、幅広いアプリケーションやサービスでデータを保護する準備も整います。

秘密度ラベルの初期セットを定義する場合は、最初のラベルセットをすべてのスコープで使用できるようにすることを検討してください。 これは、さまざまなアプリケーションやサービスで異なるラベルが表示されると、ユーザーにとって混乱を招く可能性があるためです。 ただし、時間の経過と同時に、より具体的なサブラベルのユース ケースが見つかることがあります。 ただし、一貫性のあるシンプルな初期ラベルのセットから始める方が安全です。

ラベルのスコープは、ラベルの設定時に Microsoft Purview コンプライアンス ポータルで設定されます。

チェックリスト - ラベルのスコープを計画する場合、主な決定事項とアクションは次のとおりです。

  • ラベルのスコープを決定する: 最初の各ラベルをすべてのスコープに適用するかどうかを検討し、決定します。
  • すべての前提条件を確認する: 使用する各スコープに必要な前提条件と必要なセットアップ手順を調査します。

暗号化保護の使用

秘密度ラベルを使用した保護には、複数のオプションがあります。

  • 暗号化: 暗号化設定は、ファイルまたは電子メールに関連します。 たとえば、Power BI Desktop ファイルを暗号化できます。
  • マーキング: ヘッダー、フッター、ウォーターマークを指します。 マーキングは Microsoft Office ファイル向けに便利ですが、Power BI コンテンツには表示されません。

ヒント

通常、他のユーザーが "保護された" ラベルと呼ぶ場合、暗号化を指しています。 制限付きラベルや機密ラベルなどの上位レベルのラベルのみを暗号化するだけで十分な場合があります。

暗号化は、情報を暗号を使ってエンコードする方法です。 暗号化にはいくつかの重要な利点があります。

  • 保護されたファイルを開き、復号化し、読み取ることができるのは、認可されたユーザー (組織内の内部ユーザーなど) だけです。
  • 暗号化は、ファイルが組織外に送信された場合や名前が変更された場合でも、保護されたファイルと共に保持されます。
  • 暗号化設定は、元のラベル付けされたコンテンツから取得されます。 Power BI サービスのレポートの秘密度ラベルが "機密" になっているとします。 サポートされているエクスポート パスにエクスポートされた場合、ラベルはそのまま残り、エクスポートされたファイルに暗号化が適用されます。

Azure Rights Management Service (Azure RMS) は、暗号化によるファイル保護に使用されます。 Azure RMS の暗号化を使用するには、いくつかの重要な前提条件を満たしている必要があります。

重要

考慮すべき制限があります。オフライン ユーザー (インターネット接続なし) は、暗号化された Power BI Desktop ファイル (またはその他の種類の Azure RMS で保護されたファイル) を開くことができません。 Azure RMS は、ユーザーがファイルの内容を開き、復号化し、表示する権限を持っていることを同期的に確認する必要があるためです。

暗号化されたラベルは、ユーザーが作業している場所によって異なる方法で処理されます。

  • Power BI サービスの場合: 暗号化設定は、Power BI サービスのユーザー アクセスに直接影響しません。 標準の Power BI アクセス許可 (ワークスペース ロール、アプリのアクセス許可、共有アクセス許可など) によって、Power BI サービスのユーザー アクセスが制御されます。 秘密度ラベルは、Power BI サービス内のコンテンツへのアクセスには影響しません。
  • Power BI Desktop ファイル: 暗号化されたラベルを Power BI Desktop ファイルに割り当てることができます。 ラベルは、Power BI サービスからエクスポートされるときにも保持されます。 認可されたユーザーのみが、ファイルを開き、復号化し、表示できます。
  • エクスポートされたファイル: Power BI サービスからエクスポートされた Microsoft Excel、Microsoft PowerPoint、PDF ファイルは、暗号化保護を含む秘密度ラベルを保持します。 サポートされるファイル形式について、権限を持つユーザーのみが、ファイルを開き、復号化し、表示できます。

重要

ユーザーが、Power BI サービスとファイルの違いを理解することが重要です。これらは混同しやすいです。 ユーザーが相違点を理解できるように、FAQ ドキュメントと例を提供することをお勧めします。

保護された Power BI Desktop ファイルまたはエクスポートされたファイルを開くには、ユーザーが次の条件を満たす必要があります。

  • インターネット接続: ユーザーがインターネットに接続されている必要があります。 Azure RMS と通信するには、アクティブなインターネット接続が必要です。
  • RMS のアクセス許可: ユーザーは RMS アクセス許可を持っている必要があります。これは、ラベル ポリシー内ではなく、ラベル内で定義されます。 RMS のアクセス許可により、認可されたユーザーは、サポートされているファイル形式を復号化し、開き、表示することができます。
  • 許可されるユーザー: ユーザーまたはグループは、ラベル ポリシーで指定する必要があります。 通常、認可されたユーザーの割り当ては、ラベルを適用できるようにコンテンツ作成者と所有者にのみ必要です。 ただし、暗号化保護を使用する場合は、別の要件があります。 保護されたファイルを開く必要がある各ユーザーは、ラベル ポリシーで指定する必要があります。 この要件は、より多くのユーザーに情報保護ライセンスが必要になる可能性があることを意味します。

ヒント

ワークスペース管理者が自動的に適用された秘密度ラベルを上書きできるようにするテナント設定を使用すると、ワークスペース管理者は、ラベルに対して保護 (暗号化) が有効になっている場合でも、自動的に適用されたラベルを変更できます。 この機能は、ラベルが自動的に割り当てられたり継承されたりしたとき、ワークスペース管理者が認可されたユーザーでない場合に特に役立ちます。

ラベルの保護は、ラベルを設定するときに Microsoft Purview コンプライアンス ポータルで設定されます。

チェックリスト - ラベル暗号化の使用を計画する場合、主な決定事項とアクションは次のとおりです。

  • 暗号化するラベルを決定する: 秘密度ラベルごとに、暗号化する (保護する) かどうかを決定します。 関連する制限事項を慎重に検討してください。
  • 各ラベルの RMS アクセス許可を特定する: 暗号化されたファイルにアクセスして操作するためのユーザーアクセス許可を決定します。 各秘密度ラベルでユーザーとグループのマッピングを作成し、計画プロセスに役立てます。
  • RMS 暗号化の前提条件を確認して対処する: Azure RMS 暗号化を使用するための技術的な前提条件が満たされていることを確認します。
  • 暗号化の徹底的なテストを計画する: Office ファイルと Power BI ファイルに違いがあるため、徹底的なテスト フェーズにコミットしてください。
  • ユーザー ドキュメントとトレーニングに含める: 暗号化された秘密度ラベルが割り当てられているファイルに対してユーザーが予期する必要があることに関するガイダンスとトレーニングをドキュメントに含めてください。
  • サポートを使用して知識の移転を行う: サポート チームと知識移転セッションを実施するための具体的な計画を立ててください。 暗号化は複雑なため、ユーザーから質問を受ける可能性があります。

データ ソースからのラベルの継承

サポートされているデータ ソース (Azure Synapse Analytics、Azure SQL Database、Excel ファイルなど) からデータをインポートする場合、Power BI セマンティック モデルでは、必要に応じて、ソース データに適用される秘密度ラベルを継承できます。 継承は、次の点で役立ちます。

  • ラベル付けの一貫性を高める。
  • ラベルを割り当てる際のユーザーの労力を減らす。
  • ラベルが付けられなかったためにユーザーが機密データにアクセスして、認可されていないユーザーと共有するリスクが軽減される。

ヒント

秘密度ラベルの継承には 2 種類あります。 "ダウンストリーム継承" とは、Power BI セマンティック モデルからラベルを自動的に継承するダウンストリーム項目 (レポートなど) を指します。 ただし、このセクションでは、アップストリーム継承に焦点を当てています。 アップストリーム継承とは、セマンティック モデルより上流にあるデータ ソースからラベルを継承する Power BI セマンティック モデルを指します。

"機密" の秘密度ラベルに対する組織の実用的定義に財務口座番号が含まれる例を考えてみましょう。 財務口座番号は Azure SQL データベースに格納されているため、そのソースには "機密" の秘密度ラベルが割り当てられています。 Azure SQL Database のデータが Power BI にインポートされる場合、セマンティック モデルにラベルを継承することが意図されます。

さまざまな方法で、サポートされているデータ ソースに秘密度ラベルを割り当てることができます。

  • データの検出と分類: サポートされているデータベースをスキャンして、機密データを含む可能性のある列を識別できます。 スキャン結果に基づいて、ラベルの推奨事項の一部またはすべてを適用できます。 データの検出と分類は、Azure SQL Database、Azure SQL Managed Instance、Azure Synapse Analytics などのデータベースについてサポートされています。 SQL データの検出と分類は、オンプレミスの SQL Server データベースについてサポートされています。
  • 手動割り当て: Excel ファイルに秘密度ラベルを割り当てることができます。 また、Azure SQL Database または SQL Server のデータベース列にラベルを手動で割り当てることもできます。
  • Microsoft Purview での自動ラベル付け: 秘密度ラベルは、Microsoft Purview データ マップに資産として登録されたサポートされているデータ ソースに適用できます。

警告

データ ソースに秘密度ラベルを割り当てる方法の詳細については、この記事では説明しません。 Power BI での継承でサポートされる対象に関して、技術的な機能は進化しています。 目標、使いやすさ、機能が要件を満たしているかどうかを確認するために、技術的な概念実証を実施することをお勧めします。

継承は、power BI の テナント設定でデータ ソースからデータへの Apply 秘密度ラベルを有効にした場合にのみ発生。 テナント設定の詳細については、この記事の後半の「「Power BI のテナント設定」セクションを参照してください。

ヒント

継承の動作を理解する必要があります。 テスト計画には、さまざまな状況を必ず含めてください。

チェックリスト - データ ソースからのラベルの継承を計画する場合、主な決定事項とアクションは次のとおりです。

  • Power BI でデータ ソースからラベルを継承するかどうかを決定する: Power BI でこれらのラベルを継承するかどうかを決定します。 テナント設定を有効にして、この機能を許可することを計画します。
  • 技術的な前提条件を確認する: 秘密度ラベルをデータ ソースに割り当てるために追加の手順を実行する必要があるかどうかを判断します。
  • ラベル継承機能をテストする: 技術的な概念実証を完了して、継承の動作をテストします。 さまざまな状況で、この機能が期待どおりに動作することを確認します。
  • ユーザー ドキュメントに含める: ラベルの継承に関する情報が、ユーザーに提供されるガイダンスに追加されていることを確認します。 ユーザー ドキュメントに現実的な例を含めます。

発行されたラベル ポリシー

秘密度ラベルを定義した後、ラベルを 1 つ以上の "ラベル ポリシー" に追加できます。 ラベル ポリシーとは、ラベルを使用できるようにラベルを発行する方法です。 これは、認可されたユーザーのセットで使用できるラベルを定義します。 既定ラベルや必須ラベルなど、他の設定もあります。

複数のラベル ポリシーを使用すると、さまざまなユーザー セットをターゲットにする必要がある場合に役立ちます。 秘密度ラベルを 1 回定義し、1 つ以上のラベル ポリシーに含めることができます。

ヒント

秘密度ラベルは、ラベルを含むラベル ポリシーが Microsoft Purview コンプライアンス ポータルで発行されるまで使用できません。

認可されたユーザーとグループ

ラベル ポリシーを作成するときは、1 つ以上のユーザーまたはグループを選択する必要があります。 ラベル ポリシーによって、ラベルを使用できるユーザーが決まります。 これにより、ユーザーは、Power BI Desktop ファイル、Excel ファイル、Power BI サービスに発行された項目など、特定のコンテンツにそのラベルを割り当てることができます。

認可されたユーザーとグループは、できるだけシンプルに保つことをお勧めします。 主要なラベルをすべてのユーザーに公開することをお勧めします。 サブラベルをユーザーのサブセットに割り当てるまたはスコープを設定するのが適切な場合があります。

可能な限り、個人ではなくグループを割り当てることをお勧めします。 グループを使用すると、ポリシーの管理が簡単になり、再発行する必要がある頻度が減ります。

警告

ラベルに対して認可されたユーザーとグループは、保護された (暗号化された) ラベルに対して Azure RMS に割り当てられているユーザーとは異なります。 ユーザーが暗号化されたファイルを開くときに問題が発生した場合は、暗号化に関する特定のユーザーとグループのアクセス許可を調べます (ラベル ポリシー内ではなく、ラベル構成内で設定されています)。 ほとんどの場合、同じユーザーを両方に割り当てることをお勧めします。 この一貫性により、混乱を回避し、サポート チケットを減らすことができます。

認可されたユーザーとグループは、ラベル ポリシーの発行時に Microsoft Purview コンプライアンス ポータルで設定されます。

チェックリスト - ラベル ポリシーで認可されたユーザーとグループを計画する場合、主な決定事項とアクションは次のとおりです。

  • すべてのユーザーに適用されるラベルを決定する: すべてのユーザーが使用できる秘密度ラベルについて話し合い、決定します。
  • ユーザーのサブセットに適用されるサブラベルを決定する: 特定のユーザーまたはグループのセットでのみ使用できるサブラベルがあるかどうかを検討し、決定します。
  • 新しいグループが必要かどうかを特定する: 承認されたユーザーとグループをサポートするために、新しい Microsoft Entra ID グループを作成する必要があるかどうかを判断します。
  • 計画ドキュメントを作成する: 認可されたユーザーの秘密度ラベルへのマッピングが複雑な場合は、ラベル ポリシーごとにユーザーとグループのマッピングを作成します。

Power BI コンテンツの既定ラベル

ラベル ポリシーを作成するときは、既定ラベルを選択できます。 たとえば、一般内部使用ラベルを既定ラベルとして設定できます。 この設定は、Power BI Desktop または Power BI サービスで作成された新しい Power BI 項目に影響します。

既定ラベルは、Power BI コンテンツ専用のラベル ポリシーで設定できます。これは、他の項目とは別です。 ほとんどの情報保護の決定と設定は、より広範に適用されます。 ただし、既定ラベル設定 (および次に説明する必須ラベル設定) は、Power BI にのみ適用されます。

ヒント

さまざまな既定ラベル (Power BI と Power BI 以外のコンテンツ向け) を設定できますが、それがユーザーに最適なオプションかどうかを検討してください。

ラベル ポリシーの発行 "後" に、作成または編集されたコンテンツに新しい既定ラベル ポリシーが適用されることを理解しておくことが重要です。 既定ラベルを既存のコンテンツにさかのぼって割り当てることはありません。 Power BI 管理者は、情報保護 API を使用して秘密度ラベルを一括で設定し、既存のコンテンツが既定の秘密度ラベルに割り当てられていることを確認できます。

既定ラベル オプションは、ラベル ポリシーの発行時に Microsoft Purview コンプライアンス ポータルで設定されます。

チェックリスト - Power BI コンテンツの既定ラベルを適用するかどうかを計画する場合、主な決定事項とアクションには次のものが含まれます。

  • 既定ラベルを指定するかどうかを決定する: 既定ラベルが適切かどうかを検討し、決定します。 その場合は、既定として最適なラベルを決定します。
  • ユーザー ドキュメントに含める: 必要に応じて、既定ラベルに関する情報がユーザーに提供されるガイダンスに記載されていることを確認します。 目標は、既定ラベルが適切かどうか、または変更する必要があるかどうかを判断する方法をユーザーが理解することです。

Power BI コンテンツの必須ラベルの適用

データ分類は、一般的な規制要件です。 この要件を満たすために、ユーザーにすべての Power BI コンテンツにラベルを付けることを要求できます。 この必須のラベル付け要件は、ユーザーが Power BI コンテンツを作成または編集するときに有効になります。

必須ラベル、既定ラベル (前のセクションで説明)、またはその両方を実装することを選択できます。 次のポイントについて検討してください。

  • 必須ラベル ポリシーを使用すると、ラベルが空でなくなります
  • 必須ラベル ポリシーでは、ユーザーはラベルの内容を選択する必要があります
  • 必須ラベル ポリシーを使用すると、ユーザーはラベルを完全に削除できなくなります
  • ユーザーがアクションを実行する必要がないため、既定ラベル ポリシーの方が介入が少なくなります
  • 既定ラベル ポリシーを使用すると、ユーザーが明示的に選択を行わなかったため、誤ってラベルが付いたコンテンツが発生する可能性があります
  • 既定ラベル ポリシーと必須ラベル ポリシーの両方を有効にすると、補完的な利点が得られます

ヒント

必須ラベルを実装する場合は、既定ラベルも実装することをお勧めします。

Power BI コンテンツ専用の必須ラベル ポリシーを設定できます。 ほとんどの情報保護の設定は、より広範に適用されます。 ただし、必須ラベル設定 (および既定ラベル設定) は、特に Power BI に適用されます。

ヒント

必須ラベル ポリシーは、サービス プリンシパルまたは API には適用されません。

必須ラベル オプションは、ラベル ポリシーの発行時に Microsoft Purview コンプライアンス ポータルで設定されます。

チェックリスト - Power BI コンテンツの必須ラベル付けが必要かどうかを計画する場合、主な決定事項とアクションには次のものが含まれます。

  • ラベルを必須にするかどうかを決定する: コンプライアンス上の理由から必須ラベルが必要かどうかを検討し、決定します。
  • ユーザー ドキュメントに含める: 必要に応じて、必須ラベルに関する情報が、ユーザーに提供されるガイダンスに追加されていることを確認します。 目標は、予期すべきことをユーザーが理解することです。

ライセンスの要件

秘密度ラベルを操作するには、特定のライセンスを設定する必要があります。

次の場合、Microsoft Purview 情報保護ライセンスが必要です。

  • 管理者: ラベルの設定、管理、監視を行う管理者。
  • ユーザー: コンテンツにラベルを適用する責任を負うコンテンツ作成者と所有者。 ユーザーには、保護された (暗号化された) ファイルを復号化し、開き、表示する必要があるユーザーも含まれます。

これらの機能は、Microsoft 365 E5 などのライセンス スイートに含まれているため、既に保持している可能性があります。 または、Microsoft 365 E5 Compliance 機能をスタンドアロン ライセンスとして購入することもできます。

Power BI サービスまたは Power BI Desktop で秘密度ラベルを適用および管理するユーザーには、Power BI Pro または Premium Per User (PPU) ライセンスも必要です。

ヒント

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

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

  • 製品のライセンス要件を確認する: すべてのライセンス要件を確認してください。
  • ユーザー ライセンス要件を確認する: ラベルを割り当てる予定のすべてのユーザーに、Power BI Pro または PPU ライセンスがあることを確認します。
  • 追加のライセンスを調達する: 必要に応じて、ライセンスをさらに購入して、使用する機能のロックを解除します。
  • ライセンスを割り当てる: 秘密度ラベルを割り当て、更新、管理を行う各ユーザーにライセンスを割り当てます。 暗号化されたファイルを操作する各ユーザーにライセンスを割り当てます。

Power BI テナントの設定

情報保護に関連する Power BI テナント設定がいくつかあります。

重要

情報保護の Power BI テナント設定は、すべての前提条件が満たされるまで設定しないでください。 ラベルとラベル ポリシーは、Microsoft Purview コンプライアンス ポータルで設定して発行する必要があります。 この時点までは、まだ意思決定プロセスです。 テナント設定を設定する前に、まず、ユーザーのサブセットで機能をテストする方法に関するプロセスを決定する必要があります。 次に、段階的なロールアウトを行う方法を決定できます。

ラベルを適用できるユーザー

Power BI コンテンツに秘密度ラベルを適用できるユーザーを決定する必要があります。 この決定により、コンテンツの秘密度ラベルを適用するように Allow ユーザー テナント設定を設定する方法が決まります。

典型的には、通常のワークフロー中にラベルを割り当てるコンテンツ作成者または所有者です。 最も簡単な方法は、このテナント設定を有効にして、すべての Power BI ユーザーがラベルを適用できるようにすることです。 この場合、標準のワークスペース ロールによって、Power BI サービス内の項目を編集できるユーザー (ラベルの適用を含む) が決定されます。 アクティビティ ログを使用して、ユーザーがラベルを割り当てたり変更したりするタイミングを追跡できます。

データ ソースからのラベル

Power BI の上流にある、サポートされているデータ ソースから秘密度ラベルを継承するかどうかを決定する必要があります。 たとえば、Azure SQL Database の列が "機密" の秘密度ラベルで定義されている場合、そのソースからデータをインポートする Power BI セマンティック モデルはそのラベルを継承します。

アップストリーム データ ソースからの継承を有効にする場合は、 データ ソースからの秘密度ラベルを Power BI のデータに設定します テナント設定。 データ ソース ラベルの継承を有効にすることを計画し、一貫性を高め、労力を削減することをお勧めします。

ダウンストリーム コンテンツのラベル

秘密度ラベルをダウンストリーム コンテンツに継承するかどうかを決定する必要があります。 たとえば、Power BI セマンティック モデルに "機密" の秘密度ラベルがある場合、すべてのダウンストリーム レポートはセマンティック モデルからこのラベルを継承します。

ダウンストリーム コンテンツによる継承を有効にする場合は、 ダウンストリーム コンテンツに秘密度ラベルを自動的に適用する テナント設定を設定します。 ダウンストリーム コンテンツの継承を有効にすることを計画し、一貫性を高め、労力を削減することをお勧めします。

ワークスペース管理者のオーバーライド

この設定は、自動的に適用されたラベル (既定ラベルが適用されたときや、ラベルが自動的に継承される場合など) に適用されます。 ラベルに保護設定がある場合、Power BI では、認可されたユーザーのみがラベルを変更できます。 この設定により、ワークスペース管理者は、ラベルに保護設定がある場合でも、自動的に適用されたラベルを変更できます。

ラベルの更新を許可する場合は、 Allow ワークスペース管理者が、自動的に適用される秘密度ラベル テナント設定をオーバーライドするように設定します。 この設定は組織全体 (個別のグループではない) に対して適用されます。 これにより、ワークスペース管理者は、自動的に適用されたラベルを変更できます。

Power BI ワークスペース管理者にラベルの更新を許可することを検討することをお勧めします。 アクティビティ ログを使用して、ラベルの割り当てまたは変更を追跡できます。

保護されたコンテンツの共有を禁止する

保護された (暗号化された) コンテンツを組織内のすべてのユーザーと共有できるかどうかを決定する必要があります。

保護されたコンテンツの共有を禁止する場合は、 保護されたラベルを持つコンテンツを組織内のすべてのユーザーとのリンクを介して共有されないように設定 テナント設定。 この設定は組織全体 (個別のグループではない) に対して適用されます。

このテナント設定を有効にして、保護されたコンテンツの共有を禁止することを強くお勧めします。 有効にすると、(暗号化が定義されているラベルによって定義される) 機密性の高いコンテンツに対する組織全体との共有操作が禁止されます。 この設定を有効にすると、データ漏えいの可能性を減らすことができます。

重要

組織内のすべてのユーザーにアクセス権を与える共有可能なリンクを許可するという名前の類似のテナント設定があります。 名前は似ていますが、目的は異なります。 秘密度ラベルに関係なく、組織全体の共有リンクを作成できるグループを定義します。 ほとんどの場合、この機能は組織で制限することをお勧めします。 詳細については、レポート コンシューマーのセキュリティ プランに関する記事を参照してください。

サポートされているエクスポート ファイルの種類

Power BI 管理ポータルには、多くのエクスポートと共有のテナント設定があります。 ほとんどの状況では、ユーザーの生産性を制限しないように、データをエクスポートする機能をすべての (またはほとんどの) ユーザーが使用できるようにすることをお勧めします。

ただし、規制の厳しい業界では、出力形式に対して情報保護を適用できない場合にエクスポートを制限する必要がある場合があります。 Power BI サービスに適用される秘密度ラベルは、サポートされているファイル パスにエクスポートされるとき、コンテンツに従います。 これには、Excel、PowerPoint、PDF、Power BI Desktop ファイルが含まれます。 秘密度ラベルはエクスポートされたファイルと共に保持されるため、これらのサポートされているファイル形式では保護の利点 (認可されていないユーザーがファイルを開くことができない暗号化) が保持されます。

警告

Power BI Desktop から PDF ファイルにエクスポートする場合、エクスポートされたファイルの保護は保持されません。 最大の情報保護を実現するために、Power BI サービスからエクスポートするようにコンテンツ作成者を教育することをお勧めします。

すべてのエクスポート形式で情報保護がサポートされているわけではありません。 Power BI テナント設定では、.csv、.xml、.mhtml、.png ファイル (ExportToFile API を使用する場合に使用可能) などのサポートされていない形式が無効になる場合があります。

ヒント

エクスポート機能は、特定の規制要件を満たす必要がある場合にのみ制限することをお勧めします。 一般的なシナリオでは、Power BI アクティビティ ログを使用して、エクスポートを実行しているユーザーを特定することをお勧めします。 その後、より効率的で安全な代替手段について、これらのユーザーに教えることができます。

チェックリスト - Power BI 管理ポータルでテナント設定を設定する方法を計画する場合、主な決定事項とアクションは次のとおりです。

  • 秘密度ラベルを適用できるユーザーを決定する: 秘密度ラベルをすべてのユーザーが (標準の Power BI セキュリティに基づいて) Power BI コンテンツに割り当てることができるか、または特定のユーザー グループによってのみ割り当てることができるかを検討して決定します。
  • 上流のデータ ソースからラベルを継承する必要があるかどうかを判断する: データ ソースを使用する Power BI コンテンツにデータ ソースのラベルを自動的に適用するかどうかを検討し、決定します。
  • ラベルをダウンストリーム項目に継承するかどうかを決定する: 既存の Power BI セマンティック モデルに割り当てられたラベルを関連するコンテンツに自動的に適用するかどうかを検討し、決定します。
  • Power BI ワークスペース管理者がラベルをオーバーライドできるかどうかを決定する: ワークスペース管理者が自動的に割り当てられた保護されたラベルを変更できるようにするのが適切かどうかを検討し、決定します。
  • 保護されたコンテンツを組織全体と共有できるかどうかを判断する: 保護された (暗号化された) ラベルが Power BI サービス内の項目に割り当てられているときに、"組織内のユーザー" 向けの共有リンクを作成できるかどうかを検討し、決定します。
  • 有効にするエクスポート形式を決定する: 使用できるエクスポート形式に影響を与える規制要件を特定します。 ユーザーが Power BI サービスのすべてのエクスポート形式を使用できるかどうかを検討し、決定します。 エクスポート形式で情報保護がサポートされていない場合に、テナント設定で特定の形式を無効にする必要があるかどうかを判断します。

データの分類と保護のポリシー

まず、ラベル構造を設定し、ラベル ポリシーを発行する必要があります。 ただし、組織がデータの分類と保護を成功させるためには、他にも対応する事項があります。 特定のラベルに割り当てられているコンテンツに対し、実行できることとできないことについて、ユーザーにガイダンスを提供することが重要です。 ここで、"データ分類と保護ポリシー" が役立ちます。 ラベルのガイドラインとして考えることができます。

注意

データ分類と保護ポリシーは、内部ガバナンス ポリシーです。 別の名称を選択することもできます。 重要なのは、ラベルを効果的に使用する "方法" をユーザーが把握できるように作成し、ユーザーに提供するドキュメントであるということです。 "ラベル ポリシー" は Microsoft Purview コンプライアンス ポータル内の特定のページであるため、同じ名前で内部ガバナンス ポリシーを呼ばないようにしてください。

意思決定プロセス中は、データ分類と保護ポリシーを繰り返し作成することをお勧めします。 これは、秘密度ラベルを設定するときに、すべてが明確に定義されていることを意味します。

データ分類と保護ポリシーに含める可能性がある重要な情報の一部を次に示します。

  • ラベルの説明: ラベル名を超えて、ラベルの完全な説明を提供します。 説明は明確でありながら簡潔にする必要があります。 以下に説明の例を示します。
    • "一般内部使用" - プライベート、内部、ビジネス データ用
    • "制限付き" - 漏えいした場合に損害を引き起こす、または規制またはコンプライアンス要件の対象である機密性の高いビジネス データ用
  • 例: ラベルを使用するタイミングを説明するのに役立つ例を提供します。 次に例をいくつか示します。
    • "一般内部使用" - ほとんどの内部コミュニケーション、機密ではないサポート データ、アンケートの回答、レビュー、評価、不正確な場所データ
    • "制限付き" - 個人を特定できる情報 (PII) データ (名前、住所、電話、電子メール、政府 ID 番号、人種、民族など)。 ベンダーとパートナーの契約、非公開の財務データ、従業員、人事 (HR) データが含まれます。 また、財産的価値のある情報、知的財産、正確な位置情報も含まれます。
  • 必要なラベル: 新しいコンテンツと変更されたコンテンツすべてにラベルを割り当てる必要があるかどうかを説明します。
  • 既定ラベル: このラベルが、新しいコンテンツに自動的に適用される既定のラベルであるかどうかを説明します。
  • アクセス制限: 内部ユーザーまたは外部ユーザーがこのラベルに割り当てられたコンテンツを表示できるかどうかを明確にする追加情報です。 次に例をいくつか示します。
    • 内部ユーザー、外部ユーザー、有効な機密保持契約 (NDA) を持つ第三者を含むすべてのユーザーは、この情報にアクセスできます。
    • 内部ユーザーのみが、この情報アクセスできます。 NDA または機密保持契約の状態に関係なく、パートナー、ベンダー、請負業者、または第三者は該当しません。
    • 情報への内部アクセスは、ジョブ ロールの認可に基づいています。
  • 暗号化の要件: 保存時と転送中にデータを暗号化する必要があるかどうかを説明します。 この情報は、秘密度ラベルの設定方法に関連し、ファイル (RMS) 暗号化に実装できる保護ポリシーに影響します。
  • ダウンロードの許可またはオフライン アクセス: オフライン アクセスが許可されるかどうかを説明します。 また、組織のデバイスまたは個人のデバイスにダウンロードを許可するかどうかを定義することもできます。
  • 例外を要求する方法: ユーザーが標準ポリシーに対して例外を要求できるかどうかを説明し、その方法を説明します。
  • 監査の頻度: コンプライアンス レビューの頻度を指定します。 機密性の高いラベルには、より頻繁で徹底的な監査プロセスが必要です。
  • その他のメタデータ:データ ポリシーには、ポリシー所有者、承認者、有効日など、より多くのメタデータが必要です。

ヒント

データ分類と保護ポリシーを作成するときは、ユーザーにとって簡単な参照情報にすることに重点を置きます。 可能な限り短く明確にする必要があります。 複雑すぎる場合、ユーザーが理解するために常に時間を割くとは限りません。

データ分類や保護ポリシーなど、ポリシーの実装を自動化する 1 つの方法は、Microsoft Entra の利用規約を使用することです。 利用規約ポリシーが設定されている場合、ユーザーは、初めて Power BI サービスにアクセスすることを許可される前に、ポリシーを確認する必要があります。 また、12 か月ごとに、定期的に再び同意するように求めることもできます。

チェックリスト - 秘密度ラベルの使用に対する想定を管理する内部ポリシーを計画する場合、主な決定事項とアクションは次のとおりです。

  • データ分類と保護ポリシーを作成する: 構造内の秘密度ラベルごとに、一元化されたポリシー ドキュメントを作成します。 このドキュメントでは、各ラベルに割り当てられているコンテンツで実行できることとできないことを定義する必要があります。
  • データ分類と保護ポリシーに関する合意を得る: 組織したチームの必要なすべてのユーザーが、その規定に同意していることを確認します。
  • ポリシーの例外を処理する方法を検討する: 高度な分散型の組織では、例外が発生する可能性があるかどうかを検討する必要があります。 標準化されたデータ分類と保護ポリシーを使用することをお勧めしますが、新しい要求が行われたときに例外に対処する方法を決定します。
  • 内部ポリシーの場所を検討する: データ分類と保護ポリシーを公開する場所について考えます。 すべてのユーザーが簡単にアクセスできることを確認します。 ラベル ポリシーを発行するときに、カスタム ヘルプ ページに含めることを計画します。

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

情報保護機能をロールアウトする前に、ユーザー向けのガイダンス ドキュメントを作成して発行することをお勧めします。 ドキュメントの目的は、シームレスなユーザー エクスペリエンスを実現することです。 また、ユーザー向けのガイダンスを準備することで、すべてを考慮したかどうかを確認するのにも役立ちます。

秘密度ラベルのカスタム ヘルプ ページの一部としてガイダンスを発行できます。 一元化されたポータルの SharePoint ページまたは Wiki ページは、保守が容易になるため有用です。 共有ライブラリまたは Teams サイトにアップロードされたドキュメントも適切なアプローチです。 カスタム ヘルプ ページの URL は、ラベル ポリシーを発行するときに Microsoft Purview コンプライアンス ポータルで指定されます。

ヒント

カスタム ヘルプ ページは重要なリソースです。 リンクを、さまざまなアプリケーションやサービスで利用可能にします。

ユーザー ドキュメントには、前に説明したデータ分類と保護ポリシーが含まれている必要があります。 その内部ポリシーは、すべてのユーザーを対象とします。 関心のあるユーザーには、他のユーザーによって割り当てられたラベルの影響を理解する必要がある、コンテンツ作成者とコンシューマーが含まれます。

データの分類と保護ポリシーに加えて、コンテンツ作成者と所有者に対して次に関するガイダンスを準備することをお勧めします。

  • ラベルの表示: 各ラベルの意味に関する情報。 各ラベルをデータ分類と保護ポリシーと関連付けます。
  • ラベルの割り当て: ラベルを割り当てて管理する方法に関するガイダンス。 必須ラベル、既定ラベル、ラベルの継承のしくみなど、知っておく必要がある情報を含めます。
  • ワークフロー: 通常のワークフローの一部としてラベルを割り当てて確認する方法に関する提案。 開発が始まるとすぐに Power BI Desktop でラベルを割り当てることができます。これにより、開発プロセス中に元の Power BI Desktop ファイルを保護します。
  • 状況通知: ユーザーが受け取る可能性があるシステム生成通知に関する認識。 たとえば、SharePoint サイトは特定の秘密度ラベルに割り当てられますが、個々のファイルはより機密性のある (高い) ラベルに割り当てられます。 上位のラベルを割り当てたユーザーは、ファイルに割り当てられたラベルが保存されているサイトと互換性がないという電子メール通知を受け取ります。

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

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

ヒント

一部の規制要件には、特定のトレーニング コンポーネントが含まれます。

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

  • 含める情報を特定する: 組織に代わってデータを保護することに関して、関連するすべての対象ユーザーがユーザーに期待される内容を理解できるように、どのような情報を含める必要があるかを決定します。
  • カスタム ヘルプ ページを発行する: カスタム ヘルプ ページを作成して発行します。 ラベル付けのガイダンスを FAQ と例の形式で含めます。 データ分類と保護ポリシーにアクセスするためのリンクを含めます。
  • データ分類と保護ポリシーを発行する: 各ラベルに割り当てられているコンテンツで実行できることとできないことを定義するポリシー ドキュメントを発行します。
  • 特定のトレーニングが必要かどうかを判断する: ユーザー トレーニングを作成または更新して、特に規制要件がある場合に役立つ情報を含めます。

ユーザー サポート

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

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

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

  • ユーザー サポートを提供するユーザーを特定する: ロールと責任を定義するときは、情報保護に関連する問題に対してユーザーがヘルプを受ける方法を必ず含めてください。
  • ユーザー サポート チームの準備を確実に整える: ドキュメントを作成し、知識移転セッションを実施して、ヘルプ デスクが情報保護をサポートする準備を確実に整えます。 暗号化保護など、ユーザーを混乱させる可能性のある複雑な側面を強調します。
  • チーム間のコミュニケーション: サポート チームだけでなく、Power BI 管理者やセンター オブ エクセレンスと共に、プロセスと期待について話し合います。 Power BI ユーザーからの潜在的な質問に対して、関係者全員の準備が整っていることを確認します。

実装の概要

決定が行われ、前提条件が満たされたら、段階的なロールアウト計画に従って情報保護の実装を開始します。

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

チェックリスト - 情報保護を実装する場合、主な決定事項とアクションは次のとおりです。

  • 現在の状態と目標を確認する: 組織内の情報保護の現在の状態を明確にしてください。 情報保護を実装するためのすべての目標と要件を明確にして積極的に使用し、意思決定プロセスを推進する必要があります。
  • 決定を下す: 必要なすべての決定事項を確認し、話し合います。 この作業は、運用環境で何かを設定する前に行う必要があります。
  • ライセンス要件を確認する: 製品ライセンスとユーザー ライセンスの要件を確実に理解します。 必要に応じて、より多くのライセンスを調達して割り当てます。
  • ユーザー ドキュメントを発行する: データ分類と保護ポリシーを発行します。 ユーザーが必要とする関連情報を含むカスタム ヘルプ ページを作成します。
  • サポート チームを準備する: サポート チームがユーザーからの質問に確実に対応できるように、知識移転セッションを実施します。
  • 秘密度ラベルを作成する: Microsoft Purview コンプライアンス ポータルの各秘密度ラベルを設定します。
  • 秘密度ラベル ポリシーを発行する: Microsoft Purview コンプライアンス ポータルでラベル ポリシーを作成して発行します。 まず、少数のユーザー グループでテストします。
  • Power BI テナント設定を設定する: Power BI 管理ポータルで、情報保護テナント設定を設定します。
  • 初期テストを実行する: 初期テストのセットを実行して、すべてが正常に動作していることを確認します。 初期テストに非運用テナントを使用します (使用可能な場合)。
  • ユーザーのフィードバックを収集する: 機能をテストするユーザーのごく一部にラベル ポリシーを発行します。 プロセスとユーザー エクスペリエンスに関するフィードバックを取得します。
  • 反復的なリリースを続行する: ラベル ポリシーを他のユーザー グループに発行します。 組織全体が含まれるまで、より多くのユーザー グループをオンボードします。

ヒント

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

継続的な監視

実装が完了したら、機密ラベルの監視と調整に注意を向ける必要があります。

Power BI 管理者とセキュリティおよびコンプライアンス管理者は、随時共同作業を行う必要があります。 Power BI コンテンツの場合、監視に関心を持つユーザーが 2 種類います。

  • Power BI 管理者: 秘密度ラベルが割り当てられたり変更されたりするたびに、Power BI アクティビティ ログのエントリが記録されます。 アクティビティ ログ エントリには、ユーザー、日付と時刻、項目名、ワークスペース、容量など、イベントの詳細が記録されます。 その他のアクティビティ ログ イベント (レポートを表示する場合など) には、項目に割り当てられている秘密度ラベル ID が含まれます。
  • セキュリティおよびコンプライアンス管理者: 組織のセキュリティおよびコンプライアンス管理者は、通常、Microsoft Purview のレポート、アラート、監査ログを使用します。

チェックリスト - 情報保護を監視する場合、主な決定事項とアクションは次のとおりです。

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

ヒント

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

関連するコンテンツ

このシリーズの次の記事では、Power BI のデータ損失防止について説明します。