実稼働環境でセキュリティー・スキャンを実行する際のベスト・プラクティス

実稼働環境におけるセキュリティー・スキャンの実行は、リスクがあります。しかし、実稼働環境のスキャンが必要な場合もあります。例えば、監査要件に準拠するため、サイトがハッキングされたかどうかを検出するため、またはセキュリティー・スキャンの統合に SDLC プロセスが用いられていることを検証するためなどです。

理由に関わらず、常にまず実動前環境でスキャンしてから、実稼働環境のスキャンを行うことが最適です。このようにすれば、セキュリティー・テストがサーバーに与えるリスクを最小限にすることができます。

Learn more about known security risks when scanning a production site:
  • 最も重大: スキャンによってサーバーまたはアプリケーションが停止する可能性があります。
  • 注意が必要: スキャンが同じ要求を多くの (1 つのパラメーターにつき約 40 の) バリアントでサーバーに再送します。これらの要求の一部はサーバーで拒否されますが、多くはサーバーを通過してアプリケーションによって処理され、以下のアクションを引き起こす可能性があります。
    • データベースのレコードが追加または変更される
    • 完全なトランザクション。アプリケーションが実行するように設計されている購入など。
    • E メール・フラッディング。フォームがメーリング・リストまたは個人に E メールを送信すると、受信者は大量の E メールを受け取る可能性があります。
    • サイトの改ざん。サイトにフォーラム・ページがある場合、スキャンを実行すると、そのページに多くのエントリーが送られる可能性があります。その中には、クロスサイト・スクリプティングによるポップアップ・ウィンドウが含まれる場合もあります。
    • サイトの全面的な変更。サイトで (作成、編集、および削除ボタンなどによる) 変更が許可されている場合、通常の要求に加えて多くのバリアント要求が送信されます。
    • Initiate® ベンダー・サービスに対する要求. これらの要求は、サービスを大量に要求し、トランザクションを実行するため、潜在的なコストが発生する可能性があります。
    • IDS/IPS チームに対して警告が出される (侵入検知システム/侵入防御システム)。テストは大量のシグニチャーを使用して IDS/IPS をトリガーします。テストは実際の攻撃ではなく、アプリケーションに害を与えるようには設計されていません。ただし、IDS/IPS チームはこれを知らないため、攻撃として対処します。
    • IDS および IPS システムで、テストがアタックとして報告される。

以下のベスト・プラクティスは、実稼働環境へのセキュリティー・スキャンのインプリメントのためのものであり、リスクは最小限にとどめ、価値は最大限にしています。

テスト・ユーザー・アカウントの使用

サービスの注文が実際には行われず、アカウントが壊れた場合にはリセットできるように、追跡可能なテスト・アカウントを使用してください。さらにテスト・アカウントにより、管理者がテスト後にサイトをクリーンアップすることがより簡単になります。テスト・アカウントについては、以下を考慮してください。

  • それはデータベース内のテスト・レコードだけにアクセスするようにする必要があります。これにより変更されたレコードを復元できます。
  • テスト・アカウントにより作成された新規レコードは削除します。
  • テスト・アカウントからの購入注文または他のトランザクションは無視します。
  • サイトにフォーラムがある場合、テスト・アカウントはテスト・フォーラムだけにアクセスするようにする必要があります。これにより実際の顧客がテスト・フェーズ中にテストを表示することはできません。例えば、クロスサイト・スクリプティングのポップアップ・ウィンドウが表示されると、顧客を驚かせてしまう可能性があります。
  • サイトがさまざまなアカウントに対してさまざまな特権を使用する場合は、複数のテスト・アカウントを使用します。複数のテスト・アカウントを使用すると、アプリケーションをさらに総合的にテストすることができます。

ユーザー受諾およびパフォーマンス・テストの実施

通常のユーザー受諾およびパフォーマンス・テストを扱うようにアプリケーションが実稼働環境内で構成されるまでは、実稼働環境内でセキュリティー・テストを実行しないでください。アプリケーションがこれらのタイプのテストを扱うことができない場合、スキャン・ジョブにより送信された、形式変更された要求を扱うことはできません。

承認の取得

ビジネス所有者および開発チームに相談したり、その承認を取得せずにアプリケーションを一方的にスキャンしたりすると、ほぼ必ず大きな問題となります。テストをいつ実行し、いつ完了する予定なのか、必ず前もってすべての関係者に通知してください。

スキャンを実行する適切な時刻の設定

スキャンは、サイトの通常の操作期間の妨げとならない、夜間などの事前設定時刻に実行します。

安全でないテストの実行を見落とさない

安全でないテストはデフォルトでは実行されませんが、完全テストにとってはこれは非常に重要です (例えば、バッファーのオーバーフローによりインターネットのワームが持ち込まれたりします)。安全でないテスト、安全なテストを問わず、どのテストであってもサイトをダウンさせる可能性があります。

E メールのフラッディングの回避

E メール通知を使用するページを識別し、それらをスキャンから除外するように構成します。E メール通知は、多くの要求を生成し、E メール・サーバーにとって過負荷となる可能性があります。これらのページを識別することは難しい場合がありますが、使用できるいくつかの手法を以下に示します。

  • ページを QA でテストし、それらを実動で除外します。QA で、E メール・アドレスをダミーのメールボックスに変更します。
  • 実動では、1 つの Web サーバーだけをテストし、テスト中にそれが SMTP サーバーに接続しないようにします。または、テスト前に E メール・アドレスを置き換え、テスト後にそれを復元するスクリプトを用意します。
  • スキャンを構成し、E メール・フィールドの 1 つに固有値を配置して、受信側が検索を実行し、そのすべてを消去できるようにします。「フォームの自動入力」スキャンを使用して、この機能を実行します。

事前のクリーンアップ・スクリプトの作成およびテスト

実動スキャンを実行した後に、スキャンによって作成されたテスト・データを除去するために、クリーンアップ・スクリプトまたはプログラムを使用します。

セッション・パラメーターおよびトークンの識別

セッションを無効にするセッション・パラメーターおよびトークンを識別します。一般にこの情報はアプリケーション所有者から入手できます。コンテンツ・スキャン・ジョブの「パラメーターおよび Cookie」ページにセッション・パラメーターを追加します。

アカウント無効化ルーチンの識別

すべてのアカウント無効化ルーチンを識別します。スキャンではこれらのルーチンを、除外として追加することで回避する必要があります。

  • 可能な場合は、失敗したパスワード試行に対してアカウント無効化をオフにします。
  • アカウント無効化をオフにできない場合、テスト・アカウントとパスワードを使用して、それぞれのログイン・ページを個別にスキャンします。

認証なしのスキャンの考慮

アプリケーション外部で認証なしでアクセスできるページを、個別のスキャン・ジョブを使用してスキャンします。外部からのスキャンの実行により、さらに多くの問題を検出することができ、検出されたセキュリティー問題に誰がアクセスするかを把握できます。

機密領域を識別するための対話式スキャンの使用

パスワード変更ページ、管理設定ページ、またはユーザー管理ページなどの、対話を必要とする領域を扱う個別のジョブを作成します。

IDS/IPS システムの無効化

IDS/IPS システムにより、テストが妨げられ、露呈するはずの問題が隠される場合があるので、これらのシステムは無効にするか、またはそれを回避してスキャンするのが最善です。少なくとも、IDS/IPS チームに注意を促す必要があります。

プロキシー経由でスキャンしない

プロキシ―経由でのスキャンがサポートされている場合、問題が隠される可能性があります。例えば、HTTP プロキシーによりサーバー・エラー応答が改ざんされ、セキュリティー問題が隠される場合があります。