Tenant separa organizações e dados. Project seleciona o âmbito de associação, esquema e execução dentro do tenant. O projeto ativo é uma decisão de sessão assinada e validada pelo servidor, não um filtro cosmético.
Segurança e governação
As decisões de segurança permanecem controladas pelo servidor e ligadas ao âmbito.
A visibilidade do navegador não é um limite de autorização. Rotas protegidas, serviços de aplicações e predicados de repositório reavaliam a identidade, tenant, contexto de projeto e permissão onde a operação requer isso.
Segurança e governação
Cada pedido autenticado deve corresponder a um registo ativo ligado ao JTI do ator, ao tenant e estado do utilizador, à validade da política atual, ao timeout de inatividade e ao projeto ativo. Falha do registo, material de assinatura ausente, revogação ou identidade incompatível provocam falha fechada, sem regressar a contexto anónimo ou obsoleto.
Estão implementados metadados SAML do tenant, login e ACS, ligação ou JIT de identidade externa, política de domínio e evidência de MFA confirmada pelo IdP. A geração dos endpoints utiliza a origem pública controlada pelo servidor; a correlação AuthnRequest usa estado assinado e de curta duração do fornecedor e do pedido.
O RLS de Analytics é controlado e protegido pelo servidor. Um filtro do ambiente de execução enviado pelo cliente não pode forjar metadados de origem RLS; as identidades de cache incluem permissões e âmbito RLS, em vez de confiar apenas no texto SQL.
Credenciais, tokens, cabeçalhos de autorização, chaves privadas e URLs assinados não pertencem a metadados públicos, prompts ou payloads de auditoria genéricos. Texto mascarado não é uma credencial executável. Quando uma credencial precisa de ser revelada uma única vez, a operação é limitada, protegida em trânsito e armazenamento, breve e registada sem persistir o segredo na evidência genérica.
Tenant e Project formam o contexto de segurança ativa.
Tenant separa organizações e dados. Project seleciona o âmbito de associação, esquema e execução dentro do tenant. O projeto ativo é uma decisão de sessão assinada e validada pelo servidor, não um filtro cosmético.
O registo de sessão é autorizado após o login.
Cada pedido autenticado deve corresponder a um registo ativo ligado ao JTI do ator, ao tenant e estado do utilizador, à validade da política atual, ao timeout de inatividade e ao projeto ativo. Falha do registo, material de assinatura ausente, revogação ou identidade incompatível provocam falha fechada, sem regressar a contexto anónimo ou obsoleto.
Mudar de projeto é uma ação do servidor protegida por CSRF que reemite o contexto sem prolongar o token original nem a validade da política.
O logout é um POST protegido por CSRF; alterar ou redefinir a palavra-passe e eliminar a conta revogam sessões ativas.
Os pedidos JSON recebem uma falha de autenticação estruturada e eliminação dos cookies; a navegação no browser limpa o contexto antes do redirecionamento.
O SAML é entregue com limites explícitos.
Estão implementados metadados SAML do tenant, login e ACS, ligação ou JIT de identidade externa, política de domínio e evidência de MFA confirmada pelo IdP. A geração dos endpoints utiliza a origem pública controlada pelo servidor; a correlação AuthnRequest usa estado assinado e de curta duração do fornecedor e do pedido.
O SAML não cria a associação ao Projeto; o utilizador ainda precisa de acesso autorizado ao tenant e ao projeto.
TOTP ao nível da aplicação, WebAuthn, desafios de recuperação e uma interface completa para inventário e revogação de todas as sessões não são capacidades atuais.
Uma política de palavra-passe e MFA não suportada é rejeitada, em vez de guardada como um controlo falso.
Os filtros RLS e do ambiente de execução não são intercambiáveis.
O RLS de Analytics é controlado e protegido pelo servidor. Um filtro do ambiente de execução enviado pelo cliente não pode forjar metadados de origem RLS; as identidades de cache incluem permissões e âmbito RLS, em vez de confiar apenas no texto SQL.
Os segredos permanecem fora das evidências genéricas.
Credenciais, tokens, cabeçalhos de autorização, chaves privadas e URLs assinados não pertencem a metadados públicos, prompts ou payloads de auditoria genéricos. Texto mascarado não é uma credencial executável. Quando uma credencial precisa de ser revelada uma única vez, a operação é limitada, protegida em trânsito e armazenamento, breve e registada sem persistir o segredo na evidência genérica.
A força atual do IAM é indicada precisamente.
Existem contratos de permissões específicos por módulo, mas a plataforma ainda não dispõe de uma combinação universal com prevalência de DENY sobre permissões positivas e negativas. O MFA da aplicação e o step-up não devem ser inferidos para além dos controlos atuais do fornecedor de identidade e da sessão.
Próximo passo
Comece com o fluxo que não pode permitir a ambiguidade.
Apresente os sistemas, responsáveis, regras, obrigações de entrega e requisitos de evidência relevantes.
Analisar um fluxo crítico