Servidor dedicado para SaaS: como garantir isolamento

Um servidor dedicado para SaaS oferece recursos físicos exclusivos para hospedar aplicações que atendem diferentes empresas. Entretanto, quando vários clientes utilizam a mesma plataforma, é necessário estabelecer mecanismos que impeçam acessos indevidos e reduzam a interferência entre suas operações.

Esse desafio é comum em sistemas ERP, plataformas de gestão financeira, CRMs e softwares corporativos oferecidos por assinatura.

À medida que a base de clientes cresce, a infraestrutura precisa suportar diferentes volumes de requisições, armazenar informações com segurança e manter o desempenho das aplicações.

O planejamento deve considerar tanto o isolamento lógico dos dados quanto a distribuição dos recursos computacionais.

Neste artigo, explicamos como estruturar essas camadas e quais critérios utilizar para escolher a arquitetura mais adequada.

O que é isolamento entre clientes em aplicações SaaS?

O isolamento entre clientes, também chamado de tenant isolation, consiste em aplicar controles que impedem um cliente de acessar informações, serviços ou recursos pertencentes a outro sem autorização.

Em uma aplicação SaaS multitenant, diferentes organizações podem utilizar a mesma base de código e compartilhar componentes da infraestrutura.

Essa arquitetura oferece vantagens operacionais, mas exige mecanismos específicos para garantir a separação entre os ambientes.

Quais camadas precisam ser isoladas?

O planejamento deve considerar diferentes níveis de separação:

• Aplicação: autorização para acessar funcionalidades e informações de cada cliente.
• Banco de dados: separação de registros, schemas ou instâncias.
• Processamento: controle do consumo de CPU e memória.
• Armazenamento: políticas de acesso a arquivos e objetos.
• Rede: restrição da comunicação entre serviços e ambientes.
• Operação: controle de logs, backups, tarefas e credenciais administrativas.

A autenticação de um usuário não garante, isoladamente, que ele só poderá acessar os recursos da organização à qual pertence.

É necessário verificar a autorização em cada operação que envolve informações de clientes.

Essa distinção é abordada na documentação de isolamento de tenants da AWS.

Quais são os principais modelos de isolamento em SaaS?

As arquiteturas SaaS geralmente utilizam três estratégias: pool, silo e bridge, também chamado de modelo híbrido.

A diferença está na quantidade de recursos compartilhados e na forma como os limites entre clientes são implementados.

Modelo pool: recursos compartilhados

No modelo pool, vários clientes utilizam componentes compartilhados, como servidores de aplicação, bancos de dados e serviços de processamento.

A separação ocorre principalmente por políticas de autorização e mecanismos lógicos.

Essa abordagem pode reduzir o custo operacional por cliente e facilitar atualizações centralizadas.

Entretanto, exige controles rigorosos para impedir acesso cruzado aos dados e limitar o consumo excessivo de recursos.

Modelo silo: ambientes separados

No modelo silo, cada cliente utiliza recursos próprios em uma ou mais camadas da aplicação.

O isolamento pode envolver bancos de dados individuais, máquinas virtuais, containers dedicados ou servidores físicos exclusivos.

Essa estratégia pode ser indicada quando existem requisitos específicos de segurança, desempenho ou personalização.

Em contrapartida, a manutenção e o provisionamento de ambientes separados podem aumentar a complexidade operacional.

Modelo híbrido: compartilhamento seletivo

O modelo híbrido combina componentes compartilhados com recursos dedicados para determinados clientes ou serviços.

Uma plataforma pode, por exemplo, manter autenticação e interface compartilhadas enquanto utiliza bancos de dados individuais para clientes com requisitos mais exigentes.

Também é possível separar serviços com maior consumo de CPU ou memória sem duplicar toda a infraestrutura.

Essa abordagem permite ajustar o isolamento conforme o perfil de utilização e os requisitos contratuais.

Pool, silo ou híbrido: qual modelo oferece o melhor equilíbrio?

O melhor modelo depende do nível de isolamento necessário, do número de clientes, da capacidade operacional da equipe e dos custos de infraestrutura.

O modelo silo não elimina a necessidade de autorização, criptografia e monitoramento. Da mesma forma, uma arquitetura pool pode oferecer isolamento adequado quando os controles são corretamente implementados e validados.

Como implementar o isolamento de dados entre clientes SaaS?

O isolamento de dados deve garantir que consultas, alterações, exportações e operações administrativas respeitem os limites de cada organização.

Existem diferentes estratégias para estruturar essa separação.

Banco de dados compartilhado com tenant_id

Nessa abordagem, diferentes clientes utilizam as mesmas tabelas, mas cada registro possui um identificador associado ao tenant.

Uma consulta ilustrativa seria:

SELECT id, valor, status
FROM pedidos
WHERE tenant_id = :tenant_id_autorizado;

O identificador deve ser obtido de um contexto de autenticação validado pelo servidor, e não de um parâmetro livremente informado pelo usuário.

Também é recomendável utilizar controles adicionais no banco de dados, como Row-Level Security, quando disponíveis e adequados à arquitetura.

Schemas separados por cliente

Outra estratégia é utilizar schemas individuais dentro de um mesmo banco de dados.

Essa abordagem facilita determinadas políticas de separação, mas exige controle sobre permissões, conexões e atualizações de estrutura.

O crescimento da quantidade de schemas também deve ser considerado no planejamento operacional.

Bancos de dados individuais

Clientes podem utilizar instâncias ou bancos separados, com credenciais e políticas de acesso próprias.

Essa estratégia oferece maior independência para manutenção, recuperação e dimensionamento, dependendo da implementação.

Entretanto, aumenta a quantidade de componentes que precisam ser monitorados e atualizados.

Como separar CPU, memória e processamento entre clientes?

O isolamento computacional limita a quantidade de recursos que cada cliente ou serviço pode consumir, reduzindo a interferência entre workloads.

Em um servidor dedicado, os recursos físicos pertencem exclusivamente ao ambiente contratado. Entretanto, quando vários clientes SaaS utilizam esse servidor, ainda existe compartilhamento interno de capacidade.

Para administrar essa distribuição, podemos utilizar diferentes mecanismos.

Containers com limites de recursos

Containers permitem executar serviços com limites definidos de CPU e memória, utilizando mecanismos do sistema operacional, como cgroups no Linux.

Uma configuração ilustrativa de limites em Kubernetes seria:

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "2"
    memory: "2Gi"

Esses parâmetros ajudam a controlar a utilização de recursos, mas não representam uma barreira de segurança equivalente à separação física.

Também é necessário considerar o isolamento do kernel, as permissões dos containers e a segurança do orquestrador.

Máquinas virtuais independentes

Máquinas virtuais permitem executar sistemas operacionais separados sobre um hypervisor.

Essa abordagem pode oferecer maior separação entre ambientes do que containers tradicionais, conforme a configuração de virtualização e segurança.

O dimensionamento deve considerar a memória reservada, a quantidade de vCPUs e a concorrência entre máquinas virtuais.

Servidores físicos por cliente

Quando determinado cliente exige isolamento físico, é possível utilizar um servidor dedicado exclusivo para seu ambiente.

Essa configuração elimina o compartilhamento do hardware daquele servidor com outros clientes da aplicação, mas não substitui controles de segurança em redes, sistemas e operações administrativas.

Para aplicações com requisitos específicos de processamento, conheça as opções de Servidor Dedicado da EVEO.

Como configurar o isolamento de rede em aplicações SaaS?

O isolamento de rede controla quais serviços e ambientes podem se comunicar, reduzindo a exposição de componentes internos.

Mesmo quando diferentes clientes compartilham o mesmo servidor físico, é possível estabelecer regras para restringir a comunicação entre seus serviços.

Quais controles podem ser utilizados?

• VLANs: segmentação lógica de redes conforme a arquitetura.
• Firewalls: restrição de portas, protocolos e origens.
• Redes virtuais: separação de ambientes de aplicação.
• Network Policies: controle de comunicação entre workloads em plataformas compatíveis.
• Criptografia: proteção do tráfego entre serviços e sistemas.
• Controle de acesso: restrição de interfaces administrativas e serviços internos.

O desenho da rede deve considerar a comunicação necessária entre aplicações, bancos de dados, serviços de autenticação e componentes de observabilidade.

Segmentar a rede sem definir regras adequadas de autorização pode deixar caminhos de acesso indevido entre clientes.

Como dimensionar um servidor dedicado para aplicações SaaS?

O dimensionamento deve considerar o número de clientes, o consumo de recursos por tenant e o comportamento da aplicação durante períodos de maior utilização.

Utilizar apenas a quantidade de clientes cadastrados como referência pode resultar em capacidade insuficiente ou recursos ociosos.

Como estimar a necessidade de CPU?

A quantidade de núcleos depende da concorrência, do custo computacional das requisições e da capacidade de paralelismo da aplicação.

Uma plataforma com centenas de clientes pouco ativos pode consumir menos CPU do que outra com poucos clientes executando relatórios e operações intensivas.

Por isso, é importante medir a utilização por serviço e identificar picos simultâneos.

Como calcular a memória RAM?

A RAM deve acomodar os processos da aplicação, caches, conexões, bancos de dados e demais serviços executados no servidor.

Em ambientes com máquinas virtuais ou containers, também é necessário considerar as reservas e os limites de cada workload.

O consumo total não deve ser estimado apenas pela soma das médias, pois diferentes clientes podem apresentar picos simultâneos.

Qual armazenamento utilizar?

Aplicações SaaS transacionais podem se beneficiar de armazenamento SSD ou NVMe, especialmente quando realizam muitas operações aleatórias de leitura e escrita.

O dimensionamento deve considerar:

• Capacidade atual e crescimento dos dados.
• Quantidade de operações de I/O.
• Latência exigida pelos bancos de dados.
• Retenção de logs e arquivos.
• Estratégia de redundância e backup.

A configuração de RAID deve ser escolhida conforme os requisitos de desempenho e tolerância a falhas, sem ser tratada como substituta do backup.

Como considerar o crescimento da plataforma?

É recomendável definir limites de utilização, acompanhar tendências de consumo e estabelecer critérios objetivos para expansão.

Esses critérios podem incluir utilização sustentada de CPU, pressão de memória, latência de disco e aumento do tempo de resposta das APIs.

O planejamento também deve considerar a possibilidade de distribuir workloads entre múltiplos servidores quando uma única máquina deixar de atender aos requisitos da aplicação.

Como evitar o efeito noisy neighbor entre clientes SaaS?

O efeito noisy neighbor ocorre quando um cliente ou workload consome recursos compartilhados em excesso e prejudica o desempenho dos demais.

Esse comportamento pode afetar CPU, memória, conexões de banco de dados, armazenamento e filas de processamento.

Mesmo em um servidor físico exclusivo, o problema pode ocorrer quando diferentes tenants compartilham a mesma aplicação.

Quais estratégias ajudam a reduzir a interferência?

• Definir limites de requisições por cliente.
• Controlar a concorrência de tarefas.
• Estabelecer cotas de CPU e memória.
• Separar workloads com consumo elevado.
• Monitorar conexões e consultas ao banco.
• Utilizar filas com políticas de distribuição adequadas.
• Aplicar limites de utilização por plano contratado.

Uma aplicação pode, por exemplo, executar relatórios pesados em workers separados, impedindo que essas tarefas disputem diretamente os mesmos recursos utilizados pelas requisições interativas.

Quando necessário, clientes com maior demanda podem ser direcionados para ambientes próprios.

Como planejar segurança e LGPD em aplicações multitenant?

A segurança de uma aplicação SaaS deve contemplar a proteção dos dados, o controle de acesso e a prevenção de operações não autorizadas entre clientes.

Quando existe tratamento de dados pessoais, também é necessário avaliar as obrigações aplicáveis da Lei Geral de Proteção de Dados (LGPD).

Entre as medidas técnicas relevantes estão:

• Autenticação e autorização com contexto de tenant validado.
• Princípio do menor privilégio.
• Criptografia de dados em trânsito e em repouso.
• Gestão segura de credenciais e segredos.
• Registro de eventos administrativos.
• Testes de acesso cruzado entre clientes.
• Backups e procedimentos de recuperação.
• Atualização de sistemas e componentes.

A OWASP recomenda que o contexto do tenant seja obtido de uma identidade verificada e aplicado de forma consistente às consultas, caches e operações de armazenamento.

Também é importante revisar o tratamento de dados pessoais conforme a Lei nº 13.709/2018.

A contratação de infraestrutura no Brasil não garante automaticamente conformidade com a LGPD. A adequação depende dos processos, controles e responsabilidades envolvidos no tratamento dos dados.

Quais métricas monitorar em um servidor dedicado para SaaS?

O monitoramento deve relacionar a utilização dos recursos físicos à experiência de cada cliente da aplicação.

Entre os principais indicadores estão:

Os registros devem permitir identificar o tenant associado às operações, respeitando as políticas de privacidade e evitando exposição desnecessária de dados sensíveis.

Também é importante estabelecer alertas e acompanhar tendências para identificar a necessidade de expansão antes que a capacidade disponível comprometa o serviço.

Como escolher a arquitetura de isolamento para sua aplicação SaaS?

A escolha deve considerar os requisitos de segurança, o comportamento dos workloads, o modelo comercial e a capacidade operacional da equipe.

Uma avaliação inicial pode seguir cinco etapas:

1. Classificar os clientes: identificar requisitos de segurança, volume de dados e demanda computacional.
2. Mapear as dependências: identificar componentes compartilhados e recursos que precisam de separação.
3. Definir limites: estabelecer políticas de acesso, cotas e regras de comunicação.
4. Testar a arquitetura: validar isolamento, desempenho e comportamento sob carga.
5. Planejar a expansão: estabelecer critérios para distribuir serviços ou migrar clientes para ambientes dedicados.

Em plataformas com clientes de diferentes portes, uma arquitetura híbrida pode permitir a combinação de eficiência operacional e isolamento direcionado.

Já aplicações com exigências contratuais específicas podem demandar bancos de dados, máquinas virtuais ou servidores físicos separados.

A decisão deve ser validada com testes técnicos e análise dos requisitos de cada ambiente.

A abordagem da EVEO para aplicações SaaS em servidores dedicados

Aplicações SaaS precisam de infraestrutura dimensionada para suportar múltiplos clientes, diferentes padrões de utilização e crescimento contínuo da demanda.

Com os Servidores Dedicados da EVEO, oferecemos recursos físicos exclusivos de processamento, memória e armazenamento, permitindo que sua empresa configure o ambiente conforme a arquitetura da aplicação.

Entre os recursos disponíveis estão:

• Servidores bare metal com CPU, RAM e armazenamento exclusivos.
• Configurações personalizadas para diferentes workloads.
• Opções de armazenamento SSD e NVMe.
• Conectividade de 1 ou 10 Gbps, conforme a configuração.
• Tráfego ilimitado.
• Infraestrutura em Data Centers Tier III.
• Suporte técnico 24/7 em português.
• Mensalidade fixa em reais.

O ambiente bare metal permite implementar soluções de virtualização, containers e bancos de dados conforme os requisitos técnicos e as tecnologias compatíveis com a configuração contratada.

Para aplicações que precisam de recursos isolados por cliente, também é possível avaliar a distribuição dos workloads entre servidores ou ambientes separados.

Com uma arquitetura adequada, sua empresa pode estabelecer políticas de isolamento e dimensionar a capacidade de processamento com maior previsibilidade.

Sobre o autor

Fabio Stein é CTO da EVEO e atua com tecnologia e infraestrutura para aplicações empresariais, incluindo servidores dedicados, ambientes de nuvem privada e soluções de processamento de alto desempenho.