스터디를 통해 팀 근두운 인프라가 조금씩 단순 기능 구현이 아닌, 운영에 가까운 아키텍처 구조를 갖춰나가고 있다.
현재 우리는 서비스 기능별로 VPC를 분리하는 구조로 인프라를 설계 중에 있으며, 크게 공격용 Kali Linux가 위치하는 VPC(공격 VPC), 플랫폼 서비스를 제공하는 VPC(서비스 VPC), Wazuh와 Velociraptor 보안 도구를 운영하는 VPC(CERT VPC)로 분리할 계획이다. 그리고, 공격 과정에서 발생하는 보안 이벤트 전 과정을 확인하기 위해 Kali Linux와 WEB/WAS 서버에 Agent를 설치 하고자 한다.
이제 여기서 고민이 시작 됐다.
기존 인프라 구성은 하나의 VPC에서 Subnet으로만 기능을 분리했었기 때문에, 각 보안 Agent와 Server 간의 통신을 보안그룹 정책으로만 커버하면 됐다. 하지만, 지금은 VPC가 분리되어 있어 보안그룹 정책만으로는 사설 IP 간 통신을 구현할 수가 없다.
그렇게 방법을 찾아 보던 중 AWS 서비스에서 서로 다른 VPC간의 연결을 지원하는 기능들을 발견하게 되었다. 그런데, 방법이 또 세 가지나 있어 어떤 방식을 근두운 인프라에 적용하는게 좋을지 고민하는 과정을 글로 남기려고 한다.
VPC간 통신 서비스에 대해 살펴보기 전, 현재 팀 근두운 인프라 네트워크 구성을 확인한다.
VPC 간의 통신을 지원하는 세 가지 방식의 특징에 대해 살펴본다.
VPC 피어링은 서로 다른 두 개의 VPC를 직접 연결하여, 두 VPC 간의 트래픽을 사설 IP로 전송할 수 있도록 해준다. 한 쌍의 VPC만 피어링 연결을 맺을 수 있어, 여러 VPC 간의 연결이 필요하면 각 VPC마다 별도의 피어링 연결을 설정해 주어야 한다. 그리고, VPC 피어링은 단방향 통신과 양방향 통신 모두 지원하며, 이는 라우팅 테이블과 보안그룹을 어떻게 정의 하느냐에 따라 달라진다.
피어링 연결 설정은 동일 계정 또는 다른 계정, 동일 리전 또는 다른 리전 간의 설정도 가능하며, 피어링 요청자 VPC(Requester)와 수락자 VPC(Accepter)로 구분 된다. 동일 계정 내에서는 내가 요청하고 내가 수락하는 것이기 때문에, 어떤 VPC를 요청자로 정할지는 큰 의미가 없다.
피어링 연결 설정 예시 Terraform 코드를 작성하면, 다음과 같은 구조가 된다.
resource "aws_vpc_peering_connection" "peering" {
peer_vpc_id = <수락자 VPC ID>
vpc_id = <요청자 VPC ID>
auto_accept = true # 자동 수락 여부
}
피어링 생성이 끝나면, 라우트 테이블에서 피어링 경로를 허용해 연결을 완성해야 한다.
즉, VPC 피어링에서 서로 다른 VPC 간 통신을 구성하기 위해서는 연결할 VPC 간의 피어링을 먼저 생성해 주고, 실제 통신할 서브넷 또는 인스턴스 사설 IP주소를 라우트 테이블에 정의해주면 된다.
실제 트래픽이 허용 되려면, 보안그룹 설정도 반드시 필요하다.