[AWS SG, ACL] 3 Layer 방화벽 이해(1): 보안 그룹 vs ACL

AWS에서 생성한 리소스들의 접근 제어를 하는 방법은 다양합니다. 그 중 기본적이면서 가장 중요한 보안 설정인 방화벽 구성에 대해 알아보겠습니다.

 

 

보안 그룹(SG, Security Gruop)과 네트워크 ACL(Access Control List), WAF(Web Application Firewall)은 모두 각 단에서의 방화벽 역할을 합니다. 

 

보안그룹, ACL, WAF 방화벽 구성도

 

위 위 아키텍쳐는 각 인스턴스(서버)에 보안 그룹을 설정하고, 서브넷 앞의 ACL로 접근 가능 리스트를 설정하고, 전체 VPC 앞에 WAF를 걸어 세 레이어로 방화벽을 구성한 모습입니다.

각 요소들이 어떤 역할을 하는지 지금부터 자세히 알아보겠습니다.

 

1. 보안 그룹

보안 그룹은 서버(인스턴스) 단위로 Inbound/Outbound 정책을 설정할 수 있습니다. 서브넷 안에서 내부통신을 할 경우 이 보안 그룹의 정책을 적용합니다. 따라서 서브넷 안에 있는 각 인스턴스는 각각 다른 보안 그룹을 가질 수 있습니다.

인스턴스 생성 시 보안 그룹을 설정하거나 편집할 수 있고, 이후에도 얼마든지 수정 가능합니다. 인스턴스 시작 시 보안 그룹을 명시하지 않는다면 자동으로 default 보안 그룹에 할당됩니다.

 

보안 그룹 = 인스턴스 안에서 들어가고 나가는 트래픽 제어, 인스턴스 수준 방화벽

 

 

보안 그룹의 가장 큰 특징은 Stateful이라는 것입니다. 상태를 저장하기 때문에 들어오고 나가는 트래픽을 모두 체크할 수 있습니다. 

또한 모든 inbound를 deny하고, 특정 트래픽만 allow하는 규칙만을 생성(Whitelist) 할 수 있습니다. 이 규칙은 순서 상관없이 모두 한 번에 적용됩니다.

 

 

 

그럼 보안 그룹을 직접 생성해보겠습니다.

 

 

VPC - 보안 그룹 선택

 

보안 그룹 이름과 VPC 지정

 

네이밍 규칙을 적용해 보안 그룹의 이름을 설정하고, VPC도 선택합니다. (이때 default가 아닌 꼭 생성한 해당 VPC를 선택하는 것 잊지 않기!)

 

인바운드 규칙 추가

 

인바운드 규칙을 추가합니다. 저는 원격 접속과 인터넷 연결을 위해 HTTP, HTTPS, SSH를 모두 허용해주었습니다. 0.0.0.0/0은 Any라는 뜻으로 모든 인바운드를 허용한다는 뜻입니다.(이러면 방화벽의 의미가 당연히 없습니다.. - 간단한 실습을 위한 설정) 물론 사용자 지정을 통해 직접 지정도 가능합니다.

마찬가지로 아웃바운드 규칙도 같은 방식으로 설정할 수 있습니다.

 

 

+) 이렇게 인스턴스를 만들 때 아예 네트워크 설정에서 보안 그룹을 바로 생성하고 규칙을 설정할 수도 있습니다!

 

인스턴스 시작 시 보안 그룹 설정

 

 

보안 그룹 실습

 

두 개의 보안 그룹을 만들어 inbound/outbound 규칙을 설정하고, 설정한 대로 통신이 되는지 확인해보겠습니다.

우선 VPC 생성 후 nami-01과 nami-02 인스턴스를 각각 생성했습니다. 그리고 각 인스턴스에 보안 그룹을 만들어 nami-sg01과 nami-sg02를 할당했습니다.

 

아키텍쳐

 

nami-sg01은 nami-sg02에게 ping을 보내는 outbound 규칙을,

nami-sg02는 nami-sg01로부터 ping을 받는 inbound 규칙을 만들 것입니다.

 

nami-sg01 보안그룹 규칙

 

nami-sg02 보안그룹 규칙

 

 

nami01 → nami02로 ping이 잘 나가는 것을 확인할 수 있습니다.

 

sg01 > sg02 로 ping test

 

 

nami02에서는 다른 outbound 규칙을 설정해주지 않았기 때문에 ping이 나가지 않는 것을 알 수 있습니다.

 

sg02 > sg01 로 ping test

 

 

 

보안 그룹을 이용한 내부통신 요약

 

---

 

2. ACL

 

서브넷 앞 단에 걸리는 방화벽입니다. 따라서 외부 통신을 담당하며, 서브넷 단위로 정책을 생성할 수 있습니다.

보안그룹과 달리 특정 트래픽을 deny하는 규칙도 생성할 수 있으며, 순서가 중요합니다. 리눅스 방화벽과 마찬가지로 번호가 낮은 것이 우선순위가 높습니다. (규칙 중요도 존재!)

 

ACL = 라우팅 테이블을 통해 서브넷으로 들어가고 나가는 트래픽 제어, 서브넷 수준 방화벽

 

 

가능하면 서브넷 경계에 있는 ACL에서 트래픽을 우선 차단하는 것이 바람직합니다. 보안그룹 자체에 규칙을 많이 설정하기 보다, ACL 단에서 전체 서브넷에 대한 규칙을 설정해야 합니다. 이후 인스턴스 별로 허용하는 트래픽만 보안그룹에 거는 것이 가장 이상적입니다.

 

 

 

ACL 실습

 

이제 다른 서브넷에 nami-03이라는 새 인스턴스를 만들었습니다. nami-01과 nami-02는 같은 서브넷에 있어 보안 그룹 설정만으로 통신이 되었지만, nami-03은 다른 서브넷에 위치하기 때문에 ACL 설정이 반드시 필요합니다.

 

nami-sg03의 inbound/outbound 규칙 (nami-sg01과 동일)

 

 

ACL 설정 전 nami-02와 통신되지 않는 nami-03

 

 

그렇다면 ACL을 생성해줍시다 ..!

 

VPC - 네트워크 ACL 생성

 

NACL을 생성하면 기본적으로 모든 inbound/outbound 규칙이 deny입니다.

 

서브넷 연결

 

nami-03에 해당하는 서브넷을 연결해줍니다. 지금 만든 NACL3은 nami-03이 있는 서브넷(public2)에 연결되어 해당 서브넷 전체에 규칙을 적용할 것입니다.

 

모든 규칙이 deny가 됐기 때문에, 우선 원격 접속을 위한 SSH 통신이 가능하도록 규칙을 만들어주어야 합니다.

inbound는 SSH 22로 설정하면 되지만, outbound는 OS가 어떤 포트로 응답할지 모르므로(랜덤) 포트 범위를 지정해 주어야 합니다. cat /proc/sys/net/ipv4/ip_local_port_range 명령어를 통해 해당 OS의 응답 포트 범위를 확인할 수 있습니다.

 

포트 범위 확인

 

NACL3의 inbound/outbound 규칙 (포트 확인 후 outbound 규칙 설정)

 

이제 SSH 원격 접속이 가능해졌으므로, 다시 nami-03 서버에 접속할 수 있습니다.

 

 

nami-02 서브넷을 연결한 NACL2 생성

 

마찬가지로 NACL2도 생성해 NACL3과 같이 원격 접속을 위한 SSH 규칙을 만들어줍니다. (inbound/outbound 모두 생성) 

이제 두 서버 모두 다시 원격 접속이 가능해졌습니다.

 

 

그렇다면 최종적으로 ICMP 규칙을 추가해 nami-02와 통신할 수 있도록 해보겠습니다.

 

NACL3의 규칙 (nami-02와 통신하도록 해당 서브넷 ICMP 규칙 추가)

 

NACL2의 규칙 (nami-03과 통신하도록 해당 서브넷 ICMP 규칙 추가)

 

 

제 생각에는 이렇게 ACL의 inbound/outbound ICMP 규칙을 넣어주면 다른 서브넷에 있는 두 서버가 서로 통신이 되어야 하는데 ...

여전히 ping이 가지 않습니다. 왜일까요 ?????  좀 더 고민해봐야겠습니다 . . 

 

 

ACL를 이용한 서브넷 간 통신 요약

 

---

 

3. 보안 그룹 vs ACL

보안 그룹과 NACL의 차이와 특징을 정리하면 다음과 같습니다.

 

Security Group	ACL
인스턴스 레벨	서브넷 레벨
allow 만 가능	allow, deny 모두 가능
규칙 우선순위 X	낮은 번호의 규칙부터 적용 (우선순위 O)
Stateful	Stateless

 

 

용도와 범위에 맞게 보안 그룹과 ACL을 활용해 외부 트래픽과 내부 통신을 적절히 제어하고 보안 설정을 할 수 있습니다.

 

 

 

출처

- Architection on AWS: Student Guide

- https://honglab.tistory.com/153