AWS Client VPN 기반 개발 트래픽 관리
대부분 Amazon Web Service 를 사용하고 있다는 업체 또는 서비스를 들여다 보면, 관리 트래픽을 Security Group으로 기본적인 접근을 제한하고, EC2 Instance의 경우 PEM Key 만으로 접근을 제어하는 경우가 허다했다. 가장 단순하면서도 명확한 제한 방법이나, 치명적인 문제점이 있다.
- 감사로그를 남길 수 없다 : 누가 언제 무슨 작업을 했는지 알 수 없다.
- 해당 IP(Security Group Inbound Source)를 함께 사용하는 경우 누군가를 차단할 수 없다.
- Root PEM 은 Global 하게 사용되거나, 교체하기 어렵다.
이러한 문제는 On-Promise 환경에서도 동일한 문제를 갖고 있다. 최근 KISA 에서 대규모 서비스에 대한 ISMS 인증이 의무화 되며 조금더 강력한 보안을 취하는 것 처럼 보이지만, 뚜껑을 열어보면 구색 맞추기에 지나지 않는 경우가 대부분이다. 관리자가 없거나. 네트워크 지식이 부족하거나. 기존 인프라를 특정 규격에 맞추기 어렵기 때문이다.
AWS 를 처음 시작하는 개인이나, 기업이 있다면 어떤 서비스를 사용하건간에 VPC (Virtual Private Cloud)내 Subnet 의 정책을 잘 세우고 시작할 것을 권장하고 있다. 이 정책은 추후 모든 서비스에 영향을 미치는 기준이 되기 때문이다. 기본적인 흐름은 반드시 다음과 같아야 한다 생각한다.
개발자/관리자 트래픽은 Management Subnet 을 경유하지 않고 직접 Subnet 에 접근할 수 없어야 한다. Network Management Subnet 은 모든 사용자 Traffic 을 관리 관제하는 영역이 된다. Subnet Structure 를 생각해보자. 지극히 개인적으로 기준을 4개로 두고 있다.
- Network Management Subnet : 전체 Amazon Web Service 를 관리/관제하는 핵심
- Public Service Subnet : 사용자를 서비스 서브넷.
- QA/Staging Subnet : 품질을 확인하고, 테스트를 하기 위한 서브넷.
- Development Subnet : 개발을 위한 서브넷
경우에 따라 QA 와 ST 를 나누는 경우가 있지만, 대부분 품질 검증 및 사전 확인을 한 네트워크 그룹에서 진행하는 경우가 대부분이다 보니, 이를 굳이 나눌 필요는 없다 생각한다. 16 Bit 의 앞자리를 보면 이 Subnet 의 중요도를 알 수 있고, 어떤 용도인지 대략 감이 오게 된다.
16 Bit Subnet 에는 뒷자리가 정의되어 있지 않다. 이유는간단. AWS/Cloud 가 Global Service 가 가능하기 때문에 지역 구분을 위해 사용한다. (단, 이러한 설계는 9개의 지역만 관리할 수 있기 때문에 20개가 넘는 지역을 모두 포함할 수 없다. 떄문에 10.33.0.0/16 을 North Virginia 가 아닌 North America 로 정의하고, 24 Bit 에서 추가 지역을 관리하고 있다.)
참고로, TOKYO 가 앞에 있는 이유는, 동아시아에서 가장 먼저. 가장 안정적으로 서비스를 전개하는 지역이기 때문이며, 이는 북미의 오레곤을 선택하는 이유와 같다. 난 그래서 TOKYO REGION을 좋아한다… (버지니아는 가격이 저렴하고, 우리나라와 친하기 때문에 사용하는 지역이니 … CES 등을 위해선 캘리포니아를 써야하고…)
24Bit Subnet 은 Subnet Type 을 정의하는데 사용한다. Network 는 2가지 Subnet 이 존재하며, 그 기준은 IGW(Internet Gateway) 가 있어 외부와 직접 통신을 할 수 있거나, 반드시 NAT 가 있어야 외부와 만날 수 있는 격리된 Subnet 이다. 개인적인 취향에 따라 다르나, IGW 가 있는 경우 1로 시작하고, NAT 가 필요한 경우 2로 시작하게끔 정의하고 있다. AV(Availability) Zone 이 늘어남에 따라 뒤 수가 함께 증가한다면 대응 가능하다.
3자리 중 2자리의 용도가 명확하다면, 가운데 숫자는? 바로 세부 지역이다. 앞서 말했을 때 북미(North America)는 다양한 Region 이 존재한다. 오레곤(1), 캘리포니아(2), 버지니아(3), 캐나다(4) …
대략적인 AWS VPC Subnet 구조가 완성됐다. 이 이야기를 쓸려고 한건 아니지만, 중요한건 기본 네트워크의 구조를 설계하고 접근해야 한다는것.
AWS Client VPN
AWS 는 VPC 에 Vlient VPN EndPoint를 생성함으로서 (개발자 또는 관리자의) 신뢰할 수 있는 트래픽 터널을 구성할 수 있다. AWS VPN 은 Client VPN 뿐만 아니라, Site to Site VPN 을 제공하고 있으며, AWS VPN 을 추천하는 이유는 ‘관리’의 관점에서 편리하기 때문이다.
VPN 도입을 주저하는 이유 대부분이 설치 및 관리하기가 어렵다는데 공통적 사유가 있기 때문인데, AWS VPN 은 Web Console 만으로 모든것을 일사천리로 진행할 수 있다. 전반적인 구축 방법은 개인 NAS 에서 VPN 환경을 구축하는것과 큰 차이가 없다. 단, VPC 의 개념이 추가된 것일 뿐. AWS VPN 의 특징은 다음과 같이 요약할 수 있다.
- OpenVPN (OpenSource VPN) 사용
- 계정 관리 방법
- AD(Active Directory)에 의한 계정 관리
Active Directory 인증에는 AWS Directory Service를 이용해 On-Promise AD 와 상호 연동이 가능 (AD Connector) - 서버 인증서 / 클라이언트 인증서 상호 인증
- 위 두 가지 항목을 복합적으로 사용 가능
- AD(Active Directory)에 의한 계정 관리
- 이용 요금(기본요금(a)+종량요금(b)의구조)
- Client VPN EndPoint 에 연결된 Subnet 수 x 이용시간(hours)
- 활성 클라이언트 수 x 이용시간 (hours)
편리한대신 비용이 높은 편이다. 하지만, 담당자는 없으면서 높은 보안을 유지하고자 한다면 이 비용은 결코 높은 편이라 할 수 없다 생각한다.
- AWS VPN Pricing (아직 한글 메뉴얼 없음)
만약, SE(System Engineer)가 있거나, DevOps 구조로 개발자가 인프라-스트럭쳐 까지 관리할 수있다면 직접 VPN 환경을 구축하는것도 좋은 방법이다. 확실한건, 명령어로 OpenVPN 을 관리한다는 건 일정 규모 이상의 구성원을 갖고 있는 조직에선 무리가 있다는 것. 관리형 소프트웨어를 도입하는것도 좋은 선택이다.
OpenVPN 을 직접 설치해 관리하는 경우 (비용은 저렴하나 손이 많이 간다)
OpenVPN 관리 도구를 설치해 관리하는 경우 (상대적으로 비용이 높지만, 손이 그나마 덜간다)
AWS Client VPN 아키텍쳐
이 포스트에는 ‘상호 인증’을 기반으로한 VPN 구성을 바탕으로 하고 있음
OpenVPN 을 사용하기 위해서는 서버와 클라이언트에 인증서가 필요하다.
- OpenSSL 을 통해 생성하는게 일반적이지만, AWS 는 ACM(AWS Certificate Manager)을 사용해 서버와 클라이언트용 인증서를 생성 및 관리하게 된다.
이 인증서를 바탕으로 서버(AWS Client VPN Server)-클라이언트(개발자 PC)의 신뢰 관계를 맺는다.
터널링을 위한 사설 IP 는 사전에 지정한 Subnet 을 바탕으로 한다. (일반적이지는 않지만) 모든 트래픽을 Client VPN 으로 흐르게 할 경우 퍼블릭 인터넷은 NAT Gateway 또는 기타 Proxy 를 통해 외부로 나가게 된다.
Client VPN 을 통해 VPC 에 있는 리소스에 억세스할때의 IP 는 Client VPN EndPoint ENI 를 따르게 되기 때문에 ENI 의 IP 를 기준으로 Security Group 을 지정해야 한다.
ACM을 사용한 인증서 생성
앞서 언급한 것과 같이 “상호 인증” 형태로 VPN 환경 구축을 목표로한다. 가장 간단한 구조로, VPN 인증서 만으로 신원확인을 하는 형태다. 서버 및 클라이언트 인증서는 ACM 에서 프로비저닝 되며, 기관으로 부터 발급받은 개별 인증서가 있는 경우 ACM 에 업로드해 관리 및 사용이 가능하다. Active Directory 인증을 통한 ‘사용자’ 구분은 추후 다뤄 볼 예정이다.
1. Root 인증서(CA, Certificate authority) 만들기
EasyRSA 를 사용해 인증서를 만드는게 일반적인데, 이곳에서 확인 할 수 있다. 하지만, 앞서 설명한것과 같이 AWS 에서 제공하는 도구를 최대한 활용하고자 한다. 사설 CA 를 만드는 방법은 매우 간단하다. ACM 의 사설 CA 기능을 사용하면 된다. 다른 정보보다 CN(Common Name) 명칭은 인증서의 대표격 명칭이기 때문에 미래를 내다보고 네이밍 룰을 만드는게 필요하다.
일반적으로 OpenVPN 을 만들 때는 서버를 위한 루트 CA 를 만들고, 이에 종속되는 하위 CA 를 만들지만, VPN Client 는 루트 CA 가 2개 필요하다.
간단하게 CA 가 만들어졌다. 생성된 인증서는 “CA 인증서” 탭에서 추출할 수 있다. ARN 은 Client VPN 에서 인증서 선택시 필요하므로 어디에 기록해두자.
- Common Name: MGMT_ONELABS
- ARN: arn:aws:acm-pca:ap-northeast-1:2121158410:certificate-authority/a78f21ee-34c7a18022d6
2. 사설 인증서 등록
앞서 만든 인증서는 Private CA다. 공인 인증기관에서 만들어 배포한 인증서가 아니기 때문에 Private 이다. (AWS 가 만들었지만, EasyRSA 같은 도구를 대신했을 뿐이다) 이 인증서를 사용하기 위해선 ACM 의 ‘인증서 관리자’에 등록해야 한다. 2개의 CA 모두 등록하면 되고, 하나는 AWS VPN Client 를 위해 사용하며, 하나는 사용자를 위해 사용될 것이다. 등록하지 않으면 VPN Client EndPoint 생성시 인증서가 나타나지 않는다.
인증서를 등록 후 보이는 “식별자”를 기록해두자. 미리 말하지만, VPN Client EndPoint 를 생성 시 ACM 을 선택할 때 이 정보를 기준으로 인증서 정보를 보여주기 때문이다. (이름이 보이지 않는다)
AWS VPN Client EndPoint 생성
AWS 관리 콘솔에 로그인 후 VPC(Virtual Private Network)를 방문하면 좌측에 “클라이언트 VPN 엔드포인트(Client VPN EndPoint)”가 보인다.
1. VPN Client EndPoint 생성
VPN EndPoint 를 생성은 간단 하지만 주의해야 할 세가지 항목이 있다.
- 클라이언트 IPv4 CIDR: 클라이언트가 사용할 터널링 IP 로 22Bit 로 선언 되어야 한다.
- 인증정보 > 인증옵션: ‘상호 인증 사용’을 선택하면 클라이언트 인증서 ARN 선택이 가능하다.
서버 인증서 및 클라이언트 인증서는 앞서 생성한 2개의 CA 를 각각 선택하면 된다. - 프로토콜: 일반적으로 OpenVPN 에서 가장 많이 사용되는 프로토콜은 UDP 다.
VPN Client EndPoint 를 생성한 시점 까지는 사용 요금이 발생하지 않음
2. 부가 정보 설정
“연결”, 기본적으로 접속할 VPC 와 VPC 에 속해있는 Subnet 을 선택한다. 하나라도 상관 없지만 고가용성을 위해 복수개의 Subnet을 선택할 수 있지만, 장애는 AZ 자체에 영향을 받기 때문에 선택할 서브넷이 별도의 가용영역에 있는 것이 좋다.
“보안그룹”, 기본적으로 VPC 의 기본 보안 그룹이 선택되어 있다. 최소한 내부 통신을 위한 보안 그룹이 추가 되어야 한다. 중요한것은 PC 에서 VPN 을 통해 VPC의 리소스에 억세스할 때 접근 IP 주소는 Client VPN Endpoint의 NAT 가 된다는 것.
“권한부여”, 개발자PC 에서 VPC의 어느 특정 IP 범위의 Traffic 을 허용하는 경우 CIDR 형식으로 IP 를 추가하면 된다. 만약 이 부분이 비어있다면 접속 후 개발자 PC 는 어떠한 행위도 할 수 없다. 만약 NAT Gateway 또는 가상 어플라이언스를 통해 퍼블릭 인터넷으로 연결되는것을 허용하고 싶다면 0.0.0.0/0 을 추가 해야 한다.
아래 이미지는 MGMT Subnet 에 모든 것을 사용할 수 있다는 가정하고 있다.
“라우팅테이블” , 개발자PC의 Traffic이 지정된 VPC 에서 벗어나지 않는다면 별도의 라우팅 테이블 설정이 필요없다. 하지만 앞서 우리는 “NAT Gateway”를 통해 퍼블릭 인터넷을 사용하는걸 가정으로 했다. 0.0.0.0/0 을 NAT Gateway 가 있는 Subnet 으로 연결해주면 된다.
VPC Peering을 통해 다른VPC와 연결하고 싶은 경우 해당 VPC EndPoint 를 연결해 주면 된다.
Client VPN EndPoint의 라우팅 테이블 레코드 추가 시 “Target CIDR(Subnet)”를 2개 지정한다. 우선 “CIDR=0.0.0.0/0, Target Subnet=subnet-1234” 를 추가했다고 가정해보자. 이 경우 개발자 PC 가 VPN 을 통해 퍼블릭 인터넷의 Web Service 연결을 시도하려면 패킷이 VPN을 통해 Client VPN EndPoint에 도달하게 되고, 다시 subnet-1234 에 정의된 Subnet Routing Table의 정책을 따르게 된다. subnet-1234의 Routing Table에 “0.0.0.0/0 > NAT Gateway”라는 Route 가 있다면 NAT Gateway 를 통해 퍼블릭 인터넷으로 연결되며, “0.0.0.0/0 > Virtual Appliance ENI” 형태로도 가능하다.
또, “0.0.0.0/0 > Internet Gateway” 도 가능하나, 이경우 VPC 설정에서 “Public IPv4 주소 자동 할당”이 활성화 되어 있어야 한다. 이는 Client VPN EndPoint 의 ENI 가 Public IP 를 갖고 있어야 하는데, 이 환경설정이 꺼져 있다면 Public IP 를 할당 받을 수 없기 때문이다. 즉, Client VPN EndPoint 의 Route Table은 CIDR 마다 패킷이 경유하는 경로라 이해하면 된다.
말이 조금 복잡하지만, VPN 설정에서 Route Table 은 매우 중요하고, Traffic Flow 를 이해하고 있어야 하기 때문에 사전지식이 있다면 이들을 이해하는건 그리 어려운 일은 아닐거라 생각한다.
AWS VPN Client EndPoint 설정 다운로드 및 연결
모든 설정이 끝났다. 개발자 PC를 위한 VPN EndPoint 설정을 다운로드하자. 확장자는 OVPN 으로 OpenVPN Profile 이다. OpenVPN Config 폴더에 복사하면 된다.
폴더의 위치는 대부분 동일.
결론
설정을 초기화 하고 글을 작성하고 있다 .. 자료가 날라가 Route Table 이 없다. 구조는 OpenVPN 의 일반적인 형태와 같다. 중요한건 형상을 체계적인 기준으로 만들고, 개발자 트래픽과 사용자 트래픽을 분리하되, 개발자 트래픽은 관리자가 반드시 알고 제어할 수 있어야 한다는 것.
