베스쳔, 바스티온 .. 이름은 하나인데 별명은 서 너 개
네트워크에서 다른 컴퓨터에 접근할 때 보안을 의식한 접근 방법 중 하나 입니다.
개요
AWS 를 사용하며 VPC 내에서 DB 전용 EC2 인스턴스를 두려합니다. (RDS 는 가격이 부담되어 EC2 를 사용합니다.)
공격 표면을 최소화하기위해 DB 는 private subnet 에 둘 계획입니다.
문제는 이렇게 될 시 VPC 외부에선 이 DB 인스턴스에 접근할 방법이 없습니다.
본문
이러한 문제를 해결하기 위한 방법은 최소한의 접근 표면을 가진 경유지를 둬서 가능한 조심히 DB 인스턴스에 접근하는 것입니다.
이때 경유지가 Bastion Server, Bastion Host 입니다.
얼핏보기엔 이럴꺼면 DB 인스턴스를 퍼블릭에 두고 보안그룹 설정을 통해 접근 표면을 최소화하면 되는 것 아닌가 생각할 수 있습니다.
Bastion Host 에 적용할 보안 규칙을 public subnet 의 DB 인스턴스에 그대로 적용시키는 것입니다.
결과적으로보면 둘은 동일하게 동작할 것 입니다. 하지만 유지, 관리 관점에서 차이가 발생합니다.
Bastion 도입 여부에 따른 차이
DB 인스턴스를 public 에 두고 보안그룹으로 관리할 경우- DB 인스턴스에서 로깅 등 부수 작업 전부 담당 (인스턴스가 제 역할에 집중 힘듦)
- 보안그룹 실수 시 인스턴스가 public 하게 바로 들어남 (휴먼 에러에 취약)
DB 를 담당하는 인스턴스에서 보안적인 부분을 다 담당해야합니다.
접근자 로그를 남길 때도 DB 인스턴스에서 전부 담당해야합니다.
그리고 실제 인스턴스를 public 하게 노출하게 될 경우 만에 하나 보안그룹을 잘못 건드릴 경우 그대로 위험한 상황에 처합니다.
-
Bastion Host 를 경유할 경우- Bastion Host 에서 접근자 로그를 남길 수 있다.
- 실수로 Bastion Host 의 보안규칙을 누락한다해도 DB 인스턴스가 그대로 드러나진 않는다.
단점
- 추가적인 인스턴스 비용 및 Public IP 비용
- DB 툴 지원 제한
하나의 인스턴스가 더 사용되니 비용이 듭니다.
외부에서 DB 접근 시 한 번 Bastion Host 를 거쳐야해 DB 관련 툴 지원에 제한이 있을 수 있습니다.
다른 대안은 없을까나
Private Subnet 에 접근할 수 있는 다른 방법은 아래와 같습니다.
SSM (AWS System Manager): SSM Agent 를 활용해 SSH 없이 private Subnet 리소스에 접근 가능합니다.VPN: AWS 의 서비스인데 설정이 까다롭고 비용이 듭니다.Direct Connect: AWS 의 서비스이며 온프레미스에서 직접 접근 가능하지만 비용이 많이 듭니다.
실습
이후에 추가
결론
Private 으로 완전 꽁꽁 싸매면 좋겠지만 그렇긴 쉽지 않네요.
아무리 보안적으로 중요한 요소라도 백도어를 둘 수 밖에 없는 것 같습니다.
더 보안적으로 좋은 방법이 있으면 하는데..
이번 Bastion 실습을 한 이후엔 SSM 으로 이전해보고 싶네요.
