최소한의 AWS 보안: Bastion Host

1. 도입 계기

처음 Bastion Host를 알게 된건 패스트 캠퍼스의 강의에서 였다. 그때 강사님께서 사용하시는 걸 보고 조금 공부를 한 후 이것이 보안 조치였다는 걸 알게 되었다. 마침 처음 도메인 주소가 있는 프로젝트를 만들어 보려고 한 나는 보안에 관해 전무 하다는 사실이 막연히 조금 두려웠었다. 

 

이에 최소한의 보안 설정을 해보자고 선택했던 Bastion Host. 이게 최선의 보안설정은 아니더라도 이때나 지금이나 Bastion Host를 사용한다면 가장 큰 이유는 SSH 접속시 어플리케이션 서버의 IP를 외부에 노출하지 않아도 된다는 점이 큰 것같다. On-Premise에서 Bastion Host를 만든다면 그 라우팅, 인증, 로그등 다양한 기능들을 하도록 할 수도 있겠지만 다양한 서비스가 제공되는 AWS 환경에서 이유를 찾자면 그렇다고 생각한다. 사실, AWS에서는 SSH 접속을 할 수 있는 다른 좋은 대안도 존재 한다. 그러나 기능들이 익숙하지 않은 상황에서 손쉽게 적용할 수 있는 최소한의 보안 조치 중 하나라고 생각한다. 

 

지금 생각해보면 AWS에는 참 많은 보안 기능들이 적용되어 있다. 불편하게만 여겼던 보안 정책이나 IAM들이 사용하다 보면 다 이유가 있었구나 싶다. 

 

2. 방화벽의 구성. 

IP를 숨길수 있다는 사실에 Bastion Host를 선택하긴 했지만 보안에 자신이 있지는 않았고 방화벽에 대해 조금 더 알아보고 싶었다. 방화벽의 구조는 크게 5가지가 있었는데 자세히 들여다 보면 AWS에서 서비스 해주고 있는 것과 비슷한 점도 많다고 생각했다. 

 

-1. 스크리닝 라우팅(Screening Routing)

 

내부망과 외부 사이에 라우터를 설치하고 ACL(Access Control List)을 만들어 특정 패킷의 통과를 허용하거나 거부할 수 있다.  IP헤더와 TCP헤더에서 정보를 수집하여 OSI 3(네트워크), OSI 4(전송) 계층에서 동작하기에 빠른 처리가 가능하지만 패킷 전달 능력을 떨어뜨려서 인터넷 접속 속도를 떨어뜨리고 패킷 데이터 공격에는 취약하다. 또한, 복잡한 정책을 구현하기 힘들다. ACL은 순차적으로 리스트를 비교하여 패킷의 폐기 또는 전달의 여부를 결정하기에 순서가 중요하다. 

 

-2. 싱글 홈드 게이트웨이(Single Homed Gateway)/ 베스천 호스트(Bastion Host)

베스천 호스트는 내부 네트워크가 유일하게 외부와 연결되어 있는 연결점이다. 공격자의 목표가 되기 쉽기에 불필요한 사용자 계정이나 명령들을 올리지 않고 라우팅 기능 사용시 주의 하여야 한다. 베스천 호스트를 이용시 이용자에 대한 강화된 인증과 모니터링을 할 것이 권장 된다. 베스천 호스트는 OSI 7(어플리케이션) 계층에서 동작하여 사용자의 인증을 구현할 수 있고 데이터 공격에 방어  수 있으며 로그를 남기기 쉽다. 그러나 공격 당하면 내부 네트워크 자원 보호가 불가능 하여 관리자에 의한 지속적인 점검이 필요하다. 

 

-3. 듀얼 홈드 게이트웨이 (Dual Homed Gateway)

내부 통신용과 외부 통신용 두개의 네트워크 인터페이스를 가진 베스천 호스트를 이용하는 방법으로 서비스마다 프록시 서버를 이용하여 접근하는 방법과 듀얼 홈 게이트웨이에 접근 후 프로그램을 이용해 다시 한번 내부로 접속을 하는 방법이 있다. 스크리닝 라우팅 방식과 다르게 라우팅 기능이 존재하지 않는다. 두번째 방법을 이용시 싱글 홈드 게이트 웨이처럼 강화된 사용자 관리와 모니터링이 필요하며 (로그인 정보 유출 관리) 해당 게이트웨이가 해커에 점령 당하면 내부 네트워크 자원들이 위험에 노출 된다. 

 

-4. 스크린드 호스트 게이트웨이 (Screened Host Gateway)

스크리닝 라우터와 베스천 호스트를 혼합한 형태이다. 외부에서 오는 요청은 1차로 스크리닝 라우터에서 막고 2차로 베스천 호스트를 거치며 인증 및 로그를 남긴다. 나가는 요청은 반대 방향으로 진행되게 된다. 2단계 방어로 더욱 안전하지만 속도 지연이 있을 수 있으며 공격자에 의해 라우팅 테이블이 변경되어 라우터에서 베스천 호스트를 거치지 않고 내부 네트워크로 바로 요청이 가게 되면 안전하지 않다. 가장 많이 쓰이는 방화벽 형태이지만 구축 비용이 많이 든다. 

 

-5.스크린드 서브넷 게이트 웨이(Screened Subnet Gateway)

내부 네트워크와 외부 네트워크를 중간의 스크린드 서브넷으로 분리(AWS로 치면 퍼블릿 서브넷 같은 것 같다.)하여 외부의 스크리닝 라우터가 내부의 네트워크에 접근을 하지 못하도록 한다. 스크린드 서브넷에는 공개 서버와 베스천 호스트(또는 듀얼 홈드 게이트웨이) 를 위치하고 베스천 호스트에서 허용하는 트래픽만이 내부 네트워크를 거쳐서 내부망으로 들어 올수 있다. 다단계 방어로 강력하지만 구축 비용이 많이 들고 서비스 속도가 느려 질 수 있다. 

 

3. 정리

이렇게 보니 AWS에서 Bastion Host 인스턴스를 만들면 스크린드 서브넷 게이트 웨이 방식으로 꽤나 안전하게 인스턴스를 운영할 수 있을 것 같았다. 라우팅은 아니지만 AWS의 NACL과 보안 그룹은 스크리닝 라우터의 ACL처럼 TCP/IP 레벨에서 방어를 해주고 외부와는 IGW를 통해서 내부 서브넷과는 NAT 게이트 웨이를 통해서 통신하여 듀얼 홈드 게이트 웨이를 사용하는 것과 비슷하다. 그렇지만 Bastion Host 인스턴스를 두는 것은 Bastion Host가 공격당하면 보안에 취약하다. 방화벽에 관한 설명들에도 사용자 인증이나 로깅등을 구축해 놓는게 좋다는데 비즈니스 로직의 구현과 기술 습득에 신경을 쓰고 싶은 개인 프로젝트에서 보안에 시간을 많이 들이기는 힘들다고 생각했다. 그러다가 Private Subnet에 SSH 접속을 하는 더 안전한 방법들도 있다는 걸 알게 되었다. 

 

4. 더 안전한 대안

Bastion Host에 관해 조사하던 중 Elastic Scale이라는 사이트에서 대안으로 제시한 방법들(https://elasticscale.com/better-alternatives-than-bastion-host/)이 흥미로워서 보게 되었다. 방화벽의 구조를 공부하고 AWS가 보안에 신경을 많이 쓴다는걸 알았지만 Bastion Host 관리는 조금 부담이였고 새로운 대안들은 Private Subnet에 점프 서버(Bastion Host)없이 접근이 가능 하다고 하였다. 생소한 단어들에 조금 머리가 아팠지만 'AWS강의실'이라는 Youtube 채널을 통하여 다행히 무리없이 연결할 수 있었다. 

 

A. EC2 Instance Connect EndPoint

처음에는 바로 EC2 Instance Connect이 가능한지 알았지만 Public Subnet이 아니면 경고가 뜨고 사용이 불가하다.

private subnet은 연결 할 수 없다.

 

 

알고보니 EC2 Instance Connect Endpoint를 만들어야 private subnet에 접속 가능했다. 

Endpoints는 VPC 탭에서 설정 가능하다.

 

연결 방법은 AWS강의실을 참고하였습니다. (https://www.youtube.com/watch?v=DsrDOcpS5ns)

 

EC2 Instance Connect Endpoint(EIC)보다는 Session Manager가 익숙할수도 있는데 VPC Endpoint를 통해 private subnet에 접속을 시켜주는 건 비슷하지만 둘은 조금 다르다. 일단 EIC는 무료이다. CloudTrail을 이용해 기본적인 로그가 제공되며 IAM과 Security Group을 통해 접근 권한 관리하고 계정 당 최대 5개, VPC 당 1개, 서브넷당 1개 설정을 할 수 있으나 고가용성은 지원되지 않는다.

 

반면에 Session Manager는 유료이다. SSM 세션매니저를 위한 엔드포인트 3개의 비용이 발생하나 CloudTrail외에 Cloud Watch를 통한 상세 로그를 지원하며 고가용성도 보장해준다. 

 

*실습을 하여보니 SSM의 경우 22번 포트를 열지 않아도 접속이 되는데 EIC의 경우 SSH접속을 Security Group에서 열어주어야 접근이 가능하다.

 

 

B. AWS SSM Session Manager (System Manager - Session Manager)

SSM Session Manger를 연결하려면 IAM Role을 설정하여야 한다. SSM Agent가 EC2에 설치 되어 있어야 하나 Amazon Linux 2 부터는 기본 설치가 되어 있어 혹시 다른 AMI를 사용한다면 참고하자. 

연결이 되면 Start Session때 인스턴스가 보인다.

Key Pair도 없고 Bastion Host도 없지만 yum install이 잘 된다.

 

연결방법은 AWS강의실의 영상을 참고 하였습니다. (https://www.youtube.com/watch?v=rewWxRDMgjo&t=161s)

 

IAM Role에서 AmazonEC2RoleforSSM 이라는 Policy를 추가하고 EC2에 붙여주면 된다. (EC2 생성 후 붙이는 경우 재부팅을 하여야 한다.) 

 

**추가: 이후에 요금 이슈로 VPC를 지우면서 Endpoint들도 사라져서  Session Manager에서 접근이 안되었다. 이 경우 SSM 접속용 Endpoint를 다시 만들어 주면 된다. (홍랩님: https://honglab.tistory.com/168)

 

 

4. 결론

Bastion Host 없이 private instance에 접근을 하는 것이 Bastion Host를 관리하지 않아도 되어서 보안에 더 유리하다는 생각이다.  그러나 Session Manager의 비용을 개인 프로젝트에서 감당하기는 어려울 것 같고 누가 접근하고 어떤 명령어를 사용했는지 같은 상세로그는 접근할 사람이 적을것 같아 무료인 EIC를 통해 Private Subnet에 접근하도록 앞으로는 해 보려고 한다. 

 

 

출처: 

Twingate: https://www.twingate.com/blog/bastion-host

Elastic Scale: https://elasticscale.com/better-alternatives-than-bastion-host/

Teleport: https://goteleport.com/blog/do-we-still-need-a-bastion/

별의수다 님: https://m.blog.naver.com/wnrjsxo/221067532371

choco_sister 님: https://velog.io/@choco_sister/방화벽

BeraSix-S 님:  https://berasix.tistory.com/entry/%EC%A0%95%EB%B3%B4%EB%B3%B4%EC%95%88%EA%B8%B0%EC%82%AC-2-%EB%B0%A9%ED%99%94%EB%B2%BD%EC%9D%98-%ED%98%95%ED%83%9C%EA%B5%AC%EC%A1%B0%EB%B3%84-%EC%A0%95%EC%9D%98

홍랩님 : https://honglab.tistory.com/168

AWS 강의실 SSM Manager: https://www.youtube.com/watch?v=rewWxRDMgjo&t=161s 

AWS 강의실 EIC Endpoint: https://www.youtube.com/watch?v=DsrDOcpS5ns&t=310s