Heredaste un Desorden en la Nube. ¿Por Dónde Empiezas?

Acabas de tomar control de una cuenta en la nube (o diez) que alguien más construyó durante tres años sin documentación, con un elenco rotativo de contratistas y un canal de Slack llamado #aws-help que no ha estado activo desde 2022. Esta es una de las situaciones más comunes en el trabajo de seguridad en la nube, e incómoda porque eres responsable de algo que aún no puedes explicar.

Aquí está cómo pasar de cero visibilidad a una posición defendible sin hacerlo de manera desproporcionada.

Deja de adivinar y primero haz un inventario

No puedes asegurar lo que no puedes ver. Antes de tocar una sola política de IAM, ejecuta un pase de inventario:

• AWS: aws organizations list-accounts para ver la estructura completa de cuentas, luego Steampipe o agregadores de AWS Config para extraer recursos entre cuentas en una vista consultable única.
• Azure: Consultas de Resource Graph (az graph query) entre suscripciones, ya que el modelo tenant/suscripción de Azure oculta la expansión fácilmente.
• GCP: gcloud asset search-all-resources a nivel de organización.

Cruza esto con los datos de facturación. La facturación no miente sobre lo que está ejecutándose, incluso cuando los etiquetados y la documentación lo hacen. Si ves gastos en un servicio que nadie mencionó en la incorporación, ese es tu primer hallazgo.

Encuentra quién puede hacer qué antes de encontrar qué está roto

Las configuraciones erróneas acaparan titulares, pero la identidad es donde generalmente vive la exposición real en un entorno heredado. Extrae cada usuario IAM, rol y cuenta de servicio y haz tres preguntas: ¿esto todavía necesita existir, tiene acceso que no usa, y es humano o máquina.

Ejecuta AWS IAM Access Analyzer o herramientas de estilo iam-lint para marcar permisos no utilizados en los últimos 90 días. En la práctica, las cuentas heredadas casi siempre tienen al menos un usuario de IAM con claves de acceso de larga duración que se suponía debían ser