システムの脆弱性・セキュリティ診断の計画のポイント

今回はウェブシステムの脆弱性診断を受ける際の注意点について話していきたいと思います。

脆弱性診断の実施は顧客に対しては、セキュアなシステムであることのエビデンスになりますし、開発エンジニアにとって、それにより自分たちが見逃していたセキュリティ上の課題を見つけ出すことができます。しかし、この診断サービスをうまく利用するためには、いくつかの重要なポイントを理解しておく必要があります。はじめて脆弱性診断を計画する方が、スムーズに診断を行う手助けとなればと思い、この記事を書きます。

診断サービスを提供している会社は数多くありますが、やり方は大きく分けて以下の三つに分類されます。

それぞれの方法には一長一短があり、コストもそれぞれ異なります。

自社でツールを使用する場合、かかるコストはツール使用料のみですが、社内にセキュリティの知識を有するエンジニアがいない場合、ツールを使用しても正確な結果が得られない可能性があります。一方外部に委託して全画面を手動でテストする場合、エンジニアの稼働時間や専門的な知識が必要となるため、コストは大幅に上昇します。

このような状況を考慮し、ログイン認証など重要な画面には手動診断を行い、その他の部分はツール診断を行うハイブリッドな診断方法を選択することが、現実的な選択肢となることが多いです。

脆弱性診断には、アプリケーションを評価する場合とサーバインフラを評価する場合があります。

アプリケーション診断では、Web Application Firewall (WAF)を無効化しておかなければ、テストは意味をなしません。WAFが有効な状態でテストを行うと、本来評価すべきアプリケーションではなく、WAF自体の評価を行ってしまいます。AWSのCloudFrontなどのWAFは、コンソールからの操作で無効化することが可能です。

一方、サーバの診断では、テストを行う前にIPアドレス制限の追加や必要なポートを開放しておく必要があります。AWSのEC2やLightsailといったサービスでは、AWS側の設定変更とLinux側の設定変更の2つが必要になります。これらの設定はテストの目的によって変わる可能性がありますが、一般的にはCDNのセキュリティ評価よりも、サーバそのもののセキュリティ評価が重要となることが多いため、ポートを一時的に開放するといった準備は必要という認識でよいと思われます。

なお、診断ツールの提供元からは上記のような情報が積極的に提供されないこともあるので、導入の際には診断ツールのベンダーにもしっかりと問い合わせておくことが重要です。

診断結果が出たら、それに対する対応が必要となります。しかし、すべての結果に対して直接的な対応が可能なわけではありません。アプリケーションやサーバアーキテクチャの特性により、対応が難しい場合もあります。そのような場合、以下のように対応を整理することが有効です。

診断を助けるツールとして以下のものがあります。これらは自社でも実施できるものですが、正しい結果を得るためには、やはりセキュリティの知識は必要です。

アプリケーションの脆弱性を自動で検出し、詳細なレポートを提供します。多機能でありながらもユーザーフレンドリーなインターフェースを持っています。有償のソフトウェアですが、安価な部類に入ると思います。また国内での導入実績も豊富ですので、費用を抑えつつ診断を実施したいという方向けです。管理画面のUIも使いやすく、技術的な問い合わせも可能です。

OWASPが開発した、無料で使えるWebアプリケーションセキュリティ診断ツールです。豊富な機能とコミュニティによる強力なサポートが特徴です。オープンソースで無料で利用できますが、テスト結果の解釈など、有償ツールよりは取り扱いが難しい印象です。

自社で実施した脆弱性診断ツールで問題ないという診断を出しているとき、診断方法が間違っているため、正しい結果が得られていないというケースがあります。脆弱性診断がプロジェクトのなかに組み込まれている場合、早めにテストの目的や、診断方法など具体的な計画を詰めていくようにしましょう。