Tutorial do IAM: Usar etiquetas de sessão SAML para ABAC - AWS Identity and Access Management

Tutorial do IAM: Usar etiquetas de sessão SAML para ABAC

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 anexar etiquetas a recursos do IAM, incluindo entidades (usuários ou funções) do IAM, e a recursos da AWS. Quando as entidades são usadas para fazer solicitações AWS, elas se tornam principais e incluem tags.

Você também pode passar tags de sessão ao assumir uma função ou federar um usuário. Depois disso, é possível definir políticas que usam chaves de condição de tag para conceder permissões aos seus principais com base nas tags. Ao usar tags para controlar o acesso aos recursos da AWS, você permite que suas equipes e recursos se expandam com menos alterações nas políticas da AWS. As políticas de ABAC são mais flexíveis do que as políticas tradicionais da AWS, nas quais é obrigatório listar cada recurso individual. Para obter mais informações sobre o ABAC e sua vantagem em relação às políticas tradicionais, consulte O que é ABAC para a AWS?.

Se sua empresa usar um provedor de identidade (IdP) baseado em SAML para gerenciar identidades corporativas de usuário, você pode usar atributos SAML para controle de acesso granular na AWS. Os atributos podem incluir identificadores do centro de custo, endereços de e-mail do usuário, classificações de departamento e atribuições de projeto. Ao passar esses atributos como tags de sessão, você pode controlar o acesso à AWS com base nessas tags de sessão.

Para concluir o tutorial ABAC passando atributos SAML para o principal de sessão, conclua as tarefas em Tutorial do IAM: Definir permissões para acessar recursos da AWS com base em etiquetas, com as alterações incluídas neste tópico.

Pré-requisitos

Para executar as etapas para usar tags de sessão SAML para ABAC, você já deve ter o seguinte:

  • Acesso a um IdP baseado em SAML onde você possa criar usuários de teste com atributos específicos.

  • Uma conta da AWS com a qual você possa fazer login como usuário do IAM com permissões administrativas. Se você tiver uma nova conta e fizer login como o usuário raiz da Conta da AWS, crie um usuário administrador do IAM.

  • Experimente criar e editar usuários, funções e políticas do IAM no AWS Management Console. No entanto, se você precisar de ajuda para lembrar de um processo de gerenciamento do IAM, o tutorial de ABAC fornece links por meio dos quais é possível visualizar instruções detalhadas.

  • Experiência na configuração de um IdP baseado em SAML no IAM. Para visualizar mais detalhes e links da documentação detalhada do IAM, consulte Passar tags de sessão usando AssumeRoleWithSAML.

Etapa 1: Criar um usuário de teste do IAM

Siga as instruções em Etapa 1: Criar usuários de teste. Como suas identidades são definidas em seu provedor, não é necessário adicionar usuários do IAM para os seus funcionários.

Etapa 2: Criar a política de ABAC

Siga as instruções na Etapa 2: Criar a política de ABAC para criar a política gerenciada especificada no IAM.

Etapa 3: Criar e configurar a função SAML

Ao usar o tutorial ABAC para SAML, é necessário executar etapas adicionais para criar a função, configurar o IdP SAML e habilitar o acesso ao AWS Management Console. Para mais informações, consulte Etapa 3: Criar funções.

Etapa 3A: Criar a função SAML

Crie uma única função que confie no seu provedor de identidade SAML e no usuário test-session-tags criado na etapa 1. O tutorial ABAC usa funções distintas com diferentes tags de função. Como você está passando tags de sessão do seu IdP SAML, é preciso apenas uma função. Para saber como criar uma função baseada em SAML, consulte Criar uma função para uma federação do SAML 2.0 (console).

Nomeie a função access-session-tags. Anexe a política de permissões access-same-project-team à função. Edite a política de confiança da função para usar a política a seguir. Para obter instruções detalhadas sobre como editar a relação de confiança de uma função, consulte Modificar uma função (console).

A política de confiança da função a seguir permite que seu provedor de identidade SAML e o usuário test-session-tags assumam a função. Ao assumirem a função, eles devem passar as três tags de sessão especificadas. A ação sts:TagSession é necessária para permitir a passagem de tags de sessão.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowSamlIdentityAssumeRole", "Effect": "Allow", "Action": [ "sts:AssumeRoleWithSAML", "sts:TagSession" ], "Principal": {"Federated":"arn:aws:iam::123456789012:saml-provider/ExampleCorpProvider"}, "Condition": { "StringLike": { "aws:RequestTag/cost-center": "*", "aws:RequestTag/access-project": "*", "aws:RequestTag/access-team": [ "eng", "qas" ] }, "StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"} } } ] }

A declaração AllowSamlIdentityAssumeRole permite que os membros das equipes de Engenharia e Garantia de Qualidade assumam essa função ao se federarem no Example Corporation IdP da AWS. O provedor SAML ExampleCorpProvider é definido no IAM. O administrador já configurou a declaração do SAML para passar as três tags de sessão necessárias. A declaração pode passar tags adicionais, mas essas três devem estar presentes. Os atributos da identidade podem ter qualquer valor para as tags access-project e cost-center. No entanto, o valor do atributo access-team deve corresponder a eng ou qas para indicar que a identidade está na equipe de Engenharia ou Garantia de Qualidade.

Etapa 3B: Configurar o IdP SAML

Configure seu IdP SAML para passar os atributos cost-center, access-project e access-team como tags de sessão. Para mais informações, consulte Passar tags de sessão usando AssumeRoleWithSAML.

Para passar esses atributos como tags de sessão, inclua os seguintes elementos em sua declaração do SAML.

<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:cost-center"> <AttributeValue>987654</AttributeValue> </Attribute> <Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:access-project"> <AttributeValue>peg</AttributeValue> </Attribute> <Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:access-team"> <AttributeValue>eng</AttributeValue> </Attribute>

Etapa 3C: habilitar o acesso ao console

Habilite o acesso ao console para seus usuários federados do SAML. Para mais informações, consulte Habilitar o acesso de usuários federados SAML 2.0 ao AWS Management Console.

Etapa 4: Testar a criação de segredos

Federe no AWS Management Console usando a função access-session-tags. Para mais informações, consulte Habilitar o acesso de usuários federados SAML 2.0 ao AWS Management Console. Depois, siga as instruções Etapa 4: Testar a criação de segredos para criar segredos. Use identidades SAML diferentes com atributos para corresponder às tags indicadas no tutorial ABAC. Para mais informações, consulte Etapa 4: Testar a criação de segredos.

Etapa 5: Testar a visualização de segredos

Siga as instruções em Etapa 5: Testar a visualização de segredos para exibir os segredos que você criou na etapa anterior. Use identidades SAML diferentes com atributos para corresponder às tags indicadas no tutorial ABAC.

Etapa 6: Testar a escalabilidade

Siga as instruções em Etapa 6: Testar a escalabilidade para testar a escalabilidade. Faça isso adicionando uma nova identidade ao seu IdP baseado em SAML com os seguintes atributos:

  • cost-center = 101010

  • access-project = cen

  • access-team = eng

Etapa 7: Testar a atualização e a exclusão de segredos

Siga as instruções em Etapa 7: Testar a atualização e a exclusão de segredos para atualizar e excluir segredos. Use identidades SAML diferentes com atributos para corresponder às tags indicadas no tutorial ABAC.

Importante

Exclua todos os segredos que você criou para evitar cobranças. Para obter detalhes sobre preços no Secrets Manager, consulte Preços do AWS Secrets Manager.

Resumo

Você concluiu com êxito todas as etapas necessárias para usar tags de sessão SAML e tags de recursos para o gerenciamento de permissões.

nota

Você adicionou políticas que permitem ações somente sob condições específicas. Se você aplicar uma política diferente para seus usuários ou funções que tenha permissões mais amplas, as ações podem não estar limitadas a exigir marcação. Por exemplo, se você conceder permissões administrativas completas a um usuário usando a política gerenciada AdministratorAccess da AWS, essas políticas não vão restringir esse acesso. Para obter mais informações sobre como as permissões são determinadas quando várias políticas estão envolvidas, consulte Determinar se uma solicitação é permitida ou negada em uma conta.