Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Preguntas frecuentes sobre la migración de SOAR

Compatible con:

Google SecOps SOAR

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 el impacto de la migración

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

Estamos modernizando la infraestructura de SOAR con la migración a Google Cloud. Esta actualización crítica proporciona beneficios clave, como mayor confiabilidad, mejor seguridad, mayor cumplimiento y control de acceso más detallado. También otorga 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 con la mejor capa de API 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 roles (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:

Migrar el proyecto de SOAR a un proyecto de Google Cloud propiedad del cliente
Migra la autenticación y los permisos de SOAR a IAM de Google Cloud .
Migra las APIs de SOAR a la API de Chronicle.
Migra la infraestructura de autenticación de los agentes remotos.

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

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

Propiedad del proyecto de GCP: Tu proyecto de SOAR migrará de la propiedad de Google a tu proyecto de Google Cloud propiedad del cliente.
Autenticación:
- Clientes de SecOps unificada: Sin cambios. La autenticación se seguirá administrando con Google Cloud IAM.
- Clientes independientes de SOAR: La autenticación ahora se administrará con la IAM de 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 los usuarios serán más detallados y se administrarán con IAM. Los entornos y los roles de SOC se seguirán administrando en el módulo de 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 los **Registros de auditoría de Cloud **.
Nueva URL (solo para SOAR): Los usuarios de SOAR independiente recibirán una URL nueva (dominio nuevo) para acceder a SOAR.

P.: ¿Cómo se notificará a los clientes y 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 que se debe 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 proyecto de Google Cloud ?

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 habrá costos asociados.

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

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

P.: En el caso de 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 y un SOAR), debes usar el ID del proyecto de Google Cloud existente asociado con tu SIEM. Esto permite una administración unificada de los flujos administrativos, como el RBAC y los registros.

P.: En el caso de las instancias de Google SecOps con consideraciones especiales, como los Controles del servicio de VPC (VPC-SC), ¿qué pasos se deben seguir?

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

Hay dos funciones de la API que no son compatibles con VPC-SC:

Webhooks
Vínculos de aprobación de guías

P.: ¿Cómo puedo comprobar que la migración se realizó correctamente?

Para verificar que se haya completado correctamente, ve a Configuración de SOAR > Administración de licencias. Después de la etapa 1, dirá Google.com después del número de versión del sistema. Después de la etapa 2 de la migración de permisos de SOAR a roles de IAM , se mostrará Google.com y CloudIAM Enabled después del número de versión del sistema.

Tiempo de inactividad y continuidad

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

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

Hasta 2 horas para los clientes independientes de SOAR.
Hasta 1.5 horas para los clientes de Google SecOps

Durante este período, no podrás acceder a la plataforma. Los servicios de SOAR (incluidos la transferencia, las guías 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 transferirán automáticamente una vez que se reanuden los servicios de SOAR?

Sí. Una vez que el sistema vuelva a estar en línea, se reanudarán la transferencia y las guías, y se procesarán las alertas que se hayan generado o transferido durante el tiempo de inactividad.

P.: ¿Qué sucede con las guías que se están ejecutando cuando comienza el tiempo de inactividad?

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

P.: ¿Existe un plan de contingencia o reversión en caso de que algo salga mal durante la migración?

Sí. El proceso de migración mantiene intacta tu instancia de SOAR existente (aunque desactivada). Si el proceso de migración no se completa correctamente, podemos volver a la instancia existente y quitar la nueva. Este proceso de reversión tarda hasta 30 minutos. Realizaremos pruebas exhaustivas y una supervisión estricta, 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 identidades, IDP o Google Cloud para usar la guía de solución de problemas para la identificación y 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 dejarán de estar disponibles y dejarán de funcionar después del 31 de marzo de 2027. Para garantizar una transición sin problemas, sigue estos dos pasos obligatorios:

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

Autenticación y permisos

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

Usarás una secuencia de comandos de migración en tu consola de Google Cloud 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 los grupos de permisos personalizados y solo usar roles predefinidos?

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

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 será el impacto en las cuentas de usuario existentes?

Suponiendo que tus usuarios existentes coincidan con uno de los grupos y que los permisos se asignen correctamente, no debería haber ningún impacto 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 asignación nueva.

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

Los clientes que hayan configurado 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 a 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 que se indican en Autentica 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 que ninguna dirección IP acceda a la API de Chronicle. De manera opcional, puedes incluir en la lista de entidades permitidas 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 de SOAR después de que se completa la primera etapa de la migración. Los registros estarán disponibles en tu proyecto de Google Cloud después de que se complete 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 seguir accediendo a estos datos de BigQuery después de la migración?

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

Logística y asistencia

P.: ¿Puedo elegir un horario diferente para la migración?

No. No es posible realizar la migración 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 inicio y al final del proceso de migración.

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

Migra los grupos de permisos de SOAR a IAM

En la siguiente sección, se abordan los problemas habituales 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 consola de Google Cloud ?

Esto puede deberse a dos motivos:

Faltan permisos: La herramienta de migración requiere que tu cuenta de usuario tenga permisos suficientes tanto en la instancia de Google Cloud como 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 de Google SecOps unificado, asegúrate de usar IAM para administrar los roles y permisos del lado de 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: Recibo un error cuando intento ejecutar las secuencias de comandos de migración. ¿Qué debo hacer?

Error: "Group does not exist": Cuando uses 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 ocurrir conflictos cuando se vincula a una principal que ya tiene vinculaciones condicionales. Para resolver este problema, vuelve a ejecutar la secuencia de comandos y asegúrate de seleccionar Ninguna en lugar de Especificar una condición nueva.

Problemas de acceso después de la migración

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

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

Verifica los roles y permisos de Google SecOps. Asegúrate de que tu rol de IAM personalizado 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 las llamadas a la API específicas que devuelven 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 funciona, abre un ticket de asistencia.

Permisos y roles

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?

A veces, la migración manual de IAM puede provocar que falten permisos necesarios para los roles de SOAR. Te recomendamos que uses la secuencia de comandos de migración proporcionada para asegurarte de que todos los permisos necesarios estén configurados correctamente. Si aún planeas realizar la migración manual, revisa con atención los permisos de IAM de Google SecOps para crear los roles personalizados con los permisos necesarios.

P.: Después de la migración, algunos usuarios parecen tener más permisos en SOAR de lo esperado. ¿A qué se debe este cambio?

Esto puede suceder si ya se asignaron usuarios o grupos a roles amplios predefinidos de Chronicle Google Cloud antes de la migración. 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:

Revisa tus roles predefinidos en la página Roles de IAM, incluido el de administrador de la API de Chronicle, para identificar todas las principales asignadas (usuarios y grupos).
Confirma que solo se asignen a estos roles los usuarios que requieren permisos de SOAR.
Para limitar el acceso a SOAR de principales específicos, quítalos de los roles predefinidos y asígnalos a un rol personalizado que excluya explícitamente los permisos de administrador de SOAR.

P.: La migración se realizó 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 se sigue mostrando en la página Asignación de grupos para mantener la retrocompatibilidad. No borres estas asignaciones. La columna se quitará antes del 31 de marzo de 2027 sin que esto afecte a los clientes.

Prácticas recomendadas

Usa la secuencia de comandos de migración: Siempre que sea posible, usa la secuencia de comandos de migración oficial en Google Cloud para controlar la transición de los grupos de permisos de SOAR a los roles de IAM.
Revisa los permisos de IAM: Familiarízate con los permisos de IAM de Google Cloud necesarios para las diferentes funciones y roles de SOAR.
Realiza pruebas exhaustivas: Después de la migración, prueba el acceso para diferentes roles y perfiles de usuario para asegurarte de que todo funcione según lo esperado.
Comunícate con el equipo de asistencia: Si se producen errores persistentes o comportamientos inesperados, 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.