Migrer les autorisations SOAR vers IAM

Compatible avec :

Google SecOps SOAR

Ce document s'adresse aux clients de Google Security Operations Unified et aux utilisateurs de SOAR autonome qui doivent migrer leur environnement des groupes d'autorisations SOAR existants vers Google Cloud Identity and Access Management (IAM) pour le contrôle des accès. Pour une présentation vidéo de cette procédure, consultez la vidéo sur la migration IAM SOAR.

Remarque : L'outil de migration peut vous aider à proposer de nouvelles liaisons IAM personnalisées pour les autorisations Paramètres SOAR existantes. Pour en savoir plus, consultez RBAC des fonctionnalités.

Le processus de validation de la console Google Cloud automatise la transition des autorisations SOAR versGoogle Cloud IAM en effectuant les étapes clés suivantes :

• Lit les configurations d'autorisations existantes, y compris les groupes d'autorisations personnalisés et les attributions d'utilisateurs.
• Génère des rôles IAM personnalisés qui répliquent les groupes d'autorisations existants.
• Mappez les utilisateurs et les groupes existants aux rôles IAM nouvellement créés pour vous assurer que tous les droits d'accès sont conservés.
• Crée des stratégies IAM pour lier les utilisateurs et les groupes aux rôles qui leur sont attribués.

Avant de commencer

Avant de commencer la migration, assurez-vous que les conditions suivantes sont remplies :

• Si vous êtes un client Google SecOps unifié, assurez-vous d'utiliser Cloud IAM pour gérer les rôles et les autorisations pour la partie SIEM de la plate-forme. Pour en savoir plus, consultez Migrer l'ancien RBAC vers le RBAC de fonctionnalité.

• Assurez-vous d'utiliser la même identité (adresse e-mail ou compte) pour la console Google Cloud et SOAR.

• Mappage des groupes IdP : si vous utilisez la fédération des identités des employés pour l'authentification, vérifiez que tous les utilisateurs sont mappés à des groupes de fournisseurs d'identité (IdP) sur la page Mappage de groupe. Pour en savoir plus sur le mappage des groupes IdP, consultez Mapper les utilisateurs de la plate-forme. L'outil de migration utilise ces mappages pour créer un script qui lie les adresses e-mail ou les groupes d'utilisateurs aux principaux IAM.

• Mappage des groupes de messagerie : si vous utilisez Cloud Identity pour l'authentification, vérifiez que tous les utilisateurs sont mappés à des groupes de messagerie sur la page Mappage de groupe. Pour en savoir plus sur le mappage des adresses e-mail, consultez Mapper les utilisateurs de la plate-forme à l'aide de Cloud Identity. L'outil de migration utilise ces mappages pour créer un script qui lie les adresses e-mail ou les groupes d'utilisateurs aux principaux IAM.

• Facultatif : clé API SOAR. Si vous ne disposez pas des autorisations SOAR pour mapper l'utilisateur actuel sur la page Mappages de groupe, vous pouvez demander à un administrateur SOAR de fournir une clé API SOAR et de l'utiliser pour générer les scripts.

L'administrateur SOAR doit suivre la procédure ci-dessous :

1. Dans la plate-forme Google SecOps, accédez à Paramètres SOAR> Avancé > Groupes d'autorisations (clés API).
2. Créez un groupe d'autorisations en vous assurant que le module Settings (Paramètres) et les options sous "Settings" sont tous cochés.
3. Accédez à SOAR Settings> Advanced> API Keys (Paramètres SOAR > Avancé > Clés API).
4. Ajoutez une clé API en veillant à sélectionner le groupe d'autorisations que vous avez créé.
5. Copiez la clé API générée.

• Autorisations : vérifiez que vous disposez des autorisations nécessaires.

  • Administrateur de l'API Chronicle
  • Administrateur du service Chronicle
  • Administrateur Chronicle SOAR

Avertissement : Une fois que vous avez activé IAM, tous les rôles prédéfinis Chronicle sont activés avec les autorisations SOAR. L'administrateur de l'API Chronicle inclut désormais les autorisations d'administrateur SOAR. Si vous ne souhaitez pas que les principaux (utilisateurs/groupes) attribués aux rôles prédéfinis Chronicle disposent d'autorisations SOAR ou si vous souhaitez limiter leurs autorisations, nous vous recommandons de les associer à un rôle personnalisé qui exclut explicitement les autorisations SOAR.

Après la migration, si des problèmes ne sont pas résolus, cliquez sur Désactiver IAM pour annuler la migration des groupes d'autorisations vers les rôles IAM. Les rôles et liaisons IAM nouvellement créés ne seront pas supprimés.

Pour obtenir la liste complète des autorisations requises pour chaque rôle, consultez Autorisations IAM requises.

Il existe deux façons de migrer les autorisations SOAR :

• À l'aide de la Google Cloud CLI
• À l'aide de Terraform

Migrer les autorisations SOAR à l'aide de la Google Cloud CLI

Pour migrer vos autorisations SOAR vers Google Cloud IAM, procédez comme suit :

1. Dans la console Google Cloud , accédez aux paramètres d'administration de Google SecOps.
2. Cliquez sur l'onglet Migration IAM SOAR.
3. Dans la section Migrer les liaisons de rôles, copiez les commandes Google Cloud CLI. Lorsque vous êtes invité à spécifier une nouvelle condition, sélectionnez 2. Aucune. .
4. Dans la barre d'outils Google Cloud , cliquez sur Activer Cloud Shell.
5. Dans la fenêtre de terminal, collez les commandes Google Cloud CLI et appuyez sur Entrée.
6. Assurez-vous que les scripts sont exécutés correctement.
7. Revenez à la console Google Cloud , puis dans la section Vous avez terminé cette tâche, cliquez sur Activer IAM.

Migrer les autorisations SOAR à l'aide de Terraform

Pour migrer vos autorisations SOAR vers Google Cloud IAM à l'aide de Terraform, procédez comme suit :

1. Dans la console Google Cloud , accédez aux paramètres d'administration de Google SecOps.
2. Cliquez sur l'onglet Migration IAM SOAR.
3. Dans la section Migrer les liaisons de rôles, copiez les commandes Google Cloud CLI.
4. Accédez à votre dépôt Terraform et mappez les commandes Google Cloud CLI à leurs équivalents Terraform correspondants. Le tableau suivant met en correspondance la commande de création de rôle personnalisé de la Google Cloud CLI avec les commandes Terraform.

Option gcloud	Argument Terraform	Remarques
ROLE_ID (positionnel)	role_id	Dans Terraform, n'incluez pas le préfixe projects/PROJECT_ID/roles/. Utilisez uniquement la chaîne d'ID (par exemple, myCustomRole).
--project	project	ID du projet dans lequel le rôle personnalisé est défini.
--title	title	Titre lisible par l'humain pour le rôle.
--description	description	Résumé de l'objectif et des autorisations du rôle.
--permissions	permissions	gcloud accepte une chaîne séparée par une virgule. Terraform nécessite une liste de chaînes : ["perm.a", "perm.b"].
--stage	stage	Valeurs valides : ALPHA, BETA, GA, DEPRECATED, DISABLED, EAP.

Remarque : Assurez-vous que chaque option --flag de votre ligne de commande est correctement associée à l'argument correspondant dans le bloc de ressources Terraform.

Exemple de mappage de Google Cloud CLI vers Terraform

Commande Google Cloud CLI :

gcloud iam roles create SOAR_Custom_managedUser_google.com --project="{customer project}" 
--title="SOAR Custom managedUser Role" 
--description="SOAR Custom role generated for IDP Mapping Group ManagedUser" 
--stage=GA 
--permissions=chronicle.cases.get

Commande Terraform :

resource "google_project_iam_custom_role" "{terraform_name}" {
  role_id     = "SOAR_Custom_managedUser_google.com"
  title       = "SOAR Custom managedUser Role"
  project     = "{customer project}"
  stage       = "GA"
  permissions = [
    #This is an example!
    "chronicle.cases.get"
  ]
}

Liaisons de stratégie IAM (attribuer des rôles)

Lorsque vous utilisez Google Cloud CLI projects add-iam-policy-binding, vous accordez un rôle spécifique à un membre spécifique (utilisateur, compte de service ou groupe). Le tableau suivant met en correspondance les commandes Google Cloud CLI et les commandes Terraform. Mappez les commandes pour attribuer des rôles IAM.

Flag gcloud	Argument Terraform	Remarques
PROJECT_ID (positionnel)	project	ID du projet cible.
--member	member	L'identité du compte principal (par exemple, user:email, serviceAccount:email, group:email).
--role	role	ID du rôle. Utilisez le chemin d'accès complet pour les rôles personnalisés (projects/ID/roles/NAME) et le nom court pour les rôles standards (roles/NAME).

Exemple d'attribution de rôle

Commande Google Cloud CLI :

gcloud projects add-iam-policy-binding
 {customer project}
--member="user:[e-mail]" 
--role="projects/{customer project}/roles/SOAR_Custom_managedUser_google.com"

Commande Terraform :

resource "google_project_iam_member" "{terraform_name}" {
  project = "{customer project}"
  role    = "projects/{customer project}/roles/SOAR_Custom_managedUser_google.com"
  member  = "user:[e-mail]"
}

Remarque : Google ne recommande pas d'utiliser google_project_iam_binding (le terme "binding" au singulier correspond au nom de la commande Google Cloud CLI), car cela supprime toutes les autres personnes disposant de ce rôle si elles ne sont pas listées dans votre code. Utilisez plutôt google_project_iam_member.

Important : La colonne Groupe d'autorisations continue de s'afficher sur la page Mappage de groupes après la migration pour assurer la rétrocompatibilité avec l'ancienne API SOAR. Ne supprimez pas ces devoirs. La colonne sera automatiquement supprimée d'ici le 31 mars 2027, sans aucune incidence pour les clients.

Migration des posts

Une fois que vous êtes passé aux autorisations IAM, chaque commande curl que vous utilisez pour appeler une API doit être envoyée soit avec un compte de service mappé (mappé dans les groupes de mappage IDP), soit avec un utilisateur qui s'est connecté à la plate-forme au moins une fois.

Questions fréquentes

• Pour obtenir une liste détaillée des problèmes et des bonnes pratiques, consultez les questions fréquentes sur la migration des rôles IAM.