Introduction
본 실습 과정은 AWS Training and Certification을 바탕으로 작성되었습니다.
사례 연구
애플리케이션의 실제 서버 역할을 하는 AppServer라는 인스턴스가 있고, 이는 private 서브넷에 위치하여 인터넷에서 직접적으로 접근할 수 없다.
🧐 그렇다면 어떻게 접근 할 수 있을까?
그림에 답이 나와있다.
접근 방법
ProxyServer와PublicServer라는 중간 인스턴스를 연결해서 사용한다.
ProxyServer 와 PublicServer는 동일한 가상 사설 클라우드(VPC)의 public 서브넷에 위치하도록 하여 인터넷(외부)와의 연결이 가능하도록 한다.
이후 들어오는 요청에 대해서 이러한 프록시 서버는 들어오는 웹 요청을 AppServer 인스턴스로 전달한다.
결론
이처럼 프록시 서버 모델을 구현하는 것은 프라이빗 서브넷 리소스에 원격으로 액세스하기 위한 일반적인 네트워크 보안 구성이다.
사례 기반 실습
0. 사례 분석
- 1개의 리전
- 1개의 VPC + 인터넷 게이트웨이
- 3개의 가용영역
- 각 가용영역 별 서브넷 배치 (총 3개)
- 인터넷과 연결되는 퍼블릭 2, 내부 서버인 프라이빗 1
- 각 서브넷 별 EC2 인스턴스 배치 (총 3개)
- 3개의 보안그룹
1. 보안 그룹 검사
보안 그룹은 기본적으로 stateful 즉, 상태를 저장한다. AWS 공식 문서
즉, 요청이 허용된 경우, 해당 요청에 대한 응답 트래픽도 허용된다.
자세한 내용은 [AWS] 보안그룹과 ACL을 참고하라.
각 인스턴스마다 고유의 보안그룹이 현재 존재하며, 세 보안그룹 모두 모든 IP와 포트에 대해서 전부(Anywhere) 트래픽이 허용되어 있는 것을 확인할 수 있다.
따라서 ProxyServerUrl과 PublicServerUrl 어디를 통하든 AppServer로 접속할 수 있었다.
AppServer 보안 그룹 수정
이제, AppServer쪽의 보안 인바운드 트래픽을 전체 허용에서 ProxyServer의 트래픽만 받도록 변경해보자.
전체 허용을 뜻하는 0.0.0.0에서 ProxyServer의 내부 IP 주소(10.0.1.131)로 변경해 주었다.
이제 AppServer는 10.0.1.131에서 오는 트래픽만을 허용하게 된다.
따라서, PublicServerUrl로 접근해보면, 접근이 되지 않는 것을 확인할 수 있다.
다시 사용 가능하도록 설정
이제 이 사용이 불가능해진 PublicServer를 다시 사용 가능하도록 해보자.
어떻게 해야할까?
AppServer의 보안 그룹에 PublicServer의 내부IP 주소 또한 추가하면 될까?
물론, 그것도 하나의 방법이 될 수 있지만 일반적으로 보안 그룹 규칙에 고정 IP 주소를 설정하는 것은 그닥 효율적인 방법이 아니다.
인스턴스가 계속 생긴다면, 계속해서 인바운드에 추가해 주어야 할테니 말이다.
또한, 직접적으로 IP주소를 쓰는 것이므로 보안적인 측면에서도 문제가 생길 수 있다.
여러 호스트에 대해 동일한 액세스 권한을 배포하는 가장 간단하고 안전한 방법은 개별 IP 주소가 아닌 보안 그룹 이름을 인바운드 소스로 사용하는 것이다.
PublicServer의 보안 그룹 수정
정답(최선의 방법)은 다음과 같다.
PublicServer의 기존PublicServer보안 그룹을 사용하지 않고,ProxyServer보안 그룹을 사용한다.
PublicServer의 Security Groups에 들어간 다음
이처럼 PublicServer의 기존 PublicServer보안 그룹을 사용하지 않고, ProxyServer 보안 그룹을 사용하도록 한다.
AppServer 보안 그룹 수정(2)
이제 마지막 과정만 남았다.
ProxyServer 보안 그룹을 사용하도록 하였으므로, 이 보안 그룹을 AppServer의 보안 그룹의 인바운드 소스로 사용하도록 지정만 해주면 끝난다.
접속해 보기
잘 접속되는 것을 확인할 수 있다.
