非人間アイデンティティ（NHI: Non-Human Identity）は、APIキー、サービスアカウント、OAuth トークン、TLS証明書、CI/CDパイプラインのシークレット、AIエージェント資格情報など「機械が使う認証情報」を総称する概念である。クラウドネイティブ化とAIエージェントの台頭が加速するほどNHIは爆発的に増殖し、管理の甘い経路が最大のサイバー侵害起点になりつつある。

2025年3月にSysdigが公表したクラウドネイティブセキュリティレポートでは、機械IDは人間IDの4万倍に達し、機械IDは人間IDより7.5倍リスクが高いとされた。同レポートは、資格情報の悪用が多くのクラウド侵害の起点になることを明確に示している。さらにOWASPは2025年に「Non-Human Identities Top 10」を正式公開し、NHI固有のリスクを体系化した。NHIを「人のIAMの延長」として扱う限り、攻撃面は拡大し続ける。本稿では、NHIの脅威構造を解剖し、OWASP NHI Top 10、PCI DSS 4.0/4.0.1の要件、そしてCISO向けの実践的な導入ロードマップを整理する。

NHIが攻撃面の中心に移った構造的理由

NHIが最大の侵害経路になった背景には、クラウドネイティブ化・マイクロサービス化・AIエージェント普及という3つの構造的変化がある。

第一に、クラウドネイティブ化によるNHIの爆発的増殖である。従来のモノリシックアプリケーションでは、データベース接続用のサービスアカウントが数個あれば事足りた。しかしマイクロサービスアーキテクチャでは、サービス間通信のたびに認証トークンが必要となる。100のマイクロサービスが相互通信すれば、理論上は数千のNHIが発生する。Kubernetesクラスタでは、Pod ごとにサービスアカウントが自動生成され、本番環境の82%でKubernetesが稼働する現在、NHIの数は人間が手動で管理できる規模をはるかに超えている。

第二に、CI/CDパイプラインとIaCによるシークレットの拡散である。GitHub Actions、GitLab CI、Jenkins、Terraform、Ansible──これらのツールチェーンはすべてシークレット（APIキー、クラウドプロバイダのアクセスキー、デプロイトークン）を必要とする。開発速度を重視するあまり、シークレットがハードコードされたり、環境変数として平文で保管されるケースは後を絶たない。筆者自身、セキュリティ診断の実務で、.envファイルがGitリポジトリにコミットされたまま数年間放置されていたケースや、CI/CDの環境変数に本番のAWSアクセスキーが平文で設定されていた事例に何度も遭遇してきた。「プロトコルやHTTPヘッダ一つの設定ミスが致命的な脆弱性になり得る」という原則は、シークレット管理にも当てはまる。

第三に、AIエージェントが新たなNHIカテゴリを生み出していることだ。2026年現在、20時間以上の自律作業が可能なAIエージェントが登場し、これらのエージェントはAPIキー、OAuthトークン、データベース接続情報など複数のNHIを保持して動作する。エージェントが自律的にツールを呼び出し、外部サービスと連携するたびに、NHIの管理範囲は動的に拡大する。従来のサービスアカウントと異なり、AIエージェントのNHIは「どの権限をいつ使うか」が実行時まで予測しにくいという新たな課題を生んでいる。

NHIは24時間365日稼働し、人間のように「ログアウト」しない。権限が過剰に付与されやすい一方で、退役や棚卸しが徹底されない。退職した開発者が作成したサービスアカウントが数年間アクティブなまま残り続ける──これは例外ではなく、多くの組織で常態化している現実である。

OWASP NHI Top 10が体系化した10のリスク

OWASPは2025年に「Non-Human Identities Top 10」を正式公開し、NHI固有の主要リスクを世界で初めて体系化した。従来のOWASP Top 10がWebアプリケーションの脆弱性を対象としていたのに対し、NHI Top 10はマシンIDのライフサイクル全体を対象とする。以下に全10項目を解説する。

IDリスク名概要
NHI1不適切なオフボーディング退役すべきNHIが無効化されず残存。退職者のサービスアカウント、廃止されたアプリのAPIキーなど
NHI2シークレット漏えいGitリポジトリやログへのAPIキー・トークンの意図しない露出
NHI3脆弱なサードパーティNHI外部SaaSやパートナーAPIの資格情報を信頼しすぎるリスク
NHI4安全でない認証弱い認証方式（平文パスワード、署名なしトークン）の使用
NHI5過剰な権限最小権限の原則に反するNHIの権限設定
NHI6安全でないクラウドデプロイメント設定クラウドのIAMポリシーやロール設定の不備
NHI7長寿命シークレット有効期限のない、またはローテーションされないシークレット
NHI8環境の分離不足本番・ステージング・開発環境でNHIが共有されるリスク
NHI9NHIの再利用異なる用途・システムで同じNHIを使い回すリスク
NHI10人間によるNHIの使用サービスアカウントを人間が直接利用する運用の問題

注目すべきは、これら10項目のすべてが「技術的脆弱性」ではなく「運用の弱点」に起因する点である。バッファオーバーフローのようなコードレベルの欠陥ではなく、発行・配布・保管・更新・廃棄というライフサイクル管理の不備がリスクの根本にある。CISOは「検知」より先に、NHIのライフサイクル統制を設計しなければならない。

NHI侵害の実例 ── 攻撃チェーンの解剖

NHI経由の侵害がどのように発生するかを、典型的な攻撃チェーンとして構造化する。

ステージ1：初期アクセス（シークレットの窃取）

攻撃者はGitHub上の公開リポジトリや、誤ってデプロイされた.envファイル、CI/CDログに残されたシークレットを発見する。あるいはフィッシングやサプライチェーン攻撃を通じて開発者のワークステーションからシークレットを抜き取る。クラウドネイティブ基盤の脆弱性を突いて、コンテナイメージ内にハードコードされたシークレットを取得するケースも増加している。

ステージ2：横展開（権限の拡大）

窃取したサービスアカウントの過剰な権限を利用し、クラウドリソースへのアクセスを拡大する。例えば、CI/CDパイプライン用のAWS IAMロールがAdministratorAccess相当の権限を持っていれば、そこからS3バケット、RDSデータベース、Lambda関数すべてにアクセスできる。NHIには通常MFAが設定されないため、認証情報さえ手に入れば即座にアクセスが成立する。

ステージ3：永続化と情報窃取

攻撃者は新たなサービスアカウントやAPIキーを作成して永続的なアクセスを確保し、データの外部送信を開始する。NHIのアクティビティは大量のAPI呼び出しの中に埋もれるため、人間ユーザーの不審なログインと比べて検知が困難である。SOCが監視しているのは人間ユーザーの異常行動であり、サービスアカウントの微妙な権限昇格は見落とされやすい。

この攻撃チェーンで特筆すべきは、すべてのステージで正規の認証情報が使用される点である。ブルートフォース攻撃やエクスプロイトのようなノイズの多い手法ではなく、正当なAPIキーやトークンによる「正常なアクセス」として実行される。エージェンティックAI攻撃面の産業化が進む中、NHI経由の侵害は従来のシグネチャベース検知をほぼ完全にバイパスする。検知に必要なのは、「誰がアクセスしたか」ではなく「そのNHIの通常の振る舞いから逸脱しているか」という行動ベースの分析である。

PCI DSS 4.0/4.0.1の要件とNHI管理の交差点

PCI SSCは2022年3月31日にPCI DSS v4.0を公開し、認証・アクセス管理の大幅な強化を盛り込んだ。v3.2.1は2024年3月31日に退役しており、カード決済に関わるすべての組織はv4.0準拠への移行が完了している前提となる。さらにPCI SSCは2024年6月11日にv4.0.1を公開し、要件の明確化と曖昧な表現の修正を行った。

NHI管理の観点で特に重要な要件は以下の通りである。

要件7：カード会員データへのアクセス制限 ── NHIにも「業務上の必要性」に基づく最小権限を適用する必要がある。サービスアカウントがカード会員データ環境（CDE）にアクセスする場合、その権限は明示的に文書化し、定期的にレビューしなければならない。

要件8：ユーザーアクセスの識別と認証 ── v4.0ではMFAの適用範囲がCDEへのすべてのアクセスに拡張された。NHIに対しては直接MFAを適用できないため、代替統制として短命トークン、ワークロードID、相互TLS認証などの強化策が必要となる。v4.0.1では、アプリケーションアカウントとシステムアカウントの管理要件がさらに明確化され、NHI固有の管理策がより具体的に示された。

要件10：ネットワークリソースとCDEへのすべてのアクセスの追跡と監視 ── NHIのアクティビティもログに記録し、異常検知の対象とする必要がある。サービスアカウントによる通常のAPI呼び出しパターンからの逸脱を検知するベースライン監視が求められる。

要件12：情報セキュリティポリシー ── NHIのライフサイクル管理（作成、権限付与、レビュー、廃棄）をセキュリティポリシーに明示的に含める必要がある。

これらの要件は人間IDだけでなくNHIにも「最小権限」「短命化」「継続的検証」を適用する設計を前提としている。PCI DSS準拠を目指す組織は、NHI管理を別のプロジェクトとして扱うのではなく、既存のコンプライアンスフレームワークに統合すべきである。

AIエージェント時代のNHI管理 ── 新たなリスク領域

2026年はAIエージェントの実運用元年であり、NHI管理に根本的な見直しを迫っている。従来のNHIは「静的な資格情報」──デプロイ時に設定され、以後変わらないAPIキーやサービスアカウント──が中心だった。しかしAIエージェントは動的にツールを選択し、実行時に必要な権限が変化する。

具体的なリスクとして、以下の3つが挙げられる。

1. 動的権限要求の管理困難 ── AIエージェントが「メール送信」「ファイル操作」「データベースクエリ」「外部API呼び出し」を自律的に切り替える場合、事前に最小権限を定義することが極めて難しい。広い権限を付与すればリスクが増大し、狭い権限では業務が遂行できない。

2. エージェント間のNHI伝播 ── マルチエージェントシステムでは、あるエージェントのNHIが別のエージェントに渡されることがある。このNHI伝播チェーンが管理されていなければ、1つのエージェントの侵害が全エージェント群に波及する。

3. プロンプトインジェクションによるNHI悪用 ── 攻撃者がプロンプトインジェクションを通じてAIエージェントを操作し、エージェントが保持するNHI（APIキー、データベース接続情報）を使って不正な操作を実行するリスクがある。エージェント自身は正規のNHIを使っているため、従来の認証ベースの検知では区別がつかない。プロンプトインジェクションは「完全修正不可能」な脆弱性であるため、NHI側での権限制限が防御の最終ラインとなる。

これらのリスクに対処するためには、AIエージェントのNHIに対して「セッションベースの短命トークン」「操作ごとの明示的な権限承認」「NHI利用ログの全量記録」を組み合わせた多層防御が不可欠である。エージェントに付与するNHIは、実行するタスクに必要な最小限のスコープに限定し、タスク完了後に即時失効させる設計が推奨される。

CISO向け導入ロードマップ（90日・180日・12か月）

NHI管理の成熟度を段階的に引き上げるための実践的ロードマップを示す。

フェーズ1：0〜90日 ── 可視化と棚卸し

  • NHIインベントリの構築：クラウドIAM（AWS IAM、GCP SA、Azure AD App）、CI/CDシークレット、SaaS APIキー、AIエージェント資格情報を網羅的に棚卸しする
  • シークレット保管場所の特定：Vault、AWS Secrets Manager、GCP Secret Manager、環境変数、設定ファイル、ハードコードされたシークレットを一覧化する
  • 権限レビュー：最重要NHI（本番環境アクセス権を持つもの）に対し、現在の権限を棚卸しし、過剰権限を特定する
  • 失効ルールの定義：シークレットの最大有効期間を定義する（推奨：90日以内）

フェーズ2：90〜180日 ── 短命化と自動化

  • シークレットの短命化：長寿命APIキーを短命トークン（1時間〜24時間）に移行する
  • 自動ローテーション：Vault、AWS Secrets Manager等を用いたシークレットの自動ローテーションを標準化する
  • NHI発行ポリシーの整備：用途限定、環境分離、最小権限を原則とするポリシーを策定・適用する
  • 人間によるNHI利用の禁止：サービスアカウントの直接利用を制限し、JITアクセス（Just-In-Time）に移行する

フェーズ3：180日〜12か月 ── ゼロトラスト統合

  • 静的キーの廃止：OIDCフェデレーション、ワークロードID、SPIFFEなどの動的認証に移行する
  • 監査ログと異常検知の統合：NHIのアクティビティログをSIEMに統合し、ベースライン逸脱の自動検知を実装する
  • NHIの継続的検証：期限、権限、用途、環境の4軸で定期的な自動検証を実施する
  • AIエージェントNHIのガバナンス：エージェントごとの権限境界、NHI伝播の制限、実行ログの記録を実装する

経営向けKPI設計 ── NHI対策の可視化

NHI対策は成果が見えにくいため、経営には定量指標で説明する必要がある。以下の7つのKPIを推奨する。

KPI目標値測定方法
短命資格情報の比率80%以上有効期間24時間以内のNHI / 全NHI
過剰権限NHIの削減率前四半期比-20%最小権限違反のNHI数を四半期ごとに計測
退役NHIの無効化までの平均時間24時間以内サービス廃止からNHI無効化までの時間
シークレット漏えい検知から無効化までの時間1時間以内検知アラートからローテーション完了までの時間
NHIインベントリのカバレッジ95%以上管理下NHI / 推定NHI総数
環境分離違反のNHI数0件本番・開発環境で共有されているNHI数
人間によるNHI直接利用件数0件サービスアカウントへの人間ログイン数

これらのKPIを四半期ごとに経営会議で報告することで、NHI管理への投資の妥当性を可視化できる。セキュリティ投資は「事故が起きなかったこと」では説明しにくいが、KPIの改善トレンドは経営判断の材料として有効である。

実務者の視点 ── NHI管理で最初に取り組むべきこと

筆者はセキュリティアーキテクトとして複数の企業でゼロトラスト設計やセキュリティ戦略策定に関わってきた経験から、NHI管理について一つ強調したいことがある。それは「セキュリティ戦略は、ビジネスの制約を理解した上でないと絵に描いた餅になる」という点だ。

理想的には、すべてのNHIを短命化しOIDCフェデレーションに移行すべきだが、レガシーシステムとの互換性、開発チームの運用負荷、移行コストを考慮すると、一気にすべてを変えることは現実的ではない。まずは「本番環境にアクセスできるNHI」を洗い出し、そこから優先的に短命化とローテーション自動化を適用していくことが、最も効果的な初手である。

SOCの価値はツールではなくアラートから判断までの人間のプロセスにあるが、NHI監視は逆にツールの力を借りなければ成立しない。数千〜数万のNHIが生成するAPIログを人間が目視で監視することは不可能であり、ベースラインからの逸脱を自動検知する仕組みが不可欠である。

FAQ

非人間アイデンティティ（NHI）とは何か？

APIキー、サービスアカウント、OAuthトークン、TLS証明書、CI/CDシークレット、AIエージェント資格情報など、機械やソフトウェアが使用する認証情報の総称である。人間が直接操作するユーザーIDとは異なり、システム間の自動通信を認証する目的で使用される。

なぜNHIは人間IDより危険なのか？

NHIは24時間365日稼働し、人間のようにログアウトしない。権限が広く設定されやすく、MFAが適用されず、棚卸しや廃棄が不十分になりがちである。Sysdigの調査では、機械IDは人間IDの4万倍に達し、7.5倍リスクが高いとされている。

OWASP NHI Top 10は何を示しているのか？

NHI特有の主要リスクを10項目に体系化したフレームワークである。不適切なオフボーディング（NHI1）、シークレット漏えい（NHI2）、長寿命シークレット（NHI7）など、すべて「運用の弱点」に起因するリスクを示し、ライフサイクル管理の重要性を強調している。

PCI DSS 4.0/4.0.1はNHI管理にどう影響するのか？

PCI DSS v4.0では認証とアクセス管理が大幅に強化され、MFAの適用範囲がCDEへのすべてのアクセスに拡張された。NHIに対しては短命トークンやワークロードIDなどの代替統制が必要となり、v4.0.1ではアプリケーションアカウント・システムアカウントの管理要件がさらに明確化されている。

シークレットの「短命化」とは具体的に何か？

静的なAPIキーや永続的なサービスアカウントキーの代わりに、有効期間が1時間〜24時間の一時トークンを使用することを指す。OIDCフェデレーション、AWS STS、GCPワークロードIDフェデレーションなどを活用して、シークレットの露出リスクを時間的に制限する手法である。

AIエージェントのNHI管理はなぜ難しいのか？

従来のサービスアカウントは事前に定義された固定的な用途で使用されるが、AIエージェントは実行時に動的にツールを選択し、必要な権限が変化する。加えて、マルチエージェントシステムではNHIがエージェント間で伝播するリスクがあり、プロンプトインジェクションを通じた不正利用の懸念もある。

最初に着手すべきことは何か？

まず本番環境にアクセス権を持つNHIの棚卸しから始めるべきである。クラウドIAM、CI/CD、SaaS連携のシークレット保管場所を特定し、過剰権限のNHIを洗い出す。短命化とローテーション自動化の準備はこの段階で並行して進める。全体を一気に変えるのではなく、リスクの高い本番環境アクセスから優先的に対処することが実践的である。

参考文献