Saltar para o conteudo
Avanet

Acesso RDP e SSH sem agente com Sophos Protected Browser

Sophos Workspace Protection

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 Agentenlose RDP-Anwendungen e Agentenlose SSH-Anwendungen. 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 Meine Produkte > ZTNA, bem como objetos de política e políticas de Internet em Meine Produkte > 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 Interner FQDN/IP-Adresse der Ressource; não é possível adicionar Externen 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.

  1. Abra Meine Produkte > ZTNA > Richtlinien.
  2. Clique em Richtlinie hinzufügen.
  3. Em Richtlinie hinzufügen, selecione o tipo Agentenlos. Noutras vistas do ZTNA, este tipo aparece como Ohne Agent. O aviso Agent anfordern refere-se ao caminho baseado no agente; esta política não requer um agente.
  4. Em Neue Richtlinie, introduza um nome, por exemplo Agentenloser Zugriff.
  5. Abra Richtlinie durchgesetzt e ative Richtlinie wird durchgesetzt.
  6. Clique em Speichern.

O tipo de política ZTNA Agent e os respetivos túneis não fazem parte deste procedimento. A definição global Zeitüberschreitung wegen Inaktivität des Agent-Tunnels 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 Mindestzeit, bevor die Geräte-Integrität eine Regel auslöst se o ambiente utilizar a integridade do dispositivo.

Adicionar recurso RDP ou SSH

Abra Meine Produkte > ZTNA > Ressourcen und Zugriff e clique em Ressource hinzufügen. Preencha o formulário com os valores do protocolo pretendido.

Recurso RDP

  1. Por exemplo, insira Agentenloses RDP como Ressourcenname. Uma descrição é opcional.
  2. Escolha o gateway que consegue alcançar rdp01.intern.example.
  3. Em Zugriffsmethode, selecione Agentenlos.
  4. Escolha a política Agentenloser Zugriff.
  5. Em Ressourcentyp, 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.
  6. Em Interner FQDN/IP-Adresse der Ressource, introduza o host interno. Um FQDN externo não pode ser incluído para este tipo de recurso.
  7. Em Benutzergruppen zuweisen, mova apenas o grupo piloto necessário de Verfügbar para Zugewiesen.
  8. Clique em Speichern.

Recurso SSH

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

  1. Ressourcenname: por exemplo Agentenloses SSH.
  2. Zugriffsmethode: Agentenlos.
  3. Richtlinie: Agentenloser Zugriff.
  4. Ressourcentyp: SSH. A porta 22 e o tipo de porta de acesso TCP são definidos automaticamente e não podem ser alterados.
  5. Interner FQDN/IP-Adresse der Ressource: por exemplo ssh01.intern.example; um FQDN externo não está disponível.
  6. Benutzergruppen zuweisen: mova apenas o grupo piloto pretendido para Zugewiesen e, em seguida, selecione Speichern.

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 Ohne Agent. 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:

  1. Abra Meine Produkte > Protected Browser > Richtlinienobjekte.
  2. Clique em Objekt hinzufügen > Gerätestatus.
  3. Insira Grünes Windows como o nome.
  4. Em OS-Plattform, selecione Windows.
  5. Em Endpoint Protection, selecione Prüfen, ob Gerät durch Sophos Endpoint geschützt ist e depois o estado de integridade Grün.
  6. Clique em Speichern.

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

  1. Permaneça em Meine Produkte > Protected Browser > Richtlinienobjekte.
  2. Clique em Objekt hinzufügen > Anwendungsgruppe.
  3. Insira um nome exclusivo, por exemplo Agentenlose RDP-Gruppe.
  4. Expanda ZTNA-Ressourcen.
  5. Em Verfügbar, selecione o recurso criado anteriormente e mova-o para Zugewiesen.
  6. Clique em Speichern.

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

  1. Abra Meine Produkte > Protected Browser > Internetrichtlinie e selecione a guia Richtlinien.
  2. Clique em Richtlinie hinzufügen.
  3. Insira um nome exclusivo, por exemplo Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität.
  4. Certifique-se de que Zulassen esteja selecionado.
  5. Se for utilizado, selecione o estado do dispositivo Grünes Windows.
  6. Selecione o grupo de aplicações Agentenlose RDP-Gruppe.
  7. Clique em Speichern.

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

  1. Inicie o Sophos Protected Browser e autentique-se.
  2. Na parte superior da barra de ferramentas, clique no ícone de Ligação ao Ambiente de Trabalho Remoto e, em seguida, clique em + Neuer Host.
  3. 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.
  4. Introduza o nome de utilizador e a palavra-passe do sistema de destino e clique em Verbinden.

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

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

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 Dateiübertragung > Hochladen 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 Dateiübertragung > In Ordner hochladen 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 Datei erfolgreich gescannt, 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:

  1. + Neuer 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?
  2. O utilizador de teste é membro do grupo selecionado em Benutzergruppen zuweisen?
  3. O recurso ZTNA correto está no grupo de aplicações em Zugewiesen?
  4. A política de Internet que permite o acesso utiliza exatamente este grupo de aplicações?
  5. O dispositivo de teste cumpre o estado opcional, nomeadamente Windows, proteção Sophos Endpoint e estado de integridade Grün?

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 für Gateway-Instanz para a instância afetada em Gateway > Gateway-Einstellungen. 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 Datei erfolgreich gescannt 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 Meine Produkte > ZTNA > Richtlinien. No separador Richtlinie durchgesetzt, define-se como Richtlinie umgangen. 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 Richtlinie wird durchgesetzt 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.