Collabora CODE 문서를 저장 시 암호화로 보호하세요.

Collabora Online Development Edition(CODE)을 사용할 때 저장된 문서를 암호화하려면 CODE 편집기가 아닌 파일 저장 플랫폼 또는 기본 디스크에서 암호화를 활성화해야 합니다. Collabora는 WOPI 스토리지 호스트에서 제공하는 문서를 열며, 호스트는 저장된 사본을 보호할 책임이 있습니다. 결과적으로 암호화된 저장소, 작업 가능한 편집 내용, 그리고 복구 가능한 파일을 얻을 수 있습니다.

어떤 시스템이 실제로 파일을 저장하는지 확인하십시오.

일반적인 배포 환경에서는 파일 저장을 위해 Nextcloud 또는 WOPI 호환 서비스를 사용하고, 브라우저 기반 편집을 위해 CODE를 사용합니다. 문서는 승인된 편집 세션 동안 이러한 구성 요소 간에 이동합니다. HTTPS를 활성화하면 해당 연결은 보호되지만 저장된 사본은 암호화되지 않습니다. Collabora의 보안 개요에서는 스토리지가 통합 제어 방식으로 제공된다고 설명하고 있으며, 서버 구성 템플릿 에는 WOPI, TLS, 그리고 선택적인 캐시 및 격리 설정이 문서화되어 있습니다.

변경하기 전에 WOPI 호스트가 문서 파일을 저장하는 위치(로컬 디스크 사용 여부 또는 외부 객체 스토리지 사용 여부)와 CODE 자체가 실행되는 위치를 기록해 두십시오. 백업, 스냅샷, 미리 보기, 스왑 및 컨테이너 볼륨도 포함하십시오. 메인 디렉터리 외부에 있는 복사본은 보호되지 않은 상태로 유지될 수 있습니다.

위험 수준에 맞는 암호화 방식을 선택하세요.

Linux 서버의 로컬 디스크에 저장된 문서의 경우, LUKS와 같은 디스크 또는 볼륨 암호화가 일반적으로 가장 간편한 방법입니다. LUKS는 볼륨이 잠겨 있을 때 기본 저장 장치를 보호하며, 전원이 꺼진 드라이브의 도난으로부터도 데이터를 보호합니다. Ubuntu의 전체 디스크 암호화 관련 문서에서는 LUKS를 애플리케이션 설정이 아닌 블록 수준 암호화로 설명하고 있습니다. LUKS를 초기화하면 기존 데이터가 손실될 수 있으므로, 새롭게 암호화된 볼륨을 사용하거나 검증된 마이그레이션을 수행하는 것이 좋습니다.

Nextcloud가 타사 스토리지에 파일을 저장하고 스토리지 제공업체가 파일 내용을 읽어서는 안 되는 경우, Nextcloud 서버 측 암호화(SSE)가 더 적합할 수 있습니다. SSE는 지원되는 파일 내용을 백엔드 스토리지에 저장하기 전에 암호화합니다. 암호화 키는 Nextcloud에 보관되므로 서버 또는 관리자가 해킹당한 경우에도 복호화된 파일에 접근할 수 있습니다. Nextcloud는 로컬 스토리지의 경우 디스크 암호화를 고려할 것을 권장합니다.

애플리케이션 관리자조차 문서를 읽을 수 없어야 하는 경우, 디스크 잠금 해제 암호화나 일반 SSE는 해당 요구 사항을 충족하지 못합니다. 지원되는 클라이언트 측 또는 종단 간 암호화 워크플로를 평가하고 브라우저 편집 기능이 유지되는지 확인하십시오. 모든 암호화된 문서를 CODE에서 공동 작업으로 열 수 있다고 가정하지 마십시오.

스토리지 호스트에서 암호화를 활성화합니다.

옵션 A: 로컬 볼륨을 암호화합니다.

새로운 Linux 배포 환경에서는 문서를 가져오기 전에 파일 데이터와 관련 서비스 볼륨을 암호화된 스토리지에 프로비저닝하십시오. 잠금 해제 암호와 복구 정보는 서버 외부에 보관하고, 관리자 접근을 제한하며, 재부팅 또는 잠금 해제 절차를 테스트하십시오. 기존 시스템의 경우, 백업을 확인하고 시스템 다운타임 동안 마이그레이션하십시오. 클라우드 볼륨 또는 객체 스토리지에 대한 암호화는 공급업체와 협의하여 구성하십시오.

lsblk -f블록 장치 유형과 실제 데이터 디렉터리를 지원하는 파일 시스템을 식별하는 데 사용하십시오 findmnt -T /path/to/document/data. 데이터 디렉터리에서 암호화된 장치까지의 경로를 확인하십시오. 설치 cryptsetup만으로는 파일 시스템이 암호화되지 않습니다.

옵션 B: Nextcloud 서버 측 암호화 활성화

Nextcloud SSE를 사용해야 하는 경우, 해당 서버 측 암호화 가이드를 따르십시오 . 변경하기 전에 Nextcloud 구성, 데이터베이스, 파일 및 암호화 키를 백업하십시오. 콘텐츠를 암호화하기 전에 키 모드를 결정하십시오. 현재 가이드에서는 대부분의 배포 환경에서 서버 제어 마스터 키를 기본값으로 권장합니다.

1. Nextcloud 앱에서 기본 암호화 모듈을 활성화한 다음 관리 설정에서 서버 측 암호화를 활성화하거나 문서화된 occ명령어를 사용하십시오.
2. 일반적인 Linux 설치 환경에서는 Nextcloud 설치 디렉터리에서 웹 서버 계정으로 sudo -E -u www-data php occ app:enable encryption다음 명령어를 실행하십시오 sudo -E -u www-data php occ encryption:enable. 사용자 이름과 실행 방법은 사용 환경에 맞게 조정해야 합니다. Docker 배포 환경에서는 해당 컨테이너 내부에서 명령어를 사용합니다.
3. 기능을 실행하여 sudo -E -u www-data php occ encryption:status선택한 모듈을 확인하십시오. 활성화 표시가 나타났다고 해서 기존의 모든 파일이 암호화되었다는 의미로 해석해서는 안 됩니다.
4. 사용자 파일 접근이 불가능한 유지 관리 기간을 예약하고 sudo -E -u www-data php occ encryption:encrypt-all기존 파일을 처리하기 위해 실행하십시오. 이 작업은 시간이 걸릴 수 있으며, 공식 암호화 명령 참조 문서 에는 유지 관리 모드를 관리하고 대화형 터미널이 필요하다고 명시되어 있습니다.

SSE는 파일 이름, 폴더, 기존 휴지통 파일, 일부 이전 버전, 썸네일, 미리 보기, 검색 인덱스 및 특정 애플리케이션 데이터를 제외합니다. 필요한 경우 제외된 항목을 별도로 보호하십시오. 암호화 키 백업을 보호하십시오. 중요한 키 또는 인스턴스 암호를 분실하면 복구가 영구적으로 불가능해질 수 있습니다.

CODE 호스트를 보호하고 편집 경로를 안전하게 유지하세요.

WOPI 호스트가 저장된 문서를 암호화하는 경우에도 CODE 시스템을 별도로 평가해야 합니다. Collabora는 활성 문서 처리를 메모리 기반으로 설명하며 CODE를 영구 문서 저장소로 간주하지 않습니다. 그러나 게시된 coolwsd.xml템플릿에는 선택적 격리 및 캐시 파일 설정이 포함되어 있으므로 모든 임시 아티팩트가 존재하지 않는다고 가정하기보다는 실제 배포 환경을 검사해야 합니다. 컨테이너 런타임 저장소, 마운트된 볼륨, 시스템 스왑, 크래시 덤프 및 백업에 대해 적절한 암호화 또는 보존 제어를 적용하십시오.

브라우저, CODE 및 WOPI 서비스 간에는 HTTPS를 유지하고 연결할 수 있는 WOPI 호스트를 제한하십시오. Nextcloud의 Office 구성 문서에서는 WOPI 요청을 예상되는 Collabora 서버 IP 주소로 제한할 것을 권장합니다. 이러한 액세스 제어는 저장 데이터 암호화를 대체하는 것은 아니지만, 암호화된 저장 시스템이 권한이 없는 편집자에게 평문을 제공하는 것을 방지하는 데 도움이 됩니다.

Collabora의 로컬 파일 시스템 저장 모드를 프로덕션 환경에서 간편하게 사용하지 마십시오. 공식 SDK에서는 파일 시스템 저장을 테스트 전용 옵션으로 설명하고 있으며, WOPI 사용을 권장합니다. 권한 부여 및 저장 동작이 일관되게 유지되도록 기존 저장소 통합 방식을 그대로 유지하십시오.

결과가 충분히 좋은지 확인하세요

인수 테스트에는 민감하지 않은 샘플 파일을 사용하십시오. 해당 파일을 스토리지 서비스를 통해 업로드하고, CODE에서 열고, 한 줄을 편집한 후 저장하고, 편집기를 닫았다가 다시 여십시오. 이 왕복 과정이 성공적으로 완료되면 편집 기능이 정상적으로 작동하는 것으로 확인되지만, 저장 데이터 암호화가 보장되는 것은 아닙니다 .

• 저장소 검증: 실제 문서 디렉터리가 의도한 암호화 볼륨으로 확인되는지 또는 저장소 서비스가 예상되는 암호화 구성을 보고하는지 확인합니다. SSE의 경우, 제어된 테스트와 승인된 백엔드 액세스를 사용하여 백엔드에 저장된 데이터가 저장소 애플리케이션의 키 없이는 읽을 수 없는지 확인합니다.
• 기존 파일 검증: 마이그레이션이 encryption:encrypt-all성공적으로 완료되었는지 확인합니다. 새로 업로드된 파일만 테스트하지 마십시오.
• 보조 복사본: 백업, 스냅샷, 미리 보기 데이터, 로그 및 CODE 호스트 스토리지가 동일한 보호 요구 사항을 충족하는지 확인합니다.
• 복구 가능성: 별도의 테스트 환경에서 샘플과 필요한 키를 복원한 다음, CODE를 통해 문서가 열리고 저장되는지 확인합니다.

저장 장치 제공업체나 애플리케이션이 콘텐츠를 해독할 수 없어야 하거나, 보호 대상 데이터 범주가 암호화 경계 외부에 있거나, 키 복구가 입증될 수 없는 경우 암호화 방식을 변경해야 합니다. 저장 데이터 암호화는 주로 저장 장치 손실 및 무단 백엔드 읽기로 인한 노출을 제한하는 데 사용되지만, 손상된 운영 서버, 권한 있는 사용자의 파일 다운로드 또는 도용된 계정이 열려 있는 문서를 읽는 것을 완전히 막을 수는 없습니다.