¶ Importance
Par défaut, les composants de vSphere sont sécurisés à l’aide de certificats, d’autorisations, du contrôle d’accès, et de la conformité aux normes de sécurité.
Vous pouvez renforcer davantage la sécurité de votre environnement vSphere contre les menaces en configurant les paramètres des systèmes vCenter, des hôtes ESXi, des machines virtuelles (VMs) et du réseau vSphere.
¶ Leçons du module
- Sécuriser vSphere
- Configurer l’accès et l’authentification des hôtes ESXi
- vSphere avec authentification Single Sign-On (SSO) et LDAP
- Fédération d’identité vCenter
¶ Leçon 1 : Sécuriser vSphere
¶ Objectifs d’apprentissage
- Expliquer l’importance du Guide de configuration de sécurité vSphere
- Identifier les recommandations pour la sécurité de vCenter
- Reconnaître les stratégies de sécurisation du réseau de gestion vSphere
- Identifier les recommandations pour la sécurité des hôtes ESXi
- Reconnaître les directives pour la protection générale des machines virtuelles (VM) et des systèmes d’exploitation invités
¶ À propos de la sécurisation de vSphere
La sécurisation de vSphere implique plusieurs aspects de la sécurité pour le système vCenter, les hôtes ESXi, les machines virtuelles (VM) et le réseau vSphere.
Le site Web de VMware propose plusieurs ressources liées à la sécurité.
Les avis de sécurité VMware fournissent des informations sur les vulnérabilités de sécurité identifiées dans les produits VMware.
Vous pouvez vous inscrire pour recevoir par e-mail les nouveaux avis et les mises à jour.
| Sujet | Ressource |
|---|---|
| Sécurité vSphere | https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-esxi-vcenter-80-security-guide.pdf |
| Politique de sécurité VMware | https://www.vmware.com/security/ |
| Réponse de sécurité d’entreprise | https://www.vmware.com/support/policies/security_response.html |
| Avis de sécurité VMware | https://www.vmware.com/security/advisories.html |
¶ À propos du Guide de configuration de sécurité vSphere
Le Guide de configuration de sécurité vSphere vous aide à configurer votre environnement vSphere selon les meilleures pratiques de sécurité.
Au fil du temps, vSphere est devenu plus sécurisé par défaut.
Le Guide de configuration de sécurité vSphere constitue la référence de base pour le renforcement de la sécurité de VMware vSphere lui-même, ainsi que le noyau des meilleures pratiques de sécurité VMware.
Il sert depuis longtemps de guide pour les administrateurs vSphere souhaitant protéger leur infrastructure.
Pour obtenir la version la plus récente du Guide de configuration de sécurité vSphere, consultez les VMware Security Hardening Guides à l’adresse : https://www.vmware.com/security/hardening-guides.html
Effectuez un audit quotidien à l’aide du Guide de configuration de sécurité vSphere pour identifier les vulnérabilités de sécurité dans votre environnement vSphere.
¶ Contrôle de l’accès aux systèmes vCenter
Contrôlez strictement l’accès aux composants vCenter afin d’améliorer la sécurité du système.
Le contrôle d’accès à vCenter inclut les meilleures pratiques suivantes :
- Utilisez des comptes nominatifs et accordez le rôle d’administrateur uniquement aux comptes qui en ont réellement besoin.
- Surveillez les privilèges des utilisateurs administrateurs de vCenter.
- Limitez l’accès au navigateur de datastore aux utilisateurs qui ont réellement besoin de ce privilège.
- Indiquez aux utilisateurs du client vSphere de ne jamais ignorer les avertissements de vérification des certificats.
- Les rôles personnalisés doivent être configurés pour garantir que les utilisateurs ne disposent que des privilèges nécessaires.
- Définissez la politique de mot de passe de vCenter.
- Limitez la connectivité réseau de vCenter en plaçant le système vCenter uniquement sur le réseau de gestion.
Le compte root de vCenter ne dispose pas de droits d’administration.
À la place, vous attribuez le rôle d’administrateur vCenter à un nombre limité de comptes administrateurs nominatifs.
Attribuez le privilège “Browse Datastore” uniquement aux utilisateurs ou groupes qui en ont besoin.
Les utilisateurs disposant de ce privilège peuvent afficher, télécharger ou téléverser des fichiers sur les datastores associés au déploiement vSphere via le client vSphere.
Vérifiez les certificats du client vSphere.
Sans vérification de certificat, l’utilisateur pourrait être exposé à des attaques de type “man-in-the-middle”.
Par défaut, vCenter change automatiquement le mot de passe “vpxuser” tous les 30 jours.
Vous pouvez modifier cette fréquence dans le client vSphere.
Assurez-vous que le trafic de gestion vSphere se trouve sur un réseau restreint.
Pour la liste complète des meilleures pratiques vCenter, consultez ce lien : vSphere Security
¶ Contrôle d’accès à vCenter
Pour sécuriser l’accès à vCenter Photon OS, appliquez les meilleures pratiques suivantes :
- N’autorisez pas les utilisateurs à se connecter directement à l’instance vCenter.
- Autorisez l’accès uniquement aux utilisateurs ayant des tâches légitimes à effectuer sur vCenter.
- Contrôlez l’accès via SSH et la ligne de commande.
Les utilisateurs pouvant se connecter à vCenter Photon OS avec des privilèges root peuvent causer des dommages, intentionnellement ou non, en modifiant des paramètres ou des processus.
Ces utilisateurs ont également un accès potentiel aux identifiants vCenter, tels que les certificats SSL.
Envisagez d’auditer régulièrement les événements de connexion afin de vous assurer que seuls les utilisateurs autorisés accèdent à vCenter.
Utilisez la VAMI (vCenter Appliance Management Interface) pour contrôler l’accès à SSH, DCUI (Direct Console User Interface), Appliance Shell et Bash Shell sur une instance vCenter Appliance.
¶ Sécurisation de vCenter
Assurez-vous que la mise en réseau de vCenter est sécurisée :
- Configurez le protocole NTP (Network Time Protocol) pour garantir que tous les systèmes utilisent la même source temporelle relative.
- Restreignez l’accès uniquement aux composants nécessaires à la communication avec l’appliance vCenter.
Votre instance vCenter doit être installée avec les dernières mises à jour et correctifs de sécurité :
- VMware publie régulièrement des correctifs pour vCenter.
- Téléchargez les images ISO des correctifs à partir de : https://customerconnect.vmware.com/patch
Suivez les meilleures pratiques de sécurité pour les instances de vCenter Appliance :
- Assurez-vous que tous les systèmes utilisent la même source temporelle.
Les systèmes synchronisés sont essentiels pour la validation des certificats.
Le protocole NTP facilite également le suivi d’un intrus dans les fichiers journaux. - Limitez l’accès aux seuls composants nécessaires à la communication avec l’appliance vCenter.
Le blocage de l’accès depuis des systèmes non nécessaires réduit les risques d’attaques contre le système d’exploitation.
¶ Sécurisation des réseaux de gestion vSphere
La sécurisation des réseaux de gestion vSphere ressemble à la sécurisation des réseaux physiques, mais présente certaines caractéristiques particulières :
- Sécurisez les Switches physiques auxquels les hôtes ESXi sont connectés afin d’empêcher les attaquants d’accéder à l’hôte et à ses machines virtuelles.
- Vous pouvez sécuriser les ports des Switches standards et les Switches distribués vSphere à l’aide de politiques de sécurité :
Refuser le mode promiscuité, Refuser les modifications d’adresses MAC et Refuser les transmissions falsifiées. - Vous pouvez utiliser des réseaux physiquement isolés. Si l’isolation physique n’est pas possible, utilisez des VLAN.
Créez et installez l’instance vCenter sur un réseau de gestion dès que possible.
Évitez de placer le système vCenter sur un réseau de production ou de stockage, ou sur un réseau ayant un accès à Internet.
Les systèmes vCenter nécessitent une connectivité réseau avec les systèmes suivants :
- Hôtes ESXi
- Autres systèmes vCenter dans le même domaine Single Sign-On (SSO)
- Services d’infrastructure tels que DNS, AD et NTP
- Autres systèmes exécutant des composants essentiels au bon fonctionnement du système vCenter
- Les machines à partir desquelles le vSphere Client est accessible
Pour une meilleure protection de vos hôtes, assurez-vous que les ports des Switches physiques sont configurés avec le protocole Spanning Tree désactivé et que l’option nonnegotiate est activée pour les liaisons trunk entre les Switches physiques externes et les Switches virtuels en mode Virtual Switch Tagging.
¶ Sécurisation des hôtes ESXi
Pour sécuriser les hôtes ESXi, VMware limite les paramètres et configurations de vSphere.
Considérez ces lignes directrices pour maintenir la sécurité des hôtes ESXi :
- Gérer l’accès à l’hôte ESXi :
— Évitez d’utiliser le compte utilisateur root.
— Utilisez AD pour gérer les utilisateurs au lieu de maintenir des comptes locaux.
— Utilisez toujours le vSphere Client pour administrer les hôtes ESXi gérés par vCenter.
— Utilisez uniquement le VMware Host Client pour administrer les hôtes ESXi lorsque vCenter n’est pas disponible. - Gérer l’utilisation des services et fonctions de sécurité :
— Gardez le pare-feu de l’hôte ESXi activé.
— Laissez les services SSH et vSphere ESXi Shell désactivés.
— Activez le mode lockdown pour renforcer davantage la sécurité des hôtes ESXi.
Créez au moins un compte utilisateur nommé et attribuez-lui des privilèges administratifs complets. Ce compte peut être soit un compte local, soit un compte de domaine appartenant au groupe de domaine ESX Admins. Utilisez ce compte plutôt que le compte root. Définissez un mot de passe complexe pour le compte root et limitez son utilisation.
Vous pouvez configurer les hôtes ESXi pour utiliser AD afin de gérer les utilisateurs. L’utilisation d’AD permet d’éviter la gestion de comptes utilisateurs locaux sur chaque hôte ESXi.
ESXi comprend un pare-feu activé par défaut. Vous pouvez gérer les paramètres du pare-feu en utilisant l’interface Security Profiles dans le vSphere Client. De nombreux paramètres de sécurité essentiels des hôtes ESXi peuvent être personnalisés via ces profils de sécurité. L’utilisation des profils de sécurité est particulièrement utile pour la gestion d’un seul hôte.
Vous pouvez utiliser SSH pour restreindre, contrôler et sécuriser l’accès à un hôte ESXi. Par défaut, les accès SSH et vSphere ESXi Shell sont désactivés sur les hôtes ESXi.
Le mode lockdown est désactivé par défaut. Lorsque vous utilisez le mode lockdown, la gestion des hôtes ESXi ne peut être effectuée que via vCenter.
Vous gérez les certificats depuis le vSphere Client. Les hôtes ESXi peuvent utiliser VMware CA, une autorité de certification personnalisée ou le mode thumbprint.
Pour obtenir la liste complète des meilleures pratiques de sécurité pour l’hyperviseur ESXi et les hôtes ESXi, consultez vSphere Security à l’adresse suivante : https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-esxi-vcenter-80-security-guide.pdf
¶ Vue d’ensemble de la protection des machines virtuelles (VMs)
Appliquez les mêmes mesures de sécurité à une VM que vous le feriez pour un serveur physique équivalent :
- Maintenez toutes les mesures de sécurité à jour et corrigées.
- Installez des logiciels antivirus et antimalware.
- Supprimez le matériel virtuel inutile dans la VM et désactivez les fonctions non nécessaires dans le système d’exploitation invité.
- Assurez-vous que les opérations de copie et de collage entre les systèmes d’exploitation invités et la console distante sont désactivées.
- Restreignez les utilisateurs afin qu’ils ne puissent pas exécuter de commandes sur une VM.
- Utilisez des modèles (templates) pour déployer des VMs.
- Maintenez le système d’exploitation à jour avec les derniers correctifs.
L’utilisation de modèles pour déployer des VMs réduit le risque de mauvaise configuration. Toutes les VMs sont créées avec un niveau de sécurité de référence connu.
¶ Revue des objectifs d’apprentissage
- Expliquer l’importance du vSphere Security Configuration Guide
- Identifier les recommandations pour la sécurité de vCenter
- Reconnaître les stratégies de sécurisation du réseau de gestion vSphere
- Identifier les recommandations pour la sécurité des hôtes ESXi
- Reconnaître les lignes directrices pour la protection générale des VMs et des systèmes d’exploitation invités
¶ Leçon 2 : Configuration de l’accès et de l’authentification des hôtes ESXi
¶ Objectifs d’apprentissage
- Configurer le pare-feu ESXi
- Activer et désactiver le lockdown mode sur un hôte ESXi
- Configurer la connexion des utilisateurs pour qu’ils s’authentifient auprès des services d’annuaire
¶ À propos des propriétés de sécurité des hôtes ESXi
L’architecture de l’hyperviseur ESXi comprend de nombreuses fonctionnalités de sécurité intégrées, telles que l’isolation du processeur (CPU), l’isolation de la mémoire, le pare-feu et l’isolation des périphériques.
Vous pouvez ouvrir et fermer des ports sur le pare-feu, activer et désactiver des services tels que SSH, et configurer le lockdown mode.
Un hôte ESXi est protégé par un pare-feu. Vous pouvez ouvrir des ports pour le trafic entrant et sortant selon les besoins, mais il est recommandé de restreindre l’accès aux services et aux ports.
L’utilisation du lockdown mode ESXi et la limitation de l’accès à vSphere ESXi Shell peuvent également contribuer à un environnement plus sécurisé.
¶ Configuration du pare-feu ESXi
Pour minimiser le risque d’une attaque via l’interface de gestion, ESXi inclut un pare-feu sans état (stateless), orienté service. Vous pouvez définir les adresses IP ou les plages d’adresses IP autorisées.
Les pare-feux contrôlent l’accès aux appareils situés dans leur périmètre en fermant tous les canaux de communication, sauf ceux que l’administrateur désigne explicitement ou implicitement comme autorisés.
Les chemins, ou ports, que les administrateurs ouvrent dans le pare-feu permettent le trafic entre les appareils situés de part et d’autre du pare-feu.
Avec le moteur du pare-feu ESXi, les ensembles de règles définissent les règles de ports pour chaque service.
Pour les hôtes distants, la définition d’adresses IP ou de plages d’adresses IP permet l’accès à chaque service.
Vous pouvez configurer le pare-feu ESXi à l’aide du vSphere Client ou de vSphere CLI.
Vous pouvez également gérer le pare-feu en ligne de commande en utilisant l’espace de noms : esxcli network firewall
¶ Configuration des services ESXi
Vous pouvez configurer les services pour les démarrer, les arrêter ou les redémarrer sur un hôte ESXi.
Vous contrôlez également si les services démarrent et s’arrêtent avec l’hôte ou doivent être démarrés manuellement.
Dans cet exemple, les services vSphere ESXi Shell et SSH sont arrêtés.
Ces services sont arrêtés par défaut.
¶ À propos du mode Lockdown
Pour renforcer la sécurité de vos hôtes ESXi, vous pouvez placer vos hôtes en mode Lockdown.
En mode Lockdown, l’accès direct à l’hôte ESXi est soit restreint, soit refusé.
Les modes disponibles sont :
- Normal
- Strict
Par défaut, le mode Lockdown est désactivé.
Vous pouvez activer le mode Lockdown via le vSphere Client, soit au moment où l’hôte ESXi est ajouté à l’inventaire, soit ultérieurement en modifiant le Security Profile de l’hôte.
Lorsque vous activez le mode Lockdown (normal ou strict), les utilisateurs ne peuvent pas exécuter d’opérations directement sur l’hôte.
Toute la gestion doit être effectuée via vCenter en utilisant le vSphere Client.
Vous pouvez activer le mode Lockdown :
- Lors de l’ajout de l’hôte au vCenter
- En utilisant l’interface DCUI (Direct Console User Interface) – uniquement pour activer ou désactiver le mode Normal
- En utilisant le profil de sécurité de l’hôte dans le vSphere Client
En mode Lockdown, toutes les opérations sur l’hôte doivent être réalisées via vCenter.
L’hôte ne peut pas être accessible directement par le VMware Host Client ou via l’ESXi Shell (en local ou à distance).
¶ Comportement du mode Lockdown normal
Lorsque le mode Lockdown normal est activé sur un hôte ESXi :
- L’hôte ne peut être accessible que via vCenter, par exemple à l’aide du vSphere Client.
- L’accès à la DCUI (Direct Console User Interface) est bloqué pour tous les utilisateurs, à l’exception de :
— Les utilisateurs figurant dans la liste des utilisateurs d’exception, mais ils doivent disposer des privilèges d’administrateur.
— Les utilisateurs définis dans le paramètre avancé DCUI.Access :
• Par défaut, l’utilisateur root est défini dans ce paramètre.
• Des utilisateurs non administrateurs peuvent également être définis ici.
• Les utilisateurs non administrateurs peuvent uniquement activer ou désactiver le mode Lockdown. - Si les services vSphere ESXi Shell et SSH sont activés, les utilisateurs disposant de privilèges administrateur et figurant sur la liste des utilisateurs d’exception peuvent se connecter directement à l’hôte via SSH ou le vSphere ESXi Shell local.
En mode Lockdown normal, les utilisateurs définis dans le paramètre avancé DCUI.Access peuvent se connecter via la DCUI.
En figurant sur cette liste, ils disposent d’un accès d’urgence à la DCUI si la connexion à vCenter est perdue. Ces utilisateurs n’ont pas besoin de privilèges administratifs sur l’hôte.
Les utilisateurs DCUI.Access non administrateurs peuvent uniquement activer ou désactiver le mode Lockdown.
¶ Comportement du mode Lockdown strict
Lorsque le mode Lockdown strict est activé sur un hôte ESXi :
- L’hôte ne peut être accessible que via vCenter, par exemple à l’aide du vSphere Client.
- Le service DCUI est désactivé et ne peut pas être démarré. Par conséquent, aucun utilisateur ne peut se connecter à la DCUI.
- Si les services vSphere ESXi Shell et SSH sont activés, les utilisateurs disposant de privilèges administrateur et figurant sur la liste des utilisateurs d’exception peuvent se connecter directement à l’hôte via SSH ou le vSphere ESXi Shell local.
Pour que le mode Lockdown (strict ou normal) constitue une mesure de sécurité efficace, assurez-vous que les services vSphere ESXi Shell et SSH sont désactivés.
Si vCenter n’est pas disponible, le vSphere Client ne l’est pas non plus.
Par conséquent, les hôtes en mode Lockdown strict ne peuvent pas être administrés.
¶ Intégration d’ESXi avec Active Directory
Vous pouvez configurer un hôte ESXi pour qu’il rejoigne un domaine Active Directory (AD) afin de gérer les utilisateurs et les groupes à partir d’une interface unique.
Lorsque l’hôte ESXi est ajouté à AD, le groupe de domaine ‘ESX Admins’ se voit attribuer un accès administratif complet à l’hôte, si ce groupe existe.
Bien que les opérations quotidiennes de gestion de vSphere soient effectuées en étant connecté à vCenter à l’aide du vSphere Client, il arrive que l’utilisateur doive accéder directement à l’hôte ESXi, par exemple pour consulter les fichiers journaux locaux.
Chaque fois que des identifiants sont demandés (par exemple, lors de la connexion directe à l’hôte ESXi avec le VMware Host Client), vous pouvez saisir le nom d’utilisateur et le mot de passe d’un utilisateur appartenant au domaine que l’hôte a rejoint.
L’avantage de ce modèle de gestion des comptes utilisateurs est qu’il permet d’utiliser AD pour gérer les comptes utilisateurs des hôtes ESXi.
Ce modèle est plus simple et plus sûr que la gestion indépendante des comptes sur chaque hôte.
Le seul utilisateur défini localement sur l’hôte ESXi est root.
Le mot de passe root n’est pas lié à un compte AD.
Le mot de passe root initial est généralement défini lors de l’installation d’ESXi, mais il peut être modifié ultérieurement via le VMware Host Client, le vSphere ESXi Shell ou la DCUI.
Vous pouvez créer d’autres groupes de domaine si vous souhaitez accorder des droits administratifs à un sous-ensemble d’hôtes.
Vous attribuez à ce groupe de domaine des droits d’administrateur sur les hôtes concernés, puis ajoutez les utilisateurs du domaine à ce groupe.
¶ Service VMware vSphere Authentication Proxy
Vous pouvez automatiser le processus d’ajout des hôtes ESXi à un domaine AD en utilisant le service vSphere Authentication Proxy.
Ce service permet de prendre en charge l’intégration automatique des hôtes ESXi déployés via Auto Deploy dans un domaine AD, en utilisant un compte disposant de privilèges délégués.
Si vous déployez des hôtes avec Auto Deploy, vous pouvez configurer un hôte de référence pointant vers Authentication Proxy.
Vous pouvez utiliser vSphere Authentication Proxy pour joindre un hôte à un domaine AD sans avoir à ajouter directement cet hôte au domaine.
Une chaîne de confiance est établie entre vSphere Authentication Proxy et l’hôte, ce qui permet à vSphere Authentication Proxy d’ajouter l’hôte au domaine AD.
vSphere Authentication Proxy est particulièrement utile lorsqu’il est utilisé avec vSphere Auto Deploy.
Vous pouvez configurer un hôte de référence pointant vers vSphere Authentication Proxy et créer une règle qui applique le profil de cet hôte de référence à tout hôte ESXi déployé avec vSphere Auto Deploy.
Même si vous utilisez vSphere Authentication Proxy dans un environnement utilisant des certificats — fournis par VMware CA ou des autorités tierces — le processus reste fluide, à condition de suivre les instructions relatives à l’utilisation de certificats personnalisés avec vSphere Auto Deploy.
Le service vSphere Authentication Proxy est disponible sur chaque système vCenter.
Par défaut, ce service n’est pas actif.
Si vous souhaitez utiliser vSphere Authentication Proxy dans votre environnement, vous pouvez démarrer le service depuis l’interface de gestion de l’appliance virtuelle (VAMI) ou depuis la ligne de commande.
¶ Lab 18 : Configuration du Lockdown Mode
Configurez et testez le Lockdown Mode :
- Démarrer le service SSH
- Activer et tester le Lockdown Mode
- Désactiver le Lockdown Mode
- Vérification des connaissances
Retrouvez le lien du Lab en cliquant ici : Lab 18 : Accéder à l'environnement de lab
¶ Revue des objectifs d’apprentissage
- Configurer le pare-feu ESXi
- Activer et désactiver le Lockdown Mode sur un hôte ESXi
- Configurer l’authentification des connexions utilisateurs avec les services d’annuaire
¶ Leçon 3 : vSphere avec Single Sign-On et authentification LDAP
¶ Objectifs d’apprentissage
- Identifier les services utilisés pour vCenter Single Sign-On
- Reconnaître les paramètres de source d’identité LDAP server
- Reconnaître les méthodes d’authentification à deux facteurs sur vCenter
¶ vCenter Single Sign-On
vCenter Single Sign-On est un courtier d’authentification et une infrastructure d’échange de jetons de sécurité.
vCenter SSO émet un jeton lorsqu’un utilisateur s’authentifie.
L’utilisateur peut ensuite utiliser ce jeton pour s’authentifier auprès des services vCenter Server.
¶ Services vCenter Single Sign-On
Pour gérer efficacement vCenter Single Sign-On, il est nécessaire de comprendre les services sous-jacents et leur fonctionnement.
- VMware Directory Service (VMDIR)
- VMware Certificate Authority (VMCA)
- VMware Authentication Framework Daemon (VMAFD)
- Lookup Service (lookupsvc)
- Identity Management Service (vIDM)
¶ VMware Directory Service (VMDIR)
VMware Directory Service (VMDIR) est un référentiel LDAP interne (local) dans vCenter qui contient les identités d’utilisateurs, les groupes et les données de configuration.
Le VMware Directory Service est également utilisé pour la gestion des certificats.
Les fichiers journaux de VMDIR (vmdir) sont situés sur vCenter à l’emplacement /var/log/vmware/vmdir et /var/log/vmware/vmdir/vmdird
¶ VMware Certificate Authority (VMCA)
VMCA inclut le VMware Endpoint Certificate Store (VECS) ainsi que plusieurs autres services d’authentification.
Le VMCA fournit également des certificats aux composants vCenter et aux hôtes ESXi qui utilisent le VMCA comme autorité de certification racine.
VMCA délivre des certificats uniquement aux clients pouvant s’authentifier auprès de vCenter Single Sign-On dans le même domaine.
¶ Lookup Service (lookupsvc)
Le Lookup Service fournit un emplacement centralisé permettant aux services de publier leurs fonctionnalités sous forme de service endpoints.
Les services vCenter et les solutions externes peuvent interroger le Lookup Service afin de répertorier les services et leurs endpoints associés pour des fonctionnalités spécifiques.
¶ Identity Management Service (vIDM)
Le Identity Management Service gère les sources d’identité telles que AD et les services d’annuaire OpenLDAP, ainsi que les requêtes d’authentification STS.
Le vCenter Server Security Token Service (STS) est un service Web qui émet, valide et renouvelle les security tokens.
Les fichiers journaux pour le Identity Management Service (vmware-identity-sts) sont situés sur le vCenter à l’emplacement suivant : /var/log/vmware/sso
¶ VMware Authentication Framework Daemon (VMAFD)
Le VMware Endpoint Certificate Store (VECS) fonctionne dans le cadre du VMware Authentication Framework Daemon (VMAFD).
VECS agit comme un référentiel local (côté client) pour les certificats, les clés privées et d’autres informations de certificat pouvant être stockées dans un keystore.
Il est également possible de gérer explicitement les certificats et les clés dans VECS en utilisant les commandes vecs-cli.
Pour plus d’informations sur les commandes vecs-cli, consultez la documentation : vecs-cli Command Reference
¶ À propos des sources d’identité
Les sources d’identité sont utilisées pour authentifier les utilisateurs qui accèdent à l’environnement vSphere, y compris le vCenter et les hôtes ESXi.
L’ajout d’une source d’identité à vSphere permet de rechercher des comptes d’utilisateurs et d’autres objets au sein de l’annuaire afin d’accorder des autorisations et un accès aux ressources.
Les sources d’identité offrent une gestion centralisée des comptes utilisateurs et de l’authentification, améliorant ainsi la sécurité et réduisant la charge administrative.
¶ Paramètres de la source d’identité du serveur LDAP
Vous pouvez choisir parmi les sources d’identité suivantes sur votre vCenter :
| Source d’identité | Description |
|---|---|
| System Domain | Contient les utilisateurs internes de vCenter Single Sign-On. |
| Local OS (Default) | Tous les utilisateurs du système d’exploitation local. |
| Active Directory over LDAP | vCenter Single Sign-On prend en charge plusieurs sources d’identité Active Directory via LDAP. |
| OpenLDAP | vCenter Single Sign-On prend en charge plusieurs sources d’identité OpenLDAP. |
¶ Sources d’identité pour vCenter avec vCenter Single Sign-On
Vous pouvez utiliser des sources d’identité afin de permettre à Single Sign-On de s’authentifier auprès de domaines externes.
Un domaine est un référentiel d’utilisateurs et de groupes que le serveur vCenter Single Sign-On peut utiliser pour l’authentification des utilisateurs.
À partir de vSphere 7.0 Update 2 et versions ultérieures, vous pouvez activer les Federal Information Processing Standards (FIPS) sur vCenter.
AD over LDAP et IWA ne sont pas pris en charge lorsque FIPS est activé.
Dans ce cas, il faut utiliser la fédération avec un fournisseur d’identité externe lorsque le mode FIPS est actif.
Les données des utilisateurs et des groupes sont stockées dans Active Directory, OpenLDAP, ou localement sur le système d’exploitation de la machine où vCenter Single Sign-On est installé.
Chaque instance de vCenter Single Sign-On possède sa propre source d’identité (par défaut : vsphere.local).
Le nom de ce domaine peut être configuré uniquement lors de l’installation.
Cette source d’identité est interne à vCenter Single Sign-On.
Consultez la documentation suivante pour plus d’informations : Configuring vCenter Single Sign-On Identity Sources
¶ Authentification à deux facteurs vCenter
vCenter permet à un utilisateur de s’authentifier en tant qu’utilisateur d’une source d’identité reconnue par vCenter Single Sign-On, ou en utilisant l’authentification de session Windows.
Il est également possible de s’authentifier à l’aide d’une carte à puce (smart card) — telle qu’une Common Access Card (CAC) basée sur UPN — ou encore en utilisant un jeton RSA SecurID.
¶ Authentification par carte à puce (Smart Card Authentication)
Une carte à puce est une petite carte plastique dotée d’une puce à circuit intégré.
De nombreuses agences gouvernementales et grandes entreprises utilisent des cartes à puce telles que la Common Access Card (CAC) pour renforcer la sécurité de leurs systèmes et se conformer aux réglementations de sécurité.
L’utilisation d’une carte à puce est possible dans des environnements où chaque machine dispose d’un lecteur de carte à puce.
Les pilotes matériels gérant la carte à puce sont généralement préinstallés.
Pour activer l’authentification par carte à puce sur votre vCenter, vous devez :
- Configurer le reverse proxy.
- Activer et configurer l’authentification par carte à puce.
¶ Connexion avec authentification par carte à puce
Lorsque vous vous connectez à votre vCenter, il vous est demandé de vous authentifier à l’aide d’une carte à puce et d’un code PIN, comme suit :
- Lorsque vous insérez la carte à puce dans le lecteur de carte, le navigateur lit les certificats présents sur la carte.
- Le navigateur invite ensuite l’utilisateur à sélectionner un certificat, puis à saisir le code PIN associé à ce certificat.
- vCenter Single Sign-On vérifie si le certificat présent sur la carte à puce est reconnu.
- Si le certificat est reconnu par vCenter Single Sign-On et qu’il n’a pas été révoqué, l’utilisateur est authentifié et peut exécuter les tâches pour lesquelles il dispose des autorisations.
¶ Authentification RSA SecurID
Pour utiliser l’authentification RSA SecurID, votre environnement doit inclure un RSA Authentication Manager correctement configuré.
Si votre vCenter est configuré pour pointer vers le serveur RSA et que RSA SecurID Authentication est activé, les utilisateurs peuvent se connecter en utilisant leur nom d’utilisateur et leur jeton.
Prérequis :
- RSA Authentication Manager version 8.0 ou ultérieure est requis.
- Vérifiez que la source d’identité utilisée par RSA Manager a été ajoutée à vCenter Single Sign-On.
- Vérifiez que le système RSA Authentication Manager peut résoudre le nom d’hôte vCenter, et que le système vCenter peut résoudre le nom d’hôte RSA Authentication Manager.
¶ Revue des objectifs d’apprentissage
- Identifier les services utilisés pour vCenter Single Sign-On.
- Reconnaître les paramètres de la source d’identité du serveur LDAP.
- Reconnaître les méthodes d’authentification à deux facteurs sur vCenter.
¶ Leçon 4 : Fédération d’identité vCenter
¶ Objectifs d’apprentissage
- Décrire la fédération d’identité
- Identifier les cas d’utilisation de la fédération d’identité
- Décrire l’architecture de la fédération d’identité
- Configurer la fédération d’identité
¶ À propos de la fédération du fournisseur d’identité vCenter pour ADFS
vCenter 7.0 a introduit la prise en charge de la fédération du fournisseur d’identité (IDP) pour les Active Directory Federation Services (ADFS).
Lorsque vCenter est configuré pour utiliser un fournisseur d’identité externe (IDP), vCenter SSO est contourné et les informations d’identification de l’utilisateur sont transmises directement du navigateur au fournisseur d’identité externe (IDP).
Dans cette configuration d’authentification fédérée, vCenter ne réalise pas les fonctions suivantes :
- Gestion des informations d’identification de l’utilisateur
- Création du jeton d’identité initial
- Gestion ou mise à jour des informations des utilisateurs et des groupes dans la source d’identité
¶ Cas d’utilisation de la fédération du fournisseur d’identité vCenter
Vous pouvez utiliser un fournisseur d’identité externe pour remplacer vCenter Single Sign-On en tant que fournisseur d’identité (IDP) et activer le Single Sign-On (SSO) au sein d’une infrastructure et d’applications fédérées.
La fédération du fournisseur d’identité vCenter peut être utilisée dans les scénarios suivants :
- Lors de l’utilisation du SSO avec une infrastructure et des applications déjà intégrées à ADFS.
- Pour renforcer la sécurité du centre de données, puisque vCenter ne gère jamais directement les informations d’identification des utilisateurs.
- Lors de l’utilisation de mécanismes d’authentification, tels que l’authentification multifacteur, pris en charge par le fournisseur d’identité externe.
¶ Prérequis pour la fédération du fournisseur d’identité vCenter
vCenter prend en charge ADFS comme fournisseur d’identité externe (IDP).
Exigences ADFS :
- ADFS pour Windows Server 2016 ou version ultérieure doit être déployé.
- ADFS doit être connecté à Active Directory.
- Un groupe d’applications pour vCenter doit être créé dans ADFS dans le cadre du processus de configuration.
- Le certificat du serveur ADFS doit être signé par une autorité de certification approuvée.
vCenter prend en charge un seul fournisseur d’identité externe (une seule source ADFS) — le système d’exploitation local (local OS) et vsphere.local identity source.
Vous ne pouvez pas utiliser plusieurs fournisseurs d’identité externes.
La fédération du fournisseur d’identité vCenter utilise OpenID Connect (OIDC) pour la connexion des utilisateurs à vCenter.
¶ Composants de la fédération du fournisseur d’identité vCenter
La configuration de la fédération du fournisseur d’identité (IDP) de vCenter 7.0 inclut les composants suivants de vSphere et de tiers :
- vCenter
- Un service IDP externe configuré sur vCenter
- Un serveur ADFS et le domaine Microsoft AD associé
- Un groupe d’applications ADFS
- Des groupes et utilisateurs AD disposant d’autorisations sur vCenter
¶ Connexion de l’utilisateur avec le fournisseur d’identité intégré de vCenter
vCenter, vCenter Single Sign-On et Active Directory interagissent pendant le processus de connexion.
L’utilisateur, le client vSphere et les composants internes de vCenter interagissent avec Active Directory comme suit :
-
Connexion de l’utilisateur
L’utilisateur se connecte à vCenter via la page d’accueil habituelle de vCenter. -
Redirection de l’authentification
vCenter redirige la demande d’authentification vers le service vCenter Single Sign-On. -
Demande d’authentification
Si nécessaire, le service vCenter Single Sign-On invite l’utilisateur à se connecter avec ses identifiants Active Directory. -
Authentification de l’utilisateur
Le service vCenter Single Sign-On authentifie l’utilisateur via Active Directory. -
Génération du jeton de sécurité
Le service vCenter Single Sign-On signe tous les jetons avec un certificat de signature, et stocke ce certificat sur le disque.
Le certificat du service lui-même est également enregistré sur le disque. -
Connexion via le jeton
vCenter utilise ensuite le jeton pour connecter l’utilisateur.
¶ Sources d’identité vSphere avec authentification multifacteur (MFA)
Les sources d’identité avec MFA offrent une couche de sécurité supplémentaire pour l’authentification des utilisateurs accédant à l’environnement vSphere.
Pour activer la MFA avec les sources d’identité vSphere, les administrateurs peuvent utiliser des solutions tierces qui s’intègrent à vSphere, telles que :
- RSA SecurID
- Microsoft ADFS
- Okta
Ces solutions nécessitent généralement une configuration supplémentaire pour s’intégrer à vSphere, mais une fois configurées, elles peuvent fournir une couche de sécurité supplémentaire pour l’ensemble de l’environnement vSphere.
¶ Gestion fédérée des identités Okta pour vCenter
vSphere 8 Update 1 étend la prise en charge de vCenter pour les fournisseurs d’identité tiers vers Okta, en plus des Active Directory Federation Services (ADFS).
- Les administrateurs utilisant Okta peuvent se connecter une seule fois pour vCenter et NSX Manager.
- Cette fonctionnalité améliore à la fois l’efficacité et la sécurité de l’environnement.
¶ Prérequis Okta
Exigences Okta :
- Disposer d’un espace de domaine dédié, par exemple : https://your-company.okta.com
- Vous devez créer les applications Okta suivantes pour effectuer les connexions OIDC et gérer les autorisations des utilisateurs et des groupes :
- Une application native Okta avec OpenID Connect comme méthode de connexion
- Un système pour Cross-domain Identity Management (SCIM) 2.0 avec un OAuth 2.0 Bearer Token
Exigences de connectivité Okta :
- vCenter doit pouvoir se connecter au point de découverte Okta, ainsi qu’aux points de terminaison d’autorisation, de jeton, de JWKS, et à tous les autres points de terminaison annoncés dans les métadonnées du point de découverte.
- Okta doit également pouvoir se connecter à vCenter pour envoyer les données des utilisateurs et des groupes nécessaires au provisionnement SCIM.
Référence documentation VMware :
Configure vCenter Server Identity Provider Federation for Okta
https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-authentication/GUID-88933505-9299-49FB-9C30-56E43683099B.html
¶ Prérequis vCenter
Exigences du serveur vCenter :
- vSphere 8.0 Update 1
- Sur le vCenter où vous souhaitez créer la source d’identité Okta, vérifiez que les VMware Identity Services sont activés.
Exigences de privilèges vSphere :
- Vous devez disposer du privilège permettant de créer, de mettre à jour ou de supprimer un vCenter Identity Provider requis pour l’authentification fédérée.
¶ Configurer la fédération du fournisseur d’identité vCenter pour Okta
Dans Okta, vous créez une application OpenID Connect dans Okta et assignez des groupes et des utilisateurs à l’application OpenID Connect.
Dans le vSphere Client, vous créez et configurez le fournisseur d’identité.
Après la configuration du fournisseur d’identité Okta sur vCenter, vous mettez à jour l’application OpenID Connect d’Okta avec l’URI de redirection que vous copiez depuis la page de configuration du fournisseur d’identité vCenter.
Dans Okta, à partir du catalogue d’applications Okta, vous créez l’application SCIM 2.0 et envoyez (Push) les utilisateurs et groupes vers vCenter.
Dans le vSphere Client, vous configurez l’appartenance au groupe pour l’autorisation Okta et vérifiez la connexion.
¶ Flux de connexion de la fédération du fournisseur d’identité vCenter pour ADFS
vCenter, ADFS et Active Directory interagissent pendant le flux de connexion pour la fédération vCenter IDP avec ADFS.
vCenter, ADFS et AD interagissent pendant le flux de connexion comme suit :
- L’utilisateur se connecte à vCenter via la page d’accueil habituelle de vCenter.
- vCenter redirige la requête d’authentification vers ADFS selon le domaine fourni.
- Si nécessaire, ADFS invite l’utilisateur à se connecter avec ses identifiants Active Directory.
- ADFS authentifie l’utilisateur avec Active Directory.
- ADFS émet un security token contenant les informations de groupe provenant d’Active Directory.
- vCenter utilise le token pour connecter l’utilisateur.
Si le fournisseur d’identité externe (IDP) est inaccessible, le processus de connexion revient à la page d’accueil de vCenter, affichant un message d’information approprié.
Les utilisateurs administrateurs peuvent toujours se connecter en utilisant leurs comptes locaux (local OS ou sources d’identité vsphere.local).
¶ Configuration de la fédération du fournisseur d’identité vCenter dans vSphere
Dans le vSphere Client, vous obtenez les Redirect URIs depuis vCenter.
La fédération vCenter IDP n’est pas activée par défaut. Après l’installation de vCenter, vous avez la possibilité de la configurer manuellement.
Les étapes générales pour configurer la fédération IDP sont les suivantes :
- Obtenir les Redirect URIs depuis vCenter
- Créer un groupe d’applications ADFS et le configurer pour vCenter dans la configuration Windows
- Créer un IDP sur vCenter dans le vSphere Client
- Configurer l’appartenance aux groupes à partir des onglets Users et Groups ou les privilèges via les permissions globales ou d’objet dans le vSphere Client pour l’autorisation ADFS
- Vérifier la connexion d’un utilisateur AD à vCenter
Pour configurer l’appartenance à un groupe pour vCenter pour l’autorisation AD FS :
- Cliquez sur le groupe Administrators puis sur Add Members.
- Sélectionnez le domaine dans le menu déroulant.
- Dans la zone de texte sous le menu déroulant, saisissez les premières lettres du groupe AD FS que vous souhaitez ajouter, puis attendez que la sélection apparaisse dans le menu déroulant.
- Sélectionnez le groupe AD FS et ajoutez-le au groupe Administrators.
- Cliquez sur Save.
Pour plus d’informations sur la configuration de vCenter IDP Federation for vCenter, consultez : https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-authentication/GUID-C5E998B2-1148-46DC-990E-A5DB71F93351.html
Dans le vSphere Client, vous pouvez modifier le fournisseur d’identité vCenter.
Dans le vSphere Client, vous fournissez les informations du groupe d’applications.
¶ Activation d’ADFS sur une configuration Enhanced Linked Mode existante
Pour activer ADFS sur une configuration Enhanced Linked Mode existante :
- Déployez au minimum deux nœuds vCenter dans une configuration Enhanced Linked Mode.
- Configurez ADFS sur l’un des nœuds vCenter liés. La configuration ADFS est répliquée sur l’autre nœud vCenter.
- Ajoutez toutes les Redirect URIs pour les deux nœuds vCenter dans le groupe d’applications OAuth configuré dans ADFS.
¶ Lab 19 : Configuration de la fédération d’identité pour utiliser Microsoft ADFS (Simulation)
Configuration de la fédération d’identité pour utiliser Microsoft ADFS :
- Configurez la fédération du fournisseur d’identité vCenter.
- Connectez-vous à vCenter en utilisant un compte AD.
Retrouvez le lien du Lab en cliquant ici : Lab 19 : Accéder à l'environnement de lab
¶ Revue des objectifs d’apprentissage
- Décrire la fédération d’identité
- Identifier les cas d’utilisation de la fédération d’identité
- Décrire l’architecture de la fédération d’identité
- Configurer la fédération d’identité
¶ Points clés
- Lors de la définition d’un rôle, utilisez le plus petit nombre possible de privilèges afin d’améliorer la sécurité et le contrôle.
- Le renforcement de la sécurité d’un environnement vSphere implique la configuration du système vCenter, des hôtes ESXi, des VMs et du réseau vSphere.
- Les Identity sources avec MFA fournissent une couche de sécurité supplémentaire pour authentifier les utilisateurs accédant à l’environnement vSphere.
Chapitre précédent : 7 - vSphere Monitoring - Chapitre suivant : 9 - Environnements de confiance vSphere et Chiffrement des VM