Prácticas recomendadas para la seguridad de VMware Engine
En este documento se describen las prácticas recomendadas de seguridad para gestionar y configurar Google Cloud VMware Engine. Está dirigido a usuarios que ya conocen VMware Engine. Si eres principiante, te recomendamos que empieces por los requisitos previos y la seguridad de VMware Engine.
VMware Engine tiene un modelo de responsabilidad compartida en materia de seguridad. La seguridad de confianza en la nube se consigue mediante las responsabilidades compartidas de los clientes y de Google como proveedor de servicios. Si sigues estas prácticas recomendadas, podrás 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 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 los emparejamientos de VPC para conectar una red privada de una nube privada de VMware Engine a tu red de VPC. El tráfico entrante de una VPC de tuGoogle Cloud entorno o de una red on-premise atraviesa una red de unidades de arrendamiento gestionada por Google.
Usar el servicio de IP pública de VMware Engine para la transferencia de datos por Internet
El tráfico de Internet puede entrar en una nube privada directamente mediante el servicio de IP pública de VMware Engine. También puede entrar tráfico de Internet mediante un balanceador de carga 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 se excluyen mutuamente. Si se necesitan controles personalizados para el tráfico de Internet, como el filtrado de URLs, IPS/IDS o la inspección del tráfico proporcionados por una instancia o un servicio central en tu entorno de Google Cloud , debes enrutar el tráfico de Internet a través de la red de VPC.
Si no es tu caso o tienes los controles implementados 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 externo para denegar patrones de tráfico de Internet que no se apliquen a tus aplicaciones.
Separar las reglas de cortafuegos de norte a sur y de este a oeste en el cortafuegos de gateway y distribuido de VMware Engine NSX
Configura el cortafuegos distribuido (DFW) en NSX en el router lógico de nivel 1 para segmentar el tráfico interno entre tus dominios virtuales de nivel 2. El cortafuegos distribuido de NSX se ha diseñado para gestionar el tráfico de red interno (este-oeste) entre segmentos y permite reglas de cortafuegos que permiten y deniegan el tráfico entre instancias individuales dentro de un segmento.
Para controlar el acceso a la red de forma precisa, asegúrate de aplicar una política predeterminada restringida en el cortafuegos distribuido 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 cortafuegos de la puerta de enlace de NSX para controlar el tráfico norte-sur que entra y sale de la nube privada.
El cortafuegos de la puerta de enlace de NSX se ha diseñado para controlar el tráfico norte-sur y se recomienda para casos prácticos como controlar el tráfico en un perímetro hacia otra zona de seguridad. Si necesitas configurar el tráfico norte-sur de toda la nube privada de forma coherente, configura el cortafuegos de la pasarela en el router de nivel 0. Si necesitas configurar el tráfico norte-sur de cada segmento de NSX, configura el firewall de la pasarela en el router de nivel 1.
Además de los cortafuegos de NSX, te recomendamos que uses el cortafuegos 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 VPCs. La transferencia de datos entrantes a instancias de Compute Engine desde cargas de trabajo de VMware Engine debe estar restringida de forma predeterminada y solo se debe abrir el tráfico de forma consciente.
La transferencia de datos saliente a los dispositivos de gestión, así como al intervalo CIDR de vSphere o vSAN, también se debe bloquear desde las VPCs mediante el cortafuegos de la VPC. Solo se debe permitir la transferencia de datos salientes hacia los dispositivos de gestión desde hosts y direcciones IP de confianza de tu red. Es importante tener en cuenta que los dispositivos de gestión no están dentro de un segmento de NSX y, por lo tanto, las reglas de DFW no se aplican para restringir el acceso.
Aplicar los principios de seguridad de confianza cero y la microsegmentación en NSX
Usa NSX DFW para implementar controles de tráfico en segmentos de seguridad que sean tan granulares como las máquinas virtuales individuales. Este principio de protección del tráfico entre máquinas virtuales individuales, que se deniega de forma predeterminada, también se conoce como microsegmentación, un enfoque más granular para los cortafuegos que la implementación convencional de cortafuegos entre dominios de capa 3.
El cortafuegos distribuido está habilitado en el kernel del hipervisor en todos los hosts de VMware Engine vSphere de tu nube privada y puede controlar el flujo de tráfico entre cargas de trabajo que estén en el mismo segmento de NSX o en segmentos independientes. Las reglas de cortafuegos 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 pertenencia flexibles, como la coincidencia de etiquetas o nombres de VMs.
La microsegmentación te permite implementar una red con un control de tráfico pormenorizado en la que se debe permitir explícitamente 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 dispositivo en lugar de mediante la confianza implícita también se suele denominar seguridad de confianza cero.
Desplegar un dispositivo de firewall de terceros desde el portal de Cloud Marketplace para obtener funciones de IPS o IDS
Si necesitas seguridad avanzada de 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 tus segmentos de red NSX, considera la posibilidad de implementar un dispositivo de firewall de terceros. El dispositivo de terceros se puede implementar como un dispositivo con varias NICs entre dos VPCs de tu red de Google Cloud o en 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 en diversos casos prácticos de seguridad avanzada, como IPS/IDS, DDoS, descarga de SSL y más, consulta el documento sobre seguridad de red con dispositivos centralizados en el Centro de Arquitectura de Cloud.
Usar Google Cloud Armor para proteger los servicios web en VMware Engine frente a ataques DDoS
Si enrutas el tráfico entrante a 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 endpoints de red híbridos detrás de Cloud Service Mesh y que aproveches el balanceador de carga HTTP(S) externo. Ambas configuraciones te permiten incluir Google Cloud Armor en aplicaciones públicas, lo que mitiga los ataques DDoS y las vulnerabilidades comunes, como las inyecciones de SQL o el cross-site scripting.
Si necesitas funciones de Service Mesh, como la gestión avanzada del tráfico mediante el proxy Envoy o la integración del Servicio de Autoridades de Certificación, te recomendamos Cloud Service Mesh. En todos los demás casos, recomendamos el balanceador de carga HTTP(S) externo.
Sigue las instrucciones de la documentación sobre cómo añadir cargas de trabajo de VMware Engine a NEGs híbridas en una de las siguientes configuraciones:
- Balanceo de carga HTTP(S) externo regional con conectividad híbrida
- Balanceador de carga HTTP(S) global externo con conectividad híbrida
Conectarse 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 APIs como la API Cloud Storage mediante el acceso privado a Google. Google Cloud 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 coste y la latencia de la transferencia de datos salientes. De esta forma, no es necesario que las cargas de trabajo que solo necesiten acceder a las APIs de Google tengan una ruta de red a Internet. Consulta el análisis detallado de Acceso privado a Google para obtener más información técnica y los pasos de configuración.
Del mismo modo, las cargas de trabajo de VMware Engine que necesiten acceder a recursos de una red de un productor de servicios, como instancias de Cloud SQL o Memorystore, deben conectarse de forma privada mediante PSA.Google Cloud Para obtener más información, consulta la sección sobre PSA para VMware Engine.
Cifra la comunicación entre tu entorno local y Google Cloud
Las cargas de trabajo de VMware Engine que necesiten comunicarse con sistemas on-premise deben conectarse a través de un canal cifrado. Te recomendamos que utilices un enfoque por capas para cifrar los datos en tránsito entre tus centros de datos locales yGoogle Cloud. El enlace entre los sistemas on-premise y Google Cloud se puede cifrar configurando Cloud VPN con un túnel IPsec o usando el IPsec integrado en las vinculaciones de VLAN de Interconnect. Además, se debe habilitar el cifrado de la capa de aplicación entre los componentes de la aplicación mediante TLS.
Proteger los datos frente a la filtración externa con Controles de Servicio de VPC
Te recomendamos que mitigues los riesgos de filtración externa de datos con Controles de Servicio de VPC colocando tus recursos sensibles, como los segmentos de Cloud Storage y los conjuntos de datos de BigQuery, en un perímetro de Controles de Servicio de VPC. Las cargas de trabajo que necesiten acceder a datos dentro de un perímetro también deben colocarse en el perímetro. En concreto, el Google Cloud proyecto que aloja la nube privada debe formar parte del perímetro de Controles de Servicio de VPC para acceder a los recursos protegidos por Controles de Servicio de VPC.
Debe configurar políticas de transferencia de datos entrantes y salientes en su configuración de Controles de Servicio de VPC para permitir que las APIs de servicio de productor de VMware Engine entren en el perímetro. Para obtener instrucciones detalladas sobre la configuración, consulta las páginas de nuestra documentación sobre los controles de servicio de VPC con VMware Engine.
Gestión de identidades y accesos 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 gestionar los permisos en el entorno de VMware Engine y en el Google Cloud proyecto en el que se despliega la nube privada.
Usar roles predefinidos o personalizados para conceder acceso
El enfoque de VMware Engine para gestionar los roles y permisos de vSphere se puede aprovechar de la misma forma que en otros entornos de VMware Engine. Sin embargo, para realizar actividades como implementar un clúster, se necesitan permisos de Gestión de Identidades y Accesos (IAM). En la siguiente tabla se indican los gestores de acceso pertinentes, las fuentes de identidad a las que conceden permisos y ejemplos de actividades que permiten.
| Plataforma | Componente | fuente de identidad | Dónde configurar los permisos | Actividades de ejemplo |
|---|---|---|---|---|
| Google Cloud | Portal de VMware Engine | Cloud Identity | Gestión de Identidades y Accesos | Por ejemplo, el despliegue y la cancelación de nubes privadas, así como el despliegue y la cancelación de clústeres. |
| VMware Engine | vCenter | LDAP | Hosts y clústeres, máquinas virtuales y carpetas, almacenes de datos en la interfaz de usuario de vCenter | Creación de máquinas virtuales, creación de carpetas de máquinas virtuales, creación y eliminación de objetos de almacén de datos, por ejemplo |
| NSX | LDAP | "Usuarios y roles" en la interfaz de usuario de NSX Manager | Por ejemplo, la creación de segmentos de NSX, la configuración del cortafuegos o la configuración del balanceador de carga. | |
| vCenter | Sistema operativo invitado de la VM | Active Directory, LDAP o usuarios locales, por ejemplo | Sistema operativo invitado | Inicio de sesión SSH o RDP, operaciones con archivos, por ejemplo |
En Google Cloud IAM, hay dos roles predefinidos con permisos para el portal de VMware Engine:
- Administrador del servicio VMware Engine: proporciona acceso completo al servicio VMware Engine en Google Cloud.
- Visor del servicio VMware Engine: proporciona acceso de solo lectura al servicio VMware Engine en Google Cloud.
Estos permisos están relacionados con las acciones del portal de VMware Engine y no con las de la API o la CLI. Ten en cuenta que los roles básicos también incluyen la capacidad de gestionar el servicio VMware Engine (propietario y editor) o de ver los detalles del servicio (lector). Por lo general, te recomendamos que uses roles predefinidos en lugar de roles básicos, ya que ofrecen permisos más detallados.
El acceso mediante programación a VMware Engine con cuentas de servicio mediante la API o la CLI debe restringirse con roles predefinidos o personalizados, ya que incluyen permisos más específicos que solo se aplican 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 gestión de identidades y accesos 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 de proyecto. Si hay requisitos técnicos u organizativos que hacen que tus nubes privadas se ubiquen en proyectos independientes, define los roles necesarios en una carpeta que sea común a los proyectos utilizados para tus nubes privadas.
No se necesitan permisos de Cloud IAM para las actividades que solo se deben realizar en vCenter, NSX o HCX. El personal que solo necesite operar en estos entornos no requiere los roles de gestión de identidades y accesos que se han indicado anteriormente. En su lugar, deben usar identidades LDAP con permisos configurados en vCenter y NSX. Recomendamos que solo asignes los roles de administrador o lector del servicio VMware Engine a un número muy limitado de usuarios, ya que estos roles conceden acceso a la cuenta de usuario CloudOwner, que tiene muchos privilegios, para vCenter y a la cuenta de usuario administrador para NSX. Estas cuentas de usuario solo se deben usar para la configuración inicial o para procedimientos de emergencia.
Restringir y auditar activamente el acceso de administrador
El rol Administrador de servicio de VMware Engine es muy potente y solo debe asignarse a los usuarios que necesiten gestionar 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 que puede tener un gran impacto en la facturación o en 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 ha asignado el rol Administrador de servicio de VMware Engine, ya sea directamente en el proyecto que se utiliza 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 Editor y Propietario, que incluyen permisos críticos relacionados con VMware Engine. Puedes usar servicios como el recomendador de roles de gestión de identidades y accesos para identificar roles con demasiados privilegios.
Configurar una fuente de identidad LDAP o Active Directory
Se debe configurar un proveedor de identidades que admita la autenticación LDAP, como Active Directory, para habilitar la autenticación de usuarios en vCenter y NSX Manager. Es una práctica recomendada para tener una gestión centralizada del ciclo de vida de las identidades, la gestión de grupos, la gestión de contraseñas y 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.
Rotar las contraseñas de las cuentas de servicio integradas
VMware Engine genera credenciales para acceder a los dispositivos de gestión de la nube privada (como vCenter, NSX y HCX). Te recomendamos que establezcas un proceso para cambiar 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 cambiarse periódicamente (por ejemplo, cada 60 o 90 días). Del mismo modo, cambia periódicamente las contraseñas de las cuentas de usuario de soluciones que se usan habitualmente para integrar herramientas de terceros. Cuanto más a menudo rotes las contraseñas de las cuentas de servicio, menos probabilidades habrá de que la contraseña siga siendo válida cuando un agente malintencionado la encuentre.
Logging y Monitoring de VMware Engine
En las siguientes secciones se describen las prácticas recomendadas para registrar y monitorizar tanto las cargas de trabajo de las VMs como la infraestructura de VMware Engine, que proporciona los recursos que consumen las cargas de trabajo.
Ingerir registros y métricas de VMware Engine
Muchas organizaciones quieren recoger y analizar registros en un panel único centralizado. En Google Cloud, los productos Cloud Logging y Cloud Monitoring ofrecen servicios que se pueden usar para gestionar de forma centralizada los registros y las métricas. VMware Engine se puede integrar con Cloud Monitoring mediante 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 de control basados en métricas que reenvíe vCenter o que empieces con algunos paneles de control de ejemplo que se hayan publicado en GitHub.
Para recoger 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 para los de NSX. Recoger, conservar y analizar mensajes Syslog de vCenter tiene casos prácticos de seguridad importantes, como las alertas en tiempo real basadas en los inicios de sesión de usuarios administradores (o usuarios de emergencia), que solo deben realizarse en circunstancias excepcionales. Para analizar los mensajes Syslog, es necesario configurar un agregador de Syslog, como Fluentd o el agente independiente, para que reenvíe los mensajes a Cloud Logging.
Te recomendamos que analices los registros de VMware Engine en un panel de control centralizado de un solo proyecto. Si tu entorno de VMware Engine abarca varios proyectos, también debes agregar tus proyectos configurando receptores de registro y ámbitos de monitorización.
Usar el agente de Cloud Logging para el registro de VMs de carga de trabajo
Las VMs de carga de trabajo de VMware Engine pueden enviar registros directamente a la API de Cloud Logging mediante 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 recoger y analizar los registros de las máquinas virtuales de carga de trabajo en VMware Engine con el enfoque de las instancias de Compute Engine y tu infraestructura local (si procede). El uso del agente de Logging en VMware Engine coincide con el enfoque que se utiliza en las VMs de Compute Engine, de forma que las cargas de trabajo de ambas plataformas envían sus registros a Cloud Logging.
Aplicar las funciones equivalentes de las políticas de Transparencia de acceso y Aprobación de acceso
Aunque VMware Engine no admite Transparencia de acceso (AxT) ni Aprobación de acceso (AxA) en Google Cloud, hemos implementado procesos con funciones equivalentes que se pueden habilitar si se solicita.
Para conseguir la equivalencia de Transparencia de acceso, debes tener en cuenta varias fuentes de registros, entre las que se incluyen las siguientes:
- Registros de vCenter: se pueden exportar mediante la configuración del servidor syslog remoto.
- Registros de ESXi: se pueden recoger mediante 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 normativos estrictos, implementamos una política para ofrecer funciones equivalentes para la aprobación del acceso. En esta política, las operaciones de servicio estándar requieren que se genere una incidencia con el motivo por el que los operadores de servicios de acceso necesitan acceder.
Se aplican exclusiones deGoogle Cloud aprobación de acceso
Cifrado de VMware Engine
En las siguientes secciones se presentan las prácticas recomendadas para cifrar el almacenamiento en la nube privada y los factores que se deben tener en cuenta a la hora de elegir un proveedor de claves para la nube privada.
Usar un proveedor Google-owned and managed key habilitado para el cifrado en reposo de vSAN
El cifrado de datos en reposo se implementa mediante el cifrado basado en software de vSAN. De forma predeterminada, VMware Engine habilita el cifrado de vSAN en cada clúster de ESXi y configura un proveedor de claves predeterminado en vCenter. Google requiere que los clientes mantengan habilitado el cifrado de vSAN en sus clústeres ESXi. Si lo inhabilitan, se incumplen los términos del servicio de VMware Engine. Muchas organizaciones exigen el cifrado en reposo como parte de sus políticas empresariales o están obligadas por las normativas a cifrar los datos (por ejemplo, NIST o FIPS).
Cada host ESXi cifra los datos mediante el modo XTS estándar AES-256 con claves de cifrado de datos (DEK) diferentes generadas de forma aleatoria. La DEK se cifra con una clave de cifrado de claves (KEK) y solo se almacena en el disco de forma cifrada. El servidor vCenter solo almacena el ID de la KEK, pero no la KEK en sí, que se almacena en un servicio de gestión de claves (KMS) en la nube. Puedes elegir la ubicación de Cloud KMS donde se guardará tu KEK.
Te recomendamos que utilices el proveedor de claves predeterminado gestionado por Google. Sin embargo, si tienes que gestionar tu Cloud KMS por tu cuenta, puedes usar un Cloud KMS de terceros compatible con KMIP 1.1 de uno de los proveedores admitidos. En ambos casos, el proveedor de claves se puede usar para cifrar los datos en reposo y el tráfico de vMotion en tránsito.
En la siguiente tabla se destacan las principales diferencias entre el proveedor de claves predeterminado y las integraciones de Cloud KMS de terceros:
| Proveedor de claves | Ventajas | Inconvenientes |
|---|---|---|
| Proveedor Google-owned and managed key predeterminado |
|
|
| Proveedor de claves de Cloud KMS de terceros |
|
|
Ten en cuenta que no te recomendamos que habilites el cifrado a nivel de VM junto con el cifrado del almacén de datos de vSAN, ya que la eficiencia de la desduplicación se aproxima a cero en las VMs cifradas.
Automatizar la rotación de las claves de cifrado según los estándares de tu organización
La rotación de KEK corre por tu cuenta mediante VMware Engine vSphere. Esto ocurre tanto con el proveedor de claves predeterminado como con un Cloud KMS externo. La rotación de KEK se puede iniciar desde vCenter o mediante su API. Considera la posibilidad de automatizar la rotación de KEKs 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 tras desastres de VMware Engine
Es importante proteger tus datos frente a amenazas como el ransomware, la corrupción y los errores humanos. Además, las aplicaciones esenciales para tu empresa dependen de que tus datos estén disponibles prácticamente en todo momento, por lo que tienes poco tiempo para recuperar los datos en caso de interrupciones repentinas. En esta sección no se tratan todos los aspectos de las copias de seguridad y la recuperación ante desastres que son relevantes para diseñar de forma eficaz una estrategia de copias de seguridad y recuperación ante desastres que mantenga 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.
Crear copias de seguridad de cargas de trabajo con el servicio de copia de seguridad y recuperación tras fallos
Con el servicio Backup y DR Google Cloud se ofrece una solución de copia de seguridad integrada y gestionada de forma centralizada que se puede usar en diversos casos prácticos, como la creación de copias de seguridad de cargas de trabajo en Compute Engine y Google Cloud VMware Engine. El servicio de copia de seguridad y recuperación ante desastres es la solución única recomendada de Google para las copias de seguridad de cargas de trabajo, ya que ofrece ventajas como una amplia gama de compatibilidad con cargas de trabajo, copias de seguridad incrementales para siempre que ahorran espacio y opciones de almacenamiento flexibles.
Google Cloud VMware Engine también admite el uso de soluciones de copia de seguridad de terceros basadas en agentes. Puede que prefieras estas opciones si ya tienes licencias de un producto de copia de seguridad de terceros. Para usar este tipo de herramientas, debes cumplir los siguientes requisitos:
- Proporcionan copias de seguridad a nivel de aplicación
- Están certificadas por los proveedores de las aplicaciones
- Tienen la certificación de VMware Engine para vSAN
- Admiten el protocolo estándar de la API vStorage de VMware Engine para la protección de datos (VADP) o realizan copias de seguridad a nivel de 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 conservar las copias de seguridad a largo plazo. Cloud Storage es un servicio de almacenamiento de objetos de alta durabilidad y rentable. Los segmentos de Cloud Storage se pueden configurar para replicar automáticamente objetos de almacenamiento en varias regiones, lo que resulta ideal para 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 tiempo de conservación supera un valor predefinido. Utiliza esta opción para disponer de una ubicación de almacenamiento de copias de seguridad rentable y de objetivos de tiempo de recuperación (RPOs) medios o altos, sobre todo si el coste es un factor determinante.
También puedes elegir el almacenamiento de vSAN para minimizar el RPO. Usa esta opción de almacenamiento si puedes asumir un coste más alto por el almacenamiento de copias de seguridad y no puedes cumplir los requisitos de RPO con Cloud Storage. No utilices 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 al almacenamiento.
Implementar la recuperación tras desastres con el servicio Backup y 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 frente a las interrupciones de una sola zona de una región, te recomendamos que despliegues y utilices una nube privada en una zona secundaria 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 restaures tus aplicaciones en una región secundaria.
Además de Google Cloud Backup and DR, VMware Engine es compatible con otras opciones de recuperación tras desastres, como VMware Engine SRM y Zerto. Tanto VMware Engine SRM como Zerto se basan en la replicación de vSphere para la recuperación tras fallos, que suele admitir objetivos de RPO más bajos. Si tu objetivo de RPO es de minutos en lugar de horas, considera las soluciones de recuperación ante desastres basadas en la replicación de vSphere.
Resumen de la lista de comprobación
En la siguiente lista de comprobación se resumen las prácticas recomendadas de seguridad para usar VMware Engine.
Siguientes pasos
- Prueba VMware Engine de Google Cloud. Consulta las funciones, las ventajas y los casos prácticos para obtener más información.
- Consulta los conceptos de seguridad de VMware Engine.
- Consulta arquitecturas de referencia, diagramas, tutoriales y prácticas recomendadas sobre Google Cloud. Visita el Centro de arquitectura de Cloud para obtener más información.