増殖する「ゾンビ認証情報」の脅威 これまでのシークレット管理をどう見直すべきか：「ワークロードIDへの移行が必要」 HashiCorp見解

多くの組織で非人間アイデンティティーの数が人間のユーザーを大幅に上回る中、その管理が課題となっている。HashiCorpは公式ブログで、従来の静的シークレットの管理から「ワークロードアイデンティティー（ID）」への移行が必要だとの見解を示した。

[＠IT]

　HashiCorpは2026年1月7日（米国時間）、「シークレット管理とアイデンティティー管理の未来」と題したブログ記事を公開した。

　HashiCorpは「ほとんどの組織で非人間アイデンティティー（NHI：Non-Human Identities）の数が人間のユーザー数を大幅に上回る中、静的シークレット（機密情報）の管理からワークロードIDへの移行が必要だ」と指摘し、今後取り組むべき優先事項を解説した。

人間より「桁違いに多い」認証情報をどう管理するか

　NHIには、サービスアカウント、APIキー、OAuthトークン、証明書、マシン認証情報などが含まれる。マイクロサービスや、コンテナ化されたワークロード、クラウドネイティブアーキテクチャの爆発的な利用拡大を背景に、NHIの数は人間のユーザーよりも桁違いに多くなっている。「だが、組織の多くは人間向けに設計されたアプローチでNHIを管理している」と、HashiCorpは指摘する。

　例えば、典型的なKubernetesクラスタには数百のPodが含まれ、それぞれがデータベース、メッセージキュー、オブジェクトストレージ、外部APIなどにアクセスするための認証情報を必要としている。

　さらに、それらが開発、ステージング、本番環境で使用され、そこにCI/CD（継続的インテグレーション／継続的デリバリー）パイプライン、監視エージェント、バックアップサービス、インフラ自動化ツールなども加わることで、管理対象のNHIは数千から数万まで膨れ上がる。

　このアーキテクチャにおけるアキレス腱（けん）となるのが静的シークレットだ。その中には、環境変数に埋め込まれたデータベースパスワード、「Terraform」（HashiCorpが開発したIaC〈Infrastructure as Code〉ツール）の状態ファイル内のAWS（Amazon Web Services）アクセスキー、マウントされたボリュームに存在するサービスアカウントのJSONといったものが含まれる。

　長期間有効なこれらの認証情報は、永続的なアタックサーフェス（攻撃対象領域）となる。静的シークレットが侵害された場合、手動でローテーションが行われるまで、攻撃者はアクセス権を維持することになる。

　HashiCorpは、静的シークレットは運用上の負担も深刻だと指摘する。

　「手動での認証情報ローテーションはエラーが発生しやすく、予定通りに行われることはめったにない。インフラが拡大するにつれ、シークレットがどこで使用されているかを追跡することは不可能になる。その結果、未知の依存関係を壊すことを恐れて削除できない『ゾンビ認証情報』が無期限に蓄積されてしまう」

　公開鍵暗号とバイオメトリクス（生体認証）を用いてフィッシング耐性のある認証を提供する「WebAuthn」「FIDO2」「passkey」といった技術によって、エンドユーザーのパスワードレス化は進んでいる。人間のユーザーにとって大きな進歩だ。だが、現代のインフラを支えるNHIの管理は、より複雑な課題として組織にのしかかっている。

ワークロードIDによるNHIの静的シークレットの排除

　HashiCorpによると、こうした課題を抱えるNHI管理における最も有望な進展は、「ワークロードID」への移行だという。これは、NHIを最重要な管理対象に含め、動的に発行される短時間有効な認証情報を使用するアプローチだ。

　ワークロードIDシステムは、静的シークレットを配布、管理するのではなく、インフラ自体を活用してIDを確立し、一時的な認証情報を発行する。

　主要クラウドプロバイダーもワークロードIDへの移行を主導している。AWSは「AWS IAM roles for service accounts」（IRSA）を、Microsoft Azureは「Azure Managed Identities」を、Google Cloudは「Google Cloud Workload Identity」を提供しており、いずれもワークロードにシークレットを埋め込むのではなく、ワークロードの実行コンテキストに基づくワークロード認証を可能にしている。

　例えば、Kubernetesで実行されるPodは、IAM（Identity and Access Management）ロールを引き受け、数分または数時間で失効する一時的な認証情報を受け取れる。インフラレイヤーがワークロードのIDを証明することで、静的シークレット（この場合はアクセスキー）をどこにも保存する必要がないという。

　サービスメッシュはこの概念をサービス間通信に拡張し、SPIFFE/SPIRE（Secure Production Identity Framework for Everyone/SPIFFE Runtime Environment）の実装を通じてX.509証明書を自動的に発行、ローテーションする。各サービスは暗号的に検証可能なIDを持ち、開発者が証明書を管理することなく、相互TLS（Transport Layer Security）認証（mTLS）が透過的に行われる。

　適切に実装されれば、どのサービスも、長期間有効なシークレットを扱わずに済むようになる。以下のように、その実用上の影響は大きい。

• CI/CDパイプラインは、OIDC（OpenID Connect）フェデレーションを用いてクラウドプロバイダーに認証し、そのパイプライン実行に必要な範囲に限定された一時的な認証情報を受け取る
• アプリケーションPodは、データベースのパスワードを一切見ず、ワークロードIDを用いて認証し、時間制限付きアクセストークンを受け取る
• サービスを廃止すると、そのIDも消滅するため、手動でのクリーンアップなしにアクセス権が自動的に失効する

可観測性と検出による最新状態の把握

　NHIの管理には、継続的な発見と監視も必要だ。これには、リポジトリをスキャンして、漏えいしたシークレットを探すツールや、クラウドのIAMロールやサービスアカウントのインベントリを作成できるツールが使用される。これらのプラットフォームはインフラ全体にわたって、隠れたAPIキー、パスワード、マシンIDを発見し、組織が以下を行うことを可能にする。

• サービスと認証情報の依存関係をマッピングする
• マネージドIDへの移行準備ができている移行候補を特定する
• 現在のシークレットの使用に関連するリスクを評価し、露出したシークレットをトリアージする

　「NHIの異常な挙動を検知することも同様に重要だ。人間の行動とは異なり、マシンのワークロードは、非常に予測可能である傾向があるため、NHIにおける異常検知は特に効果的となる」（HashiCorp）

過渡期におけるシークレット管理の在り方

　ワークロードIDの将来性は高いものの、多くの組織にとって静的シークレットからの移行は、依然として遠い目標だ。現実には、動的な認証情報をサポートしていないレガシーシステム、サードパーティーのSaaS API、データベースを使用しており、当面の間は一部の静的シークレットを管理する必要がある。

　HashiCorpは、現代のシークレット管理に求められる重要な機能として、「ロールバック機能を備えた自動ローテーション」「シークレットを実行時に注入するジャストインタイムのアクセスプロビジョニング」「どのワークロードがどのシークレットにアクセスできるかを制限するポリシーベースのアクセス制御」「シークレットについて、いつ誰がアクセスしたかを示す包括的な監査証跡」の4つを挙げている。

　また、CI/CDパイプラインとの統合も不可欠だと述べている。シークレットは展開（デプロイ）時に取得され、環境変数やマウントボリュームとして注入されるべきであり、リポジトリにコミットされたり、パイプライン定義に保存されたりしてはならないとしている。

技術リーダーのための実践的ステップ

　静的シークレットからワークロードIDへの移行には、何年もかかる。開発、運用、セキュリティチームが協調して取り組む必要がある。HashiCorpは、その道筋を描く技術的な意思決定者が重視すべき戦略的優先事項として、以下を挙げている。

1. 新しいサービスではワークロードIDをデフォルトとする

　クラウドネイティブなワークロードでは、慣れや見掛けの簡便さから静的認証情報に頼るのではなく、ネイティブなIDサービスを最初から活用すべきだ。

2. 既存の静的認証情報に対して包括的なシークレット管理を実装する

　シークレットを、自動ローテーション機能とアクセスポリシーを備えた一元的なプラットフォームに統合すれば、すぐにセキュリティ効果が得られ、シークレットの使用状況の可視化により、どのシステムを動的認証情報に移行すべきかの優先順位付けが可能になる。

3. NHIのガバナンスを優先事項とする

　人間のアカウントに適用するのと同様の規律でNHIのプロビジョニング、レビュー、廃止のプロセスを実装する必要がある。

4. NHIの挙動の可観測性に投資する

　正常なパターンを理解することで異常検知が可能になる。認証情報の使用に関する包括的な監査ログは、セキュリティ監視に役立ち、コンプライアンス上の証拠を提供する。

5. フェデレーションと標準化を受け入れる

　OIDC、OAuth 2.0、SPIFFEなどのオープン標準は、相互運用性を実現し、ベンダーロックインを軽減する。IDが複数のクラウドやオンプレミスシステムに分散する環境において、一貫したセキュリティポリシーを維持するには、標準ベースのアプローチが不可欠だ。

　HashiCorpは今後の展望として「NHIの認証情報とIDの管理において将来目指すべき姿は、ワークロードIDがデフォルト（既定）となり、シークレットは自動的にローテーションされ、ポリシーの適用がインフラ層で透過的に行われるというものだ。そうなれば、セキュリティは、人的ミスが発生しやすい手動プロセスではなくなり、アーキテクチャ自体の特性となる」と述べている。