インフラストラクチャ OU — ネットワークアカウント - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

インフラストラクチャ OU — ネットワークアカウント

簡単なアンケートに回答して、 AWS セキュリティリファレンスアーキテクチャ (AWS SRA) の未来に影響を与えます。

次の図は、ネットワークアカウントで設定されている AWS セキュリティサービスを示しています。 

Network アカウントのセキュリティサービス

Network アカウントは、アプリケーションとより広範なインターネット間のゲートウェイを管理しています。その双方向インターフェイスを保護することが重要です。Network アカウントは、個々のアプリケーションワークロード、セキュリティ、およびその他のインフラストラクチャからネットワークサービス、構成、およびオペレーションを分離します。この配置は、接続性、権限、およびデータフローを制限するだけでなく、これらのアカウントで運用する必要があるチームの職務分離と最小権限もサポートします。ネットワークフローを個別のインバウンドとアウトバウンドの仮想プライベートクラウド(VPC)に分割することで、機密性の高いインフラストラクチャとトラフィックを不用意なアクセスから保護できます。インバウンドネットワークは一般的に高いリスクと考えられ、適切なルーティング、モニタリング、および潜在的な問題の軽減が必要です。これらのインフラストラクチャアカウントは、Org Management アカウントとインフラストラクチャ OU から権限ガードレールを継承します。ネットワーキング (およびセキュリティ) チームは、このアカウントのインフラストラクチャの大部分を管理します。

ネットワークアーキテクチャ

ネットワーク設計と詳細はこのドキュメントの範囲外ですが、さまざまなアカウント間のネットワーク接続には、VPC ピアリングと AWS PrivateLinkの 3 つのオプションをお勧めします AWS Transit Gateway。これらの中から選択する際の重要な考慮事項は、運用規範、予算、および特定の帯域幅のニーズです。

  • VPC ピアリング — 2 つの VPC を接続する最も簡単な方法は、VPC ピアリングを使用することです。接続することで、VPC 間の完全な双方向接続が可能になります。別々のアカウントにあり、ピア接続 AWS リージョン もできる VPCs。スケールでは、数十から数百の VPC がある場合、それらをピアリングと相互接続すると、数百から数千のピアリング接続のメッシュとなり、管理やスケールが困難になる可能性があります。VPC ピアリングは、ある VPC のリソースが別の VPC のリソースと通信する必要があり、両方の VPC の環境が制御およびセキュリティで保護され、接続する VPC の数が 10 未満の場合(各接続の個別の管理を可能にする)に最適です。

  • AWS PrivateLink ‒ PrivateLink はVPCs、サービス、アプリケーション間のプライベート接続を提供します。VPC で独自のアプリケーションを作成し、PrivateLink を使用するサービス (エンドポイントサービスといいます) として設定できます。他の AWS プリンシパルは、サービスのタイプに応じて、インターフェイス VPC エンドポイントまたは Gateway Load Balancer エンドポイントを使用して、VPC からエンドポイントサービスへの接続を作成できます。PrivateLink を使用する場合、サービストラフィックは一般にルーティング可能なネットワークを通過しません。クライアント・サーバーの設定で、1 つまたは複数のコンシューマー VPC に、サービスプロバイダー VPC 内の特定のサービスまたはインスタンスのセットに一方的にアクセスさせたい場合、PrivateLink を使用します。また、2 つの VPC 内のクライアントとサーバに IP アドレスが重複している場合、PrivateLink はクライアント VPC 内の 伸縮自在のネットワークインターフェイスを使用しており、サービスプロバイダーと IP の競合が発生しないため、このオプションも適しています。

  • AWS Transit Gateway ‒ Transit Gateway は、hub-and-spoke設計を提供します。 は、高可用性とスケーラビリティ AWS を管理します。 VPCs トランジットゲートウェイはリージョンのリソースであり、同じ 内の何千もの VPCs を接続できます AWS リージョン。ハイブリッド接続 (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 は、VPCs (同一または異なる AWS リージョン)、インターネット、オンプレミスネットワーク間の検査を管理するための簡素化された一元的なアプローチを提供します。 AWS SRA の場合、VPCs 間のすべてのトラフィックが検査 VPC を通過し、検査 VPC を他のワークロードに使用しないようにします。

AWS Network Firewall

AWS Network Firewall は、VPC 用の高可用性のマネージドネットワークファイアウォールサービスです。これにより、ステートフルインスペクション、侵入防止と検出、ウェブフィルタリングを簡単にデプロイおよび管理して、仮想ネットワークを保護できます AWS。Network Firewall を使用して TLS セッションを復号し、インバウンドトラフィックとアウトバウンドトラフィックを検査できます。Network Firewall の設定の詳細については、VPC のブログ記事AWS Network Firewall 「 — New Managed Firewall Service」を参照してください。

VPC では、アベイラビリティーゾーンごとにファイアウォールを使用します。アベイラビリティーゾーンごとに、トラフィックをフィルタリングするファイアウォールエンドポイントをホストするサブネットを選択します。アベイラビリティーゾーンのファイアウォールエンドポイントは、ゾーンが存在するサブネットを除くゾーン内のすべてのサブネットを保護できます。ユースケースとデプロイメントモデルに応じて、ファイアウォールサブネットはパブリックまたはプライベートのいずれかになります。ファイアウォールは、トラフィックフローに対して完全に透過的であり、NAT を実行しません。送信元と送信先のアドレスが保持されます。このリファレンスアーキテクチャでは、ファイアウォールエンドポイントはインスペクション VPC でホストされています。インバウンド VPC からとアウトバウンド VPC へのすべてのトラフィックは、検査のためにこのファイアウォールサブネットを介してルーティングされます。

Network Firewall はAmazon CloudWatch メトリクスを通じてファイアウォールアクティビティをリアルタイムで表示し、Amazon Simple Storage Service (Amazon S3)、CloudWatch、Amazon Data Firehose にログを送信することで、ネットワークトラフィックの可視性を向上させます。Network Firewall は、AWS Partners の技術を含む、お客様の既存のセキュリティアプローチと相互運用が可能です。既存の Suricata ルールセットをインポートすることもでき、ルールセットは内部で作成されたものや、サードパーティのベンダーまたはオープンソースプラットフォームから外部調達されているものである場合があります。

AWS SRA では、Network Firewall はネットワークアカウント内で使用されます。これは、サービスのネットワーク制御に焦点を当てた機能がアカウントのインテントと一致するためです。

設計上の考慮事項
  • AWS Firewall Manager は Network Firewall をサポートしているため、組織全体で Network Firewall ルールを一元的に設定してデプロイできます。(詳細については、 AWS ドキュメントの「Firewall Manager での 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 、実証済みのセキュリティイニシアチブの最新テクノロジーを使用し、このテクノロジーをさまざまな重点分野に適用します。Network Reachability パッケージは、特に EC2 インスタンスとそのインターネットアクセシビリティに重点を置いています。

ネットワークアカウントは、 AWS 環境に出入りするトラフィックを制御する重要なネットワークインフラストラクチャを定義します。このトラフィックは厳重に監視する必要があります。 AWS SRA では、Network Access Analyzer はネットワークアカウント内で使用され、意図しないネットワークアクセスの識別、インターネットゲートウェイを介したインターネットアクセス可能なリソースの識別、ネットワークファイアウォールや NAT ゲートウェイなどの適切なネットワークコントロールがリソースとインターネットゲートウェイ間のすべてのネットワークパスに存在することを確認します。

設計上の考慮事項

Network Access Analyzer は Amazon VPC の機能であり、VPC AWS アカウント を持つ任意の で使用できます。ネットワーク管理者は、厳密にスコープされたクロスアカウント IAM ロールを取得して、承認されたネットワークパスが各ロール内に強制されていることを検証できます AWS アカウント。

AWS RAM

AWS Resource Access Manager (AWS RAM) を使用すると、1 つの で作成した AWS リソースを他の AWS アカウント と安全に共有できます AWS アカウント。AWS RAM は、リソースの共有を管理し、アカウント間でこのエクスペリエンスを標準化するための一元的な場所を提供します。これにより、管理上および請求上の分離を活用しながらリソースの管理を容易に行うことで、マルチアカウント戦略によってもたらされる影響抑制のメリットの範囲が狭まります。アカウントが によって管理されている場合 AWS Organizations、 AWS RAM は組織内のすべてのアカウント、または 1 つ以上の指定された組織単位 (OUs。アカウントが組織の一部であるかどうかにかかわらず、アカウント ID AWS アカウント ごとに特定の と共有することもできます。サポートされているリソースタイプの一部 は、指定した IAM ロールおよびユーザーと共有もできます。

AWS RAM では、VPC サブネットや Route 53 ルールなど、IAM リソースベースのポリシーをサポートしていないリソースを共有できます。さらに、リソースの所有者は AWS RAM、共有した個々のリソースにアクセスできるプリンシパルを確認できます。IAM プリンシパルは、共有されているリソースのリストを直接取得できます。これは、IAM リソースポリシーによって共有されているリソースとは関係ありません。 AWS RAM を使用して AWS 組織外のリソースを共有する場合、招待プロセスが開始されます。受信者は、リソースへのアクセスを許可する前に招待を受け入れる必要があります。これにより、追加のチェックと残高が提供されます。

AWS RAM は、共有リソースがデプロイされているアカウントで、リソース所有者によって呼び出され、管理されます。SRA AWS に AWS RAM 示されている の一般的なユースケースの 1 つは、ネットワーク管理者が VPC サブネットとトランジットゲートウェイ AWS を組織全体と共有することです。これにより、 AWS アカウント とネットワーク管理機能を切り離すことができ、職務の分離に役立ちます。VPC 共有の詳細については、 AWS ブログ記事「VPC 共有: 複数のアカウントと VPC 管理に対する新しいアプローチ」およびAWS 「ネットワークインフラストラクチャ」ホワイトペーパーを参照してください。

設計上の考慮事項

AWS RAM サービスは AWS SRA のネットワークアカウント内にのみデプロイされますが、通常は複数のアカウントにデプロイされます。たとえば、データレイク管理を単一のデータレイクアカウントに一元化し、 AWS Lake Formation データカタログリソース (データベースとテーブル) を AWS 組織内の他のアカウントと共有できます。詳細については、「 AWS Lake Formation ドキュメント」および AWS 「 ブログ記事」を参照してください AWS アカウントAWS Lake Formation。さらに、セキュリティ管理者は、 AWS RAM を使用して AWS Private Certificate Authority 階層を構築するときにベストプラクティスに従うことができます。CAsは、CA 階層にアクセスせずに証明書を発行できる外部のサードパーティーと共有できます。これにより、発信元の組織は第三者のアクセスを制限したり取り消したりすることができます。

AWS Verified Access

AWS Verified Access は、VPN なしで企業のアプリケーションとリソースへの安全なアクセスを提供します。これにより、セキュリティ体制が強化され、事前定義された要件に照らして各アクセスリクエストをリアルタイムで評価することで、ゼロトラストアクセスを適用できます。ID データ および デバイスポスチャ に基づく条件を使用して、アプリケーションごとに固有のアクセスポリシーを定義できます。Verified Access は、ブラウザベースのアプリケーションなどの HTTP(S) アプリケーション、および Git リポジトリ、データベース、EC2 インスタンスのグループなどのアプリケーションの TCP、SSH、RDP プロトコルを介した非 HTTP(S) アプリケーションへの安全なアクセスを提供します。これらは、コマンドラインターミナルを使用するか、デスクトップアプリケーションからアクセスできます。また、Verified Access は、管理者がアクセスポリシーを効率的に設定して監視できるようにすることで、セキュリティ運用を簡素化します。これにより、ポリシーの更新、セキュリティや接続に関するインシデントへの対応、コンプライアンス基準の監査のための時間が確保されます。Verified Access は、SQL インジェクションやクロスサイトスクリプティング (XSS) などの一般的な脅威を除外 AWS WAF するのに役立つ との統合もサポートしています。Verified Access は とシームレスに統合されているため AWS IAM アイデンティティセンター、ユーザーは SAML ベースのサードパーティー ID プロバイダー (IdPs で認証できます。OpenID Connect (OIDC) と互換性のあるカスタム IdP ソリューションをすでに使用している場合、Verified Access は IdP に直接接続してユーザーを認証することもできます。Verified Access はすべてのアクセス試行をログに記録するため、セキュリティインシデントや監査請求に迅速に対応できます。Verified Access は、Amazon Simple Storage Service (Amazon S3)、Amazon CloudWatch Logs、Amazon Data Firehose へのこれらのログの配信をサポートしています。 

Verified Access は、社内用とインターネット向けの 2 つの一般的な企業アプリケーションパターンをサポートします。Verified Access は、Application Load Balancer またはエラスティックネットワークインターフェースを使用してアプリケーションと統合します。Application Load Balancer を使用している場合、Verified Access には内部ロードバランサーが必要です。Verified Access は AWS WAF インスタンスレベルで をサポートしているため、Application Load Balancer と統合されている既存のアプリケーションは AWS WAF 、ロードバランサーから Verified Access インスタンスにポリシーを移動できます。企業アプリケーションは Verified Access エンドポイントとして表されます。各エンドポイントは Verified Access グループに関連付けられ、グループのアクセスポリシーを継承します。Verified Access グループは、Verified Access エンドポイントとグループレベルの Verified Access ポリシーの集合です。グループはポリシー管理を簡素化し、IT 管理者がベースライン基準を設定できるようにします。アプリケーション所有者は、アプリケーションの機密性に応じて、さらに詳細なポリシーを定義できます。

AWS SRA では、Verified Access はネットワークアカウント内でホストされます。中央の IT チームが、一元管理された構成を設定します。例えば、ID プロバイダー (Okta など) とデバイストラストプロバイダー (Jamf など) などの信頼プロバイダーを接続し、グループを作成し、グループレベルのポリシーを決定する場合があります。これらの設定は、 を使用して数十、数百、または数千のワークロードアカウントと共有できます AWS RAM。これにより、アプリケーションチームは、他のチームのオーバーヘッドなしでアプリケーションを管理する基盤となるエンドポイントを管理できます。 は、さまざまなワークロードアカウントでホストされている企業アプリケーションに Verified Access を活用するスケーラブルな方法 AWS RAM を提供します。

設計上の考慮事項

ポリシー管理を簡素化するために、同様のセキュリティ要件を持つアプリケーションのエンドポイントをグループ化し、そのグループをアプリケーションアカウントと共有できます。グループ内のすべてのアプリケーションはグループポリシーを共有します。エッジケースのためにグループ内のアプリケーションが特定のポリシーを必要とする場合は、そのアプリケーションにアプリケーションレベルのポリシーを適用できます。

Amazon VPC Lattice

Amazon VPC Lattice は、service-to-service通信を接続、モニタリング、保護するアプリケーションネットワークサービスです。マイクロサービスと呼ばれるサービスは、特定のタスクを配信するソフトウェアの独立したデプロイ可能なユニットです。VPC Lattice は、基盤となるネットワーク接続、フロントエンドロードバランサー、またはサイドカープロキシを管理する AWS アカウント ことなく、VPCs 間のサービス間のネットワーク接続とアプリケーションレイヤールーティングを自動的に管理します。パスやヘッダーなどのリクエスト特性に基づいてアプリケーションレベルのルーティングを行う、フルマネージド型のアプリケーションレイヤープロキシを提供します。VPC Lattice は VPC インフラストラクチャに組み込まれているため、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic Kubernetes Service (Amazon EKS)、 などの幅広いコンピューティングタイプにわたって一貫したアプローチを提供します AWS Lambda。VPC Lattice は、ブルー/グリーンおよび canary スタイルのデプロイメント用の加重ルーティングもサポートしています。VPC Lattice を使用して、サービスの検出と接続を自動的に実装する論理境界を持つサービスネットワークを作成できます。VPC Lattice は IAM と統合され、service-to-service認証と認可を行います。 

VPC Lattice は と統合 AWS RAM され、サービスとサービスネットワークの共有を可能にします。 AWS SRA は、開発者またはサービス所有者がアプリケーションアカウントに VPC Lattice サービスを作成する分散アーキテクチャを示しています。サービスオーナーは、リスナー、ルーティングルール、ターゲットグループを認証ポリシーとともに定義します。次に、サービスを他のアカウントと共有し、そのサービスを VPC Lattice サービスネットワークに関連付けます。これらのネットワークは、ネットワーク管理者が Network アカウントで作成し、Application アカウントと共有します。ネットワーク管理者は、サービスのネットワークレベルの認証ポリシーと監視を設定します。管理者は VPC と VPC Lattice サービスを 1 つ以上のサービスネットワークに関連付けます。この分散アーキテクチャの詳細なチュートリアルについては、 AWS ブログ記事「Amazon VPC Lattice を使用してアプリケーションに安全なマルチアカウントマルチ VPC 接続を構築する」を参照してください。

設計上の考慮事項
  • 組織のサービスまたはサービスネットワークの可視性の運用モデルに応じて、ネットワーク管理者はサービスネットワークを共有し、サービスと VPCs をこれらのサービスネットワークに関連付けるためのコントロールをサービス所有者に付与できます。また、サービスオーナーはサービスを共有し、ネットワーク管理者はサービスをサービスネットワークに関連付けることができます。

  • クライアントは、同じサービスネットワークに関連付けられている 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 は連携して、柔軟でレイヤー化されたセキュリティ境界を作成します。CloudFront では、コンテンツ、APIs、またはアプリケーションは、TLSv1.3 を使用してビューワークライアントと CloudFront 間の通信を暗号化して保護することで、HTTPS 経由で配信できます。ACM を使用してカスタム SSL 証明書を作成し、CloudFront ディストリビューションに無料でデプロイできます。ACM は証明書の更新を自動的に処理します。Shield は、 で実行されるアプリケーションを保護するのに役立つマネージド DDoS 保護サービスです AWS。アプリケーションのダウンタイムとレイテンシーを最小限に抑える動的検出と自動インライン緩和を提供します。特定の条件 (IP アドレス、HTTP ヘッダーと本文、またはカスタム URIs)、一般的なウェブ攻撃、および広範なボットに基づいてウェブトラフィックをフィルタリングするルール AWS WAF を作成します。Amazon Route 53 は、高可用性でスケーラブルな DNS Web サービスです。Route 53 は、ユーザーリクエストを、 AWS またはオンプレミスで実行されるインターネットアプリケーションに接続します。 AWS SRA は、ネットワークアカウント内でホストされている AWS Transit Gatewayを使用して一元化されたネットワーク進入アーキテクチャを採用しているため、エッジセキュリティインフラストラクチャもこのアカウントに集中されます。

Amazon CloudFront

Amazon CloudFront は、一般的なネットワーク層とトランスポート DDoS 攻撃に対する固有の保護を提供する安全なコンテンツ配信ネットワーク (CDN) です。TLS 証明書を使用してコンテンツ、API、またはアプリケーションを配信でき、高度な TLS 機能が自動的に有効になります。 AWS Certificate Manager (ACM) を使用してカスタム TLS 証明書を作成し、ACM セクションで後述するように、ビューワーと CloudFront 間の HTTPS 通信を適用できます。 AWS Certificate Manager (ACM)CloudFront とカスタムオリジン間の通信に、転送中のエンドツーエンドの暗号化を実装するようにも要求できます。このシナリオでは、TLS 証明書をオリジンサーバーにインストールする必要があります。オリジンがエラスティックロードバランサーの場合、ACM によって生成された証明書、またはサードパーティの認証機関 (CA) によって検証されて ACM にインポートされた証明書を使用できます。S3 バケットウェブサイトエンドポイントが CloudFront のオリジンとして機能する場合、Amazon S3 はウェブサイトエンドポイントの HTTPS をサポートしていないため、オリジンで HTTPS を使用するように CloudFront を設定することはできません。(ただし、閲覧者と CloudFront の間で HTTPS を要求することはできます)。HTTPS 証明書のインストールをサポートする他のすべてのオリジンでは、信頼できるサードパーティ CA によって署名された証明書を使用する必要があります。 

CloudFront は、コンテンツへのアクセスを保護および制限するための複数のオプションを提供します。例えば、署名付き URL と署名付き Cookie を使用して、Amazon S3 オリジンへのアクセスを制限できます。詳細については、CloudFront ドキュメントの「安全なアクセスの設定」および「コンテンツへのアクセスの制限」を参照してください。

AWS SRA は、 を使用して実装される一元化されたネットワークパターンと一致するため、ネットワークアカウントの一元化された CloudFront ディストリビューションを示しています AWS Transit Gateway。Network アカウントで CloudFront ディストリビューションをデプロイして管理することで、集中管理のメリットが得られます。すべての CloudFront ディストリビューションを 1 か所で管理できるため、すべてのアカウントのアクセス制御、設定の構成、使用状況の監視が容易になります。さらに、ACM 証明書、DNS レコード、CloudFront ロギングを 1 つの集中アカウントから管理できます。

CloudFront セキュリティダッシュボードは、CloudFront ディストリビューションで直接 AWS WAF 可視性とコントロールを提供します。アプリケーションの主要なセキュリティ傾向、許可およびブロックされたトラフィック、ボットアクティビティを可視化できます。ビジュアルログアナライザーや組み込みブロッキングコントロールなどの調査ツールを使用して、ログをクエリしたりセキュリティルールを記述したりすることなく、トラフィックパターンを分離し、トラフィックをブロックできます。

設計上の考慮事項
  • または、CloudFront を Application アカウントのアプリケーションの一部としてデプロイすることもできます。このシナリオでは、アプリケーションチームが CloudFront ディストリビューションのデプロイ方法などの決定を下し、適切なキャッシュポリシーを決定し、CloudFront ディストリビューションのガバナンス、監査、監視を担当します。CloudFront ディストリビューションを複数のアカウントに分散させることで、サービスクォータを増やすことができます。もう 1 つの利点として、CloudFront の固有の自動オリジンアクセスアイデンティティ (OAI) およびオリジンアクセスコントロール (OAC) 設定を使用して、Amazon S3 オリジンへのアクセスを制限できます。

  • CloudFront などの CDN を介してウェブコンテンツを配信する場合、ビューワーが CDN をバイパスして、オリジンコンテンツに直接アクセスすることを防ぐ必要があります。このオリジンアクセス制限を実現するには、CloudFront と を使用してカスタムヘッダー AWS WAF を追加し、カスタムオリジンにリクエストを転送する前にヘッダーを検証できます。このソリューションの詳細な説明については、 AWS セキュリティブログ記事「 AWS WAF および を使用して Amazon CloudFront オリジンセキュリティを強化する方法 AWS Secrets Manager」を参照してください。別の方法は、Application Load Balancer に関連付けられているセキュリティグループ内の CloudFront プレフィックスリストのみを制限することです。これにより、CloudFront ディストリビューションのみがロードバランサーにアクセスできるようになります。

AWS WAF

AWS WAF は、アプリケーションの可用性に影響を与えたり、セキュリティを侵害したり、過剰なリソースを消費したりする可能性のある一般的な脆弱性やボットなどのウェブエクスプロイトからウェブアプリケーションを保護するのに役立つウェブアプリケーションファイアウォールです。Amazon CloudFront ディストリビューション、Amazon API Gateway REST API、Application Load Balancer、 AWS AppSync GraphQL API、Amazon Cognito ユーザープール、および AWS App Runner サービスと統合できます。

AWS WAF は、一連のリソースを保護するためにウェブアクセスコントロールリスト (ACLs) を使用します。 AWS ウェブ ACL は、検査基準を定義する一連のルールであり、ウェブリクエストが基準を満たした場合に実行する (ブロック、許可、カウント、またはボット制御を実行する) 関連アクションです。 は、一般的なアプリケーションの脆弱性に対する保護を提供する一連のマネージドルール AWS WAF を提供します。これらのルールは、 AWS および AWS パートナーによってキュレートおよび管理されます。 は、カスタムルールを作成するための強力なルール言語 AWS WAF も提供します。カスタムルールを使用して、特定のニーズに合った検査基準を記述できます。例としては、IP 制限、地理的制約、特定のアプリケーションの動作により適したカスタマイズされたマネージドルールなどがあります。

AWS WAF は、共通ボットとターゲットボット、およびアカウント乗っ取り保護 (ATP) のためのインテリジェントな階層管理ルールのセットを提供します。ボットコントロールと ATP ルールグループを使用すると、サブスクリプション料金とトラフィック検査料金がかかります。従って、最初にトラフィックを監視してから、何を使用するかを決定することをお勧めします。コンソールで AWS WAF 無料で利用できるボット管理ダッシュボードとアカウント乗っ取りダッシュボードを使用して、これらのアクティビティをモニタリングし、インテリジェント階層 AWS WAF ルールグループが必要かどうかを判断できます。 

AWS SRA では、 AWS WAF はネットワークアカウントの CloudFront と統合されています。この設定では、 AWS WAF ルール処理は VPC 内ではなくエッジロケーションで行われます。これにより、コンテンツをリクエストしたエンドユーザーの近くで悪意のあるトラフィックをフィルタリングできるようになり、悪意のあるトラフィックがコアネットワークに侵入するのを防ぐことができます。 

S3 バケットへのクロスアカウントアクセスを設定することで、 AWS WAF ログアーカイブアカウントの S3 バケットに完全なログを送信できます。詳細については、このトピックの AWS re:Post 記事を参照してください。

設計上の考慮事項
  • ネットワークアカウントに一 AWS WAF 元的にデプロイする代わりに、 AWS WAF アプリケーションアカウントにデプロイすることで、いくつかのユースケースを満たすことができます。例えば、CloudFront ディストリビューションをアプリケーションアカウントにデプロイする場合や、公開されている Application Load Balancer がある場合、またはウェブアプリケーションの前に API Gateway を使用している場合に、このオプションを選択できます。 AWS WAF 各アプリケーションアカウントにデプロイする場合は、 を使用して、一元化された AWS WAF Security Tooling アカウントからこれらのアカウントのルール AWS Firewall Manager を管理します。  

  • CloudFront レイヤーに一般的な AWS WAF ルールを追加し、Application Load Balancer や API ゲートウェイなどのリージョンリソースにアプリケーション固有の AWS WAF ルールを追加することもできます。

AWS Shield

AWS Shield は、 AWSで実行されるアプリケーションを保護するマネージド DDoS 保護サービスです。Shield には、Shield Standard と Shield Advanced の 2 つの階層があります。Shield Standard は、最も一般的なインフラストラクチャ (レイヤー 3 および 4) イベントに対する保護をすべての AWS お客様に追加料金なしで提供します。Shield Advanced は、保護された Amazon EC2、Elastic Load Balancing (Elastic Load Balancing)、CloudFront AWS Global Accelerator、Route 53 ホストゾーンでアプリケーションをターゲットとする不正なイベントに対して、より高度な自動緩和を提供します。可視性の高いウェブサイトを所有している場合、または頻繁に DDoS 攻撃を受けやすい場合は、Shield Advanced が提供する追加機能を検討できます。

Shield Advanced 自動アプリケーションレイヤー DDoS 緩和機能を使用して、保護された CloudFront ディストリビューション、Elastic Load Balancing (Elastic Load Balancing) ロードバランサー (アプリケーション、ネットワーク、クラシック)、Amazon Route 53 ホストゾーン、Amazon EC2 Elastic IP アドレス、および AWS Global Accelerator 標準アクセラレーターに対するアプリケーションレイヤー (レイヤー 7) 攻撃を自動的に軽減するように Shield Advanced を設定できます。この機能を有効にすると、Shield Advanced は DDoS 攻撃を軽減するためのカスタム AWS WAF ルールを自動的に生成します。Shield Advanced では、AWS Shield レスポンスチーム (SRT) にもアクセスできます。アクティブな DDoS 攻撃中は、いつでも SRT に連絡して、アプリケーションのカスタム緩和策を作成および管理できます。SRT が保護対象リソースをプロアクティブに監視し、DDoS 攻撃時に連絡を受信する必要がある場合は、プロアクティブエンゲージメント機能 を有効にすることを検討してください。

設計上の考慮事項
  • CloudFront、Application Load Balancer、Network Load Balancer など、アプリケーションアカウントのインターネット向けリソースが前面にあるワークロードがある場合は、アプリケーションアカウントで Shield Advanced を設定し、それらのリソースを Shield Protection に追加します。を使用して、これらのオプション AWS Firewall Manager を大規模に設定できます。

  • Application Load Balancer の前に CloudFront ディストリビューションなど、データフローに複数のリソースがある場合は、保護されたリソースとしてエントリポイントリソースのみを使用します。これにより、2 つのリソースに対して Shield Data Transfer Out (DTO) 料金を 2 回支払う必要がなくなります。

  • Shield Advanced は、Amazon CloudWatch でモニタリングできるメトリクスをレコードします。(詳細については、 AWS ドキュメントのAmazon CloudWatch によるモニタリング」を参照してください。) DDoS イベントが検出されたときに、セキュリティセンターが SNS 通知を受信するように CloudWatch アラームを設定します。DDoS イベントが疑われる場合は、AWS エンタープライズサポートチームに連絡してサポートチケットを提出し、最優先事項を割り当てます。イベントを処理する際のエンタープライズサポートチームには、Shield Response Team (SRT) が含まれます。さらに、 AWS Shield エンゲージメント Lambda 関数を事前設定してサポートチケットを作成し、SRT チームに E メールを送信できます。 

AWS Certificate Manager (ACM)

AWS Certificate Manager (ACM) を使用すると、 および内部接続リソースで使用するパブリック TLS 証明書とプライベート TLS 証明書をプロビジョニング、管理 AWS のサービス 、デプロイできます。ACM を使用すると、証明書を迅速にリクエストしたり、Elastic Load Balancing ロードバランサー、CloudFront ディストリビューション、Amazon API Gateway の APIs などの ACM 統合 AWS リソースにデプロイしたり、ACM が証明書の更新を処理したりできます。ACM パブリック証明書をリクエストする場合、キーペアや証明書署名リクエスト (CSR) を生成したり、CSR を認証局 (CA) に送信したり、証明書を受信したときにアップロードしてインストールしたりする必要はありません。ACM には、サードパーティ CA が発行した TLS 証明書をインポートして ACM 統合サービスにデプロイするオプションもあります。ACM を使用して証明書を管理する場合、証明書のプライベートキーは強力な暗号化とキー管理のベストプラクティスを使用して安全に保護され、保存されます。ACM では、パブリック証明書のプロビジョニングに追加料金は発生せず、ACM が更新プロセスを管理します。

ACM は Network アカウントでパブリック TLS 証明書を生成するために使用され、次に CloudFront ディストリビューションはこの証明書を使用してビューワーと CloudFront 間の HTTPS 接続を確立します。詳細については、「CloudFront ドキュメント」を参照してください。

設計上の考慮事項

外部向け証明書の場合、ACM は証明書をプロビジョニングするリソースと同じアカウントに存在する必要があります。アカウント間で証明書を共有することはできません。

Amazon Route 53

Amazon Route 53 は、高可用性でスケーラブルな DNS ウェブサービスです。Route 53 を使用すると、ドメイン登録、DNS ルーティング、ヘルスチェックの 3 つの主要な機能を実行できます。

Route 53 を DNS サービスとして使用して、ドメイン名を EC2 インスタンス、S3 バケット、CloudFront ディストリビューション、その他の AWS リソースにマッピングできます。DNS AWS サーバーの分散性により、エンドユーザーがアプリケーションに一貫してルーティングされます。Route 53 トラフィックフローやルーティング制御などの機能は、信頼性の向上に役立ちます。プライマリアプリケーションのエンドポイントが使用できなくなった場合は、ユーザーを別の場所に再ルーティングするようにフェールオーバーを設定できます。Route 53 Resolver は、 AWS Direct Connect または AWS マネージド VPN 経由で VPC およびオンプレミスネットワークに再帰的な DNS を提供します。

Route 53 で 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 ファイアウォール機能のためにネットワークアカウントで使用されます。

設計上の考慮事項

DNS Firewall と AWS Network Firewall はどちらもドメイン名フィルタリングを提供しますが、トラフィックのタイプは異なります。DNS Firewall と Network Firewall を一緒に使用して、2 つの異なるネットワークパスでアプリケーションレイヤートラフィックのドメインベースのフィルタリングを設定できます。

  • DNS Firewall は、VPC 内のアプリケーションから Route 53 Resolver を通過するアウトバウンド DNS クエリのフィルタリングを行います。また、ブロックしたドメイン名にクエリのカスタムレスポンスを送信するように DNS Firewall を設定できます。

  • Network Firewall は、ネットワーク層とアプリケーション層の両方のトラフィックに対してフィルタリングを行いますが、Route 53 Resolver によって実行されるクエリに対する可視性はありません。