Sortie contrôlée

L'architecture du modèle de 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 ou d'un proxy, ou d'un équilibreur de charge servant de façade aux charges de travail existantes permet de contrôler cette exposition. Vous pouvez déployer la fonctionnalité de passerelle API dans un segment de réseau de périmètre isolé, comme un réseau de périmètre.

Le modèle de réseau sortie contrôlée s'applique principalement, mais sans s'y limiter, aux modèles d'architecture d'application à niveaux et aux modèles d'architecture d'application partitionnée. Lorsque vous déployez des charges de travail backend sur un réseau interne, le réseau de sortie contrôlé permet de maintenir un niveau de sécurité plus élevé dans votre environnement IT sur site. Le modèle nécessite de connecter les environnements informatiques de manière à répondre aux exigences de communication suivantes:

• Les charges de travail que vous déployez dans Google Cloud peuvent communiquer avec la passerelle API ou l'équilibreur de charge (ou un point de terminaison Private Service Connect) qui expose l'application à l'aide d'adresses IP internes.
• Les autres systèmes de l'environnement informatique privé ne sont pas accessibles directement depuis Google Cloud.
• La communication entre l'environnement informatique privé et les charges de travail déployées dans Google Cloud n'est pas autorisée.
• Le trafic vers les API privées dans d'autres environnements n'est lancé que depuis l'environnement Google Cloud.

Ce guide se concentre sur les environnements hybrides et multicloud connectés via un réseau hybride privé. Si les exigences de sécurité de votre organisation le permettent, les appels d'API vers des API cibles distantes avec des adresses IP publiques peuvent être directement accessibles via Internet. Toutefois, vous devez tenir compte des mécanismes de sécurité suivants:

• API OAuth 2.0 avec TLS (Transport Layer Security)
• Limitation du débit
• Règles de protection contre les menaces
• Authentification TLS mutuelle configurée sur le backend de votre couche API.
• Filtrage de la liste d'autorisation des adresses IP configuré pour n'autoriser que la communication avec des sources et des destinations d'API prédéfinies des deux côtés.

Pour sécuriser un proxy d'API, tenez compte de ces autres aspects de sécurité. Pour en savoir plus, consultez les bonnes pratiques pour sécuriser vos applications et vos API avec Apigee.

Architecture

Le schéma suivant montre une architecture de référence compatible avec les exigences de communication listées dans la section précédente:

Les données circulent dans le schéma précédent comme suit:

• Du côté de Google Cloud, vous pouvez déployer des charges de travail dans des cloud privés virtuels (VPC). Les VPC peuvent être uniques ou multiples (partagés ou non). Le déploiement doit être conforme aux projets et à la conception de la hiérarchie des ressources de votre organisation.
• Les réseaux VPC de l'environnement Google Cloud s'étendent aux autres environnements informatiques. Les environnements peuvent être sur site ou dans un autre cloud. Pour faciliter la communication entre les environnements à l'aide d'adresses IP internes, utilisez une connectivité réseau hybride et multicloud appropriée.

• Pour limiter le trafic provenant d'adresses IP VPC spécifiques et destiné à des passerelles ou à des équilibreurs de charge distants, utilisez le filtrage de la liste d'autorisation des adresses IP. Le trafic retour de ces connexions est autorisé lorsque vous utilisez des règles de pare-feu avec état. Vous pouvez utiliser n'importe quelle combinaison des fonctionnalités suivantes pour sécuriser et limiter les communications aux seules adresses IP source et de destination autorisées:

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

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

  • Cloud Next Generation Firewall Enterprise avec un service de prévention des intrusions (IPS) pour mettre en œuvre une inspection approfondie des paquets à des fins de prévention des menaces.

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

Variantes

Le modèle d'architecture d'sortie contrôlée peut être combiné à d'autres approches pour répondre à différentes exigences de conception tout en tenant compte des exigences de communication de ce modèle. Le modèle propose les options suivantes :

• Utiliser la passerelle d'API Google Cloud et l'interface globale
• Exposer des services distants à l'aide de Private Service Connect

Utiliser la passerelle d'API Google Cloud et l'interface globale

Avec cette approche de conception, l'exposition et la gestion des API se trouvent dans Google Cloud. Comme illustré dans le schéma précédent, vous pouvez y parvenir en implémentant Apigee comme plate-forme d'API. La décision de déployer une passerelle API ou un équilibreur de charge dans l'environnement distant dépend de vos besoins spécifiques et de votre configuration actuelle. Apigee propose deux options de provisionnement de la connectivité:

• Avec appairage de VPC
• Sans appairage de VPC

Les fonctionnalités d'interface globale de Google Cloud, telles que Cloud Load Balancing, Cloud CDN (lorsque l'accès s'effectue via Cloud Interconnect) et Cross-Cloud Interconnect, 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 du contenu, ces applications sont diffusées à partir des points de présence (PoP) Google Cloud. Les PoP Google Cloud sont présents sur plus de 180 points d'échange Internet et dans plus de 160 installations d'interconnexion à travers le monde.

Pour découvrir comment les points de présence permettent de fournir des API hautes performances lorsque vous utilisez Apigee avec Cloud CDN pour : regardez la vidéo Fournir des API hautes performances avec Apigee et Cloud CDN sur YouTube.

• Réduire la latence.
• Hébergez des API à l'échelle mondiale.
• Augmenter la disponibilité en cas de pic de trafic

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

Le réseau northbound de cette conception est établi via:

• Un équilibreur de charge (LB dans le diagramme), où les requêtes client se terminent, traite le trafic, puis l'achemine vers un backend Private Service Connect.
• Un backend Private Service Connect permet à un équilibreur de charge Google Cloud d'envoyer des requêtes client via une connexion Private Service Connect associée à un rattachement de service de producteur au service publié (instance d'exécution Apigee) à l'aide de groupes de points de terminaison du réseau (NEG) Private Service Connect.

Le réseautage Southbound est établi via:

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

• L'ILB est déployé avec des groupes de points de terminaison du réseau de connectivité hybride (NEG de connectivité hybride).

• L'accès aux services hybrides s'effectue via le NEG de connectivité hybride avec une connectivité réseau hybride, comme le VPN ou Cloud Interconnect.

Pour en savoir plus, consultez les pages Configurer un équilibreur de charge réseau proxy interne régional avec une connectivité hybride et Modèles de déploiement Private Service Connect.

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

Utilisez l'option Private Service Connect pour exposer des services distants dans les scénarios suivants:

• Vous n'utilisez pas de plate-forme d'API ou vous souhaitez éviter de connecter l'intégralité de votre réseau VPC directement à un environnement externe pour les raisons suivantes :
  • Vous avez des restrictions de sécurité ou des exigences de conformité.
  • La plage d'adresses IP se chevauche, par exemple dans le cadre d'une fusion et d'une acquisition.
• Pour activer les communications unidirectionnelles sécurisées entre les clients, les applications et les services dans les environnements, même si vous disposez d'un délai court.
• Vous devrez peut-être fournir une connectivité à plusieurs VPC client via un VPC de producteur de services (VPC de transit) pour proposer des modèles de services multi-locataires ou mono-locataires hautement é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 aux applications publiées, ce qui permet un accès sécurisé au réseau privé dans les régions et via la connectivité hybride. Cette abstraction facilite l'intégration des ressources de divers clouds et environnements sur site via un modèle de connectivité hybride et multicloud. Vous pouvez accélérer l'intégration des applications et exposer de manière sécurisée les applications qui résident dans un environnement sur site ou dans un autre environnement cloud à l'aide de Private Service Connect pour publier le service avec un accès précis. Dans ce cas, vous pouvez utiliser l'option suivante:

• Rattachement de service qui fait référence à un équilibreur de charge réseau proxy interne régional ou à un équilibreur de charge d'application interne.
  • L'équilibreur de charge utilise un groupe de points de terminaison réseau hybride (NEG de connectivité hybride) dans un VPC producteur qui agit dans cette conception comme un VPC de transit.

Dans le schéma précédent, les charges de travail du réseau VPC de votre application peuvent atteindre les services hybrides exécutés dans votre environnement sur site ou dans d'autres environnements cloud via le point de terminaison Private Service Connect, comme illustré dans le schéma suivant. Cette option de conception pour les communications unidirectionnelles constitue une alternative à l'appairage avec un VPC de transit.

Dans le cadre de la conception du diagramme précédent, plusieurs frontends, backends ou points de terminaison peuvent se connecter au même rattachement de service, ce qui permet à plusieurs réseaux VPC ou à plusieurs clients d'accéder au même service. Comme illustré dans le schéma suivant, vous pouvez rendre l'application accessible à plusieurs VPC. Cette accessibilité peut être utile dans les scénarios de services multi-locataires où votre service est consommé par plusieurs VPC client, même si leurs plages d'adresses IP se chevauchent.

La superposition d'adresses IP est l'un des problèmes les plus courants lors de l'intégration d'applications situées dans différents environnements. La connexion Private Service Connect du schéma suivant permet d'éviter le problème de chevauchement d'adresses IP. Il le fait sans avoir à provisionner ni à gérer d'autres composants réseau, tels que Cloud NAT ou un NVA, pour effectuer la traduction d'adresses IP. Pour obtenir un exemple de configuration, consultez la section Publier un service hybride à l'aide de Private Service Connect.

Cette conception présente les avantages suivants:

• Évite les dépendances de scaling partagées potentielles et la complexité de la gestion à grande échelle.
• Améliore la sécurité en fournissant un contrôle précis de la connectivité.
• Réduit la coordination des adresses IP entre le producteur et le consommateur du service, et l'environnement externe distant.

L'approche de conception du diagramme précédent peut être étendue à des étapes ultérieures pour intégrer Apigee en tant que plate-forme d'API à l'aide des options de conception de mise en réseau abordées précédemment, y compris l'option Private Service Connect.

Vous pouvez rendre le point de terminaison Private Service Connect accessible depuis d'autres régions à l'aide de l'accès mondial Private Service Connect.

Le client qui se connecte au point de terminaison Private Service Connect peut se trouver dans la même région que le point de terminaison ou dans une autre région. Cette approche peut être utilisée pour fournir une haute disponibilité à des services hébergés dans plusieurs régions ou pour accéder à des services disponibles dans une seule région à partir d'autres régions. Lorsqu'un point de terminaison Private Service Connect est accessible par des ressources hébergées dans d'autres régions, les frais de sortie interrégionaux s'appliquent au trafic destiné aux points de terminaison avec accès mondial.

Bonnes pratiques

• Choisir Apigee et 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 exigences et de l'architecture.
• La conception des VPC et des projets dans Google Cloud doit être guidée par votre hiérarchie des ressources et vos exigences concernant le modèle de communication sécurisé.
• Lorsque des API avec des passerelles API sont utilisées, vous devez également utiliser une liste d'autorisation d'adresses IP. Une liste d'autorisation limite les communications aux sources et destinations d'adresses IP spécifiques des consommateurs d'API et des passerelles d'API pouvant être hébergées dans différents environnements.
• Utilisez des règles de pare-feu VPC ou des stratégies de pare-feu pour contrôler l'accès aux ressources Private Service Connect via le point de terminaison Private Service Connect.
• Si une application est exposée en externe via un équilibreur de charge d'application, envisagez d'utiliser Google Cloud Armor comme couche de sécurité supplémentaire pour vous protéger contre les attaques DDoS et les menaces de sécurité de la couche application.

• Si les instances nécessitent un accès à Internet, utilisez Cloud NAT dans le VPC de l'application (consommateur) pour permettre aux charges de travail d'accéder à Internet. Vous évitez ainsi d'attribuer des adresses IP publiques externes aux instances de VM dans les systèmes déployés derrière une passerelle API ou un équilibreur de charge.

  • Pour le trafic Web sortant, vous pouvez utiliser le proxy Web sécurisé de Google Cloud. Le proxy présente plusieurs avantages.

• Consultez les bonnes pratiques générales pour les modèles de réseautage hybride et multicloud.