🛡️ 서브넷과 인스턴스를 지키는 보안 장치(NACL, Security Group)

About this offer

안녕하세요 😊 지난 글에서는 ALB와 Auto Scaling 을 중심으로 3-Tier 아키텍처 의 큰 골격을 살펴봤습니다. 그런데 서버를 Private Subnet에 숨겼다고 해서 보안이 끝나는 건 아닙니다. 각 Tier 사이를 오가는 트래픽을 누가, 어떤 포트로, 어디까지 허용할 것인가 라는 질문이 아직 남아있기 때문입니다. 그래서 오늘은 AWS 네트워크 보안의 핵심인 NACL(Network ACL) 과 Security Group 에 대해 알아보겠습니다! 이번 글은 개념 설명에서 끝나지 않고, 실제 IP 대역과 포트 번호를 넣어서 인바운드 / 아웃바운드 규칙을 어떻게 작성하는지까지 함께 살펴보겠습니다. 조금 길지만 끝까지 따라오시면 규칙 표를 보고 트래픽 흐름을 머릿속으로 그릴 수 있게 되실 겁니다. 😎 📚 Port와 CIDR NACL과 Security Group의 규칙은 결국 "어떤 프로토콜의, 몇 번 포트를, 어떤 IP 대역에서 / 대역으로 허용할 것인가" 를 적는 것입니다. 그래서 규칙을 보기 전에 포트와 CIDR 표기법을 먼저 짚고 넘어가겠습니다. 🔌 자주 쓰는 포트 번호 22 TCP SSH (리눅스 서버 원격 접속) 80 TCP HTTP 443 TCP HTTPS 3389 TCP RDP (윈도우 서버 원격 접속) 3306 TCP MySQL / Aurora MySQL 5432 TCP PostgreSQL 6379 TCP Redis 8080 TCP Tomcat, Spring Boot 기본 포트 53 UDP / TCP DNS 1024 ~ 65535 TCP 임시 포트(Ephemeral Port), 응답 트래픽용 여기서 마지막 임시 포트가 오늘 글에서 굉장히 중요합니다. 클라이언트가 서버의 443번 포트로 요청을 보낼 때, 클라이언트 쪽도 포트가 하나 필요한데요. 이때 OS가 1024 ~ 65535 사이의 포트 하나를 임시로 골라서 사용합니다. 그리고 서버는 응답을 바로 이 임시 포트 로 돌려보냅니다. 요청 : 203.0.113.25:52341 → 서버 IP:443 응답 : 서버 IP:443 → 203.0.113.25:52341 이 부분은 뒤에서 NACL을 설명할 때 다시 등장하니 꼭 기억해주세요! 🧮 CIDR 표기법 203.0.113.10/32 → 딱 이 IP 하나 1 10.0.10.0/24 → 10.0.10.0 ~ 10.0.10.255 256 10.0.10.0/23 → 10.0.10.0 ~ 10.0.11.255 512 10.0.0.0/16 → 10.0.0.0 ~ 10.0.255.255 65,536 0.0.0.0/0 → 모든 IPv4 주소 전체 / 뒤의 숫자는 앞에서부터 고정되는 비트 수입니다. 숫자가 클수록 범위가 좁아지고, /32는 IP 하나, 0.0.0.0/0은 인터넷 전체를 의미합니다. 오늘 아키텍처에는 아래처럼 IP 대역을 할당했다고 가정하겠습니다. 외부 ALB는 443(HTTPS) 으로 요청을 받고, Web 서버(Nginx)의 80 포트 로 전달합니다. Internal ALB는 80으로 요청을 받고, App 서버(WAS)의 8080 포트 로 전달합니다. 🚧 NACL(Network ACL) "네트워크 액세스 제어 목록(ACL)은 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부합니다. AWS 공식 설명서 NACL은 서브넷 경계에서 동작하는 방화벽 입니다. 서브넷으로 들어오고 나가는 모든 트래픽은 반드시 NACL을 거치게 됩니다. 비유하자면 아파트 단지 입구의 경비실 입니다. 단지(서브넷) 안에 몇 세대(인스턴스)가 살든 상관없이, 단지를 드나드는 사람은 모두 입구에서 검사를 받습니다. NACL의 특징을 정리하면 다음과 같습니다. 서브넷 단위 로 적용되며, 하나의 서브넷에는 하나의 NACL만 연결됩니다. (하나의 NACL을 여러 서브넷에 연결하는 것은 가능합니다) Allow와 Deny 규칙 을 모두 작성할 수 있습니다. 규칙 번호가 낮은 것부터 순서대로 평가 하고, 처음 일치한 규칙을 즉시 적용 합니다. Stateless 입니다. 요청과 응답을 각각 따로 검사합니다. 같은 서브넷 안의 인스턴스끼리 주고받는 트래픽 은 서브넷 경계를 넘지 않기 때문에 NACL을 거치지 않습니다. 📋 NACL 규칙 구조 NACL 규칙 하나는 아래 항목들로 구성됩니다. 마지막 * 규칙은 삭제할 수 없는 기본 규칙 으로, 위의 어떤 규칙에도 해당하지 않으면 모두 거부합니다. 그리고 규칙 번호는 보통 100, 110, 120처럼 간격을 두고 작성합니다. 나중에 중간에 규칙을 끼워 넣어야 할 때 105번처럼 사이 번호를 쓸 수 있게 하기 위해서입니다. 참고로 VPC 생성 시 만들어지는 기본 NACL은 모든 트래픽을 허용 하지만, 직접 만든 사용자 지정 NACL은 처음엔 모든 트래픽을 거부 합니다. 새 NACL을 붙였더니 갑자기 통신이 끊겼다면 이 부분부터 확인해보시면 됩니다. 100 : TCP 443, 0.0.0.0/0 → ALLOW 110 : 전체 전체, 198.51.100.0/24 → DENY 위처럼 작성하면 198.51.100.x 대역을 차단하고 싶었어도, 이 대역에서 온 443 요청은 100번에서 먼저 허용되어 버립니다. 110번까지 내려가지도 않는 거죠. 90 : 전체 전체 , 198.51.100.0/24 → DENY 100 : TCP 443, 0.0.0.0/0 → ALLOW 그래서 특정 대역을 막고 싶다면 Deny 규칙을 Allow 규칙보다 앞 번호에 두어야 합니다. 🔐 Security Group "보안 그룹은 연결된 리소스에 도달하고 나갈 수 있는 트래픽을 제어합니다." AWS 공식 설명서 Security Group 은 인스턴스의 네트워크 인터페이스(ENI) 에 연결되는 가상 방화벽입니다. NACL이 아파트 단지 경비실이라면, Security Group은 각 세대 현관문의 도어락입니다. 단지 입구를 통과했더라도 우리 집 비밀번호를 모르면 들어올 수 없습니다. Security Group의 특징은 다음과 같습니다. ENI(인스턴스) 단위로 적용되며, 하나의 ENI에 여러 개의 Security Group 을 붙일 수 있습니다. Allow 규칙만 작성할 수 있고, 적혀 있지 않은 트래픽은 모두 거부됩니다. 규칙 순서가 없으며, 모든 규칙을 평가해서 하나라도 일치하면 허용합니다. Stateful 입니다. 허용된 요청에 대한 응답은 자동으로 허용됩니다. 새로 만든 Security Group은 인바운드 전체 거부, 아웃바운드 전체 허용 상태로 시작합니다. 📋 Security Group 규칙 구조 NACL과 비교해보면 규칙 번호와 Allow / Deny 칸이 없다는 것이 바로 보이실 겁니다. 그리고 세 번째 줄처럼 소스에 IP 대신 다른 Security Group을 지정 할 수 있다는 점이 Security Group의 가장 강력한 기능입니다. 이렇게 하면 "ALB-SG가 붙은 리소스에서 온 요청만 허용" 이 됩니다. Auto Scaling으로 인스턴스가 늘었다 줄었다 하면서 IP가 계속 바뀌어도 규칙을 수정할 필요가 없습니다. ❌ 나쁜 예시: TCP 22, 0.0.0.0/0 → 전 세계 누구나 SSH 접속 시도 가능. 무차별 대입 공격 대상이 됩니다 ⭕ 괜찮은 예시: TCP 22, 203.0.113.10/32 → 관리자 PC의 공인 IP 하나만 허용 ✅ 좋은 예시: TCP 22, Bastion-SG → 배스천 호스트를 거쳐서만 접속 허용 🔄 Stateful vs Stateless 두 서비스의 가장 결정적인 차이가 바로 이 부분입니다. 앞에서 본 요청 / 응답 예시로 다시 보겠습니다. 요청 : 203.0.113.25:52341 → 서버:443 응답 : 서버:443 → 203.0.113.25:52341 Security Group은 Stateful 입니다. 그래서 인바운드에 443만 열어두면, 이 연결에 대한 응답(서버:443 → 클라이언트:52341)은 아웃바운드 규칙과 상관없이 자동으로 나갑니다. NACL은 Stateless 입니다. NACL은 연결을 전혀 기억하지 않고, 패킷 하나하나를 독립적으로 검사합니다. 그래서 응답 패킷도 아웃바운드 규칙에서 다시 검사받습니다. 응답의 목적지 포트는 클라이언트의 임시 포트(52341)이기 때문에, 아웃바운드에 임시 포트 범위를 열어두지 않으면 요청은 들어왔는데 응답이 나가지 못하는 상황이 생깁니다. ⚖️ NACL vs Security Group 한눈에 비교 정리하면 NACL은 서브넷 입구에서 넓게 걸러내는 1차 방어선 , Security Group은 인스턴스 앞에서 정확하게 허용하는 2차 방어선 입니다. 둘 중 하나만 쓰는 것이 아니라, 역할을 나눠서 함께 사용하는 것이 일반적 입니다. 따라서 이전 것들과 이어진 최종 아키텍처는 다음과 같이 나옵니다! 지금까지 NACL과 Security Group을 통해 각 Tier 사이의 트래픽을 어떻게 통제하는지, 실제 IP와 포트를 기준으로 살펴봤습니다. 🙇읽어주셔서 감사합니다. 다음 글에서 다시 뵙도록 하겠습니다🙇🏾‍♂️