Gestão de patches é uma área de gestão de sistemas que envolve a aquisição, teste e instalação de múltiplos patches, ou alterações de código, para um sistema informático administrado. As tarefas de gestão de patches incluem manter o conhecimento actual dos patches disponíveis, decidir que patches são apropriados para sistemas específicos, assegurar que os patches são instalados correctamente, testar os sistemas após a instalação, e documentar todos os procedimentos associados, tais como configurações específicas necessárias. Vários produtos estão disponíveis para automatizar tarefas de gestão de patches, incluindo o APM da RingMaster Software, o ManageEngine’s Desktop Central e o SolarWinds Patch Manager.

Por que é importante a gestão de patches?

A gestão de patches é importante porque os patches ajudam a manter a saúde e a segurança dos sistemas que estão a ser corrigidos. Além disso, os patches são por vezes utilizados para actualizar o software para que funcione com o hardware mais recente.

Como funciona a gestão de patches?

A gestão de patches funciona de forma diferente dependendo se um patch está a ser aplicado a um sistema autónomo ou se está a ser aplicado a sistemas numa rede corporativa. No caso de um sistema autónomo, o sistema operativo e as aplicações nesse sistema realizarão periodicamente uma verificação automática para ver se existem correcções disponíveis. Se forem encontrados novos patches, os patches serão normalmente descarregados e instalados automaticamente.

A gestão de patches tende a funcionar de forma diferente num ambiente corporativo, porque as organizações geralmente tentam manter a consistência da versão do software nos seus computadores. Como tal, as organizações normalmente realizam uma gestão centralizada de patches em vez de permitirem que cada computador descarregue os seus próprios patches.

A gestão centralizada de patches utiliza um servidor de gestão de patches centralizado que descarrega patches em nome da organização e distribui esses patches para os computadores na rede da organização, de acordo com a política de gestão de patches da organização.

Um servidor de gestão de patches centralizado faz mais do que apenas automatizar a gestão de patches. Também dá à organização um grau de controlo sobre o processo de gestão de patches. Por exemplo, se for determinado que um determinado patch é problemático, então a organização pode configurar a sua política de gestão de patch para evitar que esse patch em particular seja implementado.

Uma outra vantagem de realizar uma gestão centralizada de patch é que, ao fazê-lo, ajuda a conservar a largura de banda da Internet. Faz pouco sentido, numa perspectiva de largura de banda, permitir que todos os computadores de toda a organização descarreguem exactamente o mesmo patch. Em vez disso, o servidor de gestão centralizada de patches pode descarregar o patch e depois distribuí-lo por todos os computadores dentro da organização. Isto significa que o patch só deve ser descarregado uma vez, em vez de se descarregar uma cópia separada para cada computador.

Embora muitas organizações tratem da gestão de patch por conta própria, alguns fornecedores de serviços geridos efectuam a gestão de patch em conjunto com outros serviços de gestão de rede que fornecem aos seus clientes.

Benefícios da gestão de patch

A maior parte das grandes empresas de software lançam patches periodicamente para os seus produtos. Estes patches podem servir qualquer um de três propósitos principais.

Primeiro, os patches são frequentemente utilizados para resolver vulnerabilidades de segurança. Se um fornecedor de software descobre que existe um risco de segurança associado ao seu produto, normalmente emitirá um patch para lidar com esse risco. É importante que as organizações apliquem patches de segurança o mais rapidamente possível, porque os hackers e autores de malware sabem das vulnerabilidades de segurança que um patch é concebido para corrigir, e procuram activamente sistemas não corrigidos.

Uma segunda razão pela qual as empresas de software geralmente lançam patches é para corrigir bugs que tenham sido descobertos no seu software. A aplicação de tais correcções pode melhorar a estabilidade do software, ao mesmo tempo que se livra de problemas incómodos.

Terceiro motivo, as empresas de software lançam ocasionalmente correcções como forma de introduzir novas funcionalidades. As actualizações de funcionalidades estão a tornar-se muito mais comuns do que eram em tempos, como resultado da transição para o licenciamento de software baseado em assinaturas.

Problemas comuns com a gestão de patches

O problema mais comum associado ao processo de gestão de patches é o de um buggy patch. Ocasionalmente, um patch irá introduzir problemas que não existiam anteriormente. Estes problemas podem aparecer no produto que está a ser corrigido, ou os problemas podem manifestar-se noutro local se outro software tiver uma relação de dependência com o software que foi recentemente corrigido.

Porque os patches podem por vezes introduzir problemas num sistema que estava anteriormente a funcionar correctamente, é importante que os administradores testem os patches antes de os implantarem em toda a organização.

Outro problema comum associado à gestão de patches é que os sistemas desconectados podem não receber os patches atempadamente. Se um utilizador móvel raramente se liga à rede corporativa, por exemplo, então o dispositivo desse utilizador pode ficar por longos períodos de tempo sem ser corrigido. Nesses casos, pode ser melhor configurar o dispositivo para gestão autónoma de patches em vez de confiar na gestão centralizada de patches.

Ciclo de vida da gestão de patches

Quando um novo patch é lançado, uma organização deve testar o patch antes de o implementar em toda a organização. O departamento de TI pode inicialmente realizar alguns testes básicos dentro de um ambiente de caixa de areia. Isto impede que quaisquer problemas com o patch tenham impacto nos sistemas de produção.

Se não forem descobertos problemas óbvios durante os testes de sandbox, então o departamento de TI pode realizar um desdobramento piloto. Uma implantação piloto envolve a implantação dos remendos num número limitado de sistemas de produção para verificar se o remendo funciona correctamente num ambiente de produção. Após um período de tempo, o patch é implantado em toda a organização.

Ocasionalmente, o departamento de TI poderá ter de remover um patch que tenha sido aplicado aos sistemas de produção. Isto pode acontecer se os remendos forem considerados como causadores de problemas, mas existem outras razões para a remoção de um remendo. Um patch pode ser removido, por exemplo, se um fornecedor de software lançar um novo patch que não possa ser posto em prática enquanto o patch anterior permanecer no sistema. Neste caso, diz-se que o novo patch substitui o patch anterior.

Exemplos de gestão de patch

Microsoft fornece frequentemente patches aos seus sistemas operativos Windows e a outros produtos tais como o Office 365. Estes patches são normalmente lançados numa base programada, num dia que passou a ser conhecido como Patch Tuesday.

Sistemas independentes dependem do Windows Update para descarregar e implementar automaticamente quaisquer patches disponíveis. No entanto, em ambientes empresariais, é muito mais comum utilizar o Windows Server Update Services para gerir e implementar patches da Microsoft. Os Serviços de Actualização do Servidor Windows, que são vulgarmente referidos como WSUS, estão incluídos no Windows Server e especificamente concebidos para centralizar a gestão de patches. No entanto, existem numerosos produtos de terceiros que também são capazes de descarregar, gerir e implementar patches da Microsoft.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *