Microsoft Fabricの「Data security overview」は、OneLakeに保存したデータを安全に扱うための基本設計を整理した公式ドキュメントです。結論から言うと、今回の更新で管理者がまず見るべきなのは「ワークスペースロールだけで安全だと思い込んでいないか」「OneLake securityでデータ単位のアクセス制御を設計しているか」「外部アプリ・サービスプリンシパル・監査ログ・暗号化・ネットワーク設定まで確認しているか」の3点です。
Microsoft Learn上の該当ページは2026年5月6日に最終更新されています。OneLakeのセキュリティは、環境内の操作を制御するコントロールプレーン権限と、実際にどのデータを見られるかを制御するデータプレーン権限に分けて考える必要があります。OneLake securityは後者、つまりOneLake上のデータアクセスを細かく制御する仕組みです。(Microsoft Learn)
Microsoft FabricのData security overview更新で押さえるべき結論
今回の「Data security overview – Microsoft Fabric」は、単なるセキュリティ機能一覧ではありません。Microsoft Fabricでデータ基盤を運用する組織に対して、OneLakeを中心にした権限設計をどう考えるべきかを整理した内容です。
特に重要なのは、次の考え方です。
| 確認ポイント | 実務上の意味 |
|---|---|
| ワークスペースロールとOneLake securityは役割が違う | Admin、Member、Contributorを広く付けると、OneLake securityで細かく絞ったつもりでも意図どおり制限できない場合がある |
| ViewerやRead権限のユーザーに対して、OneLake securityでデータアクセスを付与する | 「管理できる人」と「データを読める人」を分離しやすい |
| DefaultReaderやReadAllを確認する | Lakehouseなどで既定のアクセスが残っていると、追加したデータアクセスロールより広い権限が残る可能性がある |
| 外部アプリからOneLakeへアクセスできるかはテナント設定で制御する | OneLake File Explorer、ADLS APIベースの独自アプリ、Databricksなどの利用可否に影響する |
| 監査ログには限界がある | OneLakeの監査ログには読み取り要求やFabricワークロード経由の要求が含まれないと明記されている |
Microsoft公式の説明では、OneLake security rolesはデータ、権限、メンバー、制約の4要素で構成され、ViewerロールまたはアイテムのRead権限を持つユーザーにデータアクセスを付与するために使われます。一方で、Workspace Admin、Member、ContributorはOneLake security rolesの影響を受けず、アイテム内のすべてのデータを読み書きできるとされています。(Microsoft Learn)
今回の変更点をどう読むべきか
2026年5月6日の更新は、「既存環境に突然新しい制限が強制適用される」というより、OneLake securityを中心にしたデータ保護モデルをより実務向けに整理した更新と見るのが適切です。
MicrosoftDocsの履歴では、2026年3月20日にサードパーティエンジン対応への参照追加、4月3日にget started系ドキュメントの更新、4月9日にOneLakeメタデータ関連、4月23日に説明の明確化が行われています。つまり、今回の確認ポイントは「新機能があるか」だけでなく、「既存のFabric環境で権限設計が最新の考え方に合っているか」です。(GitHub)
管理者が特に注意すべき整理点
| 整理された観点 | 確認すべきこと |
|---|---|
| コントロールプレーンとデータプレーンの分離 | ワークスペースを管理できる権限と、データを閲覧できる権限を混同していないか |
| Workspace、Item、Folder単位のアクセス | どの階層で権限を付けるのが最小権限になるか |
| OneLake security roles | テーブル、フォルダー、行、列の単位でアクセス制御が必要なデータがないか |
| Authorized engines | Fabric外のエンジンやアプリケーションがOneLake securityを正しく適用できるか |
| 外部アプリのOneLakeアクセス | テナント設定で意図せず許可または拒否されていないか |
| 暗号化とネットワーク | CMK、TLS、Private Link、外部通信の扱いをセキュリティ要件に合わせているか |
OneLake securityは、Fabric内の複数のコンピューティングエンジンで一貫して適用されるデータプレーンのセキュリティモデルです。また、承認済みサードパーティエンジンは、OneLake APIからセキュリティポリシーや有効なアクセス情報を取得し、テーブル権限、RLS、CLSをクエリ時に適用する構成が示されています。(Microsoft Learn)
影響範囲：誰が何を確認すべきか
Microsoft FabricのData security overview更新は、Fabric管理者だけでなく、ワークスペース管理者、データエンジニア、アプリ開発者、セキュリティ担当者にも影響します。
| 役割 | 影響範囲 | すぐ確認すべきこと |
|---|---|---|
| Fabric管理者 | テナント設定、外部アプリ、サービスプリンシパル、監査、ネットワーク | OneLake外部アクセス設定、SPN許可、Private Link、監査ログの取得権限 |
| ワークスペース管理者 | Workspace role、Item permission、OneLake security role | Admin/Member/Contributorの過剰付与、DefaultReader、ReadAll |
| データエンジニア | Lakehouse、Warehouse、Spark、SQL analytics endpoint | RLS/CLSの適用、SQL endpointのUser’s identity mode、ショートカットの権限 |
| アプリ開発者 | ADLS API、OneLake File Explorer、外部エンジン連携 | Microsoft Entra ID認証、サービスプリンシパル、外部アプリ許可 |
| セキュリティ・監査担当 | 暗号化、通信、監査ログ、データ分類 | CMK要否、TLS、ログで追える操作と追えない操作 |
ワークスペースロールは、Fabricワークスペース内で「誰が何をできるか」を管理します。ロールは個人だけでなく、セキュリティグループ、Microsoft 365グループ、配布リストにも割り当てられます。複数グループに所属しているユーザーは、割り当てられたロールの中で最も高い権限を得るため、グループ設計の見直しは必須です。(Microsoft Learn)
管理者が最初に確認すべき設定
ワークスペースロールは「データアクセス権」ではなく「管理権限」として見直す
Fabricでは、Admin、Member、Contributor、Viewerの4種類のワークスペースロールがあります。公式ドキュメントでは、Admin、Member、ContributorはOneLakeのデータ読み取りが可能で、Viewerは既定ではOneLakeデータを読めないものの、OneLake security rolesでアクセスを付与できると説明されています。(Microsoft Learn)
実務では、次のように分けると事故を減らせます。
| 用途 | 推奨する考え方 |
|---|---|
| ワークスペースやアイテムを作成・変更する担当者 | Admin、Member、Contributorを必要最小限に付与 |
| データを読むだけの業務ユーザー | Viewerを基本にし、OneLake securityで必要なデータだけ付与 |
| 部門横断で一部データのみ参照するユーザー | ワークスペースロールではなく、OneLake security rolesやItem permissionを優先 |
| 一時的な検証ユーザー | 個人付与ではなく、期限付きのセキュリティグループで管理 |
よくある失敗は、「分析担当者だからContributorにしておく」という付与です。Contributorはアイテム作成やデータ書き込みに関わる権限を持つため、単なる閲覧者に付けるには強すぎます。
DefaultReaderとReadAllを確認する
LakehouseにはDefaultReaderロールがあり、ReadAll権限を持つユーザーにLakehouse内データへのアクセスを与える仕組みがあります。アクセスを絞りたい場合は、DefaultReaderを削除または編集できます。公式のGet started記事では、データアクセスロールにユーザーを追加した場合でもDefaultReaderから外さなければ広いアクセスが残る可能性があると注意されています。(Microsoft Learn)
確認手順は次のとおりです。
| 手順 | 確認内容 |
|---|---|
| 対象Lakehouseを選ぶ | 機密データや部門別データを含むLakehouseを優先する |
| Manage permissionsを開く | Read、ReadAll、Writeの付与先を確認する |
| OneLake security rolesを確認する | DefaultReader、カスタムロール、メンバー、対象フォルダーやテーブルを確認する |
| テストユーザーで検証する | 管理者アカウントではなく、実際のViewer相当ユーザーでアクセス結果を見る |
| 不要な権限を削除する | 個人付与よりセキュリティグループで管理する |
SQL analytics endpointはUser’s identity modeを確認する
SQL analytics endpointでOneLake securityを使うには、User’s identity access modeに切り替える必要があります。切り替えていないエンドポイントでは、権限評価がdelegated identityで行われると説明されています。(Microsoft Learn)
特に、LakehouseのデータをSQL経由で参照するレポートやセマンティックモデルがある場合は、次の観点で確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| SQL analytics endpointのモード | User’s identity access modeになっているか |
| レポート利用者の権限 | レポート上では見えないはずの行・列がSQL経由で見えないか |
| RLS/CLSの検証 | 管理者ではなく、一般ユーザーのIDで確認したか |
| 既存レポートへの影響 | 切り替え後に参照エラーやデータ欠落が起きないか |
開発者が確認すべきOneLakeアクセスの注意点
外部アプリからのOneLakeアクセスはテナント設定に依存する
Fabric管理者は、Fabric外部で動くアプリケーションからOneLakeデータへアクセスできるかをテナント設定で制御できます。この設定をオンにすると、ADLS APIを使う独自アプリ、OneLake File Explorer、Databricksなどからのアクセスが可能になります。オフにすると、Spark、Data Engineering、Data WarehouseなどFabric内部のアプリからはアクセスできますが、Fabric外部のアプリからはアクセスできません。(Microsoft Learn)
開発者は、アプリのエラーを「認証情報の不備」と決めつける前に、次を確認してください。
| 確認項目 | 具体例 |
|---|---|
| テナント設定 | Users can access data stored in OneLake with apps external to Fabric が許可されているか |
| 認証方式 | Microsoft Entra IDを使っているか |
| サービスプリンシパル | テナント全体または対象セキュリティグループでSPN利用が許可されているか |
| アプリの実行主体 | ユーザーIDなのか、サービスプリンシパルなのか |
| アクセス対象 | Lakehouse、フォルダー、テーブル、ショートカットのどこを読みに行っているか |
OneLakeはMicrosoft Entra IDで認証を行い、ユーザーIDやサービスプリンシパルに権限を付与します。サービスプリンシパルをFabricテナントで使うには、テナント管理者がSPNをテナント全体または特定のセキュリティグループに対して有効化する必要があります。(Microsoft Learn)
承認済みエンジンを使う場合は「適用責任」を確認する
OneLake security integrations overviewでは、OneLake securityのポリシーはOneLakeに一元的に保存され、クエリ時の適用はデータを読むエンジン側で行われると説明されています。すべてのエンジンがOneLakeのRLSやCLSを理解できるわけではないため、独自エンジンや外部アプリで保護済みデータを扱う場合は、authorized engineとして構成する考え方が示されています。(Microsoft Learn)
開発チームは、次の点を設計書に明記しておくべきです。
- どのIDでOneLakeへアクセスするか
- そのIDをどのワークスペースロールに追加するか
- RLS、CLS、テーブル権限をどの層で適用するか
- 認可されていないエンジンでRLS/CLS付きデータへアクセスした場合にどうブロックされるか
- 権限変更時のテスト方法とロールバック手順
移行・展開時に失敗しやすいポイント
OneLake securityで制限したつもりでもContributorが残っている
最も危険なのは、OneLake security rolesを作成した後も、対象ユーザーがMemberやContributorに残っているケースです。公式のアクセス制御モデルでは、Workspace Admin、Member、ContributorはOneLakeのWrite権限を自動的に持ち、OneLake securityのRead権限より優先されると説明されています。(Microsoft Learn)
対策は明確です。閲覧だけでよいユーザーはViewerへ移し、必要なテーブルやフォルダーだけをOneLake securityで付与します。開発者やデータエンジニアにContributorを付ける場合も、業務上必要なワークスペースに限定してください。
Read権限とReadAll権限を混同する
Item permissionのReadは、アイテムのメタデータを見られる権限であり、OneLake上のデータを直接読めることを意味しません。一方、ReadAllはDefaultReaderを通じてOneLakeデータへのアクセスに関わります。Writeはデータの読み書きに関わるため、付与先を慎重に確認する必要があります。(Microsoft Learn)
実務では、「レポートは見えるがLakehouseのファイルは見えない」「SQLでは見えるがOneLake APIでは見えない」といった混乱が起きがちです。権限確認時は、Fabricポータル、SQL endpoint、Spark、OneLake API、外部アプリのどの経路でアクセスするのかを分けて検証してください。
RLS/CLSの適用対象エンジンを確認していない
OneLake securityでは、行レベルセキュリティ（RLS）や列レベルセキュリティ（CLS）を使って、同じテーブル内の見える行や列を制御できます。ただし、ストレージレベルの操作では行・列単位の制御をそのまま適用できないため、許可されていないユーザーのアクセスがブロックされる場合があります。公式のアクセス制御モデルでは、Lakehouse、Spark notebooks、SQL Analytics EndpointのUser’s identity access mode、Direct Lake on OneLake modeのセマンティックモデルなどがRLS/CLSフィルタリング対応として示されています。(Microsoft Learn)
移行前には、利用中のエンジンごとに次を確認します。
| 利用経路 | 検証ポイント |
|---|---|
| Lakehouse | 対象ユーザーでテーブル・フォルダーが想定どおり見えるか |
| Spark notebooks | ノートブック実行者のIDでRLS/CLSが適用されるか |
| SQL analytics endpoint | User’s identity access modeで評価されているか |
| Direct Lake | レポート利用者の権限でデータが制限されるか |
| 外部エンジン | authorized engineとして構成され、ポリシーを適用できるか |
ショートカットの見え方を誤解する
OneLake shortcutsはデータ管理を簡素化しますが、権限確認では注意が必要です。公式ドキュメントでは、ショートカットに対するフォルダーセキュリティは、データが保存されているLakehouse側のロールに基づいて適用されると説明されています。さらに、内部OneLakeショートカットは一覧表示時にターゲット権限を確認せず返され、開くときにアクセスチェックが行われる場合があります。(Microsoft Learn)
つまり、「ショートカット名が見える」ことと「中のデータが読める」ことは同じではありません。ユーザーから「見えているのに開けない」と問い合わせが来る可能性があるため、権限設計時に利用部門へ説明しておくと混乱を減らせます。
暗号化・ネットワーク・監査で確認すべきこと
保存時暗号化とCMK
OneLakeに保存されたデータは、既定でMicrosoft-managed keysにより保存時暗号化されます。さらに、顧客管理キー（CMK）を使うことで、自社が管理するキーによる追加保護を構成できます。公式ドキュメントでは、CMKはワークスペースレベルで有効化でき、Key Vaultのキーを使ってOneLakeを含むワークスペース内のデータを保護できると説明されています。(Microsoft Learn)
ただし、CMKは万能ではありません。サポート対象アイテムが限定され、非対応アイテムを含むワークスペースでは有効化できません。また、キーを失効すると暗号化されたワークスペースへの読み書きが失敗する可能性があるため、キー管理、ローテーション、復旧手順を先に決めてから展開してください。(Microsoft Learn)
通信時暗号化とPrivate Link
Fabricでは、Microsoftサービス間のパブリックインターネット経由の通信は少なくともTLS 1.2で暗号化され、可能な場合はTLS 1.3が使われます。InboundのOneLake通信でもTLS 1.2が適用されます。一方で、顧客所有インフラへのOutbound通信では、新しい安全なプロトコルを優先しつつ、相手側が対応していない場合は古いプロトコルにフォールバックする可能性があると説明されています。(Microsoft Learn)
Private Linkを使う場合は、Azure Private Linkとプライベートエンドポイントにより、Microsoftのプライベートネットワークバックボーン経由でFabricへアクセスできます。ただし、Block Internet Accessを有効にすると、一部の未対応Fabricアイテムやシナリオが無効化またはブロックされる可能性があります。(Microsoft Learn)
展開前に、次のテストは必ず実施してください。
| テスト項目 | 確認内容 |
|---|---|
| DNS解決 | Fabric、OneLake、Warehouse関連エンドポイントが想定どおりプライベートIPへ解決されるか |
| 利用中機能 | Private Link非対応のシナリオが業務で使われていないか |
| 外部ツール | Power BI Desktop、独自アプリ、CI/CD環境から接続できるか |
| ロールバック | Private Link無効化時にDNSやPrivate Endpointを削除する手順があるか |
| 業務影響 | Block Public Internet Accessによる接続断を検証済みか |
監査ログで追える範囲を過信しない
Fabricのユーザー操作はMicrosoft Purviewの監査ログで確認できます。監査ログを見るには、Exchange OnlineのAudit Logsロールが必要です。検索時は日時範囲、アクティビティ、ユーザー、ファイルやフォルダーなどの条件で絞り込めます。(Microsoft Learn)
ただし、Data security overviewでは、OneLake監査ログには読み取り要求やFabricワークロード経由のOneLake要求が含まれないと明記されています。(Microsoft Learn)
そのため、監査設計では次のように分けて考える必要があります。
| 目的 | 確認方法 |
|---|---|
| 誰が設定を変更したか | Fabric監査ログ、管理操作ログ |
| 誰がアイテムを作成・削除したか | Fabric監査ログ |
| OneLakeのファイル操作を追う | OneLake操作名とADLS API相当の操作を確認 |
| データ読み取りの完全な証跡を取りたい | Fabric監査ログだけに依存せず、レポート利用状況、アプリ側ログ、ネットワークログなどを組み合わせる |
最小権限で展開するための実践手順
Microsoft Fabricのセキュリティ更新を受けて、既存環境を見直す場合は、いきなり全ワークスペースへ展開するよりも、重要なLakehouseを1つ選んで検証するのが安全です。
| ステップ | 作業内容 | 成果物 |
|---|---|---|
| 現状棚卸し | ワークスペース、アイテム、所有者、利用者、外部アプリを一覧化する | アクセス管理台帳 |
| ロール整理 | Admin、Member、Contributor、Viewerの付与先を確認する | ロール見直しリスト |
| データ分類 | 機密データ、部門限定データ、全社共有データを分ける | データ分類表 |
| OneLake security設計 | テーブル、フォルダー、行、列単位の制御を決める | セキュリティロール設計書 |
| DefaultReader確認 | ReadAllやDefaultReaderで広すぎるアクセスが残っていないか確認する | 既定ロール変更記録 |
| SQL endpoint検証 | User’s identity access modeと既存レポートへの影響を確認する | テスト結果 |
| 外部アクセス確認 | ADLS API、OneLake File Explorer、Databricks、独自アプリの利用可否を確認する | 外部連携一覧 |
| 監査・暗号化確認 | Purview、CMK、Private Link、TLS、ログ取得範囲を確認する | セキュリティ確認票 |
| 本番展開 | セキュリティグループ単位で段階的に適用する | 展開計画とロールバック手順 |
ここで重要なのは、権限を「人」ではなく「役割」と「グループ」で管理することです。個人に直接権限を付けると、異動、退職、兼務、プロジェクト終了時に棚卸しが難しくなります。Fabricではワークスペースロールをセキュリティグループに割り当てられるため、Entra ID側のグループ管理と合わせて運用すると、継続的な見直しがしやすくなります。(Microsoft Learn)
用途別の権限設計の判断基準
最後に、どの機能を使ってアクセス制御すべきかを整理します。
| やりたいこと | 優先して使う仕組み | 理由 |
|---|---|---|
| チーム単位でFabricアイテムを作成・管理したい | Workspace role | ワークスペース全体の作成・編集・管理に向いている |
| 特定アイテムだけを共有したい | Item permission、Sharing | ワークスペース全体を見せずに対象アイテムへアクセスさせやすい |
| Lakehouse内の一部フォルダーやテーブルだけ見せたい | OneLake security roles | データ単位で細かく制御できる |
| 同じテーブルで部門別に行を分けたい | RLS | ユーザーやグループごとに見える行を制限できる |
| 個人情報や機密列だけ隠したい | CLS | 列単位でデータ露出を抑えられる |
| 外部アプリからOneLakeを読む | テナント設定、Entra ID、必要に応じてauthorized engine | Fabric外のアクセス経路を管理できる |
| 規制対応でキー管理を強化したい | CMK | 自社管理キーで追加の暗号化制御ができる |
| インターネット経由のアクセスを制限したい | Private Link、Block Public Internet Access | ネットワーク経路を制御できる |
Microsoft FabricのData security overview更新を受けて最初にやるべきことは、すべての設定を一度に変更することではありません。まず、機密データを含む代表的なLakehouseを1つ選び、Admin、Member、Contributor、Viewer、ReadAll、DefaultReader、OneLake security roles、外部アプリ設定、SQL analytics endpointのモードを順番に確認してください。
そのうえで、閲覧者はViewerとOneLake security rolesで管理し、開発者や管理者には必要最小限のワークスペースロールだけを付与します。外部アプリ、サービスプリンシパル、Private Link、CMK、監査ログは、個別の技術設定ではなく「誰が、どの経路で、どのデータにアクセスできるか」を説明できる状態にしておくことが重要です。
コメント