Ces contrôles de sécurité fournissent un ensemble de lignes de base des meilleures pratiques de conception système de vSphere.

Éliminer les plug-ins vCenter Server tiers

Réduisez ou supprimez les plug-ins vCenter Server tiers.

L'installation de plug-ins et d'autres connexions croisées tierces entre systèmes peut éroder les limites entre différents systèmes d'infrastructure, offrant ainsi la possibilité aux pirates qui ont compromis un système de se déplacer ultérieurement vers un autre. Le couplage étroit d'autres systèmes à vSphere crée souvent également des obstacles à l'application de correctifs et à des mises à niveau en temps opportun. Assurez-vous que les plug-ins ou modules complémentaires tiers des composants vSphere créent de la valeur. Si vous choisissez d'utiliser des plug-ins plutôt que des consoles de gestion individuelles, assurez-vous que leur utilisation compense les risques qu'ils créent.

Prudence avec les interfaces de gestion de l'infrastructure

Soyez prudent lorsque vous connectez des interfaces de gestion de l'infrastructure à des sources d'authentification et d'autorisation à usage général.

Les annuaires d'entreprise centralisés sont des cibles pour les pirates en raison de leur rôle dans l'autorisation au sein d'une entreprise. Un pirate peut se déplacer librement à l'intérieur d'une organisation une fois que cet annuaire est compromis. La connexion de l'infrastructure informatique à des annuaires centralisés s'est avérée un risque considérable pour les attaques de ransomware et autres. Isolez l'authentification et l'autorisation de tous les systèmes d'infrastructure.

Pour ESXi :

  • Effectuer la gestion de tous les hôtes via vCenter Server
  • Désactiver le ESXi Shell
  • Placer ESXi en mode de verrouillage normal
  • Définir le mot de passe racine ESXi sur un mot de passe complexe

Activé vSphere Distributed Resource Scheduler

Activez vSphere Distributed Resource Scheduler (DRS) en mode entièrement automatisé.

vSphere DRS utilise vMotion pour déplacer des charges de travail entre des hôtes physiques afin d'assurer les performances et la disponibilité. Le mode entièrement automatisé garantit que le vSphere Lifecycle Manager peut fonctionner avec DRS pour activer les opérations d'application de correctifs et de mise à jour.

Si des mappages spécifiques de VM à hôte sont nécessaires, utilisez des règles DRS. Dans la mesure du possible, utilisez la forme « devrait » au lieu de « doit » afin de pouvoir suspendre temporairement la règle lors de l'application de correctifs et de la récupération de la haute disponibilité.

Activer vSphere High Availability

vSphere high availability (HA) redémarre les charges de travail sur d'autres hôtes ESXi d'un cluster si un hôte ESXi échoue soudainement. Assurez-vous que les paramètres de HA sont configurés correctement pour votre environnement.

Activer la compatibilité améliorée de vMotion

vSphere enhanced vMotion Compatibility (EVC) garantit que les charges de travail peuvent être migrées en direct à l'aide de vMotion sur différents hôtes ESXi d'un cluster qui exécutent différentes générations de CPU. EVC aide également dans les situations de vulnérabilités de CPU, où de nouvelles instructions de microcode peuvent être introduites aux CPU, ce qui les rend temporairement incompatibles les uns avec les autres.

Protéger les systèmes contre la falsification

Assurez-vous que les hôtes ESXi et les composants de stockage et de mise en réseau associés sont protégés contre la falsification, l'accès non autorisé et la suppression non autorisée. De plus, protégez les hôtes des dommages causés par les facteurs environnementaux tels que les inondations, les températures extrêmes (basses ou élevées) et la poussière et les débris.

L'utilisation de fonctionnalités de sécurité, telles que vSphere Native Key Provider et la persistance de clé ESXi, peut entraîner le stockage local du matériel sécurisé sur des hôtes ESXi, ce qui permet aux pirates de démarrer et de déverrouiller des clusters protégés autrement. Il est important de prendre en compte la sécurité physique et les menaces appropriées, comme le vol.

Au-delà du vol, avoir l'esprit de sécurité implique également de vous poser, ainsi qu'à votre organisation, des questions telles que :

  • Qu'est-ce qui pourrait mal se passer ?
  • Comment pourrais-je savoir si quelque chose s'est mal passé ?

Ces questions prennent une importance supplémentaire lorsqu'il s'agit d'emplacements de centres de données et d'installations de colocalisation sans personnel. En ce qui concerne les centres de données et les configurations en rack, posez les questions suivantes :

  • Les portes du centre de données se ferment-elles automatiquement et se verrouillent-elles correctement ?
  • Si les portes étaient laissées entrouvertes, y aurait-il une alerte proactive ?
  • Si les portes de votre rack sont verrouillées, est-il toujours possible d'atteindre le rack depuis le côté ou le dessus et de déconnecter un câble ? Une personne non autorisée peut-elle connecter un câble à un commutateur réseau ?
  • Est-il possible de supprimer un périphérique, comme un périphérique de stockage ou même un serveur entier ? Que se passerait-il dans un tel scénario ?

Autres questions à poser :

  • Quelqu'un peut-il glaner des informations sur votre environnement ou votre entreprise à partir des informations affichées sur les serveurs, telles que les panneaux LCD ou les consoles ?
  • Si ces affichages d'informations sont inactifs, peuvent-ils être déclenchés de l'extérieur du rack, par exemple, à l'aide d'un fil métallique rigide ?
  • Existe-t-il d'autres boutons, tels que le bouton d'alimentation, qui peuvent être poussés pour créer une interruption de service pour votre entreprise ?

Enfin, demandez-vous s'il existe d'autres menaces physiques, telles que la possibilité d'inondation, de gel ou de chaleur élevée, ou la poussière et les débris de l'environnement, qui affecteraient la disponibilité ?

Nommer les objets vSphere de manière descriptive

Veillez à nommer les objets vSphere de manière descriptive, en modifiant les noms d'objets par défaut pour garantir l'exactitude et réduire la confusion.

Utilisez de bonnes pratiques de dénomination pour les objets vSphere, en modifiant les noms par défaut, tels que « Centre de données », « Banque de données vSAN », « DSwitch », « Réseau de VM », etc., pour inclure des informations supplémentaires. Cela permet d'améliorer la précision et de réduire les erreurs lors du développement, de la mise en œuvre et de l'audit des stratégies de sécurité et des processus opérationnels.

Les groupes de ports utilisant le balisage VLAN 802.1Q peuvent inclure le numéro de VLAN. Les centres de données et les noms de cluster peuvent refléter des emplacements et des objectifs. Les noms des banques de données et des commutateurs virtuels distribués peuvent refléter les noms de centre de données et de cluster auxquels ils sont attachés. Les noms de fournisseurs de clés sont particulièrement importants, en particulier lors de la protection de machines virtuelles chiffrées avec la réplication vers d'autres sites. Veillez à éviter les « collisions de noms » potentielles avec des objets présents dans d'autres centres de données et clusters.

Certaines organisations ne nomment pas les systèmes avec des identifiants d'emplacement physique, tels que des adresses postales, préférant masquer l'emplacement physique des centres de données en utilisant des termes tels que « Site A », « Site B », etc. Cela est également utile si des sites sont déplacés, ce qui évite d'avoir à tout renommer ou à supporter des informations inexactes.

Lorsque vous décidez d'un schéma d'attribution de nom, gardez à l'esprit que de nombreux objets peuvent avoir des propriétés similaires. Par exemple, deux groupes de ports peuvent avoir le même VLAN attribué, mais des règles de filtrage et de balisage du trafic différentes. L'incorporation d'un nom de projet ou d'une brève description dans le nom peut être utile pour distinguer des objets de ce type.

Enfin, tenez compte de l'automatisation lors du développement d'un schéma d'attribution de nom. Les noms qui peuvent être dérivés par programmation sont souvent utiles lors de l'écriture de scripts et de l'automatisation des tâches.

Isoler les interfaces de gestion de l'infrastructure

Assurez-vous que les interfaces de gestion de l'infrastructure informatique sont isolées sur leur propre segment de réseau ou dans le cadre d'un réseau de gestion isolé.

Assurez-vous que toutes les interfaces de gestion configurées pour les composants de virtualisation se trouvent sur un segment de réseau (VLAN, etc.) dédié uniquement à la gestion de la virtualisation, sans charges de travail et systèmes non liés. Assurez-vous que les interfaces de gestion sont contrôlées à l'aide de contrôles de sécurité du périmètre de sorte que seuls les administrateurs vSphere autorisés puissent accéder à ces interfaces à partir de stations de travail autorisées.

Certaines conceptions de système mettent vCenter Server et d'autres outils de gestion sur leurs propres segments de réseau, isolés d'ESXi, car ils offrent une meilleure surveillance de ces systèmes. D'autres conceptions mettent vCenter Server dans la gestion d'ESXi en raison de la relation entre les deux produits et de la possibilité d'erreurs de configuration de pare-feu ou de pannes interrompant le service. Quel que soit la conception que vous choisissez, faites-le judicieusement.

Utiliser vMotion correctement

Assurez-vous que vMotion utilise le chiffrement des données en transit (défini sur « Requis » pour les machines virtuelles) ou que les interfaces réseau VMkernel utilisées pour vMotion sont isolées sur leurs propres segments de réseau disposant de contrôles de périmètre.

vMotion et Storage vMotion copient des données de stockage et de mémoire de machine virtuelle, respectivement, sur le réseau. Le chiffrement des données en transit garantit la confidentialité. L'isolation vers un segment de réseau dédié avec des contrôles de périmètre appropriés peut ajouter une défense en profondeur et permettre également la gestion du trafic réseau.

Comme toutes les formes de chiffrement, le chiffrement vMotion entraîne une perte de performances, mais ce changement de performances se produit sur le processus vMotion en arrière-plan et n'affecte pas le fonctionnement de la machine virtuelle.

Utiliser vSAN correctement

Assurez-vous que vSAN utilise le chiffrement des données en transit ou que les interfaces réseau VMkernel utilisées pour vSAN sont isolées sur leurs propres segments de réseau disposant de contrôles de périmètre.

vSAN dispose d'un chiffrement des données en transit qui permet de maintenir la confidentialité à mesure que les nœuds vSAN communiquent. Comme pour de nombreux contrôles de sécurité, il y a un compromis avec les performances. Surveillez la latence et les performances du stockage à mesure que le chiffrement des données en transit est activé. Les organisations qui n'activent pas ou ne peuvent pas activer le chiffrement des données en transit vSAN doivent isoler le trafic réseau sur un segment de réseau dédié avec des contrôles de périmètre appropriés.

Mettre Network I/O Control

Assurez-vous que vous disposez d'une résilience au déni de service réseau en activant Network I/O Control (NIOC).

vSphere Network I/O Control (NIOC) est une technologie de gestion du trafic qui offre une qualité de service au niveau de l'hyperviseur, ce qui améliore les performances du réseau en hiérarchisant les ressources dans les environnements de cloud à locataires multiples et de charge de travail partagée. Intégré à vSphere Distributed Switch (vDS), NIOC partitionne la bande passante des adaptateurs réseau en « pools de ressources réseau » qui correspondent à différents types de trafic, tels que vMotion et le trafic de gestion. L'utilisation de NIOC permet aux utilisateurs d'allouer des partages, des limites et des réservations à ces pools.

NIOC préserve la disponibilité du réseau pour les services essentiels et empêche la congestion en limitant le trafic moins critique. Cela est possible en activant la création de stratégies de contrôle réseau selon les besoins de l'entreprise, en garantissant l'isolation du type de trafic et en autorisant la réallocation dynamique des ressources en fonction de la priorité et de l'utilisation.

Ne pas configurer les VLAN réservés par le fournisseur

Assurez-vous que les liaisons montantes du commutateur physique des hôtes ESXi ne sont pas configurées avec des VLAN réservés par le fournisseur.

Certains fournisseurs de réseau réservent des ID de VLAN particuliers pour une utilisation interne ou spécifique. Assurez-vous que vos configurations réseau vSphere n'incluent pas ces valeurs.

Configurer les liaisons montantes ESXi en tant que ports d'accès

Assurez-vous que les liaisons montantes du commutateur physique des hôtes ESXi sont configurées en tant que « ports d'accès » attribués à un seul VLAN ou en tant que jonctions VLAN 802.1Q balisées sans VLAN natif. Assurez-vous que les groupes de ports vSphere n'autorisent pas l'accès au VLAN 1 ou aux VLAN natifs non balisés.

Les connexions réseau qui disposent d'un VLAN « natif » configuré pour accepter le trafic non balisé, ou qui ont accès au VLAN 1, peuvent offrir aux pirates la possibilité de concevoir des paquets spécialisés qui anéantissent les contrôles de sécurité réseau. Le VLAN 1 est souvent utilisé par défaut pour la gestion du réseau et les communications et doit être isolé des charges de travail. Assurez-vous que les groupes de ports ne sont pas configurés pour accéder aux VLAN natifs. Assurez-vous que les ports de jonction VLAN sont configurés avec des définitions spécifiques de VLAN (pas « tous »). Enfin, assurez-vous que les groupes de ports sont correctement configurés afin que les pirates ne puissent pas utiliser un environnement virtualisé pour contourner les contrôles de sécurité réseau.

Configurer correctement les connexions de l'infrastructure de stockage

Assurez-vous que les connexions de l'infrastructure de stockage utilisent le chiffrement des données en transit ou sont isolées sur leurs propres segments de réseau ou SAN disposant de contrôles de périmètre.

La protection des données de stockage en transit contribue à garantir la confidentialité des données. Le chiffrement n'est pas une option pour de nombreuses technologies de stockage, souvent en raison de problèmes de disponibilité ou de performances. Dans ces cas, l'isolation à un segment de réseau dédié avec les contrôles de périmètre appropriés peut constituer un contrôle de compensation efficace et peut ajouter une défense en profondeur.

Utiliser le masquage des LUN sur les systèmes de stockage

Assurez-vous que les systèmes de stockage utilisent le masquage des LUN, le zonage et d'autres techniques de sécurité côté stockage pour s'assurer que les allocations de stockage ne sont visibles que par le cluster vSphere dans lequel elles doivent être utilisées.

Le masquage des LUN sur le contrôleur de stockage et le zonage SAN permettent de s'assurer que le trafic de stockage n'est pas visible par les hôtes non autorisés et que les hôtes non autorisés ne peuvent pas monter les banques de données, en contournant d'autres contrôles de sécurité.

Limiter les connexions aux systèmes autorisés

Envisagez d'utiliser le pare-feu vCenter Server Appliance pour limiter les connexions aux systèmes et administrateurs autorisés.

Le vCenter Server Appliance contient un pare-feu de base que vous pouvez utiliser pour limiter les connexions entrantes à vCenter Server. Il peut s'agir d'une couche efficace de défense en profondeur en conjonction avec les contrôles de sécurité du périmètre.

Comme toujours, avant d'ajouter des règles pour bloquer les connexions, assurez-vous que des règles sont en place pour autoriser l'accès depuis des postes de travail administratifs.

Ne pas stocker les clés de chiffrement sur les hôtes ESXi sans sécuriser l'accès physique

L'environnement ne doit pas stocker de clés de chiffrement sur des hôtes ESXi sans également sécuriser l'accès physique aux hôtes.

Pour éviter les boucles de dépendance, vSphere Native Key Provider stocke les clés de déchiffrement directement sur les hôtes ESXi, dans un module de plateforme sécurisée (TPM) ou dans le cadre de la configuration d'ESXi chiffrée. Cependant, si vous ne sécurisez pas physiquement un hôte et qu'un pirate vole l'hôte, le pirate possède les moyens de déverrouiller et d'exécuter des charges de travail chiffrées. Par conséquent, il est essentiel de garantir la sécurité physique (voir Protéger les systèmes contre la falsification) ou d'opter pour l'utilisation d'un fournisseur de clés standard (voir Qu'est-ce qu'un fournisseur de clés standard ?) qui inclut des contrôles de sécurité réseau supplémentaires.

Utiliser des périphériques persistants, non-SD et non USB correctement dimensionnés pour les volumes de démarrage ESXi

L'environnement doit utiliser des périphériques persistants, non-SD et non USB pour les volumes de démarrage ESXi.

La mémoire Flash est un composant qui s'use avec le temps, chaque écriture de données raccourcissant sa durée de vie. Les disques SSD et les périphériques NVMe disposent de fonctionnalités intégrées pour réduire cette usure, les rendant ainsi plus fiables. Cependant, les cartes SD et la plupart des lecteurs flash USB n'ont pas ces fonctionnalités et peuvent développer des problèmes de fiabilité, tels que des secteurs défectueux, souvent sans aucun signe évident.

Pour réduire l'usure et faire en sorte que les périphériques SD et USB durent plus longtemps, lorsque vous installez ESXi sur ces périphériques, vous pouvez enregistrer des journaux d'audit et système sur un disque RAM au lieu d'écrire constamment sur le périphérique. Cela signifie que vous devez configurer de nouveaux emplacements de stockage à long terme pour ces journaux et modifier la sortie de journal pour accéder à ces nouveaux emplacements.

Le choix d'un périphérique de démarrage fiable supprime ces étapes supplémentaires et permet à ESXi de réussir automatiquement les audits de sécurité.

Configurer correctement la cible iSCSI vSAN

Assurez-vous que la cible iSCSI vSAN utilise ses propres interfaces réseau VMkernel, isolées sur son propre segment de réseau et utilisant des contrôles de périmètre distincts à l'aide du filtrage et du balisage du trafic des groupes de ports distribués, de NSX ou de contrôles de sécurité réseau externes.

Étant donné que les clients cibles iSCSI sont externes au cluster, isolez-les sur leurs propres interfaces réseau. De cette manière, vous pouvez restreindre séparément d'autres communications réseau internes uniquement. L'isolation de ce type permet également de diagnostiquer et de gérer les performances.