Multi-tenant e isolamento de dados: perguntas para seu fornecedor de KYC

Um fornecedor de verificação de identidade guarda, por definição, dados sensíveis de muitas empresas ao mesmo tempo. Selfies, fotos de documento, números de CPF (Cadastro de Pessoas Físicas), resultados de análise biométrica: tudo isso vive na mesma infraestrutura, servindo dezenas ou centenas de contratantes simultaneamente. No jargão de software como serviço (SaaS), cada empresa contratante é um tenant, um inquilino do sistema. A pergunta que define o risco é uma só: o que, na prática, separa os dados de um inquilino dos dados do outro?

A resposta confortável, e insuficiente, é o contrato. Cláusula de confidencialidade, acordo de tratamento de dados, promessa de segregação. Nada disso impede uma consulta mal escrita de devolver o documento de um cliente na tela de outro. Isolamento entre tenants é decisão de arquitetura: ou está embutido no desenho do sistema e é verificado por máquina, ou depende de disciplina humana repetida milhares de vezes por dia.

Este texto é para quem contrata ou avalia um fornecedor de KYC (Know Your Customer, o processo de conhecer e verificar a identidade do cliente): quais modelos de isolamento existem, onde o vazamento entre clientes acontece de verdade e quais perguntas objetivas levar para a conversa técnica.

Três modelos, três custos

Quase todo sistema multi-tenant cai em um de três desenhos, e cada um troca custo por garantia de um jeito diferente.

Banco por tenant. Cada cliente tem seu próprio banco de dados, às vezes até seu próprio servidor. É o isolamento mais forte: não existe consulta capaz de cruzar clientes, porque os dados nem coabitam. O custo é operacional: cada migração de esquema roda uma vez por cliente, monitorar centenas de bancos é caro e provisionar um cliente novo deixa de ser instantâneo. Por isso é raro em serviços de alto volume.

Schema por tenant. Um banco só, mas cada cliente vive em um schema separado, com suas próprias tabelas. Meio-termo: a separação lógica é visível e auditável, mas conexões, backups e recursos continuam compartilhados, e a operação ainda multiplica esforço por cliente.

Tabela compartilhada com chave de tenant. Todos os clientes nas mesmas tabelas, cada linha carregando uma coluna do tipo tenant_id. É o modelo mais comum, o mais barato de operar e escalar, e também o que mais depende de disciplina: toda consulta, sem exceção, precisa filtrar pela chave do tenant certo. Um único WHERE esquecido em um endpoint obscuro é suficiente para misturar clientes.

Nenhum dos três é "errado". O que existe é modelo compatível ou incompatível com os controles que o fornecedor construiu em volta dele. O modelo compartilhado, justamente por ser o mais frágil por padrão, é o que mais exige defesa em profundidade.

Quando o próprio banco recusa a linha errada

Se a única barreira entre os clientes é o filtro que a aplicação escreve em cada consulta, a segurança do sistema inteiro tem a espessura do desenvolvedor mais apressado. A alternativa é aplicar a política no próprio banco de dados.

O PostgreSQL oferece isso nativamente com Row-Level Security (RLS, segurança em nível de linha), descrita na documentação oficial do PostgreSQL. Com RLS habilitada, cada tabela ganha políticas que dizem quais linhas cada sessão pode ler e escrever. Se a sessão está marcada com o tenant A e a aplicação, por erro, monta uma consulta sem filtro, o banco simplesmente não retorna as linhas do tenant B. A política vale também para escrita: inserir ou atualizar uma linha que viole a regra é recusado pelo banco, não pela boa vontade do código.

A mesma documentação registra os limites que valem a pena conhecer: por padrão o dono da tabela não é submetido às próprias políticas, salvo quando o modo forçado é ativado, e superusuários e papéis com o atributo de contorno de RLS nunca passam por elas. Ou seja, RLS não elimina a pergunta sobre acesso administrativo, mas transforma o cenário mais comum de vazamento, a consulta errada da aplicação, em um erro inofensivo em vez de um incidente.

A diferença conceitual importa mais que a tecnologia específica: um fornecedor sério consegue apontar onde a regra de isolamento vive fora do código da aplicação. Pode ser RLS, pode ser outro mecanismo equivalente. O que não se sustenta é "nossa aplicação sempre filtra".

Onde o vazamento acontece de verdade, além do banco

O banco de dados é o lugar óbvio, e por isso mesmo costuma ser o mais bem tratado. Os incidentes cross-tenant tendem a nascer nas bordas, onde o dado sai do banco e a chave de tenant fica pelo caminho.

• Cache. Um cache que indexa por número de documento, sem o tenant na chave, serve a resposta de um cliente para outro. O dado está "certo", a chave é que mente.
• Storage de mídia. Selfies e documentos costumam viver em storage de objetos, fora do banco. Se o caminho do arquivo é adivinhável e o acesso não é autorizado por cliente, o isolamento do banco vira decoração. O tema rende um texto próprio sobre upload seguro de mídia.
• Índices derivados. Busca textual, índices de análise e, no caso de biometria, os vetores faciais usados em comparação. Um índice biométrico global, misturando rostos de todos os clientes, é uma decisão de produto com consequência direta de privacidade. Na UNIFOKAL, a detecção de contas duplicadas usa uma busca 1:N na própria base: o rosto é comparado somente dentro da base do próprio cliente, nunca contra uma base compartilhada entre clientes.
• Exportações e backups. Relatórios agendados, planilhas geradas para o time de dados, dumps de banco. Um backup restaurado em ambiente de teste sem os mesmos controles do ambiente de produção é uma cópia inteira do problema.
• Suporte interno. As ferramentas que o time do fornecedor usa para atender chamados enxergam quantos clientes de uma vez? Com qual trilha de auditoria? O operador humano é um tenant implícito que quase nunca aparece no diagrama de arquitetura.

Um fornecedor que só fala do banco quando perguntado sobre isolamento está descrevendo a parte fácil.

O que a lei e as normas pedem

A Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) determina, no artigo 46, que os agentes de tratamento adotem medidas de segurança, técnicas e administrativas, aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas. Isolamento entre clientes é exatamente uma medida técnica dessa natureza: um acesso cross-tenant é, por definição, um acesso não autorizado.

Certificações ajudam, mas medem outra coisa. A ISO/IEC 27001, norma da International Organization for Standardization e da International Electrotechnical Commission para sistemas de gestão de segurança da informação, atesta que o fornecedor tem processos de gestão de segurança. Ela não diz qual modelo de multi-tenancy ele escolheu nem se o índice biométrico é segregado. Certificado é ponto de partida da conversa, não o fim dela.

As perguntas para levar à diligência

Estas perguntas cabem em qualquer processo de due diligence de fornecedor e não exigem acesso ao código de ninguém.

1. O isolamento é garantido no banco de dados ou só na aplicação? Qual mecanismo concreto recusa uma linha de outro tenant?
2. O storage de mídia segrega por cliente? Como um endereço de arquivo é autorizado antes de ser servido?
3. Os índices derivados, inclusive os biométricos, são segregados por cliente ou existe alguma base global?
4. Como o isolamento é testado? Existe teste automatizado que tenta acessar dado de outro tenant e precisa falhar para o software ser publicado?
5. O que acontece em um restore de backup? É possível restaurar um cliente sem materializar os dados dos outros em algum ambiente intermediário?
6. Quem do suporte interno enxerga o quê, e onde fica registrado cada acesso?

Uma resposta boa nomeia mecanismos: cita a política aplicada no banco, descreve a chave de tenant no cache e no storage, aponta o teste de cross-tenant na esteira de publicação e admite limites com naturalidade, como o tratamento de acessos administrativos. Uma resposta evasiva aponta para o certificado e para o contrato, repete que "a aplicação sempre filtra", garante que "isso nunca aconteceu" ou recusa qualquer detalhe alegando segredo industrial. Arquitetura de isolamento não é segredo competitivo: é justamente a parte que um fornecedor maduro tem interesse em explicar.

A conversa completa sobre escolha de fornecedor passa por mais dimensões, de precisão do motor a modelo de preço, e está no guia sobre como avaliar um fornecedor de KYC. Mas se for para começar por um único tema técnico, comece por este: perguntar onde mora a fronteira entre você e os outros clientes do seu fornecedor é a forma mais rápida de descobrir se ela existe.

Fontes citadas

• Lei 13.709/2018 (Lei Geral de Proteção de Dados), artigo 46, disponível em planalto.gov.br
• Documentação oficial do PostgreSQL sobre Row-Level Security, disponível em postgresql.org/docs
• ISO/IEC 27001, norma internacional de sistemas de gestão de segurança da informação