Como Persuadir Engenheiros a Rotacionar suas Chaves de Acesso AWS - Emptor

Nos primeiros dias do Emptor, costumávamos manter vários usuários IAM para nós mesmos, o que eventualmente multiplicou nossas responsabilidades de proteger um número crescente de chaves de acesso. Este é um problema comum com várias contas da AWS, onde cada engenheiro tem um usuário IAM para cada conta que usa.

Enquanto expandíamos nosso negócio, também nos concentramos em melhorar a segurança de nossos sistemas para garantir a segurança dos dados de nossos clientes. Nosso objetivo principal era aprimorar a segurança de nossos ambientes de produção, começando com uma revisão minuciosa das melhores práticas de segurança da AWS. Notamos que a maioria dos engenheiros geralmente tinha mais permissões do que o necessário para seu trabalho diário e que as chaves de acesso muitas vezes não eram rotacionadas por vários meses.

Existem vários riscos associados a não rotacionar as chaves, incluindo possíveis danos a nossos sistemas de produção se as chaves de acesso de um de nossos engenheiros fossem comprometidas.

Graças a ferramentas como o aws-vault, agora podemos armazenar essas chaves de forma segura em máquinas locais e garantir a segurança da autenticação para todos os engenheiros, mas isso nos deixou com um problema adicional: mesmo quando as chaves da AWS são armazenadas de forma segura, elas devem ser rotacionadas regularmente, e nem a AWS nem o aws-vault fornecem uma maneira automatizada de fazer isso. Portanto, tornou-se importante encontrarmos uma maneira de fazer com que os engenheiros rotem suas chaves da AWS regularmente. Para isso, durante uma de nossas reuniões diárias, desenvolvemos as seguintes regras:

• Os engenheiros devem ter apenas um usuário IAM e podem assumir funções IAM conforme necessário para obter diferentes conjuntos de permissões em diferentes contas.
• O conjunto de permissões padrão dos engenheiros deve permitir apenas que eles façam alterações em seu próprio usuário IAM (alterar senha, criar novas chaves de acesso, configurar um dispositivo MFA, etc.).
• Os engenheiros não devem ter permissão para assumir funções IAM, a menos que configurem um dispositivo MFA.
• Os engenheiros não devem ter mais de um par de chaves de acesso habilitadas a qualquer momento.
• Os engenheiros devem rotacionar suas chaves de acesso e a senha do console de gerenciamento da AWS a cada 90 dias.

Conseguimos implementar a maioria dessas condições com a ajuda dos recursos existentes do IAM, exceto pela exigência de impor uma política de expiração de 90 dias para as chaves de acesso. Como tínhamos uma pequena equipe de engenharia, nossa primeira solução para impor essa condição específica foi lembrar os engenheiros durante algumas reuniões a cada mês. Funcionou bem por vários meses, mas não escalou à medida que o número de equipes aumentou e mais engenheiros se juntaram ao Emptor. Então, decidimos automatizar esse procedimento, desenvolvendo uma ferramenta interna que chamamos de AWS Monitor.

Para construir esse sistema, a primeira coisa que precisávamos fazer era marcar cada usuário IAM com dados úteis, para que o AWS Monitor pudesse discernir quem ou o que está usando suas credenciais e notificar o proprietário sobre as iminentes expirações de suas chaves de acesso. Começamos com as seguintes tags, que se mostraram muito úteis:

• type: Esta tag nos ajudou a diferenciar entre usuários IAM para engenheiros (type=engineer) e máquinas (type=machine).
• slack-id: Esta tag nos ajudou a identificar a conta do Slack do engenheiro a quem esse usuário IAM pertence, para que possamos enviar-lhes notificações privadas por meio de nosso sistema.
• full-name: Esta tag opcional nos ajudou a melhorar a interface do usuário do console da AWS. Como o console não menciona o nome da pessoa que é proprietária do usuário IAM, adicioná-lo a uma tag facilita a pesquisa por um usuário específico e a identificação dos proprietários da conta durante uma auditoria.

Depois de conseguirmos diferenciar entre os usuários IAM, criamos um aplicativo Slack para enviar mensagens de notificação privadas aos engenheiros e construímos um aplicativo sem servidor que é executado diariamente para verificar a idade das chaves de acesso de cada usuário IAM em todas as nossas contas da AWS. Então, ele notifica o engenheiro relevante três vezes no Slack, usando seu ID do Slack que armazenamos como uma tag, assim que suas chaves de acesso atingirem as idades de 76 dias, 81 dias e 86 dias. No 91º dia, ele desabilita automaticamente suas chaves de acesso.

Também enviamos as mesmas mensagens a um canal do Slack onde a Equipe de Infraestrutura pode monitorar a expiração e a rotação das chaves de acesso com consistência. Esse sistema de monitoramento também notifica a equipe quando um novo par de chaves de acesso é criado, para que possamos verificar se essas chaves de acesso foram realmente criadas por um dos engenheiros do Emptor ou por um usuário não autorizado. Impressionante, não é?

Esse sistema nos permitiu monitorar todos os nossos usuários IAM, incentivar nossos engenheiros a praticar a rotação frequente de chaves de acesso e auditar eficientemente a idade e o uso de todas as nossas chaves de acesso. É uma pequena ferramenta que levou apenas alguns dias para construirmos, mas nos oferece informações inestimáveis sobre o aspecto mais vulnerável da AWS. Nosso próximo objetivo é explorar o serviço AWS SSO. Acreditamos que ele possa nos fornecer um conjunto de recursos que nos permitirá parar de usar usuários IAM indefinidamente.

Se você gosta de ler sobre nossas experiências com a AWS, não se esqueça de se inscrever em nosso blog.

Feliz AWS-ing!