2025年5月9日

NECサイバーセキュリティ技術統括部セキュリティ技術センターの山田です。

今回のブログでは、OWASP Top 10 Non-Human Identities Risksについてご紹介します。Non-Human Identities (NHI) はあまり馴染みのない言葉かもしれませんが、近年のクラウド環境や開発環境ではNHIの利用が不可欠になっています。NHIとは何か、またNHIにどのようなリスクや対策があるのかについて、本ブログを通じて知っていただければ幸いです。

目次

OWASP Top 10 Non-Human Identities Risks とは

OWASP Top10 Non-Human Identities Risks[1]とは、OWASP[2]により公開された Non-Human Identities (NHI) に関するリスクをまとめた文書です。
近年、クラウド環境の利用や構築の自動化が普及し、アプリケーションやサービスが連携する際に使用する NHIに関するリスクが無視できなくなっています。この NHI に関連するリスクの中から、主要なリスクを明確化してまとめた物が OWASP Top10 Non-Human Identities Risks になります。

Non-Human Identities (NHI) とは

Non-Human Identities（NHI）とは、人間以外のエンティティ(アプリケーションやサービスなど)が保護されたリソースにアクセスする際に使用されるアイデンティティを指します。具体例として、以下のようなものが挙げられます。

これらのNHIは、人間の介入なしにアプリケーションやサービスが連携して動作するために使用されるアイデンティティになります。ここに挙げた要素以外にも、NHIはパスワードや証明書やトークンなど、様々なクレデンシャルや認証方法を利用できます。

ここで、このブログで登場する用語を整理しておきます。

Non-Human Identities (NHI) のリスク

NHIは人間が介在せずサービス同士が連携するために利用されるアイデンティティですが、人間のアイデンティティと似たリスクを抱えています。

これらのリスクは人間のアイデンティティにも通じるところがあります。しかし、NHIはシステムが自動で使うという特徴があるため、人間のアイデンティティほどの注意や対策が十分に行われていない場合があります。そして、上記のリスクにより、NHIの侵害は人間のアイデンティティ以上に不正アクセスやデータ侵害、システムやインフラへの攻撃に繋がる可能性があります。
NHIはクラウド環境だけでなく、開発パイプラインなどにおいても重要な役割を果たしているため、その使用を避けることはできません。そのため、NHIのセキュリティを確保することは重要になります。

OWASP Non-Human Identities Top 10 の概要

この章では、OWASPが2025年に公開した NHI のリスク上位10個について要約してご紹介します。OWASP Non-Human Identities Top10の本文には、リスク評価の内訳、具体的な攻撃シナリオ、そしてリスクへの対策方法などが記載されています。このブログを読んで気になったリスクがある場合は、OWASP Non-Human Identities Top10 で各リスクの詳細をご確認ください。

NHI1:2025　不適切なオフボーディング

不適切なオフボーディングとは、NHIが不要になった際に、適切に無効化や削除が実施されなかった状態を指します。これは、サービスの終了時や、NHIの管理者がプロジェクトを離れた際に発生します。サービスが終了すると、サービスの運用環境への監視も緩くなることが想定されます。このとき、終了した運用環境に有効なNHIが残ったままだと、その環境への攻撃により有効なNHIが入手でき、他システムへの水平攻撃が可能になってしまいます。
対策として、アクティブなNHIの定期的な監査を行うことや、サービス終了時や管理者が離れる際には、NHIの無効化や他の管理者への所有権の移行を行うことなどの対策が推奨されます。

NHI2:2025　シークレットの漏洩

シークレットの漏洩とは、APIキーや暗号化キーなどの機密性の高いシークレットが、ソフトウェア開発ライフサイクルの中で許可されていない媒体や外部に漏洩することを指します。開発者はアプリケーションが様々なリソースやサービスと連携できるようにするためにNHIを利用します。しかし、NHIが保持するシークレットをプレーンテキストに保存したり、パブリックチャット経由で送信したりすると、そのシークレットが暴露する可能性が高まります。また、攻撃者がこのシークレットを入手すると、開発者と同じ権限の操作が出来るようになり大変危険です。
対策として、静的なシークレットを一時的なクレデンシャルに置き換える (例：AWS STS) ことや、CI/CDパイプラインに秘密情報スキャンツール (例：GitHub Secret Scanning) を統合して静的なシークレットがコミットされるのを防ぐことなどの対策が推奨されます。

NHI3:2025　脆弱なサードパーティNHI

近年の開発フローには、統合開発環境(IDE)やその拡張機能、またサードパーティSaaSが統合されています。サードパーティNHIとは、これらツールやサービスを使うために提供したアクセストークンやAPIキーなどを指します。例えば、IDEの拡張機能はコードの参照だけでなく、環境変数や開発リソースへのアクセスなど、広範囲の操作が行えます。サードパーティの拡張機能が侵害された場合、NHIを悪用して機密情報の漏洩や開発リソースの乗っ取りなどをすることが出来るようになります。
対策として、サードパーティのツールやサービスを統合する場合はセキュリティーレビューを実施することや、ログやAPIコールなどからサードパーティの活動を継続的に監視することなどの対策が推奨されます。

NHI4:2025　安全でない認証

UX向上や運用改善のために、内外のサービスを統合する機会が増えています。その際、各サービスがリソースにアクセスするためにクレデンシャルが必要になります。様々な認証方法が各プラットフォームから提供されていますが、その中には、非推奨だったり、既知の攻撃に脆弱だったりする認証方法も含まれます。例えば、Microsoftは多要素認証に対応していない古いデバイス向けに、アプリパスワードによる認証方式を提供しています[3]。この方法は簡単な認証方式ですが、多要素認証を迂回できてしまうため、利用シーンは限定されるべきです。また、OAuth のImplicit FlowはSPA (Single Page Application) で使われるケースがありましたが、URLにアクセストークンが露出するため、現在では推奨されていません[4]。
対策として、最新の標準的な認証方法を採用することや、認証方法を定期的にレビューして非推奨または安全でない認証方法を利用していないか確認することなどの対策が推奨されます。

NHI5:2025　過剰に権限付与されたNHI

NHIは自動化されたプロセスが人間の介在なしに動作するために必要です。しかし、開発中やメンテナンス中に、誤ってNHIに過剰な権限を割り当ててしまうことがあります。例えば、サービスの連携に失敗、調査のためにNHIに幅広いアクセス権を割り当てることが考えられます。調査終了後に権限をそのままにすると、そのNHIの侵害により想定外の範囲まで攻撃が拡大する恐れがあります。
対策として、最小特権の原則[5]を徹底することや、権限の濫用や過剰な割り当てが無いか定期的に監査するなどの対策が推奨されます。

NHI6:2025　安全でないクラウド配備の構成

CI/CD (継続的インテグレーションおよび継続的デプロイ) は開発プロセスに統合され、ビルド、テスト、および本番環境へのデプロイを自動的に行うことができます。このCI/CDパイプラインが開発リソースにアクセスするためには、クレデンシャルが必要になります。しかし、CI/CDパイプラインが使用する静的クレデンシャルをCI/CD用の設定ファイルに保存してしまうと、その設定ファイルを通じてクレデンシャルが漏洩するリスクが生じます。また、配備先の環境設定も重要になります。例えば、本番環境におけるアクセストークンの検証に不備[6]がある場合、CI/CDパイプラインを経由しない不正アクセスを許してしまう可能性があります。
対策として、有効期間の短い動的なトークン(例：OpenID Connect による一時的なアクセスキー) を使用することや、トークンの利用者が正しいか検証すること (例：OpenID Connect の sub Claim)、また、クレデンシャルの管理を安全にすること (例：AWS Secrets Manager の利用) などの対策が推奨されます。

また、本ブログでは過去にOWASP Top 10 CI/CD Security Risks[7]をご紹介しております。こちらも合わせてご覧ください。

NHI7:2025　長期生存のシークレット

APIキーや暗号化キーなどの機密性が高いシークレットに対して、有効期限を長く設定したり無期限にしたりすることは、漏洩の可能性が高まるだけでなく、攻撃者は時間的制約無しでシークレットの悪用ができることを意味します。また、稼働中のシステムだけでなく、システムのバックアップやダンプなどにも有効なシークレットが残ってしまいます。これは、攻撃者にとって、監視が薄いバックアップやダンプから、システムへのアクセス権が入手可能なことを意味します。
対策として、シークレットの有効期限は短く設定することや一時的なクレデンシャルを利用すること、クレデンシャルを定期的かつ自動的にローテーションして長期間有効になるのを防止することなどの対策が推奨されます。

NHI8:2025　NHIの環境分離

環境分離とは、開発・テスト・本番のようにステージ別の動作環境を用意・使用する基本的なセキュリティ対策です。環境が異なることで、開発・テスト環境の問題を、本番環境に影響させないという対策が採れます。しかし、複数の環境 (特に、テストと本番) で同じNHIを利用しているケースがあります。例えば、テスト環境と本番環境から同じアクセスキーを利用して外部サービスにアクセスしているケースが考えられます。この場合、監視が手薄なテスト環境に攻撃者が侵入、テスト環境のNHIにより本番環境のデータの取得や改竄ができる恐れがあります。
対策として、環境毎にNHIを用意することや、環境分離を徹底して非本番環境から本番環境にアクセスできないようにすることなどの対策が推奨されます。

NHI9:2025　NHIの再利用

異なるサービスでも、アクセス先のリソースや操作内容が同じことはよくあります。その際、共通利用する1個のトークンを生成して、異なるサービスに設定してしまう場合があります。しかし、このようなNHIの利用方法は、重大なセキュリティリスクがあります。片方のサービスが侵害された場合に、他サービスへの侵害を防ぐのが困難になるだけでなく、NHIの停止・削除をしようにも影響範囲が広くなり対応が困難になる恐れがあります。
対策として、NHIは共有せずサービスごとに固有のNHIを割り当てること、定期的なレビューにより再利用されてないことを確認することなどの対策が推奨されます。

NHI10:2025　NHIの人間による利用

NHIは人間が介在せずサービス同士が連携するために利用されます。しかし、サービスの開発中や保守中に、開発者や管理者がNHIを利用して手動操作してしまう場合があります。このようなNHIの人間による利用は、手動操作と自動操作の区別がつかなくなるだけでなく、開発者が作業中なのか攻撃者がNHIを悪用しているのか検出するのを困難にします。また、人間用のセキュリティコントロールとNHI用のセキュリティコントロールは異なるため、例えばNHIにより多要素認証を回避し、人間の作業中に意図しない権限昇格をする恐れがあります。
対策として、NHIの人間による利用は行わず、開発作業や保守作業には人間用のIDを使用すること、NHIの活動を監視して人間による使用 (作業や攻撃) を特定することなどの対策が推奨されます。

まとめ

今回はNon-Human Identities（NHI）とは何か、そのリスクと対策は何かを考えるために、OWASP Top10 Non-Human Identities Risksを紹介しました。また、10個のリスクについて、それぞれの内容と対策を紹介しました。
各リスクの対策でも述べられていますが、NHIのリスクへの対策は、人間のアイデンティティの対策と変わりません。

NHIの利用は、近年のクラウド環境や開発環境では必須になっています。NHIのリスクについて考慮が不足していると感じている場合は、ぜひ OWASP Top10 Non-Human Identities Risks を参考に、ご自身の環境をチェックしていただければと思います。

参考文献

執筆者の他の記事を読む