Está en la página 1de 8

TRABAJO FINAL: DRP

Jary Nallyver David Monsalve

Jose Miguel Marín Areiza

Daniel Clavijo Sierra

Daniela Jimenez Sanmartin

APRENDICES

Jaime Fonseca

INSTRUCTOR

SENA CTMA

REGULACION DE INFRAESTRUCTURA TIC

MEDELLIN, ANTIOQUIA

05/04/2022
ÍNDICE

1. Generalidades 2
2. ¿Cómo se hace un DRP? 4
3. Estándares 7
GENERALIDADES

¿QUÉ ES UN DRP?

También conocido como Disaster Recovery Plan (DRP) es un documento donde las
empresas describen los procedimientos a seguir para reanudar el área de TI en caso de
una interrupción (como caída de servidores cloud, base de datos, falla de infraestructura o
software, catástrofes) Es regido por Disaster Recovery Institute International

Tipos de DRP

Al momento de encontrar un método para recuperarse de las contingencias, las empresas


optan cada vez más por el DRaaS (Disaster Recovery as a Service) o DRP en la nube

Y si bien la opción parece ser la adecuada, lo importante en este caso es saber la mejor
forma de implementarlo.
: DRP as a Service (DRaaS). El proveedor se encarga tanto del hardware y el software
como de su manejo y mantenimiento

: DRP usando Infraestructura como servicio. El proveedor vende sus servicios,


instalaciones y equipos pero no se encarga de instalación, manejo ni mantenimiento

: DRP usando backup como servicio. O también llamado datacenter remoto.

¿Por qué es importante?

Un plan de recuperación ante desastres le permite a una empresa reanudar sus


actividades en el menor tiempo posible y con la menor pérdida de información,
garantizando la respuesta a un incidente o emergencia que afecte a los sistemas
tecnológicos.

Es un documento clave para cualquier empresa que busque un mínimo estándar de


ciberseguridad, pero sobre todo para aquellas con base tecnológica, donde la
disponibilidad de los sistemas es un asunto crítico que no puede ignorarse.
¿Por qué se debe implementar?

El plan de recuperación ante desastres es un documento clave para cualquier proyecto de


seguridad ya que asegura la continuidad de las empresas, pero, sobre todo, de aquellas
que están construidas sobre una base tecnológica.

Esta es una de las principales razones por la que un regulador o cliente corporativo te la
solicitará en sus auditorías de seguridad.

También, vimos que el DRP delimita los pasos a seguir para restaurar la tecnología
rápidamente y hacer que los sistemas estén disponibles aún en situaciones extremas. En
él también se definen los valores de las métricas RPO (tiempo en que ocurre la pérdida
real de datos) y RTO (tiempo que lleva solucionar el incidente).

“RPO” Y “RTO”

El Recovery Point Objective (RPO) y Recovery Time Objective (RTO) son dos
métricas de tiempo muy importantes para el plan de recuperación ante desastres (DRP)
ya que ayudan a crear estrategias viables para el negocio.

RPO (Recovery Point Objective): es el tiempo máximo aceptable que puede transcurrir
entre el momento en que se realizó la última copia de seguridad de los datos y un
incidente.

Para que este valor sea ínfimo debes realizar gran cantidad de backups, y eso puede
implicar mayor costo con tu proveedor. Por lo general, las empresas pequeñas suelen
establecer que el tiempo máximo de pérdida de datos sea igual a su SLA (Acuerdo de
Nivel de servicio), por ejemplo, 24 hrs.

RTO (Recovery Time Objective): es el tiempo que un negocio necesita para recuperar
sus sistemas después de la inactividad producida por un incidente.

Para definir el “RTO” es necesario conocer el tiempo de restauración que tengas con tu
proveedor de nube y cuánto demoras en levantar los servicios caídos. Habitualmente,
suele darse entre 4 y 8 horas, aunque depende de la complejidad de lo instalado.

Ten en cuenta que las estrategias y los procedimientos deben estar pensadas para
cumplir con estas dos métricas. Por ejemplo, si se definió que la métrica “RPO” es de 8
horas, entonces no puedes establecer backups cada 24 hrs.
Como se hace un DRP?

1. PLANIFICACIÓN DEL RECUPERO:

Las causas por las que una empresa generalmente no recupera más que el 31% de los
datos tienen que ver con la ausencia de un plan en el que se especifiquen los pasos a
seguir en caso de contingencia. Los servidores de DRP pueden funcionar de manera
correcta pero si no se tiene un procedimiento no se podrá operar con corrección.
También, en caso de tenerlo, se tiene que difundir de manera certera entre los actores
involucrados en la puesta en marcha de la recuperación.

2. DESTACAR LO VERDADERAMENTE IMPORTANTE:

Con un análisis que se haga de los procesos en que su empresa está involucrada podrá
determinar cuáles son aquellos movimientos que no pueden evitarse y que son realmente
fundamentales para que la empresa siga en funcionamiento. En función de la jerarquía
que se establezca se organizará el DRP.

3. DESARROLLO DE UN SIZEING EFECTIVO:

Aunque se sabe que lo más sencillo sería que el DRP funcione como un espejo de la
organización que se tiene habitualmente, la realidad es que ello no puede ser así. Es por
ello que cuando se hayan identificado los procesos verdaderamente importantes que
indicábamos en el punto anterior, se debe elaborar un sizeing que posibilite a la empresa
a trabajar con lo mínimo y con el RTO y RPO que mejor se pueda acordar.

4. DETERMINAR UN RÉGIMEN PARA EL BACKUP:

Si bien la recomendación es que el backup de imágenes sea periódico, cada empresa


tendrá que prever cómo operará esta acción de manera efectiva. Y, además, es
imprescindible comprobar que el backup funciona correctamente para que no haya
sorpresas en el momento de tener que utilizarlo.

5. LA NUBE NO LO ES TODO:
Si bien la Nube es hoy una alternativa segura para el almacenaje de información, se
recomienda también complementar el almacenaje de backup con un servidor o storage
local. Éste podría ser el primer espacio de almacenaje desde el que se cargue la
información posteriormente a la Nube.

6. ESTABLECER NORMAS DE SEGURIDAD:

De acuerdo con las políticas de seguridad que usted tenga en su empresa y que
efectivamente cumple, elabore las normas que también su proveedor de servicios de
recupero de datos tiene que cumplir.

7. CAPACITACIÓN FRENTE A LAS CONTINGENCIAS:

Cada usuario de su empresa que esté involucrado con los datos tiene que saber cómo
operar en el caso de una contingencia. Para ello se tienen que organizar capacitaciones
previas en donde se indique el procedimiento. Es aconsejable crear en este mismo
entorno de capacitación una red de comunicación y de secuenciación para que cada uno
sepa con quién debe contactarse en el caso de una contingencia.

8. COMPROBACIÓN DE QUE EL DRP FUNCIONA:

Es imposible tener un DRP y llevar a cabo incluso una capacitación sin comprobar que el
sistema funciona. Es necesario tener planificadas varias pruebas que pueden ir
escalonadas en función de los conflictos más pequeños hasta los más complejos. No
olvide tener un plan de recupero extra para el momento en que se estén desarrollando las
pruebas por si algún conflicto se ocasionara.

9. COMPLEMENTOS DEL DRP:

Además de la tecnología necesaria para la implementación del DRP, se deben tener en


consideración los planes elaborados de manejo de crisis que seguramente forman parte
del BCM (Business Continuity Management) y que colaboran en la conformación de su
empresa. De esta manera se estará operando ordenadamente.
10. ANÁLISIS DE RECURSOS

La implementación de un DRP es una tarea compleja que no solo requiere esfuerzo, sino
también tiempo y manos que lo puedan llevar a cabo, controlar y evaluar constantemente.
Es por ello que resulta necesario analizar con sinceridad cuántos recursos tiene la
empresa tanto humanos como tecnológicos para que nada se escape. Con la conclusión
que saque puede que encuentre más provechoso orientar los recursos de su empresa
para algo que abogue en su productividad, y sea más útil contratar un proveedor externo
que se encargue del recupero ante la contingencia y de la seguridad de sus datos.
ESTANDARES

actividades críticas. [Norma ISO 22301:2012, Capitulo 3, Términos y definiciones, numeral 3.42].

El análisis del riesgo incluye la estimación del riesgo. [Norma ISO 31000:2011, Capitulo 2, Términos
y definiciones, numeral 2.21].

Eventos: [Norma ISO 22301:2012, Capitulo 3, Términos y definiciones, numeral 3.17].

También podría gustarte