퍼블릭 서브넷에 데이터베이스를 뒀다

상황

스타트업의 초기 인프라를 그대로 쓰고 있는 서비스입니다. VPC에 서브넷이 두 개뿐이고, 둘 다 라우팅 테이블에 인터넷 게이트웨이로 향하는 기본 경로가 있습니다. 애플리케이션 서버와 Amazon RDS 인스턴스가 같은 서브넷에 있습니다.

RDS 인스턴스는 퍼블릭 액세스가 켜진 상태로 만들어졌습니다. 당시 개발자가 사무실 노트북에서 직접 접속해 스키마를 만들어야 했기 때문입니다. 보안 그룹은 데이터베이스 포트에 대해 사무실 고정 IP 하나만 허용하고 있었고, 여기까지는 팀도 알고 있었습니다.

문제는 지난 분기에 생겼습니다.

• 재택근무가 늘면서 "임시로" 보안 그룹에 0.0.0.0/0 규칙이 추가되었고, 그 규칙이 지워지지 않았습니다.
• 서브넷의 MapPublicIpOnLaunch가 켜져 있어 새로 만든 인스턴스마다 퍼블릭 주소가 붙습니다.
• 데이터베이스 사용자 하나가 여전히 초기 설정 비밀번호를 쓰고 있었습니다.

보안 점검에서 데이터베이스 엔드포인트가 인터넷에서 조회 가능한 주소로 해석된다는 사실이 확인되었습니다. 유출 여부는 아직 확인되지 않았습니다.

노출은 세 조건의 결합이다

인터넷에서 데이터베이스에 도달하려면 아래 셋이 모두 성립해야 합니다. 하나만 끊어도 경로는 성립하지 않습니다. 그래서 처방을 고를 때 "어느 조건을 끊는가"로 이야기하면 논의가 명확해집니다.

# 1) 이 서브넷이 실제로 퍼블릭인지 — 라우팅 테이블의 경로를 본다
aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0123456789abcdef0 \
  --query 'RouteTables[].Routes[].[DestinationCidrBlock,GatewayId]' \
  --output table

# 2) 서브넷이 시작 시 퍼블릭 IP 를 자동 할당하는지
aws ec2 describe-subnets \
  --subnet-ids subnet-0123456789abcdef0 \
  --query 'Subnets[0].[SubnetId,MapPublicIpOnLaunch,AvailabilityZone]' \
  --output table

# 3) 데이터베이스가 퍼블릭 액세스로 설정되어 있는지
aws rds describe-db-instances \
  --db-instance-identifier shop-prod \
  --query 'DBInstances[0].[PubliclyAccessible,DBSubnetGroup.DBSubnetGroupName,Endpoint.Address]' \
  --output table

# 4) 어떤 소스가 데이터베이스 포트에 허용되어 있는지
aws ec2 describe-security-groups \
  --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[0].IpPermissions'

요구사항과 제약

배경 개념은 3장 VPC 네트워킹 기초와 4장 VPC 연결과 하이브리드에 있습니다.

후보 설계안 비교

보안 그룹과 네트워크 ACL의 역할 구분

B안이 왜 단독 해법이 아닌지는 두 통제의 성질 차이에서 나옵니다.

선택과 근거

D안 — 프라이빗 서브넷으로 옮기고, 퍼블릭 액세스를 끄고, 개발자 접속은 세션 기반 경로로 제공합니다.

근거는 하나로 요약됩니다. A안과 B안은 규칙에 의존하고, C·D안은 구조에 의존합니다. 규칙은 사람이 바꿀 수 있고 실제로 이 케이스에서 바뀌었습니다. 경로 자체가 없으면 규칙이 잘못 열려도 인터넷에서 도달할 수 없습니다.

목표 구성

데이터베이스 계층 서브넷에는 NAT 게이트웨이 경로조차 두지 않는 것이 기본입니다. 데이터베이스가 인터넷으로 나갈 이유가 없기 때문입니다. 패치는 관리형 서비스가 처리하고, 백업은 서비스 내부 경로로 갑니다.

보안 그룹을 CIDR이 아니라 보안 그룹으로 참조한다

데이터베이스 보안 그룹의 인바운드 소스를 애플리케이션 서버의 CIDR로 적으면, 서브넷을 늘리거나 인스턴스를 옮길 때마다 규칙을 고쳐야 합니다. 소스를 보안 그룹 ID로 지정하면 그 보안 그룹에 속한 리소스가 늘어나도 규칙은 그대로입니다.

# 잘못 추가된 전체 개방 규칙을 제거합니다.
aws ec2 revoke-security-group-ingress \
  --group-id sg-0db0000000000000d \
  --protocol tcp --port 3306 --cidr 0.0.0.0/0

# 소스를 CIDR 이 아니라 애플리케이션 계층의 보안 그룹으로 지정합니다.
aws ec2 authorize-security-group-ingress \
  --group-id sg-0db0000000000000d \
  --ip-permissions '[{
      "IpProtocol": "tcp",
      "FromPort": 3306,
      "ToPort": 3306,
      "UserIdGroupPairs": [{"GroupId": "sg-0app000000000000"}]
    }]'

프라이빗 서브넷으로 옮기기

# 프라이빗 서브넷만으로 DB 서브넷 그룹을 만듭니다.
# 서로 다른 가용 영역의 서브넷을 최소 두 개 넣습니다.
aws rds create-db-subnet-group \
  --db-subnet-group-name shop-private-subnets \
  --db-subnet-group-description "private subnets only" \
  --subnet-ids subnet-0aaa000000000000a subnet-0bbb000000000000b

# 퍼블릭 액세스를 끄고 서브넷 그룹을 교체합니다.
# 적용 시점은 유지 관리 창을 이용하거나 계획된 창에서 즉시 적용합니다.
aws rds modify-db-instance \
  --db-instance-identifier shop-prod \
  --no-publicly-accessible \
  --db-subnet-group-name shop-private-subnets \
  --apply-immediately

# 새로 만드는 서브넷이 퍼블릭 IP 를 자동 할당하지 않게 합니다.
aws ec2 modify-subnet-attribute \
  --subnet-id subnet-0aaa000000000000a \
  --no-map-public-ip-on-launch

개발자 접속 경로 (요구 3)

"임시로 열어 두는" 규칙이 재발의 원인이므로, 규칙을 열지 않고도 접속할 수 있는 경로를 미리 제공합니다.

어느 쪽을 고르든 원칙은 같습니다 — 사람이 접속하기 위해 인터넷 인바운드 포트를 열지 않습니다.

재발 방지 (요구 4)

• 탐지 — AWS Config 규칙으로 퍼블릭 액세스가 켜진 데이터베이스와 0.0.0.0/0이 허용된 보안 그룹을 상시 감시합니다.
• 차단 — 조직 수준에서 서비스 제어 정책으로 퍼블릭 액세스를 켜는 변경을 막는 것도 가능합니다.
• 가시성 — VPC 흐름 로그로 데이터베이스 인터페이스에 대한 거부·수락 기록을 남겨 둡니다. 다만 흐름 로그는 5-튜플과 수락·거부만 기록하고 페이로드는 남기지 않습니다. "통신 내용을 감사하라"는 요구에는 답이 되지 않습니다.

비용과 운영에 미치는 영향

데이터 전송 요금의 구조는 케이스 6 · 데이터 전송 요금이 예산을 넘겼다에서 자세히 다룹니다.

설계 체크리스트

네트워크 배치

• 서브넷이 퍼블릭인지 이름이 아니라 라우팅 테이블로 확인했다
• 데이터베이스 서브넷의 라우팅 테이블에 인터넷 게이트웨이 경로가 없다
• 데이터베이스 서브넷에 NAT 경로도 두지 않았다 (필요한 이유가 없다면)
• DB 서브넷 그룹이 프라이빗 서브넷만, 서로 다른 가용 영역으로 구성되어 있다
• 서브넷의 MapPublicIpOnLaunch가 프라이빗 계층에서 꺼져 있다
• NAT 게이트웨이를 가용 영역마다 두고 라우팅을 가용 영역별로 분리했다

접근 제어

• 데이터베이스의 퍼블릭 액세스 설정이 꺼져 있다
• 데이터베이스 보안 그룹의 인바운드 소스가 보안 그룹 ID다 (CIDR이 아니다)
• 0.0.0.0/0 인바운드 규칙이 데이터베이스·관리 포트에 없다
• 사람이 접속하는 경로가 인터넷 인바운드 포트를 열지 않는다
• 데이터베이스 사용자 비밀번호가 초기값이 아니며 관리 수단이 정해져 있다
• 저장 데이터 암호화와 전송 중 암호화가 켜져 있다

탐지와 재발 방지

• 퍼블릭 액세스와 전체 개방 규칙을 상시 감시하는 규칙이 있다
• VPC 흐름 로그를 켜고 보존 위치를 정했다
• "임시로 여는" 변경에 만료가 있다 (수동 규칙이 영구히 남지 않는다)

관련 시험 포인트

이어서 볼 곳

• 3장 · VPC 네트워킹 기초 CIDR 설계, 라우팅 테이블, 보안 그룹과 네트워크 ACL, 흐름 로그를 정면으로 다룹니다. 기본개념 · 도메인 1
• 4장 · VPC 연결과 하이브리드 VPC 엔드포인트와 PrivateLink로 인터넷을 거치지 않는 경로를 만드는 방법입니다. 기본개념
• 실습 1 · 3계층 VPC 직접 구성 퍼블릭·프라이빗 서브넷과 NAT, 라우팅을 CLI로 직접 만들어 봅니다. 실습 예제
• 실습 10 · VPC 엔드포인트로 S3 비공개 접근 게이트웨이 엔드포인트와 인터페이스 엔드포인트의 구현 위치 차이를 확인합니다. 실습 예제
• 케이스 1 · EC2에 액세스 키를 심어 배포했다 네트워크가 아니라 자격 증명 쪽에서 같은 종류의 노출이 어떻게 생기는지 비교합니다. 아키텍처 케이스
• 보안 아키텍처 설계 (30%) 가중치가 가장 큰 도메인의 출제 포인트와 함정을 정리했습니다. 시험 대비

공식 문서 출처

• Amazon VPC 사용 설명서 — VPC의 보안 — 보안 그룹과 네트워크 ACL의 적용 계층, 허용·거부 규칙 지원 여부, 상태 저장 여부 비교표
• Amazon VPC 사용 설명서 — 네트워크 ACL — 규칙이 번호 순서로 평가되고 반환 트래픽을 명시 허용해야 한다는 서술
• Amazon VPC 사용 설명서 — NAT 게이트웨이 — 지정한 서브넷에 네트워크 인터페이스를 만든다는 동작과 퍼블릭·프라이빗 NAT의 구분
• Amazon VPC 사용 설명서 — VPC 흐름 로그 — 기록되는 필드와 수락·거부 표시, 페이로드가 포함되지 않는다는 범위
• Amazon RDS 사용 설명서 — VPC의 DB 인스턴스 — DB 서브넷 그룹이 서로 다른 가용 영역의 서브넷을 포함해야 한다는 요건
• Amazon RDS API 레퍼런스 — CreateDBInstance — PubliclyAccessible의 엔드포인트 해석 동작과 DB 서브넷 그룹에 따른 기본값
• Amazon EC2 API 레퍼런스 — ModifySubnetAttribute — MapPublicIpOnLaunch 속성의 의미
• Amazon EC2 API 레퍼런스 — AuthorizeSecurityGroupIngress — 인바운드 소스를 CIDR 대신 보안 그룹으로 지정하는 방법