NHI（Non-Human Identity：非人間アイデンティティ）とは、人間ではなくシステム・アプリケーション・ボット・AIエージェントが使用するアイデンティティの総称です。APIキー・サービスアカウント・OAuthトークン・マシン証明書などが代表例で、その数は組織内の人間アカウントの25〜50倍に達するとも言われています。しかし従来のIAMやPAM 特権アクセス管理はNHIへの対応が弱く、サイバー攻撃者にとって「見落とされやすい侵入口」となっています。本記事では、NHIの種類・セキュリティリスク・管理のベストプラクティスを詳しく解説します。
NHI（非人間アイデンティティ）とは何か
NHIの定義
NHIは、システム・サービス・アプリケーションが他のシステムやサービスにアクセスする際に使用するアイデンティティです。人間がパスワードやMFAで認証するのに対し、NHIは主に「シークレット（APIキー・トークン・証明書）」によって認証します。
NHIが必要な理由： 現代のITシステムは多数のサービスが連携して動作します。Slackがワークフローを実行する、CIパイプラインがAWSにデプロイする、マイクロサービスが互いにAPIを呼び出す。これらすべての連携に「マシンが提示するアイデンティティ」が必要です。
NHIの主な種類
| NHIの種類 | 説明 | リスク |
|---|---|---|
| APIキー | サービスへのAPIアクセスに使用する長期トークン | 漏洩・無効化されない限り永続的に有効 |
| サービスアカウント | アプリが他サービスにアクセスするためのアカウント | 過剰権限・パスワード未ローテーションが多い |
| OAuthトークン | アプリ連携の認可に使用するトークン | スコープ管理が複雑、長期有効なリフレッシュトークン |
| マシン証明書（X.509） | サーバー間通信の認証に使用するTLS証明書 | 有効期限管理の漏れ・失効処理の遅れ |
| SSHキー | サーバーへのリモートアクセスに使用する鍵ペア | 古い鍵の放置・共有利用が多い |
| シークレット（DB認証情報） | データベース接続に使用するパスワード | コードへのハードコーディングが問題 |
| AIエージェントID | 生成AIエージェントが持つアイデンティティ | 新しいリスク領域で管理手法が未確立 |
SSOだけでは不十分 SSO×IGA一気通貫
SSOだけでは防げないセキュリティリスクを明らかにし、IGAとの統合による一気通貫のID管理がなぜ必要かを解説します。
NHIが引き起こすセキュリティリスク
リスク1：コードへのハードコーディング
最も一般的かつ深刻な問題が、APIキーやパスワードをソースコードに直接記述（ハードコーディング）することです。
問題の深刻さ：
- 2024年にGitHubなどのパブリックリポジトリから約2,400万件のシークレット（APIキー・トークン等を含む）が漏洩（GitGuardian 2025年レポート）
- 一度コードにコミットされた秘密情報は、削除後もgit履歴に残り続ける
- npm・PyPIなどのパッケージに混入して配布される「サプライチェーン攻撃」の温床になる
リスク2：過剰権限（Least Privilege違反）
サービスアカウントは「とりあえず広い権限を付与してから絞る」という運用になりがちです。結果として、本来不要なデータや機能へのアクセス権限を持ち続けます。
典型的な過剰権限パターン：
- メール送信のみ必要なサービスが、メールボックス全体への読み取り権限を持つ
- 特定テーブルへの読み取りのみ必要なアプリが、DBのフルアクセス権を持つ
- 開発環境用のサービスアカウントが本番環境にもアクセスできる
リスク3：孤立したアカウント（Orphaned NHI）
プロジェクト終了・担当者退職・サービス廃止後も、対応するNHIが削除されずに残り続けます。これらの「孤立したNHI」は誰も監視しておらず、攻撃者に悪用されても気づきにくい状態です。
孤立NHIが生まれる典型シナリオ：
- プロジェクト担当者が退職し、サービスアカウントの所有者が不明になる
- システム廃止後もAPIキーが有効なまま放置される
- SaaSのOAuthアプリ連携が解除されずに残る
リスク4：MFA・多要素認証の非対応
人間のアカウントにはMFAを適用できますが、APIキーや証明書によるマシン認証にはMFAが適用できません。これが「NHIは人間IDより管理しやすいはず」という誤解と現実のギャップを生みます。
リスク5：AIエージェントによる新たなリスク
生成AIの普及に伴い、「AIエージェント」が人間の代わりに自律的にAPIを呼び出してタスクを実行するケースが急増しています。AIエージェントは通常、複数のAPIキーや権限を保持して動作するため、NHIの中でも新しい高リスク領域として注目されています。
NHI管理のベストプラクティス
ベストプラクティス1：シークレットをコードから排除する
環境変数の使用（最低限の対策）：
# NG：コードに直接記述
api_key = "sk-abc123xyz..."
# OK：環境変数から読み取る
import os
api_key = os.environ.get("OPENAI_API_KEY")
シークレット管理ツールの導入（推奨）： HashiCorp Vault・AWS Secrets Manager・Azure Key Vaultなどのシークレット管理ツールを導入し、実行時に動的にシークレットを取得する設計にします。
ベストプラクティス2：NHIの完全な棚卸しと継続的な可視化
組織内に存在するすべてのNHIを把握することが管理の第一歩です。
棚卸しで確認すべき項目：
- 誰（または何のサービス）が所有しているか
- 何のリソースへのアクセス権を持つか
- いつ最後に使用されたか
- 有効期限はいつか
- ローテーション設定があるか
ベストプラクティス3：最小権限の原則を徹底する
NHIに付与する権限は、実際に必要な最小限に限定します。
権限設計のポイント：
- 読み取りのみ必要なサービスに書き込み権限を与えない
- 特定リソースのみアクセスが必要なサービスにワイルドカード権限を与えない
- 環境別（開発・ステージング・本番）にNHIを分離する
ベストプラクティス4：定期的なローテーションと有効期限管理
ローテーションのベストプラクティス：
- 長期有効なAPIキー：最低でも90日ごとにローテーション
- OAuth Clientシークレット：定期的なローテーション（年1回以上）
- TLS証明書：有効期限の90日前からアラートを設定
- SSHキー：古い鍵（1年以上未使用）の定期削除
ベストプラクティス5：NHIのライフサイクル管理
【NHIライフサイクルの4フェーズ】
1. プロビジョニング
- 最小権限での作成
- 所有者・目的・有効期限の記録
- 承認フローの実施
2. 継続的なモニタリング
- アクティビティログの監視
- 異常な使用パターンの検知
- 未使用NHIのアラート
3. ローテーション・更新
- 定期的な認証情報更新
- 自動ローテーションの設定
- 証明書更新のアラート
4. デプロビジョニング
- プロジェクト終了時の即時無効化
- 担当者退職時の移管・無効化
- 孤立NHIの定期クリーンアップ
NHIとISPM・ITDR・PAMの関係
NHIとPAMの関係
従来のPAMは人間の特権アカウント管理に特化していましたが、最近では「NHI対応PAM」として機能を拡張するベンダーが増えています。
| 管理対象 | 従来のPAM | NHI対応PAM |
|---|---|---|
| ドメイン管理者 | 対応 | 対応 |
| サービスアカウント | 一部対応 | 完全対応 |
| APIキー | 非対応 | 対応 |
| OAuthトークン | 非対応 | 対応 |
| AI エージェントID | 非対応 | 対応（新機能） |
NHIとISPMの関係
ISPMの主要スコープにNHIが含まれています。ISPMはNHIの設定ミス・過剰権限・孤立アカウントを継続的に検出・評価する役割を担います。
NHIとITDRの関係
ITDRはNHIへの攻撃（APIキーの不正使用・サービスアカウントの権限昇格）をリアルタイムで検知する役割を担います。
NHI侵害の典型的な検知シグナル：
- APIキーが通常とは異なる地域・IPから使用される
- サービスアカウントが突然大量のリソースにアクセス
- 深夜に特定のサービスアカウントが異常な操作を実行
NHI市場の動向：急速に拡大する管理ニーズ
NHIの急増と管理の複雑化
- 企業内のNHI数は人間IDの25〜50倍に達する
- 約67%の企業がNHI起因のサイバー攻撃を経験（ESG 2024年レポート）
- AIエージェントの普及により、今後さらに急増する見込み
Non-Human Identity Management Group（NHIMG）
2024年に設立されたNHIMGは、NHIセキュリティの標準化・ベストプラクティスの策定を目指すコミュニティです。セキュリティ業界の実践者・研究者を中心に多数のメンバーが参加しており、CrowdStrikeやOkta、CyberArkなどのベンダーも関与しています。
LOCKED MSOとNHIセキュリティ
LOCKED MSOはIAM・SSOを中心としたソリューションですが、NHIセキュリティとの関係で以下の役割を果たします。
- OAuthアプリ管理：従業員がSaaSに接続した外部アプリの一元管理・承認
- APIアクセス制御：条件付きアクセスポリシーでAPIアクセスの制御
- シャドーITの可視化：従業員が無断で作成したOAuth連携の検出
SaaSへのNHI（OAuth連携・APIキー）を管理する起点として、LOCKED MSOが活用できます。
LOCKEDの詳細を見る SaaSのアイデンティティ管理はLOCKED MSOにご相談ください。 資料請求・デモ依頼はこちら →
まとめ：見えないNHIが最大のセキュリティリスクになる
| 課題 | 解決策 |
|---|---|
| コードへのハードコーディング | シークレット管理ツールの導入 |
| 過剰権限 | 最小権限の原則を徹底 |
| 孤立したNHI | ライフサイクル管理・定期棚卸し |
| MFA非対応 | 代替手段（短期トークン・証明書）で補完 |
| AIエージェントID | 新しい管理フレームワークの構築 |
NHIは現代のIT環境に不可欠な存在ですが、適切に管理しなければ「見えない攻撃面」となります。人間のIDと同等以上の厳格な管理を、今すぐ始めることが重要です。