Microsoft FabricでOneLakeを使っている管理者がまず確認すべきなのは、OneLake securityの適用対象、DefaultReaderなどの既定ロール、SQL analytics endpointのUser’s identity access modeです。2026年5月6日に更新されたMicrosoft Learnの「Get started with OneLake security」では、OneLake内のデータに対して、テーブル・フォルダー単位のRBAC、行レベルセキュリティ、列レベルセキュリティを使ってアクセス制御する考え方が整理されています。特に既存のLakehouseやSQL analytics endpointを運用している環境では、「ロールを作ったのに制限できていない」「SQL経由では期待どおりに効かない」といった設定漏れが起きやすいため、展開前に権限設計を見直すことが重要です。(Microsoft Learn)
Microsoft Fabricのセキュリティ更新で押さえるべき結論
今回のポイントは、OneLake securityを「Fabricアイテムに保存されたデータを細かく守るための中核機能」として扱うべきだという点です。OneLake securityでは、OneLake上のデータにRBACを適用し、Fabricアイテム内の特定フォルダーやテーブルに対してロールを定義できます。ロールにはユーザーやグループを割り当てられ、さらに行レベルセキュリティや列レベルセキュリティでアクセス範囲を絞り込めます。(Microsoft Learn)
MicrosoftDocsの更新履歴では、2026年5月にOneLake securityとOneLake data access rolesがGenerally availableとして整理され、フォルダー、行、列レベルの細かなアクセス制御を提供する機能として記載されています。運用側から見ると、プレビュー機能の試用ではなく、本番利用を前提に「誰が、どの経路で、どのデータを見られるか」を再点検する段階に入ったと考えるべきです。(GitHub)
| 確認項目 | 管理者・開発者への影響 | 取るべき対応 |
|---|---|---|
| OneLake securityロール | テーブル、フォルダー、スキーマ単位でアクセス制御できる | 部門・用途・データ分類ごとにロールを設計する |
| DefaultReader | ReadAll権限を持つユーザーが広く参照できる可能性がある | 制限したい場合はDefaultReaderを削除または調整する |
| SQL analytics endpoint | OneLake securityを使うにはUser’s identity access modeが必要 | 既存エンドポイントのアクセスモードを確認する |
| RLS / CLS | 行・列単位で絞れるが、エンジンやアクセス経路に注意が必要 | Spark、SQL、Direct Lakeなど複数経路で検証する |
| ReadWrite | 一部ユーザーにデータ更新権限を与えられる | Lakehouse UXではなくSpark、OneLake file explorer、API経由の動作を前提にする |
OneLake securityとは何か
OneLake securityは、Microsoft FabricのOneLakeに保存されたデータに対して、ロールベースのアクセス制御を適用する仕組みです。従来のようにワークスペース単位やアイテム単位だけで考えるのではなく、Lakehouseなどの中にあるテーブルやフォルダーを対象に、読み取り・書き込み・行単位・列単位の制御を組み合わせられます。
重要なのは、OneLake securityがdeny-by-defaultの考え方を採用している点です。つまり、OneLake securityロールで明示的に許可されていないユーザーは、原則として対象データにアクセスできません。ただし、Fabricのワークスペースロールや既定ロールとの組み合わせによって実際の見え方が変わるため、単に新しいロールを作るだけでは十分ではありません。(Microsoft Learn)
OneLake securityロールは、主に次の要素で構成されます。
| 構成要素 | 内容 | 実務での見方 |
|---|---|---|
| Type | 現時点ではGrantタイプが中心 | 「許可を追加するロール」として設計する |
| Permission | ReadまたはReadWrite | 参照だけか、更新も許すかを分ける |
| Scope | テーブル、フォルダー、スキーマ | データ分類や業務単位で切る |
| Members | Microsoft Entra IDのユーザー、グループ、非ユーザーIDなど | 個人ではなくグループ割り当てを基本にする |
対象になるFabricアイテムと権限
OneLake securityの対象は、すべてのFabricアイテムではありません。公式情報では、Lakehouse、Azure Databricks Mirrored Catalog、Mirrored Databasesが対象として整理されています。LakehouseはReadとReadWriteに対応しますが、Azure Databricks Mirrored CatalogとMirrored DatabasesはReadのみです。(Microsoft Learn)
| Fabricアイテム | 対応権限 | 代表的な利用シーン |
|---|---|---|
| Lakehouse | Read、ReadWrite | 部門別データ参照、特定フォルダーへの更新権限付与 |
| Azure Databricks Mirrored Catalog | Read | Databricks由来データの参照制御 |
| Mirrored Databases | Read | ミラーリングされたデータベースの参照制御 |
LakehouseでReadWriteを使う場合は、データ編集を許可できる一方で、Fabricアイテムの作成・管理権限まで渡す必要はありません。たとえば、データエンジニアには特定フォルダーへのアップロードや更新を許可し、ビジネスユーザーには参照だけを許可するといった分離ができます。ただし、ReadWriteによる書き込みはSpark notebooks、OneLake file explorer、OneLake APIsなどが対象で、ViewerによるLakehouse UXからの書き込みはサポートされません。(Microsoft Learn)
影響範囲は「OneLakeだけ」ではない
OneLake securityはストレージ内の権限設定に見えますが、影響範囲はOneLake上のファイル参照だけに留まりません。公式情報では、OneLake securityの権限はFabric内のすべてのエクスペリエンスでユーザーが見られるデータを決めると説明されています。(Microsoft Learn)
特に注意すべきなのは、アクセス経路によって挙動が変わる部分です。Lakehouse、Spark notebooks、SQL analytics endpointのUser’s identity access mode、Direct Lake on OneLake modeのセマンティックモデルでは、RLSやCLSのフィルタリングがGAとして扱われています。一方、EventhouseはRLSのみがPublic preview、認可済みサードパーティエンジンは実装されている場合にPublic previewとして扱われます。(Microsoft Learn)
| 利用者・担当者 | 影響を受ける領域 | 確認すべきポイント |
|---|---|---|
| Fabric管理者 | ワークスペースロール、アイテム権限、既定ロール | Admin / Member / Contributorの強い権限が制限を上書きしないか |
| データエンジニア | Lakehouse、Spark、OneLake API、ショートカット | フォルダー構成、Deltaテーブル条件、ReadWriteの範囲 |
| BI開発者 | SQL analytics endpoint、Direct Lake、セマンティックモデル | User’s identity access mode、RLS / CLSの効き方 |
| セキュリティ担当 | Microsoft Entraグループ、B2Bゲスト、監査 | 個人割り当てではなくグループ設計にできているか |
| 業務部門ユーザー | レポート閲覧、データ探索 | 必要なデータだけが見える状態になっているか |
管理者が最初に確認すべき設定
DefaultReaderを残したままにしない
OneLake securityで最も起きやすい失敗は、制限用のロールを作ったのにDefaultReaderで広いアクセスが残ることです。新しいアイテムには既定ロールが用意され、LakehouseではDefaultReaderがTables/とFiles/配下の全フォルダーにRead権限を与える構成として説明されています。DefaultReaderはReadAll権限を持つユーザーを対象にするため、細かく制限したい場合は既定ロールを編集または削除する必要があります。(Microsoft Learn)
公式ドキュメントでも、ユーザーをデータアクセスロールに追加した場合はDefaultReaderから外すよう注意しています。外さない場合、そのユーザーは引き続き広いデータアクセスを維持する可能性があります。(Microsoft Learn)
実務では、いきなりDefaultReaderを削除するより、次の順序で進めると安全です。
| 手順 | 作業 | 目的 |
|---|---|---|
| 1 | 現在のReadAll保持者を洗い出す | 広範囲に見えているユーザーを把握する |
| 2 | 部門・用途別の新ロールを作成する | 必要最小限のアクセスを定義する |
| 3 | テストユーザーでアクセス確認する | 見えるべきデータ、見えないべきデータを検証する |
| 4 | DefaultReaderを編集または削除する | 既定の広いアクセスをなくす |
| 5 | レポート、Notebook、SQLクエリを再確認する | 業務影響を検出する |
SQL analytics endpointをUser’s identity access modeにする
SQL analytics endpointでOneLake securityを使うには、User’s identity access modeへの設定が必要です。公式手順では、SQL analytics endpointのSecurityタブからData access mode settingsを開き、「Use OneLake security for tables (User’s identity access mode)」を選択して適用します。切り替えはSQL analytics endpointごとに一度行えばよく、切り替えていないエンドポイントはdelegated identityで権限評価を続けます。(Microsoft Learn)
既存環境では、ここが移行時の要注意ポイントです。Lakehouse側にOneLake securityロールを設定しても、SQL analytics endpointが期待するモードでなければ、SQL経由のアクセス制御が想定どおりにならない可能性があります。
確認手順は次のとおりです。
| 手順 | 操作 |
|---|---|
| 1 | 対象のSQL analytics endpointを開く |
| 2 | Securityタブを選択する |
| 3 | View data access modeからData access mode settingsを開く |
| 4 | Use OneLake security for tablesを選択する |
| 5 | Applyを選択し、確認画面でContinueする |
| 6 | テストユーザーでSQLクエリ結果を確認する |
WorkspaceロールとOneLake securityの関係を確認する
OneLake securityは、Fabricのワークスペースロールを置き換えるものではありません。ワークスペース権限はOneLake内データの最初のセキュリティ境界として扱われます。Admin、Member、ContributorはOneLakeに対するWrite権限を自動的に持つため、OneLake securityのRead制限より強い権限を持つ場合があります。(Microsoft Learn)
そのため、厳密な閲覧制御をしたいユーザーをAdminやMemberに入れたままにしないことが重要です。たとえば、部門レポートの閲覧だけが必要なユーザーはViewer相当にし、OneLake securityロールで必要なテーブルだけを付与する方が、権限設計として分かりやすくなります。
開発者が確認すべき実装上の注意点
テーブルとして認識される条件を満たしているか
OneLake securityでテーブルレベルの制御を使う場合、OneLake上のフォルダーがFabricのテーブルとして正しく認識される必要があります。公式情報では、有効なテーブルとして扱われる条件として、Tables/ディレクトリ配下に存在すること、_delta_logフォルダーとメタデータ用JSONファイルを含むこと、子ショートカットを含まないことが挙げられています。条件を満たさない場合、テーブルレベルセキュリティを構成してもアクセスが拒否されます。(Microsoft Learn)
開発時は、データ配置を後から権限で補正しようとするのではなく、Lakehouseのフォルダー設計とDeltaテーブル設計を先に整えるべきです。
RLSはシンプルなSQL述語で設計する
RLSでは、SQL述語を書いてユーザーに見せる行を制限します。公式情報では、RLSは述語がtrueになる行を表示し、文字列データの評価は大文字小文字を区別しない照合順序で行われると説明されています。また、RLS文は分かりやすく保ち、大小比較や並べ替えには整数列を使い、入力形式が不明な文字列比較は避けることが推奨されています。(Microsoft Learn)
実務では、次のような設計が安全です。
| 避けたい設計 | 推奨される設計 |
|---|---|
department_name = 'Sales'のような表記揺れしやすい文字列比較 | 部門IDや地域IDなどの整数キーで判定する |
| 複雑なOR条件を大量に並べる | 部門・地域・職位などロールを分けて整理する |
| ユーザー名やメールアドレスを条件に直接埋め込む | Microsoft Entraグループとロール設計で管理する |
| 本番データでいきなり適用する | 小さなテストテーブルでクエリ結果を検証する |
CLSは「見えない列」と「メタデータ表示」を分けて考える
CLSでは、ユーザーがアクセスできない列を非表示にできます。隠された列は権限がない列として扱われ、ユーザーには表示されず、対象列を含むクエリではその列のデータが返されません。ただし、公式情報では、特定のエラーや体験上で列名などのメタデータが見える可能性があると説明されています。(Microsoft Learn)
つまり、CLSは「列の値を見せない」ための制御として有効ですが、「列名の存在すら完全に秘匿する」用途では慎重に検証すべきです。たとえば、給与、個人番号、契約単価のような列は、列名そのものが機微情報になる場合があります。その場合は、列名の付け方やテーブル分割も含めて設計しましょう。
ReadWrite権限を展開するときの注意点
ReadWriteは便利ですが、全員に広く配るべき権限ではありません。ReadWriteはRead権限の内容を含み、フォルダーやテーブルの作成、削除、名前変更、ファイルのアップロードや編集、ショートカットの作成・削除・名前変更などを許可します。一方で、ReadWriteを持つOneLake securityロールにはRLSやCLSの制約を含められません。(Microsoft Learn)
ReadWriteの適用に向いているのは、たとえば次のようなケースです。
| 利用シーン | ReadWriteの使い方 |
|---|---|
| データエンジニアが一部フォルダーだけ更新する | 対象フォルダーに限定してReadWriteを付与する |
| 部門担当者がファイルを投入する | 入力用フォルダーに限定してアップロード権限を与える |
| Notebookで特定テーブルを更新する | Spark notebooks経由の書き込みを前提に検証する |
| ショートカット管理を一部ユーザーに任せる | ショートカット作成・削除の影響範囲を文書化する |
逆に、Admin、Member、ContributorにReadWriteを追加しても、既に強い権限を持つため実質的な効果は限定的です。権限を増やす前に、対象ユーザーをViewerまたはRead相当に落とし、必要な範囲だけReadWriteを与える設計を検討してください。
ショートカット利用時はアクセス元とアクセス先の両方を見る
OneLake securityを設定する環境では、ショートカットの扱いも重要です。内部ショートカットでは、ショートカットのターゲット側の権限がアクセスを決めます。ユーザーがショートカットを開くときにアクセスチェックが行われ、必要な権限を持つデータだけが見えます。(Microsoft Learn)
外部ショートカットでは、OneLake securityに加えて、外部システム側の接続資格情報やFabric Read権限も関係します。たとえばS3、ADLS、Dataverseへのショートカットでは、外部接続側で許可されていても、OneLake security側で許可されていなければアクセスできません。反対に、OneLake security側で許可されていても、外部接続側で許可されていなければアクセスできません。(Microsoft Learn)
Power BIやT-SQL経由でショートカットを使う場合は、delegated identityのままになっていないかも確認しましょう。公式情報では、DirectLake over SQLまたはT-SQLエンジンのDelegated identity modeでは呼び出し元ユーザーのIDがショートカット先に渡らないケースがあり、Direct Lake over OneLake modeまたはT-SQLのUser’s identity modeを使う対応が示されています。(Microsoft Learn)
移行・展開で失敗しやすいポイント
OneLake securityの展開で失敗しやすいのは、機能そのものよりも「既存権限との組み合わせ」です。以下の表を使って、展開前に確認しておきましょう。
| 失敗しやすいポイント | 起きること | 対策 |
|---|---|---|
| DefaultReaderを残したまま新ロールを作る | 制限したはずのユーザーが引き続き広く見える | DefaultReaderまたはReadAll権限を見直す |
| SQL analytics endpointのモード未確認 | SQL経由で期待どおりに制御されない | User’s identity access modeを確認する |
| Admin / Member / Contributorに制限をかけようとする | 強いワークスペース権限が優先される | 閲覧専用ユーザーはViewer相当に分離する |
| 複数ロールで意図せずアクセスが広がる | Role AとRole Bの和集合で見える範囲が増える | ユーザーが所属する全ロールを棚卸しする |
| 配布リストをロールに追加する | SQL endpointでメンバー解決できない場合がある | Microsoft Entraのセキュリティグループを使う |
| グループ変更直後に検証する | 反映待ちやキャッシュで結果がずれる | 反映時間を考慮して再テストする |
| CLSで列名も完全に隠れると思い込む | 一部体験でメタデータが見える可能性がある | 機微列は命名やテーブル分割も検討する |
複数ロールの評価では、基本的にアクセス範囲は和集合として広がります。RLSは述語がORで結合され、CLSも複数ロールの組み合わせで評価されます。つまり、「別々のロールなら安全」とは限りません。ユーザーが複数グループに属している場合は、有効権限を必ず確認してください。(Microsoft Learn)
制限事項と反映時間も運用設計に入れる
OneLake securityは即時性が必要な運用にも使えますが、権限変更の反映には一定の時間がかかります。公式情報では、ロール定義の変更は適用まで約5分、OneLake securityロール内のユーザーグループ変更はOneLake側で約1時間、さらに一部Fabricエンジンのキャッシュにより追加で時間がかかる可能性があるとされています。(Microsoft Learn)
また、B2BゲストユーザーをOneLake securityロールに割り当てる場合は、Microsoft Entra External IDの外部コラボレーション設定で、ゲストユーザーがメンバーと同等にアクセスできる設定が必要です。SQL endpointでは配布リストのメンバーを解決できない制限もあるため、外部ユーザーや部門横断グループを使う組織では特に注意が必要です。(Microsoft Learn)
運用上の上限として、OneLake securityロールはFabricアイテムごとに250ロール、ロールごとのメンバーは500ユーザーまたはユーザーグループ、ロールごとの権限は500権限とされています。ロール数は申請により1000まで増やせる可能性がありますが、最初から細かすぎるロール設計にすると管理負荷が高くなります。(Microsoft Learn)
実務での展開手順
OneLake securityを本番展開する場合は、いきなり全Lakehouseへ適用するのではなく、影響の小さいアイテムから段階的に進めるのが現実的です。
| フェーズ | 作業内容 | 成功条件 |
|---|---|---|
| 棚卸し | Lakehouse、SQL analytics endpoint、セマンティックモデル、Notebookを一覧化する | データ参照経路が把握できている |
| 権限設計 | 部門、役割、データ分類ごとにロールを設計する | 個人ではなくグループで管理できる |
| パイロット | 低リスクなLakehouseでロールを作成する | テストユーザーで期待どおりに見える |
| 既定ロール調整 | DefaultReaderやReadAllを見直す | 不要な広範囲アクセスが残っていない |
| SQL確認 | endpointをUser’s identity access modeにする | SQLクエリ結果にRLS / CLSが反映される |
| 複数経路テスト | Spark、SQL、Direct Lake、APIで確認する | すべての経路で想定外の露出がない |
| 展開・文書化 | 命名規則、申請フロー、変更反映時間を記録する | 運用担当者が迷わず変更できる |
おすすめは、最初に「閲覧だけを制限するロール」から始めることです。ReadWrite、RLS、CLS、ショートカットを同時に展開すると、問題発生時に原因を切り分けにくくなります。まずテーブル・フォルダー単位のRead制御を安定させ、その後にRLS、CLS、ReadWriteを追加していくと安全です。
管理者・開発者向けチェックリスト
本番展開前には、次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| 対象アイテム | Lakehouse、Azure Databricks Mirrored Catalog、Mirrored Databasesのどれか |
| 既定ロール | DefaultReaderが不要に広いアクセスを与えていないか |
| ワークスペース権限 | Admin、Member、Contributorに制限対象ユーザーが残っていないか |
| アイテム権限 | Read、ReadAll、Writeの実効権限を確認したか |
| SQL endpoint | User’s identity access modeに設定されているか |
| グループ設計 | 配布リストではなくMicrosoft Entraの適切なグループを使っているか |
| RLS | 述語がシンプルで、文字列比較に依存しすぎていないか |
| CLS | 非表示列の値が見えないことを複数経路で確認したか |
| ReadWrite | RLS / CLSと同じロールに入れようとしていないか |
| ショートカット | 内部・外部ショートカットのターゲット権限も確認したか |
| 反映時間 | 変更直後のテスト結果だけで判断していないか |
| 監査 | ロール名、対象スコープ、メンバー、変更理由を記録しているか |
まずはDefaultReaderとSQL analytics endpointから確認する
Microsoft FabricのOneLake securityは、OneLake上のデータを細かく保護するための重要な機能です。特に2026年5月時点では、GAとして整理された機能を本番運用に取り込むため、既存のワークスペース権限やDefaultReader、SQL analytics endpointのアクセスモードを見直す必要があります。
最初にやるべきことは明確です。対象Lakehouseを1つ選び、DefaultReaderとReadAllの状態を確認し、SQL analytics endpointがUser’s identity access modeになっているかを確認してください。そのうえで、部門別または用途別に最小権限のOneLake securityロールを作成し、テストユーザーでLakehouse、Spark、SQL、Direct Lakeの各経路を検証します。これにより、「設定したつもり」のセキュリティではなく、実際の利用経路で確実に効くセキュリティ設計に近づけます。
コメント