NHIの脆弱性に組織はどう向き合うか

こんにちは、ひろかずです。

前回のブログ「AIコーディング時代の「セキュリティの民主化」」では、AIコーディングの「アクセス経路」を整理しました。AIエージェントがいる場所、生成したコードを管理する場所、コードが動く実行基盤、そしてそこからアクセスされるデータの場所という全体像です。

今回はその続きとして、NHI（Non-Human Identity）をどう統制していくかを考えます。前回が「地図」だとすれば、今回は「その地図のどこに鍵が落ちていて、どう拾い集めるか」という話で一筆書きます。

この記事のまとめ／対象読者／読みどころ

忙しい人向けの要約

• NHIは、人間ではなくマシンやアプリ、自動化プロセスが使うIDです。AIエージェントが普及した今、PC・リポジトリ・IaaS・SaaS のあちこちに、性質の違うNHIが散らばっています。
• NHIの脆弱性は、煎じ詰めると「平文保存・ハードコード・放置・広すぎる認可・持ち主不明」の5つに集約できます。これは OWASP の ASI03（IDと権限の濫用） にそのまま当てはまり、ASI02（ツールの誤用と悪用） の被害を増幅させる前提条件にもなります。
• 取り組み方は NIST CSF 2.0 の6機能（統治・識別・防御・検知・対応・復旧）で整理できます。NHIには人間と違う固有の難しさ。所有者がいない／ライフサイクルが人事に乗らない／封じ込めが即サービス停止になりうる、があり、人間IDの手順をそのまま流用できません。
• ツール（EDR / SAST+CWPP（≒CNAPP）／ SSPM）で広い範囲をカバーできますが、本記事で題材にする Wiz をもってしても 統治（GV）はカバーできません。
• だからこそ、NHI対応の本質はガバナンスにある、というのが結論です。最後に「明日から使えるチェックシート」を付けました。

想定読者

• 主たる読者：情シス、開発チームの VPoE、CoE、セキュリティエンジニア
• あわせて読んでほしい人：この課題を検討する CISO、非エンジニアの方

技術者には踏み込んだ話を、非エンジニアには脱落しない説明を、両立させたつもりです。専門用語は初出時に軽く噛み砕き、まとめは末尾の用語集に置きました。

まず、NHIをおさらいする

NHI（Non-Human Identity）の詳しい解説は、当社ブログ記事「NHI（Non-Human Identity）管理が一気に立ち上がってきた件」に譲りますが、本記事に必要な分だけおさらいします。

NHIとは、人間ではなくマシン・アプリケーション・自動化プロセスがシステム間で認証・認可を受けるために使用するデジタルアイデンティティの総称です。具体的には以下のようなものを指します。

サービスアカウント（Active Directory、クラウドIAMのサービスプリンシパル等）APIキーOAuthトークン / アクセストークンシークレット（秘密鍵・証明書・接続文字列）ボット / RPAのアイデンティティCI/CDパイプラインの認証情報AIエージェントが使用するクレデンシャル

• サービスアカウント（Active Directory、クラウドIAMのサービスプリンシパル等）
• APIキー
• OAuthトークン / アクセストークン
• シークレット（秘密鍵・証明書・接続文字列）
• ボット / RPAのアイデンティティ
• CI/CDパイプラインの認証情報
• AIエージェントが使用するクレデンシャル

当社ブログ記事「NHI（Non-Human Identity）管理が一気に立ち上がってきた件」より引用

領域ごとに、性質が違うNHIが散らばっている

先ほどの図に当てはめると以下のようになります。

• PCにはエージェントが握るトークン、Repositoryにはハードコードされ得るシークレット、IaaSには実行ロール、SaaSにはOAuthアプリの認可と、領域ごとに性質の違うNHIが分散しています

NHIの脆弱性

さて、各領域のNHIにはどのような脆弱性や攻撃表面があるか見ていきましょう。

ここからは、出てきた脆弱性を一つずつ見ていきます。

平文保存・ハードコード・環境変数やファイルとしての保存

言うまでもありませんが、トークンやシークレット、APIキーを平文で置いておくのは危険です。その置き場所にアクセスできる人・AIエージェント・侵入者・マルウェアに読み取られ、別の場所や別の目的で使われてしまいます。

LLMへの送信・学習

発行したトークンやシークレット、APIキーが、コンテキストとして外部LLMへ送信・保持され、訓練データに取り込まれることがあります。学習されたモデルが後からそれを再生成すれば、思わぬ形で漏えいしかねません。実際に悪用される可能性は未知数ですが、管理上望ましくないのは確かです。

アクセス権設定の不備

保管場所そのものが堅牢でも、アクセス権限が広く付いていれば話は別です。「誰でも読めるなら、平文で置いてあるのとほぼ同じ」そう考えると分かりやすいでしょう。

利用が終了したトークンやシークレット、APIキーの放置

環境やシステムを使い終えても、鍵が残ったままになることがあります。放置された鍵が別の目的で再利用されると、過剰な権限の行使につながります。構築時にしか使わない鍵や、低頻度でしか使わない鍵も、同じ危うさを抱えています。

利用が終了したユーザープリンシパルの放置

これも「放置された鍵」と同じ脆弱性です。ただし、呼び出し元やアクセスできるリソースをユースケースに合わせて厳格に定義していれば、リスクは緩和されます。

利用が終了したOAuthアプリケーションの放置

AIエージェントが、OAuthで認可済みのアプリにアクセスできる状態だと、所有者の意図に反して、認可された範囲でエージェントがデータを操作・移動できてしまう可能性があります。

広すぎる認可

広すぎる認可は、それ単体でもエージェントに目的外利用される恐れがありますが、それ以上に怖いのは他の脆弱性と組み合わさって事故の「爆発半径」を広げる点です。

利用者や所有者の不明

誰が何のために作ったか分からない名前で登録されたトークンやプリンシパルは、異常な動作や広すぎる認可、利用状況の確認を困難にします。棚卸しを妨げるだけでなく、攻撃者が設置したものと区別が付かなくなるのが本当の問題です。

ログ上では人間とAIエージェントとの区別が付かない

これまでは、ユーザーが任意でOAuthアプリを使っていれば、その動作は「ユーザーの意図によるもの」とみなせました。しかし、ユーザーの権限を渡したOAuthアプリをAIエージェントが使う場合、その操作が人によるものかエージェントによるものか、ログからは区別できません。

OWASP Top 10 for Agentic Applications for 2026 との整合

ここまでの脆弱性を OWASP Top 10 for Agentic Applications for 2026 に照らすと、関係するのは2つです。

主軸は「ASI03 Identity and Privilege Abuse（IDと権限の濫用）」です。ここまで挙げてきた平文保存・ハードコード・放置された認証情報・広すぎる認可・利用者不明といった脆弱性は、いずれも「NHIの持つIDと権限が、本来の範囲を超えて使われうる」という、ASI03そのものに該当するからです。

ただし、これらは「ASI02 Tool Misuse and Exploitation（ツールの誤用と悪用）」とも関係しています。ASI02が成立する入り口（プロンプトインジェクションなど）はNHIの脆弱性とは別の話ですが、いざツールが誤用されたとき、エージェントが実際にどこまで壊せるかを決めるのは、そのエージェントが握るNHIの権限です。つまりNHIの脆弱性は、ASI02の被害を増幅する前提条件として効いてきます。

ASI02: Tool Misuse and Exploitation（ツールの誤用と悪用）

ASI02は、エージェントが正規のツールを、許可された権限の範囲内で使いながらも、安全でない・意図しない形で使ってしまうリスクを扱います。攻撃の入り口は、プロンプトインジェクション、エージェントの目標のずれ（misalignment）、安全でない委任、曖昧な指示などです。結果として、データ流出、ツール出力の改ざん、ワークフローの乗っ取りが起こります。

重要なのは、エージェントのメモリ、動的なツール選択、委任（delegation）といった仕組みが、ツールの連鎖（chaining）・権限昇格・意図しない行動を通じて誤用を助長する点です。

そして、この誤用が現実の被害に変わる度合いは、エージェントに割り当てられたNHIの権限の広さ、すなわち前章で挙げた「広すぎる認可」や「放置された認証情報」に大きく左右されます。

ASI03: Identity and Privilege Abuse（IDと権限の濫用）

ASI03は、エージェントが持つ「動的な信頼関係と委任（delegation）」を悪用して、アクセス権を昇格させたり制御を回避したりする攻撃を扱います。具体的には、委任チェーン、ロールの継承、制御フロー、そしてエージェントのコンテキストを操作することで攻撃が成立します。ここでいう「コンテキスト」には、キャッシュされた認証情報や、相互接続されたシステム間にまたがる会話履歴が含まれます。

この文脈での「アイデンティティ（identity）」は二重の意味を持ちます。

• エージェントに割り当てられたペルソナ（役割・人格）
• そのエージェントを表す認証材料（APIキー、OAuthトークン、委任されたユーザーセッション）

エージェント間の信頼や継承された認証情報が悪用されると、アクセス昇格、権限の乗っ取り、未認可のアクションの実行につながります。

NHIの脆弱性への取り組みをNIST CSF 2.0の観点で考える

ここで、NHIの脆弱性にどう取り組むべきか、みんな大好き「NIST Cyber Security Framework 2.0（以下、NIST CSF 2.0）」の観点で考えてみましょう。

まず、NIST CSF 2.0の機能をおさらいしておきましょう。

• 統治（GV） - 組織のサイバーセキュリティリスクマネジメント戦略、期待、ポリシーを確立され、伝達され、監視（モニタリング）される。
• 識別（ID） - 組織の現在のサイバーセキュリティリスクが識別されている。
• 防御 (PR) - 組織のサイバーセキュリティリスクを管理するためのセーフガード（セキュリティ対策）が使用される。
• 検知 (DE) - 起こり得るサイバーセキュリティ攻撃及び侵害の可能性が発見され、分析される。
• 対応 (RS) – 検知されたサイバーセキュリティインシデントに関するアクションが実行される。
• 復旧 (RC) - サイバーセキュリティインシデントの影響を受けた資産及び業務が復旧される。

「米国国立標準技術研究所 サイバーセキュリティフレームワーク（CSF） 2.0」より引用

関連する項目をピックアップしていきます。

統治（GV）

役割、責任、権限（GV.RR）：説明責任、実績アセスメント、継続的改善を促進するためのサイバーセキュリティの役割、責任、権限が確立され、伝達されている。

人間が利用するIDには、「本人」という所有者がいますが、NHI は明示的に割り当てない限り所有者が存在しません。そのため、すべての NHI に、名前のついた人間またはチームの責任者を必ず紐づける必要があります。（GV.RR-02）

人事（HR）プラクティスにはNHIのライフサイクルが存在しません。人は退職時にアカウント無効化されますが、退職者が在職中に作成したサービスアカウントやAPIキーは人事の退職手続きでは捕捉されません。そのため、NHIのために独立したライフサイクルが必要になってきます。（GV.RR-04）

リスクマネジメント戦略（GV.RM）：運用リスクの意思決定を支援するために、組織の優先順位、制約条件、リスク許容度、リスク選好度の表明、及び前提条件が確立され、伝達され、使用されている。

NHIは、人間に紐付けられたIDより大きく上回る規模で存在し、かつ可視性が低い性質があります。また、多くの組織はNHIに対する許容度（認証情報の有効期限や共有の可否など）を明文化していません。NHIを識別し、識別したNHIに対するリスク許容度を整理する必要があります。（GV.RM-02）

ポリシー（GV.PO）：組織のサイバーセキュリティポリシーが確立され、伝達され、実施されている。

NHIの脆弱性があるからといって、セキュリティ製品の購入に走るのは早計です。

組織の方針は、人間ユーザーを暗黙の前提としており、NHIをカバーしていないことが多いです。NHIの統制に方針上の根拠を持たせるために、組織の方針（ハードコード禁止やローテーション周期、NHI発行の承認フローなど）をアップデートする必要があります。（GV.PO-01）

また、脆弱性から導出されるリスクは、組織のセキュリティリスクマネジメントの中で取り扱われ、文書化され、技術環境の変化に合わせて継続的に更新される必要があります。（GV.PO-02）

スピード感がないように思えるかもしれませんが、目に見えるところだけを場当たり的に対応することにならないよう、組織での必要性を鑑みた上で取り扱われる必要があります。

サイバーセキュリティサプライチェーンリスクマネジメント（GV.SC）：サイバーサプライチェーンリスクマネジメントプロセスが、組織のステークホルダーによって識別され、確立され、管理され、監視され、改善されている。

NHIの脆弱性に関する取り組みは、自社内だけで良かったでしょうか？

どのサードパーティがどの NHI を介して自社環境にアクセスし、どれだけ特権を持つかを把握しなければ、優先順位付けは成立しません。各ベンダー連携について付与済みの OAuth スコープや API キーの権限範囲を棚卸しし、本番データへ広範にアクセスできる連携を高優先度として管理する必要があります。（GV.SC-04）

サプライチェーン間でやりとりされる情報の流通や事業に関わるサービスそのものに対して、NHIの脆弱性によるリスクの位置づけを整理しておく必要があります。（GV.SC-07）

サプライチェーンやサードパーティの契約が終了した際は、発行したAPIキーやOAuthアプリを使った侵入経路を断つために、これらを失効することを明文化する必要があります。（GV.SC-10）

識別（ID）

各領域に散在するNHIは、この機能にて識別され、その脆弱性や脅威、優先順位を組織で管理することになります。

資産管理（ID.AM）：組織のビジネス目的の達成を可能にする資産（例えば、データ、ハードウェア、ソフトウェア、システム、施設、サービス、人材）が識別され、組織の目的及びリスク戦略に対する相対的な重要性に整合して管理されている。

NHIを保有する領域の資産（ハードウェア、ソフトウェア、サービスやシステム）の一覧は、維持されている必要があります。（ID.AM-01, ID.AM-02, ID.AM-04）

また、NHIおよびNHIを保有する領域の資産は分類され、重要度やリソース、ミッションへのインパクトに基づいて優先順位付けされている必要があります。（ID.AM-05）

加えて、NHIおよびNHIを保有する領域の資産はライフサイクル全体を通じて管理されている必要があります。（ID.AM-08）

リスクアセスメント（ID.RA）：組織、資産、及び個人に対するサイバーセキュリティリスクを組織が理解している。

NHIの脆弱性は先に述べていますが、組織内で妥当性を確認し、その結果を記録する必要があります。（ID.RA-01）

この脆弱性に対するサイバー脅威インテリジェンスは、各情報源から入手し（ID.RA-02）、内部及び外部の脅威を識別し、記録します。（ID.RA-03）

NHIを保有する領域は広大ですので、識別された脅威が脆弱性を利用する発生可能性やインパクトに基づいて優先順位を付けるインプットとして使用します。（ID.RA-05）

防御（PR）

アイデンティティ管理、認証、アクセス制御（PR.AA）：物理的及び論理的資産へのアクセスが、認可されたユーザー、サービス、及びハードウェアに限定され、アセスメントされた不正アクセスのリスクに応じて管理されている。

ここでは、認可されたNHIとNHIを保有する各領域のIDおよび認証情報が組織によって管理し（PR.AA-01）、本人確認とIDとの結びつきを証明する（PR.AA-02）必要があります。

本人確認とIDとの結びつきを証明（PR.AA-02）は、以下3要素で構成されます。

これをNHIの文脈に当てはめると、人間とは異なる固有の難しさが見えてきます。

検知（DE）

継続的監視（DE.CM）：異常、侵害の痕跡、及びその他の潜在的な有害事象を発見するために、資産が監視されている。

潜在的な有害事象を発見するために、各領域のNHIの動作に関係するネットワーク・ネットワークサービスおよびコンピューティングハードウェアとソフトウェア、ランタイム環境、及びそれらのデータが監視され（DE.CM-01、DE.CM-09）、人員の活動及び技術の利用が監視されている（DE.CM-03）ことが必要です。

有害事象の分析（DE.AE）：異常、侵害の痕跡、及びその他の潜在的な有害事象が、事象を特徴付け、サイバーセキュリティインシデントを検知するために分析されている。

発見された潜在的な有害事象は、分析され（DE.AE-02）、複数の情報源から相互に関連付けられ（DE.AE-03）、インパクトと範囲が理解される（DE.AE-04）必要があります。

対応（RS）

インシデント軽減（RS.MI）：事象の拡大防止と影響を軽減するための活動が実施されている。

人間アカウントの封じ込めは「ユーザーを無効化しパスワードを強制リセット」で完結しますが、NHI の封じ込め（RS.MI-01）・根絶（RS.MI-02）は以下の3点において本質的に異なります。

1. 封じ込め=認証情報の失効・ローテーションであり、その認証情報が本番に組み込まれている場合、安易な失効が即サービス停止を招きます。
2. 根絶のためには漏洩したシークレットの「すべての複製」(コード、設定ファイル、CI 変数、開発者端末、ログ、git 履歴)を突き止めて除去する必要があります。
3. 攻撃者が侵害した NHI を使って新たな NHI(IAM ユーザー、アクセスキー、ロール、サービスアカウント)を作成し永続化を図るため、「攻撃者が新規に発行した認証情報」を探して消す作業が根絶に含まれます。

インシデント分析（RS.AN）：効果的な対応を確実にし、フォレンジック活動及び復旧活動をサポートするための調査が実施されている。

また、インシデント中に起きたことや根本原因を特定する分析（RS.AN-03）や、インシデントのデータ・メタデータの収集と完全性と来歴の保持（RS.AN-07）についても、NHI には人間のようなセッションや MFA イベントがないことから、静的・共有のシークレットを用いた場合「実際にどのワークロードがその認証情報を使ったのか」を後から切り分けるのが困難です。そのため、クラウド監査ログやシークレットアクセスログがほぼ唯一の証拠となり、その完全性が重要になります。

インシデント管理（RS.MA）：検知されたサイバーセキュリティインシデントへの対応が管理されている。

インシデントの分類と優先順位付け（RS.MA-03）やインシデント復旧を開始する基準の適用（RS.MA-05）においても、以下のようなNHI特有の判断があります。

1. NHIは、MFAもなく、広範囲な権限を持ち、一つの認証情報が複数のワークロードから使われる場合があります。この時、優先順位付けでは「この NHI がどこまでアクセスできるか」と「失効させると何が壊れるか」を両面で評価する必要があります。
2. 復旧開始基準についても、NHI の封じ込め（RS.MI-01）・根絶（RS.MI-02）の完了が確認できるまで、復旧に移れません。

復旧（RC）

インシデント復旧計画の実行（RC.RP）：サイバーセキュリティインシデントの影響を受けたシステム及びサービスの運用可用性を確実にするための復旧活動が実施されている。

バックアップや IaC・コンテナイメージ等の復元資産が、認証情報そのものを内包していることが多いです。インシデント前に取得したバックアップから復元すると、以下の2つの状態に陥る可能性があります。（RC.RP-03）

1. 対応中に失効させた認証情報を持つ古いシステムが復活して動かなくなる
2. 攻撃者がまだ保持している漏洩シークレットを再導入してしまう

そのため、NHIを利用する機械対機械（M2M）システムにおける「通常稼働状態」は、すべての NHI 認証チェーンが新しい認証情報で再び成立している状態とする必要があります。（RC.RP-05）

NHIが係わるインシデントの特性を踏まえると、インシデント後の運用基準の確立にあたって、重要機能とリスク管理の考慮（RC.RP-04）とは、短命・アテステーション付き認証情報への移行、CI でのシークレットスキャン、NHI インベントリの整備といった NHI 固有の恒久対策が入ってきます。

NHIの脆弱性にどう向き合うか

冒頭に紹介した、NHIが配置されている領域を振り返りましょう。

これらの領域に散らばるNHIを人力で管理するのは無理がありますね。それぞれの領域を何を用いてカバーするか考えてみましょう。広域をカバーするために、なるべく少ないソリューションで対応したいものです。

EDRは、NHIには直接関与しません。しかしながら、ローカルAIエージェントの検出や悪意あるAIエージェントの動作をブロックする機能が出てきています。NHIの窃取や誤用を防ぐ意味でもPC領域をカバーできる可能性が高いのはEDRだと考えます。まだ製品によってはプレビュー段階なので、もう少し時間が必要そうです。

SAST+CWPP（より正確にはCSPM / CIEMを含むCNAPP）は、それぞれ別のソリューションを使う場合もありますが、統合できるのであれば目指すべきです。この領域で最も近いのは、ブログ記事「AIコーディング時代の「セキュリティの民主化」」で紹介したWizです。

SSPMは、トークンやシークレット、OAuthアプリの可視化や棚卸しができるものを選ぶ必要があります。利用しているSaaSが多く対応している製品を選ぶことになるでしょう。

SAST+CWPPの領域でNHIの脆弱性にどこまで対応できるか

NHIの脆弱性への取り組みをNIST CSF 2.0の観点で考えるで挙げた項目がSAST+CWPP（より正確には CSPM/CIEM を含む CNAPP）の領域でどこまでカバーできるか、Wizを題材に見てみましょう。

Wizが有する機能の凡例

• CSPM：クラウド構成・資産インベントリ・設定ミスの可視化
• CIEM：IAMプリンシパルの権限分析・過剰権限・Attack Path
• CWPP：ワークロード（VM/コンテナ）のランタイム保護・脆弱性スキャン
• CDR：クラウド監査ログ等の相関による脅威検知
• SAST：リポジトリ/IaC/イメージのシークレット・脆弱性スキャン

この表でいちばん見てほしいのは、統治（GV）の行の多くが「ソリューションではなくガバナンスで対応」になっている点です。これが次の結論につながります。

NHIの脆弱性への対応の本質はガバナンスにある

前のセクションでは、Wizが、NHIの文脈でのNIST CSF 2.0の各領域に対して何ができるのかを挙げてきました。

しかし、ソリューションを用いるだけでは、統治（GV）の領域には対応できません。統治（GV）は、組織が対応する範囲を特定し、NHIのライフサイクルやリスクを測る尺度、尺度に応じた対応するレベル・強度を設定します。

これらは技術によって解決する問題ではなく、ガバナンスによって解決するものです。

Appendixとして、NHIの脆弱性を組織で統制していくための明日から使えるチェックシートを用意しました。

場当たり的にソリューションに飛びつく前に、まずは足場を固めるところから始めましょう。

おわりに

かなりの長文になりましたが、「NHI が大変！管理しなきゃ！ソリューション、ひとつください！」という地点から、NHI がどういう性質を持ち、統制・管理のうえで何から始めるべきかを、一通りつかんでいただけたのではないでしょうか。

この分野で困っている人の助けになれば幸いです。

今日はここまでです。
お疲れ様でした。

Appendix 1. 明日から使えるNHIのガバナンスチェックシート

0. 土台づくり：NHI 台帳とルールのひな形を用意する

1. 役割・責任・権限（GV.RR）

2. リスクマネジメント戦略（GV.RM）

3. ポリシー（GV.PO）

4. サプライチェーンリスクマネジメント（GV.SC）

Appendix 2. 用語集

記事に出てきた専門用語を、ここにまとめておきます。