Logo

セキュリティとプライバシーに関するホワイトペーパー (概要)第12章

第 12 章: 第三者による検証可能な証拠とステータスのページ

FileBolt は、社内の設計上の主張を超えて、目に見えるセキュリティ特性を検証するための、公的に再現可能なサードパーティの証拠 (Evidence) を提供します。 (TLS 構成、セキュリティ ヘッダー ポリシーなど)。この章では、証拠の種類、適用範囲、エントリ リンク、および証拠をクレーム 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 構成、プロトコル バージョン、証明書チェーン、および可視属性を検証します。例としては次のものが挙げられます。

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: クレームの証拠フィールドは、信頼できる情報源 (サードパーティのレポート ページまたは公式の再現可能なページ) のみを指します。 してはなりません スクリーンショット、要約、または権限のない再投稿を指します。
  • SHOULD: ステータス ページは証拠の「ナビゲーション コレクション」として機能する場合がありますが、クレームの主要な証拠フィールドは可能な限り元のサードパーティ ソースを指す必要があります。
  • MUST: 主張の文言は証拠の範囲と一致する必要があり、「目に見えるベースライン」を「絶対的なセキュリティの保証」として誇張することは避けてください。

クレーム ID のマスター リスト (唯一の権限): /security-privacy-appendix-claim-ids

12.7 時間性と規範的言語

サードパーティのスキャン結果は時間の経過とともに変化します (スキャナー ルールの更新、サイト構成の変更、証明書のローテーションなどにより)。証拠への参照には、「検証可能だが絶対的ではない」という表現を使用する必要があります。

  • SHOULD: 「最終検証日時」(該当する場合) をステータス ページまたはドキュメントに記録し、ユーザーが繰り返し検証を実行できるようにします。
  • MUST: 「永続的/絶対的」という表現は避けてください。 「スキャンは有効/準拠を示します」など、証拠の範囲に一致する文言を使用します。
  • SHOULD: 重要なセキュリティ ポリシーが変更された場合 (CSP の強化、TLS の更新など)、これを変更ログに記録し、関連するクレーム ID をリンクします。

12.8 関連クレーム ID (予約済み)

この章では、「第三者の証拠とマッピングの原則」について説明します。対応するクレーム ID は、 付録: クレーム ID のマスター リスト 唯一の信頼できる情報源として。