암호화 키는 어느 백업 계층에서 관리해야 할까요? 클라이언트, 리포지토리, 아니면 오프사이트 대상?

대부분의 홈 서버 백업에서는 백업을 읽는 데 필요한 암호화를 백업 애플리케이션 또는 클라이언트가 제어하고, 오프사이트 스토리지 공급자의 암호화는 추가 계층으로 취급해야 합니다. 이렇게 하면 클라우드 또는 원격 스토리지가 손상되어도 백업 콘텐츠가 자동으로 노출되지 않으며, 중복 제거, 검증 및 효율적인 데이터 복원을 계속 지원하는 백업 형식을 유지할 수 있습니다.

중요한 구분은 단순히 “클라이언트 측 암호화와 서버 측 암호화”가 아닙니다. 복호화 비밀 정보를 어느 장애 도메인이 소유하는지 결정해야 합니다. 유일한 키가 소스 서버에만 있다면, 소스 서버가 고장 나거나 랜섬웨어로 암호화될 때 복구 가능성이 사라질 수 있습니다. 오프사이트 대상이 유일하게 의미 있는 키를 소유한다면, 대상 운영자 또는 손상된 대상 계정이 여전히 신뢰 경계 안에 있을 수 있습니다. 최상의 설계는 백업 데이터, 리포지토리 자격 증명 및 복구 키를 분리합니다.

암호화가 적용될 수 있는 위치는 세 가지입니다

“암호화된 백업”이라는 표현에는 여러 아키텍처가 숨겨져 있습니다. 백업 도구가 소스 파일을 보기 전에 파일을 암호화할 수 있습니다. 백업 도구가 로컬 또는 원격 스토리지로 객체를 전송하기 전에 자체 리포지토리 형식을 암호화할 수도 있습니다. 또는 대상 스토리지 시스템이 데이터를 수신한 후 자체 키 관리 계층을 사용해 저장 데이터를 암호화할 수 있습니다.

리포지토리 수준 암호화는 일반적으로 가장 좋은 기본 설정입니다

최신 백업 도구는 리포지토리 형식의 일부로 데이터를 암호화하도록 설계되었습니다. Restic의 암호화 문서는 암호화를 리포지토리의 핵심 기능으로 다루며 여러 액세스 키와 비밀번호를 지원합니다. Kopia 역시 파일 시스템, S3, 클라우드 객체 스토리지와 같은 스토리지 백엔드 위에 리포지토리를 구성하고 암호화 및 중복 제거 기능을 추가한다고 설명합니다.

Borg는 신뢰 모델을 특히 명확하게 보여 줍니다. 보안 문서에서는 클라이언트 환경은 신뢰할 수 있지만 리포지토리는 적대적일 수 있다고 가정합니다. Borg는 로컬에서 암호화하므로 원격 리포지토리에 평문 파일이나 암호화되지 않은 백업 키가 전달되지 않습니다.

이 방식은 백업 애플리케이션이 백업을 생성하는 동안에도 원본 파일을 계속 볼 수 있기 때문에 홈 NAS에 적합합니다. 암호화 전이나 암호화와 동시에 청크 분할, 중복 제거, 압축, 스냅샷 메타데이터 처리, 검증, 선택적 복원을 수행할 수 있습니다. 스토리지 대상에는 일반적으로 읽을 수 있는 파일 대신 암호화된 리포지토리 객체가 저장됩니다.

리포지토리 키와 스토리지 자격 증명을 혼동하지 마세요

클라우드 버킷 액세스 키, SFTP 개인 키, 원격 NAS 비밀번호, 백업 복호화 키는 자동화 스크립트에 모두 필요하더라도 서로 다른 시크릿입니다. 스토리지 자격 증명은 “이 클라이언트가 리포지토리 객체를 읽거나 쓸 수 있는가?”를 결정합니다. 리포지토리 키는 “이 객체를 백업 데이터로 복호화할 수 있는가?”를 결정합니다.

사고가 발생했을 때는 이 둘을 분리하는 것이 중요합니다. 쓰기 권한이 있는 버킷 자격 증명을 탈취한 공격자가 자동으로 리포지토리 복호화 시크릿까지 얻어서는 안 됩니다. 반대로 백업 암호를 알고 있다고 해서 오프사이트 스토리지 계정에 대한 관리자 액세스 권한까지 반드시 얻을 수 있어서는 안 됩니다.

암호화된 복원에 필요한 모든 키 확인에 관한 ZimaSpace 가이드는 저장소 리포지토리 액세스, 백업 암호화, 대상 스토리지, 컨테이너 시크릿, 애플리케이션 수준 시크릿을 서로 별개의 복구 종속 항목으로 정리하므로 유용한 참고 자료입니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

좁은 고감도 데이터에는 클라이언트 측 사전 암호화가 최선입니다

백업 애플리케이션이 파일을 읽기 전에 파일을 암호화하면 특정 데이터셋을 일반적인 백업 도구나 관리자에게도 불투명하게 유지해야 할 때 유용할 수 있습니다. 예를 들면 소규모 법률 문서 보관소, 내보낸 비밀번호 데이터베이스, 개인 키 번들 또는 클라이언트가 관리하는 암호화 컨테이너가 있습니다.

단점은 암호화를 너무 일찍 수행하면 백업 시스템이 원래 활용할 수 있었던 구조가 가려질 수 있다는 점입니다. 변경된 모든 파일이 완전히 다른 암호화 출력이 되면 압축과 중복 제거의 효율이 떨어질 수 있습니다. 세밀한 파일 탐색도 암호화된 객체를 먼저 복원한 다음 다른 도구로 잠금을 해제해야 하는 2단계 복원이 될 수 있습니다.

따라서 전체 데이터셋을 미리 암호화하는 방식은 일반적으로 인증된 저장소 암호화를 기본 제공하는 백업 도구를 사용하는 것보다 기본 홈 백업 아키텍처로서 취약합니다. 데이터 일부에 두 번째 신뢰 경계를 의도적으로 설정해야 할 때 사용하세요.

오프사이트 서버 측 암호화는 스토리지를 보호하지만 전체 백업 신뢰 모델을 보호하지는 않습니다

클라우드 객체 스토리지는 일반적으로 저장 데이터를 암호화합니다. 예를 들어 Amazon S3는 기본적으로 서버 측 암호화를 적용하고 AWS 관리형 또는 고객 관리형 KMS 키를 지원합니다. SSE-KMS 문서에서는 S3가 대상에서 암호화를 수행하고 AWS KMS가 키와 권한을 제어하는 방식을 설명합니다.

Backblaze B2 역시 공급자 관리형 SSE-B2와 고객 관리형 SSE-C를 지원합니다. 서버 측 암호화 문서에는 SSE가 저장된 파일 데이터를 보호하며, 고객 관리형 SSE-C 키를 잃으면 데이터를 복구할 수 없다고 설명되어 있습니다.

서버 측 암호화는 유용합니다. 물리적 미디어와 스토리지 인프라를 보호하는 데 도움이 되며, 고객 관리형 KMS 정책은 강력한 조직 통제 수단을 만들 수 있습니다. 하지만 대상 서비스가 권한이 부여된 스토리지 요청이 들어올 때마다 데이터를 복호화할 수 있다면, 해당 대상은 여전히 기밀성 경계 안에 있습니다. 이는 공급자에 도달하기 전에 이미 암호화된 Borg, restic 또는 Kopia 저장소를 업로드하는 것과는 다릅니다.

심층 방어를 위해 오프사이트 암호화 사용

실용적인 답은 대개 “둘 다”입니다. 백업 애플리케이션이 업로드 전에 리포지토리 콘텐츠를 암호화하도록 한 다음, 또 다른 통제 수단으로 대상의 일반적인 저장 데이터 암호화를 활성화된 상태로 유지하세요. 두 계층은 서로 다른 사건으로부터 보호합니다.

키는 키가 보호하는 시스템보다 오래 살아남아야 합니다

가장 중요한 키 배치 규칙은 간단합니다. 백업 대상 서버에 암호화 비밀의 유일한 복구 사본을 보관하지 마세요. Borg의 최신 리포지토리 초기화 가이드는 Borg 키의 백업을 리포지토리와 백업을 생성하는 시스템 외부에 보관할 것을 명시적으로 권장합니다.

restic 비밀번호, Kopia 리포지토리 비밀번호, age 키, LUKS 복구 자료, 클라우드 KMS 관리, 애플리케이션 마스터 키에도 같은 논리가 적용됩니다. 유일한 복호화 비밀이 고장 난 부팅 드라이브와 함께 사라진다면, 완벽하게 암호화된 리포지토리도 쓸모가 없습니다.

가정이나 소규모 랩에서는 NAS가 작동하지 않아도 접근할 수 있는 오프라인 복구 사본이나 별도의 자격 증명 시스템에 최소 하나의 복구 사본을 보관하세요. 그런 다음 깨끗한 시스템에서 복원을 테스트하세요. 리포지토리를 여는 데 한 번도 사용하지 않은 비밀번호를 적어 둔 것은 문서화의 증거일 뿐, 복구 가능성의 증거는 아닙니다.

일반적인 홈 서버 설계에서 키를 관리해야 하는 계층은 어디인가?

오브젝트 스토리지에 홈 NAS 백업

데이터가 NAS를 떠나기 전에 restic, Borg, Kopia 또는 이에 준하는 백업 도구의 기본 리포지토리 암호화를 사용하세요. 리포지토리 키/암호문은 NAS 외부에 보관하세요. 심층 방어를 위해 버킷 암호화는 활성화된 상태로 유지하세요. 이렇게 하면 클라우드 대상이 유일한 기밀성 통제 수단이 되는 것을 막을 수 있습니다.

친구의 원격 서버에 홈 NAS 백업

평문 키가 친구의 서버에 저장되지 않는 클라이언트/저장소 암호화를 우선하세요. 원격 호스트에는 내용을 식별할 수 없는 저장소 객체를 보관하고 제한된 쓰기 권한을 적용할 수 있습니다. 원격 시스템에 대한 물리적·관리적 통제권이 다른 장애 도메인에 속하기 때문에 이는 특히 중요합니다.

같은 집에 보관하는 로컬 백업 디스크

저장소 암호화는 디스크를 분실하거나 도난당한 경우에도 기밀성을 보호합니다. 백업 디스크의 전체 디스크 암호화는 유용한 2차 방어 계층이 될 수 있지만, 디스크 잠금 해제 키가 백업 저장소로 가는 유일한 경로가 되지 않도록 하세요.

공급업체 복구 기능을 제공하는 관리형 클라우드 백업

간편성과 공급업체 지원 복구가 평문에 대한 공급업체의 신뢰 경계 외부 유지보다 중요하다면 공급업체 관리 암호화를 고려할 수 있습니다. 이는 영지식 방식의 클라이언트 암호화와는 다른 보안 결정이라는 점을 이해해야 합니다.

모든 백업 비밀을 하나의 자동화 파일에 넣지 마세요

자동으로 실행되는 백업 작업에는 자격 증명이 필요하지만, 편의성 때문에 보안 경계가 무너질 수 있습니다. Restic의 자동화 지침은 비밀번호를 제공하는 방식에 따라 자격 증명이 노출될 수 있다고 경고하며, 비밀번호 파일을 주의 깊게 보호할 것을 권장합니다.

홈 서버에서는 가능한 경우 최소한 다음 역할을 분리하세요.

• 백업 대상에 접근할 수 있도록 범위를 엄격히 제한한 자격 증명
• 저장소 복호화 비밀번호 또는 키
• 해당 비밀번호/키의 오프라인 복구 사본
• 보존 정책, 버킷 또는 원격 계정을 삭제할 수 있는 관리 자격 증명

특정 비밀 하나를 파일, 환경 변수, 비밀번호 관리자, 하드웨어 토큰 또는 KMS 중 어디에 저장할지 결정하는 것보다 이러한 분리가 더 중요합니다. 아키텍처는 도난당한 자동화 자격 증명 하나로 평문을 읽고, 저장소를 삭제하며, 유일한 복구 키를 파괴하는 일이 동시에 발생하지 않도록 해야 합니다.

암호화는 변경 불가능성이나 복원 테스트를 대체하지 않습니다

기밀성, 무결성, 삭제 저항성, 복구 가능성은 서로 별개의 목표입니다. 암호화된 저장소도 삭제될 수 있습니다. 변경 불가능한 버킷에도 복호화 키를 잃어버린 백업이 들어 있을 수 있습니다. 성공적으로 완료된 백업 작업도 복원 중에는 실패할 수 있습니다.

원격 백업 서버와 VM 백업용 클라우드 객체 스토리지에 대한 ZimaSpace의 비교도 동일한 운영상의 결론에 도달합니다. 실제 복구가 테스트되었는지가 대상의 명칭보다 중요합니다.

의사 결정 매트릭스

최종 결론

대부분의 셀프 호스팅 백업 시스템에서는 백업 클라이언트 또는 저장소 형식이 콘텐츠 암호화 경계를 담당하게 하고, 오프사이트 대상은 저장 데이터를 다시 암호화하도록 하세요. 이렇게 하면 중복 제거 및 검증과 같은 백업 기능을 유지하면서 원격 스토리지 시스템에 평문을 맡겨야 하는 정도를 줄일 수 있습니다.

키 관리 계획은 원본 서버, 스토리지 대상, 일반 관리자 워크스테이션을 잃은 후에도 복호화 비밀이 남아 있을 때만 완전합니다. 백업을 복구 가능하다고 판단하기 전에 깨끗한 시스템에서 그 가정을 테스트하세요.

자주 묻는 질문

클라우드 서버 측 암호화만으로 홈 백업에 충분한가요?

저장 데이터를 보호하지만, 일반적으로 스토리지 서비스를 복호화 신뢰 경계 안에 둡니다. 제공업체나 도난당한 스토리지 자격 증명만으로 평문에 접근할 수 없게 하려면 백업 자체 암호화도 사용하세요.

저장소 키를 저장소 안에 보관해야 하나요?

일부 백업 형식은 저장소에 암호화된 키 객체를 저장하지만, 복구하려면 여전히 강력한 암호 구문과 같은 다른 비밀이 필요합니다. 저장소와 원본 시스템 외부에 독립적인 복구 자료를 보관하세요.

백업 전에 파일을 암호화하면 보안이 향상되나요?

민감한 데이터 하위 집합에 대한 추가 신뢰 경계를 만들 수 있지만, 백업 도구가 데이터를 보기 전에 모든 데이터를 암호화하면 중복 제거, 압축, 메타데이터 가시성 및 복원 편의성이 저하될 수 있습니다.

가장 중요한 키 관리 테스트는 무엇인가요?

원래 NAS를 완전히 사용할 수 없다고 가정한 후 깨끗한 시스템에서 복원하세요. 모든 자격 증명을 찾고 대표 데이터를 복호화하지 못한다면, 키 계획은 불완전합니다.