보안 그룹 vs 네트워크 ACL: AWS VPC 방화벽 선택 가이드

Amazon Web Services(AWS)에서 안전한 Virtual Private Cloud(VPC) 환경을 설계할 때, 관리자는 네트워크 트래픽을 관리하기 위해 여러 제어 계층에 의존합니다. 네트워크 수준에서 트래픽을 필터링하는 두 가지 기본 구성 요소는 보안 그룹(SG)과 네트워크 액세스 제어 목록(NACL)입니다.

콘솔에서는 비슷해 보이지만, 실패 방식은 매우 다릅니다. 보안 그룹은 일반적으로 애플리케이션 의도를 설명하는 곳입니다. 네트워크 ACL은 광범위한 서브넷 경계나 긴급 거부를 적용하는 곳입니다.

AWS VPC에서 방화벽의 역할

AWS는 VPC 내에서 두 가지 주요 수준의 네트워크 보안을 제공합니다.

인스턴스 수준 (보안 그룹): 특정 EC2 인스턴스 또는 리소스(RDS 데이터베이스, Elastic Load Balancer 등)에 대한 방화벽 역할을 합니다. 네트워크 인터페이스로의 트래픽을 제어합니다.
서브넷 수준 (네트워크 ACL): 전체 서브넷에 대한 상태 비저장 방화벽 역할을 하며, 서브넷 경계를 출입하는 트래픽 흐름을 제어합니다.

보안 그룹(SG) 심층 분석

보안 그룹은 개별 리소스에 대한 기본적이고 세분화된 방화벽 역할을 합니다. 상태 저장이며 프로토콜, 포트, 소스 또는 대상별로 필터링합니다.

보안 그룹의 주요 특징

기능	설명	사용 시 영향
범위	인스턴스의 Elastic Network Interface(ENI)에 직접 적용됩니다.	인스턴스 로 및 로부터의 트래픽 흐름을 제어합니다.
상태 저장	상태 저장. 인바운드 요청이 명시적으로 허용되면, 해당하는 아웃바운드 응답 트래픽은 아웃바운드 규칙과 관계없이 자동으로 허용됩니다.	구성을 단순화합니다. 시작 트래픽 방향만 정의하면 됩니다.
규칙 유형	허용만 가능. 명시적 거부 규칙은 불가능합니다. 명시적 `ALLOW` 규칙과 일치하지 않는 트래픽은 암시적으로 거부됩니다.	허용되는 항목을 정의하는 데 중점을 둡니다.
평가	모든 규칙은 결정이 내려지기 전에 평가됩니다. 번호가 매겨져 있지 않으며, 모든 `ALLOW` 규칙이 실패할 때까지 암시적 `DENY`가 처리되지 않습니다.	순서는 중요하지 않습니다. 모든 규칙은 동등하게 취급됩니다.

보안 그룹 구성 예시

EC2 인스턴스에 대한 SSH 액세스(포트 22)를 허용하려면 인바운드 규칙만 필요합니다. SSH 응답에 대한 아웃바운드 규칙은 SG의 상태 저장 특성에 의해 자동으로 처리됩니다.

유형	프로토콜	포트 범위	소스	설명
인바운드	TCP	22	0.0.0.0/0 (또는 특정 관리자 IP)	SSH 액세스 허용
아웃바운드	전체	전체	0.0.0.0/0	(기본값: 모든 트래픽 허용, 필요 시 제한 가능)

# 상태 저장 흐름의 개념적 표현
사용자 (소스 IP) --> [인바운드 SG 규칙: ALLOW 22] --> EC2 인스턴스
EC2 인스턴스 (응답) --> [암시적 상태 추적] --> 사용자 (응답 수신)

모범 사례 팁: 항상 최소 권한 원칙을 사용하여 보안 그룹 규칙을 정의하세요. 가능하면 0.0.0.0/0을 허용하는 대신 소스 IP 범위를 제한하세요.

네트워크 ACL(NACL) 심층 분석

네트워크 ACL은 서브넷 경계에서 상태 비저장 필터 역할을 하는 두 번째 방어 계층을 제공합니다. 네트워크 분할 및 광범위한 거부 정책에 강력합니다.

네트워크 ACL의 주요 특징

기능	설명	사용 시 영향
범위	전체 VPC 서브넷에 적용됩니다. 서브넷은 한 번에 하나의 NACL과만 연결될 수 있습니다.	서브넷을 출입하는 모든 트래픽을 제어하여 서브넷 내의 모든 인스턴스에 영향을 미칩니다.
상태 저장	상태 비저장. 인바운드 요청과 해당 아웃바운드 응답을 모두 명시적으로 허용해야 합니다.	반환 트래픽(임시 포트)에 대한 신중한 구성이 필요합니다.
규칙 유형	허용 및 거부. 트래픽을 허용하거나 차단하는 규칙을 명시적으로 정의할 수 있습니다.	알려진 악성 IP 차단 또는 특정 프로토콜을 네트워크 전체에서 거부하는 데 탁월합니다.
평가	규칙은 번호(1~32766)가 매겨져 있으며 가장 낮은 번호부터 순차적으로 평가됩니다. 일치하는 첫 번째 규칙이 즉시 적용됩니다.	규칙 순서가 중요합니다. 암시적 거부 규칙(마지막으로 처리되는 규칙)은 명시적으로 허용되지 않은 모든 것을 거부합니다.

상태 비저장 트래픽 처리 (임시 포트)

NACL은 상태 비저장이므로, 서버에 연결하는 클라이언트가 사용하는 임시 포트를 고려해야 합니다. 클라이언트가 연결을 시작하면 대상 포트(예: HTTP의 경우 80)와 높은 번호의 소스 포트(임시 포트 범위, 일반적으로 1024-65535)를 사용합니다.

서브넷으로 웹 트래픽(HTTP)을 허용하려면 두 가지 규칙이 필요합니다.

인바운드 규칙: 대상 포트(예: 80)의 트래픽을 허용합니다.
아웃바운드 규칙: 임시 소스 포트를 사용하여 클라이언트로의 반환 트래픽을 허용합니다.

규칙 번호	유형	프로토콜	포트 범위	소스/대상	규칙 작업
100	인바운드	TCP	80	0.0.0.0/0	ALLOW (웹 트래픽 인)
110	아웃바운드	TCP	1024-65535	0.0.0.0/0	ALLOW (웹 응답 아웃 - 임시 포트)
*	암시적 거부	전체	전체	전체	DENY (마지막에 처리됨)

경고: NACL에서 임시 포트에 대한 해당 아웃바운드 규칙을 누락하면, 트래픽이 인스턴스에 도달하지만(인바운드 규칙으로 인해) 응답이 서브넷 경계에서 드롭되어 연결 시간 초과가 발생합니다.

비교 요약: SG vs. NACL

다음 표는 두 방화벽 유형 간의 중요한 차이점을 요약합니다.

기능	보안 그룹 (SG)	네트워크 ACL (NACL)
적용 범위	인스턴스/ENI 수준	서브넷 수준
상태	상태 저장	상태 비저장
규칙 유형	허용만 가능	허용 및 거부
규칙 평가	모든 규칙 평가, 특정 순서 없음.	규칙 번호별 순차 평가(낮은 번호 우선); 첫 번째 일치가 적용됨.
기본 동작	모든 인바운드 거부, 모든 아웃바운드 허용(제한하지 않은 경우).	기본 NACL은 모든 인바운드/아웃바운드 허용. 사용자 지정 NACL은 모든 인바운드/아웃바운드 거부.
트래픽 영향	연결된 리소스 로 또는 로부터의 트래픽에만 규칙 적용.	서브넷 경계를 통과하는 트래픽을 필터링하여 서브넷의 모든 리소스에 영향.

올바른 방화벽 선택: 시나리오 및 모범 사례

성공적인 VPC 보안은 SG와 NACL을 계층적 접근 방식(심층 방어)으로 함께 사용하는 데 달려 있습니다.

보안 그룹을 우선시해야 하는 경우

보안 그룹은 상태 저장 특성과 다른 SG를 참조할 수 있는 기능으로 인해 네트워크 액세스 필터링을 위한 기본 도구여야 하며, 애플리케이션 구성을 단순화합니다.

세분화된 애플리케이션 제어: SG를 사용하여 특정 애플리케이션에 필요한 포트와 프로토콜을 정확히 정의합니다(예: 웹 서버 SG에서 데이터베이스 SG로의 포트 3306 트래픽만 허용).
내부 통신: 동일한 서브넷 내 또는 서브넷 간 인스턴스 간 트래픽에 대한 보안을 관리합니다(예: 로드 밸런서가 대상 그룹과 통신할 수 있도록 보장).
관리 용이성: 상태 저장이므로 SG는 더 적은 규칙이 필요하고 NACL로 임시 포트를 관리하는 것보다 오류 가능성이 적습니다.

네트워크 ACL을 구현해야 하는 경우

NACL은 광범위한 네트워크 경계 및 분할 정책을 설정하는 데 가장 적합합니다.

광범위한 거부 정책: 명시적 DENY 규칙(규칙 번호 100)을 사용하여 트래픽이 인스턴스에 도달하기 전에 특정 악성 IP 주소 또는 IP 범위를 전체 서브넷에서 차단합니다.
서브넷 분할: 아키텍처 계층 간에 엄격한 경계를 적용합니다(예: 데이터베이스 서브넷 NACL이 SG 구성과 관계없이 인터넷의 모든 인바운드 트래픽을 명시적으로 거부하도록 보장).
규정 준수 요구 사항: 특정 규정 준수 표준은 서브넷 수준 필터링을 요구할 수 있으므로 NACL이 필수적입니다.
상태 비저장 프로토콜 필터링: SG가 자체적으로 효과적으로 관리할 수 없는 상태 비저장 프로토콜을 필터링해야 하는 경우 NACL이 필요합니다(표준 TCP/UDP 트래픽의 경우 드물지만).

장애를 유발하는 실수

가장 흔한 NACL 장애는 반환 트래픽을 잊어버리는 것입니다. 누군가 공용 서브넷에 대한 인바운드 TCP 443을 허용하고 아웃바운드 규칙을 너무 빡빡하게 설정합니다. 로드 밸런서 또는 인스턴스는 SYN을 수신하지만 응답이 나가는 도중에 드롭됩니다. 클라이언트 측에서는 시간 초과처럼 보이고, 인스턴스 측에서는 서비스가 완전히 정상으로 보일 수 있습니다.

또 다른 실수는 애플리케이션별 정책에 NACL을 사용하는 것입니다. 서브넷에 웹, 작업자, 관리자 인스턴스가 포함된 경우 하나의 NACL이 모두에 적용됩니다. 한 워크로드에 추가된 규칙이 동일한 서브넷의 다른 워크로드를 예기치 않게 노출시키거나 중단시킬 수 있습니다. 다른 네트워크 동작이 필요한 경우 다른 보안 그룹을 사용하고, 실제 경계를 적용해야 하는 경우에만 별도의 서브넷을 고려하세요.

규칙 번호 지정에도 주의가 필요합니다. 1, 2, 3 대신 100, 110, 120과 같은 간격을 두어 나중에 긴급 규칙을 삽입할 수 있도록 하세요. 첫 번째 일치가 적용된다는 점을 기억하세요. 규칙 90의 거부는 콘솔을 빠르게 읽는 사람에게 더 구체적으로 보일지라도 규칙 100의 허용보다 우선합니다.

보안 그룹의 경우 일반적인 실수는 광범위한 소스 범위입니다. 공용 로드 밸런서의 443 포트에 0.0.0.0/0은 정상일 수 있습니다. SSH, RDP, Redis, PostgreSQL 또는 내부 관리자 API에 동일한 소스를 사용하는 것은 일반적으로 문제입니다. VPC 내에서는 보안 그룹 참조를 선호하고 운영자 액세스에는 좁은 CIDR을 사용하세요.

기존 VPC를 상속받은 경우 규칙을 내보내고 의도별로 그룹화하세요: 공용 진입점, 앱 간 트래픽, 데이터 저장소, 관리, 긴급 거부. 명확한 소유자나 이유가 없는 규칙은 일반적으로 오래된 노출이 있는 곳입니다.

심층 방어 접근 방식

일반적으로 잘 설계된 VPC에서 트래픽 흐름은 NACL과 보안 그룹을 모두 통과해야 합니다. 두 보안 제어 중 하나라도 트래픽을 거부하면 패킷이 드롭됩니다.

인바운드 흐름: 트래픽이 서브넷에 진입 -> NACL 규칙 확인 -> 트래픽이 인스턴스 ENI에 도달 -> 보안 그룹 규칙 확인 -> 트래픽이 애플리케이션에 도달.
아웃바운드 흐름: 애플리케이션이 응답 생성 -> 보안 그룹 (상태 저장 확인 통과) -> 트래픽이 인스턴스 ENI를 떠남 -> NACL 규칙 확인 -> 트래픽이 서브넷을 떠남.

NACL을 거친 분할 및 거부 규칙에 활용하고, SG를 정밀한 상태 저장 애플리케이션 수준 권한에 활용함으로써 구성 단순성을 유지하면서 보안 효율성을 극대화합니다.

실용적인 설계 패턴

대부분의 애플리케이션 VPC의 경우 보안 그룹부터 시작하세요. 로드 밸런서에 공용 보안 그룹을, 애플리케이션 인스턴스에는 로드 밸런서 보안 그룹의 트래픽만 수락하는 보안 그룹을, 데이터베이스에는 데이터베이스 포트에서 애플리케이션 보안 그룹의 트래픽만 수락하는 보안 그룹을 할당하세요. 이 모델은 애플리케이션 종속성 그래프를 따르며 IP 변경에도 견딥니다.

NACL은 더 드물게 사용하세요. 좋은 NACL 사용 사례는 알려진 악성 CIDR에 대한 서브넷 수준 거부, 데이터베이스 서브넷 주변의 하드 경계, 또는 서브넷의 ENI에 도달하기 전에 적용되어야 하는 규정 준수 규칙입니다. 팀이 모든 애플리케이션 규칙을 NACL에 미러링하려고 하면 문제가 발생합니다. 상태 비저장 반환 포트 규칙은 실수하기 쉽고, 낮은 번호의 거부 하나가 전체 서브넷을 중단시킬 수 있습니다.

연결 시간이 초과되면 패킷 경로의 두 계층을 모두 확인하세요. 공용 서브넷의 EC2 인스턴스로 향하는 인바운드 인터넷 트래픽의 경우 요청은 인바운드 NACL 규칙, 라우팅 테이블, 인바운드 보안 그룹 규칙을 통과해야 합니다. 응답은 상태 저장 보안 그룹 추적과 아웃바운드 NACL 규칙을 통과해야 합니다. SG가 올바른 것 같지만 클라이언트가 여전히 멈춘다면 NACL 임시 포트 규칙이 누락된 부분인 경우가 많습니다.

가장 깔끔한 사고 모델은 다음과 같습니다. 보안 그룹은 어떤 리소스가 다른 리소스와 통신할 수 있는지 말하고, NACL은 서브넷이 절대 허용하지 않는 것을 말합니다. 이러한 작업을 분리하면 설계를 감사하기가 더 쉬워집니다.