非人間ID（NHI）とは？種類・リスク・保護のベストプラクティスを解説

クラウド利用、マイクロサービス化、CI/CD、AIエージェントの活用が進むほど、人ではなくシステム同士がやり取りする場面が急増しています。その裏側で急増しているのがNHI（非人間ID）であり、今や攻撃者に狙われやすい”IDセキュリティの盲点”となりつつあります。

近年は、AIエージェントや自動化の普及に伴い、企業内で人間のIDを上回る数のNHIが存在するケースも増えています。業界調査では、今後NHIを標的とした攻撃や認証情報の悪用リスクが拡大すると予測されています。

本記事では、NHIが注目される背景、代表的な種類、リスク、そして 保護・運用のベストプラクティスまでを整理して解説します。あわせて、 AIエージェント時代のNHI管理を実現するプラットフォームとして 注目される「Token Security」もご紹介します。

▶ Token Security の詳細はこちら
AIエージェント時代のNHI管理を一元化するプラットフォームです。

近年、生成AIやAIエージェントの普及により、企業システム内で自律的に動作するアプリケーションやサービスが急速に増えています。

なぜ今、NHIが注目されているのか

クラウド連携や自動化が進むほど、人が直接触れない認証主体（NHI）が急増し、IDセキュリティの盲点になりやすい点が注目されています。

近年のシステムは、人がログインして操作するより先に、システム同士がAPIで会話し、バッチが定期実行され、CI/CDが自動でデプロイし、監視やバックアップも自動で動きます。その「自動で動く主体」に必要なのがNHIで、気付かないうちに数が増えやすいのが特徴です。

問題は、ユーザーIDは入退社や端末管理、MFA、アクセスレビューといった統制が効きやすい一方で、NHIはプロジェクト単位で作られ、運用に埋もれ、誰の責任か曖昧になりがちな点です。結果として、棚卸しされない特権NHIや、古い連携のための秘密情報が残り続けます。

攻撃者の観点では、NHIは人間よりも監視が薄く、権限が強めで、しかも止めづらいという「おいしい条件」が揃いがちです。IDセキュリティを本気で強化するなら、ユーザーIDだけでなくNHIを同じ重要度で可視化・管理することが出発点になります。

NHIの主な種類

NHIは「アカウント」「秘密情報（シークレット）」「鍵・証明書」「クラウドIAMの権限主体」など複数の形で存在し、用途や管理方法が異なります。

NHIという言葉は一つでも、実体はさまざまです。アカウントとして存在するものもあれば、APIキーやトークンのように「秘密情報」だけが独立して配られている場合もあります。まずは種類ごとに、どこで生まれ、どこに保存され、何に使われているかを整理するのが管理の第一歩です。

多くの現場では、NHIが複数の管理領域に分散します。クラウドIAM、SaaS管理画面、Kubernetes（コンテナ運用基盤）、CIツール、コードリポジトリ、端末内の設定ファイルなどに散らばるため、単一の台帳がないと全体像がつかめません。種類を押さえることで、探索すべき場所と優先度が明確になります。これらを横断して自動的に洗い出す仕組みについては、Token Security の製品ページで実際の一覧画面をご覧いただけます。

サービスアカウント

サービスアカウントは、アプリやバッチ、連携ジョブがシステム間通信やリソース操作を行うためのアカウントです。人が日常的にログインする前提がないため、パスワード無期限、MFAなし、広めの権限といった設定になりやすく、放置されると強い侵入口になります。

作成経路は、手動で作ったものだけではありません。アプリケーションをデプロイしたときや、新しいツールを導入したときに、自動で発行されるものも多くあります。自動生成は便利な反面、どのチームが所有しているのか、どの環境で使うのかが記録に残らないまま放置されやすい点に注意が必要です。

典型的な落とし穴は「とりあえず動かすために強い権限を付与して、そのまま」になることです。運用が回り始めると権限を絞る機会が失われ、結果的に特権化したサービスアカウントが長期にわたり常駐します。用途を明確化し、必要最小限の権限に分解する設計が重要です。

APIキー・トークン

APIキーやトークンは、API利用者（多くはシステムやアプリ）を識別・認可するための秘密情報です。IDそのものというより「入場券」に近く、漏えいすると本人確認なしで悪用される点がリスクになります。

発行・配布・保管・期限・スコープが管理の要点です。特にスコープは、どのAPIや操作まで許すかの境界線なので、広すぎるスコープのトークンは一つの漏えいで被害が跳ね上がります。可能な限り操作単位で絞り、期限を短くし、再発行しやすい仕組みに寄せます。

漏えい経路として多いのは、コードへの埋め込み、設定ファイルの平文保存、CIのログ出力、誤って公開リポジトリにコミット、ストレージの公開設定ミスなどです。対策は「秘匿すべき場所に集約する」「ログに出さない」「短命化と失効手順を整える」の三点をセットで実装することが現実的です。

証明書・鍵（SSH鍵・TLS証明書）

証明書・鍵は、暗号鍵や証明書を使って認証（SSH）や通信の真正性・暗号化（TLS）を実現する仕組みです。パスワードより堅牢に見えますが、運用次第で大きな弱点にもなります。

運用の核心は、有効期限と失効、再発行の手順です。TLS証明書は期限切れがそのままサービス障害になり得るため、セキュリティだけでなく可用性の観点でも管理対象です。SSH鍵も、退職者の鍵が残っていたり、古いサーバーに鍵を配ったまま放置されていると、後から回収しようにも所在をたどれず、リスクだけが残り続けます。

とくに危険なのは共有鍵です。複数のシステムや担当者で同じ秘密鍵を使い回すと、誰が使ったか追えず、漏えい時に影響範囲が読めません。鍵は原則として個別に発行し、保管場所を限定し、必要ならハードウェアや専用ストアで保護し、棚卸しと入れ替えを前提に運用します。

クラウドIAMのロール・ワークロードID

クラウドでは、AWSのIAMロール、Google CloudのWorkload Identity連携、Azureのマネージド IDのように長期鍵を持たず短期クレデンシャルで動かせる仕組みが整っています。これはNHI管理の理想形に近く、漏えいしても有効期間が短く、実行環境に結び付けて発行できるのが強みです。

ここでのポイントはフェデレーション（ID連携）と実行環境の結び付けです。Kubernetesのサービスアカウント、サーバレス関数、VMなど「どこで動いているワークロードか」を条件にして権限を渡すことで、単なる秘密情報の配布より安全に設計できます。

ただし、ロールの権限設計が雑だと意味がありません。ワイルドカード権限や管理系操作を含むロールを複数ワークロードで共有すると、一つの侵害が広範囲に波及します。短期クレデンシャルの利点を活かすには、ロールを用途別に小さく分け、条件付きで絞り込むことが前提になります。

発行から失効までのライフサイクル

NHIは作成されて終わりではなく、発行・配布・利用・更新・失効という一連のライフサイクルを通じてリスクが変化します。

NHIのリスクは「存在していること」よりも「どう扱われているか」で決まります。作成時に誰が何の目的で発行したかが残らないと、後から権限の妥当性や廃止判断ができません。

ライフサイクルは大きく、発行、配布、保管、利用、監査、更新（ローテーション）、失効（廃止）で考えると整理しやすいです。弱くなりやすいのは配布と保管で、メールやチャット、チケットに貼られたキー、開発者PCのローカル保存、CI変数の乱立などが温床になります。

もう一つ重要なのは「最終使用日」と「依存関係」です。使われていないNHIは最優先で廃止したくなりますが、実際は月次処理や障害時のみ動くジョブもあります。まず利用実態をログで把握し、段階的に無効化テストを行うことで、業務影響を抑えながら整理できます。

人間のアイデンティティとの違い（比較表）

人間IDは、本人確認、雇用関係、端末、上長承認、退職時の停止といった「統制の前提」があります。加えて、不審なログインがあれば本人に確認でき、パスワード変更やMFA再設定も比較的進めやすいです。

一方NHIは、本人という概念がなく、24時間無人で動き続けます。止めるとサービスが止まるため、緊急時でも即時停止しにくく、過剰権限のまま温存されやすい傾向があります。さらに、例外的な権限付与が積み重なっても、利用者体験の悪化が見えにくいので是正されにくい点が落とし穴です。

だからこそNHIは、技術より運用設計が勝負です。所有者、目的、期限、実行環境、権限範囲、ローテーション方法を最初から決め、ユーザーIDと同等かそれ以上に「誰が責任を持つか」を明確にしておく必要があります。

管理不備が招くセキュリティリスク

NHIの漏えい・乗っ取りは、静かに権限を広げられやすく、侵害範囲の拡大（横展開）やサプライチェーン影響につながります。

NHIが侵害されると、攻撃は目立たない形で進みやすくなります。人間のアカウント乗っ取りはMFAや不審ログインで気付きやすい一方、NHIのAPI呼び出しは「普段の自動処理」に紛れやすく、検知が遅れがちです。

さらに、NHIはシステム間の橋渡し役であることが多く、侵害されると横展開が起きやすいです。たとえば、CIのトークンが漏れるとリポジトリ改ざんからビルド成果物に悪意あるコードが混入し、デプロイ先のクラウド権限まで連鎖的に広がる可能性があります。

影響は自社内に留まらないこともあります。取引先APIへのアクセスキー、SaaS連携のトークン、データ連携基盤の資格情報が侵害されると、サプライチェーンとして他社に影響を及ぼすケースもあります。NHIは便利な連携を作るほど、同時に「侵害時の伝播経路」も作ってしまう点を意識する必要があります。

なぜ保護が難しいのか？3つの理由

NHIの管理が難しいのは、数が多いことに加えて、作られる場所がバラバラで、しかも簡単には止められないという事情が重なるためです。

まず、増えるスピードに対して減らす手段がありません。プロジェクトが立ち上がるたびに環境が増え、その環境ごとにサービスアカウントやトークンが発行されます。作った担当者が異動しても、有効期限が設定されていなければそのまま残り続けます。

次に、発行元も利用先も分散しています。クラウド、Kubernetes、CI/CD、SaaS、オンプレのジョブスケジューラと、管理画面も管理責任者も別々です。台帳が一本化されていない状態で棚卸しをしようとしても、そもそも全体像が見えません。

そして、止めづらいという問題があります。ローテーションの手順が決まっていないと、「更新して業務が止まったら困るから触らない」という判断になり、古い鍵や過剰な権限がそのまま固定化します。

だからこそNHI保護は、あるべき論を並べるだけでは前に進みません。既存の業務を壊さずに、少しずつ改善できる手順へ落とし込めるかどうかが分かれ目になります。

保護のベストプラクティス4選

NHIの保護は「最小特権」「シークレットの安全な保管と更新」「監査と検知」「所有者と棚卸し」を運用に落とすことが要点です。

NHI対策は、単発の設定変更ではなく運用の型を作ることが効果的です。特に、NHIは数が多いので、例外が増えるほど運用は回らなくなります。基本方針を少数に絞り、ツールと自動化で守らせる設計が向いています。

優先順位としては、まず可視化です。どこに何があるかを洗い出し、そのうえで「どれから手を付けるか」を決めます。次に、長期間使い回している秘密情報を短期化へ切り替えます。どうしても長期のまま残るものは、保管場所を限定し、ローテーションを強制します。運用ルールで「気をつける」のではなく、期限が来たら自動的に回る状態にしておくことが肝心です。

そして最後に、監査ログとアラートで日々のズレを拾い、定期的な棚卸しで整理し続けます。

ゼロトラストと最小特権を徹底する

最小特権は「権限を減らす」だけではなく、「用途を分ける」ことが本質です。1つの強いNHIに集約するのではなく、ジョブ単位・サービス単位でロールを分割し、必要な操作だけ許可する設計にします。

条件付きアクセスも有効です。実行元（特定のVPC、特定のKubernetesクラスタ、特定のサーバレス）や時間帯、ネットワーク条件で縛ると、秘密情報が漏れても使える場所を狭められます。可能なら長期鍵を配らず、実行環境に紐づく短期クレデンシャルやフェデレーションに寄せるのが安全です。

特権分離も欠かせません。デプロイ用、読み取り用、運用変更用などを分け、日常処理が管理権限を持たない形にします。攻撃者はまず横展開の足場を探すため、足場になりやすい特権を常駐させないことが防御力になります。

シークレット管理と自動ローテーションを行う

シークレットはSecrets ManagerやVaultなどの専用基盤に集約し、コード、CIログ、コンテナイメージへ埋め込まない運用を徹底します。埋め込みは便利ですが、複製が増えて回収不能になりやすく、結果として漏えい時の対応が遅れます。

ローテーションは「定期」だけでなく「イベント駆動」を準備するのが実務的です。たとえば、担当者変更、リポジトリ公開ミス、侵害疑いなどのタイミングで即時に失効と再発行ができると、被害を最小化できます。

重要なのは手順の標準化です。更新しても壊れないよう、参照元を一箇所に寄せ、アプリ側は再起動やホットリロードで追従できる形にします。ローテーションできないシークレットは、長期的には負債として残り続けるため、優先的に設計改善の対象にします。

監査・可視化と異常検知を行う

まずNHIの棚卸し台帳を作り、ID名、用途、所有者、発行元、権限、期限、最終使用日、呼び出し元を記録します。ここが曖昧だと、改善が進んでも「どれが残課題か」を説明できず、運用が形骸化します。

次に、利用状況と権限の過剰付与を継続的に見ます。たとえば、長期間未使用のNHI、管理系APIを含む権限、全リソース対象のワイルドカードなどは、優先的に是正すべきシグナルです。

異常検知は、NHIの「いつも通り」を基準にすると効果が上がります。不審なIPやリージョン、時間帯、急激な呼び出し増、普段触らないリソースへのアクセスなどをアラート化し、調査から一時遮断、失効、再発行までの流れを事前に決めておくと、インシデント時に迷いません。

オーナーシップと棚卸しを運用に組み込む

NHIは技術資産であると同時に、責任の所在を決めるべき運用資産です。作成時に責任者、目的、有効期限、利用環境、更新方法を必須項目にし、未入力なら発行できないようにすると、後工程の棚卸しコストが大きく下がります。

退役（廃止）プロセスを用意し、使われなくなったNHIを確実に消せるようにします。いきなり削除ではなく、無効化の段階を挟み、影響がなければ削除する流れにすると安全です。例外的に残す場合も、期限と再レビュー日をセットにし、永続例外を作らないことが重要です。

仕組みで防ぐ工夫も有効です。IaC（インフラ設定をコードで管理する手法）やCI（コード変更時に自動検査を行う仕組み）にチェックを組み込むと、運用が回りやすくなります。過剰権限の検出、期限なしシークレットの禁止、公開リポジトリへのシークレット混入検知などを自動化し、人手のレビューに頼り切らない仕組みにします。

NHI管理（NHIM）とISPMの考え方

NHI対策について調べていると、「NHIM（Non-Human Identity Management）」や「ISPM（Identity Security Posture Management）」という言葉を目にする機会が増えています。

これらは単なる製品カテゴリではなく、急増するNHIを継続的に可視化・管理し、リスクを把握・改善するための考え方やアプローチを指します。

NHIを継続的に把握・分析・制御するために、NHIM（Non-Human Identity Management）やISPM（Identity Security Posture Management）の枠組みで運用を設計する考え方があります。

NHIMは、非人間IDを人間IDと同じくらい重要な対象として、発行から廃止までを管理する考え方です。目的は単なる台帳作りではなく、NHIの増加に合わせて「継続的に健全性を保つ」ことにあります。

ISPMは、IDセキュリティの状態を継続的に評価し、リスクを優先順位付けして改善する枠組みです。NHIに当てはめると、過剰権限、期限切れ間近の証明書、未使用NHI、公開範囲の広いトークンなどをスコアリングし、改善の順番を明確にするアプローチになります。

現場で効くのは、完璧な統制を目指すよりも、可視化と優先順位付けで「危ないものから直す」運用を回すことです。NHIは数の勝負になりやすいため、定量的に見える化し、改善が進んでいる状態を作ると継続しやすくなります。

AI・自動化時代の新たな攻撃面

AIエージェントや自動化連携が増えるほど、短命なトークンや多数の統合が生まれ、設定ミス・過剰権限・漏えい経路が新たな攻撃面になります。

AIエージェントやワークフロー自動化は、複数のSaaSや社内APIを横断して実行するため、NHIを前提にした設計になります。連携が増えるほど、必要な権限も増え、どこか一箇所の設定ミスが全体の侵入口になり得ます。

また、短命トークンが増えると「短いから安全」と思いがちですが、実際には発行経路や保管経路が弱いと同じです。トークンが生成されるログ、デバッグ出力、エージェントの設定ファイル、コネクタの権限設定など、漏えいポイントが増えることが新しい攻撃面になります。

対策としては、エージェントや自動化基盤に渡す権限を最小化し、実行環境を限定し、監査ログを必ず残すことが基本です。便利さを優先して万能トークンを渡すと、AIの導入がそのまま特権NHIの増殖になってしまうため、最初にガードレールを敷くことが重要です。

NHIの実例（クラウド・CI/CD・SaaS）

どこにNHIが潜んでいるかを具体例で把握すると、可視化・棚卸し・統制の優先順位が付けやすくなります。

クラウドの例では、サーバレス関数がストレージにアクセスするためのロール、KubernetesのワークロードがクラウドAPIを呼ぶためのワークロードID、バックアップツールがスナップショットを作る権限などがNHIです。これらは環境に密接で、削除や変更が運用に直結するため、所有者と用途の記録が欠かせません。

CI/CDでは、リポジトリに紐づくデプロイトークン、アーティファクト格納先の資格情報、パッケージレジストリの公開鍵、外部サービス連携のWebhook署名鍵などが代表例です。CIは権限が強くなりやすく、漏れると改ざんが連鎖するため、最小特権とローテーション、監査の優先度が高い領域です。

SaaSでは、CRMや会計、チケット管理、チャットのボットトークン、連携アプリのOAuthクライアント、SCIM連携用のトークンなどが該当します。退職や組織変更の対象になりにくい一方で、ビジネスデータに直結するため、棚卸しと期限設定、不要連携の削除を定期的に行うことが現実的な対策になります。

まとめ

NHIは現代のシステム運用に不可欠である一方、数と分散ゆえに見落とされやすく、管理不備が重大インシデントの起点になり得ます。

NHIは、人が見ないところでシステムを動かすための重要なIDであり、クラウド化・自動化が進むほど増え続けます。その一方で、所有者不明、期限なし、過剰権限、埋め込みシークレットといった状態になりやすく、攻撃者に狙われやすい領域です。

対策の柱は、種類を押さえて可視化し、最小特権と短期クレデンシャルを基本にし、シークレット管理とローテーションを運用に落とし、監査と異常検知で継続的にズレを直すことです。