L'application des correctifs dans un petit environnement

Dans les services informatiques des grandes entreprises, l'application des correctifs est un processus complexe impliquant un grand nombre de systèmes de test qui reproduisent les systèmes de production, afin que chaque nouveau correctif provenant des éditeurs de systèmes d'exploitation et de logiciels puisse être testé dans un environnement réel pour observer comment il interagit avec les combinaisons matérielles et logicielles présentes dans l'organisation. Dans un monde idéal, chaque service disposerait d'un processus d'application des correctifs géré qui réagirait immédiatement aux correctifs nouvellement publiés, les testerait instantanément et les appliquerait dès qu'ils seraient jugés sûrs et applicables. Mais le monde n'est pas idéal et, dans la vie réelle, nous devons faire avec des ressources limitées : physiques, temporelles et financières.

Les correctifs sont généralement publiés pour quelques raisons clés : la sécurité, la stabilité, la performance et, à l'occasion, pour fournir de nouvelles fonctionnalités. À l'exception de l'ajout de nouvelles fonctionnalités, qui est normalement géré par un processus de publication différent, les correctifs représentent la résolution d'un problème connu. Il ne s'agit pas d'un scénario du type « si ce n'est pas cassé, ne le réparez pas », mais d'un scénario du type « c'est cassé et n'a pas encore complètement lâché », qui exige une attention – le plus tôt sera le mieux. Adopter une approche attentiste face aux correctifs n'est pas judicieux, car l'existence d'un nouveau correctif signifie que les pirates malveillants disposent d'un « correctif » à analyser et que, même si une faille n'existait pas auparavant, elle existera très bientôt. La publication du correctif lui-même peut être l'élément déclencheur du besoin immédiat dudit correctif.

Cet écosystème de correctifs crée un besoin d'adopter une mentalité de « correction rapide ». Les correctifs ne devraient jamais rester en attente ; ils doivent souvent être appliqués dès leur publication et leur test. Attendre pour appliquer un correctif peut signifier fonctionner avec des failles de sécurité critiques ou maintenir des systèmes inutilement peu fiables.

Les petits services informatiques disposent rarement, voire jamais, d'environnements de test, que ce soit pour les serveurs, les équipements réseau ou même les postes de travail. Ce n'est pas idéal mais, de manière réaliste, même si ces environnements étaient disponibles, peu de petits services disposent des ressources humaines informatiques excédentaires nécessaires pour mener ces tests en temps opportun.

Ce n'est pas aussi sombre qu'il n'y paraît. Les tests effectués pour la plupart des correctifs font double emploi avec les tests déjà réalisés par l'éditeur. Les éditeurs ne peuvent pas tester toutes les interactions matérielles et logicielles qui pourraient un jour se produire avec leurs produits, mais ils testent généralement un large éventail de permutations et examinent les domaines où les interactions sont les plus probables. Il est rare qu'un éditeur majeur paralyse son propre logiciel avec de mauvais correctifs. Oui, cela arrive, et disposer de bonnes sauvegardes et de plans de retour arrière est important, mais dans les opérations quotidiennes, l'application des correctifs est un processus relativement sûr qu'il est bien plus important d'effectuer rapidement que d'attendre des occasions qui pourraient ou non se présenter.

Comme toute modification de système, les correctifs s'appliquent au mieux par doses fréquentes et réduites. Si les correctifs sont appliqués rapidement, alors normalement un seul ou quelques correctifs doivent être appliqués en même temps. Pour les systèmes d'exploitation, il se peut que vous ayez encore à gérer plusieurs correctifs à la fois, en particulier si vous n'appliquez les correctifs qu'une fois par semaine, mais vous avez rarement à corriger des dizaines ou des centaines de fichiers à la fois lorsque vous procédez de cette manière. Lorsqu'on procède ainsi, il est nettement plus facile d'évaluer les effets indésirables des correctifs et de revenir en arrière si un processus d'application se passe mal.

Le pire scénario pour une petite entreprise dépourvue d'un flux de travail approprié de test des correctifs est d'attendre avant de les appliquer. Attendre signifie que les systèmes restent sans les soins nécessaires pendant de longues périodes et que, lorsque les correctifs sont finalement appliqués, c'est souvent dans le cadre de processus d'application volumineux et groupés. Appliquer de nombreux correctifs à la fois augmente les chances que quelque chose tourne mal et, lorsque cela se produit, identifier quel(s) correctif(s) est en cause et établir une voie de remédiation peut s'avérer bien plus difficile.

L'application différée des correctifs est un processus qui n'offre que peu ou pas d'avantage, ni à l'informatique ni à l'entreprise, mais qui comporte un risque substantiel pour la sécurité, la stabilité et la performance. Les meilleures pratiques d'application des correctifs dans un petit environnement consistent soit à permettre aux systèmes de s'auto-corriger le plus rapidement possible, soit à planifier un processus d'application régulier, peut-être hebdomadaire, à un moment où l'entreprise est la mieux préparée à ce qu'une application de correctif échoue et à ce qu'une remédiation soit prise en charge. Que vous choisissiez d'appliquer les correctifs automatiquement ou simplement de le faire régulièrement par un processus manuel, appliquez-les souvent et rapidement pour obtenir les meilleurs résultats.