Trabaja con la IU de Feeds

Compatible con:

En este documento, se explica cómo crear, solucionar problemas y administrar feeds en la IU de Feed Management, incluidas las instrucciones para modificarlos, habilitarlos y borrarlos.

Antes de comenzar

Cada feed de datos requiere requisitos previos específicos antes de la configuración en Google Security Operations. Para conocer los requisitos de tu feed, consulta Configuración por tipo de fuente y busca tu fuente de datos específica.

Formatos de compresión y tamaños de archivo admitidos

Los formatos de compresión admitidos para la transferencia de datos del feed incluyen .gz, .tar.gz, .tar y solr.gz. En la siguiente tabla, se describen los diferentes tamaños de archivo que admite la transformación de los feeds de Google SecOps:

Operación Tipo de entrada Tamaño recomendado Duración esperada Tamaño máximo
Modelado de datos CSV Menos de 5 GB < 7 min 10 GB
Modelado de datos CSV Menos de 5 GB ~30 min 10 GB
Modelado de datos CSV Por definir Por definir 2 GB
Modelado de datos XML / JSON < 1 GB < 10 min 2 GB
Modelado de datos XLS / XLSX Menos de 50 MB 1 minuto aprox. 50 MB
Combinar archivos Cualquiera < 1 GB Varía según la cantidad de archivos 100 GB
Descomprimir archivos No es un archivo ZIP Menos de 5 GB Varía según la cantidad de archivos 10 GB (sin comprimir)
Descomprimir archivos ZIP - Varía según la cantidad de archivos 4 GB (sin comprimir)

Límites y delimitadores de líneas de registro

Cuando transfieras registros basados en texto (JSON, CSV o Syslog), asegúrate de que tus datos cumplan con estos límites específicos de transferencia:

  • Tamaño máximo de la línea: Una sola línea de registro no puede superar los 4 MB. Si una sola línea supera este límite, el feed fallará con el error MaxLogLineSize4MBExceeded.
  • Delimitadores admitidos: Se admiten tanto el salto de línea (\n) como el retorno de carro más salto de línea (\r\n).

Impacto del cambio de tu proyecto de Cloud vinculado en los feeds de datos

Si actualizas el proyecto Google Cloud asociado a tu instancia de Google SecOps, se detendrán todos los feeds que transfieran datos con los siguientes conectores, y deberás volver a crearlos de forma manual:

  • AMAZON_S3_V2
  • AMAZON_SQS_V2
  • GOOGLE_CLOUD_STORAGE_V2
  • AZURE_BLOBSTORE_V2
  • GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN

En el caso de todos los demás feeds que no utilizan estos conectores, la transferencia continúa sin interrupciones. Los clientes no deben realizar ninguna acción.

Qué esperar durante la migración

En el caso de los feeds afectados, observarás los siguientes cambios:

  • Estado del feed: Los feeds creados antes de la migración dejarán de extraer datos en vivo de inmediato y se volverán de solo lectura.
  • Datos existentes: Todos los datos que ya se transfirieron a Google SecOps antes de la migración se transferirán automáticamente. No se perderán datos.
  • Mensajes de error: Si intentas editar o borrar un feed anterior, recibirás un mensaje que indica lo siguiente: This feed is read-only because this SecOps has now moved to a new Google Cloud Project (BYOP). To continue ingesting data from this source, please create a new feed.

Acciones requeridas para los clientes

Para garantizar la transferencia continua de datos, debes volver a crear manualmente tus feeds en el nuevo entorno. Sigue estos pasos para minimizar las interrupciones:

  1. Vuelve a crear los feeds: Debes crear feeds nuevos para reemplazar los que existían antes de la migración.
  2. Configura la antigüedad máxima del archivo: Cuando configures tus feeds nuevos, establece la antigüedad máxima del archivo en alrededor de 2 horas antes de que se iniciara la actualización de BYOP. Este tiempo de búfer garantiza una transición sin problemas.
  3. Administra los datos duplicados: Según la antigüedad máxima del archivo que selecciones, es posible que se transfieran algunos datos duplicados. Para obtener detalles técnicos sobre cómo Google SecOps filtra estos registros redundantes, consulta Cómo evitar la deduplicación.

  4. Registra y borra los feeds existentes (antes de la migración): Antes de comenzar la migración de BYOP, registra la configuración de todos los feeds existentes que usan los conectores afectados (por ejemplo, Amazon S3 V2) y, luego, borra los feeds. Si no borras los feeds creados antes de la migración, se volverán imposibles de administrar y permanecerán en la interfaz web de Google SecOps como parámetros de configuración huérfanos.

Formas de configurar feeds

Los clientes de Google SecOps pueden configurar un feed en la plataforma de dos maneras. Usa el método que mejor funcione para tu entorno:

  • Configuración de SIEM > Feeds (estándar)
  • Content Hub > Paquetes de contenido (premium)

Configura tus feeds

En esta sección, se describe cómo configurar tus feeds de manera general, comenzando con el flujo de procedimiento estándar. Los feeds de datos que se enumeran en la página Feeds incluyen todos los feeds que Google configuró para tu cuenta, incluidos los que tú configuraste.

Cómo agregar un feed

Para agregar un feed a tu cuenta de Google SecOps, completa los siguientes pasos:

  1. En el menú de Google SecOps, selecciona Configuración de SIEM > Feeds.

  2. Haz clic en Agregar feed nuevo.

  3. En la siguiente página, haz clic en Configurar un solo feed. Nota: Este paso no es relevante para los clientes que usan la plataforma independiente de Google SecOps SIEM.

  4. Agrega un nombre para el feed.

  5. En la lista Tipo de fuente, selecciona el tipo de fuente para importar datos a Google SecOps. Puedes elegir entre los siguientes tipos de fuentes de feeds:

    • Amazon Data Firehose
    • Amazon S3 (en desuso)
    • Amazon S3 (V2)
    • Amazon SQS (obsoleto)
    • Amazon SQS (V2)
    • Azure Blob Storage (en desuso)
    • Azure Blob Storage (V2)
    • API personalizada
    • Google Cloud Pub/Sub
    • Cloud Storage (obsoleto)
    • Cloud Storage (V2)
    • Cloud Storage Event Driven
    • API de terceros
    • Webhook

    Importante:

    • Cuando uses los feeds de Amazon S3 (obsoleto), Amazon SQS (obsoleto), Azure Blob Storage (obsoleto) y Google Cloud Cloud Storage (obsoleto), asegúrate de tener una ruta de directorio válida.
    • Cuando uses Amazon SQS (obsoleto) o Amazon SQS (V2), otorga explícitamente permisos de Google SecOps para borrar mensajes de la cola de Amazon SQS.
    • Cuando utilices feeds de Amazon SQS (en desuso), asegúrate de que solo un feed consuma mensajes de la cola. Los mensajes que lee otra aplicación o feed no se incorporan al feed actual.
    • El uso de Amazon SQS (obsoleto) como tipo de fuente de feed solo se admite para los registros en buckets de Amazon S3.
  6. En la lista Tipo de registro, selecciona el tipo de registro que corresponde a los registros que deseas transferir. Los registros disponibles varían según el tipo de fuente que seleccionaste anteriormente.

    Si seleccionas Cloud Storage como el tipo de fuente, usa la opción Obtener cuenta de servicio para obtener una cuenta de servicio única. Consulta el ejemplo de configuración del feed de Google Cloud Storage.

  7. Haz clic en Siguiente.

  8. Especifica los parámetros necesarios en la pestaña Input Parameters. Las opciones que se presentan aquí varían según la fuente y el tipo de registro seleccionados en la pestaña Set Properties. Mantén el puntero sobre el ícono de signo de interrogación de cada campo para obtener información adicional sobre lo que debes proporcionar.

  9. Opcional: Puedes especificar un espacio de nombres en la pestaña Set Properties. Para obtener más información sobre los espacios de nombres, consulta Trabaja con espacios de nombres de recursos.

  10. Haz clic en Siguiente.

  11. Revisa la nueva configuración del feed en la pestaña Finalizar.

  12. Haz clic en Enviar. Google SecOps completa una verificación de validación del feed nuevo. Si el feed pasa la verificación, se genera un nombre para él, se envía a Google SecOps y Google SecOps comienza a intentar recuperar datos.

    Finaliza la solicitud del feed

Configura varios feeds para una familia de productos (solo para clientes de Google SecOps)

Puedes configurar varios feeds por familia de productos, según el tipo de registro.

  • Tipos de registros de referencia: Se marcan como recomendados. Estos tipos de registros se recomiendan para la funcionalidad principal de la plataforma.
  • Tipos de registros complementarios: Se marcan como opcionales. Estos tipos de registros proporcionan contexto adicional.

Para simplificar la configuración, la plataforma proporciona instrucciones de configuración específicas y parámetros predefinidos para cada configuración. Por ejemplo, para CrowdStrike Falcon, puedes crear varios feeds únicos en los tipos de registros recomendados y opcionales para asegurarte de que haya suficiente cobertura de datos integral.

Configura el feed para CrowdStrike EDR

Sigue estos pasos para configurar un feed de registros para CrowdStrike EDR.

  1. En Configuración > Feeds, haz clic en Agregar feed nuevo.
    1. Haz clic en el producto CrowdStrike Falcon:
    2. Selecciona el tipo de registro CrowdStrike EDR.
  2. Como alternativa, en Content Hub > Paquetes de contenido, haz clic en el producto CrowdStrike Falcon:
    1. Haz clic en Comenzar.
    2. Selecciona el tipo de registro CrowdStrike EDR.
  3. Especifica valores para los siguientes campos:

    Campo Descripción
    Source Type Amazon SQS
    Region Es la región de AWS S3 asociada al URI.
    Queue Name Es el nombre de la cola de SQS desde la que se leerá.
    Account Number Es el número de cuenta de SQS.
    Source Deletion Option Indica si se deben borrar los archivos y directorios después de la transferencia.
    Queue Access Key ID Es una clave de acceso alfanumérica de 20 caracteres para la cuenta, como AKIAOSFOODNN7EXAMPLE.
    Queue Secret Access Key Clave de acceso secreta alfanumérica de 40 caracteres para la cuenta, como wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY.

  4. Opcional: Configura los siguientes parámetros:

    • Nombre del feed: Es el nombre único predeterminado del feed.
    • Espacio de nombres del activo: Es el espacio de nombres asociado con el feed.
    • Etiquetas de transferencia: Son las etiquetas que se aplican a los eventos de este feed.
  5. Haz clic en Crear feed.

Puedes repetir este proceso para crear feeds adicionales para el mismo tipo de registro. También puedes configurar feeds para otros tipos de registros disponibles directamente desde esta página. Cuando termines, ve a la página Administración de feeds para ver un resumen detallado de todos los tipos de registros configurados.

Incluir en la lista de anunciantes permitidos de IP

Habilita la lista de entidades permitidas y agrega los rangos de IP de Google para todos los tipos de registros que transfieren datos desde APIs de terceros.

Borra los archivos fuente

La opción de borrado de la fuente te permite borrar objetos de la fuente del feed (archivos y carpetas) del almacenamiento después de una transferencia exitosa. Esta opción solo está disponible para los tipos de fuentes de datos seleccionados, incluido Cloud Storage. Estos tipos de fuentes de feeds incluyen el campo SOURCE DELETION OPTION en sus flujos de trabajo Agregar nuevo y Editar feed.

Opciones de eliminación de fuentes

  • Para los tipos de fuentes de feeds admitidos, incluido Cloud Storage, el campo OPCIÓN DE BORRADO DE LA FUENTE ofrece las siguientes opciones:

    • No borrar archivos nunca
    • Borrar los archivos transferidos y los directorios vacíos
    • Borrar archivos transferidos
  • Microsoft Azure Blob Storage (AZURE_BLOBSTORE) no admite el borrado de archivos fuente. En el campo OPCIÓN DE BORRADO DE LA FUENTE, selecciona solo la opción Nunca borrar archivos.

  • Para las siguientes fuentes de feeds ("feedSourceType"): GOOGLE_CLOUD_STORAGE_V2, GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN, AMAZON_S3_V2, AMAZON_SQS_V2 y AZURE_BLOBSTORE_V2, el campo OPCIÓN DE BORRADO DE LA FUENTE ofrece dos opciones:

    • NUNCA: Nunca borra ningún archivo después de las transferencias.
    • ON_SUCCESS: Borra todos los archivos y directorios vacíos después de la transferencia.

Configuración y permisos específicos de la fuente

Los diferentes tipos de fuentes requieren configuraciones específicas de autenticación y redes para comunicarse con Google SecOps. En esta sección, se describe cómo configurar permisos y cuentas de servicio. La configuración que se describe se enfoca en la transferencia de Cloud Storage (basada en extracción), la transferencia de múltiples nubes (extracción entre nubes) y la transferencia basada en envío (API o en tiempo real).

Ejemplo de configuración del feed de Google Cloud Storage

  1. En el menú de Google SecOps, selecciona Configuración y, luego, haz clic en Feeds.
  2. Haz clic en Agregar feed nuevo.
  3. En la siguiente página, haz clic en Configurar un solo feed. Este paso no se aplica si usas la plataforma independiente de Google SecOps SIEM.
  4. Selecciona Cloud Storage v2 en Tipo de fuente.
  5. Selecciona el Tipo de registro. Por ejemplo, para crear un feed para los registros de auditoría de Google Kubernetes Engine, selecciona Registros de auditoría de Google Kubernetes Engine como el Tipo de registro.
  6. Haz clic en Obtener cuenta de servicio. Google SecOps proporciona una cuenta de servicio única que usa para transferir datos. Como alternativa, puedes obtener esta cuenta de servicio de forma programática con la API. Consulta Recupera la cuenta de servicio.
  7. Opcional: Configura la cuenta de servicio. Para obtener más información, consulta Otorga acceso a la cuenta de servicio de Google SecOps.
  8. Haz clic en Siguiente.
  9. Según la configuración de Cloud Storage que creaste, especifica valores para los siguientes campos:

    • URI del bucket de almacenamiento

    • Opción de eliminación del código fuente

    Para obtener más información sobre cómo configurar buckets de Cloud Storage, consulta Crea buckets.

  10. Haz clic en Siguiente y, luego, en Enviar.

Otorga acceso a la cuenta de servicio de Google SecOps

  1. En la consola de Google Cloud , ve a la página Buckets de Cloud Storage.

    Ir a Buckets

  2. Otorga acceso a la cuenta de servicio a los objetos relevantes de Cloud Storage.

    • Para otorgar permiso de lectura a un archivo específico, completa los siguientes pasos:

      1. Selecciona el archivo y haz clic en Editar acceso.
      2. Haz clic en Agregar principal.
      3. En el campo Principales nuevas, ingresa el nombre de la cuenta de servicio de Google SecOps.
      4. Asigna un rol que contenga el permiso de lectura a la cuenta de servicio de Google SecOps. Por ejemplo, Storage Object Viewer (roles/storage.objectViewer). Esto solo se puede hacer si no habilitaste el acceso uniforme a nivel del bucket.
      5. Haz clic en Guardar.
    • Para otorgar permiso de lectura a varios archivos, otorga acceso a nivel del bucket de la siguiente manera:

      • Para "feedSourceType": "GOOGLE_CLOUD_STORAGE":

        1. Agrega la cuenta de servicio de Google SecOps como principal a tu bucket de almacenamiento y otórgale el rol de IAM Visualizador de objetos de almacenamiento (roles/storage.objectViewer).
        2. Si configuras el feed para que borre los archivos fuente, debes agregar la cuenta de servicio de Google SecOps como principal en tu bucket y otorgarle el rol de IAM de Administrador de objetos de almacenamiento (roles/storage.objectAdmin).
      • Para "feedSourceType": "GOOGLE_CLOUD_STORAGE_V2", otorga los siguientes roles:

        1. Otorga este rol:

          • Storage Object Viewer (roles/storage.objectViewer) si la transferencia se realiza en otro bucket de Cloud Storage.
        2. Otorga uno de los siguientes roles, según lo que selecciones para la Opción de borrado de la fuente. Si seleccionas On Success, otorga el rol de Storage Legacy Bucket Writer. Si seleccionas Nunca, otorga el rol Storage Legacy Bucket Reader:

          • Storage Legacy Bucket Writer (roles/storage.legacyBucketWriter) si se requiere permiso para borrar objetos.
          • Storage Legacy Bucket Reader (roles/storage.legacyBucketReader) si no se requiere permiso para borrar objetos.
      • Para "feedSourceType": "GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN":

        1. Otorga uno de los siguientes roles:

          • Storage Object Viewer (roles/storage.objectViewer) si la transferencia se realiza en otro bucket de Cloud Storage.
          • Storage Object Creator (roles/storage.objectCreator) si la transferencia es a un sistema de archivos.
        2. Otorga uno de los siguientes roles:

          • Storage Legacy Bucket Writer (roles/storage.legacyBucketWriter) si se requiere permiso para borrar objetos.
          • Storage Legacy Bucket Reader (roles/storage.legacyBucketReader) si no se requiere permiso para borrar objetos.

Habilita el acceso a STS para Amazon S3 y Azure Storage

Los siguientes feeds de Google Cloud Storage usan el STS para transferir datos de los almacenes de blobs de Amazon S3 y Azure Storage a Google SecOps:

  • Amazon S3 (V2)
  • Amazon SQS (V2)
  • Azure Blob Storage (V2)

El STS envía solicitudes de transferencia de datos a los servicios de almacenamiento de Amazon S3 y Azure desde un conjunto de rangos de direcciones IP definidos del STS. Estos rangos de direcciones IP de STS se publican en el siguiente archivo JSON: Rangos de IP

Para usar estos tipos de fuentes de feeds de STS, es posible que debas ajustar las restricciones de acceso a la IP para permitir que STS acceda a tus servicios de almacenamiento de Amazon S3 y Azure:

  1. Extrae los rangos de IP más recientes del archivo JSON.

    Te recomendamos que leas los datos de este archivo JSON al menos una vez por semana para mantener actualizada tu configuración de seguridad. Cuando se agrega un rango nuevo al archivo, el sistema espera al menos 7 días antes de usar ese rango para las solicitudes de STS.

    Para ver un ejemplo de una secuencia de comandos de Python que recupera rangos de IP de un archivo JSON, consulta Direcciones IP para dominios predeterminados.

  2. Compara el rango de IP actual creationTime con el rango de IP creationTime que se leyó del archivo JSON anterior. Si son diferentes, actualiza las restricciones de acceso a la IP en los almacenes de blobs de Amazon S3 y Azure Storage.

    • Para Amazon S3

      Para actualizar las restricciones de acceso a IP en tu almacén de BLOB de Amazon S3, haz lo siguiente:

      Si tu proyecto de AWS usa restricciones de IP para acceder al almacenamiento, debes agregar los rangos de IP que usan los trabajadores de STS a tu lista de IPs permitidas.

      Para agregar estos rangos como IPs permitidas, usa el campo Condition en un bucket policy, como se describe en la documentación de AWS S3: Administración del acceso según direcciones IP específicas.

    • Para Azure Storage

      Para actualizar las restricciones de acceso por IP en tu almacén de blobs de Azure Storage, sigue estos pasos:

      Si restringes el acceso a tus recursos de Azure con un firewall de Azure Storage, debes agregar los rangos de IP que usan los trabajadores de STS a tu lista de IPs permitidas.

      Para agregar estos rangos como IPs permitidas, sigue estas instrucciones: Configura firewalls y redes virtuales de Azure Storage.

Configura un feed de inserción de Pub/Sub

Para configurar un feed de inserción de Pub/Sub, haz lo siguiente:

  1. Crea un feed de envío de Pub/Sub.
  2. Especifica la URL del extremo en una suscripción a Pub/Sub.

Crea un feed de inserción de Pub/Sub

  1. En el menú de Google SecOps, selecciona Configuración y, luego, haz clic en Feeds.
  2. Haz clic en Agregar nueva.
  3. En el campo Nombre del feed, ingresa un nombre para el feed.
  4. En la lista Tipo de fuente, selecciona Google Cloud Pub/Sub Push.
  5. Selecciona el Tipo de registro. Por ejemplo, para crear un feed para Open Cybersecurity Schema Framework, selecciona Open Cybersecurity Schema Framework (OCSF) como el Tipo de registro.
  6. Haz clic en Siguiente.
  7. Opcional: Especifica valores para los siguientes parámetros de entrada:
    • Delimitador de división: Es el delimitador que se usa para separar las líneas de registro. Solo puedes usar \n.
    • Espacio de nombres del recurso: Es el espacio de nombres del recurso.
    • Etiquetas de transferencia: Es la etiqueta que se aplicará a los eventos de este feed.
  8. Haz clic en Siguiente.
  9. Revisa la nueva configuración del feed en la pantalla Finalizar y, luego, haz clic en Enviar.
  10. En la pestaña Detalles, copia la URL del extremo del feed del campo Información del extremo. Necesitas esta URL del extremo para crear una suscripción de envío en Pub/Sub.
  11. Opcional: Haz clic en el botón de activación Feed habilitado para inhabilitar el feed. El feed está habilitado de forma predeterminada.
  12. Haz clic en Listo.

Especifica la URL del extremo

Después de crear un feed de envío de Pub/Sub, especifica la URL del extremo de la siguiente manera:

  1. En Pub/Sub, crea una suscripción de envío. Para obtener más información sobre cómo crear una suscripción de envío, consulta Crea suscripciones de envío.
  2. Especifica la URL del extremo, que está disponible en el feed de envío de Google Cloud Pub/Sub.
  3. Selecciona Habilitar la autenticación y, luego, elige una cuenta de servicio.
  4. Inhabilita las opciones Separación de la carga útil de envío y Separación de la carga útil de envío para la escritura de metadatos del mensaje.

Configura un feed de Amazon Data Firehose

Para configurar un feed de Amazon Data Firehose, haz lo siguiente:

  1. Crea un feed de Amazon Data Firehose y copia la URL del extremo y la clave secreta.
  2. Crea una clave de API para autenticarte en Google SecOps. También puedes reutilizar tu clave de API existente para autenticarte en Google SecOps.
  3. Especifica la URL del extremo en Amazon Data Firehose.

Crea un feed de Amazon Data Firehose

  1. En el menú de Google SecOps, selecciona Configuración y, luego, haz clic en Feeds.
  2. Haz clic en Agregar nueva.
  3. En el campo Nombre del feed, ingresa un nombre para el feed.
  4. En la lista Tipo de fuente, selecciona Amazon Data Firehose.
  5. Selecciona el Tipo de registro. Por ejemplo, para crear un feed para Open Cybersecurity Schema Framework, selecciona Open Cybersecurity Schema Framework (OCSF) como el Tipo de registro.
  6. Haz clic en Siguiente.
  7. Opcional: Especifica valores para los siguientes parámetros de entrada:
    • Delimitador de división: Es el delimitador que se usa para separar las líneas de registro. Solo puedes usar \n.
    • Espacio de nombres del recurso: Es el espacio de nombres del recurso.
    • Etiquetas de transferencia: Es la etiqueta que se aplicará a los eventos de este feed.
  8. Haz clic en Siguiente.
  9. Revisa la nueva configuración del feed en la pantalla Finalizar y, luego, haz clic en Enviar.
  10. Haz clic en Generate Secret Key para generar una clave secreta que autentique este feed.
  11. Copia y almacena la clave secreta, ya que no podrás volver a verla. Puedes volver a generar una clave secreta nueva, pero la regeneración de la clave secreta hace que la clave secreta anterior quede obsoleta.
  12. En la pestaña Detalles, copia la URL del extremo del feed del campo Información del extremo. Necesitas esta URL de extremo cuando especificas la configuración de destino para tu flujo de entrega en Amazon Data Firehose.
  13. Opcional: Haz clic en el botón de activación Feed habilitado para inhabilitar el feed. El feed está habilitado de forma predeterminada.
  14. Haz clic en Listo.

Crea una clave de API para el feed de Amazon Data Firehose

Para crear una clave de API para el feed de Amazon Data Firehose, haz lo siguiente:

  1. Ve a la página Credenciales de la consola de Google Cloud .
  2. Haz clic en Crear credenciales y selecciona Clave de API.
  3. Restringe el acceso a la API de Chronicle con la clave de API.

Especifica la URL del extremo

En Amazon Data Firehose, especifica el extremo HTTPS y la clave de acceso de la siguiente manera:

  1. Agrega la clave de API a la URL del extremo del feed y especifica esta URL como la URL del extremo HTTP con el siguiente formato:

      ENDPOINT_URL?key=API_KEY
    

    Reemplaza lo siguiente:

    • ENDPOINT_URL: Es la URL del extremo del feed.
    • API_KEY: Es la clave de API para autenticarse en Google SecOps.
  2. Para la clave de acceso, especifica la clave secreta que obtuviste cuando creaste el feed de Amazon Data Firehose.

Configura un feed de webhook HTTPS

Antes de comenzar:

  • Asegúrate de que se haya configurado un proyecto deGoogle Cloud para Google SecOps y de que la API de Chronicle esté habilitada para el proyecto.
  • Vincula una instancia de Google SecOps a los servicios de Google Cloud .

Para configurar un feed de webhook HTTPS, haz lo siguiente:

  1. Crea un feed de webhook HTTPS y copia la URL del extremo y la clave secreta.
  2. Crea una clave de API que se especifique con la URL del extremo. También puedes reutilizar tu clave de API existente para autenticarte en Google SecOps.
  3. Especifica la URL del extremo en tu aplicación.

Envía varios eventos en una sola solicitud de webhook

En el siguiente muestra de código, se muestra cómo dar formato a un solo cuerpo de solicitud con varios objetos JSON separados por saltos de línea después del elemento curl --location:

--header 'Content-Type: application/json' \
--header 'X-goog-api-key: API_KEY' \
--header 'X-Webhook-Access-Key: SECRET' \
--data '{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}
{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}'

Crea un feed de webhook HTTPS

  1. En el menú de Google SecOps, selecciona Configuración y, luego, haz clic en Feeds.
  2. Haz clic en Agregar nueva.
  3. En el campo Nombre del feed, ingresa un nombre para el feed.
  4. En la lista Tipo de fuente, selecciona Webhook.
  5. Selecciona el Tipo de registro. Por ejemplo, para crear un feed para Open Cybersecurity Schema Framework, selecciona Open Cybersecurity Schema Framework (OCSF) como el Tipo de registro.
  6. Haz clic en Siguiente.
  7. Opcional: Especifica valores para los siguientes parámetros de entrada:
    • Delimitador de división: Es el delimitador que se usa para separar las líneas de registro. Solo puedes usar \n.
    • Espacio de nombres del recurso: Es el espacio de nombres del recurso.
    • Etiquetas de transferencia: Es la etiqueta que se aplicará a los eventos de este feed.
  8. Haz clic en Siguiente.
  9. Revisa la nueva configuración del feed en la pantalla Finalizar y, luego, haz clic en Enviar.
  10. Haz clic en Generate Secret Key para generar una clave secreta que autentique este feed.
  11. Copia y almacena la clave secreta, ya que no podrás volver a verla. Puedes volver a generar una clave secreta nueva, pero la regeneración de la clave secreta hace que la clave secreta anterior quede obsoleta.
  12. En la pestaña Detalles, copia la URL del extremo del feed del campo Información del extremo. Debes especificar esta URL de extremo en tu aplicación cliente.
  13. Opcional: Haz clic en el botón de activación Feed habilitado para inhabilitar el feed. El feed está habilitado de forma predeterminada.
  14. Haz clic en Listo.

Crea una clave de API para el feed de webhook

  1. Ve a la página Credenciales de la consola de Google Cloud .
  2. Haz clic en Crear credenciales y selecciona Clave de API.
  3. Restringe el acceso a la API de Chronicle con la clave de API.

Especifica la URL del extremo

  1. En tu aplicación cliente, especifica el extremo HTTPS, que está disponible en el feed de webhook.
  2. Para habilitar la autenticación, especifica la clave de API y la clave secreta como parte del encabezado personalizado en el siguiente formato:

    X-goog-api-key = API_KEY

    X-Webhook-Access-Key = SECRET

    Te recomendamos que especifiques la clave de API como un encabezado en lugar de hacerlo en la URL. Si tu cliente de webhook no admite encabezados personalizados, puedes especificar la clave de API y la clave secreta con parámetros de consulta en el siguiente formato:

      ENDPOINT_URL?key=API_KEY&secret=SECRET
    

    Reemplaza lo siguiente:

    • ENDPOINT_URL: Es la URL del extremo del feed.
    • API_KEY: Es la clave de API para autenticarse en Google SecOps.
    • SECRET: Es la clave secreta que generaste para autenticar el feed.

Configura un feed de la API personalizada

Los feeds de la API personalizada de Google Security Operations (también conocidos como conectores sin código) te permiten transferir telemetría de APIs de REST de terceros con un modelo flexible basado en la configuración. Puedes configurar las extracciones de datos definiendo extremos, autenticación, estrategias de paginación y administración de estados directamente en la consola.

Ventajas clave

  • Acelera la integración: Incorpora nuevas fuentes de telemetría en minutos a través de un asistente guiado sin esperar actualizaciones del backend.
  • Creación de puntos de control con estado: Garantiza que no haya duplicación de datos ni registros faltantes en los ciclos de sondeo.
  • Fan-out de elementos secundarios y principales: Admite flujos de trabajo de descubrimiento de dos niveles, como la enumeración de recursos y la recuperación de su telemetría asociada.
  • Resistencia y limitación de frecuencia automatizadas: Evita la limitación de proveedores y el agotamiento de la cuota. Para una transferencia confiable y sin interrupciones, el feed de la API personalizada controla automáticamente las respuestas HTTP 429 con una retirada exponencial, regula las solicitudes con una límite de frecuencia configurable y un escalonamiento del retraso de tareas, y aplica medidas de seguridad. Para obtener más información, consulta Protecciones contra el límite de frecuencia y la regulación.

Requisitos previos

Verifica los siguientes requisitos previos antes de crear un feed de la API personalizada:

  • Permisos: Para crear o modificar feeds, debes tener el rol de administrador de la API de Chronicle (roles/chronicle.admin) o editor de la API de Chronicle (roles/chronicle.editor).
  • Requisitos de la API de terceros:
    • Una URL base de la API válida (debe usar https://)
    • Credenciales de la API (clave de API, credenciales de autenticación básica o ID y secreto de cliente de OAuth 2.0)
    • Documentación de la API del proveedor que detalla las rutas de los extremos, los parámetros de solicitud, las estructuras de respuesta JSON y los límites de frecuencia.
  • Acceso a Secret Manager: Las credenciales se encriptan y administran de forma segura en Secret Manager. La identidad del servicio que ejecuta el conector interactúa automáticamente con Secret Manager (roles/secretmanager.secretAccessor y roles/secretmanager.admin).

Configura un feed de API personalizado

Para configurar un feed de la API personalizado, haz lo siguiente:

  1. Ve a Configuración de SIEM > Feeds.
  2. Haz clic en Agregar feed nuevo.
  3. Haz clic en Configura un feed único.
  4. En el campo Nombre del feed, ingresa un nombre descriptivo único (por ejemplo, 1Password-Audit-Events).
  5. En la lista Tipo de fuente, selecciona API personalizada.
  6. En la lista Tipo de registro, selecciona el tipo de registro de Google SecOps de destino.
  7. Haz clic en Siguiente.
  8. En Configuración general, establece lo siguiente:

    • URL base: Ingresa el host principal (por ejemplo, https://events.1password.com). Debe comenzar con https://. No agregues subrutas ni barras finales.

    • Frecuencia de sondeo: Especifica con qué frecuencia la plataforma verifica la API para obtener datos de telemetría nuevos, en minutos. El intervalo admitido es de 5 a 2,880 minutos (el valor predeterminado es de 15 minutos). Para los feeds de la API estándar (secuencial), el tiempo estándar es de 10 a 15 minutos. Para los feeds de Lista y detalles (principal-secundario), se recomienda un tiempo de 30 a 60 minutos para permitir la ejecución completa de la tarea de fan-out sin superposiciones.

  9. En Autenticación, selecciona uno de los métodos de autenticación admitidos y, luego, configura los campos obligatorios:

    • Autenticación básica: Ingresa el Nombre de usuario (identidad de la cuenta de la API) y el Secreto (es decir, la contraseña o el token secretos).
    • Credenciales de cliente de OAuth 2.0: Autentícate con el flujo de otorgamiento de credenciales de cliente de OAuth 2.0. Google SecOps solicita, almacena en caché y actualiza automáticamente los tokens de acceso de portador antes de cada ciclo de transferencia. Ingresa el extremo del token de OAuth (por ejemplo, https://auth.vendor.com/oauth/token), el ID de cliente de OAuth y el secreto de cliente de OAuth.
    • Encabezados de solicitud de clave de API: Autentícate con claves de API personalizadas insertadas en los encabezados de solicitud (el patrón de REST empresarial más común). Ingresa el nombre del encabezado (por ejemplo, Authorization o X-API-Key) y el valor del encabezado (por ejemplo, Bearer <SECRET_TOKEN> o <SECRET_KEY>).
    • Parámetros de consulta de la clave de API: Autentícate con claves de API personalizadas insertadas en los parámetros de consulta de la URL. Ingresa el Nombre del parámetro de consulta (por ejemplo, api_key) y el Valor del parámetro de consulta (por ejemplo, <SECRET_KEY>).
  10. Selecciona el modelo de conector que usa tu API personalizada:

    • API estándar (secuencial): Es un flujo de sondeo lineal en el que cada sondeo se basa directamente en el estado del anterior. En este modelo, la siguiente votación usa un cursor, un token o una marca de tiempo extraídos de la votación anterior para recuperar solo los datos nuevos. Selecciona esta tarjeta cuando el proveedor proporcione un extremo que devuelva directamente registros de eventos de telemetría (por ejemplo, 1Password, Okta, SentinelOne, GitHub o Slack).
    • Lista y detalles (solicitudes superiores y secundarias): Es un flujo de descubrimiento de dos niveles. El feed realiza una llamada inicial (principal) para recuperar una lista de recursos u objetos (por ejemplo, una lista de IDs de usuarios o zonas). Luego, el feed genera automáticamente llamadas de seguimiento dependientes (secundarias) para recuperar la telemetría detallada de cada recurso individual identificado. Selecciona esta tarjeta cuando la API del proveedor requiera un patrón de descubrimiento de dos niveles: primero, llamar a un extremo para recuperar una lista dinámica de entidades (por ejemplo, zonas, cuentas, proyectos o dispositivos) y, luego, ejecutar solicitudes de detalles de seguimiento por entidad para recuperar la telemetría (por ejemplo, Cloudflare, AWS CloudWatch o Tenable).
  11. Si seleccionaste API estándar (secuencial), haz lo siguiente:

    1. En endpoint de API, configura los siguientes parámetros para definir la ruta técnica y el ritmo de la tarifa de la solicitud:
      • Ruta de acceso del endpoint: Es la ruta de acceso específica de la API que se agrega a la URL base (por ejemplo, /api/v1/auditevents). Define el recurso de telemetría exacto para consultar.
      • Método HTTP: Selecciona GET para recuperar datos con parámetros de consulta de URL o POST para enviar una carga útil de búsqueda o un cuerpo de filtro.
    2. Cuerpo de la solicitud: Para las solicitudes POST, proporciona la carga útil de datos JSON. Puedes incorporar variables dinámicas de puntos de control, como {"limit": 100, "start_time": "{{.last_timestamp}}"}.
    3. Máximo de solicitudes por minuto: Ingresa la cantidad máxima de solicitudes que se pueden enviar por minuto. Es un limitador de frecuencia del cliente para cumplir con los límites de frecuencia de la API del proveedor (predeterminado: 5 RPM = 1 solicitud cada 12 segundos). Este parámetro de configuración evita el agotamiento de la cuota durante la paginación de varias páginas.
    4. Opcional: En Encabezados personalizados, configura el Nombre del encabezado y el Valor, y, luego, haz clic en Agregar para definir los encabezados HTTP especializados que requiere la API de destino (por ejemplo, Content-Type: application/json, Accept: application/json).
    5. Opcional: En Parámetros de consulta, configura la clave y el valor, y, luego, haz clic en Agregar para especificar filtros o parámetros adicionales anexados a la cadena de consulta de la URL (por ejemplo, count=1000, status=active) o vincular variables de plantilla dinámicas (por ejemplo, start={{.last_run_time}}).
    6. En Estrategia de paginación:, selecciona el mecanismo de paginación que requiere la API de terceros para controlar los conjuntos de resultados de varias páginas y, luego, configura los campos obligatorios:
      • None: Recupera datos en una sola solicitud sin paginación.
      • Paginación con tokens: Usa tokens (claves personalizadas) para obtener la página siguiente. Ingresa la ruta de acceso JSON del token de la página siguiente (por ejemplo, meta.next_cursor) y el nombre del parámetro de búsqueda de paginación del token (por ejemplo, cursor).
      • Paginación de vínculos: Sigue las URLs proporcionadas en la respuesta para obtener más datos. Ingresa la ruta de acceso JSON del vínculo a la página siguiente (por ejemplo, links.next o @odata.nextLink).
      • Paginación por desplazamiento: Omite una cantidad establecida de registros para obtener el siguiente conjunto. Ingresa el nombre del parámetro de consulta de desplazamiento (por ejemplo, offset).
      • Paginación con números de página: Ve al siguiente número de página secuencial. Ingresa el nombre del parámetro de consulta del número de página (por ejemplo, page).
    7. En Checkpointing, configura los parámetros que permiten que el conector recuerde dónde se detuvo entre los ciclos de sondeo recurrentes:

      • Estrategia: Elige una de las siguientes estrategias y configura los campos obligatorios:
        • None: Recupera todos los datos disponibles sin hacer un seguimiento del progreso en los ciclos.
        • Marca de tiempo más reciente: Realiza un seguimiento de la marca de tiempo del registro más reciente. Ingresa la ruta de acceso JSON del valor del punto de control (por ejemplo, timestamp o event_time) y la variable del punto de control (por ejemplo, last_run_time, a la que se hace referencia en las siguientes encuestas como {{.last_run_time}}).
        • Latest Record: Realiza un seguimiento del ID de registro más alto para recuperar solo los registros nuevos. Ingresa la ruta de acceso JSON del valor del punto de control (por ejemplo, id o event_id) y la variable del punto de control (por ejemplo, last_id, a la que se hace referencia como {{.last_id}}).
        • Token de iterador: Usa tokens de continuación persistentes proporcionados por la API. Ingresa la ruta de acceso JSON del valor del punto de control y la variable del punto de control (por ejemplo, iterator_token, a la que se hace referencia como {{.iterator_token}}).
    8. En Response Mapping, proporciona reglas que le indiquen a la plataforma cómo ubicar y extraer registros:

      • Ruta de acceso JSON de los datos de destino: Ingresa la ruta de acceso exacta en la carga útil de la respuesta de la API en la que se encuentra la lista de entradas de registro de destino. Para los arrays encapsulados en objetos (por ejemplo, {"items": [...]}), ingresa items. En el caso de las APIs que devuelven directamente un array JSON raíz (por ejemplo, [{...}, {...}]), deja este campo completamente vacío ([]).
  12. Si seleccionaste Lista y detalles (solicitudes superiores y secundarias), haz lo siguiente:

    1. Solicitud principal (descubrimiento): Configura el endpoint que devuelve una lista de elementos:
      1. En endpoint de API, configura los siguientes parámetros para definir la ruta técnica y el ritmo de la tarifa de la solicitud:
        • Ruta de acceso del endpoint: Es la ruta de acceso específica de la API que se agrega a la URL base (por ejemplo, /api/v1/auditevents). Define el recurso de telemetría exacto para consultar.
        • Método HTTP: Selecciona GET para recuperar datos con parámetros de consulta de URL o POST para enviar una carga útil de búsqueda o un cuerpo de filtro.
        • Cuerpo de la solicitud: Para las solicitudes POST, proporciona la carga útil de datos JSON. Puedes incorporar variables dinámicas de puntos de control, como {"limit": 100, "start_time": "{{.last_timestamp}}"}.
      2. Máximo de solicitudes por minuto: Ingresa la cantidad máxima de solicitudes que se pueden enviar por minuto. Es un limitador de frecuencia del cliente para cumplir con los límites de frecuencia de la API del proveedor (predeterminado: 5 RPM = 1 solicitud cada 12 segundos). Este parámetro de configuración evita el agotamiento de la cuota durante la paginación de varias páginas.
      3. Opcional: En Encabezados personalizados, configura el Nombre del encabezado y el Valor, y, luego, haz clic en Agregar para definir los encabezados HTTP especializados que requiere la API de destino (por ejemplo, Content-Type: application/json, Accept: application/json).
      4. Opcional: En Parámetros de consulta, configura la clave y el valor, y, luego, haz clic en Agregar para especificar filtros o parámetros adicionales anexados a la cadena de consulta de la URL (por ejemplo, count=1000, status=active) o vincular variables de plantilla dinámicas (por ejemplo, start={{.last_run_time}}).
      5. En Estrategia de paginación:, selecciona el mecanismo de paginación que requiere la API de terceros para controlar los conjuntos de resultados de varias páginas y, luego, configura los campos obligatorios:
        • None: Recupera datos en una sola solicitud sin paginación.
        • Paginación con tokens: Usa tokens (claves personalizadas) para obtener la página siguiente. Ingresa la ruta de acceso JSON del token de la página siguiente (por ejemplo, meta.next_cursor) y el nombre del parámetro de búsqueda de paginación del token (por ejemplo, cursor).
        • Paginación de vínculos: Sigue las URLs proporcionadas en la respuesta para obtener más datos. Ingresa la ruta de acceso JSON del vínculo a la página siguiente (por ejemplo, links.next o @odata.nextLink).
        • Paginación por desplazamiento: Omite una cantidad establecida de registros para obtener el siguiente conjunto. Ingresa el nombre del parámetro de consulta de desplazamiento (por ejemplo, offset).
        • Paginación con números de página: Ve al siguiente número de página secuencial. Ingresa el nombre del parámetro de consulta del número de página (por ejemplo, page).
      6. En Checkpointing, configura los parámetros que permiten que el conector recuerde dónde se detuvo entre los ciclos de sondeo recurrentes:
        • Estrategia: Elige una de las siguientes estrategias y configura los campos obligatorios:
          • None: Recupera todos los datos disponibles sin hacer un seguimiento del progreso en los ciclos.
          • Marca de tiempo más reciente: Realiza un seguimiento de la marca de tiempo del registro más reciente. Ingresa la ruta de acceso JSON del valor del punto de control (por ejemplo, timestamp o event_time) y la variable del punto de control (por ejemplo, last_run_time, a la que se hace referencia en las siguientes encuestas como {{.last_run_time}}).
          • Latest Record: Realiza un seguimiento del ID de registro más alto para recuperar solo los registros nuevos. Ingresa la ruta de acceso JSON del valor del punto de control (por ejemplo, id o event_id) y la variable del punto de control (por ejemplo, last_id, a la que se hace referencia como {{.last_id}}).
          • Token de iterador: Usa tokens de continuación persistentes proporcionados por la API. Ingresa la ruta de acceso JSON del valor del punto de control y la variable del punto de control (por ejemplo, iterator_token, a la que se hace referencia como {{.iterator_token}}).
    2. Extracción de datos (el puente): Configura lo siguiente:
      • Ruta de acceso JSON del identificador del elemento: Es el campo específico de la respuesta principal que identifica de forma única una entidad individual (por ejemplo, id o zone_id). El conector extrae este identificador de cada elemento del array principal.
      • Nombre de la variable de plantilla: Especifica un nombre de variable personalizado para conservar el ID extraído (por ejemplo, zone_id). La IU muestra una insignia dinámica: Usa {{.zone_id}} en tu solicitud secundaria a continuación.
    3. Solicitud secundaria (detalle): Configura el endpoint que devuelve registros detallados para cada elemento:
      1. En endpoint de API, configura los siguientes parámetros para definir la ruta técnica y el ritmo de la tarifa de la solicitud:
        • Ruta de acceso del endpoint: Es la ruta de acceso específica de la API que se agrega a la URL base (por ejemplo, /client/v4/zones/{{.zone_id}}/logs/received). Define el recurso de telemetría exacto para consultar.
        • Método HTTP: Selecciona GET para recuperar datos con parámetros de consulta de URL o POST para enviar una carga útil de búsqueda o un cuerpo de filtro.
        • Cuerpo de la solicitud: Para las solicitudes POST, proporciona la carga útil de datos JSON. Puedes incorporar variables dinámicas de puntos de control, como {"limit": 100, "start_time": "{{.last_timestamp}}"}.
      2. Máximo de solicitudes por minuto: Ingresa la cantidad máxima de solicitudes que se pueden enviar por minuto. Es un limitador de frecuencia del cliente para cumplir con los límites de frecuencia de la API del proveedor (predeterminado: 5 RPM = 1 solicitud cada 12 segundos). Este parámetro de configuración evita el agotamiento de la cuota durante la paginación de varias páginas.
      3. Opcional: En Encabezados personalizados, configura el Nombre del encabezado y el Valor, y, luego, haz clic en Agregar para definir los encabezados HTTP especializados que requiere la API de destino (por ejemplo, Content-Type: application/json, Accept: application/json).
      4. Opcional: En Parámetros de consulta, configura la clave y el valor, y, luego, haz clic en Agregar para especificar filtros o parámetros adicionales anexados a la cadena de consulta de la URL (por ejemplo, count=1000, status=active) o vincular variables de plantilla dinámicas (por ejemplo, start={{.last_run_time}}).
      5. En Estrategia de paginación:, selecciona el mecanismo de paginación que requiere la API de terceros para controlar los conjuntos de resultados de varias páginas y, luego, configura los campos obligatorios:
        • None: Recupera datos en una sola solicitud sin paginación.
        • Paginación con tokens: Usa tokens (claves personalizadas) para obtener la página siguiente. Ingresa la ruta de acceso JSON del token de la página siguiente (por ejemplo, meta.next_cursor) y el nombre del parámetro de búsqueda de paginación del token (por ejemplo, cursor).
        • Paginación de vínculos: Sigue las URLs proporcionadas en la respuesta para obtener más datos. Ingresa la ruta de acceso JSON del vínculo a la página siguiente (por ejemplo, links.next o @odata.nextLink).
        • Paginación por desplazamiento: Omite una cantidad establecida de registros para obtener el siguiente conjunto. Ingresa el nombre del parámetro de consulta de desplazamiento (por ejemplo, offset).
        • Paginación con números de página: Ve al siguiente número de página secuencial. Ingresa el nombre del parámetro de consulta del número de página (por ejemplo, page).
      6. En Checkpointing, configura los parámetros que permiten que el conector recuerde dónde se detuvo entre los ciclos de sondeo recurrentes:
        • Estrategia: Elige una de las siguientes estrategias y configura los campos obligatorios:
          • None: Recupera todos los datos disponibles sin hacer un seguimiento del progreso en los ciclos.
          • Marca de tiempo más reciente: Realiza un seguimiento de la marca de tiempo del registro más reciente. Ingresa la ruta de acceso JSON del valor del punto de control (por ejemplo, timestamp o event_time) y la variable del punto de control (por ejemplo, last_run_time, a la que se hace referencia en las siguientes encuestas como {{.last_run_time}}).
  13. Establece la siguiente configuración de Programación y etiquetas:

    • Frecuencia de sondeo: Selecciona un intervalo estándar (por ejemplo, 5m, 1h).
    • Espacio de nombres: Es una etiqueta organizativa opcional.
    • Etiquetas de transferencia: Son pares clave-valor para el RBAC de datos.
  14. Haz clic en Enviar. Google SecOps realiza una verificación automatizada de validación de credenciales y extremos. Si la validación se realiza correctamente, el feed comenzará a sondear.

Ejemplo de configuración 1: Eventos de auditoría de 1Password (modelo de API estándar [secuencial])

La siguiente configuración declarativa en formato JSON muestra un modelo de API estándar (secuencial), con la creación de puntos de control basada en el cursor para 1Password:

{
  "base_url": "https://events.1password.com",
  "polling_frequency": 15,
  "header_auth": {
    "header_key_values": [
      {
        "key": "Authorization",
        "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
      }
    ]
  },
  "primary_request": {
    "request_settings": {
      "endpoint_path": "/api/v1/auditevents",
      "http_method": "POST",
      
      "request_body": "{\"limit\": 1000, \"start_time\": \"{{.last_run_time}}\"}",
      
      "custom_headers": [
        {
          "key": "Content-Type",
          "value": "application/json"
        }
      ],
      "max_requests_per_minute": 5
    },
    "pagination_strategy": {
      "token": {
        "next_page_token_json_path": "additional_items_url",
        "query_param": "cursor"
      }
    },
    "checkpointing": {
      "latest_timestamp_strategy": {
        "checkpoint_value_path": "timestamp",
        "checkpoint_variable": "last_run_time"
      }
    },
    "response_mapping": {
      "target_data_path": ["items"]
    }
  }
}

Configuración de muestra concreta 2: Telemetría de la zona de Cloudflare (modelo de lista y detalles [principal-secundario])

La siguiente configuración JSON declarativa muestra un modelo de fan-out de lista y detalles (principal-secundario) para Cloudflare:

{
 "base_url": "https://api.cloudflare.com",
 "polling_frequency": 30,
 "header_auth": {
   "header_key_values": [
     {
       "key": "Authorization",
       "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
     }
   ]
 },

 "primary_request": {
   "request_settings": {
     "endpoint_path": "/client/v4/zones",
     "http_method": "GET"
   },
   "response_mapping": {
     "target_data_path": ["result"]
   },
   "pagination_strategy": {
     "none": {}
   },
   "checkpointing": {
     "none_strategy": {}
   },
   "dependent_requests_config": {
     "item_id_json_path": "id",
     "item_id_variable": "zone_id",
     "dependent_requests": [
       {
         "request_settings": {
           "endpoint_path": "/client/v4/zones/{{.zone_id}}/logs/received",
           "http_method": "GET",
           "query_parameters": [
             {
               "key": "start",
               "value": "{{.last_run_time}}"
             },
             {
               "key": "count",
               "value": "1000"
             }
           ],
           "max_requests_per_minute": 5
         },

         "pagination_strategy": {
           "none": {}
         },
         "checkpointing": {
           "latest_timestamp_strategy": {
             "checkpoint_value_path": "EdgeStartTimestamp",
             "checkpoint_variable": "last_run_time"
           }
         },
         "response_mapping": {
           "target_data_path": []
         }
       }
     ]
   }
 }
}

Prácticas recomendadas para las APIs personalizadas

  • Orientación sobre la frecuencia de sondeo:
    • Comienza con intervalos de sondeo moderados: Establece el intervalo de sondeo inicial en 15 o 30 minutos para los extremos de alto volumen y observa el comportamiento de la cuota de la API del proveedor antes de reducirlo a 5 minutos.
    • Optimiza para la distribución a gran escala: En el caso de los feeds principal-secundario (lista y detalle) que descubren docenas o cientos de recursos, Google recomienda que establezcas la frecuencia de sondeo entre 30 y 60 minutos para permitir que todas las tareas secundarias con ritmo se completen correctamente antes de que se inicie el siguiente ciclo de descubrimiento.
  • Valida las rutas de transferencia: Usa la documentación del proveedor o las herramientas de prueba de la API para confirmar el nombre exacto del campo JSON para las marcas de tiempo antes de configurar el registro de puntos de control de estado.
  • Descompón las APIs con varios elementos secundarios: Si una API de terceros requiere recuperar alertas y registros de auditoría para una sola lista de usuarios, crea dos feeds independientes con un solo elemento secundario (uno para las alertas y otro para los registros de auditoría) para mantener un aislamiento óptimo.

Mecanismos de protección para el límite de frecuencia y la regulación

Para evitar que la configuración de los feeds de los clientes supere las cuotas de los proveedores externos o monopolice los recursos del sistema, el tipo de feed de la API personalizada implementa las siguientes medidas de protección automáticas:

  • Pacing de solicitudes configurable (límite de frecuencia): El pacing de las solicitudes HTTP salientes se realiza automáticamente para evitar superar los límites de frecuencia del proveedor. La tasa de aceleración predeterminada es de 5 solicitudes por minuto (1 solicitud cada 12 segundos). Puedes ajustar este valor por extremo con el campo Max requests per minute en la configuración del extremo para que coincida con las cuotas de API publicadas por tu proveedor.
  • Límite de solicitudes secundarias: Para los feeds de Parent-Child (List & Detail), una solicitud de descubrimiento puede enviar hasta 500 solicitudes secundarias por ciclo de sondeo.
  • Profundidad de expansión de un solo nivel: El conector aplica estrictamente una profundidad de expansión máxima de 1 nivel (descubrimiento de elementos principales → detalles de elementos secundarios). No se admiten solicitudes dependientes anidadas (llamadas secundarias).
  • Límite del tamaño de la carga útil de respuesta: El tamaño máximo permitido de la respuesta HTTP para cualquier solicitud o página es de 50 MB. Si una API sin paginación devuelve una respuesta que supera los 50 MB, la recuperación fallará con un error de recurso agotado. Para evitar esto, siempre configura los parámetros de consulta de paginación (como limit o page_size) para recuperar registros en lotes más pequeños.
  • Retraso exponencial automático de HTTP 429: Si una API de proveedor externo responde con HTTP 429 (Demasiadas solicitudes), Google SecOps captura automáticamente el estado y comienza un período de retraso exponencial, lo que pausa la ejecución de la tarea hasta que se restablece la ventana de cuota del proveedor.

Limitaciones de la API personalizada

Cuando planifiques tus rutas de transferencia, ten en cuenta que el tipo de feed de la API personalizada tiene las siguientes limitaciones:

  • Compatibilidad estricta con JSON: Solo se admiten las respuestas de la API de JSON. No se admiten otros formatos, como XML, CSV, Parquet y Avro.
  • No se admite la firma dinámica de solicitudes: No se admiten las APIs que requieren firmas criptográficas dinámicas por solicitud (por ejemplo, AWS SigV4, Akamai o Oracle OCI).
  • Sin autenticación de varios pasos: No se admiten las APIs que requieren una llamada de acceso programático inicial para intercambiar credenciales por un token de sesión temporal (como Saviynt) antes de sondear.
  • No se admiten WebSockets ni la transferencia de datos de inserción: Los feeds de la API personalizada admiten el sondeo de extracción HTTPS estándar. No se admiten las conexiones de transmisión persistentes (WebSockets) ni los webhooks entrantes.
  • Sin TLS mutuo (mTLS): La autenticación debe basarse en claves de API, autenticación básica o credenciales de cliente estándar de OAuth 2.0. No se admiten los protocolos de enlace de certificados del cliente.

Soluciona problemas de los feeds de API personalizados

Para investigar los errores de los feeds de la API personalizada en el Explorador de registros de Cloud Logging, usa las siguientes consultas:

resource.type="gce_instance" OR resource.type="generic_task"
jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"

Reemplaza FEED_ID por el ID de tu feed.

Para filtrar específicamente las solicitudes HTTP fallidas, usa la siguiente consulta:

jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"
jsonPayload.http_status_code >= 400

Reemplaza FEED_ID por el ID de tu feed.

Modos de falla comunes y soluciones

Síntoma o error Causa principal Solución o corrección
HTTP 401 Unauthorized / HTTP 403 Forbidden La clave de API, la contraseña o las credenciales de OAuth no son válidas o vencieron. Edita el feed, vuelve a ingresar credenciales válidas y haz clic en Enviar.
HTTP 404 No encontrado La URL base o la plantilla de ruta del extremo son incorrectas. Inspecciona el endpoint en la documentación de la API del proveedor. Asegúrate de que la URL base termine correctamente y de que la ruta del extremo comience con /.
HTTP 429 Too Many Requests Se superaron los límites de frecuencia de la API del proveedor. Aumenta la frecuencia de sondeo o reduce el parámetro limit en los parámetros de consulta.
Error de extracción de JSON (items_path vacío) No coincide la ruta de configuración de la respuesta. Verifica la estructura de la carga útil de la respuesta de la API y actualiza la ruta de acceso JSON de los datos de destino.
Transferencia de datos duplicados La marca de tiempo de configuración del estado o la ruta del extractor de ID no son válidas. Verifica el nombre del campo de registro para la marca de tiempo y actualiza la ruta del extractor.

Administra feeds

Después de configurar tus feeds de datos, usa las herramientas de administración para supervisar el estado de la transferencia, modificar los parámetros existentes y administrar el ciclo de vida del feed. En esta sección, se describe cómo interpretar los estados de los feeds y realizar tareas de mantenimiento esenciales para garantizar la visibilidad continua de los datos.

La página Feeds proporciona varias herramientas para ayudarte a navegar y organizar tu lista de feeds configurados:

  • Búsqueda: Usa la barra de búsqueda para encontrar un feed por su nombre, ID o tipo de fuente.

  • Filtro: Haz clic en el ícono de filtro para reducir la lista según atributos específicos del feed.

  • Descargar CSV: Haz clic en Descargar como CSV para exportar la lista actual de feeds a un archivo CSV.

  • Paginación: Usa los controles de paginación para realizar las siguientes acciones:

    • Cambia la cantidad de Filas por página.

    • Navega por varias páginas de feeds con las pestañas y las flechas de página.

  • Hora de la última actualización: Consulta la marca de tiempo para ver cuándo se actualizó la lista de feeds por última vez.

Ver los feeds configurados

En la página Feeds, se muestran todos los feeds que configuraste.

  1. Ve a Configuración de SIEM > Feeds. En la página principal, se muestran todos los feeds que configuraste.
  2. Mantén el puntero sobre cada fila para mostrar el menú Más more_vert .
  3. En el menú, puedes ver los detalles del feed, editarlo, inhabilitarlo o borrarlo.

Supervisa el estado del feed

Puedes supervisar el estado del feed en la página inicial Feeds, en la que los feeds pueden tener los siguientes estados:

  • Activo: El feed está configurado y listo para transferir datos a tu cuenta de Google SecOps.
  • InProgress: Google SecOps intenta extraer datos del tercero configurado.
  • Completado: Este feed recuperó los datos correctamente.
  • Archivado: Feed inhabilitado.
  • Fallida: El feed no puede recuperar datos correctamente. Es probable que se deba a un problema de configuración. Haz clic en la pregunta para mostrar el error de configuración. Una vez que hayas corregido el error y vuelto a enviar el feed, regresa a la página Feeds para determinar si el feed ahora funciona.

Cómo editar feeds existentes

En la página Feeds, puedes editar un feed existente de la siguiente manera:

  1. Mantén el puntero sobre un feed existente y haz clic en more_vert en la columna de la derecha.

  2. Haz clic en Editar feed. Ahora puedes modificar los parámetros de entrada del feed y volver a enviarlo a Google SecOps, que intentará usar el feed actualizado.

Habilita (reanuda) y deshabilita (pausa) los feeds

Cuando inhabilitas un feed, Google SecOps deja de transferir datos nuevos de esa fuente. Para detener la transferencia de datos de inmediato, debes borrar el feed. Las transferencias activas o limitadas existentes continuarán hasta que finalicen. Cuando vuelvas a habilitar el feed, Google SecOps podrá recuperar los datos que se omitieron mientras el feed estuvo inhabilitado. Esta capacidad se denomina "capacidad de reabastecimiento".

En la columna Estado, los feeds habilitados se etiquetan como Activo, En curso, Completado o Falló. Los campos inhabilitados se etiquetan como Archivados. Para obtener una descripción, consulta Supervisa el estado del feed.

En la página Feeds, puedes habilitar (reanudar) o inhabilitar (pausar) cualquiera de los feeds existentes:

  1. Mantén el puntero sobre un feed existente y haz clic en more_vert en la columna de la derecha.

  2. Opcional: Haz clic en el botón de activación Feed habilitado para habilitar el feed.

  3. Opcional: Haz clic en el botón de activación Inhabilitar feed para inhabilitar el feed. El feed ahora está etiquetado como Archivado.

Recuperación de datos cuando vuelves a habilitar los feeds (capacidad de reabastecimiento)

La capacidad de Google SecOps para reabastecimiento de datos depende de si tu feed se basa en la extracción (compatible) o en la inserción (no admitido).

Feeds basados en extracción

Con estos feeds, Google SecOps extrae datos de fuentes externas. Los feeds de extracción incluyen lo siguiente:

  • Buckets de almacenamiento en la nube, como Amazon S3, Google Cloud Storage y Azure Blob Storage
  • Servidores SFTP
  • APIs de terceros, como Microsoft 365, Okta y Proofpoint

    Cuando vuelves a habilitar los feeds basados en extracción, Google SecOps puede recuperar los datos que se generaron mientras el feed estaba inhabilitado.

Feeds basados en la inserción

Con estos feeds, los sistemas externos "envían" datos a Google SecOps. Los feeds de envío incluyen lo siguiente:

  • Webhooks HTTPS
  • Google Cloud Pub/Sub
  • Amazon Kinesis Data Firehose
  • Ingestas directas de agentes o APIs, como BindPlane

Google SecOps no puede iniciar automáticamente el reabastecimiento de datos desde feeds basados en la transmisión. Mientras el feed está inhabilitado y tu sistema envía datos, Google SecOps envía un error HTTP 403 Forbidden o un error genérico 4xx.

Si tu sistema no almacena los datos y no vuelve a intentar enviarlos a Google SecOps, se perderán. Además, si tu sistema está configurado para "descartar en caso de falla" o borrar su búfer, los datos se perderán de forma permanente para el período respectivo. Para evitar la pérdida de datos, debes configurar tu sistema para que almacene en búfer y vuelva a enviar los datos una vez que se vuelva a habilitar un feed. Luego, Google SecOps puede transferir los datos que faltan cuando se reanuda el feed.

Consideraciones sobre el backfill

  • Límites del sistema fuente: La cantidad de datos históricos que Google SecOps puede completar a partir de feeds basados en extracción está limitada por el tiempo que el sistema fuente conserva los datos y lo que permite su API. Por ejemplo, algunas APIs solo proporcionan acceso a los datos de los últimos siete días.
  • Google SecOps buffer: Para la recuperación automatizada, el búfer interno de Google SecOps para los feeds basados en extracción contiene datos durante un máximo de 90 días, después de los cuales se descartan.
  • Restricciones de inquilino: Es posible que los inquilinos que no pagan, como las pruebas de concepto, tengan limitaciones en el reabastecimiento de datos anteriores.
  • Cuotas de transferencia: Para evitar que se vea afectada la transferencia de datos en tiempo real, los datos de relleno se procesan con una prioridad más baja que los datos en tiempo real. El reabastecimiento de datos basado en extracción también está limitado por la tasa, por lo general, a un tercio (33%) del límite de ráfaga de tu arrendatario por tipo de registro. Esto garantiza que los feeds críticos basados en envío, como los agentes de EDR, no se vean afectados negativamente.
  • Límites de límite de frecuencia: Si el reabastecimiento consume toda la cuota de extracción disponible, se pausa la transferencia durante el resto del intervalo de cinco minutos y se reanuda automáticamente cuando se reinicia el intervalo.
  • Almacenamiento en la nube: Puedes usar la configuración del feed para controlar el reabastecimiento, como los filtros para archivos nuevos o actualizados, o los filtros de rango de fechas, como "Antigüedad máxima del archivo".
  • Grandes registros pendientes: Si un gran registro pendiente de un feed basado en extracción causa problemas cuando se vuelve a habilitar, puedes comunicarte con el equipo de Atención al Cliente de Google para borrar el registro pendiente. Esto significa que el feed comenzará a transferir solo los datos nuevos en el futuro, y los datos faltantes no se completarán.
  • Edición de feeds inhabilitados: Cualquier cambio de configuración que se realice en un feed mientras esté inhabilitado se aplicará tan pronto como se vuelva a habilitar.

Borra feeds

En la página Feeds, también puedes borrar un feed existente:

  1. Mantén el puntero sobre un feed existente y haz clic en more_vert en la columna de la derecha.

  2. Haz clic en Borrar feed. Se abrirá la ventana DELETE FEED. Para borrar el feed de forma permanente, haz clic en Sí, bórralo.

En el caso de los feeds de la API personalizada, aparece una ventana de diálogo con una casilla de verificación opcional: Borrar los datos pendientes del backlog:

  • Sin marcar (predeterminado): Se borran la configuración y las credenciales del feed, pero se permite que los datos pendientes en la cola se procesen hasta la transferencia.
  • Marcado: Se quitarán de forma permanente la configuración del feed, las credenciales y todos los datos pendientes del backlog.

Controla la tasa de transferencia

Cuando la tasa de transferencia de datos de un arrendatario alcanza un umbral determinado, Google Security Operations restringe la tasa de transferencia de los feeds de datos nuevos para evitar que una fuente con una tasa de transferencia alta afecte la tasa de transferencia de otra fuente de datos. En este caso, hay una demora, pero no se pierden datos. El umbral se determina según el volumen de transferencia y el historial de uso del arrendatario.

Para solicitar un aumento del límite de frecuencia, comunícate con Atención al cliente de Cloud.

Soluciona problemas de feeds con errores

En la página Feeds, puedes ver detalles como el tipo de fuente, el tipo de registro, el ID del feed y el estado de los feeds existentes, de la siguiente manera:

  1. Mantén el puntero sobre un feed existente y haz clic en more_vert en la columna de la derecha.

  2. Haz clic en Ver feed. Aparecerá un diálogo que muestra los detalles del feed. En el caso de un feed fallido, puedes encontrar los detalles del error en Detalles > Estado.

En el caso de un feed fallido, los detalles incluyen la causa del error y los pasos para corregirlo.

Consulta la tabla Errores de fuente y transferencia para ver los mensajes de error que puedes encontrar cuando trabajas con feeds de datos.

Para realizar un análisis detallado y solucionar problemas relacionados con la actividad del feed, puedes ver los registros en Cloud Logging. Consulta Cómo analizar la actividad del feed con Cloud Logging.

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