Questions fréquentes sur la migration SOAR
Obtenez des réponses aux questions fréquentes sur le processus de migration SOAR. Trouvez des solutions aux problèmes fréquents et découvrez les bonnes pratiques pour réussir votre transition.
Champ d'application et impact de la migration
Q : Pourquoi cette migration est-elle nécessaire ?
Nous modernisons l'infrastructure SOAR en migrant vers Google Cloud. Cette mise à niveau essentielle offre des avantages clés, y compris une fiabilité accrue, une sécurité améliorée, une meilleure conformité et un contrôle des accès plus précis. Il permet également d'accéder aux fonctionnalités d'IA agentive grâce à l'intégration du protocole MCP (Model Context Protocol).
La migration offre les avantages suivants :
- Améliore la fiabilité et les capacités de surveillance de SOAR en utilisant la couche d'API de pointe de Google. Cette couche fournit une solution d'API de pointe avec des fonctionnalités avancées pour la gestion des quotas, l'audit et l'observabilité.
- Déverrouille le contrôle des accès basé sur les rôles (RBAC) pour les fonctionnalités et les données de l'ensemble de la plate-forme.
- Offre des fonctionnalités de conformité plus élevées, telles que VPC Service Controls, la résidence des données et les clés de chiffrement gérées par le client (CMEK).
Q : Quel est le champ d'application de la migration ?
La migration implique les composants suivants :
- Migration d'un projet SOAR vers un projet Google Cloud appartenant au client.
- Migration de l'authentification et des autorisations SOAR vers Google Cloud IAM.
- Migrer les API SOAR vers l'API Chronicle
- Migrer des agents distants
- Migration des journaux d'audit SOAR.
Q : Quels sont les changements immédiats après la migration ?
Après la migration, vous constaterez plusieurs changements clés :
- Propriété du projet GCP : votre projet SOAR sera transféré de la propriété de Google vers votre projet Google Cloud .
- Authentification :
- Clients Unified SecOps : rien ne change. L'authentification continuera d'être gérée par Google Cloud IAM.
- Clients SOAR autonome : l'authentification sera désormais gérée par Google Cloud IAM. Pour les utilisateurs de SAML, cela signifie qu'ils doivent adopter la fédération d'identité de personnel. La configuration SAML ne sera plus stockée ni gérée dans le système SOAR lui-même, ce qui renforcera les contrôles de sécurité.
- RBAC : les autorisations des utilisateurs deviendront plus précises et seront gérées à l'aide d'IAM. Les environnements et les rôles SOC continueront d'être gérés dans le module SOAR à l'aide des groupes de fournisseurs d'identité (IdP).
- Journaux d'audit : les journaux d'audit seront plus détaillés et gérés dans **Cloud Audit Logs **.
- Nouvelle URL (SOAR uniquement) : les utilisateurs autonomes de SOAR recevront une nouvelle URL (nouveau domaine) pour accéder à SOAR.
Q : Comment les clients / partenaires sont-ils informés de cette migration ?
Une fenêtre pop-up s'affiche dans le produit pour tous les clients et partenaires. Elle indique la date de migration et inclut un lien vers un formulaire à remplir. Il sera invité à confirmer la date et la plage horaire de la migration.
Q : Nos coûts d'infrastructure vont-ils changer du fait que SOAR est lié à notre projet Google Cloud ?
Non, vos coûts ne seront pas affectés. Vous ne devriez constater aucun changement au niveau de l'interface utilisateur. Aucune nouvelle ressource ne s'exécutera dans votre projet, il n'y aura donc aucun coût associé.
Q : Comment associer notre projet à SOAR ?
Google migrera votre projet SOAR vers votre projet Google Cloud . Si vous êtes client Unified SecOps, nous disposons déjà de l'ID de votre projet Google Cloud . Si vous êtes un client SOAR autonome, vous devrez nous communiquer l'ID de votre projet Google Cloud .
Q : Pour les clients qui disposent déjà d'un déploiement Google SecOps, devons-nous utiliser le même ID de projet que pour SIEM ou avons-nous besoin d'un projet distinct ?
Pour un déploiement Google SecOps unifié (un SIEM, un SOAR), vous devez utiliser l'ID de projet Google Cloud existant associé à votre SIEM. Cela permet une gestion unifiée des flux administratifs, tels que le contrôle des accès basé sur les rôles et les journaux.
Q : Quelles sont les étapes à suivre pour les instances Google SecOps avec des considérations spéciales telles que VPC Service Controls (VPC SC) ?
Pour activer la migration, vous devez définir des règles d'Ingress et de sortie dans votre règle VPC-SC. Pour obtenir des informations détaillées sur ces règles spécifiques, veuillez contacter l'équipe d'assistance.
Temps d'arrêt et continuité
Q : Y aura-t-il un temps d'arrêt pendant la migration ? Quel sera son impact ?
Oui. Voici le temps d'arrêt prévu :
- Jusqu'à deux heures pour les clients SOAR autonomes.
- Jusqu'à 1,5 heure pour les clients Google SecOps.
Pendant cette période, vous ne pourrez pas vous connecter à la plate-forme. Les services SOAR (y compris l'ingestion, les playbooks et les jobs) seront mis en veille, mais les services SIEM continueront de s'exécuter en arrière-plan.
Q : Les données générées pendant l'indisponibilité seront-elles automatiquement ingérées une fois les services SOAR rétablis ?
Oui. Une fois le système de nouveau en ligne, l'ingestion et les playbooks reprendront et traiteront toutes les alertes générées ou ingérées pendant l'indisponibilité.
Q : Qu'advient-il des playbooks en cours d'exécution lorsque l'indisponibilité commence ?
Le service de playbook sera désactivé avant le début de la migration. Il est possible que certains playbooks en cours d'exécution échouent et devront être redémarrés manuellement ou reprendront une fois la migration terminée.
Q : Existe-t-il un plan de rollback ou de secours en cas de problème lors de la migration ?
Oui. Le processus de migration préserve l'intégralité de votre instance SOAR existante (bien qu'elle soit désactivée). Si le processus de migration n'aboutit pas, nous pouvons revenir à votre instance existante et supprimer la nouvelle. Cette opération de rétablissement prend jusqu'à 30 minutes. Nous effectuerons des tests approfondis et une surveillance étroite, avec du personnel d'astreinte en cas de besoin, pour assurer une migration réussie.
Q : Quand pourrai-je migrer vers les nouveaux points de terminaison SOAR dans l'API Chronicle ?
Un accès anticipé aux nouveaux points de terminaison SOAR de l'API Chronicle V1 bêta sera disponible à partir du 1er novembre 2025. L'accès général à l'API Chronicle V1 sera disponible à partir du 1er janvier 2026. Vous devez effectuer la migration des groupes d'autorisations SOAR vers Cloud IAM avant de migrer depuis l'ancienne API SOAR. Vous devez mettre à jour vos scripts et intégrations pour remplacer les points de terminaison de l'API SOAR par les points de terminaison de l'API Chronicle correspondants. L'ancienne API SOAR et les clés API fonctionneront jusqu'au 30 juin 2026.
Authentification et autorisations
Q : Comment migrer mes groupes d'autorisations et mes autorisations SOAR ?
Nous préparons un assistant de migration à utiliser dans votre console Google Cloud pour migrer les groupes d'autorisations existants vers des rôles IAM personnalisés. Le script attribue également des rôles personnalisés aux utilisateurs (pour les clients Cloud Identity) ou aux groupes IdP (pour les clients de la fédération des identités des employés).
Q : Que faire si je préfère ne pas migrer les groupes d'autorisations personnalisés et n'utiliser que les rôles prédéfinis ?
Vous pouvez désactiver la migration automatique et mapper manuellement les groupes IdP aux rôles Cloud IAM.
Q : Nous sommes un client SOAR autonome avec un fournisseur SAML personnalisé et une authentification manuelle. Si nous remplaçons les groupes Google par des groupes IdP pour le mappage IdP, quel sera l'impact sur les comptes utilisateur existants ?
Si vos utilisateurs existants correspondent à l'un des groupes et que les autorisations sont correctement mappées, vos comptes utilisateur préexistants ne devraient pas être affectés. Toutefois, si les utilisateurs ne sont pas mappés à des groupes, ils ne pourront pas se connecter. Si les autorisations sont mappées différemment, les utilisateurs recevront de nouvelles autorisations en fonction du nouveau mappage.
Q : Existe-t-il des conditions préalables spécifiques pour les MSSP qui utilisent plusieurs fournisseurs d'identité ?
Les clients qui ont configuré plusieurs fournisseurs d'identité sur la page d'authentification externe SOAR doivent définir la fédération d'identité de personnel pour l'authentification et créer un pool de personnel distinct pour chaque fournisseur. Chaque fournisseur sera associé à un sous-domaine différent.
Journalisation et surveillance
Q : Nous avons terminé la première étape de la migration, mais nous ne voyons pas de journaux dans les journaux Cloud Audit Logs.
Les journaux sont stockés dans la plate-forme SOAR une fois la première étape de la migration terminée. Les journaux deviennent disponibles dans votre projet Google Cloud une fois la deuxième étape de la migration terminée.
Q : Les clients qui envoient des données SOAR à une instance Managed BigQuery (BQ) pourront-ils toujours accéder à ces données BigQuery après la migration ?
Oui. Le BigQuery géré existant continuera de fonctionner.
Logistique et assistance
Q : Puis-je choisir un autre créneau horaire pour la migration ?
Non. Il n'est pas possible de migrer en dehors des créneaux horaires suggérés.
Q : Recevrai-je des informations sur l'état de la migration en temps réel ?
Vous recevrez une notification par e-mail au début et à la fin du processus de migration.
Q : Qui devons-nous contacter en cas de problème après la migration ?
Vous devez créer une demande d'assistance pour consigner le problème et suivre sa résolution.
Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.