- Erste Schritte
- Datensicherheit und Compliance
- Organisationen
- Authentifizierung und Sicherheit
- Lizenzierung
- Über die Lizenzierung
- Einheitliche Preise: Lizenzierungsplan-Framework
- Aktivieren Ihrer Enterprise-Lizenz
- Migrieren von Test Suite zu Test Cloud
- Lizenzmigration
- Zuweisen von Lizenzen zu Mandanten
- Zuweisen von Benutzerlizenzen
- Freigegeben von Benutzerlizenzen
- Überwachung der Lizenzzuweisung
- Lizenzüberzuweisung
- Lizenzierungsbenachrichtigungen
- Benutzerlizenzverwaltung
- Mandanten und Dienste
- Konten und Rollen
- AI Trust Layer
- Über AI Trust Layer
- Überprüfung der Nutzungszusammenfassung
- Anzeigen von Überwachungsprotokollen
- Verwalten von AI Trust Layer-Richtlinien
- PII-Maskierung
- Verwalten von Autopilot for Everyone
- Konfigurieren von LLMs
- Einschränken von LLM-Aufrufen auf Ihre eigenen Modelle
- Konfigurieren von OpenTelemetry
- Steuern von kontextbezogenen Daten für GenAI-Funktionen
- Externe Anwendungen
- Benachrichtigungen
- Protokollierung
- Datenexport
- Tests in Ihrer Organisation
- Fehlersuche und ‑behebung
- Migration zur Test Cloud
Relay-Architektur in Test Cloud, einschließlich der Art und Weise, wie der Client einen rein ausgehenden TLS-Tunnel errichtet und wie der Datenverkehr zwischen Cloud-Diensten und lokalen Endpunkten fließt.
Wie es funktioniert
Der Relay-Client, eine einfache Binärdatei, die auf einer Maschine in Ihrem Netzwerk installiert wird, stellt eine dauerhafte, nur ausgehende Verbindung auf Port 443 mit der UiPath Relay-Infrastruktur her. Für den Relay-Client 26.4.2 oder höher stellen neue Konfigurationen eine Verbindung über cloud.uipath.com mit WSS (WebSocket über TLS) her.
Relay-Client-Versionen vor 26.4.2 verbinden sich über einen regionalen Relay-Hostnamen über TLS.
Wenn ein UiPath-Cloud-Dienst einen Ihrer lokalen Endpunkte erreichen muss, gelangt die Anforderung vom Cloud-Dienst durch die UiPath-Relay-Infrastruktur über die ausgehende Verbindung zum Relay-Client und von dort durch Ihr lokales Netzwerk zum Zieldienst.
Da der Relay-Client alle Tunnelverbindungen ausgehend initiiert, akzeptiert Ihr Netzwerk nie eine eingehende Verbindung aus dem Internet.
Konnektivitätsflow
- Sie registrieren lokale Endpunkte unter einer Relay-Gruppe in der UiPath-Verwaltung. Die Endpunktliste wird im Relay-Dienst gespeichert.
- Der Relay-Client führt einen authentifizierten Erkennungsaufruf bei der Test Cloud durch, um die Liste der zu veröffentlichenden Endpunkte abzurufen.
- Der Relay-Client stellt eine persistente ausgehende Steuerelementverbindung her. Der Relay-Client
26.4.2oder höher verbindet sich übercloud.uipath.com:443mit WSS (WebSocket über TLS). Relay-Client-Versionen vor26.4.2stellen über TLS auf Port 443 eine Verbindung mit dem regionsspezifischen Relay-Hostnamen her, z. B.eu-relay.uipath.com. - Die UiPath Relay-Infrastruktur validiert die Verbindung über OIDC und überprüft die Client-Konfiguration anhand der registrierten Relay-Gruppe, sodass ein Client Endpunkte beanspruchen kann, die er nicht besitzt.
- Wenn ein UiPath-Dienst einen lokalen Endpunkt aufrufen muss, ruft er die Relay-URL von der Relay-API ab und erhält ein Relay-Scope-Token von UiPath Identity.
- Der Dienst ruft die Relay-URL auf. Die Relay-Infrastruktur validiert das Token und die Autorisierung des verbrauchenden Mandanten, bevor die Anforderung durch den Tunnel weitergeleitet wird.
- Der Relay-Client erhält die weitergeleitete Anforderung über seine ausgehende Verbindung und öffnet eine HTTP- oder HTTPS-Verbindung zum lokalen Endpunkt über das lokale Netzwerk.
- Für einen unterstützten TCP-basierten Endpunkt übergibt der Relay-Client stattdessen die Anforderung über die Loopback-Schnittstelle an den lokalen Executor. Der Executor übersetzt die Anforderung in das Protokoll des Connectors (für SAP BAPI, SAP RFC über TCP) und öffnet die Verbindung zum lokalen Endpunkt.
Für besten Durchsatz stellen Sie den Relay-Client in der gleichen geografischen Region wie Ihr Cloud-Mandant bereit. Der Datenverkehr bewegt sich von UiPath Cloud über die Relay-Infrastruktur und den Relay-Knoten zum lokalen Dienst, sodass regionsübergreifende Tunnel die Latenz hinzufügen, die korrekt zur Round Trip Time zwischen den Regionen verfügbar ist. Bei großen Nutzlastszenarien ist dieser Unterschied signifikant.
Hohe Verfügbarkeit (High Availability)
Stellen Sie für Produktionsumgebungen mindestens zwei Relay-Clients innerhalb derselben Relay-Gruppe mit identischem Netzwerkzugriff und Vertrauensspeicherkonfiguration bereit. Clients in einer Gruppe teilen sich die Last über eine Round-Robin-Verteilung und ein automatisches Failover erfolgt, wenn ein Client nicht verfügbar ist.
Wenn mehrere Clients eine proaktive Wiederverbindung verwenden, koordinieren sie sich so, dass nur ein Client gleichzeitig entleert wird und die Gruppe während jedes Wiederverbindungszyklus kontinuierlich verfügbar bleibt.
Sicherheitsmodell
- Authentifizierung. Der Relay-Client authentifiziert sich mit OAuth 2.0 Client-Anmeldeinformationen bei der Cloud-Plattform. Die UiPath Relay-Infrastruktur validiert jede Steuerelementverbindung über OIDC und überprüft, ob der Client mit der registrierten Relay-Gruppe übereinstimmt.
- Verschlüsselung im Ruhezustand. Anmeldeinformationen, die auf der Relay-Clientmaschine gespeichert sind, sind verschlüsselt: AES-256-GCM unter Linux, DMAPI unter Windows.
- Verschlüsselung bei der Übertragung. Der gesamte Datenverkehr zwischen dem Relay-Client und der UiPath Relay-Infrastruktur wird bei der Übertragung auf Port 443 verschlüsselt. Relay-Verbindungen verwenden TLS 1.2 oder TLS 1.3. Verschlüsselungssammlungen werden vom Go TLS-Stapel mithilfe sicherer Standardeinstellungen ausgewählt; Der Relay-Client macht keine benutzerdefinierte Cipher-Suite-Konfiguration verfügbar.
- Token-Scoping. UiPath-Dienste erhalten ein Relay-Scope-Token, bevor sie eine Relay-URL aufrufen. Die Relay-Infrastruktur validiert dieses Token und die Autorisierung des verbrauchenden Mandanten, bevor die Anforderung weitergeleitet wird.
- Isolierung des lokalen Executors. Für unterstützte TCP-basierte Verbindungen kommuniziert der Relay-Client mit dem lokalen Executor über die Loopback-Schnittstelle standardmäßig auf Port
18080. Der Executor akzeptiert keine Verbindungen von außerhalb des Hosts. Bei Linux- und Windows-Dienstbereitstellungen startet der Relay-Client den Executor als lokaler Java-Prozess und überwacht dessen Lebenszyklus. In Containerbereitstellungen wird der Executor als separater Container im selben Netzwerk-Namespace ausgeführt, sodass Loopback ihn immer noch begrenzt und Ihre Container-Laufzeit oder Kubernetes ihn überwacht.
TLS und Zertifikatsvertrauenswürdig
Der Relay-Client beendet und initiiert HTTP- oder HTTPS-Verbindungen mit lokalen Zielen erneut. Bei unterstützten TCP-basierten Verbindungen stellt stattdessen der lokale Executor die Verbindung zum Ziel her. Wenn der lokale Endpunkt HTTPS verwendet, muss der Vertrauensspeicher des Betriebssystems auf der Relay-Clientmaschine der Zertifizierungsstelle vertrauen, die das Zertifikat des lokalen Endpunkts signiert hat.
Wenn Ihr Endpunkt ein selbstsigniertes Zertifikat oder eine private Unternehmens-ZS verwenden, fügen Sie die ausstellende Zertifizierungsstelle zum Vertrauensspeicher der Relay-Clientmaschine hinzu, bevor Sie den Relay-Dienst starten. Andernfalls weist der Relay-Client die Verbindung zum internen Ziel zurück.