(1/2)当連載ではWebアプリケーションのセキュリティが置かれている状況と、サイバー攻撃について具体的なデータを示し、防御策を紹介している。第1回と第2回ではWebアプリケーションの攻撃対象となる領域と、領域ごとの被害例に加えて、Webアプリケーションが攻撃を受けるまでにたどるプロセスについて簡単に整理した。今回は、Webアプリケーション側で可能な対策について脆弱性への対応とWAFを中心に解説していく。});この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。Firewall)」に加え「それらの運用を今の人的リソースで回せるのか」などが挙がるだろう。これら全てを網羅的に対策できることがもちろん望ましい。現実には、人員や予算、リスク、その他の要因があり、100点満点を取れる企業は多くないだろう。具体的にどのような手段で対策をとるかを考える前に、何点を目指す(何をどこまでやる)のか、目標を立てることも大事な要素であると筆者は考えている。連載第2回でも触れたように、インターネットに公開されているWebサイトは次のような特性を持っている。インターネットに公開しているシステムは、不特定多数からアクセスされる守る側と攻撃側は、1対1ではなく、1対多となることを常に想定する必要がある防御側が圧倒的に不利な状況に加え、そもそも脆弱性のないシステムは存在しない。この前提に基づくと、例えば100%攻撃を防ぐことを目指すのではなく、どうすれば攻撃側のROI(投資対効果)を下げられるか(攻撃者に面倒くさいサイトだと思わせるか)という観点が浮かび上がる。「セキュリティ対策=リスク低減策」と捉える上で、一つの現実的な考え方といえるだろう。Webサイトのセキュリティ対策を検討するに当たっては、インシデントの発生リスクを低減するための予防的対策が必要だ。その後の情報公開の体制などについてもプレイブック(基準および手順書)を用意しておくことが望ましい。今回はこのうちインシデントの発生リスクを低減するための予防策について考察していこう。公表された脆弱性に即応できるとは限らない外部脅威によるセキュリティインシデントが発生するシステムには、何らかの脆弱性が存在する。システムに潜む脆弱性を平時にセキュリティ担当者がどのように認識するのかというと、次のようなパターンが考えられる。新たに発見された脆弱性に対して抜本的に対応するなら、OSやミドルウェアのバージョンアップやシステムパッチを施すことが望ましい。脆弱性公表後に即座に対応することが容易ではないケースも多い。次のような理由があるからだ。OSやミドルウェアの脆弱性は予告なく公開されるサーバ保守作業の外注化などで、そもそも即座に作業できる体制が整っていない改修作業に伴うシステム停止ができるか、判断基準が明確になっていない作り込まれたアプリケーションでは、脆弱性改修が難しい。モジュールやミドルウェアの相互依存性チェックを踏まえた動作確認などに時間がかかる「公開された脆弱性が、自社のWebアプリケーションで悪用される可能性はあるか」という判断はシステムごとに違う。システム停止や改修作業をすべきか即座に判断でき、緊急度を判断できるスキルを有し、かつ実行に移せる組織やシステム管理者は、実際にはほんの一握りだろう。脆弱性検査では空白期間に用心もう一つの方法である脆弱性検査/ペネトレーションテストでは、システム全体に潜む脆弱性を主に外部からの検査で洗い出す。アプリケーションのリリース前はもちろん、その後も定期的に実施することで、システムにできた“穴”をつぶすことができる。その検査結果だけから「安全宣言」を出すことは少々早計と言わざるを得ない。いうのは、通常こうした脆弱性検査は、一定の周期(例えば半年に一度)で外部の専門家に委託して実施するからだ。一方で、それより早いペースで未知の脆弱性は日々公開されている。検査と検査の間の空白期間を埋める施策が必要になる。具体例を挙げてみよう。Server」の脆弱性を例にとった。定期的に実施する脆弱性検査と新たな脆弱性を使った攻撃との関係を時系列で示したものだ。Serverの脆弱性を使った攻撃と脆弱性検査との関係このケースでは深刻度の高い脆弱性が2019年4月25日と同6月18日に、比較的短い間隔で公開されている。Serverを利用しているシステムの脆弱性検査が、その間の時期(例えば5月)に行われた場合、次の検査のタイミングが半年後なら11月となる。6月18日に公開された脆弱性を使った攻撃が7月に行われた場合、このシステムは「脆弱性検査をしたから安全性は確認済みだ」といえるだろうか?実際、新たな脆弱性を利用した攻撃は、情報公開後すぐに始まることが多い。検査と検査の間をつなぐ形で、継続的かつ速やかに対策を取る仕組みが必要だと分かるだろう。Firewall)である。その役割を、「攻撃者が攻撃を行う際のプロセス」に沿って解説していこう。連載第2回でも示した「攻撃者が攻撃を行う際のプロセス」を少しおさらいしてみる。一般にWebアプリケーション攻撃は以下の手順で進む。偵察行為の通信には次のような特徴がある。TCPレベルの通信が多い——サーバ側の情報をWebプロトコルに限定せずに広く収集するHTTPレベルの通信が多い——Webアプリケーションの構成情報などを収集する一般的なWAFはこのうち、HTTP/HTTPSといったWebプロトコル以外のTCP通信をブロックする。WAFを経由したTCPのポート番号80、ポート番号443以外の通信は、直接Webアプリケーションに届くことはない。単純な偵察行為を妨害できる。HTTPレベルの情報収集では、大量のHTTPリクエストを送信してくる傾向があるため、単位時間当たりのリクエストレート数を調べて制御することで偵察行為を抑制できる。一部のWAFは「IPレピュテーション」機能を備えている。ビッグデータ解析によって、過去に脆弱性スキャニングや攻撃に悪用されたことのあるIPアドレスの危険度を判定して、リスクの高いIPからの通信を全てブロックする機能だ。ここで紹介したのはいずれも、「標的にされるネタとなる情報を与える」ことを阻止するものだ。「脆弱性の発見」フェーズの傾向と対策2番目の「具体的な脆弱性を発見」するフェーズの通信には次のような特徴がある。HTTPレベルの通信が多い——HTTP通信でエラーが大量に発生するリクエストに攻撃コードが含まれているWebアプリケーションの脆弱性を発見するスキャニングでは、標的にどのような脆弱性があるかを確認するため、大量のHTTPリクエストを送り付ける傾向がある。このとき、Webサイトにとってイレギュラーなアクセスが増えるため、HTTPエラーの発生も多い。このことから、WAFによる対策としてはHTTPレスポンスのエラーをカウントするようなレート制御が有効である。脆弱性を発見するため、実攻撃と似たリクエストが送信される傾向もある。このため、WAFの攻撃検知ルールや、IPレピュテーションによる検知が効いて、阻止することも可能だろう。言うまでもなく、実際の攻撃に対してはWAFが備える全ての機能が有効である。Webアプリケーションに対する実攻撃を防御するための仕組みがWAFだと単純に捉えられがちだ。ここまで順を追って示したように、偵察行為や脆弱性を見つけようとする行為に対しても、事態の進行を阻止して「狙われにくくする」対策が可能である。プロセスの段階が初期であればあるほど、対策の難易度を低く抑えることができる。図2に示したようにWAFによって偵察/情報収集を食い止めることが、効率的なセキュリティ対策につながる。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。