WAF 3.0 は、既存のネットワークアーキテクチャや DNS 構成を変更することなく、Application Load Balancer (ALB) インスタンスを Web 攻撃から保護します。この保護機能は、ALB のデータプレーンに直接埋め込まれた SDK を通じて有効化されます — 追加のゲートウェイホップは不要であり、WAF と ALB 間で証明書や構成の不一致（ドリフト）が発生することもありません。
仕組み
トラフィックがご利用の ALB インスタンスに到達すると、埋め込まれた SDK が転送パス上でリアルタイムの脅威検知を実行します。SDK は攻撃リクエストをブロックし、有効なリクエストのみをバックエンドサーバーに転送します。WAF は別途設置されたゲートウェイとしてトラフィック転送に参加しないため、リクエストは単一のゲートウェイを通過するのみです。これにより、余分なホップによるレイテンシが解消され、WAF と ALB 間での証明書および暗号スイートの同期作業も不要になります。
前提条件
開始する前に、以下の点をご確認ください。
同一アカウント: ALB インスタンスと WAF インスタンスが同一の Alibaba Cloud アカウントに属していること。ただし、マルチアカウント管理 を設定済みの場合はこの限りではありません。
対応リージョン: ALB インスタンスが以下のリージョンのいずれかに配置されていること。該当しない場合は、代わりに CNAME レコードモード を使用してください。
対応インスタンスタイプ: 実行中 状態の Basic および Standard ALB インスタンスのみが、WAF 対応エディションへアップグレード可能です。
本人確認: WAF 対応 ALB インスタンスの購入前に、本人確認を完了してください。
対応リージョン:
| 地域 | リージョン |
|---|---|
| 中国 | 中国 (成都)、中国 (青島)、中国 (北京)、中国 (広州)、中国 (杭州)、中国 (ウランチャブ)、中国 (上海)、中国 (深セン)、中国 (張家口)、中国 (香港) |
| アジアパシフィック | フィリピン (マニラ)、インドネシア (ジャカルタ)、日本 (東京)、マレーシア (クアラルンプール)、シンガポール、タイ (バンコク)、韓国 (ソウル) |
| ヨーロッパおよびアメリカ | ドイツ (フランクフルト)、米国 (シリコンバレー)、米国 (バージニア)、メキシコ |
| 中東 | サウジアラビア (リヤド - パートナー運営) |
ステップ 1: ALB のオンボーディングページを開く
WAF 3.0 コンソール にログインします。上部ナビゲーションバーで、ご利用の WAF インスタンスのリソースグループおよびリージョン（中国本土 または 中国本土以外）を選択します。左側ナビゲーションウィンドウで、オンボーディング をクリックします。クラウドネイティブ タブをクリックし、クラウドサービス一覧から Application Load Balancer (ALB) を選択します。Web Application Firewall 3.0 コンソール
ステップ 2: クラウドサービスの権限付与（初回のみ）
クラウドネイティブ統合を初めて使用する場合は、画面のプロンプトに従って、[今すぐ承認] をクリックします。これにより、AliyunServiceRoleForWAF サービスリンクロールが作成され、RAM コンソール の [ID管理] > [ロール] ページで確認できます。
ステップ 3: ALB インスタンスの追加
右側の一覧から、保護対象の ALB インスタンスを見つけ、操作 列の 今すぐ追加 をクリックします。インスタンスが表示されない場合は、右上隅の アセットの同期 をクリックしてください。
ステータスが 完全保護 と表示された場合、インスタンスの追加が正常に完了しています。
ALB インスタンスを WAF に追加すると、自動的に WAF 有効版にアップグレードされます。これにより、ALB 側で追加料金が発生します。
複数の ALB インスタンスを一度に追加するには、一括登録機能をご利用いただくか、ワンクリックオンボーディング をクリックしてすべてのインスタンスを一括で追加することもできます。
ステップ 4: 保護機能の有効化確認
ブラウザで、ご利用のウェブサイトドメインにクロスサイトスクリプティング (XSS) のテスト文字列を付加してアクセスします。
<your-website-domain>/alert(xss)WAF が 405 エラー画面を返した場合、リクエストが正常に遮断されており、保護機能が有効化されています。
本番環境に適用
本番 ALB インスタンスで WAF を有効化する前に、まず非本番インスタンスでテストを行ってください。WAF 保護の有効化および無効化はサービス中断を引き起こしませんが、ログおよびサービスの健全性を監視し、サービス可用性を確保する必要があります。
推奨される段階的導入手順:
トラフィックが少ない時間帯に、非本番 ALB インスタンスを WAF に追加します。
少なくとも 1 サイクル分、ログおよびビジネスメトリックを監視し、安定性を確認します。
予期しないブロックが発生していないことを確認した後、本番 ALB インスタンスを追加します。
有効化後のサービス監視項目:
| 確認項目 | ツール | 確認ポイント |
|---|---|---|
| トラフィックログ | ALB ログ | 200 ステータスコードの大幅な減少、または QPS の急激な増減 |
| WAF が処理したトラフィック | WAF ログ | 誤検知 — WAF によってブロックされた正当なリクエスト |
| ビジネスメトリック | お客様のモニタリングツール | ユーザーのアクセス状況、トランザクション数、その他のサービスの正常動作 |
継続的なメンテナンス:
セキュリティイベントのレビュー: 攻撃に関する情報を得るために、セキュリティレポート を監視し、Cloud Monitor の通知設定 を行います。
保護ルールの調整: WAF ログをレビューし、誤検知を特定してルールを調整することで、正当なビジネスリクエストのブロックを回避します。
保護ルールの設定および管理
WAF は、-alb 接尾辞を付けた保護対象を自動的に作成し、コア保護モジュールを含むデフォルトの保護ルールを有効化します。これらの設定は、保護設定 > 保護対象 ページで確認できます。
デフォルトのルールが要件を満たさない場合は、保護ルールの作成または編集を行ってください。「保護設定の概要」をご参照ください。
複数のドメインが同一の ALB インスタンスに解決され、各ドメインに対して異なる保護ルールを適用したい場合、ドメインを個別に保護対象として手動で追加 してください。
WAF 保護の無効化または削除
WAF 保護の一時停止
誤検知が多数発生するなどの問題が発生した場合、WAF コンソールの 保護対象 ページに移動し、WAF 保護ステータス スイッチをオフにします。「ワンクリックで WAF 保護を無効化」をご参照ください。
WAF 保護の削除
クラウドネイティブ タブに移動し、クラウドサービス一覧から Application Load Balancer (ALB) をクリックします。対象となるインスタンスを見つけ、操作 列の 削除 をクリックします。表示されたダイアログボックスで、OK をクリックします。
削除後、ALB インスタンスへのトラフィックは WAF による保護対象外となり、セキュリティレポートにも当該トラフィックのデータは含まれません。
従量課金インスタンスの場合: 削除後にリクエスト処理の課金は停止しますが、WAF インスタンスおよびその保護ルールは維持されるため、特徴量使用料金は継続して発生します。WAF 全体の課金を停止するには、「WAF サービスの終了」をご参照ください。
ALB コンソールからの WAF 保護の有効化および管理
ALB コンソールからも、WAF 保護の有効化および管理が可能です。
制限事項
| 制限事項 | 詳細 |
|---|---|
| 本人確認 | 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 |
| 非対応機能 | データ漏洩防止 (DLP); Bot Management のクローラ対策シナリオにおける Web SDK の自動統合 |
よくある質問
追加したい ALB インスタンスが見つかりません。
まず、オンボーディング ページの右上隅にある アセットの同期 をクリックしてください。
それでもインスタンスが表示されない場合、前提条件を満たしていない可能性があります。例えば、中国本土以外のリージョンに配置された ALB インスタンスは、クラウドネイティブ統合を利用するには、同一リージョングループ内の WAF インスタンスが必要です。ご利用のリージョンが対応していない場合は、代わりに CNAME レコードモード をご使用ください。
1 つのドメインが複数の ALB インスタンスに解決される場合、WAF 保護をどのように追加すればよいですか？
クラウドネイティブモードでは、それらすべての ALB インスタンスを WAF に追加します。CNAME レコードモードでは、ドメインを追加し、複数の ALB インスタンスの CNAME をオリジンアドレスとして構成します。
複数のドメインが同一の ALB インスタンスに解決される場合、それぞれに異なるルールを適用するにはどうすればよいですか？
クラウドネイティブモードで ALB インスタンスを追加すると、その ALB 上のすべてのドメインがデフォルトポリシーで保護されます。ドメインごとに異なる保護ルールを適用するには、各ドメインを個別に保護対象として手動で追加 してください。CNAME レコードモードでは、各ドメインを個別に追加します。
ALB インスタンス上の同一ドメインに対して、クラウドネイティブモードと CNAME レコードモードを併用できますか？
いいえ。両モードを同時に使用すると、転送の競合および保護機能の失敗を招きます。CNAME レコードモードからクラウドネイティブモードへ切り替えるには、DNS レコードをオリジンへ戻し、DNS 変更が反映されるのを待った後、CNAME レコードモードの設定を削除し、クラウドネイティブモードで ALB インスタンスを追加してください。
WAF 2.0 と WAF 3.0 の ALB 連携における違いは何ですか？
WAF 3.0 は、ALB インスタンスに埋め込まれた SDK を使用します。SDK はトラフィックの抽出、検出、保護を実行しますが、転送パス上に存在しないため、リクエストは単一のゲートウェイを通過します。これにより、余分なホップによるレイテンシが解消され、WAF と ALB 間での証明書および暗号スイートの同期も不要になります。
WAF 2.0 は透明プロキシを使用します。トラフィックは WAF を経由してリダイレクトされ、攻撃がブロックされた後、クリーンなリクエストがオリジンに転送されます。リクエストは 2 つのゲートウェイを通過するため、タイムアウトや証明書などの構成を両者間で同期させる必要があります。
詳細な比較については、「WAF 3.0 と WAF 2.0 の比較」をご参照ください。