ブログ

はじめに：Webサイトは「公開しているだけ」でも見られている

こんにちは！A.Iです。

最近、「AI」や「Bot」という言葉をよく聞くようになりましたね。
SEOだけではなく、AIOも大切！なんて話も増えてきて、Webサイトを取り巻く環境もずいぶん変わってきたな、と感じる今日この頃です。

AIをはじめ、さまざまな技術によって便利になっていく一方で、Webサイトを運用する側としては、「便利になったからこそ、気をつけておきたいこともあるよね」と感じることもあります。

実際にWebサーバーのアクセスログを見ていると、「あれ？このアクセス、本当に人が見に来ているのかな？」と思うような通信も少なくありません。

今回は、そんな最近のWebサイトへのアクセス事情と、普段よく利用しているAWS WAFについて紹介していきたいと思います。

そのアクセス、本当に「ユーザー」ですか？

Webサーバーのログを見ていると、少し不思議なアクセスに遭遇することがあります。

例えば、下記のようなアクセスです。

• 存在しないURLを大量にリクエストする
• 管理画面やログインページを繰り返し確認する
• 特定のCMSやソフトウェアを狙ったURLへアクセスする
• 短時間に大量のURLを機械的に巡回する

もちろん、こうしたアクセスがすべて悪意のあるものとは限りません。
検索エンジンのクローラーなど、正常なアクセスもあります。
一方で、Webサイトに脆弱性や設定上の問題がないかを機械的に探している「スキャン」もあります。
そして、この「スキャン」は決して珍しいものではありません。

実際、2026年1月～3月のサイバーセキュリティクラウドの調査レポートでは、同社のWAFで約7.1億件のサイバー攻撃を観測しています。
攻撃種別では「Web scan」が約46％と最も多く、脆弱性などを探す探索行為が大きな割合を占めています。
もちろん、これは特定の環境で観測されたデータです。
それでも、「Webサイトへのスキャンは、日常的に発生している」と考えるきっかけにはなるのではないでしょうか。

参考情報：【独自調査レポート】Webアプリケーションへのサイバー攻撃検知レポート2026（2026年1月～3月）

大企業だけが攻撃対象になるわけではない

サイバー攻撃というと、大企業や有名企業が狙われるイメージがあります。
しかし、Webサイトへの自動的なスキャンは少し事情が異なります。
自動化されたツールによって、インターネット上のWebサイトが広範囲に調査されることがあります。
そのため、「大企業だから狙われる」だけではなく、「インターネットに公開されているから探される」という側面があります。
Webサイトを運営する以上、企業規模に関係なく、一定のセキュリティリスクを考えておく必要があります。
また、大量のスキャンが繰り返されれば、Webサーバーやアプリケーション、データベースへの負荷につながることもあります。
だからこそ、「攻撃されてから対応する」のではなく、「不要なアクセスをできるだけ入口で減らす」
という考え方が重要になってきます。

サーバーに届く「前」に防御するAWS WAF

そこで選択肢の一つとなるのが、WAF（Web Application Firewall）です。

WAFは、WebサイトへのHTTP/HTTPSリクエストを確認し、設定したルールに基づいて、問題のあるリクエストを検知・遮断する仕組みです。

AWS環境でCloudFrontなどと組み合わせてAWS WAFを利用すれば、Webサーバーへリクエストが到達する前の段階でアクセスを制御できます。
イメージとしては、以下のような形です。

インターネット
↓
AWS WAF
↓
CloudFront
↓
Webサーバー

私は、WAFの大きなメリットの一つは、「Webサイトの入口に防御線を置けること」だと考えています。

個人的に入れておきたいAWS WAFのルール

ここからは、AWS WAFについてもう少し具体的にご紹介します。

AWS WAFには、AWS側があらかじめ用意している「マネージドルール」があります。
ゼロから複雑なルールを作成しなくても、代表的な攻撃パターンに対応したルールを利用できるため、WAF導入時には非常に便利です。

ここで紹介するのは、AWSが「この構成が正解」と推奨しているものではありません。

私自身がこれまでWAFを運用してきて、「まずはこのあたりを候補にしたい」と感じているものです。

AWSManagedRulesCommonRuleSet

Webアプリケーションに対する代表的な攻撃パターンを幅広く検知する、基本的なルールセットです。
まずWAFを導入するのであれば、検討しやすいルールの一つだと思います。
ただし、正常なリクエストが検知されることもあるため、実際のアクセス状況を確認しながら導入することが重要です。

Amazon IP reputation list

AWSが収集した情報をもとに、不審な活動を行っていると判断されたIPアドレスなどを対象とするルールです。
個別に怪しいIPアドレスを調査して登録する手間を減らせるため、実際の運用でも便利なルールの一つです。

国別のアクセス制限（Geo Match）

Webサイトの利用者が日本国内に限定されているなど、明確な利用条件がある場合には、国単位でアクセスを制限する方法もあります。
ただし、「海外アクセス＝悪意のあるアクセス」ではありません。
サービスの利用状況を確認した上で、必要に応じて検討することが重要です。

WAFは「運用しながら育てる」

「WAFを入れて、危険なアクセスを全部ブロックすればいいのでは？」と思うかもしれません。
実際には、ここがWAF運用の難しいところです。
ルールを厳しくしすぎると、正常なアクセスまでブロックしてしまう可能性があります。

そのため、以下のようなサイクルが重要になります。

検知する
↓
ログを確認する
↓
必要に応じて調整する
↓
再度監視する

特に、最初からすべてをBLOCKするのではなく、COUNT（検知はするものの、アクセス自体は許可する設定）などを利用して、どのようなアクセスが検知されているのかを確認する方法もあります。

「ルールに引っかかった＝攻撃」とは限らない。

ここは、実際に運用していて感じるポイントです。

WAFは「入れて終わり」ではなく、見て、考えて、調整するものだと私は考えています。

WAF以外の基本対策も大切

ここまでWAFの話をしてきましたが、WAFを導入したからといって、Webサイト全体が安全になるわけではありません。

OSやWebサーバー、WordPressなどCMSの脆弱性、認証情報の漏洩や不正利用など、WAFだけでは十分に防げない問題もあります。

そのため、以下のような複数の対策を組み合わせることが重要です。

WAF
＋
OS・ミドルウェアのアップデート
＋
CMSやプラグインの適切な管理
＋
アクセス制御
＋
監視・ログ確認
＋
バックアップ

おわりに：まずは「知る」ことから

現在のWebサイトには、ユーザーからのアクセスだけではなく、クローラーやBot、自動化されたツール、そして脆弱性を探すスキャンなど、さまざまな機械的アクセスが日々届いています。
こうしたアクセスを完全になくすことは困難です。

だからこそ、「攻撃されないようにする」だけではなく、「攻撃やスキャンが来ることを前提として、被害を受けにくい環境を作る」という考え方が重要になっています。

AWS WAFは、そのための有効な防御手段の一つです。
ただ、最初からすべてを完璧にする必要はありません。
まずは、自分たちのWebサイトにどのようなアクセスが来ているのかを知ること。
そして、できるところから少しずつ対策していく。
これからのWebサイト運用では、そんな姿勢がより重要になっていくのではないかと思います。

もしかすると、皆さんが思っている以上に、Webサイトは日々「探されている」のかもしれません。

この記事が、Webサイトのセキュリティについて考えるきっかけになれば幸いです。

株式会社ウイングドアは福岡のシステム開発会社です。
現在、私達と一緒に"楽しく仕事が出来る仲間"として、新卒・中途採用を絶賛募集しています！
ウイングドアの仲間達となら楽しく仕事できるかも？と興味をもった方、
お気軽にお問い合わせ下さい！