# Definir permissões com base em atributos com autorização ABAC
<a name="introduction_attribute-based-access-control"></a>

Controle de acesso por atributo (ABAC) é uma estratégia de autorização que define permissões com base em atributos. A AWS chama esses atributos de *tags*. Você pode anexar tags a recursos do IAM, incluindo entidades do IAM (usuários ou perfis 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. Você pode criar políticas de ABAC que permitem operações quando a tag da entidade principal corresponde à tag de recurso. O sistema de atributos do ABAC que fornece tanto contexto de usuário de nível alto quanto controle de acesso granular. Como o ABAC é baseado em atributo, ele pode realizar a autorização dinâmica de dados ou aplicações, concedendo ou revogando acesso em tempo real. O ABAC é útil em ambientes que estão escalando e em situações em que o gerenciamento de políticas de identidades ou de recursos se tornou um problema.

Por exemplo, é possível criar três perfis do IAM com a chave de tag `access-project`. Defina o valor da tag do primeiro perfil do IAM como `Heart`, o segundo como `Star` e o terceiro como `Lightning`. Você então pode usar uma única política que permita acesso quando o perfil do IAM e o recurso da AWS tiverem uma tag `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](tutorial_attribute-based-access-control.md). Para saber mais sobre os serviços compatíveis com ABAC, consulte [AWSServiços da que funcionam com o IAM](reference_aws-services-that-work-with-iam.md).

![\[Esse diagrama mostra que as tags aplicadas a uma entidade principal devem corresponder às tags aplicadas a um recurso para que o usuário tenha permissões de acesso ao recurso. As tags devem ser aplicadas a grupos de recursos, usuários individuais, recursos individuais e grupos do IAM.\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/tutorial-abac-concept-23.png)


## Comparação do ABAC com o modelo RBAC tradicional
<a name="introduction_attribute-based-access-control_compare-rbac"></a>

O modelo de autorização tradicional usado no IAM é o controle de acesso por perfil (RBAC). O RBAC define permissões com base no cargo ou no *perfil* de uma pessoa, o que é diferente de um perfil do IAM. O IAM inclui [políticas gerenciadas para funções de trabalho](access_policies_job-functions.md) 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 ou perfis do IAM). Como [prática recomendada](best-practices.md), conceda as permissões mínimas necessárias para o perfil de trabalho. Isso resulta em acesso com [privilégio mínimo](best-practices.md#grant-least-privilege). Cada política de trabalho lista os recursos específicos que as identidades que têm essa política atribuída a elas podem acessar. A desvantagem de usar o modelo RBAC tradicional é que, quando você ou seus usuários adicionam novos recursos ao ambiente, é 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 perfil do IAM para definir os recursos que qualquer pessoa com permissão para assumir esse perfil pode acessar. Se um funcionário mudar de cargo na sua empresa, você atribuirá a ele outra função do IAM. Você pode atribuir mais de um perfil do IAM a pessoas ou a programas. 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 do IAM `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.

![\[Esse diagrama ilustra que o controle de acesso baseado em perfil exige que cada identidade seja atribuída a uma política baseada em cargo específica para acessar recursos diferentes.\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/tutorial-abac-rbac-concept-23.png)


**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 o perfil do IAM 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 responder de modo dinâmico a mudança e crescimento.** Como as permissões para novos recursos são concedidas automaticamente com base em atributos, você não precisa atribuir políticas às identidades manualmente. Por exemplo, se a empresa já oferece suporte aos projetos `Heart` e `Star` que usam o ABAC, é fácil adicionar um novo projeto `Lightning`. Um administrador do IAM cria um novo perfil do IAM com a tag `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 o perfil do IAM pode criar e visualizar instâncias marcadas com `access-project` = `Lightning`. Outro cenário é quando um membro da equipe muda do projeto `Heart` para o projeto `Lightning`. Para fornecer aos membros da equipe acesso ao projeto `Lightning`, o administrador do IAM atribui a eles outro perfil 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](best-practices.md#grant-least-privilege). Usando o RBAC tradicional, você escreve uma política que permite o acesso a recursos específicos. Porém, quando você usa o ABAC, pode permitir ações em todos os recursos se a tag de recurso corresponder à tag da entidade principal.
+ **Use atributos de funcionário do seu diretório corporativo com ABAC.** Você pode configurar seu provedor SAML ou OIDC para passar tags de sessão para o IAM. Quando seus funcionários formam uma federação na AWS, o IAM aplica os atributos desses funcionários à entidade principal. 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](tutorial_attribute-based-access-control.md).