Amazon SCS-C02: 네트워킹 및 VPC 보안 — 학습 가이드
다음의 일부입니다: AWS Security Specialty SCS-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.
VPC 엔드포인트 및 엔드포인트 정책
VPC 엔드포인트는 AWS 서비스로 향하는 트래픽을 AWS 네트워크 내에 유지하여 공용 인터넷, NAT 게이트웨이, 인터넷 게이트웨이를 우회하게 합니다. 구조적으로 다른 두 종류가 있으며, 이를 혼동하는 것은 가장 흔한 설계 오류 중 하나입니다.
게이트웨이 엔드포인트는 Amazon S3와 DynamoDB에만 존재합니다. 이는 라우팅 테이블 항목입니다. 엔드포인트를 라우팅 테이블과 연결하면, 서비스의 접두사 목록(예: us-east-1의 S3에 대한 pl-63a5400a)으로 향하는 트래픽이 엔드포인트를 통해 자동으로 라우팅됩니다. 비용이 들지 않으며, 연결된 VPC 외부에서는 접근할 수 없습니다.
인터페이스 엔드포인트(AWS PrivateLink 기반)는 서브넷에 배치되는 프라이빗 IP 주소를 가진 ENI입니다. S3나 DynamoDB가 아닌 모든 서비스(Secrets Manager, KMS, STS, SSM, CloudWatch Logs, ECR API/DKR 등 수백 가지)에 필요합니다. NAT 게이트웨이가 없는 프라이빗 서브넷의 EC2 인스턴스가 Secrets Manager에서 GetSecretValue를 호출해야 할 때, 게이트웨이 엔드포인트는 도움이 되지 않습니다. com.amazonaws.<region>.secretsmanager 인터페이스 엔드포인트를 생성하고 Private DNS를 활성화하여 표준 서비스 호스트 이름이 엔드포인트의 프라이빗 IP로 확인되도록 해야 합니다.
엔드포인트 정책은 호출자의 IAM 정책과 별개로, 엔드포인트를 통해 무엇을 할 수 있는지 제한합니다. 데이터 유출을 방지하기 위한 가장 중요한 두 가지 조건 키는 aws:PrincipalOrgID(호출을 수행하는 ID가 조직에 속해야 함)와 aws:ResourceOrgID(접근하는 S3 버킷, KMS 키 등이 조직에 속해야 함)입니다. 이 두 가지를 모두 적용하면, 정상적인 S3 권한을 가진 침해된 인스턴스가 조직 외부의 공격자 소유 버킷에 데이터를 쓰는 전형적인 데이터 유출 경로를 차단할 수 있습니다. 자격 증명은 S3에 대해 여전히 유효하지만, 엔드포인트가 요청 전달을 거부합니다.
{
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-abc123",
"aws:ResourceOrgID": "o-abc123"
}
}
}]
}
기본 엔드포인트 정책은 완전히 허용적이므로("Resource":"*"에 대한 "Action":"*"), 게이트웨이 엔드포인트만 있고 최소 권한 IAM을 적용한 서브넷이라도 엔드포인트 정책 자체를 강화하지 않으면 데이터 유출에 악용될 수 있습니다.
하이브리드 연결: VPN 및 Direct Connect
Site-to-Site VPN은 가상 프라이빗 게이트웨이(또는 Transit Gateway)와 고객 게이트웨이 장치 사이에 두 개의 IPsec 터널을 설정합니다. 프로비저닝이 빠르고 기본적으로 암호화되며 공용 인터넷을 통과하므로, 처리량과 지연 시간은 ISP 경로에 따라 달라집니다.
AWS Direct Connect는 Direct Connect 로케이션을 통해 전용 물리 회선을 프로비저닝합니다. 예측 가능한 낮은 지연 시간과 높고 일관된 대역폭(1/10/100 Gbps)을 제공하며, 이는 통신량이 많은 온프레미스 데이터베이스 트래픽에 중요합니다. Direct Connect는 자체적으로 레이어 3에서 암호화되지 않습니다. 프레임은 사설 광섬유를 통해 전송됩니다. 낮은 지연 시간과 IPsec을 모두 필요로 하는 워크로드의 경우, 표준적인 해결책은 Direct Connect에 더해 퍼블릭 VIF를 통해 Site-to-Site VPN을 실행하는 것입니다(또는 최신 DX 포트에서 MACsec을 사용하는 Transit Gateway). 또한 VPN만 사용하는 것은 기본 Direct Connect 링크에 대한 권장 암호화 백업으로, 회선 장애 시 복원력을 제공합니다.
- Direct Connect만 사용: 낮은 지연 시간, 프라이빗 연결이지만 IP 계층에서 암호화되지 않음.
- VPN만 사용: 암호화, 빠른 배포, 그러나 인터넷 경로의 지연 시간 및 지터 발생.
- Direct Connect + VPN: 낮은 지연 시간 및 IPsec 암호화; 표준적인 HA 구성 패턴.
보안 그룹, NACL, DHCP 및 소스/대상 확인
보안 그룹은 상태 저장(stateful) 방식입니다. 인바운드 요청을 허용하면 응답은 자동으로 아웃바운드가 허용됩니다. 허용(allow) 규칙만 지원하며 ENI별로 평가됩니다.
네트워크 ACL은 상태 비저장(stateless) 방식이며 서브넷 경계에서 작동합니다. 모든 플로우에는 두 개의 규칙이 필요합니다. 하나는 초기 방향에 대한 규칙이고, 다른 하나는 임시 포트 범위(Linux는 보통 32768–60999, Windows는 49152–65535, NLB/ELB는 1024–65535)의 반환 트래픽에 대한 규칙입니다. 인바운드 TCP 443은 허용하지만 아웃바운드 TCP 1024–65535를 잊은 NACL은 TLS 연결을 조용히 중단시킵니다. ICMP는 TCP/UDP가 아닙니다. 반환되는 “echo reply” 패킷은 명시적으로 허용해야 하며, Path MTU Discovery는 실수로 차단하기 쉬운 ICMP 유형 3 코드 4에 의존합니다. NACL 규칙은 또한 숫자 순서대로 평가되며, 먼저 일치하는 규칙이 적용되고, 마지막에는 암시적 거부(deny) 규칙이 있습니다.
DHCP 옵션 세트는 VPC가 부팅 시 인스턴스에 전달하는 domain-name-servers, domain-name, NTP 서버, NetBIOS 등을 제어합니다. 기본 AmazonProvidedDNS를 사용자 지정 온프레미스 리졸버로 교체하는 것은 타당할 수 있지만, 실제 보안에 영향을 미칩니다. GuardDuty와 같은 서비스는 Route 53 Resolver를 통과하는 쿼리로부터 DNS 기반 탐지 결과(예: “암호화폐” 및 “C&C 도메인” 탐지)를 도출합니다. 인스턴스가 서드파티 DNS 서버를 가리키게 되면, GuardDuty는 더 이상 쿼리를 볼 수 없게 되어 해당 유형의 탐지 결과가 사라집니다. 이는 실수로 탐지 기능을 무력화하기 쉬운 방법입니다.
소스/대상 확인은 소스 또는 대상 IP가 ENI와 일치하지 않는 모든 패킷을 삭제하는 ENI 속성입니다. 이 기본 설정은 일반 인스턴스에는 올바르지만, 트래픽을 전달하는 역할을 하는 모든 어플라이언스(NAT 인스턴스, 가상 방화벽(Palo Alto, Fortinet, Check Point), 트랜짓 라우터, VPN 집중 장치)에서는 문제를 일으킵니다. 해당 ENI에 대해서는 이 확인 기능을 비활성화해야 합니다.
aws ec2 modify-instance-attribute \
--instance-id i-0abc123 \
--no-source-dest-check
VPC 피어링, RAM 공유 VPC, NAT 설계
VPC 피어링은 일대일의 비전이적(non-transitive) 레이어 3 연결입니다. A가 B와 피어링하고 B가 C와 피어링하더라도 A는 C에 도달할 수 없습니다. A-C를 직접 피어링하거나 Transit Gateway를 사용해야 합니다. 양측의 라우팅 테이블에는 피어 CIDR로 가는 경로가 포함되어야 하며, 보안 그룹은 동일 리전 내에서만 피어 보안 그룹 ID를 참조할 수 있습니다.
AWS Resource Access Manager(RAM)를 통한 공유 VPC는 네트워킹 계정이 VPC를 소유하고 개별 서브넷을 참여자 계정과 공유할 수 있게 해줍니다. 참여자는 공유 서브넷에 리소스를 시작할 수는 있지만 VPC, 라우팅 테이블, 엔드포인트를 수정할 수는 없습니다. 소유자가 연결 정책에 대한 제어권을 유지합니다. 이는 여러 VPC를 피어링하는 것보다 비용이 저렴하고 간단한 경우가 많습니다.
프라이빗 서브넷에서 아웃바운드 인터넷으로 나가려면 가용 영역(AZ)마다 NAT 게이트웨이를 배포하고, 각 프라이빗 서브넷을 자체 AZ에 있는 NAT로 라우팅해야 합니다. 단일 NAT 게이트웨이는 AZ 간 종속성을 만들고 확장성/가용성의 병목 지점이 됩니다. 워크로드가 IP 허용 목록을 사용하는 서드파티(예: 결제 처리 시스템)를 호출할 때, 등록해야 하는 것은 NAT 게이트웨이의 Elastic IP입니다. Auto Scaling 그룹 뒤의 인스턴스들은 모두 이 고정된 EIP를 통해 나가므로 그룹이 스케일링되어도 소스 IP가 변경되지 않습니다. EC2 인스턴스와 RDS 데이터베이스를 프라이빗 서브넷에 배치하고 ALB에서는 HTTP/HTTPS만 종료하도록 구성하면 이 패턴이 완성됩니다.
Route 53 Resolver: 전달 및 쿼리 로깅
Route 53 Resolver(모든 VPC의 .2 주소)는 하이브리드 DNS의 중심축입니다. 아웃바운드 리졸버 엔드포인트는 조건부 전달 규칙을 통해 지정된 도메인 이름을 AWS에서 온프레미스 DNS 서버로 전달합니다. 예를 들어 corp.example.internal이 Active Directory를 통해 확인되도록 하는 데 사용됩니다. 인바운드 리졸버 엔드포인트는 그 반대로, 온프레미스 호스트가 *.eu-west-1.compute.internal 및 Private Hosted Zone을 확인하기 위해 쿼리할 수 있는 VPC 내 프라이빗 IP를 제공합니다.
리졸버 쿼리 로깅은 VPC에서 발생하는 모든 DNS 쿼리를 CloudWatch Logs, S3 또는 Kinesis Firehose에 기록합니다. 이는 의심스러운 데이터 유출이나 오용을 조사하기 위한 신뢰할 수 있는 기록이며, GuardDuty를 대체하는 것이 아니라 보완합니다. DHCP 옵션 세트가 인스턴스를 Amazon이 아닌 리졸버로 리디렉션하면 쿼리가 Route 53 Resolver를 거치지 않으므로 쿼리 로깅과 GuardDuty DNS 탐지 결과가 모두 작동하지 않는다는 점을 기억해야 합니다.
실전 문제: 사용 사례 시나리오
시나리오: Meridian Financial은 허브 앤 스포크 네트워크를 갖춘 다중 계정 AWS 환경을 운영하고 있습니다. RAM으로 공유되는 공유 서비스 VPC는 중앙 NAT Gateway, Route 53 Resolver 엔드포인트, Transit Gateway 연결을 호스팅하며, 여러 애플리케이션 VPC는 Transit Gateway에 피어링되거나 연결됩니다. 온프레미스 데이터센터는 VPN 장애 조치를 갖춘 Direct Connect를 통해 연결되며, 팀들은 하이브리드 DNS 확인을 위해 중앙 집중식 DHCP 옵션 세트와 공유 리졸버 엔드포인트에 의존합니다.
과제: 최근 사고에서 스포크가 VPC 엔드포인트 대신 공유 NAT로 라우팅되어 민감한 S3 객체가 공용 인터넷을 통해 액세스되었고, 내부 영역에 대한 DNS 쿼리가 공용 리졸버로 유출되었으며, 임시 라우터로 사용된 EC2 인스턴스(소스/대상 확인 비활성화)가 측면 이동(lateral movement)을 가능하게 한 것으로 나타났습니다.
권장 접근 방식:
- 공유 서비스 VPC에 S3 및 DynamoDB용 Gateway VPC Endpoint와 Secrets Manager 및 KMS용 Interface Endpoint(AWS PrivateLink)를 배포하고, 명명된 버킷 및 서비스 보안 주체로 액세스를 제한하는 명시적인 엔드포인트 정책을 연결합니다.
- 애플리케이션 서브넷이 AWS API 및 S3에 VPC 엔드포인트를 사용하도록 NAT 설계를 재구성합니다. NAT Gateway는 엄격한 이그레스 보안 그룹과 CloudWatch/S3로의 Flow Logs를 사용하여 실제 인터넷 이그레스 용도로만 유지합니다.
- 문서화된 라우팅 어플라이언스를 제외한 모든 EC2 인스턴스에서 소스/대상 확인을 다시 활성화합니다. 라우팅을 Transit Gateway 연결 또는 관리형 NAT 인스턴스로 이전하고 라우팅 테이블에 최소 권한 원칙을 적용합니다.
- 보안 그룹과 서브넷 NACL을 기본적으로 거부(deny-by-default)하는 상태로 강화하고, AWS Organizations SCP 및 AWS Config 규칙을 통해 중앙 집중식 IAM+SG 기준을 적용합니다.
- Route 53 Resolver 인바운드/아웃바운드 엔드포인트를 배포하고, 조건부 전달 및 DNS Firewall 규칙을 구성하고, CloudWatch Logs로의 리졸버 쿼리 로깅을 활성화하고, DHCP 옵션 세트를 사용하여 RAM을 통해 공유된 모든 VPC에 내부 리졸버 사용을 강제함으로써 하이브리드 DNS를 강화합니다.
근거: 이 접근 방식은 엔드포인트 정책이 있는 VPC 엔드포인트를 사용하여 불필요한 인터넷 이그레스를 제거하고, Transit Gateway/Direct Connect를 통해 라우팅을 중앙 집중화 및 제어하며, 인스턴스 수준 보호를 복원하고, 리졸버 엔드포인트 및 로깅으로 DNS 유출을 방지합니다. 이는 AWS 네트워킹 및 심층 방어(defense-in-depth) 모범 사례에 부합합니다.
VPC 엔드포인트 및 엔드포인트 정책
VPC 엔드포인트는 VPC 내부의 워크로드가 퍼블릭 인터넷이나 NAT 게이트웨이를 거치지 않고 AWS 서비스 API에 도달할 수 있도록 합니다. 두 가지 아키텍처 유형이 있으며, 잘못된 유형을 선택하면 트래픽이 잘못 라우팅되는 흔한 원인이 됩니다.
게이트웨이 엔드포인트: Amazon S3와 DynamoDB에서만 사용됩니다. 라우팅 테이블의 대상(prefix list
pl-xxxxxxxx이vpce-xxxxxxxx를 가리킴)으로 구현됩니다. ENI가 생성되지 않고, DNS 변경이 필요 없으며, 시간당 비용이 없습니다.인터페이스 엔드포인트(PrivateLink): KMS, SQS, SNS, Secrets Manager, STS, EC2 API 및 대부분의 다른 서비스에 사용됩니다. 선택한 서브넷 내부에 프라이빗 IP를 가진 ENI를 프로비저닝하며, 시간당 및 GB당 요금이 청구됩니다.
계정 A의 KMS 키로 암호화된 계정 A의 S3 버킷에서 계정 B의 EC2 인스턴스가 데이터를 읽는 교차 계정 배치 작업의 경우, 올바른 설계는 S3용 게이트웨이 엔드포인트와 KMS용 인터페이스 엔드포인트를 함께 사용하는 것입니다. 게이트웨이 엔드포인트는 s3:GetObject, s3:PutObject, s3:PutObjectAcl, s3:ListBucket 트래픽이 인터넷을 통하지 않도록 하고, 인터페이스 엔드포인트는 kms:Decrypt, kms:Encrypt, kms:GenerateDataKey 트래픽에 대해 동일한 역할을 합니다. KMS 키 ARN은 표준 kms.<region>.amazonaws.com 호스트 이름을 사용하므로, SDK가 수정되지 않은 호스트 이름을 퍼블릭 KMS 서비스가 아닌 엔드포인트 ENI로 확인(resolve)하도록 인터페이스 엔드포인트에서 프라이빗 DNS를 활성화해야 합니다. 프라이빗 DNS가 없거나(또는 VPC 수준의 DNS 호스트 이름 및 DNS 확인 기능이 모두 활성화되지 않은 경우), 클라이언트는 여전히 퍼블릭 엔드포인트에 연결됩니다. 따라서 ‘코드 변경 없음’이라는 요구 사항은 암묵적으로 프라이빗 DNS를 필요로 합니다.
엔드포인트 정책은 두 번째 독립적인 권한 부여 계층입니다. 기본적으로 허용적인 정책이 존재하지만, 특정 버킷과 키에 대해 보안을 강화하는 것은 다음과 같습니다.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": ["s3:GetObject","s3:PutObject","s3:PutObjectAcl","s3:ListBucket"],
"Resource": ["arn:aws:s3:::acct-a-bucket","arn:aws:s3:::acct-a-bucket/*"]
}]
}
단순히 엔드포인트를 생성하는 것만으로는 충분하지 않습니다. 두 가지 실패 모드가 반복적으로 발생합니다. (1) 엔드포인트는 존재하지만 프라이빗 서브넷의 라우팅 테이블에 S3 접두사 목록에 대한 항목이 없어 트래픽이 여전히 NAT 게이트웨이를 통해 외부로 나가는(egress) 경우, (2) 엔드포인트 정책이 s3:PutObjectAcl과 같은 작업을 누락하거나 잘못된 버킷 ARN을 대상으로 지정하여, IAM이라면 허용했을 호출을 조용히 차단하는 경우입니다. 버킷 정책과 엔드포인트 정책 모두 요청을 허용해야 합니다. 두 정책은 합집합(union)이 아닌 교집합(intersection)으로 적용됩니다.
보안 그룹, NACL 및 신속한 격리 조치
보안 그룹과 NACL은 서로 다른 계층에서 중복되는 문제를 해결하며, 시험에서는 종종 사고 대응을 위해 둘 중 하나를 선택하도록 강요합니다.
보안 그룹: 상태 저장(Stateful) 방식이며, ENI 수준에서 평가됩니다. 반환 트래픽은 자동으로 허용됩니다. 허용 규칙만 존재합니다. 호스트 수준 정책(“웹 티어는 8080 포트로 앱 티어에 도달할 수 있음”)에 이상적입니다.
네트워크 ACL(NACL): 상태 비저장(Stateless) 방식이며, 서브넷 경계에서 평가됩니다. 허용 규칙과 거부 규칙이 모두 존재하며, 규칙 번호 순서대로 처리됩니다. 서브넷 전체에 대한 광범위한 차단, 특히 IP 범위를 차단 목록에 추가하거나 서브넷의 모든 인스턴스에 걸쳐 특정 포트를 차단하는 데 이상적입니다.
악성코드 발생으로 인해 여러 인스턴스에서 특정 명령 및 제어(C2) IP 세트로 향하는 아웃바운드 TCP/2905를 차단해야 할 때, NACL 거부 규칙이 올바른 도구입니다. 보안 그룹은 ‘거부’를 표현할 수 없으며, 영향을 받는 모든 ENI에서 참조하는 모든 보안 그룹을 일일이 찾아 수정해야 합니다. 낮은 규칙 번호(예: 90)를 가진 단일 서브넷 수준의 NACL 거부 규칙은 나중에 허용 규칙에 의해 평가될 관련 없는 트래픽은 그대로 유지하면서 해당 서브넷의 모든 인스턴스에 즉시 적용됩니다.
NACL은 상태 비저장이므로, 양방향 모두에 규칙이 필요하다는 점을 기억해야 합니다. 2905 포트의 아웃바운드 트래픽을 차단하는 데 인바운드 규칙은 필요 없지만, 인바운드 응답도 거부하고 싶다면 인바운드 항목을 추가해야 합니다. 또한 정상적인 반환 트래픽이 통과할 수 있도록 임시 포트(1024–65535)에 대한 인바운드 허용 규칙이 있어야 합니다.
NAT 게이트웨이, 라우팅 및 AZ 독립성
NAT 게이트웨이는 영역(zonal) 리소스입니다. 표준적인 패턴은 가용 영역(AZ)당 하나의 NAT 게이트웨이를 두고 각 프라이빗 서브넷의 라우팅 테이블이 0.0.0.0/0 트래픽을 동일한 AZ에 있는 NAT로 향하도록 설정하는 것입니다.
PrivateRouteTable-AZ-a: 0.0.0.0/0 -> nat-aaaa (in subnet public-az-a)
PrivateRouteTable-AZ-b: 0.0.0.0/0 -> nat-bbbb (in subnet public-az-b)
PrivateRouteTable-AZ-c: 0.0.0.0/0 -> nat-cccc (in subnet public-az-c)
여러 AZ에서 단일 NAT를 공유하면 비용이 저렴해 보이지만 두 가지 문제를 야기합니다. 모든 패킷에 대해 AZ 간 데이터 전송 요금이 발생하고, 가용성에 대한 강력한 종속성이 생깁니다. 즉, 해당 AZ에 장애가 발생하면 모든 프라이빗 서브넷의 인터넷 아웃바운드 연결이 끊깁니다. 영역별 NAT 패턴은 또한 Transit Gateway 검사와 결합될 때 발생할 수 있는 비대칭 반환(asymmetric-return) 문제를 방지합니다.
조사를 위한 VPC 흐름 로그
흐름 로그는 VPC, 서브넷 또는 ENI 수준에서 5-튜플 메타데이터(소스/대상 IP, 포트, 프로토콜, 작업 ACCEPT/REJECT, 바이트, 패킷)를 캡처합니다. C2 호스트로 TCP/2905를 통해 비콘(beaconing)을 보내는 인스턴스를 찾아내려면, VPC에서 흐름 로그를 활성화하고 트래픽 유형을 REJECT로 설정한 후(NACL이 현재 트래픽을 차단하고 있으므로) CloudWatch Logs Insights 또는 Athena에서 쿼리합니다.
SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpc_flow_logs
WHERE dstport = 2905 AND action = 'REJECT'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC;
srcaddr 열은 최소한의 노력으로 감염된 인스턴스의 IP를 보여줍니다. 패킷 캡처나 호스트 에이전트 없이도 가능합니다. 트래픽 유형으로 “ALL"을 선택해도 되지만 더 많은 데이터와 비용이 발생합니다. “ACCEPT"만 선택하면 차단된 시도를 완전히 놓치게 되는데, 바로 이 차단된 시도가 여러분이 확인해야 할 정보입니다.
PrivateLink, Transit Gateway, Network Firewall
PrivateLink는 인터페이스 엔드포인트 모델을 자체 서비스까지 확장합니다. 공급자 VPC는 VPC 엔드포인트 서비스 뒤에서 NLB를 노출하고, 소비자는 VPC 피어링이나 라우팅 공유 없이 여기에 연결하기 위해 인터페이스 엔드포인트를 생성합니다. 이 연결은 단방향이며 공급자의 CIDR을 완전히 숨깁니다.
Transit Gateway(TGW)는 다대다(many-to-many) VPC 및 온프레미스 연결을 위한 허브입니다. 일반적인 패턴은 AWS Network Firewall 또는 서드파티 어플라이언스를 실행하는 중앙 집중식 검사 VPC를 두고, TGW 라우팅 테이블이 스포크 간 트래픽을 검사 VPC로 보내는 것입니다. 하지만 기본 TGW 동작에서는 이 설계가 제대로 작동하지 않습니다. TGW가 서로 다른 AZ에 있는 연결 ENI에 걸쳐 플로우를 해싱하기 때문에, 반환 경로가 전달 경로와 다른 AZ로 들어갈 수 있습니다. 상태 저장 방화벽은 자신이 SYN을 보지 못한 중간 플로우 패킷을 삭제합니다.
두 가지 수정 사항을 함께 적용해야 합니다. 첫째, 검사 VPC에 대한 TGW 연결에서 어플라이언스 모드(Appliance Mode)를 활성화해야 합니다. 이렇게 하면 각 양방향 플로우가 동일한 AZ의 ENI에 고정되어 전달 및 반환 트래픽이 동일한 방화벽 엔드포인트를 통과하게 됩니다. 둘째, 스포크 연결이 검사 VPC 연결로 트래픽을 보내도록 TGW 라우팅 테이블을 구성하고, 검사 VPC의 별도 검사 후 라우팅 테이블이 트래픽을 올바른 스포크로 반환하도록 해야 합니다. 둘 중 하나라도 생략하면(어플라이언스 모드만 사용하거나 라우팅 테이블만 사용하는 경우) 비대칭 드롭 문제가 여전히 발생합니다.
Network Firewall 자체는 Suricata 호환 규칙을 사용하며 플로우 상태를 유지하기 위해 대칭 라우팅에 의존합니다. 이를 검사 VPC와 스포크 VPC 양쪽의 Flow Logs와 결합하면, 어떤 스포크가 세션을 시작했는지 그리고 방화벽이 이를 허용했는지 또는 차단했는지를 증명하는 데 필요한 포렌식 추적 경로를 확보할 수 있습니다.
실제 문제: 사용 사례 시나리오
시나리오: Meridian Financial은 us-east-1 리전의 세 가용 영역(AZ)에 걸쳐 프로덕션 VPC를 운영하고 있으며, 이 VPC들은 AWS Transit Gateway를 통해 중앙 보안 VPC에 연결되어 있는 다중 계정 AWS 환경을 사용합니다. 각 AZ의 NAT Gateway를 이그레스(egress)에 사용하고, 파트너 SaaS 연결을 위해 S3 Gateway Endpoint와 Interface Endpoint(PrivateLink)를 사용하며, Security Group 및 NACL과 함께 중앙 집중식 AWS Network Firewall을 사용합니다. VPC Flow Logs는 모니터링을 위해 CloudWatch로 스트리밍됩니다.
과제: 프로덕션 EC2 인스턴스 하나가 외부 IP와 S3로 데이터를 유출하고 내부망에서 수평적으로 이동(lateral movement)하려는 시도를 한 것으로 의심됩니다. Meridian은 다른 비즈니스 크리티컬 VPC에 영향을 주지 않으면서 여러 AZ에 걸쳐 신속하게 격리 조치를 해야 합니다.
권장 접근 방식:
- 침해된 인스턴스의 Security Group을 모든 인바운드/아웃바운드를 거부하는 제한적인 “격리” SG로 교체하여 즉시 격리하고, Systems Manager를 통한 자동화된 해결을 위해 인스턴스에 태그를 지정합니다. 동시에 서브넷 수준의 Network ACL 규칙을 적용하여 의심스러운 외부 IP 범위로의 이그레스를 차단합니다.
- 영향을 받은 VPC의 TGW 라우팅 테이블 연결을 제거하거나 격리용 TGW 라우팅 테이블(블랙홀 또는 다른 연결로의 라우팅 없음)로 변경하여 Transit Gateway에서 해당 VPC를 격리합니다. 이를 통해 다른 VPC로의 수평적 이동을 중지시킵니다.
- TGW/라우팅 테이블 항목을 업데이트하여 나머지 VPC 이그레스 트래픽을 중앙 집중식 AWS Network Firewall을 통과하도록 리디렉션하고, 강제로 검사를 수행하고 알려진 악성 목적지를 차단합니다. 복원력 있는 검사된 이그레스를 위해 AZ별 NAT Gateway를 유지하여 AZ 독립성을 보존합니다.
- S3/DynamoDB Gateway Endpoint에 제한적인 VPC 엔드포인트 정책을 적용하여 데이터 플레인 제어를 강화하고, 승인되지 않은 보안 주체(principal)의 Put/Get을 거부합니다. 내부 API가 인터넷 경로를 피하기 위해 Interface Endpoint(PrivateLink)를 사용하도록 보장합니다.
- VPC Flow Logs를 CloudWatch Logs Insights 및 AWS CloudTrail과 함께 사용하여 포렌식을 수행한 후, 인스턴스를 수정(이미지 재생성, 키 교체)하고 검증 후에만 다시 운영 환경에 투입합니다. AWS Firewall Manager/AWS Config를 통해 규칙을 강제 적용합니다.
근거: 이 순서는 호스트와 네트워크 계층 모두에서 최소 권한 원칙에 따른 신속한 격리를 제공하고, Network Firewall 및 Transit Gateway 라우팅을 통해 검사를 중앙 집중화하여 장애 반경을 최소화하며, AZ별 NAT로 AZ 복원력을 보존하고, 책임 있는 조사를 위해 VPC Flow Logs를 사용합니다. 이는 AWS의 심층 방어(defense-in-depth) 모범 사례에 부합합니다.
← 데이터 보호 및 S3 · 모든 도메인 · 엣지 및 애플리케이션 보안 →
이 문제 연습하기 → · 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.
시험 합격하기 →