[DevOps] SSH 없이 안전하게 EC2 운영하기: SSM 기반 접근 제어와 전역 정책 설계

개요

---

서비스가 점점 커지면서 개발자의 다양한 PoC 니즈를 충족하기 위해, EC2 Instance Self-Service 기능을 준비했다. 프라이빗 환경에서 서버가 뜰 테지만, 아무래도 서버를 오픈하는 건 여러 위험성이 있기에 작업 전에 테크 스펙을 작성해서 여러가지 인프라/보안 이슈에 대해 검토했다. 그 중에서도 가장 레슨런이 많았던 Session Manager와 SSM Logging에 대해 정리해보려고 한다.

 

1. EC2 Instance 접근 방식

---

EC2 Instance에 접근하는 다양한 방식이 있다.

1.1 EC2 Instance Connect (문서)

브라우저 기반 SSH 연결 방식으로, AWS가 일시적인 SSH 퍼블릭 키를 자동 생성하여 60초간 인스턴스 메타데이터에 푸시한다. SSH Client와 다른 점은 직접 .pem과 같은 Key를 사용하는 것이 아니라, 사용자는 IAM Role을 통해 SSH에 접근 권한을 평가 받는다. 

• 콘솔 연결 시, Public IP 주소가 필요
• 인바운드 22포트 허용 필요
• `ec2-instance-connect:SendSSHPublicKey` 권한 필요
• CLI 명령어로는 다음과 같이 접근 가능

aws ec2-instance-connect ssh --instance-id i-1234567890example

 

• 인스턴스 커넥트를 사용할 때는 endpoint가 필요한데..! 이거 작업 추기로 해보기

1.2 Session Manager (문서)

AWS SSM의 기능으로, SSH 키 없이 IAM 기반으로 인스턴스에 접근하는 방식이다. HTTPS(443) 프로토콜을 사용한다.

• 인바운드 22 포트 개방 X
• Public IP 불필요
• SSM Agent 설치 필수
• IAM 역할 필수
• CloudWatch, S3로 세션 로깅 가능

 

1.3 SSH Client (문서)

SSH 프로토콜을 사용해서 로컬 터미널에서 직접 인스턴스에 연결하는 방식이다.

• 키 페어 파일(.pem) 필수 -> 사용자가 키 직접 관리
• 인바운드 22 포트 필요
• Public IP or Pirvate 경로 필요
• 로컬 SSH 클라이언트 사용(OpenSSH, PuTTY 등)

 

1.4 EC2 Serial Console (문서)

인스턴스의 직렬 포트(serial port)에 직접 접근하는 방식이다. 특이한 점은 네트워크 연결 없이 인스턴스 접근이 가능해서, 네트워크 장애 시 유용한 접근 방법으로 통한다.

• 계정 수준에서 명시적 활성화 필요
• 인스턴스당 1개의 동시 세션만 허용
• 인스턴스가 반드시 running 상태여야 함

 

항목	Instance Connect	⭐️ Session Manager	SSH Client	Serial Console
네트워크 필요	필수 (퍼블릭 IP)	필수 (Private 가능)	필수	불필요
키 관리	자동 (60초 임시)	불필요	수동 (.pem)	SSH 키 또는 패스워드
인바운드 포트	22 필요	불필요	22 필요	불필요
주 용도	간편 SSH 접속	대규모 관리	전통적 접속	부팅/네트워크 장애 해결
IAM 인증	O	O	X	O

 

 

2. Session Manager 적용과 그 이유

---

2.1 Session Manager가 필요한 이유

⚫️ 기존 SSH 접근 방식의 한계

기존 SSH 기반 EC2 접근 방식은 다음과 같은 문제점이 있다.

• Private Subnet 환경에 있는 인스턴스에 접근하기 위해서는 따로 전용 서버 운영이 필요하다.
• EC2 인스턴스마다 Key Pair 생성 및 안전한 보관이 필요하다. (만약 키가 노출된다면...! 😱)
• Key 사용을 위한 Inbound Port 22 오픈이 필요하다.
• 접속 로그나 실행 명령어를 추적할 방법이 부족하다.
• 해당 인스턴스 사용자가 증가할 수록 키/권한 관리가 복잡하다.

Inbound 22 Port 오픈이 왜 위험할까?

• 22번 포트를 여는 것은 외부에서 SSH로 해당 서버에 접속할 수 있도록 허용하는 것을 의미하기 때문이다.
• SSH(Secure Shell) 서비스의 표준 포트로, IANA(Internet Assigned Numbers Authority)가 공식 할당한 포트 번호다. 

⚫️ SSM Session Manager 이점

• 인바운드 포트를 열 필요가 없고, HTTPS(443) 프로토콜을 사용하여 추가 포트 개방이 불필요하다.
• EC2 인스턴스의 Public IP 주소도 필요없다.
• IAM 기반으로 조직 내에 어떤 구성원이 세션을 시작할 수 있는지, 어떤 노드에 접근할 수 있는지 제어가 가능하다.
• CloudWatch Logs, S3 버킷을 통한 모든 세션 활동을 기록할 수 있다.

위와 같은 이유로 SSM Session Manager를 활용하여 Session 을 시작한 모든 ① 사내 유저 Id와 ② 해당 로그를 기록하도록 설정하였다.

 

2.2 Session Manager 동작 방식

먼저 Session Manager 동작 방식을 살펴보자.

 

• 유저가 SSM으로 인스턴스에 접근하기 위해 가장 처음하는 것이 StartSession API 호출이다.
  • Session API를 호출하면, Session Manger가 Stream URL과 토큰을 return한다. 유저는 이 값으로  Session Manager에 Websocket 연결을 하고, Session Manager를 프록시로 사용하며 인스턴스와 소통한다.

{
   "SessionId": "string",
   "StreamUrl": "string",
   "TokenValue": "string"
}

 

• EC2 Instance에 연결된 IAM Role을 통해 Session Manager와 통신하는 데 필요한 권한 & 세션 로깅 권한을 설정한다.
  • SSM Agent가 인스턴스를 시작할 때, Instance Profile에 연결된 IAM Role을 assume한다. 이 권한으로 Session Manager 서비스에 아웃바운드 연결하고, WebSocket 채널을 유지할 수 있게 된다. (Instance Profile에 대한 글!)
  • 세션 로깅이 활성화된 경우에는 버킷에 접근할 권한이 필요하다.
  • 세션 데이터 암호화를 활성화했다면, 세션 데이터 암복호화 권한이 필요하다.

 

3. Session Manager를 통한 Session 로깅 & 모니터링 설정

---

 

3.1 AWS System Manager의 Session Manager 설정

System Manager는 계정・리전 단위로 설정된다. 필자가 속한 회사의 경우 Alpha, Prod 두 환경을 운영하고 있기에 각각의 계정과 KR, JP, CA, GB 리전에 대해 설정해주었다.

 

필자의 경우 General Preferences, S3 logging 부분을 활성화 해주었다.

 

⚫️ General Preferences

 

가장 첫 번째 옵션은 세션 데이터를 KMS 키로 암호화하는 것에 대한 설정이다. 이 설정을 하지 않으면 세션 데이터가 평문으로 전송/저장되어, 보안을 위해 활성화하였다.

• 사용자와 EC2 인스턴스 간 주고받는 모든 명령어와 출력이 암호화된다. 
  • SSM 접근 및 통신을 위해 KMS 암복호화 관련 권한이 추가로 요구된다.
• S3에 저장되는 세션 로그가 암호화되어 저장된다.

 

⚫️ S3 Logging

SessionLog에 대한 정보를 볼 수 있다. 누가, 언제, 어떻게 접근하였고 어떤 명령어를 썼는지 모두 확인 가능하다.

 

해당 이미지가 그 예시다. Session Manager의 S3 Logging 활성화를 통해서 위와 같이 session을 시작한 사내 이메일과 접속 시각, 로그를 확인할 수 있다.

여기서 주의할 점은 이러한 Session 데이터를 남겨서 보안 이슈에 대응할 수 있지만, 그 반대로 Session 데이터가 노출되면 보안 위험에 처할 수 있다. 따라서 해당 버킷 접근 권한은 root 계정과 보안팀 일부 구성원들로 한정했다.

 

4. 마주한 문제

---

Session 암호화 & Logging을 전역 설정하다보니… 글로벌 리전에 대한 SSM 접근이 실패하는 현상을 겪었다.

4.1 트러블 슈팅을 위해 SSM으로 접근했는데 실패

 

4.2 HAProxy Ansible 실패

 

4.3 [해결법] SSM 접근을 위한 전역 공통 IAM Policy 정의 및 등록

AWS 여러 계정/리전을 함께 운영하면서 많이 헷갈려왔던 것인데..!

각 AWS System Manager는 각 리전/환경별로 설정되는 값이기 때문에 모든 환경/리전에 대한 관련 권한을 등록해야한다.

IAM Role의 경우 글로벌 서비스여서... SSM 접근을 위한 공용 Policy를 설정하였다.

 

1) ⭐️ 최소 권한만 갖도록 Policy 정책을 재정의

모든 인스턴스가 물고있는 Role에 부여할 Policy이므로, 보수적으로 접근하여 허용할 권한(JSON)을 작성하였다.

허용한 목록은 다음과 같다.

• AmazonSSMManagedInstanceCore
• KMSEncryptionForSessionManager
• S3BucketAccessForSessionManager
• S3EncryptionForSessionManager

 

2) 환경/리전별로 공용 Policy가 바인딩 되지 않은 Role을 추출 및 적용

• SSM 접근이 필요한 인스턴스가 물고있는 Role에 대해서만 적용하였다.

기존 Policy에 부족한 권한을 추가하는 일이라 장애는 없을 테지만, Sciprt 대상 목록을 추출해서 공유

그리고 해당 목록을 공유하고, 공지 후에 작업 진행!

 

3) 접근 권한 부여 완료...!

 

 

5. 레슨런

---

• 이번 일을 하면서 인프라의 표준화와 정책의 중요성을 알게되었다. 하나의 작업을 할 때에, 다양한 관점에서 고민하고 일관된 정책을 적용해본 특별한 경험이었다. 옆의 팀원들이 정책을 잘 설계하는 것과 기술 부채를 고민하는 모습들을 종종 보았는데 왜 그러한 고민들을 하는지 온전히 이해할 수 있게 되었다.
• 특히 보안 관점에서는 기존의 나라면 SG이나 Inbound 정도 고민했었을 텐데, 다양한 보안 고려사항을 알 수 있게 되었다. AMI, CroudStrike, 접근 방식, 표준화된 인프라 등등... 
• 그리고 SSM 동작 방식에 대해 깊이 있게 살펴본 점도 도움되었다. 원래는 그냥 SSM을 사용했다면 이제는 왜 SSH가 위험한지, SSM은 어떠한 문제가 있는지 고민할 수 있게 되었다.
  • 그래서 좀 더 구체적으로 고민이 드는 것은 SSM 접근은 ssm-agent가 정상 상태일 때만 가능하기 때문에 대책/가이드 필요하다는 것이다. 요고는 조금 더 신경써서 공부하고 챙겨보려고 한다.
  • (추가 작성) 당장 경험으로는 일단 4가지 접근 방식 중 4번이 간단하긴 한데, 너무 느린 점. 1번의 경우에는 커넥션을 위한 엔드포인트가 필요하다. 이것도 공용으로 미리 만들어 두는 게 좋을지..?