Acesso RDP e SSH sem agente com Sophos Protected Browser

O Sophos Protected Browser permite aceder a hosts RDP e SSH internos sem um agente ZTNA no dispositivo do utilizador. A Sophos apresenta estes dois casos de utilização em Access RDP agentlessly via Protected Browser e Access SSH agentlessly via Protected Browser. O acesso permanece limitado ao Protected Browser: uma ligação criada como recurso RDP ou SSH sem agente não pode ser aberta com um cliente RDP ou SSH convencional.

O processo seguro é o mesmo para ambos os protocolos: primeiro, prepare a identidade, o gateway e a conectividade; depois, crie uma política ZTNA sem agente e um recurso por host. No Protected Browser, adicione o recurso a um grupo de aplicações e autorize-o através de uma política de Internet. Só então efetue os testes com um pequeno grupo de utilizadores.

Requisitos, licença e funções

Antes da configuração, devem estar reunidas as seguintes condições:

O Protected Browser está instalado num dispositivo Windows ou macOS compatível. O exemplo abaixo utiliza um dispositivo Windows com estado de integridade verde.
Os utilizadores e grupos estão sincronizados, existe um fornecedor de identidade configurado e o gateway ZTNA está operacional.
O gateway consegue alcançar o host RDP ou SSH interno. Esta ligação é verificada antes da criação do recurso.
Existe o grupo de utilizadores mais restrito possível para o recurso. Um objeto partilhado por todos os colaboradores não é adequado para acesso administrativo.
A pessoa que executa o procedimento pode gerir políticas e recursos em My Products > ZTNA, bem como objetos de política e políticas de Internet em My Products > Protected Browser.

As informações do produto aprovadas para este processo não especificam um nome de função nem um SKU de licença separado. Não presuma que um menu visível comprova a autorização e não conceda direitos gerais de superadministrador. Antes da alteração, verifique no seu tenant se ZTNA e Protected Browser estão disponíveis e se a conta de administrador pode criar os objetos indicados. Se faltar uma página ou um botão, peça ao responsável pelo licenciamento ou pelas funções do tenant que investigue antes de continuar.

O gateway local e o Sophos Cloud Gateway são modos possíveis de implementação do ZTNA. A sua implementação, a sincronização de utilizadores e identidades, os domínios, os certificados e o DNS fazem parte da base comum do ZTNA. A ordem correta é explicada em Configurar o Sophos ZTNA. Este guia não repete deliberadamente esses procedimentos comuns.

Verificar previamente o DNS e os certificados

O domínio do gateway, o certificado e a resolução DNS pública e interna necessária já devem estar operacionais. O responsável pelo ZTNA configura esta base comum de acordo com o guia ZTNA indicado; esta não é repetida nem alterada aqui.

Os recursos RDP e SSH aqui descritos utilizam um formulário específico: introduza o endereço em Internal FQDN/IP address of the resource; não é possível adicionar External FQDN. Portanto, exemplos gerais de DNS para aplicações web ZTNA não devem ser copiados para este campo. Domínios e certificados são preparados pelo proprietário do ZTNA antes da criação do recurso RDP ou SSH.

Preparar valores de exemplo

Os nomes seguintes permitem identificar os objetos relacionados. Não constituem uma especificação do produto e devem ser adaptados à convenção de nomenclatura da organização:

Política ZTNA: Agentenloser Zugriff
Recurso RDP: Agentenloses RDP
Recurso SSH: Agentenloses SSH
Estado do dispositivo: Grünes Windows
Grupo de aplicações: Agentenlose RDP-Gruppe ou Agentenlose SSH-Gruppe
Política de Internet: Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität ou a variante SSH
Host interno: por exemplo rdp01.intern.example ou ssh01.intern.example

Um FQDN é mais fácil de controlar do que um endereço IP variável, mas deve ser resolvido corretamente na perspetiva do gateway. Se testar ambos os protocolos, crie recursos e grupos de aplicações separados. Deste modo, as atribuições, a validação e a posterior desativação permanecem rastreáveis.

Adicionar política ZTNA sem agente

Pode reutilizar uma política sem agente existente, desde que o respetivo âmbito seja adequado. No entanto, uma política piloto dedicada reduz o risco de afetar inadvertidamente recursos de produção.

Abra My Products > ZTNA > Policies.
Clique em Add policy.
Em Add policy, selecione o tipo Agentless. Noutras vistas do ZTNA, este tipo também é identificado como acesso sem agente. Um aviso que solicita um agente refere-se ao caminho baseado no agente; esta política não requer um agente.
Em New policy, introduza um nome, por exemplo Agentenloser Zugriff.
Abra Policy enforced e ative Policy is enforced.
Clique em Save.

O tipo de política ZTNA Agent e os respetivos túneis não fazem parte deste procedimento. A definição global Agent tunnel inactivity timeout aplica-se ao túnel do agente; não é um temporizador de sessão RDP ou SSH do Protected Browser. Ainda assim, o responsável pelo ZTNA deve conhecer a definição global Minimum time before device health triggers a rule se o ambiente utilizar a integridade do dispositivo.

Adicionar recurso RDP ou SSH

Abra My Products > ZTNA > Resources & Access e clique em Add Resource. Preencha o formulário com os valores do protocolo pretendido.

Recurso RDP

Por exemplo, insira Agentenloses RDP como Resource name. Uma descrição é opcional.
Escolha o gateway que consegue alcançar rdp01.intern.example.
Em Access method, selecione Agentless.
Escolha a política Agentenloser Zugriff.
Em Resource type, selecione RDP. A porta 3389 e o tipo de porta de acesso TCP são definidos automaticamente e não podem ser alterados neste formulário.
Em Internal FQDN/IP address of the resource, introduza o host interno. Um FQDN externo não pode ser incluído para este tipo de recurso.
Em Assign User Groups, mova apenas o grupo piloto necessário de Available para Assigned User Groups.
Clique em Save.

Recurso SSH

Para SSH use o mesmo fluxo com estes valores específicos do protocolo:

Resource name: por exemplo Agentenloses SSH.
Access method: Agentless.
Policy: Agentenloser Zugriff.
Resource type: SSH. A porta 22 e o tipo de porta de acesso TCP são definidos automaticamente e não podem ser alterados.
Internal FQDN/IP address of the resource: por exemplo ssh01.intern.example; um FQDN externo não está disponível.
Assign User Groups: mova apenas o grupo piloto pretendido para Assigned User Groups e, em seguida, selecione Save.

Os recursos baseados em agente e as aplicações Web oferecem outras funcionalidades. Por exemplo, o agente pode considerar a integridade do dispositivo na política de acesso ZTNA e controlar aplicações locais. Neste procedimento, o recurso permanece Agentless. Se for necessária uma verificação adicional do dispositivo, configure-a na política de Internet do Protected Browser.

Limitar o acesso ao Protected Browser

Criar um estado de dispositivo opcional

Adicionar um estado de dispositivo é opcional. Sem este objeto, o grupo piloto deve ser particularmente restrito. Para o exemplo documentado com dispositivos Windows geridos:

Abra My Products > Protected Browser > Policy objects.
Clique em Add object > Device posture.
Insira Grünes Windows como o nome.
Em OS platform, selecione Windows.
Em Endpoint Protection, selecione Check if device is protected by Sophos Endpoint e depois o estado de integridade Green.
Clique em Save.

Verificações adicionais aumentam a segurança, mas também podem excluir mais dispositivos. Cada condição adicional é, portanto, testada primeiro com o grupo piloto.

Criar grupo de aplicações

Permaneça em My Products > Protected Browser > Policy objects.
Clique em Add object > Application group.
Insira um nome exclusivo, por exemplo Agentenlose RDP-Gruppe.
Expanda ZTNA resources.
Em Available, selecione o recurso criado anteriormente e mova-o para Assigned.
Clique em Save.

Para SSH, crie Agentenlose SSH-Gruppe e atribua Agentenloses SSH. Os grupos separados evitam que uma alteração posterior ao acesso SSH modifique inadvertidamente o acesso RDP.

Adicionar política de internet

Abra My Products > Protected Browser > Web policy e selecione a guia Policies.
Clique em Add policy.
Insira um nome exclusivo, por exemplo Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität.
Certifique-se de que Allow esteja selecionado.
Se for utilizado, selecione o estado do dispositivo Grünes Windows.
Selecione o grupo de aplicações Agentenlose RDP-Gruppe.
Clique em Save.

Para SSH, crie a política correspondente com o grupo de aplicações SSH. Desta forma, fica claro qual o protocolo e a condição do dispositivo abrangidos por cada autorização.

Verificar a ligação e o resultado esperado

Comece por testar com exatamente um utilizador autorizado e um dispositivo que cumpra a condição selecionada.

Teste RDP

Inicie o Sophos Protected Browser e autentique-se.
Na parte superior da barra de ferramentas, clique no ícone de Ligação ao Ambiente de Trabalho Remoto e, em seguida, clique em + New Host.
Atribua um nome de apresentação e introduza em Host o mesmo FQDN interno ou endereço IP do recurso ZTNA. A porta 3389 é definida automaticamente.
Introduza o nome de utilizador e a palavra-passe do sistema de destino e clique em Connect.

O teste será bem-sucedido se a sessão de área de trabalho remota for aberta no Protected Browser. Um cliente RDP normal não é uma verificação cruzada válida porque os recursos RDP sem agente só são acessíveis por meio do Protected Browser.

Teste SSH

Inicie o Protected Browser, autentique-se e clique em ícone SSH na barra de ferramentas.
Selecione + New Host, atribua um nome de apresentação e introduza o valor do recurso SSH em Host. A porta 22 é definida automaticamente.
Introduza o nome de utilizador e a palavra-passe do sistema de destino e clique em Connect.

O teste é bem-sucedido se a sessão SSH abrir no browser. Em seguida, efetue um teste negativo com um utilizador fora do grupo atribuído e confirme que o acesso é recusado.

Controlar a transferência de ficheiros

Depois de estabelecida a ligação, utilize os controlos correspondentes ao protocolo:

RDP: Expanda o menu superior e selecione File Transfer > Upload para enviar um ficheiro. Para o transferir do host para o dispositivo, utilize o ícone de transferência da entrada pretendida.
SSH: Abra o controlo inferior e selecione File Transfer > Upload To Folder para enviar o ficheiro para a pasta do host. Para o transferir do host para o dispositivo, utilize o ícone de transferência.

Durante o piloto, teste apenas com um ficheiro inofensivo e sem dados confidenciais. Os ficheiros enviados são analisados e só seguem para o host se estiverem limpos. O envio é concluído quando aparece File scanned successfully, seguido da mensagem de confirmação. Teste separadamente a transferência do host para o dispositivo: esta é bem-sucedida quando o ficheiro chega intacto ao dispositivo de teste e pode ser aberto.

Solucionar problemas por sintoma

A ação RDP/SSH está ausente ou um host criado manualmente não se conecta

Verifique pela seguinte ordem:

+ New Host foi selecionado usando o símbolo RDP ou SSH e o FQDN interno exato ou o endereço IP do recurso associado inserido em Host?
O utilizador de teste é membro do grupo selecionado em Assign User Groups?
O recurso ZTNA correto está no grupo de aplicações em Assigned?
A política de Internet que permite o acesso utiliza exatamente este grupo de aplicações?
O dispositivo de teste cumpre o estado opcional, nomeadamente Windows, proteção Sophos Endpoint e estado de integridade Green?

As alterações num grupo de utilizadores ZTNA podem demorar até uma hora a ficar visíveis no gateway. Não crie imediatamente novos objetos enquanto a alteração do grupo estiver pendente.

Se o host introduzido manualmente estiver correto, verifique a acessibilidade do host de destino na perspetiva do gateway selecionado. RDP utiliza sempre TCP 3389 e SSH utiliza sempre TCP 22; um serviço noutra porta não corresponde a estes tipos de recurso.

Se o erro persistir, encaminhe o diagnóstico para o responsável pelo ZTNA. O prazo de validade dos tokens de suporte é definido nas definições globais do ZTNA. Crie o token Sophos support for gateway instance para a instância afetada em Gateway > Gateway Details. Disponibilize o token apenas para um caso específico e com um prazo de validade deliberadamente curto.

O acesso só falha com o estado do dispositivo ativado

Não remova sem controlo a condição do dispositivo de uma política de produção. Primeiro, compare a plataforma, a proteção do endpoint e o estado de integridade comunicado pelo dispositivo piloto com o objeto Grünes Windows. Para uma comparação isolada, utilize uma política piloto de Internet separada, sem estado do dispositivo; mantenha o grupo de utilizadores estritamente limitado.

O ficheiro não foi carregado

O envio só ocorre após uma análise bem-sucedida. Se a mensagem File scanned successfully não aparecer ou o ficheiro não for classificado como limpo, o envio não será considerado bem-sucedido. Em vez de contornar a análise, utilize um ficheiro de teste inofensivo e comunique a falha, indicando a hora, o utilizador, o host de destino e o nome do ficheiro.

Reposição segura e desativação

As informações aprovadas do produto não documentam um processo completo de eliminação de todos os objetos do Protected Browser envolvidos. Por isso, não elimine o gateway, o DNS, os certificados nem as políticas partilhadas como se essa ação fosse uma reposição.

Para interromper o acesso de forma imediata e reversível, pode abrir-se uma política ZTNA dedicada em My Products > ZTNA > Policies. No separador Policy enforced, desativa-se a aplicação desta política dedicada. Neste estado, os utilizadores não podem aceder aos recursos geridos por esta política.

Antes de fazer isso, verifique se apenas os recursos RDP ou SSH pretendidos estão realmente atribuídos a esta política. Depois, teste com o utilizador piloto e confirme que a ligação deixa de ser estabelecida. Para restaurar o acesso, volte a definir a mesma política dedicada como Policy is enforced e repita o teste de ligação. Se a política for utilizada por outros recursos, interrompa o procedimento antes da alteração e entregue o caso ao proprietário do ZTNA.

Para desativar permanentemente, primeiro documente o recurso, o gateway, a política, os grupos de utilizadores, o grupo de aplicações e a política da Internet. O respetivo responsável remove depois as atribuições e os objetos pela ordem das dependências. Sem um processo de eliminação aprovado e específico do produto, o limite seguro é atingido antes de eliminar objetos partilhados de ZTNA, DNS ou certificados.

Operação e ciclo de vida

Pelo menos cada vez que há uma alteração nos grupos de utilizadores, gateways, nomes de host internos ou condições de dispositivos, um teste positivo e negativo é repetido. Além disso, o proprietário deve verificar regularmente:

se os hosts RDP e SSH estão acessíveis na perspetiva do gateway;
se apenas os grupos necessários são atribuídos;
se os recursos, os grupos de aplicações e as políticas da Internet ainda estão claramente interligados;
se os domínios e certificados são válidos e atribuídos ao gateway correto;
se o tempo mínimo global para regras de integridade do dispositivo corresponde ao comportamento desejado;
se um token de suporte gerado expirou e não existe mais do que o necessário.

Os recursos RDP e SSH sem agente continuam a ser um caminho de acesso separado. As alterações aos tempos limite do túnel do agente ou à implementação baseada no agente não substituem uma nova verificação no Protected Browser. Este guia também não define datas de transição, desativação ou fim de vida. Após uma alteração do produto, o proprietário deve verificar as definições visíveis no tenant e repetir o processo piloto.