[AWS] 📚 VPC 개념 & 사용 - 보안 설정 [Security Group / NACL]

Amazon Cloud/VPC

[AWS] 📚 VPC 개념 & 사용 - 보안 설정 [Security Group / NACL]

인파_ 2022. 4. 21. 09:54

VPC 방화벽 [Security Group / NACL]

이번엔 VPC의 트래픽을 통제하고 제어하는 서비스들을 살펴보자.

이 서비스들은 흔히 특정 IP를 밴 한다거나 외국에서는 접속을 못하게 한다거나 등 이러한 방화벽 설정을 한다고 보면 된다.

대표적으로 2가지 서비스가 있는데, 바로 이번에 배울 Security Group / Network ACL 이다.

익숙해지면 매우 편리한 서비스이지만 처음 배울땐 난이도가 있기 때문에 확실히 아는 것이 중요하다.

아래 그림은 VPC를 도식화한 것이다.

앞서 배운 Internet gateway, Route table, Subnet, VPC Router가 보이는데 중간마다 자물쇠로 채워진 요소들이 있는데 이것이 Security Group과 Network ACL 이다.

배우기 앞서 간단하게 정리하자면,

Network ACL은 서브넷 상자 위에 위치해 있는데, 바로 서브넷에 오가는 트래픽을 제어하는 역할을 한다.

Security Group 서브넷 상자 안에 위치해 있는데, 인스턴스의 트래픽을 제어하는 역할을 한다. 다만 왼쪽과 오른쪽 Security Group 모양이 다른데, 이는 다수의 인스턴스가 하나의 Securiy Group을 쓰거나, 각자의 Security group을 쓸 수 있음을 의미한다.

Security Group (보안그룹)

사전 설명이 길어졌다. 이제 본격적으로 보안 그룹(Security Group)에 대해서 알아보자.

보안 그룹은 인스턴스에 대한 인바운드(외부 - > 인스턴스) & 아웃바운드(인스턴스 - > 외부) 트래픽을 제어하는 가상 방화벽 역할을 한다.

여기서 말하는 인스턴스는 EC2 인스턴스뿐만 아니라 VPC 내에 탑재될 수 있는 수많은 가상 컴퓨터를 의미한다.

그러므로 EC2, RDS, ELB, VPC Interface Endpoint 등도 포함될 수 있다.

정확히 말하면 VPC 내에서 Elastic Network Inteface(ENI)를 갖는 모든 서비스에 탑재될 수 있다. Security Group은 인스턴스의 ENI에 적용되는 것이기 때문이다.

위 두 사진은 Public Subnet 내 EC2 인스턴스의 Security Group의 설정 예시이다.

표에서 볼 수 있듯이 프로토콜 유형과 포트, IP 등을 지정할 수 있다.

이 표에서는 Public Subnet 내의 EC2 인스턴스는 외부 인터넷 웹 서비스를 제공하기 때문에 HTTP와 HTTPS를 접속할 수 있도록 허용되있고, EC2 인스턴스로의 직접 접속을 위해 SSH도 열게 설정 되었다.

아웃바운드는 EC2에서 출발하는 모든 트래픽을 의미하므로 모두 허용 되어지게 되어있다.

즉, 이 EC2 인스턴스에는 HTTP/HTTPS/SSH 트래픽만 허용되는 것이다.

이처럼 다음 사진처럼 특정 포트만을 허용해 어떤 프로토콜만 받도록 구성이 가능하다.

이를 기반으로 보안 그룹(Security Group)은 몇 가지 특징을 갖는데 열거해보면 다음과 같다.

보안 그룹은 인바운드 규칙과 아웃바운드 규칙으로 나뉨
허용 규칙만 생성 가능.
Deny 불가능 → 블랙 리스트 처럼 몇몇을 골라 특정 차단을 불가능. 일부 허용을 통해서 간접 차단으로 구성은 가능
(무언가를 차단하는 규칙은 Network ACL)
기본적으로 모든 Security Group의 아웃바운드 규칙은 모든 아웃바운드 트래픽 허용
Security Group은 인스턴스 단위로 설정 → 하나의 인스턴스에는 하나 이상의 Security Group 설정 가능. 최대 5개 동시 적용 가능.
(Network ACL은 서브넷 단위로 설정)
각 인스턴스에 각각 서로 다른 보안 그룹에도 할당 가능
설정된 인스턴스는 연결되있는 보안그룹의 모든 룰에 적용 받는다.
상태를 저장하여 한 번 인바운드를 통과하는 트래픽은 아웃바운드의 규칙 적용을 받지 않음 (Stateful)
상태를 저장하여 한 번 아웃바운드를 통과하는 트래픽은 인바운드의 규칙 적용을 받지 않음 (Stateful)

보안 그룹은 Stateful

위의 보안 그룹의 특징에서 마지막 두 부분이 Securiy Group의 가장 큰 특징이라고 할 수 있는데, 이를 Stateful이라 한다.

위의 Security Group 표를 보면 HTTP/HTTPS/SSH의 허용은 인바운드에만 적용 되어있다.

보안 그룹은 stateful이라 인바운드에만 허용시켜두면 3개 프로토콜은 아웃바운드 규칙에 영향을 받지 않고 트래픽의 왕래 한다는 소리이다.

즉, 인바운드를 통해 온 트래픽이라는 소리는 문제없는 허용된 트래픽이라는 것이고 이를 보안 그룹에서 기억하고 있다가, 트래픽이 빠져 나갈때 이 트래픽은 문제없는 놈인걸 기억하기 때문에 아웃바운드 규칙에 구애 받지않고 나가는 것이다.

그림에서 볼수 있듯이 인바운드는 80번 포트만 허용하고 있다.

그런데 아웃바운드는 none으로 되어있다. 아무것도 허용 안한다는 소리이다.

하지만 클라이언트가 80포트로 요청이 오게 되면 인바운드에서 통과가 되고 인스턴스에서 응답을 할때는 아운바운드 규칙이 아무것도 허용치 않은 none으로 설정됬음에도 불구하고 상태를 기억(stateful)하기 때문에 왕래 하는 것이다.

Security Group 실전 구축하기

보통 보안그룹은 EC2 인스턴스를 만들때 같이 설정해 만들게 된다.

물론 VPC 좌측메뉴에서 따로 보안그룹 탭을 제공하기도 한다.

[VPC 좌측 메뉴] - [보안 그룹] - [보안 그룹 생성] 을 선택한다.

외부에서 ssh나 혹은 웹을 통해 EC2 인스턴스에 접속하게 하려면 포트를 허용해줘야 한다.

다음 사진 처럼 SSH, HTTP 유형을 선택해 빠르게 포트 설정을 할수도 있고, 사용자 지정을 통해 포트 범위를 정할 수도 있다.

만일 소스에서 내 IP를 선택하면 현재 내 IP에서만 인스턴스에 접속이 가능하도록 할 수 있다.

어디에서나 접속하려면 위치 무관을 선택하거나

Security Group 변경하기

또한, 보안 그룹은 하나 만들어놓으면 다른 인스턴스에서도 골라서 사용할수도 있다.

만일 현재 인스턴스에서 다른 보안 그룹 세팅으로 적용하고 싶다면 EC2 인스턴스 메뉴에 가서, 인스턴스에 우측 클릭하고 보안 메뉴를 선택하면 된다.

또한 보안 그룹은 동시에 여러개 세팅이 가능하다.

예를들어 어떤 보안그룹 항목은 443과 80만 허용하고, 어떤 보안그룹 항목은 8080과 3306 포트를 허용한다고 하면, 이 두개의 보안 그룹 항목을 동시에 등록해 적용할 수 있다.

Network ACL (네트워크 액세스 제어)

보안 그룹(Security Group)에서 간간히 비교대상으로 설명한 NACL(Network ACL) 이다.

NACL(Network ACL)은 단어 그대로 Subnet의 Access List(접근 제어 목록)을 책임진다.

보안 그룹이 인스턴스의 접근 제어 목록이라면, NACL은 Subnet을 오고 가는 모든 트래픽을 제어하는 역할을 한다고 보면 된다.

NACL은 Subnet 단위로 적용되기 때문에 Subnet 내의 모든 트래픽은 Network ACL의 규칙 적용을 받게 된다.

일종의 서브넷이 들어있는 AZ에 가기전에 최전선에서 싸우는 보안 검문소 인 셈이다.

위 두 사진은 Public Subnet의 Network ACL 설정 예시 이다

위의 Security Group 표와 달리 규칙 # 이란 항목이 존재하고 허용/거부 항목도 있다.

Network ACL의 특징을 열거하면 다음과 같다.

인바운드 규칙과 아웃바운드 규칙으로 나뉨
NACL은 여러 서브넷에 적용이 가능하다. 하지만 서브넷은 한개의 NACL만 연결이 가능하다.
허용 규칙뿐만 아니라 거부 규칙 생성 가능. (보안 그룹은 허용만)
즉, 누군가를 블럭하는건 NACL만 가능
규칙에 숫자가 매겨져 가장 작은 숫자값을 지니는 규칙이 우선적으로 적용됨
NACL 규칙 목록은 인바운드, 아웃바운드 최대 20개까지 지정 가능하다.
상태를 저장하지 않아 한 번 인바운드를 통과하는 트래픽은 아웃바운드의 규칙 적용을 받음 (Stateless)
상태를 저장하지 않아 한 번 아웃바운드를 통과하는 트래픽은 인바운드의 규칙 적용을 받음 (Stateless)

NACL은 Stateless

Security Group처럼 NACL 특징의 마지막 두 부분이 중요하다. 이러한 특징을 Stateless라고 부른다.

인바운드 규칙을 적용받아 유입된 패킷이 다시 밖으로 나가기 위해서는 아웃바운드 규칙의 적용을 받아야 한다.

위 그림을 보면 인바운드의 80번 포트 허용 규칙으로 요청 트래픽을 아무 문제없이 인스턴스에서 받아 들였다.

그런데 이제 밖으로 빠져나오려고 보니 아웃바운드 규칙이 none(모두 비허용)으로 되어있다.

보안 그룹(Security Group) 인 경우 이전 상태를 기억(stateful)이라서 이 트래픽이 문제없는 놈이란걸 기억하고 내보낼떄 융통성있게 내보내주었었다.

하지만 NACL은 이전 상태따위 기억하지 않아(stateless) 이 트래픽이 신뢰가 있든 없든 융통성없게 무조건 아웃바운드 규칙 문서를 보고 판단한 것이다.

그래서 그림과 같이 해당 트래픽은 응답이 가지 않게 된다.

또한 모든 규칙이 적용되는 Security Group과 달리, Network ACL은 규칙 순서가 있어 가장 작은 규칙 값을 갖는 규칙이 가장 먼저 적용되는 특징도 존재한다.

NACL 규칙 순서

NACL 규칙은 가장 작은 숫자부터 우선되며 순서대로 따져 간다는 것만 기억하면 전혀 어려운 개념이 아니다.

예를들어, 다음과 같이 100번 규칙은 80번 포트를 Allow하고 그다음 101번 규칙은 Deny를 했다.

그러면 어떻게 될까? 간단하다.

숫자가 작은 100번 규칙에서 80번은 이미 Allow됬으니 뒤의 80번 규칙은 무시된다.

이 규칙을 이용해서 80번만 허용하고 나머지는 비허용하는 로직을 다음과 같이 간단하게 생성할 수도 있다.

Security Group vs Network ACL

보통 보안 그룹과 NACL은 같이 운용되어지는게 이상적이다.

우선 서브넷 단위의 NACL로 가장 먼저 트래픽이 들어올 것이다.

이때 Network ACL은 모든 트래픽을 허용하되, 차단할 필요가 있는 IP를 골라 차단하는 식으로 설정한다.

그리고 인스턴스 단위의 Security Group을 사용해 각 인스턴스에 허용되어야 할 프로토콜과 포트를 각각 지정한다. (IP는 지정하지 않음).

즉, Network ACL은 프로토콜과 포트 설정에 관여하지 않고 트래픽을 허용하되 악의적 트래픽이 의심되는 IP를 규칙 값을 이용해 우선적으로 차단하고 그 다음 프로토콜과 포트 설정을 Security Group에 전적으로 맡겨 각 인스턴스에 필요한 규칙을 서비스 특성에 맞춰 설정하여 관리의 효율을 높이는 식의 방법을 조합하여 사용한다.