[인프라진단] #CA-07 VPC 네트워크 서브넷 관리

1. 항목 설명

단일 가상 네트워크에서 공개용 네트워크와 내부 네트워크를 혼용하지 않고 역할에 맞게 분리하여 사용하는지 점검하는 항목입니다.

판단 기준은 공개용 네트워크와 내부 네트워크를 분리한 경우 양호, 분리하지 않은 경우 취약입니다.

2026 가이드 근거

출처: 과학기술정보통신부·한국인터넷진흥원, 「2026 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드」, CA-07, p.860.
본 게시글은 위 가이드의 판단 기준을 참고하여 작성했으며, 진단 결과와 증적은 개인 실습 환경에서 직접 수집했습니다.

2. 점검 목적

공개 서비스와 내부 서비스의 네트워크 경로를 분리하여 내부 리소스가 인터넷 게이트웨이 경로에 노출되거나 공개 영역의 침해가 내부 영역으로 확산되는 위험을 줄이는 것이 목적입니다.

3. 실습 환경

• 클라우드: 개인 AWS 실습 계정
• 작업 도구: AWS Management Console, AWS CloudShell, AWS CLI
• 실습 VPC: ca-lab-20260611-mixed-vpc
• 공개용 서브넷: ca-lab-20260611-public-subnet
• 내부용 예정 서브넷: ca-lab-20260611-intended-private-subnet
• 과금 방지: EC2, NAT Gateway, Elastic IP, 공인 IP를 생성하지 않음
• 외부 노출 방지: 서브넷에 실제 서비스 리소스를 배치하지 않음

실습·비용·안전 고지

본 항목은 N/A 처리하지 않고 VPC·서브넷·라우팅 연결을 실제 변경하여 진단합니다. EC2·NAT Gateway·공인 IP는 생성하지 않으며, 운영 환경에서 요구되는 NAT 구성 대신 인터넷 경로가 없는 내부용 서브넷 분리 상태를 검증합니다. 세부 원칙은 본 시리즈의 「AWS 실습 환경 구축 프롤로그」에 정리한 비용·안전 기준을 따릅니다.

4. 취약 상태 구성

공개용 서브넷과 내부용 예정 서브넷을 하나의 VPC에 생성한 뒤, 두 서브넷을 모두 인터넷 게이트웨이 기본 경로가 존재하는 동일한 라우팅 테이블에 연결합니다. 내부용 예정 서브넷이 공개용 네트워크 경로를 함께 사용하므로 분리되지 않은 취약 상태입니다.

aws ec2 create-vpc --cidr-block 10.206.0.0/16
aws ec2 create-subnet --vpc-id <VPC_ID> --cidr-block 10.206.1.0/24
aws ec2 create-subnet --vpc-id <VPC_ID> --cidr-block 10.206.2.0/24
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --internet-gateway-id <IGW_ID> --vpc-id <VPC_ID>
aws ec2 create-route --route-table-id <PUBLIC_RT_ID> --destination-cidr-block 0.0.0.0/0 --gateway-id <IGW_ID>
aws ec2 associate-route-table --route-table-id <PUBLIC_RT_ID> --subnet-id <PUBLIC_SUBNET_ID>
aws ec2 associate-route-table --route-table-id <PUBLIC_RT_ID> --subnet-id <PRIVATE_SUBNET_ID>

확인 방법:

aws ec2 describe-route-tables --filters "Name=vpc-id,Values=<VPC_ID>" --output json

내부용 예정 서브넷이 0.0.0.0/0 → Internet Gateway 경로가 있는 라우팅 테이블에 연결되어 있으면 취약입니다.

5. 최초진단 결과

• 최초진단 판정: 취약
• 판정 조건: 공개용·내부용 예정 서브넷이 동일한 인터넷 라우팅 테이블을 사용하는 경우
• 실제 확인 결과: 두 서브넷이 0.0.0.0/0 인터넷 경로가 있는 shared-public-rt에 함께 연결됨
• 실제 최초진단 증적 파일: ca06_ca10_initial_diagnosis.txt

6. 조치 방법

내부용 예정 서브넷을 인터넷 기본 경로가 없는 별도 라우팅 테이블로 분리합니다. 본 무료 실습에서는 과금 방지를 위해 NAT Gateway를 만들지 않습니다.

aws ec2 create-route-table --vpc-id <VPC_ID>
aws ec2 replace-route-table-association \
  --association-id <PRIVATE_SUBNET_ROUTE_ASSOCIATION_ID> \
  --route-table-id <PRIVATE_ROUTE_TABLE_ID>

클라우드 콘솔 경로: VPC → 라우팅 테이블 → ca-lab-20260611-private-rt → 서브넷 연결·라우팅

UI 증적 재수집(2026-08-25): 내부용 서브넷이 전용 프라이빗 라우팅 테이블에 명시적으로 연결되고 인터넷 게이트웨이 기본 경로가 없는 상태를 실제 AWS 콘솔에서 재확인했습니다.

7. 이행진단 결과

• 이행진단 판정: 양호
• 판정 조건: 내부용 예정 서브넷이 인터넷 기본 경로가 없는 별도 라우팅 테이블을 사용하는 경우
• 실제 확인 결과: 내부용 예정 서브넷은 private-rt, 공개용 서브넷은 shared-public-rt에 연결됨
• 실제 이행진단 증적 파일: ca06_ca10_after_diagnosis.txt

8. 실무 주의사항

라우팅 테이블 연결을 변경하면 애플리케이션의 외부 API 호출, 패키지 업데이트, 인증, 모니터링, 백업 전송이 중단될 수 있습니다. 내부 서브넷의 아웃바운드 요구사항과 VPC 엔드포인트·NAT·프록시 사용 여부를 확인한 후 변경해야 합니다.

컨설턴트 조언

• 담당자 인터뷰에서 서브넷별 서비스 역할, 외부 통신 필요성, 인터넷 경로, 변경 승인자와 장애 대응 절차를 확인합니다.
• VPC·서브넷 목록, 라우팅 테이블 연결, 인터넷/NAT 게이트웨이, 네트워크 ACL과 구성도를 증적으로 확보합니다.
• 공개용·내부용 리소스가 같은 서브넷 또는 동일한 공개 라우팅 경로를 사용하는지 확인합니다.
• 운영 환경에서 NAT Gateway를 제거하거나 경로를 변경하기 전 외부 통신 의존성을 검증합니다.
• 즉시 분리가 어려우면 보안 그룹, NACL, VPC 엔드포인트, 프록시, 방화벽과 모니터링을 보완 통제로 적용합니다.

9. 마무리

서브넷 이름만 Public 또는 Private로 구분하는 것은 충분하지 않습니다. 실제 연결된 라우팅 테이블과 인터넷 경로를 기준으로 네트워크 분리 상태를 검증해야 합니다.