Usuários x Roles x Grupos = ACLs
Sobre Access Control List

Recentemente encontrei um post no Linkedin de uma candidata ao exame CSA e, como maneira de auxiliar nos estudos, ela usou IA para gerar uma imagem semelhante à ilustração acima.
É uma analogia muito boa pois demonstra que:
1) Dados de usuários ficam armazenados na tabela sys_user;
1) Dados de usuários ficam armazenados na tabela sys_user;
2) Usuários que residem no Apartamento 07G estão todos dentro de um Grupo de Usuários chamado "Família do apto 07G";
3) Uma role chamada "apto 07G" é atribuída ao Grupo "Família do apto 07G". Dessa forma, sempre que um usuário é incluído nesse grupo ele herdará a role e, consequentemente, terá acesso ao Apartamento 07G.
4) Se um usuário por algum motivo for removido do Grupo "Família do apto 07G", ele não terá mais a role "apto 07G" e portanto não terá acesso ao apartamento.
A figura também demonstra usuários que por fazerem parte de um Grupo chamado "Condomínio X", herdam a role "Condomínio X Gate" e essa é a permissão que eles precisam para passar pelo portão principal.
Supondo que o Apartamento 07G está em um edifício dentro do Condomínio X, um morador necessariamente fará parte dos dois grupos:
- Será um membro do Grupo "Condomínio X" para conseguir ser identificado e entrar pelo portão do Condomínio;
Supondo que o Apartamento 07G está em um edifício dentro do Condomínio X, um morador necessariamente fará parte dos dois grupos:
- Será um membro do Grupo "Condomínio X" para conseguir ser identificado e entrar pelo portão do Condomínio;
- Será um membro do Grupo "Família do apto 07G" para conseguir entrar no Apartamento 07G.
Incluí algumas observações no post para complementar o tema, falando sobre as operações CRUD.
Vamos considerar que existe uma tabela chamada "compras_do_mes".
Uma tabela pode ter operações como Create (inserir um produto na tabela), Read (Ver o que foi comprado), Update (Atualizar qualquer característica de um produto existente na tabela), Delete (eliminar de vez o produto).
Ao criarmos uma tabela, a plataforma automaticamente cria uma role e atribui essa role às quatro operações básicas.
Mas vamos supor que apenas os pais fazem as compras do mês, então somente eles terão o acesso para inserir um produto na tabela.
Pode-se então ter uma role "inserir_produto" que estaria relacionada a "operação Create da tabela compras_do_mes"
Como apenas os pais podem comprar produtos, o filho não teria a role inserir_produto, mas com certeza teria:
- a role para a operação Read (ao abrir a despensa ele vê tudo o que tem lá);
- a role para Update (o garoto comeu 3 bombons da caixa, então ele atualizou a quantidade de bombons disponíveis);
- a role para Delete (já sabemos o que acontece quando o garoto abre uma caixa de Bis né?).
Em cenários reais, geralmente não concedemos a operação Delete a ninguém. O que costuma-se fazer é usar um campo da tabela chamado Active do tipo Sim/Não.
Quando um iogurte Danette na tabela compras_do_mês está setado como Active = True, aparece para todos os membros da família que tem a operação Read na tabela. Abriu a porta da geladeira, o Danette está lá.
Mas se o garoto comer todo o Danette, essa linha da tabela será setada como Active = False.
O Danette não aparece quando alguém abre a porta da geladeira, mas fica como histórico caso o pessoal da Auditoria pergunte "Cadê o Danette que estava aqui?".
Obrigado.
_____
Imagem original por Adriana Gutierrez
Imagem original por Adriana Gutierrez
Comentários
Postar um comentário