ペネトレーションテストの準備

ペネトレーションテストは、合意したルールの下で専門チームにプロダクトへの攻撃を依頼し、発見された問題を報告してもらう取り組みです。顧客や監査人から求められることも多く、自社チームが見落としていた問題を見つける最良の方法の1つです。テストからどれだけの成果を得られるかは、事前の準備に大きく左右されます。

スコープを決める

テスターが攻撃してよい対象を正確にリストアップします。Webアプリ、モバイルアプリ、API、管理ツール、クラウドのアカウントなどです。環境やドメイン名も明確に指定してください。リストから漏れたものはテストされないため、自信がある部分だけでなく、顧客が重視する部分も含めましょう。ベンダーが運用しているコンポーネントがある場合は、対象に含めることが許可されているか確認してください。

実施ルールを取り決める

テスト期間、テスターの接続元アドレス、禁止事項（サービス拒否攻撃、ソーシャルエンジニアリング、実顧客データの利用など）、問題発生時の緊急連絡先を書面にまとめます。ホスティング事業者のセキュリティテストに関するポリシーを確認し、事前申請が必要な場合は通知してください。また、本物の障害や攻撃がテストの一部と誤認されて見過ごされないよう、監視アラートの担当者にはテストが進行中であることを伝えておきます。

環境とアカウントを準備する

コード、構成、セキュリティ設定が本番環境と真に一致している限り、ステージング環境をテストするほうが通常は安全です。あらゆる権限（ロール）のテストアカウントを用意し、別々の顧客組織に属する2つのアカウントも含めてください。これにより、ある顧客が別の顧客のデータを閲覧できないかをテスターが検証できます。多数の顧客に提供するプロダクトでは、これが最も重要な発見事項になることがよくあります。

外部からの視点を意図的に検証したい場合を除き、ドキュメント、API仕様書、認証情報を共有してください。内部者が知る情報を持った状態で始めることで、テスターは基本情報の調査ではなく、脆弱性の発見に時間を充てられます。

深刻度と影響範囲に基づいて修正する

報告書では指摘事項が深刻度順にランク付けされます。重大（Critical）や高（High）のものを優先して修正しますが、それぞれの問題が及ぼしうる影響範囲にも目を向けてください。社内ツールの「高」よりも、ログインページの「中」のほうが重要な場合もあります。監査人や顧客から対応状況を尋ねられることがあるため、各修正についての簡単な記録を残しておきましょう。

再テストを依頼する

多くのテスターは、修正した指摘事項の再テストを提供しています。これをぜひ活用してください。再テストによって修正が有効であることが確認され、問題が解決済みであることが示された最新の報告書が得られます。顧客が見たいのはまさにその結果です。

適切な文書を共有する

プロダクトへの攻撃手順が詳細に記された完全な報告書を顧客が必要とすることは滅多にありません。テスターに受検証明書（Letter of Attestation）を依頼してください。これはスコープ、実施日、結果をまとめた簡潔なサマリーで、自由に共有できます。完全な報告書は、知る必要がある関係者のみに限定して共有しましょう。

まとめ

明確なスコープ、文書化されたルール、本番環境と一致する検証環境、全ロールのテストアカウント、そして修正後の再テスト。これらを準備しておけば、テスト報告書は予想外のトラブルではなく、確実な改善計画になります。