Comment sécuriser votre infrastructure ?

Mathieu Codéin
Mathieu Blanc
2 mai 2022

Dans le précédent article, nous avons vu comment sécuriser vos accès (locaux et serveurs) ainsi que les questions à se poser au sujet des logiciels utilisés par l’ensemble de vos collaborateurs.

Cet article a pour objectif de vous présenter nos bonnes pratiques et les technologies que nous utilisons en termes d’infogérance système qui permettent à la fois de protéger votre infrastructure sur cloud privé et public et d’assurer une continuité de service en cas d’incident ou d’attaque.

 

Les bonnes pratiques pour protéger votre infrastructure sur cloud privé ou public

 

Nous avons identifié 5 aspects de l’infogérance qui méritent une attention particulière et de se poser les bonnes questions.

  • La virtualisation : Comment est réalisée la virtualisation de vos serveurs ?
  • Le monitoring : Quel est le processus mis en place concernant le monitoring de votre infrastructure ?
  • Les sauvegardes : Un plan de sauvegarde est-il prévu ? Quel est-il ? Quel est la fréquence des sauvegardes et la durée de rétention choisie ? Est-ce adapté aux besoins de votre entreprise ?
  • L’infrastructure logicielle : Comment est assurée la sécurité de votre infrastructure logicielle ? Quels sont les systèmes d’exploitations utilisés ? Comment sont installées les mises à jour de sécurité ? À quelle fréquence ? Connaissez-vous la durée de support de votre système d’exploitation ?
  • La gestion des attaques : Qu’avez-vous prévu en cas de compromission des serveurs ? Que se passe-t-il en cas de déni de service ?

Pour vous aider à y voir plus clair, nous vous partageons maintenant nos bonnes pratiques sur les 5 aspects mentionnés ci-dessus.

 

Virtualisation et technologies utilisées

 

Tous les serveurs de notre Cloud privé sont virtualisés grâce à l’utilisation de KVM

 

KMV

 

Tous les serveurs, qu’ils soient à vocation d’usage interne, ou bien les serveurs clients que nous installons sont virtualisés. La machine (au sens matériel) est appelée “serveur physique”, “serveur parent” ou “serveur hôte”. Le serveur accueillant l’application est appelé “serveur virtuel”, “machine virtuelle” ou encore “serveur enfant”. La technologie de virtualisation est KVM, l’hyperviseur de référence sur Linux.

 

Stockage des machines virtuelles avec Open ZFS

 

OpenZFS

 

Le stockage des machines virtuelles sur le serveur hôte est réalisé sur le système de fichiers ZFS réputé pour son extrême fiabilité sur les problématiques de corruption des données.

Une machine virtuelle est systématiquement créée, même dans le cas où un serveur physique est entièrement dédié à un client et ne doit faire tourner qu’un seul applicatif.

La virtualisation permet une abstraction totale du matériel. Un serveur virtualisé peut être cloné, déplacé ou restauré sur un autre serveur physique disposant du duo Linux+KVM.

 

Adresse IP “Failover”

  • Chaque serveur virtualisé dispose d’une adresse IP (dite “Failover”) qui peut être déplacée vers une autre machine physique chez OVH.
  • L’utilisation conjointe de la virtualisation et des IP « failover » permet de déplacer ou restaurer un serveur virtuel vers n’importe quel datacenter OVH.

Par exemple, un sinistre grave (incendie) est déclaré dans le datacenter OVH de Roubaix, et celui-ci est indisponible pour une durée inconnue. La sauvegarde distante de la machine virtuelle se trouve dans le datacenter OVH de Strasbourg. Il est possible de restaurer la sauvegarde sur un serveur hôte temporaire et de basculer l’adresse IP vers ce serveur. L’application est alors à nouveau disponible sans aucun changement au niveau DNS.

 

Cas du Cloud Public

Dans certains cas spécifiques (application cloud-ready, besoin d’élasticité ou de forte automatisation), Codéin déploie ses applications en utilisant les ressources d’un fournisseur de Cloud Public. Nous utilisons pour cela OVHCloud et Outscale, selon nos besoins.

Il y a plusieurs points de réflexion à aborder sur la sécurité des données lors de l’utilisation d’un Cloud Public :

  • la localisation des serveurs 
    •  Si l’application est hautement disponible, s’assurer que la répartition des serveurs virtuels chez le fournisseur de cloud est conforme: par exemple, que tous les serveurs ne tournent pas sur la même machine physique ou dans le même datacenter
    • Si l’application a des contraintes particulières en termes de données, s’assurer que le pays ou que l’origine du fournisseur de Cloud ne pose pas de problème (cas du “Cloud Act”, du RGPD…)
  • la localisation des sauvegardes
    • Il faut s’assurer que les sauvegardes, généralement gérées via les services fournis par le fournisseur de Cloud, soient conformes à vos exigences : datacenter distant, sauvegardes chiffrées…

 

Nos outils et process de monitoring

Nous monitorons l’ensemble de nos serveurs avec plusieurs outils, dont “Zabbix” et Prometheus.

Monitoring Zabbix

 

Les alertes sont envoyées en fonction du degré de criticité et des options choisies par nos clients :

  • alertes affichées sur le dashboard Zabbix
  • métrologie accessible sur une interface Grafana
  • alertes envoyées par mails
  • alertes envoyées sur un groupe Google Chat interne à Codéin
  • alertes envoyées par SMS

L’outil Zabbix est lui-même vérifié via un second outil indépendant : PHP Server Monitor

 

Une sauvegarde doublée  

Nous distinguons deux types de sauvegardes :

  • la sauvegarde complète du serveur
  • la sauvegarde logique des composants applicatifs (base de données)

 

Sauvegarde complète du serveur par “snapshots”

Nous hébergeons nos machines virtuelles sur le système de fichier ZFS qui permet la création de “snapshots”. Il s’agit d’une vue instantanée et atomique de la machine virtuelle. À l’intérieur des machines virtuelles, le système de fichier utilisé est journalisé (ext4), ce qui permet de restaurer cet instantané sans aucune perte de données.

Cet instantané est envoyé de manière chiffrée (SSH) vers le serveur de sauvegarde qui dispose alors d’une copie complète du serveur virtuel en question.

Un snapshot peut également être réalisé en journée, dans le cas d’une mise en production par exemple. La procédure de rollback consiste alors en la restauration de l’instantané.

Nos serveurs de sauvegarde sont situés dans un datacenter distant.

 

Sauvegarde logique de la base de données

Nous doublons les sauvegardes par instantané avec une sauvegarde logique de la base de données (via mysqldump dans le cas de MariaDB/MySQL), qui permet de la restaurer à partir d’un fichier SQL.

 

MariaDB

 

En fonction de la taille de la base, cette restauration peut être souvent plus longue qu’une restauration d’instantané, mais elle permet de restaurer une base en cas de compromission des données, ou encore de restaurer une base jusqu’à un moment très précis de la journée, grâce au rejeu des logs binaires (Point-in-time-Recovery). Les logs binaires sont des journaux horodatés où sont consignées toutes les modifications réalisées sur la base de données. Ils sont activés par défaut sur nos installations.

 

La politique de sauvegarde

La politique de sauvegarde est décidée conjointement avec nos clients. Elle consiste à définir :

  • la fréquence des sauvegardes complètes et logiques
  • la rétention des sauvegardes complètes et logiques

Par défaut, nous réalisons une sauvegarde journalière (complète et logique) avec une rétention de 7 jours.

 

Pour aller plus loin sur les sauvegardes, découvrez l'étude de cas de notre client Sandaya pour lequel nous avons mis en place un Plan de Reprise d'Activité (PRA).

 

Comment assurer la sécurité de l’infrastructure logicielle ?

 

Le choix des systèmes d’exploitation 

Nous avons choisi le système d’exploitation GNU/Linux pour la quasi-totalité de nos installations.

 

GNU/Linux

 

La distribution de référence chez Codéin est la distribution Debian

 

Debian

 

Cette distribution est l’une des plus anciennes encore en activité et bénéficie d’une communauté très active. Debian fournit la stabilité nécessaire aux environnements de production.

Par défaut, pour des raisons de qualité, de stabilité et de sécurité du serveur, nous refusons toute installation de logiciel qui serait extérieur aux dépôts officiels de Debian.

L’exception notable sur le choix du système d’exploitation concerne les bastions. Le bastion est un serveur particulier qui sert à atteindre via SSH les serveurs clients. C’est ce serveur qui figure notamment dans le listing des adresses IP autorisées par les firewalls. Le bastion doit être par définition ultra-sécurisé. Pour ce besoin très spécifique, nous avons choisi le système d’exploitation OpenBSD, qui est un des OS réputé pour ses qualités sur les questions de sécurité. 

 

OpenBSD

 

Issu de la grande famille des systèmes BSD, OpenBSD est notamment le projet responsable du logiciel OpenSSH, qui est l’outil de référence permettant d’accéder à distance aux serveurs de manière chiffrée. OpenBSD est un système dont la surface d’attaque est très faible et dont tous les mécanismes de sécurité sont activés par défaut.

 

Des mises à jour de sécurité quotidiennes et automatisées

Les mises à jour de sécurité sont installées automatiquement entre 6H et 7H du matin.
L’équipe Hosting est abonnée aux listes de diffusion CERT-FR et Debian-Security.

 

Mettre en place une veille sur la durée de support du système d’exploitation

Une distribution Debian bénéficie d’environ 5 ans de mises à jour de sécurité. Passé ce délai, le système ne reçoit plus de mise à jour.

Nous prévenons nos clients 1 an à l’avance lorsque le support de son système d’exploitation arrive à échéance et proposons alors une mise à jour de leur système d’exploitation vers une version supportée. 

 

Comment gérer les attaques ?

 

Que faire en cas de compromission des serveurs ?

Un serveur est dit compromis lorsqu’un attaquant externe réussit à exécuter des commandes sur celui-ci. L’attaquant peut alors, par exemple :

  • Récupérer des données
  • Effacer des données
  • Modifier le site web
  • Participer à une attaque DDOS (des attaques ayant pour but de rendre indisponible un service)
  • Envoyer des spams

Le serveur peut être compromis de deux manières :

Via une faille système

Exemple :

  • un utilisateur test avec un mot de passe test accessible en SSH
  • Un service écoutant sur le réseau (apache) dont une faille a été publiée et le patch de sécurité n’a pas été installé

Via une faille applicative

Exemple :

La restauration d’une sauvegarde avant le piratage n’est pas considérée comme sécurisée : la faille est encore présente et le serveur était peut-être déjà compromis au moment de la sauvegarde (certains attaquants attendent plusieurs jours avant de faire des actions sur le serveur). De plus, les accès de l’attaquant peuvent être suffisants pour effacer ses propres traces, rendant la compromission difficilement détectable.

Pour ces raisons et dans une optique de garantir la sécurité de nos clients et de leur infrastructure, nous appliquons la méthode suivante en cas de piratage d’un serveur :

  • Arrêt du serveur et relance sans accès internet
  • Recherche d’une faille système par l’équipe système
  • Recherche d’une faille applicative par l’équipe développement

Une fois la faille trouvée :

  • Le serveur doit être entièrement recréé (vierge, à partir d’un modèle sûr)
  • En cas de faille système : correction de la faille par l’équipe système
  • En cas de faille applicative : correction de la faille par l’équipe développement
  • Livraison des sources du site à partir d’une source sûre (git, svn)
  • Remise en ligne du site

 

Quelle solution mettre en place lors d’un déni de services ?

Les attaques par déni de service (DOS, DDOS) consistent à rendre inaccessible un service (un site web recevant trop de requêtes par seconde finira par ne plus pouvoir répondre correctement).

Dans cette situation, l’objectif est d’essayer de limiter les conséquences en dégageant un modèle commun à l’attaque :

  • Filtrage sur les adresses IP concernées (dans le cas d’une attaque distribuée, cela peut être impossible)
  • Filtrage sur les URLs concernées (attaque d’une page spécifique par exemple)

Si les filtres classiques ne sont pas suffisants, il faut rechercher des solutions externes de protection contre les attaques de ce type.

Par défaut, tous nos serveurs bénéficient d’une protection anti-ddos fournie par le prestataire OVH : https://www.ovh.com/fr/anti-ddos/
Enfin, dans le cas où le site subit une attaque DDOS trop importante qui mettrait en péril l’infrastructure globale, couper les services est la meilleure option. En règle générale, l’attaque se termine d’elle-même en quelques minutes lorsque le service ne répond plus !

 

Cet article vous a plu ? N’hésitez pas à lire notre article précédent : Comment sécuriser votre SI, partie 1

Pour recevoir mensuellement nos derniers articles liés au hosting, aux performances, à la sécurité…, abonnez-vous à notre newsletter !

En savoir plus sur l'infogérance made in Codéin ? Consultez nos pages dédiées !

Si vous avez besoin de conseils concernant la sécurité de votre système d’information ou besoin d’auditer votre SI, n’hésitez pas à nous contacter !

Besoin d'auditer la sécurité de votre SI ? Contactez-nous!
Besoin d'auditer la sécurité de votre SI ? Contactez-nous!

A lire aussi

Sécurité des accès et protection des données, les questions à vous poser !
Entre le cloud privé, le cloud public et le cloud hybride, comment y voir plus ...
Voir tous les articles