Amazon Web Services ブログ

Protective DNS サービスを活用した AWS ワークロードのセキュリティ強化

本ブログは 2024 年 4 月 24 日に公開されたBlog “Using Protective DNS services with AWS workloads” を翻訳したものです。

Protective DNS サービス (一般的に PDNS として知られています) は、インフラストラクチャのセキュリティを基礎から強化したい場合は最適なソリューションです。トラフィックのフィルタリングに、ソフトウェアベースのエージェントやデバイスを使用する従来の方法とは異なり、PDNS サービスは独自のアプローチを採用しています。ユーザーが行う DNS リクエストを詳しく分析し、サービス内で事前に定義されたルールに基づいて応答を制御します。

このプロアクティブな戦略は、ネットワークを基礎レベルで保護するだけでなく、潜在的な攻撃者が、最初の攻撃の足がかりを作る機会を防ぐこともできます。さらに、PDNS サービスは DNS トラフィックをリアルタイムで可視化し、セキュリティ脅威の迅速な特定と対応を可能にします。このブログでは、PDNS サービスと Amazon Web Services (AWS) クラウドのワークロードとのシームレスな統合を解説し、クラウド環境内でのサイバーセキュリティ強化における PDNS サービスの有効性を解説します。

PDNS サービスの仕組み

公共部門や、セキュリティ要件が高い業種では、重要なワークロードやデバイスが容易に侵害されないことを確認する必要がある場合があります。ワークロードが、DNS 名を解決できないようにして悪意のあるウェブサイトへのリクエストを防ぐことは、重要な防御手段です。

例えば、PDNS サービスはボットネットの脅威を軽減することができます。ボットネットは多くの場合、指示を受け取り結果を報告するために、コマンド&コントロール インフラストラクチャに接続する必要があります。さらに、次のターゲットとなるホストを見つけ、コントロールインフラストラクチャに報告し、新しい指示を待ち、ネットワーク上で拡散しようとすることもよくあります。したがって、ボットネットの動作は単一の特定のホストに限定されず、攻撃範囲が広いため、感染がより深刻な問題となります。ボットネット攻撃の影響は、コントロールインフラストラクチャへのアクセスを制限することで、大幅に軽減できます。さらに、悪意のある第三者へのデータ流出を試みる攻撃を阻止することもできます。

PDNS サービスは DNS レスポンスを変更するため、通常その動作はレスポンスポリシーゾーン (RPZ) を使用して設定されます。RPZ は、DNS サーバーの名前解決機能と連携して動作するポリシーです。RPZ ポリシーは通常、信頼できるソースから受け取った脅威インテリジェンス情報に合わせて定期的に更新されます。脅威インテリジェンス情報は、既存のネットワークや公開・商用ソースから収集することができます。RPZ ポリシーは、Berkeley Internet Name Domain (BIND) DNS ゾーンと同じ形式で記述されます

クライアントが DNS リクエストを行うと、そのリクエストは PDNS サービスに転送されます。PDNS サービスは、RPZ ポリシー内でリクエストされたドメインを検索し、ポリシーの設定に従って応答します。PDNS サービスは、設定に応じて次のような動作があります。

  1. クライアントに、ドメインのアドレス解決ができなかったことを示す NXDOMAIN 応答 (RFC8020 で定義) を返します。
  2. 通常の DNS リゾルバーが返すアドレスとは異なるアドレスで応答します。これにより、組織は例えば、クライアントにWebページを表示させ、セキュリティ上の問題が発生したことと、サポートを受ける方法を説明することができます。
  3. カスタムレスポンスで応答し、応答をログに記録し、セキュリティ運用チームにそのような応答がされたことを通知できます。これにより、チームは問題を調査することができます。さらに、カスタムレスポンスは脅威が継続している間では特に有用で、セキュリティ運用チームがネットワーク上のクライアントに不必要な悪影響を与えることなく、リアルタイムで問題を調査することができます。

PDNS サービスは、官民問わず世界中の様々な組織によって提供されています。例として、Cisco UmbrellaVercara UltraDDR米国国家安全保障局 (NSA) サイバーセキュリティ協力センター (CCC) の Protective DNS サービス、そして 英国国家サイバーセキュリティセンター (NCSC) の Protective DNS サービス などがあります。

PDNS サービスの一部のプロバイダーは、既知の脅威リストだけでなく、新規の疑わしいドメイン名を自動的に判別するなどの追加機能を提供しています。脅威インテリジェンスの情報源の幅広さに加えて、これらの機能が PDNS サービス間の差別化要因となっています。PDNS サービスの利用を検討している場合は、可能な限り、複数サービスを相互に比較検討すると良いでしょう。

AWS の PDNS 機能を実装する場合は AWS Network Firewall または Amazon Route 53 Resolver DNS Firewall をご利用をできますが、次のセクションでは、AWS ワークロードに対して、サードパーティの PDNS サービスを実装するアーキテクチャの例を示します。

PDNS サービスによる AWS ワークロードの保護

Network Firewall と Route 53 DNS Firewall は、PDNS サービスを構築する際の優れた選択肢です。しかし、サードパーティの PDNS サービスが提供する追加の必須機能が必要な場合があります。サードパーティの PDNS サービスが提供する包括的な脅威インテリジェンスへのアクセスが必要な時などです。この例では、図 1 のようなアプローチを用いて、Amazon Route 53 Resolver で外部の PDNS サービスにトラフィックを誘導することができます。

図 1. Amazon Virtual Private Cloud (VPC) とプライベート DNS (PDNS) サービスを統合するアーキテクチャの例。主要なコンポーネントは、VPC、Route 53 Resolver、そしてオプションとして Route 53 Resolver DNS Firewall です。

前述のアーキテクチャは、プライベートサブネットで実行されているアプリケーションが Amazon Route 53 Resolver アウトバウンドエンドポイントとどのようにやり取りするかを示しています。

  1. アプリケーションをホストするプライベートサブネットには、ネットワーク ACL (NACL) が設置されており、サブネットレベルで特定のインバウンドまたはアウトバウンドトラフィックを許可または拒否します。
  2. トラフィックが NACL によってブロックされない場合、パブリックサブネットの NAT Gateway に転送されます。
  3. NAT Gateway は、トラフィックを Route 53 Resolver DNS Firewall に送信します。ポリシーに従い、トラフィックをフィルタリングし、アウトバウンド DNS トラフィック を制御します。
  4. Route 53 Resolver DNS Firewall は、トラフィックを Route 53 Resolver アウトバウンドエンドポイントに転送します。
  5. トラフィックが Route 53 Resolver に到達すると、可観測性のためにログ記録が行われます。Route 53 Resolver クエリログにより、VPC 内の DNS クエリのインサイトが得られ、コンプライアンス、脅威検出、トラブルシューティングの目的に役立ちます。ログは Amazon CloudWatch Logs に送信され、そこから Amazon CloudWatch Log Insights を使用してさらなる分析を行い、メトリクスやアラームを作成することができます。
  6. 最後に、リクエストは PDNS サービスに転送され、PDNS サービスはクライアントのリクエストに応答する責任を負い、独自のルールと脅威インテリジェンスを使用して適切に応答します。

この設計を実装すると、リゾルバルールが適用された VPC で実行されるワークロードが保護されます。この設計により、外部アドレス(VPC 内のリソースや AWS サービスに解決されないアドレスなど) の名前解決を、複数の VPC にわたって信頼できるリゾルバーで行えるようにスケールします。クロスアカウントネットワーキングを適切に考慮すれば、トランジットゲートウェイを通じて実装することで、複数のアカウントから PDNS サービスへの中央集中型アクセスを提供することも可能です。

多くの場合、サードパーティの PDNS サービスを使用する場合、ルールを修正することで PDNS サービスの応答方法を設定することもできます。これにより、自前でサービスを運用する場合と比べて比類のない柔軟性が提供されます。PDNS サービスがそのような機能を提供している場合、信頼できる脅威インテリジェンスに裏打ちされたソースを利用しながら、カスタムの動作を定義することができます。

まとめ

規制対象の業界や、セキュリティ要件が高い組織では、重要なワークロードが DNS ベースの攻撃の容易な標的にならないように、DNSリクエストを確実に制御する必要があります。重要なワークロードをサポートするインフラストラクチャが行う DNS リクエストの可視性を得ることで、セキュリティチームはアプリケーションの動作をリアルタイムで把握でき、異常を発見するのに役立ちます。Route 53 DNS Firewall や Network Firewall などのサービス、あるいはサードパーティのソリューションを使用して Protective DNS 機能を提供することで、組織はボットネットやデータ漏洩などの脅威を軽減できます。

このサンプルアーキテクチャは、VPC 間の保護を確保するだけでなく、包括的なロギングを通じてコンプライアンス遵守と脅威検出を可能にし、CloudWatch や既存のセキュリティツールなどのサービスを使用した将来の分析を可能にします。

AWS ワークロードを Protective DNS サービスと統合することで、高度なセキュリティ要件を持つ組織は、追加のインフラストラクチャを管理する負担なく、DNS ベースの攻撃から保護する信頼性の高い手段を得ることができます。PDNS サービスと AWS ワークロードの統合は、進化するサイバー脅威に対するクラウドのレジリエンスを強化し、重要なワークロードのための安全な環境を確保します。

Amazon Route 53 Resolver を使用して、ワークロードに対する DNS ベースの攻撃の軽減にすぐに取り組むことができます

Awzair Chaudhrey

Awzair Chaudhrey

Awzair は Amazon Web Services (AWS) のパブリックセクターでソリューションアーキテクトとして従事しています。彼はセキュリティとネットワーキングに強い情熱を持ち、顧客がクラウドへの移行の過程でベストプラクティスに従えるよう支援しています。仕事以外の時間は、読書や家族と過ごすことを楽しんでいます。

Andrew Langhorn

Andrew Langhorn

Andrew は、AWSでプリンシパルソリューションアーキテクトとしてパブリックセクターの顧客と協力しています。仕事以外では、レコード・コレクションを充実させたり、ウィスキーの知識を深めたり、定期的に新しい都市や国を訪れるのが好きです。

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