Microsoft Entra ID / managed identities / enterprise security architecture を運用する管理者が今回最初に確認すべきことは、「資格情報をより安全に保管する方法」ではなく、資格情報を残さない設計に移行できているかです。2026年4月20日の Microsoft Security Blog では、機会攻撃への防御として credential elimination、endpoint reduction、identity controls、platform engineering が強調されています。特に重要なのは、ワークロードがシークレットなしで認証できるなら、managed identities やフェデレーション ID パターンを使うべきだという考え方です。(マイクロソフト)
この記事では、IT admins、operations owners、deployment planners が発表直後に確認すべき設定差分、導入順序、社内周知項目をチェックリスト形式で整理します。結論から言うと、初動では「既存シークレットの棚卸し」「managed identities / federated identity credentials への移行候補選定」「パブリックエンドポイント縮小」「ワークロード ID と AI エージェント ID の可視化」「例外申請ルールの周知」を同時に進めるのが現実的です。
Microsoft Entra ID / managed identities / enterprise security architecture で今回見るべきポイント
Microsoft Security の発表は、単なる個別機能の紹介ではありません。管理者向けには、エンタープライズ全体のセキュリティアーキテクチャを「盗まれて使われる資格情報を前提に守る」から「そもそも盗まれる資格情報を減らす」方向へ寄せるメッセージとして読むべきです。
Microsoft は、攻撃者の多くはネットワークを“破る”のではなく、盗まれた資格情報で“ログインする”と説明しています。そのため、パスワード衛生だけに頼るのではなく、パスワード、クライアントシークレット、API キーのような再利用可能な資格情報を環境から減らすことが、機会攻撃に対する基礎防御になります。(マイクロソフト)
管理者が押さえるべき要点は次の4つです。
| 観点 | 管理者が確認すべきこと | 実務上の判断基準 |
|---|---|---|
| Credential elimination | アプリ、CI/CD、スクリプト、Power Platform、Azure リソースに埋め込まれたシークレットを減らす | 「保管・ローテーションする」ではなく「managed identities またはフェデレーションで不要にできるか」を先に判断する |
| Managed identities | Azure リソースが Microsoft Entra 認証で下流リソースにアクセスできるかを確認する | ストレージ、Key Vault、SQL、App Service、Functions など、対象サービスが Microsoft Entra 認証に対応しているかを見る |
| Endpoint reduction | 公開された管理ポート、公開データプレーン、広すぎる IP 許可リストを減らす | Private Endpoint、Private Link、Bastion、JIT アクセスなどでインターネット露出を下げる |
| Platform engineering | チームごとの例外構成を減らし、標準テンプレートと policy-as-code に寄せる | 「このチームだけ特別」を減らし、同じ認証・通信・ログ設計を横展開できるかを見る |
Microsoft の managed identities ドキュメントでも、開発者がシークレット、資格情報、証明書、キーを手動管理することはセキュリティ問題や障害の原因になり得ると説明されています。managed identities を使うと、アプリケーションは資格情報を管理せずに Microsoft Entra トークンを取得できます。(Microsoft Learn)
初動で確認する影響範囲チェックリスト
発表直後にいきなり全システムを移行しようとすると、認証失敗や権限不足で業務影響が出やすくなります。まずは、シークレットが多く、攻撃者に再利用されやすい場所から棚卸しします。
| 確認対象 | 見る場所の例 | 危険度が高い状態 | 初動アクション |
|---|---|---|---|
| アプリ登録のクライアントシークレット | Microsoft Entra ID の App registrations、Enterprise applications | 長期間有効、所有者不明、用途不明、特権 API 権限あり | 所有者を特定し、managed identity または federated identity credential へ移行候補化する |
| Azure リソースの接続文字列 | App Service、Functions、Container Apps、VM、Automation、Logic Apps など | App settings や環境変数にキー、パスワード、接続文字列が保存されている | Microsoft Entra 認証対応の SDK / コネクタに置き換える |
| CI/CD のサービス接続 | GitHub Actions、Azure DevOps、外部 CI/CD | クライアントシークレットや長期トークンで Azure に接続している | OIDC / workload identity federation の利用可否を確認する |
| リポジトリとスクリプト | Git、IaC、運用スクリプト、Runbook | API キー、SAS、接続文字列、証明書が平文または暗号化不十分な形で残っている | 露出済みの可能性があるものはローテーションし、再発防止を CI チェックに組み込む |
| パブリックエンドポイント | Storage、SQL、App Service、管理ポート、管理 API | Private Endpoint はあるが public access も有効、RDP/SSH が直接公開 | Private Endpoint と public access 無効化をセットで確認する |
| ワークロード ID | Service principals、managed identities、agent identities | 所有者・スポンサー・用途・権限範囲が不明 | 所有者、利用システム、権限、最終サインインを台帳化する |
この棚卸しでは、「有効期限が近いシークレット」だけを見ないことが重要です。期限切れによる障害は見つけやすい一方、長期間有効なシークレットや所有者不明のシークレットは、漏えいしても気づきにくいリスクになります。
導入チェックリスト：credential elimination を設計として進める
既存シークレットを分類する
まず、すべてのシークレットを同じ扱いにしないことが重要です。移行しやすいもの、業務影響が大きいもの、すぐ削除できないものを分けます。
- [ ] Microsoft Entra ID のアプリ登録で、クライアントシークレットと証明書の一覧を取得する
- [ ] 各資格情報に「所有者」「利用システム」「利用環境」「権限」「有効期限」「最終利用確認日」を付ける
- [ ] 本番環境、インターネット公開サービス、高権限 API 権限を持つものを優先度高にする
- [ ] App Service、Functions、Container Apps、VM、Automation、Data Factory、Logic Apps などの構成値に資格情報がないか確認する
- [ ] CI/CD、Runbook、IaC、Git リポジトリ、社内 Wiki、運用手順書に古いキーが残っていないか確認する
- [ ] すぐ廃止できないシークレットには、例外期限と移行予定日を設定する
「すべてを今すぐ managed identities にする」という進め方は現実的ではありません。最初のゴールは、資格情報の総量、所有者不明の資格情報、長期有効な資格情報を可視化することです。
managed identities に置き換える対象を決める
managed identities は、Azure リソースに Microsoft Entra ID の ID を付与し、コードや構成ファイルに資格情報を持たせずに下流リソースへアクセスさせる仕組みです。Microsoft Learn では、managed identities は Microsoft Entra 認証をサポートする任意のリソースに対して利用でき、開発者が資格情報を管理する必要をなくすと説明されています。(Microsoft Learn)
| 利用シーン | 推奨パターン | 判断ポイント |
|---|---|---|
| Azure リソースから Key Vault、Storage、SQL などへアクセス | managed identity + RBAC または対象サービス側の権限 | 下流サービスが Microsoft Entra 認証に対応しているかを確認する |
| Azure 外の CI/CD から Azure へデプロイ | workload identity federation | 長期シークレットを保存せず、外部 IdP のトークンを Microsoft Entra のトークンに交換できるかを確認する |
| 複数リソースで同じ業務 ID を使いたい | user-assigned managed identity | ライフサイクルをリソースから独立させたい場合に向く |
| 単一リソースのライフサイクルに合わせたい | system-assigned managed identity | リソース削除時に ID も削除されるため、単純な構成に向く |
| まだ Microsoft Entra 認証に移行できない接続先 | Key Vault で一時保管し、期限付き例外にする | 例外を恒久化せず、移行バックログに入れる |
system-assigned managed identity はリソースに直接結び付き、親リソースが削除されると ID も削除されます。一方、user-assigned managed identity は独立した Azure リソースとして作成され、複数の Azure リソースに割り当てられます。Microsoft の開発者向けガイドでは、多くのシナリオで user-assigned managed identity の利用が推奨されています。(Microsoft Learn)
federated identity credentials の注意点を確認する
workload identity federation は、外部 IdP と Microsoft Entra ID のアプリケーションまたは user-assigned managed identity の間に信頼関係を作り、外部ワークロードがシークレットを管理せずに Microsoft Entra 保護リソースへアクセスできるようにする仕組みです。(Microsoft Learn)
特に注意したいのは、issuer、subject、audience の値が大文字小文字を区別して一致する必要がある点です。CI/CD のブランチ名、Kubernetes の service account 名、外部 IdP のクレーム設計が少しでもずれると、認証失敗の原因になります。(Microsoft Learn)
| 注意点 | 実務上の対策 |
|---|---|
| issuer / subject / audience の不一致 | 本番適用前に検証環境でトークンクレームを確認する |
| user-assigned managed identity には設定できるが、system-assigned managed identity には同じ形で設定できない | 外部 IdP 連携が必要な場合は user-assigned managed identity を前提に設計する |
| federated identity credential の数に上限がある | 環境、ブランチ、名前空間ごとに無制限に増やさず、設計段階で分割方針を決める |
| シークレット削除を急ぎすぎる | 旧方式と新方式の並行稼働期間を短く設け、ログで成功を確認してから削除する |
Microsoft Learn では、user-assigned managed identity に federated identity credential を構成する手順で、system-assigned managed identity への構成はサポートされないこと、またアプリケーションまたは user-assigned managed identity に追加できる federated identity credentials は最大20個であることが説明されています。(Microsoft Learn)
設定差分チェックリスト：Microsoft Entra ID と Azure 側で見る場所
アプリ登録とエンタープライズアプリケーション
Microsoft Entra ID の App registrations と Enterprise applications では、次の項目を確認します。
- [ ] 所有者が空欄のアプリがないか
- [ ] 用途不明のクライアントシークレットが残っていないか
- [ ] 有効期限が長すぎるシークレットがないか
- [ ] Microsoft Graph や Azure 管理 API への権限が過剰でないか
- [ ] 管理者同意済みの API 権限が現在も必要か
- [ ] 利用されていないサービスプリンシパルを無効化または削除できるか
- [ ] managed identity に置き換えた後、古いシークレットを削除したか
ここでのポイントは、アプリ登録を「開発チームの所有物」として放置しないことです。アプリ登録は、実質的には企業の認証境界に入るため、運用所有者、技術所有者、権限範囲、削除基準をセットで管理します。
managed identities の可視化
managed identities は便利ですが、作成後に権限だけが増え続けると、資格情報がないにもかかわらず影響範囲の大きい ID になります。
- [ ] Microsoft Entra 管理センターで managed identities のサービスプリンシパルを確認する
- [ ] Azure RBAC の割り当てが最小権限になっているか確認する
- [ ] 同じ user-assigned managed identity を無関係な複数システムで共有していないか確認する
- [ ] 本番、検証、開発で同じ ID を使い回していないか確認する
- [ ] サインインログと Azure Activity logs を監視対象に入れる
Microsoft Learn では、managed identity のサービスプリンシパルは Enterprise applications で確認でき、フィルターで managed identities を表示できると説明されています。(Microsoft Learn)
Conditional Access for workload identities
Microsoft Entra Workload ID では、組織が所有するサービスプリンシパルに Conditional Access ポリシーを適用し、場所やリスクに基づく制御を行えます。Microsoft Learn では、Service principal sign-ins のサインインログで Conditional Access の評価結果を確認でき、report-only mode で影響を確認できると説明されています。(Microsoft Learn)
ただし、ここで重要な落とし穴があります。Microsoft Entra ID Protection のワークロード ID リスクに基づく制御は、単一テナントのサービスプリンシパルに適用できる一方、managed identities、非 Microsoft SaaS、マルチテナントアプリは対象外とされています。managed identities については、Conditional Access だけに頼らず、RBAC、ネットワーク制御、ログ監視、リソース境界で守る必要があります。(Microsoft Learn)
導入時は、いきなりブロックポリシーを本番適用せず、次の順序で進めます。
| 手順 | 実施内容 | 失敗を防ぐポイント |
|---|---|---|
| 1 | 対象サービスプリンシパルを限定する | すべてのワークロード ID を一括対象にしない |
| 2 | report-only mode で影響を見る | Service principal sign-ins で失敗候補を確認する |
| 3 | 例外対象を明文化する | 例外には期限、所有者、理由を付ける |
| 4 | 低リスク環境からブロック適用する | 開発、検証、本番の順に展開する |
| 5 | 監視ルールを SIEM / XDR に接続する | ブロック後の業務影響と攻撃兆候を同じ画面で見る |
パブリックエンドポイントの縮小
Microsoft Security の発表では、credential elimination と endpoint elimination は自然に組み合わせるべきものとして説明されています。managed identities によってサービス間認証を ID ベースにし、同時に Private Endpoint / Private Link などで公開面を縮小すると、攻撃者が探索できる入口を減らせます。(マイクロソフト)
ここでの注意点は、Private Endpoint を作っただけで public access が自動的に無効になるとは限らないことです。たとえば Azure SQL Database では、Private Endpoint を追加しても public routing は既定でブロックされず、Deny public network access を選択する必要があると説明されています。App Service でも、Private Endpoint と public access は共存できるため、分離を確実にするには public network access の無効化を確認する必要があります。(Microsoft Learn)
| 対象 | 確認すべき設定 | よくあるミス |
|---|---|---|
| Azure SQL | Private Endpoint、Deny public network access | Private Endpoint 作成後も public access が残る |
| Storage account | Public network access、Private Endpoint、許可ネットワーク | 一時的な検証用 IP 許可が残る |
| App Service | Private Endpoint、public network access、access restrictions | Private Endpoint を作っただけで公開停止したと誤解する |
| VM / 管理アクセス | RDP、SSH、Bastion、JIT | 管理ポートを広い IP 範囲に公開したままにする |
| Key Vault | Public access、Private Endpoint、RBAC / access policy | Key Vault にシークレットを集めたが、ネットワーク境界が弱い |
AI エージェントを使う組織は Microsoft Entra Agent ID も棚卸し対象にする
Copilot Studio や社内 AI エージェントを使う組織では、人間ユーザーと通常のアプリだけでなく、agent identities も管理対象に含める必要があります。Microsoft Entra Agent ID のドキュメントでは、agent identity は Microsoft Entra ID の特別なサービスプリンシパルであり、それ自体に資格情報を持たず、agent identity blueprint を通じてトークンを取得すると説明されています。なお、Microsoft Entra Agent ID はプレビュー情報として提供されています。(Microsoft Learn)
管理者が見るべきポイントは次の通りです。
- [ ] AI エージェントが通常のアプリ登録や共有アカウントとして作られていないか
- [ ] agent identity blueprint が定義されているか
- [ ] 各 agent identity に sponsor と owner が設定されているか
- [ ] 付与された Microsoft Graph 権限や業務システム権限が最小限か
- [ ] 不要になったエージェントを無効化・削除できる運用があるか
- [ ] エージェントのアクセスレビューを定期的に行うか
Microsoft Learn では、スポンサーはエージェントのビジネス上の説明責任を持ち、ライフサイクルやアクセスの判断に関わる存在として説明されています。また、agent identity または agent blueprint の作成時には sponsor が必要です。(Microsoft Learn)
AI エージェントを ordinary app registration として個別に増やすと、後から「どの業務のためのエージェントか」「誰が止めてよいのか」「どの権限が過剰なのか」が追えなくなります。Agent ID を使う場合は、blueprint 単位で Conditional Access、API 権限、ガバナンス制御を適用し、将来のエージェントにも同じ統制を継承させる設計が推奨されます。(Microsoft Learn)
展開順序チェックリスト：止めずに移行するための進め方
credential elimination は、セキュリティ部門だけで完結しません。アプリ所有者、インフラ担当、開発チーム、運用監視、ヘルプデスク、業務部門が関わります。展開順序を誤ると、認証エラーやリリース停止が発生します。
| フェーズ | 期間の目安 | 実施内容 | 完了条件 |
|---|---|---|---|
| 初動 | 1〜3営業日 | 新規シークレット作成の原則禁止、例外申請ルールの周知、棚卸し対象の確定 | 新規案件で「なぜ managed identity ではないのか」を確認するルールがある |
| 棚卸し | 1〜2週間 | アプリ登録、サービスプリンシパル、managed identities、CI/CD、構成値、公開エンドポイントを一覧化 | 所有者不明・高権限・長期有効の資格情報が抽出されている |
| パイロット | 2〜6週間 | 影響範囲の小さい本番ワークロードまたは検証環境で managed identity / federation に移行 | ログで成功を確認し、旧シークレットを削除できる |
| 横展開 | 6〜12週間 | IaC テンプレート、Azure Policy、CI/CD チェック、標準 SDK 利用を組み込む | 新規システムが標準で credential-free パターンになる |
| 定着 | 継続 | 例外レビュー、アクセスレビュー、ログ監視、監査証跡の整備 | 例外が期限付きで管理され、古いパターンが増えない |
展開では、「最も危険なもの」だけでなく「最も移行しやすいもの」も選びます。最初の成功例を作ると、開発チームへの説明がしやすくなり、運用手順も整います。
周知チェックリスト：開発者・運用・業務部門に伝える内容
開発者向けに伝えること
開発者には、「シークレットを安全に置く場所」ではなく、「シークレットを不要にする選択肢」を先に伝える必要があります。
- 新規開発では、Azure リソースからのアクセスに managed identities を優先する
- 外部 CI/CD からの接続では、可能な限り workload identity federation を使う
- App settings、環境変数、リポジトリ、Wiki、手順書に接続文字列や API キーを残さない
- SDK は Microsoft Entra 認証に対応した方式を選ぶ
- 例外的にシークレットを使う場合は、有効期限、所有者、ローテーション、削除予定日を必須にする
- user-assigned managed identity を共有する場合は、用途と境界を明確にする
社内メッセージの例は次の通りです。
今後の新規開発・構成変更では、パスワード、クライアントシークレット、API キーをアプリケーション設定やコードに保存する方式を原則として避けます。Azure リソース間の認証は managed identities、外部 CI/CD からの接続は workload identity federation を優先してください。例外が必要な場合は、所有者、理由、有効期限、移行予定日を添えて申請してください。
運用チーム向けに伝えること
運用チームには、障害対応とセキュリティ対応の両方で見るべきログを明確にします。
- 認証失敗時は、シークレット期限切れだけでなく、RBAC 不足、FIC クレーム不一致、Conditional Access ブロックを確認する
- Service principal sign-ins と Azure Activity logs を監視対象に入れる
- managed identity の権限変更を変更管理の対象にする
- Private Endpoint 作成後に public access が残っていないか確認する
- 旧シークレット削除前に、移行後の認証成功ログを確認する
- 例外シークレットの期限切れを障害予兆として検知する
特に、managed identity への移行後は「シークレット期限切れによる障害」は減りますが、「RBAC が足りない」「対象サービスが Microsoft Entra 認証に対応していない」「ネットワーク経路が Private Endpoint に切り替わっていない」といった別の失敗が増えます。移行手順には、認証、権限、ネットワーク、ログの4点を必ず入れます。
業務部門・システム所有者向けに伝えること
業務部門には、技術用語よりも責任範囲を明確に伝えます。
- システムごとに業務所有者と技術所有者を決める
- 不要になったアプリ、ワークロード、AI エージェントを放置しない
- 例外的に資格情報を残す場合は、リスクを承認し、期限を決める
- AI エージェントには sponsor を設定し、アクセス権と目的を定期的に見直す
- セキュリティ部門からの権限削減依頼に対応する窓口を決める
シークレットの削除や権限削減は、IT 部門だけで判断できない場合があります。業務影響を判断できるスポンサーがいないと、不要なアクセスが残り続けます。
失敗しやすいポイントと回避策
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| managed identity に置き換えたが、過剰な RBAC を付与した | シークレットは消えても、侵害時の影響範囲が大きい | 読み取り、書き込み、管理権限を分け、最小権限で割り当てる |
| user-assigned managed identity を多くのシステムで共有した | 1つの ID の停止や権限変更が複数システムに影響する | 業務境界、環境、本番・検証単位で分ける |
| Private Endpoint を作っただけで安心した | public access が残り、外部から到達可能なままになる | public network access / Deny public network access を明示的に確認する |
| FIC の subject 設計を場当たり的に増やした | 上限や運用複雑性に引っかかる | ブランチ、環境、namespace の命名規則を先に決める |
| Conditional Access を本番に一括適用した | 自動処理や連携処理が停止する | report-only mode と限定対象で検証する |
| シークレット削除を先に行った | 切り戻し不能な障害になる | 新方式の成功ログを確認してから旧資格情報を削除する |
| AI エージェントを通常アプリとして登録した | sponsor、owner、ライフサイクル管理が曖昧になる | Agent ID の利用可否を確認し、preview 機能は導入判断を明文化する |
| 例外申請に期限がない | 旧方式が恒久化する | 例外には期限、所有者、移行予定日を必須にする |
今日から使える最終チェックリスト
最後に、管理者が今日から実行できる項目を整理します。
- [ ] 新規シークレット作成を原則禁止し、例外申請ルールを出す
- [ ] Microsoft Entra ID のアプリ登録とサービスプリンシパルを棚卸しする
- [ ] 本番・高権限・インターネット公開ワークロードを優先順位の上位に置く
- [ ] managed identities に置き換えられる Azure リソースを選定する
- [ ] 外部 CI/CD は workload identity federation の利用可否を確認する
- [ ] Service principal sign-ins と Conditional Access の report-only 結果を見る
- [ ] Private Endpoint 作成済みリソースで public access が残っていないか確認する
- [ ] managed identities の RBAC が最小権限か確認する
- [ ] AI エージェントを利用している場合は Agent ID、sponsor、owner を確認する
- [ ] 例外シークレットには期限、所有者、削除予定日を設定する
- [ ] 社内向けに「シークレットを安全に保存する」ではなく「シークレットを作らない」方針を周知する
- [ ] IaC、CI/CD、標準テンプレートに credential-free パターンを組み込む
Microsoft Security の今回のメッセージは、攻撃を完全に防ぐ魔法の設定ではありません。しかし、Microsoft Entra ID、managed identities、workload identity federation、Private Endpoint、Conditional Access、Agent ID を組み合わせることで、攻撃者が再利用できる資格情報と到達できる入口を同時に減らせます。
管理者が次に取るべき行動は明確です。まずは既存シークレットを棚卸しし、所有者不明・高権限・長期有効・公開サービス連携のものから、managed identities またはフェデレーション ID への移行計画に入れてください。credential elimination を一度きりの改善ではなく、enterprise security architecture の標準設計にすることが、機会攻撃に強い環境づくりの出発点です。
コメント