L'architecture du modèle d'entrée contrôlée consiste à exposer certaines API de charges de travail exécutées dans Google Cloud à l'environnement informatique privé, sans les exposer à l'Internet public. Ce modèle est la contrepartie du modèle d'entrée contrôlée et convient bien aux scénarios d'hybride de périphérie, d'hybride par tranche et de multicloud partitionné.
Comme avec le modèle 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. Il est ainsi accessible aux environnements d'informatique privée, aux environnements sur site ou à un autre environnement cloud, comme suit:
- Les charges de travail que vous déployez dans l'environnement informatique privé ou d'autres environnements cloud peuvent communiquer avec la passerelle API ou l'équilibreur de charge à l'aide d'adresses IP internes. Les autres systèmes déployés 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 répondant aux exigences du modèle d'entrée contrôlée.
La description de l'architecture du 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) à l'aide d'une connectivité réseau hybride ou multicloud pour faciliter la communication entre les environnements.
- Vous pouvez éventuellement utiliser un VPC de transit pour effectuer les opérations suivantes:
- Fournissez des couches de sécurité de périmètre supplémentaires pour autoriser l'accès à des API spécifiques en dehors du VPC de votre application.
- Acheminez le trafic vers les adresses IP des API. Vous pouvez créer des règles de pare-feu VPC pour empêcher certaines sources d'accéder à certaines API via un point de terminaison.
- Inspectez le trafic de couche 7 au niveau du VPC de transit en intégrant un dispositif virtuel de réseau (NVA).
- Accédez aux API via une passerelle API ou un équilibreur de charge (proxy ou équilibreur de charge d'application) pour fournir une couche proxy, ainsi qu'une couche d'abstraction ou une façade pour vos API de service. Si vous devez distribuer le trafic entre plusieurs instances de passerelle API, vous pouvez utiliser un équilibreur de charge réseau passthrough interne.
- Fournissez un accès limité et précis à un service publié via un point de terminaison Private Service Connect à l'aide d'un équilibreur de charge via Private Service Connect pour exposer une application ou un service.
- Tous les environnements doivent utiliser un espace d'adressage IP RFC 1918 sans chevauchement.
Le schéma suivant illustre la conception de ce modèle à 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) passe par un point de terminaison Private Service Connect dans le VPC de votre application associé au VPC Apigee.
- Dans le VPC de l'application, un équilibreur de charge interne est utilisé pour exposer les API de l'application via un point de terminaison Private Service Connect présenté dans le VPC Apigee. Pour en savoir plus, consultez la section Architecture avec appairage de VPC désactivé.
Configurez des règles de pare-feu et un filtrage du trafic au niveau du VPC de l'application. Vous bénéficiez ainsi d'un accès précis et contrôlé. Il permet également d'empêcher les systèmes d'atteindre directement vos applications sans passer par le point de terminaison Private Service Connect et la passerelle API.
Vous pouvez également limiter la diffusion du sous-réseau d'adresses IP internes de la charge de travail backend dans le VPC de l'application au réseau sur site pour éviter la connectivité directe sans passer par le point de terminaison Private Service Connect et la passerelle API.
Certaines exigences de sécurité peuvent nécessiter une inspection de la sécurité du périmètre en dehors du VPC de l'application, y compris le trafic de connectivité hybride. Dans ce cas, vous pouvez intégrer un VPC de transit pour implémenter des couches de sécurité supplémentaires. Ces couches, par exemple les NVA NGFW avec plusieurs interfaces réseau, ou Cloud Next Generation Firewall Enterprise avec un service de prévention des intrusions (IPS), effectuent une inspection approfondie des paquets en dehors du VPC de votre application, comme illustré dans le schéma suivant:
Comme illustré dans le schéma précédent :
- La connectivité réseau northbound (pour le trafic provenant d'autres environnements) passe par un VPC de transit distinct vers le point de terminaison Private Service Connect dans le VPC de transit associé au VPC Apigee.
- Dans le VPC de l'application, un équilibreur de charge interne (ILB dans le diagramme) est utilisé pour exposer l'application via un point de terminaison Private Service Connect dans le VPC Apigee.
Vous pouvez provisionner plusieurs points de terminaison dans le même réseau VPC, comme illustré dans le schéma suivant. Pour couvrir différents cas d'utilisation, vous pouvez contrôler les différents chemins réseau possibles à l'aide de Cloud Router et de règles de pare-feu VPC. Par exemple, si vous connectez votre réseau sur site à Google Cloud à l'aide de plusieurs connexions réseau hybrides, vous pouvez envoyer du trafic sur site vers des API Google ou des services publiés spécifiques via une connexion et le reste via une autre connexion. Vous pouvez également utiliser l'accès global Private Service Connect pour fournir des options de basculement.
Variantes
Le modèle d'architecture d'entrée contrôlée peut être combiné à d'autres approches pour répondre à différentes exigences de conception, tout en tenant compte des exigences de communication du modèle. Le modèle propose les options suivantes :
Accéder aux API Google à partir d'autres environnements
Private Service Connect propose une solution pour les scénarios nécessitant l'accès aux services Google, tels que Cloud Storage ou BigQuery, sans envoyer de trafic sur l'Internet public. Comme 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 diagramme précédent, votre réseau sur site doit être connecté au réseau VPC de transit (consommateur) à l'aide de tunnels Cloud VPN ou d'un rattachement VLAN Cloud Interconnect.
Les API Google sont accessibles via des points de terminaison ou des backends. Les points de terminaison vous permettent de cibler un groupe d'API Google. Les backends vous permettent de cibler une API Google régionale spécifique.
Exposer les backends d'applications à d'autres environnements à l'aide de Private Service Connect
Dans des scénarios spécifiques, comme le montre le modèle hybride par tranche, vous devrez peut-être déployer des backends dans Google Cloud tout en conservant les interfaces dans des environnements informatiques privés. Bien que moins courante, cette approche est applicable lorsque vous travaillez avec des interfaces monolithiques lourdes qui peuvent s'appuyer sur des composants anciens. Ou, plus généralement, lors de la gestion d'applications distribuées dans plusieurs environnements, y compris sur site et dans d'autres clouds, qui nécessitent une connectivité à des backends hébergés dans Google Cloud via un réseau hybride.
Dans une telle architecture, vous pouvez utiliser une passerelle d'API ou un équilibreur de charge local dans l'environnement privé sur site ou dans d'autres environnements cloud pour exposer directement l'interface de l'application sur Internet. L'utilisation de Private Service Connect dans Google Cloud facilite la connectivité privée aux backends exposés via un point de terminaison Private Service Connect, idéalement à l'aide d'API prédéfinies, comme illustré dans le diagramme suivant:
La conception du diagramme 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
Dans certains cas, il peut être nécessaire d'exposer des API à partir de backends d'application hébergés dans Google Cloud sur différents réseaux VPC. Comme illustré dans le schéma suivant, un VPC hub sert de point d'interconnexion central pour les différents VPC (spokes), ce qui permet une communication sécurisée via une connectivité hybride privée. Vous pouvez également utiliser les fonctionnalités de passerelle API locales dans d'autres environnements, tels que Apigee Hybrid, pour mettre fin aux requêtes client localement, là où l'interface de l'application est hébergée.
Comme illustré dans le schéma précédent :
- Pour fournir des fonctionnalités d'inspection de couche 7 NGFW supplémentaires, le NVA avec des fonctionnalités NGFW peut être intégré à la conception. Vous devrez peut-être utiliser ces fonctionnalités pour respecter des exigences de sécurité spécifiques et les normes de votre organisation en matière de règles de sécurité.
Cette conception suppose que les VPC spokes ne nécessitent pas de communication VPC à VPC directe.
- Si une communication entre les spokes est nécessaire, vous pouvez utiliser le NVA pour faciliter cette communication.
- Si vous disposez de différents backends dans différents VPC, vous pouvez utiliser Private Service Connect pour les exposer au VPC Apigee.
- Si l'appairage de VPC est utilisé pour la connectivité nord-sud entre les VPC spoke et le VPC hub, vous devez tenir compte de la limitation de transitivité de la mise en réseau VPC via l'appairage de VPC. Pour contourner cette limitation, vous pouvez utiliser l'une des options suivantes :
- Pour interconnecter les VPC, utilisez un NVA.
- Le cas échéant, envisagez le modèle Private Service Connect.
- Pour établir la connectivité entre le VPC Apigee et les backends situés dans d'autres 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 celui provenant de vos autres environnements, la connectivité hybride vers des environnements sur site ou d'autres environnements cloud doit se terminer sur le VPC de transit hybride.
Si la conception n'inclut pas le NVA, vous pouvez mettre fin à la connectivité hybride au niveau du VPC du hub.
Si certaines fonctionnalités d'équilibrage de charge ou de sécurité sont requises, comme l'ajout d'une protection DDoS ou dWAF;application Google Cloud Armor, vous pouvez éventuellement déployer un équilibreur de charge d'application externe au périmètre via un VPC externe avant de router les requêtes client externes vers les backends.
Bonnes pratiques
- Dans les cas où les requêtes client provenant d'Internet doivent être reçues localement par une interface d'application hébergée dans un environnement cloud privé sur site ou autre environnement cloud, envisagez d'utiliser Apigee Hybrid comme solution de passerelle API. Cette approche facilite également la migration fluide de la solution vers un environnement entièrement hébergé par Google Cloud, tout en préservant la cohérence de la plate-forme d'API (Apigee).
- Utilisez Apigee Adapter for Envoy avec une architecture de déploiement Apigee Hybrid avec Kubernetes, le cas échéant, en fonction de vos exigences et de l'architecture.
- La conception des VPC et des projets dans Google Cloud doit suivre la hiérarchie des ressources et les exigences du modèle de communication sécurisé, comme décrit dans ce guide.
- L'intégration d'un VPC de transit dans cette conception offre la flexibilité nécessaire pour provisionner des mesures de sécurité périmétriques supplémentaires et une connectivité hybride en dehors du VPC de la charge de travail.
- Utilisez Private Service Connect pour accéder aux API et services Google à partir d'environnements sur site ou d'autres environnements cloud à l'aide de l'adresse IP interne du point de terminaison via un réseau de connectivité hybride. Pour en savoir plus, consultez la section Accéder au point de terminaison à partir d'hôtes sur site.
- Pour protéger les services Google Cloud dans vos projets et limiter le risque d'exfiltration de données, utilisez VPC Service Controls pour spécifier des périmètres de service au niveau du projet ou du réseau VPC.
- Si nécessaire, vous pouvez étendre les périmètres de service à un environnement hybride via un VPN ou Cloud Interconnect. Pour en savoir plus sur les avantages des périmètres de service, consultez la page Présentation de VPC Service Controls.
- Utilisez des règles de pare-feu VPC ou des stratégies de pare-feu pour contrôler l'accès au niveau du réseau aux ressources Private Service Connect via le point de terminaison Private Service Connect. Par exemple, les règles de pare-feu sortantes au niveau du VPC de l'application (client) peuvent restreindre l'accès des instances de VM à l'adresse IP ou au sous-réseau de vos points de terminaison. Pour en savoir plus sur les règles de pare-feu VPC en général, consultez la section Règles de pare-feu VPC.
- Lorsque vous concevez une solution qui inclut des NVA, il est important de prendre en compte la haute disponibilité (HD) des NVA pour éviter un point de défaillance unique qui pourrait bloquer toute communication. Suivez les conseils de conception et d'implémentation de la haute disponibilité et de la redondance fournis par votre fournisseur de NVA.
- Pour renforcer la sécurité périmétrique et sécuriser votre passerelle API déployée dans l'environnement concerné, vous pouvez éventuellement implémenter des mécanismes d'équilibrage de charge et de pare-feu d'application Web dans votre autre environnement IT (hybride ou autre cloud). Implémentez ces options au niveau du réseau de périmètre directement connecté à Internet.
- Si les instances nécessitent un accès à Internet, utilisez Cloud NAT dans le VPC de l'application pour permettre aux charges de travail d'accéder à Internet. Vous évitez ainsi d'attribuer des adresses IP publiques externes aux instances de VM dans les systèmes déployés derrière une passerelle API ou un équilibreur de charge.
- Pour le trafic Web sortant, utilisez le proxy Web sécurisé. Le proxy présente plusieurs avantages.
- Consultez les bonnes pratiques générales pour les modèles de réseautage hybride et multicloud.