ESTRATEGIA · SEGURIDAD EN LA NUBE · DECISIONES TI
Hay una frase que escucho seguido cuando hablo con equipos de TI que han migrado servicios a la nube: "el proveedor se encarga de la seguridad." A veces se dice con convicción, como una ventaja del modelo cloud. A veces como una racionalización para no tener que gestionar algo que siempre fue complejo. En ambos casos, la frase es incorrecta, y la incorrección tiene consecuencias concretas que aparecen en forma de configuraciones mal hechas, datos expuestos, y cuentas con privilegios que nadie revisó desde que se crearon en la urgencia de una migración.
Esta semana analizo la seguridad en la nube no como un problema técnico de configuración, sino como lo que es en la mayoría de las organizaciones medianas: un problema de decisiones que se tomaron bajo presión, sin tiempo de planificar, con supuestos incorrectos sobre quién era responsable de qué, y con consecuencias que se fueron acumulando mientras nadie tenía el mandato claro de revisarlas.
LA NUBE QUE LLEGA SIN ESTRATEGIA
Las migraciones cloud más problemáticas desde el punto de vista de seguridad no son las planificadas. Son las que ocurren bajo urgencia: el incidente que obliga a mover sistemas críticos en días, la oportunidad de negocio que requiere escalar rápidamente, la decisión de reducir costos de datacenter que se implementa con un plazo irreal. En esos contextos, la pregunta no es "cómo migramos de forma segura." Es "cómo migramos antes de que la situación empeore."
Bajo esa presión, las decisiones de seguridad se toman de la forma más expedita posible. Los permisos se configuran más amplios de lo necesario para que todo funcione rápido. Las cuentas de acceso se crean sin el rigor que se aplicaría en condiciones normales. Los servicios cloud se habilitan con configuraciones por defecto que nadie revisó. La visibilidad y el monitoreo quedan para después, cuando la urgencia pase.
El problema es que "después" tiene la misma característica que el próximo trimestre del simulacro de continuidad: siempre hay algo más urgente que revisarlo. Las configuraciones de emergencia se vuelven configuraciones permanentes. Los accesos provisorios se vuelven accesos vigentes. Y la deuda técnica de seguridad cloud crece en silencio mientras la organización asume que el proveedor se está encargando de lo que en realidad sigue siendo responsabilidad propia.
EL MODELO DE RESPONSABILIDAD COMPARTIDA EN LA PRÁCTICA
Todos los proveedores cloud, Azure, AWS, GCP, documentan el modelo de responsabilidad compartida. El proveedor es responsable de la seguridad de la infraestructura física: los datacenters, el hardware, la red subyacente, el hypervisor. La organización es responsable de todo lo que corre sobre esa infraestructura: la configuración de los servicios, los permisos de acceso, los datos almacenados, las identidades que tienen acceso al entorno, la red virtual y sus reglas.
Ese modelo existe en papel en todos los contratos. Lo que no existe en muchas organizaciones medianas es la comprensión operacional de qué lado de la línea está cada decisión de seguridad concreta. ¿Quién es responsable de que el bucket de almacenamiento no sea accesible públicamente? ¿La organización. ¿Quién es responsable de que las credenciales de las cuentas de servicio se roten periódicamente? La organización. ¿Quién es responsable de que los logs de actividad estén habilitados y retenidos? La organización. ¿Quién es responsable de que los grupos de seguridad de la red virtual no tengan reglas demasiado permisivas? La organización.
Cada una de esas responsabilidades requiere una decisión activa de configuración. El proveedor no las toma por defecto de forma segura en todos los casos, porque las configuraciones por defecto están optimizadas para la facilidad de adopción, no para la postura de seguridad mínima. Y las configuraciones que se hicieron bajo urgencia en una migración de emergencia raramente tienen en cuenta esas responsabilidades con el criterio necesario.
EL COSTO QUE NADIE CALCULÓ AL INICIO
Las migraciones cloud de urgencia también tienen una característica económica que genera tensión organizacional en el mediano plazo: el costo inicial es más alto de lo sostenible. Cuando la prioridad es recuperar operaciones, se habilitan servicios sin optimizar, se aprovisiona capacidad con margen amplio para no quedarse corto, y nadie tiene tiempo de revisar qué se puede apagar o reducir.
Ese costo inflado, que en el contexto del incidente era justificable, se convierte en el presupuesto de referencia de los meses siguientes. Y cuando la gerencia empieza a revisar los números, lo que ve es un gasto en cloud que es significativamente mayor de lo que esperaba para la escala de la organización. La presión para reducir ese gasto es legítima. El problema es que la reducción de costos cloud y la revisión de seguridad cloud son dos procesos distintos que en muchas organizaciones se confunden o se hacen en el orden incorrecto.
Reducir costos cloud sin revisar la postura de seguridad puede llevar a apagar servicios de monitoreo y logging que eran controles de seguridad, a consolidar cuentas de acceso de forma que se aumentan los privilegios, o a mover servicios de vuelta a on-premise sin validar que la configuración de seguridad del entorno de destino está lista para recibirlos. Y hacer la revisión de seguridad sin tener en cuenta los costos puede llevar a invertir en controles cloud en un entorno que después se va a desmantelar parcialmente.
LO QUE ESTA SEMANA ANALIZO
El martes voy a ver las configuraciones incorrectas más frecuentes en entornos cloud de organizaciones medianas, las que el equipo de TI no siempre detecta porque el proveedor no las reporta como errores. El miércoles, cómo gestionar la identidad y el acceso en un entorno cloud con las mismas fricciones que describí hace dos semanas para el entorno on-premise, más algunas específicas del modelo cloud. El jueves, el caso TechCorp Latam: la nube que llegó por urgencia, las decisiones de seguridad que quedaron pendientes, y lo que pasó cuando el foco se puso en reducir costos antes de revisar la postura de seguridad. El viernes, cómo tener la conversación de seguridad cloud con una gerencia que lo percibe principalmente como un problema de costos.
DECISIÓN QUE DEBE TOMAR EL CIO
¿Sabe la organización exactamente qué servicios cloud están activos hoy, quién tiene acceso a cada uno, y cuáles de esas configuraciones fueron hechas bajo urgencia y nunca revisadas? Si esa respuesta no existe, el primer paso no es un proyecto de seguridad cloud. Es el inventario: qué hay, quién tiene acceso, y qué configuraciones de seguridad se aplicaron cuando se creó cada servicio.
Migrar a la nube no transfiere la responsabilidad de seguridad al proveedor. La redistribuye. Y la parte que queda del lado de la organización es exactamente la que más frecuentemente nadie está gestionando: los permisos, las identidades, las configuraciones, los datos. Todo lo que el proveedor no puede ver porque está del otro lado de la línea.
Esta semana en el blog: cinco días analizando la seguridad cloud como decisión organizacional. Mañana: las configuraciones incorrectas más frecuentes que el proveedor no reporta.
#SeguridadCloud #CloudSecurity #Azure #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #TechCorpLatam #CyberLeadership #Liderazgo #Chile #ZeroTrust #NISTCSF #ISO27001 #ResponsabilidadCompartida
Comentarios
Publicar un comentario