프라이빗 RAG 시스템은 저장된 암호화 문서를 복호화하지 않고 검색할 수 있나요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Can a Private RAG System Search Encrypted Documents Without Decrypting Them at Rest?

예. “저장된 상태에서 복호화하지 않음”이 문서가 스토리지에서는 암호화된 상태로 유지되고, 인덱싱이나 검색이 필요할 때만 신뢰할 수 있는 프로세스 내부에서 복호화된다는 의미라면 가능합니다. 이는 비공개 홈 RAG 시스템을 위한 현실적인 설계입니다. 하지만 일반적인 의미 검색은 임베딩 모델이 불투명한 암호문을 바로 읽고 문서를 이해하도록 단순히 설정할 수 없습니다.

따라서 실용적인 아키텍처는 저장 시 암호화된 스토리지, 메모리에서의 통제된 복호화, 암호화되었거나 접근이 제어되는 파생 인덱스, 그리고 엄격한 키 분리로 구성됩니다. 암호문을 직접 검색하는 것은 특수한 암호 기술을 통해서만 가능하며, 이러한 기술은 일반적인 벡터 데이터베이스를 바로 대체할 수 없습니다.

“저장 시 암호화”가 “절대 복호화되지 않음”을 의미하는 것은 아닙니다

저장 데이터 암호화는 파일이 디스크, SSD, 백업 대상 또는 전원이 꺼진 장치에 저장되어 있는 동안 파일을 보호합니다. 올바른 키를 가진 프로세스는 정당한 작업을 수행해야 할 때 데이터를 복호화할 수 있습니다.

디스크에 저장된 암호화된 문서
          |
          | 인증된 읽기
          v
신뢰할 수 있는 RAG 프로세스 메모리
  ├─ 복호화
  ├─ 파싱 / 청킹
  ├─ 임베딩 생성
  └─ 검색
          |
          v
암호화된 인덱스 / 보호된 데이터베이스

이는 여러 암호화된 데이터베이스와 파일 시스템의 작동 방식과 유사합니다. 저장 매체에는 유용한 평문이 포함되지 않지만, 애플리케이션은 인증 후 평문을 볼 수 있습니다.

이 설계는 NAS의 비공개 AI 어시스턴트와 호환됩니다. 핵심은 평문이 존재해도 되는 위치와 시간을 정의하는 것입니다.

일반 벡터 검색으로 원시 암호문을 검색할 수 없는 이유

임베딩 모델에는 의미 있는 텍스트, 이미지 또는 오디오 특징이 필요합니다. 일반적인 암호화는 암호문이 모델에 필요한 의미적 관계를 보존하지 못하도록 눈에 보이는 패턴을 의도적으로 제거합니다.

두 개의 평문 문장이 유사하다면, 해당 문장들의 안전하게 암호화된 암호문도 쉽게 유사해 보이면 안 됩니다. 그러면 원문의 정보가 유출될 수 있습니다.

따라서 일반적인 RAG 수집 경로는 다음과 같이 진행됩니다.

프로세스를 인증합니다.
문서를 메모리 또는 엄격하게 통제되는 임시 영역으로 복호화합니다.
콘텐츠를 추출하고 정규화합니다.
청크와 임베딩을 생성합니다.
파생 검색 데이터를 별도의 보호 정책에 따라 저장합니다.
수집이 완료되면 일시적인 평문을 폐기합니다.

“암호화된 문서는 저장 상태에서도 암호화된 채로 남는다”는 말은 이 워크플로 전체에서 여전히 사실일 수 있습니다. 평문이 디스크에 영구 파일로 저장될 필요가 없기 때문입니다.

임베딩은 원본 문서와 같지 않지만 여전히 민감합니다

흔한 실수는 PDF는 암호화하면서 임베딩, 청크 텍스트, 파일 이름, 메타데이터, 벡터 데이터베이스 스냅샷은 보호하지 않는 것입니다. 이는 개인정보 문제를 해결하는 대신 다른 곳으로 옮길 뿐입니다.

아티팩트	정보를 드러낼 수 있나요?	권장 처리
원본 파일	예, 직접적으로	저장 시 암호화
추출된 청크 텍스트	예, 직접적으로	암호화하거나 영구적인 평문 저장을 피함
임베딩 벡터	잠재적으로 의미적 파생물로서	민감한 데이터로 보호
파일 이름 / 태그	흔히	최소화하고 액세스 제어 적용
벡터 인덱스	관계와 구성원 정보를 노출할 수 있음	스토리지를 암호화하고 액세스를 제한
백업 / 스냅샷	과거 사본을 포함함	독립적으로 암호화

Qdrant의 최신 보안 문서에서는 셀프 호스팅 배포를 명시적으로 보호해야 한다고 강조합니다. 자체 관리 환경에서 스토리지 암호화는 인프라의 책임이며, 데이터베이스가 로컬에 있다는 이유만으로 보장된다고 가정해서는 안 됩니다.

비공개 검색 시스템에서는 임베딩을 무해한 캐시 파일이 아니라 보호 대상 지식 베이스의 일부로 취급하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

복호화 키는 어디에 보관해야 하나요?

복호화 키를 암호화된 문서 옆의 모든 사용자가 읽을 수 있는 구성 파일에 저장하지 마세요. 목표는 디스크를 훔치거나 백업을 복사하는 것만으로는 데이터를 복구할 수 없게 만드는 것입니다.

더 강력한 홈랩 설계에서는 다음을 분리합니다.

데이터 볼륨: 암호화된 문서와 데이터베이스 파일입니다.
키 자료: OS 키링, 하드웨어 기반 키 저장소 또는 별도로 보호되는 비밀 저장소에 보관합니다.
서비스 ID: RAG 프로세스에는 필요한 키만 전달합니다.
백업 키: 암호화된 백업의 유일한 사본과 분리해 보관합니다.

디스크 암호화만으로는 관리자 수준의 침해가 발생한 완전히 잠금 해제된 실행 중 서버를 보호할 수 없습니다. 디스크 암호화는 도난당한 드라이브, 오프라인 복사본, 폐기된 하드웨어, 백업 미디어에 대한 무단 접근이라는 다른 위협을 방어합니다.

평문 임시 파일을 어떻게 방지하나요?

많은 문서 파서는 조용히 임시 파일을 생성합니다. OCR 파이프라인은 페이지를 압축 해제할 수 있고, 오피스 변환기는 중간 형식으로 파일을 기록할 수 있으며, PDF 도구는 추출한 리소스를 캐시할 수 있습니다.

수집 경로를 감사하고 다음 세 가지 패턴 중 하나를 선택하세요.

복호화된 바이트를 파서로 직접 스트리밍하세요.
중간 파일에는 RAM 기반 임시 파일 시스템을 사용하세요.
임시 저장소를 암호화된 볼륨에 두고 처리가 끝나는 즉시 삭제하세요.

로그도 점검하세요. 문서 텍스트, 프롬프트, 검색된 청크 또는 도구 인수를 출력하는 “디버그” 로그가 지식 베이스의 암호화되지 않은 사본 중 가장 큰 것이 될 수 있습니다.

동형 암호화로 복호화 없이 문서를 검색할 수 있을까요?

암호화된 데이터에 대한 연산을 원할 때 대부분의 사람들이 가장 먼저 찾는 기술이 동형 암호화입니다. Microsoft의 SEAL 문서에서는 동형 암호화 방식이 값이 암호화된 상태에서도 특정 연산을 수행할 수 있다고 설명합니다.

하지만 여기에는 중요한 한계도 명시되어 있습니다. 동형 암호화는 상당한 성능 오버헤드를 발생시키며 특정 연산만 효율적으로 지원합니다. Microsoft SEAL은 암호화된 덧셈과 곱셈 같은 산술 연산을 지원하지만, 일반적인 비교, 정렬, 정규 표현식은 일반적으로 평문 연산과 같은 방식으로 실용적이지 않습니다.

CKKS와 같은 방식을 사용하면 근사 거리 계산을 구성할 수 있으므로, 개인정보 보호형 벡터 검색 연구는 실제로 진행되고 있습니다. 그렇다고 해서 암호화된 시맨틱 검색이 Qdrant, pgvector 또는 Weaviate를 설치하고 “암호화된 쿼리” 플래그를 켜는 것과 같다는 의미는 아닙니다.

접근 방식	가정용 RAG의 실용성	주요 절충점
암호화된 디스크 + 메모리 내 복호화	높음	실행 중인 프로세스는 평문에 액세스할 수 있음
암호화된 데이터베이스 볼륨	높음	저장소는 보호하지만 손상된 런타임은 보호하지 못함
검색 가능 암호화 / 동형 암호화	특수 목적	복잡성, 유출 모델, 성능
일반 벡터 DB에 암호문 업로드	유용하지 않음	의미 구조가 남지 않음

더 안전한 비공개 RAG 설계

대부분의 가정과 소규모 팀에서 보안성과 복잡성의 균형이 가장 좋은 구성은 다음과 같습니다.

암호화된 NAS 데이터세트
      |
      | 서비스 범위 키
      v
RAG 수집 컨테이너
      |
      +-- 메모리 내 또는 암호화된 임시 저장소에만 평문 유지
      |
      +-- 임베딩 + 메타데이터
      v
암호화된 벡터 DB 볼륨
      |
      v
로컬 검색 서비스
      |
      | 검색된 청크 최소 개수
      v
로컬 모델 또는 승인된 클라우드 모델

클라우드 모델이 사용되는 경우 저장소는 완벽하게 암호화된 상태로 유지될 수 있지만, 검색된 텍스트는 프롬프트에 포함되어 여전히 홈 네트워크 밖으로 전송될 수 있습니다. 저장소 암호화와 데이터 외부 전송 제어는 별개의 문제입니다. 로컬 AI 신뢰 경계 가이드가 유용한 이유가 여기에 있습니다. 데이터를 복호화하도록 허용된 구성 요소가 자동으로 데이터를 전송하도록 허용되어서는 안 됩니다.

비공개 RAG 암호화 체크리스트

원본 문서 볼륨을 암호화하세요.
벡터 데이터베이스 저장소, 스냅샷 및 백업도 보호하세요.
키를 일반 문서 디렉터리 외부에 보관하세요.
RAG 서비스에는 필요한 최소한의 키 및 경로 접근 권한만 부여하세요.
지속적인 평문 추출 캐시를 사용하지 마세요.
OCR, 변환 및 디버그 임시 디렉터리를 검사하세요.
기본적으로 검색된 비공개 청크를 로그에 기록하지 마세요.
로컬 검색 권한과 클라우드 외부 전송 권한을 분리하세요.
암호화 키를 교체하거나 삭제하기 전에 복구를 테스트하세요.

문서 검색 및 RAG 가이드는 이 보안 계층을 추출, 청킹, 임베딩 및 검색에 적용하는 방법을 파악하는 데 도움이 됩니다.

자주 묻는 질문

벡터 데이터베이스가 AES로 암호화된 PDF를 직접 인덱싱할 수 있나요?

아니요. 일반적인 텍스트 또는 멀티모달 임베딩 모델이 문서에서 의미를 추출하려면 먼저 권한이 있는 프로세스가 콘텐츠를 복호화해야 합니다.

전체 디스크 암호화가 실행 중인 RAG 서버를 보호하나요?

부분적으로만 그렇습니다. 볼륨이 잠금 해제되면 권한이 높은 프로세스가 해당 볼륨을 읽을 수 있습니다. 전체 디스크 암호화는 오프라인 접근, 도난당한 드라이브, 복사된 미디어에 대한 보호에 가장 강력합니다.

임베딩을 암호화해야 하나요?

민감한 비공개 지식이라면 그렇습니다. 임베딩과 인덱스가 포함된 저장소를 보호하고, 데이터베이스 접근을 제한하며, 원본 문서와 동일한 보안 검토에 해당 파일도 포함해야 합니다.

최종 결론

비공개 RAG 시스템은 일반적인 의미 검색을 포기하지 않고도 저장된 문서를 암호화된 상태로 유지할 수 있습니다. 현실적인 방식은 불투명한 암호문을 마법처럼 검색하는 것이 아니라, 신뢰할 수 있는 메모리 내부에서 제어된 방식으로 일시적으로 복호화하는 것입니다. 파생된 임베딩과 인덱스를 보호하고, 키와 데이터를 분리하며, 평문 임시 파일을 없애고, 동형암호 검색은 일반적인 홈 RAG 기능이 아니라 특수한 암호 설계로 다뤄야 합니다.