인프런 커뮤니티 질문&답변
작성한 질문수
alb에 있는 도메인을 프라이빗 서브넷에 있는 백엔드 서버에 연결하는 것이 맞는지 고민 중입니다.
작성
·
81
·
수정됨
0
위 그림은 제가 구현한 아키텍처입니다.
제 프론트 서버에서 도메인/api 경로로 백엔드로 요청을 보내기 때문에 ALB에 기본 도메인은 프론트서버로 라우팅, 도메인/api 주소는 백엔드 서버로 라우팅되게 하였습니다.
그런데 프라이빗 서브넷은 외부로부터 접근을 못하는 것에 의미가 있는데 도메인이 연결된 로드밸런서에 프라이빗 서브넷을 연결하면 route53에서 로드밸런서 ip주소에 요청을 보내고 로드밸런서는 /api가 붙어 있는 것을 확인하고 백엔드 서버 대상 그룹으로 요청을 보냅니다.
즉 백엔드 서버 자체의 공인ip가 없어도 사용자가 웹 브라우저에 https://grow-farm.com/api/auth/health 라고 적으면 백엔드 서버에 직접 요청을 할 수 있고 응답도 그대로 돌아옵니다
물론 이것은 헬스체크라서 열어둔거고 다른 API는 앱 내부 차원에서 프론트를 통한 요청으로만 접근 할 수 있게 조치는 취해놨지만 인프라 차원에서 서버가 개방되어있으니 이 설계가 베스트 프랙티스가 아닌 것 같다는 생각이 들었습니다.
제가 기존에 했던 방법으로 도메인을 가지고 있는 로드밸런서에서 프라이빗서브넷에 있는 ec2에 /api를 붙여서 경로를 붙이는 것이 자주 쓰이는 방법이고 제가 잘못 생각한 것이라 큰 문제가 없는지 궁금합니다!
만약 1번이 문제가 있는 방법이라면 대안으로 프론트 서버는 10.0.2.2 같은 백엔드 내부 ip주소로 요청을 보내게 코드를 바꾸고 로드밸런서에서 백엔드 서버를 해제하면 사용자들은 브라우저창에 10.0.2.2/api/auth/health 를 검색하더라도 백엔드 서버에 접근할 수 없는 숨겨진 공간이 될 수 있을 것 같은데 혹시 괜찮은 방법인지 궁금합니다.
감사합니다!
답변 3
0
안녕하세요 재익님! 질문 잘 해주셨습니다:)
(자세히 질문해주셔서 답변 드리기가 편하네요ㅎㅎ)
제가 기존에 했던 방법으로 도메인을 가지고 있는 로드밸런서에서 프라이빗서브넷에 있는 ec2에 /api를 붙여서 경로를 붙이는 것이 자주 쓰이는 방법이고 제가 잘못 생각한 것이라 큰 문제가 없는지 궁금합니다!
-> 이 방식도 많이 쓰이는 방법입니다! 잘못된 부분은 없어보입니다~!!만약 1번이 문제가 있는 방법이라면 대안으로 프론트 서버는 10.0.2.2 같은 백엔드 내부 ip주소로 요청을 보내게 코드를 바꾸고 로드밸런서에서 백엔드 서버를 해제하면 사용자들은 브라우저창에 10.0.2.2/api/auth/health 를 검색하더라도 백엔드 서버에 접근할 수 없는 숨겨진 공간이 될 수 있을 것 같은데 혹시 괜찮은 방법인지 궁금합니다.
-> 기존 방법을 사용하시는 걸 추천드립니다! 그 이유를 아래에서 설명드릴게요~!!물론 이것은 헬스체크라서 열어둔거고 다른 API는 앱 내부 차원에서 프론트를 통한 요청으로만 접근 할 수 있게 조치는 취해놨지만 인프라 차원에서 서버가 개방되어있으니 이 설계가 베스트 프랙티스가 아닌 것 같다는 생각이 들었습니다.
-> 클라이언트/서버 구조의 역할로 나눠서 서버를 구성하는 방식의 어쩔 수 없는 한계이긴 합니다! 외부에서 임의로 API 요청을 보낼 수 있게끔 구성을 할 수 밖에 없습니다. 실제 쿠팡(coupang) 서비스도 보면 검색할 때 사용하는 API를 Postman으로 보낼 수 있는 걸 확인할 수 있습니다.
따라서 백엔드 서버로 악의적으로 요청을 보내는 걸 막기 위해 아래와 같은 방법을 활용해서 치명적인 요청의 형태에 대해서 막으려고 합니다!
[인증 기반 접근 제어 (Access Token, 세션 등)]
JWT, 세션 쿠키, OAuth2 등을 사용해서 사용자가 인증된 상태에서만 API 요청을 처리.
인증되지 않은 사용자의 요청은 차단.[Rate Limiting, Bot Detection]
Cloudflare, Nginx, API Gateway, WAF 등을 이용해서 비정상적인 요청 빈도, User-Agent, IP, UA fingerprint 등을 기반으로 탐지 및 차단. 봇 접근 시도, 자동화된 공격을 제한.
[CAPTCHA]
인증 요청(로그인/회원가입 등)에는 reCAPTCHA를 붙여서 사람만 요청 가능하도록.
위 방법을 참고하셔서 추가적인 보안을 고민해보시면 좋을 것 같네요 !
0
도메인을 통해 백엔드 서버에 요청을 보낼 수 있다보니 취약점을 찾으려는 이런 사람들이 검출됩니다.
-> 해당 요청은 Bot(봇)이 여기저기 IP에 요청을 보내는 걸로 알고 있습니다! 사람이 직접 취약점을 찾는 요청은 아닐거예요ㅎㅎ Nginx를 사용해서 로그를 셋팅해놓다보면 저런 로그가 많이 쌓입니다! 위에서 답변 드린 방식으로 차단 방식을 고민해보셔도 좋고, 아님 취약점만 없다면 봇이 요청하는 정도는 그대로 놔둬도 크게 상관없습니다!(과도한 트래픽을 요청하는 형식이 아니기 때문이기도 하고, 서버에 부담이 가는 정도도 아니기 때문)
0
안녕하세요, 인프런 AI 인턴입니다. 정재익님.
AWS 아키텍처 설계와 관련된 고민을 공유해주셨네요. 현재 설계하신 방법과 대안에 대해 설명드리겠습니다.
1. 현재 설계 검토
- 기존 방법: ALB를 사용하여 도메인 기반으로 경로를 백엔드 서버로 라우팅하는 방법은 일반적으로 많이 사용되는 방법입니다. 이 방식은 로드 밸런서가 모든 외부 트래픽을 처리하여, 백엔드 서버가 인터넷에 직접 노출되지 않도록 하는데 기여합니다. 이는 보안성 측면에서 유리하며, 벤더와 사용자 간의 트래픽을 관리하기에 유리합니다. 프라이빗 서브넷에 배치된 백엔드 서버가 ALB를 통해만 접근 가능하게 하는 구성은 오히려 외부의 직접적인 접근을 차단하여 보안성을 높이는 방법입니다.
2. 대안으로 고려하는 방법
- 내부 IP 사용: 프론트 서버가 프라이빗 서브넷 내의 백엔드 서버 IP를 직접 사용하여 통신을 수행하도록 하는 방법입니다. 이 방법도 가능합니다. 다만, 백엔드 서버가 완전히 프라이빗 서브넷에 종속되어 외부의 직접적인 접근을 차단하게 되며, 내부 네트워크에서만 접근이 가능해집니다. 그러나, 이를 통해 보안성은 증가하지만 운영 및 유지 관리 측면에서 복잡성이 증가할 수 있습니다.
관련 내용을 다룬 답변 링크를 함께 공유 드립니다:
- AWS의 안전한 아키텍처 구성 방법
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
자세한 답변 감사합니당!!