大学では、公式サイトだけでなく、入試・受験生向けサイト、学部や研究機関のサイト、イベントサイトなど、複数のWebサイトをインターネット上に公開しています。
こうしたWebサイトは、学生や受験生、保護者、研究者など多くの人が利用する一方、外部からのサイバー攻撃の対象にもなります。
2026年7月、富山県立大学は、学生団体が外部サーバーで運営していた公式ホームページへの不正アクセスについて公表しました。編集権限を持つ学生2名のアカウントに対し、海外から繰り返しアクセスを試みた記録があり、パスワードが総当たり攻撃によって破られ、不正に認証を突破された可能性があるとしています。実際に、不適切なサイトへ誘導するロシア語の文章やリンクが数十件投稿されていました。詳しくは、富山県立大学「学生のクラウドサービスアカウント及び学生団体HPに対する不正アクセスについて」で公表されています。
また、Webサイトへの攻撃そのものも現在進行形で観測されています。サイバーセキュリティクラウド「2026年4月～6月 Webアプリケーションへのサイバー攻撃検知レポート」によると、同社のWAFサービスで2026年4～6月に観測された攻撃検知件数は約7億9,475万件でした。内訳では「Web scan」が39.1％で最も多く、SQLインジェクション15.8％、ブルートフォース7.3％、クロスサイトスクリプティング（XSS）6.7％などが確認されています。
こうしたWebアプリケーションへの不正な通信を検知・遮断する対策の一つが、WAF（ワフ：Web Application Firewall／Webアプリケーションファイアウォール）です。
WAFは、Webサイトを公開したまま、SQLインジェクションやXSS、既知の脆弱性を狙う通信、大量のアクセスなどをWebアプリケーションへ届く前に検知・遮断する役割を持ちます。
この記事では、WAFが大学Webサイトのどこを守るものなのか、どのような攻撃を防げるのか、ほかのセキュリティ対策との違い、自大学で導入を検討するときのポイントまで解説します。
目次
WAFとは？大学Webサイトのどこを守る対策なのか
WAFはWebサイトへの通信を確認する防御層
WAFは、Webサイトへ送られるHTTP・HTTPS通信の内容を確認し、設定したルールに該当する不正なリクエストを検知・遮断する仕組みです。
WAFは、利用者とWebサーバーの間に配置され、Webサイトへの通信を確認します。
ファイアウォールが主にネットワーク通信を制御するのに対し、WAFはWebアプリケーションに送られる通信の内容を確認します。SQLインジェクションやXSSなど、Webアプリケーションを狙う攻撃の検知・遮断に利用されます。
WAFの基本的な役割については、AWS「Web Application Firewall（WAF）とは？」でも解説されています。
大学の公式サイトや入試サイトは、学生・受験生・保護者などが日常的に利用する公開Webサイトです。アクセスを受け付けながら、不正な通信を見分けて遮断する必要があります。
WAFは、Webサイトの公開を維持しながら、Webアプリケーションを狙う不正な通信を入口で防御する役割を担います。
防御できる範囲は製品や設定によって異なるため、保護するWebサイトに合わせてルールを設定し、運用していきます。
ファイアウォールとの違い
WAFと混同されやすいものに、ファイアウォールがあります。
| 対策 | 主に確認するもの | 主な役割 |
| ファイアウォール | IPアドレス、ポート、通信先など | 不要なネットワーク通信を制御する |
| WAF | HTTP・HTTPSリクエストの内容 | Webアプリケーションを狙う不正な通信を検知・遮断する |
大学公式サイトなどを公開する場合、Web閲覧に必要なHTTP・HTTPS通信は受け付ける必要があります。
しかし、そのWeb通信の中に、SQLインジェクションやXSSといった攻撃が含まれることがあります。
WAFは、ファイアウォールを通過したWeb通信について、Webアプリケーションに対する攻撃が含まれていないかを確認し、必要に応じて遮断する仕組みです。
そのため、ファイアウォールとWAFはどちらか一方を選ぶものではなく、異なる領域を守る対策として考えます。
CMSのアップデートやサーバー保守との違い
WAFと同様に、CMSのアップデートやサーバー保守もWebサイトのセキュリティには欠かせません。それぞれ守る対象が異なります。
| 対策 | 主な役割 |
| CMS・プラグイン等のアップデート | ソフトウェアに存在する脆弱性そのものを修正する |
| サーバー保守 | OSやミドルウェアの脆弱性への対応、設定・稼働状態を維持する |
| WAF | Webサイトへ送られる不正なリクエストを検知・遮断する |
WAFは、攻撃に使われる通信をWebアプリケーションへ到達する前に検知・遮断します。
一方、CMS、Webアプリケーション、フレームワークなどに存在する脆弱性そのものを修正するものではないため、それらのアップデートは別途必要です。
大学では、Webサイトの更新は広報・企画部門、CMSの保守はWeb制作会社、サーバーはサーバー運用会社、セキュリティ方針は情報システム部門というように、役割が分かれているケースもあります。
そのため、「セキュリティ対策をしているか」だけではなく、どのリスクを、どの対策で防いでいるのかを整理することが重要です。
大学のWebサイトでWAFを検討する前に確認したいこと
WAFの必要性を考える際は、まず現在のWeb環境を整理します。
例えば、次のような項目です。
- インターネットへ公開しているWebサイトは何か
- 公式サイト以外に、入試、学部・研究機関、イベント等のサイトがあるか
- CMSやWebアプリケーションを利用しているか
- 問い合わせ、申込、検索、ログインなどの機能があるか
- CMSやサーバーはどのように保守されているか
- Webアプリケーションへの攻撃を現在どの仕組みで防いでいるか
- 不審なアクセスを確認する仕組みがあるか
確認したいのは「何らかのセキュリティ対策をしているか」だけではありません。
Webアプリケーションを狙った攻撃に対して、現在どのような防御ができているかを見ることが、WAFの必要性を判断する第一歩です。
WAFではどんな攻撃を防げるのか
大学のWebサイトもインターネットへ公開されている以上、SQLインジェクションやXSS、既知の脆弱性を狙った自動的な探索など、Webアプリケーションを狙う攻撃を受ける可能性があります。
前述のサイバーセキュリティクラウドの2026年4～6月のレポートでは、Web scanが39.1％、SQLインジェクションが15.8％、ブルートフォースが7.3％、XSSが6.7％など、Webサイトを狙ったさまざまな攻撃が確認されています。
WAFの大きな役割は、こうした攻撃通信をWebアプリケーションが処理する前に検知・遮断することです。
SQLインジェクション
SQLインジェクションは、Webサイトの入力値などを悪用して不正なSQLを実行させ、データベースの情報取得や改ざんなどを狙う攻撃です。
WAFでは、リクエストに含まれるSQLインジェクション特有の攻撃パターンを検知し、Webアプリケーションへ到達する前に遮断できます。
例えば、攻撃者がWebサイトに脆弱性がないか大量のリクエストを送って調査している場合でも、該当する攻撃パターンを入口で検知・遮断することができます。
大学サイトでも、問い合わせフォーム、各種申込、検索など、利用者から入力を受け付ける機能を持つ場合があります。
こうした公開Webサイトに対して、不正なリクエストをアプリケーションへ届かせない防御層を設けられることがWAFの役割です。
SQLインジェクションの仕組みやWebアプリケーション側の対策については、OWASP「SQL Injection Prevention Cheat Sheet」でも解説されています。
クロスサイトスクリプティング（XSS）
クロスサイトスクリプティング（XSS）は、Webサイトへ悪意のあるスクリプトを送り込み、サイトを閲覧した利用者のブラウザ上で実行させる攻撃です。
WAFでは、XSSに使われる不正なスクリプトなど、攻撃に特徴的なリクエストを検知し、Webアプリケーションへ到達する前に遮断できます。
大学公式サイトや受験生向けサイトは、多くの利用者が閲覧します。
不正な通信を入口で遮断することで、Webサイトだけでなく、その先にいる利用者へ影響する攻撃のリスクを抑えることにつながります。
XSSの仕組みについては、OWASP「Cross Site Scripting（XSS）」で詳しく解説されています。
Webサイトの脆弱性を狙った不正なリクエスト
CMSやWebアプリケーション、フレームワークなどで脆弱性が公表されると、その脆弱性を持つWebサイトを探す自動スキャンや、不正なリクエストが送られることがあります。
前述のWAF観測レポートでも、2026年4～6月に検知された攻撃のうち「Web scan」が39.1％を占めています。
WAFでは、既知の攻撃パターンをルールとして持つことで、脆弱性を悪用しようとする通信をWebアプリケーションへ到達する前に遮断できる場合があります。
特に、脆弱性が公表されてからCMSやWebアプリケーションをアップデートするまでに時間がかかる場合には、WAFによって既知の攻撃パターンを遮断することで、攻撃を受けるリスクを抑えられます。
ただし、WAFは脆弱性そのものを修正するものではないため、CMS、Webアプリケーション、フレームワークなどのアップデートは別途必要です。
WAFによる入口での防御と、ソフトウェア側の脆弱性修正を組み合わせることが重要です。
大量アクセス・ブルートフォースへの対策
Webサイトには、短時間に大量のリクエストを送ったり、ログイン画面に対して大量のID・パスワードを試したりする攻撃もあります。
冒頭で紹介した富山県立大学の公表資料では、学生団体の公式HPの編集権限を持つ2アカウントに対し、2026年5月10日から6月1日にかけて海外から何度もアクセスを試みた記録が確認されています。
WAFには、一定時間内に大量のリクエストを送るアクセスを検知し、制御する仕組みがあります。
例えばAWS WAFでは、一定期間のリクエスト数を基準にアクセスを制御する「レートベースルール」が提供されています。
これにより、大量のアクセスや繰り返し行われる攻撃試行を、Webアプリケーションへ到達する前に抑制できます。
認証そのものを強化する対策については、次章で説明します。
WAFだけでは防げない攻撃には、ほかの対策も組み合わせる
ここまで見てきたように、WAFはWebアプリケーションへの攻撃を入口で検知・遮断するための有効な防御策です。
一方、サイバー攻撃にはWeb通信以外を狙うものもあります。
そのため、WAFを中心としたWebアプリケーション層の防御に加え、リスクに応じてほかの対策も組み合わせます。
| リスク・攻撃 | WAFでできること | 組み合わせたい対策 |
| SQLインジェクション・XSS | 攻撃通信の検知・遮断 | Webアプリケーションの改修、CMS更新 |
| CMS・Webアプリの脆弱性 | 悪用する通信を遮断できる場合がある | CMS・プラグイン等のアップデート |
| ブルートフォース | レート制御等で攻撃試行を抑制 | MFA、パスワード・アカウント管理 |
| 認証情報の漏えい | 通信内容によっては検知が難しい | MFA、認証情報管理 |
| OS・ミドルウェアの脆弱性 | 脆弱性そのものは修正できない | パッチ適用、サーバー保守 |
| DDoS | アプリケーション層への攻撃の一部を制御 | CDN、DDoS対策サービス等 |
| 攻撃検知後の対応 | 検知・遮断、ログ取得 | 監視、対応手順、運用体制 |
CMSやWebアプリケーションの脆弱性には、アップデートを行う
WordPressなどのCMSやプラグイン、Webアプリケーションに脆弱性が見つかった場合は、修正版へのアップデートが基本です。
あわせて、利用していないプラグインや機能を削除し、脆弱性情報を継続的に確認できる状態にしておく必要があります。特に緊急性の高い脆弱性が公表された際には、速やかに対応できる運用体制も重要です。
WAFでは、脆弱性を悪用しようとする通信をWebアプリケーションへ到達する前に遮断できる場合があります。一方、WAFそのものがCMSやWebアプリケーションの脆弱性を修正するわけではありません。
WAFで攻撃通信を防ぎながら、CMSやWebアプリケーション側でも脆弱性そのものを修正することで、複数の層でWebサイトを守ります。
大学がCMS保守をWeb制作会社などへ委託している場合は、通常のサイト更新だけでなく、脆弱性情報の確認や緊急アップデートまで対応範囲に含まれているかも確認しておきたいポイントです。
ID・パスワードを狙う攻撃には、認証を強化する
ブルートフォースのように短時間で大量のログインを試みる攻撃は、WAFのレート制御によって試行回数を抑制できる場合があります。
一方、すでに正しいID・パスワードが漏えいしている場合には、通常のログインと攻撃を通信だけで判別することが難しくなります。
そのため、WAFによるアクセス制御とあわせて、MFA（多要素認証）の導入、不要になったアカウントの削除、管理画面へのアクセス制限など、認証そのものを強化する対策を組み合わせます。
特に管理画面やWebサイトの編集権限を持つアカウントについては、パスワードだけに依存しない認証方法を検討することが重要です。
サーバーやOSの脆弱性には、継続的な保守・アップデートを行う
WAFはWebアプリケーションへの通信を確認する仕組みであり、OSやミドルウェアに存在する脆弱性そのものを修正することはできません。
サーバー側では、OSやミドルウェアのセキュリティアップデートを継続し、サポートが終了したバージョンは更新する必要があります。あわせて、不要なサービスの停止や脆弱性情報の確認など、継続的な保守も必要です。
つまり、Webサイト全体を守るには、WAFでWebアプリケーションへの攻撃を防ぐことと、CMS・Webアプリケーション・サーバーそのものを安全な状態に保つこと、の両方が必要です。
DDoS攻撃には、攻撃の種類に応じた対策を行う
DDoS攻撃は、攻撃されるレイヤーによって必要な対策が異なります。
WebサイトへのHTTP・HTTPSリクエストを大量に送りつけるOSI参照モデルの第7層（アプリケーション層、Layer 7）へのDDoS攻撃では、WAFによるレート制御などが有効な場合があります。
一方、ネットワーク自体へ大量の通信を送り込む攻撃については、CDNやDDoS防御サービスなど、別の対策を組み合わせる必要があります。
大学では、入試や合格発表、オープンキャンパスなどによって、通常時よりアクセスが増えるWebサイトもあります。そのため、単純にアクセス数だけを基準に遮断するのではなく、正常なアクセス集中と攻撃を区別できるよう、サイトの利用状況に合わせて設定することも重要です。
攻撃を検知した後に対応できる運用体制も必要
WAFで攻撃を検知・遮断できても、攻撃が増えている場合や、CMS・サーバー側でも対応が必要な場合があります。
そのため、導入後は少なくとも次の役割を決めておく必要があります。
- WAFのログを誰が確認するか
- 異常なアクセスを誰が判断するか
- 必要な場合に誰がWAFの設定を変更するか
- CMSやサーバー側で対応が必要な場合、誰へ連絡するか
- インシデント発生時に大学内の誰へ報告するか
大学では、Web担当部門、情報システム部門、Web制作会社、CMS保守会社、サーバー運用会社など、複数の関係者がWebサイト運用に関わることがあります。
WAFを導入するだけではなく、「検知 → 判断 → 対応」まで継続して行える状態にしておくことが、Webサイトを守るうえでは重要です。
大学・大学法人でWAFの導入を優先的に検討したいWebサイト
大学・大学法人では、公式サイトだけでなく、入試・受験生向けサイト、問い合わせや申込フォーム、学部・研究機関のサイトなど、さまざまなWebサイトを外部に公開しています。
こうしたWebサイトの中でも、外部から広くアクセスされる、CMSやWebアプリケーションを利用している、個人情報を扱う、停止や改ざんが大学の業務や情報発信に影響するといったサイトでは、Webアプリケーション層の防御ができているかを確認しておきたいところです。
特に、次のようなWebサイトはWAFの必要性を検討する対象になります。
図に挙げたWebサイトだからといって、すべてに一律でWAFを導入すべきというわけではありません。
重要なのは、そのWebサイトがどのような役割を持ち、現在どのような対策が行われているかを確認したうえで、Webアプリケーション層の防御を追加する必要があるかを判断することです。
外部公開しているWebサイトは、WAFの必要性を確認する
大学の公式サイトや入試サイト、学部・研究機関のサイトなどは、学生や受験生、保護者、地域の方など、不特定多数の利用者からアクセスされることを前提に公開されています。
問い合わせフォームや資料請求、各種申込などの機能を持つWebサイトでは、単に情報を掲載するだけでなく、Webアプリケーションを通じて利用者から情報を受け取る場合もあります。
こうしたサイトでは、ファイアウォールやサーバーのセキュリティ対策だけでなく、Webアプリケーションへの不正な通信を検知・遮断する対策ができているかも確認する必要があります。
WAFは、このWebアプリケーション層の防御を担う対策の一つです。
停止・改ざん・情報漏えい時の影響から優先度を考える
WAFの必要性を考える際には、Webサイトの種類だけでなく、問題が起きた場合の影響も判断材料になります。
例えば、大学公式サイトが改ざんされれば、大学から発信する情報そのものへの信頼に影響します。入試・受験生向けサイトであれば、出願や合格発表などアクセスが集中する時期の停止が、受験生への情報提供に影響する可能性があります。
また、問い合わせや申込フォームなどで個人情報を扱っている場合は、情報漏えいへの対策もより重要になります。
そのため、「大学のサイトだからWAFを入れる」と考えるのではなく、止まった場合、改ざんされた場合、情報が漏えいした場合にどの程度の影響があるかを整理し、対策の優先度を決めることが重要です。
現在の対策状況を確認してから導入を判断する
WAFの導入を判断する前に、現在のWebサイトでどこまで対策できているのかも確認します。
すでにWAFや同等のWebアプリケーション層の防御が導入されている場合もあれば、CMSのアップデートやサーバーの脆弱性対応は行っていても、Webアプリケーションへの不正な通信を防ぐ仕組みまでは導入していない場合もあります。
あわせて、CMSやWebアプリケーションの更新、サーバーやOSの保守、不審なアクセスの確認、インシデント発生時の対応など、現在の運用範囲も整理しておくと、WAFで補うべき領域を判断しやすくなります。
Webサイトの管理を制作会社やサーバー運用会社などに委託している場合は、現在どこまで対策されているのか、誰がどの範囲を担当しているのかも含めて確認するとよいでしょう。
WAFを選ぶときに確認したいポイント
どんなWebサイトを、どんな攻撃から守りたいのか
WAFを検討するときは、最初から製品を比較するのではなく、まず守る対象・想定するリスク・被害が発生した場合の影響を整理します。
大学公式サイト、入試サイト、問い合わせフォームなどでは、利用しているCMSやWebアプリケーション、扱っている情報、利用者も異なります。停止や改ざん、情報漏えいなどが発生した場合の影響も、Webサイトごとに変わります。
そのため、「WAFを導入すること」自体を目的にするのではなく、自大学のWebサイトにどのような防御が必要なのかを整理し、それを実現できるWAFを選ぶことが重要です。
既存のWeb・サーバー構成に合っているか
WAFによって、導入方法や対応できるWeb環境は異なります。
現在利用しているクラウドやWebサーバー、CDN、CMS、Webアプリケーションなどの構成を踏まえ、既存環境に適したWAFを選ぶ必要があります。
現在の構成に合わない製品を選ぶと、追加のシステム変更が必要になったり、運用が複雑になったりする可能性があります。
そのため、機能や価格だけではなく、現在のWeb・サーバー環境に無理なく組み込めるかも選定時のポイントになります。
導入後に誰が設定・監視するのか
WAFは導入時の設定だけでなく、その後の運用も重要です。
導入前に、少なくとも次の点を確認しておきます。
- 初期ルールを誰が設定するのか
- WAFのログを誰が確認するのか
- 誤検知や正常なアクセスの遮断が発生した場合に誰が対応するのか
- 攻撃状況に応じて誰がルールを変更するのか
- インシデントが発生した場合に誰が判断・対応するのか
WAFを単に「導入する製品」として考えるのではなく、攻撃の検知から設定変更、必要な対応まで継続して運用できる仕組みとして考えることが重要です。
必要な防御レベルと費用が合っているか
WAFは、高機能な製品を選べばよいというものではありません。
Webサイトの重要度や扱う情報、想定する攻撃などから必要な防御レベルを整理し、それに合った構成を選びます。
また、WAFの費用は製品そのものの利用料金だけで決まるわけではありません。Webサイトへのリクエスト数や利用する機能、ログの保存、導入後の監視や設定変更など、構成や運用範囲によっても変わります。
そのため、単純な月額料金だけを比較するのではなく、「自大学に必要な防御と運用を実現すると、どの程度の費用になるのか」という視点で比較することが重要です。
まとめ｜WAFが必要かは、現在のWeb環境と対策状況から判断する
大学では、公式サイト、入試サイト、学部や研究機関のサイトなど、複数のWebサイトをインターネット上に公開しています。
こうしたWebサイトには、通常の利用者からのアクセスだけでなく、SQLインジェクションやXSS、既知の脆弱性を狙ったスキャン、大量のアクセスなど、Webアプリケーションを狙った攻撃通信も届きます。
WAFは、Webサイトを公開した状態のまま、不正な通信をWebアプリケーションへ到達する前に検知・遮断するための防御策です。
一方、Webサイト全体を守るためには、WAFだけでなく、CMSやWebアプリケーションのアップデート、認証の強化、サーバー保守、DDoS対策、攻撃検知後の運用なども組み合わせる必要があります。
まず確認したいのは、「現在公開しているWebサイトに対して、Webアプリケーションへの攻撃をどのように防いでいるのか」という点です。
特に、CMSやWebアプリケーションを利用しているサイト、問い合わせや申込などの機能を持つサイト、停止・改ざんした場合の影響が大きいサイトでは、Webアプリケーション層の防御状況を確認し、必要に応じてWAFの導入を検討します。
クロジカでは、現在のWeb・サーバー構成や既存のセキュリティ対策を確認したうえで、WAFの必要性の整理から、環境や予算に合わせた対策の提案、WAFの導入・設定、サーバー保守や脆弱性対応、継続的な運用まで支援しています。
「今のWebサイトにどのような防御が必要なのか」「WAFを導入する場合、どのような構成が適しているのか」を確認したい場合は、現在のWebセキュリティ対策からご相談ください。
コーポレートサイトをクラウドでセキュアに
クラウドサーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカクラウドサーバー管理の主な機能
- 導入事例
- 導入までの流れ
