Logo

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

제 12 장: 제3자 검증 가능한 증거 및 상태 페이지

내부 설계 주장 외에도 FileBolt는 가시적인 보안 속성을 확인하기 위해 공개적으로 재현 가능한 제3자 증거(Evidence)를 제공합니다. (예: TLS 구성, 보안 헤더 정책 등) 이 장에서는 증거 유형, 적용 가능한 범위, 항목 링크 및 증거를 청구 ID에 매핑하는 원칙을 정의합니다.

12.0 요약

  • SHOULD: 공개적이고 재현 가능한 제3자 증거 링크를 제공하여 가시적인 보안 기준(TLS, 헤더 등)을 확인합니다.
  • 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 증거 링크의 집계 허브로 사용됩니다. 이는 타사 보고서 자체를 대체하지는 않지만 사용자와 감사자가 반복적인 검증을 수행할 수 있도록 통합 탐색 기능을 제공합니다.

  • MUST: 상태 페이지의 증거 링크는 권위 있는 제3자 소스를 가리킵니다(재현 가능).
  • SHOULD: 상태 페이지에 "마지막 확인 날짜/타임스탬프"가 표시될 수 있지만 이를 영구적이고 변경할 수 없는 결론으로 표시해서는 안 됩니다.
  • SHOULD: 특정 경로(예: 다운로드/암호 해독 페이지)가 더 엄격한 헤더를 사용하는 경우 상태 페이지에 경로 수준 증거가 제공될 수 있습니다(타사 도구에서 지원하는 경우).

12.3 TLS 구성 증거

TLS 증거는 HTTPS 구성, 프로토콜 버전, 인증서 체인 및 표시되는 속성을 확인합니다. 예는 다음과 같습니다:

Note: TLS 증거는 "스캔 시점"에 표시되는 구성을 반영합니다. 엔드투엔드 콘텐츠 경계나 서버가 CEK에 액세스할 수 있는지 여부를 증명하지 않습니다.

12.4 보안 헤더 증거

보안 헤더 증거는 CSP, Referrer-Policy, X-Frame-Options, Permissions-Policy 등과 같은 기본 정책의 존재 및 구성을 확인합니다.

Recommendation: 다운로드/복호화 페이지(예: /transfer, /d/**) 더 엄격한 정책을 사용하려면 내부 문서에 "중요한 경로가 더 엄격함"을 기록해야 하며, 가능한 경우 특정 경로 검색을 지원하는 도구를 보충 증거로 선택해야 합니다.

12.5 포괄적인 모범 사례 스캔

포괄적인 스캔은 더 광범위한 모범 사례 검사(예: HTTP 구성, 일반적인 약점, 캐싱 및 보안 정책 조합)를 포괄합니다. 이는 사이트 기준에 대한 보조 검증을 제공하지만 프로토콜 구현 감사와 동일하지 않습니다.

12.6 매핑 원칙: 증거 및 주장 ID

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

청구 ID의 마스터 목록(독점 권한): /security-privacy-appendix-claim-ids

12.7 시간성과 규범적 언어

타사 검색 결과는 시간이 지남에 따라 변경됩니다(스캐너 규칙 업데이트, 사이트 구성 변경, 인증서 순환 등으로 인해). 증거에 대한 언급은 "검증 가능하지만 절대적이지는 않음"이라는 문구를 사용해야 합니다.

  • SHOULD: 상태 페이지나 문서에 "마지막 확인 날짜/시간"(해당하는 경우)을 기록하고 사용자가 반복 확인을 수행할 수 있도록 합니다.
  • MUST: "영구적/절대적"이라는 표현은 피하세요. "스캔은 활성화/규정 준수를 나타냅니다."와 같이 증거 범위와 일치하는 언어를 사용합니다.
  • SHOULD: 중요한 보안 정책이 변경되면(예: CSP 강화, TLS 업데이트) 이를 변경 로그에 기록하고 관련 클레임 ID를 연결하세요.

12.8 관련 청구 ID(예약됨)

이 장에서는 "제3자 증거 및 매핑 원칙"을 다룹니다. 해당 청구 ID는 부록: 청구 ID 마스터 목록 유일한 권위 있는 출처로 사용됩니다.