[AWS 하드닝 03] 같은 VPC니까 안전할까요? 보안 그룹과 서브넷 경계

Об этом предложении

웹 서버, 배치 서버, 데이터베이스를 한 VPC에 넣었다고 서로의 포트를 모두 열어 줄 필요는 없습니다. 서버 하나가 침해됐을 때 다른 역할의 서버까지 쉽게 도달하면, 사설 주소 안에서도 피해가 넓어질 수 있습니다. 이번에는 애플리케이션에서 데이터베이스로 필요한 연결만 남기는 방법 을 살펴보겠습니다. 기존 AWS 시리즈 에서 서비스별 역할을 정리한 데 이어, 이번에는 정상 업무를 유지하면서 접근 범위를 줄이는 방법을 살펴봅니다. IP 주소, TCP 포트, VPC를 알고 있으면 읽을 수 있습니다. 그림과 예제는 실제 계정 구성이 아닌 학습용입니다. 라우팅과 허용 규칙은 함께 봅니다 퍼블릭 서브넷은 인터넷 게이트웨이로 직접 연결되는 경로가 있는 서브넷입니다. 그 이름만으로 모든 인스턴스에 퍼블릭 IPv4가 붙거나 모든 포트가 열리는 것은 아닙니다. 리소스의 주소, 라우팅, 보안 그룹 등 접근에 필요한 조건을 함께 봐야 합니다. 프라이빗 서브넷에도 NAT나 연결된 네트워크를 통한 경로가 있을 수 있습니다. VPC 서브넷과 라우팅 보안 그룹은 연결된 리소스의 허용 트래픽을 정합니다. 허용 규칙만 있으며 명시적 거부 규칙을 넣는 방식이 아닙니다. 여러 그룹을 연결하면 허용 범위가 합쳐지므로, 한 그룹을 좁혔다고 다른 그룹의 넓은 허용이 사라지지 않습니다. 보안 그룹은 상태를 추적하며 허용된 연결의 응답 트래픽을 처리합니다. 보안 그룹 동작 그림은 데이터베이스의 인바운드 범위를 묻습니다. 애플리케이션이 인터넷으로 내보내는 트래픽이나 다른 VPC 연결까지 검증한 그림은 아닙니다. 주소 전체 대신 역할을 연결하기 아래 JSON은 CloudFormation AWS::EC2::SecurityGroup 의 리소스 조각입니다. VPC와 애플리케이션 보안 그룹은 가상 ID입니다. 이 조각은 운영용 전체 템플릿이 아니며, DB로 들어오는 규칙 에 집중했습니다. { "Type": "AWS::EC2::SecurityGroup", "Properties": { "GroupDescription": "Study database ingress from app role", "VpcId": "vpc-0123456789abcdef0", "SecurityGroupIngress": [{ "IpProtocol": "tcp", "FromPort": 5432, "ToPort": 5432, "SourceSecurityGroupId": "sg-0123456789abcdef0" }] } } 5432 는 예제의 PostgreSQL 포트입니다. 같은 VPC 안에서 애플리케이션용 보안 그룹을 출처로 지정했습니다. 이 참조는 해당 그룹과 연결된 네트워크 인터페이스의 트래픽을 구분하기 위한 것이며, 출처 그룹의 규칙을 복사하는 기능이 아닙니다. DB의 사용자 인증이나 SQL 권한도 대신하지 않습니다. CloudFormation 보안 그룹 필드 이 예제는 아웃바운드 규칙을 생략했습니다. 새 보안 그룹의 기본 아웃바운드 허용을 제한하는 완성 예제로 읽으면 안 됩니다. 실제 적용에서는 응답과 새 연결을 구분하고, 의존 서비스의 통신도 함께 설계합니다. NACL은 같은 방화벽의 다른 이름일까요? 네트워크 ACL은 서브넷에 적용되는 허용·거부 규칙입니다. 상태를 추적하지 않으므로 응답 방향도 별도로 확인해야 합니다. 규칙 번호 순으로 첫 일치 규칙이 적용됩니다. 보안 그룹의 규칙을 그대로 복사하면 응답 포트가 막혀 연결이 실패할 수 있습니다. 네트워크 ACL 규칙 계층을 하나 더 쓰는 것과 이해하지 못한 규칙을 늘리는 것은 다릅니다. 필요한 통신 표를 먼저 적고, 추가 경계가 어떤 위험을 줄이는지 설명할 수 있을 때 적용합니다. 보안 그룹과 NACL이 IMDS나 기본 DNS를 모든 경우에 차단하는 수단이라고 가정하지도 않습니다. 적용 순서와 확인 출처 역할, 대상 역할, 프로토콜, 포트를 표로 적습니다. 테스트 DB에 좁은 규칙을 적용하고 애플리케이션의 정상 연결을 확인합니다. 다른 역할의 서버에서는 같은 DB 포트가 연결되지 않는지 확인합니다. 모든 연결된 보안 그룹, 라우팅과 IPv6 규칙까지 확인합니다. 변경 중 장애가 나면 바꾼 그룹 규칙이나 연결만 이전 상태로 되돌립니다. 0.0.0.0/0 로 모든 포트를 열어 임시 해결하는 방식은 원인을 확인하기 어렵게 만듭니다. 실제 점검에서 Flow Logs는 연결 정보의 근거가 될 수 있지만 애플리케이션의 DB 로그인 성공까지 증명하지는 않습니다. 로컬 검증: JSON 구문과 TCP 5432 한 포트, 보안 그룹 출처 참조를 검사했습니다. 출처를 인터넷 전체 CIDR로 바꾼 반례는 학습용 기준에서 거부했습니다. 실제 VPC 라우팅, 보안 그룹 연결 상태, 패킷 송수신은 시험하지 않았습니다. 확인 문제 프라이빗 서브넷이면 DB 사용자 인증을 생략해도 될까요? 좁은 그룹과 넓은 그룹을 함께 연결하면 좁은 그룹이 우선할까요? NACL에서 요청만 허용했는데 응답이 막히는 이유는 무엇인가요? 답과 해설 아닙니다. 네트워크 경계와 데이터 접근 권한은 함께 필요합니다. 아닙니다. 그룹들의 허용 규칙을 함께 평가해야 합니다. NACL은 상태를 추적하지 않아 응답 방향의 규칙도 필요합니다. 복습 오늘은 웹→앱→DB의 포트를 각각 적어 보세요. 내일은 앱 그룹 참조를 다른 그룹으로 바꾸면 어떤 연결이 달라질지 설명해 보세요. 일주일 뒤에는 EC2 관리 접속과 메타데이터 접근을 같은 경계로 막을 수 있는지 다시 생각해 보세요. 확인일: 2026-10-04, 한국 시간 . VPC 보안 그룹·NACL 및 CloudFormation 필드 기준입니다. 다음 글은 EC2의 관리 경로와 IMDSv2입니다.