Define a relação entre a pessoa, o recurso e a ação
Para definir uma permissão, identifica quem pede acesso, qual o recurso pretendido e o que quer fazer com ele. Consultar, alterar e eliminar são decisões diferentes. Acrescenta a relação relevante, como pertencer à empresa responsável pelo documento, para que a regra corresponda ao funcionamento do negócio e possa ser verificada.
Imagina uma gráfica com um portal onde os clientes entregam ficheiros para impressão. Uma pessoa pode entrar no portal para acompanhar o próprio trabalho. Isso não significa que possa abrir os ficheiros de outra empresa, aprovar uma prova em nome de outro cliente ou alterar a data prevista de uma encomenda.
Mesmo dentro da mesma empresa podem existir responsabilidades distintas. Um colaborador envia o ficheiro, outro confirma a prova e alguém acompanha a entrega. Se o produto precisa dessa separação, a aplicação deve expressá-la. A palavra cliente, por si só, pode ser demasiado ampla para determinar todas as ações permitidas.
Começa por escrever exemplos curtos de acesso permitido e recusado. Uma pessoa associada à encomenda pode consultar a prova; uma pessoa de outra empresa não pode. Se a regra admitir uma exceção, como acesso da equipa de produção, descreve a responsabilidade que a justifica e o alcance desse acesso.
Estas escolhas pertencem ao trabalho de planear a aplicação antes de programar. A IA pode ajudar a organizar a matriz de permissões, mas precisa de receber as decisões do negócio. Sem elas, consegue construir um login funcional e continuar sem saber que fronteiras de informação deve respeitar depois da entrada.
Para preparar o próximo passo, consulta Segurança de aplicações desenvolvidas com IA.
Não uses o menu como prova de proteção
Esconder um botão ou retirar um documento da lista pode melhorar a apresentação, mas não demonstra que o sistema recusa o acesso. A autorização precisa de existir onde o pedido é processado e os dados são entregues. O teste deve confirmar a recusa mesmo quando a opção não aparece no ecrã.
No portal da gráfica, a página pode listar apenas as encomendas da empresa correta. Ainda assim, é necessário verificar o que acontece quando chega ao sistema um pedido relativo a outro registo de teste. O resultado deve depender da autorização da pessoa para aquele recurso, em vez da sua presença na lista visível.
O identificador de um documento serve para o localizar, sem conceder permissão sobre ele. Tornar esse identificador difícil de adivinhar pode ter utilidade, mas não substitui a regra de acesso. Uma ligação pode circular por uma mensagem ou ficar guardada num histórico, e continuar a precisar de uma verificação adequada.
Também não aceites como autoridade uma indicação enviada pelo próprio formulário a dizer que a pessoa é administradora. A aplicação tem de obter a identidade e os poderes relevantes a partir de informação verificada. Caso contrário, o pedido passa a decidir uma condição que deveria ser controlada por quem o recebe.
Aplica a regra aos ficheiros e aos dados relacionados
A permissão sobre uma página deve ser coerente com o acesso aos elementos que ela apresenta. Verifica anexos, exportações, imagens privadas e outros recursos ligados ao registo. Proteger a consulta principal deixa trabalho por fazer se um ficheiro associado puder ser obtido por um endereço que não aplica a mesma decisão.
Na gráfica, uma encomenda pode estar corretamente protegida e ter uma prova de impressão guardada noutro serviço. A revisão deve acompanhar esse ficheiro até à forma como é disponibilizado. Não basta verificar que o botão de descarga só aparece a quem entrou no portal e pertence à empresa certa.
O mesmo vale para uma exportação usada pela equipa. Define se pode conter todas as encomendas ou apenas as que pertencem à responsabilidade daquela pessoa. Uma funcionalidade de relatório pode introduzir um caminho de acesso diferente daquele que foi testado na página individual, apesar de usar os mesmos dados de origem.
Ao dar contexto à IA sem informação indiscriminada, explica quais os dados privados, quem precisa deles e porquê. Exemplos fictícios bastam para desenvolver os casos de permissão. Não é necessário expor ficheiros reais de clientes para demonstrar como deve funcionar a separação entre duas empresas no portal.
Confirma as proteções nas camadas que entregam informação
A aplicação precisa de aplicar a autorização no servidor e de proteger o acesso aos dados segundo a arquitetura utilizada. Em projetos com Supabase, isso inclui conferir as permissões e políticas da base de dados. Ter uma opção de segurança ativa não demonstra que as regras permitem e recusam exatamente os casos pretendidos.
Pede uma explicação ligada ao percurso: onde é verificada a sessão, onde é decidida a autorização e que proteção existe ao consultar o registo. A resposta deve permitir relacionar a regra do negócio com os controlos implementados. Uma lista de nomes técnicos sem essa relação é difícil de avaliar.
Nos dados, verifica o efeito de cada operação necessária. Uma regra de leitura correta não resolve automaticamente as condições de criação ou alteração de um registo. No portal, permitir enviar um ficheiro para uma encomenda exige confirmar que a pessoa pode atuar sobre essa encomenda, além de aceitar o tipo de ficheiro.
As contas privilegiadas usadas pela operação merecem atenção própria. Não devem servir para simular um cliente comum e concluir que as restrições funcionam. Se o teste foi executado com poderes superiores aos do utilizador final, a evidência precisa de dizer isso e a verificação adequada continua por fazer.
Testa a recusa com a mesma atenção que o sucesso
Prepara contas e registos fictícios que permitam demonstrar acesso legítimo e acesso indevido no ambiente autorizado de teste. Verifica o resultado do pedido e os efeitos nos dados. Uma mensagem de erro é insuficiente se a informação foi entregue ou a alteração aconteceu antes de a aplicação apresentar essa mensagem.
Para a gráfica, cria dois clientes de teste e encomendas separadas. Confirma que cada um vê e altera apenas o permitido, e que a equipa interna tem o alcance definido. Acrescenta uma sessão terminada ou uma pessoa cujo acesso foi retirado, conforme o comportamento previsto para a gestão de utilizadores.
Regista qual a versão e a configuração verificadas, evitando apresentar uma revisão antiga como prova de uma alteração recente. Tal como ao testar uma automação antes de a entregar, o relatório deve separar observações, hipóteses e pendências. A confiança fica apoiada no comportamento demonstrado, incluindo as ações que o sistema recusou corretamente.
Quando acrescentares um novo tipo de ficheiro, relatório ou ação, volta à regra correspondente e aos testes afetados. O login pode continuar exatamente igual enquanto surgem novas possibilidades de acesso. É essa evolução que exige manter a autorização ligada aos recursos reais da aplicação e às responsabilidades atuais das pessoas.