Ir para o conteúdo

Segurança lógica e arquitetura do Jitterbit Harmony

Introdução

A segurança lógica compreende todas as medidas de segurança implementadas na plataforma Harmony. Esta seção descreve o seguinte:

Arquitetura do sistema

O Harmony é uma plataforma unificada low-code que oferece iPaaS para sistemas de integração, gerenciamento de API para expor essas integrações como APIs, desenvolvimento de aplicativos low-code para criar aplicativos web e mobile, e processamento de EDI para transações entre empresas.

Os componentes principais do Harmony são enriquecidos com recursos de IA, incluindo assistentes com inteligência artificial para construção de aplicativos e conectores.

As seções a seguir descrevem a arquitetura e segurança de cada componente principal: Designers low-code, Ativos reutilizáveis, Microsserviços e Mecanismos de plataforma.

harmony system architecture

Designers low-code

Os designers low-code da Jitterbit são os aplicativos Jitterbit front-end que permitem aos usuários criar e gerenciar projetos de integração, APIs, aplicativos web personalizados e aplicativos mobile nativos, além de processos de EDI.

A comunicação entre aplicativos Jitterbit e a plataforma Harmony ocorre através de microsserviços Jitterbit. Todos os usuários devem ser autenticados no Harmony e toda comunicação é transmitida com segurança via HTTPS.

O acesso dos usuários aos aplicativos Jitterbit é ainda controlado por uma combinação de permissões de função organizacional e níveis de acesso ao ambiente, conforme descrito em Autenticação, permissões e acesso.

Designers de integração

Use Studio (recomendado) ou Design Studio para criar, configurar, implantar e testar projetos de integração iPaaS da Jitterbit:

  • Studio é um aplicativo web portal Harmony.
  • Design Studio é um aplicativo de desktop que deve ser instalado em uma estação de trabalho Windows ou macOS com acesso à Internet.

A comunicação através de servidores proxy corporativos é totalmente suportada, assim como IP allowlisting (whitelisting) para garantir conformidade com VPN corporativa, se necessário.

Ambos os aplicativos usam a plataforma Harmony e aproveitam os recursos de segurança do Harmony, incluindo logon único, funções de usuário e permissões organizacionais, além de níveis de acesso ao ambiente.

A função de um usuário do Harmony deve ter um mínimo de acesso de Leitura em um ambiente para acessar projetos no Studio ou Design Studio. Níveis mais altos de acesso ao ambiente concedem privilégios adicionais (consulte Autenticação, permissões e acesso).

API Manager

API Manager é um aplicativo web portal Harmony onde os usuários podem criar, controlar e consumir APIs personalizadas, APIs OData e APIs proxy.

O Jitterbit oferece uma variedade de opções para proteger APIs:

  • Perfis de segurança permitem que uma API publicada seja consumida apenas por um consumidor de API específico ou grupo de consumidores. Você define o método de autenticação no perfil de segurança, escolhendo entre autenticação anônima, básica, OAuth 2.0 ou chave de API.

  • O modo somente SSL restringe o tráfego HTTP a comunicações criptografadas. A identidade da URL HTTPS é verificada pela Symantec Class 3 Secure Server SHA256 SSL CA. A conexão com a URL HTTPS é criptografada com criptografia moderna (com criptografia TLS 1.2, a conexão é criptografada e autenticada usando AES_128_GCM e utiliza ECDHE_RSA como mecanismo de troca de chaves).

  • Os registros de API registram o perfil de segurança usado para acessar a API em cada solicitação de API.

A função de um usuário do Harmony deve ter permissão de organização Admin, ou deve ter uma combinação de permissão de organização Read com acesso mínimo Read em um ambiente para acessar o API Manager.

O Portal de API para APIs individuais ou grupos de API também pode ser acessado por usuários externos convidados por um administrador da organização Harmony.

App Builder

O App Builder é um construtor de aplicações visuais com baixo código para criar aplicações web e móveis de nível empresarial.

O acesso a uma instância do App Builder configurada está disponível através do portal Harmony. Uma função de usuário do Harmony com permissão de organização Admin é necessária para configurar o acesso de usuários com uma função de usuário do Harmony de pelo menos permissão Read.

No App Builder, as seguintes opções de segurança adicionais são compatíveis:

  • HTTPS: Quando HTTPS está ativado, cookies são definidos com o sinalizador Secure. Isso impede que o navegador transmita o cookie por um canal inseguro (HTTP). Os cookies são definidos com o sinalizador HttpOnly por padrão. O sinalizador HttpOnly reduz ataques de Cross-Site Scripting (XSS).

  • Logon único (SSO): A autenticação pode ser delegada a um provedor de SSO. O App Builder oferece suporte a vários padrões do setor, incluindo SAML SSO e WS-Federation. Estes usam a especificação de assinatura digital PKCS #1 com resumos SHA-256.

  • Autenticação baseada em declarações: Provedores de autenticação de usuário transmitem declarações para o App Builder. Os administradores de segurança mapeiam as declarações para atributos de usuário, incluindo associação em grupo.

  • Autenticação local: A autenticação local pode ser usada para autenticar com uma senha armazenada no App Builder usando a função de derivação de chave PBKDF2 com algoritmo hash SHA-256, um comprimento de chave de 16 bytes, um comprimento de salt de 16 bytes e 10.000 iterações. Os recursos de segurança incluem políticas de senha, expiração de senha, bloqueio de conta e redefinição de senha.

  • Sessões: As políticas de armazenamento de sessão são configuráveis. Por padrão, o App Builder persiste informações de sessão no banco de dados. Os administradores podem visualizar sessões e forçar a desconexão de sessões de usuários. O rastreamento de sessões protege contra certas vulnerabilidades, como ataques de reprodução de cookie.

  • Segurança baseada em funções: O acesso aos dados pode ser controlado pela associação em grupo do usuário, que determina as funções do usuário, que determinam as permissões para dados comerciais. Os Realms permitem que administradores deleguem tarefas administrativas como provisionamento de usuários e associação em grupo.

EDI

EDI é uma aplicação web do portal Harmony para gerenciar parceiros comerciais de EDI e as transações realizadas com eles.

O aplicativo EDI processa dados de EDI na nuvem Harmony. (A Jitterbit oferece uma solução separada para processamento local de dados de EDI.)

As informações de identificação pessoal (PII) são mascaradas por padrão. Um administrador do Harmony pode expor os dados de PII no aplicativo EDI por até 24 horas, após o qual serão mascarados novamente.

O app EDI também oferece a opção de gerenciar as PII de um parceiro comercial removendo-as dos documentos do parceiro.

Uma função de usuário do Harmony com a permissão de organização Admin fornece acesso para editar e executar todas as ações no app EDI.

As funções específicas do EDI EDI Viewer ou EDI User fornecem acesso mais granular às páginas e funções do EDI.

Marketplace

O Marketplace é uma aplicação web do portal Harmony que fornece acesso a mais de 400 receitas de integração e modelos de processo que podem ser importados em um ambiente para usar como base em projetos de integração do Studio.

Uma função de usuário do Harmony com permissão de organização Read ou Admin fornece acesso às receitas e modelos no Marketplace. Iniciar uma receita ou modelo em um ambiente requer acesso Write nesse ambiente.

Management Console

O Management Console é uma aplicação web do portal Harmony para gerenciar e monitorar sua organização Harmony no portal Harmony, bem como os componentes da plataforma Harmony.

O gerenciamento da organização inclui a configuração de políticas organizacionais, incluindo logon único (SSO), e a definição de quem pode acessar diferentes áreas das aplicações Jitterbit (consulte Autenticação, permissões e acesso).

O Management Console facilita uma variedade de outras tarefas de gerenciamento típicas de um administrador do Harmony:

  • Configurar ambientes, agentes e grupos de agentes para uso com projetos de integração do Studio ou Design Studio.
  • Gerenciar cronogramas, variáveis, listeners e backups para projetos de integração.
  • Gerenciar acesso de usuários externos ao API Portal.
  • Configurar tokens de acesso para conectar o app EDI ao Studio.
  • Adicionar filas de mensagens para uso com o Studio.

O Management Console também fornece informações para monitorar a organização:

  • Informações de auditoria sobre quem e qual atividade ocorreu na organização.
  • Logs de operação e histórico de implantação para projetos de integração do Studio e Design Studio.

Uma função de usuário do Harmony com permissão de organização Read tem acesso à página Dashboard, enquanto a permissão de organização Admin tem acesso e a capacidade de fazer edições e executar ações em todas as páginas do Management Console.

Uma função de usuário com permissão de organização Read pode acessar páginas adicionais do Management Console ao receber níveis de acesso ao ambiente conforme descrito em Autenticação, permissões e acesso. O modelo de camada de controle de acesso definido para cada ambiente é granular, de modo que as configurações que os usuários veem e podem interagir dependem dos controles de acesso do usuário. Os controles de acesso são aplicados a todas as funções, incluindo pesquisa de operações, execução de operações, visualização de logs, etc.

Uma função de usuário com permissão User Manager pode adicionar, editar ou excluir usuários e funções não-admin, mas não pode alterar um usuário de não-admin para admin. Também pode administrar usuários externos. Usuários com apenas a permissão User Manager veem apenas a página User Management na navegação do Management Console, e funções com apenas esta permissão têm acesso à função de ambiente desabilitado.

Ativos reutilizáveis

Os ativos reutilizáveis incluem conectores, aplicações e projetos de integração, além das ferramentas para construí-los:

  • Connector SDK: O Jitterbit Connector SDK (kit de desenvolvimento de software) fornece os meios para que os desenvolvedores construam conectores e os disponibilizem no Studio.
  • Connector Builder: O Jitterbit Connector Builder é um assistente low-code para qualquer pessoa criar um conector do Studio que exponha uma API REST acessível via HTTP.
  • Conectores pré-construídos: Jitterbit e seus parceiros fornecem centenas de conectores do Studio pré-construídos para uso em projetos de integração.
  • Aplicações pré-construídas: Jitterbit oferece aplicações web e mobile nativas pré-construídas por meio do App Builder.
  • Modelos: Soluções de integração bidirecional pré-construídas que resolvem um caso de uso complexo são fornecidas por meio do Marketplace.
  • Receitas: Projetos de integração unidirecionais que resolvem um caso de uso simples são fornecidos por meio do Marketplace.
  • Agentes de IA: Agentes pré-construídos que podem ser usados para atingir autonomamente seus objetivos sem supervisão humana direta são fornecidos por meio do Marketplace.

Microsserviços

As aplicações Jitterbit se comunicam com a plataforma Harmony por meio de um conjunto bem definido de APIs da plataforma Harmony, referidas como microsserviços da Jitterbit.

As APIs são criadas usando o mesmo rigor de codificação segura da própria Harmony (veja Processos de desenvolvimento).

Todos os usuários dessas APIs devem ser autenticados com a Harmony e toda comunicação é transmitida com segurança por HTTPS.

Mecanismos da plataforma

A plataforma Harmony fornece toda a infraestrutura e os serviços para implantar, gerenciar e executar projetos de integração; criar aplicativos web personalizados e aplicativos móveis nativos; criar, controlar e consumir APIs; e processar transações EDI.

Gateways de API

Um gateway de API é um serviço que impõe as políticas e perfis de segurança criados em APIs usando a aplicação web API Manager. A conectividade com APIs publicadas por meio do API Manager é habilitada através do gateway de API em nuvem da Jitterbit ou um gateway de API privado.

Os gateways de API executam essas tarefas de segurança envolvidas na aceitação e no processamento de chamadas feitas para uma API:

  • Gerenciamento de tráfego
  • Autorização e controle de acesso
  • Limitação de taxa
  • Processamento de payload de API

Recursos de segurança são configurados no nível de API ou no nível de perfil de segurança e são armazenados em cache no gateway de API, que são então referenciados durante o tempo de execução da API.

O gateway de API em nuvem da Jitterbit é gerenciado, mantido e hospedado pela Jitterbit e não requer nenhuma configuração.

Um gateway de API privado é um gateway local para processar APIs diretamente de seus próprios servidores. Um gateway de API privado pode ficar restrito exclusivamente a uma rede interna atrás de um firewall e não ser acessível pela Internet, embora certos serviços Jitterbit devem ser inclusos na lista de permissões (lista branca). Com um gateway de API privado, os payloads de resposta de API nunca passam pelos sistemas da Jitterbit.

Mensagens

A comunicação entre vários componentes do Jitterbit iPaaS, como Studio, agentes e a plataforma Harmony, é realizada através de um conjunto de serviços seguros de mensagens em tempo de execução baseados na API de Serviços de Mensagens Java (JMS) incluída na Plataforma Java. Essas APIs são internas à Harmony e os clientes não têm acesso a elas.

Os agentes incluem ouvintes do serviço de mensagens JMS. Todos os agentes que escutam solicitações se autenticam fortemente e recebem uma sessão autorizada na rede de mensagens Harmony. Eles só podem escutar solicitações de seus grupos de agentes específicos ou que lhes são feitas diretamente por meio da Harmony. As mensagens nunca são enviadas aos agentes; os agentes sempre as coletam por HTTPS. Isso permite que os agentes sejam executados atrás de firewalls corporativos e permaneçam protegidos sem a necessidade de abrir portas que permitiriam tráfego de entrada da Internet.

Agentes

Os processos de integração projetados em projetos do Studio e Design Studio são executados em agentes, usando um grupo de agentes em nuvem Jitterbit ou agentes privados e um grupo de agentes privados.

Esses processos podem ser executados completamente na nuvem sem a necessidade de adquirir ou gerenciar nenhum software ou a infraestrutura necessária para operá-lo. Aqueles que optam por implantar agentes no local ou em modo híbrido têm a flexibilidade de executar seus processos de integração implantando agentes privados atrás do firewall, obtendo assim maior controle sobre o fluxo de seus dados.

A Jitterbit reconhece que os clientes precisam que seus processos de integração se comuniquem com aplicações que operam atrás de firewalls corporativos por vários motivos de segurança e conformidade normativa.

A arquitetura do sistema Harmony atende aos dois cenários: os processos de integração podem ser executados completamente na nuvem ou podem ser executados atrás de firewalls corporativos para garantir que os dados comerciais não fiquem expostos à nuvem. Os usuários também podem empregar modelos híbridos onde algumas integrações são executadas na nuvem, como desenvolvimento, e outras, por exemplo, em produção, podem ser executadas atrás de firewalls corporativos.

Enquanto o sistema simplifica o provisionamento, implantação e gerenciamento de projetos de integração, também oferece aos usuários a flexibilidade de executar suas operações de integração usando grupos de agentes privados desacoplados. Trata-se de subsistemas autossuficientes que podem ser instalados atrás de firewalls corporativos ou em nuvens privadas dedicadas.

A separação entre os designs de integração, armazenados no Harmony, e o tempo de execução da integração, que ocorre nos grupos de agentes, permite que os clientes controlem o acesso e o fluxo de dados comerciais sensíveis.

Grupo de agentes na nuvem

Os agentes na nuvem são serviços, conhecidos como backend as a service (BaaS), projetados para processar e atender às necessidades dos clientes sob demanda. Eles executam todo seu trabalho de forma orientada a eventos, eliminando a necessidade de qualquer configuração, setup ou gerenciamento tradicional de sistemas de servidor "sempre ligados" que ficam atrás das aplicações.

O Jitterbit oferece a seus clientes a opção de executar todas as suas integrações na nuvem fornecendo um grupo de agentes em cluster escalável e tolerante a falhas, totalmente mantido e gerenciado pelo Jitterbit.

Para aumentar a segurança e proteger a privacidade, os agentes na nuvem do Jitterbit são codificados para garantir que os dados processados localmente não persistam; são usados pelo tempo mínimo necessário para concluir o processo pretendido e depois removidos.

Quando o grupo de agentes na nuvem do Jitterbit executa uma integração, ele se conecta diretamente com a aplicação que requer integração de dados. Em seguida, lê e publica dados nessas aplicações.

Os metadados persistidos no grupo de agentes na nuvem do Jitterbit são armazenados em buckets Amazon S3 criptografados acessíveis apenas pelo grupo de agentes.

Para clientes que precisam que as aplicações residam dentro de seu firewall, ou para usuários que realizam integrações sob conformidade regulatória rigorosa que proíbe dados de viajar fora de um determinado limite geográfico ou residir na nuvem, o Jitterbit recomenda usar um grupo de agentes privados.

Agentes privados e grupo de agentes privados

O Jitterbit oferece a flexibilidade para os clientes provisionarem e gerenciarem seus próprios grupos de agentes e agentes privados dentro de seu firewall corporativo ou nuvens privadas virtuais. Isso permite que os clientes escolham onde seu ambiente de tempo de execução de integração opera e deixa-os controlar qual rede seus dados comerciais percorrem e residem. Ao usar grupos de agentes privados para integrações, as empresas podem garantir que seus dados comerciais sensíveis nunca fluam pela plataforma Harmony.

Os agentes pertencentes a grupos de agentes privados se autenticam e comunicam com o Jitterbit Harmony via HTTPS. Os grupos de agentes privados implantados atrás de firewalls corporativos podem ser configurados para se comunicarem por meio de um servidor proxy corporativo. Se sua organização não restringe conexões de saída, não há requisitos de rede adicionais, como abrir portas em firewalls corporativos. Quando as conexões de saída são restritas, é necessário adicionar determinados serviços do Jitterbit à lista de permissões (whitelist).

O código do agente privado é criado com o mesmo rigor de codificação do código Harmony (consulte Processos de desenvolvimento).

Enquanto os grupos de agentes privados atendem a requisitos de segurança rigorosos, o usuário ou cliente é responsável pela instalação e gerenciamento de seus agentes privados. No grupo de agentes na nuvem, o Jitterbit fornece roteamento inteligente pronto para uso, alta disponibilidade e escalabilidade equivalente ao que se espera de uma tecnologia sem servidor. No entanto, em grupos de agentes privados, a segurança e escalabilidade dos agentes privados é responsabilidade do cliente (embora a alta disponibilidade ainda seja garantida pela plataforma Harmony sempre que mais de um agente for usado em um grupo de agentes privados). O Jitterbit fornece orientações de práticas recomendadas para hospedar código de agentes privados em Requisitos de sistema para agentes privados.

Serviço de escuta

O serviço de escuta é um serviço de aplicação executado em um agente privado e é consumido por determinados conectores do Studio que têm capacidades de escuta. O serviço de escuta fornece capacidades de tratamento de eventos assíncronos para operações implantadas no agente.

arquitetura do sistema de serviço de escuta

  1. Uma operação contendo um conector configurado com uma atividade de escuta de eventos é implantada e habilitada para escuta.
  2. O serviço de escuta dentro do agente inicia um listener para essa operação.
  3. O listener começa a escutar ativamente por notificações de eventos do endpoint.
  4. Quando um evento ocorre no endpoint, publica uma notificação de evento que pode ser recebida por seus assinantes.
  5. O listener capta a mensagem de notificação de evento.
  6. Se houver um agente no grupo de agentes, o listener retransmite a mensagem de evento para a operação. Se o grupo de agentes contiver o número mínimo para permitir todas as capacidades do serviço de escuta, a mensagem de evento é passada ao agente com menos carga de trabalho.
  7. Ao receber a notificação de evento, a operação dispara uma operação downstream.

Logs de transação

Os logs de transação, também chamados de logs de operação, são os logs gerados quando uma operação do Studio ou Design Studio é executada. Eles contêm informações sobre a operação, incluindo sua localização, período e status.

O log na nuvem determina se os dados de log são salvos temporariamente e acessíveis a partir da nuvem Harmony. Quando o log na nuvem está habilitado, os logs das operações também incluem mensagens de log detalhadas. O log na nuvem está sempre habilitado para grupos de agentes na nuvem Jitterbit e pode ser opcionalmente desabilitado para agentes privados.

Os logs de operação, incluindo mensagens de log detalhadas de agentes na nuvem e agentes privados, e dados de entrada e saída de componentes dentro de logs de operação, são retidos por 30 dias.

Repositório de design

A Jitterbit armazena todos os projetos implantados no Harmony em um repositório de design multilocatário. Este repositório de projetos é construído em uma arquitetura de banco de dados multilocatária, que fornece particionamento lógico de projetos por organização e, na maioria dos casos, por ambiente. Especificamente, o Harmony isola e protege os projetos dos clientes usando o seguinte:

  • Arquitetura de banco de dados segura: Inclui arquitetura de banco de dados separado e arquitetura de schema separado.
  • Conexões ou tabelas seguras: Usa conexões de banco de dados confiáveis.
  • Criptografia: Obscurece dados críticos para que permaneçam inacessíveis a partes não autorizadas, mesmo que venham a possuí-los.
  • Filtragem: Usa uma camada intermediária entre um locatário e uma fonte de dados que funciona como uma peneira, fazendo parecer ao locatário que seus dados são os únicos dados no banco de dados.
  • Listas de controle de acesso: Determina quem pode acessar dados no aplicativo e o que pode fazer com eles.

Os projetos costumam conter credenciais como nome de usuário e senha usadas para se conectar a vários endpoints. Essas informações são criptografadas dentro do repositório multilocatário.

O repositório é replicado em duas regiões (como Leste e Oeste) para cada região do Harmony (NA, EMEA e APAC).

Os clientes não têm nenhum acesso direto a este repositório. Os vários componentes do iPaaS Jitterbit, como designers de integração e agentes na nuvem, usam APIs para acessar o repositório. Após autenticação e validação de controle de acesso, toda comunicação com o repositório é feita através de várias camadas de API. Além de controlar o acesso à API de borda via HTTPS e sessões do lado do servidor, as APIs devem validar o controle de acesso do usuário através de listas baseadas em ambiente e Controle de Acesso Baseado em Função (RBAC). Essas listas garantem que os usuários possam visualizar, agir e alterar o sistema apenas com base nas permissões concedidas por um administrador da organização (usuário com permissão Admin). Além disso, a granularidade da trilha de auditoria é configurável por cliente.

O banco de dados de atividade rotativo do Harmony armazena informações de status de tempo de execução, bem como logs de operações em execução de todos os usuários do Harmony.

O banco de dados de atividade é construído em uma arquitetura multilocatária, e embora os dados de atividade de todos os usuários residam no mesmo banco de dados, há segmentação lógica por organização e ambiente aplicada através de uma camada de controle de acesso de software e chaves de criptografia exclusivas para garantir que os usuários possam visualizar apenas as atividades às quais têm acesso.

O banco de dados de atividades é replicado entre Regiões e Zonas de Disponibilidade da AWS para garantir alta disponibilidade e é feito backup caso seja necessário restaurá-lo.

O acesso ao banco de dados de atividades é fornecido por um conjunto de APIs. O log de atividades usa uma infraestrutura de APIs e lista de controle de acesso (ACL) semelhante à do repositório de projetos.

Serviços de arquivo

O Harmony inclui um conjunto de serviços de arquivo usados para armazenar arquivos, como esquemas e personalizações. Todos os arquivos são armazenados no serviço AWS S3 e podem ser acessados apenas por meio da plataforma Harmony, não sendo possível acessá-los diretamente.

Repositório de esquema

Para suportar integrações de uma variedade de endpoints, o Harmony armazena vários tipos de esquemas, como WSDL, XSD, JTR e DTDs.

Além do armazenamento no armazenamento de dados em nuvem do Harmony, os esquemas do Studio são armazenados no repositório de design para gerenciar a reutilização de esquemas dentro de um projeto.

Repositório de personalizações

Para suportar integrações de uma variedade de endpoints de banco de dados, o Harmony armazena vários drivers JDBC e ODBC, incluindo aqueles que clientes instalam em agentes privados por conta própria.

Para estender as capacidades do Studio, você pode criar seus próprios conectores personalizados usando o Connector Builder ou o Connector SDK.

Serviços de backend

Os serviços de backend são os serviços e APIs subjacentes do Harmony por meio dos quais todos os dados fluem.

Os serviços de backend lidam com tarefas como login, gerenciamento de usuários, implantação, agendamento, gerenciamento de organização, etc.

Runtime do construtor de aplicativos

As soluções do App Builder podem ser executadas nas seguintes configurações de implantação:

  • On-premises: O ambiente do App Builder é implantado localmente no site do cliente. Os servidores web e de banco de dados e o ambiente do App Builder residem no hardware do cliente na rede do cliente. Esta opção oferece controle e flexibilidade total sobre o ambiente e a infraestrutura do App Builder. Todas as operações de manutenção, segurança, hardware e software são gerenciadas pelo cliente.

  • Nuvem privada: O ambiente do App Builder é implantado em um provedor de nuvem privada do cliente, seja AWS, Google Cloud Platform (GCP) ou Microsoft Azure. Os servidores web e de banco de dados e o ambiente do App Builder residem na nuvem privada. Esta opção oferece flexibilidade e controle sobre o ambiente e a infraestrutura do App Builder. Todas as operações de manutenção, segurança, hardware e software são gerenciadas pelo cliente.

Mecanismo de runtime B2B

As transações EDI são processadas por meio do runtime em nuvem EDI, também conhecido como eiCloud.

Após uma transação ser gerada, ela é armazenada no banco de dados de transações enquanto aguarda processamento. O documento EDI persiste até ser arquivado usando as configurações de arquivo definidas para o parceiro comercial. O status de um documento EDI pode ser verificado a qualquer momento por meio da página EDI Transactions.

Protocolos de comunicação EDI padrão são suportados, como FTP/SFTP, HTTP/HTTPS, AS2, pipes personalizados, etc.

Formatos EDI padrão são suportados, incluindo ANSI X12 (incluindo VICS), EDIFACT e seus subconjuntos e Tradacoms. As transações são processadas usando EDIXml, o formato de intercâmbio recomendado para novos fluxos de trabalho, ou usando o formato XCBL legado.

Sistema de mensageria

O Message Queue (MQ) Service é um serviço de fila de mensagens em nuvem multilocatário para criar e gerenciar filas e mensagens. Ele permite criar integrações desacopladas dos endpoints que você está integrando. O serviço MQ é usado com o conector Jitterbit MQ do Studio.

message queue system architecture

  1. Os dados são recuperados de um endpoint de origem, por exemplo, usando um conector do Studio. Os dados recuperados podem então ser transformados em uma mensagem a ser consumida pelo conector Jitterbit MQ.

  2. Usando a atividade Send ou Send Bulk do Jitterbit MQ, os dados são enviados para o serviço Jitterbit Message Queue (que envia as mensagens para a fila de mensagens especificada).

  3. As mensagens podem então ser recuperadas de uma fila de mensagens usando uma atividade Get ou Get Bulk do Jitterbit MQ.

  4. Os dados recuperados de uma mensagem podem então ser usados como entrada a ser consumida por um endpoint de destino, como usando um conector do Studio.

  5. Após consumir os dados, a mensagem pode ser confirmada (usando a atividade Acknowledge) ou rejeitada negativamente (usando a atividade NACK). Se a mensagem não for confirmada ou rejeitada antes do tempo limite de 30 minutos, ela estará disponível para ser recuperada da fila novamente por uma atividade Get ou Get Bulk.

Mecanismos de análise e registro

A plataforma Harmony fornece informações de análise e registro que podem ser acessadas por meio do portal Harmony ou diretamente nos servidores de agentes privados.

Processos de desenvolvimento

A Jitterbit desenvolve e melhora suas aplicações usando práticas sólidas de ciclo de vida de desenvolvimento de software (SDLC), como:

  • Identificar vulnerabilidades de fontes externas para impulsionar mudanças e melhorias de código.
  • Aplicar patches de hardware e software. Nosso ambiente virtual permite aplicar mudanças de código e patches de hardware sem tempo de inatividade.
  • Fornecer recursos seguros de autenticação e registro.
  • Remover contas de desenvolvimento, IDs e senhas de ambientes de produção.
  • Seguir práticas rigorosas de gerenciamento de mudanças para atualizações de código e patches.
  • Separar ambientes de teste e desenvolvimento de produção.
  • Manter separação de responsabilidades entre equipes de desenvolvimento e suporte.
  • Garantir que Informações Pessoais Identificáveis (PII) não sejam usadas em ambientes de teste.
  • Remover IDs de teste e desenvolvimento antes de migrar código para produção.
  • Executar revisão de código regularmente.
  • Documentar mudanças de código.
  • Solicitar aprovação de desenvolvedores sênior para todas as mudanças de código.
  • Realizar testes de funcionalidade e regressão antes do lançamento em produção.
  • Manter procedimentos de reversão para preservar alta disponibilidade e integridade.
  • Seguir práticas de codificação segura de acordo com uma política SDLC e atender às necessidades de treinamento de segurança da equipe de desenvolvimento.
  • Verificar falhas de segurança conforme prescrito pelo Projeto de Segurança de Aplicações Web Aberta (OWASP), como falhas de injeção, estouro de buffer, erros criptográficos, tratamento de erros, etc.
  • Avaliar vulnerabilidades em cada lançamento.
  • Realizar testes de penetração anuais.

Autenticação, permissões e acesso

Antes que um usuário possa começar seu trabalho, deve-se autenticar no Harmony usando sua conta de usuário. Essa conta tem permissões baseadas em função na organização Harmony. Essas funções podem receber vários níveis de acesso em ambientes individuais.

Registro e autenticação

Para acessar e usar a plataforma Harmony, um usuário deve se registrar e autenticar usando sua conta de usuário.

A força da senha, a complexidade e os atributos, como autenticação de dois fatores, são personalizáveis para que os clientes possam atender aos requisitos de sua política de segurança. Os administradores também podem restringir o acesso a domínios de membros especificados ou exigir que os endereços IP dos usuários estejam dentro de um intervalo especificado. Essas configurações são definidas nas políticas de uma organização. Se um usuário for membro de várias organizações, as políticas mais rigorosas de qualquer organização da qual for membro entrarão em vigor para seu login.

Após 5 tentativas de login falhadas usando credenciais da conta Harmony, as contas são bloqueadas por 30 minutos. Os usuários recebem notificação por e-mail se o motivo da falha de login for devido ao bloqueio da conta. Quando um usuário é bloqueado, seu status na página Management Console > User Management na aba Harmony Users é Inactive. Para limpar o bloqueio, é necessário aguardar 30 minutos antes de tentar fazer login novamente com a senha existente, ou redefinir a senha usando o link I forgot my password na página de login do portal Harmony. Senhas não podem ser reutilizadas. Se uma alteração de senha falhar por qualquer motivo, inclusive se a senha foi usada anteriormente, uma mensagem de erro genérica é retornada por razões de segurança.

Quando o single sign-on (SSO) é habilitado para um usuário, esses requisitos são gerenciados pelo provedor de identidade. Esses controles se aplicam aos usuários na lista Bypass SSO da organização, que se autenticam com credenciais Harmony. O SSO também é habilitado por um administrador nas políticas da organização. A Jitterbit suporta estes principais provedores de identidade:

  • Autodesk (OAuth 2.0)
  • Azure Active Directory (SAML 2.0)
  • BMC (proprietário apenas para clientes BMC) (OAuth 2.0)
  • Google (OAuth 2.0)
  • Okta (SAML 2.0)
  • Salesforce (OAuth 2.0 e SAML 2.0)

Quando o SSO é habilitado para uma organização, os usuários fazem login no portal Harmony e no Design Studio com as credenciais do provedor de identidade configurado.

Toda comunicação com Harmony ocorre via HTTPS (superior a TLS 1.2).

Funções de usuário e permissões da organização

Cada usuário Harmony possui sua própria conta baseada em funções e credenciais de login pessoais, onde as ferramentas de integração pessoais e projetos são armazenados com segurança.

Após a autenticação, o Harmony identifica todas as organizações e ambientes aos quais o usuário tem acesso. O Harmony fornece ao usuário uma lista dos ativos com os quais pode trabalhar e permite criar ativos em qualquer ambiente onde possui privilégios suficientes.

Os privilégios são baseados em funções e podem ser selecionados/configurados por ambiente por organização. Toda organização tem duas funções padrão:

  • Administrator: Uma função chamada Administrator cuja permissão Admin permite acesso a todos os ativos pertencentes a essa organização.
  • User: Uma função chamada User cuja permissão Read fornece acesso ao portal Harmony e a outras áreas de acesso mínimo.

Além das permissões Admin e Read, essas permissões independentes estão disponíveis para serem atribuídas às funções:

  • User Manager: Permite que um usuário gerencie usuários e funções não administradores. Pode adicionar, editar ou excluir usuários não administradores, mas não pode alterar um usuário de não administrador para administrador. Também pode administrar usuários externos. Usuários com apenas essa permissão veem apenas a página User Management na navegação do Management Console, e suas funções têm acesso à função de ambiente desabilitado.
  • Agent-Install: Permite que um usuário instale agentes, mas não fornece controle nem visibilidade fora dessa função. Isso pode ser usado para permitir que administradores dentro e fora da empresa estabeleçam conectividade adicional sem qualquer impacto nos projetos ou mesmo conhecimento da plataforma.
  • ApiConsumer: Quando usado em combinação com níveis de acesso ao ambiente, fornece acesso para visualizar documentação OpenAPI em um ambiente. Por si só, essa permissão permite acesso à página API Portal.
  • EDI User: Permite que um usuário EDI crie e atualize parceiros, transações e configurações EDI.
  • EDI Viewer: Permite que um usuário EDI visualize parceiros, transações e configurações EDI.

Os administradores podem adicionar novas funções à organização e convidar outros usuários Harmony a participarem quando precisam trabalhar em equipes para projetar, criar, testar e gerenciar seus projetos, APIs e dados EDI. Usuários podem ser adicionados a várias funções dentro de uma organização.

Consulte a tabela de Permissões para informações sobre os privilégios concedidos por cada permissão e Funções para criar funções adicionais com qualquer combinação de permissões.

Ambientes e níveis de acesso

Os ambientes segregam os ativos de uma organização para estes aplicativos do Harmony:

  • Projetos de integração do Studio e Design Studio são implantados em ambientes associados a grupos de agentes.
  • As APIs do API Manager são criadas e publicadas em ambientes.
  • Parceiros comerciais são adicionados e dados EDI são processados por ambiente.

Os ambientes representam um determinado estado de um projeto ou API. Muitos projetos existem em vários estágios dentro de diferentes ambientes. Por exemplo, uma configuração comum do ciclo de vida do projeto pode ter três ambientes: desenvolvimento, teste e produção. Um projeto ou API pode existir em estados diferentes dentro de cada ambiente.

Os administradores da organização (usuários com permissão Admin) gerenciam o acesso a cada ambiente usando controle de acesso baseado em funções. Por exemplo, usuários com a função de desenvolvedor podem ter privilégios de leitura, execução e escrita no ambiente de desenvolvimento, mas apenas acesso de leitura ao ambiente de teste e nenhum acesso ao ambiente de produção.

Existem quatro níveis de acesso ao ambiente em cascata:

  • Visualizar Logs: Permite que um usuário visualize logs de operações do Studio e Design Studio através da página Runtime do Console de Gerenciamento em um ambiente específico, mas não fornece visibilidade ou controle sobre projetos. Isso permite que usuários façam suporte mas não modifiquem projetos implantados em ambientes críticos como produção. O acesso é limitado à visualização da tabela de operações e não inclui acesso a mensagens de log.

  • Leitura: Permite que um usuário tenha acesso somente leitura a projetos do Studio e Design Studio e APIs do API Manager em um determinado ambiente. Isso pode ser usado para compartilhar modelos ou permitir que usuários visualizem mas não alterem ativos. Este nível de acesso também fornece acesso somente leitura às páginas Projetos, Ambientes e Agentes do Console de Gerenciamento.

  • Execução: Permite que usuários executem operações do Studio e Design Studio e visualizem mensagens de log na página Runtime do Console de Gerenciamento dentro de um determinado ambiente. Este é um controle de acesso comum para ambientes de teste e geralmente é concedido a usuários que precisam fazer suporte a projetos, pois podem precisar testar e executar tarefas conforme necessário.

  • Escrita: Permite controle total de um determinado ambiente. Usuários pertencentes a uma função com acesso de Escrita podem fazer edições e executar ações dentro desse ambiente específico. Isso inclui implantar operações do Studio e Design Studio; editar e publicar APIs do API Manager; iniciar receitas e modelos do Marketplace; e executar ações nas páginas Projetos, Ambientes e Agentes do Console de Gerenciamento.

Armazenamento de dados

As seções a seguir descrevem os tipos de informações armazenadas no Harmony.

Dados do usuário

Quando um usuário se registra e assina o Harmony, deve fornecer as seguintes informações, que são armazenadas no repositório do projeto: primeiro nome, sobrenome, email e número de telefone. Empresa, endereço da empresa e site da empresa podem ser fornecidos, mas são opcionais.

Além disso, certos dados do sistema que podem ser usados para identificar um usuário são registrados para garantir a segurança e integridade do sistema.

Autenticação do usuário

Tentativas de login bem-sucedidas e falhadas são registradas para identificar possíveis violações de segurança e determinar se alguém está tentando obter acesso não autorizado ao sistema. Estas informações são registradas:

  • ID do usuário: O ID do usuário associado a cada tentativa de login. Isso ajuda a identificar qual usuário está tentando fazer login e rastrear sua atividade.
  • Data e hora: A hora de cada tentativa de login. Isso ajuda a identificar quando um usuário está tentando fazer login e rastrear sua atividade ao longo do tempo.
  • Endereço IP: O endereço IP associado a cada tentativa de login. Isso ajuda a identificar de onde o usuário está tentando fazer login e detectar possíveis violações de segurança.
  • Informações do dispositivo: Informações sobre o dispositivo usado para fazer login, como o sistema operacional, versão do navegador e tipo de dispositivo. Isso ajuda a identificar possíveis violações de segurança e solucionar problemas que possam surgir.
  • Eventos de logout: Cada vez que um usuário faz logout. Isso ajuda a garantir que os usuários estejam desconectados e rastrear sua atividade.

Autorização do usuário

Autorização do usuário determina se um usuário tem as permissões apropriadas para acessar um recurso específico ou executar uma ação específica dentro de um sistema.

Além de ID do usuário e Timestamp (descritos em Autenticação do usuário), as seguintes informações de autorização do usuário são registradas:

  • ID do recurso: O ID do recurso que o usuário está tentando acessar ou modificar. Isso ajuda a identificar qual recurso o usuário está tentando acessar e rastrear o uso do recurso.
  • ID da ação: O ID da ação que o usuário está tentando executar. Isso ajuda a identificar qual ação o usuário está tentando executar e rastrear o uso da ação.
  • Resultado da autorização: O resultado de cada tentativa de autorização, incluindo se o usuário recebeu ou foi negado acesso ao recurso ou ação. Isso ajuda a identificar possíveis violações de segurança e rastrear o uso de recursos e ações.
  • Políticas de autorização: Informações sobre as políticas de autorização, como o nome e versão da política, e quaisquer opções de configuração relevantes. Isso ajuda a solucionar problemas de autorização e auditar alterações de política.

Acesso a dados

Acesso a dados refere-se ao processo de leitura ou modificação de dados dentro de um sistema.

Além de ID do usuário, Timestamp, Endereço IP e Informações do dispositivo (descritos em Autenticação do usuário), as seguintes informações de acesso a dados são registradas:

  • ID dos dados: O ID dos dados que o usuário está tentando acessar ou modificar. Isso ajuda a identificar quais dados o usuário está tentando acessar ou modificar e rastrear o uso de dados.
  • Tipo de acesso: O tipo de acesso sendo tentado, como leitura ou escrita. Isso ajuda a identificar se o usuário está tentando visualizar ou modificar dados.
  • Resultado do acesso: O resultado de cada tentativa de acesso a dados, incluindo se o usuário recebeu ou foi negado acesso aos dados. Isso ajuda a identificar possíveis violações de segurança e rastrear o uso de dados.

Alterações de configuração

Alterações de configuração referem-se a modificações feitas nas configurações de um sistema ou aplicação.

Além de ID do usuário e Timestamp (descritos em Autenticação do usuário), as seguintes informações de alteração de configuração são registradas:

  • Item de configuração: O item de configuração específico que foi alterado. Isso ajuda a identificar qual configuração foi modificada e rastrear alterações nesse item ao longo do tempo.
  • Valor anterior: O valor anterior do item de configuração antes da alteração. Isso ajuda a identificar qual era a configuração antes da alteração ser feita.
  • Novo valor: O novo valor do item de configuração após a alteração. Isso ajuda a identificar para qual valor a configuração foi alterada.
  • Tipo de alteração: O tipo de alteração feita, como adição, modificação ou exclusão. Isso ajuda a identificar que tipo de alteração foi feita no item de configuração.
  • Motivo da alteração: (opcional) O motivo da alteração de configuração, se disponível. Isso ajuda a identificar por que a alteração foi feita e solucionar problemas que possam surgir como resultado da alteração.

Eventos do sistema

Eventos do sistema referem-se a vários eventos que ocorrem dentro de um sistema, como inicialização ou desligamento do sistema, erros, avisos e outros eventos do sistema.

Além de ID do usuário, Timestamp e Endereço IP (descritos em Autenticação do usuário), as seguintes informações de evento do sistema são registradas:

  • Tipo de evento: O tipo de evento que ocorreu, como um evento de erro, aviso ou informativo. Isso ajuda a identificar a gravidade do evento e priorizar os esforços de solução de problemas.
  • Descrição do evento: Uma descrição do evento, incluindo quaisquer mensagens de erro ou outros detalhes relevantes. Isso ajuda a identificar o que aconteceu e solucionar problemas que possam surgir.
  • Origem do evento: A origem do evento, como a aplicação, processo do sistema ou dispositivo. Isso ajuda a identificar onde o evento ocorreu e isolar problemas em componentes específicos do sistema.
  • Status do evento: O status do evento, incluindo se foi resolvido ou ainda está em andamento. Isso ajuda a rastrear a resolução do evento e garantir que todos os problemas sejam adequadamente resolvidos.

Uso de API

Uso de API refere-se à utilização de interfaces de programação de aplicações (APIs) para interagir com um sistema ou aplicação.

Além de ID de usuário, Timestamp, Endereço IP e Informações do dispositivo (descritas em Autenticação de usuário), as seguintes informações de uso de API são registradas:

  • Endpoint de API: O endpoint de API específico que foi chamado. Isso ajuda a identificar qual funcionalidade foi acessada e rastrear o uso de API por endpoint.
  • Parâmetros de solicitação: Os parâmetros passados na solicitação de API. Isso ajuda a identificar quais dados foram usados na chamada de API e a solucionar problemas que possam surgir.
  • Status de resposta: O status da resposta de API, incluindo mensagens de erro ou outros detalhes relevantes. Isso ajuda a identificar se a chamada de API foi bem-sucedida ou não e a solucionar problemas que possam surgir.

Dados do projeto de integração

Para executar e gerenciar um projeto de integração, um usuário deve implantar o projeto no Harmony. O projeto armazena detalhes de design e implementação para instruir grupos de agentes sobre quais atividades precisam executar. Isso inclui o seguinte:

  • Operações de integração que descrevem o que uma unidade de integração fará. Por exemplo, sincronizar todas as alterações nos dados do cliente no sistema CRM com dados do cliente no sistema ERP.
  • Transformações e scripts que descrevem como esses dados são transpostos do sistema de origem para o sistema de destino. Isso inclui qualquer regra de validação ou manipulação de dados necessária para transferir os dados com sucesso.
  • Interfaces que descrevem as várias estruturas de objetos de origem e destino. Essas interfaces podem ser estruturas de texto simples ou representações complexas de objetos XML, JSON ou EDI.
  • Conexões e endpoints usados como origens ou destinos. Embora possam ser valores hard-coded, incluindo endereços de sistema e credenciais, também podem ser referenciados através de variáveis que podem ser armazenadas em bancos de dados internos para clientes que implementam seus próprios cofres de credenciais.
  • Cronogramas e notificações que determinam quando operações em lote precisam ser executadas e o que fazer em caso de resultados bem-sucedidos e com falha.
  • Endpoints de API que informam agentes e grupos de agentes como expor APIs para que eventos de sistemas externos possam chamar e invocar integrações do Jitterbit.

Dados persistentes são protegidos em repouso com:

  • Autenticação
  • Listas de controle de acesso
  • Criptografia FIPS 140-2 e chaves de criptografia exclusivas por cliente

Dados persistentes na nuvem são protegidos em trânsito com:

  • Autenticação.
  • Criptografia TLS (Transport Layer Security).

Log de atividade de integração

Quando um grupo de agentes executa uma operação de integração, sincroniza seus logs para o log de atividade rotativo multi-tenant do Harmony. Isso inclui as seguintes informações:

  • Status: O estado de uma operação (por exemplo, pendente, em execução, bem-sucedida, com falha).
  • Agente: Qual agente no grupo de agentes executou a operação.
  • Tempo: Quando a execução da operação foi enviada, iniciada e concluída.
  • Enviado por: Quem enviou a solicitação para executar a operação.
  • Registros processados: O número de registros processados do sistema de origem e quantos registros foram postados no destino.
  • Mensagem: Qualquer informação adicional relevante para solucionar um resultado com falha ou informações resumidas que um usuário explicitamente instrui o Jitterbit a escrever no log usando a função interna WriteToOperationLog.

Além disso, quando o log de depuração de operação está ativado em uma operação do Studio, dados de entrada e saída do componente são escritos no log de operação.

Os dados do log de operação são armazenados na nuvem em um sistema particionado rotativo diário. As atividades de cada dia são capturadas na partição desse dia e cada partição é descartada após 31 dias. Os dados do log de atividade com mais de 31 dias são removidos permanentemente.

Os logs de operação, incluindo mensagens de log detalhadas de agentes na nuvem e agentes privados, e dados de entrada e saída do componente nos logs de operação, são retidos por 30 dias pelo Harmony.

Logs do agente

Cada agente pode gerar dados adicionais que podem ser acessados via Harmony ou armazenados em dispositivos de armazenamento de arquivos locais e acessados de dentro de um firewall. Esses são logs detalhados, que incluem:

Os grupos de agentes e agentes não sincronizam automaticamente esses dados com Harmony, pois geralmente incluem dados comerciais confidenciais. Ao usar seus próprios dispositivos de armazenamento, os clientes podem proteger seus dados dentro do firewall ou em suas próprias infraestruturas de nuvem privada.

Esses logs são úteis para fins detalhados de solução de problemas e auditoria.

Por padrão, um grupo de agentes privados armazenará arquivos de log, arquivos de depuração, arquivos temporários, dados de transformação e arquivos de sucesso e falha por 1 a 14 dias, dependendo da configuração das regras do serviço de limpeza de arquivos.

Dados de teste de integração que fluem através do Harmony

Além dos dados armazenados no Harmony, dados comerciais podem fluir pela plataforma em nuvem durante o design da integração. Esses dados de teste não persistentes fluem ao realizar funções como:

  • Visualizar usando arquivo de exemplo: Traz dados de exemplo – carregados pelo usuário ou dados simulados criados a partir da estrutura de origem – para uma transformação para ajudar um usuário a identificar elementos em uma interface e testar transformações. Mostra o resultado do alvo transformado para um determinado conjunto de dados que é carregado.
  • Visualizar usando dados de origem: Traz dados de origem de certos endpoints – como os de uma consulta de banco de dados, Salesforce ou NetSuite – para a transformação que está sendo visualizada e mostra o resultado do alvo transformado para um determinado conjunto de dados que é carregado.
  • Script de teste: Permite que um usuário teste scripts incluindo funções que podem retornar dados – como os de uma consulta de banco de dados, Salesforce ou NetSuite – ou scripts que mostram valores de variáveis retornados de uma API.
  • Consulta de teste: Permite que um usuário teste se uma consulta é válida e retorna uma amostra de dados do endpoint durante a configuração de certas atividades de endpoint, como as de uma consulta de banco de dados ou Salesforce.

Serviços de IA

A plataforma Harmony é equipada com recursos de IA incluindo assistentes alimentados por IA e chatbots:

security ai

Importante

Apenas dados anonimizados e não sensíveis são compartilhados com segurança com a OpenAI.

O Jitterbit usa serviços de IA para processar dados com estes recursos:

  • Assistente de IA do iPaaS: O Assistente de IA do Connector Builder envia prompts anonimizados para a OpenAI para ensiná-la a entender a documentação da API que usa para gerar um conector Studio. O recurso de mapeamento de IA do Jitterbit (Beta) é baseado no próprio modelo do Jitterbit. O Jitterbit não envia dados de transformação para nenhum provedor de modelo.
  • Assistente de IA do APIM: O Assistente de IA do APIM envia prompts anonimizados para a OpenAI para criar e publicar ativos no API Manager.
  • Assistente de IA do EDI: O Assistente de IA do EDI envia prompts anonimizados para a OpenAI para criar ou modificar ativos no Jitterbit EDI.
  • Assistente de IA do App Builder: O Assistente de IA do App Builder envia prompts anonimizados para a OpenAI para serem usados na geração de uma aplicação do App Builder.
  • Chatbot de IA: O chatbot de IA AskJB usa a OpenAI com Retrieval Augmented Generation (RAG) para recuperar informações públicas disponíveis através do site de Documentação do Jitterbit. O AskJB AI está disponível através do portal Jitterbit Harmony e publicamente no site de Documentação do Jitterbit.

Topologias de segurança iPaaS

Qualquer projeto de integração ou serviço, incluindo APIs, pode ser implantado com as topologias de segurança descritas abaixo. Dependendo das necessidades ambientais imediatas e/ou específicas, você deve empregar a topologia que atenda aos requisitos de dados e políticas de governança da sua organização. Essas arquiteturas de implantação, com topologias de segurança associadas, são resumidas a seguir e detalhadas nesta seção.

  • Nuvem: Na nuvem Harmony, onde o sistema e a escala são totalmente gerenciados pela Jitterbit.
  • Privado (Local, On-Premises): Em um servidor local ou nuvem privada, onde o sistema é auto-hospedado e gerenciado localmente.
  • Híbrido: Em modo híbrido, onde partes específicas do sistema são auto-hospedadas e o restante é gerenciado pela Jitterbit.

Além disso, a Jitterbit permite qualquer número de combinações e localizações para seus componentes, além de permitir trocar as opções de implantação conforme necessário em diferentes situações. Essa flexibilidade oferece estes benefícios:

  • Melhor desempenho de processamento: O desempenho pode ser aprimorado usando processamento de borda, onde os agentes estão localizados próximo aos dados.
  • Facilidade de gerenciamento: Gerenciamento remoto está disponível até mesmo para implantações privadas/locais.
  • Segurança e privacidade: Todo o processamento é realizado pelos agentes diretamente sem exposição a terceiros além das conexões de origem e destino imediatas.

Topologia de segurança de implantação na nuvem completa

Clientes que precisam executar integrações onde todas as suas fontes de dados são acessíveis pela nuvem podem implantar seus projetos nos ambientes Harmony e executar seus projetos no grupo de agentes na nuvem Jitterbit.

security cloud

Aqui, o grupo de agentes de nuvem pública multi-tenant operado pela Jitterbit acessará dados comerciais do cliente diretamente pela Internet usando HTTPS. Os agentes Jitterbit dentro deste grupo de agentes processarão dados comerciais e os publicarão em qualquer sistema de destino necessário. Os dados fluem dentro da rede Jitterbit usando HTTPS.

Nota

Todos os dados mencionados acima persistirão no ambiente operacional seguro da Harmony por um breve período de tempo.

Clientes que possuem políticas que não permitem a utilização da nuvem ou que exigem garantias excessivas de responsabilidade e indenização devem validar que o Acordo de Assinatura Principal da Jitterbit e a Política de Privacidade estejam em conformidade com as necessidades relacionadas às regulamentações do setor, disposições de clientes, indenização de clientes e termos de responsabilidades de clientes.

Topologia de segurança de implantação híbrida

Em um cenário de implantação híbrida, partes específicas do sistema são auto-hospedadas e o restante é gerenciado pela Jitterbit. Por exemplo, você pode não querer expor bancos de dados e aplicativos a nenhum sistema em nuvem, incluindo a Jitterbit, se os requisitos da sua organização não permitirem que dados residam na nuvem (fora do firewall) devido a preocupações de privacidade e regulamentação.

security hybrid

Nesse caso, os agentes privados residem atrás do firewall, enquanto o gateway de API está na nuvem Harmony. O agente solicita as informações através da camada de mensagens e coloca a carga útil dos aplicativos e fontes de dados de volta ao gateway via carga útil. Os clientes podem limitar o que é armazenado nos registros para impedir que esses dados cheguem à nuvem Harmony.

Topologia de segurança de implantação privada

Na maioria dos cenários de integração corporativa, o grupo de agentes deve acessar aplicativos internos e em nuvem. Aqui, os usuários implantariam seus projetos nos ambientes Harmony, instalariam seus próprios grupos de agentes privados em suas redes que possuem acesso aos seus aplicativos e gerenciariam esses grupos de agentes provisionados através da plataforma Harmony.

security private

Esta topologia permite que os usuários provisionem e gerenciem seus grupos de agentes usando o Harmony, mas o grupo de agentes e qualquer dado comercial sensível que seja processado ou armazenado reside dentro da sua rede. Nesta topologia, o grupo de agentes privados pode ser executado em ambientes de servidor físico ou virtual Windows ou Linux (consulte Requisitos do sistema para agentes privados para obter mais informações).