La recuperación ante desastres en la nube empieza por la empresa
El hecho de que una copia de seguridad se haya realizado correctamente no garantiza que una empresa pueda recuperarse. Premnath Anand analiza cómo los objetivos de recuperación, las copias de seguridad limpias y las pruebas periódicas contribuyen a la recuperación ante desastres en la nube.
Cuando una interrupción grave paraliza las operaciones, los responsables de las empresas quieren saber cuándo se restablecerán los servicios críticos, cuántos datos se han perdido y si es seguro reanudar el trabajo. Premnath Anand, de Getronics, explica por qué la recuperación ante desastres en la nube debe partir de esas prioridades empresariales y por qué no basta con una copia de seguridad satisfactoria por sí sola.
Una tarea de copia de seguridad realizada con éxito constituye una prueba útil. No es una garantía de que las aplicaciones, las identidades, los datos y los procesos empresariales puedan recuperarse en su conjunto.
La verdadera prueba consiste en determinar si la organización es capaz de restablecer un servicio operativo en el plazo acordado, con un nivel aceptable de pérdida de datos y una responsabilidad clara en cada decisión.
Las copias de seguridad y la recuperación ante desastres resuelven problemas distintos
Las copias de seguridad conservan copias de los datos que pueden restaurarse tras un borrado, un daño o un ataque. Son una parte esencial de la recuperación, pero no definen por sí solas todo el proceso de recuperación.
La recuperación ante desastres aúna la tecnología, el personal y los procedimientos necesarios para restablecer los servicios informáticos tras una interrupción. Dependiendo del servicio y del incidente, esto puede implicar restaurar copias de seguridad, reconstruir sistemas o pasar a un entorno alternativo.
La continuidad del negocio abarca un ámbito aún más amplio. Tiene en cuenta cómo la organización sigue funcionando cuando los servicios no están disponibles, incluyendo al personal, a los proveedores, las comunicaciones y las formas de trabajo temporales.
Por lo tanto, un plan de recuperación debe ir más allá de la simple pregunta: «¿Tenemos una copia?».
Es necesario determinar qué servicios tienen prioridad, de qué dependen, quién puede autorizar su recuperación y cómo confirmará la empresa que están listos para su uso.
Define los conceptos de RTO y RPO antes de elegir la tecnología
Hay dos medidas que ayudan a traducir las prioridades empresariales en requisitos para la recuperación:
Medida | Qué significa esto para la empresa |
|---|---|
Objetivo de tiempo de recuperación — RTO | El margen de pérdida de datos aceptable, expresado en tiempo. Esto ayuda a determinar con qué frecuencia deben protegerse los datos. |
Tiempo real de recuperación | Cuánto tiempo lleva la recuperación tras una prueba o un incidente, incluidas las dependencias y las comprobaciones necesarias para que el servicio vuelva a estar operativo. |
Pérdida real de datos | La diferencia entre los datos necesarios y los datos recuperados que se pueden utilizar. Esto puede superar el RPO si los puntos de recuperación recientes se ven comprometidos o no están disponibles. |
Se trata de decisiones empresariales respaldadas por una evaluación técnica. Una plataforma financiera, una aplicación orientada al cliente y un archivo interno no tienen por qué requerir automáticamente el mismo modelo de recuperación.
Las definiciones del NIST sobre el RTO y el RPO constituyen un punto de partida útil. El siguiente paso consiste en ponerse de acuerdo sobre lo que significan esos objetivos para cada servicio crítico.
Los objetivos también deben estar respaldados por pruebas. Un tiempo de recuperación (RTO) establecido por escrito en un plan no es lo mismo que un tiempo de recuperación demostrado en un simulacro realista.
El ransomware dificulta la elección del punto de recuperación
La copia de seguridad más reciente no siempre es la más segura para realizar una restauración.
Es posible que un atacante haya comprometido un entorno antes de que el incidente se hiciera evidente. Por lo tanto, los puntos de recuperación recientes pueden contener software malicioso, datos dañados o cambios de configuración no deseados.
Eso no modifica la definición de RPO. Lo que cambia es si la organización puede cumplir su objetivo utilizando un punto de recuperación en el que pueda confiar.
Los equipos de recuperación deben investigar la cronología del incidente, identificar un punto de recuperación adecuado y validar los sistemas restaurados en un entorno controlado antes de volver a conectarlos al entorno de producción.
Las directrices de Microsoft para la recuperación tras un ataque de ransomware recomiendan identificar el último punto de recuperación sin infectar, restaurar los datos en una red aislada y comprobar que los datos restaurados no estén infectados.
La detección de anomalías en las copias de seguridad puede ayudar a identificar cambios inusuales. Debe servir de apoyo para la investigación y la validación, en lugar de considerarse una prueba de que un punto de recuperación está en buen estado.
«La resiliencia no tiene que ver con lo que resulte más fácil para el departamento de TI. Tiene que ver con lo que permite que la empresa siga funcionando cuando las cosas van mal».Premnath Anand
La nube ofrece opciones, no resiliencia automática
Los servicios en la nube ofrecen diferentes formas de equilibrar la velocidad de recuperación, los costes operativos y los requisitos de las aplicaciones.
Algunas cargas de trabajo pueden restaurarse a partir de copias de seguridad. Otras requieren un entorno de recuperación preparado o sistemas replicados para cumplir con objetivos de recuperación más estrictos.
El enfoque adecuado depende del impacto que el tiempo de inactividad y la pérdida de datos tienen en el negocio, así como de las dependencias de la aplicación.
La nube no elimina los costes de recuperación. Es necesario tener en cuenta el almacenamiento, la replicación, las redes, las licencias, la capacidad de reserva y las pruebas. Las opciones de recuperación más rápidas suelen requerir una mayor inversión y una mayor preparación operativa.
Las directrices de AWS sobre la recuperación ante desastres en la nube explican por qué las estrategias de recuperación deben reevaluarse teniendo en cuenta el impacto en el negocio, el riesgo y el coste.
Esta misma disciplina se aplica a los entornos híbridos y multinube. El mero hecho de utilizar más de una plataforma no garantiza, por sí solo, una ruta de recuperación operativa. Aún es necesario diseñar y probar la identidad, la conectividad, la compatibilidad de las aplicaciones y la responsabilidad operativa.
El objetivo es adaptar la protección al nivel de importancia de cada actividad empresarial, sin tener que asumir los costes de un modelo de recuperación innecesariamente exigente para todas las cargas de trabajo.
Incluir los servicios de IA en el plan de recuperación
A medida que las organizaciones incorporan la inteligencia artificial a sus entornos de producción, los planes de recuperación deben tener en cuenta algo más que las aplicaciones convencionales y el almacenamiento de archivos.
Un servicio basado en la inteligencia artificial puede depender de:
- Versiones del modelo y artefactos de ajuste fino.
- Documentos originales, conjuntos de datos y sus permisos.
- Bases de datos vectoriales e índices de búsqueda.
- Configuración de la aplicación, mensajes de aviso y definiciones de flujos de trabajo.
- Servicios de identidad, credenciales y proveedores de modelos externos.
Es necesario realizar una copia de seguridad de algunos activos. Otros pueden reconstruirse a partir del material de origen protegido, siempre que el tiempo de reconstrucción cumpla los requisitos de recuperación del servicio.
En el caso de los modelos alojados externamente, la organización también debe conocer cuáles son las responsabilidades del proveedor y qué ocurre si dicho servicio deja de estar disponible.
La cuestión práctica es sencilla: ¿qué hay que restaurar, reconstruir o volver a conectar para que la empresa pueda volver a utilizar el servicio de IA?
Tres pilares para una recuperación más segura
Protege las copias de recuperación
Utiliza copias inmutables o fuera de línea debidamente configuradas, controles de acceso independientes y protección frente a acciones administrativas destructivas. Comprueba los ajustes de retención y bloqueo, en lugar de dar por sentado que un producto de copia de seguridad hace que todas las copias sean intocables.
Prepara un entorno de recuperación limpio
Proporcionar un entorno controlado para restaurar e inspeccionar los sistemas antes de volver a ponerlos en producción. Definir la documentación necesaria para que los responsables de seguridad y de las aplicaciones aprueben la reconexión.
Plan de identidad y acceso
Documenta cómo accederán los equipos de recuperación a los sistemas que necesiten en caso de que los servicios de identidad habituales no estén disponibles o se vean comprometidos. Incluye en la secuencia de recuperación los servicios de directorio, las identidades en la nube, el acceso privilegiado y los procedimientos de acceso de emergencia.
Estos controles funcionan de forma conjunta. Los datos protegidos tienen un valor limitado si nadie puede acceder a las herramientas de recuperación o si las aplicaciones restauradas se vuelven a conectar inmediatamente a un entorno que sigue estando comprometido.
Prueba el servicio empresarial, no solo la tarea de restauración
Las medidas de recuperación deben adaptarse a medida que cambian las aplicaciones, las integraciones, las identidades y las prioridades empresariales.
Un ejercicio útil debería demostrar que el servicio funciona, en lugar de limitarse a confirmar que el servidor se inicia.
Esto implica comprobar las dependencias de las aplicaciones, el acceso, la coherencia de los datos, los controles de seguridad y la capacidad del equipo comercial para llevar a cabo las tareas esenciales.
La automatización puede facilitar las comprobaciones repetitivas. Sin embargo, no elimina la necesidad de realizar ejercicios coordinados ni de obtener la aceptación de la empresa.
Registra lo que ha ocurrido, compara los resultados con los RTO y RPO acordados y asigna responsables a las posibles deficiencias. Repite las pruebas pertinentes tras cualquier cambio significativo.
Antes de que se produzca el próximo incidente, los responsables deberían poder responder a lo siguiente:
- ¿Qué servicios empresariales deben recuperarse primero?
- ¿Qué tiempo de inactividad y qué pérdida de datos han aceptado sus propietarios?
- ¿Cuándo se observó por última vez una recuperación representativa?
- ¿Cómo seleccionaremos y validaremos un punto de recuperación válido?
- ¿Puede el equipo de recuperación seguir trabajando si los servicios de identidad habituales no están disponibles?
- ¿Quién autoriza la conmutación por error, la reconexión y el restablecimiento del funcionamiento normal?
Un plan de recuperación resulta creíble cuando esas respuestas están respaldadas por pruebas.
Cómo ayuda Getronics
Los servicios de gestión de la continuidad de los servicios de TI de Getronics respaldan la planificación de la recuperación mediante el análisis de los sistemas, la evaluación de riesgos, la definición de los objetivos de tiempo de recuperación (RTO) y de punto de recuperación (RPO), la estrategia de recuperación ante desastres y las pruebas gestionadas.
Nuestros servicios de nube e infraestructura conectan esa planificación con las operaciones en la nube privada, pública e híbrida, incluyendo opciones de copia de seguridad, replicación y recuperación ante desastres.
El punto de partida es comprender qué necesita la empresa para recuperarse y, a continuación, diseñar y probar un plan de recuperación basado en esos requisitos.
¿Tu plan de recuperación cumple con los requisitos de tu empresa?
Comenta con Getronics cuáles son tus servicios críticos, tus objetivos de recuperación y las carencias en las pruebas.
Sobre el autor
Premnath Anand
Director de Operaciones de la Nube Pública
Premnath Anand es director de Operaciones de Nube Pública en Getronics, donde dirige la estrategia global de nube, la implementación y el crecimiento en entornos públicos, privados e híbridos. Con experiencia en la creación de servicios de nube para empresas y en la dirección de equipos internacionales, colabora con los responsables empresariales en la transformación hacia la nube, las FinOps y la gobernanza operativa, traduciendo requisitos tecnológicos complejos en servicios fiables, una responsabilidad más clara y un valor empresarial cuantificable.
www.linkedin.com/in/premnathanand/
