기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 공격 표면 감소
AWS 솔루션을 설계할 때 고려해야 할 또 다른 중요한 사항은 공격자가 애플리케이션을 표적으로 삼을 기회를 제한하는 것입니다. 이 개념을 공격 *표면* 감소라고 합니다. 인터넷에 노출되지 않은 리소스는 공격하기가 더 어려우므로 공격자가 애플리케이션의 가용성을 목표로 삼을 수 있는 옵션이 제한됩니다.
예를 들어 사용자가 특정 리소스와 직접 상호 작용할 것으로 예상되지 않는 경우 인터넷에서 해당 리소스에 액세스할 수 없도록 하세요. 마찬가지로 통신에 필요하지 않은 포트나 프로토콜을 통해 사용자나 외부 애플리케이션이 보내는 트래픽을 수락하지 마세요.
다음 섹션에서는 공격 표면을 줄이고 애플리케이션의 인터넷 노출을 제한하는 방법을 안내하는 모범 사례를 AWS 제공합니다.
# AWS 리소스 난독화 (,,) BP1 BP4 BP5
일반적으로 사용자는 AWS 리소스를 인터넷에 완전히 노출하지 않고도 애플리케이션을 빠르고 쉽게 사용할 수 있습니다.
# 보안 그룹 및 네트워크 ACLs (BP5)
Amazon Virtual Private Cloud (AmazonVPC) 를 사용하면 정의한 가상 네트워크에서 AWS 리소스를 시작할 수 AWS 클라우드 있는 논리적으로 격리된 구역을 프로비저닝할 수 있습니다.
보안 그룹과 ACLs 네트워크는 조직 내 AWS 리소스에 대한 액세스를 제어할 수 있다는 점에서 비슷합니다VPC. 그러나 보안 그룹을 사용하면 인스턴스 수준에서 인바운드 및 아웃바운드 트래픽을 제어할 수 있는 반면, 네트워크는 VPC 서브넷 수준에서 유사한 기능을 ACLs 제공합니다. 보안 그룹 또는 네트워크 사용에 따른 추가 요금은 없습니다. ACLs
인스턴스를 시작할 때 보안 그룹을 지정할지 또는 나중에 인스턴스를 보안 그룹과 연결할 것인지 선택할 수 있습니다. 트래픽을 *허용하는 허용* 규칙을 만들지 않는 한 보안 그룹에 대한 모든 인터넷 트래픽은 암시적으로 거부됩니다.
예를 들어, Elastic Load Balancer 뒤에 Amazon EC2 인스턴스가 있는 경우 인스턴스 자체는 공개적으로 액세스할 수 없고 IPs 비공개로만 가능해야 합니다. 대신, 대상 그룹 서브넷의 네트워크 액세스 제어 목록 () 과 함께 0.0.0.0/0에 대한 액세스를 허용하는 보안 그룹 규칙 (아래 참고 참조) 을 사용하여 Elastic Load Balancer IP 범위만 인스턴스와 통신하도록 허용하는 보안 그룹 규칙을 사용하여 Elastic Load Balancer에 필요한 대상 수신기 포트에 대한 액세스 권한을 제공할 수 있습니다. NACL 이렇게 하면 인터넷 트래픽이 Amazon EC2 인스턴스와 직접 통신할 수 없으므로 공격자가 애플리케이션에 대해 알아내고 애플리케이션에 영향을 미치기가 더 어려워집니다.
네트워크를 ACLs 생성할 때 허용 및 거부 규칙을 모두 지정할 수 있습니다. 이는 애플리케이션에 대한 특정 유형의 트래픽을 명시적으로 거부하려는 경우에 유용합니다. 예를 들어 전체 서브넷에 대한 액세스가 거부되는 IP 주소 (CIDR범위), 프로토콜 및 대상 포트를 정의할 수 있습니다. 애플리케이션이 트래픽에만 사용되는 경우 모든 TCP UDP 트래픽을 거부하거나 그 반대의 규칙을 만들 수 있습니다. 이 옵션을 사용하면 소스 IPs 또는 기타 시그니처를 알면 DDoS 공격을 완화하는 규칙을 직접 만들 수 있으므로 공격에 대응할 때 유용합니다.
를 구독하는 AWS Shield Advanced경우 엘라스틱 IP 주소를 보호된 리소스로 등록할 수 있습니다. DDoS보호 리소스로 등록된 엘라스틱 IP 주소에 대한 공격은 더 빠르게 탐지되므로 방어 시간이 더 빨라질 수 있습니다. 공격이 탐지되면 DDoS 방어 시스템은 대상 엘라스틱 IP 주소에 ACL 해당하는 네트워크를 읽고 서브넷 수준이 아닌 AWS 네트워크 경계에서 적용합니다. 이렇게 하면 여러 인프라 계층 공격으로 인한 영향을 받을 위험이 크게 줄어듭니다. DDoS
DDoS복원력을 ACLs 최적화하도록 보안 그룹과 네트워크를 구성하는 [방법에 대한 자세한 내용은 공격 표면을 줄여 DDoS 공격에 대비하는 방법을](https://aws.amazon.com/blogs/security/how-to-help-prepare-for-ddos-attacks-by-reducing-your-attack-surface/) 참조하십시오.
엘라스틱 IP 주소가 포함된 Shield Advanced를 보호 리소스로 사용하는 방법에 대한 자세한 내용은 [구독](https://docs.aws.amazon.com/waf/latest/developerguide/enable-ddos-prem.html) 단계를 참조하십시오 AWS Shield Advanced.
# 오리진 보호 (BP1,BP5)
오리진이 내부에 CloudFront 있는 Amazon을 사용하는 경우 CloudFront 배포에서만 오리진에 요청을 전달할 수 있도록 하는 것이 좋습니다. VPC Edge-to-Origin 요청 헤더를 사용하면 요청을 오리진에 전달할 때 CloudFront 기존 요청 헤더의 값을 추가하거나 재정의할 수 있습니다. *Origin 사용자 지정* 헤더 (예: `X-Shared-Secret` 헤더) 를 사용하여 오리진에 보낸 요청이 보낸 것인지 확인하는 데 도움이 될 수 있습니다. CloudFront
오리진 *커스텀 헤더로 오리진을 보호하는 방법에 대한 자세한 내용은 오리진* [요청에 커스텀 헤더 [추가](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html) 및 애플리케이션 로드 밸런서에](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html) [대한 액세스 제한을](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html) 참조하십시오.
오리진 액세스 제한을 위한 *Origin 사용자 지정 헤더의* 값을 자동으로 교체하는 샘플 솔루션을 구현하는 [방법에 대한 지침은 Secrets Manager를 사용하여 AWS WAF Amazon CloudFront 오리진 보안을 강화하는 방법을](https://aws.amazon.com/blogs/security/how-to-enhance-amazon-cloudfront-origin-security-with-aws-waf-and-aws-secrets-manager/) 참조하십시오.
또는 [AWS Lambda](https://aws.amazon.com/lambda/)함수를 사용하여 CloudFront 트래픽만 허용하도록 보안 그룹 규칙을 자동으로 업데이트할 수도 있습니다. 이렇게 하면 악의적인 사용자가 웹 애플리케이션을 우회하거나 웹 애플리케이션에 액세스할 AWS WAF 때 이를 방지할 CloudFront 수 있어 오리진의 보안이 향상됩니다.
보안 그룹과 `X-Shared-Secret` 헤더를 자동으로 업데이트하여 오리진을 보호하는 [방법에 대한 자세한 내용은 Amazon CloudFront 및 AWS WAF Us를 사용하여 보안 그룹을 자동으로 업데이트하는 방법을](https://aws.amazon.com/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/) 참조하십시오 AWS Lambda.
그러나 솔루션에는 추가 구성 및 Lambda 함수 실행 비용이 포함됩니다. 이를 단순화하기 위해 이제 오리진 연결 IP 주소에서만 오리진으로 CloudFront 향하는 HTTP HTTPS 인바운드/트래픽을 제한하는 [AWS-managed 접두사 목록을](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list) 도입했습니다. CloudFront AWS-관리형 접두사 목록은 에서 생성 및 유지 관리하며 추가 비용 없이 사용할 AWS 수 있습니다. (AmazonVPC) 보안 그룹 규칙, 서브넷 라우팅 테이블, 공통 보안 그룹 규칙 및 관리형 접두사 목록을 사용할 수 있는 AWS Firewall Manager기타 AWS 리소스에서 [관리형 접두사](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html) 목록을 참조할 수 있습니다. CloudFront
Amazon용 AWS-managed 접두사 목록 사용에 대한 자세한 내용은 CloudFront Amazon용 [AWS-managed 접두사 목록을 사용하여 원본에 대한 액세스 제한을](https://aws.amazon.com/blogs/networking-and-content-delivery/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/) 참조하십시오. CloudFront
**참고**
이 문서의 다른 섹션에서 설명한 것처럼 보안 그룹을 사용하여 오리진을 보호하면 요청이 폭주하는 동안 [보안 그룹 연결 추적을](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) 병목 현상으로 만들 수 있습니다. 캐싱을 활성화하는 캐싱 정책을 CloudFront 사용하여 악의적인 요청을 필터링할 수 없다면 보안 그룹을 사용하는 것보다 앞서 설명한 *Origin 사용자 지정 헤더를* 사용하여 오리진에 대한 요청이 보낸 것인지 확인하는 것이 더 나을 수 있습니다. CloudFront Application Load Balancer 리스너 규칙과 함께 사용자 지정 요청 헤더를 사용하면 로드 밸런서에 대한 새 연결 설정에 영향을 미칠 수 있는 추적 제한으로 인한 병목 현상이 방지되므로 Application Load Balancer는 공격 발생 시 트래픽 증가에 따라 규모를 조정할 수 있습니다. DDoS
# API엔드포인트 보호 () BP4
일반에 공개해야 API 하는 경우 API 프론트엔드가 공격의 표적이 될 위험이 있습니다. DDoS 위험을 줄이기 위해 [Amazon API Gateway를 Amazon](https://aws.amazon.com/api-gateway/) 또는 다른 곳에서 실행되는 애플리케이션으로 들어가는 진입로로 사용할 수 있습니다. EC2 AWS Lambda Amazon API Gateway를 사용하면 API 프런트엔드에 자체 서버가 필요하지 않으며 애플리케이션의 다른 구성 요소를 난독화할 수 있습니다. 애플리케이션 구성 요소를 탐지하기 어렵게 만들면 해당 AWS 리소스가 공격의 표적이 되는 것을 방지할 수 있습니다. DDoS
Amazon API Gateway를 사용하면 두 가지 유형의 API 엔드포인트 중에서 선택할 수 있습니다. 첫 번째는 기본 옵션입니다. Amazon 배포를 통해 액세스하는 엣지 최적화 API 엔드포인트입니다. CloudFront 하지만 배포는 API Gateway에서 생성하고 관리하므로 사용자가 이를 제어할 수 없습니다. 두 번째 REST API 옵션은 배포된 지역과 동일한 AWS 리전 지역에서 액세스할 수 있는 리전 API 엔드포인트를 사용하는 것입니다. AWS 두 번째 유형의 엔드포인트를 사용하고 이를 자체 Amazon CloudFront 배포와 연결할 것을 권장합니다. 이를 통해 Amazon CloudFront 배포를 제어하고 애플리케이션 계층 보호에 AWS WAF 사용할 수 있습니다. 이 모드를 사용하면 AWS 글로벌 엣지 네트워크 전반에서 확장된 DDoS 완화 용량에 액세스할 수 있습니다.
Amazon CloudFront 및 AWS WAF Amazon API Gateway를 사용하는 경우 다음 옵션을 구성하십시오.
+ 모든 헤더를 API 게이트웨이 리전 엔드포인트로 전달하도록 배포의 캐시 동작을 구성하십시오. 이렇게 하면 콘텐츠를 동적인 CloudFront 것으로 취급하고 콘텐츠 캐싱을 건너뛰게 됩니다.
+ Gateway에서 [APIAPI키](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-setup-api-key-with-console.html) 값을 설정하여 원본 사용자 지정 헤더를 x-api-key 포함하도록 배포를 구성하여 API 게이트웨이를 직접 액세스로부터 보호하십시오.
+ 각 메서드에 대해 표준 또는 버스트 속도 제한을 구성하여 초과 트래픽으로부터 백엔드를 보호하십시오. REST APIs
Amazon API Gateway를 APIs 사용하여 생성하는 방법에 대한 자세한 내용은 [Amazon API Gateway](https://aws.amazon.com/api-gateway/getting-started/) [시작하기를](https://aws.amazon.com/api-gateway/getting-started/) 참조하십시오.