la virtualisation dans votre environnement, vous devez connaître certains aspects de la technologie, dont quelques soucis de sécurité qui lui sont inhérents. Donc, avant de vous lancer, il vous faut avoir une idée d’ensemble de Virtual Server et de ses dangers potentiels, et il vous faut aussi des solutions pratiques, valables pour la majorité des entreprises. C’est parti.
L’installation de Virtual Server est extrêmement facile, mais quelques étapes préparatoires sont néanmoins nécessaires pour assurer la sécurité. L’OS hôte est le maillon le plus faible de Virtual Server : s’il est compromis, pratiquement toute machine virtuelle (VM, virtual machine) qui travaille avec lui peut être compromise. C’est pourquoi le serveur physique doit se trouver dans un local particulièrement sûr. Quand Virtual Server est en action, il alloue de la mémoire physique de l’OS hôte (host) à chaque OS invité (guest). Les disques virtuels qu’utilisent les VM se trouvent généralement dans un stockage DAS ou Fibre Channel. Si un utilisateur mal intentionné se fraie l’accès physique à une machine, il peut attacher un débogueur physique ou activer un débogueur logiciel et surveiller les OS invités en action, en captant des secrets tels que des mots de passe.
Ce même utilisateur peut aussi accéder aux disques virtuels et les lire comme si c’étaient des fichiers bruts, en glanant au passage des informations sensibles au moyen de simples outils d’analyse ou même d’un banal éditeur hexadécimal. Il faut donc sécuriser au maximum l’OS hôte. Commencez par les précautions standard : supprimez les comptes locaux pas strictement nécessaires et assurez-vous que ceux qui restent sont protégés par de puissants mots de passe. Ensuite, réduisez la surface d’attaque en supprimant les éventuels services et applications étrangers. Ne faites pas cohabiter Virtual Server avec d’autres produits serveurs, comme Microsoft Exchange Server ou SQL Server.
Bien que vous deviez exécuter Microsoft IIS sur l’OS hôte pour administrer Virtual Server, vous ne devriez pas héberger des sites Web supplémentaires. Si un utilisateur malveillant parvient à exploiter à distance une vulnérabilité, il pourra contrôler la totalité de l’OS hôte et donc accéder aux VM. En réduisant la surface d’attaque, on diminue le risque de voir un pirate trouver une faille distante à exploiter. La réduction de la surface d’attaque présente un autre avantage : il y aura moins de mises à jour à appliquer au fil du temps. C’est un avantage appréciable parce que les mises à jour peuvent affecter la disponibilité des OS invités.
Si votre OS hôte est un serveur membre dans un domaine, assurez-vous que les utilisateurs sans raison légitime sont empêchés de se connecter à l’OS hôte sur le réseau – par des shares réseau ou par Terminal Services. L’implication est que l’OS hôte n’est pas utilisé pour le partage de fichiers et d’imprimantes. Vous pouvez utiliser le snap-in Microsoft Management Console (MMC) Local Security Policy ou un GPO (Group Policy Object) pour configurer la stratégie de sécurité de l’OS hôte.
Lancez le snap-in, étendez Local Policies et cliquez sur User Rights Assignment dans le panneau de gauche. Dans le panneau de droite, double-cliquez sur Deny access to this computer from the network et assurez- vous que les utilisateurs qui n’ont pas l’accès légitime à l’OS hôte (ou les groupes dont ils sont membres) sont inclus dans la liste des refusés. Répétez cette procédure pour Deny logon through Terminal Services. Sachez toutefois que le fait de refuser l’accès sur le réseau et par Terminal Services vers l’OS hôte n’empêchera pas les utilisateurs d’accéder aux services offerts par les VM sur le serveur. Pour restreindre l’accès à ces systèmes, vous devez les configurer de la même manière. Pour sécuriser encore davantage l’hôte, songez à utiliser Windows Firewall et IPsec de Windows 2003 SP1.
Sachez toutefois que le simple fait de configurer le pare-feu ou IPsec de l’OS hôte n’empêchera pas forcément les utilisateurs d’accéder aux services des OS invités. Vous devez aussi repenser votre stratégie de gestion des mises à jour pour les OS hôtes sous Virtual Server. Ainsi, vous ne devriez pas configurer votre OS hôte pour utiliser Microsoft Update (ou un mécanisme de mise à jour interne tel que SMS ou WSUS) et réinitialiser automatiquement après l’application d’une mise à jour.
Si votre serveur devait se réinitialiser dans un tel cas, toutes les données présentes dans vos VM seraient perdues à moins que vous n’ayez fait le nécessaire pour fermer en bonne et due forme les OS invités, ou au moins sauvegarder leur état sur disque. L’implication pratique est claire : il vous faudra trouver le moyen de mettre à jour votre OS hôte sans affecter la disponibilité de vos OS invités.
Téléchargez cette ressource
Préparer l’entreprise aux technologies interconnectées
Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.
