Le modèle maillé repose sur l'établissement d'une architecture réseau hybride. Cette architecture s'étend sur plusieurs environnements de calcul. Dans ces environnements, tous les systèmes peuvent communiquer entre eux et ne sont pas limités à une communication unidirectionnelle en fonction des exigences de sécurité de vos applications. Ce modèle de réseau s'applique principalement aux architectures hybrides par tranche, multicloud partitionnées ou d'utilisation intensive. Il s'applique également à la conception de la continuité des opérations pour provisionner un environnement de reprise après sinistre dans Google Cloud. Dans tous les cas, vous devez connecter les environnements informatiques de manière à répondre aux exigences de communication suivantes :
- Les charges de travail peuvent communiquer entre elles au-delà des limites de leur environnement en utilisant des adresses IP privées RFC 1918.
- La communication peut être initiée par l'une ou l'autre des parties. Les spécificités du modèle de communication peuvent varier en fonction des applications et des exigences de sécurité, comme les modèles de communication abordés 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. Dans l'idéal, vous pouvez utiliser une approche de sécurité multicouche pour filtrer avec précision les flux de trafic internes et entre les différents environnements informatiques.
Architecture
Le diagramme suivant illustre une architecture de référence générale 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 d'autres options de conception possibles de ce modèle, consultez les variantes de conception suivantes. La structure de vos VPC doit correspondre à la conception de la hiérarchie des projets et des ressources de votre organisation.
- Le réseau VPC de Google Cloud s'étend à d'autres environnements informatiques. Ces environnements peuvent être 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) avec des capacités d'inspection de pare-feu nouvelle génération (NGFW), placé dans le chemin réseau.
Cloud Next Generation Firewall Enterprise avec service de prévention des intrusions (IPS) pour implémenter l'inspection approfondie des paquets pour la prévention des menaces sans modifier la conception ni le routage 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 au niveau du réseau des réseaux et ressources VPC, conformément à la conception de la hiérarchie des ressources de votre organisation.
Si la séparation des domaines administratifs 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 dans un réseau commun et assurer l'isolation du réseau entre les différents environnements, utilisez un VPC partagé pour chaque environnement que vous avez dans Google Cloud, comme le développement, les tests et la production.
- Exigences de scaling qui peuvent dépasser les quotas de VPC pour un seul VPC ou projet.
Comme illustré dans le diagramme suivant, la conception "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 d'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 connexions hybrides peuvent être partagées avec tous les VPC spokes. 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 étendre cette conception en ajoutant des NVA avec des fonctionnalités d'inspection de pare-feu nouvelle génération (NGFW) au VPC de transit, comme décrit dans la section suivante "Utiliser un pare-feu de couche application centralisé".
Utiliser un pare-feu centralisé de couche application
Si vos exigences techniques vous obligent à envisager l'inspection de la couche application (couche 7) et des paquets en profondeur avec des fonctionnalités de pare-feu avancées qui dépassent les capacités de Cloud Next Generation Firewall, vous pouvez utiliser un dispositif NGFW hébergé dans une NVA. Toutefois, cette appliance virtuelle de réseau 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é dans le diagramme 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, l'appliance virtuelle réseau (NVA) sert de couche de sécurité du périmètre et constitue la base pour activer l'inspection du trafic en ligne. Il applique également des règles strictes de contrôle des accès. Pour inspecter les flux de trafic est-ouest et nord-sud, la conception d'une NVA centralisée peut inclure plusieurs segments avec différents niveaux de contrôles d'accès de sécurité.
Architecture distribuée zéro confiance pour les microservices
Lorsque des applications conteneurisées sont utilisées, l'architecture distribuée de microservices Zero Trust décrite dans la section sur le 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 initié de part et d'autre. 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 le modèle maillé
- 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 à sélectionner l'architecture réseau optimale qui correspond à la structure de vos projets Google Cloud .
- Utilisez une architecture distribuée Zero Trust lorsque vous utilisez Kubernetes dans votre environnement informatique privé etGoogle Cloud.
- Lorsque vous utilisez des NVA centralisées dans votre conception, vous devez définir plusieurs segments avec différents niveaux de contrôles d'accès à la sécurité et de règles d'inspection du trafic. Basez ces contrôles et ces règles sur les exigences de sécurité de vos applications.
- Lorsque vous concevez une solution qui inclut des NVA, il est important de prendre en compte la haute disponibilité (HD) des NVA pour éviter un point de défaillance unique qui pourrait bloquer toute communication. Suivez les consignes de conception et d'implémentation de la haute disponibilité et de la redondance fournies par le fournisseur de sécuritéGoogle Cloud qui fournit vos NVA.
- Pour renforcer la confidentialité et l'intégrité des données, et pour bénéficier d'un modèle de communication contrôlé, exposez les applications via des API à l'aide de passerelles API, comme Apigee et Apigee hybrid avec mTLS de bout en bout. Vous pouvez également utiliser un VPC partagé avec Apigee dans la même ressource organization.
- Si la conception de votre solution nécessite l'exposition d'une application basée sur 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 une connexion VPN ou Cloud Interconnect autorisée. 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 réseaux hybrides 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 Cloudet 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.