Entornos soportados para QRadar Data Synchronization

Para que la aplicación funcione correctamente, debe utilizar un soporteIBM®QRadar® versión, un navegador web compatible y cumplir con los requisitos del sitio de destino.

Versiones compatibles deQRadar

La aplicación IBM QRadar Data Synchronization se instala por separado en el sitio principal y en el sitio de destino.

La siguiente tabla describe qué versión deQRadar Data Synchronization para usar conQRadar .
Tabla 1. Versiones admitidas de QRadar
Versión de sincronización de datos Versión de QRadar
4.0.0 o posterior QRadar 7.6.0 o posterior
3.3.0 QRadar 7.5.0 Paquete de actualización 14 o posterior
3.2.2 QRadar 7.5.0 Paquete de actualización 13 o posterior
3.2.0 QRadar 7.5.0 Paquete de actualización 9 o posterior
3.0.0 QRadar 7.5.0 Paquete de actualización 1 o posterior
2.0.0 QRadar 7.4.2 o más tarde

Una implementación con dominios requiereQRadar7.4.2 o más tarde yQRadar Data Synchronization2.0.0 o después.

QRadar Data Synchronization3.0.0 apoyaQRadar Network Insights electrodomésticos que utilizanQRadar7.5.0 Actualice el paquete 1 o posterior. Para obtener más información, consulta la sección «Emparejamiento de hosts gestionados ».

Importante:
  • QRadar Data Synchronization no está soportada en QRadar on Cloud

Nuevas funciones y versión compatible

Se añaden las siguientes novedades:
  1. Una implementación con dominios requiereQRadar7.4.2 o más tarde yQRadar Data Synchronization2.0.0 o después.
  2. QRadar Data Synchronization 3.0.0 compatible con QRadar Dispositivos Network Insights que utilicen QRadar 7.5.0 Paquete de actualización 1 o posterior. Para obtener más información, consulta la sección «Emparejamiento de hosts gestionados ».
  3. El flujo de trabajo sólo por consola es compatible con QRadar Data Synchronization 3.2.0 y QRadar 7.5.0 Paquete de actualización 9
  4. La restauración de aplicaciones sólo de consola (aplicaciones alojadas en consola) para la configuración del tipo de dispositivo se admite a partir de QRadar Data Synchronization 3.2.2 y QRadar 7.5.0 Paquete de actualización 13. Si está actualizando la versión QRadar a QRadar 7.5.0 Paquete de actualización 13, entonces debe actualizar QRadar Data Synchronization a la última versión de v3.2.2.
  5. QRadar Data Synchronization 3.3.0 La versión y el paquete de actualización QRadar 14 de 7.5.0 introducen compatibilidad con flujos de trabajo de conmutación por error y conmutación por recuperación en una configuración híbrida (emparejamiento parcial).
  6. QRadar Data Synchronization 4.0.0 presenta la función «Panel de control de recuperación ante desastres», que ofrece comprobaciones previas automatizadas para verificar que el sistema está listo antes de iniciar una operación de conmutación por error o de retorno.

Soporte de alta disponibilidad (aplicación normal de QRadar Data Synchronization )

QRadar Data Synchronization 3.1.0 soporta alta disponibilidad (HA) para el escenario de emparejamiento normal (1:1). La lista siguiente proporciona directrices para HA.

  • La aplicación Sincronización de datos debe estar totalmente actualizada a la versión 3.1.0 antes de añadir hosts HA al despliegue.
  • Todas las funciones de sincronización de datos (emparejamiento, activación, recuperación tras error, reactivación, copia de Ariel, transferencia de copia de seguridad y restauración) funcionan cuando se añaden hosts de alta disponibilidad al despliegue.
  • El emparejamiento entre hosts que no son de alta disponibilidad en el sitio principal y hosts de alta disponibilidad en el sitio de destino está bloqueado y no está soportado. Sin embargo, puede emparejar hosts HA en el sitio principal con hosts no HA en el sitio de destino.
  • El proceso de restauración (a petición y restauración automática) no se puede completar, si el sitio principal no es HA y se ha añadido HA al sitio de destino después de que se emparejaran los hosts.
Importante: QRadar Data Synchronization sólo por consola no se integra con configuraciones de Alta Disponibilidad (HA) por las siguientes razones:
  • La HA no es compatible con la conmutación por error de sólo consola: Los usuarios deben eliminar HA del sitio de destino y del sitio principal antes de la operación de conmutación por error. Los usuarios pueden añadir la HA sólo cuando el proceso de conmutación por error se ha completado.
  • No se admite el proceso de failback de HA integrado: Los usuarios deben eliminar HA del sitio de destino y del sitio principal antes de la operación de failback. Los usuarios pueden añadir la HA sólo cuando el proceso de failback se ha completado.
  • En una configuración híbrida: los usuarios deben eliminar la alta disponibilidad del sitio de destino antes de la conmutación por error y eliminar la alta disponibilidad del sitio principal antes de la conmutación por recuperación.

Requisitos de despliegue del sitio de destino

El despliegue del sitio de destino debe ser un despliegue totalmente duplicado (proporción de host 1: 1) para los hosts que contienen o recopilan datos de Ariel (suceso y flujo), así como los hosts de QRadar Network Insights . Para obtener más información sobre la asignación d QRadar Network Insights, consulta «Emparejamiento de hosts gestionados ».
Importante: Para mantener una funcionalidad y un rendimiento equivalentes en el sitio de destino (recuperación ante desastres) durante una conmutación por error, la implementación de recuperación ante desastres debe contar con una licencia con una capacidad de eventos y flujos que coincida con la de la implementación del centro de datos (CD) principal. Es obligatorio disponer de una licencia válida de recuperación ante desastres (DR) para las implementaciones de sitios de destino de « QRadar ». La licencia DR debe proporcionar suficiente capacidad de procesamiento de eventos y flujos para dar cabida a toda la carga de trabajo del sitio principal. Es posible que las implementaciones con una licencia que ofrezca una capacidad de recuperación ante desastres (DR) reducida no puedan procesar el volumen total de eventos y flujos durante la conmutación por error, lo que puede dar lugar a limitaciones en la ingesta de datos y a una posible pérdida de eventos o flujos. Para obtener más información sobre los derechos de licencia de recuperación ante desastres ( QRadar ) de DR, ponte en contacto con el equipo de licencias de seguridad de QRadar ( Q1PD ).
Tabla 2. Requisitos de mapeo paraQRadar componentes
Componente Requiere una correlación 1:1
Procesador de sucesos Sí
Procesador de flujo Sí
Combo Event/Procesador de flujos Sí
Recopiladores de sucesos Sí
Recopiladores de flujo Sí
Consola QRadar Sí
Nodos de datos Sí
QRadar Network Insights Sí
QRadar Risk Manager Nee
QRadar Vulnerability Manager Nee
QRadar Incident Forensics Nee
Host de aplicación Nee

Un host de sitio de destino requiere un almacenamiento mayor o igual que su host de sitio principal emparejado.

Navegadores admitidos

QRadar Data Synchronization se apoya enGoogle Chrome yMozillaFirefox .

Utilización de puertos

QRadar Data Synchronization utiliza los puertos siguientes para comunicarse entre los sitios principal y de destino.

Tabla 3. Puertos utilizados por QRadar Data Synchronization
Puerto Protocolo Dirección Requisitos
22 TCP

Tráfico bidireccional entre la consola principal y la consola de destino.

Tráfico bidireccional entre el host gestionado principal y el host gestionado por destino emparejado.

 Configuración y sincronización de datos para la comunicación entre la consola principal y la consola de destino.

Sincronización de datos entre el host gestionado principal y el host gestionado por destino emparejado.
443 TCP Tráfico bidireccional entre la consola principal y la consola de destino. Acceso alQRadar API