Migra los permisos de SOAR a IAM

Compatible con:

Google SecOps SOAR

En este documento, se guía tanto a los clientes unificados de Google Security Operations como a los usuarios independientes de SOAR que necesitan migrar su entorno de los grupos de permisos de SOAR existentes a Identity and Access Management (IAM) de Google Cloud para el control de acceso. Para obtener un video explicativo de este procedimiento, consulta el video de migración de IAM de SOAR.

Nota: La herramienta de migración puede ayudarte a proponer nuevas vinculaciones de IAM personalizadas para los permisos existentes de la configuración de SOAR. Para obtener más información, consulta RBAC de funciones.

El proceso de verificación de la consola de Google Cloud automatiza la transición de los permisos de SOAR a IAM deGoogle Cloud con los siguientes pasos clave:

• Lee los parámetros de configuración de permisos existentes, incluidos los grupos de permisos personalizados y las asignaciones de usuarios.
• Genera roles de IAM personalizados que replican los grupos de permisos existentes.
• Asigna usuarios y grupos existentes a roles de IAM recién creados para garantizar que se conserven todos los privilegios de acceso.
• Crea políticas de IAM para vincular usuarios y grupos a sus roles asignados.

Antes de comenzar

Antes de comenzar la migración, confirma que se cumplan los siguientes requisitos:

• Si eres cliente de Google SecOps unificado, asegúrate de usar Cloud IAM para administrar los roles y permisos del lado de SIEM de la plataforma. Para obtener más información, consulta Migra el RBAC heredado al RBAC de funciones.

• Asegúrate de usar la misma identidad (correo electrónico o cuenta) para la consola de Google Cloud y SOAR.

• Asignación de grupos de IdP: Si usas la federación de identidades de personal para la autenticación, verifica que todos los usuarios estén asignados a grupos de proveedores de identidad (IdP) en la página Asignación de grupos. Para obtener información sobre la asignación de grupos de IdP, consulta Asigna usuarios en la plataforma. La herramienta de migración usa estas asignaciones para crear una secuencia de comandos que vincula los correos o grupos de usuarios a las entidades de IAM.

• Asignación de grupos de correo electrónico: Si usas Cloud Identity para la autenticación, verifica que todos los usuarios estén asignados a grupos de correo electrónico en la página Asignación de grupos. Para obtener información sobre la asignación de correos electrónicos, consulta Asigna usuarios en la plataforma con Cloud Identity. La herramienta de migración usa estas asignaciones para crear una secuencia de comandos que vincula los correos o grupos de usuarios a las entidades de IAM.

• Opcional: Clave de API de SOAR. Si no tienes permisos de SOAR para asignar el usuario actual en la página Asignaciones de grupos, puedes pedirle a un administrador de SOAR que proporcione una clave de API de SOAR y usarla para generar las secuencias de comandos.

El administrador de SOAR debe seguir los pasos que se indican en el siguiente procedimiento:

1. En la plataforma de Google SecOps, ve a Configuración de SOAR > Avanzada > Grupos de permisos (claves de API).
2. Crea un grupo de permisos y asegúrate de que el módulo Configuración y las opciones que se encuentran en Configuración estén marcados.
3. Ve a Configuración de SOAR > Avanzada > Claves de API.
4. Agrega una clave de API nueva y asegúrate de seleccionar el grupo de permisos que creaste.
5. Copia la clave de API generada.

• Permisos: Confirma que tienes los permisos necesarios:

  • Administrador de la API de Chronicle
  • Administrador del servicio de Chronicle
  • Administrador de Chronicle SOAR

Advertencia: Después de habilitar IAM, se activarán todos los roles predefinidos de Chronicle con permisos de SOAR. El administrador de la API de Chronicle ahora incluirá los permisos de administrador de SOAR. Si no quieres que las entidades principales (usuarios o grupos) asignadas a los roles predefinidos de Chronicle tengan permisos de SOAR o si quieres limitar sus permisos, te recomendamos que las asignes a un rol personalizado que excluya explícitamente los permisos de SOAR.

Después de la migración, si hay problemas sin resolver, haz clic en Inhabilitar IAM para revertir la migración de los grupos de permisos a los roles de IAM. No se borrarán los roles ni las vinculaciones de IAM recién creados.

Para obtener una lista completa de los permisos necesarios para cada rol, consulta Permisos de IAM obligatorios.

Existen dos maneras de migrar los permisos de SOAR:

• Usa Google Cloud CLI
• Con Terraform

Migra los permisos de SOAR con Google Cloud CLI

Para migrar tus permisos de SOAR a la IAM de Google Cloud , sigue estos pasos:

1. En la consola de Google Cloud , ve a la configuración de administración de Google SecOps.
2. Haz clic en la pestaña Migración de IAM de SOAR.
3. En la sección Migra vinculaciones de roles, copia los comandos de Google Cloud CLI. Cuando se te dé la opción de especificar una condición nueva, selecciona 2. Ninguno .
4. En la barra de herramientas de Google Cloud , haz clic en Activar Cloud Shell.
5. En la ventana de terminal, pega los comandos de Google Cloud CLI y presiona Intro.
6. Asegúrate de que las secuencias de comandos se ejecuten correctamente.
7. Regresa a la consola de Google Cloud y, en la sección Terminé con esta tarea, haz clic en Habilitar IAM.

Migra los permisos de SOAR con Terraform

Para migrar tus permisos de SOAR a la IAM de Google Cloud con Terraform, sigue estos pasos:

1. En la consola de Google Cloud , ve a la configuración de administración de Google SecOps.
2. Haz clic en la pestaña Migración de IAM de SOAR.
3. En la sección Migra vinculaciones de roles, copia los comandos de Google Cloud CLI.
4. Ve a tu repositorio de Terraform y asigna los comandos de Google Cloud CLI a sus equivalentes de Terraform. En la siguiente tabla, se asigna el comando de Google Cloud CLI para crear un rol personalizado con los comandos de Terraform.

Marca de gcloud	Argumento de Terraform	Notas
ROLE_ID (Posicional)	role_id	En Terraform, no incluyas el prefijo projects/PROJECT_ID/roles/. Usa solo la cadena de ID (por ejemplo, myCustomRole).
--project	project	Es el ID del proyecto en el que se define el rol personalizado.
--title	title	Es un título legible por humanos para el rol.
--description	description	Un resumen del propósito y los permisos del rol.
--permissions	permissions	gcloud acepta una cadena separada por comas. Terraform requiere una lista de cadenas: ["perm.a", "perm.b"].
--stage	stage	Valores válidos: ALPHA, BETA, GA, DEPRECATED, DISABLED, EAP.

Nota: Asegúrate de que cada --flag de tu línea de comandos esté vinculada correctamente con su argumento correspondiente dentro del bloque de recursos de Terraform.

Ejemplo de asignación de Google Cloud CLI a Terraform

Comando de 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

Comando de 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"
  ]
}

Vinculaciones de políticas de IAM (asignación de roles)

Cuando usas Google Cloud CLI projects add-iam-policy-binding, otorgas un rol específico a un miembro específico (usuario, cuenta de servicio o grupo). En la siguiente tabla, se asignan los comandos de Google Cloud CLI con los comandos de Terraform. Asigna los comandos para asignar roles de IAM.

Marca de gcloud	Argumento de Terraform	Notas
PROJECT_ID (Posicional)	project	Es el ID del proyecto de destino.
--member	member	Es la identidad de la principal (por ejemplo, user:email, serviceAccount:email o group:email).
--role	role	Es el ID del rol. Usa la ruta de acceso completa para los roles personalizados (projects/ID/roles/NAME) y el nombre corto para los roles estándar (roles/NAME).

Ejemplo de asignación de roles

Comando de 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"

Comando de 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]"
}

Nota: Google no recomienda usar google_project_iam_binding (la "vinculación" en singular coincide con el nombre del comando de Google Cloud CLI), ya que quitará a cualquier otra persona que tenga ese rol si no aparece en tu código. En su lugar, usa google_project_iam_member.

Importante: La columna Grupo de permisos se sigue mostrando en la página Asignación de grupos después de la migración para mantener la retrocompatibilidad con la API de SOAR heredada. No borres estas asignaciones. La columna se quitará automáticamente antes del 31 de marzo de 2027 sin que esto afecte a los clientes.

Después de la migración

Después de cambiar al uso de permisos de IAM, cada comando curl que uses para llamar a una API se debe enviar con una cuenta de servicio asignada (asignada en grupos de asignación de IDP) o con un usuario que se haya conectado a la plataforma al menos una vez.

Preguntas frecuentes

• Para obtener una lista detallada de los problemas y las prácticas recomendadas, consulta las Preguntas frecuentes sobre la migración de roles de IAM.