SSM으로 EC2 ssh 로그인 하기

https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html

세션 시작 - AWS Systems Manager

 

22번 포트를 열어두는 행위는 어느 서버던 그리 좋은 방법은 아니다.

이번에 ISO 27001 인증을 준비하며 해당 이슈에 대한 부분을 정리해야 할 케이스가 발생했다.

 

- ssh 접근시 어떻게 대처하고 있는가?

- ssh 접근시 로그를 어떻게 남기고 있는가?

 

각자 사정에 따라 다르겠지만, 보통 대부분 이렇게 처리 하고 있을 것 같다.

 

1. 22번 포트를 사무실 IP만 열어두기

2. 22번 포트를 모두 열어두기 (AWS에서도 경고가 표시 됨)

3. bastion host 22번 포트만 사무실로 오픈 후 나머지 서버에 대해서 bastion host IP만 22번 포트 오픈

 

1번 : VPN이 없으면 무슨 일 발생시 사무실에 와야 하는 것이고, Private Subnet에 있는 EC2는 접근이 불가능하다.

2번 : 22번 자체가 열림으로서 포트 스캔시 해커에게 노출이 될 수 있다는 것이고, Private Subnet에 있는 EC2는 접근이 불가능하다.

3번 : 1번과 동일.

 

나의 경우엔 3번에 해당했다.

 

사실 이 경우에 가장 강력한 해결 방법은 22번 포트를 막는 것이 가장 근본적인 방법인데, 이 방법을 해결한 내용에 대한 것을 정리한다.

 

1. EC2에 SSM이 가능한 IAM 생성

먼저, EC2를 생성하면 아무 서버나 눌러서 IAM 역할이 무엇인지 확인하자.

https://ap-northeast-2.console.aws.amazon.com/ec2/home?region=ap-northeast-2#Instances:instanceState=running;v=3;$case=tags:true%5C,client:false;$regex=tags:false%5C,client:false 

https://ap-northeast-2.console.aws.amazon.com/ec2/home?region=ap-northeast-2#Instances:instanceState=running;v=3;$case=tags:true%5C,client:false;$regex=tags:false%5C,client:false

 

IAM 역할에 아무것도 없다면, 무엇인가를 넣어줘야 한다.

 

IAM 역할 수정을 눌러 보자.

 

비어 있는 것이 있다면, 새 IAM 역할 생성을 눌러 역할 만들기를 클릭한다.

EC2를 선택하고 다음으로 넘어간다.

일단 EC2는 읽을 수 있어야 하니, AmazonEC2ReadOnlyAccess가 필요하다.

이름을 넣고 저장을 하면 이런 식으로 만들어진다.

그 다음엔 실제 ssm:startSession 권한이 필요하다.

startSession 관련 관리형 정책이 없으므로 위의 우하단의 권한 추가를 눌러서 정책을 추가로 생성해야 한다.

inline 정책으로 만들어도 상관 없지만, 인라인으로 만들면 나중에 관리가 복잡해지므로 일단 정책을 추가하는 것으로 가자.

https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/getting-started-restrict-access-examples.html

Session Manager에 대한 추가 IAM 정책 샘플 - AWS Systems Manager

이 문서에 자세한 샘플이 나와 있는데, 이 곳에서 취할 수 있는 전략을 이용해 추가로 권한을 생성한다.

일단 되는 과정이 보여야 하므로 문서 중 예 5: 모든 세션에 대한 전체 (관리) 액세스 허용을 이용하도록 하자.

다음을 눌러 이름까지 입력하면 된다.

그 다음 아까 만든 역할을 다시 선택한 뒤 정책을 추가하자

test-ssm-role이란 이름으로 만들어봤다. 클릭한 다음 권한 추가를 눌러서 추가한다.

 

2. EC2에 Profile 추가

이제 EC2로 넘어와서 서버를 클릭한 뒤 IAM 역할 수정을 다시 선택하자.

아까 만든 역할이 표시된다면, 그 역할을 선택하고 IAM 역할 업데이트를 적용하면 된다.

 

3. amazon-ssm-agent 설정

이렇게 하면 바로 될 줄 알았지만, 그렇지 않다. 왜냐하면 amazon-ssm-agent가 켜져는 있지만 새로 올리지 않아서 활성화 되지 않는 것처럼 보이기에 아래와 같은 표시가 나올 수 있다.

이땐 서버에 직접 접속하여 아래와 같은 절차를 수행해야 한다.

 

다시 연결을 눌러서 들어가려 해보자.

인스턴스가 클 수록 적용이 좀 오래 걸려서 노란 화면이 나올 수 있지만, 3 ~ 5분 정도 기다리면 이런 화면이 나오면서 접근이 가능하다.

 

연결을 누르면 이렇게 나온다.

os에 맞게 기본 id로 로그인 하면 된다.

 

 

 결과는 위와 같은 구조로 되어 있다.

 

장점

- 서버의 22번 포트를 물리적으로 열지 않아도 되어 훨씬 보안적으로 접근이 가능하다.

- AWS IAM의 접근 제한을 추가하여 논리적으로 접근 제어 관리가 가능하다.

- Session Manager 기능에서 서버의 로그인에 대한 유저 정보가 자동으로 로그화 되어 감시가 가능하다.

- 의심되는 유저의 세션을 강제로 끌 수 있다.

 

단점

- 처음부터 안되어 있다면 모든 서버에 대해서 다시 설정 해주어야 함.

- IAM Profile은 한개만 설정하게 되어 있으므로, Role이 중복되는 경우엔 해당 Role을 통합하던 하여 조정해야 함.