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. 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 falla.
Identificar y comprender todos los flujos de tráfico de tu entorno
Para proteger las cargas de trabajo y las interfaces de administración en la nube privada, es importante identificar y comprender todos los flujos de tráfico del entorno. Hay una lista de flujos de tráfico clave en VMware Engine disponible en el documento Herramientas de redes de nube privada para VMware Engine.
VMware Engine aprovecha el Acceso privado a servicios (PSA) para exponer una conexión de red privada de una red de nube privada de VMware Engine a tu red de VPC. El tráfico de entrada de una VPC en tu entorno de Google Cloud o desde una red local atraviesa una red del productor de servicios administrado por Google.
Usar el servicio de IP pública de VMware Engine para el ingreso de Internet
El tráfico de Internet puede ingresar a una nube privada directamente mediante el servicio de IP pública de VMware Engine. Como alternativa, el tráfico de Internet puede ingresar mediante un balanceador de cargas público en Google Cloud. En ese caso, el tráfico se enruta como cualquier otro tráfico de entrada a través del acceso privado a servicios. 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, IPS/IDS o la inspección de tráfico proporcionada por una instancia o un servicio central en tu entorno de Google Cloud, debes enrutar el tráfico vinculado a Internet a través de tu VPC y la VPC compartida del productor de servicios.
Si esto no se aplica a ti o si tienes los controles implementados dentro de la nube privada, te recomendamos que incluyas el servicio de dirección IP pública en VMware Engine. Además, te recomendamos que uses las reglas de firewall con estado para denegar los patrones de tráfico de Internet que no se aplican a las aplicaciones.
Reglas de firewall independientes de norte a sur y este-oeste en la puerta de enlace y un 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. NSX DFW está diseñado para controlar el tráfico de red de este a 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 las 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 la puerta de enlace de NSX para controlar el tráfico de norte a sur que ingresa a la nube privada y sale de ella.
El firewall de la puerta de enlace de NSX está diseñado para controlar el tráfico de norte a sur y se recomienda en casos de uso como controlar el tráfico en un perímetro que dirija a otra zona de seguridad. Si necesitas configurar el tráfico norte-sur para 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 de este a oeste entre las cargas de trabajo en la nube privada de VMware Engine y las cargas de trabajo en las VPC. La entrada a las instancias de Compute Engine desde las cargas de trabajo de VMware Engine debe restringirse de forma predeterminada solo con el tráfico abierto de forma consciente.
La salida a los dispositivos de administración, así como al rango de CIDR de vSphere o vSAN, se deben bloquear desde las VPC y mediante el firewall de VPC. Solo abre la salida hacia 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 están dentro de un segmento NSX-T 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-T
Usa NSX-T DFW a fin de implementar controles de tráfico para segmentos de seguridad que son tan detallados como las máquinas virtuales individuales. Este principio de protección del tráfico entre VM individuales que se rechaza de forma predeterminada también se conoce como “microsegmentación”, que es un enfoque más detallado para el firewall que la implementación tradicional de firewalls entre dominios de capa 3.
El DFW está habilitado en el kernel del hipervisor de 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 están en el mismo segmento de NSX o en segmentos separados. Las reglas de firewall para permitir el tráfico hacia y desde las VM se pueden definir si organizas las VM en grupos de políticas, que pueden tener criterios de membresía flexibles, como la coincidencia de nombres o etiquetas de VM.
La microsegmentación te permite implementar una red con control de tráfico detallado en el que cualquier patrón de tráfico deseado debe permitirse de manera explícita. El concepto de seguridad en el que todos los flujos de red se controlan mediante procesos de verificación de identidad y del dispositivo 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 funciones de IPS/IDS
Si necesitas seguridad avanzada de la capa 7, incluidas las capacidades de IDS/IPS para el tráfico de entrada a la nube privada desde el resto de tu red o entre tus segmentos de red 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 en NSX-T.
Si quieres obtener un análisis detallado de las arquitecturas de VMware Engine con dispositivos centralizados, que se pueden usar para una variedad de casos prácticos de seguridad avanzados, como IPS/IDS, DSD, transferencia SSL y más, consulta la seguridad de la red de documentos mediante dispositivos centralizados en el Cloud Architecture Center.
Usa Google Cloud Armor para proteger los servicios web alojados en VMware Engine de los ataques DSD
Si enrutas el tráfico de entrada a las cargas de trabajo en VMware Engine a través de la VPC del cliente, te recomendamos colocar las cargas de trabajo de VMware Engine en grupos de extremos de red híbridos detrás de Traffic Director y aprovechar el balanceador de cargas de HTTP(S) externo. Cualquiera de las configuraciones te permite incluir Google Cloud Armor para aplicaciones públicas, lo que permite mitigar los ataques DSD y vulnerabilidades comunes, como inyecciones de SQL o secuencia de comandos entre sitios.
Si necesitas funciones de la malla de servicios, como la administración avanzada del tráfico mediante el proxy de Envoy o la integración de Certificate Authority Service, te recomendamos Traffic Director. 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 las cargas de trabajo de VMware Engine a los NEG híbridos en cualquiera de las siguientes opciones de configuración:
- 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 de salida y la latencia. Esto también quita 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 del productor de servicios, como las instancias de Cloud SQL o Memorystore, deben conectarse de forma privada mediante PSA. Para obtener más información sobre este tema, visita la sección sobre PSA para VMware Engine.
Encripta la comunicación entre tu entorno local y Google Cloud
Las cargas de trabajo de 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 los centros de datos locales y Google Cloud. El vínculo entre las instalaciones locales y Google Cloud puede encriptarse mediante la configuración de Cloud VPN con un túnel IPSec o mediante el uso del IPSec nativo en los adjuntos de VLAN de la interconexión. Además, se debe habilitar la encriptación de la capa de aplicación entre los componentes de la aplicación mediante TLS.
Usa los Controles del servicio de VPC para proteger tus datos contra el robo de datos
Se recomienda mitigar los riesgos de robo de datos con los Controles del servicio de VPC. Para ello, coloca los 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 en él. En particular, el proyecto de 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 que están protegidos por los Controles del servicio de VPC.
Debes establecer las políticas de entrada y salida en la configuración de los Controles del servicio de VPC para permitir que las APIs del servicio del productor de VMware Engine entren en el 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 del usuario en un entorno de VMware Engine. Es importante tener en cuenta 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 las funciones y los permisos de vSphere se puede aprovechar de la misma manera que se usa con 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 relevantes, las fuentes de identidad a las que otorgan permisos y las actividades de ejemplo que habilitan.
| Platform | Componente | Fuente de identidad | Dónde configurar los permisos | Actividades de ejemplo |
|---|---|---|---|---|
| Google Cloud | Portal de VMware Engine | Cloud Identity | Identity and Access Management | Implementación y cancelación de la nube privada, implementación y cancelación de clústeres, por ejemplo. |
| VMware Engine | vCenter | LDAP | Hosts y clústeres, VMs, carpetas y almacenes de datos en la IU de vCenter | Creación de VM, creación de carpetas de VM y creación y eliminación de objetos del 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 y la configuración del balanceador de cargas. | |
| vCenter | Sistema operativo invitado de VM | Active Directory, LDAP o usuarios locales, por ejemplo | Sistema operativo invitado | Acceso SSH o RDP, operaciones con archivos, por ejemplo |
En Google Cloud IAM, hay dos funciones predefinidas 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 también las funciones básicas incluyen la capacidad de administrar el servicio de VMware Engine (Propietario, Editor) o ver los detalles del servicio (Visualizador). En general, se recomienda usar funciones predefinidas en lugar de funciones básicas, ya que proporcionan permisos más detallados.
El acceso programático a VMware Engine con cuentas de servicio mediante la API o la CLI debe limitarse mediante funciones predefinidas o personalizadas porque 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 las funciones predefinidas, se recomienda crear una función personalizada.
Elige una ubicación adecuada para la asignación de la función 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 las funciones se pueden asignar a nivel de proyecto. Si hay requisitos técnicos o de la organización que provocan que las nubes privadas se ubiquen en proyectos separados, define las funciones necesarias en una carpeta que sea común a los proyectos que se usan para las nubes privadas.
Los permisos de Cloud IAM no son necesarios para actividades que solo deben realizarse dentro de vCenter, NSX-T o HCX. El personal que solo necesita operar estos entornos no requiere las funciones de IAM enumeradas con anterioridad. En su lugar, deben usar identidades LDAP con permisos configurados en vCenter y NSX-T. Recomendamos proporcionar las funciones de administrador de servicios de VMware Engine o de visualizador de servicios de VMware Engine solo a una cantidad muy limitada de usuarios, ya que estas funciones otorgan acceso a la cuenta de usuario potente de CloudOwner para vCenter y a la cuenta de usuario de administrador para NSX-T. Estas cuentas de usuario solo deben usarse para la configuración inicial o los procedimientos de emergencia.
Restringir y auditar de forma activa el acceso de los administradores
La función de administrador de servicios 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 alto impacto en la facturación o la disponibilidad del clúster. Asigna esta función solo a muy pocas personas de tu organización.
Asegúrate de auditar con regularidad a quién se le asignó la función 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 otras funciones, como las funciones básicas de editor y propietario, que incluyen permisos fundamentales relacionados con VMware Engine. Puedes usar servicios como el recomendador de funciones de IAM para identificar las funciones 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 LDAP, como Active Directory, para habilitar la autenticación de usuario en vCenter y NSX Manager. Esta es una práctica recomendada para tener la 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 los dispositivos de administración de accesos 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 el 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 rotarse con regularidad (p.ej., cada 60 o 90 días). De manera equivalente, rota con regularidad 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 las cuentas de servicio, menos probable será que sigan siendo válidas cuando una persona que actúa de mala fe la encuentre.
Logging y Monitoring 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.
Transfiere 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 en Cloud Monitoring a través de un agente independiente. En esta configuración, vCenter reenvía métricas como el uso de memoria y CPU de ESXi a Cloud Monitoring. Se recomienda crear paneles basados en métricas que reenvía vCenter o comenzar 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 Syslog a un agregador de registros centralizado. Esto se puede hacer para los mensajes de vCenter y NSX-T Syslog. La recopilación, retención y análisis de mensajes Syslog de vCenter tiene casos de uso de seguridad importantes, como las alertas en tiempo real basadas en accesos administrativos (o usuarios de emergencia) que deben realizarse solo en circunstancias excepcionales. Para analizar los mensajes Syslog, se debe configurar un agregador Syslog, como Fluentd o el agente independiente, a fin de 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 agregar los proyectos mediante la configuración de receptores de registros y permisos de supervisión.
Usar el agente de Cloud Logging para el registro de VM de cargas de trabajo
Las VM 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 comunes de terceros y software del sistema a Cloud Logging. Como práctica recomendada, alinea el enfoque de recopilación y análisis de registros de las VM de carga de trabajo en VMware Engine con el enfoque para las instancias de Compute Engine y tu patrimonio local (si corresponde). El uso del agente de Logging en VMware Engine coincide con el enfoque que se usa para las VM en Compute Engine, de modo que las cargas de trabajo en ambas plataformas envíen sus registros a Cloud Logging.
Aplica capacidades equivalentes a las políticas de Transparencia de acceso y Aprobación de acceso
Si bien VMware Engine aún no es compatible de forma nativa con la transparencia de acceso (AxT) y la aprobación de acceso (AxA) en Google Cloud, implementamos procesos con capacidades equivalentes que se pueden habilitar si se solicita.
Para la equivalencia de la transparencia de acceso, debes considerar varias fuentes de registros, incluidas las siguientes:
- Registros de vCenter: se pueden exportar mediante la configuración remota del servidor syslog.
- Registros de ESXi: estos se pueden recopilar mediante la configuración remota de syslog; sin embargo, es necesario presentar una solicitud de asistencia en 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 de acceso. En esta política, las operaciones de servicio estándar exigen que se genere un ticket de asistencia con un motivo por el que los operadores del servicio de acceso lo requieran.
Se aplican las exclusiones de 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 que impulsan a tener en cuenta a la hora de elegir un proveedor de claves para la nube privada.
Usa un proveedor de claves administrado por Google habilitado para la encriptación en reposo de vSAN
La encriptación de datos en reposo se implementa mediante la encriptación basada en el 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 ESXi, y la inhabilitación de la encriptación de vSAN es una infracción de las condiciones del servicio para 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 regulaciones a encriptar datos (por ejemplo, NIST o FIPS).
Cada host ESXi encripta datos mediante el modo estándar AES-256 XTS con diferentes claves de encriptación de datos (DEK) generadas al azar. La DEK se encripta con una clave de encriptación de claves (KEK) y solo se almacena en el disco de forma encriptada. El servidor de 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, uno de los proveedores admitidos puede usar un Cloud KMS de terceros compatible con KMIP 1.1. En ambos casos, el proveedor de claves se puede usar para encriptar datos en reposo y tráfico de vMotion en tránsito.
En la siguiente tabla, se destacan las diferencias clave entre las integraciones del proveedor de claves predeterminado y las de terceros de Cloud KMS:
| Proveedor de claves | Ventajas | Desventajas |
|---|---|---|
| Proveedor de claves administrado por Google predeterminado |
|
|
| Proveedor de claves de Cloud KMS de terceros |
|
|
Ten en cuenta que no se recomienda habilitar la encriptación a nivel de VM junto con la encriptación del almacén de datos de vSAN, ya que la eficiencia de anulación de duplicación se acerca a cero para las VM encriptadas.
Automatiza la rotación de claves de encriptación según los estándares de tu organización
Eres responsable de la rotación de las KEK mediante la funcionalidad que proporciona VMware Engine vSphere. Este es el caso con el proveedor de claves predeterminado y con un Cloud KMS externo. La rotación de la KEK se puede iniciar desde vCenter o mediante su API. Considera automatizar la rotación de las 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 ransomware, corrupción y errores humanos. Además, las aplicaciones fundamentales para la empresa dependen de que tus datos estén disponibles de forma virtual en todo momento, lo que te deja poco tiempo para recuperar datos de interrupciones repentinas. Esta sección no contiene una cobertura completa de todos los aspectos de copias de seguridad y recuperación ante desastres que son relevantes para diseñar de manera eficaz una estrategia de copia de seguridad y DR a fin de mantener tus datos seguros y disponibles, pero que contienen consideraciones clave a la hora de elegir la estrategia correcta 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 de copia de seguridad nativa y administrada centralmente que se puede usar para una variedad de casos prácticos, 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 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 que ahorran espacio, copias de seguridad incrementales permanentes y opciones de almacenamiento flexible.
Google Cloud VMware Engine también admite el uso de soluciones de copia de seguridad de terceros basadas en agentes. Puedes preferir estas opciones si ya tienes licencias para un producto de copia de seguridad de terceros. Los requisitos previos para este tipo de herramientas incluyen los siguientes:
- Proporcionan copias de seguridad a nivel de aplicación
- Cuentan con la certificación de los proveedores de la aplicación.
- Cuentan con la certificación de VMware Engine para vSAN.
- Admite el estándar de la API de VMware Engine vStorage para la protección de datos (VADP)
Sin importar la solución de copia de seguridad que elijas, 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 muy duradero. Los buckets de Cloud Storage se pueden configurar para replicar automáticamente objetos de almacenamiento en varias regiones, lo que es ideal para las topologías de Cloud multirregionales.
Cloud Storage también es ideal para el archivado a largo plazo, ya que proporciona políticas de ciclo de vida a fin de mover automáticamente objetos de almacenamiento a otro nivel de almacenamiento una vez que su ciclo de vida supera un valor predefinido. Usa esta opción para una ubicación de almacenamiento de copia de seguridad rentable y RPO de valor medio a alto, en especial si el costo es un factor impulsor.
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 las 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 limiten al almacenamiento.
Implementa la recuperación ante desastres con el servicio de copia de seguridad y DR
Recomendamos restablecer las aplicaciones en VMware Engine con el servicio de copia de seguridad y DR. Para proteger las 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, te recomendamos restablecer las aplicaciones en una región secundaria.
Además de la copia de seguridad y DR de Google Cloud, VMware Engine es compatible con otras opciones de DR, como VMware Engine SRM y Zerto. Tanto VMware Engine SRM como Zerto dependen de vSphere Replication para la recuperación ante desastres, que, por lo general, admite objetivos de RPO más bajos. Si tu objetivo de RPO es de minutos en lugar de horas, considera usar soluciones de DR basadas en vSphere Replication.
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. Consulta las funciones, los beneficios y los casos de uso para obtener más información.
- Lee acerca de los conceptos de seguridad de VMware Engine.
- Explorar arquitecturas de referencia, diagramas, instructivos y prácticas recomendadas sobre Google Cloud Visita Cloud Architecture Center para obtener más información.