Guía de validación previa a la migración

Compatible con:

En este documento, se describe un enfoque de diagnóstico sistemático paso a paso para validar la instancia de Google Security Operations y la configuración de autenticación antes de la migración de SOAR. En esta guía, se explican los estándares de SAML y OIDC que se usan para la autenticación y autorización de usuarios.

Validación de la configuración de la API de Chronicle

Para verificar si la API de Chronicle está configurada correctamente en tu proyecto de Google Cloud , sigue estos pasos:

  1. Accede a la consola deGoogle Cloud y selecciona el proyecto de Google Cloud correcto en la lista de proyectos de la barra de navegación superior.
  2. Abre el menú de navegación (≡) y ve a APIs y servicios > APIs y servicios habilitados.
  3. Ve a la lista de APIs y servicios habilitados para encontrar Chronicle API.

  4. Si aparece en la lista: La API está habilitada.

    Si NO aparece en la lista: Haz clic en + HABILITAR APIS Y SERVICIOS en la parte superior, busca Chronicle API y haz clic en Habilitar.

Para verificar si se creó la cuenta de servicio, haz lo siguiente:

  1. Ve a la página de IAM en la consola de Google Cloud .
  2. Revelar cuentas ocultas (paso fundamental): Debes seleccionar la casilla que se encuentra en el lado derecho de la barra de filtros que dice Incluir asignaciones de roles proporcionadas por Google.
  3. Busca el agente: En la barra de filtros, escribe chronicle. Buscas una dirección de correo electrónico que coincida con este patrón específico: service-[PROJECT_NUMBER]@gcp-sa-chronicle.iam.gserviceaccount.com
  4. Verifica los permisos: Asegúrate de que tenga el rol de Agente de servicio de Chronicle. Si falta el rol, haz clic en editar Editar y agrégalo de nuevo.

Validación de la configuración de Google SecOps

  1. En la consola de Google Cloud , selecciona el Google Cloud proyecto correcto de la lista.
  2. Ve a Seguridad > Google SecOps y aparecerá la pestaña Inicio de sesión único.
  3. Si Google SecOps está habilitado, deberías ver una pestaña llamada inicio de sesión único. De lo contrario, la iniciación del cliente potencial estará incompleta. Proporciona el ID del proyecto de Google Cloud en el formulario de Google que se encuentra en la notificación del producto. Confirma la fecha y el horario de la migración y, luego, envía el formulario. Si no recibes una respuesta en un plazo de 72 horas después del envío, comunícate con soar-migration-to-gcom@google.com.
  4. Si la pestaña existe, haz clic en Ir a SecOps. El acceso exitoso confirma que la configuración de autenticación es correcta. Si falla el acceso, usa la siguiente sección para depurar la configuración. Si falla el acceso, usa la siguiente sección para depurar la configuración.

Flujo de SAML y solución de problemas

En esta sección, se proporciona una descripción general del proceso de autenticación de SAML y se describe un enfoque sistemático para diagnosticar y resolver problemas de configuración comunes.

Arquitectura del flujo de trabajo de autenticación

Comprender el flujo de solicitudes es fundamental para aislar cualquier punto de falla. En el siguiente diagrama, se ilustra la ruta secuencial de un acceso exitoso.

Arquitectura del flujo de trabajo de autenticación

Procedimiento de solución de problemas paso a paso

Para diagnosticar y rastrear el proceso de autenticación SAML de manera eficaz, puedes usar las utilidades basadas en la Web que se indican en las siguientes secciones.

Si bien Google no respalda ningún producto en particular, se sabe que las siguientes herramientas ayudan a solucionar problemas durante el proceso:

  • Validación de SAML: https://www.samltool.io/
    • Propósito: Se usa para decodificar y validar solicitudes y respuestas de SAML sin procesar.
  • Inspección de JWT: https://www.jwt.io/
    • Propósito: Se usa para inspeccionar los reclamos y el contenido de los tokens web JSON (JWT).

Fase 1: Preparación del entorno

Antes de comenzar, asegúrate de que tu entorno de navegador esté listo para capturar el tráfico de red. Para ello, completa los siguientes pasos:

  1. Abre una nueva pestaña del navegador o usa una ventana de incógnito.

  2. Abre las Herramientas para desarrolladores con el acceso directo de tu sistema operativo:

    • Windows: Presiona F12.
    • Linux: Presiona Ctrl + Mayúsculas + I.
    • macOS: Presiona Cmd + Option + I.

  3. Navega a la pestaña Red.

  4. Selecciona la casilla Guardar el registro para asegurarte de que no se pierdan datos durante los redireccionamientos.

    Guardar el registro

  5. Navega a la URL de tu entorno de Google SecOps para iniciar el flujo de acceso. Recibirás esta URL por correo electrónico después de completar la configuración de Google SecOps en el paso 5 de la etapa 1 de la migración para los clientes independientes de SOAR. El asunto del correo electrónico es Your Google SecOps instance is ready.

Fase 2: Valida la solicitud de SAML al IdP

En este paso, se verifica el mensaje inicial que Google Cloud envía a tu proveedor de identidad (IDP).

  1. Ubica la solicitud: En la barra de filtros de la pestaña Red, busca saml.

    Ubica la solicitud

  2. Extraer datos: Selecciona la solicitud y haz clic en la pestaña Carga útil. Ubica el parámetro de cadena de consulta etiquetado como SAMLRequest.

    Extraer datos

  3. Decodificar: Copia el valor de la solicitud y pégalo en la herramienta Validación de SAML (samltool.io) para decodificarlo.

    Decodifica

  4. Verificación:

    • Verifica el destino de la solicitud.
    • Confirma que esta URL coincida con la configuración de tu IdP.

Fase 3: Valida la respuesta de SAML del IdP

En este paso, se verifican los atributos que devuelve el IdP a Google Cloud después de la autenticación.

  1. Ubica la respuesta: En la barra de filtros de la pestaña Red, busca signin-callback.

    Ubica la respuesta

  2. Extraer datos: Selecciona la solicitud y haz clic en la pestaña Carga útil. Ubica los datos de SAMLResponse.

    Ubica los datos de respuesta de SAML

  3. Decodificar: Copia el valor de la respuesta y pégalo en la herramienta Validación de SAML.

  4. Verificación:

    • Revisa los reclamos (atributos) que se devolvieron, como groups, first name, last name y email.
    • Crítico: Asegúrate de que estos atributos coincidan con la configuración del parámetro de configuración Workforce pool en Google Cloud.

    • Confirma que los valores sean correctos para el usuario específico que intenta acceder.

      Configuración del grupo de personal

En la siguiente imagen, se muestra una asignación de atributos:

attribute-mapping

La asignación en la imagen es la siguiente:

  • google.subject = assertion.subject
  • attribute.last_name = assertion.attributes.last_name[0]
  • attribute.user_email = assertion.attributes.user_email[0]
  • attribute.first_name = assertion.attributes.first_name[0]
  • google.groups = assertion.attributes.groups

La parte izquierda siempre es la misma: es la sintaxis de Google. El lado derecho se basa en las claves de atributos de la declaración que se muestran en la respuesta de SAML.

El [0] es fundamental para los atributos específicos indicados (last_name, user_email y first_name), y no es relevante para subject y groups.

Fase 4: Valida la autenticación de Google SecOps

En este paso, se verifica si Google Cloud autentica al usuario para acceder a Google SecOps SOAR.

  1. Ubica el token en el navegador del usuario: En la barra de filtros de la pestaña Red, busca el extremo auth/siem.

    Cómo encontrar el token en el navegador del usuario

  2. Extrae datos: Selecciona la solicitud y ve a la pestaña Carga útil. Ubica la cadena jwt.

  3. Decodificación: Copia la cadena de JWT y pégala en la herramienta JWT Inspection (jwt.io).

    Copia la cadena de JWT y pégala.

  4. Verificación:

    • Compara los reclamos decodificados para given_name, family_name, email y idpgroups.
    • Confirmación de coincidencia: Estos valores deben coincidir exactamente con los atributos validados en la fase 3 (respuesta de SAML).
    • Si los valores coinciden y aún no tienes acceso, verifica la asignación de roles en IAM. Asegúrate de que a todos tus usuarios se les asigne uno de los roles predefinidos de Chronicle con el formato de principal correcto para tu configuración de identidad (federación de identidades de personal o Cloud Identity para cuentas administradas por Google).

Fase 5: Valida el acceso a los permisos de SOAR

Este paso confirma que el sistema asigna permisos en SOAR correctamente a través de la página Group Mapping de la plataforma.

Los administradores acceden a SOAR automáticamente porque la página Group Mapping habilita el acceso predeterminado.

Puedes validar el acceso al grupo de tus usuarios agregando algunas asignaciones de grupos de IdP en esta nueva instancia de SOAR. De forma predeterminada, las instancias nuevas tienen una página Group Mapping vacía. Para validar el acceso a grupos de otros usuarios, agrega asignaciones de grupos de IdP a la nueva instancia de SOAR. Para ello, completa los siguientes pasos:

  1. Copia las asignaciones de grupos de la página Group Mappings en tu instancia de SOAR existente.
  2. Solicita que un usuario del grupo de IdP acceda a la nueva URL de Google SecOps.

  3. Si el usuario no puede acceder a SOAR, sigue estos pasos para solucionar el problema:

    a. Inspecciona la respuesta: Abre la solicitud auth/siem de la fase 4 y selecciona la pestaña Vista previa.

    b. Verifica los permisos: Busca el objeto permissions dentro de la respuesta JSON.

Opcional: Para ahorrar tiempo, copia estas asignaciones en tu instancia existente de Google SecOps en Configuración > Avanzada > Asignación de grupos.

Flujo de OIDC y solución de problemas

En esta sección, se proporciona una descripción general del proceso de autenticación de OIDC y se describe un enfoque sistemático para diagnosticar y resolver problemas comunes de integración.

Arquitectura del flujo de trabajo de autenticación

Comprender el flujo de solicitudes es fundamental para aislar cualquier punto de falla. En el siguiente diagrama, se ilustra la ruta secuencial de un acceso exitoso.

Arquitectura del flujo de trabajo de autenticación

Procedimiento paso a paso para solucionar problemas de OIDC

Para diagnosticar y rastrear el proceso de autenticación de OIDC de manera eficaz, puedes usar las herramientas para desarrolladores del navegador y los decodificadores de JWT en línea.

  • Inspección de JWT: https://www.jwt.io/
    • Propósito: Se usa para inspeccionar los reclamos y el contenido de los tokens web JSON (JWT).

Fase 1: Preparación del entorno

Antes de comenzar, asegúrate de que tu entorno de navegador esté listo para capturar la red. Para ello, completa los siguientes pasos:

  1. Abre una nueva pestaña del navegador en blanco o en una ventana de incógnito.

  2. Abre las Herramientas para desarrolladores con el acceso directo de tu sistema operativo:

    • Windows: Presiona F12.
    • Linux: Presiona Ctrl + Mayúsculas + I.
    • macOS: Presiona Cmd + Option + I.

  3. Navega a la pestaña Red.

  4. Selecciona la casilla Guardar el registro para asegurarte de que no se pierdan datos durante los redireccionamientos.

    Guardar el registro

  5. Navega a la URL de tu entorno de Google SecOps para iniciar el flujo de acceso. Recibirás esta URL por correo electrónico después de completar la configuración de Google SecOps en el paso 5 de la etapa 1 de la migración para los clientes independientes de SOAR. El asunto del correo electrónico es YourGoogle SecOps instance is ready.

Fase 2: Valida la solicitud de autorización a un proveedor de OIDC

En este paso, se verifica el redireccionamiento inicial de Google Cloud a tu proveedor de OpenID Connect (IdP).

  1. Busca la solicitud: En la pestaña Red, busca el redireccionamiento inicial al extremo de autorización de tu proveedor de OIDC. Por lo general, la URL contiene parámetros como client_id, redirect_uri, scope, response_type y state.

    Ubica la solicitud

  2. Verificación:

    • Confirma que client_id coincida con el configurado en tu proveedor de OIDC.
    • Asegúrate de que redirect_uri coincida exactamente con https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID y reemplaza POOL_ID y PROVIDER_ID por tu grupo y proveedor de la federación de identidades de personal.
    • Verifica que response_type esté configurado como código.
    • Ten en cuenta el parámetro de alcance, que debe incluir openid y cualquier otro alcance necesario para liberar los reclamos necesarios (por ejemplo, correo electrónico y perfil).

Fase 3: Valida el intercambio de devolución de llamada y token

En este paso, se verifica la respuesta del IdP a Google Cloud.

  1. Ubica la devolución de llamada: En la pestaña Red, busca la solicitud a la URL de devolución de llamada de acceso (.../signin-callback/...).

    Ubica la devolución de llamada

  2. Verifica los datos: Verifica los parámetros de la URL de esta solicitud. Debe contener un parámetro de código proporcionado por tu IdP de OIDC.

  3. Tras bambalinas: La federación de identidades de personal intercambia este código por tokens (token de ID y token de acceso) desde el extremo de tokens del proveedor de OIDC. Los errores en esta etapa suelen ser visibles en Cloud Logging para la federación de identidades de personal.

    • Verifica la propagación de atributos y el token completo: Para verificar que la asignación de atributos en la federación de identidades de personal produzca los resultados esperados, haz lo siguiente:
      • Agrega el URI de redireccionamiento, que se proporciona en la configuración del proveedor de la federación de identidades de personal, a los URI de redireccionamiento de tu proveedor (por ejemplo, https://auth.cloud.google/signin-callback/locations/global/workforcePools/POOL_ID/providers/PROVIDER_ID).
      • Ve a tu proveedor de federación de identidades de personal para depurar el token de IdP. También puedes verificar el token completo. Para obtener más información, consulta Cómo verificar la configuración de tu producto.

    Ver el token completo Valida atributos

Fase 4: Valida la autenticación de Google SecOps

En este paso, se verifica si Google Cloud autentica al usuario para acceder a Google SecOps SOAR.

  1. Ubica el token en el navegador del usuario: En la barra de filtros de la pestaña Red, busca el extremo auth/siem.

    Cómo encontrar el token en el navegador del usuario

  2. Extrae datos: Selecciona la solicitud y ve a la pestaña Carga útil. Ubica la cadena jwt.

  3. Decodificación: Copia la cadena de JWT y pégala en la herramienta JWT Inspection (jwt.io).

    Copia la cadena de JWT y pégala.

  4. Verificación:

    • Compara los reclamos decodificados para sub, given_name, family_name, email y idpgroups.
    • Confirmación de coincidencia: Estos valores deben corresponder a los atributos que publica tu proveedor de OIDC y a cómo se asignan en las asignaciones de atributos de la federación de identidades de personal. Por ejemplo, attribute.first_name en Google Cloud debe asignarse a given_name en el JWT.
    • Roles de IAM: Si los reclamos son correctos, pero se deniega el acceso con un mensaje como Cannot Authenticate user, because user does not have access to the GCP project...,, verifica las asignaciones de roles de IAM. Asegúrate de que a los grupos del usuario (idp_groups en el JWT) se les otorguen los roles necesarios con el formato principalSet correcto (por ejemplo, principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/IDP_GROUP_NAME).

Fase 5: Valida el acceso a los permisos de SOAR

Este paso confirma que el sistema asigna permisos en SOAR correctamente a través de la página Group Mapping de la plataforma.

Los administradores acceden a SOAR automáticamente porque la página Group Mapping habilita el acceso predeterminado.

Puedes validar el acceso al grupo de tus usuarios agregando algunas asignaciones de grupos de IdP en esta nueva instancia de SOAR. De forma predeterminada, las instancias nuevas tienen una página Group Mapping vacía. Para validar el acceso a grupos de otros usuarios, agrega asignaciones de grupos de IdP a la nueva instancia de SOAR. Para ello, completa los siguientes pasos:

  1. Copia las asignaciones de grupos de la página Group Mappings en tu instancia de SOAR existente.
  2. Solicita que un usuario del grupo de IdP acceda a la nueva URL de Google SecOps.

  3. Si el usuario no puede acceder a SOAR, sigue estos pasos para solucionar el problema:

    a. Inspecciona la respuesta: Abre la solicitud auth/siem de la fase 4 y selecciona la pestaña Vista previa.

    b. Verifica los permisos: Busca el objeto permissions dentro de la respuesta JSON.

Opcional: Para ahorrar tiempo, copia estas asignaciones en tu instancia existente de Google SecOps en Configuración > Avanzada > Asignación de grupos.

Errores comunes de OIDC:

  • invalid_redirect_uri del IdP: Asegúrate de que el URI de redireccionamiento configurado en tu IdP coincida exactamente con https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID, reemplazando POOL_ID y PROVIDER_ID por tu grupo y proveedor de la federación de identidades de personal. Incluso una barra final o una discrepancia entre http y https activarán este error.

  • Faltan reclamaciones en el JWT:

    1. Lado del IdP: Verifica que el cliente de OIDC esté configurado para liberar los reclamos requeridos (que se asignan en el WIF, como sub, groups, email, given_name, family_name) en el token de ID.

    2. Lado de WIF: Asegúrate de que estos reclamos entrantes se asignen correctamente en la sección WIF Attribute Mapping (por ejemplo, google.groups=assertion.groups). Si hay un reclamo en el token, pero no se asigna en WIF, es posible que la plataforma de SOAR no pueda autorizar al usuario. Para verificar que tu asignación de atributos produzca los resultados esperados, consulta Cómo verificar la configuración del proveedor.

Asignaciones de grupos después de la migración

La asignación de grupos sigue siendo fundamental en Google SecOps después de que se completa la migración

Después de la migración, la instancia migrada conserva las asignaciones de grupos. Sirven como base para determinar el acceso de los usuarios a SOAR. Debes asegurarte de que todos los usuarios estén asignados en esta página para acceder a Google SecOps. Consulta Cómo acceder a una instancia para obtener más información.

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