Arquitetura e segurança

Arquitetura de relay no Test Cloud, incluindo como o cliente estabelece um túnel TLS apenas de saída e como o tráfego flui entre os serviços de cloud e os pontos de extremidade locais.

Como funciona

O cliente de Relay, um binário leve instalado em uma máquina dentro de sua rede, estabelece uma conexão persistente e somente de saída na porta 443 com a infraestrutura de relay da UiPath. Para o cliente de Relay 26.4.2 ou posterior, novas configurações conectam-se por meio de cloud.uipath.com usando WSS (WebSocket sobre TLS).

Versões do cliente relay anteriores a 26.4.2 conectam-se por meio de um Nome do host do relay regional sobre o TLS.

Quando um serviço de cloud da UiPath precisa acessar um de seus pontos de extremidade locais, a solicitação viaja do serviço de cloud por meio da infraestrutura de relay da UiPath, de lá, por sua conexão de saída até o cliente de relay e, de lá, por sua rede local, até o serviço de destino.

Como o cliente de Relay inicia todas as conexões de túnel de saída, sua rede nunca aceita uma conexão de entrada da internet.

Fluxo de conectividade

1. Você registra pontos de extremidade locais em um Grupo de Relay na UiPath Administration. A lista de pontos de extremidade é armazenada no serviço de Relay.
2. O cliente de Relay executa uma chamada de descoberta autenticada para o Test Cloud para recuperar a lista de pontos de extremidade a expor.
3. O cliente de Relay estabelece uma conexão de controle de saída persistente. O cliente de Relay 26.4.2 ou posterior conecta-se por meio de cloud.uipath.com:443 usando WSS (WebSocket sobre TLS). Versões do cliente de Relay anteriores à 26.4.2 conectam-se ao Nome do Host de Relay específico da região, por exemplo, eu-relay.uipath.com, sobre TLS na porta 443.
4. A infraestrutura de relay da UiPath valida a conexão por meio de OIDC e verifica a configuração do cliente contra o Grupo de Relay registrado, impedindo que um cliente reivindicar pontos de extremidade que não possui.
5. Quando um serviço da UiPath precisa chamar um endpoint local, ele recupera o URL do relay da API do relay e obtém um token com escopo de relay do UiPath Identity.
6. O serviço chama a URL do relay. A infraestrutura de relay valida o token e a autorização do tenant de consumo antes de encaminhar a solicitação por meio do túnel.
7. O cliente de Relay recebe a solicitação encaminhada por meio de sua conexão de saída e abre uma conexão HTTP ou HTTPS para o endpoint local pela rede local.
8. Para um ponto de extremidade baseado em TCP compatível, o cliente de Relay entrega a solicitação ao executor local por meio da interface de loopback. O executor traduz a solicitação para o protocolo do conector (para SAP BAPI, SAP RFC sobre TCP) e abre a conexão para o endpoint local.

Observação:

Para obter a melhor taxa de transferência, implante o cliente de Relay na mesma região geográfica que seu tenant de nuvem. O tráfego flua do UiPath Cloud por meio da infraestrutura de relay e do nó de relay para o serviço no local, então os túnel entre regiões adicionam latência proporcional ao tempo de ida e volta entre as regiões. Para cenários de cargas grandes, essa diferença é significativa.

Alta disponibilidade

Para ambientes de produção, implante pelo menos dois clientes de Relay dentro do mesmo Grupo de Relay com acesso de rede idêntico e configuração de armazenamento de confiança. Os clientes em um grupo compartilham a carga por meio da distribuição Round Robin e falham automaticamente se um cliente ficar indisponível.

Quando vários clientes usam a reconexão proativa, eles se coordenam para que apenas um cliente seja drenado de cada vez, mantendo o grupo continuamente disponível em todo o ciclo de reconexão.

Modelo de segurança

• Autenticação. O cliente de Relay autentica-se na plataforma de nuvem usando as Credenciais do Cliente do OAuth 2.0. A infraestrutura de relay da UiPath valida cada conexão de controle por meio de OIDC e verifica a correspondência do cliente com o Grupo de Relay registrado.
• Criptografia em repouso. As credenciais armazenadas na máquina cliente de Relay são criptografadas: AES-256-GCM no Linux, DPAPI no Windows.
• Criptografia em trânsito. Todo o tráfego entre o cliente de Relay e a infraestrutura de relay da UiPath é criptografado em trânsito na porta 443. As conexões de relay usam TLS 1.2 ou TLS 1.3. Os conjuntos de cifras são selecionados pela pilha Go TLS usando padrões seguros; o cliente de Relay não expõe a configuração personalizada do pacote de cifras.
• Escopo de tokens. Os serviços da UiPath obtém um token com escopo de relay antes de chamar um URL de relay. A infraestrutura de relay valida esse token e a autorização do tenant de consumo antes de encaminhar a solicitação.
• Isolamento de executor no local. Para conexões baseadas em TCP compatíveis, o cliente de Relay se comunica com o executor no local por meio da interface de loopback, na porta 18080 por padrão. O executor não aceita conexões de fora do host. Em implantações de serviço no Linux e no Windows, o cliente de Relay inicia o executor como um processo Java local e supervisiona seu ciclo de vida. Em implantações de contêiner, o executor é executado como um contêiner separado no mesmo namespace da rede, então o loopback ainda o confina e seu runtime de contêiner ou o Kubernetes o supervisiona.

TLS e confiança do certificado

O cliente de Relay encerra e reinicia conexões HTTP ou HTTPS com destinos locais. Para conexões baseadas em TCP compatíveis, o executor local estabelece a conexão com o destino. Quando o ponto de extremidade local usa HTTPS, o armazenamento de confiança do SO na máquina cliente de Relay deve confiar na autoridade de certificação (CA) que assinou o certificado do ponto de extremidade local.

Se seu ponto de extremidade usar um certificado autoassinado ou uma CA corporativa privada, adicione a CA emissora ao armazenamento de confiança da máquina cliente do Relay antes de iniciar o relay. Não fazer isso faz com que o cliente de Relay rejeite a conexão com o destino interno.