はじめに
この記事では、Fabric のデータアクセス制御に関する基本的な考え方を紹介します。特に、ワークスペース、アイテム、エンジンといったスコープに基づいた権限設定について詳しく説明し、実際の設定方法を解説します。
2024/12 時点の情報です。
権限のスコープと継承
OneLake は「組織に1つのデータレイク」という考えのもと、Fabric ワークスペースと密接に結びついています。
ワークスペースは OneLake において共同作業をするためのフォルダーで、レイクハウス、ウェアハウスなどのアイテムはそれぞれが管理する構造化（Deltaテーブル）/非構造化ファイルを管理するためのサブフォルダです。
データアクセス制御およびデータ保護も同様のスコープで定義され、ワークスペース、アイテム、エンジンの3つの階層構造のスコープで整理することが可能です。
また、Read/Write のような基本的な権限は継承関係があり、原則として、上位スコープで保持する権限が優先されます。
したがって、
- ワークスペースロールを付与した場合には 特定のアイテムのみ閲覧可能にはできない
- 特定のアイテムで共有した場合には、特定のテーブルのみを閲覧可能にはできない
といった注意点が発生します。
Read / Write 権限について
基本的な権限がどのスコープで付与可能かは以下の通りです。
| スコープ | Read 付与 | Write 付与 |
|---|---|---|
| ワークスペース | 〇 | 〇 |
| アイテム | 〇 | ×（セマンティックモデルは可能） |
| エンジン | 〇 | エンジンにより異なる |
Fabric アイテムレベルのデータ共有設定には原則、Write 権限にまつわるものが存在しないため、Write は原則ワークスペースロールで制御します。あるいは、特定のテーブルのみ書き込みを許可したい場合にはエンジン内のポリシー設定で対応することになります。
ただし、レイクハウスでは特定のフォルダやテーブルのみを書き込み可能にするような、きめ細やかなアクセス制御機能はないことに注意が必要です。
一方で、ウェアハウス（T-SQL）と KQLデータベース（KQL）では Write 権限を付与可能です。
各スコープでの権限制御について
ワークスペース
ワークスペースはロールベースのアクセス制御でアクセス権の設定を行います。
| ロール | 説明 |
|---|---|
| 管理者 | 全ての権限をもち、唯一ワークスペース自体の管理が可能 |
| メンバー | 開発作業およびメンバー追加の権限をもつ |
| 共同作成者 | 開発作業の権限をもつ |
| ビューアー | アイテムおよびデータの表示権限を持つ |
詳細は Microsoft Fabric のワークスペースのロール を参照してください。
設定はワークスペース画面のアクセス管理から行います。
Fabric 管理者などの Entra ID テナントのディレクトリロールは、ワークスペース一覧から任意のワークスペースのアクセス管理を行うことが可能です。
アイテム
アイテムにはアイテム固有の権限が存在します。
参考：https://learn.microsoft.com/ja-jp/fabric/data-warehouse/share-warehouse-manage-permissions
| 権限 | 説明 |
|---|---|
| 読み取り | OneLake カタログにアイテムが表示され、接続できる（データアクセスは不可） |
| 書き込み | アイテムの設定を変えたり、データの書き込みが可能 |
| 再共有 | アイテムを再共有可能 |
| ビルド | （セマンティックモデル限定）モデルを使用してレポートを作成可能 |
| ReadData | T-SQLを通してテーブルデータを表示、クエリ可能 |
| ReadAll | Sparkや OneLake API を通して Fileや Tables（背後のDeltaParquet）に直接アクセスおよびショートカットソースとして利用可能 |
共有ボタンでアクセス権付与が可能です。
共有ボタンでは文章になっていますが、以下のように権限とマッピングされます。
- すべての SQL エンドポイントデータを読み取る = ReadData
- すべての Apache Spark を読み取る = ReadAll
- 既定のセマンティックモデルでレポートをビルドします = ビルド
アイテムのアクセス管理メニューからも設定が可能です。
レイクハウスでは ViewLogs , ViewOutput 実行といった権限が表示されますが、現時点では仕様が公開されていないようです。
また、ReadDataについては、付随するSQL 分析エンドポイント側での管理となります。
ReadData と ReadAllについて
ReadData と ReadAll は、Fabric でのデータアクセス権限の異なる種類です。
データが必要な場合とファイルアクセスが必要な場合で使い分けることになります。
- ReadData: SQLによるデータ分析やレポート作成時に使用します。
- ReadAll: Spark や OneLake API での生データ処理を行う場合に使用します。
エンジン固有の設定
レイクハウス (Spark エンジン)
読取の制御のみ、 OneLake データアクセスロール （プレビュー）にてレイクハウスの Files / Tables フォルダレベルでの制御 が可能です。
ただし、DeltaParquet などの OneLake API に直接アクセスする Spark のワークロード内では行レベルセキュリティや動的マスキングなどの機能は現時点では存在しません。
ほとんどの場合、オブジェクトレベルのセキュリティや行レベルのセキュリティは Spark ではなく、SQL 分析で必要とされるものなので、レイクハウス上のデータに対してそうした制御をかけたい場合には、SQL 分析エンドポイントで設定を行います。
ウェアハウス / SQL 分析エンドポイント (T-SQL エンジン)
DENY / GRANT / REVOKE といった DCL にて、テーブル、ビュー、プロシージャに対する オブジェクトレベル、列レベル のアクセス制御が可能です。
また、セキュリティ述語関数を用いた 行レベルセキュリティ や、ADD MASK を使用した動的データマスキングを構成してデータを保護することもできます。
引用：https://learn.microsoft.com/ja-jp/fabric/data-warehouse/security#object-level-security
学習コンテンツ：https://learn.microsoft.com/ja-jp/training/modules/secure-data-warehouse-in-microsoft-fabric/
KQL データベース (Kusto エンジン)
データベースレベル、テーブルレベルでのロールベースアクセス制御が可能です。
データベースとテーブルの中間としてスキーマのような単位でアクセス制御範囲をまとめることができないので、特定のテーブルを見せる、見せないなどの制御は制限付き閲覧アクセスポリシー を使用するのが良いと思います。
また、行レベルセキュリティポリシーをテーブルに構成することも可能です。
セマンティックモデル (Analysis Service エンジン)
RLS(行レベルセキュリティ) と OLS(オブジェクトレベル) のアクセス制御が利用可能です。
RLSでは、2つのフィルター方式で表示レコードの制御をすることが可能です。
-
静的なフィルター
ロールごとに定数値を直接フィルターに記述する方式です。フィルタ値ごとにロールの数は増えますが、簡単に構成が可能です。
-
動的なフィルター
アクセスするユーザーとフィルタ値をマッピングしたテーブルを用意して、ユーザーごとにフィルタ値が変わるようにする方式です。ロールが一つで構成できますが、ユーザープリンシパルのテーブル管理が必要となります。
オブジェクトレベルでは、テーブルや列レベルでのアクセス制御が可能ですが、Tablular Editor などの 外部ツールを使用しないと構成できない点に注意してください。
まとめ
アクセス制御の知識は、ワークスペースを何個セットで構成するか、どのようにデータの交換をするかなど、Fabric のガバナンス設計に大きく影響する重要な要素です。
特に、メダリオンアーキテクチャ など複数のデータベース構成をする際には、ワークスペースを分けるべきか、分けないべきかを決定する際の重要な要素となるので、しっかりと押さえておきましょう。