보안 그룹과 네트워크 ACL
더 많은 작업
- Security Groups and Network ACLs; 보안 그룹; 네트워크 ACL; NACL
- 아마존 VPC에서 트래픽을 걸러내는 두 가지 방화벽. 보안 그룹은 리소스 단위의 상태 저장 방화벽이고, 네트워크 ACL은 서브넷 단위의 상태 비저장 방화벽이다
아마존 VPC에서 네트워크 접근을 통제하는 기본 수단은 보안 그룹(security group)과 네트워크 ACL(network access control list)이다. 둘 다 별도 요금이 없는 가상 방화벽이지만 적용 위치, 규칙 종류, 응답 트래픽 처리 방식이 다르다. AWS 문서는 보안 그룹을 주된 통제 수단으로 쓰고, 네트워크 ACL은 특정 트래픽을 거부하거나 서브넷 전체에 거친 울타리를 치는 보조 방어 계층으로 쓰라고 권한다.
트래픽이 인터넷 게이트웨이를 통해 들어오면 라우팅 테이블에 따라 서브넷으로 전달되고, 먼저 서브넷의 네트워크 ACL을, 그다음 인스턴스의 보안 그룹을 통과해야 한다. 나갈 때는 반대 순서이다.
| 항목 | 보안 그룹 | 네트워크 ACL |
|---|---|---|
| 적용 수준 | 인스턴스 수준(네트워크 인터페이스에 연결) | 서브넷 수준 |
| 적용 범위 | 해당 보안 그룹과 연결된 리소스 | 연결된 서브넷 안의 모든 리소스 |
| 규칙 종류 | 허용 규칙만 있음 | 허용과 거부 규칙 모두 가능 |
| 규칙 평가 | 모든 규칙을 종합해 허용 여부 결정 | 번호가 낮은 규칙부터 차례로 평가, 처음 일치한 규칙만 적용 |
| 응답 트래픽 | 자동 허용(상태 저장) | 별도 규칙으로 명시해야 함(상태 비저장) |
| 원천·대상 지정 | CIDR, 접두사 목록, 다른 보안 그룹 | CIDR만 |
| 기본 상태 | 새 보안 그룹은 인바운드 없음, 아웃바운드 전체 허용 | 기본 ACL은 전체 허용, 새로 만든 사용자 지정 ACL은 전체 거부 |
| 연결 개수 | 리소스 하나에 여러 개 연결 가능 | 서브넷 하나에 한 번에 하나만 연결 |
보안 그룹은 EC2 인스턴스, RDS DB 인스턴스, 로드 밸런서, VPC 엔드포인트 같은 리소스의 네트워크 인터페이스에 붙는 가상 방화벽이다.
- 허용 규칙만 만들 수 있다. 특정 IP를 콕 집어 차단하는 거부 규칙은 보안 그룹으로 만들 수 없다.
- 상태 저장이다. 인바운드로 허용된 요청의 응답은 아웃바운드 규칙과 상관없이 나가고, 인스턴스가 보낸 요청의 응답도 인바운드 규칙과 상관없이 들어온다.
- 새로 만든 보안 그룹은 인바운드 규칙이 없어 들어오는 트래픽을 모두 막고, 아웃바운드는 전체 허용 규칙이 하나 들어 있다.
- 리소스에 여러 보안 그룹을 연결하면 규칙이 합쳐져 하나의 규칙 집합처럼 동작한다.
- 규칙을 바꾸면 그 보안 그룹과 연결된 모든 리소스에 자동으로 반영된다.
- VPC마다 기본 보안 그룹이 있으며 삭제할 수 없다. 기본 보안 그룹은 같은 보안 그룹에 속한 리소스끼리의 인바운드만 허용한다.
규칙의 원천이나 대상으로 CIDR 대신 다른 보안 그룹 ID를 지정할 수 있다. 그러면 참조된 보안 그룹에 속한 리소스의 사설 IP에서 오는 트래픽이 허용된다. 같은 VPC 안이거나 피어링 연결, Transit Gateway로 연결된 VPC의 보안 그룹을 참조할 수 있다(아웃바운드 규칙에서는 같은 VPC나 피어링된 VPC만 가능).
전형적인 3계층 구성은 다음과 같다.
| 보안 그룹 | 인바운드 규칙 | 원천 |
|---|---|---|
| sg-alb(로드 밸런서) | TCP 443 | 0.0.0.0/0 |
| sg-web(웹·앱 서버) | TCP 80 | sg-alb |
| sg-db(데이터베이스) | TCP 3306 | sg-web |
Auto Scaling으로 서버 수와 IP가 계속 바뀌어도 규칙을 고칠 필요가 없고, 데이터베이스는 웹 계층을 거치지 않은 트래픽을 받지 않는다.
아마존 DNS(Route 53 Resolver), 아마존 DHCP, EC2 인스턴스 메타데이터, ECS 작업 메타데이터 엔드포인트, Windows 라이선스 활성화, 아마존 Time Sync Service, 기본 VPC 라우터 예약 주소로 오가는 트래픽은 보안 그룹과 네트워크 ACL 모두 걸러내지 않는다. VPC 안에서 DNS 질의를 통제하려면 Route 53 Resolver DNS Firewall을 쓴다.
네트워크 ACL은 서브넷 경계에서 들어오고 나가는 트래픽을 허용하거나 거부한다.
- VPC의 모든 서브넷은 반드시 네트워크 ACL 하나와 연결된다. 명시적으로 연결하지 않으면 기본 네트워크 ACL과 연결된다. 하나의 네트워크 ACL은 여러 서브넷에 연결할 수 있지만, 서브넷은 한 번에 하나의 ACL만 가진다.
- 각 규칙에는 1부터 32766까지의 번호가 붙는다. 번호가 낮은 규칙부터 평가하고, 일치하는 규칙을 찾으면 그 뒤의 규칙은 보지 않는다. 나중에 규칙을 끼워 넣을 수 있도록 10이나 100 단위로 번호를 매기는 것이 좋다.
- 마지막에는 번호 대신 별표(*)가 붙은 규칙이 있어, 어떤 번호 규칙과도 일치하지 않는 패킷은 거부된다. 이 규칙은 지울 수 없다.
- 서브넷 안에서 오가는 트래픽이 아니라 서브넷을 드나드는 트래픽만 평가한다.
- 상태 비저장이라서 인바운드를 허용해도 그 응답이 자동으로 나가지 않는다. 응답이 나갈 아웃바운드 규칙, 특히 임시 포트(ephemeral port) 범위를 따로 열어야 한다.
- 기본 네트워크 ACL은 모든 인바운드·아웃바운드를 허용하도록 설정되어 있다. 반대로 새로 만든 사용자 지정 네트워크 ACL은 규칙을 추가하기 전까지 모든 트래픽을 거부한다.
클라이언트는 요청을 보낼 때 운영 체제가 정한 범위에서 임시 포트 번호를 골라 출발지 포트로 쓰고, 서버의 응답은 그 포트로 돌아온다. 네트워크 ACL에서는 이 응답 경로를 직접 열어야 한다.
| 요청을 시작한 쪽 | 임시 포트 범위 |
|---|---|
| 많은 Linux 커널(아마존 Linux 포함) | 32768–61000 |
| Elastic Load Balancing이 보내는 요청 | 1024–65535 |
| Windows Server 2008 이후 | 49152–65535 |
| NAT 게이트웨이 | 1024–65535 |
| AWS Lambda 함수 | 1024–65535 |
실무에서는 다양한 클라이언트를 고려해 1024–65535를 열고, 막아야 할 포트가 있으면 그보다 낮은 번호의 거부 규칙을 앞에 둔다.
인터넷에 웹 서비스를 제공하는 퍼블릭 서브넷의 사용자 지정 네트워크 ACL 예시이다. 특정 공격 원천 대역 203.0.113.0/24를 차단해야 하는 상황을 가정했다.
| 방향 | 규칙 # | 프로토콜·포트 | 원천/대상 | 허용/거부 | 설명 |
|---|---|---|---|---|---|
| 인바운드 | 50 | 모든 트래픽 | 203.0.113.0/24 | 거부 | 차단할 대역을 허용 규칙보다 먼저 평가 |
| 인바운드 | 100 | TCP 443 | 0.0.0.0/0 | 허용 | HTTPS 요청 |
| 인바운드 | 120 | TCP 22 | 192.0.2.0/24 | 허용 | 사내 대역에서만 SSH |
| 인바운드 | 140 | TCP 1024–65535 | 0.0.0.0/0 | 허용 | 서브넷에서 시작한 요청의 응답 |
| 인바운드 | * | 모든 트래픽 | 0.0.0.0/0 | 거부 | 기본 거부(수정 불가) |
| 아웃바운드 | 100 | TCP 443 | 0.0.0.0/0 | 허용 | 서브넷에서 외부로 나가는 HTTPS |
| 아웃바운드 | 140 | TCP 1024–65535 | 0.0.0.0/0 | 허용 | 클라이언트에게 보내는 응답 |
| 아웃바운드 | * | 모든 트래픽 | 0.0.0.0/0 | 거부 | 기본 거부(수정 불가) |
아웃바운드 140번이 없으면 HTTPS 요청은 들어오지만 응답이 나가지 못해 접속이 실패한다. 상태 비저장 특성을 묻는 문제의 전형적인 원인이다.
| 요구 | 선택 |
|---|---|
| 특정 IP나 대역을 명시적으로 차단 | 네트워크 ACL의 거부 규칙(보안 그룹은 거부 불가) |
| 계층 간 접근 통제, 인스턴스가 늘었다 줄었다 함 | 보안 그룹 참조 |
| 서브넷 전체에 공통 정책을 강제, 잘못된 보안 그룹 설정에 대비한 심층 방어 | 네트워크 ACL |
| 애플리케이션 계층 공격(SQL 인젝션, XSS) 차단 | 둘 다 아님. AWS WAF |
| 대규모 IP 차단 목록이나 정교한 상태 기반 검사 | AWS Network Firewall 같은 별도 방화벽 |
- "특정 IP 대역을 차단하라"는 요구에는 보안 그룹이 아니라 네트워크 ACL의 거부 규칙이 답이다. 거부 규칙 번호를 허용 규칙보다 낮게 둔다.
- 보안 그룹은 상태 저장, 네트워크 ACL은 상태 비저장이다. 인바운드는 열었는데 통신이 안 되면 NACL 아웃바운드의 임시 포트를 의심한다.
- 웹 계층에서 오는 트래픽만 DB에 허용하려면 DB 보안 그룹의 원천을 웹 계층 보안 그룹 ID로 지정한다. IP 대역 지정보다 관리가 쉽다.
- 새 사용자 지정 네트워크 ACL은 전체 거부, 기본 네트워크 ACL은 전체 허용이 기본값이다.
- 보안 그룹은 리소스(네트워크 인터페이스)에, 네트워크 ACL은 서브넷에 붙는다. NAT 게이트웨이에는 보안 그룹을 연결할 수 없고 서브넷의 네트워크 ACL로만 통제한다.
- Amazon VPC의 인프라 보안 – AWS
- 보안 그룹을 사용하여 AWS 리소스에 대한 트래픽 제어 – AWS
- 보안 그룹 규칙 – AWS
- 네트워크 액세스 제어 목록으로 서브넷 트래픽 제어 – AWS
- VPC의 사용자 지정 네트워크 ACL – AWS