Nextcloud 보안을 강화하여 A+ 등급의 보안 헤더를 획득하는 방법

보안 헤더 스캐너에서 A+ 등급을 받는 것은 유용한 구성 목표가 될 수 있지만, Nextcloud 서버의 완벽한 보안 인증을 의미하는 것은 아닙니다. 이 등급은 특정 스캐너가 테스트한 URL에서 확인하는 HTTP 응답 헤더를 반영합니다. 데이터베이스, 운영 체제, 백업, 사용자 계정, 설치된 애플리케이션 또는 패치 프로세스는 검사하지 않습니다. 따라서 안전한 보안 강화 계획은 Nextcloud 자체 상태 점검부터 시작하여 서버와 공개 웹 계층을 보호하고 마지막으로 정확한 공개 URL을 다시 테스트하는 순서로 진행해야 합니다.

이 가이드는 2026년 10월 기준으로 제공되는 Nextcloud 35 관리 설명서를 따릅니다. 구성 예시는 Apache, NGINX, 컨테이너 및 리버스 프록시 배포 환경에 따라 다를 수 있습니다. 변경 사항을 적용하기 전에 서버 버전 및 배포 환경에 맞는 설명서를 참조하여 모든 변경 사항을 확인하십시오.

빠른 체크리스트

• 변경 또는 업그레이드를 진행하기 전에 데이터베이스, 데이터 디렉터리 및 구성을 백업하십시오.
• 지원되는 Nextcloud, PHP, 데이터베이스, 운영 체제 및 앱 업데이트를 설치합니다.
• 모든 공용 연결에 HTTPS를 사용하고 HTTP를 HTTPS로 리디렉션하십시오.
• 해당 도메인 및 영향을 받는 모든 하위 도메인에서 HTTPS가 정상적으로 작동한 후에만 HSTS를 활성화하십시오.
• 가능하면 데이터 디렉터리와 민감한 설정 정보는 웹 루트 외부에 보관하십시오.
• 관리자와 필요한 경우 모든 사용자에게 다단계 인증(MFA)을 사용하십시오.
• 신뢰할 수 있는 프록시를 엄격하게 구성하십시오. 임의로 전달된 클라이언트 IP 헤더는 절대 신뢰하지 마십시오.
• Nextcloud 관리 개요 경고를 해결하고 공개 엔드포인트에서 헤더를 테스트합니다.

1. 안전한 기준선을 설정하십시오

헤더 또는 PHP 설정을 변경하기 전에 요청이 Nextcloud에 도달하는 경로(Apache 또는 NGINX를 직접 경유하는지, 컨테이너 프록시를 경유하는지, 관리형 로드 밸런서를 경유하는지)를 확인하십시오. Nextcloud 버전, PHP 버전, 데이터베이스 유형, 활성화된 애플리케이션 및 TLS 종료 지점을 기록해 두십시오. 변경 사항이 잘못될 경우 되돌릴 수 있도록 현재 활성화된 가상 호스트 또는 프록시 구성의 사본을 보관하십시오.

데이터베이스, 전체 데이터 디렉터리 및 Nextcloud 구성(파일 포함)을 복원 가능한 백업으로 만드십시오 config.php. 파일 복사만으로는 완전한 백업이 아닙니다. 세 가지 구성 요소를 모두 함께 복원하는 방법을 알고 있는지 확인하십시오. Nextcloud 업데이트 문서에는 업데이트 프로그램이 데이터베이스나 데이터 디렉터리를 백업하지 않는다는 내용이 명시적으로 경고되어 있습니다. Nextcloud 업그레이드 및 백업 지침을 참조하십시오 .

관리자 계정으로 로그인한 다음 관리 설정에서 개요를 엽니다. 보안 및 설정 경고, 백그라운드 작업 및 데이터베이스 경고를 검토하십시오. 깨끗한 개요는 유용한 애플리케이션 수준 검사이지만 운영 체제 패치 또는 외부 헤더 테스트를 대체하지는 않습니다. 경고의 원인을 파악하기 전까지는 경고를 숨기지 마십시오.

2. Nextcloud 및 호스트에 패치를 적용합니다.

지원되는 PHP 및 데이터베이스 조합으로 지원되는 Nextcloud 릴리스를 실행하십시오. 유지 관리 릴리스는 즉시 적용하고, 새로운 주요 릴리스로 이동하기 전에 앱 호환성을 검토하십시오. 운영 체제, 웹 서버, PHP 런타임, 데이터베이스 서버 및 설치된 Nextcloud 앱은 지원되는 업데이트 채널을 통해 업데이트하십시오. 사용하지 않거나 더 이상 유지 관리되지 않는 앱은 제거하십시오. 활성화된 각 구성 요소는 코드와 유지 관리 작업을 추가합니다.

업데이트하기 전에 백업을 확인하고 대상 버전의 릴리스 노트를 읽으십시오. 설치 유형에 맞는 지원되는 업데이트 프로그램을 사용한 다음 필요한 데이터베이스 마이그레이션을 완료하고 관리 개요 및 로그를 확인하십시오. 이전 애플리케이션 파일을 마이그레이션된 인스턴스에 복사하여 다운그레이드하지 마십시오. Nextcloud 문서에서는 다운그레이드를 지원하지 않으며 롤백이 필요한 경우 호환되는 백업에서 복원할 것을 권장합니다.

3. 자격 증명 및 계정을 보호하세요

MFA를 사용하여 관리자 노출 위험을 줄이세요.

유지 관리되는 2단계 인증 공급자를 활성화하고 관리자 계정에 MFA(다단계 인증)를 요구하십시오. Nextcloud의 2단계 인증은 앱을 통해 제공되므로, 선택한 공급자가 사용 중인 릴리스와 호환되는지, 그리고 사용자가 복구 경로를 확보했는지 확인한 후 적용하십시오. 비상 복구 코드는 오프라인에 안전하게 보관하십시오. 로그인 지연 문제를 해결하기 위해 무차별 대입 공격 방지 기능을 비활성화하지 마십시오. 대신 공격자의 IP 주소와 프록시 구성을 조사하십시오.

일상적인 작업에는 개별 관리자 계정을 사용하고 필요한 경우에만 관리자 권한을 부여하십시오. 고유하고 긴 암호를 선택하고 암호 관리자를 사용하십시오. 분실한 기기의 세션과 앱 암호는 즉시 취소하십시오. 계정, 그룹, 공용 공유 폴더 및 외부 저장소를 정기적으로 검토하여 더 이상 업무상 필요하지 않은 접근 권한은 제거하십시오.

무차별 대입 공격 방지 기능을 효과적으로 유지하세요

Nextcloud의 무차별 대입 공격 방지 기능은 기본적으로 활성화되어 있습니다. 이 기능의 효과는 서버가 실제 클라이언트 IP 주소를 인식하는 데 달려 있습니다. Nextcloud가 프록시 뒤에 있는 경우, 설정 파일에는 실제 프록시 주소 또는 네트워크만 구성하고 trusted_proxies, forwarded_for_headers헤더는 프록시에서 제어하는 ​​주소로만 설정하십시오. 클라이언트가 위조할 수 있는 헤더를 신뢰하면 IP 기반 보호 기능이 약화될 수 있습니다. 광범위한 화이트리스트 항목은 피하십시오. 제외된 주소는 제한 없이 인증 시도를 할 수 있습니다. 무차별 대입 공격 방지 문서 와 리버스 프록시 구성 가이드를 참조하십시오 .

4. 파일 및 서버 구성으로 인한 노출을 줄입니다.

Nextcloud 데이터 디렉터리를 웹 루트 외부에 배치하여 웹 서버 오류로 인해 저장된 파일이 노출될 가능성을 줄이십시오. 파일 시스템 소유권과 권한은 서비스 계정과 접근이 필요한 관리자로 제한하고, 디렉터리에 모든 사용자가 읽기 또는 쓰기 권한을 갖도록 설정하지 마십시오. config.php데이터베이스 자격 증명과 인스턴스 비밀 키가 포함된 디렉터리를 보호하십시오. Nextcloud 35 보안 강화 가이드에는 구성 디렉터리를 웹 루트 외부로 이동하는 방법도 설명되어 있습니다 NEXTCLOUD_CONFIG_DIR. 웹 프로세스와 명령줄 작업 모두에 대해 이 설정을 일관되게 적용한 다음, 인스턴스가 의도한 구성을 제대로 로드하는지 확인하십시오.

프로덕션 디버그 모드는 비활성화 상태로 유지하십시오. 팀에서 지원하고 이해할 수 있는 경우 SELinux와 같은 운영 체제 보안 강화 기능을 활성화하십시오. 컨테이너에서 실행하는 경우 호스트, 영구 볼륨, 컨테이너 레지스트리 자격 증명 및 관리 인터페이스는 물론 Nextcloud 애플리케이션도 보호하십시오. 공개해야 하는 서비스에 대한 인바운드 네트워크 액세스를 제한하십시오. 데이터베이스 포트나 관리 셸을 인터넷에 노출하지 마십시오.

Nextcloud는 다른 시스템으로의 아웃바운드 연결을 지원하는 기능을 제공하므로 네트워크 분할 및 방화벽 정책이 중요합니다. 인스턴스를 적절하게 제한된 네트워크 영역에 배치하고 활성화된 기능에 필요한 아웃바운드 대상만 허용하십시오. 정확한 허용 목록은 애플리케이션 및 배포 방식에 따라 달라집니다.

5. HTTPS 및 HSTS를 신중하게 구성하십시오.

유효한 TLS 인증서로 사이트를 제공하고 모든 일반 HTTP 요청을 HTTPS로 리디렉션하십시오. 인증서 체인, 갱신 프로세스 및 사용자가 실제로 액세스하는 모든 호스트 이름을 테스트하십시오. Nextcloud 보안 강화 가이드에서는 HTTPS 사용을 권장하며 HSTS에 대해 설명합니다. HSTS는 브라우저가 정책을 수신한 후 일정 기간 동안 HTTPS를 계속 사용하도록 지시하므로 HTTPS가 안정적으로 작동하는 경우에만 활성화하십시오.

환경에 적합한 HSTS 정책(예: )부터 시작하여 Strict-Transport-Security: max-age=15552000모니터링 후 기간을 늘리십시오. includeSubDomains영향을 받는 모든 하위 도메인이 HTTPS를 지원하는 경우에만 추가하십시오. 이 작업은 preload별도의 중요한 결정으로 간주해야 합니다. 브라우저는 미리 로드된 도메인을 오랫동안 유지할 수 있으며, 제거 후에도 사용자에게 반영되는 데 몇 달이 걸릴 수 있습니다. 모든 하위 도메인과 현재 요구 사항을 확인하지 않고 미리 로드된 예제를 복사하지 마십시오. TLS 옵션은 서버 및 클라이언트 요구 사항에 따라 다릅니다. Nextcloud에서 제공하는 TLS 가이드를 참조하여 결과 엔드포인트를 테스트하십시오.

6. 응답 헤더를 올바른 계층에 설정합니다.

X-Content-Type-OptionsNextcloud는 이미 `<security-container>`, ` X-Frame-Options<security-container> X-Robots-Tag`, `<security-container> `를 포함한 여러 보안 헤더를 제공합니다 Referrer-Policy. Nextcloud 문서에서는 웹 서버에서도 보안 관련 헤더를 제공하여 정적 응답에도 적용되도록 하는 것을 권장합니다. Apache 환경에서는 관련 모듈과 Nextcloud의 .htaccess보안 규칙이 활성화되어 있는지 확인해야 합니다. NGINX 환경에서는 Apache 규칙이 적용된다고 가정하지 말고 최신 Nextcloud NGINX 구성을 사용해야 합니다. 자세한 내용은 Nextcloud 보안 강화 가이드 및 NGINX 구성 문서를 참조하십시오 .

Nextcloud, 웹 서버, CDN 또는 리버스 프록시에 동일한 헤더를 설정하는 것은 혼란스러운 결과를 초래하는 일반적인 원인입니다. 이로 인해 응답에 중복되거나 충돌하는 값이 포함될 수 있습니다. 각 헤더를 담당하는 계층을 선택하고, 브라우저에서 보이는 최종 응답을 확인하며, Nextcloud의 콘텐츠 보안 정책(CSP)을 다른 사이트에서 복사한 일반 정책으로 대체하지 않도록 주의해야 합니다. 엄격한 CSP는 Nextcloud 및 해당 애플리케이션에 필요한 스크립트나 기능을 손상시킬 수 있습니다. 프로덕션 환경에 배포하기 전에 스테이징 호스트에서 정책 변경 사항을 테스트하고 브라우저 오류를 검사하십시오.

스캐너가 의도한 결과를 보고하려면 사용자가 방문하는 최종 HTTPS URL(리디렉션 및 CDN 또는 프록시 홉 포함)을 테스트해야 합니다. 랜딩 페이지와 정적 자산 모두를 확인하세요. 각 계층에서 다른 헤더가 반환될 수 있기 때문입니다. HTTP가 HTTPS로 리디렉션되는지, 그리고 최종 응답에 각 헤더에 대해 일관된 값이 포함되어 있는지 확인하십시오. curl -I https://your-cloud.example빠른 확인 용도로 사용한 다음, 실제 공개 응답을 확인하려면 브라우저 개발자 도구 또는 외부 스캐너를 사용하십시오. 예시 호스트 이름은 실제 호스트 이름으로 바꿔야 합니다. 스캔 보고서에 개인 호스트 이름이나 자격 증명을 공개하지 마십시오.

7. 성적을 보안으로 오인하지 말고 결과를 검증하십시오.

SecurityHeaders.com에서 제공하는 공개 HTTPS URL에 대한 테스트를 실행하고 , 등급뿐만 아니라 모든 결과를 꼼꼼히 읽어보세요. FAQ에 따르면 등급은 해당 서비스에서 검사하는 보안 관련 응답 헤더에 대한 평가입니다. 따라서 A+는 테스트된 응답이 해당 서비스의 현재 채점 기준을 충족했다는 의미이며, Nextcloud에 취약점이 없거나 서버 전체가 침투 테스트를 통과했다는 것을 의미하지는 않습니다. 스캐너마다 동일한 구성에 대한 등급이 다를 수 있으며, 채점 기준은 변경될 수 있습니다.

결과가 A+ 미만인 경우, 누락되었거나 충돌하는 헤더를 정확히 파악하고, 해당 헤더를 설정해야 하는 계층을 결정한 후, 한 번에 한 항목씩 변경하십시오. 각 변경 후에는 로그인, 파일 업로드 및 다운로드, 데스크톱 및 모바일 동기화, WebDAV, 공유 기능, 그리고 모든 중요 애플리케이션이 제대로 작동하는지 다시 테스트하십시오. 동작에 문제가 발생하면 마지막 헤더 변경 사항을 되돌리고 서버 및 브라우저 로그를 검사하십시오. 애플리케이션의 문서화된 요구 사항을 확인하지 않고 단순히 높은 점수를 받기 위해 포괄적인 콘텐츠 보안 정책을 추가해서는 안 됩니다.

최종 경화 검토

• 최근 백업에서 데이터베이스, 데이터 디렉터리 및 구성을 복원할 수 있습니까?
• Nextcloud 호스트, PHP, 데이터베이스, 웹 서버 및 활성화된 앱이 지원되는 업데이트 채널에 포함되어 있습니까?
• 모든 공용 호스트 이름이 HTTPS를 사용하고, HSTS는 준비된 도메인에만 적용되는 것인가요?
• 데이터 및 구성 파일은 접근 권한이 제한되어 있어 누구나 접근할 수 없도록 되어 있습니까?
• 관리자 계정은 다단계 인증(MFA)을 사용하나요? 그리고 만료된 계정, 세션 및 앱 암호는 삭제되나요?
• Nextcloud는 신뢰도가 낮은 프록시 설정을 통해 실제 클라이언트 IP를 확인할 수 있습니까?
• 관리자 개요에 표시된 경고를 이해하고 필요한 경우 해결했습니까?
• 외부 헤더 테스트에서 최종 공개 응답에 대해 일관된 결과가 나타나는지, 그리고 일반적인 Nextcloud 워크플로가 여전히 작동하는지 궁금합니다.

버전별 단계는 Nextcloud 35 보안 강화 지침 , 업그레이드 가이드 , 그리고 웹 서버 또는 호스팅 플랫폼 설명서를 참조하십시오. 가장 중요한 결과는 단순히 등급을 매기는 것이 아니라, 보안 변경 후에도 서버가 최신 상태를 유지하고, 복구 가능하며, 취약점 노출을 최소화하고, 정상적으로 작동하는 것입니다.