大規模企業で横展開リスクを下げる最短ルートは、シークレットを「厳重に保管する」だけではありません。可能なワークロードから、そもそもパスワード、クライアントシークレット、APIキーを持たせないことです。2026年4月20日にMicrosoft Security Blogで公開された更新では、機会主義的攻撃への実践的な防御として、credential elimination、managed identities、endpoint reduction、platform engineeringが強調されています。(Microsoft)
特にMicrosoft Entra IDとmanaged identitiesを使ったシークレットレス設計は、CISO、identity architect、platform security leadにとって優先度の高いテーマです。理由は単純です。盗まれる資格情報が減れば、フィッシング、リポジトリへの誤コミット、期限切れシークレット、再利用されたAPIキーを起点にした横展開の余地も減ります。
大企業の横展開リスクは「盗まれる資格情報」から始まる
多くの企業は、侵入対策というと脆弱性スキャン、EDR、WAF、SIEMの強化を思い浮かべます。もちろんこれらは重要ですが、攻撃者が常に高度なゼロデイを使うとは限りません。実務で厄介なのは、近隣システムや周辺環境で入手した資格情報を使い、正規のログインやAPI呼び出しに見せかけて移動するケースです。
Microsoft Securityは、機会主義的攻撃の文脈で「攻撃者はネットワークを破るのではなく、盗んだ資格情報でログインする」という趣旨を示し、より確実な対策として資格情報そのものをシステムから排除する考え方を提示しています。(Microsoft)
大企業で横展開が起きやすい理由は、技術力の不足ではなく、環境の広さと例外の多さにあります。たとえば、次のような状態はどの企業でも起こりがちです。
- 古いアプリの接続文字列にデータベースパスワードが残っている
- CI/CDの環境変数にサービスプリンシパルのクライアントシークレットが入っている
- 複数チームが同じAPIキーを使い回している
- Key Vaultにシークレットを置いたが、取得側のアプリ認証に別のシークレットを使っている
- 一時的な例外として作った認証情報が棚卸しされていない
- 本番ワークロードのIDと権限の所有者が分からない
この状態で一つのシークレットが漏えいすると、攻撃者は「そのシークレットがどこまで使えるか」を試します。これが横展開の入口になります。したがって、managed identitiesとシークレットレス設計の価値は、単に認証方式を近代化することではなく、攻撃者が再利用できる材料を減らすことにあります。
managed identitiesとは何かを実務目線で整理する
Microsoft Entra IDでは、ワークロードIDはアプリケーション、サービスプリンシパル、managed identitiesを含む概念です。managed identityは、開発者が資格情報を管理しなくてもよい特殊なサービスプリンシパルとして説明されています。(Microsoft Learn)
Azure上のワークロードでは、managed identityをAzure VM、Azure App Service、Azure Functions、AKSなどのリソースに割り当て、Microsoft Entra IDのトークンを取得して下流リソースにアクセスできます。Microsoftのドキュメントでは、managed identitiesはアクセスキー、パスワード、証明書などを置き換えられる仕組みとして説明されています。(Microsoft Learn)
実務上は、次のように理解すると分かりやすいです。
| 観点 | 従来のシークレット利用 | managed identitiesによるシークレットレス設計 |
|---|---|---|
| 認証情報 | パスワード、APIキー、クライアントシークレット、証明書を保管する | ワークロードがMicrosoft Entra IDトークンを取得する |
| 保管場所 | appsettings、環境変数、CI/CD変数、Key Vaultなど | アプリ側で秘密情報を保持しない |
| 主な運用 | 発行、配布、ローテーション、失効、期限管理 | IDの割り当て、RBAC、監査、ライフサイクル管理 |
| 漏えい時の影響 | 再利用されやすく、横展開の材料になる | 再利用可能な秘密がなく、ID単位で無効化・権限調整しやすい |
| 失敗しやすい点 | 期限切れ、誤コミット、共有、棚卸し漏れ | 過剰権限、共有IDの乱用、監視不足 |
重要なのは、managed identitiesは「強いパスワード」ではなく「パスワードを置かない設計」だという点です。秘密情報を守る責任を各チームの運用努力に依存させるのではなく、プラットフォームの標準機能に寄せることで、ばらつきの少ない防御に変えられます。
なぜシークレットレスは横展開対策として効果が高いのか
盗まれて再利用される材料を減らせる
横展開では、攻撃者が取得した資格情報を別のシステムで試す行動が典型的です。APIキー、クライアントシークレット、接続文字列は、一度漏えいすると複数の場所で利用可能な場合があります。
managed identitiesでは、アプリケーションはMicrosoft Entra IDからトークンを取得して対象リソースにアクセスします。Microsoftのドキュメントでも、アプリケーションが資格情報を管理せずにMicrosoft Entraトークンを取得できる点が説明されています。(Microsoft Learn)
これにより、攻撃者がリポジトリ、ログ、構成ファイル、CI/CD変数から長期間使える秘密情報を抜き取る機会を減らせます。
ワークロード単位で監査しやすくなる
大企業のセキュリティ運用では、「誰がアクセスしたか」だけでなく「どのワークロードが、どの権限で、どのリソースにアクセスしたか」が重要です。
managed identitiesはMicrosoft Entra ID上のIDとして扱われるため、RBAC、サインインログ、アクティビティログなどと組み合わせて監査しやすくなります。Microsoftのドキュメントでも、managed identitiesのCRUD操作やサインインアクティビティを確認できることが示されています。(Microsoft Learn)
たとえば、同じ「本番アプリ」でも、注文処理、請求処理、分析バッチ、通知処理に別々のIDを割り当てれば、異常なアクセスを切り分けやすくなります。逆に、複数サービスで一つの強力なIDを共有すると、managed identityを使っていても横展開の影響範囲は広がります。
公開エンドポイント削減と組み合わせると効果が大きい
Microsoft Security Blogでは、credential eliminationとendpoint eliminationを組み合わせる考え方が示されています。managed identitiesでサービス間認証を行い、Private Linkやprivate endpoints、RDP/SSHの無効化、JITやBastionなどのブローカー型アクセスを組み合わせることで、攻撃者が到達できる入口を減らすという整理です。(Microsoft)
ここが実務上のポイントです。シークレットレスにしても、すべてのデータプレーンや管理ポートがインターネットに開いていれば、攻撃面は十分に小さくなりません。逆に、公開面を閉じても、内部に再利用可能なシークレットが大量にあれば、侵入後の横展開は止めにくくなります。
大企業では、次の2つをセットで進めるべきです。
| 対策 | 目的 | 具体例 |
|---|---|---|
| credential elimination | 盗まれる資格情報を減らす | managed identities、workload identity federation、DefaultAzureCredential |
| endpoint reduction | 攻撃者が到達できる入口を減らす | private endpoints、Private Link、Bastion、JITアクセス、不要なRDP/SSH閉鎖 |
最初に移行すべきワークロードの判断基準
すべてのワークロードを一度にシークレットレス化するのは現実的ではありません。優先順位を付けるなら、「漏えいしたときの横展開範囲」と「移行のしやすさ」で判断します。
| 優先度 | 対象 | 推奨パターン | 理由 |
|---|---|---|---|
| 高 | Azure App Service、Azure Functions、VM上の本番アプリ | managed identity + Microsoft Entra認証対応サービスへのRBAC | アプリ側の接続文字列やシークレットを削減しやすい |
| 高 | CI/CDからAzureへデプロイするパイプライン | workload identity federation | サービスプリンシパルの長期シークレットをなくしやすい |
| 高 | Key Vault、Storage、SQL、Cosmos DBにアクセスする内部アプリ | managed identity + 最小権限 | データアクセス権限の横展開を抑えやすい |
| 中 | AKS上のワークロード | Microsoft Entra Workload ID、managed identity連携 | Podや名前空間単位の権限分離を設計しやすい |
| 中 | Power PlatformやDataverse連携 | Power Platform Managed Identityなどの対応機能 | ローコード領域での埋め込み資格情報を減らせる |
| 中 | AIエージェントや自動化エージェント | Microsoft Entra上のワークロードID管理 | 人間の代理ではなく、エージェント単位で説明責任を持たせやすい |
| 低〜中 | Microsoft Entra認証に未対応の外部サービス | Key Vault + managed identityで取得 | 完全なシークレットレスではないが、保管とアクセスを分離できる |
Microsoftのシークレットレス認証に関するドキュメントでは、Azureリソース間のサービス間認証ではmanaged identitiesが推奨され、同一テナントではmanaged identitiesとDefaultAzureCredentialの利用が示されています。一方、Microsoft Entraで保護されていない外部リソースにアクセスする場合は、Key Vaultに資格情報を保存し、ワークロード側はmanaged identityでKey Vaultへアクセスする整理が示されています。(Microsoft Learn)
つまり、最初の対象は「Microsoft Entra認証に対応しているAzure依存関係」です。ここは投資対効果が高く、アプリ改修も比較的進めやすい領域です。
system-assigned、user-assigned、workload identity federationの使い分け
managed identitiesには、system-assignedとuser-assignedがあります。さらに、Azure外のワークロードやCI/CDではworkload identity federationを使う場面があります。使い分けを誤ると、せっかくのシークレットレス化が運用負荷や過剰権限につながります。
| 方式 | 向いている場面 | 注意点 |
|---|---|---|
| System-assigned managed identity | 単一のAzureリソースに固有のIDを持たせたい場合。リソース削除時にIDも削除したい場合 | リソース作成前にロール割り当てを準備しにくい。リソース再作成時にIDが変わる可能性がある |
| User-assigned managed identity | 複数リソースで同じ権限セットを使う場合。事前にIDと権限を作り、インフラ展開に使いたい場合 | 共有しすぎると影響範囲が広がる。不要になったIDの削除責任が残る |
| Workload identity federation | GitHub Actions、外部クラウド、オンプレミスなどAzure外のワークロードからMicrosoft Entra保護リソースへアクセスする場合 | issuer、subject、audienceなど信頼条件の設計と棚卸しが重要 |
| Key Vault + managed identity | 対象サービスがMicrosoft Entra認証に未対応で、まだ秘密情報が必要な場合 | シークレット自体は残るため、暫定策として扱い、ローテーションと移行計画を持つ |
Microsoftのmanaged identitiesドキュメントでは、system-assignedはリソースのライフサイクルに紐づき、user-assignedは独立したAzureリソースとして複数リソースに割り当てられると説明されています。(Microsoft Learn)
また、Microsoftのベストプラクティスでは、user-assigned managed identityはより広いシナリオで効率的とされ、リソース作成前にIDやロール割り当てを準備できる利点が説明されています。ただし、各リソースに固有の権限を持たせたい場合や、リソース削除と同時にIDも削除したい場合はsystem-assignedが適します。(Microsoft Learn)
Azure外のワークロードでは、長期シークレットを使わずに外部IdPのトークンをMicrosoft identity platformで交換するworkload identity federationが有効です。Microsoftのドキュメントでは、外部IdPとuser-assigned managed identityまたはアプリケーションの間に信頼関係を作る流れが説明されています。(Microsoft Learn)
CISOが見るべき評価指標
シークレットレス化は技術施策であると同時に、経営レベルのリスク削減施策です。CISOは「managed identitiesを導入したか」ではなく、横展開リスクがどれだけ減ったかを測る必要があります。
実務で使いやすい指標は次のとおりです。
| 指標 | 何を見るか | 改善の方向 |
|---|---|---|
| 本番ワークロードのシークレットレス率 | 本番アプリのうち、managed identityまたはfederationで認証している割合 | 四半期ごとに対象範囲を拡大する |
| 長期クライアントシークレット数 | App registrations、CI/CD、Key Vault、構成ファイルに残る長期秘密情報 | 新規発行を制限し、既存分を段階的に削減する |
| 高権限ワークロードID数 | Owner、Contributor、広範囲のデータアクセス権を持つID | 最小権限に分解し、承認制にする |
| 所有者不明のワークロードID | 管理者、アプリオーナー、利用目的が不明なID | オーナー必須化し、期限付き例外にする |
| 公開管理エンドポイント数 | RDP、SSH、管理API、公開データプレーンの露出 | Bastion、JIT、private endpointsへ移行する |
| シークレット期限切れによる障害 | 証明書・クライアントシークレット期限切れで起きた停止 | managed identityやfederationへ移行する |
| 例外の滞留期間 | 「一時的に許可した」シークレット利用が何日残っているか | 期限、責任者、廃止日を必須にする |
CISOにとって重要なのは、シークレットレスを「開発チームの良い取り組み」で終わらせないことです。新規アプリの標準、既存アプリの移行計画、例外承認、監査、インシデント対応まで含めたプログラムにする必要があります。
identity architectが設計時に決めるべきこと
identity architectは、managed identitiesを単に有効化するだけでは不十分です。IDの粒度、権限、ライフサイクル、監査、例外処理まで設計しなければ、後から別の複雑性が生まれます。
特に決めるべきポイントは次の5つです。
| 設計項目 | 判断基準 |
|---|---|
| IDの粒度 | アプリ単位、機能単位、環境単位、本番・検証の分離をどうするか |
| 権限モデル | Azure RBAC、データプレーン権限、対象サービス固有権限をどう最小化するか |
| ライフサイクル | 作成、割り当て、権限変更、削除、オーナー変更を誰が承認するか |
| federationの信頼条件 | CI/CDや外部IdPのissuer、subject、audienceをどこまで絞るか |
| 監査と検知 | サインインログ、異常なトークン利用、高権限付与、未使用IDをどう検出するか |
よくある失敗は、シークレットレス化を急ぐあまり、複数アプリに同じuser-assigned managed identityを割り当てすぎることです。これは管理は楽になりますが、侵害時の影響範囲も広がります。共有IDは「同じ権限セットを持つ同種のリソース」に限定し、業務機能やデータ境界が異なる場合は分けるべきです。
platform security leadが用意すべき「安全な標準ルート」
大規模企業では、全チームに「managed identityを正しく使ってください」と依頼しても定着しません。必要なのは、セキュアな選択が最も簡単になる標準ルートです。
Microsoft Security Blogでは、プラットフォームエンジニアリングの価値として、paved paths、policy-as-code、secure-by-defaultのランタイムやパイプライン、例外を抑える経営支援が挙げられています。また、Microsoft内部の例として、共通サービスに防御を実装すると450以上のサービスへ継承できるという説明もあります。(Microsoft)
platform security leadが用意すべきものは、次のような実装済みテンプレートです。
- managed identityが標準で有効なIaCモジュール
- 本番環境でクライアントシークレットを禁止するポリシー
- Azure SDKとDefaultAzureCredentialを使う標準コード例
- Key Vaultにアクセスする場合もmanaged identityを使う標準構成
- private endpointsを前提にしたネットワークテンプレート
- CI/CDでworkload identity federationを使うデプロイテンプレート
- 例外申請時に期限、責任者、廃止計画を必須化するワークフロー
- RBACの最小権限ロールを選ぶためのガイド
- ログ、メトリック、アラートを含む監視テンプレート
ここで大切なのは、禁止ルールだけを増やさないことです。開発チームが安全な方法を選んだほうが速くリリースできる状態を作る必要があります。セキュリティが「止める部門」ではなく、「安全なデフォルトを設計する部門」になったとき、シークレットレス化は全社に広がります。
30日・60日・90日で進める実装ロードマップ
シークレットレス化は一度のプロジェクトではなく、継続的な移行プログラムとして進めるのが現実的です。最初から全社一斉移行を狙うより、横展開リスクが高い領域に絞って成果を出すほうが成功しやすくなります。
| 期間 | 実施内容 | 成果物 |
|---|---|---|
| 最初の30日 | 本番ワークロード、App registrations、CI/CD、Key Vault、構成ファイルにあるシークレットを棚卸しする。新規の長期シークレット発行に承認制を入れる | シークレット台帳、ワークロードID台帳、優先移行リスト |
| 31〜60日 | Azure上の高リスクアプリからmanaged identityへ移行する。Storage、Key Vault、SQL、Cosmos DBなどのアクセスを最小権限化する | 代表ワークロードの移行完了、RBAC標準、接続コード標準 |
| 61〜90日 | CI/CDをworkload identity federationへ移行し、policy-as-codeとIaCテンプレートで新規シークレット利用を抑制する | federation標準、例外管理プロセス、ダッシュボード |
| 90日以降 | 公開エンドポイント削減、private endpoints、Bastion、JIT、不要ID削除を継続する | 横展開リスクKPI、監査証跡、定期レビュー |
最初の30日で無理にすべてを直す必要はありません。重要なのは、どこに長期シークレットがあり、どれが本番データや高権限に接続しているかを可視化することです。可視化できれば、CISOはリスクベースで投資判断できます。identity architectは設計標準を作れます。platform security leadは移行しやすいテンプレートを提供できます。
実装時に失敗しやすいポイント
managed identitiesとシークレットレス設計は強力ですが、導入すれば自動的に安全になるわけではありません。特に大企業では、次の失敗に注意が必要です。
| 失敗パターン | 何が問題か | 対策 |
|---|---|---|
| managed identityに広すぎる権限を付ける | シークレットはなくても、侵害時の操作範囲が広い | 対象リソース、操作、環境を分けて最小権限にする |
| 1つのuser-assigned identityを多くのサービスで共有する | 一つのID侵害や誤設定が多数のサービスに波及する | 同じ業務境界・同じ権限セットに限定する |
| シークレットレス化だけ行い、公開エンドポイントを残す | 攻撃者が到達できる入口が残る | private endpoints、Bastion、JIT、不要ポート閉鎖を同時に進める |
| 開発環境と本番環境の認証経路が違いすぎる | 本番でだけ失敗する、または開発者用資格情報が残る | DefaultAzureCredentialなどで環境差を吸収し、明示的な本番設定を作る |
| CI/CDに古いサービスプリンシパルシークレットが残る | デプロイ経路が横展開の入口になる | workload identity federationへ移行する |
| IDの所有者が不明になる | 不審なアクセスや権限変更時に判断できない | ワークロードIDにオーナー、用途、期限、連絡先を必須化する |
| 例外が恒久化する | 「一時的なシークレット」が最も危険な負債になる | 例外には期限、更新審査、廃止計画を設定する |
特に「Key Vaultに入れたから安全」という誤解は避けるべきです。Key Vaultは重要な保護レイヤーですが、アプリがKey Vaultへアクセスするために別の長期シークレットを持っているなら、根本的なリスクは残ります。Key Vaultを使う場合でも、取得側の認証はmanaged identityへ寄せるのが基本です。
シークレットレス化を全社標準にするための実務チェックリスト
最後に、CISO、identity architect、platform security leadがすぐ確認できるチェックリストを整理します。
CISO向け
| チェック項目 | 確認ポイント |
|---|---|
| 本番の長期シークレット数を把握しているか | App registrations、CI/CD、Key Vault、構成ファイルを横断して見ているか |
| 新規シークレット発行に統制があるか | 承認、期限、責任者、廃止予定が必須になっているか |
| シークレットレス率をKPI化しているか | 事業部別、環境別、重要システム別に追えるか |
| 高権限ワークロードIDをレビューしているか | Owner、Contributor、広範囲データアクセスを定期的に見直しているか |
| 横展開リスクを公開エンドポイントと合わせて見ているか | 認証情報とネットワーク到達性を別々に管理していないか |
identity architect向け
| チェック項目 | 確認ポイント |
|---|---|
| system-assignedとuser-assignedの使い分けが定義されているか | ライフサイクル、共有可否、事前承認の観点が明文化されているか |
| workload identity federationの標準があるか | issuer、subject、audience、対象リポジトリ、ブランチ条件などを絞っているか |
| 最小権限のロール設計があるか | 汎用的なContributor付与に逃げていないか |
| ID所有者と用途が記録されているか | オーナー不明のワークロードIDを作らない仕組みがあるか |
| 監査ログを運用で使えるか | 異常検知、権限変更、未使用ID削除につながっているか |
platform security lead向け
| チェック項目 | 確認ポイント |
|---|---|
| managed identity有効化済みのIaCテンプレートがあるか | 開発チームがゼロから調べなくても使えるか |
| サンプルコードがシークレットレス前提か | 接続文字列やクライアントシークレットを例示していないか |
| CI/CDテンプレートがfederation対応か | 長期シークレットを使うサービス接続が残っていないか |
| policy-as-codeで危険なパターンを止めているか | 本番の公開エンドポイント、シークレット利用、過剰権限を検出・ブロックできるか |
| 例外管理が軽く、しかし厳格か | 業務を止めずに期限付きで管理できるか |
まず取るべき行動
大規模企業が今すぐ始めるべきことは、全システムを一気に作り直すことではありません。まず、本番ワークロードに残っている長期シークレットを棚卸しし、Microsoft Entra IDとmanaged identitiesで置き換えやすい依存関係から移行することです。
優先順位は明確です。Azureサービス間通信はmanaged identitiesへ、CI/CDや外部ワークロードはworkload identity federationへ、Microsoft Entra認証に未対応の依存先はKey Vaultとmanaged identityの組み合わせへ寄せます。そのうえで、公開エンドポイント削減、最小権限、監査、policy-as-codeを組み合わせます。
シークレットを守る運用から、シークレットを持たない設計へ移ること。それが、Microsoft Entra IDを中心にしたenterprise security architectureで、横展開リスクを現実的に下げるための最も実践的な出発点です。
コメント