Un premier groupe, assez restreint, se voit appliquer automatiquement les correctifs
de sécurité dès leur mise à disposition par l’éditeur. Il convient de placer dans ce
groupe un panel de postes représentatifs. L’idéal est de sélectionner deux ou trois
postes pour chaque profil métier. Ainsi, si une régression de service est constatée, les
utilisateurs concernés peuvent alerter la production. On peut y ajouter quelques postes
de l’équipe sécurité et de la production. La détection de la régression n’en sera que
plus rapide.
Un second groupe, plus consistant, se voit appliquer les correctifs une semaine après
le premier. Dans le cas où le premier groupe aurait constaté une régression de service,
l’application des correctifs sur ce second groupe serait gelée, le temps de comprendre
la raison de la régression. Il convient de placer dans ce groupe une proportion
relativement réduite, mais non négligeable, de postes de travail.
Un troisième groupe concerne tout le reste du parc. Si aucun problème n’a été
signalé dans les étapes précédentes, il recevra les correctifs une semaine après le
second groupe.
À l’usage, on constate de très rares régressions de service en respectant cette démarche
et, quand il y en a, le mécanisme en plusieurs étapes les bloque efficacement.
Attention, cette approche ne se limite pas uniquement à un projet technique, qui se gère
entre informaticiens. Elle nécessite impérativement la collaboration active des
utilisateurs. Les personnes des deux premiers groupes doivent être informées qu’elles en
font partie. Elles doivent bien comprendre leur rôle et savoir qui prévenir en cas de
problème. En principe, ce sera le service d’assistance qui, à son tour, fera suivre
l’incident à la production et au RSSI.
Il est curieux de constater que, autant la réticence de la production est initialement grande
au début du projet, autant sa confiance est exagérée une fois qu’elle constate que le
processus des correctifs fonctionne correctement. Pourtant sans une vigilance de tous les
instants, le processus de correctifs de sécurité peut perdre très rapidement de son
efficacité sans que personne ne s’en aperçoive, et ce pour des raisons purement
techniques.
Serveur saturé : quelle que soit la solution technique retenue pour diffuser les
correctifs, le serveur chargé de les récupérer chez l’éditeur doit d’abord les stocker en
local. Ce n’est qu’ensuite qu’il peut propager les correctifs. Ainsi, plus le temps passe,
plus le volume contenant les correctifs se remplit, jusqu’à arriver un jour à saturation.
Une fois plein, le serveur ne peut plus charger les nouveaux correctifs. Il cesse donc
de fonctionner. Si personne ne surveille l’activité du serveur, cette panne de correctifs
peut passer tout à fait inaperçue, laissant croire à tort aux équipes que le parc des
postes de travail est à jour.
Groupes mal configurés : une autre erreur courante est la mauvaise intégration des
postes de travail dans le dispositif de mises à jour. Il y a mille et une façons de
déclarer un poste auprès du serveur de mises à jour. L’administrateur peut jouer sur les
groupes AD, ou sur les GPO, ou sur les groupes au niveau du serveur. C’est
généralement sur une combinaison des trois que les postes sont intégrés. Quand on
connaît la complexité des groupes et des GPO dans un domaine, on comprend que des
erreurs soient fréquentes (oublis, erreurs d’assignation de groupe, incompatibilités
de sécurité dès leur mise à disposition par l’éditeur. Il convient de placer dans ce
groupe un panel de postes représentatifs. L’idéal est de sélectionner deux ou trois
postes pour chaque profil métier. Ainsi, si une régression de service est constatée, les
utilisateurs concernés peuvent alerter la production. On peut y ajouter quelques postes
de l’équipe sécurité et de la production. La détection de la régression n’en sera que
plus rapide.
Un second groupe, plus consistant, se voit appliquer les correctifs une semaine après
le premier. Dans le cas où le premier groupe aurait constaté une régression de service,
l’application des correctifs sur ce second groupe serait gelée, le temps de comprendre
la raison de la régression. Il convient de placer dans ce groupe une proportion
relativement réduite, mais non négligeable, de postes de travail.
Un troisième groupe concerne tout le reste du parc. Si aucun problème n’a été
signalé dans les étapes précédentes, il recevra les correctifs une semaine après le
second groupe.
À l’usage, on constate de très rares régressions de service en respectant cette démarche
et, quand il y en a, le mécanisme en plusieurs étapes les bloque efficacement.
Attention, cette approche ne se limite pas uniquement à un projet technique, qui se gère
entre informaticiens. Elle nécessite impérativement la collaboration active des
utilisateurs. Les personnes des deux premiers groupes doivent être informées qu’elles en
font partie. Elles doivent bien comprendre leur rôle et savoir qui prévenir en cas de
problème. En principe, ce sera le service d’assistance qui, à son tour, fera suivre
l’incident à la production et au RSSI.
Il est curieux de constater que, autant la réticence de la production est initialement grande
au début du projet, autant sa confiance est exagérée une fois qu’elle constate que le
processus des correctifs fonctionne correctement. Pourtant sans une vigilance de tous les
instants, le processus de correctifs de sécurité peut perdre très rapidement de son
efficacité sans que personne ne s’en aperçoive, et ce pour des raisons purement
techniques.
Serveur saturé : quelle que soit la solution technique retenue pour diffuser les
correctifs, le serveur chargé de les récupérer chez l’éditeur doit d’abord les stocker en
local. Ce n’est qu’ensuite qu’il peut propager les correctifs. Ainsi, plus le temps passe,
plus le volume contenant les correctifs se remplit, jusqu’à arriver un jour à saturation.
Une fois plein, le serveur ne peut plus charger les nouveaux correctifs. Il cesse donc
de fonctionner. Si personne ne surveille l’activité du serveur, cette panne de correctifs
peut passer tout à fait inaperçue, laissant croire à tort aux équipes que le parc des
postes de travail est à jour.
Groupes mal configurés : une autre erreur courante est la mauvaise intégration des
postes de travail dans le dispositif de mises à jour. Il y a mille et une façons de
déclarer un poste auprès du serveur de mises à jour. L’administrateur peut jouer sur les
groupes AD, ou sur les GPO, ou sur les groupes au niveau du serveur. C’est
généralement sur une combinaison des trois que les postes sont intégrés. Quand on
connaît la complexité des groupes et des GPO dans un domaine, on comprend que des
erreurs soient fréquentes (oublis, erreurs d’assignation de groupe, incompatibilités