Le modèle maillé repose sur l'établissement d'une architecture de réseau hybride. Cette architecture couvre plusieurs environnements informatiques. Dans ces environnements, tous les systèmes peuvent communiquer entre eux et ne sont pas limités à une communication à sens unique en fonction des exigences de sécurité de vos applications. Ce modèle de mise en réseau s'applique principalement aux hybrides hiérarchisés, au multicloud partitionné ou Architectures d'utilisation intensive. Il s'applique également à la conception de la continuité des activités pour provisionner un environnement de reprise après sinistre (DR) dans Google Cloud. Dans tous les cas, vous devez connecter les environnements informatiques de manière à respecter les exigences de communication suivantes:
- Les charges de travail peuvent communiquer entre elles au-delà des limites de leur environnement à l'aide d'adresses IP privées RFC 1918.
- La communication peut être initiée de chaque côté. Les spécificités du modèle de communication peuvent varier en fonction des applications et des exigences de sécurité, telles que les modèles de communication décrits dans les options de conception suivantes.
- Les règles de pare-feu que vous utilisez doivent autoriser le trafic entre des sources et des destinations d'adresses IP spécifiques en fonction des exigences de l'application ou des applications pour lesquelles le modèle est conçu. Idéalement, vous pouvez utiliser une approche de sécurité à plusieurs niveaux pour limiter les flux de trafic de manière précise, à la fois entre les environnements informatiques et à l'intérieur de ceux-ci.
Architecture
Le schéma suivant illustre une architecture de référence de haut niveau du modèle maillé.
- Tous les environnements doivent utiliser un espace d'adressage IP RFC 1918 sans chevauchement.
- Du côté de Google Cloud, vous pouvez déployer des charges de travail dans un ou plusieurs VPC partagés ou non partagés. Pour connaître les autres options de conception possibles de ce modèle, reportez-vous aux variantes de conception suivantes. La structure sélectionnée de vos VPC doit s'aligner sur les projets et la conception de la hiérarchie des ressources de votre organisation.
- Le réseau VPC de Google Cloud s'étend à d'autres environnements informatiques. Ces environnements peuvent se trouver sur site ou dans un autre cloud. Utilisez l'une des options de connectivité réseau hybride et multicloud qui répondent aux exigences de votre entreprise et de votre application.
Limitez les communications aux adresses IP autorisées de vos sources et destinations. Utilisez l'une des fonctionnalités suivantes, ou une combinaison de celles-ci :
Dispositif virtuel de réseau (NVA) doté de fonctionnalités d'inspection de pare-feu nouvelle génération (NGFW), placés dans le chemin d'accès réseau.
Cloud Next Generation Firewall Enterprise avec service de prévention des intrusions (IPS) pour implémenter l'inspection approfondie des paquets afin de prévenir les menaces sans modifier la conception ou l'acheminement du réseau.
Variantes
Le modèle d'architecture maillé peut être combiné à d'autres approches pour répondre à différentes exigences de conception, tout en tenant compte des exigences de communication du modèle. Les options de modèle sont décrites dans les sections suivantes :
- Un VPC par environnement
- Utiliser un pare-feu centralisé de couche application
- Architecture distribuée zéro confiance pour les microservices
Un VPC par environnement
Voici les principales raisons d'envisager l'option d'un VPC par environnement :
- L'environnement cloud nécessite une séparation des réseaux et des ressources VPC au niveau du réseau, conformément à la conception de la hiérarchie des ressources de votre organisation.
Si la séparation de domaine administratif est requise, elle peut également être combinée avec un projet distinct par environnement.
- Pour gérer de manière centralisée les ressources réseau d'un réseau commun et assurer une isolation réseau entre les différents environnements, utilisez un VPC partagé pour chaque environnement de Google Cloud, tel que développement, test et production.
- Exigences de scaling pouvant nécessiter de dépasser les quotas VPC pour un seul VPC ou projet.
Comme illustré dans le schéma suivant, la conception d'un VPC par environnement permet à chaque VPC de s'intégrer directement à l'environnement sur site ou à d'autres environnements cloud à l'aide de VPN, ou à une interconnexion Cloud Interconnect avec plusieurs Rattachements de VLAN.
Le modèle affiché dans le schéma précédent peut être appliqué à une topologie de réseau hub-and-spoke de zone de destination. Dans cette topologie, une (ou plusieurs) connexion hybride peut être partagée avec tous les VPC spoke. Elle est partagée à l'aide d'un VPC de transit pour mettre fin à la connectivité hybride et aux autres VPC spoke. Vous pouvez également développer cette conception en ajoutant un NVA avec des fonctionnalités d'inspection de pare-feu de nouvelle génération (NGFW) au VPC de transit, comme décrit dans la section suivante, "Utiliser un pare-feu de couche d'application centralisé".
Utiliser un pare-feu de couche d'application centralisé
Si vos exigences techniques vous imposent d'effectuer une inspection approfondie des paquets (couche 7) et une inspection approfondie des paquets avec des fonctionnalités de pare-feu avancées dépassant les capacités de Cloud Next Generation Firewall, vous pouvez utiliser un dispositif NGFW hébergé dans un dispositif virtuel de réseau. Toutefois, ce NVA doit répondre aux besoins de sécurité de votre organisation. Pour ce faire, étendez la topologie de manière à faire transiter tout le trafic interenvironnement par un pare-feu NVA centralisé, comme illustré par le schéma suivant.
Vous pouvez appliquer le modèle dans le schéma suivant sur la conception de la zone de destination à l'aide d'une topologie hub-and-spoke avec des appareils centraliss:
Comme le montre le schéma précédent, le NVA agit comme une couche de sécurité du périmètre et sert de base pour activer l'inspection du trafic intégré. Il applique également des règles de contrôle des accès strictes. Pour inspecter les flux de trafic est-ouest et nord-sud, la conception d'un dispositif virtuel de réseau centralisé peut inclure plusieurs segments avec différents niveaux de contrôles d'accès de sécurité.
Architecture distribuée zéro confiance de microservices
Lorsque des applications conteneurisées sont utilisées, l'architecture distribuée de microservices zéro confiance décrite dans la section Modèle en miroir s'applique également à ce modèle d'architecture.
La principale différence entre ce modèle et le modèle en miroir est que le modèle de communication entre les charges de travail dans Google Cloud et d'autres environnements peut être lancé de chaque côté. Le trafic doit être contrôlé et précis, en fonction des exigences des applications et de sécurité, en utilisant le maillage de services.
Bonnes pratiques concernant les modèles maillés
- Avant toute chose, déterminez la conception de la hiérarchie des ressources, ainsi que la conception requise pour tout projet et tout VPC. Cela peut vous aider à choisir l'architecture réseau optimale qui correspond à la structure de vos projets Google Cloud.
- Utilisez une architecture distribuée zéro confiance lorsque vous utilisez Kubernetes dans votre environnement informatique privé et Google Cloud.
Lorsque vous utilisez des NVA centralisés dans votre conception, vous devez définir plusieurs segments avec différents niveaux de contrôles d'accès de sécurité et de règles d'inspection du trafic. Basez ces contrôles et règles sur les exigences de sécurité de vos applications. Pour en savoir plus, consultez la page Dispositifs réseau centralisés sur Google Cloud.
Lors de la conception d'une solution incluant des NVA, il est important de prendre en compte leur haute disponibilité afin d'éviter un point de défaillance unique susceptible de bloquer toutes les communications. Suivez les conseils de conception et de mise en œuvre en matière de haute disponibilité et de redondance fournis par le fournisseur de sécurité Google Cloud qui fournit vos NVA.
Pour améliorer la confidentialité, l'intégrité des données et le contrôle du modèle de communication, exposez les applications via des API à l'aide de passerelles API telles que Apigee et Apigee hybrid avec mTLS de bout en bout. Vous pouvez également utiliser un VPC partagé avec Apigee dans la même ressource d'organisation.
Si la conception de votre solution nécessite l'exposition d'une application Google Cloud à l'Internet public, tenez compte des recommandations de conception abordées dans Mise en réseau pour la diffusion d'applications Web.
Pour protéger les services Google Cloud dans vos projets et limiter le risque d'exfiltration de données, utilisez VPC Service Controls pour spécifier des périmètres de service au niveau du projet ou du réseau VPC. Vous pouvez également étendre les périmètres de service à un environnement hybride via un VPN ou Cloud Interconnect autorisé. Pour en savoir plus sur les avantages des périmètres de service, consultez la page Présentation de VPC Service Controls.
Consultez les bonnes pratiques générales pour les modèles de mise en réseau hybride et multicloud.
Si vous souhaitez renforcer l'isolement et contrôler plus précisément l'accès entre vos applications hébergées dans Google Cloud et dans d'autres environnements, envisagez d'utiliser l'un des modèles contrôlés décrits dans les autres documents de cette série.