Questions fréquentes sur la migration SOAR

Compatible avec :

Obtenez des réponses aux questions fréquentes sur le processus de migration SOAR. Découvrez des solutions aux problèmes courants et des bonnes pratiques pour une transition réussie.

Étendue 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, tels qu'une fiabilité accrue, une sécurité renforcée, une meilleure conformité et un contrôle des accès plus précis. Elle permet également d'accéder aux fonctionnalités d'IA agentique grâce à l'intégration du protocole MCP (Model Context Protocol).

La migration offre les avantages suivants :

  • Elle améliore la fiabilité et les capacités de surveillance de SOAR en utilisant la meilleure couche d'API de sa catégorie 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é.
  • Elle déverrouille le contrôle des accès basé sur les rôles (RBAC) pour les fonctionnalités et les données sur l'ensemble de la plate-forme.
  • Elle 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 : Quelle est l'étendue de la migration ?

La migration implique les composants suivants :

  • Migration du projet SOAR vers un projet appartenant au client Google Cloud .
  • Migration de l'authentification et des autorisations SOAR vers Google Cloud IAM.
  • Migration des API SOAR vers l'API Chronicle.
  • Migration des agents distants.
  • Migration des journaux d'audit SOAR.

Q : Quels sont les changements immédiats après la migration ?

Immédiatement après la migration, vous constaterez plusieurs changements clés :

  • Propriété du projet GCP : votre projet SOAR passera de la propriété de Google à votre projet appartenant au client Google Cloud .
  • Authentification :
    • Clients Unified SecOps : aucun changement. 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 qui utilisent SAML, cela signifie qu'ils devront adopter la fédération des identités des employés. 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 de groupes de fournisseurs d'identité (IdP).
  • Journalisation 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 inclut la date de migration et un lien vers un formulaire à remplir. Ils seront invités à confirmer la date et l'heure de leur migration.

Q : Nos coûts d'infrastructure changeront-ils du fait que SOAR est lié à notre Google Cloud projet ?

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 Google Cloud projet. Si vous êtes un client Unified SecOps, nous disposons déjà de l'ID de votre Google Cloud projet. Si vous êtes un client autonome de SOAR, vous devrez nous communiquer l'ID du 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 Google Cloud projet existant associé à votre SIEM. Cela permet une gestion unifiée des flux administratifs, tels que le RBAC et les journaux.

Q : Quelles sont les étapes nécessaires 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 stratégie VPC SC. Si votre Google Cloud projet dispose de VPC SC, contactez l'équipe d'assistance pour obtenir des conseils détaillés sur ces règles spécifiques.

Temps d'arrêt et continuité

Q : Y a-t-il un temps d'arrêt pendant la migration et quel est son impact ?

Oui. Le temps d'arrêt prévu est le suivant :

  • Jusqu'à deux heures pour les clients autonomes de SOAR.
  • 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 pause, mais les services SIEM continueront de s'exécuter en arrière-plan.

Q : Les données générées pendant le temps d'arrêt seront-elles automatiquement ingérées une fois les services SOAR rétablis ?

Oui. Une fois le système rétabli, l'ingestion et les playbooks reprendront et traiteront toutes les alertes générées ou ingérées pendant le temps d'arrêt.

Q : Que se passe-t-il pour les playbooks qui s'exécutent au début du temps d'arrêt ?

Le service de playbook sera désactivé avant le début de la migration. Certains playbooks en cours d'exécution peuvent échouer et devront être redémarrés manuellement ou reprendront une fois la migration terminée.

Q : Existe-t-il un plan de restauration ou de secours en cas de problème pendant la migration ?

Oui. Le processus de migration conserve votre instance SOAR existante intacte (bien que désactivée). Si le processus de migration ne se termine pas correctement, nous pouvons revenir à votre instance existante et supprimer la nouvelle. Ce processus de restauration prend jusqu'à 30 minutes. Nous effectuerons des tests approfondis et une surveillance étroite, avec du personnel d'astreinte en attente pour assurer la réussite de 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 vous coordonner avec votre identité, votre IdP ou votre Google Cloud administrateur pour utiliser le guide de dépannage afin d'identifier et de résoudre le problème. Si le problème persiste ou s'il n'est pas lié à l'accès, ouvrez un ticket d'assistance pour documenter le problème et suivre sa résolution.

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

Vous pouvez 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 assurer une transition fluide, suivez ces deux étapes obligatoires :

  1. Vous devez d'abord effectuer la migration des 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 correspondants de l'API Chronicle.

Authentification et autorisations

Q : Comment migrer mes groupes d'autorisations et mes autorisations SOAR ?

Vous utiliserez un script de migration dans votre Google Cloud console pour migrer les groupes d'autorisations existants vers des rôles personnalisés IAM. Le script attribue également des rôles personnalisés aux utilisateurs (pour les clients Cloud Identity) ou aux groupes IdP (pour les clients Fédération des identités des employés).

Q : Que se passe-t-il si je préfère ne pas migrer les groupes d'autorisations personnalisés et n'utiliser que des rôles prédéfinis ?

Vous pouvez désactiver la migration automatisée et mapper manuellement les groupes IdP aux rôles Cloud IAM.

Q : Nous sommes un client autonome de SOAR avec un fournisseur SAML personnalisé avec authentification manuelle. Si nous passons à 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 prérequis 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 des identités des employés 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 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'autoriser les adresses IP pour accéder à l'API Chronicle. Vous pouvez également autoriser la liste des plages d'adresses IP indiquées ici et ici.

Journalisation et surveillance

Q : Nous avons terminé la première étape de la migration, mais nous ne voyons pas les journaux dans 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 Google Cloud projet une fois la deuxième étape de la migration terminée.

Q : Les clients qui envoient des données SOAR à une instance BigQuery (BQ) gérée pourront-ils toujours accéder à ces données BigQuery après la migration ?

Oui. L'instance BigQuery gérée existante 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 : Recevrons-nous des mises à jour de 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 vous coordonner avec votre identité, votre IdP ou votre Google Cloud administrateur pour utiliser le guide de dépannage afin d'identifier et de résoudre le problème. Si le problème persiste ou s'il n'est pas lié à l'accès, ouvrez un ticket d'assistance pour documenter le problème 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 ?

Il existe deux raisons possibles à cela :

  • Autorisations manquantes : l'outil de migration nécessite que votre compte utilisateur dispose d'autorisations suffisantes dans le 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 un ticket d'assistance.

  • SIEM n'utilise pas Cloud IAM : si vous êtes un client Google SecOps unifié, 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 de fonctionnalité.

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

  • Erreur "Le groupe n'existe pas" : lorsque vous utilisez les 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 pas seulement le nom court du groupe.

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

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

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

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

Vérifiez 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.

Vous pouvez également examiner 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 documente l'autorisation manquante, et une bannière de notification s'affiche également dans l'interface, détaillant l'accès requis.

Si aucune de ces solutions ne vous aide, ouvrez un ticket 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 IAM manuelle peut parfois entraîner l'absence d'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 cela se produit-il ?

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

Pour assurer un accès de moindre privilège, procédez comme suit :

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

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

Après une migration réussie, la colonne Groupes d'autorisations s'affiche toujours sur la page Mappage de groupes pour assurer la rétrocompatibilité. Ne supprimez pas ces attributions. La colonne sera supprimée d'ici le 30 septembre 2026 sans aucun impact sur les clients.

Bonnes pratiques

  • Utiliser le script de migration : dans la mesure du possible, utilisez le script de migration officiel pour gérer la transition des groupes d'autorisations SOAR vers les rôles IAM. Google Cloud
  • Examiner les autorisations IAM : familiarisez-vous avec les autorisations IAM requises pour les différentes fonctions et rôles SOAR. Google Cloud
  • Tester de manière approfondie : après la migration, testez l'accès pour différents rôles et personas utilisateur afin de vous assurer que tout fonctionne comme prévu.
  • Contacter l'assistance : en cas d'erreurs persistantes 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.