[INFRA] 보안을 고려해 서버 아키텍처를 설계해 보자

📝 들어가며

우리는 기존에 dev 서버만 존재했고, prod 서버는 존재하지 않았다.

prod 서버를 구축하는 과정에서 보안을 고려해 설계한다면, 어떤 설계를 할 수 있을지에 대한 고민을 시작했다.

 

그 과정에 대해 기록해보고자 한다.

1️⃣ 인바운드 규칙

우리가 가장 먼저 고려한 것은 인바운드 규칙이었다.

현재 AWS 의 ec2 를 이용해 서버를 구축한 dev 서버에서의 인바운드 규칙은 모두에게 열려 있었다.

 

22번 포트는 우테코 규약에 따라 특정 IP (우테코 캠퍼스 내부) 만 접속할 수 있었으나, 나머지 포트들은 모든 IP 가 접근할 수 있었다.

클라이언트가 직접 사용하는 IP가 결국 dev 서버의 IP 였기 때문에, 악의적인 사용자가 해당 IP로 대량의 요청을 보내면 서비스가 쉽게 다운될 수 있는 구조였다. 이런 상황에서는 서버 IP를 숨기거나 보호하기 어려웠다.

또한 80 포트가 전 세계에 개방되어 있으면 자동화된 스캐닝 봇이나 취약점 공격 시도의 대상이 되기 때문에 무시할 수 없는 위험 요소가 된다. 더 나아가 80 포트로 외부 접근을 허용하면 HTTPS가 아닌 평문 HTTP 요청도 받아들여질 수 있어, 통신 보안 측면에서도 바람직하지 않다.

그래서 우리는 다음과 같이 보안 그룹을 변경해주었다.

 

 

해당 보안 그룹에서는 ssh 통신을 bastion 서버에서만 가능하도록 막아 둔다 (이에 대해서는 추후에 설명한다.)
또한 443 과 80 에 대해서는 기존과 같이 모든 IP 로부터의 접근을 허용하는 것이 아니라 특정 ec2 에 대해서만 접근을 허용했다.

 

 

dev 서버의 80 포트와 443 포트로 접근할 수 있는 ec2 가 바로 LB 역할을 하는 ec2 이다. 이 ec2 의 보안 그룹은 모든 ip 가 80 과 443 으로 접근할 수 있도록 해두었다.

즉, 기존의 서버 구조에서는 dev 서버 딱 하나만 있었다. 443, 80 포트들은 모든 IP 에 대해 열어두었다. 그러나 개선된 서버의 구조에서는 lb 를 앞에 두고, lb 만이 서버 역할을 하는 ec2 로 접속이 가능하다. 심지어 ssh 통신을 하는 22번 포트는 특정 IP 도 아닌 bastion 으로만 열어 두었다.

 

2️⃣ bastion 

앞서 언급한 bastion 이란 무엇일까?
이는 보안을 강화하기 위해 외부 네트워크와 내부 네트워크 사이에 위치하는 특별한 서버다.

사실 이렇게 설명하면 어렵고 복잡해보이지만, 간단히 말하자면 prod 서버가 띄워진 ec2 를 접근하기 위해 개발자가 로컬의 터미널에서 pem 키를 통해 접속하는 것이 아니라 bastion 서버가 접속하도록 하는 것이다. 막말로 ec2 하나 더 띄워서 이 ec2 가 대신 접속하는 것뿐이다..

기존의 방식인 개발자가 로컬의 터미널에서 pem 키를 통해 접속 하는 경우에는, 해당 서버가 public 으로 열려 있거나 특정 ip 에 대해서 오픈되어 있어야 하기 때문에 보안에 취약할 수 있다.

그러나 bastion 서버를 사용하게 되면, 해당 서버의 ssh 접속 자체를 서버를 경유하도록 강제할 수 있다.

 

다시 개선된 prod 서버의 보안 그룹을 확인해보자. 22번 포트는 오직 bastion 서버만 접속이 가능하다.

3️⃣ SSM

그러나 우리는 bastion 서버를 사용하지 않았다!

 

앞서 이야기한 것과 같이 ssh 통신은 bastion 서버로만 가능하다. bastion 을 사용하지 않았다면,  어떻게 ssh 통신을 할 수 있었을까?

 

우리는 SSM 을 사용하기로 했기에 가능했다.

 

SSM 이란 무엇일까?
AWS에서 제공하는 관리 서비스로, EC2·온프레미스 서버·컨테이너 등 인프라를 중앙에서 원격으로 제어·자동화 할 수 있게 해준다.  즉, pem 키 없이 AWS 내부에서 CLI 로 접속할 수 있도록 한다. 쉽게 말하자면, 기존에 pem 키를 통해 로컬 터미널로 접속해야 했던 ssh 터미널을 AWS 의 웹 페이지 내부에서 사용할 수 있게 되는 것이다.

우리가 SSM 을 도입한 이유는 다음과 같다.

✅ 1. 비용 측면

 

현재 EC2 구성

• dev(1) + Nginx(1) + DB(1) + prod(1) = 총 4대 → 약 $24/월(t2.micro 기준)
• Bastion 서버 추가 시 +$6/월 증가 → 불필요한 비용 부담이 증가한다.

반면, SSM 은 고급 파라미터 등 특수한 옵션을 사용하지 않는 한 무료로 사용 가능하다.

✅ 2. 관리 효율성 측면

Bastion 방식

• 관리해야 할 서버가 하나 더 늘어나 운영 포인트 증가
• 보안을 위해 EC2 에 접근하는 사용자들에 대해 직접 모니터링 및 로깅을 통해 추적해야 한다.

SSM 방식

• 별도의 서버가 불필요하며, 각 인스턴스의 에이전트만 관리하면 된다.

 

✅ 3. 보안 강화 측면

Bastion 방식

• .pem 키를 로컬/서버에 보관해야 함 → 키 탈취 시 보안 리스크가 증가한다.
• 22번 포트가 열려 있어야 하기에 위험 요소가 존재한다.

SSM 방식

• pem 키 불필요, IAM Role 기반 인증 → 자격 증명 탈취 위험이 최소화된다.
• 22번 포트 닫을 수 있음 → 외부 공격을 받을 가능성이 감소한다

이러한 비용 / 관리 / 보안 측면에서 우리는 보안을 고려한 서버 아키텍처 설계에서 SSM 이 더 적절한 대안이라고 판단했다.

4️⃣ Private Subnet 과 Public Subnet

기존에는 서버를 public subnet 에 두어 해당 서버의 ip 로 얼마든지 접근할 수 있도록 했다.

그러나 prod 서버를 구축하며 보안을 고려하는 과정에서는 prod 서버를 VPC 내부의 private subnet 으로 옮기기로 결정했다.

 

Private Subnet 과 Public Subnet 에 대해 설명하는 것은 주제에서 어긋나므로 따로 언급하지는 않겠다.

해당 내용이 헷갈리시는 분들은 VPC / Private Subnet / Public Subnet 에 대해 추가적으로 학습하시면 좋을 것 같아요 🤗

🙋 private subnet 으로 두는 것의 효과
Private Subnet에 서버를 두면 퍼블릭 IP가 할당되지 않으며, VPC 라우팅 테이블에 인터넷 게이트웨이가 없으므로 외부에서 직접 접속할 수 없다. 즉, 인바운드 요청은 차단된다.

🙋 왜 인바운드 규칙으로 이미 prod 서버로의 접근을 차단했음에도 왜 private subnet 을 고려해야 할까?
이는 내가 Private subnet / public subnet 에 대해 고려하면서 들었던 의문이다.

보안 그룹은 일종의 논리적 방화벽에 가깝다. 서버에 퍼블릭 IP가 있으면 외부에서 '집 위치(IP)' 자체는 알 수 있고, 나는 SG라는 규칙(‘가족만 들어와’)으로 문을 닫아둔다. 하지만 만약 규칙을 잘못 적용하면 그 틈을 타 도둑은 바로 들어올 수 있다.

반대로 서버를 Private Subnet에 두면 아예 외부와 연결된 길(인터넷 게이트웨이)이 없기 때문에, 도둑은 집에 오는 길 자체를 찾을 수 없다. 즉, 단순히 문을 잠그는 것(SG)보다, 집 입구를 외부 도로와 단절 시켜 네트워크 경계 차원에서 막는 셈이다.

따라서 Private Subnet은 SG만으로는 막을 수 없는 실수나 설정 오류까지 대비한 이중 방어로 이해할 수 있다.

🙋 서버를 private subnet 에 둔다면 서버 API 로의 접근은 어떻게 하는거지?
이를 위해 우리는 로드 밸런서 역할을 하는 Nginx 를 public subnet 에 두었다.

즉, Public Subnet 에 해당하며 LB 역할을 하는 Nginx 서버가 요청을 받아 VPC 내부의 Private Subnet 인 dev 서버에게 요청을 전달하는 것이다.

5️⃣ Nginx

1. proxy pass

 

위와 같이 nginx 의 proxy_pass 관련 설정을 해주었다.
이렇게 되면, Nginx 는 내가 전달을 원하는 VPC 내부에 있는 prod 서버에게로 요청을 넘겨준다.

• proxy_set_header Host $host; → 클라이언트가 보낸 Host 헤더 유지.
• proxy_set_header X-Real-IP $remote_addr; → 클라이언트의 실제 IP 전달.
• proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; → 프록시 체인을 따라 클라이언트 IP 리스트 전달.
• proxy_set_header X-Forwarded-Proto $scheme; → 원래 요청 프로토콜(HTTP/HTTPS) 전달.
• proxy_set_header X-Forwarded-Host $server_name; → 요청이 들어온 Host 정보 전달.

기존의 요청을 최대한 유지하며 proxy pass 가 이뤄지도록 했다.

 

2. 과도한 요청 시 특정 IP 차단

 

limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=20r/s;

 

이는 1초당 20번의 요청까지는 허용하는 설정이다. $binary_remote_addr 는 요청을 보내는 클라이언트의 ip 에 해당한다.

 

limit_req zone=req_limit_per_ip burst=10 nodelay;

 

순간적으로 요청이 더 몰릴 수가 있기 때문에, 몰리는 경우를 대비하여 10번까지 추가적으로 요청을 허용한다. 즉, 1초에 대하여  최대 30번까지 요청을 허용하는 것이다.

 

 

위 설정이 잘 적용됐는지 확인하기 위해서 위와 같이 실제로 요청을 쏴보았다. 이는 31개의 요청을 초마다 쏘는 것이다. 간간히 503 이 상태 코드로 반환되는 것을 확인할 수 있다.

---

이제 우리 서버는 

 

1. 외부에서 함부로 접근할 수 없고

2. 외부에서는 퍼블릭 IP 가 없으니 인터넷으로 접속을 할 수가 없으며

3. 일정 개수 이상 요청을 보내면 503 이 해당 IP 에 대해 뜨게 되고 

4. 연결 시에 pem 키까지 필요로 하지 않는 안전한 서버가 되었다!

 

이번 과정에서 보안과 함께 서버를 고려해보며 처음으로 개발자란 이런 것들을 고려하고 다뤄야 하는 직업이구나, 혹시 모를 상황을 대비한다는 건 이런 거구나 하는 깨달음을 얻을 수 있었다.