구체적으로 전용 웹 서버(예: lighttpd 또는 nginx)를 사용하고 웹 서버(예: Swift/Python)의 지시에 따라 프로그램을 실행하면 어떤 이점이 있나요?
구체적으로 이는 단순히 웹 프레임워크(예: Perfect/Flask)를 실행하고 내장 라우팅을 사용하는 것과 어떻게 비교됩니까?
답변1
이것은 표준 "웹 보안 아키텍처" 질문입니다.
일반적인 3계층 애플리케이션에는
- 웹 레이어
- 애플리케이션 레이어
- 데이터베이스(또는 기타 백엔드) 계층.
별도의 업무를 돕는다는 아이디어입니다.
따라서 "웹 계층"은 모든 수신 트래픽의 초기 종료 지점입니다. 여기에서 SSL 작업을 이미 완료했을 수도 있습니다. 이 시점에서 SQL 주입 공격이나 경로 통과 공격과 같은 수신 트래픽을 검사할 수 있는 웹 애플리케이션 방화벽과 같은 것을 주입할 수 있습니다.
여기에서 종료하면 apache, nginx 또는 lighttpd와 같은 프런트 엔드 서비스가 악성 트래픽 처리, 잘못된 요청 기록에만 전념하고 더 "안전"하다는 이점이 있습니다. 누군가 웹 서버를 공격하는 새로운 방법(잘못된 TCP 비트 세트로 데이터 조각화?)을 고안해 내면 상위 웹 서버가 패치될 것이라고 확신할 수 있습니다. 네트워크 프레임워크는 그다지 중요하지 않을 것입니다.
"클린" 트래픽만 애플리케이션 계층으로 전달됩니다(이 통신은 HTTP일 수도 있지만 보다 신뢰할 수 있는 소스에서 전송됨). 귀하의 애플리케이션은 백엔드와 통신할 수 있습니다.
이제 이상적으로 이러한 레이어는 네트워크 라우팅 규칙을 사용하여 다른 서버에 있어야 외부 요청 서비스가 "애플리케이션 서버"에 전혀 도달할 수 없습니다. 트래픽이 응용 프로그램 서버에 도달하는 유일한 방법은 하위 TCP 계층에서도 프런트 엔드 웹 서버를 통하는 것입니다. 그러나 이것이 없어도 몇 가지 보안상의 이점을 얻을 수 있습니다.
두 번째 이점은 프런트 엔드 서비스가 HA 프록시가 되어 여러 백엔드 애플리케이션 서버에 로드를 분산할 수 있다는 것입니다.
세 번째 장점은 프런트 엔드 웹 서버에서 정적 파일(예: 이미지, CSS, 자바스크립트)을 제공할 수 있고 대량의 애플리케이션별 콘텐츠만 애플리케이션에 전달된다는 것입니다. 캐싱 레이어 등을 추가할 수 있습니다. 여기에는 성능상의 이점이 있습니다.
따라서 비즈니스 관점에서 볼 때 이들을 별도로 유지해야 할 많은 이유가 있습니다. 그러나 더 많은 구성 및 설정 작업이 필요합니다.
어디까지 가고 싶은지는 개인 취향입니다.