Logo

Livre blanc sur la sécurité et la confidentialité (présentation)Chapitre 12

Chapitre 12 : Page de preuves et de statut vérifiables par des tiers

Au-delà de nos revendications de conception interne, FileBolt fournit des preuves tierces (preuves) publiquement reproductibles pour vérifier les propriétés de sécurité visibles. (telles que la configuration TLS, les politiques d'en-tête de sécurité, etc.). Ce chapitre définit les types de preuves, la portée applicable, les liens d'entrée et les principes de mappage des preuves aux ID de réclamation.

12.0 Résumé

  • SHOULD: Fournissez des liens de preuves tierces publics et reproductibles pour vérifier les bases de sécurité visibles (TLS, en-têtes, etc.).
  • MUST: Les liens de preuves pointent uniquement vers des sources faisant autorité, jamais vers des captures d'écran ou des republications secondaires.
  • MUST: Définir explicitement la portée des preuves : les analyses externes ne peuvent pas vérifier directement les détails complets de la mise en œuvre de Zero-Knowledge/E2EE.
  • SHOULD: utilisez la page d'état pour regrouper les liens de preuves, tandis que les champs de preuves de réclamation doivent pointer directement vers la source tierce d'origine.

12.1 Types de preuves et portée

12.1.1 Ce qui peut être vérifié

Les preuves de tiers vérifient généralement :

  • Configuration de la couche de transport: versions TLS, chaînes de certificats, suites de chiffrement, HSTS, etc. (en fonction des capacités du scanner).
  • Politiques de sécurité HTTP: Existence et configuration de base des en-têtes comme CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy, etc.
  • Surface Web publiquement visible: erreurs de configuration courantes, points de terminaison exposés et scores de sécurité de base.

12.1.2 Ce qui ne peut pas être directement vérifié

Les preuves de tiers ne peuvent généralement pas vérifier directement :

  • Exactitude sans connaissance: Par exemple, « Le serveur ne peut pas accéder au CEK », les flux de chiffrement côté client et les détails de dérivation de clé.
  • Opérations internes et contrôle d'accès: Par exemple, les autorisations internes, les flux de travail de gestion des clés, la désinfection des journaux et l'audit des accès.
  • Sécurité absolue: Les analyses couvrent uniquement leurs ensembles de règles spécifiques et leurs surfaces visibles ; ils ne remplacent pas l’ingénierie de sécurité continue et la réponse aux incidents.

Par conséquent, ce livre blanc fait la distinction entre les « lignes de base de sécurité visibles » et les « limites de protocole/implémentation » : Les lignes de base visibles sont vérifiables via les preuves ; Les limites Zero-Knowledge/E2EE sont régies par les spécifications du protocole et les contraintes du client (voir le chapitre 5 et les sections associées).

12.2 Page d'état en tant que hub d'agrégation

FileBolt utilise /status en tant que centre d'agrégation des liens de preuves. Il ne remplace pas les rapports tiers eux-mêmes mais fournit une navigation unifiée permettant aux utilisateurs et aux auditeurs d'effectuer des vérifications répétées.

  • MUST: Les liens de preuves sur la page de statut pointent vers des sources tierces faisant autorité (reproductibles).
  • SHOULD: La page d'état peut indiquer « Date/horodatage de dernière vérification », mais ne doit pas présenter cela comme une conclusion permanente et immuable.
  • SHOULD: Si des chemins spécifiques (par exemple, des pages de téléchargement/déchiffrement) utilisent des en-têtes plus stricts, des preuves au niveau du chemin peuvent être fournies sur la page d'état (si prises en charge par des outils tiers).

12.3 Preuve de configuration TLS

La preuve TLS vérifie la configuration HTTPS, les versions de protocole, les chaînes de certificats et les attributs visibles. Les exemples incluent :

Note: Les preuves TLS reflètent la configuration visible au « moment de l'analyse » ; cela ne prouve pas les limites du contenu de bout en bout ni si le serveur peut accéder au CEK.

12.4 Preuve des en-têtes de sécurité

Les preuves d'en-tête de sécurité vérifient l'existence et la configuration de politiques de base telles que CSP, Referrer-Policy, X-Frame-Options, Permissions-Policy, etc.

Recommendation: Si les pages de téléchargement/décryptage (par ex. /transfer, /d/**) utilisent des politiques plus strictes, la documentation interne doit indiquer « Les chemins critiques sont plus stricts » et, lorsque cela est possible, les outils prenant en charge les analyses de chemins spécifiques doivent être sélectionnés comme preuve supplémentaire.

12.5 Analyses complètes des meilleures pratiques

Des analyses complètes couvrent des contrôles plus larges des meilleures pratiques (par exemple, la configuration HTTP, les faiblesses courantes, les combinaisons de mise en cache et de politiques de sécurité). Ceux-ci fournissent une vérification auxiliaire des références du site mais ne sont pas équivalents aux audits de mise en œuvre du protocole.

12.6 Principes de cartographie : identifiants de preuves et de réclamations

  • MUST: Chaque réclamation vérifiable (réclamation) a un identifiant unique et un ancrage stable dans la liste principale des identifiants de réclamation.
  • MUST: Le champ Preuve d'une réclamation pointe uniquement vers des sources faisant autorité (pages de rapport tiers ou pages officielles reproductibles) et NE DOIT PAS pointez vers des captures d’écran, des résumés ou des republications ne faisant pas autorité.
  • SHOULD: La page d'état peut servir de « collection de navigation » pour les preuves, mais le champ de preuve principal d'une réclamation doit, dans la mesure du possible, pointer vers la source tierce d'origine.
  • MUST: Le libellé des allégations doit s'aligner sur la portée des preuves, en évitant d'exagérer les « lignes de base visibles » en les qualifiant de « garanties de sécurité absolues ».

Liste principale des identifiants de réclamation (autorité unique) : /security-privacy-appendix-claim-ids

12.7 Temporalité et langage normatif

Les résultats des analyses tierces changent au fil du temps (en raison des mises à jour des règles d'analyse, des modifications de la configuration du site, de la rotation des certificats, etc.). Les références aux preuves doivent utiliser une formulation « vérifiable mais non absolue ».

  • SHOULD: Enregistrez la « Date/heure de la dernière vérification » (le cas échéant) sur la page d'état ou la documentation et permettez aux utilisateurs d'effectuer une vérification répétée.
  • MUST: Évitez la formulation « permanente/absolue » ; utilisez un langage correspondant à la portée de la preuve, tel que « L'analyse indique activé/conforme ».
  • SHOULD: Lorsque les politiques de sécurité critiques changent (par exemple, renforcement du CSP, mises à jour TLS), enregistrez-le dans le journal des modifications et associez les ID de réclamation pertinents.

12.8 ID de réclamation associés (réservé)

Ce chapitre couvre les « Preuves tierces et principes de cartographie ». Les ID de réclamation correspondants sont conservés dans le Annexe : Liste principale des identifiants de réclamation comme seule source faisant autorité.