Segurança para BaaS (Banking as a Service): protegendo a stack que liquida em nome de dezenas de fintechs

Por que BaaS concentra risco que nenhum outro modelo financeiro concentra

Banking as a Service é, na essência, a desverticalização do banco. Uma instituição licenciada — tipicamente uma instituição de pagamento ou um banco — expõe suas capacidades regulatórias (abertura de contas, emissão de cartões, liquidação, arranjo de pagamento Pix, KYC) como APIs consumíveis por terceiros. Dezenas de fintechs, varejistas, marketplaces e até empresas não-financeiras constroem produtos bancários sobre essa plataforma sem nunca tocar diretamente no Banco Central. O provedor BaaS é a camada que faz a ponte regulatória e técnica.

Esse modelo é brilhante para o negócio e perigoso para a segurança, porque ele inverte a topologia de risco tradicional. Num banco clássico, cada cliente final é uma conta. Numa plataforma BaaS, cada cliente é uma fintech inteira — com seu próprio universo de usuários, contas, saldos e fluxos de liquidação. A stack do provedor passa a ser um multi-tenant onde os tenants não são pessoas, são empresas concorrentes entre si, todas confiando que a plataforma vai impedir que uma enxergue a outra.

Some a isso a concentração regulatória. O provedor BaaS é quem responde — perante o Banco Central, perante a ANPD, perante as bandeiras de cartão — pela higidez de operações que ele não originou diretamente. Quando uma rede de contas-laranja é aberta através de uma fintech parceira mal-instrumentada, o reflexo recai sobre o arranjo de pagamento do provedor. Quando um IDOR vaza saldos, o titular dos dados é cliente da fintech, mas o controlador de fato dos dados na infraestrutura é o provedor.

As quatro ameaças que definem o setor BaaS

BOLA, BFLA e o abuso de onboarding

Broken Object Level Authorization (BOLA) e Broken Function Level Authorization (BFLA) ocupam, respectivamente, o primeiro e o quinto lugar do OWASP API Security Top 10. Em BaaS, são a ameaça soberana. BOLA acontece quando um endpoint recebe um identificador de objeto — um número de conta, um id de transação, um id de cliente — e devolve o recurso sem verificar se o tenant autenticado tem direito àquele objeto específico. Um endpoint como GET /v1/accounts/{id}/balance que confia apenas no token de acesso, sem amarrar o {id} ao tenant dono do token, permite que a Fintech A incremente o {id} e leia o saldo de uma conta da Fintech B. BFLA é o irmão funcional: o atacante invoca uma função privilegiada — estorno, ajuste de limite — que não deveria poder invocar, mas que aceita a chamada de qualquer parceiro autenticado. A terceira ameaça vive no onboarding: o provedor BaaS centraliza a esteira de Conheça Seu Cliente de todos os parceiros, e quando essa esteira é fraca — validação documental superável, prova de vida burlável, ausência de device fingerprint, falta de rate limit — ela vira fábrica de contas-laranja movimentadas via Pix.

Account takeover propagado e fraude de liquidação

Para simplificar a integração, muitas plataformas BaaS adotam SSO entre o portal do provedor e os portais das fintechs, ou emitem tokens com escopo amplo demais. Um único token comprometido — vazado num log, capturado num parceiro mal-protegido, exposto num repositório público — pode dar acesso transversal. Se o modelo de identidade não isola rigorosamente cada parceiro, o comprometimento de uma fintech vira o comprometimento de toda a plataforma: é o account takeover propagado, característico da topologia BaaS. A quarta ameaça ataca o coração econômico do modelo, a liquidação: manipular janelas de liquidação, explorar condições de corrida em estorno e captura, forjar webhooks de confirmação de pagamento ou desviar arranjo Pix são vetores que atacam diretamente o dinheiro em trânsito. Diferente de um vazamento de dados, aqui o impacto é imediato e financeiro, e a janela de detecção precisa ser medida em segundos, não em horas.

Anatomia técnica de um IDOR multi-tenant em BaaS

Vale dissecar o vetor central deste setor porque ele é sutil e quase sempre invisível em revisão de código superficial. Considere um endpoint de extrato: GET /v1/accounts/{account_id}/statement. A aplicação recebe um JWT válido no header Authorization. O backend decodifica o token, confirma a assinatura, identifica que pertence à Fintech A, e — aqui está a falha — busca o extrato da account_id pedida sem verificar se aquela conta pertence ao conjunto de contas da Fintech A.

O atacante, operando como parceiro legítimo da Fintech A, observa que suas próprias contas têm ids sequenciais ou previsíveis. Ele itera o account_id e começa a receber extratos de contas que não são suas — incluindo de clientes da Fintech B. O endpoint responde 200 em todos os casos. Não há erro nos logs de aplicação. Não há alerta. O vazamento é silencioso e contínuo, e pode persistir por meses até que alguém note dados estranhos.

Como a Decripte trata a autorização multi-tenant como disciplina

A maioria dos testes de segurança de API olha um tenant de cada vez. Isso é estruturalmente cego ao risco de BaaS. A abordagem da Decripte parte de dois ou mais contextos de tenant legítimos operando simultaneamente, e modela explicitamente o atacante como um parceiro autenticado tentando atravessar a fronteira lógica para outro parceiro.

O resultado não é uma lista genérica de vulnerabilidades. É um mapa de onde a fronteira entre parceiros é permeável, com prova de conceito reproduzível para cada cruzamento — o tipo de evidência que destrava decisão executiva e priorização real de correção. A gestão de vulnerabilidades contínua mantém esse mapa atualizado à medida que novos endpoints e novos parceiros entram na plataforma, porque cada release é uma nova chance de reabrir a fronteira.

SOC 24x7 com correlação cross-tenant: ver o ataque que atravessa parceiros

Um SOC comum monitora um ambiente. O SOC para BaaS precisa monitorar muitos ambientes lógicos dentro de uma stack e — crucialmente — detectar o que acontece na costura entre eles. Um atacante que enumera contas de múltiplos tenants gera, em cada tenant isolado, um padrão que parece benigno; só correlacionando entre tenants é que o padrão de varredura aparece.

A correlação cross-tenant é a inteligência que diferencia evento isolado de campanha coordenada. Quando o mesmo ASN, o mesmo padrão de fingerprint ou a mesma rede de contas-laranja toca múltiplos parceiros, deixa de ser um incidente do parceiro X e vira uma investigação de plataforma — com resposta proporcional e comunicação adequada ao Banco Central quando aplicável.

Conformidade: as normas que recaem sobre o provedor BaaS

Provedores BaaS operam tipicamente como instituições de pagamento ou em parceria com instituição licenciada, e estão sujeitos ao arcabouço regulatório do Banco Central para instituições de pagamento, arranjos de pagamento e ao arranjo do Pix. As normas do Banco Central estabelecem requisitos de gestão de riscos, segurança cibernética e continuidade que se aplicam à operação. A Decripte estrutura a governança de segurança para que ela seja auditável perante esse arcabouço — sem inventar números de norma, mas mapeando os requisitos reais de gestão de risco operacional e cibernético às práticas técnicas implantadas.

A questão da LGPD em BaaS é particularmente delicada: o provedor frequentemente trata dados pessoais de titulares que são clientes das fintechs parceiras. A definição de papéis — quem é controlador, quem é operador — precisa estar contratualmente clara, e a segregação técnica precisa sustentar essa separação na prática. Um vazamento cross-tenant não é só uma falha técnica; é um incidente de dados pessoais com obrigações de comunicação à ANPD e aos titulares.

Estruturando a segurança por parceiro: governança de API multi-tenant

Responder a incidentes é necessário, mas insuficiente. A Decripte estrutura a plataforma para que a próxima falha de autorização seja arquiteturalmente difícil de cometer. O eixo dessa estruturação é a governança de API por parceiro: cada tenant tem credenciais com escopo mínimo, política de autorização explícita e centralizada, rate limits e cotas próprias, telemetria isolada e correlacionável, e um ciclo de vida de credencial com rotação.

Sobre essa base, a estruturação adiciona segregação de dados verificável, contratos de API versionados por parceiro, e a integração da segurança no ciclo de release: nenhum endpoint novo vai para produção sem o teste de autorização cruzada entre tenants no pipeline. É a transformação de segurança de evento para segurança de processo. Quem começa o caminho pelo diagnóstico gratuito em decripte.io/free já recebe o mapa inicial dessa superfície.

Cenário ilustrativo: vazamento de saldos entre fintechs por IDOR em endpoint compartilhado

Como a Decripte responde a um incidente em plataforma BaaS

A resposta a incidentes em BaaS exige velocidade na contenção e cirurgia na erradicação: é preciso estancar o vazamento ou a fraude sem derrubar a plataforma para os demais parceiros saudáveis. O processo da Decripte segue passos disciplinados, com SLA de contenção de até uma hora.

1. Detecção e triagem com correlação cross-tenant: o SOC 24x7 confirma o incidente, identifica se a falha atravessa parceiros e classifica o evento, inclusive quanto à possível natureza de incidente de dados pessoais sob a LGPD.
2. Contenção cirúrgica em até 1h: isolamento do tenant ou credencial comprometida, revogação de tokens e bloqueio de borda do vetor explorado, preservando a disponibilidade para os demais parceiros.
3. Análise forense e determinação do alcance: reconstrução da linha do tempo, identificação de quais objetos e quais tenants foram efetivamente acessados, e preservação de evidências para cadeia de custódia.
4. Erradicação na raiz: varredura de toda a superfície de API pela mesma classe de falha via pentest de autorização e correção centralizada, em vez de remendos por controller.
5. Recuperação validada: retorno controlado dos endpoints com teste de autorização cruzada no pipeline, rotação de credenciais e revisão de escopos de token de todos os parceiros.
6. Monitoramento reforçado pós-incidente: implantação de regras de detecção de segregação permanentes no SOC e vigilância contínua sobre o vetor explorado.
7. Conformidade e comunicação: apoio à notificação à ANPD e aos titulares quando há dados pessoais envolvidos, e organização da documentação de gestão de risco cibernético perante o Banco Central.
8. Relatório executivo e lições aprendidas: entrega de causa-raiz, impacto e plano de estruturação para que a fronteira entre parceiros deixe de ser permeável.

Como a Decripte estrutura a segurança de uma plataforma BaaS

Para além de responder, a Decripte estrutura a plataforma de modo que a próxima falha de autorização seja arquiteturalmente difícil. A estruturação repousa sobre pilares que tornam a segregação entre parceiros uma propriedade do sistema, não uma promessa.

Planos recomendados para BaaS (Banking as a Service)

Perguntas frequentes

Termos do setor

BaaS (Banking as a Service)

Modelo em que uma instituição licenciada expõe capacidades bancárias e de pagamento como APIs consumíveis por fintechs e empresas parceiras, que constroem produtos financeiros sem licença própria. O provedor concentra liquidação, KYC e responsabilidade regulatória de múltiplos clientes numa única stack.

BOLA (Broken Object Level Authorization)

Falha número um do OWASP API Security Top 10: o endpoint devolve um objeto referenciado por id sem verificar se o requisitante tem direito àquele objeto específico. Em BaaS, permite que uma fintech parceira acesse contas e dados de outra na mesma plataforma.

BFLA (Broken Function Level Authorization)

Falha do OWASP API Security Top 10 em que um usuário ou tenant consegue invocar funções privilegiadas ou administrativas para as quais não tem permissão, como endpoints de estorno, ajuste de limite ou operações internas.

Multi-tenant

Arquitetura em que uma única instância de software serve múltiplos clientes (tenants) com isolamento lógico. Em BaaS, cada tenant é uma fintech inteira, o que torna o isolamento entre tenants o núcleo do produto e da segurança.

Conta-laranja

Conta aberta com dados de terceiros, sintéticos ou de intermediários recrutados, usada para movimentar produto de crime e dificultar o rastreamento. Provedores BaaS são alvo por concentrarem o onboarding de muitas fintechs numa única esteira de KYC.

Arranjo de pagamento

Conjunto de regras e procedimentos que disciplinam um serviço de pagamento, como o Pix, sob supervisão do Banco Central. O provedor BaaS responde pela higidez das operações que liquida através desse arranjo.