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

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

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

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

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

秘密度ラベルの目的

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

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

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

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

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

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

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

Power BI 情報保護の前提条件

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

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

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

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

展開の段階

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

フェーズ 6: 初期テスト

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

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

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

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

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

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

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

フェーズ 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 コンテンツ以外にも適用されることに注意してください。

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

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

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

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

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

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

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

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

秘密度ラベルのスコープ

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

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

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

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

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

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

暗号化保護の使用

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

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

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

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

Azure Rights Management Service (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 Desktop ファイルまたはエクスポートされたファイルを開くには、ユーザーが次の条件を満たす必要があります。

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

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

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

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

サポートされているデータ ソース (Azure Synapse Analytics、Azure SQL Database、Excel ファイルなど) からデータをインポートする場合、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 のテナント設定」セクションを参照してください。

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

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

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

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

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

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

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

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

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

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

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

ラベル ポリシーを作成するときは、既定ラベルを選択できます。 たとえば、一般内部使用ラベルを既定ラベルとして設定できます。 この設定は、Power BI Desktop または 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 に適用されます。

必須ラベル オプションは、ラベル ポリシーの発行時に 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) ライセンスも必要です。

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

Power BI テナントの設定

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ラベルの説明: ラベル名を超えて、ラベルの完全な説明を提供します。 説明は明確でありながら簡潔にする必要があります。 以下に説明の例を示します。
  • "一般内部使用" - プライベート、内部、ビジネス データ用
  • "制限付き" - 漏えいした場合に損害を引き起こす、または規制またはコンプライアンス要件の対象である機密性の高いビジネス データ用
• 例: ラベルを使用するタイミングを説明するのに役立つ例を提供します。 次に例をいくつか示します。
  • "一般内部使用" - ほとんどの内部コミュニケーション、機密ではないサポート データ、アンケートの回答、レビュー、評価、不正確な場所データ
  • "制限付き" - 個人を特定できる情報 (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 と例は、ユーザー ドキュメントに特に役立ちます。

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

ユーザー サポート

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

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

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

実装の概要

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

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

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

継続的な監視

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

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

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

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

関連するコンテンツ

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