Ce document fait partie d'une série qui décrit les architectures de mise en réseau et de sécurité pour les entreprises qui migrent les charges de travail de centres de données vers Google Cloud.
La série comprend les documents suivants :
- Concevoir des réseaux pour migrer des charges de travail d'entreprise : approches architecturales
- Mise en réseau pour un accès sécurisé dans le cloud : architectures de référence (ce document)
- Mise en réseau pour la diffusion d'applications Web : Architectures de référence
- Mise en réseau pour les charges de travail hybrides et multicloud : architectures de référence
Les charges de travail pour les cas d'utilisation intra-cloud résident dans des réseaux VPC et doivent se connecter à d'autres ressources dans Google Cloud. Elles peuvent consommer des services fournis de manière native dans le cloud, tels que BigQuery. Le périmètre de sécurité est fourni par différentes fonctionnalités propriétaires et tierces, telles que des pare-feu, VPC Service Controls et des dispositifs virtuels de réseau.
Dans de nombreux cas, ces charges de travail s'étendent sur plusieurs réseaux VPC Google Cloud et les limites entre les réseaux VPC doivent être sécurisées. Ce document décrit en détail ces architectures de sécurité et de connectivité.
Architecture de migration Lift and Shift
Le premier scénario pour un cas d'utilisation intra-cloud est une architecture de migration Lift and Shift dans laquelle vous déplacez des charges de travail établies telles quelles vers le cloud.
Pare-feu
Vous pouvez contribuer à établir un périmètre sécurisé en configurant des règles de pare-feu.
Vous pouvez utiliser des tags réseau pour appliquer des règles de pare-feu précises à un ensemble de VM. Un tag est un attribut arbitraire composé d'une chaîne de caractères ajoutée au champ tags de la VM au moment de sa création.
Vous pouvez également attribuer un tag ultérieurement en modifiant la VM. Pour obtenir des consignes d'implémentation sur la gestion du trafic avec des règles de pare-feu Google Cloud, consultez la page Stratégies de pare-feu réseau dans le plan de base de l'entreprise.
Vous pouvez également utiliser la journalisation de pare-feu pour auditer et vérifier les effets de l'application des règles de pare-feu.
Vous pouvez utiliser les journaux de flux VPC pour procéder à l'investigation numérique du réseau, puis diffuser les journaux pour les intégrer à la SIEM. Ce système global peut fournir une surveillance en temps réel, la corrélation des événements, ainsi que des analyses et des alertes de sécurité.
La figure 1 montre comment les règles de pare-feu peuvent utiliser des tags de VM pour limiter le trafic entre les VM d'un réseau VPC.
Figure 1 : Configuration de pare-feu de réseau utilisant des tags réseau pour appliquer un contrôle de sortie précis.
Dispositif virtuel de réseau
Un dispositif virtuel de réseau est une VM dotée de plusieurs interfaces réseau. Un tel dispositif vous permet de vous connecter directement à plusieurs réseaux VPC. Des fonctions de sécurité telles que les pare-feu d'application Web et de sécurité au niveau des applications peuvent être mises en œuvre sur les VM. Vous pouvez utiliser des dispositifs virtuels de réseau pour mettre en œuvre des fonctions de sécurité pour le trafic est-ouest, en particulier lorsque vous utilisez une configuration hub-and-spoke, comme illustré dans la figure 2.
Pour obtenir des consignes de mise en œuvre sur l'utilisation des dispositifs virtuels de réseau sur Google Cloud, consultez la page Dispositifs réseau centralisés sur Google Cloud.
Figure 2 : Configuration de dispositif réseau centralisé dans un réseau VPC partagé.
Cloud IDS
Cloud Intrusion Detection System (Cloud IDS) vous permet de mettre en œuvre l'inspection et la journalisation natives de sécurité en mettant en miroir le trafic d'un sous-réseau de votre réseau VPC. Cloud IDS vous permet d'inspecter et de surveiller un large éventail de menaces au niveau de la couche réseau et de la couche d'application en vue de leur analyse. Vous créez des points de terminaison Cloud IDS dans votre réseau VPC associé à votre projet Google Cloud. Ces points de terminaison surveillent le trafic entrant et sortant de ce réseau, ainsi que le trafic réseau intra-VPC, à l'aide de la fonctionnalité de mise en miroir de paquets intégrée à la pile réseau Google Cloud. Vous devez activer l'accès aux services privés afin de vous connecter au projet producteur de services (le projet géré par Google), qui héberge les processus Cloud IDS.
Si vous disposez d'une architecture hub-and-spoke, le trafic de chacun des spokes peut être mis en miroir sur les instances Cloud IDS, comme illustré dans la figure 3.
Figure 3. Configuration Cloud IDS permettant de mettre en miroir le trafic VPC utilisant l'accès aux services privés.
Cloud IDS peut être sécurisé dans votre périmètre de service VPC Service Controls à l'aide d'une étape supplémentaire. Pour en savoir plus sur la compatibilité de VPC Service Controls, consultez la page Produits compatibles.
Appairage de réseaux VPC
Pour les applications qui s'étendent sur plusieurs réseaux VPC, qu'elles appartiennent au même projet Google Cloud ou à la même ressource d'organisation, l'appairage de réseaux VPC permet une connectivité entre les réseaux VPC. Cette connectivité permet au trafic de rester à l'intérieur du réseau de Google afin qu'il ne circule pas sur l'Internet public.
Il existe deux modèles pour l'utilisation de l'appairage de réseaux VPC dans une architecture de migration Lift and Shift. L'une exploite une architecture hub-and-spoke "pure", l'autre une architecture hub-and-spoke avec transitivité, où le trafic d'un spoke peut atteindre un autre spoke. Les sections suivantes fournissent des détails sur la manière d'utiliser l'appairage de réseaux VPC avec ces différentes architectures.
Architecture hub-and-spoke
Une architecture en étoile est un modèle très répandu de connectivité VPC, qui fait appel à l'appairage de réseaux VPC. Ce modèle est utile lorsqu'une entreprise possède diverses applications devant accéder à un ensemble commun de services, tels que la journalisation ou l'authentification. Le modèle est également utile si l'entreprise doit mettre en œuvre un ensemble commun de règles de sécurité pour le trafic quittant le réseau via le hub. Dans un modèle hub-and-spoke pur, l'échange de trafic entre les spokes (appelé trafic transitif) n'est pas autorisé. La figure 4 illustre une architecture hub-and-spoke pure qui utilise l'appairage de réseaux VPC pour connecter les spokes au hub. Pour obtenir des consignes d'implémentation pour la création de réseaux en étoile, consultez la section Topologie de réseau hub-and-spoke dans le plan de base de l'entreprise.
Toutefois, si vous n'avez pas besoin de séparation au niveau du VPC, vous pouvez utiliser une architecture de VPC partagé, dont le modèle potentiellement plus simple pourra séduire les entreprises qui font leurs premiers pas sur Google Cloud.
Figure 4. Architecture de réseau en étoile utilisant l'appairage de réseaux VPC pour l'isolation du réseau et la connectivité non transitive.
Hub-and-spoke avec transitivité
Pour une architecture en étoile avec transitivité (le trafic provenant d'un spoke peut atteindre d'autres spokes via le hub), plusieurs approches sont possibles pour l'utilisation de l'appairage de réseaux VPC. Vous pouvez utiliser l'appairage de réseaux VPC dans une topologie de maillage complète, où chaque réseau VPC est directement appairé à tous les autres réseaux VPC qu'il doit atteindre.
Vous pouvez également utiliser un dispositif virtuel de réseau pour connecter le hub et les spokes. Le dispositif virtuel de réseau réside alors derrière des équilibreurs de charge internes utilisés comme saut suivant pour le trafic provenant des spokes VPC. La figure 5 illustre ces deux options.
De plus, vous pouvez utiliser des VPN pour la connexion entre les réseaux VPC du hub et des spokes. Cet agencement permet l'accessibilité entre différentes connexions spoke-spoke, ce qui fournit la transitivité à travers le réseau VPC du hub.
Figure 5. Configuration de réseau hub-and-spoke utilisant Cloud VPN pour l'isolation du réseau et la connectivité transitive.
VPC partagé
Vous pouvez utiliser le VPC partagé pour maintenir un contrôle centralisé sur les ressources réseau telles que les sous-réseaux, les routes et les pare-feu des projets hôtes. Ce niveau de contrôle vous permet de mettre en œuvre la bonne pratique de sécurité du moindre privilège pour l'administration, l'audit et le contrôle des accès réseau : en effet, vous pouvez déléguer des tâches d'administration réseau aux administrateurs réseau et de sécurité. Vous pouvez attribuer la capacité à créer et gérer des VM à des administrateurs d'instance à l'aide de projets de service. L'utilisation d'un projet de service garantit que les administrateurs de VM sont uniquement autorisés à créer et gérer des instances et qu'ils ne sont pas autorisés à apporter des modifications ayant une incidence sur le réseau dans le réseau VPC partagé.
Par exemple, vous pouvez renforcer l'isolation en définissant deux réseaux VPC hébergés dans deux projets hôtes et en associant plusieurs projets de service à chaque réseau, un pour la production et un pour les tests. La figure 6 illustre une architecture qui isole un environnement de production d'un environnement de test à l'aide de projets distincts.
Pour en savoir plus sur les bonnes pratiques en matière de création de réseaux VPC, consultez la section Bonnes pratiques et architectures de référence pour la conception de VPC.
Figure 6. Configuration d'un réseau VPC partagé qui utilise plusieurs hôtes et projets de service isolés (environnements de test et de production).
Architecture de services hybrides
L'architecture de services hybrides fournit des services cloud natifs supplémentaires conçus pour vous permettre de connecter et de sécuriser des services dans un environnement multi-VPC. Ces services cloud natifs complètent les fonctionnalités disponibles dans l'architecture de migration Lift and Shift et peuvent faciliter la gestion à grande échelle d'un environnement segmenté par VPC.
Private Service Connect
Private Service Connect permet à un service hébergé sur un réseau VPC d'être mis à disposition dans un autre réseau VPC. Il n'est pas nécessaire que les services soient hébergés par la même ressource d'organisation. Par conséquent, vous pouvez utiliser Private Service Connect pour utiliser des services de manière privée depuis un autre réseau VPC, même s'il est associé à une autre ressource d'organisation.
Private Service Connect peut être utilisé de deux manières : pour accéder aux API Google ou pour accéder à des services hébergés sur d'autres réseaux VPC.
Utiliser Private Service Connect pour accéder aux API Google
Lorsque vous utilisez Private Service Connect, vous pouvez exposer les API Google à l'aide d'un point de terminaison Private Service Connect faisant partie de votre réseau VPC, comme illustré à la Figure 7.
Figure 7 : Configuration de Private Service Connect permettant d'envoyer du trafic vers les API Google à l'aide d'un point de terminaison Private Service Connect réservé à votre réseau VPC.
Les charges de travail peuvent envoyer du trafic vers un groupe d'API Google mondiales à l'aide d'un point de terminaison Private Service Connect. En outre, vous pouvez utiliser un backend Private Service Connect pour accéder à une API Google spécifique, ce qui étend les fonctionnalités de sécurité des équilibreurs de charge aux services d'API. La figure 8 illustre cette configuration.
Figure 8. Configuration de Private Service Connect pour envoyer du trafic vers les API Google à l'aide d'un backend Private Service Connect.
Utiliser Private Service Connect entre des réseaux ou des entités VPC
Private Service Connect permet également à un producteur de services de proposer des services à un client sur un autre réseau VPC, que celui-ci se trouve dans la même ressource d'organisation ou dans une autre. Un réseau VPC producteur de services peut prendre en charge plusieurs clients de service. Le client peut se connecter au service producteur en envoyant du trafic vers un point de terminaison Private Service Connect situé dans le réseau VPC du client. Le point de terminaison transfère le trafic au réseau VPC contenant le service publié.
Figure 9. Configuration de Private Service Connect pour publier un service géré via un rattachement de service et consommer le service via un point de terminaison.
Connecteur d'accès sans serveur au VPC
Un connecteur d'accès sans serveur au VPC gère le trafic entre votre environnement sans serveur et votre réseau VPC. Lorsque vous créez un connecteur dans votre projet Google Cloud, vous l'associez à un réseau VPC et à une région spécifiques. Vous pouvez ensuite configurer vos services sans serveur de sorte qu'ils utilisent le connecteur pour le trafic réseau sortant. Vous pouvez spécifier un connecteur en utilisant un sous-réseau ou une plage CIDR. Le trafic envoyé via le connecteur au réseau VPC provient du sous-réseau ou de la plage CIDR que vous avez spécifiée, comme illustré dans la figure 10.
Figure 10. Configuration d'un connecteur d'accès au VPC sans serveur pour accéder aux environnements sans serveur Google Cloud à l'aide d'adresses IP internes au sein de votre réseau VPC.
Les connecteurs d'accès au VPC sans serveur sont compatibles avec toutes les régions qui prennent en charge Cloud Run, Cloud Functions ou l'environnement standard App Engine. Pour plus d'informations, consultez la liste des services compatibles et des protocoles réseau compatibles pour l'utilisation d'un connecteur d'accès sans serveur au VPC.
VPC Service Controls
VPC Service Controls vous permet d'éviter l'exfiltration de données à partir de services tels que Cloud Storage ou BigQuery, en empêchant les accès autorisés depuis Internet ou depuis des projets situés en dehors d'un périmètre de sécurité. Par exemple, considérons un scénario dans lequel une erreur humaine ou une automatisation incorrecte entraîne la définition incorrecte de stratégies IAM sur un service tel que Cloud Storage ou BigQuery, avec pour résultat de rendre les ressources de ces services accessibles au public. Dans ce cas, il existe un risque d'exposition des données. Si ces services sont configurés pour être inclus dans le périmètre VPC Service Controls, l'accès entrant aux ressources est bloqué, et ce même si les stratégies IAM autorisent l'accès.
VPC Service Controls peut créer des périmètres basés sur des attributs client tels que le type d'identité (compte de service ou utilisateur) et l'origine du réseau (adresse IP ou réseau VPC).
VPC Service Controls permet de limiter les risques de sécurité suivants :
- Accès depuis des réseaux non autorisés avec des identifiants volés.
- Exfiltration de données due à des attaques internes malveillantes ou à du code compromis.
- Exposition publique de données privées en raison d'une configuration erronée des stratégies IAM.
La figure 11 montre comment VPC Service Controls vous permet d'établir un périmètre de service pour contribuer à limiter ces risques.
Figure 11. Périmètre de service VPC étendu aux environnements hybrides à l'aide de services d'accès privé.
À l'aide de règles d'entrée et de sortie, vous pouvez activer la communication entre deux périmètres de service, comme illustré dans la figure 12.
Figure 12. Configurer des règles d'entrée et de sortie pour la communication entre périmètres de service.
Pour obtenir des recommandations détaillées sur les architectures de déploiement de VPC Service Controls, consultez la page Concevoir et implémenter des périmètres de service. Pour en savoir plus sur la liste des services pris en charge par VPC Service Controls, consultez la page Produits compatibles et limites.
Architecture distribuée zéro confiance
Les contrôles de sécurité du périmètre réseau sont nécessaires, mais non suffisants pour respecter les principes de sécurité du moindre privilège et de défense en profondeur. Les architectures distribuées zéro confiance s'appuient entre autres (mais pas uniquement) sur la périphérie du périmètre réseau pour l'application de la sécurité. En tant qu'architectures distribuées, elles sont composées de microservices avec une application des règles de sécurité, une authentification forte et une identité de charge de travail par service.
Vous pouvez mettre en œuvre des architectures distribuées zéro confiance en tant que services gérés par Cloud Service Mesh et Cloud Service Mesh.
Cloud Service Mesh
Cloud Service Mesh peut être configuré pour fournir un maillage de microservices d'architecture distribuée zéro confiance dans un cluster GKE à l'aide de la sécurité des services. Dans ce modèle, dans les services GKE disposant de side-cars Envoy ou de gRPC sans proxy, l'identité, les certificats et les règles d'autorisation sont tous gérés par l'ensemble des éléments suivants : Cloud Service Mesh, Workload Identity, Certificate Authority Service et IAM. La gestion des certificats et la dénomination sécurisée sont fournies par la plate-forme, et toutes les communications des services sont soumises à la sécurité de transport mTLS. La figure 13 illustre un cluster doté de cette configuration.
Figure 13. Maillage d'architecture distribuée zéro confiance à cluster unique utilisant Cloud Service Mesh.
Une règle d'autorisation spécifie la manière dont un serveur autorise les requêtes entrantes ou les RPC. La règle d'autorisation peut être configurée pour autoriser ou refuser une requête entrante ou un RPC en fonction de divers paramètres, tels que l'identité du client ayant émis la requête, l'hôte, les en-têtes et d'autres attributs HTTP. Des consignes d'implémentation sont disponibles pour configurer des règles d'autorisation sur des maillages basés sur gRPC et Envoy.
Dans la Figure 13, l'architecture comporte un seul cluster et un réseau plat (espace d'adresses IP partagé). Plusieurs clusters sont généralement utilisés dans une architecture distribuée zéro confiance pour l'isolation, l'emplacement et le scaling.
Dans les environnements plus complexes, plusieurs clusters peuvent partager une identité gérée lorsque les clusters sont regroupés à l'aide de parcs. Dans ce cas, vous pouvez configurer la connectivité réseau entre réseaux VPC indépendants à l'aide de Private Service Connect. Cette approche est semblable à celle de la connectivité réseau multicluster pour l'accès aux charges de travail hybrides, comme décrit plus loin dans ce document.
Pour en savoir plus sur le contrôle précis de la gestion du trafic avec Cloud Service Mesh, consultez la page Présentation de la gestion avancée du trafic.
Cloud Service Mesh
Cloud Service Mesh fournit un maillage prêt à l'emploi de microservices d'architecture distribuée zéro confiance mTLS, basé sur Istio. Vous configurez le maillage à l'aide d'un flux intégré. Le service Cloud Service Mesh géré, avec des plans de contrôle et de données gérés par Google, est compatible avec GKE. Un plan de contrôle dans le cluster est également disponible et adapté à d'autres environnements tels que Google Distributed Cloud ou GKE Multi-cloud. Cloud Service Mesh gère pour vous l'identité et les certificats en fournissant un modèle de stratégie d'autorisation basé sur Istio.
Cloud Service Mesh s'appuie sur des parcs pour gérer la configuration et l'identité lors du déploiement de services multiclusters. Comme avec Cloud Service Mesh, lorsque vos charges de travail fonctionnent dans un environnement de connectivité réseau VPC plat (ou partagé), il n'y a pas d'exigences particulières concernant la connectivité réseau en dehors de la configuration du pare-feu. Lorsque votre architecture comprend plusieurs clusters Cloud Service Mesh répartis sur des réseaux VPC ou des environnements réseau distincts, par exemple via une connexion Cloud Interconnect, vous avez également besoin d'une passerelle est-ouest. Les bonnes pratiques de mise en réseau pour Cloud Service Mesh sont identiques à celles décrites dans la section Bonnes pratiques pour la mise en réseau GKE.
Cloud Service Mesh s'intègre également à Identity-Aware Proxy (IAP). IAP vous permet de définir des règles d'accès précises pour contrôler l'accès des utilisateurs à une charge de travail en fonction des attributs de la requête d'origine, tels que l'identité de l'utilisateur, l'adresse IP et le type d'appareil. Ce niveau de contrôle permet d'obtenir un environnement zéro confiance de bout en bout.
Vous devez tenir compte de la configuration requise pour les clusters GKE lorsque vous utilisez Cloud Service Mesh. Pour plus d'informations, consultez la section Configuration requise dans la documentation "Installation d'un projet unique sur GKE".
Étapes suivantes
- Mise en réseau pour la diffusion d'applications Web : architectures de référence
- Mise en réseau pour les charges de travail hybrides et multicloud : Architectures de référence
- Consultez la page Migration vers Google Cloud, qui peut vous aider à planifier, à concevoir et à mettre en œuvre le processus de migration de vos charges de travail vers Google Cloud.
- La section Conception des zones de destination dans Google Cloud fournit des conseils pour créer un réseau de zones de destination.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.