Tu backup inmutable tiene un permiso que lo borra

«Nuestras copias son inmutables.» Con esa frase se cierran muchas reuniones de seguridad, y es una frase incompleta. Inmutable no es una propiedad del producto: es un modo de retención, un plazo y una lista de quién puede saltárselo. Cambia cualquiera de los tres y la misma palabra describe dos situaciones distintas.

Todo lo que sigue está en la documentación pública de los fabricantes. En Amazon S3, la misma función —Object Lock— ofrece dos modos. En uno no puede borrar ni el usuario raíz de la cuenta. En el otro puede borrar cualquiera que tenga un permiso concreto, y la consola web de AWS manda por defecto la cabecera que hace falta para saltárselo. Los dos se llaman inmutabilidad. Los dos salen igual de verdes en el informe mensual.

El 93 % lo pide, el 16 % dice tenerlo

El 1 de septiembre se publicó un estudio de Omdia con una cifra que ha circulado mucho: el 93 % de los responsables encuestados considera que la inmutabilidad absoluta del almacenamiento de copias es un requisito crítico frente al ransomware, y solo el 16 % dice que su entorno actual cumple ese estándar. Hay otra cifra en el mismo estudio que nos parece más interesante y que se ha quedado fuera de los titulares: el 89 % dice que las afirmaciones de inmutabilidad de un fabricante no se pueden dar por buenas sin validación de un tercero.

Antes de usar esos números, dos avisos que el estudio merece. El primero: lo encarga y lo paga Object First, que vende precisamente un aparato de almacenamiento inmutable, y que Veeam compró en enero de 2026. Eso no convierte las respuestas en falsas —el trabajo de campo lo hace Omdia—, pero sí condiciona qué se pregunta y qué titular se destaca. El segundo aviso importa más para ti: la muestra son 700 personas de organizaciones de 1.000 a 9.999 empleados en Estados Unidos, Reino Unido, Irlanda, Francia y la región DACH, entrevistadas entre finales de febrero y finales de marzo de 2026. Ni una pyme española. Si tu empresa tiene cuarenta personas, ese 16 % no describe tu casa.

Lo que sí se traslada es la forma del hueco: la distancia entre lo que la gente cree tener y lo que tiene configurado. Y esa distancia no se cierra comprando nada. Se cierra leyendo tres cosas que ya están escritas en algún sitio: el modo, el plazo y quién tiene la excepción.

Dos modos que en la conversación se llaman igual

Amazon S3 Object Lock es el mecanismo sobre el que se apoyan casi todos los productos de copia que hablan S3, así que vale la pena leer su documentación con calma. Hay dos modos de retención y la diferencia no es de grado:

Ese requisito de cabecera suena a fricción deliberada: hay que pedirlo aparte, a mano, adrede. Pero la propia documentación de AWS añade una nota que lo desactiva en el caso más común. Literalmente: «por defecto, la consola de Amazon S3 incluye la cabecera x-amz-bypass-governance-retention:true. Si intentas borrar objetos protegidos por el modo governance y tienes el permiso s3:BypassGovernanceRetention, la operación tendrá éxito».

O sea que si esa identidad tiene el permiso y alguien entra por la consola web y pulsa borrar, se borra. Sin cabecera manual, sin aviso especial, sin un diálogo distinto del de cualquier otro fichero. La fricción existe en la API y desaparece en la interfaz por la que se hace casi todo a las tres de la tarde de un viernes.

Governance está bien diseñado y hace lo que promete. AWS lo recomienda explícitamente para probar plazos de retención antes de comprometerse con compliance, y para los casos en que alguien tiene que poder rectificar. Lo que se rompe está antes: el modo de pruebas y el modo definitivo se llaman igual en la reunión y solo se distinguen en la configuración.

Tres detalles más de la misma página, y el primero es el que más gente cuenta mal. El plazo de retención lo puede alargar siempre cualquiera con s3:PutObjectRetention; acortarlo solo es posible en governance y con el permiso de excepción —la cabecera de bypass está en la firma de esa misma llamada—, mientras que en compliance no se puede nunca. Segundo: la retención legal, que bloquea sin fecha de caducidad, «la puede poner y quitar libremente cualquier usuario que tenga el permiso s3:PutObjectLegalHold». Y tercero, el que casi nadie menciona: existe una retención variable con retención por evento que AWS recomienda literalmente «cuando quieres una ventana de recuperación configurable frente al ransomware o al borrado accidental», y que fija la fecha al soltar el bloqueo.

El modo que sí aguanta también tiene factura

La tentación, leído lo anterior, es poner todo en compliance y dormir tranquilo. Conviene saber qué se firma. En ese modo, si te equivocas al fijar la retención, pagas ese almacenamiento hasta el final: no hay forma de acortar el plazo ni de liberar espacio. Y el radio de explosión se muda de sitio: la única palanca que queda para destruir esos datos antes de tiempo es cerrar la cuenta. Tus copias dejan de depender de las credenciales del servidor de backup y pasan a depender de que nadie toque —ni pierda, ni deje de pagar— la cuenta que las aloja.

Lo escribimos nosotros en julio, a cuenta del borrado del registro de la propiedad rumano: diseña el backup asumiendo que el atacante ya tiene las credenciales de administrador. Esa frase está bien y se queda corta, y por eso volvemos sobre ella. Decir «inmutabilidad» ahí es el principio de la conversación, no el final. El aviso conjunto sobre Gunra que comentamos en agosto describe a unos atacantes que borraron los datos de copia del centro principal y del de recuperación, antes y después de cifrar. Contra ese guion, un repositorio en governance con el permiso de bypass repartido en el mismo dominio que acaban de comprometer se convierte en un paso más de su lista.

La comprobación obvia devuelve la respuesta equivocada

Supongamos que quieres comprobarlo tú mismo, que es exactamente lo que pide ese 89 % que no se fía de la palabra del fabricante. La prueba intuitiva es intentar borrar un objeto y ver si te deja. Pues resulta que esa prueba miente, y lo dice la propia documentación: si lanzas un borrado simple, sin indicar el identificador de versión, S3 responde 200 OK y coloca un marcador de borrado encima. El objeto sigue ahí, intacto y protegido, pero la respuesta que has visto es la de un borrado correcto.

El error se comete en las dos direcciones. Quien hace la prueba se va convencido de que la inmutabilidad no funciona y abre un ticket que no hace falta. Y el atacante que borra así se va convencido de lo contrario. Con la versión indicada sí hay respuesta útil: un borrado permanente contra una versión protegida devuelve 403 Forbidden. Ahora bien, ese 403 confirma que hay un candado y no dice de qué clase es —lo devuelve igual un objeto en compliance que uno en governance probado por alguien sin el permiso de excepción—. El modo no se deduce de un borrado: se lee con get-object-retention y get-object-lock-configuration.

Y una condición previa que se cae por su propio peso pero se olvida: Object Lock solo funciona en buckets con versionado activado. Sin versionado no hay retención que valga, porque no llega a existir.

El plazo de tu política tampoco es el plazo real

El tercer parámetro es el plazo. Veeam aplica a los repositorios de objetos un mecanismo llamado block generation: agrupa los bloques escritos en una misma ventana para que compartan fecha de caducidad, de modo que no haga falta reescribir el bloqueo de los bloques viejos cada noche. El motivo es de coste —menos llamadas a la API, menos tráfico— y el efecto es que ese periodo se suma al que tú configuraste. En la documentación de su agente para Windows son 30 días en Amazon S3 y Google Cloud Storage y 10 días en el resto de almacenamientos de objetos; la lista cambia según el producto y el proveedor, así que el número que te toca a ti hay que mirarlo en tu versión y no en este párrafo.

Con esos valores, pones 30 días de inmutabilidad en S3 y lo que hay escrito en el objeto son 60: más protección de la que pediste y también más almacenamiento del que presupuestaste, durante el doble de tiempo. El número que escribiste en la política no es el número que hay en el objeto, y aquí la diferencia juega a tu favor. No siempre lo hace.

¿Y la copia de Microsoft 365 dónde aterriza?

Ya contamos que la copia nativa de Microsoft 365 nunca sale de Microsoft, que es una limitación de diseño y no un descuido. Cuando contratas una copia de verdad de un tercero, esos datos acaban escritos en algún sitio, y ese sitio suele ser un almacenamiento de objetos con los mismos tres mandos: modo, plazo y permisos.

La conversación de compra, en cambio, se queda un paso antes. Se habla de retención —siete años suena bien, aunque esa cifra no sale del RGPD, que no fija plazos y obliga justo a lo contrario, sino de normativa mercantil y fiscal— y no se habla de modo. Son cosas distintas: la retención dice cuánto tiempo se guarda; el modo dice quién puede acortar ese tiempo. En una copia de Microsoft 365, el modo y el plazo tienen que estar escritos en la entrega junto con la retención. Si no lo están, la palabra «inmutable» del contrato no se puede verificar.

La frase que tiene que poder terminar quien lleva tus copias

No hace falta una auditoría ni una herramienta. Hace falta una frase con cuatro huecos. Pídesela a quien opera tus copias —tu equipo, tu proveedor, nosotros si somos nosotros— y escucha cuánto tarda:

Si tarda más de un minuto, ya tienes el resultado. No porque sea mal profesional: porque esos cuatro datos viven en cuatro sitios distintos —la política del producto de copia, la configuración del bucket, la política IAM y el gestor de credenciales— y casi nunca se han mirado juntos. El último hueco es el que más gente se salta, y es el que decide todo: si esas credenciales viven en el mismo directorio que el resto de la empresa, el atacante que tiene el directorio tiene también el permiso de bypass.

Cuándo esto no va contigo

Un post que empieza hablando de un estudio patrocinado por un fabricante de aparatos inmutables debería acabar diciéndote que compres uno. No vamos a hacer eso. Si tus copias terminan en una cinta que alguien saca de la unidad y guarda en un armario, tienes inmutabilidad absoluta y no te ha costado ni una licencia ni una política IAM: un objeto que no está conectado a nada no se borra por red. Es incómodo, es lento de restaurar y hay que acordarse de sacarlo; también es el único modo que no tiene una casilla que lo desactive.

Y decimos esto sabiendo de qué lado cobramos: vendemos copias gestionadas y recuperación ante desastres, así que un post titulado «tus copias no son lo que crees» nos conviene. Por eso el contrapeso: si puedes terminar la frase de ahí arriba sin consultar a nadie, la parte difícil ya está hecha y no necesitas contratar nada. El problema lo tiene quien descubre el modo del bucket el día que va a restaurar.

Lo que no afirmamos

Fuentes (verificadas el 29 de septiembre de 2026): modos de retención compliance y governance, permiso s3:BypassGovernanceRetention, la nota sobre la cabecera que la consola incluye por defecto, la retención variable con retención por evento recomendada frente al ransomware, la retención legal con s3:PutObjectLegalHold, la regla de que el plazo solo se puede acortar en governance y con el permiso de excepción, el requisito de versionado y el comportamiento del borrado simple (200 OK más marcador) frente al permanente (403) — documentación de Amazon S3, «Locking objects with Object Lock»; periodo de block generation de 30 días en Amazon S3 y Google Cloud Storage y de 10 días en el resto de almacenamientos de objetos, y su motivo declarado (reducir peticiones, tráfico y coste) — documentación de Veeam para el agente de Windows, «Block Generation»; cifras del estudio (93 % / 16 %, 89 % que exige validación de terceros) — nota del estudio de Omdia patrocinado por Object First (01-09-2026), con la metodología (700 encuestados, organizaciones de 1.000 a 9.999 empleados en EE. UU., Reino Unido, Irlanda, Francia y DACH, trabajo de campo entre el 26 de febrero y el 25 de marzo de 2026) recogida en Compare the Cloud; adquisición de Object First por Veeam, confirmada el 14 de enero de 2026, y fundación de la compañía en 2022 por Ratmir Timashev y Andrei Baronov — Blocks & Files.