Microsoft Fabricのガバナンスとコンプライアンスに関する公式情報は、単なる機能一覧ではなく、Fabric環境を「誰が管理し、どこで保護し、どう監査し、どのように信頼できるデータとして使わせるか」を整理した管理者向けの指針です。
結論から言うと、今回の確認ポイントは3つです。Purview hub中心の見方からOneLake catalogやPurview連携を前提にした整理へ移っていること、テナント・ドメイン・ワークスペース単位の委任管理が重要になること、感度ラベル・DLP・監査・メタデータスキャンを運用設計に組み込む必要があることです。
なお、Microsoft Learn上の現行ページでは最終更新日が2026年5月11日と表示されています。一方、GitHub上のドキュメント履歴では2026年5月8日と5月11日に該当ページの編集が確認できます。本記事では、2026年5月9日前後に確認対象となった「Governance and compliance in Microsoft Fabric」の公式情報を基に、管理者・開発者・データ所有者が実務で確認すべき点を整理します。(Microsoft Learn)
Microsoft FabricのGovernance and complianceは何を整理した情報か
Microsoft Fabricの「Governance and compliance in Microsoft Fabric」は、Fabric内のデータ資産を管理・保護・監視し、利用者が信頼できるデータを見つけやすくするための公式概要です。対象は、Fabric管理者だけでなく、Power BIやLakehouse、Warehouse、Data Factory、Spark、KQL Databaseなどを扱う開発者、データ所有者、コンプライアンス担当者にも広がります。(Microsoft Learn)
このページで扱われている領域は、大きく次の4つです。
| 領域 | 目的 | 主な機能・確認対象 |
|---|---|---|
| データ資産の管理 | 組織全体のFabric環境を統制する | 管理ポータル、テナント設定、ドメイン、ワークスペース、容量、メタデータスキャン |
| 保護・コンプライアンス | 機密データを守り、監査可能にする | Microsoft Purview、感度ラベル、DLP、監査、データレベルのアクセス制御 |
| 発見性と信頼性 | 利用者が正しいデータを見つけられるようにする | OneLake catalog、承認、タグ、リネージ、影響分析 |
| 監視と改善 | 利用状況やリスクを可視化する | Monitoring hub、Capacity Metrics、Admin monitoring |
重要なのは、この記事が「新機能を1つ紹介するページ」ではない点です。Fabricを全社展開する際に、管理・セキュリティ・データ発見・監査をどのレイヤーで担当するかを決めるための設計ガイドとして読むべき内容です。
今回の変更点として押さえるべきポイント
今回の更新で特に実務上の意味が大きいのは、Fabricのガバナンス機能が「個別機能の寄せ集め」ではなく、OneLake catalog、Microsoft Purview、ドメイン、ワークスペース、監査を組み合わせた運用モデルとして整理されている点です。
GitHub上の変更履歴を見ると、2026年5月5日のコミットでは「Remove Purview hub」として、Purview hubに関する記述が削除され、OneLake catalogへの置き換えや関連リンクの変更が行われています。該当差分では、OneLake data hubがOneLake catalogに変更され、Purview hubの説明セクションが削除されています。(GitHub)
つまり、管理者が確認すべき実務上の変更は「Purviewが不要になる」という意味ではありません。むしろ、Fabric内のデータ発見・信頼性確認はOneLake catalogを軸に見直し、組織横断の保護・監査・データガバナンスはMicrosoft Purview連携として設計するという読み方が自然です。
OneLake data hubからOneLake catalogへの整理
公式ページでは、OneLake catalogは、利用者がアクセス権を持つFabricデータ項目を見つけ、探索し、利用するための機能として説明されています。検索やフィルターにより、関連データへ到達しやすくする役割を持ちます。(Microsoft Learn)
実務では、以下のような見直しが必要です。
| 確認対象 | 見直すべき内容 |
|---|---|
| 社内手順書 | 「OneLake data hub」や「Purview hub」と書かれた箇所を現行名称に合わせる |
| 利用者向け教育資料 | 信頼できるデータを探す場所としてOneLake catalogを案内する |
| 管理者向け運用 | ドメイン、承認、タグ、リネージをOneLake catalogでどう見せるか整理する |
| 移行時の混乱防止 | 旧名称の画面キャプチャやリンクを更新し、問い合わせを減らす |
名称変更やリンク変更は小さく見えますが、社内展開では混乱の原因になりやすい部分です。特にPower BI中心の利用者は旧UI名で覚えていることがあるため、FAQや社内ポータルでは「旧称」と「現行名称」を併記しておくと移行がスムーズです。
Purview hubではなくPurview連携として捉える
今回の差分ではPurview hubセクションが削除されていますが、Microsoft Purviewそのものの重要性は下がっていません。公式ページでは、Fabricは機密データの保護やプライバシー要件への対応にMicrosoft Purviewを活用すると説明されています。感度ラベル、DLP、監査、組織全体のデータガバナンスでPurviewが関係します。(Microsoft Learn)
管理者は「Fabric画面のどこにPurview hubがあるか」ではなく、次の観点で確認すべきです。
- 感度ラベルのポリシーがFabricの利用実態に合っているか
- DLPポリシーの対象アイテムと通知先が適切か
- Purview AuditでFabricのアクティビティを追跡できる体制があるか
- Purview側のデータカタログやData MapとFabricのドメイン設計が矛盾していないか
特に監査やDLPは、導入後に「ログは取れているが誰も見ていない」「検出通知が多すぎて無視される」という失敗が起きがちです。ポリシーを有効化するだけでなく、検知後の対応担当、一次判断の基準、例外申請の流れまで決めておく必要があります。
影響範囲：誰が何を確認すべきか
この公式情報の影響は、Fabric管理者だけに閉じません。Fabricはデータ統合、分析、BI、AI活用の基盤として使われるため、ガバナンス設定の影響が開発者やデータ利用者にも及びます。
| 対象者 | 主な影響 | すぐ確認すべきこと |
|---|---|---|
| Fabric管理者 | テナント設定、ドメイン、容量、ワークスペース作成権限の設計が必要 | 管理ポータルの設定、委任範囲、監査ログの取得状況 |
| セキュリティ・コンプライアンス担当 | 感度ラベル、DLP、監査、証跡管理が重要 | Purview Information Protection、DLP、Auditの対象範囲 |
| データ所有者 | データの分類、承認、タグ付け、公開判断が求められる | データ項目のラベル、承認状態、所有者情報 |
| 開発者・データエンジニア | 開発・検証・本番環境の分離、リネージ、データレベル制御が必要 | DTAP構成、ワークスペース分離、SQL endpointやWarehouseの権限 |
| BI利用者・業務部門 | 信頼できるデータの見つけ方が変わる | OneLake catalog、承認済みアイテム、タグ検索の使い方 |
ここで失敗しやすいのは、管理者が「設定」だけを整えて、業務部門に「どのデータを使えばよいか」を伝えないケースです。OneLake catalogや承認済みアイテムを整備しても、利用者が存在を知らなければ、従来どおり個人作成のデータセットや未検証のレポートが使われ続けます。
管理ポータルとテナント設定で確認すること
Microsoft Fabricの管理ポータルは、Fabric全体を制御する中心的な場所です。公式情報では、テナント設定、容量、ドメイン、ワークスペース、ユーザーの操作に関する設定を管理できる場所として説明されています。また、一部の管理・ガバナンスを容量、ドメイン、ワークスペースの管理者へ委任できる点も示されています。(Microsoft Learn)
管理者が最初に確認すべきなのは、次の3点です。
テナント全体で統一すべき設定を決める
テナント設定は、Fabric全体の基本ルールです。たとえば、誰がワークスペースを作成できるか、外部共有をどの範囲で許可するか、機能の利用を全社許可するか一部グループに限定するか、といった判断に関わります。
実務では、いきなり全社有効にするのではなく、次のように段階を分けると安全です。
| フェーズ | 設定方針 | 向いている状況 |
|---|---|---|
| パイロット | 管理者・検証チームのみに許可 | 初期検証、セキュリティレビュー中 |
| 部門展開 | 特定部門やCoEに許可 | データ活用部門から段階展開する場合 |
| 全社展開 | ルール整備後に広く許可 | 教育、監査、問い合わせ体制が整った後 |
特に生成AIや外部共有、データエクスポートに関わる設定は、利便性だけで判断しないようにします。情報漏えいリスク、社内規程、監査要件を確認したうえで、許可対象をグループ単位で絞るのが現実的です。
ドメイン管理を誰に委任するか決める
公式情報では、ドメインを使って組織内のデータを事業部門や業務領域ごとに論理的にまとめられると説明されています。ドメインとサブドメインにより、データの発見性とガバナンスを高められ、ドメイン単位で一部のテナントレベル設定を委任できます。(Microsoft Learn)
ドメイン設計では、組織図をそのまま写すだけでは不十分です。次の観点で設計すると運用しやすくなります。
- 会計、人事、販売、製造など、データの意味と責任範囲が明確な単位にする
- ドメイン所有者を「役職名」ではなく、実際に判断できる担当者・チームで定義する
- ドメインごとに、公開できるデータ、制限が必要なデータ、外部共有禁止データを分類する
- Purview側のドメインやデータカタログ設計と矛盾しないようにする
たとえば「営業部門ドメイン」の中に、顧客マスター、商談データ、売上予測、営業レポートが混在している場合、すべてを同じ公開レベルにするのは危険です。ドメイン内でも感度ラベルやワークスペース分離を組み合わせて管理する必要があります。
ワークスペース作成権限を無制限にしない
公式情報では、ワークスペースはチームがFabricアイテムを作成し共同作業する場所であり、ガバナンス要件やデータ境界に応じてチーム・部門に割り当てると説明されています。また、開発用途では開発者ごとに分離されたワークスペースを持つことがベストプラクティスとして示されています。(Microsoft Learn)
ワークスペース作成を誰でも自由にできる状態にすると、次の問題が起きやすくなります。
| 問題 | 具体例 |
|---|---|
| 所有者不明のワークスペースが増える | 退職者が作成したワークスペースに重要データが残る |
| 命名規則が崩れる | test2、sales_new_finalのような名前が乱立する |
| 本番データと検証データが混ざる | 開発中のLakehouseから本番レポートが参照される |
| 容量管理が難しくなる | 不要なジョブや更新処理が容量を消費する |
ワークスペースは、最低でも「部門」「用途」「環境」が分かる命名規則にします。例として、FIN-REPORT-PROD、SALES-LAKE-DEV、HR-DATA-TESTのように、業務領域と用途、環境を含めると管理しやすくなります。
容量と環境分離で確認すること
Fabricの容量は、各ワークロードで使われるコンピューティングリソースです。公式情報では、組織要件に応じて、容量をコンピューティングの分離境界やチャージバックに使えると説明されています。また、開発、テスト、受け入れ、本番、いわゆるDTAPに基づいて容量を分割することが推奨されています。(Microsoft Learn)
実務での判断基準は明確です。本番の安定性を守る必要があるなら、本番容量と開発・検証容量は分けるべきです。
| 構成 | メリット | 注意点 |
|---|---|---|
| 1つの容量に集約 | 管理が簡単、初期コストを抑えやすい | 開発ジョブが本番レポートに影響する可能性がある |
| 開発・本番で分離 | 障害影響を分けやすい | 容量管理とコスト配賦のルールが必要 |
| 部門別・用途別に分離 | チャージバックや責任範囲が明確 | 容量が細分化しすぎると運用が複雑になる |
開発者がSparkジョブやData Pipelineを試している間に、本番レポートの更新が遅延するような状況は避けるべきです。特に月次締め、経営会議、外部提出資料に関わるデータ処理は、検証用途の処理と容量を分けるとトラブル時の切り分けがしやすくなります。
メタデータスキャンで確認すること
メタデータスキャンは、組織のFabricアイテムのメタデータをカタログ化・報告するための機能です。公式情報では、scanner APIsと呼ばれる管理REST API群を使い、アイテム名、ID、感度、承認状態などのメタデータを抽出できると説明されています。(Microsoft Learn)
メタデータスキャンは、次のような場面で役立ちます。
- どのワークスペースに機密ラベル付きのデータがあるか確認する
- 未承認のデータセットやレポートが増えていないか確認する
- 所有者不明のアイテムを棚卸しする
- Power BIやLakehouse、Warehouseをまたいだ資産台帳を作る
- 監査や内部統制のために、Fabric資産の一覧を定期出力する
注意点は、スキャン結果を取るだけではガバナンスにならないことです。抽出したメタデータを誰が確認し、どの基準で改善アクションにつなげるかを決めておく必要があります。
たとえば、次のようなルールを設けると運用しやすくなります。
| 検出内容 | 対応例 |
|---|---|
| 所有者が退職者のアイテム | 部門管理者へ引き継ぎ依頼 |
| 感度ラベルなしの顧客データ | データ所有者へ分類依頼 |
| 承認なしで広く共有されたレポート | 共有範囲を確認し、必要に応じて制限 |
| 長期間使われていないワークスペース | 削除候補またはアーカイブ対象にする |
感度ラベルとDLPで確認すること
Microsoft Fabricのデータ保護では、Microsoft Purview Information Protectionの感度ラベルが重要です。公式情報では、感度ラベルによりFabricデータを発見、分類、保護でき、既定ラベル、ラベル継承、プログラムによるラベル付けなどを使ってラベル適用範囲を広げられると説明されています。さらに、サポートされるエクスポート経路では、Fabric外へ出た後もラベルによる保護が維持されるとされています。(Microsoft Learn)
感度ラベルは組織全体で定義する
公式情報では、感度ラベルとラベルポリシーは組織レベルで指定し、組織全体で有効なものにすることが推奨されています。(Microsoft Learn)
ラベル設計でよくある失敗は、部門ごとに独自ルールを作りすぎることです。たとえば、営業部では「社外秘」、人事部では「機密」、経理部では「内部限定」というように表現がばらばらだと、利用者が判断できません。
最初は次のようなシンプルな分類から始めると運用しやすくなります。
| ラベル例 | 対象データ | 運用上の注意 |
|---|---|---|
| 公開可 | 社外公開済み資料、公開データ | 誤って内部情報を含めない |
| 社内限定 | 一般的な社内レポート | 外部共有を原則制限 |
| 機密 | 顧客情報、売上、契約、個人情報 | DLPや監査対象にする |
| 高機密 | 人事評価、M&A、重大インシデント情報 | アクセス権を最小化し、例外承認を必須にする |
ラベル名は、英語の直訳よりも利用者が判断しやすい表現にすることが重要です。「Confidential」だけでは判断できない場合、社内の情報分類規程と同じ名称に合わせると定着しやすくなります。
DLPは検出後の対応まで設計する
Purview DLPポリシーは、FabricおよびPower BIでサポートされるアイテムに機密情報がアップロードされた際、自動的に検出し、リスク軽減のアクションを支援します。公式情報では、DLP検出ごとに監査ログが記録され、管理者はアラートや利用者向けのカスタムメッセージを設定できると説明されています。(Microsoft Learn)
DLPで重要なのは、検出精度だけではありません。次のような運用設計が必要です。
- 何を検出対象にするか
- 誰にアラートを送るか
- 検出時に利用者へどのメッセージを表示するか
- 誤検知だった場合の申請ルートをどうするか
- 実際に情報漏えいリスクがある場合、誰がアクセス制限や共有停止を行うか
たとえば、顧客番号やメールアドレスを含むLakehouseがアップロードされた場合、「これは内部情報のため外部共有しないでください」とデータ所有者に通知するだけでも、初期段階の事故防止に役立ちます。一方で、通知が多すぎると無視されるため、最初は重要度の高いデータ種別から始めるのが現実的です。
監査ログで確認すること
公式情報では、Fabric管理者とコンプライアンスチームが、Purview Auditを使ってFabricアイテム上のユーザーアクティビティを追跡・調査できると説明されています。監査対象には、Lakehouseアクセス、Power BIアクセス、Sparkアクティビティ、Data Factoryアクティビティ、サインインなどが含まれます。(Microsoft Learn)
監査ログは、障害調査だけでなく、内部統制や不正アクセスの調査にも使います。運用上は次の観点を確認してください。
| 確認項目 | 具体的な確認内容 |
|---|---|
| ログ取得 | Fabricアイテムレベルの監査がPurview Auditで確認できるか |
| 保存期間 | 社内規程や業界要件に合う期間、ログを保持できるか |
| 調査手順 | 不審なアクセスがあったとき、誰がどの画面で調べるか |
| アラート | 高リスク操作を通知する仕組みがあるか |
| 権限 | 監査ログを閲覧できる担当者が限定されているか |
「監査ログを取っている」は十分ではありません。退職者によるアクセス、外部共有、深夜帯の大量ダウンロード、機密データへの権限変更など、何を不審な操作とみなすかを事前に決めておく必要があります。
ワークスペースとアイテム単位の権限で確認すること
公式情報では、ワークスペース管理者がワークスペースロールを割り当て、ワークスペース内のアイテムへのアクセスを管理すると説明されています。さらに、テナントやワークスペースレベルの広い制御に加えて、SQL analytics endpoint、Warehouse、Direct Lake、KQL Databaseでは、テーブル、行、列単位のデータレベル制御を適用できるとされています。(Microsoft Learn)
実務では、次の2段階で考えると分かりやすくなります。
ワークスペースロールは「作業者」と「閲覧者」を分ける
開発者、データ所有者、閲覧者を同じ権限にすると、誤操作や過剰共有の原因になります。特に本番ワークスペースでは、編集できる人を最小限にします。
| 役割 | 権限設計の考え方 |
|---|---|
| 管理者 | 少数に限定し、所有者不在を避けるため複数名にする |
| 開発者 | 開発・検証環境では広め、本番では制限する |
| データ所有者 | 承認、分類、利用可否の判断を担う |
| 閲覧者 | 原則として参照のみ。必要に応じて承認済みアイテムへ誘導する |
データレベル制御は本当に必要な場所へ適用する
行レベル、列レベルの制御は強力ですが、設計を誤ると管理が複雑になります。全データに細かい制御を入れるのではなく、顧客情報、人事情報、地域別売上など、閲覧範囲を明確に分ける必要があるデータから適用します。
たとえば、全国売上レポートは経営層のみ閲覧可、地域別売上は各地域の責任者のみ閲覧可、個人別成績は本人と上長のみ閲覧可、といったルールをデータ設計段階で決めます。後から権限制御を追加すると、既存レポートや下流処理に影響するため、開発初期から組み込むことが重要です。
OneLake catalog、承認、タグで信頼できるデータを見つけやすくする
Fabricのガバナンスは、制限するだけでは不十分です。利用者が「どのデータを使えばよいか」を判断できるようにする必要があります。
公式情報では、OneLake catalogがFabricデータアイテムの検索・探索・利用を支援し、承認機能により信頼できる高品質なアイテムを見つけやすくできると説明されています。承認されたアイテムはFabric内や関連する場所で明確に表示され、検索で優先される場合があります。(Microsoft Learn)
承認済みアイテムの基準を明文化する
承認を形だけにすると、すぐに「何でも承認済み」になってしまいます。次のような基準を用意しておくと、品質を保ちやすくなります。
| 承認条件 | 確認内容 |
|---|---|
| 所有者が明確 | 問い合わせ先と保守担当が分かる |
| データ更新が安定 | 更新頻度、最終更新日、失敗時の対応が明確 |
| 定義が説明されている | 指標や列の意味が利用者に分かる |
| 権限が適切 | 不要な広範囲共有がない |
| ラベルが付与されている | 機密度に応じた感度ラベルがある |
| 下流影響を把握できる | リネージや影響分析で参照先を確認できる |
データ利用者には、「迷ったら承認済みアイテムを使う」というルールを周知します。未承認アイテムを使う場合は、自己責任ではなく、用途やリスクを確認するプロセスを設けると安全です。
タグは検索キーワードではなく運用分類として設計する
公式情報では、Fabric管理者がタグを定義し、データ所有者がFabricアイテムへ適用できると説明されています。適用されたタグは、Fabricの各種体験で表示、検索、フィルターに利用できます。(Microsoft Learn)
タグは増やしすぎると使われなくなります。おすすめは、次のように目的を絞ることです。
| タグの種類 | 例 |
|---|---|
| 業務領域 | Sales、Finance、HR、Manufacturing |
| 利用目的 | Reporting、Training、Reference、Regulatory |
| データ状態 | Certified、Draft、Deprecated |
| 注意喚起 | ExternalUseProhibited、PII、CustomerData |
日本語のタグを使うか英語のタグを使うかは組織文化によりますが、混在は避けます。多国籍チームやシステム連携を考えるなら英語、国内利用中心であれば日本語でも問題ありません。重要なのは、タグの意味を社内で統一することです。
リネージと影響分析で変更リスクを下げる
公式情報では、リネージによりワークスペース内のアイテム同士の関係を可視化でき、影響分析により、あるアイテムを変更した場合に影響を受ける下流アイテムを確認できると説明されています。(Microsoft Learn)
リネージと影響分析は、特に次のような場面で有効です。
- Lakehouseのテーブル構造を変更する
- Warehouseの列名やデータ型を変更する
- Data Pipelineの更新スケジュールを変える
- Power BIレポートの元データを差し替える
- 不要に見えるアイテムを削除する
よくある失敗は、「使われていないと思ったテーブル」を削除した結果、月次レポートが更新できなくなるケースです。変更前にリネージを確認し、下流のレポートやデータフロー、パイプラインを把握してから作業する必要があります。
また、公式情報では、リネージ情報を見る際に、適切で一貫した命名規則を使うことが推奨されています。(Microsoft Learn)
命名規則は地味ですが、運用効率に直結します。Table1、NewPipeline、Report_final2のような名前では、影響分析を見ても判断できません。sales_daily_actuals、pl_monthly_close_pipeline、exec_sales_dashboardのように、用途が分かる名前にします。
監視：Monitoring hub、Capacity Metrics、Admin monitoringの使い分け
公式情報では、Monitoring hubはFabricアクティビティを中央で監視できる場所であり、ユーザーには自分が表示権限を持つFabricアイテムのアクティビティが表示されると説明されています。また、管理者向けにはAdmin monitoring workspaceがあり、監査や利用状況確認などのセキュリティ・ガバナンス業務に使えるとされています。(Microsoft Learn)
使い分けは次のように考えると分かりやすいです。
| 機能 | 主な利用者 | 使う場面 |
|---|---|---|
| Monitoring hub | 開発者、運用担当、データ所有者 | パイプライン、データフロー、Spark実行、更新処理などの状況確認 |
| Capacity Metrics | Fabric管理者、容量管理者 | 容量使用率、負荷、リソース消費の確認 |
| Admin monitoring | Fabric管理者、セキュリティ担当 | 組織全体の利用状況、監査、ガバナンス確認 |
開発者にはMonitoring hubを見てもらい、管理者はCapacity MetricsとAdmin monitoringで全体を確認する、という役割分担が現実的です。すべての問い合わせを管理者が受ける運用にすると、更新失敗やジョブ遅延のたびに管理者がボトルネックになります。
移行・展開時の注意点
Microsoft Fabricを既に使っている組織、またはこれから全社展開する組織は、以下の順番で確認すると無理なく進められます。
| 優先度 | 作業 | 目的 |
|---|---|---|
| 高 | 管理ポータルのテナント設定を棚卸しする | 全社の基本ルールを確認する |
| 高 | ワークスペースと容量を一覧化する | 所有者不明、用途不明、環境混在を見つける |
| 高 | 感度ラベルとDLP対象を確認する | 機密データの保護漏れを防ぐ |
| 中 | OneLake catalogの利用ルールを整える | 利用者が信頼できるデータを探せるようにする |
| 中 | 承認とタグの基準を作る | データ品質と発見性を高める |
| 中 | リネージ確認を変更手順に組み込む | 変更による下流影響を減らす |
| 低ではないが後回し可 | 高度なPurview連携や手動スキャンを整える | 組織横断のデータガバナンスを強化する |
特に注意すべきなのは、UI名やリンクの変更だけを対応して終わらせないことです。Purview hub関連の記述が整理されたことで、社内手順書の表現は更新が必要ですが、本質は「Fabric内での発見性」と「Purviewを使った保護・監査・組織横断ガバナンス」を分けて設計することです。
管理者・開発者向けチェックリスト
最後に、すぐに確認できるチェックリストをまとめます。
Fabric管理者が確認すること
- 管理ポータルにアクセスできる管理者が適切に限定されている
- テナント設定の変更履歴と承認プロセスがある
- ワークスペース作成権限が無制限になっていない
- ドメインとサブドメインの所有者が決まっている
- 容量が開発・検証・本番で適切に分離されている
- Admin monitoringやCapacity Metricsを見る担当者が決まっている
- 旧称のOneLake data hubやPurview hubを含む社内資料を更新している
セキュリティ・コンプライアンス担当が確認すること
- 感度ラベルがFabric利用に合わせて定義されている
- ラベルポリシーが組織全体で一貫している
- DLPポリシーの対象、通知先、例外対応が決まっている
- Purview AuditでFabricアクティビティを確認できる
- 監査ログの保存期間と調査手順が社内要件に合っている
- 機密データを含むアイテムの所有者と共有範囲を把握している
開発者・データエンジニアが確認すること
- 個人開発用、共有開発用、本番用のワークスペースが分離されている
- Spark環境やパイプラインの再利用ルールが決まっている
- 本番反映前にリネージと影響分析を確認している
- SQL analytics endpoint、Warehouse、Direct Lake、KQL Databaseで必要なデータレベル制御を設計している
- 命名規則に従ってLakehouse、テーブル、パイプライン、レポートを作成している
データ所有者が確認すること
- 自分が所有するデータアイテムに説明、所有者、更新頻度がある
- 承認済みとして公開する基準を満たしている
- タグが適切に付与されている
- 感度ラベルがデータ内容に合っている
- 利用者に「どのデータを使うべきか」を案内できる
まず着手すべきこと
Microsoft FabricのGovernance and complianceは、設定項目を一つずつ有効化するだけでは実効性が出ません。最初にやるべきことは、現在のFabric環境を棚卸しし、テナント、ドメイン、ワークスペース、容量、感度ラベル、DLP、監査、OneLake catalogのどこに責任者と運用ルールがあるかを確認することです。
小さく始めるなら、次の順番がおすすめです。
- 管理ポータルでテナント設定とワークスペース作成権限を確認する
- 主要ワークスペースの所有者、用途、環境区分を一覧化する
- 感度ラベルとDLPの対象データを決める
- OneLake catalogで見つけてほしい承認済みデータを定義する
- 本番変更手順にリネージ確認と影響分析を組み込む
今回の公式情報は、Fabricの管理を「管理者だけの作業」から「データ所有者、開発者、セキュリティ担当、業務利用者を含む運用設計」へ広げる内容です。すでにFabricを導入している組織ほど、まずは既存のワークスペース、容量、感度ラベル、社内手順書を見直し、OneLake catalogとPurview連携を前提にしたガバナンス運用へ更新していきましょう。
コメント