Pensábamos que la nube nos iba a aportar flexibilidad, además de:
- Servicios de primera categoría.
- Innovación en la nube.
- Sin dependencia de un proveedor concreto.
Pero cuando se produce un incidente cibernético, esa flexibilidad suele convertirse en complejidad. En este episodio de STRIVE, me senté a charlar con Akshay Joshi, director sénior de gestión de productos —cuya trayectoria profesional abarca IBM, AWS, Microsoft, Clumio y, ahora, Commvault— para analizar una verdad incómoda: la mayoría de las empresas creen que están preparadas para la nube. Hasta que se dan cuenta de que no es así. Mira el episodio completo.
Puntos clave: Lo que realmente exige la nube
- Hacer una copia de seguridad a nivel de servicio no es lo mismo que recuperar a nivel de aplicación. Proteger fuentes de datos individuales no es lo mismo que restaurar un ecosistema de aplicaciones sincronizadas.
- La complejidad de la recuperación se multiplica cuando hay varias nubes de por medio. Diferentes puntos de recuperación, diferentes cuentas, diferentes equipos de administración… cada uno de ellos supone un obstáculo cuando el tiempo es lo más importante.
- Las herramientas nativas de los hiperescaladores son necesarias, pero no suficientes. Protegen dentro de su propia nube, pero no coordinan las operaciones entre nubes.
- El aislamiento es la primera ficha de dominó en un incidente cibernético. Cuanto más amplio sea el alcance del entorno, más difícil resulta contener el impacto.
- La resiliencia hay que integrarla desde el principio, no añadirla después. El mapeo de dependencias y la planificación de la recuperación deberían comenzar ya en la fase de diseño de la aplicación, no después de su implementación.
- La automatización basada en IA aporta más potencia… pero también nuevos riesgos. Los flujos de trabajo basados en Agentic requieren controles de permisos estrictos y una gestión rigurosa.
La diferencia entre lo que dice el papel y la realidad
Sobre el papel, la recuperación parece sencilla: ¿Hasta qué punto te recuperas? ¿Qué es lo que recuperas? ¿Dónde lo recuperas? Pero, como explica Akshay, cada una de esas preguntas se complica en un entorno multicloud. Los distintos servicios pueden tener diferentes puntos de Recovery. Algunos microservicios pueden verse afectados, mientras que otros no. Recovery puede requerir un rediseño de la arquitectura si se restaura entre regiones o entre cuentas.
Lo que parece sencillo en la documentación se vuelve tremendamente complejo a la hora de ponerlo en práctica. Y cuando te ataca un ransomware, los equipos no se ponen a consultar tranquilamente los manuales de actuación, sino que se vuelven locos.
La primera ficha de dominó: el aislamiento
Cada vector de amenaza crece proporcionalmente a la complejidad del entorno. La nube no solo diversifica la infraestructura, sino que amplía el alcance operativo.
Copia de seguridad a nivel de servicio frente a recuperación a nivel de aplicación
Aquí es donde la mayoría de las organizaciones se quedan atascadas. Lo respaldan:
- Datos de Azure con Azure Backup
- Datos de AWS con AWS Backup
- Datos de Google Cloud con una herramienta independiente
Por separado, cada servicio puede estar protegido. En conjunto, puede que no sea posible recuperar la aplicación en un estado sincronizado. Las herramientas nativas no se comunican entre distintas nubes. No están diseñadas para entornos en la nube. Tampoco están optimizadas para mejorar el tiempo objetivo de recuperación (RTO) ni el punto objetivo de recuperación (RPO) a gran escala en la nube.
Y cuando la recuperación depende de coordinar varias fuentes de datos entre distintos hiperescaladores, la orquestación marca la diferencia entre horas y días. Precisamente por eso existen las estrategias de recuperación unificadas: no para sustituir a los hiperescaladores, sino para coordinarlos.
El mapeo de dependencias ya no es opcional
Llevamos más de una década hablando del mapeo de dependencias de las aplicaciones. Pero en un mundo multinube, ya no es algo «que estaría bien tener». Las aplicaciones abarcan ahora múltiples hiperescaladores, múltiples equipos de DevOps, múltiples dominios de administración y múltiples herramientas de copia de seguridad de distintos proveedores.
La fragmentación de la responsabilidad ralentiza la Recovery. La fragmentación de los proveedores complica la orquestación. Los silos operativos provocan retrasos en el peor momento posible. La resiliencia debe integrarse desde el principio, no añadirse a posteriori tras la implementación.
Avance: ¿Por qué falla la nube sin un mapa de dependencias?
En este fragmento de la charla de STRIVE, Akshay explica por qué es fundamental poner en práctica la resiliencia ya en la fase de diseño para poder sobrevivir a los ciberataques del mundo real.
Diseñar pensando en la recuperación, no solo en la protección
Uno de los puntos más importantes de este episodio: las aplicaciones modernas no solo deben diseñarse pensando en el rendimiento y la escalabilidad, sino también en la capacidad de recuperación. Eso significa que:
- Estoy pensando tanto en el RTO como en el RPO.
- Diseñar teniendo en cuenta la nube.
- Consolidar la visibilidad siempre que sea posible.
- Reducir la fragmentación de proveedores y las tareas administrativas.
- Comprobación de la recuperación en distintos entornos.
La velocidad de Recovery afecta a los ingresos. La claridad en Recovery afecta a la reputación. El tiempo de inactividad afecta a la confianza de los clientes. La innovación multicloud debe ir acompañada de una disciplina de Recovery multicloud.
La capa de IA y automatización
Ningún debate está completo sin abordar la IA. Los flujos de trabajo basados en agentes están cada vez más integrados en las plataformas SaaS empresariales. Pero la automatización plantea nuevas consideraciones:
- ¿Qué permisos tienen los agentes?
- ¿Con qué frecuencia se activan las copias de seguridad?
- ¿Qué repercusiones económicas tienen las decisiones sobre la automatización?
- ¿Se consideran los agentes como identidades con acceso regulado?
La IA puede potenciar la resiliencia, pero sin medidas de control, también puede aumentar el riesgo. La clave está en delegar de forma controlada.
¿Por qué mantuvimos esta conversación en STRIVE?
STRIVE no consiste en repetir lo que todo el mundo ya sabe. Se trata de abordar las carencias que surgen durante los incidentes cibernéticos del mundo real. La adopción de la multinube no se está ralentizando. Pero, a menos que las estrategias de Recovery evolucionen al mismo ritmo que la arquitectura, la complejidad superará a la preparación.
Por eso es importante este debate. Y por eso hemos invitado a Akshay, alguien que ha trabajado con varios hiperescaladores y conoce tanto su potencial como sus limitaciones.
Mira el episodio completo
En el episodio completo de STRIVE, descubrirás:
- La diferencia real entre la copia de seguridad a nivel de servicio y la recuperación a nivel de aplicación.
- Por qué el aislamiento es la primera ficha de dominó en los ataques de ransomware.
- Cómo la fragmentación de los proveedores complica la orquestación.
- En qué deben ponerse de acuerdo los CISO y los responsables de DevOps.
- Cómo cambia la IA el panorama de la resiliencia.
Míralo ahora. Si utilizas AWS, Azure o Google Cloud, esta conversación es imprescindible.
Preguntas frecuentes
P: ¿Por qué no hay copias de seguridad nativas de los hiperescaladores?
R: Las herramientas nativas protegen los datos dentro de una nube concreta, pero no coordinan la recuperación entre distintas nubes. Requieren una restauración coordinada entre servicios y proveedores.
P: ¿Cuál es la mayor carencia en la nube?
R: La discrepancia entre cómo se realizan las copias de seguridad (servicio por servicio) y cómo debe llevarse a cabo la recuperación (a nivel de toda la aplicación).
P: ¿Qué significa «apertura ambiental»?
R: Se refiere a la variedad de cuentas, nubes, identidades y servicios que hay en un entorno. A medida que se amplía el alcance, el riesgo y la complejidad aumentan proporcionalmente.
P: ¿Por qué es tan importante identificar las dependencias?
R: Las aplicaciones abarcan ahora varias nubes y equipos. Si no se identifican las dependencias de los servicios, la secuencia de recuperación se convierte en una cuestión de conjeturas.
P: ¿Cómo influye la IA en la recuperación ante desastres?
R: Los flujos de trabajo basados en IA pueden ayudar a automatizar las decisiones de copia de seguridad y recuperación, pero requieren controles de acceso estrictos, gestión de costes y supervisión.
P: ¿Por dónde deberían empezar las organizaciones para mejorar su gestión de la nube?
R: Empiece por evaluar:
-
- La alineación de la recuperación a nivel de aplicación.
- Las oportunidades de consolidación de proveedores.
- La coordinación entre equipos.
- La estrategia de aislamiento durante los incidentes.
- Frecuenciacloud.
Chris Mierzwa es director sénior de marketing de cartera en Commvault.
