Zum Inhalt springen

Logische Sicherheit und Architektur von Jitterbit Harmony

Einführung

Logische Sicherheit umfasst alle Sicherheitsmaßnahmen innerhalb der Harmony-Plattform. Dieser Abschnitt beschreibt Folgendes:

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 ausgestattet, 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 Frontend-Anwendungen von Jitterbit, die es Benutzern ermöglichen, Integrationsprojekte, APIs, benutzerdefinierte Web-Apps und native Mobile Apps sowie EDI-Prozesse zu erstellen und zu verwalten.

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 Organisationsrollberechtigungen und Umgebungszugriffsebenen gesteuert, 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 Internetzugang 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 sicherzustellen.

Beide Anwendungen nutzen die Harmony-Plattform und ihre 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 Umgebungszugriffsebenen 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 wird. Sie definieren die Authentifizierungsmethode im Sicherheitsprofil und wählen zwischen anonymer Authentifizierung, Basic-Authentifizierung, OAuth 2.0 oder API-Schlüssel-Authentifizierung.

  • Der SSL-only-Modus beschränkt HTTP-Datenverkehr auf verschlüsselte Kommunikation. Die Identität der HTTPS-URL wird durch Symantec Class 3 Secure Server SHA256 SSL CA überprüft. Die Verbindung zur HTTPS-URL wird mit moderner Kryptographie 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 Organisationsberechtigung Admin haben oder eine Kombination aus der Organisationsberechtigung 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-Organisationsadministrator eingeladen wurden.

App Builder

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

Der Zugriff auf eine konfigurierte App Builder-Instanz ist über das Harmony-Portal verfügbar. Eine Harmony-Benutzerrolle mit der Organisationsberechtigung Admin ist erforderlich, um den Zugriff durch 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 überträgt. Cookies werden standardmäßig mit dem Flag HttpOnly gesetzt. Das Flag HttpOnly mindert Cross-Site-Scripting-Angriffe (XSS) ab.

  • Single Sign-On (SSO): Die Authentifizierung kann an einen SSO-Provider delegiert werden. App Builder unterstützt verschiedene Industriestandards, einschließlich SAML SSO und WS-Federation. Diese verwenden die PKCS #1-Spezifikation für digitale Signaturen mit SHA-256-Digests.

  • Anspruchsbasierte Authentifizierung: Benutzerauthentifizierungsanbieter übergeben Ansprüche an App Builder. Sicherheitsadministratoren ordnen die Ansprüche Benutzerattributen zu, einschließlich Gruppenmitgliedschaft.

  • Lokale Authentifizierung: Lokale Authentifizierung kann zur Authentifizierung mit einem in App Builder gespeicherten Passwort verwendet werden, wobei die PBKDF2-Schlüsselableitungsfunktion mit dem SHA-256-Hash-Algorithmus, eine Schlüssellänge von 16 Bytes, eine Salt-Länge von 16 Bytes und 10.000 Iterationen verwendet werden. Sicherheitsfeatures 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 zwangsweise abmelden. Das Tracking von Sitzungen schützt vor bestimmten Sicherheitslücken, wie z. B. Cookie-Replay-Angriffen.

  • Rollenbasierte Sicherheit: Der Zugriff auf Daten kann durch die Gruppenmitgliedschaft eines Benutzers gesteuert werden, die die Rollen des Benutzers bestimmt, die Berechtigungen für Geschäftsdaten bestimmen. Realms ermöglichen es 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 für die lokale Verarbeitung von EDI-Daten an.)

Persönlich identifizierbare Informationen (PII) werden standardmäßig maskiert. Ein Harmony-Administrator kann die PII-Daten in der EDI-App für bis zu 24 Stunden freigeben, danach werden sie wieder maskiert.

Die EDI-App bietet auch die Möglichkeit, die personenbezogenen Daten eines Handelspartners zu verwalten, indem man sie 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 einen differenzierteren Zugriff 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 als Grundlage für Studio-Integrationsprojekte zu dienen.

Eine Harmony-Benutzerrolle mit der Organisationsberechtigung Read oder Admin ermöglicht den Zugriff auf Rezepte und Vorlagen im Marketplace. Das Starten eines Rezepts oder einer Vorlage in einer Umgebung erfordert Write-Zugriff in dieser Umgebung.

Management Console

Management Console ist eine Harmony-Portal-Webanwendung zur Verwaltung und Überwachung der Harmony-Organisation im 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 Definition, wer auf verschiedene Bereiche der Jitterbit-Anwendungen zugreifen kann (siehe Authentifizierung, Berechtigungen und Zugriff).

Die Management Console erleichtert verschiedene andere Verwaltungsaufgaben, die typisch für einen Harmony-Administrator sind:

  • 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 bietet auch Informationen zur Überwachung der Organisation:

  • Audit-Protokollinformationen darüber, wer welche Aktivitäten in der Organisation durchgeführt hat.
  • Operationsprotokolle 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 Organisationsberechtigung Admin Zugriff auf alle Management Console-Seiten hat und die Möglichkeit bietet, Bearbeitungen vorzunehmen und Aktionen auszuführen.

Eine Benutzerrolle mit der Berechtigung Read kann auf zusätzliche Management Console-Seiten zugreifen, wenn ihr Umgebungszugriffsstufen gewährt werden, wie in Authentifizierung, Berechtigungen und Zugriff beschrieben. Das für jede Umgebung definierte Zugriffskontrollschicht-Modell ist granular, sodass die Konfigurationen, die Benutzer sehen und mit denen sie interagieren können, von den Zugriffskontrolleinstellungen des Benutzers abhängen. Zugriffskontrolleinstellungen werden auf alle Funktionen angewendet, einschließlich der Suche nach Operationen, der Ausführung von Operationen, der Anzeige 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 Navigation der Management Console, und Rollen mit nur dieser Berechtigung haben den Umgebungsrollenzugriff deaktiviert.

Wiederverwendbare Assets

Wiederverwendbare Assets umfassen Konnektoren, Anwendungen und Integrationsprojekte sowie die Tools zu deren 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 über 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.
  • KI-Agenten: Vorgefertigte Agenten, die verwendet werden können, um Ihre Ziele autonom ohne direkte menschliche Überwachung 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 derselben sicheren Codierungsstrenge wie Harmony selbst erstellt (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 Services zum Bereitstellen, Verwalten und Ausführen von Integrationsprojekten, zum Erstellen von benutzerdefinierten Web- und nativen Mobile Apps, zum Erstellen, Steuern und Nutzen von APIs sowie zum Verarbeiten von EDI-Transaktionen.

API-Gateways

Ein API-Gateway ist ein Service, der die Richtlinien und Sicherheitsprofile durchsetzt, die auf APIs mithilfe der Webanwendung API Manager erstellt werden. Die Konnektivität zu APIs, die über API Manager veröffentlicht werden, wird entweder über Jitterbits Cloud-API-Gateway oder ein privates API-Gateway ermöglicht.

Die API-Gateways verwalten diese Sicherheitsaufgaben bei der Annahme und Verarbeitung von Aufrufen an eine API:

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

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

Jitterbits Cloud-API-Gateway 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 ausschließlich auf ein internes Netzwerk hinter einer Firewall beschränkt werden und ist nicht über das Internet erreichbar. Allerdings müssen bestimmte Jitterbit-Services auf die Zulassungsliste gesetzt werden (Whitelist). Bei einem privaten API-Gateway werden API-Response-Payloads niemals über Jitterbits Systeme übertragen.

Messaging

Die Kommunikation zwischen verschiedenen Jitterbit-iPaaS-Komponenten wie Studio, Agents und der Harmony-Plattform wird durch einen Satz sicherer Laufzeit-Messaging-Services basierend auf der Java Messaging Services (JMS) API erreicht, die in der Java Platform enthalten ist. Diese APIs sind intern für Harmony, und Kunden haben keinen Zugriff auf diese APIs.

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

Agents

Die in Studio und Design Studio-Projekten entworfenen Integrationsprozesse werden auf Agents ausgeführt, wobei entweder eine Jitterbit-Cloud-Agent-Gruppe oder private Agents und eine private Agent-Gruppe verwendet werden.

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

Jitterbit erkennt an, dass Kunden ihre Integrationsprozesse mit Anwendungen kommunizieren lassen müssen, die aus verschiedenen Sicherheits- und Compliance-Gründen hinter Unternehmens-Firewalls betrieben werden.

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

Translated Content

Während das System die Bereitstellung, den Einsatz und die Verwaltung von Integrationsprojekten vereinfacht, bietet es Benutzern auch die Flexibilität, ihre Integrationsvorgänge mithilfe von abnehmbaren privaten Agent-Gruppen auszuführen. Dabei handelt es sich um in sich geschlossene Subsysteme, die hinter Unternehmensfirewalls oder in dedizierten Private 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-Agents sind Dienste, bekannt als Backend as a Service (BaaS), die dazu konzipiert sind, Anforderungen von Clients ad hoc zu verarbeiten und zu bedienen. Sie führen ihre gesamte Arbeit ereignisgesteuert aus und eliminieren damit die Notwendigkeit für Setup, Konfiguration oder Verwaltung, wie sie bei traditionellen „Always-on"-Serversystemen hinter Anwendungen üblich ist.

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

Um die Sicherheit zu erhöhen und den Datenschutz zu gewährleisten, sind Jitterbit Cloud-Agents so programmiert, dass lokal verarbeitete Daten nicht persistent sind. Sie werden nur für die minimale Zeit verwendet, die zum Abschluss des beabsichtigten 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 und postet dann Daten in diese Anwendungen.

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

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

Private Agents und private Agent-Gruppe

Jitterbit bietet die Flexibilität für Kunden, ihre eigenen Agent-Gruppen und privaten Agents innerhalb ihrer Unternehmensfirewall oder virtuellen privaten Clouds bereitzustellen und zu verwalten. Dies ermöglicht es Kunden, zu wählen, wo ihre Integrationslaufzeitumgebung ausgeführt wird, und ermöglicht es ihnen, zu kontrollieren, welches Netzwerk ihre Geschäftsdaten durchlaufen und sich darin befinden. 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.

Agents, 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. Wenn Ihre Organisation 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-Dienste auf die Allowlist (Whitelist) setzen.

Privater Agent-Code wird mit der gleichen Codierungsgenauigkeit erstellt wie Harmony-Code (siehe Entwicklungsprozesse).

Während private Agent-Gruppen strenge Sicherheitsanforderungen erfüllen, ist der Benutzer oder Kunde für die Installation und Verwaltung seiner privaten Agents verantwortlich. In der Cloud-Agent-Gruppe bietet Jitterbit intelligentes Routing, hohe Verfügbarkeit und Skalierbarkeit, die dem entspricht, was von einer serverlosen Technologie erwartet wird. In privaten Agent-Gruppen liegt die Sicherheit und Skalierbarkeit privater Agents jedoch in der Verantwortung des Kunden (obwohl hohe Verfügbarkeit immer noch von der Harmony-Plattform gewährleistet wird, wenn mehr als ein Agent innerhalb einer privaten Agent-Gruppe verwendet wird). Jitterbit bietet Best-Practice-Ratschläge zum Hosten von privatem Agent-Code in Systemanforderungen für private Agents.

Listening Service

Der Listening Service ist ein Anwendungsdienst, der auf einem privaten Agent ausgeführt wird und von bestimmten Studio-Konnektoren mit Listening-Funktionen genutzt wird. Der Listening Service bietet asynchrone Ereignisbehandlungsfunktionen für Vorgänge, die auf dem Agent bereitgestellt werden.

listening service system architecture

  1. Ein Vorgang, der einen Connector mit einer Abhöraktivität enthält, wird bereitgestellt und zum Abhören aktiviert.
  2. Der Abhördienst im Agent startet einen Listener für diesen Vorgang.
  3. Der Listener beginnt aktiv, auf Ereignisbenachrichtigungen vom Endpunkt zu warten.
  4. Wenn ein Ereignis am Endpunkt auftritt, veröffentlicht dieser eine Ereignisbenachrichtigung, die von seinen Abonnenten empfangen werden kann.
  5. Der Listener erfasst die Ereignisbenachrichtigungsmeldung.
  6. Wenn sich ein Agent in der Agent-Gruppe befindet, leitet der Listener die Ereignismeldung an den Vorgang weiter. Wenn die Agent-Gruppe die Mindestanzahl für vollständige Abhördienst-Funktionen enthält, wird die Ereignismeldung an den Agent mit der geringsten Auslastung weitergeleitet.
  7. Nach Erhalt der Ereignisbenachrichtigung löst der Vorgang einen nachgelagerten Vorgang aus.

Transaktionsprotokolle

Transaktionsprotokolle, auch als Vorgangsprotokolle bezeichnet, sind die Protokolle, die bei der Ausführung eines Studio- oder Design Studio-Vorgangs generiert werden. Sie enthalten Informationen zum Vorgang, einschließlich seines Standorts, Zeitrahmens und Status.

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 Vorgänge auch detaillierte Protokollmeldungen. Die Cloud-Protokollierung ist für Jitterbit-Cloud-Agent-Gruppen immer aktiviert und kann für private Agents optional deaktiviert werden.

Vorgangsprotokolle, einschließlich detaillierter Protokollmeldungen von Cloud-Agents und privaten Agents sowie Komponenteneingabe- und -ausgabedaten in Vorgangsprotokollen, 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 Partitionierung von Projekten nach Organisation und in den meisten Fällen nach Umgebung ermöglicht. Speziell isoliert und sichert Harmony Kundenprojekte mit Folgendem:

  • Sichere Datenbankarchitektur: Umfasst getrennte Datenbank- und getrennte Schema-Architektur.
  • Sichere Verbindungen oder Tabellen: Verwendet vertrauenswürdige Datenbankverbindungen.
  • Verschlüsselung: Verschleiert kritische Daten, sodass diese für Unbefugte unzugänglich bleiben, auch wenn diese in deren Besitz gelangen.
  • Filterung: Verwendet eine Zwischenschicht zwischen einem Mandanten und einer Datenquelle, die wie ein Sieb funktioniert und dem Mandanten den Anschein erweckt, dass nur seine Daten in der Datenbank vorhanden sind.
  • Zugriffskontrolllisten: Bestimmt, wer auf Daten in der Anwendung zugreifen kann und was damit getan werden kann.

Projekte enthalten typischerweise Anmeldedaten wie Benutzername und Passwort, die zum Verbinden mit verschiedenen Endpunkten verwendet werden. Diese Informationen werden im mandantenfähigen Repository verschlüsselt.

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

Kunden haben keinen direkten Zugriff auf dieses Repository. Die verschiedenen Jitterbit iPaaS-Komponenten, wie Integrations-Designer und Cloud-Agents, verwenden APIs für den Zugriff auf das Repository. Nach der 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 nur auf der Grundlage der von einem Organisationsadministrator (Benutzer mit Admin-Berechtigung) gewährten Berechtigungen anzeigen, bearbeiten und ändern können. Darüber hinaus ist die Granularität des Audit-Trails pro Kunde konfigurierbar.

Die Harmony-Aktivitätsdatenbank mit Rotation speichert Laufzeitstatusinformationen sowie Protokolle ausgeführter Vorgänge aller Harmony-Benutzer.

Die Aktivitätsdatenbank basiert auf einer mandantenfähigen Architektur. Während Aktivitätsdaten für alle Benutzer in derselben Datenbank vorhanden sind, wird eine logische Segmentierung nach Organisation und Umgebung durch eine Software-Zugriffskontrollschicht und eindeutige Verschlüsselungsschlüssel angewendet, um sicherzustellen, dass Benutzer nur die Aktivitäten anzeigen können, auf die sie Zugriff haben.

Die Aktivitätsdatenbank wird über AWS-Regionen und Verfügbarkeitszonen repliziert, um hohe Verfügbarkeit zu gewährleisten, und wird gesichert, falls eine Wiederherstellung erforderlich ist.

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

Dateidienste

Harmony umfasst eine Reihe 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 zugegriffen werden. Ein direkter Zugriff ist nicht möglich.

Schema-Repository

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

Zusätzlich zur Speicherung im Harmony Cloud-Datenspeicher werden Studio-Schemas im Design-Repository gespeichert, um die Wiederverwendbarkeit von Schemas innerhalb eines Projekts zu verwalten.

Anpassungs-Repository

Um Integrationen von verschiedenen Datenbank-Endpunkten 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, durch die alle Daten fließen.

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

Application Builder-Laufzeit

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

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

  • Private Cloud: Die App Builder-Umgebung wird auf 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 alle in der Private Cloud. Diese Option bietet Flexibilität und Kontrolle über die App Builder-Umgebung und Infrastruktur. Alle Wartungs-, Sicherheits-, Hardware- und Softwarevorgänge werden vom Kunden verwaltet.

B2B-Laufzeit-Engine

EDI-Transaktionen werden über die EDI Cloud-Laufzeit verarbeitet, auch als eiCloud bezeichnet.

Nach der Generierung einer Transaktion wird diese in der Transaktionsdatenbank gespeichert und wartet auf die Verarbeitung. Das EDI-Dokument bleibt bestehen, bis es mithilfe der für den Handelspartner festgelegten Archivierungseinstellungen archiviert wird. Der Status eines EDI-Dokuments kann jederzeit über die EDI-Seite Transaktionen überprüft werden.

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

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

Messaging-System

Der Message Queue (MQ) Service ist ein cloudbasierter, mandantenfähiger Messaging-Queue-Dienst zum Erstellen und Verwalten von Warteschlangen und Nachrichten. Damit können Sie Integrationen erstellen, die von den Endpunkten, die Sie integrieren, entkoppelt sind. Der MQ Service wird mit dem Studio Jitterbit MQ-Konnektor verwendet.

message queue system architecture

  1. Daten werden von einem Quell-Endpunkt abgerufen, z. B. mithilfe eines Studio Konnektors. Die abgerufenen Daten können dann in eine Nachricht umgewandelt werden, die vom Jitterbit MQ-Konnektor verarbeitet 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. Daten, die aus einer Nachricht abgerufen werden, können dann als Eingabe verwendet werden, die von einem Zielendpunkt verarbeitet wird, z. B. durch Verwendung eines Studio-Connectors.

  5. Nachdem die Daten verarbeitet wurden, kann die Nachricht entweder bestätigt werden (mit der Acknowledge-Aktivität) oder negativ bestätigt werden (mit der NACK-Aktivität). Wenn die Nachricht nicht bestätigt oder negativ bestätigt wird, bevor das Timeout von 30 Minuten abläuft, wird die Nachricht erneut aus der Warteschlange abgerufen, entweder durch eine Get- oder Get Bulk-Aktivität.

Analyse- und Logging-Engines

Die Harmony-Plattform bietet Analyse- und Logging-Informationen, 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 Sicherheitslücken aus externen Quellen, um Änderungen und Code-Verbesserungen voranzutreiben.
  • Anwendung von Hardware- und Software-Patches. Die virtuelle Umgebung ermöglicht es uns, Code-Änderungen und Hardware-Patches ohne Ausfallzeiten durchzuführen.
  • Bereitstellung sicherer Authentifizierungs- und Logging-Funktionen.
  • Entfernung von Entwicklungskonten, IDs und Passwörtern aus Produktionsumgebungen.
  • Einhaltung strenger Change-Management-Praktiken für Code-Updates und Patches.
  • Trennung von Test- und Entwicklungsumgebungen von der Produktion.
  • Aufrechterhaltung der Funktionstrennung zwischen Entwicklungs- und Support-Personal.
  • Sicherstellung, dass personenbezogene Daten (PII) nicht in Test-Umgebungen verwendet werden.
  • Entfernung von Test- und Entwicklungs-IDs vor der Migration von Code in die Produktion.
  • Durchführung regelmäßiger Code-Reviews.
  • Dokumentation von Code-Änderungen.
  • Einbeziehung von Senior-Entwickler-Input und Genehmigung für alle Code-Änderungen.
  • Durchführung von Funktions- und Regressionstests vor der Freigabe in die Produktion.
  • Aufrechterhaltung von Backout-Verfahren zur Wahrung von Hochverfügbarkeit und Integrität.
  • Befolgung sicherer Coding-Praktiken gemäß einer SDLC-Richtlinie und Adressierung der Schulungsanforderungen für Sicherheit des Entwicklungsteams.
  • Überprüfung auf Sicherheitsmängel wie vom Open Web Application Security Project (OWASP) vorgeschrieben, z. B. Injection-Flaws, Buffer Overflows, kryptografische Fehler, Fehlerbehandlung usw.
  • Bewertung auf Sicherheitslücken bei jeder Freigabe.
  • Durchführung jährlicher Penetrationstests.

Authentifizierung, Berechtigungen und Zugriff

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

Registrierung und Authentifizierung

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

Passwort-Stä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 Mitgliederdomänen beschränken oder verlangen, dass Benutzer-IP-Adressen innerhalb eines angegebenen Bereichs liegen. Diese Einstellungen werden in den Organisationsrichtlinien festgelegt. Wenn ein Benutzer Mitglied mehrerer Organisationen ist, gelten die strengsten Richtlinien einer Organisation, deren Mitglied er ist, für seinen Login.

Nach 5 fehlgeschlagenen Anmeldeversuchen mit Harmony-Kontoanmeldedaten werden Konten für 30 Minuten 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, auch wenn das Passwort bereits verwendet wurde, wird aus Sicherheitsgründen eine generische Fehlermeldung zurückgegeben.

Wenn Single Sign-On (SSO) für einen Benutzer aktiviert ist, werden solche Anforderungen stattdessen vom Identitätsanbieter verwaltet. Diese Kontrollen gelten für Benutzer auf der Liste Bypass SSO der Organisation, die sich mit Harmony-Anmeldedaten authentifizieren. SSO wird auch von einem Administrator aus den Richtlinien einer Organisation 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 eine Organisation 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 verfügt über ein eigenes, rollenbasiertes Konto und Anmeldedaten, in denen persönliche Integrationswerkzeuge und Projekte sicher gespeichert werden.

Nach der Authentifizierung identifiziert 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 dieser 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 stehen diese unabhängigen Berechtigungen zur Verfügung, die Rollen zugewiesen werden können:

  • User Manager: Ermöglicht es einem Benutzer, Nicht-Admin-Benutzer und Rollen zu verwalten. Er kann Nicht-Admin-Benutzer hinzufügen, bearbeiten oder löschen, kann aber einen Benutzer nicht von Nicht-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 Zugriff auf Umgebungsrollen deaktiviert.
  • Agent-Install: Ermöglicht es einem Benutzer, Agents 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 herzustellen.
  • ApiConsumer: Bei Verwendung in Kombination mit Umgebungszugriffsstufen ermöglicht dies den Zugriff auf die Anzeige der OpenAPI-Dokumentation in einer Umgebung. Allein ermöglicht diese Berechtigung den Zugriff auf die Seite API Portal.
  • EDI User: Ermöglicht es einem EDI-Benutzer, EDI-Partner, Transaktionen und Einstellungen zu erstellen und zu aktualisieren.
  • EDI Viewer: Ermöglicht es einem EDI-Benutzer, EDI-Partner, Transaktionen und Einstellungen zu anzeigen.

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 zu den Privilegien, die durch jede Berechtigung gewährt werden, und auf Rollen zum Erstellen zusätzlicher Rollen mit beliebigen Berechtigungskombinationen.

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. Ein typisches Projektlebenszyklus-Setup könnte beispielsweise 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 Schreibberechtigungen 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 Seite Runtime der Management Console in einer bestimmten Umgebung anzuzeigen, bietet aber keine Sichtbarkeit oder Kontrolle über Projekte. Dies ermöglicht Benutzern, Projekte zu unterstützen, ohne sie in kritischen Umgebungen wie der Produktion zu ändern. Der Zugriff ist auf die Anzeige der Operationstabelle beschränkt und umfasst 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 zu ermöglichen, Assets anzuzeigen, aber nicht zu ändern. Diese Zugriffsstufe bietet auch schreibgeschützten Zugriff auf die Seiten Projekte, Umgebungen und Agents der Management Console.

  • Ausführen: Ermöglicht Benutzern, Studio- und Design Studio-Operationen auszuführen und Protokollmeldungen auf der Seite Runtime der Management Console innerhalb einer bestimmten Umgebung anzuzeigen. Dies ist eine häufige Zugriffskontrolle für Testumgebungen und wird oft Benutzern gewährt, die Projekte unterstützen müssen, da sie möglicherweise Tests durchführen und Aufgaben nach Bedarf ausführen müssen.

  • Schreiben: Ermöglicht vollständige Kontrolle über eine bestimmte Umgebung. Benutzer, die einer Rolle mit Schreib-Zugriff angehö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 aus dem Marketplace und das Ausführen von Aktionen auf den Seiten Projekte, Umgebungen und Agents der Management Console.

Datenspeicherung

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

Benutzerdaten

Wenn sich ein Benutzer bei Harmony registriert und 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, unbefugten Zugriff auf das System zu erlangen. Diese Informationen werden aufgezeichnet:

  • Benutzer-ID: Die Benutzer-ID, die mit jedem Anmeldeversuch verknüpft ist. Dies hilft zu identifizieren, welcher Benutzer sich anmelden möchte, und ihre Aktivität zu verfolgen.
  • Zeitstempel: Der Zeitpunkt jedes Anmeldeversuches. Dies hilft zu identifizieren, wann ein Benutzer versucht, sich anzumelden, und ihre Aktivität im Laufe der Zeit zu verfolgen.
  • IP-Adresse: Die IP-Adresse, die mit jedem Anmeldeversuch verknüpft 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 wird, 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 sind, und ihre Aktivität zu verfolgen.

Benutzerautorisierung

Die 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 folgende Benutzerautorisierungsinformationen protokolliert:

  • Ressourcen-ID: Die ID der Ressource, auf die der Benutzer zugreifen oder die er ändern möchte. Dies hilft dabei, zu identifizieren, auf welche Ressource der Benutzer zugreifen möchte, und die Ressourcennutzung zu verfolgen.
  • Aktions-ID: Die ID der Aktion, die der Benutzer ausführen möchte. Dies hilft dabei, zu identifizieren, welche Aktion der Benutzer ausführen möchte, und die Aktionsnutzung zu verfolgen.
  • 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 dabei, potenzielle Sicherheitsverletzungen zu identifizieren und die Ressourcen- und Aktionsnutzung zu verfolgen.
  • Autorisierungsrichtlinien: Informationen zu den Autorisierungsrichtlinien, wie z. B. der Name und die Version der Richtlinie sowie alle relevanten Konfigurationsoptionen. Dies hilft bei der Behebung von Autorisierungsproblemen und der Überprüfung von Richtlinienänderungen.

Datenzugriff

Der 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 folgende Datenzugriffsinformationen protokolliert:

  • Daten-ID: Die ID der Daten, auf die der Benutzer zugreifen oder die er ändern möchte. Dies hilft dabei, zu identifizieren, auf welche Daten der Benutzer zugreifen oder ändern möchte, und die Datennutzung zu verfolgen.
  • Zugriffstyp: Der Typ des versuchten Zugriffs, z. B. Lesen oder Schreiben. Dies hilft dabei, 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 dabei, potenzielle Sicherheitsverletzungen zu identifizieren und die Datennutzung zu verfolgen.

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 folgende Konfigurationsänderungsinformationen protokolliert:

  • Konfigurationselement: Das spezifische Konfigurationselement, das geändert wurde. Dies hilft dabei, zu identifizieren, welche Einstellung geändert wurde, und Änderungen an diesem Element im Laufe der Zeit zu verfolgen.
  • Alter Wert: Der vorherige Wert des Konfigurationselements vor der Änderung. Dies hilft dabei, zu identifizieren, wie die Einstellung vor der Änderung war.
  • Neuer Wert: Der neue Wert des Konfigurationselements nach der Änderung. Dies hilft dabei, zu identifizieren, auf welchen Wert die Einstellung geändert wurde.
  • Änderungstyp: Der Typ der vorgenommenen Änderung, z. B. eine Hinzufügung, Änderung oder Löschung. Dies hilft dabei, 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 dabei, zu identifizieren, warum die Änderung vorgenommen wurde, und alle Probleme zu beheben, die sich aus der Änderung ergeben können.

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 folgende Systemereignisinformationen protokolliert:

  • Ereignistyp: Der Typ des aufgetretenen Ereignisses, z. B. ein Fehler-, Warn- oder Informationsereignis. Dies hilft dabei, den Schweregrad des Ereignisses zu identifizieren und die Fehlerbehebung zu priorisieren.
  • Ereignisbeschreibung: Eine Beschreibung des Ereignisses, einschließlich aller Fehlermeldungen oder anderer relevanter Details. Dies hilft dabei, zu identifizieren, was passiert ist, und alle Probleme zu beheben, die sich ergeben können.
  • Ereignisquelle: Die Quelle des Ereignisses, z. B. die Anwendung, der Systemprozess oder das Gerät. Dies hilft dabei, zu identifizieren, wo das Ereignis aufgetreten ist, und alle Probleme auf bestimmte Systemkomponenten einzugrenzen.
  • Ereignisstatus: Der Status des Ereignisses, einschließlich der Frage, ob es behoben wurde oder noch andauert. Dies hilft dabei, die Behebung des Ereignisses zu verfolgen 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 identifizieren, 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 identifizieren, welche Daten im API-Aufruf verwendet wurden, und Probleme zu beheben, die möglicherweise auftreten.
  • Antwortstatus: Der Status der API-Antwort, einschließlich aller Fehlermeldungen oder anderer relevanter Details. Dies hilft dabei, zu identifizieren, ob der API-Aufruf erfolgreich war oder nicht, und Probleme zu beheben, die möglicherweise auftreten.

Integrationsprojektdaten

Um ein Integrationsprojekt auszuführen und zu verwalten, muss ein Benutzer das Projekt in Harmony bereitstellen. Das Projekt speichert Design- und Implementierungsdetails, um Agent-Gruppen anzuweisen, welche Aktivitäten sie ausführen müssen. Dies umfasst Folgendes:

  • Integrationsoperationen, die beschreiben, was eine Integrationseinheit tun wird. 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. Obwohl 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 Credential Vaults implementieren.
  • Zeitpläne und Benachrichtigungen, die bestimmen, wann Batch-Operationen ausgeführt werden müssen und was bei erfolgreichen und fehlgeschlagenen Ergebnissen zu tun ist.
  • API-Endpunkte, die Agenten und Agent-Gruppen informieren, wie APIs verfügbar gemacht werden, damit externe Systemereignisse Jitterbit-Integrationen aufrufen und aufrufen können.

Persistente Daten werden im Ruhezustand mit folgenden Mitteln gesichert:

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

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

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

Integrationsaktivitätsprotokoll

Wenn eine Agent-Gruppe eine Integrationsoperation ausführt, synchronisiert sie ihre Protokolle mit dem Harmony-Aktivitätsprotokoll mit mehreren Mandanten und rotierendem Speicher. Dies umfasst folgende Informationen:

  • Status: Der Zustand einer Operation (z. B. ausstehend, wird ausgeführt, erfolgreich, fehlgeschlagen).
  • Agent: Welcher Agent in der Agent-Gruppe 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 Datensätze, die vom Quellsystem verarbeitet wurden, und wie viele Datensätze zum Ziel gesendet 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.

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

Die Operationsprotokoll-Daten werden in der Cloud auf einem rotierenden, täglich partitionierten System 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ätsprotokoll-Daten, die älter als 31 Tage sind, werden dauerhaft entfernt.

Operationsprotokolle, einschließlich detaillierter Protokollmeldungen von Cloud-Agenten und privaten Agenten sowie Komponenteneingabe- und -ausgabedaten in 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 innerhalb einer Firewall aufgerufen werden können. Dies sind detaillierte Protokolle, die Folgendes umfassen:

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 sichern.

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 Datenlöschungsregeln.

Integrationstestdaten, die durch Harmony fließen

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

  • Vorschau mit Beispieldatei: Bringt Beispieldaten – entweder vom Benutzer geladen oder Mock-Daten aus der Quellstruktur erstellt – in eine Transformation, um einem Benutzer bei der Identifizierung von Elementen in einer Benutzeroberfläche und beim Testen von Transformationen zu helfen. Zeigt das transformierte Zielresultat für einen bestimmten Satz geladener Daten.
  • Vorschau mit Quelldaten: Bringt Quelldaten von bestimmten Endpunkten – wie beispielsweise 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 Satz geladener Daten.
  • Testskript: Ermöglicht einem Benutzer, Skripte zu testen, einschließlich Funktionen, die Daten zurückgeben könnten – wie beispielsweise von einer Datenbank, Salesforce oder NetSuite-Abfrage – oder Skripte, die von einer API zurückgegebene Variablenwerte anzeigen.
  • Testabfrage: Ermöglicht einem Benutzer zu testen, ob eine Abfrage gültig ist und während der Konfiguration bestimmter Endpunkt-Aktivitäten, wie beispielsweise für eine Datenbank- oder Salesforce-Abfrage, ein Beispiel von Daten vom Endpunkt zurückgibt.

KI-Services

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

security ai

Wichtig

Nur anonymisierte, nicht vertrauliche Daten werden sicher mit OpenAI geteilt.

Jitterbit nutzt KI-Services zur Datenverarbeitung mit diesen Funktionen:

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

iPaaS-Sicherheitstopologien

Jedes Integrationsprojekt oder jeder Service, einschließlich APIs, lässt sich mit den nachfolgend beschriebenen Sicherheitstopologien bereitstellen. Je nach unmittelbaren und/oder spezifischen Umgebungsanforderungen sollten Sie die Topologie wählen, die den Datenanforderungen und Governance-Richtlinien Ihrer Organisation entspricht. Diese Bereitstellungsarchitekturen mit zugehörigen Sicherheitstopologien werden wie folgt zusammengefasst und in diesem Abschnitt detailliert beschrieben.

  • 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 Teile des Systems 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 es, die Bereitstellungsoptionen je nach Situation ad hoc zu wechseln. Diese Flexibilität bietet folgende Vorteile:

  • Höchste Verarbeitungsleistung: Die Leistung lässt sich durch Edge Processing verbessern, bei dem Agenten dort platziert werden, wo sich die Daten befinden.
  • Einfache Verwaltung: Remote-Verwaltung ist auch für private/lokale Bereitstellungen verfügbar.
  • Sicherheit und Datenschutz: Die gesamte Verarbeitung erfolgt direkt durch die Agenten ohne Offenlegung gegenüber Dritten über die unmittelbaren Quell- und Zielverbindungen hinaus.

Sicherheitstopologie für vollständige Cloud-Bereitstellung

Kunden, die Integrationen durchführen müssen, bei denen alle ihre Datenquellen über die Cloud zugänglich sind, können ihre Projekte in Harmony-Umgebungen bereitstellen und ihre Projekte in 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 Geschäftsdaten von Kunden zu. Jitterbit-Agenten innerhalb dieser Agent-Gruppe verarbeiten Geschäftsdaten und übermitteln sie an alle erforderlichen Zielsysteme. Die Daten fließen innerhalb des Jitterbit-Netzwerks mit HTTPS.

Hinweis

Alle oben erwähnten Daten bleiben für kurze Zeit in der sicheren Betriebsumgebung von Harmony erhalten.

Kunden mit Richtlinien, die Cloud-Nutzung nicht zulassen oder übermäßige Haftungs- und Freistellungsgarantien erfordern, sollten überprüfen, ob die Jitterbit Master Subscription Agreement und die Datenschutzrichtlinie den Anforderungen bezüglich Branchenvorschriften, Kundenbestimmungen, Kundenfreistellung und Kundenverbindlichkeiten entsprechen.

Sicherheitstopologie für Hybrid-Bereitstellung

In einem Hybrid-Bereitstellungsszenario werden bestimmte Teile des Systems selbst gehostet und der Rest von Jitterbit verwaltet. Beispielsweise möchten Sie möglicherweise keine Datenbanken und Apps für Cloud-Systeme, einschließlich Jitterbit, freigeben, wenn die Anforderungen Ihrer Organisation nicht zulassen, dass Daten in der Cloud (außerhalb der Firewall) aufgrund von Datenschutz- und Compliance-Bedenken gespeichert werden.

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 Payload von Apps und Datenquellen über die Payload zurück an das Gateway. Kunden können einschränken, was in den Protokollen gespeichert wird, um zu verhindern, dass diese Daten die Harmony Cloud erreichen.

Sicherheitstopologie für private 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-Plattform verwalten.

security private

Diese Topologie ermöglicht es Benutzern, ihre Agent-Gruppen mit Harmony bereitzustellen und zu verwalten, während die Agent-Gruppe und alle sensiblen 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).