Guía de la página de integraciones

La página de Integraciones es la única superficie exclusiva para administradores donde cada conexión saliente a sus herramientas de IT, seguridad y colaboración se configura, prueba y monitorea. No es una lista de credenciales en una base de datos - es el plano de control operacional para cómo Moftgate se comunica con el resto de su stack.

Se encuentra bajo General > Settings > Integrations y es accesible desde la navegación de General, la tarjeta de la página principal de Settings y la búsqueda global de Spotlight. Los usuarios no administradores no pueden acceder a ella.

Agrupa cuatro capacidades distintas que comparten un tema común: cómo Moftgate se comunica con sistemas externos a sí mismo.

La pestaña activa se establece mediante un parámetro de consulta, por lo que se puede marcar, compartir y sobrevive a una recarga de página.

Cerrar imagen

La pestaña de Integraciones es donde la mayoría de los operadores pasan su tiempo. Muestra cada tipo de integración soportado como una tarjeta - no como una tabla - porque las integraciones son objetos configurados, no filas de telemetría. Cada tarjeta muestra el logo del proveedor, insignias de capacidades, una descripción en lenguaje sencillo y el beneficio de usarla, para que un operador pueda elegir sin leer documentación externa.

Moftgate viene con diez tipos de integraciones nativas, cada una con sus propias credenciales, comportamiento de entrega y conjunto de capacidades. Cada tipo es un conector de primera clase, no un webhook genérico con una etiqueta diferente.

Cada llamada saliente - ya sea una entrega de evento o una sincronización de assets - se registra con el nombre del evento, URL, estado HTTP, resultado, duración y un mensaje. Esta es la pista de auditoría de la capa de integración. El modal de Eventos por integración pagina este log para que los operadores puedan solucionar entregas fallidas, y la tarjeta muestra el resultado más reciente sin abrir el modal.

Configurar una integración no es un único formulario largo. Es un asistente multi-paso que valida cada paso antes de avanzar, muestra el progreso en la parte superior y le permite volver a los pasos completados.

1. 1
   Detalles

   Logo del proveedor, descripción, beneficio y un nombre visible para la integración.

2. 2
   Configuración

   Campos específicos del tipo, como URL, clave de API, token, clave de proyecto o site.

3. 3
   Eventos

   Qué eventos de Moftgate debe recibir la integración.

4. 4
   Sincronización de assets

   Para tipos con capacidad de assets: active la sincronización y mapee grupos de endpoints a empresas y sites del proveedor.

5. 5
   Revisión

   Resumen, prueba de conexión, toggle activo y guardar.

Los webhooks son la contraparte genérica e independiente del proveedor de las integraciones nativas. Mientras una integración nativa sabe cómo comunicarse con Jira o Splunk, un webhook simplemente envía por POST un payload JSON firmado a cualquier URL que configure. Use webhooks cuando quiera entregar eventos a un sistema para el que Moftgate no tiene un conector nativo.

Cuando un webhook tiene un secret configurado, cada entrega se firma con HMAC-SHA256 sobre el cuerpo JSON, enviado en el header X-Moftgate-Signature. El receptor verifica la firma para confirmar que el payload provino de Moftgate y no fue alterado en tránsito.

Las entregas se encolan y reintentan hasta tres veces con backoff, de modo que un receptor lento o temporalmente no disponible nunca bloquea el manejo de solicitudes. También puede enviar un payload de prueba manual desde la tarjeta del webhook para verificar su endpoint.

Las claves de API permiten acceso programático a la API REST de Moftgate. Son la credencial que entrega a un script, un pipeline de CI o una herramienta de terceros que necesita leer o escribir datos de Moftgate.

• Las claves se almacenan como hashes - el token en texto plano nunca se persiste.
• El formato del token es un prefijo seguido de 64 caracteres hexadecimales (32 bytes aleatorios), mostrado solo una vez al crearse.
• La autenticación usa un header Bearer token. El panel busca la clave por su prefijo, luego verifica el hash.
• Dos capacidades: read (solo lectura) y write (lectura y escritura).
• Revocación: elimine la clave o desactívela. Ambas detienen el token inmediatamente.

El inicio de sesión único proporciona inicio de sesión con proveedor de identidad compatible con OIDC para usuarios del panel. Este es un inicio de sesión completamente funcional, no solo almacenamiento de configuración. Se soportan cuatro tipos de proveedores: Microsoft Entra ID, Google Workspace, Okta y OIDC personalizado.

El modal de SSO tiene un diseño de dos columnas: el formulario a la izquierda, una guía de configuración persistente a la derecha con URLs de callback y discovery copiables e instrucciones paso a paso. La guía permanece visible mientras completa el formulario para que el foco nunca se pierda, y en pantallas estrechas se apila debajo del formulario. Cada URL de la guía es un chip de copiar al hacer clic, por lo que nunca tiene que seleccionar texto manualmente.

Se requiere un client ID y un client secret para cada proveedor OIDC - identifican a este panel como un cliente OAuth2 en el proveedor de identidad. El client secret se almacena cifrado y nunca se expone al navegador. Al editar un proveedor sin suministrar un nuevo secret, el valor existente se conserva.

La página de inicio de sesión lista cada proveedor SSO activo como un botón de inicio de sesión. Cuando un usuario inicia sesión, el panel valida el token de identidad, coincide el usuario por correo electrónico y, o lo inicia sesión o auto-provisiona una nueva cuenta. El 2FA local se omite porque el MFA lo gestiona el proveedor de identidad. Un botón de prueba de conexión en el modal valida la configuración antes de guardar cargando el documento de discovery y las claves de firma.

El reenvío de logs SIEM se gestiona por separado de la página de Integraciones, desde la página principal de Settings mediante la tarjeta SIEM Log Forwarding. Soporta transportes UDP, TCP y HTTPS y formatos CEF, LEEF, RFC 5424 y JSON, por lo que puede transmitir logs a cualquier SIEM que prefiera una entrada de estilo syslog sobre una API HTTP.

Esto complementa la integración nativa de Splunk en la pestaña de Integraciones: use la integración de Splunk para el reenvío al HTTP Event Collector, y use el reenvío SIEM para transmitir syslog a Splunk, QRadar o cualquier otro colector.

• Solo saliente: toda integración, webhook y sincronización de assets es saliente. El panel inicia todas las solicitudes - sin regla de firewall entrante, sin URL de callback pública, sin listener expuesto.
• Secrets cifrados: las claves de API, client secrets, tokens HEC y private keys se almacenan cifrados o con hash en reposo. El token de API en texto plano se muestra una vez al crearse y nunca se expone al navegador en formularios de edición.
• Credenciales por integración: cada integración tiene sus propias credenciales. Una URL de webhook de Slack comprometida no expone su token de API de Jira - mínimo privilegio aplicado en el límite de la integración.
• Registro de auditoría: cada acción de administrador en la página de Integraciones se registra con parámetros nombrados, y el propio log de auditoría es una fuente de eventos para webhooks.
• Escrituras transaccionales: las operaciones críticas - crear una integración con mapeos de grupos, crear una clave de API, almacenar un proveedor SSO - se envuelven en transacciones de base de datos para que un fallo parcial nunca deje el sistema inconsistente.