O blog da AWS
Como usar trust policies com roles do IAM
Há vários cenários diferentes em que você pode usar roles do IAM na AWS:
- Um serviço ou recurso da AWS acessa outro recurso da AWS em sua conta — Quando um recurso da AWS precisa de acesso a outros serviços, funções ou recursos da AWS, você pode criar uma role que tenha as permissões apropriadas para uso desse recurso da AWS. Serviços como AWS Lambda e Amazon Elastic Container Service (Amazon ECS) podem assumir roles para fornecer credenciais temporárias ao código que está sendo executado neles.
- Um serviço da AWS gera credenciais da AWS para serem utilizadas por dispositivos executados fora da AWS — AWS IAM Roles Anywhere, AWS IoT Core e instâncias híbridas do AWS Systems Manager podem fornecer credenciais de sessão para aplicativos, dispositivos e servidores que não são executados dentro da AWS.
- Uma conta da AWS acessa outra conta da AWS — Esse caso de uso geralmente é chamado de cross-account role pattern. Ele permite que um Principal do IAM assuma essa role e aja com base nos recursos de uma segunda conta da AWS. Uma role é assumida para habilitar esse comportamento quando o recurso na conta de destino não tem uma política baseada em recursos que possa ser usada para conceder acesso entre contas.
- Um usuário autenticado com um provedor de identidade da web ou o OpenID Connect (OIDC) que precisa acessar seus recursos da AWS — Esse caso de uso permite que identidades do Facebook ou de provedores OIDC, como GitHub, Amazon Cognito ou outros provedores genéricos de OIDC, assumam uma role para acessar recursos em sua conta da AWS.
- Um cliente realiza a autenticação dos funcionários usando a federação SAML 2.0 — Isso ocorre quando os clientes federam seus usuários na AWS a partir de seu provedor de identidade corporativo (IdP), como Okta, Microsoft Azure Active Directory ou Active Directory Federation Services (ADFS), ou do AWS IAM Identity Center (sucessor do AWS Single Sign-On).
Uma role do IAM é uma entidade do IAM cujos direitos são assumidos em um dos casos de uso anteriores. Uma role do IAM difere de um usuário do IAM da seguinte forma:
- Uma role do IAM não pode ter credenciais de longo prazo da AWS associadas a ela. Em vez disso, um Principal autorizado (um usuário do IAM, um serviço da AWS ou outra identidade autenticada) assume a role do IAM e herda as permissões atribuídas a essa role.
- As credenciais associadas a uma role do IAM são temporárias e expiram.
- Uma role do IAM tem uma trust policy (política de confiança) que define quais condições devem ser atendidas para que possa ser assumida por outras entidades.
Gerenciando o acesso a roles do IAM
Vamos ver como você pode controlar o acesso a uma role do IAM, entendendo os tipos de política que se pode aplicar a essa role.
Há três pontos em que políticas são usadas para uma role do IAM:
- Trust policy — Uma trust policy (política de confiança) define quais entidades podem assumir a role e sob quais condições. Uma trust policy é um tipo específico de política baseada em recursos para roles do IAM. A trust policy é o foco do restante desta postagem do blog.
- Políticas baseadas em identidade (em linha e gerenciadas) — Essas políticas definem as permissões que o usuário da role pode executar (ou não pode executar) e em quais recursos.
- Limite de permissões — Um limite de permissões é um recurso avançado para usar uma política gerenciada para definir as permissões máximas para uma role. O limite de permissões de um Principal permite que ele execute somente as ações permitidas por suas políticas de permissões baseadas em identidade e por seus limites de permissões. Você pode usar limites de permissões para delegar tarefas de gerenciamento de permissões, como a criação de roles do IAM, a não administradores, para que eles possam criar roles via self-service.
No restante deste blog, você aprenderá como definir as condições sob as quais as roles podem ser assumidas configurando suas trust policies.
Exemplo de uma simples trust policy
Um caso de uso comum é quando você precisa fornecer acesso a uma role na conta A para assumir uma role na conta B. Para facilitar esse processo, você adiciona uma permissão na trust policy da role da conta B que permite que entidades autenticadas da conta A assumam essa role por meio da chamada de API sts:AssumeRole.
Importante: ao referenciar
:rootna trust policy de uma role do IAM, você permite que mais entidades assumam sua role do que você pretendia, portanto, é uma boa prática usar o elementoPrincipalpara permitir que apenas entidades ou caminhos específicos assumam uma role. Mais adiante neste blog, mostraremos como limitar esse acesso a entidades mais específicas.
Essa trust policy tem a mesma estrutura de outras políticas do IAM com os componentes Effect, Action e Condition. Ela também tem o elemento Principal, mas nenhum elemento Resource. Isso ocorre porque o Resource é a role do IAM em si. Pelo mesmo motivo, o elemento Action será definido para ações relevantes para chamadas de assume role.
Nota: O sufixo
:rootno elemento Principal da política equivale aos Principals da conta, não ao usuário raiz dessa conta.
Usando o elemento Principal para limitar quem pode assumir uma role
Em uma trust policy, o elemento Principal indica quais outras entidades podem assumir a role do IAM. No exemplo anterior, 111122223333 representa o número da conta da AWS do terceiro. Desta forma, um Principal na conta 111122223333 com permissões sts:AssumeRole pode assumir essa role.
Para permitir que uma role específica do IAM assuma uma outra role, você pode adicionar essa role ao elemento Principal. Por exemplo, a trust policy a seguir permitiria que somente a role do IAM LiJuan da conta 111122223333 assumisse a role à qual a trust policy está vinculada.
As entidades incluídas no elemento Principal, definidas na documentação do IAM, podem se referir a um Principal da AWS ou um Principal federado. Não é possível usar um wildcard (“*” ou “?”) dentro do elemento Principal de uma trust policy, exceto em um caso que abordaremos a seguir. Você deve definir de forma precisa a qual entidade está se referindo, pois há uma tradução que ocorre quando você envia sua trust policy que a vincula ao ID de cada Principal. Para obter mais informações, consulte Por que há um formato de Principal desconhecido em minha política baseada em recursos do IAM?
Se uma role do IAM tem um Principal da mesma conta referenciado em sua trust policy, esse Principal não precisa de um direito explícito em sua política de identidade anexada para assumir a role.
Usando o elemento Condition em uma trust policy
O elemento Condition na trust policy de uma role define requisitos adicionais para o Principal tentar assumir a role. O elemento Condition é uma forma flexível de reduzir o conjunto de Principals que podem assumir a role sem que sejam necessariamente especificados.
Os elementos condicionais das trust policies de roles se comportam de forma idêntica aos elementos condicionais das políticas baseadas em identidade e em outras políticas de recursos na AWS.
Usando a federação de identidade SAML na AWS
Os usuários federados de um IdP compatível com SAML 2.0 recebem permissões para acessar contas da AWS por meio do uso das roles do IAM. O mapeamento de quais usuários assumem quais roles é estabelecido no diretório usado pelo SAML 2.0 IdP e inserido dentro da declaração SAML assinada pelo IdP.
O Principal da trust policy contém o ARN do IdP SAML da mesma conta da AWS. IDPs de outras contas não podem ser referenciados. As roles assumidas por federação SAML podem usar chaves de condição específicas do SAML em sua trust policy.
A trust policy de uma role a ser assumida por SAML possui o ARN do IdP SAML no elemento Principal, e verifica o público alvo (ou audiência – SAML:aud) da asserção SAML. Definir a condição de audiência é importante porque significa que somente as asserções SAML destinadas à AWS podem ser usadas para assumir uma role:
A documentação da AWS aborda detalhadamente a criação de roles para a federação SAML 2.0. Para obter informações sobre como gerenciar as trust policies de roles assumidas via SAML de múltiplas regiões da AWS para fins de resiliência, consulte o blog Como usar endpoints regionais de SAML para failover.
Para federar o acesso à AWS, você pode usar o AWS IAM Identity Center (sucessor do AWS Single Sign-On) para intermediar o acesso às roles do IAM via SAML. Roles gerenciadas pelo IAM Identity Center não podem ter sua trust policy modificada diretamente pelo IAM.
Os IDPs SAML usados em uma trust policy de role devem estar na mesma conta da role.
Assumindo uma role com o WebIdentity
As roles também podem ser assumidas com tokens emitidos por provedores de identidade da web e provedores compatíveis com OpenID Connect (OIDC).
Depois de criar um provedor de identidade OpenID Connect em sua conta, você pode configurar roles a serem assumidas por esse provedor de identidade OpenID Connect.
A seguir está uma trust policy que permite que uma role seja assumida pelo provedor de identidade auth.example.com em que o valor da claim sub é igual a Administrator e o aud é igual a MyAppWebIdentity.
As chaves de condição usadas para roles assumidas pelos provedores de identidade OIDC são sempre prefixadas com o nome do provedor de identidade (por exemplo, auth.example.com). Portanto, para usar declarações no token de ID, como aud, sub e amr, elas têm o prefixo auth.example.com:aud, auth.example.com:sub e auth.example.com:amr, respectivamente, em uma trust policy a ser avaliada como uma chave de condição. Somente as claims de ID Token listadas na documentação do STS podem ser usadas em trust policies de roles como chaves de condição.
É importante definir a condição :aud nas trust policies de roles para ajudar a verificar se os tokens usados para assumir roles em suas contas da AWS são tokens destinados a serem usados para essa finalidade.
Os clusters do Amazon Elastic Kubernetes Service (Amazon EKS) têm recursos de provedor de identidade OIDC e podem ser usados para assumir roles em contas da AWSs.
Os provedores de identidade OIDC usados para assumir uma role devem estar na mesma conta da AWS que a role.
Limitando o uso da role com base em um identificador
Às vezes, pode ser necessário conceder acesso aos seus recursos da AWS para terceiros. Suponha que você tenha contratado uma empresa terceirizada, a ExampleCorp, para monitorar sua conta da AWS e ajudar a otimizar os custos. Para monitorar seus gastos diários, a ExampleCorp precisa acessar seus recursos da AWS, então você permite que eles assumam uma role do IAM em sua conta. No entanto, a ExampleCorp também monitora os gastos de outros clientes, e pode haver um problema de configuração no ambiente da ExampleCorp que permita que outro cliente obrigue a ExampleCorp a tentar realizar uma ação em sua conta da AWS, mesmo que esse cliente só tenha acesso à sua própria conta. Isso é conhecido como Confused Deputy Problem. Esta seção mostra uma forma de mitigar esse risco.
A trust policy a seguir exige que alguém da conta da ExampleCorp AWS, 444455556666, tenha fornecido uma string especial, chamada de External ID, ao fazer sua solicitação para assumir a role. Adicionar essa condição reduz o risco de alguém da conta 444455556666 assumir essa role por engano, ou por meio de algum ataque de injeção. Essa string é configurada especificando uma chave de contexto condicional ExternalID.
As IDs externas devem ser geradas pelo terceiro que assume sua role, no caso a ExampleCorp, e associadas às chamadas de AssumeRole da ExampleCorp. Ao fazer isso, outros clientes da ExampleCorp não poderão coagi-la a assumir as suas roles para uso próprio, pois não podem forçar a ExampleCorp a usar sua ID externa.
As IDs externas devem ser exclusivas para cada cliente de um provedor de serviços. A AWS não trata as IDs externas como segredos — elas podem ser vistas por qualquer pessoa que possua permissão para ver a trust policy de uma role.
Se você assumir roles nas contas de seus clientes, uma prática recomendada é gerar valores únicos de ID externa para cada cliente, e você não deve permitir que seus clientes especifiquem uma ID externa.
Roles com a condição sts:ExternalID não podem ser assumidas por meio do console da AWS, a menos que haja outra instrução Allow sem essa condição.
Limitando o uso da role com base em endereços IP ou intervalos CIDR
Você pode colocar condições de endereço IP em uma trust policy de role para limitar as redes a partir das quais uma role pode ser assumida. Por exemplo, você pode limitar quem assume uma role a uma rede corporativa ou a um intervalo de VPN. O exemplo de trust policy a seguir só permitirá que a role seja assumida se a chamada for feita dentro do intervalo CIDR 203.0.113.0/24.
Ao usar aws:SourceIP na trust policy, você limita de onde a role pode ser assumida, mas isso não limita onde as credenciais podem ser usadas após serem assumidas. Para restringir de onde as credenciais podem ser usadas, você pode usar aws:sourceIP como uma condição na política da role ou nas service control policies que se aplicam a ela. Para obter mais informações sobre como restringir de onde as credenciais podem ser usadas, consulte o blog Estabelecendo um perímetro de dados na AWS.
Limitando o uso de roles com base em tags
Você pode usar os recursos de tagging do IAM para criar trust policies flexíveis e adaptáveis. Você pode usar um modelo de controle de acesso baseado em atributos (ABAC) para assumir roles do IAM, da mesma forma que você pode para acessar objetos em um bucket do Amazon Simple Storage Service (Amazon S3). Você pode criar trust policies que só permitam que Principals que já tenham tags com uma chave e um valor específicos assumam uma role específica. O exemplo de trust policy a seguir exige que os Principals do IAM na conta 111122223333 da AWS tenham o valor da tag department correspondente ao valor da tag owningDepartment na role a ser assumida.
Como exemplo, na política anterior, se a role obtém a tag owningDepartment com o valor marketing, somente Principals da conta 111122223333 que tenham uma tag department com o valor marketing poderão assumir a role.
Ao usar ABAC, é importante ter governança sobre quem pode definir tags nos recursos, Principals e sessões. Se alguém puder alterar ou modificar tags em Principals, recursos ou sessões, poderá acessar recursos que você não pretendia. Os Principals de contas da AWS fora do seu controle podem ter práticas de governança de tags diferentes das aplicadas na sua organização, e você deve levar isso em consideração ao usar as tags em roles entre diferentes contas. Você pode usar as tag policies para ajudar na governança de tags em sua organização. Posteriormente, neste blog, mostraremos como atribuir tags no momento em que se assume a role, usando trust policies.
Para obter mais informações, consulte a página Attribute-based Access Control (ABAC) for AWS.
Restringindo a ação de assumir roles a Principals de suaorganização
Desde seu anúncio em 2016, a grande maioria dos clientes corporativos com os quais trabalhamos usa o AWS Organizations. Esse serviço da AWS permite que você crie uma estrutura organizacional para suas contas criando limites lógicos/unidades organizacionais (OU – Organizational Unit), que permitem o agrupamento de contas da AWS que precisam ser aplicadas políticas de proteção comuns. Você pode usar a chave de condição PrincipalOrgID para limitar o uso de roles somente aos Principals de sua organização no AWS Organizations.
O exemplo a seguir mostra uma política que proíbe a ação de assumir a role, exceto pelos serviços da AWS ou por Principals que sejam membros da organização o-abcd12efg1. Essa declaração pode ser amplamente aplicada para impedir que alguém de fora da sua organização da AWS assuma suas roles.
No exemplo anterior, o operador StringNotEquals nega o acesso a essa role por um Principal que não pertence a uma conta membro da organização especificada.
As roles que você pretende usar com os serviços da AWS precisam poder ser assumidas por esses serviços da AWS. No exemplo anterior, adicionamos a chave de condição aws:PrincipalIsAwsService para que um Principal de serviço da AWS não seja afetado pela declaração explícita Deny. Todos os Principals, incluindo os serviços da AWS, ainda precisam ter uma declaração de permissão (Allow) explícita na trust policy de uma role para assumir essa role. As requisições realizadas por serviços da AWS a recursos do cliente fazem isso com a chave de condição aws:PrincipalIsAwsService definida com o valor True, o que significa que a declaração Deny anterior não se aplicará a um serviço que fizer a requisição.
Caso precise de mais granularidade de acesso, também pode ser usada a chave de condição aws:PrincipalOrgPaths, para limitar a ação de assumir a role às contas membros de uma OU específica de uma organização.
Aplicação de invariantes com declarações de negação
Permitir que somente os Principals de sua organização assumam suas roles é um exemplo de invariante de segurança. Invariantes de segurança são princípios de segurança que você deseja que sempre sejam aplicados. Declarações de negação (Deny) são úteis em trust policies para restringir condições sob as quais você nunca gostaria que uma role fosse assumida. Na autorização da AWS, a presença de uma declaração de negação aplicável tem prioridade sobre uma declaração de permissão aplicável. Portanto, é muito útil ter uma declaração de negação com condições que nunca devem ser atendidas, como permitir que uma role seja assumida por um Principal fora de sua organização.
Definindo a identidade de origem nas sessões para rastrear ações no CloudTrail
Ao assumir uma role, a sessão pode ter configurações de identidade de origem quando assumida. Isso é mais comum quando os clientes federam usuários no IAM por meio do SAML2.0 ou do Web Identity/OpenID Connect para assumir roles. Você pode configurar seu IdP para definir o atributo sourceIdentity na sessão da role.
Definir a identidade de origem faz com que os registros do AWS CloudTrail contenham este dado, para que você possa rastrear as ações tomadas pelas roles até o usuário que as assumiu. O atributo sourceIdentity também segue essa sessão se a role assumida assumir outra role.
Para definir uma identidade de origem, você precisa conceder ao IdP o direito sts:SetSourceIdentity na trust policy da role.
Para uma sessão de role que tenha um SourceIdentity definido assuma uma segunda role, ela também deve ter a permissão sts:SetSourceIdentity na trust policy dessa segunda role. Caso contrário, a primeira role não poderá assumir a segunda role.
Você também pode usar a chave de condição sts:SourceIdentity para garantir que o atributo SourceIdentity que está sendo definido esteja em conformidade com um padrão esperado:
No exemplo anterior, pelo elemento Condition, todas as requisições devem conter @example.org.
Definindo tags em sessões de roles
Você pode definir tags nas sessões de roles, que podem então ser utilizadas nas decisões de autorização do IAM e das políticas de recursos. As tags nas sessões de role são avaliadas com a mesma chave de condição que as tags nas roles do IAM: aws:PrincipalTag/TagKey. Os valores de tag definidos quando uma role é assumida têm precedência sobre os valores de tag que são anexados à role.
Se você está baseando a autorização nas tags em suas contas da AWS, é importante controlar quem pode definir as tags de sessão e as tags dos Principals em suas contas, para que não haja elevação de privilégios indevida.
A possibilidade de adicionar uma tag à sessão deve ser concedida na trust policy de uma role usando a permissão sts:TagSession, e você pode usar condições e chaves de condição para restringir quais tags podem ser definidas para quais valores.
A seguir está um exemplo de declaração de uma trust policy que permite que um Principal da conta 111122223333 assuma a role e exige que as três tags de sessão para Projeto (Project), centro de custos (CostCenter) e Departamento (Department) sejam definidas. A tag do Departamento deve ter um valor de Engenharia ou Marketing (Engineering/Marketing). A terceira declaração de condição permite que as tags de Projeto e Departamento sejam definidas como transitivas quando a role é assumida. As tags transitivas são persistentes quando uma role é assuma por outra role. Como as condições das tags estão dentro do escopo do mesmo Statement que a permissão à chamada sts:AssumeRole, essas tags são obrigatórias (verifique o atributo Action do exemplo).
Quando uma sessão de role assume outra role, as tags transitivas da sessão atual são definidas com o mesmo valor na sessão de role subsequente. Para obter mais informações, consulte Encadeamento de roles com tags de sessão.
Você pode usar instruções Deny com a Ação sts:TagSession para impedir que determinadas tags sejam definidas na sessão. No exemplo a seguir, qualquer tentativa de adicionar ou alterar a tag de administrador (Admin) seria negada:
No exemplo a seguir, negamos operações de tagging nas sessões de role em que a tag Equipe (Team) é igual a Admin, mas permitimos a atribuição de outros valores.
O que acontece quando uma role em uma trust policy é excluída
Quando você especifica uma role no elemento Principal de uma trust policy, a AWS usa o RoleID exclusivo dessa role para tomar a decisão de autorização. Se a role ExampleCorpRole dos exemplos anteriores fosse excluída e recriada na mesma conta, com o mesmo nome e ARN (Amazon Resource Name), o novo RoleID exclusivo seria diferente e a nova ExampleCorpRole não conseguiria assumir as roles que confiavam nela no elemento Principal. Esse processo evita a escalação de privilégios por meio da re-criação de roles com o mesmo nome.
Quando uma role é excluída, o valor nas trust policies das outras roles que faziam referência a ela não é atualizado:
Como a trust policy acima faz referência a um RoleID agora inválido, ela não pode ser assumida até que o RoleID inválido seja removido dela. Caso você recrie uma role com o mesmo nome, e ela seja referenciada na trust policy de outra role, é necessário removê-la e adicionar novamente.
Para obter mais informações sobre o uso do elemento Principal nas declarações de política, consulte Principals de roles do IAM.
Os Principals colocados dentro do bloco Condition de uma declaração de trust policy não fazem referência ao RoleID, mas usam o ARN da role. A declaração de trust policy a seguir permitiria que a ExampleCorpRole assumisse a role que confiou nela, mesmo que a role ExampleCorprole fosse excluída e recriada.
Ao criar uma trust policy de role, você deve determinar o comportamento que deseja que ocorra quando uma role for excluída. A postura de segurança de sua organização pode determinar que uma role excluída e recriada não possa mais assumir uma role em sua conta, portanto, seria adequado especificar a role no elemento Principal. Ou talvez você queira permitir que a role seja assumida no caso de re-criação, como no exemplo acima.
Nota: se você usar a condição aws:PrincipalArn com um Principal :root para permitir assumir a role na mesma conta, o Principal que a assume precisará ter permissão para a ação sts:assumeRole em sua política baseada em identidade.
Principals com Wildcards
Anteriormente, observamos que wildcards não podem ser colocados no elemento Principal de uma política como parte de um ARN. No entanto, wildcards podem ser usados no bloco Condition de uma política, portanto, é possível usar wildcards com os operadores de condição ArnLike e StringLike. Isso é útil quando você não conhece as roles específicas, mas tem outros controles que limitam os paths/caminhos em que as roles são criadas, como modelos de delegated administrator. A política a seguir permite que qualquer role da conta 111122223333 no path OpsRoles a assuma.
É uma prática recomendada restringir a ação de assumir roles a caminhos ou Principals específicos, em vez de permitir uma conta inteira, sempre que possível.
Usando vários Statements
Até agora, os exemplos desta postagem foram declarações (Statements) com uma única política. As trust policies, como outras políticas na AWS, podem ter várias declarações, considerando a cota de tamanho da trust policy da role.
Você pode combinar várias instruções para criar relações de confiança complexas, como a seguinte, que permite que ExampleRole assuma uma role e adicione uma tag à sessão, mas somente a partir do intervalo de rede 203.0.113.0/24, proibindo que a tag Admin seja definida:
Embora seja possível usar várias declarações, é uma prática recomendada que você não use roles para fins não relacionados e que você não compartilhe roles entre diferentes serviços da AWS. Também é uma boa prática usar diferentes roles do IAM para diferentes casos de uso e serviços da AWS e evitar situações em que Principals diferentes tenham acesso à mesma role do IAM.
Trabalhando com serviços que fornecem credenciais de sessão de role
O IAM Roles Anywhere, o AWS IoT Core e o Systems Manager podem fornecer credenciais de sessão de role da AWS para dispositivos, servidores e aplicativos executados fora da AWS. Essas roles são assumidas pelos serviços da AWS e entregues aos seus dispositivos, servidores e aplicativos após a autenticação em seus respectivos serviços da AWS.
Para obter mais informações sobre esses serviços e seus requisitos, consulte a documentação clicando nos links:
- IAM Roles Anywhere: Trust policy
- Autorização de chamadas diretas para serviços AWS usando o provedor de AWS IoT Core credenciais
- Systems Manager: Criando um role de IAM para um ambiente híbrido
Encadeamento de roles
Quando uma role assume outra role, isso é chamado de encadeamento de roles. As sessões criadas pelo encadeamento de roles têm uma vida útil máxima de 1 hora, independentemente da duração máxima da sessão que uma role está configurada para permitir.
Roles assumidas por outros meios não são consideradas encadeamento de roles e não estão sujeitas a essa restrição.
Conclusão
Neste blog, você aprendeu a criar trust policies para suas roles do IAM para restringir seu uso por Principals específicos e sob certas condições, combinando várias declarações com condições diferentes. Você também aprendeu a utilizar recursos como identidade de origem e tags de sessão, como se proteger contra o problema de Confused Deputy entre contas e as nuances do elemento Principal. Agora você tem as ferramentas necessárias para criar trust policies robustas e eficazes para as roles em sua organização.
Este artigo foi traduzido e adaptado a partir do Blog Post da AWS em inglês.