Arquitetura multi-tenant: Por Que os Discadores Precisam Dela

Se você administra uma empresa de BPO, uma revendedora ou qualquer operação que atenda vários clientes na mesma plataforma de discagem, a multilocação não é um mero diferencial. É a base sobre a qual tudo o mais se sustenta.

O que significa, na prática, multi-tenant

Multilocação significa que vários clientes independentes (tenants) compartilham a mesma infraestrutura de software, mantendo dados, configurações e regras de conformidade completamente isolados. Cada tenant opera como se tivesse seu próprio sistema dedicado, mas a plataforma subjacente é compartilhada.

A palavra-chave é isolamentoNão é separação. Não é filtragem. É isolamento.

Por que o isolamento é importante

Proteção de dados. Os contatos, gravações de chamadas, dados de agentes e resultados de campanhas do Cliente A devem ser invisíveis para o Cliente B. Não apenas ocultos, mas comprovadamente inacessíveis. Se um desenvolvedor cometer um erro em uma consulta, o banco de dados ainda deverá impedir o acesso a dados entre locatários.

Independência de conformidade. O Cliente A pode operar sob as regras TDRA (Emirados Árabes Unidos). O Cliente B, sob as CITC (Arábia Saudita). O Cliente C, sob as TCPA (EUA). Cada cliente precisa de suas próprias regras de conformidade, listas DNC , horários de contato e rastreamento de consentimento. Uma violação de conformidade por um cliente não pode afetar outro.

Isolamento de gravação. As gravações de chamadas são os dados mais sensíveis em uma central de atendimento. As gravações de cada cliente devem ser armazenadas em caminhos de armazenamento isolados, com controles de acesso específicos para cada cliente. Uma URL assinada para a gravação do Cliente A nunca deve funcionar para o Cliente B.

Isolamento de faturamento. Cada locatário possui sua própria quantidade de agentes, métricas de uso e ciclo de faturamento. Os dados de faturamento devem ser precisos para cada locatário, sem qualquer contaminação cruzada.

O Caminho Errado: Filtragem em Nível de Aplicação

Muitos discadores implementam "multilocação" com um filtro simples em seu código de aplicação. Cada consulta adiciona esse filtro. Funciona... até que alguém se esqueça.

Os problemas:

• Um filtro não aplicado = vazamento de dados entre tenants.
• Consultas complexas com junções são fáceis de serem feitas de forma incorreta.
• Consultas de agregação (relatórios, painéis) são especialmente arriscadas.
• Não há rede de segurança quando o aplicativo comete um erro.

A filtragem em nível de aplicação não é isolamento. É uma filtragem do tipo "melhor esforço" que depende de cada desenvolvedor, em cada consulta, em cada caminho de código, acertar 100% das vezes. Isso não é suficiente.

O jeito certo: isolamento em nível de banco de dados

DialerBee utiliza a Segurança em Nível de Linha (RLS) do PostgreSQL como uma camada de defesa em profundidade. Veja como funciona:

1. Cada mesa pertencente ao tenant possui uma coluna.
2. As políticas RLS estão habilitadas e FORÇADAS em todas as tabelas de locatários.
3. No início de cada transação de banco de dados, definimos
4. O próprio banco de dados filtra cada consulta — SELECT, INSERT, UPDATE, DELETE — para retornar apenas as linhas que correspondem ao locatário atual.
5. O usuário do aplicativo não possui permissão BYPASSRLS — nem mesmo SQL bruto consegue escapar do filtro.

Isso significa que, mesmo que o código do aplicativo tenha um bug — uma cláusula WHERE ausente, um JOIN incorreto, uma agregação sem agrupamento — o banco de dados impede o acesso a dados entre locatários. O filtro do aplicativo é a principal defesa. O RLS é a rede de segurança.

Teste de isolamento

Alegar isolamento não basta. É preciso comprová-lo. DialerBee executa testes adversários de isolamento de tenants em todos os endpoints API :

1. O locatário A cria um recurso (contato, campanha, gravação, etc.)
2. O locatário B tenta executar as operações GET, PATCH e DELETE nesse recurso.
3. Toda tentativa deve retornar 404 (não encontrado), nunca 403 (proibido).

Por que 404 em vez de 403? Porque o erro 403 ("você não tem permissão") confirma que o recurso existe. O erro 404 ("não encontrado") não revela nada. O locatário B nem deveria saber que o recurso existe.

Esses testes são executados na integração contínua (CI) a cada alteração de código. Se algum teste falhar, o código não é integrado ao repositório remoto.

O que os parceiros devem exigir

Se você estiver avaliando um discador para uso em marca branca ou revenda, faça estas perguntas:

• O isolamento de tenants é aplicado no nível do banco de dados ou apenas no código do aplicativo?
• Você pode me mostrar o conjunto de testes de isolamento adversário?
• O que acontece se uma consulta omitir acidentalmente o filtro de locatário?
• As gravações de chamadas são armazenadas em caminhos isolados por locatário?
• A violação das normas por um tenant pode afetar outro tenant?
• Se eu criar um locatário através do portal de parceiros, ele será imediatamente isolado de todos os outros locatários?

Se a resposta a alguma dessas perguntas for vaga, continue procurando. A gestão de múltiplos tenants feita de forma inadequada é pior do que a ausência total de multi-tenants — porque gera uma falsa sensação de segurança.

Perguntas frequentes

O que significa multilocação em um discador?

Vários clientes compartilham uma única plataforma, enquanto seus dados, configurações, regras de conformidade, gravações e relatórios permanecem separados, de forma que nenhum cliente possa ver ou afetar o outro.

Por que a filtragem em nível de aplicação não é suficiente?

Se o isolamento depender de cada consulta lembrar de filtrar por locatário, um único filtro esquecido vaza dados. O limite deve ser imposto abaixo da aplicação, e não pela disciplina do desenvolvedor.

Como o isolamento deve ser testado?

Tente deliberadamente o acesso entre locatários — solicite os registros, gravações e relatórios de outro locatário usando uma sessão válida — e confirme se a plataforma recusa, em vez de presumir que o fará.

O que um revendedor ou empresa de BPO deve exigir?

Comprovação de isolamento em nível de banco de dados, acesso de supervisores com escopo definido, configuração de conformidade por locatário e geração de relatórios e faturamento separados por cliente.