Implementar o Sophos Fusion Server Protection em servidores de terminal RDS

As sessões RDS requerem uma licença de Server Protection; não é necessária uma licença Endpoint Protection separada por sessão. Prevalecem sempre o contrato concreto e a EULA. As políticas de servidor são atribuídas ao host, não individualmente aos utilizadores com sessão iniciada. Este é um limite essencial no planeamento de ambientes RDS, servidores de terminal e Citrix.

Por isso, a sequência segura é: verificar a plataforma e a licença, testar um session host representativo, decidir antecipadamente as políticas para todo o servidor, encerrar as sessões ativas de forma controlada, instalar e só depois da validação técnica e funcional avançar para outros hosts. A criação de imagens VDI e a identificação dos utilizadores na firewall são tarefas distintas.

Âmbito e limites do suporte

Não está disponível para este guia uma matriz de compatibilidade RDS específica da Sophos que se possa consultar com suficiente confiança atualmente. Listas antigas de versões Windows e Citrix não devem ser usadas como aprovação atual para novas instalações. Antes da implementação, verificar a combinação concreta de Windows convidado, agente Sophos para servidores e respetiva versão, versão RDS ou Citrix incluindo a CU, e ambiente de virtualização face ao suporte em vigor. No caso do Citrix, verificar também o ciclo de vida e, se aplicável, o Extended Support contratado. Se a combinação continuar por esclarecer, pedir confirmação por escrito ao suporte da Sophos; não deduzir a aprovação da idade ou do nome de uma plataforma.

Para o agente de servidor num ambiente RDS virtualizado, não está comprovada uma aprovação geral de determinados hipervisores nem um âmbito de suporte genérico segundo o princípio de esforços razoáveis. Verificar separadamente o sistema operativo convidado, a plataforma do host e a camada Citrix/RDS; esclarecer com a Sophos e o fabricante da plataforma as condições de suporte e reprodução aplicáveis ao caso concreto. A aprovação de uma appliance virtual ou de um hipervisor não equivale à aprovação do sistema RDS convidado protegido.

Daqui resultam três distinções claras:

Host RDS ou Citrix multiutilizador: após a confirmação da combinação concreta de plataformas, instalar Server Protection no Windows convidado; a política de servidor aplica-se ao host.
Máquinas VDI clonadas ou não persistentes: o ciclo de vida da imagem segue o procedimento separado para imagens-mestre VDI com Sophos. Não clonar simplesmente um agente instalado da forma habitual.
Regras de firewall por utilizador: não são fornecidas por esta instalação de servidor. Quando várias sessões partilham o mesmo IP de servidor, o SATC para Remote Desktop Services descreve a atribuição de identidade separada na Sophos Firewall.

Decidir funções e políticas antes da implementação

Verificar a proteção prevista para cada função no tenant de destino, tendo em conta a licença contratada, o Windows convidado e os componentes do agente instalados. Não está confirmada aqui uma matriz completa de funções específicas de RDS para cada nível de licença de servidor. Em particular, não equiparar um sensor XDR isolado a uma instalação de Server Protection que efetivamente protege o sistema. Esclarecer a licença e as condições contratuais com base no licenciamento Sophos Fusion (anteriormente Sophos Central) e na EULA em vigor.

Medida de precaução para o piloto, não um limite de suporte RDS comprovado: por enquanto, não atribuir ao session host a função de host de Update Cache ou Message Relay, nem ativar a função antiga Server Lockdown ou Unauthorized File Protection (UFP) como nova medida de reforço da segurança. A Sophos mudou o nome de Server Lockdown para Unauthorized File Protection; isso não demonstra que a função antiga ou a nova sejam aprovadas ou proibidas especificamente em RDS. Antes de qualquer alteração, pedir confirmação específica para RDS, distinguindo se o host pode operar um cache ou relay de se pode utilizar esse serviço, e esclarecer os requisitos de Lockdown e UFP, incluindo uma eventual migração. Esta opção prudente para o piloto não representa nem uma proibição geral nem uma aprovação, e não justifica desativar indiscriminadamente outros módulos de proteção.

Políticas para o servidor, não para cada utilizador

As políticas de servidor são atribuídas ao session host e não constituem políticas de servidor separadas para cada utilizador RDS. Não é possível, através desta política de servidor, dar à utilizadora A controlos Web, Application, Peripheral ou DLP diferentes dos do utilizador B no mesmo host. Isto não se aplica necessariamente a outros produtos de utilizador ou de firewall configurados de forma independente.

Antes do piloto, esclarecer com os responsáveis pelas aplicações e pelas áreas de negócio:

Que aplicações e scripts são executados em todas as sessões?
De que periféricos necessitam determinadas funções, apesar de a decisão se aplicar ao servidor inteiro?
Que regra Web ou DLP é aceitável para todos os utilizadores deste host?
Que partilhas e caminhos dos perfis de utilizador devem ser abrangidos pelo Real-Time Scanning?
Que exceções estão tecnicamente comprovadas, têm âmbito restrito e estão documentadas com responsável e prazo de validade?

Se os grupos de utilizadores precisarem efetivamente de controlos diferentes, devem ser distribuídos por coleções distintas de session hosts, cada uma com a política de servidor adequada. Uma política comum amplamente permissiva não substitui esta separação.

Mensagens no ambiente de trabalho em várias sessões

O Desktop Messaging comunica eventos de proteção e está ativado por predefinição na política de Server Threat Protection. Não está demonstrado aqui um comportamento RDS universal para a distribuição de uma mensagem pelas sessões paralelas num servidor de terminal concreto. Também não está confirmada uma lista fixa de exceções quando a opção é desativada. Num piloto com várias sessões, verificar quem vê cada mensagem e que notificações continuam a ser geradas pelos componentes efetivamente instalados, mesmo depois de alterar a definição.

O suporte técnico e os utilizadores não devem atribuir uma mensagem visível a uma sessão específica sem verificação. Antes da implementação, definir os textos das mensagens, o canal de suporte e a correlação por hora, servidor, alerta no Fusion e processo afetado. Não encerrar um alerta apenas com base no relato de um único utilizador.

Planear o piloto e a instalação

Pré-requisitos

Antes do primeiro host, devem estar reunidas as seguintes condições:

O Windows convidado, a versão RDS ou Citrix e a plataforma de virtualização estão abrangidos pelo suporte confirmado.
Está disponível uma licença de servidor adequada; o host será instalado como servidor, não com um instalador Endpoint normal.
O host consegue comunicar com o Sophos Fusion pelas vias de rede documentadas, diretamente ou através de uma arquitetura de proxy ou relay confirmada para este sistema RDS convidado. Verificar separadamente a utilização de cache e relay e a operação destes serviços no próprio host.
Foram definidos um host piloto representativo, uma janela de manutenção, critérios de aceitação técnicos e funcionais e um responsável pela reversão.
As sessões RDS ativas podem ser terminadas de forma ordenada e os novos inícios de sessão impedidos durante a alteração.
O backup, snapshot ou outro ponto de retorno respeita o procedimento do operador da plataforma e a sua capacidade de restauro foi testada fora desta alteração.
A política de servidor prevista está atribuída ao grupo piloto; por precaução, as funções de host de cache/relay e Lockdown/UFP não serão ativadas no piloto até que sejam esclarecidos os requisitos específicos de RDS.

No tenant correto, obter o Windows Server Installer em Sophos Fusion Admin, em My Environment > Installers > Server Protection > Full malware protection, e não o instalador do sensor XDR isolado. A implementação automatizada segue as mesmas regras fundamentais da implementação controlada em Windows: proteger o pacote de instalação associado ao tenant, executá-lo no contexto de administrador local ou do sistema, recolher o código de saída real e não concluir, apenas por o processo ter arrancado com sucesso, que a proteção está completa. A escolha do produto, o grupo de destino e a licença têm, contudo, de corresponder a Server Protection.

Executar o piloto

Bloquear novos inícios de sessão no host piloto, informar os utilizadores e terminar ordenadamente as sessões ativas. Não forçar uma mudança de agente durante sessões de produção.
Documentar o estado inicial: nome do host, versões de OS e RDS/Citrix, grupo Fusion, políticas atribuídas, software de segurança instalado, estado de funcionamento e ponto de retorno.
Remover produtos concorrentes e os respetivos controladores de filtragem segundo o plano de migração aprovado ou aplicar a coexistência confirmada. Não executar dois scanners em tempo real em paralelo sem validação.
Executar o instalador de servidor atual do tenant de destino com privilégios administrativos. Em caso de distribuição de software, transmitir o código de saída do instalador ao sistema de implementação sem o alterar.
Concluir os reinícios solicitados dentro da janela de manutenção. Só depois permitir inícios de sessão para a verificação técnica.
Com algumas contas de teste, verificar aplicações habituais, perfis, impressoras, partilhas e processos Web e DLP. Só depois admitir utilizadores reais no piloto.
Observar o host sob carga multiutilizador normal durante o período acordado. Não há um valor universal da Sophos para o número de sessões nem para a reserva de CPU/RAM; prevalecem a referência inicial da própria plataforma e os critérios de aceitação da respetiva equipa.

Não alterar vários hosts em simultâneo. Um único início de sessão bem-sucedido não demonstra a compatibilidade das aplicações em todo o servidor nem o comportamento sob carga multiutilizador habitual.

Aceitação e operação

O piloto só é bem-sucedido quando todos os seguintes níveis estão validados:

Local: o agente de servidor apresenta um estado saudável; a instalação e os reinícios necessários estão concluídos.
Fusion: o host aparece exatamente uma vez como servidor no tenant e grupo corretos, está atualizado e recebe as políticas de servidor esperadas.
Proteção: os componentes de proteção acordados estão instalados; as funções de host de cache/relay e Lockdown/UFP, suspensas por precaução, não foram ativadas.
Sessões: vários utilizadores de teste conseguem iniciar sessão em paralelo, abrir as aplicações principais, carregar perfis e utilizar os recursos necessários.
Políticas: os controlos Web, Application, Peripheral e DLP efetivamente disponíveis comportam-se nas sessões de teste conforme decidido; foi verificada a visibilidade das mensagens noutras sessões.
Operação: comparar CPU, memória, duração dos inícios de sessão e tempo de resposta das aplicações com a referência da plataforma registada antes do piloto. Investigar os desvios, não ocultá-los com exclusões sem fundamento.

Só depois desta aceitação se planeia a próxima pequena vaga de hosts. As alterações às políticas continuam a ser testadas num grupo piloto, pois uma única política de servidor afeta simultaneamente muitas sessões de utilizador.

Resolução de problemas e reversão segura

Um utilizador recebe a política errada

Num host RDS não existem políticas de servidor específicas para cada utilizador. Verificar primeiro o grupo Fusion, a atribuição e a prioridade da política do servidor. Se grupos de utilizadores precisarem de controlos diferentes, a solução sólida é separá-los por coleções de hosts, não criar uma exceção por utilizador com sessão iniciada.

Uma mensagem aparece em várias sessões

Documentar essa observação no próprio piloto, sem a tratar como garantia geral para todas as instalações RDS. Correlacionar hora e servidor com alertas e eventos no Fusion e identificar o processo responsável. Testar no tenant a definição de Desktop Messaging da política de servidor em vigor e as mensagens que cada componente continua a emitir. Não interpretar a mensagem, por si só, como prova de que todas as sessões em que foi visível foram afetadas.

Aplicações ou inícios de sessão apresentam anomalias após o piloto

Suspender as próximas vagas de implementação. Recolher primeiro os eventos Fusion, o estado do agente, os eventos Windows e o processo afetado. Em seguida, repor a política piloto alterada mais recentemente no estado previamente documentado e voltar a testar. Criar exceções apenas para o processo ou caminho confirmado e com âmbito restrito; não introduzir exclusões gerais de unidades, perfis ou processos como suposta otimização de desempenho.

Se o problema persistir, retirar o host do serviço aos utilizadores e guardar os logs e os dados do Sophos Diagnostic Utility para o suporte. Se a falha ocorrer apenas em Citrix ou noutra plataforma virtual, esclarecer com o suporte da Sophos e o fabricante da plataforma os passos necessários para a reproduzir e as responsabilidades de cada um.

Suspeita de falha do SSPService num host instável

Se ocorrerem reinícios do serviço, instabilidade do host ou mensagens relativas ao SSPService, guardar antes de qualquer alteração as versões exatas do agente e dos componentes, o sistema operativo, as horas dos eventos, os eventos Windows e os logs de diagnóstico. Mesmo entradas como Process registration over the secure quota em sed.log são apenas indícios de diagnóstico: não está confirmado aqui um defeito específico de RDS com um intervalo de versões, uma sequência de eventos nos logs e uma solução determinados. Não confundir outros tipos de falha com nomes de serviço semelhantes.

Suspender as próximas vagas de implementação e retirar o host afetado do serviço aos utilizadores segundo os procedimentos de manutenção e resposta a incidentes. Pedir ao suporte da Sophos o ID do incidente, a presença esperada do serviço após um reinício, as versões afetadas, a versão que corrige o problema e uma solução aprovada para este host. Não alterar a Tamper Protection com base apenas neste indício nem apresentar um reinício como correção confirmada.

Reversão

Definir a reversão antes do piloto e executá-la segundo o tipo de falha:

Suspender novas atribuições e vagas de implementação; bloquear novos inícios de sessão no host afetado.
Se a falha estiver na política, restaurar a atribuição anteriormente documentada e voltar a testar após a sincronização com o Fusion.
Se a falha estiver na plataforma ou no agente, terminar as sessões ordenadamente, guardar os dados de diagnóstico e repor o host de acordo com o procedimento aprovado de desinstalação do agente de servidor ou de restauro da plataforma. Eliminar apenas o objeto do dispositivo no Fusion não desinstala o agente.
Só voltar a integrar o host no pool do broker depois de verificar as aplicações, as sessões paralelas, o estado no Fusion e a proteção ou uma proteção alternativa confirmada.

Não restaurar cegamente um snapshot sobre um host ativo e registado no Fusion. A escolha entre restauro e reconstrução depende do procedimento testado para a plataforma RDS/Citrix e de virtualização. Após a reversão, investigar a causa e realizar um novo piloto; não retomar simplesmente a vaga que falhou.