A autenticação

01Em uma frase #sec_ae957ae4

REVIEWIT é sua própria autoridade de autenticação: o cliente mantém seu provedor de identidade, e o produto se reserva o direito de decidir o que aceita como prova de identidade — e com que nível de garantia.

02O problema #sec_a55cce9c

Uma ferramenta de recertificação afirma, campanha após campanha, que tal pessoa decidiu tal coisa. Todo o valor probatório repousa, portanto, em uma questão anterior a tudo o resto:

O que garante que era realmente ela?

Três dificuldades se acumulam, e elas não são da mesma natureza.

O cliente já tem seu provedor de identidade. Ele não o mudará por uma ferramenta, e está fora de questão pedir-lhe que crie senhas adicionais. Um diretório empresarial, um provedor de nuvem, às vezes vários, dependendo das entidades — a ferramenta deve se basear neles, não substituí-los.

Basear-se em um único provedor aprisiona o produto. Um software que só sabe se autenticar contra um único ecossistema é inutilizável para quem não faz parte dele e se torna refém das evoluções desse provedor.

Nem todas as autenticações são iguais. Abrir a fila de trabalho de um revisor e modificar os parâmetros de governança de uma entidade não deveria exigir a mesma prova. Ainda é preciso saber, no momento da decisão de acesso, como a pessoa se autenticou — informação que as aplicações quase nunca possuem.

03O princípio #sec_d821c25a

O produto delega a verificação da identidade, nunca a decisão do que aceita.

REVIEWIT introduz uma autoridade de autenticação interna. As aplicações não falam mais com um provedor de identidade: elas falam com essa autoridade, em uma linguagem padrão. A autoridade, por sua vez, se encarrega de verificar a identidade junto ao provedor do cliente, seja ele qual for.

O ganho é duplo. O cliente mantém seu diretório, suas regras, sua política de autenticação. E o produto ganha um lugar único onde raciocinar sobre o que aceita — em vez de deixá-lo a quatro aplicações que o fariam cada uma à sua maneira.

Seis princípios estruturam essa escolha. São eles que fazem a diferença entre « funciona » e « resiste a uma auditoria ».

1. A prova é válida, nunca a solicitação

É o princípio mais importante e o mais contra-intuitivo.

Uma aplicação pode solicitar ao provedor de identidade uma autenticação forte. Mas essa solicitação é apenas uma solicitação: dependendo do provedor, sua configuração, o estado da sessão ou a política em vigor, ela pode ser parcialmente atendida, ignorada ou silenciosamente contornada.

REVIEWIT, portanto, nunca confia no que solicitou. Ele verifica o que retorna, e se a prova esperada não está lá, o acesso é recusado. Solicitar é um esforço de boa vontade; verificar é a garantia.

É isso que separa uma política de segurança exibida de uma política de segurança efetiva.

2. O nível de garantia, não o mecanismo

As aplicações nunca raciocinam sobre « a pessoa usou tal dispositivo ». Elas raciocinam sobre um nível de garantia ordenado:

Uma tela exige um nível mínimo; o mecanismo que o produziu não o considera. A vantagem é duradoura: quando um novo meio de autenticação aparece, basta saber a que nível ele corresponde — nenhuma aplicação precisa ser modificada.

O produto também mantém o momento da autenticação, o que permite exigir uma autenticação recente para um gesto sensível, e não apenas uma autenticação válida. Essa informação nunca é reconstituída por aproximação: se falta, a regra de atualidade falha em vez de deixar passar.

3. Nunca um emparelhamento automático por endereço de e-mail

Quando uma identidade desconhecida se apresenta, a tentação é vinculá-la a uma conta existente com o mesmo endereço. REVIEWIT nunca faz isso.

O endereço de e-mail não é uma prova de identidade: é declarativo, reatribuível e falsificável em um provedor mal configurado. Um emparelhamento automático com base nesse critério é um vetor clássico de tomada de controle de conta — basta emitir uma identidade com o endereço correto para herdar os direitos de outra pessoa.

A ligação entre uma identidade externa e uma conta REVIEWIT é, portanto, estabelecida em um triplo estável — o provedor, o emissor, o identificador do sujeito — e um emparelhamento entre vários provedores é objeto de um fluxo controlado e explícito, nunca de uma dedução.

4. A conta REVIEWIT é a autoridade de sessão

Uma autenticação bem-sucedida no provedor do cliente não é suficiente para abrir uma sessão.

O produto mantém seu próprio registro de contas, e esse registro decide: uma conta desativada no lado REVIEWIT vê o acesso recusado, mesmo se o provedor de identidade acabou de autenticá-la com sucesso. Os dois ciclos de vida são separados — revogar um link de identidade não é desativar uma conta, e vice-versa.

Essa verificação é reproduzida a cada emissão de acesso, inclusive durante as reconexões silenciosas permitidas pela sessão única. É precisamente o caso em que se poderia acreditar que não há « nada para reverificar » — e é o caso em que uma desativação permaneceria sem efeito por horas.

5. Identidade e contexto não se confundem

A autoridade de autenticação estabelece quem você é. Ela nunca decide a que direito você tem, nem a que assinatura ou workspace você pertence.

Quando um contexto é transmitido, é como uma dica assinada — útil para evitar que o usuário reselecione seu escopo — e nunca como uma prova de pertencimento. O aplicativo reverifica sistematicamente os direitos como se essa dica não existisse.

Confundir os dois é o erro que produz as elevações de privilégios mais discretas: um token que afirma um escopo sempre acaba sendo acreditado.

6. Os segredos não estão no banco de dados

O banco de dados contém a referência de um segredo, nunca seu valor. Os segredos vivem em um repositório dedicado, com um mecanismo de rotação de dupla versão: o novo segredo se torna ativo enquanto o antigo permanece aceito durante a transição, depois é revogado.

O mesmo raciocínio vale para as chaves: aquelas que assinam os tokens destinados aos humanos são distintas daquelas destinadas às máquinas, com emissores e destinatários explícitos. Um token emitido para uma aplicação nunca é aceitável onde outro é esperado — os mecanismos são compartilhados, nunca os segredos.

04Duas autoridades, deliberadamente separadas #sec_dd4e68e8

Esses dois mundos têm ameaças, ciclos de vida e exigências diferentes. Fazê-los coexistir em uma mesma autoridade levaria cedo ou tarde a que um token concebido para um seja aceito pelo outro. Veja o [dossier API](REVIEWIT_Dossier_API_v1.0.md).

05O provedor de identidade do cliente #sec_9c97a8ca

Cada assinatura declara seu ou seus provedores de identidade. O encaminhamento é feito com base no domínio do endereço profissional: o usuário digita seu endereço, e é enviado para o provedor que o concerne.

Os provedores em conformidade com os padrões modernos são suportados nativamente, o que cobre a maior parte do parque, incluindo os diretórios empresariais auto-hospedados em suas versões recentes. Os protocolos mais antigos são tratados por adaptador, em um segundo momento.

Um ponto de design merece ser destacado: a conexão dos usuários e a coleta de dados são dois caminhos distintos. As autorizações de que o produto precisa para inventariar os recursos de um cliente nunca transitam pelo caminho de conexão. Um usuário que se conecta não concede nada além de sua identidade — e uma modificação na configuração de coleta não pode quebrar a autenticação.

06Os acessos de emergência #sec_5e779c5b

O produto prevê contas de emergência, para o caso em que o provedor de identidade do cliente esteja indisponível.

Dois salvaguardas: essas contas são explicitamente designadas, uma por uma — não existe uma regra do tipo « todos os administradores podem se conectar de outra forma » — e seu uso é objeto de um registro reforçado na [trilha de auditoria](REVIEWIT_Dossier_PisteAudit_v1.0.md).

Um acesso de emergência é uma exceção assumida, não uma porta dos fundos permanente.

07Uma escolha assumida: a substituição completa #sec_50dd8f34

O antigo dispositivo de autenticação não é migrado, é substituído. Nenhum caminho duplo, nenhum período em que os dois coexistem.

A razão é de segurança, não de conforto. Manter dois caminhos de autenticação é manter duas superfícies de ataque, dois conjuntos de segredos e a obrigação permanente de verificar que o mais fraco dos dois não pode ser utilizado para contornar o outro. As antigas inscrições aplicativas são desativadas e seus segredos revogados.

É o mesmo raciocínio que para a [trilha de auditoria](REVIEWIT_Dossier_PisteAudit_v1.0.md): é melhor uma base curta e clara do que uma base longa sobre a qual nada se pode afirmar.

08O que o produto não faz #sec_c39b58a6

• Não gerencia senhas. O REVIEWIT não armazena nenhuma, não verifica nenhuma e não faz expirar nenhuma. Esse é o trabalho do fornecedor de identidade do cliente.
• Não implementa seu próprio multifator. O fortalecimento da autenticação baseia-se nos dispositivos do cliente. O que o produto oferece é a capacidade de exigir e verificar um nível determinado — não de fornecê-lo.
• Não decide sobre direitos. A autenticação estabelece a identidade; as habilitações são suportadas pelo workspace e pela subscrição.
• Não confia em uma declaração. Nem o endereço de e-mail, nem um contexto anunciado, nem uma solicitação de autenticação forte valem como prova.

09A reter #sec_5948ea3f

A autenticação é a fundação sobre a qual tudo o resto repousa: sem ela, « Marie certificou este acesso em 14 de março » é uma afirmação inverificável.

O REVIEWIT baseia-se na identidade que o cliente já domina, mas mantém o controle sobre o que aceita. Ele verifica as provas em vez de confiar nas solicitações, raciocina em níveis de segurança em vez de mecanismos, recusa as aproximações convenientes que levam ao controle e reserva-se o último direito sobre a abertura de uma sessão.

É isso que permite afirmar não apenas que uma decisão foi tomada, mas por quem e com que grau de certeza.