A maioria dos programas de aplicação de patches não fracassa porque a equipe não conhece as etapas. Eles fracassam 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 à espera de 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 transições instáveis 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 ocorre em cada etapa, quem geralmente é o responsável por ela, onde o processo costuma falhar e, aproximadamente, quanto tempo cada etapa deve levar em um ambiente que funciona 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 o processo dá errado 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 depois volte aqui. Para todos os demais, o processo é a espinha dorsal operacional por trás da definição. Trata-se do ciclo repetitivo que transforma uma vulnerabilidade ou um lançamento de um fornecedor em um terminal corrigido, verificado e documentado.
Você verá que isso recebe vários nomes diferentes na prática. Ciclo de vida da gestão de patches, fluxo de trabalho da gestão de patches, procedimento de gestão de patches ou simplesmente o processo de aplicação de patches. Todos 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 concreto. 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 de aplicação de patches de rotina e programados não é o mesmo que o processo de aplicação de patches de emergência ou de vulnerabilidades de dia zero. As etapas podem parecer semelhantes no papel, mas os prazos, as etapas de aprovação e a tolerância ao risco são 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, implementar e verificar atualizações sem depender de suposições. Veja a seguir como o processo geralmente se desenrola, desde a identificação 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 corrigir o que não se 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 do seu ambiente. Isso inclui servidores, estações de trabalho, laptops, dispositivos móveis, máquinas virtuais, equipamentos de rede, dispositivos IoT e quaisquer cargas de trabalho em 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 de uma detecção automatizada, em que cada ativo é complementado com a lista de componentes de software, a versão do sistema operacional, a hora da última verificação 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 se revelando mais tarde como aquele servidor que ninguém percebeu que estava rodando uma versão do OpenSSL em fim de vida.
Modos de falha comuns: 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.
Previsão 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 quais recursos estão disponíveis para corrigir os problemas. Essa etapa envolve o acompanhamento regular dos lançamentos de patches de todos os fornecedores cujo software é executado em seu ambiente, bem como dos 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 do ciclo normal.
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 importa automaticamente. O problema surge em todos os outros casos. Navegadores, ferramentas de videoconferência, bibliotecas de tempo de execução, aplicativos de nicho para linhas de negócios, 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 de falha comuns: ignorar completamente as versões de software 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 de CVE como fonte oficial, em vez dos alertas dos fornecedores.
Prazo previsto: contínuo. Desde o lançamento até a detecção no seu ambiente, você deve avaliar esse prazo em horas para fornecedores de primeira linha e em um ou dois dias para todos os demais.
Etapa 3: Avaliação de riscos e definição de prioridades
Responsável: Segurança, com a colaboração da equipe de TI quanto ao impacto operacional.
A maioria das equipes tem mais patches disponíveis do que capacidade para testar e implementar. A priorização é a forma de garantir que os patches mais importantes sejam implementados primeiro.
A abordagem tradicional consistia em classificar as vulnerabilidades pela pontuação CVSS e aplicar patches em todas as que fossem críticas. Essa abordagem ainda tem sua utilidade, mas, por si só, é pouco eficaz. Uma vulnerabilidade com pontuação CVSS 9,8 em um software que não está exposto à Internet, não possui exploits conhecidos e é executado em três hosts internos é um problema diferente de uma vulnerabilidade com pontuação CVSS 7,5 cujo exploit está ativo e sendo usado na prática contra o seu setor. Uma abordagem baseada em risco leva em conta a gravidade, mas também a criticidade do ativo, a exposição, a disponibilidade de exploits e o impacto nos negócios.
É aqui que o catálogo de vulnerabilidades exploradas 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 corrigir primeiro do que apenas o CVSS.
O resultado desta etapa é uma lista priorizada com prazos aproximados. Um modelo comum prevê que as correções críticas sejam implementadas em 48 a 72 horas, as de alto risco em 14 dias, as de risco médio em 30 dias e as de baixo risco em 90 dias. O programa Cyber Essentials, no Reino Unido, exige que as correções para vulnerabilidades com pontuação igual ou superior a 7,0 sejam implementadas em 14 dias, o que se tornou uma referência útil para organizações que buscam atingir esse nível de maturidade em conformidade. Seja qual for o prazo que você definir, documente-o em sua política de gerenciamento de patches para que o restante do processo o adote.
Modos comuns de falha: basear-se exclusivamente no CVSS, ignorar os dados de vulnerabilidade, 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 implementar a correção.
Estimativa de tempo: horas por ciclo de correção, caso suas ferramentas realizem 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 a colaboração dos responsáveis pelas aplicações no caso de correções 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 a correção que causa falhas antes que ela 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 variedade de modelos de hardware, versões de sistema operacional e aplicativos essenciais. Após 24 a 72 horas de funcionamento sem problemas, ela é transferida para um grupo piloto mais amplo. Só 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. No caso de 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 implementaçã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, e não a opção padrão.
Modos comuns de falha: ignorar completamente os testes em ambientes de pequena escala, realizar testes apenas em hardware que não reflete 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 previsto: de 24 a 72 horas para correções padrão e de 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.
Esta etapa apresenta mais pontos de falha do que qualquer outra no processo, principalmente porque é aqui que o complicado mundo real entra em cena. Laptops que não estão conectados à rede quando a implantação é executada. Usuários finais que adiam constantemente a reinicialização. Servidores que exigem uma sequência cuidadosa 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 intervenção 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 se imagina. Uma correção que exija a reinicialização de uma estação de trabalho clínica no meio de um turno hospitalar provavelmente será 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 distingue os programas de atualização 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; no entanto, o tempo total necessário para cobrir todo o 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 o tratamento de exceções.
Etapa 6: Verificação
Responsável: Operações de TI, com auditoria 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, se cada correção foi instalada em cada dispositivo de destino e se a vulnerabilidade subjacente foi corrigida.
Há dois aspectos a considerar aqui. Primeiro: a instalação da correção foi bem-sucedida? A maioria das ferramentas de gerenciamento de correções fornece essa informação, embora a resposta muitas vezes esconda uma série de estados como “reinicialização pendente” ou “adiado”, que parecem estar em ordem, mas não estão. Segundo: a vulnerabilidade foi realmente corrigida? Uma verificação de vulnerabilidades realizada separadamente após a aplicação da correção identifica os casos em que a correção foi instalada, mas não corrigiu totalmente o problema, ou em que uma vulnerabilidade relacionada permanece porque era necessária uma correção 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 é, muitas vezes, o ponto onde 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 falha 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 de falha que não são detectados imediatamente.
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 melhorar o próximo ciclo.
Como deve ser uma boa documentação: um registro por ciclo de atualização indicando 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 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 aqui 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 apresenta muitas exceções). É a documentaçã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, falta de ligação entre métricas e melhorias nos processos.
Tempo estimado: 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 as correções 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 de dia zero ou que está sendo explorada ativamente, esse fluxo se torna mais ágil. As mesmas sete etapas continuam valendo, 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 uma rápida verificação preliminar em um pequeno grupo, e a implantação é amplamente executada com a expectativa de que algumas falhas são 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 demasiada rapidez. É não ter um plano, de modo que a equipe acaba improvisando sob pressão e ignorando as etapas essenciais. 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 procedimento 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 correções 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 corrigir vulnerabilidades não críticas em servidores costuma ser maior do que em 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 preferem desligar 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 atualizações.
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 específico sobre gerenciamento de patches de terceiros para obter detalhes operacionais.
Para cargas de trabalho em nuvem, a imutabilidade muda completamente o jogo. Em um ambiente de nuvem bem 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 continua válido, 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 em paralelo, e é aí que reside a maior parte da complexidade operacional.
Onde o fluxo do processo costuma falhar
Alguns padrões se repetem constantemente em ambientes onde o programa de atualização não está funcionando como deveria.
O primeiro problema é um inventário incompleto. Se a primeira etapa for falha, todas as etapas seguintes 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 é o intervalo entre os testes e a implantação. As correções são testadas, aprovadas e, em seguida, ficam à espera de uma janela de manutenção que a empresa não para de adiar. Duas semanas depois, a correção ainda não está em produção e a urgência inicial já se dissipou. A solução, nesse caso, geralmente consiste em uma ligação mais estreita entre a aprovação e a implantação, além de janelas de manutenção menos frequentes, mas mais confiáveis.
O terceiro aspecto é a longa cauda de 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 essa longa cauda visível, 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 análise de vulnerabilidades realizada três semanas depois revela que 8% do ambiente supostamente corrigido ainda está vulnerável. Para eliminar essa lacuna, é preciso considerar os resultados da análise 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 os invasores levaram 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 rapidez com que as vulnerabilidades são exploradas já ultrapassaram em muito o que uma equipe consegue acompanhar usando planilhas e implantações individuais.
Uma boa infraestrutura de ferramentas consolida essas 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 de forma contínua. 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 os 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.
Este é 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 o torna 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, oferecendo 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 atualizações para conhecer os princípios que distinguem um programa de atualizações funcional de um excelente.
