Sécuriser les serveurs
Si les réticences exprimées par les équipes projet et par les responsables de la production
ne sont pas dénuées de fondement, le RSSI peut parfaitement proposer une démarche
prudente permettant de sécuriser les services sans pour autant retarder les projets ni
provoquer les régressions de service tellement redoutées. Nous allons voir comment.
Les nouveaux serveurs
La sécurisation des serveurs nouvellement mis en production est la plus simple. On peut
se permettre de les sécuriser, car ils ne risquent pas de provoquer de régression de
service, étant donné qu’ils ne sont pas encore en production.
Limitation des modules : tous les éditeurs de systèmes d’exploitation ainsi que les
principaux éditeurs de bases de données proposent des options d’installation
minimisées. Au moment de l’installation, l’administrateur sélectionne uniquement les
modules nécessaires en fonction de l’usage auquel le serveur est destiné. Cette
sélection peut naturellement être réalisée de façon interactive, ou bien être
préconfigurée pour être exécutée de façon automatique, à grande échelle.
Masterisation : la masterisation consiste à concevoir un socle sur le modèle duquel
tous les serveurs seront déployés. Si ce socle est sécurisé, tous les serveurs déployés le
seront, du moins au moment de leur installation. Sécuriser le master est donc une
tâche importante qu’il convient de confier à un spécialiste du système à installer.
Comme les options de sécurisation varient d’une version de système à l’autre, il ne
faut pas hésiter à faire appel à un consultant spécialisé qui, d’une part, saura
configurer les bons paramètres pour la sécurisation et, d’autre part, tiendra compte des
contraintes d’exploitation. Parmi les actions de sécurisation, il y a naturellement
l’application de tous les correctifs de sécurité disponibles au moment de l’élaboration
du master.
Affinement : comme nous venons de le voir, le principe de la masterisation consiste à
développer des socles assez fermés du point de vue des fonctionnalités. Au moment
de la mise en production, il reste à ouvrir sélectivement les fonctionnalités et à
positionner les paramètres pour rendre le service opérationnel. Les personnes chargées
de cette tâche doivent donc très bien connaître les actions à réaliser. Nous voyons ici
l’importance de disposer d’expertise en interne ainsi que de modes opératoires
détaillés et à jour. Un travail régulier de vérification et de mise à jour de ces modes
opératoires est indispensable.
Ces trois étapes garantissent que les serveurs nouvellement installés répondent aux
critères de base de la sécurité. Il ne faut pas oublier, cependant, que cette sécurité se doit
d’être maintenue dans la durée. Nous verrons cela plus loin.
Les serveurs déjà en production
Si l’on s’en tient exclusivement à l’appréciation des risques, sécuriser le parc de serveurs
existants devrait être la priorité numéro un du RSSI. Il devrait donc logiquement se
Si les réticences exprimées par les équipes projet et par les responsables de la production
ne sont pas dénuées de fondement, le RSSI peut parfaitement proposer une démarche
prudente permettant de sécuriser les services sans pour autant retarder les projets ni
provoquer les régressions de service tellement redoutées. Nous allons voir comment.
Les nouveaux serveurs
La sécurisation des serveurs nouvellement mis en production est la plus simple. On peut
se permettre de les sécuriser, car ils ne risquent pas de provoquer de régression de
service, étant donné qu’ils ne sont pas encore en production.
Limitation des modules : tous les éditeurs de systèmes d’exploitation ainsi que les
principaux éditeurs de bases de données proposent des options d’installation
minimisées. Au moment de l’installation, l’administrateur sélectionne uniquement les
modules nécessaires en fonction de l’usage auquel le serveur est destiné. Cette
sélection peut naturellement être réalisée de façon interactive, ou bien être
préconfigurée pour être exécutée de façon automatique, à grande échelle.
Masterisation : la masterisation consiste à concevoir un socle sur le modèle duquel
tous les serveurs seront déployés. Si ce socle est sécurisé, tous les serveurs déployés le
seront, du moins au moment de leur installation. Sécuriser le master est donc une
tâche importante qu’il convient de confier à un spécialiste du système à installer.
Comme les options de sécurisation varient d’une version de système à l’autre, il ne
faut pas hésiter à faire appel à un consultant spécialisé qui, d’une part, saura
configurer les bons paramètres pour la sécurisation et, d’autre part, tiendra compte des
contraintes d’exploitation. Parmi les actions de sécurisation, il y a naturellement
l’application de tous les correctifs de sécurité disponibles au moment de l’élaboration
du master.
Affinement : comme nous venons de le voir, le principe de la masterisation consiste à
développer des socles assez fermés du point de vue des fonctionnalités. Au moment
de la mise en production, il reste à ouvrir sélectivement les fonctionnalités et à
positionner les paramètres pour rendre le service opérationnel. Les personnes chargées
de cette tâche doivent donc très bien connaître les actions à réaliser. Nous voyons ici
l’importance de disposer d’expertise en interne ainsi que de modes opératoires
détaillés et à jour. Un travail régulier de vérification et de mise à jour de ces modes
opératoires est indispensable.
Ces trois étapes garantissent que les serveurs nouvellement installés répondent aux
critères de base de la sécurité. Il ne faut pas oublier, cependant, que cette sécurité se doit
d’être maintenue dans la durée. Nous verrons cela plus loin.
Les serveurs déjà en production
Si l’on s’en tient exclusivement à l’appréciation des risques, sécuriser le parc de serveurs
existants devrait être la priorité numéro un du RSSI. Il devrait donc logiquement se