Quem tem acesso ao quê: utilizadores e permissões numa aplicação de gestão

«Vamos partilhar a palavra-passe»

A conta partilhada não é uma escolha, é o que resta quando a ferramenta não oferece outra alternativa. Funciona bem durante alguns meses, mas depois apresenta a sua fatura, sempre no pior momento.

Três consequências, todas mecânicas. Retirar o acesso a uma única pessoa obriga a alterar a palavra-passe de TODOS, o que significa voltar a formar toda uma equipa no dia em que alguém sai, ou seja, precisamente no dia em que menos queremos tratar disso. Depois, ninguém consegue responder à pergunta «quem alterou esta linha?», pois, aos olhos da aplicação, todos são a mesma pessoa. Por fim, não é possível conceder um acesso parcial: quem só precisa de consultar um valor recebe exatamente os mesmos poderes que quem emite faturas.

O problema, portanto, não é a segurança no sentido espetacular do termo, ninguém está a atacar uma aplicação usada por quinze pessoas. É a irreversibilidade: uma conta partilhada não se desfaz, apenas se substitui, e quanto mais se esperar, mais pesada será essa substituição.

• Retirar o acesso a uma pessoa = alterar a palavra-passe de toda a gente.
• Nenhuma resposta possível a «quem fez isto?»: uma única conta, uma única identidade.
• Sem acesso apenas para leitura: consultar e modificar conferem os mesmos direitos.

Três papéis, e a fronteira exata entre eles

Assim que a aplicação pede autenticação, já inclui contas verdadeiramente separadas e três papéis. São poucos, e é intencional: um sistema de permissões que não se percebe à primeira vista é um sistema que se configura mal.

O administrador faz tudo, e é o único que gere contas: cria-as, desativa-as e reinicia palavras-passe. O utilizador trabalha dentro da aplicação, cria, modifica e elimina dados, mas nunca vê a gestão de contas. O papel apenas para leitura permite consultar: navega por toda a parte, abre fichas, lê painéis de controlo e não pode gravar nada.

O ponto essencial não é a lista em si, mas onde se coloca a recusa. Para o papel apenas para leitura, o bloqueio não é um botão oculto no ecrã: toda a requisição de escrita é recusada antes de chegar à rota, pelo middleware, com um código 403. Um botão oculto pode ser contornado com o teclado ou com uma ferramenta de desenvolvimento; uma recusa colocada upstream, não. É esta a diferença entre uma interface que sugere e uma aplicação que impõe.

O papel viaja no cookie de sessão assinado, o que permite esta verificação sem consultar a base de dados em cada requisição. E um visitante sem sessão não acede a nada: as páginas redirecionam-no para o ecrã de início de sessão, memorizando para onde ele ia, e as chamadas à API devolvem um código 401.

• Administrador: tudo, mais a gestão de contas.
• Utilizador: cria, modifica e elimina dados; sem acesso à gestão de contas.
• Apenas para leitura, navega e consulta; toda a escrita é recusada com código 403 antes da rota.
• Sem sessão: código 401 na API, redirecionamento para o início de sessão nas páginas.

Abrir um acesso: um identificador, um papel, uma palavra-passe temporária

Criar uma conta exige apenas três informações, nenhuma delas sendo um endereço de correio eletrónico. O administrador introduz um identificador (de 2 a 31 caracteres: letras, algarismos, ponto, hífen ou sublinhado), escolhe o papel e a aplicação gera automaticamente uma palavra-passe temporária.

Essa palavra-passe é mostrada apenas uma vez, nesse momento exato. Não pode ser visualizada novamente, nem na lista de contas, nem em qualquer outro local: apenas a sua impressão digital é guardada. Se for perdida antes de ser transmitida, o administrador gera uma nova, num processo que demora dez segundos. A conta é ainda marcada como necessitando de alteração de palavra-passe: a pessoa é obrigada a escolher a sua própria na primeira ligação, pelo que o administrador nunca fica a saber a palavra-passe dos colegas.

Não é enviado nenhum correio eletrónico, e convém saber isto antes de organizar o fluxo de trabalho: a aplicação não dispõe de nenhum serviço de envio. Cabe ao administrador transmitir o identificador e a palavra-passe temporária pelos seus próprios meios. O corolário é, na prática, mais incómodo do que a ausência de correio eletrónico em si, não existe um processo autónomo de «recuperar palavra-passe»: quem a perder terá de recorrer ao administrador, que a reiniciará.

A primeira conta, por sua vez, é criada juntamente com a aplicação: identificador «admin», palavra-passe «admin», com a mesma alteração obrigatória na primeira ligação. Trata-se de uma palavra-passe inicial, não de uma palavra-passe definitiva, e a aplicação não permite mantê-la.

• Identificador + papel: é tudo o que o administrador introduz.
• Palavra-passe temporária gerada pela aplicação, mostrada UMA ÚNICA VEZ.
• Alteração obrigatória na primeira ligação, o administrador não a conhece depois disso.
• Sem correio eletrónico: a transmissão e as reinicializações são feitas pelo administrador.

Fechar um acesso sem perfurar o histórico

Uma conta não é eliminada, é desativada, e pode ser reativada. Isto não é uma facilidade de implementação, mas sim a mesma decisão que preside à lixeira de dados: um registo eliminado definitivamente leva consigo tudo o que lhe estava associado, e só damos por isso meses depois, ao procurarmos algo que já não existe.

Duas recusas estão codificadas, e são exatamente essas que evitam que fiquemos trancados fora. Não é possível desativar a própria conta, o gesto mais fácil de fazer por acidente ao limpar uma lista. Nem é possível desativar o último administrador ativo: uma aplicação sem administrador é uma aplicação em que ninguém pode voltar a abrir um acesso, nem mesmo a si próprio. A recusa é explícita, não se limita a falhar silenciosamente.

Um afastamento resolve-se, assim, com um único gesto, sem tocar nas palavras-passe dos restantes nem apagar qualquer rasto. Uma substituição exige dois passos: desativar, depois criar.

• Desativação reversível em vez de eliminação.
• Não é possível desativar a própria conta.
• Não é possível desativar o último administrador ativo.
• Reinicialização da palavra-passe pelo administrador, em qualquer momento.

O que não faz, e é melhor saber desde já

As permissões aplicam-se ao nível da aplicação inteira. Um papel atribuído a uma conta não tem alcance sobre nenhuma entidade específica, secção ou campo. Não existe, portanto, forma alguma de exprimir frases como «este comercial só vê os seus próprios clientes», «esta pessoa acede às intervenções, mas não à faturação» ou «este campo está oculto para não gestores». Os três papéis respondem bem à pergunta «consultar ou modificar», mas não respondem de todo à pergunta «que parte?».

A aplicação regista QUANDO um dado foi alterado, mas NUNCA identifica quem o fez, nem sequer registra a informação de autor. Cada registo traz automaticamente a data de criação e a data da última modificação, mas nenhuma coluna guarda o autor. Contas separadas respondem, assim, à pergunta «quem pode entrar», mas não à pergunta «quem escreveu esta linha», são duas questões distintas, e apenas a primeira é tratada. Trata-se da limitação mais facilmente confundida com uma funcionalidade entregue, pois ter contas nominativas dá a ilusão de existir uma rastreabilidade.

O início de sessão faz-se exclusivamente com identificador e palavra-passe, e nada mais. Sem início de sessão através de contas Google ou Microsoft, sem autenticação única empresarial, sem segundo fator. Para uma equipa que já gere as suas identidades noutro lado, isto significa mais uma lista de contas a manter.

Estas quatro limitações não são esquecimentos a contornar: são os limites do que é efetivamente entregue, e é mais útil escrevê-las do que deixar que as descubra. Todas têm um recurso comum, que é justamente a razão de ser do produto, o código da aplicação pertence-lhe. Trata-se de um projeto padrão Next.js e Prisma, exportável em ZIP ou publicável no seu próprio repositório: adicionar uma coluna de autor, um isolamento por equipa ou uma autenticação empresarial é um trabalho de desenvolvimento normal, sobre código que lhe pertence e que nenhum fornecedor lhe pode negar. E se o isolamento for estrutural para o seu negócio, descreva-o desde o início, é o seu texto que define as entidades e as suas relações.

• Permissões globais: sem isolamento por entidade, secção ou campo.
• Data de modificação registada, autor não registado.
• Apenas identificador + palavra-passe: sem SSO, sem início de sessão externo, sem segundo fator.
• Recurso comum: o código é seu, e estas extensões são desenvolvimento normal.