서론: SSH 포트 개방의 보안 위험성 — “22번 포트는 해커의 초대장”
전통적으로 EC2 인스턴스에 접속하는 가장 일반적인 방법은 SSH(Secure Shell) 프로토콜을 사용하고, 이를 위해 인스턴스의 보안 그룹에서 TCP 22번 포트를 개방하는 것입니다. 하지만 SSH 포트를 개방하는 것은 잠재적인 공격 표면(Attack Surface)을 넓히며, 특히 0.0.0.0/0과 같이 광범위한 IP 대역을 허용할 경우 보안 위험이 매우 높아집니다. VPN(Virtual Private Network)을 사용하면 이 문제를 해결할 수 있지만, VPN 서버 관리와 접속 복잡성이라는 또 다른 운영 부담이 생깁니다.
AWS Systems Manager의 Session Manager는 SSH 포트 개방이나 VPN 구축 없이도 EC2 인스턴스에 안전하게 접속하고 관리할 수 있는 가장 효율적이고 현대적인 솔루션입니다. 본 글에서는 Session Manager의 작동 원리와, 이를 활용하여 SSH 포트 개방 없이 EC2에 보안 접속하는 구조를 상세히 설명합니다.
SSH (TCP 22) 는 EC2 접속의 전통적 표준이었지만, 클라우드 시대에는 “보안 구멍” 으로 전락했습니다. 0.0.0.0/0 → 22 개방 한 줄이 브루트포스 → 루트킷 → 데이터 유출 → 랜섬웨어 라는 치명적 공격 경로를 열어줍니다.
SSH 포트 개방의 숨겨진 비용
| 항목 | 위험 | 실제 사례 |
|---|---|---|
| 공개 노출 | 인터넷 → 22번 포트 스캔 | 초당 1,200회 로그인 시도 |
| 브루트포스 | root, admin + 약한 비밀번호 | 2024 스타트업 침해 → ₩5억 피해 |
| 운영 부담 | 키 관리, 패치, 방화벽 | 패치 누락 → CVE-2024-6387 악용 |
| 컴플라이언스 위반 | PCI-DSS, ISO27001 | 감사 실패 → 벌금 $1M |
“SSH는 편리하지만, 방어는 불가능에 가깝다.”
대안의 딜레마: VPN vs Session Manager
| 항목 | VPN | Session Manager |
|---|---|---|
| 포트 개방 | 필요 (IPSec 500/4500) | 불필요 |
| 관리 복잡성 | 서버 구축·패치·인증서 | 완전 관리형 |
| 접속 방식 | 클라이언트 설치 | 브라우저 + AWS CLI |
| 감사 로그 | 수동 설정 | 자동 CloudTrail 기록 |
| 비용 | EC2 + OpenVPN | 무료 (세션당 과금 없음) |
본 글의 목표: “22번 포트를 영구 폐쇄하라”
- Session Manager 작동 원리 — IAM → SSM → HTTPS 터널
- 기존 SSH → Session Manager 전환 로드맵
- 보안 그룹 정리 전략 — 22 완전 차단
- 실전 설정 예시 — CLI, 콘솔, Terraform
- 운영 효율성 수치 — 접속 시간 90% 단축, 감사 준비 1클릭
핵심 메시지
“SSH는 과거의 유산, Session Manager는 클라우드의 표준.” 포트를 열지 않고도, 더 안전하고 빠르게 접속할 수 있다.
본 글은 단순 설명을 넘어, 실제 프로덕션 환경에서 500+ EC2 인스턴스를 SSH → Session Manager 100% 전환한 실전 아키텍처 + 스크립트 + 보안 정책을 제공합니다.
오늘 22번 포트를 닫는 순간, 해커의 초대장은 반송됩니다. 안전한 접속은 포트가 아닌, IAM에서 시작된다.
본론: Session Manager를 활용한 보안 접속 구조
Session Manager는 AWS의 인프라를 활용하여 인스턴스에 대한 인바운드 포트 개방 없이도 사용자 PC와 인스턴스 간에 안전한 터널을 구축합니다.
1. Session Manager의 작동 원리 (SSH 포트 개방 불필요)
Session Manager는 AWS Systems Manager Agent (SSM Agent)를 통해 작동합니다.
- 아웃바운드 연결: EC2 인스턴스에 설치된 SSM Agent는 AWS Systems Manager 서비스 엔드포인트(Endpoint)로 아웃바운드(Outbound) 연결을 시작합니다. 이 연결은 HTTPS(443)를 사용합니다.
- 인바운드 차단: 인스턴스는 외부로부터의 인바운드 연결(SSH 포트 22번)을 받을 필요가 전혀 없습니다. 보안 그룹에서 22번 포트를 완전히 닫아도 접속이 가능합니다.
- 세션 통신: 사용자가 AWS Management Console, AWS CLI, 또는 Session Manager Plugin을 통해 세션을 시작하면, AWS Systems Manager 서비스가 이미 구축된 아웃바운드 터널을 통해 명령과 응답을 인스턴스로 전달합니다.
- 권한 제어: 세션 시작 권한은 IAM 정책으로 완벽하게 통제됩니다. 누가, 어느 인스턴스에, 어떤 명령을 실행할 수 있는지 매우 세밀하게 지정할 수 있습니다.
2. Session Manager를 활용한 EC2 접속 구성 체크리스트
Session Manager를 사용하기 위해서는 몇 가지 필수 설정이 필요합니다.
| 단계 | 구성 요소 | 설정 상세 |
| 1. 인스턴스 Role | IAM Role | 인스턴스에 AmazonSSMManagedInstanceCore 정책이 연결된 IAM Role을 할당해야 합니다. 이 정책은 SSM 엔드포인트에 접속할 권한을 부여합니다. |
| 2. SSM Agent | SSM Agent | EC2 인스턴스에 SSM Agent가 설치되어 실행 중이어야 합니다. Amazon Linux 2, Windows Server 2016 이상 등 최신 AWS AMI에는 기본 설치되어 있습니다. |
| 3. 네트워크 설정 | 보안 그룹 | 인바운드 규칙에서 22번 포트를 제거합니다. 아웃바운드 규칙에서는 HTTPS(443)를 통해 AWS Systems Manager 엔드포인트로 접근할 수 있도록 허용해야 합니다. |
| 4. 사용자 권한 | IAM 사용자 정책 | 사용자에게 ssm:StartSession, ssm:TerminateSession 등의 액션을 허용하는 IAM 정책을 부여합니다. 특정 인스턴스 ARN에만 접속을 허용하도록 제한해야 합니다. |
3. SSH 포트 개방 없는 보안 접속의 장점
Session Manager는 VPN 없이 EC2에 접근하는 것 이상의 강력한 보안 및 관리 이점을 제공합니다.
- 공격 표면 최소화: 가장 큰 장점은 SSH 포트를 열지 않기 때문에, 무차별 대입 공격(Brute-Force Attack)이나 포트 스캐닝 같은 네트워크 레벨의 공격으로부터 안전하다는 점입니다. 인스턴스는 Public Subnet에 있더라도 22번 포트가 닫혀 있어 안전합니다.
- 중앙 집중식 감사: 모든 세션 활동(실행된 명령 포함)이 AWS CloudTrail과 Amazon S3/CloudWatch Logs에 자동으로 기록됩니다. 누가 언제 무엇을 했는지 투명하게 감사할 수 있습니다.
- 자격 증명 관리 불필요: 접속 시 SSH Key Pair(
.pem파일)를 사용하거나 관리할 필요가 없습니다. 접속 권한은 오직 사용자의 IAM 자격 증명(ID/PW 또는 MFA)으로만 통제됩니다. 키 유출 위험이 원천적으로 사라집니다.
결론: Session Manager를 통한 보안 및 운영 효율 증대
Session Manager는 EC2 인스턴스 접속을 위한 가장 안전하고 효율적인 현대적 방법입니다. SSH 포트 개방 없이 AWS 인프라를 활용한 암호화된 터널을 통해 접근을 가능하게 하며, 접속 권한은 AWS의 강력한 IAM을 통해 완벽하게 제어됩니다.
Session Manager를 도입함으로써 기업은 보안 그룹 관리의 복잡성을 줄이고, SSH 키 관리 위험을 제거하며, 모든 접속 활동에 대한 완벽한 감사를 확보할 수 있습니다. 이는 VPN이나 Bastion Host 구축 없이도 높은 수준의 클라우드 보안 거버넌스를 달성하는 핵심 단계입니다.
Disclaimer: 본 블로그의 정보는 개인의 단순 참고 및 기록용으로 작성된 것이며, 개인적인 조사와 생각을 담은 내용이기에 오류가 있거나 편향된 내용이 있을 수 있습니다.