Plan de Recuperación ante Desastres: ¿Qué tener en cuenta?

 
¿Está tu organización preparada para sobrevivir a un desastre que afecte a la disponibilidad y acceso a la información crítica?
Las características de las infraestructuras IT actuales han hecho que la recuperación de la información tras un determinado incidente o desastre se haya vuelto cada vez más compleja.
Sin embargo, el mayor riesgo está en el hecho de que la pérdida de la información suele implicar una interrupción del servicio, cuyas consecuencias pueden ser devastadoras para el negocio afectado.
Mi intención con este post es que tengas claro los factores que intervienen a la hora de llevar a cabo un plan de recuperación de información. De esta forma podrás controlar qué aspectos están o no controlados en tu organización, y qué hacer para estar preparados ante un posible desastre que tenga consecuencias impredecibles.
Para tomar conciencia de la importancia del diseño y puesta a prueba de este proyecto, te recomiendo conocer el caso de éxito de Santillana, donde valoraron enormemente la aportación, trabajo y mejora de estos procesos por parte de nuestra organización.

10 Fases para desarrollar un DRP (Plan de Recuperación de Desastres)

#1 Realiza un inventario

Uno de los mejores puntos de partida para elaborar el diseño de un Plan de Recuperación ante Desastres (DRP por sus siglas en inglés), es la realización de un inventario completo de todos los activos digitales de la organización. De esa manera, serás capaz de valorar adecuadamente la complejidad y los riesgos presentes en el entorno IT.
En primer lugar, necesitas identificar los sitios físicos en los que los servicios de IT operan, así como los sistemas de información que posee cada instalación.
Enumera un listado completo de todos los servidores, dispositivos de almacenamiento, aplicaciones, conmutadores y dispositivos de red, puntos de acceso, datos, etc.
Es muy útil, además, crear un plano en el que se pueda ver la ubicación física de cada uno de estos activos, así como la red en la que se encuentran.

#2 Evalúa los riesgos

Una vez tengas una visión global de los activos digitales de la organización y su ubicación concreta, es conveniente determinar todas las amenazas internas o externas que pueden afectarlos.
Ten en cuenta que las causas que pueden generar un problema de acceso y conservación de la información son muy variadas y no sólo se reducen a los desastres naturales.
De acuerdo con una encuesta llevada a cabo por la consultora Forrester en  el año 2013, el 43% de las empresas sufren un desastre debido a un fallo en la fuente de alimentación. En el 31% las empresas encuestadas un error en el hardware de IT es también una de las principales  causas.
El aspecto más delicado de este proceso es el cálculo de la probabilidad de que dichos sucesos tengan lugar y el impacto que éstos tendrían sobre el negocio.
Para ello, te ayudará contar con el apoyo de los principales responsables de cada departamento, pues son ellos quienes pueden evaluar el daño que sufrirían ante una eventual pérdida de información o inutilización de una determinada aplicación.

#3 Determina la criticidad de las aplicaciones y los datos

También es necesario clasificar los sistemas de información según cómo de críticos resulten para la continuidad de la actividad de la empresa.
Por supuesto, no se trata de aplicar una técnica o criterio distinto a cada una de las aplicaciones y bases de datos. Mi consejo es que las agrupes en función de su importancia, la frecuencia con la que cambian y las políticas corporativas de retención de la información. De nuevo, la opinión de los responsables departamentales será fundamental.
 

#4 Define los objetivos de recuperación

Porque cada organización y ámbito implicará unos objetivos distintos. Un sistema heredado suele albergar contenido menos cambiante y, por lo tanto, los objetivos de recuperación pueden ser menos exigentes. Sin embargo, la base de datos de una entidad bancaria no puede permitirse permanecer inoperativa ni un minuto.
Para poder definir los objetivos de recuperación óptimos, será necesario que cada departamento de respuesta a una serie de preguntas, tales como:
¿Qué aplicaciones y bases de datos utilizan y con qué frecuencia?
¿Cuánto tiempo pueden permanecer operativos sin tener acceso a dichos sistemas?
¿Qué implicaciones tendría la pérdida definitiva de esos datos?
¿Existe algún tipo de requerimiento que impida que determinadas bases de datos sean realojadas en una ubicación geográfica distinta a la actual?
¿Existe algún tipo de requerimiento referente a los niveles de seguridad y cifrado de datos?
 
 Determinación del RTO (Recovery Time Objective)
Una de las maneras más prácticas de determinar el RTO es tener en cuenta la pérdida de ingresos que tu empresa sufriría en función de un lapso de tiempo específico. Cada organización debe escoger su propia escala dado que, mientras en algunos casos 24 horas es una unidad temporal válida, en otros casos, cada hora de caída del sistema supone pérdidas millonarias.
La determinación del RTO te ayudará a escoger de forma más eficiente las funcionalidades y servicios que debes poner en marcha en el sistema de backup de tu empresa. Obviamente, no es lo mismo contar con un sencillo sistema de recuperación a través de cintas, que emplear una solución de host-based replication.
 

Determinación del RPO (Recovery Point Objective)

El RPO indica la cantidad de información que tu organización puede permitirse perder. Este nivel de tolerancia puede implicar márgenes temporales muy amplios o increíblemente reducidos. Sea cual sea vuestro caso, el RPO escogido determinará, a su vez, la frecuencia con la que deben hacerse los backups.
 

#5 Elige las técnicas y herramientas apropiadas

Ahora que cuentas con un inventario completo y mapeado de los sistemas de información, así como una calificación de su importancia y respectivos objetivos de recuperación, llega el momento de escoger aquellas herramientas necesarias para garantizar dichos objetivos.
Obviamente, es necesario encontrar cierto equilibrio entre las necesidades de protección y los recursos financieros disponibles.
Así, aquellos datos cuya pérdida no tenga un gran impacto sobre el funcionamiento del negocio pueden ser respaldados con backups nocturnos, mediante métodos tradicionales basados en archivos; algo totalmente inadmisible para información de carácter prioritario, la cual necesitará de un mayor nivel de protección y de garantía.
En el caso de complementar la seguridad con sistemas de backup offsite, resulta indispensable que la localización de las instalaciones se encuentre en una zona geográfica distinta a la de la propia organización, para minimizar los riesgos en el caso de catástrofes naturales o desastres locales.
Por otra parte, la automatización de los procesos de recuperación debería ser un requisito imprescindible en cualquiera de las soluciones que se escojan, dado que no se puede contar con que los responsables de IT vayan estar disponibles en todo momento.
 

#6 Asigna los roles y responsabilidades

Además de la elaboración del Plan de Recuperación de Desastres per sé, se han de definir los roles involucrados y las responsabilidades que cada uno de ellos asume.
 

#7 Involucra a todos los stakeholders

La creación de un sistema de recuperación de desastres no debería limitarse al Data Center y el departamento de IT. Todos los stakeholders han de aportar su punto de vista durante la planificación, y lo que es más importante, deben estar de acuerdo con los SLAs y las prioridades establecidas por el equipo de IT.
 

#8 Documenta y comunica el DRP

Toda la estrategia de recuperación de la información ha de quedar documentada, para garantizar que se conservan los protocolos que se hayan definido, y facilitar la comunicación interna. La redacción de dicha estrategia debe quedar en manos de las personas encargadas de ejecutarla.
 

#9 Pon a prueba el DRP

Todo DRP debería ser sometido a un test, al menos, anualmente. Desgraciadamente, de acuerdo con el informe “Disaster Recovery as a Service (DRaaS) Attitudes & Adoption” publicado en el 2016, el 22% de las empresas encuestadas no llevan a cabo ningún tipo de prueba o la realizan en periodos superiores a un año.
La documentación mencionada anteriormente, debe especificar cuál es el procedimiento a ejecutar, así como la frecuencia de las pruebas.
Estos tests ayudan a determinar la compatibilidad de los procedimientos establecidos, identificar áreas que requieran algún tipo de cambio y, por supuesto, entrenar a los empleados. En el caso de detectarse alguna anomalía, el DRP habrá de ser actualizado.
 

#10 Actualización del DRP

Es posible que el Plan de Recuperación de Desastres también requiera de modificaciones pese a su buen funcionamiento. Esto tiene lugar cuando se producen cambios sustanciales en la propia organización, los cuales terminan afectando al RTO y RPO de la misma.
Puede ser que la infraestructura de IT migre a otro hardware o sistema operativo, que se cree o adquiera una nueva división dentro de la empresa o que determinados empleados de gran responsabilidad dejen la organización. En este sentido, te recomiendo el post ¿Cómo proteger la información de tu compañía cuando un empleado se marcha? , en el que aporto mi experiencia a la hora de tratar este delicado asunto desde el punto de vista de la seguridad.
Es cierto que la confección de un Plan de Recuperación antes Desastres requiere de una considerable dedicación y la atribución de una serie de recursos. Sin embargo, constituye un factor crítico a la hora de garantizar la supervivencia de una empresa.
Dotar de este importante recurso a las organizaciones es hoy un elemento ineludible que todo responsable IT debe tener en cuenta a la hora de gestionar o contratar un servicio de backup.
 
Quizá te interese:

• Cómo poner a prueba la fiabilidad de los procesos de backup de tu organización.
• 8 preguntas que un CIO debe hacerse antes de contratar un servicio de backup.
• La deduplicación en el backup.
• Tecnología de deduplicación de datos de última generación y su impacto en las compañías.