Environnements pris en charge pour QRadar Data Synchronization
Pour que l'application fonctionne correctement, vous devez utiliser un logiciel pris en chargeIBM®QRadar® version, un navigateur Web pris en charge et répondre aux exigences du site de destination.
Versions prises en charge deQRadar
L' applicationIBM QRadar Data Synchronization est installée séparément sur le site principal et sur le site de destination.
Le tableau suivant décrit quelle version deQRadar Data Synchronization à utiliser avecQRadar .| Version de synchronisation des données | Version de QRadar |
|---|---|
| 4.0.0 ou version ultérieure | QRadar 7.6.0 ou version ultérieure |
| 3.3.0 | QRadar 7.5.0 Mise à jour du package 14 ou version ultérieure |
| 3.2.2 | QRadar 7.5.0 Update Package 13 ou ultérieur |
| 3.2.0 | QRadar 7.5.0 Update Package 9 ou ultérieur |
| 3.0.0 | QRadar 7.5.0 Update Package 1 ou ultérieur |
| 2.0.0 | QRadar 7.4.2 ou plus tard |
Un déploiement avec des domaines nécessiteQRadar7.4.2 ou plus tard etQRadar Data Synchronization2.0.0 ou plus tard.
QRadar Data Synchronization3.0.0 les soutiensQRadar Network Insights appareils qui utilisentQRadar7.5.0 Mettez à jour le package 1 ou version ultérieure. Pour plus d'informations, consultez la section « Association d'hôtes gérés ».
Important :
- QRadar Data Synchronization n'est pas pris en charge sur QRadar on Cloud
Nouvelles fonctionnalités et version supportée
Les nouvelles fonctionnalités suivantes ont été ajoutées :
- Un déploiement avec des domaines nécessiteQRadar7.4.2 ou plus tard etQRadar Data Synchronization2.0.0 ou plus tard.
- QRadar Data Synchronization 3.0.0 supports QRadar Les appliances Network Insights qui utilisent QRadar 7.5.0 Update Package 1 ou ultérieur. Pour plus d'informations, consultez la section « Association d'hôtes gérés ».
- Le flux de travail en mode console uniquement est pris en charge à partir de QRadar Data Synchronization 3.2.0 et QRadar 7.5.0 Paquet de mise à jour 9
- La restauration des applications hébergées sur la console pour la configuration du type d'appareil est prise en charge à partir de QRadar Data Synchronization 3.2.2 et QRadar 7.5.0 Paquet de mise à jour 13. Si vous mettez à niveau la version QRadar vers QRadar 7.5.0 Update Package 13, vous devez alors mettre à niveau QRadar Data Synchronization vers la dernière version de v3.2.2.
- QRadar Data Synchronization 3.3.0 La version et le QRadar 7.5.0 Update Package 14 introduisent la prise en charge des workflows de basculement et de reprise dans une configuration hybride (appairage partiel).
- QRadar Data Synchronization 4.0.0 présente la fonctionnalité « Tableau de bord de reprise après sinistre », qui propose des vérifications préalables automatisées permettant de s'assurer que le système est prêt avant de lancer une opération de basculement ou de retour en production.
Prise en charge de la haute disponibilité (Normal QRadar Data Synchronization app)
QRadar Data Synchronization 3.1.0 prend en charge la haute disponibilité (HA) pour le scénario d'appariement normal (1:1). La liste suivante fournit des instructions pour la haute disponibilité.
- L'application Data Synchronization doit être entièrement mise à niveau vers la version 3.1.0 avant d'ajouter des hôtes à haute disponibilité au déploiement.
- Toutes les fonctionnalités de synchronisation de données (appariement, activation, reprise par restauration, réactivation, copie Ariel, transfert de sauvegarde et restauration) fonctionnent lorsque des hôtes à haute disponibilité sont ajoutés au déploiement.
- L'appariement entre les hôtes sans haute disponibilité sur le site principal et les hôtes à haute disponibilité sur le site de destination est bloqué et n'est pas pris en charge. Toutefois, vous pouvez apparier des hôtes à haute disponibilité sur le site principal avec des hôtes sans haute disponibilité sur le site de destination.
- Le processus de restauration (à la demande et restauration automatique) ne peut pas aboutir si le site principal n'est pas à haute disponibilité et que la haute disponibilité a été ajoutée au site de destination après la mise en paire des hôtes.
Important : la QRadar Data Synchronization en mode console uniquement ne s'intègre pas aux configurations de haute disponibilité (HA) pour les raisons suivantes :
- HA n'est pas pris en charge dans le cadre du basculement de la console uniquement : Les utilisateurs doivent supprimer HA du site de destination et du site principal avant l'opération de basculement. Les utilisateurs ne peuvent ajouter l'AH que lorsque le processus de basculement est terminé.
- Le processus intégré de reprise après sinistre n'est pas pris en charge : Les utilisateurs doivent supprimer HA du site de destination et du site principal avant l'opération de failback. Les utilisateurs ne peuvent ajouter l'AH qu'une fois le processus de basculement terminé.
- Dans une configuration hybride : les utilisateurs doivent supprimer la haute disponibilité du site de destination avant le basculement et supprimer la haute disponibilité du site principal avant la reprise.
Exigences de déploiement du site de destination
Le déploiement du site de destination doit être un déploiement en double (rapport d'hôte 1: 1) pour les hôtes qui contiennent ou collectent des données Ariel (événement et flux) ainsi que des hôtes QRadar Network Insights . Pour plus d'informations sur le mappage « QRadar Network Insights », consultez la section «Appairage des hôtes gérés ».
Important : afin de garantir des fonctionnalités et des performances équivalentes sur le site de destination (reprise après sinistre) lors d'un basculement, le déploiement de reprise après sinistre doit disposer d'une licence offrant une capacité en termes d'événements et de flux correspondant à celle du déploiement du centre de données (DC) principal. Une licence de reprise après sinistre (DR) valide est obligatoire pour les déploiements sur un site de destination d' QRadar. La licence DR doit offrir une capacité de traitement des événements et des flux suffisante pour prendre en charge l'intégralité de la charge de travail du site principal. Les déploiements disposant d'une licence avec une capacité de reprise après sinistre (DR) réduite pourraient ne pas être en mesure de traiter l'intégralité du volume d'événements et de flux lors d'un basculement, ce qui peut entraîner des limitations au niveau de l'ingestion des données et une perte potentielle d'événements ou de flux. Pour plus d'informations sur les droits de licence DR d' QRadar, veuillez contacter l'équipe chargée des licences de sécurité d' QRadar ( Q1PD ).
| Composant | Nécessite un mappage 1:1 |
|---|---|
| Processeur d'événements | Oui |
| Processeur de flux | Oui |
| Combo Event/Processeur de flux | Oui |
| Collecteurs d'événements | Oui |
| Collecteurs de flux | Oui |
| Console QRadar | Oui |
| Noeuds de données | Oui |
| QRadar Network Insights | Oui |
| QRadar Risk Manager | Non |
| QRadar Vulnerability Manager | Non |
| QRadar Incident Forensics | Non |
| Hôte d'application | Non |
Un hôte de site de destination nécessite un stockage égal ou supérieur à l'hôte de site principal apparié.
Navigateurs pris en charge
QRadar Data Synchronization est pris en charge surGoogle Chrome etMozillaFirefox .
Utilisation du port
QRadar Data Synchronization utilise les ports suivants pour communiquer entre les sites principal et de destination.
| Port | Protocole | Direction | Exigences |
|---|---|---|---|
| 22 | TCP | Trafic bidirectionnel entre la console principale et la console de destination. Trafic bidirectionnel entre l'hôte géré principal et l'hôte géré par destination apparié. |
Configuration et synchronisation des données pour la communication entre la console principale et la console de destination. Synchronisation des données entre l'hôte géré principal et l'hôte géré par destination apparié. |
| 443 | TCP | Trafic bidirectionnel entre la console principale et la console de destination. | Accès auQRadar API |