はじめに
2025/12 時点の OneLake のデータ共有とアクセス制御についてまとめます。
今後の Fabric の活用で重要な要素となる、OneLake セキュリティについて実際の動作を確認してみます。
関連記事
併せて参照していただくとより理解が深まるかと思います。
OneLake 上のデータアクセス制御の仕組みを理解する
安全なデータ共有をするためには、背景の仕組みを理解することが重要です。
OneLake の実体はテナントレベルでのストレージであり、「ワークスペース」、「アイテム」、「テーブルまたはファイル用フォルダ」の3階層がディレクトリとして表現されます
それぞれの階層ではそのスコープに対応する権限制御の設定があります。
ワークスペースロール
ワークスペースロールの権限のスコープはワークスペース全体であり、ワークスペース内のアイテム全てに対して権限が継承されます。
| ロール | 説明 |
|---|---|
| 管理者 | 全ての権限をもち、唯一ワークスペース自体の管理が可能 |
| メンバー | 開発作業およびメンバー追加や、再共有の権限をもつ |
| 共同作成者 | 開発作業の権限をもつ |
| ビューアー | ワークスペース内の全てのアイテムとその中のテーブルの表示権限を持つ |
参考:https://learn.microsoft.com/ja-jp/fabric/get-started/roles-workspaces
アイテム権限
アイテム権限のスコープは対象アイテム全体であり、アイテム内の全てのテーブルやファイルに対して権限が継承されます。
| 権限 | 説明 |
|---|---|
| 読み取り | メタデータの表示。OneLake カタログにアイテムが表示され、接続できる(データアクセスは不可) |
| 書き込み | アイテムの設定を変えたり、データの書き込みが可能 |
| 再共有 | アイテムを再共有可能 |
| ビルド | (セマンティックモデル限定)モデルを使用してレポートを作成可能 |
| ReadData | T-SQLを通してテーブルデータを表示、クエリ可能 |
| ReadAll | Sparkや OneLake API を通してアイテム背後のすべての Filesや Tables(背後のDeltaParquet)に直接アクセス |
参考:https://learn.microsoft.com/ja-jp/fabric/data-warehouse/share-warehouse-manage-permissions
コンピューティングエンジンでのデータ制御
コンピューティングエンジンでのデータ制御では、データを表示する際に使用されるエンジンで設定を行うことで、テーブルの行や列ごとにアクセス可否を決定できます。
たとえば、 SQL ワークロードでは、 T-SQL により、行レベルセキュリティや、オブジェクトレベル、データマスキングの設定が可能です。
参考:https://learn.microsoft.com/ja-jp/fabric/data-warehouse/security#object-level-security
ウェアハウスの内部にはストレージ(OneLake)とコンピューティングエンジン(T-SQL)がありますが、
レイクハウスはコンピューティングエンジンを持たないため、付随する SQL 分析エンドポイントで SQL ワークロードを実行します。
また、Power BI ワークロードの場合、セマンティックモデル内で行レベルセキュリティ、オブジェクトレベルセキュリティ設定を行うことができます。
Direct Lake on SQL (セマンティックモデルがSQLコンピューティングを経由している方式)

Direct Lake on OneLake (セマンティックモデルがストレージ層に直接アクセスしている方式)

Direct Lake には、on SQLと on OneLake の二つのフレーバーがあり、その際に動作する仕組みも異なることを理解しておくと理解に役立ちます。
コンピューティングによるデータアクセス制御の課題
ここまでの方式は、データを表示するコンピューティングエンジン側で行や列などの詳細なデータアクセス制御を実装する方式です。
ですが、ウェアハウスで設定したRLS設定などは、ノートブックや、Direct Lake on OneLake などの 直接ストレージにアクセスする方式 のコンピューティングアイテムには適用されません。
Fabric OneLake において、様々なワークロードで同じデータを再利用するという OneCopy のコンセプトを踏まえると、使用するコンピューティングにより表示されるデータが異なるというのは、ガバナンス上の大きな課題となりえます。
OneLake Security での制御
現在(2025/12時点)プレビューとなっている、OneLake セキュリティ では、ストレージ層で直接アクセス制御を実装することでガバナンスを強化します。

現在(2025/12時点)、OneLake セキュリティは、レイクハウスまたは Azure Databricks ミラー化カタログでのみ構成可能です。
OneLake セキュリティでは、
が適用できます。
OneLakeセキュリティを使用した共有例
OneLake セキュリティを使用したワークスペース間データ共有では、共通のセキュリティポリシーを複数の利用目的に対応させることができます。
アナリストによる DWH データ利用
一般的なパターンとして、Silver 領域(整備済みの汎用データ)をデータエンジニアが作成し、別のワークスペースでアナリストが BI 用にデータ準備をするパターンがあります。
設定の実践

アナリストによる DWH データ利用をイメージして、実際に OneLake セキュリティがどのように動作するか確認してみます。
参考:https://learn.microsoft.com/en-us/fabric/onelake/security/get-started-onelake-security
【データエンジニア】OneLake セキュリティの設定
まず、ソースのレイクハウスで、OneLake セキュリティの設定が必要です。
-
SQL エンドポイントに移動して、ユーザーアクセスモードをユーザーIDに変更します。これで、T-SQL処理が動作した際には OneLake セキュリティで設定したアクセスロールに基づいてデータが制御されます。


委任モードでは クエリの実行者ではなく、SQL 分析エンドポイントの所有者の権限でショートカットデータにアクセスするため注意が必要です。
-
行レベルセキュリティ:dimension_city で City = Troy のデータのみが表示されるように制限します。


-
対象のデータアクセスロールは以下のようなセキュリティ設定となりました。
テーブル 制御 fact_sale 全データ閲覧可能 dimension_city City = Troy のデータのみが表示 dimension_customer PostalCode は参照不可 他のテーブル 閲覧不可 本来なら fact_sale も Troy 関連データのみとしたいところですが、複数のテーブルの結合を使用した行レベルセキュリティは現在サポートされていません。
【データエンジニア】レイクハウスの共有
-
対象のレイクハウスの共有ボタンで、 すべての SQL エンドポイントデータの表示 アクセスを追加して、対象ユーザーに共有します。


通常、この追加アクセスは全てのテーブルデータを参照可能としますが、OneLake セキュリティが有効な場合は、OneLakeセキュリティが優先されるようです。なお、読取だけの権限だとデータ表示自体の権限がないと判定されて、403 エラーが発生します。
【アナリスト】Hub レイクハウスの作成
共有されたデータをスムーズに使うために、Hub レイクハウスの作成をおすすめします。
-
ショートカットが作成でき、データ再利用の準備が整いました。
行・列レベルが設定されたテーブルは現時点ではレイクハウスの画面ではエラー表示となるようです。
【アナリスト】SQL での表示確認
SQL 分析エンドポイントで簡単に確認しておきます。
【アナリスト】データフロー Gen2の確認
アナリストは、データを最適化して分析用のデータに整形するために、データフロー Gen2 を使用します。
【アナリスト】セマンティックモデルの確認
通常アナリストはデータを準備してからセマンティックモデルを作成しますが、データ探索をする際など、共有されたデータをそのままモデル化する場合もあります。
-
現時点では SQL 分析エンドポイントのボタンからセマンティックモデルを作成すると、Direct Lake on SQL となるため、レイクハウス上のボタンまたは新規アイテムの作成からセマンティックモデルを作成します。
-
リレーションシップを作成します。
-
適当なレポートを作成して、表示を確認します。
現時点だとセキュリティフィルターを設定しても、fact_saleのデータが絞り込まれませんでした。プレビューの問題かもしれません。
【データサイエンティスト】ノートブックでの確認
データサイエンティスト的なデータ消費として、ノートブックでも OneLake セキュリティが効いていることを確認します。
-
dimension_cityデータの表示を確認します。Troy のデータのみが表示されます。

RLSorCLS がかかっている場合、ファイルへの直接アクセスはブロックされ、エラーとなるようです。

OneLakeはユニバーサルセキュリティを厳格に施行し、不正な侵入点が一切ないようにしています。行レベルおよびカラムレベルのセキュリティポリシーを持つテーブルへのファイルレベルへの直接アクセスは厳しく禁止されています。同様に、Sparkコードはテーブルの直接ファイルパスを指定することでアクセスできません。アクセスは lakehouse.schema.table のような Spark SQL の名前空間参照を通じて行う必要があります。
引用翻訳元:https://blog.fabric.microsoft.com/en-US/blog/how-spark-supports-onelake-security-with-row-and-column-level-security-policies/ -
dimension_customer データの表示を確認します。PostalCode 以外の列が表示されます。

SQL実行とセマンティックモデルとは異なり、Spark でのアクセスは、自動的に列がしぼられ、SELECT * でもエラーを出さないで済みます。
引用:https://learn.microsoft.com/en-us/fabric/onelake/security/column-level-security
以上、参考になれば幸いです。














































