여기서 다루는 내용
· AWS Session Manager 출시 소식
· AWS가 말하는 장점
· 기존 방식과의 근본적인 차이점
· 마치며
들어가며
안녕하십니까, GS네오텍 최준승입니다.
지난 주에 AWS에서 흥미로운 기능이 하나 출시되었습니다.
좀 더 정확한 표현으로는 AWS Systems Manager 서비스에 Session Manager라는 이름의 신규 Action이 추가되었습니다.
그게 대체 뭔소리냐구요? 예를 들면 이런겁니다.
AWS Management Console에서 EC2 인스턴스의 터미널 접속이 똭! 하고 됩니다. 신통방통하죠?
물론 이런 기능의 면면은.. 예전에도 AWS 서비스 곳곳에서 발견할 수 있었습니다.
IDE 환경을 제공하는 Cloud9 서비스에서도. 레이아웃에 터미널 view가 포함되어 있구요.
Run Command라는 기능을 통해 특정 커맨드를 OS 내부에서 실행하고 결과를 저장하는 것도 가능했었죠.
즉, 해당 기능을 제공하는데 기술적으로는 아무 문제가 없었다는 뜻입니다. 필요한 agent도 착실히 업데이트 되고 있었죠.
저는 1차적으로 이 기능을 테스트해보고.
왜 이리 사전조건이 많은지에 대해 짜증을 내고
어떤 형식으로 이 내용을 소개드릴지에 대해 고민하기 시작했습니다.
사실 포스팅은 전개시나리오 짜는 일이 70%입니다. 그래서 보통 글의 시나리오를 2-3일간 고민합니다.
그래서 시나리오가 그럴듯하게 나오면. 그 다음에 필요한 캡쳐를 따고. HTML 작업을 해서(?).. 막노동으로 글을 마무리합니다.
아마 평이한 시나리오였다면. 오늘 글은 이렇게 흘러갔을 겁니다.
- 도입: 잡담 좀 하고.. AWS 시스템 매니저에 세션 매니저가 출시되었다
- 전개: 서비스 컨셉은 대충 이렇다. 잘 이해가 안갈테니 데모를 보여드리겠다
- 절정: 전제조건은 이렇다. 이거 다 설정하고. 이거 클릭하면. 똭! 하고 터미널 나온다
- 결말: 신기하죠? 이 기능은 이럴때 쓰면 좋겠다. 이런건 조심해야 할 것 같다. 읽어줘서 고맙다
그런데 오늘만큼은 이렇게 하고 싶지가 않습니다. 좀 장황하긴 하지만 설정 방법은 AWS가 충분히 잘 써놨습니다.
저는 오늘 이 서비스의 컨셉과 장단점에 대해서만 얘기하려고 합니다.
AWS가 말하는 AWS Systems Manager Session Manager
AWS 링크에서 정리한 사전적인 의미부터 봅시다. 설명 편의상 하나의 문장을 3개로 쪼갰습니다.
- Session Manager is a fully managed AWS Systems Manager capability → 완전 관리형 기능
- that lets you manage your Amazon EC2 instances → 매니징 대상은 EC2
- through an interactive one-click browser-based shell or through the AWS CLI → 웹브라우저에서 원클릭 or AWSCLI로
좀 더 읽어보면 이 서비스의 베너핏(benefit)은 이렇게 써놨습니다. 하나씩 차근차근 보시죠.
- Centralized access control to instances using IAM policies
ACL을 한곳에서 관리할 수 있다. IAM Policy로.
즉 어느 인스턴스에 어떤 사용자가 Access할지를 IAM Policy로 제어하겠다는 말입니다
- No open inbound ports and no need to manage bastion hosts or SSH keys
터미널에서 사용하는 포트로 인바운드 정책을 열 필요가 없다
Bastion Host도 필요없다 SSH 키도 필요없다
- One-click access to instances from the console and CLI
원클릭으로 빠르게 접속.
안그래도 클라이언트 프로그램 열고. 사용자명 넣고 키파일 지정하고 귀찮았는데. 우왕굿
- Cross-platform support for both Windows and Linux
하나의 플랫폼으로 윈도우/리눅스 둘다 접근 가능
- Logging and auditing session activity
접속 기록을 포함하여 내부에서 수행했던 Activity 정보도 수집 가능
저장소로 S3나 CloudWatch Logs를 사용
좋습니다. 장점이라고 써놨으니 당연히 좋겠죠.
이제 이와 관련된 썰과. 이걸 가능하게 하는 구조와. 미리 설정해야 하는 것들에 대해 자유롭게 적어보겠습니다.
기존 방식과의 근본적인 차이점
우선 기존 방식과 가장 근본적인 차이점은
세션을 Client → EC2 인스턴스 방향이 아니라 EC2 인스턴스 → AWS SSM Endpoint 방향으로 맺는다는 점입니다.
그림으로 표현하면 이렇습니다.
- EC2가 Public Subnet에 있다면 IGW를 통해 인터넷 구간에 있는 SSM Endpoint와 세션을 맺습니다
- EC2가 Private Subnet에 있다면 NAT Gateway를 통해 IGW를 거쳐 인터넷 구간의 SSM Endpoint와 세션을 맺거나
- 아님 VPC Endpoint를 통해 내부적으로 샤바샤바해서 SSM Endpoint와 세션을 맺는 방식입니다
즉, EC2 인스턴스가 Security Group만 사용하는 환경이라면 AWS의 SSM Endpoint로 Outbound 포트만 열려 있으면 된다는 얘기
이것은 실제 접속해서 netstat을 때려봐도 확인되는 사항입니다.
※ 여기 표시되는 52./54. IP는 AWS 자산의 IP 주소대역입니다.
따라서 Client는 EC2 인스턴스와 직접 얘기하지 않습니다.
EC2 인스턴스는 AWS와 얘기하고. Client도 AWS와 얘기합니다.
그리고 AWS는 마치 EC2 인스턴스와 Client가 얘기하는 것처럼 중간에서 에뮬레이션 하는 셈입니다.
근본적으로 이 구조기 때문에. 위에서 얘기한 5가지 장점들을 만들 수 있게 됩니다.
- Client는 AWS와 API로 얘기하기 때문에 IAM Policy로 권한을 제어할 수 있고
- Client는 EC2와 통신하지 않기 때문에 별도의 ACL이 필요 없으며
- Client는 OS와 무관하게 AWS가 통합해서 제공하는 인터페이스를 통해 EC2에 접근할 수 있고
- AWS는 중간자기 때문에. 서로 하는(것 같은) 얘기들을 별도로 저장할 수 있습니다
별거 아닌 내용을 너무 길게 설명했네요.
마치며
이제 마칠 시간입니다.
이렇게 얘기하면 안되지만 이 기능은 마치 백도어를 보는 기분입니다. 아니 착한 뒷문 정도로 순화를. 하겠습니다.
보통 서비스 환경에서 방화벽 인바운드 정책은 엄격하게 운용되기 때문에.
1차 침입을 통해 악성코드를 심게 되면. 아웃바운드 방향으로 C&C 서버와 세션을 맺습니다.
아웃바운드 정책은 제어하기가 쉽지 않기 때문에. C&C의 도메인은 유지한채로 IP값을 바꿔가며 관리하게 되지요.
그리고 C&C 서버를 통해 2차 툴을 심거나. 아님 다른 온갖 형태의 원격 조종을 하게 됩니다.
AWS System Manager도 이 루트를 통해 패치도 관리하고 커맨드도 실행하고 여러가지 착한 관리활동을 할 수 있습니다.
AWS에서 제공하는 SSM Agent의 경우 일부 AMI에는 기본적으로 포함이 되어 있습니다.
따라서 EC2에 적정한 IAM 권한을 부여하고. SSM Endpoint와 통신을 할 수 있게 하면 기본적인 환경 구성이 완성됩니다.
몽둥이도 좋은데 쓰면 도구가 되고 나쁘게 쓰면 무기가 되듯이
이 기능도 엄격하게 권한을 통제하고. 일원화된 관리툴로 활용한다면 정말 유용한 도구가 되지 않을까 싶어요.
AWS는 아주 착실하게.. 관리적인 영역까지 전체적인 큰 그림을 잘 그리고 있습니다.
새로운 방식이 보안상 이슈가 없다면.
여러분도 이런 기능을 통해 새로운 방식의 클라우드 통합 관리환경을 구상해 보시는건 어떨까요?
마칩니다. 끝!
