Logische Sicherheit und Architektur von Jitterbit Harmony

Einführung

Die logische Sicherheit besteht aus allen Sicherheitsmaßnahmen, die innerhalb der Harmony-Plattform getroffen werden. In diesem Abschnitt werden die folgenden Themen beschrieben:

• Systemarchitektur
• Entwicklungsprozesse
• Authentifizierung, Berechtigungen und Zugriff
• Datenspeicherung
• KI-Dienste
• iPaaS-Sicherheitstopologien

Systemarchitektur

Harmony ist eine einheitliche Low-Code-Plattform, die iPaaS für Integrationssysteme, API-Management zur Bereitstellung dieser Integrationen als APIs, die Entwicklung von Low-Code-Anwendungen zum Erstellen von Web- und mobilen Apps sowie die EDI-Verarbeitung für Geschäfts-zu-Geschäft-Transaktionen anbietet.

Die Kernkomponenten von Harmony sind mit KI-Funktionen ausgestattet, einschließlich KI-gestützter Assistenten für den Aufbau von Apps und Konnektoren.

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

Low-Code-Designer

Die Low-Code-Designer von Jitterbit sind die Front-End-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-Mikrodienste. Alle Benutzer müssen sich bei Harmony authentifizieren, und die gesamte Kommunikation wird sicher über HTTPS übertragen.

Der Zugriff der Benutzer auf Jitterbit-Anwendungen wird zusätzlich durch eine Kombination aus Berechtigungen für Organisationsrollen und Zugriffslevels für Umgebungen kontrolliert, wie in Authentifizierung, Berechtigungen und Zugriff beschrieben.

Integrationsdesigner

Sowohl Integration Studio (empfohlen) als auch Design Studio können verwendet werden, um Jitterbit iPaaS-Integrationsprojekte zu erstellen, zu konfigurieren, bereitzustellen und zu testen:

• Integration Studio ist eine Harmony-Portal Webanwendung.
• Design Studio ist eine Desktopanwendung, die auf einem Windows- oder macOS-Arbeitsplatz mit Internetzugang installiert werden muss.

Die Kommunikation über Unternehmens-Proxy-Server wird vollständig unterstützt, ebenso wie IP-Whitelistung (Whitelisting), um die Einhaltung des Unternehmens-VPNs sicherzustellen, falls erforderlich.

Beide Anwendungen nutzen die Harmony-Plattform und nutzen die Sicherheitsfunktionen von Harmony, einschließlich Single Sign-On, Benutzerrollen und Organisationsberechtigungen sowie Zugriffslevel für Umgebungen.

Die Rolle eines Harmony-Benutzers muss mindestens _Lese-_Zugriff in einer Umgebung haben, um auf Projekte in Integration Studio oder Design Studio zugreifen zu können. Höhere Zugriffslevel für Umgebungen 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-Dienste und Proxy-APIs erstellen, steuern und konsumieren können.

Jitterbit bietet eine Reihe von Optionen zur Sicherung von APIs:

• Sicherheitsprofile ermöglichen es, dass eine veröffentlichte API nur von einem bestimmten API-Konsumenten oder einer Gruppe von Konsumenten konsumiert werden kann. Sie definieren die Authentifizierungsmethode im Sicherheitsprofil und wählen zwischen anonym, basic, OAuth 2.0 oder API-Schlüssel-Authentifizierung.

• SSL-Only-Modus beschränkt den HTTP-Verkehr auf verschlüsselte Kommunikation. Die Identität der HTTPS-URL wird von Symantec Class 3 Secure Server SHA256 SSL CA verifiziert. Die Verbindung zur HTTPS-URL ist 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üsselwechselmechanismus).

• API-Protokolle zeichnen das Sicherheitsprofil auf, das für den Zugriff auf die API bei jeder API-Anfrage verwendet wird.

Die Rolle eines Harmony-Benutzers muss entweder die Admin-Berechtigung für die Organisation haben oder eine Kombination aus _Lese-_Berechtigung für die Organisation mit mindestens _Lese-_Zugriff in einer Umgebung haben, um auf den API-Manager zuzugreifen.

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

App Builder

App Builder ist ein visuelles Low-Code-Anwendungsentwicklungswerkzeug zur Erstellung von Unternehmensanwendungen für Web und Mobilgeräte.

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

Innerhalb des App Builders werden die folgenden zusätzlichen Sicherheitsoptionen unterstützt:

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

• Single Sign-On (SSO): Die Authentifizierung kann an einen SSO-Anbieter delegiert werden. App Builder unterstützt verschiedene Branchenstandards, einschließlich SAML SSO und WS-Federation. Diese verwenden die PKCS #1-Digital-Signatur-Spezifikation mit SHA-256-Hashes.

• Anspruchsbasierte Authentifizierung: Benutzer-Authentifizierungsanbieter übergeben Ansprüche an den App Builder. Sicherheitsadministratoren ordnen die Ansprüche Benutzerattributen zu, einschließlich der Gruppenmitgliedschaft.

• Lokale Authentifizierung: Lokale Authentifizierung kann verwendet werden, um sich mit einem Passwort zu authentifizieren, das im App Builder gespeichert ist, unter Verwendung der PBKDF2-Schlüsselerzeugungsfunktion mit dem SHA-256-Hashalgorithmus, einer Schlüssellänge von 16 Bytes, einer Salt-Länge von 16 Bytes und 10.000 Iterationen. Sicherheitsfunktionen umfassen Passwortrichtlinien, Passwortablauf, Kontosperrung und Passwortzurücksetzung.

• Sitzungen: Sitzung Speicherrichtlinien sind konfigurierbar. Standardmäßig speichert der App Builder Sitzungsinformationen in der Datenbank. Administratoren können Sitzungen einsehen und Benutzer-Sitzungen zwangsweise abmelden. Das Verfolgen von Sitzungen schützt vor bestimmten Sicherheitsanfälligkeiten, wie z.B. Cookie-Wiederholungsangriffen.

• Rollenbasierte Sicherheit: Der Zugriff auf Daten kann durch die Gruppenzugehörigkeit eines Benutzers gesteuert werden, die die Rollen des Benutzers bestimmt, die die Berechtigungen für Geschäftsdaten festlegen. Bereiche ermöglichen es Administratoren, administrative Aufgaben wie Benutzerbereitstellung und Gruppenzugehörigkeit 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.)

Personenbezogene Daten (PII) sind standardmäßig maskiert. Ein Harmony-Administrator kann die PII-Daten in der EDI-App bis zu 24 Stunden lang offenlegen, danach werden sie wieder maskiert.

Die EDI-App bietet auch die Möglichkeit, die PII eines Handelspartners zu verwalten, indem sie aus Partnerdokumenten entfernt wird.

Eine Harmony-Benutzerrolle mit entweder Lesen oder Admin Organisationsberechtigung gewährt Zugriff auf das Bearbeiten und Ausführen aller Aktionen in der EDI-App. Benutzerrollen mit Lesen Berechtigung haben ebenfalls Zugriff auf das Bearbeiten und Ausführen von Aktionen auf Seiten, die nicht die Admin-Seite sind.

Marketplace

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

Ein Harmony-Benutzerrolle mit entweder Lesen oder Admin Organisationsberechtigung gewährt Zugriff auf Rezepte und Vorlagen im Marketplace. Das Starten eines Rezepts oder einer Vorlage in einer Umgebung erfordert _Schreib-_Zugriff in dieser Umgebung.

Management Console

Management Console ist eine Harmony-Portal Webanwendung zur Verwaltung und Überwachung Ihrer Harmony-Organisation über das 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 eine Vielzahl anderer Verwaltungsaufgaben, die typisch für einen Harmony-Administrator sind:

• Einrichten von Umgebungen, Agenten und Agentengruppen für die Verwendung mit Integrationsprojekten in Integration Studio oder Design Studio.
• Verwalten von Zeitplänen, Variablen, Listenern und Backups für Integrationsprojekte.
• Verwalten des externen Benutzerzugriffs auf das API-Portal.
• Konfigurieren von Zugriffstoken zur Verbindung der EDI-App mit Integration Studio.
• Hinzufügen von Nachrichtenwarteschlangen zur Verwendung mit Integration Studio.

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

• Audit-Protokollinformationen darüber, wer und welche Aktivitäten in der Organisation stattgefunden haben.
• Betriebsprotokolle und Bereitstellungshistorie für Integrationsprojekte in Integration Studio und Design Studio.

Eine Harmony-Benutzerrolle mit Lesen Organisationsberechtigung hat Zugriff auf die Dashboard Seite, während die Admin Organisationsberechtigung Zugriff hat und die Möglichkeit hat, Änderungen vorzunehmen und Aktionen auf allen Seiten der Management Console auszuführen.

Eine Benutzerrolle mit Lesen Organisationsberechtigung kann auf zusätzliche Seiten der Management Console zugreifen, wenn ihr Umgebungszugriffslevel gewährt wird, wie in Authentifizierung, Berechtigungen und Zugriff beschrieben. Das für jede Umgebung definierte Zugriffssteuerungsschichtmodell ist granular, sodass die Konfigurationen, die Benutzer sehen und mit denen sie interagieren können, von den Zugriffssteuerungen des Benutzers abhängen. Zugriffssteuerungen werden auf alle Funktionen angewendet, einschließlich der Suche nach Operationen, dem Ausführen von Operationen, dem Anzeigen von Protokollen usw.

Data Loader Benutzer haben Zugriff auf eingeschränkte Informationen auf den Seiten Dashboard, Runtime Operations und Agents.

Wiederverwendbare Assets

Wiederverwendbare Assets umfassen Connectoren, Anwendungen und Integrationsprojekte sowie die Werkzeuge zu deren Erstellung:

• Connector SDK: Das Jitterbit Connector SDK (Software Development Kit) bietet Entwicklern die Möglichkeit, Connectoren zu erstellen und sie im Integration Studio verfügbar zu machen.
• Connector Builder: Der Jitterbit Connector Builder ist ein Low-Code-Assistent, mit dem jeder einen Integration Studio Connector erstellen kann, der eine über HTTP zugängliche REST-API bereitstellt.
• Fertige Connectoren: Jitterbit und seine Partner bieten Hunderte von vorgefertigten Integration Studio Connectoren für Integrationsprojekte an.
• Fertige Anwendungen: Jitterbit bietet vorgefertigte Web- und native mobile Apps über den App Builder an.
• Vorlagen: Vorgefertigte bidirektionale Integrationslösungen, die einen komplexen Anwendungsfall lösen, werden über den Marketplace bereitgestellt.
• Rezepte: Unidirektionale Integrationsprojekte, die einen einfachen Anwendungsfall lösen, werden über den Marketplace bereitgestellt.

Mikrodienste

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

Die APIs werden mit der gleichen Sicherheitscodierungsstrenge wie Harmony selbst erstellt (siehe Entwicklungsprozesse).

Alle Benutzer dieser APIs müssen mit Harmony authentifiziert sein, und die gesamte Kommunikation wird sicher über HTTPS übertragen.

Plattform-Engines

Die Harmony-Plattform bietet die gesamte Infrastruktur und die Dienste, um Integrationsprojekte bereitzustellen, zu verwalten und auszuführen; benutzerdefinierte Web- und native mobile Apps zu erstellen; APIs zu erstellen, zu steuern und zu konsumieren; sowie EDI-Transaktionen zu verarbeiten.

API-Gateways

Ein API-Gateway ist ein Dienst, der die Richtlinien und Sicherheitsprofile durchsetzt, die für APIs mit der API-Manager Webanwendung erstellt wurden. Die Konnektivität zu über den API-Manager veröffentlichten APIs erfolgt entweder über Jitterbits Cloud-API-Gateway oder ein privates API-Gateway.

Die API-Gateways übernehmen diese Sicherheitsaufgaben, die mit der Annahme und Verarbeitung von Aufrufen an eine API verbunden sind:

• Verkehrsmanagement
• Autorisierung und Zugriffskontrolle
• Ratenbegrenzung
• Verarbeitung von API-Nutzlasten

Sicherheitsfunktionen werden auf API-Ebene oder Sicherheitsprofilebene konfiguriert und werden im API-Gateway zwischengespeichert, das während der API-Ausführung referenziert wird.

Jitterbits Cloud-API-Gateway wird von Jitterbit verwaltet, gewartet und gehostet und erfordert keine Konfiguration.

Ein privates API-Gateway ist ein lokales Gateway zur Verarbeitung von APIs direkt von Ihren eigenen Servern. Ein privates API-Gateway kann ausschließlich auf ein internes Netzwerk hinter einer Firewall beschränkt sein und ist möglicherweise nicht über das Internet zugänglich, obwohl bestimmte Jitterbit-Dienste auf die Zulassungsliste gesetzt werden müssen (whitelisted). Bei einem privaten API-Gateway durchlaufen die API-Antwortnutzlasten niemals die Systeme von Jitterbit.

Messaging

Die Kommunikation zwischen verschiedenen Jitterbit iPaaS-Komponenten, wie Integration Studio, Agenten und der Harmony-Plattform, erfolgt durch die Verwendung einer Reihe von sicheren Laufzeit-Messaging-Diensten, die auf den Java Messaging Services (JMS) APIs basieren, die in der Java-Plattform enthalten sind. Diese APIs sind intern für Harmony, und Kunden haben keinen Zugriff auf diese APIs.

Agenten umfassen Listener für den JMS-Messaging-Dienst. Alle Agenten, die auf Anfragen hören, authentifizieren sich stark und erhalten eine autorisierte Sitzung im Harmony-Messaging-Netzwerk. Sie können nur auf Anfragen für ihre speziellen Agentengruppen oder auf Anfragen, die direkt an sie über Harmony gerichtet sind, hören. Nachrichten werden niemals an Agenten gesendet; Agenten holen sie immer über HTTPS ab. Dies ermöglicht es Agenten, hinter Unternehmensfirewalls zu arbeiten und geschützt zu bleiben, ohne Ports öffnen zu müssen, die eingehenden Verkehr aus dem Internet zulassen würden.

Agents

Die in Integration Studio und Design Studio Projekten entworfenen Integrationsprozesse werden auf Agents ausgeführt, entweder unter Verwendung einer Jitterbit-Cloud-Agentengruppe oder privater Agents und einer privaten Agentengruppe.

Diese Prozesse können vollständig in der Cloud ausgeführt werden, ohne dass Software oder die erforderliche Infrastruktur beschafft oder verwaltet werden muss. Diejenigen, die sich entscheiden, Agents entweder vor Ort oder in einem hybriden Modus bereitzustellen, haben die Flexibilität, ihre Integrationsprozesse durch die Bereitstellung privater Agents hinter der Firewall auszuführen, wodurch sie eine größere Kontrolle darüber erhalten, wohin ihre Daten fließen.

Jitterbit erkennt an, dass Kunden die Notwendigkeit haben, dass ihre Integrationsprozesse mit Anwendungen kommunizieren, die aus verschiedenen Sicherheits- und Compliance-Gründen hinter Unternehmensfirewalls betrieben werden.

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

Während das System die Bereitstellung, den Einsatz und das Management von Integrationsprojekten vereinfacht, bietet es den Benutzern auch die Flexibilität, ihre Integrationsoperationen mithilfe abtrennbarer privater Agentengruppen auszuführen. Diese sind eigenständige Teilsysteme, die hinter Unternehmensfirewalls oder in dedizierten privaten Clouds installiert werden können.

Die Trennung von Integrationsdesigns, die auf Harmony gespeichert sind, von der Integrationsausführung, die auf Agentengruppen erfolgt, ermöglicht es den Kunden, den Zugriff und den Fluss sensibler Geschäftsdaten zu steuern.

Cloud-Agentengruppe

Cloud-Agents sind Dienste, die als Backend as a Service (BaaS) bekannt sind und entwickelt wurden, um die Bedürfnisse der Kunden nach Bedarf zu verarbeiten und zu bedienen. Sie führen ihre gesamte Arbeit ereignisgesteuert aus, wodurch die Notwendigkeit für jegliche Einrichtung, Konfiguration oder Verwaltung, die traditionell mit "immer aktiven" Serversystemen verbunden ist, die hinter Anwendungen stehen, entfällt.

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

Um die Sicherheit zu erhöhen und die Privatsphäre zu schützen, sind die Jitterbit-Cloud-Agenten so programmiert, dass lokal verarbeitete Daten nicht persistent sind; sie werden nur für die minimal notwendige Zeit verwendet, um den beabsichtigten Prozess abzuschließen, und anschließend gelöscht.

Wenn die Jitterbit-Cloud-Agenten-Gruppe eine Integration durchführt, stellt sie eine direkte Verbindung zu der Anwendung her, die eine Datenintegration benötigt. Anschließend liest und veröffentlicht sie Daten in diesen Anwendungen.

Metadaten, die in der Jitterbit-Cloud-Agenten-Gruppe gespeichert sind, werden in verschlüsselten Amazon S3-Buckets aufbewahrt, die nur für die Agenten-Gruppe zugänglich sind.

Für Kunden, die Anwendungen innerhalb ihrer Firewall betreiben müssen, oder für Benutzer, die Integrationen unter strengen regulatorischen Vorgaben durchführen, die es verbieten, dass Daten entweder außerhalb eines bestimmten geografischen Bereichs reisen oder in der Cloud gespeichert werden, empfiehlt Jitterbit die Verwendung einer privaten Agenten-Gruppe.

Private Agenten und private Agenten-Gruppe

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

Agenten, die zu privaten Agenten-Gruppen gehören, authentifizieren sich und kommunizieren über HTTPS mit Jitterbit Harmony. Private Agenten-Gruppen, die hinter Unternehmensfirewalls bereitgestellt werden, können so konfiguriert werden, dass sie über einen Unternehmensproxy-Server kommunizieren. Wenn Ihre Organisation ausgehende Verbindungen nicht einschränkt, gibt es keine zusätzlichen Netzwerkanforderungen, wie das Öffnen von Ports innerhalb der Unternehmensfirewalls. Wenn ausgehende Verbindungen eingeschränkt sind, müssen Sie bestimmte Jitterbit-Dienste auf die Erlaubenliste setzen (whitelist).

Der Code für private Agenten wird mit der gleichen Programmiergenauigkeit erstellt wie der Harmony-Code (siehe Entwicklungsprozesse).

Während private Agentengruppen strengen Sicherheitsanforderungen gerecht werden, ist der Benutzer oder Kunde für die Installation und Verwaltung seiner privaten Agenten verantwortlich. In der Cloud-Agentengruppe bietet Jitterbit sofortige Hochverfügbarkeit und Skalierbarkeit, die dem entspricht, was von einer serverlosen Technologie erwartet wird. In privaten Agentengruppen liegt jedoch die Sicherheit und Skalierbarkeit der privaten Agenten in der Verantwortung des Kunden (obwohl die Hochverfügbarkeit weiterhin von der Harmony-Plattform gewährleistet wird, wenn mehr als ein Agent innerhalb einer privaten Agentengruppe verwendet wird). Jitterbit gibt Best-Practice-Empfehlungen für das Hosting von privatem Agentencode in Systemanforderungen für Jitterbit private Agenten.

Listening service

Der Listening service ist ein Anwendungsdienst, der auf einem privaten Agenten läuft und von bestimmten Integrationsstudio-Connectors mit Listening-Funktionen genutzt wird. Der Listening-Service bietet asynchrone Ereignisverarbeitungsfunktionen für auf dem Agenten bereitgestellte Operationen.

1. Eine Operation, die einen Connector mit einer konfigurierten Ereignis-Listening-Aktivität enthält, wird bereitgestellt und für das Listening aktiviert.
2. Der Listening-Service innerhalb des Agenten startet einen Listener für diese Operation.
3. Der Listener beginnt aktiv, auf Ereignisbenachrichtigungen vom Endpunkt zu hören.
4. Wenn ein Ereignis am Endpunkt eintritt, veröffentlicht es eine Ereignisbenachrichtigung, die von seinen Abonnenten empfangen werden kann.
5. Der Listener nimmt die Ereignisbenachrichtigungsnachricht auf.
6. Wenn sich ein Agent in der Agentengruppe befindet, leitet der Listener die Ereignisnachricht an die Operation weiter. Wenn die Agentengruppe die Mindestanzahl enthält, um vollständige Listening-Service-Funktionen zu ermöglichen, wird die Ereignisnachricht an den Agenten mit der geringsten Arbeitslast weitergeleitet.
7. Nach Erhalt der Ereignisbenachrichtigung wird die Operation eine nachgelagerte Operation auslösen.

Transaktionsprotokolle

Transaktionsprotokolle, auch als Betriebsprotokolle bezeichnet, sind die Protokolle, die generiert werden, wenn eine Operation im Integration Studio oder Design Studio ausgeführt wird. Sie enthalten Informationen über die Operation, einschließlich ihres 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 Operationen auch detaillierte Protokollnachrichten. Die Cloud-Protokollierung ist immer für Jitterbit-Cloud-Agentengruppen aktiviert und kann optional für private Agenten deaktiviert werden.

Betriebsprotokolle, einschließlich detaillierter Protokollnachrichten von sowohl Cloud-Agenten als auch privaten Agenten, sowie Eingabe- und Ausgabedaten von Komponenten innerhalb der Betriebsprotokolle, werden 30 Tage lang aufbewahrt.

Design-Repository

Jitterbit speichert alle Projekte, die in Harmony bereitgestellt werden, in einem Multi-Tenant-Design-Repository. Dieses Projekt-Repository basiert auf einer Multi-Tenant-Datenbankarchitektur, die eine logische Partitionierung von Projekten nach Organisation und in den meisten Fällen nach Umgebung ermöglicht. Insbesondere isoliert und sichert Harmony Kundenprojekte mit den folgenden Maßnahmen:

• Sichere Datenbankarchitektur: Beinhaltet getrennte Datenbank- und getrennte Schemaarchitektur.
• Sichere Verbindungen oder Tabellen: Verwendet vertrauenswürdige Datenbankverbindungen.
• Verschlüsselung: Verschleiert kritische Daten, sodass diese für unbefugte Parteien unzugänglich bleiben, selbst wenn sie in den Besitz dieser Daten gelangen.
• Filterung: Verwendet eine Zwischenebene zwischen einem Mandanten und einer Datenquelle, die wie ein Sieb wirkt, sodass es für den Mandanten so aussieht, als ob seine Daten die einzigen Daten in der Datenbank sind.
• Zugriffskontrolllisten: Bestimmt, wer auf Daten in der Anwendung zugreifen kann und was sie damit tun können.

Projekte enthalten typischerweise Anmeldeinformationen wie Benutzername und Passwort, die verwendet werden, um sich mit verschiedenen Endpunkten zu verbinden. Diese Informationen sind innerhalb des Multi-Tenant-Repositorys verschlüsselt.

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

Kunden haben keinen direkten Zugriff auf dieses Repository. Die verschiedenen Jitterbit iPaaS-Komponenten, wie Integrationsdesigner und Cloud-Agenten, verwenden APIs, um auf das Repository zuzugreifen. Nach der Authentifizierung und Validierung der Zugriffskontrolle erfolgt die gesamte Kommunikation mit dem Repository über verschiedene API-Schichten. Neben der Kontrolle des Zugriffs auf die Edge-APIs über HTTPS und serverseitige Sitzungen müssen APIs die Zugriffskontrolle der Benutzer durch umgebungsbasierte und rollenbasierte Zugriffskontrolllisten (RBAC) validieren. Diese Listen stellen sicher, dass Benutzer die Systeme nur basierend auf den von einem Organisationsadministrator (Benutzer mit Admin-Berechtigung) erteilten Berechtigungen einsehen, darauf zugreifen und ändern können. Darüber hinaus ist die Granularität des Audit-Trails pro Kunde konfigurierbar.

Die rotierende Aktivitätsdatenbank von Harmony speichert Informationen zum Laufzeitstatus sowie Protokolle der laufenden Operationen aller Harmony-Benutzer.

Die Aktivitätsdatenbank basiert auf einer Multi-Tenant-Architektur, und während die Aktivitätsdaten aller Benutzer in derselben Datenbank gespeichert 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 einsehen können, auf die sie Zugriff haben.

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

Der Zugriff auf die Aktivitätsdatenbank erfolgt über eine Reihe von APIs. Das Aktivitätsprotokoll verwendet ähnliche APIs und Infrastruktur für Zugriffskontrolllisten (ACL) wie das Projekt-Repository.

Dateidienste

Harmony umfasst eine Reihe von Dateidiensten, die zum Speichern von Dateien, wie Schemas und Anpassungen, verwendet werden. Alle Dateien werden im AWS S3-Dienst gespeichert und können nur über die Harmony-Plattform zugegriffen werden und nicht direkt.

Schema-Repository

Um Integrationen von einer Vielzahl von Endpunkten zu unterstützen, speichert Harmony verschiedene Arten von Schemas, wie WSDL, XSD, JTR und DTDs.

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

Anpassungs-Repository

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

Um die Funktionen des Integration Studio zu erweitern, können Sie Ihre eigenen benutzerdefinierten Connectoren mit dem 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 übernehmen Aufgaben wie Anmelden, Benutzerverwaltung, Bereitstellung, Planung, Organisationsverwaltung usw.

Anwendungsentwicklungsumgebung

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

• Vor Ort: Die App Builder-Umgebung wird vor Ort beim Kunden bereitgestellt. Die Web- und Datenbankserver sowie die App Builder-Umgebung befinden sich alle auf der Hardware des Kunden 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 alle 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-Laufzeit-Engine

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

Sobald eine Transaktion generiert wird, wird sie in der Transaktionsdatenbank gespeichert, während sie auf die Verarbeitung wartet. Das EDI-Dokument bleibt bestehen, bis es gemäß den Archivierungseinstellungen für den Handelspartner archiviert wird. Der Status eines EDI-Dokuments kann jederzeit über die EDI Transaktionen Seite ü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 dessen Untergruppen sowie xCBL-Standards.

Messaging-System

Der Message Queue (MQ) Service ist ein cloudbasierter, mandantenfähiger Messaging-Queue-Service zum Erstellen und Verwalten von Warteschlangen und Nachrichten. Er ermöglicht es Ihnen, Integrationen zu erstellen, die von den Endpunkten, die Sie integrieren, entkoppelt sind. Der MQ-Service wird mit dem Integration Studio Jitterbit MQ Connector verwendet.

1. Daten werden von einem Quellendpunkt abgerufen, beispielsweise durch die Verwendung eines Integration Studio Connectors. Die abgerufenen Daten können dann in eine Nachricht umgewandelt werden, die vom Jitterbit MQ Connector konsumiert wird.

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

3. Nachrichten können dann von einer Nachrichtenwarteschlange mit einem Jitterbit MQ Get oder Get Bulk activity abgerufen werden.

4. Die von einer Nachricht abgerufenen Daten können dann als Eingabe verwendet werden, die von einem Zielendpunkt konsumiert wird, beispielsweise durch die Verwendung eines Integration Studio Connectors.

5. Sobald die Daten verarbeitet sind, kann die Nachricht entweder bestätigt werden (unter Verwendung der Acknowledge-Aktivität) oder negativ bestätigt werden (unter Verwendung der NACK-Aktivität). Wenn die Nachricht vor dem Timeout von 30 Minuten weder bestätigt noch negativ bestätigt wird, steht die Nachricht zur erneuten Abholung aus der Warteschlange entweder durch eine Get oder Get Bulk-Aktivität zur Verfügung.

Analytics und Protokollierungs-Engines

Die Harmony-Plattform bietet Analysen und Protokollierungsinformationen, die über das Harmony-Portal oder direkt auf privaten Agenten-Servern abgerufen werden können.

Entwicklungsprozesse

Jitterbit entwickelt und verbessert seine Anwendungen durch die Anwendung solider Praktiken des Software-Entwicklungszyklus (SDLC), wie zum Beispiel:

• 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 sicherer Authentifizierungs- und Protokollierungsfunktionen.
• Entfernen von Entwicklungs-Konten, IDs und Passwörtern aus Produktionsumgebungen.
• Einhaltung strenger Änderungsmanagementpraktiken für Code-Updates sowie Patches.
• Trennung von Test- und Entwicklungsumgebungen von der Produktion.
• Aufrechterhaltung der Trennung von Aufgaben zwischen Entwicklungs- und Supportmitarbeitern.
• Sicherstellen, dass personenbezogene Daten (PII) nicht in Testumgebungen verwendet werden.
• Entfernen von Test- und Entwicklungs-IDs, bevor der Code in die Produktion migriert wird.
• Durchführung regelmäßiger Code-Überprüfungen.
• Dokumentation von Codeänderungen.
• Einbeziehung von Input und Genehmigung durch erfahrene Entwickler für alle Codeänderungen.
• Abschluss von Funktionalitäts- und Regressionstests vor der Freigabe in die Produktion.
• Aufrechterhaltung von Rückzugsverfahren zur Wahrung der hohen Verfügbarkeit und Integrität.
• Befolgung sicherer Codierungspraktiken gemäß einer SDLC-Richtlinie und Berücksichtigung der Sicherheitsanforderungen für das Entwicklungsteam.
• Überprüfung auf Sicherheitsanfälligkeiten gemäß den Vorgaben des Open Web Application Security Project (OWASP), wie z. B. Injektionsanfälligkeiten, Pufferüberläufe, kryptografische Fehler, Fehlerbehandlung usw.
• Bewertung von Schwachstellen bei jeder Veröffentlichung.
• Durchführung jährlicher Penetrationstests.

Authentifizierung, Berechtigungen und Zugriff

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

Registrierung und Authentifizierung

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

Die Passwortstärke, -komplexität und Attribute wie die Zwei-Faktor-Authentifizierung sind anpassbar, damit die Kunden die Anforderungen ihrer Sicherheitsrichtlinie erfüllen können. Administratoren können auch den Zugriff auf bestimmte Mitgliederdomänen einschränken oder verlangen, dass die IP-Adressen der Benutzer innerhalb eines bestimmten Bereichs liegen. Diese Einstellungen werden in den Richtlinien der Organisation festgelegt.

Nach 5 fehlgeschlagenen Anmeldeversuchen mit den Anmeldeinformationen des Harmony-Kontos werden die Konten für 30 Minuten gesperrt. Benutzer werden per Email benachrichtigt, wenn der Grund für eine fehlgeschlagene Anmeldung auf die Kontosperrung zurückzuführen ist. Wenn ein Benutzer gesperrt ist, ist sein Status auf der Seite Management Console > Benutzerverwaltung im Tab Harmony-Benutzer Inaktiv. Um die Sperrung aufzuheben, muss er 30 Minuten warten, bevor er erneut versucht, sich mit seinem bestehenden Passwort anzumelden, oder sein Passwort über den Link Ich habe mein Passwort vergessen auf der Anmeldeseite des Harmony-Portals zurücksetzen. Passwörter dürfen nicht wiederverwendet werden. Wenn eine Passwortänderung aus irgendeinem Grund fehlschlägt, einschließlich wenn das Passwort zuvor verwendet wurde, wird aus Sicherheitsgründen eine allgemeine Fehlermeldung zurückgegeben.

Wenn Single Sign-On (SSO) aktiviert ist, werden solche Anforderungen stattdessen vom Identitätsanbieter verwaltet. SSO wird ebenfalls von einem Administrator aus den Richtlinien der Organisation aktiviert. Jitterbit unterstützt diese wichtigen 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 die Benutzer mit den Anmeldeinformationen ihres konfigurierten Identitätsanbieters im Harmony-Portal und im Design Studio an.

Alle Kommunikationen mit Harmony erfolgen über HTTPS (höher als TLS 1.2).

Benutzerrollen und Organisationsberechtigungen

Jeder Harmony-Benutzer hat ein persönliches, rollenbasiertes Konto und Anmeldeinformationen, in denen persönliche Integrationswerkzeuge und Projekte sicher gespeichert sind.

Sobald der Benutzer authentifiziert ist, 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.

Die Berechtigungen sind rollenbasiert und pro Umgebung pro Organisation wählbar/konfigurierbar. Jede Organisation hat zwei Standardrollen:

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

Zusätzlich zu den Berechtigungen Admin und Read stehen diese unabhängigen Berechtigungen zur Verfügung, die Rollen zugewiesen werden können:

• Agent-Install: Ermöglicht einem Benutzer die Installation von Agenten, bietet jedoch 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 ohne Wissen über die Plattform herzustellen.
• ApiConsumer: In Kombination mit den Zugriffslevels der Umgebung ermöglicht es den Zugriff auf die OpenAPI-Dokumentation in einer Umgebung. Allein ermöglicht diese Berechtigung den Zugriff auf die API-Portal Seite.

Administratoren können neue Rollen zur Organisation hinzufügen und andere Harmony-Benutzer einladen, sich anzuschließen, wenn sie im Team an der Gestaltung, dem Bau, dem Testen und der Verwaltung ihrer Projekte, APIs und EDI-Daten arbeiten müssen. Benutzer können mehreren Rollen innerhalb einer Organisation zugewiesen werden.

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

Umgebungen und Zugriffslevel

Umgebungen werden verwendet, um die Vermögenswerte einer Organisation für diese Harmony-Anwendungen zu segregieren:

• Integrationsstudio- und Designstudio-Integrationsprojekte werden in Umgebungen bereitgestellt, die mit Agentengruppen verbunden sind.
• API-Manager-APIs werden in Umgebungen erstellt und veröffentlicht.
• Handelspartner werden hinzugefügt und EDI-Daten werden pro Umgebung verarbeitet.

Umgebungen repräsentieren einen bestimmten Zustand eines Projekts oder einer API. Viele Projekte existieren in verschiedenen Phasen innerhalb unterschiedlicher Umgebungen. Zum Beispiel könnte eine gängige Projektlebenszykluskonfiguration drei Umgebungen haben: Entwicklung, Test und Produktion. Ein Projekt oder eine API kann in verschiedenen Zuständen innerhalb jeder Umgebung existieren.

Organisationsadministratoren (Benutzer mit Admin-Berechtigung) verwalten den Zugriff auf jede Umgebung mithilfe von rollenbasiertem Zugriff. Zum Beispiel 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 Zugriffslevel für Umgebungen:

• Protokolle anzeigen: Ermöglicht einem Benutzer, die Betriebsprotokolle von Integrationsstudio und Designstudio über die Management Console Runtime Operations Seite in einer bestimmten Umgebung anzuzeigen, bietet jedoch keine Sichtbarkeit oder Kontrolle über Projekte. Dies ermöglicht es Benutzern, Unterstützung zu leisten, aber keine Projekte zu ändern, die in kritischen Umgebungen wie der Produktion bereitgestellt sind. Der Zugriff ist auf die Anzeige der Tabelle der Operationen beschränkt und umfasst keinen Zugriff auf Protokollnachrichten.

• Lesen: Ermöglicht einem Benutzer den schreibgeschützten Zugriff auf Integrationsstudio- und Designstudio-Projekte sowie API-Manager-APIs in einer bestimmten Umgebung. Dies kann verwendet werden, um Vorlagen zu teilen oder Benutzern zu ermöglichen, Vermögenswerte anzuzeigen, aber nicht zu ändern. Dieses Zugriffslevel bietet auch schreibgeschützten Zugriff auf die Management Console Projekte, Umgebungen und Agenten Seiten.

• Execute: Ermöglicht es Benutzern, Operationen im Integration Studio und Design Studio auszuführen und Protokollnachrichten auf der Management Console Runtime Operations Seite innerhalb einer bestimmten Umgebung anzuzeigen. Dies ist eine gängige Zugriffskontrolle für Testumgebungen und wird häufig Benutzern gewährt, die Projekte unterstützen müssen, da sie möglicherweise sowohl Aufgaben testen als auch ausführen müssen.

• Write: Ermöglicht vollständige Kontrolle über eine bestimmte Umgebung. Benutzer, die einer Rolle mit Write-Zugriff angehören, können Änderungen vornehmen und Aktionen innerhalb dieser speziellen Umgebung durchführen. Dazu gehört das Bereitstellen von Operationen im Integration Studio und Design Studio; das Bearbeiten und Veröffentlichen von APIs im API Manager; das Starten von Rezepten und Vorlagen aus dem Marketplace; sowie das Durchführen von Aktionen auf den Seiten Projects, Environments und Agents der Management Console.

Data storage

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

User data

Wenn sich ein Benutzer registriert und für Harmony anmeldet, muss er die folgenden Informationen angeben, die im Projektrepository gespeichert werden: Vorname, Nachname, Email und Telefonnummer. Firma, Firmenadresse und Firmenwebsite können angegeben werden, sind jedoch 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.

User authentication

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:

• User ID: Die Benutzer-ID, die mit jedem Anmeldeversuch verknüpft ist. Dies hilft, zu identifizieren, welcher Benutzer sich anzumelden versucht, und ihre Aktivitäten zu verfolgen.
• Timestamp: Der Zeitpunkt jedes Anmeldeversuchs. Dies hilft, zu identifizieren, wann ein Benutzer versucht, sich anzumelden, und ihre Aktivitäten im Laufe der Zeit zu verfolgen.
• IP address: Die IP-Adresse, die mit jedem Anmeldeversuch verknüpft ist. Dies hilft, zu identifizieren, von wo der Benutzer versucht, sich anzumelden, und potenzielle Sicherheitsverletzungen zu erkennen.
• Device information: Informationen über das Gerät, das zur Anmeldung verwendet wird, wie das Betriebssystem, die Browserversion und den Gerätetyp. Dies hilft, potenzielle Sicherheitsverletzungen zu identifizieren und Probleme zu beheben, die auftreten können.
• Logout events: Jedes Mal, wenn sich ein Benutzer abmeldet. Dies hilft sicherzustellen, dass Benutzer abgemeldet sind, und ihre Aktivitäten zu verfolgen.

Benutzerautorisierung

Die Benutzerautorisierung bestimmt, ob ein Benutzer die entsprechenden Berechtigungen hat, 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 Informationen zur Benutzerautorisierung 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 zu verfolgen.
• Aktions-ID: Die ID der Aktion, die der Benutzer auszuführen versucht. Dies hilft, 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, potenzielle Sicherheitsverletzungen zu identifizieren und die Ressourcennutzung sowie die Aktionsnutzung zu verfolgen.
• Autorisierungsrichtlinien: Informationen über die Autorisierungsrichtlinien, wie den Namen und die Version der Richtlinie sowie relevante Konfigurationsoptionen. Dies hilft, Autorisierungsprobleme zu beheben und Änderungen an Richtlinien zu überprüfen.

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 Informationen zum Datenzugriff 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 die er ändern möchte, und die Datennutzung zu verfolgen.
• Zugriffsart: Die Art des Zugriffs, der versucht wird, wie z. B. Lesen oder Schreiben. Dies hilft zu identifizieren, ob der Benutzer versucht, Daten anzuzeigen oder zu ändern.
• Zugriffsergebnis: Das Ergebnis jedes Zugriffsversuchs auf die Daten, 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 zu verfolgen.

Konfigurationsänderungen

Konfigurationsänderungen beziehen sich auf Modifikationen, die an den Konfigurationseinstellungen eines Systems oder einer Anwendung vorgenommen werden.

Zusätzlich zu Benutzer-ID und Zeitstempel (beschrieben in Benutzerauthentifizierung) werden folgende Informationen zu Konfigurationsänderungen protokolliert:

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

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 Informationen zu Systemereignissen protokolliert:

• Ereignistyp: Der Typ des aufgetretenen Ereignisses, wie z.B. ein Fehler, eine Warnung oder ein informatives Ereignis. Dies hilft, die Schwere des Ereignisses zu identifizieren und die Fehlersuche zu priorisieren.
• Ereignisbeschreibung: Eine Beschreibung des Ereignisses, einschließlich etwaiger Fehlermeldungen oder anderer relevanter Details. Dies hilft, zu identifizieren, was passiert ist, und eventuelle Probleme, die auftreten könnten, zu beheben.
• Ereignisquelle: Die Quelle des Ereignisses, wie z.B. die Anwendung, der Systemprozess oder das Gerät. Dies hilft, zu identifizieren, wo das Ereignis aufgetreten ist, und eventuelle Probleme auf spezifische Komponenten des Systems zu isolieren.
• Ereignisstatus: Der Status des Ereignisses, einschließlich ob es gelöst wurde oder noch andauert. Dies hilft, die Lösung des Ereignisses nachzuverfolgen und sicherzustellen, dass alle Probleme ordnungsgemäß behandelt 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 Informationen zur API-Nutzung protokolliert:

• API-Endpunkt: Der spezifische API-Endpunkt, der aufgerufen wurde. Dies hilft, die aufgerufene Funktionalität zu identifizieren und die API-Nutzung nach Endpunkt zu verfolgen.
• Anforderungsparameter: Die Parameter, die in der API-Anforderung übergeben wurden. Dies hilft, die verwendeten Daten im API-Aufruf zu identifizieren und Probleme zu beheben, die auftreten können.
• Antwortstatus: Der Status der API-Antwort, einschließlich etwaiger Fehlermeldungen oder anderer relevanter Details. Dies hilft zu identifizieren, ob der API-Aufruf erfolgreich war oder nicht, und Probleme zu beheben, die auftreten können.

Integrationsprojektdaten

Um ein Integrationsprojekt auszuführen und zu verwalten, muss ein Benutzer das Projekt in Harmony bereitstellen. Das Projekt speichert Entwurfs- und Implementierungsdetails, um den Agentengruppen Anweisungen zu geben, welche Aktivitäten sie durchführen müssen. Dies umfasst Folgendes:

• Integrationsoperationen, die beschreiben, was eine Einheit der Integration tun wird. Zum Beispiel, alle Änderungen an Kundendaten im CRM-System mit Kundendaten im ERP-System zu synchronisieren.
• Transformationen und Skripte, die beschreiben, wie diese Daten vom Quellsystem zum Zielsystem übertragen 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-Objektrepräsentationen sein.
• Verbindungen und Endpunkte, die als Quellen oder Ziele verwendet werden. Während diese feste Werte wie Systemadressen und Anmeldeinformationen sein können, können sie auch über Variablen referenziert werden, die in internen Datenbanken für Kunden gespeichert werden, die ihre eigenen Anmeldeinformationsspeicher implementieren.
• Zeitpläne und Benachrichtigungen, die bestimmen, wann Batch-Operationen ausgeführt werden müssen und was im Falle von erfolgreichen und fehlgeschlagenen Ergebnissen zu tun ist.
• API-Endpunkte, die Agenten und Agentengruppen informieren, wie APIs exponiert werden sollen, damit externe Systemereignisse Jitterbit-Integrationen aufrufen und auslösen können.

Persistente Daten sind im Ruhezustand gesichert durch:

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

Persistente Cloud-Daten sind während der Übertragung gesichert durch:

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

Integrationsaktivitätsprotokoll

Wenn eine Agentengruppe eine Integrationsoperation ausführt, synchronisiert sie ihre Protokolle mit dem rotierenden Aktivitätsprotokoll von Harmony für mehrere Mandanten. Dies umfasst die folgenden Informationen:

• Status: Der Zustand einer Operation (z. B. ausstehend, laufend, erfolgreich, fehlgeschlagen).
• Agent: Welcher Agent in der Agentengruppe die Operation ausgeführt hat.
• Zeitpunkt: Wann die Ausführung der Operation eingereicht, gestartet und abgeschlossen wurde.
• Eingereicht von: Wer die Anfrage zur Ausführung der Operation eingereicht hat.
• Verarbeitete Datensätze: Die Anzahl der aus dem Quellsystem verarbeiteten Datensätze und wie viele Datensätze an das Ziel übermittelt wurden.
• Nachricht: Alle zusätzlichen Informationen, die für die Fehlersuche bei einem fehlgeschlagenen Ergebnis relevant sind, oder Zusammenfassungsinformationen, die ein Benutzer Jitterbit ausdrücklich mitteilt, um sie im Protokoll zu schreiben, unter Verwendung der internen Funktion WriteToOperationLog.

Darüber hinaus wird, wenn das Debug-Protokollieren von Operationen in einer Integrationsstudio-Operation aktiviert ist, Komponenten-Eingabe- und Ausgabedaten im Betriebsprotokoll aufgezeichnet.

Die Daten des Betriebsprotokolls werden in der Cloud in einem rotierenden, täglich partitionierten System gespeichert. Die Aktivitäten jedes Tages 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.

Betriebsprotokolle, einschließlich detaillierter Protokollnachrichten von sowohl Cloud-Agenten als auch privaten Agenten sowie Komponenten-Eingabe- und Ausgabedaten innerhalb der Betriebsprotokolle, werden von Harmony 30 Tage lang aufbewahrt.

Agentenprotokolle

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

• Operation-Debug-Protokolle für Cloud-Agenten oder für private Agenten
• Ausführliche Protokolle, die nur auf privaten Agenten zugänglich sind
• Zusätzliche Protokolle, die nur auf privaten Agenten zugänglich sind
• Dateien erfolgreicher verarbeiteter Datensätze
• Dateien fehlgeschlagener verarbeiteter Datensätze

Die Agentengruppen 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 auf ihren eigenen privaten Cloud-Infrastrukturen sichern.

Diese Protokolle sind nützlich für detaillierte Fehlersuche und Prüfungszwecke.

Standardmäßig speichert eine private Agentengruppe Protokolldateien, Debug-Dateien, temporäre Dateien, Transformationsdaten sowie Erfolgs- und Fehlermeldungsdateien für 1 bis 14 Tage, abhängig von der Konfiguration der Datei-Reinigungsdienstregeln.

Integrations-Testdaten, die durch Harmony fließen

Zusätzlich zu den in Harmony gespeicherten Daten können Geschäftsdaten während des Integrationsdesigns durch die Cloud-Plattform fließen. Diese nicht persistente Testdaten fließen, wenn Funktionen wie die folgenden ausgeführt werden:

• Vorschau mit Beispieldatei: Bringt Beispieldaten – entweder vom Benutzer geladen oder aus der Quellstruktur erstellte Mock-Daten – in eine Transformation, um einem Benutzer zu helfen, Elemente in einer Schnittstelle zu identifizieren und Transformationen zu testen. Zeigt das transformierte Zielergebnis für einen bestimmten Satz von geladenen Daten an.
• Vorschau mit Quelldaten: Bringt Quelldaten von bestimmten Endpunkten – wie z.B. von einer Datenbank, Salesforce oder einer NetSuite-Abfrage – in die angezeigte Transformation und zeigt das transformierte Zielergebnis für einen bestimmten Satz von geladenen Daten an.
• Testskript: Ermöglicht es einem Benutzer, Skripte zu testen, die Funktionen enthalten, die Daten zurückgeben könnten – wie z.B. von einer Datenbank, Salesforce oder einer NetSuite-Abfrage – oder Skripte, die die von einer API zurückgegebenen Variablenwerte anzeigen.
• Testabfrage: Ermöglicht es einem Benutzer zu testen, ob eine Abfrage gültig ist und ein Beispiel von Daten vom Endpunkt während der Konfiguration bestimmter Endpunktaktivitäten zurückgibt, wie z.B. für eine Datenbank oder Salesforce-Abfrage.

KI-Dienste

Die Harmony-Plattform ist mit KI-Funktionen ausgestattet, darunter KI-gestützte Assistenten und Chatbots:

Jitterbit nutzt KI-Dienste zur Datenverarbeitung mit diesen Funktionen:

• iPaaS KI-Assistent: Der Connector Builder KI-Assistent (Beta) sendet anonymisierte Eingaben an OpenAI, um ihm beizubringen, die API-Dokumentation zu verstehen, die es verwendet, um einen Integration Studio-Connector zu generieren. Die KI-Mapping-Funktion von Jitterbit (Beta) basiert auf dem eigenen Modell von Jitterbit. Jitterbit sendet keine Transformationsdaten an Modellanbieter.
• APIM KI-Assistent: Der APIM KI-Assistent sendet anonymisierte Eingaben an OpenAI, um Assets im API-Manager zu erstellen und zu veröffentlichen.
• 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 verwendet OpenAI mit Retrieval Augmented Generation (RAG), um öffentliche Informationen abzurufen, die über die Jitterbit-Dokumentation verfügbar sind. AskJB KI ist über das Jitterbit Harmony-Portal und öffentlich auf der Jitterbit-Dokumentationsseite verfügbar.

iPaaS-Sicherheitstopologien

Jedes Integrationsprojekt oder jeder Dienst, einschließlich APIs, kann mit den unten beschriebenen Sicherheitstopologien bereitgestellt werden. Je nach den unmittelbaren und/oder spezifischen Umweltbedürfnissen sollten Sie die Topologie verwenden, die den Datenanforderungen und Governance-Richtlinien Ihrer Organisation entspricht. Diese Bereitstellungsarchitekturen mit den zugehörigen Sicherheitstopologien sind wie folgt zusammengefasst und in diesem Abschnitt detailliert beschrieben.

• Cloud: In der Harmony-Cloud, wo das System und die Skalierung vollständig von Jitterbit verwaltet werden.
• Privat (Vor-Ort, Lokal): Auf einem lokalen Server oder in einer privaten Cloud, wo das System selbst gehostet und lokal verwaltet wird.
• Hybrid: In einem hybriden Modus, wo bestimmte Teile des Systems selbst gehostet werden und der Rest von Jitterbit verwaltet wird.

Darüber hinaus ermöglicht Jitterbit beliebige Kombinationen und Standorte für seine Komponenten und erlaubt es, die Bereitstellungsoptionen ad hoc in verschiedenen Situationen zu wechseln. Diese Flexibilität führt zu folgenden Vorteilen:

• Höchste Verarbeitungsleistung: Die Leistung kann durch die Nutzung von Edge-Processing verbessert werden, bei dem Agenten in der Nähe der Daten platziert werden.
• Einfache Verwaltung: Remote-Management ist auch für private/lokale Bereitstellungen verfügbar.
• Sicherheit und Datenschutz: Alle Verarbeitungen erfolgen direkt durch die Agenten, ohne dass externe Parteien über die unmittelbaren Quell- und Zielverbindungen hinaus Zugriff erhalten.

Vollständige Cloud-Bereitstellungssicherheitstopologie

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-Agentengruppe ausführen.

Hier wird die von Jitterbit betriebene Multi-Tenant-Öffentliche-Cloud-Agentengruppe direkt über das Internet mit HTTPS auf die Geschäftsdaten der Kunden zugreifen. Jitterbit-Agenten innerhalb dieser Agentengruppe verarbeiten Geschäftsdaten und posten sie an jedes erforderliche Zielsystem. Die Daten fließen innerhalb des Jitterbit-Netzwerks über HTTPS.

Kunden, die Richtlinien haben, die die Nutzung der Cloud nicht zulassen oder übermäßige Haftungs- und Entschädigungsgarantien erfordern, sollten überprüfen, ob der Jitterbit Master Subscription Agreement und die Datenschutzrichtlinie den Anforderungen ihrer Branchenvorschriften, Kundenbestimmungen, Kundenentschädigungen und Haftungsbedingungen entsprechen.

Hybride Bereitstellungssicherheitstopologie

In einem hybriden Bereitstellungsszenario sind bestimmte Teile des Systems selbst gehostet, während der Rest von Jitterbit verwaltet wird. Beispielsweise möchten Sie möglicherweise keine Datenbanken und Apps für Cloud-Systeme, einschließlich Jitterbit, zugänglich machen, wenn die Anforderungen Ihrer Organisation es nicht zulassen, dass Daten in der Cloud (außerhalb der Firewall) gespeichert werden, aufgrund von Datenschutz- und regulatorischen Bedenken.

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

Private Bereitstellung Sicherheits-Topologie

In den meisten Unternehmensintegrationsszenarien muss die Agentengruppe sowohl auf interne als auch auf Cloud-Anwendungen zugreifen. Hier würden die Benutzer ihre Projekte in Harmony-Umgebungen bereitstellen, ihre eigenen privaten Agentengruppen innerhalb ihrer Netzwerke installieren, die Zugriff auf ihre Anwendungen haben, und dann diese Agentengruppen verwalten, die über die Harmony-Plattform bereitgestellt werden.

Diese Topologie ermöglicht es den Benutzern, ihre Agentengruppen mit Harmony bereitzustellen und zu verwalten, aber die Agentengruppe und alle sensiblen Geschäftsdaten, die verarbeitet oder gespeichert werden, befinden sich innerhalb ihres Netzwerks. In dieser Topologie kann die private Agentengruppe auf physischen oder virtuellen Serverumgebungen unter Windows oder Linux betrieben werden (siehe Systemanforderungen für private Agenten für weitere Informationen).