Fabric は Azure 上にあるが、アクセス制御は Azure RBAC とは別
GW中に Fabric Security が GA (一般提供開始) したので紹介記事を書こうと思ったのですが、そもそもこの前提から押さえるべきと思い至りました。
もしあなたがAzure 管理者で「Fabric 使いたいから Azure のサブスクリプションをください」と言われたものの、Fabric って何？ということでしたら、こちらの記事を先にご覧いただくことをお勧めします。
Microsoft Fabric は Azure 上に構築された統合分析プラットフォームです。Fabric のキャパシティ (容量) は Azure ポータルで作成する ARM リソース（Microsoft.Fabric/capacities）であり、課金も Azure サブスクリプションに紐づきます。
しかし、ワークスペースの内部（データ・アイテム・レポートなど）は ARM リソースとして存在しません。つまり Azure RBAC のロール割り当てでは、ワークスペース内のデータへのアクセスを制御できないのです。
ここが多くの Azure 管理者にとって最初の「驚きポイント」になります。たとえ Azure サブスクリプションの Owner ロールを持っていたとしても、Fabric 内のロールを別途割り当てられなければ、ワークスペース内のデータには一切アクセスできません。
【Azure の世界 — Azure RBAC で制御】
サブスクリプション
└─ リソースグループ
└─ Microsoft.Fabric/capacities
【Fabric の世界 — Fabric 独自の権限モデルで制御】
テナント
└─ Fabric Admin
└─ Capacity Admin (既定では Fabric キャパシティ作成者)
└─ Workspace Roles (Admin / Member / Contributor / Viewer)
└─ Item permissions
└─ OneLake Security / Compute permissions (RLS/CLS)
この境界を正しく理解することが、Fabric のセキュリティ設計の第一歩です。
Fabric における Azure RBAC の制御範囲
Azure RBAC が制御するのは、あくまで キャパシティという ARM リソースの管理操作 だけです。具体的には以下の操作が対象になります。
| 操作 | 必要な Azure RBAC ロール（または権限） |
|---|---|
| キャパシティの作成 | Contributor 以上、または Microsoft.Fabric/capacities/write
|
| キャパシティの削除 | Contributor 以上、または Microsoft.Fabric/capacities/delete
|
| キャパシティのスケールアップ/ダウン | Contributor 以上、または Microsoft.Fabric/capacities/write
|
| キャパシティの一時停止 | Contributor 以上、または Microsoft.Fabric/capacities/suspend/action
|
| キャパシティの再開 | Contributor 以上、または Microsoft.Fabric/capacities/resume/action
|
| キャパシティの参照 | Reader 以上、または Microsoft.Fabric/capacities/read
|
これらの操作は Azure ポータル、Azure CLI、ARM テンプレート（Bicep）で実行できます。ここまでは「普通の Azure リソース管理」の範疇です。
しかし、ワークスペースの作成、アイテムの読み書き、データへのクエリなどは、Fabric 独自の権限モデルで制御されます。
権限の評価フロー
Fabric がアクセス要求を評価する順序は以下のとおりです。各ステップで拒否されると、後続の評価は行われません。
Step 2 と Step 3 が Fabric 独自の権限モデルにあたります。次章以降で、この 2 つのステップに関わる 4 つのレイヤーを詳しく見ていきます。
Fabric の権限モデル
Fabric のデータアクセス制御は、以下の 4 つのレイヤーで構成されています。上位レイヤーで許可されていない場合、下位の設定は評価されません。
1 ワークスペース ロール
ワークスペースロールは Fabric のアクセス制御の基本単位です。4 つのロールがあり、割り当て対象はユーザー・セキュリティグループ・サービスプリンシパルです。
| 権限 | Admin (管理者) |
Member (メンバー) |
Contributor (共同作成者) |
Viewer (ビューアー) |
|---|---|---|---|---|
| ワークスペース削除 | ✅ | — | — | — |
| 他のユーザーを Admin に追加 | ✅ | — | — | — |
| Member/Contributor/Viewer 追加 | ✅ | ✅ | — | — |
| アイテム作成・編集 | ✅ | ✅ | ✅ | — |
| OneLake データ読み書き（既定） | ✅ | ✅ | ✅ | — |
| レポート・ダッシュボード閲覧 | ✅ | ✅ | ✅ | ✅ |
ポイント: Admin / Member / Contributor は既定で OneLake のデータに対してフルアクセスを持ちます。Viewer はレポートやダッシュボードなど「公開されたビュー」を通じてデータを閲覧できますが、OneLake に格納されている生データ（Delta テーブル、Parquet ファイルなど）に直接アクセスすることはできません（後述の OneLake Security ロールで明示的に付与する必要があります）。
2 アイテムレベル権限
ワークスペース内の個別アイテム（レイクハウス、ウェアハウス、レポートなど）を「共有」機能で特定のユーザーに公開する場合、アイテムレベルの権限が適用されます。ワークスペース ロールを付与せずに、特定のアイテムだけへのアクセスを許可したいケースで使います。
多用すると権限管理が煩雑になるため、慎重に利用することをお勧めします。
3 Compute permissions（RLS / CLS）
SQL エンドポイントやセマンティック モデルのコンピュート レイヤーで、行レベルセキュリティ（RLS）や列レベルセキュリティ（CLS）を追加で適用できます。
-
SQL 分析エンドポイント: T-SQL の
GRANT/DENY/CREATE SECURITY POLICYで制御 - セマンティック モデル: DAX による RLS ルール定義
4 OneLake Security ロール（OneLake セキュリティ）
OneLake のストレージレイヤーに直接ポリシーを設定し、テーブル・フォルダ単位でアクセスを制御します。
(詳細は別記事にて)
- Deny-by-default: ロールで明示的に許可されたデータのみアクセス可能
- ワークロード横断: Spark、SQL 分析エンドポイント、Power BI いずれの経路でも一貫して適用
- 対象: Viewer ロールまたはアイテム共有で Read 権限のみを持つユーザーに対して有効（Admin / Member / Contributor には適用されません）
よくある誤解
誤解 1:「Azure サブスクリプション Owner = Fabric の全権限」
事実: Azure サブスクリプション Owner はキャパシティの ARM 管理操作しかできません。ワークスペースのデータを閲覧するには、別途 Fabric ワークスペース ロールかアイテムへの直接のアクセス許可の割り当てが必要です。
Fabric 用のサブスクリプションを提供する代わりに、テナント管理者側で適切なサブスクリプションに Fabric キャパシティを作成して、Capacity Admin の権限を依頼者に付与するという方法を取ることも可能です。こうすることで、課金に直結する Fabric Capacity というインフラの管理については、中央で制御することもできます。誰が何をコントロールするのか、利用開始前にしっかり検討いただくことをお勧めします。
誤解 2:「Fabric ワークスペースにアクセスするには Azure サブスクリプション権限が必要」
事実: Fabric はSaaSです。Azure サブスクリプションへのアクセス権がなくても、Fabric ワークスペース ロールが付与されていればデータ操作は可能です。エンドユーザーのアナリストが Azure ポータルにアクセスする必要はありません。
誤解 3:「Capacity Admin = Workspace Admin」
事実: Capacity Admin (容量管理者) はキャパシティ全体の設定（ワークスペースの割り当て、スケーリングルール等）を管理するロールです。個々のワークスペース内のデータやアイテムへのアクセスは、Capacity Admin とは別の権限です。
まとめ
Fabric のセキュリティを設計する際は、以下の原則を念頭に置いてご利用ください。
- キャパシティ管理とデータアクセスは完全に別の権限体系です。 Azure RBAC はキャパシティの ARM 操作のみ、データアクセスは Fabric ワークスペースロール以下で制御します。
- 最小権限の原則を各レイヤーで適用してください。 「とりあえず Contributor」ではなく、業務に必要な最小ロールを選択します。
- OneLake Security により、より細かい制御が可能です。 テーブル・フォルダ・行・列レベルまで、ストレージレイヤーで一元管理できます。