O blog da AWS

Protegendo suas Access Keys na AWS

Por Maria Ane Dias , Arquiteta de Soluções Especialista em Segurança na AWS e
Daniel Garcia, Especialista em Segurança na AWS

 

12 de setembro de 2022: Este blogpost foi atualizado para refletir o novo nome do AWS Single Sign-On (SSO) – AWS IAM Identity Center. Leia mais sobre a mudança de nome aqui.

Na AWS segurança é prioridade máxima. Nós temos um modelo de responsabilidade compartilhada com os clientes: a AWS é responsável por proteger a infraestrutura que executa todos os serviços oferecidos na Nuvem AWS. Essa infraestrutura é composta por hardware, software, redes e instalações que executam nossos serviços de nuvem. Os clientes são responsáveis pela segurança de suas aplicações e dados na AWS.

A responsabilidade do cliente será determinada pelos serviços de nuvem AWS selecionados por ele. Isso determina a quantidade de operações de configuração que o cliente deverá executar como parte de suas responsabilidades de segurança. Por exemplo, os clientes que implantam uma instância do Amazon EC2 são responsáveis pelo gerenciamento do sistema operacional convidado (o que inclui atualizações e patches de segurança), por qualquer utilitário ou software de aplicativo instalado pelo cliente nas instâncias, bem como pela configuração do firewall disponibilizado pela AWS (chamado de grupo de segurança) em cada instância. Para serviços como o Amazon Simple Storage Service (Amazon S3) e o Amazon DynamoDB, a AWS opera a camada de infraestrutura, o sistema operacional e as plataformas, e os clientes acessam os endpoints para armazenar e recuperar dados. Os clientes são responsáveis por gerenciar os dados deles (o que inclui opções de criptografia), classificando os ativos e usando as ferramentas de gestão de identidade e acesso para aplicar as permissões apropriadas.

Segundo relatório da Checkpoint de 2022 em 2021 houve aumento de 50% no geral de ataques por semana em redes corporativas em comparação a 2020, com os setores de educação e pesquisa sofrendo uma média de 1,605 ataques toda semana durante o ano. O relatório da Checkpoint de 2019, já apontava o acesso não autorizado (42%) e interfaces inseguras (42%) empatados em primeiro lugar como as maiores vulnerabilidades da segurança na nuvem.

A AWS oferece sem custo adicional o serviço de gestão de identidade e acesso – Identity and Access Management (IAM) – que controla a autenticação e autorização das chamadas de API aos diversos serviços. A autenticação no IAM usa um processo de assinatura digital que frequentemente processa meio bilhão de chamadas de API por segundo feitas nos nossos diversos endpoints públicos de serviços.

O IAM é responsável por 2 processos: a autenticação através da identificação do proprietário da credencial e validação da assinatura digital incluída nas chamadas de API; se a autorização for bem sucedida o IAM irá verificar a autorização da chamada baseando-se nas permissões de acesso associadas às credenciais apresentadas, e políticas de acesso dos recursos e contas AWS envolvidos.

O processo de assinatura digital pode usar credencias duradouras ou temporárias que são compostas de:

  1. Access Key ID
  2. Secret Access Key
  3. Secret Access Token (se forem credenciais temporárias)

Access Keys duradouras são geradas pelo serviço IAM e entregues ao usuário pela AWS somente na ocasião da sua criação. Estas Access Keys perdem sua validade apenas quando há uma ação ativa de seu proprietário ou administrador do sistema em desativá-las ou excluí-las.

Credenciais temporárias por sua vez, são geradas e fornecidas através de uma chamada de API ao serviço STS (Secure Token Service) e tem um prazo de validade padrão de 1 hora, podendo ser configurado (mínimo de 15 minutos e máximo de 12 horas). Depois que transcorreu este período de validade estabelecido na criação das credenciais, elas não geram mais autenticações bem-sucedidas.

Após a geração e compartilhamento das credenciais com o requisitante, a AWS perde o controle sobre a custódia (armazenamento e controle) destas chaves. É aí que entra a parte do cliente no modelo de responsabilidade compartilhada, seguindo as boas práticas para proteção das suas chaves de acesso – as access keys.

Como os endpoints de serviços da AWS são públicos e acessíveis através da Internet, qualquer ator que tenha posse dos componentes da Access Key e possa estabelecer conectividade aos endpoints da AWS na Internet, poderá gerar e assinar uma chamada de API válida. As chaves de acesso tem o mesmo nível de acesso aos recursos AWS que o usuário IAM ao qual ela está associada, portanto deve ser usado o menor nível de privilégio possível para os usuários IAM das chaves de acesso.

É recomendado que os clientes sempre que possível usem credenciais temporárias, através do uso de IAM Roles (Funções do IAM). Os IAM Roles são associados a recursos da AWS (exemplo, associar um role a uma EC2 que permite acesso da instância ao S3), estes roles não possuem credenciais permanentes – são entregues credenciais novas ao sistema operacional a cada 1 hora. Com o uso de credenciais temporárias existe menor chance de que elas sejam usadas no código ou arquivos de configuração permanentes (chumbadas) reduzindo assim o risco de serem comprometidas, e ainda que sejam comprometidas o tempo de expiração reduz significativamente o risco associado.

Pensando no caso de uso de um desenvolvedor que deseja testar uma aplicação local em sua computador acessando um DynamoDB na AWS, também é recomendado o uso de credenciais temporárias ao invés de “chumbar” uma chave de acesso (access key) no arquivo credentials no equipamento. A obtenção de credenciais temporárias pode ser feita de várias formas: usando a integração da linha de comando da AWS (AWS CLI) com o AWS IAM Identity Center (sucessor do AWS Single Sign-On), diretamente na console do AWS IAM Identity Center (sucessor do AWS Single Sign-On), ou através de scripts que fazem o processo de AssumeRole para emitir as credenciais (vários deles integrados ao IdP para autenticação SAMLv2, por exemplo) e as entregam na sessão do terminal ou no arquivo credentials.

Se for imprescindível o uso de credencias permanentes, é fundamental que sejam adotadas as seguintes práticas:

  1. Não tenha chaves de acesso do usuário root da conta AWS exceto se você tiver um caso de uso legítimo (que são extremamente limitados)
  2. Crie políticas com o menor nível de privilégio possível
  3. Rotacione periodicamente estas credenciais
  4. Monitore credenciais não utilizadas e as remova periodicamente
  5. Estabeleça restrições ao uso destas credenciais, veja algumas opções na seção abaixo.

Práticas recomendadas para restringir o uso de credenciais não-temporárias

As políticas de controle de acesso gerenciadas pela AWS são construídas para abranger as necessidades de permissões de uma ampla gama de clientes. Por este motivo estas políticas de acesso gerenciadas pela AWS por padrão não impõe nenhum tipo de condições restritivas para execução das chamadas de API, como por exemplo, a partir de uma rede específica (endereço IP, VPC, subnet, VPC Endpoint), hora/dia ou estado de validação de um segundo fator de autenticação (MFA). No entanto o IAM provê uma extensa gama de condições que podem ser usadas para restringir o acesso, conforme exemplos sugeridos a seguir.

MFA

Se as credenciais forem usadas em uma situação em que é possível validar um segundo fator de autenticação, coloque uma condição de restrição de validação do MFA.

Veja aqui exemplos de como validar um MFA através da aplicação, e aqui exemplo de validação de MFA através da CLI.

 

Restrição de origem das requisições

O IAM permite que se use uma condição aws:SourceIp usando intervalos CIDR. Se o IP estiver dentro da(s) faixa(s) de endereço(s), a requisição poderá ser permitida, caso contrário será negada.
A política abaixo restringe quaisquer chamadas de API que não sejam originadas a partir de um endereço IP pertencente às faixas específicadas (192.0.2.0/24 e 203.0.113.0/24).

Alerta: tenha cuidado e teste antes de usar a restrição por endereço IP em SCPs (que se aplicam para toda uma ou mais contas AWS) sem condições adicionais a “principals” específicos. Os serviços da AWS fazem chamadas aos seus recursos, por exemplo o AWS CloudFormation, e em casos limitados estas chamadas podem ser bloqueadas mesmo que a política incluia a condição de excessão conforme o exemplo acima (“Bool”: {“aws:ViaAWSService”: “false”}).

Quando os recursos que devem fazer as chamadas de API estão na AWS (como EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), AWS Lambda) deve-se usar atributos de origem nativos da AWS, como o VPC de origem (aws:SourceVpc) ou o VPC Endpoint de origem (aws:SourceVpce).

 

Sumário

Buscamos sempre evitar que access keys sejam expostas acidentalmente e que pessoas não autorizadas tenham acesso a elas. Porém, caso isso ocorra, o impacto pode ser reduzido significativamente se as access keys estiverem limitadas nas ações que permitem (privilégio mínimo) e incorporem barreiras adicionais de proteção (condições) para que se consiga utilizá-las conforme sugestões acima.

Adicionar estas camadas de segurança é muito importante em um mundo digital, considerando o cenário atual de cibersegurança.

Não deixe para amanhã a proteção de suas access keys. Faça sua parte do modelo de responsabilidade compartilhada e não deixe seus dados em risco!

Referências

 

Sobre os autores

Maria Ane Dias é arquiteta de soluções especialista em Segurança na AWS, tem um background em Desenvolvimento e gosta bastante de IoT e da área de Manufatura. Atua apoiando clientes a criarem e manterem suas jornadas de segurança na nuvem. Tem 20 anos de experiência na área de TI.

 

 

 

 

Daniel Garcia é especialista em segurança na AWS com mais de 20 anos de experiência em tecnologia e segurança da informação. Trabalha junto aos clientes do Brasil e da América Latina na definição, implementação de suas jornadas de segurança na nuvem.

 

 

 

 

Agradecimentos: Julio Carvalho e Fernando Cabral pela revisão deste blogpost.