Logo

3장 시스템 아키텍처 및 데이터 흐름

이 장에서는 업로드, 다운로드 및 보낸 사람 관리를 위한 상위 수준 시스템 구성 요소와 종단 간 데이터 흐름에 대해 설명합니다. 암호화되는 내용, 필요한 메타데이터, 액세스 제어 및 해지가 적용되는 방법에 중점을 둡니다.

문서 메타데이터

백서 버전
v1.0
마지막 업데이트
2026-01-14

3.1 구성요소

  • Client: 파일을 청크하고, 암호화/해독하고, URL 조각에서 CEK를 관리합니다.
  • API/Edge: 범위가 지정된 토큰을 발행하고 검증합니다. 매니페스트 및 암호문 청크를 제공합니다.
  • 객체 스토리지: 암호화된 청크와 매니페스트를 저장합니다. 일반 텍스트 기밀성을 위해 신뢰할 수 없는 것으로 처리됩니다.
  • 주립 상점: 최소한의 메타데이터로 전송 상태(업로드 진행률, 만료, 취소)를 추적합니다.

3.2 데이터 객체

  • Manifest: 청크를 가져오고 조립하는 데 필요한 공개 매개변수(cryptoVersion, 청크 크기/개수, 매핑) CEK를 포함하면 안 됩니다.
  • Chunk: 암호화된 파일 조각(암호 텍스트)과 최소한의 메타데이터(길이/etag)를 더한 것이며 (transferId, fileId, ChunkIndex)로 주소가 지정됩니다.
  • State: 승인, TTL, 취소 및 재개를 위한 서버측 레코드입니다.

3.3 업로드 흐름

  1. 클라이언트는 전송을 생성하고 다음에 바인딩된 단기 범위의 업로드 토큰을 받습니다. transferId.
  2. 클라이언트는 파일별 CEK를 로컬에서 생성하고, 파일을 고정 크기 청크로 분할하고, AEAD로 각 청크를 암호화합니다.
  3. 클라이언트는 암호문 청크를 병렬로 업로드합니다. 재시도는 청크당 멱등성을 갖습니다.
  4. 클라이언트는 매니페스트를 업로드합니다(공개 매개변수만 해당). 필요한 부분이 있으면 서버는 전송 준비 완료로 표시합니다.

3.4 다운로드 흐름

  1. 수신자가 공유 링크를 엽니다. URL 조각(CEK 자료)은 브라우저에 남아 있으며 서버로 전송되지 않습니다.
  2. 클라이언트는 범위가 지정된 다운로드 토큰을 사용하여 매니페스트를 가져오고 청크 계획을 결정합니다.
  3. 클라이언트는 암호문 청크(선택적으로 병렬)를 다운로드하고 AEAD 인증을 확인한 다음 일반 텍스트 파일을 어셈블합니다.
  4. 실패 시 클라이언트는 누락된 청크만 요청하여 재개됩니다. 무결성 실패는 반드시 실패 처리되어야 합니다.

3.5 발신자 관리 및 감사 흐름

  • 발신자는 관리 작업을 위해 클라이언트에 저장된 장기 로그인 토큰을 사용하여 인증합니다.
  • 관리 API를 사용하면 이체 목록 조회, 배송 증거 확인, 이체 취소/삭제 등이 가능합니다.
  • 감사 데이터는 보낸 사람만 볼 수 있도록 설계되었습니다. 기본적으로 수신자에게 노출되지 않습니다.

3.6 가시성 및 최소화

  • 서버와 스토리지는 암호문과 필요한 공개 매개변수만 처리합니다. CEK 없이는 콘텐츠를 해독할 수 없습니다.
  • 로그 및 분석은 최소화되어야 하며 URL 조각이나 CEK 자료를 포함해서는 안 됩니다.
  • 메타데이터 수집은 목적이 제한되어야 합니다(전달 증거, 남용 방지 및 운영 신뢰성).