Tudo que você precisa saber sobre RBAC
O porque você deveria adotar esse método nos seus próximos sistemas.
Hoje, o tema é Role Based Access Control, um método de controle de permissões baseado na função do usuário.
Supondo que seu sistema deve atender a diferentes níveis de usuários, de estagiários a diretores, é nececessário que você possa controlar o que cada nível de usuário pode acessar.
E no mundo real, o nível de permissão é baseado é baseado nas funções que cada colaborador exerce. Você geralmente não vê estagiários de do RH tendo acesso a documentos confidências da contabilidade…certo?
Para implementar o RBAC, você precisa ter funções previamente estabelecidas com suas respectivas listas de permissões para que após isso, você possa relacionar o seu usuário a aquela determinada função e fazer com que ele herde as permissões.
Mas somente isso acaba criando um problema.
Imagine que Lucas e João, são vendedores. Porém, por Lucas ter mais tempo na empresa ele tem mais atribuições que João, por isso, precisa de mais permissões. Como ficaria?
Simples: basta atribuirmos as novas permissões necessárias diretamente a Lucas, como uma espécie de “extra permissions”.
Desse modo, nunca haverá um vendedor sem as permissões básicas necessarias e nem um vendedor sem permissões a mais necessárias.
A boa implementação de RBAC segue também o principio do menor privilégio (PoLP), um princípio importante de segurança que define que o usuário deve receber apenas os privilégios necessários para realizar o trabalho dele. Minimizando superficie de ameaças desnecessárias e violação de dados.
No mesmo raciocíonio, a proibição de acesso a um recurso é tratado como a ausência da permissão. Ou seja, por padrão o usuário não pode acessar até que seja concedido a ele a ele ou a sua função aquela determinada permissão.
Do ponto de vista de modelagem, o relacionamento de usuários com funções é N:N (muitos para muitos), ou seja, um usuário pode ser membro de muitas funções (mesmo que, na prática, ele só seja membro de uma) e uma função pode, naturalmente, pertencer a vários usuários.
O mesmo tipo de relacionamento acontece entre permissões e funções: uma permissão pode pertencer a várias funções e uma função pode conter várias permissões.
Uma dica:
Mantenha uma convenção de nomenclatura de permissões. Caso contrário começa a surgir coisas como ver_usuarios, read-user, DELETE_USER e EditarPerfi no mesmo banco de dados, estabelecendo um caos e dificuldade de busca totalmente desnecessária.
Eu recomendo esses padrões:
- Ação:Recurso - users:write, invoices:delete
- CRUD:Verbo - read:resource_x, create:resource_x