『Software Design 2026年8月号』の第1特集「特権ID・NHI管理入門」から第3章「Non-Human Identityのリスクとセキュリティ対策」を公開します。本特集のほかの章では、本章の前提となる特権IDとNHIの定義やリスク、本章の延長線上にあるAIエージェントの認証・認可についても解説しています。ぜひ本誌にてご確認ください。
NHIとは何か
なぜ今、NHIが重要なのか
現代のIT環境において、「アイデンティティ」という概念は大きく変わりつつあります。従来、アイデンティティ管理といえば、従業員や委託先スタッフといった「人」のアカウントを管理することが中心でした。しかし近年、クラウド化やDX（デジタルトランスフォーメーション）の加速により、人間ではないアイデンティティ、すなわちNHI（Non-Human Identity：ノンヒューマン・アイデンティティ）の数と種類が爆発的に増加しています。
たとえば、アプリケーションがAPIを通じて別のサービスと連携するとき、そこには「人」は介在しません。バックグラウンドで動くバッチ処理、クラウド上のサーバーレス関数、CI/CDパイプライン、AIエージェント──これらはすべて、何らかの「認証情報」を使ってシステムにアクセスしています。その認証情報こそが、NHIの実体です。
NHIそのものはけっして新しい概念ではありません。オンプレミスのWindows環境では、Active Directory（AD）のサービスアカウントが古くから使われてきました。バッチ処理やシステム間連携、業務アプリケーションの実行アカウントとして、多くの企業のインフラを長年にわたって支えてきた存在です。
NHIが人のアイデンティティ数を大幅に上回っていることは、OWASPも「NHI Top-10 2025」の中で明示しています[1]が、その具体的な比率は調査機関によって20倍から100倍以上と大きくばらついており、NHIの実態把握の難しさを象徴しています。
従来から存在していたにもかかわらず対策が遅れてきたNHIは、AIエージェントの台頭によりさらに増加・複雑化しており、もはや無視できないリスク要因となっています。
本章では、NHIとは何か、どのようなリスクをはらんでいるのか、そしてどのように保護・管理すべきかについて、実務者の視点から体系的に解説します。
NHIの種類と特徴
NHIとは、人間に代わってシステムやサービスにアクセスするために使われる、機械・ソフトウェア向けのアイデンティティの総称です。表1に示すように、その種類は多岐にわたります。
NHIの最大の特徴は、その多様性にあります。サービスアカウントはオンプレミスのシステム実行のために使われ、IAMロールはクラウド上のリソースアクセスのために使われ、OAuthトークンはサービス間連携のために使われます。用途が違えば、利用される場所も異なります。オンプレミスのAD環境、AWS/Azure/Google Cloudといったパブリッククラウド、CI/CDパイプライン、アプリケーションのコード内──NHIは組織のあらゆる場所に存在しています。同じ「NHI」という言葉でくくられていても、その実態は非常に異質なものの集合体です。
そしてNHIのもう1つの本質的な特徴が、「人ではない」という点そのものです。人のアカウントであれば、パスワードに加えてMFA（多要素認証）を適用することで、認証情報が漏洩した場合でも不正アクセスを防ぐ手段があります。しかしNHIは人間が操作するものではないため、原則としてMFAを適用できません。APIキーやシークレットといった単一の認証情報のみで認証される構造上、その認証情報が漏洩すれば即座に悪用されるリスクと直結しています。
NHIセキュリティにおける課題：なぜ管理が難しいのか
前節で見てきたように「多様性と分散性」こそが、NHI管理を難しくしている根本的な理由です。そこから3つの構造的な課題が生まれます（表2）。
❶ 可視性の欠如
NHIがどこに何個存在するかを正確に把握できている組織は、ほとんどありません。人のアカウントであればHRシステムと連動した一元管理が可能ですが、NHIは開発／インフラ／クラウド担当など組織のあらゆる場所で個別に作成され、管理ツールや台帳も環境ごとに異なります。特にマルチクラウド／ハイブリッド環境では複数の管理ドメインにまたがるため、全体像を掴むこと自体が大きな課題です。
「棚卸しをしましょう」「一覧化しましょう」と言っても、横断的にリストアップすること自体が相当な困難を伴います。仮に棚卸しを完了しても、新しいNHIが生まれ続けるため、静的なリストはすぐに陳腐化します。
❷ ライフサイクル管理の不在
人のアカウントと同様にNHIも不要になった時点で削除・無効化されるべきですが、NHIには、人のアイデンティティでいう退社のような、わかりやすい廃止トリガーがありません。プロジェクト終了後も残るサービスアカウント、担当者異動後も放置された証明書など「休眠NHI」が組織内に静かに蓄積していきます。加えて後述するように、NHIの種別ごとに管理方法が根本的に異なるため、統一的なライフサイクル管理プロセスを構築することも容易ではありません。
❸ 権限の過剰付与
NHIには利便性優先で必要以上の権限が付与されがちです。MFAが使えないNHIにとって、過剰な権限は侵害時の被害を拡大させます。
これらの課題は独立して存在するのではなく、互いに絡み合っています。可視性がなければライフサイクル管理もできず、管理されていなければ権限の適正化も進みません。次節では、この状況を実際の攻撃者がどう悪用するかを見ていきます。
NHIにまつわるリスク：攻撃者はどこを狙うのか
前節で整理した課題は、攻撃者の視点から見ると「攻撃面（アタックサーフェス）」そのものです。本節では、OWASP NHI Top-10およびMITRE ATT&CKの観点を交えながら、NHIに固有のリスクを具体的に解説します。
OWASP NHI Top-10が示すリスクの全体像
OWASPは2024年12月、実際のインシデント事例・調査データ・CVEデータベースをもとにNHI固有のリスクをランク付けした「OWASP Non-Human Identities Top 10 2025」を公開しました。全10項目と前節で整理した3つの課題との対応は表3のとおりです。
3つの課題──可視性の欠如・ライフサイクル管理の不在・権限の過剰付与──がTop-10の全項目に対応していることからも、これらの課題がいかにNHIセキュリティの根幹に関わるかがわかります。
実際に起きたインシデント：NHIが悪用された代表的な事例
OWASP NHI Top-10は実際のインシデントから導き出されたものです。次の3つは、NHIの不適切な管理がいかに深刻な被害をもたらすかを示す代表的な事例です[2]。
Microsoft Midnight Blizzard侵害（2024年1月）
国家支援型の攻撃グループMidnight Blizzardが、Microsoftの非本番テナントへのアクセスを足がかりに、フル権限を持つレガシーOAuthアプリケーション──管理されていないNHI──を悪用して本番環境に侵入。企業のメールアカウントへの不正アクセスにより、機密性の高い通信やドキュメントが窃取されました。
Oktaサポートシステム侵害（2023年11月）
Oktaのサポートシステムで使われていたサービスアカウントの認証情報が、従業員の個人Googleアカウントに保存されていたことが発端。そのGoogleアカウントが侵害されたことで攻撃者が認証情報を取得し、134社の顧客に関するファイルへの不正アクセスが発生しました。
Internet Archive Zendesk侵害（2024年10月）
Internet ArchiveのZendeskサポートプラットフォームにひも付くアクセストークンが長期間ローテーションされていなかったことを突かれ、不正アクセスとデータ漏洩が発生しました。
MITRE ATT&CKとの対応：攻撃の流れで見るNHIリスク
MITRE ATT&CKは、攻撃者の戦術（Tactics）と技術（Techniques）を体系的にまとめたフレームワークです。世界中のセキュリティチームが脅威分析に活用しています[3]。
MITRE ATT&CKでは初期侵入・永続化・権限昇格・認証情報アクセス・探索・横展開などの攻撃フェーズ（Tactics）が定義されており、NHIはそのいずれのフェーズでも悪用され得ます。前述のインシデント事例およびNHIの課題と対応させると表4のように整理できます。
NHIの保護・ガバナンス：可視化・分析・管理・保護の現実的アプローチ
これまで見てきたように、NHIのリスクは「可視性の欠如」「ライフサイクル管理の不在」「権限の過剰付与」という3つの構造的問題に根ざしています。これを解決するガバナンス方針として、可視化→分析→ライフサイクル管理→保護という4つの層を順に解説します。ただし、それぞれの層には現実的な限界もあり、その点も含めて正直に整理します。
❶ 可視化：まず「何が存在するか」を把握する
NHIセキュリティの出発点はインベントリの確立です。組織内に存在するサービスアカウント、APIキー、シークレット、証明書、IAMロールを洗い出し、表5の属性を把握することが目標になります。
従来は「まず重要システムから優先的に把握を進める」というアプローチが推奨されてきましたが、この考え方には根本的な課題があります。可視化できていない領域は対策が打てず、そこが攻撃者のターゲットになるからです。ランサムウェアをはじめとする多くの攻撃は重要かどうかにかかわらず侵入できるところから入り横展開します。そもそもこの「重要なシステムだけを守る」という発想は、境界型セキュリティが主流だった時代のものであり、「すべてを検証する」を原則とする現在のゼロトラスト戦略とは相容れません。NHIの可視化においても同様に、「重要なところから」ではなく「すべてをカバーする」という方針への転換が求められています。
目指すべきは組織全体のNHIを包括的にカバーする可視化です（図1）。IaaSやSaaSのAPIに接続することで基盤上のNHIをほぼ漏れなく自動検出でき、AWSやAzureならIAMロール・アクセスキーの一括取得、オンプレミスのADならLDAP等での自動検出が可能です。完全な可視化を一度に達成することは難しくとも、「抜け漏れを最小化する」方針で継続的にカバレッジを広げていくことが現実的なアプローチです。
❷ 分析：NHIを分類しリスクレベルを把握する
収集されたNHIの情報を人手で精査することは現実的ではなく、自動的な分析・分類によってリスクレベルを設定することが次のステップです。中心となるのは次の2つです（図2）。
NHIの自動分類
プラットフォームから取得した情報をもとに、NHIをサービスアカウント・IAMロール・アクセスキー・トークン・証明書・シークレットなどの種別に自動マッピングし、環境全体の構成を把握しやすくします。
個別NHIの詳細分析
分類されたNHIに対して、所有者・権限・利用状況・関連するクレデンシャルといった属性を詳細に分析します。特に重要なのが、付与されている権限と実際の利用状況を継続的に照合することです。付与された権限のうち実際に使われている範囲を把握することで、過剰付与の実態が明確になります。また、オーナーが不明または退職・異動済みのNHIは、管理責任が存在しないという意味で優先的に対処すべき対象として識別されます。
❸ ライフサイクル管理とクレデンシャル管理：重要だが、過信は禁物
可視化・分析の次のステップとして語られることが多いのが、NHIのライフサイクル管理です（図3）。作成・変更・廃止のプロセス整備、所有者の明確化に加え、シークレット・証明書・APIキーといったクレデンシャルの定期ローテーションや集中管理（クレデンシャル管理）もこの層に含まれます。
しかし現実には、ライフサイクル管理とクレデンシャル管理を組織横断で一元的に実施することは非常に困難です。その理由は、NHIの種別ごとに管理方法が根本的に異なることに加え、NHIそのものの性質が人のアイデンティティとは根本的に異なるからです。
人のアイデンティティはHRシステムを源泉として属性情報を各システムに連携することで一元管理が成立します。一方NHIは利用される環境の中で個別に作成されるものであり、AWSのIAMロールはAWS環境、ADのサービスアカウントはAD環境の中で作られます。人のアカウントのように組織横断で属性を連携・管理する必要がそもそもありません。
この性質をふまえると、NHIは各プラットフォーム・環境ごとに個別に管理するほうが現実的です。実際のソリューション市場でもシークレット管理（HashiCorp Vault・AWS Secrets Managerなど）、証明書管理（Venafi・DigiCertなど）のように種別ごとに特化したツールが主流であり、統合管理は技術的には可能でも共通の属性基盤が存在しないため、コストと複雑性が大きくなりがちです。業界全体で「ライフサイクル管理が重要」と言われながらも、実際に包括的に実施できている組織はごく少数であるというのが実態です。
さらに根本的な問題として、ライフサイクル管理・クレデンシャル管理が適切に行われていても、それはセキュリティリスクの排除を意味しません。管理されたNHIであっても過剰な権限が残存することはありますし、正規の認証情報を持つAIエージェントが意図しない範囲にアクセスするリスクはライフサイクル管理では防げません。クレデンシャルの管理状況だけでNHIセキュリティの全体像を評価することは危険です。
❹ 保護：アクセスコンテキストベースのアクセス制御とExposure管理
ライフサイクル管理・クレデンシャル管理の限界を補う本質的な防御層です。可視化・分析・ライフサイクル管理はいずれも事前の備えですが、実際の攻撃をリアルタイムに防御するのはこの層の役割であり、アクセスコンテキストベースのアクセス制御がその核心です。
アクセスコンテキストベースのアクセス制御
ここで言う「アクセスコンテキスト」とは、認証・認可を包含したアクセス全体の文脈──どのNHIが・どこから・何に対して・どのような権限でアクセスしようとしているか──を指します。攻撃者はNHIの正規の認証情報を悪用して侵入・横展開します。クレデンシャルの漏洩自体は防ぎようがなくとも、アクセスコンテキストをリアルタイムに評価することで、正規の認証情報を使っていても通常とは異なる挙動（場所・時間帯・対象など）を検知・ブロックでき、被害を最小化できます（図4左）。
Claude Mythosに代表されるFrontier AIを活用した攻撃により、攻撃完了までの時間が大幅に短縮されると予想される今、リアルタイムでアクセスを評価・制御するしくみの重要性は一層高まっています。
ただし実装方法はNHIの種別によって異なります。重要なのは「コンテキストを評価してアクセスを制御する」という考え方を自組織のNHI環境に合わせて適用することです。
Exposure管理とインシデント対応
②の分析がNHI情報を取得した時点でわかること──種別・所有者・権限・利用状況──を分類・整理する静的なアプローチであるのに対し、Exposure管理は運用中のNHIの状態を動的・継続的に監視するアプローチです（図4右）。具体的には次のような状態を検知の対象とします。
- 休眠NHI：長期間使用されていないにもかかわらず有効なまま残っているNHI
- 過剰権限NHI：実際の利用範囲に対して付与された権限が過大なNHI
- 長期有効シークレット：長期間ローテーションされていない認証情報
上記のようなNHI種別に共通したExposureに加えて、各プラットフォームや環境に固有（NHI種別に特有の設定不備）のExposureも検知の対象となります。たとえばAWSのクロスアカウントIAMロールにExternal IDが設定されていない状態（Third-Party Role Missing External ID）は、正規のアクセス権を持つ代理人（SaaSベンダーなど）が第三者に悪用される形で、意図しないアカウントのリソースへの不正アクセスを許してしまう問題（confused deputy問題）を引き起こす設定不備として広く知られています。このようなプラットフォーム固有の設定ミスは、一般的なライフサイクル管理では検知できず、Exposure管理の重要な役割の1つです。
前節で取り上げたInternet Archive事例はまさにこの典型で、長期間ローテーションされていないアクセストークンのExposure状態が放置された結果、侵害につながりました。インシデント発生時には影響範囲を特定して迅速に封じ込める対応プロセスも合わせて整備することが求められます（図4）。
現実的な優先順位
完璧なライフサイクル管理・クレデンシャル管理の構築を待つより、可視化・分析と並行してアクセス制御とExposure管理を導入していくことが現実的かつ効果的なアプローチと言えます。
NHIセキュリティで求められる機能とソリューションの選び方
NHIセキュリティの市場は急速に形成されつつある段階であり、製品カテゴリーの定義や機能範囲もベンダーによって大きく異なります。前節の4層に対応する形で機能を整理し、選定の考え方を解説します。
機能カテゴリーの整理
NHIセキュリティに関連するソリューションは、前節の4層に対応する形で表6のように整理できます。
カテゴリー別の補足
① NHI発見・インベントリ管理
可視化の基盤となる機能です。オンプレミスのAD環境からクラウドのIAM等まで、環境を横断してNHIを自動発見できるカバレッジの広さが選定の核心です。
加えて、NHI同士の関係性・所有者情報・ACLやポリシーとして管理されている権限情報まで取得できるかどうかが後続の分析の精度を左右します。取得できる情報の深さと広さが製品間の大きな差別化ポイントです。
② NHI分析・リスク分類
収集したNHIの情報を自動的に分析・分類し、リスクレベルを設定する機能です。①で取得した属性情報・関連情報・権限情報を活用して、次のような分析を行います。
- 付与された権限と実際の利用状況を照合し、過剰付与の実態を明確化する
- NHI同士の関係性や所有者情報をもとに、オーナー不在や不審な連携関係を識別する
- ACLやポリシーとして管理されている権限情報を統合し、NHI全体の実効権限を把握する
③ シークレット・証明書・ライフサイクル管理
シークレット管理ではHashiCorp VaultやAWS Secrets Manager、Azure Key Vaultがあります。証明書管理ではVenafi（現Palo Alto Networks）やDigiCertなどが普及しています。前節で述べたとおり、これらはそれぞれの領域では高い完成度を持つ一方で、NHI全体を横断的に管理するものではありません。既存のアプリケーションへの導入コストや運用負荷も含めて評価することが重要です。
④ アクセスコンテキストベースのアクセス制御／Exposure管理・インシデント対応
アクセスコンテキストベースのアクセス制御は、NHIが実際に認証・認可を行う瞬間に介在し、コンテキストを評価してアクセス可否を判断する機能です。人のアイデンティティ向けのPAM（特権アクセス管理）やIDaaS[4]製品がNHI対応を拡張しているケース、NHI専用に設計された製品、ネットワークレイヤーで制御するアプローチなど実装方式が多様です。NHI種別ごとにカバレッジが異なるため、自組織の主要なNHI種別をカバーできるかを確認することが重要です。
Exposure管理・インシデント対応は、それぞれISPM（Identity Security Posture Management）・ITDR（Identity Threat Detection and Response）と呼ばれることがありますが、略語が一人歩きして「ツールを入れれば解決する」という誤解を生みやすいため本章では前面に出していません。重要なのは「NHIの露出状態を継続的に把握しインシデントに迅速に対応する」という考え方そのものです。
Exposure管理においては、NHI自体の情報だけでなく、周辺情報も含めた包括的な監視が求められます。具体的には、プラットフォームの設定情報（クラウド環境の設定不備など）、NHI同士の関係性（1つのNHIの侵害が他のNHIに波及するリスク）、そしてNHIの振る舞い（通常とは異なるアクセスパターンや時間帯）を組み合わせることで、より精度の高いExposure検知とインシデント対応が可能になります。
この領域では、主要なセキュリティベンダーはアイデンティティ脅威研究チームを設置し、日々新たな攻撃手法やExposureパターンを研究・分析しています。こうした研究成果が製品の検知ルールや脅威インテリジェンスとして反映されるため、ベンダーのリサーチ体制も製品選定の重要な評価軸となります。
SIEM[5]やSOAR[6]との連携によって既存のインシデント対応フローに組み込めるかどうかも重要な選定基準になります。
具体的なソリューションの例として、筆者が所属するSilverfortのNHI管理画面を図5に示します。ダッシュボードとして統計的な情報が表示され、さまざまな環境のNHIが可視化・インベントリ管理されています。Exposure情報もタブを切り替えることで参照できるようになっています。
ソリューション選定の考え方
製品選定にあたっては、次の3つの軸で考えることをおすすめします。
軸1：自組織のインフラ環境との適合性
自組織に存在するNHIの種別を事前に正確に把握することは、前述のとおり容易ではありません。まずは自組織が利用しているインフラ環境──AD、IDaaS、IaaS（AWS/Azure/Google Cloudなど）、SaaS、AIエージェントプラットフォーム──に対してソリューションが対応しているかどうかを確認することが現実的な出発点です。対応環境のカバレッジが広いほど、可視化の段階で取りこぼしが少なくなります。
軸2：導入容易性と既存環境との整合
既存のIAM基盤／SIEM／PAM／クラウド管理ツールとの整合性が取れていることで導入後の運用がスムーズになります。既存環境への導入しやすさと運用負荷の低さを重視することが継続的な活用につながります。
軸3：包括的なカバレッジを目指しながら段階的に機能を拡張できるか
前節で述べたとおり、NHIセキュリティは「重要なところから段階的に」ではなく「すべてをカバーする」という方針が重要です。一方で、すべての機能を一度に導入することは現実的ではありません。まず可視化・分析から始め、ライフサイクル管理・保護へと機能を拡張していく際に、一貫したカバレッジを維持できる製品・アーキテクチャを選ぶことが長期的な成功につながります。
まとめ：NHIセキュリティは「今日から始める」ものである
最後に本章の要点を整理し、読者へのアクションを提示します。
NHIセキュリティの本質を3点で整理する
第1に、NHIは今や組織が無視できないリスク要因です。従来から存在していたにもかかわらず対策が遅れてきたNHIは、クラウド化・DXの加速とAIエージェントの台頭によりさらに増加・複雑化しています。MFAを適用できないNHIの認証情報は最も脆弱なリンクです。
第2に、ライフサイクル管理・クレデンシャル管理は重要ですが、種別ごとに管理方法が異なるため一元管理は困難であり、適切に管理されていても過剰権限や異常アクセスのリスクは残ります。クレデンシャル管理だけでセキュリティ全体を評価することは危険です。
第3に、保護の核心はアクセスコンテキストの評価とExposure管理です。正規の認証情報を使った攻撃を防ぐためには、誰が・どこから・何に・どのようにアクセスしているかをリアルタイムに評価し、異常を検知・制御するしくみが不可欠です。
次の領域：AIエージェントというNHIの新たな課題
AIエージェントは自律的に判断・行動し、複数のシステムやAPIを連鎖的に呼び出す新たなNHI・新たな課題ですが、本章で解説したアクセスコンテキスト評価やExposure管理の考え方はAIエージェントにも共通する基盤となります。
今日から始めるための3つのアクション
ここで1つ強調しておきたいことがあります。アイデンティティ管理の領域では従来、「まずアセスメントをしましょう」「リストを作成してください」と、企業側に多大な手作業を求めるアプローチが主流でした。それがNHIセキュリティの導入を難しくしてきた背景の1つでもあります。人手による取り組みを否定するわけではありませんが、従来の考え方にとらわれ過ぎる必要はありません。今日のソリューションは、インフラ環境さえ把握できれば自動的にNHIを検出・分析・分類してくれます。アイデンティティセキュリティは苦行ではありません。ツールをうまく活用することで、はるかに効率的かつ効果的に取り組むことができます。
まず今日取り組めることとして、次の3つのアクションを提案します。
アクション1：自組織のインフラ環境を確認し、NHIの可視化を始める
まず自組織が利用しているインフラ環境──AD、IDaaS、IaaS、SaaS、AIエージェントプラットフォームなど──を確認してください。対応するNHIセキュリティソリューションがAPIを通じてNHIを自動的に取得・分析してくれます。手作業の棚卸しは不要です。まずは「自組織のNHIが見える状態」を目標にしてください。
アクション2：可視化されたNHIをもとにリスクを把握する
適切な可視化・分析ソリューションを導入することで、オーナーが不明なNHI、一定期間使用された形跡がないNHI、過剰な権限を持つNHIなどが自動的に識別・分類され、優先対応すべき対象が自動的に浮かび上がります。
アクション3：アクセス制御のソリューションを検討・活用する
実際の攻撃を防ぐためには、前述したアクセスコンテキストベースのアクセス制御が不可欠です。新たな専用ツールの導入を検討することも有効ですが、すでに自組織に導入済みのPAMやIDaaS、SIEMといったソリューションがNHIのアクセス制御や異常検知に対応している場合があります。まずは既存ツールの活用可能性を確認したうえで、カバーできない領域を補完するソリューションを検討するアプローチが現実的です。
NHIセキュリティへの取り組みに終わりはありません。しかし、最初の一歩を踏み出すことが、自組織のセキュリティレベルを着実に高めていく旅の始まりです。完璧を待たず、今日から動き出してください。
