SEC02-BP03 Armazenar e usar segredos com segurança - Pilar de segurança

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 é feito 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 fazer a rotação de credenciais ajuda a reduzir a probabilidade de comprometimento dessas credenciais.

Resultado desejado: implementar um mecanismo para gerenciar com segurança credenciais da aplicação que atinja as seguintes metas:

  • 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 rotação automatizada das credenciais de longo prazo restantes.

  • Auditar o acesso aos segredos existentes na workload.

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

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

Práticas comuns que devem ser evitadas:

  • Ausência de rotação 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 de implementar esta prática recomendada:

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

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

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

  • Separação de preocupações: a rotação 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 rotação ocorre em um local central.

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

Nível de risco exposto se esta prática recomendada não for estabelecida: Alto

Orientação para implementação

No passado, 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 fazer a rotação. 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, considere substituir essa credencial de longo prazo por uma temporária utilizando perfis do IAM.

Em algumas situações, talvez alguns segredos de longa duração não possam removidos ou substituídos. Esses segredos podem ser armazenados em um serviço, como o AWS Secrets Manager, onde podem ser armazenados, gerenciados e ter a rotação feita centralmente de tempos em tempos.

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:

Tipo de credencial Descrição Estratégia sugerida
Chaves de acesso ao IAM Chaves secretas e de acesso do AWS IAM usadas para assumir perfis do IAM dentro de uma workload Substitua: em vez disso, use perfis do IAM atribuídos às instâncias de computação (como Amazon EC2 ou AWS Lambda). Para interoperabilidade com terceiros que precisam de acesso a recursos em sua Conta da AWS, pergunte se eles oferecem suporte ao acesso entre contas da AWS. Para aplicações móveis, considere usar credenciais temporárias nos bancos de identidades do Amazon Cognito (identidades federadas). Para workloads executadas fora da AWS, considere o usar o IAM Roles Anywhere ou o AWS Systems Manager Hybrid Activations. Para contêineres, consulte Perfil do IAM para tarefas do Amazon ECS ou Perfil do IAM em nós do Amazon EKS.
Chaves SSH Chaves privadas do Secure Shell usadas para fazer login em instâncias do EC2 Linux, manualmente ou como parte de um processo automatizado Substitua: use o AWS Systems Manager ou o EC2 Instance Connect para fornecer acesso programático e humano às instâncias do EC2 usando perfis do IAM.
Credenciais de aplicações e bancos de dados Senhas: sequência de texto simples Rotação: armazene as credenciais no AWS Secrets Manager e estabeleça a rotação automática, se possível.
Credenciais do Amazon RDS e do Aurora Admin Database Senhas: sequência de texto simples Substitua: use a integração do Secrets Manager com o Amazon RDS ou o Amazon Aurora. Além disso, alguns tipos de banco de dados do RDS podem usar perfis do IAM em vez de senhas para alguns casos de uso (para obter mais detalhes, consulte Autenticação de banco de dados do IAM).
Tokens OAuth Tokens secretos: sequência de texto simples Rotação: armazene tokens no AWS Secrets Manager e configure a rotação automática.
Chaves e tokens de API Tokens secretos: sequência de texto simples Rotação: armazene no AWS Secrets Manager e estabeleça a rotação automática, se possível.

Um prática não recomendada comum é incorporar chaves de acesso do IAM a código-fonte, arquivos de configuração ou aplicações móveis. Quando uma chave de acesso do IAM for necessária para se comunicar com um serviço da AWS, use 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, funções de execução para funções Lambda, perfis do IAM do Cognito para acesso de usuários móveis e políticas do IoT Core para dispositivos de IoT. Ao interagir com terceiros, prefira delegar acesso a um perfil do IAM com o acesso necessário aos recursos da sua conta em vez de configurar um usuário do IAM e enviar para terceiros a chave de acesso secreta desse usuário.

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

O AWS Secrets Manager oferece cinco recursos principais para garantir o armazenamento e o manuseio seguros de credenciais confidenciais: criptografia em repouso, criptografia em trânsito, auditoria abrangente, controle de acesso refinado e rotação extensível de credenciais. 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.

Ao recuperar um segredo, é possível usar os componentes de cache do lado do cliente do Secrets Manager a fim de armazená-lo em cache para uso futuro. Recuperar um segredo armazenado em cache é mais rápido do que recuperá-lo do Secrets Manager. Além disso, como há um custo para chamar APIs do Secrets Manager, usar um cache pode reduzir os custos. Para ver todas as formas pelas quais você pode recuperar segredos, consulte Obter segredos.

nota

Algumas linguagens podem exigir que você implemente sua própria criptografia na memória para o armazenamento em cache do lado do cliente.

Etapas de implementação

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

    1. Utilize o Amazon CodeGuru para verificar seus repositórios de código. Quando a revisão estiver concluída, 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 da sua workload for externa à AWS, mas exigir credenciais do IAM para acessar os recursos da AWS, considere usar o IAM Roles Anywhere ou o AWS Systems Manager Hybrid Activations.

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

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

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

      1. As funções do Lambda sem servidor podem usar uma extensão do Lambda independente de linguagem.

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

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

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

  5. Monitore a atividade do Secrets Manager em busca de indicações de uso inesperado, acesso inadequado a segredos ou tentativas de exclusão de 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:

Documentos relacionados:

Vídeos relacionados:

Workshops relacionados: