2014-01-23
Thomas Martin
Contenu :
Voici une réflexion concernant les différents niveaux de sécurisation d'un service internet hébergé sur un unique serveur dédié.
Je traite ici de sécurisation au sens de maintien de la disponibilité du service et de tolérance aux pannes, et non de la capacité de résistance à des attaques malveillantes.
L'exemple typique parmi beaucoup d'autres est un site ou service web, hébergé sur un serveur en location chez un hébergeur de masse tel que Online ou OVH. Sur cet unique serveur s'exécutent un serveur web, un serveur d'application, et un serveur de base de données.
De façon générale, je traite ici le cas d'un service s'exécutant sur un unique serveur physique. Soit directement sur le système d'exploitation du serveur, soit au sein de machines virtuelles ou de containers. Les données sont stockées sur des disques internes au serveur, et non sur un stockage distant.
Le service s'exécutant sur un unique serveur, la défaillance matérielle de celui-ci entraînera forcément une indisponibilité plus ou moins longue du service, ainsi qu'un risque concernant l'intégrité des données stockées.
On s'intéressera donc aux aspects suivants :
Le système d'exploitation s'exécute sur un serveur pourvu d'un seul disque de stockage.
Aucune sécurisation.
La disponibilité du service est à la merci de la défaillance d'un élément matériel du serveur et le temps de rétablissement dépendra du temps pour remplacer ou réparer celui-ci.
Dans le meilleur des cas, l'administrateur du serveur ou le prestataire d'hébergement dispose d'un stock de rechange. Celui-ci s'occupera réactivement de la réparation ou du transfert du disque dans un nouveau serveur. Dans tous les cas, il y aura un délai incompressible d'intervention en salle machine.
Dans le pire des cas, il n'y a pas de stock, ni pièces de rechange, ni matériel de remplacement. Il faudra patienter jusqu'à la livraison d'un nouveau serveur par le fournisseur, ou effectuer des opérations complexes pour extraire les données du disque et activer le service sur un serveur déjà dédié à une autre tâche.
Concernant la sécurité des données, en cas de défaillance de l'unique disque dur ou d'une erreur humaine qui entraînerait l'effacement des données :
Cette configuration est donc à proscrire, même pour un service de faible importance.
Idem niveau précédent, mais le serveur est pourvu de plusieurs disques avec une redondance de type RAID, qui permet de tolérer la perte d'un ou plusieurs disques.
La sécurité de l'intégrité des données est renforcée. La perte d'un disque, incident relativement fréquent, est maintenant tolérée.
On reste tout de même à la merci de la défaillance d'un groupe de disques localisé dans un même chassis matériel. En cas de problème électrique majeur, d'un bug du contrôleur RAID, ou d'une erreur humaine, la perte de données sera totale.
Ce n'est pas une configuration conseillée, mais si on l'utilise il est impératif de surveiller l'état de la redondance disque de façon régulière et automatique !
Idem niveau précédent, mais les données sont sauvegardées à intervalle régulier vers un second serveur ou un service de sauvegarde.
Le temps de rétablissement du service en cas d'incident matériel est aussi problématique que dans les niveaux précédents. Tout dépendra de la capacité à réparer ou remplacer le serveur défectueux.
La sécurité des données est assurée, mais en cas de catastrophe on perd les données depuis la dernière sauvegarde. Suivant les cas, cela peut aller d'ennuyeux (site web statique dont on perdrait seulement les journaux d'accès au serveur web) à calamiteux (site d'e-commerce ayant enregistré des transactions).
La sécurité des données en cas d'erreur humaine est assurée, mais seulement si le serveur de sauvegarde conserve un historique sur plusieurs jours, semaines, mois. On court sinon le risque qu'une suppression ou modification accidentelle d'un fichier ne soit détectée que trop tard, après que la sauvegarde ait eu lieu en écrasant la précédente.
Il s'agit pour moi du niveau de sécurisation minimum acceptable.
En plus d'une surveillance rigoureuse de l'état des disques, il est nécessaire de disposer d'une procédure de restauration des sauvegardes précise et testée.
Idem niveau précédent, mais on dispose d'un serveur de secours dédié. Celui-ci est configuré à l'identique du serveur de production afin de pouvoir prendre en charge le service à n'importe quel moment.
Il est nécessaire que la configuration système de ce serveur de secours soit synchronisée en temps réel avec le serveur de production. Deux solutions :
Soit gérer la configuration système avec un outil de gestion de configuration tel que Salt ou CFEngine. Chaque modification sera alors diffusée automatiquement vers le serveur de production et le serveur de secours.
Soit disposer d'une configuration système minimale et héberger le service dans des machines virtuelles ou des containers qui seront intégralement sauvegardés. Ceux-ci seront alors autonomes et prêts à être démarrés sur le serveur de secours. Dans ce cas de figure, le serveur de secours sera même capable de secourir plusieurs serveurs de production.
De plus, il sera nécessaire de pouvoir basculer aisément les adresses IP du service d'un serveur vers l'autre. Certains hébergeurs rendent cela possible en utilisant des adresses IP failover que l'on peut basculer facilement à l'aide d'une interface d'administration. Il est parfois possible de basculer une adresse IP d'un datacenter vers un autre, ce qui permet en plus d'établir une sécurité géographique entre le serveur principal et le serveur de secours.
Le temps de rétablissement du service est alors nettement amélioré. Il suffit de recopier depuis le serveur de sauvegarde vers le serveur de secours, soit les données nécessaires au bon fonctionnement du service (cas 1), soit les disques virtuels des containers ou machines virtuelles (cas 2), puis de basculer les adresses IP. Tout cela ne dispense évidemment pas de disposer d'une procédure de reprise d'activité détaillée.
En terme de sécurisation des données, c'est identique au niveau précédent. Tout ce qui est créé entre deux sauvegardes est menacé en cas d'incident matériel ou d'erreur humaine.
Idem niveau précédent, mais les données de production sont répliquées en permanence vers le serveur de secours.
Pour cela, on dispose sous Linux de technologies comme DRBD, qui permettent de répliquer des volumes disques par le réseau. Il devient alors nécessaire de disposer d'un réseau privé entre les serveurs, éventuellement de type VPN.
En cas d'incident matériel, il suffira de forcer l'arrêt de la réplication (pour s'assurer qu'elle ne reprenne pas lors du rétablissement du serveur principal), démarrer le service sur le serveur de secours, puis basculer les adresses IP.
Le temps de rétablissement du service reste comparable à celui du niveau précédent, mais désormais la perte de données sera minime ou inexistante en cas d'incident matériel.
Cela ne changera rien en cas d'erreur humaine entraînant une perte de données, car cette erreur sera immédiatement répliquée vers le serveur de secours. Il ne faut donc pas se dispenser d'effectuer des sauvegardes régulières et historisées.
Idem niveau précédent, mais le basculement est automatique.
Si on souhaite mettre en place un basculement automatique, il devient alors nécessaire d'utiliser un logiciel dédié à cette tâche, comme Keepalived ou Heartbeat. Celui-ci se chargera de vérifier le bon fonctionnement et la disponibilité du serveur principal, et activera automatiquement le service et les adresses IP sur le serveur de secours si c'est nécessaire. Il faut alors prendre toutes les mesures nécessaires pour éviter des incidents qui pourraient résulter d'une réplication de données encore active alors que le service a basculé sur le serveur de secours.
Il devient également impératif de disposer d'un réseau LAN dédié entre les serveurs, ce qui permet de positionner à volonté des adresses IP et d'effectuer des tests automatiques de disponibilité entre les serveurs sans passer par des équipements de routage intermédiaire. Les principaux hébergeurs de masse proposent ce type de service.
Le rétablissement du service se fait alors très rapidement, sauf encore et toujours en cas d'erreur humaine.
L'évolution suivante est le passage vers une infrastructure multi-tiers, avec de multiples serveurs applicatifs en équilibrage de charge et des données centralisées dans des base de données et du stockage en cluster. On pourra également bénéficier des services de baies de disques SAN ou NAS fournis par les hébergeurs. Mais cela sort du cadre de cet article (service internet hébergé sur un unique serveur).
Ces infrastructures évoluées sont plus robustes, plus adaptées, et plus souples à administrer pour des services nécessitant une haute fiabilité, mais cela au prix d'une augmentation de la complexité pour les développeurs en terme de déploiement du code et de gestion des données. Mais c'est probablement une bonne chose de pousser à l'utilisation des méthodes de développement modernes : contrôle de version, déploiement automatique, intégration continue.