HTTP 게시를 애플리케이션 실행 및 영구 데이터와 분리하십시오. 리버스 프록시는 라우팅과 제한을 구성할 수 있지만, 오리진 액세스, 애플리케이션 권한 부여, 업스트림 용량 및 복구에는 각각 자체 제어가 필요합니다.
웹 요청은 여러 책임을 넘나듭니다.
웹 서버는 HTTP 요청을 수신하고 정적 파일을 제공할 수 있습니다. 애플리케이션 프로세스는 계정 확인이나 데이터베이스 쿼리와 같은 프로젝트의 동적 동작을 실행합니다. 리버스 프록시는 해당 프로세스를 대신하여 요청을 수신하고 업스트림으로 전달합니다. 하나의 프로그램이 여러 역할을 수행할 수 있지만, 책임을 분리하면 구성과 복구를 더 쉽게 이해할 수 있습니다.
호스트 이름 확인부터 응답까지 하나의 요청을 추적하십시오. TLS가 어디서 끝나는지, 어떤 프로세스가 경로를 선택하는지, 어떤 구성 요소가 애플리케이션 데이터를 읽을 수 있는지 기록하십시오. 관리 요청에 대해서도 동일하게 수행하십시오. 이 연습은 종종 테스트용으로 생성되었다가 실수로 도달 가능한 상태로 남은 리스너나 호스트 이름을 드러냅니다. 다이어그램은 구축하려던 아키텍처가 아니라 배포된 경로를 설명해야 합니다.
엣지를 사용하여 HTTP 동작을 구성합니다.
NGINX는 정적 콘텐츠 제공과 업스트림으로의 요청 전달을 모두 문서화합니다. 워커 아키텍처와 HTTP 모듈은 구성 메커니즘을 제공하지만, 특정 구성이 여전히 동작을 결정합니다. 호스트 이름, 업스트림 및 파일 시스템 루트를 의도적으로 정의하십시오. 애플리케이션 근처에 있다는 이유만으로 구성, 자격 증명 및 저장소 메타데이터가 다운로드 가능해지지 않도록 제공할 수 있는 파일을 제한하십시오.
애플리케이션에 따라 요청 본문, 시간 초과 및 연결에 적절한 제한을 설정하십시오. 캐시를 데이터 결정으로 취급하십시오. 사용자나 권한에 연결된 콘텐츠는 검토 없이 공유 캐싱 규칙을 안전하게 상속할 수 없습니다. 인증과 캐시 동작을 함께 테스트하십시오. 재현 가능한 구성을 유지하고, 이전 작동 버전으로 돌아갈 수 있는 알려진 경로와 함께 서비스를 다시 로드하기 전에 변경 사항을 검증하십시오.
| 계층 | 유용한 책임 | 출시 전 확인 |
|---|---|---|
| 퍼블릭 웹 엣지 | TLS, 호스트 이름 라우팅 및 HTTP 제한 | 인증서, 루트 및 의도한 호스트 이름 |
| 애플리케이션 프로세스 | 비즈니스 로직 및 권한 부여 | 인증, 입력 검사 및 종속성 실패 |
| 내부 데이터 서비스 | 영구 애플리케이션 상태 | 제한된 액세스 및 테스트된 복원 |
| 업스트림 제공자 네트워크 | 계약된 네트워크 서비스 | 보호 범위 및 에스컬레이션 경로 |
리버스 프록시는 오리진의 노출을 제거하지 않습니다.
오리진이 공개적으로 액세스 가능한 상태로 남아 있으면 클라이언트가 의도한 프록시 경로를 사용하지 않고 오리진에 도달할 수 있습니다. 배포에 해당 경계가 필요한 경우 네트워크 설계와 애플리케이션 구성을 통해 오리진 액세스를 제한하십시오. 한 머신에서는 백엔드가 종종 루프백이나 로컬 소켓에서 수신 대기할 수 있습니다. 여러 머신에 걸쳐서는 명시적인 제한 경로와 업스트림 연결에 적합한 보호를 사용하십시오.
전달된 헤더에도 신뢰 규칙이 필요합니다. 신뢰할 수 있는 중개자로부터만 원래 클라이언트에 대한 정보를 수락하고, 임의의 호출자가 애플리케이션이 권위 있는 것으로 취급하는 값을 제공하지 못하게 하십시오. 액세스 로그와 오류 보고서에 무엇이 나타나는지 결정하십시오. 프록시는 각 계층에서 사용 가능한 정보를 변경할 수 있지만, 계정 식별자를 지우거나 애플리케이션을 자체 운영자에게 익명으로 만들지는 않습니다.
애플리케이션 내부에서 액세스 결정을 적용합니다.
NIST의 제로 트러스트 아키텍처는 네트워크 위치만을 기반으로 한 암묵적 신뢰보다 리소스에 대한 액세스 결정에 중점을 둡니다. 이 원칙을 구체적으로 적용하십시오. 호출자를 인증하고, 요청된 작업을 승인하며, 서비스 계정에 필요한 범위만 부여하십시오. 내부 서브넷에서 도착한 요청이 자동으로 관리자 요청이 되어서는 안 됩니다.
가능한 경우 퍼블릭 기능과 관리 기능을 분리하십시오. 초기 로그인에만 의존하지 말고 사용자가 레코드에 액세스할 때 권한을 다시 확인하십시오. 프록시, 애플리케이션 및 데이터베이스의 자격 증명을 서로 다르게 유지하십시오. 좁은 민감 경로부터 시작하여 테스트할 수 있는 단계로 변경 사항을 도입하십시오. 배포를 제로 트러스트라고 부르는 것은 금지된 작업이 실제로 이를 담당하는 구성 요소에서 거부됨을 입증하는 것보다 유용하지 않습니다.
둘 이상의 계층에서 서비스 거부를 계획합니다.
포화된 네트워크 링크와 비용이 많이 드는 애플리케이션 요청은 서로 다른 지점에서 실패합니다. 웹 엣지에서의 속도 제한은 요청 패턴을 제한하는 데 도움이 될 수 있으며, 애플리케이션 제한은 검색, 업로드 또는 내보내기와 같은 작업을 제한할 수 있습니다. NGINX의 요청 제한 모듈은 하나의 메커니즘을 제공합니다. 키와 임계값은 실제 사용자에게 맞아야 하며 정당한 트래픽을 거부하지 않도록 테스트해야 합니다.
OWASP의 서비스 거부 지침은 애플리케이션 동작의 리소스 고갈도 다룹니다. 비용이 많이 드는 작업에 시간 및 크기 제한을 두고, 제한된 큐를 사용하며, 실패 신호를 모니터링하십시오. 로컬 제어는 이미 포화된 업스트림 링크에서 용량을 만들 수 없습니다. 선택한 요금제에 포함된 특정 네트워크 보호를 확인하고 에스컬레이션 경로를 준비하십시오. 카탈로그의 Layer 3–4 보호가 모든 HTTP 워크로드에 대한 보호도 입증한다고 가정하지 마십시오.
복구를 게시의 일부로 만듭니다.
의도한 호스트 이름을 사용하여 외부 클라이언트에서 사이트를 확인하십시오. HTTPS, 리디렉션, 정적 리소스, 로그인 및 대표적인 애플리케이션 트랜잭션을 검증하십시오. 관리 리스너와 개인 파일이 액세스 불가능한 상태로 유지되는지 확인하십시오. 중지된 업스트림을 시뮬레이션하고 엣지가 내부 세부 정보를 노출하거나 제한 없이 대기하는 대신 통제된 실패를 반환하는지 확인하십시오.
Canvas의 경우 호스팅 계정 내에서 사용 가능한 제어를 확인하십시오. VPS의 경우 웹 엣지와 애플리케이션을 자체 운영 계획의 일부로 유지하십시오. 큰 네트워크 포트는 용량 사양이며 애플리케이션이 해당 처리량을 유지할 수 있다는 증거가 아닙니다. 모니터링, 복원 및 제공자 연락처를 런북에 유지하십시오. 실제 요청 경로와 실용적인 복구 경로가 검증된 후에만 게시하십시오.
실용 체크리스트.
- 퍼블릭 및 관리 요청을 추적합니다.
- 제공되는 루트와 업스트림 리스너를 정의합니다.
- 승인된 중개자로부터만 전달된 헤더를 신뢰합니다.
- 권한 부여 및 캐시 경계를 테스트합니다.
- 네트워크 및 애플리케이션 실패에 대한 제한과 에스컬레이션을 준비합니다.
중요한 세부 사항.
웹 서버가 리버스 프록시 역할도 할 수 있나요?+
예. NGINX가 문서화된 한 가지 예입니다. 역할은 구성에 따라 다르며, 애플리케이션에는 여전히 자체 권한 부여와 유지 관리가 필요합니다.
리버스 프록시가 오리진을 자동으로 숨기나요?+
아니요. 라우팅, 방화벽 및 리스너 설정이 의도한 경계를 강제하지 않으면 오리진은 도달 가능한 상태로 남을 수 있습니다.
요청 제한이 모든 DDoS 공격을 막나요?+
아니요. 선택된 HTTP 요청 패턴을 다룹니다. 네트워크 포화 및 기타 리소스 실패에는 적절한 업스트림 및 애플리케이션 제어가 필요합니다.
출처로 이동하세요.
이 참고 자료는 이 가이드의 기술 개념을 뒷받침합니다. 프로덕션 시스템을 변경하기 전에 최신 문서를 확인하세요.
- NGINX: 초보자 가이드 nginx.org
- NGINX: HTTP 요청 제한 nginx.org
- NIST SP 800-207: 제로 트러스트 아키텍처 nvlpubs.nist.gov
- OWASP: 서비스 거부 방지 cheatsheetseries.owasp.org
SwissOctet의 편집 지침. 예시는 설명용입니다. 서비스 사양, 사용 가능한 옵션 및 계약 조건은 별도로 확인해야 합니다.