작동 원리

설계에 의한 프라이버시

데이터베이스에서 강제되는 격리, 사용자별 키를 쓰는 필드 수준 암호화, 그리고 종단 간 레이어가 무엇을 주고 무엇을 주지 않는지에 대한 정직한 설명.

이 페이지는 검증되도록 쓰였습니다. 당신이 타인의 법률, 이민, 의료 사안을 다룬다면, 아래의 주장들은 당신의 고객이 결국 입증을 요구할 것들입니다.

두 개의 독립적인 경계

Tenant
End user
Space프라이버시 경계
documentsRow-level security필드 수준 암호화
conversationsRow-level security필드 수준 암호화
memoriesRow-level security필드 수준 암호화
Row-level security· 애플리케이션 코드가 아니라 Postgres가 강제필드 수준 암호화· 사용자별 키, 스페이스별 스코프

같은 행에 대한 두 개의 독립적인 보장 — 어느 쪽도 다른 쪽이 유지되는 것에 의존하지 않습니다.

격리는 애플리케이션 코드가 아니라 데이터베이스가 강제합니다. Row-level security는 필터를 잊은 쿼리가 다른 사람의 행이 아니라 아무것도 반환하지 않는다는 뜻입니다. 애플리케이션 수준 스코핑은 잊힌 WHERE 하나면 데이터 유출입니다. 이것은 다른 부류의 보장이며, 그것이 플랫폼이 경계를 그곳에 두는 이유입니다.

암호화는 그것과 독립적입니다. 데이터베이스 접근이 있어도 대화와 문서 내용은 암호문입니다.

봉투(envelope)

암호화된 필드는 고정된 레이아웃으로 저장됩니다:

fmt
1 byte
dek_version
2 bytes · big-endian
nonce
12 bytes
ciphertext + tag
rest

Not to scale. 실제로는 암호문이 대부분을 차지하고, 헤더 필드는 몇 바이트에 불과합니다.

그 모양에서 두 가지 결과가 나옵니다.

마이그레이션 없이 키를 회전할 수 있습니다. 버전이 암호문과 함께 이동하므로, 사용자는 여러 개의 데이터 암호화 키를 동시에 보유할 수 있습니다: 새 쓰기는 활성 키를 쓰고, 읽기는 암호문이 쓰인 키를 선택합니다. 회전은 멈춰-세우는 이벤트가 아니라 점진적인 재암호화가 됩니다 — 이는 중요합니다. 다운타임을 요구하는 회전 방식은 결국 결코 실행되지 않는 경향이 있기 때문입니다.

암호문은 옮길 수 없습니다. AEAD의 추가 인증 데이터가 각 값을 그것의 (tenant, user, space, field)에 묶습니다. 암호문을 다른 행, 다른 필드, 다른 테넌트의 레코드로 복사하면 내용을 조용히 드러내는 대신 복호화에 실패합니다 — 그래서 데이터베이스 수준의 조작 시도가 데이터 유출이 되지 않습니다.

키가 사는 곳

각 사용자의 데이터 암호화 키는 키 제공자 추상화 뒤에서 키 암호화 키로 래핑됩니다. 현재 구현은 KEK를 애플리케이션 secret에서 읽습니다. 이 이음새는 KMS, vault, 또는 테넌트별 자체 키 반입(BYOK)이 데이터 모델이나 호출 코드를 바꾸지 않고 설정만으로 도입될 수 있도록 존재합니다.

현재 상태에 대해 정확히 하자면: 오늘 KEK는 애플리케이션이 보유합니다. 그것은 현재 배포에 적절하며, 고객 관리 키와 같은 것은 아닙니다.

모든 호스팅 에이전트의 한계, 그리고 그에 대한 대응

민감한 대화는 종단 간 레이어를 추가할 수 있습니다: 클라이언트가 일시적인 ECDH(P-256) 공개 키를 보내면, 서버가 ECDH와 HKDF로 세션 키를 유도하고, 스트리밍되는 각 청크가 AES-GCM으로 암호화되어 브라우저에서 복호화됩니다. TLS 위에서 스트리밍 레이어의 노출을 줄입니다.

이것은 제로 지식(zero knowledge)이 아니며, 어떤 호스팅 에이전트도 그럴 수 없습니다. 이는 이 구현의 속성이 아니라 문제 자체의 속성이므로 분명히 말할 가치가 있습니다: 당신의 지식 베이스에서 검색하려면 서버는 당신의 콘텐츠를 임베딩하고 비교해야 하고, 답하려면 검색한 문단으로부터 생성해야 합니다. 자료를 읽을 수 없는 시스템은 그것을 검색하거나 그것으로부터 답할 수 없습니다. "제로 지식 지식 베이스"는 모순이며, 둘 다를 제공한다는 어떤 벤더든 그중 하나를 느슨하게 서술하고 있는 것입니다.

그래서 정직한 틀은 운영자가 콘텐츠를 읽을 수 있는지가 아니라, 운영자가 누구인지입니다.

우리 클라우드에서, 우리는 노출되는 것을 최소화합니다

  • 콘텐츠는 사용자별 키로 저장 시 암호화됩니다. 데이터베이스 덤프는 읽을 수 있는 것을 아무것도 내놓지 않습니다.
  • 격리는 애플리케이션 코드가 아니라 데이터베이스가 강제합니다.
  • 현재 메시지, 그것을 위해 검색된 문단, 그 엔드유저의 메모리만 모델로 갑니다 — 결코 지식 베이스 전체가 아니고, 결코 다른 사용자의 데이터가 아닙니다.
  • 종단 간 레이어가 응답 스트림을 보호합니다.

이는 의미 있는 노출 감소입니다. 우리가 대화를 읽을 수 없다는 것과 같지는 않으며, 우리는 당신이 그것을 당신 고객의 감사관이 아니라 우리에게서 듣기를 바랍니다.

요구가 절대적인 곳에서는, 직접 운영하세요

당신의 의무가 콘텐츠가 진정으로 제3자에 도달할 수 없음을 뜻한다면, 답은 더 강한 암호화 주장이 아니라 — 우리가 경로에 없는 배포입니다.

플랫폼은 당신이 통제하는 인프라, 당신 자신의 클라우드 계정을 포함해 배포될 수 있으며, 모델 엔드포인트를 당신이 호스팅하는 모델로 가리킬 수 있습니다. 그 구성에서 당신의 문서와 대화는 당신의 네트워크를 결코 떠나지 않으며, 접근 권한을 가진 운영자는 당신입니다. 공유 용량보다 비용이 더 들며, 그것이 트레이드입니다: 컴플라이언스는 형용사가 아니라 인프라로 삽니다.

전용 배포가 어떻게 범위 지정되고, 운영되고, 청구되는지는 Enterprise 플랜을 참조하세요.

무엇이 모델로 나가나

메시지에 답하면 모델로 보내지는 것은: 메시지, 그것을 위해 검색된 문단, 그리고 그 엔드유저를 위해 검색된 메모리입니다. 지식 베이스 전체가 아니고, 결코 다른 사용자의 데이터가 아닙니다 — 검색은 무엇이든 조립되기 전에 스페이스에 스코프됩니다.

당신이 자체 모델 제공자를 설정하는 곳에서는, 콘텐츠가 그들과의 계약 하에 그 제공자로 가고, 그들의 보존과 학습 약관이 적용됩니다. 그것은 우리 계약이 아니라 당신의 계약이며, 읽어볼 가치가 있습니다.

삭제

문서를 삭제하면 그것이 파생 메모리에 기여한 것이 제거됩니다 — 콘텐츠를 원본보다 오래 남은 메모리를 통해 복구 가능한 채로 두는 대신에. 보존 기간과 계정 종료 시 삭제 경로는 개인정보 처리방침에, 비즈니스 고객을 위한 처리 약속은 DPA에 있습니다.

실제로 의미하는 것

  • 쿼리 버그가 다른 고객의 대화를 노출할 수 없습니다 — 데이터베이스가 거부하기 때문입니다.
  • 도난된 데이터베이스 덤프가 읽을 수 있는 콘텐츠를 내놓지 않습니다.
  • 키를 정상 운영 중에 회전할 수 있으므로, 회전이 실제로 일어납니다.
  • 종단 간 옵션은 실재하지만 한정적입니다 — 그리고 요구가 절대적인 곳에서는, 공유 모델에 대한 더 강한 주장이 아니라 배포 모델이 답입니다.