Saltar para o conteudo
Avanet

Planear os requisitos de sistema e o ciclo de vida do Sophos Endpoint

Um agente instalado não permanece automaticamente suportado a longo prazo. O sistema operativo, a arquitetura, os componentes Sophos, os certificados e o modelo de licenciamento evoluem de forma independente. Por isso, uma operação Endpoint robusta não verifica apenas se a instalação funciona hoje, mas também quando as plataformas deixam de ser suportadas e como são introduzidas novas versões do agente.

Âmbito: Endpoint não é Server nem Linux

Este guia abrange Sophos Endpoint para postos Windows e macOS. Windows Server é gerido em Server Protection; Linux usa Sophos Protection for Linux, com requisitos, Release Notes e datas próprios. Uma linha Server ou Linux no Retirement Calendar comum não aprova Endpoint e pertence a outro Runbook.

Snapshot de aprovação e decisão de ciclo de vida

Os números concretos de versão e os limites de suporte ficam rapidamente desatualizados. Por isso, antes da primeira instalação, de um upgrade do sistema operativo, de uma mudança de pacote e pelo menos mensalmente, o responsável pelo ciclo de vida efetua a mesma revisão controlada. O ponto de partida é um snapshot de inventário com tipo de dispositivo, edição e build completo do sistema operativo, arquitetura, CPU, RAM, espaço livre na unidade do sistema, encriptação, âmbito de proteção necessário e componentes Sophos instalados com as respetivas versões.

Em seguida, são verificadas internamente as matrizes Sophos atualmente mantidas para Windows ou macOS e o Retirement Calendar. O registo de aprovação contém data da verificação, entrada examinada, plataforma e arquitetura, capacidade de instalação e upgrade, requisitos mínimos, exclusões, Maintenance, Retirement, condições de licença ou Extended Support e todas as notas. Um snapshot guardado comprova uma decisão, mas não constitui uma lista de suporte permanentemente válida; é substituído na alteração seguinte e a diferença é registada.

A decisão é aprovada, apenas piloto, migração necessária ou não aprovada. Indica responsável, âmbito, funções necessárias, limitações conhecidas, prazos do fabricante e da Sophos, destino da migração e data da próxima revisão. Se faltar a entrada exata de sistema operativo/arquitetura, houver contradições ou a matriz estiver inacessível, não há nova aprovação: o último estado aprovado permanece inalterado, o responsável regista hora da consulta e ambiguidade e esclarece-a com Sophos Support antes do piloto.

Requisitos Windows e limites de suporte

Para Windows, são verificados separadamente perante a entrada atual a edição e o build completo, x64 ou ARM64, CPU e RAM, espaço livre e unidade do sistema, atualizações e certificados Microsoft necessários e o modo de proteção pretendido. Os valores mínimos são apenas condições de entrada, não recomendações de capacidade. Os builds Insider, Preview e outras versões preliminares não são aprovados, salvo se a entrada exata os incluir expressamente.

Registe também o fim do suporte Microsoft. Instalação bem-sucedida, estado de Health sem erros e suporte atual da plataforma são três afirmações distintas. Windows Server não é um Endpoint Windows, mesmo com um build semelhante, e não está abrangido por esta aprovação.

Requisitos macOS e limites de suporte

Para macOS, verifique a versão completa do sistema operativo, Intel ou Apple Silicon, espaço livre, método de instalação e âmbito de proteção necessário. O processo de aprovação inclui também os perfis MDM utilizados para System Extensions, Network Extensions, filtro web/conteúdo, Full Disk Access e notificações. Uma entrada de OS compatível não demonstra, por si só, proteção eficaz.

Teste cada nova versão principal ou pontual do macOS, incluindo a capacidade atual do installer e do upgrade, num Mac piloto representativo. Registe expressamente as diferenças entre uma instalação nova e um agente já instalado; «macOS suportado» não implica que ambos os percursos ou todas as funções sejam suportados. Extended Support só é aceite quando a entrada macOS exata o indicar.

Componentes em vez de uma única versão do agente

O Sophos Endpoint é composto por vários componentes atualizados de forma independente, como AutoUpdate, Endpoint Defense, Health Service, Management Communication, Network Threat Protection, Endpoint UI e outros módulos dependentes da licença.

O nível visível no Central e um número local não descrevem o estado completo. Nesta revisão, o responsável abre o fluxo atualizado Sophos Core Agent para Windows ou Sophos Anti-Virus para macOS. Em cada revisão regista ao vivo build de destino, estado do rollout, correções e limitações conhecidas; o registo de versão documenta esse momento e não substitui nova verificação. O registo contém hora, plataforma, nó de produto/versão, aviso de publicação e rollout, builds, correções, problemas e diferenças. Associe cada ponto às funções usadas e aos dispositivos piloto e decida aprovar, adiar ou rejeitar. Um fluxo vazio, inacessível ou incoerente não aprova: guarde screenshot ou erro, verifique parâmetros e rede, repita e escale para Sophos Support; bloqueie pacote e fase seguinte.

Testar recursos e software de terceiros no piloto

O mínimo oficial é apenas um limiar de entrada. Um piloto representativo mede arranque e login, CPU, memória, espaço e I/O com o software real. Inclua SSD/HDD, encriptação, DLP, backup, VPN, controlo remoto e allowlisting como atributos.

Numa regressão, use Sophos Performance Analysis e logs. Não desative globalmente proteção ou Event Journals. Uma mitigação temporária exige responsável, data final, aceitação do risco e novo teste; a solução pode ser um fix, upgrade ou substituição de hardware.

Compreender o lançamento faseado

A Sophos publica algumas Release Notes no primeiro dia de um rollout com várias semanas. Assim, uma nova versão documentada pode não estar imediatamente disponível em todos os tenants ou endpoints.

Isto evita duas interpretações erradas:

  • Um dispositivo não está automaticamente desatualizado apenas porque ainda não recebeu a nova versão no dia da publicação.
  • Uma reinstalação manual não força, de forma fiável, uma versão de software que ainda não foi disponibilizada.

Níveis piloto e de produção

Software Packages e Update Management Policies permitem fases controladas:

  1. Piloto: IT e combinações representativas de hardware, OS e software.
  2. Produção inicial: pequena amostra após cumprir os critérios.
  3. Produção: atribuição ampla após aprovação do change.
  4. Pacote fixo: apenas por necessidade justificada, com responsável e expiração monitorizada.

Verifique nomes, disponibilidade, suporte, expiração e sobreposição no Sophos Fusion (anteriormente Sophos Central) e na página atual Software packages. Este artigo não fixa períodos. Updates de conteúdo de segurança são distintos das versões do produto.

Defina dispositivos saudáveis, componentes esperados, sem nova concentração de Alert e desempenho aceitável como critérios. Prepare rollback: pause a atribuição, isole o grupo, preserve Policy e Package, reatribua um pacote atual oferecido e testado pela Sophos e volte a verificar. Downgrade manual ou installer antigo não é fiável.

Extended Support é transitório

«Legacy» ou «Extended Support» é uma transição, não uma aprovação geral. Consulte a entrada exata do client OS, datas de Maintenance e Retirement, funções e eventual licença no Retirement Calendar. Atribua um prazo de migração a cada dispositivo.

As linhas Windows Server e Linux não pertencem ao grupo Endpoint. Planeie-as de acordo com os requisitos e as licenças específicos de Server Protection ou Sophos Protection for Linux. Não presuma Extended Support para macOS sem indicação explícita da Sophos para a versão exata.

Planear reinícios

A Sophos nem sempre força imediatamente um reinício necessário. As atualizações de proteção e Detection podem continuar a funcionar enquanto um componente aguarda o próximo reinício de manutenção.

Nos dispositivos que não são reiniciados há muito tempo, vários estados de Update podem exigir sucessivamente um reinício cada um. Deve ser concedido tempo suficiente entre dois ciclos para que a primeira atualização seja completamente processada. Os Central Alerts e o estado local do software são verificados novamente após cada reinício.

Early Access Programs

Um Early Access Program não é um canal de produção normal. Antes da adesão, definem-se a finalidade, os dispositivos de destino, as alterações esperadas, o método de suporte, o Exit Plan e as consequências para a proteção de dados.

Os dispositivos EAP pertencem a um grupo piloto claramente identificado. Depois de saírem, verifica-se quando voltam a receber a versão de software normal. Um EAP não deve ser ativado em dispositivos críticos apenas para contornar um problema específico sem analisar a causa.

Aplicar, validar e diagnosticar

O técnico aplica ao grupo piloto definido apenas o pacote aprovado no registo de aprovação; excluem-se mudanças improvisadas de installer, downgrades manuais e pacotes de instalação antigos. Antes, preserva o grupo de dispositivos, as atribuições de política e pacote, as versões dos componentes, o Health, os alertas abertos e um teste funcional reproduzível. O grupo de destino e os critérios de sucesso mantêm-se inalterados durante a observação.

Após a instalação, o update e cada reinício necessário, verifique no Central Last active, Health e alertas e, localmente, o estado dos serviços e as versões esperadas dos componentes. Repita depois os mesmos testes antes/depois: login e tempo de arranque, receção de políticas, capacidade de update, teste de malware segundo o procedimento interno, proteção de rede/web e todas as funções dependentes da licença. No macOS, comprove também que as extensões e autorizações de privacidade estão ativas. O responsável reconcilia o resultado com os registos de versão e aprovação e documenta os desvios em ambos; só um piloto totalmente aprovado abre a fase de rollout seguinte.

Primeiro, classifique a falha: plataforma não aprovada, installer bloqueado, componente desatualizado, rollout ainda não oferecido, reinício pendente, autorização MDM ausente ou conflito com software de terceiros. Recolha em conjunto hora, dispositivo, build do OS, arquitetura, pacote e política do Central, todas as versões dos componentes, Health/alertas, estado do reinício, passos reproduzíveis e logs relevantes. Em seguida, pare a atribuição do pacote a outros dispositivos e reverta isoladamente a última alteração se o Central disponibilizar para isso um pacote atual e já testado. Não desative globalmente a proteção nem force um installer antigo. Se a causa ou um retorno seguro permanecerem incertos, isole o piloto, marque o registo de versão como adiado e envolva a Sophos Support com este pacote de diagnóstico.

Controlo mensal do Lifecycle

Um ritmo operacional adequado inclui:

  • verificar as novas Endpoint e Central Release Notes,
  • comparar o Retirement Calendar com as plataformas próprias,
  • exportar dispositivos por sistema operativo, arquitetura e Agent Mode,
  • atribuir um responsável a dispositivos Legacy e inativos,
  • controlar Fixed-Term ou LTS Packages prestes a expirar,
  • resolver Restart e Update Alerts,
  • documentar os resultados piloto.

A arquitetura técnica de atualização é explicada em Sophos Endpoint Updates, Cache e Message Relay.

Perguntas frequentes

Porque é que um endpoint ainda não recebeu a nova versão apesar de as Release Notes terem sido publicadas?

A Sophos distribui frequentemente o software ao longo de vários dias ou semanas. As Release Notes podem aparecer logo no primeiro dia. O tenant, o Package Level e a Update Policy determinam quando um dispositivo recebe a versão.

Um agente instalado num Windows Legacy é automaticamente suportado na íntegra?

Não. Uma plataforma Legacy pode exigir uma Extended Support License e, ainda assim, não receber todas as novas funções ou correções. O estado atual do suporte tem de ser verificado explicitamente.