Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- A aplicação de patches sem reinicialização no kernel do Linux aplica correções de segurança a um kernel em execução, de modo que a correção não precisa mais aguardar a reinicialização.
- Nesta postagem do blog, analisamos uma equipe de cinco pessoas responsável por cerca de 10.000 sistemas críticos de negociação, sem a necessidade de nenhuma reinicialização obrigatória para a aplicação de patches.
- Os intervalos entre reinicializações dobraram, passando de cerca de seis meses para cerca de um ano, e passaram a ser procedimentos de manutenção opcionais.
- A eliminação da dependência da reinicialização reduziu a coordenação entre equipes e impediu que as correções relacionadas à PCI DSS fossem incluídas no cronograma de manutenção.
Uma plataforma de negociação pode resistir a muitos dias ruins. Uma reinicialização do kernel no meio da execução de uma ordem não é um deles.
Existe uma lacuna entre a disponibilidade de uma correção no kernel e a proteção efetiva de um sistema de produção. A atualização é lançada; em seguida, alguém precisa encontrar um intervalo de tempo, obter a aprovação da mudança, coordenar os responsáveis pelas aplicações e reiniciar a máquina. A aplicação de patches sem reinicialização no kernel do Linux elimina essa lacuna ao aplicar correções de segurança elegíveis ao kernel em execução, de modo que a proteção não depende mais da reinicialização.
Agora, vamos ampliar a escala do problema. Cinco engenheiros. Aproximadamente 10.000 sistemas críticos distribuídos por vários data centers, principalmente baseados em RHEL e, em grande parte, no AlmaLinux. Além disso, há a norma PCI DSS, somada a outras normas de segurança e auditoria que exigem que vulnerabilidades conhecidas sejam corrigidas em um prazo muito mais curto do que uma escala de tempo geológica.
Essa era a situação em uma empresa global de serviços financeiros, onde o tempo de atividade se reflete diretamente na receita e até mesmo pequenas interrupções na execução de ordens afetam os resultados financeiros.
Quando a aplicação de patches no kernel se torna um projeto operacional
A aplicação de patches por meio de reinicializações ocorria aproximadamente a cada seis meses. Não porque alguém achasse que meio ano de exposição fosse aceitável, mas porque essa era a frequência que a coordenação conseguia efetivamente suportar. Planejar um único ciclo podia consumir dias do tempo do líder da equipe antes mesmo que a empresa como um todo fosse envolvida, e cada responsável pelo aplicativo e cada aprovador de mudanças tinha uma opinião diferente sobre quando um sistema poderia ficar fora do ar.
Seis meses, e ainda assim não foi suficiente. As equipes de segurança e conformidade queriam uma correção mais rápida. A equipe de engenharia já estava sobrecarregada com essa frequência. Ambas as situações eram verdadeiras ao mesmo tempo, o que geralmente é sinal de que o problema está no processo, e não nas pessoas que o executam.
A maior parte desse custo nunca aparece na fila de tickets. Ele é destinado ao agendamento de chamadas, ao planejamento de reversão e às verificações de dependências. Nada disso corrige um único CVE adicional.
Os cálculos relativos ao período de manutenção nunca deram certo
Veja a seguir como o líder da equipe descreveu o problema de programação:
“Esses sistemas são essenciais; não dá para desligá-los. Se for preciso desligá-los, só é possível durante determinados intervalos de manutenção. Esses intervalos eram praticamente impossíveis de cumprir porque são muito curtos, e seriam necessárias cerca de 100 pessoas para reiniciar tudo.”
Essa é a equação com a qual toda empresa de alta disponibilidade acaba se deparando. Os prazos ficam cada vez mais curtos à medida que os negócios se tornam globais, a frota continua crescendo e o quadro de funcionários não acompanha esse crescimento.
Com algumas centenas de servidores, dá para resolver tudo à força bruta durante um fim de semana de reinicialização e chamar isso de plano. Com 10.000 sistemas críticos e cinco pessoas, a abordagem à força bruta deixa de ser viável, e o acúmulo de patches se torna uma constante no ambiente. Contratar 100 pessoas para cada CVE do kernel não é uma estratégia.
Se a sua capacidade de reinicialização aumentar junto com a sua frota, as janelas programadas ainda podem funcionar. Caso contrário, a única solução viável é deixar de vincular a correção de vulnerabilidades às reinicializações.
O que a aplicação de patches sem reinicialização mudou para uma equipe de cinco pessoas
Após avaliar várias opções, a organização escolheu o KernelCare da TuxCare e o implantou em aproximadamente 10.000 de seus sistemas mais críticos. Os testes demonstraram uma aplicação confiável e consistente de patches, e a implantação foi gerenciada centralmente por meio do ePortal, permitindo que cinco pessoas mantivessem visibilidade de todo o processo.
O número de reinicializações obrigatórias para aplicação de patches caiu para zero. As reinicializações ainda ocorrem, mas o intervalo entre elas se estendeu de cerca de seis meses para cerca de um ano, e sua finalidade mudou ao longo do tempo. Elas se tornaram eventos de manutenção opcionais, em vez de pré-requisitos para corrigir vulnerabilidades do kernel. A coordenação entre equipes para a aplicação de patches no kernel praticamente desapareceu, assim como os dias de planejamento que costumavam anteceder esse processo.
A forma de distribuição das correções também mudou. Em vez de as correções acumuladas serem aplicadas em um único período restrito, elas são aplicadas continuamente, de modo que os riscos deixam de se acumular em sistemas que estão em operação há muito tempo.
Por que isso é importante para o PCI DSS e as evidências de auditoria
As estruturas de conformidade medem o tempo decorrido. O esforço não é levado em consideração. A norma PCI DSS exige que as correções de segurança para vulnerabilidades críticas e de alto risco sejam instaladas dentro de um prazo definido após o lançamento, e o auditor solicita comprovação de que o prazo foi cumprido, em vez de uma explicação sobre o motivo pelo qual a janela de manutenção sofreu atraso.
Um ciclo de seis meses garante um intervalo entre a disponibilidade de um patch e sua aplicação. Em 10.000 sistemas, esse intervalo é documentado em cada relatório de varredura, trimestre após trimestre. Eliminar a reinicialização do processo permite fechá-lo sem adicionar uma única janela ao calendário.
Quem deve ler isto
Qualquer pessoa que opere um sistema Linux de alta disponibilidade sob pressão de auditoria, com uma equipe menor do que a que, sem dúvida, seria necessária. As plataformas de negociação são o exemplo mais óbvio, mas o mesmo raciocínio se aplica a bancos de dados, cargas de trabalho em cluster, telecomunicações, processamento de pagamentos e qualquer serviço voltado para o cliente em que “basta reiniciar” não seja uma estratégia de segurança.
O estudo de caso aborda por que o ciclo de seis meses se tornou insustentável, o que a equipe levou em consideração ao avaliar a aplicação de patches sem reinicialização e quais foram as mudanças em termos de conformidade e carga de trabalho diária a partir de então, em grande parte nas próprias palavras da organização. É uma leitura curta e mais focada em números do que em adjetivos.
Leia o estudo de caso completo:
Mantendo a segurança dos sistemas de comércio global sem comprometer o tempo de atividade →
