Modèles d'architecture réseau sécurisée hybride et multicloud

Last reviewed 2025-01-23 UTC

Cette page offre une vue d'une seule page de toutes les pages dans Créer des architectures hybrides et multicloud à l'aide de Google Cloud. Vous pouvez imprimer cette page ou l'enregistrer au format PDF à l'aide de la fonction d'impression de votre navigateur et en sélectionnant l'option Enregistrer en tant que PDF. Cette page ne fournit pas de volet de table des matières sur la droite.

Il s'agit du troisième d'une série de trois documents. Il aborde les modèles d'architecture de mise en 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 fournit 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 parties suivantes :

• Créez des architectures hybrides et multicloud : explique comment planifier une stratégie pour concevoir 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 : décrit les modèles d'architecture réseau 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. La connectivité réseau hybride et le modèle d'architecture réseau cloud que vous choisissez pour une configuration hybride et multicloud doivent répondre aux exigences particulières des charges de travail de votre entreprise. Elle doit également convenir aux modèles d'architecture que vous comptez appliquer. Bien que vous deviez peut-être adapter chaque conception, il existe des modèles courants que vous pouvez utiliser comme plan.

Les modèles d'architecture réseau de ce document ne doivent pas être considérés comme des alternatives à la conception de la zone de destination dans Google Cloud. Au lieu de cela, vous devez concevoir et déployer les modèles d'architecture que vous sélectionnez dans le cadre de la conception globale de la zone de destination Google Cloud , qui couvre les domaines suivants :

• Identités
• Gestion des ressources
• Sécurité
• Mise en réseau
• Surveillance

Différentes applications peuvent utiliser différents schémas d'architecture réseau, qui sont intégrés à l'architecture de la zone d'atterrissage. Dans une configuration multicloud, vous devez maintenir la cohérence de la conception de la zone d'atterrissage dans tous les environnements.

Cette série contient les pages suivantes :

• Éléments de conception
• Modèles d'architecture
  • Modèle mis en miroir
  • Modèle maillé
  • Modèles contrôlés
    • Sortie contrôlée
    • Entrée contrôlée
    • Sortie et entrée contrôlées
  • Transfert
• Bonnes pratiques générales

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 des solutions 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 d'atterrissage 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 abordent également les différentes variantes de conception qui peuvent ê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
• Modèle maillé
• Modèles contrôlés
  • Sortie contrôlée
  • Entrée contrôlée
  • Sortie et entrée contrôlées
• Modèle de transfert

Modèle mis en miroir

Le modèle mirrored (en miroir) repose sur la réplication de la conception d'un ou de plusieurs environnements existants dans un ou plusieurs nouveaux environnements. 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 en 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 continu (CI/CD) permet de déployer et de gérer les charges de travail dans tous les environnements informatiques ou dans des environnements spécifiques.
• La surveillance, la gestion de la configuration et les autres systèmes administratifs doivent fonctionner dans tous les 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:

L'architecture du diagramme précédent est décrite comme suit :

• Les charges de travail sont distribuées en fonction des environnements fonctionnels (développement, test, CI/CD et outils administratifs) dans des VPC distincts sur le 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 administratifs. 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 les communications 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 de calcul privé.
• Les règles de pare-feu n'autorisent que le trafic autorisé.
  • Vous pouvez également utiliser Cloud Firewall nouvelle génération Enterprise avec le service de prévention des intrusions (IPS) pour effectuer une inspection approfondie des paquets afin de prévenir les menaces sans modifier la conception ni le routage. Cloud Next Generation Firewall Enterprise fonctionne en créant 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 dans 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 en utilisant l'une des options de connectivité réseau hybride et multicloud qui répondent aux exigences de votre entreprise et de vos applications. Pour vous permettre de déployer et de gérer les charges de travail de production, cette connexion fournit une accessibilité au réseau privé entre les différents environnements de calcul. 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 outils et les fonctionnalités Google Cloud 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. La mise en réseau VPC et ses fonctionnalités de sécurité peuvent être provisionnées et gérées par les équipes d'opérations réseau en fonction des structures possibles suivantes :

• Une é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 variante 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 en miroir 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 la couche application

Dans certains scénarios, les exigences de sécurité peuvent nécessiter l'examen de la couche application (couche 7) et de l'inspection approfondie des paquets avec des mécanismes de pare-feu avancés qui dépassent les capacités du pare-feu Cloud nouvelle génération. Pour répondre aux exigences et aux 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 l'appliance virtuelle réseau dans le chemin réseau entre le cloud privé virtuel et l'environnement de calcul 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, la NVA sert de couche de sécurité du périmètre. Elle sert également de base pour activer l'inspection du trafic en ligne et appliquer des règles strictes de contrôle des accès.

Pour une stratégie de sécurité multicouche robuste incluant des règles de pare-feu VPC et des fonctionnalités de service de prévention des intrusions, incluez une inspection du trafic et un contrôle de sécurité supplémentaires pour les flux de trafic est-ouest et nord-sud.

Remarque : Dans les régions cloud compatibles et lorsque cela est techniquement possible pour votre conception, les NVA peuvent être déployées sans nécessiter plusieurs réseaux VPC ni interfaces d'appliance. Ce déploiement repose sur l'utilisation de l'équilibrage de charge et des fonctionnalités de routage basé sur des règles. Ces fonctionnalités permettent un mécanisme indépendant de la topologie et basé sur des règles pour intégrer des NVA à votre réseau cloud. Pour en savoir plus, consultez Déployer des appliances virtuelles réseau (NVA) sans plusieurs VPC.

Topologie en étoile

Une autre variante de conception possible 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 administratifs et les fonctions dans chaque environnement. Le modèle de communication en étoile 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, CI/CD ou l'authentification.
• Un ensemble commun de règles de sécurité doit être appliqué au trafic entrant et sortant de manière centralisée 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 entre les VPC et la connectivité hybride passent toutes par le VPC hub. Dans ce modèle, vous pouvez contrôler et restreindre la communication au niveau du VPC du hub pour l'adapter à vos exigences de connectivité.

Dans l'architecture réseau en étoile, les principales options de connectivité (entre les VPC spokes et hub) sur Google Cloudsont les suivantes :

• Appairage de réseaux VPC
• VPN
• Utiliser un dispositif virtuel de réseau (NVA)
  • Avec plusieurs interfaces réseau
  • Avec Network Connectivity Center (NCC)

Pour savoir quelle option envisager dans votre conception, consultez 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 provenant 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 pour séparer 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 répondre à certaines exigences de sécurité.

Il ne suffit pas de répondre aux exigences de sécurité des architectures de microservices distribuées actuelles axées sur le cloud. Vous devez également tenir compte des architectures distribuées Zero Trust. 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 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 maillage de services, les services peuvent valider efficacement les appelants et implémenter des règles de contrôle d'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 couvrant à la fois vos déploiementsGoogle Cloud et sur site. Le maillage utilise des règles d'autorisation pour sécuriser les communications de service à service.

Vous pouvez également intégrer Apigee Adapter for Envoy à cette architecture. Il s'agit d'un déploiement léger de passerelle API Apigee dans un cluster Kubernetes. Apigee Adapter for Envoy est un proxy de service et de périphérie Open Source conçu pour les applications cloud.

Pour en savoir plus sur ce sujet, consultez les articles suivants :

• Architecture distribuée zéro confiance
• Environnement hybride GKE Enterprise
• Se connecter à Google
  • Connectez un cluster GKE Enterprise sur site à un réseauGoogle Cloud .
• Configurer un maillage multicloud ou hybride
  • Déployez Cloud Service Mesh dans des environnements et des clusters.

Bonnes pratiques concernant les motifs en miroir

• Les systèmes CI/CD requis pour déployer ou reconfigurer les 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é du système attendu. Pour en savoir plus, consultez Fiabilité de l'infrastructureGoogle Cloud .
• Pour éliminer les erreurs de configuration pour les processus répétés tels que les mises à jour de code, l'automatisation est essentielle pour standardiser vos compilations, vos tests et vos déploiements.
• L'intégration de NVA centralisées dans cette conception peut nécessiter l'incorporation de plusieurs segments avec différents niveaux de contrôles d'accès à la 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 consignes de conception et d'implémentation de la haute disponibilité et de la redondance fournies par votre fournisseur 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 É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 Ingress contrôlé dans 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 maillé repose sur l'établissement d'une architecture réseau hybride. Cette architecture s'étend sur plusieurs environnements de calcul. Dans ces environnements, tous les systèmes peuvent communiquer entre eux et ne sont pas limités à une communication unidirectionnelle en fonction des exigences de sécurité de vos applications. Ce modèle de réseau s'applique principalement aux architectures hybrides par tranche, multicloud partitionnées ou d'utilisation intensive. Il s'applique également à la conception de la continuité des opérations pour provisionner un environnement de reprise après sinistre dans Google Cloud. Dans tous les cas, vous devez connecter les environnements informatiques de manière à répondre aux exigences de communication suivantes :

• Les charges de travail peuvent communiquer entre elles au-delà des limites de leur environnement en utilisant des adresses IP privées RFC 1918.
• La communication peut être initiée par l'une ou l'autre des parties. Les spécificités du modèle de communication peuvent varier en fonction des applications et des exigences de sécurité, comme les modèles de communication abordés dans les options de conception suivantes.
• Les règles de pare-feu que vous utilisez doivent autoriser le trafic entre des sources et des destinations d'adresses IP spécifiques en fonction des exigences de l'application ou des applications pour lesquelles le modèle est conçu. Dans l'idéal, vous pouvez utiliser une approche de sécurité multicouche pour filtrer avec précision les flux de trafic internes et entre les différents environnements informatiques.

Architecture

Le diagramme suivant illustre une architecture de référence de haut niveau du modèle maillé.

• Tous les environnements doivent utiliser un espace d'adressage IP RFC 1918 sans chevauchement.
• Du côté de Google Cloud , vous pouvez déployer des charges de travail dans un ou plusieurs VPC partagés ou non partagés. Pour d'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 projets et des ressources de votre organisation.
• Le réseau VPC de Google Cloud s'étend à d'autres environnements informatiques. Ces environnements peuvent être sur site ou dans un autre cloud. Utilisez l'une des options de connectivité réseau hybride et multicloud qui répondent aux exigences de votre entreprise et de votre application.

• Limitez les communications aux adresses IP autorisées de vos sources et destinations. Utilisez l'une des fonctionnalités suivantes ou une combinaison de celles-ci :

  • Règles de pare-feu ou stratégies de pare-feu

  • Dispositif virtuel de réseau (NVA) avec des capacités d'inspection de pare-feu nouvelle génération (NGFW), placé dans le chemin réseau.

  • Cloud Next Generation Firewall Enterprise avec service de prévention des intrusions (IPS) pour implémenter l'inspection approfondie des paquets pour la prévention des menaces sans modifier la conception ni le routage du réseau.

Variantes

Le modèle d'architecture maillé peut être combiné à d'autres approches pour répondre à différentes exigences de conception, tout en tenant compte des exigences de communication du modèle. Les options de modèle sont décrites dans les sections suivantes :

• Un VPC par environnement
• Utiliser un pare-feu centralisé de couche application
• Architecture distribuée zéro confiance pour les microservices

Un VPC par environnement

Voici les principales raisons d'envisager l'option d'un VPC par environnement :

• L'environnement cloud nécessite une séparation au niveau du réseau des réseaux et ressources VPC, conformément à la conception de la hiérarchie des ressources de votre organisation. Si la séparation des domaines administratifs est requise, elle peut également être combinée avec un projet distinct par environnement.
  • Pour gérer de manière centralisée les ressources réseau dans un réseau commun et assurer l'isolation du réseau entre les différents environnements, utilisez un VPC partagé pour chaque environnement que vous avez dans Google Cloud, comme le développement, les tests et la production.
• Exigences de mise à l'échelle qui peuvent nécessiter de dépasser les quotas de VPC pour un seul VPC ou projet.

Comme illustré dans le diagramme suivant, la conception "un VPC par environnement" permet à chaque VPC de s'intégrer directement à l'environnement sur site ou à d'autres environnements cloud à l'aide de VPN ou d'une interconnexion Cloud Interconnect avec plusieurs rattachements de VLAN.

Le modèle affiché dans le schéma précédent peut être appliqué à une topologie de réseau hub-and-spoke de zone de destination. Dans cette topologie, une ou plusieurs connexions hybrides peuvent être partagées avec tous les VPC spokes. Elle est partagée à l'aide d'un VPC de transit pour mettre fin à la connectivité hybride et aux autres VPC spoke. Vous pouvez également étendre cette conception en ajoutant des NVA avec des fonctionnalités d'inspection de pare-feu nouvelle génération (NGFW) au VPC de transit, comme décrit dans la section suivante "Utiliser un pare-feu de couche application centralisé".

Utiliser un pare-feu centralisé de couche application

Si vos exigences techniques vous obligent à envisager l'inspection de la couche application (couche 7) et des paquets en profondeur avec des fonctionnalités de pare-feu avancées qui dépassent les capacités de Cloud Next Generation Firewall, vous pouvez utiliser un dispositif NGFW hébergé dans une NVA. Toutefois, cette appliance virtuelle de réseau doit répondre aux besoins de sécurité de votre organisation. Pour ce faire, étendez la topologie de manière à faire transiter tout le trafic interenvironnement par un pare-feu NVA centralisé, comme illustré dans le diagramme suivant.

Vous pouvez appliquer le modèle dans le schéma suivant sur la conception de la zone de destination à l'aide d'une topologie hub-and-spoke avec des appareils centraliss:

Comme le montre le schéma précédent, l'appliance virtuelle réseau (NVA) sert de couche de sécurité du périmètre et constitue la base pour activer l'inspection du trafic en ligne. Il applique également des règles strictes de contrôle des accès. Pour inspecter les flux de trafic est-ouest et nord-sud, la conception d'une NVA centralisée peut inclure plusieurs segments avec différents niveaux de contrôles d'accès de sécurité.

Architecture distribuée zéro confiance pour les microservices

Lorsque des applications conteneurisées sont utilisées, l'architecture distribuée de microservices zéro confiance décrite dans la section Modèle en miroir s'applique également à ce modèle d'architecture.

La principale différence entre ce modèle et le modèle en miroir est que le modèle de communication entre les charges de travail dans Google Cloud et d'autres environnements peut être initié de part et d'autre. Le trafic doit être contrôlé et précis, en fonction des exigences des applications et de sécurité, en utilisant le maillage de services.

Bonnes pratiques concernant le modèle maillé

• Avant toute chose, déterminez la conception de la hiérarchie des ressources, ainsi que la conception requise pour tout projet et tout VPC. Cela peut vous aider à sélectionner l'architecture réseau optimale qui correspond à la structure de vos projets Google Cloud .
• Utilisez une architecture distribuée Zero Trust lorsque vous utilisez Kubernetes dans votre environnement informatique privé etGoogle Cloud.
• Lorsque vous utilisez des NVA centralisées dans votre conception, vous devez définir plusieurs segments avec différents niveaux de contrôles d'accès à la sécurité et de règles d'inspection du trafic. Basez ces contrôles et règles sur les exigences de sécurité de vos applications.
• Lorsque vous concevez une solution qui inclut des NVA, il est important de prendre en compte la haute disponibilité (HD) des NVA pour éviter un point de défaillance unique qui pourrait bloquer toute communication. Suivez les consignes de conception et d'implémentation de la haute disponibilité et de la redondance fournies par le fournisseur de sécuritéGoogle Cloud qui fournit vos NVA.
• Pour renforcer la confidentialité et l'intégrité des données, et pour bénéficier d'un modèle de communication contrôlé, exposez les applications via des API à l'aide de passerelles API, comme Apigee et Apigee hybrid avec mTLS de bout en bout. Vous pouvez également utiliser un VPC partagé avec Apigee dans la même ressource organization.
• Si la conception de votre solution nécessite l'exposition d'une application basée sur Google Cloud à l'Internet public, tenez compte des recommandations de conception abordées dans Mise en réseau pour la diffusion d'applications Web.
• Pour protéger les services Google Cloud dans vos projets et limiter le risque d'exfiltration de données, utilisez VPC Service Controls pour spécifier des périmètres de service au niveau du projet ou du réseau VPC. Vous pouvez également étendre les périmètres de service à un environnement hybride via une connexion VPN ou Cloud Interconnect autorisée. Pour en savoir plus sur les avantages des périmètres de service, consultez la page Présentation de VPC Service Controls.
• Consultez les bonnes pratiques générales pour les modèles de réseaux hybrides et multicloud.

Si vous souhaitez renforcer l'isolement et contrôler plus précisément l'accès entre vos applications hébergées dans Google Cloudet dans d'autres environnements, envisagez d'utiliser l'un des modèles contrôlés décrits dans les autres documents de cette série.

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 classe ce modèle en trois options possibles, chacune étant déterminée par le modèle de communication spécifique :

• Sortie contrôlée

• Entrée contrôlée

• Sortie et entrée contrôlées (contrôle bidirectionnel 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 aux exigences variées. Pour répondre aux besoins spécifiques de différentes applications, l'architecture de votre zone d'atterrissage principale peut intégrer un ou plusieurs 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é.

Remarque : En général, le modèle gated peut être appliqué ou intégré à l'option de conception de la landing zone qui expose les services dans un modèle producteur-consommateur.

Cette série aborde chaque modèle avec accès limité et ses options de conception possibles. Toutefois, une option de conception courante applicable à tous les modèles avec accès contrôlé est l'architecture distribuée Zero Trust pour les applications conteneurisées avec architecture de microservices. Cette option est optimisée 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. Cette architecture contrôle les communications sécurisées de service à service autorisées et le sens 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 contrôlés 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 l'utilisateur accède, au modèle de communication et aux exigences de sécurité. Si les exigences de sécurité nécessitent une inspection approfondie des paquets et de la 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 qui peuvent répondre à vos exigences de sécurité. L'intégration d'appliances virtuelles réseau (NVA) à ces modèles contrôlé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 des accès distincts.

Sortie contrôlée

L'architecture du modèle de mise en réseau sortie contrôlée repose sur l'exposition d'une sélection d'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, 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 dans un réseau interne, la mise en réseau avec sortie contrôlée permet de maintenir un niveau de sécurité plus élevé dans votre environnement informatique sur site. Le modèle exige que vous connectiez les environnements de calcul 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 informatique privé ne sont pas accessibles directement à partir de 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 sur 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 d'adresses IP configuré pour n'autoriser la communication qu'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 Bonnes pratiques pour sécuriser vos applications et vos API avec Apigee.

Architecture

Le diagramme suivant illustre une architecture de référence qui répond aux exigences de communication listées dans la section précédente :

Les données transitent par le diagramme précédent de la manière suivante :

• Du côté de Google Cloud , vous pouvez déployer des charges de travail dans des clouds privés virtuels (VPC). Il peut s'agir d'un ou de plusieurs VPC (partagés ou non). Le déploiement doit être conforme à la conception de la hiérarchie des projets et des ressources de votre organisation.
• Les réseaux VPC de l'environnement Google Cloud sont étendus aux autres environnements de calcul. 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 de VPC spécifiques et destiné à des passerelles ou des équilibreurs de charge à distance, utilisez le filtrage par liste d'adresses IP autorisées. 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 adresses IP sources et de destination autorisées :

  • Règles de pare-feu ou stratégies de pare-feu

  • Dispositif virtuel de réseau (NVA) avec des capacités d'inspection de pare-feu nouvelle génération (NGFW) placé dans le chemin réseau.

  • Cloud Next Generation Firewall Enterprise avec service de prévention des intrusions (IPS) pour implémenter l'inspection approfondie des paquets pour la prévention des menaces.

• Tous les environnements partagent un espace d'adressage IP RFC 1918 sans chevauchement.

Variantes

Le modèle d'architecture de 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 Google Cloud et l'interface globale
• Exposer des services à distance à 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 résident dansGoogle Cloud. Comme le montre 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 pour 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 la vitesse 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 aident à fournir des API hautes performances lorsque vous utilisez Apigee avec Cloud CDN pour effectuer les opérations suivantes, 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.
• Augmentez la disponibilité pour les pics de trafic.

L'exemple de conception illustré dans le schéma précédent est basé sur Private Service Connect sans appairage de VPC.

Dans cette conception, le réseau Northbound est établi par :

• Un équilibreur de charge (EL dans le schéma), 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 du runtime Apigee) à l'aide de groupes de points de terminaison du réseau (NEG) Private Service Connect.

La mise en réseau southbound est établie par le biais des éléments suivants :

• Point de terminaison Private Service Connect qui référence un rattachement de service associé à un équilibreur de charge interne (ILB dans le schéma) dans le VPC du client.

• L'équilibreur de charge interne 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.

Remarque : Selon vos besoins, les API des backends sur site peuvent être exposées via Apigee Hybrid, une passerelle ou un proxy d'API tiers, ou un équilibreur de charge.

Exposer des services à distance à l'aide de Private Service Connect

Utilisez l'option Private Service Connect pour exposer des services à distance 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 êtes soumis à des restrictions de sécurité ou à des exigences de conformité.
  • Vos plages d'adresses IP se chevauchent, par exemple dans le cas d'une fusion ou d'une acquisition.
• Pour activer les communications unidirectionnelles sécurisées entre les clients, les applications et les services dans les environnements, même lorsque vous avez un délai court.
• Vous devrez peut-être fournir une connectivité à plusieurs VPC de clients via un VPC de producteur de services (VPC de transit) pour proposer des modèles de services mutualisés ou à locataire unique très évolutifs, afin d'accéder aux services publiés dans d'autres environnements.

L'utilisation de Private Service Connect pour les applications consommées en tant qu'API fournit une adresse IP interne pour les applications publiées, ce qui permet un accès sécurisé au sein du réseau privé dans les régions et via la connectivité hybride. Cette abstraction facilite l'intégration de ressources provenant de différents clouds et environnements sur site via un modèle de connectivité hybride et multicloud. Vous pouvez accélérer l'intégration d'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 en utilisant 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 accéder aux 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 à un VPC de transit.

Dans 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 mutualisés où votre service est utilisé par plusieurs VPC de clients, même si leurs plages d'adresses IP se chevauchent.

Le chevauchement d'adresses IP est l'un des problèmes les plus courants lors de l'intégration d'applications résidant 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 nécessiter le provisionnement ni la gestion de composants réseau supplémentaires, tels que Cloud NAT ou une NVA, pour effectuer la traduction d'adresse 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 gestion complexe à 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 ultérieurement pour intégrer Apigee en tant que plate-forme d'API à l'aide des options de conception 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. Lorsque des ressources hébergées dans d'autres régions accèdent à un point de terminaison Private Service Connect, des frais de sortie interrégionaux s'appliquent au trafic destiné aux points de terminaison avec accès mondial.

Remarque : Pour effectuer des vérifications d'état distribuées et faciliter la connexion de plusieurs VPC à des environnements sur site via plusieurs connexions hybrides, associez un équilibreur de charge d'application interne à un équilibreur de charge d'application externe. Pour en savoir plus, consultez Chaining explicite des équilibreurs de charge de couche 7 avec PSC

. Google Cloud

Bonnes pratiques

• L'utilisation d'Apigee et d'Apigee Hybrid comme solution de plate-forme d'API offre 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 besoins et de l'architecture.
• La conception des VPC et des projets dans Google Cloud doit être basée sur votre hiérarchie de ressources et vos exigences en matière de modèle de communication sécurisée.
• Lorsque vous utilisez des API avec des passerelles d'API, vous devez également utiliser une liste d'adresses IP autorisées. Une liste d'autorisation limite les communications aux adresses IP sources et de destination spécifiques des consommateurs d'API et des passerelles d'API qui peuvent ê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 menaces de sécurité DDoS et de couche d'application.

• Si les instances ont besoin d'accéder à Internet, utilisez Cloud NAT dans le VPC de l'application (consommateur) pour permettre aux charges de travail d'accéder à Internet. Cela vous permet d'éviter 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éseaux hybrides et multicloud.

Entrée contrôlée

L'architecture du modèle d'entrée contrôlée repose sur l'exposition d'une sélection d'API de charges de travail s'exécutant 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 pour le modèle de sortie contrôlée, vous pouvez faciliter cette exposition limitée à l'aide d'une passerelle API ou d'un équilibreur de charge qui sert de façade pour les charges de travail ou les services existants. Cela le rend accessible aux environnements de calcul privés, aux environnements sur site ou à d'autres environnements cloud, comme suit :

• Les charges de travail que vous déployez dans l'environnement informatique privé ou dans 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 depuis Google Cloud vers 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 qui répond aux exigences du modèle d'entrée contrôlée.

L'architecture du diagramme précédent est décrite comme suit :

• Du côté de Google Cloud , vous déployez les charges de travail dans un VPC d'application (ou plusieurs VPC).
• Le réseau d'environnement Google Cloud s'étend à d'autres environnements de calcul (sur site ou dans un autre cloud) en utilisant 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 à l'aide d'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) transite par un point de terminaison Private Service Connect dans le VPC de votre application, associé au VPC Apigee.
• Au niveau du 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 Architecture avec appairage de VPC désactivé.

• Configurez des règles de pare-feu et le filtrage du trafic au niveau du VPC de l'application. Cela permet de bénéficier d'un accès précis et contrôlé. Il permet également d'empêcher les systèmes d'accéder directement à vos applications sans passer par le point de terminaison Private Service Connect et la passerelle d'API.

  Vous pouvez également limiter la publicité du sous-réseau d'adresses IP internes de la charge de travail de backend dans le VPC de l'application au réseau sur site pour éviter l'accessibilité directe sans passer par le point de terminaison Private Service Connect et la passerelle d'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 niveaux 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) transite par un VPC de transit distinct vers le point de terminaison Private Service Connect dans le VPC de transit associé au VPC Apigee.
• Au niveau du VPC de l'application, un équilibreur de charge interne (ILB dans le schéma) 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 d'accès réseau possibles à l'aide de Cloud Router et des règles de pare-feu VPC. Par exemple, si vous connectez votre réseau sur site à Google Cloud à l'aide de plusieurs connexions réseau hybrides, vous pouvez envoyer une partie du trafic depuis le réseau 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 mondial Private Service Connect pour fournir des options de reprise après sinistre.

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 depuis d'autres environnements

• Exposer les backends d'applications à d'autres environnements à l'aide de Private Service Connect

• Utiliser une architecture en étoile pour exposer les backends d'applications à d'autres environnements

Accéder aux API Google depuis d'autres environnements

Private Service Connect est une solution pour les scénarios nécessitant un accès aux services Google, comme Cloud Storage ou BigQuery, sans envoyer de trafic sur l'Internet public. Comme illustré dans le diagramme suivant, il permet d'accéder aux API Google compatibles et aux services (y compris Google Maps, Google Ads etGoogle Cloud) à partir d'environnements sur site ou d'autres environnements cloud via une connexion réseau hybride utilisant 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 À 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 de 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.

Remarque : Les points de terminaison Private Service Connect sont enregistrés dans l'annuaire des services des API Google, où vous pouvez stocker, gérer et publier des services.

Exposer les backends d'applications à d'autres environnements à l'aide de Private Service Connect

Dans certains cas, comme le souligne le modèle hybride par tranche, vous devrez peut-être déployer des backends dans Google Cloud tout en conservant les frontends dans des environnements informatiques privés. Bien que moins courante, cette approche est applicable lorsqu'il s'agit d'interfaces lourdes et monolithiques 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 schéma 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 besoins en termes de 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 Passerelles d'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 capacités d'inspection de couche 7 NGFW supplémentaires, la NVA avec des capacités NGFW est éventuellement intégrée à la conception. Vous pouvez avoir besoin de ces capacités pour respecter les exigences de sécurité spécifiques et les normes des règles de sécurité de votre organisation.

• Cette conception suppose que les VPC spokes ne nécessitent pas de communication directe de VPC à VPC.

  • 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 spokes et le VPC hub, vous devez tenir compte de la limitation de transitivité de la mise en réseau VPC sur l'appairage de VPC. Pour contourner cette limitation, vous pouvez utiliser l'une des options suivantes :
    • Pour interconnecter les VPC, utilisez une NVA.
    • Le cas échéant, tenez compte du 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 le VPC partagé.

• Si des NVA sont nécessaires pour l'inspection du trafic, y compris le trafic provenant de vos autres environnements, la connectivité hybride aux environnements sur site ou à d'autres environnements cloud doit être interrompue sur le VPC de transit hybride.

• Si la conception n'inclut pas la NVA, vous pouvez mettre fin à la connectivité hybride au niveau du hub VPC.

• Si certaines fonctionnalités d'équilibrage de charge ou de sécurité sont requises, comme l'ajout de la protection Google Cloud Armor contre les attaques DDoS ou d'un WAF, vous pouvez éventuellement déployer un équilibreur de charge d'application externe au niveau du périmètre via un VPC externe avant de router les requêtes des clients 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é sur Google Cloudtout en maintenant 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 besoins et de l'architecture.
• La conception des VPC et des projets dans Google Cloud doit respecter les exigences de la hiérarchie des ressources et du modèle de communication sécurisé, comme décrit dans ce guide.
• L'intégration d'un VPC de transit dans cette conception permet de provisionner des mesures de sécurité de périmètre et une connectivité hybride supplémentaires en dehors du VPC de 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 sur 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 consignes de conception et d'implémentation de la haute disponibilité et de la redondance fournies par votre fournisseur NVA.
• Pour renforcer la sécurité du périmètre 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 de calcul (hybride ou autre cloud). Implémentez ces options au niveau du réseau de périmètre directement connecté à Internet.
• Si les instances ont besoin d'accéder à Internet, utilisez Cloud NAT dans le VPC de l'application pour permettre aux charges de travail d'accéder à Internet. Cela vous permet d'éviter 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éseaux hybrides et multicloud.

Sortie et entrée contrôlées

Le modèle sortie et entrée contrôlées utilise une combinaison de sortie et d'entrée contrôlées pour les scénarios qui nécessitent 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 d'API, des points de terminaison Private Service Connect ou des équilibreurs de charge pour exposer des API spécifiques et, éventuellement, fournir des audits d'authentification, d'autorisation et d'appels d'API.

La principale différence entre ce modèle et le modèle maillé réside dans son application à des scénarios qui nécessitent uniquement une utilisation bidirectionnelle des API ou une 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 à des adresses IP spécifiques, les réseaux des différents environnements n'ont pas besoin d'être alignés dans votre conception. Voici quelques exemples de scénarios applicables :

• 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 de calcul 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 diagramme 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 comporte 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 d'environnement Google Cloud est étendu à d'autres environnements de calcul. 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 activer l'accès à des adresses IP cibles spécifiques et utiliser un VPC de transit pour ajouter une couche de sécurité du périmètre en dehors du VPC de votre application.
  • Vous pouvez utiliser Cloud Next Generation Firewall ou des appliances virtuelles réseau (NVA) avec des pare-feu 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 qu'elles n'atteignent le VPC de votre application.
• Les API doivent être accessibles via une passerelle d'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 de backend et de frontend dans des environnements sur site ou dans d'autres clouds (modèle hybride à plusieurs niveaux ou 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 apparaissent souvent.

Parfois, ces dépendances et préférences entraînent la distribution d'applications et de backends entre différents fournisseurs de services cloud. De plus, certaines applications peuvent être conçues avec une combinaison de ressources et de services répartis dans des environnements sur site et dans plusieurs environnements cloud.

Pour les applications distribuées, les fonctionnalités de connectivité hybride et multicloud d'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 sur une connexion réseau hybride, comme illustré dans le schéma suivant. Cette intégration permet la distribution progressive des 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 schéma).

L'utilisation de la conception Google Cloud dans le schéma précédent permet de :

• Facilite la communication bidirectionnelle entre Google Cloud, les environnements sur site et les 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 mondiales pour les applications Web avec des composants d'application distribués (interfaces 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 au niveau des points de présence (PoP) :
• Réduisez les dépenses d'investissement et simplifiez les opérations en utilisant des services gérés sans serveur.
• Optimisez les connexions aux backends d'application à l'échelle mondiale pour la vitesse et la latence.
  • Google Cloud Cross-Cloud Network permet la communication multicloud entre les composants d'application via des connexions privées optimales.
• Mettez en cache le contenu statique très demandé et améliorez les performances des applications utilisant l'Cloud Load Balancing mondial en fournissant un accès à Cloud CDN.
• Sécurisez les interfaces mondiales des applications accessibles sur Internet en utilisant les 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 un accès privé et précis aux API de service Google Cloud ou à vos services publiés depuis d'autres environnements sans passer par l'Internet public.

Variantes

Les modèles d'architecture d'entrée et de sortie contrôlées 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 d'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 d'API distribuées

Dans des scénarios comme celui basé sur le modèle multicloud partitionné, les applications (ou les composants d'application) peuvent être créées dans différents environnements cloud, y compris dans un environnement privé sur site. L'exigence courante consiste à acheminer les requêtes client vers le frontend 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 spécifiques de la plate-forme d'API pour l'intégration.

Le schéma suivant illustre la façon dont 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 d'appliquer des mesures strictes de contrôle des accès, où seules les adresses IP préapprouvées (adresses IP des API cibles et de destination ou des points 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 schéma précédent qui utilisent la passerelle d'API Apigee :

• Les requêtes client arrivent directement à l'interface de l'application dans l'environnement qui héberge l'application (ou le composant d'interface).
• Les passerelles et les proxys d'API de chaque environnement gèrent les requêtes d'API des clients et des applications dans différentes directions sur plusieurs environnements.
  • La fonctionnalité de passerelle API dans 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 d'interface (ou de backend) de l'application hébergés dans cet environnement.

Vous pouvez éventuellement utiliser un VPC de transit. Un VPC de transit peut offrir la flexibilité nécessaire pour séparer les préoccupations et effectuer l'inspection de sécurité et la connectivité hybride dans un réseau VPC distinct. Du point de vue de l'accessibilité des adresses IP, un VPC de transit (auquel la connectivité hybride est associée) facilite les exigences suivantes pour maintenir l'accessibilité de bout en bout :

• Les adresses IP des API cibles doivent être annoncées aux autres environnements dans lesquels 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 réside l'API cible (par exemple, les adresses IP du demandeur d'API, c'est-à-dire le client). L'exception se produit lorsque la communication a lieu 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 de VPC direct avec la fonctionnalité d'échange de routes client. Cette conception permet d'acheminer des requêtes d'API spécifiques provenant de charges de travail hébergées dans le VPC de l'application Google Cloud 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 arrive que les entreprises n'aient pas besoin d'utiliser immédiatement une passerelle API (comme Apigee) ou qu'elles souhaitent l'ajouter ultérieurement. Toutefois, il peut exister des exigences commerciales pour activer 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. Chacune des deux entreprises peut héberger ses propres charges de travail dans différents environnements (Google Cloud, sur site ou dans d'autres clouds) et doit éviter le chevauchement des 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 un accès sécurisé au sein du réseau privé dans les régions et via une connectivité hybride. Cette abstraction facilite l'intégration de ressources provenant de différents 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érents besoins 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 chemins de communication distincts. Chaque chemin est initié à partir d'une direction différente pour un objectif de connectivité distinct, idéalement par le biais d'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 d'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 de 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 spécifique, comme récupérer des données à partir de sources de données pouvant être hébergées dans le VPC consommateur ou en dehors, cette communication privée peut avoir lieu 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 consommateur. Pour ce faire, il partage une interface réseau tout en maintenant la séparation des rôles de producteur et de consommateur. Grâce à cette interface réseau dans le VPC consommateur, la VM d'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 consommateur (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 telle qu'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 Configurer la sécurité des interfaces Private Service Connect. Vous pouvez également envisager une autre approche si elle ne respecte pas les normes ou les exigences de 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 Google Cloudhébergé tout en maintenant la cohérence de la plate-forme d'API (Apigee).

• Pour minimiser la latence et optimiser les coûts liés aux transferts de volumes élevés de données sortantes vers vos autres environnements lorsque ceux-ci sont configurés de manière hybride ou multicloud à long terme ou de façon permanente, tenez compte des points suivants :

  • Utilisez Cloud Interconnect ou interconnexion cross-cloud.
  • Pour interrompre les connexions utilisateur au niveau du frontend ciblé dans l'environnement approprié, utilisez Hybrid.

• Si cela correspond à vos besoins et à l'architecture, 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 à rediriger vers une passerelle d'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 de 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 une connexion VPN ou Cloud Interconnect autorisée. Pour en savoir plus sur les avantages des périmètres de service, consultez la page Présentation de VPC Service Controls.

• 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éseaux hybrides 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 informatique privé à des projets dans Google Cloud. Ce modèle s'applique principalement aux configurations qui suivent le modèle d'architecture multicloud hybride pour l'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 s'effectuent 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 provenant 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 schéma d'architecture précédent montre 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 accessibles aux charges de travail déployées dans Google Cloudpour traitement ultérieur. 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 restreindre l'accès aux services et minimiser les risques d'exfiltration de données non justifiée à partir 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, Cloud Interconnect ou interconnexion cross-cloud. En général, la décision concernant la manière de se connecter dépend de plusieurs aspects, tels que les suivants :
  • 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 un adressage IP privé 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.
• Si possible, utilisez des solutions de transfert de données intégrées et axées sur le cloud, comme la suite de solutions Google Cloud. Pour répondre à vos besoins, 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 minimiser la latence et éviter le transfert et le déplacement de volumes importants de données sur Internet, envisagez d'utiliser Cloud Interconnect ou interconnexion cross-cloud, y compris l'accès 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 une connexion VPN ou Cloud Interconnect autorisée. Pour en savoir plus sur les avantages des périmètres de service, consultez la page Présentation de VPC Service Controls.

• 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. Validez la conception sélectionnée par rapport 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 Well-Architected Framework : 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 de l'entreprise et des applications, telles que les SLA, les performances, la sécurité, le coût, la fiabilité et la bande passante. Pour en savoir plus, consultez 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, le cas échéant et conformément aux exigences de conception de votre hiérarchie de ressources. Pour en savoir plus, consultez 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 Modèles pour authentifier les utilisateurs d'entreprise dans un environnement hybride.

• Lorsque vous concevez vos environnements sur site et cloud, pensez à l'adressage IPv6 dès le début et tenez compte des services qui le prennent en charge. Pour en savoir plus, consultez Présentation d'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 règle 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 des 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 provenant de plages d'adresses IP de cloud public spécifiques si vos services n'ont besoin de communiquer qu'avec ce cloud public. Pour en savoir plus, consultez Bonnes pratiques concernant les règles de pare-feu.

• Vous devez toujours concevoir la sécurité de votre cloud et de votre réseau en utilisant une approche de sécurité multicouche. Pour ce faire, tenez compte des 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 pour l'analyse et la 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 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 d'utiliser 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 d'API à grande échelle. L'utilisation des passerelles d'API Cloud Load Balancing vous permet 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é pour 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.

  • Utilisez 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érer 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 problèmes de capacité qui peuvent survenir dans les applications distribuées à l'échelle mondiale.

  • 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 un VPN haute disponibilité sur Cloud Interconnect pour chiffrer le trafic en transit au niveau de la 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 Comment satisfaire les exigences de conformité de chiffrement en transit.

• Si vous avez besoin d'un volume de trafic plus important sur une connectivité hybride VPN que ce 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 sortantes élevés, envisagez d'utiliser 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 remplit certaines conditions. Pour en savoir plus, consultez la section sur les tarifs de Cloud Interconnect.

• Lorsque vous vous connectez à Google Cloud des ressources et que vous essayez de choisir entre Cloud Interconnect, l'appairage direct ou l'appairage opérateur, nous vous recommandons d'utiliser Cloud Interconnect, sauf si vous avez besoin d'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 sur le cloud.

• Si vous avez des restrictions techniques qui 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 permettre aux charges de travail dans Google Cloud, sur site ou dans un autre environnement cloud avec connectivité hybride, d'accéder de manière privée aux API Google ou aux services publiés, en utilisant des 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 :

  • Évaluez de manière exhaustive les niveaux de fiabilité requis pour les différentes applications dans les 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 Fiabilité de l'infrastructureGoogle Cloud .

• La visibilité et la surveillance du réseau cloud sont essentielles pour maintenir 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 : la suite

• Renseignez-vous sur 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/en périphérie au réseau Google Cloud , ainsi que l'impact d'une déconnexion temporaire de Google Cloud.