Microsoft Fabric の workspace identity を使っていて、「Azure 側で API permissions を追加してよいのか」「サービスプリンシパルやアプリ登録を触ると壊れるのか」が気になっている場合、今回の結論は明確です。サービスプリンシパルやアプリ登録の変更・削除は引き続き避けるべきですが、ターゲットリソースへアクセスするための API permissions 追加は、workspace identity でサポートされる操作として整理されました。
2026年5月5日に GitHub 上の Microsoft Fabric ドキュメント更新 PR で、workspace identity の API permissions に関するガイダンスが修正されました。特に、docs/security/workspace-identity.md の警告文に「API permissions の追加は workspace identities でサポートされる」という趣旨が加えられています。(GitHub)
ただし、これは「Azure 上の関連オブジェクトを自由に編集してよい」という意味ではありません。Microsoft Fabric の workspace identity は Fabric が自動管理する ID であり、手動変更の範囲を誤ると OneLake ショートカット、パイプライン、セマンティックモデル、Dataflows Gen2 などの接続や認証に影響する可能性があります。この記事では、今回の Microsoft Fabric documentation update の変更点、影響範囲、設定確認の観点を実務目線で整理します。
今回の更新で何が変わったのか
今回の「Update warnings regarding workspace identity modifications」は、新機能追加というよりも、既存ドキュメントの警告文を実務で誤解しにくくするための明確化です。
Microsoft Fabric の workspace identity では、Fabric が Microsoft Entra ID にサービスプリンシパルを作成し、関連する app registration も作成します。Fabric はこの ID を使って Microsoft Entra トークンを取得するため、利用者がキー、シークレット、証明書を管理する必要はありません。(Microsoft Learn)
従来の警告文だけを見ると、「Azure 側の関連オブジェクトに対する変更はすべて危険」と受け取られやすい状態でした。今回の更新では、ターゲットリソースへのアクセスを許可するために API permissions を追加することは workspace identity でサポートされる、という点が補足されています。PR の最終的な変更では、Access control 側と Enterprise applications 側の警告文に同趣旨の記述が反映されています。(GitHub)
| 観点 | 変更前に誤解しやすかった点 | 今回の明確化で押さえるべき点 |
|---|---|---|
| API permissions の追加 | Azure 側の変更はすべて workspace identity を壊す可能性があるように見える | ターゲットリソースへのアクセスに必要な API permissions の追加は、workspace identity でサポートされる |
| サービスプリンシパルの変更・削除 | 管理者なら手動で修正してもよいと考えがち | 変更・削除は引き続き非推奨。Fabric アイテムの動作停止につながる可能性がある |
| app registration の扱い | 通常のアプリ登録と同じように編集できると考えがち | Fabric が管理する前提のため、API permissions 追加以外の手動変更は避ける |
| 権限管理 | Application Administrator を広く付与しがち | 最小権限の原則に従い、必要な管理者だけに限定する |
| 運用ルール | 「Azure 側は一切触らない」と一律禁止にしがち | API permissions 追加だけを例外として、変更申請・承認・記録の対象にする |
なお、Microsoft Learn の公開ページは反映タイミングに差が出る場合があります。確認時点で Learn 側の workspace identity ページは「Last updated on 2026-02-20」と表示されているため、実運用では Microsoft Learn 本体と該当 GitHub PR の両方を確認して判断するのが安全です。(Microsoft Learn)
Microsoft Fabric workspace identity とは
Microsoft Fabric workspace identity は、Fabric ワークスペースに関連付けられる自動管理のサービスプリンシパルです。Fabric アイテムが Microsoft Entra 認証に対応したリソースへ接続する際に、この ID を認証主体として利用できます。(Microsoft Learn)
代表的な利用シーンは次の2つです。
| 利用シーン | 具体例 |
|---|---|
| 認証 | OneLake ショートカット、パイプライン、セマンティックモデル、Dataflows Gen2 から外部データソースへ接続する |
| trusted workspace access | ファイアウォールで保護された Azure Data Lake Storage Gen2 などへ、信頼されたワークスペースとしてアクセスする |
workspace identity の重要な特徴は、Fabric がライフサイクルを管理する点です。Azure managed identity と似ている部分はありますが、管理・ガバナンス・ライフサイクルは同じではありません。ワークスペースを削除すると workspace identity も削除され、削除された workspace identity は復元できません。(Microsoft Learn)
つまり、workspace identity は「Azure 側で自由に直せる通常のアプリ」ではなく、Fabric の管理下にあるワークスペース単位の IDとして扱う必要があります。
誰が対応すべきか
今回の更新で最も影響を受けるのは、workspace identity を使って外部リソースや API に接続している組織です。特に、Microsoft Entra ID の管理者と Fabric 管理者が分かれている環境では、運用ルールの認識合わせが必要です。
| 対象者 | 確認すべきこと | 優先度 |
|---|---|---|
| Fabric 管理者 | workspace identity を作成済みのワークスペース、利用中の接続、削除リスク | 高 |
| Microsoft Entra ID 管理者 | 関連する service principal / app registration への変更履歴、API permissions、管理者ロール | 高 |
| データエンジニア | OneLake ショートカット、パイプライン、Dataflows Gen2 の接続設定 | 中〜高 |
| Power BI / Fabric 開発者 | セマンティックモデルのクラウド接続、更新失敗時の原因切り分け | 中 |
| セキュリティ・監査担当 | Purview 監査ログ、Entra の監査ログ・サインインログ、過剰権限 | 中〜高 |
| DevOps / Platform チーム | 手順書、IaC、変更申請テンプレート、検証環境での再現手順 | 中 |
特に注意したいのは、Microsoft Entra ID の Application Administrator や Cloud Application Administrator です。これらのロールはアプリケーション構成を広く管理でき、アプリケーション管理者は Microsoft Graph を除く delegated permissions と application permissions への同意権限も持ちます。workspace identity 関連の作業では、最小権限と承認フローをセットで管理する必要があります。(Microsoft Learn)
API permissions 追加は何を意味するのか
今回の更新でいう API permissions 追加は、対象 API や保護されたリソースにアクセスするために、Microsoft identity platform 上で必要なアクセス許可を付与する操作です。
Microsoft identity platform には、大きく分けて delegated permissions と application permissions があります。delegated permissions はサインインユーザーの代わりにアクセスするシナリオで使われ、application permissions はユーザーなしでアプリケーション自身としてアクセスするシナリオで使われます。(Microsoft Learn)
ただし、ここで混同しやすいのが API permissions と Azure RBAC です。たとえば Azure Data Lake Storage Gen2 に workspace identity で接続する場合、公式ドキュメントではストレージアカウントの IAM で Storage Blob Data Reader や Storage Blob Data Contributor などのロールを割り当てる手順が示されています。これは API permissions ではなく、Azure リソースに対するロール割り当てです。(Microsoft Learn)
| 権限の種類 | 使う場面 | 実務での注意点 |
|---|---|---|
| API permissions | Microsoft Graph、カスタム API、保護された API などへのアクセスを許可する | 必要なスコープまたはアプリケーション権限だけを追加する |
| Azure RBAC | ADLS Gen2、Storage Account など Azure リソースへのアクセスを許可する | Reader / Contributor などをリソーススコープで最小限に割り当てる |
| Fabric ワークスペースロール | Fabric 内で接続を作成・構成する | workspace identity を接続で使うには、管理者、メンバー、共同作成者などの権限が必要 |
| Entra 管理者ロール | app registration や enterprise application の管理 | Application Administrator の付与範囲を広げすぎない |
実務では、「API permissions を追加すればストレージにもアクセスできる」と考えるのは危険です。ADLS Gen2 などの Azure リソースでは、必要に応じて Azure RBAC の割り当ても確認してください。
引き続き避けるべき変更
今回の更新によって API permissions の追加がサポートされることは明確になりましたが、次のような操作まで許可されたわけではありません。
| 避けるべき操作 | 起こり得る影響 |
|---|---|
| workspace identity に紐づく service principal を削除する | Fabric アイテムが workspace identity で認証できなくなる |
| app registration を削除する | identity の参照関係が壊れ、復旧が難しくなる |
| シークレットや証明書を手動追加・変更する | Fabric の自動管理前提から外れ、運用責任が不明確になる |
| 表示名や所有者を不用意に変更する | 監査・識別・運用手順で混乱が起きる |
| 不要な API permissions を広く付与する | 権限過多になり、セキュリティレビューで問題になりやすい |
| App registrations 側を通常アプリと同じ感覚で編集する | 公式警告と矛盾する運用になり、障害時の切り分けが難しくなる |
Microsoft Learn の現行説明でも、workspace identity に関連するアプリケーションは Enterprise applications と App registrations の両方から確認できる一方、App registrations 側では変更しないよう警告されています。また、Enterprise applications 側でも変更すると workspace identity が動作しなくなる可能性があるとされています。(Microsoft Learn)
したがって、実務上の安全な判断基準は次のとおりです。
| 判断基準 | 対応 |
|---|---|
| ターゲット API へのアクセスに必要な API permissions を追加する | 変更申請・承認・検証を行ったうえで実施 |
| ADLS Gen2 などの Azure リソースにロールを付与する | Azure RBAC とスコープを確認して最小権限で実施 |
| service principal / app registration を削除・再作成する | 原則禁止。障害対応でも Microsoft の最新ドキュメントやサポート手順を確認 |
| 既存の workspace identity を作り直す | 削除すると復元できないため、安易に行わない |
| どの権限が必要か不明 | まず検証ワークスペースで接続テストし、必要権限を特定する |
影響を受ける Fabric 機能
workspace identity は、Fabric 内の複数の接続シナリオで使われます。今回の更新は「API permissions の追加可否」に関するものですが、実際の影響確認では workspace identity を利用しているアイテム全体を棚卸しする必要があります。
Microsoft の認証ガイドでは、workspace identity は OneLake shortcuts、pipelines、semantic models、Dataflows Gen2 などからデータソースへ接続する用途で説明されています。パイプラインでは Copy、Lookup、GetMetadata アクティビティで workspace identity を選べるとされています。(Microsoft Learn)
| Fabric 機能 | 確認ポイント |
|---|---|
| OneLake shortcuts | ADLS Gen2 への接続で workspace identity を使っているか |
| Data pipeline | Copy、Lookup、GetMetadata で workspace identity 認証を使っているか |
| Semantic model | クラウド接続に workspace identity 認証の接続を割り当てているか |
| Dataflows Gen2 | deployment pipelines や Public API 経由の利用条件に合っているか |
| Manage connections and gateways | workspace identity 認証のクラウド接続を再利用していないか |
| Trusted workspace access | ストレージアカウントのファイアウォールやネットワーク制御と整合しているか |
注意点として、workspace identity ベースの認証は gateway connections ではサポートされていません。また、workspace identity 認証で構成した接続を、対応外の Fabric アイテムや別ワークスペースで再利用すると動作しない可能性があります。さらに、クロステナント要求には対応していません。(Microsoft Learn)
既存環境で確認すべき設定
今回の更新を受けて、既存の workspace identity をすぐに移行する必要は通常ありません。優先すべきは、どの workspace identity が、どのリソースに、どの権限でアクセスしているかを可視化することです。
Fabric 側の確認
まず、Fabric 管理者は workspace identity の作成状況を確認します。workspace identity は My workspace を除くワークスペースで作成でき、作成・削除には workspace admin 権限が必要です。(Microsoft Learn)
確認項目は次のとおりです。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| workspace identity の有無 | ワークスペース設定 | 本番・検証・開発で作成状況が揃っているか |
| identity の ID | Workspace identity タブ | Entra 側のアプリと突合できるか |
| authorized users | Workspace identity タブ | 不要なユーザーが含まれていないか |
| ワークスペースロール | ワークスペースアクセス管理 | 接続を構成できるユーザーが必要最小限か |
| 利用中アイテム | ショートカット、パイプライン、モデル、Dataflows Gen2 | どの接続が workspace identity 依存か |
Microsoft Entra ID 側の確認
Entra 側では、workspace identity に関連する enterprise application と app registration を確認します。ここで重要なのは、確認することと変更することを分けることです。
| 確認項目 | 推奨アクション |
|---|---|
| 対象 identity の enterprise application | 監査ログ・サインインログを確認する |
| API permissions | 必要なターゲット API だけに絞られているか確認する |
| 管理者ロール | Application Administrator などが過剰に割り当てられていないか確認する |
| 所有者・変更履歴 | 不審な変更や属人化がないか確認する |
| app registration | 不用意な手動変更がないか確認する。原則として編集しない |
Fabric の workspace identity は、Purview の監査ログでも作成・取得・削除・トークン取得に関するイベントを確認できます。セキュリティ担当者は、Entra のログだけでなく Purview 側の監査イベントも併せて見ると、Fabric 側の操作と ID 側の操作を結び付けやすくなります。(Microsoft Learn)
接続先リソース側の確認
接続先が ADLS Gen2 や Azure Storage の場合、Storage Account 側の IAM ロール割り当てを確認します。公式手順では、workspace identity に Storage Blob Data Reader や Storage Blob Data Contributor などのロールをストレージアカウントレベルで付与する流れが示されています。(Microsoft Learn)
接続先が API の場合は、必要な API permissions を確認します。application permissions を付与する場合は、権限の影響範囲が広くなりやすいため、承認者、利用目的、検証結果を必ず記録しましょう。
変更申請に入れるべき項目
API permissions の追加がサポートされるとしても、運用上は通常の変更管理に乗せるべきです。特に本番ワークスペースでは、「安全と書かれているからすぐ追加する」ではなく、誰が見ても妥当性を判断できる形で記録します。
| 項目 | 記載例 |
|---|---|
| 対象ワークスペース | Finance-Prod-Lakehouse |
| workspace identity ID | Fabric の Workspace identity タブに表示される GUID |
| 対象リソース | Microsoft Graph、社内 API、ADLS Gen2 など |
| 追加する権限 | Files.Read.All、カスタム API の app role など |
| 権限種別 | Delegated permissions / Application permissions / Azure RBAC |
| 追加理由 | Dataflow Gen2 から対象 API のデータを取得するため |
| 代替手段 | ユーザー認証、別サービスプリンシパル、Managed Private Endpoint など |
| 検証内容 | 開発ワークスペースで接続作成、更新、ログ確認まで完了 |
| ロールバック | 追加した API permission またはロール割り当てを削除 |
| 承認者 | Fabric 管理者、Entra 管理者、データオーナー |
このテンプレートを使うと、Fabric 側の作業と Entra 側の作業が分断されにくくなります。特に API permissions と Azure RBAC を混同しないよう、権限種別は必ず明記してください。
移行や設定変更が必要なケース
今回の更新だけを理由に、workspace identity の再作成や大規模な移行を行う必要はありません。ただし、次のケースでは設定や手順書の見直しが必要です。
| 状況 | 対応 |
|---|---|
| 社内手順書に「workspace identity 関連の Azure 側変更は全面禁止」と書かれている | API permissions 追加を例外として扱うよう修正する |
| API permissions を追加したいが、過去の警告文を理由に止めていた | 最新の PR と Learn を確認し、変更申請に基づいて実施する |
| Application Administrator が多数いる | 最小権限に見直し、PIM や期間限定付与を検討する |
| 接続エラー時に identity を削除・再作成する運用がある | 削除不可逆のリスクがあるため、切り分け手順を修正する |
| ワークスペースを別 capacity に移行する予定がある | trusted workspace access への影響を事前確認する |
| Conditional Access がすべての service principals を対象にしている | workspace identity がブロックされないか確認する |
公式ドキュメントでは、workload identities 向け Conditional Access ポリシーがすべての service principals を含む場合、各 Fabric workspace identity を除外しないと workspace identities が動作しないと説明されています。(Microsoft Learn)
失敗しやすいポイント
API permissions とストレージ権限を混同する
API permissions は API へのアクセス許可です。ADLS Gen2 にアクセスする場合は、多くのケースで Storage Account 側の Azure RBAC が必要です。ストレージにアクセスできないときに API permissions だけを追加しても、問題が解決しないことがあります。
App registrations 側で通常アプリのように編集する
workspace identity に関連する app registration は Fabric が作成・管理する前提です。通常の業務アプリと同じ感覚でシークレット、証明書、所有者、表示名などを変更すると、後で原因不明の接続障害につながる可能性があります。
接続を別ワークスペースで使い回す
workspace identity はワークスペースに紐づく ID です。workspace identity 認証で作成した接続を、別ワークスペースや対応外アイテムで使い回すと動作しない可能性があります。接続を再利用する場合は、対象ワークスペースと対応機能を確認してください。(Microsoft Learn)
削除して作り直せば直ると考える
workspace identity は削除すると復元できません。ワークスペースを削除した場合も identity は削除され、ワークスペースを復元しても identity は復元されません。障害対応で削除を選ぶ前に、ログ、権限、接続先、Conditional Access を確認するべきです。(Microsoft Learn)
管理者権限を広く配りすぎる
Application Administrator や Cloud Application Administrator は便利ですが、アプリケーション構成に対する影響が大きいロールです。workspace identity の API permissions 追加を一部の担当者に任せる場合でも、恒久的な広範囲付与ではなく、必要な期間・対象・承認者を明確にしましょう。
実務での確認手順
本番環境に手を入れる前に、次の順序で確認すると安全です。
| 手順 | 作業 | 完了条件 |
|---|---|---|
| 1 | workspace identity を利用しているワークスペースを一覧化する | 本番・検証・開発の対象が分かる |
| 2 | OneLake shortcuts、pipelines、semantic models、Dataflows Gen2 の利用有無を確認する | identity 依存の Fabric アイテムが分かる |
| 3 | Entra 側の enterprise application / app registration を突合する | identity ID と Entra オブジェクトが一致する |
| 4 | API permissions と Azure RBAC を分けて棚卸しする | どの権限が何のために必要か分かる |
| 5 | 追加予定の API permissions を最小権限で設計する | 不要な広範囲権限がない |
| 6 | 検証ワークスペースで接続作成・実行・更新をテストする | 実行ログと認証成功を確認できる |
| 7 | 本番変更を申請・承認する | 承認者、変更内容、ロールバック方法が記録されている |
| 8 | 変更後に Fabric と Entra のログを確認する | 接続失敗や想定外のアクセスがない |
この手順で重要なのは、API permissions を追加する前に、何のエラーを解消したいのかを特定することです。権限不足、ネットワーク制限、Conditional Access、接続の再利用ミスは症状が似ていることがあります。原因を切り分けずに権限を追加すると、障害は解消せず、セキュリティリスクだけが増えます。
これから取るべきアクション
今回の Microsoft Fabric documentation update で押さえるべきポイントは、次の3つです。
まず、workspace identity に対する API permissions の追加はサポートされる操作として明確化された ため、必要な API アクセスを過度に恐れて止める必要はありません。
次に、service principal や app registration の変更・削除が安全になったわけではありません。Fabric が管理する ID であることを前提に、API permissions 追加以外の手動変更は避けるべきです。
最後に、既存環境では移行よりも棚卸しを優先しましょう。workspace identity を使っているワークスペース、接続、ターゲットリソース、API permissions、Azure RBAC、管理者ロールを確認し、社内手順書を今回の更新に合わせて修正することが次の実務アクションです。
特に本番環境では、「権限を追加して終わり」ではなく、変更理由、承認、検証、ログ確認までをセットにしてください。そうすることで、Microsoft Fabric の workspace identity を安全に活用しながら、Entra ID 側のガバナンスも維持できます。
コメント