Secrets Manager e Parameter Store

Um antipadrão comum e perigoso é armazenar segredos (senhas de banco de dados, chaves de API, tokens OAuth) no código-fonte da aplicação, em variáveis de ambiente ou em arquivos de configuração adicionados ao controle de versão. Quando esses repositórios são expostos — acidentalmente tornados públicos ou acessados por um invasor — todos os segredos são comprometidos imediatamente. A AWS oferece dois serviços gerenciados para eliminar esse problema: o AWS Secrets Manager, para credenciais que precisam de rotação automática, e o AWS Systems Manager Parameter Store, para valores de configuração e segredos sem rotação.

O AWS Secrets Manager é um serviço gerenciado para armazenar, recuperar e fazer a rotação automática de segredos. Ele criptografa todos os segredos com KMS (por padrão, usando uma chave gerenciada pela AWS ou sua CMK). Os segredos podem armazenar qualquer dado estruturado como uma cadeia JSON de chave-valor. O Secrets Manager cobra US$ 0,40 por segredo por mês, mais US$ 0,05 a cada 10.000 chamadas de API. Principal diferença em relação ao Parameter Store: rotação automática integrada para RDS, Redshift, DocumentDB e segredos personalizados por meio de funções de rotação do Lambda — sem necessidade de alterações na aplicação durante a rotação.

A rotação automática é o recurso mais poderoso do Secrets Manager. Para bancos de dados RDS, o Secrets Manager faz a rotação nativa das senhas: 1) gera uma nova senha; 2) atualiza a senha do usuário do banco de dados no RDS; 3) atualiza o segredo com a nova senha; 4) verifica se as novas credenciais funcionam. Tudo isso acontece enquanto sua aplicação está em execução — sem tempo de inatividade e sem intervenção manual. As aplicações sempre chamam get-secret-value para recuperar a senha atual, portanto usam automaticamente as credenciais alternadas.

Chamar o Secrets Manager em cada consulta ao banco de dados seria caro e lento. A prática recomendada é armazenar o segredo localmente em cache na memória por um curto período. A AWS fornece clientes oficiais de armazenamento em cache do Secrets Manager para Java e Python, que armazenam os segredos em cache por um TTL configurável. Quando o cache expira, o cliente busca novamente o segredo no Secrets Manager. Se uma aplicação receber um erro de autenticação (indicando que a senha foi alternada), ela atualiza imediatamente o cache e tenta novamente. Esse padrão oferece desempenho e atualidade sem sobrecarregar a API do Secrets Manager.

O AWS Systems Manager (SSM) Parameter Store é um armazenamento hierárquico gratuito (para parâmetros padrão) de pares chave-valor para dados de configuração e segredos. Ele oferece suporte aos tipos de parâmetro String, StringList e SecureString. SecureString criptografa os valores usando KMS. Ao contrário do Secrets Manager, o Parameter Store NÃO oferece suporte à rotação automática — ele foi projetado para valores de configuração que mudam com pouca frequência. Os parâmetros padrão são gratuitos e podem armazenar até 4 KB. Os parâmetros avançados aceitam valores maiores (até 8 KB), políticas de parâmetros (lembretes de expiração e rotação) e custam US$ 0,05 por parâmetro ao mês.

Organize os valores do Parameter Store usando uma estrutura hierárquica de caminhos que reflita seu ambiente e a arquitetura da aplicação. Isso permite criar políticas de IAM com permissões detalhadas, concedendo acesso aos parâmetros por prefixo de caminho. Por exemplo, conceda a uma função Lambda acesso somente aos parâmetros em /prod/payment-service/ — ela não poderá acessar os parâmetros de outros serviços. Esse princípio do menor privilégio para configurações impede que um serviço comprometido leia os segredos de outro serviço.

Escolha entre os dois serviços com base nos seus requisitos: use o Secrets Manager quando precisar de rotação automática de segredos, estiver armazenando credenciais de banco de dados, o segredo precisar ser compartilhado entre várias contas AWS ou a conformidade exigir políticas de rotação documentadas. Use o Parameter Store quando precisar de valores de configuração (não secretos), quiser uma solução gratuita para armazenamento simples de pares chave-valor, precisar de configuração hierárquica com controle de acesso baseado em caminhos ou precisar armazenar o histórico de versões dos parâmetros. Muitas arquiteturas usam os dois em conjunto: Parameter Store para configurações e Secrets Manager para credenciais.

As funções Lambda e as tarefas do ECS devem recuperar os segredos na inicialização, e não em cada invocação. Para Lambda: recupere os segredos no código de inicialização (fora da função manipuladora) e armazene-os em variáveis globais — o ambiente de execução do Lambda persiste entre as invocações, portanto os segredos são buscados apenas uma vez durante o tempo de vida de cada ambiente. Para ECS: use o campo secrets na definição da tarefa para injetar valores do Secrets Manager ou SecureStrings do Parameter Store como variáveis de ambiente — o ECS os recupera e injeta na inicialização da tarefa, sem nenhuma alteração no código da aplicação.

Um uso prático, mas frequentemente ignorado, do Parameter Store é armazenar IDs de AMI e outras referências de implantação. Em vez de codificar IDs de AMI diretamente nos modelos do CloudFormation (que ficam desatualizados quando novas AMIs são lançadas), faça referência a um valor do Parameter Store. Seu pipeline de CI/CD atualiza o ID da AMI no Parameter Store sempre que uma nova AMI dourada é criada. O CloudFormation lê o ID mais recente da AMI no Parameter Store no momento da implantação. A AWS também publica os IDs das AMIs mais recentes do Amazon Linux em caminhos públicos do Parameter Store, aos quais você pode fazer referência diretamente.

A governança de segredos exige saber quem acessou os segredos e quando. O AWS CloudTrail registra cada chamada de API ao Secrets Manager e ao Parameter Store: GetSecretValue, PutParameter, GetParameter. Isso fornece uma trilha de auditoria completa para fins de conformidade. Use alarmes do CloudWatch com métricas do CloudTrail para alertar quando os segredos forem acessados fora dos padrões normais — por exemplo, se um segredo de produção for acessado por um Principal do IAM incomum ou por um IP que não esteja no seu intervalo conhecido, dispare um alerta para investigação.

Em arquiteturas com várias contas, às vezes as aplicações de uma conta precisam de segredos gerenciados em outra conta (por exemplo, uma conta central de Security gerencia todas as senhas do RDS). As políticas de recursos do Secrets Manager permitem o acesso entre contas. Configure uma política baseada em recursos no segredo que conceda a uma função da conta consumidora permissão para chamar GetSecretValue. A função da conta consumidora também deve ter uma política do IAM que permita chamadas ao ARN do segredo. As políticas de chaves do KMS também devem conceder à conta consumidora acesso à CMK usada para criptografar o segredo.

Nesta lição, você aprendeu que: o Secrets Manager oferece rotação automática para credenciais de banco de dados e chaves de API e é a opção preferencial para segredos que precisam ser alternados; o Parameter Store oferece armazenamento hierárquico gratuito de configurações, com controle de acesso do IAM baseado em caminhos; e o ECS e o Lambda podem injetar segredos como variáveis de ambiente sem alterações no código da aplicação. O CloudTrail fornece trilhas de auditoria para todos os acessos a segredos. A seguir, exploraremos WAF, Shield e Network Firewall.