실습 1-2 _ Network ACL

실습 1-2 — 네트워크 ACL: 서브넷 경계의 경비초소

이전 편에서 라우팅 테이블로 "길"을 정했습니다. 이번엔 그 길목을 지키는 방화벽을 세웁니다. NACL은 SG와 함께 AWS 네트워크 보안의 양대 축입니다.

📌 이번 편 한눈에

키워드	핵심
적용 범위	서브넷 단위 (인스턴스 단위는 SG)
상태	Stateless — 응답도 따로 허용해야 함
평가	규칙번호 작은 것부터, 첫 일치 시 중단
기본 NACL	전부 허용 / 커스텀 NACL은 전부 거부(반대!)

---

1. 개념 — "서브넷 경계의 경비초소"

NACL은 서브넷 단위로 동작하는 방화벽입니다. 서브넷에 드나드는 모든 트래픽이 이 관문을 거칩니다. IP·프로토콜·포트(L3+L4)를 보고 허용/거부를 판단합니다.

2. 핵심 특성 4가지 (시험 단골)

• Stateless(상태 비저장): 들어온 연결을 기억하지 않습니다. 그래서 응답(반대 방향)도 규칙으로 따로 허용해야 합니다. → 응답이 나가는 임시포트(ephemeral port, TCP 1024–65535) 를 열어줘야 함.
• 규칙번호 순 평가: 작은 번호부터 보고, 처음 일치하면 즉시 적용·이후 무시. 마지막 *는 묵시적 Deny.
• 허용 + 거부 모두 가능: SG와 달리 명시적 Deny 규칙을 쓸 수 있습니다. (특정 IP 차단에 유용)
• 서브넷 단위: 같은 서브넷 내부 통신은 NACL을 안 거칩니다. 서브넷 경계를 넘을 때만 작동.

3. AWS에서 어떻게 쓰이나

• 소속/연결: VPC 리소스이며 서브넷에 연결됩니다. 서브넷 1개 = NACL 1개, NACL 1개 = 여러 서브넷 가능.
• 기본(Default) NACL: VPC 생성 시 자동 생성. 인바운드·아웃바운드 모두 ALL ALLOW(전부 통과). 서브넷은 기본적으로 이 NACL에 자동 연결됩니다.
• 커스텀 NACL: 직접 만들면 기본이 전부 Deny(규칙 추가 전까지 다 막힘) — 기본 NACL과 정반대라 주의.
• 삭제 불가: 기본 NACL은 VPC를 지울 때만 사라집니다. 대신 서브넷 연결을 커스텀으로 옮기면 됩니다.

규칙 구성 요소: 규칙번호 / 유형 / 프로토콜 / 포트범위 / 소스(또는 대상) / 허용·거부

4. NACL vs Security Group (핵심 비교)

구분	Network ACL	Security Group
적용 범위	서브넷	인스턴스(ENI)
상태	Stateless (응답 따로 허용)	Stateful (응답 자동 허용)
규칙	허용 + 거부	허용만
평가	번호 순서대로, 일치 시 중단	전체 종합 (순서 무관)
소스	IP 대역만	IP + 다른 SG 참조

5. 관례와 실무 팁

• 대부분 기본 NACL(전체 허용) 그대로 둡니다. 세밀한 제어는 SG가 1차 담당하고, NACL은 방어 심화(defense-in-depth) 보조 계층으로 씁니다.
• NACL이 빛나는 경우: 서브넷 전체에 광범위 차단이 필요할 때. 예) 악성 IP 대역 한 줄로 Deny, 특정 서브넷 통째 격리, 컴플라이언스상 서브넷 단위 통제.
• 규칙번호는 100 단위로 띄웁니다(100, 200, 300…). 사이에 끼워 넣을 여유(150 등)를 두는 관례.
• Stateless 응답 처리 잊지 말기: 커스텀 NACL을 쓸 땐 아웃바운드에 임시포트(1024–65535) 허용을 꼭 넣어야 응답이 나갑니다. 빠뜨리면 "요청은 가는데 응답이 안 와요" 사고.
• 세밀한 제어를 NACL로 하지 말 것: NACL은 IP만 보고 SG 참조가 안 되며 Stateless라 관리가 번거롭습니다. "이 인스턴스만, 이 SG에서만"은 SG로.

6. 트러블슈팅 사고법 (증상으로 구분)

• 요청이 멈춤 → 타임아웃: NACL/방화벽이 조용히 드롭한 것(차단). RST가 안 와서 hang.
• 즉시 거부(refused, 0ms): 네트워크는 도달, 서비스(데몬)가 없음 — NACL 문제 아님.

앞 실습에서 NACL 50번으로 HTTP 80을 Deny했을 때 curl이 타임아웃난 게 정확히 이 케이스입니다. 반대로 httpd가 없을 땐 refused였고요.

📎 L3(IP)+L4(포트)에서 서브넷 경계를 지키는 Stateless 방화벽 — 이게 NACL의 정체입니다. SG(인스턴스·Stateful)와 짝을 이뤄 2중 방어를 만듭니다.

---

실습 — 네트워크 ACL 생성

네트워크 ACL 생성 클릭 → 이름 My-VPC-ACL 입력 → VPC 지정 후 생성합니다.

⚠️ 커스텀 NACL은 생성 직후 전부 Deny입니다 — 기본 NACL과 정반대! 규칙을 추가하고 서브넷에 연결해야 동작합니다. 아래는 최초 생성된 NACL의 인바운드 규칙 모습입니다.

인바운드 규칙 편집

인바운드 규칙 편집을 클릭합니다.

필드별 의미

• 규칙 번호 (100): 평가 순서. 작은 번호부터 보고 처음 일치 시 적용. 관례상 100 단위.
• 유형: 프리셋(SSH, HTTP, HTTPS, 모든 트래픽 등). 고르면 프로토콜·포트 자동.
• 프로토콜: TCP/UDP/ICMP (유형 선택 시 자동).
• 포트 범위: 목적지 포트(HTTP=80, SSH=22).
• 소스: 인바운드 출발지 IP 대역. NACL은 IP(CIDR)만 — SG 참조 불가.
• 허용/거부: Allow / Deny (NACL은 Deny도 가능).
• * 행: 묵시적 거부. 고정이라 편집·삭제 불가, 항상 마지막 평가.

지금 설정의 의미

• 100 | 모든 트래픽 | 0.0.0.0/0 | 허용 → 인바운드 전부 허용
• * | 거부 → 위에서 다 허용되니 도달 안 함

즉 현재는 기본 NACL과 똑같이 "전부 통과" 상태(필터링 없음).

어떻게 채울지 (목적에 따라)

• 실습·통과만 원함: 100 모든 트래픽 허용 그대로 저장(단순)
• 실제 제어: 모든 트래픽 허용을 빼고 필요한 것만:
  • 100 | HTTP(80) | 0.0.0.0/0 | 허용
  • 110 | SSH(22) | 내IP/32 | 허용
  • 120 | 사용자 지정 TCP | 1024-65535 | 0.0.0.0/0 | 허용 ← 응답용 임시포트(중요)

⚠️ Stateless 주의 — 인바운드만 막아선 끝이 아닙니다. 아웃바운드 규칙도 따로 편집하고, 특정 포트만 열 거면 응답이 나갈 임시포트(1024–65535)를 아웃바운드에 허용해야 통신이 됩니다. (인바운드만 좁히면 "요청은 가는데 응답이 끊기는" 사고)

버튼: 새 규칙 추가 / 규칙 번호별 정렬 / 변경 사항 미리 보기 / 변경 사항 저장.

실습 단계라면 100 모든 트래픽 허용으로 저장해도 무방합니다(통신 확보 우선). 보안을 좁힐 땐 위 패턴으로.

아웃바운드 규칙

인바운드와 동일한 방식으로 값을 입력하고 저장합니다. (Stateless이므로 인바운드만큼 아웃바운드도 중요!)

---

마치며

NACL은 서브넷 경계의 Stateless 방화벽, SG는 인스턴스의 Stateful 방화벽. 둘이 짝을 이뤄 2중 방어를 만듭니다. 기억할 한 줄:

"NACL은 서브넷 입구, SG는 현관문. 그리고 NACL은 응답도 따로 열어줘야 한다."