Bonnes pratiques en matière de sécurité de VMware Engine
Ce document décrit les bonnes pratiques de sécurité recommandées pour la gestion et la configuration de Google Cloud VMware Engine. Il est destiné aux utilisateurs qui connaissent déjà VMware Engine. Si vous débutez, nous vous recommandons de commencer par vous familiariser avec les conditions préalables et la sécurité de VMware Engine.
VMware Engine repose sur un modèle de responsabilité partagée en matière de sécurité. Une sécurité fiable dans le cloud est assurée via les responsabilités partagées des clients et Google en tant que fournisseur de services. Ces bonnes pratiques peuvent vous aider à gagner du temps, à éviter les erreurs et à atténuer les effets des points de défaillance.
Mise en réseau VMware Engine
Les sections suivantes présentent les bonnes pratiques de mise en réseau dans un environnement VMware Engine.
Identifier et comprendre tous les flux de trafic de votre environnement
VMware Engine exploite les réseaux VMware Engine et les mises en pairage VPC pour connecter une connexion réseau privée à partir d'un réseau cloud privé VMware Engine à votre réseau VPC. Le trafic entrant d'un VPC de votre environnement Google Cloud ou d'un réseau sur site traverse un réseau d'unité de location géré par Google.
Utiliser le service d'adresse IP publique de VMware Engine pour le transfert de données Internet
Le trafic Internet peut entrer directement dans un cloud privé à l'aide du service d'adresse IP publique de VMware Engine. Le trafic Internet peut également entrer à l'aide d'un équilibreur de charge public sur Google Cloud. Dans ce cas, le trafic est acheminé comme tout autre trafic entrant. Notez que ces options sont mutuellement exclusives. Si des commandes personnalisées sont requises pour le trafic Internet, telles que le filtrage d'URL, l'IPS/IDS ou l'inspection du trafic fournie par une instance ou un service central dans votre environnement Google Cloud, vous devez acheminer le trafic Internet via le réseau VPC.
Si ce n'est pas le cas ou si vous avez implémenté les commandes dans votre cloud privé, nous vous recommandons d'inclure le service d'adresse IP externe dans VMware Engine. En outre, nous vous recommandons d'utiliser des règles d'accès externes pour refuser les modèles de trafic provenant d'Internet qui ne s'appliquent pas à vos applications.
Séparer les règles de pare-feu nord-sud et est-ouest sur la passerelle et le pare-feu distribué dans VMware Engine NSX-T
Configurez le pare-feu distribué (DFW) dans NSX-T sur le routeur logique de niveau 1 pour segmenter le trafic interne entre vos domaines de couche 2 virtuels. Le DFW NSX est conçu pour gérer le trafic réseau (interne) est-ouest entre les segments et permet d'appliquer des règles de pare-feu qui autorisent et refusent le trafic entre les instances individuelles d'un segment.
Pour un contrôle précis de l'accès au réseau, veillez à appliquer une stratégie par défaut limitée sur le DFW afin de refuser le trafic réseau entre les instances par défaut. Utilisez le DFW pour autoriser spécifiquement le trafic entre les applications et les services de votre application.
Configurez le pare-feu de passerelle NSX pour contrôler le trafic nord-sud qui entre et sort du cloud privé.
Le pare-feu de passerelle NSX est conçu pour contrôler le trafic nord-sud et est recommandé pour des cas d'utilisation tels que le contrôle du trafic à un périmètre vers une autre zone de sécurité. Si vous devez configurer le trafic nord-sud pour l'ensemble du cloud privé de manière cohérente, configurez le pare-feu de la passerelle sur le routeur de niveau 0. Si vous devez configurer le trafic nord-sud pour chaque segment NSX-T, configurez le pare-feu de la passerelle sur le routeur de niveau 1.
En plus des pare-feu NSX-T, il est recommandé d'utiliser le pare-feu VPC pour autoriser et bloquer le trafic est-ouest entre les charges de travail du cloud privé VMware Engine et les charges de travail des VPC. Le transfert de données entrantes vers les instances Compute Engine à partir des charges de travail VMware Engine doit être limité par défaut, et ne doit concerner que le trafic ouvert consciemment.
Le transfert de données sortant vers les appareils de gestion ainsi que vers la plage CIDR vSphere/vSAN doit également être bloqué depuis les VPC à l'aide du pare-feu VPC. N'ouvrez le transfert de données sortantes vers les dispositifs de gestion que depuis des hôtes et des adresses IP de confiance au sein de votre réseau. Il est important de noter que les appliances de gestion ne se trouvent pas dans un segment NSX-T. Par conséquent, les règles de DFW ne s'appliquent pas pour limiter l'accès.
Appliquer les principes de sécurité zéro confiance et la microsegmentation dans NSX-T
Utilisez le DFW NSX-T pour implémenter des contrôles de trafic pour des segments de sécurité aussi précis que des machines virtuelles individuelles. Ce principe de protection du trafic entre des VM individuelles qui est refusé par défaut est souvent également appelé micro-segmentation, qui est une approche plus précise du pare-feu que l'implémentation classique des pare-feu entre les domaines de couche 3.
Le DFW est activé dans le noyau de l'hyperviseur sur tous les hôtes vSphere VMware Engine de votre cloud privé. Il peut contrôler le flux de trafic entre les charges de travail situées dans le même segment NSX ou dans des segments NSX distincts. Les règles de pare-feu permettant le trafic vers et depuis les VM peuvent être définies en organisant les VM en groupes de règles, qui peuvent avoir des critères d'appartenance flexibles, tels que la correspondance de tag ou de nom de VM.
La microsegmentation vous permet d'implémenter un réseau avec un contrôle précis du trafic, où un modèle de trafic doit être explicitement autorisé. Le concept de sécurité selon lequel tous les flux réseau sont contrôlés par des processus de vérification de l'identité et des appareils plutôt que par une confiance implicite est souvent également appelé sécurité zéro confiance.
Déployer un dispositif de pare-feu tiers à partir du portail Cloud Marketplace pour bénéficier des fonctionnalités IPS/IDS
Si vous avez besoin d'une sécurité de couche 7 avancée, y compris de fonctionnalités IDS/IPS pour le trafic entrant dans le cloud privé à partir du reste de votre réseau ou entre vos segments de réseau NSX-T, envisagez de déployer un dispositif de pare-feu tiers. L'appareil tiers peut être déployé en tant qu'appareil multi-NIC entre deux VPC de votre réseau Google Cloud ou dans le cloud privé avec une intégration à NSX-T.
Pour en savoir plus sur les architectures VMware Engine avec des dispositifs centralisés, qui peuvent être utilisés pour divers cas d'utilisation de sécurité avancés, tels que l'IPS/IDS, les attaques DDoS, le déchargement SSL, etc., consultez le document "Sécurité du réseau à l'aide de dispositifs centralisés" dans le Centre d'architecture cloud.
Utiliser Google Cloud Armor pour protéger les services Web sur VMware Engine contre les attaques DDoS
Si vous acheminez le trafic entrant vers les charges de travail sur VMware Engine via le VPC client, nous vous recommandons de placer les charges de travail VMware Engine dans des groupes de points de terminaison réseau hybrides derrière Cloud Service Mesh et d'utiliser l'équilibreur de charge HTTP(S) externe. Les deux configurations vous permettent d'inclure Google Cloud Armor pour les applications publiques, ce qui atténue les attaques DDoS et les failles courantes telles que les injections SQL ou les scripts intersites.
Si vous avez besoin de fonctionnalités de service de maillage telles que la gestion avancée du trafic à l'aide du proxy Envoy ou l'intégration du Certificate Authority Service, nous vous recommandons d'utiliser Cloud Service Mesh. Dans tous les autres cas, nous vous recommandons l'équilibreur de charge HTTP(S) externe.
Consultez la documentation sur l'ajout de charges de travail VMware Engine aux NEG hybrides dans l'une des configurations suivantes:
- Équilibrement de charge HTTP(S) externe régional avec une connectivité hybride
- Équilibreur de charge HTTP(S) externe global avec connectivité hybride
Se connecter aux services Google Cloud en privé sans accès à Internet
Les charges de travail cloud privé VMware Engine peuvent accéder aux API Google Cloud telles que l'API Cloud Storage à l'aide de l'accès privé à Google. Nous vous recommandons d'utiliser lAccès privé à Google pour accéder aux services Google sans envoyer de trafic sur Internet, car cela réduit les coûts et la latence associés aux transferts de données sortants. Cela élimine également le besoin d'un chemin réseau vers Internet pour les charges de travail qui n'ont besoin que d'un accès aux API Google. Pour en savoir plus sur les détails techniques et les étapes de configuration, consultez notre présentation détaillée de l'accès privé à Google.
De même, les charges de travail VMware Engine qui doivent accéder aux ressources Google Cloud à partir d'un réseau de producteurs de services tels que des instances Cloud SQL ou Memorystore doivent se connecter de manière privée à l'aide de PSA. Pour en savoir plus, consultez la section sur le PSA pour VMware Engine.
Chiffrer la communication entre votre environnement sur site et Google Cloud
Les charges de travail sur VMware Engine qui doivent communiquer avec des systèmes sur site doivent se connecter via un canal chiffré. Nous vous recommandons d'utiliser une approche multicouche pour le chiffrement en transit entre vos centres de données sur site et Google Cloud. La liaison entre les systèmes sur site et Google Cloud peut être chiffrée en configurant Cloud VPN avec un tunnel IPsec ou en utilisant l'IPsec intégré sur les rattachements VLAN de l'interconnexion. De plus, le chiffrement de la couche application doit être activé entre les composants d'application à l'aide de TLS.
Protéger vos données contre l'exfiltration à l'aide de VPC Service Controls
Nous vous recommandons de limiter les risques d'exfiltration des données à l'aide de VPC Service Controls en plaçant vos ressources sensibles telles que les buckets Cloud Storage et les ensembles de données BigQuery dans un périmètre VPC Service Controls. Les charges de travail qui doivent accéder aux données dans un périmètre doivent également être placées dans ce périmètre. Plus précisément, le projet Google Cloud qui héberge le cloud privé doit faire partie du périmètre VPC Service Controls pour accéder aux ressources protégées par VPC Service Controls.
Vous devez configurer des règles de transfert de données entrantes et sortantes dans votre configuration VPC Service Controls pour autoriser les API du service de production VMware Engine dans le périmètre. Pour obtenir des instructions détaillées sur la configuration, consultez nos pages de documentation sur VPC Service Controls avec VMware Engine.
IAM et autorisations VMware Engine
Les sections suivantes présentent les bonnes pratiques concernant les autorisations utilisateur dans un environnement VMware Engine. Il est important de gérer les autorisations dans l'environnement VMware Engine et le projet Google Cloud dans lequel le cloud privé est déployé.
Accorder l'accès à l'aide de rôles prédéfinis ou personnalisés
L'approche VMware Engine pour gérer les rôles et autorisations vSphere peut être exploitée de la même manière que vous le faites dans d'autres environnements VMware Engine. Toutefois, des activités telles que le déploiement d'un cluster nécessitent des autorisations dans Identity and Access Management (IAM). Le tableau suivant répertorie les gestionnaires d'accès pertinents, les sources d'identité auxquelles ils accordent des autorisations et des exemples d'activités qu'ils permettent.
Plate-forme | Composant | Source d'identité | Où configurer les autorisations | Exemples d'activités |
---|---|---|---|---|
Google Cloud | Portail VMware Engine | Cloud Identity | Identity and Access Management | Déploiement et annulation de cloud privé, déploiement et annulation de cluster, par exemple. |
VMware Engine | vCenter | LDAP | Hôtes et clusters, VM et dossiers, datastores dans l'UI vCenter | Création de VM, création de dossiers de VM, création et suppression d'objets de datastore, par exemple |
NSX-T | LDAP | "Utilisateurs et rôles" dans l'interface utilisateur de NSX-T Manager | Création de segments NSX, configuration de pare-feu, configuration d'un équilibreur de charge, par exemple. | |
vCenter | Système d'exploitation invité de la VM | Active Directory, LDAP, utilisateurs locaux, par exemple | Système d'exploitation invité | Connexion SSH ou RDP, opérations de fichiers, par exemple |
Dans Google Cloud IAM, il existe deux rôles prédéfinis disposant d'autorisations sur le portail VMware Engine:
- Administrateur du service VMware Engine : permet d'accéder à l'intégralité du service VMware Engine sur Google Cloud.
- Lecteur du service VMware Engine : permet d'accéder en lecture seule au service VMware Engine sur Google Cloud.
Ces autorisations concernent les actions dans le portail VMware Engine et non les actions dans l'API ou la CLI. Notez que les rôles de base incluent également la possibilité de gérer le service VMware Engine (propriétaire, éditeur) ou d'afficher les détails du service (lecteur). En règle générale, il est recommandé d'utiliser des rôles prédéfinis plutôt que des rôles de base, car ils offrent des autorisations plus précises.
L'accès programmatique à VMware Engine à l'aide de comptes de service utilisant l'API ou la CLI doit être limité à l'aide de rôles prédéfinis ou de rôles personnalisés, car ils incluent des autorisations plus précises qui ne s'appliquent qu'à VMware Engine. Si l'accès programmatique n'est utilisé que pour une tâche qui ne nécessite qu'un sous-ensemble spécifique des autorisations des rôles prédéfinis, il est recommandé de créer un rôle personnalisé.
Choisissez un emplacement approprié pour l'attribution du rôle IAM dans la hiérarchie des ressources de votre organisation. Si vous exécutez tous vos clouds privés VMware Engine dans un seul projet, seuls les rôles peuvent être attribués au niveau du projet. Si des exigences techniques ou organisationnelles entraînent la localisation de vos clouds privés dans des projets distincts, définissez les rôles requis dans un dossier commun aux projets utilisés pour vos clouds privés.
Les autorisations Cloud IAM ne sont pas requises pour les activités qui ne doivent être effectuées que dans vCenter, NSX-T ou HCX. Le personnel qui ne doit gérer que ces environnements n'a pas besoin des rôles IAM listés précédemment. Ils doivent plutôt utiliser des identités LDAP avec des autorisations configurées dans vCenter et NSX-T. Nous vous recommandons de n'attribuer les rôles "Administrateur de services VMware Engine" ou "Lecteur de services VMware Engine" qu'à un nombre très limité d'utilisateurs, car ces rôles permettent d'accéder au compte utilisateur CloudOwner puissant pour vCenter et au compte utilisateur administrateur pour NSX-T. Ces comptes utilisateur ne doivent être utilisés que pour la configuration initiale ou les procédures d'urgence.
Limiter et auditer activement l'accès administrateur
Le rôle d'administrateur de service VMware Engine est très puissant et ne doit être attribué qu'aux utilisateurs qui doivent gérer le cycle de vie du cloud privé VMware Engine et de ses clusters. En règle générale, l'ajout ou la suppression manuels de clusters et de nœuds est une action qui ne se produit pas fréquemment et qui peut avoir un impact important sur la facturation ou la disponibilité du cluster. N'attribuez ce rôle qu'à très peu de personnes dans votre organisation.
Veillez à effectuer régulièrement un audit des utilisateurs auxquels le rôle Administrateur de service VMware Engine a été attribué, soit directement sur le projet utilisé pour VMware Engine, soit sur l'un des niveaux parent de la hiérarchie des ressources. Cet audit doit inclure d'autres rôles, tels que les rôles Éditeur et Propriétaire de base, qui incluent des autorisations critiques liées à VMware Engine. Vous pouvez utiliser des services tels que l'outil de recommandation de rôles IAM pour identifier les rôles trop privilégiés.
Configurer une source d'identité LDAP ou Active Directory
Un fournisseur d'identité compatible avec l'authentification LDAP, tel qu'Active Directory, doit être configuré pour activer l'authentification des utilisateurs pour vCenter et NSX Manager. Il est recommandé de centraliser la gestion du cycle de vie des identités, la gestion des groupes, la gestion des mots de passe, etc. Notez que l'association directe de vCenter et de NSX-T à Active Directory pour l'authentification Windows intégrée n'est pas prise en charge.
Alterner les mots de passe des comptes de service intégrés
VMware Engine génère des identifiants pour accéder aux dispositifs de gestion du cloud privé (tels que vCenter, NSX-T et HCX). Il est recommandé d'établir un processus de rotation des mots de passe du compte de service vCenter par défaut CloudOwner@gve.local et de l'administrateur du compte de service NSX-T par défaut. Les deux comptes utilisateur ne doivent être utilisés que pour la configuration initiale et les procédures d'urgence, et leurs mots de passe doivent être modifiés régulièrement (par exemple, tous les 60 ou 90 jours). De même, alternez régulièrement les mots de passe des comptes utilisateur de la solution couramment utilisés pour l'intégration d'outils tiers. Plus vous alternez souvent les mots de passe des comptes de service, moins il y a de risques qu'un pirate informatique les trouve encore valides.
Journalisation et surveillance de VMware Engine
Les sections suivantes présentent les bonnes pratiques de journalisation et de surveillance des charges de travail VM et de l'infrastructure VMware Engine, qui fournit les ressources consommées par les charges de travail.
Ingérer les journaux et les métriques VMware Engine
De nombreuses entreprises souhaitent collecter et analyser les journaux dans un "Single Pane of Glass" centralisé. Dans Google Cloud, les produits Cloud Logging et Cloud Monitoring fournissent des services qui peuvent être utilisés pour la gestion centralisée des journaux et des métriques. VMware Engine peut être intégré à Cloud Monitoring à l'aide d'un agent autonome. Dans cette configuration, vCenter transmet des métriques telles que l'utilisation du processeur et de la mémoire ESXi à Cloud Monitoring. Il est recommandé de créer des tableaux de bord basés sur les métriques transmises par vCenter ou de commencer avec des exemples de tableaux de bord publiés sur GitHub.
Pour collecter les journaux de la plate-forme, les clouds privés VMware Engine peuvent transférer les journaux syslog vers un agrégateur de journaux centralisé. Vous pouvez le faire pour les messages syslog vCenter et NSX-T. La collecte, la conservation et l'analyse des messages Syslog à partir de vCenter présentent des cas d'utilisation de sécurité importants, tels que les alertes en temps réel basées sur les connexions des utilisateurs administrateurs (ou des utilisateurs d'urgence), qui ne doivent être effectuées que dans des circonstances exceptionnelles. Pour analyser les messages Syslog, un agrégateur Syslog tel que Fluentd ou l'agent autonome doit être configuré pour relayer les messages vers Cloud Logging.
Il est recommandé d'analyser les journaux de VMware Engine dans un tableau de bord centralisé dans un seul projet. Si votre environnement VMware Engine couvre plusieurs projets, vous devez également agréger vos projets en configurant des destinations de journalisation et des champs d'application de surveillance.
Utiliser l'agent Cloud Logging pour la journalisation des VM de charge de travail
Les VM de charge de travail VMware Engine peuvent envoyer des journaux directement à l'API Cloud Logging à l'aide de l'agent Logging. L'agent Logging est basé sur fluentd et transmet les journaux des applications tierces courantes et des logiciels système à Cloud Logging. Il est recommandé d'aligner l'approche de collecte et d'analyse des journaux pour les VM de charge de travail sur VMware Engine avec celle des instances Compute Engine et de votre parc sur site (le cas échéant). L'utilisation de l'agent Logging sur VMware Engine correspond à l'approche utilisée pour les VM sur Compute Engine, de sorte que les charges de travail sur les deux plates-formes envoient leurs journaux à Cloud Logging.
Appliquer des fonctionnalités équivalentes aux stratégies Access Transparency et Access Approval
Bien que VMware Engine ne prenne pas en charge la transparence des accès (AxT) et l'approbation des accès (AxA) dans Google Cloud, nous avons implémenté des processus avec des fonctionnalités équivalentes qui peuvent être activées sur demande.
Pour l'équivalence de la transparence des accès, vous devez prendre en compte plusieurs sources de journaux, y compris:
- Journaux vCenter : exportables à l'aide de la configuration du serveur syslog distant.
- Journaux ESXi : ils peuvent être collectés à l'aide de la configuration syslog à distance. Toutefois, vous devez envoyer une demande d'assistance à Google Cloud pour configurer le transfert syslog ESXi.
Si vous avez des exigences réglementaires strictes, nous implémentons une stratégie pour fournir des fonctionnalités équivalentes pour l'approbation des accès. Conformément à ce règlement, les opérations de service standards nécessitent la création d'une demande d'assistance indiquant pourquoi les opérateurs de services d'accès ont besoin d'accéder aux données.
Les exclusions d'Access Approval Google Cloud s'appliquent.
Chiffrement VMware Engine
Les sections suivantes présentent les bonnes pratiques de chiffrement du stockage dans le cloud privé et les facteurs déterminants à prendre en compte lors du choix d'un fournisseur de clés pour votre cloud privé.
Utiliser un fournisseur de clés géré par Google activé pour le chiffrement au repos vSAN
Le chiffrement des données au repos est implémenté à l'aide du chiffrement logiciel de vSAN. Par défaut, VMware Engine active le chiffrement vSAN sur chaque cluster ESXi et configure un fournisseur de clés par défaut dans vCenter. Google exige que les clients laissent le chiffrement vSAN activé sur leurs clusters ESXi. La désactivation du chiffrement vSAN constitue un cas de non-respect des conditions d'utilisation du service VMware Engine. De nombreuses organisations exigent le chiffrement au repos dans le cadre de leurs règles d'entreprise ou sont tenues par la réglementation de chiffrer les données (par exemple, NIST, FIPS).
Chaque hôte ESXi chiffre les données à l'aide du mode XTS AES-256 standard avec des clés de chiffrement des données (DEK) différentes générées de manière aléatoire. La clé DEK est chiffrée à l'aide d'une clé de chiffrement de clé (KEK) et n'est stockée sur le disque que sous forme chiffrée. Le serveur vCenter ne stocke que l'ID de la clé KEK, mais pas la clé KEK elle-même, qui est stockée dans un service Cloud Key Management Service (KMS). Vous pouvez choisir l'emplacement Cloud KMS où votre KEK est stocké.
Nous vous recommandons d'utiliser le fournisseur de clés par défaut géré par Google. Toutefois, si vous devez gérer vous-même votre Cloud KMS, vous pouvez utiliser un Cloud KMS tiers conforme à KMIP 1.1 fourni par l'un des fournisseurs compatibles. Dans les deux cas, le fournisseur de clés peut être utilisé pour chiffrer les données au repos et le trafic vMotion en transit.
Le tableau suivant met en évidence les principales différences entre le fournisseur de clés par défaut et les intégrations Cloud KMS tierces:
Fournisseur de clés | Avantages | Inconvénients |
---|---|---|
Fournisseur de clés par défaut géré par Google |
|
|
Fournisseur tiers de clés Cloud KMS |
|
|
Notez qu'il n'est pas recommandé d'activer le chiffrement au niveau de la VM avec le chiffrement du datastore vSAN, car l'efficacité de la déduplication est proche de zéro pour les VM chiffrées.
Automatisez la rotation des clés de chiffrement conformément aux normes de votre organisation.
Vous êtes responsable de la rotation de la KEK à l'aide de VMware Engine vSphere. C'est le cas à la fois avec le fournisseur de clés par défaut et avec un Cloud KMS externe. La rotation du KEK peut être lancée à partir de vCenter ou à l'aide de son API. Envisagez d'automatiser la rotation du KEK en fonction des exigences de votre organisation. Vous trouverez un exemple de script PowerCLI sur GitHub.
Sauvegarde et reprise après sinistre VMware Engine
Il est important de protéger vos données contre les menaces telles que les rançongiciels, la corruption et les erreurs humaines. De plus, les applications critiques pour l'entreprise s'appuient sur la disponibilité quasi permanente de vos données, ce qui vous laisse peu de temps pour les récupérer en cas d'indisponibilité soudaine. Cette section ne couvre pas tous les aspects de la sauvegarde et de la reprise après sinistre pertinents pour concevoir efficacement une stratégie de sauvegarde et de reprise après sinistre afin de sécuriser et de rendre disponibles vos données. Elle contient toutefois des considérations clés à prendre en compte lorsque vous choisissez la stratégie adaptée à votre environnement VMware Engine.
Sauvegarder vos charges de travail à l'aide du service Backup and DR
Avec le service Backup and DR, Google Cloud propose une solution de sauvegarde intégrée et gérée de manière centralisée qui peut être utilisée pour divers cas d'utilisation, y compris la sauvegarde des charges de travail sur Compute Engine et Google Cloud VMware Engine. Le service de sauvegarde et de reprise après sinistre est la solution unique recommandée par Google pour les sauvegardes de charges de travail, car il offre des avantages tels qu'une large gamme de prise en charge des charges de travail, des sauvegardes incrémentielles et illimitées, et des options de stockage flexibles.
Google Cloud VMware Engine est également compatible avec l'utilisation de solutions de sauvegarde tierces basées sur des agents. Vous pouvez les préférer si vous disposez déjà de licences pour un produit de sauvegarde tiers. Les prérequis pour ces types d'outils incluent les éléments suivants:
- Elles fournissent des sauvegardes au niveau de l'application.
- Elles sont certifiées par les fournisseurs d'applications.
- Ils sont certifiés par VMware Engine pour vSAN.
- Ils sont compatibles avec la norme du protocole VMware Engine vStorage API for Data Protection (VADP) ou effectuent des sauvegardes au niveau de l'application.
Quelle que soit la solution de sauvegarde de votre choix, nous vous recommandons Cloud Storage comme option de stockage économique pour la conservation à long terme des sauvegardes. Cloud Storage est un système de stockage d'objets très durable et économique. Les buckets Cloud Storage peuvent être configurés pour répliquer automatiquement les objets de stockage dans plusieurs régions, ce qui est idéal pour les topologies Cloud multirégionales.
Cloud Storage est également idéal pour l'archivage à long terme, car il fournit des règles de cycle de vie permettant de déplacer automatiquement les objets de stockage vers un autre niveau de stockage une fois que leur durée de vie dépasse une valeur prédéfinie. Utilisez cette option pour un emplacement de stockage de sauvegarde rentable et des RPOs moyens à élevés, en particulier si le coût est un facteur déterminant.
Vous pouvez également choisir le stockage vSAN pour réduire le RPO. Utilisez cette option de stockage si un coût plus élevé pour le stockage de sauvegarde est acceptable et que les exigences de RPO ne peuvent pas être satisfaites avec Cloud Storage. Évitez cette option pour l'archivage à long terme, car il existe un risque que les tailles de cluster VMware Engine deviennent limitées par l'espace de stockage.
Implémenter la reprise après sinistre avec le service Backup and DR
Nous vous recommandons de restaurer les applications sur VMware Engine à l'aide du service Backup and DR. Pour protéger vos charges de travail de production contre les pannes d'une seule zone d'une région, nous vous recommandons de déployer et d'exploiter un cloud privé dans une zone secondaire de la région si VMware Engine est disponible dans plusieurs zones de cette région. Si ce n'est pas le cas, nous vous recommandons de restaurer vos applications dans une région secondaire.
En plus de Google Cloud Backup and DR, VMware Engine est compatible avec d'autres options de reprise après sinistre, telles que VMware Engine SRM et Zerto. VMware Engine SRM et Zerto s'appuient tous deux sur la réplication vSphere pour la reprise après sinistre, qui accepte généralement des cibles RPO plus faibles. Si votre objectif de RPO est exprimé en minutes et non en heures, envisagez des solutions de DR basées sur la réplication vSphere.
Checklist
La checklist suivante récapitule les bonnes pratiques de sécurité à suivre pour utiliser VMware Engine.
Étape suivante
- Essayez Google Cloud VMware Engine par vous-même. Pour en savoir plus, consultez la page Fonctionnalités, avantages et cas d'utilisation.
- Découvrez les concepts de sécurité de VMware Engine.
- Découvrez des architectures de référence, des schémas, des tutoriels et des bonnes pratiques concernant Google Cloud. Pour en savoir plus, consultez le Centre d'architecture cloud.