Um SaaS multiempresa permite que vários clientes usem a mesma plataforma enquanto identidades, dados, configurações e permissões permanecem separados conforme o modelo de isolamento escolhido. Multitenancy não obriga que tudo seja compartilhado: interface, aplicação, banco, armazenamento e infraestrutura podem adotar níveis diferentes.

A decisão é um equilíbrio entre segurança, custo, desempenho, escala e necessidade de personalização. O modelo correto não é automaticamente “um banco por cliente”; é aquele que atende o risco e a operação com controles verificáveis.

SaaS, tenant e multiempresa

SaaS é modelo de serviço

Software as a Service significa que o fornecedor hospeda e mantém o produto, normalmente acessado online. Atualizações e infraestrutura ficam centralizadas. O cliente usa o serviço em vez de instalar e manter uma cópia local.

Multitenancy é decisão de arquitetura

Tenant representa um limite de cliente, grupo ou organização dentro da solução. Um SaaS pode ser multitenant, single-tenant ou híbrido. E uma plataforma interna também pode usar multitenancy para separar unidades.

Empresa, unidade e usuário não são sinônimos

Uma consultoria pode ser o tenant contratante e administrar dezenas de empresas-clientes. Cada empresa pode possuir estabelecimentos, setores e usuários. Definir essa hierarquia é essencial para autorização, relatórios e cobrança.

Na Atalaia, o contexto multiempresa atende consultorias e clínicas que gerenciam carteiras de SST. A visão consolidada não deve eliminar o isolamento: cada consulta precisa considerar empresa selecionada e perfil do usuário.

Comparação de modelos multitenant com recursos compartilhados, bancos separados e infraestrutura dedicada — Guia visual LTA: SaaS multiempresa.

Modelos de isolamento

O Microsoft Azure Architecture Center descreve isolamento como espectro.

Aplicação e banco compartilhados

Clientes usam a mesma aplicação e tabelas. Cada registro contém identificador de tenant. Vantagens:

custo e operação eficientes;
atualizações centralizadas;
escala simples para muitos clientes.

Cuidados:

toda consulta deve filtrar tenant;
autorização precisa impedir troca de identificador;
falha pode impactar vários clientes;
uso intenso de um tenant pode afetar outros.

Aplicação compartilhada e banco por tenant

A camada de aplicação é comum, mas dados ficam em bancos separados. Vantagens:

isolamento maior;
restauração e política por cliente podem ser facilitadas;
personalização de capacidade em alguns cenários.

Custos:

provisionamento e atualizações de esquema mais complexos;
muitas conexões e bancos para operar;
relatórios consolidados exigem desenho adicional.

Infraestrutura dedicada

Cada cliente recebe aplicação e dados próprios. Oferece forte isolamento e flexibilidade, mas aumenta custo e trabalho. É adequado quando contrato, desempenho ou regulação justificam.

Modelo híbrido

Parte dos clientes compartilha recursos e alguns usam implantação dedicada. Ou a aplicação é comum, documentos ficam isolados e banco usa partições. O modelo pode variar por camada e plano.

Como escolher o nível

Classifique dados e impacto

Pergunte:

quais dados são pessoais, financeiros, de saúde ou estratégicos?
qual impacto de acesso cruzado?
existem requisitos contratuais ou regulatórios?
qual retenção e localização são necessárias?
cliente precisa de chave própria ou restauração individual?

Quanto maior o impacto, mais rigor deve existir na arquitetura, teste e operação.

Considere escala e custo

Centenas de bancos dedicados podem elevar manutenção. Um banco compartilhado pode ser eficiente, mas precisa de particionamento, índices e limites. Modele crescimento de clientes, usuários, dados e picos.

Avalie personalização

Configuração por tenant deve estar em dados, não em ramificações de código difíceis de manter. Customizações profundas para cada cliente comprometem atualização compartilhada.

Planeje o “vizinho barulhento”

Um tenant pode consumir CPU, conexões, fila ou armazenamento e prejudicar outros. Use quotas, rate limits, particionamento, filas e monitoramento por tenant. Planos diferentes podem oferecer capacidade e isolamento distintos, desde que transparentes.

Identidade e autorização

Identifique usuário e tenant

A sessão precisa carregar identidade confiável e tenants permitidos. Trocar empresa na interface não pode aceitar qualquer identificador enviado pelo navegador.

Aplique RBAC e autorização por objeto

Role-Based Access Control define o que funções podem fazer, mas não basta. Também valide se o objeto pertence ao tenant atual e se o usuário tem relação com ele.

Exemplo: permissão editar_trabalhador não autoriza editar trabalhador de outra empresa. O backend deve filtrar por tenant_id e identificador do objeto na mesma operação.

Use menor privilégio

Perfis devem começar restritos. Separe administração da plataforma, administração do tenant, operação e acesso do cliente final. Um Portal do Cliente pode oferecer visão limitada sem dar acesso à operação completa.

Audite ações importantes

Registre criação, alteração, exclusão, transmissão, exportação, mudança de permissão e troca de contexto. Logs devem permitir saber quem fez, quando e em qual tenant, sem expor segredos.

Dados e integrações

Filtro obrigatório e defesa em profundidade

Não dependa de o desenvolvedor lembrar de adicionar filtro. Use camadas:

contexto obrigatório na aplicação;
repositórios que exigem tenant;
políticas de banco, quando aplicáveis;
testes automatizados de acesso cruzado;
revisão de código;
monitoramento de anomalias.

Armazenamento de arquivos

Documentos precisam de caminho, bucket/container e autorização coerentes. Uma URL previsível não deve permitir baixar arquivo de outro cliente. Prefira URLs assinadas e de curta duração quando apropriado.

Exportação e portabilidade

Defina como o cliente obtém seus dados, formato, prazo e histórico. A exportação precisa respeitar escopo: um usuário não pode exportar o tenant inteiro sem permissão.

Integrações conscientes de tenant

Credenciais podem ser globais ou por cliente. Armazene segredos com proteção adequada e associe cada evento ao tenant. Webhooks devem ter assinatura, idempotência e destino correto.

No Auto Gestor, módulos como estoque, vendas e frota precisam compartilhar contexto sem misturar operações de entidades diferentes.

Operação e observabilidade

Métricas técnicas e de negócio

Monitore latência, erro, saturação, filas e uso por tenant. Evite colocar identificadores pessoais em rótulos de alta cardinalidade. Para negócio, acompanhe tarefas concluídas e pendências sem expor dados no sistema de observabilidade.

Backup e restauração

O modelo afeta restauração. Em banco compartilhado, restaurar apenas um tenant pode exigir processos próprios. Teste recuperação, não apenas criação de cópia. Documente RPO, RTO e responsabilidades.

Incidentes

Defina como detectar acesso cruzado, conter, investigar, notificar e corrigir. Logs e inventário de dados são essenciais. Um incidente em ambiente compartilhado exige saber quais tenants foram afetados.

Atualizações

Use migrações compatíveis, rollout gradual e rollback. Clientes dedicados podem receber ondas diferentes, mas isso aumenta versões mantidas.

Conheça os sistemas da LTA para observar como produtos verticais organizam módulos, perfis e empresas.

Erros comuns

Confiar no tenant enviado pela tela. O servidor deve validar.
Usar RBAC sem verificar o objeto. Função não prova pertencimento.
Colocar tabela por tenant no mesmo banco. Pode se tornar difícil de escalar e atualizar.
Não limitar consumo. Um cliente pode degradar a plataforma.
Logs sem contexto. Incidentes ficam impossíveis de investigar.
Expor arquivos por URL previsível. Autorização deve existir no download.
Prometer isolamento sem descrever modelo. Comprador precisa entender controle e evidência.
Não testar acesso cruzado. É um dos cenários mais importantes.

Checklist para avaliar um SaaS multiempresa

[ ] Tenant e hierarquia de empresas estão definidos.
[ ] Modelo de compartilhamento por camada está documentado.
[ ] Usuário só pode selecionar tenants autorizados.
[ ] RBAC e autorização por objeto são aplicados no backend.
[ ] Arquivos possuem controle equivalente ao banco.
[ ] Credenciais e integrações são isoladas corretamente.
[ ] Existem testes automatizados de acesso cruzado.
[ ] Quotas e rate limits reduzem efeito de vizinho barulhento.
[ ] Métricas e logs incluem contexto seguro de tenant.
[ ] Backup e restauração por escopo foram testados.
[ ] Exportação e portabilidade estão definidas.
[ ] Incidentes, atualização e rollback têm processo.
[ ] Custos e limites estão claros por plano.

Perguntas frequentes

Multitenancy significa banco compartilhado?

Não. Significa que uma solução atende múltiplos tenants. As camadas podem ser compartilhadas ou dedicadas.

Banco separado é sempre mais seguro?

Ele aumenta isolamento de dados em alguns cenários, mas segurança depende também de identidade, aplicação, segredos, rede, operação e processo.

Como impedir acesso a outro tenant?

Valide identidade, contexto, permissão e pertencimento do objeto no backend, com defesa em profundidade e testes.

O que é vizinho barulhento?

É quando consumo anormal de um tenant prejudica desempenho de outros que compartilham recursos.

Um SaaS pode ter configuração por cliente?

Sim. Preferências e regras podem ser dados do tenant. Customização profunda de código para cada cliente deve ser cuidadosamente governada.

Sua operação administra várias empresas?

Agende uma demonstração da Atalaia no WhatsApp e veja carteira, perfis, alertas e portal aplicados à gestão de SST. Para outro cenário, use a página de contato.