2026年4月20日にMicrosoft Security Blogで公開された「Making opportunistic cyberattacks harder by design」は、Microsoft Entra ID、managed identities、enterprise security architecture の今後を読むうえで重要な材料です。結論から言うと、これからの基準は「漏えいした資格情報を早く検知してローテーションする」だけではなく、そもそもパスワード、client secret、API keyをシステムに持たせない設計へ移ることです。Microsoftは、攻撃者の多くがネットワークを破るのではなく盗まれた資格情報でログインすると説明し、ワークロードがシークレットなしで認証できるならそうすべきだという原則を示しています。(マイクロソフト)
プロダクトオーナー、IT意思決定者、技術戦略担当者が見るべきポイントは、単発のセキュリティニュースではありません。Microsoft Entra IDを中心に、managed identities、workload identity federation、Conditional Access、AIエージェントID、Private Link、プラットフォームエンジニアリングを組み合わせ、組織全体の「安全な標準経路」を作ることです。この記事では、2026年4月20日時点の更新をきっかけに、Microsoft Entra ID / managed identities / enterprise security architecture の中期的なロードマップと、今後の運用方針を実務目線で整理します。
Microsoft Securityの更新が示す本質は「資格情報管理」から「資格情報排除」への転換
Microsoft Security Blogの主張は明確です。攻撃機会を減らすには、攻撃者が使い回せる資格情報を減らす必要があります。パスワード、client secret、API key、期限切れを忘れた証明書、リポジトリに誤ってコミットされたシークレットは、いずれも機会攻撃の入口になり得ます。Microsoftは、Azure上では managed identities と federated identity patterns を中心に、保存・ローテーション・期限管理が必要な共有シークレットを減らす方向を示しています。(マイクロソフト)
この変化を「シークレット管理ツールが不要になる」という意味に捉えると誤ります。Key Vaultやシークレット管理は引き続き必要です。ただし、今後の設計判断では、最初に「この接続に本当に保存型のシークレットが必要か」を問うべきです。必要な場合だけ安全に保管し、不要な場合は managed identities や workload identity federation に置き換える、という順序が標準になります。
Microsoftの公式ドキュメントでも、managed identities はアプリケーションが資格情報を管理せずに Microsoft Entra トークンを取得する仕組みとして説明されています。管理者や開発者が資格情報を直接扱わず、Microsoft Entra 認証をサポートするリソースへアクセスできる点が大きな利点です。(Microsoft Learn)
Microsoft Entra IDのロードマップは「人」だけでなく「非人間ID」中心に読む
従来のID管理は、ユーザーIDを中心に考えられてきました。しかし、クラウド、CI/CD、ローコード、AIエージェントが増えるほど、実際のリスクはアプリケーション、サービスプリンシパル、managed identities、AIエージェントなどの非人間IDに広がります。
Microsoft Entraでは、workload identities はアプリケーション、サービスプリンシパル、managed identitiesを含む概念として整理されています。ソフトウェアワークロードは複数の資格情報を扱うことが多く、作成時期や失効タイミングの追跡が難しいため、企業にとって攻撃・侵害リスクになりやすい領域です。(Microsoft Learn)
この文脈で見ると、Microsoft Entra IDの中期的な方向性は次のように読めます。
| 領域 | 従来の考え方 | 今後の標準的な考え方 |
|---|---|---|
| 人のサインイン | パスワード＋MFAで守る | パスキー、Windows Hello for Business、証明書ベース認証など、フィッシング耐性の高い認証へ移行する |
| Azureワークロード | client secretや接続文字列を保管する | managed identitiesでトークンベース認証に置き換える |
| CI/CD・Kubernetes・マルチクラウド | 長期シークレットを発行して保管する | workload identity federationで外部IdPのトークンを信頼し、必要時にアクセストークンを取得する |
| Power Platform | Dataverseプラグインなどに資格情報を持たせる | Power Platform managed identityでAzureリソースへ資格情報なしで接続する |
| AIエージェント | ユーザーアカウントや通常のサービスプリンシパルで代替する | Microsoft Entra Agent IDでエージェントを専用IDとして管理する |
Microsoft Entra IDの認証ドキュメントでは、Windows Hello for Business、passkeys、FIDO2 security keys、certificate-based authenticationなどがフィッシング耐性のある認証方式として位置付けられています。つまり、人間ユーザーについても「パスワードを強くする」より「パスワード依存を下げる」方向が鮮明です。(Microsoft Learn)
managed identitiesを採用すべき場面と、まだ慎重に見るべき場面
managed identities は万能ではありません。採用判断では、接続元、接続先、ライフサイクル、監査要件、利用できるポリシー範囲を確認する必要があります。
| 判断項目 | 推奨される選択 |
|---|---|
| Azure App Service、Functions、VM、AKSなどからAzureリソースへ接続する | まずmanaged identitiesを検討する |
| 1つのAzureリソースにだけ紐づく短命な用途 | system-assigned managed identityが向く |
| 複数リソースで同じIDを使いたい、IDのライフサイクルをリソースから分離したい | user-assigned managed identityが向く |
| GitHub Actions、外部Kubernetes、AWS、Google CloudなどからMicrosoft Entra保護リソースへ接続する | workload identity federationを検討する |
| DataverseプラグインからAzure Key VaultやAzure Storageへ接続する | Power Platform managed identityを検討する |
| サードパーティ製品がOIDCやmanaged identityに対応していない | 証明書認証やシークレット管理を使いつつ、移行計画を持つ |
Microsoftのmanaged identitiesドキュメントでは、system-assigned identity はAzureリソースのライフサイクルに紐づき、user-assigned identity は独立したAzureリソースとして作成され、複数のAzureリソースで利用できると説明されています。また、Microsoftサービスでは user-assigned managed identity が推奨されるmanaged identityタイプとされています。(Microsoft Learn)
一方で、Conditional AccessやID Protectionの対象範囲には注意が必要です。Conditional Accessのドキュメントでは、workload identity向けポリシーはテナント内の単一テナントサービスプリンシパルに適用できる一方、managed identitiesはポリシー対象外とされています。ID Protectionのworkload identityリスク検出でも、managed identitiesは現時点で対象外と明記されています。(Microsoft Learn)
つまり、managed identitiesを使えばすべての統制が自動的に解決するわけではありません。監査ログ、RBAC、Azure Policy、リソース側のアクセス制御、ネットワーク制御、Key VaultやStorage側の診断ログを組み合わせて、実効性のあるガバナンスを作る必要があります。
workload identity federationはCI/CDとマルチクラウドの最優先テーマになる
GitHub Actions、Azure Pipelines、Kubernetes、AWS、Google Cloudなど、Azureの外で動くワークロードに長期シークレットを配布している場合、優先度は高いです。workload identity federationは、外部IdPが発行したトークンをMicrosoft Entra IDが信頼し、Microsoft Entra保護リソースへアクセスするためのアクセストークンと交換する仕組みです。これにより、外部ワークロードのためにシークレットや証明書を保管・ローテーションする負担を減らせます。(Microsoft Learn)
実務で特に効果が出やすいのは、次のようなケースです。
| 移行対象 | よくある現状 | 改善後の姿 |
|---|---|---|
| GitHub ActionsのAzureデプロイ | リポジトリシークレットにclient secretを保存 | OIDC連携でMicrosoft Entra IDのトークンを取得 |
| AKSのPodからKey Vaultへアクセス | Podにシークレットや接続文字列を注入 | Microsoft Entra Workload IDでサービスアカウントとIDを紐づける |
| 外部KubernetesからAzure Storageへアクセス | 長期キーをConfigMapやSecretに保存 | workload identity federationでトークンベース認証 |
| マルチクラウド連携 | クラウド間で静的キーを共有 | 外部IdPとの信頼関係を作り、必要時にアクセストークンを取得 |
AKSのMicrosoft Entra Workload IDでは、KubernetesのサービスアカウントとOIDC federationを使い、Azure Identity client librariesやMSALと組み合わせてAzureリソースへアクセスできます。ただし、managed identityあたりのfederated identity credentials数など、設計時に確認すべき制限もあります。(Microsoft Learn)
Power Platformも「ローコードだから例外」ではなくなる
Microsoft Security Blogでは、Power Platform Managed Identityにも触れられています。DataverseプラグインやPower AutomateなどのPower Platformコンポーネントに、埋め込みパスワードやclient secretではなく、テナント所有のIDとfederated credentialsを使わせる方向です。(マイクロソフト)
Power Platform managed identityの公式ドキュメントでは、DataverseプラグインからAzure managed identityをサポートするリソースへ、資格情報を管理せずに接続できると説明されています。たとえば、DataverseプラグインからAzure Key Vaultへ接続し、キーやシークレットを取得する用途が挙げられています。(Microsoft Learn)
これは、エンタープライズセキュリティアーキテクチャ上かなり重要です。多くの企業では、Power Platformは業務部門主導で拡大しやすく、プロ開発の標準セキュリティ設計から外れがちです。今後は、Power Platform環境も次の観点で設計レビューに含めるべきです。
| 確認項目 | 実務上のチェックポイント |
|---|---|
| Dataverseプラグイン | Azureリソース接続に埋め込み資格情報を使っていないか |
| カスタムコネクタ | シークレットの保管場所、期限、所有者が明確か |
| Azure Key Vault連携 | managed identityでアクセスできる構成にできるか |
| 環境分離 | 開発・検証・本番でIDと権限が分離されているか |
| ネットワーク | Power Platform Virtual Network supportやprivate endpointの利用余地があるか |
Power PlatformのVirtual Network supportでは、Dataverseプラグインやコネクタから企業ネットワーク内のリソースへプライベートなアウトバウンド接続を作れるため、資格情報排除と合わせて「公開面の縮小」にもつながります。(Microsoft Learn)
AIエージェント時代のEntra IDはAgent IDを前提に考える
Microsoft Entra IDの今後を読むうえで、AIエージェントIDは避けて通れません。Microsoft Entra Agent IDは、AIエージェント向けにMicrosoft Entraの機能を拡張するIDおよびセキュリティフレームワークとして説明されています。ただし、2026年4月時点ではプレビューであり、正式導入時は対象機能、ライセンス、利用条件を確認する必要があります。(Microsoft Learn)
重要なのは、AIエージェントを通常のユーザーアカウントやサービスプリンシパルで雑に代替しないことです。MicrosoftのAgent IDの概念説明では、通常のサービスプリンシパルは静的で決定論的なワークロード向けに設計されたものであり、AIエージェントに必要なガバナンス構造が不足すると説明されています。また、通常のユーザーアカウントをAIエージェントに割り当てることも推奨されていません。(Microsoft Learn)
Microsoft Entraのリリース情報でも、Conditional Access for Agents、Agent identity sponsor lifecycle support、Microsoft Entra agent registry、Microsoft Entra ID Protection for Agentsなど、エージェントを独立した統制対象として扱う機能がプレビューとして示されています。(Microsoft Learn)
AIエージェントを業務に組み込む企業は、次のルールを早めに決めておくべきです。
| 設計テーマ | 決めるべき方針 |
|---|---|
| エージェントの所有者 | 技術管理者だけでなく、業務上のスポンサーを設定する |
| 権限付与 | 人間ユーザーの権限を無制限に借用させず、用途別に最小権限を定義する |
| 監査 | エージェントの認証、アクセス、操作ログを追跡できる状態にする |
| ライフサイクル | エージェントの作成、変更、停止、廃止の承認フローを作る |
| 例外管理 | 検証中のエージェントと本番利用エージェントを分離する |
enterprise security architectureで見るべき4つのロードマップ
ここでいうロードマップは、Microsoftの未発表リリース日を予測するものではありません。Microsoftが公開している方針と機能から、企業側がどう採用順序を組むべきかを整理したものです。
短期：資格情報と公開エンドポイントの棚卸し
最初にやるべきことは、新しいツールの導入ではなく棚卸しです。対象はユーザーアカウントだけではありません。アプリ登録、サービスプリンシパル、client secret、証明書、API key、接続文字列、CI/CDシークレット、Power Platformの接続、Key Vault内の長期シークレットまで含めます。
優先度は、次の順で付けると実務に落とし込みやすくなります。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | インターネット公開サービスに接続するシークレット | 漏えい時の悪用範囲が大きい |
| 高 | CI/CDに保存されたAzure権限付きシークレット | デプロイ権限やサブスクリプション権限を持ちやすい |
| 高 | 期限が長いclient secret | 失効忘れや退職者所有のリスクがある |
| 中 | Key Vault内で所有者不明のシークレット | 用途不明のまま残りやすい |
| 中 | Power Platformの接続情報 | 業務部門主導で可視化が遅れやすい |
Microsoft Security Blogでは、credential eliminationとendpoint eliminationを組み合わせ、Private Linkやprivate endpoints、RDP/SSHのようなインバウンド管理ポートの削減、token levelでの最小権限化を挙げています。(マイクロソフト)
中期：managed identitiesとworkload identity federationへ置き換える
棚卸しが終わったら、置き換えやすい順に移行します。Azure内のサービス間通信はmanaged identities、Azure外のCI/CDやKubernetesはworkload identity federation、Power PlatformはPower Platform managed identityを優先します。
この段階で重要なのは、個別案件ごとに例外を許さないことです。「このチームだけclient secretでよい」「この古いアプリだけ接続文字列を残す」といった判断が積み重なると、後で全社移行が難しくなります。Microsoft Security Blogも、機会攻撃者は一貫性の欠如を突くため、標準化された安全な経路、いわゆるpaved pathsを作ることが重要だと説明しています。(マイクロソフト)
長期：Policy-as-Codeとプラットフォームエンジニアリングに組み込む
資格情報排除は、セキュリティチームのチェックリストだけでは定着しません。IaCテンプレート、CI/CDパイプライン、Azure Policy、アプリケーション標準、共通ライブラリに組み込む必要があります。
たとえば、次のようなルールを標準化します。
| 標準ルール | 実装例 |
|---|---|
| 新規Azure App Serviceはmanaged identityを有効化する | Terraform/Bicepの標準モジュールに組み込む |
| Key VaultへのアクセスはRBACとmanaged identityを基本にする | アプリごとの最小権限ロールを定義する |
| GitHub ActionsのAzure接続にclient secretを使わない | OIDC federationを標準テンプレート化する |
| 本番環境のRDP/SSH直接公開を禁止する | Bastion、JIT、閉域管理に寄せる |
| 例外は期限付きで承認する | 例外台帳と自動レビューを用意する |
MicrosoftのSecure Future Initiativeは、Secure by Design、Secure by Default、Secure Operationsの考え方に基づき、製品機能、セキュアデフォルト、標準、顧客向けガイダンスへセキュリティ原則を反映する取り組みとして説明されています。(Microsoft Learn)
将来：platform-provisioned identityを前提に設計を単純化する
Microsoft Security Blogでは、次の方向として、各サービスに自動作成され、セル単位で分離され、必要最小限の権限にスコープされた platform provisioned identities へ進むことも示されています。これは、個々のチームがIDを設計・作成・権限付与する負担を減らし、サービス単位で安全なIDを自動的に持つ方向を意味します。(マイクロソフト)
企業側は、今すぐこの仕組みを前提に全面設計するのではなく、将来移行しやすい形にしておくことが重要です。具体的には、アプリケーションコードに資格情報取得ロジックを直書きしない、Azure IdentityライブラリやDefaultAzureCredentialのような抽象化を使う、IDと権限を環境ごとに分離する、という設計が有効です。
運用方針：セキュリティチームだけでなくプロダクトチームのKPIにする
credential eliminationは、セキュリティ部門だけの活動にすると失敗しやすくなります。プロダクトチームにとっては、シークレット期限切れによる障害削減、監査対応の簡素化、リリース速度の向上にもつながるため、プロダクトKPIとして扱うべきです。
| 役割 | 持つべき責任 |
|---|---|
| IT意思決定者 | 資格情報排除を中期セキュリティ投資テーマに位置付ける |
| CISO / セキュリティアーキテクト | 例外基準、監査基準、最小権限設計を定義する |
| プラットフォームチーム | managed identityやOIDC federationを使う標準テンプレートを提供する |
| プロダクトオーナー | 自プロダクトのシークレット削減率、期限切れリスク、公開面を管理する |
| 開発チーム | 新規開発でclient secretを安易に作らない |
| 運用チーム | ログ、アラート、権限変更、期限付き例外を監視する |
特に、例外管理は重要です。現実には、古いアプリケーション、サードパーティ連携、未対応SDK、規制要件により、すべてを一度にmanaged identitiesへ移せるわけではありません。だからこそ、「例外を許すかどうか」ではなく、「誰が、何の理由で、いつまで例外を認めるか」を管理します。
失敗しやすいポイントと回避策
credential eliminationの取り組みで失敗しやすいのは、技術選定ではなく運用設計です。特に次の点は、計画段階で潰しておく必要があります。
| 失敗パターン | 起きる問題 | 回避策 |
|---|---|---|
| managed identityを有効化しただけで満足する | RBACが広すぎて侵害時の影響が大きい | リソース単位・操作単位で最小権限を設計する |
| user-assigned identityを共有しすぎる | どのサービスが何をしたか追跡しにくい | 用途、環境、データ感度ごとにIDを分ける |
| CI/CDのシークレットを後回しにする | デプロイ権限の漏えいが大事故につながる | GitHub ActionsやAzure PipelinesのOIDC化を優先する |
| Power Platformを対象外にする | 業務アプリ経由で資格情報が残る | Dataverseプラグイン、コネクタ、環境変数を棚卸しする |
| AIエージェントをユーザーIDで運用する | 監査、権限、ライフサイクルが破綻する | Agent IDの採用可否を評価し、暫定運用でも所有者と権限を明確化する |
| Conditional Accessで全部守れると誤解する | managed identitiesなど対象外の範囲を見落とす | 対象範囲を確認し、RBAC、ログ、ネットワーク制御で補完する |
まず90日で実行すべきアクション
最初の90日は、全社一斉移行よりも「見える化」と「標準化」に集中するのが現実的です。
| 期間 | 実行内容 | 成果物 |
|---|---|---|
| 1〜30日 | アプリ登録、サービスプリンシパル、client secret、証明書、CI/CDシークレットを棚卸しする | 資格情報リスク台帳 |
| 31〜60日 | managed identities / workload identity federationへ移せる対象を分類する | 移行優先順位リスト |
| 61〜90日 | 代表的なAzureアプリ、CI/CD、Power Platform接続でパイロット移行する | 標準テンプレート、例外基準、運用手順 |
この90日計画で重要なのは、完璧な移行ではありません。新規開発ではシークレットを作らない、既存シークレットは期限と所有者を明確にする、置き換え可能なものからmanaged identitiesやworkload identity federationへ移す、という流れを組織標準にすることです。
まとめ：Microsoft Entra IDの次の基準は「ログインさせない設計」
2026年4月20日のMicrosoft Securityの更新は、単なるベストプラクティス記事ではありません。Microsoft Entra ID、managed identities、enterprise security architecture の方向性を読むうえで、「資格情報を守る」から「資格情報を持たせない」へ移るサインです。
今後の運用方針は、次の5点に集約できます。
- ユーザー認証は、パスワード依存を下げ、フィッシング耐性の高い認証へ移行する
- Azure内のワークロードは、managed identitiesを第一候補にする
- CI/CD、Kubernetes、マルチクラウドは、workload identity federationで長期シークレットを減らす
- Power PlatformとAIエージェントも、例外扱いせずIDガバナンスに含める
- セキュリティを後付けチェックではなく、paved paths、Policy-as-Code、共通プラットフォームに組み込む
次に取るべき行動は明確です。まず、自社の「残っている資格情報」を棚卸ししてください。そのうえで、managed identitiesへ移せる接続、workload identity federationへ移せるCI/CD、Power Platform managed identityを使える業務アプリ、Agent IDを検討すべきAIエージェントを分類します。Microsoft Entra IDのロードマップを待つだけでなく、自社のアーキテクチャをcredential-free by defaultへ寄せることが、機会攻撃に強いエンタープライズセキュリティの出発点になります。
コメント