Power Platform Managed Identity / Microsoft Entra ID を使う管理者が最初に確認すべきことは、既存の Power Platform 連携が「クライアントシークレットや API キー前提」のまま残っていないかです。2026年4月20日の Microsoft Security Blog では、機会を狙った攻撃を難しくする設計として、資格情報の削減、マネージド ID、フェデレーション ID 資格情報、攻撃対象領域の縮小が強調されました。Power Platform Managed Identity は、Dataverse プラグインなどが Azure リソースへ接続する際に、埋め込みシークレットではなく Microsoft Entra ID ベースの ID を使うための重要な選択肢です。(Microsoft)
ただし、今回のポイントは「すべての Power Platform 自動化が即座にシークレットレスになる」という単純な話ではありません。公開ドキュメント上、Power Platform Managed Identity のサポート対象として明記されているのは Dataverse プラグインと依存アセンブリ プラグインで、可用性は GA とされています。Power Automate や Copilot Studio などを含む広い自動化基盤では、対象コンポーネントごとの対応状況、Entra ID 側の権限設計、既存シークレットの棚卸しを分けて確認する必要があります。(Microsoft Learn)
今回の更新で押さえるべき結論
Microsoft が示した大きな方向性は、業務自動化の認証を「保存された秘密情報」から「管理されたワークロード ID」へ移すことです。攻撃者は必ずしも高度な侵入をするわけではなく、漏えいした資格情報、期限切れを避けるために長期間残されたシークレット、使い回された API キーを足がかりにします。Microsoft は、自社環境で「ワークロードがシークレットなしで認証できるなら、そうすべき」という原則を採用し、パスワード、クライアントシークレット、API キーを減らす方針を説明しています。(Microsoft)
Power Platform 管理者、エンタープライズアーキテクト、セキュリティエンジニアが最初に見るべき観点は、次の3つです。
| 確認観点 | すぐ確認すべき内容 | 実務上の判断 |
|---|---|---|
| 対象コンポーネント | Dataverse プラグイン、プラグイン パッケージ、カスタム連携、Power Automate フロー | 公式にサポートされる範囲と、個別に代替設計が必要な範囲を分ける |
| 認証方式 | クライアントシークレット、証明書、API キー、プラグインのセキュア構成、環境変数 | 漏えい・期限切れ・属人化のリスクが高いものから移行候補にする |
| Entra ID ガバナンス | アプリ登録、ユーザー割り当てマネージド ID、フェデレーション ID 資格情報、RBAC | 最小権限、環境分離、監査ログ確認を前提に設計する |
ここで重要なのは、Managed Identity を導入すること自体ではなく、「秘密情報をどこに置かないか」を設計することです。たとえば Dataverse プラグインから Azure Key Vault に接続して値を取得する場合、従来はプラグイン設定や環境変数にシークレットを置きたくなります。しかし Power Platform Managed Identity を使えば、Dataverse プラグインが Microsoft Entra ID のワークロード ID として Azure リソースへアクセスする構成を検討できます。(Microsoft Learn)
Power Platform Managed Identity とは何か
Power Platform Managed Identity は、Power Platform 側のコンポーネントが Azure リソースへ安全に接続するための仕組みです。Microsoft Learn では、Dataverse プラグインから Azure Managed Identity をサポートする Azure リソースへ、資格情報を管理せずに接続できる機能として説明されています。内部的には、Microsoft Entra ID のワークロード ID とフェデレーション ID 資格情報を利用し、ユーザー割り当てマネージド ID またはアプリケーション登録に FIC を構成します。(Microsoft Learn)
従来の「アプリ登録 + クライアントシークレット」方式では、次のような運用課題が起きがちです。
- シークレットの有効期限切れで業務フローが停止する
- シークレットがリポジトリ、設定ファイル、チケット、手順書に残る
- 退職者や外部委託先が作成したアプリ登録の所有者が分からない
- Key Vault にシークレットを置いても、結局その Key Vault にアクセスするための認証情報が必要になる
- 本番、検証、開発で同じ ID や権限が使い回される
Managed Identity はこれらの問題をすべて自動で解決する魔法ではありませんが、少なくとも「長期保存された秘密値を Power Platform 側に持たせる」設計から離れるための現実的な選択肢になります。Microsoft のマネージド ID概要でも、マネージド ID は資格情報を開発者が管理する必要をなくし、Microsoft Entra トークンを取得して Entra 認証をサポートするリソースへアクセスできる仕組みだと説明されています。(Microsoft Learn)
対象範囲はまず Dataverse プラグインから確認する
2026年4月時点で実務上まず確認すべき対象は、Dataverse プラグインとプラグイン パッケージです。Power Platform Managed Identity の公式概要では、サポートされる Power Platform サービスとして Dataverse プラグインと依存アセンブリ プラグインが挙げられ、GA とされています。(Microsoft Learn)
一方で、Microsoft Security Blog では Power Platform Managed Identity が Dataverse プラグインや Power Automate などの Power Platform コンポーネントにテナント所有の ID を与える文脈で紹介されています。ここは読み違えやすい点です。Power Automate のすべての HTTP アクション、カスタム コネクタ、外部 API 呼び出しが同じ方式でそのまま利用できると決めつけず、対象機能の公式ドキュメント、テナントのロールアウト状況、利用している接続方式を個別に確認してください。(Microsoft)
影響を受けやすい利用シーン
Power Platform Managed Identity の検討優先度が高いのは、次のような連携です。
| 利用シーン | 従来のよくある構成 | 見直しの方向性 |
|---|---|---|
| Dataverse プラグインから Azure Key Vault を参照 | プラグイン設定や環境変数にアプリ ID / シークレットを保存 | Managed Identity と RBAC で Key Vault へのアクセスを付与 |
| Dataverse プラグインから Azure Storage へ書き込み | 接続文字列やアクセスキーを保持 | Entra ID 認証と最小権限ロールへ移行 |
| ISV / IP プラグインが顧客テナントの Azure リソースへ接続 | 顧客ごとにシークレットを発行・共有 | 顧客テナント所有の ID と明示的なアクセス許可で統制 |
| 業務フローから社内 API を呼び出す | カスタム コネクタや HTTP 呼び出しに秘密値を設定 | 対応可否を確認し、必要に応じて Azure 側の中継基盤や Entra 認証へ再設計 |
特に Key Vault 連携は分かりやすいユースケースです。Microsoft Learn でも、Dataverse プラグインから Azure Key Vault に接続し、キーやシークレットなどの機密情報を取得する例が示されています。ここでの狙いは「Key Vault を使えば安全」という表面的な話ではなく、Key Vault に到達するための認証も含めてシークレットレス化することです。(Microsoft Learn)
Microsoft Entra ID 側で確認すべき変更点
Power Platform Managed Identity を導入すると、管理の中心は Power Platform 管理センターだけでは完結しません。Microsoft Entra ID 側で、アプリ登録、ユーザー割り当てマネージド ID、フェデレーション ID 資格情報、サインインログ、Azure RBAC を確認する必要があります。
フェデレーション ID 資格情報が鍵になる
フェデレーション ID 資格情報は、外部または別サービス側のワークロードから発行されたトークンを、Microsoft Entra ID 側で信頼するための設定です。Microsoft Graph のドキュメントでは、FIC により、サポートされるシナリオでシークレットを管理せずに Microsoft Entra で保護されたリソースへアクセスできると説明されています。issuer、subject、audience の組み合わせが重要で、これらの値は大文字小文字を含めて一致する必要があります。(Microsoft Learn)
実務では、次のようなミスが起きやすくなります。
| 失敗しやすい点 | 起きる問題 | 確認方法 |
|---|---|---|
| issuer の URL が違う | トークン交換に失敗する | テナント ID、クラウド環境、v2.0 issuer を確認 |
| subject の形式が違う | AADSTS700213 などの認証エラーが出る | Power Platform 側の期待値と FIC の subject を照合 |
| audience の値が違う | Entra ID がトークンを受け付けない | public cloud / sovereign cloud の audience を確認 |
| 大文字小文字の差異 | 見た目は似ていても認可されない | コピー&ペースト後に余分な空白や大小文字を確認 |
| 1つの ID に多くの用途を集約 | 権限が広がり、侵害時の影響範囲が大きくなる | 環境、用途、コンポーネント単位で分離を検討 |
Microsoft Learn の設定手順では、Power Platform Managed Identity の構成として、新しいアプリ登録またはユーザー割り当てマネージド ID の作成、FIC の構成、Dataverse プラグインの登録、Dataverse での managed identity レコード作成、Azure リソースへのアクセス許可付与、統合検証が示されています。つまり、Power Platform 側の設定だけでなく、Entra ID と Azure リソース側の権限付与まで含めて完了させる必要があります。(Microsoft Learn)
アプリ登録とユーザー割り当てマネージド ID の選び方
Microsoft Learn では、Dataverse プラグインに関連付ける ID として、アプリケーション登録またはユーザー割り当てマネージド ID を作成できると説明されています。Azure Key Vault などへアクセスするプラグインにアプリ ID を関連付けたい場合はアプリ登録を、サービス プリンシパルとして Azure リソースへアクセスさせる場合はユーザー割り当てマネージド ID を使う選択肢があります。(Microsoft Learn)
実務では、次の基準で決めると整理しやすくなります。
| 判断基準 | アプリ登録が向く場合 | ユーザー割り当てマネージド ID が向く場合 |
|---|---|---|
| ガバナンス | アプリ単位で所有者、同意、ポリシーを管理したい | Azure リソースへの RBAC 付与を中心に管理したい |
| ライフサイクル | ISV 連携やアプリ単位の識別を重視する | 環境・ワークロード単位で ID を再利用したい |
| 運用チーム | Entra ID 管理チームがアプリ登録を統制している | Azure 管理チームが Managed Identity と RBAC を統制している |
| 権限分離 | アプリごとの明確な境界が必要 | 開発・検証・本番で ID を分けたい |
どちらを選んでも、「1つの強力な ID を複数のプラグインや環境で使い回す」設計は避けるべきです。Managed Identity はシークレット漏えいリスクを下げますが、ID に過剰な権限を与えれば、侵害時の影響範囲は広がります。
Power Platform 管理者が最初にやるべき棚卸し
Power Platform 管理者は、まずテナント内の「秘密情報を持っている可能性がある自動化」を洗い出します。最初から全環境を完璧に移行しようとすると、関係者調整だけで止まりがちです。最初の1週間は、影響が大きく、停止すると業務に響く連携から優先順位を付けるのが現実的です。
棚卸し対象の例
| 場所 | 見るべき設定 | リスクの例 |
|---|---|---|
| Dataverse プラグイン | Secure Configuration、Unsecure Configuration、環境変数 | クライアントシークレットや接続文字列が残っている |
| Power Automate | HTTP アクション、カスタム コネクタ、接続参照 | API キーや Basic 認証が使われている |
| ソリューション | 環境変数、接続参照、プラグイン パッケージ | 本番移行時に秘密値が手作業で設定される |
| Azure | Key Vault、Storage、Service Bus、Functions、API Management | Power Platform 側からのアクセス権が広すぎる |
| Entra ID | アプリ登録、サービス プリンシパル、FIC、所有者 | 所有者不明、期限切れ間近、過剰権限のアプリがある |
棚卸しでは、単に「シークレットがあるか」を見るだけでは不十分です。誰が更新できるのか、期限切れ時に誰が検知するのか、削除してよいのか、代替手段があるのかまで確認してください。特に本番環境の古いプラグインは、作成者が退職している、ソースコードが見つからない、証明書の管理者が不明といった問題が起きやすい領域です。
セキュリティエンジニアが見るべきポイント
セキュリティエンジニアにとって、Power Platform Managed Identity の価値は「シークレットがなくなる」だけではありません。ワークロードごとに識別可能な ID を持たせ、サインインログやアクセス権を監査できる状態に近づけられる点が重要です。Microsoft Entra のワークロード ID は、アプリケーション、サービス プリンシパル、マネージド ID を含むソフトウェアワークロードの ID として説明されています。(Microsoft Learn)
確認すべきポイントは次の通りです。
| 項目 | 確認内容 | 判断の目安 |
|---|---|---|
| 最小権限 | Key Vault Secrets User、Storage Blob Data Contributor など必要最小限か | Contributor や Owner を安易に付けない |
| 監査 | Entra ID サインインログ、Azure Activity Log、Dataverse 側の変更履歴 | 誰が、どの ID に、何の権限を与えたか追える |
| ライフサイクル | 開発・検証・本番の ID が分離されているか | 本番 ID を開発環境から使えないようにする |
| 例外管理 | 一時的に残すシークレットの期限と所有者が明確か | 「後で消す」をチケット化しない例外は作らない |
| 検知 | 不審なサインイン、想定外リソースへのアクセスが見えるか | 人間のユーザーだけでなく非人間 ID も監視対象にする |
Microsoft は、資格情報の削減とあわせて、プライベート エンドポイント、Public Internet から到達可能な面の削減、トークンレベルでの最小権限などを組み合わせる考え方も示しています。つまり、Managed Identity は単体施策ではなく、ネットワーク到達性、RBAC、監査、標準化とセットで効果が出ます。(Microsoft)
エンタープライズアーキテクトは「標準パターン」を作る
エンタープライズ規模では、各チームが個別に「安全そうな構成」を考えると、結果的に例外だらけになります。Microsoft のブログでも、攻撃者は一貫性のない設定や例外を突きやすく、プラットフォームエンジニアリングによって安全な既定値を用意する重要性が説明されています。(Microsoft)
アーキテクトが用意すべきなのは、抽象的なガイドラインではなく、チームがそのまま使える標準パターンです。
標準パターンに含めるべき内容
| 項目 | 標準化する内容 |
|---|---|
| ID 命名規則 | uami-ppmi-prod-{system} のように用途・環境・所有者が分かる名前にする |
| 環境分離 | 開発、検証、本番で UAMI またはアプリ登録を分ける |
| 権限テンプレート | Key Vault、Storage、Service Bus など接続先ごとの最小権限ロールを定義 |
| FIC 設定手順 | issuer、subject、audience の取得・登録・検証手順を固定化 |
| 監査ルール | Entra ID、Azure Activity Log、Dataverse 変更履歴の確認責任を決める |
| 例外申請 | シークレットを残す場合の期限、理由、代替計画を必須にする |
| 廃止手順 | 移行後に古いシークレット、アプリ登録、過剰権限を削除する |
標準パターンがないまま移行を始めると、チームごとに subject の形式、ID の粒度、RBAC の付け方、証明書の扱いがばらつきます。その結果、将来の監査やインシデント対応で「この ID は何のためにあるのか」が分からなくなります。
実装の基本ステップ
Dataverse プラグインまたはプラグイン パッケージで Power Platform Managed Identity を設定する場合、Microsoft Learn の手順は大きく6段階です。新しいアプリ登録またはユーザー割り当てマネージド ID の作成、FIC の構成、プラグインの作成と登録、Dataverse での managed identity レコード作成、Azure リソースへのアクセス許可付与、統合検証の順に進めます。(Microsoft Learn)
| 手順 | 実務での確認ポイント |
|---|---|
| アプリ登録または UAMI を作成 | 所有者、命名規則、環境分離、削除責任を決める |
| FIC を構成 | issuer、subject、audience を正確に設定する |
| プラグインを作成・登録 | アセンブリ署名、証明書、プラグイン登録ツールを確認する |
| Dataverse に managed identity レコードを作成 | application ID、tenant ID、managed identity ID を取り違えない |
| Azure リソースへアクセス許可を付与 | Key Vault や Storage 側で最小権限にする |
| 統合を検証 | 認証エラー、権限不足、ログ記録を確認する |
開発・検証では自己署名証明書を使う場面があっても、本番環境では避けるべきです。Microsoft Learn でも、自己署名証明書は開発またはテスト目的に限り、本番環境では使用しないよう記載されています。(Microsoft Learn)
Power Platform CLI を使う場合の注意
Power Platform CLI には pac managed-identity コマンドグループがあり、Dataverse コンポーネントの Managed Identity レコード管理、FIC の作成、確認、更新、削除などに関するコマンドが用意されています。ただし、ドキュメント上ではこれらのコマンドに Preview と記載されているものがあります。運用自動化に組み込む場合は、プレビュー扱いのコマンドを本番標準に入れてよいかを組織の変更管理ルールで確認してください。(Microsoft Learn)
CLI を使う価値が高いのは、次のような場面です。
- 複数環境で同じ形式の FIC を作成・検証したい
- 手作業による issuer / subject の入力ミスを減らしたい
- ALM パイプライン内で ID 関連設定の差分を確認したい
- 監査用に managed identity の関連付け状態を定期的に出力したい
一方で、CLI 化する前に、誰が実行権限を持つのか、失敗時にどこまでロールバックするのか、FIC の変更が本番プラグインに与える影響は何かを明確にしておく必要があります。
グローバル環境での注意点
グローバル企業では、Public Cloud だけでなく、GCC High、DoD、China などの特殊なクラウド環境を扱う場合があります。Microsoft Learn の設定手順では、Public Cloud 以外の一部環境で audience、issuer URL、subject prefix を明示的に設定する必要があることが示されています。Public Cloud 前提の値をそのまま使うと、FIC の照合に失敗する可能性があります。(Microsoft Learn)
海外拠点を含むテナントで確認すべき点は次の通りです。
| 確認項目 | 理由 |
|---|---|
| テナントがどのクラウドに属するか | issuer URL と audience が異なる可能性がある |
| Power Platform 環境のリージョン | 環境 ID、接続先 Azure リソース、データ所在地の確認が必要 |
| 管理者ロールの分担 | Power Platform 管理者、Entra 管理者、Azure 管理者が別チームの場合が多い |
| 標準手順の翻訳 | 海外拠点が独自手順でシークレットを残すリスクを防ぐ |
| 監査証跡の保管 | 地域ごとの規制や内部監査要件に対応する |
グローバル展開では「日本本社で動いた手順」をそのまま全リージョンに展開しないことが重要です。FIC は issuer、subject、audience の一致が前提になるため、クラウド環境やテナント構成の差を最初に確認してください。
Microsoft Entra Agent ID との関係
今回の発表では、Power Platform Managed Identity と並んで、Microsoft Entra Agent ID も文脈上重要です。Microsoft は、Copilot Studio などで作られる AI エージェントを一級の ID として扱い、インベントリ化、ガバナンス、人間のスポンサーによる説明責任に結び付ける考え方を示しています。(Microsoft)
ただし、Microsoft Entra Agent ID はプレビュー段階の情報を含みます。Microsoft Learn でも、Microsoft Entra エージェント ID は現在プレビュー段階であり、リリース前に大きく変更される可能性があると説明されています。Copilot Studio では、環境で機能を有効にすると新しいエージェントごとに Entra エージェント ID が自動作成され、Entra 管理センターで表示・管理できるとされていますが、運用環境への適用はプレビュー条件を確認して判断してください。(Microsoft Learn)
実務上は、Power Platform Managed Identity と Agent ID を同じ「非人間 ID ガバナンス」の流れで整理すると理解しやすくなります。
| 領域 | 主な対象 | 管理の狙い |
|---|---|---|
| Power Platform Managed Identity | Dataverse プラグインなどのワークロード | Azure リソース接続時のシークレット削減 |
| Microsoft Entra Workload ID | アプリ、サービス プリンシパル、マネージド ID | 非人間ワークロードの認証・アクセス管理 |
| Microsoft Entra Agent ID | Copilot Studio などの AI エージェント | エージェントの可視化、ライフサイクル、責任者管理 |
これからの Power Platform 管理では、「ユーザーが誰か」だけでなく、「どのプラグイン、どの自動化、どのエージェントが、どの権限で動いているか」を説明できることが重要になります。
移行時にやってはいけないこと
Power Platform Managed Identity の導入で失敗しやすいのは、技術設定そのものよりも運用設計です。特に次のパターンは避けてください。
| NG パターン | なぜ危険か | 代替策 |
|---|---|---|
| 既存シークレットを残したまま Managed Identity も追加する | 侵害経路が残り、監査上も説明しにくい | 移行完了後に旧シークレットを削除する日付を決める |
| 本番・検証・開発で同じ ID を使う | 開発環境の侵害が本番リソースに波及する | 環境ごとに ID と RBAC を分ける |
| Azure リソースに Contributor を付与する | 必要以上の操作が可能になる | 接続先ごとにデータ読み取り・書き込み権限を限定する |
| FIC の subject を手入力で管理する | 入力ミスや再現性のない設定になる | 手順化、CLI、構成管理で値を記録する |
| Power Automate もすべて同じ方式で対応済みと考える | 対応していないアクションや接続方式で設計が破綻する | フロー単位で認証方式を確認し、必要なら中継基盤を設計する |
| 所有者不明の ID を作る | 異動・退職・組織変更後に管理不能になる | 所有者、技術責任者、業務責任者を記録する |
Managed Identity は「シークレットをローテーションしなくてよい」だけの機能ではありません。正しく使えば、攻撃者が再利用できる秘密情報を減らし、ワークロード単位の監査性を高める設計に変えられます。一方で、過剰権限の ID を作れば、単にリスクの形が変わるだけです。
まず着手すべき初動チェックリスト
Power Platform Managed Identity / Microsoft Entra ID の利用者は、次の順番で動くと無理なく進められます。
| 優先度 | やること | 完了条件 |
|---|---|---|
| 高 | Dataverse プラグインでシークレットを使っている箇所を洗い出す | 対象プラグイン、接続先、秘密情報の種類、所有者が一覧化されている |
| 高 | Azure リソース接続の権限を確認する | Key Vault、Storage、Service Bus などの RBAC が分かる |
| 高 | Power Platform Managed Identity の適用候補を1つ選ぶ | 影響範囲が限定されたパイロット対象が決まっている |
| 中 | アプリ登録と UAMI のどちらを使うか決める | 組織標準の判断基準が文書化されている |
| 中 | FIC 設定手順を標準化する | issuer、subject、audience、検証手順が再現可能になっている |
| 中 | 古いシークレットの廃止計画を作る | 削除日、ロールバック条件、責任者が決まっている |
| 低 | CLI や ALM への組み込みを検討する | 手作業設定を減らす対象が明確になっている |
最初のパイロットには、次の条件を満たすものを選ぶと成功しやすくなります。
- 接続先 Azure リソースが1〜2個に限られている
- 業務影響はあるが、短時間でロールバックできる
- プラグインのソースコードと登録情報が揃っている
- Entra ID 管理者と Azure 管理者が協力できる
- 現在使っているシークレットの場所と有効期限が分かっている
逆に、複数部門にまたがる基幹業務、所有者不明の古いプラグイン、外部ベンダー依存の強い連携を最初の対象にすると、技術検証より調整コストが大きくなります。
今回の更新をどう受け止めるべきか
2026年4月20日の Microsoft Security Blog は、Power Platform Managed Identity の単独機能紹介というより、Microsoft が進める「シークレットを持たないエンタープライズ自動化」への設計思想を示したものです。Power Platform Managed Identity はその具体策の1つであり、特に Dataverse プラグインから Azure リソースへ接続する構成では、すぐに確認する価値があります。(Microsoft)
次に取るべき行動は明確です。まず、Power Platform 環境内の Dataverse プラグインと自動化フローを棚卸しし、シークレットを持つ連携を特定します。そのうえで、Dataverse プラグインから Azure Key Vault や Storage へ接続しているような、効果が分かりやすい領域をパイロットに選びます。Entra ID 側では、アプリ登録または UAMI、FIC、RBAC、監査ログをセットで確認し、移行後に古いシークレットを確実に削除してください。
Power Platform の自動化は、業務部門に近い場所で素早く作られるため、認証情報の管理が後回しになりがちです。今回の更新は、その弱点を見直すよいタイミングです。安全な標準パターンを先に作り、各チームが迷わず使える形にすることが、Power Platform Managed Identity / Microsoft Entra ID を実務で活かす最短ルートです。
コメント