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 업로드 흐름
- 클라이언트는 전송을 생성하고 다음에 바인딩된 단기 범위의 업로드 토큰을 받습니다.
transferId. - 클라이언트는 파일별 CEK를 로컬에서 생성하고, 파일을 고정 크기 청크로 분할하고, AEAD로 각 청크를 암호화합니다.
- 클라이언트는 암호문 청크를 병렬로 업로드합니다. 재시도는 청크당 멱등성을 갖습니다.
- 클라이언트는 매니페스트를 업로드합니다(공개 매개변수만 해당). 필요한 부분이 있으면 서버는 전송 준비 완료로 표시합니다.
3.4 다운로드 흐름
- 수신자가 공유 링크를 엽니다. URL 조각(CEK 자료)은 브라우저에 남아 있으며 서버로 전송되지 않습니다.
- 클라이언트는 범위가 지정된 다운로드 토큰을 사용하여 매니페스트를 가져오고 청크 계획을 결정합니다.
- 클라이언트는 암호문 청크(선택적으로 병렬)를 다운로드하고 AEAD 인증을 확인한 다음 일반 텍스트 파일을 어셈블합니다.
- 실패 시 클라이언트는 누락된 청크만 요청하여 재개됩니다. 무결성 실패는 반드시 실패 처리되어야 합니다.
3.5 발신자 관리 및 감사 흐름
- 발신자는 관리 작업을 위해 클라이언트에 저장된 장기 로그인 토큰을 사용하여 인증합니다.
- 관리 API를 사용하면 이체 목록 조회, 배송 증거 확인, 이체 취소/삭제 등이 가능합니다.
- 감사 데이터는 보낸 사람만 볼 수 있도록 설계되었습니다. 기본적으로 수신자에게 노출되지 않습니다.
3.6 가시성 및 최소화
- 서버와 스토리지는 암호문과 필요한 공개 매개변수만 처리합니다. CEK 없이는 콘텐츠를 해독할 수 없습니다.
- 로그 및 분석은 최소화되어야 하며 URL 조각이나 CEK 자료를 포함해서는 안 됩니다.
- 메타데이터 수집은 목적이 제한되어야 합니다(전달 증거, 남용 방지 및 운영 신뢰성).