O modelo de autorização

01A identidade não decide os direitos #sec_877062d8

O fornecedor de identidade — Entra ID, Okta, Google, ADFS ou outro IdP — responde a uma questão: quem se autenticou e com que nível de garantia? REVIEWIT responde às seguintes questões: o que esta pessoa pode fazer, em que perímetro e até quando?

Esta separação impede que um administrador de diretório cliente possa atribuir a si mesmo um papel interno na plataforma. Os grupos ou papéis enviados por um IdP não se tornam automaticamente autorizações REVIEWIT. Eles podem contribuir para a identificação, mas a decisão de acesso permanece levada, administrada, auditada e revogada em REVIEWIT.

O identificador pivot é estável e independente do endereço de correio ou do nome exibido. Uma mudança de IdP, nome ou organização não deve recriar os direitos nem tornar o histórico ilegível.

02Três âmbitos fechados #sec_5953283d

O modelo distingue três níveis que nunca se confundem.

A plataforma. O papel de Operador de Plataforma é reservado ao editor. Permite explorar o serviço, sem dar direito aos dados de um cliente além das operações explicitamente previstas.

A subscrição. O Admin de Subscrição governa uma subscrição identificada pelo seu identificador público: parâmetros comuns, workspaces, papéis e capacidades subscritas. O seu poder não se estende a outras subscrições.

O workspace. Os papéis de Gestor, Leitor, Leitor de Relatórios e Auditor exercem-se num workspace específico. São resolvidos a partir da base no momento em que a aplicação precisa, de forma a refletir uma revogação ou uma expiração sem transportar todos os direitos numa sessão longa.

Esta taxonomia é fechada por construção. Adicionar um papel de plataforma ou de subscrição não é uma simples operação de configuração: é uma decisão de modelo que deve definir o seu perímetro, administração e impacto de auditoria.

Nenhum papel de administração confere o direito de tomar uma decisão de revisão. O papel de Gestor de Revisão e as atribuições de campanha respondem a um modelo de negócio distinto. Administrar o contentor não significa decidir em lugar do revisor.

03O contexto é resolvido do lado do servidor #sec_f2e08188

Um pedido de cliente não pode impor a sua própria subscrição ou o seu próprio workspace. A aplicação resolve o contexto autorizado do lado do servidor, a partir da identidade e das associações ativas. Um identificador fornecido numa URL ou num formulário permanece um alvo solicitado, nunca uma prova de autorização.

Os direitos são versionados. Quando um papel é atribuído, suspenso, revogado ou expirado, uma versão de autorização evolui. As sessões e aplicações podem então detetar que as suas informações não são mais atuais e reavaliar os direitos efetivos.

Cada associação possui um estado, uma data de concessão, um autor, um motivo e uma expiração. Uma suspensão temporária distingue-se de uma revogação definitiva. O modelo torna, portanto, visíveis tanto o direito atual como o seu ciclo de vida.

A gestão do « último administrador » aplica uma guarda fail-closed: uma subscrição não pode ficar sem responsável ativo devido a uma eliminação concorrente ou a uma expiração mal preparada. A regra aplica-se aos direitos realmente efetivos, não apenas ao número de linhas presentes.

04Bootstrap, elevação e acesso de emergência #sec_b168e1cb

O primeiro administrador de uma subscrição deve ser estabelecido por um procedimento explícito e rastreável. Este bootstrap não é um atalho permanente: uma vez instalada a governança, os administradores são geridos de acordo com as mesmas regras que as outras associações.

As operações sensíveis podem exigir uma elevação TrustGate, ou seja, uma autenticação recente ou mais forte. A elevação confirma a identidade do ator no momento crítico; não lhe inventa nenhum papel. A autorização é avaliada antes e depois da elevação.

O break-glass é uma postura de exploração excepcional, não um papel de cliente oculto. É limitado no tempo, motivado, monitorizado e auditado. Nunca serve para contornar silenciosamente o modelo de autorização de uma subscrição.

05Uma revogação que se propaga e se demonstra #sec_812968cd

Qualquer atribuição, suspensão, expiração e revogação produz um ato no Rastreio de Auditoria com o seu ator, motivo e perímetro. Uma modificação dos direitos não é apenas uma mudança de configuração: é um evento de segurança.

A propagação combina vários mecanismos: versão dos papéis, leitura das associações efetivas e resolução na base dos direitos de workspace. O objetivo não é confiar num cookie até à sua expiração, mas reduzir a janela durante a qual uma sessão poderia continuar a portar uma informação que se tornou falsa.

O reaproximamento periódico verifica finalmente a completude: os direitos declarados, as sessões emitidas e as contas ativas devem contar a mesma situação. Uma divergência torna-se um incidente visível em vez de uma permissão implícita.

06Em resumo #sec_e0f5ace1

O modelo de autorização REVIEWIT baseia-se numa regra fácil de lembrar: o IdP prova a identidade; REVIEWIT possui os direitos. Três âmbitos fechados, um contexto resolvido do lado do servidor, papéis versionados e uma rastreabilidade sistemática impedem que os privilégios viajem mais longe ou por mais tempo do que o previsto.