Nginx에서 보안 헤더를 구성하는 방법

웹 애플리케이션의 보안을 강화하려면 NGINX에서 보안 헤더를 구성하는 것이 필수적입니다. 보안 헤더는 XSS(교차 사이트 스크립팅), 클릭재킹 및 기타 코드 삽입 공격과 같은 다양한 공격으로부터 보호합니다. 이는 브라우저에 사이트 콘텐츠 처리 방법을 지시하여 추가 보안 계층을 제공합니다.

이 가이드는 NGINX에서 보안 헤더를 구성하는 단계를 안내하여 웹 애플리케이션을 보호하고 전반적인 보안을 향상시키는 데 도움을 줍니다.

NGINX에서 HSTS(HTTP 엄격한 전송 보안) 구현

HSTS 이해

HSTS(HTTP Strict Transport Security)는 중요한 웹사이트 보안 프로토콜입니다. 도메인에 대한 연결이 HTTPS를 통해서만 이루어지도록 강제합니다. 이는 중간자 공격과 같은 위험을 완화하고 온라인으로 전송되는 데이터의 무결성과 기밀성을 보장합니다. 사용자가 HTTP를 통해 사이트에 액세스하려고 하면 HSTS는 자동으로 연결을 HTTPS로 업그레이드합니다.

NGINX에서 HSTS 구성

NGINX에서 HSTS를 설정하려면 NGINX 구성 파일에서 서버 블록을 업데이트해야 합니다. 이 파일은 일반적으로 /etc/nginx/nginx.conf 또는 /etc/nginx/sites-available/의 사이트별 구성 내에 있습니다. 업데이트에는 지정된 도메인에 대해 항상 HTTPS를 사용하도록 브라우저에 지시하는 헤더 추가가 포함됩니다.

도메인의 서버 블록에 다음 줄을 추가합니다.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

이 줄에는 두 가지 구성 요소가 포함되어 있습니다.

  • max-age=31536000: 향후 12개월 동안 사이트에 HTTPS를 사용하도록 브라우저에 지시합니다.
  • includeSubDomains: 포괄적인 보안을 위해 사이트의 모든 하위 도메인에 HSTS 정책을 적용합니다.

HSTS를 사용한 샘플 NGINX 구성

HSTS 헤더가 포함된 NGINX 구성은 다음과 같습니다.

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        proxy_pass http://my_portal;
    }
}

이 헤더를 추가한 후 NGINX를 다시 로드하여 sudo systemctl reload nginx 또는 sudo nginx -s reload를 사용하여 변경 사항을 적용합니다.

추가 NGINX 구성 예

다양한 시나리오의 경우 HSTS를 사용한 NGINX 구성이 다를 수 있습니다. 추가 예는 다음과 같습니다.

다중 도메인 서버

server {
    listen 80;
    server_name example1.com example2.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        # Configuration details
    }
}

이 구성은 동일한 서버에서 호스팅되는 여러 도메인에 HSTS를 적용합니다. 나열된 각 도메인은 HTTPS 연결을 시행합니다.

SSL 종료 서버

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        # Configuration details
    }
}

이 설정은 SSL 종료를 처리하는 서버용입니다. 지정된 SSL 인증서를 사용하여 보안 포트(443)에 HSTS를 구성하여 보안 연결을 강화합니다.

NGINX에서 CSP(콘텐츠 보안 정책) 구성

NGINX에서 CSP 구현

CSP(콘텐츠 보안 정책)를 NGINX에 통합하는 것은 웹 애플리케이션 보안을 강화하기 위한 전략적 움직임입니다. NGINX 구성 파일의 서버 블록 내에 특정 헤더를 추가하는 작업이 포함됩니다. 일반적으로 /etc/nginx/nginx.conf 또는 /etc/nginx/sites-available/ 디렉터리에 있는 이 파일은 CSP를 효과적으로 적용하려면 주의 깊게 편집해야 합니다.

기본 CSP 설정의 경우 서버 블록에 다음 줄을 추가합니다.

add_header Content-Security-Policy "default-src 'self';" always;

이 지시어는 웹 사이트의 도메인('자체')에 대한 콘텐츠 로드를 제한하여 악의적인 외부 콘텐츠 실행 위험을 크게 줄입니다.

CSP를 사용한 NGINX 구성 예

기본 CSP 지시문을 사용한 NGINX 구성은 다음과 같습니다.

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Content-Security-Policy "default-src 'self';" always;

    location / {
        proxy_pass http://my_portal;
    }
}

이 지시어를 추가한 후 sudo systemctl reload nginx 또는 sudo nginx -s reload를 사용하여 NGINX를 다시 로드하세요.

특정 요구 사항에 맞게 CSP 사용자 정의

CSP는 웹 사이트의 특정 보안 요구 사항을 해결하도록 맞춤화될 수 있습니다. 다양한 시나리오에 대한 확장 구성은 다음과 같습니다.

모든 소스의 이미지 허용

add_header Content-Security-Policy "default-src 'self'; img-src *;" always;

이 구성을 사용하면 모든 소스에서 이미지를 로드하고 다른 유형의 콘텐츠를 엄격하게 제어할 수 있습니다.

특정 스크립트 및 스타일 구성

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trustedscript.com; style-src 'self' 'unsafe-inline';";

이 설정을 사용하면 인라인 스타일과 함께 도메인 및 신뢰할 수 있는 외부 소스의 스크립트를 허용하여 기능과 보안의 균형을 맞출 수 있습니다.

CSP 지시문 및 옵션 탐색

CSP의 지시문

CSP 지시문은 특정 콘텐츠 유형에 대한 정책을 정의하는 규칙입니다. 일반적인 지시어는 다음과 같습니다.

  • default-src: 대부분의 콘텐츠 유형에 적용되는 기본 정책입니다.
  • script-src: JavaScript 리소스의 소스를 관리합니다.
  • style-src: CSS 리소스에 허용되는 소스를 지정합니다.
  • img-src: 이미지 리소스의 소스를 제어합니다.
  • connect-src: XMLHttpRequest, WebSocket 및 EventSource와 같은 네트워크 연결에 대한 정책을 설정합니다.

CSP의 소스 표현식

소스 표현식은 각 지시문에 대해 허용되는 소스를 정의합니다.

  • '없음': 모든 소스를 차단합니다.
  • 'self': 동일한 출처의 리소스를 허용합니다.
  • 'unsafe-inline': 스타일이나 JavaScript URL과 같은 인라인 리소스를 허용합니다.
  • 'unsafe-eval': JavaScript를 허용합니다. eval() 기능 및 이와 유사한 방법.
  • https:: 모든 HTTPS URL의 리소스를 활성화합니다.

NGINX에서 X-XSS 보호 구성

X-XSS 보호 소개

X-XSS-Protection 또는 Cross-Site Scripting 헤더는 XSS(Cross-Site Scripting) 공격으로부터 웹 애플리케이션을 보호하는 데 필수적입니다. Chrome, Internet Explorer, Safari 등 주요 웹 브라우저에서 지원되는 이 헤더는 반사된 XSS 공격이 감지될 경우 페이지 로드를 방지하여 웹 보안을 강화합니다.

NGINX에서 X-XSS 보호 활성화

X-XSS-Protection 헤더를 NGINX 서버 구성에 통합하면 브라우저의 기본 XSS 보호가 강화됩니다. 이 보안 기능을 활성화하려면 일반적으로 /etc/nginx/nginx.conf 또는 /etc/nginx/sites-available/ 디렉터리에 있는 NGINX 구성 파일에 액세스하세요.

NGINX 구성 파일의 서버 블록에 다음 지시어를 삽입하세요.

add_header X-XSS-Protection "1; mode=block";

이 지시문은 두 부분으로 구성됩니다.

  • 1: 브라우저의 XSS 필터를 활성화합니다.
  • mode=block: XSS 공격이 감지되면 페이지를 삭제하려고 시도하는 대신 브라우저에 페이지를 차단하도록 지시합니다.

X-XSS 보호를 사용한 NGINX 구성 예

X-XSS-Protection을 포함한 예제 NGINX 구성은 다음과 같이 나타날 수 있습니다.

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-XSS-Protection "1; mode=block";

    location / {
        proxy_pass http://my_portal;
    }
}

이 헤더를 추가한 후 sudo systemctl reload nginx 또는 sudo nginx -s reload를 사용하여 NGINX를 다시 로드합니다.

추가 NGINX 구성 시나리오

SSL을 사용하는 서버의 경우

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header X-XSS-Protection "1; mode=block";

    # Further configuration
}

이 설정은 SSL을 사용하는 서버용으로, 암호화된 연결에서 X-XSS 보호가 활성화되도록 합니다.

여러 도메인 처리

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-XSS-Protection "1; mode=block";

    # Further configuration
}

이 구성은 단일 서버에서 호스팅되는 여러 도메인에 X-XSS 보호를 적용합니다.

NGINX에서 X-프레임 옵션 구성

X-프레임 옵션의 역할

X-Frame-Options는 클릭재킹 공격으로부터 웹사이트를 보호하도록 설계된 필수 보안 헤더입니다. 이러한 공격에 자주 사용되는 프레임이나 iframe에 웹 페이지가 표시되는 것을 방지합니다. 모든 주요 웹 브라우저에서 지원되는 X-Frame-Options는 광범위한 보호를 제공하여 다양한 플랫폼에서 웹 존재의 보안을 강화합니다.

NGINX에서 X-프레임 옵션 구현

NGINX 서버 구성에 X-Frame-Options 헤더를 통합하는 것은 사이트 보안을 강화하는 데 중요합니다. 이 작업에는 일반적으로 /etc/nginx/nginx.conf 또는 /etc/nginx/sites-available/ 디렉터리에 있는 NGINX 구성 파일을 편집하는 작업이 포함됩니다.

이 보안 기능을 활성화하려면 NGINX 구성 파일의 서버 블록에 다음 지시문을 추가하세요.

add_header X-Frame-Options "DENY";

"DENY"로 설정된 이 지시문은 프레임이나 iframe에서 페이지를 렌더링하려는 모든 시도를 차단하도록 브라우저에 지시하여 클릭재킹에 대한 강력한 방어 기능을 제공합니다.

X-프레임 옵션을 사용한 NGINX 구성 예

X-Frame-Options 헤더를 사용한 NGINX 설정의 예는 다음과 같습니다.

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-Frame-Options "DENY";

    location / {
        proxy_pass http://my_portal;
    }
}

이 헤더를 추가한 후에는 NGINX를 다시 로드하여 변경 사항을 활성화하는 것이 중요합니다. 이는 sudo systemctl reload nginx 또는 sudo nginx -s reload를 사용하여 수행할 수 있습니다.

X-Frame-Options에 대한 NGINX 구성 확장

SSL 지원 서버의 경우

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header X-Frame-Options "DENY";

    # Additional configuration
}

이 구성은 SSL을 사용하는 서버용으로 보안 연결에서 X-Frame-Options가 적용되도록 합니다.

여러 도메인 처리

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-Frame-Options "DENY";

    # Additional configuration
}

이 설정은 동일한 서버의 여러 도메인에 X-Frame-Options 헤더를 적용하여 각 도메인의 보안을 강화합니다.

NGINX에서 X-Content-Type-Options 구현

X-Content-Type-Options의 역할

X-Content-Type-Options는 브라우저의 MIME 유형 스니핑을 방지하는 웹 보안의 중요한 보안 헤더입니다. 이 헤더는 브라우저가 HTTP 헤더에 선언된 콘텐츠 유형을 존중하도록 강화하여 브라우저가 파일 유형을 잘못 해석할 때 발생할 수 있는 보안 취약성을 해결합니다(예: 이미지 파일을 실행 가능한 HTML로 처리하여 XSS(교차 사이트 스크립팅) 공격으로 이어질 수 있음)

NGINX에서 X-Content-Type-Options 설정

X-Content-Type-Options 헤더를 사용하여 웹 서버의 보안을 강화하려면 NGINX 구성 파일을 직접 수정해야 합니다. 이 파일은 일반적으로 /etc/nginx/nginx.conf 또는 /etc/nginx/sites-available/의 사이트별 구성 내에서 찾을 수 있습니다.

다음 줄을 추가하여 이 헤더를 통합합니다. server NGINX 구성 블록:

add_header X-Content-Type-Options "nosniff";

"nosniff" 설정은 브라우저가 서버의 지정된 콘텐츠 유형을 엄격하게 따르도록 지시하여 콘텐츠에 대한 대체 해석을 방지합니다.

X-Content-Type-Options를 사용한 NGINX 구성 예

X-Content-Type-Options가 포함된 NGINX 구성은 다음과 같이 구성될 수 있습니다.

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-Content-Type-Options "nosniff";

    location / {
        proxy_pass http://my_portal;
    }
}

구성을 업데이트한 후 변경 사항을 적용하려면 sudo systemctl reload nginx 또는 sudo nginx -s reload를 사용하여 NGINX를 다시 로드해야 합니다.

확장된 NGINX 구성 예

SSL/TLS 구성

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/key.pem;
    add_header X-Content-Type-Options "nosniff";

    # Additional SSL configurations and locations
}

이 설정은 보안을 강화하기 위해 보안 연결에 X-Content-Type-Options를 적용하는 SSL/TLS 서버용입니다.

다중 도메인 서버 구성

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-Content-Type-Options "nosniff";

    # Additional configurations for multiple domains
}

이 구성은 동일한 서버에서 호스팅되는 여러 도메인에 X-Content-Type-Options 헤더를 적용하여 모든 도메인에서 일관된 보안 설정을 보장합니다.

NGINX에서 리퍼러 정책 구성

리퍼러 정책의 기능

Referrer-Policy는 웹에서 사용자 개인 정보 보호 및 보안을 강화하기 위한 필수 HTTP 헤더입니다. 사용자가 귀하의 사이트에서 다른 사이트로 이동할 때 추천자 헤더에 포함되는 추천 정보의 양을 제어하여 민감한 정보가 웹 요청에 노출되지 않도록 보호합니다.

NGINX에서 리퍼러 정책 설정

NGINX 서버에서 Referrer-Policy 헤더를 구현하려면 일반적으로 /etc/nginx/nginx.conf 또는 /etc/nginx/sites-available/ 디렉토리에 있는 NGINX 구성 파일을 수정하십시오. 서버 블록에 다음 지시문을 추가합니다.

add_header Referrer-Policy "no-referrer";

"no-referrer"로 설정된 이 지시문은 사이트 탐색 중에 참조자 정보가 전송되지 않도록 보장하여 개인 정보 보호를 극대화합니다.

리퍼러 정책을 사용한 NGINX 구성 예

Referrer-Policy 헤더가 포함된 NGINX 구성은 다음과 같습니다.

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Referrer-Policy "no-referrer";

    location / {
        proxy_pass http://my_portal;
    }
}

이 헤더를 추가한 후 sudo systemctl reload nginx 또는 sudo nginx -s reload와 같은 명령을 사용하여 NGINX를 다시 로드합니다.

리퍼러 정책 옵션 및 정의

  • no-referrer: 리퍼러 정보가 전송되지 않습니다.
  • no-referrer-when-downgrade(기본값): 보안 페이지에서 동일한 출처 대상 또는 보안(HTTPS) 대상 URL에 대한 리퍼러 정보를 보냅니다.
  • Origin: 원본(Scheme, 호스트, 포트)만 보냅니다.
  • Origin-when-cross-origin: 동일한 출처 요청에 대해서는 전체 URL을 보내지만 다른 경우에는 출처만 보냅니다.
  • same-origin: 동일 출처 요청에 대해서는 전체 리퍼러를 보내지만 교차 출처 요청에 대해서는 헤더를 보내지 않습니다.
  • strict-origin: HTTPS 요청의 원본은 보내지만 HTTP 요청의 헤더는 보내지 않습니다.
  • strict-origin-when-cross-origin: 동일 출처 요청에 전체 리퍼러를 보내고, 출처는 HTTPS 페이지에서 HTTPS 대상으로, HTTP 대상에는 헤더를 보내지 않습니다.
  • unsafe-url: 원본이나 보안에 관계없이 전체 URL을 보냅니다(권장하지 않음).

확장된 NGINX 구성 예

SSL/TLS 구성

server {
    listen 443 ssl;
    server_name secure.example.com;
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/key.pem;
    add_header Referrer-Policy "no-referrer";

    # Additional SSL configurations
}

이 구성은 안전한 SSL/TLS 지원 환경에서 Referrer-Policy 헤더를 적용하여 암호화된 연결의 개인정보 보호를 강화합니다.

다중 도메인 서버 구성

server {
    listen 80;
    server_name example1.com example2.com;
    add_header Referrer-Policy "no-referrer";

    # Additional configurations for each domain
}

이 설정을 통해 동일한 서버에서 호스팅되는 여러 도메인에 Referrer-Policy 헤더가 적용되어 일관된 개인정보 보호 설정이 유지됩니다.

NGINX에서 권한 정책 구현

권한 정책 이해

Permissions-Policy 헤더는 웹 관리자가 웹 사이트의 브라우저 기능과 API를 정밀하게 제어할 수 있는 권한을 부여합니다. 이 헤더를 구성하면 사이트 보안 및 개인 정보 보호가 크게 강화되어 사이트의 특정 요구 사항에 따라 위치 정보, 카메라, 마이크 등의 기능 제한이 가능해집니다.

NGINX에서 권한 정책 구성

NGINX 서버에 Permissions-Policy 헤더를 통합하려면 일반적으로 /etc/nginx/nginx.conf 또는 /etc/nginx/sites-available/ 디렉터리에 있는 NGINX 구성 파일을 수정하세요.

서버 블록에 다음 지시문을 추가합니다.

add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

이 지시문은 다양한 브라우저 기능과 API를 나열하고 모두 ()로 설정하여 효과적으로 비활성화합니다. 이 구성은 사용자 개인 정보 보호나 보안을 손상시킬 수 있는 기능을 제한하는 포괄적인 접근 방식을 제공합니다.

권한 정책이 포함된 샘플 NGINX 구성

다음은 Permissions-Policy 헤더를 사용하여 NGINX 구성이 어떻게 보이는지에 대한 예입니다.

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

    location / {
        proxy_pass http://my_portal;
    }
}

이 지시문은 다양한 브라우저 기능과 API를 포괄적으로 나열하고 이를 효과적으로 비활성화하기 위해 ()로 설정합니다.

권한 정책이 포함된 샘플 NGINX 구성

권한 정책을 포함한 NGINX 구성은 다음과 같이 나타날 수 있습니다.

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

    location / {
        proxy_pass http://my_portal;
    }
}

이러한 변경을 수행한 후 sudo systemctl reload nginx 또는 sudo nginx -s reload를 사용하여 NGINX를 다시 로드하세요.

권한-정책 옵션 설명

Permissions-Policy 헤더를 사용하면 다양한 기능의 사용을 맞춤설정할 수 있습니다.

  • 지리적 위치: 위치정보 데이터에 대한 액세스를 제어합니다.
  • 미디: MIDI 장치에 대한 액세스를 관리합니다.
  • 알림: 알림 표시를 관리합니다.
  • 푸시: 푸시 알림 기능에 영향을 미칩니다.
  • 동기화-xhr: 동기 XMLHTTPRequest와 관련됩니다.
  • 가속도계: 장치의 가속도계에 대한 액세스를 지시합니다.
  • 자이로스코프: 자이로스코프 액세스를 제어합니다.
  • 자력계: 기기의 자력계에 대한 액세스를 관리합니다.
  • 지불: 결제 요청 기능에 적용됩니다.
  • USB: USB 장치에 대한 액세스를 관리합니다.
  • VR: 가상 현실 기능과 관련이 있습니다.
  • 카메라: 카메라 접근을 관리합니다.
  • 마이크로폰: 마이크 액세스를 지시합니다.
  • 스피커: 스피커 장치에 대한 접근을 제어합니다.
  • 떨리다: 진동 API에 영향을 줍니다.
  • 주변 광 센서: 주변광 센서와 관련됩니다.
  • 자동 재생: 미디어 자동 재생을 제어합니다.
  • 암호화된 미디어: 암호화된 미디어 접근을 관리합니다.
  • 실행 클립보드: 클립보드 읽기/쓰기 액세스를 관리합니다.
  • 문서 도메인: document.domain 기능과 관련됩니다.
  • 전체 화면: 전체 화면 액세스를 지정합니다.
  • 이미지 캡처: 이미지 캡처 기능을 제어합니다.
  • 게으른 로드: 이미지의 지연 로딩에 영향을 줍니다.
  • 레거시 이미지 형식: 레거시 이미지 형식과 관련됩니다.
  • 대형 이미지: 대형 이미지의 로드를 관리합니다.
  • 최적화되지 않은 손실 이미지: 최적화되지 않은 손실 이미지를 관리합니다.
  • 최적화되지 않은 무손실 이미지: 최적화되지 않은 무손실 이미지와 관련됩니다.
  • 크기가 조정되지 않은 미디어: 명시적인 크기 없이 미디어를 제어합니다.
  • 수직 스크롤: 수직 스크롤에 영향을 줍니다.
  • 웹 공유: 웹 공유 기능과 관련됩니다.
  • xr 공간 추적: XR 공간 추적을 관리합니다.

NGINX의 권한 정책 고급 구성

특정 도메인 및 와일드카드를 사용하여 권한 정책 구성

()를 사용하여 기능을 비활성화하는 기본 설정 외에도 NGINX의 권한 정책은 특정 도메인의 특정 기능을 허용하거나 와일드카드를 사용하도록 맞춤화될 수 있습니다. 이 고급 구성을 사용하면 웹사이트에서 액세스할 수 있는 항목과 위치를 보다 세밀하게 제어할 수 있습니다.

예: 특정 도메인의 기능 허용

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(https://trusteddomain.com), microphone=(https://alloweddomain.com)";

    location / {
        proxy_pass http://my_portal;
    }
}

이 구성은 https://trusteddomain.com에서만 지리적 위치 데이터 액세스를 허용하고 https://alloweddomain.com에서만 마이크 액세스를 허용하여 이러한 민감한 기능을 신뢰할 수 있는 소스로 제한하여 보안을 강화합니다.

예: 광범위한 권한을 위해 와일드카드 사용

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "camera=*; fullscreen=*";

    location / {
        proxy_pass http://my_portal;
    }
}

이 설정의 와일드카드 *는 모든 도메인에서 카메라 액세스 및 전체 화면 모드를 허용합니다. 이 접근 방식은 다양한 소스에서 광범위한 기능 액세스가 필요한 웹 사이트에 적합한 더 광범위한 권한을 제공합니다.

예: 제한 사항과 권한 결합

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "accelerometer=(); gyroscope=(self https://example2.com); payment=*";

    location / {
        proxy_pass http://my_portal;
    }
}

이 구성에서는 가속도계 액세스가 비활성화되고 동일한 도메인 및 https://example2.com에서 자이로스코프 액세스가 허용되며 모든 도메인에서 결제 요청이 허용됩니다.

NGINX에서 Curl 명령을 사용하여 보안 헤더 확인

Curl을 사용하여 보안 헤더 확인

컬 명령은 NGINX 서버의 보안 헤더 구성을 확인하는 데 유용한 도구입니다. 이를 통해 웹사이트 헤더를 검사하고 보안 헤더가 올바르게 설정되었는지 확인할 수 있습니다. 이 확인 단계는 웹 서버의 보안 조치가 활성화되어 의도한 대로 작동하는지 확인하는 데 중요합니다.

헤더 확인을 위한 Curl 명령 실행

웹사이트 헤더를 확인하려면 터미널에서 다음 명령을 실행하세요.

curl -I http://example.com

example.com을 도메인 이름으로 바꾸세요. 이 명령은 서버의 헤더를 요청하여 활성 보안 구성에 대한 통찰력을 제공합니다.

예상 결과 및 해석

컬 명령을 실행하면 다음과 유사한 출력이 표시됩니다.

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 20 Mar 2023 00:00:00 GMT
Content-Type: text/html
Connection: keep-alive
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self';
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();"

이 출력은 서버에 Strict-Transport-Security, Content-Security-Policy, X-XSS-Protection 등과 같은 다양한 보안 헤더의 존재와 올바른 구성을 확인합니다. 출력에 나열된 각 헤더는 다양한 웹 취약성으로부터 웹 서버를 보호하고 보호하는 데 특정 역할을 합니다.

결론

NGINX에서 보안 헤더를 구성하면 웹 애플리케이션의 보안이 크게 향상됩니다. 진화하는 보안 위협에 적응할 수 있도록 보안 헤더를 정기적으로 검토하고 업데이트하세요. 이러한 헤더를 구현하면 광범위한 공격으로부터 보호하고 사용자에게 보다 안전한 탐색 환경을 보장할 수 있습니다. 웹 자산을 강력하게 보호하려면 경계를 유지하고 NGINX 구성을 최신 상태로 유지하세요.

Joshua James

코멘트를 남겨주세요