Guide de validation avant la migration

Compatible avec :

Google SecOps SOAR

Ce document décrit une approche de diagnostic systématique et détaillée pour valider la configuration de l'instance et de l'authentification Google Security Operations avant la migration SOAR. Ce guide se concentre sur la norme SAML et OIDC utilisée pour l'authentification et l'autorisation des utilisateurs.

Validation de la configuration de l'API Chronicle

Pour vérifier si l'API Chronicle est correctement configurée dans votre projet Google Cloud , procédez comme suit :

1. Connectez-vous à la consoleGoogle Cloud et sélectionnez le projet Google Cloud approprié dans la liste Projet de la barre de navigation supérieure.
2. Ouvrez le menu de navigation (≡) et accédez à API et services > API et services activés.
3. Accédez à la liste des API et services activés pour trouver Chronicle API.

4. Si elle figure dans la liste : l'API est activée.

   Si elle ne figure PAS dans la liste : cliquez sur + ACTIVER LES API ET LES SERVICES en haut de la page, recherchez Chronicle API, puis cliquez sur Activer.

Pour vérifier si le compte de service a été créé :

1. Accédez à la page IAM dans la console Google Cloud .
2. Afficher les comptes masqués (étape cruciale) : vous devez cocher la case Inclure les attributions de rôles fournies par Google à droite de la barre de filtres.
3. Recherchez l'agent : saisissez chronicle dans la barre de filtre. Vous recherchez une adresse e-mail qui correspond à ce modèle spécifique : service-[PROJECT_NUMBER]@gcp-sa-chronicle.iam.gserviceaccount.com
4. Vérifiez les autorisations : assurez-vous qu'il dispose du rôle Agent de service Chronicle. Si le rôle est manquant, cliquez sur Modifier Modifier et ajoutez-le.

Validation de la configuration de Google SecOps

1. Dans la console Google Cloud , sélectionnez le projet Google Cloud approprié dans la liste.
2. Accédez à Sécurité > Google SecOps. L'onglet Authentification unique s'affiche.
3. Si Google SecOps est activé, un onglet Authentification unique devrait s'afficher. Si ce n'est pas le cas, l'initiation du prospect est incomplète. Indiquez l'ID du projet Google Cloud dans le formulaire Google accessible depuis la notification dans le produit. Confirmez la date et le créneau horaire de la migration, puis envoyez le formulaire. Si vous ne recevez pas de réponse dans les 72 heures suivant l'envoi, contactez [e-mail].
4. Si l'onglet existe, cliquez sur Accéder à SecOps. Si vous parvenez à vous connecter, cela signifie que la configuration de l'authentification est correcte. Si la connexion échoue, utilisez la section suivante pour déboguer la configuration. Si la connexion échoue, utilisez la section suivante pour déboguer la configuration.

Flux SAML et dépannage

Cette section présente le processus d'authentification SAML et décrit une approche systématique pour diagnostiquer et résoudre les problèmes de configuration courants.

Architecture du workflow d'authentification

Il est essentiel de comprendre le flux de requêtes pour isoler les points de défaillance. Le diagramme suivant illustre le chemin séquentiel d'une connexion réussie.

Procédure de dépannage détaillée

Pour diagnostiquer et suivre efficacement le processus d'authentification SAML, vous pouvez utiliser les utilitaires Web listés dans les sections suivantes.

Bien que Google n'approuve aucun produit en particulier, les outils suivants sont connus pour faciliter le dépannage du processus :

• Validation SAML : https://www.samltool.io/
  • Objectif : décoder et valider les requêtes et réponses SAML brutes.
• Inspection JWT : https://www.jwt.io/
  • Objectif : permet d'inspecter les revendications et le contenu des jetons Web JSON (JWT).

Phase 1 : Préparation de l'environnement

Avant de commencer, assurez-vous que votre environnement de navigateur est prêt à capturer le trafic réseau en procédant comme suit :

1. Ouvrez un nouvel onglet de navigateur ou utilisez une fenêtre de navigation privée.

2. Ouvrez les outils pour les développeurs à l'aide du raccourci de votre système d'exploitation :

   • Windows : appuyez sur F12.
   • Linux : appuyez sur Ctrl+Maj+I.
   • macOS : appuyez sur Cmd+Option+I.

3. Accédez à l'onglet Réseau.

4. Cochez la case Conserver le journal pour vous assurer qu'aucune donnée n'est perdue lors des redirections.

   

5. Accédez à l'URL de votre environnement Google SecOps pour lancer le processus de connexion. Vous recevrez cette URL par e-mail une fois que vous aurez terminé la configuration de Google SecOps à l'étape 5 de la phase de migration 1 pour les clients SOAR autonomes. L'objet de l'e-mail est Your Google SecOps instance is ready.

Phase 2 : Valider la requête SAML auprès de l'IdP

Cette étape permet de vérifier le message initial envoyé par Google Cloud à votre fournisseur d'identité (IdP).

1. Localisez la requête : dans la barre de filtres de l'onglet Réseau, recherchez saml.

   

2. Extraire des données : sélectionnez la requête, puis cliquez sur l'onglet Charge utile. Localisez le paramètre de chaîne de requête intitulé SAMLRequest.

   

3. Décoder : copiez la valeur de la requête et collez-la dans l'outil Validation SAML (samltool.io) pour la décoder.

   

4. Validation :

   • Vérifiez la destination de la demande.
   • Vérifiez que cette URL correspond aux paramètres de configuration de votre IdP.

Phase 3 : Valider la réponse SAML de l'IdP

Cette étape permet de vérifier les attributs renvoyés par le fournisseur d'identité à Google Cloud après l'authentification.

1. Localisez la réponse : dans la barre de filtre de l'onglet Réseau, recherchez signin-callback.

   

2. Extraire des données : sélectionnez la requête, puis cliquez sur l'onglet Charge utile. Localisez les données SAMLResponse.

   

3. Décoder : copiez la valeur de la réponse et collez-la dans l'outil de validation SAML.

4. Validation :

   • Examinez les revendications (attributs) renvoyées, telles que groups, first name, last name et email.
   • Important : Assurez-vous que ces attributs correspondent à la configuration des paramètres du pool d'employés dans Google Cloud.

   • Vérifiez que les valeurs sont correctes pour l'utilisateur spécifique qui tente de se connecter.

     

L'image suivante montre un mappage d'attributs :

Le mappage dans l'image est le suivant :

• google.subject = assertion.subject
• attribute.last_name = assertion.attributes.last_name[0]
• attribute.user_email = assertion.attributes.user_email[0]
• attribute.first_name = assertion.attributes.first_name[0]
• google.groups = assertion.attributes.groups

La partie de gauche est toujours la même : il s'agit de la syntaxe Google. La partie de droite correspond aux clés d'attributs de revendication affichées dans la réponse SAML.

L'attribut [0] est essentiel pour les attributs spécifiques indiqués (last_name, user_email et first_name), mais n'est pas pertinent pour subject et groups.

Étape 4 : Validez l'authentification Google SecOps

Cette étape permet de vérifier si Google Cloud authentifie l'utilisateur pour qu'il puisse se connecter à Google SecOps SOAR.

1. Localisez le jeton dans le navigateur de l'utilisateur : dans la barre de filtre de l'onglet Réseau, recherchez le point de terminaison auth/siem.

   

2. Extraire des données : sélectionnez la requête et affichez l'onglet Charge utile. Localisez la chaîne jwt.

3. Décoder : copiez la chaîne JWT et collez-la dans l'outil JWT Inspection (jwt.io).

   

4. Validation :

   • Comparez les revendications décodées pour given_name, family_name, email et idpgroups.
   • Confirmation de la correspondance : ces valeurs doivent correspondre exactement aux attributs validés lors de la phase 3 (réponse SAML).
   • Si les valeurs correspondent et que vous n'avez toujours pas accès, vérifiez l'attribution des rôles dans IAM. Assurez-vous que tous vos utilisateurs se voient attribuer l'un des rôles prédéfinis de Chronicle en utilisant le format de principal approprié pour votre configuration d'identité (fédération des identités des employés ou Cloud Identity pour les comptes Google gérés).

Phase 5 : Valider l'accès aux autorisations SOAR

Cette étape confirme que le système attribue correctement les autorisations dans SOAR via la page Mappage de groupe de la plate-forme.

Les administrateurs ont automatiquement accès à SOAR, car la page Mappage des groupes permet un accès par défaut.

Vous pouvez valider l'accès aux groupes pour vos utilisateurs en ajoutant quelques mappages de groupes IdP dans cette nouvelle instance SOAR. Par défaut, les nouvelles instances ont une page Mappage des groupes vide. Pour valider l'accès au groupe pour d'autres utilisateurs, ajoutez des mappages de groupes IdP à la nouvelle instance SOAR en procédant comme suit :

1. Copiez les mappages de groupe depuis la page Mappages de groupe de votre instance SOAR existante.
2. Demandez à un utilisateur du groupe IdP d'accéder à la nouvelle URL Google SecOps.

3. Si l'utilisateur ne parvient pas à accéder à SOAR, suivez ces étapes de dépannage :

   a. Inspectez la réponse : ouvrez la requête auth/siem de la phase 4, puis sélectionnez l'onglet Aperçu.

   b. Vérifiez les autorisations : localisez l'objet permissions dans la réponse JSON.

Facultatif : Pour gagner du temps, copiez ces mappages dans votre instance Google SecOps existante en accédant à Paramètres > Avancés > Mappage des groupes.

Remarque : Lorsque vous terminez la migration de l'étape 1, les mappages de groupes de votre instance SOAR existante remplacent tous les mappages que vous avez ajoutés à la nouvelle instance Google SecOps. Pour accéder à ces paramètres, accédez à Paramètres> Avancé> Mappage des groupes.

Flux OIDC et dépannage

Cette section présente le processus d'authentification OIDC et décrit une approche systématique pour diagnostiquer et résoudre les problèmes d'intégration courants.

Architecture du workflow d'authentification

Il est essentiel de comprendre le flux de requêtes pour isoler les points de défaillance. Le diagramme suivant illustre le chemin séquentiel d'une connexion réussie.

Procédure de dépannage OIDC détaillée

Pour diagnostiquer et suivre efficacement le processus d'authentification OIDC, vous pouvez utiliser les outils de développement du navigateur et les décodeurs JWT en ligne.

• Inspection JWT : https://www.jwt.io/
  • Objectif : permet d'inspecter les revendications et le contenu des jetons Web JSON (JWT).

Phase 1 : Préparation de l'environnement

Avant de commencer, assurez-vous que l'environnement de votre navigateur est prêt à capturer le réseau en procédant comme suit :

1. Ouvrez un nouvel onglet vide dans votre navigateur ou une fenêtre de navigation privée.

2. Ouvrez les outils pour les développeurs à l'aide du raccourci de votre système d'exploitation :

   • Windows : appuyez sur F12.
   • Linux : appuyez sur Ctrl+Maj+I.
   • macOS : appuyez sur Cmd+Option+I.

3. Accédez à l'onglet Réseau.

4. Cochez la case Conserver le journal pour vous assurer qu'aucune donnée n'est perdue lors des redirections.

   

5. Accédez à l'URL de votre environnement Google SecOps pour lancer le processus de connexion. Vous recevrez cette URL par e-mail une fois que vous aurez terminé la configuration de Google SecOps à l'étape 5 de la phase de migration 1 pour les clients SOAR autonomes. L'objet de l'e-mail est YourGoogle SecOps instance is ready.

Étape 2 : Validez la demande d'autorisation auprès d'un fournisseur OIDC

Cette étape permet de vérifier la redirection initiale de Google Cloud vers votre fournisseur OpenID Connect (IdP).

1. Localisez la requête : dans l'onglet Réseau, recherchez la redirection initiale vers le point de terminaison d'autorisation de votre fournisseur OIDC. L'URL contient généralement des paramètres tels que client_id, redirect_uri, scope, response_type et state.

   

2. Validation :

   • Vérifiez que client_id correspond à celui configuré dans votre fournisseur OIDC.
   • Assurez-vous que redirect_uri correspond exactement à https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID, en remplaçant POOL_ID et PROVIDER_ID par votre pool et votre fournisseur de la fédération des identités des employés.
   • Vérifiez que response_type est défini sur "code".
   • Notez le paramètre "scope", qui doit inclure "openid" et tous les autres niveaux d'accès requis pour publier les revendications nécessaires (par exemple, "email" et "profile").

Phase 3 : Valider le rappel et l'échange de jetons

Cette étape permet de vérifier la réponse du fournisseur d'identité à Google Cloud.

1. Localisez le rappel : dans l'onglet Réseau, recherchez la requête envoyée à l'URL signin-callback (.../signin-callback/...).

   

2. Vérifier les données : vérifiez les paramètres d'URL de cette requête. Il doit contenir un paramètre de code fourni par votre fournisseur d'identité OIDC.

3. En coulisses : la fédération des identités des employés échange ce code contre des jetons (jeton d'identité, jeton d'accès) à partir du point de terminaison de jeton du fournisseur OIDC. Les erreurs à ce stade sont souvent visibles dans Cloud Logging pour la fédération des identités des employés.

   • Vérifiez la propagation des attributs et le jeton complet : pour vérifier que votre mappage d'attributs dans la fédération des identités des employés produit les résultats attendus :
     • Ajoutez l'URI de redirection fourni dans la configuration du fournisseur de fédération des identités des employés aux URI de redirection de votre fournisseur (par exemple, https://auth.cloud.google/signin-callback/locations/global/workforcePools/POOL_ID/providers/PROVIDER_ID).
     • Accédez à votre fournisseur de fédération des identités des employés pour déboguer le jeton IdP. Vous pouvez également consulter le jeton complet. Pour en savoir plus, consultez Vérifier la configuration de votre produit.

   

Étape 4 : Validez l'authentification Google SecOps

Cette étape permet de vérifier si Google Cloud authentifie l'utilisateur pour qu'il puisse se connecter à Google SecOps SOAR.

1. Localisez le jeton dans le navigateur de l'utilisateur : dans la barre de filtre de l'onglet Réseau, recherchez le point de terminaison auth/siem.

   

2. Extraire des données : sélectionnez la requête et affichez l'onglet Charge utile. Localisez la chaîne jwt.

3. Décoder : copiez la chaîne JWT et collez-la dans l'outil JWT Inspection (jwt.io).

   

4. Validation :

   • Comparez les revendications décodées pour sub, given_name, family_name, email et idpgroups.
   • Confirmation de la correspondance : ces valeurs doivent correspondre aux attributs publiés par votre fournisseur OIDC et à la façon dont ils sont mappés dans les mappages d'attributs de la fédération des identités des employés. Par exemple, attribute.first_name dans Google Cloud doit correspondre à given_name dans le jeton JWT.
   • Rôles IAM : si les revendications sont correctes, mais que l'accès est refusé avec un message tel que Cannot Authenticate user, because user does not have access to the GCP project...,, vérifiez les attributions de rôle IAM. Assurez-vous que les groupes de l'utilisateur (idp_groups dans le JWT) disposent des rôles nécessaires en utilisant le format principalSet approprié (par exemple, principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/IDP_GROUP_NAME).

Phase 5 : Valider l'accès aux autorisations SOAR

Cette étape confirme que le système attribue correctement les autorisations dans SOAR via la page Mappage de groupe de la plate-forme.

Les administrateurs ont automatiquement accès à SOAR, car la page Mappage des groupes permet un accès par défaut.

Vous pouvez valider l'accès aux groupes pour vos utilisateurs en ajoutant quelques mappages de groupes IdP dans cette nouvelle instance SOAR. Par défaut, les nouvelles instances ont une page Mappage des groupes vide. Pour valider l'accès au groupe pour d'autres utilisateurs, ajoutez des mappages de groupes IdP à la nouvelle instance SOAR en procédant comme suit :

1. Copiez les mappages de groupe depuis la page Mappages de groupe de votre instance SOAR existante.
2. Demandez à un utilisateur du groupe IdP d'accéder à la nouvelle URL Google SecOps.

3. Si l'utilisateur ne parvient pas à accéder à SOAR, suivez ces étapes de dépannage :

   a. Inspectez la réponse : ouvrez la requête auth/siem de la phase 4, puis sélectionnez l'onglet Aperçu.

   b. Vérifiez les autorisations : localisez l'objet permissions dans la réponse JSON.

Facultatif : Pour gagner du temps, copiez ces mappages dans votre instance Google SecOps existante en accédant à Paramètres > Avancés > Mappage des groupes.

Remarque : Lorsque vous terminez la migration de l'étape 1, les mappages de groupes de votre instance SOAR existante remplacent tous les mappages que vous avez ajoutés à la nouvelle instance Google SecOps. Pour accéder à ces paramètres, accédez à Paramètres> Avancé> Mappage des groupes.

Erreurs OIDC courantes :

• invalid_redirect_uri depuis l'IdP : assurez-vous que l'URI de redirection configuré dans votre IdP correspond exactement à https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID, en remplaçant POOL_ID et PROVIDER_ID par votre pool et votre fournisseur de la fédération d'identité des employés. Même une barre oblique de fin ou une différence entre http et https déclenchera cette erreur.

• Revendications manquantes dans le jeton JWT :

  1. Côté IdP : vérifiez que le client OIDC est configuré pour libérer les revendications requises (mappées dans le WIF, telles que sub, groups, email, given_name, family_name) dans le jeton d'identité.

  2. Côté WIF : assurez-vous que ces revendications entrantes sont correctement mappées dans la section "Mappage des attributs WIF" (par exemple, google.groups=assertion.groups). Si une revendication est présente dans le jeton, mais n'est pas mappée dans WIF, il est possible que la plate-forme SOAR ne parvienne pas à autoriser l'utilisateur. Pour vérifier que votre mappage d'attributs produit les résultats attendus, consultez Vérifier la configuration de votre fournisseur.

Mappages de groupes après la migration

Le mappage des groupes reste essentiel dans Google SecOps une fois la migration terminée

Après la migration, l'instance migrée conserve les mappages de groupe. Ils servent de base pour déterminer l'accès des utilisateurs à SOAR. Pour accéder à Google SecOps, vous devez vous assurer que chaque utilisateur est mappé sur cette page. Pour en savoir plus, consultez Accéder à une instance.

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