production, passera en revue l’avancement du projet de sécurisation. Ce mode opératoire
permet de s’adapter aux contraintes de la production. Le projet avancera plus vite dans
les périodes creuses et ralentira lorsque des tâches plus urgentes seront nécessaires. Le
tout est que la sécurisation des serveurs ne s’arrête pas.
Une question se pose alors logiquement : par quelles machines commencer la
sécurisation ? L’idée est de traiter en priorité les machines les plus sensibles. Pour cela,
on utilisera deux critères : celui du niveau d’exposition des machines aux risques, et celui
de la sensibilité pour l’entreprise.
Systèmes exposés : sécuriser les systèmes les plus exposés est une priorité car ce sont
les plus susceptibles de subir des attaques depuis l’extérieur. Il est donc important
d’identifier ces serveurs. Attention, il ne faut pas se limiter aux systèmes visibles
depuis Internet, il convient aussi d’intégrer les systèmes auxquels les partenaires
accèdent. En effet, nul ne connaît le niveau de sécurité des partenaires.
Systèmes sensibles : en marge de leur exposition aux menaces extérieures, certains
serveurs sont plus sensibles que d’autres. Par exemple, les serveurs assurant la
téléphonie dans un centre d’appel sont capitaux. Les serveurs de facturation sont un
élément clé pour la trésorerie de l’entreprise. Il va sans dire que les serveurs
directement impliqués dans la production industrielle sont eux aussi essentiels.
Pour réduire les risques de régression de service, il est prudent de n’appliquer que les
correctifs de sécurité jugés critiques par les éditeurs. De plus, l’application de ces
correctifs concernera d’abord les environnements de développement puis de
préproduction. Ce n’est qu’après des tests de non-régression, ou plusieurs semaines de
préproduction sans incident, que ces mêmes correctifs pourront enfin être exécutés sur
les plates-formes de production.
Maintien de la sécurité
La sécurisation des serveurs nouvellement déployés ainsi que celle des serveurs déjà en
production ne sert à rien si aucune action de maintien de la sécurité n’est entreprise.
Cela commence par l’application des correctifs de sécurité. Or, un correctif de sécurité ne
s’applique pas aussi systématiquement sur un service en production que sur le parc de
postes de travail.
Mise à jour périodique des masters : comme cela a été indiqué plus haut, les
masters permettent de déployer rapidement des serveurs, conformément à un modèle
adapté à l’entreprise. Nous avons vu qu’il convient que ces masters soient sécurisés et
disposent (entre autres paramètres) des derniers correctifs de sécurité. Or, la durée de
vie des masters peut être de plusieurs mois, voire de plusieurs années. Si, par exemple,
on installe un serveur sur la base d’un master constitué il y a dix-huit mois, cela veut
dire que le serveur aura un grand retard sur les correctifs de sécurité. Plus le master
sera ancien, plus le risque sera grand. Pour éviter cette situation, il convient de
reconstruire périodiquement les masters en leur appliquant les derniers correctifs en
date. Une mise à jour par semestre, voire par trimestre est souhaitable. Cette pratique
garantit que les nouveaux serveurs installés disposent d’une version raisonnablement à
jour des correctifs de sécurité.
permet de s’adapter aux contraintes de la production. Le projet avancera plus vite dans
les périodes creuses et ralentira lorsque des tâches plus urgentes seront nécessaires. Le
tout est que la sécurisation des serveurs ne s’arrête pas.
Une question se pose alors logiquement : par quelles machines commencer la
sécurisation ? L’idée est de traiter en priorité les machines les plus sensibles. Pour cela,
on utilisera deux critères : celui du niveau d’exposition des machines aux risques, et celui
de la sensibilité pour l’entreprise.
Systèmes exposés : sécuriser les systèmes les plus exposés est une priorité car ce sont
les plus susceptibles de subir des attaques depuis l’extérieur. Il est donc important
d’identifier ces serveurs. Attention, il ne faut pas se limiter aux systèmes visibles
depuis Internet, il convient aussi d’intégrer les systèmes auxquels les partenaires
accèdent. En effet, nul ne connaît le niveau de sécurité des partenaires.
Systèmes sensibles : en marge de leur exposition aux menaces extérieures, certains
serveurs sont plus sensibles que d’autres. Par exemple, les serveurs assurant la
téléphonie dans un centre d’appel sont capitaux. Les serveurs de facturation sont un
élément clé pour la trésorerie de l’entreprise. Il va sans dire que les serveurs
directement impliqués dans la production industrielle sont eux aussi essentiels.
Pour réduire les risques de régression de service, il est prudent de n’appliquer que les
correctifs de sécurité jugés critiques par les éditeurs. De plus, l’application de ces
correctifs concernera d’abord les environnements de développement puis de
préproduction. Ce n’est qu’après des tests de non-régression, ou plusieurs semaines de
préproduction sans incident, que ces mêmes correctifs pourront enfin être exécutés sur
les plates-formes de production.
Maintien de la sécurité
La sécurisation des serveurs nouvellement déployés ainsi que celle des serveurs déjà en
production ne sert à rien si aucune action de maintien de la sécurité n’est entreprise.
Cela commence par l’application des correctifs de sécurité. Or, un correctif de sécurité ne
s’applique pas aussi systématiquement sur un service en production que sur le parc de
postes de travail.
Mise à jour périodique des masters : comme cela a été indiqué plus haut, les
masters permettent de déployer rapidement des serveurs, conformément à un modèle
adapté à l’entreprise. Nous avons vu qu’il convient que ces masters soient sécurisés et
disposent (entre autres paramètres) des derniers correctifs de sécurité. Or, la durée de
vie des masters peut être de plusieurs mois, voire de plusieurs années. Si, par exemple,
on installe un serveur sur la base d’un master constitué il y a dix-huit mois, cela veut
dire que le serveur aura un grand retard sur les correctifs de sécurité. Plus le master
sera ancien, plus le risque sera grand. Pour éviter cette situation, il convient de
reconstruire périodiquement les masters en leur appliquant les derniers correctifs en
date. Une mise à jour par semestre, voire par trimestre est souhaitable. Cette pratique
garantit que les nouveaux serveurs installés disposent d’une version raisonnablement à
jour des correctifs de sécurité.