Dentro de nuestro rol como consultores o arquitectos, debatimos a menudo con nuestros clientes o interesados, sobre si es conveniente migrar el contenido a la nube, desde el punto de vista de la seguridad e integridad de los datos. Las opiniones son de todo tipo, pero lo más habitual es encontrarnos con bastante desconocimiento acerca de qué grado de protección tienen nuestros datos en los sistemas en la nube de Microsoft.
En este post vamos a centrarnos en un aspecto especialmente desconocido, como es la disponibilidad y seguridad de los datos de Dynamics 365, concretamente de la versión mas extendida del servicio que es la versión cloud, tanto de D365 basado en Power Platform como D365 F&O, sin aplicar a versiones on-premise.
Toda organización dispone de una serie de sistemas de información que se pueden catalogar de acuerdo con su criticidad a la hora de soportar el negocio. La organización dispondrá de un plan de recuperación ante desastres, que detalla los mecanismos disponibles para cada sistema, alineado con las necesidades del negocio, el presupuesto disponible para ponerlo en marcha y mantenerlo operativo a lo largo del tiempo.
Los planes de DR se evalúan de acuerdo con 3 parámetros:
RTO, o Recovery Time Objective, es el tiempo máximo tolerable durante el que un sistema puede no estar disponible. Por ejemplo, un RTO de 60 minutos significa que si el sistema se cae a las 9 am , para cumplir el RTO debería estar operativo de nuevo antes de las 10.
RPO, o Recovery Point Objective, es la cantidad de perdida de datos tolerable por la organización, en tiempo, desde la aparición de un problema de cualquier tipo, hasta el primer punto de recuperación válido.
Finalmente, un último concepto, relacionado con los dos anteriores, y que determina el nivel de servicio al que se compromete un proveedor de servicios en el que externalizamos nuestros sistemas, se denomina SLA o Service Level Agreement, y determina el tiempo mínimo mensual / anual, al que se compromete contractualmente el proveedor para que el sistema esté disponible.
El plan debe cubrir los distintos escenarios que puedan producirse y deriven en una no disponibilidad del sistema, comprendiendo tanto fallos relativos a la disponibilidad de la infraestructura como de la propia integridad de los datos.
Teniendo claros estos conceptos sobre seguridad, veamos ahora de qué mecanismos disponemos en Dynamics 365 para dar respuesta a estos parámetros.
Todos los sistemas de información que dan soporte a Dynamics 365 (CE, F&O) se hospedan en Azure. Azure, como servicio, está diseñado para que todos los datos estén replicados en un mínimo de 3 instancias físicas, pero hay diferencias en función del tipo de entorno y su disponibilidad ante situaciones de este tipo.
Los entornos de producción son replicados a tiempo real en una región secundaria, conocida como replica geo-secundaria, o lo que es lo mismo, GRS.
Esto implica que de entrada disponemos de tolerancia ante fallos de hardware gracias a esta configuración triple.
Si se produce una interrupción del servicio que afecte a la totalidad del centro de datos de la región primaria, los entornos de producción cambiarán al centro de datos ubicado en la región secundaria. En caso de no haber perdida de datos (RPO), no habría necesidad de intervenir, y el criterio para realizar este cambio sería discrecional por parte de Microsoft. Por el contrario, si existiese pérdida de datos a consecuencia del failover, se requeriríade nuestra autorización para proceder, siendo la alternativa esperar a recuperar el servicio en la región primaria.
Los entornos no productivos (sandbox, teams, trial, etc) tienen replicación local (ZRS o LRS, Microsoft no especifica cuál de las dos) y por tanto estarían inoperativos durante la duración de la interrupción de servicio regional.
Microsoft gestiona y declara las emergencias de servicio a través del centro de administración de Microsoft 365.
Como consecuencia podemos estimar que las políticas de Microsoft nos garantizan:
RTO menor a 60 minutos (estimado)
RTO menor a 15 minutos (estimado)
SLA mensual del 99,9% (contractual)
Mas allá de cuestiones de disponibilidad de la infraestructura y tolerancia a fallos hardware, puede ser que un error propio, de un colaborador, o cualquier otro motivo que afecte a la integridad de los datos, nos llevara a la necesidad de volver a un estado anterior de la base de datos.
En Dynamics 365 F&O basado en LCS disponemos de la funcionalidad PITR por la que podemos restaurar la BBDD de Azure SQL a cualquier momento anterior en el tiempo:
Conviene recordar que el alojamiento de entornos en LCS está en vías de deprecación, por lo que todos los entornos de Dyn365 pasarán a gestionarse a través de Power Platform. Ahora veremos cómo funcionarán.
Así pues, para Dynamics 365 CE / Power Platform y en todos los nuevos entornos de D365 FO desplegados en este entorno, se funcionará de forma ligeramente distinta. En este caso, no disponemos exactamente de PITR, sino que podemos restaurar a cualquier momento en el tiempo, pero en intervalos de 30 minutos. La retención funciona según se especifica en este cuadro:
Por contra, a diferencia de lo que sucedía en LCS, tenemos la posibilidad de realizar backups manuales a petición, por ejemplo antes de alguna actuación importante, los cuales se conservan con la misma retención indicada en la imagen anterior.
Cabe destacar que en caso de restaurar un entorno que disponga de BBDD de Dataverse y de FO, se restaurarán ambas, así como el código asociado a las mismas.
A tenor de todo esto podríamos afirmar que el RPO sería para cada caso
Ante este escenario no aplica el RTO ni el SLA porque hablamos de restauraciones 'manuales' y por lo tanto no dependen de la disponibilidad del sistema como tal.
A tener en cuenta, que en ambos casos restaurar una copia de seguridad, rompe la cadena de copias, es decir que la retención empieza a contar de 0 desde el momento en que se ejecuta la copia. Por eso, se recomienda valorar el volcar los datos a otro entorno antes de proceder.
Dynamics 365 pone a nuestra disposición mecanismos de protección de los datos de grado empresarial, que hacen altamente improbable un escenario importante de pérdida de datos, tanto por fallo hardware como por indisponibilidad o por error humano.
Si estos mecanismos son suficientes para cumplir con los planes y políticas de disaster recovery, ya será una decisión del negocio, teniendo en cuenta los parámetros técnicos anteriormente mencionados.
En todo caso, esperamos haberte ayudado a aclarar los conceptos para poder abrir este debate en tu organización con todos los datos encima de al mesa. Si necesitas más información o crees que podemos ayudarte, no dudes en contactar con nosotros.
Referencias:
➡️ Documentación oficial de Microsoft
