coup d’œil sur la console d’administration est souvent édifiant. Lorsque l’on compare le
nombre de postes déclarés comme protégés par l’antivirus avec le nombre total de postes
du parc, on constate souvent une différence. Il y a toujours plus de postes dans le parc
que de postes déclarés comme protégés par l’antivirus. Selon le niveau de maturité des
SI, cette différence peut atteindre 40 %. Cela revient à dire qu’alors qu’on se croit
parfaitement protégé par l’antivirus, seuls 60 % du parc le sont réellement.
Comment se fait-il qu’un nombre non négligeable de machines ne soient pas
correctement protégées par l’antivirus ? Les causes sont multiples.
Agents mal déployés : les antivirus sont presque toujours intégrés aux masters des
postes de travail et des serveurs Windows. Cela permet dès l’installation de disposer
d’un antivirus correctement installé et opérationnel. Pourtant, une erreur est souvent
commise dans ce type de déploiement. Chaque agent installé dispose d’un numéro qui
lui est propre et qui identifie de façon certaine la machine protégée auprès de la
console d’administration (bien que le fonctionnement varie d’un éditeur à l’autre, le
principe reste partout le même). Ceci permet au serveur central de pousser les
politiques et les bases de signatures de façon très ciblée, ainsi que de lancer des
actions sur tel ou tel poste. Le problème est que, si aucune précaution n’est prise au
moment de la constitution du master, cet identifiant censé être unique est répliqué sur
tous les postes et tous les serveurs installés par le master. Aussi, même si l’antivirus
est déployé sur toutes les machines, les agents partagent tous le même identifiant
(celui du master). Concrètement, bien que l’antivirus soit déployé partout, la console
d’administration ne voit qu’une seule machine (puisqu’il n’y a qu’un seul identifiant).
Agents mal installés : un problème similaire au précédent est la mauvaise installation
de l’antivirus sur le poste ou le serveur. Les paramètres sont mal configurés, si bien
que l’agent n’arrive pas à joindre le serveur pivot le plus proche, censé lui envoyer les
bases de signatures et les instructions. Il arrive aussi que des postes de travail mal
installés cherchent à joindre un serveur pivot situé dans un autre site, non joignable au
niveau du réseau. Bien d’autres cas d’erreurs de configuration sont possibles.
Agents anciens : comme tous les éditeurs de logiciels, les éditeurs d’antivirus mettent
régulièrement à jour leurs infrastructures. Il est donc souvent nécessaire de mettre à
jour, soit la console d’administration, soit les serveurs pivots, soit les agents distribués
sur le parc. Les mises à jour mineures ne posent généralement pas de problème, mais
lorsqu’une mise à jour majeure arrive, notamment concernant les agents distribués, les
problèmes commencent. En effet, la mise à jour des agents est loin d’être anodine et
doit être menée en mode projet. Force est de constater que, très souvent, ces projets ne
sont pas suivis avec rigueur jusqu’au bout. Ainsi, on se retrouve trop souvent avec un
parc disposant d’un reliquat important d’agents non à jour. Or, au bout d’un certain
temps, les anciens agents ne sont plus pris en compte par la console centrale
d’administration. Les postes correspondants ne sont donc plus protégés. On se
retrouve au final avec un parc partiellement sécurisé.
Agents désactivés : lorsque l’on inspecte de façon détaillée l’état des agents, on
constate que certains de ces derniers sont désactivés. Ils sont bien présents sur le poste
de travail ou sur le serveur, mais ils ne sont pas opérationnels. Dans cet état, autant
dire qu’ils ne servent à rien. Les raisons de ces désactivations sont très variées. Elles
vont de la désactivation ponctuelle suite à une action d’administration, à la
nombre de postes déclarés comme protégés par l’antivirus avec le nombre total de postes
du parc, on constate souvent une différence. Il y a toujours plus de postes dans le parc
que de postes déclarés comme protégés par l’antivirus. Selon le niveau de maturité des
SI, cette différence peut atteindre 40 %. Cela revient à dire qu’alors qu’on se croit
parfaitement protégé par l’antivirus, seuls 60 % du parc le sont réellement.
Comment se fait-il qu’un nombre non négligeable de machines ne soient pas
correctement protégées par l’antivirus ? Les causes sont multiples.
Agents mal déployés : les antivirus sont presque toujours intégrés aux masters des
postes de travail et des serveurs Windows. Cela permet dès l’installation de disposer
d’un antivirus correctement installé et opérationnel. Pourtant, une erreur est souvent
commise dans ce type de déploiement. Chaque agent installé dispose d’un numéro qui
lui est propre et qui identifie de façon certaine la machine protégée auprès de la
console d’administration (bien que le fonctionnement varie d’un éditeur à l’autre, le
principe reste partout le même). Ceci permet au serveur central de pousser les
politiques et les bases de signatures de façon très ciblée, ainsi que de lancer des
actions sur tel ou tel poste. Le problème est que, si aucune précaution n’est prise au
moment de la constitution du master, cet identifiant censé être unique est répliqué sur
tous les postes et tous les serveurs installés par le master. Aussi, même si l’antivirus
est déployé sur toutes les machines, les agents partagent tous le même identifiant
(celui du master). Concrètement, bien que l’antivirus soit déployé partout, la console
d’administration ne voit qu’une seule machine (puisqu’il n’y a qu’un seul identifiant).
Agents mal installés : un problème similaire au précédent est la mauvaise installation
de l’antivirus sur le poste ou le serveur. Les paramètres sont mal configurés, si bien
que l’agent n’arrive pas à joindre le serveur pivot le plus proche, censé lui envoyer les
bases de signatures et les instructions. Il arrive aussi que des postes de travail mal
installés cherchent à joindre un serveur pivot situé dans un autre site, non joignable au
niveau du réseau. Bien d’autres cas d’erreurs de configuration sont possibles.
Agents anciens : comme tous les éditeurs de logiciels, les éditeurs d’antivirus mettent
régulièrement à jour leurs infrastructures. Il est donc souvent nécessaire de mettre à
jour, soit la console d’administration, soit les serveurs pivots, soit les agents distribués
sur le parc. Les mises à jour mineures ne posent généralement pas de problème, mais
lorsqu’une mise à jour majeure arrive, notamment concernant les agents distribués, les
problèmes commencent. En effet, la mise à jour des agents est loin d’être anodine et
doit être menée en mode projet. Force est de constater que, très souvent, ces projets ne
sont pas suivis avec rigueur jusqu’au bout. Ainsi, on se retrouve trop souvent avec un
parc disposant d’un reliquat important d’agents non à jour. Or, au bout d’un certain
temps, les anciens agents ne sont plus pris en compte par la console centrale
d’administration. Les postes correspondants ne sont donc plus protégés. On se
retrouve au final avec un parc partiellement sécurisé.
Agents désactivés : lorsque l’on inspecte de façon détaillée l’état des agents, on
constate que certains de ces derniers sont désactivés. Ils sont bien présents sur le poste
de travail ou sur le serveur, mais ils ne sont pas opérationnels. Dans cet état, autant
dire qu’ils ne servent à rien. Les raisons de ces désactivations sont très variées. Elles
vont de la désactivation ponctuelle suite à une action d’administration, à la