4장 인증, 권한 부여 및 접근 제어

4.0 요약

• 수명이 짧은 액세스 토큰: 암호문/매니페스트 접근을 통제합니다. 서버 측 세션(조회 방식)이며, transferId에 반드시 바인딩되어야 하고, 범위가 반드시 제한되어야 하며, 반드시 만료되어야 합니다.
• 수명이 긴 로그인 토큰: 발신자의 관리 작업(삭제/취소/감사)에 사용합니다. 클라이언트에 저장되며, 수신자가 암호문에 접근하는 데 사용해서는 절대 안 됩니다.
• 키와 권한 부여의 분리: 토큰은 암호문 접근만 통제합니다. 복호화 능력은 URL 프래그먼트에 담긴 CEK에서 나옵니다(5장 참조).

4.1 신원 모델

• 시스템은 발신자 관리를 위한 유료 사용자 신원 모델을 지원합니다.
• 발신자 로그인에는 일회용 매직 링크를 사용할 수 있으며(MAY), 인증에 성공하면 클라이언트가 수명이 긴 로그인 토큰을 저장합니다.
• 기본 다운로드에서는 수신자가 계정을 가질 필요가 없으며(UX 문서 참조), 접근은 링크/토큰으로 통제됩니다.

4.2 권한 부여 모델 & 토큰 계층

역할을 엄격하게 분리한 두 가지 토큰 유형을 사용합니다.

1. 수명이 짧은 액세스 토큰(세션 / 조회): 암호문 업로드/다운로드와 매니페스트 읽기에 사용합니다. transferId에 반드시 바인딩되어야 하고, 반드시 만료되어야 하며, 작업별로 범위가 반드시 제한되어야 합니다.
2. 수명이 긴 로그인 토큰: 발신자의 관리 작업에 사용합니다. 복호화 능력을 부여해서는 절대 안 됩니다.

4.3 업로드 권한 부여

• 업로드 API는 암호문을 받기 전에 토큰의 범위와 transferId 바인딩을 반드시 검증해야 합니다.
• 청크 업로드는 (transferId, fileId, chunkIndex) 단위로 멱등성을 가져야 합니다(SHOULD).
• 토큰이 유효하지 않거나 일치하지 않으면 시스템은 반드시 안전하게 거부(fail closed)해야 합니다.

4.4 다운로드 권한 부여

• 매니페스트와 암호문에 접근하려면 유효하고 범위가 제한된 토큰이 반드시 필요하며, 토큰에는 반드시 유효 기간이 있어야 합니다.
• 수신자는 다른 전송을 열거하거나 바인딩된 transferId 밖의 청크에 접근할 수 없어야 합니다(MUST NOT).
• 이어서 전송하기를 방해하지 않는 범위에서 남용 방지(7장 참조)를 위해 속도 제한을 적용할 수 있습니다(MAY).

4.5 취소 & 조기 무효화

• 발신자는 전송을 반드시 취소할 수 있어야 하며, 취소하면 토큰으로 이후 접근을 할 수 없게 되어야 합니다.
• 취소 시 가능한 경우 암호문의 정리/TTL 단축이 실행되어야 합니다(SHOULD).
• 수신자 UX는 취소됨/만료됨 상태와 다음 단계(발신자에게 문의)를 명확히 안내해야 합니다.

4.6 감사 & 권한 격리

• 전달 증거(다운로드, 횟수)는 기본적으로 발신자에게만 보여야 합니다(MUST).
• 감사 API는 발신자 인증을 반드시 요구해야 하며, 수신자의 액세스 토큰과 반드시 분리되어야 합니다.

4.7 로깅 & 민감 데이터 최소화

• 로그에는 URL 프래그먼트, CEK, 키 자료를 유추할 수 있는 정보가 포함되어서는 안 됩니다(MUST NOT).
• 로그는 개인 데이터를 최소화하고 보안과 관련된 이벤트(토큰 실패, 취소, 속도 제한)에 집중해야 합니다(SHOULD).
• 오류 메시지는 사용자가 조치할 수 있어야 하지만, 비밀 정보를 노출해서는 안 됩니다.

4.8 관련 클레임 ID

• 공식 매핑은 부록: 클레임 ID를 참조하세요.