[AWS Network] 04. Security Group과 Network ACL

 

목차 : AWS Network를 어떻게 공부할까? - VPC부터 Transit Gateway, PrivateLink까지

ㅁ 들어가며

AWS VPC에서 Security Group과 Network ACL은 모두 트래픽을 통제한다.

둘을 단순히 방화벽이라고만 기억하면 응답 패킷이 차단되는 이유나 특정 규칙이 적용되지 않는 이유를 설명하기 어렵다.

핵심 질문은 하나다.

트래픽을 어느 경계에서, 어떤 방식으로 허용할 것인가?

 

ㅁ 서로 다른 두 경계

Client
  ↓
Subnet 경계 ── Network ACL
  ↓
ENI/Resource ─ Security Group

Security Group은 ENI와 같은 연결된 리소스를 보호한다.

NACL은 연결된 ㄱ의 경계를 드나드는 트래픽을 통제한다.

 

ㅁ Security Group은 Stateful이다

Security Group에는 Allow 규칙만 있다.

여러 Security Group을 하나의 ENI에 연결하면 모든 허용 규칙을 합산한다.

Stateful이라는 말은 허용된 연결의 상태를 기억한다는 뜻이다.

Client:51000 → EC2:443  요청 허용
EC2:443 → Client:51000  응답 자동 허용

응답 패킷의 목적지 Port가 Client의 Ephemeral Port라도 별도 응답 규칙을 만들 필요가 없다.

같은 Security Group을 쓰는 EC2끼리 자동 통신하는 것은 아니다.

같은 규칙 집합을 적용받을 뿐이며, 서로 통신하려면 필요한 Inbound 규칙이 있어야 한다.

 

ㅁ NACL은 Stateless이다

NACL은 Allow와 Deny를 모두 지원한다.

낮은 Rule Number부터 검사하고 첫 번째로 일치한 규칙을 적용한 뒤 멈춘다.

Rule 50:  특정 공격자 /32  DENY
Rule 100: 모든 IPv4       ALLOW

구체적인 규칙이라고 자동 우선하지 않는다.

Route Table의 Longest Prefix Match와 달리 Rule Number가 우선순위를 결정한다.

Stateless이므로 요청과 응답을 각각 허용해야 한다.

Inbound  → EC2의 Service Port 허용
Outbound → Client의 Ephemeral Port 범위 허용

 

ㅁ Security Group 참조

Security Group 규칙에서는 IP CIDR 대신

다른 Security Group을 Source로 지정할 수 있다.

SG-App Inbound
Source: SG-Web
TCP 8080

이는 SG-Web이 연결된 Source ENI에서 SG-App이 연결된 리소스의 TCP 8080으로 오는 트래픽을 허용한다는 뜻이다.

SG-Web의 규칙을 복사하거나 네트워크 경로를 만드는 기능은 아니다.

 

ㅁ 어느 것을 먼저 사용해야 할까?

AWS는 Security Group을 주된 리소스 접근 통제로 사용하고 NACL을 Subnet 수준의 추가 방어선으로 사용할 것을 안내한다.

Security Group → 리소스별 세밀한 Allow 정책
Network ACL    → Subnet 전체의 Allow/Deny 방어선

통신이 성립하려면 두 보안 요소뿐 아니라 Route와 Application도 정상이어야 한다.

Route
+ NACL
+ Security Group
+ Application
= 통신

 

ㅁ 비교 정리

구분	Security Group	Network ACL
적용 위치	ENI/리소스	Subnet 경계
규칙	Allow	Allow, Deny
평가	허용 규칙 합산	낮은 번호부터 첫 일치
상태	Stateful	Stateless
응답	자동 허용	별도 허용 필요

SG와 NACL을 구분하는 가장 좋은 방법은 설정 화면을 외우는 것이 아니라

요청과 응답 패킷을 양방향으로 그려보는 것이다.

 

ㅁ 참고 자료

• Security Group과 NACL 비교
• Security Group
• Network ACL