Boas práticas para integrar o IAM Roles Anywhere com sua PKI

O que é o IAM Roles Anywhere e por que ele importa

Usar credenciais temporárias é uma boa prática de segurança amplamente recomendada para reduzir o risco de comprometimento de credenciais de longa duração. O AWS IAM Roles Anywhere estende esse modelo para workloads que rodam fora da Amazon Web Services (AWS), permitindo que eles obtenham credenciais temporárias do AWS Identity and Access Management (IAM) por meio de certificados digitais.

A base dessa integração é a Infraestrutura de Chave Pública (PKI), responsável pela geração, distribuição e verificação de certificados digitais usando criptografia assimétrica. A AWS publicou um guia detalhado de boas práticas sobre como integrar sua PKI com o IAM Roles Anywhere — e é exatamente isso que vamos explorar aqui.

Nota importante: A partir de julho de 2026, o AWS Certificate Manager (ACM) passa a suportar certificados públicos exportáveis para workloads fora da AWS, além do protocolo ACME para emissão e renovação automatizada de certificados em ambientes externos. Essas capacidades complementam o IAM Roles Anywhere em cenários híbridos.

Identidades de workload com certificados X.509

Em ambientes com múltiplos workloads, cada um deve ter uma identidade única e permissões bem definidas. Ferramentas de PKI como o Active Directory Certificate Services permitem gerenciar essas identidades centralmente. A recomendação da AWS é aplicar os mesmos princípios de segregação de workloads à PKI e ao IAM Roles Anywhere.

A prática recomendada é emitir um certificado X.509 distinto para cada workload, com atributos de identidade específicos assinados pela sua Autoridade Certificadora (CA). Isso garante que o Workload A tenha um escopo de acesso completamente diferente do Workload B ao acessar recursos AWS.

Como funcionam as credenciais temporárias

O fluxo de obtenção de credenciais temporárias começa quando o workload apresenta seu certificado X.509 ao IAM Roles Anywhere. O serviço realiza a validação da assinatura verificando o emissor e o subject do certificado antes de liberar as credenciais.

Para habilitar esse processo, é necessário configurar um modelo de confiança no IAM Roles Anywhere — seja fazendo upload do certificado digital da sua CA como um trust anchor (âncora de confiança), seja referenciando um certificado existente da AWS Private Certificate Authority (AWS Private CA).

A configuração do modelo de confiança segue três etapas, conforme descrito no artigo Extend AWS IAM Roles Anywhere to workloads outside of AWS:

• Criar um trust anchor.
• Configurar roles IAM com a trust policy do IAM Roles Anywhere, que serão assumidas pelos workloads externos.
• Configurar profiles com as roles IAM e anexar as session policies relevantes.

Atributos de certificado e o modelo de confiança

O modelo de confiança do IAM Roles Anywhere gira em torno dos atributos presentes nos certificados X.509. Os certificados são registros binários com pares chave/valor codificados. O IAM Roles Anywhere extrai valores dos campos Common Name (CN) do subject, do issuer e do Subject Alternative Name (SAN) do certificado autenticador, disponibilizando-os como tags de principal para avaliação de políticas.

Veja um exemplo de certificado PEM decodificado com ferramentas como o openssl:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            e0:5d:b7:72:56:fa:75:e3
        Signature Algorithm: ecdsa-with-SHA512
        Issuer: C=US, ST=CA, L=San Francisco, O=MyCompany Inc., OU=AC, CN=MyCompany CA
        Validity
            Not Before: Sep 15 00:09:17 2023 GMT
            Not After : Sep 18 00:09:17 2023 GMT
        Subject: C=US, O=MyCompany, OU=eCommerce, CN=WorkloadA
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:3b:74:e1:68:06:fa:b0:3d:fe:f7:5f:74:80:05:
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:ecommerce.mycompany.com, DNS:*ecommerce.mycompany.com,
                URI:spiffe://mycompany.com/workload/ecommerce
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature
    Signature Algorithm: ecdsa-with-SHA512
        30:64:02:30:19:a7:a0:33:49:ce:e1:cb:76:6e:c0:f3:c5:66:

A partir desse certificado, o IAM Roles Anywhere gera as seguintes tags de principal, usadas nas condições das políticas:

"aws:PrincipalTag/x509Subject/CN": "WorkloadA"
"aws:PrincipalTag/x509Issuer/CN": "MyCompany CA"
"aws:PrincipalTag/x509SAN/DNS": "ecommerce.mycompany.com"
"aws:PrincipalTag/x509SAN/URI": "spiffe://mycompany.com/workload/ecommerce"
"aws:PrincipalTag/x509SAN/Name/CN": "WorkloadA"

Atenção: Um Subject CN vazio no certificado não é suportado pelo IAM Roles Anywhere. Além disso, a AWS recomenda configurar períodos de validade curtos nos certificados emitidos para workloads — certificados de vida curta limitam a janela de exposição em caso de comprometimento e reduzem a necessidade de revogação ativa.

Trust policy e permissões efetivas das credenciais

Para que a chamada à API CreateSession seja autorizada, a trust policy da role IAM precisa confiar no service principal do IAM Roles Anywhere. Veja um exemplo:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "rolesanywhere.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/x509Issuer/CN": "MyCompany CA",
          "aws:PrincipalTag/x509Subject/CN": "WorkloadA",
          "aws:PrincipalTag/x509SAN/Name/CN": "WorkloadA"
        },
        "ArnEquals": {
          "aws:SourceArn": [
            "arn:aws:rolesanywhere:region:account:trust-anchor/TA_ID"
          ]
        }
      }
    }
  ]
}

Como boa prática de segurança, a AWS recomenda usar condições adicionais baseadas nas tags de PrincipalTag extraídas do certificado para restringir ainda mais a autorização. Se os workloads usam certificados efêmeros com Subject CN dinâmico, as tags de issuer ou SAN podem ser usadas nas condições da trust policy.

As permissões efetivas das credenciais temporárias resultam da interseção entre políticas baseadas em recurso, em identidade e de sessão. Ao configurar o trust anchor e o profile no IAM Roles Anywhere com session policies, é possível limitar as permissões de cada sessão com granularidade.

Posicionamento do trust anchor na hierarquia de certificados

Dependendo da plataforma de CA utilizada, é possível configurar uma ou mais CAs intermediárias na hierarquia de PKI. O nível em que o trust anchor é posicionado determina quais certificados de entidade final o IAM Roles Anywhere aceita — e, portanto, quais workloads estão autorizados a assumir uma role.

Para criar um trust anchor, exporte o bundle de certificados da CA emissora da sua plataforma de CA externa no formato PEM e faça o upload no console do trust anchor.

Credential helper: obtendo credenciais temporárias na prática

Para obter credenciais temporárias do IAM Roles Anywhere, a AWS disponibiliza o credential helper, compatível com o recurso credential_process dos SDKs AWS. Ele recebe a chave privada do workload e o certificado assinado pela CA como parâmetros principais.

Exemplo de uso:

$ ./aws_signing_helper credential-process \
    --certificate /path/to/certificate \
    --private-key /path/to/private-key \
    --trust-anchor-arn arn:aws:rolesanywhere:region:account:trust-anchor/TA_ID \
    --profile-arn arn:aws:rolesanywhere:region:account:profile/PROFILE_ID \
    --role-arn arn:aws:iam::account:role/role-name-with-path

Quando usado com SDKs AWS, as credenciais temporárias ficam em memória e são renovadas automaticamente. Já a AWS Command Line Interface (AWS CLI) invoca o credential-process a cada comando, criando uma nova sessão e adicionando latência. Para evitar esse problema, a AWS recomenda usar o comando update, que grava as credenciais renovadas em um arquivo lido pela CLI sem invocar o credential-process novamente.

Contudo, como as credenciais escritas em arquivo podem ser lidas por qualquer usuário ou processo com acesso ao arquivo, a recomendação é usar o comando serve — que disponibiliza as credenciais temporárias via endpoint local usando as mesmas URIs e headers do Instance Metadata Service Version 2 (IMDSv2), sem necessidade de arquivos de configuração AWS.

A partir de dezembro de 2024, o credential helper (versão 1.4.0 e posterior) passou a suportar Trusted Platform Module (TPM) 2.0.

Certificados just-in-time versus certificados de vida curta

Para mitigar riscos de exposição de recursos críticos, a AWS recomenda o uso de certificados just-in-time ou de vida curta como identidade de workload.

Certificados just-in-time são emitidos pela CA para uso imediato em uma autenticação específica. A CA usa as roles e políticas definidas no IAM para determinar quando e sob quais condições o workload pode estabelecer uma sessão. Como as credenciais são recriadas a cada requisição, mudanças de role se aplicam em tempo real — sem necessidade de revogar acessos manualmente. Esse modelo requer suporte da sua CA, então é importante verificar a compatibilidade antes de implementar.

Para certificados de vida curta, a AWS recomenda calibrar os períodos de validade conforme os requisitos do negócio, o ciclo de vida do workload e a tolerância a risco da organização. A AWS Private Certificate Authority oferece um modo de CA para certificados de vida curta (validade abaixo de 7 dias), com preço de US$ 50/mês — bem abaixo dos US$ 400/mês do modo de CA de uso geral —, tornando-o atraente para identidades efêmeras como containers e funções serverless. Saiba mais em How to use AWS Private CA short-lived certificate mode. O uso de credenciais de vida curta também é um pilar da arquitetura de zero trust na AWS.

Boas práticas para armazenamento de chaves privadas

A chave privada é criada pelo proprietário do certificado no momento da solicitação via CSR (Certificate Signing Request — Requisição de Assinatura de Certificado). A CA não cria nem armazena a chave privada — e ninguém fora dos administradores deve ter acesso a esse material. Guardrails devem impedir que as chaves sejam armazenadas em repositórios online.

O credential helper do IAM Roles Anywhere suporta integração com módulos compatíveis com PKCS #11 (a partir da versão 1.1.0), permitindo usar chaves privadas armazenadas em módulos de segurança de hardware (HSMs) ou armazenamentos seguros baseados em software, sem gravá-las em disco. Veja os detalhes em How to implement cryptographic modules to secure private keys used with IAM Roles Anywhere.

Desde dezembro de 2024, o credential helper também suporta TPM 2.0, permitindo que as chaves privadas sejam geradas dentro do TPM e marcadas como não exportáveis. Com chaves protegidas por TPM, a chave privada não pode ser extraída mesmo que o host do workload seja comprometido — essa é a proteção mais robusta disponível para workloads on-premises e híbridos usando IAM Roles Anywhere.

Para organizações que não utilizam módulos PKCS #11, o IAM Roles Anywhere suporta a versão 1.0.5 do credential helper para certificados X.509 e chaves privadas armazenadas nos certificate stores do macOS e Windows. No Windows, tanto CryptoAPI quanto CNG (Cryptography API: Next Generation) são suportados; no macOS, o Keychain é suportado. Nesses ambientes, a chave privada nunca é lida diretamente — a operação de assinatura é delegada ao secure store.

Se você tiver múltiplos certificados, use a flag --cert-selector do credential helper para localizar um certificado específico pelo subject, issuer ou número de série. Exemplo via arquivo JSON:

[
  {
    "Key": "x509Subject",
    "Value": "CN=Subject"
  },
  {
    "Key": "x509Issuer",
    "Value": "CN=Issuer"
  },
  {
    "Key": "x509Serial",
    "Value": "15D19632234BF759A32802C0DA88F9E8AFC8702D"
  }
]

Se o arquivo acima for salvo como selector.json, ele pode ser referenciado com --cert-selector file://path/to/selector.json. O mesmo argumento também pode ser passado diretamente pela linha de comando:

--cert-selector Key=x509Subject,Value=CN=Subject Key=x509Issuer,Value=CN=Issuer Key=x509Serial,Value=15D19632

Monitoramento de expiração de certificados

Certificados expirados podem causar falhas de autenticação e deixar sistemas vulneráveis. O IAM Roles Anywhere permite receber notificações de expiração tanto para certificados de CA quanto para certificados de entidade final, por meio dos seguintes canais:

• Expiração de certificado de CA: CloudWatch, Amazon EventBridge e AWS Health — notificação padrão 45 dias antes da expiração.
• Expiração de certificado de entidade final: EventBridge e AWS Health — notificação padrão 45 dias antes da expiração.

Esses limites de notificação são configurações padrão e podem ser personalizados conforme as instruções em Customize notification settings in IAM Roles Anywhere.

Rotação de certificados do trust anchor

A AWS recomenda rotacionar os certificados do trust anchor usando deployments blue/green para garantir a disponibilidade do serviço durante a transição. A automação deve ser integrada ao pipeline de deployment blue/green para testar a rotação de certificados.

Nessa abordagem, dois trust anchors são criados — um para cada ambiente. Isso permite testar o processo de rotação em um ambiente de staging controlado antes de aplicá-lo em produção, reduzindo o risco de indisponibilidades relacionadas a certificados.

Template de solução para deploy

A AWS disponibiliza um template de solução no repositório IAM Roles Anywhere — External PKI Integration no GitHub. O template realiza as seguintes etapas principais via AWS CloudFormation:

• Cria uma role IAM distinta com políticas com escopo nos recursos que o workload necessita.
• Atribui um relacionamento de confiança a um principal do IAM Roles Anywhere.
• Cria um trust anchor usando um bundle de certificados de uma CA externa.
• Cria um profile com as roles IAM necessárias.

Os principais parâmetros do template são:

• TrustAnchorCertificateBody (obrigatório): certificado X.509 da sua CA em formato PEM.
• WorkloadSubjectCN (padrão: WorkloadA): Subject CN do certificado do workload, usado nas condições da trust policy.
• WorkloadIssuerCN (padrão: MyCompany CA): Issuer CN do certificado da CA, usado nas condições da trust policy.
• WorkloadSANCN (padrão: WorkloadA): SAN CN do certificado do workload.
• SessionDurationSeconds (padrão: 3600): duração máxima da sessão em segundos (900–43200).
• NotificationEmail (opcional): endereço de e-mail para notificações de expiração. Quando fornecido, cria um tópico do Amazon Simple Notification Service (Amazon SNS) e uma regra do EventBridge.

Importante: O valor de SessionDurationSeconds não pode exceder o MaxSessionDuration da role IAM, que por padrão é 3600 segundos. Se você solicitar uma sessão mais longa do que o permitido, a API CreateSession do IAM Roles Anywhere retornará erro. O template mantém ambos os valores sincronizados automaticamente.

O template também impõe três condições de atributos de certificado na trust policy IAM: Issuer CN, Subject CN e SAN CN devem corresponder aos valores configurados como parâmetros. Além disso, a trust policy restringe a assunção da role ao ARN (Amazon Resource Name — Nome de Recurso da Amazon) específico do trust anchor, impedindo que outros trust anchors na mesma conta assumam aquela role.

Conclusão

O AWS IAM Roles Anywhere, combinado com certificados X.509, oferece uma forma dinâmica e segura de gerenciar identidades de workloads externos e emitir credenciais de acesso temporárias. Entender o modelo de confiança, usar atributos de certificado nas políticas e implementar controle de acesso granular são os pilares para obter o máximo de segurança nessa integração.

A escolha entre certificados just-in-time e de vida curta depende dos requisitos específicos de cada organização. O armazenamento seguro das chaves privadas — seja via HSM, TPM ou certificate stores do SO — é essencial para manter a integridade da infraestrutura de segurança. E a rotação regular dos certificados do trust anchor garante a confiabilidade do sistema a longo prazo.

Para um guia completo de planejamento de deployment, incluindo arquitetura de rede, monitoramento e considerações operacionais, consulte Planning for your IAM Roles Anywhere deployment. Dúvidas podem ser enviadas ao AWS re:Post ou ao AWS Support.

Fonte

Best practices for integrating IAM Roles Anywhere with your PKI (https://aws.amazon.com/blogs/security/best-practices-for-integrating-iam-roles-anywhere-with-your-pki/)