Workspace identity – Microsoft Fabricは、Microsoft Fabricのワークスペースにひも付く自動管理のサービスプリンシパルです。結論から言うと、Microsoft Entra側で資格情報を人手管理せずに、OneLakeショートカット、パイプライン、セマンティックモデル、Dataflows Gen2などから外部リソースへ安全に接続するための仕組みです。2026年5月9日時点で確認すべきポイントは、B2B・クロステナントでは未サポートであること、Entra上のサービスプリンシパルやアプリ登録を不用意に変更・削除してはいけないこと、ただし対象リソースへアクセスするためのAPIアクセス許可追加はサポートされることです。(GitHub)
Microsoft Entra管理者、Fabric管理者、Azure Storage管理者、データエンジニアが特に確認すべきなのは、「誰がWorkspace identityを作れるか」「Entra上でどの権限を持つ管理者が触れるか」「ADLS Gen2や接続先にどのRBAC・ネットワーク許可を与えるか」です。削除や容量移行の影響も大きいため、本番展開前に権限・監査・復旧手順をセットで確認しておく必要があります。(Microsoft Learn)
Workspace identity – Microsoft Fabricとは
Workspace identity – Microsoft Fabricは、Fabricワークスペースに関連付けられるIDです。作成すると、Microsoft FabricがMicrosoft Entra ID内にサービスプリンシパルを作成し、関連するアプリ登録も作成します。Fabric側が資格情報を自動管理するため、ユーザーや開発者がシークレット、キー、証明書を直接管理する必要がありません。(Microsoft Learn)
用途は大きく2つあります。1つ目は、Microsoft Entra認証をサポートするデータソースへ接続する際の認証方式として使うことです。2つ目は、ファイアウォールで保護されたAzure Data Lake Storage Gen2に対して、trusted workspace accessを使い、特定のFabricワークスペースから安全にアクセスすることです。(Microsoft Learn)
AzureのマネージドIDと似ていますが、同じものではありません。Workspace identityのライフサイクル、管理、ガバナンスはFabricによって管理されます。ワークスペースを削除するとWorkspace identityも削除され、ワークスペース名を変更するとWorkspace identity名も変更されます。ただし、Microsoft Entra側のアプリケーションやサービスプリンシパル自体は同じものとして残るため、名前だけで管理すると混乱しやすい点に注意が必要です。(Microsoft Learn)
2026年5月9日時点で見るべき変更点
Microsoft Learnの該当ドキュメントは、ページ上の最終更新日およびGitHub上のメタデータで2026年5月8日更新と確認できます。日本時間で5月9日前後に確認している管理者は、以下の変更点を重点的に見直すとよいでしょう。(Microsoft Learn)
| 確認項目 | 変更・明確化された内容 | 実務上の影響 |
|---|---|---|
| B2B・クロステナント | Workspace identityはB2Bまたはクロステナントのシナリオではサポートされない | 外部テナントのデータソース、ゲストユーザー前提の設計では代替方式を検討する |
| APIアクセス許可 | 対象リソースへのアクセスに必要なAPIアクセス許可を追加することはサポートされる | Entra上のアプリ登録を完全に触ってはいけないのではなく、許可追加は例外的に設計対象になる |
| Entra上の変更 | サービスプリンシパルやアプリ登録の変更・削除は非推奨で、Fabricアイテムの停止につながる可能性がある | Application Administrator権限を持つユーザーを最小限にし、変更履歴を監査する |
| テナント上限 | 既定で10,000件のFabric identityを作成でき、テナント設定で独自の上限を指定できる | 大規模展開では上限管理とMicrosoft Entraのリソース制限を事前確認する |
B2B・クロステナント未サポートの追加は、複数テナント構成やグループ会社間連携を設計している組織に影響します。たとえば、親会社テナントのFabricから子会社テナントのストレージへWorkspace identityで接続する前提の設計は、そのままでは成立しない可能性があります。(GitHub)
APIアクセス許可については、「Entra上の関連アプリには一切触れてはいけない」と理解すると不正確です。公式情報では、対象リソースへのアクセスを許可するためにAPIアクセス許可を追加することはWorkspace identityでサポートされると整理されています。一方で、サービスプリンシパルやアプリ登録そのものを変更・削除すると、Workspace identityに依存するFabricアイテムが停止する可能性があります。(GitHub)
影響を受けるユーザーと役割
Workspace identityはFabricだけの話ではありません。実際の運用では、Microsoft Entra、Azure Storage、Microsoft Purview、Fabricワークスペースの権限管理が交差します。誰がどこまで責任を持つかを曖昧にすると、接続エラー、過剰権限、監査漏れが起きやすくなります。(Microsoft Learn)
| 役割 | 主な確認内容 |
|---|---|
| Fabric管理者 | 管理ポータルのFabric identitiesタブで、テナント内のWorkspace identityを棚卸しする |
| ワークスペース管理者 | Workspace identityの作成・削除、ワークスペースロール、接続設定を確認する |
| Microsoft Entra管理者 | Enterprise applications、App registrations、Application Administrator権限、監査ログを確認する |
| Azure Storage管理者 | ADLS Gen2のRBAC、ファイアウォール、resource instance ruleを設定する |
| データエンジニア・開発者 | OneLakeショートカット、パイプライン、セマンティックモデル、Dataflows Gen2で認証方式を確認する |
| セキュリティ・監査担当 | Purview Audit LogとEntraのサインインログ・監査ログを確認する |
ワークスペース管理者はWorkspace identityを作成・削除できます。ただし、Workspace identityを接続の認証方式として構成できるのは、ワークスペース内のAdmin、Member、Contributorロールを持つユーザーです。閲覧者が勝手にIDを使って接続を作る、という運用にはならない一方で、Contributor以上の権限付与は慎重に扱う必要があります。(Microsoft Learn)
Microsoft Entra側では、Application Administratorまたはそれ以上の権限を持つユーザーが、Workspace identityに関連するサービスプリンシパルやアプリ登録を表示、変更、削除できる可能性があります。Application Administratorはアプリ登録やエンタープライズアプリを広く管理でき、アプリ資格情報の管理を通じてアプリIDをなりすませるリスクもあるため、最小権限での割り当てが重要です。(Microsoft Learn)
管理者が最初に確認すべき設定
最初に見るべき場所は、Fabric管理ポータル、Microsoft Entra管理センター、Azure Storage、Microsoft Purviewの4か所です。Workspace identityは1つの画面で完結する機能ではないため、設定値だけでなく「どのチームがどの画面を管理するか」まで決めておくと運用トラブルを減らせます。(Microsoft Learn)
Fabric管理ポータルで確認すること
Fabric管理者は、Admin portalのFabric identitiesタブでテナント内のFabric identityを確認できます。この一覧では、ID名、サービスプリンシパルID、状態、ワークスペースIDを確認でき、詳細画面ではWorkspace name、Application ID、Tenant ID、Roleなども確認できます。(Microsoft Learn)
実務では、少なくとも次の項目を棚卸ししてください。
- どのワークスペースにWorkspace identityが作成されているか
- StateがActive以外になっていないか
- 不要になったワークスペースのIDが残っていないか
- 削除予定のIDに依存するショートカット、パイプライン、セマンティックモデル、Dataflows Gen2がないか
- テナント全体のFabric identity数が上限に近づいていないか
Fabric identitiesタブでは一覧の更新やCSVエクスポートも可能です。月次の棚卸しや監査証跡の補助資料として、CSVを保存しておくと変更追跡に使いやすくなります。(Microsoft Learn)
Microsoft Entraで確認すること
Workspace identityに関連するアプリケーションは、AzureポータルのMicrosoft Entra IDでEnterprise applicationsとApp registrationsの両方から確認できます。Enterprise applications側では監査ログやサインインログも確認できます。(Microsoft Learn)
ここで重要なのは、Entra上に見えるからといって通常のアプリ登録と同じ感覚で編集しないことです。公式情報では、関連するサービスプリンシパルやアプリ登録を変更・削除するとWorkspace identityが停止し、依存するFabricアイテムが動かなくなる可能性があるとされています。対象リソースへのアクセスに必要なAPIアクセス許可の追加はサポートされますが、それ以外の変更は変更管理プロセスに載せるべきです。(GitHub)
Microsoft Purviewで確認すること
監査担当者はMicrosoft Purview Audit LogでWorkspace identity関連のイベントを確認できます。公式情報では、Activitiesのfriendly namesで「fabric identity」を検索すると、作成、取得、削除、トークン取得に関するイベントを確認できるとされています。(Microsoft Learn)
特に本番環境では、次のイベントを定期的に確認してください。
| 監査イベント | 確認すべき観点 |
|---|---|
| Created Fabric Identity for Workspace | 予定外のワークスペースでIDが作成されていないか |
| Retrieved Fabric Identity for Workspace | 管理・確認操作が想定された担当者によるものか |
| Deleted Fabric Identity for Workspace | 削除申請や変更管理チケットと一致しているか |
| Retrieved Fabric Identity Token for Workspace | 異常な時間帯や頻度でトークン取得が発生していないか |
ADLS Gen2へ接続する場合の実装手順
Workspace identityの代表的な活用シーンは、ファイアウォールで制限されたAzure Data Lake Storage Gen2へFabricから接続するケースです。公式情報では、Workspace identityを作成し、ストレージアカウントに対して権限を付与し、Fabricアイテム側でWorkspace identity認証を選ぶ流れが示されています。(Microsoft Learn)
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| Workspace identityを作成する | Fabricワークスペース設定のWorkspace identityタブから作成する | My Workspaceでは作成できない |
| ADLS Gen2にRBACを付与する | Storage Blob Data ReaderまたはStorage Blob Data Contributorなどを付与する | ロール付与はストレージアカウントレベルで行う必要がある |
| ネットワーク許可を設定する | trusted workspace access用のresource instance ruleを設定する | Azureポータルだけで完結せず、ARMテンプレートまたはPowerShellが必要 |
| Fabricアイテムで認証方式を選ぶ | OneLakeショートカット、パイプライン、セマンティックモデル、Dataflows Gen2でWorkspace identityを選ぶ | Workspace identity作成前は認証方式として表示されない |
| 動作確認する | ショートカットのプレビュー、パイプライン実行、モデル更新を確認する | RBACとネットワーク設定のどちらが原因か切り分けにくい |
ADLS Gen2のRBACでは、読み取り専用ならStorage Blob Data Reader、書き込みも必要ならStorage Blob Data Contributorなどを選びます。最小権限を守るなら、開発・検証段階でContributorを広く付与し続けるのではなく、処理内容に応じてReaderへ戻す運用を決めておくと安全です。(Microsoft Learn)
trusted workspace accessでは、特定のFabricワークスペースからストレージアカウントへアクセスさせるためにresource instance ruleを設定します。公式情報では、Fabricワークスペース向けのresource instance ruleはARMテンプレートまたはPowerShellで作成し、Azureポータルからの作成はサポートされないとされています。(Microsoft Learn)
「trusted service exception」を使うと、条件によってはテナント内のFabric capacity上にあるWorkspace identity付きワークスペースからアクセスできる範囲が広くなります。公式情報ではこの構成は推奨されず、将来的にサポートが終了する可能性があるため、特定ワークスペースに絞るresource instance ruleを優先してください。(Microsoft Learn)
開発者が注意すべき接続方式
Workspace identity認証は、OneLakeショートカット、パイプライン、セマンティックモデル、Dataflows Gen2で利用できます。パイプラインではCopy、Lookup、GetMetadataアクティビティが対象として示されており、Dataflows Gen2ではdeployment pipelinesとPublic APIでのみサポートされる点に注意が必要です。(Microsoft Learn)
接続を作成するときは、再利用範囲を広げすぎないことが重要です。公式情報では、Workspace identity認証の接続はOneLakeショートカット、パイプライン、セマンティックモデル、Dataflows Gen2でのみ利用でき、その他のFabricアイテムや別ワークスペースで再利用すると動作しない可能性があるとされています。Gateway接続ではWorkspace identityベースの認証は現時点でサポートされていません。(Microsoft Learn)
開発・検証でありがちな失敗は、ユーザー個人の資格情報で接続を作り、そのまま本番に移すことです。Workspace identityを使う場合は、接続先の権限が「個人」ではなく「ワークスペースにひも付くID」に与えられているかを確認してください。これにより、担当者の退職、MFA変更、パスワード変更、シークレット期限切れによる停止リスクを減らせます。(Microsoft Learn)
条件付きアクセスとワークロードIDの確認
Microsoft Entraの条件付きアクセスを使ってワークロードIDを制御している組織では、Workspace identityが意図せずブロックされないか確認が必要です。公式情報では、すべてのサービスプリンシパルを含むワークロードID向け条件付きアクセスポリシーがある場合、各Fabric workspace identityを除外しないとWorkspace identityが動作しないとされています。(Microsoft Learn)
これはセキュリティを弱めるという意味ではありません。重要なのは、Workspace identityを「例外として放置する」のではなく、どのWorkspace identityをどのポリシーから除外したのか、どのデータソースへのアクセスに使うのかを台帳化することです。除外設定、RBAC、resource instance rule、Purview監査をセットで管理すると、セキュリティと可用性のバランスを取りやすくなります。(Microsoft Learn)
移行・容量変更で壊れやすいポイント
Workspace identityは、作成後に放置しても安全に動き続ける仕組みではありません。ワークスペースの削除、復元、容量移行、名前変更、テナント設計変更のタイミングで影響が出ます。(Microsoft Learn)
特に注意すべきなのは削除です。Workspace identityを削除すると、trusted workspace accessや認証でそのIDに依存しているFabricアイテムは動作しなくなります。削除されたWorkspace identityは復元できません。さらに、ワークスペースを削除するとWorkspace identityも削除され、ワークスペースを復元してもWorkspace identityは復元されないため、必要であれば新しく作成し直す必要があります。(Microsoft Learn)
容量変更にも注意が必要です。Workspace identityを持つワークスペースを非Fabric容量または非F SKUのFabric容量へ移行しても、ID自体は無効化・削除されません。ただし、trusted workspace accessに依存するFabricアイテムは動作しなくなります。trusted workspace accessはF SKU容量で利用でき、Trial容量ではサポートされないため、容量移行前に接続テストを行うべきです。(Microsoft Learn)
ワークスペース名を変更した場合、Workspace identity名もワークスペース名に合わせて変更されます。ただし、Microsoft Entraのアプリケーションとサービスプリンシパルは同じままです。テナント内に同じ名前のアプリ登録が複数存在する可能性もあるため、運用台帳では名前だけでなくWorkspace ID、Service principal ID、Application IDを記録してください。(GitHub)
展開前チェックリスト
本番環境へWorkspace identityを展開する前に、次のチェックリストを確認してください。特に、削除不可・復元不可の性質と、Microsoft Entra上で見えるオブジェクトを不用意に編集しない点は、変更管理ルールに明記しておくべきです。(Microsoft Learn)
| チェック項目 | 判断基準 |
|---|---|
| ワークスペース種別 | My Workspaceではなく、管理対象のFabricワークスペースである |
| 権限 | Workspace adminが作成し、Admin/Member/Contributorのみが接続認証に使える |
| Entra管理者権限 | Application AdministratorやCloud Application Administratorを必要最小限にしている |
| APIアクセス許可 | 対象リソースへのアクセスに必要な許可だけを追加している |
| ADLS Gen2 RBAC | Reader/Contributorなどをストレージアカウントレベルで適切に付与している |
| ネットワーク | trusted workspace accessはresource instance ruleで特定ワークスペースに絞っている |
| 条件付きアクセス | ワークロードID向けポリシーでWorkspace identityが不必要にブロックされていない |
| 監査 | Purview Audit LogとEntraのサインインログ・監査ログを確認できる |
| 容量 | trusted workspace accessを使う場合はF SKU容量である |
| クロステナント | B2B・クロステナント前提の構成にしていない |
| 削除手順 | 削除前に依存するショートカット、パイプライン、モデル、Dataflows Gen2を確認する |
| 上限管理 | 既定10,000件のFabric identityとテナント設定上限を確認する |
よくあるトラブルと対処
Workspace identityの作成ボタンが無効になっている場合は、まず自分が対象ワークスペースの管理者か確認してください。公式情報では、Workspace identityの作成・管理にはWorkspace admin権限が必要であり、My Workspaceでは作成できないとされています。(Microsoft Learn)
初回作成時に状態がFailedになった場合は、公式情報では1時間待ってからIDを削除し、削除後5分待って再作成する手順が示されています。ただし、削除済みのWorkspace identityは復元できないため、本番運用中のIDに対して同じ判断を機械的に行うのは避けてください。(Microsoft Learn)
セマンティックモデルの更新に失敗する場合は、Workspace identityにストレージアカウント上の適切な権限があるか、ストレージアカウントのネットワーク設定が正しいかを確認します。ADLS Gen2ではRBACとファイアウォールの両方が関係するため、権限だけを見て「設定済み」と判断しないことが大切です。(Microsoft Learn)
まず何をすべきか
Workspace identity – Microsoft Fabricを使う組織は、最初に「対象ワークスペース」「接続先リソース」「付与するRBAC」「Entra上で変更してよい範囲」「監査方法」を1枚の設計メモにまとめてください。機能そのものは資格情報管理を楽にしますが、サービスプリンシパルを使う以上、権限の棚卸しと監査は欠かせません。(Microsoft Learn)
すでにWorkspace identityを使っている場合は、2026年5月9日時点の確認として、B2B・クロステナント構成が含まれていないか、Application Administrator権限を持つユーザーが多すぎないか、Entra上のアプリ登録を不用意に変更していないかを優先して確認しましょう。これから展開する場合は、開発環境でADLS Gen2への接続、Purview監査ログ、容量変更時の影響まで検証してから、本番ワークスペースへ段階的に適用するのが安全です。(GitHub)
コメント