Definir primeiro o resultado
Controle de acesso começa com uma pergunta de negócio: quem pode fazer o quê em qual registro e em quais condições? Nomes de papéis não bastam. Identifique ações, limites de propriedade e autoridade excepcional. Ler, editar, exportar e conceder acesso são poderes diferentes.
Escolher a abordagem
Papéis simples podem atender uma aplicação interna pequena. Propriedade, organização ou estado do fluxo podem exigir verificações extras. Não crie um papel para cada combinação se alguns atributos explicam melhor a regra. A OWASP recomenda negar por padrão e verificar cada requisição; esconder botão não impõe autorização.
Conciliar um caso concreto
Em um portal ilustrativo, o gestor lê pedidos da própria empresa e o financeiro baixa faturas. Teste cada ação com identificador de outra empresa, incluindo downloads diretos e buscas. Remova depois a associação de alguém com navegador aberto. A próxima requisição protegida deve aplicar a nova decisão, não a tela antiga.
Preservar evidências úteis
Não dê acesso total permanente ao suporte por conveniência. Se precisar de exceção, defina motivo, duração e registro. Examine exportações, tarefas de fundo e credenciais de integração como as telas. A matriz de permissões precisa virar verificações executáveis e testes negativos.
Construir a matriz a partir de ações e limites
Coloque ações nas linhas, papéis nas colunas e anote o limite dos registros. Ler pedidos só da organização atribuída é parte da permissão, não observação. Inclua busca, download, exportação, segundo plano e concessão de acesso. Proteger edição e esquecer exportação pode expor os mesmos dados.
Percorra convite, verificação da empresa, mudança de papel e remoção. Decida alterações que exigem outra pessoa e expiração de emergência. Separe operar o negócio e administrar a aplicação. Aprovar compra não exige alterar autenticação ou ler outra empresa. Restrinja identidades de integração às tarefas, com responsável e revogação.
Transforme a matriz em casos permitidos e negados: registro correto, outra organização com mesmo papel, membro removido e requisição direta. Repita para lotes e filas, pois direitos podem mudar. Guarde prova de quem autorizou sem copiar todo o conteúdo pessoal. Peça investigação de uma recusa com essa evidência. Ela protege e orienta o usuário legítimo sem revelar registros alheios.
Casos de aceite de permissões
| Caso | Limite esperado |
|---|---|
| Mesmo papel, outra organização | Sem acesso cruzado a registros, buscas ou anexos só pela semelhança de papel. |
| Remoção durante sessão aberta | A próxima ação usa autoridade atual, não o controle renderizado antes. |
| Tentativa de se elevar | Aplica aprovação configurada e registra a tentativa sem conceder poder silencioso. |
| Exportação após alteração | A execução segue política acordada, não distribui só porque existia seleção antiga. |
Perguntas ao responsável
Quem concede e revoga acesso? Alguém pode aprovar a própria elevação? Que registros continuam separados no mesmo papel? Leve uma matriz papel-ação-registro e exemplos de recusa à revisão. O proibido importa tanto quanto o permitido.
Fontes e outras leituras
Software sob medida
Software que acompanha a forma como seu negócio trabalha.
Converse sobre este serviço