AWS Secrets Manager: boas práticas para armazenar e rotacionar segredos
Credenciais hardcoded são a falha que mais vaza. Veja como centralizar, rotacionar e restringir o acesso a segredos.
Credenciais hardcoded em código, variáveis de ambiente e imagens de container estão entre as falhas mais comuns e mais caras. Elas vazam em repositórios, logs e camadas de imagem, e dão acesso persistente difícil de detectar. O AWS Secrets Manager existe para tirar segredos do código: ele armazena, criptografa e rotaciona credenciais, e controla quem pode acessá-las via IAM.
Este guia mostra como usar o Secrets Manager de forma defensiva: rotação, criptografia com KMS, acesso mínimo e auditoria, além de como migrar de credenciais hardcoded sem quebrar a aplicação. O objetivo é que segredos deixem de ser texto fixo espalhado e passem a ser ativos gerenciados e rastreáveis.
Rotação e criptografia
A rotação é o maior diferencial do Secrets Manager. Configurar rotação automática, especialmente para credenciais de banco, reduz a janela em que um segredo vazado continua válido. A aplicação busca o segredo em runtime em vez de carregá-lo fixo, então a troca acontece de forma transparente. Os segredos são criptografados com KMS, e usar uma chave dedicada adiciona controle sobre quem pode descriptografar.
Evite o anti-padrão de copiar o segredo para uma variável de ambiente fixa no deploy, o que recria o problema que você queria resolver. Busque o valor em runtime e armazene em memória pelo tempo necessário, com cache controlado para não estourar limites de chamada.
Acesso mínimo e auditoria
Restrinja por IAM quem pode ler cada segredo, aplicando menor privilégio: uma aplicação acessa apenas os segredos que ela usa, e nada além. Combine com a resource policy do próprio segredo para controle adicional. Todo acesso é registrado no CloudTrail, o que permite responder quem leu determinado segredo em uma investigação.
- Configurar rotação automática, em especial para bancos
- Buscar o segredo em runtime, não fixar em variável
- Criptografar com chave KMS dedicada quando sensível
- Restringir leitura por IAM e resource policy, com menor privilégio
- Auditar acesso a segredos no CloudTrail
Migrando de credenciais hardcoded
Comece inventariando onde há segredos hardcoded: repositórios, pipelines, arquivos de configuração e imagens. Mova-os para o Secrets Manager, ajuste a aplicação para buscá-los em runtime e, crucialmente, rotacione qualquer segredo que já esteve exposto, porque mover não desfaz um vazamento anterior. Trate segredos versionados no histórico do repositório como comprometidos.
Checklist prático
- Inventariar segredos hardcoded em código, pipelines e imagens
- Mover segredos para o Secrets Manager
- Buscar segredos em runtime, sem fixar em variável de ambiente
- Configurar rotação automática quando aplicável
- Criptografar com chave KMS dedicada para segredos sensíveis
- Restringir leitura por IAM com menor privilégio
- Usar resource policy do segredo para controle adicional
- Auditar acesso a segredos no CloudTrail
- Rotacionar qualquer segredo que já esteve exposto
- Tratar segredos no histórico do repositório como comprometidos
Boas práticas
- Tire segredos do código e do Dockerfile, sem exceção
- Use rotação para encurtar a vida de um segredo vazado
- Busque o valor em runtime, com cache controlado
- Aplique menor privilégio na leitura de cada segredo
- Audite quem acessa segredos sensíveis
- Rotacione após qualquer suspeita de exposição
Erros comuns
Credenciais hardcoded em código ou Dockerfile
Vazam em repositório, logs e camadas de imagem, dando acesso persistente.
Copiar o segredo para variável de ambiente fixa
Recria o problema que o Secrets Manager deveria resolver.
Acesso amplo de leitura a todos os segredos
Uma carga comprometida lê segredos de toda a aplicação.
Não rotacionar após exposição
Mover o segredo não desfaz o vazamento; o valor antigo continua válido.
Sem auditoria de acesso
Impossível saber quem leu um segredo em uma investigação.
Quando procurar apoio especializado
Inventariar segredos espalhados e migrar para gestão centralizada com rotação é parte do serviço de Segurança AWS e Cloud Security da GUARDIASEC, que ajuda a eliminar credenciais hardcoded e a estruturar acesso mínimo a segredos.
Perguntas frequentes
Secrets Manager ou variável de ambiente?
Variável de ambiente fixa recria o risco de segredo estático, que pode vazar em logs e em configuração. O Secrets Manager armazena de forma criptografada, controla acesso por IAM, audita e rotaciona. O ideal é buscar o segredo do Secrets Manager em runtime, mantendo-o em memória pelo tempo necessário, em vez de fixá-lo no ambiente.
A rotação automática quebra a aplicação?
Quando bem configurada, não. A aplicação busca o segredo em runtime, então a troca acontece de forma transparente. Para bancos, a integração de rotação atualiza a credencial de forma coordenada. O cuidado é testar a rotação e garantir que a aplicação relê o segredo, em vez de cachear indefinidamente um valor antigo.
Mover um segredo vazado para o Secrets Manager resolve?
Não por si só. Se o segredo já esteve exposto, por exemplo no histórico de um repositório, ele deve ser considerado comprometido e rotacionado. Mover o valor para um cofre não invalida cópias que já vazaram. A migração precisa vir acompanhada da rotação de qualquer credencial que tenha estado em local inseguro.
Como controlo quem acessa cada segredo?
Use políticas de IAM com menor privilégio para que cada carga acesse apenas os segredos que usa, e combine com a resource policy do próprio segredo para controle adicional. Todo acesso fica registrado no CloudTrail, permitindo auditar quem leu o quê. Acesso amplo a todos os segredos deve ser evitado.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.