As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Tipos de controle de acesso
Você pode usar dois modelos amplamente definidos para implementar o controle de acesso: controle de acesso baseado em função (RBAC) e controle de acesso baseado em atributos (ABAC). Cada modelo tem vantagens e desvantagens, que são discutidas brevemente nesta seção. O modelo que você deve usar depende do seu caso de uso específico. A arquitetura discutida neste guia é compatível com os dois modelos.
## RBAC
O controle de acesso baseado em funções (RBAC) determina o acesso aos recursos com base em uma função que geralmente se alinha à lógica de negócios. As permissões são associadas à função, conforme apropriado. Por exemplo, uma função *de marketing* autorizaria um usuário a realizar atividades *de marketing* em um sistema restrito. Esse é um modelo de controle de acesso relativamente simples de implementar porque se alinha bem à lógica de negócios facilmente reconhecível.
O modelo RBAC é menos eficaz quando:
+ Você tem usuários exclusivos cujas responsabilidades abrangem várias funções.
+ Você tem uma lógica de negócios complexa que dificulta a definição de funções.
+ A escalabilidade para um tamanho grande exige administração e mapeamento constantes de permissões para funções novas e existentes.
+ As autorizações são baseadas em parâmetros dinâmicos.
## ABAC
O controle de acesso baseado em atributos (ABAC) determina o acesso aos recursos com base nos atributos. Os atributos podem ser associados a um usuário, recurso, ambiente ou até mesmo ao estado do aplicativo. Suas políticas ou regras fazem referência a atributos e podem usar a lógica booleana básica para determinar se um usuário tem permissão para realizar uma ação. Aqui está um exemplo básico de permissões:
*No sistema de pagamentos, todos os usuários do departamento financeiro podem processar pagamentos no endpoint da API `/payments` durante o horário comercial.*
Ser membro do departamento financeiro é um atributo do usuário que determina o acesso `/payments` a. Também há um atributo de recurso associado ao endpoint da `/payments` API que permite acesso somente durante o horário comercial. No ABAC, se um usuário pode ou não processar um pagamento é determinado por uma política que inclui a associação ao departamento financeiro como atributo do usuário e a hora como atributo do recurso de`/payments`.
O modelo ABAC é muito flexível ao permitir decisões de autorização dinâmicas, contextuais e granulares. No entanto, o modelo ABAC é difícil de implementar inicialmente. Definir regras e políticas, bem como enumerar atributos para todos os vetores de acesso relevantes, exigem um investimento inicial significativo para serem implementadas.
## Abordagem híbrida RBAC-ABAC
A combinação do RBAC e do ABAC pode oferecer algumas das vantagens de ambos os modelos. O RBAC, estando tão alinhado à lógica de negócios, é mais simples de implementar do que o ABAC. Para fornecer uma camada adicional de granularidade ao tomar decisões de autorização, você pode combinar o ABAC com o RBAC. Essa abordagem híbrida determina o acesso combinando a função de um usuário (e suas permissões atribuídas) com atributos adicionais para tomar decisões de acesso. O uso dos dois modelos permite uma administração e atribuição simples de permissões, além de permitir maior flexibilidade e granularidade em relação às decisões de autorização.
## Comparação de modelos de controle de acesso
A tabela a seguir compara os três modelos de controle de acesso discutidos anteriormente. Essa comparação deve ser informativa e de alto nível. Usar um modelo de acesso em uma situação específica pode não necessariamente se correlacionar com as comparações feitas nesta tabela.
| | | | |
| --- |--- |--- |--- |
| **Fator** | **RBAC** | **ABAC** | **Híbrida** |
| **Flexibilidade** | Médio | Alto | Alto |
| **Simplicidade** | Alto | Baixo | Médio |
| **Granularity** | Baixo | Alto | Médio |
| **Decisões e regras dinâmicas** | Não | Sim | Sim |
| **Consciente do contexto** | Não | Sim | Um pouco |
| **Esforço de implementação** | Baixo | Alto | Médio |