Questions fréquentes sur la migration SOAR

Compatible avec :

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.
  • Migrer l'authentification et les 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 utilisateur 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. 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 un 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 ont déjà déployé Google SecOps, devons-nous utiliser le même ID de projet que pour le 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 de gérer de manière unifiée les flux administratifs, tels que le contrôle d'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. Si votre projet Google Cloud utilise VPC-SC, contactez l'équipe d'assistance pour obtenir des conseils détaillés sur ces règles spécifiques.

Q : Comment puis-je vérifier que la migration a réussi ?

Pour vérifier que l'opération a réussi, accédez à Paramètres SOAR> Gestion des licences. Après l'étape 1, Google.com s'affiche après le numéro de version du système. Après la migration des autorisations SOAR vers les rôles IAM lors de l'étape 2 , les mentions Google.com et CloudIAM activé s'afficheront après le numéro de version du système.

Temps d'arrêt et continuité

Q : Y aura-t-il un temps d'arrêt pendant la migration et 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 procédure 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 garantir une migration réussie.

Si vous rencontrez des problèmes d'accès après la migration, il est probable que la configuration de l'authentification soit incorrecte. Vous devrez coordonner avec votre administrateur d'identité, d'IdP ou de Google Cloud pour utiliser le guide de dépannage afin d'identifier et de résoudre les problèmes. Si le problème persiste ou n'est pas lié à l'accès, ouvrez une demande d'assistance pour le signaler et suivre sa résolution.

Q : Quand pourrai-je migrer vers les nouveaux points de terminaison SOAR v1 dans l'API Chronicle ?

Vous pourrez migrer vers les nouveaux points de terminaison SOAR v1 dans l'API Chronicle à partir de mi-janvier 2026.

L'ancienne API SOAR et les clés API seront obsolètes et ne fonctionneront plus après le 30 septembre 2026. Pour faciliter la transition, suivez ces deux étapes obligatoires :

  1. Vous devez d'abord migrer les groupes d'autorisations SOAR vers Cloud IAM.
  2. Mettez à jour vos scripts et intégrations existants pour remplacer les anciens points de terminaison de l'API SOAR par les points de terminaison de l'API Chronicle correspondants.

Authentification et autorisations

Q : Comment migrer mes groupes et autorisations SOAR ?

Vous utiliserez un script de migration 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 Workforce Identity Federation).

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 est associé à un sous-domaine différent. Pour en savoir plus, consultez le guide de migration des MSSP.

Q : Comment m'authentifier auprès de l'API Chronicle ?

Suivez les instructions de la section S'authentifier auprès de l'API Chronicle.

Q : Quelles sont les nouvelles adresses IP requises pour accéder à la nouvelle API SOAR ? Il n'est pas nécessaire d'ajouter des adresses IP à une liste d'autorisation pour accéder à l'API Chronicle. Vous pouvez éventuellement ajouter à la liste d'autorisation la plage d'adresses IP indiquée ici et ici.

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 seront 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 en temps réel pendant la migration ?

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 ?

Si vous rencontrez des problèmes d'accès après la migration, il est probable que la configuration de l'authentification soit incorrecte. Vous devrez coordonner avec votre administrateur d'identité, d'IdP ou de Google Cloud pour utiliser le guide de dépannage afin d'identifier et de résoudre les problèmes. Si le problème persiste ou n'est pas lié à l'accès, ouvrez une demande d'assistance pour le signaler et suivre sa résolution.

Migrer les groupes d'autorisations SOAR vers IAM

La section suivante traite des problèmes courants rencontrés pendant et après la migration des autorisations vers IAM.

Problèmes liés à l'outil et au script de migration

Q : Pourquoi ne puis-je pas voir ni charger le script de migration dans la Google Cloud Console ?

Deux raisons peuvent expliquer ce problème :

  • Autorisations manquantes : l'outil de migration exige que votre compte utilisateur dispose d'autorisations suffisantes dans l'instance Google Cloud et dans l'instance Google SecOps. Assurez-vous d'être connecté avec un compte disposant des rôles IAM requis dans Google Cloud et qui est également un utilisateur reconnu dans Google SecOps SOAR. L'utilisation de comptes différents pour Google Cloud et SOAR peut entraîner des échecs d'autorisation. Si vous disposez des autorisations requises et que vous ne parvenez toujours pas à charger le script de migration, ouvrez une demande d'assistance.

  • SIEM n'utilise pas Cloud IAM : si vous êtes un client Google SecOps Unified, assurez-vous d'utiliser IAM pour gérer les rôles et les autorisations pour la partie SIEM de la plate-forme. Pour en savoir plus, consultez le guide de migration de l'ancien RBAC vers le RBAC des fonctionnalités.

Q : Je reçois un message d'erreur lorsque j'essaie d'exécuter les scripts de migration. Que dois-je faire ?

  • Erreur : "Le groupe n'existe pas" : lorsque vous utilisez add-iam-policy-binding commands, assurez-vous d'utiliser l'adresse e-mail complète du groupe (par exemple, your-group@example.com) pour l'indicateur --member, et non pas uniquement le nom abrégé du groupe.

  • Erreurs liées aux rôles préexistants : des conflits peuvent survenir lors de la liaison à un compte principal qui possède déjà des liaisons conditionnelles. Pour résoudre ce problème, réexécutez le script et assurez-vous de sélectionner Aucune au lieu de Spécifier une nouvelle condition.

Problèmes d'accès après la migration

Q : Pourquoi l'erreur "403 Forbidden" s'affiche-t-elle lorsque j'essaie d'accéder à certaines pages ou fonctionnalités (comme les playbooks ou l'IDE) après la migration IAM ?

Une erreur 403 après la migration peut indiquer que le rôle IAM Google Cloud attribué à votre utilisateur ne dispose pas des autorisations requises par la partie SOAR de la plate-forme Google SecOps. Cela arrive souvent si vous utilisez des rôles IAM personnalisés.

Consultez les rôles et autorisations Google SecOps. Assurez-vous que votre rôle IAM personnalisé inclut toutes les autorisations nécessaires pour accéder aux fonctionnalités SOAR requises.

Si vous le souhaitez, examinez les outils de développement de votre navigateur pour identifier les appels d'API spécifiques qui renvoient une erreur 403. La charge utile de la réponse indique l'autorisation manquante, et une bannière de notification s'affiche également dans l'interface pour détailler l'accès requis.

Si aucune de ces solutions ne vous aide, ouvrez une demande d'assistance.

Autorisations et rôles

Q : J'ai effectué la migration IAM manuellement sans utiliser l'outil fourni, et j'ai maintenant des problèmes d'autorisation. Comment résoudre ce problème ?

La migration manuelle d'IAM peut parfois entraîner l'absence des autorisations nécessaires pour les rôles SOAR. Nous vous recommandons vivement d'utiliser le script de migration fourni pour vous assurer que toutes les autorisations requises sont correctement configurées. Si vous prévoyez toujours d'effectuer une migration manuelle, examinez attentivement les autorisations IAM Google SecOps pour créer les rôles personnalisés avec les autorisations nécessaires.

Q : Certains utilisateurs semblent disposer de plus d'autorisations que prévu dans SOAR après la migration. Pourquoi ce changement ?

Cela peut se produire si des utilisateurs ou des groupes ont déjà été attribués à des rôles généraux prédéfinis dans Chronicle  Google Cloud avant la migration. Une fois la migration terminée, les rôles prédéfinis Chronicle (tels que chronicle.apiAdmin) incluent automatiquement les autorisations SOAR. Par exemple, le rôle "Administrateur de l'API Chronicle" inclut désormais les autorisations d'administrateur SOAR.

Pour assurer un accès de moindre privilège, procédez de la façon suivante :

  1. Consultez vos rôles prédéfinis sur la page Rôles IAM, y compris le rôle "Administrateur de l'API Chronicle", pour identifier tous les principaux (utilisateurs et groupes) attribués.
  2. Vérifiez que seuls les utilisateurs ayant besoin d'autorisations SOAR sont attribués à ces rôles.
  3. Pour limiter l'accès SOAR pour des comptes principaux spécifiques, supprimez-les des rôles prédéfinis et attribuez-leur un rôle personnalisé qui exclut explicitement les autorisations d'administrateur SOAR.

Q : La migration a réussi, mais la colonne "Groupes d'autorisations" s'affiche toujours sur la page "Mappage des groupes". Pourquoi ?

Une fois la migration terminée, la colonne Groupes d'autorisations s'affiche toujours sur la page Mappage des groupes pour assurer la rétrocompatibilité. Ne supprimez pas ces devoirs. La colonne sera supprimée d'ici le 30 septembre 2026, sans aucun impact sur les clients.

Bonnes pratiques

  • Utilisez le script de migration : dans la mesure du possible, utilisez le script de migration officiel dans Google Cloud pour gérer la transition des groupes d'autorisations SOAR vers les rôles IAM.
  • Examiner les autorisations IAM : familiarisez-vous avec les autorisations IAM Google Cloud requises pour les différentes fonctions et rôles SOAR.
  • Testez minutieusement : après la migration, testez l'accès pour différents rôles et personas d'utilisateur afin de vous assurer que tout fonctionne comme prévu.
  • Contacter l'assistance : en cas d'erreur persistante ou de comportement inattendu, contactez l'assistance et fournissez autant de détails que possible.

Vous avez encore besoin d'aide ? Obtenez des réponses auprès des membres de la communauté et des professionnels Google SecOps.