Senhas e credenciais expostas no legado¶
Hoje existe um risco de segurança alto porque senhas e credenciais ficam fáceis de ler ou copiar. A API Nova é a chance de corrigir isso com baixo impacto e sem parar o negócio.
Contexto rápido¶
Quando a gente fala em senha e credencial, estamos falando de três coisas diferentes que se misturam no legado
- senha de usuário, como corretor e cliente
- credenciais técnicas, como acesso ao banco e integrações
- segredos internos do próprio sistema, como chaves e senhas mestre
O problema é que, no legado, essas três coisas acabam indo parar em lugares onde qualquer pessoa com acesso técnico consegue enxergar ou reaproveitar.
O que é o problema, em linguagem simples¶
1) Senhas de usuários legíveis no banco¶
O ponto mais grave é que as senhas dos usuários ficam armazenadas no banco de um jeito que dá para ver. Qualquer pessoa com acesso ao banco, backup, restore ou query consegue ler e reutilizar essas senhas.
Isso vale para corretores, clientes e outros perfis.
Por que isso é perigoso
- não é só um risco de invasão do sistema. vira risco de reutilização em outros serviços, já que muita gente repete senha
- aumenta o impacto de qualquer acesso indevido ao banco, mesmo que seja um acesso “interno”
- torna quase impossível provar que nunca houve uso indevido
2) Credenciais dentro do código, com troca manual em deploy¶
Além das senhas de usuário, existem credenciais técnicas dentro do código. Um exemplo bem claro está no processo atual de publicação, onde a classe ConfiguracoesBanco concentra strings de conexão e credenciais, e a troca de ambiente faz parte do processo manual de deploy. Isso mistura entrega de versão com gestão de segredo.
Na prática, o fluxo de deploy incentiva esse tipo de risco
Esse trecho existe no nosso material de referência de deploy e já descreve o ponto crítico como credenciais dentro do código.
3) Credenciais hardcoded em integrações e serviços¶
O mesmo padrão se repete fora do banco e fora da conexão do banco
- envio automático de e-mail
- integrações com parceiros
- serviços de geração de PDF
- qualquer outra ferramenta que exige chave, token ou usuário e senha
O efeito é o mesmo. segredo fica no repositório, em arquivo de configuração versionado, ou espalhado em código.
Como isso acontece hoje, com exemplos práticos¶
Cenário 1. Alguém com acesso ao banco enxerga senha¶
Exemplo simples do que acontece no dia a dia
- a pessoa tem acesso ao banco por motivo legítimo, como BI, planilha, auditoria, etc.
- com uma consulta, ela enxerga a senha como texto legível
- essa senha pode ser usada para entrar como corretor ou cliente
Mesmo quando não há intenção maliciosa, esse desenho cria risco porque a senha não deveria ser um dado recuperável.
Cenário 2. Deploy manual força troca de credencial no código¶
O documento de deploy manual já descreve o padrão atual
- credenciais de homologação ficam no repositório
- credenciais de produção ficam fora do repositório e são coladas no código na hora de publicar
- isso cria risco de publicar apontando para o ambiente errado e risco de vazar segredo por acidente
Aqui o impacto é duplo
- risco operacional, porque o erro só aparece quando alguém usa
- risco de segurança, porque segredo passa a fazer parte de rotina manual
Cenário 3. Existe a ideia de senha mestre e segredos fixos¶
No material de autenticação, aparece um exemplo concreto de segredo fixo que funciona como senha mestre em um fluxo de token, com valores hardcoded.
Não é exatamente o mesmo problema de senha no banco, mas é a mesma família de risco
- segredo fixo vira uma chave universal
- quando vaza, o impacto é grande
- a troca vira difícil porque várias coisas podem depender disso
Esse tipo de padrão precisa ser bloqueado na API Nova.
Impactos no negócio¶
Tempo e retrabalho¶
- investigação de incidentes fica mais lenta, porque a dúvida vira enorme
- troca de credencial exige cuidado extra, já que está espalhada
- o time perde tempo apagando incêndio em vez de melhorar o produto
Risco operacional¶
- um erro simples de deploy pode jogar produção em homologação ou expor credencial sem querer
- quando uma credencial precisa mudar rápido, a operação vira corrida contra o tempo
Risco de segurança¶
- senha legível no banco amplia o impacto de qualquer acesso indevido
- segredo no código facilita vazamento por commit, etc
- segredo fixo, como senha mestre, amplia o raio do problema
O que a API Nova muda para reduzir esse risco e por quê¶
A API Nova é a oportunidade de corrigir isso desde o começo. A matriz de políticas já marca como decisão que segredos devem ficar fora do código. A parte mais importante é separar responsabilidades
- a API vira o lugar único de autenticação e validação de acesso
- senhas não ficam mais como dado recuperável
- credenciais técnicas ficam em cofre de segredos ou equivalente, segregadas por ambiente
Como fica a arquitetura na prática¶
O gateway como porta de entrada única e com políticas por consumidor também está descrito como caminho de arquitetura no material do projeto.
1) Senha deixa de ser algo que dá para ler¶
Na API Nova, a senha não deve ser guardada de forma reversível. A aplicação guarda um “resumo seguro” da senha, e na hora do login ela compara sem nunca precisar revelar o texto original.
Isso resolve dois pontos
- mesmo com acesso ao banco, não dá para ler a senha
- o impacto de vazamento de base cai muito
2) Migração gradual, com baixo impacto¶
A proposta de baixo impacto faz sentido
- a API Nova nasce com o padrão correto
- os sistemas atuais vão sendo adaptados para autenticar via API Nova
- a troca acontece por etapas, sem quebrar tudo de uma vez
Um caminho comum aqui é migrar no uso:
- quando o usuário autentica pelo novo fluxo, a senha passa a ser tratada no padrão novo
- com o tempo, o legado deixa de depender da senha armazenada do jeito antigo
3) Credenciais de banco e integrações saem do código¶
A matriz de políticas já coloca como decidido que segredos ficam fora do código, e também separa ambientes e credenciais por ambiente.
Isso elimina o padrão atual descrito no deploy manual, onde o deploy exige colar credenciais dentro do projeto.