[도서] Amazon VPC - 6장: 우리가 만들어 나갈 네트워크 공간

VPC의 퍼블릭 CIDR 전략과 보안 위협

온프레미스 환경에서는 퍼블릭 서버들이 고정된 CIDR 하나를 공유하는 경우가 많다. 그래서 해커 입장에서는 취약한 호스트를 하나 찾으면 그 IP가 속한 CIDR 전체를 스캔하고, 같은 대역에서 더 많은 정보를 뽑아내는 방식이 통한다.

근데 Amazon VPC는 이 공식이 안 먹힌다. VPC는 퍼블릭 CIDR에 구속되지 않아서, 인스턴스가 필요할 때만 퍼블릭 IP를 그때그때 붙일 수 있다. 책에 나오는 예시를 보면, 같은 퍼블릭 서브넷 안에 놓인 인스턴스 2개의 퍼블릭 IP가 15.177.76.130과 3.34.198.67로 전혀 다른 CIDR에 속한다. 프라이빗 IP는 92.75.100.0/24로 동일한 대역이지만 퍼블릭 IP는 제각각이다. 즉, 15.177.76.234를 공격해봤자 15.177.76.130과 같은 VPC라는 정보를 전혀 유추할 수 없다.

KISA 후이즈로 15.177.0.0/16을 조회하면 Amazon Technologies Inc.라는 게 나온다. VPC의 퍼블릭 CIDR 전략을 아는 공격자라면 그 대역 전체를 긁어봐야 의미 없다는 걸 알기 때문에, 온프레미스 대비 정찰 단계부터 난이도가 올라간다. VPC를 쓰는 것만으로도 공격자의 정보 수집 경로 하나가 막히는 셈이다.

기본 VPC(Default VPC)를 삭제해야 하는 이유

AWS 계정을 처음 만들면 모든 리전에 기본 VPC가 자동으로 깔려 있다. 서울 리전 기준으로 가용 영역마다 퍼블릭 서브넷 4개, 그리고 보안 그룹, 네트워크 ACL, Route Table이 미리 세팅돼 있다. 인스턴스를 만들기만 하면 바로 인터넷에 연결되는 편의 구조다.

문제는 이 기본 보안 그룹의 규칙이다. 인바운드 쪽을 보면 같은 보안 그룹 멤버면 모든 트래픽이 허용되고, 아웃바운드는 0.0.0.0/0으로 모든 목적지에 전송 가능하다. 아웃바운드 기본 규칙이 이렇게 열려 있으면 악성코드에 감염된 인스턴스가 C&C 서버로 데이터를 마음껏 보낼 수 있다. 온프레미스도 마찬가지라고 명시되어 있다.

보안 그룹은 수명 주기 동안 네트워크 인터페이스에 계속 붙어있고, 어느 인스턴스에 연결됐는지 콘솔에서 한눈에 파악하기 어렵다. 기본 보안 그룹 자체는 삭제가 안 되지만, 규칙을 전부 지우는 방식으로 관리해야 한다. 그리고 프로덕션 환경이라면 기본 VPC를 아예 삭제하고 직접 만든 VPC에서 시작하는 걸 권장한다. 기본 VPC를 그냥 두면 연쇄적으로 불필요한 리소스가 살아있게 되고, 어느 순간 거기서 인스턴스를 띄웠다가 의도치 않게 열린 네트워크 위에서 서비스가 올라가는 상황이 생긴다.

서브넷 우회 경로 문제

서브넷은 VPC의 CIDR 공간을 나눠 담는 논리 네트워크인데, 단순히 IP 대역을 쪼개는 것 이상의 역할을 한다. 서브넷 존재 이유 자체가 네트워크 인터페이스를 담는 그릇이고, VPC의 보안 3요소인 보안 그룹, 네트워크 ACL, Route Table이 이 네트워크 인터페이스 단위로 작동하기 때문이다.

그런데 서버에 NIC가 2개 이상 붙어있으면 얘기가 달라진다. 예를 들어 DB 서버가 방화벽을 거치지 않고 자기 NIC로 직접 접근 가능한 퍼블릭 네트워크에 연결돼 있다면, 방화벽을 통해 트래픽을 유도하는 Route Table 설정이 있어도 NIC를 직접 타고 우회할 수 있다. 이걸 서브넷 우회 경로라고 부른다.

온프레미스에서도 서버의 NIC가 스위치에 연결되는 구조라 같은 문제가 생긴다. 보안을 중시하는 기업들이 사무실 PC조차 NIC 추가 장착을 통제하는 이유가 여기 있다. AWS에서 이 문제를 막으려면 DB 인스턴스를 프라이빗 서브넷에만 두고, 외부 접근은 반드시 방화벽이나 로드밸런서가 있는 경로의 Route Table을 통해서만 오도록 설계해야 한다. 서브넷의 포함 관계를 파악하는 게 AWS의 네트워크 보안 전체 그림을 이해하는 출발점인 이유가 바로 이것이다.