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 により、より細かい制御が可能です。 テーブル・フォルダ・行・列レベルまで、ストレージレイヤーで一元管理できます。