はじめに

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 ワークロードの場合、セマンティックモデル内で行レベルセキュリティ、オブジェクトレベルセキュリティ設定を行うことができます。

参考：https://learn.microsoft.com/ja-jp/training/modules/enforce-power-bi-model-security/2-restrict-access-to-power-bi-model-data

Direct Lake on SQL (セマンティックモデルがSQLコンピューティングを経由している方式)

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

Direct Lake には、on SQLと on OneLake の二つのフレーバーがあり、その際に動作する仕組みも異なることを理解しておくと理解に役立ちます。

https://learn.microsoft.com/ja-jp/fabric/fundamentals/direct-lake-overview#comparison-of-storage-modes

コンピューティングによるデータアクセス制御の課題

ここまでの方式は、データを表示するコンピューティングエンジン側で行や列などの詳細なデータアクセス制御を実装する方式です。

ですが、ウェアハウスで設定したRLS設定などは、ノートブックや、Direct Lake on OneLake などの 直接ストレージにアクセスする方式 のコンピューティングアイテムには適用されません。

Fabric OneLake において、様々なワークロードで同じデータを再利用するという OneCopy のコンセプトを踏まえると、使用するコンピューティングにより表示されるデータが異なるというのは、ガバナンス上の大きな課題となりえます。

OneLake Security での制御

現在(2025/12時点)プレビューとなっている、OneLake セキュリティ　では、ストレージ層で直接アクセス制御を実装することでガバナンスを強化します。

現在(2025/12時点)、OneLake セキュリティは、レイクハウスまたは Azure Databricks ミラー化カタログでのみ構成可能です。

OneLake セキュリティでは、

が適用できます。

OneLakeセキュリティを使用した共有例

OneLake セキュリティを使用したワークスペース間データ共有では、共通のセキュリティポリシーを複数の利用目的に対応させることができます。

アナリストによる DWH データ利用

一般的なパターンとして、Silver 領域（整備済みの汎用データ）をデータエンジニアが作成し、別のワークスペースでアナリストが BI 用にデータ準備をするパターンがあります。

OneLake セキュリティを使用しない場合、レイクハウスのすべてのテーブルを共有するか、テーブルレベルで制御をかける場合には T-SQL のセキュリティ設定をかける必要があります。

なお、テーブルレベルでの制御が必要な場合には、全てのファイルアクセスを許可する Read All 権限を与える必要があるため、ショートカットは許可できない状態になります。
ショートカットを使用した共有をしたい場合には、共有したいテーブルのセットごとにレイクハウス/ウェアハウスを作成するなどの対応が必要でした。

設定の実践

アナリストによる DWH データ利用をイメージして、実際に OneLake セキュリティがどのように動作するか確認してみます。

参考：https://learn.microsoft.com/en-us/fabric/onelake/security/get-started-onelake-security

【データエンジニア】OneLake セキュリティの設定

まず、ソースのレイクハウスで、OneLake セキュリティの設定が必要です。

対象のレイクハウスを OneLake セキュリティのオプトインします。
SQL エンドポイントに移動して、ユーザーアクセスモードをユーザーIDに変更します。これで、T-SQL処理が動作した際には OneLake セキュリティで設定したアクセスロールに基づいてデータが制御されます。

委任モードではクエリの実行者ではなく、SQL 分析エンドポイントの所有者の権限でショートカットデータにアクセスするため注意が必要です。
ロールが参照可能なテーブルを設定し、データアクセスロールを作成します。
追加の制御を行うために、データアクセスロールの編集に移動します。
行レベルセキュリティ：dimension_city で City = Troy のデータのみが表示されるように制限します。
列レベルセキュリティ：dimension_customer で、 PostalCode は参照不可にします。

対象のデータアクセスロールは以下のようなセキュリティ設定となりました。

テーブル	制御
fact_sale	全データ閲覧可能
dimension_city	City = Troy のデータのみが表示
dimension_customer	PostalCode は参照不可
他のテーブル	閲覧不可

本来なら fact_sale も Troy 関連データのみとしたいところですが、複数のテーブルの結合を使用した行レベルセキュリティは現在サポートされていません。

最後に、対象のユーザーをロールに割り当てます。

【データエンジニア】レイクハウスの共有

対象のレイクハウスの共有ボタンで、 すべての SQL エンドポイントデータの表示 アクセスを追加して、対象ユーザーに共有します。

通常、この追加アクセスは全てのテーブルデータを参照可能としますが、OneLake セキュリティが有効な場合は、OneLakeセキュリティが優先されるようです。なお、読取だけの権限だとデータ表示自体の権限がないと判定されて、403 エラーが発生します。

【アナリスト】Hub レイクハウスの作成

共有されたデータをスムーズに使うために、Hub レイクハウスの作成をおすすめします。

レイクハウスを作成し、OneLake セキュリティをオプトインします。
データエンジニアの作業と同様に、SQL エンドポイントのユーザーアクセスモードをユーザーIDに変更します。
ショートカットを作成します。

データアクセスロールに設定されたテーブルだけが表示されています。
ショートカットが作成でき、データ再利用の準備が整いました。

行・列レベルが設定されたテーブルは現時点ではレイクハウスの画面ではエラー表示となるようです。

【アナリスト】SQL での表示確認

SQL 分析エンドポイントで簡単に確認しておきます。

fact_sale は問題なく表示されます。
行レベルセキュリティが適用され、 Troy のデータだけの表示になっています。
列レベルセキュリティにより、PostalCodeを含むクエリがブロックされます。
PostalCode をコメントアウトすると正常に表示されます。

【アナリスト】データフロー Gen2の確認

アナリストは、データを最適化して分析用のデータに整形するために、データフロー Gen2 を使用します。

データフロー Gen2 を作成し、OneLake カタログから Hub レイクハウスを参照します。
対象のテーブルを選択します。
データのプレビューで、dimension_city に行レベルセキュリティがかかっていることがわかります。
dimension_customer のクエリはデフォルトでは対象にPostal コードをふくむのでエラー表示になります。
Postal Code を含まないように修正すると、データが表示されます。
ウェアハウスへの同期を設定します。
データフローを実行し、データロードが成功することを確認しておきます。
行レベルセキュリティがかかっているので、ウェアハウスには Troy のデータだけがロードされた状態となりました。

【アナリスト】セマンティックモデルの確認

通常アナリストはデータを準備してからセマンティックモデルを作成しますが、データ探索をする際など、共有されたデータをそのままモデル化する場合もあります。

Hub レイクハウスからセマンティックモデルを作成します。

現時点では SQL 分析エンドポイントのボタンからセマンティックモデルを作成すると、Direct Lake on SQL となるため、レイクハウス上のボタンまたは新規アイテムの作成からセマンティックモデルを作成します。
テーブルを選択します。列レベルセキュリティを含むテーブルはエラーが発生するため、customer は除きました。
リレーションシップを作成します。
適当なレポートを作成して、表示を確認します。

現時点だとセキュリティフィルターを設定しても、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

以上、参考になれば幸いです。