現在は、Alibaba Cloud Elastic Compute Service の仮想マシンを直接インターネットに公開しているのですが、セキュリティ強化の目的で Alibaba Cloud ESA 経由に変更し、セキュリティを強化する話です。 構成変更のBefore / After は以下の感じです。
Alibaba Cloud ESA (Edge Security Acceleration)はエッジセキュリティ、WAAP の類で、CDN（高速配信） ＋ WAF（Web層防御） ＋ 高度DDoS ＋ ボット対策 ＋ エッジコンピューティングが一つまとまったサービスです。 今回のセキュリティ強化用途には最適なサービスとなります。 世の中的には Cloudflare や Akamai 、Fastly の方が有名だとは思います。
最初はこの ESA を利用するのではなく Cloudflare を利用する予定でした。 Alibaba Cloud CDN はコンテンツ配信が得意でセキュリティには有償のWAFオプションが必要です。 それに対して Cloudflare は無償の範囲でセキュリティの機能が比較的充実していました。Cloudflare のWorkers が良いとも聞いていて将来このブログサイトもそこに引っ越しもよいかなと考えていました。
それで Cloudflareの構築を進めたのですが早々に DNS ゾーンをCloudflare に切り替える必要があることがわかり（切り替えない場合は有償のCloudflareが必要）、とりあえず Alibaba Cloud CDN で構築するかと調べ始めたら Cloudflare 相当の機能を提供する Alibaba Cloud ESA の存在を知り、今回利用することにしています。
Alibaba Cloud ESA と Cloudflare の比較情報は別途行おうと思います。ちょっと調べると ESA にも Cloudflare の Workers 相当があるようでエッジセキュリティだけではなくWebサイト全体での比較を行おうかなと。 さらにやれるなら Alibaba Cloud と Cloudflare でサイトの冗長化までも。
目次
作業の流れ
最初に全体の作業の流れを整理しておきます。
- ESA コンソールでのドメイン登録
- ESA 側の証明書・TLS・WAF 設定
- トラフィック超過保護ルール（Overage Rules）の設定
- ECS（Apache / WordPress）側の設定調整
- DNS 切り替えとサーバへの直接アクセスのブロック設定
1.ESA コンソールでのドメイン登録
Alibaba Cloud コンソールにログインし、Edge Security Acceleration の管理画面に移動します。
ESA コンソールの 「Websites」> 「Add Website」 をクリックし、Webサイトの追加を進めます。
ここでは root domain を指定します。 この後選ぶプランで無償の”Entrance”を利用するには root domain の指定が必要なため。 サブドメインを利用する場合は有償プランが必要とのこと。
Locationは “Global (Excluding the chinese Mainland)” を選択します。 右隣のGlobalやChina Mainland を利用するには中国の ICP filing が必要です。
DNS Setup には “CNAME”を選択します。 今使っている Alibaba Cloud DNS を継続して利用します。
Planは無償の “Entrance”を利用します。 有償の Pro は 15 USD / Month です。 1年間で買えば 50% off の 7.50 USD / Month までディスカウントされますが、まずは無償で進めます。
支払い画面は省略しますが、1分もかからずに購入は完了です。
次は DNS ドメインの確認です。
指定のTXT recored を作成します。
面白いことに Cloudflare や AWS Route53、GCP DNS、Dyn DNS について設定画面の画像が紹介されています。 面白といったのはあまりこういうのを見たことがなかったのと、Alibaba Cloud DNS については紹介がなかったためです。
Cloudflare だとこんな画像が案内
私のDNSゾーンはAlibaba Cloud DNS で管理しているので Alibaba Cloud DNS で TXT レコードを追加します。 TXTレコードの登録で特に注意するべきことはありませんが、せっかく Alibaba Cloud DNS を使っているので TTL を 1秒にしています。
dig コマンドで登録したTXTレコードが正しく応答されるか確認します。
問題なく応答がかえってきたのでOKです。
$ dig txt _esaauth.bigriver.jp.
; <<>> DiG 9.18.39-0ubuntu0.22.04.6-Ubuntu <<>> txt _esaauth.bigriver.jp.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37594
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_esaauth.bigriver.jp. IN TXT
;; ANSWER SECTION:
_esaauth.bigriver.jp. 10 IN TXT "verify_f492a50b931ee7fa594d3629cca4a335"
;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sat Oct 03 20:33:21 CST 2026
;; MSG SIZE rcvd: 101元の画面で”Verify”をクリックし、ESA 側でTXTレコードを確認させます。
クリックすると一瞬正常終了のメッセージが見えたような気がして閉じてしまいました。
まだStatusはPendingですが設定を続けていきます
Originとして woredpress サーバ（Alibaba Cloud Elastic Compute Service の仮想マシン）を登録します。
Traffic > Origin Pools から “Create Origin Pool”をクリックし、
まずは Origin Server を追加します。
Alibaba Cloud ECS の仮想マシンを Origin にしますが、Origin Address には Public IP Address を指定します。
これで Origin Pools の設定は完了です。
2. ESA 側の証明書・TLS・WAF 設定
Edge Certificates（ユーザー ↔ ESA 間の TLS 終端）を設定します。
“Upload Custom Certificates”をクリックします。
Alibaba Cloud SSL で購入し ECS のApacheで利用している証明書をリストボックスから選びます。
別途購入した証明書を使う場合は Certificate Source で Custom Certificate を選び、Private Key と Public Key を指定することになります。
登録した証明書のStatus が “Normal”になればOKです。
次はOrigin TLS / Back-to-Origin Protocol（ESA ↔ ECS 間の暗号化）を設定していきます。
“Origin Protocol and Port” の “Configure”をクリックします。
Origin Protocol に”HTTPS”を指定します。
これで Origin Protocol の設定も完了です。
WAF（マネージドルール・攻撃防御）の有効化を行います。タブ「Managed Rules（マネージドルール）」から設定します。
Managed Ruleset を”Enable”にします。
Managed Rulesetが有効なりました。
“Edit”から既定の設定を確認しておきます。 とりあえずは既定のままで進めて今後問題が出たらチューニングしていきます。
ポイントは Basic Protection Rules (Free) の Protection Level が”Medium (Recommended)”になっていることです。 推奨なのでいったんはこのままとしますが、問題が出る場合はここを緩めるか、本当にチューニングする場合は有償のProに移行してルールをカスタマイズすることになるかなと。
その他、Request のフィルタリングや時間帯などもチューニングできそうですがまずは既定のままとします。
他にもいろいろWAFで設定できるのですが大体有償版にアップグレードしないと使えない感じでした。
これでWAF設定も完了です。
3. トラフィック超過保護ルール（Overage Rules）の設定
ESA の無料枠を超えた場合を想定し、制限をかけます。 可能性は低いとはいえ、万が一大量のトラフィックをさばいた結果莫大な課金が発生しても困ってしまうためです。
今回、ESAの管理画面に初めてアクセスしたのですが、その際、Feature updateとして以下が案内され、トラフィック超過時のアラートを出せることが分かりました。
左メニューの一番下にある”Usage Cap”から上限を設定します。 “Create Rule”をクリックします。
無償プランの無料枠は以下の通りです。 上限の80%位で Cap Rule を設定することにします。
- 月間データ転送量（Traffic）: 50 GB / 月
- 月間リクエスト数: 300 万リクエスト / 月
これで cap の設定も完了です。 無料枠を超えての課金が発生しないようになるので少し安心です。
4. ECS（Apache / WordPress）側の設定調整
ESA ↔ ECS 間が HTTPS で正しく通信されていることを WordPress に認識させる設定です。
私は以前にAlibaba Cloud の Load Balancer を利用していたことがあり、その時にすでに設定済。
if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' ) { $_SERVER['HTTPS']='on'; }5. DNS切り替え
切り替えのために、www.bigriver.jp のDNSレコードを変更し、これまでは Aレコードで直接 ECS インスタンスへの接続となっていた状態を CNAME で ESA に経由に切り替えていきます。
ESA にどのWebサイトを対象とするか、ESA のDNS画面で登録します。
“Add Record”をクリックします。
hostname には www.bigriver.jp となるように”www”を指定します。
Recorded Value には”Origin Pool”を選択し、Origin Poolでは別途作成したpoolを選択します。 このプール名は一見 DNS にレコード登録が必要に見えますが不要です。 ESA内での識別子となります。
Business Typeを選びます。 ”Web”を選択し、”OK”をクリックします。
Recordの追加が問題なく完了しました。 次は CNAME をDNSドメインに追加します。
ESAの画面でCNAMEの設定値を確認しておきます。
まずはもともとある www.bigriver.jp のAレコードを削除します。 画面は割愛しますが、Alibaba Cloud DNS上で
Alibaba Cloud側でCNAMEレコードを追加します。
このあと、Webブラウザからアクセスできることを確認し、問題なくアクセスできました。
ESA の overview 画面でトラフィックを処理していることも確認できました。
以下は、翌朝に再確認したもの。 日曜の24:00くらいから7:30までのアクセスが少ない時間帯ではありますが40.65MBのトラフィック、2.5KのリクエストをESAでさばいてもらえています。
ひとまず順調な滑り出しといえそうです。
6. オリジンサーバへのアクセス制限
最後に ECS の Security Group で https 通信の送信元を制限します。
これまではすべての送信元を許可していましたが、ESA からのアクセスに限定します。
しかし、ESA のIPアドレスリストの入手には ESA の Free バージョンではなく Pro 以上の有償バージョンが必要なことがわかりました。
今回は Pro を購入してのアクセス制限は見送ります。 コストやWAF機能の観点で再度整理、検討してみて本当に必要かどうかを見極めます。 サーバ側で Security Center のAdvanced Edition と Agentic EDR で強化しているのと、ESA で本当に守ろうと思ったらESA のWAF機能を正しく評価し必要な機能を備えているのか、備えているとしても他の方式（Alibaba Cloud WAFなど）と比べて適切かなどを確認してからになると思います。
ESAの IPアドレスではなく ESA を通過する際にHTTPの Header を付与し、Apache側でその Header があるものだけを受け付けるようにします。
ESA側の設定は Transform Rules > Modify Request Header で行います。
設定画面でイメージ図もありますがこの左側のESA to Origin の図の通りで今回設定する header は ESA と Origin サーバだけでした使われないため第三者となる Client は値を知ることは出来ません。 が、このあと設定する値がばれてしまうとサーバにESAを経由せずとも接続できてしまうので値は漏れないようにしましょう。
“X-Origin-Auth”ヘッダーを追加するようにします。 Request Header Value には合言葉を設定しておきます。後ほどのApacheでも利用します。
Apache側では .htaccess ファイルでHTTPヘッダーを識別するルールを追加します。XXXX～は伏字ですが、ESAで設定した Request Header Value と同じ値である必要があります。
この.htaccess ファイルは wordpress のトップフォルダに配置します。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:X-Origin-Auth} !^XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX$ [NC]
RewriteRule ^ - [F,L]
</IfModule>wordpress の管理者画面のアクセス制限をもともとはIPアドレスで行っていました。 今回、ESAを導入したことで送信元がESAのIPアドレスとなります。 このままアクセスすると制限されます。
管理画面のフォルダにも.htaccess を配置します。
最初の設定はヘッダの識別です。次はIPアドレスで管理者画面へのアクセスを制限します。
<IfModule mod_rewrite.c>
RewriteEngine On
# ESAからの接続をHeaderで識別する
RewriteCond %{HTTP:X-Origin-Auth} !^XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [NC]
RewriteRule ^ - [F,L]
# 接続元をIPアドレスで制限する
RewriteCond %{HTTP:X-Forwarded-For} !XXX\.XXX\.XXX\.XXX [NC]
RewriteRule ^ - [F,L]
</IfModule>これで基本的にはESA経由でしか HTTPリクエストは受け付けない状態となり、また、これまで通り特定の送信元のみWordpressの管理者画面にアクセスできる状態となりました。
以上
