A operação precisa responder “o que aconteceu com o job deste cliente?” sem transformar logs compartilhados num navegador de dados entre contas. Contexto de tenant ajuda em diagnóstico, suporte e medição, mas não garante isolamento. O identificador precisa vir de identidade confiável, payloads sensíveis devem ser minimizados e a busca de logs precisa de autorização própria.
Um tenant enviado em query string, header arbitrário ou mensagem de log não prova escopo. Resolva-o pelo principal autenticado e pelo recurso autorizado; propague um identificador canônico e opaco. Jobs assíncronos devem guardar a vinculação verificada e revalidar acesso na execução.
Prefira identificadores pseudônimos. Mesmo IDs em logs e métricas podem revelar relações comerciais e gerar cardinalidade alta. Separe correlação de nomes de empresas, e-mails e números de conta.
| Campo útil | Forma mais segura | Evite |
|---|---|---|
| Tenant | Chave opaca vinda da identidade confiável | Nome do cliente ou tenant bruto do request |
| Operação | Evento normalizado e código de resultado | Corpo completo da requisição/resposta |
| Recurso | ID interno ou pseudônimo quando necessário | Credenciais, dados de pagamento ou conteúdo sensível |
| Correlação | Trace ID e job ID com controle de acesso | Token de sessão ou credencial reutilizável |
| Falha | Classe de erro sanitizada e status da dependência | Exceção bruta com segredo ou entrada de usuário |
Sanitize entradas para bloquear log injection por quebras de linha e delimitadores. Masque no limite da aplicação, antes de serializar; mascaramento posterior não evita acesso de coletores, arquivos ou operadores ao fluxo bruto. Use campos permitidos em eventos de segurança em vez de “logar tudo” para ajudar no suporte.
Autorização do produto não protege automaticamente a plataforma de logs. Restrinja quem pode pesquisar dados por tenant, diferencie suporte de administração da plataforma e registre consultas excepcionais. Exportações para clientes devem ser filtradas no servidor com a identidade autenticada, nunca apenas no navegador. Teste que um usuário não consegue trocar o seletor de tenant e ver eventos de outra conta.
Quebra de vidro para incidentes deve exigir justificativa, prazo e auditoria, não uma conta administrativa compartilhada permanente. Defina retenção e exclusão conforme compromissos de privacidade e requisitos legais.
IDs de tenant podem gerar cardinalidade alta quando anexados a toda métrica. Mantenha dimensões detalhadas em logs ou traces protegidos e use métricas agregadas para saúde do serviço. Aplique amostragem em sucessos rotineiros, retenha eventos de segurança conforme política e limite payloads contra log flooding.
Execute testes com dois tenants atravessando request, fila e fluxo de suporte. Tente falsificar IDs, remover contexto, repetir jobs e consultar/exportar logs de outra conta. Verifique sucesso e negação. Use evento sintético para confirmar que dashboards e alertas não expõem dados amplamente.
Logs multi-tenant exigem identidade confiável, minimização e autorização na própria camada de observabilidade. Use IDs opacos, registre decisões em vez de payloads, restrinja suporte e teste fronteiras de ponta a ponta. Diagnóstico deve ajudar a entender o impacto sem transformar a atividade de um cliente em vazamento para outro.