Saltar al contenido

Jitterbit puerta de enlace API privada

Introducción

Una puerta de enlace API privada, alojada en una red privada, maneja estas características de seguridad y tareas involucradas en aceptar y procesar llamadas a la API de API Manager:

  • Gestión del tráfico.
  • Autorización y control de acceso.
  • Limitación de tasa.
  • Procesamiento de carga útil de API.

Puedes instalar y ejecutar una puerta de enlace API privada en Linux, o ejecutar una como un contenedor Docker basado en Linux.

Una puerta de enlace API privada es una puerta de enlace local para procesar APIs directamente desde tus propios servidores. Las características de seguridad de API Manager se configuran a nivel de API o a nivel de perfil de seguridad y se almacenan en caché en la puerta de enlace API privada, que luego se referencia durante el tiempo de ejecución de la API como se describe a continuación.

Arquitectura del sistema de puerta de enlace API privada

Usar una puerta de enlace API privada proporciona estas ventajas adicionales sobre la puerta de enlace API en la nube:

  • Red interna: La puerta de enlace API privada y sus agentes pueden estar restringidos únicamente a una red interna detrás de un firewall y no ser accesibles desde Internet.

    Nota

    Si la instalación de tu puerta de enlace API privada está detrás de un firewall dentro de tu red, debes permitir los servicios necesarios de Jitterbit.

  • Seguridad de carga útil: Las cargas útiles de respuesta de API nunca pasan por los sistemas de Jitterbit.

  • Control: Tienes control sobre el hardware y el entorno de software de la puerta de enlace API privada, asegurando que cumpla con los estándares de tu empresa.
  • Nombre de dominio: La URL base del endpoint de la API puede configurarse para ser un subdominio de un nombre de dominio que controlas, en lugar de un subdominio de la región de Harmony (jitterbit.cc, jitterbit.eu o jitterbit.net). Una alternativa a usar una puerta de enlace API privada para controlar el nombre de dominio es utilizar una herramienta de terceros como Cloudflare o un proxy DNS para dirigir un nombre de dominio personalizado a la URL base.

Este diagrama muestra la arquitectura del sistema de una API personalizada desplegada en las instalaciones con un agente privado y un gateway API privado:

attachment

  1. Un consumidor de API realiza una llamada a la API ubicada en el gateway API privado.

  2. El gateway API privado hace referencia a los perfiles de seguridad en caché (si corresponde) y a los metadatos de la API para llevar a cabo tareas de autenticación y control de acceso. Si se deniega el acceso a la API, el gateway API privado devolverá una respuesta HTTP y un estado apropiados al consumidor de la API. Si se concede el acceso a la API, la solicitud de API se enruta al servicio de mensajería, que enruta solicitudes para grupos de agentes.

  3. El agente privado recibe la solicitud del servicio de mensajería.

  4. El agente privado hace referencia a la operación de API especificada durante la configuración de API personalizada y activa la operación desplegada.

  5. La operación responde con una carga útil de API consistente con el tipo de respuesta seleccionado durante la configuración de API personalizada.

  6. La carga útil de respuesta de la API se enruta desde el agente privado de vuelta al gateway API privado, que extrae la carga útil de la API y establece la respuesta HTTP final y el estado. La respuesta HTTP y el estado se envían al consumidor de la API.

    Nota

    A menos que la operación que se activa mediante la llamada a la API esté utilizando Almacenamiento Temporal, la carga útil de respuesta de la API permanecerá en el agente por un máximo de dos días. La carga útil de respuesta de la API permanecerá en el gateway API privado por no más de el tiempo de espera del gateway API de 15 segundos.

    Precaución

    En entornos de múltiples gateways detrás de un equilibrador de carga de aplicaciones (ALB) como AWS ALB, si un gateway no tiene la carga útil solicitada, se creará una solicitud proxy al gateway que sí la tenga para asegurar la recuperación de la carga útil.

El enrutamiento exitoso de cargas útiles puede requerir configuración adicional dependiendo de su entorno de múltiples gateways.

  1. La información del estado de ejecución y los registros de operaciones en curso se envían a la base de datos de registros de transacciones.

    Nota

    Los datos del consumidor no se almacenan en la base de datos de registros de transacciones a menos que se habilite el modo de depuración durante la configuración de la API personalizada.