O processo de gerenciamento de patches: um guia passo a passo

A maioria dos programas de aplicação de patches não falha porque a equipe não conhece as etapas. Eles falham nas lacunas entre elas: o ativo que nunca foi incluído no inventário, o patch que ficou no status “aprovado” por três semanas aguardando uma janela de manutenção ou o relatório de implantação que ninguém revisou porque o painel já mostrava 96% de conformidade.

Um processo sólido de gerenciamento de patches é o que transforma essas transferências precárias em algo repetível. Ele oferece uma sequência a ser seguida, uma maneira de confirmar quando uma etapa está realmente concluída e uma resposta clara quando um auditor perguntar como você decidiu quais patches foram aplicados na última terça-feira.

Este guia apresenta passo a passo todo o ciclo de vida. Você verá o que acontece em cada etapa, quem normalmente é o responsável por ela, onde o processo costuma apresentar falhas e, aproximadamente, quanto tempo cada etapa deve levar em um ambiente que funcione bem. O software RMM da Kaseya gerencia a aplicação de patches em milhões de terminais para MSPs e equipes internas de TI, o que oferece uma visão bastante clara de onde ocorrem os problemas e como deve ser o desempenho ideal em cada etapa do processo.

O que é um processo de gerenciamento de patches?

Se você ainda não está familiarizado com o assunto, comece lendo nosso guia completo“O que é gerenciamento de patches?” e, em seguida, volte aqui. Para todos os demais, o processo é a espinha dorsal operacional por trás da definição. É o ciclo repetível que transforma uma vulnerabilidade ou um lançamento de fornecedor em um terminal corrigido, verificado e documentado.

Você verá que isso é chamado de várias maneiras diferentes na prática. Ciclo de vida do gerenciamento de patches, fluxo de trabalho do gerenciamento de patches, procedimento de gerenciamento de patches ou simplesmente o processo de aplicação de patches. Todos esses termos descrevem a mesma coisa. O número de etapas varia entre quatro e dez, dependendo de quem está escrevendo sobre o assunto, mas a lógica subjacente não muda muito.

Utilizamos sete etapas aqui porque esse é o nível de detalhamento em que cada fase tem um responsável definido e um resultado esperado claro. Se forem menos do que isso, as etapas começam a se confundir. Se forem mais do que isso, você acaba criando distinções que não existem na prática.

Uma coisa que vale a pena destacar antes de entrarmos no assunto: o processo para a aplicação de patches de rotina e programada não é o mesmo que o processo para a aplicação de patches de emergência ou de vulnerabilidades “zero-day”. As etapas podem parecer semelhantes no papel, mas os prazos, as etapas de aprovação e a tolerância ao risco se tornam significativamente mais restritos. Abordaremos ambos, usando o fluxo de rotina como base e destacando as variações de emergência nos pontos mais relevantes.

Fluxo do processo de gerenciamento de patches: 7 etapas principais

Um processo robusto de gerenciamento de patches define uma maneira padronizada de identificar, priorizar, implantar e verificar atualizações sem depender de suposições. Veja a seguir como o processo geralmente se desenrola, desde a descoberta de ativos até a geração de relatórios.

Etapa 1: Inventário e identificação de ativos

Responsável: Normalmente, o administrador de terminais ou de sistemas, com a colaboração da equipe de segurança.

Não é possível aplicar correções no que você não conhece. O primeiro passo é criar e manter um inventário completo, preciso e atualizado de todos os dispositivos, sistemas operacionais, aplicativos e versões de firmware em seu ambiente. Isso inclui servidores, estações de trabalho, laptops, dispositivos móveis, máquinas virtuais, equipamentos de rede, dispositivos de IoT e quaisquer cargas de trabalho na nuvem sob sua gestão.

O ideal não é uma planilha que alguém atualiza trimestralmente. É um inventário atualizado continuamente, construído a partir da detecção automatizada, em que cada ativo é complementado com a lista de componentes de software, a versão do sistema operacional, a hora do último registro e a informação sobre a propriedade. Cada lacuna nesse inventário se torna uma lacuna na sua cobertura de atualizações, e cada lacuna na cobertura acaba aparecendo mais tarde como aquele servidor que ninguém percebeu que estava rodando uma versão do OpenSSL em fim de vida útil.

Modos comuns de falha: dispositivos BYOD que não executam o agente, laptops de prestadores de serviços que se conectam à VPN uma vez por trimestre, o servidor de laboratório que alguém configurou e se esqueceu de registrar e qualquer recurso hospedado em uma assinatura de nuvem de propriedade de uma única equipe.

Estimativa de tempo: O Discovery em si é executado continuamente. Chegar a uma linha de base considerada completa pela primeira vez geralmente leva de uma a quatro semanas, dependendo do tamanho do ambiente e da extensão da TI paralela.

Etapa 2: Monitoramento e identificação de patches

Responsável: Normalmente, essa função é compartilhada entre as equipes de TI e de segurança.

Depois de saber o que você possui, é preciso saber o que está disponível para corrigir isso. Essa etapa envolve o acompanhamento regular dos lançamentos de patches de todos os fornecedores cujo software é executado em seu ambiente, juntamente com os alertas de segurança da CISA, das equipes PSIRT dos fornecedores e de fontes de inteligência sobre ameaças, a fim de identificar vulnerabilidades que possam exigir uma resposta fora da rotina.

Para a Microsoft, a Adobe e a Oracle, esse processo é relativamente estruturado. A “Patch Tuesday” ocorre na segunda terça-feira do mês, os boletins são previsíveis e a maioria das ferramentas de gerenciamento de patches os incorpora automaticamente. O problema surge em todos os outros casos. Navegadores, ferramentas de videoconferência, bibliotecas de tempo de execução, aplicativos de nicho para negócios específicos, firmware de rede e drivers de impressora são lançados em seus próprios ritmos e, muitas vezes, sem alarde. Esse é um dos argumentos mais fortes a favor de uma ferramenta de gerenciamento de patches que lide com a detecção de terceiros de forma nativa, em vez de exigir que sua equipe monitore manualmente centenas de feeds RSS.

Modos comuns de falha: ignorar completamente as versões de terceiros, não levar em conta os alertas fora do ciclo normal que chegam entre as “terças-feiras de atualizações” e tratar os feeds do CVE como a fonte oficial, em vez dos alertas dos fornecedores.

Prazo previsto: Em andamento. Desde o lançamento até a detecção em seu ambiente, você deve medir esse tempo em horas para fornecedores de nível um e em um ou dois dias para todos os demais.

Etapa 3: Avaliação e priorização de riscos

Responsável: Segurança, com contribuição da área de TI quanto ao impacto operacional.

A maioria das equipes tem mais patches disponíveis do que capacidade para testá-los e implementá-los. A priorização é a forma de garantir que os patches mais importantes sejam implementados primeiro.

A abordagem tradicional consistia em classificar por pontuação CVSS e aplicar patches em todas as vulnerabilidades críticas. Essa abordagem ainda tem seu lugar, mas, por si só, é muito genérica. Uma vulnerabilidade com pontuação CVSS 9,8 em um software que não está exposto à internet, não possui exploit conhecido e é executado em três hosts internos é um problema diferente de uma vulnerabilidade com pontuação CVSS 7,5 cujo exploit está ativamente sendo usado na prática contra o seu setor. Uma abordagem baseada em risco leva em consideração a gravidade, mas também a criticidade do ativo, a exposição, a disponibilidade de explorações e o impacto nos negócios.

É aqui que o catálogo de vulnerabilidades exploradas conhecidas da CISA e os feeds de inteligência contra ameaças mostram seu valor. Eles indicam quais vulnerabilidades os invasores estão utilizando, o que é um indicador muito mais preciso do que apenas o CVSS para determinar quais correções devem ser aplicadas primeiro.

O resultado dessa etapa é uma lista priorizada com prazos aproximados. Uma estrutura comum prevê que patches críticos sejam implantados em 48 a 72 horas, os de alto risco em 14 dias, os de médio risco em 30 dias e os de baixo risco em 90 dias. O programa Cyber Essentials, no Reino Unido, exige que patches para vulnerabilidades com pontuação igual ou superior a 7,0 sejam implantados em 14 dias, o que se tornou uma referência útil para organizações que buscam esse nível de maturidade em conformidade. Sejam quais forem os prazos definidos, documente-os em sua política de gerenciamento de patches para que o restante do processo os adote.

Modos comuns de falha: basear-se exclusivamente no CVSS, ignorar dados sobre a explorabilidade, tratar todas as correções “críticas” como igualmente críticas, o problema inverso de considerar os prazos como datas-limite em vez de metas e esperar até o 13º dia para fazer a implantação.

Estimativa de tempo: horas por ciclo de correção, caso suas ferramentas façam o trabalho pesado. Um dia inteiro ou mais, caso sua equipe esteja avaliando manualmente cada aviso.

Etapa 4: Teste de contato

Responsável: Operações de TI, com contribuições dos responsáveis pelas aplicações no caso de patches de alto risco.

Os testes são a etapa que é a primeira a ser cortada quando uma equipe está sob pressão, e é a etapa que causa mais arrependimento quando é ignorada. O objetivo principal é detectar o patch que causa falhas antes que ele chegue à produção.

Equipes experientes utilizam anéis de implantação ou implementações em etapas. Uma correção é aplicada primeiro a uma amostra representativa de máquinas de teste, incluindo, idealmente, uma combinação de modelos de hardware, versões de sistema operacional e aplicativos essenciais. Após 24 a 72 horas de operação sem problemas, ela passa para um grupo piloto mais amplo. Somente então é aplicada a todo o ambiente de produção. O número exato de anéis é menos importante do que o princípio: em nenhum momento uma única implantação deve atingir todos os terminais de uma só vez.

Para correções de rotina, a fase de testes geralmente dura de 24 a 72 horas. Para correções de emergência ou de dia zero, é possível reduzir esse tempo a algumas horas de testes preliminares em um pequeno grupo antes da implantação em larga escala, aceitando o risco maior em troca de fechar a janela de exposição mais rapidamente. Essa escolha deve ser uma decisão deliberada, não a padrão.

Modos comuns de falha: ignorar completamente os testes em ambientes de pequena escala, realizar testes apenas em hardware que não representa o ambiente de produção, declarar um patch como “testado” após um único host ter funcionado por 30 minutos e não ter um plano de reversão caso algo dê errado.

Prazo estimado: 24 a 72 horas para correções padrão; duas a doze horas para emergências, dependendo da tolerância ao risco.

Etapa 5: Implantação

Responsável: Operações de TI

A implantação é onde tudo se concretiza. As correções são transferidas do ambiente de teste para o de produção de acordo com um cronograma definido e dentro das janelas de manutenção acordadas com a empresa.

Essa etapa apresenta mais pontos de falha do que qualquer outra no processo, principalmente porque é nela que o caótico mundo real entra em cena. Laptops que não estão conectados à rede quando a implantação é executada. Usuários finais que ficam adiando as reinicializações. Servidores que exigem um sequenciamento cuidadoso devido a dependências. Patches que exigem que um serviço específico seja interrompido primeiro. Dispositivos fora da rede que não se conectam há semanas.

Um RMM bem configurado realiza a maior parte do trabalho aqui de forma invisível. Ele aplica as correções de acordo com a política, tenta novamente quando os computadores voltam a ficar online, gerencia as reinicializações dentro dos intervalos acordados e destaca as exceções para que sejam analisadas manualmente. O que você espera de suas ferramentas nesta fase são altas taxas de sucesso na implantação, sem a necessidade de acompanhamento manual, além de visibilidade sobre os dispositivos que não receberam a correção na primeira tentativa.

Os intervalos de manutenção são mais importantes do que as pessoas imaginam. Uma correção que exija a reinicialização de uma estação de trabalho clínica no meio de um turno hospitalar acabará sendo adiada, o que significa que a correção não será realmente aplicada, mesmo que seu painel de controle indique o contrário. Alinhar esses intervalos com a forma como a instituição realmente opera é o que diferencia os programas de aplicação de correções que apresentam bons resultados dos que realmente reduzem os riscos.

Modos comuns de falha: supor que “implantado” signifique que o patch está instalado, quando na verdade significa apenas que o pacote foi enviado; ignorar a grande quantidade de dispositivos fora da rede ou não compatíveis; realizar a implantação sem janelas de manutenção coordenadas; e não ter um plano de reversão caso a implantação cause falhas na produção.

Estimativa de tempo: de alguns minutos a algumas horas por máquina para a implantação técnica em si, mas o tempo total necessário para a cobertura completa do parque de equipamentos durante um ciclo de atualização de rotina é normalmente de uma a duas semanas, levando em conta dispositivos fora da rede, reinicializações adiadas e tratamento de exceções.

Etapa 6: Verificação

Responsável: Operações de TI, com auditoria realizada pela equipe de segurança.

A verificação é a etapa em que a maioria das equipes sabe que precisa melhorar. O objetivo é confirmar, depois que tudo se acalmar, que cada patch foi instalado em cada dispositivo de destino e que a vulnerabilidade subjacente foi corrigida.

Há dois aspectos a serem considerados aqui. Primeiro: a instalação do patch foi bem-sucedida? A maioria das ferramentas de gerenciamento de patches fornece essa informação, embora a resposta muitas vezes esconda uma longa lista de estados como “reinicialização pendente” ou “adiado”, que parecem estar tudo bem, mas não estão. Segundo: a vulnerabilidade foi realmente corrigida? Uma verificação separada de vulnerabilidades após a aplicação do patch identifica os casos em que o patch foi instalado, mas não corrigiu totalmente a vulnerabilidade, ou em que uma vulnerabilidade relacionada permanece porque era necessário um patch diferente.

A discrepância entre a “taxa de sucesso na implantação” relatada pela sua ferramenta de aplicação de patches e a “taxa de correção de vulnerabilidades” relatada pelo seu scanner costuma ser o ponto em que se concentram as constatações de auditoria. Uma equipe que relata 98% de conformidade com os patches, mas apenas 85% de correção de vulnerabilidades, apresenta uma lacuna no processo, e não um problema com a ferramenta.

Modos comuns de falha: confiar nas métricas de sucesso da implantação como prova de correção, não realizar uma verificação pós-implantação e nunca investigar os casos residuais de implantações malsucedidas.

Tempo estimado: de 24 a 48 horas após a implantação para que a verificação pós-atualização seja executada e gere dados válidos.

Etapa 7: Relatórios e documentação

Responsável: Operações de TI, frequentemente em conjunto com as áreas de segurança e conformidade.

O ciclo não termina quando as correções são verificadas. Ele termina quando a atividade é documentada de forma a comprovar a devida diligência aos auditores, demonstrar tendências à liderança e servir de base para o aprimoramento do próximo ciclo.

Como deve ser uma boa documentação: um registro por ciclo de atualização mostrando o que foi lançado, o que foi priorizado, o que foi implantado, o que falhou e por quê, quais exceções foram concedidas e a quais ativos. Métricas de tempo de aplicação de atualizações por nível de gravidade. Porcentagens de conformidade com as atualizações por cliente, por departamento ou por classe de ativo. Uma trilha de auditoria clara que um revisor externo possa seguir para verificar o histórico de atualizações de qualquer terminal específico.

É também aí que você encontra suas oportunidades de melhoria. Se 30% dos seus patches críticos ficam fora do prazo de 14 dias, a pergunta a ser respondida não é “como podemos fazer a implantação mais rapidamente?”, mas “em qual das seis etapas anteriores o tempo está sendo gasto?”. A resposta é quase sempre a etapa três (a priorização é muito lenta) ou a etapa cinco (a implantação tem muitas exceções). A documentação é o que torna esse diagnóstico possível.

Modos comuns de falha: documentação tratada como algo secundário; painéis que relatam a implantação sem contexto; ausência de ciclo de revisão; e falta de ligação entre métricas e melhorias nos processos.

Estimativa de tempo: Reunião mensal de revisão, além do registro contínuo de métricas. A geração dos relatórios em si deve ser automatizada; o que leva tempo é a revisão humana e as mudanças no processo decorrentes disso.

Como os patches de emergência alteram o processo

Tudo o que foi descrito acima refere-se ao fluxo de trabalho rotineiro de aplicação de patches. Quando surge uma vulnerabilidade do tipo “zero-day” ou que está sendo ativamente explorada, esse fluxo se torna mais compacto. As mesmas sete etapas continuam válidas, mas o prazo passa de semanas para horas.

Em um ciclo de correções de emergência, a identificação ocorre poucas horas após o aviso; a priorização é basicamente decidida por outros (se for crítica, se estiver sendo explorada, ela é lançada); os testes se resumem a um rápido teste de verificação em um pequeno ambiente de teste; e a implantação é realizada em larga escala, com a expectativa de que algumas falhas sejam preferíveis à exposição contínua. A verificação e a documentação são reforçadas, pois haverá uma discussão sobre a auditoria.

O risco na resposta a emergências geralmente não é agir com muita rapidez. É não ter um plano, de modo que a equipe improvisa sob pressão e ignora as etapas importantes. Um processo documentado de aplicação de patches de emergência, incluindo um responsável designado pela tomada de decisões, uma derrogação pré-aprovada para o controle normal de mudanças e um caminho de reversão testado, é o que torna a aplicação rápida de patches segura.

Quando o processo de aplicação de patches varia de acordo com o ambiente

Servidores, terminais, aplicativos de terceiros e cargas de trabalho na nuvem utilizam todos a mesma estrutura básica de sete etapas, mas com detalhes significativamente diferentes.

No caso dos servidores, o gráfico de dependências é mais importante. Aplicar uma correção em um servidor de banco de dados na sequência errada em relação aos servidores de aplicativos que dependem dele pode resultar em horas de interrupção do serviço. As janelas de manutenção são mais restritas, o controle de mudanças é mais rigoroso e o planejamento de reversão é imprescindível. O tempo necessário para aplicar correções em vulnerabilidades não críticas de servidores costuma ser maior do que para terminais, e isso é adequado.

No caso dos terminais, o problema está na “cauda longa”. Laptops que viajam, dispositivos que adiam a reinicialização, usuários que desligam o computador em vez de reiniciá-lo. A aplicação de patches nos terminais exige um gerenciamento confiável dos dispositivos fora da rede e uma maneira de lidar com os inevitáveis 5% a 10% de máquinas que ficam de fora de um determinado ciclo de patches.

No caso de aplicativos de terceiros, o problema está no volume. Um ambiente típico conta com dezenas de aplicativos de terceiros, cada um com seu próprio cronograma de lançamento, e uma parcela significativa das violações de segurança tem origem em um aplicativo de terceiros sem patch, e não em um sistema operacional sem patch. Esse aspecto é tão relevante que decidimos abordá-lo separadamente. Consulte nosso guia dedicado ao gerenciamento de patches de aplicativos de terceiros para obter detalhes operacionais.

Para cargas de trabalho na nuvem, a imutabilidade muda completamente o jogo. Em um ambiente de nuvem adequadamente projetado, não se aplica patches a uma instância em execução; em vez disso, substitui-se essa instância por uma nova, criada a partir de uma imagem atualizada. O processo de sete etapas ainda se aplica, mas a quinta etapa se assemelha mais à criação de imagens e à substituição de instâncias do que à instalação de software. Os ambientes híbridos acabam executando os dois padrões simultaneamente, e é aí que reside a maior parte da complexidade operacional.

Onde o fluxo do processo costuma apresentar falhas

Alguns padrões se repetem constantemente em ambientes onde o programa de aplicação de patches não está funcionando como deveria.

O primeiro é um inventário incompleto. Se a primeira etapa for falha, todas as etapas subsequentes herdam essa lacuna. Os hosts que você não conhece não recebem as atualizações de segurança e, muitas vezes, são justamente esses que os invasores encontram primeiro, pois são mal mantidos — exatamente pela mesma razão pela qual não constam no inventário.

O segundo é a lacuna entre o teste e a implantação. Os patches são testados, recebem aprovação e, em seguida, ficam aguardando uma janela de manutenção que a empresa vive adiando. Duas semanas depois, o patch ainda não está em produção e a urgência inicial já diminuiu. A solução, nesse caso, geralmente é uma ligação mais estreita entre a aprovação e a implantação, além de janelas de manutenção menos frequentes e mais confiáveis.

O terceiro é a “cauda longa” dos dispositivos não conformes. O painel de controle indica 95%. Os 5% restantes são sempre os mesmos 5% a cada ciclo e são quase sempre os 5% mais importantes. Os laptops dos executivos, os servidores que ninguém quer mexer, o ambiente de laboratório com suas próprias regras. Um programa maduro torna visível essa “cauda longa”, identifica os responsáveis por cada exceção e trabalha para resolvê-la, em vez de ignorá-la.

A quarta é a verificação baseada exclusivamente no status de implantação. A ferramenta indica sucesso, a equipe segue em frente, mas a varredura de vulnerabilidades realizada três semanas depois revela que 8% do ambiente supostamente corrigido ainda está vulnerável. Para eliminar essa lacuna, é preciso tratar os resultados da varredura de vulnerabilidades como a fonte de referência para a correção, e não o relatório de implantação da ferramenta de correção.

A combinação desses modos de falha é o motivo pelo qual as organizações levaram, em média, 209 dias para corrigir as 17 vulnerabilidades em dispositivos de borda rastreadas pela Verizon em seu DBIR 2025, enquanto um invasor levou apenas cinco dias para explorá-las. O problema está nos processos, não na falta de conscientização.

Como as ferramentas modernas da Kaseya transformam o processo

A aplicação manual de patches em qualquer escala razoável não funciona. O volume de lançamentos, a diversidade de plataformas e a velocidade com que as vulnerabilidades são exploradas já ultrapassaram em muito o que uma equipe consegue acompanhar usando planilhas e implantações individuais.

O que uma boa infraestrutura de ferramentas faz é reunir as sete etapas em um fluxo de trabalho automatizado e coerente, com a participação humana nos pontos de decisão. A descoberta de ativos ocorre continuamente. A identificação de patches acontece poucas horas após o lançamento pelo fornecedor. A priorização pode ser orientada por políticas, com patches críticos aprovados automaticamente para anéis de emergência. Os testes são executados em anéis de implantação definidos, sem intervenção manual. A implantação rastreia dispositivos fora da rede e gerencia reinicializações dentro dos intervalos acordados. A verificação fornece feedback para as varreduras de vulnerabilidades. Os relatórios são gerados automaticamente.

Esse é o modelo operacional por trás do gerenciamento automatizado de patches, que hoje é o padrão para qualquer ambiente que leve a sério a aplicação de patches em grande escala. O processo de sete etapas descrito acima é o que está por trás da automação; a automação é o que torna esse processo sustentável.

O software de gerenciamento de patches da Kaseya cuida desse fluxo de trabalho para equipes de TI e MSPs em diversos sistemas operacionais e mais de mil aplicativos de terceiros, com implantação baseada em políticas, anéis de implantação, gerenciamento de dispositivos fora da rede e relatórios de conformidade de patches em uma única solução. O Datto RMM, parte da família Kaseya RMM, é a opção nativa da nuvem para equipes que desejam a mesma capacidade de aplicação de patches sem precisar gerenciar a infraestrutura subjacente.

O processo é mais importante do que a ferramenta. Mas, uma vez que o processo esteja bem definido, é a ferramenta certa que faz a diferença entre um programa que funciona no papel e um que realmente mantém o parque de equipamentos atualizado no ritmo que a empresa precisa. A partir daí, o próximo passo é passar do processo para o programa: consulte nosso guia complementar sobre as melhores práticas de gerenciamento de patches para conhecer os princípios que diferenciam um programa de patches que funciona de um programa excelente.