Du point de vue de la sécurité, une option sûre qui est utilisée par exemple par les fournisseurs d'hébergement de VPS avec lesquels nous travaillons, est de DMZ les VM, et non l'hôte hyper-v.
En mettant en DMZ les VM au lieu de l'hôte, vous pouvez accéder et sauvegarder l'hôte comme d'habitude et n'avoir que les VM exposées à l'extérieur. Les attaquants ne peuvent pas facilement accéder à l'hôte depuis la VM. Seuls les services d'intégration Hyper-V permettraient potentiellement et théoriquement à certains logiciels malveillants de parler à l'hôte ; cependant, Microsoft a assez bien protégé cela jusqu'à présent.
Toutes les stratégies, y compris celles mentionnées ci-dessus, ont leurs propres avantages et inconvénients :
Ajouter un nouveau NAS de sauvegarde dans le réseau local interne et ouvrir le port entre le serveur Hyper-V de la DMZ pour les sauvegardes
Dans ce cas, l'attaquant prend le contrôle de l'hôte et peut faire ce qu'il veut, y compris endommager le dispositif de sauvegarde. Au fait, le logiciel de rançon fait cela aussi. Il peut y trouver des partages d'accès au réseau et y endommager tous les fichiers.
Ajout d'un nouveau NAS dans la DMZ. Pro : pas besoin de changer quoi que ce soit dans le pare-feu
Dans ce cas, l'inconvénient est que l'attaquant pourrait obtenir un accès complet à l'hôte, à toutes les VM qui s'y trouvent et à toutes les sauvegardes, vous laissant potentiellement sans rien à restaurer en cas d'attaque.
Si vous DMZ toutes les VM en utilisant des adresses IP statiques, le risque est limité aux internes de chaque VM. L'inconvénient est que vous devez DMZ toutes les VM séparément, mais l'hôte resterait sur le réseau interne et serait protégé tel quel, y compris les sauvegardes, etc.
Une autre astuce de sécurité consiste à installer un commutateur virtuel isolé et à connecter une carte d'interface réseau distincte pour ces machines de la zone démilitarisée, de sorte que les machines n'aient aucun moyen de communiquer avec le réseau interne, y compris l'hôte. Cela vous donne une autre couche de sécurité au cas où quelqu'un piraterait la VM.
Essayez cette solution de sauvegarde pour protéger vos serveurs Hyper-V et vos VM à un prix avantageux.
mardi 25 août 2020
Sauvegarde Hyper-V et serveurs DMZ sécurisés : Un guide pratique
Sauvegarde Hyper-V CSV: Que faut-il prendre en compte pour les sauvegardes VM?
Les points suivants doivent être observés lors de la sauvegarde des VM Hyper-V en CSV.
1. La dernière version de votre BackupChain doit être utilisée
2. Tous les fichiers VM doivent être sauvegardés sur le même CSV
3. La sauvegarde doit être effectuée uniquement via l'onglet Hyper-V. La sauvegarde complète de l'image du serveur ne doit pas inclure de volumes CSV ; elle doit seulement inclure le système d'exploitation et, éventuellement, les disques de données.
4. S'il est probable que les VM seront déplacées vers d'autres nœuds, la fonction de sélection automatique doit être utilisée au lieu de sélectionner les VM dans la liste Une limite de vitesse est activée lorsque l'option de cluster est définie lors de la création de la tâche. Elle peut être augmentée ou désactivée si vous êtes sûr que le trafic de gestion des CSV est isolé à 100 % et ne peut pas être affecté par le trafic de sauvegarde et les autres transferts de données. Sinon, il peut arriver que les battements de cœur n'arrivent pas à temps et que Hyper-V désactive complètement le nœud
Comme pour toutes les sauvegardes Hyper-V, en fonction de l'OS hôte et invité, il peut arriver qu'Hyper-V "glisse" un minuscule point de contrôle peu avant la sauvegarde, qui est supprimé immédiatement après la phase d'initialisation. Ce fichier de point de contrôle apparaît dans les dossiers de sauvegarde sous la forme *.AVHDX. En outre, vous trouverez également d'autres AVHD / X dans les dossiers de sauvegarde si la VM a d'autres points de contrôle.
Nous recommandons de ne pas utiliser les points de contrôle et si vous les utilisez, ils ne doivent être utilisés que pendant une courte période. L'utilisation des points de contrôle présente également certains inconvénients et risques à prendre en compte. La récupération granulaire dans BackupChain ne fonctionne que sur la base VHD / X. Les points de contrôle ne peuvent pas être inspectés avec cette fonctionnalité, c'est-à-dire qu'une récupération complète est plus probablement nécessaire si les fichiers souhaités ne peuvent pas être trouvés dans le fichier VHD principal. Lorsque vous créez un point de contrôle dans Hyper-V, le VHD est gelé (et les points de contrôle précédents le sont également) et un nouveau AVHD/X est créé. Toutes les modifications au sein de la VM seront à l'avenir écrites dans l'AVHD par secteur. Lors de la suppression d'un point de contrôle, le contenu des AVHD doit être fusionné avec la VHD parente, ce qui peut prendre un certain temps.
Les inconvénients sont une plus grande complexité et un accès plus lent aux hôtes et au réseau. Les risques sont la perte possible de données, il y avait déjà plusieurs bogues dans Hyper-V qui ont conduit à une perte complète. Quelques phases risquées sont restées, par exemple le processus de fusion lorsqu'un point de contrôle est supprimé ou lorsque les références VHD sont mises en place lors de la création des points de contrôle. Si, par exemple, le système est sauvegardé ou s'il y a une panne de courant, la mémoire du CSV est également séparée et affectée en plus, il y a un risque de corruption des données. Microsoft a bien sûr amélioré le format VHDX pour réduire les risques, mais les disques durs virtuels ne sont certainement pas protégés à 100 % contre la corruption, quelle qu'en soit la cause.