Logo

Artigo sobre segurança e privacidade (visão geral)Capítulo 12

Capítulo 12: Página de status e evidências verificáveis de terceiros

Além de nossas reivindicações de design interno, o FileBolt fornece evidências de terceiros reproduzíveis publicamente (Evidência) para verificar propriedades de segurança visíveis (como configuração TLS, políticas de cabeçalho de segurança, etc.). Este capítulo define tipos de evidências, escopo aplicável, links de entrada e princípios para mapear evidências para IDs de reivindicação.

12.0 Resumo

  • SHOULD: forneça links de evidências de terceiros públicos e reproduzíveis para verificar linhas de base de segurança visíveis (TLS, cabeçalhos, etc.).
  • MUST: os links de evidências apontam apenas para fontes confiáveis, nunca para capturas de tela ou republicações secundárias.
  • MUST: defina explicitamente o escopo da evidência: varreduras externas não podem verificar diretamente detalhes completos da implementação do Zero-Knowledge/E2EE.
  • SHOULD: use a página de status para agregar links de evidências, enquanto os campos de evidências de reivindicação devem apontar diretamente para a fonte original de terceiros.

12.1 Tipos e escopo de evidências

12.1.1 O que pode ser verificado

Evidências de terceiros normalmente verificam:

  • Configuração da camada de transporte: Versões TLS, cadeias de certificados, conjuntos de criptografia, 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 básicas.

12.1.2 O que não pode ser verificado diretamente

Evidências de terceiros normalmente não podem verificar diretamente:

  • Correção de conhecimento zero: por exemplo, "O servidor não pode acessar CEK", fluxos de criptografia do lado do cliente e detalhes de derivação de chave.
  • Operações Internas e Controle de Acesso: por exemplo, permissões internas, fluxos de trabalho de gerenciamento de chaves, limpeza de logs e auditoria de acesso.
  • Segurança Absoluta: as verificações cobrem apenas seus conjuntos de regras específicos e superfícies visíveis; eles não substituem a engenharia de segurança contínua e a resposta a incidentes.

Portanto, este whitepaper distingue entre "linhas de base de segurança visíveis" e "limites de protocolo/implementação": As linhas de base visíveis são verificáveis através de evidências; Os limites de Conhecimento Zero/E2EE são governados por especificações de protocolo e restrições de cliente (consulte o Capítulo 5 e seções relacionadas).

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

FileBolt usa /status como o centro de agregação para links de evidências. Ele não substitui os próprios relatórios de terceiros, mas fornece navegação unificada para usuários e auditores realizarem verificações repetidas.

  • MUST: links de evidências na página de status apontam para fontes confiáveis de terceiros (reproduzíveis).
  • SHOULD: a página de status pode indicar "Data/hora da última verificação", mas não deve apresentar isso como uma conclusão permanente e imutável.
  • SHOULD: se caminhos específicos (por exemplo, páginas de download/descriptografia) empregarem cabeçalhos mais rígidos, a evidência em nível de caminho poderá ser fornecida na página de status (se suportada por ferramentas de terceiros).

12.3 Evidência de configuração TLS

A evidência TLS verifica a configuração HTTPS, versões de protocolo, cadeias de certificados e atributos visíveis. Os exemplos incluem:

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

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

A evidência do cabeçalho de segurança verifica a existência e configuração de políticas básicas como CSP, Referrer-Policy, X-Frame-Options, Permissions-Policy, etc.

Recommendation: Se as páginas de download/descriptografia (por exemplo, /transfer, /d/**) usam políticas mais rigorosas, a documentação interna deve indicar "Os caminhos críticos são mais rigorosos" e, quando viável, as ferramentas que suportam verificações de caminhos específicos devem ser selecionadas como evidência suplementar.

12.5 Varreduras Abrangentes de Melhores Práticas

Varreduras abrangentes cobrem verificações mais amplas de práticas recomendadas (por exemplo, configuração HTTP, pontos fracos comuns, cache e combinações de políticas de segurança). Estas fornecem verificação auxiliar para linhas de base do local, mas não são equivalentes a auditorias de implementação de protocolo.

12.6 Princípios de Mapeamento: Evidências e IDs de Reclamações

  • MUST: toda reivindicação verificável (Reivindicação) possui um ID exclusivo e uma âncora estável na Lista Principal de IDs de Reivindicação.
  • MUST: o campo Evidência de uma reivindicação aponta apenas para fontes confiáveis (páginas de relatórios de terceiros ou páginas oficiais reproduzíveis) e NÃO DEVE apontam para capturas de tela, resumos ou republicações não oficiais.
  • SHOULD: a página de status pode servir como uma "coleção de navegação" para evidências, mas o campo principal de evidências de uma reivindicação deve apontar para a fonte original de terceiros sempre que possível.
  • MUST: A redação da reivindicação deve estar alinhada com o escopo das evidências, evitando exagerar "linhas de base visíveis" como "garantias de segurança absolutas".

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

12.7 Temporalidade e Linguagem Normativa

Os resultados da verificação de terceiros mudam com o tempo (devido a atualizações de regras do scanner, alterações na configuração do site, rotação de certificados, etc.). As referências às evidências devem usar a frase “verificável, mas não absoluta”.

  • SHOULD: registre a "data/hora da última verificação" (se aplicável) na página de status ou na documentação e permita que os usuários realizem a verificação repetida.
  • MUST: Evite palavras "permanentes/absolutas"; use linguagem que corresponda ao escopo da evidência, como "A verificação indica habilitada/compatível".
  • SHOULD: quando as políticas de segurança críticas mudam (por exemplo, reforço do CSP, atualizações do TLS), registre isso no Changelog e vincule os IDs de reivindicação relevantes.

12.8 IDs de reivindicação relacionadas (reservados)

Este capítulo aborda "Evidências de terceiros e princípios de mapeamento". Os IDs de reivindicação correspondentes são mantidos no Apêndice: Lista mestre de IDs de reivindicação como a única fonte autorizada.