Preguntas frecuentes sobre la migración a 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 e 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, seguridad mejorada, mayor cumplimiento y control de acceso más detallado. También brinda acceso a las capacidades de la IA agentiva a través de la integración del Protocolo de contexto del modelo (MCP).
La migración proporciona lo siguiente:
- Mejora las capacidades de supervisión y confiabilidad 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 Google Cloud propiedad del cliente.
- Se migró la autenticación y los permisos de SOAR a Google Cloud IAM.
- Se migraron las APIs de SOAR a la API de Chronicle.
- Migración de agentes remotos
- Migración de 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, notarás varios cambios clave:
- Propiedad del proyecto de GCP: Tu proyecto de SOAR migrará de la propiedad de Google a tu proyecto Google Cloud propiedad del cliente.
- Autenticación:
- Clientes de SecOps unificadas: No hay cambios. La autenticación seguirá siendo administrada por Google Cloud IAM.
- Clientes de SOAR independiente: La autenticación ahora se administrará con Google Cloud IAM. Para los usuarios que utilizan SAML, esto significa adoptar la federación de identidades de Workforce, y la configuración de SAML ya no se almacenará ni administrará dentro del propio 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 los roles del SOC se seguirán administrando dentro del módulo de SOAR con grupos del proveedor de identidad (IdP).
- Audit Logging: Los registros de auditoría serán más detallados y se administrarán en los **Registros de auditoría de Cloud **.
- URL nueva (solo para 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 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 para completar. Se le pedirá que confirme 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 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 Google Cloud . Si eres cliente de Unified SecOps, ya tenemos el ID de tu proyecto Google Cloud . Si eres cliente independiente de SOAR, deberás compartir con nosotros tu ID de proyecto de Google Cloud .
P.: Para los clientes que ya tienen una implementación de SecOps de Google, ¿debemos usar el mismo ID del proyecto que el 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 Google Cloud existente asociado con tu SIEM. Esto permite la administración unificada de los flujos administrativos, como el RBAC y los registros.
P.: ¿Qué pasos se deben seguir para las instancias de SecOps de Google que tienen consideraciones especiales, como los Controles del servicio de VPC (VPC SC)?
Para habilitar la migración, deberás definir reglas de entrada y salida en tu política de SC de VPC. Si deseas obtener orientación detallada sobre estas reglas específicas, comunícate con el equipo de asistencia.
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 previsto 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 los de transferencia, 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 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 los playbooks, 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 descanso?
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.: ¿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é apagada). 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, y tendremos personal de guardia para garantizar una migración exitosa.
P.: ¿Cuándo puedo migrar a los nuevos extremos de SOAR en la API de Chronicle?
El acceso anticipado a los nuevos extremos de SOAR, que se encuentran en la versión beta de la API de Chronicle V1, estará disponible a partir del 1 de noviembre de 2025. El acceso general a la versión 1 de la API de Chronicle estará disponible a partir del 1 de enero de 2026. Debes completar la migración de los grupos de permisos de SOAR a Cloud IAM antes de migrar desde la API heredada de SOAR. Debes actualizar tus secuencias de comandos e integraciones para reemplazar los extremos de la API de SOAR por los extremos correspondientes de la API de Chronicle. Las APIs heredadas de SOAR y las claves de API funcionarán hasta el 30 de junio de 2026.
Autenticación y permisos
P.: ¿Cómo migro mis grupos y permisos de SOAR?
Estamos preparando un asistente de migración para usar en tu consola de Google Cloud y 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 automática y asignar manualmente los grupos del IdP a las funciones de Cloud IAM.
P.: Somos clientes independientes de SOAR con un proveedor de SAML personalizado y 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?
Si tus usuarios existentes coinciden con uno de los grupos y los permisos se asignaron 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 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 se asociará con un subdominio diferente.
Registro y supervisión
P.: Completamos la primera etapa de la migración, pero no vemos registros en los registros de Cloud Audit Logs.
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 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 administrada de BigQuery (BQ) podrán seguir accediendo a estos datos de BigQuery después de la migración?
Sí. El BigQuery administrado 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 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?
Debes crear un ticket de asistencia para registrar el problema y hacer un seguimiento del progreso.
¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.