SW BBANG P

Se você já precisou revogar acesso de um desenvolvedor que saiu da empresa e descobriu que ele tinha políticas anexadas diretamente ao usuário — espalhadas por dezenas de permissões individuais — você entende exatamente por que IAM Groups existem. Gerenciar permissões usuário a usuário não escala, e o custo disso aparece sempre no pior momento. TL;DR — IAM Groups vs. Políticas Diretas em Usuários Critério Política Direta no Usuário IAM Group Escalabilidade Não escala — cada usuário precisa de atualização individual Escala — uma mudança no grupo afeta todos os membros Auditoria Difícil — permissões fragmentadas por usuário Centralizada — políticas visíveis no grupo Onboarding Manual e propenso a erro Adicionar ao grupo aplica todas as permissões automaticamente Offboarding Requer auditoria ...

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...