NACL
소개글
보안 그룹Security Group이 인스턴스 레벨에서 정밀한 접근 제어를 담당한다면, NACL(Network Access Control List)은 서브넷 경계에서의 광범위한 방어를 담당합니다. Stateless 동작, 규칙 번호 기반 순차 평가, 그리고 거부(Deny) 규칙 지원이라는 세 가지 속성이 Security Group과의 핵심 차이점입니다. 이 글에서는 NACL의 작동 원리, Security Group과의 비교, 그리고 두 메커니즘을 조합한 심층 방어 전략을 살펴봅니다.
개념과 적용 범위
NACL(Network Access Control List)은 서브넷 단위에 적용되는 방화벽이다. 하나의 NACL은 하나 이상의 서브넷에 연결할 수 있으며, 해당 서브넷을 오가는 모든 트래픽이 NACL의 규칙에 의해 평가된다.
Security Group이 ENI 단위에서 개별 인스턴스의 접근을 제어하는 것과 달리, NACL은 서브넷 전체에 대한 가드레일 역할을 수행한다. VPC를 생성하면 기본 NACLDefault NACL이 자동으로 만들어지며, 이 기본 NACL은 모든 인바운드·아웃바운드 트래픽을 허용한다. 반면, 사용자가 직접 생성한 커스텀 NACL은 기본적으로 모든 트래픽을 거부한다.
Stateless 동작
NACL은 보안 그룹과 달리 상태 비저장(Stateless)이다. 요청 트래픽과 응답 트래픽을 각각 독립적으로 평가하므로, 인바운드를 허용했다고 해서 응답이 자동으로 나가지 않는다. 아웃바운드 규칙에서 임시 포트ephemeral port1 범위를 명시적으로 열어줘야 한다.
이 점을 간과하면 통신 장애가 빈번히 발생한다. 예를 들어, 웹 서버 서브넷의 NACL에서 인바운드 443만 열고 아웃바운드를 설정하지 않으면, 클라이언트의 요청은 도착하지만 응답이 나가지 못한다.
인바운드 규칙:
Rule 100: ALLOW TCP 443 from 0.0.0.0/0
아웃바운드 규칙:
Rule 100: ALLOW TCP 1024-65535 to 0.0.0.0/0 ← 이것이 빠지면 응답 불가
규칙 평가 순서
NACL은 규칙 번호Rule Number 순서대로 평가하며, 첫 번째로 매칭되는 규칙에서 평가가 중단된다. 이 점이 Security Group(모든 규칙을 평가하고 하나라도 허용이면 통과)과의 근본적인 차이다.
| 규칙 번호 | 유형 | 프로토콜 | 포트 | 소스 | 허용/거부 |
|---|---|---|---|---|---|
| 100 | TCP | TCP | 443 | 0.0.0.0/0 | ALLOW |
| 200 | TCP | TCP | 443 | 198.51.100.0/24 | DENY |
| * | ALL | ALL | ALL | 0.0.0.0/0 | DENY |
위 구성에서 198.51.100.5의 HTTPS 요청은 Rule 100에 먼저 매칭되어 허용된다. Rule 200의 DENY에 도달하기 전에 평가가 끝나기 때문이다. 특정 IP를 차단하려면 더 작은 번호에 DENY 규칙을 배치해야 한다. 규칙 번호는 보통 100 단위로 부여하여, 나중에 중간에 규칙을 삽입할 여유를 남겨두는 것이 관례다.
허용과 거부 규칙
보안 그룹과 달리 NACL은 허용(ALLOW)과 거부(DENY) 규칙을 모두 지원한다. 이 특성이 NACL의 존재 이유이기도 하다. 특정 악성 IP 대역을 서브넷 경계에서 즉각적으로 차단하는 것은 보안 그룹으로는 불가능하지만, NACL로는 단 하나의 DENY 규칙으로 가능하다.
보안 그룹과 비교
| 기능 | 보안 그룹 | NACL |
|---|---|---|
| 적용 레벨 | 인스턴스(ENI) 단위 | 서브넷 단위 |
| 상태 | Stateful — 응답 자동 허용 | Stateless — 응답도 명시적 허용 필요 |
| 규칙 유형 | 허용(Allow)만 가능 | 허용(Allow) + 거부(Deny) 모두 가능 |
| 평가 순서 | 모든 규칙 평가 (순서 무관) | 규칙 번호 순서대로 (첫 매칭 시 중단) |
| 기본 동작 | 인바운드: 모두 거부 | 기본 NACL: 모두 허용 |
| 주요 용도 | 앱 간 화이트리스트 접근 제어 | 악성 IP 차단, 서브넷 경계 보안 |
심층 방어 전략
보안 그룹과 NACL을 조합하면 네트워크 보안의 심층 방어Defense in Depth를 구현할 수 있다. 핵심은 각 계층에 서로 다른 역할을 부여하는 것이다.
NACL은 서브넷 경계에서의 가드레일을 담당한다. DDoS 공격 시 공격자 IP 대역을 최상단 규칙에 DENY로 추가하면, 서브넷 내 수백 대의 인스턴스를 일일이 수정하지 않고도 즉각적으로 보호할 수 있다. 또한 데이터 서브넷의 NACL에서 아웃바운드 인터넷 경로를 원천 차단하면, 보안 그룹 설정 실수로 인한 데이터 유출을 방지하는 안전장치가 된다.
보안 그룹은 애플리케이션 간 정밀한 접근 제어를 담당한다. SG 참조 기능으로 동적 환경에 자동 대응하며, 3계층 아키텍처의 각 계층 간 트래픽을 최소 권한 원칙에 따라 제어한다.
트래픽 가시성: VPC Flow Logs
보안 정책을 설정하는 것만으로는 부족하다. 실제로 어떤 트래픽이 흐르고 있는지 관찰할 수 있어야 한다.
VPC Flow Logs는 네트워크 인터페이스를 통과하는 트래픽의 메타데이터(소스/대상 IP, 포트, 프로토콜, 패킷 수, 바이트 수, Action)를 기록한다. 패킷의 내용(payload)은 포함하지 않지만, 트래픽 패턴 분석과 보안 규칙 검증에 매우 유용하다.
Flow Logs의 기록 대상은 세 수준에서 선택할 수 있다. VPC 수준(VPC 내 모든 ENI), 서브넷 수준(특정 서브넷의 모든 ENI), 또는 ENI 수준(특정 인스턴스)이다. 기록된 로그는 CloudWatch Logs, S3, 또는 Kinesis Data Firehose로 전송하여 분석할 수 있다.
Flow Log의 Action 필드는 ACCEPT 또는 REJECT 값을 가진다. 거부된 트래픽(REJECT)의 패턴을 분석하면, 비정상적인 포트 스캔 시도나 잘못된 보안 그룹/NACL 설정을 탐지할 수 있다.
출처
- Amazon Web Services (2026) Control subnet traffic with network access control lists. Available at: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html
- Amazon Web Services (2026) Security groups and network ACLs (BP5). Available at: https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/security-groups-and-network-acls-bp5.html
- Amazon Web Services (2026) Logging IP traffic using VPC Flow Logs. Available at: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html
Footnotes
-
클라이언트가 서버에 연결할 때 운영체제가 동적으로 할당하는 소스 포트다. 보통 1024~65535 범위에서 선택된다. ↩