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

문서 메타데이터

백서 버전

v1.0

최종 업데이트

2026-01-14

3.1 구성 요소

• 클라이언트: 파일을 청크로 나누고, 암호화/복호화하며, URL 프래그먼트에 담긴 CEK를 관리합니다.
• API/엣지: 범위가 제한된 토큰을 발급하고 검증하며, 매니페스트와 암호문 청크를 제공합니다.
• 오브젝트 스토리지: 암호화된 청크와 매니페스트를 저장합니다. 평문의 기밀성 측면에서는 신뢰할 수 없는 것으로 간주합니다.
• 상태 저장소: 최소한의 메타데이터로 전송 상태(업로드 진행 상황, 만료, 폐기)를 추적합니다.

3.2 데이터 객체

• 매니페스트: 청크를 가져와 조립하는 데 필요한 공개 매개변수(cryptoVersion, 청크 크기/개수, 매핑)이며, CEK를 포함해서는 안 됩니다(MUST NOT).
• 청크: 암호화된 파일 조각(암호문)과 최소한의 메타데이터(길이/etag)이며, (transferId, fileId, chunkIndex)로 식별합니다.
• 상태: 인가, TTL, 폐기, 이어받기를 위한 서버 측 기록입니다.

3.3 업로드 흐름

1. 클라이언트가 전송을 생성하면 transferId에 묶인, 수명이 짧고 범위가 제한된 업로드 토큰을 받습니다.
2. 클라이언트는 파일별 CEK를 로컬에서 생성하고, 파일을 고정 크기 청크로 나눈 뒤 각 청크를 AEAD로 암호화합니다.
3. 클라이언트는 암호문 청크를 병렬로 업로드하며, 재시도는 청크 단위로 멱등적입니다.
4. 클라이언트는 매니페스트(공개 매개변수만 포함)를 업로드합니다. 필요한 부분이 모두 갖춰지면 서버가 전송을 READY로 표시합니다.

3.4 다운로드 흐름

1. 수신자가 공유 링크를 엽니다. URL 프래그먼트(CEK 정보)는 브라우저에만 남고 서버로 전송되지 않습니다.
2. 클라이언트는 범위가 제한된 다운로드 토큰으로 매니페스트를 가져와 청크 계획을 정합니다.
3. 클라이언트는 암호문 청크를 다운로드(필요에 따라 병렬)하고 AEAD 인증을 검증한 뒤 평문 파일을 조립합니다.
4. 실패하면 클라이언트는 누락된 청크만 다시 요청하여 이어받습니다. 무결성 검증에 실패하면 반드시 실패 시 차단 방식으로 처리해야 합니다(MUST).

3.5 보내는 사람 관리 및 감사 흐름

• 보내는 사람은 관리 작업을 위해 클라이언트에 저장된 장기 로그인 토큰으로 인증합니다.
• 관리 API로 전송 목록 조회, 전달 증거 확인, 전송 폐기/삭제를 할 수 있습니다.
• 감사 데이터는 보내는 사람만 볼 수 있도록 설계되었으며, 기본적으로 수신자에게는 노출되지 않습니다.

3.6 가시성 및 최소화

• 서버와 스토리지는 암호문과 필요한 공개 매개변수만 다루며, CEK 없이는 콘텐츠를 복호화할 수 없습니다.
• 로그와 분석 데이터는 최소화하는 것이 좋으며(SHOULD), URL 프래그먼트나 CEK 정보를 포함해서는 안 됩니다(MUST NOT).
• 메타데이터 수집은 목적에 맞게 제한하는 것이 좋습니다(SHOULD). 전달 증거, 오남용 방지, 운영 안정성이 그 목적입니다.