Sécurisation des hyperviseurs

L’hyperviseur Azure est conçu pour tenir compte des objectifs de sécurité suivants : Objectif Source Isolation Une stratégie de sécurité n’impose aucun transfert d’informations entre les machines virtuelles. Cette contrainte requiert des capacités dans Virtual Machine Manager (VMM) et du matériel pour l’isolation de la mémoire, des appareils, du réseau et des ressources managées telles que les données persistantes. Intégrité de VMM Pour garantir l’intégrité globale du système, l’intégrité des composants individuels de l’hyperviseur est établie et entretenue. Intégrité de la plateforme L’intégrité de l’hyperviseur dépend de l’intégrité du matériel et des logiciels sur lesquels il s’appuie. Bien que l’hyperviseur n’ait pas de contrôle direct sur l’intégrité de la plateforme, Azure s’appuie sur des mécanismes matériels et logiciels, tels que le processeur Cerberus, pour protéger et détecter l’intégrité de la plateforme sous-jacente. Les invités et VMM ne peuvent pas s’exécuter si l’intégrité de la plateforme est compromise.

ACCÈS RESTREINT Les fonctions de gestion ne sont exercées que par les administrateurs autorisés connectés via des connexions sécurisées. Un principe de moindre privilège est appliqué par les mécanismes Azure RBAC (contrôle d’accès en fonction du rôle Azure). Audit Azure permet à la capacité d’audit de capturer et de protéger les données sur ce qui se passe sur un système afin qu’elles puissent être inspectées ultérieurement. Limiter l'accès à ESXi Par défaut, les services ESXi Shell et SSH ne s'exécutent pas et seul l'utilisateur racine peut se connecter à l'interface utilisateur de la console directe (DCUI). Si vous décidez d'activer l'accès à ESXi ou SSH, vous pouvez définir des délais d'expiration pour limiter le risque d'accès non autorisé. Les hôtes pouvant accéder à l'hôte ESXi doivent disposer d'autorisations de gestion de l'hôte. Ces autorisations se définissent sur l'objet hôte du système vCenter Server qui gère l'hôte. Utiliser des utilisateurs nommés et le moindre privilège Par défaut, l'utilisateur racine peut effectuer de nombreuses tâches. N'autorisez pas les administrateurs à se connecter à l'hôte ESXi en utilisant le compte d'utilisateur racine. Au lieu de cela, créez des utilisateurs Administrateur nommés à partir de vCenter Server et attribuez-leur le rôle d'administrateur. Vous pouvez également attribuer à ces utilisateurs un rôle personnalisé.

L’hyperviseur Azure applique plusieurs limites de sécurité entre : Les partitions « invité » virtualisées et la partition privilégiée (« hôte ») Plusieurs invités Lui-même et l’hôte Lui-même et tous les invités. La confidentialité, l’intégrité et la disponibilité sont assurées pour les limites de sécurité de l’hyperviseur. Ces limites permettent de se défendre contre toute une série d’attaques, notamment les fuites d’informations sur les canaux secondaires, le déni de service et l’élévation des privilèges. La limite de sécurité de l’hyperviseur fournit également une segmentation entre les locataires pour le trafic, les appareils virtuels, le stockage, les ressources de calcul et toutes les autres ressources de machine virtuelle. Pourquoi les hyperviseurs sont importants pour la sécurité Les hyperviseurs permettent de réduire la surface d'attaque en isolant les machines virtuelles. Si une VM est compromise, les autres ne sont pas affectées. Un déploiement et une configuration appropriés de l'hyperviseur peuvent également favoriser une segmentation sécurisée, une reprise plus rapide et une résilience globale de l'infrastructure plus forte.

Dans le cas improbable où une limite de sécurité présente une vulnérabilité, l’hyperviseur Azure inclut plusieurs couches d’atténuations, notamment : Isolation du processus basé sur l’hôte hébergeant des composants entre machines virtuelles Sécurité basée sur la virtualisation (VBS) pour garantir l’intégrité des composants utilisateur et en mode noyau à partir d’un monde sécurisé Plusieurs niveaux d’atténuations de code malveillant exploitant une faille de sécurité. Les atténuations incluent la randomisation du layout d’espace d’adresse (ASLR), la prévention de l’exécution des données (DEP), la protection de code arbitraire, l’intégrité du flux de contrôle et la prévention de l’altération des données Initialisation automatique des variables de pile au niveau du compilateur API de noyau qui initialisent automatiquement les allocations de tas de noyau effectuées par Hyper-V. Ces atténuations sont conçues pour rendre irréalisable le développement d’un code malveillant exploitant une faille de sécurité pour introduire une vulnérabilité sur toutes les machines virtuelles. Réduire le nombre de ports de pare-feu ESXi ouverts Par défaut, les ports de pare-feu de votre hôte ESXi sont uniquement ouverts lorsque vous démarrez un service correspondant. Vous pouvez utiliser les commandes de vSphere Client, ESXCLI ou PowerCLI pour vérifier et gérer l'état des ports du pare-feu.

Vérifier l'intégrité du module VIB Un niveau d'acceptation est associé à chaque module VIB. Vous pouvez ajouter un VIB à un hôte ESXi uniquement si son niveau d'acceptation est identique ou supérieur au niveau d'acceptation de l'hôte. Vous ne pouvez pas ajouter un VIB CommunitySupported ou PartnerSupported à un hôte à moins d'avoir explicitement modifié le niveau d'acceptation de l'hôte. Gérer les certificats ESXi Dans vSphere 6.0 et version ultérieure, VMware Certificate Authority (VMCA) provisionne chaque hôte ESXi à l'aide d'un certificat signé dont l'autorité de certification racine par défaut est VMCA. Si la stratégie de votre entreprise l'exige, vous pouvez remplacer les certificats existants par des certificats signés par une autorité de certification d'entreprise ou tierce. Envisager l'authentification par carte à puce À partir de vSphere 6.0, ESXi prend en charge l'utilisation de l'authentification par carte à puce plutôt que l'authentification par nom d'utilisateur et mot de passe. Pour une sécurité renforcée, vous pouvez configurer l'authentification par carte à puce. L'authentification à deux facteurs est également prise en charge pour vCenter Server. Envisager le verrouillage des comptes ESXi À partir de vSphere 6.0, le verrouillage des comptes est pris en charge pour l'accès via SSH et vSphere Web Services SDK. Par défaut, un nombre maximal de 10 tentatives de connexion échouées est autorisé avant le verrouillage du compte. Par défaut, le compte est déverrouillé au bout de deux minutes.

La surface d’attaque liée à l’hyperviseur comprend la mise en réseau logicielle, les appareils virtuels et toutes les surfaces de machines virtuelles. La surface d’attaque est suivie grâce à l’intégration automatisée de build, qui déclenche des révisions de sécurité périodiques. Toutes les surfaces d’attaque de machine virtuelle sont modélisées d’après les menaces et le code est revu, mis à l’épreuve de tests à données aléatoires et testé par notre équipe RED pour rechercher les violations des limites de sécurité. Microsoft dispose d’un programme de primes pour les bogues qui récompense la découverte de vulnérabilités pertinentes dans les versions de produit éligibles pour Microsoft Hyper-V. Les conseils DATIVE pour éviter des attaques de ce type : Mettre en place des mesures de sécurité supplémentaires telles que des règles de pare-feu dédié, bloquer les ports non utilisés… Désactiver le service SLP jusqu’à la réalisation du patch de sécurité. Réaliser un inventaire (matériels et logiciels). Effectuer des sauvegardes régulières. Mettre à jour les correctifs de sécurité le plus tôt possible. S’inscrire à un service de suivi de vulnérabilités.