[AWS] Network Firewall

CLOUD COMPUTING · SECURITY

Network Firewall

방화벽의 기본 원리부터 AWS Network Firewall의 아키텍처, Stateless·Stateful 룰 작성법, ACM 연동 TLS 검사, 그리고 콘솔/실습 기준 생성 가이드까지 전부 담는다.

Category	Level	Reads	Status
Cloud Computing · Security	중급 ~ 고급	약 25분	VERIFIED

Part 1

방화벽(Firewall) 기초

개념 · 동작 방식 · 장단점

01 · Concept

방화벽(Firewall)이란?

방화벽은 네트워크를 드나드는 트래픽을 미리 정한 규칙에 따라 검사하고, 허용하거나 차단하는 보안 장치다.

이름은 건물의 화재 확산을 막는 방화벽(내화벽)에서 왔다 — 불이 나도 그 구획 밖으로 번지지 않게 막는 벽처럼, 네트워크 방화벽도 위협이 한쪽 네트워크에서 다른 쪽으로 번지지 않게 막는 경계 역할을 한다. 모든 트래픽은 이 경계를 지날 때 규칙과 대조되고, 규칙에 맞지 않으면 차단된다.

02 · How Firewalls Work

동작 방식 — 검사의 깊이에 따른 3단계

방화벽은 트래픽을 얼마나 깊이 들여다보느냐에 따라 세대가 나뉜다. 뒤에서 다룰 AWS Network Firewall은 이 세 가지를 모두 아우른다.

패킷 필터링
(Stateless)

각 패킷의 헤더(출발지·목적지 IP, 포트, 프로토콜 — 이른바 5-tuple)만 보고 개별적으로 허용/차단을 판단한다. 앞뒤 패킷의 맥락(연결 상태)은 기억하지 않는다. 가장 빠르지만 가장 단순하다.

상태 기반 검사
(Stateful)

연결의 상태(이 패킷이 기존에 허용된 연결에 속하는 응답인지)를 추적한다. "나가는 요청을 허용했다면 그에 대한 응답은 자동으로 허용"하는 식으로, 매번 왕복 규칙을 다 적을 필요가 없다.

심층 패킷 검사
(DPI / IDS·IPS)

헤더뿐 아니라 패킷 내용(페이로드)까지 검사해서 악성 시그니처, 특정 도메인 접근, 애플리케이션 계층 패턴을 탐지·차단한다. 가장 강력하지만 연산 비용이 크다.

TERM 5-tuple

패킷을 식별하는 다섯 가지 값 — 출발지 IP, 출발지 포트, 목적지 IP, 목적지 포트, 프로토콜. Stateless 방화벽 규칙의 기본 판단 기준이다.

03 · Why & When

왜, 그리고 언제 쓰는가

장점

• 정책 기반으로 트래픽을 중앙에서 일관되게 통제
• 알려진 악성 트래픽·침해 시도를 사전에 차단
• 규제 준수(내부망 분리, 아웃바운드 통제) 대응
• DPI 수준까지 가면 애플리케이션 계층 위협도 탐지

한계

• 규칙 관리가 늘어날수록 운영 복잡도가 커짐
• DPI는 연산 비용·지연이 상대적으로 큼
• 암호화된 트래픽(TLS)은 복호화 없이는 내용을 볼 수 없음
• 방화벽 하나로 모든 위협을 막을 수는 없음(다계층 방어의 한 층일 뿐)

언제 쓰는가 — 인터넷과 만나는 모든 경계, 서로 다른 신뢰 수준의 네트워크 구간 사이, 그리고 규제상 트래픽 검사·로깅 의무가 있는 환경이라면 사실상 필수다.

Part 2

AWS Network Firewall

아키텍처 · 구성요소 · 룰 작성법

04 · Concept

AWS Network Firewall이란?

AWS Network Firewall은 VPC 트래픽에 대해 Stateless·Stateful 검사와 DPI(침입 탐지/방지)까지 제공하는 완전관리형 네트워크 방화벽이다. Suricata 기반 엔진 위에서 동작해서, 업계 표준 IDS/IPS 룰을 그대로 가져다 쓸 수 있다.

구분	Security Group	NACL	Network Firewall
적용 단위	인스턴스(ENI)	서브넷	VPC(서브넷 경계)
상태 추적	Stateful	Stateless	Stateless + Stateful 모두
검사 깊이	5-tuple만	5-tuple만	5-tuple + 페이로드(DPI)
도메인/URL 필터링	불가	불가	가능
IDS/IPS 시그니처	불가	불가	가능(Suricata 룰)

헷갈리지 않기 Security Group·NACL은 기본적인 접근 통제다. Network Firewall은 그 위에서 도메인 단위 아웃바운드 통제, 악성 트래픽 탐지, TLS 검사까지 하는 더 상위의 보안 계층이다 — 서로 대체재가 아니라 함께 겹겹이 쓰는 다계층 방어(Defense in Depth) 구성요소다.

05 · Architecture

VPC 배치 아키텍처

Network Firewall은 물리적으로 각 AZ의 전용 서브넷(Firewall Subnet)에 엔드포인트를 만들고, 라우팅 테이블을 조작해서 트래픽이 이 엔드포인트를 반드시 거치도록 강제하는 방식으로 동작한다.

모든 인바운드·아웃바운드 트래픽이 라우팅 테이블에 의해 Firewall Subnet을 강제로 경유

Firewall Subnet

Network Firewall 엔드포인트 전용 서브�트. AZ마다 하나씩 만들어야 고가용성이 확보된다. 이 서브넷 자체에는 워크로드를 두지 않는다.

Protected Subnet

실제 EC2·애플리케이션이 있는 서브넷. 이 서브넷의 라우팅 테이블에서 인터넷으로 나가는 트래픽의 다음 홉을 Firewall Endpoint로 지정한다.

Public Subnet(IGW)

인터넷에서 들어오는 트래픽을 받는 서브넷. 여기서도 라우팅 테이블을 조작해 인바운드 트래픽이 Firewall Endpoint를 거치게 만든다.

TERM 비대칭 라우팅 주의

인바운드·아웃바운드 트래픽이 서로 다른 경로로 Firewall Endpoint를 거치면(비대칭 라우팅) Stateful 검사가 깨질 수 있다. 양방향 모두 같은 엔드포인트를 일관되게 거치도록 라우팅 테이블을 설계해야 한다.

06 · Core Components

핵심 구성요소의 관계

Firewall → Firewall Policy → 여러 Rule Group(Stateless/Stateful)을 참조하는 계층 구조

1개의 Firewall은 정확히 1개의 Firewall Policy를 가지며, 그 Policy가 여러 개의 Rule Group을 순서대로 참조한다. 실제 "허용/차단" 판단 로직은 전부 Rule Group 안에 있다 — Firewall과 Policy는 그 Rule Group들을 어떤 서브넷에, 어떤 순서로 적용할지 결정하는 그릇이다.

07 · Rule Writing

STATELESS

Stateless Rule Group 작성법

Stateless 규칙은 5-tuple만 보고 우선순위(Priority) 순서대로 평가된다. 각 규칙은 하나의 액션을 갖는다.

pass

매칭되면 통과시키고, Stateful 검사도 생략(또는 이어서 진행하도록 설정)

drop

매칭되면 즉시 폐기, 이후 어떤 검사도 진행 안 함

forward_to_sfe

매칭되면 Stateful 엔진으로 넘겨 추가 검사 진행

// Stateless 규칙 예시 (콘솔/JSON 기준 개념)
Priority: 100
Source: 10.0.0.0/16       // 사내 대역만
Destination: 0.0.0.0/0
Protocol: TCP
Destination Port: 443
Action: forward_to_sfe    // Stateful 엔진으로 전달해 추가 검사

Priority: 200
Source: 0.0.0.0/0
Destination: 0.0.0.0/0
Protocol: ALL
Action: drop               // 나머지는 기본적으로 차단

실무 패턴 Stateless 규칙은 정교한 판단보다는 "이 트래픽은 Stateful 엔진으로 넘길지 말지"를 빠르게 걸러내는 1차 관문으로 주로 쓴다. 세밀한 허용/차단 로직은 대부분 Stateful Rule Group에서 처리한다.

08 · Rule Writing

STATEFUL

Stateful Rule Group 작성법 — 3가지 형식

Stateful 규칙은 연결 상태를 추적하며, 3가지 형식 중 하나로 작성한다. 목적에 따라 형식을 고른다.

① Standard 형식 (5-tuple + 옵션)

가장 기본적인 형식. Suricata 문법을 몰라도 출발지·목적지·포트·프로토콜·액션을 직관적으로 지정할 수 있다.

Action: DROP
Protocol: TCP
Source: ANY   Source Port: ANY
Direction: FORWARD
Destination: 198.51.100.0/24   Destination Port: 3389
Rule Options: sid:1000001; msg:"내부 RDP 포트로의 접근 차단";

② 도메인 목록 형식 (Domain List)

HTTP/HTTPS 트래픽의 도메인(호스트 헤더 또는 SNI)을 기준으로 허용/차단 목록을 관리한다. 화이트리스트 방식의 아웃바운드 통제에 가장 널리 쓰인다.

// Domain List Rule Group 예시
Rule type: DENYLIST (또는 ALLOWLIST)
Target types: TLS_SNI, HTTP_HOST
Targets:
  - .amazonaws.com
  - .github.com
  - update.example-vendor.com

실무에서 가장 흔한 패턴 프라이빗 서브넷의 아웃바운드를 "회사가 승인한 도메인만" 허용하고 싶을 때 ALLOWLIST 방식의 Domain List Rule Group을 쓰는 게 가장 직관적이고 유지보수가 쉽다. 다만 암호화된 HTTPS 트래픽에서 SNI만으로 판단하는 것과, 뒤에서 볼 TLS Inspection으로 실제 내용까지 검사하는 것은 다른 수준의 통제라는 점을 구분해야 한다.

③ Suricata 호환 형식 (완전한 IDS/IPS 룰)

가장 강력하고 세밀한 형식. Suricata 문법을 그대로 사용해서 페이로드 패턴, 시그니처 기반 탐지까지 가능하다.

alert tcp any any -> any any (
  msg:"SQL Injection 시도 탐지";
  flow:to_server,established;
  content:"UNION SELECT"; nocase;
  sid:1000002; rev:1;
)

drop tcp $HOME_NET any -> $EXTERNAL_NET 6667 (
  msg:"IRC 프로토콜(악성코드 C2 의심) 아웃바운드 차단";
  sid:1000003; rev:1;
)

이 형식은 오픈소스 위협 인텔리전스 룰셋(Emerging Threats 등)을 거의 그대로 가져다 쓸 수 있다는 게 큰 강점이다.

규칙 평가 순서

Default order

Pass → Drop → Alert 순으로 액션 우선순위에 따라 평가. 여러 룰 그룹의 규칙이 섞여도 AWS가 정한 기본 순서를 따른다.

Strict order

룰 그룹과 규칙을 작성한 순서 그대로 첫 매칭에서 평가를 멈춘다. 세밀하게 순서를 통제하고 싶을 때 사용하며, 최근 신규 정책은 이 방식이 권장된다.

TERM Rule Group Capacity

Rule Group을 생성할 때 미리 선언하는 최대 처리 용량(Capacity Unit). 규칙 하나가 차지하는 용량은 조건의 복잡도에 따라 달라지며, 한 번 정한 Capacity는 이후 늘릴 수 없어 여유 있게 설정하는 것이 실무 관행이다.

09 · TLS Inspection

TLS Inspection과 ACM 연동

HTTPS 트래픽은 암호화되어 있어 기본적으로는 SNI(어떤 도메인에 접속하는지) 정도만 보인다. 내용(페이로드)까지 검사하려면 방화벽이 트래픽을 복호화해야 하는데, 이때 ACM(AWS Certificate Manager)이 필요하다.

TLS Inspection = 방화벽이 복호화 → 검사 → 재암호화하는 중간자(MITM) 구조

ACM 연동 절차 개념

1. CA 인증서 준비

사설 CA(AWS Private CA 또는 자체 CA)로 발급한 인증서를 ACM에 가져오기(Import)한다. 이 인증서가 방화벽이 트래픽을 재서명할 때 쓰는 신뢰의 근거가 된다.

2. TLS Inspection Configuration

Network Firewall 콘솔에서 이 구성을 새로 만들고, ACM의 인증서를 지정한다. 아웃바운드/인바운드 검사 범위(Scope)도 여기서 정의한다.

3. Firewall Policy에 연결

생성한 TLS Inspection Configuration을 Firewall Policy에 연결하면, 그 정책이 적용된 트래픽부터 복호화·검사가 시작된다.

4. 클라이언트 신뢰 배포

내부 클라이언트(EC2 등)의 신뢰 저장소에 이 CA 인증서를 배포해야 한다. 그렇지 않으면 클라이언트가 재서명된 인증서를 "알 수 없는 CA"로 인식해 연결 오류가 난다.

주의 TLS Inspection은 강력하지만 모든 트래픽에 적용하면 성능 부담과 관리 복잡도가 크다. 규제상 반드시 내용 검사가 필요한 구간(예: 아웃바운드 데이터 유출 방지)에 Scope를 한정해서 적용하는 것이 실무 관행이다.

TERM Certificate Chain of Trust

TLS Inspection이 성립하려면 방화벽의 재서명 인증서 체인을 클라이언트가 신뢰해야 한다. 이 신뢰 체인이 깨지면 정상적인 HTTPS 연결도 인증서 오류로 실패한다 — 앞서 다룬 TLS 글의 Chain of Trust 개념이 여기서도 그대로 적용된다.

10 · Managed Rule Groups

AWS 관리형 규칙 그룹

직접 룰을 짜지 않아도, AWS가 위협 인텔리전스를 기반으로 지속 업데이트하는 관리형 Rule Group을 그대로 가져다 쓸 수 있다.

• 봇넷 명령·제어(C2) 도메인 차단 — 알려진 악성 C2 서버로의 아웃바운드 통신 차단
• 알려진 악성 IP 평판 목록 — 위협 인텔리전스 기반 IP 차단
• Log4j 등 특정 취약점 대응 룰셋 — 주요 공개 취약점이 알려질 때마다 긴급 업데이트되는 시그니처

자체 룰과 관리형 룰을 같은 Firewall Policy 안에서 함께 참조할 수 있어, 기본 방어선은 관리형 룰에 맡기고 조직 특화 정책만 커스텀 룰로 얹는 조합이 일반적이다.

11 · Logging

로깅

로그 타입	내용
Alert 로그	Stateful 규칙에서 alert/drop으로 매칭된 이벤트
Flow 로그	방화벽을 지나간 모든 연결의 흐름 정보(NetFlow 유사)
TLS 로그	TLS Inspection 과정에서 발생한 이벤트(핸드셰이크 실패 등)

로그 목적지로 S3(장기 보관·분석), CloudWatch Logs(실시간 모니터링·알림), Kinesis Data Firehose(SIEM 등 외부 연동) 중 하나 이상을 선택할 수 있다.

12 · Trade-offs

장단점

장점

• 완전관리형 — 방화벽 소프트웨어·패치를 직접 운영할 필요 없음
• Suricata 호환으로 업계 표준 룰셋 재사용 가능
• 도메인 필터링·TLS 검사까지 하나의 서비스로 커버
• AWS 관리형 위협 인텔리전스 룰을 즉시 활용 가능

단점

• 서브넷 설계·라우팅 재구성이 필요해 초기 도입 난이도가 있음
• Rule Group Capacity는 사후 확장이 불가능해 신중한 사전 설계 필요
• TLS Inspection은 성능·인증서 배포 관리 부담을 동반
• 트래픽량에 비례한 처리 비용이 발생

13 · Decision Guide

언제 Network Firewall을 추가해야 하나

• Security Group·NACL만으로는 도메인 단위 아웃바운드 통제가 불가능할 때
• 규제상 침입 탐지/방지(IDS/IPS) 로그·증적이 필요할 때
• 여러 VPC의 아웃바운드 정책을 중앙에서 일괄 통제해야 할 때
• 알려진 위협 시그니처 기반의 실시간 차단이 필요할 때

Part 3

실습 가이드

콘솔 기준 생성 순서 — 서브넷 설계부터 검증까지

14 · Hands-on Guide

AWS Network Firewall 생성 가이드

실제 구축 시 반드시 이 순서를 지켜야 한다 — 방화벽 리소스를 먼저 만들고 라우팅을 나중에 바꾸는 순서가 중요하다(반대로 하면 트래픽이 끊긴다).

1

Firewall Subnet 설계

기존 VPC에 AZ마다 전용 서브넷을 하나씩 추가한다(예: 10.0.100.0/28, 10.0.101.0/28). 이 서브넷엔 워크로드를 두지 않는다. VPC 콘솔 → Subnets → Create subnet에서 진행.

2

Stateless Rule Group 생성

VPC 콘솔 → Network Firewall → Network Firewall rule groups → Create. 유형은 Stateless, Capacity는 규칙 수보다 여유 있게(예: 예상 규칙의 1.5배) 지정하고, 07장의 예시처럼 규칙을 추가한다.

3

Stateful Rule Group 생성

같은 메뉴에서 유형을 Stateful로 선택. 룰 형식(Standard/Domain list/Suricata) 중 목적에 맞는 것을 고르고 08장의 예시를 참고해 규칙을 입력한다. Domain list부터 시작하는 걸 권장한다 — 진입장벽이 가장 낮다.

4

Firewall Policy 생성

Network Firewall policies → Create. 2·3단계에서 만든 Rule Group을 각각 Stateless/Stateful 슬롯에 추가하고, 평가 순서(Default/Strict order)를 지정한다. 기본 아웃바운드 액션(Drop 권장 — 화이트리스트 방식)도 이때 정한다.

5

Firewall 리소스 생성

Firewalls → Create firewall. 대상 VPC를 선택하고, 1단계에서 만든 Firewall Subnet들을 AZ별로 매핑한 뒤, 4단계의 Firewall Policy를 연결한다. 생성 후 각 서브넷에 Firewall Endpoint(ENI)가 자동으로 만들어진다.

6

라우팅 테이블 재구성

Protected Subnet: 0.0.0.0/0 → Firewall Endpoint. Firewall Subnet: 0.0.0.0/0 → Internet Gateway. Public/IGW 라우팅 테이블: Protected Subnet 대역 → Firewall Endpoint. 05장 아키텍처 다이어그램의 화살표 방향과 정확히 일치해야 한다.

7

(선택) TLS Inspection 구성

ACM에서 사설 CA 인증서를 Import → Network Firewall → TLS inspection configurations → Create에서 해당 인증서 지정 → 4단계 Firewall Policy에 연결. 09장의 절차를 그대로 따른다.

8

로깅 활성화 & 검증

Firewall 설정에서 Logging을 켜고 목적지(S3/CloudWatch Logs)를 지정한다. Protected Subnet의 EC2에서 허용/차단 대상 도메인으로 각각 접속을 시도해 의도한 대로 동작하는지, 로그에 기록되는지 확인한다.

디버깅 팁 트래픽이 예상과 다르게 막히거나 뚫릴 때 가장 먼저 확인할 것은 라우팅 테이블의 방향성이다. Stateful 규칙이 응답 트래픽까지 제대로 추적하려면 인바운드·아웃바운드가 반드시 같은 Firewall Endpoint를 대칭적으로 거쳐야 한다 — 05장에서 언급한 비대칭 라우팅 문제가 실무에서 가장 흔한 장애 원인이다.

15 · Wrap-up

정리

방화벽은 결국 "트래픽을 어디까지 들여다보고 판단할 것인가"의 문제다. AWS Network Firewall은 Stateless로 빠르게 걸러내고, Stateful(Standard/Domain List/Suricata 3형식)로 정교하게 판단하고, 필요하면 TLS Inspection + ACM으로 암호화된 내용까지 들여다본다. Security Group·NACL이 기본 방어선이라면, Network Firewall은 그 위에 얹는 도메인 통제와 위협 탐지 계층이다 — 실습 순서(서브넷 → 룰그룹 → 정책 → 방화벽 → 라우팅)만 정확히 지키면 구축 자체는 생각보다 어렵지 않다.

---

CLOUD COMPUTING BLOG NETWORK FIREWALL · TLS INSPECTION · ACM