Resumen: La DRaaS
(Recuperación de Desastres como servicio en el CLOUD) es un componente de un
DRP (Plan de Recuperación de Desastres) que implica el mantenimiento de copias
de los datos empresariales en un entorno de almacenamiento en el CLOUD, como
medida de seguridad. Hay una serie de ventajas que lo hacen atractivo, en su
mayoría relacionadas con la reducción de costes.
Autor del artículo
|
Colaboración
|
|
JOSE
LUIS COLOM PLANAS
|
||
Actualizado
|
15 de mayo de 2015
|
|
ÍNDICE.
1. INTRODUCCIÓN A LA CONTINUIDAD DEL
NEGOCIO1.1. Normativa existente
1.2. DRP (Disaster Recovery Plan)
2. DRaaS (RECUPERACIÓN DE DESASTRES EN EL CLOUD)
2.1. Generalidades
2.2. Aspectos a tener en cuenta
2.3. Glosario de términos empleados en un DRP
3. DIFERENTES ENFOQUES DE DRaaS
3.1. Proceso de elección
3.2. Ambos entornos, de producción y de backup, en el CLOUD
3.3. Solamente el entorno de backup en el CLOUD
3.4. Backup en el CLOUD, con rest. intermedia en VMs del CLOUD.
3.5. Réplica de VMs en el CLOUD
3.6. Resumen
4. ¿ESTÁ EL CLOUD PREPARADO PARA OFRECER UN SERVICIO DE DR?
4.1. El escenario adecuado
4.2. Análisis de un caso
5. DR EN EL CLOUD, VERSUS DR TRADICIONAL
5.1. Ventajas de DRaaS frente a DR tradicional
5.2. Inconvenientes de DRaaS frente a DR tradicional
5.3. Restricciones a tener en cuenta
6. LEGISLACIÓN Y PROTECCIÓN DE DATOS
7. CERTIFICACIONES
8. BIBLIOGRAFÍA CONSULTADA
9. DERECHOS DE AUTOR
1. INTRODUCCIÓN A LA
CONTINUIDAD DEL NEGOCIO.
1.1. Normativa existente.
Como consecuencia de la creciente
preocupación de las empresas para preservar su continuidad en el tiempo,
aparece la Norma ISO 22301:2012 sobre Gestión de la Continuidad del
Negocio.
Se trata de un nuevo estándar
internacional, que especifica los requisitos para configurar y gestionar de
forma eficaz un SGCN o Sistema de Gestión de la Continuidad de Negocio.
En inglés BCMS (Business Continuity Management System).
Otras Normas, como puede ser la ISO/IEC 27001:2013, sobre un Sistema de Gestión de la Seguridad de la Información, implícitamente se apoya en la Norma ISO 22301:2012 y ya no incorpora cuestiones de continuidad en su Anexo A de controles, salvo el Objetivo de Control A.17.2 Redundancias, compuesto por un único control A.17.2.1 "Disponibilidad de los recursos de tratamiento de la información". Recuerdo la anterior versión del año 2005, que disponía del dominio A.14 "Gestión de la Continuidad del negocio" constituido por 5 controles.
La
continuidad del negocio es parte de la gestión general del riesgo en una
compañía y tiene áreas superpuestas con la gestión de la Seguridad de la
Información y la Gestión de Servicios de TI.
Si se planifica,
implementa y revisa periódicamente, la gestión de la continuidad del negocio
disminuirá la posibilidad de ocurrencia de un incidente disruptivo y, en caso
de producirse, la organización estará preparada para responder en forma
adecuada, reduciendo drásticamente el daño o impacto potencial de ese
incidente.
Una vez
determinado el alcance del SGCN dentro del contexto de la organización, logrado
el compromiso de la Dirección, definidas las políticas, contemplada la
legislación vigente en materia de protección de datos, hecho un análisis de
riesgos y decidido su tratamiento tras evaluarlos, ya estamos en condiciones de
establecer e implementar los procedimientos necesarios para la continuidad del
negocio.
Como se
trata de un sistema de gestión basado en la mejora contínua (ciclo PDCA),
deberán establecerse los mecanismos de revisión y mejora a lo largo del tiempo.
1.2.
DRP (Disaster Recovery Plan).
Un desastre es un evento que hace
que la continuación de los servicios y funcionalidades normales de la empresa,
sean imposibles. Así, un DRP se compone de las precauciones a tomar para que
los efectos de un desastre se reduzcan al mínimo y la organización sea capaz de
mantener o reanudar rápidamente sus servicios y funcionalidades, al menos las
de misión crítica.
Por lo general, la planificación de
la recuperación de desastres no solo implica un análisis de los procesos de
negocio y las necesidades de continuidad, sino que también puede incluir un
enfoque significativo en la prevención de desastres.
La recuperación de desastres se
está convirtiendo en un aspecto cada vez más importante de la informática empresarial.
Como los dispositivos, sistemas y redes son cada vez más complejos, hay muchas mas
cosas que simplemente pueden salir mal. Como consecuencia de ello, los planes
de recuperación también se han vuelto más complejos.
La mediana y gran empresa suele
tener los sistemas en CPDs dimensionados y complejos para tales enfoques simplistas
mientras que las pymes lo que no tienen es presupuesto para implementar según
qué DRP. Sin embargo, la interrupción del servicio o la pérdida de datos pueden
tener un impacto financiero grave, ya sea directamente o a través de la pérdida
de confianza del cliente, independientemente del tamaño de la empresa.
El DRP varía de una empresa a otra,
en función de variables como el tipo de negocio, los procesos involucrados y el
nivel de seguridad necesario.
Por una razón u otra, la realidad
es que la mayoría de las empresas todavía están mal preparadas ante un
desastre. Apenas el 50 por ciento de ellas afirman tener un DRP y de las que lo
tienen, muchas nunca han probado su plan, lo que equivale a no tener ninguno en
absoluto.
2. DRaaS (RECUPERACIÓN DE DESASTRES EN EL CLOUD).
2.1. Generalidades.
La DRaaS (Recuperación de Desastres
como servicio en el CLOUD) es un componente de un DRP (Plan de Recuperación de Desastres) que
implica el mantenimiento de copias de los datos empresariales en un entorno de
almacenamiento en el CLOUD, como medida de seguridad.
Algunas empresas que todavía están
recelosas de ubicar almacenamiento primario en el CLOUD, son más propensas a
usar copias de seguridad basadas en la Nube o incluso a implementar allí un
completo sistema de recuperación ante desastres.
Hay una serie de ventajas que hacen
atractivo el DRaaS, en su mayoría relacionadas con la reducción de costes. El pago
por uso lo hace asequible en contraposición a la necesidad de emplear otros
recursos en una concepción clásica, si pensemos en la infraestructura de TI
necesaria para el centro de datos replicado o de Backup.
Tomados en conjunto, estos ahorros del
DRaaS significan que las pequeñas empresas puedan contemplar planes de
recuperación de desastres, que habría sido imposible implementar de otra
manera.
2.2. Aspectos a tener en cuenta.
Hay cuestiones de seguridad importantes
a considerar en el DRP, antes de adoptar DRaaS. Conjuntamente con el CSP (Cloud Services Provider), debe
garantizarse que:
- Los datos se transfieren hacia el CLOUD de forma segura.
- Los usuarios en caso de contingencia, se autentifiquen correctamente.
- En caso de desastre, se tendrá el ancho de banda y la capacidad de red necesaria para redirigir a los usuarios al CLOUD (Cambio de Rol a destino).
- El DRP también debe incluir detalles de cómo se van a restaurar los datos, cuando se restablezca la situación (Cambio de Rol a origen).
2.3. Glosario de términos empleados en un DRP.
- RTO (Recovery Time Objective / Objetivo de Tiempo de Recuperación): Es el tiempo dentro del cual, un proceso o procesos empresariales deben ser restituidos después de un desastre (o interrupción) con determinado nivel de servicio, con el fin de evitar consecuencias inaceptables asociadas a una ruptura en la continuidad del negocio.
- RPO (Recovery Point Objective / Objetivo de Punto de Recuperación): Es el intervalo máximo tolerable en el que pueden perderse datos de un servicio de TI, tras ocurrir un desastre. En otras palabras, es el momento en el que los datos se restauran y se obtiene una perspectiva de los datos que se perderán durante el proceso de recuperación. Suele coincidir con el tiempo transcurrido desde el último backup o desde la última replicación, si ésta no es continua.
3. DIFERENTES ENFOQUES DE DRaaS.
3.1. Proceso de elección.
Al igual que con DR tradicional, no
existe un modelo único para la recuperación de desastres en el CLOUD. El
proceso de elaboración de un DRP se inicia con la identificación y priorización
de Servicios, aplicaciones y datos, determinando para cada uno la cantidad de
tiempo de inactividad que es aceptable antes de que haya un impacto empresarial
significativo.
Priorizar los activos y determinar
los necesarios objetivos de tiempo de recuperación (RTO), determinará el método
adecuado de recuperación ante desastres.
Tabla cortesía
de SearchDisasterRecovery
Identificar los activos críticos y los
métodos de recuperación, es el aspecto más relevante en este proceso, ya que es
necesario asegurar de que todas las aplicaciones y datos así clasificados,
están incluidos en el DRP. De igual modo, para controlar los costes y para
asegurar la recuperación rápida y focalizada cuando el DRP debe ser ejecutado, debe
asegurarse el dejar de lado las aplicaciones y los datos irrelevantes.
Cuanto más focalizado esté el alcance de un DRP,
más probable es que pueda verificarse periódicamente y ejecutarse caso de
desastre, dentro de los objetivos definidos.
Con las aplicaciones identificadas
y priorizadas, y definido el RTO, podrán determinarse los métodos mejores y más
rentables de alcanzarlo.
Es infrecuente que se obtenga un
único método DR para todas los Servicios, aplicaciones y datos. Lo más probable
es terminar el proceso de análisis con varios métodos, protegiendo cada uno a
grupos de aplicaciones y datos con un RTO similar.
Tabla cortesía de SmartCloud Virtualized Server Recovery de IBM
3.2. Ambos entornos, de producción y de Backup,
en el CLOUD.
Una opción cada vez más popular es
poner ambos en el CLOUD, tanto el entorno primario de producción, como el
entorno secundario de RD, estando ambos a cargo de un MSP (Proveedor de Servicios
Gestionados). De esta manera se aprovechan todos los beneficios del Cloud
Computing, basado en el “pago por uso” para la eliminación de las instalaciones
de infraestructura.
En lugar de hacerlo la empresa, ésta
desplaza DR al CSP (Proveedor de Servicios en el Cloud).
La elección del proveedor de
servicios y el proceso de negociación de las Cláusulas Contractuales y de los correspondientes
acuerdos de nivel de servicio (SLAs), son de suma importancia.
NOTA DEL EDITOR: Puede consultarse un artículo sobre
las Cláusulas Contractuales en entornos de Cloud Computing, en éste mismo Blog,
mediante el siguiente enlace:
3.3. Solamente el entorno de Backup en el CLOUD.
Otra opción es tener como entorno
primario un entorno tradicional y, realizar copias de seguridad y su restauración
caso de contingencia, en un entorno de
CLOUD.
Las aplicaciones y los datos
permanecen de forma local mediante este enfoque, con un proceso de copia hacia
la nube y restaurándose desde ella en el hardware de las instalaciones de la
empresa, después de que se produzca un
desastre.
Cuando se contempla la copia de
seguridad y recuperación en el CLOUD, es crucial entender claramente ambos caminos.
La copia de seguridad es sencilla, mientras que el aspecto más difícil es la recuperación.
Con ancho de banda limitado y, quizá
terabytes de datos a restaurar, lograr restaurar los datos de nuevo en las
instalaciones de la empresa dentro de un RTO previamente definido, puede ser un
reto.
En función de los datos que se van
a restaurar, funcionalidades como la compresión y, más importante aún, la
deduplicación, pueden facilitar y hacer viable las restauraciones de
datos desde la nube, hacia la infraestructura en las instalaciones de la
empresa.
3.4. Backup en el CLOUD, con restauración
intermedia en VMs del CLOUD.
Otra opción en caso de desastre, es
utilizar mientras duren sus efectos VM (Máquinas Virtuales) en el CLOUD, ya que
con deduplicación, prácticamente sólo se tiene que restaurar una copia de máquina
virtual completa y las diferencias de las demás. En este enfoque, los datos no
se restauran inmediatamente en las instalaciones de infraestructura de la
empresa, sino que se restablecen en las máquinas virtuales de la nube. Esto
requiere tener pre-contratado almacenamiento en la nube y un pool de recursos.
La restauración a la situación
original se puede hacer inmediatamente, después que la empresa recupere la
infraestructura tras un desastre, o bien de manera “suave” y continuada hasta
conseguir el nivelado, mientras se sigue trabajando con VMs en el CLOUD.
La “crianza” o mantenimiento previo
de máquinas virtuales DR, consiste en mantenerlas relativamente puestas al día
a través de replicaciones o restauraciones programadas. Es crucial en los casos
en que RTO agresivos deban cumplirse.
3.5. Réplica de VMs en el CLOUD.
Para aplicaciones que requieran RTO
(Objetivo de Tiempo de Recuperación) y RPO (Objetivos de Punto de Recuperación)
agresivos, la replicación es la mejor
elección de movimiento de datos.
La replicación de máquinas
virtuales en el CLOUD, se puede utilizar para proteger datos, tanto de VM a VM ambas
en la nube, como de VM en las instalaciones hacia la nube.
Para éste método, el CSP
normalmente proporciona puntos de recuperación consistentes con las
aplicaciones. Suelen proveerse para las principales, como Exchange, SQL Server,
Oracle, SharePoint, etc.
3.6. Resumen.
El CLOUD nos proporciona una serie
de ventajas en relación al DR tradicional:
- Amplía enormemente las opciones de recuperación ante desastres.
- Los ahorros de costes son significativos.
- Permite métodos de DR en pymes, que anteriormente estaban reservados a las grandes organizaciones.
No cambia, sin embargo, los fundamentos del DR:
- Tener que elaborar un DRP (Plan de Recuperación de Desastres) sólido.
- Tener que probarlo periódicamente.
- Los usuarios deben estar concienciados y preparados adecuadamente.
4. ¿ESTÁ EL CLOUD PREPARADO PARA OFRECER UN
SERVICIO DE DR?
Es importante para decidir si un
servicio de recuperación de desastres es viable, analizar las necesidades de la empresa,
entender la arquitectura de los sistemas críticos en el entorno primario o de producción
y definir los RPO (Objetivos de Punto de Recuperación) y RTO (Objetivos de Tiempo
de Recuperación).
Hay muchos casos en que la nube
pública o “privada en modalidad off-premise”, está mejor preparada para el
servicio de recuperación de desastres y es mas económica, que las soluciones
tradicionales o basadas en infraestructuras dedicadas.
4.1. El escenario adecuado.
Estos escenarios adecuados, se
reconocen por presentar las siguientes características:
- Ningún deseo de "poseer" o intención de invertir capital alguno en una solución de recuperación de desastres, con predisposición a alquilar todas las tecnologías necesarias (licencias, almacenamiento, tratamiento, servicios) en modalidad de “pago por uso” mensual.
- Enviar las copias de seguridad replicando (esperemos que deduplicadas) a una ubicación “off-premise” o fuera del sitio.
- Configurarse para estar “always-on” en una red “resiliente”, con AD (Autentificación de Directorio o equivalente) y “encaminadores” o firewalls que garanticen la reorientación inmediata de los usuarios desde un directorio principal, caso de interrupción de la red o de un desastre completo.
- Emplear plataformas tecnológicas comunes que aprovechen la virtualización (virtualización x86) y/o crear particiones (por ejemplo, LPAR de Power Systems “i”) que pueden ser segregables.
- Deseo de externalizar la implementación de su RDP y trasladar el riesgo de desempeño a un proveedor de servicios capaz, que será el propietario del acuerdo de nivel de servicio (SLA) para los datos de entorno secundario de la replicación, pruebas, documentación y personal para llevar a cabo la restauración.
- Deseo de maximizar las reclamaciones que se puedan obtener de los seguros, en caso de desastre.
4.2. Análisis de un caso.
Analicemos un caso, basado en una
empresa con dichas características, paso a paso:
- Se contrató el servicio de implantar el DRP a un CSP, con un RPO de 12 a 24 horas y un RTO de 4 a 8 horas, ambos comprobables.
- Todo se contrató en modalidad de “pago por uso” mensual (OPEX frente a CAPEX).
- Debido a la deduplicación y a la “siembra inicial de los datos”, el ancho de banda actual disponible con Internet, agregando un túnel VPN seguro, pudo ser aprovechado para el tráfico de replicación. Una segunda conexión redundante de backup, se contrató por seguridad al TSP (Proveedor de Servicios de Telecomunicaciones).
- Las copias de seguridad se realizan todas las noches, mediante deduplicación y replicado en el sitio de destino (CPD del proveedor de servicios en el CLOUD).
- La situación del Backup es monitoreado por el proveedor, el cual administra la solución de RD.
- Escritorios de usuarios fueron virtualizados y respaldados mediante una "imagen de oro", así como todos los datos locales para ciertos usuarios clave (directivos / gerentes / otros equipos críticos) bajo sospecha de no hacer salvaguardas hacia una unidad de red.
- Active Directory, autenticación y cortafuegos se configuraron para estar "siempre activos".
- En el CSP, solo se adecua la granja de servidores virtualizados y el aumento requerido de personal en el equipo que administra la recuperación, en momentos de prueba o de desastre real para realizar la recuperación. Al imputarse dichos costes solo cuando se necesitan, permite alinear los costes de recuperación con lo que realmente se está utilizando y solamente durante dicho intervalo (OPEX).
- Los escritorios virtuales se pueden clonar y ampliarse a toda la plantilla en el momento de desastre para que puedan trabajar desde su casa o ir a la sala de conferencias contratada en un hotel. Sólo tienen que acceder mediante un navegador a un sitio de Internet y los empleados volverán a trabajar con sus aplicaciones y datos corporativos.
- Los procedimientos de "Solicitud de restablecimiento" o Cambio de Rol, y los “procedimientos técnicos para la recuperación” fueron escritos por el CSP que administra la recuperación y puestos a disposición de la empresa cliente para su revisión y adaptación, y así poder incluirlos en el DRP.
- El Cambio de Rol podrá ser invocado por cualquier razón, no sólo un desastre, como puede ser para una verificación o test del DRP o para proporcionar tiempo de actividad durante una migración o actualización de hardware / sistema operativo o software de aplicación.
- El CSP permitirá una VTR (Validation Test of Recovery) o “prueba de validación de la recuperación” realizada por él mismo en otras VM (Máquinas Virtuales), de forma que no moleste a la empresa cliente para dichas pruebas, salvo una vez realizadas para la verificación final.
- Compromiso de devolver el entorno primario a la empresa cliente desde el CLOUD, en 72 horas una vez restaurada la situación de desastre en la infraestructura del sitio del cliente, y tras la petición formal de dicha intención.
- Entrega por el CSP de un “documento de rendimiento de la prueba”, sin contener ningún tipo de información técnica confidencial, para que pueda ser compartida con los grupos de interés de la empresa, como pueden ser clientes o auditores, aumentando el reconocimiento.
- En el momento de producirse un desastre real, el entorno de producción cambiará de rol hacia el entorno secundario, gestionado por el proveedor de servicios en el CLOUD.
- La empresa cliente puede permanecer el tiempo que sea necesario operando sobre dicho entorno secundario, siempre pagando las cuotas acordadas.
- Las copias de seguridad se seguirán llevando a cabo por el CSP hasta que vuelvan a intercambiarse los roles y el control pase de nuevo al entorno productivo.
5. DR EN EL CLOUD, VERSUS DR TRADICIONAL.
El concepto de DRaaS en el CLOUD, presenta varias ventajas competitivas respecto
al servicio tradicional de recuperación de desastres, incluyendo un menor coste
de operaciones y un menor tiempo de recuperación.
Analizándolo en detalle:
5.1. Ventajas de DRaaS frente a DR tradicional.
- El coste es el factor clave para la elección de un DRaaS. Un sitio secundario físico DR, significa inversiones en espacio, conectividad, servidores y quizá cabinas de almacenamiento en un CPD adicional. También conduce a costos operacionales adicionales de energía y refrigeración, mantenimiento del sitio, y las necesidades asociadas de personal técnico y de apoyo.
- Un servicio de recuperación de desastres basado en el CLOUD, ofrece un entorno secundario basado en máquinas virtuales, a partir de la infraestructura física o virtual en el centro de datos principal de la empresa. Se paga para almacenar las instantáneas y los datos de las aplicaciones en un estado de suspensión, y la replicación de los datos del entorno primario al secundario (Cloud DR) para la sincronización de datos entre sitios (OPEX).
- Con DRaaS, la recuperación ante desastres permite poner en línea el sitio secundario en cuestión de segundos o minutos, en lugar del tiempo requerido para un sitio físico DR, que podría tardar unos minutos (si no horas). El arranque de una máquina física toma por lo menos un minuto o más, mientras que una instancia de máquina virtual puede estar en funcionamiento en cuestión de segundos. Típicamente, un sitio físico DR sólo funciona durante la replicación de datos, o en el caso de un desastre real.
- Además, la pérdida de disponibilidad está directamente relacionada con el tiempo de inactividad. Un sitio DR en el CLOUD que arranca al cabo de unos pocos segundos, se traduce en una pérdida de disponibilidad de únicamente ese período de tiempo.
- En caso de que la conectividad de red no esté disponible con la configuración física de DR, las operaciones manuales pueden ser necesarias para reanudar las operaciones del sitio. Sin embargo, un DRaaS se pueden activar desde cualquier sitio, incluso con un ordenador portátil dotado de una conexión 3G a Internet.
5.2. Inconvenientes de DRaaS frente a DR tradicional.
- El CPD del CSP, puede incluso estar ubicado en un continente diferente. Esto puede causar problemas de latencia para las VM (Máquinas Virtuales) de una empresa en los casos en que se utilicen aplicaciones críticas que requieran tiempos de respuesta altos y baja latencia. Suele ser el caso de controlar procesos productivos en planta, con captura de transacciones desde máquinas o PLCs (Controladores Lógicos Programables), en tiempo real.
- Con un DRaaS, la empresa debe asegurarse de que sus aplicaciones son compatibles con la infraestructura de nube pública. Por ejemplo, algunas aplicaciones pueden exigir un entorno específico que puede no estar disponible en el CSP. Deben estudiarse en detalle todos los casos.
Por tanto, la elección de ir a un DRaaS se regirá exclusivamente por el
imperativo del negocio. Si una empresa tiene aplicaciones importantes que deben
estar disponibles en cuestión de minutos de tiempo de inactividad, se puede
considerar DRaaS. Sin embargo, si una organización presenta problemas de
latencia o aplicaciones poco estándares, se debe optar por la DR física
tradicional.
5.3. Restricciones a tener en cuenta.
Debido a los diferentes protocolos utilizados por los proveedores de
DRaaS para escribir datos en su almacenamiento en el CLOUD, la velocidad o tasa
de transferencia a la que los datos se copian o replican en la nube puede
diferir de un proveedor a otro. Por ejemplo, según estudios realizados, la
velocidad a la que los datos se copian con un servicio de copia de seguridad de
Google Cloud, difiere de la de una copia de seguridad en la nube de Amazon,
incluso con el mismo ancho de banda disponible.
Además, aunque no hay ninguna limitación sobre el tipo de datos que
pueden ser guardados en la nube, puede haber una restricción impuesta por el CSP
en el tamaño del archivo. Por ejemplo, cierto proveedor de almacenamiento en el
Cloud limita el envío de un único archivo, a un tamaño máximo de 5 GB; Sin embargo
no limita la cantidad de datos que pueden ser enviados por período de tiempo.
6. LEGISLACIÓN Y PROTECCIÓN DE DATOS.
No hay que olvidar que el hecho de llevar datos cifrados al CLOUD, no exime
de los requisitos jurídicos.
NOTA DEL EDITOR: Para ampliar conceptos en relación a la problemática
legislativa de llevar datos personales al CLOUD, puede consultarse en éste
mismo Blog, los siguientes artículos:
NOTA DEL EDITOR: Para ampliar conceptos en relación a los Backups en
general, puede consultarse en éste mismo Blog, el siguiente artículo:
7. CERTIFICACIONES.
Existen diferentes certificaciones que pueden
acreditar el “buen hacer” de un proveedor de DRaaS:
- ISO 22301:2012 que certifica al CSP conforme dispone de un Sistema de Gestión de la Continuidad del Negocio.
- ISO 27001:2008 que Certifica al CSP conforme dispone de un Sistema de Gestión de la Seguridad de la Información.
- ISO 27017 “Security in Cloud Computing”.
- ISO 27018 “Code of pactice for data protection controls for public Cloud Computing services”.
8.
BIBLIOGRAFIA CONSULTADA
- TechTarget.
(SearchDisasterRevovery).
“Disaster recovery and business continuity tutorials”.
DR tutorials
- Jacob
Gsoedl. “Disaster recovery in the
cloud explained”. August 2011. SearchDisasterRecovery.
9.
DERECHOS DE AUTOR.
Todas las
imagines bajo licencia 123RF Internacional o extraídas de los documentos
referenciados en el apartado BIBLIOGRAFÍA CONSULTADA.
La presente obra y su título están protegidos por el derecho de autor. Las
denominadas obras derivadas, es decir, aquellas que son el resultado de la
transformación de ésta para generar otras basadas en ella, también se ven
afectadas por dicho derecho.
Sobre el autor:
José Luis Colom Planas Posee
un doble perfil, jurídico y técnico, que le facilita el desempeño profesional
en el ámbito de los diferentes marcos normativos, especialmente del Derecho de
las nuevas tecnologías y las normas ISO de adscripción voluntaria.
A
nivel de especialización jurídica, ha realizado el postgrado
de Especialista Universitario en Protección de Datos y Privacidad en la
Facultad de Derecho de la Universidad de Murcia, disponiendo de la
certificación CDPP (Certified Data
Privacy Professional) del ISMS Fórum Spain. También ha cursado el programa
superior de Compliance Officer (Controller jurídico) en la Escuela Legal WKE y
se ha especializado respecto a los delitos de blanqueo de capitales en la UOC,
en colaboración con el Ilustre Colegio de Abogados de Barcelona (ICAB). Es
experto externo en prevención de blanqueo de capitales, certificado por INBLAC.
A
nivel de especialización técnica, ha cursado Ingeniería
técnica de Telecomunicaciones en “la Salle BCN” estando adscrito a la AEGITT
(Asociación Española de Graduados e Ingenieros Técnicos de Telecomunicación). Es
Auditor e Implantador de SGSI (Gestión de la Seguridad de la Información) por
AENOR (Asociación Española de Certificación y Normalización). Leader Auditor & Implanter ISO 27001 e ISO 22301
by BSI (British Standards Institution). Auditor del esquema de
certificación STAR para prestadores de servicios de Cloud Computing (BSI +
Cloud Security Alliance). Ha obtenido la certificación internacional CISA
(Certified Information Systems Auditor) by ISACA (Information Systems Audit and
Control Association). Dispone de las certificaciones ISO 20000 PMI (Process
Management Improvement) e ITIL Service Management by EXIN (Examination
Institute for Information Science).
Desempeña su labor
profesional en GOVERTIS Advisory Services
cómo Compliance, Management & IT Advisor, incidiendo en Compliance
Penal, PBCyFT, asesoramiento respecto a cumplimiento normativo, privacidad
y gestión de la seguridad de la información. Ha participado como lead implementer y lead auditor de diferentes sistemas de gestión basados en Normas
ISO, individuales o integrados, y en la optimización de sus procesos. Ha
realizado diferentes niveles de auditorías de cumplimiento legal ya sea para
organizaciones sujetas a Derecho público o privado.
También colabora con BSI como
auditor jefe de certificación e impartiendo formación para la obtención de la
certificación de lead auditor, en diferentes marcos normativos. A partir de su
dilatada experiencia, edita el Blog temático “Aspectos Profesionales”.
Convencido del valor que
aportan las organizaciones profesionales, es asociado sénior de la APEP
(Asociación Profesional Española de Privacidad), miembro de ISACA
(Information Systems Audit and Control Association), miembro de ISMS Forum
Spain (Asociación Española para el Fomento de la Seguridad de la
Información), miembro de itSMF (IT Service Management Forum), ATI (Asociación
de Técnicos de Informática), ENATIC (Asociación de expertos nacionales
de la abogacía TIC), CUMPLEN (Asociación de Profesionales de
Cumplimiento Normativo) y asociado de INBLAC (Instituto
de expertos en prevención del Blanqueo de Capitales), habiendo sido
ponente o colaborado en casi todas las referidas organizaciones. También lo es
de la iniciativa del Observatorio Iberoamericano de Protección de Datos (OIPRODAT)
habiendo obtenido, junto a algunos colaboradores del mismo, un premio
compartido otorgado por la AEPD.
Twittear
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.