Informe técnico sobre seguridad y privacidad (descripción general)Capítulo 12
Capítulo 12: Página de estado y evidencia verificable por terceros
Más allá de nuestras afirmaciones de diseño interno, FileBolt proporciona evidencia de terceros reproducible públicamente (Evidencia) para verificar las propiedades de seguridad visibles. (como configuración TLS, políticas de encabezado de seguridad, etc.). Este capítulo define los tipos de evidencia, el alcance aplicable, los enlaces de entrada y los principios para asignar evidencia a los ID de reclamo.
12.0 Resumen
- SHOULD: proporcione enlaces de evidencia de terceros públicos y reproducibles para verificar líneas de base de seguridad visibles (TLS, encabezados, etc.).
- MUST: Los enlaces de evidencia apuntan únicamente a fuentes autorizadas, nunca a capturas de pantalla o publicaciones secundarias.
- MUST: Defina explícitamente el alcance de la evidencia: los escaneos externos no pueden verificar directamente los detalles completos de la implementación de Conocimiento Cero/E2EE.
- SHOULD: utilice la página de estado para agregar enlaces de evidencia, mientras que los campos de evidencia de reclamación deben apuntar directamente a la fuente original de terceros.
12.1 Tipos de evidencia y alcance
12.1.1 Qué se puede verificar
La evidencia de terceros generalmente verifica:
- Configuración de la capa de transporte: Versiones TLS, cadenas de certificados, conjuntos de cifrado, HSTS, etc. (dependiendo de las capacidades del escáner).
- Políticas de seguridad HTTP: Existencia y configuración básica de encabezados como CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy, etc.
- Superficie web públicamente visible: Errores de configuración comunes, puntos finales expuestos y puntuaciones de seguridad básicas.
12.1.2 Lo que no se puede verificar directamente
Por lo general, la evidencia de terceros no puede verificar directamente:
- Corrección del conocimiento cero: Por ejemplo, "El servidor no puede acceder a CEK", flujos de cifrado del lado del cliente y detalles de derivación de claves.
- Operaciones internas y control de acceso: Por ejemplo, permisos internos, flujos de trabajo de administración de claves, desinfección de registros y auditoría de acceso.
- Seguridad absoluta: Los escaneos solo cubren sus conjuntos de reglas específicos y superficies visibles; no reemplazan la ingeniería de seguridad continua y la respuesta a incidentes.
Por lo tanto, este documento técnico distingue entre "líneas de base de seguridad visibles" y "límites de protocolo/implementación": Las líneas de base visibles son verificables mediante evidencia; Los límites del conocimiento cero/E2EE se rigen por las especificaciones del protocolo y las restricciones del cliente (consulte el Capítulo 5 y secciones relacionadas).
12.2 Página de estado como centro de agregación
Usos de FileBolt /status como centro de agregación de enlaces de evidencia. No reemplaza los informes de terceros en sí, pero proporciona navegación unificada para que los usuarios y auditores realicen verificaciones repetidas.
- MUST: Los enlaces de evidencia en la página de estado apuntan a fuentes autorizadas de terceros (reproducibles).
- SHOULD: La página de estado puede indicar "Última fecha/marca de tiempo verificada", pero no debe presentar esto como una conclusión permanente e inmutable.
- SHOULD: Si rutas específicas (por ejemplo, páginas de descarga/descifrado) emplean encabezados más estrictos, se puede proporcionar evidencia a nivel de ruta en la página de estado (si es compatible con herramientas de terceros).
12.3 Evidencia de configuración TLS
La evidencia TLS verifica la configuración HTTPS, las versiones del protocolo, las cadenas de certificados y los atributos visibles. Los ejemplos incluyen:
- Índice de la página de estado: /status#tls-configuration
- Fuente de terceros autorizada (ejemplo): Informe TLS de SSL Labs
Note: La evidencia TLS refleja la configuración visible en el "momento del escaneo"; no prueba los límites del contenido de un extremo a otro ni si el servidor puede acceder a la CEK.
12.4 Evidencia de encabezados de seguridad
La evidencia del encabezado de seguridad verifica la existencia y configuración de políticas de referencia como CSP, política de referencia, opciones de marco X, política de permisos, etc.
- Índice de la página de estado: /status#security-headers
- Fuente de terceros (ejemplo): Informe de encabezados de seguridad
Recommendation: Si las páginas de descarga/descifrado (por ejemplo, /transfer, /d/**) utilizan políticas más estrictas, la documentación interna debe indicar "Las rutas críticas son más estrictas" y, cuando sea posible, se deben seleccionar herramientas que admitan exploraciones de rutas específicas como evidencia complementaria.
12.5 Análisis completos de mejores prácticas
Los análisis completos cubren comprobaciones más amplias de mejores prácticas (por ejemplo, configuración HTTP, debilidades comunes, combinaciones de políticas de seguridad y almacenamiento en caché). Estos proporcionan verificación auxiliar para las líneas base del sitio, pero no son equivalentes a las auditorías de implementación del protocolo.
- Índice de la página de estado: /status#http-observatory
- Fuente de terceros (ejemplo): Observatorio Mozilla
12.6 Principios de mapeo: evidencia e identificación de reclamos
- MUST: Cada reclamo verificable (Reclamo) tiene una identificación única y un ancla estable en la Lista maestra de ID de reclamo.
- MUST: El campo Evidencia de una Reclamación apunta únicamente a fuentes autorizadas (páginas de informes de terceros o páginas oficiales reproducibles) y NO DEBE señale capturas de pantalla, resúmenes o publicaciones no autorizadas.
- SHOULD: La página de estado puede servir como una "colección de navegación" para la evidencia, pero el campo de evidencia principal de un reclamo debe apuntar a la fuente original de terceros siempre que sea posible.
- MUST: La redacción de la afirmación debe alinearse con el alcance de la evidencia, evitando exagerar las "líneas de base visibles" como "garantías absolutas de seguridad".
Lista maestra de ID de reclamaciones (autoridad única): /security-privacy-appendix-claim-ids
12.7 Temporalidad y lenguaje normativo
Los resultados del análisis de terceros cambian con el tiempo (debido a actualizaciones de las reglas del análisis, cambios en la configuración del sitio, rotación de certificados, etc.). Las referencias a la evidencia deben utilizar frases "verificables pero no absolutas".
- SHOULD: Registre la "Fecha/Hora de la última verificación" (si corresponde) en la página de estado o la documentación y permita a los usuarios realizar una verificación repetida.
- MUST: Evite la redacción "permanente/absoluta"; utilice un lenguaje que coincida con el alcance de la evidencia, como "El escaneo indica habilitado/compatible".
- SHOULD: Cuando las políticas de seguridad críticas cambian (por ejemplo, endurecimiento de CSP, actualizaciones de TLS), regístrelo en el registro de cambios y vincule los ID de reclamo relevantes.
12.8 ID de reclamaciones relacionadas (reservadas)
Este capítulo cubre "Principios de mapeo y evidencia de terceros". Los ID de reclamo correspondientes se mantienen en el Apéndice: Lista maestra de ID de reclamaciones como única fuente autorizada.