Amazon SCS-C02: 엣지 및 애플리케이션 보안 — 학습 가이드
다음의 일부입니다: AWS Security Specialty SCS-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.
CloudFront 지역 제한 및 국가 수준 차단
CloudFront는 국가별 트래픽을 차단하는 두 가지 메커니즘을 제공하며, 비용과 기능에 따라 둘 중 하나를 선택하는 것이 중요합니다. 내장된 지역 제한(geoblocking이라고도 함) 기능은 배포(distribution)에 직접 구성되며, 뷰어의 IP에서 파생된 국가 허용 목록 또는 차단 목록을 기준으로 엣지에서 요청을 평가합니다. 이 기능은 무료이며, 규칙 평가가 필요 없고, 오리진(origin) 패치(fetch)가 발생하기 전에 HTTP 403을 반환합니다. “X 국가 방문자 차단"과 같은 단순한 규정 준수 시나리오의 경우, 이것이 가장 저렴하고 간단한 옵션입니다.
대안은 WAF 지역 일치(geo match) 문으로, 더 유연합니다. 국가 일치를 URI 경로, 헤더, 속도 제한과 결합하거나 부정("/admin에 대해서만 A 국가 허용”)할 수 있습니다. 로직이 조건부일 때 WAF가 필요합니다. 지역 제한만으로는 “특정 경로에 대해서만 X 국가 차단"을 표현할 수 없습니다. 요구 사항이 단순한 국가 차단이고 WAF의 요청당 비용을 피하고 싶을 때는 기본 지역 제한 기능을 선택하십시오.
프라이빗 콘텐츠를 위한 서명된 URL(Signed URL)과 서명된 쿠키(Signed Cookie) 비교
CloudFront는 오리진 액세스 제어(origin access control) 또는 사용자 지정 헤더 뒤에 오리진(S3 버킷, ALB 또는 미디어 오리진)을 숨긴 채 승인된 프라이빗 콘텐츠를 제공하는 두 가지 방법을 지원합니다.
서명된 URL(Signed URL): 각 URL에 서명과 정책이 포함됩니다. 단일 파일 다운로드나 파일별 액세스 제어(예: 일회성 소프트웨어 설치 프로그램 링크)가 필요할 때 이상적입니다.
서명된 쿠키(Signed Cookie): 클라이언트는 인증 서비스로부터
CloudFront-Policy,CloudFront-Signature,CloudFront-Key-Pair-Id쿠키 세트를 한 번 받습니다. 이후 일치하는 경로 패턴에 대한 모든 요청은 URL을 다시 작성할 필요 없이 자동으로 승인됩니다.
매니페스트에서 참조하는 수천 개의 .ts 세그먼트를 가져오는 HLS 비디오 스트리밍의 경우, 서명된 쿠키가 훨씬 더 간단합니다. 매니페스트의 모든 세그먼트 URL을 별개의 서명된 URL로 다시 작성하는 것은 가능하지만, 지연 시간과 복잡성이 추가됩니다. 구독자가 내부 사용자 저장소에 대해 인증을 받은 후, 스트리밍 경로 패턴으로 범위를 지정하여 쿠키를 설정하십시오.
와일드카드를 사용한 서명된 쿠키의 표준 정책은 다음과 같습니다:
{
"Statement": [{
"Resource": "https://d123.cloudfront.net/videos/*",
"Condition": {
"DateLessThan": {"AWS:EpochTime": 1735689600},
"IpAddress": {"AWS:SourceIp": "203.0.113.0/24"}
}
}]
}
사용자가 CloudFront를 우회하여 오리진에 직접 접근하지 못하도록 이를 오리진 액세스 제어(OAC) 또는 오리진의 WAF에서 검증하는 비밀 사용자 지정 헤더와 함께 사용하십시오.
AWS WAF: 관리형 규칙(Managed Rules), ATP 및 속도 기반 규칙(Rate-Based Rules)
워크로드가 CloudFront 뒤에 있는 경우, Web ACL을 리전별 ALB가 아닌 CloudFront 배포에 연결하십시오. 엣지에 연결하면 수백 개의 POP 중 하나에서 악성 요청을 종료시키므로 공격자와 더 가까운 위치에서 차단됩니다. 이는 DDoS 공격 중 오리진 부하를 줄이고, 차단된 트래픽이 VPC를 통과하지 않으므로 오리진에서의 이그레스(egress) 비용을 낮춥니다. WAF를 ALB에만 연결하면 대규모 트래픽 공격이 리전 로드 밸런서에 도달하여 LCU를 소모하게 되며, 리전 간 공격이 글로벌 엣지 네트워크가 아닌 단일 리전에서 처리됩니다.
결합할 주요 규칙 그룹:
AWS 관리형 규칙 세트:
AWSManagedRulesCommonRuleSet(OWASP 상위 10개 스타일),AWSManagedRulesKnownBadInputsRuleSet,AWSManagedRulesAmazonIpReputationList는 거의 조정 없이 광범위한 보호를 제공합니다.계정 탈취 방지(ATP):
AWSManagedRulesATPRuleSet은 지정한 로그인 엔드포인트를 검사하고, 크리덴셜 스터핑(credential stuffing) 패턴을 추적하고, 제출된 자격 증명을 유출된 자격 증명 데이터베이스와 대조하며, 유출된 암호를 재사용하는 봇을 차단합니다. 정확한 로그인 경로와 사용자 이름 및 암호에 대한 JSON 본문 필드 이름으로 구성하십시오.속도 기반 규칙: 5분 동안 단일 IP에서 오는 요청 수를 제한합니다(예: 2,000개 요청).
/search에 대한 스크래핑이/의 익명 브라우징에 영향을 주지 않도록 URI 또는 메서드별로 범위를 지정하십시오. 속도 규칙은 Layer 7 대규모 공격 및 무차별 대입(brute-force) 열거 공격을 완화합니다.
간소화된 WAF 규칙 블록:
Rules:
- Name: RateLimitLogin
Priority: 1
Action: { Block: {} }
Statement:
RateBasedStatement:
Limit: 500
AggregateKeyType: IP
ScopeDownStatement:
ByteMatchStatement:
SearchString: /api/login
FieldToMatch: { UriPath: {} }
PositionalConstraint: STARTS_WITH
TextTransformations: [{ Priority: 0, Type: LOWERCASE }]
ACM 인증서, DNS 검증 및 CloudFront
CloudFront의 경우, 오리진의 위치와 상관없이 인증서는 반드시 us-east-1(N. Virginia) 리전의 ACM에서 프로비저닝해야 합니다. 이는 CloudFront가 해당 리전에서 인증서를 읽는 글로벌 서비스이기 때문에 반드시 지켜야 하는 요구 사항입니다. ALB와 같은 리전 서비스는 ALB 자체 리전에서 인증서를 읽습니다.
자동 갱신하려는 모든 퍼블릭 인증서에 대해서는 항상 DNS 검증과 Route 53의 CNAME 레코드를 사용하십시오. ACM은 검증 CNAME이 게시되어 있는 한 DNS로 검증된 인증서를 자동으로 갱신합니다. Route 53을 사용하면 이 과정이 매우 간단해집니다(콘솔에서 요청 중에 “Route 53에서 레코드 생성” 옵션을 제공). 반면, 이메일 검증은 도메인의 5개 주소(admin@, administrator@, hostmaster@, postmaster@, webmaster@)와 WHOIS 연락처로 확인 메일을 보냅니다. 이러한 메일함은 존재하지 않거나 회사 메일 필터에 의해 격리되는 경우가 많아, 만료 60일 전에 갱신이 실패하여 예방 가능한 장애를 유발합니다. 이메일 검증 클릭을 자동화할 방법은 없습니다.
다중 리전 ALB의 올바른 갱신 패턴은 다음과 같습니다: 리전별로 DNS 검증 ACM 인증서를 요청하고, Route 53에 검증 CNAME을 한 번 게시하고, 인증서를 ALB 리스너에 연결한 다음, ACM이 갱신 및 재배포를 처리하도록 하는 것입니다. 사람의 개입은 발급 단계에서 끝납니다.
DNSSEC와 Route 53
도메인에 대한 DNS 스푸핑 및 캐시 포이즈닝을 방지하려면 Route 53 호스팅 영역에서 DNSSEC 서명을 활성화하십시오. Route 53은 KMS에서 KSK(us-east-1의 비대칭 ECC 키)를 관리하며, 사용자는 등록 기관(registrar)에 DS 레코드를 게시해야 합니다. DNSSEC 서명은 영역(zone)의 확인(resolution) 과정을 보호하지만, DNS 트래픽을 암호화(이는 DoH/DoT의 역할)하거나 CloudFront의 TLS에 영향을 주지는 않습니다.
응답 헤더: 정책과 Lambda@Edge 비교
CloudFront는 Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options 또는 Content-Security-Policy와 같은 보안 헤더를 자동으로 삽입하지 않습니다. 오리진을 수정할 수 없는 경우(레거시 S3 사이트, 서드파티 오리진 등), 두 가지 옵션이 있습니다.
응답 헤더 정책: 네이티브하고 선언적인 CloudFront 기능입니다. 캐시 동작에 관리형 또는 사용자 지정 정책을 연결하여 HSTS, CORS, 보안 및 사용자 지정 헤더를 추가합니다. 코드가 필요 없고, 콜드 스타트가 없으며, 호출당 비용이 발생하지 않으므로 기본적으로 이 방법을 선택해야 합니다.
Lambda@Edge (뷰어 응답 또는 오리진 응답): 요청마다 다른 CSP nonce를 사용하거나 요청 속성에 따라 헤더를 재작성하는 등 동적인 로직이 필요할 때 사용합니다. 단순함을 포기하는 대신 유연성을 얻고 요청당 비용이 추가됩니다.
관리형 응답 헤더 정책인 SecurityHeadersPolicy는 한 번의 연결로 일반적인 보안 기준을 충족시킵니다.
주요 함정 설명
이메일 검증으로 공인 ACM 인증서를 요청하는 방식은 갱신이 사람이 메일을 읽는 것에 의존하기 때문에 취약합니다. 대부분의 조직은 이러한 일반 주소를 모니터링하지 않거나 스팸으로 처리하기 때문입니다. Route 53을 사용한 DNS 검증은 사람의 개입을 완전히 제거합니다.
WAF를 ALB에만 연결하는 것은 서류상으로는 동등해 보이지만, 공격 트래픽을 리전으로 유입시키고 ALB 용량을 소모하게 만듭니다. CloudFront에 연결된 엣지 WAF는 수백 개의 POP에서 차단하므로, 분산된 대규모 공격이 전 세계적으로 흡수되고 오리진 이그레스(egress)가 낮게 유지됩니다. 이는 DDoS 공격 시 매우 중요합니다.
CloudFront가 자동으로 보안 헤더를 추가한다고 가정하면 모의 해킹 테스트 실패로 이어질 수 있습니다. 배포는 오리진이 보내는 헤더를 그대로 프록시합니다. X-Frame-Options: DENY, HSTS, CSP를 삽입하려면 응답 헤더 정책이나 Lambda@Edge 함수를 명시적으로 연결해야 합니다.
실용적인 문제: 사용 사례 시나리오
시나리오: Meridian Financial은 전 세계적으로 분산된 고객 포털과 내부 보고서 포털을 AWS에서 운영하고 있습니다. 퍼블릭 트래픽은 Amazon CloudFront를 통해 동적 API를 위한 Application Load Balancer와 비공개 보고서를 위한 S3 오리진으로 라우팅됩니다. DNS는 Route 53에 있으며 TLS 인증서는 AWS Certificate Manager(ACM)에서 발급받습니다.
과제: 공격자들이 여러 국가에서 계정을 스크래핑하고 크리덴셜 스터핑을 하고 있으며, 오리진 엔드포인트를 직접 공격하여 CloudFront를 우회하고 비공개 보고서를 다운로드하여 오리진 과부하와 데이터 유출을 유발하고 있습니다.
권장 접근 방식:
- CloudFront를 유일한 퍼블릭 진입점으로 구성하고 CloudFront 지역 제한을 적용하여 문제가 되는 국가를 차단합니다. Origin Access Control(OAC)을 활성화하고 S3/ALB 오리진 정책을 잠가 CloudFront만이 오리진 콘텐츠를 가져올 수 있도록 합니다.
- 각 다운로드가 개별적으로 인가되고 감사 가능하도록, 서명된 쿠키 대신 CloudFront 서명된 URL(짧은 TTL)을 사용하여 사용자별 비공개 보고서를 제공합니다.
- AWS 관리형 규칙을 사용하여 AWS WAF를 CloudFront 배포에 연결하고, AWS WAF Bot Control(고급 위협 방어)을 활성화하며, 속도 기반 규칙 및 CAPTCHA 챌린지를 생성하여 스크래핑과 크리덴셜 스터핑을 완화합니다.
- Route 53을 통한 DNS 검증을 사용하여 ACM(CloudFront 배포의 경우 us-east-1)에서 TLS 인증서를 프로비저닝하고, Route 53 별칭(Alias) 레코드를 CloudFront 배포에 게시합니다.
- Route 53 호스팅 영역에서 DNSSEC를 활성화하고, CloudFront 및 WAF 액세스 로그를 S3에 저장하도록 활성화하며, DDoS 가시성 및 경보를 위해 CloudWatch 경보 및 선택적으로 AWS Shield Advanced를 생성합니다.
근거: OAC와 WAF를 통해 모든 트래픽이 CloudFront를 통과하도록 강제하면 최소 권한의 오리진 액세스가 적용됩니다. 지역 제한 및 속도 기반/WAF 보호는 악의적인 트래픽을 차단하고, 서명된 URL은 객체별 권한 부여를 제공하며, DNSSEC와 함께 ACM+DNS 검증을 사용하면 AWS 모범 사례에 따라 신뢰할 수 있는 TLS 및 DNS 무결성을 보장합니다.
AWS WAF 규칙 및 ALB, CloudFront와의 통합
AWS WAF는 순서가 있는 규칙들로 구성된 Web ACL에 대해 HTTP(S) 요청을 평가하는 Layer 7 방화벽입니다. 각 규칙은 요청 속성(URI, 헤더, 본문, 쿼리 문자열, 소스 IP)을 검사하고 종료 작업(Allow, Block, Challenge, CAPTCHA) 또는 비종료 작업(Count)을 반환합니다. Web ACL은 CloudFront 배포, Application Load Balancer, API Gateway, AppSync, Cognito 사용자 풀 및 App Runner 서비스에 연결할 수 있습니다. CloudFront에 연결할 때 ACL은 엣지에서 실행되며 us-east-1(글로벌) 범위에서 생성해야 합니다. ALB의 경우 로드 밸런서와 동일한 리전에 있어야 합니다.
속도 기반 규칙은 5분 단위의 롤링 윈도우 동안 단일 IP(또는 전달된 IP 헤더, 또는 URI + IP 조합과 같은 집계 키)에서 도착하는 요청 수를 추적합니다. 수가 구성된 임계값을 초과하면, 속도가 다시 한도 아래로 떨어질 때까지 규칙 작업이 실행됩니다. AWS WAF는 몇 초 안에 공격자 목록을 지속적으로 업데이트하므로, 속도 기반 규칙은 소수의, 계속 바뀌는 IP 집합으로부터 발생하는 대량의 악용에 대한 표준적인 해결책입니다. 수동으로 IP 집합을 관리할 필요가 없으며, 초기 규칙 배포 후 운영 오버헤드는 거의 0에 가깝습니다.
{
"Name": "RateLimitPerIP",
"Priority": 10,
"Statement": {
"RateBasedStatement": {
"Limit": 2000,
"AggregateKeyType": "IP"
}
},
"Action": { "Block": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "RateLimitPerIP"
}
}
IP 집합은 규칙에서 IPSetReferenceStatement로 참조하는 재사용 가능한 CIDR 범위 목록입니다. 지리적으로 제한된 관리자 엔드포인트나 위협 인텔리전스 피드에서 얻은 알려진 악성 범위와 같이 결정적인 차단/허용 목록이 있을 때 적합한 기본 요소입니다. 사용자 지정 규칙은 논리적 AndStatement, OrStatement, NotStatement 연산자를 사용하여 여러 문을 결합하여 “미국 이외의 국가에서 특정 헤더 없이 /login으로 들어오는 요청을 차단"과 같은 조건을 표현할 수 있습니다.
DDoS 완화 계층 및 오리진 보호로서의 CloudFront
CloudFront는 트래픽이 ALB나 EC2 플릿에 도달하기 훨씬 전인 AWS 엣지에서 볼륨 기반 공격(volumetric attack)과 상태 소진 공격(state-exhaustion attack)을 흡수합니다. 모든 엣지 로케이션은 AWS Shield Standard를 자동으로 실행하여 추가 비용 없이 SYN 플러드 및 반사 공격(reflection attack)을 완화합니다. ALB 앞에 CloudFront를 배치하면 공격 표면(attack surface)을 엣지 네트워크로 축소하고 엣지 범위의 WAF, 지리적 제한(geo-restriction), TLS 종료(termination)를 활성화할 수 있습니다.
이러한 완화 조치는 공격자가 ALB DNS 이름을 직접 공격하여 CloudFront를 우회할 수 없는 경우에만 효과적입니다. 두 가지 메커니즘으로 이 경로를 강화할 수 있습니다. 첫째, CloudFront가 비밀 사용자 지정 오리진 헤더(예: X-Origin-Verify: <random-value>)를 주입하도록 구성하고, 해당 헤더 값이 없는 모든 요청에 대해 403을 반환하는 ALB 리스너 규칙을 구성합니다. AWS Secrets Manager를 통해 주기적으로 이 비밀 값을 교체합니다. 둘째, ALB 보안 그룹을 CloudFront 엣지 IP 범위를 포함하는 AWS 관리형 접두사 목록(prefix list) com.amazonaws.global.cloudfront.origin-facing으로 제한합니다.
ALBListenerRule:
Type: AWS::ElasticLoadBalancingV2::ListenerRule
Properties:
Actions:
- Type: fixed-response
FixedResponseConfig: { StatusCode: "403", ContentType: text/plain }
Conditions:
- Field: http-header
HttpHeaderConfig:
HttpHeaderName: X-Origin-Verify
Values: ["!Ref OriginSecret"]
- Field: http-header
HttpHeaderConfig: { HttpHeaderName: X-Origin-Verify, Values: ["*"] }
Priority: 1
트래픽이 CloudFront를 통과하도록 강제하지 않고 WAF ACL을 ALB에 연결하기만 하면 ALB 엔드포인트는 공개적으로 확인 가능한 상태로 남게 됩니다. 공격자가 인증서 투명성 로그, 과거 DNS 기록 또는 하위 도메인 열거를 통해 DNS 이름을 발견하면 모든 엣지 보호 기능을 우회하여 직접 공격할 수 있습니다. 이것이 ‘CloudFront + ALB’ 설계에서 가장 흔한 단일 아키텍처 실수입니다.
Shield Advanced 지표, 경보 및 알림
Shield Advanced는 향상된 탐지 기능, Shield 대응팀(Shield Response Team)에 대한 24/7 액세스, 공격 중 스케일링에 대한 비용 보호, 애플리케이션 계층 공격 가시성을 추가로 제공합니다. 하지만 공격이 발생했을 때 이메일이나 SMS를 자동으로 보내지는 않습니다. 알림은 CloudWatch를 통해 명시적으로 연결해야 합니다.
Shield Advanced는 AWS/DDoSProtection 네임스페이스에 보호된 리소스별로 DDoSDetected 지표(공격 진행 중 값 1)와 DDoSAttackBitsPerSecond, DDoSAttackPacketsPerSecond, DDoSAttackRequestsPerSecond를 게시합니다. DDoSDetected >= 1에 대한 CloudWatch 경보를 생성하고 경보 작업으로 SNS 주제를 지정합니다. 그러면 SNS가 이메일, SMS, 채팅 또는 Lambda 응답기로 알림을 팬아웃(fan-out)합니다.
aws cloudwatch put-metric-alarm \
--alarm-name ShieldDDoSDetected \
--namespace AWS/DDoSProtection \
--metric-name DDoSDetected \
--statistic Maximum --period 60 --threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-east-1:111122223333:secops-alerts
Shield Advanced가 ‘알아서 이메일을 보내줄 것’이라고 가정하는 것은 흔한 오해입니다. CloudWatch 경보와 SNS 구독이 없으면 유일한 신호는 Shield 콘솔과 AWS Health Dashboard 이벤트뿐입니다.
자동화된 Lambda 차단 기능을 갖춘 AWS Network Firewall
Network Firewall은 서브넷 라우팅 테이블을 통과하는 트래픽을 검사하는 상태 저장(stateful) 방식의 VPC 연결형 Layer 3–7 방화벽입니다. 정책은 상태 비저장(stateless) 및 상태 저장(stateful) 규칙 그룹으로 구성되며, 상태 저장 규칙 그룹은 Suricata 호환 구문을 사용합니다. 규칙 그룹은 API로 관리되므로 이벤트 기반 자동화에 이상적인 대상입니다.
일반적인 패턴은 GuardDuty 결과(예: UnauthorizedAccess:EC2/RDPBruteForce 또는 Backdoor:EC2/C&CActivity)에 응답하는 것입니다. Security Hub가 결과를 집계하고, EventBridge가 이벤트 패턴과 일치하는 것을 찾아 Lambda 함수를 호출하면, Lambda는 UpdateRuleGroup을 호출하여 공격 IP 또는 침해된 인스턴스의 ENI를 대상으로 하는 차단 규칙을 삽입합니다.
def handler(event, _):
ip = event["detail"]["findings"][0]["ProductFields"]["aws/guardduty/service/action/networkConnectionAction/remoteIpDetails/ipAddressV4"]
new_rule = f'drop ip {ip} any -> any any (msg:"GD-block"; sid:{sid()}; rev:1;)'
rg = nfw.describe_rule_group(RuleGroupArn=RG_ARN)
rules = rg["RuleGroup"]["RulesSource"]["RulesString"] + "\n" + new_rule
nfw.update_rule_group(
RuleGroupArn=RG_ARN,
UpdateToken=rg["UpdateToken"],
RulesSource={"RulesString": rules})
VPC 엣지에서 EC2 인스턴스나 CIDR을 오가는 양방향 트래픽을 차단해야 할 때 Network Firewall이 올바른 선택입니다. WAF는 지원되는 Layer 7 엔드포인트로 향하는 HTTP 요청만 검사하므로 아웃바운드 C2 트래픽이나 비(非)HTTP 프로토콜은 중지시킬 수 없습니다.
Count를 사용한 로깅, 모니터링 및 안전한 배포
모든 Web ACL에 WAF 로깅을 활성화하고 CloudWatch Logs, S3 또는 Kinesis Data Firehose로 스트리밍합니다. 로그에는 일치된 규칙, 작업, 요청 헤더 및 (편집 규칙에 따라) 삭제 처리된 본문이 포함됩니다. 콘솔의 샘플링된 요청은 빠른 보기를 제공하지만, 마지막 3시간 및 규칙당 100개의 샘플만 보존합니다. 감사 및 포렌식을 위해서는 전체 로그가 필요합니다.
Count 작업은 안전한 규칙 배포에 필수적입니다. 새로운 관리형 규칙 그룹(예: AWSManagedRulesCommonRuleSet 또는 Bot Control 그룹)을 배포할 때는 먼저 규칙 작업 재정의를 Count로 설정합니다. CountedRequests CloudWatch 지표와 로그 항목을 주시하여 오탐(false positive), 즉 차단될 수 있었던 정상 트래픽을 확인합니다. 예외 사항을 조정한 후에만 작업을 Block으로 전환합니다. Count 단계 없이 관리형 규칙을 바로 Block으로 배포하면 SizeRestrictions_BODY와 같은 규칙이 정상적인 대용량 업로드 엔드포인트를 차단하거나, CrossSiteScripting_BODY가 리치 텍스트 편집기 페이로드에서 발생하는 등 일상적으로 장애를 유발합니다. 해결 방법은 전체 그룹을 비활성화하는 것이 아니라, 잘못 동작하는 특정 규칙에 대해 범위 축소 문(scope-down statement)이나 규칙 작업 재정의를 추가하는 것입니다.
WAF 지표(BlockedRequests, AllowedRequests, CountedRequests)를 CloudWatch 경보와 연계하여 차단 요청이 갑자기 급증하거나 허용된 트래픽이 갑자기 급감할 때 온콜 엔지니어에게 알림을 보내 엣지 보호와 운영 인식 간의 연계를 완성합니다.
실제 문제: 사용 사례 시나리오
시나리오: Meridian Financial은 다중 AZ VPC에서 Application Load Balancer(ALB)를 ECS 서비스 앞에 두고 고객 대면 웹 애플리케이션을 실행하며, CloudFront를 통해 정적 및 동적 콘텐츠를 배포합니다. 이 팀은 AWS WAF를 사용하지만 네트워크 계층 위협에 대한 자동화가 제한적이었고 서비스 간 로깅이 일관되지 않았습니다.
과제: 최근 대규모 및 애플리케이션 계층 트래픽 급증이 로그인 엔드포인트를 대상으로 발생하여 크리덴셜 스터핑을 시도하면서 ALB CPU 고갈을 유발했습니다. 보안팀은 신속한 DDoS 완화, 일관된 오리진 보호, 악성 IP 자동 차단, 더 엄격한 규칙의 안전한 배포가 필요합니다.
권장 접근 방식:
- ALB 앞에 CloudFront를 활성화하여 글로벌 엣지에서 완화하고, 사용자 지정 오리진 헤더를 검증하고 CloudFront 관리형 접두사 목록 또는 알려진 IP 범위로 인바운드 액세스를 제한하여 CloudFront로부터의 트래픽만 수락하도록 ALB를 구성합니다.
- 관리형 AWS 규칙 세트와 사용자 지정 속도 기반 및 봇 탐지 규칙을 사용하여 AWS WAFv2를 배포합니다. WAF를 CloudFront 배포와 ALB 모두에 연결합니다. 처음에는 새로운 사용자 지정 규칙을 COUNT 모드로 설정하여 원격 측정 데이터를 수집합니다.
- 계정을 AWS Shield Advanced에 등록하고 CloudFront 배포와 ALB를 연결합니다. Shield/DDoS 지표를 사용하여 CloudWatch 지표 경보를 생성하고, 경보를 SNS 주제로 전달하여 온콜 알림 및 런북 트리거를 설정합니다.
- 로그 중앙화: CloudFront, ALB, WAF, AWS Network Firewall 로그를 Kinesis Data Firehose → S3로 스트리밍하고, CloudWatch 지표/대시보드를 활성화하여 COUNT 모드에서 규칙 일치 수를 모니터링합니다.
- VPC에 AWS Network Firewall을 배포하고 상태 저장 규칙 그룹을 활성화한 후 로깅을 활성화합니다. 의심스러운 패턴에 대한 CloudWatch 지표 필터를 생성하고, 경보에 의해 트리거되어 공격 IP를 거부 목록에 추가하도록 Network Firewall 규칙 그룹을 자동으로 업데이트하는 Lambda를 생성합니다.
- 합의된 관찰 기간 동안 COUNT 모드와 대시보드에서 트래픽을 관찰한 후, 신뢰도 높은 WAF 규칙을 BLOCK으로 전환하고, 안전한 롤백과 규칙 그룹 버전 관리를 통해 자동화된 Network Firewall 업데이트를 유지합니다.
근거: CloudFront를 WAF 및 Shield Advanced와 함께 엣지 계층으로 사용하면 계층화된 DDoS 보호를 제공하며, 중앙 집중식 로깅, COUNT 모드 규칙 검증, Lambda 기반의 자동화된 Network Firewall 업데이트는 AWS 모범 사례와 일치하는 안전하고 관찰 가능하며 자동화된 네트워크 방어를 제공합니다.
← 네트워킹 및 VPC 보안 · 모든 도메인 · 거버넌스 →
이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
시험 합격하기 →