SEC05-BP01 ネットワークレイヤーを作成する - AWS Well-Architected フレームワーク
実装のガイダンスリソース

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

SEC05-BP01 ネットワークレイヤーを作成する

ワークロードコンポーネントをそのデータの機密度とアクセス要件に応じて論理的にグループ化し、そのグループに基づいてネットワークトポロジをさまざまなレイヤーに分割します。インターネットからのインバウンドアクセスを必要とするコンポーネント (公開ウェブエンドポイントなど) と、内部アクセスのみを必要とするコンポーネント (データベースなど) は区別します。

望ましい結果： ネットワークのレイヤーは、ワークロードの ID 認証と認可戦略を補完するセキュリティへの不可欠な defense-in-depthアプローチの一部です。データの機密度とアクセス要件に応じてレイヤーが配置され、トラフィックフローと統制のメカニズムが適切に機能しています。

一般的なアンチパターン:

  • すべてのリソースは、単一のサブネットVPCまたはサブネットに作成します。

  • データの機密度の要件、コンポーネントの動作、機能を考慮せずにネットワークレイヤーを構築する。

  • ネットワークレイヤーに関するすべての考慮事項では、 VPCsおよび サブネットをデフォルトとして使用します。 AWS マネージドサービスがトポロジにどのように影響するかは考慮しません。

このベストプラクティスを活用するメリット: ネットワークレイヤーを確立することは、ネットワーク内の不要な経路、特に重要なシステムやデータにつながる経路を制限するための第一歩です。これにより、権限のない攻撃者がネットワークにアクセスしたり、ネットワーク内の他のリソースを操作したりしづらくなります。ネットワークレイヤーが分離されていると、侵入検知やマルウェア防止などの検査システムの分析範囲が狭くなるという利点があります。そのおかげで、誤検出や不要な処理に伴うオーバーヘッドの発生確率が下がります。

このベストプラクティスを活用しない場合のリスクレベル: 高

実装のガイダンス

ワークロードのアーキテクチャを設計する場合、一般的には、コンポーネントをそれぞれの役割に応じて異なるレイヤーに分けます。例えば、ウェブアプリケーションは、プレゼンテーションレイヤー、アプリケーションレイヤー、データレイヤーで構成できます。ネットワークトポロジを設計する際も似たようなアプローチを採用できます。基盤にあるネットワーク統制が、ワークロードのデータアクセス要件を適用するのに役立つことがあります。例えば、3 層ウェブアプリケーションアーキテクチャでは、静的プレゼンテーションレイヤーファイルを Amazon S3に保存し、Amazon CloudFront などのコンテンツ配信ネットワーク (CDN) から配信できます。アプリケーションレイヤーには、Application Load Balancer (ALB） が Amazon VPC パブリックサブネット (非軍事ゾーンまたは に類似DMZ) で提供するパブリックエンドポイントがあり、バックエンドサービスはプライベートサブネットにデプロイされます。データレイヤーは、データベースや共有ファイルシステムなどのリソースをホストします。アプリケーションレイヤーのリソースとは異なるプライベートサブネットに配置できます。これらの各レイヤー境界 (CDN、パブリックサブネット、プライベートサブネット) には、許可されたトラフィックのみがそれらの境界を通過できるようにするコントロールをデプロイできます。

ワークロードのコンポーネントの機能面の目的に基づいてネットワークレイヤーをモデル化するのと同様に、処理対象のデータの機密度も考慮してください。ウェブアプリケーションの例で考えてみると、ワークロードサービスはすべてアプリケーションレイヤー内にある一方で、それぞれのサービスが処理するデータの機密度は異なる場合があります。この場合、アプリケーションレイヤーを複数のプライベートサブネットで分割するか、同じ VPCsで異なるか AWS アカウント、データ機密性のレベル AWS アカウント ごとにVPCs異なるかでさえも、コントロール要件に応じて適切である場合があります。

ネットワークレイヤーについてさらに考慮すべき点は、ワークロードのコンポーネントの動作の一貫性です。引き続き同じ例で言えば、アプリケーションレイヤーにエンドユーザーや統合先の外部システムからの入力を受け入れるサービスがあり、その入力のリスクが他のサービスへの入力と比べて本質的に高いという場合が考えられます。例えば、ファイルのアップロード、実行するコードスクリプト、メールのスキャンなどが該当します。こうしたサービスを独自のネットワークレイヤーに配置すれば、より強固な分離境界を張り巡らせることができ、それらの固有の動作のせいで検査システムで誤検知アラートが発生するのを防止できます。

設計の一環として、 AWS マネージドサービスの使用がネットワークトポロジにどのように影響するかを検討してください。Amazon Lattice VPC などの のサービスが、ネットワークレイヤー間のワークロードコンポーネントの相互運用性をどのように容易にするかについて説明します。を使用する場合はAWS Lambda、特に理由がない限り、VPCサブネットに をデプロイします。 VPCエンドポイントを特定し、インターネットゲートウェイへのアクセスを制限するセキュリティポリシーへの準拠を簡素化AWS PrivateLinkできます。

実装手順

  1. ワークロードのアーキテクチャを見直します。コンポーネントやサービスを、それらが提供する機能、処理対象のデータの機密度、動作に基づいて論理的にグループ化します。

  2. インターネットからのリクエストに応答するコンポーネントについては、ロードバランサーやその他のプロキシを使用してパブリックエンドポイントを設けることを検討します。 CloudFront、Amazon API Gateway 、Elastic Load Balancing 、 などのマネージドサービスを使用して、パブリックエンドポイントAWS Amplifyをホストすることで、セキュリティコントロールの移行について説明します。

  3. Amazon EC2インスタンス、AWS Fargateコンテナ、Lambda 関数などのコンピューティング環境で実行されているコンポーネントについては、最初のステップのグループに基づいてプライベートサブネットにデプロイします。

  4. Amazon DynamoDB 、Amazon Kinesis、Amazon SQSなどのフルマネージド AWS サービスでは、プライベート IP アドレス経由でのアクセスのデフォルトとしてVPCエンドポイントを使用することを検討してください。

リソース

関連するベストプラクティス:

関連動画:

関連する例: