Política de segurança da informação

Tradução de cortesia. Prevalece a versão em inglês.

Esta política explica como a LFW protege os sistemas que administra e os sistemas dos clientes em que trabalha. Ela é escrita para quem faz uma revisão de segurança e descreve a prática, não a intenção.

Versão 1.0, 6 de outubro de 2026. Faz parte das práticas publicadas na página Confiança, junto com a política de controle de acesso, o plano de resposta a incidentes e a política de uso aceitável.

1. Escopo e responsável

A política cobre o LFW.com, o Portal do cliente em my.lfw.com, o site de administração da equipe, o servidor em que eles rodam, o equipamento de trabalho da LFW e o acesso da LFW aos sistemas dos clientes.

Leland Fiegel, fundador da LFW, é o responsável por esta política e o único integrante da equipe em 27 de setembro de 2026. Quando um controle depende de uma segunda pessoa, esta política diz isso em vez de dar a entender que ela existe.

2. Onde rodam os sistemas da LFW

As aplicações da LFW rodam em um servidor da Hetzner em Ashburn, na Virgínia, atrás da Cloudflare. O firewall do host só aceita tráfego web das faixas de endereços da Cloudflare, então o servidor não pode ser alcançado diretamente pela internet nas portas web.

O acesso SSH é feito só com chave; o login com senha e as senhas vazias são recusados. A aplicação, o banco de dados e o índice de busca escutam no endereço de loopback. O fail2ban bloqueia endereços após repetidas tentativas de login malsucedidas.

Os visitantes chegam ao site com TLS 1.3 e uma política HSTS de um ano; TLS 1.0 e 1.1 são recusados. O tráfego entre a Cloudflare e o servidor também é criptografado.

O site de administração da equipe e o Portal do cliente são origens separadas (admin.lfw.com e my.lfw.com). Um script injetado em uma página pública não consegue agir como um integrante da equipe ou um cliente autenticado, porque nenhum dos dois cookies de sessão chega ao site público.

3. A aplicação

Cada página envia uma política de segurança de conteúdo que autoriza scripts e estilos por hash, sem permitir scripts inline, junto com os cabeçalhos padrão: nenhuma detecção de tipo MIME, uma política de referenciador rigorosa e uma política de permissões que nega câmera, microfone e localização.

Toda escrita na aplicação é verificada pela origem de onde vem, e os endpoints públicos têm limite de requisições por endereço. O tipo dos arquivos enviados é determinado pelos bytes, nunca pelo que o remetente declara; SVGs são recusados; uma solicitação pode conter três arquivos de até oito megabytes cada.

Os links privados (relatórios, orçamentos, convites) usam tokens aleatórios de pelo menos 72 bits. Os segredos ficam em um único arquivo no servidor, restrito ao administrador do servidor e à conta de serviço. O repositório não contém segredos.

4. Construção e publicação

Cada versão é construída em um contêiner descartável que não contém chaves, nem arquivos privados, nem acesso ao servidor. Os scripts de instalação das dependências estão desativados; só dois pacotes nativos são recompilados, indicados pelo nome.

A compilação falha em caso de erro de lint, de erro de parede de texto ou de link quebrado, de regra de componente duplicada, de vulnerabilidade conhecida de gravidade alta em uma das duas árvores de dependências de produção, ou de teste reprovado.

Uma versão de dependência publicada há menos de sete dias é recusada. As versões comprometidas costumam ser retiradas nesse período: a espera é o controle.

Uma versão é ativada em um só passo, depois que a nova versão passa nas verificações das suas rotas públicas e protegidas, e a versão anterior é mantida para um eventual retorno.

5. Backups

O diretório de dados do servidor, os bancos de dados, os segredos e a configuração são salvos com o restic: criptografados e deduplicados, uma vez por dia e a cada publicação. Só o administrador do servidor pode ler os backups.

Cada banco de dados é copiado com o backup a quente do SQLite antes de ser arquivado, para que cada snapshot seja consistente. O repositório é verificado toda semana.

Retenção: os dez snapshots mais recentes, 30 diários, 26 semanais, 24 mensais e 10 anuais. Uma cópia criptografada do repositório também é guardada fora da conta de hospedagem, em um bucket privado do Cloudflare R2.

Os backups do site de um cliente são os da hospedagem. A LFW verifica periodicamente se estão sendo feitos e os usa para restaurar quando necessário, como prevê o anexo de gestão.

6. Registro e monitoramento

O servidor web registra cada requisição com o endereço de origem. O Portal do cliente mantém um histórico somente de inclusão das alterações em solicitações e documentos, registra cada visualização de uma conta de cliente pela equipe e registra cada token de acesso no momento do uso, para que nenhum possa ser reutilizado.

O LFW Monitor verifica o LFW.com todos os dias como verifica os sites dos clientes: acessibilidade, links quebrados, velocidade, TLS, registros de autenticação de e-mail, política de segurança de conteúdo e outros cabeçalhos de segurança. A disponibilidade é verificada a cada minuto, e o rodapé de cada página a mostra.

No site de um cliente, o LFW Activity Logger registra quem alterou o quê no WordPress e quando, para que um incidente possa ser reconstruído junto com os logs de acesso da hospedagem.

7. Sites dos clientes

A LFW só assume um site se houver três itens: hospedagem gerenciada em nome do cliente, um firewall dentro do WordPress (Wordfence Premium) licenciado para o site, e a Cloudflare na frente da hospedagem com o firewall de aplicação e a proteção contra ataques DDoS ativados.

O núcleo do WordPress, os temas e os plugins são atualizados todo mês a partir do controle de versão, com verificações automáticas após cada publicação. Uma versão de segurança é aplicada antes do ciclo mensal. Entre uma atualização e outra, os firewalls bloqueiam os ataques conhecidos, inclusive contra uma falha publicada antes de existir a correção.

8. Revisão dos sistemas da LFW

A LFW examinou o LFW.com, os seus endpoints, o servidor, o DNS e a autenticação de e-mail, junto com o repositório, em 16 de setembro de 2026, por inspeção e verificações não autenticadas dos próprios recursos. Não foi encontrada nenhuma vulnerabilidade explorável por um visitante não autenticado.

O único apontamento moderado, permissões de arquivo que deixavam uma segunda conta de serviço do host ler os bancos de dados da LFW, foi corrigido no mesmo dia e agora é verificado por um teste. Os outros apontamentos eram pontos de reforço, aceitos como estão, e estão registrados de forma confidencial.

Ainda não foi contratado nenhum teste de intrusão independente dos sistemas da LFW. Quando o contrato de um cliente prevê um para o site do cliente, a LFW o organiza e informa o resultado.

9. Relatar um problema

Os relatos de segurança vão para security@lfw.com, indicado em security.txt (em inglês). A política de divulgação de vulnerabilidades, com o seu escopo, as suas regras e o seu compromisso de não tomar medidas judiciais, está publicada em lfw.com/security.

Uma pessoa responde em até dois dias úteis. Horário comercial: De segunda a sexta, das 9h às 17h, horário da costa leste dos EUA (das 6h às 14h no Pacífico), exceto feriados federais. Não oferecemos atendimento fora desse horário nem plantão.

10. O que esta política não afirma

A LFW não tem nenhum relatório SOC 2 ou ISO 27001 e não declara conformidade com nenhum framework específico. Não declara criptografia de disco para o banco de dados de produção do seu servidor, nem criptografia validada pelo FIPS, nem um sistema de detecção de intrusão de rede.

Esta política muda de forma transparente: a versão e a data acima mudam quando ela muda, e o texto anterior fica no histórico do repositório.