Ao criar ou editar seus modelos de nuvem do vRealize Automation, use as opções de recursos de segurança mais adequadas para atender aos seus objetivos.

Recurso de grupo de segurança independente de nuvem

Você adiciona um recurso de grupo de segurança usando o recurso Grupo de Segurança > Independente de Nuvem na página Modelo. O recurso é exibido no código do modelo de nuvem como um tipo de recurso Cloud.SecurityGroup. O recurso padrão é exibido como:
  Cloud_SecurityGroup_1:
    type: Cloud.SecurityGroup
    properties:
      constraints: []
      securityGroupType: existing

Você especifica um recurso de grupo de segurança em um design de modelo de nuvem como existente (securityGroupType: existing) ou sob demanda (securityGroupType: new).

É possível adicionar um grupo de segurança existente ao seu modelo de nuvem ou usar um grupo de segurança existente que tenha sido adicionado a um perfil de rede.

Para NSX-V e NSX-T, bem como o NSX-T com a opção de gerenciador de políticas ativada em combinação com o VMware Cloud on AWS, você pode adicionar um grupo de segurança existente ou definir um novo grupo de segurança conforme projeta ou modifica seu modelo de nuvem. Grupos de segurança sob demanda têm suporte para o NSX-T, o NSX-V e o VMware Cloud on AWS quando usados com o gerenciador de políticas do NSX-T.

Para todos os tipos de conta de nuvem, exceto Microsoft Azure, você pode associar um ou mais grupos de segurança a um NIC de máquina. Um NIC de máquina virtual Microsoft Azure (machineName) só pode ser associado a um grupo de segurança.

Por padrão, a propriedade de grupo de segurança securityGroupType está definida como existing. Para criar um grupo de segurança sob demanda, insira new para a propriedade securityGroupType. Para especificar regras de firewall para um grupo de segurança sob demanda, use a propriedade rules na seção Cloud.SecurityGroup do recurso de grupo de segurança.

Grupos de segurança existentes

Grupos de segurança existentes são criados em um recurso de conta de nuvem de origem, como o NSX-T ou o Amazon Web Services. Eles são coletados por dados pelo vRealize Automation da origem. Você pode selecionar um grupo de segurança existente em uma lista de recursos disponíveis como parte de um perfil de rede do vRealize Automation. Em um design de modelo de nuvem, é possível especificar um grupo de segurança existente de forma inerente por sua associação em um perfil de rede especificado ou especificamente por nome usando a configuração securityGroupType: existing em um recurso de grupo de segurança. Se você adicionar um grupo de segurança a um perfil de rede, adicione pelo menos uma tag de recurso ao perfil de rede. Recursos de grupo de segurança sob demanda exigem uma tag de restrição quando usados em um design de modelo de nuvem.

Você pode associar um recurso de grupo de segurança no seu design de modelo de nuvem a um ou mais recursos de máquina.

Observação: Se você pretende usar um recurso de máquina no seu design de modelo de nuvem para provisionar em um NIC de máquina virtual da Microsoft Azure ( machineName), deverá associar apenas o recurso de máquina a um único grupo de segurança.

Grupos de segurança sob demanda

Você pode definir grupos de segurança sob demanda à medida que define ou modifica um design de modelo de nuvem usando a configuração securityGroupType: new no código de recursos do grupo de segurança.

Você pode usar um grupo de segurança sob demanda para o NSX-V e o NSX-T, assim como a Amazon Web Services quando usada com o Tipo de política do NSX-T, para aplicar um conjunto específico de regras de firewall a um recurso de máquina em rede ou conjunto de recursos agrupados. Cada grupo de segurança pode conter várias regras de firewall nomeadas. É possível usar um grupo de segurança sob demanda para especificar serviços ou protocolos e portas. Observe que você pode especificar um serviço ou um protocolo, mas não ambos. É possível especificar uma porta além de um protocolo. Não será possível especificar uma porta se você especificar um serviço. Se a regra não contiver um serviço ou um protocolo, o valor padrão do serviço será Qualquer.

Você também pode especificar endereços IP e intervalos de IP em regras de firewall. Alguns exemplos de regras de firewall são mostrados em Redes, recursos de segurança e balanceadores de carga no vRealize Automation.

Quando você cria regras de firewall em um grupo de segurança do NSX-V ou NSX-T sob demanda, o padrão permite o tráfego de rede especificado. O padrão também permite outro tráfego de rede. Para controlar o tráfego de rede, você deve especificar um tipo de acesso para cada regra. Os tipos de acesso de regra são:
  • Permitir (padrão) - permite o tráfego de rede especificado nessa regra de firewall.
  • Negar - bloqueia o tráfego de rede especificado nessa regra de firewall. Informa ativamente ao cliente que a conexão foi rejeitada.
  • Descartar - rejeita o tráfego de rede especificado nessa regra de firewall. Descarta silenciosamente o pacote como se o ouvinte não estivesse online.
Para obter um exemplo de design que usa uma regra access: Allow e uma regra de firewall access: Deny, consulte Redes, recursos de segurança e balanceadores de carga no vRealize Automation.
Observação: Um administrador de nuvem pode criar um design de modelo de nuvem que contenha apenas um grupo de segurança do NSX sob demanda e pode implantar esse design para criar um recurso de grupo de segurança existente reutilizável que os membros da organização podem adicionar a perfis de rede e designs de modelo de nuvem como um grupo de segurança existente.

As regras de firewall oferecem suporte a valores CIDR de formato IPv4 ou IPv6 para endereços IP de origem e de destino. Para obter um exemplo de design que usa valores CIDR IPv6 em uma regra de firewall, consulte Redes, recursos de segurança e balanceadores de carga no vRealize Automation.

Grupos de segurança sob demanda e existentes para VMware Cloud on AWS

Você pode definir um grupo de segurança sob demanda para uma máquina VMware Cloud on AWS em um modelo de nuvem usando a configuração securityGroupType: new no código de recurso do grupo de segurança.

Um exemplo de snippet de código para um grupo de segurança sob demanda é mostrado abaixo:
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

Você também pode definir um grupo de segurança existente para uma máquina VMware Cloud on AWS em rede e, opcionalmente, incluir a marcação de restrição, como mostrado nos exemplos a seguir:

  Cloud_SecurityGroup_2:
    type: Cloud.SecurityGroup
    properties:
      constraints: [xyz]
      securityGroupType: existing
Cloud_SecurityGroup_3:
  type: Cloud.SecurityGroup
  properties:
    securityGroupType: existing
     constraints:
        - tag: xyz
Há suporte para o desenvolvimento de modelos de nuvem iterativos.
  • Se um grupo de segurança estiver associado a uma ou mais máquinas na implantação, uma ação de exclusão exibirá uma mensagem informando que o grupo de segurança não pode ser excluído.
  • Se um grupo de segurança não estiver associado a uma máquina na implantação, uma ação de exclusão exibirá uma mensagem informando que o grupo de segurança será excluído dessa implantação e que a ação não poderá ser desfeita. Um grupo de segurança existente é excluído do modelo de nuvem, enquanto um grupo de segurança sob demanda é destruído.

Usando tags de segurança do NSX-V e tags de VM do NSX-T

É possível visualizar e usar tags de segurança do NSX-V e o NSX-T e o NSX-T com tags de VM de política a partir de recursos gerenciados em modelos de nuvem do vRealize Automation.

Tags de segurança do NSX-V e do NSX-T têm suporte para uso com o vSphere. Tags de segurança do NSX-T também têm suporte para uso com o VMware Cloud on AWS.

Observação:

Assim como acontece com as VMs implantadas no vSphere, você pode configurar tags de máquina para que uma VM seja implantada no VMware Cloud on AWS. Você também pode atualizar a tag da máquina após a implantação inicial. Essas tags de máquina permitem que o vRealize Automation atribua dinamicamente uma VM a um grupo de segurança apropriado do NSX-T durante a implantação.

Você pode especificar tags de segurança do NSX-V usando key: nsxSecurityTag e um valor de tag no recurso de processamento no modelo de nuvem, como mostrado no exemplo a seguir, desde que a máquina esteja conectada a uma rede do NSX-V:
tags:
  - key: nsxSecurityTag
  - value: security_tag_1
  - key: nsxSecurityTag
  - value: security_tag_2

O valor especificado deve corresponder a uma tag de segurança do NSX-V especificada. Se não houver tags de segurança no NSX-V que correspondam ao valor da chave nsxSecurityTag especificado, a implantação falhará.

Observação:

A marcação de segurança do NSX-V requer que a máquina esteja conectada a uma rede do NSX-V. Se a máquina estiver conectada a uma rede do vSphere, a marcação de segurança do NSX-V será ignorada. Em ambos os casos, a máquina do vSphere também é marcada.

O NSX-T não tem uma tag de segurança separada. Qualquer tag especificada no recurso de processamento no modelo de nuvem fará com que a VM implantada seja associada a todas as tags especificadas no NSX-T. Para NSX-T, incluindo NSX-T com política, tags de VM também são expressas como um par de valores-chave no modelo de nuvem. A configuração key equivale à configuração scope no NSX-T, enquanto a configuração value equivale a Tag Name especificada em NSX-T.

Observe que se você tiver usado o Assistente de migração do vRealize Automation V2T para migrar suas contas de nuvem do NSX-V para o NSX-T , incluindo o NSX-T com Política, o assistente de migração criará um nsxSecurityTag par de chave/valor. Neste cenário, ou se o nsxSecurityTag for por qualquer motivo explicitamente especificado em um modelo de nuvem para uso com o NSX-T, incluindo o NSX-T com Política, a implantação criará uma tag de VM com uma configuração de Escopo vazia com um nome de Tag que corresponde ao value especificada. Quando você visualizar essas tags no NSX-T, a coluna Escopo ficará vazia.

Para evitar confusão, não use pares de chaves nsxSecurityTag quando para o NSX-T. Se você especificar um par de chave/valor nsxSecurityTag para uso com o NSX-T, incluindo o NSX-T com política, a implantação criará uma tag de VM com uma configuração de escopo vazia com um nome de tag que corresponde ao value especificado. Quando você visualizar essas tags no NSX-T, a coluna de escopo ficará vazia.

Usando políticas de isolamento de aplicativos em regras de firewall do grupo de segurança sob demanda

Você pode usar uma política de isolamento de aplicativos para permitir somente o tráfego interno entre os recursos provisionados pelo modelo de nuvem. Com o isolamento de aplicativos, as máquinas provisionadas pelo modelo de nuvem podem se comunicar entre si, mas não podem se conectar fora do firewall. Você pode criar uma política de isolamento de aplicativos no perfil de rede. Também é possível especificar o isolamento de aplicativos em um design de modelo de nuvem usando um grupo de segurança sob demanda com uma regra de firewall de negação ou uma rede privada ou de saída.

Uma política de isolamento de aplicativo é criada com uma precedência mais baixa. Se você aplicar várias políticas, as políticas com o maior peso terão precedência.

Quando você cria uma política de isolamento de aplicativo, um nome de política é gerado automaticamente. A política também é disponibilizada para reutilização em outros designs de modelo de nuvem e iterações específicas do projeto e do endpoint de recurso associados. O nome da política de isolamento de aplicativos não é visível no modelo de nuvem, mas é visível como uma propriedade personalizada na página do projeto (Infraestrutura > Administração > Projetos) após a implantação do design de modelo de nuvem.

Para o mesmo endpoint associado em um projeto, qualquer implantação que exija um grupo de segurança sob demanda para o isolamento de aplicativos pode usar a mesma política de isolamento de aplicativos. Depois de criada, a política não pode ser excluída. Quando você especifica uma política de isolamento de aplicativos, o vRealize Automation procura essa política dentro do projeto e em relação ao endpoint associado. Se ele encontrar a política, esta será reutilizada. Caso contrário, ele a criará. O nome da política de isolamento de aplicativo só estará visível após sua implantação inicial na lista de propriedades personalizadas do projeto.

Usando grupos de segurança no desenvolvimento iterativo de modelos de nuvem

Ao alterar as restrições do grupo de segurança durante o desenvolvimento iterativo, em que o grupo de segurança não está associado a uma máquina no modelo de nuvem, o grupo de segurança é atualizado na iteração conforme especificado. No entanto, quando o grupo de segurança já está associado a uma máquina, a reimplantação falha. Você deve desanexar os grupos de segurança existentes e/ou propriedades de recursos do securityGroupType de máquinas associadas durante o desenvolvimento iterativo de modelos de nuvem e fazer a reassociação entre cada reimplantação. O fluxo de trabalho necessário é o seguinte, supondo que você tenha implantado inicialmente o modelo de nuvem.
  1. No designer de modelos do Cloud Assembly, desanexe o grupo de segurança de todas as suas máquinas associadas no modelo de nuvem.
  2. Reimplante o modelo clicando em Atualizar uma implantação existente.
  3. Remova as propriedades securityGroupType e/ou tags de restrição de grupo de segurança existentes no modelo.
  4. Adicione novas propriedades securityGroupType e/ou tags de restrição de grupo de segurança no modelo.
  5. Associe as novas instâncias de propriedades securityGroupType e/ou tags de restrição de grupo de segurança às máquinas no modelo.
  6. Reimplante o modelo clicando em Atualizar uma implantação existente.

Operações de dia 2 disponíveis

Para obter uma lista de operações comuns de dia 2 disponíveis para recursos de modelo de nuvem e implantação, consulte Quais ações posso executar nas implantações do Cloud Assembly.

Saiba mais

Para obter informações sobre como usar um grupo de segurança para isolamento de rede, consulte Recursos de segurança no vRealize Automation.

Para obter informações sobre como usar grupos de segurança em perfis de rede, consulte Saiba mais sobre perfis de rede no vRealize Automation e Usando configurações de grupos de segurança em perfis de rede e designs de modelo de nuvem no vRealize Automation.

Para obter exemplos de uso de grupos de segurança em modelos de nuvem, consulte Redes, recursos de segurança e balanceadores de carga no vRealize Automation.