WAF 3.0 は、既存のネットワークアーキテクチャや DNS 設定を変更することなく、Application Load Balancer (ALB) インスタンスを Web 攻撃から保護します。この保護は、ALB のデータプレーンに直接組み込まれた SDK によって有効になります。WAF と ALB 間で余分なゲートウェイホップや、証明書・設定のドリフトは発生しません。
仕組み
トラフィックが ALB インスタンスに到達すると、組み込み SDK が転送パス上でリアルタイムの脅威検出を実行します。SDK は悪意のあるリクエストをブロックし、有効なリクエストをバックエンドサーバーに転送します。WAF は独立したゲートウェイとしてトラフィック転送に関与しないため、リクエストは 1 つのゲートウェイのみを通過します。これにより、余分なホップによるレイテンシが排除され、WAF と ALB 間で証明書と暗号スイートを同期する必要がなくなります。
前提条件
作業を開始する前に、以下をご確認ください。
同じアカウント：マルチアカウント管理が設定されている場合を除き、ALB インスタンスと WAF インスタンスは同じ Alibaba Cloud アカウントにある必要があります。
サポート対象リージョン：ALB インスタンスは、次のいずれかのリージョンに存在する必要があります。そうでない場合は、代わりに CNAME レコードモード を使用してください。
サポート対象インスタンスタイプ：実行中 状態の Basic および Standard の ALB インスタンスのみ、WAF 有効化版にアップグレードできます。
本人確認：WAF 有効化版の ALB インスタンスを購入する前に、本人確認を完了してください。
サポート対象リージョン：
エリア | リージョン |
中国 | China (Chengdu), China (Qingdao), China (Beijing), China (Guangzhou), China (Hangzhou), China (Ulanqab), China (Shanghai), China (Shenzhen), China (Zhangjiakou), 香港 (中国) |
アジア太平洋 | Philippines (Manila), Indonesia (Jakarta), Japan (Tokyo), Malaysia (Kuala Lumpur), Singapore, Thailand (Bangkok), South Korea (Seoul) |
ヨーロッパ・アメリカ | Germany (Frankfurt), US (Silicon Valley), US (Virginia), Mexico |
中東 | SAU (Riyadh - Partner Region) |
ステップ 1：ALB オンボーディングページを開く
Web Application Firewall 3.0 コンソールにログインします。上部メニューで、WAF インスタンスのリソースグループとリージョン ( [中国本土] または [中国本土以外] ) を選択します。左側メニューで、アクセス管理 をクリックします。クラウドプロダクトアクセス タブをクリックし、クラウドサービスのリストから Application Load Balancer (ALB) をクリックします。
ステップ 2：クラウドサービスの承認 (初回のみ)
クラウドネイティブ統合を初めて使用する場合は、画面の指示に従い、今すぐ許可する をクリックします。これにより、[AliyunServiceRoleForWAF] という名前のサービスリンクロールが作成されます。このロールは、RAM コンソール の [ID] > [ロール] ページで確認できます。
ステップ 3：ALB インスタンスの追加
右側のリストで、保護する ALB インスタンスを見つけ、操作 列の 今すぐアクセスする をクリックします。インスタンスが表示されない場合は、右上の 資産の同期 をクリックします。
ステータスが 全部保護 と表示されたら、インスタンスは正常に追加されています。
ALB インスタンスを WAF に追加すると、自動的に WAF 有効化版にアップグレードされます。これにより、ALB 側で 追加料金 が発生します。
複数の ALB インスタンスを一度に追加したり、一括接続 をクリックしてすべてのインスタンスを一度に追加することもできます。
ステップ 4：保護が有効であることの確認
ブラウザで、Web サイトのドメイン名の後にクロスサイトスクリプティング (XSS) のテスト文字列を入力します：
<your-website-domain>/alert(xss)WAF が 405 エラーページを返した場合、リクエストがインターセプトされ、保護が有効になっていることを示します。
次のステップ
保護ルールの設定と管理
WAF は自動的に -alb というサフィックスが付いた保護対象を作成し、コア保護モジュールを含むデフォルトの保護ルールを有効にします。これらは、保護設定 > 保護対象 ページで確認できます。
デフォルトのルールが要件を満たさない場合は、保護ルールを作成または編集してください。「保護設定の概要」をご参照ください。
複数のドメインが同じ ALB インスタンスに解決され、それぞれに異なる保護ルールを適用したい場合は、保護対象としてドメインを手動で追加してください。
関連操作
ロールバック (WAF 保護の削除)
WAF 保護の一時的な無効化：誤検知が多数発生するなどの問題が発生した場合は、WAF コンソールの 保護対象 ページに移動し、WAF 保護ステータス スイッチをオフにします。「ワンクリックでの WAF 保護の無効化」をご参照ください。
WAF 保護の削除：クラウドプロダクトアクセス タブに移動し、クラウドサービスのリストから Application Load Balancer (ALB) をクリックし、対象のインスタンスを見つけて、操作 列の 接続解除 をクリックします。表示されたダイアログボックスで、OK をクリックします。
重要削除後、ALB インスタンスへのトラフィックは WAF によって保護されなくなり、セキュリティレポートにはそのトラフィックのデータが含まれなくなります。
従量課金インスタンスの場合：リクエスト処理料金は削除後に停止しますが、WAF インスタンスとその保護ルールは残るため、機能の使用料は継続して発生します。WAF のすべての課金を停止するには、「WAF サービスの終了」をご参照ください。
ALB コンソールでの WAF 保護の有効化と管理
ALB コンソールから WAF 保護を有効化および管理することもできます：
本番環境への適用
ALB インスタンスの WAF 保護の有効化および削除は、サービスを中断しません。ただし、ALB インスタンスを追加する際は、サービスの可用性を確保するために、ログとサービスの健全性を監視する必要があります。
展開戦略：オフピーク時に、まず非本番環境の ALB インスタンスを WAF に追加します。一定期間実行して正常な動作を確認してから、本番環境の ALB インスタンスを追加します。
サービスの検証：インスタンスを追加した後、サービスが正常に実行されていることを確認します：
継続的なメンテナンス：本番インスタンスを追加した後、継続的なメンテナンスを実行し、攻撃イベントや誤検知イベントに注意を払ってください。
イベントの確認：セキュリティレポートを監視し、Cloud Monitor 通知を設定して、攻撃やセキュリティイベントに関する情報を常に入手できるようにしてください。
ルールの調整：攻撃ログを確認して誤検知を特定し、それに応じて保護ルールを調整してください。
制限事項
制限事項 | 詳細 |
本人確認 | WAF 有効化版の ALB インスタンスを購入する前に必要 |
対象インスタンスタイプ | 実行中 状態の Basic および Standard の ALB インスタンスのみ |
Container Service for Kubernetes (ACK) | ACK の ALB インスタンスで WAF を有効にするには、「WAF 有効化版 ALB インスタンスを使用したアプリケーションの保護」をご参照ください。 |
サブスクリプション - 統合可能な最大インスタンス数 | Basic Edition: 300 / Pro Edition: 600 / Enterprise Edition: 2,500 / Ultimate Edition: 10,000 |
従量課金 - 統合可能な最大インスタンス数 | 10,000 |
サポートされていない機能 | データ漏洩防止、ボット管理のアンチクローラシナリオにおける Web SDK の自動統合 |
よくある質問
追加したい ALB インスタンスが見つからないのはなぜですか？
まず、アクセス管理 ページの右上隅にある 資産の同期 をクリックします。
それでもインスタンスが表示されない場合は、前提条件が満たされていない可能性があります。たとえば、中国本土以外の ALB インスタンスでは、クラウドネイティブ統合のために同じリージョングループ内の WAF インスタンスが必要です。お使いのリージョンがサポートされていない場合は、代わりに CNAME レコードモード を使用してください。
1 つのドメインが複数の ALB インスタンスに解決される場合、どのように WAF 保護を追加しますか？
クラウドネイティブモードでは、それらすべての ALB インスタンスを WAF に追加します。CNAME レコードモードでは、ドメインを追加し、複数の ALB インスタンスの CNAME をオリジンアドレスとして設定します。
複数のドメインが同じ ALB インスタンスに解決される場合、それぞれに異なるルールを適用するにはどうすればよいですか？
クラウドネイティブモードで ALB インスタンスを追加すると、そのインスタンス上のすべてのドメインがデフォルトのポリシーで保護されます。ドメインごとに異なる保護ルールを適用するには、各ドメインを保護対象として手動で追加します。CNAME レコードモードでは、各ドメインを個別に追加します。
ALB インスタンス上の同じドメインに、クラウドネイティブモードと CNAME レコードモードの両方を使用できますか？
いいえ。両方のモードを同時に使用すると、転送の競合が発生し、保護が失敗します。ドメインを CNAME レコードモードからクラウドネイティブモードに切り替えるには、DNS レコードの向き先をオリジンに戻し、DNS の変更が伝播するのを待ってから CNAME レコードモードの設定を削除し、その後クラウドネイティブモードで ALB インスタンスを追加します。
ALB との WAF 2.0 と WAF 3.0 の統合の違いは何ですか？
WAF 3.0 は、ALB インスタンスに組み込まれた SDK を使用します。SDK は、転送パスに介在することなくトラフィックの抽出、検出、保護を処理するため、リクエストは 1 つのゲートウェイのみを通過します。これにより、余分なホップによるレイテンシが排除され、WAF と ALB 間で証明書と暗号スイートを同期する必要がなくなります。
WAF 2.0 は、透過型プロキシを使用します。トラフィックは WAF を経由してリダイレクトされ、WAF が攻撃をブロックし、正常なリクエストをオリジンに転送します。リクエストは 2 つのゲートウェイを通過するため、タイムアウトや証明書などの設定を両方で同期させておく必要があります。
完全な比較については、「WAF 3.0 と WAF 2.0 の比較」をご参照ください。