SEC02-BP03 Armazenar e usar segredos com segurança

Uma workload exige um recurso automatizado para comprovar a identidade dela em bancos de dados, recursos e serviços de terceiros. Isso é realizado com o uso de credenciais de acesso secretas, como chaves de acesso de API, senhas e tokens do OAuth. Utilizar um serviço com propósito específico para armazenar, gerenciar e alternar essas credenciais ajuda a reduzir a probabilidade de comprometimento dessas credenciais.

Resultado desejado: implementar um mecanismo para gerenciar com segurança credenciais de aplicações que concretize os seguintes objetivos:

• Identificar quais segredos são necessários para a workload.

• Reduzir o número de credenciais de longo prazo necessárias substituindo-as por credenciais de curto prazo quando possível.

• Estabelecer um armazenamento seguro e uma alternância automatizada das credenciais de longo prazo restantes.

• Auditar o acesso aos segredos existentes na workload.

• Monitorar continuamente para confirmar que nenhum segredo seja incorporado a código-fonte durante o processo de desenvolvimento.

• Reduzir a probabilidade de divulgação acidental de credenciais.

Antipadrões comuns:

• Ausência de alternância de credenciais.

• Armazenar credenciais de longo prazo em código-fonte ou arquivos de configuração.

• Armazenar credenciais em repouso não criptografadas.

Benefícios do estabelecimento desta prática recomendada:

• Os segredos são armazenados com criptografia em repouso e em trânsito.

• O acesso às credenciais é fechado por meio de uma API (pense nisso como uma máquina automática de venda de credenciais).

• O acesso a uma credencial (de leitura e gravação) é auditado e registrado.

• Separação de preocupações: a alternância de credenciais é realizada por um componente separado, que pode ser segregado do restante da arquitetura.

• Os segredos são automaticamente distribuídos sob demanda em componentes de software e a alternância ocorre em um local central.

• O acesso às credenciais pode ser controlado de forma detalhada.

Nível de exposição a riscos quando esta prática recomendada não é estabelecida: alto

Orientação de implementação

Antes, as credenciais usadas para realizar a autenticação em bancos de dados, APIs de terceiros, tokens e outros segredos podiam ser incorporadas em código-fonte ou em arquivos do ambiente. A AWS oferece vários mecanismos para armazenar essas credenciais com segurança, alterná-las automaticamente e auditar o uso delas.

A melhor forma de abordar o gerenciamento de segredos é seguir as orientações de remover, substituir e alternar. A credencial mais segura é a que você não precisa armazenar, gerenciar nem processar. Pode haver credenciais que não sejam mais necessárias ao funcionamento da workload que podem ser removidas com segurança.

Para credenciais que ainda são necessárias ao funcionamento adequado da workload, pode haver uma oportunidade de substituir uma credencial de longo prazo por uma credencial temporária ou de curto prazo. Por exemplo, em vez de codificar uma chave de acesso secreta da AWS, pense em substituir essa credencial de longo prazo por uma temporária utilizando perfis do IAM.

Alguns segredos duradouros podem não ser removidos ou substituídos. Esses segredos podem ser armazenados em um serviço, como o AWS Secrets Manager, no qual eles podem ser armazenados centralmente, gerenciados e alternados regularmente.

Uma auditoria do código-fonte da workload e os arquivos de configuração podem revelar muitos tipos de credencial. A seguinte tabela resume as estratégias para lidar com tipos comuns de credenciais:

Credential type	Description	Suggested strategy
IAM access keys	AWS IAM access and secret keys used to assume IAM roles inside of a workload	Replace: Use Perfis do IAM assigned to the compute instances (such as Amazon EC2 or AWS Lambda) instead. For interoperability with third parties that require access to resources in your Conta da AWS, ask if they support Acesso entre contas da AWS. For mobile apps, consider using temporary credentials through Grupos de identidades (identidades federadas) do Amazon Cognito. For workloads running outside of AWS, consider IAM Roles Anywhere or AWS Systems Manager Hybrid Activations.
SSH keys	Secure Shell private keys used to log into Linux EC2 instances, manually or as part of an automated process	Replace: Use AWS Systems Manager or EC2 Instance Connect to provide programmatic and human access to EC2 instances using IAM roles.
Application and database credentials	Passwords – plain text string	Rotate: Store credentials in AWS Secrets Manager and establish automated rotation if possible.
Amazon RDS and Aurora Admin Database credentials	Passwords – plain text string	Replace: Use the Integração do Secrets Manager ao Amazon RDS or Amazon Aurora. In addition, some RDS database types can use IAM roles instead of passwords for some use cases (for more detail, see Autenticação de banco de dados do IAM).
OAuth tokens	Secret tokens – plain text string	Rotate: Store tokens in AWS Secrets Manager and configure automated rotation.
API tokens and keys	Secret tokens – plain text string	Rotate: Store in AWS Secrets Manager and establish automated rotation if possible.

Um antipadrão comum é incorporar chaves de acesso do IAM ao código-fonte, a arquivos de configuração ou aplicativos móveis. Quando uma chave de acesso do IAM é necessária para comunicação com um serviço da AWS, utilize credenciais de segurança temporárias (de curto prazo). Essas credenciais de curto prazo podem ser fornecidas por meio de perfis do IAM para instâncias do EC2, perfis de execução para funções do Lambda, perfis do Cognito IAM para acesso de usuários móveis e políticas do IoT Core para dispositivos IoT. Ao fazer interface com terceiros, prefira delegar o acesso a um perfil do IAM com o acesso necessário aos recursos de sua conta em vez de configurar um usuário do IAM e enviar a terceiros a chave de acesso secreta desse usuário.

Há muitos casos em que a workload exige o armazenamento de segredos necessários para interoperar com outros serviços e recursos. O AWS Secrets Manager foi concebido especificamente para gerenciar com segurança essas credenciais, bem como o armazenamento, o uso e a alternância de tokens de API, senhas e outras credenciais.

O AWS Secrets Manager oferece cinco recursos principais para proteger o armazenamento e o processamento de credenciais sigilosas: criptografia em repouso, criptografia em trânsito, auditoria abrangente, controle de acesso detalhado e alternância de credenciais extensíveis. Outros serviços de gerenciamento de segredos de parceiros da AWS ou soluções desenvolvidas localmente que oferecem recursos e garantias semelhantes também são aceitáveis.

Etapas da implementação

1. Identifique caminhos de código que contenham credenciais codificadas usando ferramentas automatizadas, como o Amazon CodeGuru.

   • Utilize o Amazon CodeGuru para verificar seus repositórios de código. Depois de concluir a revisão, filtre Type=Secrets no CodeGuru para encontrar linhas de código problemáticas.

2. Identifique credenciais que possam ser removidas ou substituídas.

   1. Identifique credenciais não mais necessárias e marque-as para remoção.

   2. Para chaves secretas da AWS incorporadas ao código-fonte, substitua-as por perfis do IAM associados aos recursos necessários. Se parte de sua workload estiver fora do AWS, mas exigir credenciais do IAM para acessar recursos da AWS, considere o IAM Roles Anywhere ou o AWS Systems Manager Hybrid Activations.

3. Para outros terceiros, segredos duradouros que exijam o uso da estratégia de alternância, integre o Secrets Manager ao seu código para recuperar segredos de terceiros no tempo de execução.

   1. O console do CodeGuru pode criar um segredo automaticamente no Secrets Manager utilizando as credenciais descobertas.

   2. Integre a recuperação de segredos do Secrets Manager ao código de sua aplicação.

      • Funções do Lambda Sem Servidor podem usar uma extensão do Lambda independente de linguagem.

      • Para instâncias ou contêineres do EC2, a AWS oferece código do lado do cliente de exemplo para recuperar segredos do Secrets Manager em várias linguagens de programação conhecidas.

4. Revise periodicamente sua base de código e verifique novamente para confirmar se não há novos segredos adicionados ao código.

   • Considere usar uma ferramenta como o git-secrets para impedir a confirmação de novos segredos em seu repositório de código-fonte.

5. Monitore a atividade do Secrets Manager quanto a indicações de uso inesperado, acesso inadequado a segredos ou tentativas de excluir segredos.

6. Reduza a exposição humana às credenciais. Restrinja o acesso a credenciais de leitura, gravação e modificação a um perfil do IAM dedicado a esse fim, e apenas forneça acesso para assumir o perfil a um pequeno subconjunto de usuários operacionais.

Recursos

Práticas recomendadas relacionadas:

• SEC02-BP02 Usar credenciais temporárias

• SEC02-BP05 Fazer a auditoria e a alternância periódica das credenciais

Documentos relacionados:

• Conceitos básicos do AWS Secrets Manager

• Provedores de identidades e federação

• Amazon CodeGuru apresenta o Secrets Detector

• Como o AWS Secrets Manager usa o AWS Key Management Service

• Criptografia e descriptografia de segredos no Secrets Manager

• Entradas do blog do Secrets Manager

• Amazon RDS anuncia integração com o AWS Secrets Manager

Vídeos relacionados:

• Práticas recomendadas para gerenciar, recuperar e alternar segredos em grande escala

• Encontre segredos codificados com o Amazon CodeGuru Secrets Detector

• Proteger segredos para workloads híbridas usando o AWS Secrets Manager

Workshops relacionados:

• Armazenar, recuperar e gerenciar credenciais sigilosas no AWS Secrets Manager

• Ativações híbridas do AWS Systems Manager