Microsoft Securityが2026年4月20日に示した要点は明確です。Microsoft Entra ID、managed identities、enterprise security architectureを使う組織は、「資格情報を厳重に保管する」だけでは不十分であり、可能な限り資格情報そのものをなくす設計へ移行すべきです。
特にCISO、identity architect、platform security leadが最初に確認すべきなのは、パスワード、クライアントシークレット、APIキー、長寿命証明書を使っているワークロードの棚卸しです。次に、Azure上のワークロードはmanaged identitiesへ、GitHub ActionsやKubernetesなど外部実行基盤はworkload identity federationへ、Power PlatformやAIエージェント領域はEntra IDベースの非人間ID管理へ移行できるかを判断します。
今回の更新は、単一機能のリリース情報というより、Microsoft Securityが「機会主義的な攻撃に強い設計」の基準を整理したものです。攻撃者は必ずしも高度な侵入をするわけではなく、盗まれた資格情報で正規ログインし、横展開の足場を探します。だからこそ、最初の防御線は「盗まれて困る資格情報を減らすこと」になります。(Microsoft)
Microsoft Securityが強調した変更点は「資格情報を守る」から「資格情報を消す」への転換
Microsoft Securityの記事では、攻撃機会を減らす実践として、credential elimination、endpoint reduction、identity controls、platform engineeringが並べて説明されています。中でも重要なのは、ワークロードがシークレットなしで認証できるなら、そう設計すべきだという考え方です。Microsoftは、managed identitiesやフェデレーションされたIDパターンを使い、パスワード、クライアントシークレット、APIキーのような再利用可能な資格情報を減らす方針を示しています。(Microsoft)
実務上の読み替えは次のとおりです。
| 見直す対象 | 従来のよくある実装 | 今後優先したい実装 |
|---|---|---|
| Azure上のアプリ、VM、Functions、App Service | 環境変数やKey Vaultに保存したクライアントシークレットで接続 | managed identitiesでMicrosoft Entra認証を使う |
| CI/CD、GitHub Actions、外部Kubernetes | サービスプリンシパルのシークレットをパイプライン変数に保存 | workload identity federationで短命トークンを交換 |
| Dataverseプラグイン、Power Platform連携 | アプリ登録とシークレットを個別に管理 | Power Platform managed identityの利用可否を確認 |
| AIエージェント、Copilot Studio | アプリ登録や所有者不明の非人間IDが増える | Microsoft Entra Agent IDで可視化、監査、ガバナンスを検討 |
| 管理用アクセス | RDP、SSH、IP許可リストに依存 | Bastion、JIT、Private Link、Private Endpointを組み合わせる |
| 組織全体の設計 | チームごとに例外的な構成を許可 | paved pathsとpolicy-as-codeで標準化する |
ここで重要なのは、Key Vaultにシークレットを保存するだけでは「資格情報排除」ではないという点です。Key Vaultはシークレット管理には有効ですが、シークレットが存在する限り、漏えい、期限切れ、過大権限、所有者不明という問題は残ります。まず目指すべきは、シークレットを安全に置くことではなく、シークレットを使わない接続方式に変えることです。
Microsoft Entra ID利用者が最初に確認すべき影響範囲
今回のメッセージは、Microsoft Entra IDをユーザー認証の基盤として使っている組織だけでなく、アプリケーション、サービス、CI/CD、AIエージェントなどの非人間IDを大量に扱う組織に強く関係します。
サービスプリンシパルとアプリ登録に残っているシークレット
最初に見るべき場所は、Microsoft Entra IDのアプリ登録とサービスプリンシパルです。特に、以下のようなものは優先度が高くなります。
- 有効期限が長い、または期限管理が曖昧なクライアントシークレット
- 所有者が退職者、共有アカウント、古いチーム名になっているアプリ登録
- Azureサブスクリプション、Microsoft Graph、Key Vault、Storage、SQL Databaseに広い権限を持つサービスプリンシパル
- CI/CDパイプライン、IaC、コンテナ環境変数、アプリ設定に埋め込まれたシークレット
- 障害対応時に「誰が消してよいか分からない」資格情報
Microsoft Entraのセキュリティベストプラクティスでも、サービスプリンシパルが必要な場面では証明書資格情報やworkload identities向け条件付きアクセスを使い、クライアントシークレットは組織ポリシー上の例外として扱う考え方が示されています。(Microsoft Learn)
managed identitiesへ移行できるAzureワークロード
Azureリソース上で動くワークロードは、まずmanaged identitiesに移行できるかを確認します。Microsoft Learnでは、managed identitiesはアクセスキーやパスワードなどのシークレットを置き換え、資格情報を開発者が管理しなくてよい仕組みとして説明されています。資格情報は利用者からアクセスできず、Microsoft Entra認証をサポートするリソースへの認証に使えます。(Microsoft Learn)
判断基準はシンプルです。
| 利用パターン | 選びやすいmanaged identity | 判断基準 |
|---|---|---|
| 1つのApp ServiceやVMだけが接続する | システム割り当てmanaged identity | リソース削除時にIDも削除されてよい |
| 複数のApp Service、VM、Functionsで同じ権限を使う | ユーザー割り当てmanaged identity | IDのライフサイクルをリソースと分けたい |
| プラットフォーム標準として複数チームに配布する | ユーザー割り当てmanaged identity | 権限、監査、再利用を一元管理したい |
| 一時的な検証環境 | システム割り当てmanaged identity | 構成を簡素化し、削除漏れを減らしたい |
ただし、managed identityを使えば自動的に安全になるわけではありません。接続先のRBAC、スコープ、ログ、ネットワーク制御を合わせて設計しないと、単に「パスワードのない過大権限ID」を作るだけになります。
workload identity federationは外部ワークロードのシークレット削減に効く
GitHub Actions、Kubernetes、オンプレミス、他クラウド上のワークロードは、Azureのmanaged identityだけでは完結しない場合があります。その場合に重要になるのがworkload identity federationです。
Microsoft Learnでは、workload identity federationは、GitHub Actions、Kubernetes、Azure外のコンピュート環境などで、シークレットを管理せずにMicrosoft Entraで保護されたリソースへアクセスするための仕組みとして説明されています。外部IDプロバイダーのトークンをMicrosoft identity platformで検証し、アクセス先に必要なトークンへ交換します。(Microsoft Learn)
実務での代表例は次のとおりです。
| シナリオ | 以前の構成 | 見直し後の構成 |
|---|---|---|
| GitHub ActionsからAzureへデプロイ | AzureサービスプリンシパルのシークレットをGitHub Secretsに保存 | GitHub OIDCとMicrosoft Entraのフェデレーション資格情報を使う |
| AKS以外のKubernetesからAzure Storageへ接続 | コンテナ環境変数にクライアントシークレットを注入 | Kubernetes側のIDトークンをMicrosoft Entraで信頼する |
| オンプレミスの自動化ジョブからMicrosoft Graphを呼ぶ | 長期シークレットや証明書をジョブサーバーに配置 | 外部IDプロバイダーとの信頼関係で短命トークンを使う |
| Azure VM上のアプリが別のアプリ登録として動く | アプリ登録のシークレットをVMに保存 | ユーザー割り当てmanaged identityをフェデレーション資格情報として使う |
移行時に失敗しやすいのは、発行者、サブジェクト、audienceの不一致です。フェデレーション資格情報は、外部IDプロバイダーが発行するトークンの値とMicrosoft Entra側の設定が一致して初めて機能します。環境名、ブランチ名、リポジトリ名、Kubernetes service account名を後から変えると、認証に失敗することがあります。構成変更を前提に、命名規則と変更管理を先に決めておくべきです。
Power Platform managed identityはDataverse連携の確認対象
Power Platformを業務アプリ基盤として使っている組織では、DataverseプラグインやAzureリソース連携も確認対象です。Power Platform managed identityは、Dataverseプラグインからmanaged identityをサポートするAzureリソースへ、資格情報を管理せずに接続するための仕組みとして説明されています。Microsoft Learnでは、フェデレーションID資格情報をベースにし、ユーザー割り当てmanaged identityまたはアプリ登録をMicrosoft Entraテナント内に作成する構成が示されています。(Microsoft Learn)
例えば、DataverseプラグインからAzure Key Vault、Azure Storage、Azure Functionsなどへ接続している場合、プラグイン内や構成値にシークレットを持たせるのではなく、Power Platform managed identityで置き換えられるかを確認します。
この領域で注意したいのは、Power Platformの開発者とEntra ID管理者が別組織になりやすいことです。業務部門が作ったプラグインに、誰が所有するIDを付与し、誰がアクセス権を承認し、誰が棚卸しするのかを決めないまま導入すると、シークレットは減ってもIDガバナンスが弱くなります。
AIエージェント時代は「非人間ID」の棚卸しがさらに重要になる
Copilot StudioやAIエージェントの導入が進むと、人間ではないIDが急速に増えます。Microsoft Entra Agent IDは、AIエージェント向けにMicrosoft EntraのID管理、アクセス保護、ガバナンス、コンプライアンスを拡張するためのフレームワークとして説明されています。ただし、Microsoft Entra Agent IDは現時点でプレビュー扱いであり、正式リリース前に仕様が変わる可能性がある点には注意が必要です。(Microsoft Learn)
Copilot Studioでは、環境で機能を有効にすると、新しいエージェントごとにMicrosoft Entra agent identityが自動作成され、Microsoft Entra admin centerで確認・管理できるとされています。Microsoft Learnでは、この機能もプレビューであり、プレビュー機能は本番利用を目的としたものではなく、制限がある可能性があると明記されています。(Microsoft Learn)
そのため、現時点での初動は「すぐ全面導入する」ではなく、次の確認を進めることです。
| 確認項目 | 実務上の観点 |
|---|---|
| どの環境でAIエージェントが作成されているか | 本番、検証、個人開発環境を分けて棚卸しする |
| エージェントの所有者・スポンサーが分かるか | 退職、異動、部門変更時に放置されないようにする |
| エージェントが接続できるリソースは何か | SharePoint、Dataverse、Graph、外部APIへの権限を確認する |
| サインインログや監査ログで追跡できるか | インシデント時に「どのエージェントが何をしたか」を追えるようにする |
| プレビュー機能を本番統制に組み込んでいないか | 正式機能とプレビュー機能の境界を明確にする |
AIエージェントは便利な自動化手段ですが、権限を持った非人間IDでもあります。ユーザーIDと同じ発想で管理すると、ライフサイクル、所有者、アクセスレビューのタイミングが合わなくなります。エージェント専用のID管理プロセスを設けることが、今後のenterprise security architectureでは重要になります。
条件付きアクセスだけではmanaged identitiesを守り切れない
Microsoft Entra IDを使う組織では、条件付きアクセスを中心にゼロトラストを設計していることが多いでしょう。ただし、workload identityとmanaged identityは同じ扱いではありません。
Microsoft Learnでは、条件付きアクセスはテナント内に登録された単一テナントのサービスプリンシパルに適用できる一方、非Microsoft SaaSやマルチテナントアプリは対象外であり、managed identitiesもポリシー対象外と説明されています。(Microsoft Learn)
つまり、managed identityを使う場合は、条件付きアクセスを前提にしすぎず、次の制御を組み合わせる必要があります。
| 制御 | 実務での使い方 |
|---|---|
| Azure RBAC | 必要なリソース、必要な操作、必要なスコープだけに絞る |
| リソース側のアクセス制御 | Key Vault、Storage、SQLなど接続先ごとに許可を限定する |
| ネットワーク制御 | Private Endpoint、Private Link、Public network accessの制御を使う |
| ログ監視 | Microsoft Entraサインインログ、Azure Activity logs、接続先サービスの監査ログを見る |
| IDのライフサイクル管理 | 使われていないmanaged identity、所有者不明のID、過大権限を定期的に削除・縮小する |
特に避けたいのは、「managed identityだから安全」と考えて広いContributor権限を付与することです。資格情報が盗まれにくくなっても、トークンが悪用された場合の影響範囲が広ければ、被害は大きくなります。
endpoint reductionも同時に進めるべき理由
資格情報排除と同じくらい重要なのが、攻撃者が到達できる入口を減らすことです。Microsoft Securityの記事では、managed identitiesでサービス間認証を行いながら、Private EndpointやPrivate Linkでデータプレーンを保護し、RDPやSSHのような管理ポートはJIT、Bastion、serial consoleなどの仲介型アクセスに寄せる考え方が示されています。(Microsoft)
Defender for CloudのJust-in-time machine accessは、RDPやSSHなど開いた管理ポートを狙う攻撃者からリソースを守るため、VMへの受信トラフィックをロックダウンし、必要なときだけアクセスを許可する機能として説明されています。(Microsoft Learn)
実務では、次の順で見直すと進めやすくなります。
| 優先度 | 見直し対象 | 初動 |
|---|---|---|
| 高 | インターネット公開されたRDP、SSH、管理API | 原則閉じる。Bastion、JIT、VPN、Privileged Access Workstationを検討 |
| 高 | Storage、SQL、Key Vaultなどの公開エンドポイント | Private Endpoint化できるか確認 |
| 中 | IP許可リストだけで守るサービス間通信 | Microsoft Entra IDベースの認証と最小権限へ移行 |
| 中 | 古いジャンプサーバー | アクセスログ、MFA、JIT、不要アカウントの削除を確認 |
| 低 | 検証環境の一時公開 | 自動削除、期限付き例外、タグ付けを義務化 |
資格情報をなくしても、公開面が広ければスキャン、ブルートフォース、設定ミスの標的になります。逆に、公開面を減らしても、内部に再利用可能なシークレットが残っていれば横展開されます。両方を同時に進めることが重要です。
enterprise security architectureではpaved pathsを作る
今回の記事のもう一つの重要点は、platform engineeringです。Microsoft Securityは、機会主義的な攻撃者は一貫性のない構成を好むとし、例外やチームごとの独自構成が増えるほど、設定ミスや対応遅延が増えると説明しています。対策として、secure-by-defaultなランタイム、ライブラリ、パイプライン、policy-as-code、例外を抑える経営層の支援を挙げています。(Microsoft)
これは、CISOやセキュリティ部門が「各チームにお願いする」だけでは限界があるという意味です。実際には、開発者が自然に安全な構成を選べる標準ルート、つまりpaved pathsを作る必要があります。
paved pathsに含めたい標準
| 領域 | 標準化する内容 |
|---|---|
| アプリ実行基盤 | App Service、Functions、AKS、Container Appsなどの推奨テンプレート |
| ID | managed identityの種類、命名規則、所有者、RBAC付与ルール |
| シークレット例外 | クライアントシークレットを許可する条件、期限、承認者、更新手順 |
| CI/CD | OIDC、workload identity federation、署名、環境分離 |
| ネットワーク | Private Endpoint、Public network access、管理ポート禁止ルール |
| ログ | サインインログ、Activity logs、リソースログ、SIEM連携 |
| IaC | Terraform、Bicep、Azure Policy、GitHub Actions、Azure DevOpsのチェック |
paved pathsの目的は、開発チームの自由を奪うことではありません。安全な選択肢を最も簡単にし、危険な例外を手間のかかる承認制にすることです。
役割別に見る初動チェックリスト
CISOが確認すべきこと
CISOは、技術移行の細部よりも「組織標準」と「例外管理」を先に決めるべきです。
| 確認項目 | 判断基準 |
|---|---|
| 長期シークレットを新規作成できる状態か | 原則禁止または期限付き例外にする |
| 例外承認者が明確か | セキュリティ、ID、プラットフォーム、業務責任者の責任分界を決める |
| KPIがあるか | シークレット数、期限切れ件数、managed identity移行率、公開管理ポート数を見る |
| 買収・海外拠点・委託先も対象か | グローバル組織ではテナント、サブスクリプション、運用委託範囲を含める |
| AIエージェントのID管理方針があるか | 所有者、監査、権限、削除基準を定義する |
identity architectが確認すべきこと
identity architectは、サービスプリンシパル、managed identity、workload identity federation、agent identityを分けて設計します。
| 確認項目 | 判断基準 |
|---|---|
| managed identityに移行できるワークロードを分類したか | Azure上で完結するものから優先 |
| 外部ワークロードにOIDCを使えるか | GitHub Actions、Kubernetes、他クラウドのIdPを確認 |
| 条件付きアクセスの対象外を理解しているか | managed identitiesは条件付きアクセスの対象外である点を設計に反映 |
| RBACスコープが広すぎないか | サブスクリプション単位ではなく、リソースグループや個別リソース単位を検討 |
| ログで追跡できるか | サインインログ、Activity logs、監査ログをSIEMへ集約する |
platform security leadが確認すべきこと
platform security leadは、個別移行よりも再利用可能なテンプレートを作ることが重要です。
| 確認項目 | 判断基準 |
|---|---|
| 新規サービス作成時にmanaged identityが標準で有効か | テンプレート、IaC、ポータル手順に組み込む |
| シークレットを含むデプロイをブロックできるか | secret scanning、policy-as-code、CI/CDチェックを使う |
| Private Endpoint構成がテンプレート化されているか | 接続先ごとに毎回設計しない |
| 開発者が迷わないドキュメントがあるか | 「なぜ」より「この手順で作る」を重視 |
| 例外が見える化されているか | 期限、所有者、リスク、代替計画を台帳化する |
30日以内に始める実務アクション
最初の30日で全移行を終える必要はありません。むしろ、いきなり全面移行を始めると、権限不足や認証失敗で業務影響が出ます。最初は、棚卸し、優先順位付け、標準化の入口を作ることに集中します。
| 期間 | 実施内容 | 成果物 |
|---|---|---|
| 1週目 | アプリ登録、サービスプリンシパル、Key Vault、CI/CD変数を棚卸し | 長期シークレット一覧、所有者不明ID一覧 |
| 2週目 | 高リスク対象を分類 | 公開面、権限、事業重要度で優先順位表を作成 |
| 3週目 | managed identityまたはfederationのパイロット移行 | 代表的な1〜3システムで移行手順を確立 |
| 4週目 | 新規シークレット作成の抑止策を導入 | ポリシー、承認フロー、IaCテンプレート、CIチェック |
高リスクの判定では、次の条件に該当するものを優先します。
| リスク条件 | 優先理由 |
|---|---|
| インターネット公開サービスが使っている | 攻撃者が到達しやすい |
| Microsoft GraphやサブスクリプションContributor権限を持つ | 悪用時の影響範囲が広い |
| シークレットがCI/CDや環境変数に保存されている | 閲覧・誤出力・漏えいの可能性がある |
| 期限切れで過去に障害を起こした | 可用性リスクも高い |
| 所有者が不明 | インシデント時に停止判断が遅れる |
失敗しやすいポイントと回避策
| 失敗パターン | 何が起きるか | 回避策 |
|---|---|---|
| Key Vaultへの保存だけで満足する | シークレット自体は残り、漏えいや期限切れリスクも残る | managed identityやfederationでシークレット不要にできるかを先に確認 |
| managed identityに広い権限を付ける | トークン悪用時の影響範囲が大きくなる | RBACを最小スコープにし、接続先ごとの権限を分ける |
| 外部ワークロードのOIDC設定を属人的にする | リポジトリ名やブランチ変更で認証が壊れる | issuer、subject、audienceの命名規則と変更管理を定義 |
| 例外の期限を決めない | クライアントシークレットが恒久化する | 例外は期限、所有者、代替計画を必須にする |
| セキュリティ部門だけで進める | 開発チームが迂回策を作る | platform engineeringとしてテンプレートと自動化を提供 |
| プレビュー機能を本番統制の前提にする | 仕様変更や制限で運用が揺らぐ | プレビューは検証対象、本番統制は正式機能中心に設計 |
次に取るべき行動
Microsoft Entra ID、managed identities、enterprise security architectureの利用者が今回の更新から取るべき行動は、シークレットのローテーション計画を作ることだけではありません。最初に行うべきなのは、どこに再利用可能な資格情報が残っているかを可視化し、それをmanaged identities、workload identity federation、Power Platform managed identity、AIエージェント向けID管理に置き換えられるかを判断することです。
実務では、次の順番で進めると失敗しにくくなります。
- Microsoft Entra IDのアプリ登録、サービスプリンシパル、シークレット、証明書を棚卸しする
- Azure上のワークロードはmanaged identitiesへ移行できるか確認する
- GitHub Actions、Kubernetes、外部基盤はworkload identity federationを検討する
- Dataverse、Power Platform、AIエージェントの非人間IDを別枠で管理する
- RDP、SSH、公開データプレーンなどの到達可能なエンドポイントを減らす
- 例外を人手で管理せず、paved pathsとpolicy-as-codeに落とし込む
資格情報排除は、単なるIDチームの改善ではありません。認証、ネットワーク、プラットフォーム、CI/CD、監査、ガバナンスを横断するアーキテクチャ変更です。まずは新規シークレットの発行を抑え、既存の高リスク資格情報から順に消していくことが、機会主義的な攻撃に強いMicrosoft Entra ID環境を作る現実的な第一歩になります。
コメント