Logo

보안 및 개인정보 보호 백서(개요)6장

6장 데이터 수명 주기 및 삭제

이 장에서는 암호화된 데이터(암호문 청크와 매니페스트)의 수명 주기, 즉 생성, 보관, 만료, 삭제를 정의합니다. 목표는 영지식 경계를 유지하면서 사용자와 감사자 모두가 예측할 수 있는 동작을 보장하는 것입니다.

6.1 데이터 범주

  • 암호문 청크: 오브젝트 스토리지에 저장되는 암호화된 파일 조각.
  • 매니페스트: 다운로드와 조립에 필요한 공개 매개변수(CEK 없음).
  • 상태: 인가, 진행 상황, TTL, 폐기 플래그, 최소한의 전달 증거.

6.2 삭제 의미

  • 보내는 사람이 시작한 삭제/폐기는 이후의 접근이 실패하도록 해야 합니다(MUST). 토큰이 무효화되거나 상태가 접근을 거부해야 합니다.
  • 삭제 시 가능한 범위에서 관련 객체(청크/매니페스트)를 정리하는 것이 좋습니다(SHOULD).
  • 시스템 동작은 수신자에게 일관되어야 합니다(MUST). 폐기되거나 만료된 전송에는 명확한 사유가 표시되어야 합니다.

6.3 만료 정책 및 자동 정리

6.3.1 만료 트리거

  • 전송에는 expiresAt 정책(플랜별 보관 기간 또는 사용자가 선택한 TTL)을 두는 것이 좋습니다(SHOULD).
  • 만료된 후에는 암호문이 일시적으로 남아 있더라도 접근을 거부해야 합니다(MUST).

6.3.2 자동 정리

  • 백그라운드 정리는 만료된 청크/매니페스트를 합리적인 기간 안에 삭제하는 것이 좋습니다(SHOULD).
  • 정리 작업은 재시도와 부분 실패에도 견딜 수 있어야 합니다(멱등적 삭제).

6.3.3 만료 후 UX 제약 조건

  • 수신자에게는 "만료됨" 상태와 다음 단계(보내는 사람에게 문의)를 명확히 보여 주어야 합니다(MUST).
  • 보내는 사람은 관리 UI에서 "만료됨"과 "폐기됨"을 구분할 수 있어야 합니다(SHOULD).

6.4 사용자에게 보이는 보장 사항

  • 삭제/폐기는 접근 제어에 즉시 적용되어야 합니다(MUST). 실패 시 차단 방식입니다.
  • 스토리지에서의 물리적 삭제는 최종적으로 이루어져도 됩니다(MAY). 다만 다시 활성화하지 않는 한 접근은 계속 거부되어야 합니다.
  • 로그와 증거는 최소한으로 유지해야 하며, 비밀 정보(프래그먼트/CEK)를 포함해서는 안 됩니다.

6.5 관련 클레임 ID