Las copias de seguridad entre varias zonas de seguridad deben respetar los límites de confianza impuestos por la red de producción. Utilice credenciales específicas para cada zona, flujos de red de alcance limitado, tráfico de control y de datos separados, y rutas de recuperación independientes. Cuando esté prohibida la conectividad persistente entre zonas, utilice la replicación controlada, la transferencia unidireccional o soportes fuera de línea, en lugar de debilitar la segmentación de la red.
Esta nota está dirigida a arquitectos de infraestructura y seguridad, así como a administradores sénior que se dedican a la arquitectura de copias de seguridad empresariales en entornos deliberadamente segmentados, como los de defensa, aeroespacial, investigación, tecnología operativa, infraestructuras críticas y empresas que gestionan redes en diferentes niveles de clasificación o dominios de confianza. Estos pueden ser dominios de red clasificados y no clasificados, tecnología de la información corporativa frente a tecnología operativa en planta y configuraciones similares.
El enfoque se centra en los conocimientos sobre copias de seguridad y en resolver un problema de diseño concreto. En concreto, esta nota trata sobre cómo proteger las zonas sin crear nuevas rutas entre ellas.
Puntos clave
- Las copias de seguridad multizona deben preservar los límites existentes de las zonas de seguridad.
- Utilice credenciales privilegiadas específicas para cada zona y reglas de cortafuegos de alcance limitado.
- Separe el tráfico de control de las copias de seguridad del tráfico de datos de las copias de seguridad.
- Mantenga la capacidad de recuperación local en los casos en que las zonas deban funcionar de forma independiente.
- Pruebe la recuperación sin conectividad entre zonas, sin identidad centralizada y sin catálogos compartidos.
¿Por qué resulta difícil realizar copias de seguridad en múltiples zonas de seguridad?
Las arquitecturas de copia de seguridad centralizadas pueden generar riesgos de seguridad estructurales en entornos segmentados. A menudo dependen de una conectividad persistente y de privilegios elevados que traspasan los límites de las zonas, lo que puede convertir el sistema de copia de seguridad en una vía potencial para el movimiento lateral.
Las arquitecturas de copia de seguridad centralizadas, como las suites de copia de seguridad empresarial con una única consola y las arquitecturas centralizadas de dispositivos de extracción, dan por sentado que el servidor de copia de seguridad llega a todos los clientes, que los clientes devuelven los datos al almacenamiento compartido y que todos pueden acceder al plano de gestión.
Esa suposición funciona en una red plana. Sin embargo, no funciona en entornos segmentados deliberadamente, como las redes tácticas militares y los enclaves de investigación de defensa, así como en entornos industriales de tecnología operativa y de control de supervisión y adquisición de datos.
Las copias de seguridad entre zonas de seguridad deben preservar los entornos con segmentación de red impuesta. Cuando la copia de seguridad conecta la zona de tecnologías de la información corporativa con un entorno de ingeniería restringido, la segmentación empieza a jugar en contra del sistema de copias de seguridad.
El tráfico de copias de seguridad complica la situación. En concreto, esto se refiere a conexiones grandes, regulares y autenticadas que cruzan los límites de las zonas siguiendo un horario predecible. Además, se refiere a credenciales de cuentas de servicio con altos privilegios en ambos extremos y a copias almacenadas de todo lo que se procesa.
Cuando un componente de copia de seguridad se ve comprometido, permite el acceso a datos de zonas a las que no se podía llegar a través de la red de producción.
A partir de octubre de 2026, la norma NIST SP 1339 (junio de 2026) recomienda crear copias de seguridad de la tecnología operativa (OT) de forma regular, probarlas y revisarlas durante los ejercicios de recuperación.
¿Por qué la infraestructura de copias de seguridad puede generar un riesgo entre zonas?
Un servidor de copias de seguridad con conexiones autorizadas a varias zonas puede comunicarse entre ellas a través de rutas permitidas. Cuando el servidor se ve comprometido, los canales autorizados existentes llegan a todas las zonas a las que da servicio. Y esto se debe a su ubicación, no a una configuración incorrecta.
¿Por qué se deben definir los límites de confianza antes de elegir un software de copias de seguridad?
Defina los límites de confianza, la dirección de conexión permitida y las rutas de comunicación prohibidas antes de elegir o configurar productos de copias de seguridad. En primer lugar, diseñe la arquitectura; después, el producto se adaptará a ella.
La arquitectura «Zero Trust» del NIST describe la eliminación de la confianza implícita basada simplemente en la ubicación en la red. Guía de inicio rápido de copias de seguridad de tecnología operativa (OT) del NIST (SP 1339) es la guía de inicio rápido para copias de seguridad de tecnología operativa (OT) publicada por el Instituto Nacional de Estándares y Tecnología (NIST) y el Centro Nacional de Excelencia en Ciberseguridad (NCCoE). Esta guía señala que las organizaciones deben establecer procedimientos claros para la realización de copias de seguridad y la recuperación ante ataques de ransomware.
La Arquitectura «Zero Trust» del NIST (SP 800-207) es una publicación oficial del Instituto Nacional de Estándares y Tecnología que define la Arquitectura «Zero Trust» (ZTA) y establece directrices para que la ciberseguridad pueda alejarse de las defensas de red tradicionales basadas en el perímetro.
No se concede ninguna confianza implícita basada únicamente en la ubicación física o en la red. Aquí hay una fuente gubernamental fidedigna que aborda las copias de recuperación protegidas, fuera de línea e inmutables.
Un error habitual es establecer primero las relaciones de confianza y solo después elegir una plataforma de copias de seguridad.
Las capacidades del producto, como la deduplicación y compresión en línea global, las instantáneas multicloud y la orquestación de matrices de almacenamiento, son menos esenciales que comprender qué comunicaciones están permitidas entre zonas. Los productos de copias de seguridad no pueden anular una regla de cortafuegos aplicada correctamente.
- Antes de cualquier configuración de copias de seguridad, identifica las zonas de seguridad y su nivel de clasificación.
- A continuación, define qué sistemas pueden conectarse con otros.
- A continuación, separe el tráfico del plano de control del del plano de datos mientras realiza los análisis.
- Además, identifique los lugares en los que se permite la existencia de credenciales.
- Por último, trace las rutas prohibidas por las que puede operar el diseño de la copia de seguridad.
La ubicación de las credenciales es una decisión relativa a los límites de confianza. Una cuenta de servicio de copia de seguridad con acceso de lectura a los sistemas de la Zona C no debería existir en un sistema con conectividad a la Zona A.
El alcance y la ubicación de las credenciales representan decisiones relativas a los límites de confianza.
Referencia de las directrices revisada en octubre de 2026: NIST SP 800-207, publicada en agosto de 2020.
¿Qué modelos de arquitectura de copias de seguridad funcionan en múltiples zonas de seguridad?
No hay modelos universalmente correctos. El patrón adecuado depende de los niveles de clasificación, las rutas de comunicación permitidas, los requisitos de recuperación y el coste operativo que supone el aislamiento de cada zona. Las copias de seguridad multizona no deben crear nuevas rutas de acceso entre zonas.
Existen cinco patrones establecidos que permiten realizar copias de seguridad a través de los límites de las zonas, como la red de tecnología de la información corporativa frente a la planta de tecnología operativa industrial, y los enclaves de producción general en la nube frente a los entornos de procesamiento de pagos que cumplen la Norma de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI-DSS).
Cada uno de ellos representa un equilibrio entre la simplicidad operativa y el aislamiento de seguridad.
| Modelo | Descripción | Ideal para | Riesgo principal |
|---|---|---|---|
| Centralizado | Un único servidor de copias de seguridad utiliza reglas de cortafuegos entre zonas para dar servicio a todas las zonas | Zonas con distintos niveles de sensibilidad, pero con el mismo nivel de confianza | Un único punto de compromiso con acceso autorizado a todas las zonas |
| Totalmente distribuido | Cada zona cuenta con su propio servidor de copia de seguridad, almacenamiento y catálogo. Los datos no cruzan los límites de las zonas. | Entornos en los que los datos permanecen siempre dentro de su zona. | Duplicación de la infraestructura; complica la recuperación entre zonas |
| Jerárquica | Infraestructura de copias de seguridad a nivel de zona con replicación opcional a un repositorio central a través de una puerta de enlace controlada. La infraestructura de copias de seguridad no debe debilitar los límites de confianza existentes. | Entornos que necesitan recuperación local y retención centralizada | La pasarela se convierte en un objetivo de alto valor entre zonas, lo que la convierte en una pasarela crítica para la seguridad con acceso a múltiples zonas. |
| Replicación controlada | Copia de seguridad local en la zona; los datos se transfieren a través de una pasarela, un diodo de datos o una apertura programada del cortafuegos. Un diodo de datos es un dispositivo de seguridad de red basado en hardware que permite la transmisión unidireccional de datos entre dos redes. | Entornos en los que están prohibidas las conexiones persistentes de copia de seguridad entre zonas | La ventana de transferencia actúa como superficie de ataque si no se controla estrictamente. La superficie de ataque son los sistemas, servicios y rutas de red que un atacante podría explotar. |
| Totalmente separado | Los componentes no se comparten en ninguna capa. Cuenta con servidores, almacenamiento, catálogos, rutas de administración y procedimientos de recuperación independientes. | Requisitos de aislamiento absoluto; separación entre información clasificada y no clasificada | Máximo coste operativo; capacidad de copia de seguridad con duplicación completa |
¿Qué parte debe iniciar la conexión de copia de seguridad?
La dirección de conexión preferida depende del límite de confianza. En zonas con el mismo nivel de confianza, puede ser adecuado utilizar conexiones estándar de Bacula iniciadas por el Director. En zonas restringidas, una conectividad entrante reducida puede traducirse en una superficie de ataque autorizada más reducida, y la configuración de Bacula seleccionada debe ser compatible y haber sido probada.
En una implementación convencional de Bacula, el Director establece conexiones tanto con el daemon de archivos (en el cliente) como con el daemon de almacenamiento (en el destino de almacenamiento). El flujo de datos de copia de seguridad circula entre el daemon de archivos y el daemon de almacenamiento. El Director no se encuentra en la ruta de los datos.
En entornos en los que las zonas tienen el mismo nivel de confianza y el Director puede establecer conexiones entrantes con los clientes, el modelo estándar puede funcionar sin necesidad de modificaciones.
Cuando el límite de una zona no permite que las conexiones entrantes procedan de la red de copias de seguridad, es posible que la conexión estándar iniciada por el Director hacia el demonio de archivos no cuente con los permisos necesarios.
Bacula admite la conectividad iniciada por el demonio de archivos a través de su configuración «ConnectToDirector». Comprueba la disponibilidad y el comportamiento en función de la versión de Bacula implementada en tu entorno, reduciendo así los requisitos de acceso entrante a la zona restringida. Esto requiere una planificación y unas pruebas específicas, lo que también afecta a la programación y al comportamiento del control de tareas.
¿Cómo afecta la dirección de la conexión de copia de seguridad al riesgo entre zonas?
El riesgo de pivote es el riesgo de utilizar una conexión de copia de seguridad autorizada para acceder a otra zona. ¿Qué lado debe iniciar la conexión de copia de seguridad?
Si el Director establece conexiones con los clientes de la Zona C utilizando una regla autorizada, un Director comprometido dispone de una ruta permitida hacia la Zona C. Si los File Daemons de la Zona C establecen conexiones salientes, esa superficie de entrada se reduce. El cortafuegos controla lo que se puede mantener bajo control, y la arquitectura determina lo que está autorizado.
La conectividad bidireccional a través de un límite de zona permite que el número de rutas de conexión entre zonas permitidas aumente en ambas direcciones. Los requisitos operativos específicos deben justificar las reglas bidireccionales del cortafuegos asociadas al tráfico de copia de seguridad a través de un límite de alta sensibilidad, sin dejarlas como predeterminadas.
¿Cómo se evita que la infraestructura de copias de seguridad cree una ruta entre zonas?
Un servidor de copias de seguridad conectado a varias zonas puede enrutar el tráfico entre ellas utilizando sus interfaces. Esto se evita mediante controles explícitos en la capa de red, interfaces separadas por zona, el enrutamiento entre interfaces desactivado y una huella de servicio mínima.
Un servidor de copias de seguridad con conexiones autorizadas a varias zonas actúa como puente entre ellas. El servidor utiliza el enrutamiento, no una configuración errónea. Si el tráfico de la Zona B y la Zona C llega a interfaces diferentes, el enrutamiento entre ellas debe desactivarse o regirse por una política específica.
Cada zona debe tener una interfaz de red independiente. Minimice los servicios en la infraestructura de copias de seguridad. Trate cada uno de ellos como una superficie de ataque adicional.
La administración debe basarse en una ruta de gestión dedicada sin atravesar las redes de las zonas de producción.
¿Cómo deben separarse el control de las copias de seguridad y el tráfico de datos?
La arquitectura de Bacula está diseñada estructuralmente para separar los planos de control y de datos. El plano de control transporta el tráfico de gestión y coordinación de tareas. El plano de datos transporta los datos de copia de seguridad y restauración.
El Director mantiene bajo control la programación y la coordinación de tareas sin transportar datos de copia de seguridad. El demonio de archivos envía datos al demonio de almacenamiento. No hay ningún Director en la ruta de datos.
Esto tiene implicaciones específicas para el cortafuegos: las conexiones Director→Demonio de archivos (Protocolo de control de transmisión 9102) y Director→Demonio de almacenamiento (Protocolo de control de transmisión 9103) transportan el control de los trabajos. La ruta Demonio de archivos→Demonio de almacenamiento transporta el flujo de copia de seguridad.
Es posible restringir el acceso de la consola de gestión al Director (TCP 9101) a una red de gestión dedicada sin afectar a los flujos de datos de copia de seguridad.
El Director puede permanecer en la zona de copias de seguridad utilizando reglas restrictivas para las zonas de producción (solo coordinación de tareas). Las reglas del daemon de almacenamiento regulan por separado la ruta de datos de mayor volumen.
Cuando se utiliza una única regla amplia para ambas, se pierde el valor arquitectónico de la separación. El tráfico de gestión, incluido el acceso a la consola y las consultas al catálogo, debe circular por una ruta dedicada. No debe circular por interfaces compartidas con los datos de copia de seguridad.
Tabla de referencia de flujos del cortafuegos
| Origen | Destino | Puerto predeterminado | Finalidad | Dirección |
| Consola | Director | TCP 9101 | Gestión | Consola → Director |
| Director | Demonio de archivos | TCP 9102 | Control de tareas | Director → FD |
| Director | Demonio de almacenamiento | TCP 9103 | Control de almacenamiento | Director → SD |
| Demonio de archivos | Demonio de almacenamiento | TCP 9103 | Datos de copia de seguridad | FD → SD |
¿Cómo deben aislarse las credenciales de respaldo entre las distintas zonas de seguridad?
Utiliza credenciales de respaldo privilegiadas independientes para cada zona de seguridad. Asegúrate de que el compromiso de las credenciales en una zona no proporcione automáticamente acceso autenticado a otra.
Las cuentas de servicio de respaldo de la Zona C deben ser diferentes de las de la Zona B y la Zona A. Cuando se comparten credenciales, un único compromiso puede ampliar el alcance autenticado a todas las zonas que utilicen dichas credenciales.
Las dependencias de recuperación en una infraestructura de identidades centralizada, como Active Directory, el Protocolo Ligero de Acceso a Directorios (LDAP) y los proveedores de identidades (IdP) externos, representan un punto débil arquitectónico habitual. Los IdP son sistemas centrales, como Okta, Microsoft Entra ID o Google Identity, que gestionan las cuentas de usuario, las autenticaciones y los permisos de acceso.
Si la Zona C se autentica mediante el proveedor de identidad de la Zona A, esta última puede ayudar a la Zona C a recuperarse. Las cuentas de servicio locales con credenciales gestionadas de forma independiente eliminan esa dependencia.
Utiliza un calendario específico para rotar las credenciales de las cuentas de servicio de copia de seguridad. Responde a la pregunta «¿Se puede restaurar la Zona C con un proveedor de identidad central fuera de línea?» antes de que se produzca un incidente.
¿Cómo deben trasladarse los datos de copia de seguridad entre zonas de seguridad?
Elige el mecanismo de transferencia en función del nivel de sensibilidad de la zona. Una zona restringida implica que el mecanismo de transferencia debe minimizar su superficie de red persistente. Concretamente, esto se refiere a la transferencia directa a través de puertas de enlace y aperturas de duración limitada, así como a soportes físicos sin conexión cuando una ruta de red entre zonas esté prohibida o sea inaceptable.
Cuando los datos de copia de seguridad deben cruzar el límite de una zona con fines de retención o recuperación ante desastres, el método de transferencia forma parte de la arquitectura de seguridad.
La transferencia directa mediante una regla de cortafuegos autorizada es la opción más sencilla. Sin embargo, crea una ruta persistente con reglas que especifican direcciones y puertos exactos. Estas reglas deben registrarse.
Una pasarela controlada puede limitar el efecto de una violación de seguridad cuando sus destinos, protocolos y funciones permitidos están estrictamente restringidos.
El almacenamiento y reenvío con aperturas de cortafuegos limitadas en el tiempo preserva la capacidad de recuperación local, independientemente de si la ventana de transferencia está abierta o no.
La transferencia de soportes físicos sin conexión evita una conexión de red entre las zonas de origen y destino durante la transferencia. Es posible que las zonas altamente aisladas solo acepten esta opción. Las zonas aisladas deben contar con una ruta de recuperación definida cuando los servicios compartidos estén fuera de línea.
Los datos de copia de seguridad deben cifrarse antes de cruzar un límite de zona. Nadie debe poder acceder a las claves de descifrado fuera de la zona de origen.
¿Por qué la recuperación entre zonas puede ser más difícil que la copia de seguridad?
Aunque el diseño consiga escribir correctamente los datos de copia de seguridad entre zonas, puede fallar durante la recuperación ante desastres. La recuperación se basa en un entorno de destino funcional, servicios de identidad, conectividad de red y un catálogo operativo. Estas dependencias pueden impedir la recuperación incluso cuando los datos de copia de seguridad en sí están intactos. La recuperación debe probarse sin que estén disponibles las dependencias entre zonas.
La integridad de la zona también está relacionada con la recuperación. Concretamente, si los datos de la Zona C se restauran en la Zona A, es posible que la forma en que los datos han salido de su zona no cumpla los requisitos del límite. La integridad de la zona y la integridad de los datos no son las mismas restricciones.
Responde a estas preguntas antes de que se produzca un incidente:
- Si no hay conectividad entre zonas, ¿puede cada zona recuperarse de forma independiente?
- Si el catálogo de copias de seguridad no está disponible, ¿puede proseguirse la recuperación desde soportes offline?
- ¿Se ha definido y probado la copia de seguridad local de credenciales para la recuperación en caso de que los servicios de identidad centrales no estén disponibles?
- ¿Está el almacenamiento local lo suficientemente actualizado como para permitir una recuperación útil con un cortafuegos entre zonas cerrado?
- ¿Pueden los sitios funcionar y recuperarse de forma independiente sin una red de área amplia?
¿Cuál es la diferencia entre la disponibilidad de las copias de seguridad y la capacidad de recuperación?
Escribir con éxito en el almacenamiento se considera disponibilidad. Cuando los datos se recuperan correctamente en la zona adecuada, mediante una autenticación que funciona, dentro del tiempo requerido, con el cortafuegos entre zonas cerrado y la identidad central fuera de línea, se trata de capacidad de recuperación. Es esencial centrarse en diseñar y probar la capacidad de recuperación, no solo la disponibilidad.
Un sistema que escribe en el almacenamiento se considera disponible. Un sistema se considera recuperable cuando utiliza una autenticación válida para restaurar los datos correctos en la zona correcta, en un destino funcional, dentro del tiempo requerido y con el cortafuegos entre zonas cerrado y la identidad central fuera de línea. Se trata de propiedades diferentes. La segunda debe someterse a pruebas.
¿Cómo es una arquitectura de copia de seguridad de tres zonas?
Este escenario trata sobre un diseño multizona coherente en el que la capacidad de recuperación de las zonas se ajusta a su nivel de aislamiento. Concretamente, la zona A depende de la zona de copia de seguridad, y la zona B se recupera localmente o desde la zona de copia de seguridad. La zona C se recupera a partir de componentes locales sin depender de sistemas externos.
La siguiente arquitectura de referencia muestra un diseño multizona coherente. La zona C está aislada, por lo que no tiene rutas de red de entrada ni de salida hacia zonas externas. Las funciones de control y del plano de datos son locales a la zona C. Los datos salen mediante transferencia física en cinta.
El término «air-gapped» se refiere a soportes de copia de seguridad físicamente desconectados, sin conexión activa a la red. No se trata de un almacenamiento aislado lógicamente de la red.
Una réplica del catálogo representa una copia sincronizada de algunos o todos los registros del catálogo principal, que se mantiene en una instancia de base de datos independiente.
Zona A: TI corporativa
Los demonios de archivos transfieren datos salientes al demonio de almacenamiento central. El director utiliza una ruta autorizada a través del cortafuegos para programar los trabajos. No hay almacenamiento local de copias de seguridad. Cuando hay conectividad, la Zona A puede recuperarse desde la Zona de Copias de Seguridad.
Zona B: Ingeniería restringida
La Zona B protege clústeres de computación de alto rendimiento, cargas de trabajo de simulación, datos de diseño asistido por ordenador y conjuntos de datos de investigación. Aloja un Director de Bacula local, demonios de archivos, un demonio de almacenamiento y un catálogo, lo que permite realizar copias de seguridad y recuperaciones sin necesidad de conectividad con la Zona central de Copias de Seguridad y Recuperación.
Los datos de copia de seguridad se transfieren localmente desde los demonios de archivos al demonio de almacenamiento de la zona, mientras que el Director local gestiona las tareas de copia de seguridad y restauración. Las copias de seguridad pueden replicarse a la zona central de copia de seguridad y recuperación a través de una pasarela controlada durante las ventanas de transferencia autorizadas. Si no hay conectividad entre zonas, la Zona B puede continuar con las operaciones locales de copia de seguridad y recuperación.
Zona C: Altamente aislada
No hay ruta de red hacia zonas externas. La Zona C alberga su propio Director, demonios de archivos, demonio de almacenamiento, catálogo y biblioteca de cintas. Un proceso auditado transfiere físicamente las cintas a la zona de copia de seguridad para la importación al catálogo central. La Zona C realiza la recuperación desde su demonio de almacenamiento local sin necesidad de servicios de identidad externos ni conectividad de red.
Zona de copia de seguridad y recuperación
Aquí se encuentran el Director central, el daemon de almacenamiento, el catálogo y la consola de gestión. Acepta conexiones de copia de seguridad procedentes de las zonas A y B. No hay enrutamiento entre zonas de producción. Retención resistente al ransomware mediante almacenamiento de objetos inmutables. La retención resistente al ransomware es el almacenamiento de copias de seguridad diseñado para resistir el borrado o la modificación no autorizados.
La biblioteca de cintas permite la retención a largo plazo y la importación a la Zona C. La administración se basa en una interfaz de gestión dedicada a la que las redes de las zonas de producción no pueden acceder.
¿Cómo se elige una arquitectura de copia de seguridad multizona?
Esta tabla ayuda a comparar las opciones en las dimensiones clave del diseño. Cada fila representa una decisión independiente. Las elecciones no tienen por qué ser uniformes en todas las dimensiones.
Cómo diseñar una copia de seguridad multizona en 7 pasos
| Pregunta de diseño | Opción A | Opción B | Opción C |
|---|---|---|---|
| Infraestructura de copias de seguridad | Centralizada: un servidor, todas las zonas | Específica por zona: dedicada por zona | Híbrida: Director central, almacenamiento a nivel de zona |
| Dirección de la conexión | Iniciada por el servidor: la copia de seguridad se extrae de los clientes | Iniciada por el cliente: los clientes envían los datos al almacenamiento | Mixta: varía según la sensibilidad de la zona |
| Almacenamiento de copias de seguridad | Central: todas las zonas escriben en un almacenamiento compartido | Por zona: cada zona conserva sus propios datos | Por niveles: copia local más replicación central |
| Transferencia entre zonas | Directa: regla de cortafuegos persistente | Pasarela: transferencia con límite de tiempo | Fuera de línea: soportes físicos, sin ruta de red |
| Administración | Compartida: una consola da acceso a todas las zonas | Segmentada: rutas separadas por zona | Totalmente aislada: sin infraestructura de administración compartida |
| Copia de recuperación final | Disco inmutable: en línea, protegido contra escritura | Almacenamiento de objetos con bloqueo de objetos. El bloqueo de objetos consiste en un control de retención que impide que los datos de copia de seguridad se modifiquen o eliminen durante un periodo de protección definido, independientemente del proveedor. | Cinta / sin conexión: aislamiento físico |
| Identidad para la recuperación | Centralizada: depende de Active Directory y de un proveedor de identidad externo | Cuentas locales: credenciales preparadas previamente | Mista: primaria centralizada, secundaria local |
¿A qué fallos debe resistir una arquitectura de copia de seguridad multizona?
Revisa los escenarios de fallo en relación con la arquitectura diseñada antes de implementar el software. Los escenarios con respuestas poco claras o negativas representan una deficiencia de diseño que debes resolver antes de que se produzca un incidente.
| Escenario de fallo | Pregunta de diseño |
|---|---|
| Red corporativa comprometida | ¿Pueden las zonas B y C seguir realizando copias de seguridad y recuperándose de forma independiente? ¿El compromiso de la zona A proporciona una vía de acceso a la zona de copia de seguridad? |
| Servidor de copia de seguridad comprometido | ¿Puede un atacante establecer conexiones con las zonas de producción? ¿Son las copias de seguridad inalterables, de modo que no puedan eliminarse? |
| Una zona queda inaccesible | ¿Pueden las zonas restantes seguir realizando copias de seguridad y recuperándose? ¿Afecta la indisponibilidad de una zona a los catálogos de otras zonas? |
| Infraestructura de identidad fuera de línea | ¿Pueden las operaciones de copia de seguridad y recuperación autenticarse sin el proveedor de identidad central? |
| Cortafuegos entre zonas cerrado | ¿Puede cada zona recuperarse de forma independiente desde el almacenamiento local? ¿Está el catálogo local lo suficientemente actualizado? |
| Almacenamiento primario destruido | ¿Existe una segunda copia en un soporte diferente y en otra ubicación? ¿Cuál es el tiempo de recuperación a partir de la copia secundaria? |
| Catálogo de copias de seguridad no disponible | ¿Se puede proceder a la recuperación desde soportes fuera de línea sin la ayuda del catálogo? ¿Está documentado y probado el procedimiento? |
¿Qué debes comprobar antes de implementar una copia de seguridad multizona?
Esta lista de comprobación es esencial para la revisión del diseño. Los elementos sin marcar constituyen una deficiencia que debes resolver antes de que la arquitectura se considere completa.
- En primer lugar, se documentan los límites de confianza y las clasificaciones de zonas, y a continuación se inicia el diseño de la arquitectura de copia de seguridad.
- Un componente comprometido en la zona B no puede acceder a la zona C a través de canales de copia de seguridad autorizados ni de reglas de cortafuegos.
- Las cuentas del servicio de copia de seguridad están aisladas para cada zona. No hay credenciales privilegiadas compartidas que crucen los límites entre zonas.
- Las reglas de cortafuegos relacionadas con la copia de seguridad especifican con exactitud el origen, el destino, los puertos y la dirección.
- Las zonas pueden realizar copias de seguridad y recuperarse localmente si no hay conectividad entre zonas.
- Al menos una copia de recuperación se encuentra fuera de la red de producción: almacenamiento en línea inmutable o soportes físicos.
- No es necesario disponer de la infraestructura o los servicios de identidad de otra zona para restaurar cada zona.
- Se prueban los procedimientos de recuperación, incluidos los escenarios en los que el catálogo no está disponible.
- Se prueban las credenciales de respaldo locales para la recuperación sin el proveedor de identidad central. Las credenciales locales son credenciales preparadas previamente que se pueden utilizar cuando no hay servicios de identidad centralizados.
- El tráfico de copias de seguridad que cruza los límites de las zonas se registra en el cortafuegos. Las anomalías se someten a supervisión.
¿Cómo admite Bacula las copias de seguridad entre varias zonas de seguridad?
La separación entre el Director, el daemon de almacenamiento y el daemon de archivos de Bacula es más que una simple comodidad operativa. Se trata de una propiedad arquitectónica que permite ubicar los distintos componentes en zonas diferentes con reglas de cortafuegos distintas. De este modo, pueden admitir los patrones de diseño multizona descritos a lo largo de esta nota.
La arquitectura de copias de seguridad de Bacula Enterprise ofrece un modelo de componentes distribuidos que se adapta de forma natural a múltiples zonas. Los usuarios pueden implementar de forma independiente el Director, el daemon de almacenamiento y el daemon de archivos. Los distintos componentes pueden permanecer en zonas diferentes con reglas de cortafuegos distintas. Esta separación de componentes permite patrones de implementación que alinean los servicios individuales de Bacula con diferentes zonas de seguridad.
La documentación de configuración del daemon de archivos de Bacula describe la comunicación entre el Director y el daemon de almacenamiento para realizar copias de seguridad de los archivos de los clientes.
Un Director en la zona de copia de seguridad puede gestionar daemons de archivos en varias zonas. Los daemons de almacenamiento locales actúan como punto final de la ruta de datos en las zonas. Los datos fluyen directamente entre el daemon de archivos y el daemon de almacenamiento sin pasar por el Director. Por eso, los requisitos de cortafuegos del Director siguen siendo más limitados. La ubicación del daemon de almacenamiento puede adaptarse a la sensibilidad de la zona sin depender de la ubicación del Director.
Para aquellas zonas en las que no existe una ruta de red aceptable hacia la zona de copia de seguridad, Bacula admite cintas y soportes offline como destinos locales de la zona. Es decir, un daemon de almacenamiento escribe localmente y la cinta se transfiere físicamente para su importación a la zona de copia de seguridad sin necesidad de una ruta de red entre zonas.
Las opciones de almacenamiento inmutable de Bacula, que incluyen el bloqueo de objetos y las cintas de tipo «escribir una vez, leer muchas veces» (WORM), pueden proteger las copias de seguridad debidamente configuradas contra el borrado o la modificación no autorizados.
Las copias de seguridad inmutables y la recuperación ante ransomware son importantes cuando se trata de una zona de producción comprometida desde la que un atacante podría intentar eliminar o modificar copias de recuperación accesibles.
Para entornos HPC en zonas restringidas, Bacula es compatible con Lustre, el Sistema de Archivos Paralelo General de IBM (GPFS) y sistemas de archivos paralelos a gran escala. No se requieren cambios para el aislamiento de zonas.
Los componentes se ejecutan en las propias instalaciones sin depender de una infraestructura externa de gestión en la nube. Comprueba las licencias y las dependencias de servicios externos en relación con tu entorno antes de utilizar el software.
El comportamiento del producto Bacula y las opciones de implementación compatibles deben verificarse en función de la versión implementada. Las referencias técnicas de esta nota de arquitectura se revisaron en octubre de 2026.
Principio clave de arquitectura
Las copias de seguridad multizona deben preservar la seguridad de los límites del entorno de producción. La infraestructura de copia de seguridad no debe permitir un acceso entre zonas que esté prohibido por la arquitectura de producción. Diseñe los flujos permitidos, las credenciales y las rutas de recuperación independientes, y solo entonces decida dónde se implementan los componentes de Bacula.
Preguntas frecuentes
¿Puede un servidor de copia de seguridad proteger de forma segura varias zonas de seguridad?
En principio, sí. Un servidor de copia de seguridad centralizado puede ser adecuado cuando las zonas comparten requisitos de confianza compatibles y sus conexiones permitidas, credenciales y controles de enrutamiento no crean un riesgo inaceptable entre zonas.
¿Deben los clientes de copia de seguridad iniciar las conexiones?
En zonas restringidas, sí. Las conexiones salientes iniciadas por el cliente reducen la superficie de ataque entrante a través de los canales de copia de seguridad hacia esa zona.
¿Sustituye el almacenamiento inmutable a la copia de seguridad fuera de línea?
No. La inmutabilidad protege los datos de copia de seguridad contra modificaciones o eliminaciones bajo controles de retención definidos, pero no proporciona, por sí sola, aislamiento de red. La copia de seguridad fuera de línea elimina la conexión de red activa mientras el almacenamiento permanece fuera de línea. Se trata de protecciones independientes que abordan riesgos diferentes y pueden utilizarse conjuntamente.
¿Puede una zona aislada utilizar una identidad centralizada?
Sí, si esa dependencia es aceptable durante la recuperación. Si la recuperación depende de ese proveedor de identidad y no existe un plan de contingencia de autenticación local, la pérdida del proveedor puede impedir la recuperación.
¿Puede Bacula realizar una copia de seguridad de una zona sin conexión de red persistente?
Sí. Un demonio de almacenamiento local escribe en cinta dentro de la zona. La cinta se transfiere físicamente y se importa al catálogo central.
