[13] 보안 케이스 테스트 : NAT GATEWAY와 NACL 설정

NAT Gateway 뒤에서 더 빡세지는 이유 ALB는 되는데 EC2 직접 접속은 안 되는 케이스

 

NAT Gateway 뒤에 있다(= 프라이빗 서브넷에 있다) 는 말은,

그 EC2는 기본적으로 인터넷에서 “들어오는(inbound) 길” 자체가 막혀있다는 뜻이라서 “더 빡세” 보이는 거예요.

1) NAT Gateway 뒤에서 더 빡세지는 이유

• NAT GW는 “나가는(outbound) 용도” 전용이에요.
  프라이빗 서브넷의 EC2가 외부로 업데이트/패키지 다운로드/외부 API 호출 같은 걸 할 때,
  출발지 IP를 NAT의 EIP로 바꿔서 밖으로 내보내 주는 역할.
• 반대로 외부에서 NAT EIP로 들어오는 트래픽을 EC2로 포워딩해주지 않아요.
  (포트포워딩/인바운드 라우팅 기능 없음)

즉, NAT 뒤 = “외부에서 직접 접속 불가(기본값)”가 되는 구조라서 보안적으로 강해 보이고, 실제로도 공격면이 줄어요.

---

2) “ALB는 되는데 EC2 직접 접속은 안 됨” 대표 케이스

가장 흔한 그림:

✅ 되는 쪽 (ALB)

• ALB는 퍼블릭 서브넷 + IGW 라우팅 + Public IP(EIP는 아니어도 됨) 구조로 인터넷에 공개됨
• ALB가 받은 트래픽을 VPC 내부에서 프라이빗 서브넷의 EC2로 전달
• EC2 보안그룹 인바운드는 보통 이렇게 열어둠:
  • inbound: 80/443 from (ALB의 SG)
    → 그래서 ALB 경유는 통과

❌ 안 되는 쪽 (EC2 직접)

프라이빗 서브넷 EC2는 보통 아래 중 하나(혹은 복합)라서 직접 접속이 막혀요.

• EC2에 Public IPv4가 없음 (auto-assign off)
• 서브넷 라우트테이블에 0.0.0.0/0 → IGW가 없음 (대신 → NAT GW만 있음)
• EC2 SG 인바운드가 내 IP가 아니라 ALB SG만 허용하고 있음
  (예: SSH 22가 “내 IP”가 아니라 “ALB SG”로만 열려있음 → 직접 SSH는 당연히 막힘)
• NACL도 “내 IP → 22”가 없거나, 응답용 ephemeral 범위가 안 열려있음(드물지만 있음)

---

3) 딱 빠르게 판별하는 체크포인트

EC2 “직접 접속”을 원하면 최소 조건이 이거예요:

1. EC2가 퍼블릭 서브넷에 있어야 함
2. 퍼블릭 서브넷 RT에 0.0.0.0/0 → IGW
3. EC2에 Public IPv4 할당(또는 EIP)
4. SG 인바운드에 내 공인 IP/32로 22(SSH) 또는 80/443 허용

여기서 1)~2)가 아니라면, NAT 뒤(프라이빗)에서는 구조적으로 직접 인바운드가 안 됩니다.

---

4) “프라이빗은 유지하면서 접속” 정석 옵션

• Bastion(점프 서버) + SSH (퍼블릭에 작은 인스턴스 1대)
• SSM Session Manager (요즘 제일 깔끔: 인바운드 포트 0개로 접속 가능)
• Site-to-Site VPN / Client VPN / Direct Connect
• ALB 뒤로만 서비스하고, 관리 접속은 위 방식으로 분리

---

원하면, 지금 네 구성 기준으로 “왜 ALB는 되고 EC2는 안 되는지”를 RT/SG/NACL 한 줄씩 체크 순서로 바로 점검 플로우로 정리해줄게. (콘솔/CLI 둘 다 가능)