Ayer, 4 de agosto de 2026, Microsoft anunció la disponibilidad general de la inmutabilidad automática para los backups de Azure SQL Database y Azure SQL Managed Instance. El anuncio ha pasado bastante desapercibido, quizá porque no incluye una nueva SKU ni un botón azul que diga «Proteger». Sin embargo, desde el punto de vista de seguridad y continuidad de negocio, me parece una de las mejoras más relevantes que ha recibido el servicio en bastante tiempo.
En el blog ya hablamos de backups inmutables y de cómo proteger las copias frente al ransomware. Allí expliqué por qué una copia accesible y modificable con las mismas credenciales que el resto de la infraestructura no es una última línea de defensa, sino otro objetivo esperando turno. Ahora Azure SQL incorpora esa protección directamente en su servicio administrado de backup.
La novedad merece atención, pero también aclarar ciertas cosas. Microsoft no ha convertido todos los backups históricos en objetos inmutables durante años. Lo que ha activado es una protección automática para los backups recientes de recuperación a un momento dado.
Qué ha anunciado Microsoft exactamente
Azure SQL protegerá con inmutabilidad hasta los siete días más recientes de backups utilizados para Point-in-Time Restore, tanto en Azure SQL Database como en Azure SQL Managed Instance. La protección se habilita de forma predeterminada, no requiere cuentas de almacenamiento, políticas WORM, bloqueos de retención ni procesos de exportación, y no tiene coste adicional. Se aplica con independencia del periodo PITR configurado.
Esto último conviene leerlo sin prisas. Si nuestra retención PITR es de siete días o menos, todos esos backups quedarán protegidos. Si tenemos 35 días, solo los siete más recientes serán inmutables con esta primera versión. Los otros 28 días seguirán retenidos, pero no reciben esta protección automática.
Otro detalle es que Microsoft presenta la funcionalidad como disponible de forma general, aunque el despliegue se está realizando progresivamente en todas las regiones y tardará unas semanas en completarse. De momento tampoco existe una propiedad visible que permita comprobar el estado de inmutabilidad, llegará más adelante. Azure SQL Database Hyperscale queda fuera por ahora.
Sí, has leído bien, disponibilidad general pero con despliegue pendiente y sin incluir indicador visible que nos diga si está o no activado. Así no se hacen las cosas, Microsoft, ¡así no!.
El valor de la medida se entiende mejor cuando dejamos de tratar el backup como una tarea de mantenimiento y lo consideramos un activo de seguridad.
Por qué la inmutabilidad cambia el escenario de seguridad
Un ransomware serio no se limita a cifrar la base de datos. Busca las copias, las consolas de administración, las cuentas privilegiadas y cualquier mecanismo que permita recuperar sin pagar. Si el atacante consigue borrar o alterar los puntos de restauración, el incidente puede convertirse en una pérdida definitiva de información.
La inmutabilidad introduce una barrera distinta al control de acceso tradicional. Un objeto protegido mediante un modelo WORM (Write Once Read Many) no puede modificarse ni eliminarse durante el periodo establecido. Esto reduce el impacto de unas credenciales administrativas comprometidas, de una automatización mal configurada o del operador que ejecuta una orden destructiva en el entorno equivocado porque todos los portales de Azure se parecen demasiado.
No sustituye al mínimo privilegio, a MFA, a la supervisión ni a las pruebas de restauración. Tampoco evita que un atacante robe información antes de cifrarla. Pero conserva puntos de recuperación recientes aunque alguien consiga capacidad administrativa suficiente para intentar eliminarlos. Esa diferencia, durante un incidente, es la autentica «resiliencia».
Hasta ahora, esa historia era muy distinta según utilizáramos Azure SQL Database o Azure SQL Managed Instance.
SQL Database ya tenía una vía; Managed Instance no
Azure SQL Database ya permitía configurar inmutabilidad sobre backups de Long-Term Retention. Podíamos aplicar una política temporal o un legal hold y bloquearla para impedir la modificación o eliminación de las copias durante el periodo correspondiente. Era una capacidad orientada principalmente a conservación prolongada, auditoría y cumplimiento.
Azure SQL Managed Instance, en cambio, no permitía (ni permite) configurar sus backups LTR como inmutables. Las copias de larga duración no podían modificarse, pero un usuario con permisos suficientes sí podía eliminarlas desde el portal, Azure CLI, PowerShell o la API REST. Microsoft documentaba como alternativa la creación de backups manuales `COPY_ONLY` y su almacenamiento en una cuenta propia de Azure Storage con una política de inmutabilidad.
La alternativa funcionaba, pero estaba lejos de ser transparente. Había que diseñar el almacenamiento, proteger el acceso, crear credenciales, programar los backups, supervisar los trabajos y controlar la retención. Porque crear una política de inmutabilidad que se puede desactivar con la misma cuenta comprometida es una forma especialmente sofisticada de no resolver nada.
Y todavía quedaba el detalle más incómodo: TDE.
Cómo había que hacerlo hasta ahora en Azure SQL Managed Instance
Azure SQL Managed Instance utiliza TDE de forma predeterminada. Cuando la base de datos está cifrada con una clave administrada por el servicio, no podemos generar un backup `COPY_ONLY`, porque la clave interna utilizada por Microsoft no se puede exportar. El backup se hace, si, pero luego no podría restaurarse fuera del flujo administrado del servicio, así que, podemos decir, que la operación no está soportada.
Para crear esas copias manuales teníamos que cambiar TDE y utilizar un protector administrado por el cliente, almacenado en Azure Key Vault o Managed HSM. Dicho de forma menos ceremonial, debíamos gestionar nuestra propia clave o certificado y conservar el material criptográfico necesario para restaurar. No bastaba con lanzar un `BACKUP DATABASE … WITH COPY_ONLY` y marcharnos satisfechos a actualizar el ticket.
Ese cambio añadía trabajo real. Había que configurar identidades y permisos sobre Key Vault, proteger la clave frente a borrados accidentales, definir su rotación, supervisar el acceso, documentar la recuperación y probar restauraciones. Una mala gestión del protector TDE puede dejar la base de datos inaccesible.
Después había que enviar el backup a Blob Storage y aplicar allí una política de inmutabilidad correctamente bloqueada. Era una solución válida para organizaciones que necesitaban ese control, pero suponía una sobrecarga notable si el objetivo era evitar que los backups recientes desaparecieran durante un ataque.
La nueva funcionalidad elimina buena parte de esa complejidad para la ventana de recuperación inmediata.
El cambio operativo real
Con la inmutabilidad automática, Microsoft protege los backups administrados que Azure SQL ya utiliza para PITR. No necesitamos extraer la base de datos, mantener un trabajo propio, configurar un contenedor inmutable ni modificar TDE para abandonar la clave administrada por el servicio. Los procedimientos actuales de backup y restauración continúan funcionando sin cambios.
Para Azure SQL Managed Instance esto resulta especialmente importante. Por primera vez contamos con una capa nativa de inmutabilidad sobre los puntos recientes de recuperación sin asumir la cadena operativa del backup manual. En un incidente de ransomware, disponer de hasta siete días protegidos puede permitirnos restaurar a un punto anterior incluso cuando las credenciales administrativas hayan quedado comprometidas.
La ventana, sin embargo, obliga a pensar. Si el atacante permanece dentro del entorno durante semanas antes de ejecutar la fase destructiva, siete días pueden no ser suficientes. Tampoco bastan cuando la organización exige conservar copias inmutables durante meses o años. La mejora protege la recuperación operativa inmediata, pero no sustituye una política completa de conservación.
Y aquí entramos en el terreno donde seguridad y cumplimiento suelen encontrarse, aunque a los DBAs esta parte siempre nos resulte muy aburrida.
Cumplimiento normativo: ayuda mucho, pero no firma la auditoría
Muchas empresas no implementan backups inmutables porque el DBA haya tenido una revelación durante la ventana de mantenimiento. Lo hacen porque una norma sectorial, una auditoría, una póliza de ciberseguro o una política corporativa exige conservar copias resistentes a manipulación y borrado.
Microsoft basa esta protección en las capacidades de almacenamiento inmutable de Azure Storage y cita escenarios relacionados con SEC 17a-4(f), CFTC 1.31(d) y requisitos de conservación de FINRA. Es un control técnico relevante para gobierno, resiliencia y auditoría, pero no convierte por sí solo a la empresa en conforme con ninguna regulación. Cada organización debe validar sus obligaciones con sus equipos legales y de cumplimiento.
El auditor no debería preguntar únicamente si el backup es inmutable. También preguntará cuánto tiempo se conserva, quién puede restaurarlo, dónde se almacena, qué evidencias demuestran la protección y cuándo se probó la última recuperación. Contestar «Azure lo hace solo» puede funcionar en una reunión comercial, pero en una auditoría seria no va a colar.
Además, la imposibilidad actual de consultar una propiedad que confirme la inmutabilidad puede complicar la evidencia durante el despliegue inicial. Conviene documentar el anuncio, la cobertura esperada y la fecha en la que Microsoft complete la activación en nuestra región.
La diferencia entre siete días de protección y una estrategia completa sigue siendo importante.
Lo que esta novedad todavía no resuelve
Azure SQL Managed Instance continúa sin permitir configurar la inmutabilidad de sus backups LTR. Una empresa que necesite conservar copias inmutables durante uno, cinco, años o cualquier periodo superior a 7 días, seguirá necesitando una solución adicional. A día de hoy, el patrón documentado continúa siendo el backup `COPY_ONLY` a Blob Storage inmutable, con todo lo que implica para TDE, claves, automatización y pruebas de restauración.
La protección automática tampoco cubre Azure SQL Database Hyperscale en esta primera versión. Ni evita la corrupción lógica ya presente en los backups, ni detecta cuándo comenzó un ataque. Un backup inmutable de una base de datos dañada sigue siendo un backup dañado, solo que ahora nadie puede borrarlo. La inmutabilidad protege la copia, las pruebas de restauración demuestran que sirve.
Tampoco debemos confundir inmutabilidad con aislamiento total. Seguimos necesitando identidades protegidas, alertas, registros de actividad, separación de funciones y procedimientos de respuesta. No podemos confiar toda la seguridad a una cuenta con rol Owner compartida por cuatro administradores.
La noticia cambia prioridades concretas y merece una revisión de nuestra arquitectura actual.
Qué haría yo a partir de ahora
Lo primero sería identificar qué bases de datos dependen exclusivamente de PITR y cuáles tienen requisitos de retención inmutable superiores a siete días. Para las primeras, esta funcionalidad reduce mucho el riesgo sin añadir trabajo. Para las segundas, debemos mantener la estrategia LTR correspondiente en Azure SQL Database o el mecanismo adicional implantado para Managed Instance.
También revisaría las instancias donde se cambió a TDE con clave administrada por el cliente únicamente para poder generar backups `COPY_ONLY` inmutables. La nueva protección puede permitir simplificar parte de esa arquitectura, pero no retiraría nada hasta confirmar que siete días cubren el riesgo y el cumplimiento aplicables. Cambiar el protector TDE porque ha aparecido una noticia interesante no es una tarea para hacer entre dos reuniones.
Por último, actualizaría la documentación de continuidad y los procedimientos de respuesta. El equipo debe saber qué periodo está protegido, cómo restaurar, qué ocurre con las copias anteriores y qué limitaciones siguen existiendo. La funcionalidad automática reduce operaciones, no elimina la necesidad de entenderlas.
La mejora es importante precisamente porque convierte una protección compleja en una capacidad predeterminada del servicio.
Conclusión
La inmutabilidad automática de los backups recientes refuerza de forma clara la seguridad de Azure SQL Database y, sobre todo, de Azure SQL Managed Instance. Protege hasta siete días de PITR sin coste adicional, sin políticas propias y sin obligarnos a modificar TDE para crear copias manuales.
No resuelve la retención inmutable de larga duración en Managed Instance ni sustituye una estrategia completa de recuperación. Pero cierra una carencia seria frente a ransomware, borrados malintencionados y credenciales comprometidas.
Ahora tenemos una última línea de defensa mejor. Toca documentarla, probarla y no estropearla creyendo que «automático» significa «no tengo que saber cómo funciona».
Enlaces de referencia:
https://learn.microsoft.com/es-es/azure/storage/blobs/immutable-storage-overview
