SEC05-BP01 네트워크 계층 생성 - AWS Well-Architected 프레임워크
구현 지침리소스

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

SEC05-BP01 네트워크 계층 생성

데이터 민감도 및 액세스 요구 사항에 따라 워크로드 구성 요소의 논리적 그룹을 기반으로 네트워크 토폴로지를 여러 계층으로 세분화합니다. 인터넷에서 인바운드 액세스를 필요로 하는 구성 요소(예: 퍼블릭 웹 엔드포인트)와 내부 액세스만 필요한 구성 요소(예: 데이터베이스)를 구분합니다.

원하는 결과:네트워크 계층은 워크로드의 자격 증명 인증 및 권한 부여 전략을 보완하는 보안에 대한 필수 defense-in-depth 접근 방식의 일부입니다. 데이터 민감도 및 액세스 요구 사항에 따라 적절한 트래픽 흐름 및 제어 메커니즘과 함께 계층이 배치됩니다.

일반적인 안티 패턴:

  • 단일 VPC 또는 서브넷에 모든 리소스를 생성합니다.

  • 데이터 민감도 요구 사항, 구성 요소 동작 또는 기능을 고려하지 않고 네트워크 계층을 구성합니다.

  • VPCs 및 서브넷을 모든 네트워크 계층 고려 사항에 대한 기본값으로 사용하며 AWS 관리형 서비스가 토폴로지에 미치는 영향은 고려하지 않습니다.

이 모범 사례 확립의 이점: 네트워크 계층 구축은 네트워크를 통한 불필요한 경로, 특히 중요한 시스템 및 데이터로 이어지는 불필요한 경로를 제한하는 첫 번째 단계입니다. 이를 통해 승인되지 않은 행위자가 네트워크에 액세스할 권한을 얻어 내부의 추가 리소스를 탐색하기가 더 어려워집니다. 개별 네트워크 계층은 침입 탐지 또는 맬웨어 방지와 같은 검사 시스템의 분석 범위를 효과적으로 줄입니다. 이렇게 하면 오탐과 불필요한 처리 오버헤드가 생길 가능성이 낮아집니다.

이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준: 높음

구현 가이드

워크로드 아키텍처를 설계할 때는 보통 구성 요소를 책임에 따라 여러 계층으로 분리합니다. 예를 들어, 웹 애플리케이션에는 프레젠테이션 계층, 애플리케이션 계층, 데이터 계층이 있을 수 있습니다. 네트워크 토폴로지를 설계할 때도 비슷한 접근 방식을 사용할 수 있습니다. 기본 네트워크 제어는 워크로드의 데이터 액세스 요구 사항을 적용하는 데 도움이 될 수 있습니다. 예를 들어 3계층 웹 애플리케이션 아키텍처에서는 정적 프레젠테이션 계층 파일을 Amazon S3에 저장하고 Amazon CloudFront 와 같은 콘텐츠 전송 네트워크(CDN)에서 제공할 수 있습니다. 애플리케이션 계층에는 Application Load Balancer(ALB)가 Amazon VPC 퍼블릭 서브넷(비무장 영역 또는 와 유사DMZ)에서 제공하는 퍼블릭 엔드포인트가 있을 수 있으며, 백엔드 서비스는 프라이빗 서브넷에 배포됩니다. 데이터베이스, 공유 파일 시스템과 같은 리소스를 호스팅하는 데이터 계층은 애플리케이션 계층의 리소스와는 다른 프라이빗 서브넷에 있을 수 있습니다. 이러한 각 계층 경계(CDN, 퍼블릭 서브넷, 프라이빗 서브넷)에서 승인된 트래픽만 해당 경계를 통과하도록 허용하는 제어를 배포할 수 있습니다.

워크로드 구성 요소의 기능적 목적을 기반으로 네트워크 계층을 모델링하는 것과 마찬가지로, 처리 중인 데이터의 민감도도 고려하세요. 웹 애플리케이션 예제를 사용하면 모든 워크로드 서비스가 애플리케이션 계층 내에 있을 수 있지만, 서비스마다 민감도 수준이 다른 데이터를 처리할 수 있습니다. 이 경우 제어 요구 사항에 따라 여러 프라이빗 서브넷을 사용하여 애플리케이션 계층VPCs을 나누는 것이 적합 AWS 계정할 VPCs AWS 계정 수 있습니다.

네트워크 계층에 대해 추가로 고려해야 할 사항은 워크로드 구성 요소의 동작 일관성입니다. 계속해서 예를 들자면, 애플리케이션 계층에는 최종 사용자의 입력을 받아들이는 서비스 또는 다른 서비스에 대한 입력보다 본질적으로 더 위험한 외부 시스템 통합이 있을 수 있습니다. 파일 업로드, 실행할 코드 스크립트, 이메일 스캔 등을 그 예로 들 수 있습니다. 이러한 서비스를 자체 네트워크 계층에 배치하면 주위에 더 강력한 격리 경계가 형성되고, 검사 시스템에서 이러한 서비스의 고유한 동작으로 인해 오탐 알림이 발생하는 것을 방지할 수 있습니다.

설계의 일환으로 AWS 관리형 서비스를 사용하는 것이 네트워크 토폴로지에 미치는 영향을 고려하세요. Amazon VPC Lattice와 같은 서비스가 네트워크 계층 전반에서 워크로드 구성 요소의 상호 운용성을 더 쉽게 만드는 데 어떻게 도움이 되는지 알아봅니다. 를 사용하는 경우AWS Lambda, 하지 말아야 할 특별한 이유가 없는 한 VPC 서브넷에 를 배포합니다. VPC 엔드포인트와 가 인터넷 게이트웨이에 대한 액세스를 제한하는 보안 정책 준수를 간소화할 AWS PrivateLink 수 있는 위치를 결정합니다.

구현 단계

  1. 워크로드 아키텍처를 검토합니다. 제공하는 기능, 처리 중인 데이터의 민감도, 동작을 기반으로 구성 요소와 서비스를 논리적으로 그룹화하세요.

  2. 인터넷 요청에 응답하는 구성 요소의 경우 로드 밸런서 또는 기타 프록시를 사용하여 퍼블릭 엔드포인트를 제공하는 것을 고려해 보세요. , Amazon API Gateway CloudFront, Elastic Load Balancing 및 와 같은 관리형 서비스를 사용하여 퍼블릭 엔드포인트를 호스팅AWS Amplify하여 보안 제어 전환에 대해 알아봅니다.

  3. Amazon EC2 인스턴스, AWS Fargate 컨테이너 또는 Lambda 함수와 같은 컴퓨팅 환경에서 실행되는 구성 요소의 경우 첫 번째 단계의 그룹을 기반으로 프라이빗 서브넷에 배포합니다.

  4. Amazon DynamoDB, Amazon Kinesis 또는 Amazon SQS와 같은 완전 관리형 AWS 서비스의 경우 VPC 엔드포인트를 프라이빗 IP 주소를 통한 액세스의 기본값으로 사용하는 것이 좋습니다.

리소스

관련 모범 사례:

관련 비디오:

관련 예제: