Preguntas frecuentes sobre la migración de SOAR
Consulta las respuestas a preguntas frecuentes sobre el proceso de migración de SOAR. Descubre soluciones a problemas frecuentes y prácticas recomendadas para que la transición sea todo un éxito.
Ámbito e impacto de la migración
P: ¿Por qué es necesaria esta migración?
Estamos modernizando la infraestructura de SOAR migrando a Google Cloud. Esta actualización crítica ofrece ventajas clave, como una mayor fiabilidad, una seguridad mejorada, un mayor cumplimiento y un control de acceso más granular. También da acceso a las funciones de IA basadas en agentes mediante la integración de Model Context Protocol (MCP).
La migración proporciona lo siguiente:
- Mejora la fiabilidad y las funciones de monitorización de SOAR gracias a la mejor capa de APIs de Google. Esta capa proporciona una solución de API líder con funciones avanzadas de gestión de cuotas, auditoría y observabilidad.
- Desbloquea el control de acceso basado en roles (RBAC) para las funciones y los datos de toda la plataforma.
- Ofrece funciones de cumplimiento más avanzadas, como Controles de Servicio de VPC, residencia de datos y claves de cifrado gestionadas por el cliente (CMEK).
P: ¿Cuál es el ámbito de la migración?
La migración implica los siguientes componentes:
- Migrar un proyecto de SOAR a un proyecto propiedad del cliente. Google Cloud
- Migración de la autenticación y los permisos de SOAR a Google Cloud IAM.
- Migrar APIs de SOAR a la API de Chronicle.
- Migrar agentes remotos.
- Migración de registros de auditoría de SOAR.
P: ¿Qué cambios se producen inmediatamente después de la migración?
Inmediatamente después de la migración, notarás varios cambios importantes:
- Propiedad del proyecto de GCP: tu proyecto de SOAR se migrará de la propiedad de Google al proyecto de tu cliente. Google Cloud
- Autenticación:
- Clientes de SecOps unificado: no hay cambios. La autenticación seguirá gestionándose mediante Google Cloud gestión de identidades y accesos.
- Clientes de SOAR independiente: la autenticación ahora se gestionará mediante Google Cloud gestión de identidades y accesos. En el caso de los usuarios que utilicen SAML, esto significa adoptar la federación de identidades de Workforce, y la configuración de SAML dejará de almacenarse y gestionarse en el propio sistema SOAR, lo que permitirá reforzar los controles de seguridad.
- RBAC: los permisos de usuario serán más granulares y se gestionarán mediante IAM. Los entornos y los roles de SOC se seguirán gestionando en el módulo SOAR mediante grupos de proveedores de identidades (IdPs).
- Registro de auditoría: los registros de auditoría serán más detallados y se gestionarán en **Registros de auditoría de Cloud **.
- Nueva URL (solo para SOAR): los usuarios independientes de SOAR recibirán una nueva URL (nuevo dominio) para acceder a SOAR.
P: ¿Cómo se les está notificando esta migración a los clientes y partners?
Se muestra una ventana emergente en el producto a todos los clientes y partners, que incluye la fecha de migración y un enlace a un formulario que deben rellenar. Se le pedirá que confirme la fecha y la hora de la migración.
P: ¿Cambiarán nuestros costes de infraestructura como resultado de que SOAR esté vinculado a nuestro proyecto Google Cloud ?
No, tus costes no se verán afectados. No debería notar ningún cambio en el frontend. No se ejecutará ningún recurso nuevo en tu proyecto, por lo que no habrá costes 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 tu ID de proyecto Google Cloud . Si eres cliente independiente de SOAR, tendrás que compartir tu Google Cloud ID de proyecto con nosotros.
P: Si un cliente ya ha implementado Google SecOps, ¿debe usar el mismo ID de proyecto que el SIEM o necesita un proyecto independiente?
En el caso de una implementación unificada de Google SecOps (un SIEM y un SOAR), debes usar el ID de proyecto asociado a tu SIEM. Google Cloud Esto permite gestionar de forma unificada los flujos administrativos, como el control de acceso basado en roles y los registros.
P: ¿Qué pasos hay que seguir en las instancias de Google SecOps con consideraciones especiales, como Controles de Servicio de VPC (VPC SC)?
Para habilitar la migración, deberá definir reglas de entrada y de salida en su política de SC de VPC. Para obtener instrucciones detalladas sobre estas reglas específicas, póngase en contacto con el equipo de Asistencia.
Tiempo de inactividad y continuidad
P: ¿Hay algún periodo de inactividad durante la migración? ¿Cómo afecta?
Sí. El tiempo de inactividad previsto es el siguiente:
- Hasta 2 horas para los clientes de SOAR independiente.
- Hasta 1,5 horas para los clientes de Google SecOps.
Durante este periodo, no podrás iniciar sesión en la plataforma. Los servicios de SOAR (incluidos la ingesta, los cuadernos de estrategias 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 incorporarán automáticamente una vez que se reanuden los servicios de SOAR?
Sí. Cuando el sistema vuelva a estar online, se reanudarán la ingesta y los cuadernos de estrategias, y se procesarán las alertas que se hayan generado o ingerido durante el tiempo de inactividad.
P: ¿Qué ocurre con los manuales que se están ejecutando cuando empieza el periodo de inactividad?
El servicio de guías se desactivará antes de que empiece la migración. Es posible que algunas guías en ejecución fallen y deban reiniciarse manualmente o se reanuden una vez completada 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 (aunque esté desactivada). Si el proceso de migración no se completa correctamente, podemos volver a tu instancia y eliminar la nueva. Este proceso de reversión tarda hasta 30 minutos. Realizaremos pruebas exhaustivas y una monitorización minuciosa, con personal de guardia disponible para asegurar que la migración se realice correctamente.
P: ¿Cuándo puedo migrar a los nuevos endpoints de SOAR en la API de Chronicle?
El acceso anticipado a los nuevos endpoints de SOAR, que están en la versión beta de la API de Chronicle V1, estará disponible a partir del 1 de noviembre del 2025. El acceso general a la API Chronicle V1 estará disponible a partir del 1 de enero del 2026. Debes completar la migración de grupos de permisos de SOAR a Cloud IAM antes de migrar de la API de SOAR antigua. Debes actualizar tus secuencias de comandos e integraciones para sustituir los endpoints de la API SOAR por los endpoints de la API Chronicle correspondientes. Las APIs y las claves de API antiguas de SOAR funcionarán hasta el 30 de junio del 2026.
Autenticación y permisos
P: ¿Cómo migro mis grupos y permisos de SOAR?
Estamos preparando un asistente de migración para que lo uses en tu consola y puedas migrar los grupos de permisos a roles personalizados de IAM. Google Cloud La secuencia de comandos también asigna roles personalizados a los usuarios (en el caso de los clientes de Cloud Identity) o a los grupos de proveedores de identidades (en el caso de los clientes de la federación de identidades de Workforce).
P: ¿Qué ocurre si prefiero no migrar grupos de permisos personalizados y solo usar roles predefinidos?
Puedes inhabilitar la migración automática y asignar manualmente grupos de proveedores de identidades a roles de gestión de identidades y accesos de Cloud.
P: Somos clientes independientes de SOAR con un proveedor de SAML personalizado con autenticación manual. Si cambiamos a grupos de IdP para la asignación de IdPs, ¿cómo afectará a las cuentas de usuario actuales?
Si tus usuarios actuales coinciden con uno de los grupos y los permisos se han asignado correctamente, no debería haber ningún impacto en tus cuentas de usuario. Sin embargo, si los usuarios no están asignados a grupos, no podrán iniciar sesión. Si los permisos se asignan de forma diferente, los usuarios recibirán nuevos permisos en función de la nueva asignación.
P: ¿Hay requisitos específicos para los MSSPs que usan varios proveedores de identidades?
Los clientes que hayan configurado varios proveedores de identidades en la página de autenticación externa de SOAR deben definir la federación de identidades de los empleados para la autenticación y crear un grupo de empleados independiente para cada proveedor. Cada proveedor se asociará a un subdominio diferente.
Almacenamiento de registros y monitorización
P: Hemos completado la primera fase de la migración, pero no vemos los registros en los registros de auditoría de Cloud.
Los registros se almacenan en la plataforma SOAR una vez completada la primera fase de la migración. Los registros estarán disponibles en tu proyecto Google Cloud una vez que se haya completado la segunda fase de la migración.
P: ¿Podrán los clientes que envíen datos de SOAR a una instancia de BigQuery (BQ) gestionada seguir accediendo a estos datos de BigQuery después de la migración?
Sí. El BigQuery gestionado seguirá funcionando.
Logística y asistencia
P: ¿Puedo elegir otra franja horaria para la migración?
No. No es posible migrar fuera de los periodos 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 ponernos en contacto si surge algún problema después de la migración?
Debes crear una incidencia para registrar el problema y hacer un seguimiento del progreso.
¿Necesitas más ayuda? Recibe respuestas de los miembros de la comunidad y de los profesionales de Google SecOps.