Copias inmutables: la copia de seguridad que un ransomware no puede borrar

Por qué la copia normal no basta frente a un ransomware

Imagina una clínica con un NAS en el cuarto de comunicaciones. Cada noche, el servidor de ficheros copia las historias y la agenda a una unidad de red, mapeada como Z:. Un lunes, alguien abre un adjunto en PC-RECEP-02, el ransomware cifra los documentos y, como ese usuario también ve la unidad Z:, cifra también la copia. Tienes copia, pero solo de archivos ya cifrados.

Los atacantes saben que la copia es tu salida y la buscan antes de pedir el rescate: borran instantáneas de Windows, vacían la papelera del NAS y, si consiguen la contraseña de administración de la consola de copias, eliminan también los puntos de restauración. Una copia que se puede borrar con las mismas credenciales con las que se trabaja cada día es una copia que el atacante también puede borrar.

Si todavía no tienes una política básica de copias, empieza por la guía copias de seguridad para una pyme. Esta va un paso más allá: cómo conseguir que, pase lo que pase en la red, exista al menos una copia que nadie pueda tocar.

Qué es una copia inmutable (y qué no es)

Una copia inmutable es la que, una vez escrita, no se puede modificar ni borrar durante un periodo fijado de antemano, ni siquiera con una cuenta de administrador. Se basa en el modelo WORM (write once, read many: se escribe una vez y se lee las veces que haga falta). Hoy se consigue de tres maneras habituales en una oficina:

• Bloqueo de objetos en almacenamiento en la nube. El servicio S3 de Amazon lo llama Object Lock y otros proveedores compatibles con S3 ofrecen algo equivalente. En modo compliance, una versión bloqueada no la puede borrar nadie hasta que venza el periodo, ni siquiera el usuario raíz de la cuenta. En modo governance se puede saltar el bloqueo con un permiso especial, lo cual es útil para probar pero deja una puerta abierta si se roban esas credenciales. Requiere versionado activado en el depósito.
• Instantáneas inmutables en un NAS. Algunos NAS con sistema de archivos Btrfs permiten fijar un periodo de bloqueo a las instantáneas. Synology, por ejemplo, lo incluye en Snapshot Replication desde DSM 7.2, con la indicación de comprobar qué modelos lo soportan. Revisa en el manual de tu equipo si el bloqueo puede levantarse antes de tiempo.
• Repositorios reforzados en el software de copias. Programas como Veeam permiten un repositorio Linux que rechaza cambios y borrados durante el periodo configurado.

No hay que confundirla con la copia desconectada (air-gapped), que es la que está físicamente apartada: un disco USB que se guarda en la caja fuerte o una cinta fuera de la oficina. La desconectada protege porque nadie puede alcanzarla por la red; la inmutable protege porque, aunque la alcancen, no pueden cambiarla. Una cumple lo que la otra no: el disco guardado depende de que alguien lo cambie cada semana, y la inmutable depende de que esté bien configurada. Cualquiera de las dos sirve como la copia «extra» de la regla de abajo.

La regla 3-2-1-1-0 aplicada a una oficina

La vieja regla 3-2-1 dice: tres copias de los datos, en dos tipos de soporte distintos, con una fuera de la oficina. Fabricantes como Veeam la han ampliado con dos cifras más: una copia inmutable o desconectada y cero errores al verificar la restauración. Pulsa cada cifra para ver cómo queda en una oficina de unos veinte puestos.

Retención, credenciales separadas y MFA en la consola

El periodo de retención tiene que ser más largo que el tiempo que tardas en darte cuenta de un ataque. Si el ransomware lleva dos semanas dentro sin hacer ruido, una copia inmutable de siete días solo conserva datos ya comprometidos. Para una oficina pequeña, un bloqueo de 30 días como mínimo para las copias diarias y copias mensuales con bloqueo más largo suele ser un punto de partida razonable, ajustado al espacio disponible y a los plazos legales de conservación de tu sector. Ten en cuenta que una copia inmutable no se puede borrar para hacer sitio: calcula el almacenamiento con holgura.

Las credenciales de la consola de copias merecen el mismo cuidado que la caja fuerte. Las reglas que más protegen cuestan poco:

• El servidor o NAS de copias no se une al dominio de Windows ni a Microsoft 365: si el atacante domina el directorio, no por eso domina las copias.
• Una cuenta de administración propia, con contraseña larga distinta de las demás y guardada en un gestor, no la del administrador del dominio.
• Segundo factor (MFA) obligatorio para entrar a la consola, ideal con aplicación de autenticación o llave física. Es lo que pide también el control 8.5 de la ISO 27001 (autenticación segura).
• La consola no se publica a internet. Acceso solo desde la red de gestión o por VPN (consulta la guía de wifi y segmentación de la red).
• Avisos por correo cuando se borre una tarea, se cambie la retención o falle una copia.

Una comprobación rápida desde un equipo de usuario: si el ransomware dispone de una unidad de red de las copias con permisos de escritura, el diseño falla. Puedes ver qué unidades de red tiene mapeadas un puesto con este comando:

Get-SmbMapping | Select-Object LocalPath, RemotePath, Status

Si en el resultado aparece la ruta de tu NAS de copias, quítala: las copias deben moverse por una cuenta de servicio y no por la sesión de ningún empleado.

Probar la restauración: el cero que casi nadie cumple

Una copia que nunca has restaurado es una hipótesis. El «0» de la regla significa comprobar de forma periódica que lo copiado se recupera sin errores. En una oficina pequeña basta con un ensayo trimestral:

1. Elige un caso real, como la carpeta de un cliente de la gestoría o la agenda de la clínica de hace dos semanas.
2. Restáurala en una ubicación aparte, nunca encima de la original.
3. Abre algún documento y comprueba que se lee. En bases de datos, arranca la aplicación contra la copia restaurada.
4. Anota la fecha, quién lo hizo, cuánto tardó y si hubo incidencias.

Para comparar un fichero restaurado con el original puedes usar su huella (hash):

Get-FileHash -Algorithm SHA256 'D:\Pruebas-restauracion\agenda.xlsx'

El tiempo que mediste en el ensayo es tu estimación real de recuperación. Es la cifra que querrás tener a mano cuando montes el plan de continuidad informática.

Qué piden ISO 27001 y el ENS sobre las copias

La ISO/IEC 27001:2022 trata las copias en el control 8.13 copias de seguridad de la información del Anexo A: se mantienen copias de información, software y sistemas y se prueban de forma periódica conforme a una política acordada. Se apoya en el 5.30 (preparación de las TIC para la continuidad) y en el 8.7 (protección contra malware). El Esquema Nacional de Seguridad (Real Decreto 311/2022) lo recoge en mp.info.6 copias de seguridad y, para la continuidad, en op.cont; aplica al sector público y a las empresas privadas que le prestan servicios. Ninguna de las dos normas menciona la palabra «inmutable» en esos controles, pero con el ransomware actual es la forma sencilla de poder demostrar que la copia es íntegra.

La certificación la emite una entidad acreditada (ENAC en España); Inventariamos no certifica ni audita, y ayuda a preparar y mantener estas evidencias técnicas según el alcance acordado. Para el conjunto, mira la guía de cómo preparar una auditoría ISO 27001 y ENS.

Fuentes oficiales

• INCIBE, ciberseguridad para empresas
• ISO/IEC 27001
• Real Decreto 311/2022, Esquema Nacional de Seguridad

Cómo lo hacemos en Inventariamos

Ofrecemos el montaje y el mantenimiento de copias inmutables para oficinas sin informático propio: diseñamos el esquema 3-2-1-1-0 según tus datos y presupuesto, configuramos el bloqueo y la retención, separamos las credenciales y el acceso con MFA de la consola, y hacemos el ensayo de restauración con un registro que puedas enseñar en una auditoría. Puedes ver cómo trabajamos en sistemas y redes y en ciberseguridad, o escribirnos si quieres que revisemos cómo están hoy tus copias.