Bases de référence de gouvernance et de sécurité pour Azure VMware Solution

Cet article vous aide à établir des bases de référence de gouvernance et de sécurité afin que chaque charge de travail Azure VMware Solution hérite de contrôles cohérents et réduit les risques avant l’intégration.

Diagramme montrant le processus de Cloud Adoption Framework Microsoft pour l’adoption de Azure VMware Solution.

Cet article aide les décideurs à établir la base de référence de gouvernance et de sécurité que chaque charge de travail Azure VMware Solution hérite par défaut. Une base de référence est l’ensemble de contrôles minimal dont hérite chaque charge de travail de solution Azure VMware avant qu’une équipe responsable d’une charge de travail ne soit intégrée. Vous créez et gérez ces bases de référence. Créez des contrôles supplémentaires pour répondre aux besoins de l’organisation, tels que la conformité réglementaire ou pour gérer les risques spécifiques à la charge de travail.

Les instructions de base supposent ici Azure VMware Solution génération 2 (Gen2), où le cloud privé est déployé à l’intérieur d’un réseau virtuel Azure par défaut, ce qui donne une connectivité native aux services Azure et aux contrôles natifs Azure. La génération 1 (Gen 1) est l’exception héritée et est appelée uniquement lorsque ses fonctionnalités diffèrent.

Appliquez les mêmes bases de référence de gouvernance et de sécurité aux environnements hors production que vous le faites aux environnements de production. Avoir des lignes de base cohérentes signifie moins de risques de faiblesses dans votre patrimoine global et simplifie la transition des charges de travail d’un environnement à un autre.

Recommandation : Déterminez la base de référence de gouvernance et de sécurité que chaque charge de travail Azure VMware Solution doit hériter à la fois de l’environnement Azure et du cloud privé VMware avant d’intégrer des applications ou des équipes opérationnelles.

1. Étendue de la base de référence de gouvernance

Azure VMware Solution a besoin de gouvernance sur deux surfaces, et une base de référence qui ne couvre qu’une seule d’entre elles laisse des lacunes dans le contrôle et le risque.

  • Gouvernance Azure :Le périmètre Azure est l’ensemble des ressources Azure qui sous-tendent le cloud privé, telles que l’abonnement, le réseau virtuel, la supervision et les attributions de rôles Azure. Vous le régissez avec des outils natifs Azure.

  • Gouvernance du cloud privé : La surface VMware est le cloud privé lui-même, comme les segments réseau, la stratégie de pare-feu, les rôles vCenter et NSX et les stratégies de stockage. Vous gérez la plupart de ces outils avec des outils natifs VMware à l’intérieur du cloud privé.

Une base de référence de gouvernance qui traite uniquement l’environnement Azure ou uniquement l’environnement VMware crée des lacunes dans le contrôle opérationnel et la gestion des risques.

2. Application de la gouvernance

Appliquez les exigences de référence via la zone d’atterrissage de la plateforme dans la mesure du possible. Utilisez des processus opérationnels manuels pour prendre en charge l’application lorsque les contrôles techniques ne sont pas disponibles.

Appliquez Azure Policy au niveau du groupe d’administration, de l’abonnement ou du groupe de ressources pour établir des exigences obligatoires pour chaque déploiement Azure VMware Solution. En utilisant Azure Policy, vous pouvez garantir la cohérence entre les clouds privés Azure VMware Solution, en particulier lorsque vous délèguez l’administration VMware aux propriétaires de charge de travail. Alignez ces exigences avec les normes déjà utilisées dans l’ensemble du patrimoine Azure. Certaines stratégies et mécanismes d’application standard sont les suivants :

3. Base de référence de sécurité

Chaque déploiement Azure VMware Solution doit hériter d’une base de référence de sécurité approuvée avant l’intégration de la charge de travail. Commencez par la base de référence de sécurité Azure pour Azure VMware Solution, qui mappe les fonctionnalités de Azure VMware Solution au benchmark de sécurité Microsoft Cloud et fournit des conseils de sécurité Microsoft recommandés. Microsoft Defender for Cloud pouvez évaluer en permanence l’environnement par rapport aux recommandations applicables et aux contrôles réglementaires. Les définitions Azure Policy associées aux contrôles du benchmark apparaissent dans la vue Conformité réglementaire de Microsoft Defender for Cloud. Consultez Azure VMware Solution recommandations en matière de sécurité.

4. niveau de référence de l’identité pour Azure VMware Solution

Azure VMware Solution consomme vos services d’identité existants. Par conséquent, la base de référence fait référence à la façon dont vous vous connectez et à vos ressources telles que des machines virtuelles, plutôt que de déployer de nouveaux services d’identité. Cette base de référence concerne les services d'identité utilisés par Azure VMware Solution lui-même et n'affecte pas les services d'identité utilisés par les charges de travail d'application individuelles s'exécutant sur VMware.

4.1 Fournisseur d’identité

Utilisez une source d’identité externe pour l’accès vCenter plutôt que le compte CloudAdmin intégré. Azure VMware Solution prend en charge Microsoft Entra ID et Active Directory (LDAPS) comme sources d’identité externes pour vCenter Server.

  • Option numéro 1. Microsoft Entra ID (recommandé). Les organisations qui standardisent déjà sur Microsoft Entra ID doivent préférer Entra ID fédération, car elles centralisent la gouvernance des identités, l’accès conditionnel et l’authentification multifacteur dans Azure et l’administration VMware.

  • Option 2. services de domaine Active Directory sur LDAPS. Les organisations ayant des dépendances opérationnelles sur l’administration VMware intégrée à Active Directory peuvent continuer à utiliser LDAPS. Il assure une continuité avec les flux de travail d’administration VMware intégrés à AD existants. Vous hébergez de façon centralisée des contrôleurs de domaine AD dans Azure, dans l’abonnement d’identité de la plateforme.

4.2 Autorisations utilisateur

Les décisions d’accès utilisateur établissent la base de l’administration sécurisée de Azure VMware Solution. Avant d’intégrer des équipes opérationnelles, définissez la façon dont les administrateurs reçoivent l’accès, quels rôles ils peuvent utiliser et comment l’accès est examiné au fil du temps.

  • Affectation basée sur un groupe : Définissez des groupes d’administrateurs avant d’intégrer des équipes opérationnelles. Affecter des utilisateurs à des groupes et affecter des groupes à des rôles. Évitez les affectations directes d’utilisateurs à l’exception des exceptions temporaires.

  • Rôles vCenter à privilèges minimaux : Utilisez des rôles vCenter personnalisés lorsque le rôle CloudAdmin accorde davantage d’accès qu’une équipe n’en a besoin. Azure VMware Solution prend en charge les rôles personnalisés dans vCenter avec des privilèges égaux ou inférieurs au rôle CloudAdmin. Il ne propose pas de rôles personnalisés dans le portail Azure VMware Solution.

  • Parité NSX Manager : appliquez le même processus de gouvernance d’accès au NSX Manager. Définissez des rôles d’administration approuvés, appliquez des privilèges minimum et effectuez des révisions d’accès périodiques. Tous les rôles NSX prédéfinis ne sont pas pris en charge. Définissez donc un petit ensemble de rôles NSX approuvés et examinez-les régulièrement.

4.3 Rôle CloudAdmin

Le rôle CloudAdmin dans Azure VMware Solution fonctionne différemment d’un accès administrateur VMware sur site, et le considérer comme un compte administrateur utilisé au quotidien est une erreur courante. Traitez CloudAdmin comme un compte de secours, renouvelé régulièrement, surveillé et réservé aux situations d’urgence. Accordez un accès au quotidien via des groupes d’identités externes associés à des rôles de moindre privilège.

  • Réservé aux urgences : n’utilisez pas le compte CloudAdmin intégré pour l’administration au quotidien ou l’intégration de services. Réservez-le comme compte de secours pour un accès d’urgence. Stockez les informations d’identification par le biais de votre processus d’accès privilégié, faites-la pivoter selon une planification définie et alertez-les lors de la récupération ou de l’utilisation.

  • Aucun accès au niveau de l'hôte : Azure VMware Solution administrateurs ne reçoivent pas le compte vCenter Server administrator@vsphere.local ni le compte racine ESXi. Toutefois, les administrateurs peuvent affecter Active Directory utilisateurs et groupes au rôle CloudAdmin dans vCenter Server.

  • Domaine d’authentification unique managé : Le domaine d’authentification unique vsphere.local est une ressource managée qui prend en charge les opérations de plateforme. Vous ne pouvez pas l’utiliser pour créer ou gérer des utilisateurs et des groupes locaux au-delà des comptes par défaut fournis avec le cloud privé.

  • Ajout d’une source d’identité : Le rôle CloudAdmin ne peut pas ajouter directement une source d’identité (par exemple LDAP/LDAPS). Utilisez les commandes d’exécution pour ajouter une source d’identité externe et affecter le rôle CloudAdmin aux utilisateurs et aux groupes.

5. base de référence de mise en réseau Azure VMware Solution

Chaque cloud privé utilise VMware NSX comme couche réseau définie par logiciel, en remplaçant le modèle VLAN local de VMware. Vos équipes créent des segments NSX pour les charges de travail, routent le trafic via les passerelles NSX Tier-0 et Tier-1 et écrivent des règles de pare-feu distribuées. Planifiez l’approche de sécurité réseau tôt et définissez une limite claire :

  • Utilisez NSX pour le trafic à l’intérieur de l’environnement Azure VMware Solution (est-ouest).

  • Utilisez des contrôles Azure natifs ou locaux pour le trafic qui traverse la limite Azure VMware Solution (nord-sud).

5.1 Ligne de base du trafic est-ouest

Les contrôles est-ouest régissent le trafic entre les charges de travail à l’intérieur du cloud privé. Appliquez la microsegmentation avec le pare-feu distribué NSX pour chaque charge de travail. Ajoutez vDefend uniquement lorsqu’un objectif de contrôle spécifique l’exige.

  • Option numéro 1. Pare-feu NSX. Utilisez toujours le pare-feu distribué NSX pour appliquer la microsegmentation entre les charges de travail. La microsegmentation limite le mouvement latéral si un attaquant atteint une charge de travail, par exemple l’arrêt d’un serveur web compromis d’atteindre une base de données. Les équipes sous-utilisent souvent cette fonctionnalité juste après la migration, alors intégrez-la à la configuration de base.

  • Option 2. Pare-feu NSX et pare-feu VMware vDefend. Lorsque le pare-feu distribué ne répond pas à une exigence spécifique, évaluez le module complémentaire VMware vDefend Firewall facultatif pour les fonctionnalités que NSX seul ne fournit pas, telles que la détection d’intrusion et le filtrage d’URL. Adoptez-le uniquement lorsque ces fonctionnalités correspondent à un objectif de contrôle que vous devez respecter.

Appliquez la même approche de privilège minimum à NSX en limitant qui peut modifier les règles de pare-feu, les segments et le routage. Placez le contrôle des modifications et l’audit, car les mises à jour NSX peuvent affecter la connectivité partagée et perturber plusieurs charges de travail.

5.2 Ligne de base du trafic nord-sud

Les contrôles nord-sud régissent l’entrée et la sortie du trafic dans l’environnement Azure VMware Solution. L’outil approprié dépend de votre conception réseau plus large Azure.

  • Option 1.Pare-feu Azure ou une appliance virtuelle réseau tierce. De nombreuses organisations inspectent ce trafic avec Pare-feu Azure ou une appliance virtuelle réseau tierce placée dans votre abonnement de plateforme « Connectivité » centralisé.

  • Option 2.Pare-feu de passerelle NSX à la périphérie. Utilisez le pare-feu de passerelle NSX à la périphérie Azure VMware Solution lorsque vous préférez inspecter la limite du cloud privé.

  • Option 3.Pare-feu local. Certains routent la sortie Internet via un pare-feu local existant.

Sur Gen 2, ajoutez Azure groupes de sécurité réseau (NSG) au niveau du réseau virtuel Azure pour une couche Azure native supplémentaire qui complète NSX. Gen 1 n’offre pas de NSG.

Si vous appliquez des contrôles à plusieurs couches, planifiez la façon dont vous les garderez cohérents. Les contrôles répartis sur plusieurs couches ajoutent de la complexité, compliquent la résolution des problèmes et peuvent créer des chemins de trafic inattendus. Si vous utilisez des outils réseau automatisés, décidez de la façon dont vous conservez les stratégies synchronisées entre VMware et Azure. Documentez les exigences de connectivité réseau de la charge de travail et assurez-vous que la même documentation et le même processus de notification de modification sont utilisés par les administrateurs VMware et les équipes d’administration réseau en amont.

6. Base de référence des coûts Azure VMware Solution

La gouvernance des coûts définit les garde-fous financiers que chaque déploiement Azure VMware Solution hérite. Au minimum, vous avez besoin d’un budget avec des alertes, d’une norme d’étiquetage requise et d’un approbateur nommé pour les modifications de capacité sur chaque abonnement Azure VMware Solution.

  • Budgets et alertes : Utilisez Microsoft Cost Management pour définir des seuils budgétaires et des alertes de dépenses afin de repérer rapidement tout dépassement de budget. Exiger que les équipes de charge de travail configurent des alertes pour les seuils d’utilisation du processeur, de la mémoire et des vSAN, et routent ces alertes vers un propriétaire d’opérations nommées afin que la réponse ne soit pas ambiguë. Définissez les valeurs de seuil de manière centralisée, telles que l’alerte à 75 % de l’utilisation soutenue du processeur pour les clusters de production, afin que les décisions de capacité soient basées sur les mêmes données dans chaque équipe. Consultez Configurer des alertes pour Azure VMware Solution.

  • Étiquetage : Exigez des balises sur les ressources Azure VMware Solution pour que les coûts soient imputés aux propriétaires et aux charges de travail et que vous puissiez en rendre compte. Consultez les définitions de stratégie pour l’étiquetage des ressources.

  • Capacité : Traitez l’ajout d’hôtes comme une action délibérée et approuvée. Décidez qui peut approuver une nouvelle capacité. Définissez des normes pour la taille minimale et maximale des clusters et pour les régions de déploiement autorisées, et imposez une marge de capacité afin qu’une banque de données ne soit jamais trop remplie. Demander un quota d’hôte en avance sur le besoin. Les demandes de quota n’ajoutent aucun coût, mais un ajout de capacité peut prendre plusieurs jours. Vérifiez que votre processus inclut l’acquisition des licences VCF nécessaires pour les hôtes Azure VMware Solution nouvellement ajoutés.

7. configuration de référence de la machine virtuelle invitée de la solution Azure VMware

Microsoft gère l’infrastructure Azure VMware Solution, y compris les hôtes ESXi, vCenter Server et NSX. Vous restez responsable des systèmes d’exploitation invités, des applications et des contrôles de sécurité qui s’exécutent à l’intérieur de chaque machine virtuelle.

Étendez la gouvernance aux systèmes d’exploitation invités en intégrant des machines virtuelles à VMware vSphere avec Azure Arc. Consultez VMware vSphere avec Azure Arc.

Une fois qu’une machine virtuelle est compatible avec Arc, les organisations peuvent appliquer la configuration des machines d’Azure Policy, les services Microsoft Defender, Update Manager et d’autres fonctionnalités de gestion d’Azure à l’aide des mêmes processus de gouvernance que ceux utilisés pour les machines virtuelles Azure. Consultez les définitions de stratégie intégrées pour les serveurs compatibles avec Azure Arc et comment créer des définitions de stratégie de configuration d’ordinateur personnalisées.

7.1 Configuration de base de l’invité

Exiger l’intégration à Azure Arc dans le cadre du processus de provisionnement des machines virtuelles. L’intégration anticipée garantit que les contrôles de gouvernance s’appliquent dès le jour 1 au lieu d’être ajoutés ultérieurement par le biais d’efforts manuels. Azure Arc permet des fonctionnalités telles que l’inventaire, le suivi des modifications et la configuration de l’ordinateur.

Ces services fonctionnent dans Azure VMware Solution de la même manière qu’avec les machines virtuelles Azure, une fois l’invité activé avec Arc. Les organisations peuvent ensuite appliquer les mêmes normes de configuration dans les environnements Azure, VMware locaux et Azure VMware Solution.

7.2 Protection des terminaux

Les normes endpoint protection doivent rester cohérentes, quel que soit l’emplacement d’exécution de la machine virtuelle. Pour Azure VMware Solution machines virtuelles, VMware vSphere compatible avec Azure Arc fournit le chemin d’intégration requis pour déployer Microsoft Defender for Endpoint et d’autres services de sécurité Azure. Cette approche permet aux équipes de sécurité de maintenir une vue unifiée de la posture de sécurité des points de terminaison dans l’environnement hybride. Consultez Intégrer Microsoft Defender for Cloud à Azure VMware Solution.

7.3 Base de référence de correctif

Microsoft est responsable de la mise à jour corrective de l’infrastructure Azure VMware Solution. Dans votre organisation, l’équipe des opérations informatiques ou les équipes d’administration de charge de travail sont généralement responsables de la mise à jour corrective des systèmes d’exploitation invités et des applications. Si votre organisation dépend des solutions de mise à jour corrective d’entreprise établies, continuez à utiliser ces outils où des exigences avancées en matière de planification ou d’orchestration existent. Ces exigences peuvent inclure Gestionnaire de mise à jour Azure sur les machines virtuelles avec Arc Azure VMware Solution.

Base de référence de l’extension de machine virtuelle 7.4

Les extensions de machine virtuelle fournissent des fonctionnalités telles que la surveillance de la sécurité, la collecte de données de télémétrie et la gestion opérationnelle. Sans gouvernance, le déploiement d’extension peut devenir fragmenté et difficile à contrôler.

Définissez un catalogue d’extensions approuvés et demandez aux équipes de charge de travail d’utiliser uniquement les extensions autorisées. Associez la gouvernance des extensions avec Azure Policy pour appliquer la conformité et détecter les configurations non autorisées.

Étape suivante