codingstairs
노트에듀라이프연락
⌕검색⌘K
koen

Navigation

  • Intro
  • Blog
  • Life

연락하기

로그인 없이도 보낼 수 있어요. 답변이 필요하면 이메일을 함께 적어 주세요.

  • 익명 폼으로 의견 남기기 →
  • ✉ warragon112@gmail.com
  • 카카오톡 오픈채팅 ↗

© 2026 codingstairs

  • 노트
  • 에듀
  • 검색
  • 라이프
  • 연락
  • 약관
  • RSS
  • GitHub
노트›cloud

보안 그룹과 네트워크 ACL

2026-04-28 게시· 2026-05-18 갱신·0회 조회

보안 그룹과 네트워크 ACL — 두 층 방화벽

AWS 의 네트워크 방화벽은 두 층입니다. 인스턴스에 붙는 보안 그룹 (Security Group) 과 서브넷에 붙는 네트워크 ACL (NACL). 이름은 비슷하지만 동작 모델이 꽤 다릅니다.

1. 두 층에 대한 이야기

항목 Security Group Network ACL
적용 단위 ENI (인스턴스) 서브넷
상태성 Stateful Stateless
기본 정책 inbound 거부 / outbound 허용 기본 NACL 은 모두 허용
규칙 Allow 만 (거부 없음) Allow + Deny 양쪽
평가 순서 모든 규칙 OR 번호 낮은 순 평가, 매치 시 종료
응답 트래픽 자동 허용 명시 규칙 필요

2. Security Group — Stateful

stateful 의 의미는 "허용된 inbound 의 응답은 outbound 규칙과 무관하게 자동 허용" 입니다. SG 의 outbound 가 모두 막혀 있어도 클라이언트로의 응답 패킷은 나갑니다.

Inbound:
  - HTTP, Source: 0.0.0.0/0
  - HTTPS, Source: 0.0.0.0/0
  - SSH, Source: 203.0.113.5/32      # 내 IP
Outbound:
  - All traffic, 0.0.0.0/0            # 기본값

소스·대상으로 IP 대역뿐 아니라 다른 SG 의 ID 를 쓸 수 있습니다. "ALB 의 SG 에서 들어온 트래픽만 허용" 같은 규칙이 가능 — 인스턴스가 늘어도 IP 를 매번 갱신할 필요가 없습니다.

3. Network ACL — Stateless

서브넷 단위. 규칙이 번호 순서로 평가되며 매치되는 즉시 종료합니다.

Inbound:
  100  ALLOW  HTTP   0.0.0.0/0
  110  ALLOW  HTTPS  0.0.0.0/0
  120  ALLOW  TCP 1024-65535          # 응답 ephemeral 포트
  *    DENY   ALL

Outbound:
  100  ALLOW  TCP 1024-65535          # 응답 ephemeral
  110  ALLOW  HTTP/HTTPS
  *    DENY   ALL

stateless 라 응답을 위한 ephemeral port 범위 (보통 1024–65535) 를 명시해야 합니다. NACL 을 너무 좁게 잡으면 정상 트래픽이 막힙니다.

4. 두 층의 평가 순서

들어오는 패킷은 NACL → SG → 인스턴스 순으로 평가됩니다. 둘 중 하나라도 막으면 통과 못 합니다. 운영에서 트러블슈팅할 때 두 층 모두 확인합니다.

5. 일반적 SG 규칙 패턴

역할 Inbound
ALB (공용) 80, 443 ← 0.0.0.0/0 (::/0 IPv6)
웹/앱 EC2 8080 ← ALB 의 SG
RDS 5432 ← 앱 SG
Redis 6379 ← 앱 SG
Bastion 22 ← 회사·자택 IP/32

DB · Redis 는 외부에 직접 노출되지 않습니다. 앱 SG 에서만 들어올 수 있게 합니다.

6. 0.0.0.0/0 의 위험

0.0.0.0/0 은 인터넷 전체를 의미합니다. 자주 사고 나는 자리:

  • SSH 22 를 0.0.0.0/0 — 자동 스캐너의 무차별 시도 대상.
  • DB 포트 5432 / 3306 을 0.0.0.0/0 — 인터넷 전체에 DB 가 열림.
  • 관리 UI (예: Kibana 5601) 를 0.0.0.0/0.

베스트 프랙티스:

  • 80 / 443 만 0.0.0.0/0.
  • SSH 는 회사·자택 IP/32, 또는 SSM Session Manager (포트 노출 없음).
  • DB 는 앱 SG 만.

7. NACL 의 자리

대부분의 운영에서 SG 만으로 충분하고 NACL 은 기본값 (모두 허용) 으로 둡니다. NACL 이 빛나는 자리:

  • 특정 IP 대역을 단순 차단 (SG 는 deny 가 없으므로 NACL 로).
  • 서브넷 단위 광역 정책.
  • 컴플라이언스 요건의 명시적 거부 규칙.

NACL 을 잘못 좁히면 서브넷 전체가 끊깁니다. 운영에서는 신중하게.

8. Bastion 또는 SSM

SSH 22 를 외부에 열지 않는 흐름:

  • Bastion (jump host) — 한 대만 22 노출, 다른 인스턴스는 bastion SG 만 허용.
  • AWS SSM Session Manager — 22 포트 자체를 열지 않고 IAM 인증으로 셸 접근.

후자는 키 관리 부담이 줄고 감사 로그가 IAM · CloudTrail 에 남는다는 점이 강점입니다.

9. 다른 클라우드의 대응

  • GCP — VPC Firewall Rules. SG 와 NACL 의 중간 — VPC 단위, stateful, 우선순위 기반.
  • Azure — Network Security Group (NSG). 우선순위 기반 평가.

같은 어휘라도 모델이 다른 점은 이전 시 점검 항목입니다.

10. 자주 걸리는 자리

SG 변경 후 기존 연결 — 일부 변경은 즉시 반영되지만 기존 연결은 끊길 수 있습니다. 점검 시 신규 연결로 검증.

NACL 의 ephemeral port — 응답이 막히는 사고가 잦습니다. NACL 을 좁힐 때 outbound 응답 포트도 함께.

여러 SG 부착 시 합집합 — 한 ENI 에 여러 SG 가 붙으면 규칙은 모두의 합집합 (하나라도 허용하면 허용).

IPv6 누락 — 0.0.0.0/0 만 두면 IPv6 트래픽이 빠집니다. 필요 시 ::/0 도 명시.

MyIP 가 변하는 IP — 가정 인터넷 IP 는 종종 바뀝니다. 동적 갱신 자동화 또는 VPN · SSM 으로 우회.

하고픈 말

SG 의 stateful 모델 + SG ID 참조는 한 번 익히면 NACL 보다 훨씬 쓰기 쉽습니다. 22 / 5432 / 6379 같은 관리 포트가 실수로 0.0.0.0/0 에 열리는 사고가 가장 흔하니 처음부터 SSM Session Manager 쪽으로 정책을 잡는 편이 안전합니다.

Next

  • ec2
  • deploying-options

Security Groups · Network ACL · VPC 보안 모범사례 · SSM Session Manager · GCP Firewall · Azure NSG 를 참고합니다.

cloud 카테고리의 다른 글

카테고리 전체 보기 →
  • title 템플릿 단일 소스 — 자식 페이지가 박지 않게 한다
  • GitHub Pages — 저장소를 정적 사이트로
  • Replit — 브라우저 기반 개발·배포 통합 플랫폼
  • HTTP API Mocking — WireMock · MockServer · Prism · MSW
  • Firebase Local Emulator Suite — Firebase 한 묶음을 노트북에
  • Supabase Self-Hosted — Postgres 한 통에 BaaS 를 담는 방법