Il s'agit du troisième d'une série de trois documents. Il présente les modèles d'architecture réseau hybride et multicloud. Cette partie explore plusieurs modèles courants d'architecture réseau sécurisée que vous pouvez utiliser pour les architectures hybrides et multicloud. Il décrit les scénarios auxquels ces modèles de mise en réseau sont les plus adaptés et présente les bonnes pratiques pour les implémenter avec Google Cloud.
L'ensemble de documents sur les modèles d'architecture hybride et multicloud se compose des éléments suivants:
- Créer des architectures hybrides et multicloud : traite de la planification d'une stratégie de conception d'une configuration hybride et multicloud avec Google Cloud.
- Modèles d'architecture hybride et multicloud : présente les modèles d'architecture courants à adopter dans le cadre d'une stratégie hybride et multicloud.
- Modèles d'architecture réseau sécurisée hybride et multicloud : présente les modèles d'architecture réseau sécurisée hybride et multicloud du point de vue de la mise en réseau (ce document).
Connecter des environnements informatiques privés à Google Cloud de manière sécurisée et fiable est essentiel pour toute architecture hybride et multicloud réussie. Le modèle de connectivité réseau hybride et d'architecture réseau cloud que vous choisissez pour une configuration hybride et multicloud doit répondre aux exigences particulières des charges de travail de votre entreprise. Il doit également correspondre aux modèles d'architecture que vous prévoyez d'appliquer. Bien que vous deviez adapter chaque conception, vous pouvez vous appuyer sur des modèles courants comme modèle.
Les modèles d'architecture réseau présentés dans ce document ne doivent pas être considérés comme des alternatives à la conception de zone de destination dans Google Cloud. À la place, vous devez concevoir et déployer les modèles d'architecture que vous sélectionnez dans le cadre de la conception globale de la Google Cloud zone de destination, qui couvre les domaines suivants:
- Identités
- Gestion des ressources
- Sécurité
- Mise en réseau
- Surveillance
Différentes applications peuvent utiliser différents modèles d'architecture réseau, qui sont intégrés dans une architecture de zone de destination. Dans une configuration multicloud, vous devez maintenir la cohérence de la conception de la zone de destination dans tous les environnements.
Cette série comprend les pages suivantes:
Contributeurs
Auteur : Marwan Al Shawi | Partner Customer Engineer
Autres contributeurs :
- Saud Albazei | Ingénieur client, modernisation des applications
- Anna Berenberg | Engineering Fellow
- Marco Ferrari | Architecte de solutions cloud
- Victor Moreno | Responsable produit, Mise en réseau cloud
- Johannes Passing | Architecte de solutions cloud
- Mark Schlagenhauf | Rédacteur technique, Mise en réseau
- Daniel Strebel | Responsable de la solution EMEA, modernisation des applications
- Ammett Williams | Ingénieur relations avec les développeurs
Schémas d'architecture
Les documents de cette série traitent des modèles d'architecture réseau conçus en fonction des modèles de communication requis entre les applications résidant dans Google Cloud et dans d'autres environnements (sur site, dans d'autres clouds ou les deux).
Ces modèles doivent être intégrés à l'architecture globale de la zone de destination de l'organisation, qui peut inclure plusieurs modèles de mise en réseau pour répondre aux exigences spécifiques de communication et de sécurité des différentes applications.
Les documents de cette série traitent également des différentes variantes de conception pouvant être utilisées avec chaque modèle d'architecture. Les modèles de mise en réseau suivants peuvent vous aider à répondre aux exigences de communication et de sécurité de vos applications:
Modèle mis en miroir
Le modèle miroité consiste à répliquer la conception d'un ou de plusieurs environnements existants dans un ou plusieurs environnements nouveaux. Par conséquent, ce modèle s'applique principalement aux architectures qui suivent le modèle d'environnement hybride. Dans ce modèle, vous exécutez vos charges de travail de développement et de test dans un environnement, tandis que vous exécutez vos charges de travail de préproduction et de production dans un autre.
Le modèle miroir suppose que les charges de travail de test et de production ne sont pas censées communiquer directement les unes avec les autres. Toutefois, il doit être possible de gérer et de déployer les deux groupes de charges de travail de manière cohérente.
Si vous utilisez ce modèle, connectez les deux environnements informatiques de manière à répondre aux exigences suivantes:
- L'intégration/le déploiement continus (CI/CD) permettent de déployer et de gérer des charges de travail dans tous les environnements informatiques ou dans des environnements spécifiques.
- La surveillance, la gestion de la configuration et d'autres systèmes d'administration doivent fonctionner dans plusieurs environnements informatiques.
- Les charges de travail ne peuvent pas communiquer directement entre les différents environnements informatiques. Si nécessaire, la communication doit être précise et contrôlée.
Architecture
Le schéma d'architecture suivant illustre une architecture de référence de haut niveau de ce modèle compatible avec l'intégration et la diffusion continues, la surveillance, la gestion de la configuration, d'autres systèmes administratifs et la communication des charges de travail:
La description de l'architecture du diagramme précédent est la suivante:
- Les charges de travail sont distribuées en fonction des environnements fonctionnels (développement, test, CI/CD et outils d'administration) sur des VPC distincts à côté. Google Cloud
- Le VPC partagé est utilisé pour les charges de travail de développement et de test. Un VPC supplémentaire est utilisé pour les outils CI/CD et d'administration. Avec les VPC partagés :
- Les applications sont gérées par différentes équipes par environnement et par projet de service.
- Le projet hôte administre et contrôle la communication réseau et les contrôles de sécurité entre les environnements de développement et de test, ainsi qu'en dehors du VPC.
- Le VPC CI/CD est connecté au réseau exécutant les charges de travail de production dans votre environnement IT privé.
- Les règles de pare-feu n'autorisent que le trafic autorisé.
- Vous pouvez également utiliser Cloud Next Generation Firewall Enterprise avec un service de prévention des intrusions (IPS) pour implémenter une inspection approfondie des paquets afin de prévenir les menaces sans modifier la conception ni le routage. Cloud Next Generation Firewall Enterprise consiste à créer des points de terminaison de pare-feu zonaux gérés par Google, qui utilisent la technologie d'interception des paquets afin d'inspecter de manière transparente les charges de travail à la recherche des signatures de menaces configurées. Il protège également les charges de travail contre les menaces.
- Permet la communication entre les VPC appairés à l'aide d'adresses IP internes.
- L'appairage de ce modèle permet aux systèmes CI/CD et administratifs de déployer et de gérer des charges de travail de développement et de test.
- Tenez compte de ces bonnes pratiques générales.
Vous établissez cette connexion CI/CD à l'aide de l'une des options de connectivité réseau hybride et multicloud discutées qui répondent aux exigences de votre entreprise et de vos applications. Pour vous permettre de déployer et de gérer des charges de travail de production, cette connexion offre une connectivité réseau privée entre les différents environnements informatiques. Tous les environnements doivent disposer d'un espace d'adressage IP RFC 1918 sans chevauchement.
Si les instances des environnements de développement et de test nécessitent un accès à Internet, envisagez les options suivantes:
- Vous pouvez déployer Cloud NAT dans le même réseau de projet hôte VPC partagé. Le déploiement dans le même réseau de projet hôte de VPC partagé permet d'éviter de rendre ces instances directement accessibles depuis Internet.
- Pour le trafic Web sortant, vous pouvez utiliser le proxy Web sécurisé. Le proxy présente plusieurs avantages.
Pour en savoir plus sur les Google Cloud outils et fonctionnalités qui vous aident à créer, tester et déployer dans Google Cloud et dans des environnements hybrides et multicloud, consultez le blog DevOps et CI/CD sur Google Cloud expliqué.
Variantes
Pour répondre aux différentes exigences de conception, tout en tenant compte de toutes les exigences en termes de communication, le modèle d'architecture en miroir offre ces options, décrites dans les sections suivantes:
- VPC partagé par environnement
- Pare-feu centralisé de la couche application
- Topologie hub-and-spoke
- Architecture distribuée zéro confiance pour les microservices
VPC partagé par environnement
L'option de conception de VPC partagé par environnement permet de séparer les applications ou les services dans les environnements, y compris les outils CI/CD et d'administration qui peuvent être nécessaires pour répondre à certaines exigences de sécurité organisationnelles. Ces exigences limitent la communication, le domaine administratif et le contrôle des accès pour différents services qui doivent également être gérés par différentes équipes.
Cette conception permet la séparation en assurant un isolement au niveau du réseau et du projet entre les différents environnements, ce qui permet une communication plus précise et le contrôle d'accès Identity and Access Management (IAM).
Du point de vue de la gestion et des opérations, cette conception offre la flexibilité nécessaire pour gérer les applications et les charges de travail créées par différentes équipes par environnement et par projet de service. Le réseau VPC et ses fonctionnalités de sécurité peuvent être provisionnés et gérés par des équipes d'exploitation réseau en fonction des structures possibles suivantes:
- Une seule équipe gère tous les projets hôtes dans tous les environnements.
- Différentes équipes gèrent les projets hôtes dans leurs environnements respectifs.
Les décisions concernant la gestion des projets hôtes doivent être basées sur la structure de l'équipe, les opérations de sécurité et les exigences d'accès de chaque équipe. Vous pouvez appliquer cette variation de conception à l'option de conception de la zone de destination "Réseau VPC partagé pour chaque environnement". Toutefois, vous devez tenir compte des exigences de communication du modèle miroité pour définir les communications autorisées entre les différents environnements, y compris les communications sur le réseau hybride.
Vous pouvez également provisionner un réseau VPC partagé pour chaque environnement principal, comme illustré dans le schéma suivant:
Pare-feu centralisé de couche application
Dans certains cas, les exigences de sécurité peuvent nécessiter de prendre en compte la couche application (couche 7) et l'inspection approfondie des paquets avec des mécanismes de pare-feu avancés qui dépassent les capacités de Cloud NGFW. Pour répondre aux exigences et normes de sécurité de votre organisation, vous pouvez utiliser un dispositif NGFW hébergé dans un dispositif virtuel de réseau (NVA). Plusieurs Google Cloud partenaires de sécurité proposent des options adaptées à cette tâche.
Comme illustré dans le schéma suivant, vous pouvez placer le NVA dans le chemin réseau entre le cloud privé virtuel et l'environnement d'informatique privé à l'aide de plusieurs interfaces réseau.
Cette conception peut également être utilisée avec plusieurs VPC partagés, comme illustré dans le schéma suivant.
Dans cette conception, le NVA sert de couche de sécurité du périmètre. Il sert également de base pour activer l'inspection du trafic en ligne et appliquer des règles de contrôle des accès strictes.
Pour une stratégie de sécurité multicouche robuste qui inclut des règles de pare-feu VPC et des fonctionnalités de service de prévention des intrusions, incluez une inspection et un contrôle de sécurité supplémentaires pour les flux de trafic est-ouest et nord-sud.
Topologie en étoile
Une autre variante de conception consiste à utiliser des VPC distincts (y compris des VPC partagés) pour le développement et les différentes étapes de test. Dans cette variante, comme illustré dans le schéma suivant, tous les environnements d'étape se connectent au VPC CI/CD et administratif dans une architecture hub-and-spoke. Utilisez cette option si vous devez séparer les domaines d'administration et les fonctions dans chaque environnement. Le modèle de communication en hub et spoke peut vous aider à répondre aux exigences suivantes:
- Les applications doivent accéder à un ensemble commun de services, tels que la surveillance, les outils de gestion de la configuration, l'intégration et la livraison continues (CI/CD) ou l'authentification.
- Un ensemble commun de règles de sécurité doit être appliqué de manière centralisée au trafic entrant et sortant via le hub.
Pour en savoir plus sur les options de conception hub-and-spoke, consultez les pages Topologie hub-and-spoke avec serveurs centralisés et Topologie hub-and-spoke sans configuration centralisée des appareils mobiles.
Comme indiqué dans le schéma précédent, la communication inter-VPC et la connectivité hybride passent toutes par le VPC hub. Dans le cadre de ce modèle, vous pouvez contrôler et limiter la communication au niveau du VPC du hub pour qu'elle corresponde à vos exigences de connectivité.
Dans le cadre de l'architecture réseau en hub et spoke, voici les principales options de connectivité (entre les spokes et les VPC hub) sur Google Cloud:
- Appairage de réseaux VPC
- VPN
- À l'aide d'un dispositif virtuel de réseau (NVA)
- Avec plusieurs interfaces réseau
- Avec le Network Connectivity Center (NCC)
Pour en savoir plus sur l'option à envisager pour votre conception, consultez la page Architecture de réseau hub et spoke. Un facteur déterminant dans la sélection d'un VPN via un appairage VPC entre les spokes et le VPC hub réside dans la nécessité de la transitivité du trafic. La transitivité du trafic signifie que le trafic d'un spoke peut atteindre d'autres spokes via le hub.
Architecture distribuée zéro confiance pour les microservices
Les architectures hybrides et multicloud peuvent nécessiter plusieurs clusters pour atteindre leurs objectifs techniques et commerciaux, y compris en séparant l'environnement de production des environnements de développement et de test. Par conséquent, les contrôles de sécurité du périmètre réseau sont importants, en particulier lorsqu'ils sont nécessaires pour respecter certaines exigences de sécurité.
Il ne suffit pas de répondre aux exigences de sécurité des architectures de microservices distribuées cloud first actuelles. Vous devez également envisager des architectures distribuées zéro confiance. L'architecture distribuée zéro confiance des microservices est compatible avec votre architecture de microservices grâce à l'application des règles de sécurité, à l'authentification et à l'identité de la charge de travail au niveau des microservices. La confiance est basée sur l'identité et appliquée pour chaque service.
En utilisant une architecture de proxy distribuée, telle qu'un service mesh, les services peuvent valider efficacement les appelants et implémenter des règles de contrôle des accès précises pour chaque requête, ce qui permet de créer un environnement de microservices plus sécurisé et évolutif. Cloud Service Mesh vous permet de disposer d'un maillage commun pouvant couvrir vos déploiementsGoogle Cloud et sur site. Le réseau maillé utilise des règles d'autorisation pour sécuriser les communications de service à service.
Vous pouvez également intégrer Apigee Adapter for Envoy, qui est un déploiement léger de la passerelle API Apigee dans un cluster Kubernetes, avec cette architecture. Apigee Adapter for Envoy est un proxy de service et de périphérie Open Source conçu pour les applications cloud first.
Pour en savoir plus sur ce sujet, consultez les articles suivants:
- Architecture distribuée zéro confiance
- Environnement hybride GKE Enterprise
- Se connecter à Google
- Connecter un cluster GKE Enterprise sur site à un réseauGoogle Cloud
- Configurer un maillage multicloud ou hybride
- Déployez Cloud Service Mesh dans différents environnements et clusters.
Bonnes pratiques concernant les motifs en miroir
- Les systèmes CI/CD requis pour le déploiement ou la reconfiguration des déploiements de production doivent être disponibilité élevée, ce qui signifie que tous les composants de l'architecture doivent être conçus pour fournir le niveau de disponibilité système attendu. Pour en savoir plus, consultez la section Fiabilité de l'infrastructureGoogle Cloud .
- Pour éliminer les erreurs de configuration pour des processus répétés tels que les mises à jour de code, l'automatisation est essentielle pour standardiser vos compilations, tests et déploiements.
- L'intégration de NVA centralisées dans cette conception peut nécessiter l'intégration de plusieurs segments avec différents niveaux de contrôle des accès de sécurité.
- 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 conseils de conception et d'implémentation de la haute disponibilité et de la redondance fournis par votre fournisseur de NVA.
- En n'exportant pas les routes IP sur site via l'appairage VPC ou le VPN vers le VPC de développement et de test, vous pouvez limiter la joignabilité du réseau des environnements de développement et de test à l'environnement sur site. Pour en savoir plus, consultez la section Échange de routes personnalisées avec l'appairage de réseaux VPC.
- Pour les charges de travail avec adressage IP privé pouvant nécessiter l'accès aux API de Google, vous pouvez exposer les API Google à l'aide d'un point de terminaison Private Service Connect au sein d'un réseau VPC. Pour en savoir plus, consultez la section Entrée contrôlée de cette série.
- Consultez les bonnes pratiques générales pour les modèles d'architecture réseau hybride et multicloud.
Modèle maillé
Le modèle en réseau maillé est basé sur l'établissement d'une architecture réseau hybride. Cette architecture s'étend sur plusieurs environnements IT. 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 réseau s'applique principalement aux architectures hybride par niveaux, multicloud partitionné ou utilisation intensive. Il est également applicable à la conception de la continuité d'activité 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 lancée de n'importe quel côté. 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 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é 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 de haut niveau du modèle en réseau.
- 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, consultez les variantes de conception suivantes. La structure sélectionnée pour vos VPC doit correspondre à la conception de la hiérarchie des ressources et des projets 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 fonctionnalités d'inspection de pare-feu de nouvelle génération (NGFW), placé sur le chemin réseau.
Cloud Next Generation Firewall Enterprise avec un service de prévention des intrusions (IPS) pour implémenter une inspection approfondie des paquets afin de prévenir les 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 des ressources VPC, conformément à la conception de la hiérarchie des ressources de votre organisation.
Si une séparation de domaine administratif est requise, elle peut également être combinée à 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 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 un seul projet.
Comme illustré dans le diagramme 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 d'un Cloud Interconnect avec plusieurs rattachements 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 seule (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 niveau du VPC de transit, comme décrit dans la section suivante intitulée "Utiliser un pare-feu de couche application centralisé".
Utiliser un pare-feu centralisé de couche application
Si vos exigences techniques exigent de prendre en compte la couche application (couche 7) et l'inspection approfondie des paquets avec des fonctionnalités de pare-feu avancées qui dépassent les fonctionnalités du pare-feu nouvelle génération Cloud, vous pouvez utiliser un dispositif NGFW hébergé dans un NVA. 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é 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, le NVA sert de couche de sécurité de périmètre et de base pour l'activation de l'inspection du trafic en ligne. Il applique également des stratégies de contrôle des accès strictes. Pour inspecter les flux de trafic est-ouest et nord-sud, la conception d'un NVA centralisé peut inclure plusieurs segments avec différents niveaux de contrôle 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 zéro confiance abordée dans la section Modèle miroir est également applicable à 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 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 Google Cloud projets.
- Utilisez une architecture distribuée de confiance zéro lorsque vous utilisez Kubernetes dans votre environnement IT privé etGoogle Cloud.
- Lorsque vous utilisez des NVA centralisés dans votre conception, vous devez définir plusieurs segments avec différents niveaux de contrôle 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.
- 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 conseils de conception et d'implémentation de la haute disponibilité et de la redondance fournis par le Google Cloud fournisseur de solutions de sécurité qui fournit vos NVA.
- Pour améliorer la confidentialité, l'intégrité des données et 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 organisation.
- 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 la section 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 réseautage 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 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.
Modèles contrôlés
Le modèle gated (clôturé) repose sur une architecture qui expose certaines applications et certains services de manière précise, en fonction d'API ou de points de terminaison spécifiques exposés entre les différents environnements. Ce guide catégorise ce modèle en trois options possibles, chacune déterminée par le modèle de communication spécifique:
- Sortie contrôlée
Sortie et entrée contrôlées (bidirectionnelles dans les deux sens)
Comme indiqué précédemment dans ce guide, les modèles d'architecture réseau décrits ici peuvent être adaptés à diverses applications ayant des exigences diverses. Pour répondre aux besoins spécifiques de différentes applications, votre architecture de zone de destination principale peut intégrer un modèle ou une combinaison de modèles simultanément. Le déploiement spécifique de l'architecture sélectionnée est déterminé par les exigences de communication spécifiques de chaque modèle contrôlé.
Cette série aborde chaque modèle de page de destination et ses options de conception possibles. Toutefois, une option de conception commune applicable à tous les modèles de contrôle d'accès est l'architecture distribuée zéro confiance pour les applications conteneurisées avec une architecture de microservices. Cette option est fournie par Cloud Service Mesh, Apigee et Apigee Adapter for Envoy, un déploiement de passerelle Apigee léger dans un cluster Kubernetes. Apigee Adapter for Envoy est un proxy de service et de périphérie Open Source courant, conçu pour les applications cloud first. Cette architecture contrôle les communications de service à service sécurisées autorisées et la direction de la communication au niveau du service. Les règles de communication du trafic peuvent être conçues, affinées et appliquées au niveau du service en fonction du modèle sélectionné.
Les modèles avec portillon permettent d'implémenter Cloud Next Generation Firewall Enterprise avec un service de prévention des intrusions (IPS) pour effectuer une inspection approfondie des paquets afin de prévenir les menaces, sans aucune modification de la conception ni du routage. Cette inspection est soumise aux applications spécifiques auxquelles on accède, au modèle de communication et aux exigences de sécurité. Si les exigences de sécurité exigent une inspection approfondie des paquets et de couche 7 avec des mécanismes de pare-feu avancés qui dépassent les capacités de Cloud Next Generation Firewall, vous pouvez utiliser un pare-feu nouvelle génération (NGFW) centralisé hébergé dans un dispositif virtuel de réseau (NVA). Plusieurs Google Cloud partenaires de sécurité proposent des appliances NGFW pouvant répondre à vos exigences de sécurité. L'intégration de NVA avec ces modèles de contrôle d'accès peut nécessiter l'introduction de plusieurs zones de sécurité dans la conception du réseau, chacune avec des niveaux de contrôle d'accès distincts.
Sortie contrôlée
L'architecture du modèle de réseau sortie contrôlée repose sur l'exposition de certaines API de l'environnement sur site ou d'un autre environnement cloud aux charges de travail déployées dans Google Cloud. Il le fait sans les exposer directement à l'Internet public à partir d'un environnement sur site ou d'autres environnements cloud. L'utilisation d'une passerelle API ou d'un proxy, ou d'un équilibreur de charge servant de façade aux charges de travail existantes permet de contrôler cette exposition. Vous pouvez déployer la fonctionnalité de passerelle API dans un segment de réseau de périmètre isolé, comme un réseau de périmètre.
Le modèle de réseau sortie contrôlée s'applique principalement, mais sans s'y limiter, aux modèles d'architecture d'application à niveaux et aux modèles d'architecture d'application partitionnée. Lorsque vous déployez des charges de travail de backend sur un réseau interne, le réseau de sortie contrôlé permet de maintenir un niveau de sécurité plus élevé dans votre environnement IT sur site. Le modèle nécessite que vous connectiez les environnements informatiques de manière à répondre aux exigences de communication suivantes:
- Les charges de travail que vous déployez dans Google Cloud peuvent communiquer avec la passerelle API ou l'équilibreur de charge (ou un point de terminaison Private Service Connect) qui expose l'application à l'aide d'adresses IP internes.
- Les autres systèmes de l'environnement IT privé ne sont pas accessibles directement depuis Google Cloud.
- La communication entre l'environnement informatique privé et les charges de travail déployées dans Google Cloud n'est pas autorisée.
- Le trafic vers les API privées dans d'autres environnements n'est lancé que depuis l'environnement Google Cloud .
Ce guide se concentre sur les environnements hybrides et multicloud connectés via un réseau hybride privé. Si les exigences de sécurité de votre organisation le permettent, les appels d'API vers des API cibles distantes avec des adresses IP publiques peuvent être directement accessibles via Internet. Toutefois, vous devez tenir compte des mécanismes de sécurité suivants:
- API OAuth 2.0 avec TLS (Transport Layer Security)
- Limitation du débit
- Règles de protection contre les menaces
- Authentification TLS mutuelle configurée sur le backend de votre couche API.
- Filtrage de la liste d'autorisation des adresses IP configuré pour n'autoriser que la communication avec des sources et des destinations d'API prédéfinies des deux côtés.
Pour sécuriser un proxy d'API, tenez compte de ces autres aspects de sécurité. Pour en savoir plus, consultez les bonnes pratiques pour sécuriser vos applications et vos API avec Apigee.
Architecture
Le schéma suivant montre une architecture de référence compatible avec les exigences de communication listées dans la section précédente:
Les données circulent dans le diagramme précédent comme suit:
- Du côté de Google Cloud , vous pouvez déployer des charges de travail dans des clouds privés virtuels (VPC). Les VPC peuvent être uniques ou multiples (partagés ou non). Le déploiement doit être conforme aux projets et à la conception de la hiérarchie des ressources de votre organisation.
- Les réseaux VPC de l'environnement Google Cloud s'étendent aux autres environnements informatiques. Les environnements peuvent être sur site ou dans un autre cloud. Pour faciliter la communication entre les environnements à l'aide d'adresses IP internes, utilisez une connectivité réseau hybride et multicloud appropriée.
Pour limiter le trafic provenant d'adresses IP VPC spécifiques et destiné à des passerelles ou à des équilibreurs de charge distants, utilisez le filtrage de la liste d'autorisation des adresses IP. Le trafic retour de ces connexions est autorisé lorsque vous utilisez des règles de pare-feu avec état. Vous pouvez utiliser n'importe quelle combinaison des fonctionnalités suivantes pour sécuriser et limiter les communications aux seules adresses IP source et de destination autorisées:
Dispositif virtuel de réseau (NVA) avec des fonctionnalités d'inspection de pare-feu nouvelle génération (NGFW) placées sur le chemin réseau.
Cloud Next Generation Firewall Enterprise avec un service de prévention des intrusions (IPS) pour mettre en œuvre une inspection approfondie des paquets à des fins de prévention des menaces.
Tous les environnements partagent un espace d'adressage IP RFC 1918 sans chevauchement.
Variantes
Le modèle d'architecture d'sortie contrôlée peut être combiné à d'autres approches pour répondre à différentes exigences de conception tout en tenant compte des exigences de communication de ce modèle. Le modèle propose les options suivantes :
- Utiliser la passerelle d'API et l'interface globale Google Cloud
- Exposer des services distants à l'aide de Private Service Connect
Utiliser la passerelle d'API Google Cloud et l'interface globale
Avec cette approche de conception, l'exposition et la gestion des API se trouvent dansGoogle Cloud. Comme illustré dans le schéma précédent, vous pouvez y parvenir en implémentant Apigee comme plate-forme d'API. La décision de déployer une passerelle d'API ou un équilibreur de charge dans l'environnement distant dépend de vos besoins spécifiques et de votre configuration actuelle. Apigee propose deux options de provisionnement de la connectivité:
- Avec appairage de VPC
- Sans appairage de VPC
Les fonctionnalités d'interface globale deGoogle Cloud , telles que Cloud Load Balancing, Cloud CDN (lorsque l'accès s'effectue via Cloud Interconnect) et interconnexion cross-cloud, permettent aux utilisateurs d'accéder plus rapidement aux applications dont les backends sont hébergés dans vos environnements sur site et dans d'autres environnements cloud.
Pour optimiser les vitesses de diffusion de contenu, ces applications sont diffusées à partir de Google Cloud points de présence (PoP) Google Cloud . Les PoP sont présents sur plus de 180 points d'échange Internet et dans plus de 160 installations d'interconnexion à travers le monde.
Pour découvrir comment les points de présence permettent de fournir des API hautes performances lorsque vous utilisez Apigee avec Cloud CDN pour : regardez la vidéo Fournir des API hautes performances avec Apigee et Cloud CDN sur YouTube.
- Réduire la latence.
- Hébergez des API à l'échelle mondiale.
- Augmenter la disponibilité en cas de pic de trafic
L'exemple de conception illustré dans le schéma précédent est basé sur Private Service Connect sans l'appairage de réseaux VPC.
Le réseau northbound de cette conception est établi via:
- Un équilibreur de charge (LB dans le diagramme), où les requêtes client se terminent, traite le trafic, puis l'achemine vers un backend Private Service Connect.
- Un backend Private Service Connect permet à un équilibreur de charge Google Cloud d'envoyer des requêtes client via une connexion Private Service Connect associée à un rattachement de service de producteur au service publié (instance d'exécution Apigee) à l'aide de groupes de points de terminaison du réseau (NEG) Private Service Connect.
Le réseautage Southbound est établi via:
- Point de terminaison Private Service Connect qui fait référence à un rattachement de service associé à un équilibreur de charge interne (ILB dans le diagramme) dans le VPC du client.
L'ILB est déployé avec des groupes de points de terminaison du réseau de connectivité hybride (NEG de connectivité hybride).
L'accès aux services hybrides s'effectue via le NEG de connectivité hybride avec une connectivité réseau hybride, comme le VPN ou Cloud Interconnect.
Pour en savoir plus, consultez les pages Configurer un équilibreur de charge réseau proxy interne régional avec une connectivité hybride et Modèles de déploiement Private Service Connect.
Exposer des services distants à l'aide de Private Service Connect
Utilisez l'option Private Service Connect pour exposer des services distants dans les scénarios suivants:
- Vous n'utilisez pas de plate-forme d'API ou vous souhaitez éviter de connecter l'intégralité de votre réseau VPC directement à un environnement externe pour les raisons suivantes :
- Vous avez des restrictions de sécurité ou des exigences de conformité.
- La plage d'adresses IP se chevauche, par exemple dans le cas d'une fusion et d'une acquisition.
- Pour activer les communications unidirectionnelles sécurisées entre les clients, les applications et les services dans les environnements, même si vous disposez d'un délai court.
- Vous devrez peut-être fournir une connectivité à plusieurs VPC client via un VPC de producteur de services (VPC de transit) pour proposer des modèles de services multi-tenants ou mono-tenants hautement évolutifs, afin d'accéder aux services publiés sur d'autres environnements.
L'utilisation de Private Service Connect pour les applications consommées en tant qu'API fournit une adresse IP interne aux applications publiées, ce qui permet un accès sécurisé au réseau privé dans les régions et via la connectivité hybride. Cette abstraction facilite l'intégration des ressources de divers clouds et environnements sur site via un modèle de connectivité hybride et multicloud. Vous pouvez accélérer l'intégration des applications et exposer de manière sécurisée les applications qui résident dans un environnement sur site ou dans un autre environnement cloud à l'aide de Private Service Connect pour publier le service avec un accès précis. Dans ce cas, vous pouvez utiliser l'option suivante:
- Rattachement de service qui fait référence à un équilibreur de charge réseau proxy interne régional ou à un équilibreur de charge d'application interne.
- L'équilibreur de charge utilise un groupe de points de terminaison réseau hybride (NEG de connectivité hybride) dans un VPC producteur qui agit dans cette conception comme un VPC de transit.
Dans le schéma précédent, les charges de travail du réseau VPC de votre application peuvent atteindre les services hybrides exécutés dans votre environnement sur site ou dans d'autres environnements cloud via le point de terminaison Private Service Connect, comme illustré dans le schéma suivant. Cette option de conception pour les communications unidirectionnelles constitue une alternative à l'appairage avec un VPC de transit.
Dans le cadre de la conception du diagramme précédent, plusieurs frontends, backends ou points de terminaison peuvent se connecter au même rattachement de service, ce qui permet à plusieurs réseaux VPC ou à plusieurs clients d'accéder au même service. Comme illustré dans le schéma suivant, vous pouvez rendre l'application accessible à plusieurs VPC. Cette accessibilité peut être utile dans les scénarios de services multi-locataires où votre service est consommé par plusieurs VPC client, même si leurs plages d'adresses IP se chevauchent.
La superposition d'adresses IP est l'un des problèmes les plus courants lors de l'intégration d'applications situées dans différents environnements. La connexion Private Service Connect du schéma suivant permet d'éviter le problème de chevauchement d'adresses IP. Il le fait sans avoir à provisionner ni à gérer d'autres composants réseau, tels que Cloud NAT ou un NVA, pour effectuer la traduction d'adresses IP. Pour obtenir un exemple de configuration, consultez la section Publier un service hybride à l'aide de Private Service Connect.
Cette conception présente les avantages suivants:
- Évite les dépendances de scaling partagées potentielles et la complexité de la gestion à grande échelle.
- Améliore la sécurité en fournissant un contrôle précis de la connectivité.
- Réduit la coordination des adresses IP entre le producteur et le consommateur du service, et l'environnement externe distant.
L'approche de conception du diagramme précédent peut être étendue à des étapes ultérieures pour intégrer Apigee en tant que plate-forme d'API à l'aide des options de conception de mise en réseau abordées précédemment, y compris l'option Private Service Connect.
Vous pouvez rendre le point de terminaison Private Service Connect accessible depuis d'autres régions à l'aide de l'accès mondial Private Service Connect.
Le client qui se connecte au point de terminaison Private Service Connect peut se trouver dans la même région que le point de terminaison ou dans une autre région. Cette approche peut être utilisée pour fournir une haute disponibilité à des services hébergés dans plusieurs régions ou pour accéder à des services disponibles dans une seule région à partir d'autres régions. Lorsqu'un point de terminaison Private Service Connect est accessible par des ressources hébergées dans d'autres régions, les frais de sortie interrégionaux s'appliquent au trafic destiné aux points de terminaison avec accès mondial.
Google CloudBonnes pratiques
- Choisir Apigee et Apigee Hybrid comme solution de plate-forme d'API présente plusieurs avantages. Elle fournit une couche proxy, ainsi qu'une abstraction ou une façade pour vos API de service de backend, associées à des fonctionnalités de sécurité, une limitation du débit, des quotas et des analyses.
- Utilisez Apigee Adapter for Envoy avec une architecture de déploiement Apigee Hybrid avec Kubernetes, le cas échéant, en fonction de vos exigences et de l'architecture.
- La conception des VPC et des projets dans Google Cloud doit être guidée par votre hiérarchie des ressources et vos exigences concernant le modèle de communication sécurisé.
- Lorsque des API avec des passerelles d'API sont utilisées, vous devez également utiliser une liste d'autorisation d'adresses IP. Une liste d'autorisation limite les communications aux sources et destinations d'adresses IP spécifiques des consommateurs d'API et des passerelles d'API pouvant être hébergées dans différents environnements.
- Utilisez des règles de pare-feu VPC ou des stratégies de pare-feu pour contrôler l'accès aux ressources Private Service Connect via le point de terminaison Private Service Connect.
- Si une application est exposée en externe via un équilibreur de charge d'application, envisagez d'utiliser Google Cloud Armor comme couche de sécurité supplémentaire pour vous protéger contre les attaques DDoS et les menaces de sécurité de la couche application.
Si les instances nécessitent un accès à Internet, utilisez Cloud NAT dans le VPC de l'application (consommateur) pour permettre aux charges de travail d'accéder à Internet. Vous évitez ainsi d'attribuer des adresses IP publiques externes aux instances de VM dans les systèmes déployés derrière une passerelle API ou un équilibreur de charge.
- Pour le trafic Web sortant, vous pouvez utiliser Google Cloud Secure Web Proxy. Le proxy présente plusieurs avantages.
Consultez les bonnes pratiques générales pour les modèles de réseautage hybride et multicloud.
Entrée contrôlée
L'architecture du modèle entrée contrôlée repose sur l'exposition de certaines API de charges de travail exécutées dans Google Cloud à l'environnement informatique privé, sans les exposer à l'Internet public. Ce modèle est la contrepartie du modèle d'entrée contrôlée et convient bien aux scénarios d'hybride de périphérie, d'hybride par tranche et de multicloud partitionné.
Comme avec le modèle d'égresse contrôlée, vous pouvez faciliter cette exposition limitée via une passerelle API ou un équilibreur de charge qui sert de façade pour les charges de travail ou les services existants. Il est ainsi accessible aux environnements d'informatique privée, aux environnements sur site ou à un autre environnement cloud, comme suit:
- Les charges de travail que vous déployez dans l'environnement informatique privé ou d'autres environnements cloud peuvent communiquer avec la passerelle API ou l'équilibreur de charge à l'aide d'adresses IP internes. Les autres systèmes déployés dansGoogle Cloud ne sont pas accessibles.
- La communication entre Google Cloud et l'environnement informatique privé ou d'autres environnements cloud n'est pas autorisée. Le trafic n'est lancé que depuis l'environnement privé ou d'autres environnements cloud vers les API dans Google Cloud.
Architecture
Le diagramme suivant montre une architecture de référence répondant aux exigences du modèle d'entrée contrôlée.
La description de l'architecture du diagramme précédent est la suivante:
- Du côté de Google Cloud , vous déployez les charges de travail dans un VPC d'application (ou plusieurs VPC).
- Le réseau de l'environnement Google Cloud s'étend à d'autres environnements informatiques (sur site ou dans un autre cloud) à l'aide d'une connectivité réseau hybride ou multicloud pour faciliter la communication entre les environnements.
- Vous pouvez éventuellement utiliser un VPC de transit pour effectuer les opérations suivantes:
- Fournissez des couches de sécurité de périmètre supplémentaires pour autoriser l'accès à des API spécifiques en dehors du VPC de votre application.
- Acheminez le trafic vers les adresses IP des API. Vous pouvez créer des règles de pare-feu VPC pour empêcher certaines sources d'accéder à certaines API via un point de terminaison.
- Inspectez le trafic de couche 7 au niveau du VPC de transit en intégrant un dispositif virtuel de réseau (NVA).
- Accédez aux API via une passerelle API ou un équilibreur de charge (proxy ou équilibreur de charge d'application) pour fournir une couche proxy, ainsi qu'une couche d'abstraction ou une façade pour vos API de service. Si vous devez distribuer le trafic entre plusieurs instances de passerelle API, vous pouvez utiliser un équilibreur de charge réseau passthrough interne.
- Fournissez un accès limité et précis à un service publié via un point de terminaison Private Service Connect à l'aide d'un équilibreur de charge via Private Service Connect pour exposer une application ou un service.
- Tous les environnements doivent utiliser un espace d'adressage IP RFC 1918 sans chevauchement.
Le schéma suivant illustre la conception de ce modèle en utilisant Apigee comme plate-forme d'API.
Dans le diagramme précédent, l'utilisation d'Apigee comme plate-forme d'API fournit les fonctionnalités suivantes pour activer le modèle d'entrée contrôlée:
- Fonctionnalité de passerelle ou de proxy
- Fonctionnalités de sécurité
- Limitation de débit
- Analyse
Dans la conception:
- La connectivité réseau northbound (pour le trafic provenant d'autres environnements) passe par un point de terminaison Private Service Connect dans le VPC de votre application associé au VPC Apigee.
- Dans le VPC de l'application, un équilibreur de charge interne est utilisé pour exposer les API de l'application via un point de terminaison Private Service Connect présenté dans le VPC Apigee. Pour en savoir plus, consultez la section Architecture avec appairage de VPC désactivé.
Configurez des règles de pare-feu et un filtrage du trafic au niveau du VPC de l'application. Vous bénéficiez ainsi d'un accès précis et contrôlé. Il permet également d'empêcher les systèmes d'atteindre directement vos applications sans passer par le point de terminaison Private Service Connect et la passerelle API.
Vous pouvez également limiter la diffusion du sous-réseau d'adresses IP internes de la charge de travail backend dans le VPC de l'application au réseau sur site pour éviter la connectivité directe sans passer par le point de terminaison Private Service Connect et la passerelle API.
Certaines exigences de sécurité peuvent nécessiter une inspection de la sécurité du périmètre en dehors du VPC de l'application, y compris le trafic de connectivité hybride. Dans ce cas, vous pouvez intégrer un VPC de transit pour implémenter des couches de sécurité supplémentaires. Ces couches, par exemple les NVA NGFW avec plusieurs interfaces réseau, ou Cloud Next Generation Firewall Enterprise avec un service de prévention des intrusions (IPS), effectuent une inspection approfondie des paquets en dehors du VPC de votre application, comme illustré dans le schéma suivant:
Comme illustré dans le schéma précédent :
- La connectivité réseau Northbound (pour le trafic provenant d'autres environnements) passe par un VPC de transit distinct vers le point de terminaison Private Service Connect dans le VPC de transit associé au VPC Apigee.
- Dans le VPC de l'application, un équilibreur de charge interne (ILB dans le diagramme) est utilisé pour exposer l'application via un point de terminaison Private Service Connect dans le VPC Apigee.
Vous pouvez provisionner plusieurs points de terminaison dans le même réseau VPC, comme illustré dans le schéma suivant. Pour couvrir différents cas d'utilisation, vous pouvez contrôler les différents chemins réseau possibles à l'aide de Cloud Router et de règles de pare-feu VPC. Par exemple, si vous connectez votre réseau sur site à Google Cloud à l'aide de plusieurs connexions de réseau hybride, vous pouvez envoyer du trafic sur site vers des API Google ou des services publiés spécifiques via une connexion et le reste via une autre connexion. Vous pouvez également utiliser l'accès global Private Service Connect pour fournir des options de basculement.
Variantes
Le modèle d'architecture d'entrée contrôlée 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. Le modèle propose les options suivantes :
Accéder aux API Google à partir d'autres environnements
Private Service Connect propose une solution pour les scénarios nécessitant l'accès aux services Google, tels que Cloud Storage ou BigQuery, sans envoyer de trafic sur l'Internet public. Comme illustré dans le diagramme suivant, il permet d'atteindre les API Google compatibles et les services (y compris Google Maps, Google Ads etGoogle Cloud) à partir d'environnements cloud ou sur site via une connexion réseau hybride à l'aide de l'adresse IP du point de terminaison Private Service Connect. Pour en savoir plus sur l'accès aux API Google via des points de terminaison Private Service Connect, consultez la section À propos de l'accès aux API Google via des points de terminaison.
Dans le diagramme précédent, votre réseau sur site doit être connecté au réseau VPC de transit (consommateur) à l'aide de tunnels Cloud VPN ou d'un rattachement VLAN Cloud Interconnect.
Les API Google sont accessibles via des points de terminaison ou des backends. Les points de terminaison vous permettent de cibler un groupe d'API Google. Les backends vous permettent de cibler une API Google régionale spécifique.
Exposer les backends d'applications à d'autres environnements à l'aide de Private Service Connect
Dans certains cas, comme indiqué par le modèle hybride par tranche, vous devrez peut-être déployer des backends dans Google Cloud tout en conservant les interfaces dans des environnements informatiques privés. Bien que moins courante, cette approche est applicable lorsque vous travaillez avec des interfaces monolithiques lourdes qui peuvent s'appuyer sur des composants anciens. Ou, plus généralement, lors de la gestion d'applications distribuées dans plusieurs environnements, y compris sur site et dans d'autres clouds, qui nécessitent une connectivité à des backends hébergés dans Google Cloud via un réseau hybride.
Dans une telle architecture, vous pouvez utiliser une passerelle d'API ou un équilibreur de charge local dans l'environnement privé sur site ou dans d'autres environnements cloud pour exposer directement l'interface de l'application sur Internet. L'utilisation de Private Service Connect dans Google Cloud facilite la connectivité privée aux backends exposés via un point de terminaison Private Service Connect, idéalement à l'aide d'API prédéfinies, comme illustré dans le diagramme suivant:
La conception du schéma précédent utilise un déploiement Apigee Hybrid composé d'un plan de gestion dans Google Cloud et d'un plan d'exécution hébergé dans votre autre environnement. Vous pouvez installer et gérer le plan d'exécution sur une passerelle API distribuée sur l'une des plates-formes Kubernetes compatibles dans votre environnement sur site ou dans d'autres environnements cloud. En fonction de vos exigences concernant les charges de travail distribuées sur Google Cloud et d'autres environnements, vous pouvez utiliser Apigee sur Google Cloud avec Apigee hybrid. Pour en savoir plus, consultez la section Passerelles API distribuées.
Utiliser une architecture ub and spoke pour exposer les backends d'applications à d'autres environnements
Dans certains cas, il peut être nécessaire d'exposer des API à partir de backends d'application hébergés dans Google Cloud sur différents réseaux VPC. Comme illustré dans le schéma suivant, un VPC hub sert de point d'interconnexion central pour les différents VPC (spokes), ce qui permet une communication sécurisée via une connectivité hybride privée. Vous pouvez également utiliser les fonctionnalités de passerelle API locales dans d'autres environnements, tels que Apigee Hybrid, pour mettre fin aux requêtes client localement, là où l'interface de l'application est hébergée.
Comme illustré dans le schéma précédent :
- Pour fournir des fonctionnalités d'inspection de couche 7 NGFW supplémentaires, le NVA avec des fonctionnalités NGFW peut être intégré à la conception. Vous devrez peut-être disposer de ces fonctionnalités pour respecter les exigences de sécurité spécifiques et les normes de votre organisation en matière de règles de sécurité.
Cette conception suppose que les VPC spokes ne nécessitent pas de communication VPC à VPC directe.
- Si une communication entre les spokes est nécessaire, vous pouvez utiliser le NVA pour faciliter cette communication.
- Si vous disposez de différents backends dans différents VPC, vous pouvez utiliser Private Service Connect pour les exposer au VPC Apigee.
- Si l'appairage de VPC est utilisé pour la connectivité nord-sud entre les VPC spoke et le VPC hub, vous devez tenir compte de la limitation de transitivité de la mise en réseau VPC via l'appairage de VPC. Pour contourner cette limitation, vous pouvez utiliser l'une des options suivantes :
- Pour interconnecter les VPC, utilisez un NVA.
- Le cas échéant, envisagez le modèle Private Service Connect.
- Pour établir la connectivité entre le VPC Apigee et les backends situés dans d'autres projetsGoogle Cloud de la même organisation sans composants réseau supplémentaires, utilisez un VPC partagé.
Si des NVA sont nécessaires pour l'inspection du trafic, y compris celui provenant de vos autres environnements, la connectivité hybride vers des environnements sur site ou d'autres environnements cloud doit se terminer sur le VPC de transit hybride.
Si la conception n'inclut pas le NVA, vous pouvez mettre fin à la connectivité hybride au niveau du VPC du hub.
Si certaines fonctionnalités d'équilibrage de charge ou de sécurité sont requises, comme l'ajout d'une protection DDoS ou dWAF;application Google Cloud Armor, vous pouvez éventuellement déployer un équilibreur de charge d'application externe au périmètre via un VPC externe avant de router les requêtes client externes vers les backends.
Bonnes pratiques
- Dans les cas où les requêtes client provenant d'Internet doivent être reçues localement par une interface d'application hébergée dans un environnement cloud privé sur site ou autre environnement cloud, envisagez d'utiliser Apigee Hybrid comme solution de passerelle API. Cette approche facilite également la migration fluide de la solution vers un environnement entièrement hébergé par Google Cloud, tout en préservant la cohérence de la plate-forme d'API (Apigee).
- Utilisez Apigee Adapter for Envoy avec une architecture de déploiement Apigee Hybrid avec Kubernetes, le cas échéant, en fonction de vos exigences et de l'architecture.
- La conception des VPC et des projets dans Google Cloud doit suivre la hiérarchie des ressources et les exigences du modèle de communication sécurisé, comme décrit dans ce guide.
- L'intégration d'un VPC de transit dans cette conception offre la flexibilité nécessaire pour provisionner des mesures de sécurité périmétriques supplémentaires et une connectivité hybride en dehors du VPC de la charge de travail.
- Utilisez Private Service Connect pour accéder aux API et services Google à partir d'environnements sur site ou d'autres environnements cloud à l'aide de l'adresse IP interne du point de terminaison via un réseau de connectivité hybride. Pour en savoir plus, consultez la section Accéder au point de terminaison à partir d'hôtes sur site.
- 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.
- Si nécessaire, vous pouvez étendre les périmètres de service à un environnement hybride via un VPN ou Cloud Interconnect. Pour en savoir plus sur les avantages des périmètres de service, consultez la page Présentation de VPC Service Controls.
- Utilisez des règles de pare-feu VPC ou des stratégies de pare-feu pour contrôler l'accès au niveau du réseau aux ressources Private Service Connect via le point de terminaison Private Service Connect. Par exemple, les règles de pare-feu sortantes au niveau du VPC de l'application (client) peuvent restreindre l'accès des instances de VM à l'adresse IP ou au sous-réseau de vos points de terminaison. Pour en savoir plus sur les règles de pare-feu VPC en général, consultez la section Règles de pare-feu VPC.
- 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 conseils de conception et d'implémentation de la haute disponibilité et de la redondance fournis par votre fournisseur de NVA.
- Pour renforcer la sécurité périmétrique et sécuriser votre passerelle API déployée dans l'environnement concerné, vous pouvez éventuellement implémenter des mécanismes d'équilibrage de charge et de pare-feu d'application Web dans votre autre environnement IT (hybride ou autre cloud). Implémentez ces options au niveau du réseau de périmètre directement connecté à Internet.
- Si les instances nécessitent un accès à Internet, utilisez Cloud NAT dans le VPC de l'application pour permettre aux charges de travail d'accéder à Internet. Vous évitez ainsi d'attribuer des adresses IP publiques externes aux instances de VM dans les systèmes déployés derrière une passerelle API ou un équilibreur de charge.
- Pour le trafic Web sortant, utilisez le proxy Web sécurisé. Le proxy présente plusieurs avantages.
- Consultez les bonnes pratiques générales pour les modèles de réseautage hybride et multicloud.
Sortie et entrée contrôlées
Le modèle Entrée et sortie contrôlées combine l'entrée et la sortie contrôlées pour les scénarios qui exigent une utilisation bidirectionnelle d'API sélectionnées entre les charges de travail. Les charges de travail peuvent s'exécuter dans Google Cloud, dans des environnements privés sur site ou dans d'autres environnements cloud. Dans ce modèle, vous pouvez utiliser des passerelles API, des points de terminaison Private Service Connect ou des équilibreurs de charge pour exposer des API spécifiques et éventuellement fournir une authentification, une autorisation et des audits des appels d'API.
La principale différence entre ce modèle et le modèle en réseau maillé réside dans son application à des scénarios qui ne nécessitent que l'utilisation d'API bidirectionnelle ou la communication avec des sources et des destinations d'adresses IP spécifiques (par exemple, une application publiée via un point de terminaison Private Service Connect). Étant donné que la communication est limitée aux API exposées ou aux adresses IP spécifiques, les réseaux des environnements n'ont pas besoin d'être alignés dans votre conception. Voici quelques exemples courants de scénarios applicables (liste non exhaustive) :
- Fusions et acquisitions
- Intégrations d'applications avec des partenaires
- Intégrations entre les applications et les services d'une organisation avec différentes unités organisationnelles qui gèrent leurs propres applications et les hébergent dans différents environnements.
La communication fonctionne comme suit:
- Les charges de travail que vous déployez dans Google Cloud peuvent communiquer avec la passerelle API (ou des adresses IP de destination spécifiques) à l'aide d'adresses IP internes. Les autres systèmes déployés dans l'environnement informatique privé ne sont pas accessibles.
- À l'inverse, les charges de travail que vous déployez dans d'autres environnements informatiques peuvent communiquer avec la passerelle API côté Google Cloud(ou une adresse IP de point de terminaison publiée spécifique) à l'aide d'adresses IP internes. Les autres systèmes déployés dans Google Cloud ne sont pas accessibles.
Architecture
Le schéma suivant montre une architecture de référence pour le modèle d'entrée et de sortie contrôlées:
L'approche de conception du diagramme précédent comprend les éléments suivants:
- Du côté de Google Cloud , vous déployez des charges de travail dans un VPC (ou un VPC partagé) sans les exposer directement à Internet.
- Le réseau de l'environnement Google Cloud s'étend à d'autres environnements informatiques. Cet environnement peut être sur site ou dans un autre cloud. Pour étendre l'environnement, utilisez un modèle de communication de connectivité hybride et multicloud approprié pour faciliter la communication entre les environnements afin qu'ils puissent utiliser des adresses IP internes.
- Vous pouvez éventuellement utiliser un VPC de transit pour ajouter une couche de sécurité de périmètre en dehors de votre VPC d'application en activant l'accès à des adresses IP cibles spécifiques.
- Vous pouvez utiliser Cloud Next Generation Firewall ou des appliances réseau virtuels (NVA) avec des pare-feu de nouvelle génération (NGFW) au niveau du VPC de transit pour inspecter le trafic et autoriser ou interdire l'accès à certaines API à partir de sources spécifiques avant d'atteindre votre VPC d'application.
- Les API doivent être accessibles via une passerelle API ou un équilibreur de charge pour fournir une couche proxy, ainsi qu'une abstraction ou une façade pour vos API de service.
- Pour les applications consommées en tant qu'API, vous pouvez également utiliser Private Service Connect pour fournir une adresse IP interne à l'application publiée.
- Tous les environnements utilisent un espace d'adressage IP RFC 1918 sans chevauchement.
Une application courante de ce modèle consiste à déployer des backends d'application (ou un sous-ensemble de backends d'application) dans Google Cloud tout en hébergeant d'autres composants backend et frontend dans des environnements sur site ou dans d'autres clouds (modèle hybride à niveaux ou modèle multicloud partitionné). À mesure que les applications évoluent et migrent vers le cloud, des dépendances et des préférences pour des services cloud spécifiques émergent souvent.
Parfois, ces dépendances et préférences entraînent la distribution d'applications et de backends sur différents fournisseurs cloud. De plus, certaines applications peuvent être créées avec une combinaison de ressources et de services distribués dans des environnements sur site et plusieurs environnements cloud.
Pour les applications distribuées, les fonctionnalités de la connectivité hybride et multicloud Cloud Load Balancing externe peuvent être utilisées pour mettre fin aux requêtes des utilisateurs et les acheminer vers des frontends ou des backends dans d'autres environnements. Ce routage s'effectue via une connexion réseau hybride, comme illustré dans le schéma suivant. Cette intégration permet de distribuer progressivement les composants d'application dans différents environnements. Les requêtes du frontend vers les services de backend hébergés dans Google Cloud communiquent de manière sécurisée via la connexion réseau hybride établie, facilitée par un équilibreur de charge interne (ILB dans le diagramme).
L'utilisation de la conception Google Cloud du schéma précédent permet de:
- Facilite la communication bidirectionnelle entre Google Cloud, sur site et d'autres environnements cloud à l'aide d'API prédéfinies des deux côtés, qui s'alignent sur le modèle de communication de ce modèle.
- Pour fournir des interfaces utilisateur globales pour les applications exposées sur Internet avec des composants d'application distribués (interfaces utilisateur ou backends), et pour atteindre les objectifs suivants, vous pouvez utiliser les fonctionnalités avancées d'équilibrage de charge et de sécurité de Google Cloud distribuées sur des points de présence (PoP):
- Réduisez vos dépenses d'investissement et simplifiez vos opérations grâce aux services gérés sans serveur.
- Optimisez les connexions aux backends d'application de manière globale pour améliorer la vitesse et la latence.
- Google Cloud Cross-Cloud Network (Réseau multicloud) permet la communication multicloud entre les composants d'application via des connexions privées optimales.
- Mettez en cache le contenu statique à forte demande et améliorez les performances des applications qui utilisent Cloud Load Balancing global en leur donnant accès à Cloud CDN.
- Sécurisez les frontends globaux des applications exposées sur Internet à l'aide des fonctionnalités de Google Cloud Armor qui fournissent des services de pare-feu d'application Web (WAF) et d'atténuation des attaques DDoS distribués à l'échelle mondiale.
- Vous pouvez également intégrer Private Service Connect à votre conception. Cela permet d'accéder de manière privée et précise aux API de service ou à vos services publiés à partir d'autres environnements, sans passer par l'Internet public. Google Cloud
Variantes
Les modèles d'architecture sortie contrôlée et entrée contrôlée peuvent être combinés à d'autres approches pour répondre à différentes exigences de conception, tout en tenant compte des exigences de communication de ce modèle. Les modèles proposent les options suivantes:
- Passerelles API distribuées
- Communication bidirectionnelle des API à l'aide de Private Service Connect
- Communication bidirectionnelle à l'aide de points de terminaison et d'interfaces Private Service Connect
Passerelles API distribuées
Dans des scénarios comme celui basé sur le modèle multicloud partitionné, les applications (ou composants d'application) peuvent être créées dans différents environnements cloud, y compris un environnement privé sur site. L'exigence courante consiste à acheminer les requêtes client vers l'interface de l'application directement vers l'environnement dans lequel l'application (ou le composant de frontend) est hébergée. Ce type de communication nécessite un équilibreur de charge local ou une passerelle d'API. Ces applications et leurs composants peuvent également nécessiter des fonctionnalités de plate-forme d'API spécifiques pour l'intégration.
Le diagramme suivant montre comment Apigee et Apigee Hybrid sont conçus pour répondre à ces exigences avec une passerelle API localisée dans chaque environnement. La gestion de la plate-forme d'API est centralisée dans Google Cloud. Cette conception permet de mettre en œuvre des mesures de contrôle des accès strictes, où seules les adresses IP préapprouvées (API de destination et de cible ou adresses IP de point de terminaison Private Service Connect) peuvent communiquer entre Google Cloud et les autres environnements.
La liste suivante décrit les deux chemins de communication distincts du diagramme précédent qui utilisent la passerelle API Apigee:
- Les requêtes client arrivent directement dans l'environnement qui héberge l'application (ou le composant d'interface) à l'interface de l'application.
- Les passerelles API et les proxys de chaque environnement gèrent les requêtes d'API client et d'application dans différentes directions dans plusieurs environnements.
- La fonctionnalité API Gateway de Google Cloud(Apigee) expose les composants d'application (frontend ou backend) hébergés dans Google Cloud.
- La fonctionnalité de passerelle API dans un autre environnement (hybride) expose les composants de l'interface de l'application (ou du backend) hébergés dans cet environnement.
Vous pouvez également envisager d'utiliser un VPC de transit. Un VPC de transit peut offrir la flexibilité nécessaire pour séparer les problèmes et effectuer une inspection de sécurité et une connectivité hybride dans un réseau VPC distinct. Du point de vue de la joignabilité des adresses IP, un VPC de transit (où la connectivité hybride est associée) facilite les exigences suivantes pour maintenir la joignabilité de bout en bout:
- Les adresses IP des API cibles doivent être annoncées aux autres environnements où les clients/demandeurs sont hébergés.
- Les adresses IP des hôtes qui doivent communiquer avec les API cibles doivent être annoncées à l'environnement dans lequel se trouve l'API cible (par exemple, les adresses IP de l'appelant de l'API, le client). L'exception se produit lorsque la communication se produit via un équilibreur de charge, un proxy, un point de terminaison Private Service Connect ou une instance NAT.
Pour étendre la connectivité à l'environnement distant, cette conception utilise l'appairage VPC direct avec la fonctionnalité d'échange de routes client. La conception permet d'acheminer des requêtes API spécifiques provenant de charges de travail hébergées dans le VPC Google Cloud de l'application via le VPC de transit. Vous pouvez également utiliser un point de terminaison Private Service Connect dans le VPC de l'application associé à un équilibreur de charge avec un backend de groupe de points de terminaison réseau hybride dans le VPC de transit. Cette configuration est décrite dans la section suivante: Communication bidirectionnelle des API à l'aide de Private Service Connect.
Communication bidirectionnelle des API à l'aide de Private Service Connect
Il peut arriver que les entreprises n'aient pas besoin d'utiliser immédiatement une passerelle API (comme Apigee) ou qu'elles souhaitent l'ajouter plus tard. Toutefois, des exigences métier peuvent être nécessaires pour permettre la communication et l'intégration entre certaines applications dans différents environnements. Par exemple, si votre entreprise a racheté une autre entreprise, vous devrez peut-être exposer certaines applications à cette entreprise. Il se peut qu'elle ait besoin d'exposer des applications à votre entreprise. Les deux entreprises peuvent chacune avoir leurs propres charges de travail hébergées dans différents environnements (Google Cloud, sur site ou dans d'autres clouds) et doivent éviter les chevauchements d'adresses IP. Dans ce cas, vous pouvez utiliser Private Service Connect pour faciliter une communication efficace.
Pour les applications consommées en tant qu'API, vous pouvez également utiliser Private Service Connect pour fournir une adresse privée aux applications publiées, ce qui permet d'accéder de manière sécurisée au réseau privé dans les régions et via une connectivité hybride. Cette abstraction facilite l'intégration des ressources de divers clouds et environnements sur site via un modèle de connectivité hybride et multicloud. Elle permet également d'assembler des applications dans des environnements multicloud et sur site. Cela peut répondre à différentes exigences de communication, comme l'intégration d'applications sécurisées où une passerelle API n'est pas utilisée ou n'est pas prévue.
En utilisant Private Service Connect avec Cloud Load Balancing, comme illustré dans le schéma suivant, vous pouvez obtenir deux parcours de communication distincts. Chaque chemin est lancé à partir d'une direction différente pour un objectif de connectivité distinct, idéalement via des appels d'API.
- Toutes les considérations et recommandations de conception de Private Service Connect abordées dans ce guide s'appliquent à cette conception.
- Si une inspection de couche 7 supplémentaire est requise, vous pouvez intégrer des NVA à cette conception (au niveau du VPC de transit).
- Cette conception peut être utilisée avec ou sans passerelles API.
Les deux chemins de connectivité représentés dans le schéma précédent représentent des connexions indépendantes et n'illustrent pas la communication bidirectionnelle d'une seule connexion ou d'un seul flux.
Communication bidirectionnelle à l'aide de points de terminaison et d'interfaces Private Service Connect
Comme indiqué dans le modèle d'entrée contrôlée, l'une des options permettant d'activer la communication client-service consiste à utiliser un point de terminaison Private Service Connect pour exposer un service dans un VPC producteur à un VPC consommateur. Cette connectivité peut être étendue à un environnement sur site ou même à un autre environnement de fournisseur cloud via une connectivité hybride. Toutefois, dans certains cas, le service hébergé peut également nécessiter une communication privée.
Pour accéder à un service donné, comme récupérer des données à partir de sources de données pouvant être hébergées dans le VPC client ou en dehors de celui-ci, cette communication privée peut s'établir entre le VPC de l'application (producteur) et un environnement distant, tel qu'un environnement sur site.
Dans ce cas, les interfaces Private Service Connect permettent à une instance de VM de producteur de services d'accéder au réseau d'un client. Pour ce faire, il partage une interface réseau, tout en maintenant la séparation des rôles de producteur et de consommateur. Avec cette interface réseau dans le VPC consommateur, la VM de l'application peut accéder aux ressources du consommateur comme si elles résidaient localement dans le VPC producteur.
Une interface Private Service Connect est une interface réseau associée au VPC consommateur (de transit). Il est possible d'atteindre des destinations externes accessibles depuis le VPC client (de transit) auquel l'interface Private Service Connect est associée. Par conséquent, cette connexion peut être étendue à un environnement externe via une connectivité hybride, comme un environnement sur site, comme illustré dans le schéma suivant:
Si le VPC consommateur est une organisation ou une entité externe, comme une organisation tierce, vous ne pourrez généralement pas sécuriser la communication avec l'interface Private Service Connect dans le VPC consommateur. Dans ce cas, vous pouvez définir des règles de sécurité dans l'OS invité de la VM d'interface Private Service Connect. Pour en savoir plus, consultez la section Configurer la sécurité pour les interfaces Private Service Connect. Vous pouvez également envisager une autre approche si elle ne respecte pas les normes ou la conformité en matière de sécurité de votre organisation.
Bonnes pratiques
Dans les cas où les requêtes client provenant d'Internet doivent être reçues localement par une interface d'application hébergée dans un environnement cloud privé sur site ou autre environnement cloud, envisagez d'utiliser Hybrid comme solution de passerelle API.
- Cette approche facilite également la migration de la solution vers un environnement entièrement hébergé par Google Cloud, tout en préservant la cohérence de la plate-forme d'API (Apigee).
Pour minimiser la latence et optimiser les coûts des transferts de données sortants volumineux vers vos autres environnements lorsque ces environnements sont configurés en mode hybride ou multicloud à long terme ou de manière permanente, tenez compte des points suivants:
- Utilisez Cloud Interconnect ou Cross-Cloud Interconnect.
- Pour interrompre les connexions utilisateur au frontend ciblé dans l'environnement approprié, utilisez Hybrid.
Le cas échéant, utilisez Apigee Adapter for Envoy avec un déploiement hybride avec Kubernetes.
Avant de concevoir les chemins de connectivité et de routage, vous devez d'abord identifier le trafic ou les requêtes d'API à diriger vers une passerelle API locale ou distante, ainsi que les environnements source et de destination.
Utilisez VPC Service Controls pour protéger les services Google Cloud dans vos projets et limiter le risque d'exfiltration des données en spécifiant des périmètres de service au niveau du projet ou du réseau VPC.
- Vous pouvez é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.
Utilisez des règles de pare-feu de cloud privé virtuel (VPC) ou des stratégies de pare-feu pour contrôler l'accès au niveau du réseau aux ressources Private Service Connect via le point de terminaison Private Service Connect. Par exemple, les règles de pare-feu sortantes au niveau du VPC de l'application (client) peuvent restreindre l'accès des instances de VM à l'adresse IP ou au sous-réseau de vos points de terminaison.
Lorsque vous utilisez une interface Private Service Connect, vous devez protéger la communication avec l'interface en configurant la sécurité pour l'interface Private Service Connect.
Si une charge de travail dans un sous-réseau privé nécessite un accès à Internet, utilisez Cloud NAT pour éviter d'attribuer une adresse IP externe à la charge de travail et de l'exposer à l'Internet public.
- Pour le trafic Web sortant, utilisez le proxy Web sécurisé. Le proxy présente plusieurs avantages.
Consultez les bonnes pratiques générales pour les modèles de réseautage hybride et multicloud.
Modèles de transfert
Avec le modèle de transfert, l'architecture repose sur l'utilisation de services de stockage fournis parGoogle Cloudpour connecter un environnement IT privé à des projets dans Google Cloud. Ce modèle s'applique principalement aux configurations qui suivent le modèle d'architecture multicloud hybride d'analyse, selon lequel:
- Les charges de travail qui s'exécutent dans un environnement informatique privé ou dans un autre cloud importent les données dans des emplacements de stockage partagés. En fonction des cas d'utilisation, les importations peuvent s'effectuer de façon groupée ou par petits incréments.
- Les charges de travail hébergées parGoogle Cloudou d'autres services Google (services d'analyse de données et d'intelligence artificielle, par exemple) consomment les données des emplacements de stockage partagés et les traitent par flux ou par lots.
Architecture
Le diagramme suivant illustre une architecture de référence appliquant une topologie de transfert.
Le diagramme d'architecture précédent présente les workflows suivants:
- Du côté de Google Cloud , vous déployez les charges de travail dans un VPC d'application. Ces charges de travail peuvent inclure des applications de traitement de données, d'analyse et d'interface analytique.
- Pour exposer de manière sécurisée les applications d'interface aux utilisateurs, vous pouvez utiliser Cloud Load Balancing ou API Gateway.
- Un ensemble de buckets Cloud Storage ou de files d'attente Pub/Sub importe les données à partir de l'environnement informatique privé et les rend disponibles pour un traitement ultérieur par les charges de travail déployées dans Google Cloud. Les stratégies IAM (Identity and Access Management) vous permettent de limiter l'accès aux charges de travail validées.
- Utilisez VPC Service Controls pour limiter l'accès aux services et minimiser les risques d'exfiltration de données non justifiée provenant des services Google Cloud .
- Dans cette architecture, la communication avec les buckets Cloud Storage ou Pub/Sub s'effectue sur les réseaux publics ou via une connectivité privée à l'aide de VPN, de Cloud Interconnect ou de interconnexion cross-cloud. En règle générale, la décision de connecter des éléments dépend de plusieurs aspects, par exemple :
- Volume de trafic attendu
- S'il s'agit d'une configuration temporaire ou permanente
- Exigences de sécurité et de conformité
Variante
Les options de conception décrites dans le modèle d'entrée contrôlée, qui utilise des points de terminaison Private Service Connect pour les API Google, peuvent également être appliquées à ce modèle. Plus précisément, il permet d'accéder à Cloud Storage, BigQuery et d'autres API de services Google. Cette approche nécessite une adresse IP privée sur une connexion réseau hybride et multicloud, telle que VPN, Cloud Interconnect et interconnexion cross-cloud.
Bonnes pratiques
- Verrouillez l'accès aux buckets Cloud Storage et aux sujets Pub/Sub.
- Le cas échéant, utilisez des solutions de transfert de données intégrées et cloud first, comme la Google Cloud suite de solutions. Pour répondre aux besoins de votre cas d'utilisation, ces solutions sont conçues pour déplacer, intégrer et transformer efficacement les données.
Évaluez les différents facteurs qui influencent les options de transfert de données, tels que le coût, le temps de transfert prévu et la sécurité. Pour en savoir plus, consultez la section Évaluer vos options de transfert.
Pour réduire la latence et éviter de transférer et de déplacer de grandes quantités de données sur Internet, envisagez d'utiliser Cloud Interconnect ou interconnexion cross-cloud, y compris pour accéder aux points de terminaison Private Service Connect dans votre cloud privé virtuel pour les API Google.
Pour protéger les services Google Cloud dans vos projets et limiter le risque d'exfiltration de données, utilisez VPC Service Controls. Ces contrôles de service peuvent spécifier des périmètres de service au niveau du projet ou du réseau VPC.
- Vous pouvez é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.
Communiquez avec des charges de travail d'analyse de données publiées publiquement et hébergées sur des instances de VM via une passerelle API, un équilibreur de charge ou une appliance de réseau virtuel. Utilisez l'une de ces méthodes de communication pour renforcer la sécurité et éviter de rendre ces instances directement accessibles depuis Internet.
Si un accès à Internet est nécessaire, Cloud NAT peut être utilisé dans le même VPC pour gérer le trafic sortant des instances vers l'Internet public.
Consultez les bonnes pratiques générales pour les topologies de réseaux hybrides et multicloud.
Bonnes pratiques générales
Lorsque vous concevez et intégrez des identités cloud, la hiérarchie des ressources et les réseaux de zones de destination, tenez compte des recommandations de conception de la page Conception des zones de destination dans Google Cloud et des bonnes pratiques de sécurité Google Cloud traitées dans le plan de base de l'entreprise. Vérifiez que la conception que vous avez sélectionnée est conforme aux documents suivants:
- Bonnes pratiques et architectures de référence pour la conception de VPC
- Choisir une hiérarchie de ressources pour votre Google Cloud zone de destination
- Google Cloud Framework d'architecture: sécurité, confidentialité et conformité
Tenez également compte des bonnes pratiques générales suivantes:
Lorsque vous choisissez une option de connectivité réseau hybride ou multicloud, tenez compte des exigences métier et applicatives telles que les contrats de niveau de service, les performances, la sécurité, les coûts, la fiabilité et la bande passante. Pour en savoir plus, consultez les pages Choisir un produit de connectivité réseau et Modèles pour la connexion d'autres fournisseurs de services cloud avec Google Cloud.
Utilisez des VPC partagés sur Google Cloud au lieu de plusieurs VPC lorsque cela est approprié et conforme aux exigences de votre conception de hiérarchie des ressources. Pour en savoir plus, consultez la section Choisir de créer ou non plusieurs réseaux VPC.
Suivez les bonnes pratiques de planification des comptes et des entreprises.
Le cas échéant, établissez une identité commune entre les environnements afin que les systèmes puissent s'authentifier de manière sécurisée dans les limites de l'environnement.
Pour exposer en toute sécurité les applications aux utilisateurs d'entreprise dans une configuration hybride et pour choisir l'approche la mieux adaptée à vos besoins, suivez la méthode recommandée pour intégrer Google Cloud à votre système de gestion des identités.
- Consultez également la section Modèles pour authentifier les utilisateurs d'entreprise dans un environnement hybride.
Lorsque vous concevez vos environnements sur site et cloud, tenez compte de l'adressage IPv6 dès le départ et identifiez les services qui le prennent en charge. Pour en savoir plus, consultez la page Présentation de l'IPv6 sur Google Cloud. Cette section récapitule les services compatibles lors de la rédaction du blog.
Lorsque vous concevez, déployez et gérez vos règles de pare-feu VPC, vous pouvez:
- Utiliser le filtrage basé sur les comptes de service plutôt que le filtrage basé sur les tags réseau si vous avez besoin d'un contrôle strict sur la manière dont les règles de pare-feu sont appliquées aux VM.
- Utiliser des stratégies de pare-feu lorsque vous regroupez plusieurs règles de pare-feu afin de pouvoir les mettre à jour toutes en même temps. Vous pouvez également rendre la stratégie hiérarchique. Pour en savoir plus sur les spécifications des stratégies de pare-feu hiérarchiques, consultez la page Stratégies de pare-feu hiérarchiques.
- Utilisez des objets de géolocalisation dans la stratégie de pare-feu lorsque vous devez filtrer le trafic IPv4 et IPv6 externe en fonction d'emplacements géographiques ou de régions spécifiques.
- Utilisez Threat Intelligence pour les règles de stratégie de pare-feu si vous devez sécuriser votre réseau en autorisant ou en bloquant le trafic en fonction de données Threat Intelligence, telles que les adresses IP malveillantes connues ou les plages d'adresses IP du cloud public. Par exemple, vous pouvez autoriser le trafic à partir de plages d'adresses IP de cloud public spécifiques si vos services doivent communiquer avec ce cloud public uniquement. Pour en savoir plus, consultez la section Bonnes pratiques pour les règles de pare-feu.
Vous devez toujours concevoir la sécurité de votre cloud et de votre réseau en appliquant une approche multicouche en tenant compte de couches de sécurité supplémentaires, comme les suivantes:
- Google Cloud Armor
- Cloud Intrusion Detection System
- IPS Cloud Next Generation Firewall
- Threat Intelligence pour les règles de stratégie de pare-feu
Ces couches supplémentaires peuvent vous aider à filtrer, inspecter et surveiller un large éventail de menaces au niveau des couches réseau et application à des fins d'analyse et de prévention.
Afin de décider du cadre d'exécution de la résolution DNS dans une configuration hybride, nous vous conseillons de mettre en place deux systèmes DNS faisant autorité pour votre environnementGoogle Cloud privé et pour vos ressources sur site hébergées par des serveurs DNS existants dans votre environnement sur site. Pour en savoir plus, consultez la section Choisir où la résolution DNS est effectuée.
Dans la mesure du possible, exposez toujours les applications via des API à l'aide d'un équilibreur de charge ou d'une passerelle d'API. Nous vous recommandons d'envisager une plate-forme d'API comme Apigee. Apigee sert d'abstraction ou de façade pour vos API de service de backend, associées à des fonctionnalités de sécurité, une limitation du débit, des quotas et des analyses.
Une plate-forme d'API (passerelle ou proxy) et un équilibreur de charge d'application ne s'excluent pas mutuellement. Parfois, l'utilisation conjointe de passerelles d'API et d'équilibreurs de charge peut fournir une solution plus robuste et sécurisée pour gérer et distribuer le trafic des API à grande échelle. Les passerelles API Cloud Load Balancing vous permettent d'effectuer les opérations suivantes:
Fournir des API hautes performances avec Apigee et Cloud CDN pour :
- Réduire la latence
- Héberger des API à l'échelle mondiale
Augmenter la disponibilité pendant les périodes de pic de trafic
Pour en savoir plus, regardez la vidéo Fournir des API hautes performances avec Apigee et Cloud CDN sur YouTube.
Implémenter une gestion avancée du trafic.
Utiliser Google Cloud Armor comme service de protection contre les attaques DDoS, de WAF et de sécurité réseau afin de protéger vos API.
Gérez un équilibrage de charge efficace sur les passerelles de plusieurs régions. Pour en savoir plus, regardez la vidéo Sécuriser les API et mettre en œuvre le basculement multirégional avec PSC et Apigee.
Pour déterminer le produit Cloud Load Balancing à utiliser, vous devez d'abord déterminer le type de trafic que vos équilibreurs de charge doivent gérer. Pour en savoir plus, consultez la page Choisir un équilibreur de charge.
Lorsque vous utilisez Cloud Load Balancing, vous devez exploiter ses fonctionnalités d'optimisation de la capacité des applications le cas échéant. Cela peut vous aider à résoudre certains des problèmes de capacité pouvant survenir dans les applications distribuées dans le monde entier.
- Pour une analyse approfondie de la latence, consultez la section Optimiser la latence des applications avec l'équilibrage de charge.
Alors que Cloud VPN chiffre le trafic entre les environnements, avec Cloud Interconnect, vous devez utiliser MACsec ou le VPN haute disponibilité via Cloud Interconnect pour chiffrer le trafic en transit au niveau de la couche de connectivité. Pour en savoir plus, consultez la section Comment chiffrer le trafic sur Cloud Interconnect ?
- Vous pouvez également envisager le chiffrement de la couche de service à l'aide de TLS. Pour en savoir plus, consultez la section Décider comment répondre aux exigences de conformité concernant le chiffrement en transit.
Si vous avez besoin d'un volume de trafic sur une connectivité hybride VPN supérieur à celui qu'un seul tunnel VPN peut prendre en charge, vous pouvez envisager d'utiliser l'option de routage VPN haute disponibilité actif/actif.
- Pour les configurations hybrides ou multicloud à long terme avec des volumes de transfert de données sortants élevés, envisagez Cloud Interconnect ou interconnexion cross-cloud. Ces options de connectivité permettent d'optimiser les performances de connectivité et peuvent réduire les frais de transfert de données sortantes pour le trafic qui répond à certaines conditions. Pour en savoir plus, consultez la section sur les tarifs de Cloud Interconnect.
Lorsque vous vous connectez aux ressources Google Cloud et que vous devez choisir entre Cloud Interconnect, l'appairage direct ou l'appairage opérateur, nous vous recommandons d'utiliser Cloud Interconnect, sauf si vous devez accéder aux applications Google Workspace. Pour en savoir plus, vous pouvez comparer les caractéristiques de l'appairage direct avec Cloud Interconnect et de l'appairage opérateur avec Cloud Interconnect.
Prévoyez suffisamment d'espace d'adressage IP à partir de votre espace d'adressage IP RFC 1918 existant pour accueillir vos systèmes hébergés dans le cloud.
Si des restrictions techniques vous obligent à conserver votre plage d'adresses IP, vous pouvez:
Utiliser les mêmes adresses IP internes pour vos charges de travail sur site lors de leur migration vers Google Cloud, à l'aide de sous-réseaux hybrides.
Provisionner et utiliser vos propres adresses IPv4 publiques pour les ressourcesGoogle Cloud à l'aide de l'option BYOIP (Bring your own IP) de Google.
Si la conception de votre solution nécessite l'exposition d'une application basée surGoogle Cloudà l'Internet public, tenez compte des recommandations de conception abordées dans Mise en réseau pour la diffusion d'applications Web.
Le cas échéant, utilisez des points de terminaison Private Service Connect pour autoriser les charges de travail dans Google Cloud, sur site ou dans un autre environnement cloud avec une connectivité hybride à accéder de manière privée aux API Google ou aux services publiés, à l'aide d'adresses IP internes de manière précise.
Lorsque vous utilisez Private Service Connect, vous devez contrôler les éléments suivants:
- Personnes autorisées à déployer des ressources Private Service Connect
- Si des connexions peuvent être établies ou non entre les consommateurs et les producteurs.
- Le trafic réseau autorisé à accéder à ces connexions.
Pour en savoir plus, consultez Points de terminaison Private Service Connect.
Pour obtenir une configuration cloud robuste dans le contexte d'une architecture hybride et multicloud:
- Effectuez une évaluation complète des niveaux de fiabilité requis des différentes applications dans les différents environnements. Cela peut vous aider à atteindre vos objectifs de disponibilité et de résilience.
- Comprendre les fonctionnalités de fiabilité et les principes de conception de votre fournisseur de services cloud Pour en savoir plus, consultez la section Fiabilité de l'infrastructureGoogle Cloud .
La visibilité et la surveillance du réseau cloud sont essentielles pour assurer des communications fiables. Network Intelligence Center fournit une console unique permettant de gérer la visibilité, la surveillance et le dépannage du réseau.
Modèles d'architecture réseau sécurisée hybride et multicloud: que nous réserve l'avenir ?
- Découvrez les modèles d'architecture courants que vous pouvez appliquer à l'aide des modèles de mise en réseau décrits dans ce document.
- Découvrez comment aborder les technologies hybrides et multicloud et sélectionner les charges de travail appropriées.
- Découvrez Google Cloud Cross-Cloud Network, une plate-forme réseau mondiale ouverte, sécurisée et optimisée pour les applications et les utilisateurs, aussi bien sur site que dans d'autres clouds.
- Concevoir une infrastructure fiable pour vos charges de travail dans Google Cloud : obtenez des conseils pour protéger vos applications contre les défaillances au niveau des ressources, des zones et des régions.
- Pour en savoir plus sur la conception d'architectures disponibilité élevée dansGoogle Cloud, consultez les modèles d'applications résilientes et évolutives.
- Découvrez les options de connectivité possibles pour connecter un cluster GKE Enterprise exécuté dans votre environnement sur site/périphérique au réseau, ainsi que l'impact d'une déconnexion temporaire de Google Cloud. Google Cloud