Posts in category: ブログ

フィッシング詐欺の報告件数は増え続け、2025年には過去最多を更新しました。従業員教育や多要素認証を導入済みの企業でも被害は発生しており、対策を打っても防ぎきれないという声は少なくありません。その理由は、フィッシング対策を入口だけで完結させようとしている点にあります。

本記事では最新の手口を整理したうえで、企業が実施すべき入口対策と出口対策の二段構えを、具体的な設定レベルまで踏み込んで解説します。

フィッシング詐欺の対策は「予防」と「不正アクセス対策」の二段構えが必要

フィッシング詐欺の対策では、偽メールや偽サイトによる認証情報の窃取を防ぐだけでなく、認証情報が盗まれた場合に不正アクセスへ悪用されるリスクも抑える必要があります。

多要素認証などの認証強化に加え、ボットによる大量のログイン試行やWebアプリケーションへの攻撃を検知・遮断する対策を組み合わせることが重要です。ペンタセキュリティのCloudbric WAF+は、こうしたWeb側の防御を強化する選択肢となります。

入口対策だけではフィッシング被害を防ぎきれない理由

2025年のフィッシング報告件数は約245万件に達し、過去最多を更新しました。フィッシング対策協議会のレポートでは、警察庁の発表として2025年上半期の報告件数が119万6,314件、インターネットバンキングの不正送金被害額は約42億2,400万円と示されています。

IPAの情報セキュリティ10大脅威 2026［個人編］にも、フィッシングと不正ログインがともに選出されています。認証情報の窃取が不正ログインへ直結する構造は、公的にも指摘されています。

情報セキュリティ10大脅威 2026については、以下の記事で詳しく解説しています。あわせてお読みください。

情報セキュリティ10大脅威2026が公表！2026年版のポイントや取り組むべき対策について解説

出典：「フィッシングレポート2026」 フィッシング対策協議会

フィッシング詐欺対策の4領域と、それぞれで防げる範囲

フィッシング詐欺への対策は次の4領域に整理できます。それぞれに防げない範囲があるため、守備範囲を見比べましょう。

これらの対策は役割が異なるため、いずれかひとつだけでフィッシング被害を防ぎきれるものではありません。とくに認証情報が窃取された場合に備えて、フィッシング耐性のある認証方式に加え、ボットによる大量ログイン試行や既知の脅威IPからのアクセスなどを検知・遮断する多層的な対策が重要です。

そもそもフィッシング詐欺とは

フィッシング詐欺とは、実在する企業や金融機関、公的機関を装った偽のメールや偽サイトに誘導し、IDやパスワード、クレジットカード情報を詐取する攻撃手法です。従来はメール中心でしたが、現在はSMS、SNS、QRコード、電話など複数のチャネルが悪用されています。

企業にとって深刻なのは、リスクが二面にわたる点です。ひとつは自社ブランドをかたられ、顧客への対応負荷とブランド毀損が生じること。もうひとつは従業員の認証情報が窃取され、社内システムへの侵害に発展することです。

フィッシング詐欺の主な手口と対策が追いつかない理由

フィッシング詐欺の手口は年々巧妙化し、不自然な日本語やURLの違和感といった従来の見分け方が通用しません。対策が追いつかない理由を3つ整理します。

① メール等による誘導とフィッシング詐欺メール対策の限界

メールやSMSに偽サイトのリンクを載せ、不安を煽って誘導する手口が基本です。フィッシングレポート2026では、フィルター回避のため表示されない制御コードを混ぜる手法が確認されています。

さらに、攻撃者自身が取得した独自ドメインからメールを送信し、DMARC認証を通過させるケースも確認されています。フィッシング対策協議会の2026年1月の報告では、調査対象のフィッシングメールの76.3％が独自ドメインによる「非なりすまし送信」で、その一部はDMARC認証にも成功していました。そのため、送信ドメイン認証だけですべてのフィッシングメールを防ぐことはできません。

出典：「2026/01 フィッシング報告状況」 フィッシング対策協議会

② 多要素認証を突破するリアルタイムフィッシング

リアルタイムフィッシングは、偽サイトに入力されたIDとパスワードを攻撃者が即座に正規サイトへ転送し、表示されたワンタイムパスワードもその場で窃取する手口です。IPAの資料でも、入力した情報が即座に悪用されると示されています。

ワンタイムパスワードを利用する方式など、一部の多要素認証はリアルタイムフィッシングによって突破される可能性があります。そのため、パスキーなどフィッシング耐性のある認証方式への移行と、不審なログイン試行を検知・制限する対策を組み合わせることが重要です。

Cloudbric WAF+では、脅威インテリジェンスを活用したボット対策やMalicious IP遮断を利用できるため、ボットによる自動化されたアクセスや既知の脅威IPからの通信をWebアプリケーションへ到達する前段階で遮断できます。ただし、リアルタイムフィッシング自体をWAFで防ぐものではないため、フィッシング耐性のある認証方式と併用することが重要です。

Cloudbric WAF+については、以下の記事で詳しく解説しています。あわせてお読みください。

Cloudbric WAF+とは？WAAP対応の6つの機能と選ばれる理由を解説

③ 正規サイトの改ざんによるフィッシングページの設置

攻撃者は偽サイトを用意するだけでなく、脆弱性を突いて正規サイトを改ざんし、配下にフィッシングページを設置することもあります。厄介なのは、そのページが正規ドメイン上に存在する点です。

URLのドメインを確認する一般的な見分け方が通用せず、利用者も運営者も気づきにくくなります。自社サイトが踏み台にされれば、ブランド毀損と顧客対応の負荷が同時に生じます。

IPAの「安全なウェブサイトの作り方」でも、SQLインジェクションやOSコマンドインジェクション、ディレクトリトラバーサルなど、Webサイトの改ざんにつながり得る脆弱性への対策が示されています。

企業が実施すべきフィッシング詐欺対策

企業が実施すべきフィッシング詐欺対策を入口・出口ごとに紹介します。

① 入口対策：教育・送信ドメイン認証・多要素認証

従業員教育では、不審なメールを開かない、URLをクリックせず公式サイトやブックマークからアクセスするといった基本行動の徹底が土台です。あわせて、リンクを開いた場合の報告ルールを明文化しておきましょう。報告が遅れれば初動も遅れ、被害が拡大します。

送信ドメイン認証では、SPF、DKIM、DMARCを適切に設定し、自社ドメインを不正にかたるメールを受信側が判別できるようにします。また、多要素認証は漏えいしたIDとパスワードのみを使った不正ログインへの有効な対策です。ただし、ワンタイムパスワード方式などはリアルタイムフィッシングで突破される可能性があるため、パスキーなどフィッシング耐性のある認証方式も検討する必要があります。

これらはいずれも重要な対策ですが、ひとつの対策だけですべてのフィッシング被害を防ぐことはできません。認証情報の窃取を想定し、フィッシング耐性のある認証方式や不審なアクセスを検知・遮断する仕組みを組み合わせることが重要です。

②Web側の防御：不正なアクセスとWeb攻撃を遮断する

窃取された認証情報は、リスト型攻撃（クレデンシャルスタッフィング）として大量の自動ログイン試行に使われます。正規の認証情報が使われるため、アプリケーション側のログでは通常のログインと区別しにくいのです。

ボットを使ったリスト型攻撃では、短時間に多数のログインを試みるなど、自動化されたアクセス特有の挙動が現れる場合があります。ボット対策や脅威IP遮断を活用することで、こうした不審な通信を検知・遮断し、不正アクセスのリスクを低減できます。

また、WAFはSQLインジェクションやOSコマンドインジェクションなど、Webサイトの改ざんにつながり得る攻撃の遮断にも有効です。ただし、窃取された正規アカウントによる管理画面へのログインなど、WAFだけでは防げない改ざん経路もあるため、認証強化や脆弱性管理との併用が必要です。Cloudbric WAF+では、WAF・ボット対策・Malicious IP遮断などをひとつのサービスで利用できます。

SQLインジェクションについては、以下の記事で詳しく解説しています。あわせてお読みください。

SQLインジェクションとは? 攻撃の仕組みや被害例、対策方法を解説

Cloudbric WAF+による出口対策の設定と防御範囲

Cloudbric WAF+は、WAFに加えDDoS攻撃遮断、API保護、ボット対策、Malicious IP遮断を単一プラットフォームで提供するクラウド型WAFです。導入はDNS情報の変更のみで完了します。ここからは設定すべき3つの機能を解説します。

①ボット対策で不正ログイン試行を遮断する

ボット対策機能では、脅威インテリジェンスから抽出・評価された悪性ボットと良性ボットを管理画面上で切り分けて制御できます。検索エンジンのクローラーなどは許可したまま悪性ボットのみを遮断できるため、SEOや正規サービスへの影響を抑えられます。

さらにCloudbric WAF+ v3.0では、利用環境に合わせたカスタムボットブロック機能が追加されています。良性ボットを管理しながら、自社環境で不要または不審と判断したボットを個別に制御できるため、自動化された不正アクセスへの防御を強化できます。

v3.0では良性ボットの管理とカスタムボットブロック機能が追加され、ボットセキュリティが強化されています。

②脅威IP遮断で悪性IPからのアクセスを排除する

Malicious IP遮断は、Cloudbric Labsの脅威インテリジェンスをもとに、危険度スコアリングが最も高い「危険度10」の脅威IPを遮断する機能です。Cloudbric WAF+ v3.0では、世界171カ国・70万以上のサイトから収集した脅威インテリジェンスを活用しており、IPの評価は毎日更新されます。

既知の脅威IPをあらかじめ遮断することで、不正アクセスやWeb攻撃に利用された実績のある送信元からの通信をWebアプリケーションへ到達する前段階で排除できます。ボット対策と組み合わせることで、不正アクセスに対する防御層を追加できます。

③WAFエンジンでサイト改ざんにつながるWeb攻撃を遮断する

Webアプリケーションの脆弱性を悪用した改ざんを防ぐには、攻撃通信をWebアプリケーションへ到達する前に検知・遮断することが重要です。Cloudbric WAF+は、日本を含む5カ国で特許を取得した独自の論理演算検知エンジンとAIエンジンを搭載し、SQLインジェクションやXSS、コマンドインジェクションなどのWeb攻撃を検知・遮断します。

Cloudbric WAF+では、DNS切り替え後に標準で約1カ月間の検知モードを設け、セキュリティエキスパートが検知ログを分析したうえで、保護対象ごとのセキュリティ運用ポリシーを作成・適用するマネージドサービスが提供されています。

フィッシング詐欺対策に関するQ&A

最後に、実務でよく寄せられる質問を3つ取り上げます。

Q1．多要素認証を導入していればフィッシング詐欺は防げますか？

多要素認証の方式によって異なります。ID・パスワードにワンタイムパスワードを組み合わせる方式は、リアルタイムフィッシングで突破される可能性があります。一方、パスキーなどフィッシング耐性を持つ認証方式は、リアルタイムフィッシングへの有効な対策です。認証強化に加え、不審なアクセスを検知・遮断する対策も組み合わせましょう。

Q2．フィッシングサイトにアクセスするだけでも被害を受けますか？

フィッシングサイトへアクセスしただけで、必ずIDやパスワードが窃取されるわけではありません。一般的なフィッシングでは、偽サイトに認証情報やクレジットカード情報などを入力することで情報が窃取されます。ただし、悪意あるスクリプトやマルウェアなど別の攻撃が組み合わされている可能性もあるため、不審なサイトに気づいたら入力や操作をせず離脱してください。

Q3．自社をかたるフィッシングサイトを見つけた場合はどうすればよいですか？

フィッシング対策協議会と警察に報告し、公式サイトやSNSで注意喚起します。あわせて自社サイトが改ざんされていないか確認してください。

まとめ

フィッシング詐欺の対策は、メールや偽サイトへの対策だけでは完結しません。従業員教育や送信ドメイン認証に加え、パスキーなどフィッシング耐性のある認証方式を導入し、認証情報が窃取された場合も想定した多層防御が必要です。また、ボットによる大量ログイン試行やWebアプリケーションへの攻撃を検知・遮断する対策も、被害拡大のリスクを抑えるうえで有効です。

Cloudbric WAF+は、ボット対策、Malicious IP遮断、WAFなどをひとつのサービスで提供し、自動化された不正アクセスやWebアプリケーションへの攻撃に対する防御を強化できます。マネージドセキュリティサービスも付帯しているため、自社だけでWAFを設計・運用する負荷を抑えられます。フィッシングを起点とした不正アクセスを含め、Web側のセキュリティを強化したい方は、まず資料をご覧ください。

AWS WAFは、AWS上のWebアプリケーションを守る有効な選択肢です。ただし有効化しただけでは効果は出ません。成果を左右するのは、適切なルール設計と継続的な運用です。専任のセキュリティ担当者を置けない組織なら、AWS WAF専用の運用管理サービスであるCloudbric WMSの活用が現実的な解になります。

この記事では、AWS WAFについて実現できることや課金体系などについて紹介します。

AWS WAFとは？

AWS WAFは、Webアプリケーションに届くHTTP／HTTPSリクエストを検査し、条件に応じて許可・ブロック・カウントを判定するアプリケーション層（L7）のセキュリティサービスです。

AWS WAFでは、検査条件と一致時のアクションをルールとして定義し、複数のルールをWeb ACLにまとめて保護対象のAWSリソースに関連付けます。代表的なルールアクションにはAllow、Block、Countのほか、CAPTCHAやChallengeがあります。Web ACLはCloudFrontやALBをはじめ、API GatewayやAppSyncなど複数のAWSリソースに関連付けられます。

なお責任共有モデル上、アプリケーションを守る責任は利用者側にあります。

AWS WAFで防げる攻撃・防げない攻撃

防げるのは、リクエストの内容や送信元の特性から判別できる攻撃です。SQLインジェクション、クロスサイトスクリプティング（XSS）、悪意あるボット、既知の脆弱性を狙う攻撃が代表例です。

一方、権限昇格などビジネスロジックの脆弱性はリクエストが正規の形式のため検知が難しく、ネットワーク層の大規模DDoSはAWS Shieldの領域です。AWS WAFは多層防御の一層と位置づけましょう。

AWS Shieldとの違い

両者は守備範囲が異なります。主な違いは以下のとおりです。

AWS WAFが主にL7のWebリクエストを検査するのに対し、Shield Standardは主にL3／L4のDDoS攻撃を自動的に防御します。Shield StandardはすべてのAWS利用者に追加料金なしで提供され、Shield Advancedではより高度なDDoS防御に加え、AWS WAFと連携したL7のDDoS対策も利用できます。両者は用途が異なるため、必要に応じて組み合わせて利用します。 

AWS WAFの料金体系

AWS WAFに初期費用はかかりません。ただし従量課金である以上、使い方次第で費用は大きく変わります。課金の構造と、高額になりやすいケースを整理します。

AWS WAFで課金される3つの要素

料金は、作成したWeb ACLの数、追加したルールの数、処理したWebリクエスト数の3要素で決まります。

基本料金に加え、1,500 WCUを超えるWeb ACL、追加の本文検査容量、CAPTCHA／Challenge、Bot ControlやFraud Controlなどの機能では追加料金が発生する場合があります。

ログについても保存先や使用量などに応じて関連サービスの料金が発生する場合があります。料金体系は変更される可能性があるため、見積りは公式の料金ページで確認してください。

料金が想定より高くなるケースと抑えるポイント

料金が膨らむのは、環境ごとにWeb ACLを個別作成している、マネージドルールを必要以上に適用しているといったケースです。

料金を見直す際は、Web ACLや適用中のルール、ルールグループの構成を確認し、必要性を精査することが重要です。ただし、防御性能を維持しながらルールを調整するには専門知識が求められます。Cloudbric WMSでは、AWS WAFのログや利用環境をもとにセキュリティエキスパートがルールの最適化と運用を支援するため、社内の運用工数を抑えやすくなります。

AWS WAFの導入・設定の流れとマネージドルールの選び方

導入自体は難しくありません。マネジメントコンソールから数ステップで有効化できます。つまずきやすいのは、その先のルール選定です。判断を誤ると、守れないか、正規のアクセスを止めてしまいます。

Web ACLの作成からリソース関連付けまでの3ステップ

導入は3ステップで進められます。

1. Web ACLを作成し、どのルールにも一致しないリクエストの扱いをデフォルトアクションとして決める
2. マネージドルールやカスタムルールを追加し、評価の優先順位を設定する
3. CloudFrontやALBなど保護対象のリソースにWeb ACLを関連付ける

最初からブロックで始めるのは避けましょう。まずカウントモードでログを観察し、誤検知がないと確認してから切り替えるのが安全です。

AWSマネージドルール一覧と選び方

AWS Managed Rulesには、ベースラインルールグループとユースケース固有のルールグループだけでなく、IPレピュテーション、Bot Control、アカウント乗っ取り・不正アカウント作成対策、Anti-DDoSなど複数の種類があります。

利用するルールグループは、自社のアプリケーション構成やリスクに合わせて選定します。各ルールグループにはWCUが設定されているため、Web ACL全体のキャパシティも考慮が必要です。また、本番環境へ適用する前には誤検知がないかテストと調整を行うことがAWSから推奨されています。

Cloudbric WMSでは、ユーザーのログや利用環境に基づき、セキュリティエキスパートがルールの最適化を支援します。

AWS WAFの運用でつまずきやすい3つの課題

AWS WAFは導入して終わりではありません。負荷が集中するのは、有効化したあとの運用フェーズです。代表的な3つの課題を取り上げます。

課題①ルール設計とWCU（キャパシティ）の制約

WCU（Web ACLキャパシティユニット）は、ルールの実行に必要なリソース量を数値化したものです。Web ACLごとに上限があり、複雑なルールほど多く消費します。限られたキャパシティのなかで、守りたい範囲と消費量のバランスを取る設計が求められます。

この判断には攻撃手法とアプリケーション構成の双方への理解が必要で、専任者がいない組織では後回しにされがちです。

課題②誤検知への対応

マネージドルールは汎用的なため、自社アプリケーション特有のリクエストが誤判定され、正規ユーザーの操作が遮断されることがあります。

対応にはログから該当ルールを特定し、除外設定で調整する作業が必要です。恐れて全ルールをカウントモードのまま放置すれば、実質的に無防備な状態が続きます。その点、Cloudbric WMSなら対応をエキスパートに任せられます。

課題③新規脆弱性への追従と24時間365日の監視

新たな脆弱性は日々公表され、攻撃コードが出回るまでの時間も短くなっています。自社運用では、情報収集、影響判断、ルールへの反映を継続する体制が必要です。

しかし通常業務と兼務する担当者が夜間や休日まで対応し続けるのは現実的ではなく、監視の空白時間がそのままリスクとして残ります。

Cloudbric WMSが選ばれる4つの理由

AWS WAFを適切に運用するには、ルール設計や誤検知への対応、新たな脆弱性への追従などを継続して行う必要があります。こうした運用負荷を自社だけで担うことが難しい場合に選択肢となるのが、Cloudbric WMSです。

Cloudbric WMSはAWS WAFの代替製品ではなく、AWS WAFの運用を支援する管理サービスです。AWS WAFを利用しながら、専門家によるルールの最適化や監視・運用支援を受けられます。ここでは、Cloudbric WMSが選ばれる4つの理由を紹介します。

理由① 高度な攻撃検知能力

WAFに深い知見を持つペンタセキュリティが独自開発した攻撃検知エンジンを備え、リアルタイムのログ分析、脅威IPの自動遮断、新規脆弱性への対応を継続的に行います。

Cloudbric WMSで利用されるCloudbric Rule Setについて、第三者検証機関Tolly GroupがOWASP Top 10のWeb脆弱性を対象とした413種類の攻撃トラフィックで比較テストを実施したところ、91.53％の正常検知率を記録しました。比較対象となった他社ルールセットは50.61～68.28％で、最も高い比較対象との差は23.25ポイントでした。 

出典：ペンタセキュリティのCloudbric Rule Set、Tolly Groupの検証によって他社製品よりも高い攻撃検知率であることが実証

理由② エキスパートによるコンサルティングとサポート

カスタムルールの作成や誤検知への対応を、セキュリティエキスパートに相談できます。24時間365日のモニタリング体制が整っているため、夜間や休日の空白を自社で埋める必要がありません。

適用されるのは汎用テンプレートではなく、ユーザーのログをもとにOWASP Top 10対応のポリシーとMalicious IP Reputationを環境へ合わせたものです。

理由③ 運用負荷軽減とコスト削減

ルールの作成や新規脆弱性への対応をCloudbric WMS側が担うため、社内の運用工数を抑えられます。インシデント発生時の調査・復旧費用も、未然に防げた分だけ削減できます。

Cloudbric WMSでは、ルール作成や新規脆弱性への対応、ログ分析などをセキュリティエキスパートが支援するため、AWS WAFを自社だけで運用する場合に必要となる人的な運用負荷や管理コストの削減につながります。

理由④ 専用コンソールによる可視化

専用コンソールから、IP遮断や国別アクセス制御を画面上で変更できます。運用状況が把握できるダッシュボードとセキュリティレポートも提供され、約3カ月分のログ管理が付帯します。

AWS WAFでもCloudWatchメトリクスやサンプリングされたWebリクエスト、ログなどを利用できますが、継続的な分析やレポート作成には設定・運用が必要です。Cloudbric WMSでは専用ダッシュボードやセキュリティレポートが用意され、約3カ月分のWeb ACLログ分析データを確認できるため、運用状況を把握しやすくなります。

AWS WAFに関するよくある質問

検討段階でよく寄せられる質問を4つにまとめました。

Q1. AWS WAFとは何ですか？

Webアプリケーションへのリクエストを検査し、許可・ブロック・カウントを判定するアプリケーション層のセキュリティサービスです。SQLインジェクションやXSSなど、内容から判別できる攻撃を遮断します。

Q2. AWS WAFとAWS Shieldの違いは何ですか？

守備範囲が異なります。AWS WAFはアプリケーション層（L7）、AWS Shieldは主にネットワーク層・トランスポート層（L3／L4）のDDoS防御を担当します。併用が前提です。

Q3. AWS WAFは無料で使えますか？

初期費用は不要ですが無料ではありません。Web ACL数、ルール数、処理リクエスト数に応じた従量課金が発生します。最新の単価はAWS公式の料金ページで確認してください。

Q4. AWS WAFの運用は自社だけでできますか？

可能です。ただしルール設計、誤検知対応、新規脆弱性への追従、24時間365日の監視を継続できる体制が前提です。難しい場合はCloudbric WMSのような運用管理サービスの活用が有効です。

まとめ

AWS WAFはAWS上のWebアプリケーションを守る有効な手段です。ただし成果を左右するのは導入そのものではなく、その後の運用です。ルール設計、誤検知への対応、新規脆弱性への追従と24時間365日の監視を継続できて初めて、期待どおりに機能します。

専任のセキュリティ担当者を置けない場合は、AWS WAFに特化した運用管理サービスであるCloudbric WMSという選択肢があります。高い検知率が第三者機関のテストで確認されたCloudbricのルールセットに加え、24時間365日のモニタリング・サポートを利用でき、30日間の無償トライアルも用意されています。

お悩みの際はぜひCloudbricまでお気軽にご相談ください。

Webサイトを狙う悪性ボットの被害を防ぐには、相手が人間かボットかを自動で見分けて遮断する仕組みと、多層防御が欠かせません。自動化された攻撃は年々巧妙になり、人の目による監視だけで防ぎ切ることは難しくなっています。

本記事では、ボットの基礎から攻撃手法、悪影響、対策方法までを解説します。

ボット対策とは？

ボットと聞くと不正なプログラムを思い浮かべがちですが、実際には利便性を支える有益なボットも存在します。対策の対象となるのは、不正を目的とする「悪いボット」です。

ボット（bot）とは

ボットとは「ロボット（Robot）」を語源とする言葉で、決められた処理を人の手を介さずに自動かつ高速で実行するプログラムの総称です。人間が数時間かける作業を数分で終えられる点が特徴です。

身近な例としては、検索結果に情報を反映させるクローラー、問い合わせに自動応答するチャットボットなどが挙げられます。これらはいわば「良いボット」であり、技術自体は中立的で、善悪は使われ方によって決まります。

対策が必要な「悪性ボット」とは

一方で、不正アクセスやデータの窃取、サービスの妨害といった悪意ある目的で運用されるボットも存在します。これが「悪性ボット（悪いボット）」であり、対策するべき相手です。24時間365日稼働する自動性、正規の利用者になりすます隠蔽性、手口を変える適応性を備えています。両者の違いを整理すると、次のとおりです。

良いボットまで一律に遮断すると検索順位の低下などにつながるため、両者を見極める視点が欠かせません。

悪性ボットによる主な攻撃・脅威の種類

悪性ボットの代表的な4つの手口を見ていきます。いずれも人間を装った自動プログラムにより、大量かつ高速に行われる点が共通しています。

リスク① クレデンシャルスタッフィング

クレデンシャルスタッフィングとは、漏えいしたIDとパスワードのリストを使い、ボットが複数のサービスへ自動でログインを試みる手口です。パスワードを使い回す習慣が悪用され、一つの漏えいが連鎖的な被害を招きます。

ログインに成功するとアカウントが乗っ取られ、登録情報の窃取や不正購入につながります。厄介なのは、正規のログインフォームに正しい形式でアクセスしてくる点です。不正な文字列を含まないため、WAF単体では検知しきれないケースも見られます。試行の頻度やIPアドレスの異常を見るボット検知との併用が有効です。

リスク② スクレイピング

スクレイピングは、ボットがWebサイト上のコンテンツや商品情報を自動的に収集する手口です。人間なら何日もかかる作業を数分で終えるため、サイト全体の情報が短時間で抜き取られることもあります。

ECサイトでは価格や在庫の情報を競合他社に収集され、価格戦略を先読みされる恐れがあります。記事や画像の無断複製、大量アクセスによる表示速度の低下も生じます。ただし検索クローラーとの線引きは難しく、一律のブロックは正規のアクセスまで弾くため、両者を見分ける仕組みが必要です。

スクレイピングへの対策については、以下の記事で詳しく解説しています。あわせてお読みください。

スクレイピング対策とは？IPブロック・CAPTCHA・WAFなど有効な手法を紹介

リスク③ DDoS攻撃・ボットネット

DDoS攻撃は、標的のサーバーに大量のリクエストを一斉に送りつけ、過剰な負荷でサービスを停止に追い込む攻撃です。ここで使われる「ボットネット」とは、マルウェアに感染して遠隔操作が可能になった多数の端末を、攻撃者がまとめて操るものを指します。

注意したいのは、社内のPCやIoT機器が感染すれば、知らないうちに他社への攻撃へ加担する加害者側にもなり得る点です。またWebアプリケーション層（L7）を狙うDDoSは通常のアクセスに紛れ込むため、通信量だけを見る防御では見分けにくい傾向にあります。

DDoS攻撃対策については、以下の記事で詳しく解説しています。あわせてお読みください。

DDoS攻撃への対策とは？攻撃手法や実際の被害事例も紹介

リスク④ スパム・買占め・アドフラウド

問い合わせフォームや会員登録フォームに、ボットが自動で大量の投稿を行うスパムも代表的な被害です。担当者が対応に追われて業務が妨げられ、不要なデータの蓄積を招く原因にもなります。

また、限定商品やチケットを買い占めて高値で転売する「買占め（スカルピング）」も問題です。正規の利用者が購入できず、不満につながります。さらに広告を自動でクリックし広告費を消費させる「アドフラウド」もあり、いずれも人間には不可能な速度と量で実行されます。

ボットを放置することで生じる悪影響・被害

ここまでの攻撃は、企業にどのような損失をもたらすのでしょうか。金銭・情報の面と、サービス・信頼の面に分けて整理します。

金銭的被害・情報漏えい

不正ログインでアカウントが乗っ取られると、クレジットカードの不正購入など直接的な金銭被害が発生します。また顧客の個人情報が流出すれば、補償や損害賠償に加え、原因調査や再発防止の対応コストが重くのしかかります。被害が顧客や取引先にも波及するケースも見られます。

サービス停止・信頼失墜

DDoS攻撃でサービスが停止すれば、その間の売上機会を失うだけでなく、復旧作業にも人手とコストがかかります。稼働時間が収益に直結するECサイトでは、短時間の停止でも影響は小さくありません。買占めによる購入機会の喪失も顧客体験の低下を招き、長年築いた信頼が損なわれます。

ボットへの対策とは

悪性ボットへの対策には、人間かボットかを自動で見分ける仕組みと、複数の手段を重ねる多層防御が必要です。その点、Cloudbric WAF+のようなWAF・ボット検知機能を備えたソリューションであれば、自動化された不正アクセスを入口の段階で抑えられます。

対策① 自社で取り組む基本の対策

まず着手できるのが、認証まわりの基本的な対策です。推測されにくいパスワードを設定し、使い回しを避ける運用の徹底で、クレデンシャルスタッフィングの成功率を下げられます。

あわせて多要素認証（MFA）の導入も効果的です。「知識情報」「所持情報」「生体情報」から複数を組み合わせて本人確認を行う仕組みで、パスワードが漏れても不正ログインを防ぎやすくなります。

CAPTCHAも広く使われていますが、高度なボットに突破される場合もあり、基本策だけで万全とはいえません。

対策② ツール・サービスの導入

そこで、相手が人間かボットかを専用のツールで自動的に見分ける方法があります。たとえばブラウザ情報（HTTPヘッダ）に不自然な点がないか、JavaScriptやCookieを人間のブラウザと同じように扱えるか、端末の特徴（フィンガープリント）に不審なパターンがないか、といったサインを複数組み合わせて判断します。

ざっくり言えば「人間なら当たり前にできることができているか」を見ています。こうした判定を手作業で行うのは現実的ではなく、自動でチェックできる仕組みが求められます。

対策③ WAF・ボット検知ソリューションによる対応

複数の検知技術を統合し、正規の利用者を妨げずに悪性ボットだけを見分ける手段として有効なのが、WAF・ボット検知ソリューションの導入です。その点、Cloudbric WAF+であれば、既知の攻撃パターンの遮断や不正アクセスの防御に加え、DDoS対策やボット検知にも対応し、クラウド型のため機器の設置が不要です。

ただし、WAFも万能ではありません。正規の形式でアクセスしてくる攻撃には、認証・認可の設計やログ監視との併用が前提となります。多層防御の中核と位置づけ、基本の対策と組み合わせて運用しましょう。

Cloudbric WAF+については、以下の記事で詳しく解説しています。あわせてお読みください。

Cloudbric WAF+とは？WAAP対応の6つの機能と選ばれる理由を解説

ボット対策に関するよくある質問

最後に、よく寄せられる質問にお答えします。

Q1. 良いボットと悪いボットの違いは？

良いボットは、検索エンジンのクローラーやチャットボットのように、利便性を高めるために動く自動化ツールで、運営者が定めたルールに従います。一方の悪いボットは、不正アクセスやデータ窃取を目的とし、ルールを無視して人間になりすまします。対策の対象は後者です。

Q2. 自社サイトがボットに狙われているか確認する方法は？

アクセス数が特定の時間帯だけ不自然に急増している、短時間に大量のログイン試行がある、想定されない地域からのアクセスが多い、といった兆候があれば狙われている可能性があります。アクセスログの定期的な確認が第一歩で、ボット検知ツールを使えば異常を可視化できます。

Q3. CAPTCHAだけでボット対策は十分？

CAPTCHAは手軽に導入できる基本的な対策ですが、それだけで十分とは言えません。近年は画像認識技術の進化により、突破できる高度なボットも登場しているためです。また利用者の手間が増え、離脱の原因になる場合もあります。行動分析やWAFと組み合わせた多層的な防御が推奨されます。

まとめ

本記事では、ボットの基礎から攻撃の種類、悪影響、具体的な対策方法までを解説しました。ボットには検索クローラーのような良いボットと、不正を目的とする悪いボットがあり、対策すべきは後者です。

悪性ボットはクレデンシャルスタッフィングやスクレイピング、DDoS攻撃、買占めといった手口で、金銭的被害やサービス停止、信頼の失墜を引き起こします。それらを防ぐには、パスワード運用や多要素認証といった基本の対策に加え、ボットを自動で見分ける仕組みを組み合わせた多層防御が欠かせません。

その入口として、Cloudbric WAF+の導入をぜひご検討ください。

2026年5月16日から発生したKDDIの情報漏洩（以下、情報漏えい）のような被害を防ぐには、単一の情報セキュリティ製品に頼らず、運用の見直し・監視の強化・入口での防御を重ねる多層防御が必要です。

今回の不正アクセスは、ソフトウェアの提供元すら把握していなかった未知の脆弱性が悪用されたもので、ひとつの対策だけで防ぎ切ることは困難でした。

本記事では、何が起きたのかを整理したうえで、対象サービスや原因、利用者が今すぐ取るべき対応と企業の対策を解説します。

KDDIの情報漏えいとは？

KDDIの情報漏えいは、同社がインターネットサービスプロバイダー（ISP）事業者向けに提供するメールシステムが不正アクセスを受け、利用者のメールアドレスとパスワードが流出した事案です。2026年6月に第一報が公表され、7月に件数が確定しました。

不正アクセスの概要と経緯

被害を受けたのは、KDDIが開発し、ISP事業者向けに提供していたメール基盤で、au メールなど自社のメールサービスとは別の設備で運用されていました。

不正アクセスは一部のISP事業者において2026年5月16日から発生しており、KDDIが確認したのは6月17日です。同日中にシステムを改修して脆弱性へ対処し、6月23日には第一報として最大1,422万件の漏えいの可能性を公表しました。その後、総務省から電気通信事業法に基づく報告を求められ、7月6日に報告書を提出するとともに確定件数を明らかにしています。

再発防止策としては、6月21日に外部通信を制御する全サーバーへのEDR導入を完了し、6月23日には第三者機関の調査で当該脆弱性以外に不審な痕跡がないことを確認しています。今後はAI等も活用したプログラム分析や、より安全な通信規格への移行を進めるとしています。

漏えいが確認された情報と件数

2026年7月6日の公表による確定件数は次のとおりです。

• 電子メールアドレス：約1,223万件（のちに1,223万1,954名へ訂正） 
• パスワード：約762万件（7,61万6,173名） 
• 解約済みや休眠のアカウント、ハッシュ化・暗号化されたパスワードも含む

パスワードの漏えい人数はメールアドレスの漏えい人数に含まれる「内数」であり、両者を足した数が被害総数になるわけではありません。

情報漏えいの対象は？auメールが大丈夫な理由

自分が対象かどうかは、利用中のメールサービスの提供事業者で判断できます。対象はメール基盤を利用していた6社に限られます。

対象となるサービス

対象となったのは次の6社のメールサービスです。集計単位が事業者ごとに異なるため、単純な合算はできません。

※上記の数字には、すでに解約した方や休眠アカウントも対象に含まれるため、注意が必要です。

auメール・UQ mobileメールが影響を受けない理由

au メール、UQ mobile メール、au one net メールについては、今回の影響はないとされています。これらがISP事業者向けメール基盤とは異なる設備で運用されているためです。

社名が同じKDDIであることから混同されやすいものの、被害を受けたのは他社のISPへ提供していた共通のメールシステムであり、自社の契約者向けサービスとは切り分けられています。

情報漏えいの原因はゼロデイ脆弱性

原因はメールシステムに組み込まれていた第三者製ソフトウェアの脆弱性であり、発覚時点で提供元すら認識していなかった点が特徴です。

情報漏えいの原因について

KDDIの公表によれば、今回の不正アクセスはシステムの一部として導入していた第三者製ソフトウェアの脆弱性を悪用されたものです。この脆弱性は、確認時点の6月17日でベンダー自身も把握していない、いわゆるゼロデイの状態でした。

修正プログラムが存在しない未知の脆弱性は事前に完全に塞ぐことが難しく、この前提が対策の考え方を左右します。

ゼロデイ攻撃については、以下の記事で詳しく解説しています。あわせてお読みください。

ゼロデイ攻撃とは？最新の手口や事例・有効な対策を紹介

なぜ被害が複数事業者に広がったのか

被害が6社にまたがった背景には、複数のISPが一つの共通基盤を利用していた構造があります。基盤側の脆弱性が、その上でサービスを提供していた各社へ連鎖的に波及しました。

これは委託先や利用中のソフトウェアの弱点が突かれるサプライチェーンリスクの典型例です。IPAの「情報セキュリティ10大脅威2026」でも上位に挙げられており、委託しているから安全とは限らないという教訓を示しています。

情報漏えいで想定されるリスク

最も警戒すべきなのは、他サービスへの二次被害です。同じパスワードを使い回していると、流出情報をもとに別サービスへログインを試みるパスワードリスト攻撃（クレデンシャルスタッフィング）でアカウントを乗っ取られるおそれがあります。ネットショッピングや金融サービスに波及すれば、不正購入や金銭被害につながるケースも見られます。

また、こうした事案の後は混乱に便乗したフィッシングメールが増える傾向にあります。使い回しが残る状態こそが最大のリスクと言えます。

【利用者向け】今すぐやるべきこと

対象サービスを利用中の方、または過去に利用していた方は、次の対応を早めに実施してください。

• まず対象のメールサービスのパスワードを変更する（各ISPの案内と期限を確認）
• 同じパスワードを使い回している他のサービスもあわせて変更する
• パスワードはサービスごとに別のものを設定し、管理ツールの活用も検討する 
• 対応しているサービスでは二段階認証（多要素認証）を有効にする
• 「パスワード変更のお願い」等の偽メールに注意し、公式サイトを自分で開いてログインする

メールソフトに保存したパスワードの更新漏れにも注意してください。

【企業向け】情報漏えいを防ぐための対策とは

企業が同種の被害を防ぐには、運用の見直しを土台に、ITツールによる監視、WAFによる入口防御を段階的に重ねる多層防御が有効です。

対策① 運用の見直し

定期的な脆弱性診断で自社システムや委託先の弱点を把握し、パッチ管理によって公表済みの脆弱性を早期に塞ぐ体制を整えます。今回のように委託先が起点となる事案もあるため、サプライチェーン全体を対象とした管理も欠かせません。

ただし修正プログラムが未提供のゼロデイ脆弱性には、運用の徹底だけでは限界があります。

対策② ITツール活用による監視・検知の強化

運用で塞ぎきれない部分を補うのが、ログ監視やEDR等のITツールによる検知です。前述のとおりKDDIもEDR導入を完了していますが、EDRは侵入そのものを事前に防ぐ製品ではなく、侵入後の不審な挙動を検知して対応を早める仕組みである点は理解しておく必要があります。

今回は攻撃の発生から認識まで約1カ月の空白がありました。この「気づくまでの時間」の短縮が、被害規模を左右します。

対策③ WAFの活用

異常に「気づく」体制に加え、入口で攻撃を「止める」層を担うのがWAFです。既知の攻撃パターンを遮断できるほか、脆弱性の公表後に本体の修正を待たず、仮想パッチで暫定的に通信を遮断できる点も利点です。

その点、Cloudbric WAF+であれば、既知の攻撃や不正アクセス、DDoS攻撃、ボット検知に対応するWAAP型のサービスとして、脅威の判明から防御適用までの時間を短縮できます。

もっともWAFも万能ではなく、運用の見直しや監視と組み合わせてこそ効果を発揮する多層防御の一層として位置づけることが大切です。

Cloudbric WAF+については、以下の記事で詳しく解説しています。あわせてお読みください。

Cloudbric WAF+とは？WAAP対応の6つの機能と選ばれる理由を解説

よくある質問

Q1．自分は今回の漏えいの対象ですか？

対象となるのは、KDDIのISP向けメール基盤を利用していた6社（BIGLOBE、@nifty、J:COM NET、コミュファ光、ピカラ、CPI）の利用者です。解約済みの方や長期間使っていない方も含まれる可能性があるため、各社の公式案内をご確認ください。

Q2．漏えいの原因は何ですか？

メールシステムに導入していた第三者製ソフトウェアの脆弱性が悪用されたことが原因です。この脆弱性は、KDDIが確認した2026年6月17日時点でベンダーも認識していないゼロデイの状態でした。不正アクセスは一部の事業者で同年5月16日から発生していたとされています。

Q3．auメール・UQ mobileメールは大丈夫ですか？

au メール、UQ mobile メール、au one net メールは、今回のISP向けメール基盤とは別の設備で運用されていたため、影響はないとされています。対象となったのはISP事業者向けの共通メールシステムであり、自社の契約者向けサービスとは切り分けられています。

まとめ

KDDIの情報漏えいは、ISP事業者向けメール基盤の第三者製ソフトウェアに存在したゼロデイ脆弱性が悪用され、約1,223万件のメールアドレスと約762万件のパスワードが流出した事案です。対象は6社で、au メールなど自社サービスは影響を受けていません。

利用者はパスワード変更と使い回しの解消を、企業は運用の見直しから監視、入口防御へと重ねる多層防御を進めることが重要です。

入口対策として、Cloudbric WAF+の導入もあわせてご検討ください。

Webサイトやシステムを運営する企業にとって、WAF（Web Application Firewall）は欠かせないセキュリティ対策の1つです。WAFを導入することで、Webアプリケーションの脆弱性（セキュリティ上の弱点）を突く攻撃を検知・防御できます。

WAFの導入を検討する際、無視できないのがコスト面です。「どのWAF製品が自社に合っているのか」「料金はどのくらいかかるのか」といった疑問を抱える担当者は多いのではないでしょうか。

そこで本記事では、おすすめのWAF製品8選を料金や特徴とともに比較し、製品選びで押さえたいポイントを解説します。なお、WAFの仕組みや種類、導入メリットについて詳しく知りたい方は、次の記事もあわせてご覧ください。

WAF導入の方法は？メリット・デメリット・費用・注意点をわかりやすく解説

WAFのおすすめ8製品・料金比較表

本記事で紹介するおすすめWAF製品8選の料金や提供形態を一覧表でまとめました。まずは、自社の予算やシステム環境に合う製品の目星をつけるための参考にしてください。

※記載内容は2026年7月時点の公式サイト情報にもとづいています。

WAFのおすすめ8製品を紹介！

ここからは、比較表で挙げた各WAF製品の概要や強みを順番に解説します。料金だけでなく、導入のしやすさや運用負担も比較しながら、自社に適した製品を選びましょう。

①Cloudbric WAF+

「Cloudbric WAF+」は、特許取得のAI（人工知能）およびロジックベースの高精度な検知能力を持つクラウド型WAFです。WAF機能に加え、DDoS攻撃の対策やボット対策など、幅広いセキュリティ機能をオールインワンで提供します。

24時間365日体制の専門家による運用サポートが標準で付帯しているのが特長です。専任のセキュリティ担当者が不要となるため、運用にかかる見えない人件費を削減しやすいでしょう。

明快な料金体系を採用しています。初期費用は発生するものの、個別設定や環境構築、ポリシー作成といった導入支援サポートまで一貫して含まれる設計です。運用を含めたトータルコストを抑えたい企業におすすめです。

Cloudbric WAF+については、以下の記事で詳しく解説しています。あわせてお読みください。

Cloudbric WAF+とは？WAAP対応の6つの機能と選ばれる理由を解説

②攻撃遮断くん

「攻撃遮断くん」は、国内で多くの導入実績を持つクラウド型WAFです。DNSの設定を切り替えるだけで、最短即日で導入を完了できるスピード感に定評があります。24時間365日の日本語サポートが用意されており、専門知識が少ない担当者でも安心です。

手軽な料金設定で、予算の限られた中小企業でも無理なくスタートできます。ただし、初期費用は導入する構成やプランによって変わってくるため、事前に確認しましょう。

③BLUE Sphere

「BLUE Sphere」は、多層的な防御をワンパッケージで提供するクラウド型WAFです。DDoS防御やWebサイトの改ざん検知までを1つのサービスでカバーしています。大きな特長は、万が一の事故に備えたサイバー保険が追加費用なしで自動付帯される点です。

料金体系は、サイバー攻撃を含む受信通信を含めず、送信（アウトバウンド）データ量のみを基準とします。過去3か月の合計データ量で費用を算出するため、突発的なアクセス増加による費用の増額が発生しません。1つの契約で20ドメインまで追加費用なしで保護できるため、複数のWebサイトを運営する企業におすすめです。

④AWS WAF

「AWS WAF」は、Amazon Web Services（AWS）環境に特化したクラウド型WAFです。あらかじめ用意された保護テンプレートなどを活用し、セキュリティ設定の手間を削減します。ボットの監視や制限をはじめ、APIやWebアプリケーションの保護に必要な機能を幅広くカバーしているのが特長です。

料金は初期費用なしの完全従量課金制で、設定したルール数や処理したリクエスト数に応じて細かく決まります。「Amazon CloudFront」など別のAWSサービス利用料に上乗せされるほか、ログの保存量でも費用が変動する仕組みです。料金体系がやや複雑な面があるため、導入時は自社のシステム構成に合わせた事前のコスト試算が欠かせません。

⑤Cloudflare WAF

「Cloudflare WAF」は、世界規模のネットワークから得られる脅威情報を活用したWAFです。機械学習を用いて、ゼロデイエクスプロイト（修正前の脆弱性を狙う攻撃）を自動で阻止します。複雑な専門知識がなくても、数回のクリックだけでスムーズに導入や設定を完了できる手軽さが特長です。

料金は月額20ドルから利用でき、Webサイトの規模や必要な機能に応じてプランを選択できます。上位プランでは、より高度なセキュリティ機能や細かなルール設定に対応可能です。ただし、大規模なシステムや高度な要件の場合は、個別見積もりのカスタムプランの利用が必要となります。

⑥SiteGuard

「SiteGuard」は、純国産のWAF製品です。クラウド型の「SiteGuard Cloud Edition」と、ソフトウェア型の「SiteGuard Server Edition」「SiteGuard Proxy Edition」から、環境に応じた導入形態を選べます。

クラウド型は通信量ごとの定額プラン、ソフトウェア型はOS単位の年間ライセンス契約です。クラウド型は、あらかじめ設定された通信量プランの中で定額利用する形で、超過通信量の扱いはプランごとに定められています。一方、ソフトウェア型は年額固定で、トラフィック量による課金はありません。

⑦Imperva WAF

「Imperva WAF」は、クラウド環境とオンプレミス環境の両方に対応するエンタープライズ向けのWAFです。自動ポリシー生成や脅威検知機能を備え、Cloud WAF（SaaS）とWAF Gateway（アプライアンス／ゲートウェイ）など、環境に応じた導入形態を選べます。

料金は要問い合わせとなり、導入規模や要件に応じた個別見積もりが前提です。本番環境で事前に検証済みの信頼できるルールが用意されているため、ブロッキングモード（不正な通信を自動で遮断する設定）でも安心して運用を始められます。大規模システムや厳しいセキュリティ要件を持つ環境に適した製品です。

⑧F5 Advanced WAF

「F5 Advanced WAF」は、主に専用ハードウェアを設置して運用するアプライアンス型WAFです。従来の機能に機械学習を用いたデータ分析を取り入れ、DDoS攻撃や悪質なボット通信を自動で防御します。通信の負荷を分散する機能やSSL処理（通信の暗号化）も標準装備した、オールインワンのパッケージが特長です。

料金は導入規模や要件に応じた個別見積もりが基本です。ガイド付きの設定や学習エンジンを備えているため、複雑な要件を持つシステムでも運用設計を進めやすい製品といえます。

WAF製品の料金を比較するときの2ポイント

WAF製品を選ぶ際は、目先の価格だけで判断しないことが大切です。ここでは、自社に合った製品を見つけるために、料金を比較する際のポイント2つについて解説します。

• ①料金体系（月額固定・従量課金・買い切り）を確認する
• ②目に見える料金だけでなく運用コストも確認する

①料金体系（月額固定・従量課金・買い切り）を確認する

WAFの料金体系は、大まかに「月額固定」「従量課金」「買い切り」の3種類に分けられます。それぞれ特徴が異なるため、自社の利用環境に合ったものを選びましょう。

たとえば、従量課金制は小規模な運用で費用を抑えやすい反面、アクセス数が増えると料金も高くなります。一方、月額固定制は毎月のコストを予測しやすく、急な出費を防げるのがメリットです。

また、買い切り型は初期費用が高くなりやすいものの、長期間利用する場合はトータルコストを抑えられます。導入時の金額だけでなく、数年単位の運用を見据えて比較すると判断しやすくなるでしょう。

②目に見える料金だけでなく運用コストも確認する

WAFの導入では、初期費用や月額料金にばかり意識が向きがちです。しかし、導入後に発生する「見えない運用コスト」も計算に入れなければなりません。日々のルール更新や誤検知への対応には、担当者の人件費がかかるためです。料金が安く見える製品でも、運用負担の大きさによっては結果としてトータルコストが高くなるケースがあります。

専門知識を持つエンジニアを自社で確保すると、かえって高くつくケースも少なくありません。そのため、初めから専門家の運用サポートが含まれている製品を選ぶことをおすすめします。表面的な料金だけでなく、運用負担を含めた総コストで判断することが大切です。

料金を抑えて無理なく導入するなら「Cloudbric WAF+」

WAFの選定では、初期費用や月額料金だけでなく、運用負担を含めたトータルコストの比較が重要になります。その点「Cloudbric WAF+」は、管理の手間を抑えながら幅広い攻撃へ対応できるクラウド型WAFです。AIを活用した高精度な攻撃検知をはじめ、次のような特長を備えています。

• WAFやDDoS対策など6つの機能を標準搭載
• AIを活用した高精度な攻撃検知と無料で自動更新されるSSL証明書
• 脅威情報に基づく悪性ボット遮断と専門家による24時間の運用サポート
• 初期費用と月額料金のプラン制で利用規模に合わせて導入しやすい
• DNS設定の変更のみで短期間で運用を開始しやすい

複数のセキュリティ製品を個別に契約すると、管理の負担が増えるだけでなくトータルコストも高くなりがちです。Cloudbric WAF+であれば、必要なセキュリティ機能をまとめて導入できるため、予算と運用効率の両立を目指す企業に適しています。

コストを抑えながら堅実にセキュリティを強化したい場合は、ぜひ導入をご検討ください。

▼Cloudbric WAF+の資料はこちら

▼お問い合わせはこちら

まとめ

Webサイトやシステムをサイバー攻撃から守るため、WAFの導入は不可欠なセキュリティ対策です。しかし、自社の環境に合わない製品を選んでしまうと、運用に手間取ったり無駄なコストが発生したりしかねません。

WAFの製品を比較する際は、初期費用や月額料金といった目に見える金額だけで判断しないことが大切です。日々のセキュリティ設定にかかる運用負担や、専任の担当者を配置する人件費なども計算に含めましょう。

運用負担を減らしつつ高い防御力を維持するためには、「Cloudbric WAF+」のようなサポート一体型の製品が向いています。自社の予算や体制に合ったWAFを選び、安全なWebサイト運用を実現しましょう。

APIセキュリティ対策には、認証・認可、通信の暗号化、脆弱性診断、WAF/WAAPによる入口防御を組み合わせた多層的な対策が必要です。APIは外部システムやアプリとデータをやり取りする「入口」であり、攻撃者に狙われやすい領域です。

その点、ペンタセキュリティのCloudbric WAF+であれば、DDoS攻撃遮断、API保護、ボット対策、悪性IP遮断により、APIを含むWebサービス全体の防御を強化できます。

本記事では、APIセキュリティの基礎、主なリスク、対策を解説します。 

APIセキュリティとは

APIセキュリティとは、APIを経由した不正アクセス、情報漏えい、サービス停止、データ改ざんなどを防ぐための対策です。APIは便利な連携口である一方、認証や権限管理が不十分だと攻撃者の侵入口になります。安全なAPI運用には、設計段階からの対策と運用中の監視が欠かせません。 

APIとは

APIとは、異なるソフトウェアやサービスをつなぎ、機能やデータをやり取りするための仕組みです。たとえば、地図情報の表示やECサイトの決済、SNSアカウントを使ったログインなどに利用されています。

人間社会に例えると、必要な情報や機能を受け渡す「受付窓口」のような役割を担います。一方で、利用者の本人確認やアクセス権限の設定が不十分な場合、第三者に情報を取得されるおそれがあるため、適切なセキュリティ対策が必要です。

APIセキュリティとは

APIセキュリティは、APIの「誰が、何に、どこまでアクセスできるか」を制御する考え方です。具体的には、認証、認可、通信の暗号化、レート制限、ログ監視、WAFによる攻撃遮断などを組み合わせます。APIはWeb画面の裏側で動きますが、攻撃者は直接APIを狙えます。

そのため、API単位の保護が必要です。Cloudbric WAF+は、API保護やDDoS攻撃遮断などを備えたクラウド型WAFサービスです。

Cloudbric WAF+については、以下の記事で詳しく解説しています。あわせてお読みください。

Cloudbric WAF+とは？WAAP対応の6つの機能と選ばれる理由を解説

APIセキュリティが重要な理由

APIセキュリティが重要な理由は、APIが企業システムの接続点として急速に増えているためです。ここではその理由について細かく解説します。

① APIの普及で攻撃対象領域が拡大している

APIが増えると、攻撃者が狙える範囲も広がります。特に注意したいのが、開発中に作られたまま放置されたAPI、古いバージョンのAPI、管理台帳に載っていない「シャドーAPI」です。これらは認証設定やアクセス制御が古いまま残りやすく、攻撃の入口になります。

OWASP API Security Top 10 2023でも、APIは従来のWebアプリより多くのエンドポイントを公開しやすいため、適切な棚卸しと文書管理が重要だと示されています。

② API攻撃による被害と代表的な事例

API攻撃が成功すると、個人情報や顧客データの漏えい、不正ログイン、サービス停止、クラウドコストの増加などが発生します。海外では、T-Mobileが2023年にAPI経由で約3,700万人分の顧客情報に影響する侵害を公表しました。

国内でも、パーソルキャリアの「doda」において、求人広告の販売代理店向けシステムの不備により、採用担当者情報などが閲覧可能となった事例が公表されています。APIやシステム連携の不備は、企業の信用低下に直結する問題です。

サイバー攻撃を受けた企業については、以下の記事で詳しく解説しています。あわせてお読みください。

サイバー攻撃を受けた企業の事例11選【2024～2025年版】

APIに対する主なセキュリティリスク

APIセキュリティでは、OWASP API Security Top 10 2023を参考に、自社のリスクを整理することが有効です。ここではその代表的なリスクについて紹介します。

① 認証・認可の不備（BOLA・BFLA）

APIで特に重要なのが、認証と認可です。認証は「本人確認」、認可は「権限確認」です。BOLAは、URLやリクエスト内のIDを変更するだけで他人のデータにアクセスできてしまう不備です。BFLAは、本来使えない管理者機能などを一般利用者が実行できてしまう不備を指します。これらは正規のリクエストに見えるため、WAFだけでは防ぎにくく、サーバー側で都度権限を確認する設計が必要です。

② 過剰なデータ露出・情報漏えい

APIが必要以上の情報を返す設計も危険です。たとえば、画面には氏名だけを表示していても、APIレスポンスに住所や権限情報が含まれていれば、攻撃者に取得される可能性があります。レスポンスの中身を最小限にすることが重要です。Cloudbric WAF+による入口防御とあわせて、API側では「必要な項目だけ返す」設計を徹底します。 

③ リソースの過剰消費（DoS・DDoS攻撃）

レート制限のないAPIは、大量のリクエストにより、サーバー負荷の増加、サービス停止、クラウド利用料の増大を招きます。APIリクエストはサーバー資源を消費するため、攻撃を受けると運用コストにも影響します。Cloudbric WAF+は、L3/L4およびL7のDDoS攻撃遮断に対応しており、APIを含むサービス停止リスクの低減に役立ちます。

DDos攻撃への対策については、以下の記事で詳しく解説しています。あわせてお読みください。

DDoS攻撃への対策とは？攻撃手法や実際の被害事例も紹介

④ インジェクション攻撃・設定不備

SQLインジェクションやコマンドインジェクションは、APIに不正な入力を送り込み、データベース操作やサーバー上の命令実行を狙う攻撃です。また、詳細すぎるエラーメッセージや古いAPIの放置もリスクです。これらは既知の攻撃パターンとして検知しやすいため、WAF／WAAPの導入が有効です。

Cloudbric WAF+はWeb攻撃遮断に加え、API保護や悪性IP遮断を組み合わせて防御できます。

SQLインジェクションについては、以下の記事で詳しく解説しています。あわせてお読みください。

SQLインジェクションとは? 攻撃の仕組みや被害例、対策方法を解説

APIセキュリティの対策・ベストプラクティス

APIセキュリティ対策は、1つの製品だけで完結しません。認証・認可、暗号化、脆弱性診断、WAF/WAAPを組み合わせる多層防御が基本です。ここでは推奨されるベストプラクティスについて4つ紹介します。

① 認証・認可とアクセス制御を徹底する

まずは、APIにアクセスする利用者やシステムを正しく識別し、必要な権限だけを与えることが重要です。主な対策は以下のとおりです。

• OAuth 2.0やOpenID Connectなど標準的な認証方式を採用する
• APIキーやトークンに有効期限を設定する
• 最小権限の原則に基づき、必要な操作だけを許可する
• サーバー側で毎回、対象データへのアクセス権限を確認する
• 管理者向けAPIと一般利用者向けAPIを明確に分離する

特にBOLAやBFLAは、仕様や業務ロジックに関わるため、設計段階からの確認が欠かせません。

② 通信の暗号化とレスポンスの最小化

API通信では、HTTPS、つまりTLSによる暗号化を必須にするべきです。通信が暗号化されていないと、ネットワーク上でAPIキーやトークン、個人情報を盗聴される恐れがあります。また、APIのレスポンスは必要最小限に抑え、画面表示に使わない情報を返さない設計が重要です。

エラーメッセージにも注意が必要で、内部のテーブル名、サーバー情報、スタックトレースなどを出すと、攻撃者にヒントを与えてしまいます。

③ 脆弱性診断で潜在リスクを可視化する

API固有のリスクは、通常の画面操作だけでは見つけにくい場合があります。特にBOLAのような認可不備は、リクエスト内のIDやパラメータを変更し、権限外の情報にアクセスできるかを確認しなければ発見できません。

そのため、公開前や大きな仕様変更時には、APIに対応した脆弱性診断を行うことが有効です。WAFは入口で攻撃を遮断する対策ですが、設計上の不備をなくすには、診断による可視化と改修が必要です。

Cloudbric脆弱性診断については、以下の記事で詳しく解説しています。あわせてお読みください。

Cloudbric 脆弱性診断とは？6つの診断メニューと選ばれる理由を解説

④ WAF・WAAPを導入して多層防御を実現する

APIの入口対策として有効なのが、WAFやWAAPの導入です。WAFはWebアプリケーションへの不正な通信を検知・遮断する仕組みで、SQLインジェクション、XSS、既知の攻撃パターンへの対策に役立ちます。WAAPは、WAFに加えてAPI保護、DDoS対策、ボット対策などを含む考え方です。

Cloudbric WAF+は、WAF、DDoS攻撃遮断、API保護、ボット対策、悪性IP遮断を備えたクラウド型サービスです。また、導入時・運用時にセキュリティエキスパートによるマネージドセキュリティサービスを提供し、ダッシュボードや自動レポートによる可視化にも対応しています。

さらにAWS環境では、Cloudbric WMSによりAWS WAFのルール作成、ログ分析、新規脆弱性対応、24時間365日のサポートを受けられます。Cloudbric WMSは、OWASP Top 10対応のセキュリティポリシーやMalicious IP Reputationも提供しており、AWS WAFの運用負荷を抑えたい企業に適しています。

WAAPについては、以下の記事で詳しく解説しています。あわせてお読みください。

WAAPとは？次世代Web防御の仕組みとWAFからの進化を徹底解説

APIセキュリティに関するよくある質問

Q：WAFを導入すればAPIは完全に守れますか？

A：WAFはインジェクション、DDoS、悪性ボット、不審なアクセスの遮断に有効ですが、BOLAのような認可不備を完全に防ぐものではありません。認証・認可設計、脆弱性診断、Cloudbric WAF+による入口防御を組み合わせることが重要です。

Q：OWASP API Security Top 10とは何ですか？

A：OWASP API Security Top 10は、APIに特化した重大なセキュリティリスクを整理した一覧です。2023年版では、BOLA、認証不備、リソースの無制限消費、設定不備、API管理不備などが挙げられています。

Q：APIキーやトークンを安全に管理するには？

A：APIキーやトークンは、ソースコードに直接書かず、環境変数や秘密情報管理サービスで保管します。また、有効期限の設定、定期的なローテーション、不要キーの削除、利用状況の監視を行うことが重要です。

まとめ

APIセキュリティ対策では、認証・認可、通信の暗号化、レスポンスの最小化、脆弱性診断、WAF/WAAPによる入口防御を組み合わせる必要があります。APIは便利な連携口である一方、攻撃者にとっても狙いやすい入口です。特にBOLAやBFLAのような認可不備、過剰なデータ露出、リソースの過剰消費、インジェクション攻撃には注意が必要です。

その点、Cloudbric WAF+は、WAFに加えてDDoS攻撃遮断、API保護、ボット対策、悪性IP遮断を備えており、APIを含むWebサービス全体の入口防御を強化できます。AWS環境であれば、Cloudbric WMSによってAWS WAFの導入・運用負荷を抑えながら、高度な攻撃検知やログ分析、専門家によるサポートを活用できます。APIを安全に活用するには、開発時の設計対策と、Cloudbricによる運用中の防御を両立させることが重要です。

▼お問い合わせはこちら

▼Cloudbric WAF+の資料はこちら

WAF導入後に「正常な通信が止まる」「アラート対応が追いつかない」と悩む担当者は多いものです。その原因の多くは「過検知（過剰検知）」または「誤検知」にあり、適切なチューニングによって改善できる傾向にあります。これらの課題を効率よく解決するには、AI検知機能とマネージドサービスを備えたペンタセキュリティの「Cloudbric WAF+」の活用が有効です。

本記事では、過検知・誤検知の定義から原因、具体的なチューニング方法までを順に解説します。

WAFについては、以下の記事で詳しく解説しています。あわせてお読みください。

「セキュリティ対策に有効なWAFとは？仕組みや種類、おすすめ製品を紹介」

過検知・誤検知とは？

ここでは過検知と誤検知の違いについて紹介します。

過検知（False Positive）とは

過検知（False Positive）とは、正常な通信をWAFが攻撃と誤認してブロックする状態で、「フォルスポジティブ」や「過剰検知」「誤遮断」とも呼ばれます。

WAFのシグネチャーが正規リクエストの特定パターンと合致した際に発生しやすく、フォームへの特殊文字入力や大容量ファイルのアップロードなどが引き金になる傾向にあります。多発するとユーザーがサービスを正常に利用できなくなり、機会損失や顧客離れにつながる恐れがあります。

誤検知（False Negative）とは

誤検知（False Negative）とは、攻撃通信を正常と誤認して通過させてしまう状態で、「フォルスネガティブ」や「検知漏れ」とも呼ばれます。

未知の攻撃手法や、エンコード・分割送信といった回避テクニックを使った攻撃に対して発生しやすい傾向にあります。誤検知は気づかないうちに攻撃を通過させてしまうため、情報漏えいや不正アクセスといった直接的な被害につながる点で、より深刻な問題と言えます。

過検知と誤検知の違い

過検知と誤検知は対になる概念であり、WAFのセキュリティ強度を上げると過検知が増え、緩めると誤検知が増えるというトレードオフの関係にあります。これを最小化するために行うのが「チューニング」であり、WAF運用の核心となる作業です。

両者の違いを下表にまとめます。

WAFのシグネチャーの仕組みについては、以下の記事で詳しく解説しています。あわせてお読みください。

WAFのシグネチャーとは？仕組みや種類、設定・更新方法をわかりやすく解説

WAFで過検知・誤検知が発生する主な原因

WAFで過検知・誤検知が発生する原因には、以下の3つがあります。

原因①シグネチャー設定が厳格すぎる

ブラックリスト方式のWAFでは、広範な攻撃をカバーするために定義（シグネチャー）を厳しく設定しがちです。その結果、たとえばSQLインジェクション対策のルールが、通常のフォーム入力に含まれる記号を誤って捕捉してしまいます。そのため、自社サービスの通信仕様に即したカスタマイズが不可欠です。

原因②自社アプリの通信パターンをWAFが把握できていない

WAF導入直後やWebアプリのアップデート後は、新しい機能やパラメータをWAFが「未知の通信」として警戒し、過検知を引き起こします。本番環境に適用する前に、十分な学習期間や段階的な運用移行が必要です。

原因③マネージドルールの更新が意図せず影響する

クラウド型WAFのマネージドルールは自動更新で運用を簡略化しますが、予告なくルールが追加・変更されるため、昨日まで通過していたリクエストが突如ブロックされる場合があります。逆に新種攻撃への対応が遅れ、誤検知を招くリスクもあります。

過検知・誤検知がもたらすデメリット

過検知・誤検知を放置するとさまざまな悪影響が生じます。ここでは主な3つのデメリットを解説します。

①正規ユーザーの業務・取引機会が失われる

過検知によって正常なリクエストがブロックされると、ユーザーがWebサービスを利用できなくなり、業務停止や購入・申込みの失敗につながるケースが見られます。

特にECサイトやBtoBサービスでは、過検知が売上や契約機会の損失に直結する傾向にあります。さらに、ユーザーからの問い合わせ対応や復旧作業も必要となるため、カスタマーサポートへの負荷も増大し、企業の信頼性にも影響しかねません。

②重要な攻撃アラートが埋もれる

過検知が多発すると大量の誤アラートが発生し、SOC担当者がすべて確認できなくなる「アラート疲れ」に陥るケースがあります。

問題は、誤アラートの中に本物の攻撃通知が埋もれ、実際の侵害を見逃す二次的なリスクが生まれる点です。セキュリティアラートの大半を過検知・誤検知が占めるケースも多く、運用上の構造的な課題となっています。検知の質を高めることが、実際の脅威への対応力強化にもつながります。

③担当者の運用工数が大幅に増える

過検知が発生するたびに、担当者はログを確認してブロック内容を精査し、必要に応じてホワイトリストを追加する対応が求められます。

この作業は定型化されにくく専門知識も必要なため、属人化しやすい傾向にあります。人手不足が深刻な情シス部門では、過検知対応に追われて本来の業務が圧迫される悪循環も生じやすい点が課題です。継続的な運用を見据えるなら、運用支援機能を備えたWAFの選定が有効です。

WAFの過検知・誤検知を減らすチューニング方法

過検知・誤検知を減らすには、以下の4つのチューニング方法が有効です。

①まず検知モードで試験運用する

WAF導入時や設定変更時には、通信を遮断せず検知ログのみを取得する「検知モード」で試験運用することが推奨されます。実際の通信を1〜2週間程度観察し、過検知が発生する箇所を特定してから遮断モードへ移行することで、本番環境への影響を最小化できます。

たとえばCloudbric WAF+の場合、DNS切り替え後に標準で約1カ月間の検知モードで運用し、エキスパートが分析した検知ログをもとにポリシーを作成してから遮断モードへ切り替える仕組みになっています。

②ログを分析して過検知の発生パターンを特定する

検知モード中に収集したWAFログを分析し、どのURLへのアクセスがどのシグネチャーに引っかかっているのかを特定することが次のステップです。ログには送信元IP・リクエスト内容・適用ルールなどが記録されており、過検知の根本原因を絞り込む手がかりとなります。

こうしたログ分析の工数を抑えるなら、Cloudbric WAF+のように直感的なダッシュボードと検知ログメニューを備え、過去3カ月分のサマリーレポートも自動作成されるWAFを選ぶことで、担当者の負担を大幅に削減できます。

③ホワイトリスト・例外設定で対象を絞り込む

過検知と確認された通信には、送信元IP・URL・パラメータなどを指定した「ホワイトリスト（例外ルール）」を設定し、WAFの検査対象から除外する方法が有効です。ただし例外設定の範囲が広すぎると攻撃を通過させるセキュリティホールになるため、具体的かつ限定的に設定することが原則です。

自社での対応が難しい場合は、Cloudbric WAF+のようにマネージドサービスの一環としてエキスパートが誤検知対応を行うWAFを活用すれば、担当者がホワイトリストを設定する手間を省けます。

④AI検知で運用負荷を軽減する

シグネチャー照合だけに頼るWAFでは、未知の攻撃手法や通信パターンの変化への対応に限界があるため、AIを活用した異常検知機能を組み合わせることが過検知・誤検知の低減に有効です。AIが正常な通信パターンを継続的に学習することで、ルールに定義されていない攻撃も検知でき、正常通信の誤ブロックも抑えられる傾向にあります。

Cloudbric WAF+も論理演算検知エンジンに加え、Webトラフィック特性を学習するAIエンジンを搭載しており、過検知・誤検知の低減に貢献します。

Cloudbric WAF+については、以下の記事で詳しく解説しています。あわせてお読みください。

「Cloudbric WAF+とは？WAAP対応の6つの機能と選ばれる理由を解説」

よくある質問（Q&A）

ここではよくある質問をまとめました。

Q1.過検知と誤検知はどちらが問題ですか？

過検知は業務停止など目に見える影響が出るため担当者が気づきやすい一方、誤検知は気づかないうちに攻撃が通過するため、直接的な被害リスクが高い傾向にあります。両者はともに低減することが目標であり、ルール設定の最適化によって両方を最小化し続けることが求められます。

Q2.WAFの過検知はどうすれば減らせますか？

検知モードで試験運用してログを収集→過検知パターンを特定→例外設定（ホワイトリスト）を絞り込んで追加、という手順が基本的な流れです。自社でのチューニングが難しい場合は、ベンダーへの運用委託やAI検知を備えたクラウド型WAFへの移行も有効な選択肢となります。

Q3.Cloudbric WAF+は過検知・誤検知にどう対処しますか？

Cloudbric WAF+はAIによるリアルタイム学習機能を備えており、検知精度が継続的に最適化されます。シグネチャーの自動更新や誤検知対応もベンダーに依頼できるため、担当者の運用負担を抑えながら検知漏れリスクも低減できます。詳細はCloudbric公式サイトからご確認ください。  

まとめ

WAFの過検知は正常な通信を誤ってブロックする問題、誤検知は攻撃を見逃す問題であり、両者はトレードオフの関係にあります。適切なチューニング（検知モード→ログ分析→例外設定）によって両者のバランスを最適化することが、WAF運用の核心です。

ただし、継続的なチューニングには専門知識と工数が必要なため、AI検知とマネージドサービスを備えたWAFを選ぶこともひとつの有効な解決策です。「Cloudbric WAF+」は、AIによる高精度検知で過検知・誤検知を最小化するクラウド型WAFです。

自社のセキュリティ強化をお考えの方は、ぜひお気軽にお問い合わせください。

▼お問い合わせはこちら

▼Cloudbric WAF+の資料請求

Webサイトへのサイバー攻撃は、WAF（Web Application Firewall）があれば防げたケースが数多く存在します。特にSQLインジェクション・サイト改ざん・パスワードリスト攻撃は、WAFが対応する代表的な脅威です。

本記事では、国内企業の実際の被害事例をもとに、各攻撃の手口とWAFによる防御効果を解説します。自社のリスクを把握し、適切な対策を検討するための参考にしてください。

WAFで防げるサイバー攻撃とは

Webアプリケーションへの攻撃は多様化していますが、WAFが有効に機能する攻撃と、別の対策との組み合わせが必要な攻撃があります。攻撃ごとの防御効果を把握することが、適切なセキュリティ対策の第一歩です。

以下の表に、代表的な攻撃種別とWAFによる防御可否をまとめました。

SQLインジェクションやXSSなどのアプリケーション層の攻撃については、WAFが不正なリクエストをリアルタイムで検知・遮断することで高い防御効果を発揮します。一方、パスワードリスト攻撃は「正規のID・パスワードを使ったログイン」であるため、WAF単体での判別には限界があり、多要素認証（MFA）やボット対策との併用が推奨されます。

ペンタセキュリティのCloudbric WAF+は、WAF機能に加えてボット対策・DDoS防御・API保護を統合したWAAP（Web Application and API Protection）型クラウドWAFとして、こうした複合的な脅威に備えることができます。

WAFについては、以下の記事で詳しく解説しています。あわせてお読みください。

「セキュリティ対策に有効なWAFとは？仕組みや種類、おすすめ製品を紹介」

SQLインジェクション攻撃による情報漏えい事例

SQLインジェクションとは、入力フォームやURLなどに不正な命令文を送り込み、データベースを不正に操作する攻撃です。ここでは実際にあった攻撃事例を２つ紹介します。

事例① 積水ハウス（2024年5月）

2024年5月、積水ハウス株式会社の会員制サービス「積水ハウス Net オーナーズクラブ」において、運用終了済みのページに残存していた脆弱性を突いたSQLインジェクション攻撃が発生しました。この攻撃により、メールアドレス、ログインID、パスワードの漏えいが確認され、最大46万人超の顧客情報についても漏えいの可能性が否定できない状況となっています。

使われなくなったページの脆弱性が攻撃の入り口となった事例です。WAFが導入され、適切に運用されていれば、不正なSQL文を含むリクエストを検知・遮断できた可能性があります。

事例② 学悠出版株式会社（2025年6月）

愛知全県模試を運営する学悠出版株式会社は、2025年6月30日にSQLインジェクション攻撃による不正アクセスを受け、塾関係者や模試受験者を含む最大約33万件の個人情報（氏名・住所・連絡先等）が漏えいした可能性があると発表しました。不正アクセスは2025年4月下旬に検出されましたが、対象データの一部は暗号化されており、個人の特定には別データベースとの照合が必要な状況です。

公表時点で情報の不正利用は確認されていませんが、教育機関は膨大な個人情報を保有する一方で、セキュリティリソースが不足しがちな傾向にあります。WAFの導入によって不正なSQLリクエストを遮断する仕組みを整えておくことが、こうした被害を未然に防ぐ鍵となったと考えられます。

サイト改ざんによる被害事例

Webサイトに悪意あるスクリプトを埋め込み、利用者のブラウザ上で不正な処理を実行させる攻撃です。ここでは実際にあった攻撃事例を２つ紹介します。

事例③ 全国漁業協同組合連合会「JFおさかなマルシェ ギョギョいち」（2024年8月）

全国漁業協同組合連合会（JF全漁連）が運営する通販サイト「JFおさかなマルシェ ギョギョいち」では、脆弱性を悪用した不正アクセスによりペイメントアプリケーションが改ざんされ、顧客のクレジットカード情報が攻撃者に継続的に送信される状態になっていました。

2024年5月14日に警視庁からの連絡で発覚しサイトは閉鎖されましたが、2021年4月から2024年5月の間に2万件超の個人情報が流出した可能性があります。このような脆弱性を突いた不正アクセスは、WAFが導入・適切に運用されていれば、不正なリクエストの段階で検知・遮断できた可能性が高いです。

事例④ タリーズコーヒージャパン（2024年10月）

タリーズコーヒージャパンのオンラインストアでは、システムの一部の脆弱性を突いた不正アクセスにより、ペイメントアプリケーションが改ざんされました。公式発表では、2020年10月から2024年5月の間に個人情報9万件超が漏えいした可能性があるとされています。

Webアプリケーションの脆弱性を悪用した不正アクセスによる改ざんは、WAFが導入されていれば不審なリクエストの検知・遮断により被害を防げた可能性があります。

パスワードリスト攻撃による不正ログイン事例

パスワードリスト攻撃とは、他サービスから流出したID・パスワードを使い、別のWebサービスへログインを試みる攻撃です。ここでは実際にあった攻撃事例を紹介します。

事例⑤ エン・ジャパン「エン転職」（2023年3月）

エン・ジャパンが運営する「エン転職」では、2023年3月に外部から不正に取得されたID・パスワードを利用するパスワードリスト攻撃（リスト型アカウントハッキング）が発生しました。発覚後は送信元IPアドレスからの通信をブロックし、全ユーザーのパスワードをリセットしましたが、登録されたユーザーの一部Web履歴書について、職歴や連絡先などの情報が閲覧された可能性があると公表されています。

パスワードリスト攻撃は正規ログインと見分けにくいため、多要素認証（MFA）の導入が根本対策となります。WAAP型のWAFは、ボット検知・レートリミット機能を内包していることが多く、認証強化と組み合わせることで多層防御を実現できるものがあります。

その他のサイバー攻撃事例については、以下の記事で詳しく解説しています。あわせてお読みください。

「【2025年最新】国内外のサイバー攻撃事例10選！対策方法も紹介」

WAFで防ぐための具体的な対策

上記の事例に共通するのは、Webアプリケーション層への攻撃が起点になっているという点です。自社のWebサービスを守るために、以下の対策を組み合わせることが推奨されます。

• WAF（Web Application Firewall）の導入：SQLインジェクション・XSSなどアプリケーション層の攻撃をリアルタイムで検知・遮断する
• 多要素認証（MFA）の導入：パスワードリスト攻撃による不正ログインを防止する
• ログイン試行回数の制限：自動化ツールによる大量ログイン試行を抑制する
• 定期的な脆弱性診断の実施：XSSやSQLインジェクションの脆弱性を事前に検出する
• ソフトウェア・CMSの最新化：既知の脆弱性を放置せず、パッチを迅速に適用する

Cloudbric WAF+は、WAF機能に加えてDDoS対策・ボット対策・API保護を統合したWAAP型クラウドWAFです。専門知識がなくてもマネージドサービスとして導入・運用が可能で、中小企業から大企業まで幅広い規模の組織で活用されています。

Cloudbric WAF+については、以下の記事で詳しく解説しています。あわせてお読みください。

「Cloudbric WAF+とは？WAAP対応の6つの機能と選ばれる理由を解説」

よくある質問（Q&A）

ここではよくある質問を紹介します。

Q1. WAFで防げる攻撃と防げない攻撃の違いは？

WAFはSQLインジェクション・XSS・OSコマンドインジェクションなどのアプリケーション層の攻撃を得意とし、不正なリクエストをリアルタイムで遮断します。一方、パスワードリスト攻撃は正規のID・パスワードを使ったログインのため、WAF単体での判別には限界があります。レートリミット・多要素認証・ボット対策との併用が推奨されます。

Q2. 小規模な企業でもWAFは必要ですか？

はい、必要です。攻撃者は企業規模を問わず、自動化ツールで脆弱なサイトを標的にする傾向にあります。Cloudbric WAF+は月額2万8,000円〜から導入でき、専任のセキュリティ担当者がいなくてもマネージドサービスとして運用が可能です。中小企業でも導入しやすい価格帯と運用体制が整っています。

Q3. WAFを導入すれば情報漏えいはゼロになりますか？

WAFは多層防御の重要な一部ですが、単体で完全な防御を保証するものではありません。定期的な脆弱性診断・多要素認証の導入・ログ監視といった対策との組み合わせにより、リスクを大幅に低減できます。セキュリティ対策は導入後の継続的な運用と改善が重要です。

まとめ

今回紹介した事例の多くは、WAFが適切に導入・運用されていれば被害を防げた、または軽減できた可能性があります。SQLインジェクション・XSSなどのアプリケーション層の攻撃はWAFで対応でき、パスワードリスト攻撃には多要素認証やボット対策との併用が有効です。

これらの脅威からWebアプリケーションを守るには、Cloudbric WAF+の導入が有効です。WAAP型クラウドWAFとしてWAF・ボット対策・DDoS防御・API保護を統合しており、AIによる高精度な脅威検知とマネージド運用で継続的にセキュリティを強化できます。

自社のセキュリティ強化をお考えの方は、お気軽にペンタセキュリティまでお問い合わせください。

▼お問い合わせはこちら

▼Cloudbric WAF+の資料請求

近年、Webアプリケーションを狙ったサイバー攻撃は増加の一途をたどっており、企業がWebサービスを安全に運用するためのセキュリティ対策が急務となっています。そのなかで注目を集めているのが「WAF（Web Application Firewall）」の導入です。

本記事では、WAF導入のメリット・デメリット・費用・注意点をわかりやすく整理します。「自社にWAFは本当に必要か」「費用対効果はどうか」を検討中の情報システム担当者の方は、ぜひ参考にしてください。

WAFとは

WAFとは「Web Application Firewall（ウェブ・アプリケーション・ファイアウォール）」の略称で、Webアプリケーションへの通信をリアルタイムに検査し、不正なリクエストを検知・遮断するセキュリティ対策です。

クライアント（ブラウザ等）とWebサーバーの間に位置し、HTTP/HTTPS通信の内容を解析することで、通常のアクセスに見せかけた攻撃を識別・遮断します。Webアプリケーション層（L7）に特化した防御を担う点が、WAFの最大の特徴です。

WAFについては、以下の記事で詳しく解説しています。あわせてお読みください。

セキュリティ対策に有効なWAFとは？仕組みや種類、おすすめ製品を紹介

ファイアウォール・IDS/IPSとの違い

WAFと混同されやすい製品として、従来のファイアウォールとIDS/IPSが挙げられます。両者の違いを整理すると、WAFの必要性がより明確になります。

従来のファイアウォールは、送受信先のIPアドレスやポート番号をもとに通信を制御します。Webサービスのように外部へ公開されたサーバーは、HTTP通信を原則許可する必要があるため、ファイアウォールだけではWebアプリケーション層の攻撃を防ぐことができません。

IDS/IPSはネットワーク全体を対象として通信を監視・防御しますが、こちらもWebアプリケーション固有の攻撃への対応は限定的です。WAFはこれら既存の対策では守りきれないWebアプリケーション層の脅威に、特化した防御を提供します。

WAF導入が必要な理由

IPA（独立行政法人情報処理推進機構）が2026年1月に発表した「情報セキュリティ10大脅威 2026」の組織向けランキングでは、1位「ランサム攻撃による被害」、2位「サプライチェーンや委託先を狙った攻撃」、4位「システムの脆弱性を悪用した攻撃」、9位「DDoS攻撃」がランクインしています。これらのうち複数は、WAFによる対策が有効な脅威です。

ファイアウォールやIDS/IPSだけでは守りきれないWebアプリケーション層への攻撃が増加している現在、WAFはWebサービスを運営する企業にとって、多層防御の一角を担う不可欠なセキュリティ対策となっています。

WAFで防げる主な攻撃

WAFが検知・遮断の対象とする代表的な攻撃は以下のとおりです。

• SQLインジェクション（データベースへの不正な命令文の挿入）
• クロスサイトスクリプティング（XSS）（悪意あるスクリプトをWebページに埋め込む攻撃）
• OSコマンドインジェクション（OSへの不正なコマンドを実行させる攻撃）
• クロスサイトリクエストフォージェリ（CSRF）（正規ユーザーになりすまして不正な操作を行う攻撃）
• パス名パラメーターの未チェック／ディレクトリ・トラバーサル（サーバー内の非公開ファイルへの不正アクセス）

一方、認証情報の窃取・内部不正・フィッシングメールなど、WAFの守備範囲外の脅威も存在します。WAFを過信せず、多層防御の一環として位置づけることが重要である点は、後のデメリット・注意点のセクションで改めて解説します。

WAFの種類と選び方

WAFには大きく3つの種類があり、自社の状況に合ったものを選ぶことが導入成功の鍵となります。

クラウド型WAF

クラウド上のサービスとして提供されるWAFです。DNSの設定変更のみで導入が完了するケースが多く、専用ハードウェアの設置やサーバーへのインストール作業が不要です。

シグネチャーの更新や運用管理はベンダー側が担うため、社内に専任のセキュリティエンジニアがいない企業でも導入・運用がしやすい傾向にあります。初期費用が低く月額課金制が一般的なため、導入ハードルが低い点も特徴です。

アプライアンス型WAF

専用ハードウェアをWebサーバーの手前に設置する形態です。高い処理性能とカスタマイズ性が特徴で、大規模なWebサービスや独自要件が多い環境に向いています。

一方で、初期費用・保守費用が高く、適切に運用できるエンジニアの確保に加え、場合によってはネットワーク設計の見直しが必要なこともあります。

ソフトウェア型WAF

自社サーバーにインストールして利用するタイプです。アプライアンス型と比較して初期費用を抑えやすく、自社環境に合わせたカスタマイズがしやすい点はメリットです。

一方、初期設定・運用・メンテナンスを自社で対応できるエンジニアが必要なため、導入前に社内のエンジニアリソースを確認しておくことが重要となります。

WAFの選び方については、以下の記事で詳しく解説しています。あわせてお読みください。

【2025年版】WAFのおすすめ4製品を比較！機能や価格をわかりやすく紹介

WAF導入のメリット

WAFを導入することで得られる主なメリットは3つです。

サイバー攻撃をリアルタイムで防御できる

WAFはWebアプリケーションへの通信をリアルタイムで検査するため、SQLインジェクションやXSSなどの攻撃を、被害が発生する前の通信段階で遮断できます。攻撃を受けてから事後対応するのではなく、攻撃そのものを未然に防げる点が大きなメリットです。

また、シグネチャー（攻撃パターン）の継続的な更新によって、新たな脅威にも対応できる体制を維持できます。

セキュリティリスクを可視化できる

WAFはWebアプリケーションへのすべての通信を記録するため、「どのような攻撃がいつ・どこから来ているか」をログとして把握できます。攻撃の傾向を定量的に把握できることは、自社のリスク状況を正確に理解するうえで重要です。

情報システム担当者が経営層へセキュリティ投資の必要性を説明する際の根拠データとしても活用でき、社内での合意形成をスムーズに進めやすくなります。

企業の信頼・ブランド価値を守れる

情報漏えいや不正アクセスが発生した場合、顧客・取引先からの信頼失墜や損害賠償リスクが生じます。IPA「情報セキュリティ10大脅威 2026」でも、機密情報を狙った標的型攻撃や内部不正による情報漏えいが上位にランクインしており、Webアプリケーションの保護はブランド価値を守ることに直結します。

WAFの導入は攻撃を防ぐ「防御」であると同時に、「セキュリティへの取り組みを対外的に示す」姿勢としても機能します。

WAF導入のデメリット・注意点

WAFは有効なセキュリティ対策ですが、過信は禁物です。主な注意点は3つあります。

WAFだけでは防げない攻撃もある

WAFが守備対象とするのはWebアプリケーション層への攻撃であり、すべての脅威をカバーするわけではありません。たとえば、フィッシングメールによる認証情報の窃取、内部不正、DDoS攻撃の一部（ネットワーク層攻撃）などはWAFの守備範囲外となるケースがあります。

WAFはあくまで多層防御の一環として位置づけ、ファイアウォール・IDS/IPS・エンドポイント対策などと組み合わせて運用することが重要です。

誤検知と運用チューニングにコストがかかる

WAFには、正常な通信を誤って攻撃と判断し遮断してしまう「誤検知」が発生するケースがあります。誤検知が多発すると、正規ユーザーのアクセスを妨げるため、利便性に影響が出る傾向にあります。

適切な検知精度を維持するためには、定期的なシグネチャーの更新とチューニングが必要です。これらの作業には専門知識と継続的な運用リソースが求められます。なお、クラウド型WAFの場合、シグネチャーの更新やチューニングをベンダー側が担うサービスもあり、運用負荷を軽減できます。

導入形態によってはネットワーク構成の変更が必要

アプライアンス型やソフトウェア型のWAFは、既存のネットワーク構成に変更が生じる場合があります。専門的な知識を持つエンジニアによる設計・導入作業が必要となるため、導入工数とコストがかさむケースも見られます。

一方でクラウド型WAFは、DNSの設定変更のみで導入が完了するケースが多く、エンジニアリソースが限られている企業でも比較的スムーズに導入できます。

クラウド型のCloudbric WAF+については、以下の記事で詳しく解説しています。あわせてお読みください。

Cloudbric WAF+とは？WAAP対応の6つの機能と選ばれる理由を解説

まとめ

IPA「情報セキュリティ10大脅威 2026」が示すとおり、Webアプリケーションを狙うサイバー攻撃は年々多様化・高度化しています。WAFは、SQLインジェクションやXSSをはじめとするWebアプリケーション層の脅威に対応する、多層防御の重要な一手です。

一方、誤検知への対応や継続的な運用チューニング、ネットワーク構成の変更といった課題も存在します。これらのデメリットを解消する手段として、マネージドサービスが付帯したクラウド型WAFの導入が有効です。

「Cloudbric WAF+」は、DNSの設定変更のみで導入が完了するクラウド型WAFです。WAF機能に加え、DDoS攻撃遮断・ボット対策・API保護・Malicious IP遮断・SSL証明書の自動発行を統合した次世代のセキュリティサービスで、セキュリティエキスパートによる24時間365日のマネージドサービスが付帯しているため、社内に専任担当者がいない企業でも安心して運用いただけます。

自社のWebアプリケーションのセキュリティ強化をお考えの方は、ぜひお気軽にお問い合わせください。

2026年3月、JavaScriptの定番ライブラリ「axios」の公式配布経路が攻撃者に悪用され、マルウェアを含む不正バージョンが約39分間にわたって公開される事態が発生しました。短時間の公開ながら、多数の開発環境に影響が及んだ可能性があります。

本記事では、攻撃の概要・仕組みから影響の確認方法、感染時の対処、再発防止策まで順を追って解説します。

axiosのサプライチェーン攻撃とは

axiosは世界中の開発現場で利用されているJavaScriptの定番ライブラリです。2026年3月末、その公式配布経路を悪用したサプライチェーン攻撃が明らかになりました。攻撃の概要と仕組みを以下で解説します。

攻撃の概要と経緯

「axios（アクシオス）」とは、WebサービスやアプリがインターネットでデータをやりとりするためのJavaScriptライブラリです。2026年3月31日、このaxiosを配布しているnpm（Node Package Manager）を通じて、マルウェアを含む不正なバージョンが公開されました。

攻撃者はaxiosの管理者（メンテナー）のアカウントを乗っ取り、正規のソフトウェアに見せかけた悪性バージョン（1.14.1および0.30.4）を公開したと見られています。不正バージョンが公開されていた時間はわずか約39分間でしたが、その間に多数の環境に影響が及んだ可能性があります。

攻撃の仕組み・マルウェアの動作

今回の攻撃は、二段階の仕掛けで成立していました。

攻撃者はあらかじめ「plain-crypto-js」という悪意あるパッケージをnpmに登録しておき、悪性版axiosの依存関係（動作に必要な関連ソフトウェアのリスト）にそのパッケージを追加していました。そのため、開発者がnpm installを実行すると、インストール完了と同時にマルウェアが自動起動する仕組みになっていました。

起動したマルウェアはOSの種類（Windows・macOS・Linux）を自動判別し、それぞれに対応したRAT（遠隔操作型トロイの木馬）を取得・実行します。さらに実行後は自身の痕跡を消去するため、後から調査しても感染に気づきにくい点が特に問題視されています。

トロイの木馬ウイルスについては、以下の記事で詳しく解説しています。あわせてお読みください。

トロイの木馬ウイルスとは？特徴・症状・感染時の対処法をわかりやすく解説

axiosが狙われた原因とは

今回の攻撃の直接的な原因は、axiosの管理者のnpmアカウントが乗っ取られたことにあります。攻撃者は盗んだ認証情報を使って管理者になりすまし、正規の配布経路（npm）からマルウェア入りのaxiosを公開しました。利用者側からは通常の更新と見分けがつかないため、感染に気づくことが非常に困難な状況でした。

また、同時期にTrivyやLiteLLMなど複数のOSSも連続して侵害されており、組織的な攻撃とみられています。Googleのレポートでは、北朝鮮系サイバー攻撃グループ「UNC1069」との関連が指摘されています。

影響範囲および確認について

侵害されたバージョンは2つに限定されていますが、axiosを直接インストールしていない環境でも間接的に影響を受けるケースがあります。影響を受けるバージョンや環境の特徴、および確認方法を以下で紹介します。

影響を受けるバージョン・環境

今回侵害されたのは「axios@1.14.1」および「axios@0.30.4」の2バージョンです。「axios@1.14.0」（1.x系）および「axios@0.30.3」（0.x系）は対象外となっています。

注意が必要なのは、axiosを直接使用していない環境でも影響を受ける可能性がある点です。自社が導入している別のソフトウェアが内部でaxiosに依存していた場合（間接依存）、同様のリスクが生じます。

また、バージョンを固定せず「常に最新版を自動取得する」設定にしていた環境では、気づかないうちに悪性バージョンをインストールしていたケースも報告されています。

影響を受けているか確認する方法

まず、package-lock.jsonやyarn.lock（インストールされたバージョンを記録する管理ファイル）を確認し、axiosのバージョンが「1.14.1」または「0.30.4」になっていないかをチェックしてください。特に、日本時間の2026年3月31日 午前9時21分〜午後12時15分の間にnpm installを実行していた環境は優先的に確認が必要です。あわせて、「plain-crypto-js」というパッケージがインストールされていないかも確認してください。

ただし、マルウェアは実行後に痕跡を消去するため、インストール済みファイルの確認だけでは検知できないケースがあります。ネットワークログ（通信記録）に見慣れない外部サーバーへの接続記録がないかどうかをあわせて確認することを推奨します。

影響があった場合の対処

悪性バージョンをインストールした環境は、「すでに侵害されている」前提で対応することが重要です。

まず、影響を受けた端末をネットワーク（社内LANやインターネット）から即時切り離してください。その後、axiosを安全なバージョンに戻し、インストール済みの不正ファイルを削除して再インストールします。

次に、GitHubトークン・APIキー・クラウドサービス（AWS・GCPなど）の認証情報・データベースのパスワードなど、該当端末に保存されていたすべての認証情報を新しいものに変更（ローテーション）してください。CI/CD環境でaxiosを参照していた場合は、そこで使用しているシークレット（秘密鍵やトークン類）も対象に含めます。

感染が疑われる場合、端末をクリーンな状態から再セットアップする方が確実なケースも報告されています。被害の拡大を防ぐためにも、早期の対処が求められます。

実施すべき対策について

今回の攻撃を踏まえ、同様の被害を防ぐための対策を5つの観点から解説します。入口対策・出口対策・アカウント管理など複数の面から多層的に取り組むことが重要です。

ロックファイルの活用

まず取り組みやすい対策として、ロックファイルの活用が挙げられます。package-lock.jsonなどのロックファイルを必ず使用することで、意図しないバージョンアップを防ぐことができます。

あわせて、npmのmin-release-age設定（クールダウン機能）の活用も有効です。これは新しく公開されたパッケージをすぐにインストールしないようにする設定で、推奨は7日程度とされています。

公開直後の悪性パッケージを自動的に取り込まないようにすることで、セキュリティコミュニティが悪意あるコードを発見・報告するための時間的な余裕を確保できます。

CI/CD環境の設定を見直す

CI/CD環境（ソフトウェアのビルド・テスト・リリースを自動化する仕組み）では、最小権限の原則を徹底し、必要最小限の認証情報のみを設定することが基本です。

あわせてSCAツール（Software Composition Analysis）を導入し、依存パッケージのリスクを継続的に監視することを推奨します。SCAツールとは、使用しているソフトウェアの構成部品を分析し、既知の脆弱性がないかチェックするツールです。

今回のような複数のOSSへの連続攻撃は今後も増加傾向にあると見られており、サプライチェーン全体でのセキュリティ強化が求められます。

多要素認証（MFA）の導入

今回の攻撃の根本原因は、管理者の認証情報が盗まれたことにあります。この再発を防ぐうえで最も効果的な対策が、多要素認証（MFA：Multi-Factor Authentication）の導入です。

MFAとは、パスワードに加えてスマートフォンへの通知や認証アプリのコードなど、複数の方法で本人確認を行う仕組みです。npmなどの開発者アカウントにMFAを設定することで、パスワードが盗まれた場合でも不正ログインを防ぐことができます。

開発者個人のアカウントだけでなく、CI/CDシステムやサービス連携用のアカウントにも同様の対策を講じることが重要です。

脆弱性診断・SBOM等の利用

SBOM（Software Bill of Materials：ソフトウェア部品表）とは、自社のシステムがどのソフトウェアやライブラリを使用しているかを一覧化したものです。SBOMを整備しておくことで、今回のaxiosのように広く使われているライブラリが攻撃を受けた際に、自社への影響を迅速に把握できます。

脆弱性診断と組み合わせることで、知らないうちに混入した危険なソフトウェアの早期発見にもつながります。SBOMの作成・管理にはSCAツールを活用することで、手作業の負担を大幅に削減できます。

脆弱性については、以下の記事で詳しく解説しています。あわせてお読みください。

脆弱性とは？被害例や攻撃手法、セキュリティ対策方法を紹介

WAFの活用

今回のマルウェアは感染後、攻撃者のC2サーバー（攻撃者がウイルスに指示を送るための外部サーバー）へ60秒ごとに通信を送り続ける動作が確認されています。

WAF（Web Application Firewall）を導入することで、こうした不審な外部通信や不正リクエストをリアルタイムで検知・遮断できます。パッケージ管理やバージョン固定といった「入口対策」と、WAFによる不審通信の遮断という「出口対策」を組み合わせた多層防御が、サプライチェーン攻撃への現実的な対応策となります。

Cloudbric WAF+については、以下の記事で詳しく解説しています。あわせてお読みください。

Cloudbric WAF+とは？WAAP対応の6つの機能と選ばれる理由を解説

まとめ

今回のaxiosサプライチェーン攻撃は、正規の配布経路そのものが悪用された点が最大の特徴です。約39分という短時間で実行された攻撃は、「インストール後に確認する」という従来型の対策だけでは対応が困難であることを示しています。ロックファイルの活用・MFAの導入・SBOMの整備を組み合わせた多層的な対策に取り組むことが、今後のリスク低減につながります。

出口対策として、WAFの導入も有効な手段のひとつです。 「Cloudbric WAF+」は、サプライチェーン攻撃によるマルウェア感染後のC2通信をはじめ、Webアプリケーションへの多様な脅威をリアルタイムで検知・遮断するクラウド型WAFです。

ソフトウェアサプライチェーンのリスク対策をご検討の際は、ぜひお気軽にお問い合わせください。