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. Escreva a permissão sobre o ARN específico do segredo, não com wildcard sobre todos, para que uma carga comprometida não alcance o cofre inteiro.
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:REGIAO:CONTA:secret:prod/app/db-*"
}A resource policy do próprio segredo adiciona uma camada: dá para negar qualquer leitura que não venha do VPC endpoint esperado, mantendo o acesso ao segredo dentro da rede privada. Todo acesso fica registrado no CloudTrail, o que permite responder quem leu determinado segredo em uma investigação.
{
"Effect": "Deny",
"Principal": "*",
"Action": "secretsmanager:GetSecretValue",
"Resource": "*",
"Condition": {
"StringNotEquals": { "aws:sourceVpce": "vpce-0a1b2c3d" }
}
}- 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 ao ARN do segredo, sem wildcard amplo
- Usar resource policy e VPC endpoint para conter o acesso
- 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.
Detecção de segredos vazados
Migrar segredos uma vez não impede que novos apareçam. A defesa contínua é varrer commits em busca de credenciais antes que elas cheguem ao repositório remoto e falhar o pipeline quando algo escapa. Ferramentas de varredura como o gitleaks rodam localmente em um hook de pré-commit e também no CI, funcionando como duas barreiras.
# Etapa de CI: procura segredos no historico e falha se achar
gitleaks detect --source . --redact --exit-code 1Quando a varredura encontra algo, o segredo já deve ser tratado como comprometido: rotacione o valor, não apenas remova a linha. Reescrever o histórico ajuda a limpar o repositório, mas o valor que já esteve publicado precisa ser trocado de qualquer forma, porque cópias podem ter sido lidas antes da remoção.
Secrets Manager e Parameter Store
Nem todo dado de configuração é um segredo, e usar o serviço certo economiza custo e simplifica o controle. O Parameter Store, do Systems Manager, guarda parâmetros de configuração e, no tipo SecureString, também valores sensíveis criptografados com KMS, sem custo por segredo. O Secrets Manager cobra por segredo, mas entrega rotação gerenciada nativa, integração de rotação com bancos e resource policy própria.
Uma divisão prática: parâmetros de configuração e segredos simples e estáticos podem ficar no Parameter Store; credenciais que exigem rotação automática, em especial de banco, ficam no Secrets Manager. Nos dois casos, o acesso à rede pela rota privada, com VPC endpoint, evita que a busca do segredo trafegue pela internet.
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 ao ARN do segredo, sem wildcard amplo
- Usar resource policy e VPC endpoint para conter o acesso
- Auditar acesso a segredos no CloudTrail
- Varrer commits em busca de segredos no pré-commit e no CI
- Escolher entre Secrets Manager e Parameter Store por necessidade de rotação
- 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
- Restrinja a leitura ao ARN do segredo, evitando wildcard
- Varra commits para barrar segredos antes do push
- 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.
Permissão de leitura com wildcard sobre todos os segredos
Uma carga comprometida alcança o cofre inteiro, não só o que precisa.
Sem varredura de segredos no pipeline
Novas credenciais voltam a vazar em commits sem ninguém barrar.
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
O que é o AWS Secrets Manager e para que serve?
O AWS Secrets Manager é o serviço da AWS para armazenar, criptografar, rotacionar e controlar o acesso a segredos, como senhas de banco, chaves de API e tokens. Ele serve para tirar credenciais de dentro do código e da configuração, onde vazam com facilidade, e transformá-las em ativos gerenciados: criptografados com KMS, acessíveis apenas por quem tem permissão IAM e com cada acesso registrado no CloudTrail. O objetivo é eliminar segredos hardcoded e reduzir o risco de vazamento.
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.
Devo usar Secrets Manager ou Parameter Store?
Depende da necessidade de rotação e do custo. O Parameter Store guarda configuração e, no tipo SecureString, valores sensíveis criptografados com KMS sem cobrar por segredo, o que atende bem segredos simples e estáticos. O Secrets Manager cobra por segredo, mas oferece rotação gerenciada nativa, integração de rotação com bancos e resource policy própria. Um caminho comum é manter configuração e segredos estáticos no Parameter Store e reservar o Secrets Manager para credenciais que precisam de rotação automática.
Como evito que segredos voltem a vazar em commits?
Adicione varredura de segredos ao fluxo de desenvolvimento em dois pontos: um hook de pré-commit que verifica localmente antes de enviar e uma etapa de CI que falha o build se encontrar credenciais. Ferramentas como o gitleaks cobrem os dois. Quando algo é detectado, trate como comprometido e rotacione o valor, porque remover a linha não desfaz o que já pode ter sido lido.
A busca do segredo trafega pela internet?
Por padrão, a chamada ao Secrets Manager sai para o endpoint público do serviço. Criar um VPC endpoint mantém esse tráfego dentro da rede privada da AWS, sem passar pela internet, e permite condicionar o acesso ao segredo à origem daquele endpoint na resource policy. Em cargas que rodam em sub-rede privada, é a forma recomendada de buscar segredos.
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.