Em 2019, uma grande plataforma de nuvem divulgou que um bug em sua infraestrutura compartilhada de banco de dados havia feito com que dados de clientes fossem retornados em respostas de API pertencentes a outros tenants. O bug estava na camada de consulta: um mecanismo de cache havia associado resultados de consultas ao contexto de tenant errado, retornando os registros de um cliente à chamada de API de outro cliente. O banco de dados subjacente continha dados de todos os tenants nas mesmas tabelas, separados por identificadores de tenant. O próprio banco de dados não tinha nenhum mecanismo para impor o isolamento entre tenants; essa aplicação estava inteiramente nas camadas de aplicação e de consulta. Quando essas camadas tiveram um bug, o banco de dados não tinha nada por baixo delas para impedir a exposição de dados entre tenants. O bug foi descoberto por um cliente que percebeu estar recebendo registros que não reconhecia. Ele estava em produção por um período que o fornecedor se recusou a especificar na divulgação pública. A segregação dependia inteiramente do código. O código tinha um bug. O banco de dados não conseguia perceber a diferença.
O que é, de fato, o problema das falhas de segregação de dados?
A segregação de dados em ambientes multi-tenant é a abordagem arquitetural e técnica usada para garantir que os dados de um cliente não possam ser acessados por meio da sessão autenticada de outro cliente. Em implantações single-tenant, em que cada cliente tem seu próprio banco de dados, sua própria instância de aplicação e sua própria infraestrutura, a separação física da implantação oferece fortes garantias de segregação. Em implantações multi-tenant, em que vários clientes compartilham as mesmas tabelas de banco de dados, o mesmo código de aplicação e a mesma infraestrutura, a segregação depende de controles lógicos que precisam ser implementados corretamente e aplicados de forma consistente na camada de aplicação e de consulta.
A vulnerabilidade do isolamento de tenants na camada de aplicação é o desafio central da segurança multi-tenant. Uma cláusula WHERE que filtra registros por ID de tenant é uma implementação correta do isolamento de tenants quando é executada corretamente. Quando um bug de cache associa o contexto de tenant errado a uma resposta, quando um caminho de código deixa de incluir o filtro de tenant, quando uma operação em massa se aplica a todos os tenants quando deveria se aplicar a um só, ou quando um erro de configuração permite acesso de API entre tenants, em cada um desses cenários o banco de dados nada faz para impedir a exposição entre tenants, porque contém os dados de todos os tenants e não tem controle de acesso por tenant. O isolamento está inteiramente na camada de aplicação, e a camada de aplicação tem bugs.
As alternativas arquiteturais ao isolamento na camada de aplicação oferecem garantias de segregação mais fortes, com custos operacionais variados. As implantações com schema por tenant dão a cada cliente seu próprio schema de banco de dados no mesmo mecanismo de banco de dados, oferecendo isolamento em nível de schema imposto pelo próprio banco de dados, e não pelo código da aplicação. As implantações com banco de dados por tenant dão a cada cliente sua própria instância de banco de dados, oferecendo a garantia de isolamento mais forte, equivalente a uma implantação single-tenant. Essas abordagens têm custo operacional maior do que o multi-tenancy com tabelas compartilhadas e não estão disponíveis em todas as plataformas SaaS, mas representam uma postura de risco significativamente diferente para a segurança da segregação de dados.
As falhas de segregação de dados se concentram em cinco padrões específicos de vulnerabilidade em ambientes multi-tenant:
- Bugs no filtro de tenant da camada de aplicação: defeitos de código que fazem com que os filtros de ID de tenant sejam omitidos, aplicados incorretamente ou anulados em caminhos de código específicos, resultando em acesso a dados entre tenants
- Erros de contexto de tenant na camada de cache: mecanismos de cache que associam resultados de consultas ou respostas de API a contextos de tenant incorretos, entregando os dados de um cliente à sessão de outro cliente
- Exposição entre tenants em operações em massa: operações administrativas ou de manutenção que se aplicam a todos os tenants quando deveriam se restringir a um tenant específico
- Manipulação de parâmetros de API: parâmetros de identificador de tenant em chamadas de API que podem ser modificados por um cliente para acessar recursos de outro tenant se o contexto de tenant no servidor não for verificado de forma independente
- Exposição por canal lateral em infraestrutura compartilhada: ataques de temporização, exposição de memória compartilhada ou padrões de disputa por recursos em infraestrutura compartilhada que vazam informações entre cargas de trabalho de tenants
Por que isso importa
As falhas de segregação de dados importam para TPRM porque representam uma categoria de risco específica das plataformas multi-tenant, capaz de expor dados de clientes a outros clientes sem nenhuma participação de um atacante, por meio de bugs, erros de configuração e falhas de projeto intrínsecos à arquitetura multi-tenant. O bug da plataforma de nuvem descrito na abertura não exigiu um atacante. Um cliente autenticado corretamente recebeu dados incorretos na resposta da API. A segregação falhou por um defeito de software, e não por um ataque de segurança.
O risco multi-tenant é qualitativamente diferente do risco de uma implantação single-tenant. Em uma implantação single-tenant, uma falha de segurança expõe os dados daquele cliente. Em uma implantação multi-tenant, uma falha de segregação expõe os dados de qualquer cliente à sessão de qualquer outro cliente: o escopo da exposição potencial é toda a população de tenants da plataforma, e não apenas o cliente que sofreu a falha. Um bug que causa vazamento de dados entre tenants é, ao mesmo tempo, uma violação para cada cliente cujos dados foram expostos e uma violação para cada cliente que recebeu dados que não eram seus.
Para profissionais de TPRM, a avaliação da segregação de dados exige entender o mecanismo arquitetural do isolamento de tenants, e não apenas confirmar que a segregação existe como propriedade declarada. Multi-tenancy com tabelas compartilhadas e isolamento na camada de aplicação, schema por tenant e banco de dados por tenant representam posturas de risco significativamente diferentes, e a pergunta de avaliação 'seus dados são segregados?' não distingue entre elas.
Onde a maioria das equipes erra
A falha mais recorrente é aceitar a segregação de dados como uma propriedade binária, segregado ou não, sem perguntar sobre o mecanismo arquitetural que a implementa. Um fornecedor de plataforma multi-tenant com tabelas compartilhadas que confirma a segregação de dados está dizendo a verdade: os dados dos clientes estão logicamente separados por ID de tenant. Se essa separação lógica pode falhar em razão de um defeito de software é uma questão arquitetural que a confirmação binária não responde.
A segunda falha é não perguntar sobre testes de intrusão entre tenants. Testes que confirmam que a aplicação impõe corretamente o isolamento de tenants em condições normais não confirmam que o isolamento se mantém em condições adversariais, ou seja, que um cliente que tente acessar os dados de outro tenant por meio de manipulação de parâmetros de API, modificação de consultas ou técnicas conhecidas de contorno não consiga fazê-lo. O teste de intrusão entre tenants é um objetivo de teste específico que precisa estar explicitamente no escopo para ser realizado.
- Aceitar a confirmação de segregação sem o mecanismo arquitetural: tabela compartilhada, schema por tenant e banco de dados por tenant representam posturas de risco diferentes
- Nenhum teste de intrusão entre tenants: testes de segurança que não tentam explicitamente quebrar o isolamento de tenants
- Risco do isolamento na camada de aplicação não avaliado: dependência da correção do código para a separação de tenants, sem controles arquiteturais independentes
- Isolamento de tenants na camada de cache não questionado: mecanismos de cache como vetor específico de vulnerabilidade de segregação
- Exposição entre tenants em operações em massa não tratada: operações administrativas que podem afetar vários tenants
Como é uma boa prática
Programas maduros de segregação multi-tenant implementam defesa em profundidade, aplicando o isolamento de tenants em várias camadas arquiteturais para que uma falha em uma camada seja detectada pelos controles de outra. Filtros de tenant na camada de aplicação, políticas de segurança em nível de linha no banco de dados, isolamento em nível de schema e testes de intrusão entre tenants se combinam para oferecer uma garantia de segregação que nenhuma camada arquitetural isolada consegue oferecer.
- Políticas de segurança em nível de linha no banco de dados: segurança em nível de linha imposta pelo banco de dados, que acrescenta uma camada de segregação independente do código da aplicação
- Schema ou banco de dados por tenant para os dados de maior sensibilidade: isolamento arquitetural imposto pelo mecanismo de banco de dados, independentemente do código da aplicação
- Testes de intrusão entre tenants: objetivos de teste explícitos que tentam quebrar o isolamento de tenants por meio de manipulação de API, exploração de cache e contorno dos filtros da camada de aplicação
- Revisão de código do isolamento de tenants: revisão de código de segurança específica, focada na implementação e na completude do filtro de tenant em todos os caminhos de acesso a dados
- Validação do contexto de tenant na camada de cache: testes explícitos dos mecanismos de cache quanto à associação de contexto entre tenants
Ferramentas
Implementar e testar a segregação de dados multi-tenant exige tanto controles arquiteturais quanto ferramentas de teste projetadas especificamente para o problema da verificação do isolamento de tenants.
Segurança em nível de linha no banco de dados: PostgreSQL RLS, Oracle VPD, SQL Server RLS
Os recursos de segurança em nível de linha dos bancos de dados relacionais oferecem isolamento de tenants imposto pelo banco de dados, aplicando políticas de acesso no nível do mecanismo de banco de dados que restringem cada sessão às linhas correspondentes ao seu contexto de tenant. O Row Level Security do PostgreSQL permite políticas que filtram os resultados das consultas por ID de tenant na camada de banco de dados, oferecendo um ponto de aplicação da segregação independente da camada de aplicação. Para profissionais de TPRM, perguntar se o fornecedor usa políticas de segurança em nível de linha no banco de dados, além da filtragem de tenants na camada de aplicação, é a pergunta sobre segregação com defesa em profundidade que a confirmação de uma única camada não responde.
Testes de segurança multi-tenant: Burp Suite, OWASP Testing Guide for Multi-Tenant
O teste de intrusão entre tenants exige uma metodologia de teste específica: enumerar identificadores de tenant, tentar a manipulação de parâmetros de API, testar o acesso a recursos entre tenants e verificar se o contexto de tenant é imposto no servidor em todos os endpoints de API. Para profissionais de TPRM, exigir que a quebra do isolamento entre tenants seja um objetivo explícito do teste de intrusão revela se o teste de segurança multi-tenant mais específico foi realizado.
Isolamento de cargas de trabalho em nuvem: AWS Organizations, Azure Management Groups, GCP Resource Hierarchy
Para fornecedores que usam infraestrutura em nuvem, o isolamento de cargas de trabalho entre tenants pode ser implementado no nível da conta ou do projeto na nuvem, oferecendo uma separação no nível da infraestrutura que complementa o isolamento no banco de dados e na aplicação. Para profissionais de TPRM, perguntar se os tenants com os requisitos de sensibilidade mais altos podem ser hospedados em infraestrutura isolada, em vez de compartilhada, revela se existem opções de isolamento arquitetural para as implantações de maior risco.
Desafios de governança
O desafio de governança da segregação de dados multi-tenant é que o risco é arquitetural, pois decorre da decisão de projeto de usar infraestrutura compartilhada, e riscos arquiteturais exigem mitigações arquiteturais que não podem ser totalmente tratadas apenas com controles. A filtragem de tenants na camada de aplicação pode se tornar mais robusta com controles de defesa em profundidade, revisão de código e testes. Ela não pode se tornar equivalente ao isolamento com banco de dados por tenant, porque a diferença arquitetural fundamental (o código da aplicação pode ter bugs, enquanto o isolamento no nível do banco de dados é imposto pelo mecanismo de banco de dados) não pode ser eliminada por nenhuma quantidade de revisão de código.
Para programas de TPRM, a abordagem prática de governança é entender a arquitetura multi-tenant de cada plataforma crítica de fornecedor e avaliar o mecanismo de segregação de acordo com ela. Fornecedores com tabelas compartilhadas justificam perguntas mais específicas sobre testes entre tenants, isolamento de cache e controles de defesa em profundidade. Fornecedores com schema por tenant justificam perguntas sobre o controle de acesso entre schemas. Fornecedores com banco de dados por tenant oferecem a garantia de segregação mais forte, mas ainda devem ser questionados sobre os controles de acesso entre bancos de dados e o isolamento da infraestrutura.
- Pergunte especificamente sobre a arquitetura multi-tenant: tabela compartilhada, schema por tenant ou banco de dados por tenant
- Exija testes de intrusão entre tenants como escopo explícito nos requisitos de avaliação de segurança de fornecedores
- Pergunte sobre segurança em nível de linha no banco de dados: se o isolamento de tenants existe na camada de banco de dados, além da camada de aplicação
- Pergunte sobre o isolamento de tenants na camada de cache: testes específicos dos mecanismos de cache quanto à exposição de contexto entre tenants
- Considere infraestrutura dedicada por tenant para as implantações de maior sensibilidade, perguntando se há opções de banco de dados por tenant ou de conta por tenant
Se você faz parte de uma equipe pequena
Acrescente duas perguntas às suas avaliações de fornecedores SaaS multi-tenant. Primeira: qual é o mecanismo arquitetural do isolamento de dados entre tenants, ou seja, os dados dos clientes são separados por colunas de ID de tenant em tabelas compartilhadas, por schemas separados por cliente ou por instâncias de banco de dados separadas por cliente? Segunda: os seus testes de intrusão tentam explicitamente acessar dados a partir da sessão de um tenant usando os identificadores de outro tenant, ou seja, a quebra do isolamento entre tenants foi um objetivo de teste definido? Essas duas perguntas revelam imediatamente a postura de risco arquitetural e se ela foi testada especificamente.
- Pergunte qual é o mecanismo específico da arquitetura multi-tenant: tabela compartilhada, schema ou banco de dados por tenant
- Pergunte se a quebra do isolamento entre tenants é um objetivo explícito do teste de intrusão
- Pergunte se existem políticas de segurança em nível de linha no banco de dados, além da filtragem de tenants na camada de aplicação
- Para as implantações de maior sensibilidade, pergunte se há opções de infraestrutura dedicada
O que exigir
Pergunte diretamente:
"Qual é o mecanismo arquitetural do isolamento de dados entre tenants: as tabelas de dados dos clientes são compartilhadas, com filtragem por ID de tenant na camada de aplicação, ou cada cliente tem um schema separado ou uma instância de banco de dados separada?"
"Os seus testes de intrusão tentam explicitamente acessar os dados de um tenant a partir da sessão de outro tenant, testando especificamente a manipulação de parâmetros de API, a modificação de consultas e o contexto de tenant na camada de cache, e a quebra do isolamento entre tenants é um objetivo de teste definido?"
"Vocês implementam políticas de segurança em nível de linha no banco de dados que imponham o isolamento de tenants na camada do mecanismo de banco de dados, independentemente da filtragem de tenants na camada de aplicação?"
O que esperar como evidência
- Descrição da arquitetura multi-tenant: mecanismo específico de isolamento
- Confirmação do escopo do teste de intrusão entre tenants, com a quebra do isolamento como objetivo explícito
- Confirmação de segurança em nível de linha no banco de dados ou de isolamento arquitetural alternativo
- Evidências de testes de isolamento de tenants na camada de cache
Um fornecedor que responde à pergunta sobre arquitetura com 'nossa plataforma é multi-tenant com segregação de dados' confirmou a intenção. Pergunte especificamente se essa segregação é imposta na camada de banco de dados por políticas de segurança em nível de linha ou apenas na camada de aplicação, pela filtragem por ID de tenant. O banco de dados não consegue mentir sobre o que impõe. A camada de aplicação pode ter bugs que a camada de banco de dados detectaria.
Como comprovar
A segregação de dados multi-tenant é tratada nos Trust Services Criteria do SOC 2 para confidencialidade e disponibilidade, nos controles da ISO 27001 para segregação de informações e em benchmarks de segurança em nuvem, incluindo os controles do CIS. Demonstrar a devida diligência exige evidências de que o mecanismo de segregação foi avaliado do ponto de vista arquitetural e testado especificamente, e não apenas confirmado como uma propriedade declarada.
- Registros de avaliação de fornecedores que documentam o mecanismo da arquitetura multi-tenant e os controles de defesa em profundidade
- Confirmação do escopo do teste de intrusão entre tenants
- Evidências de segurança em nível de linha no banco de dados ou de isolamento arquitetural
- Evidências de testes de isolamento da camada de cache
Principal conclusão
O isolamento de tenants em uma plataforma multi-tenant com tabelas compartilhadas é uma cláusula WHERE. Quando ela é aplicada corretamente, os dados ficam segregados. Quando um bug faz com que ela seja omitida, aplicada ao contexto errado ou anulada por um erro de cache, o banco de dados não tem nada por baixo para impedir a exposição entre tenants, porque ele não sabe de qual tenant são os dados que está retornando. Ele sabe o que a aplicação pediu. A aplicação pediu a coisa errada. A confirmação de segregação de dados diz que o fornecedor pretende manter separados os dados dos tenants. O mecanismo arquitetural diz como. O escopo do teste de intrusão diz se o mecanismo foi validado especificamente em condições adversariais. As três perguntas importam. A confirmação é apenas a primeira.