Em 2023, uma vulnerabilidade em uma plataforma de transferência de arquivos baseada em nuvem amplamente utilizada permitiu que atacantes se movessem lateralmente entre ambientes de clientes, não invadindo cada locatário individualmente, mas explorando fraquezas na arquitetura da plataforma que os conectava. Milhares de organizações foram afetadas. Elas não tinham nada em comum, exceto o fato de todas confiarem no mesmo fornecedor. Nenhuma delas havia avaliado se a arquitetura multilocatário desse fornecedor oferecia isolamento adequado entre clientes. Nenhuma delas havia perguntado se um comprometimento que afetasse outro cliente da mesma plataforma poderia alcançar seus dados. A questão nunca havia surgido, porque a maioria das organizações não pensa nos outros locatários que compartilham a infraestrutura do seu fornecedor. Até que precisem pensar.
O que são, de fato, os riscos de acesso entre locatários?
O risco de acesso entre locatários é a possibilidade de que os dados, as cargas de trabalho ou o ambiente de um cliente em uma plataforma de nuvem multilocatário sejam acessados, afetados ou comprometidos em decorrência da presença de outro cliente na mesma plataforma, ou em decorrência de fraquezas nos componentes compartilhados da plataforma que atendem todos os locatários simultaneamente. É uma categoria de risco estruturalmente invisível na maioria das avaliações de fornecedores, porque não decorre da relação do fornecedor especificamente com você. Decorre da arquitetura do fornecedor e do fato de você compartilhar essa arquitetura com todos os demais clientes que ele atende.
A multilocação é o modelo econômico fundamental do software baseado em nuvem. Um fornecedor de SaaS não constrói uma instância separada de sua plataforma para cada cliente: ele constrói uma plataforma e a particiona para que cada cliente veja apenas os seus próprios dados e configurações. Esse particionamento pode ser implementado em vários níveis: separação lógica dentro de um banco de dados compartilhado, esquemas de banco de dados separados por locatário, bancos de dados separados em infraestrutura compartilhada ou infraestrutura totalmente isolada por locatário. As implicações de segurança de cada abordagem são radicalmente diferentes, e a maioria dos clientes não tem ideia de qual modelo seus fornecedores usam.
O risco não é teórico. A separação lógica, o modelo mais comum e econômico, depende inteiramente de controles de acesso na camada de aplicação para impedir que um locatário veja os dados de outro. Se esses controles contiverem um bug, uma configuração incorreta ou uma falha de projeto, a separação falha. Um pesquisador que consulta o ID de cliente errado em um endpoint de API mal validado, uma ferramenta de suporte que agrega dados de vários locatários sem delimitação adequada ou uma tarefa em segundo plano que processa registros sem impor os limites entre locatários: qualquer um desses casos pode resultar em exposição de dados entre locatários sem envolvimento de nenhum atacante. Quando há um atacante real buscando deliberadamente essas fraquezas, a probabilidade de a exposição ser descoberta e explorada é muito maior.
O risco entre locatários se manifesta em vários padrões distintos de ataque e de falha:
- Referências diretas inseguras a objetos: APIs que aceitam identificadores de locatário ou de recurso sem validar se o usuário solicitante pertence a esse locatário, permitindo que um cliente consulte os dados de outro
- Vulnerabilidades na infraestrutura compartilhada: falhas em componentes compartilhados por todos os locatários (serviços de autenticação, pipelines de logs, processadores em segundo plano) que afetam todos os clientes simultaneamente quando exploradas
- Escalonamento de privilégios entre locatários: comprometer uma conta de baixo privilégio na plataforma e usar essa base para escalar o acesso a outros locatários por meio de interfaces administrativas compartilhadas ou de ferramentas de suporte
- Efeitos de vizinho barulhento: a atividade de um locatário consome recursos compartilhados de forma a degradar a disponibilidade ou criar canais laterais baseados em tempo para outros locatários
- Acesso de suporte e administrativo: funcionários do fornecedor com a capacidade de acessar o ambiente de qualquer locatário para fins de suporte, criando uma camada de acesso compartilhada que contorna os controles de segurança de cada locatário
Por que isso importa
O risco entre locatários é uma das dimensões menos avaliadas do risco de terceiros em nuvem justamente porque é invisível no modelo padrão de avaliação. Um questionário de fornecedores pergunta sobre as práticas de segurança do fornecedor: criptografia, controles de acesso, capacidade de resposta a incidentes. Não pergunta sobre os outros clientes que compartilham a infraestrutura do fornecedor, nem sobre como o comprometimento de um desses clientes poderia criar um caminho até os seus dados. No entanto, em uma arquitetura multilocatário, todos os demais clientes da plataforma são uma parte indireta do seu modelo de ameaças.
O cálculo do raio de impacto de um incidente entre locatários é fundamentalmente diferente do de uma violação direcionada a um fornecedor. Quando um fornecedor sofre uma violação por meio de uma vulnerabilidade em sua plataforma compartilhada, todos os clientes dessa plataforma podem ser afetados simultaneamente, independentemente de sua postura de segurança individual, da devida diligência que realizaram na contratação ou dos controles que implementaram do seu lado. Não há nada que um cliente possa fazer dentro do próprio locatário para impedir que uma vulnerabilidade entre locatários seja explorada. A proteção está inteiramente na arquitetura e na implementação do fornecedor, sobre as quais o cliente não tem controle direto.
Isso cria uma obrigação específica de devida diligência que vai além da avaliação padrão de fornecedores: avaliar a arquitetura multilocatário e os mecanismos de isolamento do fornecedor como um fator de risco em si. Um fornecedor que trata dados de organizações muito visadas (instituições financeiras, prestadores de serviços de saúde, contratados do governo) junto com clientes menos preocupados com segurança representa uma proposta de risco diferente da de um fornecedor com uma base de clientes mais homogênea. A sofisticação dos atacantes que visam um cliente da plataforma pode afetar todos os demais clientes se o isolamento for insuficiente.
Onde a maioria das equipes erra
A falha mais comum é equiparar a separação no nível da conta ao isolamento de segurança. A maioria dos clientes entende que tem sua própria conta, seu próprio login e seu próprio espaço de dados dentro da plataforma de um fornecedor. Eles interpretam isso como se seus dados estivessem isolados dos de outros clientes. O que de fato confirmaram é que a interface do usuário da aplicação mostra apenas os seus próprios dados em operação normal, e não que a arquitetura subjacente impede o acesso entre locatários em condições adversariais. São afirmações significativamente diferentes, e a maioria das organizações nunca pediu a um fornecedor que demonstrasse a segunda.
A segunda falha é não considerar o acesso do suporte do fornecedor como fator de risco entre locatários. Praticamente todo fornecedor de SaaS mantém a possibilidade de a equipe de suporte acessar os locatários dos clientes para investigar problemas, responder a chamados de suporte ou executar operações administrativas. Essa camada de acesso do suporte é uma capacidade compartilhada que existe em todos os locatários simultaneamente. Se os controles de acesso internos do fornecedor para essas ferramentas de suporte forem inadequados, ou se uma conta da equipe de suporte for comprometida, a exposição não se limita a um locatário. Ela pode abranger toda a base de clientes.
- Aceitar “os dados dos nossos clientes são separados logicamente” como evidência de isolamento adequado sem entender o que isso significa em termos de arquitetura
- Nenhuma avaliação do modelo de isolamento de locatários do fornecedor (lógico, por esquema, por banco de dados ou por infraestrutura) e das implicações de segurança de cada um
- Não perguntar sobre o acesso do suporte do fornecedor ao seu locatário específico: quem pode acessá-lo, em quais condições e com qual registro
- Não considerar a composição de clientes da plataforma do fornecedor como fator de risco: uma plataforma que atende clientes muito visados apresenta um risco entre locatários diferente do de uma que atende pequenas e médias empresas de baixo risco
- Tratar o risco entre locatários como uma preocupação do provedor de nuvem, e não como uma preocupação com a arquitetura do fornecedor
Como é uma boa prática
Organizações com avaliação madura do risco entre locatários tratam o isolamento de locatários como uma questão de primeira ordem na devida diligência de fornecedores, e não como algo secundário. Elas entendem que a arquitetura do fornecedor é tão relevante para a sua postura de segurança quanto as políticas do fornecedor e fazem perguntas destinadas a revelar como o isolamento é de fato implementado, e não apenas se ele existe.
- Modelo de isolamento de locatários documentado nos registros de avaliação do fornecedor (separação lógica, por esquema, por banco de dados ou infraestrutura dedicada), com compreensão do que cada um implica
- Controles de acesso do suporte do fornecedor avaliados: quem, no fornecedor, pode acessar o seu locatário, mediante qual processo de autorização e o que é registrado quando isso acontece
- Histórico de incidentes entre locatários analisado: o fornecedor já sofreu alguma exposição de dados entre locatários e, em caso afirmativo, qual foi a sua resposta e quais mudanças de arquitetura se seguiram?
- Escopo dos testes de intrusão confirmado: os testes de segurança do fornecedor incluem cenários de ataque entre locatários, e os resultados estão disponíveis para os clientes?
- Residência e isolamento de dados definidos em contrato: o contrato especifica como o isolamento de locatários é implementado e quais medidas corretivas existem caso ele falhe
Ferramentas
A avaliação do risco entre locatários é principalmente uma avaliação de arquitetura e de governança, e não um problema de ferramentas. No entanto, várias ferramentas apoiam as obrigações de devida diligência e de monitoramento do lado do cliente que ela cria.
Gestão da postura de segurança de SaaS: AppOmni, Obsidian Security, Valence Security
As ferramentas de SSPM oferecem visibilidade sobre como as plataformas SaaS estão configuradas e são usadas dentro do locatário de um cliente. Elas revelam integrações com privilégios excessivos, concessões excessivas de acesso a dados e padrões de uso anômalos que podem indicar exposição entre locatários. Para profissionais de TPRM, elas também fornecem evidências de monitoramento ativo da camada de responsabilidade do cliente dentro das plataformas SaaS, demonstrando que a organização não confia passivamente nas alegações de isolamento do fornecedor.
Agentes de segurança de acesso à nuvem: Netskope, Microsoft Defender for Cloud Apps, Zscaler
Os CASBs oferecem visibilidade e controle sobre os dados que entram e saem das plataformas SaaS, incluindo detecção de anomalias nos padrões de acesso a dados. Em um incidente entre locatários, um CASB pode detectar volumes ou padrões incomuns de acesso a dados antes que o fornecedor identifique o problema, oferecendo um alerta precoce e evidências para a resposta a incidentes.
Plataformas de avaliação de segurança de fornecedores: OneTrust, ProcessUnity, Vanta
Essas plataformas apoiam avaliações estruturadas de risco de fornecedores que podem ser configuradas para incluir perguntas específicas sobre o risco entre locatários. O essencial é garantir que o modelo de avaliação vá além do conteúdo padrão dos questionários de segurança e inclua perguntas específicas sobre a arquitetura relativas ao isolamento de locatários, aos controles de acesso do suporte e ao histórico de incidentes entre locatários.
Programas de recompensa por bugs e de divulgação de vulnerabilidades: HackerOne, Bugcrowd
Um fornecedor com um programa ativo de recompensa por bugs que inclui cenários de ataque entre locatários no escopo assumiu um compromisso público significativo de identificar essas vulnerabilidades. A existência desse programa, e o histórico do fornecedor na resposta e na remediação de achados entre locatários, é um sinal concreto de maturidade de segurança da arquitetura que vai além de uma declaração de política.
Desafios de governança
O desafio de governança do risco entre locatários é que ele fica fora do modelo padrão de avaliação de risco de fornecedores. A maioria dos programas de TPRM avalia os controles de segurança do fornecedor conforme se aplicam aos dados e à relação do cliente. O risco entre locatários exige avaliar a arquitetura do fornecedor conforme se aplica a toda a população de clientes, uma avaliação mais ampla e menos familiar que a maioria dos frameworks de avaliação não foi projetada para realizar.
A resposta prática é incorporar a avaliação entre locatários à classificação de fornecedores por níveis e à devida diligência como uma dimensão de risco específica, ponderada pela sensibilidade dos dados tratados e pela provável composição da base de clientes do fornecedor. Um fornecedor que trata dados regulados altamente sensíveis junto com os de muitos outros clientes justifica uma devida diligência arquitetural mais aprofundada do que um que lida com dados operacionais de baixa sensibilidade em uma implantação dedicada.
- Incluir o isolamento de locatários no seu questionário padrão de fornecedores como seção obrigatória para qualquer fornecedor baseado em nuvem que trate dados sensíveis
- Solicitar os relatórios de testes de intrusão do fornecedor, com atenção específica à inclusão de cenários de ataque entre locatários no escopo
- Analisar as divulgações históricas de incidentes do fornecedor em busca de eventos de exposição de dados entre locatários: eles costumam ser minimizados nas respostas aos questionários
- Exigir em contrato a notificação, dentro de um prazo definido, caso o fornecedor tome conhecimento de qualquer vulnerabilidade ou incidente entre locatários que possa ter afetado os seus dados
- Considerar a locação dedicada para as relações com fornecedores de maior risco: alguns fornecedores oferecem, com custo adicional, isolamento no nível da infraestrutura que elimina totalmente o risco dos componentes compartilhados
Se você faz parte de uma equipe pequena
Comece identificando quais dos seus fornecedores de SaaS tratam os seus dados sensíveis mais críticos em um ambiente multilocatário compartilhado. Para esses fornecedores, inclua três perguntas na próxima conversa de avaliação: como o isolamento de locatários é implementado no nível da arquitetura, quem no fornecedor pode acessar o seu locatário específico e em quais condições, e se o fornecedor já sofreu alguma exposição de dados entre locatários. As respostas mostrarão se o risco está sendo gerenciado ou simplesmente ignorado por suposição.
- Revisar os seus contratos com fornecedores quanto à redação sobre isolamento de dados: referências vagas a “separação lógica” sem detalhes de arquitetura são uma lacuna que vale a pena corrigir
- Perguntar aos seus fornecedores de SaaS de maior sensibilidade se a locação dedicada está disponível e a que custo: vale a pena avaliá-la para as suas relações mais críticas
- Ativar todos os registros de auditoria que as suas plataformas SaaS oferecem para o seu próprio locatário: isso não impedirá incidentes entre locatários, mas ajudará a detectá-los e a responder a eles
- Verificar se os seus fornecedores SaaS críticos têm programas ativos de recompensa por bugs e se as vulnerabilidades entre locatários estão incluídas no escopo
O que exigir
Pergunte diretamente:
“Como o isolamento de locatários é implementado na arquitetura da sua plataforma: separação lógica dentro de um banco de dados compartilhado, separação por esquema, bancos de dados separados ou infraestrutura dedicada por cliente?”
“Em quais condições a sua equipe de suporte ou de engenharia pode acessar o nosso locatário específico, qual autorização é necessária e o que é registrado quando isso acontece?”
“A sua plataforma já sofreu alguma exposição ou vulnerabilidade de dados entre locatários? Em caso afirmativo, qual foi o impacto, qual foi a sua resposta e quais mudanças de arquitetura vocês fizeram?”
O que esperar como evidência
- Uma descrição clara da arquitetura de isolamento de locatários: não uma declaração de marketing, mas uma explicação técnica
- Documentação dos controles de acesso do suporte, incluindo requisitos de autorização e registros de auditoria
- Relatórios de testes de intrusão ou resumos executivos que confirmem que cenários entre locatários foram testados
- Compromissos contratuais de isolamento de dados com medidas corretivas definidas caso o isolamento falhe
Um fornecedor que responde à pergunta sobre isolamento com “seus dados estão completamente seguros na sua conta” descreveu a experiência do usuário, e não a arquitetura. Insista na resposta técnica.
Como comprovar
O risco entre locatários é cada vez mais reconhecido nos marcos regulatórios como uma dimensão da devida diligência de fornecedores de nuvem. Demonstrar que a sua organização avaliou esse risco, e não apenas aceitou as garantias do fornecedor, exige evidências documentadas de avaliação da arquitetura, e não apenas o preenchimento de questionários.
- Registros de avaliação de fornecedores que documentam o modelo de isolamento de locatários de cada plataforma SaaS que trata dados sensíveis
- Evidências da análise do histórico de incidentes entre locatários como parte da devida diligência do fornecedor
- Cláusulas contratuais que especificam compromissos de isolamento de locatários e obrigações de notificação de violações
- Registros da revisão do escopo dos testes de intrusão que confirmem a inclusão de cenários entre locatários
- Documentação das decisões em todos os casos em que a locação dedicada foi avaliada e adotada ou recusada, com justificativa documentada
Principal conclusão
Cada fornecedor que você usa em um ambiente de nuvem multilocatário conecta você, de forma indireta mas significativa, a todos os demais clientes dessa plataforma. A sua postura de segurança dentro do seu próprio locatário é irrelevante se a arquitetura que separa você dos outros locatários for inadequada. Não é possível eliminar uma vulnerabilidade entre locatários aplicando correções, contorná-la com configurações nem chegar à segurança por meio de avaliações sem perguntar especificamente como o isolamento funciona e se ele já falhou. O risco entre locatários não é exótico: é uma característica estrutural de toda plataforma multilocatário da qual você depende. A única questão é se você o avaliou.