Preguntas frecuentes sobre la migración de SOAR

Compatible con:

Obtén respuestas a preguntas frecuentes sobre el proceso de migración de SOAR. Encuentra soluciones a problemas frecuentes y prácticas recomendadas para lograr una transición exitosa.

Alcance y efecto de la migración

P: ¿Por qué es necesaria esta migración?

Estamos modernizando la infraestructura de SOAR mediante la migración a Google Cloud. Esta actualización fundamental proporciona beneficios clave, como mayor confiabilidad, mejor seguridad, mayor cumplimiento y control de acceso más detallado. También permite el acceso a las capacidades de IA de agentes a través de la integración del Protocolo de contexto del modelo (MCP).

La migración proporciona lo siguiente:

  • Mejora la confiabilidad y las capacidades de supervisión de SOAR mediante el uso de la mejor capa de API de su clase de Google. Esta capa proporciona una solución de API líder con funciones avanzadas para la administración de cuotas, la auditoría y la observabilidad.
  • Desbloquea el control de acceso basado en funciones (RBAC) para las funciones y los datos en toda la plataforma.
  • Proporciona una mayor funcionalidad de cumplimiento, como los Controles del servicio de VPC, la residencia de datos y las claves de encriptación administradas por el cliente (CMEK).

P: ¿Cuál es el alcance de la migración?

La migración implica los siguientes componentes:

  • Migración del proyecto SOAR a un proyecto propiedad del cliente Google Cloud .
  • Migración de la autenticación y los permisos de SOAR a Google Cloud IAM de.
  • Migración de las APIs de SOAR a la API de Chronicle.
  • Migración de agentes remotos.
  • Migración de los registros de auditoría de SOAR.

P: ¿Cuáles son los cambios inmediatos después de la migración?

Inmediatamente después de la migración, experimentarás varios cambios clave:

  • Propiedad del proyecto de GCP: Tu proyecto de SOAR se migrará de la propiedad de Google a tu proyecto propiedad del cliente Google Cloud .
  • Autenticación:
    • Clientes de SecOps unificado: No hay cambios. La autenticación seguirá siendo administrada por Google Cloud IAM.
    • Clientes independientes de SOAR: IAM ahora administrará la autenticación Google Cloud . Para los usuarios que usan SAML, esto significa adoptar la federación de identidades de personal, y la configuración de SAML ya no se almacenará ni administrará dentro del sistema SOAR, lo que generará controles de seguridad más sólidos.
  • RBAC: Los permisos de usuario serán más detallados y se administrarán con IAM. Los entornos y las funciones de SOC seguirán administrándose dentro del módulo SOAR con grupos de proveedores de identidad (IdP).
  • Registro de auditoría: Los registros de auditoría serán más detallados y se administrarán en **Registros de auditoría de Cloud **.
  • URL nueva (solo SOAR): Los usuarios independientes de SOAR recibirán una URL nueva (dominio nuevo) para acceder a SOAR.

P: ¿Cómo se notifica a los clientes o socios sobre esta migración?

Se muestra una ventana emergente en el producto para todos los clientes y socios que incluye la fecha de migración y un vínculo a un formulario para completar. Se les pedirá que confirmen la fecha y el horario de la migración.

P: ¿Cambiarán nuestros costos de infraestructura como resultado de que SOAR esté vinculado a nuestro Google Cloud proyecto?

No, tus costos no se verán afectados. No deberías experimentar ningún cambio en el frontend. No se ejecutarán recursos nuevos en tu proyecto, por lo que no hay costos asociados.

P: ¿Cómo conectamos nuestro proyecto a SOAR?

Google migrará tu proyecto de SOAR a tu Google Cloud proyecto. Si eres cliente de SecOps unificado, ya tenemos tu Google Cloud ID de proyecto. Si eres cliente independiente de SOAR, deberás compartir tu Google Cloud ID de proyecto con nosotros.

P: Para los clientes que ya tienen una implementación de Google SecOps, ¿debemos usar el mismo ID del proyecto que SIEM o necesitamos un proyecto independiente?

Para una implementación unificada de Google SecOps (un SIEM, un SOAR), debes usar el ID de proyecto existente asociado con tu SIEM. Google Cloud Esto permite la administración unificada de los flujos administrativos, como RBAC y los registros.

P: Para las instancias de Google SecOps con consideraciones especiales, como los Controles del servicio de VPC (VPC SC), ¿qué pasos se necesitan?

Para habilitar la migración, deberás definir reglas de entrada y salida en tu política de VPC SC. Si tu Google Cloud proyecto tiene VPC SC, comunícate con el equipo de asistencia para obtener instrucciones detalladas sobre estas reglas específicas.

Tiempo de inactividad y continuidad

P: ¿Hay algún tiempo de inactividad durante la migración y cuál es su efecto?

Sí. El tiempo de inactividad esperado es el siguiente:

  • Hasta 2 horas para clientes independientes de SOAR
  • Hasta 1.5 horas para clientes de Google SecOps

Durante este período, no podrás acceder a la plataforma. Los servicios de SOAR (incluidos la ingesta, los playbooks y los trabajos) se pausarán, pero los servicios de SIEM seguirán ejecutándose en segundo plano.

P: ¿Los datos generados durante el tiempo de inactividad se ingerirán automáticamente una vez que se reanuden los servicios de SOAR?

Sí. Una vez que el sistema vuelva a estar en línea, la ingesta y los playbooks se reanudarán y procesarán las alertas que se generaron o ingirieron durante el tiempo de inactividad.

P: ¿Qué sucede con los playbooks que se están ejecutando cuando comienza el tiempo de inactividad?

El servicio de playbook se desactivará antes de que comience la migración. Es posible que algunos playbooks en ejecución fallen y deban reiniciarse de forma manual o se reanuden después de que se complete la migración.

P: ¿Hay un plan de reversión o de contingencia si algo sale mal durante la migración?

Sí. El proceso de migración mantiene intacta tu instancia de SOAR existente (aunque esté desactivada). Si el proceso de migración no se completa correctamente, podemos volver a tu instancia existente y quitar la nueva. Este proceso de reversión tarda hasta 30 minutos. Realizaremos pruebas exhaustivas y una supervisión minuciosa, con personal de guardia en espera para garantizar una migración exitosa.

Si tienes problemas de acceso después de la migración, es probable que la configuración de autenticación sea incorrecta. Deberás coordinar con tu administrador de identidad, IDP o Google Cloud para usar la guía de solución de problemas para la identificación y la resolución. Si el problema persiste o no está relacionado con el acceso, abre un ticket de asistencia para documentar la inquietud y supervisar su resolución.

P: ¿Cuándo puedo migrar a los nuevos extremos de SOAR v1 en la API de Chronicle?

Puedes migrar a los nuevos extremos de SOAR v1 en la API de Chronicle a partir de mediados de enero de 2026.

La API heredada de SOAR y las claves de API quedarán obsoletas y dejarán de funcionar después del 30 de septiembre de 2026. Para garantizar una transición fluida, sigue estos dos pasos obligatorios:

  1. Primero, debes completar la migración de los grupos de permisos de SOAR a Cloud IAM.
  2. Actualiza tus secuencias de comandos e integraciones existentes para reemplazar los extremos de la API heredada de SOAR por los extremos correspondientes de la API de Chronicle.

Autenticación y permisos

P: ¿Cómo migro mis grupos y permisos de SOAR?

Usarás una secuencia de comandos de migración en tu Google Cloud consola para migrar los grupos de permisos existentes a roles personalizados de IAM. La secuencia de comandos también asigna roles personalizados a los usuarios (para los clientes de Cloud Identity) o a los grupos de IdP (para los clientes de la federación de identidades de personal).

P: ¿Qué sucede si prefiero no migrar grupos de permisos personalizados y solo usar roles predefinidos?

Puedes inhabilitar la migración automatizada y, en su lugar, asignar grupos de IdP a roles de Cloud IAM de forma manual.

P: Somos un cliente independiente de SOAR con un proveedor de SAML personalizado con autenticación manual. Si cambiamos esto a grupos de IdP para la asignación de IdP, ¿cuál es el efecto en las cuentas de usuario existentes?

Si tus usuarios existentes coinciden con uno de los grupos y los permisos se asignan correctamente, no debería haber ningún efecto en tus cuentas de usuario preexistentes. Sin embargo, si los usuarios no están asignados a grupos, no podrán acceder. Si los permisos se asignan de manera diferente, los usuarios recibirán permisos nuevos según la nueva asignación.

P: ¿Existen requisitos previos específicos para los MSSP que usan varios proveedores de identidad?

Los clientes que configuraron varios proveedores de identidad en la página de autenticación externa de SOAR deben definir la federación de identidades de personal para la autenticación y crear un grupo de personal independiente para cada proveedor. Cada proveedor está asociado con un subdominio diferente. Para obtener más información, consulta la guía de migración de MSSP.

P: ¿Cómo me autentico en la API de Chronicle?

Sigue las instrucciones en Autenticación en la API de Chronicle.

P: ¿Cuáles son las nuevas IPs necesarias para acceder a la nueva API de SOAR? No es necesario permitir ninguna dirección IP para acceder a la API de Chronicle. De manera opcional, puedes permitir el rango de direcciones IP que se indica aquí y aquí.

Registro y supervisión

P: Completamos la primera etapa de la migración, pero no vemos registros en los registros de auditoría de Cloud.

Los registros se almacenan en la plataforma SOAR después de completar la primera etapa de la migración. Los registros estarán disponibles en tu Google Cloud proyecto después de completar la segunda etapa de la migración.

P: ¿Los clientes que envían datos de SOAR a una instancia de BigQuery (BQ) administrada podrán acceder a estos datos de BigQuery después de la migración?

Sí. La instancia de BigQuery administrada existente seguirá funcionando.

Logística y asistencia

P: ¿Puedo elegir otro horario para la migración?

No. No es posible migrar fuera de los horarios sugeridos.

P: ¿Recibiremos actualizaciones de estado en tiempo real durante la migración?

Recibirás una notificación por correo electrónico al comienzo y al final del proceso de migración.

P: ¿Con quién debemos comunicarnos si surge un problema después de la migración?

Si tienes problemas de acceso después de la migración, es probable que la configuración de autenticación sea incorrecta. Deberás coordinar con tu administrador de identidad, IDP o Google Cloud para usar la guía de solución de problemas para la identificación y la resolución. Si el problema persiste o no está relacionado con el acceso, abre un ticket de asistencia para documentar la inquietud y supervisar su resolución.

Migra los grupos de permisos de SOAR a IAM

En la siguiente sección, se abordan los problemas comunes que se producen durante y después de la migración de permisos a IAM.

Problemas con la herramienta y la secuencia de comandos de migración

P: ¿Por qué no puedo ver ni cargar la secuencia de comandos de migración en la Google Cloud Console?

Hay dos motivos posibles para esto:

  • Faltan permisos: La herramienta de migración requiere que tu cuenta de usuario tenga permisos suficientes en la instancia de Google Cloud y en la de Google SecOps. Asegúrate de haber accedido con una cuenta que tenga los roles de IAM necesarios en Google Cloud y que también sea un usuario reconocido en Google SecOps SOAR. Usar cuentas diferentes para Google Cloud y SOAR puede causar fallas de autorización. Si tienes los permisos necesarios y aún no puedes cargar la secuencia de comandos de migración, abre un ticket de asistencia.

  • SIEM no usa Cloud IAM: Si eres cliente unificado de Google SecOps, asegúrate de usar IAM para administrar los roles y permisos del lado SIEM de la plataforma. Para obtener más información, consulta la guía de migración de RBAC heredado a RBAC de funciones.

P: Aparece un error cuando intento ejecutar las secuencias de comandos de migración. ¿Qué debo hacer?

  • Error: "El grupo no existe": Cuando uses los add-iam-policy-binding commands, asegúrate de usar la dirección de correo electrónico completa del grupo (por ejemplo, your-group@example.com) para la marca --member, no solo el nombre corto del grupo.

  • Errores relacionados con roles preexistentes: Pueden producirse conflictos cuando se vincula a una entidad principal que ya tiene vinculaciones condicionales. Para resolver este problema, vuelve a ejecutar la secuencia de comandos y asegúrate de seleccionar Ninguno en lugar de Especificar una condición nueva.

Problemas de acceso después de la migración

P: ¿Por qué recibo un error "403 Forbidden" cuando intento acceder a ciertas páginas o funciones (como Playbooks o IDE) después de la migración de IAM?

Un error 403 después de la migración puede indicar que el Google Cloud rol de IAM asignado a tu usuario no tiene los permisos que requiere el lado SOAR de la plataforma de Google SecOps. Esto es común si usas roles personalizados de IAM.

Consulta los roles y permisos de Google SecOps. Asegúrate de que tu rol personalizado de IAM incluya todos los permisos necesarios para acceder a las funciones de SOAR requeridas.

De manera opcional, examina las herramientas para desarrolladores de tu navegador para identificar llamadas a la API específicas que muestran un error 403. La carga útil de la respuesta documenta el permiso faltante, y también aparece un banner de notificación en la interfaz que detalla el acceso requerido.

Si ninguna de estas soluciones te ayuda, abre un ticket de asistencia.

Permisos y funciones

P: Realicé la migración de IAM de forma manual sin usar la herramienta proporcionada y ahora tengo problemas de permisos. ¿Cómo puedo solucionar este problema?

La migración manual de IAM a veces puede generar la falta de permisos necesarios para las funciones de SOAR. Te recomendamos que uses la secuencia de comandos de migración proporcionada para asegurarte de que todos los permisos requeridos estén configurados correctamente. Si aún planeas realizar la migración manual, revisa detenidamente los permisos de IAM de Google SecOps para crear los roles personalizados con los permisos necesarios.

P: Algunos usuarios parecen tener más permisos en SOAR de lo esperado después de la migración. ¿A qué se debe este problema?

Esto puede suceder si los usuarios o grupos ya se asignaron a roles amplios predefinidos de Chronicle antes de la migración. Google Cloud Después de completar la migración, los roles predefinidos de Chronicle (como chronicle.apiAdmin) incluirán automáticamente los permisos de SOAR. Por ejemplo, el rol de administrador de la API de Chronicle ahora incluirá los permisos de administrador de SOAR.

Para garantizar el acceso con privilegios mínimos, sigue estos pasos:

  1. Revisa tus roles predefinidos en la página Roles de IAM, incluido el administrador de la API de Chronicle, para identificar todas las entidades principales asignadas (usuarios y grupos).
  2. Confirma que solo los usuarios que requieren permisos de SOAR estén asignados a estos roles.
  3. Para limitar el acceso a SOAR para entidades principales específicas, quítalas de los roles predefinidos y asígnalas a un rol personalizado que excluya explícitamente los permisos de administrador de SOAR.

P: La migración se completó correctamente, pero aún puedo ver la columna Grupos de permisos en la página Asignación de grupos. ¿Por qué?

Después de una migración exitosa, la columna Grupos de permisos aún se muestra en la página Asignación de grupos para la retrocompatibilidad. No borres estas asignaciones. La columna se quitará el 30 de septiembre de 2026 sin ningún efecto en el cliente.

Prácticas recomendadas

  • Usa la secuencia de comandos de migración: Siempre que sea posible, usa la secuencia de comandos de migración oficial para controlar la transición de los grupos de permisos de SOAR a los roles de IAM. Google Cloud
  • Revisa los permisos de IAM: Familiarízate con los permisos de IAM requeridos para las diferentes funciones y roles de SOAR. Google Cloud
  • Realiza pruebas exhaustivas: Después de la migración, prueba el acceso para diferentes roles y personajes de usuario para asegurarte de que todo funcione según lo esperado.
  • Comunícate con el equipo de asistencia: Si tienes errores persistentes o un comportamiento inesperado, comunícate con el equipo de asistencia y proporciona la mayor cantidad de detalles posible.

¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.