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

Este documento descreve as práticas recomendadas de segurança para gerir e configurar o Google Cloud VMware Engine e destina-se a utilizadores que já conhecem o VMware Engine. Se for principiante, pode considerar começar por saber mais acerca dos pré-requisitos e da segurança do VMware Engine.

O VMware Engine tem um modelo de responsabilidade partilhada para a segurança. A segurança fidedigna na nuvem é alcançada através das responsabilidades partilhadas dos clientes e da Google como fornecedor de serviços. Seguir estas práticas recomendadas pode ajudar a poupar tempo, evitar erros e mitigar os efeitos dos pontos de falha.

Redes do VMware Engine

As secções seguintes apresentam práticas recomendadas para a criação de redes num ambiente do VMware Engine.

Identifique e compreenda todos os fluxos de tráfego do seu ambiente

O VMware Engine tira partido das redes do VMware Engine e dos intercâmbios da VPC para ligar uma ligação de rede privada de uma rede de nuvem privada do VMware Engine à sua rede da VPC. O tráfego de entrada de uma VPC no seu ambienteGoogle Cloud ou de uma rede no local atravessa uma rede de unidade de arrendamento gerida pela Google.

Use o serviço de IP público do VMware Engine para a transferência de dados da Internet

O tráfego da Internet pode entrar diretamente numa nuvem privada através do serviço de IP público do VMware Engine. Em alternativa, o tráfego da Internet pode entrar através de um balanceador de carga público em Google Cloud. Nesse caso, o tráfego é encaminhado como qualquer outro tráfego de entrada. Tenha em atenção que estas opções são mutuamente exclusivas. Se forem necessários controlos personalizados para o tráfego de Internet, como filtragem de URLs, IPS/IDS ou inspeção de tráfego fornecida por uma instância ou um serviço central no seu ambiente Google Cloud , deve encaminhar o tráfego destinado à Internet através da rede VPC.

Se isto não se aplicar a si ou tiver os controlos implementados na sua nuvem privada, recomendamos que inclua o serviço de endereço IP externo no VMware Engine. Além disso, recomendamos que use regras de acesso externo para negar padrões de tráfego da Internet que não se aplicam às suas aplicações.

Separe as regras de firewall norte-sul e este-oeste no gateway e na firewall distribuída no NSX do VMware Engine

Configure a firewall distribuída (DFW) no NSX no router lógico de nível 1 para segmentar o tráfego interno entre os seus domínios virtuais de camada 2. A DFW do NSX foi concebida para processar o tráfego de rede (interno) leste-oeste entre segmentos e permite regras de firewall que permitem e negam o tráfego entre instâncias individuais dentro de um segmento.

Para um controlo de acesso à rede detalhado, certifique-se de que aplica uma política predefinida restrita na DFW para negar o tráfego de rede entre instâncias por predefinição. Use a DFW para permitir especificamente o tráfego entre aplicações e entre serviços na sua aplicação.

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

A firewall de gateway do NSX foi concebida para controlar o tráfego norte-sul e é recomendada para exemplos de utilização, como controlar o tráfego num perímetro para outra zona de segurança. Se precisar de configurar o tráfego norte-sul para toda a nuvem privada de forma consistente, configure a firewall do gateway no router de nível 0. Se precisar de configurar o tráfego norte-sul para cada segmento NSX individual, configure a firewall de gateway no router de nível 1.

Além das firewalls do NSX, recomendamos que use a firewall da VPC para permitir e bloquear o tráfego leste-oeste entre cargas de trabalho na nuvem privada do VMware Engine e cargas de trabalho nas VPCs. A transferência de dados de entrada para instâncias do Compute Engine a partir de cargas de trabalho do VMware Engine deve ser restrita por predefinição com apenas tráfego conscientemente aberto.

A transferência de dados de saída para dispositivos de gestão, bem como para o intervalo CIDR do vSphere/vSAN, deve ser bloqueada a partir de VPCs também através da firewall de VPC. Abra apenas a transferência de dados de saída para dispositivos de gestão a partir de anfitriões e endereços IP fidedignos na sua rede. É importante ter em atenção que os dispositivos de gestão não estão num segmento do NSX e, por isso, as regras da DFW não se aplicam para restringir o acesso.

Aplique os princípios de segurança de confiança zero e a microsegmentação no NSX

Use o NSX DFW para implementar controlos de tráfego para segmentos de segurança tão detalhados quanto máquinas virtuais individuais. Este princípio de proteção do tráfego entre VMs individuais que é recusado por predefinição também é frequentemente designado por "microsegmentação", que é uma abordagem mais detalhada para a utilização de firewalls do que a implementação convencional de firewalls entre domínios da camada 3.

A DFW está ativada no kernel do hipervisor em todos os anfitriões do VMware Engine vSphere na sua nuvem privada e pode controlar o fluxo de tráfego entre cargas de trabalho que estão no mesmo segmento NSX ou em segmentos NSX separados. As regras de firewall para permitir o tráfego de e para VMs podem ser definidas organizando as VMs em grupos de políticas, que podem ter critérios de associação flexíveis, como a correspondência de etiquetas ou nomes de VMs.

A microsegmentação permite-lhe implementar uma rede com um controlo detalhado do tráfego, em que um padrão de tráfego tem de ser explicitamente permitido. O conceito de segurança em que todos os fluxos de rede são controlados por processos de validação de identidade e de dispositivo, em vez de confiança implícita, também é frequentemente denominado segurança de confiança zero.

Implemente um dispositivo de firewall de terceiros a partir do portal do Cloud Marketplace para capacidades de IPS/IDS

Se precisar de segurança avançada da camada 7, incluindo capacidades de IDS/IPS para tráfego de entrada na nuvem privada a partir do resto da sua rede ou entre os segmentos de rede do NSX, considere implementar um dispositivo de firewall de terceiros. O dispositivo de terceiros pode ser implementado como um dispositivo com várias NICs entre duas VPCs na sua rede Google Cloud ou na nuvem privada com uma integração com o NSX.

Para uma análise detalhada das arquiteturas do VMware Engine com dispositivos centralizados, que podem ser usados para uma variedade de exemplos de utilização de segurança avançada, como IPS/IDS, DDoS, descarregamento de SSL e muito mais, consulte o documento segurança de rede com dispositivos centralizados no Centro de arquitetura na nuvem.

Use o Google Cloud Armor para ajudar a proteger os serviços Web no VMware Engine contra ataques DDoS

Se encaminhar o tráfego de entrada para cargas de trabalho no VMware Engine através da VPC do cliente, recomendamos que coloque as cargas de trabalho do VMware Engine em grupos de pontos finais de rede híbridos atrás da Cloud Service Mesh e tire partido do equilibrador de carga HTTP(S) externo. Qualquer uma das configurações permite-lhe incluir o Google Cloud Armor para aplicações viradas para o público, mitigando ataques DDoS e vulnerabilidades comuns, como injeções de SQL ou scripting entre sites.

Se precisar de funcionalidades de Service Mesh, como gestão de tráfego avançada através do proxy Envoy ou integração do serviço de autoridade de certificação, 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 numa das seguintes configurações:

Ligue-se aos Google Cloud Serviços em privado sem acesso à Internet

As cargas de trabalho da nuvem privada do VMware Engine podem aceder a Google Cloud APIs, como a API Cloud Storage, através do acesso privado à Google. Recomendamos que use o acesso privado do Google para aceder aos serviços Google sem enviar tráfego através da Internet, uma vez que reduz o custo e a latência da transferência de dados de saída. Isto também elimina a necessidade de um caminho de rede para a Internet para cargas de trabalho que só precisam de acesso a APIs Google. Siga a análise detalhada do acesso privado da Google para ver mais detalhes técnicos e passos de configuração.

Da mesma forma, as cargas de trabalho do VMware Engine que precisam de aceder a Google Cloud recursos de uma rede de produtor de serviços, como instâncias do Cloud SQL ou do Memorystore, devem ligar-se de forma privada através do PSA. Para mais informações, visite a secção sobre o PSA para o VMware Engine.

Encriptar a comunicação entre o seu ambiente nas instalações e o Google Cloud

As cargas de trabalho no VMware Engine que precisam de comunicar com sistemas no local devem estabelecer ligação através de um canal encriptado. Recomendamos uma abordagem em camadas para a encriptação em trânsito entre os seus centros de dados no local e oGoogle Cloud. A ligação entre os sistemas no local e Google Cloud pode ser encriptada configurando o Cloud VPN com um túnel IPsec ou usando o IPsec incorporado em anexos de VLAN do Interconnect. Além disso, a encriptação da camada de aplicação deve ser ativada entre os componentes da aplicação através do TLS.

Ajude a proteger os seus dados contra a exfiltração através dos VPC Service Controls

Recomendamos que mitigue os riscos de exfiltração de dados através dos VPC Service Controls, colocando os seus recursos sensíveis, como contentores do Cloud Storage e conjuntos de dados do BigQuery, num perímetro dos VPC Service Controls. As cargas de trabalho que precisam de aceder a dados dentro de um perímetro também têm de ser colocadas no perímetro. Especificamente, o projeto que aloja a nuvem privada tem de fazer parte do perímetro dos VPC Service Controls para aceder a recursos protegidos pelos VPC Service Controls. Google Cloud

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

IAM e autorizações do VMware Engine

As secções seguintes apresentam práticas recomendadas para autorizações de utilizadores num ambiente do VMware Engine. É importante ter cuidado com as autorizações no ambiente do VMware Engine e no Google Cloud projeto em que a nuvem privada está implementada.

Use funções predefinidas ou funções personalizadas para conceder acesso

A abordagem do VMware Engine para gerir funções e autorizações do vSphere pode ser usada da mesma forma que está habituado a usar noutros ambientes do VMware Engine. No entanto, atividades como a implementação de um cluster requerem autorizações na gestão de identidade e de acesso (IAM). A tabela seguinte apresenta os gestores de acesso relevantes, as origens de identidade às quais concedem autorizações e exemplos de atividades que permitem.

Plataforma Componente Origem da identidade Onde configurar as autorizações Exemplos de atividades
Google Cloud Portal do VMware Engine Cloud ID Gestão de identidade e de acesso Implementação e cancelamento de nuvem privada, implementação e cancelamento de clusters, por exemplo.
VMware Engine vCenter LDAP Anfitriões e clusters, VMs e pastas, armazenamentos de dados na IU do vCenter Criação de VMs, criação de pastas de VMs, criação e eliminação de objetos de repositórios de dados, por exemplo
NSX LDAP "Utilizadores e funções" na IU do NSX Manager Criação de segmentos NSX, configuração de firewall, configuração de balanceador de carga, por exemplo.
vCenter Sistema operativo convidado da VM Active Directory, LDAP, utilizadores locais, por exemplo Sistema operativo convidado Início de sessão SSH ou RDP, operações de ficheiros, por exemplo

No Google Cloud IAM, existem duas funções predefinidas com autorizações para o portal do VMware Engine:

  • Administrador do serviço VMware Engine: concede acesso total ao serviço VMware Engine no Google Cloud.
  • VMware Engine Service Viewer: concede acesso só de leitura ao serviço VMware Engine no Google Cloud.

Estas autorizações estão relacionadas com ações no portal do VMware Engine e não estão relacionadas com ações na API nem na CLI. Tenha em atenção que as funções básicas também incluem a capacidade de gerir o serviço VMware Engine (proprietário, editor) ou ver os detalhes do serviço (leitor). Geralmente, recomendamos que use funções predefinidas em vez de funções básicas, porque oferecem autorizações mais detalhadas.

O acesso programático ao VMware Engine através de contas de serviço que usam a API ou a CLI deve ser restrito através de funções predefinidas ou funções personalizadas, porque incluem autorizações mais detalhadas 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 autorizações das funções predefinidas, então recomendamos que crie uma função personalizada.

Escolha uma localização adequada para a atribuição de funções do IAM na hierarquia de recursos da sua organização. Se estiver a executar todas as suas nuvens privadas do VMware Engine num único projeto, só pode atribuir funções ao nível do projeto. Se existirem requisitos técnicos ou organizacionais que façam com que as suas nuvens privadas estejam localizadas em projetos separados, defina as funções necessárias numa pasta comum aos projetos usados para as suas nuvens privadas.

As autorizações do IAM do Google Cloud não são necessárias para atividades que só precisam de ser realizadas no vCenter, NSX ou HCX. Os funcionários que só precisam de operar estes ambientes não precisam das funções do IAM indicadas anteriormente. Em alternativa, devem usar identidades LDAP com autorizações configuradas no vCenter e no NSX. Recomendamos que atribua as funções de administrador ou visitante do serviço VMware Engine apenas a um número muito limitado de utilizadores, uma vez que estas funções concedem acesso à poderosa conta de utilizador CloudOwner para o vCenter e à conta de utilizador de administrador para o NSX. Estas contas de utilizador só devem ser usadas para a configuração inicial ou procedimentos de emergência.

Restrinja e audite ativamente o acesso de administrador

A função de administrador do serviço VMware Engine é muito poderosa e só deve ser atribuída a utilizadores que precisam de gerir o ciclo de vida da nuvem privada do VMware Engine e dos respetivos clusters. Normalmente, a adição ou a eliminação manual de clusters e nós é uma ação que não ocorre com frequência e pode ter um grande impacto na faturação ou na disponibilidade do cluster. Atribua esta função apenas a muito poucas pessoas na sua organização.

Certifique-se de que audita regularmente a quem foi atribuída a função de administrador do serviço do VMware Engine, diretamente no projeto usado para o VMware Engine ou num dos níveis principais da hierarquia de recursos. Esta auditoria deve incluir outras funções, como as funções básicas de editor e proprietário, que incluem autorizações críticas relacionadas com o VMware Engine. Pode usar serviços como o recomendador de funções da IAM para ajudar a identificar funções com privilégios excessivos.

Configure uma origem de identidade LDAP ou Active Directory

Deve configurar um fornecedor de identidade que suporte a autenticação LDAP, como o Active Directory, para ativar a autenticação do utilizador para o vCenter e o NSX Manager. Esta é uma prática recomendada para ter uma gestão central do ciclo de vida da identidade, gestão de grupos, gestão de palavras-passe e muito mais. Tenha em atenção que a associação direta do vCenter e do NSX ao Active Directory para autenticação integrada do Windows não é suportada.

Rode as palavras-passe das contas de serviço incorporadas

O VMware Engine gera credenciais para aceder a dispositivos de gestão na nuvem privada (como o vCenter, o NSX e o HCX). Recomendamos que estabeleça um processo para rodar as palavras-passe da conta de serviço do vCenter predefinida CloudOwner@gve.local e do administrador da conta de serviço do NSX predefinido. Ambas as contas de utilizador só devem ser usadas para a configuração inicial e procedimentos de emergência, e as respetivas palavras-passe devem ser alteradas regularmente (por exemplo, a cada 60 ou 90 dias). Em alternativa, altere regularmente as palavras-passe das contas de utilizadores da solução que são usadas frequentemente para a integração de ferramentas de terceiros. Quanto mais frequentemente rodar as palavras-passe das contas de serviço, menor é a probabilidade de a palavra-passe ainda ser válida quando um agente malicioso a encontra.

Registo e monitorização do VMware Engine

As secções seguintes apresentam práticas recomendadas para o registo e a monitorização das cargas de trabalho das VMs e da infraestrutura do VMware Engine, que fornece os recursos que as cargas de trabalho consomem.

Carregue registos e métricas do VMware Engine

Muitas organizações querem recolher e analisar registos num "painel único" centralizado. No Google Cloud, os produtos Cloud Logging e Cloud Monitoring oferecem serviços que podem ser usados para a gestão centralizada de registos e métricas. O VMware Engine pode ser integrado com o Cloud Monitoring através de um agente autónomo. Nesta configuração, o vCenter encaminha métricas, como a utilização de memória e CPU do ESXi, para o Cloud Monitoring. Recomendamos que crie painéis de controlo com base em métricas encaminhadas pelo vCenter ou que comece com alguns painéis de controlo de exemplo publicados no GitHub.

Para recolher registos da plataforma, as nuvens privadas do VMware Engine podem encaminhar registos Syslog para um agregador de registos centralizado. Isto pode ser feito para mensagens de syslog do vCenter e do NSX. A recolha, a retenção e a análise de mensagens Syslog do vCenter têm exemplos de utilização de segurança importantes, como alertas em tempo real baseados em inícios de sessão de utilizadores administrativos (ou utilizadores de emergência), que devem ser realizados apenas em circunstâncias excecionais. Para analisar mensagens Syslog, tem de configurar um agregador Syslog, como o Fluentd ou o agente autónomo, para retransmitir as mensagens para o Cloud Logging.

Recomendamos que analise os registos do VMware Engine num painel de controlo centralizado num único projeto. Se o seu ambiente do VMware Engine abranger vários projetos, também tem de agregar os projetos configurando destinos de registo e âmbitos de monitorização.

Use o agente do Cloud Logging para o registo de VMs de cargas de trabalho

As VMs de carga de trabalho do VMware Engine podem enviar registos diretamente para a API Cloud Logging através do agente Logging. O agente de registos baseia-se no fluentd e transmite registos de aplicações de terceiros comuns e software de sistema para o Cloud Logging. Como prática recomendada, alinhe a abordagem para recolher e analisar registos de VMs de cargas de trabalho no VMware Engine com a abordagem para instâncias do Compute Engine e a sua propriedade no local (se aplicável). A utilização 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 enviam os respetivos registos para o Cloud Logging.

Aplique capacidades equivalentes das políticas de Transparência de acesso e Aprovação de acesso

Embora o VMware Engine não suporte a transparência de acesso (AxT) nem a aprovação de acesso (AxA) no Google Cloud, implementámos processos com capacidades equivalentes que podem ser ativados mediante pedido.

Para a equivalência da transparência de acesso, tem de considerar várias fontes de registos, incluindo:

  • Registos do vCenter: exportáveis através da configuração do servidor syslog remoto.
  • Registos do ESXi: estes podem ser recolhidos através da configuração remota do syslog. No entanto, tem de apresentar um pedido de apoio técnico à Google Cloud para configurar o encaminhamento do syslog do ESXi.

Se tiver requisitos regulamentares rigorosos, implementamos uma política para fornecer capacidades equivalentes para a aprovação de acesso. Nesta política, as operações de serviço padrão requerem a geração de um pedido de apoio técnico com um motivo pelo qual os operadores do serviço de acesso requerem acesso.

Aplicam-seGoogle Cloud exclusões da aprovação de acesso.

Encriptação do VMware Engine

As secções seguintes apresentam práticas recomendadas para a encriptação do armazenamento na nuvem privada e fatores determinantes a ter em conta ao escolher um fornecedor de chaves para a sua nuvem privada.

Use um Google-owned and managed key fornecedor ativado para a encriptação em repouso do vSAN

A encriptação de dados em repouso é implementada através da encriptação baseada em software do vSAN. Por predefinição, o VMware Engine ativa a encriptação vSAN em cada cluster ESXi e configura um fornecedor de chaves predefinido no vCenter. A Google exige que os clientes mantenham a encriptação do vSAN ativada nos respetivos clusters ESXi e a desativação da encriptação do vSAN constitui uma violação dos termos de serviço do VMware Engine. Muitas organizações exigem a encriptação em repouso como parte das políticas da empresa ou são obrigadas por regulamentos a encriptar dados (por exemplo, NIST, FIPS).

Cada anfitrião ESXi encripta os dados através do modo AES-256 XTS padrão com chaves de encriptação de dados (DEK) diferentes geradas aleatoriamente. A DEK é encriptada através de uma chave de encriptação de chaves (KEK) e armazenada apenas no disco de forma encriptada. O servidor vCenter armazena apenas o ID da KEK, mas não a própria KEK, que é armazenada num Cloud Key Management Service (KMS). Pode escolher a localização do Cloud KMS onde a sua KEK é mantida.

Recomendamos que use o fornecedor de chaves predefinido gerido pela Google. No entanto, se tiver de gerir o Cloud KMS por si, pode usar um Cloud KMS compatível com KMIP 1.1 de um dos fornecedores suportados. Em ambos os casos, o fornecedor de chaves pode ser usado para encriptar dados em repouso e o tráfego de vMotion em trânsito.

A tabela seguinte realça as principais diferenças entre o fornecedor de chaves predefinido e as integrações do Cloud KMS de terceiros:

Fornecedor de chaves Vantagens Desvantagens
Fornecedor Google-owned and managed key predefinido
  • Simplicidade: implementado "pronto a usar" sem gestão de fornecedores nem encargos operacionais
  • Apoio técnico ponto a ponto da Google
  • O método mais simples de rodar DEKs/KEKs é o requisito fundamental
  • Sem custos adicionais
  • Redundância de zona incorporada para alta disponibilidade
  • Não é possível trazer o seu próprio material de chaves (BYOK)
  • As KEKs são armazenadas e geridas na infraestrutura da Google. Os gestores de chaves externos (EKM) não são suportados.
Fornecedor de chaves do Cloud KMS externo
  • Controlo total sobre os dados encriptados e a chave de encriptação
  • As chaves suportadas por hardware podem ser armazenadas num dispositivo HSM
  • Complexidade e sobrecarga operacional adicionais
  • Custo adicional
  • Possível latência adicional, especialmente no caso do KMS de SaaS
  • Possível disponibilidade mais baixa

Tenha em atenção que não recomendamos que ative a encriptação ao nível da VM juntamente com a encriptação do banco de dados vSAN porque a eficiência da desduplicação aproxima-se de zero para VMs encriptadas.

Automatize a rotação das chaves de encriptação de acordo com as normas da sua organização

É responsável pela rotação da KEK através do VMware Engine vSphere. Isto aplica-se tanto ao fornecedor de chaves predefinido como a um Cloud KMS externo. A rotação da KEK pode ser iniciada a partir do vCenter ou através da respetiva API. Considere automatizar a rotação da KEK de acordo com os requisitos da sua organização. Pode encontrar um exemplo de script do PowerCLI no GitHub.

Cópia de segurança e recuperação de desastres do VMware Engine

É importante proteger os seus dados contra ameaças como ransomware, corrupção e erro humano. Além disso, as aplicações críticas para a empresa dependem da disponibilidade dos seus dados praticamente em todos os momentos, o que lhe deixa pouco tempo para recuperar dados de interrupções súbitas. Esta secção não contém uma cobertura completa de todos os aspetos de cópia de segurança e recuperação de desastres relevantes para conceber eficazmente uma estratégia de cópia de segurança e recuperação de desastres para manter os seus dados seguros e disponíveis, mas contém considerações importantes ao escolher a estratégia certa para o seu ambiente do VMware Engine.

Faça uma cópia de segurança das suas cargas de trabalho com o serviço de cópias de segurança e RD

O serviço de cópia de segurança e recuperação de desastres Google Cloud oferece uma solução de cópia de segurança integrada e gerida centralmente que pode ser usada para uma variedade de exemplos de utilização, incluindo a cópia de segurança de cargas de trabalho no Compute Engine e no Google Cloud VMware Engine. O serviço de cópia de segurança e recuperação de desastres é a solução única recomendada pela Google para cópias de segurança de cargas de trabalho, uma vez que oferece vantagens como um vasto espetro de suporte de cargas de trabalho, cópias de segurança incrementais para sempre eficientes em termos de espaço e opções de armazenamento flexíveis.

Google Cloud O VMware Engine também suporta a utilização de soluções de cópia de segurança de terceiros baseadas em agentes. Pode preferir estas opções se já tiver licenças para um produto de cópia de segurança de terceiros. Os pré-requisitos para estes tipos de ferramentas incluem o seguinte:

  • Oferecem cópias de segurança ao nível da aplicação
  • Estão certificados pelos fornecedores das aplicações
  • Estão certificados pelo VMware Engine para vSAN
  • Suportam a norma do protocolo da API vStorage do VMware Engine para proteção de dados (VADP) ou fazem cópias de segurança ao nível da aplicação

Independentemente da solução de cópia de segurança da sua escolha, recomendamos o armazenamento na nuvem como uma opção de armazenamento económica para a retenção a longo prazo de cópias de segurança. O Cloud Storage é um armazenamento de objetos altamente duradouro e económico. Os contentores 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 o arquivo a longo prazo, uma vez que fornece políticas de ciclo de vida para mover automaticamente objetos de armazenamento para outro nível de armazenamento assim que o respetivo tempo de vida excede um valor predefinido. Use esta opção para uma localização de armazenamento de cópias de segurança rentável e RPOs médios a elevados, especialmente se o custo for um fator determinante.

Em alternativa, pode escolher o armazenamento vSAN para minimizar o RPO. Use esta opção de armazenamento se um custo mais elevado para o armazenamento de cópias de segurança for aceitável e os requisitos de RPO não puderem ser cumpridos com o Cloud Storage. Evite esta opção para o arquivo a longo prazo, uma vez que existe o risco de os tamanhos dos clusters do VMware Engine ficarem limitados pelo armazenamento.

Implemente a recuperação de desastres com o serviço de cópias de segurança e RD

Recomendamos que restaure as aplicações no VMware Engine através do serviço de cópia de segurança e recuperação de desastres. Para ajudar a proteger as suas cargas de trabalho de produção contra interrupções de uma única zona numa região, recomendamos que implemente e opere uma nuvem privada numa zona secundária na região se o VMware Engine estiver disponível em mais do que uma zona dessa região. Se não for esse o caso, recomendamos que restaure as suas aplicações numa região secundária.

Além da Google Cloud cópia de segurança e da recuperação de desastres, o VMware Engine é compatível com outras opções de recuperação de desastres, como o VMware Engine SRM e o Zerto. O VMware Engine SRM e o Zerto baseiam-se na replicação do vSphere para a recuperação de desastres, que geralmente suporta objetivos de RPO mais baixos. Se o seu alvo de RPO for minutos em vez de horas, considere soluções de recuperação de desastres baseadas na replicação do vSphere.

Resumo da lista de verificação

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

Tarefa Tópico
Redes do VMware Engine
IAM e autorizações do VMware Engine
Registo e monitorização do VMware Engine
Encriptação do VMware Engine
Cópia de segurança e recuperação de desastres do VMware Engine

O que se segue?