Casi todas las propuestas de almacenamiento de backup llevan ya la palabra inmutable en la primera página. Detrás de esa palabra hay normalmente un mecanismo concreto, S3 Object Lock, y detrás de ese mecanismo hay un conjunto de garantías más estrecho y preciso de lo que sugiere el atajo. Los equipos que saben exactamente qué está bloqueado, por quién y durante cuánto tiempo tienden a recuperarse del ransomware; los equipos que asumen que “inmutable” significa “seguro” descubren a veces la diferencia durante un incidente.
Esto importa porque los atacantes se han adaptado. Cifrar los datos de producción es la mitad de una operación de ransomware moderna; la otra mitad es destruir primero los backups para que la víctima no tenga otra alternativa que pagar. Object lock existe para hacer fracasar ese segundo paso. Lo hace de forma fiable cuando está configurado correctamente y no hace absolutamente nada cuando no lo está. Este artículo define object lock con precisión, cubre los tres modos, explica por qué las ventanas de retención son el punto débil más habitual, describe cómo lo utilizan las aplicaciones de backup y termina con una lista de comprobación.
S3 Object Lock es un control de escritura única y lectura múltiple (WORM) que el sistema de almacenamiento aplica a versiones individuales de objetos. Cuando una versión está bloqueada, ninguna llamada a la API puede eliminarla ni sobrescribirla hasta que expira su periodo de retención. Esa frase contiene cuatro matices, y cada uno importa.
Object lock se habilita a nivel de bucket, pero el bloqueo en sí es una propiedad de cada versión de objeto. Un bucket con object lock habilitado puede seguir conteniendo versiones sin bloquear si quien escribió no solicitó retención y el bucket no tiene una retención por defecto. Habilitar la función es un requisito previo, no la protección.
Una versión bloqueada puede leerse tantas veces como sea necesario y copiarse o replicarse a otro lugar. Un PUT sobre la misma clave crea una nueva versión en lugar de modificar la antigua. Lo que object lock impide es la eliminación o sustitución de la versión existente; los datos antiguos siguen siendo legibles con independencia de lo que se escriba después.
Todo bloqueo tiene una marca temporal de “retener hasta” (retain until). Antes de esa fecha, la eliminación se rechaza. Después, la versión se convierte en un objeto ordinario que las reglas de ciclo de vida o la aplicación de backup pueden limpiar. La retención puede ampliarse en una versión existente pero, en modo compliance, nunca acortarse.
Este matiz es el que da valor a object lock. El servidor de backup, su base de datos, su cuenta de servicio y todos los administradores que pueden iniciar sesión en él están fuera del perímetro de aplicación. Si todos ellos están comprometidos, la capa de almacenamiento sigue rechazando la eliminación porque la decisión se toma contra los propios metadatos del objeto. Una protección aplicada por la aplicación que el atacante ya ha tomado no es una protección.
La lista de cosas que object lock no hace es más larga que la lista de cosas que hace. Ninguna de las siguientes es un defecto de la función; son límites, y la mayoría de los fallos reales caen en uno de ellos.
S3 define dos modos de retención y un indicador independiente. Se comportan de forma distinta bajo ataque, por lo que la elección merece más reflexión que aceptar un valor por defecto.
| Control | Quién puede retirarlo o acortarlo | Cómo expira | Uso típico |
|---|---|---|---|
| Modo compliance | Ninguna identidad, incluido el propietario de la cuenta. | Únicamente en la fecha de retención. La retención puede ampliarse, nunca reducirse. | Copias de recuperación frente a ransomware, retención regulada, cualquier copia que deba sobrevivir a un administrador comprometido. |
| Modo governance | Cualquier identidad con el permiso de bypass. | En la fecha de retención, o antes mediante bypass. | Protección frente a accidentes y usos indebidos ordinarios cuando es aceptable una vía de escape controlada. |
| Retención legal (legal hold) | Cualquier identidad con el permiso de retención legal. | Nunca por sí sola; permanece hasta que se retira explícitamente. | Retenciones por litigio o investigación superpuestas a cualquiera de los dos modos; no es un control frente a ransomware por sí misma. |
Para los repositorios de backup cuyo propósito es sobrevivir a una brecha, el modo compliance es el valor por defecto adecuado. El modo governance se elige a menudo porque conservar una salida parece más seguro, pero esa salida es exactamente lo que utilizará un atacante con credenciales robadas. Si una vía de escape en modo governance es realmente necesaria, el permiso de bypass debería pertenecer a una identidad que nunca se utilice para el trabajo rutinario y esté protegida por una autenticación multifactor robusta.
Un bloqueo que expira antes de que alguien advierta la brecha no protege nada. La duración de la retención es una decisión de seguridad, no de capacidad, y debe fijarse en función del tiempo previsto entre el compromiso inicial y la detección, lo que suele denominarse tiempo de permanencia del atacante (dwell time).
Supongamos que una organización establece un periodo de inmutabilidad de siete días porque coincide con su ciclo de backup y mantiene la capacidad predecible. Supongamos que un atacante consigue un punto de apoyo el día uno, pasa tres semanas recolectando credenciales y desencadena el cifrado el día veintidós. Todos los backups escritos antes del día quince han salido ya de su ventana de retención y pueden ser eliminados por cualquiera que posea las credenciales del servicio de backup. Los únicos puntos de restauración inmutables son los siete más recientes, que pueden contener ya datos preparados por el atacante o cifrados. El bloqueo funcionó exactamente como se configuró; la configuración no se correspondía con la amenaza. De ello se derivan tres consecuencias.
Las estimaciones publicadas del tiempo de permanencia varían y cambian de un año a otro, por lo que este artículo no citará ninguna. El principio es estable: si la organización no puede detectar con confianza a un intruso en un número determinado de días, la ventana inmutable debe ser más larga que ese número. Treinta días es un punto de partida habitual; los entornos regulados o de alto valor suelen ir más allá.
Las aplicaciones de backup distinguen entre cuánto tiempo se conserva un punto de restauración (política de retención) y cuánto tiempo el almacenamiento rechaza eliminarlo (periodo de inmutabilidad). Ambos pueden estar alineados o el periodo de inmutabilidad puede ser más corto. Lo que no debe ocurrir es que el periodo de inmutabilidad sea tan corto que la propia limpieza de la aplicación, o una copia comprometida de esta, pueda eliminar puntos de restauración que la organización aún necesita.
Los datos que no pueden eliminarse no pueden recuperarse como espacio. Ampliar el bloqueo de siete a treinta días aumenta la huella retenida, y ese aumento debe planificarse en lugar de descubrirse; el artículo sobre dimensionamiento del repositorio de backup explica cómo modelarlo.
El software de backup raramente expone los ajustes de retención S3 en bruto. En su lugar, el repositorio o el trabajo lleva un ajuste de inmutabilidad que la aplicación traduce en retención por objeto a medida que escribe. Normalmente, el administrador apunta un repositorio a un bucket con object lock habilitado y especifica un periodo de inmutabilidad en días. Cada objeto que crea el trabajo recibe una fecha de retención calculada a partir de ese periodo y, en muchos productos, ampliada para que toda la cadena de la que depende un punto de restauración permanezca bloqueada tanto tiempo como el propio punto de restauración.
Dos detalles merecen verificación. Primero, confirmar qué modo solicita la aplicación; la mayoría de los fabricantes que admiten object lock escriben en modo compliance, pero el operador debería comprobarlo en lugar de asumirlo. Segundo, confirmar cómo interactúa la aplicación con la retención por defecto del bucket. Cuando existen ambas, generalmente prevalece la más larga, pero los desajustes entre las dos son una fuente frecuente de confusión durante las auditorías.
La página de aplicaciones de backup validadas enumera las plataformas probadas con ARTESCA, lo que elimina parte de estas conjeturas.
Estas comprobaciones llevan una tarde y habrían evitado la mayoría de los fallos anteriores.
Object lock es fiable precisamente porque sus garantías son estrechas y mecánicas. Saber dónde terminan lo convierte de una casilla marcada en un plan de recuperación. Hay más contexto arquitectónico disponible en backup inmutable.
Scality ARTESCA es almacenamiento de objetos S3 diseñado como destino de backup, y object lock se aplica en su ruta de datos en lugar de superponerse como un gateway sobre un sistema de archivos escribible por separado. La eliminación de una versión bloqueada la rechaza el propio sistema de almacenamiento, sean cuales sean las credenciales o la consola desde las que se emita la solicitud.
ARTESCA admite el modo compliance, de modo que un periodo de retención, una vez establecido, no puede acortarse ni eliminarse por ninguna cuenta, incluido el administrador del almacenamiento. Está validado con las principales aplicaciones de backup, incluidas Veeam, Commvault, Cohesity y Rubrik, de modo que la correspondencia entre el ajuste de inmutabilidad de un trabajo y la retención escrita en cada objeto está probada y no asumida. El modelo de seguridad se describe en la página de seguridad y ciberresiliencia.
Sea cual sea la plataforma que aloje los backups, el paso práctico es el mismo: leer los metadatos de retención de un objeto real, intentar eliminarlo con las credenciales que robaría un atacante y fijar la ventana en un plazo más largo que el tiempo que se tardaría en detectarlo.