Logo

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

12장: 제3자가 검증할 수 있는 증거 및 상태 페이지

내부 설계상의 주장에 더해, FileBolt는 외부에서 확인할 수 있는 보안 속성(예: TLS 구성, 보안 헤더 정책 등)을 검증할 수 있도록 누구나 재현할 수 있는 제3자 증거(Evidence)를 공개적으로 제공합니다. 이 장에서는 증거의 유형, 적용 범위, 접근 링크, 그리고 증거를 클레임 ID에 연결하는 원칙을 정의합니다.

12.0 요약

  • SHOULD: 외부에서 확인할 수 있는 보안 기준(TLS, 헤더 등)을 검증할 수 있도록 공개적이고 재현 가능한 제3자 증거 링크를 제공합니다.
  • MUST: 증거 링크는 신뢰할 수 있는 원본 출처만 가리키며, 스크린샷이나 2차 재게시물은 절대 가리키지 않습니다.
  • MUST: 증거의 범위를 명시적으로 정의합니다. 외부 스캔으로는 영지식/E2EE 구현의 세부 사항 전체를 직접 검증할 수 없습니다.
  • SHOULD: 상태 페이지는 증거 링크를 모아 보여 주는 용도로 사용하되, 클레임의 증거 필드는 원본 제3자 출처를 직접 가리켜야 합니다.

12.1 증거 유형 및 범위

12.1.1 검증할 수 있는 것

제3자 증거로 일반적으로 검증할 수 있는 것은 다음과 같습니다.

  • 전송 계층 구성: TLS 버전, 인증서 체인, 암호 스위트, HSTS 등(스캐너의 기능에 따라 다름).
  • HTTP 보안 정책: CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy 등의 헤더 존재 여부와 기본 구성.
  • 외부에 공개된 웹 표면: 흔한 설정 오류, 노출된 엔드포인트, 기본 보안 점수.

12.1.2 직접 검증할 수 없는 것

제3자 증거로 일반적으로 직접 검증할 수 없는 것은 다음과 같습니다.

  • 영지식의 정확성: 예: "서버는 CEK에 접근할 수 없다", 클라이언트 측 암호화 흐름, 키 파생 세부 사항.
  • 내부 운영 및 접근 제어: 예: 내부 권한, 키 관리 절차, 로그 정제, 접근 감사.
  • 절대적인 보안: 스캔은 자체 규칙 집합과 외부에서 보이는 표면만 다룹니다. 지속적인 보안 엔지니어링과 사고 대응을 대신하지 못합니다.

따라서 이 백서는 "외부에서 확인 가능한 보안 기준"과 "프로토콜/구현의 경계"를 구분합니다. 확인 가능한 기준은 증거를 통해 검증할 수 있고, 영지식/E2EE의 경계는 프로토콜 사양과 클라이언트 제약으로 규율됩니다(5장 및 관련 절 참조).

12.2 집계 허브로서의 상태 페이지

FileBolt는 /status를 증거 링크의 집계 허브로 사용합니다. 제3자 보고서 자체를 대체하지는 않으며, 사용자와 감사자가 반복해서 검증할 수 있도록 통합된 탐색 경로를 제공합니다.

  • MUST: 상태 페이지의 증거 링크는 신뢰할 수 있는 제3자 출처(재현 가능)를 가리킵니다.
  • SHOULD: 상태 페이지에 "마지막 확인 날짜/타임스탬프"를 표시할 수 있으나, 이를 영구적이고 변하지 않는 결론처럼 제시해서는 안 됩니다.
  • SHOULD: 특정 경로(예: 다운로드/복호화 페이지)에 더 엄격한 헤더를 적용한 경우, (제3자 도구가 지원한다면) 상태 페이지에 경로 단위의 증거를 제공할 수 있습니다.

12.3 TLS 구성 증거

TLS 증거는 HTTPS 구성, 프로토콜 버전, 인증서 체인 및 외부에서 보이는 속성을 검증합니다. 예시는 다음과 같습니다.

참고: TLS 증거는 "스캔 시점"에 외부에서 보이는 구성을 반영할 뿐이며, 종단 간 콘텐츠 경계나 서버가 CEK에 접근할 수 있는지 여부를 증명하지는 않습니다.

12.4 보안 헤더 증거

보안 헤더 증거는 CSP, Referrer-Policy, X-Frame-Options, Permissions-Policy 등 기본 정책의 존재 여부와 구성을 검증합니다.

권장 사항: 다운로드/복호화 페이지(예: /transfer, /d/**)에 더 엄격한 정책을 적용한다면, 내부 문서에 "핵심 경로는 더 엄격함"이라고 명시하고, 가능하면 특정 경로 스캔을 지원하는 도구를 골라 보완 증거로 활용해야 합니다.

12.5 종합 모범 사례 스캔

종합 스캔은 더 폭넓은 모범 사례 점검(예: HTTP 구성, 흔한 취약점, 캐싱과 보안 정책의 조합)을 다룹니다. 사이트 기준에 대한 보조적인 검증은 되지만, 프로토콜 구현 감사와 같지는 않습니다.

12.6 매핑 원칙: 증거와 클레임 ID

  • MUST: 검증 가능한 모든 클레임(Claim)은 클레임 ID 마스터 목록에 고유한 ID와 안정적인 앵커를 가집니다.
  • MUST: 클레임의 증거 필드는 신뢰할 수 있는 출처(제3자 보고서 페이지 또는 재현 가능한 공식 페이지)만 가리켜야 하며, 스크린샷, 요약, 신뢰할 수 없는 재게시물을 가리켜서는 안 됩니다(MUST NOT).
  • SHOULD: 상태 페이지는 증거의 "탐색용 모음" 역할을 할 수 있지만, 클레임의 주된 증거 필드는 가능한 한 원본 제3자 출처를 가리켜야 합니다.
  • MUST: 클레임의 표현은 증거의 범위와 일치해야 하며, "확인 가능한 기준"을 "절대적인 보안 보장"으로 과장해서는 안 됩니다.

클레임 ID 마스터 목록(유일한 기준 출처): /security-privacy-appendix-claim-ids

12.7 시점 의존성과 규범적 표현

제3자 스캔 결과는 시간이 지나면서 달라집니다(스캐너 규칙 업데이트, 사이트 구성 변경, 인증서 교체 등). 증거를 언급할 때는 "검증할 수 있지만 절대적이지는 않다"는 표현을 사용해야 합니다.

  • SHOULD: 상태 페이지나 문서에 "마지막 확인 날짜/시간"(해당하는 경우)을 기록하고, 사용자가 반복해서 검증할 수 있도록 합니다.
  • MUST: "영구적/절대적"이라는 표현을 피하고, "스캔 결과 활성화됨/준수함으로 나타남"처럼 증거의 범위에 맞는 표현을 사용합니다.
  • SHOULD: 핵심 보안 정책이 바뀌면(예: CSP 강화, TLS 업데이트) 변경 이력에 기록하고 관련 클레임 ID를 연결합니다.

12.8 관련 클레임 ID(예약)

이 장은 "제3자 증거와 매핑 원칙"을 다룹니다. 해당하는 클레임 ID는 부록: 클레임 ID 마스터 목록 에서 관리되며, 이 목록이 유일한 기준 출처입니다.