アーキテクチャとセキュリティ

Test Cloud の Relay のアーキテクチャ。クライアントが送信専用の TLS トンネルを確立する方法と、クラウド サービスとオンプレミスのエンドポイント間でのトラフィックの流れ方が含まれます。

動作のしくみ

Relay クライアントは、ネットワーク内のマシンにインストールされる軽量のバイナリで、ポート 443 で UiPath Relay インフラストラクチャへの永続的な送信専用接続を確立します。Relay クライアント 26.4.2 以降では、新しい構成は WSS (WebSocket over TLS) を使用して cloud.uipath.com を介して接続します。

26.4.2 より前のバージョンの Relay クライアントは、リージョンの Relay ホスト名を介して TLS 上で接続します。

UiPath クラウド サービスがオンプレミスのエンドポイントの 1 つに接続する必要がある場合、要求はクラウド サービスから UiPath の Relay インフラストラクチャを経由した後、送信接続を通じて Relay クライアントまで移動し、そこからローカル ネットワーク上で対象のサービスに到達します。

Relay クライアントはアウトバウンドのすべてのトンネル接続を開始するため、ネットワークはインターネットからのインバウンド接続を受け入れません。

接続フロー

1. オンプレミスのエンドポイントは、UiPath Administration の Relay グループに登録します。エンドポイントリストは Relay サービスに保存されます。
2. Relay クライアントは、Test Cloud に対して認証された検出呼び出しを実行し、公開するエンドポイントのリストを取得します。
3. Relay クライアントは、永続的なアウトバウンド制御接続を確立します。Relay クライアント 26.4.2 以降は、WSS (WebSocket over TLS) を使用して cloud.uipath.com:443 経由で接続します。26.4.2 より前のバージョンの Relay クライアントは、ポート 443 で TLS 経由でリージョン固有の Relay ホスト名 (eu-relay.uipath.comなど) に接続します。
4. UiPath のリレー インフラストラクチャは、OIDC 経由で接続を検証し、登録済みのリレー グループに対してクライアントの構成を検証します。これにより、クライアントが所有していないエンドポイントを要求するのを防ぎます。
5. UiPath サービスは、オンプレミスのエンドポイントを呼び出す必要がある場合に、リレー API からリレー URL を取得し、UiPath Identity からリレー範囲のトークンを取得します。
6. サービスはリレー URL を呼び出します。リレー インフラストラクチャは、トンネル経由で要求を転送する前に、トークンと消費するテナントの認可を検証します。
7. リレー クライアントは、転送された要求をアウトバウンド接続経由で受信し、ローカル ネットワーク経由でオンプレミス エンドポイントへの HTTP または HTTPS 接続を開きます。
8. サポートされている TCP ベースのエンドポイントの場合、Relay クライアントは代わりに、ループバック インターフェイスを介してオンプレミスの Executor に要求を引き渡します。Executor は要求をコネクタのプロトコル (SAP BAPI、SAP RFC over TCP の場合) に変換し、オンプレミスのエンドポイントへの接続を開きます。

注:

最適なスループットを得るには、Relay クライアントをクラウド テナントと同じ地理的リージョンにデプロイします。トラフィックは UiPath Cloud からリレー インフラストラクチャとリレー ノードを経由してオンプレミスのサービスに送信されるため、リージョンをまたぐトンネルを使用すると、リージョン間の往復時間に比例した遅延が加わります。ペイロードが大きいシナリオでは、この違いは大きくなります。

高可用性

運用環境の場合は、同じRelayグループ内に少なくとも2つのRelayクライアントを、同一のネットワークアクセスとトラストストア構成で展開します。グループ内のクライアントは、ラウンドロビン分散を介してロードし、1 つのクライアントが使用できなくなった場合は自動的にフェールオーバーします。

複数のクライアントがプロアクティブ再接続を使用する場合、一度に 1 つのクライアントのみがドレインするように調整し、各再接続サイクルを通じてグループを継続的に使用できるようにします。

セキュリティ モデル

• 認証。Relay クライアントは、OAuth 2.0 クライアント資格情報を使用してクラウド プラットフォームに対して認証を行います。UiPath のリレー インフラストラクチャは、OIDC を介した各制御接続を検証し、クライアントが登録済みのリレー グループと一致することを検証します。
• 保存時の暗号化。リレークライアントマシンに保存される資格情報は暗号化されます(LinuxではAES-256-GCM、WindowsではDPAPI)。
• 転送中の暗号化。リレー クライアントと UiPath のリレー インフラストラクチャ間のすべてのトラフィックは、ポート 443 で転送中に暗号化されます。リレー接続では、TLS 1.2 または TLS 1.3 を使用します。暗号スイートは、安全なデフォルトを使用してGo TLSスタックによって選択されます。リレークライアントは、カスタム暗号スイート構成を公開しません。
• トークンのスコープ。UiPath サービスは、リレー URL を呼び出す前に、リレー スコープのトークンを取得します。リレー インフラストラクチャは、要求を転送する前に、このトークンと使用するテナントの認可を検証します。
• オンプレミスの Executor の分離。サポートされる TCP ベースの接続の場合、Relay クライアントは、デフォルトでポート 18080 のループバック インターフェイスを介してオンプレミスの Executor と通信します。Executor は、ホストの外部からの接続を一切受け入れません。Linux および Windows サービスのデプロイでは、Relay クライアントは Executor をローカルの Java プロセスとして起動し、そのライフサイクルを監視します。コンテナーデプロイでは、Executor は同じネットワーク名前空間内の別のコンテナーとして実行されるため、ループバックは引き続き Executor を制限し、コンテナーランタイムまたは Kubernetes がそれを監視します。

TLS と証明書の信頼性

Relay クライアントは、オンプレミス ターゲットへの HTTP または HTTPS 接続を終了して再開します。サポートされる TCP ベースの接続の場合、オンプレミスの Executor は代わりにターゲットへの接続を確立します。オンプレミスのエンドポイントで HTTPS を使用する場合、Relay クライアント マシン上の OS 信頼ストアは、オンプレミス エンドポイントの証明書に署名した証明機関 (CA) を信頼する必要があります。

エンドポイントで自己署名証明書またはプライベート企業 CA を使用している場合は、リレーを開始する前に、発行元 CA をリレークライアントマシンの信頼ストアに追加します。そうしないと、リレークライアントは内部ターゲットへの接続を拒否します。