Nextcloud에서 성능 저하 없이 서버 측 암호화를 활성화하는 방법

2026년 10월 현재, Nextcloud 35 안정화 버전 관리자 문서에서는 이전의 많은 튜토리얼보다 중요한 점을 명확히 설명하고 있습니다. 서버 측 암호화(SSE)는 주로 외부 타사 스토리지에 저장된 파일을 보호하기 위한 것이며, 기본 마스터 키 모드는 사용자별 키 모드보다 성능이 우수하고 인증 호환성이 더 넓다는 것입니다. 또한, 해당 문서에서는 암호화된 파일로 인해 발생하는 스토리지 오버헤드가 이제 약 1%에 불과하며, Nextcloud 25 이전 버전에서는 훨씬 더 컸던 것과 비교된다고 언급하고 있습니다.

그렇다고 암호화가 말 그대로 무료라는 의미는 아닙니다. 모든 암호화된 읽기 및 쓰기 작업에는 암호화 작업이 필요하므로, 어떤 책임 있는 가이드도 모든 서버에서 CPU 사용률이나 지연 시간이 전혀 발생하지 않는다고 보장할 수는 없습니다. 실질적인 목표는 다릅니다. 사용자에게 눈에 띄는 속도 저하를 유발하지 않고, 데이터베이스 및 잠금 부하를 제어하며, 실제로 필요한 저장소만 암호화하는 방식으로 암호화를 활성화하는 것입니다.

Nextcloud 서버 측 암호화가 보호하는 내용

Nextcloud SSE는 파일 내용을 서버에 저장하기 전에 암호화합니다. 사용자가 Nextcloud를 통해 파일을 다운로드하거나 열면 서버는 해당 파일을 복호화한 후 승인된 사용자에게 전달합니다. 암호화 키는 Nextcloud 서버에 보관되므로, 실제 파일 데이터가 완전히 신뢰할 수 없는 외부 저장소에 있는 경우 SSE가 특히 유용합니다.

SSE는 파일 이름이나 디렉터리 구조를 숨기지 않으며, 악의적인 Nextcloud 관리자나 완전히 손상된 애플리케이션 서버로부터 파일을 보호하지도 않습니다. 서버 관리자조차 파일을 읽을 수 없어야 하는 경우, Nextcloud의 종단 간 암호화 모델이 적절한 보안 계층입니다. 자세한 비교 내용은 Nextcloud 서버 측 암호화 문서를 참조하십시오 .

불필요한 작업을 최소화하는 구성을 선택하십시오.

1단계: 인스턴스를 백업하고 성능 기준선을 설정합니다.

암호화 키와 인스턴스 시크릿은 복구에 필수적인 자료입니다. Nextcloud는 SSE를 활성화하기 전에 인스턴스 구성과 암호화 키를 백업할 것을 명시적으로 권장합니다. 필수 키 또는 인스턴스 시크릿을 분실하면 암호화된 데이터를 복구할 수 없게 될 수 있습니다.

변경 전에 사용자에게 중요한 작업 부하를 사용하여 간단한 기준선을 설정하세요. 대표적인 업로드 및 다운로드 작업을 몇 차례 측정하고 PHP-FPM CPU 사용률, 데이터베이스 부하, 스토리지 지연 시간, 파일 앱의 응답 시간을 기록합니다. 실험실 수준의 벤치마크가 필요한 것이 아닙니다. 배포 후 사용자에게 보이는 동작 변화가 있는지 확인할 수 있는 반복 가능한 사전-사후 테스트가 필요합니다.

또한 홈 스토리지를 실제로 암호화해야 하는지 여부를 결정하십시오. S3, SMB, 객체 스토리지 또는 기타 외부 백엔드를 스토리지 공급자로부터 보호하는 것이 목표라면 로컬 홈 스토리지를 SSE 외부에 유지함으로써 해당 위협 모델에 대해 추가적인 가치를 제공하지 않는 암호화 작업을 피할 수 있습니다.

2단계: 암호화를 활성화하기 전에 캐싱 및 파일 잠금 문제를 해결하십시오.

이는 성능을 위한 가장 중요한 준비 단계입니다. Nextcloud는 최적의 성능을 위해 메모리 캐싱을 권장하며, 특히 로컬 캐싱에는 APCu를, 트랜잭션 파일 잠금에는 Redis 또는 호환 가능한 백엔드를 사용할 것을 권장합니다. 트랜잭션 파일 잠금은 암호화된 파일의 경우 특히 중요합니다. Nextcloud는 암호화 및 저장 작업이 진행되는 동안 파일 변경 사항을 안전하게 처리해야 하기 때문입니다.

일반적인 단일 서버 구성에서는 로컬 캐시에 APCu를, 잠금에는 Redis를 사용합니다.

'memcache.local' => '\OC\Memcache\APCu',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
    'host' => '127.0.0.1',
    'port' => 6379,
    'dbindex' => 0,
],

Redis가 동일 호스트에서 실행되는 경우, Nextcloud의 파일 잠금 관련 문서에서는 가능한 경우 Unix 소켓 사용을 권장합니다. 최신 Nextcloud 35 문서에서는 Redis 또는 Valkey 호환 서버에 대해 번들로 제공되는 KeyValueCache 옵션도 설명하고 있으며, 이 옵션을 사용하면 phpredis PHP 확장 프로그램 없이도 트랜잭션 잠금을 제공할 수 있습니다. 샘플 설정을 그대로 복사하기보다는 배포 환경에 맞는 구성을 사용하십시오.

PHP OPcache도 활성화하고 컴파일된 코드가 반복적으로 제거되지 않도록 크기를 조정해야 합니다. Nextcloud 서버 튜닝 가이드에 따르면 OPcache는 PHP 애플리케이션 성능을 향상시키고 설정된 사용률이 90%를 초과할 경우 관리자에게 경고합니다. 배포 전에 공식 메모리 캐싱 가이드 , 트랜잭션 파일 잠금 가이드 및 서버 튜닝 가이드를 검토하십시오.

3단계: 기본 암호화 모듈을 활성화하고 마스터 키 모드를 사용합니다.

대부분의 최신 배포 환경에서는 마스터 키 모드가 최적의 시작점입니다. Nextcloud 35는 이를 기본값으로 명시하고 대부분의 배포 환경에 권장하며, 더 나은 성능과 다양한 로그인 방식과의 호환성을 제공한다고 설명합니다. 하지만 분명한 단점이 있습니다. 서버를 제어하는 ​​관리자는 사용자 파일을 해독할 수 있다는 것입니다. 만약 이러한 보안 취약점이 용납될 수 없다면, 마스터 키를 사용하는 SSE는 적절한 보안 방식이 아닙니다.

웹 인터페이스에서 관리자 설정의 서버 측 암호화 섹션을 열고 서버 측 암호화를 활성화한 다음, Nextcloud에서 암호화 모듈이 로드되지 않았다고 표시되면 앱에서 Nextcloud 기본 암호화 모듈을 활성화합니다. 암호화 설정으로 돌아가서 모듈이 선택되었는지 확인합니다. 로그아웃 후 다시 로그인하여 암호화 키를 초기화합니다.

암호화를 관리하려면 다음 명령어를 사용할 수도 있습니다 occ. 현재 명령어 참조 문서에는 다음 순서가 나와 있습니다.

sudo -E -u www-data php occ app:enable encryption
sudo -E -u www-data php occ encryption:enable
sudo -E -u www-data php occ encryption:status

SSE의 목적이 외부 저장소에만 국한된다면, 광범위한 배포를 진행하기 전에 홈 저장소 암호화 옵션을 해제하십시오. 이 옵션을 선택하면 암호화 계층을 통과해야 하는 데이터 양을 크게 줄일 수 있습니다.

4단계: 의도한 외부 마운트를 암호화하고 실제 트래픽으로 검증합니다.

외부 저장소 암호화는 마운트별로 구성됩니다. 필요한 마운트에만 암호화를 활성화한 다음 Nextcloud를 통해 대표 파일을 업로드하고 다시 다운로드하십시오. 사용자가 실제로 사용하는 데스크톱, 모바일, WebDAV 또는 브라우저 워크플로를 통해 액세스를 확인할 수 있습니다.

기능 테스트 후 1단계에서 수행한 기준 측정 작업을 반복합니다. 업로드 시간, 다운로드 시간, CPU 사용률, 데이터베이스 활동 및 스토리지 지연 시간을 비교합니다. 변화가 미미하고 사용자에게 체감되는 응답 시간이 안정적이라면 서버에 충분한 여유 공간이 있는 것입니다. 성능이 급격히 저하되는 경우 암호화 자체만을 원인으로 단정하지 마십시오. 데이터베이스 기반 파일 잠금, PHP-FPM 워커 과부하, 느린 외부 스토리지, OPcache 부족 또는 Redis 연결 문제 등을 먼저 확인하십시오.

SSE가 활성화되기 전에 이미 존재했던 파일을 암호화해야 하는 경우 Nextcloud는 OCC 암호화 기능을 제공합니다 encryption:encrypt-all. 이 작업은 일반적인 대화형 요청이 아닌 마이그레이션 작업으로 간주해야 합니다. 대량의 데이터를 처리할 수 있으므로 유지 관리 기간에 작업을 예약하고 백업 및 롤백 계획을 철저히 수립해야 합니다. 사용 가능한 암호화 명령은 공식 OCC 암호화 참조 문서 에 설명되어 있습니다 .

출시가 성공적으로 진행되고 있는지 어떻게 알 수 있을까요?

• 사용자는 업로드 또는 다운로드 시간의 의미 있는 증가를 느끼지 못합니다. 변경 전후의 동일한 파일 크기와 클라이언트를 비교해 보세요.
• 데이터베이스 부하가 안정적으로 유지되고 있습니다. 데이터베이스 활동이 급격히 증가하는 것은 파일 잠금이 Redis 또는 Valkey 대신 데이터베이스를 계속 사용하고 있음을 나타낼 수 있습니다.
• PHP 워커는 CPU 부족 현상을 겪고 있지 않습니다. 암호화 작업은 CPU 작업량을 증가시키므로, 이미 용량 한계에 가까운 상태로 실행 중인 인스턴스는 더 많은 여유 공간이 필요합니다.
• 외부 스토리지 지연 시간은 여전히 ​​적절한 경우 가장 중요한 요소입니다. 속도가 느린 S3, SMB 또는 원격 객체 스토리지는 암호화 비용보다 훨씬 더 큰 손실을 초래할 수 있습니다.
• 관리자 개요 또는 로그에 암호화 또는 키 관련 경고가 표시되지 않습니다. 배포를 확대하기 전에 경고를 해결하십시오.

피할 수 있는 속도 저하를 유발하는 일반적인 실수

외부 저장 장치만 보호하면 될 때 로컬 홈 저장 장치를 암호화합니다.

이는 실제 위협에 대응하지 않고 암호화된 I/O 양만 증가시킬 뿐입니다. SSE를 활성화하는 이유에 맞춰 암호화 범위를 설정하십시오.

데이터베이스에 트랜잭션 잠금을 남겨두는 것

Nextcloud 문서에 따르면 기본 데이터베이스 잠금 백엔드는 데이터베이스에 상당한 부하를 발생시킵니다. Redis 또는 Valkey 기반의 잠금 캐시는 이러한 병목 현상을 제거하는 가장 직접적인 방법 중 하나입니다.

피크 시간대에 대량 암호화 실행

대화형 트래픽과 전체 데이터 암호화 과정은 CPU, I/O, PHP 워커 및 스토리지 대역폭을 놓고 경쟁합니다. 마이그레이션 작업은 일반 프로덕션 트래픽과 분리해야 합니다.

SSE를 손상된 Nextcloud 서버로부터 보호하는 수단으로 간주

SSE 키는 서버에서 사용할 수 있으므로 악의적인 관리자나 완전히 손상된 서버도 신뢰 경계 내에 남아 있을 수 있습니다. 종단 간 암호화가 필요한 위협에 대해서는 종단 간 암호화를 사용하십시오.

결론적으로

성능 저하 없이 Nextcloud 서버 측 암호화를 활성화하는 가장 안전한 방법은 범위를 좁히고, 신뢰 모델이 적합한 경우 기본 마스터 키를 사용하고, APCu 및 Redis 또는 Valkey 잠금을 먼저 구성한 다음, 변경 전후의 실제 워크로드를 벤치마킹하는 것입니다. 현재 Nextcloud 35 가이드라인은 이러한 접근 방식을 지원합니다. 마스터 키 모드는 성능 친화적인 기본값이며, 외부 스토리지가 주요 SSE 사용 사례이고, 암호화된 파일 크기 오버헤드는 현재 약 1%입니다.

Nextcloud 35 공식 서버 측 암호화 가이드 와 서버 측 암호화 기술 세부 정보 부터 시작하십시오 . 해당 문서는 키 관리 동작, 마이그레이션 명령 및 버전별 제한 사항에 대한 가장 정확한 정보 출처입니다.