Lors de la création ou de la modification de vos modèles de cloud vRealize Automation, utilisez les ressources de sécurité les mieux adaptées à vos objectifs.

Ressource de groupe de sécurité indépendante du cloud

Ajoutez une ressource de groupe de sécurité en utilisant la ressource Indépendant du cloud > Groupe de sécurité sur la page Modèle. La ressource s'affiche dans le code du modèle de cloud en tant que type de ressource Cloud.SecurityGroup. La ressource par défaut s'affiche sous la forme suivante : 
  Cloud_SecurityGroup_1:
    type: Cloud.SecurityGroup
    properties:
      constraints: []
      securityGroupType: existing

Vous pouvez spécifier une ressource de groupe de sécurité dans une conception de modèle de cloud comme existante (securityGroupType: existing) ou à la demande (securityGroupType: new).

Vous pouvez ajouter un groupe de sécurité existant à votre modèle de cloud ou vous pouvez utiliser un groupe de sécurité existant qui a été ajouté à un profil réseau.

Pour NSX-V et NSX-T, ainsi que pour NSX-T pour lequel avec le commutateur de gestionnaire de stratégies est activé en combinaison avec VMware Cloud on AWS, vous pouvez ajouter un groupe de sécurité existant ou définir un nouveau groupe de sécurité lorsque vous concevez ou modifiez votre modèle de cloud. Les groupes de sécurité à la demande sont pris en charge pour NSX-T et NSX-V, et VMware Cloud on AWS lorsqu'ils sont utilisés avec le gestionnaire de stratégies de NSX-T.

Pour tous les types de compte de cloud, à l'exception de Microsoft Azure, vous pouvez associer un ou plusieurs groupes de sécurité à la carte réseau d'une machine. La carte réseau d'une machine virtuelle Microsoft Azure (machineName) ne peut être associée qu'à un seul groupe de sécurité.

Par défaut, la propriété du groupe de sécurité securityGroupType est définie sur existing. Pour créer un groupe de sécurité à la demande, entrez new pour la propriété securityGroupType. Pour spécifier des règles de pare-feu pour un groupe de sécurité à la demande, utilisez la propriété rules dans la section Cloud.SecurityGroup de la ressource du groupe de sécurité.

Groupes de sécurité existants

Les groupes de sécurité existants sont créés dans une ressource de compte de cloud source, telle que NSX-T ou Amazon Web Services. Il s'agit de données collectées par vRealize Automation depuis la source. Vous pouvez sélectionner un groupe de sécurité existant dans la liste des ressources disponibles dans le cadre d'un profil réseau vRealize Automation. Dans une conception de modèle de cloud, vous pouvez spécifier un groupe de sécurité existant de manière inhérente par son appartenance à un profil réseau spécifié ou de manière spécifique par son nom à l'aide du paramètre securityGroupType: existing dans une ressource de groupe de sécurité. Si vous ajoutez un groupe de sécurité à un profil réseau, ajoutez au moins une balise de capacité au profil réseau. Les ressources du groupe de sécurité à la demande nécessitent une balise de contrainte lorsqu'elles sont utilisées dans une conception de modèle de cloud.

Vous pouvez associer une ressource de groupe de sécurité dans votre conception de modèle de cloud à une ou plusieurs ressources de machine.

Note : Si vous prévoyez d'utiliser une ressource de machine dans votre conception de modèle de cloud pour provisionner une carte réseau de machine virtuelle Microsoft Azure ( machineName), vous devez uniquement associer la ressource de machine à un seul groupe de sécurité.

Groupes de sécurité à la demande

Vous pouvez définir des groupes de sécurité à la demande lorsque vous définissez ou modifiez une conception de modèle de cloud à l'aide du paramètre securityGroupType: new dans le code de la ressource de groupe de sécurité.

Vous pouvez utiliser un groupe de sécurité à la demande pour NSX-V et NSX-T, ainsi que Amazon Web Services lorsqu'ils sont utilisés avec le type de stratégie NSX-T, pour appliquer un ensemble spécifique de règles de pare-feu à une ressource de machine en réseau ou à un ensemble de ressources groupées. Chaque groupe de sécurité peut contenir plusieurs règles de pare-feu nommées. Vous pouvez utiliser un groupe de sécurité à la demande pour spécifier des services ou des protocoles et des ports. Notez que vous pouvez spécifier un service ou un protocole, mais pas les deux. Vous pouvez spécifier un port en plus d'un protocole. Vous ne pouvez pas spécifier un port si vous spécifiez un service. Si la règle ne contient aucun service ou protocole, la valeur de service par défaut est Tous.

Vous pouvez également spécifier des adresses IP et des plages d'adresses IP dans les règles de pare-feu. Des exemples de règles de pare-feu sont présentés dans Réseaux, ressources de sécurité et équilibrages de charge dans vRealize Automation.

Lorsque vous créez des règles de pare-feu dans un groupe de sécurité à la demande NSX-V ou NSX-T, les paramètres par défaut autorisent le trafic réseau spécifié. La valeur par défaut autorise également d'autres trafics réseau. Pour contrôler le trafic réseau, vous devez spécifier un type d'accès pour chaque règle. Les types d'accès aux règles sont les suivants :
  • Autoriser (par défaut) : autorise le trafic réseau spécifié dans cette règle de pare-feu.
  • Refuser : bloque le trafic réseau spécifié dans cette règle de pare-feu. Indique activement au client que la connexion est rejetée.
  • Abandonner : rejette le trafic réseau spécifié dans cette règle de pare-feu. Abandonne silencieusement le paquet comme si l'écouteur n'était pas en ligne.
Pour obtenir un exemple de conception qui utilise une règle de pare-feu access: Allow et access: Deny, reportez-vous à Réseaux, ressources de sécurité et équilibrages de charge dans vRealize Automation.
Note : Un administrateur de cloud peut créer une conception de modèle de cloud contenant uniquement un groupe de sécurité NSX à la demande et peut déployer cette conception pour créer une ressource de groupe de sécurité existante réutilisable que les membres de l'organisation peuvent ajouter aux profils réseau et aux conceptions de modèle de cloud comme un groupe de sécurité existant.

Les règles de pare-feu prennent en charge les valeurs CIDR au format IPv4 ou IPv6 pour les adresses IP source et de destination. Pour obtenir un exemple de conception qui utilise des valeurs CIDR au format IPv6 dans une règle de pare-feu, reportez-vous à Réseaux, ressources de sécurité et équilibrages de charge dans vRealize Automation.

Groupes de sécurité à la demande et existants pour VMware Cloud on AWS

Vous pouvez définir un groupe de sécurité à la demande pour une machine VMware Cloud on AWS dans un modèle de cloud à l'aide du paramètre securityGroupType: new dans le code de la ressource de groupe de sécurité.

Voici un exemple d'extrait de code pour un groupe de sécurité à la demande : 
resources:
  Cloud_SecurityGroup_1:
    type: Cloud.SecurityGroup
    properties:
      name: vmc-odsg
      securityGroupType: new
      rules: 
        - name: datapath
          direction: inbound
          protocol: TCP
          ports: 5011
          access: Allow
          source: any

Vous pouvez également définir un groupe de sécurité existant pour une machine VMware Cloud on AWS réseau et éventuellement inclure un balisage de contrainte, comme illustré dans les exemples suivants : 

  Cloud_SecurityGroup_2:
    type: Cloud.SecurityGroup
    properties:
      constraints: [xyz]
      securityGroupType: existing
Cloud_SecurityGroup_3:
  type: Cloud.SecurityGroup
  properties:
    securityGroupType: existing
     constraints:
        - tag: xyz
Le développement de modèles de cloud itératifs est pris en charge.
  • Si un groupe de sécurité est associé à une ou plusieurs machines du déploiement, une action de suppression affiche un message indiquant que le groupe de sécurité ne peut pas être supprimé.
  • Si un groupe de sécurité n'est associé à aucune machine du déploiement, une action de suppression affiche un message indiquant que le groupe de sécurité sera supprimé de ce déploiement et que l'action ne peut pas être annulée. Un groupe de sécurité existant est supprimé du modèle de cloud, tandis qu'un groupe de sécurité à la demande est détruit.

Utilisation de balises de sécurité NSX-V et de machines virtuelles NSX-T

Vous pouvez voir et utiliser des balises de sécurité NSX-V et NSX-T, et des balises de machine virtuelle NSX-T avec stratégie à partir de ressources gérées dans des modèles de cloud vRealize Automation.

Les balises de sécurité NSX-V et NSX-T sont prises en charge pour une utilisation avec vSphere. Les balises de sécurité NSX-T sont également utilisables avec VMware Cloud on AWS.

Note :

Comme pour les machines virtuelles déployées sur vSphere, vous pouvez configurer des balises de machine pour déployer une machine virtuelle sur VMware Cloud on AWS. Vous pouvez également mettre à jour la balise de machine après le déploiement initial. Ces balises de machine permettent à vRealize Automation d'attribuer dynamiquement une machine virtuelle à un groupe de sécurité NSX-T approprié pendant le déploiement.

Vous pouvez spécifier des balises de sécurité NSX-V en utilisant key: nsxSecurityTag et une valeur de balise dans la ressource de calcul du modèle de cloud, comme dans l'exemple suivant, à condition que la machine soit connectée à un réseau NSX-V : 
tags:
  - key: nsxSecurityTag
  - value: security_tag_1
  - key: nsxSecurityTag
  - value: security_tag_2

La valeur spécifiée doit correspondre à une balise de sécurité NSX-V. Si aucune balise de sécurité NSX-V ne correspond à la valeur de clé nsxSecurityTag spécifiée, le déploiement échoue.

Note :

La balise de sécurité NSX-V requiert que la machine soit connectée à un réseau NSX-V. Si la machine est connectée à un réseau vSphere, la balise de sécurité NSX-V est ignorée Dans l'un ou l'autre cas, la machine vSphere est également balisée.

NSX-T n'a pas de balise de sécurité distincte. Toute balise spécifiée sur la ressource de calcul dans le modèle de cloud entraîne l'association de la machine virtuelle déployée à toutes les balises spécifiées dans NSX-T. Pour NSX-T, y compris NSX-T avec stratégie, les balises de machine virtuelle sont également exprimées sous la forme d'une paire clé-valeur dans le modèle de cloud. Le paramètre key correspond au paramètre scope dans NSX-T et le paramètre value correspond au Tag Name spécifié dans NSX-T.

Notez que si vous avez utilisé l'assistant de migration vRealize Automation V2T pour migrer vos comptes de cloud de NSX-V vers NSX-T, y compris NSX-T avec stratégie, l'assistant de migration crée une paire clé-valeur nsxSecurityTag. Dans ce scénario, ou si nsxSecurityTag est explicitement spécifié pour une raison quelconque dans un modèle de cloud à utiliser avec NSX-T, y compris NSX-T avec stratégie, le déploiement crée une balise de machine virtuelle avec un paramètre de portée vide et un nom de balise qui correspond à la value spécifiée. Lorsque vous affichez ces balises dans NSX-T, la colonne Portée est vide.

Pour éviter toute confusion, n'utilisez pas une paire de clés nsxSecurityTag pour NSX-T. Si vous spécifiez une paire clé-valeur nsxSecurityTag à utiliser avec NSX-T, y compris NSX-T avec stratégie, le déploiement crée une balise de machine virtuelle avec un paramètre de portée vide et un nom de balise qui correspond à la value spécifiée. Lorsque vous affichez ces balises dans NSX-T, la colonne Portée est vide.

Utilisation des stratégies d'isolation d'application dans les règles de pare-feu du groupe de sécurité à la demande

Vous pouvez utiliser une stratégie d'isolation d'application pour autoriser uniquement le trafic interne entre les ressources provisionnées par le modèle de cloud. Avec l'isolation d'application, les machines provisionnées par le modèle de cloud peuvent communiquer entre elles, mais ne peuvent pas se connecter en dehors du pare-feu. Vous pouvez créer une stratégie d'isolation d'application dans le profil réseau. Vous pouvez également spécifier l'isolation d'application dans une conception de modèle cloud en utilisant un groupe de sécurité à la demande avec une règle de pare-feu Refuser, ou un réseau privé ou sortant.

Une stratégie d'isolation d'application est créée avec une priorité plus faible. Si vous appliquez plusieurs stratégies, les stratégies les plus volumineuses sont prioritaires.

Lorsque vous créez une stratégie d'isolation d'application, un nom de stratégie généré automatiquement est généré. La stratégie est également rendue disponible pour réutilisation dans d'autres conceptions et itérations de modèles de cloud spécifiques au point de terminaison et au projet de ressources associés. Le nom de la stratégie d'isolation d'application n'est pas visible dans le modèle de cloud, mais il est visible sous la forme d'une propriété personnalisée sur la page Projets (Infrastructure > Administration > Projets) après le déploiement de la conception du modèle de cloud.

Pour le même point de terminaison associé dans un projet, tout déploiement nécessitant un groupe de sécurité à la demande pour l'isolation d'application peut utiliser la même stratégie d'isolation d'application. Une fois la stratégie créée, celle-ci n'est pas supprimée. Lorsque vous spécifiez une stratégie d'isolation d'application, vRealize Automation recherche dans le projet la stratégie relative au point de terminaison associé. Si la stratégie est présente, elle est réutilisée. Dans le cas contraire, une stratégie est créée. Le nom de la stratégie d'isolation d'application est visible uniquement après son déploiement initial dans la liste des propriétés personnalisées du projet.

Utilisation de groupes de sécurité dans un développement de modèle de cloud itératif

Lors de la modification des contraintes du groupe de sécurité au cours d'un développement itératif, lorsque le groupe de sécurité n'est pas associé à une machine dans le modèle de cloud, le groupe de sécurité est mis à jour dans l'itération comme spécifié. Cependant, si le groupe de sécurité est déjà associé à une machine, le redéploiement échoue. Vous devez détacher les groupes de sécurité existants et/ou les propriétés de ressources securityGroupType des machines associées au cours d'un développement de modèle de cloud itératif, puis les réassocier entre chaque redéploiement. Le workflow nécessaire est le suivant, en supposant que vous avez déployé initialement le modèle de cloud.
  1. Dans le concepteur de modèle Cloud Assembly, détachez le groupe de sécurité de toutes les machines qui y sont associées dans le modèle de cloud.
  2. Redéployez le modèle en cliquant sur Mettre à jour un déploiement existant.
  3. Supprimez les balises de contrainte du groupe de sécurité et/ou les propriétés securityGroupType existantes dans le modèle.
  4. Ajoutez les nouvelles balises de contrainte du groupe de sécurité et/ou les propriétés securityGroupType dans le modèle.
  5. Associez les nouvelles balises de contrainte du groupe de sécurité et/ou les instances de propriété securityGroupType aux machines dans le modèle.
  6. Redéployez le modèle en cliquant sur Mettre à jour un déploiement existant.

Opérations de jour 2 disponibles

Pour obtenir la liste des opérations de jour 2 communes qui sont disponibles pour les ressources de modèle de cloud et de déploiement, reportez-vous à Actions pouvant être exécutées sur les déploiements de Cloud Assembly.

En savoir plus

Pour obtenir des informations sur l'utilisation d'un groupe de sécurité pour l'isolation réseau, consultez Ressources de sécurité dans vRealize Automation.

Pour plus d'informations sur l'utilisation de groupes de sécurité dans des profils réseau, consultez En savoir plus sur les profils réseau dans vRealize Automation et Utilisation des paramètres de groupe de sécurité dans les profils réseau et les conceptions de modèle de cloud dans vRealize Automation.

Pour obtenir des exemples d'utilisation de groupes de sécurité dans des modèles de cloud, consultez Réseaux, ressources de sécurité et équilibrages de charge dans vRealize Automation.