IPA
分冊1 分冊2 分冊3 分冊4 分冊5 分冊6
※アイコンの説明
サーバー サーバー
ネットワーク ネットワーク
クライアントPC クライアントPC
アプリケーション アプリケーション

2 公開Webサイトの運用におけるセキュリティ対策

2.1  技術的な対策

ここでは、公開Webサイトを運用する上での脅威に対する技術的なセキュリティ対策を説明する(図表9)。ここに登場するセキュリティ対策は、リスクに応じて導入することが望ましい。

図表9 公開Webサイト運用における技術的なセキュリティ対策

図表9 公開Webサイト運用における技術的なセキュリティ対策


2.1.1 アプリケーション開発時の留意点 アプリケーション

この対策により防ぐことができる脅威
1.4.1 Webサイト内の情報の書き換え、漏洩などの攻撃
1.4.4 電子商取引サイトの運営にまつわるトラブル

(1) セキュアなプログラミングの実践

SQLインジェクションやクロスサイトスクリプティングのように、プログラム開発時のコーディングミスによる脆弱性を突いた攻撃が圧倒的に多いことは先述したとおりである。これらを防ぐためには、脆弱性を生まないようにプログラムを作成することが要求される。
  SQLインジェクションによる攻撃を防ぐためには、プログラミングの時点から不正なSQL文を実行しないように対策することが必要である。以下に、SQLインジェクションの対策方法を示す。
  • SQL 文の組み立てにバインド機構 3を使用する。バインド機構を使用できない場合は、SQL 文を構成する全ての変数に対しエスケープ処理 4を行う
  • Webアプリケーションに渡されるパラメータにSQL 文を直接指定しない
  • エラーメッセージをそのままブラウザに表示しない
  • データベースアカウントに適切な権限を与える
クロスサイトスクリプティング脆弱性を排除するためには、解決法としてプログラミングの時点から対策することが必要である。以下に、クロスサイトスクリプティング脆弱性への対策方法を示す。
  • Webページに出力する全ての要素に対して、エスケープ処理を施す
  • URL を出力するときは、「http://」や 「https://」で始まるURL のみを許可するようにする
  • <script>...</script> 要素の内容を動的に生成しないようにする
  • スタイルシートを外部サイトから取り込めるようにしない
  • 入力値の内容チェックを行う
  • 入力されたHTMLテキストから構文解析木を作成し、スクリプトを含まない必要な要素のみを抽出する
  • 入力されたHTMLテキストから、スクリプトに該当する文字列を排除する
SQLインジェクション、クロスサイトスクリプティング脆弱性への対処の詳細については、以下を参照していただきたい。

IPA「安全なウェブサイトの作り方」
http://www.ipa.go.jp/security/vuln/documents/website_security.pdf

(2) 法令遵守(コンプライアンス)

経済産業省では、電子商取引等に関する様々な法的問題点について、民法をはじめとする関係する法律がどのように適用されるのか、その解釈を示すことで、取引の円滑化を目的した「電子商取引及び情報財取引等に関する準則」を公表している。準則では、契約に関する問題や、消費者を保護するための画面設定、知的財産に関する内容等が盛り込まれており、電子商取引を行っているWebサイトの関係者は一読することをお勧めする。図表10はその一例である。

図表10 インターネット通販における分かりやすい申込画面の設定義務

図表10 インターネット通販における分かりやすい申込画面の設定義務

図表10 インターネット通販における分かりやすい申込画面の設定義務
(出所)経済産業省「電子商取引及び情報財取引等に関する準則」(経済産業省、平成19年3月)

個人情報をWebページから取得するページを作成する場合は、あらかじめ利用者本人に対しその利用目的を明示しなければならない。具体的には、本人が送信ボタン等をクリックする前等にその利用目的(利用目的の内容が示された画面に1回程度の操作でページ遷移するよう設定したリンクやボタンを含む。)が本人の目に留まるよう、その配置に留意する必要がある。

(3) その他の留意点

その他、利用者の保護、あるいは不正アクセスの未然防止のために、必要に応じて以下の機能を組み込むことが望ましい。
●タイムアウト
パスワードにより利用者のアクセスを許可するWebサイトでは、一定時間操作が行われない場合に強制的にログオフする。
●利用者にログイン・ログオフ履歴情報を提供する
利用者がログイン、ログオフした履歴を利用者に提供する。その他、利用者がログインした時に前回のログオフ日時を表示する、など。
●パスワード入力失敗の回数制限
パスワードの入力を一定回数失敗した場合は、当該IDを一時的に使用不可とする。




2.1.2 サーバーにおける基本的なセキュリティ対策 サーバー

この対策により防ぐことができる脅威
1.4.1 Webサイト内の情報の書き換え、漏洩などの攻撃
1.4.2 Webサーバーへのアクセスを不可能にする攻撃

サーバーは常に攻撃される脅威に晒されているため、特にセキュリティ対策を万全にしておく必要がある。

(1) セキュリティパッチの適用

攻撃者は攻撃する際に、まず公開Webサーバーに存在する脆弱性を突いてくると考えられる。したがって、公開Webサーバーにセキュリティホールを残しておくことは危険である。また、セキュリティホールは、公開Webサーバーを構成するOS、Webサーバー、Webアプリケーションなど構成要素の全てに存在する可能性がある。公開Webサーバーの管理者は、公開Webサーバーの構成要素の全ての脆弱性に関する情報を常日頃から収集しておくことが重要である。団体、企業などによってセキュリティホールの情報を収集・公開している代表的なサイトとして、次のサイトがある。
  • SecurityFocus(英語)(http://www.securityfocus.com/)
  • IPA(http://www.ipa.go.jp/security/)
  • JPCERT/CC(http://www.jpcert.or.jp/)
セキュリティホールが発見され、セキュリティパッチが公開された場合は、速やかにセキュリティパッチを入手し、テストを行った上で適用する。セキュリティパッチは、各ベンダーのWebサイトから入手することもできる。

(2) 不要なサービスの停止やアプリケーションの削除

不要なサービスはサーバー管理者の意識から外れることが多く、脆弱性が放置されやすい。したがって、公開Webサーバー上では不要なサービスを停止するか、もしくはそのもの自体を削除することが必要である。さらには、サービスを提供しているポート以外に対する要求に対し応答を返さないよう、サーバーにおいてフィルタリングすることが望ましい。

(3) 管理者権限のアカウントの変更

管理者権限のアカウントは、サーバーに対してすべての操作を行うことができる権限を持つ。デフォルトの設定では、管理者権限のユーザーIDはWindows系OSではAdministrator、UNIX系OSではrootとなっている。これらは攻撃者に最も狙われやすいアカウントである。パスワードクラックツールなどによるパスワード推測攻撃においても、管理者権限のアカウントのユーザーIDがデフォルトの設定のままだと、パスワードのみを推測すればよく、攻撃が容易となるため、管理者権限のアカウントに対して不正アクセスを許す危険性が高くなる。したがって、管理者権限のアカウントのユーザーIDをデフォルト設定とは別のユーザーIDに変更しておくことが有効である。

(4) 不要なアカウントの削除

サーバーを運用する上で、使用していないアカウントを残しておくと、そのアカウントがセキュリティホールになる危険性があるため、不要なアカウントは削除しておく必要がある。例えば、多くのUNIX系OSでは、インストールした状態で多数のアカウントが存在している。必要がなければ削除することが望ましい。

(5) 安全なパスワードの設定

安全なパスワードとは、他人に推測されにくく、パスワードクラックツールなどでも割り出しにくいパスワードのことである。安全なパスワードには、アルファベットの大文字、小文字、数字や記号を含んでおり、名前などの個人の情報から推測されないものが望まれる。よりセキュリティ強度を高めるために、ワンタイムパスワードを導入することも検討すべきである。

(6) パスワードに対するポリシー設定

Windows系OSの場合、パスワードに対するポリシーとして、長さや有効期間、複雑さやロックアウトの設定ができるため、ポリシーを決定し適切に設定しておくことが望まれる。UNIX系OSの場合は、PAM(Pluggable Authentication Module)を使用することで、Windows系OSと同等の機能を実現することができる。

(7) ログの取得

Windows系OSやUNIX系OSにはログを取得する機能がある。ログ取得機能を使用することで、ローカルやネットワークを介してサーバーに対して行われた操作内容をログとして記録することができる。ログを取得する際は、以下の点について留意しておくことが望ましい。

●ログの遠隔保存
攻撃者は、攻撃者自身の不正アクセスの履歴を消すために、ログを削除する場合がある。そのため、ログの格納場所をサーバー上だけではなく、ログ専用サーバー(ログサーバー)に飛ばすようにしておくことは有効な手段である。
●正確な時刻への同期
不正アクセスなどの攻撃を受けた場合の追跡調査は、他のログと突合せすることにより行うことが多い。したがって、ログを取得しているサーバーの時刻が正確でないと、ログの前後関係が狂うため事象の把握が困難となる。そのため、ログを取得する場合は、NTP 5サーバーから正確な時刻を定期的に取得し同期しておくことが望ましい。
●ログのローテーション
ログを取得するサーバーでは、一定の大きさのログファイルを保存しておくことができる。しかし、格納できる容量を超えてしまうと、新しいログが記録されない可能性がある。ログファイルが肥大化し、結果として新しいログが取得できないことを未然に防ぐため、ログのローテーションを行うことが有効である。ログのローテーションとは、一定のサイズや期間ごとにログファイル名を変更し、新しいものから一定の数だけ残して、古いものはサーバー上から消去することをいう。なお、消去する場合は、テープ等にバックアップすることで長期保管しておくことが望ましい。


2.1.3 データベースの保護 サーバー

この対策により防ぐことができる脅威
1.4.1 Webサイト内の情報の書き換え、漏洩などの攻撃

最近では、ほとんどの公開Webサーバーがデータベースと連動している。データベースには、個人情報などの機密情報が含まれている場合が多いため、Webサーバーと同様にセキュリティ機能を高め、保護することが必要である。データベースの具体的なセキュリティ対策を下記に示す。

(1) ユーザーの一元管理機能

データベースのユーザー数や、データベースそのものの数が非常に多くなると、その管理は煩雑になる。使われていないアカウントをそのまま残していると、それが悪用される可能性がある。Webアプリケーションのユーザーとデータベースを使用するユーザーの両方を一元的に管理することが望ましい。

(2) アクセスコントロール

一度データベースから認証を受けたユーザーは、決められた制限に基づいて管理をしなければならない。不必要な権限をユーザーに与えると、不正アクセスを受けた場合のリスクが大きくなるからである。そのため、各ユーザーに応じて必要な権限を付与し、適切なアクセスコントロールを行わなければならない。

(3) 格納データの暗号化

データベース内に格納されている重要なデータや個人情報については暗号化することが望ましい。データベース内のデータ全てに対して暗号化の処理を行うと、サーバー自体の負荷になることがあるので、特定のカラムだけを暗号化するなどの考慮が必要である。

(4) 通信データの暗号化

公開Webサーバーとデータベースの間では、常に通信が行われている。通信内容を傍受され、データを不正に取得されないようにするため、通信内容の暗号化を行うことが望ましい。また、通信経路上にあるデータの改ざんを防止・検出するために、データのハッシュ値を取得する方法も有効である。

(5) 監査機能

何かしらの問題が起きた場合や、起きている可能性がある場合、その原因を追跡するために、ログの収集を行うことが望ましい。内部からの不正アクセスを抑制するためにも、定期的なログの取得や管理は有効である。

2.1.4 SSLの導入 サーバー

この対策により防ぐことができる脅威
1.4.3 Webサイトの乗っ取り攻撃
1.4.4 電子商取引サイトの運営にまつわるトラブル
1.4.5 Webサイト利用者との通信に対する盗聴

SSL(Secure Socket Layer)とは、インターネット上の通信を暗号化するために用いられる技術である。Webの通信をSSLにより暗号化することで、利用者の個人情報や、クレジットカード番号などを安全に送受信することができるが、通信の暗号化だけでなく、デジタル証明書、ハッシュ関数などの技術の組み合わせにより、改ざんやなりすましを防ぐこともできる。
   SSLによる暗号化通信を提供するためには、公開Webサーバー上に認証局が発行したサーバー証明書が必要となる。サーバー証明書は、ベリサインなどの認証局を持つ第三者機関が発行している。サーバー証明書の発行の際、申請団体の実在性を企業データバンクに登録されていることで確認している。企業データバンクに未登録の企業であった場合は、登記簿謄本などの確認書類が必要となる。このような手続きにより、サーバー証明書がその企業のものであることの信憑性を高めている。
   サーバー証明書には、証明書の所有者や公開鍵、有効期間などを示した署名前証明書と、それに対し認証局が署名した署名値が記録されている(図表11)。

図表11  サーバー証明書の構成

図表11  サーバー証明書の構成
(出所)IPA「PKI 関連技術解説」(IPA、2005年6月)

Webで利用される通信プロトコルHTTPはSSLを用いて暗号化することができ、利用者のブラウザからは「http://」で始まるURLを「https://」とするだけでSSLによる暗号化通信を始めることができる。SSL通信によりサーバー証明書がブラウザに送信され、ブラウザは主に次の2点について検証する。
  • 主要な認証局により署名されたサーバー証明書であるか?
  • サーバー証明書は有効期限内にあるか?
検証の結果に問題があった場合は、ブラウザに警告画面が表示される。利用者に対して「なりすましサイトではないか」「管理が不徹底なのでは」などの不安感を与えることになるため、サーバー証明書を利用する場合は、認証局による署名を受けたものを使用し、有効期限が切れる前に更新するなど、管理を徹底することが重要である。

公開Webサーバー上でSSLを実現するには、WebサーバーがSSLに対応していることが必要である。市場に出回っているWebサーバーのほとんどはSSL化が可能であるが、最新の情報については、ベンダーのページを参照していただきたい。

2.1.5 DNSキャッシュポイズニングへの対処 サーバー

この対策により防ぐことができる脅威
1.4.3 Webサイトの乗っ取り攻撃

DNSキャッシュポイズニングに対する脆弱性を持つDNSサーバーを利用している場合は、速やかにアップデートすることが必要である。また、DNSキャッシュポイズニングは「再帰問い合わせ(Recursive Query)」を有効にしたDNSサーバーに対する攻撃手法が存在するため、外部に公開するDNSサーバーでは、必要がなければ再帰問い合わせを無効にしておく。その他、DNSパケット中のIDを予測し応答を置き換える手法や、TTL(Time To Live)の短いリソースレコードに対しては比較的容易に置き換えられる手法が知られている。

2.1.6 負荷分散と冗長化 サーバー ネットワーク

この対策により防ぐことができる脅威
1.4.2 Webサーバーへのアクセスを不可能にする攻撃

利用者が多くなるにつれて、公開Webサーバーが1台だけではアクセス集中による処理能力低下を招く可能性がある。また、1台だけの場合、障害等でサーバーがダウンした場合にサービスの提供が止まってしまうことから、同じく可用性が脅かされるリスクをはらんでいる。したがって、公開Webサーバーを立てる際は、負荷分散と冗長化が重要となる。

(1) 負荷分散装置(ロードバランサー)

負荷分散は、同じ処理を行うサーバーを複数台設置し、負荷がなるべく均等になるように処理を分散する技術である。負荷分散の導入により、大量のアクセス要求をすばやく処理することができ、またシステムダウンを防止することができる。負荷分散を実現する装置が「負荷分散装置(ロードバランサー)」である。負荷分散装置を使用すると、サーバーの負荷状況などに応じて柔軟にアクセスをサーバーに振り分けることができる。また、各サーバーに対してヘルスチェックを定期的に行い、サーバーが稼働しているかどうかを確認している。ヘルスチェックの際に、サーバーがダウンしたと判断した場合には、アクセスを振り分けないようにする。

   負荷分散の方式は、通信プロトコルのどの層の情報を見てアクセスを振り分けているかにより、レイヤー4ロードバランサーとレイヤー7ロードバランサーに分類される。前者はトランスポート層のIPアドレスやポート番号を元に振り分け先を決めるのに対し、後者はHTTPヘッダやURLなどの情報も含めて振り分け先を決める(図表12)。なお、Cookieを用いたWebサイトを構築する場合は、Webセッションを維持する必要があるため、レイヤー7ロードバランサーを導入する必要がある。

図表12 レイヤー7ロードバランサー

図表12 レイヤー7ロードバランサー
以上から、負荷分散装置を使うことにより、負荷分散と冗長化が実現できる。しかし、負荷分散装置自体が障害などにより停止してしまうと、負荷分散処理を行っているすべてのサーバーにアクセスできなくなってしまう。このような箇所を単一故障点(Single Point of Failure)と呼ぶ。より可用性を向上させるには、負荷分散装置自体を冗長化させる必要がある。負荷分散装置によっては、冗長化構成をとることができない製品があるため、導入する際に冗長化構成をとることができるかどうかを確認しておくことが必要である。また、また、障害時に通信の接続維持が必要ならフェイルオーバー 6 機能の有無も確認すべきである。
   公開Webサーバーに負荷分散装置を使用する場合は、冗長化された全てのサーバーがクライアントPCの要求に対し応答することから、データの整合に留意しなくてはならない。通常は冗長化されたサーバーは共有サーバー上の同一データを参照更新することになるが、更新する場合は他のサーバーが同時に更新してしまわないように排他処理を施さなければならないなど、プログラミング上の考慮が必要となる。

(2) SSLアクセラレータ

先述のSSLを用いた通信では、公開Webサーバーは通常の処理とは別に、暗号化/復号処理を行う必要がある。SSL通信を始める際に、ブラウザとサーバー間で「ハンドシェイク」と呼ばれる暗号化通信の初期ネゴシエーションが行われるが、このときサーバー側では膨大な計算が必要となる暗号鍵の指数演算を実行しなければならず、極めて重い処理をCPUに課すことになる。公開Webサーバーにアクセスする利用者が増えれば比例して負荷も増大するため、処理能力の高い機器を選定することが重要である。そのためのハードウェアとして、「SSLアクセラレータ」が存在する。
   SSLアクセラレータは、暗号化/復号にかかる処理をサーバーではなく専用ハードウェア上で行うことにより、サーバーのCPU負荷を軽減することを目的としている。アプライアンスとしても、PCIカードとしても市場に出回っており、負荷分散装置に内蔵されているものも存在する。


(3) クラスタ化

その他、冗長化対策として「クラスタ化」と呼ばれる方法が存在する。サービスを提供しているサーバー(本番系・主系)と待機しているサーバー(待機系)がお互いにハートビートと呼ばれる通信を行うことにより、お互いの死活状態を監視し、本番系のサーバーがサービス提供不能に陥った場合に、待機系サーバーがフェイルオーバーするしくみのことを言う。一般的にクラスタは負荷分散の仕組みを持たない、冗長化のみを提供する技術である。負荷分散装置を用いる場合と比べ、大量のアクセスに対応することはできないが、排他処理などの考慮が不要なため、中規模Webサイトでは有効な手段である。


2.1.7 IDS/IPSの導入 サーバー  ネットワーク

この対策により防ぐことができる脅威
1.4.2 Webサーバーへのアクセスを不可能にする攻撃

IDS(Intrusion Detection System)とは、侵入検知システムとも呼ばれ、ホストや通信回線を監視し、不正侵入を検知した場合に管理者へ通知を行うシステムである。IDSは監視対象により、ネットワーク型とホスト型の2つに分類される。

(1) ネットワーク型IDS

ネットワーク型IDSは、IDSセンサを設置したセグメント上のすべての通信パケットを監視する。トラフィックがあらかじめ登録された攻撃パターンと一致した場合は、侵入行為とみなし、ネットワーク管理者に警告を行う。

(2) ホスト型IDS

ホスト型IDSは、インストールされたホストに対する不正アクセスを検知する。ホスト内のOS、サーバープログラムなどが生成したログやコマンド履歴などを解析したり、ホストへの通信の監視を行う。

  ネットワーク型IDSとホスト型IDSの比較を図表13に示す。


図表13 ネットワーク型IDSとホスト型IDSの比較
ネットワーク型IDS ホスト型IDS
監視対象 ネットワーク上の通信 OSやサーバープログラムが生成するログ、ホストへの通信
検出タイミング 不正アクセスと同時 不正アクセス発生後(ログ監視の場合)
導入場所 監視したいネットワークセグメント 監視したいホスト
侵入検出率 通信量増加につれ低下 低下しない
IDS導入による周囲への影響 他のネットワーク機器への影響なし ホストに負荷を与える。

IPS(Intrusion Prevention System)とは、侵入防御システムとも呼ばれる。IDSでは侵入を「検知」することしかできないが、IPSは侵入を「防御」することが可能である。つまり、IPSはIDSが持つ検知機能に加え、防御機能を強化したものである。IDSでは、不正アクセスや不正侵入を検知した場合、警告を管理者に送り、それをもとに管理者が対応を行ってきた。IPSは不正アクセスや不正侵入の通信を自動的に遮断することができるため、IDSと比較して運用負荷を軽減することが期待できる。

  IDSおよびIPSにおいて、誤検知が少なからずとも発生する。正常な通信を不正な通信と認識してしまう誤検知のことを「False Positive」といい、不正な通信を正常な通信と認識してしまう誤検知のことを「False Negative」という。通常は、不正な通信を通してしまう「False Negative」の発生がセキュリティ上において問題となるが、IPSを利用している場合には、正常な通信が遮断されてしまう「False Positive」によりサービス提供を阻害してしまうことが問題となるため留意しておくことが必要である。

2.1.8 ファイアウォールの設定 ネットワーク

この対策により防ぐことができる脅威
1.4.1 Webサイト内の情報の書き換え、漏洩などの攻撃
その他、サーバーへの不正アクセス

近年の企業ネットワークでは、外部からの社内ネットワークへの攻撃や侵入を防ぐため、ファイアウォールを導入することは必須となっている。ファイアウォールはネットワークを通過するパケットを監視し、フィルタを設定することにより通信を許可、遮断、あるいは制限することができる。Webサーバーを社外へ公開する場合は、DMZ(DeMilitarized Zone)と呼ばれるネットワークセグメントに設置する。

  DMZとは、外部ネットワーク(インターネットなど)と内部ネットワーク(社内ネットワーク)の間に設置されたネットワークセグメントのことであり、非武装地帯とも呼ばれる。Webサーバーに限らず、外部に公開するサーバーは通常DMZに設置する。万が一DMZ上に設置されたサーバーが不正アクセスを受けて乗っ取られた場合にも、ファイアウォールにより内部ネットワークまで侵入されないよう防御することができる。

  公開WebサーバーをDMZに設置する場合の、ファイアウォールにおける基本的なフィルタリングルールを図表14に示す。

図表14 ファイアウォールのフィルタリングルール設定
通信の方向 フィルタリングルール
外部ネットワーク
→内部ネットワーク
DMZをバイパスするすべての通信を拒否する。
外部ネットワーク
→DMZ
公開Webサーバー(TCP(80))、DNSサーバー(TCP,UDP(53))への通信を許可する。
内部ネットワーク
→DMZ
公開Webサーバー(TCP(80))、DNSサーバー(TCP,UDP(53))への通信を許可する。
DMZ
→外部ネットワーク
公開Webサーバー、DNSサーバーからの通信を許可する。
DMZ
→内部ネットワーク
公開Webサーバー、DNSサーバーからの通信を許可する。



ファイアウォール構築での留意点を下記に示す。

(1) 適切なフィルタリングを行う

ファイアウォールで最も重要な機能は、フィルタリング機能である。必要な通信だけを許可するようフィルタリングルールを設定する。ただし、あまりにも強固なフィルタリングを行うと、想定しない通信障害によるトラブルが発生する可能性がある。サーバーや、使用しているアプリケーションの通信に関する仕様を理解し適切なフィルタリングルールの設定を行い、十分にテストすることが重要である。

(2) ログの取得を有効にする

最近のファイアウォールは、ログを収集する機能をもっているものが多い。万が一の事態に備えて、ログの取得機能は有効にし、定期的に取得したログの保存や、解析を行うことが望まれる。また、フィルタリングルールの設定に不備があり、サーバーへ接続できないなどの不具合があった場合にも、ログの解析を行うことで対処することができる可能性もある。ただし、ログの取得によりファイアウォールのパフォーマンスが劣化することがあるため、留意が必要である。



2.1.9 Webアプリケーションファイアウォール(WAF)の利用 ネットワーク

この対策により防ぐことができる脅威
1.4.1 Webサイト内の情報の書き換え、漏洩などの攻撃

Webアプリケーションファイアウォール(以下WAF)と呼ばれる機器を利用することにより、外部ネットワークからWebアプリケーションに対する不正アクセスを未然に防ぐことができる。WAFの基本機能は、Webアプリケーションに渡される入力内容などを検査することにより、不正と見なされたアクセスを遮断することである。
   WAFは、公開Webサーバーの前段に置かれ、利用者のブラウザと公開Webサーバーの間に位置する。攻撃者からのSQLインジェクションやクロスサイトスクリプティングといった不正な要求が公開Webサーバーに到達する前にWAFが攻撃と判断してアクセスを拒否することができる。



↑ページの先頭へ戻る

Copyright © 2007 Information-technology Promotion Agency, Japan. All rights reserved.