GGlinter CRM
Técnico··6 min de leitura

CRM multi-tenant - por que segurança importa em SaaS B2B

Como funciona arquitetura multi-tenant em CRM SaaS. Riscos de vazamento cross-tenant, garantias da Glinter e o que perguntar antes de contratar qualquer CRM.

Por Equipe Glinter

#segurança#multi-tenant#SaaS#LGPD

Toda empresa que contrata CRM SaaS está confiando os contatos comerciais, valores de proposta e histórico de pipeline a uma plataforma compartilhada com centenas (ou milhares) de outras empresas. Isso é arquitetura multi-tenant — e é o padrão da indústria. Funciona, escala e é mais barato. Mas tem riscos reais que CTOs precisam entender antes de assinar contrato.

Esse texto explica o que multi-tenant significa, qual é a falha de segurança mais grave possível em SaaS B2B (vazamento cross-tenant), como o Glinter CRM mitiga, e o que perguntar a qualquer CRM antes de migrar dados sensíveis.

O que multi-tenant significa

Você abre conta no CRM. Recebe URL próprio (empresa.crm.com). Vê seus dados, seus vendedores, seus leads. Parece sistema dedicado. Não é.

Por baixo:

  • Mesmo banco de dados PostgreSQL
  • Mesma tabela "Lead", "Order", "Proposal", etc.
  • Mesma aplicação rodando no mesmo servidor

A separação acontece via coluna tenantId em cada registro. Cada lead tem tenantId = 'sua-empresa-id'. Toda query que o sistema faz tem que filtrar por esse ID — SELECT * FROM Lead WHERE tenantId = 'sua-empresa-id'.

Se em algum lugar do código essa cláusula WHERE for esquecida, a query retorna leads de todas as empresas que estão no mesmo banco. Esse é o vazamento cross-tenant — falha mais grave em SaaS B2B.

Por que isso é vetor de risco

Imagine: concorrente seu também usa o mesmo CRM. Se houver uma falha de filtragem, ele pode (em tese) ver:

  • Sua lista de clientes
  • Valor das suas propostas
  • Histórico de fechamento
  • Pipeline em andamento

Isso é dado comercial sensível. Em alguns segmentos (saúde, financeiro), também é dado pessoal — sob LGPD, vazamento gera multa e responsabilidade civil.

A maioria dos CRMs sérios investe pesado para isso não acontecer. Mas o risco é real e existe em escala (Salesforce já teve incidente público em 2018, Atlassian em 2022, GitLab em 2023).

Como evitar

Há três níveis de proteção que CRM bem feito implementa:

Nível 1: tenantId em toda query

Regra de ouro do código:

// ERRADO — retorna leads de todos os tenants
const leads = await prisma.lead.findMany()

// CERTO — filtra por sessão do usuário
const leads = await prisma.lead.findMany({
  where: { tenantId: session.user.tenantId }
})

Sem esse filtro, vazamento.

Nível 2: tenantId vem da sessão, não do request

Cliente nunca pode mandar tenantId no body da request. Atacante mudaria pra ID de outro tenant. O ID precisa vir do token de sessão assinado pelo servidor.

Nível 3: validação cruzada em update/delete

Antes de atualizar lead com ID X, verifique se esse lead pertence ao tenant da sessão:

const lead = await prisma.lead.findFirst({
  where: { id: x, tenantId: session.user.tenantId }
})
if (!lead) return 404 // Não diga "não pertence ao seu tenant"
await prisma.lead.update({ ... })

Mesmo se atacante adivinhar ID, sistema responde 404.

Como o Glinter CRM aplica

Implementamos esses três níveis em todas as APIs. Mais que isso:

  • Auditoria automática: toda query escrita pela equipe passa por revisão de código focada em tenantId
  • Test suite específica: testes automatizados verificam vazamento entre tenants antes de qualquer deploy
  • Logs auditados: toda ação tem log com tenantId — se algo escapar, identificamos rápido
  • Princípio de menor privilégio: usuário tem acesso apenas ao próprio tenant. Sem "super admin" cross-tenant que possa esquecer filtro.

A regra de ouro do nosso código:

Toda query ao banco DEVE filtrar por tenantId da sessão. Sem exceções. Sem atalhos. Sempre.

Está no nosso CLAUDE.md (instruções para IA que escreve código no projeto), está no manual de novos devs, está no review de cada pull request.

Outros riscos relevantes

Multi-tenant não é o único vetor. Ao avaliar qualquer CRM SaaS, pergunte sobre:

1. Criptografia em trânsito (TLS)

Mínimo: TLS 1.2. Ideal: TLS 1.3. Glinter CRM usa TLS 1.3 com cifras modernas em todo tráfego.

2. Criptografia em repouso

Banco de dados criptografado em disco. Não impede vazamento via aplicação, mas protege se servidor físico for comprometido.

3. Hash de senha

Senha nunca armazenada em plaintext. Algoritmos aceitáveis: bcrypt (com cost ≥10), Argon2id, scrypt. Usamos bcrypt via Better-Auth.

4. Rate limiting

Login com tentativas ilimitadas é vetor de força bruta. Limite por IP + por usuário. Glinter CRM tem rate limiting agressivo em endpoints de auth.

5. Backup e recuperação

Frequência de backup? Em outro datacenter? Quanto tempo retém? Quanto tempo leva pra restaurar? Esses números deveriam estar em SLA.

Glinter CRM: backup diário em outro datacenter, retenção 30 dias, recuperação RTO de 4 horas.

6. Política de incidentes

Quando algo der errado (não "se", quando), como você é avisado? Em quanto tempo?

LGPD obriga aviso de incidente em 72h. Vendor que não tem política clara já é alerta.

O que perguntar antes de assinar

Cinco perguntas obrigatórias para qualquer CRM SaaS:

  1. Como vocês isolam dados entre clientes em arquitetura multi-tenant? (resposta deve mencionar tenantId, sessão, validação)
  2. Vocês têm test suite de vazamento cross-tenant rodando em CI/CD? (resposta SIM ou explicação clara)
  3. Quem na sua equipe tem acesso ao banco de produção e como é auditado? (princípio de menor privilégio + log)
  4. Vocês são compatíveis com LGPD? Têm DPO? Como respondem solicitação de portabilidade/exclusão? (LGPD não é opcional para SaaS)
  5. Em caso de incidente de segurança, qual é o tempo de resposta e como você é avisado? (deve estar em contrato/SLA)

Se vendor titubear em qualquer dessas, vire e ande.

Sobre LGPD

LGPD se aplica a qualquer empresa que processa dado pessoal de brasileiro. CRM tem dado pessoal: nome, email, telefone do contato.

Como cliente do CRM (controlador), você é responsável pela legalidade do processamento. Como vendor (operador), o CRM é responsável por:

  • Implementar medidas técnicas adequadas
  • Notificar incidentes
  • Permitir portabilidade
  • Permitir exclusão de dado pessoal sob requisição

Glinter CRM tem termo de operador, política de privacidade alinhada à LGPD e funcionalidade de exportação/exclusão de dados pessoais via interface administrativa.

Self-hosted como alternativa

Para empresas com dados extremamente sensíveis (dados de saúde, financeiro grande porte, governo), self-hosted ainda tem espaço. Você roda o CRM no seu próprio datacenter, com seu próprio banco. Multi-tenancy desaparece — você é o único tenant.

Trade-off: você assume operação. Backup, atualização, segurança de servidor, etc. Para PME, raramente vale o esforço.

Glinter CRM tem opção self-hosted no plano Enterprise. Para 95% dos clientes, SaaS multi-tenant com as garantias acima é suficiente.

Para aprofundar

Resumo

Multi-tenant é o padrão. Bem implementado, é seguro. Mal implementado, é catastrófico. Ao escolher CRM SaaS, valide os três níveis (tenantId em query, sessão como fonte da verdade, validação cruzada), pergunte sobre criptografia, backup, política de incidentes e LGPD.

Quer entender em detalhe como Glinter CRM trata isso?