非人間のアイデンティティ（NHIs）の解説と保護方法

ほとんどの組織は、環境内で稼働している非人間のアイデンティティ（NHIs）を完全な棚卸しとして把握できません。サービスアカウント、API キー、アプリケーションの認証情報は、Active Directory（AD）やクラウド環境全体にわたって蓄積されがちで、明確な所有者、記録された目的、または定義されたレビューサイクルがない場合も多くあります。

このギャップには現実のリスクがあります。 Netwrix 2025 Cybersecurity Trends Report によると、昨年は 46% の組織がアカウントの侵害を経験しており、2020 年の 16% から増加しています。サービスアカウントやトークンのようなマシン対マシン（machine-to-machine）のアイデンティティが、この傾向を押し上げる要因として拡大しており、ほとんどのミッドマーケットの IT チームはそれらを効果的に管理するための可視性を持っていません。

サイバーセキュリティにおける非人間のアイデンティティ（NHIs）とは何ですか？また、なぜ重要なのでしょうか？

非人間のアイデンティティ（NHIs）とは、人の介入なしに、マシン、アプリケーション、そして自動化されたプロセスが認証を行い、リソースにアクセスできるようにするデジタル証明書（デジタルクレデンシャル）です。サービスアカウント、API キー、マネージドアイデンティティ（managed identities）、OAuth トークン、そして AI エージェントはすべて NHI の枠組みに含まれます。

その数は急速に増えています。すべてのクラウドリソース、CI/CD パイプライン、自動化ワークフロー、AI 統合によって、資格情報と権限が必要な新しい NHI（非人間のアイデンティティ）が生まれます。多くの組織では、機械（マシン）アイデンティティが人間のユーザーより 10:1 以上 という比率で多くなっています。

バックアップソフトウェアが午前2時にデータベースへ接続するとき、パスワードをタイプ入力することはありません。保存された資格情報を使うサービスアカウントで認証します。これが NHI です。同様に、チケット発行システムが CRM データを取得するために使う API キーや、従業員レコードを Entra ID に同期する OAuth トークンにも当てはまります。

Netwrix のチーフ・プロダクト・オフィサー（Chief Product Officer）である Jeff Warren が『2025 Cybersecurity Trends Report』で指摘したとおり、アイデンティティ主導の攻撃はさらに主流になる可能性が高く、「サービスアカウントやトークンのようなマシン・ツー・マシンのアイデンティティの悪用」が新たな攻撃ベクトルとして挙げられています。

人間のアイデンティティと非人間のアイデンティティ

人間のアイデンティティと非人間のアイデンティティでは、所有（運用責任）、認証、管理、監視の方法が異なります。

• 所有権： 人の身元には明確なオーナーがいます。NHI では、所有権が共有されたり不明確だったりすることが多く、その結果、説明責任（アカウンタビリティ）を強制するのが難しくなります。
• 認証： 人はパスワードに MFA を組み合わせて使用します。NHI はキー、トークン、証明書を使用し、MFA は適用されません。
• ライフサイクル： 人の身元は、人事主導のプロセス（オンボーディング、役割変更、オフボーディング）に従います。NHI は、同等のライフサイクル管理なしで、開発者や管理者によって必要に応じて（ad hoc）作成されます。
• 行動： 人のアクセスはインタラクティブで変動があります。NHI のアクセスはプログラムによるもので反復的なため、異常検知は基準値（ベースライン）を作りやすい一方で、大規模におけるレビューは難しくなります。

パスワードポリシー、MFA、SSO、アクセスレビューは NHI にそのまま適切に当てはまりません。そのため、機械（マシン）アイデンティティには独自のガバナンスアプローチが必要です。

関連用語の「machine identity（マシンアイデンティティ）」は、サーバー、VM、証明書などのインフラ層のアイデンティティを具体的に指します。NHI はさらに広く、これらに加えて、API キー、トークン、ボットといったアプリケーション層の資格情報も含みます。

非人間のアイデンティティ認証方法

NHI は対話型のログインではなく、プログラムによって認証を行います。主な方法は4つです。

• トークンベース： API キー、ベアラートークン、JWT トークン
• キー ベース： SSH キーとサービスアカウントキー
• 証明書ベース： X.509 証明書と相互 TLS（mTLS）
• ワークロード ID フェデレーション： AWS IAM ロール、Azure マネージド ID、GCP サービスアカウントなどのクラウドネイティブの仕組み

4つすべてに共通する致命的なリスクは、MFA と SSO が適用されないことです。認証情報が侵害された場合、悪用を防ぐための2つ目の要素がなくなり、攻撃者はそのアイデンティティが持つアクセス権をそのまま引き継ぎます。

非人間のアイデンティティの代表的な種類

環境内のさまざまな種類の NHIs を理解することは、それらを効果的に管理するための最初のステップです。以下のカテゴリは、オンプレミス環境とクラウド環境の両方で遭遇する最も一般的な非人間のアイデンティティを示しています。

1. サービスアカウントとアプリケーションのアイデンティティ

サービスアカウントは、人間の認証情報なしでアプリケーションがタスクを実行できるようにする専用アカウントです。バックアップソフトウェアはこれを使用して SQL Server データベースにアクセスし、監視ツールはこれを使用してパフォーマンスデータを収集します。AD 環境では、これらは ServicePrincipalName (SPN) 属性によって識別されます。

最大のセキュリティ課題は、パスワードがほとんど変更されないことです。現在のベストプラクティスは Group Managed Service Accounts (gMSAs) に移行することです。これにより Active Directory を通じてパスワードの自動管理が提供され、手動での管理者介入を不要にします。

アプリケーションのアイデンティティは、この考え方をクラウドネイティブ環境へ広げます。クラウドプラットフォームが、API、データベース、その他のクラウドリソースにアクセスするために、アプリケーションへ専用のアイデンティティを割り当てるのです。

2. API キーとシークレット

API キーとシークレットは、同じ基本的な役割を果たします。つまり、人が関与せずに 1 つのシステムが別のシステムに対して認証できるようにするものです。これらは社内ツール、SaaS の統合、そしてサードパーティのサービス接続に組み込まれており、誰かがログインする必要なくプログラムによるアクセスを可能にします。

この第三者のカテゴリーは、多くのチームが思っているよりも幅広いものです。たとえば、プリンターが消耗品の監視のために製造元と通信するときや、製造設備が遠隔保守のために OEM（相手先メーカー）へテレメトリを送信するとき、こうした接続は、組織の境界を越えて認証を行う API キーまたは埋め込まれた認証情報に依存しています。これらのベンダー管理の NHIs は、IT チームではなくベンダーによって提供（プロビジョニング）されるため、標準的な ID ガバナンスの範囲外になりがちです。

これらすべてに共通する課題は、その「静的（st atic）」な性質です。ユーザーアカウントに紐づくパスワードと違って、ほとんどのシステムでは API キーは既定では期限切れにならず、設定ファイル、コードリポジトリ、環境変数、さらにはチャットのログにまで残ってしまいがちです。

金庫（vault）や設定ファイルに保存されているシークレット、たとえばパスワード、接続文字列、暗号化キーについても同じです。これらの認証情報は、どの API キーと同様のアクセスリスクを持つ一方で、見直し（精査）されることが多くの場合より少ないのが実情です。

いったん漏えいすると、これらの資格情報はどれも直ちに悪用可能になり、組織は実際に使われるまで「すでに誰かに露出していた」ことに気づかないことがよくあります。侵害された資格情報が第三者の統合に属している場合、影響範囲は自社環境の外へ広がり、NIS2 や DORA のような枠組みによって管理されるベンダーとの取引関係にまで及びます。これらはいずれも、デジタルサービスの依存関係に対してサプライチェーンのリスク管理を義務付けています。

3. Managed identities

Managed identities は、Azure における NHI 認証のための Microsoft のモダンなアプローチを表します。システム割り当ての Managed identities は、特定の Azure リソースに直接紐づけられるため、資格情報を完全に保存する必要がなくなります。ユーザー割り当ての Managed identities は、複数のリソース間で共有できます。

ただし、Managed identities が解決できるのは Azure のエコシステム内の問題に限られます。ハイブリッド環境を運用している組織では、Managed identities ではカバーできないオンプレミスのサービスアカウントやクロスプラットフォームの資格情報について、可視性を確保する必要があります。

4. OAuth tokens

OAuth トークン アプリケーション間で委任されたアクセスを可能にします。HR プラットフォームが従業員データを identity provider に同期する場合、またはレポート ツールが SaaS CRM からレコードを取得する場合、その接続は持続的なアクセスを維持するために OAuth refresh tokens に依存します。

これらのトークンは、意図したよりも寿命が長いことが多く、チームがより多くのツールを組み合わせるほど、SaaS 統合全体で蓄積されていきます。

5. クラウドのワークロードとコンテナのアイデンティティ

ワークロードのアイデンティティには、コンテナ化されたアプリケーション、サーバーレス関数、クラウドのワークロードに割り当てられる資格情報（credentials）が含まれます。Kubernetes のデプロイ、Azure Container Instances、AWS Lambda 関数はいずれも、他のサービスにアクセスするために資格情報が必要です。

クラウド プラットフォームは、VM、コンテナ、サーバーレス関数、Kubernetes pods などのこれらのワークロードに対して、クラウド リソース、ストレージ、API へアクセスするためのアイデンティティを割り当てます。これらのワークロードのアイデンティティは、作成と削除が非常に速く行われるため、セキュリティ チームが追跡できる速度を上回ってしまうことがよくあります。

6. マシンとデバイスのアイデンティティ

物理マシンと仮想マシン、IoTデバイス、インフラストラクチャの構成要素はすべて、それぞれ独自のアイデンティティを持ちます。証明書はこれらのマシンのアイデンティティを認証することが多く、アプリケーションレベルの資格情報と重なりながらも、それを超えて拡張する NHI のガバナンス層を構築します。IoT の導入が拡大するにつれて、このアイデンティティの数も増え続けます。

7. ボットと AI エージェント

ボットと AI エージェント は、最も新しく、かつ最も急速に拡大している非人間のアイデンティティのカテゴリです。たとえば：

• Microsoft Copilot が役に立つには、ファイルとメールへのアクセスが必要です
• ロボティック・プロセス・オートメーション（RPA）ボットは、業務アプリケーションとやり取りするために認証情報（credentials）が必要です。
• CI/CD ボットはコードをデプロイするためにアクセス権が必要です。
• オーケストレーション・ツールや AI エージェントは、非人間のアイデンティティとして動作し、オートメーションのワークフローを実現するために、しばしば幅広いアクセス権限を持ちます。

これらのいずれも、他の NHI と同様のガバナンスが必要となるアイデンティティの関係を作り出しますが、セキュリティレビューなしで業務チームによって迅速にプロビジョニングされることがよくあります。

追加されるリスクは、AI ツールがコードリポジトリや開発環境とやり取りすることです。これにより、プロンプト、出力、ログの中に認証情報（credentials）が意図せず露出してしまう可能性があり、従来のシークレットスキャンでは必ずしも検知できない情報漏えいの経路（leak vectors）が生まれます。

これらの各アイデンティティ タイプには異なる管理アプローチが必要ですが、すべてに共通するガバナンス上の課題があります。所有権の追跡、資格情報のローテーション、そして不要になった時点での廃止です。

環境内の非人間（ノンヒューマン）アイデンティティを検出する方法

NHIs（ノンヒューマン・アイデンティティ）をガバナンスする前に、まずそれらを見つける必要があります。構造化された検出プロセスは問題の範囲を理解するのに役立ちますが、多くの組織はすぐに、手作業のアプローチでは表面をかすめるだけだと実感するでしょう。

まずはアイデンティティ プロバイダーから始めましょう

Active Directory で、サービス プリンシパル名（Service Principal Names）を持つアカウント、スタンドアロンのマネージド サービス アカウント、およびグループのマネージド サービス アカウントを検索します。

クラウド環境では、アイデンティティ プロバイダーの管理コンソールから、サービス プリンシパル（service principals）、アプリ登録（app registrations）、マネージド アイデンティティ（managed identities）の棚卸し（inventory）を取得します。各アイデンティティについて、次の4つの属性に注目してください。どのアプリケーションがそれを使っているか、どの資格情報（credentials）を保持しているか、どのリソースにアクセスできるか、そして誰がそれを所有しているか（who owns it）です。

コードと自動化レイヤまで拡張する

DevOps チームと連携して、CI/CD パイプライン設定、Infrastructure-as-Code テンプレート（インフラストラクチャー・アズ・コード）、環境変数に保存されている資格情報（credentials）を特定します。リポジトリのスキャン ツールは、バージョン管理（version control）にコミットされたハードコードされた資格情報や API キーを検出・フラグ付けできます。これは、多くの場合、追跡されていない NHIs が最も多く潜んでいる場所です。

SaaS の統合を監査する

SaaS アプリケーション全体で OAuth の許可（grants）と API 接続を見直してください。多くの組織では、数か月または数年前に、すでにチームや会社を離れた人によってセットアップされた統合から、十数〜数十個のアクティブな OAuth トークンが見つかることがあります。

見つけた内容を文書化する

見つけたすべての NHI について、所有者（チームではなく個人）、業務上の正当性、資格情報の種類とローテーションの状態、そして「まだ必要かどうか」を誰かが最後に検証した時点を記録してください。このインベントリは、以降に行うすべての取り組みの土台になります。

重要な注意点があります。手動での検出では、稼働中のインベントリではなく、ある時点のスナップショットしか得られません。環境は毎日変わり、四半期ごとのエクスポートでは、先週の火曜日に誰かが作成したサービスアカウントを見逃してしまいます。

継続的で自動化された検出があるかどうかが、NHI の母集団を把握できている組織と、把握できていると思い込んでいるだけの組織を分ける要因です。

非人間のアイデンティティを保護し、ガバナンスする方法

ノンヒューマン・アイデンティティ管理（Non-human identity management、NHIM）とは、従来の IAM や Privileged Access Management(PAM) が想定していなかった「機械（マシン）アイデンティティ」を発見し、統制（ガバナンス）し、保護するための実践です。

つまり、人が介在しない状態でのアクセスを統制し、MFA を利用できない認証情報を管理し、HR の手続きではなく開発者や自動化によって作成されるアイデンティティについて所有権を追跡することを意味します。

まず、環境の中に何が存在するかを特定したら、ガバナンスによってその状態を統制下に維持します。効果的な NHI セキュリティでは、機械アイデンティティをアイデンティティ セキュリティ プログラムにおける第一級の存在として扱い、そのライフサイクルのあらゆる段階に対して定義されたポリシーを適用します。

実際には、次のようになります：

• 作成時にすべての NHI に所有者を割り当てます： アクセス権とライフサイクルに責任を負う「個人名の担当者」（配布リストではない、チームのエイリアスではない）がいないアイデンティティを作ってはいけません。所有権をプロビジョニング手順の必須フィールドにしてください。
• 最初の日から最小権限を徹底する： 各 NHI がその機能を果たすために必要な、特定の権限だけを付与し、可能な限り最小のリソース階層にスコープを絞り込みます。単一のアプリケーションにだけアクセスする必要があるサービスアカウントには、サブスクリプション全体またはドメイン全体の権限を付与しないでください。
• 可能な範囲で資格情報（credential）のローテーションを自動化する： gMSA は、オンプレミスの AD ワークロードに対してこれを自動的に処理します。クラウドのサービスプリンシパルや API キーについては、ローテーションをデプロイのパイプラインに組み込むか、シークレット管理ソリューションを利用してください。

適切なローテーション間隔は、資格情報（credential）の種類と露出リスク（exposure risk）によって決まります。主要なフレームワークである NIST、CIS 、および PCI DSS は、特権アカウントに対して普遍的なローテーション期間を義務付けていません。

• 行動の異常を監視する： 通常のパターンから外れて突然リソースにアクセスするサービスアカウント、または見慣れない場所から認証してくる API キーは、アラートを出すべきです。すべてのイベントを確認しようとするのではなく、確立されたベースラインからの逸脱に監視の重点を置いてください。
• 積極的に廃止（Decommission）する： 使われていない（古い）NHI は、どの環境でも最も悪用されやすい弱点の一つです。プロセスに廃止のトリガーを組み込みましょう。例えば、90 日間認証が行われていない ID があれば、レビュー対象としてフラグを立てます。所有者が正当化できない場合は無効化します。さらに 30 日間誰も気づかなければ削除します。
• 定期的なスケジュールでアクセスを認証します： NHI の所有者に対して、各 identity が現在の権限を引き続き必要としているかを再検証するよう求めます。年次レビューは出発点になりますが、特権 identity には四半期ごとの方が適しています。

これらのコントロールは、主要なコンプライアンス・フレームワークにすでに組み込まれている要件に直接対応しています：

• CMMC Level 2 では、非人間のものを含むすべての identity に対してアクセス制御とアカウント管理が必要です
• SOC 2 のトラストサービス基準では、非人間の identity にまで拡張するアクセス制御が求められます
• HIPAA は、automated processes および service accounts によるアクセスを含む Protected Health Information へのすべてのアクセスについて監査ログ（audit trails）を義務付けています
• NIS2（EU）では、組織に対して、第三者サービスの認証情報や、そうしたサービスが使用するベンダー管理のマシン・アイデンティティなど、ICTサプライチェーンのリスクを管理することが求められています。
• DORA（EUの金融セクター）では、ICTの第三者リスク管理を義務化し、これらのサービスが使用するマシン・アイデンティティを含め、デジタルサービスの依存関係を監視・統治するための具体的な要件を定めています。

NHIのガバナンスを構築しているなら、同時にコンプライアンスのエビデンスも構築しています。

Netwrix が非人間（ノンヒューマン）アイデンティティのセキュリティを支援する方法

上記のあらゆるガバナンスの取り組みは、1つのことに依存しています。それは、環境内にどのような非人間（ノンヒューマン）アイデンティティが存在し、それらが何をしているのかを把握することです。これは多くの組織が自力で埋めにくいギャップであり、その解決に Netwrix が適しています。

Netwrix 1Secure platform は、Active Directory およびクラウド環境全体にわたって、アイデンティティの姿勢（ポスチャ）を継続的に可視化します。特に非人間のアイデンティティに対しては、非アクティブなアカウント、期限切れ／古いアカウント、組織ポリシーに違反する過度に許可されたアクセス設定を表面化し、セキュリティチームが四半期ごとのスナップショットではなく「現在の状態」を把握できるようにします。

手作業のクエリでは、その時点のエクスポート（抜き取り）しか得られませんが、1Secure は新しいアイデンティティが作成され、既存のものが変化していく状況を継続的に追跡し続けます。

とりわけ Active Directory では、Netwrix Auditor はサービスアカウントの変更を追跡し、認証イベントを監視し、グループポリシー（Group Policy）の変更を監査します。ネイティブツールが開けてしまう可視性のギャップを埋めることで、全体像をより確実に把握できます。

誰かが新しいサービスアカウントを作成したり、そのグループメンバーシップを変更したり、インタラクティブログオン（interactive logon）を試みたりすると、Auditor がそれを検知してフラグを立てます。チームは、HIPAA 、SOC 2、そして CMMC のようなコンプライアンス・フレームワークに直接対応付けられる、人が読めるレポートを使って、NHI 活動に関する監査上の質問への回答を始められます。

権限昇格を必要とする特権の非人間アイデンティティには、Netwrix Privilege Secure は、監査トレイルのためのフルセッション録画（full session recording）付きのジャストインタイム（just-in-time）プロビジョニングによって、常時付与（standing）の特権を解消します。サービスアカウントが24時間365日持続的に管理者権限を保持するのではなく、Privilege Secure は必要なときにだけ昇格権限を付与し、タスクが完了すると自動的に取り消します。

非人間のアイデンティティの可視性ギャップを埋める準備はできていますか？ デモを予約する お使いの環境で Netwrix がどのように機能するかをご確認ください。