기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 중앙 집중식 인바운드 검사
인터넷 연결 애플리케이션은 본질적으로 공격 표면이 더 크며 대부분의 다른 유형의 애플리케이션은 직면할 필요가 없는 위협 범주에 노출됩니다. 이러한 유형의 애플리케이션에 대한 공격으로부터 필요한 보호를 확보하고 영향 영역을 최소화하는 것은 모든 보안 전략의 핵심 부분입니다.
랜딩 존에 애플리케이션을 배포하면 퍼블릭 로드 밸런서, API 게이트웨이 또는 인터넷 게이트웨이를 통해 퍼블릭 인터넷(예: 콘텐츠 전송 네트워크(CDN) 또는 퍼블릭 웹 애플리케이션을 통해)을 통해 사용자가 많은 앱에 액세스할 수 있습니다. 이 경우 인바운드 애플리케이션 검사에 AWS Web Application Firewall(AWS WAF)을 사용하거나 Gateway Load Balancer 또는를 사용하여 IDS/IPS 인바운드 검사를 사용하여 워크로드와 애플리케이션을 보호할 수 있습니다 AWS Network Firewall.
랜딩 존에 애플리케이션을 계속 배포함에 따라 인바운드 인터넷 트래픽을 검사해야 할 수도 있습니다. 타사 방화벽 어플라이언스를 실행하는 Gateway Load Balancer를 사용하거나 오픈 소스 Suricata 규칙을 사용하여 AWS Network Firewall 고급 DPI 및 IDS/IPS 기능을 사용하여 분산, 중앙 집중식 또는 결합된 검사 아키텍처를 사용하는 등 다양한 방법으로 이를 달성할 수 있습니다. 이 섹션에서는 트래픽 라우팅을 위한 중앙 허브 AWS Transit Gateway 역할을 사용하여 중앙 집중식 배포 AWS Network Firewall 에서 Gateway Load Balancer와를 모두 다룹니다.
## AWS WAF 인터넷의 인바운드 트래픽 검사를 AWS Firewall Manager 위한 및
AWS WAF 는 가용성에 영향을 미치거나, 보안을 손상시키거나, 과도한 리소스를 소비할 수 있는 일반적인 웹 악용 및 봇으로부터 웹 애플리케이션 또는 APIs를 보호하는 데 도움이 되는 웹 애플리케이션 방화벽입니다. AWS WAF 는 봇 트래픽을 제어하고 SQL 삽입 또는 교차 사이트 스크립팅(XSS)과 같은 일반적인 공격 패턴을 차단하는 보안 규칙을 생성할 수 있도록 하여 트래픽이 애플리케이션에 도달하는 방식을 제어할 수 있도록 합니다. 특정 트래픽 패턴을 필터링하는 규칙을 사용자 지정할 수도 있습니다.
AWS WAF CDN 솔루션, 웹 서버 앞에 있는 Application Load Balancer, REST API용 Amazon API Gateway 또는 GraphQL API의 일부로 Amazon Amazon CloudFront AWS AppSync 에 배포할 수 있습니다. APIs GraphQL APIs
배포한 후에는 시각적 규칙 빌더 AWS WAF, JSON 코드,에서 유지 관리하는 관리형 규칙을 사용하여 자체 트래픽 필터 규칙을 생성하거나 AWS에서 타사 규칙을 구독할 수 있습니다 AWS Marketplace. 이러한 규칙은 지정된 패턴에 대해 트래픽을 평가하여 원치 않는 트래픽을 필터링할 수 있습니다. Amazon CloudWatch를 사용하여 수신 트래픽 지표를 모니터링하고 로깅할 수 있습니다.
의 모든 계정 및 애플리케이션에서 중앙 집중식 관리를 위해 AWS Organizations를 사용할 수 있습니다 AWS Firewall Manager. AWS Firewall Manager 는 방화벽 규칙을 중앙에서 구성하고 관리할 수 있는 보안 관리 서비스입니다. 새 애플리케이션이 생성되면는 공통 보안 규칙 세트를 적용하여 새 애플리케이션과 리소스를 AWS Firewall Manager 쉽게 규정 준수 상태로 만들 수 있습니다.
AWS Firewall Manager를 사용하면 Application Load Balancer, API Gateway 인스턴스 및 Amazon CloudFront distributions. AWS Firewall Manager integrate AWS Managed Rules 에 대한 AWS WAF 규칙을 쉽게 롤아웃할 수 AWS WAF있으므로 애플리케이션에 사전 구성되고 큐레이션된 AWS WAF 규칙을 쉽게 배포할 수 있습니다. AWS WAF 를 사용하여 중앙에서 관리하는 방법에 대한 자세한 내용은를 사용하여 [중앙에서 관리 AWS WAF (API v2) 및 AWS Managed Rules 대규모로 AWS Firewall Manager](https://aws.amazon.com/blogs/security/centrally-manage-aws-waf-api-v2-and-aws-managed-rules-at-scale-with-firewall-manager/) 관리를 AWS Firewall Manager참조하세요.
![\[를 사용한 중앙 집중식 인바운드 트래픽 검사를 보여주는 다이어그램 AWS WAF\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/inbound-traffic-inspection-with-waf.png)
이전 아키텍처에서 애플리케이션은 프라이빗 서브넷의 여러 가용 영역에 있는 Amazon EC2 인스턴스에서 실행됩니다. Amazon EC2 인스턴스 앞에 퍼블릭 Application Load Balancer(ALB)가 배포되어 서로 다른 대상 간에 요청을 로드 밸런싱합니다. AWS WAF 는 ALB와 연결됩니다.
### 장점
+ [AWS WAF Bot Control](https://aws.amazon.com/waf/features/bot-control/)을 사용하면 애플리케이션에 대한 일반 및 퍼베이시브 봇 트래픽을 파악하고 제어할 수 있습니다.
+ [용 관리형 규칙을 AWS WAF](https://aws.amazon.com/marketplace/solutions/security/waf-managed-rules) 사용하면 웹 애플리케이션 또는 APIs 빠르게 시작하고 일반적인 위협으로부터 보호할 수 있습니다. 오픈 웹 애플리케이션 보안 프로젝트(OWASP) 상위 10개 보안 위험, WordPress 또는 Joomla와 같은 콘텐츠 관리 시스템(CMS)과 관련된 위협, 심지어 새로운 일반 취약성 및 노출(CVE)과 같은 문제를 해결하는 규칙 유형 등 다양한 규칙 유형 중에서 선택할 수 있습니다. 관리형 규칙은 새로운 문제가 발생하면 자동으로 업데이트되므로 애플리케이션 구축에 더 많은 시간을 할애할 수 있습니다.
+ AWS WAF 는 관리형 서비스이며이 아키텍처에서 검사하는 데 어플라이언스가 필요하지 않습니다. 또한 [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/)를 통해 거의 실시간에 가까운 로그를 제공합니다. 웹 트래픽에 대한 거의 실시간 가시성을 AWS WAF 제공하여 Amazon CloudWatch에서 새 규칙 또는 알림을 생성하는 데 사용할 수 있습니다.
### 주요 고려 사항
+ 이 아키텍처는 ALB당, CloudFront 배포 및 API Gateway에 AWS WAF 통합되어 있으므로 HTTP 헤더 검사 및 분산 검사에 가장 적합합니다.는 요청 본문을 로깅하지 AWS WAF 않습니다.
+ 두 번째 ALB 세트(있는 경우)로 이동하는 트래픽은 두 번째 ALB 세트에 대해 새 요청이 이루어지기 때문에 동일한 AWS WAF 인스턴스에서 검사되지 않을 수 있습니다.
# 타사 어플라이언스를 사용한 중앙 집중식 인바운드 검사
이 아키텍처 설계 패턴에서는 별도의 검사 VPC의 Application/Network Load Balancer와 같은 Elastic Load Balancer(ELB) 뒤의 여러 가용 영역에 걸쳐 Amazon EC2에 타사 방화벽 어플라이언스를 배포합니다.
검사 VPC는 다른 스포크 VPCs와 함께 전송 게이트웨이를 통해 VPC 연결로 함께 연결됩니다. 스포크 VPCs의 애플리케이션은 애플리케이션 유형에 따라 ALB 또는 NLB일 수 있는 내부 ELB의 프런트엔드입니다. 인터넷을 통한 클라이언트는 트래픽을 방화벽 어플라이언스 중 하나로 라우팅하는 검사 VPC에 있는 외부 ELB의 DNS에 연결됩니다. 방화벽은 트래픽을 검사한 다음 다음 그림과 같이 내부 ELB의 DNS를 사용하여 Transit Gateway를 통해 스포크 VPC로 트래픽을 라우팅합니다. 타사 어플라이언스를 사용한 인바운드 보안 검사에 대한 자세한 내용은 [타사 방화벽 어플라이언스를 AWS 환경으로 통합하는 방법](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-integrate-third-party-firewall-appliances-into-an-aws-environment/) 블로그 게시물을 참조하세요.
![\[타사 어플라이언스 및 ELB를 사용한 중앙 집중식 수신 트래픽 검사를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/ingress-inspection-third-party.png)
## 장점
+ 이 아키텍처는 타사 방화벽 어플라이언스를 통해 제공되는 검사 및 고급 검사 기능을 위한 모든 애플리케이션 유형을 지원할 수 있습니다.
+ 이 패턴은 방화벽 어플라이언스에서 스포크 VPCs로의 DNS 기반 라우팅을 지원하므로 스포크 VPCs의 애플리케이션이 ELB 뒤에서 독립적으로 확장될 수 있습니다.
+ ELB와 함께 Auto Scaling을 사용하여 검사 VPC에서 방화벽 어플라이언스를 조정할 수 있습니다.
## 주요 고려 사항
+ 고가용성을 위해 가용 영역에 여러 방화벽 어플라이언스를 배포해야 합니다.
+ 흐름 대칭을 유지하려면 방화벽을 로 구성하고 소스 NAT를 수행해야 합니다. 즉, 클라이언트 IP 주소가 애플리케이션에 표시되지 않습니다.
+ Network Services 계정에 Transit Gateway 및 Inspection VPC를 배포하는 것이 좋습니다.
+ 추가 타사 공급업체 방화벽 라이선스/지원 비용. Amazon EC2 요금은 인스턴스 유형에 따라 다릅니다.
# Gateway Load Balancer에서 방화벽 어플라이언스를 사용하여 인터넷의 인바운드 트래픽 검사
고객은 심층 방어 전략의 일부로 타사 차세대 방화벽(NGFW) 및 침입 방지 시스템(IPS)을 사용합니다. 일반적으로 이러한 방화벽은 전용 하드웨어 또는 소프트웨어/가상 어플라이언스인 경우가 많습니다. 다음 그림과 같이 Gateway Load Balancer를 사용하여 이러한 가상 어플라이언스를 수평으로 확장하여 VPC에서 송수신되는 트래픽을 검사할 수 있습니다.
![\[Gateway Load Balancer와 함께 방화벽 어플라이언스를 사용한 중앙 집중식 수신 트래픽 검사를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/ingress-inspection-fa.png)
앞의 아키텍처에서 Gateway Load Balancer 엔드포인트는 별도의 엣지 VPC의 각 가용 영역에 배포됩니다. 차세대 방화벽, 침입 방지 시스템 등이 중앙 집중식 어플라이언스 VPC의 Gateway Load Balancer 뒤에 배포됩니다. 이 어플라이언스 VPC는 스포크 VPCs 또는 다른 AWS 계정에 있을 수 있습니다. 가상 어플라이언스는 Auto Scaling 그룹을 사용하도록 구성할 수 있으며 Gateway Load Balancer에 자동으로 등록되므로 보안 계층의 Auto Scaling이 가능합니다.
이러한 가상 어플라이언스는 인터넷 게이트웨이(IGW)를 통해 관리 인터페이스에 액세스하거나 어플라이언스 VPC의 접속 호스트 설정을 사용하여 관리할 수 있습니다.
VPC 수신 라우팅 기능을 사용하면 인터넷에서 Gateway Load Balancer 뒤의 방화벽 어플라이언스로 인바운드 트래픽을 라우팅하도록 엣지 라우팅 테이블이 업데이트됩니다. 검사된 트래픽은 Gateway Load Balancer 엔드포인트를 통해 대상 VPC 인스턴스로 라우팅됩니다. [AWS Gateway Load Balancer를 사용하는 다양한 방법에 대한 자세한 내용은 Gateway Load Balancer 소개: 지원되는 아키텍처 패턴](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/) 블로그 게시물을 참조하세요. Load Balancer
# 중앙 집중식 수신 AWS Network Firewall 에 사용
이 아키텍처에서 수신 트래픽은 나머지 VPCs에 도달 AWS Network Firewall 하기 전에에서 검사합니다. 이 설정에서는 Edge VPC에 배포된 모든 방화벽 엔드포인트 간에 트래픽이 분할됩니다. 방화벽 엔드포인트와 Transit Gateway 서브넷 사이에 퍼블릭 서브넷을 배포합니다. 스포크 VPCs에 IP 대상이 포함된 ALB 또는 NLB를 사용할 수 있으며, 그 뒤에 있는 대상에 대한 Auto Scaling을 처리할 수 있습니다.
![\[AWS Network Firewall을 사용한 수신 트래픽 검사를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/ingress-inspection-using-aws-nf.png)
AWS Network Firewall 이 모델에서의 배포 및 관리를 간소화하기 위해를 사용할 수 AWS Firewall Manager 있습니다. Firewall Manager를 사용하면 중앙 위치에서 생성한 보호를 여러 계정에 자동으로 적용하여 여러 방화벽을 중앙에서 관리할 수 있습니다. Firewall Manager는 Network Firewall에 대한 분산 배포 모델과 중앙 집중식 배포 모델을 모두 지원합니다. 블로그 게시물 [AWS Network Firewall 를 사용하여 배포하는 방법은 AWS Firewall Manager](https://aws.amazon.com/blogs/security/how-to-deploy-aws-network-firewall-by-using-aws-firewall-manager/) 모델에 대한 자세한 내용을 제공합니다.
## 를 사용한 심층 패킷 검사(DPI) AWS Network Firewall
Network Firewall은 수신 트래픽에 대해 심층 패킷 검사(DPI)를 수행할 수 있습니다. Network Firewall은 (ACM)에 저장된 전송 계층 보안 AWS Certificate Manager (TLS) 인증서를 사용하여 패킷을 해독하고, DPI를 수행하고, 패킷을 다시 암호화할 수 있습니다. Network Firewall을 사용하여 DPI를 설정하는 데는 몇 가지 고려 사항이 있습니다. 먼저 신뢰할 수 있는 TLS 인증서를 ACM에 저장해야 합니다. 둘째, 복호화 및 재암호화를 위해 패킷을 올바르게 전송하도록 Network Firewall 규칙을 구성해야 합니다. 자세한 내용은 블로그 게시물 [TLS 검사 구성에서 암호화된 트래픽 및 AWS Network Firewall](https://aws.amazon.com/blogs/security/tls-inspection-configuration-for-encrypted-traffic-and-aws-network-firewall/)를 참조하세요.
## 중앙 집중식 수신 아키텍처 AWS Network Firewall 에서의 주요 고려 사항
+ Edge VPC의 Elastic Load Balancing은 호스트 이름이 아닌 대상 유형으로만 IP 주소를 가질 수 있습니다. 위 그림에서 대상은 스포크 VPC에 있는 Network Load Balancer의 프라이빗 IPs입니다. VPCs 엣지 VPC에서 ELB 뒤의 IP 대상을 사용하면 Auto Scaling이 손실됩니다.
+ 를 방화벽 엔드포인트에 대한 단일 창 AWS Firewall Manager 으로 사용하는 것이 좋습니다.
+ 이 배포 모델은 엣지 VPC에 들어갈 때 트래픽 검사를 올바르게 사용하므로 검사 아키텍처의 전체 비용을 줄일 수 있습니다.