Seguridad lógica y arquitectura de Jitterbit Harmony

Introducción

La seguridad lógica consiste en todas las medidas de seguridad implementadas dentro de la plataforma Harmony. Esta sección describe lo siguiente:

• Arquitectura del sistema
• Procesos de desarrollo
• Autenticación, permisos y acceso
• Almacenamiento de datos
• Servicios de IA
• Topologías de seguridad de iPaaS

Arquitectura del sistema

Harmony es una plataforma unificada de bajo código que ofrece iPaaS para sistemas de integración, administración de API para exponer esas integraciones como APIs, desarrollo de aplicaciones de bajo código para crear aplicaciones web y móviles, y procesamiento EDI para transacciones entre empresas.

Los componentes principales de Harmony están integrados con capacidades de IA, incluidos asistentes impulsados por IA para la construcción de aplicaciones y conectores.

Las siguientes secciones describen la arquitectura y la seguridad de cada componente principal: Diseñadores de bajo código, Activos reutilizables, Microservicios y Motores de plataforma.

Diseñadores de bajo código

Los diseñadores de bajo código de Jitterbit son las aplicaciones Jitterbit de front-end que permiten a los usuarios crear y administrar proyectos de integración, APIs, aplicaciones web personalizadas y aplicaciones móviles nativas, y procesos EDI.

La comunicación entre las aplicaciones Jitterbit y la plataforma Harmony se realiza a través de microservicios de Jitterbit. Todos los usuarios deben autenticarse con Harmony y toda la comunicación se transmite de forma segura a través de HTTPS.

El acceso de los usuarios a las aplicaciones Jitterbit se controla además mediante una combinación de permisos de rol de organización y niveles de acceso al entorno, tal como se describe en Autenticación, permisos y acceso.

Diseñadores de integración

Se puede utilizar Studio (recomendado) o Design Studio para crear, configurar, implementar y probar proyectos de integración iPaaS de Jitterbit:

• Studio es una aplicación web del portal de Harmony.
• Design Studio es una aplicación de escritorio que debe instalarse en una estación de trabajo Windows o macOS con acceso a Internet.

La comunicación a través de servidores proxy corporativos es totalmente compatible, así como la lista de permiso de IP (lista blanca) para garantizar el cumplimiento de la VPN corporativa si es necesario.

Ambas aplicaciones utilizan la plataforma Harmony y aprovechan las características de seguridad de Harmony, incluido el inicio de sesión único, los roles de usuario y los permisos de organización, y los niveles de acceso del entorno.

El rol de un usuario de Harmony debe tener un acceso mínimo de Lectura en un entorno para acceder a proyectos en Studio o Design Studio. Los niveles superiores de acceso del entorno otorgan privilegios adicionales (consulta Autenticación, permisos y acceso).

API Manager

API Manager es una aplicación web del portal de Harmony donde los usuarios pueden crear, controlar y consumir APIs personalizadas, APIs OData y APIs proxy.

Jitterbit ofrece una variedad de opciones para proteger APIs:

• Los perfiles de seguridad permiten que una API publicada sea consumida únicamente por un consumidor de API específico o un grupo de consumidores. Se define el método de autenticación en el perfil de seguridad, eligiendo entre autenticación anónima, básica, OAuth 2.0 o clave de API.

• El modo Solo SSL restringe el tráfico HTTP a comunicaciones cifradas. Symantec Class 3 Secure Server SHA256 SSL CA verifica la identidad de la URL HTTPS. La conexión a la URL HTTPS se cifra con criptografía moderna (con cifrado TLS 1.2, la conexión se cifra y autentica mediante AES_128_GCM y utiliza ECDHE_RSA como mecanismo de intercambio de claves).

• Los registros de API documentan el perfil de seguridad utilizado para acceder a la API en cada solicitud.

El rol de un usuario de Harmony debe contar con permiso de organización de Admin, o debe tener una combinación de permiso de organización de Read con un acceso mínimo de Read en un entorno para acceder a API Manager.

El Portal de API de APIs individuales o grupos de API también puede ser accedido por usuarios externos invitados por un administrador de la organización Harmony.

App Builder

App Builder es un constructor visual de aplicaciones de bajo código para crear aplicaciones web y móviles de nivel empresarial.

El acceso a una instancia de App Builder configurada se proporciona a través del portal de Harmony. Se requiere que el rol de usuario Harmony cuente con permiso de organización de Admin para configurar el acceso de usuarios con rol de usuario Harmony de al menos permiso de Read.

Dentro de App Builder, se soportan las siguientes opciones de seguridad adicionales:

• HTTPS: Cuando HTTPS está habilitado, las cookies se establecen con la bandera Secure. Esto evita que el navegador transmita la cookie a través de un canal no seguro (HTTP). Las cookies se establecen con la bandera HttpOnly de forma predeterminada. La bandera HttpOnly mitiga los ataques de secuencias de comandos entre sitios (XSS).

• Inicio de sesión único (SSO): La autenticación puede delegarse a un proveedor SSO. App Builder soporta diversos estándares de la industria, incluyendo SSO SAML y WS-Federation. Estos utilizan la especificación de firma digital PKCS #1 con resúmenes SHA-256.

• Autenticación basada en notificaciones: Los proveedores de autenticación de usuarios pasan notificaciones a App Builder. Los administradores de seguridad asignan las notificaciones a atributos de usuario, incluyendo la pertenencia a grupos.

• Autenticación local: La autenticación local se puede utilizar para autenticarse con una contraseña almacenada en App Builder mediante la función de derivación de clave PBKDF2 con el algoritmo hash SHA-256, una longitud de clave de 16 bytes, una longitud de sal de 16 bytes e iteraciones de 10,000. Las características de seguridad incluyen políticas de contraseña, expiración de contraseña, bloqueo de cuenta y restablecimiento de contraseña.

• Sesiones: Las políticas de almacenamiento de sesión se pueden configurar. De forma predeterminada, App Builder persiste la información de sesión en la base de datos. Los administradores pueden ver sesiones y cerrar sesiones de usuario de forma forzada. El seguimiento de sesiones protege contra determinadas vulnerabilidades, como ataques de reproducción de cookies.

• Seguridad basada en roles: El acceso a los datos se puede controlar con la pertenencia a grupos del usuario, que determina los roles del usuario, que determinan los permisos para acceder a los datos empresariales. Los reinos permiten a los administradores delegar tareas administrativas como provisión de usuarios y pertenencia a grupos.

EDI

EDI es una aplicación web del portal de Harmony para administrar socios comerciales EDI y las transacciones realizadas con ellos.

La aplicación EDI procesa datos EDI en la nube de Harmony. (Jitterbit proporciona una oferta separada para el procesamiento local de datos EDI.)

La información de identificación personal (PII) se enmascara de forma predeterminada. Un administrador de Harmony puede exponer los datos de PII en la aplicación EDI durante un máximo de 24 horas, después de las cuales volverá a enmascararse.

La app de EDI también proporciona la opción de administrar la información de identificación personal (PII) de un socio comercial al eliminarla de los documentos del socio.

Un rol de usuario de Harmony con permiso de organización Admin proporciona acceso para editar y realizar todas las acciones en la app de EDI.

Los roles específicos de EDI EDI Viewer o EDI User proporcionan acceso más granular a las páginas y funciones de EDI.

Marketplace

Marketplace es una aplicación web del portal de Harmony que proporciona acceso a más de 400 recetas de integración y plantillas de procesos que se pueden importar en un ambiente para usarlas como base en proyectos de integración de Studio.

Un rol de usuario de Harmony con permiso de organización Read o Admin proporciona acceso a las recetas y plantillas en Marketplace. Iniciar una receta o plantilla en un ambiente requiere acceso Write en ese ambiente.

Management Console

Management Console es una aplicación web del portal de Harmony para administrar y monitorear tu organización de Harmony en el portal de Harmony, así como los componentes de la plataforma Harmony misma.

La administración de la organización incluye la configuración de políticas de organización, incluyendo inicio de sesión único (SSO), y la definición de quién puede acceder a diferentes áreas de las aplicaciones de Jitterbit (consulta Autenticación, permisos y acceso).

Management Console facilita una variedad de otras tareas de administración típicas de un administrador de Harmony:

• Configurar ambientes, agentes y grupos de agentes para usar con proyectos de integración de Studio o Design Studio.
• Administrar horarios, variables, receptores y copias de seguridad para proyectos de integración.
• Administrar el acceso de usuarios externos al Portal de API.
• Configurar tokens de acceso para conectar la app de EDI a Studio.
• Agregar colas de mensajes para usarse con Studio.

Management Console también proporciona información para monitorear la organización:

• Información de registro de auditoría sobre quién realizó qué actividad en la organización.
• Registros de operaciones e historial de implementación para proyectos de integración de Studio y Design Studio.

Un rol de usuario de Harmony con permiso de organización Read tiene acceso a la página Dashboard, mientras que el permiso de organización Admin tiene acceso y la capacidad de hacer ediciones y realizar acciones en todas las páginas de Management Console.

Un rol de usuario con permiso de organización Read puede acceder a páginas adicionales de Management Console cuando se le otorgan niveles de acceso al ambiente como se describe en Autenticación, permisos y acceso. El modelo de capa de control de acceso definido para cada ambiente es granular, de modo que las configuraciones que ven los usuarios y con las que pueden interactuar dependen de los controles de acceso del usuario. Los controles de acceso se aplican a todas las funciones, incluida la búsqueda de operaciones, la ejecución de operaciones, la visualización de registros, etc.

Un rol de usuario con permiso User Manager puede agregar, editar o eliminar usuarios y roles que no sean administradores, pero no puede cambiar un usuario de no administrador a administrador. También pueden administrar usuarios externos. Los usuarios con solo el permiso User Manager ven solo la página User Management en la navegación de Management Console, y los roles con solo este permiso tienen acceso de rol de ambiente deshabilitado.

Activos reutilizables

Los activos reutilizables incluyen conectores, aplicaciones y proyectos de integración, así como las herramientas para construirlos:

• Connector SDK: El Jitterbit Connector SDK (kit de desarrollo de software) proporciona los medios para que los desarrolladores creen conectores y los pongan a disposición en Studio.
• Connector Builder: Jitterbit Connector Builder es un asistente de bajo código para que cualquiera cree un conector de Studio que exponga una API REST accesible a través de HTTP.
• Conectores preintegrados: Jitterbit y sus socios proporcionan cientos de conectores de Studio preintegrados para usar en proyectos de integración.
• Aplicaciones preintegradas: Jitterbit ofrece aplicaciones web y móviles nativas preintegradas a través de App Builder.
• Plantillas: Soluciones de integración bidireccionales preintegradas que resuelven un caso de uso complejo se proporcionan a través de Marketplace.
• Recetas: Proyectos de integración unidireccionales que resuelven un caso de uso simple se proporcionan a través de Marketplace.
• Agentes de IA: Agentes preintegrados que se pueden usar para lograr tus objetivos de forma autónoma sin supervisión humana directa se proporcionan a través de Marketplace.

Microservicios

Las aplicaciones de Jitterbit se comunican con la plataforma Harmony a través de un conjunto bien definido de API de la plataforma Harmony, conocidas como microservicios de Jitterbit.

Las API se crean utilizando el mismo rigor de codificación segura que Harmony mismo (consulta Procesos de desarrollo).

Todos los usuarios de estas API deben autenticarse con Harmony y toda la comunicación se transmite de forma segura a través de HTTPS.

Motores de plataforma

La plataforma Harmony proporciona toda la infraestructura y los servicios para implementar, administrar y ejecutar proyectos de integración; crear aplicaciones web personalizadas y aplicaciones móviles nativas; crear, controlar y consumir API; y procesar transacciones EDI.

Puertas de enlace de API

Una puerta de enlace de API es un servicio que aplica las políticas y perfiles de seguridad creados en las API mediante la aplicación web API Manager. La conectividad a las API publicadas a través de API Manager se habilita a través de la puerta de enlace de API en la nube de Jitterbit o una puerta de enlace de API privada.

Las puertas de enlace de API manejan estas tareas de seguridad relacionadas con aceptar y procesar llamadas realizadas a una API:

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

Las características de seguridad se configuran en el nivel de API o en el nivel de perfil de seguridad y se almacenan en caché en la puerta de enlace de API, que se consultan durante la ejecución de la API.

Jitterbit administra, mantiene y aloja la puerta de enlace de API en la nube de Jitterbit, y no requiere configuración alguna.

Una puerta de enlace de API privada es una puerta de enlace local para procesar API directamente desde tus propios servidores. Una puerta de enlace de API privada se puede restringir únicamente a una red interna detrás de un cortafuegos y no ser accesible desde Internet, aunque ciertos servicios de Jitterbit deben estar en la lista de permitidos (en la lista blanca). Con una puerta de enlace de API privada, las cargas útiles de respuesta de la API nunca pasan a través de los sistemas de Jitterbit.

Mensajería

La comunicación entre varios componentes de Jitterbit iPaaS, como Studio, agentes y la plataforma Harmony, se logra utilizando un conjunto de servicios de mensajería en tiempo de ejecución seguros basados en la API de Servicios de Mensajería de Java (JMS) incluida en la Plataforma Java. Estas API son internas de Harmony, y los clientes no tienen acceso alguno a estas API.

Los agentes incluyen oyentes del servicio de mensajería JMS. Todos los agentes que escuchan solicitudes se autentican fuertemente y reciben una sesión autorizada en la red de mensajería de Harmony. Solo pueden escuchar solicitudes para sus grupos de agentes particulares o las que se les hagan directamente a través de Harmony. Los mensajes nunca se envían a los agentes; estos siempre los recogen a través de HTTPS. Esto permite que los agentes se ejecuten detrás de cortafuegos corporativos y permanezcan protegidos sin necesidad de abrir puertos que permitan tráfico entrante desde Internet.

Agentes

Los procesos de integración diseñados en proyectos de Studio y Design Studio se ejecutan en agentes, utilizando un grupo de agentes en la nube de Jitterbit o agentes privados y un grupo de agentes privado.

Estos procesos se pueden ejecutar completamente en la nube sin necesidad de adquirir o administrar software ni la infraestructura requerida para operarlo. Quienes opten por implementar agentes locales o en modo híbrido tienen la flexibilidad de ejecutar sus procesos de integración implementando agentes privados detrás del cortafuegos, obteniendo así mayor control sobre dónde fluyen sus datos.

Jitterbit reconoce que los clientes necesitan que sus procesos de integración se comuniquen con aplicaciones que funcionan detrás de cortafuegos corporativos por diversas razones de seguridad y cumplimiento normativo.

La arquitectura del sistema de Harmony se adapta a ambos escenarios: los procesos de integración pueden ejecutarse completamente en la nube o pueden ejecutarse detrás de cortafuegos corporativos para garantizar que los datos empresariales no se expongan a la nube. Los usuarios también pueden emplenar modelos híbridos donde algunas integraciones se ejecutan en la nube, como desarrollo, y otras, por ejemplo en producción, pueden ejecutarse detrás de cortafuegos corporativos.

Aunque el sistema simplifica el aprovisionamiento, la implementación y la administración de proyectos de integración, también ofrece a los usuarios la flexibilidad de ejecutar sus operaciones de integración utilizando grupos de agentes privados independientes. Se trata de subsistemas autónomos que se pueden instalar detrás de cortafuegos corporativos o en nubes privadas dedicadas.

La separación de los diseños de integración, que se almacenan en Harmony, de la ejecución de integración que ocurre en grupos de agentes, permite a los clientes controlar el acceso y el flujo de datos empresariales confidenciales.

Grupo de agentes en la nube

Los agentes en la nube son servicios, conocidos como backend as a service (BaaS), diseñados para procesar y satisfacer las necesidades de los clientes de forma ad-hoc. Realizan todo su trabajo de manera orientada a eventos, eliminando así la necesidad de configuración, instalación o administración tradicionales de sistemas de servidor "siempre activos" que se encuentran detrás de las aplicaciones.

Jitterbit ofrece a sus clientes la opción de ejecutar todas sus integraciones en la nube al proporcionar un grupo de agentes escalable, tolerante a fallos y en clúster, totalmente mantenido y administrado por Jitterbit.

Para mejorar la seguridad y proteger la privacidad, los agentes en la nube de Jitterbit están codificados para garantizar que los datos procesados localmente no sean persistentes; se utilizan durante el tiempo mínimo necesario para completar el proceso previsto y luego se eliminan.

Cuando el grupo de agentes en la nube de Jitterbit realiza una integración, se conecta directamente con la aplicación que requiere integración de datos. Luego lee y publica datos en estas aplicaciones.

Los metadatos persistentes en el grupo de agentes en la nube de Jitterbit se almacenan en buckets de Amazon S3 cifrados, a los que solo puede acceder el grupo de agentes.

Para clientes que necesitan que las aplicaciones residan dentro de su cortafuegos, o para usuarios que realizan integraciones bajo normativas de cumplimiento estricto que prohíben que los datos viajen fuera de un límite geográfico determinado o residan en la nube, Jitterbit recomienda utilizar un grupo de agentes privados.

Agentes privados y grupo de agentes privados

Jitterbit ofrece la flexibilidad para que los clientes aprovisionen y administren sus propios grupos de agentes y agentes privados dentro de su cortafuegos corporativo o nubes privadas virtuales. Esto permite a los clientes elegir dónde opera su entorno de ejecución de integración y les permite controlar qué red utiliza y dónde residen sus datos empresariales. Al utilizar grupos de agentes privados para integraciones, las empresas pueden garantizar que sus datos empresariales confidenciales nunca fluyan a través de la plataforma Harmony.

Los agentes que pertenecen a grupos de agentes privados se autentican y comunican con Jitterbit Harmony a través de HTTPS. Los grupos de agentes privados implementados detrás de cortafuegos corporativos se pueden configurar para comunicarse a través de un servidor proxy corporativo. Si su organización no restringe las conexiones salientes, no hay requisitos de red adicionales, como abrir puertos en cortafuegos corporativos. Cuando se restringen las conexiones salientes, debe permitir (lista blanca) ciertos servicios de Jitterbit.

El código del agente privado se crea con el mismo rigor de codificación que el código de Harmony (consulte Procesos de desarrollo).

Aunque los grupos de agentes privados satisfacen requisitos de seguridad rigurosos, el usuario o cliente es responsable de instalar y administrar sus agentes privados. En el grupo de agentes en la nube, Jitterbit proporciona enrutamiento inteligente listo para usar, alta disponibilidad y escalabilidad equivalentes a lo que se espera de una tecnología sin servidor. Sin embargo, en grupos de agentes privados, la seguridad y escalabilidad de los agentes privados es responsabilidad del cliente (aunque la plataforma Harmony sigue garantizando la alta disponibilidad siempre que se utilice más de un agente dentro de un grupo de agentes privados). Jitterbit proporciona asesoramiento sobre prácticas recomendadas para alojar código de agentes privados en Requisitos del sistema para agentes privados.

Servicio de escucha

El Servicio de escucha es un servicio de aplicación que se ejecuta en un agente privado y se consume mediante ciertos conectores de Studio que tienen capacidades de escucha. El servicio de escucha proporciona capacidades de manejo de eventos asincrónico para operaciones implementadas en el agente.

1. Se implementa una operación que contiene un conector configurado con una actividad de escucha de eventos y se habilita para escucha.
2. El servicio de escucha dentro del agente iniciará un escuchador para esa operación.
3. El escuchador comenzará a escuchar activamente cualquier notificación de evento del endpoint.
4. Cuando ocurre un evento en el endpoint, publica una notificación de evento que pueden recibir sus suscriptores.
5. El escuchador capta el mensaje de notificación de evento.
6. Si hay un agente en el grupo de agentes, el escuchador retransmite el mensaje de evento a la operación. Si el grupo de agentes contiene el número mínimo para permitir capacidades completas del servicio de escucha, el mensaje de evento se pasa al agente con la menor carga de trabajo.
7. Al recibir la notificación de evento, la operación desencadenará una operación descendente.

Registros de transacciones

Los registros de transacciones, también denominados registros de operación, son los registros generados cuando se ejecuta una operación de Studio o Design Studio. Contienen información sobre la operación, incluida su ubicación, período y estado.

El registro en la nube determina si se guardan temporalmente los datos de registro y se accede a ellos desde la nube de Harmony. Cuando el registro en la nube está habilitado, los registros de operaciones también incluyen mensajes de registro detallados. El registro en la nube siempre está habilitado para grupos de agentes en la nube de Jitterbit y se puede deshabilitar opcionalmente para agentes privados.

Los registros de operación, incluidos los mensajes de registro detallados de agentes en la nube y agentes privados, así como los datos de entrada y salida del componente dentro de los registros de operación, se retienen durante 30 días.

Repositorio de diseño

Jitterbit almacena todos los proyectos implementados en Harmony en un repositorio de diseño multiinquilino. Este repositorio de proyectos se basa en una arquitectura de base de datos multiinquilino, que proporciona particionamiento lógico de proyectos por organización y, en la mayoría de los casos, por ambiente. Específicamente, Harmony aísla y asegura los proyectos de los clientes usando lo siguiente:

• Arquitectura de base de datos segura: Incluye arquitectura de base de datos separada y arquitectura de esquema separado.
• Conexiones o tablas seguras: Utiliza conexiones de base de datos de confianza.
• Cifrado: Oscurece datos críticos de modo que permanezcan inaccesibles para partes no autorizadas incluso si llegan a poseerlos.
• Filtrado: Utiliza una capa intermediaria entre un inquilino y una fuente de datos que actúa como un colador, haciendo que al inquilino le parezca que sus datos son los únicos datos en la base de datos.
• Listas de control de acceso: Determina quién puede acceder a los datos en la aplicación y qué puede hacer con ellos.

Los proyectos típicamente contienen credenciales como nombre de usuario y contraseña utilizados para conectarse a varios endpoints. Esta información se cifra dentro del repositorio multiinquilino.

El repositorio se replica en dos regiones (como Este y Oeste) para cada región de Harmony (NA, EMEA y APAC).

Los clientes no tienen acceso directo a este repositorio. Los diversos componentes de Jitterbit iPaaS, como diseñadores de integración y agentes en la nube, utilizan APIs para acceder al repositorio. Una vez que se autentica y se valida el control de acceso, toda comunicación con el repositorio se realiza a través de varias capas de API. Además de controlar el acceso de API perimetral por HTTPS y sesiones del lado del servidor, las APIs deben validar el control de acceso del usuario a través de listas de Control de Acceso Basado en Rol (RBAC) y basadas en ambiente. Estas listas garantizan que los usuarios puedan ver, actuar y cambiar el sistema solo en función de los permisos otorgados por un administrador de la organización (usuario con permiso de Admin). Además, la granularidad de la pista de auditoría se puede configurar por cliente.

La base de datos de actividad rotativa de Harmony almacena información de estado en tiempo de ejecución así como registros de operaciones en ejecución de todos los usuarios de Harmony.

La base de datos de actividad se basa en una arquitectura multiinquilino, y aunque los datos de actividad de todos los usuarios residen en la misma base de datos, hay segmentación lógica por organización y ambiente aplicada a través de una capa de control de acceso de software y claves de cifrado únicas para garantizar que los usuarios solo puedan ver las actividades a las que tienen acceso.

La base de datos de actividad se replica en regiones de AWS y zonas de disponibilidad para garantizar alta disponibilidad y cuenta con respaldo en caso de que sea necesario restaurarla.

El acceso a la base de datos de actividad se proporciona mediante un conjunto de API. El registro de actividad utiliza una infraestructura similar de API y lista de control de acceso (ACL) que la del repositorio de proyectos.

Servicios de archivo

Harmony incluye un conjunto de servicios de archivo utilizados para almacenar archivos, como esquemas y personalizaciones. Todos los archivos se almacenan en el servicio AWS S3 y solo se puede acceder a ellos a través de la plataforma Harmony; no se puede acceder directamente.

Repositorio de esquemas

Para permitir integraciones desde una variedad de extremos, Harmony almacena varios tipos de esquemas, como WSDL, XSD, JTR y DTD.

Además del almacenamiento en el almacén de datos en la nube de Harmony, los esquemas de Studio se almacenan en el repositorio de diseño para gestionar la reutilización de esquemas dentro de un proyecto.

Repositorio de personalizaciones

Para permitir integraciones desde una variedad de extremos de base de datos, Harmony almacena varios controladores JDBC y ODBC, incluidos los que los clientes instalan en agentes privados por sí mismos.

Para ampliar las capacidades de Studio, puedes crear tus propios conectores personalizados utilizando Connector Builder o el SDK de conector.

Servicios de backend

Los servicios de backend son los servicios API subyacentes de Harmony a través de los cuales fluyen todos los datos.

Los servicios de backend manejan tareas como iniciar sesión, gestión de usuarios, implementación, programación, gestión de organización, etc.

Tiempo de ejecución del generador de aplicaciones

Las soluciones de App Builder pueden ejecutarse en las siguientes configuraciones de implementación:

• Local: El entorno de App Builder se implementa localmente en el sitio del cliente. Los servidores web y de base de datos, así como el entorno de App Builder, residen en hardware del cliente dentro de la red del cliente. Esta opción proporciona control total y flexibilidad sobre el entorno e infraestructura de App Builder. El cliente gestiona todo el mantenimiento, la seguridad, el hardware y las operaciones de software.

• Nube privada: El entorno de App Builder se implementa en un proveedor de nube privada del cliente, ya sea AWS, Google Cloud Platform (GCP) o Microsoft Azure. Los servidores web y de base de datos, así como el entorno de App Builder, residen en la nube privada. Esta opción proporciona flexibilidad y control sobre el entorno e infraestructura de App Builder. El cliente gestiona todo el mantenimiento, la seguridad, el hardware y las operaciones de software.

Motor de tiempo de ejecución B2B

Las transacciones EDI se procesan a través del tiempo de ejecución en la nube de EDI, también conocido como eiCloud.

Una vez que se genera una transacción, se almacena en la base de datos de transacciones mientras espera procesamiento. El documento EDI persiste hasta que se archiva utilizando la configuración de archivo establecida para el socio comercial. El estado de un documento EDI se puede verificar en cualquier momento a través de la página EDI Transacciones.

Se admiten protocolos de comunicación EDI estándar, como FTP/SFTP, HTTP/HTTPS, AS2, tuberías personalizadas, etc.

Se admiten formatos EDI estándar, incluidos ANSI X12 (incluido VICS), EDIFACT y sus subconjuntos, y Tradacoms. Las transacciones se procesan utilizando EDIXml, el formato de intercambio recomendado para nuevos flujos de trabajo, o utilizando el formato XCBL heredado.

Sistema de mensajería

El servicio Message Queue (MQ) es un servicio de cola de mensajería multiinquilino basado en la nube para crear y gestionar colas y mensajes. Te permite crear integraciones desacopladas de los extremos que estás integrando. El servicio MQ se utiliza con el conector Jitterbit MQ de Studio.

1. Los datos se recuperan de un extremo de origen, por ejemplo, utilizando un conector de Studio. Los datos recuperados se pueden transformar en un mensaje para ser consumido por el conector Jitterbit MQ.

2. Mediante la actividad Jitterbit MQ Send o Send Bulk, se envían los datos al servicio Jitterbit Message Queue (que envía los mensajes a la cola de mensajes especificada).

3. Posteriormente, se pueden recuperar mensajes de una cola de mensajes mediante una actividad Jitterbit MQ Get o Get Bulk.

4. Los datos recuperados de un mensaje se pueden utilizar como entrada para ser consumidos por un punto de conexión de destino, como por ejemplo mediante un conector de Studio.

5. Una vez que se consumen los datos, el mensaje se puede confirmar (mediante la actividad Acknowledge) o rechazar negativamente (mediante la actividad NACK). Si el mensaje no se confirma ni se rechaza antes del vencimiento de 30 minutos, estará disponible para ser recuperado de la cola nuevamente mediante una actividad Get o Get Bulk.

Motores de análisis y registro

La plataforma Harmony proporciona información de análisis y registro que se puede consultar a través del portal de Harmony o directamente en servidores de agentes privados.

Procesos de desarrollo

Jitterbit desarrolla y mejora sus aplicaciones utilizando prácticas sólidas de ciclo de vida del desarrollo de software (SDLC), tales como:

• Identificar vulnerabilidades de fuentes externas para impulsar cambios y mejoras en el código.
• Aplicar parches de hardware y software. Nuestro entorno virtual nos permite aplicar cambios de código y parches de hardware sin tiempo de inactividad.
• Proporcionar capacidades seguras de autenticación y registro.
• Eliminar cuentas de desarrollo, identificadores y contraseñas de entornos de producción.
• Adherirse a prácticas estrictas de gestión de cambios para actualizaciones de código así como parches.
• Separar entornos de prueba y desarrollo de la producción.
• Mantener separación de funciones entre el personal de desarrollo y soporte.
• Asegurar que la información de identificación personal (PII) no se utilice en entornos de prueba.
• Eliminar identificadores de prueba y desarrollo antes de migrar código a producción.
• Realizar revisiones de código periódicas.
• Documentar cambios en el código.
• Requerir revisión y aprobación de desarrolladores senior para todos los cambios de código.
• Completar pruebas de funcionalidad y regresión antes del lanzamiento a producción.
• Mantener procedimientos de reversión para preservar alta disponibilidad e integridad.
• Seguir prácticas de codificación segura según una política SDLC y abordar las necesidades de capacitación en seguridad del equipo de desarrollo.
• Verificar defectos de seguridad según lo prescribe el Proyecto de Seguridad de Aplicaciones Web Abierto (OWASP), como defectos de inyección, desbordamientos de búfer, errores criptográficos, manejo de errores, etc.
• Evaluar vulnerabilidades en cada lanzamiento.
• Realizar pruebas de penetración anuales.

Autenticación, permisos y acceso

Antes de que un usuario pueda iniciar su trabajo, debe autenticarse en Harmony usando su cuenta de usuario. Esa cuenta tiene permisos basados en roles en la organización de Harmony. Se pueden asignar varios niveles de acceso a esos roles en entornos individuales.

Registro y autenticación

Para acceder y usar la plataforma Harmony, un usuario debe registrarse y autenticarse usando su cuenta de usuario.

La solidez, complejidad y atributos de la contraseña, como la autenticación de dos factores, son personalizables para que los clientes puedan cumplir con los requisitos de su política de seguridad. Los administradores también pueden restringir el acceso a dominios de miembros especificados o requerir que las direcciones IP del usuario estén dentro de un rango especificado. Estos parámetros se configuran en las políticas de la organización. Si un usuario es miembro de varias organizaciones, las políticas más estrictas de cualquier organización de la que sea miembro entran en vigor para su inicio de sesión.

Después de 5 intentos fallidos de inicio de sesión usando credenciales de cuenta de Harmony, las cuentas se bloquean durante 30 minutos. Se notifica a los usuarios por correo electrónico si el motivo del fallo de inicio de sesión se debe al bloqueo de la cuenta. Cuando se bloquea una cuenta de usuario, su estado en la página Management Console > User Management en la pestaña Harmony Users es Inactive. Para desbloquear la cuenta, debe esperar 30 minutos antes de intentar iniciar sesión de nuevo con su contraseña actual, o restablecer la contraseña mediante el enlace I forgot my password en la página de inicio de sesión del portal de Harmony. No se pueden reutilizar contraseñas. Si un cambio de contraseña falla por cualquier motivo, incluyendo si la contraseña ha sido utilizada anteriormente, se devuelve un mensaje de error genérico por razones de seguridad.

Cuando se habilita el inicio de sesión único (SSO) para un usuario, tales requisitos se gestionan en su lugar por el proveedor de identidad. Estos controles se aplican a los usuarios en la lista Bypass SSO de la organización, que se autentican con credenciales de Harmony. Un administrador también habilita SSO desde las políticas de una organización. Jitterbit admite estos proveedores de identidad principales:

• Autodesk (OAuth 2.0)
• Azure Active Directory (SAML 2.0)
• BMC (exclusivo para clientes de BMC) (OAuth 2.0)
• Google (OAuth 2.0)
• Okta (SAML 2.0)
• Salesforce (OAuth 2.0 y SAML 2.0)

Cuando se habilita SSO para una organización, los usuarios inician sesión en el portal de Harmony y Design Studio con las credenciales de su proveedor de identidad configurado.

Toda comunicación con Harmony ocurre a través de HTTPS (superior a TLS 1.2).

Roles de usuario y permisos de organización

Cada usuario de Harmony tiene su propia cuenta personal basada en roles y credenciales de inicio de sesión donde se almacenan de forma segura las herramientas de integración personales y los proyectos.

Una vez autenticado, Harmony identifica todas las organizaciones y entornos a los que tiene acceso este usuario. Harmony proporciona al usuario una lista de los activos con los que puede trabajar y le permite crear activos en cualquier entorno donde tenga privilegios suficientes.

Los privilegios se basan en roles y son seleccionables/configurables por entorno por organización. Cada organización tiene dos roles predeterminados:

• Administrator: Un rol llamado Administrator cuyo permiso Admin permite el acceso a todos los activos pertenecientes a esa organización.
• User: Un rol llamado User cuyo permiso Read proporciona acceso al portal de Harmony y otras áreas de acceso mínimo.

Además de los permisos Admin y Read, estos permisos independientes están disponibles para asignarse a roles:

• User Manager: Permite a un usuario gestionar usuarios y roles que no son administradores. Puede añadir, editar o eliminar usuarios que no son administradores, pero no puede cambiar un usuario de no administrador a administrador. También pueden administrar usuarios externos. Los usuarios con solo este permiso ven únicamente la página User Management en la navegación de la Management Console, y sus roles tienen deshabilitado el acceso a roles de entorno.
• Agent-Install: Permite a un usuario instalar agentes pero no proporciona control ni visibilidad fuera de esta función. Se puede utilizar para permitir que administradores dentro y fuera de la empresa establezcan conectividad adicional sin ningún impacto en los proyectos o incluso conocimiento de la plataforma.
• ApiConsumer: Cuando se utiliza en combinación con niveles de acceso a entornos, proporciona acceso para ver documentación de OpenAPI en un entorno. Por sí solo, este permiso permite acceso a la página del Portal de API.
• EDI User: Permite a un usuario de EDI crear y actualizar socios EDI, transacciones y configuraciones.
• EDI Viewer: Permite a un usuario de EDI ver socios EDI, transacciones y configuraciones.

Los administradores pueden añadir nuevos roles a la organización e invitar a otros usuarios de Harmony a unirse cuando necesitan trabajar en equipo para diseñar, construir, probar y gestionar sus proyectos, API y datos de EDI. Los usuarios pueden añadirse a múltiples roles dentro de una organización.

Consulta la tabla de Permisos para obtener información sobre los privilegios que otorga cada permiso, y Roles para crear roles adicionales con cualquier combinación de permisos.

Entornos y niveles de acceso

Se utilizan entornos para segregar los activos de una organización en estas aplicaciones de Harmony:

• Los proyectos de integración de Studio y Design Studio se implementan en entornos asociados con grupos de agentes.
• Las API de API Manager se crean y publican en entornos.
• Se agregan socios comerciales y se procesan datos EDI por entorno.

Los entornos representan un estado determinado de un proyecto o API. Muchos proyectos existen en varias etapas dentro de diferentes entornos. Por ejemplo, una configuración de ciclo de vida de proyecto común podría tener tres entornos: desarrollo, prueba y producción. Un proyecto o API puede existir en diferentes estados dentro de cada entorno.

Los administradores de la organización (usuarios con permiso Admin) administran el acceso a cada entorno mediante control de acceso basado en roles. Por ejemplo, es posible que los usuarios en el rol de desarrollador tengan privilegios de lectura, ejecución y escritura en el entorno de desarrollo, pero solo acceso de lectura al entorno de prueba y sin acceso al entorno de producción.

Existen cuatro niveles de acceso a entornos en cascada:

• Ver registros: Permite que un usuario vea los registros de operaciones de Studio y Design Studio a través de la página Runtime de la consola de administración en un entorno particular, pero no proporciona visibilidad ni control sobre los proyectos. Esto permite a los usuarios brindar soporte pero no modificar proyectos implementados en entornos críticos como producción. El acceso se limita a ver la tabla de operaciones y no incluye acceso a mensajes de registro.

• Lectura: Permite que un usuario tenga acceso de solo lectura a los proyectos de Studio y Design Studio y las API de API Manager en un entorno determinado. Esto se puede utilizar para compartir plantillas o permitir que los usuarios vean pero no cambien activos. Este nivel de acceso también proporciona acceso de solo lectura a las páginas Proyectos, Entornos y Agentes de la consola de administración.

• Ejecución: Permite que los usuarios ejecuten operaciones de Studio y Design Studio y vean mensajes de registro en la página Runtime de la consola de administración dentro de un entorno determinado. Este es un control de acceso común para entornos de prueba y a menudo se otorga a usuarios que necesitan brindar soporte a proyectos, ya que es posible que necesiten probar y ejecutar tareas según sea necesario.

• Escritura: Permite control total sobre un entorno determinado. Los usuarios que pertenecen a un rol con acceso de Escritura pueden realizar ediciones y acciones dentro de ese entorno particular. Esto incluye implementar operaciones de Studio y Design Studio; editar y publicar API de API Manager; iniciar recetas y plantillas desde Marketplace; y realizar acciones en las páginas Proyectos, Entornos y Agentes de la consola de administración.

Almacenamiento de datos

Las siguientes secciones describen los tipos de información almacenada en Harmony.

Datos del usuario

Cuando un usuario se registra y se suscribe a Harmony, debe proporcionar la siguiente información, que se almacena en el repositorio de proyectos: nombre, apellido, correo electrónico y número de teléfono. La empresa, dirección de la empresa y sitio web de la empresa se pueden proporcionar pero son opcionales.

Además, ciertos datos del sistema que se pueden utilizar para identificar a un usuario se registran para garantizar la seguridad e integridad del sistema.

Autenticación de usuarios

Se registran los intentos de inicio de sesión exitosos y fallidos para identificar posibles violaciones de seguridad y determinar si alguien intenta obtener acceso no autorizado al sistema. Se registra la siguiente información:

• ID de usuario: El ID de usuario asociado con cada intento de inicio de sesión. Esto ayuda a identificar qué usuario intenta iniciar sesión y rastrear su actividad.
• Marca de tiempo: La hora de cada intento de inicio de sesión. Esto ayuda a identificar cuándo un usuario intenta iniciar sesión y rastrear su actividad a lo largo del tiempo.
• Dirección IP: La dirección IP asociada con cada intento de inicio de sesión. Esto ayuda a identificar desde dónde el usuario intenta iniciar sesión y detectar posibles violaciones de seguridad.
• Información del dispositivo: Información sobre el dispositivo utilizado para iniciar sesión, como el sistema operativo, la versión del navegador y el tipo de dispositivo. Esto ayuda a identificar posibles violaciones de seguridad y solucionar cualquier problema que pueda surgir.
• Eventos de cierre de sesión: Cada vez que un usuario cierra sesión. Esto ayuda a garantizar que los usuarios hayan cerrado sesión y rastrear su actividad.

Autorización de usuario

La autorización de usuario determina si un usuario tiene los permisos apropiados para acceder a un recurso específico o realizar una acción específica dentro de un sistema.

Además de ID de usuario e Marca de tiempo (descritos en Autenticación de usuario), se registra la siguiente información de autorización de usuario:

• ID de recurso: El ID del recurso al que el usuario intenta acceder o modificar. Esto ayuda a identificar qué recurso intenta acceder el usuario y realizar un seguimiento del uso de recursos.
• ID de acción: El ID de la acción que el usuario intenta realizar. Esto ayuda a identificar qué acción intenta realizar el usuario y realizar un seguimiento del uso de acciones.
• Resultado de la autorización: El resultado de cada intento de autorización, incluyendo si se le otorgó o negó acceso al usuario al recurso o acción. Esto ayuda a identificar posibles brechas de seguridad y realizar un seguimiento del uso de recursos y acciones.
• Políticas de autorización: Información sobre las políticas de autorización, como el nombre y versión de la política, y cualquier opción de configuración relevante. Esto ayuda a solucionar problemas de autorización y auditar cambios de políticas.

Acceso a datos

El acceso a datos se refiere al proceso de leer o modificar datos dentro de un sistema.

Además de ID de usuario, Marca de tiempo, Dirección IP e Información del dispositivo (descritos en Autenticación de usuario), se registra la siguiente información de acceso a datos:

• ID de datos: El ID de los datos al que el usuario intenta acceder o modificar. Esto ayuda a identificar qué datos intenta acceder o modificar el usuario y realizar un seguimiento del uso de datos.
• Tipo de acceso: El tipo de acceso que se intenta, como lectura o escritura. Esto ayuda a identificar si el usuario intenta ver o modificar datos.
• Resultado del acceso: El resultado de cada intento de acceso a datos, incluyendo si se le otorgó o negó acceso al usuario a los datos. Esto ayuda a identificar posibles brechas de seguridad y realizar un seguimiento del uso de datos.

Cambios de configuración

Los cambios de configuración se refieren a modificaciones realizadas en la configuración de un sistema o aplicación.

Además de ID de usuario y Marca de tiempo (descritos en Autenticación de usuario), se registra la siguiente información de cambio de configuración:

• Elemento de configuración: El elemento de configuración específico que fue cambiado. Esto ayuda a identificar qué configuración fue modificada y realizar un seguimiento de los cambios en ese elemento a lo largo del tiempo.
• Valor anterior: El valor anterior del elemento de configuración antes del cambio. Esto ayuda a identificar cuál era la configuración antes de que se realizara el cambio.
• Valor nuevo: El nuevo valor del elemento de configuración después del cambio. Esto ayuda a identificar a qué se cambió la configuración.
• Tipo de cambio: El tipo de cambio que fue realizado, como una adición, modificación o eliminación. Esto ayuda a identificar qué tipo de cambio fue realizado en el elemento de configuración.
• Razón del cambio: (opcional) La razón del cambio de configuración, si está disponible. Esto ayuda a identificar por qué fue realizado el cambio y solucionar cualquier problema que pueda surgir como resultado del cambio.

Eventos del sistema

Los eventos del sistema se refieren a varios eventos que ocurren dentro de un sistema, como el inicio o apagado del sistema, errores, advertencias y otros eventos del sistema.

Además de ID de usuario, Marca de tiempo y Dirección IP (descritos en Autenticación de usuario), se registra la siguiente información de evento del sistema:

• Tipo de evento: El tipo de evento que ocurrió, como un evento de error, advertencia o informativo. Esto ayuda a identificar la gravedad del evento y priorizar los esfuerzos de solución de problemas.
• Descripción del evento: Una descripción del evento, incluyendo cualquier mensaje de error u otros detalles relevantes. Esto ayuda a identificar qué sucedió y solucionar cualquier problema que pueda surgir.
• Origen del evento: El origen del evento, como la aplicación, proceso del sistema o dispositivo. Esto ayuda a identificar dónde ocurrió el evento e aislar cualquier problema a componentes específicos del sistema.
• Estado del evento: El estado del evento, incluyendo si fue resuelto o sigue en curso. Esto ayuda a realizar un seguimiento de la resolución del evento y asegurar que todos los problemas sean debidamente atendidos.

Uso de API

El uso de API se refiere a la utilización de interfaces de programación de aplicaciones (API) para interactuar con un sistema o aplicación.

Además de ID de usuario, Marca de tiempo, Dirección IP e Información del dispositivo (descritos en Autenticación de usuario), se registra la siguiente información de uso de API:

• Endpoint de API: El endpoint de API específico que se llamó. Esto ayuda a identificar qué funcionalidad se accedió y a rastrear el uso de API por endpoint.
• Parámetros de solicitud: Los parámetros que se pasaron en la solicitud de API. Esto ayuda a identificar qué datos se utilizaron en la llamada de API y a solucionar problemas que puedan surgir.
• Estado de respuesta: El estado de la respuesta de API, incluidos mensajes de error u otros detalles relevantes. Esto ayuda a identificar si la llamada de API fue exitosa o no y a solucionar problemas que puedan surgir.

Datos del proyecto de integración

Para ejecutar y administrar un proyecto de integración, el usuario debe desplegar el proyecto en Harmony. El proyecto almacena detalles de diseño e implementación para indicar a los grupos de agentes qué actividades necesitan realizar. Esto incluye lo siguiente:

• Operaciones de integración que describen qué hará una unidad de integración. Por ejemplo, sincronizar todos los cambios en los datos de clientes en el sistema CRM con los datos de clientes en el sistema ERP.
• Transformaciones y scripts que describen cómo se transponen los datos del sistema de origen al sistema de destino. Esto incluye cualquier regla de validación o manipulación de datos necesaria para transferir los datos exitosamente.
• Interfaces que describen las diversas estructuras de objetos de origen y destino. Estas interfaces pueden ser estructuras de texto simple o representaciones complejas de objetos XML, JSON o EDI.
• Conexiones y endpoints que se utilizan como orígenes o destinos. Aunque estos pueden ser valores codificados, incluyendo direcciones de sistema y credenciales, también pueden referenciarse a través de variables que se pueden almacenar en bases de datos internas para clientes que implementan sus propias bóvedas de credenciales.
• Programaciones y notificaciones que determinan cuándo deben ejecutarse las operaciones por lotes y qué hacer en caso de resultados exitosos o fallidos.
• Endpoints de API que informan a los agentes y grupos de agentes cómo exponer API para que eventos de sistemas externos puedan llamar e invocar integraciones de Jitterbit.

Los datos persistentes se protegen en reposo con:

• Autenticación
• Listas de control de acceso
• Cifrado FIPS 140-2 y claves de cifrado únicas por cliente

Los datos en la nube persistentes se protegen en tránsito con:

• Autenticación.
• Cifrado TLS (Seguridad de la capa de transporte).

Registro de actividad de integración

Cuando un grupo de agentes ejecuta una operación de integración, sincroniza sus registros al registro de actividad rotativo multiusuario de Harmony. Esto incluye la siguiente información:

• Estado: El estado de una operación (p. ej. pendiente, en ejecución, exitosa, fallida).
• Agente: Qué agente del grupo de agentes ejecutó la operación.
• Temporización: Cuándo se envió, inició y completó la ejecución de la operación.
• Enviado por: Quién envió la solicitud para ejecutar la operación.
• Registros procesados: El número de registros procesados del sistema de origen y cuántos registros se publicaron en el destino.
• Mensaje: Cualquier información adicional relevante para solucionar un resultado fallido, o información de resumen que el usuario explícitamente indica a Jitterbit que escriba en el registro usando la función interna WriteToOperationLog.

Además, cuando el registro de depuración de operación se habilita en una operación de Studio, datos de entrada y salida del componente se escriben en el registro de operación.

Los datos del registro de operación se almacenan en la nube en un sistema particionado rotativo diario. Las actividades de cada día se capturan en la partición de ese día y cada partición se elimina después de 31 días. Los datos del registro de actividad más antiguos que 31 días se eliminan permanentemente.

Los registros de operación, incluidos los mensajes de registro detallados de agentes en la nube y agentes privados, y los datos de entrada y salida del componente dentro de los registros de operación, se retienen durante 30 días por Harmony.

Registros de agentes

Cada agente puede generar datos adicionales que se pueden acceder a través de Harmony o almacenar en dispositivos de almacenamiento de archivos locales y acceder desde dentro de un firewall. Se trata de registros detallados que incluyen:

• Registros de depuración de operaciones para agentes en la nube o para agentes privados
• Registros detallados de conectores accesibles solo en agentes privados
• Registros adicionales accesibles solo en agentes privados
• Archivos de registros procesados correctamente
• Archivos de registros procesados con errores

Los grupos de agentes y agentes no sincronizan automáticamente estos registros con Harmony, ya que generalmente incluyen datos comerciales confidenciales. Al utilizar sus propios dispositivos de almacenamiento, los clientes pueden proteger sus datos dentro de su firewall o en sus propias infraestructuras de nube privada.

Estos registros son útiles para propósitos de solución de problemas detallada y auditoría.

Por defecto, un grupo de agentes privados almacenará archivos de registro, archivos de depuración, archivos temporales, datos de transformación y archivos de éxito y error durante 1 a 14 días, según la configuración de las reglas del servicio de limpieza de archivos.

Datos de prueba de integración que fluyen a través de Harmony

Además de los datos almacenados en Harmony, los datos comerciales pueden fluir a través de la plataforma en la nube durante el diseño de la integración. Estos datos de prueba no persistentes fluyen cuando se realizan funciones tales como:

• Vista previa mediante archivo de muestra: Lleva datos de muestra (cargados por el usuario o datos ficticios creados a partir de la estructura de origen) a una transformación para ayudar a un usuario a identificar elementos en una interfaz y probar transformaciones. Muestra el resultado del destino transformado para un conjunto determinado de datos cargados.
• Vista previa mediante datos de origen: Lleva datos de origen de ciertos extremos (como los de una consulta de base de datos, Salesforce o NetSuite) a la transformación que se está previsualizando y muestra el resultado del destino transformado para un conjunto determinado de datos cargados.
• Script de prueba: Permite a un usuario probar scripts que incluyen funciones que podrían devolver datos (como los de una consulta de base de datos, Salesforce o NetSuite) o scripts que muestran valores de variables devueltos por una API.
• Consulta de prueba: Permite a un usuario probar si una consulta es válida y devuelve una muestra de datos del extremo durante la configuración de ciertas actividades de extremo, como las de una consulta de base de datos o Salesforce.

Servicios de IA

La plataforma Harmony está infundida con capacidades de IA que incluyen asistentes potenciados por IA y chatbots:

Jitterbit utiliza servicios de IA para procesar datos con estas características:

• Asistente de IA de iPaaS: El Asistente de IA del Generador de conectores envía indicaciones anónimas a OpenAI para enseñarle a comprender la documentación de API que utiliza para generar un conector de Studio. La característica de mapeo de IA de Jitterbit (Beta) se basa en el modelo propio de Jitterbit. Jitterbit no envía datos de transformación a ningún proveedor de modelos.
• Asistente de IA de APIM: El Asistente de IA de APIM envía indicaciones anónimas a OpenAI para crear y publicar recursos en API Manager.
• Asistente de IA de EDI: El Asistente de IA de EDI envía indicaciones anónimas a OpenAI para crear o modificar recursos en Jitterbit EDI.
• Asistente de IA de App Builder: El Asistente de IA de App Builder envía indicaciones anónimas a OpenAI para utilizarlas a fin de generar una aplicación de App Builder.
• Chatbot de IA: El chatbot de IA AskJB utiliza OpenAI con Generación Aumentada de Recuperación (RAG) para recuperar información pública disponible a través del sitio de Documentación de Jitterbit. AskJB AI está disponible a través del portal Jitterbit Harmony y públicamente en el sitio de Documentación de Jitterbit.

Topologías de seguridad de iPaaS

Cualquier proyecto de integración o servicio, incluyendo APIs, se puede desplegar con las topologías de seguridad que se describen a continuación. Dependiendo de las necesidades ambientales inmediatas y/o específicas, se debe emplear la topología que cumpla con los requisitos de datos y las políticas de gobierno de tu organización. Estas arquitecturas de despliegue, con sus topologías de seguridad asociadas, se resumen a continuación y se detallan en esta sección.

• Cloud: En la nube de Harmony, donde Jitterbit gestiona completamente el sistema y la escala.
• Privada (On-Premises, Local): En un servidor local o nube privada, donde el sistema se aloja de forma local y se gestiona localmente.
• Híbrida: En modo híbrido, donde determinadas partes del sistema se alojan de forma local y el resto es gestionado por Jitterbit.

Además, Jitterbit permite cualquier cantidad de combinaciones y ubicaciones para sus componentes, así como cambiar las opciones de despliegue según sea necesario en diferentes situaciones. Esta flexibilidad proporciona estos beneficios:

• Mayor rendimiento de procesamiento: Se puede mejorar el rendimiento utilizando el procesamiento perimetral, donde los agentes se ubican cerca de donde residen los datos.
• Facilidad de gestión: La gestión remota está disponible incluso para despliegues privados/locales.
• Seguridad y privacidad: Todo el procesamiento se realiza directamente por los agentes sin exposición a terceros, más allá de las conexiones inmediatas de origen y destino.

Topología de seguridad de despliegue en la nube completa

Los clientes que necesitan realizar integraciones donde todas sus fuentes de datos son accesibles desde la nube pueden desplegar sus proyectos en entornos de Harmony y ejecutar sus proyectos en el grupo de agentes en la nube de Jitterbit.

Aquí, el grupo de agentes en la nube pública multiinquilino operado por Jitterbit accederá directamente a los datos empresariales del cliente a través de Internet usando HTTPS. Los agentes de Jitterbit dentro de este grupo de agentes procesarán los datos empresariales y los enviarán a cualquier sistema de destino requerido. El flujo de datos dentro de la red de Jitterbit utilizará HTTPS.

Los clientes que tienen políticas que no permiten la utilización de la nube o requieren garantías excesivas de responsabilidad civil e indemnización deben validar que el Acuerdo de Suscripción Principal de Jitterbit y la Política de Privacidad cumplan con los requisitos pertinentes a las regulaciones de su industria, disposiciones de clientes, indemnización de clientes y términos de responsabilidades de clientes.

Topología de seguridad de despliegue híbrido

En un escenario de despliegue híbrido, determinadas partes del sistema se alojan de forma local y el resto es gestionado por Jitterbit. Por ejemplo, es posible que no desees exponer bases de datos y aplicaciones a ningún sistema en la nube, incluyendo Jitterbit, si los requisitos de tu organización no permiten que los datos residan en la nube (fuera del firewall) debido a preocupaciones de privacidad y regulación.

En este caso, los agentes privados residen detrás del firewall, mientras que la puerta de enlace de API está en la nube de Harmony. El agente solicita la información a través de la capa de mensajería y devuelve la carga útil de las aplicaciones y fuentes de datos a la puerta de enlace a través de la carga útil. Los clientes pueden limitar lo que se almacena en los registros para evitar que estos datos lleguen a la nube de Harmony.

Topología de seguridad de despliegue privado

En la mayoría de escenarios de integración empresarial, el grupo de agentes debe acceder tanto a aplicaciones internas como en la nube. Aquí, los usuarios desplegarían sus proyectos en entornos de Harmony, instalarían sus propios grupos de agentes privados dentro de sus redes que tengan acceso a sus aplicaciones, y luego gestionarían esos grupos de agentes aprovisionados a través de la plataforma de Harmony.

Esta topología permite a los usuarios aprovisionar y administrar sus grupos de agentes mediante Harmony, pero el grupo de agentes y cualquier dato sensible de la empresa que se procese o almacene reside dentro de su red. En esta topología, el grupo de agentes privados puede ejecutarse en entornos de servidor físico o virtual Windows o Linux (consulta Requisitos del sistema para agentes privados para obtener más información).