Quando um software online passa a ter mais usuários, a questão deixa de ser apenas quem consegue entrar. Também importa quais informações cada pessoa pode ver, quais ações pode realizar e em quais condições. Conceder acessos caso a caso costuma gerar perfis confusos, exposição de dados e auditorias difíceis.
Uma alternativa melhor é desenhar os acessos a partir do trabalho. O controle de acesso baseado em funções, ou RBAC, agrupa autorizações conforme a função organizacional, em vez de atribuí-las individualmente. O NIST define RBAC a partir de funções que reúnem as autorizações necessárias para atividades organizacionais definidas.
Uma permissão útil não responde quem a solicitou primeiro. Ela responde do que uma função precisa para realizar seu trabalho com responsabilidade.
Comece separando identidade, função e permissão
Esses conceitos se relacionam, mas não são iguais:
- Usuário: a pessoa, conta ou integração que acessa o sistema.
- Função: uma responsabilidade de trabalho, como vendas, administração, supervisão ou suporte.
- Permissão: uma ação permitida sobre um recurso, como visualizar clientes, editar um pedido ou exportar um relatório.
- Escopo: o limite da permissão: todos os registros, apenas os próprios, uma filial ou uma equipe.
Por exemplo, “supervisor comercial” não deve ser uma permissão. É uma função. Suas permissões podem incluir visualizar oportunidades da equipe, redistribuí-las e aprovar descontos dentro de um limite definido.
Mapeie ações reais, não apenas telas
Antes de criar perfis como “administrador”, descreva as decisões e tarefas que o sistema deve suportar. Uma mesma tela pode reunir ações com riscos diferentes: visualizar, criar, alterar, aprovar, baixar, excluir ou compartilhar.
- Liste os recursos sensíveis: clientes, preços, faturas, arquivos, usuários, configurações e relatórios.
- Registre as ações possíveis em cada recurso.
- Defina o escopo de cada ação: próprio, equipe, área, filial ou toda a organização.
- Identifique ações irreversíveis ou de alto impacto, como excluir, aprovar pagamentos, alterar dados bancários ou administrar usuários.
- Defina responsáveis de negócio para validar cada regra.
A matriz de permissões resultante pode ser simples: funções nas linhas, ações nas colunas e observações sobre escopo. Uma matriz que todos conseguem explicar vale mais do que uma longa lista de permissões que ninguém entende.
Use quatro regras para evitar acessos excessivos
1. Conceda apenas o necessário
O princípio do menor privilégio indica que cada usuário deve receber somente os acessos necessários para realizar seu trabalho. A OWASP recomenda aplicá-lo desde o desenho: é mais fácil acrescentar uma permissão justificada do que retirar um acesso amplo demais depois. A orientação de autorização da OWASP também recomenda evitar acessos concedidos por conveniência ou por padrão.
2. Negue o que não foi definido
Uma nova funcionalidade, API ou arquivo não deve ficar acessível porque ninguém criou uma regra explícita. O critério de negar por padrão exige justificativa para cada caminho de acesso e reduz lacunas quando o sistema cresce.
3. Separe tarefas incompatíveis
Se uma pessoa pode criar um pagamento, aprová-lo e alterar a conta de destino, a fragilidade não é apenas técnica: falta um controle operacional. Para ações com impacto financeiro, legal ou reputacional, separe preparação, aprovação e execução entre funções ou exija uma confirmação adicional.
4. Verifique a permissão em cada operação
Ocultar um botão não é o mesmo que proteger uma ação. A autorização deve ser verificada no servidor sempre que o sistema consulta, altera, aprova ou exclui um recurso. O NIST explica que uma transação precisa ser autorizada por meio das funções atribuídas ao usuário; estar autenticado não basta. As perguntas frequentes do NIST sobre RBAC descrevem a relação entre função, transação e autorização.
Quando somente uma função não é suficiente
RBAC funciona bem para responsabilidades estáveis. Algumas regras, porém, dependem do contexto. Um consultor pode ver somente clientes da sua carteira; um gestor pode aprovar despesas apenas até certo valor; um fornecedor pode baixar um arquivo somente até uma data determinada.
Nesses casos, combine a função com condições como pertencimento a uma conta, status do registro, limite financeiro, data, filial ou relação com um caso. Não transforme cada exceção em uma nova função. Se surgirem funções como “vendas-norte”, “vendas-sul” e “vendas-norte-temporário”, provavelmente são necessárias funções mais gerais com regras de escopo.
Teste e revise o modelo antes de ampliá-lo
Transforme a matriz em casos de teste. Para cada função, verifique tanto o que ela deve poder fazer quanto o que deve ser bloqueado. Teste também alterações de URL, identificadores de registros, solicitações de integrações e acessos a arquivos ou exportações.
- Um usuário consegue ver dados de outra equipe alterando um identificador?
- Alguém consegue contornar uma aprovação por outro caminho?
- Um usuário desativado perde o acesso imediatamente?
- Alterações de permissões, aprovações e ações sensíveis ficam registradas?
- Contas com privilégios elevados são revisadas regularmente?
Também defina quem é responsável por criar, alterar e remover contas. Mesmo um bom modelo de permissões se deteriora quando mudanças de funcionários, fornecedores e substituições não atualizam os acessos.
Conclusão: trate o acesso como uma decisão operacional
Um bom modelo de permissões não busca adicionar complexidade. Ele garante que cada pessoa tenha as informações e ações necessárias para sua responsabilidade, que alterações importantes possam ser rastreadas e que o sistema não dependa de privilégios informais.
Comece com uma matriz de funções, ações e escopos para o processo mais sensível da sua operação. Valide-a com quem executa o trabalho e com quem responde pelos resultados. Se o sistema precisa transformar fluxos, responsabilidades e aprovações específicos em regras fáceis de manter, a Ideasweb pode ajudar a desenvolver software e sistemas sob medida com essa lógica desde o início.
