Según el reporte State of Cloud Security 2024 de Lacework, el 80% de las organizaciones sufrió al menos un incidente de seguridad en nube en los 12 meses previos. La causa más frecuente no fue una vulnerabilidad de día cero ni un ataque sofisticado de estado-nación: fue una mala configuración. Un bucket S3 público, un rol IAM con permisos excesivos, una regla de firewall mal definida en un grupo de seguridad.
Errores que cualquier equipo entrenado en seguridad de nube detectaría en minutos. Pero que un equipo formado en seguridad perimetral tradicional puede no ver, no porque sea incompetente, sino porque está mirando con las herramientas y los modelos mentales equivocados.
La nube no es un datacenter rentado. Esa confusión tiene consecuencias.
El problema no es la tecnología: es el modelo de competencias
Cuando una organización migra a Azure, AWS o GCP, el modelo de responsabilidad compartida redistribuye qué protege el proveedor y qué protege el cliente. El proveedor asegura la infraestructura subyacente. Todo lo que está encima —configuraciones, identidades, datos, accesos, aplicaciones— es responsabilidad del cliente. Siempre.
El problema es que muchos equipos de seguridad siguen operando como si la nube fuera similar a lo que conocen: un perímetro que defender, un firewall que gestionar, una red que monitorear. En la nube, el perímetro se disolvió. La identidad es el nuevo perímetro. Las APIs son la nueva superficie de ataque. Y la velocidad de cambio del entorno — recursos que se crean y destruyen en minutos — hace irrelevantes muchos procesos de revisión manual.
Las competencias que se necesitan son distintas, no superiores. Pero distintas igual hace que el equipo quede expuesto.
¿Qué hacer al respecto?
El primer paso es hacer una evaluación honesta del estado actual. No una encuesta de autodiagnóstico, sino una revisión técnica real: ¿quién en el equipo puede revisar una política IAM de AWS y detectar permisos excesivos? ¿Quién sabe interpretar los hallazgos de un CSPM? ¿Quién ha configurado alertas en CloudTrail o en Microsoft Defender for Cloud alguna vez? Las respuestas a esas preguntas definen el mapa de brecha.
El segundo paso es priorizar por exposición. No todas las competencias son igualmente urgentes. Si el 80% de tus cargas críticas están en Azure, la prioridad es la profundidad en ese entorno, no la cobertura teórica de los tres grandes proveedores. Dispersar el entrenamiento en múltiples plataformas sin dominar ninguna produce equipos con conocimiento superficial en todas y experiencia real en ninguna.
El tercer paso, frecuentemente omitido, es revisar los procesos, no solo las habilidades. Un equipo con las certificaciones correctas pero con procesos de revisión de cambios diseñados para entornos on-premise seguirá siendo lento, manual y reactivo. La seguridad en nube requiere integrar controles en los pipelines de desarrollo, automatizar la detección de configuraciones inseguras y operar con una mentalidad de revisión continua, no periódica.
Si la brecha es significativa y la velocidad de cierre interna es insuficiente frente al ritmo de adopción de nube, la combinación de capacitación interna con apoyo externo especializado suele ser la vía más práctica. No para sustituir al equipo, sino para acelerar la curva mientras se construye la competencia propia.
La pregunta que vale hacerse
¿La velocidad a la que tu organización adopta servicios en la nube es mayor, igual o menor que la velocidad a la que tu equipo de seguridad desarrolla competencias para protegerlos? Si la respuesta honesta es "mayor", ya sabes dónde está el riesgo más urgente.
Acciones inmediatas
- Mapea qué porcentaje de tus cargas críticas ya están en nube. Si no tienes ese dato claro, el primer riesgo no es técnico: es de visibilidad. Haz el inventario antes de cualquier otra acción. Sin él, no puedes priorizar.
- Identifica quién en tu equipo tiene experiencia práctica —no solo certificaciones— en el proveedor de nube que más usas. La diferencia entre haber tomado un curso y haber resuelto un incidente real en ese entorno es enorme. Ese mapa de capacidad real define tu exposición actual.
- Revisa las configuraciones de IAM de tu entorno de nube principal esta semana. Busca roles con permisos de administrador no justificados, cuentas de servicio con accesos excesivos y usuarios sin MFA habilitado. Son los hallazgos más frecuentes y los más aprovechados por atacantes.
- Verifica que tienes logging activo en tus entornos de nube y que alguien lo revisa. CloudTrail en AWS, Audit Logs en GCP, o Activity Log en Azure deben estar habilitados y conectados a algún proceso de revisión o alerta. Tener logs que nadie revisa equivale a no tenerlos.
- Define un plan de desarrollo de competencias en nube para el siguiente trimestre. No hace falta un programa masivo: identifica las dos o tres competencias más críticas según tu exposición y asigna tiempo y recursos concretos. Lo que no tiene fecha y responsable asignado no ocurre.
Si tu organización necesita evaluar las capacidades de su equipo para proteger entornos en la nube o necesita apoyo especializado mientras construye esas competencias internamente, contáctanos en https://tbsek.mx/contacto/.
