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 exécutées dans Google Cloud à l'environnement informatique privé, sans les exposer à l'Internet public. Ce modèle est la contrepartie du modèle d'entrée contrôlée et convient bien aux scénarios d'hybride de périphérie, d'hybride par tranche et de multicloud partitionné.
Comme avec le modèle de sortie contrôlée, vous pouvez faciliter cette exposition limitée via une passerelle API ou un équilibreur de charge qui sert de façade pour les charges de travail ou les services existants. Les environnements informatiques privés, les environnements sur site ou les autres environnements cloud sont ainsi accessibles, comme indiqué ci-dessous:
- 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 le répartiteur de charge à l'aide d'adresses IP internes. Les autres systèmes déployés dans Google Cloud ne sont pas accessibles.
- La communication entre Google Cloud et l'environnement informatique privé ou d'autres environnements cloud n'est pas autorisée. Le trafic n'est lancé que depuis l'environnement privé ou d'autres environnements cloud vers les API dans Google Cloud.
Architecture
Le diagramme suivant montre une architecture de référence qui répond aux exigences du modèle d'entrée contrôlée.
La description de l'architecture dans le schéma précédent est la suivante:
- Du côté de Google Cloud, vous déployez les charges de travail dans un VPC d'application (ou plusieurs VPC).
- Le réseau de l'environnement Google Cloud s'étend à d'autres environnements informatiques (sur site ou dans un autre cloud) 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é 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 sur le 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) afin de fournir une couche proxy, ainsi qu'une couche ou une façade d'abstraction pour vos API de service. Si vous devez répartir le trafic sur 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'adresses IP RFC 1918 sans chevauchement.
Le schéma suivant illustre la conception de ce modèle en utilisant Apigee comme plate-forme d'API.
Dans le schéma précédent, l'utilisation d'Apigee en tant que plate-forme d'API offre 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 du débit
- Analytics
Dans la conception:
- La connectivité réseau Northbound (pour le trafic provenant d'autres environnements) passe par un point de terminaison Private Service Connect dans le VPC d'application associé au VPC Apigee.
- Au niveau du VPC d'application, un équilibreur de charge interne est utilisé pour exposer les API d'application via un point de terminaison Private Service Connect présenté dans le VPC Apigee. Pour en savoir plus, consultez la section Architecture avec appairage de VPC désactivé.
Configurer les règles de pare-feu et le filtrage du trafic au niveau du VPC de l'application Cela permet d'obtenir un accès précis et contrôlé. Cela 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 API.
Vous pouvez également limiter l'annonce du sous-réseau d'adresses IP internes de la charge de travail du backend dans le VPC de l'application au réseau sur site pour éviter la joignabilité directe sans passer par le point de terminaison Private Service Connect et la passerelle API.
Certaines exigences de sécurité peuvent nécessiter une inspection de 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 mettre en œuvre des couches de sécurité supplémentaires. Ces couches, par exemple les NVA NGFW avec plusieurs interfaces réseau, ou Cloud Next Generation Firewall Enterprise avec un service de prévention des intrusions (IPS), effectuent une inspection approfondie des paquets en dehors du VPC de votre application, comme illustré dans le schéma suivant:
Comme illustré dans le schéma précédent :
- La connectivité réseau northbound (pour le trafic provenant d'autres environnements) passe par un VPC de transit distinct vers le point de terminaison Private Service Connect dans le VPC de transit associé au VPC Apigee.
- 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 réseau possibles à l'aide de règles de pare-feu Cloud Router et VPC. Par exemple, si vous connectez votre réseau sur site à Google Cloud à l'aide de plusieurs connexions de réseau hybride, vous pouvez envoyer une partie du trafic sur site vers des API Google ou des services publiés spécifiques via une connexion, et le reste via une autre connexion. Vous pouvez également utiliser l'accès global Private Service Connect pour fournir des options de basculement.
Variantes
Le modèle d'architecture d'entrée contrôlée peut être combiné à d'autres approches pour répondre à différentes exigences de conception, tout en tenant compte des exigences de communication du modèle. Le modèle propose les options suivantes :
Accéder aux API Google depuis d'autres environnements
Pour les scénarios nécessitant un accès aux services Google, tels que Cloud Storage ou BigQuery, sans envoyer de trafic via l'Internet public, Private Service Connect propose une solution. Comme le montre le diagramme suivant, il permet la joignabilité aux API Google et aux services compatibles (y compris Google Maps, Google Ads et Google Cloud) depuis des 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 la section À propos de l'accès aux API Google via des points de terminaison.
Dans le schéma 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.
Exposer les backends d'application à d'autres environnements à l'aide de Private Service Connect
Dans des scénarios spécifiques, comme indiqué par le modèle hybride par tranche, vous devrez peut-être déployer des backends dans Google Cloud tout en conservant des interfaces dans des environnements informatiques privés. Bien que moins courante, cette approche est applicable à des interfaces monolithiques lourdes et susceptibles de reposer sur d'anciens composants. 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 exigences concernant les charges de travail distribuées sur Google Cloud et d'autres environnements, vous pouvez utiliser Apigee sur Google Cloud avec Apigee hybrid. Pour en savoir plus, consultez la section Passerelles API distribuées.
Utiliser une architecture en étoile pour exposer les backends d'applications à d'autres environnements
L'exposition des API à partir de backends d'applications hébergés dans Google Cloud sur différents réseaux VPC peut être nécessaire dans certains scénarios. 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, le NVA avec capacités NGFW peut être intégré à la conception. Vous pouvez exiger que ces fonctionnalités soient conformes à des exigences de sécurité spécifiques et aux normes de règles de sécurité de votre organisation.
Cette conception suppose que les VPC spokes ne nécessitent pas de communication directe entre VPC.
- Si une communication entre les spokes est nécessaire, vous pouvez utiliser le NVA pour faciliter cette communication.
- Si vous avez différents backends dans différents VPC, vous pouvez utiliser Private Service Connect pour exposer ces backends au VPC Apigee.
- Si l'appairage de VPC est utilisé pour la connectivité Northbound et Southbound entre les VPC spoke et le VPC hub, vous devez tenir compte de la limite de transitivité de la mise en réseau VPC via l'appairage de VPC. Pour contourner cette limitation, vous pouvez utiliser l'une des options suivantes :
- Pour interconnecter les VPC, utilisez un NVA.
- Le cas échéant, envisagez le modèle Private Service Connect.
- Pour établir la connectivité entre le VPC Apigee et les backends situés dans d'autres projets Google 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 vers les environnements sur site ou d'autres environnements cloud doit être terminée sur le VPC de transit hybride.
Si la conception n'inclut pas le NVA, vous pouvez mettre fin à la connectivité hybride au niveau du VPC hub.
Si certaines fonctionnalités d'équilibrage de charge ou de sécurité sont requises, comme l'ajout d'une protection DDoS ou d'un pare-feu Web de Google Cloud Armor, vous pouvez éventuellement déployer un équilibreur de charge d'application externe au niveau du périmètre via un VPC externe avant de rediriger 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é par Google Cloud tout 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 selon vos besoins et 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ée, 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é périmétriques supplémentaires et une connectivité hybride 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 page 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é (HA) des NVA pour éviter un point de défaillance unique qui pourrait bloquer toute communication. Suivez les conseils de votre fournisseur de NVA pour la conception et la mise en œuvre de la haute disponibilité et de la redondance. Pour en savoir plus, sur la réalisation d'une haute disponibilité entre les dispositifs virtuels, consultez la section des options d'architecture des dispositifs réseau centralisés sur Google Cloud
- Pour renforcer la sécurité du périmètre et sécuriser votre passerelle API déployée dans l'environnement respectif, vous pouvez éventuellement mettre en œuvre des mécanismes d'équilibrage de charge et de pare-feu d'application Web dans votre autre environnement informatique (hybride ou autre cloud). Implémentez ces options sur le réseau périphérique directement connecté à Internet.
- Si les instances ont besoin d'un accès à Internet, utilisez Cloud NAT dans le VPC de l'application pour permettre aux charges de travail d'accéder à Internet. Vous évitez ainsi d'attribuer des instances de VM avec des adresses IP publiques externes 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 offre plusieurs avantages.
Consultez les bonnes pratiques générales pour les modèles de réseau hybride et multicloud.