View a markdown version of this page

Centralização do gerenciamento das chaves de acesso do IAM no AWS Organizations usando o Terraform - Recomendações da AWS

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Centralização do gerenciamento das chaves de acesso do IAM no AWS Organizations usando o Terraform

Aarti Rajput, Chintamani Aphale, T.V.R.L.Phani Kumar Dadi, Pratap Kumar Nanda, Pradip Kumar Pandey e Mayuri Shinde, Amazon Web Services

Resumo

Aplicar as regras de segurança para chaves e senhas é uma tarefa essencial para qualquer organização. Uma regra fundamental é rotacionar as chaves do AWS Identity and Access Management (IAM) periodicamente para garantir a segurança. As chaves de acesso da AWS geralmente são criadas e configuradas localmente sempre que equipes precisam acessar a AWS por meio da AWS Command Line Interface (AWS CLI) ou de aplicações externas à AWS. Para manter uma segurança robusta em toda a organização, as chaves de segurança antigas devem ser alteradas ou excluídas após o cumprimento da exigência ou periodicamente. O processo de gerenciar a rotação de chaves em várias contas de uma organização é demorado e trabalhoso. Esse padrão auxilia na automação do processo de rotação por meio do Account Factory for Terraform (AFT) e dos serviços da AWS.

O padrão fornece os seguintes benefícios:

  • Gerencia sua chave de acesso IDs e chaves de acesso secretas em todas as contas da sua organização a partir de um local central.

  • Rotação automática das variáveis de ambiente AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY.

  • Imposição da renovação se as credenciais do usuário forem comprometidas.

O padrão usa o Terraform para implantar funções do AWS Lambda, regras da EventBridge Amazon e funções do IAM. Uma EventBridge regra é executada em intervalos regulares e chama uma função Lambda que lista todas as chaves de acesso do usuário com base em quando elas foram criadas. As funções do Lambda adicionais criam um novo ID de chave de acesso e uma chave de acesso secreta, caso a chave anterior seja mais antiga do que o período de rotação definido (por exemplo, 45 dias), e notificam um administrador de segurança usando o Amazon Simple Notification Service (Amazon SNS) e o Amazon Simple Email Service (Amazon SES). Os segredos são criados no AWS Secrets Manager para o usuário, a chave de acesso secreta anterior é armazenada no Secrets Manager e as permissões para acessar a antiga chave são configuradas. Para garantir que a chave de acesso antiga não seja mais usada, ela é desativada após um período de inatividade (por exemplo, 60 dias, o que ocorreria 15 dias após a rotação das chaves no nosso exemplo). Após um período de buffer de inatividade (por exemplo, 90 dias, ou 45 dias após as chaves serem rotacionadas no nosso exemplo), as chaves de acesso antigas são excluídas do AWS Secrets Manager. Para obter uma arquitetura e um fluxo de trabalho detalhados, consulte a seção Arquitetura.

Pré-requisitos e limitações

Arquitetura

Repositórios do AFT

Este padrão usa o Account Factory for Terraform (AFT) para criar todos os recursos da AWS necessários e o pipeline de código para implantar esses recursos em uma conta de implantação. O pipeline de código é executado em dois repositórios:

  • A personalização global contém código do Terraform que será executado em todas as contas registradas no AFT.

  • As personalizações da conta contêm código do Terraform que será executado na conta de implantação.

Detalhes do recurso

Os CodePipeline trabalhos da AWS criam os seguintes recursos na conta de implantação:

  • EventBridge Regra da AWS e regra configurada

  • Função do Lambda em account-inventory

  • Função do Lambda em IAM-access-key-rotation

  • Função do Lambda em Notification

  • Bucket do Amazon Simple Storage Service (Amazon S3) que contém um modelo de e-mail

  • Política do IAM necessária

Arquitetura

Arquitetura para centralizar o gerenciamento de chaves de acesso do IAM no AWS Organizations

O diagrama ilustra o seguinte:

  1. Uma EventBridge regra chama a função account-inventory Lambda a cada 24 horas.

  2. A função account-inventory Lambda consulta o AWS Organizations para obter uma lista de todas as contas IDs, nomes de contas e e-mails de contas da AWS. 

  3. A função do Lambda account-inventory inicia a função do Lambda IAM-access-key-auto-rotation para cada conta da AWS e transfere os metadados para processamento adicional.

  4. A função do Lambda IAM-access-key-auto-rotation usa um perfil do IAM assumido para acessar a conta da AWS. O script do Lambda executa uma auditoria em todos os usuários e suas chaves de acesso do IAM na conta.

  5. O limite de rotação da chave do IAM (período de rotação) é configurado como uma variável de ambiente quando a função do Lambda IAM-access-key-auto-rotation é implantada. Se o período de rotação for modificado, a função do Lambda IAM-access-key-auto-rotation é implantada novamente com a variável de ambiente atualizada. Você pode configurar parâmetros para definir o período de rotação, o período de inatividade das chaves antigas e o buffer de inatividade após o qual as chaves antigas serão excluídas (consulte Personalização de parâmetros para o pipeline de código na seção Épicos).

  6. A função do Lambda IAM-access-key-auto-rotation valida a data de criação da chave de acesso com base em sua configuração. Se a data de criação da chave de acesso do IAM não ultrapassou o período de rotação definido, a função do Lambda não executa nenhuma ação adicional.

  7. Se a data de criação da chave de acesso do IAM exceder o período de rotação definido, a função do Lambda IAM-access-key-auto-rotation cria uma nova chave e rotaciona a chave existente.

  8. A função do Lambda armazena a chave antiga no Secrets Manager e limita as permissões ao usuário cujas chaves de acesso não estão em conformidade com os padrões de segurança. A função do Lambda também cria uma política baseada em recursos que permite que somente a entidade principal especificada do IAM acesse e recupere o segredo.

  9. A função do Lambda IAM-access-key-rotation chama a função do Lambda Notification.

  10. A função do Lambda Notification consulta o bucket do S3 em busca de um modelo de e-mail e gera dinamicamente mensagens de e-mail com os metadados de atividade relevantes.

  11. A função do Lambda Notification chama o Amazon SES para a execução de ações subsequentes.

  12.  O Amazon SES envia um e-mail para o endereço de e-mail do proprietário da conta com as informações relevantes.

Ferramentas

Serviços da AWS

  • O AWS Identity and Access Management (IAM) ajuda você a gerenciar com segurança o acesso aos seus recursos da AWS, controlando quem está autenticado e autorizado a usá-los. Este padrão requer perfis IAM e permissões.

  • O AWS Lambda é um serviço de computação que ajuda você a executar código sem exigir provisionamento ou gerenciamento de servidores. Ele executa o código somente quando necessário e dimensiona automaticamente, assim, você paga apenas pelo tempo de computação usado.

  • O AWS Secrets Manager ajuda você a substituir credenciais codificadas em seu código, incluindo senhas, por uma chamada de API ao Secrets Manager para recuperar o segredo programaticamente.

  • Amazon Simple Email Service (Amazon SES): ajuda você a enviar e receber e-mails usando seus próprios endereços de e-mail e domínios.

Outras ferramentas

  • O Terraform é uma ferramenta de infraestrutura como código (IaC) HashiCorp que ajuda você a criar e gerenciar recursos na nuvem e no local.

Repositório de código

As instruções e o código desse padrão estão disponíveis no repositório de rotação de chaves de acesso GitHub do IAM. Você pode realizar a implantação do código na conta central de implantação do AWS Control Tower para gerenciar a rotação de chaves a partir de um único local.

Práticas recomendadas

Épicos

TarefaDescriptionHabilidades necessárias

Clonar o repositório.

  1. Clone o GitHub repositório de rotação da chave de acesso do IAM:

    $ git clone https://github.com/aws-samples/centralized-iam-key-management-aws-organizations-terraform.git
  2. Confirme que sua cópia local do repositório contém três pastas:

    $ cd Iam-Access-keys-Rotation $ ls org-account-customization global-account-customization account-customization
DevOps engenheiro
TarefaDescriptionHabilidades necessárias

Configure a conta de inicialização.

Como parte do processo de inicialização do AFT, você deve ter uma pasta chamada aft-bootstrap em sua máquina local.

  1. Copie todos os arquivos do Terraform manualmente da sua GitHub org-account-customizationpasta local para a sua aft-bootstrap pasta.

  2. Execute os comandos do Terraform para configurar o perfil global de acesso entre contas na conta gerencial do AWS Control Tower:

    $ cd aft-bootstrap $ terraform init $ terraform apply —auto-approve
DevOps engenheiro

Configure as personalizações globais.

Como parte da configuração da pasta do AFT, você deve ter uma pasta chamada aft-global-customizations em sua máquina local.

  1. Copie manualmente todos os arquivos do Terraform da sua GitHub global-account-customizationpasta local para a sua aft-global-customizations/terraform pasta.

  2. Envie o código para a AWS CodeCommit:

    $ git add * $ git commit -m "message" $ git push
DevOps engenheiro

Configure as personalizações da conta.

Como parte da configuração da pasta do AFT, você deve ter uma pasta chamada aft-account-customizations em sua máquina local.

  1. Crie uma pasta com o número da conta fornecida.

  2. Copie manualmente todos os arquivos do Terraform da pasta local GitHub de personalização da conta para sua pasta. aft-account-customizations/<vended account>/terraform

  3. Envie o código para a AWS CodeCommit:

    $ git add * $ git commit -m "message" $ git push
DevOps engenheiro
TarefaDescriptionHabilidades necessárias

Personalize os parâmetros do pipeline de código que não são do Terraform para todas as contas.

Crie um arquivo chamado input.auto.tfvars na pasta aft-global-customizations/terraform/, e forneça os dados de entrada necessários. Consulte o arquivo no GitHub repositório para ver os valores padrão.

DevOps engenheiro

Personalize os parâmetros do pipeline de código para a conta de implantação.

Crie um arquivo chamado input.auto.tfvars na aft-account-customizations/<AccountName>/terraform/ pasta e envie o código para a AWS CodeCommit. Enviar código para a AWS inicia CodeCommit automaticamente o pipeline de código.

Especifique os valores dos parâmetros com base nos requisitos da sua organização, incluindo os seguintes itens (consulte o arquivo no repositório do GitHub para conferir os valores padrão):

  • s3_bucket_name: um nome exclusivo para o bucket do modelo de e-mail.

  • s3_bucket_prefix: um nome para a pasta do bucket do S3.

  • admin_email_address: o endereço de e-mail do administrador que deve receber a notificação.

  • org_list_account: o número da conta gerencial.

  • rotation_period: o número de dias após os quais uma chave deve ser rotacionada de ativa para inativa.

  • inactive_period: o número de dias após os quais as chaves rotacionadas devem ser desativadas. Este valor deve ser maior que o valor estabelecido para rotation_period.

  • inactive_buffer: o período de carência entre a rotação e a desativação de uma chave.

  • recovery_grace_period: o período de carência entre a desativação e a exclusão de uma chave.

  • dry_run_flag: defina como verdadeiro se você deseja enviar uma notificação para o administrador para fins de teste, sem rotacionar as chaves.

  • store_secrets_in_central_account: defina como verdadeiro se você deseja armazenar o segredo na conta de implantação. Se a variável for definida como falsa, que é o padrão, o segredo será armazenado na conta de membro.

  • credential_replication_region: a região da AWS em que você deseja implantar a função do Lambda e os buckets do S3 para o modelo de e-mail.

  • run_lambda_in_vpc: defina como verdadeiro para executar a função do Lambda dentro da VPC.

  • vpc_id: o ID da VPC da conta de implantação, caso você deseje executar a função do Lambda dentro da VPC.

  • vpc_cidr: o intervalo implantação CIDR para a conta de implantação.

  • subnet_id— A sub-rede da conta IDs de implantação.

  • create_smtp_endpoint: defina como verdadeiro se você deseja habilitar o endpoint de e-mail.

DevOps engenheiro
TarefaDescriptionHabilidades necessárias

Valide a solução.

  1. No Console de Gerenciamento da AWS, faça login na conta de implantação.

  2. Abra o console do IAM e verifique se as credenciais do usuário (chave de acesso IDs e chaves secretas) estão sendo alternadas conforme especificado.

  3. Após uma chave IAM ser rotacionada, confirme o seguinte:

    • O valor antigo está armazenado no AWS Secrets Manager.

    • O nome do segredo está no formato Account_<account ID>_User_<username>_AccessKey.

    • O usuário especificado no parâmetro admin_email_address recebe uma notificação por e-mail sobre a rotação da chave.

DevOps engenheiro
TarefaDescriptionHabilidades necessárias

Personalize a data da notificação por e-mail.

Se você deseja enviar notificações por e-mail em um dia específico antes de desabilitar a chave de acesso, pode atualizar a função do Lambda IAM-access-key-auto-rotation com essas alterações:

  1. Defina uma variável chamada notify-period.

  2. Adicione uma condição if em main.py antes de desativar a chave:

    If (keyage>rotation-period-notify-period){ send_to_notifier(context, aws_account_id, account_name, resource_owner, resource_actions[resource_owner], dryrun, config.emailTemplateAudit) }
DevOps engenheiro

Solução de problemas

ProblemaSolução

A execução da função do Lambda account-inventory falha com o erro AccessDenied ao listar contas.

Se você encontrar esse problema, é necessário validar as permissões:

  1. Faça login na conta recém-vendida, abra o CloudWatch console da Amazon e, em seguida, visualize o grupo /aws/lambda/account-inventory-lambda de CloudWatch registros.

  2. Nos CloudWatch registros mais recentes, identifique o número da conta que está causando o problema de acesso negado.

  3. Faça login na conta gerencial do AWS Control Tower e confirme se o perfil allow-list-account foi criado.

  4. Caso o perfil não exista, execute novamente o código do Terraform usando o comando terraform apply.

  5. Escolha a guia Conta confiável e valide que a mesma conta é confiável.

Recursos relacionados