La mayoría de los manuales de ataque de ransomware incluyen ya un paso dirigido a los backups antes de que comience el cifrado. Una vez que el atacante dispone de credenciales administrativas, un repositorio de backup en línea que pueda borrarse o sobrescribirse es simplemente otro conjunto de datos que destruir. Frente a ello suelen proponerse dos controles: un air gap que separa la copia de backup de la red de producción, y la inmutabilidad, que impide que la copia sea alterada incluso por un administrador. A menudo se presentan como alternativas. Resuelven problemas distintos.
La verdadera pregunta es qué modos de fallo debe sobrevivir la organización, con qué rapidez debe recuperarse y cuánta carga operativa puede asumir. Este artículo define el air gap físico, el air gap lógico y la inmutabilidad en la capa de almacenamiento, expone qué detiene cada uno y qué no, y describe el diseño por capas al que acaban llegando la mayoría de los entornos maduros.
Un air gap es una separación entre la copia de backup y cualquier sistema al que un atacante pudiera llegar desde el entorno de producción. En la práctica abarca dos enfoques.
Un air gap físico sitúa la copia en soportes que no están conectados a nada: cartuchos de cinta extraídos de la librería y guardados en una cámara acorazada, discos extraíbles enviados fuera de las instalaciones, o un sistema apagado entre ventanas de backup. Mientras el soporte permanece en la estantería, nada puede borrarlo ni cifrarlo sin que una persona lo manipule físicamente.
Un air gap lógico mantiene la copia en línea, pero la aísla administrativamente y a nivel de red: un segmento de red o un sitio separado con enrutamiento restringido, un dominio de identidad independiente de modo que las credenciales de producción no otorguen nada en el lado del backup, replicación extraída (pull) por el sistema aislado en lugar de enviada (push) desde producción, y conectividad abierta únicamente durante las ventanas de replicación programadas.
Inmutabilidad significa que, una vez escrito un objeto de backup, no puede modificarse ni eliminarse hasta que expira un periodo de retención. En almacenamiento de objetos compatible con S3 esto se implementa con S3 Object Lock, un mecanismo de escritura única y lectura múltiple (WORM) aplicado por el propio sistema de almacenamiento. En modo compliance, el bloqueo no puede acortarse ni eliminarse por ningún usuario, incluido el administrador del almacenamiento, durante todo el periodo de retención.
La propiedad crítica es dónde reside el control. Un ajuste de retención dentro de la aplicación de backup protege frente a errores en esa aplicación. Object lock en la capa de almacenamiento protege frente a cualquiera que llegue al almacenamiento con credenciales válidas, porque el almacenamiento rechaza la eliminación con independencia de quién la solicite. Aplicaciones de backup como Veeam y Commvault escriben de forma nativa en repositorios con object lock.
Un atacante con credenciales del servidor de backup puede emitir comandos de borrado contra cualquier repositorio al que lleguen esas credenciales. La inmutabilidad impide que la eliminación prospere. Un air gap lógico con credenciales separadas impide que los comandos lleguen siquiera a la copia aislada. Un air gap físico hace la copia inalcanzable, pero solo para los soportes que ya están fuera de línea; los backups más recientes que aún están en la librería o en el disco de staging siguen expuestos.
Un administrador malintencionado o coaccionado es el caso que distingue la inmutabilidad en la capa de almacenamiento de la mayoría de los demás controles. Un air gap lógico operado por la misma persona ofrece poca protección. Object lock en modo compliance sí la ofrece, porque ningún privilegio del sistema puede anularlo antes de que expire la retención. Un air gap físico también protege aquí, siempre que el acceso a la cámara requiera una segunda persona.
El malware que se propaga por recursos compartidos de red no puede alcanzar los soportes guardados en una estantería, y un air gap lógico correctamente configurado lo contiene. La inmutabilidad no impide que el malware se escriba en nuevos backups; garantiza que los puntos de restauración limpios escritos con anterioridad permanezcan intactos. La pérdida del sitio es el caso inverso: la inmutabilidad en un único sitio no sirve de nada frente a un incendio, una inundación o una interrupción regional, mientras que una copia física fuera de las instalaciones o un segundo sitio aislado lógicamente sí protegen.
Ninguna de las dos formas de air gap detecta la degradación de bits (bit rot); una cinta en una cámara puede fallar sin que nadie lo advierta durante años. El almacenamiento de objetos con comprobación continua de integridad aborda este problema, y todo diseño debería incluir pruebas periódicas de restauración con independencia del control elegido.
| Control | Protege frente a | No protege frente a | Velocidad de recuperación | Carga operativa |
|---|---|---|---|---|
| Air gap físico (cinta, soportes extraíbles, sistema apagado en cámara) | Robo de credenciales, propagación de malware, borrado interno con doble control, pérdida del sitio cuando se almacena fuera de las instalaciones | Backups recientes aún no fuera de línea, degradación silenciosa de los soportes | De horas a días para la recuperación, restauración secuencial | Alta: manipulación, transporte, custodia, renovación de soportes |
| Air gap lógico (red aislada, credenciales separadas, replicación pull) | Robo de credenciales desde producción, propagación de malware, pérdida del sitio cuando está en un segundo sitio | Usuario interno con acceso al dominio aislado, configuración incorrecta, corrupción de los datos replicados | Rápida, en línea | Media a alta: segundo entorno permanente, mantenimiento de identidad y cortafuegos |
| Inmutabilidad en la capa de almacenamiento (S3 Object Lock, modo compliance) | Robo de credenciales, borrado interno, cifrado de puntos de restauración existentes, borrado accidental | Pérdida del sitio por sí sola, malware escrito en nuevos backups | Rápida, en línea, directa a la aplicación de backup | Baja a media: planificación de capacidad consciente de la retención, sincronización horaria |
El patrón habitual es por niveles. El destino de backup principal es un repositorio de almacenamiento de objetos inmutable y en línea, situado on-premises, a menudo configurado como repositorio reforzado (hardened) o como nivel de capacidad directamente en la aplicación de backup. Recibe todos los trabajos de backup, mantiene los puntos de restauración bajo object lock y atiende la gran mayoría de las restauraciones a velocidad de disco.
Detrás se sitúa una copia aislada como último recurso: un segundo sistema de almacenamiento de objetos inmutable en otro sitio tras un air gap lógico, una exportación a cinta hacia una cámara, o ambos. Esta copia se utiliza raramente, por lo que una recuperación más lenta es aceptable. Supongamos que una organización debe restaurar un servidor de archivos de 40 TB tras un incidente: se recupera desde el nivel inmutable local el mismo día, mientras la copia aislada se mantiene en reserva por si la propia plataforma principal hubiera sido comprometida.
Lo que sigue es una orientación general; los requisitos regulatorios y los objetivos de recuperación deben guiar la decisión.
Scality ARTESCA es almacenamiento de objetos S3 diseñado para backup, con S3 Object Lock proporcionando inmutabilidad en la capa de almacenamiento. En el diseño por niveles descrito más arriba actúa como nivel inmutable en línea, atendiendo las restauraciones del día a día sin esperar a la recuperación de soportes. Su implementación de object lock y sus medidas de refuerzo se describen en la página de seguridad y ciberresiliencia.
ARTESCA está validado con las principales aplicaciones de backup, incluidas Veeam, Commvault, Cohesity, Rubrik, HYCU y Veritas, de modo que el repositorio inmutable se configura desde la consola de backup. La lista actualizada se mantiene en la página de compatibilidad con soluciones de backup.
Dado que ARTESCA está disponible como software o como appliance hardware desde decenas de terabytes en adelante, puede desplegarse una segunda instancia en otro sitio como copia aislada, replicada por una ruta controlada con credenciales separadas. Esto proporciona inmutabilidad en ambos niveles y un air gap lógico entre ellos, con la cinta como tercera capa opcional.
Empiece por hacer inmutable el repositorio de backup principal en la capa de almacenamiento y decida después cuán aislada debe estar la segunda copia en función de los escenarios de pérdida del sitio y de amenaza interna que la organización deba sobrevivir.