# 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 as 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 [Definir permissões com base em atributos com autorização ABAC](introduction_attribute-based-access-control.md). **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. **Topics** + [ ## Visão geral do tutorial ](#tutorial_attribute-based-access-control-overview) + [ ## Pré-requisitos ](#tutorial_abac_prereqs) + [ ## Etapa 1: Criar usuários de teste ](#tutorial_abac_step1) + [ ## Etapa 2: Criar a política de ABAC ](#tutorial_abac_step2) + [ ## Etapa 3: Criar funções ](#tutorial_abac_step3) + [ ## Etapa 4: Testar a criação de segredos ](#tutorial_abac_step4) + [ ## Etapa 5: Testar a visualização de segredos ](#tutorial_abac_step5) + [ ## Etapa 6: Testar a escalabilidade ](#tutorial_abac_step6) + [ ## Etapa 7: Testar a atualização e a exclusão de segredos ](#tutorial_abac_step7) + [ ## Resumo ](#tutorial-abac-summary) + [ ## Recursos relacionados ](#tutorial_abac_related) + [ # Tutorial do IAM: Usar etiquetas de sessão SAML para ABAC ](tutorial_abac-saml.md) ## 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 [AWSServiços da que funcionam com o IAM](reference_aws-services-that-work-with-iam.md). 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](reference_policies_actions-resources-contextkeys.html). Você pode configurar seu provedor de identidade da Web ou com base em SAML para passar [tags de sessão](id_session-tags.md) 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](tutorial_abac-saml.md). 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](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) no *Guia do usuário do Gerenciamento de Faturamento e Custos da AWS*. **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 obter mais informações, consulte [Tutorial do IAM: Usar etiquetas de sessão SAML para ABAC](tutorial_abac-saml.md). + 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. ![\[O diagrama mostra dois projetos em que os perfis estão limitados a acesso somente de leitura fora do projeto, embora tenham permissões para criar, ler, atualizar e excluir recursos em seu próprio projeto.\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/tutorial-abac-cross-project.png) ## 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 Console de gerenciamento da AWS, selecione**Suporte** 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. ![\[Página do Suporte Center mostrando o número da conta.\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/account-id-support-center.console.png) + Experimente criar e editar usuários, funções e políticas do IAM no Console de gerenciamento da AWS. 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. 1. 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](access_policies_create-console.md#access_policies_create-start). **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. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TutorialAssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333: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 [Criar grupos do IAM](id_groups_create.md) e [Editar usuários em grupos do IAM](id_groups_manage_add-remove-users.md). 1. 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 Console de gerenciamento da AWS** e depois adicione as seguintes tags. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## 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](access_policies_create-console.md#access_policies_create-start). Para obter políticas adicionais que podem ser adaptadas para este tutorial, consulte as seguintes páginas: + [Controle de acesso de entidades de segurança do IAM](access_iam-tags.md#access_iam-tags_control-principals) + [Amazon EC2: permite iniciar ou interromper instâncias do EC2 que um usuário etiquetou, de forma programática e no console](reference_policies_examples_ec2_tag-owner.md) + [EC2: iniciar ou interromper instâncias baseadas em etiquetas de entidade de segurança e recurso correspondentes](reference_policies_examples_ec2-start-stop-match-tags.md) + [EC2: iniciar ou interromper instâncias baseadas em etiquetas](reference_policies_examples_ec2-start-stop-tags.md) + [IAM: assumir funções que têm uma etiqueta específica](reference_policies_examples_iam-assume-tagged-role.md) **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`. ------ #### [ JSON ] **** ``` { "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](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html). Essa página mostra que as ações executadas no [tipo de recurso **Secret (Segredo)**](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-resources-for-iam-policies) oferecem suporte à chave de condição `secretsmanager:ResourceTag/tag-key`. Algumas [ações do Secrets Manager](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-actions-as-permissions) 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 obter mais informações, consulte [Operadores de conjunto para chaves de contexto de vários valores](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys). + 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`](reference_policies_elements_condition_operators.md#Conditions_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 [Criar um perfil para conceder permissões a um usuário do IAM](id_roles_create_for-user.md). 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](tutorial_abac-saml.md). | 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** 1. 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/](https://console.aws.amazon.com/secretsmanager/). 1. 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 Console de gerenciamento da AWS, consulte [Mudar de um usuário para um perfil do IAM (console)](id_roles_use_switch-role-console.md) 1. Alterne para a função `access-peg-engineering`. 1. Armazene um novo segredo usando as seguintes informações. Para saber como armazenar um segredo, consulte [Criar um segredo básico](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) 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. 1. 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`. 1. Insira `test-access-peg-eng` no campo **Secret name (Nome do segredo)**. 1. Adicione diferentes combinações de tags da tabela a seguir e visualize o comportamento esperado. 1. 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. A tabela a seguir mostra as combinações de tags de ABAC para o perfil `test-access-peg-eng`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) 1. 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. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## 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** 1. 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` 1. 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 Console de gerenciamento da AWS, consulte [Mudar de um usuário para um perfil do IAM (console)](id_roles_use_switch-role-console.md). 1. No painel de navegação à esquerda, escolha o ícone do menu para expandir o menu e escolha **Secrets (Segredos)**. 1. 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. 1. Escolha o nome de um dos segredos. 1. 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. A tabela a seguir mostra o comportamento de visualização de segredo do ABAC para cada perfil. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) 1. 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** 1. Faça login como usuário administrador do IAM e abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. 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` 1. No painel de navegação à esquerda, escolha **Uses (Usuários)**. 1. 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` 1. Use os procedimentos em [Etapa 4: Testar a criação de segredos](#tutorial_abac_step4) e [Etapa 5: Testar a visualização de segredos](#tutorial_abac_step5). 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. 1. Na janela principal do navegador em que você fez login como administrador, escolha o usuário `access-Saanvi-uni-eng`. 1. Na guia **Permissions (Permissões)**, remova a política de permissões **access-assume-role**. 1. 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)](access_policies_manage-attach-detach.md#embed-inline-policy-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 obter mais informações, consulte [Regras para etiquetar no IAM e no AWS STS](id_tags.md#id_tags_rules). 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. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TutorialAssumeSpecificRoles", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::111122223333:role/access-peg-engineering", "arn:aws:iam::111122223333:role/access-cen-engineering" ] } ] } ``` ------ 1. Use os procedimentos em [Etapa 4: Testar a criação de segredos](#tutorial_abac_step4) e [Etapa 5: Testar a visualização de segredos](#tutorial_abac_step5). 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** 1. 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` 1. 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 Console de gerenciamento da AWS, consulte [Mudar de um usuário para um perfil do IAM (console)](id_roles_use_switch-role-console.md). 1. 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](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html) e [Excluir e restaurar um segredo](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html) no *Guia do usuário do AWS Secrets Manager*. A tabela a seguir mostra a atualização e exclusão de segredos de ABAC para cada perfil. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## 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 [Como a lógica do código de imposição da AWS avalia as solicitações para permitir ou negar acesso](reference_policies_evaluation-logic_policy-eval-denyallow.md). ## Recursos relacionados Para obter informações relacionadas, consulte os recursos a seguir: + [Definir permissões com base em atributos com autorização ABAC](introduction_attribute-based-access-control.md) + [AWSChaves de contexto de condições globais da](reference_policies_condition-keys.md) + [Criar um perfil para conceder permissões a um usuário do IAM](id_roles_create_for-user.md) + [Tags para recursos do AWS Identity and Access Management](id_tags.md) + [Controlar o acesso a recursos da AWS usando tags](access_tags.md) + [Mudar de um usuário para um perfil do IAM (console)](id_roles_use_switch-role-console.md) + [Tutorial do IAM: Usar etiquetas de sessão SAML para ABAC](tutorial_abac-saml.md) 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](https://aws.amazon.com/blogs/mt/monitor-tag-changes-on-aws-resources-with-serverless-workflows-and-amazon-cloudwatch-events/). # Tutorial do IAM: Usar etiquetas de sessão SAML para ABAC O controle de acesso por atributo (ABAC) é uma estratégia de autorização que define as 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](id_session-tags.md) 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 [Definir permissões com base em atributos com autorização ABAC](introduction_attribute-based-access-control.md). 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](tutorial_attribute-based-access-control.md) 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](tutorial_attribute-based-access-control.md), 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. + A capacidade de fazer login com um usuário que tenha permissões de administrador. + Experimente criar e editar usuários, funções e políticas do IAM no Console de gerenciamento da AWS. 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](id_session-tags.md#id_session-tags_adding-assume-role-saml). ## Etapa 1: Criar usuários de teste Siga as instruções em [Etapa 1: Criar usuários de teste](tutorial_attribute-based-access-control.md#tutorial_abac_step1). 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](tutorial_attribute-based-access-control.md#tutorial_abac_step2) 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 Console de gerenciamento da AWS. Para obter mais informações, consulte [Etapa 3: Criar funções](tutorial_attribute-based-access-control.md#tutorial_abac_step3). ### 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 um perfil para uma federação do SAML 2.0 (console)](id_roles_create_for-idp_saml.md). 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 [Atualizar a política de confiança de um perfil](id_roles_update-role-trust-policy.md). 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. ------ #### [ JSON ] **** ``` { "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 `cost-center` e `access-project`. 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 obter mais informações, consulte [Passar tags de sessão usando AssumeRoleWithSAML](id_session-tags.md#id_session-tags_adding-assume-role-saml). Para passar esses atributos como tags de sessão, inclua os seguintes elementos em sua declaração do SAML. ``` 987654 peg eng ``` ### Etapa 3C: habilitar o acesso ao console Habilite o acesso ao console para seus usuários federados do SAML. Para obter mais informações, consulte [Habilitar o acesso das entidades principais federadas do SAML 2.0 ao Console de gerenciamento da AWS](id_roles_providers_enable-console-saml.md). ## Etapa 4: Testar a criação de segredos Federe no Console de gerenciamento da AWS usando a função `access-session-tags`. Para obter mais informações, consulte [Habilitar o acesso das entidades principais federadas do SAML 2.0 ao Console de gerenciamento da AWS](id_roles_providers_enable-console-saml.md). Depois, siga as instruções [Etapa 4: Testar a criação de segredos](tutorial_attribute-based-access-control.md#tutorial_abac_step4) para criar segredos. Use identidades SAML diferentes com atributos para corresponder às tags indicadas no tutorial ABAC. Para obter mais informações, consulte [Etapa 4: Testar a criação de segredos](tutorial_attribute-based-access-control.md#tutorial_abac_step4). ## Etapa 5: Testar a visualização de segredos Siga as instruções em [Etapa 5: Testar a visualização de segredos](tutorial_attribute-based-access-control.md#tutorial_abac_step5) 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](tutorial_attribute-based-access-control.md#tutorial_abac_step6) 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](tutorial_attribute-based-access-control.md#tutorial_abac_step7) 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](https://aws.amazon.com/secrets-manager/pricing/). ## 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 [Como a lógica do código de imposição da AWS avalia as solicitações para permitir ou negar acesso](reference_policies_evaluation-logic_policy-eval-denyallow.md).