MSTech Geeks

Introducción

Durante años, uno de los mayores puntos débiles en identidad cloud ha sido claro: no existía una forma nativa de hacer backup y recovery de Microsoft Entra ID.

Podíamos auditar, monitorizar e incluso automatizar configuraciones… pero no podíamos restaurar el estado de nuestro tenant ante un incidente grave.

Esto empieza a cambiar.

Con la llegada de Microsoft Entra ID Backup & Recovery (preview), Microsoft introduce por primera vez una capacidad orientada a mejorar la resiliencia de la identidad frente a errores operativos, configuraciones erróneas o incluso ataques.

¿Qué problema viene a resolver?

Hasta ahora, los escenarios podrían ser bastante complejos, como, por ejemplo:

• Eliminación accidental de objetos críticos (apps, grupos, SPNs…)
• Cambios masivos incorrectos en Conditional Access
• Configuraciones comprometidas tras un ataque
• Dificultad para volver a un estado conocido y seguro

Aunque existían mecanismos como soft delete (usuarios, grupos), cierto versionado parcial en algunos recursos o incluso exportaciones manuales vía Microsoft Graph, la realidad es que no disponíamos de un modelo estructurado que permitiera recuperar de forma controlada el estado de configuración del tenant.

¿Qué es Microsoft Entra ID Backup & Recovery?

Es una nueva capacidad, todavía en “Preview”, que nos permite lo siguiente:

• Capturar el estado de configuración del tenant: crea copias de seguridad automáticamente, sin intervención del administrador, una vez al día, con una retención de 5 días. Podemos consultar dichas copias de seguridad en el panel de Microsoft Entra Id.

• Comparar cambios a lo largo del tiempo: gracias a su generador de informes de diferencias, podemos comparar el estado actual del tenant con la copia de seguridad mediante dicho informe.

• Restaurar configuraciones críticas: podemos elegir recuperar todos los objetos o seleccionar aquellos objetos por tipo o identificador a restaurar.

El enfoque no es un “backup clásico” tipo snapshot completo, como haríamos con una máquina virtual en Azure, sino que se acerca más a un modelo de configuración como estado recuperable. Es decir, se guarda el estado de los objetos clave de Entra ID para poder volver atrás en caso necesario.

Pongamos un ejemplo. Imaginemos que tenemos una directiva de acceso condicional que bloquea la autenticación heredada y aplica a todas las aplicaciones críticas. Un administrador excluye un grupo sin darse cuenta o modifica algún parámetro relevante de la directiva. Con este tipo de backup, no restauramos todo Entra ID, sino únicamente el estado de esa política concreta, devolviéndola a su configuración original. Otro escenario donde esta característica puede brillar de verdad es en el conocido “configuration drift”, muy habitual en entornos grandes con muchos objetos y múltiples administradores. Poco a poco, sin que nadie lo perciba, se van introduciendo pequeños cambios: excepciones, relajación de controles o ajustes puntuales que acaban alejando la configuración del estado inicial.

¿Qué tipo de objetos y propiedades cubre?

Aunque la característica está todavía en versión preliminar y presenta un alcance limitado, se prevé que evolucione progresivamente. En su estado actual, se centra en elementos clave de identidad como:

• Usuarios.
• Grupos.
• Directivas de acceso condicional.
• Directivas de ubicación con nombre.
• Directivas de autorización.
• Directivas de método de autenticación.
• Aplicaciones.
• Entidad principal de servicio.
• Organización.

Limitaciones a tener en cuenta

Como cualquier funcionalidad en fase preliminar, Microsoft Entra ID Backup & Recovery presenta actualmente ciertas limitaciones que conviene entender antes de incorporarlo como parte de la estrategia de resiliencia.

En primer lugar, es importante destacar que no permite recuperar objetos eliminados de forma permanente. La capacidad de recuperación se limita a objetos modificados o eliminados dentro del periodo de soft delete. Esto implica que, ante eliminaciones definitivas, seguirá siendo necesario contar con mecanismos adicionales de protección o procesos operativos bien definidos.

En entornos híbridos, la limitación es aún más relevante. Los objetos sincronizados desde Active Directory on-premises no pueden restaurarse desde Entra ID, ya que su origen de autoridad permanece en el entorno local. Aunque estos objetos pueden aparecer en los análisis de cambios, cualquier recuperación debe realizarse en el directorio on-premises. Otro aspecto clave es que la recuperación no siempre es completa, sino que se limita a las propiedades soportadas de cada objeto. Es decir, no estamos ante una restauración íntegra, sino ante una recuperación selectiva del estado de configuración.

Además, el proceso de recuperación no es inmediato. Dependiendo del tamaño del tenant y del volumen de cambios, los tiempos pueden variar, especialmente durante la fase inicial de carga y procesamiento de datos.

También hay que tener en cuenta que existen dependencias entre objetos, lo que puede afectar a la granularidad de la recuperación. En algunos casos, los elementos no pueden restaurarse de forma completamente independiente, ya que forman parte de configuraciones más amplias.

Por último, y probablemente lo más importante, esta funcionalidad no sustituye una estrategia completa de gobierno y seguridad. Debe entenderse como una capa adicional dentro de un modelo más amplio que incluya control de cambios, automatización, auditoría y buenas prácticas de configuración.

¿Cómo funciona conceptualmente?

Microsoft Entra ID Backup & Recovery no introduce un modelo de backup tradicional, sino un enfoque orientado a la recuperación del estado de configuración del tenant.

En esencia, y por lo que se deduce de la documentación oficial, la plataforma trabaja sobre el estado de los objetos clave de identidad —como usuarios, grupos, aplicaciones o políticas— a lo largo del tiempo. Esto permite no solo preservar configuraciones, sino también analizar su evolución y detectar cambios relevantes.

A partir de ahí, el servicio permite identificar modificaciones y, en caso necesario, recuperar configuraciones a un punto anterior considerado válido (“previously known good state”), facilitando la vuelta a un estado seguro tras errores operativos o incidentes de seguridad.

Es importante destacar que este proceso no implica la restauración completa del tenant, sino una recuperación granular y selectiva, centrada en objetos y propiedades concretas. Este enfoque permite actuar de forma precisa sobre los elementos afectados, reduciendo el impacto y el tiempo de recuperación.

En conjunto, Microsoft introduce un modelo más cercano a la gestión de configuración que a un backup clásico, donde el foco no está en restaurar todo, sino en recuperar aquello que ha cambiado y que compromete el estado esperado del entorno.

Casos de usos reales

Como hemos venido diciendo a lo largo del post, esta funcionalidad tiene mucho más impacto del que parece:

• Error humano: un administrador modifica una directiva crítica de acceso condicional y bloque accesos. Restauramos nuestra configuración previa.
• Ataque o compromiso: un atacante, tras una escalada de privilegios, modifica aplicaciones, añade credenciales o cambia políticas. ¡Podemos identificar cambios y revertirlos!
• Drift de configuración: cambios acumulativos no controlados en el tiempo. Comparamos estados y volvemos a nuestra línea base.

Ejemplo de caso de uso

Supongamos que un administrador, por error, elimina a varios usuarios de un grupo de seguridad en Entra ID.

A los pocos minutos, los usuarios comienzan a contactar con el departamento de IT indicando que han perdido acceso a su buzón de correo. Esto ocurre porque dicho grupo se utiliza para la asignación de licencias de Microsoft 365 y, por tanto, para el aprovisionamiento de los buzones.

Ante este escenario, el proceso de recuperación sería el siguiente:

• Generar un informe de direferencias, seleccionando un estado previo cuya configuración era correcta:

• Analizar el informe de diferencias para identificar las modificaciones realizadas sobre el grupo:

• Iniciar el proceso de recuperación, seleccionando la opción: “Recover only specific objects by their ID”

• Introducir el Object ID del grupo, disponible en el propio informe, y añadirlo al proceso de recuperación:

• Por último, ejecutar la recuperación.

La recuperación en este caso ha sido casi instantánea:

Observación importante: Durante las pruebas, también intenté recuperar el secreto de un Service Principal. Aunque el informe de diferencias detectó correctamente el cambio tras su eliminación, el proceso de recuperación no pudo completarse con éxito. Esto indica que no todos los atributos están actualmente soportados, algo coherente con las limitaciones existentes en esta fase preliminar.

Conclusión

Microsoft Entra ID Backup & Recovery supone un paso relevante en la evolución de la identidad en la nube, pero conviene entender bien qué es… y qué no es.

No estamos ante un mecanismo de recuperación total del tenant ni ante un sustituto de las capacidades tradicionales de backup o disaster recovery. Tampoco reemplaza a las herramientas de detección o análisis forense. Sin embargo, introduce algo que hasta ahora no existía de forma nativa: la posibilidad de recuperar de forma estructurada el estado de configuración de la identidad.

Este cambio, aunque todavía limitado en su versión preliminar, tiene implicaciones importantes. La identidad deja de ser un plano difícilmente recuperable y pasa a tratarse como un conjunto de configuraciones que pueden analizarse, compararse y revertirse de forma controlada.

En la práctica, esto reduce significativamente el impacto de errores operativos, cambios no deseados o configuraciones alteradas tras un incidente de seguridad. No elimina la necesidad de gobierno, automatización o monitorización, pero sí añade una capa clave: la capacidad de recuperación.

La clave estará en su evolución. Si Microsoft amplía el alcance, mejora la cobertura de objetos y reduce las limitaciones actuales, podríamos estar ante el inicio de un modelo más maduro de resiliencia en identidad.