이 글에 대해 코멘트 준 분이 계셔서 여기에 답장을 남깁니다. 댓글 다는 사이에 코멘트를 삭제하셔서 답장을 쓸 곳이 여기 외에 마땅치 않군요.
AWS의 각 서비스는 특정 요구 사항에 맞게끔 만들어져 있습니다. SSM은 일반 사용자가 특정 인스턴스를 운영/관리하기 위한 용도가 아니라, “Ops팀이 전체 시스템을 효율적으로 관리하거나 모니터링하기 위한 용도”로 만들어진 것입니다. 개별 사용자에게 ssh 연결 기능을 대체하거나, 편의에 따라 권한을 나눠주는 용도로 사용하는 것은 매우 위험합니다.
즉, SSM agent는 전체 시스템의 패치나 업그레이드, 개별 사용자의 ssh 접근에 대한 보안 감사 모니터링 등의 용도로만 사용해야 합니다. 회사 내에 자원 운영 매뉴얼이 있고, 보안 감사가 동작하는 구성에서 전체 시스템을 운영할 때 용이한 서비스 입니다.
AWS의 각 서비스는 특정 요구 사항에 맞게끔 만들어져 있습니다. SSM은 일반 사용자가 특정 인스턴스를 운영/관리하기 위한 용도가 아니라, “Ops팀이 전체 시스템을 효율적으로 관리하거나 모니터링하기 위한 용도”로 만들어진 것입니다. 개별 사용자에게 ssh 연결 기능을 대체하거나, 편의에 따라 권한을 나눠주는 용도로 사용하는 것은 매우 위험합니다.
어떤 취지에서 이야기하시는지는 압니다. 그러나 이러한 문제제기는 제가 아니라 AWS 측에 하는 편이 맞다고 봅니다. SSM이 처음 나왔을 때는 aws ssm send-command 와 같이 시스템 자동화의 측면이 강했습니다. 그러나 이후에 Session Manager를 ssm-agent에 얹고 한술 더떠 ssh까지 얹고 나서는 접근제어 솔루션의 측면이 강해졌습니다. 이는 AWS의 Session Manager 문서만 봐도 확실합니다.
Centralized access control to instances using IAM policies
Administrators have a single place to grant and revoke access to instances. Using only AWS Identity and Access Management (IAM) policies, you can control which individual users or groups in your organization can use Session Manager and which instances they can access.
“편의에 따라 권한을 나눠주는 것은 위험하다”고 하셨지만 AWS 의 공식 문서는 개인과 그룹이 인스턴스에 접근하는 용도로 쓰라고 권합니다. 게다가 다음 문단에서는
No open inbound ports and no need to manage bastion hosts or SSH keys
Leaving inbound SSH ports and remote PowerShell ports open on your instances greatly increases the risk of entities running unauthorized or malicious commands on the instances. Session Manager helps you improve your security posture by letting you close these inbound ports, freeing you from managing SSH keys and certificates, bastion hosts, and jump boxes.
아예 Bation과 SSH와 직접적으로 비교하며 Session Manager의 이점을 강조합니다. 상황이 이렇다 보니 왓챠에서도 SSM과 SSH를 나란히 놓고 비교하는 글을 쓰고, 왓챠가 아니더라도 이와 비슷한 글을 찾기는 전혀 어렵지 않습니다.
태생이 시스템 관리와 자동화이기 때문에 말씀하신 바와 같은 문제가 있다는 점을 저도 지적하고 싶었습니다. 대신 지적해주셔서 고맙습니다. 다만 이 부분은 제가 아니라 AWS가 답해야 할 문제라 생각합니다.
