인프라 OU - Network 계정 - AWS 규범적 지침

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

인프라 OU - Network 계정

간단한 설문조사를 통해 AWS 보안 참조 아키텍처 (AWS SRA) 의 미래에 영향을 미치세요.

다음 다이어그램은 Network 계정에서 구성할 수 있는 AWS 보안 서비스를 보여줍니다. 

Network 계정용 보안 서비스

Network 계정은 애플리케이션과 광범위한 인터넷 사이의 게이트웨이를 관리합니다. 양방향 인터페이스 보호에 있어 중요합니다. Network 계정은 네트워킹 서비스, 구성 및 운영을 개별 애플리케이션 워크로드, 보안 및 기타 인프라로부터 분리합니다. 이를 통해 연결성, 권한 및 데이터 흐름을 제한할 뿐만 아니라 이러한 계정을 운영해야 하는 팀의 업무 및 최소 권한 분리를 지원합니다. 네트워크 흐름을 별도의 인바운드 및 아웃바운드 Virtual Private Cloud(VPC)로 분리하여 원치 않는 액세스로부터 민감한 인프라와 트래픽을 보호할 수 있습니다. 인바운드 네트워크는 일반적으로 위험이 더 크다고 간주되며 적절한 라우팅, 모니터링 및 잠재적 문제 완화 조치가 필요합니다. 이러한 인프라 계정은 Org Management 계정과 인프라 OU의 권한 가드레일을 상속합니다. 네트워킹 (및 보안) 팀에서 이 계정의 인프라 대부분을 관리합니다.

네트워크 아키텍처

네트워크 설계 및 세부 사항은 이 문서의 범위를 벗어나지만 다양한 계정 간의 네트워크 연결에는 VPC 피어링, PrivateLink AWS 및 AWS Transit Gateway라는 세 가지 옵션을 사용하는 것이 좋습니다. 이들 중에서 선택할 때 고려해야 할 중요한 사항은 운영 기준, 예산, 특정 대역폭 요구 사항입니다. 

  • VPC 피어링 ‒ 두 VPC를 연결하는 가장 간단한 방법은 VPC 피어링을 사용하는 것입니다. 연결을 통해 VPC 간에 완전한 양방향 연결이 가능합니다. 별도의 계정과 AWS 리전에 있는 VPC도 함께 피어링할 수 있습니다. VPC가 수십, 수백 개인 경우 피어링으로 상호 연결하면 수백, 수천 개의 피어링 연결 메시가 생성되므로 관리 및 확장이 어려울 수 있습니다. VPC 피어링은 한 VPC에 있는 리소스가 다른 VPC의 리소스와 통신해야 하고, 두 VPC 모두의 환경이 제어 및 보호되며, 연결할 VPC의 수가 10개 미만인 경우(각 연결을 개별적으로 관리할 수 있음)에 가장 적합합니다.

  • AWS PrivateLink ‒ VPC, 서비스 및 애플리케이션 간의 프라이빗 연결을 PrivateLink 제공합니다. VPC에서 자체 애플리케이션을 만들고 이를 PrivateLink 고성능 서비스 (엔드포인트 서비스라고 함) 로 구성할 수 있습니다. 기타 AWS 보안 주체는 서비스 유형에 따라 인터페이스 VPC 엔드포인트 또는 Gateway Load Balancer 엔드포인트를 사용하여 VPC에서 엔드포인트 서비스로 이어지는 연결을 생성할 수 있습니다. 를 사용하면 PrivateLink 서비스 트래픽이 공개적으로 라우팅 가능한 네트워크를 통과하지 않습니다. 클라이언트-서버 설정에서 하나 이상의 소비자 VPC에 서비스 공급자 VPC의 특정 서비스 또는 인스턴스 세트에 대한 단방향 액세스 권한을 부여하려는 PrivateLink 경우에 사용합니다. 두 VPC의 클라이언트와 서버의 IP 주소가 겹치는 경우에도 좋은 옵션입니다. 클라이언트 VPC 내에서 엘라스틱 네트워크 인터페이스를 PrivateLink 사용하므로 서비스 공급자와의 IP 충돌이 발생하지 않기 때문입니다. 

  • AWS Transit Gateway ‒ Transit Gateway는 가상 어플라이언스를 프로비저닝할 필요 없이 VPC와 온프레미스 네트워크를 완전관리형 서비스로 연결하기 위한 hub-and-spoke 설계를 제공합니다. AWS는 고가용성 및 확장성을 관리합니다. 전송 게이트웨이는 리전 리소스이며 동일한 AWS 리전 내에 있는 수천 개의 VPC를 연결할 수 있습니다. 하이브리드 연결(VPN 및 AWS Direct Connect 연결)을 단일 전송 게이트웨이에 연결하여 AWS 조직의 전체 라우팅 구성을 한 장소에서 통합 및 제어할 수 있습니다. 전송 게이트웨이는 여러 VPC 피어링 연결을 대규모로 생성하고 관리할 때 발생하는 복잡성을 해결합니다. 이 옵션은 대부분의 네트워크 아키텍처에서 기본값이지만, 비용, 대역폭 및 지연 시간과 관련된 특정 요구 사항의 경우 VPC 피어링이 더 적합할 수 있습니다.

인바운드(수신) VPC

인바운드 VPC는 애플리케이션 외부에서 시작된 네트워크 연결을 허용, 검사 및 라우팅합니다. 애플리케이션의 특성에 따라 이 VPC에서 일부 Network Address Translation(NAT)을 볼 수 있을 것입니다. 이 VPC의 흐름 로그는 캡처되어 Log Archive 계정에 저장됩니다.

아웃바운드(송신) VPC

아웃바운드 VPC는 애플리케이션 내에서 시작된 네트워크 연결을 처리합니다. 애플리케이션의 특성에 따라 이 VPC에서 NAT 트래픽, AWS 서비스별 VPC 엔드포인트, 외부 API 엔드포인트 호스팅을 확인할 수 있습니다. 이 VPC의 흐름 로그는 캡처되어 Log Archive 계정에 저장됩니다.

검사 VPC

전용 검사 VPC는 VPC(동일하거나 다른 AWS 리전에 있음), 인터넷, 온프레미스 네트워크 간 검사 관리에 간소화 및 중앙화된 접근 방식을 제공합니다. AWS SRA의 경우 VPC 간 모든 트래픽이 검사 VPC를 통과하는지 확인하고, 검사 VPC를 다른 워크로드에 사용하지 마세요.

AWS Network Firewall

AWS Network Firewall은 가용성이 뛰어난 VPC용 관리형 네트워크 방화벽 서비스입니다. 스테이트풀 검사, 침입 방지 및 탐지, 웹 필터링을 손쉽게 배포하고 관리하여 AWS의 가상 네트워크를 보호할 수 있습니다. Network Firewall을 사용하여 TLS 세션을 해독하고 인바운드 및 아웃바운드 트래픽을 검사할 수 있습니다. Network Firewall 구성에 대한 자세한 내용은 AWS Network Firewall – New Managed Firewall Service in VPC 블로그 게시물을 참조하세요.

VPC의 가용 영역별로 방화벽을 사용합니다. 각 가용 영역에 대해 트래픽을 필터링하는 방화벽 엔드포인트를 호스팅할 서브넷을 선택합니다. 가용 영역의 방화벽 엔드포인트는 가용 영역이 위치한 서브넷을 제외하고 영역 내의 모든 서브넷을 보호할 수 있습니다. 사용 사례 및 배포 모델에 따라 방화벽 서브넷은 퍼블릭 또는 프라이빗일 수 있습니다. 방화벽은 트래픽 흐름에 완전히 투명하며 Network Address Translation(NAT)을 수행하지 않습니다. 소스 및 대상 주소를 보존합니다. 이 참조 아키텍처에서 방화벽 엔드포인트는 검사 VPC에서 호스팅됩니다. 인바운드 VPC에서 아웃바운드 VPC로 향하는 모든 트래픽은 검사를 위해 이 방화벽 서브넷을 통해 라우팅됩니다. 

Network Firewall을 사용하면 Amazon CloudWatch 지표를 통해 방화벽 활동을 실시간으로 볼 수 있으며, Amazon Simple Storage Service (Amazon S3) 및 Amazon Data Firehose에 로그를 전송하여 네트워크 트래픽의 가시성을 높일 수 있습니다. CloudWatch Network Firewall은 AWS 파트너의 기술을 포함한 기존 보안 접근 방식과의 상호 운용이 가능합니다. 또한 내부적으로 작성되었거나 타사 공급업체 또는 오픈 소스 플랫폼에서 외부 소싱되었을 수 있는 기존 Suricata 규칙 세트를 가져올 수 있습니다. 

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이 east-west(VPC-to-VPC) 또는 north-south(인터넷 송신 및 수신, 온프레미스) 트래픽에 대한 중앙 집중식 VPC에 배포되는 중앙 집중식 배포 모델.

    • Network Firewall이 east-west 트래픽과 north-south 트래픽의 하위 집합에 대한 중앙 집중식 VPC에 배포되는 결합형 배포 모델.

  • 가장 좋은 방법은 Network Firewall 서브넷을 사용하여 다른 서비스를 배포하지 않는 것입니다. 이는 Network Firewall이 방화벽의 서브넷 내 소스 또는 대상에서 오는 트래픽을 검사할 수 없기 때문입니다.

Network Access Analyzer

Network Access Analyzer는 리소스에 대한 의도하지 않은 네트워크 액세스를 식별하는 Amazon VPC의 기능입니다. Network Access Analyzer를 사용하여 네트워크 세분화를 검증하고, 인터넷에서 액세스할 수 있거나 신뢰할 수 있는 IP 주소 범위에서만 액세스할 수 있는 리소스를 식별하고, 모든 네트워크 경로에 적절한 네트워크 제어가 있는지 검증할 수 있습니다.

Network Access Analyzer는 자동 추론 알고리즘을 사용하여 패킷이 AWS 네트워크의 리소스 사이에서 가질 수 있는 네트워크 경로를 분석하고 정의된 네트워크 액세스 범위와 일치하는 경로 조사 결과를 생성합니다. Network Access Analyzer는 네트워크 구성의 정적 분석을 수행합니다. 따라서 이 분석의 일환으로 네트워크에서 패킷이 전송되지 않습니다.

Amazon Inspector Network Reachability 규칙은 관련 기능을 제공합니다. 이러한 규칙에 의해 생성된 조사 결과는 Application 계정에서 사용됩니다. Network Access Analyzer와 Network Reachability는 모두 AWS Provable Security 이니셔티브의 최신 기술을 사용하며, 이 기술을 다양한 중점 분야에 적용합니다. Network Reachability 패키지는 특히 EC2 인스턴스와 해당 인터넷 접근성에 중점을 둡니다. 

네트워크 계정은 AWS 환경에서 들어오고 나가는 트래픽을 제어하는 중요 네트워크 인프라를 정의합니다. 이 트래픽을 면밀하게 모니터링해야 합니다. AWS SRA에서 Network Access Analyzer는 Network 계정 내에서 사용되므로 의도하지 않은 네트워크 액세스를 식별하고, 인터넷 게이트웨이를 통해 인터넷에서 액세스할 수 있는 리소스를 식별하고, 리소스와 인터넷 게이트웨이 사이의 모든 네트워크 경로에 네트워크 방화벽 및 NAT 게이트웨이와 같은 적절한 네트워크 제어가 마련되어 있는지 확인하는 데 도움이 됩니다. 

설계 고려 사항
  • Network Access Analyzer는 Amazon VPC의 기능으로, VPC가 있는 모든 AWS 계정에서 사용할 수 있습니다. 네트워크 관리자는 제한된 범위의 교차 계정 IAM 역할을 사용하여 승인된 네트워크 경로가 각 AWS 계정 내에 적용되는지 검증할 수 있습니다.

AWS RAM

AWS Resource Access Manager(AWS RAM)를 사용하면 하나의 AWS 계정에서 생성한 AWS 리소스를 다른 AWS 계정과 안전하게 공유할 수 있습니다. AWS RAM을 사용하면 중앙 위치에서 리소스 공유를 관리하고 계정 전반에서 경험을 표준화할 수 있습니다. 따라서 관리 및 청구 격리를 활용하면서 리소스를 더욱 쉽게 관리하고, 다중 계정 전략이 제공하는 영향 억제 혜택의 범위를 줄일 수 있습니다. AWS Organizations에서 관리하는 계정인 경우 AWS RAM을 통해 조직의 다른 모든 계정과 리소스를 공유하거나 하나 이상의 지정된 조직 단위(OU)에 포함된 계정과만 리소스를 공유할 수 있습니다. 계정이 조직에 속해 있는지 여부와 관계없이 계정 ID로 특정 AWS 계정과 공유할 수도 있습니다. 지원되는 일부 리소스 유형을 특정 IAM 역할 및 사용자와 공유할 수도 있습니다.

AWS RAM을 사용하면 VPC 서브넷 및 Route 53 규칙과 같이 IAM 리소스 기반 정책을 지원하지 않는 리소스를 공유할 수 있습니다. 추가로 AWS RAM을 사용하면 리소스 소유자는 자신이 공유한 개별 리소스에 액세스할 수 있는 보안 주체를 확인할 수 있습니다. IAM 엔터티는 직접 공유되는 리소스 목록을 검색할 수 있지만, IAM 리소스 정책에서 공유하는 리소스는 검색할 수 없습니다. AWS RAM을 사용하여 AWS 조직 외부에서 리소스를 공유하는 경우 초대 프로세스가 시작됩니다. 수신자가 초대를 수락해야 리소스 액세스가 허가됩니다. 이를 통해 추가 검사와 및 균형이 이루어집니다.

AWS RAM은 공유 리소스가 배포된 계정의 리소스 소유자가 호출하고 관리합니다. AWS SRA에서 보여주는 AWS RAM의 일반적인 사용 사례 중 하나는 네트워크 관리자가 VPC 서브넷 및 전송 게이트웨이를 전체 AWS 조직과 공유하는 것입니다. 이를 통해 AWS 계정 및 네트워크 관리 기능을 분리하고 업무 분리를 달성하는 데 도움이 됩니다. VPC 공유에 대한 자세한 내용은 VPC sharing: A new approach to multiple accounts and VPC management AWS 블로그 게시물과 AWS 네트워크 인프라 백서를 참조하세요. 

설계 고려 사항
  • 서비스형 AWS RAM은 AWS SRA의 Network 계정 내에서만 배포되지만 일반적으로 둘 이상의 계정에 배포됩니다. 예를 들어, 데이터 레이크 관리를 단일 데이터 레이크 계정으로 중앙 집중화한 다음 AWS Lake Formation 데이터 카탈로그 리소스(데이터베이스 및 테이블)를 AWS 조직의 다른 계정과 공유할 수 있습니다. 자세한 내용은 AWS Lake Formation 설명서Securely share your data across AWS accounts using AWS Lake Formation AWS 블로그 게시물을 참조하세요. 또한 보안 관리자는 AWS RAM을 사용하여 AWS Private CA 계층 구조를 구축할 때 모범 사례를 따를 수 있습니다. CA는 외부 타사와 공유할 수 있으며, 타사는 CA 계층 구조에 액세스하지 않고도 인증서를 발급할 수 있습니다. 이를 통해 기존 조직은 타사 액세스를 제한하고 철회할 수 있습니다.

AWS Verified Access

AWS Verified Access는 VPN 없이 기업 애플리케이션에 대한 안전한 액세스를 제공합니다. 사전 정의된 요구 사항을 기준으로 각 액세스 요청을 실시간으로 평가하여 보안 태세를 개선합니다. 자격 증명 데이터디바이스 상태를 기반으로 하는 조건으로 각 애플리케이션에 대한 고유한 액세스 정책을 정의할 수 있습니다. 또한 Verified Access는 관리자가 액세스 정책을 효율적으로 설정하고 모니터링할 수 있도록 지원하여 보안 작업을 간소화합니다. 따라서 정책을 업데이트하고, 보안 및 연결 사고에 대응하고, 규정 준수 표준을 감사할 시간을 확보할 수 있습니다. Verified Access는 SQL 명령어 삽입과 크로스 사이트 스크립팅(XSS) 같은 일반적인 위협을 필터링하는 데 도움이 되도록 AWS WAF 통합을 지원합니다. 검증된 액세스는 사용자가 SAML 기반 타사 자격 증명 공급자 () 를 통해 인증할 수 있는 AWS IAM ID 센터와 원활하게 통합됩니다. IdPs OpenID Connect(OIDC)와 호환되는 사용자 지정 IdP 솔루션이 이미 있는 경우 Verified Access는 IdP에 직접 연결하여 사용자를 인증할 수도 있습니다. Verified Access는 모든 액세스 시도를 로깅하므로 보안 사고 및 감사 요청에 신속하게 대응할 수 있습니다. Verified Access는 이러한 로그를 Amazon Simple Storage Service (Amazon S3), Amazon Logs 및 CloudWatch Amazon Data Firehose로 전송할 수 있도록 지원합니다.

Verified Access는 두 가지 일반적인 기업 애플리케이션 패턴인 내부 및 인터넷 경계를 지원합니다. Verified Access는 Application Load Balancer 또는 탄력적 네트워크 인터페이스를 사용하여 애플리케이션과 통합됩니다. Application Load Balancer를 사용하는 경우 Verified Access에 내부 로드 밸런서가 필요합니다. Verified Access가 인스턴스 수준에서 AWS WAF를 지원하므로 AWS WAF와 Application Load Balancer와 AWS WAF가 통합된 기존 애플리케이션은 정책을 로드 밸런서에서 Verified Access 인스턴스로 이동할 수 있습니다. 기업 애플리케이션은 Verified Access 엔드포인트로 표시됩니다. 각 엔드포인트는 Verified Access 그룹과 연결되며 그룹에 대한 액세스 정책을 상속합니다. Verified Access 그룹은 Verified Access 엔드포인트와 그룹 수준의 확인된 액세스 정책의 모음입니다. 그룹은 정책 관리를 간소화하고 IT 관리자가 기준을 설정할 수 있도록 지원합니다. 애플리케이션 소유자는 애플리케이션의 민감도에 따라 세분화된 정책을 추가로 정의할 수 있습니다.

AWS SRA에서 Verified Access는 네트워크 계정 내에서 호스팅됩니다. 중앙 IT 팀은 중앙에서 관리되는 구성을 설정합니다. 예를 들어 ID 제공업체(예: Okta)와 디바이스 신뢰 제공업체(예: Jamf)와 같은 신뢰 제공자를 연결하고, 그룹을 생성하고, 그룹 수준 정책을 결정할 수 있습니다. 이러한 구성은 AWS Resource Access Manager(AWS RAM)를 사용하여 수십, 수백 또는 수천 개의 워크로드 계정과 공유할 수 있습니다. 이를 통해 애플리케이션 팀은 다른 팀의 오버헤드 없이 애플리케이션을 관리하는 기본 엔드포인트를 관리할 수 있습니다. AWS RAM은 다양한 워크로드 계정에 호스팅되는 기업 애플리케이션에 대해 Verified Access를 활용할 수 있는 확장 가능한 방법을 제공합니다.

설계 고려 사항
  • 보안 요구 사항이 유사한 애플리케이션에 대한 엔드포인트를 그룹화하여 정책 관리를 간소화하고, 이 그룹을 애플리케이션 계정과 공유할 수 있습니다. 그룹 내 모든 애플리케이션은 그룹 정책을 공유합니다. 엣지 케이스 때문에 그룹의 애플리케이션에 특정 정책이 필요한 경우 해당 애플리케이션에 애플리케이션 수준 정책을 적용할 수 있습니다.

Amazon VPC Lattice

Amazon VPC Lattice는 통신을 연결, 모니터링 및 보호하는 애플리케이션 네트워킹 서비스입니다. service-to-service 마이크로서비스라고도 하는 서비스는 특정 작업을 제공하는 독립적으로 배포 가능한 소프트웨어 단위입니다. VPC Lattice는 기본 네트워크 연결, 프런트엔드 로드 밸런서 또는 사이드카 프록시를 관리할 필요 없이 VPC와 AWS 계정 전반의 서비스 간 네트워크 연결 및 애플리케이션 계층 라우팅을 자동으로 관리합니다. 경로 및 헤더와 같은 요청 특성을 기반으로 애플리케이션 수준 라우팅을 제공하는 종합 관리형 애플리케이션 계층 프록시를 제공합니다. VPC Lattice는 VPC 인프라에 구축되어 있으므로 Amazon Elastic Compute Cloud(Amazon EC2), Amazon Elastic Kubernetes Service(Amazon EKS) 및 AWS Lambda와 같은 광범위한 컴퓨팅 유형에서 일관된 접근 방식을 제공합니다. 또한 VPC Lattice는 블루/그린 및 canary 스타일 배포에 대한 가중치 기반 라우팅을 지원합니다. VPC Lattice를 사용하여 서비스 검색 및 연결을 자동으로 구현하는 논리적 경계가 있는 서비스 네트워크를 생성할 수 있습니다. VPC Lattice는 인증 정책을 사용한 service-to-service 인증 및 권한 부여를 위해 AWS ID 및 액세스 관리 (IAM) 와 통합됩니다.

VPC Lattice는 AWS Resource Access Manager(AWS RAM)와 통합되어 서비스 및 서비스 네트워크 공유가 가능합니다. AWS SRA는 개발자 또는 서비스 소유자가 Application 계정에서 VPC Lattice 서비스를 생성하는 분산 아키텍처를 나타냅니다. 서비스 소유자는 인증 정책과 함께 리스너, 라우팅 규칙 및 대상 그룹을 정의합니다. 그런 다음 서비스를 다른 계정과 공유하고, 서비스를 VPC Lattice 서비스 네트워크와 연결합니다. 이러한 네트워크는 네트워크 관리자가 Network 계정에서 생성하고 Application 계정과 공유합니다. 네트워크 관리자는 서비스 네트워크 수준 인증 정책 및 모니터링을 구성합니다. 관리자는 VPC와 VPC Lattice 서비스를 하나 이상의 서비스 네트워크와 연결합니다. 이 분산 아키텍처에 대한 자세한 내용은 Build secure multi-account multi-VPC connectivity for your applications with Amazon VPC Lattice AWS 블로그 게시물을 참조하세요.

설계 고려 사항
  • 조직의 서비스 운영 모델 또는 서비스 네트워크 가시성에 따라 네트워크 관리자는 서비스 네트워크를 공유하고 서비스 소유자에게 서비스 및 VPC를 이러한 서비스 네트워크에 연결할 수 있는 제어 권한을 부여할 수 있습니다. 또는 서비스 소유자가 서비스를 공유하고, 네트워크 관리자는 서비스를 서비스 네트워크에 연결할 수 있습니다.

    클라이언트는 동일한 서비스 네트워크와 연결된 VPC에 있는 경우에만 서비스 네트워크와 연결된 서비스에 요청을 보낼 수 있습니다. VPC 피어링 연결 또는 전송 게이트웨이를 통과하는 클라이언트 트래픽은 거부됩니다.

엣지 보안

엣지 보안에는 일반적으로 보안 콘텐츠 전송, 네트워크 및 애플리케이션 계층 보호, 분산 서비스 거부(DDoS) 완화라는 세 가지 유형의 보호가 수반됩니다. 권장 버전의 TLS를 사용하여 엔드포인트 간 통신을 암호화하여 데이터, 비디오, 애플리케이션, API와 같은 콘텐츠를 빠르고 안전하게 제공해야 합니다. 또한 콘텐츠에는 서명된 URL, 서명된 쿠키 및 토큰 인증을 통한 액세스 제한이 적용되어야 합니다. 애플리케이션 수준 보안은 봇 트래픽을 제어하고, SQL 명령어 삽입 또는 크로스 사이트 스크립팅(XSS)과 같은 일반적인 공격 패턴을 차단하고, 웹 트래픽 가시성을 제공하도록 설계되어야 합니다. 엣지에서 DDoS 완화는 미션 크리티컬 비즈니스 운영 및 서비스의 지속적인 가용성을 보장하는 중요한 방어 계층을 제공합니다. 애플리케이션과 API는 SYN 플러드, UDP 플러드 또는 기타 반사 공격으로부터 보호되어야 하며 기본적인 네트워크 계층 공격을 차단할 수 있는 인라인 완화 기능을 갖추어야 합니다.

AWS는 코어 클라우드부터 AWS 네트워크의 엣지에 이르기까지 안전한 환경을 제공하는 데 도움이 되는 여러 서비스를 제공합니다. 아마존 CloudFront, AWS 인증서 관리자 (ACM), AWS Shield, AWS WAF 및 Amazon Route 53은 서로 협력하여 유연하고 계층화된 보안 경계를 구축할 수 있도록 지원합니다. CloudFrontAmazon에서는 TLSv1.3을 사용하여 최종 사용자 클라이언트와 클라이언트 간의 통신을 암호화하고 보호함으로써 HTTPS를 통해 콘텐츠, API 또는 애플리케이션을 전송할 수 있습니다. CloudFront ACM을 사용하여 사용자 지정 SSL 인증서를 생성하고 배포판에 무료로 배포할 수 있습니다. CloudFront ACM은 인증서 갱신을 자동으로 처리합니다. AWS Shield는 AWS에서 실행되는 애플리케이션을 보호하는 데 도움이 되는 관리형 DDoS 보호 서비스입니다. 애플리케이션 가동 중지와 지연 시간을 최소화하는 동적 탐지 및 자동 인라인 완화 기능을 제공합니다. AWS WAF를 사용하면 특정 조건(IP 주소, HTTP 헤더 및 본문 또는 사용자 지정 URI), 일반적인 웹 공격, 광범위한 봇을 기반으로 웹 트래픽을 필터링하는 규칙을 생성할 수 있습니다. Route 53은 가용성과 확장성이 뛰어난 DNS 웹 서비스입니다. Route 53은 사용자 요청을 AWS 또는 온프레미스에서 실행되는 인터넷 애플리케이션에 연결합니다. AWS SRA는 Network 계정 내에서 호스팅되는 AWS Transit Gateway를 사용하여 중앙 집중화된 네트워크 수신 아키텍처를 채택하므로 엣지 보안 인프라도 이 계정에서 중앙 집중화됩니다.

아마존 CloudFront

CloudFrontAmazon은 일반적인 네트워크 계층 및 전송 DDoS 시도에 대한 고유한 보호 기능을 제공하는 안전한 CDN (콘텐츠 전송 네트워크) 입니다. TLS 인증서를 사용하여 콘텐츠, API 또는 애플리케이션을 배포할 수 있으며, 고급 TLS 기능은 자동으로 활성화됩니다. ACM을 사용하여 사용자 지정 TLS 인증서를 생성하고 CloudFront 최종 사용자 간 HTTPS 통신을 적용할 수 있습니다. 자세한 내용은 ACM 섹션 뒷부분에 설명되어 있습니다. 또한 사용자 지정 오리진과 사용자 지정 오리진 간의 통신에 전송 중 CloudFront 암호화를 구현하도록 요구할 수 있습니다. end-to-end 이 시나리오의 경우 오리진 서버에 TLS 인증서를 설치해야 합니다. 오리진이 탄력적 로드 밸런서인 경우 ACM에서 생성한 인증서 또는 타사 인증 기관(CA)에서 검증하고 ACM으로 가져온 인증서를 사용할 수 있습니다. S3 버킷 웹 사이트 엔드포인트가 오리진으로 사용되는 경우 Amazon S3는 웹 사이트 엔드포인트에 HTTPS를 지원하지 않기 때문에 오리진에 HTTPS를 사용하도록 구성할 CloudFront 수 없습니다. CloudFront (하지만 최종 사용자와 최종 사용자 간에는 여전히 HTTPS를 요구할 수 있습니다.) CloudFront HTTPS 인증서 설치를 지원하는 다른 모든 오리진의 경우 신뢰할 수 있는 타사 CA에서 서명한 인증서를 사용해야 합니다.

CloudFront 콘텐츠에 대한 액세스를 보호하고 제한하기 위한 여러 옵션을 제공합니다. 예를 들어 서명된 URL과 서명된 쿠키를 사용하여 Amazon S3 오리진에 대한 액세스를 제한할 수 있습니다. 자세한 내용은 CloudFront 설명서의 보안 액세스 구성 및 콘텐츠에 대한 액세스 제한을 참조하십시오.

AWS SRA는 네트워크 계정의 중앙 집중식 CloudFront 배포를 보여줍니다. 이는 Transit Gateway를 사용하여 구현된 중앙 집중식 네트워크 패턴과 일치하기 때문입니다. 네트워크 계정에서 배포를 배포하고 CloudFront 관리하면 중앙 집중식 제어의 이점을 얻을 수 있습니다. 모든 CloudFront 배포를 한 곳에서 관리할 수 있으므로 모든 계정의 액세스를 제어하고, 설정을 구성하고, 사용량을 모니터링하기가 더 쉬워집니다. 또한 하나의 중앙 계정에서 ACM 인증서, DNS 레코드 및 CloudFront 로깅을 관리할 수 있습니다. CloudFront 보안 대시보드는 배포판에서 직접 AWS WAF 가시성과 제어 기능을 제공합니다. CloudFront 애플리케이션의 주요 보안 트렌드, 허용 및 차단된 트래픽, 봇 활동을 파악할 수 있습니다. 시각적 로그 분석기 및 내장된 차단 제어와 같은 조사 도구를 사용하여 로그를 쿼리하거나 보안 규칙을 작성하지 않고도 트래픽 패턴을 분리하고 트래픽을 차단할 수 있습니다.

설계 고려 사항
  • 또는 애플리케이션 계정에서 애플리케이션의 CloudFront 일부로 배포할 수도 있습니다. 이 시나리오에서 응용 프로그램 팀은 배포 방법 등을 결정하고 적절한 캐시 정책을 결정하며 배포의 거버넌스, 감사 및 모니터링을 담당합니다. CloudFront CloudFront 여러 계정에 분산하여 CloudFront 배포하면 추가 서비스 할당량을 활용할 수 있습니다. 또 다른 이점은 고유의 자동 원본 액세스 ID (OAI) 및 원본 액세스 제어 (OAC) 구성을 사용하여 CloudFront Amazon S3 원본에 대한 액세스를 제한할 수 있다는 것입니다.

  • 와 같은 CloudFront CDN을 통해 웹 콘텐츠를 전송할 때는 시청자가 CDN을 우회하여 원본 콘텐츠에 직접 액세스하는 것을 방지해야 합니다. 이러한 오리진 액세스 제한을 달성하려면 요청을 사용자 지정 오리진에 전달하기 전에, AWS WAF를 사용하여 CloudFront 사용자 지정 헤더를 추가하고 헤더를 확인할 수 있습니다. 이 솔루션에 대한 자세한 설명은 AWS 보안 블로그 게시물 AWS WAF 및 AWS Secrets Manager를 사용하여 Amazon CloudFront 오리진 보안을 강화하는 방법을 참조하십시오. 또 다른 방법은 Application Load Balancer와 연결된 보안 그룹의 CloudFront 접두사 목록만 제한하는 것입니다. 이렇게 하면 CloudFront 배포본만 로드 밸런서에 액세스할 수 있습니다.

AWS WAF

AWS WAF는 애플리케이션 가용성에 영향을 미치거나, 보안을 손상시키거나, 과도한 리소스를 소비할 수 있는 공통 취약성 및 봇과 같은 웹 악용으로부터 웹 애플리케이션을 보호하는 데 도움이 됩니다. 아마존 CloudFront 배포판, 아마존 API 게이트웨이 REST API, 애플리케이션 로드 밸런서, AWS GraphQL AppSync API, 아마존 Cognito 사용자 풀 및 AWS 앱 러너 서비스와 통합될 수 있습니다.

AWS WAF는 웹 액세스 제어 목록(ACL)을 사용하여 AWS 리소스 집합을 보호합니다. 웹 ACL은 검사 기준, 그리고 웹 요청이 기준을 충족하는 경우 취해야 할 관련 조치(차단, 허용, 계산 또는 Bot Control 실행)를 정의하는 일련의 규칙입니다. AWS WAF는 일반적인 애플리케이션 취약성으로부터 보호하는 일련의 관리형 규칙을 제공합니다. 이러한 규칙은 AWS와 AWS 파트너가 선별 및 관리합니다. 또한 AWS WAF는 사용자 지정 규칙 작성을 위한 강력한 규칙 언어를 제공합니다. 사용자 지정 규칙을 사용하여 특정 요구 사항에 맞는 검사 기준을 작성할 수 있습니다. IP 제한, 지리적 제한, 특정 애플리케이션 동작에 더 적합한 관리형 규칙의 사용자 지정 버전 등을 예로 들 수 있습니다.

AWS WAF는 공통 및 대상 지정 봇과 계정 탈취 보호(ATP)에 대한 지능형 등급 관리 규칙 세트를 제공합니다. Bot Control 및 ATP 규칙 그룹을 사용하는 경우 구독 요금과 트래픽 검사 요금이 부과됩니다. 따라서 트래픽을 먼저 모니터링하고 무엇을 사용할지 결정하는 것이 좋습니다. AWS WAF 콘솔에서 무료로 제공되는 봇 관리 및 계정 탈취 대시보드를 사용하여 이러한 활동을 모니터링한 다음 지능형 계층 AWS WAF 규칙 그룹이 필요한지 여부를 결정할 수 있습니다.

AWS SRA에서는 AWS WAF가 네트워크 CloudFront 계정과 통합됩니다. 이 구성에서 WAF 규칙 처리는 VPC 내부가 아닌 엣지 로케이션에서 발생합니다. 이를 통해 콘텐츠를 요청한 최종 사용자와 가까운 곳에서 악성 트래픽을 필터링할 수 있고, 코어 네트워크로 들어오는 악성 트래픽을 제한할 수 있습니다.

S3 버킷에 대한 교차 계정 액세스를 구성하여 로그 아카이브 계정의 S3 버킷으로 전체 AWS WAF 로그를 보낼 수 있습니다. 자세한 내용은 이 주제에 대한 AWS re:Post 문서를 참조하세요.

설계 고려 사항
  • Network 계정에서 중앙 집중식으로 AWS WAF를 배포하는 대신 Application 계정에 AWS WAF를 배포하는 것이 더 나은 사용 사례도 있습니다. 예를 들어 애플리케이션 계정에 배포를 배포하거나 공용 애플리케이션 로드 밸런서를 사용하는 경우 또는 웹 애플리케이션 앞에서 Amazon API Gateway를 사용하는 경우 이 옵션을 선택할 수 있습니다. CloudFront 각 Application 계정에 AWS WAF를 배포하기로 한 경우, AWS Firewall Manager를 사용하여 중앙 집중식 Security Tooling 계정에서 해당 계정의 AWS WAF 규칙을 관리합니다.

  • 또한 CloudFront 계층에 일반 AWS WAF 규칙을 추가하고 Application Load Balancer 또는 API 게이트웨이와 같은 지역 리소스에 애플리케이션별 AWS WAF 규칙을 추가할 수 있습니다.

AWS Shield

AWS Shield는 AWS에서 실행되는 애플리케이션을 보호하는 관리형 DDoS 보호 서비스입니다. Shield에는 Shield Standard와 Shield Advanced, 두 가지 계층이 있습니다. Shield Standard는 모든 AWS 고객에게 추가 비용 없이 가장 일반적인 인프라(계층 3 및 4) 이벤트에 대한 보호를 제공합니다. Shield Advanced는 보호되는 Amazon Elastic Compute Cloud (Amazon EC2), 엘라스틱 로드 밸런싱 (ELB), 아마존, AWS Global CloudFront Accelerator 및 Route 53 호스팅 영역의 애플리케이션을 대상으로 하는 무단 이벤트에 대한 보다 정교한 자동 완화 기능을 제공합니다. 가시성이 높은 웹 사이트를 소유하고 있거나 잦은 DDoS 공격이 발생하는 경우 Shield Advanced가 제공하는 추가 기능을 고려해 보세요.

Shield Advanced의 자동 애플리케이션 계층 DDoS 방어 기능을 사용하여 보호된 CloudFront 배포와 애플리케이션 로드 밸런서에 대한 애플리케이션 계층 (계층 7) 공격을 완화하기 위해 자동으로 대응하도록 Shield Advanced를 구성할 수 있습니다. 이 기능을 활성화하면 Shield Advanced는 사용자 지정 AWS WAF 규칙을 자동으로 생성하여 DDoS 공격을 완화합니다. 또한 Shield Advanced는 AWS Shield 대응 팀(SRT)에 대한 액세스를 제공합니다. 진행 중인 DDoS 공격 중에 언제든지 SRT에 문의하여 애플리케이션에 대한 사용자 지정 완화 기능을 만들고 관리할 수 있습니다. SRT에서 보호되는 리소스를 사전에 모니터링하고 DDoS 시도 중에 연락을 취하도록 하려면 사전 참여 기능을 활성화하는 것이 좋습니다.

설계 고려 사항
  • Amazon, Application Load Balancer 또는 Network CloudFront Load Balancer와 같이 애플리케이션 계정의 인터넷 연결 리소스가 앞에 있는 워크로드가 있는 경우 애플리케이션 계정에서 Shield Advanced를 구성하고 해당 리소스를 Shield 보호에 추가하십시오. AWS Firewall Manager를 사용하여 이러한 옵션을 대규모로 구성할 수 있습니다.

  • Application Load Balancer 앞에 CloudFront 배포하는 것과 같이 데이터 흐름에 여러 리소스가 있는 경우 진입점 리소스만 보호된 리소스로 사용하십시오. 이렇게 하면 두 리소스에 대해 Shield 데이터 전송(DTO) 요금을 두 번 지불하지 않아도 됩니다.

  • Shield Advanced는 아마존에서 모니터링할 수 있는 지표를 CloudWatch 기록합니다. (자세한 내용은 AWS 설명서의 AWS Shield Advanced 지표 및 경보를 참조하세요.) DDoS 이벤트가 탐지되면 보안 센터로 SNS 알림을 수신하도록 CloudWatch 경보를 설정하십시오. DDoS 이벤트가 의심되는 경우 지원 티켓을 제출하고 가장 높은 우선순위를 지정하여 AWS Enterprise Support 팀에 문의하세요. Enterprise Support 팀은 이벤트 처리 시 Shield 대응 팀(SRT)을 포함할 것입니다. 추가로 지원 티켓을 생성하고 SRT 팀에 이메일을 보내도록 AWS Shield 참여 Lambda 함수를 사전 구성할 수 있습니다.

AWS Certificate Manager

AWS Certificate Manager(ACM)를 사용하여 AWS 서비스 및 내부의 연결된 리소스에 사용할 퍼블릭 및 프라이빗 TLS 인증서를 프로비저닝, 관리 및 배포할 수 있습니다. ACM을 사용하면 인증서를 신속하게 요청하여 Elastic Load Balancing 로드 밸런서, 아마존 배포판, CloudFront Amazon API Gateway의 API와 같은 ACM 통합 AWS 리소스에 배포하고 인증서 갱신은 ACM이 처리하도록 할 수 있습니다. ACM 퍼블릭 인증서를 요청하면 키 페어 또는 인증서 서명 요청(CSR)을 생성하거나, 인증 기관(CA)에 CSR을 제출하거나, 인증서를 받은 후 업로드하고 설치할 필요가 없습니다. 또한 ACM은 타사 CA에서 발급한 TLS 인증서를 가져와 ACM 통합 서비스에 배포할 수 있는 옵션을 제공합니다. ACM을 사용하여 인증서를 관리하는 경우 강력한 암호화 및 키 관리 모범 사례를 사용하여 인증서 프라이빗 키를 안전하게 보호하고 저장합니다. ACM을 사용하면 퍼블릭 인증서 프로비저닝에 대한 추가 비용이 없으며, ACM에서 갱신 프로세스를 관리합니다.

ACM은 네트워크 계정에서 공개 TLS 인증서를 생성하는 데 사용되며, 이 인증서는 배포판에서 최종 사용자와 사용자 간의 HTTPS 연결을 설정하는 데 사용됩니다. CloudFront CloudFront 자세한 내용은 설명서를 참조하십시오. CloudFront

설계 고려 사항
  • 외부 인증서의 경우 ACM은 인증서를 프로비저닝하는 리소스와 동일한 계정에 있어야 합니다. 인증서는 계정 간에 공유될 수 없습니다.

Amazon Route 53

Amazon Route 53는 가용성과 확장성이 뛰어난 DNS 웹 서비스입니다. Route 53을 사용하여 세 가지 주요 기능, 즉 도메인 등록, DNS 라우팅, 상태 확인을 실행할 수 있습니다.

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 and Access Management(IAM) 서비스를 사용하면 DNS 데이터를 업데이트할 수 있는 사람을 세부적으로 제어할 수 있습니다. DNS Security Extensions(DNSSEC) 서명을 활성화하여 DNS 해석기가 DNS 응답이 Route 53에서 왔으며 변조되지 않았는지 검증할 수 있습니다.

Route 53 Resolver DNS Firewall은 VPC의 아웃바운드 DNS 요청을 보호합니다. 이러한 요청은 도메인 이름 해석을 위해 Route 53 Resolver를 통과합니다. DNS 방화벽 보호의 주된 용도는 데이터의 DNS 유출을 방지하는 것입니다. DNS 방화벽을 사용하면 애플리케이션에서 쿼리할 수 있는 도메인을 모니터링하고 제어할 수 있습니다. 잘못된 것으로 알고 있는 도메인에 대한 액세스를 거부하고 다른 모든 쿼리가 통과하도록 허용할 수 있습니다. 또는 명시적으로 신뢰하는 도메인을 제외한 모든 도메인에 대한 액세스를 거부할 수 있습니다. DNS 방화벽을 사용하여 VPC 엔드포인트 이름을 포함하여 프라이빗 호스팅 영역(공유 또는 로컬 호스팅 영역)의 리소스에 대한 해석 요청을 차단할 수도 있습니다. 또한 퍼블릭 또는 프라이빗 EC2 인스턴스 이름에 대한 요청을 차단할 수도 있습니다.

Route 53 해석기는 기본적으로 모든 VPC의 일부분으로 생성됩니다. AWS SRA에서 Route 53은 Network 계정에서 주로 DNS 방화벽 기능에 사용됩니다. 

설계 고려 사항
  • DNS Firewall 및 AWS Network Firewall 모두 도메인 이름 필터링을 제공하지만 트래픽 유형이 다릅니다. DNS Firewall과 Network Firewall을 함께 사용하면 서로 다른 두 네트워크 경로에서 애플리케이션 계층 트래픽에 대한 도메인 기반 필터링을 구성할 수 있습니다.

    • DNS 방화벽은 VPC 내의 애플리케이션에서 Route 53 Resolver를 통과하는 아웃바운드 DNS 쿼리에 대한 필터링을 제공합니다. 쿼리에 대한 사용자 지정 응답을 차단된 도메인 이름에 전송하도록 DNS 방화벽을 구성할 수도 있습니다.

    • Network Firewall은 네트워크 및 애플리케이션 계층 트래픽 모두에 대한 필터링을 제공하지만 Route 53 Resolver에서 만든 쿼리는 표시하지 않습니다.