Amazon Route 53 Resolver DNS Firewall によるハイブリッドワークロードの保護

本ブログは 2025 年 8 月 18 日に公開された AWS Blog “Securing hybrid workloads using Amazon Route 53 Resolver DNS Firewall” を翻訳したものです。

2021 年のリリース以来、Amazon Route 53 Resolver DNS Firewall により、Amazon Web Services (AWS) のユーザーは、Amazon Virtual Private Cloud (Amazon VPC) リソースから発信されるアウトバウンド DNS クエリのモニタリングと制御ができるようになりました。Route 53 Resolver DNS Firewall でドメインフィルタリングルールを設定すると、さまざまなセキュリティ脅威を軽減できます。例えば、DNS トンネリングによるデータ流出、フィッシングやマルウェア配布に使用される悪意のあるドメインへのアクセス、承認されていない宛先やコンプライアンスに準拠していない宛先への意図しない接続などです。さらに、AWS Firewall Manager を使用すると、AWS Organizations の組織内の複数の VPC とアカウントにわたって、Route 53 Resolver DNS Firewall ルールを一元的かつ大規模に設定、管理できます。では、ハイブリッド AWS 環境のオンプレミスワークロードにも DNS 保護の範囲を広げたい場合は、どうすればよいでしょうか？この記事では、AWS DNS Firewall による保護をオンプレミスワークロードに拡張し、ハイブリッド AWS 環境全体で統一的で一貫したセキュリティポリシーを実現する方法を紹介します。単一の統合された DNS フィルタリングソリューションによって、セキュリティポスチャを強化し、コンプライアンスを維持しながら、運用上のオーバーヘッドを削減する方法を説明します。

ハイブリッド AWS 環境向けに DNS 保護の範囲を拡張する

Route 53 Resolver DNS Firewall を設定して AWS ワークロードを保護し、組織のセキュリティポリシーに基づいて DNS クエリをフィルタリングできるようになったら、この保護をハイブリッド AWS 環境に拡張できます。そのためには、オンプレミスの DNS サーバーを設定し、直接管理していないすべてのドメインに対する DNS クエリを Amazon Route 53 Resolver のインバウンドエンドポイントに転送する必要があります。DNS クエリの転送経路には、パブリックインターネットを経由する方法と、Route 53 Resolver インバウンドエンドポイントを含む VPC へのプライベートネットワーク接続を経由する方法があります。以下のセクションでは、これら 2 つの接続オプションについて詳しく説明します。

AWS Direct Connect または AWS Site-to-Site VPN を介したプライベート接続

オンプレミス環境と AWS の間でプライベート接続を利用できる場合は、プライベートネットワーク接続を介して DNS クエリを安全に転送するように設定できます。オンプレミスの DNS サーバーは、AWS Direct Connect または AWS Site-to-Site VPN を介して、DNS クエリを Route 53 Resolver インバウンドエンドポイントに転送します。この通信チャネルのセキュリティをさらに強化するために、Direct Connect と Site-to-Site VPN を組み合わせたり、Direct Connect 接続で MAC Security を有効にしたりするなど、追加の対策を講じることもできます。

図 1: Site-to-Site VPN または Direct Connect を介した安全な DNS クエリ

図 1 は、Direct Connect または Site-to-Site VPN を介した安全な DNS クエリのフローを示しています。

1. 企業のワークステーションが、データセンター内の社内 DNS サーバーに DNS クエリを送信します。
2. 社内 DNS サーバーが、AWS の Route 53 Resolver インバウンドエンドポイントに DNS クエリを転送します。
3. DNS クエリは、Direct Connect または Site-to-Site VPN を介して、カスタマーゲートウェイと AWS の仮想プライベートゲートウェイを経由してルーティングされます。
4. 必要な DNS プロトコル標準に準拠した Route 53 Resolver インバウンドエンドポイントが、DNS クエリを受信します。
5. Route 53 Resolver DNS Firewall のルールによって、DNS クエリを許可するかブロックするかが判断され、疑わしいドメインへのクエリがログに記録されます。
6. Route 53 Resolver DNS Firewall によってクエリがブロックされなかった場合は、Route 53 Resolver が DNS クエリを処理します。Amazon Route 53 プライベートホストゾーン (PHZ) 内のドメインであれば、リゾルバーは設定済みの PHZ を使用してクエリを直接処理します。外部ドメインであれば、リゾルバーはクエリを外部のネームサーバーに転送して応答を取得します。その後、応答は同じ経路を逆にたどってクライアントに返されます。

インターネット向け AWS Network Load Balancer を介したパブリック接続

プライベート接続を利用できない場合は、インターネット向けの AWS Network Load Balancer (NLB) を介して、DNS クエリを Route 53 Resolver インバウンドエンドポイントにルーティングできます。NLB はオンプレミスの DNS サーバーからの DNS クエリをインバウンドエンドポイントに転送します。このとき、イングレストラフィックは NLB のセキュリティグループによる送信元 IP 制限で保護されます。NLB は、一般的な DDoS 攻撃に対する保護機能を標準で備えています。保護をさらに強化したい場合は、NLB リソースに対して AWS Shield Advanced を有効にできます。

図 2: パブリックインターネットを介した安全な DNS クエリ

図 2 は、インターネット向け NLB を介した安全な DNS クエリのフローを示しています。

1. 企業のワークステーションが、データセンター内の社内 DNS サーバーに DNS クエリを送信します (プライベート接続のフローと同じ)。
2. 社内 DNS サーバーが、インターネット向け NLB のパブリック IP アドレスに DNS クエリを転送します。
3. DNS クエリは、パブリックインターネットを介して、お客様側のルーターのネットワークアドレス変換 (NAT) IP アドレスとインターネットゲートウェイ (IGW) を経由してルーティングされます。
4. インターネット向け NLB は DNS クエリを受信し、Route 53 Resolver インバウンドエンドポイントの Elastic Network Interface (ENI) のいずれかにルーティングします。これらの ENI は、それぞれ異なる AWS アベイラビリティーゾーン (AZ) のプライベートサブネットに配置されており、NLB のターゲットグループ内の IP ターゲット (UDP/TCP ポート 53) として設定されています。あるいは、DNS over HTTPS (DoH) を使用するようにソリューションを設定し、ウェブベースのセキュリティコントロールを提供することもできます。
5. 必要な DNS プロトコル標準に準拠した Route 53 Resolver インバウンドエンドポイントが、DNS クエリを受信します (プライベート接続のフローと同じ)。
6. Route 53 Resolver DNS Firewall のルールによって、DNS クエリを許可するかブロックするかが判断され、疑わしいドメインへのクエリがログに記録されます (プライベート接続のフローと同じ)。
7. Route 53 Resolver DNS Firewall によってクエリがブロックされなかった場合は、Route 53 Resolver が DNS クエリを解決し、同じ経路を逆にたどってクライアントに応答を返します (プライベート接続のフローと同じ)。

ハイブリッド DNS 保護ソリューションの設計上の考慮事項

ハイブリッド DNS 保護ソリューションを設計する際は、さまざまなアーキテクチャ上の判断に直面します。これらの判断では、設計の各側面で相反する優先事項のバランスを取る必要があります。

ソリューションは、DNS クエリの量に応じて効率的にスケールする必要があります。NLB は、1 秒あたり数千万件のリクエストを超低レイテンシーで処理できます。Route 53 Resolver エンドポイントには、サービスクォータに留意しつつ、オンプレミスの DNS クエリの量に応じて適切な数の ENI を設定する必要があります。また、DNS クエリのパフォーマンスは、クエリタイプ、応答サイズ、ターゲットネームサーバーの正常性、クエリ応答時間、ラウンドトリップレイテンシー、使用するプロトコルなどの要因によって変わります。

高可用性については、まずワークロードの要件を評価します。ミッションクリティカルなオンプレミスワークロードが外部依存関係の追加を許容できない場合は、ハイブリッド DNS 保護の対象をエンドユーザーデバイスに限定する必要が生じることもあります。NLB と Route 53 Resolver エンドポイントの ENI を複数の AZ に分散させるとともに、Site-to-Site VPN または Direct Connect 接続を冗長化します。障害発生時の Route 53 Resolver DNS Firewall の動作は、障害モードによって決まります。デフォルトでは、クエリを評価できない場合にそのクエリをブロックします。可用性に関する具体的な要件とリスク評価の結果によっては、この設定の調整が必要になる場合があります。パブリック接続を選択する場合は、DDoS 保護を強化するために AWS Shield Advanced の有効化を検討してください。その際は、追加コストと可用性要件を比較して判断します。Route 53 Resolver エンドポイントの高可用性の詳細については、「How to achieve DNS high availability with Route 53 Resolver endpoints」を参照してください。

パフォーマンス要件は、ユーザーや拠点の地理的な分布に大きく左右されます。グローバルに分散したユーザーや遠隔地の拠点がある場合は、AWS Global Accelerator を使用すると DNS 解決のパフォーマンスを向上できます (パブリック接続オプションについては、「Use AWS Global Accelerator to improve application performance」を参照してください)。また、Site-to-Site VPN Accelerator は VPN 接続のレイテンシーの削減に役立ちます。NLB でセキュリティグループを使用する場合は、接続が自動的に追跡される点に注意してください (「Amazon EC2 セキュリティグループの接続追跡」)。接続追跡によって、IP アドレスごとの 1 秒あたりの最大クエリ数が減少する可能性があります (「Route 53 Resolver エンドポイントのクォータ」)。このパフォーマンスへの影響は、セキュリティ要件と照らし合わせて評価する必要があります。DNS プロトコルの選択 (UDP、TCP、または DoH) も、クエリのパフォーマンスとスループットに影響します。オンプレミスの DNS サーバーでは、DNS キャッシュと TTL 値を調整し、クエリ応答時間とデータの鮮度のバランスを取ってください。

セキュリティ対策は、脅威モデルに基づいて実装します。NLB でセキュリティグループを使用すると、送信元 IP 制限によってイングレストラフィックを保護し、承認されたオンプレミス DNS サーバーからの DNS クエリのみを受け付けるようにできます。ただし、この構成では接続追跡が自動的に有効になり、DNS クエリのスループットに影響します。パフォーマンス要件を満たすためにより高いスループットが必要であり、かつリスク評価の結果から許容できると判断した場合は、緩和策の 1 つとして、セキュリティグループを使用せずに NLB を運用する方法があります。この場合は、サブネットレベルの補完的なコントロールとして VPC のネットワーク ACL (「Amazon VPC – ネットワークアクセスコントロールリストを使用して、サブネットのトラフィックを制御する」) を実装し、送信元 IP アドレスを制限します。

DNS セキュリティコントロールにもトレードオフがあり、バランスを取る必要があります。パブリック DNS クエリを DNS スプーフィングから保護するために、運用上のオーバーヘッドも考慮したうえで、DNSSEC 検証の導入を検討するとよいでしょう (「Amazon Route 53 での DNSSEC 検証の有効化」)。

DNS プロトコルの選択も、セキュリティとパフォーマンスのトレードオフの 1 つです。選択肢は、基本的な機能を提供する UDP から、暗号化された DoH まであります。

さらに、可用性とセキュリティのどちらを優先するかという点では、Route 53 Resolver DNS Firewall の障害モード設定も重要な判断事項です。デフォルトのフェイルクローズ設定では、クエリを評価できない場合にそのクエリがブロックされます。これはセキュリティを重視した設定であるため、可用性要件とのバランスを考慮する必要があります。

これらのアーキテクチャ上の考慮事項を踏まえることで、ハイブリッド DNS 保護ソリューションの実装時に、スケーラビリティ、高可用性、パフォーマンス、セキュリティに関する固有の要件のバランスを取ることができます。

ハイブリッド DNS 保護を大規模に管理する

図 3 に示すように、AWS Security Hub、Firewall Manager、Route 53 Resolver DNS Firewall を使用すると、アカウントをまたいで複数の VPC が存在するマルチアカウント AWS 環境で、DNS クエリの保護を一元的かつ一貫した方法で大規模に管理、統制できます。このソリューションの主な特徴は次のとおりです。

• 必要なすべてのセキュリティポリシーを含む DNS Firewall ルールグループが、Security Tooling/Audit アカウントで作成されます。
• Firewall Manager のセキュリティポリシーにより、複数の AWS アカウントにわたる VPC 全体に DNS Firewall ルールグループを一元的に配布、適用できます。
• Security Hub は、DNS Firewall ポリシーのコンプライアンスに関する Firewall Manager の検出結果など、さまざまなソースからの検出結果を統合し、セキュリティポスチャを一元的に可視化します。Firewall Manager ポリシーで定義されている DNS Firewall ルールグループが VPC に関連付けられていない場合、Security Hub はこれをセキュリティの検出結果として表示します。これにより、組織全体における DNS 保護の不備を一元的に把握できます。
• ワークロード VPC 内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスなどの AWS リソースからの DNS クエリは VPC+2 IP アドレスにルーティングされ、そこで Route 53 Resolver が、VPC に関連付けられている DNS Firewall ルールグループを適用します。
• オンプレミスの DNS クエリは、NLB を使用するパブリックインターネット接続、または Direct Connect や Site-to-Site VPN を使用するプライベート接続を介して、ハイブリッド DNS 保護アカウントの VPC にあるインバウンドエンドポイントにルーティングされます。ここで Route 53 Resolver が同じ DNS Firewall ルールグループを適用します。

図 3: マルチアカウント環境におけるオンプレミスと VPC の DNS クエリの保護

まとめ

この記事では、Amazon Route 53 Resolver DNS Firewall による保護を AWS 環境の外部へ拡張し、ハイブリッドインフラストラクチャ全体で統一された DNS セキュリティ戦略を構築する方法を紹介しました。プライベート接続 (AWS Direct Connect または AWS Site-to-Site VPN を使用) とパブリック接続 (AWS Network Load Balancer を使用) のどちらを選択しても、運用効率を維持しながら、ネットワーク全体で一貫した DNS フィルタリングポリシーを適用できます。

ここで紹介したアーキテクチャには、戦略的なメリットが複数あります。具体的には、AWS Firewall Manager による DNS Firewall の一元管理、AWS とオンプレミスのワークロード全体での一貫したポリシーの適用、柔軟な接続オプション、マルチアカウント AWS 環境に対応するエンタープライズグレードのスケーラビリティです。DNS ベースの脅威がますます巧妙化する中、このハイブリッド DNS 保護ソリューションは、DNS トンネリング、ドメイン生成アルゴリズム、その他の DNS ベースの攻撃に対する組織の防御力の強化に役立ちます。ここで説明したアーキテクチャ上の考慮事項に従うことで、可用性、パフォーマンス、セキュリティに関する固有の要件に沿った堅牢な DNS セキュリティフレームワークを構築し、ハイブリッドインフラストラクチャのセキュリティポスチャを強化できます。

ご質問がある場合は、Amazon Route 53 Resolver DNS Firewall re:Post で新しいスレッドを作成するか、AWS サポートにお問い合わせください。

著者について

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。