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 des bonnes pratiques pour une transition réussie.
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, notamment une fiabilité accrue, une sécurité renforcée, une meilleure conformité et un contrôle des accès plus précis. Il donne également accès aux fonctionnalités d'IA agentive via l'intégration du protocole MCP (Model Context Protocol).
La migration fournit les éléments 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 dotée de fonctionnalités avancées pour la gestion des quotas, l'audit et l'observabilité.
- Débloque 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.
- Fournit des fonctionnalités de conformité plus avancé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 la portée de la migration ?
La migration implique les composants suivants :
- Migration du 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.
- Migration de l'infrastructure d'authentification des agents distants.
Q : Quels sont les changements immédiats après la migration ?
Immédiatement après la migration, vous constaterez plusieurs changements importants :
- Propriété du projet GCP : votre projet SOAR sera migré de la propriété de Google vers votre projet Google Cloud appartenant au client.
- Authentification :
- Clients SecOps unifié : aucun changement. L'authentification continuera d'être gérée par Google Cloud IAM.
- Clients SOAR Standalone : l'authentification sera désormais gérée par Google Cloud IAM. Pour les utilisateurs de 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 de l'utilisateur seront plus précises et 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).
- 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 de SOAR autonome recevront une nouvelle URL (nouveau domaine) pour accéder à SOAR.
Q : Comment les clients et les partenaires sont-ils informés de cette migration ?
Un pop-up s'affiche dans le produit pour tous les clients et partenaires. Il indique la date de migration et inclut un lien vers un formulaire à remplir. Ils seront invités à confirmer la date et le créneau horaire de leur 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 sur l'interface. Aucune nouvelle ressource ne sera exécutée dans votre projet, ce qui signifie qu'aucun coût ne sera associé.
Q : Comment connecter 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 disposent déjà d'un déploiement 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 une gestion unifiée des flux administratifs, tels que le RBAC 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.
Deux fonctionnalités de l'API ne sont pas compatibles avec VPC-SC :
- Webhooks
- Liens d'approbation du playbook
Q : Comment puis-je vérifier que la migration a bien été effectuée ?
Vérifiez que l'opération a bien été effectuée en accédant à Paramètres SOAR > Gestion des licences. Après l'étape 1, la mention Google.com s'affiche après le numéro de version du système. Après l'étape 2 de la migration des autorisations SOAR vers les rôles IAM , les mentions Google.com et CloudIAM Enabled s'afficheront après le numéro de version du système.
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 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 suspendus, 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 le temps d'arrêt.
Q : Qu'advient-il des playbooks en cours d'exécution lorsque le temps d'arrêt commence ?
Le service de playbook sera désactivé avant le début de la migration. Certains playbooks en cours d'exécution risquent d'échouer et devront être redémarrés manuellement ou reprendront une fois la migration terminée.
Q : Existe-t-il un plan de rollback ou d'urgence en cas de problème lors de la migration ?
Oui. Le processus de migration conserve votre instance SOAR existante intacte (bien que désactivée). Si le processus de migration échoue, nous pouvons revenir à votre instance existante et supprimer la nouvelle. Ce processus de rollback peut prendre jusqu'à 30 minutes. Nous effectuerons des tests approfondis et une surveillance étroite, avec du personnel d'astreinte en attente pour garantir une migration réussie.
Si vous rencontrez des problèmes d'accès après la migration, il est probable que votre configuration d'authentification soit incorrecte. Vous devrez vous coordonner avec votre administrateur d'identité, d'IdP ou Google Cloud 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 une demande 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 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 anciennes clés API seront obsolètes et ne fonctionneront plus après le 31 mars 2027. Pour faciliter la transition, suivez ces deux étapes obligatoires :
- Vous devez d'abord terminer la migration des groupes d'autorisations SOAR vers Cloud IAM.
- 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 allez utiliser 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 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 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 SOAR autonome avec un fournisseur SAML personnalisé et une authentification manuelle. Si nous remplaçons cette option par "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 d'identités 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'ajouter des adresses IP à la 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 Cloud Audit Logs.
Les journaux sont stockés dans la plate-forme SOAR une fois la première étape de migration terminée. Les journaux sont disponibles dans votre projet Google Cloud une fois la deuxième étape de 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. 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 d'effectuer la migration en dehors des créneaux horaires suggérés.
Q : Recevrons-nous 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 si un problème survient après la migration ?
Si vous rencontrez des problèmes d'accès après la migration, la configuration de l'authentification est probablement incorrecte. Vous devrez vous coordonner avec votre administrateur d'identité, d'IdP ou Google Cloud 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 une demande 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 console Google Cloud ?
Deux raisons peuvent expliquer cette situation :
Autorisations manquantes : l'outil de migration nécessite que votre compte utilisateur dispose d'autorisations suffisantes à la fois dans 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.
Le 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 du côté SIEM de la plate-forme. Pour en savoir plus, consultez le guide de migration du RBAC hérité 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
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'option--member, et pas seulement le nom court du groupe.Erreurs liées à des rôles préexistants : des conflits peuvent se produire 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 veillez à sélectionner Aucune au lieu de Spécifier une nouvelle condition.
Problèmes d'accès après la migration
Q : Pourquoi est-ce que je reçois une erreur "403 Forbidden" (403 Interdit) 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 le côté SOAR de la plate-forme Google SecOps. C'est souvent le cas 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 pour les développeurs 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 fonctionne, envoyez une demande d'assistance.
Autorisations et rôles
Q : J'ai effectué la migration IAM manuellement sans utiliser l'outil fourni, et je rencontre 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 dans SOAR que prévu 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 Google Cloud Chronicle prédéfinis 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 d'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 :
- 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 comptes principaux (utilisateurs et groupes) attribués.
- Vérifiez que seuls les utilisateurs ayant besoin d'autorisations SOAR sont attribués à ces rôles.
- 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 de groupes pour assurer la rétrocompatibilité. Ne supprimez pas ces attributions. La colonne sera supprimée d'ici le 31 mars 2027, sans 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.
- Vérifier les autorisations IAM : familiarisez-vous avec les autorisations IAM Google Cloud requises pour les différents rôles et fonctions SOAR.
- Effectuez des tests approfondis : après la migration, testez l'accès pour différents rôles et personas d'utilisateurs afin de vous assurer que tout fonctionne comme prévu.
- Contacter l'assistance : pour toute erreur persistante ou tout comportement inattendu, contactez l'assistance en fournissant autant de détails que possible.
Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.