D2-13. Amazon OpenSearch Service
Amazon OpenSearch Service(구 Elasticsearch Service)는 검색(Search) 및 분석(Analytics) 을 위한 관리형 서비스입니다.
1. VPC Flow Logs
VPC Flow Logs는 VPC, 서브넷 또는 개별 ENI(Elactic Network Interface) 레벨에서 주고받는 IP 트래픽 정보를 캡처하는 기능입니다.
주로 네트워크 연결 문제를 해결하고, 트래픽 패턴을 모니터링하며, 악의적인 동작을 탐지하는 데 사용됩니다.
1-1. 핵심 기능 및 대상
- 캡처 범위
EC2 인스턴스뿐만 아니라 ELB, RDS, ElactiCache, NAT Gateway, Transit Gateway 등 AWS 관리형 인터페이스에서 발생하는 트래픽도 포함됩니다. - 데이터 전송
- S3: 장기 보관 및 Athena를 통한 SQL 분석용
- CloudWatch Logs: 실시간 모니터링 및 Logs Insights를 통한 검색용
- Kinesis Data Firehose: 실시간 스트리밍 처리용
- IAM 권한
데이터 전송 시 IAM 역할이 필요하며,logs:CreateLogGroup,logs:CreateLogStream,logs:PutLogEvents와 같은 권한이 포함되어야 합니다.
1-2. 로그 분석
로그 파일에는 트래픽에 대한 상세한 메타데이터가 포함되며, action 필드가 문제 해결의 핵심입니다.
| 필드 | 설명 |
|---|---|
srcaddr / dstaddr |
트래픽을 주고 받는 IP 주소 |
srcport / dstport |
사용된 포트 |
action |
ACCEPT 또는 REJECT결과는 SG(Security Group 또는 NACL(Network ACL) 규칙에 의해 결정 |
1). 주요 분석 도구
- Amazon Athena: S3에 저장된 로그를 SQL로 심층 분석
- CloudWatch Logs Insights: CloudWatch Logs로 전송된 로그를 검색 및 분석
1-3. SG와 NACL 문제 해결
Flow Logs의 action 필드를 분석하면, Stateful(상태 저장)인 SG과 Stateless(상태 비저장)인 NACL 중 무엇이 문제인지 식별할 수 있습니다.
Stateful vs Stateless 핵심 원리
Security Group (Stateful): Inbound가 허용되면, 돌아가는 Outbound 트랙픽은 자동으로 허용됩니다. (반대도 마찬가지)
NACL (Stateless): Inbound와 Outbound 트래픽을 각각 별개로 검사해야 합니다.
1). Inbound 요청
action 필드 |
문제 원인 | 설명 |
|---|---|---|
Inbound REJECT |
NACL 또는 SG 문제 | 트래픽이 인스턴스에 도달하기 전에 둘 중 하나에 의해 거부됩니다.해당 로그만으로는 정확한 원인 판별이 불가능합니다. |
Inbound ACCEPT + Outbound REJECT |
NACL 문제 | SG는 Stateful이라 Inbound가 ACCEPT되면 Outbound를 자동으로 허용합니다.그런데도 Outbound가 REJECT된 것은 Stateless인 NACL이 Outbound 트래픽을 차단했다는 의미입니다. |
2). Ounbound 요청
action 필드 |
문제 원인 | 설명 |
|---|---|---|
Outbound REJECT |
NACL 또는 SG 문제 | 트래픽이 외부에 도달하기 전에 둘 중 하나에 의해 거부됩니다.해당 로그만으로는 정확한 원인 판별이 불가능합니다. |
Outbound ACCEPT + Inbound REJECT |
NACL 문제 | SG는 Stateful이라 Outbound가 ACCEPT되면 Inbound를 자동으로 허용합니다.그런데도 Inbound가 REJECT된 것은 Stateless인 NACL이 Inbound 트래픽을 차단했다는 의미입니다. |
1-4. 주요 아키텍처 패턴
1). Top Tolker(트래픽 상위 IP) 분석
2). 실시간 이행 행위 탐지 (SSH 접속 시도 감지 등)
3). SQL 분석 및 시각화
1-5. 로깅 예외
VPC Flow logs는 대부분의 IP 트래픽을 캡처하지만, 아래와 같은 특정 트래픽은 로깅(캡처)하지 않습니다.
- Amazon DNS 서버로 향하는 트래픽 (커스텀 DNS 서버로 향하는 드래픽은 로깅됨.)
- Amazon Windows 라이선스 활성화 트래픽
- EC2 인스턴스 메타데이터 서비스(
169.254.169.254) 트래픽 - Amazon Time Sync 서비스(
169.254.169.123) 트래픽 - 모든 DHCP 트래픽
- 트래픽 미러링(Mirrored) 을 통한 생성된 트래픽
- VPC 라우터의 예약된 IP 주소(각 서브넷의
x.x.x.1주소)로 향하는 트래픽 - VPC Endpoint ENI와 Network Load Balancer ENI 간의 트래픽
2. VPC Traffic Mirroring
VPC Traffic Mirroring은 VPC 내의 네트워크 트래픽을 실시간으로 복사하여 비간섭적(Non-intrusive) 방식으로 검사할 수 있게 해주는 기능입니다.
원본 트래픽에 영향을 주지 않고 사본을 보안 장비로 전송하여 위협 모니터링, 콘텐츠 검사, 문제 해결 등을 수행할 수 있습니다.
2-1. 동작 방식
| 구성 요소 | 설명 |
|---|---|
| Source | 트래픽을 모니터링할 대상 |
| Target | 복사된 트래픽을 수신할 목적지일반적으로 NLB(Network Load Balancer)를 사용하며, 이 NLB는 트래픽을 분석용 보안장비로 라우팅합니다. |
| Filter | 선택 사항으로 모든 트래픽이 아닌, 특정 트래픽만 복사하도록 지정하는 규칙 |
원본 트래픽은 중단 없이 정상적으로 Source ENI로 계속 전달됩니다.
트래픽의 사본만 Target으로 전송되므로, Source는 미러링 사실을 인지하지 못하며 성능에 영향을 받지 않습니다.
2-2. 주요 용도
- 콘텐츠 검사: 악성 페이로드나 데이터 유출 검사
- 위협 모니터링: 비정상적인 트래픽 패턴이나 침입 시도 탐지
- 네트워크 문제 해결: 상세한 패킷 레벨의 트러블슈팅
2-3. 라우팅
핵심 원칙은 미러링된 트래픽(Source)이 대상(Target)으로 라우팅(Routing)될 수 있어야 한다는 것입니다.
즉, Source와 Target이 사설 IP를 통해 서로 통신할 수 있는 네트워크 경로에 있어야 합니다.
- 동일 VPC: Source ENI와 Target ENI이 같은 VPC 내에 있는 기본적이고 간단한 구성
- VPC Peering: 서로 다른 VPC가 연결되어, Source VPC의 트래픽이 Target VPC로 라우팅
- Transit Gateway: Transit Gateway를 통해 연결된 VPC 간에 트래픽을 라우팅
VPC Peering vs Transit Gateway
VPC Peering은 두 VPC 간의 1:1 직접 연결(Mesh 구조)이며, Transit Gateway는 여러 VPC와 온프레미스를 연결하는 중앙 허브(Hub-and-Spoke 구조)입니다.가장 큰 차이는 전이성(Transitive) 유무입니다.
VPC Peering: 전이성 없음 (A↔B, B↔C 연결되어도 A↔C는 통신 불가)
Transit Gateway: 전이성 있음 (허브를 통해 A↔B↔C 모두 통신 가능)
3. VPC Traffic Mirroring 아키텍처 패턴
3-1. 트래픽 분산 모델
모니터링할 트래픽이 많거나 여러 종류의 분석이 필요할 때 사용합니다.
1). 동일 어플라이언스 확장
트래픽을 동일한 보안 장비 여러 대에 분산 시킵니다.
미러링된 트래픽을 NLB로 전송하고, NLB 뒤편의 ASG(Auto Scaling Group)이 트랙픽을 처리합니다.
트래픽이 증가하면 ASG가 자동으로 확장되어 유연하게 대응할 수 있습니다.
2). 서로 다른 어플라이언스 분산
트래픽을 여러 종류의 보안 장비로 보냅니다.
미러링된 트래픽은 먼저 Cloud Packet Broker(타사 솔루션)로 전송됩니다.
해당 Broker가 트래픽의 특성을 파악하여, 목적에 맞게 목적에 맞는 보안 장비로 분배합니다.
3-2. 중앙 집중화 모델
여러 VPC나 계정에 분산된 트래픽을 한 곳으로 모아 중앙에서 관리하고 분석하는 모델입니다.
1). VPC Peering
각 소스 VPC와 중앙의 “보안 VPC”를 VPC Peering으로 1:1 연결합니다.
이를 통해 각 VPC의 트래픽을 중앙 모니터링 어플라이언스로 라우팅하여 분석할 수 있습니다.
2). TGW(Transit Gateway)
Transit Gateway를 허브로 사용하여, 여러 계정과 여러 VPC를 중앙의 “보안 VPC”에 연결합니다.
모든 트래픽이 TGW를 통해 중앙으로 모이므로 확장성이 매우 뛰어나지만, TGW 데이터 처리 비용이 추가로 발생할 수 있습니다.
3-3. 자동화된 대응 모델
보안 위협이 탐지되었을 때만 자동으로 트래픽 미러링을 활성화하여 필요한 포렌식 데이터를 수집하는 아키텍처입니다.
- Step 1. GuardDuty가 탐지한 경보를 EventBridge로 전송합니다.
- Step 2. EventBridge는 경보를 받아 Lambda 함수를 트리거합니다.
- Step 3. Lambda 함수가 경보 내용을 분석하여, 자동 활성화합니다.
- 실시간 분석을 위한 모니터링 어플라이언스를 실행
- 위협이 탐지된 EC2 인스턴스의 ENI에 VPC Traffic Mirroring 세션을 자동으로 활성화
- Step 4. 즉시 복제되기 시작한 공격 트래픽은 분석을 위해 S3 등으로 전송됩니다.
4. VPC Network Access Analyzer
VPC Network Access Analyzer는 리소스에 대한 잠재적인 네트워크 경로를 식별하여, 네트워크 보안 의도(요구 사항)와 실제 구성이 일치하는지 확인하는 도구입니다.
이를 통해 “모든 데이터베이스는 인터넷에서 접근 불가능해야 한다”와 같은 네트워크 요구 사항을 정의하고, 실제 규정 준수 여부를 자동으로 검증할 수 있습니다.
4-1. Network Access Scope
분석의 기준이 되는 보안 요구 사항을 정의한 JSON 문서입니다. “인터넷 게이트웨이에서 RDS로 들어오는 트래픽이 없어야 한다”와 같이 구체적인 조건을 이 Scope에 정의합니다.
4-2. 동작 방식
- Step 1. 요구 사항 정의
보안 관리자가 Network Access Scope를 생성하여 허용되거나 차단되어야 할 네트워크 경로를 정의합니다. - Step 2. 자동 분석
분석기가 VPC의 모든 리소스(EC2, RDS 등)와 네트워크 구성(보안 그룹, NACL, 라우팅 테이블, 인터넷 게이트웨이 등)을 수학적으로 분석합니다. - Step 3. 결과 도출
정의된 Scope를 위반하는(예: 의도치 않게 인터넷에 노출된 RDS) 리소스가 발견되면 이를 보고합니다.