Zum Inhalt springen

Logische Sicherheit und Architektur von Jitterbit Harmony

Einführung

Logische Sicherheit umfasst alle Sicherheitsmaßnahmen innerhalb der Harmony-Plattform. In diesem Abschnitt werden die folgenden Themen beschrieben:

Systemarchitektur

Harmony ist eine einheitliche Low-Code-Plattform, die iPaaS für Integrationssysteme, API-Management zur Bereitstellung dieser Integrationen als APIs, Low-Code-Anwendungsentwicklung zum Erstellen von Web- und Mobile Apps sowie EDI-Verarbeitung für B2B-Transaktionen bietet.

Die Kernkomponenten von Harmony sind mit KI-Funktionen durchdrungen, einschließlich KI-gestützter Assistenten für App- und Connector-Erstellung.

Die folgenden Abschnitte beschreiben die Architektur und Sicherheit jeder Kernkomponente: Low-Code-Designer, Wiederverwendbare Assets, Microservices und Plattform-Engines.

harmony system architecture

Low-Code-Designer

Jitterbit's Low-Code-Designer sind die Front-End-Jitterbit-Anwendungen, mit denen Benutzer Integrationsprojekte, APIs, benutzerdefinierte Web-Apps und native Mobile Apps sowie EDI-Prozesse erstellen und verwalten können.

Die Kommunikation zwischen Jitterbit-Anwendungen und der Harmony-Plattform erfolgt über Jitterbit-Microservices. Alle Benutzer müssen sich bei Harmony authentifizieren und die gesamte Kommunikation wird sicher über HTTPS übertragen.

Der Benutzerzugriff auf Jitterbit-Anwendungen wird durch eine Kombination aus Organisationsrolle-Berechtigungen und Umgebungszugriffsebenen weitere kontrolliert, wie in Authentifizierung, Berechtigungen und Zugriff beschrieben.

Integrations-Designer

Zum Erstellen, Konfigurieren, Bereitstellen und Testen von Jitterbit iPaaS-Integrationsprojekten können entweder Studio (empfohlen) oder Design Studio verwendet werden:

  • Studio ist eine Harmony-Portal-Webanwendung.
  • Design Studio ist eine Desktop-Anwendung, die auf einer Windows- oder macOS-Workstation mit Internetzugriff installiert werden muss.

Die Kommunikation über Unternehmens-Proxy-Server wird vollständig unterstützt, ebenso wie IP-Allowlisting (Whitelisting), um bei Bedarf die Einhaltung des Unternehmens-VPN zu gewährleisten.

Beide Anwendungen nutzen die Harmony-Plattform und profitieren von Harmony-Sicherheitsfunktionen, einschließlich Single Sign-On, Benutzerrollen und Organisationsberechtigungen sowie Umgebungszugriffsebenen.

Die Rolle eines Harmony-Benutzers muss mindestens Lesezugriff in einer Umgebung haben, um auf Projekte in Studio oder Design Studio zuzugreifen. Höhere Stufen des Umgebungszugriffs gewähren zusätzliche Berechtigungen (siehe Authentifizierung, Berechtigungen und Zugriff).

API Manager

API Manager ist eine Harmony-Portal-Webanwendung, in der Benutzer benutzerdefinierte APIs, OData-APIs und Proxy-APIs erstellen, steuern und nutzen können.

Jitterbit bietet eine Reihe von Optionen zum Sichern von APIs:

  • Sicherheitsprofile ermöglichen es, dass eine veröffentlichte API nur von einem bestimmten API-Consumer oder einer Gruppe von Consumern genutzt werden kann. Du definierst die Authentifizierungsmethode im Sicherheitsprofil und wählst zwischen anonymer, grundlegender, OAuth 2.0 oder API-Key-Authentifizierung.

  • Der SSL-only-Modus beschränkt HTTP-Datenverkehr auf verschlüsselte Kommunikation. Die Identität der HTTPS-URL wird durch eine Symantec Class 3 Secure Server SHA256 SSL CA überprüft. Die Verbindung zur HTTPS-URL wird mit moderner Kryptografie verschlüsselt (mit TLS 1.2-Verschlüsselung wird die Verbindung mit AES_128_GCM verschlüsselt und authentifiziert und verwendet ECDHE_RSA als Schlüsselaustausch-Mechanismus).

  • API-Protokolle erfassen das Sicherheitsprofil, das für jeden API-Request zum Zugriff auf die API verwendet wird.

Eine Harmony-Benutzerrolle muss entweder die Organizationsberechtigung Admin haben oder eine Kombination aus der Organizationsberechtigung Read mit mindestens Read-Zugriff in einer Umgebung haben, um auf API Manager zuzugreifen.

Das API-Portal für einzelne APIs oder API-Gruppen kann auch von externen Benutzern aufgerufen werden, die von einem Harmony-Organization-Administrator eingeladen wurden.

App Builder

App Builder ist ein Low-Code-Visual-Application-Builder zum Erstellen von unternehmensgerechten Web- und Mobilanwendungen.

Der Zugriff auf eine konfigurierte App Builder-Instanz ist über das Harmony-Portal verfügbar. Eine Harmony-Benutzerrolle mit der Organizationsberechtigung Admin ist erforderlich, um den Zugriff für Benutzer mit einer Harmony-Benutzerrolle von mindestens Read-Berechtigung zu konfigurieren.

Innerhalb von App Builder werden die folgenden zusätzlichen Sicherheitsoptionen unterstützt:

  • HTTPS: Wenn HTTPS aktiviert ist, werden Cookies mit dem Flag Secure gesetzt. Dies verhindert, dass der Browser das Cookie über einen unsicheren (HTTP) Kanal übermittelt. Cookies werden standardmäßig mit dem Flag HttpOnly gesetzt. Das Flag HttpOnly mindert Cross-Site-Scripting-(XSS-)Angriffe.

  • Single Sign-On (SSO): Die Authentifizierung kann an einen SSO-Anbieter delegiert werden. App Builder unterstützt verschiedene Industriestandards, darunter SAML SSO und WS-Federation. Diese verwenden die PKCS #1-Digitalsignaturspezifikation mit SHA-256-Digests.

  • Claims-basierte Authentifizierung: Benutzerauthentifizierungsanbieter übergeben Claims an App Builder. Sicherheitsadministratoren ordnen die Claims Benutzerattributen zu, einschließlich Gruppenmitgliedschaft.

  • Lokale Authentifizierung: Lokale Authentifizierung kann verwendet werden, um sich mit einem in App Builder gespeicherten Passwort unter Verwendung der PBKDF2-Schlüsselableitungsfunktion mit SHA-256-Hash-Algorithmus, einer Schlüssellänge von 16 Bytes, einer Salz-Länge von 16 Bytes und 10.000 Iterationen zu authentifizieren. Sicherheitsfunktionen umfassen Passwortrichtlinien, Passwortablauf, Kontosperrung und Passwort-Zurücksetzen.

  • Sitzungen: Sitzungs-Speicherrichtlinien sind konfigurierbar. Standardmäßig speichert App Builder Sitzungsinformationen in der Datenbank. Administratoren können Sitzungen anzeigen und Benutzersitzungen erzwungenermaßen abmelden. Das Verfolgen von Sitzungen schützt vor bestimmten Sicherheitslücken, z. B. vor Cookie-Replay-Angriffen.

  • Rollengestützte Sicherheit: Der Zugriff auf Daten kann über die Gruppenmitgliedschaft eines Benutzers gesteuert werden, die die Rollen des Benutzers bestimmt, die Berechtigungen für Geschäftsdaten bestimmen. Realms ermöglichen Administratoren, administrative Aufgaben wie Benutzerbereitstellung und Gruppenmitgliedschaft zu delegieren.

EDI

EDI ist eine Harmony-Portal-Webanwendung zur Verwaltung von EDI-Handelspartnern und den mit ihnen durchgeführten Transaktionen.

Die EDI-App verarbeitet EDI-Daten in der Harmony-Cloud. (Jitterbit bietet ein separates Angebot zur lokalen Verarbeitung von EDI-Daten.)

Personenbezogene Informationen (PII) werden standardmäßig maskiert. Ein Harmony-Administrator kann die PII-Daten in der EDI-App für bis zu 24 Stunden verfügbar machen, danach werden sie erneut maskiert.

Die EDI-App bietet auch die Möglichkeit, personenbezogene Daten eines Handelspartners zu verwalten, indem man diese aus Partnerdokumenten entfernt.

Eine Harmony-Benutzerrolle mit der Organisationsberechtigung Admin ermöglicht den Zugriff auf alle Bearbeitungs- und Aktionsfunktionen in der EDI-App.

Die EDI-spezifischen Rollen EDI Viewer oder EDI User bieten präzisere Zugriffsmöglichkeiten auf EDI-Seiten und -Funktionen.

Marketplace

Marketplace ist eine Harmony-Portal-Webanwendung, die Zugriff auf mehr als 400 Integrations-Rezepte und Prozessvorlagen bietet, die in eine Umgebung importiert werden können, um sie als Grundlage für Studio-Integrationsprojekte zu nutzen.

Eine Harmony-Benutzerrolle mit der Organisationsberechtigung Read oder Admin ermöglicht den Zugriff auf Rezepte und Vorlagen im Marketplace. Um ein Rezept oder eine Vorlage in einer Umgebung zu starten, ist Write-Zugriff in dieser Umgebung erforderlich.

Management Console

Management Console ist eine Harmony-Portal-Webanwendung zur Verwaltung und Überwachung der Harmony-Organisation im gesamten Harmony-Portal sowie der Komponenten der Harmony-Plattform selbst.

Die Verwaltung der Organisation umfasst die Konfiguration von Organisationsrichtlinien, einschließlich Single Sign-On (SSO), und die Festlegung, wer auf verschiedene Bereiche der Jitterbit-Anwendungen zugreifen kann (siehe Authentifizierung, Berechtigungen und Zugriff).

Die Management Console vereinfacht verschiedene andere Verwaltungsaufgaben, die typischerweise von einem Harmony-Administrator durchgeführt werden:

  • Umgebungen, Agenten und Agentgruppen für die Verwendung mit Studio- oder Design-Studio-Integrationsprojekten einrichten.
  • Zeitpläne, Variablen, Listener und Sicherungen für Integrationsprojekte verwalten.
  • Externen Benutzerzugriff auf das API Portal verwalten.
  • Zugriffstokens für die Verbindung der EDI-App mit Studio konfigurieren.
  • Nachrichtenwarteschlangen hinzufügen, die mit Studio verwendet werden sollen.

Die Management Console liefert auch Informationen zur Überwachung der Organisation:

  • Audit-Protokoll mit Informationen darüber, wer welche Aktivitäten in der Organisation durchgeführt hat.
  • Vorgangsprotokolle und Bereitstellungsverlauf für Studio- und Design-Studio-Integrationsprojekte.

Eine Harmony-Benutzerrolle mit der Organisationsberechtigung Read hat Zugriff auf die Seite Dashboard, während die Berechtigung Admin Zugriff auf alle Management-Console-Seiten sowie die Möglichkeit zur Bearbeitung und Durchführung von Aktionen hat.

Eine Benutzerrolle mit der Berechtigung Read kann auf weitere Management-Console-Seiten zugreifen, wenn Zugriffsstufen für Umgebungen wie in Authentifizierung, Berechtigungen und Zugriff beschrieben gewährt werden. Das Zugriffskontrollschichten-Modell, das für jede Umgebung definiert ist, ist präzise, sodass die Konfigurationen, die Benutzer sehen und mit denen sie interagieren können, von den Zugriffskontrollrechten des Benutzers abhängen. Zugriffskontrollrechte werden auf alle Funktionen angewendet, einschließlich der Suche nach Vorgängen, des Ausführens von Vorgängen, des Anzeigens von Protokollen usw.

Eine Benutzerrolle mit der Berechtigung User Manager kann Nicht-Admin-Benutzer und -Rollen hinzufügen, bearbeiten oder löschen, kann aber keinen Benutzer von Nicht-Admin zu Admin ändern. Sie können auch externe Benutzer verwalten. Benutzer mit nur der Berechtigung User Manager sehen nur die Seite User Management in der Management-Console-Navigation, und Rollen mit nur dieser Berechtigung haben deaktivierte Umgebungsrollenzugriffe.

Wiederverwendbare Assets

Wiederverwendbare Assets umfassen Konnektoren, Anwendungen und Integrationsprojekte sowie die Tools zu ihrer Erstellung:

  • Connector SDK: Das Jitterbit Connector SDK (Software Development Kit) bietet Entwicklern die Möglichkeit, Konnektoren zu erstellen und sie in Studio verfügbar zu machen.
  • Connector Builder: Jitterbit Connector Builder ist ein Low-Code-Assistent für jeden, um einen Studio-Konnektor zu erstellen, der eine über HTTP zugängliche REST-API bereitstellt.
  • Vorgefertigte Konnektoren: Jitterbit und seine Partner stellen Hunderte von vorgefertigten Studio-Konnektoren zur Verwendung in Integrationsprojekten bereit.
  • Vorgefertigte Anwendungen: Jitterbit bietet vorgefertigte Web- und native mobile Apps durch App Builder.
  • Vorlagen: Vorgefertigte bidirektionale Integrationslösungen, die einen komplexen Anwendungsfall lösen, werden über Marketplace bereitgestellt.
  • Rezepte: Unidirektionale Integrationsprojekte, die einen einfachen Anwendungsfall lösen, werden über Marketplace bereitgestellt.
  • AI-Agenten: Vorgefertigte Agenten, die verwendet werden können, um Ihre Ziele autonom ohne direkte menschliche Aufsicht zu erreichen, werden über Marketplace bereitgestellt.

Microservices

Jitterbit-Anwendungen kommunizieren mit der Harmony-Plattform über einen klar definierten Satz von Harmony-Plattform-APIs, die als Jitterbit-Microservices bezeichnet werden.

Die APIs werden mit der gleichen sicheren Codierungsstrenge entwickelt wie Harmony selbst (siehe Entwicklungsprozesse).

Alle Benutzer dieser APIs müssen sich bei Harmony authentifizieren und die gesamte Kommunikation wird sicher über HTTPS übertragen.

Plattform-Engines

Die Harmony-Plattform bietet die gesamte Infrastruktur und Dienste zum Bereitstellen, Verwalten und Ausführen von Integrationsprojekten, zum Erstellen von benutzerdefinierten Web- und nativen Mobile-Apps, zum Erstellen, Steuern und Verbrauchen von APIs sowie zum Verarbeiten von EDI-Transaktionen.

API-Gateways

Ein API-Gateway ist ein Dienst, der die Richtlinien und Sicherheitsprofile erzwingt, die auf APIs mit der Webanwendung API Manager erstellt werden. Die Konnektivität zu APIs, die über API Manager veröffentlicht werden, wird entweder über das Cloud-API-Gateway von Jitterbit oder ein privates API-Gateway ermöglicht.

Die API-Gateways handhaben diese Sicherheitsaufgaben beim Akzeptieren und Verarbeiten von Aufrufen an eine API:

  • Datenverkehrsmanagement
  • Autorisierung und Zugriffskontrolle
  • Ratenbegrenzung
  • API-Payload-Verarbeitung

Sicherheitsfunktionen werden auf API-Ebene oder Sicherheitsprofilebene konfiguriert und im API-Gateway zwischengespeichert, auf das dann während der API-Laufzeit verwiesen wird.

Das Cloud-API-Gateway von Jitterbit wird von Jitterbit verwaltet, gepflegt und gehostet und erfordert keine Konfiguration.

Ein privates API-Gateway ist ein lokales Gateway zur direkten Verarbeitung von APIs von den eigenen Servern. Ein privates API-Gateway kann auf ein internes Netzwerk hinter einer Firewall beschränkt werden und nicht vom Internet aus erreichbar sein, wobei bestimmte Jitterbit-Services auf die Allowlist gesetzt werden müssen (auf die Whitelist). Bei einem privaten API-Gateway durchlaufen API-Response-Payloads niemals die Systeme von Jitterbit.

Messaging

Die Kommunikation zwischen verschiedenen Jitterbit-iPaaS-Komponenten wie Studio, Agenten und der Harmony-Plattform wird durch einen Satz sicherer Laufzeit-Messaging-Dienste ermöglicht, die auf der Java Messaging Services (JMS)-API basieren und in der Java Platform enthalten sind. Diese APIs sind intern in Harmony vorhanden, und Kunden haben keinen Zugriff auf diese APIs.

Agenten enthalten Listener für den JMS-Messaging-Dienst. Alle Agenten, die auf Anfragen warten, authentifizieren sich stark und erhalten eine autorisierte Sitzung im Harmony-Messaging-Netzwerk. Sie können nur auf Anfragen für ihre bestimmten Agent-Gruppen oder auf Anfragen warten, die direkt über Harmony an sie gestellt werden. Nachrichten werden niemals an Agenten gesendet; Agenten rufen sie immer über HTTPS ab. Dies ermöglicht Agenten, hinter Firewalls zu laufen und geschützt zu bleiben, ohne dass Ports geöffnet werden müssen, die eingehenden Datenverkehr aus dem Internet erlauben würden.

Agenten

Die in Studio und Design Studio-Projekten entworfenen Integrationsprozesse werden auf Agenten mit entweder einer Jitterbit-Cloud-Agent-Gruppe oder privaten Agenten und einer privaten Agent-Gruppe ausgeführt.

Diese Prozesse können vollständig in der Cloud ausgeführt werden, ohne dass Software oder die erforderliche Infrastruktur für deren Betrieb beschafft oder verwaltet werden müssen. Diejenigen, die Agenten lokal oder in einem Hybrid-Modus bereitstellen, haben die Flexibilität, ihre Integrationsprozesse durch die Bereitstellung privater Agenten hinter der Firewall auszuführen und erhalten so mehr Kontrolle darüber, wie ihre Daten fließen.

Jitterbit erkennt an, dass Kunden benötigen, dass ihre Integrationsprozesse mit Anwendungen kommunizieren, die aus verschiedenen Sicherheits- und Compliance-Gründen hinter Firewalls von Unternehmen ausgeführt werden.

Die Systemarchitektur von Harmony berücksichtigt beide Szenarien: Integrationsprozesse können vollständig in der Cloud ausgeführt werden oder können hinter Firewalls von Unternehmen ausgeführt werden, um sicherzustellen, dass Geschäftsdaten nicht der Cloud ausgesetzt werden. Benutzer können auch Hybrid-Modelle einsetzen, bei denen einige Integrationen in der Cloud wie Entwicklung ausgeführt werden und andere beispielsweise in der Produktion hinter Firewalls von Unternehmen ausgeführt werden können.

Während das System die Bereitstellung, Implementierung und Verwaltung von Integrationsprojekten vereinfacht, bietet es Benutzern auch die Flexibilität, ihre Integrationsvorgänge mit abnehmbaren privaten Agent-Gruppen auszuführen. Dies sind in sich geschlossene Subsysteme, die hinter Unternehmensfirewalls oder in dedizierten privaten Clouds installiert werden können.

Die Trennung von Integrationsentwürfen, die in Harmony gespeichert sind, von der Integrationslaufzeit, die in Agent-Gruppen stattfindet, ermöglicht es Kunden, den Zugriff und den Fluss sensibler Geschäftsdaten zu kontrollieren.

Cloud-Agent-Gruppe

Cloud-Agenten sind Services, bekannt als Backend as a Service (BaaS), die dazu konzipiert sind, Client-Anforderungen ad hoc zu verarbeiten und zu bedienen. Sie führen ihre gesamte Arbeit ereignisgesteuert aus und eliminieren damit die Notwendigkeit für die Einrichtung, Konfiguration oder Verwaltung, die bei traditionellen „Always-On"-Serversystemen hinter Anwendungen erforderlich ist.

Jitterbit bietet seinen Kunden die Möglichkeit, alle ihre Integrationen in der Cloud auszuführen, indem es eine skalierbare, fehlertolerante, gruppierte Agent-Gruppe bereitstellt, die vollständig von Jitterbit verwaltet und gepflegt wird.

Um die Sicherheit zu erhöhen und den Datenschutz zu gewährleisten, sind Jitterbit-Cloud-Agenten so codiert, dass lokal verarbeitete Daten nicht persistent sind. Sie werden für die minimale Zeit verwendet, die zur Durchführung des vorgesehenen Prozesses erforderlich ist, und dann gelöscht.

Wenn die Jitterbit-Cloud-Agent-Gruppe eine Integration durchführt, verbindet sie sich direkt mit der Anwendung, die eine Datenintegration erfordert. Sie liest dann Daten aus diesen Anwendungen und schreibt Daten in diese Anwendungen.

Metadaten, die in der Jitterbit-Cloud-Agent-Gruppe persistent gespeichert werden, werden in verschlüsselten Amazon-S3-Buckets gespeichert, auf die nur die Agent-Gruppe zugreifen kann.

Für Kunden, deren Anwendungen sich in ihrer Firewall befinden müssen, oder für Benutzer, die Integrationen unter strenger behördlicher Compliance durchführen, die verbietet, dass Daten entweder eine geografische Grenze verlassen oder in der Cloud gespeichert werden, empfiehlt Jitterbit die Verwendung einer privaten Agent-Gruppe.

Private Agenten und private Agent-Gruppe

Jitterbit bietet die Flexibilität für Kunden, ihre eigenen Agent-Gruppen und privaten Agenten in ihrer Unternehmensfirewall oder in virtuellen privaten Clouds bereitzustellen und zu verwalten. Dies ermöglicht es Kunden zu wählen, wo ihre Integrationslaufzeitumgebung betrieben wird, und ermöglicht es ihnen zu kontrollieren, über welches Netzwerk ihre Geschäftsdaten übertragen und gespeichert werden. Durch die Verwendung privater Agent-Gruppen für Integrationen können Unternehmen sicherstellen, dass ihre sensiblen Geschäftsdaten niemals durch die Harmony-Plattform fließen.

Agenten, die zu privaten Agent-Gruppen gehören, authentifizieren sich und kommunizieren mit Jitterbit Harmony über HTTPS. Private Agent-Gruppen, die hinter Unternehmensfirewalls bereitgestellt werden, können so konfiguriert werden, dass sie über einen Unternehmens-Proxy-Server kommunizieren. Falls Ihr Unternehmen ausgehende Verbindungen nicht einschränkt, gibt es keine zusätzlichen Netzwerkanforderungen wie das Öffnen von Ports in Unternehmensfirewalls. Wenn ausgehende Verbindungen eingeschränkt sind, müssen Sie bestimmte Jitterbit-Services auf die Allowlist (Whitelist) setzen.

Private-Agent-Code wird mit derselben Coding-Genauigkeit erstellt wie Harmony-Code (siehe Entwicklungsprozesse).

Obwohl private Agent-Gruppen strenge Sicherheitsanforderungen erfüllen, ist der Benutzer oder Kunde für die Installation und Verwaltung seiner privaten Agenten verantwortlich. In der Cloud-Agent-Gruppe bietet Jitterbit sofort einsatzbereites intelligentes Routing, hohe Verfügbarkeit und Skalierbarkeit, die der Erwartung an eine serverlose Technologie entspricht. In privaten Agent-Gruppen liegt die Sicherheit und Skalierbarkeit für private Agenten jedoch in der Verantwortung des Kunden (obwohl hohe Verfügbarkeit von der Harmony-Plattform weiterhin gewährleistet wird, wenn mehr als ein Agent in einer privaten Agent-Gruppe verwendet wird). Jitterbit bietet Best-Practice-Ratschläge für das Hosten von Private-Agent-Code in Systemanforderungen für private Agenten.

Listening Service

Der Listening Service ist ein Anwendungsservice, der auf einem privaten Agent ausgeführt wird und von bestimmten Studio-Connectoren mit Listening-Funktionen genutzt wird. Der Listening Service bietet asynchrone Ereignisverarbeitungsfunktionen für auf dem Agent bereitgestellte Operationen.

listening service system architecture

  1. Ein Operation mit einem Connector, der mit einer Event-Listening-Aktivität konfiguriert ist, wird bereitgestellt und zum Abhören aktiviert.
  2. Der Listening Service im Agent startet einen Listener für diese Operation.
  3. Der Listener beginnt aktiv, Event-Benachrichtigungen vom Endpoint zu abhören.
  4. Wenn ein Event am Endpoint auftritt, veröffentlicht dieser eine Event-Benachrichtigung, die von seinen Abonnenten empfangen werden kann.
  5. Der Listener empfängt die Event-Benachrichtigungsmeldung.
  6. Wenn sich ein Agent in der Agent-Gruppe befindet, leitet der Listener die Event-Meldung an die Operation weiter. Wenn die Agent-Gruppe die Mindestanzahl für vollständige Listening-Service-Funktionen enthält, wird die Event-Meldung an den Agent mit der geringsten Arbeitslast weitergeleitet.
  7. Nach dem Empfang der Event-Benachrichtigung löst die Operation eine nachgelagerte Operation aus.

Transaktionsprotokolle

Transaktionsprotokolle, auch als Operation Logs bezeichnet, sind die Protokolle, die bei der Ausführung einer Studio- oder Design-Studio-Operation generiert werden. Sie enthalten Informationen zur Operation, einschließlich ihres Speicherorts, des Zeitraums und des Status.

Die Cloud-Protokollierung bestimmt, ob Protokolldaten vorübergehend gespeichert und über die Harmony Cloud zugänglich sind. Wenn die Cloud-Protokollierung aktiviert ist, enthalten die Protokolle für Operations auch detaillierte Protokollmeldungen. Die Cloud-Protokollierung ist immer für Jitterbit Cloud Agent-Gruppen aktiviert und kann optional für Private Agenten deaktiviert werden.

Operation Logs, einschließlich detaillierter Protokollmeldungen von Cloud Agenten und Private Agenten sowie Komponenteneingabe- und -ausgabedaten innerhalb von Operation Logs, werden 30 Tage lang aufbewahrt.

Design-Repository

Jitterbit speichert alle in Harmony bereitgestellten Projekte in einem mandantenfähigen Design-Repository. Dieses Projekt-Repository basiert auf einer mandantenfähigen Datenbankarchitektur, die eine logische Aufteilung von Projekten nach Organisation und in den meisten Fällen nach Umgebung ermöglicht. Insbesondere isoliert und sichert Harmony Kundenprojekte mit Folgendem:

  • Sichere Datenbankarchitektur: Umfasst getrennte Datenbank- und getrennte Schema-Architektur.
  • Sichere Verbindungen oder Tabellen: Nutzt vertrauenswürdige Datenbankverbindungen.
  • Verschlüsselung: Verdeckt kritische Daten, damit diese für unbefugte Parteien unzugänglich bleiben, auch wenn diese in deren Besitz gelangen.
  • Filterung: Nutzt eine Zwischenschicht zwischen einem Mandanten und einer Datenquelle, die wie ein Sieb fungiert und dem Mandanten suggeriert, dass nur seine Daten in der Datenbank vorhanden sind.
  • Zugriffssteuerungslisten: Bestimmt, wer auf Daten in der Anwendung zugreifen kann und was er damit tun kann.

Projekte enthalten typischerweise Anmeldeinformationen wie Benutzername und Passwort, die zum Herstellen von Verbindungen zu verschiedenen Endpoints verwendet werden. Diese Informationen werden im mandantenfähigen Repository verschlüsselt.

Das Repository wird für jede Harmony-Region (NA, EMEA und APAC) in zwei Regionen (z. B. East und West) repliziert.

Kunden haben keinen direkten Zugriff auf dieses Repository. Die verschiedenen Jitterbit iPaaS-Komponenten, wie Integration Designer und Cloud Agenten, verwenden APIs für den Zugriff auf das Repository. Nach Authentifizierung und Validierung der Zugriffskontrolle erfolgt die gesamte Kommunikation mit dem Repository über verschiedene API-Schichten. Zusätzlich zur Kontrolle des Edge-API-Zugriffs über HTTPS und serverseitige Sitzungen müssen APIs den Benutzerzugriff durch umgebungsbasierte und rollenbasierte Zugriffskontrolllisten (RBAC) validieren. Diese Listen stellen sicher, dass Benutzer das System basierend nur auf den Berechtigungen, die ein Organisationsadministrator (Benutzer mit Admin-Berechtigung) gewährt hat, anzeigen, bearbeiten und ändern können. Darüber hinaus ist die Granularität der Audit-Trail pro Kunde konfigurierbar.

Die Harmony Rotating Activity Database speichert Laufzeit-Statusinformationen sowie Protokolle ausgeführter Operations aller Harmony-Benutzer.

Die Activity Database basiert auf einer mandantenfähigen Architektur, und während Activity Data für alle Benutzer in derselben Datenbank vorhanden sind, gibt es eine logische Segmentierung nach Organisation und Umgebung, die durch eine Software-Zugriffssteuerungsschicht und eindeutige Verschlüsselungsschlüssel angewendet wird, um sicherzustellen, dass Benutzer nur Activities anzeigen können, auf die sie Zugriff haben.

Die Aktivitätsdatenbank wird über AWS-Regionen und Verfügbarkeitszonen hinweg repliziert, um hohe Verfügbarkeit zu gewährleisten, und wird gesichert, falls sie wiederhergestellt werden muss.

Der Zugriff auf die Aktivitätsdatenbank erfolgt über eine Reihe von APIs. Das Aktivitätsprotokoll nutzt ähnliche APIs und die Zugriffssteuerungsliste (ACL) wie das Projekt-Repository.

Dateidienste

Harmony umfasst einen Satz von Dateidiensten zum Speichern von Dateien wie Schemas und Anpassungen. Alle Dateien werden im AWS S3-Dienst gespeichert und können nur über die Harmony-Plattform aufgerufen werden. Ein direkter Zugriff ist nicht möglich.

Schema-Repository

Um Integrationen von verschiedenen Endpoints zu unterstützen, speichert Harmony verschiedene Schematypen wie WSDL, XSD, JTR und DTDs.

Neben dem Speicher im Harmony-Cloud-Datenspeicher werden Studio-Schemas im Design-Repository gespeichert, um die Wiederverwendbarkeit von Schemas innerhalb eines Projekts zu verwalten.

Anpassungen-Repository

Um Integrationen von verschiedenen Datenbank-Endpoints zu unterstützen, speichert Harmony verschiedene JDBC- und ODBC-Treiber, einschließlich derjenigen, die Kunden selbst auf privaten Agenten installieren.

Um die Funktionen von Studio zu erweitern, können Sie eigene benutzerdefinierte Konnektoren mit Connector Builder oder dem Connector SDK erstellen.

Backend-Dienste

Backend-Dienste sind die zugrunde liegenden Dienste und APIs von Harmony, über die alle Daten fließen.

Backend-Dienste verarbeiten Aufgaben wie Anmeldung, Benutzerverwaltung, Bereitstellung, Planung, Organisationsverwaltung usw.

App Builder-Laufzeitumgebung

App Builder-Lösungen können in den folgenden Bereitstellungskonfigurationen ausgeführt werden:

  • Lokal: Die App Builder-Umgebung wird vor Ort am Kundenstandort bereitgestellt. Die Web- und Datenbankserver sowie die App Builder-Umgebung befinden sich alle auf Kundenhardware im Kundennetzwerk. Diese Option bietet vollständige Kontrolle und Flexibilität über die App Builder-Umgebung und Infrastruktur. Alle Wartungs-, Sicherheits-, Hardware- und Softwareoperationen werden vom Kunden verwaltet.

  • Private Cloud: Die App Builder-Umgebung wird bei einem privaten Cloud-Anbieter des Kunden bereitgestellt – entweder AWS, Google Cloud Platform (GCP) oder Microsoft Azure. Die Web- und Datenbankserver sowie die App Builder-Umgebung befinden sich in der privaten Cloud. Diese Option bietet Flexibilität und Kontrolle über die App Builder-Umgebung und Infrastruktur. Alle Wartungs-, Sicherheits-, Hardware- und Softwareoperationen werden vom Kunden verwaltet.

B2B-Laufzeitmodul

EDI-Transaktionen werden über die EDI-Cloud-Laufzeitumgebung verarbeitet, auch eiCloud genannt.

Nach dem Generieren einer Transaktion wird diese in der Transaktionsdatenbank gespeichert, während sie auf die Verarbeitung wartet. Das EDI-Dokument bleibt bestehen, bis es mit den für den Handelspartner festgelegten Archivierungseinstellungen archiviert wird. Der Status eines EDI-Dokuments kann jederzeit auf der Seite EDI-Transaktionen überprüft werden.

Es werden Standard-EDI-Kommunikationsprotokolle unterstützt, wie FTP/SFTP, HTTP/HTTPS, AS2, benutzerdefinierte Pipes usw.

Es werden Standard-EDI-Formate unterstützt, einschließlich ANSI X12 (inkl. VICS), EDIFACT und deren Untergruppen sowie Tradacoms. Transaktionen werden mit EDIXml, dem empfohlenen Austauschformat für neue Workflows, oder mit dem älteren XCBL-Format verarbeitet.

Nachrichtensystem

Der Message Queue (MQ)-Dienst ist ein Cloud-basierter Multi-Tenant-Nachrichtenwarteschlangendienst zur Erstellung und Verwaltung von Warteschlangen und Nachrichten. Damit können Sie Integrationen erstellen, die von den zu integrierenden Endpoints entkoppelt sind. Der MQ-Dienst wird mit dem Studio-Jitterbit MQ-Konnektor verwendet.

message queue system architecture

  1. Daten werden von einem Quell-Endpoint abgerufen, z. B. mithilfe eines Studio-Konnektors. Die abgerufenen Daten können dann in eine Nachricht umgewandelt werden, die vom Jitterbit MQ-Konnektor verwendet wird.

  2. Mit der Jitterbit MQ Send- oder Send Bulk-Aktivität werden die Daten an den Jitterbit Message Queue-Service gesendet (der die Nachrichten an die angegebene Nachrichtenwarteschlange sendet).

  3. Nachrichten können dann mit einer Jitterbit MQ Get- oder Get Bulk-Aktivität aus einer Nachrichtenwarteschlange abgerufen werden.

  4. Aus einer Nachricht abgerufene Daten können dann als Eingabe verwendet werden, die von einem Zielendpunkt verarbeitet wird, z. B. durch die Verwendung eines Studio-Connectors.

  5. Nach der Verarbeitung der Daten kann die Nachricht entweder bestätigt (mithilfe der Acknowledge-Aktivität) oder negativ bestätigt werden (mithilfe der NACK-Aktivität). Wenn die Nachricht nicht bestätigt oder negativ bestätigt wird, bevor das Zeitlimit von 30 Minuten abläuft, wird die Nachricht erneut von einer Get- oder Get Bulk-Aktivität aus der Warteschlange abgerufen.

Analyse- und Logging-Engines

Die Harmony-Plattform stellt Analyse- und Logging-Informationen bereit, auf die über das Harmony-Portal oder direkt auf privaten Agent-Servern zugegriffen werden kann.

Entwicklungsprozesse

Jitterbit entwickelt und verbessert seine Anwendungen durch bewährte Software-Development-Lifecycle-(SDLC-)Praktiken wie:

  • Identifizierung von Schwachstellen aus externen Quellen, um Veränderungen und Codeverbesserungen voranzutreiben.
  • Anwendung von Hardware- und Software-Patches. Unsere virtuelle Umgebung ermöglicht es uns, Codeänderungen und Hardware-Patches ohne Ausfallzeiten anzuwenden.
  • Bereitstellung von sicherer Authentifizierung und Logging-Funktionen.
  • Entfernung von Entwicklungskonten, IDs und Passwörtern aus Produktionsumgebungen.
  • Einhaltung strikter Change-Management-Praktiken für Code-Updates und Patches.
  • Trennung von Test- und Entwicklungsumgebungen von der Produktion.
  • Aufrechterhaltung der Aufgabentrennung zwischen Entwicklungs- und Supportpersonal.
  • Sicherstellung, dass persönlich identifizierbare Informationen (PII) nicht in Test-Umgebungen verwendet werden.
  • Entfernung von Test- und Entwicklungs-IDs vor der Migration von Code in die Produktion.
  • Regelmäßige Code-Reviews.
  • Dokumentation von Code-Änderungen.
  • Einholung von Input und Genehmigung von Senior Developern für alle Code-Änderungen.
  • Durchführung von Funktions- und Regressionstests vor der Freigabe für die Produktion.
  • Aufrechterhaltung von Backout-Verfahren zur Sicherung von Hochverfügbarkeit und Integrität.
  • Befolgung sicherer Coding-Praktiken gemäß einer SDLC-Richtlinie und Erfüllung der Schulungsanforderungen für Cybersicherheit des Entwicklungsteams.
  • Überprüfung auf Sicherheitsmängel wie vom Open Web Application Security Project (OWASP) vorgegeben, z. B. Injection Flaws, Buffer Overflows, kryptographische Fehler, Error Handling usw.
  • Bewertung auf Schwachstellen bei jeder Freigabe.
  • Durchführung von jährlichen Penetrationstests.

Authentifizierung, Berechtigungen und Zugriff

Bevor ein Benutzer seine Arbeit beginnen kann, muss er sich bei Harmony mit seinem Benutzerkonto authentifizieren. Dieses Konto hat rollenbasierte Berechtigungen in der Harmony-Organisation. Diese Rollen können verschiedene Zugriffsebenen in einzelnen Umgebungen zugewiesen bekommen.

Registrierung und Authentifizierung

Um die Harmony-Plattform zu nutzen, muss sich ein Benutzer mit seinem Benutzerkonto registrieren und authentifizieren.

Die Passwortstärke, -komplexität und Attribute wie Zwei-Faktor-Authentifizierung sind anpassbar, damit Kunden die Anforderungen ihrer Sicherheitsrichtlinie erfüllen können. Administratoren können auch den Zugriff auf angegebene Memberdomänen beschränken oder verlangen, dass IP-Adressen von Benutzern in einem bestimmten Bereich liegen. Diese Einstellungen werden in den Richtlinien einer Organisation festgelegt. Wenn ein Benutzer Mitglied mehrerer Organisationen ist, werden die strengsten Richtlinien aller Organisationen, deren Mitglied er ist, bei der Anmeldung wirksam.

Nach 5 fehlgeschlagenen Anmeldeversuchen mit Harmony-Kontoanmeldedaten werden Konten 30 Minuten lang gesperrt. Benutzer werden per E-Mail benachrichtigt, wenn ein fehlgeschlagener Anmeldeversuch auf eine Kontosperrung zurückzuführen ist. Wenn ein Benutzer gesperrt ist, wird sein Status auf der Seite Management Console > User Management auf der Registerkarte Harmony Users als Inactive angezeigt. Um die Sperrung aufzuheben, muss der Benutzer 30 Minuten warten, bevor er sich erneut mit seinem vorhandenen Passwort anmeldet, oder sein Passwort über den Link I forgot my password auf der Harmony-Portal-Anmeldeseite zurücksetzen. Passwörter können nicht wiederverwendet werden. Wenn eine Passwortänderung aus irgendeinem Grund fehlschlägt, z. B. weil das Passwort zuvor verwendet wurde, wird aus Sicherheitsgründen eine generische Fehlermeldung zurückgegeben.

Wenn Single Sign-On (SSO) für einen Benutzer aktiviert ist, werden diese Anforderungen stattdessen vom Identitätsanbieter verwaltet. Diese Kontrollen gelten für Benutzer auf der Liste Bypass SSO des Unternehmens, die sich mit Harmony-Anmeldedaten authentifizieren. SSO wird auch von einem Administrator über die Richtlinien eines Unternehmens aktiviert. Jitterbit unterstützt diese großen Identitätsanbieter:

  • Autodesk (OAuth 2.0)
  • Azure Active Directory (SAML 2.0)
  • BMC (nur für BMC-Kunden) (OAuth 2.0)
  • Google (OAuth 2.0)
  • Okta (SAML 2.0)
  • Salesforce (OAuth 2.0 und SAML 2.0)

Wenn SSO für ein Unternehmen aktiviert ist, melden sich Benutzer beim Harmony-Portal und in Design Studio mit den Anmeldedaten ihres konfigurierten Identitätsanbieters an.

Die gesamte Kommunikation mit Harmony erfolgt über HTTPS (größer als TLS 1.2).

Benutzerrollen und Organisationsberechtigungen

Jeder Harmony-Benutzer hat sein eigenes persönliches, rollenbasiertes Konto und Anmeldedaten, unter denen persönliche Integrationswerkzeuge und Projekte sicher gespeichert werden.

Nach der Authentifizierung erkennt Harmony alle Organisationen und Umgebungen, auf die dieser Benutzer Zugriff hat. Harmony stellt dem Benutzer eine Liste der Assets zur Verfügung, an denen er arbeiten kann, und ermöglicht es dem Benutzer, Assets in jeder Umgebung zu erstellen, in der er über ausreichende Berechtigungen verfügt.

Berechtigungen sind rollenbasiert und können pro Umgebung pro Organisation ausgewählt/konfiguriert werden. Jede Organisation hat zwei Standardrollen:

  • Administrator: Eine Rolle namens Administrator, deren Berechtigung Admin Zugriff auf alle Assets der Organisation ermöglicht.
  • User: Eine Rolle namens User, deren Berechtigung Read Zugriff auf das Harmony-Portal und andere Bereiche mit minimalem Zugriff bietet.

Zusätzlich zu den Berechtigungen Admin und Read sind diese unabhängigen Berechtigungen verfügbar, um Rollen zugewiesen zu werden:

  • User Manager: Ermöglicht einem Benutzer, Nicht-Admin-Benutzer und Rollen zu verwalten. Er kann Nicht-Admin-Benutzer hinzufügen, bearbeiten oder löschen, kann aber keinen Benutzer von Non-Admin zu Admin ändern. Er kann auch externe Benutzer verwalten. Benutzer mit nur dieser Berechtigung sehen nur die Seite User Management in der Navigation der Management Console, und ihre Rollen haben den Umgebungsrollenzugriff deaktiviert.
  • Agent-Install: Ermöglicht einem Benutzer, Agenten zu installieren, bietet aber weder Kontrolle noch Sichtbarkeit außerhalb dieser Funktion. Dies kann verwendet werden, um Administratoren innerhalb und außerhalb des Unternehmens zu ermöglichen, zusätzliche Konnektivität ohne Auswirkungen auf die Projekte oder sogar Kenntnisse der Plattform zu etablieren.
  • ApiConsumer: In Kombination mit Umgebungszugriffsebenen bietet diese Berechtigung Zugriff auf OpenAPI-Dokumentation in einer Umgebung. Allein bietet diese Berechtigung Zugriff auf die Seite API Portal.
  • EDI User: Ermöglicht einem EDI-Benutzer, EDI-Partner, -Transaktionen und -Einstellungen zu erstellen und zu aktualisieren.
  • EDI Viewer: Ermöglicht einem EDI-Benutzer, EDI-Partner, -Transaktionen und -Einstellungen anzuzeigen.

Administratoren können neue Rollen zur Organisation hinzufügen und andere Harmony-Benutzer einladen, beizutreten, wenn sie in Teams zusammenarbeiten müssen, um ihre Projekte, APIs und EDI-Daten zu entwerfen, zu erstellen, zu testen und zu verwalten. Benutzer können mehreren Rollen innerhalb einer Organisation hinzugefügt werden.

Beziehen Sie sich auf die Tabelle Berechtigungen für Informationen über die Privilegien, die durch jede Berechtigung gewährt werden, und auf Rollen zum Erstellen zusätzlicher Rollen mit einer beliebigen Kombination von Berechtigungen.

Umgebungen und Zugriffsstufen

Umgebungen werden verwendet, um die Assets einer Organisation für diese Harmony-Anwendungen zu trennen:

  • Studio- und Design Studio-Integrationsprojekte werden in Umgebungen bereitgestellt, die mit Agent-Gruppen verknüpft sind.
  • API Manager-APIs werden in Umgebungen erstellt und veröffentlicht.
  • Trading Partner werden pro Umgebung hinzugefügt und EDI-Daten werden verarbeitet.

Umgebungen stellen einen bestimmten Zustand eines Projekts oder einer API dar. Viele Projekte befinden sich in verschiedenen Phasen innerhalb unterschiedlicher Umgebungen. Beispielsweise könnte eine typische Projekt-Lebenszykluskonifguration drei Umgebungen haben: Entwicklung, Test und Produktion. Ein Projekt oder eine API kann in verschiedenen Zuständen innerhalb jeder Umgebung vorhanden sein.

Organisationsadministratoren (Benutzer mit der Berechtigung Admin) verwalten den Zugriff auf jede Umgebung mithilfe von rollenbasiertem Zugriff. Beispielsweise können Benutzer in der Entwicklerrolle Lese-, Ausführungs- und Schreibprivilegien in der Entwicklungsumgebung haben, aber nur Lesezugriff auf die Testumgebung und keinen Zugriff auf die Produktionsumgebung.

Es gibt vier kaskadierende Umgebungszugriffsstufen:

  • Protokolle anzeigen: Ermöglicht einem Benutzer, Studio- und Design Studio-Betriebsprotokolle über die Management Console-Seite Runtime in einer bestimmten Umgebung anzuzeigen, bietet aber keine Sichtbarkeit oder Kontrolle über Projekte. Dies ermöglicht es Benutzern, Projekte zu unterstützen, aber nicht zu ändern, die in kritischen Umgebungen wie der Produktion bereitgestellt werden. Der Zugriff ist auf die Anzeige der Tabelle der Operationen beschränkt und beinhaltet keinen Zugriff auf Protokollmeldungen.

  • Lesen: Ermöglicht einem Benutzer schreibgeschützten Zugriff auf Studio- und Design Studio-Projekte sowie API Manager-APIs in einer bestimmten Umgebung. Dies kann verwendet werden, um Vorlagen freizugeben oder Benutzern das Anzeigen, aber nicht das Ändern von Assets zu ermöglichen. Diese Zugriffsstufe bietet auch schreibgeschützten Zugriff auf die Management Console-Seiten Projekte, Umgebungen und Agents.

  • Ausführen: Ermöglicht Benutzern das Ausführen von Studio- und Design Studio-Operationen und das Anzeigen von Protokollmeldungen auf der Management Console-Seite Runtime innerhalb einer bestimmten Umgebung. Dies ist eine typische Zugriffskontrolle für Testumgebungen und wird häufig Benutzern gewährt, die Projekte unterstützen müssen, da sie möglicherweise Aufgaben testen und ausführen müssen.

  • Schreiben: Ermöglicht volle Kontrolle über eine bestimmte Umgebung. Benutzer, die zu einer Rolle mit Schreiben-Zugriff gehören, können Änderungen vornehmen und Aktionen innerhalb dieser bestimmten Umgebung ausführen. Dies umfasst die Bereitstellung von Studio- und Design Studio-Operationen, das Bearbeiten und Veröffentlichen von API Manager-APIs, das Starten von Rezepten und Vorlagen vom Marketplace sowie das Ausführen von Aktionen auf den Management Console-Seiten Projekte, Umgebungen und Agents.

Datenspeicherung

Die folgenden Abschnitte beschreiben die Typen von Informationen, die in Harmony gespeichert werden.

Benutzerdaten

Wenn sich ein Benutzer registriert und Harmony abonniert, muss er die folgenden Informationen bereitstellen, die im Projekt-Repository gespeichert werden: Vorname, Nachname, E-Mail und Telefonnummer. Unternehmen, Unternehmensadresse und Unternehmenswebsite können angegeben werden, sind aber optional.

Darüber hinaus werden bestimmte Systemdaten, die zur Identifizierung eines Benutzers verwendet werden können, protokolliert, um die Sicherheit und Integrität des Systems zu gewährleisten.

Benutzerauthentifizierung

Erfolgreiche und fehlgeschlagene Anmeldeversuche werden protokolliert, um potenzielle Sicherheitsverletzungen zu identifizieren und festzustellen, ob jemand versucht, unautorisiert auf das System zuzugreifen. Diese Informationen werden aufgezeichnet:

  • Benutzer-ID: Die Benutzer-ID, die jedem Anmeldeversuch zugeordnet ist. Dies hilft zu identifizieren, welcher Benutzer sich anmelden versucht, und ihre Aktivitäten nachzuverfolgen.
  • Zeitstempel: Die Zeit jedes Anmeldeversuches. Dies hilft zu identifizieren, wann sich ein Benutzer anmelden versucht, und seine Aktivitäten im Laufe der Zeit nachzuverfolgen.
  • IP-Adresse: Die IP-Adresse, die jedem Anmeldeversuch zugeordnet ist. Dies hilft zu identifizieren, von wo aus der Benutzer versucht sich anzumelden, und potenzielle Sicherheitsverletzungen zu erkennen.
  • Geräteinformationen: Informationen über das Gerät, das zum Anmelden verwendet wurde, wie das Betriebssystem, die Browserversion und der Gerätetyp. Dies hilft, potenzielle Sicherheitsverletzungen zu identifizieren und Probleme zu beheben, die auftreten können.
  • Abmeldeereignisse: Jedes Mal, wenn sich ein Benutzer abmeldet. Dies hilft sicherzustellen, dass Benutzer abgemeldet werden, und ihre Aktivitäten nachzuverfolgen.

Benutzerautorisierung

Benutzerautorisierung bestimmt, ob ein Benutzer über die erforderlichen Berechtigungen verfügt, um auf eine bestimmte Ressource zuzugreifen oder eine bestimmte Aktion innerhalb eines Systems auszuführen.

Zusätzlich zu Benutzer-ID und Zeitstempel (beschrieben in Benutzerauthentifizierung) werden diese Benutzerautorisierungsinformationen protokolliert:

  • Ressourcen-ID: Die ID der Ressource, auf die der Benutzer zugreifen oder die er ändern möchte. Dies hilft zu identifizieren, auf welche Ressource der Benutzer zugreifen möchte, und die Ressourcennutzung nachzuverfolgen.
  • Aktions-ID: Die ID der Aktion, die der Benutzer ausführen möchte. Dies hilft zu identifizieren, welche Aktion der Benutzer ausführen möchte, und die Aktionsnutzung nachzuverfolgen.
  • Autorisierungsergebnis: Das Ergebnis jedes Autorisierungsversuchs, einschließlich der Frage, ob dem Benutzer der Zugriff auf die Ressource oder Aktion gewährt oder verweigert wurde. Dies hilft, potenzielle Sicherheitsverletzungen zu identifizieren und die Ressourcen- und Aktionsnutzung nachzuverfolgen.
  • Autorisierungsrichtlinien: Informationen über die Autorisierungsrichtlinien, wie der Name und die Version der Richtlinie sowie alle relevanten Konfigurationsoptionen. Dies hilft bei der Fehlerbehebung bei Autorisierungsproblemen und beim Audit von Richtlinienänderungen.

Datenzugriff

Datenzugriff bezieht sich auf den Prozess des Lesens oder Änderns von Daten innerhalb eines Systems.

Zusätzlich zu Benutzer-ID, Zeitstempel, IP-Adresse und Geräteinformationen (beschrieben in Benutzerauthentifizierung) werden diese Datenzugriffsinformationen protokolliert:

  • Daten-ID: Die ID der Daten, auf die der Benutzer zugreifen oder die er ändern möchte. Dies hilft zu identifizieren, auf welche Daten der Benutzer zugreifen oder diese ändern möchte, und die Datennutzung nachzuverfolgen.
  • Zugriffstyp: Der Typ des versuchten Zugriffs, z. B. Lesen oder Schreiben. Dies hilft zu identifizieren, ob der Benutzer versucht, Daten anzuzeigen oder zu ändern.
  • Zugriffsergebnis: Das Ergebnis jedes Datenzugriffversuchs, einschließlich der Frage, ob dem Benutzer der Zugriff auf die Daten gewährt oder verweigert wurde. Dies hilft, potenzielle Sicherheitsverletzungen zu identifizieren und die Datennutzung nachzuverfolgen.

Konfigurationsänderungen

Konfigurationsänderungen beziehen sich auf Änderungen an den Konfigurationseinstellungen eines Systems oder einer Anwendung.

Zusätzlich zu Benutzer-ID und Zeitstempel (beschrieben in Benutzerauthentifizierung) werden diese Konfigurationsänderungsinformationen protokolliert:

  • Konfigurationselement: Das spezifische Konfigurationselement, das geändert wurde. Dies hilft zu identifizieren, welche Einstellung geändert wurde, und Änderungen an diesem Element im Laufe der Zeit nachzuverfolgen.
  • Alter Wert: Der vorherige Wert des Konfigurationselements vor der Änderung. Dies hilft zu identifizieren, welche Einstellung vor der Änderung vorhanden war.
  • Neuer Wert: Der neue Wert des Konfigurationselements nach der Änderung. Dies hilft zu identifizieren, worin die Einstellung geändert wurde.
  • Änderungstyp: Der Typ der vorgenommenen Änderung, z. B. ein Zusatz, eine Änderung oder eine Löschung. Dies hilft zu identifizieren, welche Art von Änderung am Konfigurationselement vorgenommen wurde.
  • Grund für die Änderung: (optional) Der Grund für die Konfigurationsänderung, falls verfügbar. Dies hilft zu identifizieren, warum die Änderung vorgenommen wurde, und alle Probleme zu beheben, die sich aus der Änderung ergeben könnten.

Systemereignisse

Systemereignisse beziehen sich auf verschiedene Ereignisse, die innerhalb eines Systems auftreten, wie z. B. Systemstart oder -herunterfahren, Fehler, Warnungen und andere Systemereignisse.

Zusätzlich zu Benutzer-ID, Zeitstempel und IP-Adresse (beschrieben in Benutzerauthentifizierung) werden diese Systemeventinformationen protokolliert:

  • Ereignistyp: Der Typ des aufgetretenen Ereignisses, z. B. ein Fehler-, Warn- oder Informationsereignis. Dies hilft, den Schweregrad des Ereignisses zu identifizieren und Fehlerbehebungsbemühungen zu priorisieren.
  • Ereignisbeschreibung: Eine Beschreibung des Ereignisses, einschließlich eventueller Fehlermeldungen und anderer relevanter Details. Dies hilft zu identifizieren, was passiert ist, und alle auftretenden Probleme zu beheben.
  • Ereignisquelle: Die Quelle des Ereignisses, z. B. die Anwendung, der Systemprozess oder das Gerät. Dies hilft zu identifizieren, wo das Ereignis aufgetreten ist, und alle Probleme auf bestimmte Komponenten des Systems zu isolieren.
  • Ereignisstatus: Der Status des Ereignisses, einschließlich der Frage, ob es behoben wurde oder noch andauert. Dies hilft, die Behebung des Ereignisses nachzuverfolgen und sicherzustellen, dass alle Probleme ordnungsgemäß behoben werden.

API-Nutzung

API-Nutzung bezieht sich auf die Verwendung von Anwendungsprogrammierschnittstellen (APIs), um mit einem System oder einer Anwendung zu interagieren.

Zusätzlich zu Benutzer-ID, Zeitstempel, IP-Adresse und Geräteinformationen (beschrieben in Benutzerauthentifizierung) werden folgende API-Nutzungsinformationen protokolliert:

  • API-Endpunkt: Der spezifische API-Endpunkt, der aufgerufen wurde. Dies hilft dabei, zu ermitteln, welche Funktionalität aufgerufen wurde, und die API-Nutzung nach Endpunkt zu verfolgen.
  • Anfrageparameter: Die Parameter, die in der API-Anfrage übergeben wurden. Dies hilft dabei, zu ermitteln, welche Daten im API-Aufruf verwendet wurden, und mögliche Probleme zu beheben.
  • Antwortstatus: Der Status der API-Antwort, einschließlich eventueller Fehlermeldungen oder anderer relevanter Details. Dies hilft dabei, zu ermitteln, ob der API-Aufruf erfolgreich war oder nicht, und mögliche Probleme zu beheben.

Integrationsprojektdaten

Zum Ausführen und Verwalten eines Integrationsprojekts muss ein Benutzer das Projekt in Harmony bereitstellen. Das Projekt speichert Entwurfs- und Implementierungsdetails, um Agentgruppen anzuweisen, welche Aktivitäten sie durchführen müssen. Dies umfasst Folgendes:

  • Integrationsoperationen, die beschreiben, was eine Integrationseinheit ausführt. Beispielsweise können alle Änderungen an Kundendaten im CRM-System mit Kundendaten im ERP-System synchronisiert werden.
  • Transformationen und Skripte, die beschreiben, wie diese Daten vom Quellsystem in das Zielsystem transponiert werden. Dies umfasst alle Validierungsregeln oder Datenmanipulationen, die erforderlich sind, um die Daten erfolgreich zu übertragen.
  • Schnittstellen, die die verschiedenen Quell- und Zielobjektstrukturen beschreiben. Diese Schnittstellen können einfache Textstrukturen oder komplexe XML-, JSON- oder EDI-Objektdarstellungen sein.
  • Verbindungen und Endpunkte, die als Quellen oder Ziele verwendet werden. Während diese hartcodierte Werte sein können, einschließlich Systemaddressen und Anmeldedaten, können sie auch über Variablen referenziert werden, die in internen Datenbanken für Kunden gespeichert werden können, die ihre eigenen Anmeldedaten-Vaults implementieren.
  • Zeitpläne und Benachrichtigungen, die bestimmen, wann Batch-Operationen ausgeführt werden müssen und was im Falle erfolgreicher und fehlgeschlagener Ergebnisse zu tun ist.
  • API-Endpunkte, die Agenten und Agentgruppen informieren, wie APIs so bereitgestellt werden, dass externe Systemereignisse Jitterbit-Integrationen aufrufen und aufrufen können.

Persistente Daten werden im Ruhezustand mit Folgendem gesichert:

  • Authentifizierung
  • Zugriffskontrolllisten
  • FIPS 140-2-Verschlüsselung und eindeutige Verschlüsselungsschlüssel pro Kunde

Persistente Cloud-Daten werden während der Übertragung mit Folgendem gesichert:

  • Authentifizierung.
  • TLS-Verschlüsselung (Transport Layer Security).

Integritätsaktivitätsprotokoll

Wenn eine Agentgruppe eine Integrationsoperation ausführt, synchronisiert sie ihre Protokolle mit dem Harmony-Multi-Tenant-Rotationsaktivitätsprotokoll. Dies umfasst folgende Informationen:

  • Status: Der Zustand einer Operation (z. B. ausstehend, läuft, erfolgreich, fehlgeschlagen).
  • Agent: Welcher Agent in der Agentgruppe die Operation ausgeführt hat.
  • Zeitpunkt: Wann die Operationsausführung eingereicht, gestartet und abgeschlossen wurde.
  • Eingereicht von: Wer die Anfrage zur Ausführung der Operation eingereicht hat.
  • Verarbeitete Datensätze: Die Anzahl der vom Quellsystem verarbeiteten Datensätze und wie viele Datensätze im Ziel bereitgestellt wurden.
  • Nachricht: Alle zusätzlichen Informationen, die für die Behebung eines fehlgeschlagenen Ergebnisses relevant sind, oder Zusammenfassungsinformationen, die ein Benutzer Jitterbit explizit anweist, mit der internen Funktion WriteToOperationLog in das Protokoll zu schreiben.

Darüber hinaus werden Komponenteneingabe- und Ausgabedaten in das Operationsprotokoll geschrieben, wenn das Debug-Protokollieren von Operationen für eine Studio-Operation aktiviert ist.

Die Operationsprotokolldaten werden in der Cloud auf einem täglich partitionierten Rotationssystem gespeichert. Die Aktivitäten für jeden Tag werden in der Partition dieses Tages erfasst und jede Partition wird nach 31 Tagen gelöscht. Aktivitätsprotokolldaten, die älter als 31 Tage sind, werden dauerhaft entfernt.

Operationsprotokolle, einschließlich detaillierter Protokollmeldungen von Cloud-Agenten und Private Agenten sowie Komponenteneingabe- und Ausgabedaten innerhalb von Operationsprotokollen, werden von Harmony 30 Tage lang aufbewahrt.

Agent-Protokolle

Jeder Agent kann zusätzliche Daten generieren, auf die entweder über Harmony zugegriffen werden kann oder die auf lokalen Speichergeräten gespeichert und von innerhalb einer Firewall aus zugegriffen werden können. Dies sind detaillierte Protokolle, die Folgendes enthalten:

Die Agent-Gruppen und Agenten synchronisieren diese nicht automatisch mit Harmony, da sie typischerweise vertrauliche Geschäftsdaten enthalten. Durch die Verwendung eigener Speichergeräte können Kunden ihre Daten innerhalb ihrer Firewall oder in ihren eigenen Private-Cloud-Infrastrukturen schützen.

Diese Protokolle sind für detaillierte Fehlerbehebung und Audit-Zwecke nützlich.

Standardmäßig speichert eine Private-Agent-Gruppe Protokolldateien, Debug-Dateien, temporäre Dateien, Transformationsdaten sowie Erfolgs- und Fehlerdateien für 1 bis 14 Tage, je nach Konfiguration der Bereinigungsregelndienste.

Integrationstestdaten, die durch Harmony fließen

Zusätzlich zu den in Harmony gespeicherten Daten können Geschäftsdaten während des Integrationsentwurfs durch die Cloud-Plattform fließen. Diese nicht persistenten Testdaten fließen bei der Durchführung von Funktionen wie:

  • Vorschau mit Beispieldatei: Bringt Beispieldaten – entweder vom Benutzer geladen oder Mock-Daten aus der Quellenstruktur erstellt – in eine Transformation, um einem Benutzer zu helfen, Elemente in einer Schnittstelle zu identifizieren und Transformationen zu testen. Zeigt das transformierte Zielresultat für einen bestimmten Datensatz, der geladen wird.
  • Vorschau mit Quelldaten: Bringt Quelldaten aus bestimmten Endpunkten – wie von einer Datenbank, Salesforce oder NetSuite-Abfrage – in die Transformation, die in der Vorschau angezeigt wird, und zeigt das transformierte Zielresultat für einen bestimmten Datensatz, der geladen wird.
  • Testskript: Ermöglicht es einem Benutzer, Skripts zu testen, einschließlich Funktionen, die Daten zurückgeben können – wie von einer Datenbank, Salesforce oder NetSuite-Abfrage – oder Skripts, die von einer API zurückgegebene Variablenwerte anzeigen.
  • Abfrage testen: Ermöglicht es einem Benutzer, zu testen, ob eine Abfrage gültig ist, und zeigt ein Beispiel von Daten vom Endpunkt während der Konfiguration bestimmter Endpunktaktivitäten, wie solche für eine Datenbank- oder Salesforce-Abfrage.

KI-Dienste

Die Harmony-Plattform ist mit KI-Funktionen durchdrungen, einschließlich KI-gestützter Assistenten und Chatbots:

security ai

Wichtig

Nur anonymisierte, nicht-sensitive Daten werden sicher mit OpenAI geteilt.

Jitterbit nutzt KI-Dienste zur Datenverarbeitung mit diesen Funktionen:

  • iPaaS-KI-Assistent: Der Connector Builder KI-Assistent sendet anonymisierte Eingaben an OpenAI, um es zu lehren, API-Dokumentation zu verstehen, die er zum Generieren eines Studio-Connectors nutzt. Die KI-Mapping-Funktion von Jitterbit (Beta) basiert auf Jitterbits eigenem Modell. Jitterbit sendet keine Transformationsdaten an irgendwelche Modellanbieter.
  • APIM-KI-Assistent: Der APIM-KI-Assistent sendet anonymisierte Eingaben an OpenAI, um Ressourcen in API Manager zu erstellen und zu veröffentlichen.
  • EDI-KI-Assistent: Der EDI-KI-Assistent sendet anonymisierte Eingaben an OpenAI, um Ressourcen in Jitterbit EDI zu erstellen oder zu ändern.
  • App Builder KI-Assistent: Der App Builder KI-Assistent sendet anonymisierte Eingaben an OpenAI, um eine App Builder-Anwendung zu generieren.
  • KI-Chatbot: Der AskJB-KI-Chatbot nutzt OpenAI mit Retrieval Augmented Generation (RAG), um öffentlich verfügbare Informationen von der Jitterbit-Dokumentation-Website abzurufen. AskJB AI ist über das Jitterbit Harmony-Portal und öffentlich auf der Jitterbit-Dokumentationswebsite verfügbar.

iPaaS-Sicherheitstopologien

Jedes Integrationsprojekt oder jeden Service, einschließlich APIs, kann man mit den nachfolgend beschriebenen Sicherheitstopologien bereitstellen. Je nach unmittelbaren und/oder spezifischen Umgebungsanforderungen sollte man die Topologie wählen, die den Datenanforderungen und Governance-Richtlinien der Organisation entspricht. Diese Bereitstellungsarchitekturen mit zugehörigen Sicherheitstopologien werden wie folgt zusammengefasst und in diesem Abschnitt näher erläutert.

  • Cloud: In der Harmony Cloud, wo System und Skalierung vollständig von Jitterbit verwaltet werden.
  • Privat (On-Premises, lokal): Auf einem lokalen Server oder in einer privaten Cloud, wo das System selbst gehostet und lokal verwaltet wird.
  • Hybrid: Im Hybrid-Modus, wo bestimmte Systemanteile selbst gehostet werden und der Rest von Jitterbit verwaltet wird.

Darüber hinaus ermöglicht Jitterbit beliebig viele Kombinationen und Standorte für seine Komponenten und erlaubt das Ad-hoc-Wechseln der Bereitstellungsoptionen in verschiedenen Situationen. Diese Flexibilität bringt diese Vorteile mit sich:

  • Höchste Verarbeitungsleistung: Man kann die Leistung durch Edge Processing erhöhen, wo Agenten in der Nähe der Datenquellen angesiedelt sind.
  • Einfache Verwaltung: Remote-Verwaltung ist auch für private/lokale Bereitstellungen verfügbar.
  • Sicherheit und Datenschutz: Die Agenten führen die gesamte Verarbeitung direkt durch, ohne dass Daten außerhalb der unmittelbaren Quell- und Zielverbindungen offengelegt werden.

Sicherheitstopologie bei vollständiger Cloud-Bereitstellung

Kunden, die Integrationen durchführen müssen, bei denen alle Datenquellen über die Cloud zugänglich sind, können ihre Projekte in Harmony-Umgebungen bereitstellen und ihre Projekte auf der Jitterbit Cloud-Agent-Gruppe ausführen.

security cloud

Hier greift die von Jitterbit betriebene Multi-Tenant-Public-Cloud-Agent-Gruppe direkt über das Internet mit HTTPS auf Kundenbusinessdaten zu. Jitterbit-Agenten innerhalb dieser Agent-Gruppe verarbeiten Geschäftsdaten und posten diese an beliebige Zielsysteme. Die Daten fließen über HTTPS innerhalb des Jitterbit-Netzwerks.

Hinweis

Alle oben genannten Daten werden für kurze Zeit in der sicheren Betriebsumgebung von Harmony gespeichert.

Kunden, deren Richtlinien Cloud-Nutzung nicht zulassen oder übermäßige Haftungs- und Schadensersatzgarantien erfordern, sollten validieren, dass die Jitterbit Master Subscription Agreement und die Datenschutzrichtlinie den Anforderungen bezüglich Branchenvorschriften, Kundenbestimmungen, Schadensersatzverpflichtungen und Haftungsbedingungen entsprechen.

Sicherheitstopologie bei Hybrid-Bereitstellung

Bei einem Hybrid-Bereitstellungsszenario werden bestimmte Systemanteile selbst gehostet und der Rest wird von Jitterbit verwaltet. Beispielsweise möchte man Datenbanken und Apps möglicherweise nicht Cloud-Systemen, einschließlich Jitterbit, aussetzen, wenn die Anforderungen der Organisation nicht zulassen, dass Daten in der Cloud (außerhalb der Firewall) gespeichert werden, und zwar aufgrund von Datenschutz- und Compliance-Bedenken.

security hybrid

In diesem Fall befinden sich die privaten Agenten hinter der Firewall, während sich das API-Gateway in der Harmony Cloud befindet. Der Agent fordert die Informationen über die Messaging-Schicht an und sendet die Nutzlast aus Apps und Datenquellen über die Nutzlast zurück an das Gateway. Kunden können beschränken, welche Daten in den Logs gespeichert werden, um zu verhindern, dass diese Daten die Harmony Cloud erreichen.

Sicherheitstopologie bei privater Bereitstellung

In den meisten Enterprise-Integrationsszenarios muss die Agent-Gruppe auf interne und Cloud-Anwendungen zugreifen. Hier würden Benutzer ihre Projekte in Harmony-Umgebungen bereitstellen, ihre eigenen privaten Agent-Gruppen in ihren Netzwerken installieren, die Zugriff auf ihre Anwendungen haben, und diese Agent-Gruppen dann über die Harmony Platform verwalten.

security private

Diese Topologie ermöglicht es Benutzern, ihre Agent-Gruppen mithilfe von Harmony bereitzustellen und zu verwalten, während die Agent-Gruppe und alle vertraulichen Geschäftsdaten, die verarbeitet oder gespeichert werden, in ihrem Netzwerk verbleiben. In dieser Topologie kann die private Agent-Gruppe auf Windows oder Linux-Umgebungen auf physischen oder virtuellen Servern ausgeführt werden (weitere Informationen finden Sie unter Systemanforderungen für private Agenten).