Visão geral do tutorial Pré-requisitos Etapa 1: Criar usuários de teste Etapa 2: Criar a política de ABAC Etapa 3: Criar funções Etapa 4: Testar a criação de segredos Etapa 5: Testar a visualização de segredos Etapa 6: Testar a escalabilidade Etapa 7: Testar a atualização e a exclusão de segredos Resumo Recursos relacionados

Tutorial do IAM: Definir permissões para acessar recursos da AWS com base em etiquetas

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 etiquetas a recursos do IAM, incluindo entidades (usuários ou funções) do IAM, e a recursos da AWS. Você pode ainda 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?.

nota

Você deve passar um único valor para cada etiqueta de sessão. O AWS Security Token Service não oferece suporte a etiquetas de sessão de vários valores.

Tópicos

Visão geral do tutorial
Pré-requisitos
Etapa 1: Criar usuários de teste
Etapa 2: Criar a política de ABAC
Etapa 3: Criar funções
Etapa 4: Testar a criação de segredos
Etapa 5: Testar a visualização de segredos
Etapa 6: Testar a escalabilidade
Etapa 7: Testar a atualização e a exclusão de segredos
Resumo
Recursos relacionados
Tutorial do IAM: Usar etiquetas de sessão SAML para ABAC

Visão geral do tutorial

Este tutorial mostra como criar e testar uma política que permite que funções do IAM com etiquetas de entidades acessem recursos com etiquetas correspondentes. Quando um principal faz uma solicitação para a AWS, suas permissões são concedidas com base na correspondência entre as tags de principal e de recurso. Essa estratégia permite que os indivíduos visualizem ou editem apenas os recursos da AWS necessários para seus trabalhos.

Cenário

Vamos supor que você seja um desenvolvedor líder em uma grande empresa chamada Example Corporation e seja um administrador experiente do IAM. Você está familiarizado com a criação e o gerenciamento de usuários, funções e políticas do IAM. Você quer garantir que os engenheiros de desenvolvimento e membros da equipe de controle de qualidade possam acessar os recursos necessários. Também é necessária uma estratégia que possa ser dimensionada à medida que sua empresa cresce.

Você escolhe usar as etiquetas de recursos da AWS e as etiquetas de entidades de função do IAM para implementar uma estratégia ABAC para serviços compatíveis com ela, começando com o AWS Secrets Manager. Para saber quais serviços oferecem suporte à autorização com base em tags, consulte Serviços da AWS que funcionam com o IAM. Para saber quais chaves de condição de marcação você pode usar em uma política com as ações e recursos de cada serviço, consulte Ações, recursos e chaves de condição de serviços da AWS. Você pode configurar seu provedor de identidade da Web ou com base em SAML 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 saber como o uso de tags de sessão com uma identidade federada SAML difere deste tutorial, consulte Tutorial do IAM: Usar etiquetas de sessão SAML para ABAC.

Os membros da equipe de engenharia e controle de qualidade estão no projeto Pegasus ou Unicorn . Escolha os seguintes valores de tag de projeto e equipe de 3 caracteres:

access-project = peg para o projeto Pegasus
access-project = uni para o projeto Unicorn
access-team = eng para a equipe de engenharia
access-team = qas para a equipe de controle de qualidade

Além disso, escolha se deseja exigir a tag de alocação de custos cost-center para habilitar relatórios personalizados de faturamento da AWS. Para obter mais informações, consulte Usar tags de alocação de custos no Guia do usuário do AWS Billing and Cost Management.

Resumo das principais decisões

Os funcionários fazem login com credenciais de usuário do IAM e assumem a função do IAM para suas respectivas equipes e projetos. Se sua empresa tiver seu próprio sistema de identidade, será possível configurar a federação para permitir que os funcionários assumam uma função sem usuários do IAM. Para ter mais informações, consulte Tutorial do IAM: Usar etiquetas de sessão SAML para ABAC.
A mesma política é anexada a todas as funções. As ações são permitidas ou negadas com base em tags.
Os funcionários poderão criar novos recursos, mas somente se anexarem as mesmas tags ao recurso que são aplicadas à sua função. Isso garante que os funcionários possam visualizar o recurso depois de criá-lo. Os administradores não precisam mais atualizar políticas com o ARN de novos recursos.
Os funcionários podem ler recursos de propriedade de sua equipe, independentemente do projeto.
Os funcionários podem atualizar e excluir recursos de propriedade de sua própria equipe e do projeto.
Os administradores do IAM podem adicionar uma nova função para novos projetos. Eles podem criar e etiquetar um novo usuário do IAM para permitir o acesso à função apropriada. Os administradores não precisam editar uma política para oferecer suporte a um novo projeto ou membro da equipe.

Neste tutorial, você marcará cada recurso, marcará suas funções de projeto e adicionará políticas às funções para permitir o comportamento descrito anteriormente. A política resultante permite que as funções Create, Read, Update e Delete acessem recursos marcados com as mesmas tags de projeto e equipe. A política também permite o acesso Read entre projetos para recursos marcados com a mesma equipe.

Criação de permissões do tutorial de ABAC

Pré-requisitos

Para executar as etapas neste tutorial, você já deve ter o seguinte:

Uma Conta da AWS com a qual você possa fazer login como usuário com permissões administrativas.
O ID de conta de 12 dígitos, que você usa para criar as funções na etapa 3.

Para localizar o ID da conta da AWS usando o AWS Management Console, selecioneSuporte na barra de navegação do canto superior direito e selecione Support Center. O número da conta (ID) aparece no painel de navegação à esquerda.
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, este tutorial fornece links por meio dos quais é possível visualizar instruções detalhadas.

Etapa 1: Criar usuários de teste

Para testes, crie quatro usuários do IAM com permissões para assumir funções com as mesmas etiquetas. Isso facilita a adição de mais usuários às suas equipes. Ao marcar os usuários, eles recebem acesso automaticamente para assumir a função correta. Não será necessário adicionar os usuários à política de confiança da função se eles trabalharem apenas em um projeto e equipe.

Crie a seguinte política gerenciada pelo cliente chamada access-assume-role. Para obter mais informações sobre como criar uma política JSON, consulte Criação de políticas do IAM.

Política de ABAC: assumir qualquer função de ABAC, mas somente quando as tags da função e do usuário forem correspondentes

A política a seguir permite que um usuário assuma qualquer função em sua conta com o prefixo de nome access-. A função também deve ser marcada com as mesmas tags de projeto, equipe e centro de custos que o usuário.

Para usar esta política, substitua o texto do espaço reservado em itálico pelas informações da conta.
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "TutorialAssumeRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::account-ID-without-hyphens:role/access-*",
            "Condition": {
                "StringEquals": {
                    "iam:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
                    "iam:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
                    "iam:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
                }
            }
        }
    ]
}
```
Para dimensionar este tutorial para um grande número de usuários, é possível anexar a política a um grupo e adicionar cada usuário ao grupo. Para obter mais informações, consulte Criação de grupos de usuários do IAM e Adicionar e remover usuários de um grupo de usuários do IAM.

Crie os usuários do IAM a seguir e anexe a política de permissões access-assume-role. Certifique-se de selecionar Fornecer ao usuário acesso ao AWS Management Console e depois adicione as seguintes tags. Para obter mais informações sobre como criar e marcar um novo usuário, consulte Criação de usuários do IAM (console).

Usuários de ABAC
Nome do usuário	Chave de tag de usuário	Valor de tag de usuário
`access-Arnav-peg-eng`	`access-project` `access-team` `cost-center`	`peg` `eng` `987654`
`access-Mary-peg-qas`	`access-project` `access-team` `cost-center`	`peg` `qas` `987654`
`access-Saanvi-uni-eng`	`access-project` `access-team` `cost-center`	`uni` `eng` `123456`
`access-Carlos-uni-qas`	`access-project` `access-team` `cost-center`	`uni` `qas` `123456`

Etapa 2: Criar a política de ABAC

Crie a política a seguir chamada access-same-project-team. Você adicionará essa política às funções em uma etapa posterior. Para obter mais informações sobre como criar uma política JSON, consulte Criação de políticas do IAM.

Para obter políticas adicionais que podem ser adaptadas para este tutorial, consulte as seguintes páginas:

Política de ABAC: acessar recursos do Secrets Manager somente quando as etiquetas de entidade e recurso forem correspondentes

A política a seguir permitirá que os principais criem, leiam, editem e excluam recursos, mas somente quando esses recursos forem marcados com os mesmos pares de chave/valor que o principal. Quando um principal cria um recurso, ele deve adicionar as tags access-project, access-team e cost-center e com valores correspondentes às tags do principal. A política também permite adicionar as tags opcionais Name ou OwnedBy.


{
 "Version": "2012-10-17",
 "Statement": [
     {
         "Sid": "AllActionsSecretsManagerSameProjectSameTeam",
         "Effect": "Allow",
         "Action": "secretsmanager:*",
         "Resource": "*",
         "Condition": {
             "StringEquals": {
                 "aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
                 "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
                 "aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
             },
             "ForAllValues:StringEquals": {
                 "aws:TagKeys": [
                     "access-project",
                     "access-team",
                     "cost-center",
                     "Name",
                     "OwnedBy"
                 ]
             },
             "StringEqualsIfExists": {
                 "aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}",
                 "aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}",
                 "aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}"
             }
         }
     },
     {
         "Sid": "AllResourcesSecretsManagerNoTags",
         "Effect": "Allow",
         "Action": [
             "secretsmanager:GetRandomPassword",
             "secretsmanager:ListSecrets"
         ],
         "Resource": "*"
     },
     {
         "Sid": "ReadSecretsManagerSameTeam",
         "Effect": "Allow",
         "Action": [
             "secretsmanager:Describe*",
             "secretsmanager:Get*",
             "secretsmanager:List*"
         ],
         "Resource": "*",
         "Condition": {
             "StringEquals": {
                 "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}"
             }
         }
     },
     {
         "Sid": "DenyUntagSecretsManagerReservedTags",
         "Effect": "Deny",
         "Action": "secretsmanager:UntagResource",
         "Resource": "*",
         "Condition": {
             "ForAnyValue:StringLike": {
                 "aws:TagKeys": "access-*"
             }
         }
     },
     {
         "Sid": "DenyPermissionsManagement",
         "Effect": "Deny",
         "Action": "secretsmanager:*Policy",
         "Resource": "*"
     }
 ]
}

O que essa política faz?

A declaração AllActionsSecretsManagerSameProjectSameTeam permitirá todas as ações desse serviço em todos os recursos relacionados, mas somente se as tags de recurso forem correspondentes às tags de principal. Ao adicionar "Action": "secretsmanager:*" à política, ela se expande à medida que o Secrets Manager o faz. Se o Secrets Manager adicionar uma nova operação de API, não será necessário adicionar essa ação à instrução. A declaração implementa o ABAC usando três blocos de condição. A solicitação será permitida somente se todos os três blocos retornarem true.
- O primeiro bloco de condição dessa declaração retornará true se as chaves de tag especificadas estiverem presentes no recurso e seus valores forem correspondentes às tags de principal. Esse bloco retorna false para tags não correspondentes ou para ações que não oferecem suporte à marcação de recursos. Para saber quais ações não são permitidas por esse bloco, consulte Ações, recursos e chaves de condição do AWS Secrets Manager. Essa página mostra que as ações executadas no tipo de recurso Secret (Segredo) oferecem suporte à chave de condição secretsmanager:ResourceTag/tag-key. Algumas ações do Secrets Manager não oferecem suporte a esse tipo de recurso, incluindo GetRandomPassword e ListSecrets. É necessário criar declarações adicionais para permitir essas ações.
- O segundo bloco de condição retornará true se cada chave de tag passada na solicitação for incluída na lista especificada. Isso é feito usando ForAllValues com o operador de condição StringEquals. Se nenhuma chave ou nenhum subconjunto do conjunto de chaves for passado, a condição retornará true. Isso permite operações Get* que não permitem passar tags na solicitação. Se o solicitante incluir uma chave de tag que não estiver na lista, a condição retornará false. Cada chave de tag passada na solicitação deve corresponder a um membro dessa lista. Para ter mais informações, consulte Chaves de contexto de múltiplos valores.
- O terceiro bloco de condição retornará true se a solicitação oferecer suporte à passagem de tags, se todas as três tags estiverem presentes e se forem correspondentes aos valores de tag do principal. Esse bloco também retorna true se a solicitação não oferecer suporte à passagem de tags. Isso ocorre devido a ...IfExists no operador de condição. O bloco retornará false se não houver nenhuma tag passada durante uma ação que ofereça suporte a ele ou se as chaves e os valores das tags não forem correspondentes.
A declaração AllResourcesSecretsManagerNoTags permite as ações GetRandomPassword e ListSecrets que não são permitidas pela primeira declaração.
A declaração ReadSecretsManagerSameTeam permitirá operações somente leitura se o principal estiver marcado com a mesma tag access-team que o recurso. Isso é permitido independentemente da tag do projeto ou do centro de custos.
A declaração DenyUntagSecretsManagerReservedTags nega solicitações para remover tags com chaves que começam com "access-" do Secrets Manager. Essas tags são usadas para controlar o acesso aos recursos, portanto, a remoção de tags pode remover permissões.
A declaração DenyPermissionsManagement nega o acesso para criar, editar ou excluir políticas baseadas em recursos do Secrets Manager. Essas políticas podem ser usadas para alterar as permissões do segredo.

Importante

Essa política usa uma estratégia para permitir todas as ações de um serviço, mas nega explicitamente ações que alteram permissões. Negar uma ação substitui qualquer outra política que permita que o principal execute essa ação. Isso pode ter resultados indesejados. Como melhor prática, use negações explícitas somente quando não houver nenhuma circunstância que permita essa ação. Caso contrário, permita uma lista de ações individuais, e as ações indesejadas serão negadas por padrão.

Etapa 3: Criar funções

Crie as funções do IAM a seguir e anexe a política access-same-project-team que você criou na etapa anterior. Para obter mais informações sobre como criar funções do IAM, consulte Criação de uma função para delegar permissões a um usuário do IAM. Se você optar por usar a federação em vez de usuários e funções do IAM, consulte Tutorial do IAM: Usar etiquetas de sessão SAML para ABAC.

Funções de ABAC
Função de trabalho	Nome do perfil	Tags de função	Descrição de função
Projeto Pegasus de engenharia	`access-peg-engineering`	`access-project` = `peg` `access-team` = `eng` `cost-center` = `987654`	Permite que os engenheiros leiam todos os recursos de engenharia e criem e gerenciem recursos de engenharia do Pegasus.
Projeto Pegasus de controle de qualidade	`access-peg-quality-assurance`	`access-project` = `peg` `access-team` = `qas` `cost-center` = `987654`	Permite que a equipe de controle de qualidade leia todos os recursos de controle de qualidade e crie e gerencie todos os recursos de controle de qualidade do Pegasus.
Projeto Unicorn de engenharia	`access-uni-engineering`	`access-project` = `uni` `access-team` = `eng` `cost-center` = `123456`	Permite que os engenheiros leiam todos os recursos de engenharia e criem e gerenciem recursos de engenharia do Unicorn.
Projeto Unicorn de controle de qualidade	`access-uni-quality-assurance`	`access-project` = `uni` `access-team` = `qas` `cost-center` = `123456`	Permite que a equipe de controle de qualidade leia todos os recursos de controle de qualidade e crie e gerencie todos os recursos de controle de qualidade do Unicorn.

Etapa 4: Testar a criação de segredos

A política de permissões anexada às funções permite que os funcionários criem segredos. Isso será permitido somente se o segredo estiver marcado com seu projeto, equipe e centro de custos. Verifique se suas permissões estão funcionando conforme o esperado, fazendo login como seus usuários, assumindo a função correta e testando a atividade no Secrets Manager.

Como testar a criação de um segredo com e sem as tags necessárias

Na janela principal do navegador, permaneça conectado como usuário administrador para que seja possível revisar usuários, funções e políticas no IAM. Use uma janela incognito do navegador ou um navegador separado para seus testes. Lá, faça login como o usuário do IAM access-Arnav-peg-eng e abra o console do Secrets Manager em https://console.aws.amazon.com/secretsmanager/.
Tente alternar para a função access-uni-engineering.

Ocorrerá falha nessa operação porque os valores de tag access-project e cost-center não são correspondentes para o usuário access-Arnav-peg-eng e a função access-uni-engineering.

Para obter mais informações sobre alternância de perfis no AWS Management Console, consulte Alternância para uma função (console)
Alterne para a função access-peg-engineering.

Armazene um novo segredo usando as seguintes informações. Para saber como armazenar um segredo, consulte Criar um segredo básico no Guia do usuário do AWS Secrets Manager.

Importante

O Secrets Manager exibe alertas de que você não tem permissões para os serviços adicionais da AWS que funcionam com o Secrets Manager. Por exemplo, para criar credenciais para um banco de dados do Amazon RDS, é necessário ter permissão para descrever instâncias do RDS, clusters do RDS e clusters do Amazon Redshift. Você pode ignorar esses alertas, pois não vai usar esses serviços específicos da AWS neste tutorial.

Na seção Select secret type (Selecionar tipo de segredo), escolha Other type of secrets (Outros tipos de segredos). Nas duas caixas de texto, insira test-access-key e test-access-secret.
Insira test-access-peg-eng no campo Secret name (Nome do segredo).
Adicione diferentes combinações de tags da tabela a seguir e visualize o comportamento esperado.
Escolha Store (Armazenar) para tentar criar o segredo. Quando o armazenamento falhar, volte para as páginas anteriores do console do Secrets Manager e use o próximo conjunto de etiquetas da tabela a seguir. O último conjunto de tags é permitido e criará o segredo com êxito.

Combinações de tags de ABAC para a função `test-access-peg-eng`
Valor da tag `access-project`	Valor da tag `access-team`	Valor da tag `cost-center`	Tags adicionais	Comportamento esperado
(none)	(none)	(none)	(none)	Negado porque o valor da tag `access-project` não é correspondente ao valor do perfil de `peg`.
`uni`	`eng`	`987654`	(none)	Negado porque o valor da tag `access-project` não é correspondente ao valor do perfil de `peg`.
`peg`	`qas`	`987654`	(none)	Negado porque o valor da tag `access-team` não é correspondente ao valor do perfil de `eng`.
`peg`	`eng`	`123456`	(none)	Negado porque o valor da tag `cost-center` não é correspondente ao valor do perfil de `987654`.
`peg`	`eng`	`987654`	`owner` = `Jane`	Negado porque a tag adicional `owner` não é permitida pela política, mesmo que todas as três tags necessárias estejam presentes e seus valores correspondam aos valores da função.
`peg`	`eng`	`987654`	`Name` = `Jane`	Permitido porque todas as três tags necessárias estão presentes e seus valores são correspondentes aos valores da função. Você também tem permissão para incluir a tag opcional `Name`.

Saia e repita as três primeiras etapas deste procedimento para cada um dos valores de função e de tag a seguir. Na quarta etapa deste procedimento, teste qualquer conjunto de tags ausentes, tags opcionais, tags não permitidas e valores de tags inválidos que você escolher. Depois disso, use as tags necessárias para criar um segredo com as tags e o nome a seguir.

Funções e tags de ABAC
Nome do usuário	Nome do perfil	Nome de segredo	Tags de segredo
`access-Mary-peg-qas`	`access-peg-quality-assurance`	`test-access-peg-qas`	`access-project` = `peg` `access-team` = `qas` `cost-center` = `987654`
`access-Saanvi-uni-eng`	`access-uni-engineering`	`test-access-uni-eng`	`access-project` = `uni` `access-team` = `eng` `cost-center` = `123456`
`access-Carlos-uni-qas`	`access-uni-quality-assurance`	`test-access-uni-qas`	`access-project` = `uni` `access-team` = `qas` `cost-center` = `123456`

Etapa 5: Testar a visualização de segredos

A política anexada a cada função permite que os funcionários visualizem todos os segredos marcados com o nome da equipe, independentemente do projeto. Verifique se suas permissões estão funcionando conforme o esperado testando suas funções no Secrets Manager.

Como testar a visualização de um segredo com e sem as tags necessárias

Faça login como um dos seguintes usuários do IAM:
- access-Arnav-peg-eng
- access-Mary-peg-qas
- access-Saanvi-uni-eng
- access-Carlos-uni-qas
Alterne para a função correspondente:
- access-peg-engineering
- access-peg-quality-assurance
- access-uni-engineering
- access-uni-quality-assurance
Para obter mais informações sobre como alternar funções no AWS Management Console, consulte Alternância para uma função (console).
No painel de navegação à esquerda, escolha o ícone do menu para expandir o menu e escolha Secrets (Segredos).
Você deve ver todos os quatro segredos na tabela, independentemente da sua função atual. Isso é esperado porque a política chamada access-same-project-team permite a ação secretsmanager:ListSecrets para todos os recursos.
Escolha o nome de um dos segredos.

Na página de detalhes do segredo, as tags da função determinam se é possível visualizar o conteúdo da página. Compare o nome da função com o nome do segredo. Se eles compartilharem o mesmo nome de equipe, as tags access-team serão correspondentes. Se elas não forem correspondentes, o acesso será negado.

Comportamento de visualização de segredo de ABAC para cada função
Nome do perfil	Nome de segredo	Comportamento esperado
`access-peg-engineering`	`test-access-peg-eng`	Permitido
	`test-access-peg-qas`	Negado
	`test-access-uni-eng`	Permitido
	`test-access-uni-qas`	Negado
`access-peg-quality-assurance`	`test-access-peg-eng`	Negado
	`test-access-peg-qas`	Permitido
	`test-access-uni-eng`	Negado
	`test-access-uni-qas`	Permitido
`access-uni-engineering`	`test-access-peg-eng`	Permitido
	`test-access-peg-qas`	Negado
	`test-access-uni-eng`	Permitido
	`test-access-uni-qas`	Negado
`access-uni-quality-assurance`	`test-access-peg-eng`	Negado
	`test-access-peg-qas`	Permitido
	`test-access-uni-eng`	Negado
	`test-access-uni-qas`	Permitido

Na trilha de navegação na parte superior da página, escolha Secrets (Segredos) para retornar à lista de segredos. Repita as etapas neste procedimento usando funções diferentes para testar se é possível visualizar cada um dos segredos.

Etapa 6: Testar a escalabilidade

Um motivo importante para usar o controle de acesso baseado em atributo (ABAC) em vez do controle de acesso baseado em função (RBAC) é a escalabilidade. À medida que sua empresa adiciona novos projetos, equipes ou pessoas à AWS, não é necessário atualizar suas políticas orientadas pelo ABAC. Por exemplo, vamos supor que a Example Company esteja financiando um novo projeto, o código chamado Centaur. Uma engenheira chamada Saanvi Sarkar será a engenheira-chefe da Centaur enquanto continua trabalhando no projeto Unicorn . Saanvi também revisará o trabalho para projeto Peg. Há também vários engenheiros recém-contratados, incluindo Nikhil Jayashankar, que trabalhará apenas no projeto Centaur .

Como adicionar o novo projeto à AWS

Faça login como usuário administrador do IAM e abra o console do IAM em https://console.aws.amazon.com/iam/.
No painel de navegação à esquerda, escolha Roles (Funções) e adicione uma função do IAM chamada access-cen-engineering. Anexe a política de permissões access-same-project-team ao perfil e adicione as seguintes tags de perfil:
- access-project = cen
- access-team = eng
- cost-center = 101010
No painel de navegação à esquerda, escolha Uses (Usuários).
Adicione um novo usuário denominado access-Nikhil-cen-eng, anexe a política denominada access-assume-role e adicione as seguintes tags de usuário.
- access-project = cen
- access-team = eng
- cost-center = 101010
Use os procedimentos em Etapa 4: Testar a criação de segredos e Etapa 5: Testar a visualização de segredos. Em outra janela do navegador, teste se Nikhil pode criar apenas segredos de engenharia do Centaur e se ele pode visualizar todos os segredos de engenharia.
Na janela principal do navegador em que você fez login como administrador, escolha o usuário access-Saanvi-uni-eng.
Na guia Permissions (Permissões), remova a política de permissões access-assume-role.
Adicione a seguinte política em linha chamada access-assume-specific-roles. Para obter mais informações sobre como adicionar uma política em linha a um usuário, consulte Para incorporar uma política em linha de um usuário ou uma função (console).

Política de ABAC: assumir apenas funções específicas

Essa política permite que Saanvi assuma os perfis de engenharia nos projetos Pegasus e Centaur. É necessário criar essa política personalizada porque o IAM não oferece suporte a etiquetas de vários valores. Não é possível marcar o usuário de Saanvi com access-project = peg e access-project = cen. Além disso, o modelo de autorização da AWS não pode ser correspondente a ambos os valores. Para ter mais informações, consulte Regras para etiquetar no IAM e no AWS STS. Em vez disso, é necessário especificar manualmente as duas funções que ela pode assumir.

Para usar esta política, substitua o texto do espaço reservado em itálico pelas informações da conta.
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "TutorialAssumeSpecificRoles",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::account-ID-without-hyphens:role/access-peg-engineering",
                "arn:aws:iam::account-ID-without-hyphens:role/access-cen-engineering"
            ]
        }
    ]
}
```
Use os procedimentos em Etapa 4: Testar a criação de segredos e Etapa 5: Testar a visualização de segredos. Em outra janela do navegador, verifique se Saanvi pode assumir ambas as funções. Verifique se ela pode criar segredos apenas para seu projeto, equipe e centro de custos, dependendo das tags da função. Verifique também que ela pode visualizar detalhes sobre todos os segredos de propriedade da equipe de engenharia, incluindo os que ela acabou de criar.

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

A política access-same-project-team anexada às funções permite que os funcionários atualizem e excluam todos os segredos marcados com seu projeto, equipe e centro de custos. Verifique se suas permissões estão funcionando conforme o esperado testando suas funções no Secrets Manager.

Como testar a atualização e a exclusão de um segredo com e sem as tags necessárias

Faça login como um dos seguintes usuários do IAM:
- access-Arnav-peg-eng
- access-Mary-peg-qas
- access-Saanvi-uni-eng
- access-Carlos-uni-qas
- access-Nikhil-cen-eng
Alterne para a função correspondente:
- access-peg-engineering
- access-peg-quality-assurance
- access-uni-engineering
- access-peg-quality-assurance
- access-cen-engineering
Para obter mais informações sobre como alternar funções no AWS Management Console, consulte Alternância para uma função (console).

Para cada função, tente atualizar a descrição do segredo e tente excluir os segredos a seguir. Para obter mais informações, consulte Modificar um segredo e Excluir e restaurar um segredo no Guia do usuário do AWS Secrets Manager.

Atualização e exclusão de segredos de ABAC para cada função
Nome do perfil	Nome de segredo	Comportamento esperado
`access-peg-engineering`	`test-access-peg-eng`	Permitido
	`test-access-uni-eng`	Negado
	`test-access-uni-qas`	Negado
`access-peg-quality-assurance`	`test-access-peg-qas`	Permitido
`access-peg-quality-assurance`	`test-access-uni-eng`	Negado
`access-uni-engineering`	`test-access-uni-eng`	Permitido
`access-uni-engineering`	`test-access-uni-qas`	Negado
`access-peg-quality-assurance`	`test-access-uni-qas`	Permitido

Resumo

Agora você concluiu com êxito todas as etapas necessárias para usar tags para o controle de acesso baseado em atributo (ABAC). Você aprendeu a definir uma estratégia de marcação. Você aplicou essa estratégia aos seus principais e recursos. Você criou e aplicou uma política que impõe a estratégia para o Secrets Manager. Você também aprendeu que o ABAC é dimensionado facilmente ao adicionar novos projetos e membros da equipe. Como resultado, é possível fazer login no console do IAM com suas funções de teste e experimentar como usar etiquetas para ABAC na AWS.

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.

Recursos relacionados

Para obter informações relacionadas, consulte os recursos a seguir:

Para saber como monitorar as etiquetas em sua conta, consulte Monitorar alterações de etiquetas em recursos da AWS com fluxos de trabalho sem servidor e o Amazon CloudWatch Events.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Criar uma política gerenciada pelo cliente

Usar tags de sessão SAML para ABAC

Tutorial do IAM: Definir permissões para acessar recursos da AWS com base em etiquetas

nota

Tópicos

Visão geral do tutorial

Cenário

Resumo das principais decisões

Pré-requisitos

Etapa 1: Criar usuários de teste

Política de ABAC: assumir qualquer função de ABAC, mas somente quando as tags da função e do usuário forem correspondentes

Etapa 2: Criar a política de ABAC

Política de ABAC: acessar recursos do Secrets Manager somente quando as etiquetas de entidade e recurso forem correspondentes

Importante

Etapa 3: Criar funções

Etapa 4: Testar a criação de segredos

Como testar a criação de um segredo com e sem as tags necessárias

Importante

Etapa 5: Testar a visualização de segredos

Como testar a visualização de um segredo com e sem as tags necessárias

Etapa 6: Testar a escalabilidade

Como adicionar o novo projeto à AWS

Política de ABAC: assumir apenas funções específicas

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

Como testar a atualização e a exclusão de um segredo com e sem as tags necessárias

Resumo

nota

Recursos relacionados