Um fornecedor de software de RH baseado em nuvem operava uma plataforma SaaS multilocatário que atendia mais de trezentos clientes corporativos. Quando um de seus maiores clientes sofreu uma violação, iniciada por meio de uma credencial de administrador comprometida, a equipe de resposta a incidentes do fornecedor investigou e conteve a violação em quarenta e oito horas. A investigação concluiu que a violação havia ficado contida no locatário afetado e não havia se propagado para os dados de outros clientes. Essa conclusão se baseou na análise dos logs de acesso a dados do locatário afetado e dos controles de segmentação de rede entre os ambientes dos locatários. Três semanas depois, um segundo cliente contatou o fornecedor após descobrir que seus dados de RH haviam sido acessados a partir de um endereço IP desconhecido. A investigação conjunta subsequente revelou que o atacante inicial, depois de obter acesso ao locatário do primeiro cliente, havia identificado uma vulnerabilidade na camada de isolamento de locatários do fornecedor: uma configuração incorreta nos controles de acesso ao banco de dados compartilhado que permitia ao atacante acessar tabelas específicas além das fronteiras entre locatários. A investigação inicial do fornecedor havia confirmado que o atacante não se movera lateralmente pela rede, o que era correto, mas não detectara que o atacante havia acessado dados de outros locatários por meio da camada de banco de dados mal configurada. A abordagem da investigação verificou os controles de rede. O ataque explorou a camada de dados.
Qual é, de fato, o problema da detecção de ataques entre locatários?
A detecção de ataques entre locatários é o desafio de identificar quando um comprometimento de segurança que afeta o ambiente de um cliente em uma plataforma multilocatário acessou, ou tem potencial para acessar, os ambientes de outros clientes por meio de componentes de infraestrutura compartilhada. As plataformas multilocatário compartilham infraestrutura para oferecer serviços com boa relação custo-benefício: bancos de dados, capacidade computacional, redes e componentes de middleware compartilhados. Esses componentes compartilhados criam possíveis caminhos para acessos entre locatários quando os controles de isolamento que deveriam impedir que um locatário acesse os dados de outro apresentam vulnerabilidades ou configurações incorretas.
A lacuna na metodologia de investigação é a falha de detecção específica. As investigações pós-violação em ambientes multilocatário normalmente se concentram no locatário comprometido: analisam o acesso do atacante dentro do ambiente desse locatário, confirmam que o isolamento de locatários na camada de rede resistiu e determinam o escopo dos dados acessados no locatário comprometido. Essa metodologia de investigação identifica com precisão o movimento lateral na camada de rede. Ela pode não detectar acessos entre locatários na camada de dados, ou seja, ataques que exploram permissões mal configuradas em bancos de dados compartilhados, falhas de controle de acesso em API ou outras vulnerabilidades da camada de dados para acessar dados de outros locatários sem realizar o movimento lateral na camada de rede que a investigação verifica.
O problema da suposição de isolamento de locatários é a causa raiz. As plataformas multilocatário implementam o isolamento de locatários em várias camadas (rede, aplicação e dados), e a metodologia de investigação da equipe de segurança tende a verificar a camada em que ela mais confia. Um fornecedor com forte isolamento de rede pode verificar essa camada minuciosamente e ser menos sistemático nas verificações da camada de dados. Um atacante que pesquisou a arquitetura do fornecedor sabe qual camada de isolamento atacar para obter acesso entre locatários.
- Investigação verificando a camada de rede enquanto o ataque usava a camada de dados
- Suposição de isolamento de locatários não testada de forma abrangente após a violação
- Isolamento em várias camadas não verificado: a rede foi confirmada, mas a camada de dados não foi verificada
- Notificação tardia do segundo locatário: três semanas de exposição sem notificação para o Cliente B
- Acesso entre locatários por meio de infraestrutura compartilhada fora da lista de verificação da investigação de violações
Por que isso importa
A detecção de ataques entre locatários é relevante para TPRM porque os clientes de plataformas multilocatário enfrentam um risco de violação que se origina no ambiente de outro cliente, um risco que está totalmente fora do seu controle e que depende da capacidade do fornecedor de detectar acessos entre locatários e notificar os clientes afetados. O cliente que confia na conclusão da investigação do fornecedor de que “a violação não se propagou” deve entender qual metodologia de investigação produziu essa conclusão e se essa metodologia detectaria as técnicas específicas de acesso entre locatários relevantes para a arquitetura do fornecedor.
A consequência do atraso na notificação é a dimensão regulatória. Um atraso de três semanas na notificação de um segundo cliente cujos dados foram acessados significa um atraso de três semanas na resposta à violação e no cronograma de notificação regulatória desse segundo cliente. O prazo de notificação do GDPR do segundo cliente começa a contar quando ele toma conhecimento, mas a sua exposição efetiva começou quando o atacante acessou o seu locatário, e não quando ele recebeu a notificação tardia do fornecedor.
Onde a maioria das equipes erra
A falha mais recorrente é aceitar a garantia de contenção da violação dada pelo fornecedor sem entender a metodologia de investigação que produziu essa garantia. Uma contenção entre locatários confirmada pela análise da camada de rede não confirma a contenção na camada de dados.
- Garantia de contenção da violação aceita sem revisão da metodologia de investigação
- Testes de isolamento em várias camadas não verificados: camada de rede, de dados e de aplicação
- Nenhuma auditoria, do lado do cliente, de acessos entre locatários ao próprio locatário durante a violação de outro cliente
- Revisão dos controles de acesso ao banco de dados compartilhado não acionada pelo incidente de outro cliente
- Escopo da investigação do fornecedor não revisado quanto a lacunas de metodologia
Como é uma boa prática
Protocolos maduros de resposta a incidentes entre locatários investigam todas as camadas da infraestrutura compartilhada (rede, aplicação e dados) quando uma violação é detectada em qualquer locatário, e verificam explicitamente, em cada camada, que não houve acesso entre locatários.
- Investigação entre locatários em várias camadas: camadas de rede, aplicação e dados, todas verificadas
- Análise dos logs de acesso ao banco de dados compartilhado de todos os locatários quando um deles sofre uma violação
- Teste de isolamento entre locatários como etapa padrão da investigação de violações
- Notificação proativa aos colocatários quando houver infraestrutura compartilhada envolvida na investigação
- Documentação da arquitetura de isolamento de locatários analisada na investigação da violação
Ferramentas
Segurança em nuvem: plataformas de CSPM, SIEM nativo de nuvem com visibilidade entre locatários
As plataformas de gestão da postura de segurança em nuvem que monitoram infraestruturas multilocatário podem oferecer visibilidade sobre acessos entre locatários, identificando quando componentes compartilhados são acessados além das fronteiras entre locatários. Para profissionais de TPRM, perguntar se o monitoramento de CSPM do fornecedor cobre tentativas de acesso a dados entre locatários constitui uma pergunta específica sobre o monitoramento do isolamento.
Desafios de governança
O desafio de governança da detecção entre locatários é a exigência de ampliar o escopo da investigação. Quando uma violação é detectada em um locatário, investigar toda a infraestrutura compartilhada em busca de acessos entre locatários exige acesso a todos os ambientes de locatários, ao qual a equipe de investigação pode não ter acesso rotineiro e que pode suscitar preocupações de privacidade para outros clientes. A solução de governança é incorporar a verificação do isolamento entre locatários à lista de verificação padrão de investigação de violações antes que os incidentes a exijam.
- Solicitar a metodologia de investigação entre locatários: o que é verificado quando qualquer locatário sofre uma violação
- Perguntar se os logs de acesso ao banco de dados compartilhado são analisados em todos os locatários durante uma investigação
- Solicitar a documentação da arquitetura de isolamento de locatários: o que é compartilhado e o que é isolado
- Perguntar sobre a notificação proativa aos colocatários quando houver infraestrutura compartilhada envolvida
- Solicitar evidências de testes de intrusão entre locatários nos componentes de infraestrutura compartilhada
Se você faz parte de uma equipe pequena
Para o seu fornecedor multilocatário mais importante, faça duas perguntas. Primeira: quando o locatário de outro cliente na sua plataforma sofre uma violação, qual é o seu procedimento de investigação para determinar se o comprometimento acessou dados de algum outro locatário? Especificamente, esse procedimento verifica a camada de acesso ao banco de dados e a camada de acesso da aplicação, e não apenas a movimentação na camada de rede? Segunda: se essa investigação identificasse um risco de acesso entre locatários, em que momento vocês nos notificariam, mesmo que a investigação ainda não tivesse confirmado o acesso ao nosso locatário específico? Essas duas perguntas revelam a profundidade da investigação e o gatilho de notificação em violações de colocatários.
- Perguntar sobre a metodologia de investigação entre locatários: quais camadas são verificadas
- Perguntar em que momento os colocatários são notificados durante a investigação de uma violação de outro locatário
- Solicitar uma visão geral da arquitetura de isolamento de locatários
- Perguntar sobre a visibilidade dos logs de acesso ao banco de dados compartilhado durante investigações
O que exigir
Pergunte diretamente:
“Quando o locatário de outro cliente na sua plataforma sofre uma violação, o seu procedimento de investigação verifica especificamente se o atacante acessou componentes de infraestrutura compartilhada, incluindo as camadas de acesso ao banco de dados, que poderiam permitir o acesso a dados entre locatários? E em que momento nós seríamos notificados?”
O que esperar como evidência
- Lista de verificação da investigação entre locatários: quais camadas são verificadas
- Gatilho e prazo da notificação aos colocatários
- Documentação da arquitetura de isolamento de locatários
- Procedimento de revisão dos controles de acesso ao banco de dados compartilhado
Um fornecedor que confirma o isolamento de locatários deve ser questionado sobre qual metodologia de investigação confirma o isolamento após uma violação, especificamente se a camada de dados é verificada além da camada de rede. A arquitetura de isolamento descreve o desenho. A metodologia de investigação descreve como o isolamento é verificado quando o desenho é posto à prova por um atacante.
Como comprovar
- Registros da metodologia de investigação entre locatários
- Documentação da arquitetura de isolamento de locatários
- Procedimento de notificação aos colocatários
- Evidências de testes de isolamento em várias camadas
Principal conclusão
A investigação confirmou que a violação não se propagou pela rede. O atacante usou a camada de banco de dados. As duas afirmações eram verdadeiras ao mesmo tempo. A metodologia de investigação verificou uma camada e confirmou a contenção nessa camada. O atacante explorou outra camada. Três semanas depois, o Cliente B foi notificado. A violação havia permanecido ativa no locatário dele durante as três semanas seguintes à confirmação inicial de contenção pelo fornecedor. O isolamento entre locatários exige uma investigação em várias camadas: rede, aplicação e dados. Uma metodologia de investigação que verifica apenas a camada em que a equipe mais confia deixa as demais camadas como suposições não verificadas. Solicite a metodologia de investigação. Confirme que todas as camadas estão no escopo.