Prácticas recomendadas para la seguridad de VMware Engine
En este documento, se describen las prácticas recomendadas de seguridad para administrar y configurar Google Cloud VMware Engine, y está dirigido a usuarios que ya están familiarizados con VMware Engine. Si eres principiante, puedes comenzar por obtener información sobre los requisitos previos y la seguridad de VMware Engine.
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. Seguir estas prácticas recomendadas puede ayudarte a ahorrar tiempo, evitar errores y mitigar los efectos de los puntos de falla.
Herramientas de redes de VMware Engine
En las siguientes secciones, se presentan las prácticas recomendadas para las 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 las interconexiones 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 entorno deGoogle 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 a través del 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 estas opciones son mutuamente excluyentes. Si se requieren controles personalizados para el tráfico de Internet, como el filtrado de URL, el IPS/IDS o la inspección de tráfico proporcionados por una instancia o un servicio central en tu entorno de Google Cloud , debes enrutar el tráfico con destino a Internet a través de la red de VPC.
Si esto no se aplica a tu caso o si implementaste los controles en tu nube privada, te recomendamos que incluyas el servicio de direcciones IP externas en VMware Engine. Además, te recomendamos que uses reglas de acceso externas para rechazar patrones de tráfico de Internet que no se apliquen a tus aplicaciones.
Reglas de firewall separadas de norte a sur y de este a oeste en el firewall distribuido y de puerta de enlace en NSX de VMware Engine
Configura el firewall distribuido (DFW) en NSX 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 (interno) este-oeste entre segmentos y permite reglas de firewall que permiten y rechazan el tráfico entre instancias individuales dentro de un segmento.
Para un control de acceso a la red detallado, asegúrate de aplicar una política predeterminada restringida en el DFW para rechazar 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 de norte a 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 hacia otra zona de seguridad. Si necesitas configurar el tráfico de norte a sur para toda la nube privada de manera 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 de NSX individual, configura el firewall de la puerta de enlace en el router de nivel 1.
Además de los firewalls de NSX, te recomendamos que uses el firewall de VPC para permitir y bloquear el tráfico este-oeste entre las cargas de trabajo en la nube privada de VMware Engine y las cargas de trabajo en las VPC. De forma predeterminada, la transferencia de datos entrantes a las instancias de Compute Engine desde las cargas de trabajo de VMware Engine debe estar restringida, y solo se debe permitir el tráfico que se abra de forma consciente.
La transferencia de datos salientes a los dispositivos de administración y al rango de CIDR de vSphere/vSAN también se debe bloquear desde las VPC con el firewall de la VPC. Solo abre la transferencia de datos saliente hacia los dispositivos de administración desde hosts y direcciones IP confiables dentro de tu red. Es importante tener en cuenta que los dispositivos de administración no se encuentran dentro de un segmento de NSX y, por lo tanto, las reglas del DFW no se aplican para restringir el acceso.
Aplica los principios de seguridad de confianza cero y la microsegmentación en NSX
Usa el DFW de NSX 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 del tráfico entre VMs individuales que se rechaza de forma predeterminada también se conoce como "microsegmentación", que es un enfoque más detallado para el uso de firewalls que la implementación convencional 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 en 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. Las reglas de firewall para permitir el tráfico hacia y desde las VMs se pueden definir organizando las VMs en grupos de políticas, que pueden tener criterios de membresía flexibles, como la coincidencia de etiquetas o nombres de VM.
La microsegmentación te permite implementar una red con un control de tráfico detallado en la que se debe permitir de forma explícita un patrón de tráfico. El concepto de seguridad en el que todos los flujos de red se controlan mediante procesos de verificación de identidad y dispositivos en lugar de confianza implícita también se suele denominar seguridad de confianza cero.
Implementa un dispositivo de firewall de terceros desde el portal de Cloud Marketplace para obtener capacidades de IPS/IDS
Si necesitas seguridad avanzada de capa 7, incluidas las capacidades de IDS/IPS para el tráfico entrante a la nube privada desde el resto de tu red o entre tus segmentos de red de NSX, considera implementar un dispositivo de firewall de terceros. El dispositivo de terceros se puede implementar como un dispositivo de varias NIC entre dos VPC en tu red Google Cloud o dentro de la nube privada con una integración con NSX.
Para obtener información detallada sobre las arquitecturas de VMware Engine con dispositivos centralizados, que se pueden usar para una variedad de casos de uso de seguridad avanzados, como IPS/IDS, DSD, descarga de SSL y mucho más, consulta el documento sobre seguridad de red con dispositivos centralizados en el Centro de arquitectura de Cloud.
Usa Google Cloud Armor para proteger los servicios web en VMware Engine de los ataques DSD
Si enrutas el tráfico entrante a las cargas de trabajo en VMware Engine a través de la VPC del cliente, te recomendamos que coloques las cargas de trabajo de VMware Engine en grupos de extremos de red híbridos detrás de Cloud Service Mesh y que aproveches el balanceador de cargas de HTTP(S) externo. Cualquiera de los dos parámetros de configuración te permite incluir Google Cloud Armor para las aplicaciones orientadas al público, lo que mitiga los ataques DSD y las vulnerabilidades comunes, como las inyecciones de SQL o las secuencia de comandos entre sitios.
Si necesitas funciones de Service Mesh, como la administración avanzada del tráfico con el proxy de Envoy o la integración de Certificate Authority Service, te recomendamos Cloud Service Mesh. En todos los demás casos, recomendamos el balanceador de cargas de 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 una 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 Google Cloud Servicios de forma privada sin acceso a Internet
Las cargas de trabajo de la nube privada de VMware Engine pueden acceder a Google Cloud APIs 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 elimina la necesidad de una ruta de red a Internet para las cargas de trabajo que solo necesitan acceso a las APIs de Google. Consulta el análisis detallado del Acceso privado a Google para obtener más detalles técnicos y pasos de configuración.
Del mismo modo, las cargas de trabajo de VMware Engine que necesitan acceder a recursos de una red de productor de servicios, como instancias de Cloud SQL o Memorystore, deben conectarse de forma privada con PSA.Google Cloud Para obtener más información, consulta la sección sobre el PSA para VMware Engine.
Encripta la comunicación entre tu entorno local y Google Cloud
Las cargas de trabajo en VMware Engine que necesitan comunicarse con sistemas locales deben conectarse a través de un canal encriptado. Te recomendamos un enfoque en capas para la encriptación en tránsito entre tus centros de datos locales yGoogle Cloud. La vinculación entre los sistemas locales y Google Cloudse puede encriptar configurando Cloud VPN con un túnel IPsec o usando el IPsec integrado en los adjuntos de VLAN de Interconnect. Además, se debe habilitar la encriptación de la capa de aplicación entre los componentes de la aplicación con TLS.
Protege tus datos contra el robo con los Controles del servicio de VPC
Recomendamos mitigar los riesgos de robo de datos con los Controles del servicio de VPC. Para ello, coloca tus recursos sensibles, como los buckets de Cloud Storage y los 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 dentro del perímetro. Específicamente, el proyecto Google Cloud que aloja la nube privada debe formar parte del perímetro de los Controles del servicio de VPC para acceder a los recursos protegidos por los Controles del servicio de VPC.
Debes configurar políticas de transferencia de datos entrantes y salientes en la configuración de los Controles del servicio de VPC para permitir que las APIs del servicio de productor de VMware Engine ingresen al perímetro. Para obtener una guía detallada sobre la configuración, consulta nuestras páginas de 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 de usuario en un entorno de VMware Engine. Es importante tener en cuenta los permisos dentro del entorno de VMware Engine y el proyecto Google Cloud en el que se implementa la nube privada.
Usa roles predefinidos o personalizados para otorgar acceso
El enfoque de VMware Engine para administrar los roles y permisos de vSphere se puede aprovechar de la misma manera en que lo haces en otros entornos de VMware Engine. Sin embargo, las actividades como implementar un clúster requieren permisos en Identity and Access Management (IAM). En la siguiente tabla, se enumeran los administradores de acceso pertinentes, las fuentes de identidad a las que otorgan permisos y ejemplos de actividades que habilitan.
| Plataforma | Componente | Fuente de identidad | Dónde configurar los permisos | Ejemplos de actividades |
|---|---|---|---|---|
| Google Cloud | Portal de VMware Engine | Cloud Identity | Identity and Access Management | 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, VMs y carpetas, almacenes de datos en la IU de vCenter | Creación de VM, creación de carpetas de VM, creación y eliminación de objetos de almacén de datos, por ejemplo |
| NSX | LDAP | "Usuarios y roles" en la IU de NSX Manager | Por ejemplo, la creación de segmentos de NSX, la configuración del firewall y la configuración del balanceador de cargas. | |
| vCenter | Sistema operativo invitado de la VM | Active Directory, LDAP, usuarios locales, por ejemplo | Sistema operativo invitado | Acceso con SSH o RDP, operaciones con 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 al servicio de VMware Engine en Google Cloud.
- Visualizador del servicio de VMware Engine: Otorga acceso de solo lectura al servicio de VMware Engine en Google Cloud.
Estos permisos se relacionan con las acciones en el portal de VMware Engine y no con las acciones en la API o la CLI. Ten en cuenta que los roles básicos también incluyen la capacidad de administrar el servicio de VMware Engine (propietario, editor) o ver los detalles del servicio (visualizador). En general, te recomendamos que uses roles predefinidos en lugar de roles básicos, ya que proporcionan permisos más detallados.
El acceso programático a VMware Engine con cuentas de servicio a través de la API o la CLI debe restringirse con roles predefinidos o personalizados, ya que incluyen permisos más detallados que se aplican solo a VMware Engine. Si el acceso programático solo se usa para una tarea que requiere un subconjunto específico de los permisos de los roles predefinidos, te recomendamos que crees un rol personalizado.
Elige una ubicación adecuada para la asignación del rol de IAM en la jerarquía de recursos de tu organización. Si ejecutas todas tus nubes privadas de VMware Engine en un solo proyecto, los roles solo se pueden asignar a nivel del proyecto. Si hay requisitos técnicos o de organización que hacen que tus nubes privadas se ubiquen en proyectos separados, define los roles necesarios en una carpeta que sea común a los proyectos que se usan para tus nubes privadas.
No se requieren permisos de Cloud IAM para las actividades que solo deben realizarse dentro de vCenter, NSX o HCX. El personal que solo necesita operar estos entornos no requiere los roles de IAM mencionados anteriormente. En su lugar, deben usar identidades de LDAP con permisos configurados en vCenter y NSX. Recomendamos proporcionar los roles de administrador del servicio de VMware Engine o visualizador del servicio de VMware Engine solo a una cantidad muy limitada de usuarios, ya que estos roles otorgan acceso a la potente cuenta de usuario de CloudOwner para vCenter y a la cuenta de usuario de administrador para NSX. Estas cuentas de usuario solo se deben usar para la configuración inicial o los procedimientos de emergencia.
Restringe y audita de forma activa el acceso de administrador
El rol de administrador del servicio de VMware Engine es muy potente y solo se debe asignar a los usuarios que necesitan administrar el ciclo de vida de la nube privada de VMware Engine y sus clústeres. Por lo general, la adición o eliminación manual de clústeres y nodos es una acción que no ocurre con frecuencia y puede tener un gran impacto en la facturación o la disponibilidad del clúster. Asigna este rol solo a unas pocas personas de tu organización.
Asegúrate de auditar periódicamente 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 críticos relacionados con VMware Engine. Puedes usar servicios como el recomendador de roles de IAM para 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 para 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 no se admite la unión directa de vCenter y NSX a Active Directory para la autenticación integrada de Windows.
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 y HCX). Te recomendamos que establezcas un proceso para rotar las contraseñas de la cuenta de servicio predeterminada de vCenter CloudOwner@gve.local y del administrador de la cuenta de servicio predeterminada de NSX. Ambas cuentas de usuario solo deben usarse para la configuración inicial y los procedimientos de emergencia, y sus contraseñas deben rotarse con regularidad (por ejemplo, cada 60 o 90 días). De manera equivalente, rota con regularidad las contraseñas de las cuentas de usuario de solución que se usan comúnmente para la integración de herramientas de terceros. Cuanto más seguido rotes las contraseñas de cuenta de servicio, menos probabilidades existen 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 prácticas recomendadas para el registro y la supervisión de las cargas de trabajo de VM y la infraestructura de VMware Engine, que proporciona los recursos que consumen las cargas de trabajo.
Ingiere registros y métricas de VMware Engine
Muchas organizaciones desean recopilar y analizar registros en un "panel único" centralizado. En Google Cloud, los productos de Cloud Logging y Cloud Monitoring proporcionan servicios que se pueden usar para la administración centralizada de registros y métricas. VMware Engine se puede integrar con Cloud Monitoring a través de un agente independiente. En esta configuración, vCenter reenvía métricas, como el uso de CPU y memoria de ESXi, a Cloud Monitoring. Te recomendamos que crees paneles basados en las métricas que reenvía vCenter o que comiences con algunos paneles de muestra que se publicaron en GitHub.
Para recopilar registros de la plataforma, las nubes privadas de VMware Engine pueden reenviar registros de Syslog a un agregador de registros centralizado. Esto se puede hacer tanto para los mensajes de syslog de vCenter como de NSX. La recopilación, la retención y el análisis de los mensajes de Syslog de vCenter tienen casos de uso importantes para la seguridad, como las alertas en tiempo real basadas en los accesos de usuarios administradores (o usuarios de emergencia), que solo se deben realizar en circunstancias excepcionales. Para analizar los mensajes de Syslog, se debe configurar un agregador de Syslog, como Fluentd o el agente independiente, para retransmitir los mensajes a Cloud Logging.
Te recomendamos que analices los registros de VMware Engine en un panel centralizado en un solo proyecto. Si tu entorno de VMware Engine abarca varios proyectos, también debes agregarlos configurando receptores de registros y alcances de supervisión.
Usa el agente de Cloud Logging para el registro de la VM de la carga de trabajo
Las VMs de cargas 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 y software del sistema comunes a Cloud Logging. Como práctica recomendada, alinea el enfoque para recopilar y analizar los registros de las VMs de carga de trabajo en VMware Engine con el enfoque para las instancias de Compute Engine y tu entorno local (si corresponde). El uso del agente de Logging 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 las capacidades equivalentes de las políticas de Transparencia de acceso y Aprobación de acceso
Si bien VMware Engine no admite la transparencia de acceso (AxT) ni la aprobación de acceso (AxA) en Google Cloud, implementamos procesos con capacidades equivalentes que se pueden habilitar a pedido.
Para la equivalencia de la transparencia del acceso, debes considerar varias fuentes de registros, incluidas las siguientes:
- Registros de vCenter: Se pueden exportar con la configuración del servidor syslog remoto.
- Registros de ESXi: Se pueden recopilar con la configuración de syslog remoto. Sin embargo, debes presentar una solicitud de asistencia a Google Cloud para configurar el reenvío de syslog de ESXi.
Si tienes requisitos reglamentarios estrictos, implementamos una política para proporcionar capacidades equivalentes para la aprobación del 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 de servicio de acceso requieren acceso.
Se aplicanGoogle Cloud exclusiones de la Aprobación de Acceso.
Encriptación de VMware Engine
En las siguientes secciones, se presentan prácticas recomendadas para la encriptación del almacenamiento en la nube privada y los factores que se deben tener en cuenta al elegir un proveedor de claves para tu nube privada.
Usa un Google-owned and managed key proveedor habilitado para la encriptación en reposo de vSAN
La encriptación de datos en reposo se implementa con 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 la encriptación de vSAN constituye un incumplimiento de las condiciones del servicio de VMware Engine. Muchas organizaciones requieren la encriptación en reposo como parte de sus políticas empresariales o están obligadas por las reglamentaciones a encriptar los 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 formato encriptado. El servidor de vCenter solo almacena el ID de la KEK, pero no la KEK en sí, que se almacena en un servicio de administración de claves (KMS) de Cloud. Puedes elegir la ubicación de Cloud KMS donde se almacena tu KEK.
Te recomendamos que uses el proveedor de claves predeterminado administrado por Google. Sin embargo, si debes administrar tu Cloud KMS por tu cuenta, puedes usar un Cloud KMS de terceros que cumpla con KMIP 1.1 de uno de los proveedores admitidos. En ambos casos, el proveedor de claves se puede usar para encriptar los datos en reposo y el tráfico de vMotion en tránsito.
En la siguiente tabla, se destacan las diferencias clave entre el proveedor de claves predeterminado y las integraciones de Cloud KMS de terceros:
| Proveedor de claves | Ventajas | Desventajas |
|---|---|---|
| Default Google-owned and managed key provider |
|
|
| Proveedor externo de claves de Cloud KMS |
|
|
Ten en cuenta que no recomendamos que habilites la encriptación a nivel de la VM junto con la encriptación del almacén de datos de vSAN, ya que la eficiencia de la anulación de duplicación se acerca a cero para las 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 se aplica tanto al proveedor de claves predeterminado como a un Cloud KMS externo. La rotación de la KEK se puede iniciar desde vCenter o con su API. Considera automatizar la rotación de la KEK según los requisitos de tu organización. Puedes encontrar un ejemplo de secuencia de comandos de PowerCLI 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 el negocio 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. En esta sección, no se 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 DR para mantener tus datos seguros y disponibles, pero sí se incluyen consideraciones clave a la hora de elegir la estrategia adecuada para tu entorno de VMware Engine.
Crea copias de seguridad de tus cargas de trabajo con el servicio Backup and DR
Con el servicio Backup and DR, Google Cloud se ofrece una solución de copias de seguridad integrada y administrada de forma centralizada que se puede usar para una variedad de casos de uso, incluidas las copias 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 por Google para las copias de seguridad de cargas de trabajo, ya que ofrece beneficios como un amplio espectro de compatibilidad con cargas de trabajo, copias de seguridad incrementales para siempre y eficientes en el uso del espacio, y opciones de almacenamiento flexibles.
Google Cloud VMware Engine también admite el uso de soluciones de copias de seguridad de terceros basadas en agentes. Es posible que prefieras estas opciones si ya tienes licencias para un producto de copias de seguridad de terceros. Estos son algunos requisitos previos para este tipo de herramientas:
- Proporcionan copias de seguridad a nivel de la aplicación
- Están certificados por los proveedores de aplicaciones.
- Están certificadas por VMware Engine para vSAN.
- Admiten el estándar del protocolo de la API de VMware Engine vStorage para protección de datos (VADP) o realizan copias de seguridad a nivel de la aplicación.
Independientemente de la solución de copia de seguridad que elijas, te recomendamos Cloud Storage como una opción de almacenamiento rentable para la retención a largo plazo de las copias de seguridad. Cloud Storage es un almacenamiento de objetos rentable y de alta durabilidad. Los buckets de Cloud Storage se pueden configurar para replicar automáticamente objetos de almacenamiento en varias regiones, lo que resulta ideal para las topologías de nube multirregionales.
Cloud Storage también es ideal para el archivado a largo plazo, ya que proporciona políticas de ciclo de vida para mover automáticamente los objetos de almacenamiento a otro nivel de almacenamiento una vez que su vida útil supera un valor predefinido. Usa esta opción para obtener una ubicación de almacenamiento de copias de seguridad rentable y RPO de media a alta, en especial si el costo es un factor determinante.
Como alternativa, puedes elegir el almacenamiento de vSAN para minimizar el RPO. Usa esta opción de almacenamiento si se acepta un costo más alto para el almacenamiento de copias de seguridad y los requisitos del RPO 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 de los clústeres de VMware Engine se limiten por el almacenamiento.
Implementa la recuperación ante desastres con el servicio Backup and DR
Te recomendamos que restaures las aplicaciones en VMware Engine con el servicio Backup and DR. Para proteger tus cargas de trabajo de producción de las interrupciones de una sola zona dentro de una región, te recomendamos que implementes y operes 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 no es así, te recomendamos que restablezcas tus aplicaciones en una región secundaria.
Además de Google Cloud Backup and DR, VMware Engine es compatible con otras opciones de DR, como VMware Engine SRM y Zerto. Tanto VMware Engine SRM como Zerto dependen de la replicación de vSphere para la recuperación ante desastres, que generalmente admite objetivos de RPO más bajos. Si tu objetivo de RPO se mide en minutos en lugar de horas, considera las soluciones de DR basadas en la replicación de vSphere.
Resumen de la lista de tareas
En la siguiente lista de tareas, se resumen las prácticas recomendadas de seguridad para usar VMware Engine.
¿Qué sigue?
- Prueba Google Cloud VMware Engine por tu cuenta. Visita funciones, beneficios y casos de uso para obtener más información.
- Obtén información sobre los conceptos de seguridad de VMware Engine.
- Explora arquitecturas de referencia, diagramas, instructivos y prácticas recomendadas sobre Google Cloud. Visita Cloud Architecture Center para obtener más información.