La regla de backup 3-2-1 (tres copias, dos tipos de soporte, una fuera de las instalaciones) protege frente a los fallos para los que se escribió: una cabina de discos averiada, un volumen corrupto, una sala de servidores inundada. Nunca se diseñó para un adversario que localiza el catálogo de backup, elimina los repositorios y solo entonces cifra producción. La regla ampliada 3-2-1-1-0 pretende cerrar esa brecha.
La ampliación añade una copia que está fuera de línea, aislada mediante air gap o es inmutable, y un requisito de cero errores tras la verificación de la recuperación. Ambos obligan a plantear dos preguntas que la regla original nunca formuló: ¿puede un atacante con credenciales de administrador destruir todas las copias?, y ¿alguien sabe realmente si los backups se restauran? Este artículo explica cada dígito, cómo encaja el almacenamiento de objetos inmutable en la copia adicional, qué significa "cero errores" en la práctica, y cierra con un diseño ilustrativo y una lista de comprobación.
¿Qué es la regla 3-2-1-1-0?
La regla 3-2-1-1-0 establece cinco condiciones mínimas para una estrategia de backup: tres copias de los datos, en dos tecnologías de almacenamiento, una copia fuera de las instalaciones, una copia fuera de línea, aislada mediante air gap o inmutable, y cero errores en la verificación. Los tres primeros dígitos son la regla clásica; los dos últimos se añadieron cuando el ransomware se convirtió en el escenario de recuperación dominante.
La lectura ingenua es que simplemente significa más copias. Si todas las copias pueden eliminarse con las mismas credenciales, una cuarta copia aporta poco. El "1" adicional se gana su lugar mediante la independencia respecto al plano de control utilizado en todo lo demás; el "0" sustituye la suposición de que los backups funcionan por la evidencia de que lo hacen.
¿Frente a qué protege cada dígito?
3: tres copias
Producción más al menos dos backups, de modo que un único evento, como un fallo de controladora, no pueda destruir a la vez los datos y su único backup. Hoy esto suele ser un repositorio principal on-premises para restauraciones rápidas más una segunda copia en otro repositorio o en un almacén de objetos.
2: dos tecnologías de almacenamiento
Las copias de backup no deberían compartir un modo de fallo: el mismo error de firmware, la misma corrupción del sistema de archivos o la misma cuenta de administrador capaz de eliminar ambas. Históricamente esto significaba disco y cinta; hoy significa con mayor frecuencia un repositorio de bloques o de archivos más un almacén de objetos S3.
1: una copia fuera de las instalaciones
Protección frente a incendio, inundación, fallo eléctrico o interrupción regional, normalmente cubierta mediante replicación a un centro de datos secundario o un trabajo de copia a una instalación de colocation o a la nube pública. Fuera de las instalaciones no significa protegida frente al ransomware: una réplica que hereda las eliminaciones del origen sigue estando expuesta.
1: una copia fuera de línea, aislada mediante air gap o inmutable
Este es el dígito del ransomware. Protege frente a un atacante que ha comprometido el servidor de backup, el hipervisor o el dominio y posee credenciales legítimas. La copia debe ser una que esas credenciales no puedan modificar ni eliminar:
- Fuera de línea: soportes desconectados físicamente tras la escritura, con mayor frecuencia cinta expulsada y guardada en una cámara.
- Aislada mediante air gap: un destino en una red separada, accesible únicamente durante una ventana controlada.
- Inmutable: almacenamiento que aplica retención de escritura única en la capa de almacenamiento, de modo que ni siquiera la cuenta propietaria puede eliminar o sobrescribir un objeto antes de que expire su retención. En almacenamiento de objetos esto es S3 Object Lock en modo compliance.
0: cero errores tras la verificación
El fallo aquí es silencioso: un trabajo puede informar de éxito mientras escribe una imagen que no puede montarse o una máquina virtual que no arranca. El requisito es que la verificación, y no el estado del trabajo, informe de cero errores.
¿Cómo se corresponden los dígitos con las amenazas y los errores habituales?
| Dígito | Amenaza abordada | Implementaciones habituales | Error típico |
|---|---|---|---|
| 3 copias | Un único fallo que destruye los datos y su único backup | Producción más repositorio principal más copia secundaria | Contar las instantáneas de la cabina de producción como una copia |
| 2 tecnologías | Modo de fallo compartido entre copias | Repositorio de bloques o archivos más almacén de objetos S3; disco más cinta | Dos repositorios en la misma plataforma y con la misma cuenta de administrador |
| 1 fuera de las instalaciones | Pérdida del sitio, interrupción regional | Centro de datos secundario, colocation, almacén de objetos en la nube | Replicación que propaga fielmente las eliminaciones |
| 1 fuera de línea / inmutable | Atacante con credenciales de administrador de backup o de dominio | Cinta expulsada, destino en red aislada, S3 Object Lock en modo compliance | Modo governance, o retención más corta que el tiempo de permanencia del atacante |
| 0 errores | Corrupción silenciosa, backups no restaurables | Análisis de integridad, verificación de arranque, restauraciones de prueba programadas | Tratar "trabajo completado" como prueba de recuperabilidad |
¿Cómo satisface el almacenamiento de objetos inmutable el "1" adicional?
La cinta sigue siendo una copia fuera de línea legítima, pero conlleva una logística para la que muchos equipos ya no disponen de personal: mantenimiento de la librería, rotación de soportes, transporte a la cámara y restauraciones que esperan al cartucho correcto. Un air gap evita la manipulación de soportes, pero sigue dependiendo de la disciplina en la programación. El almacenamiento de objetos inmutable alcanza el mismo resultado haciendo que la copia sea lógicamente imposible de eliminar durante un periodo definido, en lugar de separarla físicamente.
Cuando la aplicación de backup escribe un objeto con un periodo de retención en modo compliance, el almacenamiento rechaza cualquier eliminación o sobrescritura hasta que ese periodo expira, con independencia de quién lo solicite. Un servidor de backup comprometido aún puede emitir comandos de borrado; simplemente recibe errores. Dado que la retención se aplica en la capa de almacenamiento, reconfigurar o desinstalar la aplicación de backup no la elimina.
De ello se derivan varias consecuencias de diseño. La cuenta que utiliza la aplicación de backup debería tener únicamente permisos de escritura, de modo que su compromiso no permita alterar las políticas del bucket. La administración del almacenamiento debería utilizar una identidad separada con autenticación multifactor, en manos de personas distintas de las que administran el backup. La retención debería superar el tiempo de permanencia probable del atacante, ya que un intruso presente durante semanas simplemente esperará a que expire un periodo corto. Las principales aplicaciones de backup, incluidas Veeam, Commvault, Rubrik, Cohesity y HYCU, escriben directamente en buckets con object lock habilitado; en términos de Veeam, se trata de un nivel de capacidad inmutable de un repositorio de backup scale-out o de un repositorio de almacenamiento de objetos directo. Desplegado en un segundo sitio, el mismo destino cubre también la segunda tecnología y la copia fuera de las instalaciones.
¿Qué significa "cero errores" en la práctica?
Una interpretación viable tiene tres capas.
Comprobaciones de integridad del repositorio
La aplicación de backup o el sistema de almacenamiento relee los datos almacenados y los compara con las sumas de comprobación registradas en el momento de la escritura, detectando la degradación de bits y las escrituras incompletas antes de que una restauración dependa de ellos. Los almacenes de objetos suelen hacerlo de forma continua.
Verificación automatizada de restauración
La mayoría de las aplicaciones de backup empresariales pueden montar un punto de restauración en un entorno aislado, arrancarlo y ejecutar comprobaciones a nivel de aplicación de forma programada. Un fallo en ese informe significa que el backup no se cuenta como válido, con independencia de lo que indicara el estado del trabajo.
Restauraciones de prueba programadas
Las comprobaciones automatizadas demuestran que los datos son legibles; una restauración de prueba demuestra que las personas, los procedimientos y la infraestructura pueden devolver un servicio dentro del tiempo objetivo. Debería ejecutarse específicamente desde la copia inmutable, ya que una restauración desde el repositorio principal no dice nada sobre la copia que importará durante un ataque. Cero errores no significa que nunca se encuentre un problema; significa que cada problema encontrado se corrige y los backups afectados se vuelven a verificar.
¿Qué aspecto tiene un diseño conforme para un entorno de tamaño medio?
Supongamos que una organización opera aproximadamente 400 máquinas virtuales en dos sitios, mantiene unos 150 TB de datos primarios y se propone restaurar los servicios esenciales en las 24 horas siguientes a un incidente de ransomware. Las cifras son ilustrativas; lo relevante es la forma del diseño.
- Copia 1: datos de producción en la cabina principal del Sitio A.
- Copia 2: el repositorio de backup principal en el Sitio A, un repositorio Linux reforzado (hardened) o un appliance de deduplicación que conserva 14 días de puntos de restauración.
- Copia 3: un repositorio de almacenamiento de objetos S3 en el Sitio B, escrito con object lock en modo compliance y retención de 30 días, con puntos de restauración mensuales conservados más tiempo por motivos de cumplimiento.
Esto proporciona tres copias, dos tecnologías, una copia fuera de las instalaciones y una copia inmutable. El "0" se cumple mediante una verificación de arranque automatizada semanal de las 40 máquinas virtuales más críticas, comprobación continua de integridad en ambos repositorios y una restauración completa trimestral de una aplicación de negocio desde la copia del Sitio B con el repositorio principal excluido. Dos detalles suelen pasarse por alto: las credenciales administrativas del almacenamiento de objetos están en manos del equipo de infraestructura y no del equipo de backup, y la retención de 30 días refleja un plan de incidentes que asume que un atacante puede estar presente durante varias semanas antes de ser detectado.
Lista de comprobación: revisar una estrategia existente frente a 3-2-1-1-0
- ¿Existen dos copias de backup independientes de la cabina de producción, excluyendo del recuento las instantáneas de la cabina?
- ¿Puede una única cuenta administrativa eliminar ambas copias de backup?
- ¿Sobrevive la copia fuera de las instalaciones a la eliminación o el cifrado en el origen?
- ¿Está una de las copias protegida por un mecanismo que las propias credenciales del servidor de backup no pueden anular?
- ¿Es la retención de inmutabilidad más larga que el tiempo de permanencia del atacante que se asume?
- ¿Son los administradores de almacenamiento, de backup y de dominio identidades separadas con autenticación multifactor?
- ¿Se ejecuta la verificación automatizada de restauración, y alguien revisa los resultados?
- ¿Se ha realizado una restauración completa desde la copia inmutable en el último año, y se comparó el tiempo con el objetivo de recuperación?
Cómo actúa Scality ARTESCA como copia inmutable
Scality ARTESCA es almacenamiento de objetos S3 diseñado para backup, disponible como software o como appliance hardware, desde decenas de terabytes hasta petabytes. Es compatible con S3 Object Lock, de modo que los puntos de restauración no pueden eliminarse ni sobrescribirse antes de que expire su retención, que es lo que exige el cuarto dígito de la regla.
ARTESCA está validado con las principales aplicaciones de backup, incluidas Veeam, Commvault, Cohesity, Rubrik, HYCU, Veritas, Zerto, Acronis e IBM, de modo que la copia inmutable puede añadirse como repositorio dentro de las herramientas que el equipo ya utiliza. Sus funciones de seguridad y ciberresiliencia abordan los detalles de configuración, como las identidades administrativas separadas y la autenticación multifactor, que deciden si la inmutabilidad se sostiene en la práctica.
La conclusión práctica: cumpla el "1" inmutable añadiendo un repositorio con object lock habilitado a la aplicación de backup que ya utiliza, y después demuestre el "0" restaurando desde ese repositorio de forma programada.