들어가며
아키텍처를 설계하면서, 견고한 아키텍처를 설계하려면 어떻게 해야 할까 늘 고민하고 있습니다. 아키텍처의 네트워크 환경을 잘 구축하려면 어떻게 해야 할까 고민하던 중, VPC 개념에 대해 알 수 있었습니다. 이번 기회에 VPC를 적용해서 더 나은 서버구조를 설계하고 싶었습니다. 아래 글은 유튜브 AWS 강의실의 보안 그룹과 AWS NACL에 대한 영상을 보고 정리한 내용이 적혀 있습니다. 자세하게 살펴보고 싶으신 분들은 영상을 참고해 주시면 됩니다. 이 글에서는 보안그룹과 NACL에 대해 알아보겠습니다.
보안 그룹
보안 그룹은 Network Access Control List(NACL)와 함께 인스턴스에 대한 인바운드 및 아운바운드 트래픽을 제어하는 가상 방화벽 역할을 합니다. 보안그룹에서는 기본적으로 모든 포트를 비활성화하는데요. 선택적으로 트래픽이 지나갈 수 있는 Port와 Source를 설정할 수 있습니다. NACL에서는 Deny가 가능하지만, 보안그룹에서는 Deny가 불가능하다는 특징이 있습니다.
그리고 NACL의 경우엔 서브넷 단위로 설정이 가능하지만 인스턴스 단위(ENI)로 하나 이상의 보안그룹 설정이 가능합니다. 그래서 보안그룹이 설정된 인스턴스는 설정한 모든 보안그룹의 룰을 적용받습니다. 또한 외부 통신의 경우 NACL과 보안 그룹을 모두 거쳐야 하는데, 내부적으로 통신하는 경우엔 보안 그룹만 거치면 된다는 특징이 있습니다.
또한 보안그룹은 Stateful 한 특징이 있고, NACL은 Stateless 한 특징이 있는데요. 여기서 stateless란, 요청 정보를 따로 저장하지 않아서 응답하는 트래픽도 제어해줘야 한다는 특징이며, stateful이란 요청 정보를 저장하여 응답하는 트래픽 제어를 하지 않는다는 특징입니다. 즉 NACL을 사용하면 외부에서 들어오는 트래픽에 대해 요청 정보를 저장하지 않기 때문에, 아웃바운드 설정을 반드시 설정해야 하고, 보안그룹은 요청 정보를 저장하기 때문에, 인바운드로 들어온 트래픽이 아웃바운드 설정을 별도로 하지 않아도 응답을 전달할 수 있다는 특징이 있습니다.
보안 그룹 source
보안 그룹의 Source가 될 수 있는 건 크게 3가지입니다. 첫 번째는 IP Range(CIDR), 두 번째는 접두사 목록, 세 번째는 다른 보안 그룹이 될 수 있습니다. 여기서 접두사 목록이란, 하나 이상의 CIDR 블록의 집합을 뜻합니다. 보안 그룹 혹은 Route Table에서 많은 대상을 참조하기 위해 사용합니다. 접두사 목록에는 두 가지 종류가 있습니다. 첫 번째는 고객 관리형이 있고, 두 번째는 AWS 관리형이 있습니다. 고객 관리형의 경우, 직접 IP 주소를 생성, 수정, 삭제할 수 있으며 다른 계정과도 공유가 가능하다는 특징이 있습니다. AWS 관리형의 경우 AWS의 서비스들을 위한 IP 목록입니다. 이는 수정, 삭제, 업데이트가 불가능합니다. IPv4, IPv6 둘 다 사용이 가능하지만, 한 접두사 목록에 두 가지 타입은 동시에 사용이 불가능합니다.
만약 위 그림처럼 아키텍처가 구성되어 있다고 가정하면, 이 경우 보안그룹을 어떻게 설정해야 할까요?
아마 위의 방식처럼 인바운드 규칙을 설정할 것입니다. 인바운드로 들어오는 ip 주소를 모두 하나씩 추가해줘야 할 것입니다. 이렇게 관리한다면, 너무 힘들 것입니다. 실전이라면 많은 종류의 인스턴스, 보안그룹이 있을 수 있는데, 외부 IP가 하나 추가되거나 삭제할 때마다 보안그룹을 업데이트해야 하는 특징이 있습니다.
그때 활용하는 것이 접두사 목록입니다. 미리 테이블로 빼놓는 방식입니다. 그리고 다른 보안그룹에서 가져다 쓰는 방식입니다. 만약 접두사 목록에서 사용하지 않는 IP를 제거하더라도, 접두사 목록을 참조하고 있는 EC2, RDS에 바로 반영이 됩니다. 그래서 별도로 보안그룹을 수정할 필요가 없다는 큰 장점이 있습니다. 만약 IP 주소를 더하더라도, 동일하게 EC2, RDS에 바로 반영이 된다는 특징이 있습니다.
그럼 두 번째는 다른 보안 그룹을 참조하는 방법에 대해 살펴보겠습니다.
이 경우, RDS의 보안그룹을 어떻게 설정할까요?
보안 그룹의 소스는 CIDR Block으로 ip range를 잡을 수 있으니, 10.1.1.0/24로 잡을 수도 있을 것입니다. 그렇지만, 이렇게 설정한다면 10.1.1.0/24 안에 해당하는 IP 주소값들이 모두 인바운드 규칙으로 적용되어 다른 문제를 야기할 수 있습니다. 경우에 따라 하나의 서브넷 안에 여러 개의 인스턴스가 있을 수 있기 때문에, 모든 레인지를 허용하면 모든 서브넷에 있는 원치 않는 ec2 인스턴스들도 rds에 들어올 수 있기에 이렇게 허용하는 것은 좋은 방식이 아닐 수 있습니다.
이때 사용하는 것이 보안그룹의 참조 방식입니다. 보안그룹의 참조를 하면 예를 들어 소스에 SeG-EC2로 설정하면, SeG-EC2 보안그룹에 있는 트래픽들은 모두 받겠다는 뜻입니다. 이러면 다른 서브넷에 있더라도, 보안그룹만 적용하면 됩니다.
이렇게 간단히 보안그룹에 알아봤고, 다음은 NACL에 대해 알아보겠습니다.
NACL
NACL은 1개 이상의 서브넷 내부와 외부의 트래픽을 제어하기 위한 방화벽 역할을 하는 VPC를 위한 선택적 보안 계층입니다. 보안 그룹과 같이 방화벽 역할을 담당하며, 서브넷 단위로 트래픽을 제어하기 때문에, 인스턴스 단위로 제어는 불가능합니다. 다양한 서브넷에 연동이 가능하다는 특징이 있습니다. 단 하나의 서브넷에는 여러 개의 NACL을 연동할 순 없습니다. 포트 및 아이피를 직접 Deny가 가능하기 때문에, 외부 공격을 받는 상황 등 특정 아이피를 블록 하고 싶을 때 사용이 가능합니다. 또한 Stateless 하다는 특징이 있어서 들어오는 트래픽과 나가는 트래픽을 구분하지 않고, 아웃바운드에 포트 범위를 열어줘야 정상적으로 통신이 가능합니다.
NACL 규칙
NACL의 규칙에 대해 살펴보겠습니다. NACL에는 규칙을 설정할 수 있는데, 규칙 번호를 지정하여 규칙 번호가 낮은 순으로 규칙이 평가됩니다. AWS에서는 100 단위로 증가하는 것을 추천한다고 합니다. 예를 들어 살펴보겠습니다.
만약 112.12.35.4의 접근을 막고 싶어서 NACL에서 규칙을 설정했다고 가정하겠습니다. 위처럼 규칙을 설정했을 땐 제대로 동작하지 않습니다. 왜냐하면 규칙 번호에 100으로 모든 소스를 허용했기에, 접근을 거부할 수 없습니다. 만약 112.12.35.4 IP 주소를 Deny 하려면 아래처럼 구성해야 합니다.
규칙 번호를 위로 올려서, Deny 하고 싶은 소스를 먼저 작성해줘야 합니다. 그럼 왜 AWS는 100 단위로 증가하는 것을 추천했을까요? 만약 규칙 번호를 1, 2로 설정했다면, 1과 2 사이에 공간이 없기 때문에, 1, 2를 제외한 나머지 규칙들을 뒤로 미뤄야 하기 때문에 관리하기 번거로울 수 있습니다. 그래서 여유 있게 구성할 수 있도록 추천하는 듯싶습니다.
만약 VPC 안에서 여러 서브넷끼리 통신을 해야 하는 경우, NACL에 80번 포트만 허용해 둔다면, EC2와의 접근은 가능할 수 있어도, 다른 서브넷에 존재하는 DB에는 접근이 불가능할 것입니다. Subnet A와 B에 하나의 NACL을 연결했기 때문에, 서브넷 밖으로 들어가거나 나올 땐 NACL의 영향을 받게 됩니다. EC2도 클라이언트기 때문에, DB와 통신할 텐데, 어떤 포트로 응답을 보낼지 알 수 없습니다.
NACL에 80번 포트만 허용됐기 때문에 그럼 데이터베이스와 통신이 이뤄지지 않을 것입니다. 그래서 보안그룹으로 통제가 안 되는 부분을 NACL로 제어하는 것이 좋아 보입니다.
마치며
네트워크에 대해 조금씩이라도 지식을 쌓아가고 싶습니다. 기본을 꾸준히 쌓을 수 있는 개발자가 되겠습니다.
출처
VPC는 Sims같아요. (AWS 강의실 - VPC 개념)
Sims 해보셨나요? 심즈는 땅과 건물을 사서 그 안에 개인 캐릭터를 키우는 게임입니다. 건물 내에 벽을 설치해서 공간을 나눌 수도 있습니다. 또한, 가구 등을 주문해서 인테리어를 할 수도 있습
rileyko.tistory.com
[ AWS ] ACL 및 보안그룹 비교, 생성 및 적용
※ 개인 공부를 위한 공간입니다. 틀린 부분 지적해주시면 감사하겠습니다 (_ _) [AWS 설명] AWS는 VPC를 위해 보안을 늘리고 모니터링 할 수 있는 기능들을 제공한다. 보안그룹(Security groups) ACL(Network
martinkim1954.tistory.com
[AWS] NACL vs Security Group (Stateless와 Stateful 차이)
# 요약만 확인하기 NACL과 Security Group에 대한 전반적인 개념은 아래 글을 참조하자 https://cleverdj.tistory.com/122 위의 글에서 볼 수 있듯이, NACL은 "서브넷 단위"이고, Security Group은 "서버 단위" 이다 따
honglab.tistory.com
'네트워크' 카테고리의 다른 글
| [네트워크] Systems Manager 이해하기 (1) | 2023.10.03 |
|---|---|
| [네트워크] NAT Gateway, Bastion Host 이해하기 (0) | 2023.10.02 |
| [네트워크] 인터넷 게이트웨이(IGW) 이해하기 (0) | 2023.10.01 |
| [네트워크] 라우팅테이블(Route Table) 이해하기 (0) | 2023.10.01 |
| [네트워크] Region, AZ, Subnet, CIDR 이해하기 (0) | 2023.10.01 |
