Atualizar não é só clicar em “Atualizar”: como gerenciar patches sem parar a empresa

Muitas invasões não acontecem porque a correção não existe. A correção já foi publicada pelo fabricante, mas não chegou a todos os computadores: um notebook ficou desligado nas férias, uma reinicialização foi adiada por semanas, um computador nunca entrou no inventário.

Por isso, manter a empresa atualizada não é só deixar a atualização automática ligada. É um processo, e é sobre ele que este texto fala. Se a dúvida é por que corrigir falhas importa tanto, comece por vulnerabilidades de segurança e riscos de TI.

Atualização automática e gestão de patches são a mesma coisa?

Não. Patch é a correção que o fabricante publica. Gestão de patches é o processo de garantir que essas correções cheguem aos equipamentos certos, na hora certa, e de comprovar que chegaram.

Atualização automática	Gestão de patches
Depende da configuração de cada computador	Mantém um inventário central de equipamentos
Nem sempre avisa quando falha	Identifica o que está faltando em cada um
Pode reiniciar na hora errada, ou nunca reiniciar	Usa grupos, políticas e janelas de manutenção
Quase nenhuma visibilidade central	Acompanha instalações, falhas e reinicializações
Não necessariamente cobre programas de outros fabricantes	Gera relatórios e evidências

A coluna da direita também tem limite: o que ela cobre depende da ferramenta, das integrações e do que foi contratado.

O que é RMM

RMM vem de Remote Monitoring and Management, ou monitoramento e gerenciamento remoto. É a plataforma que as empresas de TI gerenciada (MSPs) instalam nos computadores dos clientes para:

• manter o inventário de equipamentos e programas;
• monitorar disponibilidade e saúde, como disco cheio ou serviço parado;
• automatizar rotinas e executar tarefas a distância;
• distribuir atualizações;
• gerar alertas e relatórios;
• dar suporte técnico remoto.

O RMM é a ferramenta. A gestão de patches é um dos processos que a equipe executa com ela.

Como uma empresa de TI gerencia atualizações

1. Inventariar. Não dá para atualizar o que você não sabe que existe. O inventário lista computadores, servidores, sistemas e versões, e mostra quem está sem comunicação.
2. Identificar o que falta. A ferramenta compara o que está instalado com as correções publicadas e aponta as pendências de cada equipamento.
3. Priorizar. Nem tudo tem a mesma urgência. Uma falha que já está sendo explorada, como as do catálogo KEV da CISA, em um equipamento exposto à internet vem antes de uma melhoria de recurso no computador da recepção. O caso do PHP2Shell mostrou como o intervalo entre a divulgação e o ataque ficou curto.
4. Testar primeiro em um grupo piloto. A atualização vai antes para poucos equipamentos representativos. Se algo quebrar, quebra em pouco lugar. A Microsoft chama esse modelo de anéis de implantação, e o NIST recomenda a mesma lógica até para correções urgentes.
5. Programar a instalação. A distribuição geral acontece em uma janela que não atrapalhe o trabalho, combinada com a empresa.
6. Controlar reinicializações e exceções. Muitas atualizações só passam a valer depois de reiniciar. Computadores que nunca reiniciam ficam com a correção baixada, mas não aplicada.
7. Verificar e registrar. Conferir o que foi de fato instalado, o que falhou e por quê, e transformar isso em relatório.

Por que não instalar tudo imediatamente

Porque atualização também pode dar problema: um sistema de gestão que para de abrir, uma impressora que perde o driver. O NIST trata a atualização como manutenção preventiva, e manutenção bem feita equilibra risco e continuidade.

Esse equilíbrio tem dois ritmos. Uma falha crítica, exposta à internet e já explorada pede tratamento de urgência. Uma atualização de menor risco pode passar pelo grupo piloto e entrar na janela programada.

O que não pode existir é o adiamento sem fim. Toda exceção precisa de motivo, responsável e prazo, e, quando fizer sentido, de uma proteção no lugar, como isolar o equipamento da rede.

O que impede um computador de ficar atualizado

Mesmo com um bom processo, sempre existem pendências. As mais comuns:

• equipamento desligado, fora da empresa ou sem conexão estável;
• reinicialização pendente;
• falta de espaço em disco;
• instalação que falhou;
• sistema operacional ou programa sem suporte do fabricante;
• programa legado incompatível com a versão nova;
• correção que o fabricante ainda não publicou;
• aplicação que precisa ser homologada antes;
• programa que a ferramenta não cobre;
• equipamento que nunca entrou no gerenciamento;
• firmware de firewall, roteador ou impressora, que segue outro processo.

Por isso, conferir o resultado importa tanto quanto mandar instalar. Atualização “enviada” e atualização “instalada” são coisas diferentes.

Indicadores que valem acompanhar

Não existe meta universal, mas estes números mostram se o processo funciona:

• percentual de equipamentos em conformidade, e qual é a definição de conformidade;
• atualizações críticas pendentes;
• tempo entre a publicação de uma correção e a instalação;
• computadores aguardando reinicialização;
• falhas de instalação;
• equipamentos sem comunicação há vários dias;
• sistemas operacionais e programas sem suporte;
• exceções abertas e prazo de cada uma.

O CIS, centro que publica os CIS Controls, recomenda aplicar atualizações do sistema operacional e dos aplicativos de forma automatizada, mensalmente ou com mais frequência.

Perguntas para fazer à sua empresa de TI

1. Vocês têm um inventário atualizado dos nossos computadores?
2. Quais sistemas e programas entram na atualização automática, e quais ficam de fora?
3. Existe grupo piloto antes da distribuição geral?
4. Como as reinicializações são controladas?
5. O que acontece quando uma instalação falha, e como uma exceção é aprovada?
6. Recebo um relatório que mostre o que está em dia e o que está pendente?

Como a Pulso faz

Usamos uma plataforma RMM de mercado nos computadores que gerenciamos. A rotina cobre o sistema operacional e os softwares da Microsoft:

• Verificação diária das atualizações disponíveis, com aplicação semanal.
• Ambiente controlado primeiro: toda atualização passa por um grupo de teste antes de ir para os clientes.
• Reinicialização combinada: o usuário recebe um aviso uma vez por semana, com duas horas de antecedência, no dia definido previamente com cada cliente.
• Exceções globais e por grupo: quando uma atualização causa problema, ela é investigada e bloqueada na política até haver solução.
• Relatório mensal em PDF com a situação do ambiente.

Essa rotina faz parte do suporte de TI especializado e está incluída nos planos de suporte.

Equipamentos fora do gerenciamento, sistemas sem suporte do fabricante e programas de outros fabricantes ficam fora dessa rotina e precisam de um plano próprio.

Um processo, não um botão

Gestão de patches é um ciclo contínuo: inventário, prioridade, instalação, verificação e evidência. Uma plataforma RMM automatiza boa parte dele e aumenta a visibilidade, mas não elimina o risco sozinha. O que reduz a exposição é alguém acompanhando as pendências toda semana.

Fontes

• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
• CIS Controls v8.1, controle 7: gestão contínua de vulnerabilidades (salvaguardas 7.3 e 7.4)
• CISA: catálogo de vulnerabilidades exploradas (KEV)
• Microsoft Learn: plano de implantação e anéis de atualização do Windows

Perguntas frequentes

O RMM atualiza programas de outros fabricantes?

Depende da ferramenta, das integrações disponíveis e do que está no contrato. Algumas plataformas cobrem uma lista de aplicativos de terceiros, outras só o sistema operacional e os produtos de um fabricante. Pergunte à sua empresa de TI exatamente o que entra na rotina automática e como ficam os programas que não entram.

Quem é responsável pelas atualizações em um contrato de suporte de TI?

Quem estiver escrito no contrato. O ideal é que ele diga quais sistemas e programas estão cobertos, com que frequência as atualizações são verificadas e aplicadas, como funcionam as exceções e qual relatório o cliente recebe. Equipamentos fora do gerenciamento e sistemas sem suporte do fabricante costumam ficar fora dessa responsabilidade e precisam de um plano próprio.

Este conteúdo é informativo e não substitui orientação jurídica.

• Gestão de patches
• RMM
• Atualizações
• Suporte de TI
• Vulnerabilidades

Ver todos os artigos