AWS Network FirewallとRoute 53 Resolver DNS Firewallのドメインリスト管理の一元化について

お客様の多くは、Amazon Virtual Private Cloud (Amazon VPC)内のワークロードを保護するために「多層防御」アプローチを採用しています。AWS Network FirewallとAmazon Route 53 Resolver DNS Firewallでドメインリストルールを使用すると、ドメイン名に基づいて複数のレイヤーでネットワークセキュリティ制御を適用できます。DNS FirewallとNetwork Firewallの両方でドメインリストを使用できますが、現在のところ、両方のサービス間でドメインリストを同期する機能はありません。DNS Firewallを使用すると、VPC に関連付けるルールグループでドメイン名フィルタリングルールを定義できます。また、Amazon Network Firewall は、ステートフルファイアウォールルールにドメインリストを含めることで、ドメインをフィルタリングします。
この記事では、DNS Firewallと Route 53 Resolver DNS Firewallの共通ドメインリストを作成および更新するプロセスを自動化する方法について説明します。この機能を自動化すると、複雑さとリスクが軽減され、セキュリティ体制が強化され、時間を節約し、運用上の負担が軽減されます。
Route 53 Resolver DNS Firewall は、Route 53 Resolver 向けの可用性の高いマネージド DNS ファイアウォールサービスです。これにより、すべての VPC にわたる DNS トラフィックを一元的に簡単に拒否/許可し、DNS コントロールポイントを提供できます。Amazon Network Firewallは、ホストヘッダーインスペクションを適用して、同様のドメイン許可リストまたは拒否リストコントロールを作成できます。

ソリューションの概要

このソリューションでは、Amazon Simple Storage Service (Amazon S3)バケット、Amazon S3 Event Trigger、AWS Lambda Function、DNS Firewallドメインリストとルールグループ、Network Firewallルールとルールグループ、および必要なAWS Identity and Access Management (IAM) ロールを導入するAWS CloudFormationテンプレートを提供します。導入後は、1行に1ドメインのテキストファイルがドメインリストを定義し、Amazon S3にアップロードすることで、Lambda関数をトリガーにしてNetwork FirewallとDNS Firewallの両方のドメインリストルールを更新することができます。ドメインリストのその後の更新は、展開されたS3バケットに新しいリストをアップロードすることで行うことができます。本ソリューションは、新しいリストがアップロードされるたびに、本ソリューションが管理する既存のドメインリストにドメインを追加または削除します。

このソリューションでは、ルールグループをAmazon VPCまたはNetwork Firewallに関連付けることはできないので、このステップを完了する必要があります。ソリューションのアーキテクチャは、次の図のとおりです。

図 1 – アーキテクチャ図

ソリューションの仕組みの概要は次のとおりです。

GitHub リポジトリにある CloudFormation テンプレートをデプロイします。
CloudFormation によって作成された S3 バケットにファイルをアップロードします。このファイルは、行ごとに 1 つの一意のドメインで管理するドメインリストです。
ドメインリストがアップロードされた後、S3 イベントは、ルール、ルールグループ、およびドメインリストを管理する Lambda 関数を呼び出します。
DNS Firewallの場合、Lambda 関数は Amazon S3 からドメインリストを取得し、DNS Firewallドメインリストを更新します。
Amazon Network Firewall の場合、Lambda 関数は Amazon S3 からドメインリストを取得し、Firewallルールを更新します。

前提条件

この記事に従うには、次の前提条件が必要です。

既存のAWS アカウント
CloudFormation がリソースをデプロイできるようにする IAM ロール
行ごとに 1 つのドメインを含むドメインのリスト。ドメインのワイルドカードは、*.example.com の形式でサポートされています。
Route 53 リゾルバーエンドポイント
DNS Firewall アソシエーション用の VPC
Network Firewall
このソリューションの CloudFormation テンプレートは、GitHub リポジトリにあります。

CloudFormation スタックの起動

まず、CloudFormation スタックを起動します。

AWS マネジメントコンソールでAWS CloudFormationに移動します。
[Create Stack]を選択し、[With new resources] (標準) を選択します。
[Create Stack] ページの [Specify template] で、[Upload a template file] テンプレートソースを選択します。
[Choose file]を選択し、前提条件の手順でダウンロードしたテンプレートを見つけます。
[Next]を選択して続行します。
[Specify Stack Details] ページで、スタックに「 MyStackName 」などの名前を付けます。
パラメータ画面で既定のパラメーターを確認し、必要なパラメーターを入力します。
BUCKETNAME、R53_RULE_TYPE、 ANFW_RULE_TYPE、 ANFW_RULE_GROUP_CAPACITY
- CloudFormation をデプロイするときに、構成されたドメインリストがNetwork Firewallと DNS Firewallの両方のトラフィックを許可するか拒否するかを選択します。
- CloudFormation スタックにはいくつかのパラメーターがあります。
  - BUCKETNAME – 作成する S3 バケットの名前
  - R53_RULE_TYPE – これは、ドメインリストに適用される DNS Firewallルールアクションのタイプです。これは、ALLOW、DENY、または ALERT のタイプである必要があります。DENY アクションでは、DENY ACTION パラメータを構成する必要があります。
  - ANFW_RULE_TYPE – これは、ドメインリストに適用されるステートフルファイアウォールルールアクションのタイプです。タイプは ALLOWLIST または DENYLIST でなければなりません。
  - ANFW_RULE_GROUP_CAPACITY – これは、Amazon Network Firewall ルールグループに対して定義された容量です。これは、作成後に変更することはできません。容量単位の計算については、こちらを参照してください。
[Configure stack options] ページで、タグを追加するか、追加のオプションを選択するか、単に [ Next]を選択するかを選択できます。
確認ページで、パラメーターを検証し、IAM リソースが作成されることを確認します。最後に、Create stackを選択します。
[Create stack]を選択すると、プロセスに従い、 CloudFormation スタックの[Events]タブからデプロイのステータスを表示できます。デプロイが完了したら、次のステップに進みます。

ルールグループの関連付け

このソリューションは、作成したルールグループをNetwork Firewallまたは VPC に関連付けないため、Network FirewallルールグループをNetwork Firewallポリシーに、DNS FirewallルールグループをVPC に手動で関連付ける必要があります。

デプロイされたリソースを確認する

CloudFormation を介してルール、ルールグループ、およびドメインリストをデプロイしたので、コンソールでそれらを確認できます。Network Firewallコンソールでは、Network Firewallルールグループとドメインリストを含むステートフルルールを確認できます。

図 2 – インポートされたドメインを含むNetwork Firewallドメインリスト

DNS Firewallコンソールで、管理されたルールグループ、ルール、およびドメインリストを確認できるようになりました。

図 3 – インポートされたドメインを含む Route53 Resolver DNS Firewallドメインリスト

Lambda 呼び出しごとにAmazon CloudWatch Logsを確認することで、各サービスのドメインリストにインポートされたドメインを確認できます。

図 4 – 正常にインポートされたドメインと除外されたドメインを示す CloudWatch Logs

図 4を見ると、このソリューションでは、不適切な形式のドメイン名や、正しいワイルドカード形式を使用していないドメイン名が破棄されることがわかります。このソリューションは、処理されてドメインリストにインポートされた有効なドメインの数と、破棄された無効なドメインの数を記録します。

ソリューションのテスト

ソリューションがデプロイされ、Network Firewallポリシーと VPC に関連付けられたルールグループを使用して、ソリューションが機能することをテストできます。
このソリューションをテストするには、Network Firewallと DNS Firewallによって保護されたAmazon Elastic Compute Cloud (Amazon EC2) インスタンスから、拒否リスト内のドメインに対して dig および curl コマンドを実行しました。

DNS ファイアウォールとNetwork Firewallのブロックリストが構成され、関連付けられている場合、dig は空の DNS 応答を返し、curl がタイムアウトします。
次のように、curl を介してNetwork Firewallをテストすることもできます。
ドメインリストの展開前にcurl -I https://example.com実行すると有効な応答が返されます。展開後、クライアントがTLS接続を試みているのがわかりますが、ホストヘッダを検査した後、Network Firewallによってドロップされるため、完了することはありません。この場合、ローカルDNSキャッシュをまだクリアしていないため、クライアントはDNSを解決することができます。

図 5 – Network Firewallを介した Curl テストの成功例

図 6 – Route 53 からの Dig レスポンスの成功例

図 7 – ドメイン拒否リストの展開後に TLS ハンドシェイクが失敗したことを示すcurlレスポンスの詳細

図 8 – ドメイン拒否リストを展開した後の空の DNS 応答を示す dig テスト

次のように、dig を使用して DNS Firewall構成をテストできます。
dig example.com +shortを実行すると、ドメインdenylistを展開する前に有効なDNS応答が返されます。ドメイン拒否リストを展開し、ローカルDNSキャッシュをクリアした後、dig example.com +shortは回答を返しません。DENY_ACTIONパラメータをNXDOMAINに設定してソリューションを展開した場合、応答はNXDOMAINとなります。

クリーンアップ

今後の課金を避けるため、作成したS3バケットからドメインリストを削除し、その後、CloudFormationスタックを削除して作成したリソースを削除してください。プロビジョニングされたCloudFormationスタックの削除は、CloudFormation コンソールのドキュメントまたは（AWS CLI）の手順で行うことができます。CloudFormationスタックによって作成されたリソースを削除するには、手動でルールグループの関連付けを解除し、CloudFormationによって作成されたAmazon S3バケットを空にする必要があります。

まとめ

この記事では、Network FirewallとDNS Firewallで使用できるドメインリストの作成と更新を自動化および集中化するソリューションを提供しました。このソリューションにより、単一のドメインリストを両方のサービスで簡単に使用できるようになり、VPCワークロードの「多層防御」戦略をサポートすることができます。また、指定したドメインに対してのみアウトバウンドトラフィックとDNSクエリーを許可する「allowlists」を作成することで、より厳格な「walled-garden」アプローチを取ることもできます。

詳細については、Network Firewall開発者ガイドおよび DNS Firewall開発者ガイドを参照してください。また、 GitHub リポジトリでソリューションのクローンを作成したり、ソリューションに貢献したりすることもできます。

この記事は「Centralizing Domain List Management for AWS Network Firewall and Route 53 Resolver DNS Firewall」の日本語訳です。
プロフェッショナルサービス本部インフラストラクチャアーキテクトの大谷真広、大木和田留が翻訳しました。

Amazon Web Services ブログ