©2026 MIT Sloan Management Review Brasil. Todos os direitos reservados. A reprodução, total ou parcial, é proibida sem a autorização prévia e expressa do CNEX.

Imagine que você tem uma fintech com uma conta de pagamentos em tempo real, com alta liquidez (como a conta PI, usada pelos provedores de Pix) – digamos, R$ 100 milhões disponíveis. Para movimentar esse dinheiro, o sistema depende de um cofre digital (como um HSM) que guarda as chaves criptográficas responsáveis por autorizar as transações. Essas chaves são tão seguras que nenhum ser humano ou software não autorizado consegue acessá-las diretamente. Somente um software específico, já autorizado, consegue usá-las para assinar digitalmente as mensagens enviadas.

Parece seguro, não é?

Na prática, não é. Isso só cria uma ilusão de segurança para convencer executivos leigos que “seu dinheiro está seguro”. O verdadeiro risco não está em roubar as chaves, mas em sequestrar o software que já tem acesso a elas. Um invasor que controle esse software pode criar mensagens falsas, que vão parecer assinadas de forma legítima, e enviá-las como se fossem ordens válidas. Ou seja, o problema deixa de ser criptográfico e passa a ser de controle e isolamento de execução.

Agora imagine que esse mesmo software, com acesso às chaves e capacidade de assinar mensagens, está hospedado num servidor multi-tenant, ou seja, compartilhado entre várias empresas — como se fosse um andar de coworking com 20 fintechs, cada uma com R$ 100 milhões. O software consegue assinar mensagens em nome de qualquer uma delas.

Nesse cenário, o prêmio para um criminoso deixa de ser R$100 milhões e passa a ser R$2 bilhões. Esse valor justifica contratar atacantes altamente qualificados, capazes de explorar falhas sofisticadas no software, rede ou configuração do ambiente. Este é um erro grave: o prêmio pelo crime nunca pode ser tão alto.

Você pode se perguntar: “Mas não há isolamento entre os clientes?”. A resposta é: não no nível que importa. Em sistemas multi-tenant, quem faz a separação entre clientes é o próprio software aplicativo – o mesmo que pode ser comprometido. O sistema operacional, a infraestrutura e muitas vezes até o banco de dados são compartilhados. Se o software falhar em identificar corretamente de qual cliente veio uma requisição, pode acabar assinando ordens em nome de quem não deveria.

Isso cria uma vulnerabilidade sistêmica: o ataque a um ponto comum compromete todos os clientes simultaneamente. E quanto maior a concentração de recursos sob um único software, maior o incentivo econômico para o crime.

Mas o Gmail é multi-tenant e funciona bem, certo?

Sim, e esse é um bom ponto. O GMail é um clássico sistema multi-tenant. Todos nós, usuários de e-mail, somos tenants nesse sistema. E, de fato, só conseguimos ver nossas mensagens.

O que justifica esse modelo no GMail é a escala. São mais de 100 mil novas contas por dia. Criar um ambiente isolado para cada uma seria tecnicamente inviável e economicamente proibitivo. O multi-tenancy é uma solução inteligente nesse caso, mesmo com riscos, pois o volume e a frequência das contas exigem automação extrema.

Só que, quando muda o cenário…

Agora pense em um sistema com apenas 20 novos clientes por ano. Cada cliente movimenta valores altos e possui grande relevância estratégica. Apesar do elevado valor financeiro, estas instituições processam poucas transações de valor elevado e com isso um ambiente multi-tenant suporta a demanda computacional.

Mesmo que a baixa demanda de cada cliente viabilize a solução multi-tenant, este modelo deixa de ser vantajoso. Ainda que se economize algum custo de infraestrutura, o risco cibernético introduzido é enorme. E, infelizmente, é comum vermos decisões motivadas apenas por custo imediato, sem considerar o risco agregado.

É o famoso caso do barato que sai caro. 

Boas práticas para ambientes de alto risco

Listo a seguir cinco boas práticas que qualquer empresa com uma unidade fintech deveria considerar:

1. Evite sistemas multi-tenant sempre que possível

Principalmente quando:

• O volume de clientes é pequeno.
  
• Os valores envolvidos são altos.
  
• O risco de invasão é atraente.
  

Isolamento físico ou virtual (containers, VMs, ambientes dedicados) pode reduzir drasticamente o impacto de uma eventual brecha.

2. Limite o poder das pessoas

Não permita que uma única pessoa, mesmo interna, tenha acesso a todos os recursos ou consiga autorizar transferências sozinha. Divida responsabilidades. O uso de senhas, tokens e imagens em conjunto com múltiplos operadores impede que um único ponto de falha comprometa tudo.

Além disso, isso protege os profissionais contra coação física, algo infelizmente real no Brasil. Se um gerente precisa da ajuda de outros dois colegas para liberar uma transação, o crime se torna mais difícil e arriscado.

3. Não deixe muitos recursos a mão

Contas que processam pagamentos instantâneos (como Pix) devem ter saldos ajustados à necessidade imediata. Um sistema de gestão de liquidez automatizado ajuda a manter o saldo enxuto e reduz o incentivo para ataques direcionados.

4. Impeça a assinatura unilateral de mensagens

O software que assina transações deve rodar em servidores isolados e sem acesso administrativo direto. E mais importante: só deve assinar mensagens que tenham sido previamente aprovadas pelo cliente, com a chave privada que está em seu próprio celular, cartão ou hardware externo. Isso garante que nem mesmo a sua equipe possa forjar transações – protegendo tanto os clientes quanto os próprios funcionários.

5. Implemente servidores inatingíveis — sem acesso possível

O software responsável por assinar mensagens financeiras críticas deve ser executado em um servidor que ninguém consegue acessar — literalmente.

Isso não significa que ele deve estar protegido com múltiplos fatores de autenticação. Significa que o servidor não deve possuir nenhum meio de acesso interativo: nada de SSH, RDP, painel administrativo ou mesmo shell local. Nenhum agente de monitoramento que permita executar comandos. Nenhum software de acesso remoto.

É um servidor com um único propósito: assinar mensagens automaticamente com base em critérios pré-definidos. Ele não é gerenciado no dia a dia como os demais. Caso apresente qualquer falha, a correção não é feita entrando nele, mas sim provisionando um novo servidor, com base em uma imagem imutável, previamente validada e armazenada com segurança, com imagem do servidor e código assinado digitalmente por várias testemunhas.

Essa abordagem reduz a superfície de ataque e elimina o fator humano como vetor direto de invasão — e, com isso, eleva consideravelmente o nível de proteção de um sistema sensível.

O criminoso não precisa mais da chave. Ele só precisa convencer o software a abrir o cofre

Ameaças à integridade física de familiares

Sistemas multi-tenant não são, por si só, inseguros. Mas eles exigem um nível de maturidade técnica, vigilância e análise de risco que nem sempre é levado a sério. Quando o que está em jogo são bilhões de reais, não basta apenas confiar no software: é preciso desenhar a arquitetura pensando desde o início em dificultar o ataque e limitar o potencial dano.

Afinal, o criminoso não precisa mais da chave. Ele só precisa convencer o software a abrir o cofre.

E lembre-se: todas as palavras sofisticadas como HSM, 2FA e biometria se tornam insuficientes quando o elo vulnerável está fora da tecnologia. Não se trata apenas de confiar em um profissional – trata-se de aceitar que nenhum ser humano, por mais íntegro que seja, pode resistir à coação sob ameaça real. A pessoa que possui essas credenciais pode ter familiares ameaçados fisicamente.

Por isso, proteger os sistemas é também proteger as pessoas. A regra é: menos poder concentrado, menos risco. E eu me refiro a risco tanto para os recursos financeiros quanto para a integridade física dos profissionais envolvidos.

Salvar conteúdo 4