SaaS脆弱性診断の検査項目と準備｜ログイン・権限・API

最初に「誰が、何をできるか」を整理する

管理者、一般利用者、閲覧専用ユーザーなど、SaaSには異なる権限を持つ利用者が存在します。診断前に役割と操作の対応を整理しておくと、画面上では操作できない機能をAPIから実行できないか、別の顧客のデータを参照できないか、といった検査を計画しやすくなります。

ユーザー登録、招待、ログイン、権限変更、エクスポート、退会など、データや権限の状態が変わる機能も一覧化しましょう。課金・承認フローなどの業務ロジックは、サービス固有の前提を共有する必要があります。

検査範囲を決めるためのチェック項目

この表は検査計画を考えるための例で、網羅的な合格基準ではありません。実際に必要な項目は、扱う情報、利用者、システム構成に応じて決めます。

AIと検査ツールを、どう組み合わせるか

コードを読む静的な検査、動作するサービスに対する動的な検査、依存ソフトの確認などでは、見つけやすい問題が異なります。NISTのソフトウェア検証ガイダンスも、脅威モデリング、自動テスト、コード解析、Webスキャナーなど複数の手法を示しています。

AIは検査計画の整理や結果の分類を支援できますが、AIの説明がもっともらしいことと、脆弱性が実際に存在することは同じではありません。発見事項は実行結果と結び付け、誤検出や見逃しの可能性も考慮して評価します。

診断前に合意しておきたい実施条件

• 診断を許可する管理者と、対象URL・API・環境の範囲
• 実施期間、負荷の上限、停止条件、緊急時の連絡方法
• 本番環境と検証環境の差、および対象外となる機能
• テスト用アカウントの権限、利用可能なダミーデータ
• コードやログの受け渡し方法、保管・削除条件
• AIサービスへの情報送信の有無と、その対象

依頼時点で秘密情報を通常の問い合わせフォームへ送る必要はありません。必要な情報と受け渡し方法を、先に診断事業者と調整してください。

報告書と再診断で確認すること

報告書には、診断対象と実施日だけでなく、対象外、発見事項の影響、再現に必要な条件、是正方針が記載されているかを確認しましょう。件数の少なさだけで品質を判断せず、予定した検査を完了したかを見ることが重要です。

修正後の再診断では、コード変更の有無だけでなく、問題の挙動が解消したかを確認します。認証や取引先向けの説明に利用する場合は、是正前後の対応関係がわかる記録を残しておくと役立ちます。大きな機能変更や新しい脆弱性情報への対応は、別途再検査の条件を決めましょう。