Nos últimos meses, a Casa Hacker fez um trabalho de endurecimento das nossas plataformas. Hardening, no jargão. Na prática: apertar o que estava frouxo e fechar o que estava aberto por hábito.
Foi de ponta a ponta — dos servidores que a gente usa todo dia até treinamento de equipe e mudanças consideráveis nos sistemas. Não foi manutenção. Foi condição.
Condição porque a gente queria avançar com nossos planos de inteligência artificial e de computação cognitiva, e não dava para fazer isso sobre uma base que ninguém tinha revisado. Uma plataforma de IA construída em cima de alicerce frouxo não é uma plataforma de IA. É um risco com interface bonita.
Então a ordem foi essa: primeiro a casa, depois o que a gente quer colocar dentro dela. Segurança e privacidade desde a concepção — não como camada aplicada no fim, porque camada aplicada no fim é remendo, e remendo se descola.
A Casa Hacker defende proteção de dados há anos. Sobretudo a do titular: a pessoa de quem o dado é. Isso não é postura de comunicação. É a forma como a Lei Geral de Proteção de Dados foi concebida, e a gente concorda com ela.
E se a gente acha a LGPD importante a ponto de defendê-la para fora, o mínimo é implementá-la aqui dentro. Etapa por etapa. Inclusive as etapas chatas, as que ninguém vê e que não rendem publicação nenhuma.
O que “criptografado” quer dizer aqui
Toda conversa entre o mundo lá fora e a Casa Hacker passa cifrada, por uma entrada só. Não existe segunda porta, nem atalho para um sistema específico, nem exceção “só por enquanto” — que é o tipo de exceção que fica.
Depois da porta, nossos sistemas conversam entre si sem tocar a internet. Eles falam dentro da própria máquina.
E tem a outra metade, a que quase ninguém pergunta: o dado parado. Nossos bancos e os arquivos sensíveis vivem dentro de um volume cifrado. Se alguém levasse o disco embora, levaria ruído.
As cópias
O que a gente guarda é copiado para fora do Brasil todos os dias: três países, em três continentes. Cifrado antes de sair — nome do arquivo e conteúdo. Quem interceptasse não saberia nem como o arquivo se chama.
Duas decisões aí dentro merecem ser ditas, porque as duas custam.
O servidor cifra as próprias cópias e não consegue lê-las de volta. A chave não mora nele. Quem comprometer o servidor não lê o histórico. O preço é que a gente passou a depender de uma custódia de chave guardada fora dali: perdeu a chave, perdeu o backup. Assumimos esse risco de olhos abertos, porque o outro risco é pior.
As cópias podem ser escritas, nunca apagadas. Alguém com controle total do servidor não consegue apagar o que já foi guardado. É a diferença entre ter backup e ter backup que sobrevive exatamente ao dia em que você precisa dele.
Guardar não basta. Tem que ensaiar a volta.
Backup que nunca foi testado é fé, não é backup.
Toda semana um processo automático vai até uma das cópias mais distantes, baixa de verdade — pela internet, como faria num dia ruim — e confere se o pacote está íntegro e se abre com a chave certa.
Sendo exatos sobre o que esse ensaio prova e o que ele não prova: ele prova que a cópia existe fora daqui, que chega inteira e que é legível por quem tem a chave. Ele não é uma restauração completa do sistema em pé. Essa continua sendo um exercício com mão humana. A gente escreve isso porque “temos backup testado” é uma frase que muita organização usa quando o que testou foi o exit code de um script.
Confiança zero — inclusive na gente
O nome disso é zero trust, confiança zero. Não é invenção nossa: o conceito nasceu numa consultoria americana em 2010, virou norma técnica publicada pelo instituto de padrões dos Estados Unidos e hoje é prática corrente de segurança. O que ele diz é simples e desconfortável — estar dentro não é credencial.
Na prática, aqui: todo acesso a dado é registrado, e quem acessa precisa continuar provando que é quem diz ser. Não é login uma vez de manhã e livre-trânsito até a noite. É identificação a cada vez, com mais de um fator — e um desses fatores passa por uma plataforma que só existe para gente da Casa Hacker.
Esse último detalhe é o que mais reduz o risco que não é técnico. A maior parte dos ataques bem-sucedidos hoje não arromba nada: convence alguém. Um fator que não pode ser pedido por telefone, nem colado num chat, nem reproduzido por quem imita bem um crachá tira a engenharia social do jogo em boa parte dos casos.
Quem sustenta isso na nossa borda é a plataforma de acesso da Cloudflare. Nossos painéis administrativos internos não ficam protegidos apenas pela senha da própria aplicação: ficam atrás de uma checagem de identidade que acontece antes de a requisição chegar ao sistema. Quem não passa nessa checagem nunca conversa com a aplicação — ela nem toma conhecimento da tentativa.
A identidade vem do nosso diretório corporativo, não de um cadastro paralelo. Isso importa mais do que parece: quando alguém sai da organização, desligar a conta corporativa fecha o acesso a tudo de uma vez. Não existe aquela lista de sistemas em que a pessoa “também tinha login” — a lista que ninguém encontra justamente no dia em que precisa dela.
A sessão expira. Acesso concedido não é acesso permanente. E conta de máquina — a que um programa usa para falar com outro — tem regra própria, separada da de gente. Tratar programa e pessoa com a mesma régua é como se perde o controle dos dois.
O equipamento também entra na conta. Os dispositivos da equipe são inscritos com um perfil definido pela organização, e esse perfil não é negociável na máquina da pessoa: não dá para desligar a proteção porque naquele dia ela incomodou. Segurança que o próprio usuário desativa em dois cliques é sugestão, não é controle.
Cada pessoa vê o que o trabalho dela exige
Ninguém aqui tem acesso a tudo. Cada pessoa tem um papel, e o papel define o que ela alcança — o nome técnico é segregação de funções, ou controle de acesso baseado em papéis.
Isso é chato. É chato de verdade: gera pedido de acesso, gera espera, gera “não consigo abrir isso”. A gente escolheu o chato. Acesso amplo é confortável até o dia em que uma única conta comprometida vira a organização inteira.
A borda: o Projeto Galileo
Tem uma coisa que precisa ser dita sem falsa modéstia: organizações como a nossa são atacadas. Não por acaso, e não porque temos dinheiro — mas por causa do que a gente diz, de quem a gente atende e de onde a gente está. Sociedade civil, jornalismo, direitos humanos e educação em território periférico entram na mira com regularidade. E quase nenhuma organização desse campo tem orçamento para segurança de porte empresarial.
O Projeto Galileo, da Cloudflare, existe exatamente por causa desse desencontro. Criado em 2014, ele dá gratuitamente proteção de nível empresarial a organizações de interesse público em situação de vulnerabilidade. A Casa Hacker faz parte dele.
Na prática, isso mudou o desenho da nossa borda — a fronteira entre a internet e a gente. Vale explicar o que cada peça faz, porque “estamos protegidos pela Cloudflare” não quer dizer nada sozinho.
O ataque não chega. Contra ataque de negação de serviço — aquele que derruba um site pelo volume, não pela falha —, a defesa não é aguentar o tranco. É o tranco não chegar. O tráfego malicioso é absorvido numa rede distribuída pelo mundo, com capacidade que a gente jamais teria e nem faria sentido tentar ter. Nosso servidor não fica mais forte: ele fica fora do caminho.
Só passa o que é legítimo. Toda requisição que chega é inspecionada antes de ser encaminhada. Requisição que carrega padrão de ataque conhecido morre na borda, não no nosso servidor. O que sustenta a máquina não é a nossa capacidade de resistir a um pedido malicioso — é ele nunca ter sido entregue.
O DNS também é uma porta — e ela abre para os dois lados. Quase todo mundo pensa em segurança como quem vigia a entrada. Mas um equipamento comprometido não é perigoso porque alguém entra por ele: é perigoso porque ele tenta sair, procurando o servidor de quem o infectou. A gente usa filtragem de DNS monitorada justamente aí. Antes de qualquer conexão existir, na hora em que um nome vira endereço, destinos reconhecidamente maliciosos são bloqueados. É a defesa mais barata e mais subestimada que existe: ela age antes do ataque ter para onde ligar.
A política anda junto com a pessoa, não com o escritório. Os equipamentos da equipe rodam o cliente da plataforma de acesso da Cloudflare. Isso significa que as mesmas regras valem no escritório, em casa, num coworking ou no celular no ônibus. É o oposto do modelo antigo, em que a rede do escritório era “o lugar seguro” e todo o resto era exceção — modelo que morreu, e que muita organização ainda finge que está vivo.
Um firewall de aplicação que a gente audita todo dia. Filtro de segurança tem um efeito colateral clássico: barrar gente de verdade. Um formulário que não envia, um anexo que falha, uma pessoa que desiste. E ninguém fica sabendo, porque quem foi barrado por engano não abre chamado — vai embora.
Por isso o nosso filtro não fica só ligado: ele é auditado. Todo dia um processo automático examina o que foi bloqueado nas últimas horas e separa o que era ataque do que pode ter sido alguém legítimo, e o resultado cai num canal interno onde a equipe vê. Se esse monitor emudece, isso conta como incidente — monitor calado é indistinguível de “está tudo bem”.
Essa distinção é a diferença entre segurança e obstrução. Bloquear é fácil. Saber quem você bloqueou por engano é o trabalho.
Anti-robô sem pedágio para quem é gente. Nossas telas públicas — inclusive o canal de denúncias — usam uma verificação anti-robô que funciona sem quebra-cabeça, sem “clique em todos os semáforos” e sem rastrear a pessoa pela internet afora. Isso não é conforto: um canal de denúncia precisa resistir a inundação automatizada e, ao mesmo tempo, não pode cobrar de quem denuncia o preço de ser identificado. Conciliar as duas coisas era difícil até pouco tempo atrás.
Duas peças discretas fecham o bloco. Nosso domínio é assinado criptograficamente, o que impede que alguém convença a internet de que o endereço da Casa Hacker é outro servidor. E a conexão só acontece em versões modernas do protocolo de cifra, com a própria borda conferindo o certificado do nosso servidor antes de falar com ele. Ninguém entra no meio dessa conversa.
Repare que essa última peça é a mesma ideia da seção anterior. Confiança zero não é um produto que se compra: é a decisão de não ter lugar privilegiado. A borda é onde essa decisão vira configuração.
A gente não economiza em segurança
Essa é uma escolha orçamentária, e ela aparece nas ferramentas.
Nossa infraestrutura roda em Red Hat Enterprise Linux 10. Não é o sistema mais barato de operar, e não é o mais fácil. É o que tem ciclo de vida longo e previsível, correção de segurança com prazo e responsável, política criptográfica gerenciada de forma central e um ecossistema de conformidade que permite auditar a máquina contra um padrão externo em vez de contra a nossa própria opinião.
E boa parte do que a gente desenvolve — inclusive o sistema onde vivem os dados sensíveis da organização — é escrito em Rust. A razão é direta e não é moda: uma parcela enorme das falhas graves de segurança da história do software vem de erros de manuseio de memória, e o Rust foi desenhado para tornar essa classe inteira de erro impossível de compilar. É segurança que não depende de a pessoa que escreveu estar atenta naquele dia.
Custa mais caro em tempo de desenvolvimento. É uma linguagem exigente, que discute com quem escreve. A gente aceita essa discussão, porque ela acontece antes do código ir para produção — e não depois, com dado de gente real no meio.
Uma organização social escolher a ferramenta mais robusta em vez da mais barata é uma decisão política sobre a quem esses dados pertencem.
Software seguro desde onde ele nasce
Segurança de plataforma não começa no servidor. Começa em como o software chega até ele.
Aqui, três princípios governam isso.
Por padrão, nada roda. A configuração do nosso servidor recusa qualquer imagem de aplicação por princípio. Cada origem de software precisa estar explicitamente autorizada para poder ser executada, e as peças do sistema operacional só rodam se a assinatura criptográfica delas conferir com a chave do fabricante. A postura padrão é “não”, e cada “sim” foi uma decisão registrada.
Versão exata, não rótulo. As aplicações rodam numa versão identificada pela impressão digital do conteúdo, não por um apelido como “a mais recente”. Apelido muda debaixo do pé; impressão digital não. Isso significa que a gente sabe exatamente o que está rodando, e que uma atualização é sempre um ato deliberado — nunca uma surpresa que chegou de madrugada.
Nada entra sem revisão. Mudança de código passa por proposta revisada e por verificação automática antes de virar produção.
Como a gente sabe que está seguro: medindo
Essa é a parte que separa segurança de discurso sobre segurança.
Existe um padrão internacional de configuração segura para servidores, mantido por uma organização independente, o CIS. É uma lista longa e chata de centenas de verificações objetivas — o tipo de documento que ninguém lê por prazer e que é exatamente por isso que serve: ele não tem opinião sobre nós.
A gente auditou nossa máquina contra esse padrão, no nível recomendado para servidor de produção, antes de começar o trabalho. Depois voltou a auditar a cada etapa. Hoje nossa conformidade está num patamar alto — bem acima do que encontramos na primeira medição, e acima do que é comum ver em infraestrutura de organização do nosso porte.
O que interessa aqui não é a nota. São duas outras coisas.
A primeira: a régua veio antes do trabalho. A primeira medição foi feita para saber onde a gente estava, não para provar que estava bem. Sem essa linha de base, “melhoramos muito a segurança” seria uma frase sem nada atrás.
A segunda: não estamos em 100%, e não pretendemos fingir que sim. Parte do que falta é desvio deliberado, documentado com a razão — configurações que o padrão recomenda e que quebrariam o funcionamento do banco de dados ou das aplicações, e onde a gente escolheu conscientemente o funcionamento, registrando a escolha. Segurança sem serviço funcionando não é segurança: é um servidor desligado.
A inteligência artificial entra pela mesma porta que todo mundo
Voltando ao início: tudo isso existia para que a gente pudesse avançar com IA em cima de uma base defensável.
Quando essa base ficou de pé, a IA entrou obedecendo às mesmas regras. Nenhuma exceção foi aberta para ela — e vale dizer, porque abrir exceção para o sistema novo é exatamente como as brechas nascem.
Na prática: um assistente de IA não tem conta própria nem permissão própria. Ele age em nome de uma pessoa, com autorização explícita dela, e o acesso concedido é obrigatoriamente menor ou igual ao que essa pessoa já teria na tela. Ninguém ganha permissão por conectar um assistente.
Cada ação que a IA pode executar foi classificada, uma a uma, por quanto ela dói. Ação reversível executa e fica registrada. Ação com efeito para fora da organização devolve o que iria acontecer e para, esperando confirmação. Ação que movimenta dinheiro ou patrimônio exige ensaio prévio registrado e confirmação humana.
E dado pessoal identificável é substituído antes de qualquer trecho sair para um serviço externo, com registro de quanto saiu.
O relato completo desse trabalho — inclusive das seis hipóteses nossas que a medição desmentiu — está na publicação anterior.
Quem autoriza uma transferência de dados
Transferência de dados para fora daqui só acontece com autorização do nosso diretor de proteção de dados. Não é alçada compartilhada, não é aprovação por conveniência de quem está tocando a tarefa.
Sim, isso cria gargalo. É o gargalo que a gente quer. Dado que sai da organização sem alguém responsável por ter deixado sair é dado que ninguém consegue explicar depois — e “depois” costuma ser na frente de um titular, de um financiador ou de uma autoridade.
Um exemplo real, porque princípio sem exemplo é enfeite.
Quando decidimos pôr nosso tráfego atrás dessa proteção de borda, apareceu um conflito que nenhum manual resolve: passar o tráfego por uma rede externa significa que essa rede vê o que passa. Para a maior parte dos nossos sistemas isso é aceitável e está regulado por contrato de tratamento de dados. Para o canal de denúncias, não era — porque o desenho dele guarda o endereço de quem denuncia de forma irreversível, de propósito, para que nem a gente consiga saber quem foi.
A decisão não foi da equipe de tecnologia. Foi levada ao diretor de proteção de dados, decidida com base legal e registrada por escrito na nossa documentação de arquitetura, junto com o contrato que a sustenta. E o sistema mais sensível de todos ficou deliberadamente fora da borda: aceitamos perder proteção contra ataque para não perder anonimato.
Escrevo isso porque é o tipo de decisão em que segurança e privacidade puxam para lados opostos, e alguém precisa ter autoridade para dizer qual das duas cede. Se essa pessoa não existir na sua organização, a decisão vai ser tomada do mesmo jeito — por quem estiver configurando, sozinho, às onze da noite.
Saber onde cada dado está
Tem uma parte desse trabalho que não é sobre invasor nenhum. É sobre a pessoa de quem o dado é.
A gente mantém uma plataforma que centraliza o mapeamento dos dados pessoais e sensíveis espalhados pelos nossos sistemas — o que existe, onde está, por que está lá e como está sendo tratado.
A razão é direta. A LGPD dá ao titular o direito de pedir acesso, correção, portabilidade e exclusão dos próprios dados. Só que esse direito não vale nada se a organização não souber onde as informações estão. Uma organização que precisa de três semanas e uma força-tarefa para responder “quais dados vocês têm sobre mim?” não está cumprindo a lei — está fingindo cumprir, e contando com ninguém perguntar.
Aqui, quando um titular pede, a resposta sai em poucos cliques. Foi para isso que o mapeamento existe: não para ter política publicada, mas para conseguir responder.
Treinamento, porque a falha quase nunca é da máquina
Todo ano o time recebe treinamento, e ao longo do ano recebe informes — o que é permitido, o que não é, como proteger o dado de quem confiou na gente, e como reconhecer uma tentativa de golpe.
A gente insiste nisso porque quase nenhum incidente começa em um servidor. Começa em alguém com pressa, num pedido que parecia legítimo, numa mensagem que chegou na hora certa. Você pode cifrar tudo e ainda perder tudo por um “confirma pra mim rapidinho?”. Contra isso não existe configuração. Existe gente treinada.
O que dá para levar daqui
Se este texto servir para outra organização do nosso campo, que sirva por estes cinco pontos — todos independem de orçamento:
Meça antes de melhorar. Rode uma auditoria contra um padrão externo antes de mexer em qualquer coisa. Sem linha de base, você não tem como saber se melhorou nem como provar isso a quem financia.
Peça ajuda a quem oferece. Proteção de nível empresarial existe de graça para organizações de interesse público. O Projeto Galileo é um caminho real, e a maior parte das organizações elegíveis simplesmente não sabe que existe. Vale para mais coisa: identidade corporativa, acesso de confiança zero e verificação anti-robô têm faixa gratuita que cobre organização do nosso tamanho.
Trate a saída, não só a entrada. Filtragem de DNS é barata, rápida de ligar e cobre o cenário mais comum de comprometimento real.
Decida quem autoriza o quê, por escrito. Papéis definidos e uma pessoa responsável por transferência de dados valem mais que qualquer ferramenta. Isso não custa licença nenhuma — custa decisão.
Publique seus limites. Dizer o que você ainda não faz é o que dá peso ao que você diz que faz.
A gente costuma dizer que as periferias não são lugar de espera, são lugar de começo. Vale para isso também. Segurança da informação virou, na cabeça de muita gente, coisa de banco e de multinacional — algo que organização social não alcança e por isso nem tenta.
Não é verdade. O que a maior parte disso exige não é dinheiro: é decidir que o dado de um jovem da periferia merece o mesmo cuidado que o dado de um cliente de banco.
Merece. E é por isso que a gente arrumou a casa.
Referências e leituras
- Slack — Security at Slack: how Slack protects your data. A publicação que inspirou esta. https://slack.com/intl/pt-br/blog/collaboration/security-at-slack-how-slack-protects-your-data
- Lei nº 13.709/2018 — Lei Geral de Proteção de Dados Pessoais (LGPD). https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm
- Autoridade Nacional de Proteção de Dados (ANPD). https://www.gov.br/anpd/pt-br
- Cloudflare — Projeto Galileo. Proteção gratuita de nível empresarial para organizações de interesse público, desde 2014. https://www.cloudflare.com/galileo/
- Cloudflare — Relatório de aniversário do Projeto Galileo: ataques cibernéticos contra a sociedade civil. https://cfl.re/cyberattacks-against-civil-society-project-galileo-anniversary-report
- Cloudflare One — documentação da plataforma de acesso e filtragem. https://developers.cloudflare.com/cloudflare-one/
- Cloudflare Turnstile — verificação anti-robô sem rastreamento do usuário. https://developers.cloudflare.com/turnstile/
- NIST SP 800-207 — Zero Trust Architecture. A norma que formalizou o conceito de confiança zero. https://csrc.nist.gov/pubs/sp/800/207/final
- Forrester Research — No More Chewy Centers: Introducing the Zero Trust Model of Information Security (John Kindervag, 2010). O trabalho que cunhou o termo.
- Google — BeyondCorp. A primeira implementação em larga escala do modelo. https://cloud.google.com/beyondcorp
- CIS Benchmarks — Center for Internet Security. O padrão de configuração segura contra o qual auditamos nossos servidores. https://www.cisecurity.org/cis-benchmarks
- Casa Hacker — A IA que nos interessa não responde e-mail. O relato do trabalho de dados que esta publicação sustenta. https://casahacker.org/publicacoes/a-ia-que-nos-interessa-nao-responde-e-mail/