X-Accel-Redirect 헤더로 클라우드 NGINX Access Control

Amazon S3와 같은 전용 클라우드 스토리지의 가용성이 높아지면서 웹사이트들이 자산을 클라우드로 옮기고 있습니다. 무한에 가까운 확장성, 사용량 기반 비용, 서비스형 스토리지의 단순성 등 이점은 분명합니다. 하지만 클라우드 스토리지는 애플리케이션이 컴퓨팅 클라우드나 로컬 On-Premise 데이터 센터 등 다른 곳에서 실행될 때 한 서비스에 저장된 자산에 대한 액세스 제어를 어떻게 적용할 것인가와 같은 몇 가지 중요한 질문도 야기합니다. 또한 클라이언트에게 자산 위치의 세부 정보를 어떻게 숨길 수 있을까요?

NGINX Plus를 사용하면 액세스 제어 로직을 자산 스토리지에서 분리할 수 있습니다. 액세스 제어 애플리케이션은 인증 작업(쿠키 확인, 자격 증명 확인 등)을 수행하며, 로그인 양식, 액세스 거부 양식 또는 요청된 리소스를 적절히 제공하도록 NGINX Plus에 지시하는 데 필요한 메타데이터를 보유합니다. 리소스는 항상 NGINX Plus에 의해 Proxy되며 실제 URL은 클라이언트에게 공개되지 않으므로 악의적인 사용자가 NGINX Plus를 우회하여 리소스에 직접 액세스할 방법이 없습니다.

이 개념은 자산이 하이브리드 또는 멀티클라우드 아키텍처에 저장되는 경우와 같이 훨씬 더 정교한 사용 사례에 적용할 수 있습니다. 여러 서비스를 사용하면 기업은 데이터 스토리지에 대한 최적의 가격을 찾고, 공급업체 종속을 피하고, 재해 복구에 대비할 수 있습니다. 예를 들어, 일부 자산은 로컬 On-Premise 데이터 센터에 저장하고 NGINX Plus에서 직접 서비스하는 반면, 다른 자산은 여러 퍼블릭 또는 프라이빗 클라우드 서비스에 저장할 수 있습니다. 다음은 로컬 On-Premise 데이터 센터에서 NGINX Plus와 액세스 제어 애플리케이션이 실행되고 자산이 로컬 스토리지와 세 개의 다른 클라우드 스토리지 서비스에 분산되어 있는 예시입니다.

NGINX Plus는 X-Accel-Redirect 응답 헤더를 사용하여 이 기능을 지원합니다. 이 헤더는 Upstream 그룹(Upstream 구성 블록에 의해 정의됩니다)에 속하는 서버에 의해 설정되며, 이 기능을 XSendfile이라고도 합니다. Upstream 서버가 X-Accel-Redirect 헤더에 설정한 값은 NGINX Plus에서 제공할 자산의 실제 URL을 제공하고 내부 리디렉션을 유발하여 클라이언트가 자산에 직접 액세스할 수 없도록 합니다. 이것이 어떻게 작동하는지 더 잘 이해하기 위해 요청/응답 흐름을 살펴봅시다.

1. 클라이언트가 파일 다운로드를 요청합니다. NGINX Plus는 요청을 수신하여 액세스 제어 애플리케이션을 호스팅하는 Upstream 서버로 전달합니다.

2. Upstream 서버는 사용자가 로그인되어 있고 요청된 리소스에 액세스할 수 있는 권한이 있는지 확인합니다. 그렇지 않은 경우 사용자는 로그인 또는 액세스 거부 양식으로 리다이렉션됩니다.

3. 사용자가 로그인하고 리소스에 액세스할 수 있는 권한이 있는 경우 리소스의 내부 URL이 X-Accel-Redirect 헤더에 기록됩니다.

4. NGINX Plus는 X-Accel-Redirect 헤더의 URL을 사용하여 내부 리다이렉션을 수행하고 로컬 또는 클라우드 서버에서 콘텐츠를 제공하며, 액세스 제어 서버에서 반환한 실제 응답 본문은 삭제합니다.

이 흐름은 노력의 분담을 허용합니다. NGINX Plus는 정적 콘텐츠 전송 및 Reverse Proxy Load Balancing과 같은 설계된 기능을 수행하고, 애플리케이션은 정적 콘텐츠 전송에 대한 세부 사항에서 벗어난 로직을 실행합니다. 또한 클라이언트가 사용하는 URL이 리소스의 실제 위치와 무관하도록 할 수 있습니다. 따라서 클라이언트에 제공되는 URL을 변경하거나 NGINX Plus를 재구성할 필요 없이 콘텐츠를 클라우드 간에 이동할 수 있습니다. 외부 URL을 리소스의 실제 위치에 매핑하는 작업은 애플리케이션에서 처리합니다. NGINX Plus는 X-Accel-Redirect 헤더에 지정된 리다이렉션을 자동으로 처리하여 NGINX Plus 구성을 간소화합니다.

목차

1. 로컬 파일 또는 외부 호스팅 파일을 제공하도록 NGINX Plus 구성하기
1-1. 로컬 파일 제공
1-2. 외부 파일 제공

2. 요약

1. 로컬 파일 또는 외부 호스팅 파일을 제공하도록 NGINX Plus 구성하기

1-1. 로컬 파일 제공

다음은 위에서 설명한 사용 사례의 단순화된 버전을 처리하기 위한 NGINX Plus 구성 및 PHP 코드의 Snippet으로, NGINX Plus에서 로컬로 파일을 제공합니다. 이 예제에서는 클라이언트가 /download/filename URL에 액세스하면 NGINX Plus가 /download.php? path=filename으로 리다이렉션합니다. download.php 프로그램은 X-Accel-Redirect 헤더를 /files/filename으로 설정하여 NGINX Plus가 내부 리디렉션을 수행하고 /files location에서 /var/www/filename 파일을 제공하도록 합니다. 예제를 단순하게 유지하기 위해 권한 부여 로직과 반환할 내부 URL을 결정하는 처리는 생략했습니다.

NGINX Plus 구성.

server {
    listen 80;
    server_name www.example.com

    location ~* ^/download/(.*) {
        proxy_pass http://127.0.0.1:8080/download.php?path=$1;
    }

    location /files {
        root /var/www;
        internal;
    }
}

PHP 프로그램.

<?php
# Get the file name
$path = $_GET["path"];

# Do an internal redirect using the X-Accel-Redirect header
header("X-Accel-Redirect: /files/$path");

# PHP will default Content-Type to text/html.
# If left blank, NGINX Plus sets it correctly
header('Content-Type:');
?>

PHP 프로그램이 127.0.0.1:8080에서 사용할 수 있고, 파일 abc.jpg가 NGINX Plus 서버의 /var/www/files 디렉터리에 있으며, www.example.com가 NGINX Plus 서버의 IP 주소에 매핑되어 있다고 가정합니다. 이 예제 구성에 따라 사용자가 http://www.example.com/download/abc.jpg에 접속하면 abc.jpg의 콘텐츠가 브라우저에 표시되며, 파일이 실제로는 /files 디렉터리에서 제공되더라도 URL은 http://www.example.com/download/abc.jpg로 설정됩니다.

1-2. 외부 파일 제공

다음은 다른 사용 사례인 외부 서버(이 경우 Amazon S3)에서 리소스 검색을 처리하기 위한 NGINX Plus 구성 및 PHP 코드의 Snippet입니다. 이 예제에서 클라이언트는 여전히 URL 경로 /download/filename을 입력하고 NGINX Plus는 여전히 이를 /download.php? path=filename으로 리다이렉션하지만, download.php 프로그램은 X-Accel-Redirect 헤더를 /internal_redirect/s3.amazonaws.com/nginx-data/filename으로 설정하여 NGINX Plus가 내부 리다이렉션을 수행하고 Amazon S3로 요청을 Proxy하도록 합니다. 다시 말하지만, 예제를 단순하게 유지하기 위해 권한 부여 로직과 반환할 내부 URL을 결정하는 처리는 생략했습니다.

NGINX Plus 구성.

server {
    listen 80;
    server_name www.example.com;
    location ~* ^/download/(.*) {
        proxy_pass http://127.0.0.1:8080/download.php?path=$1;
   }

    location ~* ^/internal_redirect/(.*) {
        internal;
        resolver 8.8.8.8;
        proxy_pass http://$1;
    }
}

PHP 프로그램.

<?php
# Get the file name

$prefix = "s3.amazonaws.com/nginx-data/";
$path = $_GET["path"];

# Do an internal redirect using the X-Accel-Redirect header
header("X-Accel-Redirect: /internal_redirect/$prefix$path);

# PHP defaults Content-Type to text/html.
# If left blank, NGINX Plus sets it correctly
header('Content-Type:');
?>

이 구성을 사용하면 클라이언트가 http://www.example.com/download/30-banner 에 접속하면 브라우저에 NGINX Plus AMI 배너 페이지가 표시됩니다. URL은 Amazon S3에서 제공되더라도 http://www.example.com/download/30-banner 로 설정됩니다. 실제 사용 사례에서 PHP 프로그램에는 클라이언트의 요청에 대해 NGINX Plus가 응답하는 방식을 결정하는 로직이 포함됩니다. 추가 헤더를 설정해야 할 수도 있고, PHP 프로그램과 추가 NGINX Plus 지시문을 사용해야 할 수도 있지만, 이 예는 필요한 기본 사항만 보여주기 위해 단순화했습니다.

2. 요약

NGINX Plus와 X-Accel-Redirect 헤더를 사용하면 NGINX Plus를 실행하고 다양한 위치에서 파일을 저장할 수 있으며 환경을 쉽게 확장하고 변경할 수 있는 유연성을 확보할 수 있습니다. 즉, 파일을 안전하게 보호하고 클라이언트에게 리소스의 실제 위치를 숨기면서 로컬 데이터 센터는 물론 퍼블릭, 프라이빗, 하이브리드 클라우드 환경에도 NGINX Plus와 데이터를 저장할 수 있습니다. 점점 더 많은 기업이 클라우드 컴퓨팅을 활용함에 따라 이러한 유형의 기능에 대한 필요성이 커질 것입니다.

NGINX Plus를 직접 사용해 보거나 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.