Verbindungen zur AE sichern (TLS/SSL)

Die Kommunikation zwischen der Automation Engine und den verschiedenen Komponenten verwendet 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, wie beispielsweise Agenten.

Wichtig! Lesen Sie in Broadcom Software Academy nach. Es gibt einen Kurs zu diesem Thema. Weitere Informationen finden Sie im Abschnitt Schulung am Ende dieses Themas.

Diese Seite beinhaltet Folgendes:

Übersicht

Die JCP- und REST-Prozesse verwenden vertrauenswürdige Zertifikate, um ihre Identität gegenüber anderen Kommunikationspartnern nachzuweisen, wie z. B. AWI sowie Java-, Windows- und UNIX-Agenten.

Die TLS/SSL-Implementierung von Automic Automation verwendet Zertifikate mit öffentlichem Schlüssel im X.509-Format und TLS-Version 1.2 für die sicheren Verbindungen zwischen dem Server (Automation Engine) und den Mandanten (AWI, Agenten usw.).

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. Weitere Informationen finden Sie unter https://www.java.com/en/configure_crypto.html.

Sie sollten mit TLS/SSL und der Zertifikatimplementierung vertraut sein, bevor Sie die entsprechende Komponente installieren bzw. aktualisieren. Weitere Informationen finden Sie unter Hinweise zu TLS/SSL für Automic Automation.

Weitere Informationen über die verschiedenen Zertifikattypen und Beispiele, wie sie erstellt und verwendet werden können, finden Sie unter Welche Art von Zertifikaten sollte ich für Automic Automation v21 verwenden?

Wichtig! Beachten Sie, dass dies nur Beispiele sind, keine Anforderung für Automic Automation darstellen und nicht dafür gedacht sind, die Produktdokumentation zu ersetzen.

Parameter - Automation Engine

Definieren Sie für eine lokale Installation die unten aufgeführten Parameter im Abschnitt [TLS] der Konfigurationsdatei (UCSRV.INI) der Automation Engine. Weitere Informationen finden Sie unter Automation Engine INI-Datei.

  • keystore= Pfad und Datei, in der der Keystore für das TLS/SSL-Zertifikat gespeichert ist

    Standardwert: ./httpsKeyfile

    Dieser Parameter ist obligatorisch und muss auf das richtige Ziel zeigen; andernfalls wird der Prozess-Server beendet.

  • keystorePassword= Kennwort für die Keystore-Datei

    Standardwert: changeit

    Wenn der Wert nicht definiert ist oder leer bleibt, verwendet das System den Standardwert.

  • keyPassword=Kennwort für den Schlüssel

    Standardwert: changeit

    Wenn der Wert nicht definiert ist oder leer bleibt, verwendet das System den Standardwert.

  • keyAlias= Alias, der für den Schlüssel verwendet wird

    Standardwert: jetty

    Wenn der Wert nicht definiert ist oder leer bleibt, verwendet das System den Standardwert.

Das keystorePassword und das keyPassword können mit dem Dienstprogramm UCYBCRYP verschleiert werden. Weitere Informationen finden Sie unter Passwörter verschleiern.

In der Automic Automation Kubernetes Edition verwendet der JCP standardmäßig ein generiertes, selbstsigniertes Zertifikat im Kubernetes-Cluster. Aus diesem Grund müssen Sie diese Parameter für eine AAKE-Installation nicht definieren.

Wenn Sie Zertifikate über gegenseitiges TLS/SSL in einer lokalen Installation verwenden, z. B. zur Authentifizierung der Automation Engine beim CyberArk-Passworttresor (siehe Passworttresore), definieren Sie die folgenden Parameter im Abschnitt [TLS] der INI-Datei der AE:

  • mutualAuthenticationKeystore= Pfad und Datei, unter dem bzw. in der der Keystore für die gegenseitige TLS/SSL-Authentifizierung gespeichert ist

    Standardwert: ./mutualTlsKeystore.p12

    Wenn dieser Parameter nicht festgelegt ist, verwendet das System die Definition des Parameters keystore.

  • mutualAuthenticationKeystorePassword= Passwort für die Keystore-Datei

    Standardwert: changeit

    Wenn dieser Parameter nicht festgelegt ist, verwendet das System die Definition des Parameters keystorePassword.

  • mutualAuthenticationKeyPassword= Passwort für den Schlüssel

    Standardwert: changeit

    Wenn dieser Parameter nicht festgelegt ist, verwendet das System die Definition des Parameters keyPassword.

  • mutualAuthenticationKeyAlias= Alias, der für den Schlüssel für die gegenseitige Authentifizierung verwendet wird

    Wenn dieser Wert nicht definiert ist oder leer gelassen wird, versucht das System nicht, eine gegenseitige Authentifizierung durchzuführen.

In der Automic Automation Kubernetes Edition müssen Sie den geheimen Schlüssel mutual-tls-cert Kubernetes vor der Installation erstellen. Der geheime Schlüssel enthält das Paar aus privatem Schlüssel/Zertifikat, das die Automation Engine gegenüber CyberArk identifiziert. Weitere Informationen finden Sie unter Einrichten von CyberArk für Automic Automation Kubernetes Edition.

Parameter – Agenten, Java-Komponenten, Proxy und TLS Gateway

Alle Java-Komponenten sowie der Proxy, die Windows-, UNIX- und Java-Agenten und das TLS Gateway können verschiedene Parameter in ihrer entsprechenden INI-Datei verwenden, um zu definieren, wie mit den Zertifikaten umgegangen wird.

Wichtig! TLS/SSL-Agenten (in Containern und vor Ort) sowie das TLS Gateway, wenn sie für die Automic Automation Kubernetes Edition verwendet werden, stellen eine Verbindung zu einem Ingress-/HTTPS-Load-Balancer her, der zur Authentifizierung ein Zertifikat anfordert.

Stellen Sie sicher, dass die Adresse des Load Balancers auf beiden Seiten definiert ist: in der Automation Engine und auf dem Agenten/TLS Gateway, und dass Ihr HTTPS-Load-Balancer die erforderlichen Zertifikate zur Nutzung besitzt. Weitere Informationen finden Sie unter Eine Verbindung zum AWI, die JCP- und REST-Prozesse über einen Ingress herstellen.

Weitere Informationen finden Sie unter Eine Verbindung zum AWI, die JCP- und REST-Prozesse über einen Ingress herstellen.

Dies gilt für die folgenden Komponenten und Agenten:

Komponenten

Agenten

Hinweis: Die TLS/SSL-Implementierung gilt nicht für den HP-UX-Agenten, da er in dieser Version nicht mehr unterstützt wird.

Wenn Sie von einer Zertifizierungsstelle signierte Zertifikate verwendet haben, werden die Zertifikate standardmäßig im entsprechenden Java- oder Betriebssystemspeicher gespeichert: dem Java Trust Store für Java-Komponenten und Java-Agenten, dem Windows-Betriebssystemspeicher für Windows-Agenten und dem TLS/SSL-Speicher für UNIX-Agenten. In diesem Fall müssen Sie nur prüfen, ob die Root-Zertifikate bereits im jeweiligen Speicher sind.

Wenn Sie nicht den Standardspeicherort für die oben aufgeführten Komponenten und Agenten verwenden möchten, stellen Sie sicher, dass Sie die Parameter trustedCertFolder=, agentSecurityFolder= und keyPassword= (falls zutreffend) in der entsprechenden Konfigurationsdatei (INI) verwenden, um den Pfad zum Ordner zu definieren, in dem die vertrauenswürdigen Zertifikate gespeichert sind.

Darüber hinaus können die Agenten die folgenden Parameter im Abschnitt [AUTHORIZATION] der jeweiligen INI-Datei verwenden:

  • agentSecurityFolder= Pfad zum Ordner, in dem der Agent sicherheitsbezogene Dateien wie private Schlüssel, signierte Zertifikate, Stammzertifikate usw. speichert

  • keyPassword= Passwort für den Schlüssel

    Standardwert: changeit

    Wenn der Wert nicht definiert ist oder leer bleibt, verwendet das System den Standardwert.

    Hinweis: Das keyPassword kann mit dem Dienstprogramm UCYBCRYP verschleiert werden. Weitere Informationen finden Sie unter Passwörter verschleiern.

Der Agent sucht in den gängigsten TLS/SSL-Speichern nach Zertifikaten. Wenn Sie keinen Standardspeicherort verwenden, ist es bei UNIX-Agenten außerdem erforderlich, dass Sie die Parameter SSLCertDir= und SSLCertFile= definieren, um die Zertifikate aus dem TLS/SSL-Speicher zu laden.

Standard: SSLCertDir

  • /etc/ssl/certs

    Plattformen: Debian/Ubuntu

  • /etc/pki/tls/certs

    Plattformen: Fedora/RHEL/CentOS

  • /usr/local/share/certs

    Plattformen: FreeBSD

  • /etc/openssl/certs

    Platfformen: NetBSD

  • /var/ssl/certs

    Plattformen: AIX

Standard: SSLCertFile

  • /etc/ssl/certs/ca-certificates.crt

    Plattformen: Debian/Ubuntu

  • /etc/pki/tls/certs/ca-bundle.crt

    Plattformen: Fedora/RHEL 6/CentOS

  • /etc/ssl/ca-bundle.pem

    Plattformen: OpenSUSE

  • /etc/pki/tls/cacert.pem

    Plattformen: OpenELEC

  • /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

    Plattformen: CentOS/RHEL 7

  • /etc/ssl/cert.pem

    Plattformen: Alpine Linux

Wenn der Agent keine Zertifikate findet oder die Pfade nicht in Ihrem System existieren, dann kann der Agent keine Verbindung zur Automation Engineherstellen.

Sie können verschiedene Befehle verwenden, um nach den Zertifikaten in Ihrem System zu suchen. Nur ein privilegierter Benutzer, wie beispielsweise Root, kann diese Ordner durchsuchen.

Beispiele – SSL_CERT_DIR

sudo find /etc/ssl/ -name '*DigiCert*'

sudo find /etc/ -name 'DigiCert_Global_Root_CA.pem'

Beispiele – SSL_CERT_FILE

sudo grep -R "DigiCert" /etc/ssl/

sudo grep -R "DigiCert Global Root CA" /etc/

Mehr Informationen:

Ablaufdatum des Zertifikats

Sie müssen sicherstellen, dass die verwendeten Zertifikate nicht nur die jeweiligen Sicherheitsanforderungen erfüllen, sondern auch nicht abgelaufen sind. Andernfalls können die Komponenten keine Verbindung zur Automation Engine herstellen.

Das System prüft das Zertifikatablaufdatum alle 24 Stunden (um Mitternacht UTC). Wenn das Ablaufdatum eines oder mehrerer Zertifikate innerhalb von 30 Tagen liegt, zeigt AWI die folgende Benachrichtigung an: "Die folgenden JCP-Zertifikate laufen innerhalb der nächsten 30 Tage ab: <Zertifikatname (Ablaufdatum)>". Das Ablaufdatum des Zertifikats wird auch beim Start sowie um Mitternacht (UTC) in die JCP-Logdatei geschrieben.

Die Benachrichtigung wird in allen Mandanten aber nur für Benutzer mit dem Recht Zugriff auf Administration angezeigt. Weitere Informationen finden Sie unter Berechtigungen Automation Enginegewähren. Die Benachrichtigung bleibt sichtbar, bis das Zertifikat verlängert wird.

Hinweise:

  • AWI zeigt nur eine Benachrichtigung an, selbst wenn mehr als ein Zertifikat abläuft. Alle relevanten Zertifikate werden nacheinander durch ein Komma getrennt nach Ablaufdatum aufgelistet; das Zertifikat, das dem Ablaufdatum am nächsten ist, wird zuerst aufgelistet.

  • Nach der Erneuerung des Zertifikats muss der JCP nicht neu gestartet werden.

  • Stellen Sie sicher, dass das neue Zertifikat richtig eingestellt ist und dieselbe Definition wie der TLS-Abschnitt der INI-Datei der Automation Engineverwendet, siehe Automation Engine. Andernfalls wird die alte KeyStore-Definition verwendet und der JCP wird nicht gestartet.

Optional können Sie auch die Variable UC_SERVER_TLS_SETTINGS verwenden, um eine benutzerdefinierte Aktion auszulösen, wenn eines dieser Zertifikate kurz vor dem Ablauf steht. Weitere Informationen finden Sie unter UC_SERVER_TLS_SETTINGS – Serverzertifikatsverwaltung.

Schulung

Die Broadcom Software Academy bietet zahlreiche kostenlose Online-Schulungen. Informationen dazu, wie Sie innerhalb der Academy navigieren und sich für Kurse anmelden, finden Sie unter Kostenlose Online-Kurse.

Diesem Thema sind die folgenden Kurse zugeordnet:

Siehe auch: