Nextcloud의 Strict-Transport-Security(HSTS) 헤더 누락 경고를 해결합니다.

Nextcloud에서 "Strict-Transport-Security HTTP 헤더가 구성되지 않았습니다."라는 오류 메시지가 표시되면, 해당 문제는 HTTPS 응답을 처리하는 계층(Apache, Nginx 또는 TLS 연결을 종료하는 공용 리버스 프록시)에서 해결해야 합니다. Nextcloud의 최신 관리 설명서에서는 헤더가 누락되었거나 특정 시간 max-age미만인 15552000경우를 보안 경고로 간주합니다. 공용 HTTPS 엔드포인트에 해당 헤더가 추가되면 브라우저는 지정된 기간 동안 호스트가 HTTPS를 사용해야 함을 인식하게 됩니다.

기본적인 변경 사항은 작지만, 그 범위는 중요합니다. HSTS는 유효한 인증서가 있는 정상 작동하는 HTTPS 엔드포인트에만 적용하십시오. 먼저 호스트에만 적용하고, 영향을 받는 모든 호스트 이름이 HTTPS를 지원할 준비가 된 후에 추가하십시오 includeSubDomains. 이 가이드는 2026년 10월에 제공되는 Nextcloud 관리 문서 (보안 경고 지침 및 서버 강화 지침preload 포함)를 반영합니다 .

경고의 의미는 무엇인가요?

HTTP Strict Transport Security(HSTS)는 브라우저에게 해당 호스트 이름에 대한 향후 요청에 HTTPS를 사용하도록 지시하는 응답 헤더입니다. 이는 브라우저가 유효한 HTTPS 연결을 통해 정책을 수신한 후 일반 HTTP로 되돌아가는 것을 방지하는 데 도움이 됩니다. Nextcloud는 공개 응답을 확인하고 권장 최소 유효 기간을 충족하지 않는 정책이 있는 경우 경고를 표시합니다.

HSTS는 TLS 활성화 또는 HTTP를 HTTPS로 리디렉션하는 것을 대체하는 것이 아닙니다. 브라우저는 HTTPS를 통해 전달된 HSTS 정책만 허용합니다. 브라우저가 정책을 학습하기 전인 첫 방문 시에는 호스트 이름이 브라우저 사전 로드 목록에 포함되어 있지 않으면 초기 요청이 여전히 취약할 수 있습니다. 일반적인 HTTP-HTTPS 리디렉션은 여전히 ​​유용하지만 헤더를 대체하지는 않습니다.

헤더를 전송해야 하는 서버를 찾으십시오.

설정을 변경하기 전에 공개 요청을 추적하십시오. 사용자가 HTTPS를 통해 Apache 또는 Nginx에 직접 연결하는 경우 해당 웹 서버의 TLS 가상 호스트를 구성하십시오. 로드 밸런서, 인그레스, CDN 또는 리버스 프록시가 공개 TLS 연결을 종료하는 경우 브라우저로 응답을 전송하는 계층을 구성하십시오. 내부 HTTP 연결에만 헤더를 추가하는 것은 공개 응답에 영향을 미치지 않을 수 있습니다.

Nextcloud는 리버스 프록시를 지원되는 배포 패턴으로 문서화하고 있으며, 관리자는 필요한 경우 신뢰할 수 있는 프록시를 정의해야 합니다. 프록시의 HSTS(고해상도 보안 스키마) 처리는 Nextcloud의 URL 및 클라이언트 IP 처리와는 별개입니다. 특히, overwriteprotocol일부 프록시 구성에서 외부 스키마를 Nextcloud가 인식하도록 돕는 역할을 하며, 이를 설정한다고 해서 HSTS 응답 헤더가 자동으로 추가되는 것은 아닙니다. 애플리케이션에서 HTTP 링크가 생성되거나 프록시 관련 경고가 발생하는 경우, Nextcloud 공식 리버스 프록시 구성 가이드를 참조하십시오.

정책을 변경하기 전에

  • https://cloud.example.com인증서 오류 없이 로드되고 의도한 인증서 체인을 사용하는지 확인하십시오 .
  • HTTP 요청이 HTTPS를 통해서도 동일한 호스트 이름으로 리디렉션되는지 확인하십시오.
  • 고려하기 전에 동일한 상위 도메인 아래에 있는 다른 서비스 및 하위 도메인을 식별하십시오 includeSubDomains.
  • 관리자 경로 또는 서버 콘솔을 항상 사용할 수 있도록 유지하십시오. HSTS 캐시가 있는 브라우저는 정책 기간 동안 사용자가 인증서 오류를 우회하는 것을 허용하지 않습니다.

예시에서 <호스트 이름> 부분을 실제 Nextcloud 호스트 이름으로 바꾸십시오 cloud.example.com. 예시 호스트 이름을 프로덕션 환경 설정에 복사하지 마십시오.

Apache에서 HSTS를 설정하세요

Nextcloud를 서비스하는 Apache TLS 가상 호스트에서 헤더 모듈을 활성화하고 정책을 추가하세요. Nextcloud의 보안 강화 가이드에서는 6개월 값을 권장하며 includeSubDomains, 다음 호스트 전용 버전은 신중한 시작점입니다.

<VirtualHost *:443>
    ServerName cloud.example.com

    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=15552000"
    </IfModule>

    # Existing Nextcloud and TLS directives
</VirtualHost>

사용하는 배포판의 Apache 설정에서 HTTPS가 활성화되어 있는지 확인하십시오 mod_headers. HTTPS 가상 호스트에 지시문을 추가하고, 포트 80 가상 호스트에는 추가하지 마십시오. 설치된 배포판에 맞는 명령어를 사용하여 구성을 검증한 다음, 서비스 관리자를 사용하여 Apache를 다시 로드하십시오. 예를 들어, 많은 systemd 기반 배포판 에서는 `--service` sudo apachectl configtest뒤에 `--service`가 옵니다. sudo systemctl reload apache2일부 배포판에서는 서비스 이름이 `--service`입니다 httpd. 사용하는 패키지 및 서비스 이름과 일치하는 명령어를 사용하십시오.

Nginx에서 HSTS 설정

serverHTTPS를 수신하고 공개 Nextcloud 호스트 이름을 제공하는 Nginx 블록에 다음을 추가하세요.

server {
    listen 443 ssl;
    server_name cloud.example.com;

    add_header Strict-Transport-Security "max-age=15552000" always;

    # Existing certificate and Nextcloud configuration
}

이 always매개변수를 사용하면 응답 상태와 관계없이 Nginx가 헤더를 추가합니다. Nginx는 운영자가 예상치 못할 수 있는 상속 규칙을 문서화하고 있습니다. add_header하위 구성 수준의 지시문은 일반적인 상속 동작을 변경합니다. 중첩된 location블록이 자체 add_header지시문을 정의하는 경우 서버 수준의 HSTS 헤더가 더 이상 상속되지 않을 수 있습니다. 활성 구성을 확인하고 로그인 페이지 및 정적 리소스를 포함한 대표적인 URL을 테스트하십시오. 자세한 내용은 Nginx 헤더 모듈 공식 문서를 참조하십시오 .

변경 사항을 적용하기 전에 명령을 실행하십시오 sudo nginx -t. 유효성 검사에 성공하면 시스템에 맞는 서비스 명령(일반적으로 `nginx.reload`)을 사용하여 Nginx를 다시 로드하십시오 sudo systemctl reload nginx. 구문 검사에 실패한 경우 다시 로드하기 전에 수정해야 합니다.

리버스 프록시 또는 TLS 터미네이터를 구성하십시오.

공용 HTTPS 연결이 리버스 프록시에서 종료되는 경우, 해당 프록시의 HTTPS 응답에 HSTS 헤더를 포함해야 합니다. 예를 들어, 프록시는 Nextcloud 백엔드와의 연결이 HTTP를 사용하더라도 HSTS 헤더를 전송할 수 있습니다. 암호화되지 않은 백엔드 응답에만 HSTS 헤더를 전송하고 브라우저가 이를 인식할 것이라고 가정해서는 안 됩니다.

프록시와 백엔드 모두 동일한 헤더를 추가하는지 확인하십시오. 중복된 HSTS 필드는 진단을 어렵게 할 수 있으며, 프록시가 백엔드 헤더를 덮어쓰거나 숨길 수도 있습니다. 정책을 관리할 공개 레이어를 하나 선택하거나, 브라우저가 명확한 하나의 값을 수신하도록 레이어를 의도적으로 구성하십시오. 프록시를 변경한 후, 예상되는 호스트와 스키마를 Nextcloud로 전달하는지, 그리고 HTTPS 링크가 여전히 작동하는지 확인하십시오.

대중의 반응을 확인하세요

로컬호스트나 백엔드 주소뿐만 아니라 공개 HTTPS 호스트 이름으로 요청하십시오.

curl -sSI https://cloud.example.com
curl -sSIL http://cloud.example.com

첫 번째 응답에서 다음과 유사한 헤더를 정확히 하나 찾으십시오.

Strict-Transport-Security: max-age=15552000

두 번째 명령은 리디렉션을 확인합니다. HTTP URL이 의도한 HTTPS 호스트 이름에 도달하는지 확인한 다음, HTTPS 응답에서 HSTS 헤더를 검사합니다. 브라우저는 일반 HTTP를 통해 수신된 HSTS 헤더를 무시하므로 초기 80번 포트 리디렉션에는 해당 헤더가 나타나지 않을 수 있습니다. 브라우저 개발자 도구를 사용할 수도 있습니다. 네트워크 패널을 열고 HTTPS 페이지를 새로 고침한 다음, 문서 응답을 선택하고 응답 헤더를 검사하십시오.

구성에 중첩된 위치, 여러 프록시 계층 또는 별도의 정적 자산 처리가 있는 경우 두 개 이상의 응답 경로를 확인하십시오. 그런 다음 Nextcloud 관리 설정으로 이동하여 보안 개요를 새로 고치십시오. 경고가 새로 고쳐지는 데 시간이 걸릴 수 있으며 Nextcloud가 검색하는 정확한 공개 URL을 반영할 수 있으므로 해당 URL을 테스트한 URL과 비교하십시오.

보증 범위와 기간을 신중하게 선택하세요.

max-age초 단위 의 정책 기간은 155520006개월로, Nextcloud에서 명시한 경고 임계값과 일치합니다. 정책은 브라우저가 새롭고 유효한 HSTS 헤더를 수신할 때 갱신됩니다. 나중에 정책을 단축하거나 제거하려면 max-age=0영향을 받는 각 호스트 이름에 대해 HTTPS를 통해 전달해야 합니다. 변경 기간 동안 다시 방문하지 않는 브라우저는 현재 정책의 유효 기간이 만료될 때까지 캐시된 정책을 유지합니다.

includeSubDomains이 정책은 호스트 이름 아래의 모든 서브도메인에 적용됩니다. 현재 및 계획된 모든 서브도메인이 유효한 인증서를 사용하여 HTTPS를 지원하는 경우에만 사용하십시오. 그렇지 않으면 특정 서비스(예: mail.example.com또는 ) 가 브라우저에서 접근할 수 없게 될 수 있습니다.legacy.example.com

토큰 preload추가는 별도의 중요한 결정 사항입니다. Nextcloud의 보안 강화 지침에서는 호스트 이름을 브라우저 사전 로드 목록에 추가하는 방법을 설명하고 있으며, 제거 후 설치된 브라우저에 반영되기까지 몇 달이 걸릴 수 있다고 경고합니다. 스캐너 탐지 결과를 빠르게 해결하기 위한 방법으로 추가하지 마십시오. 먼저 필요한 모든 사전 로드 조건과 모든 하위 도메인에 미치는 영향을 확인하고, 포함을 요청하려는 경우 공식 HSTS 사전 로드 서비스 지침을 따르십시오.

경고 메시지가 계속 표시되는 경우

  • curl에서 헤더가 누락되었습니다. 가상 호스트, 프록시 또는 Nginx 위치를 잘못 설정했을 수 있습니다. 공용 DNS 대상과 활성 서버 구성을 확인하십시오.
  • 해당 헤더는 일부 페이지에만 나타납니다. 중첩된 Nginx add_header지시문, 오류 처리, 정적 자산 경로 및 프록시 규칙을 확인하세요.
  • 응답에는 여러 정책이 있습니다. 어떤 계층에 필드가 추가되는지 파악하고 이를 하나의 일관된 값으로 통합합니다.
  • 헤더는 있지만 경고가 계속 표시됩니다. Nextcloud의 외부 구성 URL이 동일한 HTTPS 엔드포인트로 확인되는지 확인하고, 프록시 스키마 처리를 점검한 다음 관리자 개요를 다시 로드하십시오.
  • HTTPS 또는 인증서가 준비되지 않았습니다. 먼저 TLS 및 HTTP-HTTPS 라우팅 문제를 해결하십시오. HSTS는 손상된 인증서를 복구하거나 HTTPS를 자체적으로 활성화할 수 없습니다.

공용 HTTPS 응답에 의도한 HSTS 값이 일관되게 포함되고, Nextcloud가 공용 HTTPS URL에 올바르게 접속할 수 있으며, 브라우저가 인증서 또는 리디렉션 오류 없이 인스턴스를 로드할 수 있으면 문제가 해결된 것입니다. HSTS는 반환되는 브라우저에 대한 전송 정책 적용을 개선하는 기능이며, 인증서 관리, 보안 프록시 구성 또는 검증된 복구 경로를 대체하는 것은 아닙니다.

댓글 남기기

네트워크에서 장치를 찾는 데 유용한 최고의 핑 스윕 도구 10가지

네트워크에서 장치를 찾는 데 유용한 최고의 핑 스윕 도구 10가지

빠른 LAN 검색, 플랫폼 간 스캔 및 IP 주소 관리를 위한 10가지 핑 스윕 도구를 비교해 보세요. 스윕을 통해 무엇을 알 수 있고 무엇을 알 수 없는지 알아보세요.

성능 추적을 위한 최고의 네트워크 관리 도구 6가지

성능 추적을 위한 최고의 네트워크 관리 도구 6가지

SNMP 적용 범위, 매핑, 알림, 배포 모델 및 비용 대비 효과를 포함하여 성능 모니터링을 위한 6가지 네트워크 관리 도구를 비교합니다.

Windows, iOS 및 Android용 최고의 Wi-Fi 분석기

Windows, iOS 및 Android용 최고의 Wi-Fi 분석기

Windows, iPhone, Android용 Wi-Fi 분석 앱들을 비교해 보세요. 채널 혼잡도, 신호 범위, 히트맵, 네트워크 문제 해결 도구 등을 포함합니다.

핑 모니터: 네트워크 가용성을 위한 7가지 무료 오픈소스 도구

핑 모니터: 네트워크 가용성을 위한 7가지 무료 오픈소스 도구

종합적인 네트워크 관리 도구부터 특정 지연 시간 측정에 특화된 도구까지, 7가지 무료 오픈 소스 핑 모니터링 도구를 비교하고 가용성, 패킷 손실률, 기록 관리에 적합한 도구를 선택하세요.

네트워킹에서의 QoS: 서비스 품질(QoS)이란 무엇이며 어떻게 작동하는가

네트워킹에서의 QoS: 서비스 품질(QoS)이란 무엇이며 어떻게 작동하는가

네트워킹에서 QoS가 무엇을 의미하는지, DSCP 마킹과 트래픽 큐가 음성, 비디오 및 비즈니스 애플리케이션의 우선순위를 어떻게 지정하는지, 그리고 QoS로 해결할 수 없는 문제는 무엇인지 알아보세요.

Nmap을 사용하여 트레이서루트를 실행하고 네트워크 경로를 읽는 방법

Nmap을 사용하여 트레이서루트를 실행하고 네트워크 경로를 읽는 방법

Nmap의 --traceroute 옵션을 사용하여 홉을 인증된 호스트로 매핑하고, 홉 및 RTT 출력을 이해하고, 과도한 스캔 없이 누락된 응답 문제를 해결할 수 있습니다.

안전한 파일 전송을 위한 최고의 SFTP 서버 소프트웨어

안전한 파일 전송을 위한 최고의 SFTP 서버 소프트웨어

Windows 및 Linux용 안정적인 SFTP 서버 소프트웨어(OpenSSH, Bitvise, SolarWinds, SFTPGo 등)를 비교해 보세요. 보안 및 파일 전송 요구 사항에 맞는 최적의 솔루션을 찾아보세요.

네트워크 팀을 위한 최고의 IP 주소 관리 도구 7가지

네트워크 팀을 위한 최고의 IP 주소 관리 도구 7가지

서브넷 검색, DNS 및 DHCP 조정, 네트워크 인벤토리, 오픈 소스 IPAM을 위한 7가지 IP 주소 관리 도구를 비교합니다.

네트워크 모니터링 모범 사례: 추적 대상 및 사용 도구

네트워크 모니터링 모범 사례: 추적 대상 및 사용 도구

SolarWinds NPM, PRTG 및 OpManager를 비교하여 명확한 장치 범위, 유용한 성능 지표, 실행 가능한 알림을 통해 실용적인 네트워크 모니터링 시스템을 구축하십시오.

기기 및 IP 주소 검색을 위한 최고의 네트워크 스캐너 도구 10가지

기기 및 IP 주소 검색을 위한 최고의 네트워크 스캐너 도구 10가지

빠른 장치 검색, 플랫폼 간 IP 스캔 및 엔터프라이즈 IPAM을 위한 네트워크 스캐너 도구를 비교하고, 각 옵션을 네트워크에 맞게 선택하는 방법에 대한 지침을 제공합니다.