Guia de segurança de software e LGPD no Brasil em 2026

O que este guia resolve

Segurança e LGPD costumam entrar na conversa tarde demais, quando o produto já está no ar e alguém pergunta se está tudo certo. A resposta honesta, na maioria das vezes, é não. Vazamento de dado, autenticação frágil, log que não existe, base legal que ninguém definiu. O problema não é falta de boa vontade, é que segurança foi tratada como fase final em vez de fundação. Escrevi este guia para inverter isso: mostrar o que precisa estar no software desde o começo e o que a LGPD exige na prática, sem o juridiquês que assusta e sem o marketing de fornecedor de firewall.

O conteúdo vem de projetos que entregamos na Bradata, de sistemas que lidam com dado sensível de verdade, incluindo saúde, e de auditorias onde vimos o que quebra. Vou tratar da segurança de aplicação pelo OWASP Top 10, de autenticação e autorização com JWT e OAuth, de criptografia que serve para algo, da LGPD na prática com bases legais, consentimento, DPO, RIPD e resposta a incidente, de auditoria e log, de pentest, de compliance por setor com foco em saúde, e fecho com um checklist técnico. É longo. Use os títulos para navegar.

OWASP Top 10: os riscos que se repetem

Segurança de aplicação tem uma referência que vale mais que qualquer curso genérico: o OWASP Top 10, a lista dos riscos mais comuns em software web, revisada periodicamente por quem vê o mundo real quebrar. Não é teoria, é o mapa de onde os ataques acontecem. Vale conhecer os principais e o que cada um significa na prática.

Risco	O que é	Exemplo concreto
Broken Access Control	Usuário acessa o que não deveria	Trocar o ID na URL e ver dado de outro cliente
Cryptographic Failures	Dado sensível mal protegido	Senha em texto puro, tráfego sem TLS
Injection	Entrada não tratada vira comando	SQL injection, campo que executa código
Insecure Design	Falha na arquitetura, não no código	Fluxo que confia no cliente para validar
Security Misconfiguration	Configuração padrão insegura	Painel admin exposto, senha default
Vulnerable Components	Dependência desatualizada com falha conhecida	Biblioteca antiga com CVE público
Authentication Failures	Login que dá para burlar	Sem limite de tentativa, senha fraca aceita

O primeiro da lista, Broken Access Control, é o que mais aparece e o mais barato de explorar. Não precisa de hacker sofisticado. Basta um usuário curioso trocando um número na URL e descobrindo que o sistema mostra o pedido, o prontuário ou o contrato de outra pessoa. A defesa não é esconder a URL, é verificar no servidor, a cada requisição, se aquele usuário tem direito àquele recurso. Parece óbvio e é o erro mais comum que encontramos.

O segundo grupo de campeões é injection e componente vulnerável. Injection se resolve nunca confiando na entrada do usuário e usando queries parametrizadas, nunca concatenando string. Componente vulnerável se resolve com uma prática que quase ninguém mantém: acompanhar as dependências e atualizar as que têm falha conhecida. Uma biblioteca desatualizada com CVE público é convite aberto. Detalhei como esses riscos se manifestam em aplicações web e como a autenticação se encaixa neles em segurança de aplicações web com OWASP, JWT e LGPD. Quem constrói produto web deveria ler antes de pensar que está seguro.

Autenticação e autorização: quem é você e o que pode fazer

As duas palavras se confundem e são coisas diferentes. Autenticação responde quem é você. Autorização responde o que você pode fazer. Sistema seguro precisa das duas, e errar a fronteira entre elas é fonte de vazamento.

Na autenticação moderna, o padrão é o token. Depois que o usuário prova quem é, o sistema emite um JWT, um token assinado que carrega a identidade e viaja em cada requisição. O servidor valida a assinatura e sabe quem está falando sem consultar o banco toda vez. É eficiente e escala bem. Os cuidados que separam o uso correto do perigoso:

O token precisa ter validade curta. Um JWT que vale para sempre é uma chave que, se vazar, abre a porta indefinidamente. O padrão é um access token de vida curta, minutos, acompanhado de um refresh token de vida mais longa e guardado com mais cuidado.

O que vai dentro do token não pode ser sensível. JWT é assinado, não criptografado por padrão. Qualquer um lê o conteúdo. Colocar dado pessoal ou permissão que dê para forjar é erro.

A assinatura precisa ser forte e a chave protegida. Token assinado com algoritmo fraco ou com chave exposta é token que dá para falsificar.

Para cenários onde um sistema precisa agir em nome do usuário em outro sistema, entra o OAuth. É o protocolo por trás do "entrar com o Google". Ele não compartilha senha, compartilha uma autorização delegada e revogável. Usar OAuth para login social ou para integração entre serviços é o caminho maduro, e reinventar isso à mão costuma dar errado.

A autorização, o que cada um pode fazer, merece desenho próprio. Papéis (admin, gestor, operador), permissões finas por recurso, e a regra de ouro: validar sempre no servidor. O cliente pode esconder um botão, mas quem decide se a ação acontece é o backend. Interface que confia no navegador para controlar acesso é interface que se burla com a ferramenta de desenvolvedor aberta.

Criptografia que serve para algo

Criptografia virou palavra de marketing, e por isso vale separar o que protege de verdade do que é enfeite. Existem dois momentos em que o dado precisa estar protegido, e eles pedem soluções diferentes.

Dado em trânsito, viajando entre o navegador e o servidor ou entre serviços, se protege com TLS. Não é opcional em 2026. Todo tráfego, sem exceção, sob HTTPS. Sistema que aceita conexão sem TLS está expondo dado no caminho, e não há desculpa técnica que justifique.

Dado em repouso, guardado no banco e em disco, pede tratamento por categoria. Senha nunca se guarda de forma reversível: usa-se hash com algoritmo próprio para isso, como bcrypt ou argon2, com salt. Se o banco vazar, as senhas não viram texto. Dado sensível como CPF, dado de saúde e dado financeiro se protege com criptografia de campo ou de coluna, para que um vazamento de banco não entregue tudo em claro. E a chave que criptografa precisa viver longe do dado que ela protege, num cofre de segredos, não no código nem numa variável de ambiente exposta.

O erro caro é achar que criptografia resolve segurança sozinha. Ela protege o dado guardado e em trânsito. Não protege contra um usuário legítimo que acessa o que não deveria, contra injection, contra token mal gerido. Criptografia é uma camada, não a muralha inteira. Sistema que criptografa tudo e não controla acesso está trancando o cofre e deixando a chave na fechadura.

LGPD na prática, sem juridiquês

A LGPD assusta porque parece jurídica, e é, mas a parte que o software precisa cumprir é concreta. Vou tratar do que importa para quem constrói e opera sistema.

Base legal: você não precisa de consentimento para tudo

O mito mais comum é que todo tratamento de dado exige consentimento. Não exige. A LGPD prevê dez bases legais, e o consentimento é só uma delas, muitas vezes a mais frágil, porque pode ser revogada. As bases que mais aparecem no dia a dia de software empresarial:

Base legal	Quando se usa
Execução de contrato	Dado necessário para entregar o serviço contratado
Obrigação legal	Dado que a lei obriga a guardar, como fiscal e trabalhista
Legítimo interesse	Uso razoável e esperado, com teste de proporcionalidade
Consentimento	Quando nenhuma outra base cobre, como marketing
Tutela da saúde	Tratamento por profissional ou serviço de saúde

O ponto prático: antes de coletar um dado, a pergunta certa é qual base legal justifica isso, não como pego o consentimento. Um sistema de RH guarda CPF por obrigação legal, não por consentimento do funcionário. Um e-commerce guarda endereço por execução de contrato. Definir a base legal de cada tratamento é o trabalho de fundação que evita problema depois, e a maioria dos projetos pula essa etapa.

Consentimento, quando ele se aplica

Quando o consentimento é a base, ele precisa ser livre, informado e específico. Livre significa que negar não pode punir o usuário. Informado significa que ele entende para que serve. Específico significa que um consentimento não vale para dez finalidades diferentes. E precisa ser revogável com a mesma facilidade com que foi dado. O sistema precisa registrar quando, como e para quê o consentimento foi obtido, porque numa fiscalização a prova é sua responsabilidade.

DPO e RIPD: os papéis e documentos que a lei pede

O DPO, ou encarregado, é a pessoa que faz a ponte entre a empresa, os titulares dos dados e a ANPD, a autoridade. Não precisa ser advogado nem funcionário exclusivo em toda empresa, mas precisa existir e ser identificável. O canal de contato do DPO precisa estar visível para quem quer exercer seus direitos.

O RIPD, Relatório de Impacto à Proteção de Dados, é o documento que descreve como um tratamento de risco elevado funciona, quais dados usa, quais riscos traz e como eles são mitigados. Não é para todo tratamento, é para os de risco relevante, como uso de dado sensível em escala. Ter o RIPD pronto antes da fiscalização, e não durante, é a diferença entre demonstrar governança e improvisar.

Direitos do titular: o software precisa entregar

A LGPD dá ao titular direitos que o sistema precisa conseguir cumprir, não só a política de privacidade prometer. Acesso aos dados que a empresa tem sobre ele. Correção de dado errado. Eliminação quando cabível. Portabilidade. Informação sobre com quem os dados foram compartilhados. Na prática isso vira requisito técnico: o sistema precisa conseguir localizar todos os dados de uma pessoa, exportar, corrigir e apagar. Software que espalhou dado pessoal por dez tabelas sem rastreio não consegue atender um pedido de eliminação, e isso é descumprimento.

Incidente: o relógio começa a correr

Quando acontece um vazamento ou incidente de segurança com dado pessoal, a LGPD exige comunicação à ANPD e aos titulares afetados em prazo razoável. Ter um plano de resposta a incidente definido antes de ele acontecer é o que separa a empresa que age em horas da que descobre o vazamento semanas depois pela imprensa. O plano cobre detecção, contenção, avaliação do impacto, comunicação e registro. E o registro importa: mesmo incidente contido precisa ficar documentado.

Montei um checklist prático que amarra tudo isso, do técnico ao organizacional, em segurança e LGPD em software empresarial: checklist. É o material para quem quer sair da teoria e verificar item por item o que falta no seu sistema.

Auditoria e log: o que você não registra, não consegue explicar

Segurança sem log é segurança cega. Quando algo dá errado, e vai dar, a diferença entre entender o que aconteceu e encolher os ombros está no que o sistema registrou. Log de segurança não é o mesmo que log de erro de programador. Ele responde perguntas de auditoria: quem acessou aquele dado, quando, de onde, e o que fez.

O que um sistema sério registra: autenticações, bem e mal sucedidas; acesso a dado sensível, quem viu o quê; alterações de permissão, quem promoveu quem; operações críticas, exclusão, exportação, alteração de configuração. E o log precisa ser confiável: um log que o próprio usuário pode apagar não serve de prova. Ele precisa viver separado, imutável, retido pelo prazo que a auditoria do setor exige.

A pergunta honesta para o seu sistema: se um titular reclamar que alguém acessou o dado dele indevidamente, você consegue mostrar quem acessou, quando e se tinha direito? Se a resposta é não, o log não está fazendo o trabalho dele.

Pentest: descobrir a falha antes do atacante

Revisar o próprio código encontra parte dos problemas. Um teste de intrusão, o pentest, encontra o que a equipe não vê porque está perto demais. É um profissional tentando invadir o sistema como um atacante faria, de forma controlada e autorizada, e reportando o que conseguiu.

Vale entender os tipos. Pentest de caixa preta, onde o testador não tem acesso ao código e ataca de fora, simula o atacante externo. Caixa branca, com acesso ao código, encontra mais fundo. Caixa cinza fica no meio. Para produto que lida com dado sensível, o pentest não é luxo, é higiene periódica, idealmente antes de um lançamento grande e depois em ciclos regulares.

O erro comum é fazer o pentest uma vez, guardar o relatório e nunca corrigir os achados. Pentest só vale pelo que se corrige depois. Um relatório com dez vulnerabilidades altas que ficou na gaveta é pior que não ter feito, porque agora existe prova documentada de que a empresa sabia e não agiu.

Compliance por setor: saúde é o caso mais exigente

A LGPD vale para todos, mas alguns setores têm camadas extras. Saúde é o mais rigoroso, e vale como referência do que exigência séria significa.

Dado de saúde é dado sensível pela LGPD, com proteção reforçada. Um prontuário eletrônico não é um cadastro qualquer: mistura identificação, histórico clínico, exame, prescrição. Além da LGPD, há normas específicas do setor, como as certificações da SBIS para prontuário eletrônico, e regras do conselho de medicina sobre guarda e sigilo. Sistema de saúde que ignora essas camadas não está só arriscando multa da ANPD, está arriscando a operação do cliente.

Os pontos que um sistema de saúde precisa acertar: controle de acesso rígido, porque quem pode ver um prontuário é um conjunto restrito e rastreado; log completo de todo acesso a dado clínico; criptografia do dado sensível em repouso; base legal clara, geralmente tutela da saúde e não consentimento; e retenção pelos prazos que a norma do setor exige, que são longos. Tratamos das particularidades de prontuário, telemedicina e o que a LGPD exige da saúde em LGPD na saúde: prontuário eletrônico e telemedicina em 2026. Quem constrói para o setor deveria começar por lá, porque errar aqui não é multa, é a saúde de uma pessoa exposta.

Outros setores têm suas camadas. Financeiro responde ao Banco Central e a regras de Open Finance. Educação lida com dado de menor, que tem proteção especial. O princípio geral se mantém: a LGPD é o piso, e cada setor empilha exigência em cima.

Checklist técnico

Para fechar a teoria num material acionável, os itens que separam o sistema seguro do exposto. Se algum destes está em branco no seu produto, ali mora o risco.

Área	Item	Pergunta de verificação
Acesso	Controle no servidor	Toda requisição valida permissão no backend?
Autenticação	Token de vida curta	JWT expira em minutos, com refresh separado?
Senha	Hash com salt	Senhas guardadas com bcrypt ou argon2?
Trânsito	TLS em tudo	Nenhuma conexão aceita sem HTTPS?
Repouso	Dado sensível cifrado	CPF, saúde e financeiro criptografados no banco?
Segredo	Cofre de chaves	Chave e senha fora do código e do ambiente exposto?
Dependência	Atualização	Bibliotecas com CVE conhecido são monitoradas?
Log	Auditoria imutável	Acesso a dado sensível fica registrado e protegido?
LGPD	Base legal por tratamento	Cada dado coletado tem base legal definida?
LGPD	Direitos do titular	O sistema localiza, exporta e apaga dados de uma pessoa?
LGPD	Plano de incidente	Existe processo de resposta antes do vazamento?
Teste	Pentest periódico	Achados anteriores foram corrigidos?

Este checklist não é decoração. É o roteiro de uma conversa séria sobre o seu sistema. Empresa que consegue responder sim a todos com prova está num patamar que a maioria não alcança. Quem tem lacunas agora sabe por onde começar.

Perguntas frequentes

Preciso de consentimento para tratar qualquer dado pessoal? Não. A LGPD prevê dez bases legais e o consentimento é só uma, muitas vezes a mais frágil por ser revogável. Muito tratamento se apoia em execução de contrato, obrigação legal ou legítimo interesse. Um sistema de RH guarda CPF por obrigação legal, não por consentimento. A pergunta certa antes de coletar um dado é qual base legal justifica, não como obtenho o consentimento.

JWT é seguro para autenticação? É, quando bem usado. O token precisa ter validade curta, com um access token de minutos e um refresh token guardado com cuidado. O conteúdo do JWT não pode ser sensível, porque ele é assinado e não criptografado, então qualquer um lê. E a assinatura precisa ser forte com a chave protegida. JWT eterno, com dado sensível dentro ou com chave exposta, deixa de ser seguro.

Criptografar o banco resolve a segurança do sistema? Não sozinho. Criptografia protege o dado em repouso e em trânsito, mas não protege contra um usuário legítimo que acessa o que não deveria, contra injection ou contra token mal gerido. É uma camada entre várias. Sistema que criptografa tudo e não controla acesso está trancando o cofre e deixando a chave na fechadura.

O que a LGPD exige quando acontece um vazamento? Comunicação à ANPD e aos titulares afetados em prazo razoável, além do registro do incidente. Ter um plano de resposta definido antes é o que separa a empresa que age em horas da que descobre o vazamento semanas depois. O plano cobre detecção, contenção, avaliação de impacto, comunicação e registro. Mesmo incidente contido precisa ficar documentado.

Todo sistema precisa de um DPO? Precisa de um encarregado identificável que faça a ponte com titulares e com a ANPD. Nem toda empresa precisa de um DPO exclusivo e dedicado, mas o papel precisa existir e o canal de contato precisa estar visível para quem quer exercer seus direitos. O RIPD, o relatório de impacto, é exigido para tratamentos de risco elevado, como uso de dado sensível em escala, não para todo processamento.

Com que frequência devo fazer pentest? Depende do risco, mas para produto que lida com dado sensível o pentest é higiene periódica, idealmente antes de lançamentos grandes e depois em ciclos regulares. O ponto que mais importa não é a frequência, é corrigir os achados. Pentest cujo relatório fica na gaveta é pior que nenhum, porque cria prova de que a empresa sabia da falha e não agiu.

Fechamento

Segurança e LGPD não são fase final nem selo pendurado no rodapé do site. São fundação. O sistema que controla acesso no servidor, guarda senha com hash, cifra dado sensível, registra auditoria imutável e sabe a base legal de cada dado que coleta está protegido de verdade. O que trata isso como enfeite descobre a lacuna no pior momento possível, num vazamento ou numa fiscalização, quando o custo de corrigir é o maior.

Se você precisa construir ou revisar um sistema com segurança e LGPD desde a fundação, incluindo setores exigentes como saúde, a Bradata trata isso como parte da engenharia, não como fase colada no fim. Somos uma software house que entrega produto pensando em segurança e conformidade desde o desenho. Fale com a gente para uma conversa técnica, sem folheto.