Dans le cadre de la stratégie de défense en profondeur de votre organisation, vous pouvez avoir des règles de sécurité qui nécessitent l'utilisation de dispositifs réseau centralisés pour la détection intégrée et le blocage des activité suspectes. Ce document vous permet de concevoir les fonctionnalités avancées de protection réseau suivantes pour les charges de travail Google Cloud VMware Engine :
- Atténuation des attaques par déni de service distribué (DDoS)
- Déchargement SSL
- Pare-feu nouvelle génération (NGFW)
- Système de prévention des intrusions (IPS) et système de détection des intrusions (IDS)
- Inspection approfondie des paquets (DPI)
Les architectures décrites dans ce document utilisent Cloud Load Balancing et les dispositifs réseau de Google Cloud Marketplace. Cloud Marketplace propose, par le biais des partenaires sécurité Google Cloud, des dispositifs réseau prêts à l'emploi et dont la compatibilité est assurée par le fournisseur, pour répondre aux besoins informatiques de votre entreprise.
Ce document est destiné aux architectes de sécurité et aux administrateurs réseau qui conçoivent, provisionnent et gèrent la connectivité réseau des charges de travail VMware Engine. Dans ce document, nous partons du principe que vous connaissez le cloud privé virtuel (VPC), VMware vSphere, VMware NSX, la traduction d'adresses réseau (NAT) et Cloud Load Balancing.
Architecture
Le schéma suivant illustre une architecture de connectivité réseau aux charges de travail VMware Engine à partir de réseaux sur site et depuis Internet. Plus loin dans ce document, cette architecture est étendue pour répondre aux exigences de cas d'utilisation spécifiques.
La figure 1 illustre les principaux composants suivants de l'architecture :
- Cloud privé VMware Engine : pile VMware isolée constituée de machines virtuelles (VM), d'espace de stockage, de l'infrastructure de mise en réseau et d'un serveur VMware vCenter. VMware NSX-T fournit des fonctionnalités de mise en réseau et de sécurité telles que la microsegmentation et les règles de pare-feu. Les VM VMware Engine utilisent des adresses IP provenant de segments de réseau que vous créez dans votre cloud privé.
- Service d'adresse IP publique : fournit des adresses IP externes aux VM VMware Engine pour permettre l'accès en entrée à partir d'Internet. La passerelle Internet fournit un accès en sortie par défaut pour les VM VMware Engine.
- Réseau VPC locataire VMware Engine : réseau VPC dédié et géré par Google, utilisé avec chaque cloud privé VMware Engine pour permettre la communication avec les services Google Cloud.
Réseaux VPC client :
- Réseau VPC client 1 (externe) : réseau VPC qui héberge l'interface publique de votre dispositif réseau et de votre équilibreur de charge.
- Réseau VPC client 2 (interne) : réseau VPC qui héberge l'interface interne du dispositif réseau et est appairé au réseau VPC locataire VMware Engine à l'aide du modèle accès aux services privés.
Accès privé aux services : modèle d'accès privé qui utilise l'appairage de réseaux VPC pour permettre la connectivité entre les services gérés par Google et vos réseaux VPC.
Dispositifs réseau : logiciels de mise en réseau que vous choisissez depuis Cloud Marketplace et déployez sur des instances Compute Engine.
Cloud Load Balancing : service géré par Google que vous pouvez utiliser pour gérer le trafic vers des charges de travail distribuées à disponibilité élevée dans Google Cloud. Vous pouvez choisir le type d'équilibreur de charge qui convient à votre protocole de trafic et à vos exigences d'accès. Les architectures décrites dans ce document n'utilisent pas les équilibreurs de charge NSX-T intégrés.
Remarques concernant la configuration
Le schéma suivant présente les ressources requises pour fournir la connectivité réseau pour les charges de travail VMware Engine :
La figure 2 montre les tâches que vous devez effectuer pour configurer les ressources de cette architecture. Voici une description de chaque tâche, y compris un lien vers un document fournissant plus d'informations et des instructions détaillées.
Créez les réseaux et sous-réseaux VPC externes et internes en suivant les instructions de la section Créer un réseau VPC en mode personnalisé.
- Pour chaque sous-réseau, choisissez une plage d'adresses IP unique parmi les réseaux VPC.
- Le réseau VPC de gestion illustré dans le schéma d'architecture est facultatif. Si nécessaire, vous pouvez l'utiliser pour héberger des interfaces NIC pour la gestion de vos dispositifs réseau.
Déployez les dispositifs réseau requis à partir de Cloud Marketplace.
Pour assurer la haute disponibilité des dispositifs réseau, déployez chacun d'entre eux dans une paire de VM réparties sur deux zones.
Vous pouvez déployer les dispositifs réseau dans des groupes d'instances. Les groupes d'instances peuvent être des groupes d'instances gérés ou des groupes d'instances non gérés, en fonction de vos exigences en matière de gestion ou d'assistance des fournisseurs.
Provisionnez les interfaces réseau comme suit :
nic0dans le réseau VPC externe pour acheminer le trafic vers la source publique.nic1pour les opérations de gestion, si le fournisseur du dispositif l'exige.nic2dans le réseau VPC interne pour la communication interne avec les ressources VMware Engine.
Le déploiement des interfaces réseau sur des réseaux VPC distincts vous permet d'assurer la séparation entre zones de sécurité au niveau de l'interface pour les connexions publiques et sur site.
Pour configurer VMware Engine :
- Créez un cloud privé VMware Engine.
- Créez un segment de réseau pour les VM VMware Engine.
Utilisez l'accès privé aux services pour configurer l'appairage de réseaux VPC afin de connecter le réseau VPC interne au réseau VPC géré par VMware Engine.
Si vous avez besoin d'une connectivité hybride à votre réseau sur site, utilisez Cloud VPN ou Cloud Interconnect.
Vous pouvez étendre l'architecture de la figure 2 dans les cas d'utilisation suivants :
| Cas d'utilisation | Produits et services utilisés |
|---|---|
| NGFW pour les charges de travail VMware Engine publiques |
|
| Atténuation des attaques NGFW, DDoS, déchargement SSL et réseau de diffusion de contenu (CDN) pour les charges de travail publiques VMware Engine |
|
| NGFW pour la communication privée entre les charges de travail VMware Engine et les centres de données sur site ou d'autres fournisseurs cloud |
|
| Points de sortie centralisés vers Internet pour les charges de travail VMware Engine |
|
Les sections suivantes décrivent ces cas d'utilisation et présentent les tâches de configuration permettant de les implémenter.
NGFW pour les charges de travail publiques
Ce cas d'utilisation présente les exigences suivantes :
- Une architecture hybride composée d'instances VMware Engine et Compute Engine, avec un équilibreur de charge L4 comme interface commune.
- Protection des charges de travail publiques VMware Engine à l'aide d'une solution IPS/IDS, NGFW, DPI ou NAT.
- Un nombre d'adresses IP publiques supérieur à celui accepté par le service d'adresse IP publique de VMware Engine.
Le schéma suivant illustre les ressources requises pour provisionner un NGFW pour vos charges de travail publiques VMware Engine :
La figure 3 montre les tâches que vous devez effectuer pour configurer les ressources de cette architecture. Voici une description de chaque tâche, y compris un lien vers un document fournissant plus d'informations et des instructions détaillées.
Provisionnez un équilibreur de charge réseau passthrough externe dans le réseau VPC externe en tant que point d'entrée public pour les charges de travail VMware Engine.
- Créez plusieurs règles de transfert pour prendre en charge plusieurs charges de travail VMware Engine.
- Configurez chaque règle de transfert avec une adresse IP unique et un numéro de port TCP ou UDP.
- Configurez les dispositifs réseau en tant que backends pour l'équilibreur de charge.
Configurez les dispositifs réseau pour qu'ils effectuent une traduction NAT de destination (DNAT) pour l'adresse IP publique de la règle de transfert vers les adresses IP internes des VM hébergeant les applications publiques dans VMware Engine.
- Les dispositifs réseau doivent effectuer une traduction NAT source (SNAT) pour le trafic provenant de l'interface
nic2afin de garantir un chemin renvoyé symétrique. - Les dispositifs réseau doivent également acheminer le trafic destiné aux réseaux VMware Engine via l'interface
nic2vers la passerelle du sous-réseau (la première adresse IP du sous-réseau). - Pour que les vérifications d'état réussissent, les dispositifs réseau doivent utiliser des interfaces secondaires ou de rebouclage pour répondre aux adresses IP des règles de transfert.
- Les dispositifs réseau doivent effectuer une traduction NAT source (SNAT) pour le trafic provenant de l'interface
Configurez la table de routage du réseau VPC interne pour transférer le trafic VMware Engine vers l'appairage de réseaux VPC en tant que saut suivant.
Dans cette configuration, les VM VMware Engine utilisent le service de passerelle Internet de VMware Engine pour générer des sorties vers des ressources Internet. Cependant, l'entrée est gérée par les dispositifs réseau pour les adresses IP publiques mappées sur les VM.
NGFW, atténuation des attaques DDoS, déchargement SSL et CDN
Ce cas d'utilisation présente les exigences suivantes :
- Une architecture hybride composée d'instances VMware Engine et Compute Engine, avec un équilibreur de charge L7 en tant qu'interface commune et un mappage d'URL pour acheminer le trafic vers le backend approprié.
- Protection des charges de travail publiques VMware Engine à l'aide d'une solution IPS/IDS, NGFW, DPI ou NAT.
- Atténuation des attaques DDoS L3-L7 pour les charges de travail publiques VMware Engine à l'aide de Google Cloud Armor.
- Terminaison SSL à l'aide de certificats SSL gérés par Google ou de règles SSL pour contrôler les versions SSL et les algorithmes de chiffrement utilisés pour HTTPS ou des connexions SSL à des charges de travail publiques VMware Engine.
- Diffusion réseau accélérée pour les charges de travail VMware Engine en utilisant Cloud CDN pour diffuser du contenu provenant d'emplacements proches des utilisateurs.
Le schéma suivant présente les ressources requises pour provisionner la fonctionnalité NGFW, l'atténuation des attaques DDoS, le déchargement SSL et le CDN pour vos charges de travail publiques VMware Engine :
La figure 4 montre les tâches que vous devez effectuer pour configurer les ressources de cette architecture. Voici une description de chaque tâche, y compris un lien vers un document fournissant plus d'informations et des instructions détaillées.
Provisionnez un équilibreur de charge d'application externe global dans le réseau VPC externe en tant que point d'entrée public pour les charges de travail VMware Engine.
- Créez plusieurs règles de transfert pour prendre en charge plusieurs charges de travail VMware Engine.
- Configurez chaque règle de transfert avec une adresse IP publique unique, et configurez-la pour écouter le trafic HTTP(S).
- Configurez les dispositifs réseau en tant que backends pour l'équilibreur de charge.
En outre, vous pouvez effectuer les opérations suivantes :
- Pour protéger les dispositifs réseau, configurez des règles de sécurité Google Cloud Armor sur l'équilibreur de charge.
- Pour permettre le routage, la vérification d'état et l'adresse IP Anycast pour les dispositifs réseau qui agissent en tant que backends CDN, configurez Cloud CDN pour les MIG qui hébergent les dispositifs réseau.
- Pour acheminer les requêtes vers différents backends, configurez le mappage d'URL sur l'équilibreur de charge. Par exemple, acheminez les requêtes à
/apivers les VM Compute Engine, les requêtes à/imagesvers un bucket Cloud Storage et les requêtes à/appvia les dispositifs réseau vers vos VM VMware Engine.
Configurer chaque dispositif réseau pour qu'il effectue la traduction NAT de destination (DNAT) pour l'adresse IP interne de son interface
nic0vers les adresses IP internes des VM hébergeant les applications publiques dans VMware Engine.- Les dispositifs réseau doivent exécuter la SNAT pour le trafic source depuis l'interface
nic2(adresse IP interne) pour garantir un chemin symétrique renvoyé. - En outre, les dispositifs réseau doivent acheminer le trafic destiné aux réseaux VMware Engine via l'interface
nic2vers la passerelle de sous-réseau (la première adresse IP du sous-réseau).
L'étape DNAT est nécessaire, car l'équilibreur de charge est un service basé sur un proxy qui est implémenté sur un service Google Front End (GFE). Selon l'emplacement de vos clients, plusieurs GFE peuvent initier des connexions HTTP(S) aux adresses IP internes des dispositifs de réseau backend. Les paquets des GFE ont des adresses IP sources de la même plage que celle utilisée pour les vérifications d'état (35.191.0.0/16 et 130.211.0.0/22), et non les adresses IP clientes d'origine. L'équilibreur de charge ajoute les adresses IP clientes à l'aide de l'en-tête
X-Forwarded-For.Pour que les vérifications d'état réussissent, configurez les dispositifs réseau afin qu'ils répondent à l'adresse IP de la règle de transfert à l'aide d'interfaces secondaires ou de rebouclage.
- Les dispositifs réseau doivent exécuter la SNAT pour le trafic source depuis l'interface
Configurez la table de routage du réseau VPC interne pour transférer le trafic VMware Engine vers l'appairage de réseaux VPC.
Dans cette configuration, les VM VMware Engine utilisent le service de passerelle Internet de VMware Engine pour la sortie vers Internet. Cependant, l'entrée est gérée par les dispositifs réseau pour les adresses IP publiques des VM.
NGFW pour la connectivité privée
Ce cas d'utilisation présente les exigences suivantes :
- Une architecture hybride composée d'instances VMware Engine et Compute Engine, avec un équilibreur de charge L4 comme interface commune.
- Protection de vos charges de travail privées VMware Engine à l'aide d'une solution IPS/IDS, NGFW, DPI ou NAT.
- Cloud Interconnect ou Cloud VPN pour la connectivité avec le réseau sur site.
Le schéma suivant présente les ressources requises pour provisionner un NGFW pour la connectivité privée entre vos charges de travail VMware Engine et les réseaux sur site ou d'autres fournisseurs cloud :
La figure 5 montre les tâches que vous devez effectuer pour configurer les ressources de cette architecture. Voici une description de chaque tâche, y compris un lien vers un document fournissant plus d'informations et des instructions détaillées.
Provisionnez un équilibreur de charge réseau passthrough interne dans le réseau VPC externe, avec une seule règle de transfert paramétrée pour écouter tout le trafic. Configurez les dispositifs réseau en tant que backends pour l'équilibreur de charge.
Configurez la table de routage du réseau VPC externe de sorte qu'elle pointe vers la règle de transfert en tant que prochain saut pour le trafic destiné aux réseaux VMware Engine.
Configurez les dispositifs réseau comme suit :
- Acheminez le trafic destiné aux réseaux VMware Engine via l'interface
nic2vers la passerelle de sous-réseau (la première adresse IP du sous-réseau). - Pour que les vérifications d'état réussissent, configurez les dispositifs réseau afin qu'ils répondent à l'adresse IP de la règle de transfert à l'aide d'interfaces secondaires ou de rebouclage.
- Pour que les vérifications d'état réussissent pour les équilibreurs de charge internes, configurez plusieurs domaines de routage virtuel afin de garantir un routage approprié. Cette étape est nécessaire pour permettre à l'interface
nic2de renvoyer le trafic de vérification d'état provenant des plages publiques (35.191.0.0/16 et 130.211.0.0/22), tandis que la route par défaut des dispositifs réseau pointe vers l'interfacenic0. Pour plus d'informations sur les plages d'adresses IP des vérifications d'état de l'équilibreur de charge, consultez la section Plages d'adresses IP de vérification et règles de pare-feu.
- Acheminez le trafic destiné aux réseaux VMware Engine via l'interface
Configurez la table de routage du réseau VPC interne pour transférer le trafic VMware Engine vers l'appairage de réseaux VPC en tant que saut suivant.
Pour le trafic renvoyé ou pour le trafic provenant de VMware Engine vers des réseaux distants, configurez l'équilibreur de charge réseau passthrough interne en tant que saut suivant annoncé via l'appairage de réseaux VPC vers le réseau VPC d'accès aux services privés.
Sortie centralisée vers Internet
Ce cas d'utilisation présente les exigences suivantes :
- Filtrage d'URL, journalisation et application du trafic centralisés pour la sortie Internet.
- Protection personnalisée des charges de travail VMware Engine à l'aide des dispositifs réseau de Cloud Marketplace
Le schéma suivant illustre les ressources requises pour provisionner des points de sortie centralisés depuis les charges de travail VMware Engine vers Internet :
La figure 6 montre les tâches que vous devez effectuer pour configurer les ressources de cette architecture. Voici une description de chaque tâche, y compris un lien vers un document fournissant plus d'informations et des instructions détaillées.
Provisionnez un équilibreur de charge réseau passthrough interne dans le réseau VPC interne comme point d'entrée de sortie pour les charges de travail VMware Engine.
- Créez une seule règle de transfert pour écouter tout le trafic.
- Configurez les dispositifs réseau en tant que backends pour l'équilibreur de charge.
Configurez les dispositifs réseau pour qu'ils agissent sur le trafic SNAT à partir de leurs adresses IP publiques (
nic0). Pour que les vérifications d'état réussissent, les dispositifs réseau doivent répondre à l'adresse IP de la règle de transfert à l'aide d'interfaces secondaires ou de rebouclage.Configurez le réseau VPC interne pour annoncer une route par défaut via l'appairage de réseaux VPC vers le réseau VPC d'accès privé aux services, avec la règle de transfert de l'équilibreur de charge interne comme prochain saut.
Pour autoriser le trafic sortant via les dispositifs réseau au lieu de la passerelle Internet, suivez la même procédure que pour activer le routage du trafic Internet via une connexion sur site.
Étapes suivantes
- En savoir plus sur VMware Engine.
- Consultez les bonnes pratiques relatives de conception des réseaux VPC.
- En savoir plus sur la mise en réseau dans VMware Engine.
- En savoir plus sur Cloud Load Balancing.
- Parcourir Cloud Marketplace.