Introduction

라우팅 테이블과 게이트웨이가 트래픽의 경로를 결정한다면, Security Group은 그 경로 위에서 어떤 트래픽을 허용할지를 결정합니다. Security Group은 VPC 내 리소스의 네트워크 인터페이스에 적용되는 가상 방화벽으로, 허용 규칙만으로 동작하는 포지티브 보안 모델과 연결 상태를 추적하는 Stateful 속성이 핵심입니다. 이 글에서는 Security Group의 작동 원리, 참조 기반 접근 제어, 그리고 연결 추적의 성능 특성을 살펴봅니다.

보안 그룹이란?

보안 그룹Security Group은 VPC 내 리소스의 네트워크 인터페이스(ENI)1에 적용되는 가상 방화벽이다. EC2, RDS, ELB 등 VPC 안에서 실행되는 거의 모든 리소스에 적용할 수 있다. 핵심은 보안 그룹이 서브넷이나 VPC 단위가 아닌, 개별 ENI 단위에서 작동한다는 점이다. 동일한 서브넷 안에 있는 두 인스턴스라도 서로 다른 보안 그룹을 할당받아 상이한 트래픽 정책을 적용받을 수 있다.

하나의 인스턴스에 여러 개의 보안 그룹을 동시에 할당할 수 있으며, 이 경우 모든 규칙이 합집합aggregate 형태로 적용된다. 어떤 보안 그룹의 규칙이든 하나라도 트래픽을 허용하면 해당 트래픽은 통과한다.

Stateful 동작

보안 그룹의 가장 큰 기술적 특징은 상태 저장(Stateful) 속성이다. 이는 연결의 상태를 추적하여, 요청이 허용되면 응답은 별도의 규칙 없이 자동으로 허용된다는 것을 의미한다.

이 동작 덕분에 관리자는 응답 트래픽이 사용하는 임시 포트ephemeral port(1024~65535)2 범위를 별도로 개방할 필요가 없다. 웹 서버의 인바운드 443 포트만 열어두면, 그에 대한 응답은 어떤 포트를 사용하든 자동으로 통과한다.

이와 대비되는 것이 NACL의 Stateless 동작이다. NACL은 연결 상태를 추적하지 않으므로, 인바운드를 허용하더라도 응답에 사용되는 임시 포트 범위를 아웃바운드 규칙에서 명시적으로 열어줘야 한다.

허용 전용 정책

보안 그룹은 긍정적인 보안 모델positive security model을 따른다.

  1. 보안 그룹 생성 직후에는 인바운드 규칙이 없으므로 모든 인바운드 트래픽이 차단된다. 명시적으로 허용 규칙을 추가해야만 트래픽이 통과한다.
  2. 허용 규칙만 존재한다. '거부(Deny)' 규칙은 생성할 수 없다. 특정 IP를 차단하려면 NACL이나 AWS WAF 같은 다른 계층의 도구를 사용해야 한다.
  3. 새로 생성된 보안 그룹은 모든 아웃바운드 트래픽(0.0.0.0/0)을 허용하는 규칙을 포함한다. 보안 강화를 위해 이 규칙을 삭제하고 필요한 목적지만 허용하도록 축소할 수 있다.

보안 그룹 참조

보안 그룹의 가장 강력한 기능은 IP 주소 대신 다른 보안 그룹의 ID를 소스로 참조할 수 있다는 점이다.

예를 들어, DB Security Group의 인바운드 규칙에서 소스를 sg-web(웹 서버 보안 그룹의 ID)으로 지정하면, sg-web이 할당된 모든 인스턴스에서의 접근이 허용된다. IP가 변경되거나 자동 스케일링으로 인스턴스 수가 늘어나도 규칙을 수정할 필요가 없다.

DB Security Group (sg-db):
  인바운드: MySQL(3306) ← 소스: sg-app

App Security Group (sg-app):
  인바운드: HTTP(8080) ← 소스: sg-web

Web Security Group (sg-web):
  인바운드: HTTPS(443) ← 소스: 0.0.0.0/0

이 체인 구조에서 인터넷 → 웹 → 앱 → DB의 순서로만 트래픽이 흐르며, 중간 단계를 건너뛰는 접근(예: 인터넷 → DB)은 불가능하다. 이것이 보안 그룹으로 구현하는 마이크로 세그멘테이션(micro-segmentation)3이다.

VPC 피어링 환경에서의 참조

보안 그룹 참조는 동일 VPC 내에서만 가능한 것이 아니다. VPC 피어링으로 연결된 다른 VPC의 보안 그룹도 참조할 수 있다. 피어링된 VPC의 보안 그룹 ID를 소스나 대상에 지정하면, VPC 경계를 넘어서도 IP 주소 없이 동적 접근 제어가 가능하다.

다만, 트랜짓 게이트웨이(Transit Gateway)로 연결된 VPC 간에는 보안 그룹 참조가 지원되지 않는다. 이 경우에는 IP 기반(CIDR)으로 규칙을 작성해야 한다.

연결 추적과 성능

보안 그룹의 Stateful 기능은 하이퍼바이저의 연결 추적(connection tracking) 테이블로 구현된다. 인스턴스 타입별로 최대 연결 추적 허용량이 존재하며, 이 한도를 초과하면 새 연결이 드롭된다.

conntrack_allowance_exceeded CloudWatch 지표로 이를 모니터링할 수 있다. 고성능 네트워크 어플라이언스처럼 대량의 연결을 처리해야 하는 경우, 인바운드와 아웃바운드 규칙 모두에서 0.0.0.0/0 전체를 허용하면 AWS는 해당 트래픽의 연결 추적을 생략(untracked connection)하여 성능을 향상시킨다. 단, 이 경우 Stateful 동작이 비활성화되므로 양방향 규칙을 모두 명시적으로 설정해야 한다.

추적 대상과 비추적 대상

모든 트래픽이 연결 추적의 대상이 되는 것은 아니다. AWS는 다음 기준에 따라 추적 여부를 결정한다.

인바운드와 아웃바운드 규칙이 모두 0.0.0.0/0(또는 ::/0)으로 전체 트래픽을 허용하는 경우, 해당 프로토콜의 트래픽은 추적되지 않는다. 이를 비추적 연결(untracked connection)이라 부른다.

반대로, 하나라도 특정 IP 범위나 포트로 제한된 규칙이 있으면 해당 트래픽은 추적 대상이 된다. 예를 들어 인바운드에서 443만 허용하고 아웃바운드는 전체 허용이면, 인바운드 443에 매칭된 트래픽은 추적된다.

비추적 연결은 연결 추적 테이블을 사용하지 않으므로 conntrack_allowance_exceeded 이벤트에 영향을 주지 않는다. 대량의 연결을 처리하는 NAT 인스턴스나 로드 밸런서에서 이 특성을 활용할 수 있다.

보안 그룹 설계 원칙

최소 권한 원칙

보안 그룹 설계의 출발점은 최소 권한 원칙Principle of Least Privilege이다. 기본 아웃바운드 규칙(0.0.0.0/0 전체 허용)을 삭제하고, 실제로 필요한 목적지와 포트만 허용하는 것이 권장된다. 예를 들어 DB 인스턴스의 아웃바운드를 제한하면, 만약 인스턴스가 침해되더라도 공격자가 외부로 데이터를 유출하기 어려워진다.

역할 기반 그룹 분리

리소스의 역할별로 보안 그룹을 분리하면 관리가 용이해진다. 웹 서버, 애플리케이션 서버, 데이터베이스 각각에 별도의 보안 그룹을 부여하고, SG 참조로 연결하면 3계층 아키텍처의 트래픽 흐름을 명확하게 제어할 수 있다.

공통 규칙(예: SSH 접근, 모니터링 에이전트 포트)은 별도의 공통 보안 그룹으로 분리한 뒤, 각 인스턴스에 역할별 SG와 공통 SG를 함께 할당하면 규칙 중복을 방지할 수 있다.

NACL과의 심층 방어

보안 그룹만으로도 충분한 접근 제어가 가능하지만, NACL과 조합하면 심층 방어Defense in Depth를 구현할 수 있다. 보안 그룹이 인스턴스 레벨에서 정밀한 화이트리스트 접근 제어를 담당하고, NACL이 서브넷 경계에서 악성 IP 차단과 같은 광범위한 가드레일 역할을 수행하는 이중 구조다.

출처

Footnotes

  1. ENI(Elastic Network Interface) — EC2 인스턴스에 부착되는 가상 네트워크 인터페이스다. 프라이빗 IP, 퍼블릭 IP, MAC 주소, 보안 그룹 등의 속성을 갖는다. 하나의 인스턴스에 여러 ENI를 부착할 수 있다. ↩

  2. 클라이언트가 서버에 연결할 때 운영체제가 동적으로 할당하는 소스 포트다. 보통 1024~65535 범위에서 선택된다. ↩

  3. 네트워크를 세밀한 단위로 분할하여 각 구간의 트래픽을 독립적으로 제어하는 보안 전략이다. 전통적인 경계 기반 보안과 달리, 내부 네트워크 안에서도 리소스 간 최소 권한 접근을 적용한다. ↩