Sécurité des accès et protection des données, les questions à vous poser !
change de nom...
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.
Nous avons identifié 5 aspects de l’infogérance qui méritent une attention particulière et de se poser les bonnes questions.
Pour vous aider à y voir plus clair, nous vous partageons maintenant nos bonnes pratiques sur les 5 aspects mentionnés ci-dessus.
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.
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.
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. |
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 :
Nous monitorons l’ensemble de nos serveurs avec plusieurs outils, dont “Zabbix” et Prometheus.
Les alertes sont envoyées en fonction du degré de criticité et des options choisies par nos clients :
L’outil Zabbix est lui-même vérifié via un second outil indépendant : PHP Server Monitor
Nous distinguons deux types de sauvegardes :
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.
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.
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 est décidée conjointement avec nos clients. Elle consiste à définir :
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).
Nous avons choisi le système d’exploitation GNU/Linux pour la quasi-totalité de nos installations.
La distribution de référence chez Codéin est la distribution 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é.
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.
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.
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.
Un serveur est dit compromis lorsqu’un attaquant externe réussit à exécuter des commandes sur celui-ci. L’attaquant peut alors, par exemple :
Le serveur peut être compromis de deux manières :
Via une faille système
Exemple :
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 :
Une fois la faille trouvée :
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 :
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 !
Audit sécurité
Besoin d'auditer la sécurité de votre SI ?
Contactez-nous!
Besoin d'auditer la sécurité de votre SI ?
Contactez-nous!
Besoin d'auditer la sécurité de votre SI ?
Contactez-nous!