왓챠에서 WATCHA 서버 접속을 위한 CLI 와 SSH 인증서버 소개라는 글을 썼길래 나도 SSM Agent vs. ssh에 이어 몇 가지를 더해 요약해보려 한다.
AWS Systems Manager는 ssh와 달리 우리가 직접 Endpoint를 생성해 노출하지 않아도 되므로 외형상 ssh에 비해 더 안전하다. 그러나 보안에는 여러 측면이 있다. 다른 측면도 종합적으로 검토하고 판단해보자.
SSM Agent는 ssh와 달리 사용자별 구분을 두지 않는다. Systems Manager로 접속한다는 말은 Linux의 root 사용자로 접속한다는 말이다. root 사용자는 접속을 금하고 일반사용자로 접속한 후 sudo 등으로 권한을 상승하길 권하는 ssh 의 일반적인 권장사항과는 차이가 있다.
거기에다 SSM이 작동하기 위해선 상당한 권한을 EC2 Instance Profile에 부여해야 한다. IAM 정책의 세부사항을 들여다 보면 매우 침투적임을 깨닫게 된다. 한 인스턴스가 뚫렸을 때 그 파급효과가 어마어마할 수 있다. 게다가 IAM 정책을 어떻게 손봐야 이런 문제를 해결할 수 있는가 하는 문제로 넘어가면, 결론적으로 말해 그다지 희망이 없다. 구구절절 설명하긴 힘든데 문제가 여럿 있고 이를 해결하는데 도움이 되는 베스트 프랙티스를 찾기 힘들다. 베스트 프랙티스라고 하는 문서는 몇 개 있지만 대부분 터미널 접속자의 권한을 제한하는데 초점을 맞춘다. ssm-agent에 부여하는 IAM 권한을 통제해야 EC2 인스턴스 하나가 침투당하더라도 그 여파를 제한할 수 있는데 그런 주제를 다룬 자료를 찾기 매우 어렵다.
세션 로깅에 대해선 지난 편에 이야기했지만 다시 정리해보자. 세션 로깅은 규제 이슈에 대응할 때 편리하긴 하나 실질적으로는 그 이상도 그 이하도 아니다. 표준입출력을 로그로 남기는데 로그 분량이 상당하기 때문에 분석이 쉽지 않다. 분석을 한다 해도 단순한 키워드 분석에 그칠 것이다. 하지만 공격자는 rm -rf 같은 단순한 공격을 하지 않는다. 보통은 서버 탈취 후 http://github.com 등 흔히 방화벽 화이트리스트에 있을 법한 공개 사이트에서 툴킷을 받아 자동화된 공격을 감행한다. 이런 경우에는 시스템호출 자체를 모니터링해야지 표준입출력을 모니터링해서 될 일이 아니다.
세션 로깅은 실시간 탐지용은 분명 아니다. 세션을 끊고 한참 뒤에 로그가 쌓이기 때문이다. 공격자가 세션을 끊지 않으면 탐지가 안 된다. 이런 구조로는 실시간 탐지는 어렵다. 감사 로그를 확보하라는 규제 상의 요구사항은 만족할지 몰라도 보안을 진지하게 생각하는 곳에선 결코 충분치 않다. 결국에는 osquery 같은 도구를 이용해 실시간 모니터링을 강화해야 한다.
결론적으로 SSM은 쓸만한 도구이긴 하다. 그러나 단점도 분명하므로 조직에서 구축하려 하는 보안체계에 부합하는지 면밀하게 검토하고 도입할 필요가 있다.
대안
글을 마무리하고 나니 어쩐지 아쉬운 마음이 들어 몇 가지 대안을 제시하려 한다.
- Scalable and secure access with SSH – Facebook Engineering
- keybase/bot-sshca: A chat bot that can manage your team’s SSH accounts
- widdix/aws-ec2-ssh: Manage AWS EC2 SSH access with IAM
- 편리하게 AWS EC2 인스턴스의 접속 관리하기
SSH PAM 스크립트를 활용하는 방법도 있다. Okta 또는 OneLogin 는 Radius, LDAP, API 인증 등을 지원한다. PAM 스크립트에서 IDP가 제공하는 인증 서비스를 연계하여 방벽을 추가하는 방안도 있다.
한마디 더
이 글에 대해 코멘트 준 분이 계신다. 댓글 다는 사이에 코멘트를 삭제하셔서 답장을 블로그에 적는다.
