El problema de seguridad cloud más extendido en las empresas no es que les falten herramientas. Es que construyen la infraestructura primero y la aseguran después. Lo dice Nodir Safarov, Cloud Architect Expert de SOTI Inc. —una empresa que gestiona entornos cloud para miles de clientes en Norteamérica, Europa y Asia— en un artículo publicado esta semana en The Next Web. Safarov repite el mismo diagnóstico en empresa tras empresa: la seguridad se trata como una capa que se añade al final, y eso crea vulnerabilidades que son caras de remediar y fáciles de pasar por alto.
El dato de contexto importa: según informes de la industria revisados en 2026, cuatro de cada cinco empresas han sufrido al menos una brecha de seguridad en sus entornos cloud. El 89% opera ya en entornos multi-cloud. Y el 69% de los profesionales de TI declaran dificultades con la visibilidad de sus propios sistemas. Esos números no hablan de falta de inversión: el gasto en servicios cloud crecerá a un ritmo anual del 19,4% entre 2026 y 2028. Hablan de que se invierte en plataforma antes de haber resuelto la arquitectura de seguridad.
Error 1: Construir la infraestructura antes de diseñar la seguridad
Es el fallo que hace posibles todos los demás. En demasiadas organizaciones, el equipo de infraestructura despliega los entornos de nube —AWS, Azure, entornos multi-cloud— y el equipo de seguridad llega después a evaluar lo que ya está en producción. Para entonces, la arquitectura tiene suposiciones incorrectas horneadas: permisos demasiado amplios porque eran más fáciles de configurar rápido, datos sin cifrar porque «se haría luego», configuraciones de red abiertas que «eran temporales».
El coste de corregir seguridad en producción es desproporcionadamente mayor que el de diseñarla desde el principio. Cada modificación sobre un sistema en activo introduce riesgo de instabilidad. El incentivo para no tocar nada que funcione es fuerte, y así el «temporal» dura años.
Safarov cita un caso real: en una empresa que auditó, una regla de acceso abierto creada durante el despliegue inicial llevaba meses activa, exponiendo APIs internas a internet. Todos los monitores de seguridad mostraban verde. El problema era invisible para las herramientas de observabilidad convencionales porque la configuración estaba dentro de los parámetros esperados.
Error 2: Fallos de aislamiento en entornos multi-tenant
Los entornos multi-tenant son la norma en cloud empresarial: varias unidades de negocio, proyectos o clientes comparten la misma infraestructura con separación lógica. El problema aparece cuando esa separación no se diseña con criterios de seguridad sino de comodidad operativa.
En la práctica, esto significa que una vulnerabilidad en un tenant puede afectar a otros que comparten recursos. Las APIs compartidas sin autenticación suficiente, las redes que no están correctamente segmentadas, los sistemas de logging comunes que mezclan datos de clientes diferentes: todos son consecuencias de no haber planteado el modelo de amenazas multi-tenant antes de desplegar.
La segmentación correcta no es compleja técnicamente, pero requiere tomarla en serio como decisión de diseño. Una vez que la infraestructura está desplegada sin segmentación adecuada, añadirla sin interrumpir el servicio es una operación quirúrgica de alto riesgo.
Error 3: Configuración que deriva con el tiempo
Los entornos cloud no son estáticos. Se actualizan, se amplían, se modifican para adaptar nuevas necesidades. Cada cambio es una oportunidad para introducir una configuración incorrecta que nadie detecta hasta que hay una brecha.
El configuration drift —la divergencia entre la configuración de seguridad documentada y la que realmente existe en producción— es uno de los problemas más comunes y menos monitorizados. Las herramientas de seguridad estándar detectan amenazas conocidas, pero no siempre captan una configuración que ha evolucionado fuera de las políticas establecidas. La solución es la infraestructura como código: tratar la configuración con los mismos controles de versión, revisión y auditoría que el software.
Error 4: Monitorización incompleta que solo ve lo que espera ver
El problema de los sistemas de monitorización cloud no es su cobertura técnica, sino su orientación. Detectan lo que se les ha enseñado a detectar. No pueden alertar sobre vectores de ataque que no han sido incluidos en sus modelos de amenaza. Como resume Safarov: si tu monitorización solo te dice lo que ya sabías que podía pasar, no te protege contra lo que no anticipaste.
En entornos multi-cloud especialmente, la visibilidad se fragmenta: herramientas diferentes para AWS y Azure, logs en formatos distintos, correlaciones que nadie ha automatizado. El 69% de los profesionales que reportan dificultades con la visibilidad de sus sistemas están describiendo exactamente este problema. Saben que tienen puntos ciegos; no siempre saben dónde están.
Error 5: Seguridad que depende de decisiones individuales, no de patrones estandarizados
El quinto error es estructural. Cuando la seguridad de un sistema depende del criterio de quien lo configuró ese día, la empresa tiene un problema de escala. Los patrones se repiten con errores. Las mejoras alcanzadas en un equipo no se transfieren al siguiente. Las auditorías encuentran inconsistencias que no tienen origen técnico sino de proceso.
La solución que Safarov recomienda es la estandarización a través de código y automatización: plantillas de seguridad reutilizables, infraestructura como código con controles integrados, procesos de revisión que apliquen los mismos criterios independientemente de quién implemente el cambio. «Los patrones se repiten en organizaciones de todos los tamaños», dice Safarov. «Estos son problemas sistémicos y requieren soluciones arquitectónicas. No se pueden parchar después del hecho.»
Después de revisar incidentes de seguridad cloud durante los últimos años, el patrón que Safarov describe es exactamente el que aparece en el análisis post-mortem de las brechas más costosas: no falló la tecnología, sino el proceso que la rodea.
Mi valoración
Lo que más me convence es el foco en las decisiones de diseño antes del despliegue. La industria de ciberseguridad tiene un sesgo fuerte hacia la detección y respuesta —SIEM, EDR, SOC— y relativamente poco foco en prevención arquitectónica. Las cinco áreas que señala Safarov son todas problemas de diseño, no de herramientas. Y los problemas de diseño son más baratos de prevenir que de corregir.
Lo que más me preocupa es la velocidad de adopción cloud versus la madurez de las prácticas de seguridad en las empresas que migran. El gasto en cloud crece al 19,4% anual, pero las capacidades de seguridad arquitectónica no crecen al mismo ritmo. La brecha entre infraestructura desplegada y seguridad bien diseñada se amplía con cada migración acelerada.
Lo más estructuralmente significativo es que estos cinco errores no son nuevos. Se conocen desde los primeros años de la nube empresarial. Que Safarov los siga viendo en todas las empresas que audita en 2026 dice algo preocupante: el problema no es falta de conocimiento disponible, sino falta de prioridad real por parte de la dirección en hacer la seguridad parte del diseño desde el día uno.
Mi predicción: en 2027, la adopción de IA en la gestión de infraestructura cloud —agentes que detectan configuration drift y proponen correcciones automáticas— reducirá el error 3 significativamente en las empresas que adopten estas herramientas. Los otros cuatro errores seguirán siendo problemas de cultura organizacional más que de tecnología.
Preguntas frecuentes
¿Qué herramientas concretas ayudan a detectar el configuration drift en entornos cloud?
Las principales opciones para AWS incluyen AWS Config y AWS Security Hub. Para Azure, Microsoft Defender for Cloud tiene funciones de gestión de postura de seguridad. Para entornos multi-cloud, herramientas como Wiz, Orca Security y Prisma Cloud de Palo Alto ofrecen visibilidad centralizada. Lo más importante, independientemente de la herramienta, es definir una línea base de configuración segura antes de desplegar y automatizar la comparación periódica contra esa base.
¿Por qué es más difícil remediar los problemas de seguridad en producción que prevenirlos en diseño?
Porque cualquier cambio en un sistema en producción introduce riesgo de interrupción del servicio. Modificar una regla de acceso puede dejar sin servicio a aplicaciones que dependen de ella. Añadir cifrado a datos ya almacenados requiere migración. Segmentar una red que no fue segmentada puede cortar flujos de comunicación necesarios entre servicios. Cada operación de remediación es, en sí misma, un evento de cambio con sus propios riesgos. Diseñar bien desde el inicio es técnicamente más simple, aunque requiere disciplina de proceso.
¿La seguridad como código realmente funciona para equipos pequeños o es solo para grandes empresas?
Funciona para cualquier tamaño, pero el esfuerzo inicial de crear plantillas reutilizables es mayor que para equipos grandes que tienen más recursos para hacerlo. La buena noticia es que existen frameworks de infraestructura como código open source —Terraform, Pulumi, AWS CDK— con módulos de seguridad preconfigurados que pueden servir como punto de partida. El coste de adopción se ha reducido significativamente en los últimos tres años.
☞ El artículo completo original de Natalia Polo lo puedes ver
aquí
