# Tutoriais do IAM
Os tutoriais a seguir apresentam procedimentos completos para tarefas comuns do AWS Identity and Access Management (IAM). Eles foram projetados para um ambiente de tipo de laboratório, com exemplos fictícios de nomes de empresas, nomes de usuários e assim por diante. O objetivo é fornecer orientação geral. Eles não se destinam ao uso direto em um ambiente de produção sem uma revisão e adaptação cuidadosas para atender às necessidades exclusivas do ambiente da organização.
**Topics**
+ [Delegar acesso entre Contas da AWS usando perfis](tutorial_cross-account-with-roles.md)
+ [Criar uma política gerenciada pelo cliente](tutorial_managed-policies.md)
+ [Usar controle de acesso baseado em atributos (ABAC)](tutorial_attribute-based-access-control.md)
+ [Permitir que os usuários gerenciem suas credenciais e configurações de MFA](tutorial_users-self-manage-mfa-and-creds.md)
+ [Criar o IdP do SAML com o CloudFormation](tutorial_saml-idp.md)
+ [Crie o perfil federado do SAML com o CloudFormation](tutorial_saml-federated-role.md)
+ [Criar o IdP do SAML e perfil federado com CloudFormation](tutorial_saml-idp-and-federated-role.md)
# Tutorial do IAM: Delegar acesso entre contas da AWS usando funções do IAM
**Importante**
As [práticas recomendadas](best-practices.md) do IAM aconselham exigir que os usuários humanos usem a federação com um provedor de identidades para acessar a AWS usando credenciais temporárias em vez de usuários do IAM com credenciais de longo prazo. Recomendamos usar somente usuários do IAM para [casos de uso específicos](gs-identities-iam-users.md) não compatíveis com usuários federados.
Este tutorial ensina a usar um perfil para delegar acesso a recursos em diferentes Contas da AWS, denominadas **Destino** e **Origem**. Você compartilha recursos em uma conta com usuários em outra conta. Ao configurar o acesso entre contas dessa forma, você não precisa criar usuários individuais do IAM em cada conta. Além disso, os usuários não precisam sair de uma conta e fazer login em outra conta para acessar recursos em diferentes Contas da AWS. Depois de configurar a função, você verá como usar a função do Console de gerenciamento da AWS, da AWS CLI e da API.
Neste tutorial, a conta **Destino** gerencia os dados de aplicações acessados por diferentes aplicações e equipes. Em cada conta, você armazena as informações da aplicação em buckets do Amazon S3. Você gerencia os usuários do IAM na conta **Origem**, em que tem dois perfis de usuário do IAM: **Desenvolvedores** e **Analistas**. Desenvolvedores e analistas usam a conta **Origem** para gerar dados compartilhados por vários microsserviços. Ambos os perfis têm permissões para trabalhar na conta Origem e acessar os recursos ali existentes. Periodicamente, um desenvolvedor deve atualizar os dados compartilhados na conta **Destino**. Os desenvolvedores armazenam esses dados em um bucket do Amazon S3 denominado `amzn-s3-demo-bucket-shared-container`.
Ao final deste tutorial, você terá o seguinte:
+ Usuários na conta **Origem** (a conta confiável) com permissão para assumir um determinado perfil na conta **Destino**.
+ Um perfil na conta **Destino** (a conta confiável) com permissão para acessar um determinado bucket do Amazon S3.
+ O bucket `amzn-s3-demo-bucket-shared-container` na conta **Destino**.
Os desenvolvedores podem usar o perfil no Console de gerenciamento da AWS para acessar o bucket `amzn-s3-demo-bucket-shared-container` na conta **Destino**. Eles também podem acessar o bucket usando chamadas de API autenticadas por credenciais temporárias fornecidas pelo perfil. As tentativas semelhantes de usar um perfil feitas por um analista falham.
Esse fluxo de trabalho tem três etapas básicas:
**[Para criar um perfil na conta Destino](#tutorial_cross-account-with-roles-1)**
Primeiro, você usa o Console de gerenciamento da AWS para estabelecer confiança entre a conta **Destino** (número de identificação 999999999999) e a conta **Origem** (número de identificação 111111111111). Você começa criando um perfil do IAM denominado *UpdateData*. Ao criar o perfil, você define a conta **Origem** como uma entidade confiável e especifica uma política de permissões que deixa os usuários confiáveis atualizarem o bucket `amzn-s3-demo-bucket-shared-container`.
**[Conceder acesso ao perfil](#tutorial_cross-account-with-roles-2)**
Nesta sessão, você modifica a política de perfil para negar aos analistas acesso ao perfil `UpdateData`. Porque os analistas têm acesso de PowerUser nesse cenário, e você deve *negar* explicitamente a capacidade de usar o perfil.
**[Teste o acesso alternando funções](#tutorial_cross-account-with-roles-3)**
Por fim, como desenvolvedor, você usa o perfil `UpdateData` para atualizar o bucket `amzn-s3-demo-bucket-shared-container` na conta **Destino**. Você verá como acessar a função por meio do console da AWS da AWS CLI e da API.
## Considerações
Antes de usar perfis do IAM para delegar acesso aos recursos nas Contas da AWS, é importante levar em conta o seguinte:
+ Você não pode alternar um perfil ao fazer login como Usuário raiz da conta da AWS.
+ As funções do IAM e as políticas baseadas em recurso delegam o acesso entre contas em uma única partição. Por exemplo, suponha que você tenha uma conta no Oeste dos EUA (Norte da Califórnia) na partição `aws` padrão. Além disso, você tem uma conta na China (Pequim) na partição `aws-cn`. Você não pode usar uma política baseada em recurso do Amazon S3 em sua conta na China (Pequim) para permitir o acesso de usuários em sua conta `aws` padrão.
+ Você pode usar o Centro de Identidade do AWS IAM para facilitar a autenticação única (SSO) de Contas da AWS externas (contas fora da sua AWS Organizations) usando Security Assertion Markup Language (SAML). Para obter detalhes, consulte [Integrate external Contas da AWS into Centro de Identidade do AWS IAM for central access management with independent billing using SAML 2.0](https://community.aws/content/2dIMI8N7w7tGxbE0KQMrkSBfae4/aws-iam-identity-center-integration-with-external-aws-accounts-for-independent-billing?lang=en)
+ Você pode associar perfis a recursos da AWS, como instâncias do Amazon EC2 ou funções do AWS Lambda. Para obter detalhes, consulte [Criar um perfil para delegar permissões a um serviço da AWS](id_roles_create_for-service.md).
+ Se você quiser que uma aplicação assuma um perfil em outra Conta da AWS, poderá usar o AWS SDK para assumir perfis entre contas. Para obter mais informações, consulte [Authentication and access](https://docs.aws.amazon.com//sdkref/latest/guide/access.html) no *AWS SDKs and Tools Reference Guide*.
+ Trocar de função usando o Console de gerenciamento da AWS só funciona com contas que não exijam um `ExternalId`. Por exemplo, vamos supor que você conceda acesso à sua conta a terceiros e exija um `ExternalId` em um elemento `Condition` em sua política de permissões. Nesse caso, o terceiro pode acessar sua conta somente usando a API da AWS ou uma ferramenta de linha de comando. O terceiro não pode usar o console, pois ele deve fornecer um valor para `ExternalId`. Para obter mais informações sobre esse cenário, consulte [Acesso às Contas da AWS de propriedade de terceiros](id_roles_common-scenarios_third-party.md) e [How to enable cross account access to the Console de gerenciamento da AWS](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) no AWS Security Blog.
## Pré-requisitos
Este tutorial pressupõe que você já tenha os seguintes itens configurados:
+ **Duas** Contas da AWS distintas que você pode usar, uma para representar a conta **Origem** e outra para representar a conta **Destino**.
+ Usuários e perfis na conta **Origem** criados e configurados da seguinte forma:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ Você não precisa criar nenhum usuário na conta **Destino**.
+ Um bucket do Amazon S3 criado na conta **Destino**. Você pode chamá-lo de `amzn-s3-demo-bucket-shared-container` neste tutorial, mas como os nomes dos buckets do S3 devem ser globalmente exclusivos, você deve usar um bucket com outro nome.
## Para criar um perfil na conta Destino
É possível permitir que os usuários de uma Conta da AWS acessem recursos em outra Conta da AWS. Neste tutorial, faremos isso criando um perfil que define quem pode acessá-lo e quais permissões são concedidas aos usuários que alternam para ele.
Nesta etapa do tutorial, você cria o perfil na conta **Destino** e especifica a conta **Origem** como uma entidade confiável. Você também limita as permissões da função a acesso somente leitura e gravação para o bucket `amzn-s3-demo-bucket-shared-container`. Qualquer pessoa com permissão para usar a função pode ler e gravar no bucket `shared-container`.
Antes de poder criar um perfil, você precisa do *ID de conta* da Conta da AWS **Origem**. Cada Conta da AWS tem um identificador ID de conta exclusivo e ela atribuído.
**Para obter o ID da Conta da AWS Origem**
1. Faça login no Console de gerenciamento da AWS como administrador da conta **Origem** e abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No console do IAM, escolha seu nome de usuário na barra de navegação no canto superior direito. Geralmente, ele é assim: ***username*@*account\$1ID\$1number\$1or\$1alias***.
Nesse cenário, você pode usar o ID de conta 111111111111 para a conta **Origem**. No entanto, é necessário usar um ID de conta válido se você usar este cenário em seu ambiente de teste.
**Para criar um perfil na conta Destino que possa ser usado pela conta Origem**
1. Entre no Console de gerenciamento da AWS como administrador da conta **Destino** e abra o console do IAM.
1. Para criar a função, prepare a política gerenciada que define as permissões para os requisitos da função. Em uma etapa posterior, você anexará essa política à função.
Você deseja definir o acesso de leitura e gravação ao bucket `amzn-s3-demo-bucket-shared-container`. Embora a AWS forneça algumas políticas gerenciadas do Amazon S3, não há uma que conceda acesso de leitura e gravação a um único bucket do Amazon S3. Você pode criar a sua própria política.
No painel de navegação, escolha **Policies (Políticas)** e, em seguida, selecione **Create policy (Criar política)**.
1. Escolha a guia **JSON** e copie o texto do documento de política JSON a seguir. Cole este texto na caixa de texto **JSON**, substituindo o ARN do recurso (`arn:aws:s3:::shared-container`) pelo verdadeiro ARN para o seu bucket do Amazon S3.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container/*"
}
]
}
```
------
A ação `ListAllMyBuckets` concede permissão para listar todos os buckets de propriedade do remetente autenticado da solicitação. A permissão `ListBucket` concede aos usuários a habilidade de visualizar objetos no bucket `amzn-s3-demo-bucket-shared-container`. As permissões `GetObject`, `PutObject`, `DeleteObject` concedem aos usuários a capacidade de visualizar, atualizar e excluir o conteúdo no bucket `amzn-s3-demo-bucket-shared-container`.
**nota**
É possível alternar entre as opções de editor **Visual** e **JSON** a qualquer momento. Porém, se você fizer alterações ou escolher **Avançar** no editor **Visual**, o IAM poderá reestruturar a política a fim de otimizá-la para o editor visual. Para obter mais informações, consulte [Reestruturação da política](troubleshoot_policies.md#troubleshoot_viseditor-restructure).
1. Na página **Revisar e criar**, digite **read-write-app-bucket** para o nome da política. Revise as permissões concedidas pela política e depois escolha **Criar política** para salvar seu trabalho.
As novas políticas aparecem na lista de políticas gerenciadas.
1. No painel de navegação, escolha **Funções** e **Criar função**.
1. Selecione o tipo de perfil **Uma Conta da AWS**.
1. Em **ID da conta**, digite a ID da conta **Origem**.
Este tutorial usa o ID da conta de exemplo **111111111111** para a conta **Origem**. Você deve usar um ID de conta válido. Se você usar um ID de conta inválido, como **111111111111**, o IAM não permitirá que você crie a nova função.
Por enquanto, não é necessário exigir um ID externo ou exigir que os usuários tenham autenticação multifator (MFA) para assumirem a função. Deixe essas opções desmarcadas. Para obter mais informações, consulte [Código da autenticação multifator no IAM da AWS](id_credentials_mfa.md).
1. Selecione **Next: Permissions** (Próximo: permissões) para definir as permissões associadas à função.
1. Marque a caixa de seleção ao lado da política que você criou anteriormente.
**Dica**
Em **Filter** (Filtrar), selecione **Customer managed** (Gerenciado pelo cliente) para filtrar a lista, de modo que ela inclua apenas as políticas criadas por você. Isso oculta as políticas criadas pela AWS e torna muito mais fácil encontrar a que você necessita.
Em seguida, escolha **Próximo**.
1. (Opcional) Adicione metadados à função anexando etiquetas como pares de chave-valor. Para obter mais informações sobre como usar tags no IAM, consulte [Tags para recursos do AWS Identity and Access Management](id_tags.md).
1. (Opcional) Em **Descrição da função**, insira uma descrição para a nova função.
1. Depois de revisar a função, escolha **Criar função**.
A função `UpdateData` é exibida na lista de funções.
Agora você deve obter o nome do recurso da Amazon (ARN) da função, que é um identificador exclusivo para a função. Ao modificar o perfil de desenvolvedor na conta Origem, você especifica o ARN do perfil da conta Destino para conceder ou negar as permissões.
**Para obter o ARN para UpdateData**
1. No painel de navegação do console do IAM, escolha **Perfis**.
1. Na lista de funções, escolha `UpdateData`.
1. Na seção **Resumo** do painel de detalhes, copie o valor de **ARN da função**.
A conta Destino tem o ID de conta 999999999999, portanto, o ARN do perfil é `arn:aws:iam::999999999999:role/UpdateData`. Certifique-se de fornecer o ID da Conta da AWS verdadeiro para a conta Destino.
Neste ponto, você estabeleceu confiança entre as contas **Destino** e **Origem**. Você fez isso criando um perfil na conta **Destino** que identifica a conta **Origem** como uma entidade principal confiável. Você também definiu o que os usuários que passarem para a função `UpdateData` podem fazer.
Em seguida, modifique as permissões para o perfil Desenvolvedor.
## Conceder acesso ao perfil
Nesse momento, os analistas e os desenvolvedores têm permissões para gerenciar os dados na conta **Origem**. Use as seguintes etapas necessárias para adicionar permissões a fim de permitir alternar para a função.
**Para modificar o perfil Desenvolvedores para permitir que eles alternem para o perfil UpdateData**
1. Entre como administrador na conta **Origem** e abra o console do IAM.
1. Escolha **Perfis** e depois **Desenvolvedores**.
1. Escolha a guia **Permissions** (Permissões), **Add permissions** (Adicionar permissões) e **Create inline policy** (Criar política em linha).
1. Selecione a guia **JSON**.
1. Adicione a seguinte instrução de política para permitir a ação `AssumeRole` no perfil `UpdateData` na conta Destino. Certifique-se de alterar *DESTINATION-ACCOUNT-ID* no elemento `Resource` para o ID da Conta da AWS real da conta Destino.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/UpdateData"
}
}
```
------
O efeito `Allow` permite explicitamente que o grupo Desenvolvedores acesse o perfil `UpdateData` na conta Destino. Qualquer desenvolvedor que tente acessar a função é bem-sucedido.
1. Selecione **Revisar política**.
1. Digite um **Nome**, como, por exemplo, **allow-assume-S3-role-in-destination**.
1. Escolha **Criar política**.
Na maioria dos ambientes, talvez o procedimento a seguir não seja necessário. Se, no entanto, você usar permissões PowerUserAccess, alguns grupos já poderão alternar funções. O procedimento a seguir mostra como adicionar uma permissão `"Deny"` ao grupo Analistas para garantir que eles não possam assumir o perfil. Se esse procedimento não for necessário em seu ambiente, recomendamos que não o adicione. As permissões `"Deny"` fazem com que seja mais complicado de gerenciar e entender o estado geral das permissões. Use as permissões `"Deny"` somente quando não existir uma opção melhor.
**Para modificar o perfil Analistas para negar permissão de assumir o perfil `UpdateData`**
1. Escolha **Perfis** e depois **Analistas**.
1. Escolha a guia **Permissions** (Permissões), **Add permissions** (Adicionar permissões) e **Create inline policy** (Criar política em linha).
1. Selecione a guia **JSON**.
1. Adicione a instrução de política a seguir para negar a ação `AssumeRole` na função `UpdateData`. Certifique-se de alterar *DESTINATION-ACCOUNT-ID* no elemento `Resource` para o ID da Conta da AWS real da conta Destino.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/UpdateData"
}
}
```
------
O efeito `Deny` nega explicitamente ao grupo Analistas acesso ao perfil `UpdateData` na conta Destino. Qualquer analista que tente acessar o perfil receberá uma mensagem de acesso negado.
1. Selecione **Revisar política**.
1. Digite um **nome**, como **deny-assume-S3-role-in-destination**.
1. Escolha **Criar política**.
O perfil Desenvolvedores agora tem permissões para usar o perfil `UpdateData` na conta Destino. O perfil Analistas é impedido de usar o perfil `UpdateData`.
Em seguida, você verá como David, um desenvolvedor, pode acessar o bucket `amzn-s3-demo-bucket-shared-container` na conta Destino. David pode acessar o bucket no Console de gerenciamento da AWS, na AWS CLI ou na API do AWS.
## Teste o acesso alternando funções
Após concluir as duas primeiras etapas deste tutorial, você terá um perfil que concede acesso a um recurso na conta **Destino**. Você também terá um perfil na conta **Origem** com usuários que têm permissão para usar esse perfil. Esta etapa discute como testar a alternância para essa função no Console de gerenciamento da AWS, na AWS CLI e na API da AWS.
Para obter ajuda com os problemas comuns que você pode encontrar ao trabalhar com perfis do IAM, consulte [Solucionar problemas de perfis do IAM](troubleshoot_roles.md).
### Alternar funções (console)
Se David precisar atualizar os dados na conta **Destino** no Console de gerenciamento da AWS, ele poderá fazer isso usando **Switch Role**. Ele especifica o ID da conta ou o alias e o nome da função, e suas permissões mudam imediatamente para as permitidas pela função. Depois, ele poderá usar o console para trabalhar com o bucket `amzn-s3-demo-bucket-shared-container`, mas não poderá trabalhar com nenhum outro recurso em **Destino**. Enquanto David usar o perfil, não poderá usar também seus privilégios de usuário avançado na conta **Origem**. Isso porque apenas um conjunto de permissões pode ser ativado por vez.
O IAM oferece duas maneiras para David acessar a página **Switch Role** (Alternar função):
+ David recebe um link do administrador que aponta para uma configuração predefinida Switch Role (Trocar de função). O link é fornecido ao administrador na última página do assistente **Criar função** ou na página **Resumo da função** de uma função entre contas. Ao selecionar esse link, David acessa a página **Alternar função** com os campos **ID da conta** e **Nome da função** já preenchidos. Tudo o que David precisa fazer é escolher **Trocar perfis**.
+ O administrador não envia o link no e-mail, mas, em vez disso, envia os valores do número de **ID da conta** e do **Nome da função**. David deve inserir manualmente os valores para tocar de função. Isso é ilustrado no procedimento a seguir.
**Para assumir uma função**
1. David inicia sessão no Console de gerenciamento da AWS usando seu usuário normal na conta **Origem**.
1. Ele escolhe o link que o administrador enviou por e-mail para ele. Esse link leva David à página **Switch Role** (Trocar de função) com as informações de ID ou alias da conta e nome da função já preenchidas.
—ou—
David escolhe os nomes (menu Identity [Identidade]) na barra de navegação e, depois, escolhe **Switch Roles** (Trocar de função).
Se essa for a primeira vez que David tenta acessar a página Alternar função dessa forma, primeiramente ele entrará na página **Switch Role** (Alternar função) de primeiro acesso. Essa página fornece informações adicionais sobre como a alternância de perfis pode permitir aos usuários gerenciar os recursos entre Contas da AWS. David deve selecionar **Switch Role** (Alternar função) nessa página para concluir o restante do procedimento.
1. Em seguida, para acessar o perfil, David deve digitar manualmente o número do ID da conta Destino (`999999999999`) e o nome do perfil (`UpdateData`).
Além disso, David deseja monitorar quais funções e permissões associadas estão ativas no IAM no momento. Para controlar essas informações, ele digita `Destination` na caixa de texto **Display Name** (Nome de exibição), escolhe a opção na cor vermelha e escolhe **Switch Role** (Alternar função).
1. David agora pode usar o console do Amazon S3 para trabalhar com o bucket do Amazon S3 ou qualquer outro recurso ao qual a função `UpdateData` tenha permissões.
1. Quando concluído, David poderá voltar para as permissões originais. Para isso, ele escolhe o nome de exibição do perfil **Destino** na barra de navegação e depois escolhe **Voltar para David em 111111111111**.
1. Da próxima vez que David desejar alternar perfis e escolher o menu **Identidade** na barra de navegação, ele verá a entrada Destino no mesmo local em que estava da última vez. Ele pode simplesmente escolher essa entrada para alternar funções imediatamente sem inserir novamente o ID da conta e o nome da função.
### Alternar funções (AWS CLI)
Se David precisar trabalhar no ambiente **Destino** na linha de comando, poderá fazer isso usando a [AWS CLI](https://aws.amazon.com/cli/). Ele executa o comando `aws sts assume-role` e transmite o nome de recurso da Amazon (ARN) para obter credenciais de segurança temporárias para essa função. Em seguida, ele configura essas credenciais em variáveis do ambiente para que os comandos da AWS CLI funcionem usando as permissões da função. Enquanto David estiver usando o perfil, não poderá usar também seus privilégios de usuário avançado na conta **Origem**, pois apenas um conjunto de permissões pode estar ativo de cada vez.
Todas as chaves de acesso e tokens são apenas exemplos e não podem ser usados da forma que são mostrados. Substitua pelos valores apropriados do seu ambiente real.
**Para assumir uma função**
1. David abre uma janela de prompt de comando e confirma que o cliente de AWS CLI está funcionando executando o comando:
```
aws help
```
**nota**
O ambiente padrão de David usa as credenciais do usuário `David` do seu perfil padrão que ele criou com o comando `aws configure`. Para obter mais informações, consulte [Configuração da AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration) no *Guia do usuário da AWS Command Line Interface*.
1. Ele inicia o processo de alternar perfis executando o comando a seguir para alternar para o perfil `UpdateData` na conta **Destino**. Ele recebeu o ARN de função do administrador que criou a função. O comando também exige que você forneça um nome de sessão, você pode escolher qualquer texto que desejar para isso.
```
aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateData" --role-session-name "David-ProdUpdate"
```
Em seguida, David vê a seguinte na saída:
```
{
"Credentials": {
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"SessionToken": "AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLE
CvSRyh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDy
EXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3Uuysg
sKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87e
NhyDHq6ikBQ==",
"Expiration": "2014-12-11T23:08:07Z",
"AccessKeyId": "AKIAIOSFODNN7EXAMPLE"
}
}
```
1. David vê três elementos de que precisa na seção Credentials Credenciais) da saída.
+ `AccessKeyId`
+ `SecretAccessKey`
+ `SessionToken`
David precisa configurar o ambiente de AWS CLI para usar esses parâmetros nas chamadas subsequentes. Para obter informações sobre as várias maneiras de configurar suas credenciais, consulte [Configuração da AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence). Você não pode usar o comando `aws configure` porque ele não dá suporte à captura do token de sessão. Porém, você pode inserir manualmente as informações em um arquivo de configuração. Como essas são credenciais temporárias com um tempo de expiração relativamente curto, é mais fácil adicioná-las ao ambiente de sua sessão de linha de comando atual.
1. Para adicionar os três valores ao ambiente, David recorta e cola a saída da etapa anterior nos seguintes comandos. Talvez você queira recortar e colar em um editor de texto simples para resolver problemas de quebra de linha na saída do token de sessão. Ela deve ser adicionada como uma string longa simples, apesar de a linha ser mostrada quebrada aqui para fins de clareza.
O exemplo a seguir mostra os comandos fornecidos no ambiente Windows, onde "set" é o comando para criar uma variável de ambiente. Nos computadores Linux ou macOS, o comando é "exportar". Todas as outras partes do exemplo são válidas em todos os três ambientes.
Para obter detalhes sobre como usar as ferramentas para Windows Powershell, consulte [Alternar para um perfil do IAM (Ferramentas para Windows PowerShell)](id_roles_use_switch-role-twp.md)
```
set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
set AWS_SESSION_TOKEN=AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvS
Ryh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXA
MPLEKEY9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UusKd
EXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLENhykxiHen
DHq6ikBQ==
```
Nesse ponto, todos os comandos a seguir são executados de acordo com as permissões de função identificadas por essas credenciais. No caso de David, a função `UpdateData`.
**Importante**
Você pode salvar as definições de configuração usadas com frequência e credenciais em arquivos que são mantidos pela AWS CLI. Para obter mais informações, consulte [Using existing configuration and credentials files](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-existing) no *AWS Command Line Interface User Guide*.
1. Execute o comando para acessar os recursos na conta Destino. Neste exemplo, David lista o conteúdo do bucket do S3 com o comando a seguir.
```
aws s3 ls s3://shared-container
```
Como nomes de bucket do Amazon S3 são universalmente exclusivos, não há necessidade de especificar o ID da conta que tem o bucket. Para acessar recursos de outros serviços da AWS, consulte a documentação da AWS CLI desse serviço para obter os comandos e a sintaxe necessários para referenciar seus recursos.
### Uso da AssumeRole (API da AWS)
Quando David precisa fazer uma atualização na conta **Destino** no código, ele faz uma chamada `AssumeRole` para assumir o perfil `UpdateData`. A chamada retorna credenciais temporárias que ele pode usar para acessar o bucket `amzn-s3-demo-bucket-shared-container` na conta **Destino**. Com essas credenciais, David pode fazer chamadas de API para atualizar o bucket `amzn-s3-demo-bucket-shared-container`. Porém, ele não pode fazer chamadas de API para acessar nenhum outro recurso na conta **Destino**, mesmo tendo permissões de usuário avançado na conta **Origem**.
**Para assumir uma função**
1. David chama `AssumeRole` como parte de um aplicativo. Ele deve especificar o ARN `UpdateData`: `arn:aws:iam::999999999999:role/UpdateData`.
A resposta da chamada `AssumeRole` inclui as credenciais temporárias com um `AccessKeyId` e um `SecretAccessKey`. Também inclui um horário de `Expiration` que indica quando as credenciais expiram, e é necessário solicitar novas. Quando você configura o encadeamento de perfis com o AWS SDK, muitos provedores de credenciais atualizam automaticamente as credenciais antes que expirem.
1. Com as credenciais temporárias, David faz uma chamada `s3:PutObject` para atualizar o bucket `amzn-s3-demo-bucket-shared-container`. Ele pode passar as credenciais para a chamada de API como o parâmetro `AuthParams`. Como as credenciais temporárias do perfil têm apenas acesso de leitura e gravação ao bucket `amzn-s3-demo-bucket-shared-container`, todas as outras ações na conta Destino são negadas.
Para obter um exemplo de código (usando Python), consulte [Alternar para um perfil do IAM (API da AWS)](id_roles_use_switch-role-api.md).
## Recursos adicionais
Os seguintes recursos podem ajudar você a saber mais sobre os tópicos deste tutorial:
+ Para obter mais informações sobre os usuários do IAM, consulte [Identidades do IAM](id.md).
+ Para mais informações sobre os buckets do Amazon S3, consulte [Criar um bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) no *Guia do usuário do Amazon Simple Storage Service*.
+ Para saber se as entidades de contas fora de sua zona de confiança (organização confiável ou conta) têm acesso para assumir as suas funções, consulte [O que é o IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html).
## Resumo
Você concluiu o tutorial de acesso à API entre contas. Você criou uma função para estabelecer confiança com outra conta e definiu quais ações as entidades confiáveis podem executar. Depois, você modificou uma política de perfil para controlar quais usuários do IAM; podem acessar o perfil. Como resultado, da conta **Origem** os desenvolvedores podem fazer atualizações no bucket `amzn-s3-demo-bucket-shared-container` na conta **Destino** usando credenciais temporárias.
# Tutorial do IAM: Criar e anexar sua primeira política gerenciada pelo cliente
Neste tutorial, você usará o Console de gerenciamento da AWS para criar uma [política gerenciada pelo cliente](access_policies_managed-vs-inline.md#customer-managed-policies) e anexará essa política a um usuário do IAM na sua Conta da AWS. A política que você cria permite que um usuário de teste do IAM faça login diretamente no Console de gerenciamento da AWS com permissões somente leitura.
Esse fluxo de trabalho tem três etapas básicas:
**[Etapa 1: Criar a política](#step1-create-policy)**
Por padrão, os usuários do IAM não têm permissões para fazer nada. Eles não podem acessar o Console de Gerenciamento da AWS ou gerenciar os dados, a menos que você permita. Nesta etapa, você cria uma política gerenciada pelo cliente que permite a qualquer usuário anexado fazer login no console.
**[Etapa 2: Anexar a política](#step2-attach-policy)**
Quando você anexa uma política a um usuário, ele herda todas as permissões de acesso associadas a essa política. Nesta etapa, você anexa a nova política a um usuário de teste.
**[Etapa 3: Testar o acesso do usuário](#step3-test-access)**
Assim que a política é anexada, você pode fazer login como o usuário e testá-la.
## Pré-requisitos
Para executar as etapas neste tutorial, você precisa já ter o seguinte:
+ Uma Conta da AWS com a qual você possa fazer login como usuário do IAM com permissões administrativas.
+ Um usuário de teste do IAM que não tenha permissões atribuídas ou associações de grupo da seguinte forma:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/tutorial_managed-policies.html)
## Etapa 1: Criar a política
Nesta etapa, você cria uma política gerenciada pelo cliente que permita a qualquer usuário anexado fazer login no Console de gerenciamento da AWS com acesso somente leitura aos dados do IAM.
**Para criar a política para o usuário de teste**
1. Faça login no console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) com seu usuário que tenha permissões de administrador.
1. No painel de navegação, selecione **Políticas**.
1. No painel de conteúdo, escolha **Criar política**.
1. Escolha a opção **JSON** e copie o texto do documento da política JSON a seguir. Cole este texto na caixa de texto do **JSON**.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [ {
"Effect": "Allow",
"Action": [
"iam:GenerateCredentialReport",
"iam:Get*",
"iam:List*"
],
"Resource": "*"
} ]
}
```
------
1. Resolva os avisos de segurança, erros ou avisos gerais gerados durante a [validação de política](access_policies_policy-validator.md) e depois escolha **Próximo**.
**nota**
Você pode alternar entre as opções de editor **Visual** e **JSON** a qualquer momento. No entanto, se você fizer alterações ou escolher a opção **Review policy** (Revisar política) na guia **Visual editor** (Editor visual), o IAM poderá reestruturar sua política de forma a otimizá-la para o editor visual. Para obter mais informações, consulte [Reestruturação da política](troubleshoot_policies.md#troubleshoot_viseditor-restructure).
1. Na página **Revisar e criar**, digite **UsersReadOnlyAccessToIAMConsole** para o nome da política. Revise as permissões concedidas pela política e depois escolha **Criar política** para salvar seu trabalho.
A nova política aparece na lista de políticas gerenciadas e está pronta para ser anexada.
## Etapa 2: Anexar a política
Em seguida, anexe a política que você acabou de criar ao usuário de teste do IAM.
**Para anexar a política ao usuário de teste**
1. No console do IAM, no painel de navegação, escolha **Policies** (Políticas).
1. Na parte superior da lista de políticas, na caixa de pesquisa, comece a digitar **UsersReadOnlyAccesstoIAMConsole** até ver a política. Depois, escolha o botão de seleção ao lado de **UsersReadOnlyAccessToIAMConsole** na lista.
1. Selecione o botão **Actions** (Ações) e escolha **Attach** (Anexar).
1. Nas entidades do IAM, escolha a opção de filtrar por **Usuários**.
1. Na caixa de pesquisa, comece a digitar **PolicyUser** até que o usuário fique visível na lista. Depois, marque a caixa de seleção ao lado desse usuário na lista.
1. Escolha **Anexar política**.
Você anexou a política ao usuário de teste do IAM, o que significa que o usuário agora tem acesso somente leitura ao console do IAM.
## Etapa 3: Testar o acesso do usuário
Para este tutorial, recomendamos que você teste o acesso, fazendo login como o usuário de teste para ver o que os usuários podem experimentar.
**Para testar o acesso fazendo login com seu usuário de teste**
1. Faça login no console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) com o seu usuário de teste `PolicyUser`.
1. Navegue pelas páginas do console e tente criar um novo usuário ou grupo. Observe que `PolicyUser` pode exibir dados, mas não pode criar ou modificar dados existentes do IAM.
## Recursos relacionados
Para obter informações relacionadas, consulte os recursos a seguir:
+ [Políticas gerenciadas e em linha](access_policies_managed-vs-inline.md)
+ [Controlar o acesso do usuário do IAM ao Console de gerenciamento da AWS](console_controlling-access.md)
## Resumo
Você concluiu com êxito todas as etapas necessárias para criar e anexar uma política gerenciada pelo cliente. Como resultado, você pode fazer login no console do IAM com sua conta de teste para ver como é a experiência para os usuários.
# 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).
# Tutorial do IAM: Permitir que os usuários gerenciem suas credenciais e configurações de MFA
Você pode permitir que os usuários gerenciem seus próprios dispositivos e credenciais de autenticação multifator (MFA) na página **Credenciais de segurança**. É possível usar o Console de gerenciamento da AWS para configurar credenciais (chaves de acesso, senhas, certificados de assinatura e chaves públicas de SSH), excluir ou desativar credenciais que não sejam mais necessárias e habilitar dispositivos MFA para seus usuários. Isso é útil para um pequeno número de usuários, mas essa tarefa que pode rapidamente se tornar demorada conforme o número de usuários aumenta. Este tutorial mostra como habilitar essas melhores práticas sem sobrecarregar seus administradores.
Este tutorial mostra como permitir que usuários acessem os serviços da AWS, mas **apenas** quando fazem login com MFA. Se o login desse usuários não for feito com um dispositivo MFA, eles não poderão acessar outros serviços.
Esse fluxo de trabalho tem três etapas básicas.
**[Etapa 1: Criar uma política para impor o login com MFA](#tutorial_mfa_step1)**
Crie uma política gerenciada pelo cliente que proíba todas as ações, ***exceto*** as poucas ações do IAM. Essas exceções permitem que um usuário altere suas próprias credenciais e gerencie seus dispositivos de MFA na página **Credenciais de segurança**. Para obter mais informações sobre como acessar essa página, consulte [Como os usuários do IAM alteram a própria senha (console)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console).
**[Etapa 2: Anexar políticas ao grupo de usuários de teste](#tutorial_mfa_step2)**
Crie um grupo de usuários cujos membros tenham acesso total a todas as ações do Amazon EC2 se eles fizerem login com MFA. Para criar esse grupo de usuários, anexe a política gerenciada pela AWS chamada `AmazonEC2FullAccess` e a política gerenciada pelo cliente que você criou na primeira etapa.
**[Etapa 3: Testar o acesso do usuário](#tutorial_mfa_step3)**
Faça login como o usuário de teste para verificar se o acesso ao Amazon EC2 está bloqueado *até* que o usuário crie um dispositivo com MFA. Depois, o usuário pode fazer login usando esse dispositivo.
## 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 do IAM com permissões administrativas.
+ O número do ID da conta que você digitará na política na Etapa 1.
Para localizar o número de ID de sua conta, na barra de navegação na parte superior da página, escolha **Suporte** e, em seguida, escolha **Central de suporte**. Você pode localizar o ID da conta no menu **Suporte** dessa página.
+ Um [dispositivo de MFA virtual (baseado em software)](id_credentials_mfa_enable_virtual.md), [chave de segurança FIDO](id_credentials_mfa_enable_fido.md) ou [dispositivo de MFA baseado em hardware](id_credentials_mfa_enable_physical.md).
+ Um usuário de teste do IAM que é membro de um grupo de usuários da seguinte forma:
| Nome de usuário | Instruções sobre nome de usuário | Nome do grupo de usuários | Adicionar usuário como membro | Instruções sobre grupo de usuários |
| --- | --- | --- | --- | --- |
| MFAUser | Escolha apenas a opção para Habilitar acesso ao console: opcional e atribua uma senha. | EC2MFA | MFAUser | NÃO anexe quaisquer políticas nem conceda permissões para este grupo de usuários. |
## Etapa 1: Criar uma política para impor o login com MFA
Comece com a criação de uma política gerenciada pelo cliente do IAM que negue todas as permissões, exceto as necessárias para os usuários do IAM gerenciarem suas próprias credenciais e dispositivos com MFA.
1. Faça login no Console de Gerenciamento da AWS como um usuário com credenciais de administrador. Para seguir as melhores práticas do IAM não faça login com as suas credenciais de Usuário raiz da conta da AWS.
**Importante**
As [práticas recomendadas](best-practices.md) do IAM aconselham exigir que os usuários humanos usem a federação com um provedor de identidades para acessar a AWS usando credenciais temporárias em vez de usuários do IAM com credenciais de longo prazo. Recomendamos usar somente usuários do IAM para [casos de uso específicos](gs-identities-iam-users.md) não compatíveis com usuários federados.
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação, escolha **Políticas** e, em seguida, **Criar política**.
1. Selecione a guia **JSON** copie o texto do documento de política JSON a seguir: [AWS: permite que os usuários do IAM autenticados por MFA gerenciem suas próprias credenciais na página Credenciais de segurança](reference_policies_examples_aws_my-sec-creds-self-manage.md).
1. Cole o texto da política na caixa de texto **JSON**. Resolva os avisos de segurança, erros ou avisos gerais gerados durante a validação da política e depois escolha **Avançar**.
**nota**
Você pode alternar entre as opções de editor **Visual** e **JSON** a qualquer momento. No entanto, a política acima inclui o elemento `NotAction`, que não é compatível com o editor visual. Para esta política, você verá uma notificação na guia **Editor visual**. Volte para a guia **JSON** para continuar a trabalhar com essa política.
Este exemplo de polítia não permite que os usuários redefinam uma senha quando fazem login no Console de gerenciamento da AWS pela primeira vez. Recomendamos que você não conceda permissões a novos usuários até que eles façam login e redefinam suas senhas.
1. Na página **Revisar e criar**, digite **Force\$1MFA** para o nome da política. Para a descrição da política, digite **This policy allows users to manage their own passwords and MFA devices but nothing else unless they authenticate with MFA.** Na área **Tags**, você tem a opção de adicionar pares de chave-valor de tag à política gerenciada pelo cliente. Revise as permissões concedidas pela política e depois escolha **Criar política** para salvar seu trabalho.
A nova política aparece na lista de políticas gerenciadas e está pronta para ser anexada.
## Etapa 2: Anexar políticas ao grupo de usuários de teste
Em seguida, anexe duas políticas ao grupo de usuários de teste do IAM, que serão usadas para conceder as permissões protegidas por MFA.
1. No painel de navegação, selecione **User groups** (Grupos de usuários).
1. Na caixa de pesquisa, digite **`EC2MFA`** e, em seguida, escolha o nome do grupo (não a caixa de seleção) na lista.
1. Escolha a guia **Permissões**, escolha **Adicionar permissões** e depois **Anexar políticas**.
1. Na página **Attach permission policies to EC2MFA group** (Anexar políticas de permissão ao grupo EC2MFA), na caixa de pesquisa, digite **EC2Full**. Depois, marque a caixa de seleção ao lado de **AmazonEC2FullAccess** na lista. Não salve ainda as alterações.
1. Na caixa de pesquisa, digite **Force** e, em seguida, marque a caixa de seleção ao lado de **Force\$1MFA** na lista.
1. Escolha **Anexar políticas**.
## Etapa 3: Testar o acesso do usuário
Nesta parte do tutorial, você faz login como o usuário de teste e verifica se a política funciona conforme o esperado.
1. Faça login na sua Conta da AWS como **MFAUser** com a senha atribuída na seção anterior. Use o URL: `https://.signin.aws.amazon.com/console`
1. Escolha **EC2** para abrir o console do Amazon EC2 e confirme se o usuário não tem permissões para fazer nada.
1. Na barra de navegação no canto superior direito, selecione o nome de usuário `MFAUser` e selecione **Security Credentials** (Credenciais de segurança).
![\[Link para as credenciais de segurança do Console de Gerenciamento da AWS.\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)
1. Agora adicione um dispositivo MFA. Na seção **Multi-Factor Authentication (MFA)**, selecione **Assign MFA device (Atribuir dispositivo MFA)**.
**nota**
É possível que você receba um erro informando que você não está autorizado a executar `iam:DeleteVirtualMFADevice`. Isso pode acontecer se alguém tiver começado a atribuir um dispositivo MFA virtual a esse usuário anteriormente e tiver cancelado o processo. Para continuar, você ou outro administrador deve excluir o dispositivo de MFA virtual existente e não atribuído do usuário. Para obter mais informações, consulte [Não estou autorizado a executar: iam:DeleteVirtualMFADevice](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa).
1. Para este tutorial, usamos um dispositivo MFA virtual (em software), como o aplicativo Google Authenticator em um celular. Escolha a **Authenticator app** (Aplicação de autenticador) e clique em **Next** (Avançar).
O IAM gera e exibe informações de configuração para o dispositivo com MFA virtual, incluindo um código QR gráfico. O gráfico é uma representação da chave de configuração secreta que está disponível para entrada manual em dispositivos que não suportam códigos de QR.
1. Abra o seu aplicativo de MFA virtual. (Para obter uma lista de aplicativos que você pode usar para hospedar dispositivos MFA virtuais, consulte [Aplicativos de MFA virtual](https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications).) Se o aplicativo de MFA virtual oferecer suporte a várias contas (vários dispositivos MFA virtuais), selecione a opção para criar uma nova conta (um novo dispositivo MFA virtual).
1. Determine se o aplicativo de MFA é compatível com códigos QR e, em seguida, execute uma das seguintes ações:
+ No assistente, escolha **Mostrar código QR**. Em seguida, use o aplicativo para digitalizar o código QR. Por exemplo, você pode escolher o ícone de câmera ou escolher uma opção semelhante a **Digitalizar código** e, em seguida, usar a câmera do dispositivo para digitalizar o código.
+ No assistente **Set up device** (Configurar dispositivo), selecione **Show secret key** (Exibir chave secreta) e digite a chave secreta em sua aplicação de MFA.
Quando você tiver concluído, o dispositivo MFA virtual inicia a geração de senhas de uso único.
1. No assistente **Set up device** (Configurar dispositivo), na caixa **Enter the code from your authenticator app.** (Insira o código da aplicação de autenticador.), digite a senha de uso único que atualmente é exibida no dispositivo de MFA virtual. Escolha **Register MFA** (Registrar MFA).
**Importante**
Envie sua solicitação imediatamente após gerar o código. Se você gerar os códigos e esperar muito tempo para enviar a solicitação, o dispositivo MFA conseguirá se associar ao usuário. No entanto, o dispositivo MFA estará fora de sincronia. Isso ocorre porque as senhas únicas baseadas em tempo (time-based one-time passwords, TOTP) expiram após um curto período. Caso isso ocorra, você pode [ressincronizar o dispositivo](id_credentials_mfa_sync.md).
O dispositivo MFA virtual está pronto para ser usado com a AWS.
1. Saia do console e, em seguida, faça login como **MFAUser** novamente. Dessa vez, a AWS solicita um código de MFA de seu telefone. Quando você obtiver esse código, digite-o na caixa e, em seguida, escolha **Enviar**.
1. Escolha **EC2** para abrir o console do Amazon EC2 novamente. Desta vez, observe que você poderá ver todas as informações e realizar qualquer ação desejada. Se você acessar qualquer outro console como esse usuário, verá mensagens de acesso negado. O motivo é que as políticas neste tutorial concedem acesso somente ao Amazon EC2.
## Recursos relacionados
Para obter informações adicionais, consulte os seguintes tópicos:
+ [Código da autenticação multifator no IAM da AWS](id_credentials_mfa.md)
+ [Login habilitado para MFA](console_sign-in-mfa.md)
# Tutorial do IAM: use um modelo do CloudFormation para criar um provedor de identidades (IdP) do SAML
Para configurar a federação SAML para sua conta da AWS, você precisa criar um provedor de identidades (IdP) SAML. Este tutorial mostra como usar um modelo do CloudFormation para criar um IdP do SAML que estabeleça confiança entre a AWS e seu IdP externo.
O modelo cria um IdP do SAML configurado com o documento de metadados do seu IdP. Os perfis federados do IAM podem então fazer referência a esse IdP para permitir que usuários autenticados do seu IdP externo acessem os recursos da AWS.
O recurso implantado consiste em um IdP do SAML configurado com o documento de metadados do seu IdP e configurações de criptografia opcionais.
## Pré-requisitos
Este tutorial pressupõe que você já tenha os seguintes itens configurados:
+ Python 3.6 ou posterior instalado em sua máquina local para executar o comando Python usado neste tutorial para formatar o arquivo XML de metadados SAML do seu IdP.
+ Um documento de metadados SAML do seu IdP externo salvo como um arquivo XML.
## Criar um IdP do SAML usando o CloudFormation
Para criar o IdP do SAML e o perfil federado, você criará um modelo do CloudFormation e o usará para criar uma pilha contendo os dois recursos.
### Criar o modelo do
Primeiro, crie o modelo do CloudFormation.
1. Na seção [Modelo](#tutorial_saml-idp-template), clique no ícone de cópia na guia **JSON** ou **YAML** para copiar o conteúdo do modelo.
1. Copie o conteúdo do modelo em um novo arquivo.
1. Salve o arquivo localmente.
### Crie a pilha.
Em seguida, use o arquivo de modelo que você salvou para provisionar uma pilha do CloudFormation.
1. Abra o console do CloudFormation em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Na página **Pilhas**, no menu **Criar pilha**, escolha **com novos recursos (padrão)**.
1. Especifique o modelo:
1. Em **Pré-requisito**, escolha **Escolher um modelo existente**.
1. Em **Especificar modelo**, escolha **Fazer upload de um arquivo de modelo**.
1. Selecione **Escolher arquivo**, navegue até o arquivo de modelo e selecione-o.
1. Escolha **Próximo**.
1. Especifique os seguintes detalhes da pilha:
1. Digite um nome de pilha.
1. Você pode deixar o campo **IdentityProviderName** em branco para gerar automaticamente um nome com base no nome da pilha ou inserir um nome personalizado para seu IdP do SAML. Nomes personalizados devem conter apenas caracteres alfanuméricos, pontos, sublinhados e hifens.
1. Para **IdentityProviderSAMLMetadataDocument**, você precisa formatar seu arquivo XML de metadados SAML como uma única linha antes de colá-lo nesse campo. Isso é necessário porque o console do CloudFormation exige que o conteúdo XML seja formatado como uma única linha quando passado pelos parâmetros do console.
Use o seguinte comando Python para reformatar seu arquivo XML:
```
python3 -c "import sys, re; content=open(sys.argv[1]).read(); print(re.sub(r'>\s+<', '><', content.replace('\n', '').replace('\r', '').strip()))" saml-metadata.xml
```
**nota**
O documento de metadados SAML do IdP deve ser formatado como uma única linha para entrada de parâmetros do console. O comando Python remove quebras de linha e espaços em branco extras para criar o formato necessário, mantendo todo o conteúdo e estrutura originais.
Copie a saída do comando Python e cole-a no campo **IdentityProviderSAMLMetadataDocument**.
Exemplo de documento de metadados SAML formatado (abreviado):
```
MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV...urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
```
1. Para outros parâmetros, aceite os valores padrão ou insira seus próprios com base em seus requisitos:
+ **IdentityProviderAddPrivateKey**: chave privada opcional para descriptografar asserções do SAML
+ **IdentityProviderAssertionEncryptionMode**: opcional, define o modo de criptografia para asserções SAML (permitido, obrigatório ou vazio)
1. Escolha **Próximo**.
1. Configurar as opções da pilha:
1. Em **Opções de falha de pilha**, escolha **Excluir todos os recursos recém-criados**.
**nota**
A escolha dessa opção evita que você seja cobrado por recursos cuja política de exclusão especifica que eles sejam retidos mesmo que a criação da pilha falhe.
1. Aceite todos os outros valores padrão.
1. Em **Capacidades**, marque a caixa para confirmar que o CloudFormation pode criar recursos do IAM em sua conta.
1. Escolha **Próximo**.
1. Revise os detalhes a pilha e selecione **Enviar**.
CloudFormationO cria a pilha. Quando a criação da pilha for concluída, os recursos da pilha estarão prontos para uso. Você pode usar a guia **Recursos** na página de detalhes da pilha para visualizar os recursos que foram provisionados em sua conta.
A pilha produzirá os seguintes valores, que você pode ver na guia **Saídas**:
+ **ProviderARN**: o ARN do IdP do SAML criado (por exemplo `arn:aws:iam::123456789012:saml-provider/CompanyIdP`). Você precisará desse ARN ao criar perfis que confiem nesse provedor.
+ **ProviderName**: o nome do IdP do SAML criado (por exemplo `CompanyIdP`, se você especificou um nome personalizado ou `my-saml-stack-saml-provider` se usou a nomenclatura padrão).
Essas saídas também são exportadas, permitindo que sejam importadas por outras pilhas do CloudFormation usando o função `Fn::ImportValue`.
## Verificar o IdP do SAML
Depois que o IdP do SAML for criado, você poderá verificar sua configuração e anotar seu ARN para uso com perfis federados.
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação, escolha **Identity providers (Provedores de identidade)**.
Você deverá ver seu IdP do SAML recém-criado na lista.
1. Selecione o nome do IdP para visualizar seus detalhes.
Na página de detalhes do IdP, você pode ver o documento de metadados do SAML e outros detalhes de configuração.
1. Observe o **ARN do provedor** exibido na página de detalhes.
Você precisará desse ARN ao criar perfis federados do IAM que confiam nesse IdP.
1. Revise o documento de metadados para garantir que corresponda ao que você forneceu do IdP externo.
Seu IdP do SAML agora está pronto para ser usado por perfis federadas do IAM. Você pode criar perfis que confiem nesse IdP para permitir que usuários autenticados do seu IdP externo assumam esses perfis e acessem os recursos da AWS.
## Limpeza: excluir recursos
Como etapa final, você excluirá a pilha e os recursos que ela contém.
1. Abra o CloudFormation Console.
1. Na página **Pilhas**, escolha a pilha criada a partir do modelo, escolha **Excluir** e confirme para **Excluir**.
O CloudFormation inicia a exclusão da pilha e de todos os recursos que ela inclui.
## Detalhes do modelo do CloudFormation
### Recursos
O modelo do CloudFormation para este tutorial criará o seguinte recurso em sua conta:
[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html): um IdP do SAML que estabeleça confiança entre AWS e seu IdP externo.
### Configuração
O modelo inclui os seguintes parâmetros configuráveis:
+ **IdentityProviderName**: o nome do seu IdP do SAML (deixe em branco para nome gerado automaticamente)
Exemplo: `CompanyIdP` ou `EnterpriseSSO`
+ **IdentityProviderSAMLMetadataDocument**: o documento de metadados SAML do seu IdP externo (formatado como uma única linha)
+ **IdentityProviderAddPrivateKey**: chave privada opcional para descriptografar asserções do SAML
+ **IdentityProviderAssertionEncryptionMode**: opcional, define o modo de criptografia para asserções SAML
## Modelo do CloudFormation
Salve o código JSON ou YAML a seguir em outro arquivo para usar como modelo do CloudFormation neste tutorial.
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-idp",
"Parameters": {
"IdentityProviderName": {
"Type": "String",
"Description": "Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens"
},
"IdentityProviderSAMLMetadataDocument": {
"Type": "String",
"Description": "SAML metadata document from identity provider"
},
"IdentityProviderAddPrivateKey": {
"Type": "String",
"Description": "Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.",
"Default": ""
},
"IdentityProviderAssertionEncryptionMode": {
"Type": "String",
"Description": "Optional, sets encryption mode for SAML assertions",
"Default": "",
"AllowedValues": ["", "Allowed", "Required"]
}
},
"Conditions": {
"HasPrivateKey": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAddPrivateKey"}, ""]}]},
"HasEncryptionMode": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAssertionEncryptionMode"}, ""]}]},
"HasCustomName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderName"}, ""]}]}
},
"Resources": {
"SAMLProvider": {
"Type": "AWS::IAM::SAMLProvider",
"Properties": {
"Name": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Ref": "AWS::NoValue"}]},
"SamlMetadataDocument": {"Ref": "IdentityProviderSAMLMetadataDocument"},
"Tags": [
{
"Key": "Name",
"Value": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Fn::Sub": "${AWS::StackName}-saml-provider"}]}
}
],
"AddPrivateKey": {"Fn::If": ["HasPrivateKey", {"Ref": "IdentityProviderAddPrivateKey"}, {"Ref": "AWS::NoValue"}]},
"AssertionEncryptionMode": {"Fn::If": ["HasEncryptionMode", {"Ref": "IdentityProviderAssertionEncryptionMode"}, {"Ref": "AWS::NoValue"}]}
}
}
},
"Outputs": {
"ProviderARN": {
"Description": "ARN of the created SAML Identity Provider",
"Value": {"Ref": "SAMLProvider"},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-ProviderARN"}
}
},
"ProviderName": {
"Description": "Name of the SAML Identity Provider",
"Value": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Fn::Sub": "${AWS::StackName}-saml-provider"}]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-ProviderName"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-idp'
Parameters:
IdentityProviderName:
Type: String
Description: Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[a-zA-Z0-9._-]+$'
ConstraintDescription: 'Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens'
IdentityProviderSAMLMetadataDocument:
Type: String
Description: SAML metadata document from identity provider
IdentityProviderAddPrivateKey:
Type: String
Description: Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.
Default: ""
IdentityProviderAssertionEncryptionMode:
Type: String
Description: Optional, sets encryption mode for SAML assertions
Default: ""
AllowedValues:
- ""
- "Allowed"
- "Required"
Conditions:
HasPrivateKey: !Not [!Equals [!Ref IdentityProviderAddPrivateKey, ""]]
HasEncryptionMode: !Not [!Equals [!Ref IdentityProviderAssertionEncryptionMode, ""]]
HasCustomName: !Not [!Equals [!Ref IdentityProviderName, ""]]
Resources:
SAMLProvider:
Type: 'AWS::IAM::SAMLProvider'
Properties:
Name: !If
- HasCustomName
- !Ref IdentityProviderName
- !Ref AWS::NoValue
SamlMetadataDocument: !Ref IdentityProviderSAMLMetadataDocument
Tags:
- Key: Name
Value: !If
- HasCustomName
- !Ref IdentityProviderName
- !Sub '${AWS::StackName}-saml-provider'
AddPrivateKey: !If
- HasPrivateKey
- !Ref IdentityProviderAddPrivateKey
- !Ref AWS::NoValue
AssertionEncryptionMode: !If
- HasEncryptionMode
- !Ref IdentityProviderAssertionEncryptionMode
- !Ref AWS::NoValue
Outputs:
ProviderARN:
Description: 'ARN of the created SAML Identity Provider'
Value: !Ref SAMLProvider
Export:
Name: !Sub '${AWS::StackName}-ProviderARN'
ProviderName:
Description: 'Name of the SAML Identity Provider'
Value: !If
- HasCustomName
- !Ref IdentityProviderName
- !Sub '${AWS::StackName}-saml-provider'
Export:
Name: !Sub '${AWS::StackName}-ProviderName'
```
------
# Tutorial do IAM: use um modelo de CloudFormation para criar um perfil do IAM federado por SAML
Quando você tem um provedor de identidades (IdP do SAML) existente configurado em sua conta da AWS, você pode criar perfis federados do IAM que confiam nesse IdP. Este tutorial mostra como usar um modelo do CloudFormation para criar um perfil federado do IAM por SAML que pode ser assumido por usuários autenticados por meio do seu IdP externo.
O modelo cria um perfil federado do IAM com uma política de confiança que permite que o IdP do SAML assuma o perfil. Os usuários autenticados pelo seu IdP externo podem assumir esse perfil para acessar recursos da AWS nas permissões anexadas ao perfil.
O recurso implantado consiste no seguinte:
+ Um perfio federada do IAM que confia em seu IdP do SAML existente.
+ Políticas gerenciadas configuráveis que podem ser anexadas ao perfil para conceder permissões específicas.
+ Configurações opcionais de limite de permissões e duração da sessão.
## Pré-requisitos
Este tutorial pressupõe que você já tenha os seguintes itens configurados:
+ Um IdP do SAML existente configurado em sua conta da AWS. Se você não tiver um, poderá criá-lo usando o tutorial [Tutorial do IAM: use um modelo do CloudFormation para criar um provedor de identidades (IdP) do SAML](tutorial_saml-idp.md).
+ O ARN do seu IdP do SAML, que você precisará especificar como parâmetro ao criar a pilha.
+ Python 3.6 ou posterior instalado em sua máquina local para executar o comando Python usado neste tutorial para formatar o arquivo XML de metadados SAML do seu IdP.
## Crie um perfil federado do SAML usando CloudFormation
Para criar o perfil federado do IdP do SAML, você criará um modelo do CloudFormation e o usará para criar uma pilha contendo o perfil.
### Criar o modelo do
Primeiro, crie o modelo do CloudFormation.
1. Na seção [Modelo](#tutorial_saml-federated-role-template), clique no ícone de cópia na guia **JSON** ou **YAML** para copiar o conteúdo do modelo.
1. Copie o conteúdo do modelo em um novo arquivo.
1. Salve o arquivo localmente.
### Crie a pilha.
Em seguida, use o arquivo de modelo que você salvou para provisionar uma pilha do CloudFormation.
1. Abra o console do CloudFormation em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Na página **Pilhas**, no menu **Criar pilha**, escolha **com novos recursos (padrão)**.
1. Especifique o modelo:
1. Em **Pré-requisito**, escolha **Escolher um modelo existente**.
1. Em **Especificar modelo**, escolha **Fazer upload de um arquivo de modelo**.
1. Selecione **Escolher arquivo**, navegue até o arquivo de modelo e selecione-o.
1. Escolha **Próximo**.
1. Especifique os seguintes detalhes da pilha:
1. Digite um nome de pilha.
1. Para **SAMLProviderARN**, insira o ARN do seu IdP do SAML existente. Isso deve estar no formato `arn:aws:iam::123456789012:saml-provider/YourProviderName`.
Exemplo: `arn:aws:iam::123456789012:saml-provider/CompanyIdP`
**nota**
Se você criou seu IdP do SAML usando o tutorial [Tutorial do IAM: use um modelo do CloudFormation para criar um provedor de identidades (IdP) do SAML](tutorial_saml-idp.md), poderá encontrar o ARN do provedor na guia Saídas dessa pilha do CloudFormation.
1. Para **RoleName**, é possível deixar isso em branco para gerar automaticamente um nome com base no nome da pilha ou inserir um nome personalizado para o perfil do IAM.
Exemplo: `SAML-Developer-Access` ou `SAML-ReadOnly-Role`
1. Para outros parâmetros, aceite os valores padrão ou insira seus próprios com base em seus requisitos:
+ **RoleSessionDuration**: duração máxima da sessão em segundos (3600-43200, padrão 7200)
Exemplo: `14400` (4 horas)
+ **RolePermissionsBoundary**: ARN opcional de uma política de limite de permissões
Exemplo: `arn:aws:iam::123456789012:policy/DeveloperBoundary`
+ **RolePath**: caminho para o perfil do IAM (o padrão é /)
Exemplo: `/saml-roles/`
+ **ManagedPolicy1-5**: ARNs opcionais de até 5 políticas gerenciadas para anexar
Exemplo de ManagedPolicy1: `arn:aws:iam::aws:policy/ReadOnlyAccess`
Exemplo de ManagedPolicy2: `arn:aws:iam::123456789012:policy/CustomPolicy`
1. Escolha **Próximo**.
1. Configurar as opções da pilha:
1. Em **Opções de falha de pilha**, escolha **Excluir todos os recursos recém-criados**.
**nota**
A escolha dessa opção evita que você seja cobrado por recursos cuja política de exclusão especifica que eles sejam retidos mesmo que a criação da pilha falhe.
1. Aceite todos os outros valores padrão.
1. Em **Capacidades**, marque a caixa para confirmar que o CloudFormation pode criar recursos do IAM em sua conta.
1. Escolha **Próximo**.
1. Revise os detalhes a pilha e selecione **Enviar**.
CloudFormationO cria a pilha. Quando a criação da pilha for concluída, os recursos da pilha estarão prontos para uso. Você pode usar a guia **Recursos** na página de detalhes da pilha para visualizar os recursos que foram provisionados em sua conta.
A pilha produzirá o seguinte valor, que você pode ver na guia **Saídas**:
+ **RoleARN**: o ARN do perfil do IAM criado (por exemplo, `arn:aws:iam::123456789012:role/SAML-Developer-Access` ou `arn:aws:iam::123456789012:role/stack-name-a1b2c3d4` se estiver usando um nome gerado automaticamente).
Você precisará desse ARN de perfil ao configurar seu IdP para enviar os atributos SAML apropriados para assumir o perfil.
## Teste o perfil federado do SAML
Depois que o perfil federado do SAML for criado, você pode verificar sua configuração e testar a configuração da federação.
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação, escolha **Perfis**.
1. Encontre e selecione o perfil federado recém-criado.
Se você forneceu um nome de perfil personalizado, procure esse nome. Se você deixar o parâmetro RoleName vazio, o perfil terá um nome gerado automaticamente com base no nome da pilha e um identificador exclusivo.
1. Selecione a guia **Relações de confiança** para revisar a política de confiança.
A política de confiança deve mostrar que o IdP do SAML é confiável para assumir esse perfil com a condição de que o público do SAML (`SAML:aud`) corresponda ao `https://signin.aws.amazon.com/saml`.
1. Clique na guia **Permissões** para revisar as políticas anexadas.
Você pode ver todas as políticas gerenciadas que foram anexadas ao perfil durante a criação.
1. Observe o **ARN do perfil** exibido na página de resumo do perfil.
Você precisará desse ARN para configurar seu IdP externo para permitir que os usuários assumam esse perfil.
Seu perfil federado do SAML agora está pronto para ser usado. Configure seu IdP externo para incluir o ARN desse perfil nas asserções do SAML, e os usuários autenticados poderão assumir esse perfil para acessar recursos da AWS.
## Limpeza: excluir recursos
Como etapa final, você excluirá a pilha e os recursos que ela contém.
1. Abra o CloudFormation Console.
1. Na página **Pilhas**, escolha a pilha criada a partir do modelo, escolha **Excluir** e confirme para **Excluir**.
O CloudFormation inicia a exclusão da pilha e de todos os recursos que ela inclui.
## Detalhes do modelo do CloudFormation
### Recursos
O modelo do CloudFormation para este tutorial criará o seguinte recurso em sua conta:
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html): uma perfil federado do IAM que pode ser assumido por usuários autenticados por meio do seu IdP do SAML.
### Configuração
O modelo inclui os seguintes parâmetros configuráveis:
+ **RoleName**: nome do perfil do IAM (deixe em branco para nome gerado automaticamente)
+ **SAMLProviderARN**: ARN do IdP do SAML (obrigatório)
+ **RoleSessionDuration**: duração máxima da sessão em segundos (3600-43200, padrão 7200)
+ **RolePermissionsBoundary**: ARN opcional da política de limite de permissões
+ **RolePath**: caminho para o perfil do IAM (padrão /)
+ **ManagedPolicy1-5**: ARNs opcionais de até 5 políticas gerenciadas para anexar
## Modelo do CloudFormation
Salve o código JSON ou YAML a seguir em outro arquivo para usar como modelo do CloudFormation neste tutorial.
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-federated-role",
"Parameters": {
"RoleName": {
"Type": "String",
"Description": "Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[\\w+=,.@-]{1,64}$",
"ConstraintDescription": "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
},
"SAMLProviderARN": {
"Type": "String",
"Description": "ARN of the SAML Identity Provider",
"AllowedPattern": "^arn:aws:iam::\\d{12}:saml-provider/[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be a valid SAML provider ARN"
},
"RoleSessionDuration": {
"Type": "Number",
"Description": "The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)",
"MinValue": 3600,
"MaxValue": 43200,
"Default": 7200
},
"RolePermissionsBoundary": {
"Type": "String",
"Description": "Optional ARN of the permissions boundary policy (leave empty for none)",
"Default": ""
},
"RolePath": {
"Type": "String",
"Description": "Path for the IAM role (must start and end with /)",
"Default": "/",
"AllowedPattern": "^\/.*\/$|^\/$",
"ConstraintDescription": "Role path must start and end with forward slash (/)"
},
"RoleManagedPolicy1": {
"Type": "String",
"Description": "Optional managed policy ARN 1",
"Default": ""
},
"RoleManagedPolicy2": {
"Type": "String",
"Description": "Optional managed policy ARN 2",
"Default": ""
},
"RoleManagedPolicy3": {
"Type": "String",
"Description": "Optional managed policy ARN 3",
"Default": ""
},
"RoleManagedPolicy4": {
"Type": "String",
"Description": "Optional managed policy ARN 4",
"Default": ""
},
"RoleManagedPolicy5": {
"Type": "String",
"Description": "Optional managed policy ARN 5",
"Default": ""
}
},
"Conditions": {
"HasCustomRoleName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleName"}, ""]}]},
"HasPermissionsBoundary": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RolePermissionsBoundary"}, ""]}]},
"HasPolicy1": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy1"}, ""]}]},
"HasPolicy2": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy2"}, ""]}]},
"HasPolicy3": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy3"}, ""]}]},
"HasPolicy4": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy4"}, ""]}]},
"HasPolicy5": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy5"}, ""]}]}
},
"Resources": {
"SAMLFederatedRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"RoleName": {"Fn::If": ["HasCustomRoleName", {"Ref": "RoleName"}, {"Ref": "AWS::NoValue"}]},
"Description": "IAM role with SAML provider trust",
"MaxSessionDuration": {"Ref": "RoleSessionDuration"},
"PermissionsBoundary": {"Fn::If": ["HasPermissionsBoundary", {"Ref": "RolePermissionsBoundary"}, {"Ref": "AWS::NoValue"}]},
"Path": {"Ref": "RolePath"},
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": {"Ref": "SAMLProviderARN"}
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
},
"ManagedPolicyArns": {
"Fn::Split": [
",",
{
"Fn::Join": [
",",
[
{"Fn::If": ["HasPolicy1", {"Ref": "RoleManagedPolicy1"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy2", {"Ref": "RoleManagedPolicy2"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy3", {"Ref": "RoleManagedPolicy3"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy4", {"Ref": "RoleManagedPolicy4"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy5", {"Ref": "RoleManagedPolicy5"}, {"Ref": "AWS::NoValue"}]}
]
]
}
]
}
}
}
},
"Outputs": {
"RoleARN": {
"Description": "ARN of the created IAM Role",
"Value": {"Fn::GetAtt": ["SAMLFederatedRole", "Arn"]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-RoleARN"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-federated-role'
Parameters:
RoleName:
Type: String
Description: 'Name of the IAM Role (leave empty for auto-generated name like ''{StackName}-{UniqueId}'')'
Default: ""
AllowedPattern: '^$|^[\w+=,.@-]{1,64}$'
ConstraintDescription: 'Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-'
SAMLProviderARN:
Type: String
Description: 'ARN of the SAML Identity Provider'
AllowedPattern: '^arn:aws:iam::\d{12}:saml-provider/[a-zA-Z0-9._-]+$'
ConstraintDescription: 'Must be a valid SAML provider ARN'
RoleSessionDuration:
Type: Number
Description: 'The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)'
MinValue: 3600
MaxValue: 43200
Default: 7200
RolePermissionsBoundary:
Type: String
Description: Optional ARN of the permissions boundary policy (leave empty for none)
Default: ""
RolePath:
Type: String
Description: 'Path for the IAM role (must start and end with /)'
Default: "/"
AllowedPattern: '^\/.*\/$|^\/$'
ConstraintDescription: 'Role path must start and end with forward slash (/)'
RoleManagedPolicy1:
Type: String
Description: Optional managed policy ARN 1
Default: ""
RoleManagedPolicy2:
Type: String
Description: Optional managed policy ARN 2
Default: ""
RoleManagedPolicy3:
Type: String
Description: Optional managed policy ARN 3
Default: ""
RoleManagedPolicy4:
Type: String
Description: Optional managed policy ARN 4
Default: ""
RoleManagedPolicy5:
Type: String
Description: Optional managed policy ARN 5
Default: ""
Conditions:
HasCustomRoleName: !Not [!Equals [!Ref RoleName, ""]]
HasPermissionsBoundary: !Not [!Equals [!Ref RolePermissionsBoundary, ""]]
HasPolicy1: !Not [!Equals [!Ref RoleManagedPolicy1, ""]]
HasPolicy2: !Not [!Equals [!Ref RoleManagedPolicy2, ""]]
HasPolicy3: !Not [!Equals [!Ref RoleManagedPolicy3, ""]]
HasPolicy4: !Not [!Equals [!Ref RoleManagedPolicy4, ""]]
HasPolicy5: !Not [!Equals [!Ref RoleManagedPolicy5, ""]]
Resources:
SAMLFederatedRole:
Type: 'AWS::IAM::Role'
Properties:
RoleName: !If
- HasCustomRoleName
- !Ref RoleName
- !Ref AWS::NoValue
Description: 'IAM role with SAML provider trust'
MaxSessionDuration: !Ref RoleSessionDuration
PermissionsBoundary: !If
- HasPermissionsBoundary
- !Ref RolePermissionsBoundary
- !Ref AWS::NoValue
Path: !Ref RolePath
AssumeRolePolicyDocument:
Version: '2012-10-17 '
Statement:
- Effect: Allow
Principal:
Federated: !Ref SAMLProviderARN
Action: 'sts:AssumeRoleWithSAML'
Condition:
StringEquals:
'SAML:aud': 'https://signin.aws.amazon.com/saml'
ManagedPolicyArns:
!Split
- ','
- !Join
- ','
- - !If [HasPolicy1, !Ref RoleManagedPolicy1, !Ref 'AWS::NoValue']
- !If [HasPolicy2, !Ref RoleManagedPolicy2, !Ref 'AWS::NoValue']
- !If [HasPolicy3, !Ref RoleManagedPolicy3, !Ref 'AWS::NoValue']
- !If [HasPolicy4, !Ref RoleManagedPolicy4, !Ref 'AWS::NoValue']
- !If [HasPolicy5, !Ref RoleManagedPolicy5, !Ref 'AWS::NoValue']
Outputs:
RoleARN:
Description: 'ARN of the created IAM Role'
Value: !GetAtt SAMLFederatedRole.Arn
Export:
Name: !Sub '${AWS::StackName}-RoleARN'
```
------
# Tutorial do IAM: use um modelo de CloudFormation para criar um provedor de identidades (IdP) do SAML e um perfil do IAM federado por SAML
Para se familiarizar com a federação do SAML e seus recursos, você usará um modelo de CloudFormation para configurar um provedor de identidades (IdP) do SAML e o perfil federado do IAM associado. Este tutorial mostra como criar os dois recursos juntos em uma única pilha.
O modelo cria um IdP do SAML que pode ser usado para acesso federado aos recursos da AWS, junto com um perfil do IAM que confia no provedor de SAML. Os usuários autenticados pelo seu IdP externo podem assumir esse perfil para acessar recursos da AWS.
Os recursos implantados consistem no seguinte:
+ Um IdP do SAML configurado com o documento de metadados do seu IdP.
+ Um perfil federado do IAM que confia no IdP do SAML e pode ser assumido por usuários autenticados.
+ Políticas gerenciadas configuráveis que podem ser anexadas ao perfil para conceder permissões específicas.
## Pré-requisitos
Este tutorial pressupõe que você já tenha os seguintes itens configurados:
+ Python 3.6 ou posterior instalado em sua máquina local para executar o comando Python usado neste tutorial para formatar o arquivo XML de metadados SAML do seu IdP.
+ Um documento de metadados SAML do seu IdP externo salvo como um arquivo XML.
## Criar um IdP e um perfil do SAML usando o CloudFormation
Para criar o IdP do SAML e o perfil federado, você criará um modelo do CloudFormation e o usará para criar uma pilha contendo os dois recursos.
### Criar o modelo do
Primeiro, crie o modelo do CloudFormation.
1. Na seção [Modelo](#tutorial_saml-idp-and-federated-role-template), clique no ícone de cópia na guia **JSON** ou **YAML** para copiar o conteúdo do modelo.
1. Copie o conteúdo do modelo em um novo arquivo.
1. Salve o arquivo localmente.
### Crie a pilha.
Em seguida, use o arquivo de modelo que você salvou para provisionar uma pilha do CloudFormation.
1. Abra o console do CloudFormation em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Na página **Pilhas**, no menu **Criar pilha**, escolha **com novos recursos (padrão)**.
1. Especifique o modelo:
1. Em **Pré-requisito**, escolha **Escolher um modelo existente**.
1. Em **Especificar modelo**, escolha **Fazer upload de um arquivo de modelo**.
1. Selecione **Escolher arquivo**, navegue até o arquivo de modelo e selecione-o.
1. Escolha **Próximo**.
1. Especifique os seguintes detalhes da pilha:
1. Digite um nome de pilha.
1. Você pode deixar o campo **IdentityProviderName** em branco para gerar automaticamente um nome com base no nome da pilha ou inserir um nome personalizado para seu IdP do SAML.
Exemplo: `CompanyIdP` ou `EnterpriseSSO`
1. Para **IdentityProviderSAMLMetadataDocument**, você precisa formatar seu arquivo XML de metadados SAML como uma única linha antes de colá-lo nesse campo. Isso é necessário porque o console do CloudFormation exige que o conteúdo XML seja formatado como uma única linha quando passado pelos parâmetros do console.
Use o seguinte comando Python para reformatar seu arquivo XML:
```
python3 -c "import sys, re; content=open(sys.argv[1]).read(); print(re.sub(r'>\s+<', '><', content.replace('\n', '').replace('\r', '').strip()))" saml-metadata.xml
```
**nota**
O documento de metadados SAML do IdP deve ser formatado como uma única linha para entrada de parâmetros do console. O comando Python remove quebras de linha e espaços em branco extras para criar o formato necessário, mantendo todo o conteúdo e estrutura originais.
Copie a saída do comando Python e cole-a no campo **IdentityProviderSAMLMetadataDocument**.
Exemplo de documento de metadados SAML formatado (abreviado):
```
MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV...urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
```
1. Você pode deixar **RoleName** em branco para gerar automaticamente um nome com base no nome da pilha ou inserir um nome personalizado para o perfil federado do IAM.
Exemplo: `SAML-Developer-Access` ou `SAML-ReadOnly-Role`
1. Para outros parâmetros, aceite os valores padrão ou insira seus próprios com base em seus requisitos:
+ **IdentityProviderAddPrivateKey**: chave privada opcional para descriptografar asserções do SAML
+ **IdentityProviderAssertionEncryptionMode**: modo de criptografia para asserções SAML
Valores de exemplo: `Allowed`, `Required` ou deixe em branco para sem criptografia
+ **RoleSessionDuration**: duração máxima da sessão em segundos (3600-43200, padrão 7200)
Exemplo: `14400` (4 horas)
+ **RolePermissionsBoundary**: ARN opcional de uma política de limite de permissões
Exemplo: `arn:aws:iam::123456789012:policy/DeveloperBoundary`
+ **RolePath**: caminho para o perfil do IAM (o padrão é /)
Exemplo: `/saml-roles/`
+ **RoleManagedPolicy1-5**: ARNs opcionais de até 5 políticas gerenciadas para anexar
Exemplo de RoleManagedPolicy1: `arn:aws:iam::aws:policy/ReadOnlyAccess`
Exemplo de RoleManagedPolicy2: `arn:aws:iam::123456789012:policy/CustomPolicy`
1. Escolha **Próximo**.
1. Configurar as opções da pilha:
1. Em **Opções de falha de pilha**, escolha **Excluir todos os recursos recém-criados**.
**nota**
A escolha dessa opção evita que você seja cobrado por recursos cuja política de exclusão especifica que eles sejam retidos mesmo que a criação da pilha falhe.
1. Aceite todos os outros valores padrão.
1. Em **Capacidades**, marque a caixa para confirmar que o CloudFormation pode criar recursos do IAM em sua conta.
1. Escolha **Próximo**.
1. Revise os detalhes a pilha e selecione **Enviar**.
CloudFormationO cria a pilha. Quando a criação da pilha for concluída, os recursos da pilha estarão prontos para uso. Você pode usar a guia **Recursos** na página de detalhes da pilha para visualizar os recursos que foram provisionados em sua conta.
A pilha produzirá os seguintes valores, que você pode ver na guia **Saídas**:
+ **RoleARN**: o ARN do perfil do IAM criado (por exemplo, `arn:aws:iam::123456789012:role/SAML-Developer-Access` ou `arn:aws:iam::123456789012:role/stack-name-a1b2c3d4` se estiver usando um nome gerado automaticamente).
+ **IdentityProviderARN**: o ARN do IdP do SAML criado (por exemplo, `arn:aws:iam::123456789012:saml-provider/CompanyIdP`).
Você precisará desses dois ARNs ao configurar seu IdP para enviar os atributos de SAML apropriados para assumir o perfil.
## Testar a federação do SAML
Depois que o IdP do SAML e o perfil federado forem criados, você poderá testar a configuração da federação.
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação, escolha **Identity providers (Provedores de identidade)**.
Você deverá ver seu IdP do SAML recém-criado na lista.
1. Selecione o nome do IdP para visualizar seus detalhes.
Na página de detalhes do IdP, você pode ver o documento de metadados do SAML e outros detalhes de configuração.
1. No painel de navegação, escolha **Perfis**.
1. Encontre e selecione seu perfil federado recém-criado.
Na página de detalhes do perfil, você pode ver a política de confiança que permite que o IdP do SAML assuma esse perfil.
1. Selecione a guia **Relações de confiança** para revisar a política de confiança.
A política de confiança deve mostrar que o IdP do SAML é confiável para assumir esse perfil com a condição de que o público do SAML (`SAML:aud`) corresponda ao `https://signin.aws.amazon.com/saml`.
## Limpeza: excluir recursos
Como etapa final, você excluirá a pilha e os recursos que ela contém.
1. Abra o CloudFormation Console.
1. Na página **Pilhas**, escolha a pilha criada a partir do modelo, escolha **Excluir** e confirme para **Excluir**.
O CloudFormation inicia a exclusão da pilha e de todos os recursos que ela inclui.
## Detalhes do modelo do CloudFormation
### Recursos
O modelo do CloudFormation para este tutorial criará os seguintes recursos em sua conta:
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html): um IdP do SAML que estabeleça confiança entre AWS e seu IdP externo.
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html): um perfil federado do IAM que pode ser assumido por usuários autenticados por meio do IdP do SAML.
### Configuração
O modelo inclui os seguintes parâmetros configuráveis:
+ **IdentityProviderName**: nome do IdP do SAML (deixe em branco para nome gerado automaticamente)
+ **IdentityProviderSAMLMetadataDocument**: Documento de metadados SAML do seu IdP (obrigatório)
+ **IdentityProviderAddPrivateKey**: chave privada opcional para descriptografar asserções do SAML
+ **IdentityProviderAssertionEncryptionMode**: modo de criptografia para asserções SAML
+ **RoleName**: nome do perfil do IAM (deixe em branco para nome gerado automaticamente)
+ **RolePath**: caminho para o perfil do IAM (padrão /)
+ **RolePermissionsBoundary**: ARN opcional da política de limite de permissões
+ **RoleSessionDuration**: duração máxima da sessão em segundos (3600-43200, padrão 7200)
+ **RoleManagedPolicy1-5**: ARNs opcionais de até 5 políticas gerenciadas para anexar
## Modelo do CloudFormation
Salve o código JSON ou YAML a seguir em outro arquivo para usar como modelo do CloudFormation neste tutorial.
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-idp-and-federated-role",
"Parameters": {
"IdentityProviderName": {
"Type": "String",
"Description": "Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens"
},
"IdentityProviderSAMLMetadataDocument": {
"Type": "String",
"Description": "SAML metadata document from identity provider"
},
"IdentityProviderAddPrivateKey": {
"Type": "String",
"Description": "Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.",
"Default": ""
},
"IdentityProviderAssertionEncryptionMode": {
"Type": "String",
"Description": "Optional, sets encryption mode for SAML assertions",
"Default": "",
"AllowedValues": ["", "Allowed", "Required"]
},
"RoleName": {
"Type": "String",
"Description": "Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[\\w+=,.@-]{1,64}$",
"ConstraintDescription": "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
},
"RolePath": {
"Type": "String",
"Description": "Path for the IAM Role",
"AllowedPattern": "(^\\/$)|(^\\/.*\\/$)",
"Default": "/"
},
"RolePermissionsBoundary": {
"Type": "String",
"Description": "Optional ARN of the permissions boundary policy (leave empty for none)",
"Default": ""
},
"RoleSessionDuration": {
"Description": "The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)",
"Type": "Number",
"MinValue": 3600,
"MaxValue": 43200,
"Default": 7200
},
"RoleManagedPolicy1": {
"Type": "String",
"Description": "Optional managed policy ARN 1",
"Default": ""
},
"RoleManagedPolicy2": {
"Type": "String",
"Description": "Optional managed policy ARN 2",
"Default": ""
},
"RoleManagedPolicy3": {
"Type": "String",
"Description": "Optional managed policy ARN 3",
"Default": ""
},
"RoleManagedPolicy4": {
"Type": "String",
"Description": "Optional managed policy ARN 4",
"Default": ""
},
"RoleManagedPolicy5": {
"Type": "String",
"Description": "Optional managed policy ARN 5",
"Default": ""
}
},
"Conditions": {
"HasCustomProviderName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderName"}, ""]}]},
"HasCustomRoleName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleName"}, ""]}]},
"HasPermissionsBoundary": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RolePermissionsBoundary"}, ""]}]},
"HasPolicy1": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy1"}, ""]}]},
"HasPolicy2": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy2"}, ""]}]},
"HasPolicy3": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy3"}, ""]}]},
"HasPolicy4": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy4"}, ""]}]},
"HasPolicy5": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy5"}, ""]}]},
"HasPrivateKey": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAddPrivateKey"}, ""]}]},
"HasAssertionEncryptionMode": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAssertionEncryptionMode"}, ""]}]}
},
"Resources": {
"SAMLProvider": {
"Type": "AWS::IAM::SAMLProvider",
"Properties": {
"Name": {"Fn::If": ["HasCustomProviderName", {"Ref": "IdentityProviderName"}, {"Ref": "AWS::NoValue"}]},
"SamlMetadataDocument": {"Ref": "IdentityProviderSAMLMetadataDocument"},
"AddPrivateKey": {"Fn::If": ["HasPrivateKey", {"Ref": "IdentityProviderAddPrivateKey"}, {"Ref": "AWS::NoValue"}]},
"AssertionEncryptionMode": {"Fn::If": ["HasAssertionEncryptionMode", {"Ref": "IdentityProviderAssertionEncryptionMode"}, {"Ref": "AWS::NoValue"}]}
}
},
"SAMLFederatedRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"RoleName": {"Fn::If": ["HasCustomRoleName", {"Ref": "RoleName"}, {"Ref": "AWS::NoValue"}]},
"Path": {"Ref": "RolePath"},
"Description": "SAML federated IAM role for SSO access with specified permissions",
"MaxSessionDuration": {"Ref": "RoleSessionDuration"},
"PermissionsBoundary": {"Fn::If": ["HasPermissionsBoundary", {"Ref": "RolePermissionsBoundary"}, {"Ref": "AWS::NoValue"}]},
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": {"Ref": "SAMLProvider"}
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
},
"ManagedPolicyArns": {
"Fn::Split": [
",",
{
"Fn::Join": [
",",
[
{"Fn::If": ["HasPolicy1", {"Ref": "RoleManagedPolicy1"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy2", {"Ref": "RoleManagedPolicy2"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy3", {"Ref": "RoleManagedPolicy3"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy4", {"Ref": "RoleManagedPolicy4"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy5", {"Ref": "RoleManagedPolicy5"}, {"Ref": "AWS::NoValue"}]}
]
]
}
]
}
}
}
},
"Outputs": {
"RoleARN": {
"Description": "ARN of the created IAM Role",
"Value": {"Fn::GetAtt": ["SAMLFederatedRole", "Arn"]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-RoleARN"}
}
},
"IdentityProviderARN": {
"Description": "ARN of the created SAML Identity Provider",
"Value": {"Ref": "SAMLProvider"},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-IdentityProviderARN"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-idp-and-federated-role'
Parameters:
IdentityProviderName:
Type: String
Description: Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[a-zA-Z0-9._-]+$'
ConstraintDescription: Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens
IdentityProviderSAMLMetadataDocument:
Type: String
Description: SAML metadata document from identity provider
IdentityProviderAddPrivateKey:
Type: String
Description: Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.
Default: ""
IdentityProviderAssertionEncryptionMode:
Type: String
Description: Optional, sets encryption mode for SAML assertions
Default: ""
AllowedValues:
- ""
- "Allowed"
- "Required"
RoleName:
Type: String
Description: Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[\w+=,.@-]{1,64}$'
ConstraintDescription: "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
RolePath:
Type: String
Description: Path for the IAM Role
AllowedPattern: (^\/$)|(^\/.*\/$)
Default: "/"
RolePermissionsBoundary:
Type: String
Description: Optional ARN of the permissions boundary policy (leave empty for none)
Default: ""
RoleSessionDuration:
Description: The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)
Type: Number
MinValue: 3600
MaxValue: 43200
Default: 7200
RoleManagedPolicy1:
Type: String
Description: Optional managed policy ARN 1
Default: ""
RoleManagedPolicy2:
Type: String
Description: Optional managed policy ARN 2
Default: ""
RoleManagedPolicy3:
Type: String
Description: Optional managed policy ARN 3
Default: ""
RoleManagedPolicy4:
Type: String
Description: Optional managed policy ARN 4
Default: ""
RoleManagedPolicy5:
Type: String
Description: Optional managed policy ARN 5
Default: ""
Conditions:
HasCustomProviderName: !Not [!Equals [!Ref IdentityProviderName, ""]]
HasCustomRoleName: !Not [!Equals [!Ref RoleName, ""]]
HasPermissionsBoundary: !Not [!Equals [!Ref RolePermissionsBoundary, ""]]
HasPolicy1: !Not [!Equals [!Ref RoleManagedPolicy1, ""]]
HasPolicy2: !Not [!Equals [!Ref RoleManagedPolicy2, ""]]
HasPolicy3: !Not [!Equals [!Ref RoleManagedPolicy3, ""]]
HasPolicy4: !Not [!Equals [!Ref RoleManagedPolicy4, ""]]
HasPolicy5: !Not [!Equals [!Ref RoleManagedPolicy5, ""]]
HasPrivateKey: !Not [!Equals [!Ref IdentityProviderAddPrivateKey, ""]]
HasAssertionEncryptionMode: !Not [!Equals [!Ref IdentityProviderAssertionEncryptionMode, ""]]
Resources:
SAMLProvider:
Type: AWS::IAM::SAMLProvider
Properties:
Name: !If
- HasCustomProviderName
- !Ref IdentityProviderName
- !Ref AWS::NoValue
SamlMetadataDocument: !Ref IdentityProviderSAMLMetadataDocument
AddPrivateKey: !If
- HasPrivateKey
- !Ref IdentityProviderAddPrivateKey
- !Ref AWS::NoValue
AssertionEncryptionMode: !If
- HasAssertionEncryptionMode
- !Ref IdentityProviderAssertionEncryptionMode
- !Ref AWS::NoValue
SAMLFederatedRole:
Type: AWS::IAM::Role
Properties:
RoleName: !If
- HasCustomRoleName
- !Ref RoleName
- !Ref AWS::NoValue
Path: !Ref RolePath
Description: "SAML federated IAM role for SSO access with specified permissions"
MaxSessionDuration: !Ref RoleSessionDuration
PermissionsBoundary: !If
- HasPermissionsBoundary
- !Ref RolePermissionsBoundary
- !Ref AWS::NoValue
AssumeRolePolicyDocument:
Version: '2012-10-17 '
Statement:
- Effect: Allow
Principal:
Federated: !Ref SAMLProvider
Action:
- 'sts:AssumeRole'
- 'sts:SetSourceIdentity'
- 'sts:TagSession'
Condition:
StringEquals:
'SAML:aud': 'https://signin.aws.amazon.com/saml'
ManagedPolicyArns: !Split
- ','
- !Join
- ','
- - !If [HasPolicy1, !Ref RoleManagedPolicy1, !Ref "AWS::NoValue"]
- !If [HasPolicy2, !Ref RoleManagedPolicy2, !Ref "AWS::NoValue"]
- !If [HasPolicy3, !Ref RoleManagedPolicy3, !Ref "AWS::NoValue"]
- !If [HasPolicy4, !Ref RoleManagedPolicy4, !Ref "AWS::NoValue"]
- !If [HasPolicy5, !Ref RoleManagedPolicy5, !Ref "AWS::NoValue"]
Outputs:
RoleARN:
Description: ARN of the created IAM Role
Value: !GetAtt SAMLFederatedRole.Arn
Export:
Name: !Sub '${AWS::StackName}-RoleARN'
IdentityProviderARN:
Description: ARN of the created SAML Identity Provider
Value: !Ref SAMLProvider
Export:
Name: !Sub '${AWS::StackName}-IdentityProviderARN'
```
------