Amazon Web Services 한국 블로그
보안성 높은 재택근무 환경을 위한 AWS 아키텍처 구성하기
팬데믹으로 인해 재택근무는 일상화가 되었습니다. AWS의 CISO인 Stephen Schmidt의 AWS re:Inforce 2021 기조연설에 따르면, 팬데믹 이후 재택 근무자는 114% 증가했고, 재택 근무자가 직접 장비를 갖추는 사례가 59% 늘었다고 합니다. 이런 상황은 기업 보안팀에게는 재택 근무자의 단말기에 일관된 보안 정책 적용이 어려워지고 보안 정책 적용의 누수로 이어져, 새로운 보안 위협으로 대두되고 있습니다.
이 글에서는, 기업 보안팀에서 재택 근무자의 인터넷 트래픽을 제어할 수 있는 AWS Client VPN과 재택 근무자의 단말기에 일관된 보안 정책을 적용할 수 있는 Amazon Workspaces를 통한 가상 데스크톱 업무 환경을 구성하는 아키텍처를 두 단계로 나누어서 알아봅니다.
1. AWS Client VPN 구성 소개
먼저 AWS Client VPN 연결 후 고객의 가상 사설 네트워크(VPC)의 Private subnet에 구성된 내부 업무용 시스템에 직접 접근하는 방식으로 VPN을 통해 인증된 사용자로 접근을 제한하는 방법입니다. 온-프레미스에서는 VPC의 Private subnet에 설치된 내부 업무용 시스템에 접근하기 위해 AWS Direct Connect 또는 AWS Site-to-Site VPN 등의 연결 구성을 활용했습니다. 재택근무를 위해서는 AWS Client VPN을 사용하여 내부 업무용 시스템에 접근할 수 있는 VPN연결 환경을 구성할 수 있습니다. 재택근무자는 VPN이 연결되지 않은 상태에서는 내부 업무용 시스템에 접근할 수 없고, VPN 연결 후에 내부 업무용 시스템에 접근할 수 있습니다.
AWS Client VPN 연결을 생성할 때 사용자를 인증하는 방식은 상호인증 방식과 사용자 기반 인증방식을 제공합니다. 상호인증을 위한 서버 및 클라이언트 키 발급은 AWS Certificate Manager를 통해 신규를 발급받을 수 있고, 고객의 키를 가져와서 사용하는 것도 가능합니다. 사용자 기반 인증은 Active Directory 또는 SAML 기반의 자격 증명 공급자를 사용할 수 있으며, Active Directory는 AWS에서 관리형으로 제공하는 서비스를 활용할 수도 있고, 고객이 온-프레미스에서 운영하고 있는 Active Directory를 사용한다면 AWS에서 제공하는 AD Connector를 통해 연동하여 사용할 수 있습니다.
AWS Client VPN을 사용하면 재택근무 환경에서도 인터넷망을 사용하면서도 보안성이 높은 VPN 연결을 사용할 수 있고, VPN이 연결되어 있는 동안 재택근무자의 단말에서 발생하는 인터넷 트래픽을 제어할 수 있습니다. AWS Client VPN은 연결 생성 후 사설망 통신은 VPN으로, 인터넷망 통신은 로컬인터넷으로 분리해서 라우팅하는 분할 터널과 사설망과 인터넷망 통신 모두 VPN으로 라우팅하는 풀 터널을 지원합니다. 따라서 AWS Client VPN을 풀 터널 연결을 생성하면 VPN 연결 후 재택근무자의 단말에서 유해사이트 차단 등 인터넷 트래픽을 제어할 수 있습니다. 접근을 허용하는 Allow list 도메인 관리를 위해 Squid 등 오픈소스 프록시를 사용하는 방법이 있습니다.
2. Amazon Workspaces 구성 소개
AWS Client VPN 연결을 통해 VPC의 Private subnet에 있는 내부 업무용 시스템을 보호하는 아키텍처를 만들 수 있으나, 개인이 소유한 스마트 기기를 직장에 가져와 업무에 활용하도록 허용하는 정책인 BYOD(Bring Your Own Device)에 대한 보안통제는 불가능합니다. 따라서 BYOD를 직접 보안통제하는 것 대신, BYOD에서 가상 데스크톱 환경(Amazon Workspaces)에 접근 후 내부 업무용 시스템에 접근하도록 하는 간접접근방식으로 아키텍처를 구성할 수 있습니다. 가상 데스크톱 환경은 기업 보안팀에서 보안패치 및 보안솔루션 설치 등 일관된 IT내부통제를 수립하는데 이점을 얻을 수 있습니다. Amazon Workspaces의 보안 특성을 알아보겠습니다.
Amazon Workspaces가 프로비저닝된 후 사용자가 가상 데스크톱에 접근을 하기 위해서는 Amazon Workspaces 전용 클라이언트 프로그램이나 브라우저를 사용해서 접근할 수 있습니다. Amazon Workspaces는 디렉토리 서비스를 통해 사용자 인증을 하는데, 디렉토리 별로 등록코드가 발급 됩니다. 클라이언트 프로그램을 실행하면 등록코드로 1차 검증 후 등록된 Username과 Password로 가상 데스크톱에 접근할 수 있습니다. Amazon Workspaces 인증 시 MFA를 적용할 수 있으며, FreeRADIUS 서버를 AWS Directory Service에 통합 등을 활용할 수 있습니다.
Amazon Workspaces에서는 사용자 인증을 위한 트래픽과 가상 데스크톱을 스트리밍을 위한 트래픽이 있으며 두 트래픽은 다른 방식으로 처리됩니다. 인증트래픽은 HTTPS 프로토콜을 사용하고, 스트리밍 트래픽은 PCoIP, WSP 프로토콜을 사용합니다. AWS Client VPN ENI가 있는 VPN subnet의 라우팅테이블에서 인증트래픽은 NAT 인스턴스로, 스트리밍 트래픽은 NAT GW로 라우팅하도록 고 나머지 트래픽은 차단하도록 설정하고, NAT 인스턴스에 있는 Squid에서 인증트래픽에 필요한 도메인만 Allow list에 등록하면 재택근무자는 가상 데스크톱으로만 접근을 제한할 수 있습니다. Amazon Worksapces에서는 접근을 허용하는 IP에 대한 접근 제어를 할 수 있으며, VPC에 있는 NAT의 IP만 허용함으로써 VPN 연결이 되지 않은 인터넷에서는 접근이 불가하고 VPN 연결 후에만 가상 데스크톱에 접근할 수 있도록 접근제어를 할 수 있습니다.
3. 재택 근무자 보안 솔루션 구현 및 테스트하기
이제 앞서 소개한 AWS 기반 아키텍처에 대한 이해를 바탕으로 실제로 AWS 콘솔에서 구성하는 방법을 알아보겠습니다. 테스트에 사용된 명칭과 규칙은 솔루션 구현의 이해를 돕기위한 예시이므로 실제 워크로드에 적용시에는 운영 환경에 맞게 설정해야 합니다.
PART 1 – AWS Client VPN 구성하기
1. VPC를 생성합니다.
– VPC명: wfh-vpc
– IPv4 CIDR 블록: 10.1.0.0/16
2. Internet Gateway 생성 후 VPC에 연결합니다.
– IGW명: wfh-igw
3. subnet을 생성합니다.
| 서브넷명 | 가용 영역 | IPv4 CIDR 블록 | 구성 요소 |
| wfh-public-az-a | ap-northeast-2a | 10.1.0.0/24 | NAT 게이트웨이 및 NAT 인스턴스 |
| wfh-public-az-c | ap-northeast-2c | 10.1.1.0/24 | |
| wfh-private-az-a | ap-northeast-2a | 10.1.2.0/24 | 내부 업무용 시스템 및 Active Directory Controller |
| wfh-private-az-c | ap-northeast-2c | 10.1.3.0/24 | |
| wfh-vpn-az-a | ap-northeast-2a | 10.1.100.0/24 | AWS Client VPN 엔드포인트 |
| wfh-vpn-az-c | ap-northeast-2c | 10.1.101.0/24 |
4. NAT 인스턴스를 생성합니다.
4-1) EC2 인스턴스를 생성한 후 EC2에 접속하여 Squid를 설정합니다.
– subnet: wfh-public-az-a
– EC2의 보안그룹
| 구분 | 포트 범위 | 프로토콜 | 원본 |
| 인바운드 규칙 | 80 | TCP | 0.0.0.0/0 |
| 443 | TCP | 0.0.0.0/0 | |
| 아웃바운드 규칙 | ANY | ANY | 0.0.0.0/0 |
4-2) Squid를 사용하여 NAT 인스턴스에 DNS 필터링 방법을 참고하여 Squid를 설치 및 설정합니다.
– Squid에서 DNS 필터링에 사용하는 /etc/squid/allowlist.txt에 접근을 허용할 도메인리스트를 추가 합니다. 반대로 Deny list 방식으로 등록된 도메인은 차단하는 방식으로 설정도 할 수 있습니다.
4-3) Squid 서비스 시작 후 allowlist.txt를 작성했다면, 서비스를 재시작 합니다.
4-4) 네트워크 소스/대상 확인 중지 설정을 합니다. (EC2인스턴스 선택 후 > 작업 > 네트워킹 > 소스/대상 확인 변경 > 중지 체크)
5. Route Table을 생성합니다.
| 라우팅 테이블명 | 목적지 | 라우팅 경로 | 서브넷 연결 |
| wfh-public-rtb | 10.1.0.0/16 | local | wfh-public-az-a wfh-public-az-c |
| 0.0.0.0/0 | Internet Gateway (wfh-igw) | ||
| wfh-private-rtb | 10.1.0.0/16 | local | wfh-private-az-a wfh-private-az-c |
| wfh-vpn-rtb | 10.1.0.0/16 | local | wfh-vpn-az-a wfh-vpn-az-c |
| 0.0.0.0/0 | NAT인스턴스(Squid) ENI |
6. AWS Client VPN에서 사용할 인증서를 생성합니다.
AWS Certificate Manager의 공인 인증서 요청 문서를 참고합니다.
7. AWS Client VPN 생성 및 설정
AWS Client VPN 관리자 안내서를 참고하여 AWS Client VPN 엔드포인트를 생성 및 설정합니다.
7-1) AWS Client VPN 엔드포인트를 생성합니다.
– 클라이언트 IPv4 CIDR: 172.16.0.0/16
– 서버 인증서 ARN: 7에서 생성한 인증서 사용
– VPC: wfh-vpc
7-2) AWS Client VPN 엔드포인트를 subnet에 연결합니다.
– VPC: wfh-vpc
– 연결할 subnet: wfh-vpn-az-a
7-3) AWS Client VPN 엔드포인트에 적용할 보안 그룹 생성 및 적용합니다.
| 구분 | 포트 범위 | 프로토콜 | 원본 |
| 인바운드 규칙 | 80 | TCP | 0.0.0.0/0 |
| 443 | TCP | 0.0.0.0/0 | |
| 아웃바운드 규칙 | ANY | ANY | 0.0.0.0/0 |
7-4) AWS Client VPN 엔드포인트에 라우팅 테이블을 생성합니다.
| 라우팅 대상 | 대상 VPC 서브넷 | 구분 |
| 10.1.0.0/16 | wfh-vpn-az-a | Default Route |
| 0.0.0.0/0 | wfh-vpn-az-a | 재택 단말에서 풀 터널을 위한 추가 Route |
7-5) AWS Client VPN 엔드포인트에 권한을 부여합니다.
| 액세스를 활성화할 대상 네트워크 | 액세스 권한 |
| 10.1.0.0/16 | 모든 사용자 |
| 0.0.0.0/0 | 모든 사용자 |
8. AWS Client VPN 엔드포인트 연결을 테스트합니다.
– 셀프 서비스 포털에서 클라이언트 구성 및 애플리케이션을 다운로드 할 수 있습니다.
– 구성 파일 다운로드 후 AWS Client VPN 엔드포인트의 도메인 앞에 임의의 문자열을 추가 합니다. 그렇지 않으면 VPN 연결이 되지 않습니다.
– AWS Client VPN에 연결하기 위해서는 셀프 서비스 포털에 있는 AWS Client VPN 애플리케이션 또는 OpenVPN 클라이언트 프로그램 등을 사용할 수 있습니다.
9. VPN 연결 후 설정이 잘 동작하는지 테스트합니다.
– AWS Client VPN 연결에 성공했다면, Private subnet에 있는 EC2 서버에 접근 가능 여부를 테스트합니다.
– Allow list에 등록한 도메인에 접근 가능여부와 Allow list에 등록되지 않은 도메인 차단 여부를 테스트합니다.
PART 2 – Amazon Workspaces 구성하기
1. Amazon Workspaces를 생성합니다.
1-1) Amazon Workspaces와 VPC간 통신을 위한 ENI가 위치할 subnet을 생성합니다.
| 서브넷명 | 가용 영역 | IPv4 CIDR 블록 | 구성 요소 |
| wfh-workspaces-az-a | ap-northeast-2a | 10.1.200.0/24 | Amazon Workspaces ENI |
| wfh-workspaces-az-c | ap-northeast-2c | 10.1.201.0/24 |
1-2) Amazon Workspaces 관리 안내서에 따라 가상 데스크톱을 생성합니다.
2. VPN 연결 상태에서만 가상데스크톱에 접근할 수 있도록 IP 접근제어를 설정합니다.
Part1에서 DNS 필터링을 위해 NAT 인스턴스를 사용했습니다. 하지만 더 나은 가용성과 대역폭을 제공하고 관리에 소요되는 작업이 줄어들기 때문에 AWS에서는 NAT 게이트웨이 사용을 권장합니다. 따라서 DNS 필터링이 필요한 트래픽은 NAT 인스턴스로 Amazon Workspaces의 스트리밍 트래픽은 NAT 게이트웨이로 라우팅하도록 구성합니다.
2-1) NAT 게이트웨이 를 생성합니다.
– NAW-GW명: wfh-nat-gw
– subnet: wfh-public-az-a
2-2) Amazon WorkSpaces 콘솔의 왼쪽 메뉴에서 IP Access Control Groups 에서 등록할 수 있습니다. IP Access Control Group을 생성 후 VPC의 Public subnet에 있는 NAT 게이트웨이와 NAT 인스턴스의 공인IP를 등록합니다.
2-3) Amazon WorkSpaces 콘솔의 왼쪽 메뉴에서 Directories 메뉴에서 적용할 디렉토리 선택 후 Action 메뉴 중 Update Details에서 디렉토리에 적용할 IP Access Control Group을 선택할 수 있습니다.
3. VPC에서 Amazon Workspaces 접근을 위한 Route Table을 업데이트 합니다. 다음의 라우팅 경로는 서울리전의 Amazon Worksapces에서 PC 클라이언트 프로그램으로 접속하는 PCoIP 게이트웨이의 IP주소입니다. 다른 리전을 사용하거나 브라우저 방식을 사용하기 위해서는 WSP 게이트웨이 IP주소를 등록해야 합니다. WorkSpaces IP 주소 및 포트 요구 사항을 참고하여 사용하는 환경에 맞도록 설정합니다.
| 라우팅 테이블명 | 업데이트 내역 | 목적지 | 라우팅 경로 | 서브넷 연결 |
| wfh-vpn-rtb | 추가 | 13.124.44.166/32 | NAT 게이트웨이 (wfh-nat-gw) | wfh-vpn-az-a wfh-vpn-az-c |
| 추가 | 13.124.203.105/32 | NAT 게이트웨이 (wfh-nat-gw) | ||
| 추가 | 52.78.44.253/32 | NAT 게이트웨이 (wfh-nat-gw) | ||
| 추가 | 52.79.54.102/32 | NAT 게이트웨이 (wfh-nat-gw) | ||
| 추가 | 3.34.37.0/24 | NAT 게이트웨이 (wfh-nat-gw) | ||
| 추가 | 3.34.38.0/24 | NAT 게이트웨이 (wfh-nat-gw) | ||
| 추가 | 3.34.39.0/24 | NAT 게이트웨이 (wfh-nat-gw) | ||
| 추가 | 13.124.247.0/24 | NAT 게이트웨이 (wfh-nat-gw) | ||
| 기존 유지 | 10.1.0.0/16 | local | ||
| 기존 유지 | 0.0.0.0/0 | NAT 인스턴스(Squid) ENI |
4. NAT 인스턴스의 DNS 필터링을 업데이트 합니다.
4-1) Squid에서 DNS 필터링에 사용하는 /etc/squid/allowlist.txt에 Amazon Workspaces 액세스에 사용되는 도메인리스트를 추가합니다.
다음의 도메인리스트는 서울리전의 Amazon Worksapces에 액세스 하기 위해 필요한 것으로, 다른 리전에서 사용한다면 WorkSpaces IP 주소 및 포트 요구 사항을 참고하여 사용하는 환경에 맞도록 설정해야 합니다.
4-2) 변경사항 적용을 위해 Squid 서비스를 재시작합니다.
5. 가상 데스크톱 연결을 테스트 합니다.
5-1) 등록코드를 입력합니다. 등록코드는 Amazon Workspaces 생성 시 셋업한 디렉토리 정보에서 확인할 수 있습니다.
Amazon Workspaces에 VPC의 NAT IP에서만 접근할 수 있도록 접근제어를 설정했기 때문에, VPN이 연결되지 않은 상태에서는 등록코드 검증이 진행되지 않습니다. 따라서 접근이 허용되지 않은 네트워크에서 인증정보를 유추하기 위한 Brute Force 공격 시도를 차단할 수 있습니다.
5-2) VPN 연결 후 가상데스크톱 연결을 확인합니다.
5-3) VPN 연결 상태에서도 내부 업무용 시스템에 접근이 불가하고, 가상 데스크톱에서만 접근 가능하도록 설정합니다.
NACL 또는 Security Group에서 Amazon Workspaces ENI가 있는 subnet으로 부터 접근만 허용하도록 하는 규칙을 생성하여 적용합니다.
– EC2의 보안그룹 적용 예시
| 구분 | 포트 범위 | 프로토콜 | 원본 |
| 인바운드 규칙 | 80 | TCP | 10.1.200.0/24 |
| 80 | TCP | 10.1.201.0/24 | |
| 443 | TCP | 10.1.200.0/24 | |
| 443 | TCP | 10.1.201.0/24 | |
| 아웃바운드 규칙 | ANY | ANY | 0.0.0.0/0 |
5-4) VPN 연결이 종료되면 가상데스크톱 연결도 종료됩니다.
마치며
이 글에서 소개한 보안성 높은 재택근무 환경 AWS 아키텍처에서는 재택근무자의 보안을 강화하기 위해 두 단계로 접근했습니다. 먼저 AWS Client VPN을 사용하여 내부망 접근을 통제하고, 내부망에 접근하는 동안에는 허용된 도메인리스트 외 외부 인터넷 트래픽을 차단했습니다. 그후 단말 보안을 강화하기 위해 Amazon Workspaces를 가상 데스크톱으로 사용했습니다. 가상 데스크톱을 사용하면 기업 보안팀에서 일관된 보안 정책을 적용할 수 있고, 외부의 보안 위협으로 부터 안전한 업무환경을 구축할 수 있으며, 업무자료를 재택 근무자의 장비로 이동하는 것을 통제할 수 있습니다.
재택근무의 일상화에 따라 보안통제 방식도 변화하고 있습니다. AWS서비스를 활용하여 보다 안전한 재택근무 환경을 만들어 보시기 바랍니다.
– 이종근, AWS Security Solutions Architect
– 신중훈, AWS Solutions Architect