Logo

セキュリティとプライバシーのホワイトペーパー（概要）第12章

第12章：第三者が検証できる証拠とステータスページ

FileBoltは、社内の設計上の主張にとどまらず、外部から確認できるセキュリティ特性（TLS構成、セキュリティヘッダーのポリシーなど）を検証するために、 誰でも再現できる第三者の証拠（Evidence）を公開しています。本章では、証拠の種類、適用範囲、参照リンク、そして証拠をクレーム IDに対応づける原則を定めます。

12.0 概要

  • SHOULD：外部から確認できるセキュリティ基準（TLS、ヘッダーなど）を検証できるよう、公開された再現可能な第三者の証拠へのリンクを提供します。
  • MUST：証拠のリンクは信頼できる一次情報源のみを指し、スクリーンショットや二次的な転載を指してはなりません。
  • MUST：証拠の範囲を明示します。外部スキャンでは、ゼロナレッジやE2EEの実装の詳細全体を直接検証することはできません。
  • SHOULD：ステータスページで証拠のリンクを集約し、クレームの証拠欄は第三者の一次情報源を直接指すようにします。

12.1 証拠の種類と範囲

12.1.1 検証できること

第三者の証拠で通常検証できるのは、次のとおりです。

  • トランスポート層の構成：TLSのバージョン、証明書チェーン、暗号スイート、HSTSなど（スキャナーの機能によります）。
  • HTTPセキュリティポリシー：CSP、X-Frame-Options、Referrer-Policy、Permissions-Policyなどのヘッダーの有無と基本的な構成。
  • 外部から見えるWebの表面：よくある設定ミス、公開されているエンドポイント、基準となるセキュリティスコア。

12.1.2 直接は検証できないこと

第三者の証拠では通常、次のことは直接検証できません。

  • ゼロナレッジの正しさ：例：「サーバーはCEKにアクセスできない」こと、クライアント側の暗号化フロー、鍵導出の詳細。
  • 内部の運用とアクセス制御：例：社内の権限、鍵管理のワークフロー、ログのサニタイズ、アクセス監査。
  • 絶対的な安全性：スキャンが対象とするのは、そのルールセットと外部から見える範囲だけです。継続的なセキュリティエンジニアリングやインシデント対応の代わりにはなりません。

そのため、このホワイトペーパーでは「外部から確認できるセキュリティ基準」と「プロトコル／実装上の境界」を区別します。 確認できる基準は証拠によって検証でき、ゼロナレッジ／E2EEの境界はプロトコル仕様とクライアント側の制約によって担保されます（第5章および関連する節を参照）。

12.2 証拠を集約するハブとしてのステータスページ

FileBoltは、証拠のリンクを集約するハブとして /status を使用しています。 これは第三者のレポート自体の代わりになるものではなく、ユーザーや監査担当者が繰り返し検証できるよう、統一された導線を提供するものです。

  • MUST：ステータスページの証拠リンクは、信頼できる第三者の一次情報源（再現可能なもの）を指します。
  • SHOULD：ステータスページに「最終確認日時」を表示してもかまいませんが、それを恒久的で不変の結論として示してはなりません。
  • SHOULD：特定のパス（ダウンロード／復号のページなど）でより厳格なヘッダーを採用している場合は、（第三者ツールが対応していれば）パス単位の証拠をステータスページで提供してもかまいません。

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：検証可能なすべての主張（クレーム）に、クレーム ID総覧内で一意のIDと安定したアンカーを付与します。
  • MUST：クレームの証拠欄は、信頼できる一次情報源（第三者のレポートページ、または公式の再現可能なページ）のみを指し、スクリーンショット、要約、信頼できない転載を指してはなりません（MUST NOT）。
  • SHOULD：ステータスページは証拠の「ナビゲーション用の一覧」として使ってもかまいませんが、クレームの主たる証拠欄は、できる限り第三者の一次情報源を直接指すようにします。
  • MUST：クレームの表現は証拠の範囲に合わせ、「外部から確認できる基準」を「絶対的な安全性の保証」であるかのように誇張することを避けます。

クレーム ID総覧（唯一の正式な情報源）： /security-privacy-appendix-claim-ids

12.7 時点依存性と規範的な表現

第三者のスキャン結果は、スキャナーのルール更新、サイト構成の変更、証明書のローテーションなどにより、時間とともに変化します。証拠を参照する際は、「検証できるが絶対的ではない」という表現を用いる必要があります。

  • SHOULD：「最終検証日時」（該当する場合）をステータスページやドキュメントに記録し、ユーザーが繰り返し検証できるようにします。
  • MUST：「恒久的」「絶対的」といった表現を避け、「スキャンでは有効／準拠と表示される」のように、証拠の範囲に合った言い回しを使います。
  • SHOULD：重要なセキュリティポリシーを変更した場合（CSPの厳格化、TLSの更新など）は、変更履歴に記録し、関連するクレーム IDにリンクします。

12.8 関連するクレーム ID（予約）

本章は「第三者の証拠と対応づけの原則」を扱います。対応するクレーム IDは、唯一の正式な情報源として 付録：クレーム ID総覧 で管理されています。