Práticas recomendadas para a segurança do VMware Engine

Este documento descreve as práticas recomendadas de segurança para gerenciar e configurar o Google Cloud VMware Engine e é destinado a usuários que já estão familiarizados com o VMware Engine. Se você é um iniciante, comece a aprender sobre os pré-requisitos e a segurança do VMware Engine.

O VMware Engine tem um modelo de responsabilidade compartilhada para segurança. A segurança confiável na nuvem é alcançada por meio das responsabilidades compartilhadas de clientes e do Google como provedor de serviços. Seguir essas práticas recomendadas pode ajudar você a economizar tempo, evitar erros e atenuar os efeitos de pontos de falha.

Rede do VMware Engine

As seções a seguir apresentam as práticas recomendadas para rede em um ambiente do VMware Engine.

Identifique e entenda todos os fluxos de tráfego do ambiente

O VMware Engine aproveita as redes do VMware Engine e os peerings de VPC para conectar uma conexão de rede particular de uma rede de nuvem privada do VMware Engine à sua rede VPC. O tráfego de entrada de uma VPC no ambiente do Google Cloud ou de uma rede local passa por uma rede da unidade de locação gerenciada pelo Google.

Usar o serviço de IP público do VMware Engine para transferência de dados pela Internet

O tráfego da Internet pode entrar em uma nuvem privada diretamente usando o serviço de IP público do VMware Engine. Como alternativa, o tráfego da Internet pode entrar usando um balanceador de carga público no Google Cloud. Nesse caso, o tráfego é roteado como qualquer outro tráfego de entrada. Essas opções são mutuamente exclusivas. Se forem necessários controles personalizados para o tráfego da Internet, como filtragem de URL, IPS/IDS ou inspeção de tráfego fornecida por uma instância central ou serviço no ambiente do Google Cloud, direcione o tráfego vinculado à Internet por rede VPC.

Se isso não se aplicar a você ou se os controles estiverem implementados na sua nuvem privada, recomendamos que você inclua o serviço de endereço IP externo no VMware Engine. Além disso, recomendamos o uso de regras de acesso externo para negar padrões de tráfego da Internet que não se aplicam aos aplicativos.

Separar as regras de firewall norte-sul e leste-oeste no gateway e no firewall distribuído no VMware Engine NSX-T

Configure o firewall distribuído (DFW, na sigla em inglês) no NSX-T no roteador lógico de nível 1 para segmentar o tráfego interno entre os domínios virtuais da camada 2. O NSX DFW foi projetado para processar o tráfego de rede leste-oeste (interno) entre segmentos e permite regras de firewall que permitam e neguem tráfego entre instâncias individuais dentro de um segmento.

Para ter um controle refinado de acesso à rede, aplique uma política padrão restrita no DFW para negar o tráfego de rede entre instâncias por padrão. Use o DFW para permitir especificamente o tráfego entre aplicativos e entre serviços dentro do aplicativo.

Configure o firewall de gateway do NSX para controlar o tráfego norte-sul que entra e sai da nuvem privada.

O firewall de gateway do NSX foi projetado para controlar o tráfego norte-sul e recomendado para casos de uso como controle do tráfego em um perímetro para outra zona de segurança. Se você precisar configurar o tráfego norte-sul para toda a nuvem privada de maneira consistente, configure o firewall do gateway no roteador nível 0. Se você precisar configurar o tráfego norte-sul para cada segmento NSX-T individual, configure o firewall do gateway no roteador de nível 1.

Além dos firewalls NSX-T, é recomendável usar o firewall da VPC para permitir e bloquear o tráfego leste-oeste entre as cargas de trabalho na nuvem privada do VMware Engine e nas VPCs. A transferência de dados de entrada para instâncias do Compute Engine de cargas de trabalho do VMware Engine precisa ser restringida por um tráfego aberto consciente.

A transferência de dados de saída para dispositivos de gerenciamento e para o intervalo CIDR do vSphere/vSAN também precisa ser bloqueada das VPCs usando o firewall da VPC. Abra apenas a transferência de dados de saída para dispositivos de gerenciamento de hosts e endereços IP confiáveis dentro da sua rede. É importante observar que os dispositivos de gerenciamento não estão dentro de um segmento NSX-T. Portanto, as regras de DFW não se aplicam para restringir o acesso.

Aplicar os princípios da segurança de confiança zero e a microssegmentação no NSX-T

Use o DFW do NSX-T para implementar controles de tráfego para segmentos de segurança tão granulares quanto as máquinas virtuais individuais. Esse princípio de proteção do tráfego entre VMs individuais que é negado por padrão também é chamado de "microssegmentação", que é uma abordagem mais granular para firewall do que a implementação convencional de firewalls entre domínios de camada 3.

O DFW é ativado no kernel do hipervisor em todos os hosts do VMware Engine vSphere na nuvem privada e pode controlar o fluxo de tráfego entre cargas de trabalho que estão nos mesmos segmentos NSX ou em segmentos separados. As regras de firewall que permitem o tráfego de entrada e saída das VMs podem ser definidas organizando-as em grupos de políticas, que podem ter critérios de associação flexíveis, como correspondência de tag ou nome da VM.

A microssegmentação permite implementar uma rede com controle de tráfego refinado, em que um padrão de tráfego precisa ser explicitamente permitido. O conceito de segurança em que todos os fluxos de rede são controlados por processos de verificação de identidade e dispositivo, em vez de confiança implícita, também é chamado de Segurança de confiança zero.

Implantar um dispositivo de firewall de terceiros no portal do Cloud Marketplace para recursos IPS/IDS

Se você precisar de segurança avançada da camada 7, incluindo recursos do SDI/IPS para o tráfego de entrada para a nuvem privada do restante da rede ou entre os segmentos da rede NSX-T, implante um firewall de terceiros. O dispositivo de terceiros pode ser implantado como um dispositivo multi-NIC entre duas VPCs na rede do Google Cloud ou dentro da nuvem privada com uma integração com o NSX-T.

Para mais informações sobre as arquiteturas do VMware Engine com dispositivos centralizados, que podem ser usados em diversos casos de uso de segurança avançados, como IPS/IDS, DDoS, descarregamento de SSL e muito mais, consulte o documento de segurança de rede usando dispositivos centralizados no Centro de arquitetura do Cloud.

Usar o Google Cloud Armor para proteger serviços da Web no VMware Engine contra ataques DDoS

Se você encaminhar o tráfego de entrada para cargas de trabalho no VMware Engine usando a VPC do cliente, recomendamos colocar cargas de trabalho do VMware Engine em grupos de endpoints de rede híbrida, atrás da Cloud Service Mesh, e aproveitar o balanceador de carga HTTP(S) externo. Qualquer configuração permite incluir o Google Cloud Armor para aplicativos públicos, mitigando ataques DDoS e vulnerabilidades comuns, como injeções de SQL ou scripting em vários locais.

Se você precisar de recursos do Service Mesh, como o gerenciamento de tráfego avançado usando o proxy Envoy ou a integração do Certificate Authority Service, recomendamos o Cloud Service Mesh. Em todos os outros casos, recomendamos o balanceador de carga HTTP(S) externo.

Siga a documentação sobre como as cargas de trabalho do VMware Engine podem ser adicionadas a NEGs híbridos em uma das seguintes configurações:

Conectar-se aos serviços do Google Cloud de maneira privada sem acesso à Internet

As cargas de trabalho de nuvem privada do VMware Engine podem acessar as APIs do Google Cloud, como a API Cloud Storage, usando o Acesso privado do Google. Recomendamos que você use o Acesso privado do Google para acessar os serviços do Google sem enviar tráfego pela Internet, porque isso reduz a latência e o custo de transferência de dados de saída. Isso também elimina a necessidade de um caminho de rede para a Internet para cargas de trabalho que só precisem de acesso à API do Google. Veja detalhes sobre o Acesso privado do Google para mais detalhes técnicos e etapas de configuração.

Da mesma forma, as cargas de trabalho do VMware Engine que precisam acessar os recursos do Google Cloud a partir de uma rede de produtores de serviços, como instâncias do Cloud SQL ou do Memorystore, precisam se conectar de maneira particular usando PSA. Para mais informações, acesse a seção sobre PSA para o VMware Engine.

Criptografar a comunicação entre o ambiente local e o Google Cloud

As cargas de trabalho no VMware Engine que precisam se comunicar com sistemas no local precisam se conectar por um canal criptografado. Recomendamos uma abordagem em camadas para criptografia em trânsito entre os data centers locais e o Google Cloud. O vínculo entre os sistemas locais e o Google Cloud pode ser criptografado configurando o Cloud VPN com um túnel IPsec ou usando o IPsec integrado nos anexos da VLAN do Interconnect. Além disso, a criptografia da camada de aplicativos precisa ser ativada entre esses componentes usando TLS.

Proteger seus dados contra exfiltração com o VPC Service Controls

É recomendável reduzir os riscos de exfiltração de dados com o VPC Service Controls. Basta colocar os recursos confidenciais, como buckets do Cloud Storage e conjuntos de dados do BigQuery, em um perímetro do VPC Service Controls. As cargas de trabalho que precisam acessar dados dentro de um perímetro também precisam ser colocadas no perímetro. Especificamente, o projeto do Google Cloud que hospeda a nuvem privada precisa fazer parte do perímetro do VPC Service Controls para acessar recursos protegidos pelo VPC Service Controls.

Você precisa definir políticas de transferência de dados de entrada e saída na configuração do VPC Service Controls para permitir que as APIs de serviço do produtor do VMware Engine entrem no perímetro. Para orientações detalhadas sobre a configuração, siga nossas páginas de documentação em VPC Service Controls com o VMware Engine.

IAM e permissões do VMware Engine

As seções a seguir apresentam as práticas recomendadas para permissões do usuário em um ambiente do VMware Engine. É importante cuidar das permissões no ambiente do VMware Engine e no projeto do Google Cloud em que a nuvem privada é implantada.

Usar papéis predefinidos ou personalizados para conceder acesso

A abordagem do VMware Engine para gerenciar os papéis e permissões do vSphere pode ser aproveitada da mesma maneira que você está acostumado a fazer com outros ambientes do VMware Engine. No entanto, atividades como a implantação de um cluster exigem permissões no Identity and Access Management (IAM). A tabela a seguir lista os gerenciadores de acesso relevantes, as origens de identidade a que eles concedem permissões e exemplos de atividades ativadas.

Plataforma Componente Origem de identidade Onde configurar as permissões Exemplos de atividades
Google Cloud Portal do VMware Engine Cloud Identity Identity and Access Management Implantação e cancelamento de nuvem privada, implantação e cancelamento de clusters, por exemplo.
VMware Engine vCenter LDAP Hosts e clusters, VMs e pastas, repositórios de dados na IU do vCenter Criação e exclusão de VMs, de pastas de VMs e de objetos do repositório de dados, por exemplo
NSX-T LDAP "Usuários e papéis" na IU do NSX-T Manager Criação de segmento NSX, configuração de firewall, configuração do balanceador de carga, por exemplo.
vCenter Sistema operacional de convidado da VM Active Directory, LDAP, usuários locais, por exemplo Sistema operacional convidado Login SSH ou RDP, operações de arquivo, por exemplo

No Google Cloud IAM, há dois papéis predefinidos com permissões para o portal do VMware Engine:

  • Administrador de serviço do VMware Engine: dá acesso total ao serviço do VMware Engine no Google Cloud.
  • Leitor de serviços do VMware Engine: oferece acesso somente leitura ao serviço do VMware Engine no Google Cloud.

Essas permissões estão relacionadas a ações no portal do VMware Engine e não a ações na API ou CLI. Observe que também os papéis básicos incluem a capacidade de gerenciar o serviço do VMware Engine (Proprietário, Editor) ou visualizar os detalhes do serviço (leitor). Geralmente, é recomendável usar papéis predefinidos em vez de papéis básicos, porque eles fornecem permissões mais granulares.

O acesso programático ao VMware Engine com contas de serviço que usam a API ou a CLI precisa ser restrito usando papéis predefinidos ou personalizados, porque eles incluem permissões mais refinadas que se aplicam apenas ao VMware Engine. Se o acesso programático for usado apenas para uma tarefa que requer apenas um subconjunto específico das permissões dos papéis predefinidos, é recomendável criar um papel personalizado.

Escolha um local apropriado para a atribuição do papel de IAM na hierarquia de recursos da sua organização. Se você estiver executando todas as nuvens privadas do VMware Engine em um projeto, apenas os papéis poderão ser atribuídos no nível do projeto. Se houver requisitos técnicos ou organizacionais que resultem na localização de suas nuvens privadas em projetos separados, defina os papéis necessários em uma pasta comum aos projetos usados para suas nuvens privadas.

As permissões do Cloud IAM não são necessárias para atividades que só precisam ser feitas no vCenter, NSX-T ou HCX. A equipe que só precisa operar esses ambientes não precisa dos papéis do IAM listados anteriormente. Em vez disso, eles precisam usar identidades LDAP com permissões configuradas no vCenter e no NSX-T. Recomendamos que você forneça os papéis de administrador de serviço do VMware Engine ou visualizador de serviços do VMware Engine a um número muito limitado de usuários, já que eles concedem acesso à conta de usuário poderosa do CloudOwner para o vCenter e a conta de usuário administrador para NSX-T. Essas contas de usuário só devem ser usadas para configuração inicial ou procedimentos de emergência.

Restringir e fazer auditorias ativas do acesso de administradores

O papel de administrador de serviço do VMware Engine é muito eficiente e só deve ser atribuído a usuários que precisam gerenciar o ciclo de vida da nuvem privada do VMware Engine e dos clusters dela. Normalmente, a adição ou exclusão manual de clusters e nós é uma ação que não acontece com frequência e pode ter um alto impacto no faturamento ou na disponibilidade do cluster. Atribua esse papel apenas a poucas pessoas na sua organização.

Faça auditorias regulares de quem recebeu o papel de Administrador de serviço do VMware Engine, seja diretamente no projeto usado para o VMware Engine ou em um dos níveis pais da hierarquia de recursos. Essa auditoria precisa incluir outros papéis, como os papéis básicos de Editor e Proprietário, que incluem permissões críticas relacionadas ao VMware Engine. É possível usar serviços como o recomendador de papéis do IAM para ajudar a identificar papéis excessivamente privilegiados.

Configurar uma origem de identidade LDAP ou do Active Directory

Um provedor de identidade compatível com a autenticação LDAP, como o Active Directory, precisa ser configurado para ativar a autenticação do usuário para o vCenter e o NSX Manager. Essa é uma prática recomendada para ter gerenciamento central do ciclo de vida de identidade, gerenciamento de grupos, gerenciamento de senhas e muito mais. Observe que não é possível mesclar diretamente o vCenter e o NSX-T com o Active Directory para autenticação integrada do Windows.

Alternar as senhas das contas de serviço integradas

O VMware Engine gera credenciais para acessar dispositivos de gerenciamento na nuvem privada (como vCenter, NSX-T e HCX). É recomendado estabelecer um processo para alternar as senhas da conta de serviço padrão do vCenter, CloudOwner@gve.local, e do administrador da conta de serviço NSX-T padrão. Ambas as contas de usuário só devem ser usadas para a configuração inicial e os procedimentos de emergência, e as senhas devem ser alternadas regularmente (por exemplo, a cada 60 ou 90 dias). Da mesma forma, alterne regularmente as senhas das contas de usuário da solução, comumente usadas para a integração de ferramentas de terceiros. Quanto mais você alternar as senhas da conta de serviço, menor será a probabilidade de que a senha ainda seja válida quando um usuário de má-fé as encontrar.

Geração de registros e monitoramento do VMware Engine

Nas seções a seguir, apresentamos as práticas recomendadas para a geração de registros e o monitoramento de cargas de trabalho de VM e da infraestrutura do VMware Engine, que fornece os recursos que as cargas de trabalho consomem.

Ingerir registros e métricas do VMware Engine

Muitas organizações querem coletar e analisar registros em um "Painel único" centralizado. No Google Cloud, os produtos Cloud Logging e Cloud Monitoring oferecem serviços que podem ser usados para o gerenciamento centralizado de registros e métricas. O VMware Engine pode ser integrado ao Cloud Monitoring usando um agente autônomo. Nessa configuração, o vCenter encaminha métricas como o uso de CPU e memória ESXi para o Cloud Monitoring. É recomendável criar painéis com base nas métricas encaminhadas pelo vCenter ou começar com alguns painéis de amostra publicados no GitHub.

Para coletar registros da plataforma, as nuvens privadas do VMware Engine podem encaminhar registros Syslog para um agregador de registros centralizado. Isso pode ser feito para mensagens do vCenter e do NSX-T Syslog. A coleta, retenção e análise de mensagens Syslog do vCenter tem casos de uso de segurança importantes, como alertas em tempo real baseados em logins de usuários administrativos (ou de emergência), que devem ser executados apenas em circunstâncias excepcionais. Para analisar as mensagens Syslog, é preciso configurar um agregador Syslog, como o Fluentd ou o agente autônomo, para enviar as mensagens ao Cloud Logging.

É recomendável analisar os registros do VMware Engine em um painel central em um único projeto. Se o ambiente do VMware Engine abrange vários projetos, você também precisará agregá-los configurando coletores de registros e escopos de monitoramento.

Usar o agente do Cloud Logging para gerar registros de VMs de cargas de trabalho

As VMs de carga de trabalho do VMware Engine podem enviar registros diretamente para a API Cloud Logging usando o agente do Logging. O agente do Logging é baseado no DaemonSet e faz streaming de registros de aplicativos comuns de terceiros e de software de sistema para o Cloud Logging. Como prática recomendada, alinhe a abordagem para coletar e analisar registros de VMs de cargas de trabalho no VMware Engine com a abordagem para instâncias do Compute Engine e seu estado no local (se aplicável). O uso do agente do Logging no VMware Engine corresponde à abordagem usada para VMs no Compute Engine, de modo que as cargas de trabalho em ambas as plataformas enviem registros para o Cloud Logging.

Aplicar recursos equivalentes das políticas de Transparência no acesso e de Aprovação de acesso

O VMware Engine não oferece suporte à transparência de acesso (AxT) e à aprovação de acesso (AxA) no Google Cloud, mas implementamos processos com recursos equivalentes que podem ser ativados mediante solicitação.

Para a equivalência de transparência no acesso, é preciso considerar várias fontes de registros, incluindo:

  • Registros do vCenter: podem ser exportados usando a configuração do servidor syslog remoto.
  • Registros ESXi: eles podem ser coletados usando a configuração syslog remota. No entanto, é necessário fazer uma solicitação de suporte ao Google Cloud para configurar o encaminhamento de syslog do ESXi.

Se você tiver requisitos regulamentares rigorosos, implementamos uma política para fornecer recursos equivalentes para aprovação de acesso. Nesta política, as operações de serviço padrão exigem que um tíquete de suporte seja gerado com um motivo pelo qual os operadores de serviço de acesso exigem acesso.

As exclusões da Google Cloud Access Approval são aplicáveis.

Criptografia do VMware Engine

Nas seções a seguir, apresentamos as práticas recomendadas para criptografia do armazenamento na nuvem privada e os fatores a serem considerados ao escolher um provedor de chaves para sua nuvem privada.

Usar um provedor de chaves gerenciado pelo Google ativado para criptografia vSAN em repouso

A criptografia dos dados em repouso é implementada com a criptografia baseada em software vSAN. Por padrão, o VMware Engine ativa a criptografia vSAN em cada cluster ESXi e configura um provedor de chaves padrão no vCenter. O Google exige que os clientes mantenham a criptografia vSAN ativada nos clusters ESXi. Além disso, desativar a criptografia vSAN é uma violação dos termos de serviço do VMware Engine. Muitas organizações exigem a criptografia em repouso como parte das políticas da empresa ou são obrigadas por regulamentos a criptografar os dados (por exemplo, NIST, FIPS).

Cada host ESXi criptografa dados usando o modo XTS AES-256 padrão com diferentes chaves de criptografia de dados (DEK, na sigla em inglês) geradas aleatoriamente. A DEK é criptografada com uma chave de criptografia de chaves (KEK, na sigla em inglês) e armazenada apenas no disco de forma criptografada. O servidor vCenter armazena apenas o ID da KEK, mas não a KEK em si, que é armazenada em um Cloud Key Management Service (KMS). É possível escolher o local do Cloud KMS em que a KEK é mantida.

Recomendamos que você use o provedor de chaves padrão gerenciado pelo Google. No entanto, se você precisar gerenciar o Cloud KMS por conta própria, use um Cloud KMS compatível com KMIP 1.1 de terceiros de um dos fornecedores suportados. Em ambos os casos, o provedor de chaves pode ser usado para criptografar dados em repouso e tráfego vMotion em trânsito.

A tabela a seguir destaca as principais diferenças entre o provedor de chaves padrão e as integrações do Cloud KMS de terceiros:

Fornecedor de chaves Prós Contras
Provedor de chaves padrão gerenciado pelo Google
  • Simplicidade: implantada de maneira imediata, sem gerenciamento de fornecedores e sem sobrecarga operacional
  • Suporte completo do Google
  • O método mais simples da capacidade de alternar DEKs/KEKs é o requisito chave
  • Sem custo extra
  • Redundância de zona integrada para alta disponibilidade
  • Não é possível trazer seu próprio material de chave (BYOK)
  • As KEKs são armazenadas e gerenciadas na infraestrutura do Google. Gerenciadores de chaves externos (EKM) não são compatíveis.
Provedor de chaves do Cloud KMS de terceiros
  • Controle total sobre os dados criptografados e a chave de criptografia
  • As chaves protegidas por hardware podem ser armazenadas em um dispositivo HSM.
  • Complexidade adicional e sobrecarga operacional
  • Custo adicional
  • Possível latência adicional, especialmente no caso de KMS SaaS
  • Possível disponibilidade menor

Não é recomendável ativar a criptografia no nível da VM com a criptografia do armazenamento de dados vSAN, porque a eficiência de eliminação de duplicação se aproxima de zero para VMs criptografadas.

Automatizar a rotação de chaves de criptografia de acordo com os padrões da sua organização

Você é responsável pela rotação da KEK usando o VMware Engine vSphere. Esse é o caso com o provedor de chaves padrão e com um Cloud KMS externo. A rotação de KEK pode ser iniciada pelo vCenter ou por meio da API dele. Considere automatizar a rotação de KEKs de acordo com os requisitos da sua organização. Veja um exemplo de script do PowerCLI no GitHub.

Backup e recuperação de desastres do VMware Engine

É importante proteger seus dados contra ameaças como ransomware, corrupção e erro humano. Além disso, aplicativos essenciais para os negócios dependem da disponibilidade dos seus dados virtualmente o tempo todo, o que lhe dá pouco tempo para recuperar dados de interrupções repentinas. Esta seção não contém uma cobertura completa de todos os aspectos de backup e recuperação de desastres que são relevantes para projetar efetivamente uma estratégia de backup e DR para manter seus dados seguros e disponíveis, mas contém considerações importantes ao escolher a melhor estratégia para o ambiente do VMware Engine.

Fazer backup das cargas de trabalho usando o serviço de backup e DR

Com o serviço de backup e DR, o Google Cloud oferece uma solução de backup integrada gerenciada centralmente que pode ser usada para vários casos de uso, incluindo backup de cargas de trabalho no Compute Engine e no Google Cloud VMware Engine. O serviço de backup e DR é a solução única recomendada pelo Google para backups de cargas de trabalho, porque oferece benefícios como um amplo espectro de suporte a cargas de trabalho, pouco espaço, backups incrementais permanentes e opções flexíveis de armazenamento.

O Google Cloud VMware Engine também oferece suporte ao uso de soluções de backup de terceiros baseadas em agentes. Você poderá preferir essas opções se já tiver licenças para um produto de backup de terceiros. Os pré-requisitos para esses tipos de ferramentas incluem o seguinte:

  • Eles fornecem backups no nível do aplicativo
  • Eles são certificados pelos fornecedores de aplicativos
  • Eles são certificados pelo VMware Engine para vSAN
  • Eles são compatíveis com o padrão do protocolo VMware Engine vStorage for Data Protection (VADP) ou fazem backups no nível do aplicativo

Seja qual for a solução de backup escolhida, recomendamos o Cloud Storage como uma opção de armazenamento econômica para retenção de backups a longo prazo. O Cloud Storage é um armazenamento de objetos altamente durável e econômico. Os buckets do Cloud Storage podem ser configurados para replicar automaticamente objetos de armazenamento em várias regiões, o que é ideal para topologias de nuvem multirregionais.

O Cloud Storage também é ideal para arquivamento de longo prazo, já que fornece políticas de ciclo de vida para mover automaticamente objetos de armazenamento para outro nível de armazenamento quando o ciclo de vida deles exceder um valor predefinido. Use essa opção para ter um local de armazenamento de backup econômico e RPOs médios a altos, especialmente se o custo for um fator determinante.

Como alternativa, escolha o armazenamento vSAN para minimizar o RPO. Use essa opção de armazenamento se um custo mais alto para armazenamento de backup for aceitável e os requisitos de RPO não puderem ser atendidos com o Cloud Storage. Evite essa opção para arquivamento de longo prazo, já que há o risco de que os tamanhos dos clusters do VMware Engine se tornem vinculados ao armazenamento.

Implementar a recuperação de desastres com o serviço de backup e DR

Recomendamos restaurar aplicativos no VMware Engine usando o serviço de backup e DR. Para proteger as cargas de trabalho de produção contra interrupções de uma única zona dentro de uma região, é recomendável implantar e operar uma nuvem privada em uma zona secundária dentro da região se o VMware Engine estiver disponível em mais de uma zona dessa região. Se esse não for o caso, a recomendação é restaurar os aplicativos em uma região secundária.

Além do backup e DR do Google Cloud, o VMware Engine é compatível com outras opções de DR, como o SRM do VMware Engine e o Zerto. O SRM do VMware Engine e o Zerto dependem da replicação do vSphere para recuperação de desastres, que geralmente oferece suporte a destinos de RPO mais baixos. Se o objetivo de RPO for de minutos em vez de horas, considere soluções de DR baseadas na replicação do vSphere.

Lista de verificação resumida

A lista de verificação a seguir resume as práticas recomendadas de segurança para usar o VMware Engine.

Tarefa Tópico
Rede do VMware Engine
IAM e permissões do VMware Engine
Geração de registros e monitoramento do VMware Engine
Criptografia do VMware Engine
Backup do VMware Engine e recuperação de desastres

A seguir