Bonnes pratiques de sécurité pour VMware Engine
Ce document décrit les bonnes pratiques de sécurité recommandées pour gérer et configurer Google Cloud VMware Engine. Il est destiné aux utilisateurs qui connaissent déjà VMware Engine. Si vous débutez, vous pouvez commencer par vous renseigner sur les conditions préalables et la sécurité VMware Engine.
VMware Engine repose sur un modèle de responsabilité partagée en matière de sécurité. La sécurité fiable dans le cloud est assurée grâce aux responsabilités partagées entre les clients et Google en tant que fournisseur de services. Le respect de ces bonnes pratiques peut vous aider à gagner du temps, à éviter les erreurs et à atténuer les effets des points de défaillance.
Identifier et comprendre tous les flux de trafic de votre environnement
Pour protéger vos charges de travail et vos interfaces de gestion sur votre cloud privé, il est important d'identifier et de comprendre tous les flux de trafic de votre environnement. Une liste des principaux flux de trafic dans VMware Engine est disponible dans le document Mise en réseau du cloud privé pour VMware Engine.
VMware Engine exploite l'accès aux services privés (PSA) pour exposer une connexion réseau privée à votre réseau VPC à partir d'un réseau de cloud privé VMware Engine. Le trafic Ingress provenant d'un VPC de votre environnement Google Cloud ou d'un réseau sur site transite par un réseau du producteur de services géré par Google.
Utiliser le service IP public de VMware Engine pour l'entrée Internet
Le trafic Internet peut entrer directement dans un cloud privé à l'aide du service d'adresse IP publique de VMware Engine. Un équilibreur de charge public sur Google Cloud permet également d'accéder au trafic Internet. Dans ce cas, le trafic est acheminé comme tout autre trafic entrant via un accès privé aux services. Notez que ces options s'excluent mutuellement. Si des contrôles personnalisés sont requis pour le trafic Internet, tels que le filtrage d'URL, les contrôles IPS/IDS ou l'inspection du trafic fournis par une instance ou un service central de votre environnement Google Cloud, vous devez acheminer le trafic Internet via votre VPC et le VPC partagé du producteur de services.
Si cela ne vous concerne pas ou si vous avez mis en œuvre les contrôles dans votre cloud privé, nous vous recommandons d'inclure le service d'adresses IP publiques dans VMware Engine. En outre, nous vous recommandons d'utiliser les règles de pare-feu avec état 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 virtuelle 2. NSX DFW est conçu pour gérer le trafic réseau est-ouest (interne) entre les segments et autorise les 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 règle par défaut restreinte sur le DFW afin de refuser par défaut le trafic réseau entre les instances. Utilisez le protocole DFW pour autoriser spécifiquement le trafic entre les applications et entre les services au sein de votre application.
Configurez le pare-feu de la passerelle NSX pour contrôler le trafic nord-sud entrant et sortant 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 au niveau d'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 individuel, configurez le pare-feu de la passerelle sur le routeur de niveau 1.
Outre les 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 celles des VPC. L'Ingress vers les instances Compute Engine à partir des charges de travail VMware Engine doit être limitée par défaut avec le trafic ouvert uniquement.
La sortie vers les dispositifs de gestion ainsi que vers la plage CIDR vSphere/vSAN doit être bloquée à partir des VPC et du pare-feu VPC. N'ouvrez la sortie vers les dispositifs de gestion que depuis des hôtes approuvés et des adresses IP au sein de votre réseau. Il est important de noter que les dispositifs de gestion ne font pas partie d'un segment NSX-T. Par conséquent, les règles DFW ne s'appliquent pas pour restreindre l'accès.
Appliquer les principes de sécurité zéro confiance et la microsegmentation dans NSX-T
Utilisez NSX-T DFW afin de mettre en œuvre 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 refusé par défaut entre des VM individuelles est souvent appelé microsegmentation, qui constitue une approche plus précise du pare-feu que la mise en œuvre traditionnelle de pare-feu entre les domaines de couche 3.
Le DFW est activé dans le noyau de l'hyperviseur sur tous les hôtes VMware Engine vSphere de votre cloud privé et peut contrôler le flux de trafic entre les charges de travail qui se trouvent dans le même segment NSX ou dans des segments NSX distincts. Vous pouvez définir des règles de pare-feu autorisant le trafic vers et depuis les VM en organisant les VM en groupes de règles, qui peuvent comporter des critères d'appartenance flexibles, tels que des tags de VM ou des correspondances de noms.
La microsegmentation vous permet de mettre en œuvre un réseau avec un contrôle du trafic ultraprécis, là où tout modèle de trafic souhaité doit être explicitement autorisé. Le concept de sécurité selon lequel tous les flux réseau sont contrôlés par des processus de validation d'identité et d'appareil 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 les fonctionnalités IPS/IDS
Si vous avez besoin d'une sécurité avancée de couche 7, y compris de fonctionnalités IDS/IPS pour le trafic entrant dans le cloud privé en provenance du reste de votre réseau ou entre vos segments réseau NSX-T, envisagez de déployer un dispositif de pare-feu tiers. Le dispositif tiers peut être déployé en tant qu'appareil doté de plusieurs cartes d'interface réseau entre deux VPC de votre réseau Google Cloud ou dans le cloud privé avec une intégration à NSX-T.
Pour une présentation détaillée des architectures VMware Engine avec des dispositifs centralisés, pouvant être utilisés pour divers cas d'utilisation de sécurité avancée, tels que IPS/IDS, DDoS, le déchargement SSL et plus encore, consultez la documentation sur la 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 des 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 du réseau hybrides derrière Traffic Director et d'exploiter l'équilibreur de charge HTTP(S) externe. Ces deux configurations vous permettent d'inclure Google Cloud Armor pour les applications publiques, de réduire les attaques DDoS et les failles courantes telles que les injections SQL ou les scripts intersites.
Si vous avez besoin de fonctionnalités de maillage de services telles que la gestion avancée du trafic à l'aide du proxy Envoy ou l'intégration de Certificate Authority Service, nous vous recommandons d'utiliser Traffic Director. Dans tous les autres cas, nous vous recommandons d'utiliser l'équilibreur de charge HTTP(S) externe.
Suivez la documentation pour savoir comment ajouter des charges de travail VMware Engine aux NEG hybrides dans l'une des configurations suivantes:
- Équilibrage de charge HTTP(S) externe régional avec connectivité hybride
- Équilibreur de charge HTTP(S) externe global avec connectivité hybride
Se connecter aux services Google Cloud en mode privé sans accès à Internet
Les charges de travail du 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 l'accès privé à Google pour accéder aux services Google sans envoyer de trafic sur Internet, car cela réduit les coûts de sortie et la latence. Cela élimine également la nécessité d'un chemin réseau vers Internet pour les charges de travail qui n'ont besoin que d'un accès aux API Google. Découvrez en détail l'accès privé à Google pour obtenir plus d'informations techniques et des étapes de configuration.
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 tel que Cloud SQL ou les instances Memorystore doivent se connecter en mode privé à l'aide d'un message d'intérêt public. Pour en savoir plus à ce sujet, consultez la section sur les messages d'intérêt public 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 une approche multicouche pour le chiffrement en transit entre vos centres de données sur site et Google Cloud. La liaison entre l'infrastructure sur site et Google Cloud peut être chiffrée en configurant Cloud VPN avec un tunnel IPSec ou en utilisant le protocole IPSec natif sur les rattachements de VLAN de l'interconnexion. En outre, le chiffrement de la couche d'application doit être activé entre les composants d'application à l'aide du protocole TLS.
Protégez vos données contre l'exfiltration à l'aide de VPC Service Controls.
Il est recommandé de limiter les risques d'exfiltration de 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 situées à l'intérieur d'un périmètre doivent également être placées dans celui-ci. 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 pouvoir accéder aux ressources protégées par VPC Service Controls.
Vous devez configurer des règles d'entrée et de sortie dans votre configuration VPC Service Controls pour autoriser les API de service du producteur VMware Engine dans le périmètre. Pour obtenir des instructions détaillées sur la configuration, consultez les pages de documentation de 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 au sein de l'environnement VMware Engine et du 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 utilisée de la même manière que les 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 les exemples d'activités qu'ils activent.
| 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 | le déploiement et l'annulation du cloud privé, le déploiement et l'annulation du cluster, par exemple. |
| VMware Engine | vCenter | LDAP | Hôtes et clusters, VM et dossiers, datastores dans l'UI vCenter | Création et suppression d'objets dans un datastore, création de dossiers de VM, etc. |
| NSX-T | LDAP | "Utilisateurs et rôles" dans l'interface utilisateur de NSX-T Manager | Création de segments NSX, configuration d'un pare-feu ou d'un équilibreur de charge, par exemple. | |
| vCenter | Système d'exploitation invité de la VM | Active Directory, LDAP, les utilisateurs locaux, etc. | Système d'exploitation invité | la connexion SSH ou RDP, les opérations sur les fichiers, |
Dans Google Cloud IAM, il existe deux rôles prédéfinis disposant d'autorisations sur le portail VMware Engine:
- Administrateur de services VMware Engine : donne un accès complet au service VMware Engine sur Google Cloud.
- Lecteur de service VMware Engine : donne un accès en lecture seule au service VMware Engine sur Google Cloud.
Ces autorisations concernent les actions effectuées sur le portail VMware Engine et ne concernent pas les actions de l'API ou de 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 fournissent 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 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 projet, seuls les rôles peuvent être attribués au niveau du projet. Si vos clouds privés se trouvent dans des projets distincts en raison d'exigences techniques ou organisationnelles, 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 n'a besoin que de ces environnements n'a pas besoin des rôles IAM précédemment répertoriés. À la place, elles doivent utiliser des identités LDAP dont les autorisations sont configurées dans vCenter et NSX-T. Nous vous recommandons de ne fournir les rôles d'administrateur de services VMware Engine ou de lecteur de services VMware Engine qu'à un nombre très limité d'utilisateurs, car ces rôles accordent l'accès au puissant compte d'utilisateur CloudOwner pour vCenter et au compte d'administrateur pour NSX-T. Ces comptes utilisateur ne doivent être utilisés que pour la configuration initiale ou les procédures de type "bris de glace".
Restreindre et auditer activement l'accès des administrateurs
Le rôle d'administrateur de services 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 leurs 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 souvent et peut avoir un impact important sur la facturation ou la disponibilité du cluster. N'attribuez ce rôle qu'à un nombre limité de personnes dans votre organisation.
Veillez à auditer régulièrement l'attribution du rôle d'administrateur de services VMware Engine, soit directement sur le projet utilisé pour VMware Engine, soit à l'un des niveaux parents de la hiérarchie des ressources. Cet audit doit inclure d'autres rôles, tels que les rôles de base Éditeur et Propriétaire, qui incluent des autorisations critiques liées à VMware Engine. Identifiez les rôles trop privilégiés à l'aide de services tels que l'outil de recommandation de rôles IAM.
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 s'agit d'une pratique recommandée pour centraliser la gestion du cycle de vie des identités, des groupes, des mots de passe, etc. Notez qu'il n'est pas possible de joindre directement vCenter et NSX-T à Active Directory pour l'authentification Windows intégrée.
Alternez 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 des accès dans le cloud privé (tels que vCenter, NSX-T et HCX). Il est recommandé d'établir un processus pour alterner les 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 de type "bris de glace". En outre, leurs mots de passe doivent être alternés régulièrement (par exemple, tous les 60 ou 90 jours). De la même manière, effectuez une rotation régulière des 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 est probable que le mot de passe reste valide lorsqu'un acteur malveillant le trouve.
Journalisation et surveillance VMware Engine
Les sections suivantes présentent les bonnes pratiques de journalisation et de surveillance des charges de travail de VM et de l'infrastructure VMware Engine, qui fournit les ressources utilisées par les charges de travail.
Ingérer les journaux et les métriques VMware Engine
De nombreuses organisations souhaitent collecter et analyser les journaux dans un "volet unique" centralisé. Dans Google Cloud, les produits Cloud Logging et Cloud Monitoring fournissent des services permettant une 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 transfère des métriques telles que l'utilisation du processeur et de la mémoire ESXi à Cloud Monitoring. Nous vous recommandons de créer des tableaux de bord basés sur les métriques transmises par vCenter ou, pour commencer, avec des exemples de tableaux de bord publiés sur GitHub.
Pour collecter des journaux de plate-forme, les clouds privés VMware Engine peuvent transférer les journaux Syslog vers un agrégateur de journaux centralisé. Cela peut être fait pour les messages Syslog vCenter et NSX-T. La collecte, la conservation et l'analyse des messages Syslog provenant de vCenter sont associées à des cas d'utilisation de sécurité importants, tels que les alertes en temps réel basées sur les connexions d'utilisateurs avec accès administrateur (ou d'utilisateur "bris de glace") 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 transmettre les messages à Cloud Logging.
Il est recommandé d'analyser les journaux de VMware Engine dans un tableau de bord central au sein d'un même projet. Si votre environnement VMware Engine couvre plusieurs projets, vous devez également regrouper vos projets en configurant des récepteurs de journaux 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 diffuse les journaux d'applications tierces et de logiciels système courants vers 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 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 exécutées 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 soit pas encore compatible de manière native avec la transparence des accès (AxT) et l'approbation des accès (AxA) dans Google Cloud, nous avons mis en œuvre des processus dotés de fonctionnalités équivalentes, qui peuvent être activés sur demande.
Pour l'équivalence d'Access Transparency, vous devez prendre en compte plusieurs sources de journaux, y compris les suivantes:
- Journaux vCenter : exportables via la configuration du serveur syslog distant.
- Les journaux ESXi : ils peuvent être collectés à l'aide d'une configuration syslog distante. 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 règle afin de fournir des fonctionnalités équivalentes pour l'approbation des accès. Dans cette règle, les opérations de service standards nécessitent la création d'une demande d'assistance en indiquant la raison pour laquelle les opérateurs de service d'accès ont besoin d'un accès.
Les exclusions Google Cloud Access Approval s'appliquent.
Chiffrement VMware Engine
Les sections suivantes présentent les bonnes pratiques de chiffrement du stockage dans le cloud privé, ainsi que les facteurs à prendre en compte lors du choix d'un fournisseur de clés pour votre cloud privé.
Utilisez un fournisseur de clés géré par Google pour lequel le chiffrement vSAN au repos est activé
Le chiffrement des données au repos est implémenté à l'aide du chiffrement logiciel 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 demande aux clients de maintenir le chiffrement vSAN activé sur leurs clusters ESXi. La désactivation du chiffrement vSAN constitue une violation des conditions de service de VMware Engine. De nombreuses organisations exigent le chiffrement au repos dans le cadre de leurs politiques ou sont tenues par des réglementations de chiffrer leurs données (par exemple, le NIST ou le FIPS).
Chaque hôte ESXi chiffre les données à l'aide du mode XTS AES-256 standard à l'aide de clés de chiffrement de données (DEK, Data Encryption Keys) générées aléatoirement. 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 KEK, mais pas la KEK elle-même, qui est stockée dans un service Cloud Key Management Service (KMS). Vous pouvez choisir l'emplacement de Cloud KMS dans lequel votre KEK est conservée.
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 service Cloud KMS, vous pouvez utiliser un service Cloud KMS tiers compatible avec la norme KMIP 1.1, proposé par l'un des fournisseurs acceptés. 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ées par Google |
|
|
| Fournisseur de clés Cloud KMS tiers |
|
|
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 approche de zéro pour les VM chiffrées.
Automatisez la rotation des clés de chiffrement selon les normes de votre organisation
Vous êtes responsable de la rotation des clés KEK à l'aide de la fonctionnalité fournie par VMware Engine vSphere. Cela est le cas aussi bien avec le fournisseur de clés par défaut qu'avec un service Cloud KMS externe. La rotation de la KEK peut être lancée à partir de vCenter ou à l'aide de son API. Envisagez d'automatiser la rotation des 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 stratégiques reposent sur une disponibilité virtuelle permanente de vos données, ce qui vous laisse peu de temps pour récupérer les données 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 garantir la sécurité et la disponibilité de vos données. Elle contient toutefois des éléments clés à prendre en compte pour choisir la stratégie adaptée à votre environnement VMware Engine.
Sauvegarder vos charges de travail à l'aide du service de sauvegarde et de reprise après sinistre
Avec le service de sauvegarde et de reprise après sinistre, Google Cloud propose une solution de sauvegarde native gérée de manière centralisée, qui peut être utilisée pour divers cas d'utilisation, y compris la sauvegarde de 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'un large éventail de charges de travail, des sauvegardes incrémentielles et économes en espace, ainsi que des options de stockage flexibles.
Google Cloud VMware Engine est également compatible avec l'utilisation de solutions de sauvegarde tierces basées sur un agent. Vous pouvez les utiliser si vous possédez déjà des licences pour un produit de sauvegarde tiers. Voici les conditions préalables à l'utilisation de ce type d'outils:
- Elles fournissent des sauvegardes au niveau de l'application.
- Ils sont certifiés par les fournisseurs d'applications
- Ils sont certifiés par VMware Engine pour vSAN
- Ils sont compatibles avec la norme de protocole VADP (VMware Engine vStorage API for Data Protection) ou effectuent des sauvegardes au niveau de l'application.
Quelle que soit la solution de sauvegarde de votre choix, nous vous recommandons d'utiliser Cloud Storage comme solution de stockage économique pour la conservation à long terme des sauvegardes. Cloud Storage est un stockage d'objets hautement 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 économique et des RPO 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 des sauvegardes 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 est possible que les tailles de clusters VMware Engine soient liées au stockage.
Implémenter la reprise après sinistre avec le service de sauvegarde et de reprise après sinistre
Nous vous recommandons de restaurer des applications sur VMware Engine à l'aide du service de sauvegarde et de reprise après sinistre. Pour protéger vos charges de travail de production des pannes d'une zone unique au sein d'une région, il est recommandé 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.
Outre la sauvegarde et la reprise après sinistre Google Cloud, 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 RPO cibles inférieurs. Si votre RPO cible est exprimé en minutes plutôt qu'en heures, envisagez des solutions de reprise après sinistre basées sur la réplication vSphere.
Checklist
La checklist suivante récapitule les bonnes pratiques de sécurité concernant l'utilisation de VMware Engine.
Étapes suivantes
- Essayez Google Cloud VMware Engine. 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.