# Credenciais de segurança temporárias no IAM É possível usar o AWS Security Token Service (AWS STS) para criar e fornecer aos usuários confiáveis credenciais de segurança temporárias que podem controlar o acesso aos seus recursos da AWS. As credenciais de segurança temporárias funcionam quase de forma idêntica às credenciais de chave de acesso de longo prazo, com as seguintes diferenças: + As credenciais de segurança temporárias são de *curto prazo*, como o nome indica. Elas podem ser configuradas para durar de alguns minutos a várias horas. Depois que as credenciais expiram, a AWS não as reconhece mais ou permite qualquer tipo de acesso de solicitações de API feitas com elas. + As credenciais de segurança temporárias não são armazenadas com o usuário, mas são geradas dinamicamente e fornecidas ao usuário quando solicitadas. Quando (ou até mesmo antes) as credenciais de segurança temporárias expiram, o usuário pode solicitar novas credenciais, desde que o usuário solicitante ainda tenha permissões para fazê-lo. Como resultado, as credenciais temporárias apresentam as seguintes vantagens em relação às credenciais de longo prazo: + Você não tem que distribuir ou incorporar credenciais de segurança da AWS de longo prazo com um aplicativo. + É possível fornecer acesso aos seus recursos da AWS para os usuários sem a necessidade de definir uma identidade da AWS para eles. As credenciais temporárias são a base para [perfis](id_roles.md) e a [federação de identidades](id_roles_providers.md). + As credenciais de segurança temporárias têm vida limitada. Portanto, não é necessário atualizá-las ou explicitamente revogá-las quando elas não forem mais necessárias. Quando as credenciais de segurança temporárias expiram, elas não podem ser reutilizadas. É possível especificar por quanto tempo as credenciais são válidas, até um limite máximo. ## AWS STS e regiões da AWS Credenciais de segurança temporárias são geradas pelo AWS STS. Por padrão, o AWS STS é um serviço global com um único endpoint em `https://sts.amazonaws.com`. No entanto, você também pode optar por fazer chamadas de API do AWS STS para endpoints em qualquer outra região com suporte. Isso pode reduzir a latência (atraso do servidor), enviando as solicitações para servidores em uma região que está geograficamente mais perto de você. Não importa de qual região suas credenciais são, elas funcionam globalmente. Para obter mais informações, consulte [Gerenciar o AWS STS em uma Região da AWS](id_credentials_temp_enable-regions.md). ## Cenários comuns para credenciais temporárias As credenciais temporárias são úteis em cenários que envolvem federação de identidades, delegação, acesso entre contas e funções do IAM. ### Federação de identidades Você pode gerenciar suas identidades de usuários em um sistema externo fora da AWS e conceder acesso aos usuários que fazem login a partir desses sistemas para realizar tarefas da AWS e acessar seu recursos da AWS. O IAM é compatível com dois tipos de federação de identidades. Em ambos os casos, as identidades são armazenadas fora da AWS. A distinção é onde o sistema externo reside, em seu data center ou em um terceiro externo na Web. Para comparar os recursos das credenciais de segurança temporárias para federação de identidades, consulte [Compare credenciais do AWS STS](id_credentials_sts-comparison.md). Para obter mais informações sobre provedores de identidade externos, consulte [Federação e provedores de identidade na AWS](id_roles_providers.md). + **Federação OpenID Connect (OIDC)**: é possível permitir que os usuários iniciem sessão usando um provedor de identidade de terceiros conhecido, como Login with Amazon, Facebook, Google ou qualquer provedor compatível com o OIDC 2.0 para sua aplicação móvel ou Web. Não é necessário criar um código de início de sessão personalizado nem gerenciar suas próprias identidades de usuário. O uso da federação OIDC ajuda a manter sua Conta da AWS segura, pois você não precisa distribuir credenciais de segurança de longo prazo, como chaves de acesso de usuários do IAM, com a aplicação. Para obter mais informações, consulte [Federação OIDC](id_roles_providers_oidc.md). A federação OIDC do AWS STS oferece suporte a Login with Amazon, Facebook, Google e qualquer provedor de identidades compatível com OpenID Connect (OIDC). **nota** Para aplicações móveis, recomendamos o uso do Amazon Cognito. Você pode usar esse serviço com SDKs da AWS para desenvolvimento de dispositivos móveis para criar identidades exclusivas para os usuários e autenticá-las para acesso seguro aos recursos da AWS. O Amazon Cognito oferece suporte aos mesmos provedores de identidade do AWS STS e também oferece suporte ao acesso não autenticado (de convidado) e permite que você migre os dados do usuário quando um usuário faz login. O Amazon Cognito também fornece operações de API para sincronização de dados de usuário para que eles sejam preservados à medida que passarem de um dispositivo para outro. Para obter mais informações, consulte [Autenticação com o Amplify](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify) na *documentação do Amplify*. + **Federação SAML**: é possível autenticar usuários na rede da sua organização e, em seguida, fornecer a eles acesso à AWS sem criar novas identidades da AWS para eles nem exigir que façam login com credenciais de login diferentes. Isso é conhecido como a abordagem de *logon único* para acesso temporário. O AWS STS é compatível com padrões abertos, como o Security Assertion Markup Language (SAML) 2.0, com o qual você pode usar o Microsoft AD FS para utilizar seu Microsoft Active Directory. Você também pode usar o SAML 2.0 para gerenciar sua própria solução para federação de identidades de usuários. Para obter mais informações, consulte [Federação SAML 2.0](id_roles_providers_saml.md). + **Agente de federação personalizado**: você pode usar o sistema de autenticação da sua organização para conceder acesso aos recursos da AWS. Para obter um cenário de exemplo, consulte [Habilitar o acesso do intermediador de identidades personalizado ao console da AWS](id_roles_providers_enable-console-custom-url.md). + **Federação com SAML 2.0**: você pode usar o sistema de autenticação da sua organização e o SAML para conceder acesso aos recursos da AWS. Para obter mais informações e um cenário de exemplo, consulte [Federação SAML 2.0](id_roles_providers_saml.md). ### Funções para acesso entre contas Muitas organizações mantêm mais de uma Conta da AWS. Com o uso de funções e acesso entre contas, você pode definir identidades de usuários em uma conta e usar essas identidades para acessar recursos da AWS em outras contas que pertencem à sua organização. Isso é conhecido como a abordagem de *delegação* para acesso temporário. Para obter mais informações sobre a criação de funções entre contas, consulte [Criar um perfil para conceder permissões a um usuário do IAM](id_roles_create_for-user.md). 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). ### Funções do Amazon EC2 Se você executa aplicações em instâncias do Amazon EC2 e essas aplicações precisam de acesso a recursos da AWS, você pode fornecer credenciais de segurança temporárias para suas instâncias ao executá-las. Essas credenciais de segurança temporárias estão disponíveis para todos os aplicativos que são executados na instância, portanto você não precisa armazenar qualquer credencial de longo prazo na instância. Para obter mais informações, consulte [Use um perfil do IAM para conceder permissões a aplicações em execução em instâncias do Amazon EC2](id_roles_use_switch-role-ec2.md). Para saber mais sobre as credenciais de perfil do IAM do Amazon EC2, consulte [Perfis do IAM para Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) no *Guia do usuário do Amazon Elastic Compute Cloud*. ### Outros serviços da AWS Você pode usar credenciais de segurança temporárias para acessar a maioria dos serviços da AWS. Para obter uma lista dos serviços que aceitam credenciais de segurança temporárias, consulte [AWSServiços da que funcionam com o IAM](reference_aws-services-that-work-with-iam.md). ## Amostra de aplicações que usam credenciais temporárias É possível usar o AWS Security Token Service (AWS STS) para criar e fornecer aos usuários confiáveis credenciais de segurança temporárias que podem controlar o acesso aos seus recursos da AWS. Para obter mais informações sobre o AWS STS, consulte [Credenciais de segurança temporárias no IAM](#id_credentials_temp). Para ver como usar AWS STS para gerenciar credenciais de segurança temporárias, você pode fazer download dos seguintes exemplos de aplicativos que implementam exemplos de cenários completos: + [Habilitar a federação na AWS usando o Windows Active Directory, o ADFS e o SAML 2.0](https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/). Demonstra como delegar o acesso usando a federação corporativa na AWS usando Windows Active Directory (AD), Active Directory Federation Services (ADFS) 2.0 e SAML (Security Assertion Markup Language) 2.0. + [Habilitar o acesso do intermediador de identidades personalizado ao console da AWS](id_roles_providers_enable-console-custom-url.md). Demonstra como criar um proxy de federação personalizado que permite autenticação única (SSO) para que os usuários do Active Directory existentes possam iniciar sessão no Console de gerenciamento da AWS. + [Como usar o Shibboleth para autenticação única no Console de gerenciamento da AWS.](https://aws.amazon.com/blogs/security/how-to-use-shibboleth-for-single-sign-on-to-the-aws-management-console/). Mostra como usar o [Shibboleth](http://shibboleth.net/) e o [SAML](id_roles_providers_saml.md) para fornecer aos usuários logon único (SSO) ao Console de gerenciamento da AWS. ### Exemplos de federação OIDC Os exemplos de apliacações a seguir ilustram como usar a federação OIDC com provedores como Login with Amazon, Amazon Cognito, Facebook ou Google. Você pode trocar a autenticação desses provedores por credenciais de segurança temporárias da AWS para acessar serviços da AWS. + [Tutoriais do Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/tutorials.html): recomendamos que você use o Amazon Cognito com os AWS SDKs para desenvolvimento móvel. O Amazon Cognito é a maneira mais simples de gerenciar identidades para aplicativos móveis e fornece recursos adicionais como sincronização e identidade entre dispositivos. Para obter mais informações sobre o Amazon Cognito, consulte [Autenticação com o Amplify](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify) na *documentação do Amplify*. ## Recursos adicionais para credenciais de segurança temporárias Os seguintes cenários e aplicativos podem orientá-lo quanto ao uso de credenciais de segurança temporárias: + [Como integrar o AWS STS SourceIdentity ao seu provedor de identidade](https://aws.amazon.com/blogs/security/how-to-integrate-aws-sts-sourceidentity-with-your-identity-provider/). Esta postagem mostra como configurar o atributo do AWS STS `SourceIdentity` ao usar Okta, Ping ou OneLogin como IdP. + [Federação OIDC](id_roles_providers_oidc.md). Esta seção discute como configurar perfis do IAM ao usar federação OIDC e a API `AssumeRoleWithWebIdentity`. + [Acesso seguro à API com a MFA](id_credentials_mfa_configure-api-require.md). Este tópico explica como usar funções para exigir a autenticação multifator (MFA) para proteger ações de API confidenciais em sua conta. Para obter mais informações sobre políticas e permissões na AWS, consulte os seguintes tópicos: + [Gerenciamento de acesso para recursos da AWS](access.md) + [Lógica da avaliação de política](reference_policies_evaluation-logic.md). + [Gerenciar permissões de acesso aos seus recursos do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.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). # Compare credenciais do AWS STS A tabela a seguir compara os recursos das operações da API no AWS STS que retornam credenciais de segurança temporárias. Para saber mais sobre os diferentes métodos que você pode usar para solicitar credenciais de segurança temporárias ao assumir uma função, consulte [Métodos para assumir um perfil](id_roles_manage-assume.md). Para saber mais sobre as diferentes operações de API do AWS STS que permitem passar tags de sessão, consulte [Passar tags de sessão no AWS STS](id_session-tags.md). **nota** Você pode enviar chamadas de API do AWS STS para um endpoint global ou para um dos endpoints regionais. Se escolher um endpoint mais próximo a você, você poderá reduzir a latência e melhorar a performance de suas chamadas de API. Você também pode optar por direcionar suas chamadas para um endpoint regional alternativo se não puder mais se comunicar com o endpoint original. Se estiver usando um dos vários SDKs da AWS, use o método do respectivo SDK para especificar uma região antes de fazer a chamada de API. Se construir manualmente as solicitações de API HTTP, você deverá direcionar a solicitação para o endpoint correto. Para obter mais informações, consulte a seção [AWS STS de *Regiões e endpoints*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region) e [Gerenciar o AWS STS em uma Região da AWS](id_credentials_temp_enable-regions.md). | **API do AWS STS** | **Quem pode chamar** | **Vida útil da credencial (mín.\$1máx.\$1padrão)** | **Suporte a MFA**¹ | **Suporte à política de sessão**² | **Restrições nas credenciais temporárias resultantes** | | --- | --- | --- | --- | --- | --- | | [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) | Usuário do IAM ou função do IAM com credenciais de segurança temporárias existentes | 15 min \$1 Configuração de duração máxima da sessão³ \$1 1 h | Sim | Sim | Não pode chamar `GetFederationToken` ou `GetSessionToken`. | | [AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) | Todo chamador de usuário; deve passar uma resposta de autenticação de SAML que indica a autenticação de um provedor de identidade conhecido | 15 min \$1 Configuração de duração máxima da sessão³ \$1 1 h | Não | Sim | Não pode chamar `GetFederationToken` ou `GetSessionToken`. | | [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) | Qualquer usuário; o chamador deve passar um token JWT compatível com OIDC que indique a autenticação por um provedor de identidade conhecido | 15 min \$1 Configuração de duração máxima da sessão³ \$1 1 h | Não | Sim | Não pode chamar `GetFederationToken` ou `GetSessionToken`. | | [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) | Usuário do IAM ou Usuário raiz da conta da AWS | Usuário do IAM: 15 min \$1 36 h \$1 12 h Usuário raiz: 15 min \$1 1 h \$1 1 h | Não | Sim | Não é possível chamar operações do IAM usando a AWS CLI ou a API da AWS. Essa limitação não se aplica a sessões do console. Não é possível chamar operações do AWS STS, exceto `GetCallerIdentity`.⁴ Logon único para console é permitido.⁵ | | [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) | Usuário do IAM ou Usuário raiz da conta da AWS | Usuário do IAM: 15 min \$1 36 h \$1 12 h Usuário raiz: 15 min \$1 1 h \$1 1 h | Sim | Não | Não é possível chamar as operações da API do IAM, a menos que as informações da MFA sejam incluídas na solicitação. Não pode chamar as operações de API do AWS STS exceto `AssumeRole` ou `GetCallerIdentity`. Logon único para console não é permitido.⁶ | ¹ **Compatibildade com MFA**. Você pode incluir informações sobre um dispositivo de autenticação multifator (MFA) quando chamar as operações de API AssumeRole e GetSessionToken. Isso garante que as credenciais de segurança temporárias que resultam da chamada de API possam ser usadas somente pelos usuários que são autenticados com um dispositivo MFA. Para obter mais informações, consulte [Acesso seguro à API com a MFA](id_credentials_mfa_configure-api-require.md). ² **Suporte à política de sessão**. As políticas de sessão são políticas que você transmite como um parâmetro quando você cria de forma programática uma sessão temporária para uma sessão de usuário federado do AWS STS ou perfil. Esta política limita as permissões da política baseada em identidade da função ou do usuário que são atribuídas à sessão. As permissões da sessão resultam da interseção das políticas baseadas em identidade da entidade e das políticas de sessão. As políticas de sessão não podem ser usadas para conceder mais permissões do que as permitidas pela política baseada em identidade da função que está sendo assumida. Para obter mais informações sobre as permissões de sessão da função, consulte [Políticas de sessão](access_policies.md#policies_session). ³ **Configuração de duração máxima da sessão**. Use o parâmetro `DurationSeconds` para especificar a duração da sessão da função de 900 segundos (15 minutos) até o valor configurado de duração máxima da sessão para a função. Para saber como visualizar o valor máximo para sua função, consulte [Atualizar a duração máxima da sessão de um perfil](id_roles_update-role-settings.md#id_roles_update-session-duration). ⁴ **GetCallerIdentity**. Nenhuma permissão é necessária para executar essa operação. Se um administrador adicionar uma política ao seu usuário ou função do IAM que negue explicitamente o acesso à ação `sts:GetCallerIdentity`, você ainda poderá executar esta operação. As permissões não são necessárias porque as mesmas informações são retornadas quando um usuário ou uma função do IAM tem acesso negado. Para visualizar uma resposta de exemplo, consulte [Não estou autorizado a executar: iam:DeleteVirtualMFADevice](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa). ⁵ **Logon único (SSO) para o console**. Para dar suporte a SSO, a AWS permite chamar um endpoint da federação (`https://signin.aws.amazon.com/federation`) e passar credenciais de segurança temporárias. O endpoint retorna um token que pode ser usado para construir um URL que assina um usuário diretamente no console sem a necessidade de uma senha. 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) e [ Como habilitar o acesso entre contas ao Console de Gerenciamento da AWS](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) no Blog de segurança da AWS. ⁶ Depois de recuperar as credenciais temporárias, você não poderá acessar o Console de gerenciamento da AWS transmitindo as credenciais para o endpoint de logon único de federação. Para obter mais informações, consulte [Habilitar o acesso do intermediador de identidades personalizado ao console da AWS](id_roles_providers_enable-console-custom-url.md). # Tokens de portador de serviço Alguns serviços da AWS exigem que você tenha permissão para obter um token de portador do serviço AWS STS para poder acessar seus recursos de forma programática. Esses serviços são compatíveis com um protocolo que requer que você use um token de portador em vez de usar uma tradicional [AWS Signature Version 4 para solicitações de API](reference_sigv.md). Quando você executa operações da AWS CLI ou da API da AWS que exigem tokens de portador, o serviço da AWS solicita um token de portador em seu nome. O serviço fornece o token que você pode usar para executar operações subsequentes nesse serviço. AWS STSOs tokens de portador do serviço incluem informações de sua autenticação principal original que podem afetar suas permissões. Essas informações podem incluir tags de principal, tags de sessão e políticas de sessão. O ID de chave de acesso do token começa com o prefixo `ABIA`. Isso ajuda você a identificar operações que foram realizadas usando tokens de portador de serviço em seus logs do CloudTrail. **Importante** O token de portador pode ser usado apenas para chamadas ao serviço que o gera e na região onde ele foi gerado. Você não pode usar o token de portador para executar operações em outros serviços ou regiões. Um exemplo de serviço compatível com tokens de portador é o AWS CodeArtifact. Para poder interagir com o AWS CodeArtifact usando um gerenciador de pacotes, como NPM, Maven ou PIP, você deve chamar a operação `aws codeartifact get-authorization-token`. Essa operação retorna um token de portador que você pode usar para executar operações do AWS CodeArtifact. Como alternativa, você pode usar o comando `aws codeartifact login` que conclui a mesma operação e configura seu cliente automaticamente. Para executar uma ação em um serviço da AWS que gera um token de portador para você, você deverá ter as seguintes permissões em sua política do IAM: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowServiceBearerToken", "Effect": "Allow", "Action": "sts:GetServiceBearerToken", "Resource": "*" } ] } ``` ------ Para obter um exemplo de token de portador do serviço, consulte [Usar políticas baseadas em identidade para o AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/auth-and-access-control-iam-identity-based-access-control.html) no *Guia do usuário do AWS CodeArtifact*. # Solicitar credenciais de segurança temporárias Para solicitar credenciais de segurança temporárias, você pode usar as operações do AWS Security Token Service (AWS STS) na API da AWS. É possível usar operações para criar e fornecer aos usuários confiáveis credenciais de segurança temporárias que podem controlar o acesso aos seus recursos da AWS. Para obter mais informações sobre o AWS STS, consulte [Credenciais de segurança temporárias no IAM](id_credentials_temp.md). Para saber mais sobre os diferentes métodos que você pode usar para solicitar credenciais de segurança temporárias ao assumir uma função, consulte [Métodos para assumir um perfil](id_roles_manage-assume.md). Para chamar as operações de API, você pode usar um dos [AWS SDKs](https://aws.amazon.com/tools/). Os SDKs estão disponíveis para uma grande variedade de ambientes e linguagens de programação, incluindo Java, .NET, Python, Ruby, Android e iOS. Os SDKs processam tarefas como a assinatura criptográfica de suas solicitações, a solicitação de novas tentativas (se necessário) e o tratamento das respostas de erro. Você também pode usar a API de consulta do AWS STS, descrita na [Referência de API do AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/). Por fim, duas ferramentas de linha de comando são suporte aos comandos do AWS STS: a [AWS Command Line Interface](https://aws.amazon.com/documentation/cli) e o [AWS Tools for Windows PowerShell](https://aws.amazon.com/documentation/powershell). As operações da API do AWS STS criam uma nova sessão com credenciais de segurança temporárias que incluem um par de chaves de acesso e um token de sessão. O par de chaves de acesso consiste em um ID de chave de acesso e uma chave secreta. Os usuários (ou um aplicativo que o usuário executa) pode usar essas credenciais para acessar seus recursos. Você pode criar uma sessão de função e aprovar políticas e tags de sessão programaticamente usando operações de API do AWS STS. As permissões de sessão resultante são a interseção das políticas baseadas em identidade da função e das políticas de sessão. Para obter mais informações sobre políticas de sessão, consulte [Políticas de sessão](access_policies.md#policies_session). Para obter mais informações sobre tags de sessão, consulte [Passar tags de sessão no AWS STS](id_session-tags.md). **nota** O tamanho do token de sessão que as operações de API do AWS STS retornam não é fixo. É altamente recomendável que você não faça suposições sobre o tamanho máximo. O tamanho típico do token é menos de 4096 bytes, mas pode variar. ## Uso do AWS STS com regiões da AWS Você pode enviar chamadas de API do AWS STS para um endpoint global ou para um dos endpoints regionais. Se escolher um endpoint mais próximo a você, você poderá reduzir a latência e melhorar a performance de suas chamadas de API. Você também pode optar por direcionar suas chamadas para um endpoint regional alternativo se não puder mais se comunicar com o endpoint original. Se estiver usando um dos vários SDKs da AWS, use o método do respectivo SDK para especificar uma região antes de fazer a chamada de API. Se construir manualmente as solicitações de API HTTP, você deverá direcionar a solicitação para o endpoint correto. Para obter mais informações, consulte a seção [AWS STS de *Regiões e endpoints*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region) e [Gerenciar o AWS STS em uma Região da AWS](id_credentials_temp_enable-regions.md). A seguir veja as operações de API que podem ser usadas para adquirir credenciais temporárias para o uso em seu ambiente e aplicativos da AWS. ## Solicitar credenciais para delegação e federação entre contas por meio de um intermediador de identidades personalizado A operação da API [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html) é útil para permitir que os usuários existentes do IAM acessem os recursos da AWS aos quais eles ainda não têm acesso. Por exemplo, o usuário pode precisar de acesso a recursos em outra Conta da AWS. Ela também é útil como um meio de obter acesso privilegiado temporariamente, por exemplo, para fornecer uma autenticação multifator (MFA). Você deve chamar essa API usando credenciais ativas. Para saber quem pode chamar essa operação, consulte [Compare credenciais do AWS STS](id_credentials_sts-comparison.md). Para obter mais informações, consulte [Criar um perfil para conceder permissões a um usuário do IAM](id_roles_create_for-user.md) e [Acesso seguro à API com a MFA](id_credentials_mfa_configure-api-require.md). **Para solicitar credenciais de segurança temporárias para delegação e federação entre contas por meio de um intermediador de identidades personalizado** 1. Autentique-se com suas credenciais de segurança da AWS. Essa chamada deve ser feita usando credenciais de segurança da AWS válidas. 1. Chame a operação [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html). O exemplo a seguir mostra uma solicitação e resposta de exemplo usando `AssumeRole`. Este exemplo de solicitação assume a função `demo` para a duração especificada com a [política de sessão](access_policies.md#policies_session) incluída, [etiquetas de sessão](id_session-tags.md), [ID externo](id_roles_common-scenarios_third-party.md) e [identidade-fonte](id_credentials_temp_control-access_monitor.md). A sessão resultante é nomeada `John-session`. **Example Exemplo de solicitação** ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=AssumeRole &RoleSessionName=John-session &RoleArn=arn:aws::iam::123456789012:role/demo &Policy=%7B%22Version%22%3A%222012-10-17 %22%2C%22Statement%22%3A%5B%7B%22Sid%22%3A%20%22Stmt1%22%2C%22Effect%22%3A%20%22Allow%22%2C%22Action%22%3A%20%22s3%3A*%22%2C%22Resource%22%3A%20%22*%22%7D%5D%7D &DurationSeconds=1800 &Tags.member.1.Key=Project &Tags.member.1.Value=Pegasus &Tags.member.2.Key=Cost-Center &Tags.member.2.Value=12345 &ExternalId=123ABC &SourceIdentity=DevUser123 &AUTHPARAMS ``` O valor da política mostrado no exemplo anterior é a versão codificada por URL da seguinte política: ------ #### [ JSON ] **** ``` {"Version":"2012-10-17", "Statement":[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:*","Resource":"*"}]} ``` ------ O parâmetro `AUTHPARAMS` no exemplo é um espaço reservado para a sua *assinatura*. Uma assinatura é a informação de autenticação que você deve incluir com as solicitações de API HTTP da AWS. Recomendamos usar os [SDKs da AWS](https://aws.amazon.com/tools/) para criar solicitações de API. Um dos benefícios de se fazer isso é que os SDKs tratam da assinatura das solicitações por você. Se você tiver que criar e assinar as solicitações de API manualmente, acesse [Assinaturas e solicitações da AWS usando o Signature versão 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) no *Referência geral da Amazon Web Services* para saber como assinar uma solicitação. Além das credenciais de segurança temporárias, a resposta inclui o nome de recurso da Amazon (ARN) para o usuário federado e o tempo de expiração das credenciais. **Example Exemplo de resposta** ``` DevUser123 AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU 9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCR/oLxBA== wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY 2019-07-15T23:28:33.359Z AKIAIOSFODNN7EXAMPLE arn:aws:sts::123456789012:assumed-role/demo/John ARO123EXAMPLE123:John 8 c6104cbe-af31-11e0-8154-cbc7ccf896c7 ``` **nota** Uma conversão da AWS compacta as políticas de sessão e as tags de sessão passadas em um formato binário compactado que têm um limite separado. Sua solicitação pode falhar para esse limite mesmo que seu texto simples atenda aos outros requisitos. O elemento de resposta `PackedPolicySize` indica, em porcentagem, o quão perto as políticas e tags da sua solicitação estão do limite de tamanho superior. ## Solicitar credenciais por meio de um provedor OIDC A operação da API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) retorna um conjunto de credenciais de segurança temporárias da AWS em troca de um JSON Web Token (JWT). Isso inclui provedores de identidade públicos, como Login with Amazon, Facebook, Google e provedores que emitem JWTs compatíveis com a descoberta do OpenID Connect (OIDC), como GitHub Actions ou Azure DevOps. Para obter mais informações, consulte [Federação OIDC](id_roles_providers_oidc.md). **nota** As solicitações `AssumeRoleWithWebIdentity` não são assinadas com as credenciais da AWS nem as exigem. **Solicitar credenciais por meio de um provedor OIDC** 1. Chame a operação [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html). Quando você chama `AssumeRoleWithWebIdentity`, a AWS valida o token apresentado verificando a assinatura digital usando chaves públicas disponibilizadas por meio do conjunto de chaves da Web JSON (JWKS) do seu IdP. Se o token for válido e todas as condições estabelecidas na política de confiança do perfil do IAM forem atendidas, a AWS retornará as seguintes informações para você: + Um conjunto de credenciais de segurança temporárias. Elas consistem em um ID de chave de acesso, chave de acesso secreta e um token de sessão. + O ID da função e o ARN da função assumida. + Um valor `SubjectFromWebIdentityToken` que contém o ID de usuário exclusivo. 1. A aplicação pode então usar as credenciais de segurança temporárias que foram retornadas na resposta para fazer chamadas de API da AWS. Esse é o mesmo processo de fazer uma chamada de API da AWS com credenciais de segurança de longo prazo. A diferença é que você deve incluir o token de sessão, o que permite que a AWS verifique se as credenciais de segurança temporárias são válidas. A aplicação deve armazenar em cache as credenciais retornadas pelo AWS STS e atualizá-las conforme necessário. Se a aplicação foi criada usando um AWS SDK, ele tem provedores de credenciais que podem lidar com as chamadas `AssumeRoleWithWebIdentity` e a atualização de credenciais da AWS antes que elas expirem. Para obter mais informações, consulte [AWS SDKs and Tools standardized credential providers](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html) no *Guia de referência de ferramentas e SDKs da AWS*. ## Solicitar credenciais por meio de um provedor de identidades SAML 2.0 A operação de API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) retorna um conjunto de credenciais de segurança temporárias para entidades principais federadas SAML que são autenticadas pelo sistema de identidade existente da sua organização. Os usuários também devem usar [SAML](https://www.oasis-open.org/standards#samlv2.0) 2.0 (Security Assertion Markup Language) para passar informações de autenticação e autorização para a AWS. Esta operação de API é útil em organizações que integraram seus sistemas de identidade (como o Windows Active Directory ou OpenLDAP) a um software que pode produzir declarações em SAML. Essa integração fornece informações sobre a identidade e as permissões do usuário (como o Active Directory Federation Services ou o Shibboleth). Para obter mais informações, consulte [Federação SAML 2.0](id_roles_providers_saml.md). 1. Chame a operação [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html). Essa é uma chamada não assinada, o que significa que você não precisa autenticar as credenciais de segurança da AWS antes de fazer a solicitação. **nota** Uma chamada para `AssumeRoleWithSAML` não é assinada (criptografada). Portanto, você deve incluir somente as políticas de sessão opcionais se a solicitação é transmitida por meio de um intermediário de confiança. Nesse caso, alguém poderia alterar a política para remover as restrições. 1. Quando você chama `AssumeRoleWithSAML`, a AWS verifica a autenticidade da declaração do SAML. Supondo que o provedor de identidade valide a declaração, a AWS retorna as seguintes informações: + Um conjunto de credenciais de segurança temporárias. Elas consistem em um ID de chave de acesso, chave de acesso secreta e um token de sessão. + O ID da função e o ARN da função assumida. + Um valor `Audience` que contém o valor do atributo `Recipient` do elemento `SubjectConfirmationData` da declaração do SAML. + Um valor `Issuer` que contém o valor do o elemento `Issuer` da declaração do SAML. + Um elemento `NameQualifier` que contém um valor de hash criado a partir do valor `Issuer`, o ID da Conta da AWS e o nome amigável do provedor de SAML. Quando combinado com o elemento `Subject`, eles podem identificar exclusivamente a entidade principal federada SAML. + Um elemento `Subject` que contém o valor do elemento `NameID` no elemento `Subject` da declaração do SAML. + Um elemento `SubjectType` que indica o formato do elemento `Subject`. O valor pode ser `persistent`, `transient`ou o URI `Format` completo dos elementos `Subject` e `NameID` usados em sua declaração do SAML. Para obter mais informações sobre o atributo `NameID` do elemento `Format`, consulte [Configurar declarações SAML para a resposta de autenticação](id_roles_providers_create_saml_assertions.md). 1. Use as credenciais de segurança temporárias devolvidas na resposta para fazer chamadas de API da AWS. Esse é o mesmo processo de fazer uma chamada de API da AWS com credenciais de segurança de longo prazo. A diferença é que você deve incluir o token de sessão, o que permite que a AWS verifique se as credenciais de segurança temporárias são válidas. Seu aplicativo deve armazenar as credenciais em cache. Por padrão, as credenciais expiram após uma hora. Se você não estiver usando a ação [AmazonSTSCredentialsProvider](https://aws.amazon.com/blogs/mobile/using-the-amazoncredentialsprovider-protocol-in-the-aws-sdk-for-ios) no SDK da AWS, caberá a você e ao seu aplicativo chamar `AssumeRoleWithSAML` novamente. Chame esta operação para obter um novo conjunto de credenciais de segurança temporárias antes que as antigas expirem. ## Solicitar credenciais por meio de um intermediador de identidades personalizado A operação de API [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) retorna um conjunto de credenciais de segurança temporárias para usuários federados do AWS STS. A API é diferente de `AssumeRole`, em que o período de expiração padrão é significativamente maior (até 12 horas, em vez de 1 hora). Além disso, você pode usar o parâmetro `DurationSeconds` para especificar uma duração para que as credenciais de segurança temporárias permaneçam válidas. As credenciais resultantes são válidas pela duração especificada, de 900 segundos (15 minutos) até 129.600 segundos (36 horas). O período de expiração maior pode ajudar a reduzir o número de chamadas para a AWS porque você não precisa obter novas credenciais com a mesma frequência. 1. Faça a autenticação com as credenciais de segurança da AWS do seu usuário do IAM específico. Essa chamada deve ser feita usando credenciais de segurança da AWS válidas. 1. Chame a operação [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html). A chamada `GetFederationToken` retorna credenciais de segurança temporárias que consistem em um token de segurança, chave de acesso, chave secreta e expiração. Você pode usar `GetFederationToken` se deseja gerenciar permissões dentro de sua organização (por exemplo, usando o aplicativo de proxy para atribuir permissões). O exemplo a seguir mostra uma solicitação e resposta de exemplo que usa `GetFederationToken`. Esta solicitação de exemplo agrupa o usuário de chamada pela duração especificada ao ARN da [política de sessão](access_policies.md#policies_session) e às [tags de sessão](id_session-tags.md). A sessão resultante é nomeada `Jane-session`. **Example Exemplo de solicitação** ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=GetFederationToken &Name=Jane-session &PolicyArns.member.1.arn==arn%3Aaws%3Aiam%3A%3A123456789012%3Apolicy%2FRole1policy &DurationSeconds=1800 &Tags.member.1.Key=Project &Tags.member.1.Value=Pegasus &Tags.member.2.Key=Cost-Center &Tags.member.2.Value=12345 &AUTHPARAMS ``` O ARN da política mostrado no exemplo anterior inclui o seguinte ARN codificado em URL: `arn:aws:iam::123456789012:policy/Role1policy` Além disso, observe que o parâmetro `&AUTHPARAMS` no exemplo destina-se a ser o espaço reservado para as informações de autenticação. Esta é a *assinatura*, que é necessário incluir às solicitações de API HTTP da AWS. Recomendamos usar os [SDKs da AWS](https://aws.amazon.com/tools/) para criar solicitações de API. Um dos benefícios de se fazer isso é que os SDKs tratam da assinatura das solicitações por você. Se você tiver que criar e assinar as solicitações de API manualmente, acesse [Assinaturas e solicitações da AWS usando o Signature versão 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) no *Referência geral da Amazon Web Services* para saber como assinar uma solicitação. Além das credenciais de segurança temporárias, a resposta inclui o nome de recurso da Amazon (ARN) para o usuário federado e o tempo de expiração das credenciais. **Example Exemplo de resposta** ``` AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU 9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCEXAMPLE== wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY 2019-04-15T23:28:33.359Z AKIAIOSFODNN7EXAMPLE; arn:aws:sts::123456789012:federated-user/Jean 123456789012:Jean 4 c6104cbe-af31-11e0-8154-cbc7ccf896c7 ``` **nota** Uma conversão da AWS compacta as políticas de sessão e as tags de sessão passadas em um formato binário compactado que têm um limite separado. Sua solicitação pode falhar para esse limite mesmo que seu texto simples atenda aos outros requisitos. O elemento de resposta `PackedPolicySize` indica, em porcentagem, o quão perto as políticas e tags da sua solicitação estão do limite de tamanho superior. A AWS recomenda que você conceda permissões no nível do recurso (por exemplo, você anexa uma política baseada em recurso a um bucket do Amazon S3). Você pode omitir o parâmetro `Policy`. No entanto, se você não incluir uma política para a entidade principal do usuário federado do AWS STS, as credenciais de segurança temporárias não concederão permissões. Neste caso, você *deve* usar as políticas de recurso para conceder ao usuário federado o acesso aos seus recursos da AWS. Por exemplo, suponha que o número da sua Conta da AWS seja 111122223333 e você tenha um bucket do Amazon S3 que deseja permitir que Susan acesse. As credenciais de segurança temporárias da Susan não incluem uma política para o bucket. Nesse caso, é necessário certificar-se de que o bucket tem uma política com um ARN que corresponde ao de Susan, como `arn:aws:sts::111122223333:federated-user/Susan`. ## Solicitar credenciais para usuários em ambientes não confiáveis A operação da API [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) retorna um conjunto de credenciais de segurança temporárias para um usuário do IAM existente. Ela é útil para fornecer segurança aprimorada, como, por exemplo, permitir solicitações da AWS somente quando a MFA estiver habilitada para o usuário do IAM. Como as credenciais são temporárias, elas fornecem segurança aprimorada quando você tem um usuário do IAM que acessa seus recursos por meio de um ambiente menos seguro. Exemplos de ambientes menos seguros incluem um dispositivo móvel ou navegador da web. 1. Faça a autenticação com as credenciais de segurança da AWS do seu usuário do IAM específico. Essa chamada deve ser feita usando credenciais de segurança da AWS válidas. 1. Chame a operação [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html). 1. `GetSessionToken` retorna as credenciais de segurança temporárias que consistem em um token de sessão, um ID de chave de acesso e uma chave de acesso secreta. Por padrão, as credenciais de segurança temporárias de um usuário do IAM são válidas por no máximo 12 horas. Mas você pode solicitar uma duração de, no mínimo, 15 minutos ou, no máximo, 36 horas usando o parâmetro `DurationSeconds`. Por motivos de segurança, um token para um Usuário raiz da conta da AWS é restrito a uma hora de duração. O exemplo a seguir mostra uma solicitação e resposta de exemplo usando `GetSessionToken`. A resposta também inclui o tempo de expiração das credenciais de segurança temporárias. **Example Exemplo de solicitação** ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=GetSessionToken &DurationSeconds=1800 &AUTHPARAMS ``` O parâmetro `AUTHPARAMS` no exemplo é um espaço reservado para a sua *assinatura*. Uma assinatura é a informação de autenticação que você deve incluir com as solicitações de API HTTP da AWS. Recomendamos usar os [SDKs da AWS](https://aws.amazon.com/tools/) para criar solicitações de API. Um dos benefícios de se fazer isso é que os SDKs tratam da assinatura das solicitações por você. Se você tiver que criar e assinar as solicitações de API manualmente, acesse [Assinaturas e solicitações da AWS usando o Signature versão 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) no *Referência geral da Amazon Web Services* para saber como assinar uma solicitação. **Example Exemplo de resposta** ``` AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/L To6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3z rkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtp Z3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY 2011-07-11T19:55:29.611Z AKIAIOSFODNN7EXAMPLE 58c5dbae-abef-11e0-8cfe-09039844ac7d ``` Opcionalmente, a solicitação `GetSessionToken` pode incluir os valores `SerialNumber` e `TokenCode` para a verificação da autenticação multifator (MFA) da AWS. Se os valores fornecidos forem válidos, o AWS STS fornecerá credenciais de segurança temporárias que incluem o estado da autenticação MFA. As credenciais de segurança temporárias podem ser usadas para acessar as operações de API protegidas por MFA ou os sites da AWS pelo tempo em que a autenticação MFA for válida. O exemplo a seguir mostra uma solicitação `GetSessionToken` que inclui um código de verificação de MFA e número de série do dispositivo. ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=GetSessionToken &DurationSeconds=7200 &SerialNumber=YourMFADeviceSerialNumber &TokenCode=123456 &AUTHPARAMS ``` **nota** A chamada para o AWS STS pode ser para o endpoint global ou para qualquer um dos endpoints regionais para os quais você ativar sua Conta da AWS. Para obter mais informações, consulte a [seção do AWS STS de *Regiões e endpoints*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region). O parâmetro `AUTHPARAMS` no exemplo é um espaço reservado para a sua *assinatura*. Uma assinatura é a informação de autenticação que você deve incluir com as solicitações de API HTTP da AWS. Recomendamos usar os [SDKs da AWS](https://aws.amazon.com/tools/) para criar solicitações de API. Um dos benefícios de se fazer isso é que os SDKs tratam da assinatura das solicitações por você. Se você tiver que criar e assinar as solicitações de API manualmente, acesse [Assinaturas e solicitações da AWS usando o Signature versão 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) no *Referência geral da Amazon Web Services* para saber como assinar uma solicitação. # Usar credenciais temporárias com recursos da AWS Você pode usar credenciais de segurança temporárias para fazer solicitações programáticas de recursos da AWS usando a AWS CLI ou API da AWS (usando os [SDKs da AWS](https://aws.amazon.com/tools/)). As credenciais temporárias fornecem as mesmas permissões que as credenciais de segurança de longo prazo, como as credenciais de usuário do IAM. No entanto, há algumas diferenças: + Ao fazer uma chamada usando credenciais de segurança temporárias, ela deve incluir um token de sessão, que é retornado junto com essas credenciais temporárias. O AWS usa o token de sessão para validar as credenciais de segurança temporárias. + As credenciais temporárias expiram após um intervalo especificado. Após a expiração das credenciais temporárias, ocorrerá falha em todas as chamadas que você fizer com essas credenciais, portanto, você deve gerar um novo conjunto de credenciais temporárias. As credenciais temporárias não podem ser estendidas nem renovadas além do intervalo original especificado. + Ao usar credenciais temporárias para fazer uma solicitação, seu principal pode incluir um conjunto de tags. Essas tags vêm de tags de sessão e tags anexadas à função que você assume. Para obter mais informações sobre tags de sessão, consulte [Passar tags de sessão no AWS STS](id_session-tags.md). Se você usar os [SDKs da AWS](https://aws.amazon.com/tools), a [AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/) (AWS CLI) ou o [Tools for Windows PowerShell](https://aws.amazon.com/powershell), a maneira de obter e usar credenciais de segurança temporárias será diferente conforme o contexto. Se você estiver executando código, comandos da AWS CLI ou do Tools for Windows PowerShell em uma instância do EC2, poderá aproveitar as funções do Amazon EC2. Caso contrário, é possível chamar uma [API do AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/) para obter as credenciais temporárias e, em seguida, usá-las explicitamente para fazer chamadas de serviços da AWS. **nota** É possível usar o AWS Security Token Service (AWS STS) para criar e fornecer aos usuários confiáveis credenciais de segurança temporárias que podem controlar o acesso aos seus recursos da AWS. Para obter mais informações sobre o AWS STS, consulte [Credenciais de segurança temporárias no IAM](id_credentials_temp.md). AWS STS é um serviço global que tem um endpoint padrão em `https://sts.amazonaws.com`. Esse endpoint fica na região Leste dos EUA (N. da Virgínia)), embora as credenciais obtidas desse e de outros endpoints sejam válidas globalmente. Essas credenciais funcionam com serviços e recursos em qualquer região. Você também pode optar por fazer chamadas de API do AWS STS para endpoints em qualquer uma das regiões com suporte. Isso pode reduzir a latência fazendo as solicitações de servidores em uma região que está geograficamente mais perto de você. Não importa de qual região suas credenciais são, elas funcionam globalmente. Para obter mais informações, consulte [Gerenciar o AWS STS em uma Região da AWS](id_credentials_temp_enable-regions.md). **Contents** + [Uso de credenciais temporárias em instâncias do Amazon EC2](#using-temp-creds-sdk-ec2-instances) + [Uso de credenciais de segurança temporárias com os AWS SDKs](#using-temp-creds-sdk) + [Uso de credenciais de segurança temporárias com a AWS CLI](#using-temp-creds-sdk-cli) + [Uso de credenciais de segurança temporárias com operações de API](#RequestWithSTS) + [Mais informações](#using-temp-creds-more-info) ## Uso de credenciais temporárias em instâncias do Amazon EC2 Se você deseja executar comandos da AWS CLI ou código dentro de uma instância do EC2, a forma recomendada de obter credenciais é usar [funções para o Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html). Você cria uma função do IAM que especifica as permissões a serem concedidas a aplicações em execução nas instâncias do EC2. Ao executar a instância, você associa a função à instância. Aplicações, a AWS CLI e comandos do Tools for Windows PowerShell executados na instância podem, então, obter credenciais de segurança temporárias automáticas dos metadados da instância. Você não precisa obter explicitamente as credenciais de segurança temporárias. Os AWS SDKs, a AWS CLI e as Tools for Windows PowerShell obtêm automaticamente as credenciais do serviço de metadados da instância (IMDS) do EC2 e as utilizam. As credenciais temporárias têm as permissões que você define para a função que está associada à instância. Para obter mais informações e exemplos, veja a seguir: + [Usar funções do IAM para conceder acesso a recursos da AWS no Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) — AWS SDK para Java + [Conceder acesso utilizando uma função do IAM](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-hosm.html) — AWS SDK para .NET + [Criar uma função](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/iam-example-create-role.html): AWS SDK para Ruby ## Uso de credenciais de segurança temporárias com os AWS SDKs Para usar credenciais de segurança temporárias em código, você chama programaticamente uma API do AWS STS como `AssumeRole` e extrai as credenciais resultantes e o token de sessão. Depois, use esses valores como credenciais em chamadas subsequentes para a AWS. O exemplo a seguir mostra o pseudocódigo de como usar credenciais de segurança temporárias se você estiver usando um SDK da AWS: ``` assumeRoleResult = AssumeRole(role-arn); tempCredentials = new SessionAWSCredentials( assumeRoleResult.AccessKeyId, assumeRoleResult.SecretAccessKey, assumeRoleResult.SessionToken); s3Request = CreateAmazonS3Client(tempCredentials); ``` Para obter um exemplo escrito em Python (usando o [AWS SDK para Python (Boto)](https://aws.amazon.com/sdk-for-python/)), consulte [Alternar para um perfil do IAM (API da AWS)](id_roles_use_switch-role-api.md). Este exemplo mostra como chamar `AssumeRole` para obter credenciais de segurança temporárias e usar essas credenciais para fazer uma chamada para o Amazon S3. Para obter detalhes sobre como chamar `AssumeRole`, `GetFederationToken` e outras operações de API, consulte a [Referência da API do AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/). Para obter informações sobre como obter as credenciais de segurança temporárias e o token de sessão provenientes do resultado, consulte a documentação do SDK com o qual você está trabalhando. Você pode encontrar a documentação de todos os AWS SDKs na principal [página da documentação da AWS](https://aws.amazon.com/documentation), na seção **SDKs e toolkits**. É necessário obter um novo conjunto de credenciais antes que o antigo expire. Em alguns SDKs, você pode usar um provedor que gerencie o processo de atualização de credenciais para você; verifique a documentação do SDK que você está usando. ## Uso de credenciais de segurança temporárias com a AWS CLI Você pode usar credenciais de segurança temporárias com a AWS CLI. Isso pode ser útil para testar políticas. Usando a [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/), você pode chamar uma [API do AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/) como `AssumeRole` ou `GetFederationToken` e, depois capturar os resultados gerados. O exemplo a seguir mostra uma chamada para `AssumeRole` que envia a saída para um arquivo. No exemplo, o parâmetro `profile` é considerado um perfil no arquivo de configuração da AWS CLI. Ele também é considerado como referência às credenciais de um usuário do IAM que tem permissões para assumir a função. ``` aws sts assume-role --role-arn arn:aws:iam::123456789012:role/role-name --role-session-name "RoleSession1" --profile IAM-user-name > assume-role-output.txt ``` Quando o comando for concluído, você poderá extrair o ID de chave de acesso, a chave de acesso secreta e o token de sessão de onde quer que você o tenha roteado. Você pode fazer isso manualmente ou usando um script. Em seguida, você pode atribuir esses valores a variáveis do ambiente. Quando você executa comandos da AWS CLI, a AWS CLI procura as credenciais em uma ordem específica – primeiro em variáveis do ambiente e, em seguida, no arquivo de configuração. Portanto, depois de colocar as credenciais temporárias em variáveis do ambiente, a AWS CLI usa essas credenciais por padrão. (Se você especificar um parâmetro `profile` no comando, a AWS CLI ignorará as variáveis de ambiente. Em vez disso, a AWS CLI procurará no arquivo de configuração, que permite substituir as credenciais nas variáveis de ambiente, se necessário.) O exemplo a seguir mostra como definir as variáveis do ambiente para credenciais de segurança temporárias e, em seguida, chamar um comando da AWS CLI. Como nenhum parâmetro `profile` está incluído no comando da AWS CLI, a AWS CLI procura credenciais primeiro em variáveis do ambiente e depois usa as credenciais temporárias. **Linux** ``` $ export AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE $ export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY $ export AWS_SESSION_TOKEN=AQoDYXdzEJr... $ aws ec2 describe-instances --region us-west-1 ``` **Windows** ``` C:\> SET AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE C:\> SET AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY C:\> SET AWS_SESSION_TOKEN=AQoDYXdzEJr... C:\> aws ec2 describe-instances --region us-west-1 ``` ## Uso de credenciais de segurança temporárias com operações de API Se estiver fazendo solicitações de API de HTTPS diretas à AWS, será possível assinar essas solicitações com as credenciais de segurança temporárias obtidas do AWS Security Token Service (AWS STS). Para isso, você pode usar o ID de chave de acesso e a chave de acesso secreta recebidos do AWS STS. Use o ID da chave de acesso e a chave de acesso secreta do mesmo modo que você usaria credenciais de longo prazo para assinar uma solicitação. Você também adiciona à sua solicitação de API o token de sessão que você recebe do AWS STS. Você adiciona o token de sessão a um cabeçalho HTTP ou a um parâmetro de string de consulta denominado `X-Amz-Security-Token`. Você adiciona o token de sessão ao cabeçalho HTTP *ou* ao parâmetro de string de consulta, mas não a ambos. Para obter mais informações sobre como assinar solicitações da API HTTPS, consulte [Como assinar solicitações de API da AWS](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html) na *Referência geral da AWS*. ## Mais informações Para obter mais informações sobre como usar o AWS STS com outros produtos da AWS, consulte os seguintes links: + **Amazon S3**. Consulte [Fazer solicitações usando credenciais temporárias de usuário do IAM](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempSessionToken.html) ou [Fazer solicitações usando credenciais temporárias de usuário federado](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempFederationToken.html), no *Guia do usuário do Amazon Simple Storage Service*. + **Amazon SNS**. Consulte [Usar políticas baseadas em identidade com o Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#UsingTemporarySecurityCredentials_SNS), no *Guia do desenvolvedor do Amazon Simple Notification Service*. + **Amazon SQS**. Consulte [Gerenciamento de identidade e acesso no Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/UsingIAM.html#UsingTemporarySecurityCredentials_SQS) no *Guia do desenvolvedor do Amazon Simple Queue Service*. + **Amazon SimpleDB**. Consulte [Usar credenciais de segurança temporárias](https://docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/index.html?UsingTemporarySecurityCredentials_SDB.html) no *Guia do desenvolvedor do Amazon SimpleDB*. # Permissões de credenciais de segurança temporárias É possível usar o AWS Security Token Service (AWS STS) para criar e fornecer aos usuários confiáveis credenciais de segurança temporárias que podem controlar o acesso aos seus recursos da AWS. Para obter mais informações sobre o AWS STS, consulte [Credenciais de segurança temporárias no IAM](id_credentials_temp.md). Assim que o AWS STS emite credenciais de segurança temporárias, elas são válidas durante o período de expiração e não podem ser revogadas. No entanto, as permissões atribuídas a credenciais de segurança temporárias são avaliadas todas as vezes que uma solicitação é feita usando as credenciais, portanto você pode atingir o resultado da revogação de credenciais alterando seus direitos de acesso depois que elas forem emitidas. Os tópicos a seguir presumem que você tenha conhecimento das permissões e políticas da AWS. Para mais informações sobre esses tópicos, consulte [Gerenciamento de acesso para recursos da AWS](access.md). **Topics** + [Permissões para AssumeRole, AssumeRoleWithSAML e AssumeRoleWithWebIdentity](id_credentials_temp_control-access_assumerole.md) + [Monitorar e controlar ações realizadas com funções assumidas](id_credentials_temp_control-access_monitor.md) + [Permissões para GetFederationToken](id_credentials_temp_control-access_getfederationtoken.md) + [Permissões para GetSessionToken](id_credentials_temp_control-access_getsessiontoken.md) + [Desabilitar permissões de credenciais de segurança temporárias](id_credentials_temp_control-access_disable-perms.md) + [Conceder permissões para criar credenciais de segurança temporárias](id_credentials_temp_control-access_enable-create.md) + [Concessão de permissões para o uso de sessões de console aprimoradas com identidade](id_credentials_temp_control-access_sts-setcontext.md) # Permissões para AssumeRole, AssumeRoleWithSAML e AssumeRoleWithWebIdentity A política de permissões da função que está sendo assumida determina as permissões para as credenciais de segurança temporárias retornadas por `AssumeRole`, `AssumeRoleWithSAML` e `AssumeRoleWithWebIdentity`. Você define essas permissões quando cria ou atualiza uma função. Você também pode transmitir as [políticas de sessão](access_policies.md#policies_session) gerenciadas ou em linha como parâmetros das operações de API `AssumeRole`, `AssumeRoleWithWebIdentity` ou `AssumeRoleWithSAML`. As políticas de sessão limitam as permissões para a sessão de credencial temporária da função. As permissões da sessão resultante são a interseção da política baseada em identidade da função e das políticas de sessão. Você pode usar as credenciais temporárias da função em chamadas subsequentes à API da AWS para acessar recursos na conta que possui a função. Você não pode usar políticas de sessão para conceder mais permissões do que as permitidas pela política baseada em identidade da função que está sendo assumida. Para saber mais sobre como a AWS determina as permissões efetivas de uma função, consulte [Lógica da avaliação de política](reference_policies_evaluation-logic.md). ![\[PermissionsWhenPassingRoles_Diagram\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/role_passed_policy_permissions.png) As políticas que são anexadas às credenciais que fizeram a chamada original para o `AssumeRole` não são avaliadas pela AWS ao tomar a decisão de autorização "permitir" ou "negar". O usuário fornece temporariamente suas permissões originais em favor das permissões atribuídas pelo função assumida. No caso das operações de API `AssumeRoleWithSAML` e `AssumeRoleWithWebIdentity`, não há políticas para avaliar porque o chamador da API não é uma identidade da AWS. ## Exemplo: atribuição de permissões usando AssumeRole Você pode usar uma operação de API `AssumeRole` com diferentes tipos de políticas. Veja a seguir alguns exemplos. ### Política de permissões da função Neste exemplo, você chama a operação de API `AssumeRole` sem especificar a política da sessão no parâmetro `Policy` opcional. As permissões atribuídas às credenciais temporárias são determinadas pela política de permissões da função que está sendo assumida. O exemplo a seguir de política de permissões concede à função permissão para listar todos os objetos contidos em um bucket do S3 chamado `productionapp`. Ele também permite que a função obtenha, adicione e exclua objetos dentro desse bucket. **Example Exemplo de política de permissões da função** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::productionapp" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::productionapp/*" } ] } ``` ### Política de sessão transmitida como parâmetro Imagine que você deseja permitir que um usuário assuma a mesma função do exemplo anterior. No entanto, neste caso, você deseja que a sessão de função tenha permissão apenas para obter e colocar objetos no bucket `productionapp` do S3. Você não deseja permitir que ele exclua objetos. Uma forma de conseguir isso é criar uma nova função e especificar as permissões desejadas nessa política de permissão da função. Outra forma de fazer isso é chamar a API `AssumeRole` e incluir políticas de sessão no parâmetro opcional `Policy` como parte da operação de API. As permissões da sessão resultante são a interseção das políticas baseadas em identidade da função e das políticas de sessão. As políticas de sessão não podem ser usadas para conceder mais permissões do que as permitidas pela política baseada em identidade da função que está sendo assumida. Para obter mais informações sobre as permissões de sessão da função, consulte [Políticas de sessão](access_policies.md#policies_session). Depois de recuperar as credenciais temporárias da nova sessão, você pode transmiti-las para o usuário que você deseja que tenha essas permissões. Por exemplo, imagine que a seguinte política é transmitida como um parâmetro da chamada de API. A pessoa que usa a sessão tem permissões para executar apenas as seguintes ações: + Listar todos os objetos no bucket `productionapp`. + Obter e colocar objetos no bucket `productionapp`. Na política de sessão a seguir, a permissão `s3:DeleteObject` é filtrada e a sessão assumida não recebe a permissão `s3:DeleteObject`. A política define o máximo de permissões para a sessão da função de forma que ele substitui todas as políticas de permissões existentes na função. **Example Exemplo de política de sessão passada com a chamada da API `AssumeRole`** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::productionapp" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::productionapp/*" } ] } ``` ### Política baseada em recurso Alguns recursos da AWS dão suporte às políticas baseadas em recursos, e essas políticas fornecem outro mecanismo para definir permissões que afetam credenciais de segurança temporárias. Apenas alguns recursos, como buckets do Amazon S3, tópicos do Amazon SNS e filas do Amazon SQS oferecem suporte a políticas baseadas em recurso. O exemplo a seguir expande os exemplos anteriores usando um bucket do S3 denominado `productionapp`. A política a seguir é anexada ao bucket. Quando você anexa a seguinte política baseada em recurso ao bucket `productionapp`, *todos* os usuários ficam impedidos de excluir objetos do bucket. (Consulte o elemento `Principal` na política). Isso inclui todos os usuários da função assumida, mesmo que a política de permissões da função conceda a permissão `DeleteObject`. Uma declaração explicita `Deny` sempre tem precedência sobre uma instrução `Allow`. **Example Exemplo de política de bucket** **** ``` { "Version":"2012-10-17", "Statement": { "Principal": {"AWS": "*"}, "Effect": "Deny", "Action": "s3:DeleteObject", "Resource": "arn:aws:s3:::productionapp/*" } } ``` Para obter mais informações sobre como vários tipos de políticas são combinados e avaliados pela AWS, consulte [Lógica da avaliação de política](reference_policies_evaluation-logic.md). # Monitorar e controlar ações realizadas com funções assumidas Uma [função do IAM](id_roles.md) é um objeto no IAM ao qual são atribuídas [permissões](access_policies.md). Ao [assumir essa função](id_roles_manage-assume.md) usando uma identidade do IAM ou uma identidade de fora da AWS, você recebe uma sessão com as permissões atribuídas à função. Quando você executa ações na AWS, as informações sobre sua sessão podem ser registradas no AWS CloudTrail para o administrador da conta monitorar. Os administradores podem configurar funções para exigir que as identidades passem uma string personalizada que identifica a pessoa ou a aplicação que está executando ações na AWS. Essas informações de identidade são armazenadas como a *identidade-fonte* no AWS CloudTrail. Quando o administrador revisa a atividade no CloudTrail, ele pode visualizar as informações de identidade-fonte para determinar quem ou o que executou ações com sessões de funções assumidas. Depois que uma identidade-fonte é definida, ela estará presente em solicitações para qualquer ação da AWS realizada durante a sessão de função. O valor definido persiste quando uma função é usada para assumir outra função por meio da AWS CLI ou da API da AWS, o que é conhecido como [encadeamento de funções](id_roles.md#iam-term-role-chaining). O valor definido não pode ser alterado durante a sessão da função. Os administradores podem configurar permissões detalhadas com base na presença ou no valor da identidade-fonte para controlar ainda mais as ações da AWS que são tomadas com funções compartilhadas. Você pode decidir se o atributo de identidade-fonte pode ser usado, se é necessário e qual valor pode ser usado. A maneira como você usa a identidade-fonte difere do nome da sessão de função e das etiquetas de sessão de uma maneira importante. O valor da identidade-fonte não pode ser alterado depois de definido, e ele persiste para quaisquer ações adicionais realizadas com a sessão de função. Veja como você pode usar etiquetas de sessão e nome de sessão de função: + **Etiquetas de sessão**: você também pode passar etiquetas de sessão ao assumir uma função ou federar um usuário. As etiquetas de sessão estão presentes quando uma função é assumida. 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. Em seguida, você pode usar o CloudTrail para visualizar as solicitações feitas para assumir funções ou federar usuários. Para saber mais sobre tags de sessão, consulte [Passar tags de sessão no AWS STS](id_session-tags.md). + **Nome da sessão de função**: você pode usar a chave de condição `sts:RoleSessionName` em uma política de confiança de função para exigir que seus usuários forneçam um nome de sessão específico quando assumirem uma função. O nome da sessão de função pode ser usado para diferenciar sessões de função quando uma função é usada por diferentes entidades de segurança. Para saber mais sobre o nome da sessão de função, consulte [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname). Recomendamos que você use a identidade-fonte quando quiser controlar a identidade que assume uma função. A identidade-fonte também é útil para mineração de logs do CloudTrail para determinar quem usou a função para executar ações. **Topics** + [Configuração para usar a identidade-fonte](#id_credentials_temp_control-access_monitor-setup) + [O que é preciso saber sobre a identidade-fonte](#id_credentials_temp_control-access_monitor-know) + [Permissões necessárias para definir a identidade-fonte](#id_credentials_temp_control-access_monitor-perms) + [Especificação de uma identidade-fonte ao assumir uma função](#id_credentials_temp_control-access_monitor-specify-sourceid) + [Uso da identidade-fonte com AssumeRole](#id_credentials_temp_control-access_monitor-assume-role) + [Uso da identidade-fonte com AssumeRoleWithSAML](#id_credentials_temp_control-access_monitor-assume-role-saml) + [Uso da identidade-fonte com AssumeRoleWithWebIdentity](#id_credentials_temp_control-access_monitor-assume-role-web-id) + [Controlar o acesso usando informações de identidade-fonte](#id_credentials_temp_control-access_monitor-control-access) + [Visualização de uma identidade-fonte no CloudTrail](#id_credentials_temp_control-access_monitor-ct) ## Configuração para usar a identidade-fonte A maneira que você configura para usar a identidade-fonte depende do método usado quando suas funções são assumidas. Por exemplo, seus usuários do IAM podem assumir funções diretamente usando a operação `AssumeRole`. Se você tiver identidades empresariais, também conhecidas como identidades do quadro de funcionários, elas poderão acessar seus recursos da AWS usando `AssumeRoleWithSAML`. Se os usuários finais acessarem suas aplicações móveis ou Web, eles poderão fazer isso usando `AssumeRoleWithWebIdentity`. Veja a seguir uma visão geral do fluxo de trabalho de alto nível para ajudar você a entender como configurar para uso as informações de identidade-fonte em seu ambiente existente. 1. **Configure usuários e funções de teste**: usando um ambiente de pré-produção, configure usuários e funções de teste e configure suas respectivas políticas para permitir a definição de uma identidade-fonte. Se você usar um provedor de identidade (IdP) para suas identidades federadas, configure seu IdP para passar um atributo de usuário de sua escolha para a identidade-fonte na asserção ou no token. 1. **Assuma a função**: teste assumindo funções e passando uma identidade-fonte com os usuários e funções que você configurou para teste. 1. **Reveja o CloudTrail**: reveja as informações de identidade-fonte para suas funções de teste nos logs do CloudTrail. 1. **Treine seus usuários**: depois de testar em seu ambiente de pré-produção, certifique-se de que seus usuários saibam como transmitir as informações de identidade-fonte, se necessário. Defina um prazo para quando você exigirá que seus usuários forneçam uma identidade-fonte em seu ambiente de produção. 1. **Configure políticas de produção**: configure as políticas para o ambiente de produção e, em seguida, adicione-as aos usuários e funções de produção. 1. **Monitore a atividade**: monitore sua atividade de função de produção usando logs do CloudTrail. ## O que é preciso saber sobre a identidade-fonte Lembre-se do seguinte ao trabalhar com a identidade-fonte. + As políticas de confiança para todas as funções conectadas a um provedor de identidade (IdP) devem ter a permissão `sts:SetSourceIdentity`. Para funções que não têm essa permissão na política de confiança de função, a operação `AssumeRole*` falhará. Se não quiser atualizar a política de confiança de função para cada função, você pode usar uma instância do IdP separada para passar a identidade-fonte. Em seguida, adicione a `sts:SetSourceIdentity` permissão apenas às funções que estiverem conectadas ao IdP separado. + Quando uma identidade define uma identidade-fonte, a chave `sts:SourceIdentity` fica presente na solicitação. Para ações subsequentes realizadas durante a sessão de função, a chave `aws:SourceIdentity` estará presente na solicitação. A AWS não controla o valor da identidade-fonte nas chaves `sts:SourceIdentity` ou `aws:SourceIdentity`. Se você optar por exigir uma identidade-fonte, deverá escolher um atributo que deseja que seus usuários ou o IdP forneçam. Por motivos de segurança, você deve garantir que pode controlar como esses valores são fornecidos. + O valor da identidade-fonte deve ter entre 2 e 64 caracteres, pode conter apenas caracteres alfanuméricos, sublinhados e os seguintes caracteres: **. , \$1 = @ -** (hífen). Você não pode usar um valor que comece com o texto **aws:**. Este prefixo está reservado para uso interno da AWS. + As informações de identidade-fonte não são capturadas pelo CloudTrail quando um produto da AWS ou uma função vinculada ao serviço executa uma ação em nome de uma identidade do quadro de funcionários ou federada. **Importante** Você não pode alternar para uma função no Console de gerenciamento da AWS ue exija que uma identidade-fonte seja definida quando a função for assumida. Para assumir essa função, você pode usar a AWS CLI ou a API da AWS para chamar a operação `AssumeRole` e especificar o parâmetro da identidade-fonte. ## Permissões necessárias para definir a identidade-fonte Além da ação que corresponde à operação da API, é necessário ter a seguinte ação somente com permissão em sua política: ``` sts:SetSourceIdentity ``` + Para especificar uma identidade-fonte, as entidades de segurança (usuários e funções do IAM) devem ter permissões para `sts:SetSourceIdentity`. Como administrador, você pode configurar isso na política de confiança da função e na política de permissões da entidade de segurança. + Quando você assume uma função com outra função, chamada de [encadeamento de funções](id_roles.md#iam-term-role-chaining), as permissões para `sts:SetSourceIdentity` são necessárias na política de permissões da entidade de segurança que está assumindo a função e na política de confiança da função de destino. Caso contrário, a operação de assumir função falhará. + Ao usar a identidade-fonte, as políticas de confiança de função para todas as funções conectadas a um IdP devem ter a permissão `sts:SetSourceIdentity`. A operação `AssumeRole*` falhará para qualquer função conectada a um IdP sem essa permissão. Se você não quiser atualizar a política de confiança de função para cada função, use uma instância de IdP separada para passar a identidade-fonte e adicionar a permissão `sts:SetSourceIdentity` apenas às funções que estão conectadas ao IdP separado. + Para definir uma identidade-fonte entre os limites da conta, você deve incluir a permissão `sts:SetSourceIdentity` em dois lugares. Ela deve estar na política de permissões da entidade de segurança na conta originadora e na política de confiança da função na conta de destino. Talvez seja necessário fazer isso, por exemplo, quando uma função for usada para assumir uma função em outra conta com o[encadeamento de funções](id_roles.md#iam-term-role-chaining). Como administrador da conta, imagine que você deseja permitir que o usuário do IAM `DevUser` em sua conta assuma a `Developer_Role` na mesma conta. Mas você deseja permitir essa ação somente se o usuário tiver definido a identidade-fonte como seu próprio nome de usuário do IAM. Você pode anexar a política a seguir ao usuário do IAM. **Example Exemplo de política baseada em identidade anexada ao DevUser** **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::123456789012:role/Developer_Role" }, { "Sid": "SetAwsUserNameAsSourceIdentity", "Effect": "Allow", "Action": "sts:SetSourceIdentity", "Resource": "arn:aws:iam::123456789012:role/Developer_Role", "Condition": { "StringLike": { "sts:SourceIdentity": "${aws:username}" } } } ] } ``` Para impor os valores de identidade-fonte aceitáveis, você pode configurar a política de confiança de função a seguir. A política fornece ao usuário do IAM `DevUser` permissões para assumir a função e definir uma identidade-fonte. A chave de condição `sts:SourceIdentity` define o valor da identidade-fonte aceitável. **Example Exemplo de política de confiança de função para identidade-fonte** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowDevUserAssumeRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/DevUser" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "sts:SourceIdentity": "DevUser" } } } ] } ``` ------ Usando as credenciais `DevUser` do usuário do IAM, o usuário tenta assumir a função `DeveloperRole` usando a solicitação da AWS CLI a seguir. **Example Exemplo de solicitação da CLI AssumeRole** ``` aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/Developer_Role \ --role-session-name Dev-project \ --source-identity DevUser \ ``` Quando a AWS avalia a solicitação, o contexto da solicitação contém a `sts:SourceIdentity` de `DevUser`. ## Especificação de uma identidade-fonte ao assumir uma função Você pode especificar uma identidade-fonte ao usar uma das operações da API `AssumeRole*` do AWS STS para obter credenciais de segurança temporárias para uma função. A operação de API que você usa difere dependendo do seu caso de uso. Por exemplo, se você usar funções do IAM para dar aos usuários do IAM acesso aos recursos da AWS quais eles normalmente não têm acesso, você poderá usar a operação `AssumeRole`. Se você usar a federação de identidade empresarial para gerenciar os usuários do quadro de funcionários, poderá usar a operação `AssumeRoleWithSAML`. Se você usar a federação OIDC para permitir que os usuários finais acessem suas aplicações móveis ou Web, use a operação `AssumeRoleWithWebIdentity`. As seções a seguir explicam como usar a identidade-fonte em cada operação. Para saber mais sobre cenários comuns de credenciais temporárias, consulte [Cenários comuns para credenciais temporárias](id_credentials_temp.md#sts-introduction). ## Uso da identidade-fonte com AssumeRole A operação `AssumeRole` retorna um conjunto de credenciais temporárias que você pode usar para acessar recursos da AWS. Você pode usar o usuário do IAM ou credenciais de função para chamar `AssumeRole`. Para passar a identidade-fonte enquanto assume uma função, use a opção `-–source-identity` da AWS CLI ou o parâmetro `SourceIdentity` da API da AWS. O exemplo a seguir mostra como especificar a identidade-fonte usando a AWS CLI. **Example Exemplo de solicitação da CLI AssumeRole** ``` aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/developer \ --role-session-name Audit \ --source-identity Admin \ ``` ## Uso da identidade-fonte com AssumeRoleWithSAML A entidade de segurança que chama a operação `AssumeRoleWithSAML` é autenticada usando a federação baseada em SAML. Essa operação retorna um conjunto de credenciais temporárias que você pode usar para acessar os recursos da AWS. Para obter mais informações sobre como usar a federação baseada em SAML para acesso ao Console de gerenciamento da AWS, 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). Para obter detalhes sobre acesso à AWS CLI ou à API da AWS, consulte [Federação SAML 2.0](id_roles_providers_saml.md). Para obter um tutorial sobre como configurar a federação do SAML para seus usuários do Active Directory, consulte [AWS Federated Authentication with Active Directory Federation Services (ADFS)](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/) no AWS Security Blog. Como administrador, você pode permitir que os membros do diretório da empresa se agrupem na AWS usando a operação AWS STS da `AssumeRoleWithSAML`. Para isso, é necessário concluir as seguintes tarefas: 1. [Configure um provedor SAML na sua organização](id_roles_providers_saml_3rd-party.md). 1. [Criar um provedor SAML no IAM](id_roles_providers_create_saml.md). 1. [Configurar um perfil e suas permissões na AWS para suas entidades principais federadas SAML](id_roles_create_for-idp_saml.md). 1. [Concluir a configuração do IdP SAML e criar declarações para a resposta de autenticação SAML](id_roles_providers_create_saml_assertions.md). Para definir um atributo SAML para a identidade-fonte, inclua o elemento `Attribute` com o atributo `Name` definido como `https://aws.amazon.com/SAML/Attributes/SourceIdentity`. Use o elemento `AttributeValue` para especificar o valor da identidade-fonte. Por exemplo, suponha que você deseja passar o seguinte atributo de identidade como a identidade-fonte. `SourceIdentity:DiegoRamirez` Para passar esse atributo, inclua o seguinte elemento em sua declaração SAML. **Example Exemplo de trecho de uma declaração SAML** ``` DiegoRamirez ``` ## Uso da identidade-fonte com AssumeRoleWithWebIdentity A entidade principal que chama a operação `AssumeRoleWithWebIdentity` é autenticada usando federação compatível com o OpenID Connect (OIDC). Essa operação retorna um conjunto de credenciais temporárias que você pode usar para acessar os recursos da AWS. Para obter mais informações sobre como usar a federação OIDC para acesso ao Console de gerenciamento da AWS, consulte [Federação OIDC](id_roles_providers_oidc.md). Para passar a identidade-fonte do OpenID Connect (OIDC), é necessário incluir a identidade-fonte no JSON Web Token (JWT). Inclua a identidade-fonte no namespace `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity` no token ao enviar a solicitação `AssumeRoleWithWebIdentity`. Para saber mais sobre tokens e reivindicações OIDC, consulte [Usar tokens com grupos de usuários](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html) no *Guia do desenvolvedor Amazon Cognito*. Por exemplo, o JWT decodificado a seguir é um token usado para chamar `AssumeRoleWithWebIdentity` com a identidade-fonte`Admin`. **Example Exemplo de JSON Web Token decodificado** ``` { "sub": "john", "aud": "ac_oic_client", "jti": "ZYUCeRMQVtqHypVPWAN3VB", "iss": "https://xyz.com", "iat": 1566583294, "exp": 1566583354, "auth_time": 1566583292, "https://aws.amazon.com/source_identity":"Admin" } ``` ## Controlar o acesso usando informações de identidade-fonte Quando uma identidade-fonte é definida inicialmente, a chave [sts:SourceIdentity](reference_policies_iam-condition-keys.md#ck_sourceidentity) fica presente na solicitação. Depois que uma identidade-fonte for definida, a chave [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) estará presente em todas as solicitações subsequentes feitas durante a sessão de função. Como administrador, você pode escrever políticas que concedem autorização condicional para realizar ações da AWS com base na existência ou no valor do atributo de identidade-fonte. Imagine que você deseja exigir que seus desenvolvedores definam uma identidade-fonte para assumir uma função crítica que tenha permissão para gravar em um recurso crítico de produção da AWS. Imagine também que você conceda acesso da AWS às identidades do quadro de funcionários usando `AssumeRoleWithSAML`. Você deseja que apenas os desenvolvedores sênior Saanvi e Diego tenham acesso à função, portanto, você cria a seguinte política de confiança para a função. **Example Exemplo de política de confiança de função para identidade-fonte (SAML)** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "SAMLProviderAssumeRoleWithSAML", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider" }, "Action": [ "sts:AssumeRoleWithSAML" ], "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" } } }, { "Sid": "SetSourceIdentitySrEngs", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider" }, "Action": [ "sts:SetSourceIdentity" ], "Condition": { "StringLike": { "sts:SourceIdentity": [ "Saanvi", "Diego" ] } } } ] } ``` ------ A política de confiança possui uma condição para `sts:SourceIdentity` que requer uma identidade-fonte definida como Saanvi ou Diego para assumir a função crítica. Como alternativa, se você usar um provedor OIDC para federação e os usuários forem autenticados com `AssumeRoleWithWebIdentity`, sua política de confiança de perfil poderá ser semelhante à mostrada a seguir. **Example Exemplo de política de confiança de função para identidade-fonte (provedor OIDC)** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/server.example.com" }, "Action": [ "sts:AssumeRoleWithWebIdentity", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "server.example.com:aud": "oidc-audience-id" }, "StringLike": { "sts:SourceIdentity": [ "Saanvi", "Diego" ] } } } ] } ``` ------ ### Requisitos de encadeamento de funções e entre contas Imagine que você deseja permitir que os usuários que assumiram a `CriticalRole` assumam uma `CriticalRole_2` em outra conta. As credenciais da sessão de função que foram obtidas para assumir `CriticalRole` são usadas para [encadear funções](id_roles.md#iam-term-role-chaining) para uma segunda função, `CriticalRole_2`, em outra conta. A função está sendo assumida além dos limites de uma conta. Portanto, a permissão `sts:SetSourceIdentity` deve ser concedida na política de permissões em `CriticalRole` e na política de confiança de função em `CriticalRole_2`. **Example Exemplo de política de permissões em CriticalRole** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeRoleAndSetSourceIdentity", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Resource": "arn:aws:iam::222222222222:role/CriticalRole_2" } ] } ``` ------ Para proteger a definição de identidade-fonte além do limite da conta, a seguinte política de confiança de função confia apenas na entidade de segurança da função de `CriticalRole` para definir a identidade-fonte. **Example Exemplo de política de confiança de função em CriticalRole\$12** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:role/CriticalRole" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Condition": { "StringLike": { "aws:SourceIdentity": ["Saanvi","Diego"] } } } ] } ``` ------ O usuário faz a seguinte chamada usando credenciais de sessão de função obtidas assumindo a CriticalRole. A identidade-fonte foi definida durante a suposição de CriticalRole, portanto, ela não precisa ser explicitamente definida novamente. Se o usuário tentar definir uma identidade-fonte diferente do valor definido quando `CriticalRole` foi assumida, a solicitação de assumir função será negada. **Example Exemplo de solicitação da CLI AssumeRole** ``` aws sts assume-role \ --role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \ --role-session-name Audit \ ``` Quando a entidade de segurança de chamada assume a função, a identidade-fonte na solicitação persiste desde a primeira sessão de função assumida. Portanto, as chaves `aws:SourceIdentity` e `sts:SourceIdentity` estão presentes no contexto da solicitação. ## Visualização de uma identidade-fonte no CloudTrail Você pode usar o CloudTrail para visualizar as solicitações feitas para assumir funções ou federar usuários. Você também pode visualizar as solicitações de função ou do usuário para realizar ações na AWS. O arquivo de log do CloudTrail inclui informações sobre a identidade-fonte definida para a função assumida ou a sessão de usuário federado. Para obter mais informações, consulte . [Registro em log de chamadas de API do IAM e do AWS STS com o AWS CloudTrail](cloudtrail-integration.md) Por exemplo, suponha que um usuário faça uma solicitção `AssumeRole` ao AWS STS e defina uma identidade-fonte. Você pode encontrar as informações de `sourceIdentity` na chave `requestParameters` em seu log do CloudTrail. **Example Exemplo de seção requestParameters em um log do AWS CloudTrail** ``` "eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "AIDAJ45Q7YFFAREXAMPLE", "accountId": "111122223333" }, "eventTime": "2020-04-02T18:20:53Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRole", "awsRegion": "us-east-1", "sourceIPAddress": "203.0.113.64", "userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86", "requestParameters": { "roleArn": "arn:aws:iam::123456789012:role/DevRole", "roleSessionName": "Dev1", "sourceIdentity": "source-identity-value-set" } ``` Se o usuário usar a sessão de função assumida para executar uma ação, as informações da identidade-fonte estarão presentes na chave `userIdentity` no log do CloudTrail. **Example Exemplo de chave userIdentity em um log do AWS CloudTrail** ``` { "eventVersion": "1.08", "userIdentity": { "type": "AssumedRole", "principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1", "arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROAJ45Q7YFFAREXAMPLE", "arn": "arn:aws:iam::123456789012:role/DevRole", "accountId": "123456789012", "userName": "DevRole" }, "webIdFederationData": {}, "attributes": { "mfaAuthenticated": "false", "creationDate": "2021-02-21T23:46:28Z" }, "sourceIdentity": "source-identity-value-present" } } } ``` Para ver exemplos de eventos de API do AWS STS em logs do CloudTrail, consulte [Exemplo de eventos de API do IAM no log do CloudTrail](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api). Para obter mais detalhes sobre as informações contidas nos arquivos de log do CloudTrail, consulte [Referência de evento do CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) no *Guia do usuário do AWS CloudTrail*. # Permissões para GetFederationToken A operação `GetFederationToken` é chamada por um usuário do IAM e retorna credenciais temporárias para esse usuário. Essa operação *federa* o usuário. As permissões atribuídas a uma sessão de usuário federado do AWS STS são definidas em um de dois lugares: + A política de sessão transmitida como um parâmetro da chamada de API `GetFederationToken`. (Isso é mais comum.) + Uma política com base em recursos que nomeia explicitamente o usuário federado do AWS STS no elemento `Principal` da política. (Isso é menos comum.) As políticas de sessão são políticas avançadas que você transmite como parâmetros ao criar de forma programática uma sessão temporária. Quando você cria uma sessão de usuário federado do AWS STS e transmite as políticas de sessão, as permissões da sessão resultante são a interseção da política baseada em identidade do usuário e das políticas da sessão. Você não pode usar a política de sessão para conceder mais permissões do que as permitidas pela política baseada em identidade do usuário que está sendo federado. Na maioria dos casos, se você não transmitir uma política com a chamada de API `GetFederationToken`, as credenciais de segurança temporárias não terão permissões. No entanto, uma política baseada em recurso pode fornecer permissões adicionais para a sessão. Você pode acessar um recurso com uma política baseada em recurso que especifica sua sessão como a entidade principal permitida. As figuras a seguir mostram uma representação visual de como as políticas interagem para determinar permissões para as credenciais de segurança temporárias retornadas por uma chamada de `GetFederationToken`. ![\[Usuário do IAMAs ilustrações a seguir mostram marcas de seleção para indicar que as permissões de sessão são a interseção entre a política baseada em identidade do usuário e as políticas de sessão. As permissões de sessão também podem ser a interseção entre a política baseada em identidade do usuário e as políticas baseadas em recurso.\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/images/getfederationtoken-permissions.diagram.png) ## Exemplo: atribuição de permissões usando GetFederationToken Você pode usar a ação de API `GetFederationToken` com diferentes tipos de políticas. Veja a seguir alguns exemplos. ### Política anexada ao usuário do IAM Neste exemplo, você tem uma aplicação cliente baseada em navegador que conta com dois serviços da Web de backend. Um serviço de backend é o seu próprio servidor de autenticação que usa o seu próprio sistema de identidade para autenticar a aplicação cliente. O outro serviço de backend é um serviço do AWS que fornece algumas das funcionalidades da aplicação cliente. O aplicativo cliente é autenticado pelo seu servidor, e este cria ou recupera a política de permissões apropriada. Seu servidor chama a API `GetFederationToken` para obter as credenciais de segurança temporárias e retorna essas credenciais para o aplicativo cliente. O aplicativo cliente pode então fazer solicitações diretamente ao serviço da AWS com as credenciais de segurança temporárias. Essa arquitetura permite que o aplicativo cliente faça solicitações da AWS sem incorporação das credenciais da AWS de longo prazo. Seu servidor de autenticação chama a API `GetFederationToken` com as credenciais de segurança de longo prazo de um usuário do IAM chamado `token-app`. No entanto, as credenciais do usuário do IAM de longo prazo permanecem no servidor e nunca são distribuídas para o cliente. A política do exemplo a seguir está anexada ao usuário `token-app` do IAM e define o mais amplo conjunto de permissões necessários para seus usuários federados do AWS STS (clientes). Observe que a permissão `sts:GetFederationToken` é necessária para o seu serviço de autenticação para obter credenciais de segurança temporárias para os usuários federados do AWS STS. **Example Exemplo de política anexada ao usuário do IAM `token-app` que chama `GetFederationToken`** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:GetFederationToken", "Resource": "*" }, { "Effect": "Allow", "Action": "dynamodb:ListTables", "Resource": "*" }, { "Effect": "Allow", "Action": "sqs:ReceiveMessage", "Resource": "*" }, { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "*" }, { "Effect": "Allow", "Action": "sns:ListSubscriptions", "Resource": "*" } ] } ``` A política anterior concede várias permissões ao usuário do IAM. No entanto, essa política sozinha não concede permissões ao usuário federado do AWS STS. Se esse usuário do IAM chamar `GetFederationToken` e não transmitir uma política como um parâmetro da chamada de API, o usuário federado do AWS STS resultante não terá permissões efetivas. ### Política de sessão transmitida como um parâmetro A forma mais comum para garantir que o usuário federado do AWS STS tenha a atribuição da permissão apropriada é transmitir políticas de sessão na chamada de API `GetFederationToken`. Expandindo o exemplo anterior, imagine que ação `GetFederationToken` é chamada com as credenciais do usuário do IAM `token-app`. Por exemplo, imagine que a seguinte política de sessão seja transmitida como um parâmetro da chamada de API. O usuário federado do AWS STS resultante tem permissão para listar o conteúdo do bucket do Amazon S3 chamado `productionapp`. O usuário não pode executar as ações do `GetObject` `PutObject` e `DeleteObject` do Amazon S3 em itens no bucket `productionapp`. Essas permissões são atribuídas ao usuário federado porque as permissões são a interseção das políticas de usuário do IAM e das políticas de sessão que você transmite. O usuário federado do AWS STS não podia executar ações no Amazon SNS, Amazon SQS, Amazon DynamoDB ou em qualquer bucket do S3, exceto `productionapp`. Essas ações são negadas mesmo que essas permissões sejam concedidas ao usuário do IAM que está associado à chamada `GetFederationToken`. **Example Exemplo de política de sessão passada como parâmetro de chamada de API `GetFederationToken`** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": ["arn:aws:s3:::productionapp"] }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": ["arn:aws:s3:::productionapp/*"] } ] } ``` ### Políticas baseadas em recursos Alguns recursos da AWS oferecem suporte às políticas baseadas em recursos, e essas políticas fornecem outro mecanismo para conceder permissões diretamente ao usuário federado do AWS STS. Apenas alguns serviços da AWS oferecem suporte para políticas baseadas em recursos. Por exemplo, o Amazon S3 tem buckets, o Amazon SNS tem tópicos e o Amazon SQS tem filas às quais você pode anexar políticas. Para obter uma lista de todos os serviços que oferecem suporte às políticas baseadas em recurso, consulte [AWSServiços da que funcionam com o IAM](reference_aws-services-that-work-with-iam.md) e analise a coluna "Políticas baseadas em recurso" das tabelas. Você pode usar as políticas baseadas em recurso para atribuir permissões diretamente a um usuário federado do AWS STS. Faça isso ao especificar o nome do recurso da Amazon (ARN) do usuário federado do AWS STS no elemento `Principal` da política baseada em recurso. O exemplo a seguir ilustra isso e explora mais os exemplos anteriores, usando um bucket do S3 chamado `productionapp`. A seguinte política baseada em recurso é anexada a um bucket. Essa política do bucket permite que um usuário federado do AWS STS chamado Carol acesse o bucket. Quando a política de exemplo descrita anteriormente é anexada ao usuário do IAM `token-app`, o usuário federado do AWS STS chamado Carol tem permissão para executar as ações `s3:DeleteObject`, `s3:GetObject` e `s3:PutObject` no bucket chamado `productionapp`. Isso é verdadeiro mesmo quando nenhuma política de sessão é transmitida como um parâmetro da chamada de API `GetFederationToken`. Isso porque, nesse caso, a política baseada em recursos a seguir concedeu explicitamente permissões ao usuário federado do AWS STS chamado Carol. Lembre-se de que um usuário federado do AWS STS recebe permissões apenas quando essas permissões são concedidas explicitamente ao usuário do IAM ***e*** ao usuário federado do AWS STS. Elas também podem ser concedidas (dentro de uma conta) por uma política baseada em recurso que nomeie explicitamente o usuário federado do AWS STS no elemento `Principal` da política, como no exemplo a seguir. **Example Exemplo de política de bucket que permite acesso ao usuário federado** **** ``` { "Version":"2012-10-17", "Statement": { "Principal": { "AWS": "arn:aws:sts::111122223333:federated-user/Carol" }, "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::productionapp/*" ] } } ``` Para obter mais informações sobre como as políticas são avaliadas, consulte [Lógica de avaliação da política](reference_policies_evaluation-logic.md). # Permissões para GetSessionToken A principal ocasião para chamar a operação de API `GetSessionToken` ou o comando `get-session-token` da CLI é quando um usuário deve ser autenticado com Multi-Factor Authentication (MFA). É possível gravar uma política que permite determinadas ações somente quando essas ações são solicitadas por um usuário que foi autenticado com o MFA. Para passar na verificação de autorização MFA, um usuário deve primeiro chamar `GetSessionToken` e incluir os parâmetros `SerialNumber` e `TokenCode` opcionais. Se o usuário for autenticado com êxito com um dispositivo MFA, as credenciais retornadas pela operação de API `GetSessionToken` incluirão o contexto de MFA. Esse contexto indica que o usuário é autenticado com a MFA e é autorizado para operações de API que exigem autenticação de MFA. ## Permissões necessárias para GetSessionToken Nenhuma permissão é necessária para que um usuário obtenha um token de sessão. O objetivo da operação `GetSessionToken` é autenticar o usuário que usa a MFA. Não é possível usar políticas para controlar as operações de autenticação. Para conceder permissões para a execução da maioria das operações da AWS, adicione a ação com o mesmo nome a uma política. Por exemplo, para criar um usuário, você deve usar a operação de API `CreateUser`, o comando `create-user` da CLI ou o Console de gerenciamento da AWS. Para executar essas operações, você deve ter uma política que permite acessar a ação `CreateUser`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:CreateUser", "Resource": "*" } ] } ``` ------ Você pode incluir a ação `GetSessionToken` em suas políticas, mas não terá efeito sobre a capacidade de um usuário executar a operação `GetSessionToken`. ## Permissões concedias por GetSessionToken Se a ação `GetSessionToken` for chamada com as credenciais de um usuário do IAM, as credenciais de segurança temporárias terão as mesmas permissões que o usuário do IAM. Da mesma forma, se a ação `GetSessionToken` for chamada com credenciais de Usuário raiz da conta da AWS, as credenciais de segurança temporárias terão permissões de usuário raiz. **nota** Recomendamos que você não chame a ação `GetSessionToken` com as credenciais de usuário raiz. Em vez disso, siga nossas [práticas recomendadas](best-practices-use-cases.md) e crie usuários do IAM com as permissões de que precisam. Em seguida, use esses usuários do IAM para a interação diária com a AWS. As credenciais temporárias que você obtém ao chamar `GetSessionToken` têm os seguintes recursos e limitações: + Você pode usar as credenciais para acessar o Console de gerenciamento da AWS especificando as credenciais para o endpoint de logon único de federação em `https://signin.aws.amazon.com/federation`. Para obter mais informações, consulte [Habilitar o acesso do intermediador de identidades personalizado ao console da AWS](id_roles_providers_enable-console-custom-url.md). + Você **não pode** usar as credenciais para chamar as operações de API do IAM ou do AWS STS. Você **pode** usá-las para chamar operações de API para outros serviços da AWS. Compare essa operação de API e suas limitações e recursos com as outras operações de API que criam credenciais de segurança temporárias em [Compare credenciais do AWS STS](id_credentials_sts-comparison.md) Para obter mais informações sobre o acesso de API protegido por MFA usando `GetSessionToken`, consulte [Acesso seguro à API com a MFA](id_credentials_mfa_configure-api-require.md). # Desabilitar permissões de credenciais de segurança temporárias As credenciais de segurança temporárias são válidas até que expirem. Essas credenciais são válidas pela duração especificada, de 900 segundos (15 minutos) até um máximo de 129.600 segundos (36 horas). A duração padrão da sessão é de 43.200 segundos (12 horas). Você pode revogar essas credenciais, mas deverá também alterar as permissões do usuário ou perfil do IAM para impedir o uso de credenciais comprometidas para atividades de conta maliciosas. As permissões atribuídas às credenciais de segurança temporárias são avaliadas cada vez que são usadas para fazer uma solicitação da AWS. Quando você remove todas as permissões das credenciais, as solicitações da AWS que as usam falham. Pode levar alguns minutos para que as atualizações da política entrem em vigor. Para sessões de perfil do IAM, você pode revogar as credenciais de segurança temporárias do perfil para forçar todos os usuários que assumirem o perfil a se autenticar novamente e a solicitar novas credenciais. Para obter mais informações, consulte [Revogar as credenciais de segurança temporárias do perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html). Não é possível alterar as permissões para um Usuário raiz da conta da AWS. Da mesma forma, você não pode alterar as permissões para as credenciais de segurança temporárias criadas chamando `GetFederationToken` ou `GetSessionToken` enquanto estiver conectado como usuário raiz. Por esse motivo, recomendamos que você não chame o `GetFederationToken` nem o `GetSessionToken` como usuário raiz. Para obter os procedimentos sobre como alterar as permissões para um usuário do IAM, consulte [Alterar permissões de um usuário do IAM](id_users_change-permissions.md). Para obter os procedimentos sobre como alterar as permissões para um perfil do IAM, consulte [Atualizar permissões para um perfil](id_roles_update-role-permissions.md). **Importante** Não é possível editar perfis no IAM que foram criados a partir de conjuntos de permissões do Centro de Identidade do IAM. É necessário revogar a sessão ativa do conjunto de permissões de um usuário no Centro de Identidade do IAM. Para obter mais informações, consulte [Revogar sessões ativas de perfil do IAM criadas por conjuntos de permissões](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions), no *Guia do usuário do Centro de Identidade do IAM*. **Topics** + [Negar acesso a todas as sessões de perfil do IAM associadas a um perfil](#deny-access-to-all-sessions) + [Negar acesso a uma determinada sessão de perfil do IAM](#deny-access-to-specific-session) + [Negar acesso a sessões de credenciais de segurança temporárias com chaves de contexto de condição](#deny-access-to-specific-session-condition-key) + [Negar acesso a uma determinada entidade principal com políticas baseadas em identidade](#deny-access-with-resource-based) ## Negar acesso a todas as sessões de perfil do IAM associadas a um perfil Esse procedimento nega permissões para **todas** as sessões de perfil do IAM associadas a um perfil. Use essa abordagem quando tiver preocupações com relação a acesso suspeito por meio de: + Entidades principais de outra conta usando acesso entre contas + Identidades de usuários externos com permissões de acesso a recursos da AWS em sua conta + Os usuários que foram autenticados em uma aplicação móvel ou Web com um provedor de OIDC Para alterar ou remover as permissões atribuídas às credenciais de segurança temporárias obtidas chamando as APIs `AssumeRole`, `AssumeRoleWithSAML`, `AssumeRoleWithWebIdentity`, `GetFederationToken` ou `GetSessionToken`, você pode editar ou excluir a política baseada em identidade que define as permissões do perfil. **Importante** Se houver uma política baseada em recursos que permita o acesso da entidade principal, você também deverá adicionar uma negação explícita para o recurso. Para mais detalhes, consulte [Negar acesso a uma determinada entidade principal com políticas baseadas em identidade](#deny-access-with-resource-based). **Para negar acesso a **todas** as sessões de perfil do IAM associadas a um perfil** 1. Faça login no Console de gerenciamento da AWS e abra o console do IAM. 1. No painel de navegação, escolha **Perfis**. 1. Selecione o nome do perfil a editar. Você pode usar a caixa de pesquisa para filtrar a lista. 1. Escolha a aba **Permissões**. 1. Selecione a política relevante a editar. Antes de editar uma política gerenciada pelo cliente, revise a guia **Entidades anexadas** para evitar interromper o acesso a outras identidades que tenham a mesma política anexada. 1. Escolha a guia **JSON** e atualize a política para negar todos os recursos e ações. **nota** Essas permissões são as mesmas da política gerenciada pela AWS [AWSDenyAll](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html). Você pode anexar essa política gerenciada pela AWS a qualquer usuário ou perfil do IAM ao qual você queira negar acesso. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyAll", "Effect": "Deny", "Action": [ "*" ], "Resource": "*" } ] } ``` ------ 1. Na página **Revisão**, revise o **Resumo** da política e, em seguida, selecione **Salvar alterações** para salvar seu trabalho. Quando você atualiza a política, as alterações afetam as permissões de todas as credenciais de segurança temporárias associadas ao perfil, incluindo credenciais emitidas antes da alteração da política de permissões do perfil. Após atualizar a política, você poderá [revogar as credenciais de segurança temporárias do perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) para revogar imediatamente todas as permissões às credenciais emitidas pelo perfil. ## Negar acesso a uma determinada sessão de perfil do IAM Quando você atualiza perfis do IAM com uma política de negação total ou exclui o perfil, todos os usuários que têm acesso ao perfil são afetados. Você pode negar acesso sem afetar as permissões de todas as outras sessões associadas ao perfil. É possível negar permissões à `Principal` usando [chaves de contexto de condição](#deny-access-to-specific-session-condition-key) ou [políticas baseadas em recursos](#deny-access-with-resource-based). **dica** Você pode encontrar os ARNs de usuários federados usando logs do AWS CloudTrail. Para obter mais informações, consulte  a página [How to Easily Identify Your Federated Users by Using AWS CloudTrail](https://aws.amazon.com/blogs/security/how-to-easily-identify-your-federated-users-by-using-aws-cloudtrail/). ## Negar acesso a sessões de credenciais de segurança temporárias com chaves de contexto de condição Você pode usar chaves de contexto de condição nas políticas baseadas em identidade quando desejar negar acesso a sessões específicas de credenciais de segurança temporárias sem afetar as permissões do usuário ou perfil do IAM que criou as credenciais. Para perfis do IAM, depois de atualizar a política, você também pode [revogar as sessões de credenciais de segurança temporárias do perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) para revogar imediatamente todas as credenciais emitidas. Para obter mais informações sobre chaves de contexto de condição, consulte [AWSChaves de contexto de condições globais da](reference_policies_condition-keys.md). ### aws:PrincipalArn Você pode usar a chave de contexto de condição [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) em uma política baseada em identidade para negar acesso a uma determinada entidade principal por seu nome do recurso da Amazon (ARN). Para fazer isso, especifique o ARN da sessão do usuário do IAM, do perfil ou do usuário federado do AWS STS à qual as credenciais de segurança temporárias estão associadas no elemento de condição de uma política. **Para negar acesso a uma determinada entidade principal por ARN** 1. No painel de navegação do console do IAM, escolha **Usuários** ou **Perfis**. 1. Escolha o nome do usuário ou perfil do IAM a editar. Você pode usar a caixa de pesquisa para filtrar a lista. 1. Escolha a aba **Permissões**. 1. Selecione a política relevante a editar. Antes de editar uma política gerenciada pelo cliente, revise a guia **Entidades anexadas** para evitar interromper o acesso a outras identidades que tenham a mesma política anexada. 1. Escolha a guia **JSON** e adicione uma instrução de negação para o ARN da entidade principal, conforme mostrado no exemplo a seguir. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "ArnEquals": { "aws:PrincipalArn": [ "arn:aws:iam::222222222222:role/ROLENAME", "arn:aws:iam::222222222222:user/USERNAME", "arn:aws:iam::222222222222:federated-user/USERNAME" ] } } } ] } ``` ------ 1. Na página **Revisão**, revise o **Resumo** da política e, em seguida, selecione **Salvar alterações** para salvar seu trabalho. ### aws:SourceIdentity Você pode usar a chave de contexto de condição [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) em uma política baseada em identidade para negar acesso a uma determinada identidade de origem associada a uma sessão de perfil do IAM. Isso se aplica contanto que a sessão de perfil tenha sido emitida definindo o parâmetro de solicitação `SourceIdentity` quando a entidade principal assumiu um perfil usando qualquer comando `assume-role` da CLI do AWS STS\$1 ou operações da API `AssumeRole` do AWS STS\$1. Faça isso especificando a identidade de origem à qual as credenciais de segurança temporárias estão associadas no elemento `Condition` de uma política. Ao contrário da chave de contexto [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname), após a definição da identidade-fonte, o valor não poderá ser alterado. A chave `aws:SourceIdentity` estará presente no contexto da solicitação para todas as ações executadas pelo perfil. A identidade-fonte persiste nas sessões de perfil subsequentes quando você usa as credenciais da sessão para assumir outro perfil. Assumir uma função de outra é chamado de [encadeamento de funções](id_roles.md#iam-term-role-chaining). A política a seguir mostra um exemplo de como é possível negar acesso a sessões temporárias de credenciais de segurança usando a chave de contexto de condição `aws:SourceIdentity`. Se você especificar a identidade-fonte associada a uma sessão de perfil, serão negadas sessões de perfil com a identidade-fonte nomeada sem afetar as permissões da perfil que criou as credenciais. Neste exemplo, a identidade de origem definida pela entidade principal quando a sessão de perfil foi emitida é `nikki_wolf@example.com`. Qualquer solicitação feita por uma sessão de perfil com a identidade-fonte `nikki_wolf@example.com` será negada porque a identidade-fonte está incluída na condição da política e a política Efeito está definida como `Deny`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringLike": { "aws:SourceIdentity": [ "nikki_wolf@example.com", "" ] } } } ] } ``` ------ ### aws:userid Você pode usar a chave de contexto de condição [aws:userid](reference_policies_condition-keys.md#condition-keys-userid) em uma política baseada em identidade para negar acesso a todas ou a determinadas sessões de credenciais de segurança temporárias associadas ao usuário ou perfil do IAM. Isso é feito especificando o identificador exclusivo (ID) da sessão do usuário do IAM, do perfil ou do usuário federado do AWS STS à qual as credenciais de segurança temporárias estão associadas no elemento `Condition` de uma política. A política a seguir mostra um exemplo de como é possível negar acesso a sessões temporárias de credenciais de segurança usando a chave de contexto de condição `aws:userid`. + `AIDAXUSER1` representa o ID exclusivo de um usuário do IAM. Especificar o ID exclusivo de um usuário do IAM como um valor para a chave de contexto `aws:userid` negará acesso ao usuário do IAM. Isso inclui todas as sessões de credenciais de segurança temporárias que foram criadas chamando a API `GetSessionToken`. + `AROAXROLE1:*` representa o ID exclusivo de todas as sessões associadas ao perfil do IAM. Especificar o ID exclusivo de um perfil do IAM e um caractere curinga (\$1) na porção caller-specified-role-session-name como um valor para a chave de contexto `aws:userid` negará todas as sessões associadas ao perfil. + `AROAXROLE2:` representa o ID exclusivo de uma sessão de perfil assumido. Na porção caller-specified-role-session-name do ID exclusivo do perfil assumido, você poderá especificar o nome da sessão do perfil ou um caractere curinga se o operador de condição StringLike for usado. Se você especificar o nome da sessão do perfil, isso negará a sessão do perfil nomeada sem afetar as permissões do perfil que criou as credenciais. Se você especificar um caractere curinga para o nome da sessão do perfil, negará todas as sessões associadas ao perfil. **nota** O nome da sessão de perfil especificada pelo chamador, que faz parte do identificador exclusivo de uma sessão de perfil assumida, pode mudar durante o encadeamento de perfis. O encadeamento de perfis ocorre quando um perfil assume outro perfil. O nome da sessão do perfil é definido usando o parâmetro de solicitação `RoleSessionName` quando a entidade principal assume um perfil usando a operação da API `AssumeRole` do AWS STS. + `account-id:` representa o ID exclusivo de uma sessão de usuário federado do AWS STS. Um usuário do IAM cria essa sessão chamando a API `GetFederationToken`. Especificar o ID exclusivo de uma sessão de usuário federado do AWS STS nega a sessão federada nomeada sem afetar as permissões do usuário do IAM que criou as credenciais. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringLike": { "aws:userId": [ "AIDAXUSER1", "AROAXROLE1:*", "AROAXROLE2:", "123456789012:" ] } } } ] } ``` ------ Para exemplos específicos de valores de chave de entidade principal, consulte [Valores de chave de principal](reference_policies_variables.md#principaltable). Para obter informações sobre os identificadores exclusivos do IAM e como obtê-los, consulte [Identificadores exclusivos](reference_identifiers.md#identifiers-unique-ids). ## Negar acesso a uma determinada entidade principal com políticas baseadas em identidade Para restringir o acesso a uma determinada entidade principal com uma política baseada em recurso, você pode usar as chaves de contexto de condição [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) ou [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) no elemento `Condition`. Uma política baseada em recurso é uma política de permissão anexada a um recurso e controla quem pode acessar o recurso e quais ações a pessoa pode executar nele. Quando usar a chave de contexto `aws:PrincipalARN`, especifique o ARN da sessão do usuário do IAM, do perfil ou do usuário federado do AWS STS associada às credenciais de segurança temporárias no elemento de condição de uma política. O exemplo de política a seguir demonstra como usar a chave de contexto `aws:PrincipalARN`em uma política baseada em recurso: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Principal": "*", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket", "Condition": { "ArnEquals": { "aws:PrincipalArn": [ "arn:aws:iam::222222222222:role/ROLENAME", "arn:aws:iam::222222222222:user/USERNAME", "arn:aws:sts::222222222222:federated-user/USERNAME" ] } } } } ``` ------ Quando usar a chave de contexto `aws:SourceIdentity`, especifique o valor da identidade de origem associada às credenciais de segurança temporárias do perfil no elemento `Condition` de uma política. Isso se aplica contanto que a sessão de perfil tenha sido emitida definindo o parâmetro de solicitação `SourceIdentity` quando a entidade principal assumiu um perfil usando qualquer comando `assume-role` da CLI do AWS STS\$1 ou operações da API `AssumeRole` do AWS STS\$1. O exemplo a seguir demonstra como usar a chave de contexto `aws:SourceIdentity` em uma política baseada em recurso: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Principal": "*", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket", "Condition": { "StringLike": { "aws:SourceIdentity": [ "nikki_wolf@example.com", "" ] } } } } ``` ------ Se você atualizar apenas a política baseada em identidade para uma entidade principal, ainda será possível executar as ações permitidas na política baseada em recurso, exceto quando essas ações forem explicitamente negadas na política baseada em identidade. **Para negar acesso a uma determinada entidade principal com uma política baseada em identidade** 1. Consulte [AWSServiços da que funcionam com o IAM](reference_aws-services-that-work-with-iam.md) para ver se o serviço oferece suporte a políticas baseadas em recursos. 1. Faça login no Console de gerenciamento da AWS e abra o console do serviço. Cada serviço tem uma localização diferente no console para anexar políticas. 1. Edite a política baseada em recurso. Adicione uma instrução de política "Deny" para especificar as informações de identificação da credencial: 1. No elemento `Principal`, insira o curinga (\$1). A entidade principal será restringida no elemento `Condition`. 1. No elemento `Effect`, insira “Deny.” 1. Em `Action`, insira o namespace do serviço e o nome da ação a ser negada. Para negar todas as ações, use o caractere curinga (\$1). Por exemplo: `"s3:*"`. 1. No elemento `Resource`, insira o ARN do recurso-alvo. Por exemplo: `"arn:aws:s3:::amzn-s3-demo-bucket"`. 1. No elemento `Condition`, especifique a chave de contexto `aws:PrincipalARN` ou `aws:SourceIdentity`. Se você usar a chave de contexto `aws:PrincipalARN`, insira o ARN da entidade principal à qual negar acesso. Se você usar a chave de contexto `aws:SourceIdentity`, insira o valor da identidade de origem definido na sessão de perfil à qual negar acesso. 1. Salve seu trabalho. # Conceder permissões para criar credenciais de segurança temporárias Por padrão, os usuários do IAM não têm permissão para criar credenciais de segurança temporárias para sessões de usuários federados do AWS STS e perfis. Você deve usar uma política para fornecer essas permissões aos usuários. Embora você possa conceder permissões diretamente a um usuário, é altamente recomendável que você conceda permissões para um grupo. Isso torna o gerenciamento de permissões muito mais fácil. Quando alguém não precisar mais executar as tarefas associadas às permissões, bastará removê-las do grupo. Se outra pessoa precisa executar essa tarefa, adicione-a ao grupo para conceder as permissões. Para conceder a um grupo do IAM permissão para criar credenciais de segurança temporárias para sessões de usuários federados do AWS STS ou perfid, anexe uma política que conceda um ou ambos os seguintes privilégios: + Para entidades principais federadas OIDC e SAML acessarem um perfil do IAM, conceda acesso a `AssumeRole` do AWS STS. + Para usuários federados do AWS STS que não precisam de um perfil, conceda acesso a `GetFederationToken` do AWS STS. Para obter mais informações sobre as diferenças entre o `AssumeRole` e `GetFederationToken` operações de API, consulte [Solicitar credenciais de segurança temporárias](id_credentials_temp_request.md). Os usuários do IAM também podem chamar [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) para criar credenciais de segurança temporárias. Nenhuma permissão é necessária para um usuário realizar a chamada `GetSessionToken`. O objetivo dessa operação é autenticar o usuário que usa a MFA. Não é possível usar políticas para controlar a autenticação. Isso significa que não é possível impedir que os usuários do IAM chamem `GetSessionToken` para criar credenciais temporárias. **Example Exemplo de política que concede permissão para assumir uma função** O exemplo de política a seguir concede permissão para chamar `AssumeRole` para o perfil `UpdateApp` na Conta da AWS `123123123123`. Quando `AssumeRole` é usado, o usuário (ou o aplicativo) que cria as credenciais de segurança em nome de um usuário federado não pode delegar permissões que já não tenham sido especificadas na política de permissões da função. **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::123123123123:role/UpdateAPP" }] } ``` **Example Exemplo de política que concede permissão para criar credenciais de segurança temporárias para um usuário federado** No exemplo a seguir a política concede permissões de acesso `GetFederationToken`. **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sts:GetFederationToken", "Resource": "*" }] } ``` **Importante** Quando você concede a usuários do IAM permissão para criar credenciais de segurança temporárias para usuários federados do AWS STS com `GetFederationToken`, isso permite que eles deleguem suas próprias permissões. Para obter mais informações sobre a delegação de permissões entre usuários do IAM e Contas da AWS, consulte [Exemplos de políticas para delegação de acesso](id_roles_create_policy-examples.md). Para obter mais informações sobre o controle de permissões em credenciais de segurança temporárias, consulte [Permissões de credenciais de segurança temporárias](id_credentials_temp_control-access.md). **Example Exemplo de política que concede a um usuário permissão limitada para criar credenciais de segurança temporárias para usuários federados** Quando você permite que um usuário do IAM chame `GetFederationToken`, uma prática recomendada é restringir as permissões que esse usuário do IAM pode delegar. Por exemplo, a política a seguir mostra como permitir que um usuário do IAM crie credenciais de segurança temporárias apenas para usuários federados do AWS STS cujos nomes começam com *Manager*. **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sts:GetFederationToken", "Resource": ["arn:aws:sts::123456789012:federated-user/Manager*"] }] } ``` # Concessão de permissões para o uso de sessões de console aprimoradas com identidade As sessões de console aprimoradas com identidade possibilitam que os IDs de usuário e de sessão do Centro de Identidade do AWS IAM sejam incluídos nas sessões de console da AWS quando os usuários fizerem login. Por exemplo, o Amazon Q Developer Pro usa as sessões de console aprimoradas com identidade para oferecer uma experiência de serviço personalizada. Para obter mais informações sobre as sessões de console aprimoradas com identidade, consulte [Enabling identity-enhanced console sessions](https://docs.aws.amazon.com/singlesignon/latest/userguide/identity-enhanced-sessions.html) no *Guia do usuário do Centro de Identidade do AWS IAM*. Para obter informações sobre a configuração do Amazon Q Developer, consulte [Configurando o Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/setting-up.html) no *Guia do usuário do Amazon Q Developer*. Para que as sessões de console aprimoradas com identidade estejam disponíveis para um usuário, é necessário usar uma política baseada em identidades para conceder à entidade principal do IAM a permissão `sts:SetContext` no recurso que representa sua própria sessão de console. **Importante** Por padrão, os usuários não têm permissão para configurar o contexto em suas sessões de console aprimoradas com identidade. Para permitir isso, você deve conceder a entidade principal do IAM a permissão `sts:SetContext` em uma política baseada em identidade, conforme mostrado no exemplo de política abaixo. O exemplo de política baseada em identidades, apresentado a seguir, concede a permissão `sts:SetContext` a uma entidade principal do IAM, permitindo que essa entidade defina o contexto da sessão de console aprimorada com identidade para suas próprias sessões no console da AWS. O recurso de política, `arn:aws:sts::account-id:self`, representa a sessão do chamador da AWS. O segmento do `account-id` do ARN pode ser substituído por um caractere curinga `*` nos casos em que a mesma política de permissão é implantada em várias contas, como quando essa política é implantada usando os conjuntos de permissões do IAM Identity Center. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:SetContext", "Resource": "arn:aws:sts::111122223333:self" } ] } ``` ------ # Gerenciar o AWS STS em uma Região da AWS Um endpoint regional é a URL do ponto de entrada em uma região específica para um serviço da Web da AWS. A AWS recomenda o uso dos endpoints regionais do AWS Security Token Service (AWS STS) em vez do endpoint global, para reduzir a latência, incorporar redundância e aumentar a validade dos tokens de sessão. Embora o endpoint global (legado) do AWS STS, `https://sts.amazonaws.com`, esteja altamente disponível, ele é hospedado em uma única região da AWS, Leste dos EUA (Norte da Virgínia), e, como outros endpoints, não fornece failover automático para endpoints em outras regiões. + **Reduzir a latência**: ao fazer suas chamadas do AWS STS para um endpoint geograficamente mais próximo de seus serviços e aplicações, você pode acessar serviços do AWS STS com menor latência e melhores tempos de resposta. + **Incorporar redundância** — Você pode limitar os efeitos de uma falha em uma workload a um número limitado de componentes com um escopo previsível de contenção de impactos. O uso de endpoints regionais do AWS STS permite alinhar o escopo de seus componentes com o escopo de seus tokens de sessão. Para obter mais informações sobre esse pilar de confiabilidade, consulte [Usar isolamento de falhas para proteger sua workload](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) no *AWS Well-Architected Framework*. + **Aumentar a validade do token de sessão**: tokens de sessão de endpoints regionais do AWS STS são válidos em todas as Regiões da AWS. Tokens de sessão do endpoint global do STS são válidos apenas em Regiões da AWS que são habilitadas por padrão. Se pretende habilitar uma nova região para sua conta, você pode usar tokens de sessão de endpoints regionais do AWS STS. Se optar por usar o endpoint global, você deverá alterar a compatibilidade de regiões de tokens de sessão do AWS STS para o endpoint global. Isso garante que os tokens sejam válidos em todas as Regiões da AWS. Para obter uma lista de regiões da AWS STS e seus endpoints, consulte [AWS STSRegiões e endpoints do](id_credentials_temp_region-endpoints.md). **nota** A AWS fez alterações no endpoint global (`https://sts.amazonaws.com`) do AWS Security Token Service (AWS STS) nas regiões [habilitadas por padrão](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) para aprimorar sua resiliência e desempenho. As solicitações do AWS STS para o endpoint global são atendidas automaticamente da mesma Região da AWS que suas workloads. Essas alterações não serão implantadas em regiões opt-in. Recomendamos usar endpoints regionais do AWS STS apropriados. Para obter mais informações, consulte [Alterações nos endpoints globais do AWS STS](id_credentials_temp_region-endpoints.md#reference_sts_global_endpoint_changes). **Topics** + [Ativar e desativar o AWS STS em uma Região da AWS](#sts-regions-activate-deactivate) + [Escrever código para usar regiões do AWS STS](#id_credentials_temp_enable-regions_writing_code) + [Gerenciar tokens de sessão de endpoint global](#sts-regions-manage-tokens) ## Ativar e desativar o AWS STS em uma Região da AWS Quando você ativar endpoints do AWS STS para uma região, o AWS STS poderá emitir credenciais temporárias para usuários e funções em sua conta que faz uma solicitação do AWS STS. Essas credenciais podem ser usadas em qualquer região habilitada por padrão ou habilitada manualmente. Para regiões que são habilitadas por padrão, é necessário ativar o endpoint do AWS STS regional na conta em que as credenciais temporárias são geradas. Não importa se um usuário está conectado na mesma conta ou em uma conta diferente quando fizer a solicitação. Ao solicitar credenciais temporárias para uma função em outra Conta da AWS usando uma região ativada manualmente, a conta de destino (a conta que contém a função) deve habilitar essa região para operações AWS STS. Esta é uma forma de garantir que as credenciais de segurança temporárias possam ser geradas corretamente. Por exemplo, imagine que um usuário na conta A deseje enviar uma solicitação de API `sts:AssumeRole` ao [endpoint regional do AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html) `https://sts.ap-southeast-3.amazonaws.com`. A solicitação é para credenciais temporárias para a função denominada `Developer` na conta B. Como a solicitação é para criar credenciais para uma entidade na conta B, a conta B deve ter a região `ap-southeast-3` ativada. Os usuários da conta A (ou de qualquer outra conta) podem chamar o endpoint do AWS STS `ap-southeast-3` para solicitar credenciais para a conta B, esteja ou não ativada a região em suas contas. Para saber mais, consulte [Ativar ou desativar Regiões da AWS em sua conta](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html). **nota** Regiões ativas estão disponíveis para todas as pessoas que usam credenciais temporárias nessa conta. Para controlar quais usuários ou perfis do IAM podem acessar a região, use a chave de condição `aws:RequestedRegion` em suas políticas de permissões. **Para ativar ou desativar o AWS STS em uma região habilitada por padrão (console)** 1. Faça login como um usuário raiz ou um usuário com permissões para realizar tarefas de administração do IAM. 1. Abra o [console do IAM](https://console.aws.amazon.com/iam/home?#home) e, no painel de navegação, escolha [https://console.aws.amazon.com/iam/home?#account_settings](https://console.aws.amazon.com/iam/home?#account_settings) (Configurações da conta). 1. Na seção **Endpoints** do **Security Token Service (STS)**, localize a região que você deseja configurar e escolha **Ativa** ou **Inativa** na coluna **Status do STS**. 1. Na caixa de diálogo que é exibida, escolha **Activate** (Ativar) ou **Deactivate** (Desativar). Para regiões que precisam ser habilitadas, o AWS STS é ativado automaticamente quando você habilita a região. Depois de habilitar uma região, o AWS STS estará sempre ativo nessa região e você não poderá desativá-lo. Para saber como habilitar regiões que estão desabilitadas por padrão, consulte [Especificar qual Regiões da AWS sua conta pode usar](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) no *Guia de referência do AWS Gerenciamento de contas*. ## Escrever código para usar regiões do AWS STS Depois de ativar uma região, você pode direcionar chamadas de API do AWS STS para essa região. O trecho de código Java a seguir demonstra como configurar um objeto `AWSSecurityTokenService` para fazer solicitações para a região Europa (Milão) (eu-south-1). ``` EndpointConfiguration regionEndpointConfig = new EndpointConfiguration("https://sts.eu-south-1.amazonaws.com", "eu-south-1"); AWSSecurityTokenService stsRegionalClient = AWSSecurityTokenServiceClientBuilder.standard() .withCredentials(credentials) .withEndpointConfiguration(regionEndpointConfig) .build(); ``` AWS STSO recomenda fazer chamadas para um endpoint regional. Para obter informações sobre como habilitar manualmente uma região, consulte [Especificar quais Regiões da AWS sua conta pode usar](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) no *Guia de referência do AWS Gerenciamento de contas*. No exemplo, a primeira linha cria uma instância de objeto `EndpointConfiguration` chamado `regionEndpointConfig`, passando o URL do endpoint e a Região da AWS como os parâmetros. Para aprender a configurar endpoints regionais do AWS STS usando uma variável de ambiente para AWS SDKs, consulte [Endpoints regionalizados do AWS STS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html) no *Guia de referência de AWS SDKs e ferramentas*. Para todas as outras combinações de linguagem e ambiente de programação, consulte a documentação das [para o SDK relevante](https://aws.amazon.com/tools/). ## Gerenciar tokens de sessão de endpoint global Por padrão, a maioria das Regiões da AWS está habilitada para operações em todos os Serviços da AWS. Essas regiões são automaticamente habilitadas para uso com o AWS STS. Algumas regiões, como Ásia-Pacífico (Hong Kong), devem ser habilitadas manualmente. Para saber como habilitar e desabilitar Regiões da AWS, consulte [Especificar qual Regiões da AWS sua conta pode usar](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) no *Guia de referência do AWS Gerenciamento de contas*. Quando você habilitar essas regiões da AWS, elas serão automaticamente habilitadas para uso com o AWS STS. Você não pode ativar o endpoint do AWS STS para uma região que está desabilitada. Tokens de sessão que são válidos em todas as Regiões da AWS incluem mais caracteres do que os tokens que são válidos em regiões habilitadas por padrão. A alteração dessa configuração pode afetar sistemas existentes em que você armazena tokens temporariamente. Você pode alterar essa configuração usando o Console de gerenciamento da AWS, a AWS CLI, ou a API da AWS. **Para alterar a compatibilidade de regiões dos tokens de sessão para o endpoint global (console)** 1. Faça login como um usuário raiz ou um usuário com permissões para realizar tarefas de administração do IAM. Para alterar a compatibilidade de tokens de sessão, você deve ter uma política que permita a ação `iam:SetSecurityTokenServicePreferences`. 1. Abra o [console do IAM](https://console.aws.amazon.com/iam/home?#home). No painel de navegação, selecione **Configurações da conta**. 1. Em **Security Token Service (STS)**, na seção **Session Tokens from the STS endpoints** (Tokens de sessão dos endpoints do STS). O **endpoint global** indica `Valid only in Regiões da AWS enabled by default`. Escolha **Alterar**. 1. Na caixa de diálogo **Alterar compatibilidade da região**, selecione **Todas as Regiões da AWS**. Em seguida, escolha **Salvar alterações**. **nota** Tokens de sessão que são válidos em todas as Região da AWS incluem mais caracteres do que os tokens que são válidos em regiões habilitadas por padrão. A alteração dessa configuração pode afetar sistemas existentes em que você armazena tokens temporariamente. **Para alterar a compatibilidade de regiões de tokens de sessão para o endpoint global (AWS CLI)** Defina a versão do token da sessão. Tokens de versão 1 são válidos somente em Regiões da AWS que estão disponíveis por padrão. Esses tokens não funcionam em regiões habilitadas manualmente, como Ásia-Pacífico (Hong Kong). Tokens de versão 2 são válidos em todas as regiões. No entanto, tokens de versão 2 incluem mais caracteres e podem afetar sistemas em que você armazena tokens temporariamente. + [https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html](https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html) **Para alterar a compatibilidade de regiões de tokens de sessão para o endpoint global (API da AWS)** Defina a versão do token da sessão. Tokens de versão 1 são válidos somente em Regiões da AWS que estão disponíveis por padrão. Esses tokens não funcionam em regiões habilitadas manualmente, como Ásia-Pacífico (Hong Kong). Tokens de versão 2 são válidos em todas as regiões. No entanto, tokens de versão 2 incluem mais caracteres e podem afetar sistemas em que você armazena tokens temporariamente. + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html) # AWS STSRegiões e endpoints do **nota** A AWS fez alterações no endpoint global (`https://sts.amazonaws.com`) do AWS Security Token Service (AWS STS) nas regiões [habilitadas por padrão](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) para aprimorar sua resiliência e desempenho. As solicitações de AWS STS para o endpoint global são atendidas automaticamente da mesma Região da AWS que suas workloads. Essas alterações não serão implantadas em regiões opt-in. Recomendamos usar endpoints regionais do AWS STS apropriados. Para obter mais informações, consulte [Alterações nos endpoints globais do AWS STS](#reference_sts_global_endpoint_changes). A tabela a seguir lista as regiões e seus endpoints. Ela indica quais são as ativadas por padrão e quais você pode ativar ou desativar. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html) ¹Você deve [habilitar a região](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) para usá-la. Isso ativa automaticamente o AWS STS. Não é possível ativar ou desativar manualmente o AWS STS nessas regiões. ²Para usar a AWS na China, são necessárias uma conta e credenciais específicas da AWS na China. ## Alterações nos endpoints globais do AWS STS A AWS fez alterações no endpoint global (`https://sts.amazonaws.com`) do AWS Security Token Service (AWS STS) em regiões [habilitadas por padrão](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) para aprimorar sua resiliência e performance. Anteriormente, todas as solicitações ao endpoint global do AWS STS eram atendidas por uma única Região da AWS Leste dos EUA (Norte da Virgínia). Agora, nas regiões [habilitadas por padrão](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html), as solicitações para o endpoint global do AWS STS serão atendidas automaticamente na mesma região de origem da solicitação, em vez da região Leste dos EUA (Norte da Virgínia). Essas alterações não serão implantadas em regiões opt-in. Com essas alterações, o AWS STS processará sua solicitação com base na região de origem e no resolvedor de DNS usado. As solicitações ao endpoint global do AWS STS são atendidas na mesma região da sua workload implantada da AWS se a solicitação de DNS ao endpoint global do AWS STS for tratada pelo servidor Amazon DNS em regiões habilitadas por padrão. As solicitações ao endpoint global do AWS STS continuarão sendo atendidas na região Leste dos EUA (Norte da Virgínia) se sua solicitação tiver sido originada de regiões opcionais ou se sua solicitação tiver sido resolvida usando um resolvedor de DNS diferente do servidor Amazon DNS. Para obter mais informações sobre o Amazon DNS, consulte [Servidor Amazon DNS](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#AmazonDNS) no *Guia do usuário da Amazon Virtual Private Cloud*. A tabela a seguir mostra como as solicitações ao endpoint global do AWS STS são roteadas com base em seu provedor de DNS. | Resolvedor de DNS | Solicitações ao endpoint global do AWS STS roteadas para a Região da AWS local? | | --- | --- | | Resolvedor do Amazon DNS em uma Amazon VPC em uma região habilitada por padrão | Sim | | Resolvedor do Amazon DNS em uma Amazon VPC em uma região opt-in | Não, a solicitação será encaminhada para a região Leste dos EUA (Norte da Virgínia) | | Resolvedor de DNS fornecido pelo seu ISP, um provedor de DNS público ou qualquer outro provedor de DNS | Não, a solicitação será encaminhada para a região Leste dos EUA (Norte da Virgínia) | Para garantir o mínimo de interrupção em seus processos existentes, a AWS implementou as seguintes medidas: + Os logs do AWS CloudTrail para solicitações feitas ao endpoint global do AWS STS são enviados para a região Leste dos EUA (Norte da Virgínia). Os logs do CloudTrail para solicitações atendidas por endpoints regionais do AWS STS continuarão sendo registrados em suas respectivas regiões no CloudTrail. + Os logs do CloudTrail para operações realizadas pelo endpoint global do AWS STS e pelos endpoints regionais tem campos adicionais `endpointType` e `awsServingRegion` para indicar qual endpoint e região atenderam à solicitação. Para obter exemplos de log do CloudTrail, consulte [Exemplo de evento de API AWS STS usando o endpoint global no arquivo de log do CloudTrail](cloudtrail-integration.md#stscloudtrailexample-assumerole-sts-global-endpoint). + As solicitações feitas ao endpoint global do AWS STS tem um valor de `us-east-1` para a chave de condição `aws:RequestedRegion`, independentemente de qual região atendeu à solicitação. + As solicitações tratadas pelo endpoint global do AWS STS não compartilham uma cota de solicitações por segundo com endpoints regionais do AWS STS. Se você tiver workloads em uma região opt-in e ainda estiver usando o endpoint global do AWS STS, recomendamos migrar para endpoints regionais do AWS STS para melhorar a resiliência e a performance. Para obter mais informações sobre a configuração de endpoints regionais do AWS STS, consulte [Endpoints regionais do AWS STS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html) no *Guia de referência de SDKs e ferramentas da AWS*. ## AWS CloudTrail e endpoints regionais As chamadas para endpoints regionais e globais são registradas no campo `tlsDetails` no AWS CloudTrail. As chamadas para endpoints regionais, como `us-east-2.amazonaws.com`, são registradas no CloudTrail em sua região apropriada. As chamadas para o endpoint global, `sts.amazonaws.com`, são registradas como chamadas para um serviço global. Os eventos para endpoints globais de AWS STS são registrados em us-east-1. **nota** `tlsDetails` só pode ser visualizado para serviços que oferecem suporte a esse campo. Consulte [Serviços que oferecem suporte a detalhes de TLS no CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-supported-tls-details.html) no *Guia de usuário do AWS CloudTrail* Para obter mais informações, consulte [Registro em log de chamadas de API do IAM e do AWS STS com o AWS CloudTrail](cloudtrail-integration.md). # Habilitar o acesso do intermediador de identidades personalizado ao console da AWS Você pode escrever e executar um código para criar um URL que permita que os usuários que façam login na rede de sua organização acessem com segurança o Console de gerenciamento da AWS. O URL inclui um token de login que você obtém da AWS e que autentica o usuário na AWS. A sessão de console resultante pode incluir um `AccessKeyId` diferente devido à federação. [Para rastrear o uso da chave de acesso para o login da federação por meio de eventos relacionados do CloudTrail, consulte [Registro em log de chamadas de API do IAM e do AWS STS com o AWS CloudTrail](cloudtrail-integration.md) e Eventos de login do Console de gerenciamento da AWS](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-aws-console-sign-in-events.html). **nota** Se sua organização usa um provedor de identidade (IdP) que é compatível com SAML, é possível configurar o acesso ao console sem escrever código. Isso funciona com fornecedores como o Microsoft Active Directory Federation Services ou o Shibboleth de código aberto. Para obter detalhes, 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). Para permitir que os usuários de sua organização acessem o Console de gerenciamento da AWS, você pode criar um *intermediador de identidades* personalizado que executa as seguintes etapas: 1. Verificar se o usuário está autenticado pelo seu sistema de identidades local. 1. Chame as operações de API do AWS Security Token Service (AWS STS) [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) (recomendado) ou [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) para obter credenciais de segurança temporárias para o usuário. Para saber mais sobre os diferentes métodos que você pode usar para assumir uma função, consulte [Métodos para assumir um perfil](id_roles_manage-assume.md). Para saber como passar tags de sessão opcionais ao obter suas credenciais de segurança, consulte [Passar tags de sessão no AWS STS](id_session-tags.md). + Se você usar uma das operações de API `AssumeRole*` para obter as credenciais de segurança temporárias para uma função, poderá incluir o parâmetro `DurationSeconds` na chamada. Esse parâmetro especifica a duração da sessão da função de 900 segundos (15 minutos) até o valor configurado de duração máxima da sessão para a função. Ao usar `DurationSeconds` em uma operação `AssumeRole*`, você deve chamá-la como um usuário do IAM com credenciais de longo prazo. Caso contrário, a chamada para o endpoint de federação na etapa 3 falhará. Para saber como visualizar ou alterar o valor máximo de uma função, consulte [Atualizar a duração máxima da sessão de um perfil](id_roles_update-role-settings.md#id_roles_update-session-duration). + Se você usar a operação de API `GetFederationToken` para obter as credenciais, poderá incluir o parâmetro `DurationSeconds` na chamada. Esse parâmetro especifica a duração da sessão da função. O valor pode variar de 900 segundos (15 minutos) a 129.600 segundos (36 horas). Você só pode fazer essa chamada de API usando as credenciais de segurança da AWS de longo prazo de um usuário do IAM. Você também pode fazer essas chamadas usando credenciais de Usuário raiz da conta da AWS, mas isso não é recomendado. Se você fizer essa chamada como usuário raiz, a sessão padrão durará por uma hora. Ou você pode especificar uma sessão de 900 segundos (15 minutos) até 3.600 segundos (uma hora). 1. Chamar o endpoint de federação da AWS e fornecer as credenciais de segurança temporárias para solicitar um token de login. 1. Construir um URL para o console que inclui o token: + Se você usar uma das operações da API `AssumeRole*` em seu URL, poderá incluir o parâmetro HTTP `SessionDuration`. Esse parâmetro especifica a duração da sessão do console de 900 segundos (15 minutos) a 43.200 segundos (12 horas). + Se você usar a operação de API `GetFederationToken` em seu URL, poderá incluir o parâmetro `DurationSeconds`. Esse parâmetro especifica a duração da sessão do console federado. O valor pode variar de 900 segundos (15 minutos) a 129.600 segundos (36 horas). **nota** A `SessionDuration` não pode ser maior ou igual à configuração de duração máxima da sessão para o perfil que você está assumindo. Por exemplo, você definiu a duração máxima da sessão para o perfil que deseja assumir como 5 horas. Seu parâmetro `SessionDuration` pode ser 16524 segundos ou 4 horas e 59 segundos. Não use o parâmetro HTTP `SessionDuration` quando obtiver as credenciais temporárias com `GetFederationToken`. A operação vai falhar. O uso de credenciais de uma função para assumir outra função é chamado de [*encadeamento de funções*](id_roles.md#iam-term-role-chaining). Quando você usa o encadeamento de funções, suas novas credenciais são limitadas a uma duração máxima de uma hora. Quando você usa funções para [conceder permissões a aplicativos executados em instâncias do EC2](id_roles_use_switch-role-ec2.md), esses aplicativos não estão sujeitos a essa limitação. Não use o parâmetro HTTP `SessionDuration` quando obtiver as credenciais temporárias por meio do encadeamento de perfis. A operação vai falhar. 1. Fornecer o URL para o usuário ou invocar o URL em nome do usuário. O URL que o endpoint de federação fornece é válido por 15 minutos após sua criação. Esse valor é diferente da duração (em segundos) da sessão com credenciais de segurança temporárias que é associada ao URL. Essas credenciais são válidas pela duração especificada quando você as criou, a partir do momento em que elas foram criadas. **Importante** O URL concede acesso aos seus recursos da AWS por meio do Console de gerenciamento da AWS se você habilitou permissões nas credenciais de segurança temporárias associadas. Por esse motivo, você deve tratar o URL como um segredo. Recomendamos o retorno do URL através de um redirecionamento seguro, por exemplo, usando um código de status de resposta HTTP 302 por meio de uma conexão SSL. Para obter mais informações sobre o código de status de resposta HTTP 302, consulte [RFC 2616, seção 10.3.3](https://datatracker.ietf.org/doc/html/rfc2616#section-10.3.3). Para concluir essas tarefas, você pode usar a [API de consulta HTTPS para o AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/APIReference/) e o [AWS Security Token Service (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/). Ou então, use linguagens de programação, como Java, Ruby ou C\$1, juntamente com o [SDK da AWS](https://aws.amazon.com/tools/). Cada um desses métodos é descrito nos tópicos a seguir. **Topics** + [Código de exemplo usando operações de API de consulta do IAM](#STSConsoleLink_manual) + [Exemplo de código que usa o Python](#STSConsoleLink_programPython) + [Exemplo de código usando Java](#STSConsoleLink_programJava) + [Exemplo que mostra como criar o URL (Ruby)](#STSConsoleLink_programRuby) ## Código de exemplo usando operações de API de consulta do IAM Você pode construir um URL que conceda a perfis e entidades principais federadas acesso direto ao Console de gerenciamento da AWS. Esta tarefa usa a API de consulta HTTPS do IAM e do AWS STS. Para obter mais informações sobre como fazer solicitações de consulta, consulte [Como fazer solicitações de consulta](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UsingQueryAPI.html). **nota** O procedimento a seguir contém exemplos de strings de texto. Para melhorar a legibilidade, quebras de linha foram adicionadas em alguns dos exemplos mais longos. Quando você criar estas strings para seu próprio uso, você deve omitir as quebras de linha. **Para conceder a perfis e entidades principais federados acesso aos seus recursos via Console de gerenciamento da AWS** 1. Autentique o usuário em seu sistema de identidades e autorização. 1. Obtenha credenciais de segurança temporárias para o usuário. As credenciais de segurança temporárias consistem em um ID de chave de acesso, uma chave de acesso secreta e um token de sessão. Para obter mais informações sobre a criação de credenciais de segurança temporárias, consulte [Credenciais de segurança temporárias no IAM](id_credentials_temp.md). Para obter credenciais temporárias, você pode chamar a API [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) (recomendado) ou a API [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) do AWS STS. Para obter mais informações sobre as diferenças entre essas operações de API, consulte [Compreenda as opções de API para delegação segura de acesso à sua conta da AWS](https://aws.amazon.com/blogs/security/understanding-the-api-options-for-securely-delegating-access-to-your-aws-account) no blog de segurança da AWS. **Importante** Quando você usa a API [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) para criar credenciais de segurança temporárias, deve especificar as permissões que as credenciais vão conceder ao usuário que assume a função. Para qualquer uma das operações de API que começam com `AssumeRole*`, você usa uma função do IAM para atribuir permissões. Para as outras operações de API, o mecanismo varia de acordo com a API. Para obter mais detalhes, consulte [Permissões de credenciais de segurança temporárias](id_credentials_temp_control-access.md). Além disso, se você usar as operações de API `AssumeRole*`, deverá chamá-las como um usuário do IAM com credenciais de longo prazo. Caso contrário, a chamada para o endpoint de federação na etapa 3 falhará. 1. Depois que você obter as credenciais de segurança temporárias, incorpore as credenciais em uma string de sessão JSON para trocá-las por um token de login. O exemplo a seguir mostra como codificar as credenciais. Substitua o espaço reservado para texto pelos valores apropriados das credenciais que você recebeu na etapa anterior. ``` {"sessionId":"*** temporary access key ID ***", "sessionKey":"*** temporary secret access key ***", "sessionToken":"*** session token ***"} ``` 1. [Codifique por URL](https://en.wikipedia.org/wiki/Percent-encoding) a string da sessão da etapa anterior. Como as informações que você está codificando são confidenciais, recomendamos que você evite usar um serviço da web para esta codificação. Em vez disso, use uma função ou recurso instalado localmente em seu toolkit de desenvolvimento para codificar essas informações com segurança. Você pode usar a função `urllib.quote_plus` em Python, a função `URLEncoder.encode` em Java ou a função `CGI.escape` em Ruby. Veja os exemplos mais adiante neste tópico. 1. **nota** A AWS é compatível com solicitações POST aqui. Envie a solicitação para o endpoint de federação da AWS: `https://region-code.signin.aws.amazon.com/federation` Para obter uma lista dos possíveis valores de *region-code* (região-código), consulte a coluna **Region** (Região) em [AWS Sign-In endpoints](https://docs.aws.amazon.com/general/latest/gr/signin-service.html) (Endpoints de login da ). Opcionalmente, é possível usar um endpoint de federação de login padrão da AWS: `https://signin.aws.amazon.com/federation` A solicitação deve incluir os parâmetros `Action` e `Session`, e (opcionalmente) se você tiver usado uma operação de API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html), um parâmetro HTTP `SessionDuration` conforme mostrado no exemplo a seguir. ``` Action = getSigninToken SessionDuration = time in seconds Session = *** the URL encoded JSON string created in steps 3 & 4 *** ``` **nota** As instruções a seguir nesta etapa só funcionam usando solicitações GET. O parâmetro HTTP `SessionDuration` especifica a duração da sessão do console federado. Ele é separado da duração das credenciais temporárias que você especifica usando o parâmetro `DurationSeconds`. Você pode especificar um valor `SessionDuration` máximo de 43200 (12 horas). Se o parâmetro `SessionDuration` estiver ausente, a sessão assume a duração das credenciais recuperadas do AWS STS na etapa 2 (cujo padrão é uma hora). Consulte a [documentação da API `AssumeRole`](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) para obter detalhes sobre como especificar a duração usando o parâmetro `DurationSeconds`. A capacidade de criar uma sessão do console com duração superior a uma hora é intrínseca para a operação `getSigninToken` do endpoint de federação. **nota** A `SessionDuration` não pode ser maior ou igual à configuração de duração máxima da sessão para o perfil que você está assumindo. Por exemplo, você definiu a duração máxima da sessão para o perfil que deseja assumir como 5 horas. Seu parâmetro `SessionDuration` pode ser 16524 segundos ou 4 horas e 59 segundos. Não use o parâmetro HTTP `SessionDuration` quando obtiver as credenciais temporárias com `GetFederationToken`. A operação vai falhar. O uso de credenciais de uma função para assumir outra função é chamado de [*encadeamento de funções*](id_roles.md#iam-term-role-chaining). Quando você usa o encadeamento de funções, suas novas credenciais são limitadas a uma duração máxima de uma hora. Quando você usa funções para [conceder permissões a aplicativos executados em instâncias do EC2](id_roles_use_switch-role-ec2.md), esses aplicativos não estão sujeitos a essa limitação. Não use o parâmetro HTTP `SessionDuration` quando obtiver as credenciais temporárias por meio do encadeamento de perfis. A operação vai falhar. Ao ativar as sessões do console com uma duração estendida, você aumenta o risco de exposição das credenciais. Para ajudar a reduzir esse risco, você pode desabilitar imediatamente as sessões ativas do console para qualquer função escolhendo a opção **Revoke Sessions** (Revogar sessões) em **Role Summary** (Resumo da função) na página do console do IAM. Para obter mais informações, consulte [Revogar as credenciais de segurança temporárias do perfil do IAM](id_roles_use_revoke-sessions.md). Veja a seguir um exemplo da possível aparência de sua solicitação. As linhas são distribuídas aqui para legibilidade, mas você deve enviá-la como uma string de linha única. ``` https://signin.aws.amazon.com/federation ?Action=getSigninToken &SessionDuration=1800 &Session=%7B%22sessionId%22%3A+%22ASIAJUMHIZPTOKTBMK5A%22%2C+%22sessionKey%22 %3A+%22LSD7LWI%2FL%2FN%2BgYpan5QFz0XUpc8s7HYjRsgcsrsm%22%2C+%22sessionToken%2 2%3A+%22FQoDYXdzEBQaDLbj3VWv2u50NN%2F3yyLSASwYtWhPnGPMNmzZFfZsL0Qd3vtYHw5A5dW AjOsrkdPkghomIe3mJip5%2F0djDBbo7SmO%2FENDEiCdpsQKodTpleKA8xQq0CwFg6a69xdEBQT8 FipATnLbKoyS4b%2FebhnsTUjZZQWp0wXXqFF7gSm%2FMe2tXe0jzsdP0O12obez9lijPSdF1k2b5 PfGhiuyAR9aD5%2BubM0pY86fKex1qsytjvyTbZ9nXe6DvxVDcnCOhOGETJ7XFkSFdH0v%2FYR25C UAhJ3nXIkIbG7Ucv9cOEpCf%2Fg23ijRgILIBQ%3D%3D%22%7D ``` A resposta do endpoint de federação é um documento JSON com um valor `SigninToken`. Ele se parece com o seguinte exemplo. ``` {"SigninToken":"*** the SigninToken string ***"} ``` 1. **nota** AWSA permite solicitações POST aqui. Finalmente, crie o URL que seus usuários podem usar para acessar o Console de gerenciamento da AWS. O URL é o mesmo URL do endpoint de federação usado em [Step 5](#STSConsoleLink_manual_step5), mais os seguintes parâmetros: ``` ?Action = login &Issuer = *** the form-urlencoded URL for your internal sign-in page *** &Destination = *** the form-urlencoded URL to the desired AWS console page *** &SigninToken = *** the value of SigninToken received in the previous step *** ``` **nota** As instruções a seguir nesta etapa só funcionam usando a API GET. O exemplo a seguir mostra a possível aparência do URL final. O URL é válido por 15 minutos a partir do momento em que ele é criada. As credenciais de segurança temporárias e a sessão do console incorporada dentro do URL são válidas durante o período especificado no parâmetro HTTP `SessionDuration` quando você inicialmente as solicita. ``` https://signin.aws.amazon.com/federation ?Action=login &Issuer=https%3A%2F%2Fexample.com &Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F &SigninToken=VCQgs5qZZt3Q6fn8Tr5EXAMPLEmLnwB7JjUc-SHwnUUWabcRdnWsi4DBn-dvC CZ85wrD0nmldUcZEXAMPLE-vXYH4Q__mleuF_W2BE5HYexbe9y4Of-kje53SsjNNecATfjIzpW1 WibbnH6YcYRiBoffZBGExbEXAMPLE5aiKX4THWjQKC6gg6alHu6JFrnOJoK3dtP6I9a6hi6yPgm iOkPZMmNGmhsvVxetKzr8mx3pxhHbMEXAMPLETv1pij0rok3IyCR2YVcIjqwfWv32HU2Xlj471u 3fU6uOfUComeKiqTGX974xzJOZbdmX_t_lLrhEXAMPLEDDIisSnyHGw2xaZZqudm4mo2uTDk9Pv 9l5K0ZCqIgEXAMPLEcA6tgLPykEWGUyH6BdSC6166n4M4JkXIQgac7_7821YqixsNxZ6rsrpzwf nQoS14O7R0eJCCJ684EXAMPLEZRdBNnuLbUYpz2Iw3vIN0tQgOujwnwydPscM9F7foaEK3jwMkg Apeb1-6L_OB12MZhuFxx55555EXAMPLEhyETEd4ZulKPdXHkgl6T9ZkIlHz2Uy1RUTUhhUxNtSQ nWc5xkbBoEcXqpoSIeK7yhje9Vzhd61AEXAMPLElbWeouACEMG6-Vd3dAgFYd6i5FYoyFrZLWvm 0LSG7RyYKeYN5VIzUk3YWQpyjP0RiT5KUrsUi-NEXAMPLExMOMdoODBEgKQsk-iu2ozh6r8bxwC RNhujg ``` ## Exemplo de código que usa o Python Os exemplos a seguir mostram como usar o Python para construir programaticamente um URL que ofereça aos usuários acesso direto ao Console de gerenciamento da AWS. Veja dois exemplos a seguir: + Federar por meio de solicitações GET à AWS + Federar por meio de solicitações POST à AWS Ambos os exemplos usam [AWS SDK para Python (Boto3)](https://aws.amazon.com/tools/) e a API [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) para obter credenciais de segurança temporárias. Não inclua `SessionDuration` se as credenciais de `AssumeRoleSession` forem provenientes do encadeamento de perfis. Se você incluir `SessionDuration`, a operação vai falhar. ### Usar solicitações GET ``` import urllib, json, sys import requests # 'pip install requests' import boto3 # AWS SDK for Python (Boto3) 'pip install boto3' # Step 1: Authenticate user in your own identity system. # Step 2: Using the access keys for an IAM user in your Conta da AWS, # call "AssumeRole" to get temporary access keys for the role or federated principal # Note: Calls to AWS STS AssumeRole must be signed using the access key ID # and secret access key of an IAM user or using existing temporary credentials. # The credentials can be in Amazon EC2 instance metadata, in environment variables, # or in a configuration file, and will be discovered automatically by the # client('sts') function. For more information, see the Python SDK docs: # http://boto3.readthedocs.io/en/latest/reference/services/sts.html # http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role sts_connection = boto3.client('sts') assumed_role_object = sts_connection.assume_role( RoleArn="arn:aws:iam::account-id:role/ROLE-NAME", RoleSessionName="AssumeRoleSession", ) # Step 3: Format resulting temporary credentials into JSON url_credentials = {} url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId') url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey') url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken') json_string_with_temp_credentials = json.dumps(url_credentials) # Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with # the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials # as parameters. request_parameters = "?Action=getSigninToken" request_parameters += "&SessionDuration=43200" if sys.version_info[0] < 3: def quote_plus_function(s): return urllib.quote_plus(s) else: def quote_plus_function(s): return urllib.parse.quote_plus(s) request_parameters += "&Session=" + quote_plus_function(json_string_with_temp_credentials) request_url = "https://signin.aws.amazon.com/federation" + request_parameters r = requests.get(request_url) # Returns a JSON document with a single element named SigninToken. signin_token = json.loads(r.text) # Step 5: Create URL where users can use the sign-in token to sign in to # the console. This URL must be used within 15 minutes after the # sign-in token was issued. request_parameters = "?Action=login" request_parameters += "&Issuer=Example.org" request_parameters += "&Destination=" + quote_plus_function("https://console.aws.amazon.com/") request_parameters += "&SigninToken=" + signin_token["SigninToken"] request_url = "https://signin.aws.amazon.com/federation" + request_parameters # Send final URL to stdout print (request_url) ``` ### Usar solicitações POST ``` import urllib, json, sys import requests # 'pip install requests' import boto3 # AWS SDK for Python (Boto3) 'pip install boto3' import os from selenium import webdriver # 'pip install selenium', 'brew install chromedriver' # Step 1: Authenticate user in your own identity system. # Step 2: Using the access keys for an IAM user in your AConta da AWS, # call "AssumeRole" to get temporary access keys for the role or federated principal # Note: Calls to AWS STS AssumeRole must be signed using the access key ID # and secret access key of an IAM user or using existing temporary credentials. # The credentials can be in Amazon EC2 instance metadata, in environment variables, # or in a configuration file, and will be discovered automatically by the # client('sts') function. For more information, see the Python SDK docs: # http://boto3.readthedocs.io/en/latest/reference/services/sts.html # http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role if sys.version_info[0] < 3: def quote_plus_function(s): return urllib.quote_plus(s) else: def quote_plus_function(s): return urllib.parse.quote_plus(s) sts_connection = boto3.client('sts') assumed_role_object = sts_connection.assume_role( RoleArn="arn:aws:iam::account-id:role/ROLE-NAME", RoleSessionName="AssumeRoleDemoSession", ) # Step 3: Format resulting temporary credentials into JSON url_credentials = {} url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId') url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey') url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken') json_string_with_temp_credentials = json.dumps(url_credentials) # Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with # the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials # as parameters. request_parameters = {} request_parameters['Action'] = 'getSigninToken' request_parameters['SessionDuration'] = '43200' request_parameters['Session'] = json_string_with_temp_credentials request_url = "https://signin.aws.amazon.com/federation" r = requests.post( request_url, data=request_parameters) # Returns a JSON document with a single element named SigninToken. signin_token = json.loads(r.text) # Step 5: Create a POST request where users can use the sign-in token to sign in to # the console. The POST request must be made within 15 minutes after the # sign-in token was issued. request_parameters = {} request_parameters['Action'] = 'login' request_parameters['Issuer']='Example.org' request_parameters['Destination'] = 'https://console.aws.amazon.com/' request_parameters['SigninToken'] =signin_token['SigninToken'] jsrequest = ''' var form = document.createElement('form'); form.method = 'POST'; form.action = '{request_url}'; request_parameters = {request_parameters} for (var param in request_parameters) {{ if (request_parameters.hasOwnProperty(param)) {{ const hiddenField = document.createElement('input'); hiddenField.type = 'hidden'; hiddenField.name = param; hiddenField.value = request_parameters[param]; form.appendChild(hiddenField); }} }} document.body.appendChild(form); form.submit(); '''.format(request_url=request_url, request_parameters=request_parameters) driver = webdriver.Chrome() driver.execute_script(jsrequest) input("Press Enter to close the browser window...") ``` ## Exemplo de código usando Java O exemplo a seguir mostra como usar Java para construir programaticamente um URL que ofereça aos usuários acesso direto ao Console de gerenciamento da AWS. O trecho de código a seguir usa o [AWS SDK for Java](https://aws.amazon.com/documentation/sdkforjava/). ``` import java.net.URLEncoder; import java.net.URL; import java.net.URLConnection; import java.io.BufferedReader; import java.io.InputStreamReader; // Available at http://www.json.org/java/index.html import org.json.JSONObject; import com.amazonaws.auth.AWSCredentials; import com.amazonaws.auth.BasicAWSCredentials; import com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient; import com.amazonaws.services.securitytoken.model.Credentials; import com.amazonaws.services.securitytoken.model.GetFederationTokenRequest; import com.amazonaws.services.securitytoken.model.GetFederationTokenResult; /* Calls to AWS STS API operations must be signed using the access key ID and secret access key of an IAM user or using existing temporary credentials. The credentials should not be embedded in code. For this example, the code looks for the credentials in a standard configuration file. */ AWSCredentials credentials = new PropertiesCredentials( AwsConsoleApp.class.getResourceAsStream("AwsCredentials.properties")); AWSSecurityTokenServiceClient stsClient = new AWSSecurityTokenServiceClient(credentials); GetFederationTokenRequest getFederationTokenRequest = new GetFederationTokenRequest(); getFederationTokenRequest.setDurationSeconds(1800); getFederationTokenRequest.setName("UserName"); // A sample policy for accessing Amazon Simple Notification Service (Amazon SNS) in the console. String policy = "{\"Version\":\"2012-10-17\", \"Statement\":[{\"Action\":\"sns:*\"," + "\"Effect\":\"Allow\",\"Resource\":\"*\"}]}"; getFederationTokenRequest.setPolicy(policy); GetFederationTokenResult federationTokenResult = stsClient.getFederationToken(getFederationTokenRequest); Credentials federatedCredentials = federationTokenResult.getCredentials(); // The issuer parameter specifies your internal sign-in // page, for example https://mysignin.internal.mycompany.com/. // The console parameter specifies the URL to the destination console of the // AWS Management Console. This example goes to Amazon SNS. // The signin parameter is the URL to send the request to. String issuerURL = "https://mysignin.internal.mycompany.com/"; String consoleURL = "https://console.aws.amazon.com/sns"; String signInURL = "https://signin.aws.amazon.com/federation"; // Create the sign-in token using temporary credentials, // including the access key ID, secret access key, and session token. String sessionJson = String.format( "{\"%1$s\":\"%2$s\",\"%3$s\":\"%4$s\",\"%5$s\":\"%6$s\"}", "sessionId", federatedCredentials.getAccessKeyId(), "sessionKey", federatedCredentials.getSecretAccessKey(), "sessionToken", federatedCredentials.getSessionToken()); // Construct the sign-in request with the request sign-in token action, a // 12-hour console session duration, and the JSON document with temporary // credentials as parameters. String getSigninTokenURL = signInURL + "?Action=getSigninToken" + "&DurationSeconds=43200" + "&SessionType=json&Session=" + URLEncoder.encode(sessionJson,"UTF-8"); URL url = new URL(getSigninTokenURL); // Send the request to the AWS federation endpoint to get the sign-in token URLConnection conn = url.openConnection (); BufferedReader bufferReader = new BufferedReader(new InputStreamReader(conn.getInputStream())); String returnContent = bufferReader.readLine(); String signinToken = new JSONObject(returnContent).getString("SigninToken"); String signinTokenParameter = "&SigninToken=" + URLEncoder.encode(signinToken,"UTF-8"); // The issuer parameter is optional, but recommended. Use it to direct users // to your sign-in page when their session expires. String issuerParameter = "&Issuer=" + URLEncoder.encode(issuerURL, "UTF-8"); // Finally, present the completed URL for the AWS console session to the user String destinationParameter = "&Destination=" + URLEncoder.encode(consoleURL,"UTF-8"); String loginURL = signInURL + "?Action=login" + signinTokenParameter + issuerParameter + destinationParameter; ``` ## Exemplo que mostra como criar o URL (Ruby) O exemplo a seguir mostra como usar Ruby para construir programaticamente um URL que ofereça aos usuários acesso direto ao Console de gerenciamento da AWS. Esse trecho de código usa o [AWS SDK for Ruby](https://aws.amazon.com/documentation/sdkforruby/). ``` require 'rubygems' require 'json' require 'open-uri' require 'cgi' require 'aws-sdk' # Create a new STS instance # # Note: Calls to AWS STS API operations must be signed using an access key ID # and secret access key. The credentials can be in EC2 instance metadata # or in environment variables and will be automatically discovered by # the default credentials provider in the AWS Ruby SDK. sts = Aws::STS::Client.new() # The following call creates a temporary session that returns # temporary security credentials and a session token. # The policy grants permissions to work # in the AWS SNS console. session = sts.get_federation_token({ duration_seconds: 1800, name: "UserName", policy: "{\"Version\":\"2012-10-17\", \"Statement\":{\"Effect\":\"Allow\",\"Action\":\"sns:*\",\"Resource\":\"*\"}}", }) # The issuer value is the URL where users are directed (such as # to your internal sign-in page) when their session expires. # # The console value specifies the URL to the destination console. # This example goes to the Amazon SNS console. # # The sign-in value is the URL of the AWS STS federation endpoint. issuer_url = "https://mysignin.internal.mycompany.com/" console_url = "https://console.aws.amazon.com/sns" signin_url = "https://signin.aws.amazon.com/federation" # Create a block of JSON that contains the temporary credentials # (including the access key ID, secret access key, and session token). session_json = { :sessionId => session.credentials[:access_key_id], :sessionKey => session.credentials[:secret_access_key], :sessionToken => session.credentials[:session_token] }.to_json # Call the federation endpoint, passing the parameters # created earlier and the session information as a JSON block. # The request returns a sign-in token that's valid for 15 minutes. # Signing in to the console with the token creates a session # that is valid for 12 hours. get_signin_token_url = signin_url + "?Action=getSigninToken" + "&SessionType=json&Session=" + CGI.escape(session_json) returned_content = URI.parse(get_signin_token_url).read # Extract the sign-in token from the information returned # by the federation endpoint. signin_token = JSON.parse(returned_content)['SigninToken'] signin_token_param = "&SigninToken=" + CGI.escape(signin_token) # Create the URL to give to the user, which includes the # sign-in token and the URL of the console to open. # The "issuer" parameter is optional but recommended. issuer_param = "&Issuer=" + CGI.escape(issuer_url) destination_param = "&Destination=" + CGI.escape(console_url) login_url = signin_url + "?Action=login" + signin_token_param + issuer_param + destination_param ```