> [!abstract] Introduction > [[VPC Routing & Gateway#라우팅 테이블|라우팅 테이블과 게이트웨이]]가 트래픽의 경로를 결정한다면, Security Group은 그 경로 위에서 어떤 트래픽을 허용할지를 결정합니다. Security Group은 VPC 내 리소스의 네트워크 인터페이스에 적용되는 가상 방화벽으로, 허용 규칙만으로 동작하는 포지티브 보안 모델과 연결 상태를 추적하는 Stateful 속성이 핵심입니다. 이 글에서는 Security Group의 작동 원리, 참조 기반 접근 제어, 그리고 연결 추적의 성능 특성을 살펴봅니다. # 보안 그룹이란? 보안 그룹*Security Group*은 VPC 내 리소스의 네트워크 인터페이스(ENI)[^elastic-network-interface]에 적용되는 가상 방화벽이다. EC2, RDS, ELB 등 VPC 안에서 실행되는 거의 모든 리소스에 적용할 수 있다. 핵심은 보안 그룹이 서브넷이나 VPC 단위가 아닌, 개별 ENI 단위에서 작동한다는 점이다. 동일한 서브넷 안에 있는 두 인스턴스라도 서로 다른 보안 그룹을 할당받아 상이한 트래픽 정책을 적용받을 수 있다. [^elastic-network-interface]: ENI(Elastic Network Interface) — EC2 인스턴스에 부착되는 가상 네트워크 인터페이스다. 프라이빗 IP, 퍼블릭 IP, MAC 주소, 보안 그룹 등의 속성을 갖는다. 하나의 인스턴스에 여러 ENI를 부착할 수 있다. 하나의 인스턴스에 여러 개의 보안 그룹을 동시에 할당할 수 있으며, 이 경우 모든 규칙이 합집합*aggregate* 형태로 적용된다. 어떤 보안 그룹의 규칙이든 하나라도 트래픽을 허용하면 해당 트래픽은 통과한다. ## Stateful 동작 보안 그룹의 가장 큰 기술적 특징은 상태 저장(*Stateful*) 속성이다. 이는 연결의 상태를 추적하여, 요청이 허용되면 응답은 별도의 규칙 없이 자동으로 허용된다는 것을 의미한다. ```mermaid sequenceDiagram participant EXT as 외부 클라이언트 participant SG as 보안 그룹 participant EC2 as EC2 인스턴스 EXT->>SG: 인바운드 요청 (HTTPS 443) Note over SG: 인바운드 규칙 확인 SG->>EC2: 전달 EC2->>SG: 응답 (임시 포트) Note over SG: 상태 테이블 확인<br/>→ 기존 연결의 응답이므로<br/>아웃바운드 규칙 무시 SG->>EXT: 전달 ``` 이 동작 덕분에 관리자는 응답 트래픽이 사용하는 임시 포트*ephemeral port*(1024~65535)[^ephemeral-port] 범위를 별도로 개방할 필요가 없다. 웹 서버의 인바운드 `443` 포트만 열어두면, 그에 대한 응답은 어떤 포트를 사용하든 자동으로 통과한다. [^ephemeral-port]: 클라이언트가 서버에 연결할 때 운영체제가 동적으로 할당하는 소스 포트다. 보통 1024~65535 범위에서 선택된다. 이와 대비되는 것이 [[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)[^micro-segmentation]이다. [^micro-segmentation]: 네트워크를 세밀한 단위로 분할하여 각 구간의 트래픽을 독립적으로 제어하는 보안 전략이다. 전통적인 경계 기반 보안과 달리, 내부 네트워크 안에서도 리소스 간 최소 권한 접근을 적용한다. ### VPC 피어링 환경에서의 참조 보안 그룹 참조는 동일 VPC 내에서만 가능한 것이 아니다. [[Peering & Transit Gateway#VPC Peering|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`에 매칭된 트래픽은 추적된다. ```mermaid flowchart TD A["트래픽 도착"] --> B{"인바운드 + 아웃바운드<br/>모두 0.0.0.0/0?"} B -- "예" --> C["비추적 연결<br/>(Untracked)<br/>성능 최적화"] B -- "아니오" --> D{"규칙에 매칭?"} D -- "예" --> E["추적 연결<br/>(Tracked)<br/>Stateful 동작"] D -- "아니오" --> F["거부"] ``` 비추적 연결은 연결 추적 테이블을 사용하지 않으므로 `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 차단과 같은 광범위한 가드레일 역할을 수행하는 이중 구조다. ```mermaid flowchart LR INET["인터넷"] --> NACL["NACL<br/>(서브넷 경계)<br/>악성 IP 차단"] NACL --> SG["Security Group<br/>(인스턴스 경계)<br/>앱별 정밀 접근 제어"] SG --> EC2["EC2 인스턴스"] ``` --- ## 출처 - Amazon Web Services (2026) *Control traffic to your AWS resources using security groups.* Available at: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html - Amazon Web Services (2026) *Amazon EC2 security group connection tracking.* Available at: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html - Amazon Web Services (2026) *Security groups and network ACLs (BP5).* Available at: https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/security-groups-and-network-acls-bp5.html