Bastion Host 없이 Private Subnet에 위치한 EC2 인스턴스 접속 방법
본 글은 사내에서 SSH 방식으로 Private Subnet에 위치한 EC2 인스턴스에 접속하던 방식에서 SSM 방식으로 변경한 경험을 토대로 작성하였습니다.
결론
AWS SSM(Systems Manager) Session Manager를 사용하여 Private Subnet에 위치한 EC2 인스턴스에 접속할 수 있다. SSM Session Manager를 사용하지 않는다면 Public Subnet에 Bastion Host를 위치시켜 SSH를 통해 Private Subnet에 EC2에 접속해야 한다.
Bastion Host 방식의 문제점
Pem 키 관리의 어려움
Private Subnet에 위치한 EC2에 접속하기 위해 Public Subnet에 Bastion Host를 위치시키는 것은 SSH 키 관리 부담이 발생하고, Bastion Host가 Public에 노출 위험이 발생한다. Private Subnet의 EC2에 접속하기 위해 Bastion Host를 위한 pem 키와 Private Subnet에 위치한 EC2의 pem 키, 총 두 개가 필요하다. 이 키들은 로컬 PC에 저장하게 되고, 한 번 유출되면 인프라 전체가 위험에 노출되게 된다. 이를 방지하기 위해 키를 주기적으로 바꾸는 것도 번거로운 작업이다.
Brute-force 공격
Bastion Host는 인터넷에 노출되어야 하므로 SSH 포트가 외부에 노출되어 있다. 따라서 Brute-force(무차별 대입 공격)나 알려진 취약점을 이용한 공격의 표적이 된다.
추적의 어려움
어떤 사용자가 Bastion Host를 거쳐 Private Subnet에 위치한 EC2에 접속했는지 알기 어렵다. 왜냐하면 터미널에서 AWS 자격 증명을 활성화하지 않고도, Bastion Host의 pem 키와 Private Subnet에 위치한 EC2의 pem키만 있다면 접속이 가능하기 때문이다.
SSM Session Manager 방식의 장점
공격 표면 감소
Private Subnet에 위치한 EC2 인스턴스의 보안 그룹에 인바운드 규칙을 허용할 필요가 없다. 모든 연결은 EC2 인스턴스 내부의 SSM Agent가 AWS SSM 엔드포인트로 아웃바운드 연결을 시작하는 방식으로 이루어진다. 따라서 외부 공격 표면이 원천적으로 제거된다.
중앙 집중식 접근 제어
SSH 키 대신 IAM 사용자 및 역할을 기반으로 EC2 접근 권한을 제어한다. 특정 사용자나 특정 태그가 붙은 인스턴스에 대한 접근을 허용하는 등 세분화된 정책 설정이 가능하다.
추적에 용이
SSM Session Manager를 사용하기 위해서는 AWS 자격 증명 정보가 필요하므로 모든 세션 활동이 CloudWatch Logs에 자동으로 기록된다. 이를 통해 규정 준수 요건을 충족하고 보안 감사를 쉽게 수행할 수 있다.
SSM Session Manager 구성 방법
Private Subnet에 위치한 EC2 인스턴스에 SSM Session Manager를 접근하기 위해 VPC Endpoint를 사용할 수 있다.
사전 요구 사항
- IAM Instance Profile: EC2 인스턴스가 SSM 서비스와 통신할 수 있도록 권한을 부여해야 한다.
- SSM Agent 설치: EC2 인스턴스에 SSM Agent가 설치 및 실행 중이어야 한다.
- Amazon Linux 2를 사용하는 경우 기본적으로 설치되어 있다.
- VPC Endpoint: EC2 인스턴스가 SSM 서비스 엔드포인트와 통신할 수 있어야 한다.
1. IAM 역할 생성 및 EC2 인스턴스에 부여
EC2 인스턴스가 자신을 SSM 서비스에 등록하고, Session 연결 요청을 수신하기 위해 SSM API를 호출할 수 있는 권한이 필요하다. => AmazonSSMManagedInstanceCore AWS 관리형 정책인 AmazonSSMManagedInstanceCore 권한을 갖는 Role을 생성하고, 이를 Private Subnet의 EC2 인스턴스에 부여한다.
2. VPC Endpoint 생성
VPC Endpoint를 사용하면 Private Subnet의 EC2 인스턴스가 인터넷을 거치지 않고 AWS 내부 네트워크(Private Link)를 통해 SSM 서비스와 안전하게 통신이 가능하다. 덕분에 NAT Gateway가 필요 없어지므로 보안을 강화할 수 있다. Private Subnet에 NAT Gateway가 없다면 인터넷으로 나가는 경로가 없다. 이 경우 SSM Agent는 AWS 서비스 엔드포인트와 통신할 수 없다.
VPC 콘솔에 접속하여 VPC Endpoint를 생성할 수 있는데, SSM Session Manager를 위해 Interface 타입의 엔드포인트 3개가 필요하다.
com.amazonaws.<region>.ssmcom.amazonaws.<region>.ssmmessagescom.amazonaws.<region>.ec2messages
엔드포인트를 생성할 때, Private Subnet의 EC2 인스턴스가 속한 VPC를 선택해야 한다. 그리고 VPC Endpoint의 보안 그룹에서 Private Subnet의 EC2 인스턴스로부터의 HTTPS 인바운드 트래픽을 허용해야 한다.
3. VPC Endpoint용 보안 그룹 생성
VPC Endpoint를 위한 보안 그룹을 생성하고, 인바운드 규칙으로 Private Subnet에 속한 EC2 인스턴스의 HTTPS 트래픽을 허용해야 한다. 간단하게 HTTPS 프로토콜로 들어오는 Private Subnet에 속한 보안 그룹을 허용하면 된다.
기존의 Private Subnet에 위치한 EC2 인스턴스의 보안 그룹을 수정할 필요가 없다. SSH 포트를 포함한 어떤 포트도 인터넷에 열 필요가 없다. 단, EC2 인스턴스가 SSM 서비스 엔드포인트와 통신할 수 있도록 HTTPS 트래픽을 허용해야 한다. 기본적으로 모든 아웃바운드 트래픽을 허용하므로 별도의 설정이 필요 없다.
4. SSM Session Manager로 접속
AWS 웹 콘솔 또는 AWS CLI를 통해서 접속할 수 있는데, 다음은 AWS CLI를 통해 Private Subnet에 위치한 EC2 인스턴스에 접속하는 방법이다.
1
$ aws ssm start-session --target <private_subnet_instace_id>
SSM을 사용하여 Private Subnet에 위치한 RDS에 접속할 수 없다.
사내에서 SSH 방식이 아닌 SSM 방식으로 사용하도록 변경하고, Bastion Host를 중지한 순간… “희망님 개발 서버 RDS 연결이 안돼요~” 라는 말이 들려왔다. RDS는 생각도 하지 못한채 EC2만 생각하고 작업을 했던 것이다.
그래서 SSM을 사용하여 Private Subnet에 위치한 RDS에 접속할 수 있는지 알아보니 불가능이었다. 당연하게도 SSM Agent를 RDS에 설치할 수 없기 때문이엇다. SSM Session Manager는 EC2 인스턴스의 OS에 설치된 SSM Agent와 통신하는 방식으로 동작한다. 즉, 사용자가 OS에 직접 로그인하여 셸 명렁을 내리는 것과 같은 호나경을 제공하는 것이다.
하지만 Amazon RDS의 경우 사용자가 OS에 접근할 수 없는 PasS(완전 관리형 서비스)이므로 DB 엔드포인트 주소만 받아서 사용하는 구조이다. 따라서 RDS 인스턴스의 OS에 SSM Agent를 설치하는 것 자체가 불가능하므로 SSM Session Manager로 RDS에 접속할 수 없다.
따라서… Bastion Host는 완전히 제거하지 못하고 RDS에 접속하기 위한 용도로만 남겨두었다.