Asegurando un entorno cloud que no construiste

Acabas de recibir las llaves de una cuenta de cloud que ha estado creciendo sin atención durante tres años. Nadie dejó documentación. IAM tiene 40 roles con permisos comodín, hay buckets de S3 que nadie recuerda haber creado, y la última persona que entendía la topología de la red se fue de la empresa en 2022. Esto es más común de lo que la mayoría de las ofertas de trabajo admiten, y el primer mes establece el tono para todo lo que viene después.

Obtén un inventario antes de tocar nada

Resiste la urgencia de empezar a asegurar las cosas inmediatamente. Primero necesitas un mapa. Ejecuta aws resourcegroupstaggingapi get-resources en cada región, no solo en us-east-1 — los equipos adoran crear recursos de prueba en ap-southeast-2 y olvidarse de ellos. Combina eso con AWS Config si ya está habilitado, o actívalo ahora si no lo está. En Azure, az resource list --output table enviado a una hoja de cálculo funciona bien para un primer análisis. En GCP, Cloud Asset Inventory con gcloud asset search-all-resources te da la misma vista.

Cruza referencias con facturación. Cualquier cosa que custe dinero debe aparecer en tu inventario de recursos; cualquier cosa en el inventario sin actividad reciente es candidata para archivarse. Las discrepancias aquí son usualmente donde se esconde lo aterrador — instancias de EC2 huérfanas con IPs públicas, snapshots de RDS olvidados sin cifrar, load balancers que apuntan a nada.

Audita IAM como si fuera una escena de crimen

Extrae cada política de IAM y busca "Action": "*" combinado con "Resource": "*". Esa combinación no debería existir fuera de un puñado de roles de admin de emergencia, y aun así esos deberían tener imposición de MFA y alertas de CloudTrail adjuntas. Usa IAM Access Analyzer para encontrar roles que otorgan acceso a cuentas externas — esto detecta tanto relaciones de confianza entre cuentas intencionales como errores de alguien que probaba un módulo de Terraform contra el ID de cuenta equivocado.

Verifica claves de acceso anteriores a 90 días con aws iam generate-credential-report. Los entornos heredados casi siempre tienen claves de larga duración adjuntas a cuentas de servicio, a veces codificadas en una variable de entorno de Lambda o un trabajo de Jenkins. Rótalas, pero hazlo por etapas — matar una clave de la que depende un trabajo batch nocturno a las 2 AM es cómo terminas siendo paginado durante tu primera semana.

Encuentra la exposición pública antes que un atacante

Ejecuta una verificación de accesibilidad de red en tus VPCs. Los grupos de seguridad con 0.0.0.0/0 en cualquier cosa que no sea 80/443 necesitan justificación, no suposición. Herramientas como ScoutSuite o Prowler procesarán una cuenta en minutos y escupirán un reporte clasificado por severidad — comienza ahí en lugar de construir tu propia lista de verificación desde cero.

Los buckets de S3 merecen atención especial porque son la mina terrestre clásica de entornos heredados. Verifica tanto políticas de bucket como configuraciones de Block Public Access a nivel de cuenta; alguien puede haber deshabilitado la configuración por defecto de la cuenta años atrás para un sitio estático único y nunca la volvió a activar. aws s3api list-buckets combinado con un bucle que verifica get-bucket-acl y get-bucket-policy-status en cada uno te da una imagen clara en menos de diez minutos para la mayoría de cuentas.

Establece logging antes de establecer confianza

Si CloudTrail, VPC Flow Logs o GuardDuty no están ya en ejecución en todas partes, actívalos ahora, antes de hacer otros cambios. Quieres un registro de qué sucede de este punto en adelante, y lo quieres antes de empezar a eliminar cosas, porque la eliminación es exactamente cuándo se cometen errores y se culpa a la persona nueva. Envía logs a una cuenta o suscripción separada si es posible en absoluto, así una carga de trabajo comprometida tampoco pueda borrar su propia evidencia.

Configura GuardDuty o Azure Defender for Cloud con alertas enrutadas a algún lugar que un humano realmente verifique — no un canal de Slack con 400 mensajes sin leer. El valor de la herramienta de detección es cercano a cero si las alertas llegan al vacío.

Arregla los problemas más ruidosos primero, documenta todo

No arreglarás un entorno heredado en un sprint. Triaje por radio de impacto: exposición de datos públicos primero, luego identidades con excesivos privilegios, luego segmentación de red, luego todo lo demás. Anota qué encontraste y qué cambiaste, incluso en un Google Doc simple, porque la siguiente persona que herede esto de ti merece algo mejor que lo que tú recibiste.

Espera resistencia cuando ajustes un grupo de seguridad y la prueba de integración de un desarrollador comienza a fallar. Eso es normal — significa que la auditoría está funcionando. Habla con el equipo que posee la carga de trabajo antes de cambiar cualquier cosa en producción, y ten un plan de reversión listo para las primeras dos semanas.

Para más información sobre las herramientas y el razonamiento detrás de auditorías en cloud, revisa los segmentos de Korra Studio sobre hardening de IAM e ingeniería de detección en cloud — ambos combinan bien con el flujo de trabajo anterior.