Cloudflare WAF導入時の注意点7選｜フォーム・ログイン・APIへの影響も解説
「Webサイトのセキュリティを強化するために、Cloudflare WAFを導入したい」
「でも、今動いているシステムに影響はないのだろうか？」
こうした疑問を持つ企業のWeb担当者やシステム管理者も多いのではないでしょうか。
Cloudflare WAFは、Webサイトへの不正アクセスを検知・遮断するための仕組みです。既存のWebサーバーの前段に配置できるため、大規模なプログラム改修をせずに導入できる場合があります。
しかし、Webサーバーやプログラムを変更しなくても、Cloudflareを経由することで通信の流れが変わります。
その結果、問い合わせフォームが送信できない、ログインに失敗する、外部システムとのデータ連携が止まるといった問題が起こる可能性があります。
この記事では、Cloudflare WAF導入時に確認しておきたい7つの注意点と、既存システムへの影響、導入前後に実施したいチェック項目を紹介します。
Cloudflare WAFを導入すると何が変わる？
Cloudflare WAFを導入すると、通常、Webサイトへの通信はCloudflareを経由するようになります。
導入前
利用者 → Webサーバー
導入後
利用者 → Cloudflare → Webサーバー
CloudflareがWebサイトへの通信を受け付け、設定されたセキュリティルールに従って検査します。
不審な通信は遮断し、許可された通信を既存のWebサーバーへ届けます。
例えば、PHPで開発された業務システムであっても、基本的にはPHPのプログラムを書き換えずに導入できる場合があります。
ただし、通信経路が変わるため、これまでとは異なる条件でWebサーバーがアクセスを受けることになります。
特に、IPアドレスを使ったアクセス制限や、フォーム送信、ログイン処理、API連携などを行っている場合は注意が必要です。
重要なのは、「サイトが表示されること」と「業務システムが正常に動くこと」は別だという点です。
トップページが表示できても、裏側のデータ登録や通知処理が正常に動いているとは限りません。
Cloudflare WAF導入時の注意点7選
1. DNS設定の変更によるWebサイトやメールへの影響
CloudflareをWebサイトの前段に配置する場合、対象のWeb通信がCloudflareを経由するよう、DNSの設定が必要です。
DNSとは、ドメイン名と接続先のサーバーを結び付ける仕組みです。
Cloudflareでは、Web用のDNSレコードをプロキシ有効にすることで、対象のHTTP・HTTPS通信をCloudflare経由にできます。
ただし、DNSの設定変更を誤ると、Webサイトに接続できなくなる可能性があります。
特に注意したいのが、メール関連のDNSレコードです。
企業のドメインでは、Webサイトだけでなく、メールの送受信にもDNSが利用されています。
例えば、次のようなレコードがあります。
- MX：メールの配送先を指定する
- SPF：送信元メールサーバーの認証に使用する
- DKIM：メールの電子署名による認証に使用する
- DMARC：SPFやDKIMの認証結果に基づくメールの扱いを指定する
CloudflareへDNS管理を移す場合は、こうした既存レコードが正しく引き継がれているか確認する必要があります。
メール用のホスト名は、通常、CloudflareのHTTPプロキシを有効にせず「DNS only」として運用します。
確認したいこと
- 現在のDNS管理者は誰か
- 対象ドメインとサブドメインは何か
- DNS管理をCloudflareへ移す必要があるか
- MX、SPF、DKIM、DMARCなどを正しく引き継げるか
- Webサイトとメールの両方が正常に利用できるか
2. SSL/TLSの設定によるHTTPSエラー
SSL/TLSは、Webサイトと利用者の間などで通信を暗号化するための仕組みです。
Cloudflare導入後は、主に次の2区間の通信を考える必要があります。
- 利用者とCloudflareの間
- Cloudflareと本番Webサーバーの間
Cloudflareでは、SSL/TLSの暗号化モードを設定できます。
一般的には、Cloudflareと本番Webサーバーの間も暗号化し、サーバー証明書を検証する「Full (strict)」が推奨されます。
ただし、本番サーバー側の証明書が期限切れになっていたり、接続先のホスト名と一致していなかったりすると、HTTPS接続でエラーになる可能性があります。
また、既存サーバー側のHTTPSリダイレクト設定とCloudflareの設定が合わず、リダイレクトループが発生することもあります。
確認したいこと
- 本番WebサーバーのSSL証明書は有効か
- CloudflareのSSL/TLS設定は適切か
- HTTPからHTTPSへの転送が正常に動くか
- リダイレクトループが発生しないか
3. 問い合わせフォームがWAFに誤検知される可能性
Cloudflare WAF導入時に、特に注意したいのが問い合わせフォームです。
WAFはWebサイトに送られる通信を検査し、攻撃と判断したものを遮断します。
しかし、正常な通信が攻撃と誤って判断される場合があります。
これを「誤検知（False Positive）」と呼びます。
例えば、顧客が問い合わせフォームに文章を入力して送信した際、その内容がWAFの防御ルールに該当してしまうケースです。
その結果、フォームの画面は正常に表示されているのに、送信だけが失敗する可能性があります。
さらに、画面上は送信できたように見えても、アプリケーション側で正しく登録されていなければ問題です。
そこで、フォームの確認では「送信ボタンを押せるか」だけでなく、処理が最後まで完了するかをテストします。
確認したい流れ
入力 → 送信 → データ登録 → 完了画面 → 通知メール
また、ファイル添付機能がある場合は、ファイルサイズや形式によって動作が変わらないかも確認します。
誤検知が発生したらどうする？
Cloudflareには、セキュリティイベントを確認する機能があります。
フォーム送信がブロックされた場合は、該当した日時、URL、通信、WAFルールなどを調べ、遮断の原因を確認します。
誤検知と判断できた場合は、対象となるURLやルールを限定して例外を設定するなどの調整を検討します。
WAF全体を無効にするのではなく、必要な通信に限定して調整することが重要です。
4. ログイン画面や会員ページへの影響
ログイン機能があるWebサイトでは、WAFだけでなく、Cookieやセッション、キャッシュの扱いにも注意が必要です。
例えば、会員がログインした後も認証状態を維持するために、Cookieやセッション情報を利用している場合があります。
Cloudflare側で動的なページを不適切にキャッシュすると、ログイン状態が正しく維持されなかったり、意図しない画面が表示されたりする可能性があります。
また、ログイン処理がWAFの検査やセキュリティチャレンジによって中断される場合もあります。
会社案内のような一般公開ページと、ログイン後の個人向けページでは、適切なキャッシュ設定が異なります。
そのため、会員画面や管理画面では、必要に応じてキャッシュを除外する設定を検討します。
確認したいこと
- ログインとログアウトが正常にできるか
- ログイン後もセッションが維持されるか
- 個人情報や会員情報が誤ってキャッシュされないか
- 管理画面へのアクセス制限が正しく機能するか
- セキュリティチャレンジで処理が中断されないか
5. 利用者のIPアドレスが正しく取得できない場合がある
Cloudflare導入後に見落とされやすいのが、送信元IPアドレスの扱いです。
導入前のWebサーバーは、利用者のIPアドレスを直接認識している場合があります。
しかし、Cloudflareを経由すると、本番WebサーバーからはCloudflareのIPアドレスが接続元として見えるようになります。
この違いは、既存システムの処理に影響することがあります。
例えば、次のような機能です。
- アクセスログの記録
- 特定IPアドレスからのアクセス制限
- 不正ログインの検知
- アクセス回数に応じた制限
- IPアドレスを利用する業務処理
Cloudflareには、元の利用者IPアドレスをHTTPヘッダーで伝える仕組みがあります。
代表的なものが「CF-Connecting-IP」です。
ただし、元のIPアドレスを正しく利用するには、Webサーバー側で信頼できるCloudflareからの接続だけを対象として、適切に復元する設定が必要です。
外部から送られたヘッダーを無条件に信用すると、IPアドレスの偽装につながるおそれがあります。
確認したいこと
- 既存システムで利用者IPアドレスを使っているか
- Webサーバー側で元のIPを適切に復元できるか
- アクセスログに正しいIPが記録されるか
- IP制限や不正ログイン対策が従来どおり機能するか
6. API・Webhookなど外部システムとの連携
業務システムでは、Webサイトの画面だけでなく、外部サービスと自動でデータをやり取りしていることがあります。
例えば、取引先のシステムから注文データを受信したり、決済サービスから処理結果を受け取ったりするケースです。
こうした連携では、APIやWebhookと呼ばれる仕組みが利用されます。
Cloudflare WAFを導入すると、これらのHTTP通信もWAFの検査対象となる場合があります。
その結果、正常な自動通信が不正アクセスと判断され、遮断される可能性があります。
人が操作するWeb画面とは違い、自動通信ではCloudflareのセキュリティチャレンジに対応できないこともあります。
そのため、外部連携があるシステムでは、実際の通信を使った動作確認が重要です。
確認したいこと
- 外部から受信するAPIやWebhookがあるか
- 外部サービスからのデータが正常に届くか
- WAFの誤検知やチャレンジによって処理が止まらないか
- APIの認証や署名検証が引き続き有効か
なお、WAFの例外を設定する場合も、APIの認証やWebhookの署名検証まで無効にしてはいけません。
Amazon SESなどのメール送信はどうなる？
例えば、WebシステムからAmazon SESへAPIやSMTPでメールを送信している場合、その送信通信は通常、Cloudflare WAFを経由しません。
そのため、メール送信プログラム自体の変更は原則として不要です。
ただし、問い合わせフォームがWAFで遮断された場合は、メール送信処理まで到達しません。
また、DNS管理を変更する場合は、メール認証用レコードの引き継ぎが必要です。
外部サービスからHTTPで通知を受け取る仕組みがある場合は、その受信側も確認しましょう。
7. Cloudflareを経由しない直接アクセスへの対策
Cloudflare WAFを導入しても、本番Webサーバーへ直接アクセスできる経路が残っている場合があります。
例えば、WebサーバーのIPアドレスを指定することで、Cloudflareを経由せずに接続できる状態です。
この場合、Cloudflare WAFを通らない通信には、その防御が適用されません。
そのため、原則としてWebサーバーへの直接接続を制限することが推奨されます。
例えば、ファイアウォールでCloudflareからの通信だけを許可する方法があります。
ただし、既存の監視システムや運用ツール、外部連携などが直接接続している場合は注意が必要です。
これらを確認せずにアクセス制限を変更すると、正常な運用通信まで止まってしまう可能性があります。
確認したいこと
- 本番Webサーバーへ直接接続できる経路があるか
- ファイアウォールで接続元を制限できるか
- 運用・監視システムへの影響がないか
- Cloudflareを経由しない必要な通信をどう扱うか
Cloudflare WAF導入前後のチェックリスト
ここまで紹介した内容を、実務で確認しやすいように整理します。
導入前に確認する項目
| 確認項目 | 確認する内容 |
|---|---|
| 対象ドメイン | WAFを適用するドメインとサブドメイン |
| DNS | 管理者、既存レコード、メール設定 |
| SSL/TLS | 証明書とHTTPS設定 |
| フォーム | 問い合わせ、申込、ファイル添付 |
| ログイン | 認証、Cookie、セッション |
| IPアドレス | IP制限、ログ、アクセス回数制限 |
| 外部連携 | API、Webhook、外部サービス |
| 接続経路 | 直接アクセス、監視・運用通信 |
| 担当者 | Cloudflare設定、サーバー設定、動作確認の分担 |
導入後に確認する項目
| 確認対象 | テスト内容 |
|---|---|
| Webサイト | 全ページが正常に表示できる |
| HTTPS | 証明書エラーやリダイレクトループがない |
| フォーム | 送信から登録・通知まで完了する |
| ログイン | ログイン・ログアウトが正常に動く |
| 会員画面 | セッションやキャッシュに問題がない |
| ファイル添付 | 想定する形式・サイズで送信できる |
| API連携 | 外部とのデータ送受信が成功する |
| メール | 通知メールが正常に届く |
| アクセスログ | 元の利用者IPが適切に記録される |
| WAFイベント | 誤検知による遮断がないか確認する |
チェックリストは、すべてのサイトで同じ対応が必要という意味ではありません。
利用している機能に応じて確認範囲を決めることが大切です。
Cloudflare WAF導入のおすすめ手順
Cloudflare WAF導入は、次の4段階で進めると整理しやすくなります。
ステップ1：現在のシステム構成を調査する
公開ドメイン、DNS、Webサーバー、SSL証明書、フォーム、外部連携などを確認します。
まずは、現在どのような通信が行われているかを把握することが重要です。
ステップ2：Cloudflareの設定を準備する
DNS、SSL/TLS、WAFルール、キャッシュ、必要なアクセス制限を設定します。
適用する防御ルールは、既存システムへの影響も考慮して選びます。
ステップ3：実際の業務操作でテストする
フォーム送信、ファイルアップロード、ログイン、API連携などを確認します。
単に画面が表示されるかだけでなく、処理結果まで確認しましょう。
ステップ4：切替後の監視と調整を行う
切替後は、アクセスログやWAFのセキュリティイベントを確認します。
誤検知があれば原因を調べ、対象を限定してルールを調整します。
また、切替前には、問題が発生した際の復旧方法や、元の構成へ戻す手順を決めておくことも大切です。
Cloudflare WAF導入時によくある質問
Q. Cloudflare WAFの導入にはプログラム改修が必要ですか？
必ずしも必要ではありません。
既存のWebサーバーの前段にCloudflareを配置できるため、大規模なプログラム改修なしで導入できるケースもあります。
ただし、送信元IPアドレスの扱いやAPI連携など、既存の実装によっては設定変更やプログラム改修が必要になる場合があります。
Q. WAFを導入すると問い合わせフォームが使えなくなりますか？
必ず使えなくなるわけではありません。
ただし、WAFの誤検知によって正常なフォーム送信が遮断される可能性があります。
導入後は、実際にフォームから送信し、データ登録や通知メールまで確認することをおすすめします。
Q. Cloudflare WAFを導入するとメールに影響しますか？
WAFそのものは、通常のSMTPメール送信を直接検査する仕組みではありません。
ただし、CloudflareへのDNS移管時にメール関連レコードを正しく引き継がなかった場合、メールの送受信に影響する可能性があります。
Q. WAFで正しい通信が遮断されたらどうすればよいですか？
まずCloudflareのセキュリティイベントを確認し、どのルールが対象通信に適用されたか調査します。
誤検知であることを確認したうえで、該当するルールやURLに限定した例外設定などを検討します。
Q. WAF導入後はPHPなどの更新をしなくても大丈夫ですか？
いいえ。
WAFは攻撃を検知・遮断する仕組みですが、PHPなどのソフトウェアの脆弱性を修正するものではありません。
WAFによる防御とセキュリティ更新を組み合わせて運用する必要があります。
まとめ｜Cloudflare WAF導入では既存システムの動作確認が重要
Cloudflare WAFは、既存のWebサイトやWebアプリケーションにセキュリティ対策を追加できる仕組みです。
大規模なプログラム改修をせずに導入できる場合もありますが、通信経路が変わるため、既存システムに影響が出る可能性があります。
特に、次のような機能を利用している場合は事前確認が重要です。
- 問い合わせフォームやファイルアップロード
- ログイン・会員管理
- IPアドレスを利用したアクセス制御
- APIやWebhookによる外部連携
- メール通知やDNS設定
WAF導入の目的は、不正なアクセスを防ぐことです。
しかし、セキュリティ対策によって、今まで利用できていた業務機能が止まってしまっては困ります。
大切なのは、セキュリティを強化することと、既存システムを正常に使い続けることを両立させることです。
導入前にシステム構成を把握し、必要な設定と動作確認を行うことで、トラブルのリスクを減らすことができます。
既存Webシステムのセキュリティ対策でお困りの方へ
テイルウインド株式会社では、システム開発や既存システムの改善に関するご相談を承っています。
「Cloudflare WAFを導入したいが、既存システムへの影響が分からない」
「PHPで構築された業務システムのセキュリティを強化したい」
「フォームや外部APIなど、導入前に何を確認すればよいか整理したい」
こうしたお悩みがある場合は、現在のシステム構成や運用状況を整理することからご検討ください。
関連記事
- Cloudflare WAFとは？できること・できないこととPHP脆弱性への対策
- Cloudflare WAFは無料で十分？有料プランとの違いと選び方
