Ley Marco de Ciberseguridad Chilena – Disposiciones Generales

La primera sección de la Ley Marco de Ciberseguridad Chilena, conocida como Título 1, habla sobre las disposiciones generales de la Ley, lo que corresponde al marco de referencia de esta ley. Como tal, está compuesta de 3 artículos, los cuales se explicarán a continuación.

Artículo 1 – Objeto

El primer artículo de la ley apunta a definir su objetivo principal. Y en este sentido, la ley declara, textualmente como objeto el “establecer la institucionalidad, los principios y la normativa general que permitan estructurar, regular y coordinar las acciones de ciberseguridad de los organismos de Estado y entre estos y los particulares”.

Este primer párrafo plantea el principal objetivo que persigue una ley marco. Y este objetivo está asociado a afrontar la necesidad de abordar la ciberseguridad no solo como un desafío de una industria en particular, sino que forma parte de todo un ecosistema a nivel nacional.

Para poder abordar la ciberseguridad es necesario regular de forma coordinada la respuesta ante incidentes de ciberseguridad que puedan afectar a organismos del estado u otros organismos particulares que, de verse afectados por un incidente de esta naturaleza, puedan comprometer la seguridad nacional o la información de ciudadanos del país. Y esta respuesta coordinada debe estar regida por una serie de principios y normativas, que en otros países suelen estar asociadas a estándares como ISO 27001 (Information security, cybersecurity and privacy protection – Information security management systems – Requirements), o ISO 27018 (Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors), por nombrar ejemplos.

Además, la ley tiene como objetivo el “establecer los requisitos mínimos para la prevención, contención, resolución y respuesta a incidentes de ciberseguridad”, así como el “establecer las atribuciones y obligaciones de los organismos de Estado, así como los deberes de las instituciones determinadas en el artículo 4” (de servicios esenciales y operadores de importancia vital, los cuales serán descritos en el próximo artículo de esta serie).  

Este punto se convertirá en un pilar importante de la Ley Marco, ya que establecerá un lenguaje de común entendimiento para la gestión de los incidentes de ciberseguridad. Al establecer una serie de requerimientos mínimos para el manejo de estos, así como las atribuciones y obligaciones de los organismos de estado y de instituciones de servicios esenciales, se logrará un estándar en este proceso tan relevante.

Finalmente, el primer artículo de la Ley indica que la administración del estado estará compuesta por “los Ministerios, las Delegaciones Presidenciales Regionales y Provinciales, los Gobiernos Regionales, las Municipalidades, las Fuerzas Armadas, de Orden y de Seguridad Pública, así como las Empresas Públicas creadas por Ley, y los órganos y Servicios Públicos creados para el cumplimiento de la función administrativa”. Finalmente, la Ley Marco de Ciberseguridad será aplicable no solo a las empresas del Estado, sino que aquellas sociedades donde el Estado “tenga participación accionaria superior al 50% o mayoría en el directorio”.

Este último párrafo muestra el ámbito de acción de la Ley, que estará asociada entonces a todas las entidades públicas y/o asociadas al estado nacional.

Artículo 2 – Definiciones

El artículo 2 establece un glosario de términos que serán de utilidad para la aplicación de esta ley. Comprende 15 conceptos que mezcla definiciones estándares y otras propias del ámbito de aplicación de la Ley y son las siguientes:

• Activo Informático: Se refiere a toda información almacenada en una red y/o sistema informático, que tenga valor para una persona u organización.
• Agencia: Hace referencia a la ANCI (Agencia Nacional de Ciberseguridad).
• Auditoría de seguridad: Proceso de control destinado a revisar el cumplimiento de las políticas y procedimientos derivados del SGSI (Sistema de Gestión de Seguridad de la Información).
• Autenticación: Propiedad de la información que da cuenta de su legítimo origen.
• Ciberataque: Hace referencia a cualquier intento de destruir, exponer, alterar, deshabilitar, obtener acceso, filtrar o hacer uso no autorizado de un activo informático.
• Ciberseguridad: Preservación de la confidencialidad e integridad de la información, así como de la disponibilidad y resiliencia de las redes y sistemas informáticos, con el objetivo de proteger a las personas, la sociedad, las organizaciones o naciones de algún incidente de Ciberseguridad.
• Confidencialidad: Propiedad de la información relativa a la restricción de acceso a ella solo por individuos, entidades o procesos autorizados.
• Disponibilidad: Propiedad de la información relativa a la factibilidad de acceder y/o utilizar la información cada vez que sea requerida por un individuo, entidad o proceso autorizado.
• Equipo de Respuesta a Incidentes de Ciberseguridad (CSIRT): Corresponde a un centro multidisciplinario que tiene como objeto la prevención, detección, gestión y respuesta a incidentes de ciberseguridad o ciberataques, en forma rápida y efectiva, que actúe conforme a procedimientos y políticas predefinidas, ayudando a mitigar sus efectos.
• Incidente de ciberseguridad: se refiere a todo evento que perjudique o comprometa la confidencialidad o integridad de la información, la disponibilidad o resiliencia en las redes y/o sistemas informáticos, o la autenticación de los procesos ejecutados o implementados en las redes y sistemas informáticos.
• Integridad: Propiedad de la información que asegura que ésta no ha sido modificada de forma alguna sin autorización previa.
• Red y Sistema Informático: Se refiere a un conjunto de dispositivos, cables, enlaces, enrutadores u otros equipos de comunicaciones o sistemas que almacenen, procesen o transmitan datos digitales.
• Resiliencia: Se refiere a la capacidad de las redes y sistemas informáticos para seguir operando luego de un incidente de ciberseguridad, aunque esta operación sea en un estado degradado, debilitado o segmentado, así como la capacidad de las redes y sistemas informáticos para recuperar sus funciones después de un incidente de ciberseguridad.
• Riesgo: Probabilidad de ocurrencia de un incidente de ciberseguridad. La magnitud de un riesgo es cuantificada en términos de la probabilidad de ocurrencia del incidente y del impacto de las consecuencias de este.
• Vulnerabilidad: Debilidad de un activo o control de seguridad que puede ser explotado por una o más amenazas informáticas.

Artículo 3 – Principios Rectores

El tercer artículo de la Ley Marco, siendo además el último artículo de su primer título de disposiciones generales, establece los 8 principios bajo los cuales regirá la Ley. Estos principios son los siguientes:

• Control de Daños: En caso de que ocurra un ciberataque o un incidente de ciberseguridad, la ley indica que se deberá actuar “coordinada y diligentemente”, adoptando las “medidas necesarias para evitar la escalada del ciberataque o incidente de ciberseguridad y su posible propagación a otros sistemas informáticos”.
• Cooperación con la autoridad: destaca la necesidad de prestar la “cooperación debida con la autoridad competente, y si es necesario, cooperar entre diversos sectores” para la resolución de incidentes de ciberseguridad, teniendo en cuenta la “interconexión e interdependencia de los sistemas y servicios”. En otras palabras, se establece la obligación de sacar provecho a la red interconectada que se pretende establecer con la Ley Marco.
• Coordinación: Hace mención a la Ley N° 18.575 (Ley orgánica constitucional de bases generales de la administración del estado), el cual busca que los organismos del estado, en caso de este tipo de incidentes, actúen coordinadamente y eviten la duplicación o interferencia de funciones.
• Seguridad en el ciberespacio: Este principio establece el deber del estado de “resguardar la seguridad en el ciberespacio”. En este sentido, el Estado deberá velar porque todas las personas “puedan participar de un ciberespacio seguro”, lo que establece la necesidad de otorgar la protección de las redes y/o sistemas informáticos que contengan información de grupos de personas que suelan ser en mayor medida objeto de ciberataques. Como comentario al margen, la Ley Marco podría haber hecho una definición más explícita del concepto de Ciberespacio.
• Respuesta responsable: la aplicación de medidas para responder a incidentes de ciberseguridad o ciberataques en ningún caso podrá significar la realización o el apoyo a operaciones ofensivas.
• Seguridad informática: Establece que toda persona tiene derecho a “adoptar las medidas técnicas de seguridad informática que considere necesarias, incluyendo el cifrado”.
• Racionalidad: Establece que las medidas para la gestión de incidentes, las obligaciones asociadas y el ejercicio de las facultades de la ANCI deberán ser “necesarias y proporcionales al grado de exposición a los riesgos, y al eventual impacto social y económico”.
• Seguridad y privacidad por defecto y desde el diseño: Indica que el proceso de diseño e implementación de sistemas, aplicaciones y tecnologías informáticas deben tener en cuenta la seguridad y la privacidad de los datos personales que se procesan.

Con esto terminamos la primera sección de la norma. En un próximo artículo, se detallará la definición de los servicios esenciales y operadores de importancia vital.

Ley Marco de Ciberseguridad Chilena – Análisis a Fondo

Estructura General de la Ley

El día 08 de abril de este año, luego de un poco más de dos años de trámites legislativos en el congreso nacional de Chile, fue publicada en el Diario Oficial la Ley N° 21.663, conocida como la Ley Marco de Ciberseguridad, la cual fue promulgada por el congreso el pasado 26 de marzo.

Es sin duda uno de los pasos más relevantes dentro del tratamiento de los riesgos de ciberseguridad existentes a nivel nacional, ya que entre otras cosas, establece la creación de una Agencia Nacional de Ciberseguridad (ANCI), la cual estará a cargo de la fiscalización y sanción a empresas, tanto públicas como privadas, que presten servicios esenciales o de importancia vital, así como aquellas empresas dedicadas a industrias como los servicios financieros, la salud, energía o transporte, entre otros. Esta agencia será ni más ni menos que la primera de esta naturaleza en Latinoamérica, lo cual puede establecer un precedente en cuanto a la adaptación de las normativas internacionales a la realidad de nuestro continente.

A través de este blog, revisaremos en detalle esta ley tan relevante para nuestro país, en una serie de artículos en donde desmenuzaremos sus capítulos y el impacto que tendrá sobre el ecosistema de seguridad de nuestro país.

La estructura de la Ley es la siguiente:

• Título 1: Disposiciones generales
• Título 2: Obligaciones de ciberseguridad
  • Párrafo 1: Servicios esenciales y operadores de importancia vital
  • Párrafo 2: Obligaciones de ciberseguridad
• Título 3: De la agencia nacional de ciberseguridad
  • Párrafo 1: Objeto, naturaleza y atribuciones
  • Párrafo 2: Dirección, organización y patrimonio
  • Párrafo 3: Consejo multisectorial sobre ciberseguridad
  • Párrafo 4: Red de conectividad segura del estado
  • Párrafo 5: Equipo nacional de respuesta a incidentes de seguridad informática
• Título 4: Coordinación regulatoria y otras disposiciones
• Título 5: Del equipo de respuesta a incidentes de seguridad de la defensa nacional
• Título 6: De la reserva de información en el sector público en materia de ciberseguridad
• Título 7: De las infracciones y sanciones
• Título 8: Del comité interministerial sobre ciberseguridad
• Título 9: Órganos autónomos constitucionales
• Título 10: De las modificaciones a diversos cuerpos legales
• Disposiciones transitorias

Bienvenidos entonces a esta serie de artículos de ciberseguridad. ¡Nos vemos en el siguiente capítulo!

Usando vCloud Availability para escenarios de Disaster Recovery (Parte 8 y final)

En esta serie de artículos hemos revisado a nivel de detalle el proceso de Disaster Recovery de servidores virtuales, utilizando la herramienta vCloud Availability de VMware. Este proceso parte con la protección, el failover, la protección reversa (para establecer la réplica en sentido inverso), el failback o failover reverso y posteriormente la re-protección.

El proceso de Disaster Recovery con vCloud Availability.

Sin embargo, vCloud Availability tiene una opción adicional para hacer el proceso de failover, llamado migrate. ¿Qué diferencias tiene con el failover y cuál es el rendimiento de este proceso? Vamos a revisar esta opción en el último artículo de esta serie.

Usando la opción migrate.

El primer detalle relevante al utilizar esta opción es que el asistente nos indica inmediatamente que el servidor del Datacenter Principal, una vez terminado el proceso, se apagará. En este sentido, el proceso de migración, a diferencia del proceso de failover, está pensado para escenarios en donde ambos datacenters se encuentran operativos. En ese sentido, el servidor migrado se debe apagar en el Datacenter Principal para no causar conflictos a nivel de red.

Configuración del proceso.

Otro aspecto relevante de este proceso es que no permite seleccionar instancias anteriores. Se sincroniza siempre con la última réplica.

Resumen del proceso.

Seguimiento del proceso.

Podemos visualizar que en el Datacenter Principal, apenas inicia el proceso, el servidor de pruebas cambia a estado de ejecución parcial.

Cambio de estado del servidor en el Datacenter Principal.

El proceso de migración duró 3 minutos, comparado con el proceso de failover para el mismo servidor que duró poco más de un minuto.

Comparación de tiempos del proceso.

Una vez finalizado el proceso de migración, el servidor en nuestro Datacenter Principal se ha detenido, mientras aparece en ejecución en nuestro Datacenter de Contingencia.

Situación del servidor en el Datacenter Principal una vez terminada la migración.

Situación del servidor en el Datacenter de Contingencia una vez terminada la migración.

El resto del proceso es similar; toca ahora hacer la reversa.

Realizando la protección reversa.

Confirmando la protección reversa.

Seguimiento del proceso.

El servidor ahora aparece en Incoming Replications.

Rendimiento de red en la protección reversa.

Una vez terminada la protección reversa, el servidor desaparece del Datacenter Principal.

El proceso de sincronización reversa duró 6 minutos, bastante más que los 2 minutos que duró la protección reversa cuando aplicamos la opción de failover.

Duración de la protección reversa.

Luego realizaremos el failback utilizando la misma opción de migración, para comparar los tiempos de ejecución de las actividades.

Esta vez, el servidor en nuestro Datacenter de Contingencia entra en un estado de ejecución parcial mientras comienza la migración a su Datacenter de Origen.

Paralelamente, comienza a levantarse el servidor en nuestro Datacenter Principal.

Posteriormente, el servidor en el Datacenter de Contingencia queda detenido.

Al igual que como sucedió en el proceso de failover, el failback utilizando la opción de migración tomó más tiempo que el proceso de failback que realizamos anteriormente.

Comparación de los tiempos de failback.

Para finalizar las pruebas, haremos la re-protección y cerraremos así el proceso. Lamentablemente para propósitos de esta prueba, el proceso de re-protección se realizó en paralelo con la sincronización de un servidor altamente transaccional, por lo cual los tiempos de sincronización no son comparables.

En resumen, utilizar la opción de migración en vez de utilizar la opción de failover en vCloud Availability tiene como principal diferencia el hecho de que no deja utilizar instancias anteriores para el proceso, además del hecho de que apaga forzosamente el servidor en el Datacenter de Origen una vez finalizado el proceso. Si bien las pruebas realizadas no son 100% concluyentes, se puede indicar que el proceso de migración es ligeramente más lento que el proceso de failover, ya que añade tareas adicionales que el proceso anteriormente mencionado.  Es un proceso pensado para utilizar en escenarios donde ambos Datacenters se encuentren operativos.

Con esto terminamos esta serie de artículos sobre esta herramienta de DRP como servicio, nativa de VMware y que ha mejorado una enormidad desde su primera versión. ¡Nos vemos pronto en otro artículo de seguridad y continuidad de negocio!

Usando vCloud Availability para escenarios de Disaster Recovery (Parte 7)

En el capítulo anterior de esta serie, dejamos preparado el escenario de vuelta atrás, al realizar una protección reversa de nuestro servidor ya ubicado en el Datacenter de Contingencia. Esto nos permite habilitar el servicio de réplica desde dicho Datacenter al Datacenter Principal, para que una vez que nos den luz verde, poder iniciar el proceso de failback o failover reverso.

Antes de eso había olvidado comentarles algo relevante. La consola de vCloud Availability existe en ambos Datacenter, y podemos operar de manera cruzada desde cualquiera de las dos consolas. Para propósitos de este artículo, toda la operación la hemos realizado desde la consola del Datacenter Principal.

Partiremos nuestro failback revisando el estado de las réplicas de nuestro servidor de pruebas. Para ello, iremos a la consola de vCloud Availability de nuestro Datacenter Principal y en la sección Incoming Replications pincharemos en nuestro servidor, para ir a la pestaña Instances. Si hacemos esta misma acción en la consola de nuestro Datacenter de Contingencia, la única diferencia es que esta tarea deberemos hacerla en la sección Outgoing Replications.

Estado de las réplicas de nuestro servidor de pruebas.

Podemos visualizar rápidamente que todo se encuentra OK. Es importante acá considerar que como este es un servidor de pruebas no transaccional, las réplicas son muy pequeñas, ya que el servidor no ha tenido transaccionalidad alguna en estos días.

Sin embargo, podemos visualizar que el server ha generado un disco activo de unos 12 GB, los cuales se replicaron inicialmente a gran velocidad gracias a los algoritmos de compresión de la herramienta.

Uso de disco en el servicio de réplica.

Llegó entonces el momento de realizar el failback. Para ello, en la consola de vCloud Availability, seleccionamos nuestro servidor y en Actions seleccionamos Failover.

Iniciando el proceso de failover.

De manera similar a lo que vimos un par de artículos atrás, configuraremos las opciones de nuestro proceso.

Configuración del proceso.

Posteriormente a esto, se debe seleccionar el punto de recuperación utilizado para el failback. Como este artículo lo escribí después de realizar el anterior, existen más puntos de recuperación creados.

Seleccionando el punto de restauración o failback.

Finalmente, en el cuadro de resumen de la operación se destaca que el proceso se realizará hacia el Datacenter Principal. Una vez que demos clic en Finish comenzará el proceso.

Cuadro resumen del proceso.

Gráficamente, podemos ver como comienza el proceso de failback.

Seguimiento del proceso de failback.

Una vez terminado el proceso de failback, podremos visualizar como nuestro servidor se ha encendido en el Datacenter Principal. Es importante recalcar que, en esta ocasión, se crea una nueva vApp, sin eliminar la anterior.

Status del servidor en el Datacenter Principal.

Por otro lado, el servidor sigue encendido en el Datacenter de Contingencia.

Status del servidor en el Datacenter de Contingencia.

Se puede visualizar, además, en el Datacenter Principal, las tareas asociadas al proceso de failback.

Tareas asociadas al proceso de failback. Se visualiza la eliminación del disco independiente asociado al servicio de réplica.

Una vez terminado el proceso de failover, que para el caso del servidor de pruebas duró algunos segundos, se puede visualizar que, a nivel de tráfico de red, la cantidad de datos que se movieron de un Datacenter a otro fue irrelevante.

Transferencia de archivos asociados al proceso.

Para cerrar el ciclo del DRP, debemos realizar la re-protección del servidor. Con esta tarea, se reestablecerá el servicio de réplica desde el Datacenter Principal hacia el Datacenter de Contingencia, lo cual eliminará el servidor desde el segundo Datacenter.

Para ello, iremos a nuestro servidor de pruebas y seleccionaremos Reprotect dentro del listado de acciones.

Iniciando la re-protección.

En la ventana emergente, daremos clic a Reverse para iniciar el proceso de re-protección.

Podemos seguir el status del proceso de re-protección en la consola principal.

Seguimiento al proceso de reprotección.

Al igual como pasó anteriormente, al cabo de unos segundos el servidor desaparecerá de la sección Incoming Replications, para volver a la sección Outgoing Replications como estaba originalmente.

El servidor ahora aparece en Outgoing Replications, tal como estaba al comienzo de todo el proceso.

Podemos visualizar, en el Datacenter de Contingencia, como el servidor ha sido borrado y su vApp ha quedado en estado Detenida.

Una vez iniciada la réplica asociada a la reprotección, desaparece el servidor del Datacenter de Contingencia.

Podemos visualizar en el registro como se eliminó el servidor y como se ha creado el disco independiente asociado al servicio de réplica.

Tareas asociadas a la re-protección del servidor en el Datacenter de Contingencia.

Para propósitos de esta prueba, el proceso de re-protección duró casi 10 minutos.

Duración del proceso.

Una vez finalizado el proceso, podemos borrar manualmente las vApps que quedaron huérfanas en ambos Datacenters y renombrar nuestra vApp en el Datacenter Principal, para mantener el orden de estas.

Eliminando la vApp que quedó vacía.

Confirmando la eliminación.

Renombrando la vApp al valor original.

Y con esto hemos concluido nuestro artículo de hoy. Para finalizar, en el último artículo de esta serie veremos las diferencias entre efectuar un failover y una migración del servidor. ¡Será hasta la próxima!

Usando vCloud Availability para escenarios de Disaster Recovery (Parte 6)

En el capítulo anterior de esta serie, realizamos un proceso de Failover de nuestro servidor de pruebas hacia el Datacenter de Contingencia. Hoy, comenzaremos a preparar el proceso de vuelta a operaciones normales realizando la protección reversa del servidor en el Datacenter de Contingencia, para así habilitar el servicio de réplica inversa que finalmente permitirá realizar el proceso de Failback o Failover inverso. Veamos cómo se hace.

En la consola de vCloud Availability, seleccionamos nuestro servidor y en Actions seleccionamos Reverse.

Comenzando la protección reversa.

En la ventana emergente, confirmamos haciendo clic en Reverse. Esto nos indica que se establecerá el proceso de réplica inversa.

Confirmando la protección reversa.

Seguimiento a la tarea de protección reversa.

Al cabo de algunos segundos, veremos cómo nuestro servidor ha desaparecido del Datacenter Principal. Para poder volver a visualizarlo, debemos buscarlo en la sección Incoming Replications, ya que ahora se encuentra operando desde el Datacenter de Contingencia.

Esta vez, el servidor se encuentra realizando la sincronización desde el Datacenter de Contingencia hacia el Datacenter Principal.

¿Y qué ha sucedido con nuestros servidores en ambos Datacenter? Una vez terminada la sincronización reversa, en el Datacenter Principal la máquina original ¡ha desaparecido!

Status de la vApp en el Datacenter Principal.

La máquina virtual ha desaparecido una vez terminada la protección reversa.

Por otro lado, se ha creado un disco independiente en el Datacenter Principal, el cual está asociado al proceso de réplica inversa.

Creación de la réplica en el Datacenter Principal.

Podemos visualizar que el ID de disco independiente es equivalente al indicado en vCloud Availability.

Finalmente, podemos visualizar el proceso de réplica inversa en relación con el rendimiento, el cual se realizó de manera muy rápida.

Tiempos de ejecución de la réplica inversa.

En el próximo artículo de esta serie, realizaremos el proceso de failover reverso, paso clave en el proceso de vuelta a operaciones normales. ¡Nos vemos!

Usando vCloud Availability para escenarios de Disaster Recovery (Parte 5)

Ya hicimos todos los preparativos para realizar el proceso de Failover, así que ya es tiempo de ejecutar esta actividad y visualizar los cambios a nivel de ambos Datacenter con los equipos.

Para iniciar el proceso de failover, seleccionamos el servidor de pruebas en la consola principal de vCloud Availability y en la sección de Actions, seleccionamos Failover.

Iniciando el proceso de failover.

En la ventana emergente configuraremos las primeras opciones de nuestro proceso. En primer lugar, nos da la opción de realizar un consolidado de todas las instancias creadas, a fin de minimizar los problemas de integridad que puedan existir. Es una opción que, al habilitarla, incrementará el RTO del proceso (tiempo de recuperación). Posteriormente, nos entrega la opción de encender el servidor en el Datacenter de Contingencia una vez finalizado el failover y nos permite cambiar la configuración de red, conectando el servidor a otra VLAN. Esto es particularmente útil si el Datacenter de Contingencia no está extendido en Capa 2 al Datacenter Principal. Una vez seleccionadas las opciones, damos clic a Next.

Configuración inicial del failover.

Posteriormente, debemos definir el punto de restauración. Es importante saber que mientras más antiguo sea el punto que escojamos, mayor debería ser la cantidad de datos perdidos en el proceso. Generalmente, se utilizan puntos antiguos cuando el failover se realiza por problemas de integridad de datos más que por un evento disruptivo desde el ámbito de la continuidad. Una vez seleccionado el punto de recuperación, hacemos clic en Next.

Seleccionando el punto de failover.

En la ventana de resumen, damos clic en Finish para confirmar el proceso de failover.

Resumen del proceso.

Gráficamente, podemos ver como comienza el proceso de failover.

Seguimiento en línea del proceso.

Una vez terminado el proceso de failover, podremos visualizar como nuestro servidor se ha encendido en el Datacenter de Contingencia.

Servidor creado en Datacenter de Contingencia.

Por otro lado, el servidor sigue encendido en el Datacenter Principal.

En el Datacenter Principal, nuestro servidor de pruebas se mantiene encendido.

Por otro lado, en el Datacenter de Contingencia el disco independiente que visualizamos en el artículo anterior ya está asociado al server que se encuentra prendido en dicho Datacenter.

La búsqueda en el Datacenter de Contingencia del disco independiente asociado a nuestro servidor de pruebas no da resultados.

Se puede visualizar, además, en el Datacenter de Contingencia, las tareas asociadas al proceso de failover.

Tareas de creación del servidor de pruebas en el Datacenter de Contingencia. Registro de vCloud Director.

Tareas de eliminación del disco independiente, una vez que está asociado a la nueva máquina creada en el Datacenter de Contingencia.

Una vez terminado el proceso de failover, que para el caso del servidor de pruebas duró algunos segundos, se puede visualizar que, a nivel de tráfico de red, la cantidad de datos que se movieron de un Datacenter a otro fue irrelevante.

Visualización de la transferencia de archivos durante el proceso de failover.

En el caso de un escenario de Disaster Recovery real, el Datacenter Principal no está habilitado. Por ende, una vez que se restituye el servicio de dicho Datacenter y para preparar la vuelta a operaciones normales, se debe realizar la protección reversa, vale decir, habilitar el servicio de réplica, pero esta vez desde el Datacenter de Contingencia hacia el Datacenter Principal. Este aspecto lo revisaremos en el próximo artículo de esta serie. ¡Nos vemos!

Usando vCloud Availability para escenarios de Disaster Recovery (Parte 4)

En el artículo anterior revisamos el proceso de prueba de failover de un servidor utilizando vCloud Availability de VMware. A continuación, entraremos en tierra derecha analizando el proceso de failover y como se reflejan las actividades dentro de esta fase. Comencemos.

La situación previa al failover

Cuando realizamos la protección de nuestros servidores utilizando la herramienta vCloud Availability, lo que hacemos es crear una unidad de disco independiente que no queda asociada a máquina virtual alguna. Esta unidad se asocia a las réplicas que se realizan de cada servidor protegido; así podremos corroborar que, si no hemos aplicado failover a ningún servidor del Datacenter Principal, el Datacenter de Contingencia no tendrá máquinas encendidas, pero sí tendrá unidades de disco creadas según cuantas máquinas estemos protegiendo.

En el Datacenter Principal, tenemos 99 máquinas, de las cuales 89 están protegidas.

En el Datacenter de Contingencia, no hay servidores encendidos.

Sin embargo, en el Datacenter de Contingencia hay 89 discos independientes creados, los cuales están asociados a los 89 servidores protegidos.

Cuando creamos la protección hacia nuestro servidor de pruebas, vCloud Availability identifica la unidad de disco independiente que creó en el Datacenter de Contingencia. Esto podemos revisarlo haciendo clic en la sección Replication Tasks de la consola de administración de la herramienta.

Identificando el ID de Disco asociado al servidor de pruebas.

Esto lo podemos corroborar en el Datacenter de Contingencia, buscando los discos independientes por su ID.

Encontramos el disco independiente asociado a nuestro servidor de pruebas en el Datacenter de Contingencia.

Preparando el proceso de failover

Escribí este artículo al día siguiente de que establecí la protección del servidor de pruebas usando vCloud Availability. Esto lo hice para poder generar varios puntos de restauración y réplica durante la noche y así poder verificar que este trabajo se hizo adecuadamente para así realizar el failover más tarde.

Una vez ingresando en la consola principal de vCloud Availability, vamos a ir a la sección Outgoing Replications – To Cloud para buscar nuestro servidor y verificar el status del servicio de réplica.

Verificando el estado del servicio de réplicas para nuestro servidor de pruebas.

En el panel de control podremos corroborar rápidamente si nuestro servidor se encuentra en buen estado en cuanto a su servicio de réplicas, encontrando además información útil sobre el RPO, su última sincronización y el perfil de SLA que posee el mismo. Más abajo, podemos pinchar en Instances para visualizar el estado de la generación de instancias, en base a la política que definimos para el servidor al momento de crear la protección. Esta vista la podemos tener en formato lista o gráfico.

Vista de réplicas – Lista.

Vista de réplicas – Gráfica.

Como dato interesante, debido a la configuración del RPO, siempre se debe generar una réplica en un intervalo inferior al definido como RPO, lo cual pude corroborar dado que mientras sacaba las capturas de pantalla el sistema volvió a replicar.

Nueva réplica, 5 minutos después.

La visión de réplicas nos muestra gráficamente que cada 5 minutos aparece una nueva réplica, no persistente, que reemplaza la anterior, y adicionalmente a esto, cada 4 horas se genera una réplica persistente (o instancia), acorde a la configuración que aplicamos para la protección. Es momento entonces de ejecutar el proceso de failover. Y esto lo veremos en el siguiente artículo de esta serie. ¡No se lo pierdan!

Usando VCloud Availability para escenarios de Disaster Recovery (Parte 3)

En el artículo anterior revisamos el proceso de protección de un servidor utilizando vCloud Availability de VMware. A continuación, nos adentraremos en la siguiente fase del ciclo: el failover. Y para ello, utilizaremos una funcionalidad que posee vCloud Availability que se llama Test Failover. Comencemos.

Probando el failover sin afectar el servicio

En un proceso normal de failover, a partir del disco “oculto” en el Datacenter de Contingencia se crea un servidor de iguales características al original (manteniendo la configuración de disco, CPU, memoria y red), para posteriormente encenderlo y culminar el proceso.

Sin embargo, una estrategia atractiva utilizada para propósitos de troubleshooting o para realizar la primera prueba de un DRP es utilizar la opción de Test Failover de vCloud Availability. Esta opción permite levantar una copia de la máquina de origen en el Datacenter de Contingencia sin apagar el servidor original. Esto permite, por ejemplo, probar distintas instancias a fin de detectar cual de ellas no alcanzó a ser afectada por un malware y restablecer de manera definitiva el servidor afectado a partir de dicha instancia.

Por otro lado, la opción de Test Failover puede ayudar a realizar pruebas funcionales, aunque por lo general este proceso tiene limitantes a nivel de red. Esto porque al ser una copia del equipo replicado, conectar dicha máquina directamente a la red podría causar más de un conflicto.

Para realizar un test failover, debemos ubicar nuestro servidor en la consola principal de vCloud Availability y seleccionar la opción Test Failover.

Iniciando un proceso de Test Failover.

El asistente de este proceso es muy sencillo. En la primera opción podemos seleccionar si queremos o no encender la VM o si la queremos configurar a alguna red en particular. Una vez seleccionadas las opciones, damos clic en Next.

Configurando el test failover.

Posteriormente, debemos seleccionar la instancia de recuperación. Aquí aparecen dos opciones; la primera de ellas apunta a usar la última réplica existente (que debe estar dentro del rango de RPO configurado), o bien, utilizar una instancia anterior. Esto dependerá de la configuración de instancias que hayamos seleccionado cuando creamos la réplica para este servidor. El asistente, al seleccionar la segunda opción, muestra gráficamente las réplicas existentes, por lo que podemos seleccionar la que queramos utilizar.

Seleccionando la instancia para hacer el test.

Resumen del proceso.

El proceso de prueba del failover es por lo general bastante rápido y efectivo. Una vez completado, tendremos a nuestro servidor original en el Datacenter Principal funcionando de manera normal y una copia de dicho servidor en el Datacenter de Contingencia, el cual podremos abrir y revisar cuando estimemos conveniente. Una vez terminadas las pruebas, debemos seleccionar la opción Test Cleanup para borrar la máquina con la cual hicimos la prueba.

Realizando el cleanup para culminar el proceso.

Y esto es todo por hoy. En el siguiente artículo, haremos un failover, para medir tiempos, y estableceremos la protección reversa para asegurar la réplica desde el Datacenter de Contingencia hacia el Datacenter Principal. ¡Nos vemos!

Usando VCloud Availability para escenarios de Disaster Recovery (Parte 2)

En el artículo anterior describimos el proceso general de Disaster Recovery utilizando vCloud Availability de VMware. A continuación, nos adentraremos en las distintas fases del ciclo, para lo cual hemos montado en nuestro ambiente una máquina de pruebas con las siguientes especificaciones:

Especificación	Valor
Sistema Operativo	Windows Server 2012 R2 x64
Memoria RAM	2GB
CPU	1vCPU
Disco	50GB en una unidad

Especificaciones del servidor de pruebas.

Fase 1: Protección

En la primera fase del proceso, se debe habilitar el servicio de réplicas hacia el Datacenter de Contingencia. En esta etapa se definirán ciertos parámetros clave para el proceso, los cuales revisaremos en el paso a paso.

En la primera fase del proceso, se debe habilitar el servicio de réplicas hacia el Datacenter de Contingencia. En esta etapa se definirán ciertos parámetros clave para el proceso, los cuales revisaremos en el paso a paso.

Una vez que ya iniciamos sesión en la herramienta (que está previamente instalada tanto en el Datacenter Principal como en el de Contingencia, debemos ingresar a la sección Outgoing Replications. En esta sección aparecerán todos aquellos servidores para los cuales el servicio de réplica esté habilitado, tanto hacia otro Datacenter en la nube como hacia plataformas On-Premise. En este caso, utilizaremos la sección To Cloud y pincharemos All Actions, para luego dar clic en New Protection.

Configurando la protección en vCloud Availability.

Después de iniciar sesión con las credenciales de vCloud Availability en el Datacenter de Contingencia, en la ventana emergente, localizamos el servidor al cual habilitaremos la réplica, para luego hacer clic en Next.

Definiendo el servidor a replicar.

En la siguiente ventana, se deben configurar las políticas de storage y la organización de destino en donde se instalará el servicio de réplica. Una vez configurado esto, daremos clic en Next para pasar a la configuración medular de la réplica.

Definiendo Datacenter de Destino.

Definiendo política de storage.

El primer punto que configurar tiene relación con el RPO. El RPO o Recovery Point Objetive guarda relación con la cantidad de data que estamos dispuestos a perder en caso de existir un escenario de desastre. Esto cobra especial relevancia en los servidores transaccionales, que deberían apuntar a un RPO bastante pequeño a fin de que, en caso de una pérdida de servicio que obligue a un proceso de failover, disminuya la cantidad de transacciones perdidas o corruptas. En los servicios no transaccionales, se puede configurar un RPO mayor ya que no se espera que estos servidores sufran grandes cambios a nivel estructural en el tiempo.

Configuración de la protección.

RPO.

Ahora bien, la definición de RPO impacta directamente en la frecuencia de réplicas que tiene el servicio. Herramientas como vCloud Availability realizar réplicas similares a un backup incremental y su frecuencia dependerá directamente de la configuración del parámetro de RPO. Esto quiere decir que si configuro un RPO de 5 minutos, el sistema tiene como máximo 5 minutos entre réplicas, a fin de garantizar que en caso de que se tenga que aplicar un failover, la data recreada en el Datacenter de Contingencia tenga a lo sumo 5 minutos de antigüedad. Esta herramienta permite parametrizar el RPO en un rango que varía desde los 5 minutos hasta las 24 horas.

Otro punto relevante en la configuración del servicio de réplicas guarda relación con las instancias.

Configurando instancias.

El servicio de réplica, al realizarse de manera tan continua (podrían realizarse como máximo 288 réplicas diarias) podría impactar fuertemente en el uso de disco. Para evitar esto, el servicio está diseñado para mantener solamente la réplica más reciente como disponible, vale decir, cada réplica va “pisando” la anterior. Esta característica de diseño implica un riesgo inherente al servicio: si la máquina de origen por algún motivo queda corrupta (malware, borrado accidental de datos, etc.), en cosa de minutos será replicada al Datacenter de Contingencia en las mismas condiciones. Por este motivo, si el failover está motivado, por citar un ejemplo, en un evento de ramsonware, no solucionará el problema, sino que lo replicará al Datacenter de Contingencia. En estos casos y como una alternativa al uso de respaldos, es que el servicio de réplicas usa el concepto de instancias.

Las instancias son réplicas persistentes, y vCloud Availability permite almacenar hasta 24 instancias para tener puntos de restauración adicionales que permitan volver a un momento anterior al de la última réplica realizada. Esto permitiría recuperar equipos que han sido afectados a nivel de integridad de datos a un estado previo al evento. Además de configurar el número de instancias (desde 1 a 24) se puede configurar el tiempo en el cual se quieren distribuir estos puntos, lo que varía desde 1 día hasta 1 año. Así, si se configura una política de 24 instancias en 1 día, esto quiere decir que se generarán puntos de réplica persistentes cada 60 minutos.

Considerando que el proceso de protección generará una réplica inicial del total del disco del servidor a proteger, se ha añadido la alternativa de programar esta réplica inicial a una fecha y hora posterior, a fin de minimizar el impacto a nivel de redes que pueda ocasionar este proceso.

Configuración de primera réplica.

Finalmente, se puede configurar una exclusión de discos no necesarios para optimizar el proceso o usar una copia antigua de otras máquinas ya protegidas para reducir el tráfico de red. A esto último se le llama Seed VMs o Máquinas semilla.

Configuraciones adicionales.

Una vez que damos clic en Next, muestra un cuadro resumen de la configuración y podemos dar clic en Finish para terminar el proceso de protección.

Resumen de configuración.

Una vez que se inicia el proceso de configuración, vCloud Availability crea un objeto de disco en el Datacenter de Contingencia, el cual queda oculto y no queda asociado a ninguna máquina. Posterior a eso, se establece el proceso de réplica inicial, en el cual se envía en formato comprimido el disco utilizado al Datacenter de Contingencia. Para propósitos de esta prueba, el sistema se demoró cerca de 8 minutos en sincronizar aproximadamente 9,5 GB iniciales de Datos.

Estadísticas de flujo de datos en tiempo real durante la primera réplica.

Datos sobre las réplicas creadas.

Y ¡esto ha sido todo por hoy! El próximo artículo será para ahondar en el proceso de failover, pasando primero por la prueba de este. Nos vemos en otra ocasión.

Usando VCloud Availability para escenarios de Disaster Recovery (Parte 1)

Una de las estrategias de Disaster Recovery más utilizadas en los entornos de Datacenter virtualizados es el uso de herramientas de réplica de máquinas virtuales entre un Datacenter Principal y un Datacenter Secundario (o de Contingencia). Estas herramientas están continuamente replicando en segundo plano los cambios a nivel de configuración y contenido de los servidores hacia el segundo Datacenter, manteniendo los servidores en dicho Datacenter apagados hasta el momento en que sea necesario aplicar un proceso de Failover. En este sentido, las herramientas de réplica constituyen una estrategia de contingencia que, si bien es manual, es muy eficiente, dado que el proceso de Failover de un servidor puede resolverse en cosa de minutos.

En los siguientes artículos, revisaremos como funciona el proceso de Disaster Recovery usando una herramienta de réplica nativa de VMware: vCloud Availability.

Según indica VMware en su descripción de producto (https://www.vmware.com/cl/products/cloud-director-availability.html), vCloud Availability es una herramienta de tipo DRaaS (Disaster Recovery as a Service), la cual se ha diseñado para ofrecer diversos servicios de incorporación, migración y recuperación ante desastres a través de un proceso sencillo, seguro y rentable, entre Datacenters Virtuales (VDC).  Esta solución forma parte de la plataforma de proveedor de nube de VMware (VMware Cloud Provider Platform) y como tal se integra de forma nativa con VMware Cloud Director. Por otra parte y en cuanto a seguridad, que es un aspecto siempre relevante en este tipo de soluciones, los datos en reposo y en circulación asociados al servicio de réplica se encuentran cifrados, además de ofrecer compresión integrada del tráfico de replicación y cifrado TLS integral.

El proceso de Disaster Recovery utilizando vCloud Availability consiste en una serie de fases, que se describen en el siguiente diagrama y que serán analizados en los siguientes artículos:

Fases de un proceso de Disaster Recovery usando vCloud Availability.

• Protección. Corresponde a la fase inicial del proceso, en donde se establece la primera réplica del servidor desde el Datacenter Principal al Datacenter de Contingencia y se configura el servicio de réplica continua.
• Failover. Corresponde a la primera actividad propia de un proceso de Disaster Recovery. En esta fase, se activa el Servidor en el Datacenter de Contingencia usando una réplica disponible desde el Datacenter Principal. En caso de que el servidor en el Datacenter Principal aún estuviese encendido, en esta fase dicho servidor es apagado.
• Protección Reversa: Una vez que el servidor ya se encuentra operativo en el Datacenter de Contingencia, se debe habilitar el servicio de réplica en el sentido inverso, vale decir desde el Datacenter de Contingencia hacia el Datacenter Principal.
• Failback (Failover inverso). De manera similar al proceso de Failover, en esta fase de vuelta a operaciones normales se utiliza una réplica disponible desde el Datacenter de Contingencia para volver a habilitar el servidor en el Datacenter Principal.
• Reprotección: Una vez vuelto el servidor a operaciones normales, se habilita nuevamente el servicio de réplica hacia el Datacenter de Contingencia, cerrando el ciclo.

En el próximo artículo, revisaremos la primera fase de este proceso: La protección de los servidores.

¡Nos vemos!