O que é ABAC para a AWS?

O controle de acesso por atributo (ABAC) é uma estratégia de autorização que define permissões com base em atributos. Na AWS, esses atributos são chamados de tags. Você pode anexar tags a recursos do IAM, incluindo entidades (usuários ou funções) do IAM, e a recursos da AWS. É possível criar uma única política de ABAC ou um pequeno conjunto de políticas para suas entidades do IAM. Essas políticas de ABAC podem ser criadas para permitir operações quando a tag da entidade principal corresponder à tag de recurso. O ABAC é útil em ambientes que estão crescendo rapidamente e ajuda em situações em que o gerenciamento de políticas se torna um problema.

Por exemplo, é possível criar três funções com a chave de tag access-project. Defina o valor da tag da primeira função como Heart, a segunda como Star e a terceira como Lightning. Depois disso, é possível usar uma única política que permitirá o acesso quando a função e o recurso estiverem marcados com o mesmo valor para access-project. Para obter um tutorial detalhado que demonstra como usar o ABAC na AWS, consulte Tutorial do IAM: Definir permissões para acessar recursos da AWS com base em etiquetas. Para saber mais sobre os serviços compatíveis com ABAC, consulte Serviços da AWS que funcionam com o IAM.

Comparar o ABAC com o modelo de RBAC tradicional

O modelo de autorização tradicional usado no IAM é chamado de controle de acesso baseado em função (RBAC). O RBAC define permissões com base na função de trabalho de uma pessoa, conhecida fora da AWS como uma função. Na AWS, uma função geralmente se refere a uma função do IAM, que é uma identidade no IAM que você pode assumir. O IAM inclui políticas gerenciadas para funções de trabalho que alinham as permissões para uma função de trabalho em um modelo de RBAC.

No IAM, você implementa o RBAC criando diferentes políticas para diferentes funções de trabalho. Em seguida, você anexa as políticas às identidades (usuários, grupos de usuários ou funções do IAM). Como prática recomendada, conceda as permissões mínimas necessárias para o perfil de trabalho. Isso é conhecido como concessão de privilégio mínimo. Faça isso listando os recursos específicos que a função de trabalho pode acessar. A desvantagem de usar o modelo de RBAC tradicional é que, quando os funcionários adicionarem novos recursos, será necessário atualizar as políticas para permitir o acesso a esses recursos.

Por exemplo, vamos supor que você tenha três projetos, chamados Heart, Star e Lightning, nos quais seus funcionários trabalham. Você cria uma função do IAM para cada projeto. Depois, você anexa políticas a cada função do IAM para definir os recursos que qualquer pessoa com permissão para assumir a função pode acessar. Se um funcionário mudar de cargo na sua empresa, você atribuirá a ele outra função do IAM. Pessoas ou programas podem ser atribuídos a mais de uma função. No entanto, o projeto Star pode exigir recursos adicionais, como um novo contêiner do Amazon EC2. Nesse caso, é necessário atualizar a política anexada ao perfil Star para especificar o novo recurso de contêiner. Caso contrário, os membros do projeto Star não terão permissão para acessar o novo contêiner.

O ABAC oferece as seguintes vantagens em relação ao modelo de RBAC tradicional:

• As permissões de ABAC são dimensionadas com inovação. Não é mais necessário que um administrador atualize as políticas existentes para permitir o acesso a novos recursos. Por exemplo, vamos supor que você tenha criado sua estratégia de ABAC com a tag access-project. Um desenvolvedor usa a função com a tag access-project = Heart. Quando as pessoas no projeto Heart precisarem de recursos adicionais do Amazon EC2, o desenvolvedor poderá criar novas instâncias do Amazon EC2 com a etiqueta access-project = Heart. Depois disso, qualquer pessoa no projeto Heart pode iniciar e interromper essas instâncias porque seus valores de tag são correspondentes.

• O ABAC exige menos políticas. Como não é necessário criar políticas diferentes para funções de trabalho diferentes, você cria menos políticas. Essas políticas são mais fáceis de gerenciar.

• Usando o ABAC, as equipes podem mudar e crescer rapidamente. Isso ocorre porque as permissões para novos recursos são concedidas automaticamente com base em atributos. Por exemplo, se a empresa já oferece suporte aos projetos Star e Heart que usam o ABAC, é fácil adicionar um novo projeto Lightning. Um administrador do IAM cria uma nova função com a etiqueta access-project = Lightning. Não é necessário alterar a política para oferecer suporte a um novo projeto. Qualquer pessoa com permissões para assumir a função pode criar e visualizar instâncias marcadas com access-project = Lightning. Além disso, um membro da equipe pode mudar do projeto Heart para o projeto Lightning. O administrador do IAM atribui ao usuário outra função do IAM. Não é necessário alterar as políticas de permissões.

• Permissões granulares são possíveis usando ABAC. Ao criar políticas, faz parte das melhores práticas conceder privilégio mínimo. Usando RBAC tradicional, é necessário escrever uma política que permita o acesso apenas a recursos específicos. No entanto, ao usar ABAC, será possível permitir ações em todos os recursos, mas somente se a tag de recurso for correspondente à tag do principal.

• Use atributos de funcionário do seu diretório corporativo com ABAC. É possível configurar seu provedor SAML ou OIDC para passar tags de sessão para a AWS. Quando seus funcionários se agrupam na AWS, os atributos deles são aplicados ao principal resultante na AWS. Você pode usar o ABAC para conceder ou não permissões com base nesses atributos.

Para obter um tutorial detalhado que demonstra como usar o ABAC na AWS, consulte Tutorial do IAM: Definir permissões para acessar recursos da AWS com base em etiquetas.