역방향 프록싱 작동 방식

역방향 프록싱은 다음과 같은 두 가지 방법으로 사용할 수 있습니다. 한 가지 방법은 Proxy Server의 보안 기능을 사용하여 트랜잭션을 처리하는 것입니다. 다른 방법은 캐시를 사용하여 사용량이 많은 서버에 로드 균형 조정을 제공하는 것입니다. 두 가지 방법 모두 방화벽에서 엄격하게 작동하지 않기 때문에 일반 프록시 사용과는 다릅니다.

서버의 대역 역할을 하는 프록시

신용 카드 번호 데이터베이스와 같이 보안을 유지해야 하는 중요한 정보가 포함된 컨텐트 서버가 있는 경우 컨텐트 서버의 대역 역할을 할 프록시를 방화벽 외부에 설정할 수 있습니다. 컨텐트 서버에 액세스를 시도하는 외부 클라이언트는 프록시 서버로 보내집니다. 컨텐트 서버에 있는 실제 컨텐트는 안전하게 방화벽 내부에 존재합니다. 프록시 서버는 방화벽 외부에 있으며 클라이언트에게는 컨텐트 서버로 보입니다.

클라이언트가 사이트에 요청을 하면 요청은 프록시 서버로 보내집니다. 그러면 프록시 서버는 클라이언트의 요청을 방화벽의 특정한 경로를 통해 컨텐트 서버로 전송합니다. 컨텐트 서버는 방화벽의 특정 경로를 통해 결과를 다시 프록시로 전달합니다. 프록시는 그림 14–1에 나와 있는 대로 프록시가 실제 컨텐트 서버인 것처럼 검색된 정보를 클라이언트에 보냅니다. 컨텐트 서버가 오류 메시지를 반환하면 프록시 서버는 메시지를 가로채고 헤더에 나열된 모든 URL을 변경한 다음 메시지를 클라이언트에 전송할 수 있습니다. 이 작동 방식은 외부 클라이언트가 내부 컨텐트 서버에 대한 리디렉션 URL을 얻지 못하게 합니다.

이런 방법으로 프록시는 보안 데이터베이스와 악의적 공격의 가능성 사이에 추가적인 보호벽을 제공합니다. 가능성은 별로 없지만 공격에 성공하더라도 공격자는 전체 데이터베이스에 대한 액세스 권한을 얻는 것이 아니라 단일 트랜잭션에 관련된 정보로만 제한될 가능성이 많습니다. 방화벽 통로는 프록시 서버에만 액세스를 허용하기 때문에 인증되지 않은 사용자는 실제 컨텐트 서버에 액세스할 수 없습니다.

그림 14–1 역방향 프록시 프로세스

다른 시스템의 액세스는 허용하지 않고 특정 포트의 특정 서버(이 경우 할당된 포트의 프록시)만 방화벽을 통해 액세스할 수 있도록 방화벽 라우터를 구성할 수 있습니다.

보안 역방향 프록싱

보안 역방향 프록싱은 프록시 서버와 다른 시스템 간의 하나 이상의 연결이 SSL(Secure Sockets Layer) 프로토콜을 사용하여 데이터를 암호화할 때 수행됩니다.

보안 역방향 프록싱은 다음과 같은 여러 가지 용도로 사용됩니다.

• 방화벽 외부의 프록시 서버에서 방화벽 내부의 보안 컨텐트 서버로 암호화된 연결을 제공

• 클라이언트가 프록시 서버에 안전하게 연결할 수 있도록 하여 신용 카드 번호와 같은 정보의 안전한 전송을 보장

보안 역방향 프록싱이 수행되면 데이터 암호화에 따르는 오버헤드 때문에 각 보안 연결의 속도가 느려집니다. 하지만 SSL은 캐시 메커니즘을 제공하기 때문에 연결의 양측 모두 이전에 협상된 보안 매개 변수를 다시 사용할 수 있어 이후 연결에서는 오버헤드게 크게 줄어듭니다.

다음과 같은 세 가지 방법으로 보안 역방향 프록시를 구성할 수 있습니다.

• 클라이언트와 프록시 간 보안. 이 시나리오는 다음 그림에서처럼 프록시와 컨텐트 서버 사이에 교환되는 정보가 인증되지 않은 사용자에 의해 액세스될 위험이 없거나 거의 없는 경우에 효과적입니다.

그림 14–2 프록시에 대한 클라이언트 연결 보안

• 프록시와 컨텐트 서버 간 보안. 이 시나리오는 클라이언트가 방화벽 내부에 있고 컨텐트 서버가 방화벽 외부에 있는 경우에 효과적입니다. 이 시나리오에서는 다음 그림에서처럼 프록시 서버가 사이트 간의 보안 채널 역할을 수행할 수 있습니다.

그림 14–3 컨텐트 서버에 대한 프록시 연결 보안

• 클라이언트와 프록시 간 및 프록시와 컨텐트 서버 간 보안. 이 시나리오는 서버, 프록시 및 클라이언트 간에 교환되는 정보가 보안되어야 하는 경우에 효과적입니다. 이 시나리오에서는 다음 그림에서처럼 프록시 서버가 추가 보안 방법인 클라이언트 인증을 사용하여 사이트 간의 보안 채널 역할을 수행할 수 있습니다.

그림 14–4 프록시에 대한 클라이언트 연결 보안 및 컨텐트 서버에 대한 프록시 연결 보안

각 구성을 설정하는 방법에 대해서는 역방향 프록시 설정을 참조하십시오.

프록시는 SSL 이외에도 클라이언트 인증을 사용할 수 있는데, 이 경우 프록시에 요청을 하는 컴퓨터는 인증서나 다른 식별 형식을 제공하여 자신의 아이디를 확인할 수 있게 해야 합니다.

로드 균형 조정을 위한 프록싱

조직 내에서 프록시 서버를 여러 개 사용하여 웹 서버 간의 네트워크 로드 균형을 조정할 수 있습니다. 이 모델은 프록시 서버의 캐시 기능을 활용하여 로드 균형 조정을 위한 서버 풀을 만듭니다. 이 경우 프록시 서버는 방화벽의 어느 쪽에도 위치할 수 있습니다. 일별로 많은 양의 요청을 수신하는 웹 서버가 있는 경우 프록시 서버를 사용하여 웹 서버의 로드를 줄이고 네트워크 액세스의 효율성을 높일 수 있습니다.

프록시 서버는 클라이언트 요청을 실제 서버로 전달하는 매개자 역할을 합니다. 프록시 서버는 요청된 문서를 캐시합니다. 프록시 서버가 두 개 이상인 경우 DNS는 프록시 서버의 IP 주소를 "라운드 로빈" 방식으로 선택하여 요청을 임의로 라우팅할 수 있습니다. 클라이언트는 매번 같은 URL을 사용하지만 요청은 매번 다른 프록시를 통해 라우팅될 수 있습니다.

프록시 서버를 여러 개 사용하여 사용량이 많은 컨텐트 서버 하나에 대한 요청을 처리하면 프록시 서버를 한 개 사용할 때보다 서버가 로드를 더 많이 처리할 수 있고 효율성도 더 높아집니다. 프록시가 처음으로 컨텐트 서버에서 문서를 검색하는 초기 시작 기간이 지나면 컨텐트 서버에 대한 요청의 수가 크게 줄어들 수 있습니다.

CGI 요청과 일부 새 요청만 항상 컨텐트 서버로 전달되고 나머지는 프록시가 처리할 수 있습니다. 예를 들어 서버에 대한 요청의 90%가 CGI 요청이 아니어서 캐시가 가능하고 컨텐트 서버는 일별로 2백만 히트를 수신한다고 가정합니다. 이 경우 세 개의 역방향 프록시를 연결하고 각각 일별로 2백만 히트를 처리하면 하루에 약 6백만 히트를 처리할 수 있습니다. 컨텐트 서버에 도달하는 요청의 10%는 각 프록시로부터 일일 약 200,000 히트까지 또는 총 600,000 히트만 추가할 수 있으므로 효율성이 훨씬 높아집니다. 히트 수는 약 2백만에서 6백만으로 증가할 수 있으며 컨텐트 서버의 로드는 이에 따라 2백만에서 600,000으로 줄어들 수 있습니다. 실제 결과는 상황에 따라 다를 수 있습니다.

그림 14–5 로드 균형 조정에 사용되는 프록시