6 grandes vulnerabilidades do AWS IAM — e como evitá-las

O que é uma vulnerabilidade na nuvem? Em termos simples, é uma fragilidade explorável em um ambiente de nuvem. As vulnerabilidades geralmente são causadas por configurações incorretas de recursos na nuvem e podem levar a violações de segurança e falhas — especialmente quando estão relacionadas ao gerenciamento de identidade e acesso (IAM).

O IAM é notoriamente complexo, e as consequências de configurá-lo incorretamente podem ser graves. De acordo com nosso  relatório State of Cloud Security 2021, o IAM é a configuração incorreta de nuvem mais citada (mencionada por 41% dos participantes). E o Relatório de investigações sobre violações de dados da Verizon de 2021 afirma que 61% das violações analisadas envolveram credenciais.

Nesta publicação do blog, vamos apresentar várias vulnerabilidades relacionadas ao AWS IAM, além de dicas para evitá-las.

Vulnerabilidades relacionadas a credenciais da AWS

Não alternar as chaves de acesso

A vulnerabilidade: Chaves de acesso do IAM que não são alternadas

Por que é perigoso:  As chaves de acesso são credenciais de longo prazo que os usuários do IAM usam para acessar o CLI ou a API de forma programática. As chaves de acesso consistem em um ID de chave de acesso e uma chave de acesso secreta. Quanto mais tempo as chaves ficam ativas, maior a oportunidade de um agente mal-intencionado comprometê-las. Chaves de acesso comprometidas são tão perigosas quanto um nome de usuário e uma senha comprometidos.

Como corrigir: CIS AWS Foundations Benchmark v1.4.0 recomenda alternar as chaves de acesso a cada 90 dias ou menos. Isso pode ser feito pelo AWS Management Console, CLI ou API. As etapas gerais são:

1. Criar uma nova chave de acesso

2. Atualizar os aplicativos para usar a nova chave

3. Desativar a chave antiga

4. Depois de confirmar que os aplicativos estão funcionando, excluir a chave antiga

Confira aqui as etapas de correção.

Reutilizar senhas

A vulnerabilidade: Reutilizar uma senha usada anteriormente

Por que é perigoso: Assim como acontece com as chaves de acesso, quanto mais tempo uma senha fica ativa, maior a oportunidade de ela ser comprometida — e usar a mesma senha repetidamente não ajuda. Além disso, existe o risco de ataques de credential stuffing, nos quais um invasor tenta acessar uma conta usando várias combinações de nomes de usuário e senhas roubados.

Como corrigir: O CIS AWS Foundations Benchmark v1.4.0 recomenda definir uma política de senhas com a opção “Impedir a reutilização de senhas” ativada e “Número de senhas a serem lembradas” definido como 24.  Confira aqui as etapas de correção.

Não usar MFA

A vulnerabilidade: Não usar MFA

Por que é perigoso:  A autenticação multifator (MFA) é uma camada adicional de proteção para usuários do IAM. Sem ela, basta um nome de usuário e uma senha para entrar na AWS. Portanto, um invasor que obtenha um conjunto de credenciais terá acesso irrestrito. Porém, quando a MFA está ativada em uma conta, o usuário precisa fornecer uma informação adicional para entrar, como um código de uso único de um dispositivo MFA virtual ou físico. Sem essa informação, o login não será concluído e o invasor será impedido de acessar a conta.

Como corrigir: O CIS AWS Foundations Benchmark v1.4.0 recomenda ativar a MFA para todos os usuários do IAM com acesso ao console.  Confira aqui as etapas de correção.

Vulnerabilidades relacionadas a políticas do IAM

Permitir ações de listagem abrangentes em buckets do S3

A vulnerabilidade: As políticas de função do IAM permitem ações de listagem abrangentes em buckets do S3

Por que é perigoso: Se uma função do IAM tiver uma política que permita ações de listagem abrangentes em buckets do S3 e um agente mal-intencionado obtiver acesso a essa função, ele poderá enumerar todos os seus buckets para descobrir onde seus dados estão armazenados. Como o s3 sync também exige permissões de listagem, o agente mal-intencionado poderá roubar dados confidenciais dos seus buckets. As ações s3:ListAllMyBuckets, s3:List* e s3:* devem ficar de fora das políticas do IAM, a menos que sejam estritamente necessárias. Essa vulnerabilidade pode ter contribuído para a violação de dados da Capital One em 2019. Saiba mais em Uma análise técnica da violação de dados da Capital One causada por configuração incorreta na nuvem.

Como corrigir: Remova da política do IAM as permissões de listagem excessivamente abrangentes. Confira aqui as etapas de correção.

Permitir que todos os principais assumam uma função

A vulnerabilidade: As políticas de confiança de funções do IAM permitem que todos os principais assumam a função

Por que é perigoso: Permitir que qualquer usuário do IAM de qualquer conta da AWS assuma uma função na sua conta equivale a conceder acesso a todas as permissões dessa função do IAM. Isso pode ser catastrófico e levar à escalada de privilégios, à exfiltração de dados e a outros problemas. Verifique se as políticas de confiança de funções não contêm todos os elementos a seguir:

• Effect: “Allow”

• Principal: “*”

• Action: “sts:AssumeRole”

Como corrigir: Substitua o curinga por um principal específico. Confira aqui as etapas de correção.

Permitir privilégios administrativos completos

A vulnerabilidade: As políticas do IAM permitem privilégios administrativos completos "*:*"

Por que é perigoso: Ter uma política do IAM que permita todas as permissões possíveis para todos os serviços possíveis viola diretamente o princípio de segurança do  privilégio mínimo. Se um agente mal-intencionado obtiver acesso a um usuário ou função com uma política desse tipo, terá acesso ilimitado a tudo na sua conta da AWS — e será o fim. É melhor conceder apenas as permissões necessárias, sem nada além disso.

Como corrigir: Remova os curingas das políticas Allow em que Action e Resource estejam definidos como *.  Confira aqui as etapas de correção.

Dicas e práticas recomendadas para o IAM

Confira algumas práticas recomendadas para trabalhar com o IAM:

• Adote o princípio de segurança do privilégio mínimo. Conceda apenas as permissões necessárias para realizar uma tarefa. É melhor começar com uma função que tenha o mínimo de permissões e adicionar outras conforme necessário do que começar com acesso administrativo e remover permissões.

• Adote boas práticas de segurança para senhas. Você pode criar uma política de senhas para os usuários que exija o cumprimento de determinados critérios, como um tamanho mínimo (o CIS recomenda pelo menos 14 caracteres), uma combinação de letras, números e símbolos, e a não reutilização de senhas anteriores. Você também pode definir uma data de expiração para exigir que os usuários atualizem suas senhas periodicamente — por exemplo, a cada 90 dias.

• Armazene as credenciais com responsabilidade. Não salve chaves de acesso ou senhas em repositórios de código, nem mesmo nos privados: foi assim que  a Uber foi hackeada em 2016. Também não compartilhe credenciais entre usuários.

• Monitore sua configuração do IAM para saber sempre que uma política for alterada ou uma chave de acesso for ativada ou desativada. Você também deve criar regras personalizadas para atender às necessidades específicas da empresa. Sua organização exige que os usuários alterem a senha da AWS a cada 45 dias? Tenha uma solução que verifique se cada conta da AWS tem uma política de senhas que imponha esse requisito.

Quer continuar aprendendo? Confira nossa série sobre as 5 configurações incorretas mais comuns da AWS.