目次
- 目次
- はじめに
- ゴール
- 前提
- App instance構築
- AWS Network Firewall構築
- ルートテーブルの編集
- 接続確認
- AWS Network Firewallポリシーの編集
- 参考
- まとめ
- おわりに
はじめに
こんにちは、株式会社エーピーコミュニケーションズ クラウド事業部の松尾です。
今回は「AWS Network Firewall」を検証してみます。「Firewallとして色々制御できるサービス」程度の理解ですが、より具体的に機能を確認してみたいと思います。
検証するのは宛先ドメインのフィルタリング動作です。例えばWindowsサーバでWindowsUpdate通信のみをインターネット接続許可するような状況を想定しています。
ゴール
本記事でお伝えすることは次の内容です。
- AWS Network Firewallの構築手順
- AWS Network Firewallでの宛先ドメインフィルタ設定方法
前提
本検証は参考サイトの情報をベースに行っています。最もシンプルと思われる構成（IGWーFW EndpointーEC2）のシングル構成として、動作確認のしやすさを最優先にしています。
最終的な検証構成はこのようなイメージ。
App instance構築
現時点のAWSリソースはこのようになっています。
App instanceとしてWordPressサーバを構築し、ルートテーブルはデフォルトルートをIGWへ向けています。この状態でインターネット上からApp instanceのWordPressに接続できることを確認しておきます。
EC2のグローバルIPに対して接続出来ている状態。
AWS Network Firewall構築
ここから本題です。Network Firewallを作成していきます。
VPCとサブネットを指定。
検証用途なので削除保護とサブネット変更保護は無効化していきます。
空のポリシーを関連付けておきます。内容は後ほど設定します。
ファイアーウォール作成後、ステータスが準備完了になればOKです。
この時点ではこのような状態です。
Firewallは作成したものの、ルートテーブルが正しくない状態。
ルートテーブルの編集
メインルートテーブルは触らずに、各サブネットに明示的に新しいルートテーブルを紐づける形で実装していきます。
ルートテーブル紐づけ手順は割愛しますが、App subnetに紐づけるルートテーブル作成時の注意です。
Targetは「FW Endpoint」ではなく、「ゲートウェイロードバランサのエンドポイント」を指定していきます。ここは少し分かりにくいポイント。
ルートテーブル3つを作成し、サブネットへ紐づけた設定状態。上から2番目と3番目のルートテーブルが明示的に各サブネットへ紐づいているため、1番目のメインルートテーブルは使われていない状態です。4番目のルートテーブルはサブネットではなく、インターネットゲートウェイへ紐づけているもの。
図にするとこのような状態。メインルートテーブルは存在しているものの機能していない。
設定が出来たので接続確認をしていきます。
接続確認
デフォルトのままだとファイアーウォールポリシーによってドロップされてしまうため、一時的にデフォルトのアクションを「ドロップ」から「すべてアラート」に変更します。
この状態でブラウザのWordPressページを更新してみると、ファイアーウォールのモニタリングからトラフィックが確認出来ました。
ここまでで接続確認が取れました。続いてファイアーウォールの設定変更を行っていきます。
AWS Network Firewallポリシーの編集
ファイアーウォールポリシーのステートフルルールを作成していきます。
ルールグループタイプを選択します。今回はドメインでフィルタしたいので「ドメインリスト」で進めていきます。
ルールグループにはキャパシティという概念があります。このルールグループにルール数を最大いくつまで設定するか、を指定するものです。1つのファイアーウォールポリシーで30000までなので、大きくしすぎると他のルールグループを追加できなくなる点に注意です。
ドメインはGooleのみを許可する設定としました。
ルールグループが作成された状態。
許可したgoogle.comへ接続して動作を確認するとConnectできています。
アクションを「許可」から「拒否」へ変更してみます。
再度google.comへ疎通確認をすると接続できない。
想定通りの挙動となりました。
参考
まとめ
今回はシンプルなアーキテクチャでAWS Network Firewallの設定を検証してみました。
宛先ドメインでフィルタする機能は、AWS Network Firewallのリリース以前にはAWSサービスで実現出来なかった機能です。その頃はEC2上にOSSのプロキシやサードパーティ製のフィルタ機能を持つソフトを使うことで実現していました。可用性や拡張性を考慮した構成構築には手間がかかっていた記憶があります。
マネージドサービスとして実装出来ることのメリットは、機能が実装できることに加えて非機能要件もAWS側で担保されることになる点も大きいと感じています。（どういった内容が担保されるかどうかはAWSサービスの機能によりますが。）
今回のようなシンプルな構成でもルートテーブルの理解が必要なので、より複雑な集中型アーキテクチャはルートテーブル周りの設定が手間になるかもしれません。より柔軟なアーキテクチャで構築できる、ということでもあるので、目的に合わせたアーキテクチャを選択していきたいと思います！
おわりに
私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
また、一緒に働いていただける仲間も募集中です！ ご興味持っていただけましたらぜひお声がけください。
