Logo

Whitepaper de segurança e privacidade (visão geral)Capítulo 12

Capítulo 12: Evidências verificáveis por terceiros e página de status

Além das nossas declarações de projeto internas, o FileBolt oferece evidências de terceiros reproduzíveis publicamente (Evidence) para verificar propriedades de segurança visíveis (como a configuração de TLS, as políticas de cabeçalhos de segurança etc.). Este capítulo define os tipos de evidência, o escopo aplicável, os links de acesso e os princípios para mapear evidências para IDs de afirmação.

12.0 Resumo

  • SHOULD: Disponibilizar links públicos e reproduzíveis de evidências de terceiros para verificar as linhas de base de segurança visíveis (TLS, cabeçalhos etc.).
  • MUST: Os links de evidência apontam apenas para fontes autoritativas, nunca para capturas de tela ou republicações secundárias.
  • MUST: Definir explicitamente o escopo da evidência: varreduras externas não conseguem verificar diretamente todos os detalhes de implementação do conhecimento zero/E2EE.
  • SHOULD: Usar a página de status para agregar os links de evidência, enquanto os campos de evidência das afirmações devem apontar diretamente para a fonte original de terceiros.

12.1 Tipos e escopo das evidências

12.1.1 O que pode ser verificado

As evidências de terceiros normalmente verificam:

  • Configuração da camada de transporte: versões do TLS, cadeias de certificados, conjuntos de cifras, HSTS etc. (dependendo dos recursos do scanner).
  • Políticas de segurança HTTP: existência e configuração básica de cabeçalhos como CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy etc.
  • Superfície da Web publicamente visível: configurações incorretas comuns, endpoints expostos e pontuações de segurança de linha de base.

12.1.2 O que não pode ser verificado diretamente

As evidências de terceiros normalmente não conseguem verificar diretamente:

  • Correção do conhecimento zero: por exemplo, “o servidor não pode acessar a CEK”, os fluxos de criptografia no cliente e os detalhes da derivação de chaves.
  • Operações internas e controle de acesso: por exemplo, permissões internas, fluxos de gerenciamento de chaves, sanitização de logs e auditoria de acesso.
  • Segurança absoluta: as varreduras cobrem apenas seus conjuntos de regras específicos e as superfícies visíveis; elas não substituem a engenharia de segurança contínua nem a resposta a incidentes.

Por isso, este whitepaper distingue entre “linhas de base de segurança visíveis” e “limites de protocolo/implementação”: as linhas de base visíveis podem ser verificadas por meio de evidências; os limites de conhecimento zero/E2EE são regidos por especificações de protocolo e restrições do cliente (veja o Capítulo 5 e as seções relacionadas).

12.2 Página de status como hub de agregação

O FileBolt usa /status como hub de agregação dos links de evidência. Ela não substitui os relatórios de terceiros em si, mas oferece uma navegação unificada para que usuários e auditores façam verificações repetidas.

  • MUST: Os links de evidência na página de status apontam para fontes autoritativas de terceiros (reproduzíveis).
  • SHOULD: A página de status pode indicar “data/hora da última verificação”, mas não deve apresentá-la como uma conclusão permanente e imutável.
  • SHOULD: Se caminhos específicos (por exemplo, as páginas de download/descriptografia) usarem cabeçalhos mais rigorosos, pode-se fornecer na página de status uma evidência em nível de caminho (se houver suporte nas ferramentas de terceiros).

12.3 Evidência da configuração de TLS

A evidência de TLS verifica a configuração do HTTPS, as versões do protocolo, as cadeias de certificados e os atributos visíveis. Exemplos:

Observação: A evidência de TLS reflete a configuração visível no “momento da varredura”; ela não prova os limites de conteúdo de ponta a ponta nem se o servidor pode acessar a CEK.

12.4 Evidência dos cabeçalhos de segurança

A evidência dos cabeçalhos de segurança verifica a existência e a configuração de políticas de linha de base como CSP, Referrer-Policy, X-Frame-Options, Permissions-Policy etc.

Recomendação: Se as páginas de download/descriptografia (por exemplo, /transfer, /d/**) usarem políticas mais rigorosas, a documentação interna deve registrar que “os caminhos críticos são mais rigorosos” e, sempre que possível, devem ser escolhidas ferramentas que permitam varreduras de caminhos específicos como evidência complementar.

12.5 Varreduras abrangentes de boas práticas

As varreduras abrangentes cobrem verificações mais amplas de boas práticas (por exemplo, configuração HTTP, fraquezas comuns, combinações de cache e políticas de segurança). Elas oferecem verificação auxiliar das linhas de base do site, mas não equivalem a auditorias da implementação do protocolo.

12.6 Princípios de mapeamento: evidências e IDs de afirmação

  • MUST: Toda declaração verificável (afirmação) tem um ID exclusivo e uma âncora estável na Lista mestre de IDs de afirmação.
  • MUST: O campo de evidência de uma afirmação aponta apenas para fontes autoritativas (páginas de relatórios de terceiros ou páginas oficiais reproduzíveis) e MUST NOT apontar para capturas de tela, resumos ou republicações não autoritativas.
  • SHOULD: A página de status pode servir como uma “coleção de navegação” das evidências, mas o campo principal de evidência de uma afirmação deve apontar, sempre que possível, para a fonte original de terceiros.
  • MUST: A redação da afirmação deve estar alinhada ao escopo da evidência, evitando exagerar “linhas de base visíveis” como “garantias de segurança absoluta”.

Lista mestre de IDs de afirmação (autoridade única): /security-privacy-appendix-claim-ids

12.7 Temporalidade e linguagem normativa

Os resultados de varreduras de terceiros mudam com o tempo (por atualização das regras do scanner, mudanças na configuração do site, rotação de certificados etc.). As referências às evidências devem usar a formulação “verificável, mas não absoluta”.

  • SHOULD: Registrar a “data/hora da última verificação” (se aplicável) na página de status ou na documentação e permitir que os usuários repitam a verificação.
  • MUST: Evitar termos “permanente/absoluto”; usar uma linguagem compatível com o escopo da evidência, como “a varredura indica habilitado/em conformidade”.
  • SHOULD: Quando políticas de segurança críticas mudarem (por exemplo, endurecimento da CSP, atualizações de TLS), registrar isso no Changelog e vincular os IDs de afirmação relevantes.

12.8 IDs de afirmação relacionados (reservado)

Este capítulo trata de “evidências de terceiros e princípios de mapeamento”. Os IDs de afirmação correspondentes são mantidos no Apêndice: Lista mestre de IDs de afirmação, que é a única fonte autoritativa.