네트워크 ACL과 보안 그룹 비교

AWS는 VPC 내에서 서로 다른 두 가지 방화벽 메커니즘을 제공합니다. 보안 그룹은 인스턴스 수준(기술적으로는 ENI 수준)에서 작동하며 상태를 추적합니다. Network Access Control Lists (NACL)은 서브넷 수준에서 작동하며 상태를 추적하지 않습니다. 두 기능은 서브넷과 연결된 인스턴스로 들어오거나 나가는 모든 트래픽에 대해 평가됩니다. 두 기능을 함께 사용하면 심층 방어를 구현할 수 있습니다. NACL은 서브넷 경계의 첫 번째 방어선으로, 보안 그룹은 인스턴스별 방화벽으로 사용합니다. SAA-C03 시험에서는 이 두 메커니즘을 자주 비교합니다.

Network ACL (NACL)은 서브넷 경계를 통과하는 모든 트래픽에 적용되는 번호가 지정된 규칙 목록입니다. NACL은 상태 비저장이므로 각 패킷을 독립적으로 평가합니다. 인바운드 TCP 포트 80을 허용했다면 응답이 서브넷 밖으로 나갈 수 있도록 아웃바운드 반환 트래픽(임시 포트 1024-65535)도 명시적으로 허용해야 합니다. 규칙은 숫자 순서(가장 낮은 번호부터)로 평가되며, 처음 일치하는 규칙이 적용되고 이후 규칙은 확인하지 않습니다. 각 VPC에는 모든 인바운드 및 아웃바운드 트래픽을 허용하는 기본 NACL이 함께 제공됩니다.

NACL 규칙은 규칙 번호의 오름차순(1~32766)으로 평가되며, 규칙이 일치하는 즉시 평가가 중단됩니다. 따라서 같은 트래픽에 대해 더 낮은 번호의 Allow 규칙이 있더라도 번호가 더 낮은 Deny 규칙에 의해 무시될 수 있습니다. AWS는 나중에 규칙을 삽입할 수 있도록 규칙 번호를 10 또는 100 단위로 지정할 것을 권장합니다. 모든 NACL의 마지막에는 명시적인 규칙과 일치하지 않는 모든 트래픽을 거부하는 기본 규칙(* DENY)이 있습니다. 이 포괄 규칙은 수정하거나 삭제할 수 없습니다.

NACL은 상태를 추적하지 않으므로 모든 연결의 양방향 트래픽을 고려해야 합니다. 인터넷의 클라이언트가 포트 443을 통해 EC2 인스턴스에 연결하면 인스턴스는 클라이언트의 임시 포트(일반적으로 Linux에서는 1024-65535, Windows에서는 49152-65535인 무작위 높은 포트)로 응답을 보냅니다. NACL의 아웃바운드 규칙에서 이 범위를 명시적으로 허용해야 합니다. 흔히 발생하는 NACL 구성 실수는 인바운드 포트 443에 대한 Allow 규칙은 만들면서 아웃바운드 임시 포트 허용을 잊는 것입니다. 그러면 연결은 설정되지만 응답이 조용히 삭제됩니다.

다시 정리하면, 보안 그룹은 인스턴스(또는 ENI)에 연결되고 명시적인 Allow 규칙만 허용하며 Deny 규칙은 없습니다. 또한 상태를 추적하므로 허용된 인바운드 트래픽에 대한 응답은 규칙이 없어도 아웃바운드로 자동 허용됩니다. 연결된 모든 규칙은 OR 논리를 사용하여 함께 평가됩니다. 다른 보안 그룹 ID를 소스 또는 대상으로 참조할 수 있으므로 IP 범위를 사용하는 것보다 관리하기 쉽습니다. 보안 그룹은 인스턴스 수준 액세스 제어의 기본 메커니즘이며, NACL은 서브넷 수준의 추가 계층을 제공합니다.

시험을 위한 핵심 비교입니다.

• 수준: NACL = 서브넷, SG = 인스턴스(ENI)
• 상태: NACL = 상태 비저장, SG = 상태 추적
• 규칙: NACL = Allow 및 Deny, SG = Allow만 허용(암시적 거부)
• 평가: NACL = 순서대로 평가(첫 일치 규칙 적용), SG = 모든 규칙 평가(Allow 중 하나라도 있으면 허용)
• 범위: NACL은 서브넷의 모든 인스턴스에 적용되고, SG는 연결된 인스턴스에만 적용됨
• 인바운드/아웃바운드: NACL은 양방향 모두에 명시적 규칙이 필요하고, SG는 상태를 추적하므로 응답에는 인바운드 규칙만 필요함

다음과 같은 경우 NACL을 사용합니다. 특정 IP 차단(보안 그룹은 거부할 수 없고 허용만 가능하지만, NACL은 명시적인 Deny 규칙을 추가하여 알려진 악성 IP나 스크레이퍼를 차단할 수 있음), 서브넷 전체에 적용되는 규칙(개별 보안 그룹을 수정하지 않고 서브넷의 모든 인스턴스에 동일한 규칙을 적용함), 추가 방어 계층(보안 그룹을 잘못 구성하여 실수로 액세스가 열리더라도 서브넷 경계의 NACL Deny 규칙으로 트래픽을 차단할 수 있음)입니다. 실제로 대부분의 팀은 주로 보안 그룹을 통해 액세스를 관리하고, NACL은 명시적인 IP 차단에만 사용합니다.

기본 NACL(모든 VPC와 함께 생성됨)은 모든 인바운드 및 아웃바운드 트래픽을 허용하며, 100 Allow All Inbound 및 100 Allow All Outbound 규칙을 포함합니다. 사용자 지정 NACL에 명시적으로 연결되지 않은 서브넷은 기본 NACL을 사용합니다. 사용자 지정 NACL을 생성하면 기본 Deny-All 규칙(규칙 *)만 있는 상태로 시작하므로, 명시적인 Allow 규칙을 추가할 때까지 모든 트래픽이 차단됩니다. 따라서 새 사용자 지정 NACL을 서브넷에 연결하면 모든 트래픽이 즉시 차단됩니다. 프로덕션 서브넷에 연결하기 전에 Allow 규칙을 추가해야 합니다.

EC2 인스턴스로 들어오는 트래픽의 경우, 트래픽은 먼저 서브넷 경계의 NACL을 통과하며 규칙 순서에 따라 평가됩니다. NACL이 트래픽을 허용하면 트래픽은 인스턴스의 보안 그룹에 도달하고, 보안 그룹도 해당 트래픽을 허용해야 합니다. 트래픽이 인스턴스에 도달하려면 두 기능 모두 허용해야 합니다. 아웃바운드 트래픽의 경우 보안 그룹이 먼저 평가됩니다(상태를 추적하므로 허용된 인바운드 트래픽에 대한 응답이면 허용). 그다음 NACL이 평가되며, 상태를 추적하지 않으므로 명시적인 아웃바운드 Allow가 필요합니다. 이 순서를 이해하면 상태를 추적하는 보안 그룹을 사용하더라도 상태 비저장 NACL에 반환 트래픽 규칙이 필요한 이유를 알 수 있습니다.

NACL은 상태를 추적하지 않기 때문에 원인을 파악하기 어려운 네트워크 문제의 일반적인 원인이 됩니다. 증상은 다음과 같습니다. 연결은 설정되지만 데이터 흐름이 중단됨(아웃바운드 임시 포트 규칙 누락), 한 방향으로만 트래픽이 흐름(인바운드 또는 아웃바운드 규칙 누락), 특정 IP가 연결할 수 없음(더 낮은 번호의 Deny 규칙이 Allow 규칙보다 먼저 일치함). 문제를 해결하려면 VPC Flow Logs를 사용하여 NACL 수준에서 패킷이 ACCEPT인지 REJECT인지 확인합니다. 플로 로그에는 거부된 패킷과 해당 소스 및 대상이 표시되므로 누락된 규칙을 정확히 찾는 데 도움이 됩니다.

다중 계층 VPC 보안에 권장되는 패턴은 다음과 같습니다. 퍼블릭 서브넷의 네트워크 ACL은 인터넷에서 들어오는 트래픽 중 80번, 443번 및 필요한 임시 포트만 허용하고 나머지는 모두 거부합니다. ALB의 퍼블릭 서브넷 보안 그룹은 0.0.0.0/0에서 들어오는 80번 및 443번 포트만 허용합니다. 프라이빗 애플리케이션 보안 그룹은 ALB 보안 그룹 ID에서 들어오는 트래픽만 허용합니다. 프라이빗 데이터 보안 그룹은 애플리케이션 보안 그룹 ID에서 들어오는 트래픽만 허용합니다. 이러한 심층 방어를 적용하면 한 계층이 잘못 구성되더라도 다른 계층이 보호 기능을 제공할 수 있습니다. 이를 모든 계층에서의 최소 접근 권한 원칙이라고 합니다.

이 단원에서 다룬 AWS 솔루션스 아키텍트(SAA-C03) 개념에 대한 이해도를 확인해 보세요.

이 단원에서는 다음을 배웠습니다. 네트워크 ACL은 서브넷 수준에서 동작하는 비상태 방화벽이며, 번호 순서대로 평가되는 Allow 및 Deny 규칙을 모두 지원합니다. 보안 그룹은 인스턴스 수준에서 동작하는 상태 저장 방화벽이며 Allow 규칙만 사용하고 모든 규칙을 함께 평가합니다. 또한 명시적인 IP 차단과 서브넷 전체에 적용되는 규칙에는 네트워크 ACL을 사용하고, 세밀한 인스턴스 접근 제어에는 보안 그룹을 사용합니다. 이것으로 VPC 기초 모듈을 마칩니다. 다음에는 AWS의 RDS와 관계형 데이터베이스를 자세히 살펴보겠습니다.