O blog da AWS
Controle de acesso baseado em atributos (ABAC)
Por Sébastien Stormacq, Principal Developer Advocate na AWS
12 de setembro de 2022: Este blogpost foi atualizado para refletir o novo nome do AWS Single Sign-On (SSO) – AWS IAM Identity Center. Leia mais sobre a mudança de nome aqui.
O AWS IAM Identity Center (sucessor do AWS Single Sign-On) facilita o gerenciamento centralizado do acesso a várias contas e aplicativos de negócios da AWS, e fornece aos usuários acesso de logon único a todas as suas contas e aplicativos atribuídos em um só local. Com o AWS IAM Identity Center (sucessor do AWS Single Sign-On), você pode gerenciar com facilidade o acesso e as permissões de usuário a todas as suas contas no AWS Organizations de forma centralizada. O AWS IAM Identity Center (sucessor do AWS Single Sign-On) configura e mantém todas as permissões necessárias para as suas contas automaticamente, sem exigir qualquer configuração adicional nas contas individuais. Você pode atribuir permissões de usuário com base nas funções de trabalho comuns e as personaliza para atender seus requisitos de segurança específicos. O AWS IAM Identity Center (sucessor do AWS Single Sign-On) também inclui integrações incorporadas em várias aplicações de negócios, como Salesforce, Box e Microsoft 365.
O Controle de acesso baseado em 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 associar 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 seus principais do IAM. Essas políticas de ABAC podem ser criadas para permitir operações quando a tag do 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 passar atributos na sessão AWS quando o usuário realiza login na nuvem usando o AWS IAM Identity Center (sucessor do AWS Single Sign-On). Isso oferece gerenciamento centralizado de acesso à conta do AWS IAM Identity Center (sucessor do AWS Single Sign-On) e controle granular de acesso baseado em atributos (ABAC), com a flexibilidade de usar um provedor de identidade externo como por exemplo o Active Directory, Azure Active Directory ou Okta (para uma lista de provedores de identidade suportados pelo AWS IAM Identity Center (sucessor do AWS Single Sign-On), clique aqui).
Como configurar o AWS IAM Identity Center (sucessor do AWS Single Sign-On) para mapear atributos de usuários
Antes de configurar o AWS IAM Identity Center (sucessor do AWS Single Sign-On), há dois pontos a serem destacados.
Primeiro, o ABAC trabalhará com atributos de qualquer fonte de identidade configurada no AWS IAM Identity Center (sucessor do AWS Single Sign-On): O próprio AWS IAM Identity Center (sucessor do AWS Single Sign-On), o Active Directory ou um provedor de identidade externo.
Em segundo lugar, há duas maneiras de passar atributos para controle de acesso ao AWS IAM Identity Center (sucessor do AWS Single Sign-On). Você pode passar atributos diretamente na asserção SAML usando o prefixo
https://thinkwithwp.com/SAML/Attributes/AccessControl
– ou pode usar atributos que estão no Identity Store do AWS IAM Identity Center (sucessor do AWS Single Sign-On).
Esses atributos são criados pelo administrador (diretamento na console do AWS IAM Identity Center (sucessor do AWS Single Sign-On)), sincronizados desde um Active Directory ou sincronizados desde um provedor de identidade externo usando o provisionamento automático (SCIM).
No artigo “Integrações: Active Directory, Azure AD com AWS IAM e AWS Single Sign-On”, encontramos na prática o passo-a-passo de como realizar a federação entre identidades.
Para esta demonstração, utilizaremos o Microsoft Azure Active Directory como provedor de identidade externo e o protocolo SCIM para o provisionamento automático.
Resumo dos passos necessários para configuração do ABAC:
- Passo 1: No Microsoft Azure Active Directory, configure os atributos a serem sincronizados.
- Passo 2: No AWS IAM Identity Center (sucessor do AWS Single Sign-On), habilite a funcionalidade de controle de acesso e configure os atributos SCIM que deseja utilizar.
- Passo 3: No AWS IAM Identity Center (sucessor do AWS Single Sign-On), crie regras ABAC por meio de permission sets e políticas baseadas em recursos usando atributos especificados no passo 2.
Processo detalhado para configuração do ABAC
1. Configurando os atributos a serem sincronizados.
Neste exemplo utilizaremos o Microsoft Azure Active Directory como provedor de identidade, criando o usuário com o nome de Rafael Mantovani e no campo departamento atribuiremos o departamento como “Support”:
Em “Enterprise Applications”, selecionamos a opção “AWS IAM Identity Center (sucessor do AWS Single Sign-On)”:
E adicionamos os usuários como membro da Enterprise Application:
Configuramos Provisioning para provisionamento automático. O serviço se conecta ao ponto de extremidade do SCIM, usando as APIs Rest para automatizar o provisionamento e desprovisionamento de usuários e grupos.
2. Habilitando Atributos para controle de Acesso (Attributes for access control)
A funcionalidade de ABAC (atributos para controle de acesso) é um recurso do AWS IAM Identity Center (sucessor do AWS Single Sign-On) onde você especifica os atributos de usuário que deseja usar em políticas para controlar o acesso aos recursos AWS.
Os administradores podem atribuir este controle com base nos atributos já existentes em seus serviços de diretório.
Configuramos os atributos SCIM para controle de acesso usando o Attributes for access control nas configurações do AWS IAM Identity Center (sucessor do AWS Single Sign-On).
Neste exemplo usamos o valor:
${path:enterprise.department}
Ao utilizar este valor, o ABAC irá coincidir os valores de atributo de departamento que são provisionados pelo Azure AD via protocolo SCIM. Apenas usuários criados com o valor de atributo “departamento” que coincide com o valor da tag que iremos criar em recursos, terão os acessos necessários. Iremos facilitar este entendimento nos passos a seguir.
Através da console do AWS IAM Identity Center (sucessor do AWS Single Sign-On), confirmamos que o usuário foi sincronizado através do SCIM e o atributo Department populado em Users no AWS IAM Identity Center (sucessor do AWS Single Sign-On):
3. Criando regras ABAC
Criamos uma permission set e vinculamos ao usuário:
Neste exemplo utilizamos a politica abaixo:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [ "ec2:DescribeInstances"],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": ["ec2:StartInstances","ec2:StopInstances"],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Department": "${aws:PrincipalTag/Department}"
}
}
}
]
}
Como podemos ver nesta política, estamos utilizando a tag “department” para coincidir com o valor de atributo que o ABAC irá utilizar. Nesta política em questão, os usuários que coincidem este valor, poderão efetuar a tarefa de “start” e “stop” EC2.
Atribuimos à permissão aos usuários, em AWS Accounts selecionamos a guia AWS organization e vinculamos a política aos usuários e contas desejadas através da opção Assign users:
Efetuamos logon com o usuário Rafael Mantovani, e neste momento somente as permissões atribuídas foram apresentadas como opções:
Criamos duas máquinas, Servidor 01 e Servidor 02, com as seguintes configurações de tag:
Servidor 01 (Tag Key Department e Value Support)
Servidor 02 (sem a tag department configurada)
Neste exemplo esta instância possui tag “Department” como “Support”, fazendo um match com o atributo “Department” do usuário que efetuou o logon:
Agora em outra instância, desta vez sem a tag (ou até com a tag department com outro valor), recebemos a mensagem de erro abaixo, informando que não temos permissão para efetuar um “stop” no EC2:
Podemos efetuar um novo teste, com um logon de um usuário diferente chamado Daniel (que possui o atributo Departament populado como Developer):
Ao tentar executar stop nas instancias (tag com valor Support ou uma tag sem valor atribuído), o usuário recebe um erro de falha ao efetuar o “stop” do EC2:
Neste Blog, discutimos como o controle de acesso baseado em atributo (ABAC) serve como uma estratégia de autorização que define permissões com base em atributos. Podemos usar o AWS IAM Identity Center (sucessor do AWS Single Sign-On) para gerenciar o acesso aos recursos da AWS em várias contas da AWS usando atributos de usuário provenientes de qualquer origem de identidade do AWS IAM Identity Center (sucessor do AWS Single Sign-On)(no nosso cenário, utilizando o Azure Active Directory). O ABAC possui diversos benefícios no AWS IAM Identity Center (sucessor do AWS Single Sign-On):
- O ABAC requer menos conjuntos de permissões –como você não precisa criar políticas diferentes para funções de trabalho diferentes, você cria menos conjuntos de permissões. Isso reduz a complexidade do gerenciamento de permissões.
- Usando o ABAC, as equipes podem mudar e crescer rapidamente –as permissões para novos recursos são concedidas automaticamente com base em atributos quando os recursos são marcados adequadamente após a criação.
- Usar atributos de funcionário do diretório corporativo com ABAC –é possível usar atributos de funcionário existentes de qualquer origem de identidade configurada no AWS SSO para tomar decisões de controle de acesso na AWS.
- Rastrear quem está acessando recursos –Os administradores de segurança podem determinar facilmente a identidade de uma sessão examinando os atributos de usuário no AWS CloudTrail para rastrear a atividade do usuário na AWS.
Para obter informações sobre como configurar o ABAC usando o console do AWS IAM Identity Center (sucessor do AWS Single Sign-On), consulte Atributos para controle de acesso.
Para obter informações sobre como habilitar e configurar o ABAC usando as APIs do AWS IAM Identity Center (sucessor do AWS Single Sign-On), consulte CreateInstanceAccessControlAttributeConfiguration no Guia de referência da API do AWS IAM Identity Center (sucessor do AWS Single Sign-On)
Este artigo foi traduzido do Blog da AWS em Inglês.
Sobre o autor
Sébastien Stormacq é Principal Developer Advocate na AWS Paris.
Tradutores
Rafael Mantovani é Technical Account Manager na AWS Brasil.
Daniel Pires é Senior Technical Account Manager na AWS Brasil.
Revisor
Caio Ribeiro Cesar atualmente trabalha como arquiteto de soluções especializadas em tecnologia da Microsoft na nuvem AWS. Ele iniciou sua carreira profissional como administrador de sistemas, que continuou por mais de 14 anos em áreas como Segurança da Informação, Identity Online e Plataformas de Email Corporativo. Recentemente, se tornou fã da computação em nuvem da AWS e auxilia os clientes a utilizar o poder da tecnologia da Microsoft na AWS.