lunes, 5 de noviembre de 2012

DRaaS: LA RECUPERACIÓN DE DESASTRES COMO SERVICIO EN EL CLOUD


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 NEGOCIO
         1.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).

Aunque no nos basemos en la Norma, lo que al menos se debería tener siempre es un BCP (Business Continuity Plan) o en su defecto un 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.

                                              Categorización de activos  (C) ITIL:2011

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:




Al ceder parte de la Gestión al proveedor de servicios, la empresa debe estar absolutamente segura de que es capaz de ofrecer un servicio ininterrumpido dentro del SLA, definido tanto para los casos de entorno primario, como para los de entorno DR.






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.

Si una organización tiene restricciones en cuanto a la ubicación geográfica donde residen los datos (Regulaciones tipo ENS y/o legislación en materia de protección de datos tipo LOPD), como pueden ser las AA.PP. (Administraciones Públicas), debe estudiarse el caso con detenimiento. Una solución pasa por elegir un proveedor nacional, o bien contratar el DRaaS en un CSP que nos de a escoger entre sus diferentes CPDs, optando por uno que esté ubicado en España, en el EEE (Espacio Económico Europeo) o en su defecto, en un país considerado por la AEPD (Agencia Española de Protección de Datos) con nivel adecuado de protección.

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.

El comité ISO/IEC JTC1, está elaborando dos borradores sobre CLOUD SECURITY, concretamente:

  • 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.





No hay comentarios:

Publicar un comentario