Prácticas recomendadas para la seguridad de VMware Engine
Este documento describe las prácticas recomendadas de seguridad para administrar y configurando Google Cloud VMware Engine y está dirigido a usuarios que ya conocen con VMware Engine. Si eres principiante, podrías considerar empezar a aprender sobre los requisitos previos y VMware Engine seguridad.
VMware Engine tiene un modelo de responsabilidad compartida para la seguridad. La seguridad de confianza en la nube se logra a través de las responsabilidades compartidas de los clientes y Google como proveedor de servicios. Sigues estos las prácticas recomendadas pueden ayudarte a ahorrar tiempo, evitar errores y mitigar los efectos de puntos de fallo.
Redes de VMware Engine
En las siguientes secciones, se presentan las prácticas recomendadas para establecer redes en un entorno de VMware Engine.
Identificar y comprender todos los flujos de tráfico de tu entorno
VMware Engine aprovecha las redes de VMware Engine y los vinculaciones de VPC para conectar una conexión de red privada desde una red de nube privada de VMware Engine a tu red de VPC. El tráfico entrante desde una VPC en tu de Google Cloud o desde una red local atraviesa una Red de unidad de usuario administrada por Google.
Usa el servicio de IP pública de VMware Engine para la transferencia de datos por Internet
El tráfico de Internet puede ingresar a una nube privada directamente con el servicio de IP pública de VMware Engine. Como alternativa, el tráfico de Internet puede ingresar a través de un balanceador de cargas público en Google Cloud. En ese caso, el tráfico se enruta como cualquier otro tráfico entrante. Ten en cuenta que estos las opciones son mutuamente excluyentes. Si se requieren controles personalizados para acceder a Internet tráfico, como filtros de URL, IPS/IDS o inspección de tráfico que proporciona un instancia o servicio central en tu entorno de Google Cloud, deberías enrutar el tráfico vinculado a Internet a través de la red de VPC.
Si esto no se aplica en su caso o si tiene los controles implementados en tu nube privada, te recomendamos que incluyas el servicio de dirección IP externa en VMware Engine. Además, recomendamos usar reglas de acceso externas para denegar los patrones de tráfico de Internet que no se aplican a tu aplicaciones.
Reglas de firewall separadas de norte a sur y de este a oeste en la puerta de enlace y en el firewall distribuido en VMware Engine NSX-T
Configura el firewall distribuido (DFW) en NSX-T en el router lógico de nivel 1 para segmentar el tráfico interno entre tus dominios virtuales de capa 2. El DFW de NSX está diseñado para controlar el tráfico de red este-oeste (interno) entre segmentos y permite reglas de firewall que permiten y rechazan el tráfico entre instancias individuales dentro de un segmento.
Para obtener un control de acceso a la red detallado, asegúrate de aplicar una política predeterminada restringida en el DFW para denegar el tráfico de red entre instancias de forma predeterminada. Usa el DFW para permitir específicamente el tráfico entre aplicaciones y entre servicios dentro de tu aplicación.
Configura el firewall de puerta de enlace de NSX para controlar el tráfico norte-sur que entra y sale de la nube privada.
El firewall de puerta de enlace de NSX está diseñado para controlar el tráfico de norte a sur y se recomienda para casos de uso como controlar el tráfico en un perímetro a otra zona de seguridad. Si necesitas configurar el tráfico norte-sur de toda la nube privada de forma coherente, configura el firewall de la puerta de enlace en el router de nivel 0. Si necesitas configurar el tráfico norte-sur para cada segmento individual de NSX-T, configura el firewall de la puerta de enlace en el router de nivel 1.
Además de los firewalls de NSX-T, se recomienda usar el firewall de VPC para permitir y bloquear el tráfico este-oeste entre las cargas de trabajo de la nube privada de VMware Engine y las cargas de trabajo de las VPC. La transferencia de datos entrantes a las instancias de Compute Engine desde las cargas de trabajo de VMware Engine debe restringirse de forma predeterminada, con solo el tráfico abierto de forma consciente.
La transferencia de datos salientes a los dispositivos de administración y al rango de CIDR de vSphere/vSAN también debe bloquearse desde las VPC con el firewall de VPC. Solo abre la transferencia de datos saliente hacia los dispositivos de administración desde hosts y direcciones IP de confianza dentro de tu red. Es importante tener en cuenta que los dispositivos de administración no se encuentran dentro de un segmento de NSX-T y, por lo tanto, las reglas de DFW no se aplican para restringir el acceso.
Aplica los principios de seguridad de confianza cero y la microsegmentación en NSX-T
Usa el DFW de NSX-T para implementar controles de tráfico para segmentos de seguridad que sean tan detallados como las máquinas virtuales individuales. Este principio de protección el tráfico entre VMs individuales que se rechaza de forma predeterminada también se denomina "Microsegmentación", que es un enfoque más detallado para el uso de firewall que el convencional implementación de firewalls entre dominios de capa 3.
El DFW está habilitado en el kernel del hipervisor en todos los hosts de vSphere de VMware Engine de tu nube privada y puede controlar el flujo de tráfico entre cargas de trabajo que se encuentran en el mismo segmento de NSX o en segmentos separados. Para definir las reglas de firewall que permitan el tráfico hacia y desde las VMs, organiza las VMs en grupos de políticas, que pueden tener criterios de membresía flexibles, como la coincidencia de etiquetas o nombres de VMs.
La microsegmentación te permite implementar una red con un control de tráfico detallado en el que se debe permitir de forma explícita un patrón de tráfico. El de seguridad en el que todos los flujos de red están controlados por la identidad y el de seguridad en lugar de la confianza implícita también se denomina ninguna Confiar Seguridad.
Implementa un dispositivo de firewall de terceros desde el portal de Cloud Marketplace para capacidades de IPS/IDS.
Si necesitas seguridad avanzada de capa 7, incluidas las capacidades IDS/IPS para tráfico entrante a la nube privada desde el resto de tu red o entre en tus segmentos de red NSX-T, considera implementar un firewall de Google. El dispositivo de terceros se puede implementar como una NIC de múltiples de Google entre dos VPC en tu red de Google Cloud nube privada virtual con una integración en NSX-T.
Para obtener un análisis detallado de las arquitecturas de VMware Engine con dispositivos centralizados, que se pueden usar para una variedad de casos de uso de seguridad avanzada, como IPS/IDS, DDoS, descarga de SSL y mucho más, consulta el documento Seguridad de red con dispositivos centralizados en el Cloud Architecture Center.
Usa Google Cloud Armor para proteger los servicios web en VMware Engine de los ataques DDoS
Si enrutas el tráfico entrante a las cargas de trabajo en VMware Engine a través de a la VPC del cliente, recomendamos ubicar las cargas de trabajo de VMware Engine en grupos de extremos de red híbridos detrás de Cloud Service Mesh balanceador de cargas HTTP(S) externo. Cualquier configuración te permite incluir Google Cloud Armor para aplicaciones orientadas al público, lo que mitiga los ataques DDoS y las vulnerabilidades comunes, como las inyecciones de SQL o las secuencias de comandos entre sitios.
Si necesitas funciones de la malla de servicios, como la administración avanzada del tráfico el proxy Envoy o la integración de Certificate Authority Service, te recomendamos la malla de servicios en la nube. En todos los demás casos, recomendamos el balanceador de cargas HTTP(S) externo.
Sigue la documentación sobre cómo se pueden agregar cargas de trabajo de VMware Engine a los NEG híbridos en cualquiera de las siguientes configuraciones:
- Balanceo de cargas de HTTP(S) externo regional con conectividad híbrida
- Balanceador de cargas de HTTP(S) externo global con conectividad híbrida
Conéctate a los servicios de Google Cloud de forma privada sin acceso a Internet
Las cargas de trabajo de la nube privada de VMware Engine pueden acceder a las APIs de Google Cloud, como la API de Cloud Storage, con el Acceso privado a Google. Te recomendamos que uses el Acceso privado a Google para acceder a los servicios de Google sin enviar tráfico a través de Internet, ya que reduce el costo y la latencia de la transferencia de datos salientes. Esto también quita la necesidad de una ruta de red a Internet para las cargas de trabajo que solo necesitan Acceso a las APIs de Google. Sigue el análisis detallado del Acceso privado a Google para obtener más información detalles técnicos y pasos de configuración.
Del mismo modo, las cargas de trabajo de VMware Engine que necesitan acceder Recursos de Google Cloud de una red de productor de servicios, como Las instancias de Cloud SQL o Memorystore se deben conectar de forma privada usando PSA. Para obtener más información, consulta la sección sobre PSA para VMware Engine.
Encripta la comunicación entre tu entorno local y Google Cloud
Cargas de trabajo en VMware Engine que deben comunicarse con entornos locales los sistemas deben conectarse mediante un canal encriptado. Recomendamos un enfoque en capas para la encriptación en tránsito entre tus centros de datos locales y Google Cloud. El vínculo entre los sistemas locales y Google Cloud pueden encriptarse configurando Cloud VPN con un túnel IPsec con el IPsec integrado en los adjuntos de VLAN de la interconexión. Además, La encriptación de la capa de aplicación debe habilitarse entre los componentes de la aplicación con TLS.
Protege tus datos contra el robo con los Controles del servicio de VPC
Se recomienda mitigar los riesgos de robo de datos con los Controles del servicio de VPC colocando recursos sensibles, como buckets de Cloud Storage Conjuntos de datos de BigQuery en un perímetro de Controles del servicio de VPC. Las cargas de trabajo que necesitan acceder a los datos dentro de un perímetro también deben colocarse en él. Específicamente, el proyecto de Google Cloud que aloja la nube privada necesita formar parte del perímetro de los Controles del servicio de VPC y acceder a los recursos protegidas por los Controles del servicio de VPC.
Debes configurar políticas de transferencia de datos de entrada y salida en tus Controles del servicio de VPC para permitir que las APIs del servicio de productor de VMware Engine el perímetro. Para obtener una guía detallada sobre la configuración, sigue las páginas de nuestra documentación sobre los controles del servicio de VPC con VMware Engine.
IAM y permisos de VMware Engine
En las siguientes secciones, se presentan las prácticas recomendadas para los permisos del usuario en un Entorno de VMware Engine. Es importante que tengas en cuenta los permisos en el entorno de VMware Engine y el proyecto de Google Cloud en la que se implementa la nube privada.
Usa roles predefinidos o personalizados para otorgar acceso
El enfoque de VMware Engine para administrar funciones y permisos de vSphere pueden aprovecharse de la misma manera que se suele aprovechar entornos de VMware Engine. Sin embargo, actividades como la implementación de un clúster requieren permisos en Identity and Access Management (IAM). La siguiente tabla enumera los administradores de acceso relevantes, las fuentes de identidad a las que otorgan permisos y las actividades de ejemplo que habilitan.
| Plataforma | Componente | Fuente de identidad | Dónde configurar los permisos | Actividades de ejemplo |
|---|---|---|---|---|
| Google Cloud | Portal de VMware Engine | Cloud Identity | Administración de identidades y accesos | Implementación y cancelación de nubes privadas, implementación y cancelación de clústeres, por ejemplo. |
| VMware Engine | vCenter | LDAP | Hosts y clústeres, VM y carpetas, almacenes de datos en la IU de vCenter | Creación y eliminación de VM, creación de carpetas de VM y creación y eliminación de objetos de almacén de datos, por ejemplo |
| NSX-T | LDAP | "Usuarios y roles" en la IU de NSX-T Manager | Por ejemplo, la creación de segmentos de NSX, la configuración de firewall o la configuración de balanceador de cargas. | |
| vCenter | Sistema operativo invitado de VM | Active Directory, LDAP o Usuarios locales, por ejemplo | Sistema operativo invitado | Acceso a SSH o RDP, operaciones de archivos, por ejemplo |
En Google Cloud IAM, existen dos roles predefinidos con permisos para el portal de VMware Engine:
- Administrador del servicio de VMware Engine otorga acceso completo a la Servicio de VMware Engine en Google Cloud.
- Visualizador del servicio de VMware Engine: Ofrece acceso de solo lectura al servicio de VMware Engine en Google Cloud.
Estos permisos se relacionan con las acciones del portal de VMware Engine y y no se relacionan con las acciones en la API o en la CLI. Ten en cuenta que también los roles básicos incluyen la capacidad de administrar el servicio de VMware Engine (propietario, Editor) o para ver los detalles del servicio (Visualizador). Generalmente, se recomienda usan roles predefinidos en lugar de básicos porque brindan más con permisos precisos.
Acceso programático a VMware Engine con cuentas de servicio mediante La API o la CLI deben restringirse mediante roles predefinidos o personalizados ya que incluyen permisos más detallados que se aplican solo a VMware Engine. Si el acceso programático se usa solo para una tarea que requiere solo un subconjunto específico de permisos de los roles predefinidos, se recomienda crear un rol personalizado.
Elige una ubicación adecuada para la asignación de roles de IAM en la jerarquía de recursos de tu organización. Si estás ejecutando todas tus Hay nubes privadas de VMware Engine en un solo proyecto. asignados a nivel de proyecto. Si hay requisitos técnicos u organizacionales que provoquen que tus nubes privadas se ubiquen en proyectos separados, define los roles necesarios en una carpeta común a los proyectos usados para tu y nubes privadas.
Los permisos de Cloud IAM no son necesarios para actividades que solo se debe realizar en vCenter, NSX-T o HCX. El personal que solo necesita operar estos entornos no requiere los roles de IAM enumerados anteriormente. En su lugar, deben usar las identidades LDAP con permisos configurados en vCenter y NSX-T. Te recomendamos que proporciones los roles de administrador de servicios de VMware Engine o de visor de servicios de VMware Engine solo a una cantidad muy limitada de usuarios, ya que estos roles otorgan acceso a la poderosa cuenta de usuario de CloudOwner para vCenter y a la cuenta de usuario de administrador de NSX-T. Estas cuentas de usuario solo deben usarse para la configuración inicial o los procedimientos de emergencia.
Restringe y audita de forma activa el acceso de los administradores
El rol Administrador de servicios de VMware Engine es muy potente y solo debería asignarse a los usuarios que necesitan administrar el ciclo de vida del Nube privada de VMware Engine y sus clústeres. Por lo general, los comandos manuales agregar o borrar clústeres y nodos es una acción que no ocurre con frecuencia y pueden tener un gran impacto en la facturación o la disponibilidad del clúster. Asigna este rol solo a muy pocas personas de tu organización.
Asegúrate de auditar con frecuencia a quién se le asignó el rol de administrador de servicios de VMware Engine, ya sea directamente en el proyecto que se usa para VMware Engine o en uno de los niveles superiores de la jerarquía de recursos. Esta auditoría debe incluir otros roles, como los roles básicos de editor y propietario que incluyen permisos fundamentales relacionados con VMware Engine. Puedes usar servicios como el recommender de roles de IAM para ayudar a identificar roles con privilegios excesivos.
Configura una fuente de identidad de LDAP o Active Directory
Se debe configurar un proveedor de identidad que admita la autenticación de LDAP, como Active Directory, para habilitar la autenticación de usuarios en vCenter y NSX Manager. Esta es una práctica recomendada para tener una administración central del ciclo de vida de la identidad, la administración de grupos, la administración de contraseñas y mucho más. Ten en cuenta que directamente unión de vCenter y NSX-T a Active Directory para Windows integrado no se admite la autenticación.
Rota las contraseñas de las cuentas de servicio integradas
VMware Engine genera credenciales para acceder a los dispositivos de administración en la nube privada (como vCenter, NSX-T y HCX). se recomienda establecer un proceso para rotar las contraseñas del servicio de vCenter predeterminado CloudOwner@gve.local y el administrador de cuentas de servicio de NSX-T predeterminado. Ambas cuentas de usuario solo deben usarse para la configuración inicial y que los procedimientos de emergencia y sus contraseñas se cambien con regularidad (por ejemplo, cada 60 o 90 días). También puede rotar periódicamente las contraseñas de las cuentas de usuario de la solución que de uso general para integrar herramientas de terceros. Cuanto más a menudo rotes las contraseñas de la cuenta de servicio, menos probabilidades habrá de que la contraseña siga siendo válida cuando una persona/entidad que actúa de mala fe la encuentre.
Registro y supervisión de VMware Engine
En las siguientes secciones, se presentan las prácticas recomendadas para el registro y la supervisión las cargas de trabajo de VM y la infraestructura de VMware Engine, que proporciona los recursos que consumen las cargas de trabajo.
Transfere registros y métricas de VMware Engine
Muchas organizaciones quieren recopilar y analizar registros en una solución centralizada Panel de vidrio". En Google Cloud, los servicios de Cloud Logging Los productos de Cloud Monitoring ofrecen servicios que pueden usarse para la administración de registros y métricas. VMware Engine se puede integrar a Cloud Monitoring con un agente independiente. En esta configuración, vCenter reenvía métricas como el uso de memoria y CPU ESXi a Cloud Monitoring. Se recomienda crear paneles basados en las métricas que reenvía vCenter o comenzar con algunos paneles de ejemplo que se publicaron en GitHub.
Para recopilar registros de plataforma, las nubes privadas de VMware Engine pueden reenviar De los registros Syslog a un agregador de registros centralizado Esto se puede hacer con vCenter y NSX-T Syslog. Recopilación, retención y análisis de mensajes Syslog de vCenter tiene casos de uso de seguridad importantes, como alertas inicios de sesión de usuarios administrativos (o usuarios de emergencia), lo que solo en circunstancias excepcionales. Para analizar los mensajes de Syslog, agregador como Fluentd o el Agente independiente deben configurarse para retransmitir los mensajes a Cloud Logging.
Se recomienda analizar los registros de VMware Engine en un panel central en un solo proyecto. Si tu entorno de VMware Engine abarca varios proyectos, también deberás agregarlos configurando destinos de registro y ámbitos de supervisión.
Usa el agente de Cloud Logging para el registro de VMs de cargas de trabajo
Las VMs de carga de trabajo de VMware Engine pueden enviar registros directamente a La API de Cloud Logging con el agente de Logging El agente de Logging se basa en fluentd y transmite registros de aplicaciones de terceros comunes y software del sistema a Cloud Logging. Como práctica recomendada, alinea el enfoque para recopila y analiza registros de VMs de cargas de trabajo en VMware Engine con el enfoque para las instancias de Compute Engine y tu infraestructura local (si aplicable). El uso del agente de registro en VMware Engine coincide con el enfoque que se usa para las VMs en Compute Engine, de modo que las cargas de trabajo en ambas plataformas envían sus registros a Cloud Logging.
Aplica capacidades equivalentes a las de las políticas de Transparencia de acceso y Aprobación de acceso
Si bien VMware Engine no es compatible con la Transparencia de acceso (AxT) y la aprobación de acceso (AxA) en Google Cloud, implementamos con capacidades equivalentes que se pueden habilitar mediante una solicitud.
Para lograr la equivalencia de transparencia de acceso, debes considerar varias fuentes de registros, como
- Registros de vCenter: Se pueden exportar con la configuración del servidor syslog remoto.
- Registros ESXi, que pueden recopilarse a través de la configuración syslog remota, sin embargo, debes presentar una solicitud de asistencia a Google Cloud para configurar el reenvío de syslog de ESXi.
Si tiene requisitos normativos estrictos, implementamos una política que le proporciona capacidades equivalentes para la aprobación de acceso. En esta política, las operaciones de servicio estándar requieren que se genere un ticket de asistencia con un motivo por el que los operadores del servicio de acceso requieren acceso.
Se aplican las exclusiones de la Aprobación de acceso de Google Cloud.
Encriptación de VMware Engine
En las siguientes secciones, se presentan las prácticas recomendadas para la encriptación de almacenamiento en la nube privada y los factores impulsores que se deben considerar cuando se elige un proveedor clave para tu nube privada.
Usa un proveedor de claves administrado por Google habilitado para la encriptación de vSAN en reposo
La encriptación de los datos en reposo se implementa mediante la encriptación basada en software de vSAN. De forma predeterminada, VMware Engine habilita la encriptación de vSAN en cada clúster de ESXi y configura un proveedor de claves predeterminado en vCenter. Google requiere que los clientes mantengan habilitada la encriptación de vSAN en sus clústeres de ESXi, y la inhabilitación de esta función constituye un incumplimiento de las condiciones del servicio de VMware Engine. Muchas organizaciones requieren encriptación en reposo como parte de su empresa. o están obligadas por reglamentaciones a encriptar datos (por ejemplo, NIST, FIPS).
Cada host ESXi encripta los datos con el modo XTS AES-256 estándar con diferentes claves de encriptación de datos (DEK) generadas de forma aleatoria. La DEK se encripta con una clave de encriptación de claves (KEK) y solo se almacena en el disco en forma encriptada. El vCenter solo almacena el ID de la KEK, pero no la KEK en sí, que se almacena Cloud Key Management Service (KMS) Puedes elegir la ubicación de Cloud KMS en la que se guarda tu KEK.
Te recomendamos usar el proveedor de claves predeterminado administrado por Google. Sin embargo, si debes administrar Cloud KMS por tu cuenta, puedes usar un de terceros que cumplan con KMIP 1.1 de Cloud KMS proveedores. En ambos casos, se puede usar el proveedor de claves para encriptar datos en reposo y Tráfico de vMotion en tránsito.
En la siguiente tabla, se destacan las diferencias clave entre el proveedor de claves predeterminado e integraciones de Cloud KMS de terceros:
| Proveedor de claves | Ventajas | Desventajas |
|---|---|---|
| Proveedor de claves predeterminado administrado por Google |
|
|
| Proveedor externo de claves de Cloud KMS |
|
|
Ten en cuenta que no se recomienda habilitar la encriptación a nivel de VM junto con la vSAN La encriptación del almacén de datos se debe a que la eficiencia de anulación de duplicación se aproxima a cero. para VMs encriptadas.
Automatiza la rotación de las claves de encriptación según los estándares de tu organización
Eres responsable de la rotación de la KEK con vSphere de VMware Engine. Esto sucede cuando se usa la clave predeterminada con un proveedor de servicios en la nube y con un Cloud KMS externo. La rotación del KEK se puede iniciar desde vCenter o con su API. Considera automatizar la rotación del KEK según los requisitos de tu organización. Puedes encontrar un ejemplo de PowerCLI secuencia de comandos en GitHub.
Copia de seguridad y recuperación ante desastres de VMware Engine
Es importante proteger tus datos contra amenazas como el ransomware, la corrupción y los errores humanos. Además, las aplicaciones esenciales para la empresa dependen de que tus datos estén disponibles prácticamente en todo momento, lo que te deja poco tiempo para recuperar datos de interrupciones repentinas. Esta sección no incluye una cobertura completa de todos los aspectos de la copia de seguridad y la recuperación ante desastres que son relevantes para diseñar de manera eficaz una estrategia de copia de seguridad y recuperación ante desastres para mantener tus datos seguros y disponibles, pero contiene consideraciones clave a la hora de elegir la estrategia adecuada para tu entorno de VMware Engine.
Crea una copia de seguridad de tus cargas de trabajo con el servicio de copia de seguridad y DR
Con el servicio de copia de seguridad y DR, Google Cloud ofrece una solución que puede usarse para una variedad de casos de uso, incluida la copia de seguridad de cargas de trabajo en Compute Engine y Google Cloud VMware Engine. El servicio de copia de seguridad y DR es la solución única recomendada de Google para cargas de trabajo copias de seguridad porque ofrecen beneficios como un amplio espectro de cargas espacio de almacenamiento eficiente, copias de seguridad incrementales para siempre y almacenamiento flexible opciones de estado.
Google Cloud VMware Engine también admite el uso de soluciones de copia de seguridad de tercerosbasadas en agentes. Es posible que prefieras estas opciones si ya tienes licencias para un producto de copia de seguridad de terceros. Entre los requisitos previos para este tipo de herramientas, se incluyen los siguientes:
- Proporcionan copias de seguridad a nivel de la aplicación
- Los proveedores de aplicaciones los certifican.
- Están certificados por VMware Engine para vSAN.
- Admiten el estándar del protocolo de la API de VMware vStorage para protección de datos (VADP) o crean copias de seguridad a nivel de la aplicación.
Sin importar la solución de copia de seguridad que elijas, Cloud Storage como opción de almacenamiento rentable para la retención a largo plazo de de las copias de seguridad. Cloud Storage es un almacenamiento de objetos duradero y rentable. Los buckets de Cloud Storage se pueden configurar para replicar el almacenamiento automáticamente en varias regiones, lo que es ideal para los entornos multirregionales de procesamiento de datos.
Cloud Storage también es ideal para el archivado a largo plazo, ya que proporciona información políticas para mover automáticamente objetos de almacenamiento a otro nivel de almacenamiento una vez su ciclo de vida supere un valor predefinido. Usa esta opción para obtener una ubicación de almacenamiento de copias de seguridad rentable y RPO de mediano a alto, en especial, si el costo es un factor determinante.
Como alternativa, puedes elegir el almacenamiento de vSAN para minimizar el RPO. Usar esta una opción de almacenamiento si se acepta un costo más alto para el almacenamiento de copias de seguridad y el RPO requisitos no se pueden cumplir con Cloud Storage. Evita esta opción para el archivado a largo plazo, ya que existe el riesgo de que los tamaños del clúster de VMware Engine se vuelvan limitados por el almacenamiento.
Implementa la recuperación ante desastres con el servicio de copia de seguridad y DR
Te recomendamos que restablezcas las aplicaciones en VMware Engine con el servicio de copia de seguridad y DR. Para proteger tus cargas de trabajo de producción de las interrupciones de una sola zona dentro de una región, se recomienda implementar y operar una nube privada en una zona secundaria dentro de la región si VMware Engine está disponible en más de una zona de esa región. Si este no es el caso, es se recomienda restablecer las aplicaciones en una región secundaria.
Además de Copia de seguridad y DR de Google Cloud, VMware Engine es compatible con otras opciones de DR, como VMware Engine SRM y Zerto. Tanto SRM de VMware Engine como Zerto confía en la replicación de vSphere para la recuperación ante desastres, que generalmente admite con objetivos de RPO más bajos. Si tu objetivo de RPO es de minutos en lugar de horas, considera la DR. soluciones basadas en vSphere Replication.
Resumen de la lista de tareas
La siguiente lista de tareas resume las prácticas recomendadas de seguridad para usar las VMware Engine.
¿Qué sigue?
- Prueba Google Cloud VMware Engine por tu cuenta. Visita las funciones, los beneficios y los casos de uso para obtener más información.
- Lee acerca de la seguridad de VMware Engine conceptos básicos.
- Explora arquitecturas de referencia, diagramas, instructivos y prácticas recomendadas sobre Google Cloud. Para obtener más información, visita Cloud Architecture Center.