こんにちは。
タイトルの通り自社WebサーバにAWS WAFを適用しまして、
正常に稼働していることが確認できた頃合いだったので、
社内への技術的な共有も兼ねて寄稿することにしました。
全5回以下のような構成となります。
- 構成編
- 費用算出
- 構成変更における課題
- AWS WAFとALBの初期設定
- 運用後の経過
目次
構成変更における課題の把握
当初、構成変更するにあたって、どのような課題があるのかがあまりわかっていませんでした。
Webサーバの構築や運用に関わっていなかったため、
どういう設定が入っているのかが分からなかったためです。
そのため、最初はWebサーバ構築時の経緯を追うことと、コンフィグに目を通すことから始めました。
お客様環境に製品を導入する際には、関連するコンフィグ全てのパラメータの値を確認して、
どういう影響があるのかを確認しています。
ただ、自社Webサーバに対してそこまでの可用性を求められていない雰囲気を察して、
ある程度妥協をしながら設定値を確認しました。
（パラメータから実際どういう影響が及ぶのかを想像することも限界があるので、
結果として本番環境のスナップショットをもとに、
テスト環境を作って色々試験をしてみるという気持ちに切り替えたのが正解でした。）
洗い出した課題で特にインパクトがあったもの
移行において、問題になった課題を3つ紹介します。
- DNSのリソースレコード変更
- 送信元IPアドレス制限方法の切替
- HTTPSを無効化するにあたっての対応
DNSのリソースレコード変更
ALBを作成すると、「～～.elb.amazonaws.com」というFQDNが払い出されます。
その払い出されたFQDNにアクセスすれば、ALBを経由してWebサーバに通信が到達します。
ただし、元々弊社では [ www.secuavail.com ] [ secuavail.com ] のいずれにアクセスしてもWebサイトが表示されるようにしていました。
そのため、 [ www.secuavail.com ] 及び [ secuavail.com ] にアクセスしたら、[ ～～.elb.amazonaws.com ] に通信をするようにするために、CNAMEレコードを使う必要がありました。
弊社ドメインは、AレコードでElastic IPと紐づけていたため、レコードの変更が必要になりました。
ただ、 [ secuavail.com ] のようなネイキッドドメインはRFCの規定上、紐づけることはできません。
（https://datatracker.ietf.org/doc/html/rfc1912#section-2.4）
※Route53では追加拡張機能を使うことで、実現することができます。
元々ネイキッドドメインでのアクセスは想定しておらず、件数も多くないだろうということで、
社内で調整したうえで、ネイキッドドメインでWebサイトにアクセスできないようにしました。
※Network Load Balancerを使えば固定IPアドレスをALBに紐づけることもできるようです。
要件によっては、こちらで実装することも考えてもよさそうです。
送信元IPアドレス制限方法の切替
Webサーバで、送信元IPアドレスでアクセス制限をしているURLがありました。
ALBではプライベートサブネットのIPアドレスへ送信元NATが行われます。
つまり、これまでグローバルIPアドレスベースでアクセス制限をしていた設定が使えなくなってしまいます。
これについては、X-Forwarded-Forの情報をもとに送信元IPアドレス制限をするようにしました。
幸い弊社で使っているWebサーバのミドルウェアでは、XFFを送信元IPとして扱うモジュールが用意されており、
そのモジュールを有効化すると、既存の送信元制限の設定を変更する必要がありませんでした。
XFFを詐称してのリクエストを試してみましたが、
サーバに到達した時点での最後のXFFの値に制限されることが確認でき、これまで通りの制限が行えました。
HTTPSを無効化するにあたっての対応
ALB＋ACMによってTLS終端をするので、WebサーバでHTTPS通信を受け取らなくなります。
不要なプロセスを動かしたくないほか、切り分けなどが面倒になるため、
HTTPSを有効化するモジュールを無効化するようにしました。
関連する課題として、HTTPリクエストをHTTPSへリダイレクトする設定を削除する必要がありました。
HTTPSでのリクエストが普通になりましたが、過去に作成されたページのリンクやユーザのアクセス方法によって、
HTTPでリクエストが飛んでくる可能性があります。
それに備えて、HTTPSのURLへリダイレクトするような設定がサーバに入っていました。
その設定は削除して、ALBのリスナールールにて、HTTPSへリダイレクトする設定を入れることで引き継ぎました。
まとめ
発生した課題についていくつか紹介させていただきました。
いずれもロードバランサをWebサーバの前段に配置する場合にありがちな問題だと思います。
DNSのリソースレコードの変更については、危うく社内インフラにも影響が及んでいた可能性があるため、
課題によって割く労力に濃淡をつけるのはやはり重要だと思った次第です。
記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。
当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。
