Bonnes pratiques pour la sécurité de 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 découvrir les conditions préalables et la sécurité de VMware Engine.
VMware Engine dispose d'un modèle de responsabilité partagée pour la sécurité. Une sécurité fiable dans le cloud est assurée grâce aux responsabilités partagées des clients et de 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 pour la mise en réseau dans un environnement VMware Engine.
Identifier et comprendre tous les flux de trafic de votre environnement
VMware Engine utilise les réseaux VMware Engine et le peering VPC pour établir une connexion réseau privée entre un réseau de cloud privé VMware Engine et votre réseau VPC. Le trafic entrant provenant d'un VPC dans votre environnementGoogle Cloud ou d'un réseau sur site transite par un réseau d'unité locative géré par Google.
Utiliser le service d'adresse IP publique de VMware Engine pour le transfert de données sur Internet
Le trafic Internet peut accéder directement à 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 n'importe quel autre trafic entrant. 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, l'IPS/IDS ou l'inspection du trafic fournis par une instance ou un service central dans votre environnement Google Cloud , vous devez acheminer le trafic destiné à Internet via le réseau VPC.
Si cela ne s'applique pas à votre cas ou si vous avez implémenté les contrôles dans votre cloud privé, nous vous recommandons d'inclure le service d'adresse IP externe dans VMware Engine. De plus, nous vous recommandons d'utiliser des règles d'accès externe pour refuser les schémas de trafic provenant d'Internet qui ne s'appliquent pas à vos applications.
Règles de pare-feu nord-sud et est-ouest distinctes sur le pare-feu de passerelle et le pare-feu distribué dans VMware Engine NSX
Configurez le pare-feu distribué (DFW) dans NSX sur le routeur logique de niveau 1 pour segmenter le trafic interne entre vos domaines virtuels de niveau 2. Le DFW NSX est conçu pour gérer le trafic réseau (interne) est-ouest 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 des accès réseau, assurez-vous d'appliquer une règle par défaut restrictive au 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 entre les services de votre application.
Configurez le pare-feu de passerelle NSX pour contrôler le trafic nord-sud qui entre dans le cloud privé et en sort.
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 individuel, configurez le pare-feu de passerelle sur le routeur de niveau 1.
En plus des pare-feu NSX, nous vous recommandons d'utiliser le pare-feu VPC pour autoriser et bloquer le trafic est-ouest entre les charges de travail dans le cloud privé VMware Engine et les charges de travail dans les 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 le trafic ne doit être ouvert que de manière consciente.
Le transfert de données sortantes vers les appliances de gestion ainsi que vers la plage CIDR vSphere/vSAN doit également être bloqué à partir des VPC à l'aide du pare-feu VPC. N'autorisez le transfert de données sortantes vers les appliances de gestion qu'à partir d'hôtes et d'adresses IP fiables de votre réseau. Il est important de noter que les appliances de gestion ne se trouvent pas dans un segment NSX. 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
Utilisez le NSX DFW pour implémenter des contrôles du trafic pour les segments de sécurité aussi précis que les machines virtuelles individuelles. Ce principe de protection du trafic entre les VM individuelles, qui est refusé par défaut, est souvent appelé microsegmentation. Il s'agit d'une approche plus précise pour la mise en place de pare-feu que l'implémentation conventionnelle de 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 qui se trouvent dans le même segment NSX ou dans des segments NSX distincts. Les règles de pare-feu permettant d'autoriser le trafic vers et depuis les VM peuvent être définies en organisant les VM dans des groupes de règles, qui peuvent avoir des critères d'appartenance flexibles tels que la correspondance des tags ou des noms 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é dans lequel tous les flux réseau sont contrôlés par des processus de validation de l'identité et de l'appareil plutôt que par une confiance implicite est souvent 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 des fonctionnalités IDS/IPS pour le trafic entrant dans le cloud privé depuis le reste de votre réseau ou entre vos segments de réseau NSX, envisagez de déployer un pare-feu tiers. Le dispositif tiers peut être déployé en tant que dispositif multi-NIC entre deux VPC de votre réseau Google Cloud ou dans le cloud privé avec une intégration à NSX.
Pour en savoir plus sur les architectures VMware Engine avec des appliances centralisées, qui peuvent être utilisées pour divers cas d'utilisation de sécurité avancée, tels que l'IPS/IDS, le DDoS, le déchargement SSL et plus encore, consultez le document sur la sécurité du réseau à l'aide d'appliances centralisées 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 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 Service Mesh telles que la gestion avancée du trafic à l'aide du proxy Envoy ou l'intégration de Certificate Authority Service, nous vous recommandons Cloud Service Mesh. Dans tous les autres cas, nous vous recommandons d'utiliser l'équilibreur de charge HTTP(S) externe.
Suivez la documentation sur l'ajout de 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 de manière privée sans accès à Internet
Les charges de travail des clouds privés 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 et la latence liés au transfert de données sortantes. 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 l'accès privé à Google, y compris sur les détails techniques et les étapes de configuration, consultez l'article détaillé.
De même, les charges de travail VMware Engine qui doivent accéder aux ressourcesGoogle Cloud d'un réseau de producteurs de services, telles que les instances Cloud SQL ou Memorystore, doivent se connecter de manière privée à l'aide de l'accès aux services privés. Pour en savoir plus, consultez la section sur les PSA pour VMware Engine.
Chiffrez 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'adopter une approche multicouche pour le chiffrement en transit entre vos centres de données sur site etGoogle Cloud. La liaison entre les systèmes sur site et Google Cloudpeut être chiffrée en configurant Cloud VPN avec un tunnel IPsec ou en utilisant l'IPsec intégré aux rattachements de VLAN de l'interconnexion. De plus, le chiffrement de la couche application doit être activé entre les composants de l'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 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 à l'intérieur d'un périmètre doivent également être placées dans le 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 producteur 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 dans 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 utilisée de la même manière que 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 concernés, 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 | Par exemple, le déploiement et l'annulation d'un cloud privé ou d'un cluster. |
| VMware Engine | vCenter | LDAP | Hôtes et clusters, VM et dossiers, datastores dans l'interface utilisateur vCenter | Création de VM, de dossiers de VM, d'objets de datastore et suppression de ces éléments, par exemple |
| NSX | LDAP | "Utilisateurs et rôles" dans l'interface utilisateur NSX Manager | Par exemple, la création de segments NSX, la configuration du pare-feu et la configuration de l'équilibreur de charge. | |
| 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 sur les fichiers, par exemple |
Dans Google Cloud IAM, il existe deux rôles prédéfinis avec des autorisations pour le portail VMware Engine :
- Administrateur du service VMware Engine : donne un accès complet au service VMware Engine sur Google Cloud.
- Lecteur du 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 non celles effectuées 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 général, nous vous recommandons 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 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, nous vous recommandons 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, les rôles ne peuvent être attribués qu'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 ou HCX. Le personnel qui n'a besoin que d'exploiter 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. Nous vous recommandons d'attribuer les rôles "Administrateur du service VMware Engine" ou "Lecteur du service VMware Engine" à un nombre très limité d'utilisateurs, car ces rôles donnent accès au puissant compte utilisateur CloudOwner pour vCenter et au compte utilisateur administrateur pour NSX. Ces comptes utilisateur ne doivent être utilisés que pour la configuration initiale ou les procédures d'urgence.
Restreindre et auditer activement l'accès administrateur
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 ses clusters. En règle générale, l'ajout ou la suppression manuels de clusters et de nœuds sont des actions qui ne se produisent pas fréquemment et qui peuvent 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 à vérifier régulièrement qui s'est vu attribuer le rôle Administrateur de services VMware Engine, soit directement dans 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, comme les rôles de base Éditeur et Propriétaire, 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 qui présentent trop de privilèges.
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 permettre 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 que l'association directe de vCenter et NSX à 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 dans le cloud privé (tels que vCenter, NSX et HCX). Nous vous recommandons d'établir une procédure 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 par défaut. Les deux comptes utilisateur ne doivent être utilisés que pour la configuration initiale et les procédures d'urgence. 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 solution qui sont couramment utilisés pour l'intégration d'outils tiers. Plus vous alternez souvent les mots de passe du compte de service, moins il y a de risques que le mot de passe soit toujours valide lorsqu'un acteur malintentionné le trouve.
Journalisation et surveillance de VMware Engine
Les sections suivantes présentent les bonnes pratiques pour la journalisation et la surveillance des charges de travail de 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 organisations 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. Nous vous recommandons de créer des tableaux de bord basés sur les métriques transférées par vCenter, ou de commencer avec des exemples de tableaux de bord publiés sur GitHub.
Pour collecter les 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 à la fois pour les messages syslog vCenter et NSX. La collecte, la conservation et l'analyse des messages Syslog de vCenter présentent d'importants cas d'utilisation liés à la sécurité, comme les alertes en temps réel basées sur les connexions des utilisateurs administratifs (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.
Nous vous recommandons d'analyser les journaux de VMware Engine dans un tableau de bord centralisé d'un seul projet. Si votre environnement VMware Engine s'étend sur plusieurs projets, vous devez également les agréger en configurant des collecteurs de journaux et des périmètres 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. Nous vous recommandons 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 les fonctionnalités équivalentes des règles Access Transparency et Access Approval
Bien que VMware Engine ne soit pas compatible avec Access Transparency (AxT) ni avec l'approbation de l'accès (AxA) dans Google Cloud, nous avons mis en place des processus offrant des fonctionnalités équivalentes qui peuvent être activées sur demande.
Pour l'équivalence Access Transparency, vous devez tenir compte de plusieurs sources de journaux, y compris :
- Journaux vCenter : exportables à l'aide de la configuration du serveur syslog distant.
- Journaux ESXi : vous pouvez les collecter à 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 mettons en place une règle pour fournir des fonctionnalités équivalentes pour l'approbation de l'accès. Dans ce règlement, les opérations de service standards nécessitent la création d'une demande d'assistance indiquant la raison pour laquelle les opérateurs de service ont besoin d'accéder au service.
Des exclusions s'appliquent à Access Approval.Google Cloud
Chiffrement VMware Engine
Les sections suivantes présentent les bonnes pratiques pour le 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 Google-owned and managed key activé pour le chiffrement vSAN au repos.
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 exige que les clients maintiennent le chiffrement vSAN activé sur leurs clusters ESXi. La désactivation du chiffrement vSAN constitue une violation des conditions d'utilisation de VMware Engine. De nombreuses organisations exigent le chiffrement au repos dans 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 AES-256 XTS standard avec différentes clés de chiffrement des données (DEK) 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é 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 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 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 Google-owned and managed key par défaut |
|
|
| Fournisseur tiers de clés Cloud KMS |
|
|
Notez que nous vous déconseillons d'activer le chiffrement au niveau de la VM en même temps que le chiffrement du datastore vSAN, car l'efficacité de la déduplication approche de zéro pour les VM chiffrées.
Automatiser la rotation des clés de chiffrement selon les normes de votre organisation
Vous êtes responsable de la rotation de la KEK à l'aide de VMware Engine vSphere. Cela vaut aussi bien pour le fournisseur de clés par défaut que pour un service Cloud KMS externe. La rotation des clés KEK peut être lancée depuis 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 de 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 dépendent de la disponibilité de vos données pratiquement à tout moment, ce qui vous laisse peu de temps pour récupérer les données en cas de panne soudaine. Cette section ne couvre pas tous les aspects de la sauvegarde et de la reprise après sinistre qui sont pertinents pour concevoir efficacement une stratégie de sauvegarde et de reprise après sinistre afin de protéger vos données et de les rendre disponibles. Elle contient toutefois des éléments 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
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 charges de travail compatibles, des sauvegardes incrémentielles permanentes peu gourmandes en espace et des options de stockage flexibles.
Google Cloud VMware Engine est également compatible avec les 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 sont les suivants :
- Elles fournissent des sauvegardes au niveau de l'application.
- Ils sont certifiés par les fournisseurs d'applications.
- Elles sont certifiées par VMware Engine pour vSAN.
- Elles 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 service 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 é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 minimiser le RPO. Utilisez cette option de stockage si un coût plus élevé pour le stockage des sauvegardes est acceptable et si 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 la taille des clusters VMware Engine soit limitée par le 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 prend généralement en charge des objectifs de RPO plus faibles. 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é à appliquer pour utiliser VMware Engine.
Étapes suivantes
- Testez Google Cloud VMware Engine. Pour en savoir plus, consultez Fonctionnalités, avantages et cas d'utilisation.
- En savoir plus sur 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 Cloud Architecture Center.