Automation Engine

Diese Seite beschreibt die neuen Funktionen, die in dieser Version der Automation Engine implementiert sind:

TLS/SSL-Implementierung

Ab dieser Version verwendet die Kommunikation zwischen der Automation Engine, der Automic Web Interface, der Java API und dem Proxy-Client sowie zwischen der Automation Engine, den TLS/SSL-Agenten (Java-, Windows-, UNIX-Agenten) und dem TLS Gateway TLS/SSL über ein sicheres WebSocket (WSS). Diese Komponenten richten eine Verbindung zum Java-Kommunikationsprozess (JCP) und/oder dem REST-Prozess (REST) ein, die vertrauenswürdige Zertifikate verwenden, um ihre Identität gegenüber anderen Kommunikationspartnern nachzuweisen. Um mit diesen Zertifikaten zu arbeiten, benötigen die Prozesse einen Keystore, der zuvor im pkcs12-Format erstellt werden muss.

Hinweis: Die TLS/SSL-Implementierung gilt nicht für die HP-UX- und ZLINUX (32 Bit)-Agenten, da sie in dieser Version nicht mehr unterstützt werden.

Abhängig von Ihren Sicherheitsanforderungen gibt es verschiedene Optionen für Zertifikate. Durch Verwendung von Zertifikaten, die von einer öffentlichen Zertifizierungsstelle signiert sind, vereinfachen Sie jedoch die TLS/SSL-Installation und -Konfiguration. Stellen Sie sicher, dass Sie die gesamte Vertrauenskette (Zwischen- und Stammzertifizierungsstelle) an das Zertifikat anhängen.

Außerdem müssen Sie die relevanten Parameter in der Konfigurationsdatei (INI) jeder Komponente definieren.

Für die Konfiguration der TLS/SSL-Verbindung wird die Java-Standard-Cipher-Suite des JCP verwendet. Sie können die unterstützten Cipher Suites in der Java-Sicherheitsrichtlinie ändern.

Schulung

Die Broadcom Software Academy bietet zahlreiche kostenlose Online-Schulungen. Falls noch nicht geschehen, registrieren Sie sich bei der Broadcom Software Academy, um von unserem Schulungsangebot zu profitieren.

Der folgende Kurs zu Automic Automation und TLS/SSL ist jetzt verfügbar:

  • Automic Automation TLS und Zertifikate

Weitere Informationen finden Sie unter Kostenlose Online-Kurse

Mehr Informationen:

Neuer REST-Prozess und Java-Kommunikationsprozess (JCP)

Bis Version 12.3 wurde der Java-Kommunikationsprozess (JCP) teilweise verwendet, um einen REST-Endpunkt für die Automation Engine zur Verfügung zu stellen. Der neue REST-Prozess deckt jetzt diese Funktionen ab, während der neue Java-Kommunikationsprozess (JCP) als Kommunikationsprozess (CP) für Komponenten funktioniert, die TLS/SSL und WebSockets verwenden.

Mit der TLS/SSL-Implementierung richten die Automation Engine, die Automic Web Interface, der Proxy-Client, die TLS/SSL-Agenten (Java-, Windows-, UNIX-Agenten) und das TLS Gateway eine Verbindung mit dem neuen Java-Kommunikationsprozess (JCP) ein.

Das heißt, dass aktualisierte Komponenten, die verwendet werden, um eine Verbindung zu einem Kommunikationsprozess (CP) herzustellen, eine Verbindung zu einem Java-Kommunikationsprozess (JCP) herstellen müssen.

Mehr Informationen:

Neue TLS Gateway-Komponente

Das TLS Gateway ist eine neue Komponente der Automation Engine, die Nicht-TLS/SSL-Agenten ermöglicht, eine Verbindung mit der Automation Engine herzustellen. Dadurch können Sie einen dem Industriestandard entsprechenden Kommunikationskanal zwischen Agenten aus früheren Versionen oder den aktuellen BS2000-, NSK-, OS/400-, VMS- und z/OS-Agenten und der Automation Engine verwenden. Das TLS Gateway unterstützt außerdem die sichere Dateiübertragung mit einem oder zwei Nicht-TLS/SSL-Agenten.

Es wird empfohlen, das TLS Gateway in der Nähe der Agenten zu installieren, die es unterstützt, und damit den Abstand Ihres weniger sicheren Kommunikationskanals zu reduzieren. Sie können es jedoch zentral installieren und eine Verbindung zu mehreren Agenten herstellen.

Hinweis: Obwohl das TLS Gateway ein Agentenobjekt ist, ist keine Agentenfunktionalität (Aufgabenausführung, Überwachung, Berichterstellung) integriert. Es verhält sich nur als Proxy, der Meldungen über einen sicheren Kanal sendet.

Wenn Sie nach dem Upgrade auf diese Version dauerhaft andere als TLS-/SSL-Agenten in Ihrem System unterstützen müssen, benötigen Sie das TLS Gateway. In diesem Fall wird empfohlen, Ihre Kommunikationsprozesse (CPs) weiter auszuführen. Andernfalls können Sie, sobald Sie Agenten auf ihre TLS/SSL-Versionen aktualisiert haben, die Kommunikationsprozesse (CPs) und die TLS Gateway-Instanzen deinstallieren.

Das TLS Gateway kann auch so konfiguriert werden, dass es einen Kommunikationsprozess (CP)-Port für andere als TLS-/SSL-Agenten zur Verfügung stellt, falls erforderlich. Dies ist in Systemen hilfreich, auf denen keine Kommunikationsprozesse (CPs) ausgeführt werden. Es wird jedoch davon abgeraten, mit einer Mischung aus CPs und TLS Gateway-CP-Ports zu arbeiten. Aus diesem Grund ist diese Funktion standardmäßig deaktiviert und muss explizit aktiviert werden.

Wenn Sie ein TLS Gateway als CP-Port verwenden, müssen Sie die relevanten Parameter in der INI-Datei des TLS Gateway definieren. Sie können es auch in einem bestimmten Netzbereich verwenden.

Sie können Scripts verwenden, um TLS Gateway-Packs einfach zu erstellen, herunterzuladen und zu extrahieren sowie zu starten.

Schulung

Die Broadcom Software Academy bietet zahlreiche kostenlose Online-Schulungen. Falls noch nicht geschehen, registrieren Sie sich bei der Broadcom Software Academy, um von unserem Schulungsangebot zu profitieren.

Der folgende Kurs zu Automic Automation und TLS/SSL ist jetzt verfügbar:

  • Automic Automation TLS Gateway

Mehr Informationen:

Änderungen in der INI-Datei

Mit der TLS/SSL-Implementierung und der Einführung des neuen Java-Kommunikationsprozesses sowie der neuen TLS Gateway-Komponente und der Automic Automation Kubernetes Edition wurden die folgenden INI-Dateiänderungen implementiert:

AE INI-Datei

  • Der Abschnitt [PORTS] enthält jetzt den Parameter WS.PORT=, mit dem Sie die Ports für eingehende WebSocket-Verbindungen definieren können.

  • Im neuen Abschnitt [TLS] können Sie die relevanten Parameter für Schlüssel und Keystore definieren:

    • keystore=

    • keystorePassword=

    • keyPasssword=

    • keyAlias=

    Diese Parameter befanden sich vorher im Abschnitt [REST] der INI-Datei und wurden in den Abschnitt TLS verschoben.

  • Der neue Abschnitt [CONTAINER] ist nur in der Automic Automation Kubernetes Edition relevant und wird automatisch vom Install Operator festgelegt. Der Parameter readinessFile = gibt an, ob eine Bereitschaftsdatei geschrieben wird, wenn ein Prozess innerhalb eines Containers zur Ausführung bereit ist.

  • Der Parameter parallelDbConnections wurde aus dem Abschnitt [REST] in den Abschnitt [JDBC] der INI-Datei verschoben. Mit Hilfe dieses Parameters können Sie die maximale Anzahl paralleler Verbindungen zur Datenbank definieren, sodass Anfragen gleichzeitig verarbeitet werden können. Beachten Sie, dass diese Parameter pro Serverprozess festgelegt werden müssen.

  • Der Standardwert des Parameters docu= im Abschnitt [REST] wurde in 1 (aktiviert) geändert. Ab dieser Version ist also der Endpunkt für die Anforderung der AE REST API OpenAPI (Swagger)-Dokumentation standardmäßig aktiviert.

Weitere Informationen finden Sie unter Automation Engine INI-Datei.

INI-Dateien für TLS/SSL-Agenten

  • Da die TLS/SSL-Agenten eine Verbindung zum neuen JCP herstellen, wurde der Verbindungsparameter im Abschnitt [TCP/IP] der TLS/SSL-Agenten von cp= in connection= geändert.

  • Der Abschnitt [AUTHORIZATION] enthält jetzt die Parameter trustedCertFolder = und agentSecurityFolder =, mit denen Sie definieren können, wo der Agent Zertifikat- und sicherheitsbezogene Dateien speichern soll.

    Hinweis: Der UNIX-Agent enthält auch die Parameter SSLCertDir= und SSL CertFile=, die erforderlich sind, um den Speicherort von vertrauenswürdigen CA-Zertifikaten zu definieren.

  • Der neue Abschnitt [JCPLIST] ist ein selbstverwalteter Abschnitt, der alle TLS/SSL-fähigen Verbindungen anzeigt, die für den Agenten verfügbar sind.

Weitere Informationen finden Sie unter INI-Dateien von Agenten.

TLS Gateway INI-Datei

Das TLS Gateway ist ein Agentenobjekt und verfügt daher über eine eigene INI-Datei. Diese INI-Datei ist neu im System und ermöglicht es Ihnen, alle relevanten Parameter für das TLS Gateway zu definieren. Weitere Informationen finden Sie unter TLS Gateway.

DB-ServiceAgent

Der DB Service Agent verwendet seine eigene INI-Datei. Sie hat die gleiche Struktur wie die INI-Datei des SQL-Agenten, einschließlich der Konfiguration für TLS/SSL.

Der DB-Service-Agent verwendet seine eigene SQL-INI-Datei. Da Variablen-Objekte mit SQLI-Quelle direkt über die Automation Engine auf die AE-Datenbank zugreifen, benötigen sie keinen Agenten.

Mehr Informationen:

Proxy-Client-INI-Datei

Der Proxy verwendet jetzt TLS/SSL-Verbindungen, deshalb wurden in der INI-Datei des Proxy-Clients die folgenden Änderungen vorgenommen:

  • Der vollständige Abschnitt [SSL] einschließlich der Parameter keyStore und keyStorePwd wurde aus der INI-Datei entfernt.

    Sie können die Parameter trustedCertFolder=, agentSecurityFolder= und keyPassword= in der INI-Datei des Proxy-Clients verwenden, um auf die relevanten Zertifikate zu verweisen. Wenn der Parameter trustedCertFolder= nicht festgelegt ist, müssen die Zertifikate im Java-Trust Store installiert werden.

  • Im Abschnitt [GLOBAL] wurden die Parameter cpSelection und cpName entfernt.

  • Der Abschnitt [CP_LIST] wurde durch den Abschnitt [JCPLIST] ersetzt. Die JCP-Auswahl wird hier definiert.

Mehr Informationen:

Neue Serverrollen für den Java-Arbeitsprozess

Ab dieser Version können Sie Serverrollen für Java-Arbeitsprozesse (JWP) definieren und die Rollen so klassifizieren, dass sie bestimmte Queues oder Zuweisungen verarbeiten. Auf diese Weise kann die Last zwischen den JWPs verteilt werden.

Die folgenden JWP-Serverrollen sind verfügbar:

  • AUT für Authentifizierung

  • PER für periodische Aufgaben

  • UTL für Dienstprogramme

  • IDX zum Indizieren

    Die Lucene-Indizierung wird von JWP mit der Rolle IDX durchgeführt.

Sie können die Anzahl der Prozesse definieren, die Sie einer Rolle zuweisen möchten, und sie auf der neuen Seite JWP-Rollen im Abschnitt Automation Engine Management der Administration-Perspektive einordnen. Diese Seite ist nur auf Client 0 verfügbar.

In der Administration-Perspektive können Sie auch erkennen, ob für einen JWP auf der Seite Prozesse und Auslastung eine Rolle definiert ist. Sie werden in der Spalte Rolle durch Komma getrennt aufgelistet, wenn dem JWP mehr als eine Rolle zugewiesen ist.

Mehr Informationen:

Verfügbarkeitsprüfung für JCP und JWP

Um die Zuverlässigkeit und die Transparenz der Automation Engine zu steigern, prüft das System jetzt intern, ob die Mindestzahl von Java-basierten Prozessen (JCP, JWP, REST) verfügbar ist, die erforderlich sind, um sich beim System anzumelden oder Vorgänge in der AWI durchzuführen. Ist dies nicht der Fall, wird die Anmeldung abgelehnt und es wird eine Benachrichtigung angezeigt.

Wenn die Java-basierten Prozesse während der AWI-Operationen nicht verfügbar sind, erhält der Benutzer eine Benachrichtigung. Um sich abzumelden, halten Sie weitere Benutzeraktivitäten an und informieren Sie Ihren Administrator.

Benutzerkennwörter speichern

Die Benutzerkennwörter werden jetzt unter Verwendung des Argon2-Algorithmus als Hashes gespeichert.

Vorhandene Kennwörter werden automatisch migriert, aber die Kennwortgenerierung (Zähler für zuletzt verwendete Kennwörter) wird erneut initialisiert und beginnt mit 1.

Kennwörter, die vor der Migration verwendet wurden, werden beim Ändern des Kennworts nicht berücksichtigt und als neues Kennwort akzeptiert.

Verfügbarkeit des LDAP-Dienstes für die Anmeldung

In früheren Versionen wurde das letzte gültige LDAP-Kennwort in der AE-Datenbank gespeichert, um eine Anmeldung auch dann zu ermöglichen, wenn der Dienst gerade nicht verfügbar ist. Die gespeicherten Benutzerkennwörter wurden auch für die Synchronisierung verwendet, die im Benutzerobjekt verfügbar ist. Dieses Verhalten wird als Sicherheitsproblem gesehen und wird daher nicht mehr unterstützt.

Jetzt muss der LDAP-Dienst für die Anmeldung verfügbar sein. Um die Schaltfläche Synchronisieren im Benutzerobjekt für die manuelle Synchronisierung zu verwenden, muss ein Login-Objekt zugewiesen werden. Wenn der LDAP-Dienst nicht verfügbar ist, wird der Zugriff verweigert. Weitere Informationen finden Sie unter UC_LDAP_EXAMPLE - LDAP Verbindungsvariable.

Abtrennung der Berechtigungen für UNIX-Agenten

Die UNIX-Agenten verfügen nicht mehr über eine Trennung von Rechten. Nur ein Prozess ist für alle Agentenfunktionen verantwortlich.

Erweiterung des Automation Engine REST API

Die folgenden Verbesserungen wurden für die Automation Engine REST-API implementiert:

  • OpenAPI: Ab dieser Version ist die API-Referenz in OpenAPI (Swagger) geschrieben.

  • REST-API-Authentifizierung: Für eingehende REST API-Authentifizierungen wird die Passwortverschleierung mit UCYBCRYP.EXE unterstützt, siehe Passwörter verschleiern.

  • Endpunkterweiterung: Der AE REST API wurden mehrere Endpunkte hinzugefügt, die verschiedene Funktionen abdecken.

  • Objektausführung: Ab dieser Version können Sie die AE REST API verwenden, um Objekte zur Aktivierungszeit auszuführen.

Mehr Informationen:

z/OS Ereignis-Monitor

Der z/OS Ereignis-Monitor wurde verbessert und ermöglicht jetzt die Verwendung erweiterter Filterkriterien. Weitere Informationen finden Sie unter z/OS und automatische FILE-Ereignisse.

UC_VAULT_CYBERARK - Passworttresor-Konfiguration

Kennwörter werden gewöhnlich in der Datenbank gespeichert, aber sie können auch aus einem Passworttresor stammen. Mit diesem statischen Variablen (VARA)-Objekt können Sie Ihren Passworttresor konfigurieren. Dies wurde erweitert, sodass Sie nun aus drei Optionen auswählen können, um den Tresor abhängig davon zu konfigurieren, ob Ihr Benutzername in jedem Safe eindeutig ist oder nicht.

Wenn der Benutzername eindeutig ist, können Sie Ihren Tresor mit einem Safe konfigurieren. Die Variable UC_VAULT_CYBERARK muss den Schlüssel VLT_SAFE<nr> für jeden Safe enthalten, der im Anmeldeobjekt konfigurierbar sein soll. Wenn der Benutzername nicht eindeutig ist, können Sie jetzt den Tresor mit dem Objektnamen (und dem Safe) konfigurieren und den Objektnamen (Kontoname) als Kennung verwenden. Cyberark fordert, dass dieser Objektname innerhalb eines Safes eindeutig ist. Die dritte Option ist, Ihren Passworttresor mit der Adresse und dem Namen des Safes n zu konfigurieren. Sie können die Adresse als Teil der Cyberark-Abfrage verwenden. Der Benutzername ist immer Teil der Abfrage. Weitere Informationen finden Sie unter UC_VAULT_CYBERARK - Passworttresor-Konfiguration