# Security Group ## 소개글 > [!abstract] Introduction > [[VPC 라우팅과 게이트웨이|라우팅 테이블과 게이트웨이]]가 트래픽의 경로를 결정한다면, Security Group은 그 경로 위에서 어떤 트래픽을 허용할지를 결정한다. Security Group은 VPC 내 리소스의 네트워크 인터페이스에 적용되는 가상 방화벽으로, 허용 규칙만으로 동작하는 포지티브 보안 모델과 연결 상태를 추적하는 Stateful 속성이 핵심이다. 이 포스트에서는 Security Group의 작동 원리, 참조 기반 접근 제어, 그리고 연결 추적의 성능 특성을 다룬다. ## 개념과 적용 범위 Security Group은 VPC 내 리소스의 네트워크 인터페이스(ENI)[^elastic-network-interface]에 적용되는 가상 방화벽이다. EC2, RDS, ELB 등 VPC 안에서 실행되는 거의 모든 리소스에 적용할 수 있다. 핵심은 Security Group이 서브넷이나 VPC 단위가 아닌, 개별 ENI 단위에서 작동한다는 점이다. 동일한 서브넷 안에 있는 두 인스턴스라도 서로 다른 Security Group을 할당받아 상이한 트래픽 정책을 적용받을 수 있다. [^elastic-network-interface]: ENI(Elastic Network Interface) — EC2 인스턴스에 부착되는 가상 네트워크 인터페이스다. 프라이빗 IP, 퍼블릭 IP, MAC 주소, Security Group 등의 속성을 갖는다. 하나의 인스턴스에 여러 ENI를 부착할 수 있다. 하나의 인스턴스에 여러 개의 Security Group을 동시에 할당할 수 있으며, 이 경우 모든 규칙이 합집합(*aggregate*) 형태로 적용된다. 어떤 Security Group의 규칙이든 하나라도 트래픽을 허용하면 해당 트래픽은 통과한다. ## Stateful 동작 Security Group의 가장 큰 기술적 특징은 상태 저장(*Stateful*) 속성이다. 이는 연결의 상태를 추적하여, 요청이 허용되면 응답은 별도의 규칙 없이 자동으로 허용된다는 것을 의미한다. ```mermaid sequenceDiagram participant EXT as 외부 클라이언트 participant SG as Security Group 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]: 임시 포트(Ephemeral Port) — 클라이언트가 서버에 연결할 때 운영체제가 동적으로 할당하는 소스 포트다. 보통 1024~65535 범위에서 선택된다. 이와 대비되는 것이 [[NACL]]의 Stateless 동작이다. NACL은 연결 상태를 추적하지 않으므로, 인바운드를 허용하더라도 응답에 사용되는 임시 포트 범위를 아웃바운드 규칙에서 명시적으로 열어줘야 한다. ## 허용 전용 정책 Security Group은 포지티브 보안 모델(*positive security model*)을 따른다. 첫째, 암시적 거부(*Implicit Deny*). Security Group 생성 직후에는 인바운드 규칙이 없으므로 모든 인바운드 트래픽이 차단된다. 명시적으로 허용 규칙을 추가해야만 트래픽이 통과한다. 둘째, 허용 규칙만 존재한다. '거부(Deny)' 규칙은 생성할 수 없다. 특정 IP를 차단하려면 [[NACL]]이나 AWS WAF 같은 다른 계층의 도구를 사용해야 한다. 셋째, 기본 아웃바운드 허용. 새로 생성된 Security Group은 모든 아웃바운드 트래픽(`0.0.0.0/0`)을 허용하는 규칙을 포함한다. 보안 강화를 위해 이 규칙을 삭제하고 필요한 목적지만 허용하도록 축소할 수 있다. ## Security Group 참조 Security Group의 가장 강력한 기능은 IP 주소 대신 다른 Security Group의 ID를 소스로 참조할 수 있다는 점이다. 예를 들어, DB Security Group의 인바운드 규칙에서 소스를 `sg-web`(웹 서버 Security Group의 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)은 불가능하다. 이것이 Security Group으로 구현하는 마이크로 세그멘테이션(*micro-segmentation*)[^micro-segmentation]이다. [^micro-segmentation]: 마이크로 세그멘테이션(Micro-segmentation) — 네트워크를 세밀한 단위로 분할하여 각 구간의 트래픽을 독립적으로 제어하는 보안 전략이다. 전통적인 경계 기반 보안과 달리, 내부 네트워크 안에서도 리소스 간 최소 권한 접근을 적용한다. ### VPC 피어링 환경에서의 참조 Security Group 참조는 동일 VPC 내에서만 가능한 것이 아니다. [[VPC 연결 전략 — Peering과 Transit Gateway|VPC 피어링]]으로 연결된 다른 VPC의 Security Group도 참조할 수 있다. 피어링된 VPC의 Security Group ID를 소스나 대상에 지정하면, VPC 경계를 넘어서도 IP 주소 없이 동적 접근 제어가 가능하다. 다만, Transit Gateway로 연결된 VPC 간에는 Security Group 참조가 지원되지 않는다. 이 경우에는 IP 기반(CIDR)으로 규칙을 작성해야 한다. ## 연결 추적과 성능 Security Group의 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{"인바운드 + 아웃바운드\n모두 0.0.0.0/0?"} B -- "예" --> C["비추적 연결\n(Untracked)\n성능 최적화"] B -- "아니오" --> D{"규칙에 매칭?"} D -- "예" --> E["추적 연결\n(Tracked)\nStateful 동작"] D -- "아니오" --> F["거부"] ``` 비추적 연결은 연결 추적 테이블을 사용하지 않으므로 `conntrack_allowance_exceeded` 이벤트에 영향을 주지 않는다. 대량의 연결을 처리하는 NAT 인스턴스나 로드 밸런서에서 이 특성을 활용할 수 있다. ## Security Group 설계 원칙 ### 최소 권한 원칙 Security Group 설계의 출발점은 최소 권한 원칙(*Principle of Least Privilege*)이다. 기본 아웃바운드 규칙(`0.0.0.0/0` 전체 허용)을 삭제하고, 실제로 필요한 목적지와 포트만 허용하는 것이 권장된다. 예를 들어 DB 인스턴스의 아웃바운드를 제한하면, 만약 인스턴스가 침해되더라도 공격자가 외부로 데이터를 유출하기 어려워진다. ### 역할 기반 그룹 분리 리소스의 역할별로 Security Group을 분리하면 관리가 용이해진다. 웹 서버, 애플리케이션 서버, 데이터베이스 각각에 별도의 Security Group을 부여하고, SG 참조로 연결하면 3계층 아키텍처의 트래픽 흐름을 명확하게 제어할 수 있다. 공통 규칙(예: SSH 접근, 모니터링 에이전트 포트)은 별도의 공통 Security Group으로 분리한 뒤, 각 인스턴스에 역할별 SG와 공통 SG를 함께 할당하면 규칙 중복을 방지할 수 있다. ### NACL과의 심층 방어 Security Group만으로도 충분한 접근 제어가 가능하지만, [[NACL]]과 조합하면 심층 방어(*Defense in Depth*)를 구현할 수 있다. Security Group이 인스턴스 레벨에서 정밀한 화이트리스트 접근 제어를 담당하고, NACL이 서브넷 경계에서 악성 IP 차단과 같은 광범위한 가드레일 역할을 수행하는 이중 구조다. ```mermaid flowchart LR INET["인터넷"] --> NACL["NACL\n(서브넷 경계)\n악성 IP 차단"] NACL --> SG["Security Group\n(인스턴스 경계)\n앱별 정밀 접근 제어"] SG --> EC2["EC2 인스턴스"] ``` ## 정리 Security Group은 VPC 보안의 핵심 도구다. ENI 단위의 정밀한 적용, Stateful한 연결 추적, 허용 전용 정책의 세 가지 속성이 결합되어, 복잡한 클라우드 환경에서도 직관적이면서 강력한 접근 제어를 가능하게 한다. 특히 SG 참조 기능은 IP 주소에 의존하지 않는 동적 접근 제어를 실현하여, 오토스케일링 환경에서 진가를 발휘한다. 서브넷 경계에서의 Stateless 방화벽인 [[NACL]]과 비교하면 Security Group의 위치와 역할이 더 명확해진다. 두 메커니즘의 차이와 조합 전략은 [[NACL]] 포스트에서 자세히 다룬다. --- ## 출처 - 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