Skip to main content

Boas práticas para gerenciar segredos em aplicações serverless

Escrito por
Cheat Sheet assetts

13 de junho de 2019

0 minutos de leitura

Se você está desenvolvendo uma aplicação serverless, é provável que suas funções precisem acessar segredos ou outros tipos de informações confidenciais armazenadas, como chaves de API, tokens ou senhas. No entanto, gerenciar esses segredos corretamente pode ser uma tarefa difícil.

Quando os usuários não adotam um serviço de gerenciamento de chaves, esses segredos acabam, infelizmente, armazenados no código-fonte ou em arquivos de manifesto. Isso pode ter consequências devastadoras, como o vazamento de segredos por exposição e manipulação do código-fonte, além de tornar mais complexo gerenciar tarefas como a rotação e a desativação de chaves.

Você pode baixar o PDF do guia rápido de segurança serverless ou ler a versão do artigo online.

Veja a seguir um exemplo de uma forma insegura de lidar com segredos:


service:
 name: hello-world

provider:
  name: aws

functions:
  helloWorld:
    handler: helloworld.get
    environment:
      GITHUB_API_KEY: ABCDEF

  goodbyeWorld:
    handler: goodbye.get

Primeiro, vamos analisar os aspectos positivos dessa estrutura. A função helloWorld aplica bem o princípio de isolamento de funções. A variável de ambiente GITHUB_API_KEY está disponível apenas para a função que está sendo executada, e não para nenhuma outra função do código — neste caso, goodbyeWorld.

Por outro lado, o token secreto de GITHUB_API_KEY está definido diretamente no arquivo de manifesto serverless.yml, que mistura questões de configuração e gerenciamento de segredos. Isso pode expor informações caso o arquivo de manifesto seja publicado publicamente ou compartilhado com outras pessoas.

O exemplo a seguir usa o AWS Simple Systems Manager, projetado para buscar segredos criptografados com segurança pelo AWS Parameter Store. Neste exemplo, a variável SSM é usada para acessar um valor específico criado previamente, disponibilizando-o para uma função por meio de uma variável de ambiente:


service:
 name: hello-world

provider:
  name: aws

functions:
  helloWorld:
    handler: helloworld.get
    environment:
      GITHUB_API_KEY: ${ssm:/github/api-key}

Observe que ${ssm:/github/api-key} retorna o valor criptografado dessa chave. Para descriptografá-lo e retornar o valor real, é necessário especificar ${ssm:/github/api-key~true}.

Confira mais informações sobre o Parameter Store e o Key Management Service (KMS) na documentação do Parameter Store da Amazon.

Para aumentar ainda mais a segurança e a flexibilidade no gerenciamento de segredos das suas aplicações, considere acessar segredos e outras informações de configuração durante a execução, em vez de usar variáveis de ambiente, que exigem a reinicialização do processo para aplicar uma nova configuração.

Faça a rotação de chaves e credenciais regularmente

Usar um armazenamento para seus segredos reduz as chances de uma chave vazar, mas não as elimina completamente. Felizmente, se você armazena os segredos usados pela sua função, ninguém precisa saber qual é o valor da chave — então você pode fazer a rotação regularmente! Assim, se a chave vazar ou for roubada, ela só poderá ser usada por um curto período antes de expirar.

Fazer a rotação de chaves é uma tarefa simples e pode ser automatizada quando você usa um KMS. No entanto, isso pode ser um pouco mais complicado ao integrar com outros sistemas. Se a chave for necessária para acessar um sistema de terceiros, explore a API desse sistema para encontrar uma forma de fazer a rotação automaticamente. Se houver uma opção, crie uma tarefa periódica que gere uma nova chave, atualize o token no KMS e expire ou coloque a chave antiga em uma lista de bloqueio na próxima execução. Assim, apenas duas chaves ficam ativas por vez. Como suas funções têm duração muito curta, elas passam a usar a nova chave rapidamente, permitindo expirar a antiga e iniciar uma nova rotação com frequência — diariamente ou até mesmo a cada hora.

Resumo

Para concluir, recomendamos que você use uma solução segura para armazenar segredos e credenciais confidenciais, com suporte de grandes provedores de nuvem e FaaS. Como alternativa, você pode implementar sua própria solução, como o Vault da HashiCorp. Armazenar chaves em um cofre de segredos reduz os riscos associados a informações confidenciais guardadas em arquivos estáticos de um repositório de código-fonte ou em variáveis de ambiente, além de diminuir consideravelmente as chances de exposição. Para saber mais sobre ferramentas de gerenciamento de segredos e boas práticas, clique aqui.

Crie agora uma conta gratuita na Snyk para aumentar a segurança dos seus projetos.

Comece a jogar Capture the Flag

Aprenda a resolver desafios de Capture the Flag assistindo sob demanda ao nosso workshop virtual introdutório.

Leia mais

blog feature ai lilac
Blog

Transforme seu backlog de vulnerabilidades em pull requests com remediação agentiva

O Evo Remediation Agent está em Open Preview e traz a resolução automatizada de dependências para o Evo Agentic AppSec. Agora, as equipes de AppSec podem executar campanhas contínuas de remediação

AI Background min crop
Blog

A IA está acionando todos os riscos que você aceitou: sete insights do painel de segurança de IA sem filtros

A IA está tornando os ataques mais baratos e rápidos, expondo riscos que as organizações já carregam. Quatro líderes de segurança explicam por que a defesa na velocidade das máquinas e a correção mais rápida são essenciais.

blog feature ai violet
Blog

VulnBump: agentes de IA conseguem corrigir dependências vulneráveis sem quebrar o build?

O VulnBump testa agentes de IA em 307 atualizações reais de dependências. Uma correção só é considerada válida se eliminar a vulnerabilidade e mantiver o build e os testes passando.