Application Security Reviewとは

何であるのか

このレビューでは、合意したアプリケーションの範囲を調べ、意図的な不正利用、境界条件、そして認証回避、権限昇格、インジェクションの欠陥、安全でないデータの取り扱い、セッション管理の弱点といったよくあるセキュリティ上の懸念に対して、アプリケーションがどう反応するかを確認します。スコープは作業開始前に書面で確定します。選択するサービスに応じて、ユーザー向けのエンドポイント、管理画面、APIの動作、クライアント側の制御、外部の依存関係、開発時の安全な設計判断を示す証跡のレビューなどが含まれます。担当者は、手動テスト、ドキュメントのレビュー、必要に応じて限定的な自動スキャンを組み合わせ、合意した範囲内でアプリケーションのセキュリティ状況を把握します。何が観察されたか、実際の攻撃シナリオでどう関係し得るか、どのような是正策が釣り合いがとれているかを説明する体系的な指摘事項報告書をお届けします。このレビューは、社内での優先順位付けに役立てるためのものであり、本番環境を妨げたり、機密性の高い顧客データに不必要にアクセスしたりするものではありません。

誰のために

Application Security Reviewは、次のような企業に適しています。

• 顧客向けアプリケーション、SaaS製品、デジタルサービスを運営しているものの、アプリケーションレベルの動作について正式なセキュリティレビューをまだ受けていない企業
• 大型リリース、機能の公開、市場拡大を控え、変更を本番に反映する前にアプリケーションセキュリティをより明確に把握したい企業
• 大企業の顧客、取引先、投資家から、アプリケーションレベルのレビューの証跡を求めるセキュリティ質問票や妥当なデューデリジェンスの依頼を受けている企業
• 次の是正策を選ぶ前に、設定上の問題、インフラの露出、アプリケーション層の欠陥を区別する必要がある企業

明確にするのに役立つこと

アプリケーションセキュリティレビューでは、次の点が明確になります。

• ユーザー向け機能と管理機能のうち、意図的な不正利用に対して想定どおりに動作するものと、不正アクセスやデータの露出を許す可能性があるもの
• クライアント側の検証、推測可能な識別子、認可チェックの欠如、弱いセッション処理に依存しており、実際のシナリオで悪用され得る箇所
• 露出をもたらす外部ライブラリ、API連携、依存関係と、その緩和策が導入済みか、欠けているか、不十分か
• 次のリリース前に対処すべきこと、設計面の協議が必要なこと、エスカレーションまたは別スコープとすべきこと

含まれる内容

• レビュー対象のアプリケーション、ユーザーロール、エンドポイント、機能を明記した書面によるスコープ確認
• 合意したユーザー向け機能と管理機能に対する手動テスト、および必要に応じた限定的な自動テスト
• 優先度付きの指摘事項、実際の攻撃シナリオ、明確な是正指針をまとめた体系的な指摘事項報告書
• 各指摘事項が実際の状況でどう重要になり得るかの平易な説明（単なるツールの出力や深刻度スコアではありません）
• 非技術系の関係者との社内協議に使える経営層向けサマリー
• 指摘事項、優先順位、妥当な次のステップを確認するフォローアップの打ち合わせ1回

含まれていないもの

• 別途スコープを定めない限り、インフラ、ネットワーク、ホスティング層の管理策全体を対象とする本格的なペネトレーションテスト
• コンプライアンス認証、監査上の承認、アプリケーションが該当するすべてのセキュリティ要件を満たしているという表明
• レビュー期間中のアプリケーションにおける是正作業、コード変更、設定変更
• 業務終了後の継続的な監視、インシデント対応、継続的な再テスト
• 書面のスコープに含まれていないアプリケーション機能、ユーザーロール、API、連携のレビュー

それを選ぶべきとき

リリース、顧客からの質問、社内の計画サイクルの前に、アプリケーションがセキュリティ上の懸念をどう扱っているかについて、意図的で証跡に基づく見解が必要な場合は、Application Security Reviewをお選びください。アプリケーションが評価できる程度に安定しており、ユーザーロールと主要な業務フローが把握され、指摘事項を受け取って対応できる明確な社内担当者がいる場合に、妥当な一歩となります。中心となる課題がアプリケーションの動作ではなく、設定、アクセス権限、ホスティング設定に関するものであれば、Security Baseline Reviewのほうが適切な場合があります。懸念が開発手法、リリースの規律、チームレベルのセキュリティプロセスに関わる場合は、Secure SDLC Reviewをご検討ください。アプリケーションのレビューが最も効果を発揮するのは、作業開始前に、アプリケーションの責任者、技術窓口、許容できるテスト方法、期待する成果を企業側で示せる場合です。

私たちのアプローチ

まず、アプリケーションの範囲、ユーザーロール、テスト方法を書面で確定します。概要書では、アプリケーションのURLまたは環境、テスト対象のユーザー種別、テスト環境に対して許容されるリスク、必要なアクセス、スコープから除外するものを明記します。テストは、この確認が得られた時点で開始します。テストは合意した機能を調べるよう設計されており、特に合意し管理された場合を除き、意図的にサービスを妨げたり、本番環境の顧客データにアクセスしたりすることはありません。合意したスコープを超える詳しい調査が必要な指摘事項がある場合は、合意なく作業を広げるのではなく、その指摘事項を記録し、適切な次のステップを協議します。指摘事項は、何が観察されたか、どのように悪用され得るか、釣り合いのとれた是正策は何かという実践的な文脈とともに記述します。報告書は、どの変更をいつ計画するかについて、開発、製品、経営の各チームが落ち着いて検討できる対話を支えるためのものです。引き渡し時には貴社と一緒に指摘事項を確認し、報告書が放置される一覧ではなく、現実的な実行計画に役立つものとなるようにします。

よくある質問

関連記事