Sophos Protected Browser: resolver problemas de acesso e início de sessão

Este runbook ajuda a delimitar problemas de acesso com o Protected Browser e recursos RDP/SSH ZTNA sem agente. No Sophos Central, abre-se Meine Produkte > Protected Browser e começa-se pelo sintoma visível. Corrige-se apenas a causa confirmada durante as verificações. Alterações abrangentes ao DNS, diretório de utilizadores ou ZTNA dificultam o diagnóstico.

Percurso rápido: Se a adição ou edição de um recurso já falhar, verificam-se os endereços de email de todos os membros do grupo de utilizadores utilizado. Se um recurso existente estiver inacessível sem uma mensagem de erro concreta, testa-se primeiro o portal de utilizador ZTNA e depois a resolução DNS do FQDN do gateway ZTNA. Perante «Netzwerk nicht erreichbar» ou «Verbindung konnte nicht hergestellt werden», compara-se diretamente o fornecedor de identidade configurado no ZTNA com o método de início de sessão da sessão do Protected Browser. Se o início de sessão no Protected Browser falhar, verificam-se o acesso ao Self Service Portal e a existência de um endereço de email único entre tenants. A mensagem «Hostschlüsselüberprüfung fehlgeschlagen» é tratada separadamente.

Pré-requisitos e limites de trabalho seguros

As verificações descritas exigem um ambiente Protected Browser e ZTNA já configurado, bem como um utilizador afetado claramente identificado. A ausência de menus ou permissões não permite concluir que existe uma causa específica de licença ou função. Nesse caso, a verificação é encaminhada para o administrador Sophos Central responsável.

Para verificar o utilizador no Sophos Central, é necessário acesso a Meine Umgebung > Benutzer und Gruppen > Benutzer. Para o teste de conectividade, têm de ser conhecidos o FQDN do gateway ZTNA efetivamente configurado e o tipo de gateway: Sophos Cloud Gateway ou gateway local. No comando, substitui-se o marcador de posição pelo FQDN do gateway ZTNA e não pelo nome de um recurso RDP/SSH de destino.

Durante o diagnóstico, altera-se apenas um valor de cada vez e volta-se a testar com o mesmo utilizador e o mesmo dispositivo. Se um pré-requisito não for claro ou não existir acesso à gestão de utilizadores, interrompe-se o diagnóstico e encaminha-se o caso para o administrador responsável pelo Sophos Central, serviço de diretório ou ZTNA.

Resolução de problemas por sintoma

Falha ao adicionar ou editar um recurso RDP/SSH sem agente

Causa provável: Pelo menos um membro do grupo de utilizadores utilizado não tem um endereço de email válido. Isto pode afetar tanto um recurso ZTNA como um recurso RDP/SSH num grupo de aplicações do Protected Browser.

Verificação:

1. Abre-se Meine Umgebung > Benutzer und Gruppen > Benutzer.
2. Na coluna E-Mail, verificam-se todos os utilizadores do grupo que será atribuído ao recurso ou grupo de aplicações.

Resultado esperado: Cada utilizador no grupo afetado tem um endereço de email válido. Uma entrada vazia confirma o estado de erro.

Medida segura: O endereço em falta é adicionado no serviço de diretório principal. Apenas para utilizadores criados manualmente no Sophos Central se adiciona o endereço diretamente no Sophos Central. Os endereços existentes não são alterados com base em suposições.

Validar novamente: Repete-se a tentativa de adicionar ou editar o mesmo recurso sem alterar o grupo. Se continuar a falhar apesar de a coluna E-Mail estar completa, esta causa não está confirmada. Em vez de alterar mais dados de identidade, registam-se o tipo de recurso, o grupo, a hora e a mensagem visível, e encaminha-se o caso.

Recurso RDP/SSH sem agente inacessível através do Protected Browser

Causa provável: O dispositivo não consegue resolver corretamente o FQDN do gateway ZTNA. Contudo, o primeiro ponto de separação é o portal de utilizador ZTNA: se este já estiver inacessível através do Protected Browser, o problema ocorre antes do recurso RDP/SSH individual.

Verificação:

1. No mesmo dispositivo e com o mesmo utilizador, tenta-se abrir o portal de utilizador ZTNA através do Protected Browser.
2. Se o portal estiver inacessível, executa-se uma consulta DNS no dispositivo afetado:

nslookup <ZTNA-Gateway-FQDN>

<ZTNA-Gateway-FQDN> é substituído pelo nome do gateway efetivamente configurado. nslookup é um teste só de leitura e não altera qualquer configuração.

Resultado esperado: Num Sophos Cloud Gateway, o nome do gateway é resolvido para o endereço do proxy do gateway. Num gateway local, é resolvido para o endereço do gateway ZTNA configurado no servidor DNS da organização. Compara-se a resposta com o destino efetivamente configurado para o modelo de gateway em questão. Se a resolução falhar, é necessário verificar a configuração DNS. Uma resposta diferente só confirma um erro quando não corresponde ao destino configurado. Se o destino pretendido for desconhecido, não se altera o DNS e encaminha-se a verificação para o responsável pelo DNS/ZTNA.

Medida segura: A configuração DNS é corrigida de acordo com o procedimento DNS/ZTNA previsto. A zona e o destino corretos dependem do modelo de gateway; por isso, não são efetuadas aqui alterações gerais ao DNS.

Validar novamente: Depois de o responsável pelo DNS/ZTNA confirmar uma correção segundo o procedimento previsto, executa-se novamente a mesma consulta nslookup. Em seguida, abre-se o portal de utilizador ZTNA e só depois se testa o recurso RDP/SSH original. Se a resposta DNS for a esperada e o portal estiver acessível, mas o recurso continuar inacessível, documentam-se estes dois controlos positivos e encaminha-se a verificação ZTNA específica do recurso.

«Netzwerk nicht erreichbar» ou «Verbindung konnte nicht hergestellt werden»

Causa provável: O ZTNA utiliza um fornecedor de identidade, como Okta ou Entra ID, mas o utilizador iniciou sessão no Protected Browser com o respetivo Sophos ID ou como utilizador local. Ao aceder a uma aplicação SSH ou RDP por trás do gateway ZTNA, podem surgir as mensagens indicadas.

Verificação: Identifica-se o fornecedor de identidade configurado no ZTNA e compara-se com o método de início de sessão da sessão atual do Protected Browser.

Resultado esperado: A causa é confirmada se o ZTNA utilizar um fornecedor de identidade, mas a sessão do Protected Browser não tiver sido autenticada através desse fornecedor.

Medida segura: Termina-se a sessão afetada e inicia-se a sessão do utilizador no Protected Browser através do fornecedor de identidade configurado no ZTNA. O fornecedor de identidade do ZTNA não é alterado para contornar um único erro de início de sessão.

Validar novamente: Na sessão novamente autenticada, abre-se a mesma aplicação SSH ou RDP. Se a mensagem persistir apesar de os métodos de início de sessão coincidirem, registam-se o fornecedor de identidade, o utilizador, o recurso e a hora, e encaminha-se o caso para o responsável pelo ZTNA.

O utilizador não consegue iniciar sessão no Protected Browser

Verificam-se aqui duas causas independentes. Não são corrigidas ao mesmo tempo, para que a causa efetiva permaneça identificável.

Falta acesso ao Self Service Portal

Verificação: Abre-se Meine Umgebung > Benutzer und Gruppen > Benutzer e verifica-se a coluna Rolle do utilizador afetado. Em alternativa, seleciona-se o nome de utilizador e verifica-se o texto sob a fotografia de perfil.

Resultado esperado: Quando existe acesso ao Sophos Central Self Service Portal, é apresentado SelfService na coluna Rolle ou sob a fotografia de perfil.

Medida segura: Se SelfService não estiver presente, a atribuição de acesso ao Self Service Portal é encaminhada para o administrador Sophos Central responsável.

Validar novamente: Confirma-se primeiro a apresentação de SelfService e, em seguida, repete-se o início de sessão exatamente com esse utilizador.

O endereço de email está associado a várias contas Sophos Central

Verificação: Determina-se se o endereço de email do utilizador afetado está atribuído a várias contas Sophos Central.

Resultado esperado: O endereço não pode estar associado a várias contas Sophos Central.

Medida segura: A associação deve ser corrigida pelo administrador responsável pelo tenant ou pelas identidades. Sem um tenant de destino confirmado, não se elimina qualquer utilizador nem se altera um endereço de produção.

Validar novamente: Depois de confirmada a associação única, repete-se o início de sessão no Protected Browser. Se continuar a falhar, documentam-se SelfService, a associação do email, a hora e a mensagem visível para o encaminhamento.

O SSH apresenta «Hostschlüsselüberprüfung fehlgeschlagen»

Causa provável: A chave guardada no cliente SSH já não corresponde à chave do host. Isto pode acontecer após uma alteração legítima, como uma reinstalação, mas a mesma mensagem também pode indicar uma alteração inesperada.

Verificação: Obtém-se a impressão digital esperada da chave do host junto do responsável pelo sistema através de um canal independente e fidedigno e compara-se com a impressão digital do host de destino correto. Não se confia na ligação SSH falhada nem na nova chave aí apresentada. Se a impressão digital esperada não tiver sido confirmada de forma independente, não corresponder ou a alteração não puder ser explicada, interrompe-se o processo neste ponto e encaminha-se como incidente de segurança.

Resultado esperado: O host de destino, a alteração legítima da chave e a impressão digital esperada foram confirmados de forma independente e inequívoca.

Medida segura: Antes de eliminar, determina-se que entradas são removidas pela função disponibilizada pelo cliente SSH utilizado. A Sophos apresenta Bekannte Hosts löschen como exemplo, mas não confirma que esta função remova apenas o host afetado. Se o âmbito da eliminação for desconhecido ou não for possível confirmar de forma independente a impressão digital esperada, não se efetua qualquer reset e encaminha-se o caso. A chave guardada só é removida quando o âmbito estiver esclarecido e a impressão digital confirmada. Na ligação seguinte, aceita-se apenas a chave cuja impressão digital corresponda à confirmação independente.

Validar novamente: Restabelece-se a ligação. A verificação da chave do host deve ser concluída com êxito com a chave recém-aceite. Se a mensagem voltar a surgir ou a chave mudar novamente de forma inesperada, não se removem entradas repetidamente; encaminha-se o caso com o nome do host, a hora e o cliente SSH.

Reversão, encaminhamento e limites operacionais

Não existe um rollback universal para estes problemas. Para um retorno seguro, não se efetuam alterações abrangentes e documenta-se o valor inicial de qualquer associação de utilizador alterada de forma específica. Se a medida não resolver o problema, interrompe-se o processo no ponto de encaminhamento relevante. A eliminação de chaves de host SSH conhecidas não é um reset geral e só é aceitável com uma impressão digital confirmada de forma independente e um âmbito de eliminação conhecido.

Para um encaminhamento interno ou para o suporte, registam-se, no mínimo, o sintoma, o utilizador, o dispositivo, o tipo de recurso, o modelo de gateway, o FQDN do gateway ZTNA, a hora e o resultado da verificação diretamente relacionada. Credenciais, chaves privadas e tokens não devem ser incluídos no ticket.

Repete-se apenas a verificação associada à medida efetivamente executada ou ao encaminhamento confirmado: voltar a adicionar ou editar o recurso depois de corrigir o email; iniciar sessão após a confirmação do acesso ao Self Service Portal ou da associação única da conta; abrir o recurso depois de iniciar sessão através do fornecedor de identidade configurado; ou estabelecer a ligação SSH depois do reset controlado da chave do host. Após o encaminhamento para o responsável pelo DNS/ZTNA, só se voltam a testar nslookup, o portal de utilizador e o recurso original quando este confirmar uma correção de acordo com o respetivo procedimento.

Delimitação face a guias relacionados

Este runbook abrange exclusivamente os sintomas do Protected Browser aqui descritos. A configuração do Protected Browser ou da extensão, bem como a configuração geral de DNS e ZTNA, pertencem aos respetivos guias de configuração. Quando tal configuração for necessária, encaminha-se o caso para o administrador responsável.