Power Platform Managed Identity / Microsoft Entra IDを使う組織が今すぐ優先すべきことは、すべての自動化を一気に作り直すことではありません。まず、Power PlatformやDataverseプラグイン、関連するAzureリソース接続に残っているパスワード、クライアントシークレット、APIキー、期限切れ間近の資格情報を棚卸しし、漏えい時の影響が大きい順にシークレットレス認証へ移行することです。
2026年4月20日にMicrosoft Security Blogで公開された「Making opportunistic cyberattacks harder by design」は、Power Platform Managed Identityを単なる便利機能ではなく、機会的攻撃を入り口から減らすための設計原則として位置付けています。Microsoftは、盗まれる資格情報そのものを減らし、公開エンドポイントを絞り、ワークロードごとに監査可能なIDを持たせる考え方を強調しています。Power Platform Managed Identityは、この「secret-free enterprise automation」をPower Platform側で実現するための重要な選択肢です。(Microsoft)
この記事では、Security teams、compliance leads、platform architectsが、Power Platform Managed Identity / Microsoft Entra IDの最新動向をどう読み解き、どのリスク低減策から着手すべきかを実務目線で整理します。
Power Platform Managed Identity / Microsoft Entra IDの最新動向を安全対策として読む
今回のMicrosoft発信で重要なのは、「マネージドIDが使えるようになった」という機能紹介よりも、認証情報を残さない設計に寄せるべきだというメッセージです。
従来のPower Platform連携では、Dataverseプラグイン、カスタム処理、Azure Key Vault、Azure Storage、Azure Functions、外部APIなどに接続するために、アプリ登録のクライアントシークレットやAPIキーを構成ファイル、環境変数、Key Vault、運用台帳で管理するケースがありました。これらは適切に管理すれば有効ですが、漏えい、期限切れ、過剰権限、退職者による放置、テスト環境からの横展開といった運用リスクを抱えます。
Microsoftのブログでは、攻撃者は必ずしも高度な侵入をするのではなく、盗まれた資格情報で「ログインする」ことが多いという前提から、ワークロードがシークレットなしで認証できるならそう設計すべきだと説明しています。Power Platform Managed Identityは、Power Platformコンポーネントにテナント所有のIDを持たせ、埋め込みパスワードやクライアントシークレットではなくフェデレーション資格情報でAzureリソースに認証する方向性を支えるものです。(Microsoft)
| 観点 | 従来のシークレット運用 | Power Platform Managed Identity活用時の考え方 |
|---|---|---|
| 認証情報 | クライアントシークレット、証明書、APIキーを保管・更新する | ワークロードIDとフェデレーション資格情報で認証する |
| 主なリスク | 漏えい、期限切れ、リポジトリへの誤コミット、共有アカウント化 | IDごとの権限管理、監査、失効が中心になる |
| 運用負荷 | ローテーション、期限管理、保管場所の統制が必要 | IDライフサイクル、RBAC、ログ監視の設計が重要 |
| 監査 | 「誰のシークレットか」「どこで使うか」が曖昧になりやすい | ワークロード単位で追跡しやすい |
| 注意点 | シークレットを厳格に管理すれば短期的には使える | マネージドID化しても過剰権限ならリスクは残る |
Power Platform Managed Identityとは何か
Power Platform Managed Identityは、Power Platform環境内のDataverseプラグインなどが、資格情報を直接管理せずにAzureリソースへ接続するための仕組みです。Microsoft Learnでは、Power Platform Managed Identityはフェデレーション資格情報に基づくワークロードIDを利用し、企業のMicrosoft Entra IDテナント内にユーザー割り当てマネージドID、またはアプリ登録を作成して構成すると説明されています。(Microsoft Learn)
現時点で公開ドキュメント上、Power Platform Managed Identityのサポート対象として明示されている代表的なシナリオはDataverseプラグインです。Microsoft Security BlogではPower PlatformコンポーネントやPower Automateにも言及されていますが、実装時は各サービス、リージョン、コネクタ、環境種別で対応状況が変わる可能性があります。特にグローバル展開している企業では、「Power Platform全体で一律に使える」と決めつけず、対象ワークロードごとにMicrosoft Learnと管理センター上の実際の選択肢を確認してください。(Microsoft)
Microsoft Entra IDとの関係
Microsoft Entra IDは、Power Platform Managed Identityの土台になるID基盤です。AzureのマネージドIDには、リソースとライフサイクルが紐づくシステム割り当てマネージドIDと、独立したAzureリソースとして作成し複数リソースで利用できるユーザー割り当てマネージドIDがあります。Microsoftのドキュメントでは、ユーザー割り当てマネージドIDは複数リソースで共有でき、独立したライフサイクルを持つと説明されています。(Microsoft Learn)
Power Platform Managed Identityを導入する際は、「IDを作る」だけでは不十分です。次の3点をセットで設計する必要があります。
- どのPower Platformコンポーネントが、どのIDを使うのか
- そのIDに、どのAzureリソースへの、どの操作権限を付与するのか
- そのIDのサインイン、リスク、権限変更を誰が監視するのか
この3点が曖昧なまま移行すると、シークレットは減っても「使い回しの強いID」が増えるだけになり、攻撃時の影響範囲を小さくできません。
影響評価で最初に見るべき範囲
Power Platform Managed Identity / Microsoft Entra IDの安全対策は、全体棚卸しから始めます。特に優先度が高いのは、業務データ、個人情報、財務データ、顧客データ、管理APIにアクセスする自動化です。
| 優先度 | 確認対象 | 見るべきリスク | 初動 |
|---|---|---|---|
| 高 | DataverseプラグインからAzure Key Vault、Storage、SQL、Functionsへ接続している処理 | シークレット漏えい時に機密データや後続APIへアクセスされる | Power Platform Managed Identity化の候補にする |
| 高 | クライアントシークレットを使うアプリ登録、サービスプリンシパル | 期限切れ停止、退職者管理、過剰なアプリ権限 | 未使用・期限切れ間近・高権限を抽出する |
| 高 | 本番環境と検証環境で同じIDや同じシークレットを使う処理 | 検証環境の侵害から本番へ横展開される | 環境別IDへ分離する |
| 中 | Power Automateやカスタムコネクタの外部API連携 | コネクタ所有者依存、個人アカウント依存 | 接続所有者、認証方式、DLPポリシーを確認する |
| 中 | パブリック到達可能なAzureリソース | 認証突破前のスキャン、総当たり、脆弱性探索 | Private Link、VNet、IP制限を検討する |
| 低 | 低権限かつ限定データのみ扱うテスト処理 | 影響は小さいが放置されやすい | 移行候補として台帳化する |
棚卸しでは、「どこにシークレットが保存されているか」だけでなく、「そのシークレットで何ができるか」を必ず記録します。漏えい時にKey Vault全体を読めるのか、特定のシークレットだけを読めるのか、Storageアカウント全体を操作できるのかで、優先順位は大きく変わります。
優先すべきリスク低減策
シークレットの棚卸しと削除を最初の成果にする
最初の30日で狙うべき成果は、すべての自動化をマネージドID化することではありません。まず、使われていないアプリ、期限切れが近い資格情報、不要なクライアントシークレット、高権限のまま放置されたサービスプリンシパルを減らします。
Microsoft DefenderのApp governanceでは、最終使用日、未使用の資格情報、資格情報の有効期限などでアプリを並べ替え・フィルターし、未使用アプリや期限切れ間近の資格情報をトリアージできます。大規模環境では、これを手作業の台帳更新ではなく、定期的なレビュー運用に組み込むことが重要です。(Microsoft Learn)
実務では、次のような判断基準が使いやすいです。
| 条件 | 判断 | 対応 |
|---|---|---|
| 90日以上使われていないアプリ登録 | 廃止候補 | 所有者確認後、無効化してから削除 |
| 高権限なのに所有者が不明 | 重大リスク | 所有者を再設定し、権限を即時見直し |
| 本番データへアクセスし、クライアントシークレットを使用 | 移行優先 | Power Platform Managed Identityまたはフェデレーション認証を検討 |
| 検証環境と本番環境で同じ資格情報を使用 | 横展開リスク | 環境別にIDを分離 |
| 有効期限が近いが利用実態が不明 | 障害リスク | 更新ではなく、利用実態確認を先に行う |
ここで重要なのは、「期限が近いから新しいシークレットを発行する」という反射的な対応を避けることです。更新のたびに、マネージドID化できないか、権限を削れないか、そもそも廃止できないかを確認します。
DataverseプラグインからのAzure接続はPower Platform Managed Identity化を優先する
DataverseプラグインがAzure Key Vault、Azure Storage、Azure SQL、Azure Functionsなどへ接続している場合は、Power Platform Managed Identityの優先候補です。Microsoft Learnでは、Power Platform Managed Identityの設定手順として、アプリ登録またはユーザー割り当てマネージドIDの作成、フェデレーション資格情報の構成、Dataverseプラグインの登録、Dataverse側のマネージドIDレコード作成、Azureリソースへのアクセス許可、統合検証が示されています。(Microsoft Learn)
導入時の実務ポイントは、次のとおりです。
| 設計項目 | 推奨される考え方 | 失敗しやすい例 |
|---|---|---|
| IDの粒度 | 本番・検証・開発を分け、重要処理は用途別に分ける | すべてのプラグインで1つのIDを共有する |
| 権限 | Azure RBACやKey Vault権限を最小限にする | Key Vault全体の管理権限を付与する |
| 証明書 | 本番では信頼された発行元の証明書を使う | 自己署名証明書を本番で使い回す |
| スコープ | 必要なリソースと操作に限定する | .defaultだけで広く許可し、後から整理しない |
| 検証 | 失敗時のログ、FICのissuer/subject、権限不足を確認する | 接続成功だけで本番展開する |
Microsoft Learnでは、プラグインアセンブリの署名が必要であり、自己署名証明書は開発・テスト用途に限り、本番環境では使用しないよう注意されています。これはコンプライアンス上も重要です。証明書の発行元、期限、保管場所、更新手順を証跡として残しておくと、監査時に説明しやすくなります。(Microsoft Learn)
権限最小化は「移行後」にではなく「移行時」に行う
シークレットレス化は、権限最小化と同時に進めて初めて効果が出ます。クライアントシークレットをPower Platform Managed Identityに置き換えても、そのIDに過剰な権限を与えれば、侵害時の被害範囲は十分に小さくなりません。
たとえば、DataverseプラグインがKey Vaultから1つの外部APIキーを読むだけなら、Key Vault全体の管理権限は不要です。Storageに特定コンテナへ書き込むだけなら、サブスクリプション全体のContributor権限は過剰です。
移行時は、次の順で見直します。
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 現状確認 | 既存シークレットで可能な操作を洗い出す | 読み取り、書き込み、削除、管理操作を分ける |
| 必要権限の定義 | 業務処理に必要な最小操作だけを定義する | 障害対応用の権限を通常実行IDに混ぜない |
| ID作成 | 用途別・環境別にIDを作る | 共有IDは例外扱いにする |
| 権限付与 | Azure RBACや対象サービス側の権限を付与する | 広すぎる組み込みロールを安易に使わない |
| 検証 | 成功系だけでなく失敗系も確認する | 権限不足時に安全に失敗するかを見る |
Platform architectsは、このプロセスを個別案件の判断に任せず、標準テンプレート化すべきです。たとえば「DataverseプラグインからKey Vaultを読む標準パターン」「Storageへ書き込む標準パターン」「本番環境で使用できる証明書要件」を用意しておくと、各チームが安全な構成を選びやすくなります。
パブリックエンドポイントを減らす
Microsoftのブログでは、資格情報の削減とあわせて、公開された到達可能なエンドポイントを減らすことも重視されています。マネージドIDを使ってサービス間認証を行い、データプレーンをPrivate Linkやprivate endpointsで保護し、RDP/SSHのような管理用インバウンド経路を減らすことで、攻撃者が試せる入口を減らせるという考え方です。(Microsoft)
Power Platform側でも、Virtual Networkサポートを使うことで、Dataverseプラグインや対応コネクタからVNet内またはプライベートエンドポイントで保護されたリソースへ接続できるシナリオがあります。Microsoft Learnでは、Dataverseプラグイン、SQL Server、Azure Key Vault、Azure Blob Storage、HTTP with Microsoft Entra IDなどの対応シナリオが示されています。(Microsoft Learn)
ただし、VNet対応は「有効にすれば安全になる」設定ではありません。Power Platform環境でVirtual Networkサポートを有効にすると、対象サービスの実行時リクエストが委任サブネットとネットワークポリシーの影響を受け、公開リソースへの呼び出しが失敗する可能性があります。Microsoft Learnでも、有効化前にプラグインやコネクタのURL、接続方式を確認し、必要に応じてprivate endpointなどに変更するよう注意されています。(Microsoft Learn)
実務では、次の順で進めると失敗しにくくなります。
| フェーズ | やること | 注意点 |
|---|---|---|
| 設計 | Power Platform環境、Azureリソース、リージョン対応を確認する | グローバル企業では地域ごとの対応差を確認する |
| 検証 | 代表的なDataverseプラグインとコネクタで疎通確認する | 公開URLに依存する処理を洗い出す |
| 移行 | Azure Key VaultやStorageをprivate endpoint化する | 名前解決、Firewall、DNSを同時に確認する |
| 監視 | ブロックされた通信、失敗したプラグイン実行を監視する | セキュリティ強化が業務停止にならないよう段階展開する |
Microsoft Entra IDでワークロードIDの監視を強化する
Power Platform Managed Identityに移行しても、Microsoft Entra ID側の監視は必要です。むしろ、シークレット中心の監視から、ワークロードID中心の監視へ切り替える必要があります。
Microsoft Entra ID Protectionでは、ワークロードIDのリスク検出として、不審なサインイン、異常なサービスプリンシパル活動、不審なAPIトラフィックなどを確認できます。また、リスクデータはLog Analytics、Storage、Event Hubs、SIEMへエクスポートできます。(Microsoft Learn)
条件付きアクセスについては、特に注意が必要です。Microsoft EntraのワークロードID向け条件付きアクセスは、テナントに登録されたシングルテナントのサービスプリンシパルに適用できますが、マネージドID自体は対象外と説明されています。また、サービスプリンシパルをグループに入れても、そのグループに割り当てた条件付きアクセスはサービスプリンシパルには適用されないため、対象サービスプリンシパルを直接ポリシーに割り当てる必要があります。(Microsoft Learn)
| 対象 | 使える対策 | 注意点 |
|---|---|---|
| アプリ登録・サービスプリンシパル | ワークロードID向け条件付きアクセス、ID Protection、サインインログ | ポリシーはサービスプリンシパルへ直接割り当てる |
| マネージドID | サインインログ、Azure Activity logs、アクセスレビュー、RBAC監査 | 条件付きアクセスの対象範囲外である点を理解する |
| 高権限アプリ | App governance、リスク検出、所有者確認 | 未使用でも権限が強ければ削除優先度は高い |
| AIエージェントやCopilot Studio関連ID | Microsoft Entra側のエージェントID管理を検討 | プレビューや対応範囲は最新情報を確認する |
Security teamsは、Power Platform Managed Identity導入を「シークレットがなくなるから監視不要」と受け止めてはいけません。見るべき対象が、シークレットの期限管理から、ワークロードIDの行動、権限変更、異常なリソースアクセスへ変わるだけです。
30日・60日・90日の実行計画
最初の30日: リスクの見える化と即時削減
最初の30日は、棚卸しと廃止に集中します。新しい設計を始める前に、使われていない資格情報や過剰権限を減らすだけでもリスクを下げられます。
| 作業 | 成果物 | 担当 |
|---|---|---|
| Power PlatformからAzureへ接続する処理を一覧化 | 自動化・接続・所有者の台帳 | Platform architects |
| アプリ登録、サービスプリンシパル、資格情報を棚卸し | 未使用・期限切れ・高権限リスト | Security teams |
| 本番データへアクセスする処理を分類 | 移行優先度リスト | Security teams / compliance leads |
| 所有者不明の接続を洗い出す | 是正チケット | Platform team |
| すぐ廃止できるシークレットを削除 | 削除記録・承認記録 | Application owners |
この段階では、完璧な移行計画よりも「どのIDが、どのデータに、どの権限でアクセスしているか」を可視化することが重要です。
31〜60日: 高リスク処理をPower Platform Managed Identityへ移行する
次に、DataverseプラグインからAzureリソースへ接続する高リスク処理を選び、Power Platform Managed Identityのパイロットを行います。対象は、機密データを扱い、既にクライアントシークレットやAPIキーを使っている処理が適しています。
移行時は、次の点を必ず確認します。
- 既存シークレットを使う処理と新しいマネージドID処理を並行検証できるか
- Azureリソース側の権限が最小化されているか
- エラー時に資格情報やトークン情報がログへ出ないか
- FICのissuer、subject、tenant ID、environment IDが正しいか
- 本番証明書の管理責任者と更新手順が決まっているか
- 旧シークレットの削除日が移行計画に含まれているか
Microsoft Learnでは、Power Platform Managed Identity構成時にフェデレーション資格情報を設定し、DataverseにマネージドIDレコードを作成し、プラグインアセンブリまたはプラグインパッケージへ関連付ける流れが示されています。認証エラーが出た場合は、FICのissuerやsubjectの不一致を確認することが重要です。(Microsoft Learn)
61〜90日: 標準化と例外管理に移す
90日目までにやるべきことは、個別移行を続けることではなく、標準パターンを作ることです。Microsoftのブログでも、長期的にはplatform engineeringによって安全な既定値を作り、例外やばらつきを減らすことが攻撃面の削減につながると説明されています。(Microsoft)
標準化すべき項目は、少なくとも次の5つです。
| 標準化項目 | 内容 |
|---|---|
| ID命名規則 | 環境、用途、所有チーム、データ分類が分かる名前にする |
| 権限テンプレート | Key Vault読み取り、Storage書き込みなど用途別の最小権限を定義する |
| 証明書ポリシー | 本番で使える証明書、期限、保管、更新責任を定義する |
| 例外申請 | シークレット利用を続ける場合の期限、理由、承認者を記録する |
| 監査証跡 | 移行前後の権限、アクセスログ、削除済みシークレットを保存する |
Compliance leadsにとって重要なのは、「マネージドIDを導入した」という事実だけではありません。監査で説明できるのは、誰がリスクを評価し、どの権限を削り、どの例外をいつまで認め、どのログで継続監視しているかです。
よくある失敗と回避策
| 失敗 | 何が問題か | 回避策 |
|---|---|---|
| マネージドIDを1つだけ作り、複数システムで共有する | 侵害時の影響範囲が広がり、監査もしにくい | 用途別・環境別にIDを分ける |
| シークレットを残したままマネージドIDを追加する | 旧経路から侵害される可能性が残る | 移行完了後の削除日を計画に入れる |
| RBACを広く付与する | シークレットレスでも過剰権限になる | 必要操作から逆算して最小権限を付与する |
| 条件付きアクセスでマネージドIDも制御できると思い込む | マネージドIDはワークロードID向け条件付きアクセスの対象外 | ログ監視、RBAC監査、アクセスレビューで補完する |
| VNet対応を一括有効化する | 既存の公開URL呼び出しが失敗する可能性がある | 代表環境で疎通検証し、DNSとPrivate Linkを確認する |
| 本番で自己署名証明書を使う | 信頼性・監査性・更新管理に問題が出やすい | 本番は信頼された証明書発行元を使う |
| Power Automateまで一律にPPMI対応と判断する | サービスやコネクタごとに対応状況が異なる | 対象フロー、コネクタ、認証方式を個別確認する |
役割別に見る次のアクション
Security teamsが優先すること
Security teamsは、まずMicrosoft Entra ID上のアプリ登録、サービスプリンシパル、ワークロードID、サインインログ、リスク検出を確認します。Power Platform側の接続一覧だけでは、AzureリソースやMicrosoft Graph権限まで見えないことがあります。
優先アクションは次のとおりです。
- 未使用アプリと未使用資格情報を抽出する
- 高権限アプリの所有者を確認する
- 本番データへアクセスするサービスプリンシパルを優先監視する
- リスク検出をSIEMやLog Analyticsへ送る
- 条件付きアクセスの対象になるサービスプリンシパルと、対象外のマネージドIDを分けて管理する
特に「所有者不明の高権限アプリ」は、シークレットの有無にかかわらずリスクが高い対象です。移行計画より先に、所有者再設定、無効化、権限削減を進めるべきです。
Compliance leadsが優先すること
Compliance leadsは、技術的な実装そのものよりも、説明可能性を重視します。監査で問われるのは、「なぜこのIDにこの権限があるのか」「例外は誰が承認したのか」「旧シークレットは削除されたのか」「ログはどこに残るのか」です。
用意すべき証跡は次のとおりです。
| 証跡 | 内容 |
|---|---|
| リスク評価表 | 対象自動化、扱うデータ、現行認証、移行優先度 |
| 権限設計書 | IDごとのAzure RBAC、Key Vault、Storageなどの権限 |
| 変更記録 | シークレット削除、ID作成、権限変更、承認者 |
| 例外台帳 | シークレット継続利用の理由、期限、補完統制 |
| 監視設計 | サインインログ、リスク検出、アラート、対応手順 |
「シークレットレス化したので安全です」では、監査対応として不十分です。「どの攻撃経路を減らし、残るリスクをどう監視しているか」まで説明できる状態を目指します。
Platform architectsが優先すること
Platform architectsは、個別案件ごとの最適化ではなく、組織全体で再利用できる安全な標準を作る役割です。Power Platform Managed Identityは、個々の開発者が都度調べて構成するには複雑な要素があります。フェデレーション資格情報、証明書、Dataverseレコード、Azure RBAC、ネットワーク制御が絡むためです。
そのため、次のような「paved path」を作ると効果的です。
| 標準パターン | 内容 |
|---|---|
| DataverseプラグインからKey Vaultを読む | PPMI、最小権限、監査ログ、証明書要件をセット化 |
| DataverseプラグインからStorageへ書く | コンテナ単位の権限、環境別ID、Private Linkを標準化 |
| 本番環境のID作成 | 命名規則、所有者、タグ、承認フローを統一 |
| シークレット例外 | 期限付き承認、ローテーション、検出ルールを必須化 |
| 廃止フロー | 旧シークレット、旧アプリ登録、未使用IDの削除手順を定義 |
安全な標準がない状態で「各チームでマネージドIDを使ってください」と依頼すると、構成のばらつきが増えます。結果として、シークレットは減っても、監査しづらいIDと例外が増える可能性があります。
Power Platform Managed Identity導入時の判断基準
Power Platform Managed Identityを使うべきか迷った場合は、次の基準で判断します。
| 質問 | Yesの場合 | Noの場合 |
|---|---|---|
| DataverseプラグインからAzureリソースへ接続しているか | PPMI候補として検討する | 他の認証方式やコネクタ設計を確認する |
| クライアントシークレットやAPIキーを使っているか | 移行優先度を上げる | 権限とログ監視を確認する |
| 本番データや機密データを扱うか | 最優先で影響評価する | 標準化後に移行してもよい |
| 旧シークレットの所有者が不明か | 即時是正対象にする | 所有者と更新手順を確認する |
| Private LinkやVNetで閉域化できるか | ID認証とネットワーク制御を組み合わせる | 代替のIP制限、DLP、監視を検討する |
| 条件付きアクセスで制御したい対象がサービスプリンシパルか | ワークロードID向けポリシーを検討する | マネージドIDの場合は別の統制で補完する |
判断のコツは、「使えるか」ではなく「漏えい時の被害をどれだけ小さくできるか」で見ることです。シークレットレス化、最小権限、ネットワーク露出削減、監視の4つが揃って初めて、実効性のあるリスク低減になります。
まとめ: まずシークレットを減らし、ID単位で守る設計へ移行する
Power Platform Managed Identity / Microsoft Entra IDの最新動向は、Power Platformの自動化をより安全にするための明確な方向性を示しています。Microsoftが強調しているのは、攻撃された後に検知するだけでなく、盗まれる資格情報や到達可能な入口を設計段階で減らすことです。
最初にやるべきことは、Power PlatformとAzureをつなぐ自動化を棚卸しし、クライアントシークレット、APIキー、期限切れ間近の資格情報、高権限サービスプリンシパルを特定することです。次に、DataverseプラグインからAzureリソースへ接続する高リスク処理をPower Platform Managed Identityへ移行し、権限を最小化します。その後、Private LinkやVNet対応、ワークロードID監視、例外管理、標準テンプレート化へ広げます。
「シークレットを別の場所に安全に保管する」だけでは、運用リスクは残ります。これからのPower Platformセキュリティでは、シークレットを持たない、IDを分ける、権限を絞る、公開面を減らす、ログで継続監視するという順番で設計することが重要です。
コメント