Power Platform Managed Identity / Microsoft Entra ID を導入する管理者が最初に確認すべきことは、「どの自動化からシークレットをなくすか」「どの ID にどの Azure 権限を与えるか」「利用者へ何を周知するか」の3点です。2026年4月20日の Microsoft Security Blog では、パスワード、クライアントシークレット、API キーを持たない設計を広げる文脈で Power Platform Managed Identity が取り上げられ、Dataverse プラグインや Power Automate などの Power Platform コンポーネントが、埋め込みシークレットではなくフェデレーション資格情報を使って Azure リソースへ認証する方向性が示されました。(Microsoft)
ただし、管理者がすぐに全環境へ一括展開するのは危険です。Microsoft Learn の公開ドキュメントでは、Power Platform Managed Identity のサポート対象として Dataverse プラグインと依存アセンブリ プラグインが GA と説明されています。Power Automate については、テナントや機能公開状況、公式ドキュメントの更新を確認しながら段階的に扱うのが現実的です。(Microsoft Learn)
Power Platform Managed Identity / Microsoft Entra ID の最新動向
Microsoft が今回強調しているポイントは、単なる「認証方法の追加」ではありません。狙いは、企業の自動化基盤から長寿命のシークレットを減らし、攻撃者が盗用できる資格情報そのものを減らすことです。
従来の Power Platform 連携では、次のような構成がよく使われていました。
| 従来の構成 | よくある問題 | Managed Identity 化で変わる点 |
|---|---|---|
| クライアントシークレットを環境変数に保存 | 期限切れ、漏えい、ローテーション漏れが起きやすい | シークレットを保存せず、Microsoft Entra ID でトークンを取得する |
| サービスアカウントで Power Automate やプラグインを実行 | 退職・異動・MFA・条件付きアクセス変更の影響を受けやすい | ワークロード専用 ID として権限を管理できる |
| Azure Key Vault や Storage への広い権限付与 | どの自動化がどの権限を使っているか追いにくい | ID 単位で RBAC、ログ、棚卸しを行いやすい |
| 複数環境で同じシークレットを使い回す | 開発・検証・本番の境界が曖昧になる | 環境ごとに ID とフェデレーション資格情報を分けやすい |
Microsoft Entra ID のマネージド ID は、アプリケーションが Microsoft Entra トークンを取得するための仕組みで、開発者が認証情報を直接管理しなくて済む点が重要です。Microsoft のドキュメントでも、マネージド ID はアクセスキー、パスワード、証明書などの代替として使えると説明されています。(Microsoft Learn)
管理者がまず見るべき設定差分チェックリスト
発表直後に確認すべきなのは、「新機能を有効化するか」だけではありません。既存のシークレット運用、Entra ID の権限設計、Power Platform 環境の ALM、利用者への周知をまとめて見直す必要があります。
| 確認項目 | 管理者が見るポイント | 初回アクション |
|---|---|---|
| 対象コンポーネント | Dataverse プラグイン、依存アセンブリ プラグイン、Power Automate、カスタムコネクタ、Azure 連携処理を分類する | まず GA として確認できる Dataverse プラグインから棚卸しする |
| 既存シークレット | クライアントシークレット、API キー、共有パスワード、環境変数、カスタムテーブルに保存された認証情報を洗い出す | 「保存場所」「期限」「利用者」「対象 Azure リソース」を一覧化する |
| ID の種類 | アプリ登録を使うか、ユーザー割り当てマネージド ID を使うかを決める | 1環境1用途を基本に、再利用しすぎない命名規則を作る |
| フェデレーション資格情報 | issuer、subject、audience、tenant ID、environment ID が一致しているか確認する | 開発環境で値を固定し、IaC または手順書へ落とす |
| Azure RBAC | Key Vault、Storage、SQL、API など接続先ごとに最小権限を割り当てる | Contributor や Owner を避け、用途別ロールに分ける |
| 証明書と署名 | プラグイン アセンブリまたはパッケージの署名方式を確認する | 自己署名証明書は開発・検証に限定し、本番は信頼された証明書を使う |
| 監査ログ | Microsoft Entra ID サインインログ、Azure Activity Log、Power Platform 側の変更履歴を確認する | ID 作成、FIC 作成、RBAC 付与、Dataverse レコード作成を変更管理に含める |
| ロールバック | シークレット廃止前に戻し手順を決める | 本番切替前に旧接続を一定期間だけ残し、検証後に削除する |
| グローバル展開 | Public、GCC、GCC High、DoD、中国クラウドなどで issuer や audience が異なる可能性を確認する | 国・リージョン別の環境一覧を作り、同じ値を流用しない |
Power Platform Managed Identity の設定手順では、アプリ登録またはユーザー割り当てマネージド ID の作成、フェデレーション ID 資格情報の構成、Dataverse 側のマネージド ID レコード作成、Azure リソースへのアクセス許可、統合検証が必要です。公式手順でもこの流れが示されています。(Microsoft Learn)
アプリ登録とユーザー割り当てマネージド ID の選び方
Power Platform Managed Identity では、Microsoft Entra ID 側でアプリ登録またはユーザー割り当てマネージド ID を用意します。どちらを選んでも「シークレットを持たない」設計に近づけますが、運用上の向き不向きがあります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| アプリ登録 | Azure Policy やアプリケーション単位の統制を強めたい。プラグインに明確なアプリ ID を持たせたい | アプリ登録の所有者、API 権限、証明書・フェデレーション資格情報の変更管理が必要 |
| ユーザー割り当てマネージド ID | Azure リソースへアクセスするサービスプリンシパルとして管理したい。複数リソースで独立した ID ライフサイクルを持たせたい | 使い回しすぎると、どの処理がどの権限を使っているか分かりにくくなる |
| 既存のサービスアカウント | 原則として新規採用は避ける | MFA、パスワード期限、退職・異動、権限過多のリスクが残る |
| 既存のクライアントシークレット | 短期の暫定運用に限定する | 期限切れと漏えいリスクが残るため、移行対象として扱う |
Microsoft Learn では、Azure Key Vault などに接続するプラグインにアプリ ID を関連付けたい場合はアプリ登録、Azure リソースへアクセスするサービスプリンシパルが必要な場合はユーザー割り当てマネージド ID をプロビジョニングできると説明されています。(Microsoft Learn)
実務では、「1つの ID を全社で共用する」よりも、「業務システム」「環境」「接続先リソース」ごとに分ける方が監査しやすくなります。たとえば、営業本番環境の Dataverse プラグインが Key Vault から外部 API キーを取得する場合、uami-sales-prod-kv-reader のように用途が分かる名前を付けると、後から権限を見直しやすくなります。
導入手順チェックリスト
事前準備: 対象自動化を棚卸しする
最初に、Power Platform 環境内で Azure リソースへ接続している処理を洗い出します。対象は Dataverse プラグインだけではありません。Power Automate のクラウドフロー、カスタムコネクタ、環境変数、Azure Key Vault 参照、外部 API 呼び出しも確認します。
棚卸しでは、次の項目を最低限記録します。
| 項目 | 記録例 |
|---|---|
| 環境 | Sales-Prod、Finance-Test |
| 処理名 | 顧客登録後の外部 CRM 同期プラグイン |
| 接続先 | Azure Key Vault、Storage Account、Azure Function、外部 API |
| 現在の認証方式 | クライアントシークレット、API キー、サービスアカウント |
| 権限の範囲 | Key Vault の Secrets User、Storage の Data Reader など |
| 業務影響 | 失敗時に受注登録が止まる、通知だけ遅延するなど |
| 移行優先度 | 高、中、低 |
優先度は「シークレットの期限が近いもの」ではなく、「漏えい時の影響が大きいもの」「本番障害につながるもの」「複数環境で使い回されているもの」から決めます。
Microsoft Entra ID で ID を作成する
次に、アプリ登録またはユーザー割り当てマネージド ID を作成します。この時点で、アプリケーション ID、クライアント ID、テナント ID、リソースグループ、サブスクリプション、所有者を記録しておきます。
命名規則は運用に直結します。たとえば次のように、用途が一目で分かる形式にすると監査と問い合わせ対応が楽になります。
uami-<system>-<env>-<purpose>
app-<system>-<env>-<purpose>例:
uami-sales-prod-keyvault-reader
app-dataverse-prod-customer-syncフェデレーション ID 資格情報を構成する
Power Platform Managed Identity の中心になるのが、Microsoft Entra ID のフェデレーション ID 資格情報です。Power Platform 側のワークロードが発行する情報と、Entra ID 側の issuer、subject、audience が一致していないと、トークン交換に失敗します。
公式手順では、issuer としてテナントの v2.0 発行者を使う例が示されています。
https://login.microsoftonline.com/{tenantID}/v2.0また、subject には環境 ID、証明書ハッシュ、発行者、証明書サブジェクトなどが関わります。自己署名証明書は開発用途、本番環境では信頼された発行者証明書が推奨されています。(Microsoft Learn)
フェデレーション資格情報には制約もあります。Microsoft Entra ID のドキュメントでは、アプリケーションまたはユーザー割り当てマネージド ID に追加できるフェデレーション ID 資格情報は最大20個とされています。また、issuer と subject の組み合わせはトークン交換時に照合されます。(Microsoft Learn)
そのため、環境ごと、証明書ごと、プラグインごとに無計画に FIC を増やすと、後から制限にぶつかります。大規模環境では、最初から「ID を分ける単位」を設計しておくことが重要です。
Dataverse プラグインを署名し、登録する
Dataverse プラグインまたはプラグイン パッケージで Power Platform Managed Identity を使う場合、プラグインのビルド、署名、登録が必要です。公式手順では、プラグイン登録ツール、SignTool.exe、Power Platform CLI、有効な証明書が前提として示されています。(Microsoft Learn)
開発チームには、次の点を必ず周知します。
| 周知項目 | 理由 |
|---|---|
| プラグイン内にクライアントシークレットを埋め込まない | Managed Identity 化の目的と矛盾するため |
| 環境変数にシークレットを保存しない | 移行後も漏えいリスクが残るため |
| トークン取得処理を共通化する | プラグインごとの実装差異を減らすため |
| 例外ログにトークンや機密値を出さない | 認証情報をなくしてもログから漏れる可能性があるため |
| 本番では自己署名証明書を使わない | 信頼性と監査対応で問題になりやすいため |
Dataverse にマネージド ID レコードを作成する
Power Platform 側では、Dataverse にマネージド ID レコードを作成し、プラグイン アセンブリまたはプラグイン パッケージへ関連付けます。公式手順では、Dataverse Web API への POST で managedidentities レコードを作成し、その後 pluginassemblies または pluginpackages へ PATCH して関連付ける流れが示されています。(Microsoft Learn)
ここで失敗しやすいのは、ID の値を取り違えることです。アプリケーション ID、クライアント ID、テナント ID、Dataverse の managedidentityid、PluginAssemblyId は似た名前で扱われます。作業者が複数いる場合は、Excel やチケットに値を貼るだけでなく、どの画面から取得した ID かまで記録してください。
Azure リソースへ最小権限を付与する
最後に、作成した ID に Azure リソースへのアクセス権を付与します。ここで広い権限を与えると、シークレットをなくしても侵害時の影響範囲が大きくなります。
| 接続先の例 | 付与する権限の考え方 |
|---|---|
| Azure Key Vault | 読み取りだけなら Secrets User など、必要な操作に限定する |
| Azure Storage | Blob の読み取りだけか、書き込みも必要かを分ける |
| Azure SQL | データベース側のロールと Entra ID 認証を分けて確認する |
| Azure Function / App Service | 呼び出しに必要な認証方式、ネットワーク制限、API 側の認可を確認する |
| カスタム API | API 側でアプリロールやスコープを定義し、呼び出し元 ID を識別できるようにする |
権限付与後は、プラグインが Azure リソースへ安全にアクセスできること、追加の資格情報が不要になっていることを検証します。公式手順でも、最後にプラグイン統合の検証を行うことが示されています。(Microsoft Learn)
Power Automate はどう扱うべきか
2026年4月20日の Microsoft Security Blog では、Power Platform Managed Identity が Dataverse プラグインや Power Automate などの Power Platform コンポーネントに、テナント所有の ID を提供する文脈で言及されています。(Microsoft)
一方で、公開されている Microsoft Learn の Power Platform Managed Identity 概要では、サポート対象サービスとして Dataverse プラグインと依存アセンブリ プラグインが GA と記載されています。(Microsoft Learn)
そのため、管理者は Power Automate を次のように扱うのが安全です。
| 状況 | 判断 |
|---|---|
| Dataverse プラグインから Azure Key Vault や Storage に接続している | Power Platform Managed Identity の優先移行候補にする |
| Power Automate のフローにクライアントシークレットが埋め込まれている | まず棚卸しし、公式対応状況を確認しながら移行計画を立てる |
| カスタムコネクタで Entra ID OAuth を使っている | アプリ登録、証明書、シークレット期限、接続所有者を見直す |
| サービスアカウント所有のフローが多い | 所有者、接続参照、DLP ポリシー、環境戦略を先に整理する |
| すぐ本番フローを Managed Identity 前提に変更したい | 公式ドキュメント、テナントの機能公開状況、サポート窓口の回答を確認してから進める |
重要なのは、Power Automate を「対象外」と決めつけないことです。Microsoft が secret-free enterprise automation の方向性を明確にしている以上、フロー側のシークレット棚卸し、接続所有者の整理、カスタムコネクタの認証方式見直しは今すぐ始める価値があります。
周知チェックリスト
Power Platform Managed Identity / Microsoft Entra ID の導入は、管理者だけで完結しません。開発者、運用担当、業務部門、セキュリティ担当の理解がずれると、移行後に「なぜ接続が失敗したのか」「誰に権限申請すればよいのか」が分からなくなります。
| 対象者 | 周知する内容 | 伝え方の例 |
|---|---|---|
| IT 管理者 | Entra ID のアプリ登録、UAMI、FIC、RBAC の作成・変更ルール | 変更管理フローと標準命名規則を配布する |
| セキュリティ担当 | シークレット削減の目的、ログ監査、最小権限、例外申請 | 「例外は期限付き承認」と明記する |
| 開発者 | プラグインにシークレットを保存しない、署名証明書を正しく使う、トークン取得を共通化する | サンプルコードと禁止パターンをセットで共有する |
| Power Platform 作成者 | 環境変数や接続情報に機密値を置かない、サービスアカウント依存を減らす | 作成者向けガイドに「やってはいけない例」を載せる |
| 業務部門オーナー | 移行時の影響、検証期間、障害時の問い合わせ先 | 対象フロー・プラグイン一覧と検証観点を共有する |
| ヘルプデスク | 認証エラー時の一次切り分け、問い合わせ先、ログ採取項目 | エラー別のテンプレートを用意する |
| 展開計画担当 | 開発、検証、本番の順序、ロールバック、旧シークレット削除日 | リリース判定表を作る |
特に重要なのは、「シークレットを消す日」を明確にすることです。Managed Identity 化が成功しても、旧クライアントシークレットやサービスアカウントが残っていれば、攻撃面は十分に減りません。移行完了後に、不要なシークレット、古いアプリ登録、使われていない接続を削除する作業まで計画に含めてください。
展開順序のおすすめ
いきなり全環境で切り替えるのではなく、影響範囲を絞って検証し、標準化してから横展開します。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 準備 | シークレット利用箇所、対象プラグイン、Azure 接続先を棚卸しする | 優先順位と対象一覧が承認されている |
| パイロット | 開発環境の低リスクな Dataverse プラグインで検証する | トークン取得、Azure アクセス、ログ確認が完了している |
| 検証環境 | 本番に近い証明書、RBAC、FIC、ネットワーク条件で確認する | 業務部門が正常系・異常系を確認している |
| 本番適用 | メンテナンス時間を決め、旧認証方式から切り替える | 主要処理が成功し、監査ログで ID 利用を確認できる |
| 旧設定削除 | クライアントシークレット、不要な接続、古い権限を削除する | 旧シークレットが無効化され、再利用できない |
| 標準化 | 命名規則、申請フロー、サンプル実装、監査手順を整備する | 次の案件が同じ手順で展開できる |
パイロット対象は、重要すぎる処理でも、利用実績が少なすぎる処理でもなく、「Azure Key Vault などに接続していて、失敗時の影響を切り分けやすいプラグイン」が向いています。最初の1件で手順、ログ、権限申請、ロールバックを確認してから、業務クリティカルな処理へ広げます。
失敗しやすいポイントと対策
AADSTS700213 が出る
AADSTS700213: 一致するフェデレーション ID レコードが見つかりません のようなエラーは、FIC の issuer や subject が一致していない場合に起きやすい問題です。公式 FAQ でも、FIC が正しく構成・保存されているか、発行者とサブジェクトが指定形式と一致しているかを確認するよう案内されています。(Microsoft Learn)
対策は、手入力を減らすことです。tenant ID、environment ID、証明書情報を取得する担当と、FIC を登録する担当が違う場合は、コピー元の画面、取得日時、対象環境を記録します。
開発環境の自己署名証明書を本番に流用する
自己署名証明書は検証には便利ですが、本番運用では監査や信頼性の面で問題になりやすくなります。公式手順でも、自己署名証明書は開発またはテスト目的でのみ使用し、本番では使わないよう示されています。(Microsoft Learn)
対策は、検証段階から本番証明書の取得・更新フローを設計することです。証明書の有効期限、所有者、更新手順をチケット化し、シークレット削減のために別の期限切れリスクを増やさないようにします。
RBAC を広く付けすぎる
Managed Identity 化しても、Azure 側で Owner や Contributor を広く付けると、侵害時の影響範囲は大きいままです。最小権限を徹底し、読み取りだけでよい処理に書き込み権限を与えないようにします。
実務では、「動かないから一時的に Contributor」を許すと、そのまま残りがちです。一時権限を使う場合は、有効期限、承認者、削除日を必ず記録してください。
旧シークレットを削除し忘れる
移行後に旧クライアントシークレットや API キーが残っていると、攻撃者にとってはまだ利用可能な入口になります。切り替え後は、ログで新しい ID の利用を確認し、旧シークレットを無効化・削除する日を決めます。
「移行完了」の定義を、単に新方式で動いたことではなく、「旧資格情報を削除し、不要な権限を外し、監査ログで確認したこと」まで含めるのが安全です。
管理者が今すぐ取るべきアクション
Power Platform Managed Identity / Microsoft Entra ID の導入では、最初に大きな設計書を作るより、短期間で棚卸しとパイロットを始める方が効果的です。
まず、Power Platform 環境で使われているクライアントシークレット、サービスアカウント、API キーを一覧化します。次に、Dataverse プラグインのうち Azure Key Vault や Azure Storage に接続しているものを1つ選び、開発環境でアプリ登録またはユーザー割り当てマネージド ID、FIC、RBAC、Dataverse 側のマネージド ID レコード作成まで通します。
その結果をもとに、命名規則、権限申請、証明書管理、障害時の切り分け、旧シークレット削除までを標準手順にします。Microsoft の発表を「新機能のニュース」で終わらせず、シークレットを持たない Power Platform 自動化へ移行するための運用変更として扱うことが、管理者にとって最も重要です。
コメント