翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
インフラストラクチャ OU — ネットワークアカウント
| 簡単な調査を行い、 AWS セキュリティリファレンスアーキテクチャ (AWS SRA) の未来に影響を与えます。 https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua |
以下の図表は、Network アカウントで設定されている AWS セキュリティサービスを示しています。
Network アカウントは、アプリケーションとより広範なインターネット間のゲートウェイを管理しています。その双方向インターフェイスを保護することが重要です。Network アカウントは、個々のアプリケーションワークロード、セキュリティ、およびその他のインフラストラクチャからネットワークサービス、構成、およびオペレーションを分離します。この配置は、接続性、権限、およびデータフローを制限するだけでなく、これらのアカウントで運用する必要があるチームの職務分離と最小権限もサポートします。ネットワークフローを個別のインバウンドとアウトバウンドの仮想プライベートクラウド（VPC）に分割することで、機密性の高いインフラストラクチャとトラフィックを不用意なアクセスから保護できます。インバウンドネットワークは一般的に高いリスクと考えられ、適切なルーティング、モニタリング、および潜在的な問題の軽減が必要です。これらのインフラストラクチャアカウントは、Org Management アカウントとインフラストラクチャ OU から権限ガードレールを継承します。ネットワーキング (およびセキュリティ) チームは、このアカウントのインフラストラクチャの大部分を管理します。
ネットワークアーキテクチャ
ネットワーク設計と詳細はこのドキュメントの範囲外ですが、さまざまなアカウント間のネットワーク接続には、VPC ピアリング、AWS PrivateLink、および AWS Transit Gateway の 3 つのオプションをお勧めします。これらの中から選択する際の重要な考慮事項は、運用規範、予算、および特定の帯域幅のニーズです。
-
VPC ピアリング — 2 つの VPC を接続する最も簡単な方法は、VPC ピアリングを使用することです。接続することで、VPC 間の完全な双方向接続が可能になります。別のアカウントや AWS リージョンにある VPC を相互にピアリングすることもできます。スケールでは、数十から数百の VPC がある場合、それらをピアリングと相互接続すると、数百から数千のピアリング接続のメッシュとなり、管理やスケールが困難になる可能性があります。VPC ピアリングは、ある VPC のリソースが別の VPC のリソースと通信する必要があり、両方の VPC の環境が制御およびセキュリティで保護され、接続する VPC の数が 10 未満の場合（各接続の個別の管理を可能にする）に最適です。
-
AWS PrivateLink
PrivateLink‒ はVPCs、サービス、アプリケーション間のプライベート接続を提供します。VPC に独自のアプリケーションを作成し、それを PrivateLinkを使用したサービス (エンドポイントサービス と呼ばれる) として設定できます。他の AWS プリンシパルは、サービスのタイプに応じて、インターフェイス VPC エンドポイント または Gateway Load Balancer エンドポイント を使用して、VPC からエンドポイントサービスへの接続を作成できます。を使用する場合 PrivateLink、サービストラフィックはパブリックにルーティング可能なネットワークを経由しません。1 つ以上のコンシューマー VPCs に、サービスプロバイダー VPC 内の特定のサービスまたはインスタンスセットへの一方向アクセスを許可するクライアント/サーバー設定 PrivateLink がある場合に使用します。これは、2 つの VPCsがある場合にも適しています。これは、 がクライアント VPC 内の Elastic Network Interface PrivateLink を使用して、サービスプロバイダーと IP 競合が発生しないためです。 -
AWS Transit Gateway
‒ Transit Gateway は、仮想アプライアンスVPCsプロビジョニングすることなく、VPC とオンプレミスネットワークをフルマネージドサービスとして接続する hub-and-spoke 設計を提供します。AWS は高可用性とスケーラビリティを管理します。トランジットゲートウェイはリージョナルリソースであり、同じ AWS リージョン内の数千の VPC を接続できます。ハイブリッド接続 (VPN と AWS Direct Connect 接続) を、単一のトランジットゲートウェイにアタッチすることで、AWS 組織のルーティング構成全体を 1 か所に集約し制御することができます。Transit gateway は、複数の VPC ピアリング接続を大規模に作成および管理する際の複雑さを解決します。これは、ほとんどのネットワークアーキテクチャではデフォルトですが、コスト、帯域幅、レイテンシーに関する特定のニーズでは、VPC ピアリングがより適切かもしれません。
インバウンド (受信) VPC
インバウンド VPC は、アプリケーションの外部で開始されたネットワーク接続を受け入れ、検査、ルーティングすることを目的としています。アプリケーションの特性にもよりますが、この VPC ではネットワークアドレス変換 (NAT) が行われることが期待できます。この VPC からのフローログはキャプチャされ、Log Archive アカウントに保存されます。
アウトバウンド (送信) VPC
アウトバウンド VPC は、アプリケーション内から開始されたネットワーク接続を処理することを目的としています。アプリケーションの特性に応じて、トラフィック NAT、AWS サービス固有の VPC エンドポイント、およびこの VPC での外部 API エンドポイントのホスティングが見られることが期待できます。この VPC からのフローログはキャプチャされ、Log Archive アカウントに保存されます。
インスペクション VPC
検査専用 VPC は、VPC (同一もしくは異なる AWS リージョン内)、インターネット、オンプレミスネットワーク間の検査を簡素化し、一元管理するためのものです。AWS SRA では、VPC 間のすべてのトラフィックは検査 VPC を経由するようにし、検査 VPC を他のワークロードで使用しないようにしてください。
AWS Network Firewall
AWS Network Firewall
VPC では、アベイラビリティーゾーンごとにファイアウォールを使用します。アベイラビリティーゾーンごとに、トラフィックをフィルタリングするファイアウォールエンドポイントをホストするサブネットを選択します。アベイラビリティーゾーンのファイアウォールエンドポイントは、ゾーンが存在するサブネットを除くゾーン内のすべてのサブネットを保護できます。ユースケースとデプロイメントモデルに応じて、ファイアウォールサブネットはパブリックまたはプライベートのいずれかになります。ファイアウォールは、トラフィックフローに対して完全に透過的であり、NAT を実行しません。送信元と送信先のアドレスが保持されます。このリファレンスアーキテクチャでは、ファイアウォールエンドポイントはインスペクション VPC でホストされています。インバウンド VPC からとアウトバウンド VPC へのすべてのトラフィックは、検査のためにこのファイアウォールサブネットを介してルーティングされます。
Network Firewall は、Amazon CloudWatch メトリクスを通じてファイアウォールアクティビティをリアルタイムで表示し、Amazon Simple Storage Service (Amazon S3) および Amazon Data Firehose にログを送信することで CloudWatch、ネットワークトラフィックの可視性を高めます。Network Firewall は、AWS Partners
AWS SRA では、ネットワークコントロールに重点を置いたサービスの機能がアカウントの意図と一致するため、Network Firewall はネットワークアカウント内で使用されます。
設計上の考慮事項
-
AWS Firewall Manager は、Network Firewall をサポートしているため、組織全体に Network Firewall ルールを集中的に構成し、デプロイすることができます。(詳細については、AWS ドキュメント内の「AWS Network Firewall ポリシー」を参照してください。) Firewall Manager を構成すると、指定したアカウントと VPC に一連のルールを持つファイアウォールが自動的に作成されます。また、パブリックサブネットを含むすべてのアベイラビリティーゾーンの専用サブネットにエンドポイントをデプロイします。同時に、集中的に構成された一連のルールに変更があった場合、デプロイされた Network Firewall ファイヤウォールの下流で自動的に更新されます。
-
Network Firewall には、複数のデプロイモデル
が用意されています。適切なモデルは、ユースケースと要件によって異なります。次に例を示します。 -
Network Firewall を個々の VPC にデプロイする配信型デプロイモデル。
-
中央集中型デプロイモデルで、そこでは Network Firewall が東西 (VPC 間) または南北 (インターネット送信および受信、オンプレミス) のトラフィック用に集中型 VPC にデプロイされます。
-
Network Firewall を東西と南北のトラフィックのサブセット用に中央集中型 VPC にデプロイした複合型デプロイモデル。
-
-
ベストプラクティスとして、Network Firewall サブネットを使用して他のサービスをデプロイしないでください。これは、Network Firewall がファイアウォールサブネット内の送信元または発信先からのトラフィックを検査できないためです。
Network Access Analyzer
Network Access Analyzer は Amazon VPC の機能で、リソースへの意図しないネットワークアクセスを特定します。Network Access Analyzer を使用すると、ネットワークのセグメンテーションを検証し、インターネットからアクセスできるリソースや信頼できる IP アドレス範囲からのみアクセスできるリソースを特定し、すべてのネットワークパスで適切なネットワーク制御が行われていることを検証できます。
Network Access Analyzer は、自動推論アルゴリズムを使用して、パケットが AWS ネットワーク内のリソース間で通過できるネットワークパスを分析し、定義した Network Access Scope に一致するパスの結果を生成します。Network Access Analyzer はネットワーク構成の静的な分析を行います。つまり、この分析の一環としてネットワーク内でパケットが送信されることはありません。
Amazon Inspector Network Reachability ルールが、関連する機能を提供します。これらのルールによって生成された結果は Application アカウントで使用されます。Network Access Analyzer と Network Reachability はどちらも AWS Provable Security イニシアチブ
ネットワークアカウントは、AWS 環境に出入りするトラフィックを制御する重要なネットワークインフラストラクチャを定義します。このトラフィックは厳重に監視する必要があります。AWS SRA では、ネットワークアカウント内で Network Access Analyzer を使用して、意図しないネットワークアクセスを識別し、インターネットゲートウェイ経由でインターネットにアクセスできるリソースを識別し、リソースとインターネットゲートウェイ間のすべてのネットワークパスにネットワークファイアウォールや NAT ゲートウェイなどの適切なネットワーク制御が存在することを確認します。
設計上の考慮事項
-
Network Access Analyzer は Amazon VPC の機能であり、VPC を持つすべての AWS アカウントで使用できます。ネットワーク管理者は、厳しくスコープされたクロスアカウント IAM ロールを取得して、承認されたネットワークパスが各 AWS アカウント内で適用されていることを確認できます。
AWS RAM
AWS Resource Access Manager
AWS RAM を使用すると、VPC サブネットや Route 53 ルールなど、IAM リソースベースのポリシーをサポートしないリソースを共有できます。さらに AWS RAM では、リソースの所有者は、共有した個々のリソースにアクセスできるプリンシパルを確認できます。IAM エンティティは、共有されているリソースのリストを直接取得できますが、IAM リソースポリシーによって共有されているリソースでは取得できません。AWS RAM を使用して AWS Organizations 外のリソースを共有する場合、招待プロセスが開始されます。リソースへのアクセスが許可される前に、受信者は招待を受け入れる必要があります。これにより、追加のチェックとバランスが行われます。
AWS RAM は、共有リソースがデプロイされているアカウントのリソース所有者によって呼び出され、管理されます。AWS SRA で示されている AWS RAM の一般的な使用例の 1 つは、ネットワーク管理者が VPC サブネットとトランジットゲートウェイを AWS Organizations 全体と共有することです。これにより、AWS アカウントとネットワークの管理機能を切り離すことができ、職務の分離が容易になります。VPC 共有の詳細については、AWS ブログ記事の「VPC 共有: 複数のアカウントと VPC 管理への新しいアプローチ
設計上の考慮事項
-
サービスとしての AWS RAM は AWS SRA の Network アカウント内にのみデプロイされますが、通常は複数のアカウントにデプロイされます。例えば、データレイク管理を単一のデータレイクアカウントに一元化し、AWS Lake Formation データカタログリソース (データベースとテーブル) を AWS Organizations 内の他のアカウントと共有できます。詳細については、「AWS Lake Formation ドキュメント」と AWS ブログ記事「AWS Lake Formation を使用して AWS アカウント間でデータを安全に共有する
」を参照してください。さらに、セキュリティ管理者は AWS RAM を使用して、 AWS Private CA 階層を構築する際のベストプラクティスに従うことができます。CA は外部の第三者と共有でき、第三者は CA 階層にアクセスしなくても証明書を発行できます。これにより、発信元の組織は第三者のアクセスを制限したり取り消したりすることができます。
AWS Verified Access
AWS Verified Access
Verified Access は、社内用とインターネット向けの 2 つの一般的な企業アプリケーションパターンをサポートします。Verified Access は、Application Load Balancer またはエラスティックネットワークインターフェースを使用してアプリケーションと統合します。Application Load Balancer を使用している場合、Verified Access には内部ロードバランサーが必要です。Verified Access はインスタンスレベルで AWS WAF をサポートしているため、AWS WAF が Application Load Balancer と統合されている既存のアプリケーションは、ポリシーをロードバランサーから Verified Access インスタンスに移動できます。企業アプリケーションは Verified Access エンドポイントとして表されます。各エンドポイントは Verified Access グループに関連付けられ、グループのアクセスポリシーを継承します。Verified Access グループは、Verified Access エンドポイントとグループレベルの Verified Access ポリシーの集合です。グループはポリシー管理を簡素化し、IT 管理者がベースライン基準を設定できるようにします。アプリケーション所有者は、アプリケーションの機密性に応じて、さらに詳細なポリシーを定義できます。
AWS SRA では、Verified Access は Network アカウント内でホストされます。中央の IT チームが、一元管理された構成を設定します。例えば、ID プロバイダー (Okta など) とデバイストラストプロバイダー (Jamf など) などの信頼プロバイダーを接続し、グループを作成し、グループレベルのポリシーを決定する場合があります。これらの設定は、AWS Resource Access Manager (AWS RAM) を使用することで、数十、数百、数千のワークロードアカウントと共有することができます。これにより、アプリケーションチームは、他のチームによるオーバーヘッドなしに、アプリケーションを管理する基盤となるエンドポイントを管理できます。AWS RAM は、さまざまなワークロードアカウントでホストされている企業アプリケーションに、Verified Access を活用するスケーラブルな方法を提供します。
設計上の考慮事項
-
ポリシー管理を簡素化するために、同様のセキュリティ要件を持つアプリケーションのエンドポイントをグループ化し、そのグループをアプリケーションアカウントと共有できます。グループ内のすべてのアプリケーションはグループポリシーを共有します。エッジケースのためにグループ内のアプリケーションが特定のポリシーを必要とする場合は、そのアプリケーションにアプリケーションレベルのポリシーを適用できます。
Amazon VPC Lattice
Amazon VPC Lattice
VPC Lattice は AWS Resource Access Manager (AWS RAM) と統合して、サービスとサービス ネットワークの共有を可能にします。AWS SRA は、開発者またはサービスオーナーが Application アカウントで VPC Lattice サービスを作成する分散アーキテクチャを示しています。サービスオーナーは、リスナー、ルーティングルール、ターゲットグループを認証ポリシーとともに定義します。次に、サービスを他のアカウントと共有し、そのサービスを VPC Lattice サービスネットワークに関連付けます。これらのネットワークは、ネットワーク管理者が Network アカウントで作成し、Application アカウントと共有します。ネットワーク管理者は、サービスのネットワークレベルの認証ポリシーと監視を設定します。管理者は VPC と VPC Lattice サービスを 1 つ以上のサービスネットワークに関連付けます。この分散アーキテクチャの詳細なウォークスルーについては、AWS ブログ記事「Amazon VPC Lattice を使用してアプリケーション用の安全なマルチアカウントマルチ VPC 接続を構築する
設計上の考慮事項
-
組織のサービス運用モデルやサービスネットワークの可視性に応じて、ネットワーク管理者はサービスネットワークを共有し、サービスオーナーにサービスと VPC をこれらのサービスネットワークに関連付ける権限を与えることができます。また、サービスオーナーはサービスを共有し、ネットワーク管理者はサービスをサービスネットワークに関連付けることができます。
クライアントは、同じサービスネットワークに関連付けられている VPC 内にある場合に限り、サービスネットワークに関連付けられたサービスにリクエストを送信できます。VPC ピアリング接続またはトランジットゲートウェイを通過するクライアントトラフィックは拒否されます。
エッジセキュリティ
エッジセキュリティには通常、安全なコンテンツ配信、ネットワーク層とアプリケーション層の保護、分散型サービス拒否 (DDoS) の緩和という 3 種類の保護が必要です。データ、動画、アプリケーション、API などのコンテンツは、エンドポイント間の通信を暗号化する TLS 推奨バージョンを使用して、迅速かつ安全に配信する必要があります。コンテンツには、署名付き URL、署名付き Cookie、トークン認証によるアクセス制限も必要です。アプリケーションレベルのセキュリティは、ボットトラフィックを制御し、SQL インジェクションやクロスサイトスクリプティング (XSS) などの一般的な攻撃パターンをブロックし、Web トラフィックを可視化するように設計する必要があります。エッジでは、DDoS 対策がミッションクリティカルな事業運営やサービスの継続的な可用性を確保する重要な防御層を提供します。アプリケーションと API を SYN フラッド、UDP フラッド、またはその他のリフレクション攻撃から保護し、基本的なネットワーク層攻撃を阻止するためのインライン緩和を備えている必要があります。
AWS は、コアクラウドから AWS ネットワークのエッジまで、安全な環境を提供するのに役立ついくつかのサービスを提供しています。Amazon CloudFront、AWS Certificate Manager (ACM)、AWS Shield 、AWS WAF 、および Amazon Route 53 は連携して、柔軟で階層化されたセキュリティ境界を作成します。Amazon CloudFrontでは、TLSv1.3 を使用してビューワークライアントと 間の通信を暗号化して保護することで、コンテンツ、APIs、またはアプリケーションを HTTPS 経由で配信できます CloudFront。ACM を使用してカスタム SSL 証明書
Amazon CloudFront
Amazon CloudFront
CloudFront には、コンテンツへのアクセスを保護および制限するための複数のオプションが用意されています。例えば、署名付き URL と署名付き Cookie を使用して、Amazon S3 オリジンへのアクセスを制限できます。詳細については、 ドキュメントの CloudFront「セキュアアクセスの設定」および「コンテンツへのアクセスの制限」を参照してください。
AWS SRA は、Transit Gateway を使用して実装される一元化されたネットワークパターンと一致するため、ネットワークアカウントの一元化された CloudFront ディストリビューションを示しています。ネットワークアカウントに CloudFront ディストリビューションをデプロイして管理することで、一元管理のメリットを得ることができます。すべての CloudFront ディストリビューションを 1 か所で管理できるため、すべてのアカウントでアクセスの制御、設定の構成、使用状況のモニタリングが容易になります。さらに、1 つの集中型アカウントから ACM 証明書、DNS レコード、ログ CloudFront記録を管理できます。 CloudFront セキュリティダッシュボードは、AWS WAF の可視性とコントロールを CloudFront ディストリビューション内で直接提供します。アプリケーションの主要なセキュリティ傾向、許可およびブロックされたトラフィック、ボットアクティビティを可視化できます。ビジュアルログアナライザーや組み込みブロッキングコントロールなどの調査ツールを使用して、ログをクエリしたりセキュリティルールを記述したりすることなく、トラフィックパターンを分離し、トラフィックをブロックできます。
設計上の考慮事項
-
または、アプリケーションアカウントでアプリケーション CloudFront の一部としてデプロイすることもできます。このシナリオでは、アプリケーションチームが CloudFront ディストリビューションのデプロイ方法などの決定を行い、適切なキャッシュポリシーを決定し、ディストリビューションのガバナンス、監査、モニタリングを担当します CloudFront。ディス CloudFront トリビューションを複数のアカウントに分散することで、追加のサービスクォータのメリットを得ることができます。もう 1 つの利点として、 CloudFront固有の自動オリジンアクセスアイデンティティ (OAI) とオリジンアクセスコントロール (OAC) の設定を使用して、Amazon S3 オリジンへのアクセスを制限できます。
-
などの CDN を介してウェブコンテンツを配信する場合 CloudFront、ビューワーが CDN をバイパスしてオリジンコンテンツに直接アクセスしないようにする必要があります。このオリジンアクセス制限を実現するには、 CloudFront および AWS WAF を使用してカスタムヘッダーを追加し、カスタムオリジンにリクエストを転送する前にヘッダーを検証できます。このソリューションの詳細な説明については、AWS セキュリティブログ記事「AWS AWS WAFと AWS Secrets Manager で Amazon CloudFront オリジンセキュリティを強化する方法 AWS Secrets Manager
」を参照してください。別の方法は、Application Load Balancer に関連付けられているセキュリティグループ内の CloudFront プレフィックスリストのみを制限することです。これにより、ディス CloudFront トリビューションのみがロードバランサーにアクセスできるようになります。
AWS WAF
AWS WAF
AWS WAF は、ウェブアクセスコントロールリスト (ACL) を使用して、一連の AWS リソースを保護します。ウェブ ACL は、検査基準と、ウェブリクエストが基準を満たした場合に実行する関連アクション (ブロック、許可、カウント、またはボット制御の実行) を定義する一連の ルール です。AWS WAF は、一般的なアプリケーションの脆弱性に対する保護を提供する一連の マネージドルール
AWS WAF には、一般的なボットやターゲットを絞ったボットやアカウント乗っ取り防止 (ATP) に対応したインテリジェントな階層管理ルールが用意されています。ボットコントロールと ATP ルールグループを使用すると、サブスクリプション料金とトラフィック検査料金がかかります。従って、最初にトラフィックを監視してから、何を使用するかを決定することをお勧めします。AWS WAF コンソールで無料で利用できるボット管理およびアカウント乗っ取りダッシュボードを使用してこれらのアクティビティを監視し、インテリジェント階層の AWS WAF ルールグループが必要かどうかを判断できます。
AWS SRA CloudFront では、AWS WAF はネットワークアカウントの と統合されています。この設定では、WAF ルール処理は VPC 内ではなくエッジロケーションで行われます。これにより、コンテンツをリクエストしたエンドユーザーの近くで悪意のあるトラフィックをフィルタリングできるようになり、悪意のあるトラフィックがコアネットワークに侵入するのを防ぐことができます。
S3 バケットへのクロスアカウントアクセスを設定することで、ログアーカイブアカウントの S3 バケットに AWS WAF ログをすべて送信できます。詳細については、このトピックに関する「AWS re:Post の記事
設計上の考慮事項
-
AWS WAF を Network アカウントで集中的にデプロイする代わりに、Application アカウントに AWS WAF をデプロイする方が適しているユースケースもあります。例えば、アプリケーションアカウントに CloudFront ディストリビューションをデプロイする場合や、一般公開されている Application Load Balancer がある場合、またはウェブアプリケーションの前で Amazon API Gateway を使用している場合に、このオプションを選択できます。各 Application アカウントに AWS WAF をデプロイする場合は、AWS Firewall Manager を使用して、集中管理された Security Tooling アカウントからこれらのアカウントの AWS WAF ルールを管理します。
-
CloudFront レイヤーに一般的な AWS WAF ルールを追加し、Application Load Balancer や API ゲートウェイなどのリージョンリソースにアプリケーション固有の AWS WAF ルールを追加することもできます。
AWS Shield
AWS Shield
Shield Advanced の自動アプリケーションレイヤー DDoS 緩和機能を使用して、保護された CloudFront ディストリビューションと Application Load Balancer に対するアプリケーションレイヤー (レイヤー 7) 攻撃を自動的に緩和するように Shield Advanced を設定できます。この機能を有効にすると、Shield Advanced は DDoS 攻撃を軽減するためのカスタム AWS WAF ルールを自動的に生成します。Shield Advanced を使用すると、AWS Shield Response Team (SRT) へのアクセスも可能になります。アクティブな DDoS 攻撃中は、いつでも SRT に連絡して、アプリケーションのカスタム緩和策を作成および管理できます。SRT が保護対象リソースをプロアクティブに監視し、DDoS 攻撃時に連絡を受信する必要がある場合は、プロアクティブエンゲージメント機能 を有効にすることを検討してください。
設計上の考慮事項
-
Amazon 、Application Load Balancer 、Network Load Balancer など CloudFront、アプリケーションアカウントのインターネット向けリソースが前面にあるワークロードがある場合は、アプリケーションアカウントで Shield Advanced を設定し、それらのリソースを Shield Protection に追加します。AWS Firewall Manager を使用して、これらのオプションを大規模に設定できます。
-
Application Load Balancer の前の CloudFront ディストリビューションなど、データフローに複数のリソースがある場合は、保護されたリソースとしてエントリポイントリソースのみを使用します。これにより、2 つのリソースに対して Shield Data Transfer Out (DTO) 料金を
2 回支払う必要がなくなります。 -
Shield Advanced は、Amazon でモニタリングできるメトリクスを記録します CloudWatch。(詳細については、AWS ドキュメントの「AWS Shield Advanced メトリクスとアラーム」を参照してください。) DDoS イベントが検出されたときにセキュリティセンターに SNS 通知を受信するように CloudWatch アラームを設定します。DDoS イベントが疑われる場合は、サポートチケットを提出し、優先度を最高に指定して、AWS エンタープライズサポートチーム
に連絡してください。イベントを処理する際のエンタープライズサポートチームには、Shield Response Team (SRT) が含まれます。また、AWS Shield エンゲージメント Lambda 関数を事前に設定して、サポートチケットを作成して SRT チームにメールを送信することもできます。
AWS Certificate Manager
AWS Certificate Manager (ACM)
ACM はネットワークアカウントでパブリック TLS 証明書を生成するために使用されます。次に、ディス CloudFront トリビューションはビューワーと 間の HTTPS 接続を確立するために使用します CloudFront。詳細については、 CloudFront ドキュメントを参照してください。
設計上の考慮事項
-
外部向け証明書の場合、ACM は証明書をプロビジョニングするリソースと同じアカウントに存在する必要があります。アカウント間で証明書を共有することはできません。
Amazon Route 53
Amazon Route 53
Route 53 を DNS サービスとして使用して、ドメイン名を EC2 インスタンス、S3 バケット、 CloudFront ディストリビューション、およびその他の AWS リソースにマッピングできます。AWS DNS サーバーは分散型であるため、エンドユーザーが常にアプリケーションにルーティングされることを保証できます。Route 53 のトラフィックフローやルーティング制御などの機能は、信頼性の向上に役立ちます。プライマリアプリケーションのエンドポイントが使用できなくなった場合は、ユーザーを別の場所に再ルーティングするようにフェールオーバーを設定できます。Route 53 Resolver は、AWS Direct Connect または AWS マネージド VPN 経由で VPC およびオンプレミス ネットワークに再帰的 DNS を提供します。
Route 53 で AWS Identity と Access Management (IAM) サービスを使用することで、DNS データを更新できるユーザーをきめ細かく制御できます。DNS Security Extensions (DNSSEC) 署名を有効にして、DNS 応答が Route 53 から送信されていて、改ざんされていないことを DNS リゾルバーが検証できるようにします。
Route 53 Resolver DNS Firewall は、VPC からのアウトバウンド DNS リクエストを保護できます。これらのリクエストは、ドメイン名の解決用に Route 53 Resolver を経由します。DNS Firewall による保護の主な用途は、データの DNS 漏洩を防ぐことです。DNS Firewall を使用すると、アプリケーションでクエリできるドメインを監視および管理できます。不正であるとわかっているドメインへのアクセスを拒否し、他のすべてのクエリの通過を許可できます。また、確実に信頼できるドメインを除くすべてのドメインへのアクセスを拒否することもできます。DNS ファイアウォールは、VPC エンドポイント名など、プライベートのホストゾーン (共有またはローカル) 内のリソースに対する解決リクエストをブロックする場合にも使用できます。また、パブリックまたはプライベートの EC2 インスタンス名のリクエストをブロックすることもできます。
Route 53 リゾルバーは、すべての VPC の一部としてデフォルトで作成されます。AWS SRA では、Route 53 は主に DNS ファイアウォール機能の Network アカウントで使用されます。
設計上の考慮事項
-
DNS Firewall と AWS Network Firewall は、どちらもドメイン名のフィルタリングを行いますが、トラフィックの種類は異なります。DNS Firewall と Network Firewall を組み合わせることで、2 つの異なるネットワークパス上のアプリケーション層トラフィックに対してドメインベースのフィルタリングを設定できます。
-
DNS Firewall は、VPC 内のアプリケーションから Route 53 Resolver を通過するアウトバウンド DNS クエリのフィルタリングを行います。また、ブロックしたドメイン名にクエリのカスタムレスポンスを送信するように DNS Firewall を設定できます。
-
Network Firewall は、ネットワーク層とアプリケーション層の両方のトラフィックに対してフィルタリングを行いますが、Route 53 Resolver によって実行されるクエリに対する可視性はありません。
-
