O que é Controle de Acesso Baseado em Atributos? Política a Partir de Atributos
O controle de acesso baseado em atributos (ABAC) toma decisões de acesso avaliando atributos de quem faz a requisição, do recurso e do contexto ao redor em relação a regras de política.
O controle de acesso baseado em atributos, ou ABAC, é um modelo de autorização flexível. Em vez de mapear usuários para papéis fixos, o ABAC avalia regras sobre atributos: quem está pedindo, o que está acessando e as condições da requisição. Ele se destaca quando o acesso precisa depender do contexto, algo cada vez mais comum em sistemas de nuvem e de CI/CD.
Como o ABAC decide
Um motor de política avalia regras como "permitir se o departamento do usuário corresponder ao dono do recurso e a requisição vier de uma rede confiável." As entradas são atributos; a saída é permitir ou negar. Isso permite que uma única política cubra muitos casos sem enumerar cada usuário.
As categorias de atributos
- Atributos do sujeito: papel, equipe, nível de autorização.
- Atributos do recurso: dono, sensibilidade, ambiente.
- Atributos de contexto: horário, localização, origem da requisição.
ABAC versus RBAC
O RBAC é mais simples e mais fácil de auditar, mas pode explodir em muitos papéis estreitos quando o acesso depende do contexto. O ABAC lida com o contexto de forma limpa, mas pode ser mais difícil de raciocinar sobre. Muitos sistemas reais começam com RBAC e sobrepõem condições no estilo ABAC para os casos mais granulares.
ABAC em CI/CD
As políticas de confiança na nuvem frequentemente usam condições de atributos: um pipeline pode assumir um papel apenas se os atributos do token OIDC mostrarem um repositório, um branch e um ambiente específicos. Isso é ABAC na prática, restringindo o acesso com base na identidade da carga de trabalho, não apenas em um papel estático.
Pontos fortes e trade-offs
O ABAC escala para regras complexas e reduz a proliferação de papéis, mas as políticas podem se tornar opacas e difíceis de testar. Autoria, teste e revisão claros de políticas são essenciais, caso contrário uma regra sutil pode conceder mais do que o pretendido.
ABAC e runners efêmeros
Como os tokens OIDC do pipeline carregam atributos sobre o job, as condições ABAC podem fixar o acesso exatamente àquele contexto. Em runners efêmeros (como os runners gerenciados da Latchkey), os atributos descrevem um único job de curta duração, então o acesso concedido pela política expira junto com ele.
Principais conclusões
- O ABAC avalia atributos do sujeito, do recurso e do contexto em relação a regras de política.
- Ele lida melhor com acesso dependente de contexto do que o RBAC, mas é mais difícil de auditar.
- As políticas de confiança OIDC na nuvem usam condições no estilo ABAC para delimitar o acesso do pipeline.