SW BBANG P

A pergunta aparece toda semana em revisões de código: 'o repositório é privado, então qual é o problema de deixar a senha do banco no application.properties ?' O problema é que repositório privado não é modelo de segurança — é uma suposição que falha no primeiro acidente de permissão, no primeiro desenvolvedor que sai da empresa, ou no primeiro vazamento de token do GitHub. O AWS Secrets Manager existe exatamente para eliminar essa suposição do design da aplicação. TL;DR — Hardcoding vs. Secrets Manager Critério Hardcoding / Variável de Ambiente AWS Secrets Manager Rotação de senha Manual, requer redeploy Automática via Lambda rotation function Auditoria de acesso Nenhuma CloudTrail registra cada GetSecretValue Superfície de exposição Código-fonte, logs, variáveis de processo Apenas em memória, no momento do uso Controle de acesso Quem tem acesso ao repo tem a senha IAM policy por role, por recurs...

Você tem um endpoint de banco de dados que precisa chegar até a função Lambda — hardcodar isso no código é o caminho mais rápido para um vazamento de credencial em um repositório público. Variáveis de ambiente no Lambda resolvem esse problema, e quando combinadas com KMS, você adiciona uma camada de criptografia que vai além do padrão gerenciado pela AWS. TL;DR — Variáveis de Ambiente no Lambda Ponto Detalhe Onde configurar Console, CLI ( --environment ), IaC (CloudFormation/SAM/Terraform) Criptografia padrão AWS gerencia com chave própria (aws/lambda) — transparente, sem custo adicional de KMS Criptografia customizada Você fornece uma CMK do KMS; Lambda criptografa em repouso e você descriptografa em runtime Acesso no código process.env.NOME (Node.js), os.environ['NOME'] (Python) Limite de tamanho 4 KB total para todas as variáveis — verifique a documentação oficial para limites atuais ...