Security NEWS TOPに戻る
バックナンバー TOPに戻る
近年、クラウドやSaaSの普及で、人の手を介さずに動作する「Non-Human Identity（NHI）」が存在感を増しています。このNHIに対するOWASPのTop10シリーズが2025年から公開されています。「OWASP Top 10」を中心に、基本的なセキュリティ知識を深め、企業での対策に活かすことを目的としたシリーズ第3回の今回は、NHIとは何か、悪用事例や企業が今取るべきセキュリティ対策の方向性を解説します。
Non-Human Identity（NHI）とは
NHIとは、マシン間のアクセスと認証に使用されるデジタル的なIdentity（ID注 1)）の総称です。IDは機械的な処理や自動化の場面で使われます。NHIはクラウドサービスの普及やAPI化の進展とともに爆発的にその数を増やしています。その最大のメリットはAPIやマイクロサービス、アプリケーションごとに設定・運用が可能な点にあります。そして最大のデメリットがセキュリティ関連の問題です。
NHIが用いられる代表例としてCI/CD注 2)環境があります。CI/CD環境では日常的にコードのコミットやレビュー、テスト、ビルド、バージョン管理、デプロイといったことがCI/CDパイプラインやクラウドサービスプロバイダとの統合を通じて行われています。ここでのNHIの利用状況を考えてみましょう。
CI/CD環境とNHIのイメージ
ユーザがIDEからプラグイン経由でワークフローにコードのプッシュ/プルなどの操作を行うことでCI/CDパイプラインのワークフローが動作し、ワークフローから様々なコンポーネントや外部APIへの通信にNHI（凡例①～③）が利用されます。
CI/CDに限らず、私たちの周りにはNHIを必要とするサービス間・システム間の連携が多数存在しています。次の図は顧客管理システム（CRM）と営業支援システム（SFA）を中心とした、NHIを用いた典型的なサービス間の連携のイメージです。
CI/CD環境も、この図に挙げた例でも、1人のユーザが1つのアプリケーションから複数の機能を動かすことができます。このため、組織内では人の10～50倍のNHIが存在するともいわれています注 3)。さらに、すべてのNHIが適切に管理されているとは限らず、サービス間・開発者間でのNHIの共有や認証情報のローテーションのないNHIの存在など、多くの問題があります。これらのセキュリティ上の問題をまとめたものが「OWASP NHI Top10」です。
事例から見るNHIのセキュリティ課題
tj-actionsサプライチェーン攻撃（2025年発生）
GitHub Actions（GitHubによるCI/CDプラットフォーム）向けのサードパーティー製のアクション集であるtj-actionsが依存するライブラリへの侵害が原因となったサプライチェーン攻撃です。GitHub Actionsにはワークフローやその中の一部アクションの再利用という機能がありますが、tj-actionsはGitHub Actionsでは提供していないアクションを多数提供することでGitHub Actionsの補完目的で使用できるツールの一つです。図は時間的経過を含む本事案の推移をあらわしたものです。
tj-actions侵害・サプライチェーン攻撃の概要
GitHub独自のセキュリティに関連する補足説明
PAT: ここでのPATはGitHubが提供するPersonal Access Tokenを指します。APIやCLIからのアクセス（たとえばgit cloneやpush, pullなど）を行う際の認証に用いられるものです。発行が人（GitHubユーザ）に対して行われるので属人性がありますが、実際にはNHIとして使用します。Settings>Developer SettingsからToken（Classic）またはFine Grained Tokenが選択できます。Fine Grained Tokenを選択した場合はトークンに関するパーミッションの詳細が設定できるようになっていますが、セキュリティの観点では非推奨の設定項目（例えば有効期限を設定しないなど）が有効になっている点や、設定項目が詳細かつ多岐にわたるためセキュリティ上の配慮のない設定をしているケースもありうる点に注意が必要です。
pull_request_target: GitHub Actionsにはpull_requestとpull_request_targetの２つのpull requestトリガーがあります。pull_request_targetは使い方を理解していないと今回のようなケースで悪用されることがあります。参考資料を以下に記載しますので、ぜひご一読ください。
https://blog.gitguardian.com/github-actions-security-cheat-sheet/
https://blog.gitguardian.com/github-actions-security-cheat-sheet/https://runs-on.com/github-actions/pull-request-vs-pull-request-target/
本件でOWASP NHI Top 10のうち該当する可能性がある項目は以下の通りです。
| No. | 名称 | 今回何が該当するか |
| NHI2 | Secret Leakage（シークレット漏洩） | 本件ではtj-actions経由でログにダンプされた秘密情報があった点、各PATの漏洩があった点の2点が該当 |
| NHI3 | Vulnerable Third-Party NHI（脆弱なサードパーティーNHI） | spotbugsおよびreviewdog への侵害がtj-actionsへの侵害へ繋がった点が該当 |
| NHI7 | Long-Lived Secrets（長期間有効なシークレット） | 攻撃期間からspotbugsのメンテナーのPATの有効期限が長かった可能性がある |
OWASP NHI Top 10
OWASP NHI Top 10 2025をここで簡単にご紹介します。
| NHI番号 | 名称 | 概要 | 対策 |
| NHI1:2025 | Improper Offboarding（不適切なオフボーディング） | サービスアカウントやアクセスキーなどの非人間的アイデンティティが不要になった際に、適切に無効化・削除されない問題。放置された認証情報が攻撃者に悪用され、機密システムへの不正アクセスに利用される可能性がある。 | NHIのライフサイクル管理を自動化し、使用されていないアイデンティティを定期的に検出・無効化する。継続的なスキャンとモニタリングでゾンビNHIを特定し、ガバナンス、ツール、ワークフローの観点から廃止プロセスを体系化する。 |
| NHI2:2025 | Secret Leakage（シークレット漏洩） | APIキー、トークン、暗号化キー、証明書などの機密情報が、ソースコードへのハードコーディング、平文設定ファイル、公開チャットアプリケーションなど、認可されていないデータストアに漏洩する問題。 | ハードコードされた認証情報を排除し、適切なシークレット管理プラットフォーム（CyberArk Conjur、HashiCorp Vault等）を導入する。CI/CDパイプラインにシークレットスキャンを組み込み、リアルタイムで漏洩を検出・検証する。 |
| NHI3:2025 | Vulnerable Third-Party NHI（脆弱なサードパーティーNHI） | 開発ワークフローに統合されたサードパーティーの非人間的アイデンティティが、セキュリティ脆弱性や悪意のあるアップデートにより侵害され、認証情報の窃取や権限の悪用に利用される問題。 | サードパーティーサービスのセキュリティ実践を定期的に監査し、統合されたサービスの更新状況を追跡する。最小権限の原則に従い、サードパーティーに与える権限を最小限に制限し、定期的にアクセス権を見直す。 |
| NHI4:2025 | Insecure Authentication（安全でない認証） | 開発者が内部・外部サービスを統合する際に、非推奨で脆弱性のある認証方式や、古いセキュリティ慣行による弱い認証メカニズムを使用することで組織が重大なリスクにさらされる問題。 | 非推奨の認証方式（SHA1等）を特定し、最新のセキュリティ標準に準拠した認証方式に移行する。すべての暗号化・認証方式を定期的に見直し、技術の進歩に合わせて更新する。長期間有効なAPIキーを短期間トークンに置き換える。 |
| NHI5:2025 | Overprivileged NHI（過度な権限を持つNHI） | アプリケーション開発・保守時に、開発者や管理者が非人間的アイデンティティに必要以上の権限を付与し、侵害時に攻撃者がその過剰な権限を悪用して重大な被害を与える可能性がある問題。 | 最小権限の原則を厳格に適用し、NHIの権限を定期的に見直す。権限のスコープを適切に設定し、シークレットローテーション時に権限の再評価を実施する。人間のアイデンティティと同様の自動化されたアクセス権見の直しプロセスを導入する。 |
| NHI6:2025 | Insecure Cloud Deployment Configurations（安全でないクラウドデプロイ設定） | CI/CDアプリケーションがクラウドサービス認証で静的認証情報やOIDCを使用する際、設定ミスや検証不備により、攻撃者が本番環境への永続的で特権的なアクセスを獲得する可能性がある問題。 | 静的認証情報の代わりにOIDCトークンベース認証を使用し、アイデンティティトークンの適切な検証を実装する。設定ファイルへのハードコード化を避け、適切なシークレット管理システムを使用する。CI/CDパイプラインでのシークレット露出を防ぐ。 |
| NHI7:2025 | Long-Lived Secrets（長期間有効なシークレット） | APIキー、トークン、暗号化キー、証明書の有効期限が遠い将来に設定されているか無期限の場合、侵害されたシークレットが時間制約なく攻撃者に機密サービスへのアクセスを提供する問題。 | 短期間で自動ローテーションされるシークレットを実装し、可能な限り実行時に生成される一時的なトークンを使用する。シークレットのライフサイクルを可視化し、作成・使用・ローテーション状況を追跡する。有効期限のないシークレットを特定し排除する。 |
| NHI8:2025 | Environment Isolation（環境分離） | 開発、テスト、ステージング、本番環境で同じ非人間的アイデンティティを再利用することで、特にテスト環境と本番環境間での使い回しが重大なセキュリティ脆弱性を引き起こす問題。 | 開発、ステージング、本番環境で異なるNHIを使用し、環境間でのNHI共有を禁止する。各環境専用のNHIを設定し、環境固有のアクセス権限を適用する。NHIの使用状況を可視化し、環境分離ポリシーの遵守状況を監視する。 |
| NHI9:2025 | NHI Reuse（NHI再利用） | 異なるアプリケーション、サービス、コンポーネント間で同じ非人間的アイデンティティを再利用することで、一箇所での侵害が他の部分への不正アクセスに利用される重大なセキュリティリスクを生む問題。 | 異なるアプリケーション間でのNHI共有を禁止し、1対1のNHI-アプリケーション使用ポリシーを確立する。NHIの使用コンテキストを詳細に把握し、複数システム間での再利用を防ぐ。侵害時の影響範囲を限定するため、専用NHIを各アプリケーションに割り当てる。 |
| NHI10:2025 | Human Use of NHI（人間によるNHIの使用） | アプリケーション開発・保守時に、開発者や管理者が個人の人間的 アイデンティティで行うべき手動タスクに非人間的アイデンティティを悪用し、監査やアカウンタビリティの欠如などのリスクを引き起こす問題。 | 手動タスクには適切な権限を持つ個人のアイデンティティを使用し、NHIの人間による使用を禁止する。NHIの異常使用を検出するモニタリングを実装し、承認されたアクセスパターンから逸脱した使用を特定する。監査とアカウンタビリティを確保するため、人間とNHIの活動を明確に区別する。 |
企業がとるべき対策
NHI固有の対策（NHI10:2025人間によるNHIの使用）もありますが、例えば人の認証に関する対策と似たようなもの（オフボーディング対策、認証情報のハードコードの排除、最小権限の原則の徹底、認証方法のアップデート、環境分離やシステム間での再利用禁止）も多く含まれます。企業のIT環境は今後、AI統合やレガシーシステムの置き換え、人手不足を背景とした業務の自動化を中心に大きく変動していくことが予想されます。
NHIはアプリケーション間、システム間といったマシン間の認証に用いられることから、AI統合や業務のデジタル化・自動化において利用される機会が増えていきます。新しい概念であり、新しいセキュリティ上のリスクでもあり、なかなか理解するのが難しい分野ではありますが、少なくとも、以下の点においてセキュリティ上重要であることをご理解いただければと思います。
- NHIは企業のデジタル資産やシステム間の接続のために多数用いられており、攻撃者から見たときに非常に広い攻撃面となりうること
- 特権が付与されるNHIも存在することから、攻撃者から見たときに有用な攻撃面であるが、最小権限の原則が適用されていない場合、防御側にとっては保護が難しいこと
- 人間の認証と同じく、認証方法がセキュリティリスクの高いもの（単純なAPIキー）からセキュリティリスクが低いもの（OAuthと証明書の同時活用）まで非常に多様であり、選択を間違うと攻撃された際の被害が甚大であること
セキュリティは「開発初期から」「全社横断で」
3つのTop 10に共通しているのは、「問題の多くは設計段階・開発段階で防げる」という事実です。脆弱性や権限ミスは、開発中の選択や運用ポリシーによって生まれるため、セキュリティは“あとから付け足す”ものではなく、最初から組み込むべき設計要件であるという考え方がますます重要になっています。また、情報システム部門だけでなく、開発チーム・運用チーム・経営層を巻き込んだ全社的なセキュリティ体制の確立が求められます。
OWASP Top 10を「読むだけ」で終わらせないために
OWASPのTop10シリーズは、ただの知識リストではありません。それぞれのリスクが「なぜ問題なのか」「どう防げるのか」を考えることで、企業ごとのセキュリティ成熟度を高めることができます。自社システムに照らして「どこが該当するか」「どのリスクが潜在しているか」をチームで共有し、日々の開発・運用の判断にOWASPの知見を活用することが、最も効果的なセキュリティ強化への第一歩です。3回にわたる本シリーズが、皆さまのセキュリティ戦略の一助となれば幸いです。
【参考情報】
- NHI Top 10及びNHI全般
OWASP Non-Human Identities Top 10-2025
Amit Zimerman (Cloud Security Alliance),” What are Non-Human Identities?”, - tj-actionsサプライチェーン攻撃
https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised
https://unit42.paloaltonetworks.com/github-actions-supply-chain-attack/
https://www.wiz.io/blog/new-github-action-supply-chain-attack-reviewdog-action-setup
https://github.com/tj-actions/changed-files/issues/2464#issuecomment-2727020537
【連載一覧】
―第1回「OWASP Top 10とは？アプリケーションセキュリティの基本を押さえよう」―
―第2回「OWASP API Security Top 10とは？APIの脅威と対策を知ろう」―
注：
1)ここでは読者の皆さんに理解しやすいようにIDとしていますが、実態としてはデジタル的な構成要素（digital construct）であり、デジタル的な主体（digital entity）となります。
2)Continuous Integration/ Continuous Delivery（継続的インテグレーション/継続的デリバリー）の略語
3)https://cloudsecurityalliance.org/blog/2024/03/08/what-are-non-human-identities
Security NEWS TOPに戻る
バックナンバー TOPに戻る
