Você Herdou uma Bagunça em Cloud. Por Onde Começar?

Você assumiu uma conta cloud (ou dez) que alguém construiu ao longo de três anos sem documentação, com uma rotatividade de contractors e um canal do Slack chamado #aws-help que não está ativo desde 2022. Essa é uma das situações mais comuns em trabalhos de segurança cloud, e é desconfortável porque você é responsável por algo que ainda não consegue explicar.

Aqui está como sair de zero visibilidade para uma posição defensável sem exagerar.

Pare de adivinhar e primeiro faça um inventário

Você não pode proteger o que não consegue ver. Antes de mexer em uma única política de IAM, execute um passe de inventário:

• AWS: aws organizations list-accounts para ver a estrutura completa de contas, depois Steampipe ou agregadores do AWS Config para extrair recursos entre contas em uma visualização queryável única.
• Azure: Consultas do Resource Graph (az graph query) entre assinaturas, já que o modelo tenant/subscription do Azure esconde sprawl facilmente.
• GCP: gcloud asset search-all-resources no nível da organização.

Cruzar isso com os dados de faturamento. Faturamento não mente sobre o que está rodando, mesmo quando tags e documentação mentem. Se você vê gastos com um serviço que ninguém mencionou na integração, esse é seu primeiro achado.

Encontre quem pode fazer o que antes de encontrar o que está quebrado

Misconfigurações ganham as manchetes, mas identidade é onde a exposição real geralmente fica em um ambiente herdado. Extraia cada usuário de IAM, função e conta de serviço e faça três perguntas: isso ainda precisa existir, tem acesso que não usa, e é humano ou máquina.

Execute AWS IAM Access Analyzer ou ferramentas do estilo iam-lint para marcar permissões não utilizadas nos últimos 90 dias. Na prática, contas herdadas quase sempre têm pelo menos um usuário de IAM com chaves de acesso de longa duração que deveriam ter sido