Isolamento de tenants para MSPs: um tenant ID ou um login não é autorização

Um tenant ID fornecido pelo cliente, um cabeçalho X-Tenant-ID, um login que funciona, uma política de Acesso Condicional ou uma ligação SSO indicam cada um algo útil — mas nenhum deles, por si só, prova que quem chama está autorizado a ver os dados de um determinado cliente. Este guia destina-se a MSPs e equipas de TI que operam ou adquirem plataformas multi-tenant: expõe, mecanismo a mecanismo, onde uma verificação de autorização do lado do servidor tem mesmo de estar, desde o primeiro pedido até ao dia em que uma conta é desativada.

Um tenant ID apenas seleciona um cliente, não o autoriza

Um tenant ID fornecido pelo cliente — no corpo do pedido, num parâmetro de consulta, ou resolvido a partir de um subdomínio — é um seletor. Diz à aplicação qual o contexto de cliente a abrir. O OWASP Multi-Tenant Security Cheat Sheet estabelece a regra subjacente: vincular cada pedido a um principal autenticado, resolver a associação desse principal ao tenant a partir do estado do lado do servidor, aplicar verificações ao nível do objeto dentro do tenant, e manter os caminhos administrativos ou de emergência separados do acesso normal ao tenant. Essa verificação tem de funcionar onde quer que uma fronteira de tenant seja relevante, não apenas na porta de entrada da API: nas leituras e escritas, nas ações administrativas, e nas tarefas em segundo plano que retomam trabalho depois de o pedido original ter terminado. Uma tarefa acionada por uma fila que herda um tenant ID a partir de uma mensagem, sem o reverificar, reabre exatamente a falha que a verificação original devia fechar.

Um cabeçalho X-Tenant-ID ou um campo do corpo escondem a mesma armadilha

O mesmo erro aparece com o nome de um cabeçalho. As APIs multi-tenant aceitam habitualmente um cabeçalho X-Tenant-ID ou um campo tenant no corpo do pedido para escolher os dados de que cliente uma chamada deve tocar, e é tentador tratar esse valor como suficiente assim que é interpretado corretamente. As orientações da OWASP assinalam duas armadilhas relacionadas: presumir que um identificador de tenant é seguro por ser longo ou difícil de adivinhar, em vez de executar uma verificação de autorização real; e permitir que um caminho de código normalmente limitado ao tenant recorra silenciosamente a uma consulta sem limite quando o valor esperado está ausente ou mal formado. Qualquer uma destas falhas permite que alguém autenticado, mas que não pertence ao tenant pedido, aceda a dados de outra pessoa.

O login prova quem alguém é, não a que tenant pode aceder

A autenticação responde a uma pergunta diferente da isolação. A NIST Special Publication 800-210, sobre controlo de acesso para sistemas em nuvem, trata a isolação de tenants como uma propriedade que a própria plataforma tem de aplicar em cada API e caminho de dados quando uma única instância de software serve muitos tenants, porque o cliente que usa o serviço não controla a infraestrutura subjacente. O Well-Architected SaaS Lens da AWS descreve duas formas de os fornecedores construirem isto: num modelo «silo», cada tenant tem recursos dedicados e um papel de execução limitado, mais simples de compreender mas mais difícil de operar em grande escala; num modelo «pool», os tenants partilham infraestrutura e a isolação tem de ser aplicada dentro da lógica da aplicação em cada pedido. Nenhum dos modelos é inerentemente mais seguro. O que importa é se um fornecedor consegue mostrar, concretamente, como um pedido é vinculado ao tenant de quem chama antes de qualquer dado ser tocado — não que quem chama tenha um login que funciona.

O Acesso Condicional protege o login, não o caminho dos dados

A Microsoft descreve o Acesso Condicional como um motor de políticas Zero Trust baseado em lógica se-então: se um utilizador, ou cada vez mais um agente de IA, tenta aceder a um recurso, então uma condição como a conformidade do dispositivo, o risco de início de sessão ou a localização tem de ser satisfeita primeiro. Isso é uma barreira genuinamente útil — pode impedir que uma credencial comprometida sequer inicie uma sessão, ou cortar uma sessão que começa a comportar-se de forma suspeita. Mas não tem qualquer visibilidade sobre como o backend de uma aplicação decide, uma vez que uma sessão existe, que registos de que cliente uma determinada chamada de API está autorizada a ler ou escrever. Se uma plataforma confia num valor de tenant fornecido pelo cliente para tomar essa decisão, o Acesso Condicional já terminou o seu trabalho, com sucesso e de forma irrelevante para a falha, no momento em que a decisão é tomada. Uma barreira de login bem configurada à frente de uma API mal isolada produz a mesma fuga que produziria sem essa barreira. A licença Agent 365 da Microsoft está a estender o Acesso Condicional a agentes de IA, mas a mesma distinção entre login e acesso a dados continuará a aplicar-se aí.

O SSO deixa as pessoas entrar; só o SCIM faz sair quem parte

A federação responde a «quem pode iniciar sessão agora?». O System for Cross-domain Identity Management, normalizado como RFC 7644, responde a uma pergunta diferente: que contas ainda deveriam existir. A documentação de provisionamento SCIM da Microsoft descreve o fluxo habitual: uma eliminação lógica no fornecedor de identidade coloca o atributo active de um recurso de utilizador a false, e espera-se que a aplicação recetora desative ou arquive esse lugar em resposta. Sem uma integração SCIM, o início de sessão único de quem parte deixa de funcionar, mas o seu lugar — e qualquer acesso residual à API a ele ligado — pode persistir intacto. O lado do provisionamento também precisa do seu próprio âmbito: um token bearer SCIM deveria ser emitido por tenant de cliente e aceite apenas no endpoint SCIM próprio desse tenant. Partilhar um único segredo SCIM multi-tenant entre vários clientes transforma um único token vazado num risco de desprovisionamento e de tomada de conta entre clientes diferentes.

Desativar a conta não termina a sessão nem o token

Quando alguém sai e um administrador desativa a sua conta no fornecedor de identidade, é fácil presumir que o trabalho está feito. A própria orientação da Microsoft sobre revogação de acesso diz o contrário: desativar uma conta bloqueia novos logins, mas não invalida automaticamente tokens de atualização, sessões ativas ou cookies do browser já emitidos. Cortar o acesso de facto exige revogar separadamente sessões e tokens e limpar credenciais em cache — e, onde disponível, a Avaliação Contínua de Acesso aplica o corte mais depressa do que esperar que um token expire por si só. O rascunho de orientação do NIST sobre gestão de sessões faz uma observação relacionada: possuir um token de acesso válido não é prova de que uma sessão continua legitimamente aberta, e as sessões do fornecedor de identidade e da aplicação são independentes entre si, pelo que terminar uma não termina a outra. É por isso que o OWASP Session Management Cheat Sheet exige invalidação de sessão do lado do servidor com tempos limite de inatividade e absolutos, em vez de confiar que o cliente descarta as credenciais.

Alguns MSPs preferem entregar este trabalho de plano de controlo a um fornecedor dedicado em vez de o construir e auditar eles próprios; Auris é uma plataforma europeia de IAM-as-a-Service para MFA adaptativa, SSO federado e registos de auditoria imutáveis.

O que fazer

• Resolver a associação ao tenant a partir de dados de identidade do lado do servidor em cada pedido; nunca confiar apenas num ID, cabeçalho ou campo do corpo fornecido pelo cliente.
• Aplicar essa verificação em cada caminho onde uma fronteira de tenant esteja envolvida: leituras, escritas, ações administrativas e tarefas em segundo plano ou acionadas por fila.
• Rejeitar qualquer seletor de tenant que não tenha sido confirmado face às associações reais de quem chama autenticado, em vez de presumir que um identificador longo é seguro.
• Tratar o Acesso Condicional, o SSO e a vinculação ao tenant como controlos separados com modos de falha separados, e testar cada um de forma independente.
• Configurar o SCIM a par do SSO, limitar cada token SCIM a um único tenant, e confirmar que a conta de quem sai é desativada também no sistema de origem, não apenas no fornecedor de identidade.
• No offboarding, revogar explicitamente sessões e tokens de atualização em todas as aplicações que a pessoa utilizou, em vez de parar em «conta desativada».

Fontes: OWASP Multi Tenant Security Cheat Sheet, NIST SP 800-210, AWS Well-Architected SaaS Lens, Microsoft Learn — Visão geral do Acesso Condicional, Microsoft Learn — Use SCIM to provision users and groups, OWASP Session Management Cheat Sheet.