"Respaldo inmutable con Object Lock: qué protege de verdad"

El ransomware moderno no se conforma con cifrar los datos de producción. El operador busca primero el respaldo — porque un respaldo íntegro vuelve innecesario el rescate. Si borra tus copias antes de cifrar, la negociación empieza contigo sin alternativa.

Contra eso sirve la inmutabilidad. Y por eso cómo se configura importa más que el hecho de estar activada.

Qué hace realmente Object Lock

Object Lock de S3 impide que una versión de objeto sea borrada o sobrescrita hasta una fecha determinada. Exige versionado y se define al crear el bucket — no se puede activar después en un bucket que ya existe.

Hay dos modos, y la diferencia entre ellos es lo más importante de este texto:

Modo governance. El objeto está protegido, pero quien tenga el permiso específico de ignorar la retención puede quitar la protección. Sirve contra el error, la automatización defectuosa y una credencial de bajo privilegio comprometida.

Modo compliance. Nadie quita la protección antes del plazo. Ni el administrador. Ni la cuenta raíz. Ni AWS a pedido del titular. Sirve contra un atacante que ya obtuvo control administrativo de la cuenta.

La elección es real y tiene dos caras. El modo compliance protege de verdad contra el escenario más grave — y también significa que un error tuyo es definitivo. ¿Grabaste 500 TB con diez años de retención por equivocación? Vas a pagar por diez años. No hay botón de deshacer, y es exactamente eso lo que lo vuelve eficaz.

Dónde suele filtrarse la protección

Activar Object Lock y dar el asunto por cerrado es el error más común. La protección depende de lo que la rodea:

La retención debe cubrir el tiempo de detección. Los compromisos pasan semanas sin ser notados. Una retención de siete días no protege contra un intruso que lleva un mes en tu red — cuando te das cuenta, el plazo ya pasó y las versiones protegidas ya pueden borrarse.

El ciclo de vida puede borrar lo que la retención protegería. Una política de expiración configurada de forma independiente convive mal con la retención. El resultado suele descubrirse tarde: datos que deberían existir, y no existen.

Quien graba no debería poder borrar. Si la misma credencial que envía el respaldo tiene permiso de eliminación, comprometerla derriba los dos extremos. Escritura y eliminación deben ser identidades distintas.

Governance sin restringir el permiso de bypass es teatro. El modo governance sólo significa algo si el permiso de ignorar la retención está genuinamente restringido. Si todo el equipo de infraestructura lo tiene, tienes un aviso, no una protección.

Inmutable no quiere decir recuperable

Este es el punto que más caro sale. La inmutabilidad garantiza que el dato no fue alterado. No garantiza que sea útil.

Un respaldo puede estar perfectamente protegido contra borrado y aun así ser inútil porque:

• se perdió la clave de cifrado — y sin ella, el dato inmutable es ruido protegido;
• el índice que dice dónde está cada archivo nunca fue probado;
• nadie sabe ejecutar la recuperación sin la persona que está de vacaciones;
• la recuperación tarda más de lo que el negocio aguanta parado.

La pregunta correcta no es "¿los datos están inmutables?". Es "¿cuánto tardo en tener este archivo de vuelta, y ya lo cronometré?".

La clave de cifrado es el punto único de falla

Si el respaldo está cifrado — y debería estarlo — la clave pasa a ser tan crítica como el dato. Perderla produce el mismo resultado práctico que perder el respaldo, con el agravante de que sigues pagando el almacenamiento.

Dos reglas resuelven la mayoría de los casos:

1. La clave no vive sólo en la máquina que hace el respaldo. Si muere con el servidor, el respaldo muere con ella.
2. La copia de la clave se prueba. Guardarla en una bóveda y nunca verificar que la copia funciona es el mismo tipo de error que nunca probar la recuperación.

Lista honesta de verificación

• Object Lock activado, con versionado — y el modo elegido conscientemente, sabiendo que compliance no tiene vuelta atrás.
• Retención mayor que tu tiempo realista de detección, no que el deseado.
• Identidad de escritura sin permiso de eliminación.
• Permiso de bypass de retención limitado a pocas personas, con registro de uso.
• Política de ciclo de vida revisada junto con la retención, no por separado.
• Clave de cifrado guardada fuera del servidor de respaldo y con copia probada.
• Recuperación ejercitada de extremo a extremo, cronometrada, con la identidad real.
• Registro de auditoría de quién pidió qué — incluidas las recuperaciones.

Ninguno de esos puntos es caro. Lo caro es descubrir la ausencia de uno de ellos el día en que el respaldo es lo único entre tú y el pago de un rescate.

NubliVault graba con Object Lock activado, separa las identidades de escritura y eliminación, registra toda acción en una traza de auditoría y corre en la infraestructura del propio cliente, con sus claves. Mira la página de seguridad.