【第3回】Non-Human Identities Top 10とは?自動化時代に求められる新しいセキュリティ視点

Share

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の2つの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.名称今回何が該当するか
NHI2Secret Leakage(シークレット漏洩)本件ではtj-actions経由でログにダンプされた秘密情報があった点、各PATの漏洩があった点の2点が該当
NHI3Vulnerable Third-Party NHI(脆弱なサードパーティーNHI)spotbugsおよびreviewdog への侵害がtj-actionsへの侵害へ繋がった点が該当
NHI7Long-Lived Secrets(長期間有効なシークレット)攻撃期間からspotbugsのメンテナーのPATの有効期限が長かった可能性がある

OWASP NHI Top 10

OWASP NHI Top 10 2025をここで簡単にご紹介します。

NHI番号名称概要対策
NHI1:2025Improper Offboarding(不適切なオフボーディング)サービスアカウントやアクセスキーなどの非人間的アイデンティティが不要になった際に、適切に無効化・削除されない問題。放置された認証情報が攻撃者に悪用され、機密システムへの不正アクセスに利用される可能性がある。NHIのライフサイクル管理を自動化し、使用されていないアイデンティティを定期的に検出・無効化する。継続的なスキャンとモニタリングでゾンビNHIを特定し、ガバナンス、ツール、ワークフローの観点から廃止プロセスを体系化する。
NHI2:2025Secret Leakage(シークレット漏洩)APIキー、トークン、暗号化キー、証明書などの機密情報が、ソースコードへのハードコーディング、平文設定ファイル、公開チャットアプリケーションなど、認可されていないデータストアに漏洩する問題。ハードコードされた認証情報を排除し、適切なシークレット管理プラットフォーム(CyberArk Conjur、HashiCorp Vault等)を導入する。CI/CDパイプラインにシークレットスキャンを組み込み、リアルタイムで漏洩を検出・検証する。
NHI3:2025Vulnerable Third-Party NHI(脆弱なサードパーティーNHI)開発ワークフローに統合されたサードパーティーの非人間的アイデンティティが、セキュリティ脆弱性や悪意のあるアップデートにより侵害され、認証情報の窃取や権限の悪用に利用される問題。サードパーティーサービスのセキュリティ実践を定期的に監査し、統合されたサービスの更新状況を追跡する。最小権限の原則に従い、サードパーティーに与える権限を最小限に制限し、定期的にアクセス権を見直す。
NHI4:2025Insecure Authentication(安全でない認証)開発者が内部・外部サービスを統合する際に、非推奨で脆弱性のある認証方式や、古いセキュリティ慣行による弱い認証メカニズムを使用することで組織が重大なリスクにさらされる問題。非推奨の認証方式(SHA1等)を特定し、最新のセキュリティ標準に準拠した認証方式に移行する。すべての暗号化・認証方式を定期的に見直し、技術の進歩に合わせて更新する。長期間有効なAPIキーを短期間トークンに置き換える。
NHI5:2025Overprivileged NHI(過度な権限を持つNHI)アプリケーション開発・保守時に、開発者や管理者が非人間的アイデンティティに必要以上の権限を付与し、侵害時に攻撃者がその過剰な権限を悪用して重大な被害を与える可能性がある問題。最小権限の原則を厳格に適用し、NHIの権限を定期的に見直す。権限のスコープを適切に設定し、シークレットローテーション時に権限の再評価を実施する。人間のアイデンティティと同様の自動化されたアクセス権見の直しプロセスを導入する。
NHI6:2025Insecure Cloud Deployment Configurations(安全でないクラウドデプロイ設定)CI/CDアプリケーションがクラウドサービス認証で静的認証情報やOIDCを使用する際、設定ミスや検証不備により、攻撃者が本番環境への永続的で特権的なアクセスを獲得する可能性がある問題。静的認証情報の代わりにOIDCトークンベース認証を使用し、アイデンティティトークンの適切な検証を実装する。設定ファイルへのハードコード化を避け、適切なシークレット管理システムを使用する。CI/CDパイプラインでのシークレット露出を防ぐ。
NHI7:2025Long-Lived Secrets(長期間有効なシークレット)APIキー、トークン、暗号化キー、証明書の有効期限が遠い将来に設定されているか無期限の場合、侵害されたシークレットが時間制約なく攻撃者に機密サービスへのアクセスを提供する問題。短期間で自動ローテーションされるシークレットを実装し、可能な限り実行時に生成される一時的なトークンを使用する。シークレットのライフサイクルを可視化し、作成・使用・ローテーション状況を追跡する。有効期限のないシークレットを特定し排除する。
NHI8:2025Environment Isolation(環境分離)開発、テスト、ステージング、本番環境で同じ非人間的アイデンティティを再利用することで、特にテスト環境と本番環境間での使い回しが重大なセキュリティ脆弱性を引き起こす問題。開発、ステージング、本番環境で異なるNHIを使用し、環境間でのNHI共有を禁止する。各環境専用のNHIを設定し、環境固有のアクセス権限を適用する。NHIの使用状況を可視化し、環境分離ポリシーの遵守状況を監視する。
NHI9:2025NHI Reuse(NHI再利用)異なるアプリケーション、サービス、コンポーネント間で同じ非人間的アイデンティティを再利用することで、一箇所での侵害が他の部分への不正アクセスに利用される重大なセキュリティリスクを生む問題。異なるアプリケーション間でのNHI共有を禁止し、1対1のNHI-アプリケーション使用ポリシーを確立する。NHIの使用コンテキストを詳細に把握し、複数システム間での再利用を防ぐ。侵害時の影響範囲を限定するため、専用NHIを各アプリケーションに割り当てる。
NHI10:2025Human Use of NHI(人間によるNHIの使用)アプリケーション開発・保守時に、開発者や管理者が個人の人間的 アイデンティティで行うべき手動タスクに非人間的アイデンティティを悪用し、監査やアカウンタビリティの欠如などのリスクを引き起こす問題。手動タスクには適切な権限を持つ個人のアイデンティティを使用し、NHIの人間による使用を禁止する。NHIの異常使用を検出するモニタリングを実装し、承認されたアクセスパターンから逸脱した使用を特定する。監査とアカウンタビリティを確保するため、人間とNHIの活動を明確に区別する。
出典:OWASP Non-Human Identities Top 10より弊社編集・和訳

企業がとるべき対策

NHI固有の対策(NHI10:2025人間によるNHIの使用)もありますが、例えば人の認証に関する対策と似たようなもの(オフボーディング対策、認証情報のハードコードの排除、最小権限の原則の徹底、認証方法のアップデート、環境分離やシステム間での再利用禁止)も多く含まれます。企業のIT環境は今後、AI統合やレガシーシステムの置き換え、人手不足を背景とした業務の自動化を中心に大きく変動していくことが予想されます。

NHIはアプリケーション間、システム間といったマシン間の認証に用いられることから、AI統合や業務のデジタル化・自動化において利用される機会が増えていきます。新しい概念であり、新しいセキュリティ上のリスクでもあり、なかなか理解するのが難しい分野ではありますが、少なくとも、以下の点においてセキュリティ上重要であることをご理解いただければと思います。

  • NHIは企業のデジタル資産やシステム間の接続のために多数用いられており、攻撃者から見たときに非常に広い攻撃面となりうること
  • 特権が付与されるNHIも存在することから、攻撃者から見たときに有用な攻撃面であるが、最小権限の原則が適用されていない場合、防御側にとっては保護が難しいこと
  • 人間の認証と同じく、認証方法がセキュリティリスクの高いもの(単純なAPIキー)からセキュリティリスクが低いもの(OAuthと証明書の同時活用)まで非常に多様であり、選択を間違うと攻撃された際の被害が甚大であること

セキュリティは「開発初期から」「全社横断で」

3つのTop 10に共通しているのは、「問題の多くは設計段階・開発段階で防げる」という事実です。脆弱性や権限ミスは、開発中の選択や運用ポリシーによって生まれるため、セキュリティは“あとから付け足す”ものではなく、最初から組み込むべき設計要件であるという考え方がますます重要になっています。また、情報システム部門だけでなく、開発チーム・運用チーム・経営層を巻き込んだ全社的なセキュリティ体制の確立が求められます。

OWASP Top 10を「読むだけ」で終わらせないために

OWASPのTop10シリーズは、ただの知識リストではありません。それぞれのリスクが「なぜ問題なのか」「どう防げるのか」を考えることで、企業ごとのセキュリティ成熟度を高めることができます。自社システムに照らして「どこが該当するか」「どのリスクが潜在しているか」をチームで共有し、日々の開発・運用の判断にOWASPの知見を活用することが、最も効果的なセキュリティ強化への第一歩です。3回にわたる本シリーズが、皆さまのセキュリティ戦略の一助となれば幸いです。

【参考情報】

【連載一覧】

―第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に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

【第2回】「OWASP API Security Top 10とは?APIの脅威と対策を知ろう」

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

デジタル化が進む現代において、Webサービスやスマートフォンアプリ、IoT機器まで、あらゆるシステムがAPIを通じて連携しています。しかし、その利便性の反面、APIを標的としたサイバー攻撃も急増しています。こうした背景の中、APIに特化したセキュリティリスクをまとめたのが「OWASP API Security Top 10」です。

「OWASP Top 10」を中心に、基本的なセキュリティ知識を深め、企業での対策に活かすことを目的としたシリーズ第2回の今回は、API開発や管理に関わる企業の情報システム部門・開発担当者に向けて、OWASP API Security Top 10の概要と代表的なリスク、具体的な対策についてわかりやすく解説します。

OWASP API Security Top 10とは

OWASP API Security Top 10は、OWASP(Open Web Application Security Project)がAPIセキュリティに関する10大リスクを選定・解説したもので、Webアプリケーション版『OWASP Top 10』同様、攻撃シナリオや防御方法がTop10形式で詳しく記載されており、API固有の脆弱性やセキュリティリスクの把握と対策をするための判断材料のひとつとして捉え、活用することができます。

「API」について、SQAT.jpでは以下の記事でも解説しています。
あわせてぜひご覧ください。
APIのセキュリティ脅威とは
APIとは何か(2)~APIの脅威とリスク~

APIセキュリティ

APIは異なるソフトウェア間の通信を可能にしますが、同時に攻撃者にとっての格好の標的にもなり得ます。そのため、APIを利用する企業やアプリケーション開発者にとってAPIのセキュリティ対策は重要な課題です。セキュリティリスクは他のプログラムやサービスと機能などデータを共有しているAPI特有の仕組みから生じます。APIが不適切に設計・管理されていると、未認証のアクセス、データ漏洩、機密情報の不正取得といったリスクが高まります。以下は、APIセキュリティに関する主なリスクの例です。

  • データ漏洩:APIを通じて個人情報や機密情報が漏洩するリスク
  • 不十分な認証:認証要素が不十分なことによる不正アクセスのリスク
  • サイバー攻撃リスク:標的型攻撃インジェクション攻撃やサービス運用妨害(DoS)攻撃などのサイバー攻撃を受けてしまうリスク
  • APIキーの窃取:APIキーが盗まれることによる不正利用のリスク

OWASP API Security Top 10:2023概要

以下は、2023年に発表された最新版のOWASP API Security Top 10のリストです。

項目番号リスク名概要
API1:2023Broken Object Level Authorization
(オブジェクトレベルでの認可の不備)
オブジェクトレベルの認可が不適切で、他ユーザのIDを参照できてしまう問題。IDを任意に変更して不正取得される
API2:2023Broken Authentication
(認証の不備)
認証トークンやセッション管理の不備により、なりすましや不正アクセスが可能となる状態
API3:2023Broken Object Property Level Authorization
(オブジェクトプロパティレベルの認可の不備)
オブジェクト内の個別プロパティに対して、参照・更新権限チェックがない問題。内部値が漏洩・改ざんされる恐れがある
API4:2023Unrestricted Resource Consumption
(無制限のリソース消費)
CPU、ネットワーク、メール送信等リソース制御がなく、DoS攻撃対策やコスト対策が不十分な状態
API5:2023Broken Function Level Authorization
(機能レベルの認可の不備)
本来の権限を超えて管理機能が呼び出され、削除・変更など不正操作が可能になる
API6:2023Unrestricted Access to Sensitive Business Flows
(機密性の高いビジネスフローへの無制限のアクセス)
購入や予約など、業務フローが制限なく自動化され悪用され得る状態。API側の防御が不十分な状態
API7:2023Server Side Request Forgery
(サーバサイドリクエストフォージェリ)
外部から渡されたURLを検証せず内部リソースをリクエストし、不正アクセス・ポートスキャンを誘発する
API8:2023Security Misconfiguration
(不適切なセキュリティ設定)
セキュリティ設定ミスにより、デバッグモードや不要エンドポイントが公開されたままになっている状態
API9:2023Improper Inventory Management(不適切なインベントリ管理)バージョン管理や資産管理不備により、古いAPIやテスト系エンドポイントが放置された状態
API10:2023Unsafe Consumption of APIs
(APIの安全でない使用)
APIクライアント側の不適切な利用により、API仕様外の動作等を招くケース
出典:OWASP Top 10 API Security Risks – 2023より弊社和訳

OWASP API Security Top 10:2023の代表的なリスクとその影響

OWASP API Security Top 10では、APIに特化した攻撃手法や設計ミスを10項目に分類しています。ここでは特に影響の大きい代表的な5項目を取り上げ、それぞれの特徴と企業に与える影響を見ていきましょう。

API1: Broken Object Level Authorization

  • 概要:他人のデータにアクセスできてしまう認可チェックの不備
  • 例:/users/12345を/users/12346に変更して別ユーザの情報を取得
  • 影響:個人情報漏洩、プライバシー侵害、法令違反リスク
  • 実例:T-Mobile(2020年)でAPI経由により契約者情報が漏洩*1

API2: Broken Authentication

API3: Broken Object Property Level Authorization

API4: Unrestricted Resource Consumption

  • 概要:API利用時のリソース消費に対する制限がなく、過剰利用を許してしまう
  • 例:無制限にファイルをアップロード、高頻度でログイン試行
  • 影響:DoS攻撃によるサービスの停止、インフラコストの急増
  • 実例:なし

API6: Unrestricted Access to Sensitive Business Flows

これらのリスクは、API開発における「利便性と安全性のバランス」が崩れたときに生じやすいものです。次章では、こうしたリスクに対して開発・運用チームがどのように備えるべきか、具体的な対策を解説します。

開発・運用チームがすべき対策

OWASP API Security Top 10:2023に示されたリスクは、設計・開発・運用のあらゆる段階での対策が必要です。APIは公開範囲が広く、攻撃対象になりやすいため、企業の情報システム部門や開発チームは「守るべきポイント」を明確にし、セキュリティレベルを高めていく必要があります。以下に代表的な対策を整理します。

認証・認可の適切な管理

  • アクセストークン(OAuthトークンなど)の署名検証や有効期限管理を適切に行う
  • 多要素認証(MFA)やOAuth 2.0/OpenID Connectなどの業界標準プロトコルを採用
  • ユーザIDやオブジェクトIDに基づいたアクセス制御(認可)の一貫性を保つ

目的:適切なユーザにのみ権限を付与し、不正アクセスのリスクを軽減する

入力データのバリデーションと制御

  • ユーザから受け取るリクエストパラメータ、JSON、ヘッダー情報などに対してサーバーサイドで厳格な検証を実施
  • 過剰なフィールドの受け入れを避け、明示的に許可されたパラメータだけを処理
  • 入力サイズ、データ型、構造の制限と、想定外の入力に対する例外処理を徹底

目的:不正な値による処理改ざん(Mass Assignment、インジェクション)やサービス停止リスクを軽減

脆弱性診断・ログ監視等の定期的な実施

  • APIエンドポイントに対するセキュリティ診断(ペネトレーションテスト、動的解析)を定期的に実施
  • SwaggerやOpenAPI仕様書をもとに、未公開API・テスト用APIが本番に露出していないか確認するため、棚卸しを実施
  • APIゲートウェイやWAF(Web Application Firewall)と連携したログの収集・監視も強化

目的:潜在的な脆弱性や構成ミスを早期に発見し、攻撃の起点となる入口を閉じる

レート制限と自動化対策

  • IPアドレスやユーザごとのレートリミットを設ける(例:1分間に○回まで)
  • CAPTCHAやボット対策(Device Fingerprint等)を導入して業務APIの濫用を防止
  • クラウド利用時はコスト制御のためのクォータ設定や自動アラートも重要

目的:DoS攻撃や不正自動化による買い占め行為の防止

セキュアなAPI設計の徹底

  • 最小権限の原則に基づいたロール設計、バージョン管理の明確化
  • 非公開APIは認証必須かつアクセス制限を設け、エラーメッセージは曖昧化
  • API仕様書の公開範囲と利用契約(利用規約・SLAs)にもセキュリティ要件を記載

目的:開発段階からセキュリティを組み込む“Security by Design(セキュリティ・バイ・デザイン)”の実現

企業におけるAPI活用が進む今、セキュリティ対策もまたアプリケーションとは別軸で強化が求められます。OWASP API Security Top 10はその出発点であり、ここで挙げた対策はすべての開発・運用現場で必須です。継続的な見直しと体制整備によって、APIの安全な運用を実現しましょう。

第3回では、クラウドや自動化が進む今、ますます注目されている「Non-Human Identities(NHI)」に焦点を当てます。人ではないアカウントが引き起こす新たな課題とは何か、そして企業はどう備えるべきかを解説します。


―第3回「Non-Human Identities Top 10とは?自動化時代に求められる新しいセキュリティ視点」へ続く―

【連載一覧】

―第1回「OWASP Top 10とは?アプリケーションセキュリティの基本を押さえよう」―
―第3回「Non-Human Identities Top 10とは?自動化時代に求められる新しいセキュリティ視点」―

Security NEWS TOPに戻る
バックナンバー TOPに戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

【第1回】「OWASP Top 10とは?アプリケーションセキュリティの基本を押さえよう」

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

近年、Webアプリケーションを狙ったサイバー攻撃が急増しており、企業にとってWebアプリケーションのセキュリティ強化は欠かせない課題となっています。その中で、世界中のセキュリティ専門家が指標として活用しているのが「OWASP Top 10」です。

今回は、Webアプリケーションの代表的な脆弱性をまとめた「OWASP Top 10」を通じて、基本的なセキュリティ知識を深め、企業での対策に活かすことを目的とし、背景から各脆弱性カテゴリの説明、実例、対策方法までを全3回のシリーズに分けて解説します。

OWASPとは

OWASP(Open Worldwide Application Security Project)は、ソフトウェアのセキュリティ向上を目的とした国際的な非営利団体です。開発者やセキュリティ専門家によって構成されており、セキュリティに関するツールやドキュメントなどを無償で提供しています。OWASPは中立かつオープンな立場から情報を発信しており、多くの企業や政府機関がそのガイドラインを信頼し、採用しています。

OWASP Top 10とは

OWASP Top 10は、Webアプリケーションにおける代表的なセキュリティリスクをランキング形式でまとめたもので、最も重要な10の脆弱性カテゴリを示しています。このリストはおよそ3年ごとに更新されており、業界の最新動向や実際の脅威傾向を反映しています。このTop 10は、アプリケーション開発やセキュリティ教育、脆弱性診断の指針として世界中で活用されており、情報システム部門にとってはセキュリティの共通言語ともいえる存在です。

OWASP Top 10:2021概要

OWASP Top 10:2021で挙げられているリスクとその概要について、SQAT.jpでは以下の記事でも取り上げています。あわせてぜひご覧ください。
OWASP Top 10―世界が注目するWebアプリケーションの重大リスクを知る―

以下は、2021年に発表された最新版のOWASP Top 10のリストです。

項目番号リスク名概要
A01Broken Access Control
(アクセス制御の不備)
アクセス制御の不備により、本来アクセスできない情報や機能へアクセスされるリスク
A02Cryptographic Failures
(暗号化の不備)
暗号化の不備による機密情報の漏洩や改ざん
A03Injection
(インジェクション)
SQLインジェクションなど、外部から不正なコードを注入されるリスク
A04Insecure Design
(セキュアでない設計)
セキュリティを考慮しない設計により生じる構造的リスク
A05Security Misconfiguration
(セキュリティ設定のミス)
設定ミスや不要な機能の有効化に起因する脆弱性
A06Vulnerable and Outdated Components(脆弱かつ古いコンポーネントの使用)脆弱性を含む古いライブラリやフレームワークの使用
A07Identification and Authentication Failures(識別と認証の不備)認証処理の不備により、なりすましや権限昇格が発生する
A08Software and Data Integrity Failures(ソフトウェアとデータの整合性の不備)ソフトウェア更新やCI/CDの不備により改ざんを許すリスク
A09Security Logging and Monitoring Failures(セキュリティログとモニタリングの不備)侵害の検知・追跡ができないログ監視体制の欠如
A10Server-Side Request Forgery (SSRF)(サーバサイドリクエストフォージェリ)サーバが内部リソースにアクセスしてしまうリスク
出典:OWASP Top 10:2021より弊社和訳

各リスク項目の代表的な脅威事例

項目番号実例企業・事例概要
A01Facebook (2019)他人の公開プロフィールがIDの推測とAPI操作により取得可能だった*8
A02Turkish Citizenship Leak(2016)暗号化されていなかったデータベースから約5,000万人の個人情報が流出*9
A03Heartland Payment Systems (2008)SQLインジェクションにより1億件以上のクレジットカード情報が漏洩*10
A04パスワードリセットの仕様不備(複数事例)多くの中小サイトで、トークンなしにメールアドレス入力のみでリセット可能な設計が確認されている
A05Kubernetes Dashboard誤設定事件(Tesla 2018)管理用インターフェースが公開状態になっており、社内クラウドで仮想通貨マイニングに悪用された*11
A06Equifax (2017)古いApache Strutsの脆弱性(CVE-2017-5638)を放置していたことで1.4億件以上の個人情報が漏洩*12
A07GitHub (2012)認証処理の不備により、セッションを乗っ取られる脆弱性が悪用され、一時的にユーザが他人のリポジトリにアクセス可能に
A08SolarWinds サプライチェーン攻撃(2020)正規のソフトウェアアップデートにマルウェアが仕込まれ、多数の政府機関や企業を含めた組織に影響を与えた
A09Capital One (2019)AWS環境の不適切なログ監視により、Web Application Firewallの設定ミスから約1億600万人分の情報が流出*13
A10Capital One (同上)SSRF攻撃によりAWSメタデータサービスへリクエストが可能となり、内部資格情報を窃取された*14

企業はOWASP Top 10をどう活用すべきか

OWASP Top 10は、単なる「参考資料」ではなく、企業が自社のセキュリティ対策を体系的に見直すための実践的な指針として活用できます。以下に、企業の情報システム部門担当者等が実際に取り入れるべき活用方法を紹介します。

開発プロセスへの組み込み(セキュア開発)

アプリケーション開発において、設計段階からOWASP Top 10を参考にすることで、設計段階から脆弱性を防ぐ「セキュア・バイ・デザイン(Secure by Design)」の思想を組み込むことが可能です。とくにA04「Insecure Design」などはアプリケーション開発の初期段階での対策が鍵となります。

脆弱性診断の評価基準として

外部のセキュリティ診断会社や自社診断の基準としてOWASP Top 10を採用することで、リスクの見落としを防ぎつつ、業界標準の診断を実現できます。

セキュリティ教育・啓発資料として

企業の社員のセキュリティリテラシーを高めるため、開発者・インフラ管理者・経営層を含めたセキュリティ教育プログラムにOWASP Top 10を取り入れることも有効です。定期的な研修やハンズオン形式での演習と組み合わせることで、具体的な攻撃手法や防御策を理解しやすいため、セキュリティ意識の向上につながります。

OWASP Top 10はセキュリティ対策の出発点

OWASP Top 10は、Webアプリケーションの開発やセキュリティ対策に取り組む企業にとって、最も基本かつ重要な指標です。サイバー攻撃の多くは、実はこうした「基本的な脆弱性」から発生しており、OWASP Top 10で挙げられているリスクを理解することがリスク低減の第一歩になります。特に情報システム部門や開発チームは、OWASP Top 10を設計・開発・テスト・運用の各フェーズに取り入れ、継続的なセキュリティ対策を行う必要があります。また、社員へのセキュリティ教育や脆弱性診断サービスの評価基準としても有効活用することで、より実効性の高いセキュリティ体制を構築できるでしょう。

第2回では、API特有の脅威にフォーカスした「OWASP API Security Top 10」をご紹介します。APIを活用している企業にとって、見逃せない内容となっていますので、ぜひあわせてご覧ください。


―第2回「OWASP API Security Top 10とは?APIの脅威と対策を知ろう」へ続く―

【連載一覧】

―第2回「OWASP API Security Top 10とは?APIの脅威と対策を知ろう」―
―第3回「Non-Human Identities Top 10とは?自動化時代に求められる新しいセキュリティ視点」―

Security NEWS TOPに戻る
バックナンバー TOPに戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

前倒しで対処 -セキュリティを考慮したソフトウェア開発アプローチ「シフトレフト」とは-

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

シフトレフトとは、より早期の段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方です。ソフトウェアの開発工程の各フェーズにおいてセキュリティが組み込まれていないと、後工程での手戻りが発生し、修正コストもかかってしまいます。本記事では、シフトレフトによるメリットや開発におけるセキュリティ対策の実施例について解説いたします。

シフトレフト(Shift Left)とは

セキュリティにおける 「シフトレフト(Shift Left)」 とは、より早期の段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方です。元々この概念は仕様を満たしているか等の検証に対するソフトウェアテストのジャンルで使われていた言葉ですが、近年セキュリティの世界で注目されています。

ソフトウェア開発の主要工程である「設計」→「開発」→「検証」→「運用」の各プロセスは、計画書や図などで、通常左から右に向けて記載されます。図の左側(レフト)、すなわち時間軸の早い段階で脆弱性を作り込まない対策を施した開発を行えば、セキュリティリスクを低減させるだけでなく、品質向上、期間短縮、トータルコスト低減などの効果があります。

セキュアなWebアプリケーション開発を推進する国際NPO「OWASP(Open Web Application Security Project)」もシフトレフトを推奨しており、Googleをはじめとする先進IT企業ではこの考え方を採用したシステム開発を行っています。

シフトレフトの考え方

シフトレフトの考え方では開発工程からセキュリティ診断を組み込むことで、スケジュールに与える影響を最小限に、また計画的かつ定期的に実施頂くことで費用面、人材面のコストを抑えつつセキュリティの堅牢性向上を見込むことができます。

「要件定義」や「設計」等の上流工程の段階からシステム運用までの各フェーズで、セキュリティへの配慮を取り入れることが、より安全なシステムを構築するうえで重要となります。

セキュリティを開発の最終段階で対応したのではすでに遅く、開発プロセスの全フェーズにおいて常にセキュリティ上の課題を先取りして解決しながら進めることが、テストやリリースといった最終段階での手戻りを防ぎ、結果的にトータルコストの削減と品質の向上に寄与します。

「シフトレフト」と「セキュリティ・バイ・デザイン」「DevOps」「DevSecOps」との違い・関係

シフトレフトと関連する言葉に、「セキュリティ・バイ・デザイン」「DevOps(デブオプス)」「DevSecOps(デブセックオプス)」などがあります。

「セキュリティ・バイ・デザイン(SBD:Security by Design)」とは、開発の企画・設計段階からセキュリティを考慮することです。

「DevOps(デブオプス)」は、ソフトウェア開発チーム(Developer)と運用チーム(Operations)が互いに協力し合い、ソフトウェアとサービスのクオリティを向上させます。「DevSecOps(デブセックオプス)」は、開発チームと運用チームに、セキュリティチーム(Security)が加わり、セキュリティを含めトータルコストを低減しつつ、さらなるクオリティ向上を実現する仕組みです。

セキュリティ・バイ・デザインは概念、DevSecOpsは体制運用、そしてシフトレフトは工程管理の考え方ですが、いずれも、事故やトラブルが起こってから、あるいは脆弱性が見つかってから、といった事後対応のセキュリティ対策ではなく、事前対応、すなわち前倒しで実践する点で一致しています。

シフトレフトによって向上する品質

たとえば、ビルを建てた後になってから、建物の基礎部分に問題が見つかったら改修は容易ではありません。また、社会的な信頼も大きく損なうことでしょう。ソフトウェアも同じで、問題発見が早いほど、改修に必要な労力、費用、時間は少なくてすみますし、信用失墜の危険性も軽減できます。

リリース直前の脆弱性診断でWebアプリケーションに脆弱性が発見されたら、手戻り分のコストがかかるだけではなく、リリース日の遅れや、機会損失の発生を招き、ステークホルダーのビジネスにまで影響を及ぼしかねません。シフトレフトの考え方でセキュリティに配慮しながら開発を進めれば、こうしたリスクを低減でき、ソフトウェアの信頼度が高まります。

シフトレフトによるトータルコスト低減メリット

セキュリティに配慮せず開発を行えば、短期的にはコストを抑え、開発期間を短くすることができるでしょう。しかし、リリース後の運用過程で、もしサイバー攻撃による情報漏えいや知的財産の窃取などが起こったら、発生した損失や対応費用など、長期的に見たコストはより大きくなるでしょう。

こうしたトータルコストの低減効果こそ、シフトレフトによるセキュアな開発および運用の真骨頂です。

シフトレフトとは、発生しうるトラブルに事前に備えるということです。病気にならないように運動をしたり、食生活に気をつけたりといった、ごくごくあたりまえのことです。

つまり、これまでのソフトウェア開発は、その当たり前をやっていなかったとも言えます。シフトレフト、セキュリティ・バイ・デザイン、 DevSecOpsという言葉がいろいろな場面で見られるようになったことは、開発現場が成熟してきた現れでもあります。今後、こういった開発プロセスが新常識となっていくことでしょう。

シフトレフトを普及させた裁判の判決とは

ここで、セキュリティ視点でのシフトレフトの考え方を日本に普及させるきっかけのひとつになったとされる、2014年の、ある裁判の判決をご紹介します。

とある企業の開発依頼で納品されたオンラインショッピングのシステムに、SQLインジェクションの脆弱性があったことで、不正アクセスによる情報漏えい事故が発生しました。依頼した企業は、開発会社がセキュリティ対策を怠っていたことを債務不履行として提訴、東京地方裁判所がそれを認め、開発会社に約2200万円の損害賠償支払いを命じました( 平成23年(ワ)第32060号 )。ただし、全面的に開発会社の落ち度としたわけではなく、発注会社側が責務を果たしていない点については、相当程度の過失相殺を認めています。

この判決は、これまで技術者がいくらセキュリティの必要性を説いても首を縦に振らなかった、セキュリティよりも利益を重視していた「開発会社の経営管理層」と、セキュリティよりもコストと納期を重視していた「発注者」の考えを変えるインパクトを持っていました。

将来事故が起こらないよう、トータルコストを抑えセキュリティに配慮した開発を行う有効な方法としてシフトレフトが採用されたのは、ごく自然なことといえるでしょう。

シフトレフトに基づく開発におけるセキュリティ対策の実施例

シフトレフトに基づく開発におけるセキュリティ対策の実施例は以下のとおりです。

●セキュリティ・バイ・デザイン
まず、セキュリティ・バイ・デザインの考え方に基づいて、企画・設計段階からセキュリティを考慮しましょう 。

●セキュアな開発環境
開発は、脆弱性を作り込まないようにするフレームワークやライブラリなど、セキュアな開発環境を活用して行います。

●ソースコード診断
開発の各段階で、プログラムコードに問題がないかを適宜検証するソースコード診断を実施します。

●脆弱性診断
もし、どんなセキュリティ要件を入れたらいいかわからなくても、独立行政法人情報処理推進機構(IPA)などの専門機関がいくつもガイドラインを刊行しています。「このガイドラインを満たすような開発を」と依頼して、それを契約書に記載しておけばいいでしょう。ガイドラインの中身を完全に理解している必要はありません。

リリース前や、リリース後の新機能追加等の際には、必ず事前に脆弱性診断を行います。また、脆弱性が悪用された場合、どんなインシデントが発生しうるのかを、さらに深く検証するペネトレーションテストの実施も有効です。

シフトレフト視点での発注の仕方

シフトレフトは主に開発者側の考え方です。では、ソフトウェア開発を依頼する発注者はどうすればいいのでしょうか。

まず、発注の際には必ずセキュリティ要件を入れましょう。納品されたシステムやWebアプリケーションにセキュリティの問題が発見された際に対応を要求しやすくなります。

もしそれによって見積額が上がったら、トータルコストのこと、シフトレフトというこれからの新常識のことを思い出していただきたいと思います。

・安全なウェブサイトの作り方(IPA)
https://www.ipa.go.jp/security/vuln/websecurity.html

シフトレフトの実現に向けて

とはいえ、今回ご紹介したシフトレフトの考え方が社会に広く普及するまでには、もう少し時間がかかりそうです。

システムライフサイクルの早い工程(シフトレフト)でのセキュリティ対策の実施例の一つに、「ソースコード診断」があります。

実装工程でソースコードに作り込んでしまった脆弱性を検出するのが、「ソースコード診断」です。ソースコード診断では、他の種類の脆弱性診断では検出しづらい潜在的な脆弱性を、
開発ライフサイクルのより早い工程で洗い出すことが可能です。他の脆弱性診断に先駆けて実施されるべき診断と言えます。

セキュアコーディングを実践しつつ、ソースコード診断を効率的に行うためには、自動診断ツールを利用するのも有効です。静的コード解析を行うソースコード診断ツールの選定においては、以下のような点がポイントとなるでしょう。

SQAT.jp を運営する株式会社ブロードバンドセキュリティが、リリース直前のWebサービスに脆弱性診断を行うと、山のように脆弱性が発見されることがあります。

その脆弱性の中には、2014年の裁判で開発会社の債務不履行とされたSQLインジェクションのような、極めて重大なものが含まれていることも多くあります。

業界が成熟し、シフトレフトによるセキュリティ対策が実践されていけば、脆弱性診断というサービスの位置づけ自体が将来変わることすらあるかもしれません。たとえば自動車のような、安全規格に基づいて設計製造された製品における出荷前の品質チェック、あるいは監査法人による会計監査のように、「きちんと行われている前提」で実施する広義のクオリティコントロール活動の一環になるかもしれません。

SQAT.jp は、そんな未来の到来を少しでも早く実現するために、こうして情報発信を行い続けます。

まとめ

・シフトレフトとは上流工程でセキュリティを組み込み、トータルコストを抑えるという考え方
・セキュリティを考慮せずにWebサービスを開発し提供するのは、たとえるなら建築基準法を考慮せずにビルを建ててテナントを入居させるようなもの
・セキュリティをコストととらえ費用を惜しむと、将来的により高い出費を余儀なくされる可能性がある
・シフトレフトによるセキュリティ対策には、セキュリティ・バイ・デザイン、セキュリティ要件の明示、セキュアな開発環境、早期段階から適宜に実施する各種セキュリティ診断等がある

Security NEWS TOPに戻る
バックナンバー TOPに戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。


Security Serviceへのリンクバナー画像

BBsecコーポレートサイトへのリンクバナー画像

セキュリティ緊急対応のバナー画像

セキュリティトピックス動画申し込みページリンクへのバナー画像