ssh와 AWS SSM Agent의 장단점을 비교해보자.
SSM Agent 우세
SSM Agent는 AWS IAM으로 통제한다. IAM은 SAML 등 SSO 서비스와 연계할 수도 있으니 기업의 보안체계를 구축하는데 큰 도움이 된다. 물론 ssh 서비스를 고도화하는 다른 기업용 서비스가 있긴 하다. 하지만 어차피 AWS를 이용하는 입장에선 별개의 시스템을 두고 비용까지 추가로 지불하는 상황이 달갑지 않을 수 있다.
ssh와 달리 Bastion 또는 VPN과 같이 외부로 노출되는 진입점이 불필요하다. 실질적으론 AWS가 관리하는 진입점이 있긴 하지만 우리가 관리할 필요는 없다.
AWS Console에서 바로 서버에 접속할 수 있다. 터미널을 쓰지 않아도 된다.
ssh 우세
Root 볼륨이 Disk full 났을 때 접속이 안 된다. ssh 덕분에 살았다.
SSM Agent는 세션 로그를 CloudWatch Logs에 남긴다. 그러니까 감사로그를 제공한다. 일반적인 ssh 구현보다 보안상 낫지만 세부사항을 들여다 보면 몇 가지 문제가 있다. SSM Agent는 세션을 종료할 때 로그를 한번에 정리해서 올린다. 그런 까닭에 실시간 칩입탐지에는 적합하지 않다. 공격자가 세션을 끊지 않으면 로그가 기록되지 않는다. 며칠 뒤에나 클라우드워치 로그에 올라갈 것이다. 이런 구현에는 또다른 문제가 있다. 표준입출력이 많은 작업을 반복한 후에 세션을 정리하고 로그를 한번에 정리하다 보면 메모리가 부족해서 서비스에 악영향을 주기도 한다. 운이 없다면 OOM (Out of memory) 가 발생해 서비스가 다운될 수도 있다.
접속여부 자체는 CloudTrails 에 기록된다. 일반적으로 이벤트 발생시점으로부터 15분 정도 지나야 CloudTrails에 로그가 기록되므로 실시간 감시를 원한다면 별도의 조치가 필요할 수 있다. 물론 sshd 의 기본 구현은 감사기록 자체를 제공하지 않으므로 어떤 의미에선 SSM Agent가 낫다고 볼 여지가 있다.
SSM Agent는 기본적으로 root 사용자 권한으로 실행한다. SSM Agent로 접속할 권한이 있다는 말인즉 당신이 root 사용자란 것이다. Linux 가 제공하는 다양한 사용자 권한 체계를 활용할 생각은 말아야 한다.
SSM Agent는 scp와 달리 직접 파일을 업로드할 수단이 없다. S3 버켓을 이용하거나 SSH over Session Manager 라는 기능을 이용해야 한다. 후자는 말이 좋아 ssh 이지, SSM부터 설정한 후에 거기에 얹어서 ssh 를 추가로 설정해야 하기 때문에 관리하기 쉽다곤 말하기 힘들다.
참고
- Goodbye SSH, use AWS Session Manager instead | cloudonaut
- Using AWS Session Manager with Enhanced SSH and SCP Capability
