2026年4月20日の Microsoft Security Blog「Making opportunistic cyberattacks harder by design」は、「攻撃を検知して止める」以前に、攻撃者が使いやすい資格情報そのものを減らすべきだ、という強いメッセージとして読めます。特に Microsoft Entra ID、managed identities、enterprise security architecture を使う組織にとって、優先すべき対策は明確です。パスワード、クライアントシークレット、APIキー、共有接続文字列を棚卸しし、managed identities や workload identity federation に置き換え、あわせて公開エンドポイントと例外的な個別構成を減らすことです。(Microsoft)
重要なのは、「資格情報を安全に保管する」だけで満足しないことです。Microsoft Security が示す方向性は、漏えい・使い回し・期限切れ・リポジトリへの誤コミットといった事故原因を、設計段階から減らすアプローチです。Security teams、compliance leads、platform architects は、単なる設定変更ではなく、認証方式、ネットワーク到達性、権限設計、開発標準をまとめて見直す必要があります。
Microsoft Security の主張は「資格情報を守る」から「資格情報をなくす」への転換
Microsoft Security Blog では、日和見的な攻撃への対策として、credential elimination、endpoint reduction、identity controls、platform engineering が取り上げられています。特に印象的なのは、多くの攻撃者はネットワークを高度に突破するのではなく、盗まれた資格情報でログインする、という前提です。資格情報が少なければ、フィッシング、推測、再利用、漏えいの対象も少なくなります。(Microsoft)
この考え方は、Microsoft Entra ID を中心にした認証基盤を運用している組織ほど重要です。クラウド環境では、人間のアカウントだけでなく、アプリケーション、サービスプリンシパル、CI/CD、AIエージェント、ローコード基盤など、多数の非人間IDがリソースへアクセスします。Microsoft Entra のワークロードIDは、アプリケーション、サービスプリンシパル、managed identities を含む概念であり、これらは人間のIDとは別の管理課題を持ちます。(Microsoft Learn)
従来のセキュリティ対策は、パスワードポリシー、MFA、シークレットローテーション、監査ログに重点を置きがちでした。しかし、ワークロードIDはMFAを実行できず、正式なライフサイクル管理がないまま増えやすく、どこかに資格情報やシークレットを保存する必要があるケースもあります。そのため、単に「強いシークレットを使う」よりも、「シークレットを使わない設計へ移行する」方が根本的なリスク低減につながります。(Microsoft Learn)
まず評価すべきリスクは「外部公開・高権限・再利用可能」な資格情報
すべての資格情報を一度に廃止するのは現実的ではありません。最初に見るべきは、漏えいしたときに攻撃者がすぐ横展開できる資格情報です。
| 見るべき対象 | よくある場所 | 典型的なリスク | 優先する対応 |
|---|---|---|---|
| アプリ登録のクライアントシークレット | Microsoft Entra ID、CI/CD設定、環境変数 | 有効期限が長い、所有者不明、複数環境で使い回し | managed identity または workload identity federation へ移行 |
| APIキー・接続文字列 | appsettings.json、Key Vault、GitHub、DevOps変数 | コードやログに出る、権限範囲が広い | Entra ID認証、RBAC、Key Vaultは暫定利用に限定 |
| サービスアカウント | バッチ処理、レガシー連携、運用スクリプト | パスワードが長期固定、個人に紐づかない | 用途別IDへ分離し、可能な範囲で managed identity 化 |
| CI/CDのサービス接続 | Azure DevOps、GitHub Actions、社内デプロイ基盤 | デプロイ権限が広い、リポジトリ単位で横展開される | フェデレーション認証、環境別の最小権限 |
| Power Platform / Dataverse 連携 | プラグイン、カスタム連携、Power Automate | 業務ユーザーがアプリ登録やシークレット管理を回避しにくい | Power Platform managed identity の利用を検討 |
| 公開された管理・データプレーン | RDP、SSH、App Service、Storage、Key Vault、DB | 資格情報漏えい時に外部から到達可能 | Private Endpoint、Bastion、JIT、公開アクセス無効化 |
優先順位を決めるときは、次の5つを点数化すると判断しやすくなります。
| 評価軸 | 高リスクと判断する例 |
|---|---|
| 外部到達性 | インターネットから到達できるエンドポイントで使われている |
| 権限の強さ | Owner、Contributor、Key Vault管理、Storage広範囲アクセスなどを持つ |
| 再利用性 | 1つの資格情報を複数アプリ、複数環境、複数パイプラインで共有している |
| 発見されやすさ | コード、ログ、環境変数、チケット、Wikiに残っている可能性がある |
| ライフサイクル不備 | 所有者不明、有効期限なし、ローテーション履歴なし、削除基準なし |
最初のターゲットは、「本番環境」「高権限」「外部到達可能」「長期シークレット」の4条件が重なる箇所です。ここは、攻撃者にとって最も使いやすく、監査・コンプライアンス上も説明が難しい領域です。
managed identities を標準の認証方式にする
managed identities は、Azureリソースに Microsoft Entra ID 上の自動管理されたIDを付与し、対応するサービスへ資格情報をコードに持たずに認証する仕組みです。Microsoft のドキュメントでも、managed identities はアクセスキーやパスワードなどのシークレットを置き換えられ、資格情報自体が利用者からアクセスできないことが利点として説明されています。(Microsoft Learn)
実務では、まず「この接続は本当にシークレットが必要か」と問い直すべきです。たとえば、App Service から Key Vault、Azure Functions から Storage、VM上のアプリから Azure SQL や Service Bus にアクセスするケースでは、managed identity と Azure RBAC、または対象サービス側の権限モデルで置き換えられる可能性があります。
| 種類 | 向いている場面 | 注意点 |
|---|---|---|
| システム割り当て managed identity | 1つのAzureリソースに紐づく単純なワークロード | リソース削除時にIDも削除されるため、ライフサイクルは分かりやすい |
| ユーザー割り当て managed identity | 複数リソースで同じ役割を使う、blue/green構成、権限をリソースと分離したい場合 | 使わなくなったIDを手動で削除する運用が必要 |
| アプリ登録・サービスプリンシパル | Azure外部のワークロード、SaaS、CI/CDなど | クライアントシークレットではなくフェデレーション認証を優先する |
Microsoft のドキュメントでは、システム割り当てIDはリソースのライフサイクルに紐づき、ユーザー割り当てIDは独立したAzureリソースとして複数リソースに割り当てられると説明されています。ユーザー割り当て managed identity は、権限設計をリソースから分離しやすいため、複数インスタンスや標準化されたプラットフォームで特に有効です。(Microsoft Learn)
managed identities 移行の実務手順
| 手順 | 実施内容 | 成功条件 |
|---|---|---|
| 接続先の確認 | Key Vault、Storage、SQL、Service Busなどが Microsoft Entra 認証に対応しているか確認 | パスワードやアクセスキー以外の認証方式が使える |
| IDの作成・有効化 | システム割り当てまたはユーザー割り当て managed identity を設定 | ワークロードごとに識別可能なIDがある |
| 権限付与 | Azure RBACやデータプレーン権限を最小権限で付与 | 読み取りだけでよい処理に書き込み権限を与えない |
| アプリ修正 | Azure Identity SDK、MSAL、各サービスSDKのEntra認証へ変更 | 接続文字列やシークレットを参照しない |
| 検証 | 本番同等の権限・ネットワーク条件で疎通確認 | 旧シークレットを無効化しても処理が動く |
| 旧資格情報の廃止 | クライアントシークレット、APIキー、接続文字列を削除または失効 | 監査で「残存シークレットなし」と説明できる |
ここで失敗しやすいのは、managed identity に広すぎる権限を与えてしまうことです。managed identity が割り当てられたリソースでコードを実行できるユーザーは、そのIDに付与された権限を実質的に使える可能性があります。Microsoft も、コード実行権限を持つユーザーが managed identity の権限を利用できる点に注意を促しています。(Microsoft Learn)
CI/CDや外部ワークロードは workload identity federation を優先する
Azure上で動くワークロードは managed identities が第一候補です。一方、GitHub Actions、Kubernetes、外部クラウド、SaaS、社内ビルド基盤など、Azureリソースとして直接 managed identity を割り当てにくい環境では、workload identity federation を検討します。
Microsoft Entra Workload ID のドキュメントでは、Azure上のワークロードは managed identities により、GitHub Actions、Kubernetes、Azure外部のコンピュートなどは workload identity federation により、シークレット管理なしで Microsoft Entra 保護リソースへアクセスできるシナリオが示されています。(Microsoft Learn)
Power Platform の領域でも、Power Platform managed identity は Dataverse プラグインからAzureリソースへ資格情報管理なしに接続する仕組みとして説明されています。また、Power Platform Build Tools for Azure DevOps では、サービスプリンシパルのクライアントシークレットよりも、workload identity federation を使う接続方式が推奨されています。(Microsoft Learn)
フェデレーション認証で注意すべき設計
| 設計項目 | 悪い例 | 良い例 |
|---|---|---|
| 対象範囲 | すべてのリポジトリ、すべてのブランチから本番へデプロイ可能 | 本番デプロイ用IDは特定リポジトリ・特定ブランチ・承認済み環境に限定 |
| 権限 | 1つのサービスプリンシパルに全サブスクリプションのContributorを付与 | 環境・アプリ・操作単位で権限を分割 |
| 監査 | パイプライン名だけで誰が何をしたか追えない | リポジトリ、環境、ジョブ、承認者をログで追える |
| 例外管理 | 一時的なクライアントシークレットを放置 | 期限付き例外として登録し、削除日を持たせる |
フェデレーション認証は「シークレットを持たない」点で強力ですが、発行条件が広すぎると、別のリポジトリやブランチから意図せず権限を使える設計になります。特に本番環境では、issuer、subject、audience、環境承認、ブランチ保護をセットで見直すべきです。
公開エンドポイントを減らし、資格情報漏えい時の到達経路を絞る
credential elimination と並行して取り組むべきなのが endpoint reduction です。managed identity に置き換えても、データプレーンや管理プレーンが広く公開されたままでは、設定ミスや過剰権限の影響範囲が残ります。
Azure Private Endpoint は、仮想ネットワーク内のプライベートIPアドレスを使って Azure Private Link 対応サービスへ接続するネットワークインターフェイスです。これにより、対象サービスを実質的に仮想ネットワーク内へ取り込む形でアクセスできます。(Microsoft Learn)
ただし、Private Endpoint を作成しただけで公開アクセスが自動的に無効になるとは限りません。たとえば Azure Storage のドキュメントでは、Private Link を作成しても public endpoint への接続は自動的にはブロックされず、private endpoint のみに制限したい場合はストレージファイアウォールで public endpoint 経由のアクセスを拒否または制御する必要があると説明されています。(Microsoft Learn)
Key Vault でも同じ考え方が重要です。Microsoft の Key Vault セキュリティ推奨では、ネットワーク露出を減らすことが重要であり、最も制限の強い構成として public network access を無効化し、Private Endpoints のみを使うことが示されています。(Microsoft Learn)
| 対象 | 推奨される見直し | 注意点 |
|---|---|---|
| Azure Key Vault | Private Endpoint 化、public network access 無効化、RBAC利用 | シークレット保管庫にするだけでは資格情報排除にならない |
| Azure Storage | Private Endpoint、Storage firewall、Entra ID認証、アカウントキー利用の削減 | Private Endpoint作成だけではpublic endpointが残る場合がある |
| App Service / API | Private Endpoint、アクセス制限、不要な公開URLの削除 | Private Endpointとpublic accessは併存し得るため、明示的な無効化が必要 |
| 管理アクセス | RDP/SSH公開を避け、Bastion、JIT、Serial Consoleなどを検討 | 緊急運用のための例外を恒久化しない |
| データベース | Entra認証、Private Link、最小権限、監査ログ | 接続元DNSがpublic側を引いていないか確認する |
App Service の Private Endpoint でも、Microsoft は private endpoints と public access が共存できるため、分離を確実にするには public network access を無効化するよう説明しています。さらに、DNS設定が誤っていると private endpoint ではなく public endpoint 側へ解決されることがあるため、Private DNS Zone やカスタムDNSの設計まで含めて検証する必要があります。(Microsoft Learn)
Key Vault は「資格情報排除」までの中間地点と考える
Azure Key Vault は重要な保護策ですが、credential elimination のゴールではありません。Key Vault にシークレットを入れると、コード直書きよりは安全になります。しかし、シークレットが存在する限り、ローテーション、参照権限、漏えい検知、期限切れ、依存アプリ停止の問題は残ります。
Microsoft のアプリケーション移行ガイドでも、短期的にシークレットベース認証から移行できないアプリケーションについては、シークレットをローテーションし、Azure Key Vault などの安全な方法を使うよう説明されています。つまり、Key Vault は「移行できないものを安全に扱う」ための対策であり、「シークレットを残し続ける理由」にはなりません。(Microsoft Learn)
実務上は、次のように整理すると判断しやすくなります。
| 状況 | Key Vault の位置づけ | 次のアクション |
|---|---|---|
| すぐ managed identity 化できる | 不要または一時的 | 直接Entra認証へ移行 |
| レガシーアプリで短期移行が難しい | 暫定的な保管場所 | 期限付き例外として登録し、移行計画を作る |
| 外部SaaSがAPIキーしか対応しない | 必要な保護策 | ローテーション、アクセス監査、利用範囲の限定 |
| 証明書や暗号鍵の管理が必要 | 本来の用途として利用 | 自動ローテーション、分離、復旧手順を整備 |
Key Vault のセキュリティ推奨では、アプリケーション、リージョン、環境ごとにKey Vaultを分けることや、Key Vaultを一般的なデータストアとして使わないことも示されています。これは、侵害時の影響範囲を小さくし、監査証跡を分かりやすくするうえで重要です。(Microsoft Learn)
プラットフォーム標準化で「例外だらけの安全対策」を終わらせる
Microsoft Security Blog がもう一つ強調しているのが platform engineering です。日和見的な攻撃は、一貫性のない構成、例外的な許可、チームごとの独自実装を好みます。Microsoft の記事では、標準化された共通の実行基盤、通信ライブラリ、ポリシー、テレメトリによって、個別サービスごとに対策を展開するのではなく、プラットフォーム側の変更で多数のサービスに防御を適用する考え方が示されています。(Microsoft)
enterprise security architecture の観点では、個別チームに「安全に作ってください」と依頼するだけでは限界があります。安全な設計を、開発者が自然に選べる「既定値」にする必要があります。
| 標準化する領域 | 具体例 | セキュリティ上の効果 |
|---|---|---|
| 認証方式 | managed identity、workload identity federation、Entra認証SDK | シークレットの新規発生を抑える |
| IaCテンプレート | Bicep、Terraform、Azure Verified Modulesなど | Private Endpoint、ログ、RBACを標準で有効化 |
| CI/CD | 承認フロー、環境分離、フェデレーション認証 | デプロイ権限の乱立を防ぐ |
| ネットワーク | public access無効、Private DNS、接続元制御 | 外部からの探索対象を減らす |
| 監査証跡 | Entraサインインログ、Azure Activity Log、Defender、Sentinel | 例外と権限変更を追跡しやすくする |
| 例外管理 | 期限、所有者、リスク受容、再承認 | 「一度だけ」の例外が恒久化するのを防ぐ |
ここでのポイントは、セキュリティチームがすべてのレビューを手作業で抱え込まないことです。ポリシーとして禁止するもの、標準テンプレートで自動適用するもの、例外申請で扱うものを分けると、スピードと統制を両立しやすくなります。
役割別に優先すべきアクション
Security teams、compliance leads、platform architects は、同じテーマを見ていても責任範囲が異なります。credential elimination を組織施策として進めるには、それぞれの成果物を明確にすることが重要です。
| 役割 | 最初にやること | 成果物 |
|---|---|---|
| Security teams | 長期シークレット、公開エンドポイント、高権限サービスプリンシパルを棚卸し | リスク順リスト、検知ルール、失効・移行計画 |
| Compliance leads | 例外、所有者、期限、証跡、承認プロセスを定義 | 監査用コントロール、例外台帳、証跡テンプレート |
| Platform architects | managed identity と Private Endpoint を前提にした標準構成を作る | IaCモジュール、参照アーキテクチャ、開発者向けガードレール |
特にコンプライアンス担当者は、「シークレットがKey Vaultにあるから安全」と単純化しない方がよいでしょう。監査で問われるのは、保管場所だけではありません。誰がアクセスできるか、なぜ必要か、いつ廃止するか、漏えい時にどこまで影響するか、証跡を示せるかが重要です。
30日・60日・90日で進める実行計画
一気に全社移行を狙うと、影響範囲が大きくなりすぎます。最初の90日は、棚卸し、優先順位付け、標準化の土台作りに集中すると効果が出やすくなります。
| 期間 | 重点テーマ | 実施内容 |
|---|---|---|
| 30日以内 | 見える化と高リスク封じ込め | 本番・高権限・外部公開の資格情報を棚卸し。新規クライアントシークレット作成を原則禁止または承認制にする |
| 60日以内 | 主要ワークロードの移行 | Key Vault、Storage、DB、CI/CDの上位リスクから managed identity / federation へ移行。旧シークレットを失効 |
| 90日以内 | 標準化と再発防止 | IaC、Azure Policy、CI/CDテンプレート、例外台帳、監査証跡を整備。開発チームが標準構成を選べる状態にする |
この計画では、移行件数よりも「新しい危険な資格情報を増やさない」ことを重視します。既存の負債を減らしても、新規プロジェクトで長期シークレットが作られ続ければ、リスクは戻ってしまいます。
失敗しやすいポイントと回避策
credential elimination は効果が大きい一方、設計を誤ると停止や権限過多を招きます。特に次の点に注意してください。
| 失敗パターン | 何が起きるか | 回避策 |
|---|---|---|
| managed identity に広すぎる権限を付ける | そのリソースでコード実行できる人が強い権限を使える | 実行権限とID権限をセットでレビューする |
| 権限変更がすぐ反映されると思い込む | 削除・変更した権限がしばらく効いているように見える | 検証時間を確保し、直接割り当てを優先する |
| Private Endpoint だけ作って公開アクセスを残す | 外部からの到達経路が残る | public network access、ファイアウォール、DNSを確認する |
| Key Vault に入れたので完了とする | シークレットの存在リスクが残る | Key Vault利用を暫定扱いし、廃止日を持たせる |
| ユーザー割り当てIDを放置する | 使われていないIDやロール割り当てが残る | 定期レビューと削除手順を標準化する |
| 例外に期限を付けない | 「一時対応」が恒久化する | 例外は所有者、理由、期限、再承認を必須にする |
managed identity の権限変更では、トークンがAzure基盤側でキャッシュされるため、グループやロールメンバーシップの変更反映に時間がかかる場合があります。Microsoft は、managed identity のトークンキャッシュにより権限変更の反映に数時間かかる可能性があり、迅速な反映が必要な場合はユーザー割り当て managed identity に権限を直接付与することを推奨しています。(Microsoft Learn)
また、ユーザー割り当て managed identity はリソースとは独立したライフサイクルを持つため、不要になったら手動で削除する必要があります。managed identity を削除してもロール割り当てが自動削除されない点も、棚卸し時に見落としやすいポイントです。(Microsoft Learn)
まず着手すべき結論
Microsoft Entra ID / managed identities / enterprise security architecture を使う組織が最初にやるべきことは、次の3つです。
1つ目は、本番環境で使われているパスワード、クライアントシークレット、APIキー、接続文字列を棚卸しし、外部公開・高権限・長期有効なものから移行対象にすることです。
2つ目は、Azure上のワークロードでは managed identities、CI/CDや外部ワークロードでは workload identity federation を優先し、Key Vault は移行できないシークレットの暫定的な保護策として扱うことです。
3つ目は、Private Endpoint、public network access の無効化、DNS確認、Azure Policy、IaCテンプレートを組み合わせ、個別チームの努力ではなくプラットフォームの既定値として安全な構成を提供することです。
日和見的な攻撃に強い組織は、攻撃者が使える「便利な入口」を減らしています。資格情報を複雑に守るより、資格情報を持たない設計へ移す。その方針を Microsoft Entra ID、managed identities、ネットワーク分離、プラットフォーム標準化に落とし込むことが、2026年以降のクラウドセキュリティで優先度の高いリスク低減策です。
コメント