Controle de acesso com session tags no IAM Identity Center

O problema de escala no gerenciamento de acesso AWS

À medida que as organizações expandem sua presença na Amazon Web Services (AWS), gerenciar o acesso de forma segura, escalável e eficiente em múltiplas contas se torna um desafio crescente. A abordagem tradicional — criar usuários IAM individuais e atribuir permissões manualmente — não sustenta ambientes corporativos complexos.

Para endereçar esse problema, a AWS oferece o AWS IAM Identity Center, uma solução centralizada para gerenciar o acesso de colaboradores a contas AWS. Ele simplifica a autenticação, reforça a segurança e proporciona uma experiência de login consistente em diferentes ambientes.

O ponto mais poderoso dessa solução, no entanto, está na combinação entre permission sets e session tags — uma dupla que abre caminho para controle de acesso granular e otimização de custos sem aumentar a complexidade operacional.

O que são session tags e por que elas importam

Session tags são atributos dinâmicos que podem ser passados de um provedor de identidade externo para a AWS durante o processo de autenticação. Em vez de definir permissões estáticas por usuário, é possível usar informações contextuais — como departamento, projeto ou perfil de custo — para determinar o que cada sessão pode fazer.

Essa abordagem viabiliza o que a AWS chama de controle de acesso baseado em atributos (ABAC): as permissões são determinadas pelos atributos do usuário, não por regras fixas atribuídas individualmente. O resultado é um modelo mais flexível, onde adicionar um novo colaborador ao grupo correto no provedor de identidade já é suficiente para garantir o acesso adequado — sem necessidade de reconfigurar políticas IAM.

Essa integração também habilita recursos avançados da AWS, como os perfis de uso do AWS Glue e o AWS Systems Manager Session Manager com Run As, permitindo que administradores mapeiem permissões e configurações de runtime dinamicamente com base nos atributos do usuário.

A arquitetura: Microsoft Entra ID + IAM Identity Center

O artigo publicado pela AWS demonstra como session tags derivadas de atributos de grupos no Microsoft Entra ID podem entregar uma funcionalidade equivalente às tags de roles do AWS Identity and Access Management (IAM). A integração usa dois protocolos complementares:

  • SAML 2.0 — para autenticação federada entre o Entra ID e o IAM Identity Center
  • SCIM — para sincronização automática de usuários e grupos do Entra ID para a AWS

O fluxo de autenticação funciona da seguinte forma: o usuário acessa a aplicação corporativa configurada no Azure, o Microsoft Entra ID realiza o login, e durante a autenticação SAML, atributos do usuário (como departamento, função, centro de custo ou ID de projeto) são enviados como session tags para o IAM Identity Center. A partir daí, esses atributos são usados para aplicar permissões granulares dentro da AWS.

Os usuários podem acessar a AWS pelo console ou pela Interface de Linha de Comando da AWS (AWS CLI), e o acesso é concedido a contas específicas dentro do AWS Organizations.

Pré-requisitos para implementar a solução

Antes de colocar a solução em prática, a AWS lista os seguintes requisitos:

Implementando a solução passo a passo

1. Criar um perfil de uso no AWS Glue

O caso de uso demonstrado utiliza os perfis de uso do AWS Glue para controle flexível de custos. Para o exemplo, deve-se criar um perfil chamado developer com as seguintes configurações:

  • Número de workers padrão: 20
  • Tipo de worker padrão: G.1X
  • Tipos de worker permitidos: G.1X, G.2X, G.4X e G.8X

Essas configurações se aplicam tanto a jobs quanto a sessões interativas.

2. Criar um permission set personalizado

Em vez de usar permission sets predefinidos, a AWS recomenda criar um permission set personalizado e anexar as seguintes políticas gerenciadas da AWS:

  • AWSGlueConsoleFullAccess
  • IAMReadOnlyAccess

Vale destacar que o exemplo usa políticas com permissões amplas por simplicidade didática. Em ambientes de produção, a AWS orienta seguir o princípio do menor privilégio e escopar as permissões adequadamente.

Após criar o permission set, é necessário provisioná-lo em uma conta AWS atribuindo acesso a usuários ou grupos no IAM Identity Center. Mais detalhes estão disponíveis em Atribuir acesso de usuário ou grupo a contas AWS.

3. Configurar atributos de usuário no Microsoft Entra ID

Esta etapa é o coração da solução. A configuração segue o passo 5 da documentação Configure SAML e SCIM com Microsoft Entra ID e IAM Identity Center para habilitar o ABAC.

No portal do Azure, dentro da aplicação corporativa criada, acesse a seção Single sign-on e depois Attributes & Claims. Em seguida, adicione uma nova claim com as seguintes configurações:

  • Name: AccessControl:<NomeDoAtributo> — para o exemplo, use AccessControl:glue:UsageProfile
  • Claim conditions:
    • User type: Members
    • Source: Attribute
    • Value: developer

O ponto central aqui é que as tags são atribuídas com base na associação de grupo no Entra ID. Isso significa que qualquer usuário que faça login no IAM Identity Center e pertença ao grupo configurado receberá automaticamente o valor da tag aplicado à sua sessão — sem necessidade de configurar tags individualmente por usuário.

Quando o AWS Glue recebe chamadas de API para criação de recursos, o sistema verifica se o usuário ou role está marcado com a chave glue:UsageProfile e o nome do perfil como valor.

Testando e validando a configuração

Com tudo configurado, o teste consiste em fazer login como usuário pelo Microsoft Entra ID acessando https://myapps.microsoft.com/ e verificar a criação de jobs no AWS Glue usando o perfil developer. Um job criado com sucesso dentro das configurações do perfil confirma que as session tags estão sendo aplicadas corretamente.

Validação via AWS CloudTrail

Para confirmar que as tags de sessão estão sendo transmitidas corretamente durante a autenticação, a AWS recomenda verificar o evento AssumeRoleWithSAML no AWS CloudTrail. O caminho é:

  • Acessar o console do CloudTrail
  • Selecionar Event history
  • Filtrar pelo nome de evento AssumeRoleWithSAML
  • Abrir um evento relevante e inspecionar a seção requestParameters
  • Confirmar que as session tags esperadas aparecem em PrincipalTags

Outros casos de uso: AWS Systems Manager Session Manager

A mesma lógica pode ser estendida para o AWS Systems Manager Session Manager com suporte a Run As para usuários federados.

Por padrão, o Session Manager inicia sessões usando uma conta de sistema gerada automaticamente chamada ssm-user. Para instâncias Linux, é possível configurar sessões para serem executadas como um usuário específico do sistema operacional. Nesse cenário, basta configurar o provedor de identidade para passar o atributo AccessControl:SSMSessionRunAs com o nome de um usuário do SO como valor durante a federação — e a sessão será iniciada com esse usuário automaticamente.

Limpeza dos recursos

Para evitar cobranças desnecessárias após os testes, a AWS orienta remover os recursos criados:

  • Remover a instância do IAM Identity Center e limpar a aplicação corporativa no Microsoft Entra
  • Excluir o perfil de uso do AWS Glue
  • Remover quaisquer outros recursos AWS provisionados durante os testes

Por que essa abordagem importa

A combinação de IAM Identity Center, SAML 2.0 e session tags representa uma evolução significativa na forma como organizações gerenciam acesso em ambientes AWS multi-conta. Ao usar ABAC com atributos vindos de um provedor de identidade externo, as equipes de segurança conseguem manter controle granular sem a complexidade de gerenciar usuários IAM individuais ou roles estáticas.

À medida que os ambientes de nuvem crescem em complexidade, adotar federação de identidade moderna e ABAC via IAM Identity Center é uma das formas mais eficazes de equilibrar segurança rigorosa com agilidade operacional.

Recursos adicionais

Fonte

Access control with IAM Identity Center session tags (https://aws.amazon.com/blogs/security/access-control-with-iam-identity-center-session-tags/)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *