Página de segurança do fornecedor: o que conferir antes de assinar

Toda empresa que vende tecnologia tem uma página de segurança, e quase todas dizem as mesmas coisas: criptografia, controle de acesso, conformidade. Quem homologa fornecedor não tem como auditar o que acontece dentro da casa do outro, mas tem como conferir o que ela publica, e boa parte do que se publica pode ser checada em minutos, de fora, sem pedir nada a ninguém.

Este roteiro serve para qualquer fornecedor, de identidade ou não, e parte de uma regra simples: afirmação que pode ser medida deve ser medida. A divergência entre o que a página diz e o que o servidor entrega vale mais do que qualquer selo. Ele complementa o roteiro geral para avaliar um fornecedor de KYC, com o foco na vitrine de segurança.

O arquivo de contato de segurança

A RFC 9116, publicada pela IETF em abril de 2022, padroniza um arquivo de texto chamado security.txt, servido no endereço /.well-known/security.txt do domínio, para dizer a quem encontra uma falha como avisar a empresa. Dois campos são obrigatórios: Contact, com um endereço de e-mail, um telefone ou uma página, e Expires, a data a partir da qual o conteúdo deve ser considerado velho. A RFC recomenda que essa data fique a menos de um ano no futuro e diz, na seção 5.3, que não ter o arquivo pode ser preferível a ter informação velha.

Três sinais de alerta aparecem em poucos segundos de leitura. O Expires vencido mostra que ninguém cuida do arquivo. O Expires anos à frente mostra que a recomendação de validade curta foi ignorada, o que costuma andar junto com contato desatualizado. E o campo Policy, que deveria apontar para a política de divulgação de vulnerabilidades, às vezes abre uma página que não fala de divulgação nenhuma, ou devolve erro. Uma política de verdade diz o que está no escopo e o que está fora, como relatar, o que o pesquisador pode esperar e quando a falha pode ser publicada.

A mesma RFC, na seção 2.3, recomenda assinar o arquivo com uma assinatura OpenPGP em texto claro. Quando a assinatura existe, confira se a chave pública está publicada no domínio da própria empresa.

O que a página afirma contra o que a resposta entrega

Muita página de segurança diz que o site usa HSTS, a política que obriga o navegador a falar com o domínio só por HTTPS. Conferir é simples: no navegador, a aba de rede das ferramentas de desenvolvedor mostra os cabeçalhos de cada resposta; no terminal, o comando curl -I seguido do endereço mostra os cabeçalhos da página pedida. Se a página afirma HSTS e a resposta não traz o cabeçalho Strict-Transport-Security, a afirmação não se sustenta. A documentação da MDN lembra um detalhe que pega muita gente: o navegador ignora esse cabeçalho quando ele chega por HTTP, então ele só conta na resposta HTTPS.

O OWASP Secure Headers Project mantém a lista dos cabeçalhos de resposta recomendados e dos que devem ser removidos, e a HTTP Security Response Headers Cheat Sheet, também da OWASP, explica cada um. Para uma aplicação que mostra dado pessoal, um conjunto razoável inclui Strict-Transport-Security, Content-Security-Policy com a diretiva frame-ancestors, X-Content-Type-Options com nosniff, X-Frame-Options, Referrer-Policy e Permissions-Policy.

Olhe mais de uma rota. A tela de login e a área logada importam mais do que a página inicial, e é comum a página de marketing estar protegida e a aplicação não. O cabeçalho X-Powered-By faz o caminho inverso: ele está na lista de remoção da OWASP porque entrega de graça a tecnologia do servidor a quem procura alvo.

Um encarregado, um endereço

A LGPD, no artigo 41, obriga o controlador a indicar um encarregado pelo tratamento de dados pessoais, e o parágrafo 1º manda divulgar a identidade e o contato dele "de forma clara e objetiva, preferencialmente no sítio eletrônico do controlador". A Resolução CD/ANPD nº 18, de julho de 2024, detalhou a regra: o artigo 8º exige manter essas informações atualizadas, e o artigo 9º pede que elas fiquem "em local de destaque e de fácil acesso" no site.

A conferência aqui é de consistência. Procure o contato do encarregado na política de privacidade, nos termos, no rodapé e na página de segurança. Dois endereços diferentes em canais oficiais que não se citam indicam que um deles está desatualizado, e o pedido de um titular pode acabar numa caixa que ninguém lê. Isso importa para quem contrata: quando o fornecedor atua como operador, o titular que procura por ele precisa achar o caminho certo, e a cláusula de cooperação no contrato de fornecedor só funciona se o canal do outro lado existir.

"Baseada em" não é "certificada"

Muita política de segurança diz que segue o NIST Cybersecurity Framework, o CSF. A versão 2.0 foi publicada pelo NIST em fevereiro de 2024, no documento CSWP 29, e organiza a gestão de risco em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. O próprio NIST afirma, nas perguntas frequentes do CSF, que não oferece certificação nem endosso de produtos, implementações ou serviços relacionados ao arcabouço, e que não há planos de criar um programa de avaliação de conformidade. Ou seja: "baseada no CSF" é um jeito legítimo de dizer como a política foi organizada, e "certificada no CSF" é uma frase que não corresponde a nada.

Com norma certificável a conversa é outra. A certificação ISO/IEC 27001 é emitida por um organismo certificador e tem número, escopo e validade. A certificação emitida por organismo acreditado pode ser conferida no IAF CertSearch, a base do International Accreditation Forum criada para validar o status desse tipo de certificação. Peça o número, o escopo e a validade, e confira. O escopo importa tanto quanto o certificado: uma certificação que cobre só a área administrativa não diz nada sobre a plataforma que vai tratar os seus dados.

Subprocessadores, DPA e status

Três documentos completam a vitrine. A lista de subprocessadores deve dizer, para cada terceiro que o fornecedor usa, o papel dele, que dado recebe e em que país; é ela que responde para onde o dado vai. O acordo de tratamento de dados, o DPA, é onde as medidas de segurança viram obrigação de contrato, e vale ler as ressalvas: um DPA honesto diz onde a proteção não alcança. A página de status, quando existe, deveria ficar fora da infraestrutura que ela monitora, senão cai junto no dia em que você mais precisa dela, e o roteiro para ler o SLA de um fornecedor mostra por que o número da disponibilidade sozinho não basta.

Na UNIFOKAL, por exemplo, esses documentos ficam reunidos numa central de confiança. Cada compromisso da política de segurança aponta para um teste automatizado ou um trecho de código que o sustenta, e essa ligação é conferida a cada entrega: se a contrapartida some, a entrega é reprovada.

Lista de conferência

• O /.well-known/security.txt existe, tem Contact e Expires, o Expires está no futuro e a menos de um ano, e o Policy abre uma política de divulgação de verdade.
• Os cabeçalhos que a página afirma aparecem na resposta HTTPS da página inicial, da tela de login e de uma rota da aplicação.
• O cabeçalho X-Powered-By não aparece em nenhuma delas.
• O contato do encarregado é o mesmo em todos os documentos públicos.
• Toda menção a arcabouço diz "baseada em", e toda certificação alegada tem número, organismo, escopo e validade que você consegue conferir.
• A lista de subprocessadores diz papel, dado e país, e o DPA traz as ressalvas por escrito.

Nenhum item exige acesso privilegiado nem questionário. Um fornecedor que não passa nesta lista dificilmente passa no questionário longo, e um que passa ganhou o direito de ser avaliado a fundo.

Fontes citadas

• RFC 9116, A File Format to Aid in Security Vulnerability Disclosure, de E. Foudil e Y. Shafranovich, IETF, abril de 2022, seções 2.3, 2.5.3, 2.5.5, 2.5.7 e 5.3: rfc-editor.org
• OWASP Secure Headers Project, listas de cabeçalhos a acrescentar e a remover: owasp.org
• OWASP, HTTP Security Response Headers Cheat Sheet: cheatsheetseries.owasp.org
• MDN Web Docs, da Mozilla, página de referência do cabeçalho Strict-Transport-Security: developer.mozilla.org
• Lei 13.709/2018, LGPD, artigo 41, parágrafo 1º: planalto.gov.br
• Resolução CD/ANPD nº 18, de 16 de julho de 2024, Regulamento sobre a atuação do encarregado, artigos 8º e 9º, publicada no Diário Oficial da União
• NIST, CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0, fevereiro de 2024: doi.org
• NIST, perguntas frequentes do Cybersecurity Framework: nist.gov
• International Accreditation Forum, IAF CertSearch, base de validação de certificação acreditada: iaf.nu