Prácticas recomendadas de 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, te recomendamos que comiences por aprender 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 fallo.
Redes de VMware Engine
En las siguientes secciones, se presentan las prácticas recomendadas para establecer redes en un entorno de VMware Engine.
Identifica y comprende 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 de una VPC en tu entorno de Google Cloud o de 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 estas opciones son mutuamente excluyentes. Si se requieren controles personalizados para el tráfico de Internet, como el filtrado de URLs, IPS/IDS o la inspección de tráfico que proporciona una instancia o un servicio central en tu entorno de Google Cloud, debes enrutar el tráfico destinado a Internet a través de la red de VPC.
Si esto no se aplica a tu caso o tienes los controles implementados en tu nube privada, te recomendamos que incluyas el servicio de dirección IP externa en VMware Engine. Además, te recomendamos que uses reglas de acceso externas para denegar los patrones de tráfico de Internet que no se apliquen a tus aplicaciones.
Separa las reglas de firewall de norte a sur y de este a oeste en la puerta de enlace y 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 del tráfico entre VMs individuales que se rechaza de forma predeterminada a menudo también se conoce como "microsegmentación", que es un enfoque más detallado para el firewall 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 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 VM.
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 concepto de seguridad en el que todos los flujos de red están controlados por procesos de verificación de identidad y dispositivo en lugar de confianza implícita a menudo también se denomina 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 la capa 7, incluidas las funciones de IDS/IPS para el tráfico entrante a la nube privada desde el resto de tu red o entre los segmentos de red de NSX-T, 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 de Google Cloud o dentro de la nube privada con una integración con 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, DSD, 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 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 aproveches el 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 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 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
Cómo conectarse 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 de 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 la API de Google. Sigue 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 los recursos de Google Cloud desde una red de productor de servicios, como instancias de Cloud SQL o Memorystore, deben conectarse de forma privada con 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
Las cargas de trabajo en VMware Engine que necesitan comunicarse con sistemas locales deben conectarse a través de 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 se 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 del robo con los Controles del servicio de VPC
Se recomienda 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 datos dentro de un perímetro también deben colocarse en el perímetro. Específicamente, el proyecto de Google Cloud que aloja la nube privada debe ser parte del perímetro de Controles del servicio de VPC para acceder a los recursos que protegen 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 accedan al 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 de los usuarios en un entorno de VMware Engine. Es importante tener cuidado con los permisos dentro del entorno de VMware Engine y el proyecto de 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 que lo haces en otros entornos de VMware Engine. Sin embargo, actividades como la implementación de un clúster requieren permisos en Identity and Access Management (IAM). En la siguiente tabla, se enumeran los administradores de acceso relevantes, las fuentes de identidad a las que otorgan permisos y los ejemplos de actividades 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, 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-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 la VM | Active Directory, LDAP, 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: Te brinda acceso completo al 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 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 o editor) o de ver los detalles del servicio (visualizador). Por lo general, se recomienda usar 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 que usan 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, 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 ejecutas todas tus nubes privadas de VMware Engine en un proyecto, solo se pueden asignar roles a nivel del proyecto. Si hay requisitos técnicos o organizativos que hacen que tus nubes privadas se ubiquen en proyectos separados, define los roles requeridos 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 se deben realizar dentro de 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 identidades de 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 de administrador de servicios de VMware Engine es muy potente y solo debe asignarse a los usuarios que necesiten 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 se realiza con frecuencia y puede 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 no se admite la unión directa de vCenter y NSX-T 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-T y HCX). Se recomienda establecer 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-T. Ambas cuentas de usuario solo deben usarse para la configuración inicial y los procedimientos de emergencia, y sus contraseñas deben rotar con regularidad (por ejemplo, cada 60 o 90 días). De manera equivalente, rota las contraseñas de las cuentas de usuario de la solución que se usan con frecuencia para la integración de 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 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.
Transfere registros y métricas de VMware Engine
Muchas organizaciones desean recopilar y analizar registros en una "ventana única" centralizada. En Google Cloud, los productos 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 a Cloud Monitoring con un agente independiente. En esta configuración, vCenter reenvía métricas, como el uso de CPU y memoria de 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 la plataforma, las nubes privadas de VMware Engine pueden reenviar registros de Syslog a un agregador de registros centralizado. Esto se puede hacer para los mensajes de syslog de vCenter y de NSX-T. La recopilación, retención y el análisis de los mensajes de Syslog desde vCenter tienen casos de uso de seguridad importantes, como alertas en tiempo real basadas en accesos de usuarios administrativos (o de emergencia), que solo deben realizarse 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.
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 VM de cargas 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 comunes y software del sistema a Cloud Logging. Como práctica recomendada, alinea el enfoque para recopilar y analizar registros de las VMs de cargas de trabajo en VMware Engine con el enfoque de 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.
Aplicar 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 transparencia de acceso, debes considerar varias fuentes de registros, entre las que se incluyen las siguientes:
- Registros de vCenter: Se pueden exportar con la configuración del servidor de syslog remoto.
- Registros de ESXi: Se pueden recopilar con la configuración de syslog remoto. Sin embargo, debes enviar 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 funciones 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 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 prácticas recomendadas para la encriptación del almacenamiento en la nube privada y los factores clave que debes tener en cuenta cuando elijas un proveedor de claves 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 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 es un incumplimiento de las condiciones del servicio de VMware Engine. Muchas organizaciones requieren la encriptación en reposo como parte de las políticas de su empresa 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 forma encriptada. El servidor vCenter solo almacena el ID de la KEK, pero no la KEK en sí, que se almacena en Cloud Key Management Service (KMS). Puedes elegir la ubicación de Cloud KMS en la que se guarda 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 la KMIP 1.1 de uno de los proveedores compatibles. 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 |
|---|---|---|
| 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 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. Este es el caso tanto con el proveedor de claves predeterminadas como 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 una secuencia de comandos de PowerCLI de ejemplo 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 DR 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 copias 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 de copia de seguridad integrada y administrada de forma centralizada que se puede usar 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 única solución 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 y siempre eficientes en el espacio, y opciones de almacenamiento flexibles.
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 Engine vStorage para protección de datos (VADP) o crean 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 duradero y rentable. Los buckets de Cloud Storage se pueden configurar para replicar automáticamente los objetos de almacenamiento en varias regiones, lo que es ideal para topologías de Cloud multirregionales.
Cloud Storage también es ideal para el archivo 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 ciclo de vida supera 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. Usa esta opción de almacenamiento si se acepta un costo más alto por el almacenamiento de copias de seguridad y no se pueden cumplir los requisitos de RPO 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 Backup and DR
Te recomendamos que restablezcas las aplicaciones en VMware Engine con el servicio de Backup and 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 no es así, se recomienda restablecer las 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 es de 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 las funciones, los beneficios y los 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. Para obtener más información, visita Cloud Architecture Center.