Account access manager da AWS centraliza acesso de workforce sem abandonar roles IAM personalizadas

O que mudou

A AWS anunciou o account access manager, um novo jeito de gerenciar acesso de workforce (usuários e grupos humanos, não aplicações) às contas da organização, descrito no AWS Security Blog. Ele fecha uma lacuna antiga do IAM: até agora, quem queria acesso centralizado via IAM Identity Center tinha que migrar para permission sets, abrindo mão de recursos de role que muitos times já tinham investido tempo configurando.

Com account access manager, você continua usando as roles IAM que já existem em cada conta, com tudo que elas carregam: trust policy customizada, tags para ABAC (attribute-based access control) e paths para organização em escala. A diferença é que, em vez de federar separadamente em cada conta, você atribui essas roles a usuários e grupos sincronizados no IAM Identity Center a partir do seu provedor de identidade corporativo (Okta, Microsoft Entra ID, Ping Identity, entre outros).

O ponto central para quem desenha arquitetura multi-conta: isso não é um substituto dos permission sets, é uma terceira via. Dá para rodar os dois modelos lado a lado na mesma organização, porque ambos consomem os mesmos usuários e grupos do Identity Center. Times com roles muito específicas por conta não precisam mais generalizá-las em permission sets só para ganhar federação central.

Onde está disponível

A fonte não traz uma lista de regiões suportadas para account access manager, nem confirma se a região América do Sul (São Paulo), sa-east-1, está no catálogo. Os exemplos do próprio anúncio usam us-east-2 de forma genérica, sem indicar abrangência geográfica.

O que dá para inferir com segurança: account access manager depende de uma instância de organização do IAM Identity Center já habilitada, e deve ser ativado na conta de gerenciamento da organização, na mesma região primária dessa instância. Na prática, isso significa que a disponibilidade do recurso segue a disponibilidade regional do Identity Center na sua organização, e não existe hoje confirmação pública de que sa-east-1 já suporta o serviço. Vale checar o console antes de planejar rollout.

Quanto custa

O anúncio não cita preço para account access manager, nem por usuário, por entitlement ou por chamada à API account-access. Não há tabela de cobrança no post do Security Blog.

O que se sabe pelo material: o serviço usa roles IAM que você já paga pelo uso dos próprios serviços que elas acessam, e uma instância do IAM Identity Center que precisa estar habilitada antes. Nenhum dos dois recursos tem cobrança própria mencionada no texto da AWS. Antes de assumir isso como garantia de custo zero, monitore o AWS Cost Explorer por volume de chamadas à API account-access depois de habilitar, porque a AWS não descarta cobrança futura em nenhum trecho do anúncio.

Como começar

O pré-requisito é ter uma instância de organização do IAM Identity Center ativa e usuários ou grupos já provisionados (via SCIM do seu IdP, ou criados direto no diretório do Identity Center). É preciso também ter o AWS CLI v2.36.0 ou mais recente para usar aws login.

O fluxo de habilitação tem cinco passos, rodados na conta de gerenciamento da organização:

1. Liberar o serviço na organização: aws organizations enable-aws-service-access --service-principal account-access.amazonaws.com.
2. Habilitar account access manager pelo console (IAM > Multi-account access) ou via CLI com aws account-access create-application, informando o ARN da instância do Identity Center.
3. Atualizar o firewall ou Secure Web Gateway para liberar os domínios do account access portal, no formato https://[Tenant-ID].account-access.[Region].app.aws.
4. Ajustar a trust policy de cada role que será atribuída, adicionando o principal account-access.amazonaws.com com as condições aws:SourceAccount e aws:SourceArn apontando para o ARN da aplicação, o que evita confused deputy.
5. Criar o entitlement ligando usuário ou grupo, conta e role, pelo console ou com aws account-access create-entitlement --application-arn "<ARN>" --entitlement '{"principalRole":{"principal":{"userId":"<ID>"},"roleArn":"arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>"}}'.

A trust policy mínima que a AWS recomenda fica assim:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AccountAccessManagerIAMRoleTrustPolicyStatement",
    "Effect": "Allow",
    "Principal": { "Service": "account-access.amazonaws.com" },
    "Action": ["sts:AssumeRole", "sts:SetContext", "sts:TagSession"],
    "Condition": {
      "StringEquals": {
        "aws:SourceAccount": "<your-account-id>",
        "aws:SourceArn": "arn:aws:account-access:<region>:<your-account-id>:application/<application-id>"
      }
    }
  }]
}

A ação sts:TagSession só é necessária se suas políticas downstream consultam aws:PrincipalTag/<key> populado por claim SAML do IdP; sem ela, a sessão funciona normalmente, só não propaga tags. Depois de atribuído, o usuário acessa pelo portal dedicado, pelo AWS access portal padrão do Identity Center, ou rodando aws login no CLI.

O que muda para quem já usa

Para quem já opera multi-conta com IAM Identity Center e permission sets, a decisão passa a ser por role, não por organização inteira. Um time com role de Developer cheia de condições de trust policy específicas por departamento ou cost center não precisa mais ser forçado a um permission set genérico: ela entra no account access manager como está, tags e tudo.

A AWS recomenda explicitamente atribuir acesso a grupos, não a usuários individuais, para reduzir overhead administrativo e manter a auditoria mais limpa. Isso é consistente com o que arquitetos já fazem com AWS Organizations e service control policies: unidade de gestão é o grupo, não a pessoa. Duração de sessão segue o MaxSessionDuration configurado na própria role, até 12 horas, igual já funcionava na federação direta.

Para automação via IaC, o anúncio já traz integração com Terraform e Pulumi, além de CloudFormation, então o entitlement pode entrar no mesmo pipeline que já provisiona a role. A AWS também publicou uma ferramenta de referência, a sample-aam-migration, para quem quer automatizar a atualização em massa das trust policies existentes em vez de editar role por role manualmente. O lançamento já vem com parceiros de identidade e governança de acesso, incluindo Okta, BeyondTrust e Britive, para quem já usa essas plataformas, além de integração com Pulumi para quem gerencia acesso via IaC.

Fonte: AWS Security Blog