Ce guide présente les bonnes pratiques et les architectures d'entreprise types pour la conception de clouds privés virtuels (VPC, Virtual Private Cloud) avec Google Cloud. Ce guide s'adresse aux architectes de réseaux cloud et aux architectes de système qui connaissent déjà les concepts de mise en réseau Google Cloud .
Principes généraux et premières étapes
Identifiez les décideurs, les échéances et le travail préparatoire.
Penchez-vous tôt sur la conception des réseaux VPC.
Recherchez la simplicité.
Utilisez des conventions d'attribution de noms claires.
Identifier les décideurs, les échéances et le travail préparatoire
La première étape de la conception de votre réseau VPC consiste à identifier les décideurs, les échéances et le travail préparatoire vous permettant de répondre aux exigences des parties prenantes.
Les parties prenantes peuvent inclure les propriétaires d'applications, les architectes de sécurité, les architectes de solutions et les responsables des opérations. Les parties prenantes elles-mêmes peuvent changer selon que vous planifiez votre réseau VPC pour un projet, un secteur d'activité ou l'ensemble de l'organisation.
Une partie du travail préparatoire consiste à familiariser l'équipe avec les concepts et la terminologie relatifs à la conception des réseaux VPC. Voici des documents utiles :
- Documentation de Resource Manager
- Documentation sur Identity and Access Management (IAM)
- Documentation sur les clouds privés virtuels (VPC, Virtual Private Cloud)
Penchez-vous tôt sur la conception des réseaux VPC
Veillez à aborder la conception des réseaux VPC au début du processus de conception de votre organisation dans Google Cloud. Si vous devez modifier des éléments fondamentaux ultérieurement tels que la segmentation de votre réseau ou l'emplacement de vos charges de travail, cela peut perturber votre organisation.
Des configurations de réseaux VPC différentes peuvent avoir de profondes répercussions en matière de routage, de scaling et de sécurité. Une planification minutieuse et une compréhension approfondie de vos caractéristiques spécifiques vous aident à créer une base architecturale solide pour les charges de travail incrémentielles.
Rechercher la simplicité
Le meilleur moyen d'assurer la gestion, la fiabilité et la compréhension d'une architecture est de maintenir la simplicité de conception de votre topologie de réseaux VPC.
Utiliser des conventions de nommage claires
Rendez vos conventions de nommage simples, intuitives et cohérentes. Ainsi, les administrateurs et les utilisateurs finaux comprennent l'objectif de chaque ressource, son emplacement et sa différence par rapport aux autres ressources.
Vous pouvez utiliser les abréviations communément acceptées pour les mots longs à des fins de concision. Dans la mesure du possible, utilisez une terminologie familière pour assurer la lisibilité.
Prenez en compte les composants illustrés dans l'exemple suivant lorsque vous établissez vos conventions d'attribution de noms :
- Nom de l'entreprise : Compagnie Acme :
acmeco - Unité commerciale : Ressources humaines :
hr - Code de l'application : Système de rémunération :
comp - Code de région : northamerica-northeast1 :
na-ne1, europe-west1 :eu-we1 - Codes de l'environnement :
dev,test,uat,stage,prod
Dans cet exemple, l'environnement de développement du système de rémunération du département des ressources humaines est nommé acmeco-hr-comp-eu-we1-dev.
Pour les autres ressources réseau courantes, envisagez des modèles tels que les suivants :
Syntaxe du réseau VPC
:{company name}-{description(App or BU)-label}-{environment-label}-{seq#}
exemple :acmeco-hr-dev-vpc-1Sous-réseau
Syntaxe :{company-name}-{description(App or BU)-label}-{region-label}-{environment-label}-{subnet-label}
Exemple :acmeco-hr-na-ne1-dev-vpc-1-subnet-1
Remarque : Si un sous-réseau ne contient des ressources que dans une zone, vous pouvez utiliser "zone-label" au lieu de "region-label".Syntaxe de la règle de pare-feu
:{company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
exemple :acmeco-hr-internet-internal-tcp-80-allow-ruleSyntaxe de la route IP
:{priority}-{VPC-label}-{tag}-{next hop}
exemple :1000-acmeco-hr-dev-vpc-1-int-gw
Adresses et sous-réseaux
Utilisez des sous-réseaux en mode personnalisé dans les réseaux VPC de votre entreprise.
Regroupez les applications dans un nombre réduit de sous-réseaux avec des plages d'adresses plus étendues.
Utiliser des réseaux VPC en mode personnalisé
Même si les réseaux VPC en mode automatique peuvent être utiles pour une exploration préliminaire, ceux en mode personnalisé sont davantage adaptés à la plupart des environnements de production.
Nous recommandons aux entreprises d'utiliser dès le départ les réseaux VPC en mode personnalisé pour les raisons suivantes :
- Les réseaux VPC en mode personnalisé s'intègrent mieux dans les schémas existants de gestion des adresses IP. Étant donné que tous les réseaux en mode automatique utilisent le même ensemble de plages d'adresses IP internes, ces plages peuvent se chevaucher lorsqu'elles sont connectées à vos réseaux d'entreprise sur site.
- Vous ne pouvez pas connecter deux réseaux VPC en mode automatique à l'aide de l'appairage de réseaux VPC, car leurs sous-réseaux utilisent des plages d'adresses IP principales identiques.
- Les sous-réseaux en mode automatique portent le même nom que le réseau. Vous pouvez choisir des noms descriptifs uniques pour les sous-réseaux en mode personnalisé, rendant ainsi vos réseaux VPC plus compréhensibles et faciles à gérer.
- Lorsqu'une nouvelle région Google Cloud est introduite, les réseaux VPC en mode automatique obtiennent automatiquement un nouveau sous-réseau dans cette région. Les réseaux VPC en mode personnalisé n'obtiennent de nouveaux sous-réseaux que si vous les spécifiez. Cela peut être important pour des raisons de souveraineté et de gestion des adresses IP.
S'il ne dispose d'aucune ressource, vous pouvez supprimer le réseau default. Vous ne pouvez pas supprimer un réseau VPC tant que vous n'avez pas supprimé toutes les ressources (y compris les instances de VM) qui en dépendent.
Pour plus de détails sur les différences entre les réseaux VPC en mode automatique et en mode personnalisé, consultez la page Présentation du réseau VPC.
Regrouper les applications dans un nombre moins élevé de sous-réseaux avec des plages d'adresses plus étendues
De manière conventionnelle, certains réseaux d'entreprise sont séparés en de nombreuses petites plages d'adresses pour diverses raisons. Par exemple, pour identifier ou isoler une application, ou pour conserver un petit domaine de diffusion.
Toutefois, nous vous recommandons de regrouper les applications du même type dans un nombre moins élevé de sous-réseaux, plus faciles à gérer et dotés de plages d'adresses plus étendues, dans les régions que vous souhaitez exploiter.
Contrairement aux autres environnements réseau dans lesquels un masque de sous-réseau est utilisé,Google Cloud utilise une approche de réseau défini par logiciel (SDN, Software-Defined Networking) pour fournir un maillage complet de joignabilité entre toutes les VM du réseau VPC global. Le nombre de sous-réseaux n'affecte pas le comportement de routage.
Vous pouvez appliquer des règles de routage ou des règles de pare-feu spécifiques à l'aide de comptes de service ou de tags réseau. L'identité dans Google Cloud ne repose pas uniquement sur l'adresse IP du sous-réseau.
Certaines fonctionnalités des VPC, y compris Cloud NAT, l'accès privé à Google, les journaux de flux VPC et les plages d'adresses IP d'alias, sont configurées par sous-réseau. Si vous avez besoin d'exercer un contrôle plus précis sur ces fonctionnalités, utilisez des sous-réseaux supplémentaires.
Réseau VPC unique et VPC partagé
Commencez par utiliser un seul réseau VPC pour les ressources ayant des exigences communes.
Administrez plusieurs groupes de travail à l'aide du VPC partagé.
Accordez le rôle d'utilisateur réseau au niveau du sous-réseau.
Utilisez un seul projet hôte si les ressources requièrent plusieurs interfaces réseau.
Utilisez plusieurs projets hôtes si les ressources nécessaires dépassent le quota d'un seul projet.
Utilisez plusieurs projets hôtes si vous avez besoin de règles d'administration distinctes pour chaque VPC.
Commencer par utiliser un seul VPC pour les ressources ayant des exigences communes
Dans de nombreux cas d'utilisation simples, un seul réseau VPC fournit les fonctionnalités dont vous avez besoin, tout en étant plus facile à créer, à gérer et à comprendre que les alternatives plus complexes. En regroupant les ressources ayant des exigences et des caractéristiques communes dans un seul réseau VPC, vous commencez à établir la frontière du VPC comme périmètre des problèmes potentiels.
Pour obtenir un exemple de cette configuration, consultez l'architecture de référence Un seul projet, un seul réseau VPC.
Parmi les facteurs susceptibles de vous amener à créer des réseaux VPC supplémentaires figurent le scaling, la sécurité du réseau, des aspects financiers, des exigences opérationnelles et la gestion de l'authentification et des accès (IAM, Identity and Access Management).
Administrer plusieurs groupes de travail à l'aide du VPC partagé
Pour les organisations comprenant plusieurs équipes, le VPC partagé constitue un outil efficace pour étendre la simplicité architecturale d'un réseau VPC unique à plusieurs groupes de travail. L'approche la plus simple consiste à déployer un seul projet hôte de VPC partagé avec un seul réseau VPC partagé, puis à rattacher des projets de service d'équipe au réseau du projet hôte.
Dans cette configuration, les règles réseau et le contrôle de toutes les ressources réseau sont centralisés et faciles à gérer. Les départements des projets de service peuvent configurer et gérer des ressources hors réseau, ce qui permet une séparation claire des responsabilités entre les différentes équipes de l'organisation.
Les ressources de ces projets peuvent communiquer entre elles de manière plus sécurisée et plus efficace sur l'ensemble des limites des projets à l'aide d'adresses IP internes. Vous pouvez gérer les ressources réseau partagées (telles que des sous-réseaux, des routes et des pare-feu) à partir d'un projet hôte central, afin de pouvoir appliquer des règles réseau cohérentes à l'ensemble des projets.
Pour obtenir un exemple de cette configuration, consultez l'architecture de référence Un seul projet hôte, plusieurs projets de service, un seul VPC partagé.
Accorder le rôle d'utilisateur réseau au niveau du sous-réseau
L'administrateur de VPC partagé centralisé peut octroyer aux membres le rôle d'utilisateur réseau (networkUser) soit au niveau d'un sous-réseau, pour obtenir une autorisation spécifique à un projet de service, soit pour tous les sous-réseaux au niveau du projet hôte.
Conformément au principe du moindre privilège, nous vous recommandons d'attribuer le rôle d'utilisateur réseau au niveau du sous-réseau à l'utilisateur, au compte de service ou au groupe associé.
Étant donné que les sous-réseaux sont régionaux, ce contrôle précis vous permet de spécifier les régions que chaque projet de service peut utiliser pour déployer des ressources.
Avec les architectures de VPC partagé, vous avez également la possibilité de déployer plusieurs projets hôtes de VPC partagé au sein de votre organisation. Chaque projet hôte de VPC partagé peut alors accueillir un seul ou plusieurs réseaux VPC partagés. Dans cette configuration, différents environnements peuvent résoudre différentes questions en matière de règles.
Pour en savoir plus, consultez la page Rôles IAM pour la mise en réseau.
Utiliser un seul projet hôte si les ressources requièrent plusieurs interfaces réseau
Si vous disposez d'un projet de service devant déployer des ressources sur plusieurs réseaux VPC isolés, par exemple des instances de VM dotées de plusieurs interfaces réseau, votre projet hôte doit contenir tous les réseaux VPC fournissant les services. Cela est dû au fait qu'un projet de service ne peut être associé qu'à un seul projet hôte.
Utiliser plusieurs projets hôtes si les ressources nécessaires dépassent le quota d'un seul projet
Si le quota d'un projet ne permet pas de répondre aux exigences de ressources agrégées de tous les réseaux VPC, utilisez une architecture comportant plusieurs projets hôtes dotés chacun d'un seul réseau VPC partagé, plutôt qu'un seul projet hôte doté de plusieurs réseaux VPC partagés. Il est important d'évaluer vos exigences en matière de scaling, car ce type d'architecture nécessite que le projet hôte contienne plusieurs réseaux VPC, et les quotas sont appliqués au niveau du projet.
Pour obtenir un exemple de cette configuration, consultez l'architecture de référence Plusieurs projets hôtes, plusieurs projets de service, plusieurs VPC partagés.
Utiliser plusieurs projets hôtes si vous avez besoin de règles d'administration distinctes pour chaque réseau VPC
Étant donné que chaque projet possède son propre quota, utilisez un projet hôte de réseau VPC partagé distinct pour chaque réseau VPC afin de procéder au scaling des ressources agrégées. Chaque réseau VPC dispose ainsi d'autorisations IAM distinctes pour la gestion de réseau et de la sécurité, car ces autorisations sont également mises en œuvre au niveau du projet. Par exemple, si vous déployez deux réseaux VPC (réseau VPC A et réseau VPC B) dans le même projet hôte, le rôle d'administrateur réseau (networkAdmin) s'applique aux deux réseaux VPC.
Décider s'il convient de créer plusieurs réseaux VPC
Créez un seul réseau VPC par projet pour mapper les quotas du réseau VPC avec les projets.
Créez un réseau VPC pour chaque équipe autonome, en plaçant les services partagés dans un réseau VPC commun.
Créez des réseaux VPC dans différents projets pour obtenir des contrôles IAM indépendants.
Isolez les données sensibles dans leur propre réseau VPC.
Créer un seul réseau VPC par projet pour mapper les quotas de ressources des VPC avec les projets
Les quotas sont des contraintes appliquées au niveau du projet ou du réseau. Toutes les ressources disposent d'un quota par défaut initial destiné à vous protéger contre toute utilisation inattendue des ressources. Toutefois, de nombreux facteurs peuvent vous amener à demander plus de quota. Pour la plupart des ressources, vous pouvez demander un quota supplémentaire.
Nous vous recommandons de créer un seul réseau VPC par projet si vous prévoyez de dépasser les quotas de ressources VPC par défaut. Cela permet de mapper plus facilement les augmentations de quotas au niveau du projet avec chaque réseau VPC, plutôt qu'utiliser une combinaison de réseaux VPC dans le même projet.
Les limites sont conçues pour protéger les ressources système de manière globale. En règle générale, elles ne peuvent pas être relevées facilement, même si les équipes de vente et d'assistance deGoogle Cloud peuvent vous aider à augmenter certaines limites.
Pour connaître les valeurs actuelles, consultez la section Quotas et limites applicables aux ressources VPC.
L'assistance Google peut augmenter certaines limites de scaling, mais il peut arriver que vous ayez besoin de créer plusieurs réseaux VPC pour répondre à vos exigences en la matière. Si les besoins de scaling de votre réseau VPC dépassent les limites, discutez-en avec les équipes de vente et d'assistance deGoogle Cloud afin de déterminer la meilleure approche à adopter.
Créer un réseau VPC pour chaque équipe autonome, en plaçant les services partagés dans un réseau VPC commun
Certains déploiements de grandes entreprises impliquent des équipes autonomes ayant chacune besoin d'exercer un contrôle total sur leurs réseaux VPC respectifs. Pour répondre à cette exigence, vous pouvez créer un réseau VPC pour chaque unité commerciale, avec des services partagés dans un réseau VPC commun (par exemple, outils d'analyse, pipeline CI/CD et machines de compilation, services d'annuaire/DNS).
Créer des réseaux VPC dans différents projets pour obtenir des contrôles IAM indépendants.
Un réseau VPC est une ressource au niveau du projet dotée de contrôles de gestion de l'authentification et des accès (IAM) précis, également au niveau du projet. Ces derniers incluent les rôles suivants :
networkAdminsecurityAdminnetworkUsernetworkViewer
Par défaut, les contrôles IAM sont déployés au niveau du projet, et chaque rôle IAM s'applique à l'ensemble des réseaux VPC qu'il contient.
Si vous avez besoin de contrôles IAM indépendants par réseau VPC, créez vos réseaux VPC dans différents projets.
Si vous avez besoin de rôles IAM associés à des ressources Compute Engine spécifiques, telles que des instances de VM, des disques et des images, utilisez les stratégies IAM applicables aux ressources Compute Engine.
Isoler les données sensibles dans leur propre réseau VPC
Pour les entreprises qui gèrent des initiatives de conformité, des données sensibles ou des données strictement réglementées qui doivent respecter des normes de conformité telles que HIPAA ou PCI-DSS, la mise en place de mesures de sécurité supplémentaires est souvent judicieuse. Une méthode permettant d'améliorer la sécurité et d'assurer plus facilement la conformité consiste à isoler chacun de ces environnements dans leur propre réseau VPC.
Se connecter aux différents réseaux VPC
Choisissez la méthode de connexion VPC répondant à vos besoins en matière de coûts, de performances et de sécurité.
Utilisez les spokes VPC Network Connectivity Center.
Utilisez l'appairage de réseaux VPC si vous devez insérer des NVA ou si votre application n'est pas compatible avec Private Service Connect.
Utilisez le routage externe si vous n'avez pas besoin de communications par adresse IP privée.
Servez-vous de Cloud VPN pour connecter des réseaux VPC qui hébergent des points d'accès aux services qui ne sont pas accessibles de manière transitoire via Network Connectivity Center.
Utilisez des dispositifs virtuels dotés de plusieurs cartes d'interface réseau pour contrôler le trafic entre les réseaux VPC via un appareil cloud.
Choisir la méthode de connexion VPC répondant à vos besoins en matière de coûts, de performances et de sécurité
Une fois que vous avez décidé de mettre en œuvre plusieurs réseaux VPC, la prochaine étape consiste à les connecter. Les réseaux VPC sont des espaces locataires isolés au sein du réseau défini par logiciel (SDN) Andromeda de Google, mais vous pouvez activer la communication entre eux de plusieurs façons. Les sections suivantes décrivent les bonnes pratiques à adopter lors de la sélection d'une méthode de connexion VPC.
Le tableau ci-dessous résume les avantages et les inconvénients de chacune de ces méthodes. Les sections suivantes indiquent les bonnes pratiques à adopter lors de la sélection d'une méthode de connexion VPC.
| Avantages | Inconvénients | |
|---|---|---|
| Spokes VPC Network Connectivity Center |
|
|
| Appairage de réseaux VPC |
|
|
| Routage externe (adresse IP publique ou passerelle NAT) |
|
|
| Cloud VPN |
|
|
| Plusieurs interfaces réseau (avec plusieurs cartes d'interface réseau) |
|
|
Utiliser les spokes VPC Network Connectivity Center
Nous vous recommandons d'utiliser des spokes VPC Network Connectivity Center lorsque vous devez connecter des réseaux VPC. Les spokes VPC Network Connectivity Center permettent de réutiliser des adresses dans des VPC appartenant au même projet et à la même organisation, ou à un autre projet et une autre organisation.
Les spokes VPC Network Connectivity Center sont la méthode recommandée pour connecter des réseaux VPC pour les raisons suivantes :
- Le plan de données est distribué, il n'y a donc pas de goulot d'étranglement au niveau de la passerelle. Le trafic transite par les réseaux VPC comme si les VM se trouvaient dans le même réseau VPC.
- Connectivité entre les réseaux de différentes organisations. Les réseaux incluent les VPC et les réseaux externes.
- Jusqu'à 250 réseaux VPC par hub.
- Joignabilité transitive entre les VPC des points d'accès aux services.
- Cloud NAT inter-VPC intégré pour permettre la réutilisation des adresses IP dans les VPC.
- Définition de règles d'accessibilité réseau à l'aide de topologies prédéfinies et de filtres de préfixe.
Utilisez l'appairage de réseaux VPC si vous devez insérer des NVA ou si votre application n'est pas compatible avec Private Service Connect.
Nous vous recommandons d'utiliser le peering de réseaux VPC si vous devez insérer des appliances virtuelles réseau (NVA), telles que des VM de pare-feu. Vous devrez peut-être insérer des NVA pour le trafic qui traverse plusieurs réseaux VPC ou pour la connectivité privée aux services qui ne sont pas publiés à l'aide de Private Service Connect.
Lorsque vous utilisez le peering de réseaux VPC, assurez-vous que le total des ressources nécessaires pour tous les pairs directement connectés ne dépasse pas les limites concernant les instances de VM, le nombre de connexions de peering et les règles de transfert internes.
L'appairage de réseaux VPC permet à deux réseaux VPC de se connecter en interne via le SDN de Google, qu'ils appartiennent ou non au même projet ou à la même organisation. Cette méthode de connexion fusionne le plan de contrôle et la propagation du flux entre chaque pair. Les caractéristiques de transfert sont ainsi identiques à celles obtenues lorsque toutes les VM se trouvent dans le même réseau VPC. Lorsque les réseaux VPC sont appairés, l'ensemble des sous-réseaux, des plages d'adresses IP d'alias et des règles de transfert internes sont accessibles, et chaque réseau VPC gère son propre pare-feu distribué. L'appairage de réseaux VPC n'est pas transitif.
Utiliser le routage externe si aucune communication par adresse IP privée n'est nécessaire
Si vous n'avez pas besoin de communications par adresse IP privée, vous pouvez utiliser un routage externe avec des adresses IP externes ou une passerelle NAT.
Lorsqu'un réseau VPC est déployé, une route vers la passerelle Internet par défaut de Google est configurée avec une priorité de 1 000. Si cette route existe et qu'une adresse IP externe est attribuée à une VM, les VM peuvent envoyer du trafic sortant via la passerelle Internet de Google. Vous pouvez également déployer des services derrière l'une des nombreuses solutions d'équilibrage de charge public de Google, ce qui rend les services joignables en externe.
Les VM à adresse externe communiquent entre elles de manière privée via le réseau backbone de Google, quels que soient la région et les niveaux de service réseau. Contrôlez le trafic entrant vers vos VM à l'aide des règles de pare-feu Google Cloud .
Le routage externe est une bonne option en matière de scaling, mais il est important de comprendre l'incidence du routage public sur les coûts. Pour en savoir plus, consultez la documentation sur les prix de la mise en réseau.
Utilisez Cloud VPN pour connecter des réseaux VPC qui hébergent des points d'accès aux services qui ne sont pas accessibles de manière transitive via Network Connectivity Center.
Les VPN haute disponibilité fournissent un service géré permettant de connecter des réseaux VPC en créant des tunnels IPsec entre des ensembles de points de terminaison. Si vous configurez vos routeurs Cloud Router avec des mode d'annonce personnalisés, vous pouvez activer le routage transitif entre les réseaux VPC et les topologies en étoile, comme décrit plus loin dans ce document. À l'aide de Network Connectivity Center, vous pouvez utiliser des tunnels VPN haute disponibilité en tant que réseau de transit entre les réseaux sur site, comme expliqué dans la documentation Cloud VPN.
Cloud VPN n'accepte pas les MTU volumineuses. Pour en savoir plus, consultez la section Considérations relatives aux MTU.
Utiliser des dispositifs virtuels pour contrôler le trafic entre les réseaux VPC via un appareil cloud
Les VM dotées de plusieurs interfaces réseau sont courantes pour les réseaux VPC qui nécessitent une sécurité ou des services supplémentaires entre eux, car elles permettent aux instances de VM d'établir la communication entre les réseaux VPC.
Une VM ne peut disposer que d'une seule interface pour chaque réseau VPC auquel elle se connecte. Pour déployer une VM dans plusieurs réseaux VPC, vous devez posséder l'autorisation IAM appropriée pour chaque réseau VPC auquel la VM se connecte.
Tenez compte des caractéristiques suivantes lorsque vous déployez une VM dotée de plusieurs cartes d'interface réseau :
- Une VM dotée de plusieurs cartes d'interface réseau peut comporter jusqu'à huit interfaces.
- Les plages d'adresses IP de sous-réseau des interfaces ne doivent pas se chevaucher.
Connectivité des services
Private Service Connect permet aux consommateurs d'accéder aux services de manière privée depuis leur réseau VPC, sans avoir besoin d'un modèle de déploiement orienté réseau. De même, il permet aux producteurs d'héberger ces services dans leurs propres réseaux VPC séparés et de proposer une connexion privée à leurs clients au sein de la même organisation ou entre plusieurs organisations. Private Service Connect permet la connectivité aux services gérés propriétaires et tiers, ce qui élimine le besoin d'allocation de sous-réseaux pour l'accès aux services privés et l'appairage de réseaux VPC.
Private Service Connect propose un modèle de sécurité axé sur les services, qui présente les avantages suivants :
- Aucune dépendance partagée
- Autorisation explicite
- Performances au débit maximal
Private Service Connect est disponible sous différents types offrant des fonctionnalités et des modes de communication différents :
- Points de terminaison Private Service Connect : les points de terminaison sont déployés à l'aide de règles de transfert qui fournissent au client une adresse IP mappée au service Private Service Connect.
- Backends Private Service Connect : les backends sont déployés à l'aide de groupes de points de terminaison du réseau (NEG) qui permettent aux clients de diriger le trafic vers leur équilibreur de charge avant qu'il n'atteigne un service Private Service Connect. Si les backends sont déployés avec un équilibreur de charge HTTPS, ils peuvent accepter les certificats.
- Interfaces Private Service Connect : les interfaces permettent au consommateur et au producteur d'initier du trafic, ce qui permet une communication bidirectionnelle. Les interfaces peuvent être utilisées sur le même réseau VPC que les points de terminaison et les backends.
Une alternative à Private Service Connect est l'accès aux services privés, qui permet aux consommateurs de connecter les services du producteur via l'appairage de réseaux VPC. Lorsque vous utilisez l'accès aux services privés, nous vous recommandons de tenir compte de l'allocation d'adresses IP pour chaque service de producteur, du chevauchement d'adresses IP et du quota partagé.
Conception hybride : connecter un environnement sur site
Utilisez le routage dynamique dans la mesure du possible.
Utilisez un réseau VPC de connectivité pour procéder au scaling d'une architecture en étoile avec plusieurs réseaux VPC.
Une fois que vous avez déterminé que vous avez besoin d'une connectivité hybride et que vous avez choisi une solution qui répond à vos exigences en matière de bande passante, de performances et de sécurité, réfléchissez à la manière de l'intégrer à votre conception de VPC.
Avec un VPC partagé, vous n'avez pas besoin de répliquer la même solution pour chaque projet. Par exemple, lorsque vous intégrez une solution Cloud Interconnect à un VPC partagé, toutes les VM, indépendamment de la région ou du projet de service, peuvent accéder à la connexion Cloud Interconnect.
Utiliser le routage dynamique si possible
Le routage dynamique est disponible sur toutes les solutions hybrides, y compris le VPN haute disponibilité, le VPN classique, l'interconnexion dédiée et l'interconnexion partenaire. Il utilise le routeur cloud de Google en tant que speaker BGP (Border Gateway Protocol) pour fournir un routage BGP externe (eBGP) dynamique.
Le routeur cloud ne se trouve pas dans le plan de données, il crée seulement des routes dans le SDN.
Le routage dynamique n'utilise pas de tags, et le routeur cloud ne réannonce jamais les préfixes appris.
Vous pouvez activer l'un ou l'autre des modes du routeur cloud (régional ou global) sur chaque réseau VPC. Si vous optez pour le routage régional, le routeur cloud n'annonce que les sous-réseaux co-résidant dans la région où il est déployé. En revanche, le routage global annonce tous les sous-réseaux du réseau VPC donné, quelle que soit la région, mais pénalise les routes annoncées et apprises en dehors de la région. Cela maintient la symétrie au sein de la région, en privilégiant toujours une interconnexion locale. Le calcul est effectué en ajoutant une métrique de pénalité (MED) égale à 200 + valeur TTL en millisecondes entre les régions.
Routage statique
Le routage statique n'est disponible que sur le VPN standard. Il permet de définir une route jusqu'au saut suivant pointant vers un tunnel Cloud VPN.
Par défaut, une route statique s'applique à toutes les VM du réseau, quelle que soit la région. Le routage statique permet également aux administrateurs réseau de définir de manière sélective les VM auxquelles la route s'applique en utilisant des tags d'instance, qui peuvent être spécifiés lorsque vous créez une route.
Les routes statiques s'appliquent au réseau VPC de manière globale, chacune ayant la même priorité. Par conséquent, si vous disposez de plusieurs tunnels dans plusieurs régions avec le même préfixe et la même priorité, une VM utilisera le protocole ECMP basé sur un hachage à cinq tuples dans tous les tunnels. Pour optimiser cette configuration, vous pouvez créer une route intra-régionale préférée en référençant des tags d'instance pour chaque région et en créant des routes préférées en conséquence.
Si vous ne souhaitez pas que le trafic sortant passe par la passerelle Internet par défaut de Google, vous pouvez définir une route statique par défaut préférée pour renvoyer l'ensemble du trafic sur site via un tunnel.
Utiliser un réseau VPC de connectivité pour procéder au scaling d'une architecture en étoile avec plusieurs réseaux VPC
Si vous devez procéder au scaling d'une architecture en étoile avec plusieurs réseaux VPC, configurez une connectivité hybride centralisée dans un ou plusieurs réseaux VPC dédiés, puis ajoutez les connexions hybrides et tous les spokes VPC à un hub Network Connectivity Center. Vous devez activer l'échange de routes avec des spokes VPC. Cette configuration permet d'exporter des routes statiques ou apprises de manière dynamique vers des spokes VPC afin de fournir une configuration centralisée et de procéder au scaling de votre conception de réseau VPC.
Le schéma suivant illustre une conception de connectivité hybride centralisée à l'aide de Network Connectivity Center :
Vous pouvez également utiliser l'appairage de réseaux VPC et des routes annoncées personnalisées pour fournir un accès aux connexions hybrides partagées, si vous ne dépassez pas les limites de ressources et que vous devez utiliser des NVA.
Le schéma suivant illustre une connectivité hybride centralisée comportant des routes personnalisées d'appairage de réseau VPC :
Cette conception centralisée diffère du déploiement classique d'une connectivité hybride, qui utilise des tunnels VPN ou des rattachements de VLAN dans chaque réseau VPC.
Sécurité du réseau
Identifiez des objectifs de sécurité clairs.
Limiter l'accès externe
Définissez des périmètres de service pour les données sensibles.
Gérez le trafic avec des règles de pare-feu Google Cloud si possible.
Utilisez des ensembles de règles de pare-feu moins nombreux et plus étendus.
Isolez les VM à l'aide de comptes de service si possible.
Recourez à l'automatisation pour surveiller les règles de sécurité en cas d'utilisation de tags.
Utilisez des outils supplémentaires pour sécuriser et protéger vos applications.
Google Cloud fournit des fonctionnalités de sécurité robustes à travers son infrastructure et ses services, allant de la sécurité physique des centres de données au matériel de sécurité personnalisé, en passant par des équipes de chercheurs dédiées. Cependant, la sécurisation de vos ressourcesGoogle Cloud est une responsabilité partagée. Vous devez prendre les mesures appropriées pour vous assurer que vos applications et vos données sont protégées.
Identifier des objectifs de sécurité clairs
Avant d'évaluer des contrôles de sécurité cloud natifs ou compatibles avec le cloud, commencez par définir un ensemble d'objectifs de sécurité clairs que toutes les parties prenantes considèrent comme un élément fondamental du produit. Ces objectifs doivent mettre l'accent sur la réalisabilité, la documentation et l'itération, de manière à pouvoir être référencés et améliorés tout au long du développement.
Limiter l'accès externe
Lorsque vous créez une ressource Google Cloud qui utilise un réseau VPC, vous choisissez un réseau et un sous-réseau dans lesquels celle-ci réside. Une adresse IP interne issue de l'une des plages d'adresses IP associées au sous-réseau est attribuée à la ressource. Les ressources d'un réseau VPC peuvent communiquer entre elles via des adresses IP internes si les règles de pare-feu le permettent.
Limitez l'accès à Internet aux ressources qui en ont besoin. Les ressources disposant uniquement d'une adresse IP interne privée peuvent toujours accéder à de nombreux services et API Google via Private Service Connect ou l'accès privé à Google. L'accès privé permet aux ressources d'interagir avec les services clés de Google et de Google Cloud tout en restant isolées d'Internet.
En outre, utilisez des règles d'administration pour restreindre davantage les ressources autorisées à utiliser des adresses IP externes.
Pour autoriser les VM à accéder à Internet, utilisez Secure Web Proxy si le trafic peut être téléchargé via HTTP(S) et que vous souhaitez implémenter des contrôles d'identité. Sinon, utilisez Cloud NAT.
Définir des périmètres de service pour les données sensibles
Pour les charges de travail impliquant des données sensibles, utilisez VPC Service Controls pour configurer des périmètres de service autour de vos ressources VPC et services gérés par Google, ainsi que pour contrôler le déplacement des données au-delà des limites des périmètres. Grâce à ce service, vous pouvez regrouper les projets et votre réseau sur site dans un seul périmètre qui empêche l'accès aux données via les services gérés par Google. Les périmètres de service ne peuvent pas contenir de projets de différentes organisations, mais vous pouvez utiliser des liaisons de périmètre pour permettre aux projets et aux services situés dans des périmètres de service différents de communiquer.
Gérer le trafic avec des règles de pare-feu Google Cloud si possible
Google Cloud Le VPC comprend un pare-feu avec état à scaling horizontal et appliqué à chaque VM de manière distribuée. Pour en savoir plus, consultez la présentation de Cloud NGFW.
Google Cloud Marketplace propose un vaste écosystème de solutions tierces, y compris des VM offrant les fonctionnalités suivantes : sécurité avancée (par exemple, protection contre les fuites d'informations, les failles d'applications et l'élévation des privilèges), détection des menaces connues et inconnues, et application du filtrage par URL. La mise en place d'une seule règle de mise en œuvre de fournisseurs pour l'ensemble des fournisseurs de services cloud et des environnements sur site présente également des avantages opérationnels.
Le trafic est généralement acheminé vers ces VM en spécifiant des routes ayant la même priorité (pour le distribuer à l'aide d'un hachage à cinq tuples) ou des priorités différentes (pour créer un chemin redondant), comme indiqué dans les différents chemins d'accès au sous-réseau de développement (Dev-subnet) dans le schéma ci-après.
La plupart des solutions nécessitent plusieurs VM d'interface réseau. Comme une VM ne peut pas comporter plus d'une interface par réseau VPC, lorsque vous créez une VM dotée de plusieurs interfaces réseau, chaque interface doit être associée à un réseau VPC distinct.
Le scaling est également un aspect important à prendre en compte lors du déploiement de solutions tierces dans votre réseau VPC pour les raisons suivantes :
- Limites : la plupart des appliances basées sur des VM doivent être insérées dans le chemin de données. Cela nécessite une VM à plusieurs interfaces réseau qui relie plusieurs réseaux VPC résidant dans le même projet. Étant donné que les quotas de ressources des VPC est défini au niveau du projet, les besoins agrégés en ressources de tous les réseaux VPC peuvent devenir contraignants.
- Performances : l'introduction d'un seul goulot d'étranglement basé sur des VM dans les attributs d'évolutivité entièrement horizontale d'un réseau VPC va à l'encontre des méthodologies de conception cloud. Pour limiter ce problème, vous pouvez placer plusieurs dispositifs virtuels de réseau (NVA) dans un groupe d'instances géré derrière un équilibreur de charge réseau passthrough interne.
Pour tenir compte de ces facteurs dans les architectures exigeant un scaling élevé, stockez des contrôles de sécurité dans vos points de terminaison. Pour commencer, renforcez vos VM et utilisez des règles de pare-feu Google Cloud. Cette stratégie peut également impliquer l'introduction d'agents d'inspection de points de terminaison basés sur l'hôte qui ne modifient pas l'architecture de transfert de votre réseau VPC via les VM dotées de plusieurs interfaces réseau.
Pour obtenir un autre exemple de cette configuration, consultez l'architecture de référence Pare-feu L7 avec état entre les réseaux VPC.
Utiliser des ensembles de règles de pare-feu moins nombreux et plus étendus
Seul un certain nombre de règles peut être programmé sur une VM. Toutefois, vous pouvez combiner plusieurs règles en une définition de règle complexe. Par exemple, si toutes les VM du réseau VPC doivent autoriser explicitement 10 ports TCP d'entrée, deux possibilités s'offrent à vous : écrire 10 règles distinctes, chacune définissant un seul port, ou bien définir une seule règle incluant les 10 ports. Cette dernière option est la plus efficace.
Créez un ensemble de règles générique qui s'applique à l'ensemble du réseau VPC, puis utilisez des ensembles de règles plus spécifiques pour les regroupements de VM de plus petite taille qui utilisent des cibles. En d'autres termes, commencez par définir des règles générales, puis définissez-les progressivement de façon plus précise :
- Appliquez des règles de pare-feu communes à toutes les VM du réseau VPC.
- Appliquez des règles de pare-feu qui peuvent être regroupées sur plusieurs VM, comme un sous-réseau ou un groupe d'instances de service.
- Appliquez des règles de pare-feu à des VM individuelles, par exemple une passerelle NAT ou un hôte bastion.
Isoler les VM à l'aide de comptes de service si possible
De nombreuses organisations possèdent des environnements qui nécessitent des règles spécifiques pour un sous-ensemble de VM d'un réseau VPC. Dans ce cas de figure, vous pouvez adopter deux approches courantes : l'isolation de sous-réseau et le filtrage des cibles.
Isolation de sous-réseau
Avec l'isolation de sous-réseau, le sous-réseau constitue la limite de sécurité dans laquelle les règles de pare-feu Google Cloud sont appliquées. Cette approche est courante dans les constructions de réseau sur site, et dans les cas où les adresses IP et l'emplacement du réseau font partie de l'identité des VM.
Vous pouvez identifier les VM sur un sous-réseau spécifique en appliquant un Tag, un tag réseau ou un compte de service unique à ces instances. Cela vous permet de créer des règles de pare-feu qui ne s'appliquent qu'aux VM d'un sous-réseau, c'est-à-dire celles qui possèdent le tag, le tag réseau ou le compte de service associé. Par exemple, pour créer une règle de pare-feu autorisant toutes les communications entre des VM du même sous-réseau, vous pouvez utiliser la configuration de règles suivante sur la page Règles de pare-feu :
- Cibles : Tags cibles spécifiés
- Tags cibles : subnet-1 (sous-réseau 1)
- Filtre source : Sous-réseaux
- Sous-réseaux : sélectionnez le sous-réseau par son nom (par exemple, subnet-1)
Filtrage des cibles
Si vous optez pour le filtrage des cibles, toutes les VM résident sur le même sous-réseau ou font partie d'un ensemble arbitraire de sous-réseaux. Avec cette approche, l'appartenance au sous-réseau n'est pas considérée comme faisant partie de l'identité des instances pour les règles de pare-feu. À la place, vous pouvez utiliser des Tags, des tags réseau ou des comptes de service pour limiter l'accès entre des VM d'un même sous-réseau. Le même tag réseau est appliqué à chaque groupe de VM utilisant des règles de pare-feu identiques.
Pour illustrer cela, prenons l'exemple d'une application à trois niveaux (Web, application, base de données) pour laquelle toutes les instances sont déployées dans le même sous-réseau. Le niveau Web peut communiquer avec les utilisateurs finaux ainsi qu'avec le niveau application, lequel peut communiquer avec le niveau base de données, mais aucune autre communication entre les niveaux n'est autorisée. Les instances exécutant le niveau Web ont le tag réseau web, celles exécutant le niveau application ont le tag réseau app et celles exécutant le niveau base de données ont le tag réseau db.
Les règles de pare-feu suivantes mettent en œuvre cette approche :
| Règle 1 : Autoriser les utilisateurs finaux à communiquer avec le niveau Web | Cibles : Tags cibles spécifiés Tags cibles : Web Filtre source : plages d'adresses IP plages d'adresses IP sources : 0.0.0.0/0 |
| Règle 2 : Autoriser le niveau Web à communiquer avec le niveau application | Cibles : Tags cibles spécifiés Tags cibles : application Filtre source : Tags sources Tags sources : Web |
| Règle 3 : Autoriser le niveau application à communiquer avec le niveau base de données | Cibles : Tags cibles spécifiés Tags cibles : db Filtre source : Tags sources Tags sources : application |
Cependant, même s'il est possible d'utiliser les tags réseau de cette manière pour le filtrage des cibles, nous vous recommandons de recourir à des Tags ou des comptes de service lorsque cela est possible. L'accès aux tags cibles n'est pas contrôlé, et ceux-ci peuvent être modifiés par une personne dotée du rôle instanceAdmin lorsque les VM sont en service. L'accès aux Tags et comptes de service est contrôlé, ce qui signifie qu'un utilisateur spécifique doit être explicitement autorisé à les utiliser.
Il ne peut y avoir qu'un seul compte de service par instance, alors qu'il peut y avoir plusieurs tags. De plus, les comptes de service attribués à une VM ne peuvent être modifiés que lorsque celle-ci est arrêtée.
Recourir à l'automatisation pour surveiller les règles de sécurité en cas d'utilisation de tags
Si vous utilisez des tags réseau, n'oubliez pas qu'un administrateur d'instance peut les modifier. Cela peut contourner les règles de sécurité. Par conséquent, si vous utilisez des tags réseau dans un environnement de production, utilisez un framework d'automatisation pour vous aider à remédier au manque de gouvernance IAM sur ces tags réseau.
Utiliser des outils supplémentaires pour sécuriser et protéger vos applications
Outre les règles de pare-feu, utilisez les outils supplémentaires suivants pour sécuriser et protéger vos applications :
- Utilisez un équilibreur de charge HTTP(S) Google Cloud global pour assurer la haute disponibilité et la normalisation du protocole.
- Intégrez Google Cloud Armor à l'équilibreur de charge HTTP(S) pour offrir une protection contre les attaques DDoS ainsi que pour permettre le blocage ou l'autorisation des adresses IP à la périphérie du réseau.
- Contrôlez l'accès aux applications en utilisant IAP (Identity-Aware Proxy) pour vérifier l'identité de l'utilisateur et le contexte de la requête afin de déterminer si l'autorisation doit être accordée.
- Fournissez une seule interface pour les informations de sécurité, la détection des anomalies et la détection des failles avec Security Command Center.
Services réseau : NAT et DNS
Utilisez des adresses IP externes fixes avec Cloud NAT.
Réutilisez les adresses IP dans les VPC avec Cloud NAT.
Utilisez des zones DNS privées pour la résolution des noms.
Utiliser des adresses IP externes fixes avec Cloud NAT
Si vous avez besoin d'adresses IP externes fixes d'une plage de VM, utilisez Cloud NAT. Cela peut par exemple être le cas lorsqu'un tiers autorise les requêtes provenant d'adresses IP externes spécifiques. Cloud NAT vous permet de disposer pour chaque région d'un petit nombre d'adresses IP NAT à utiliser pour les communications sortantes.
Cloud NAT permet également à vos instances de VM de communiquer sur Internet sans qu'elles n'aient leurs propres adresses IP externes. Google Cloud Les règles de pare-feu sont avec état. Cela signifie que si une connexion est autorisée entre une source et une cible, ou une cible et une destination, l'intégralité du trafic lié dans l'un ou l'autre sens sera autorisée aussi longtemps que la connexion reste active. En d'autres termes, les règles de pare-feu permettent une communication bidirectionnelle une fois qu'une session est établie.
Réutiliser des adresses IP dans plusieurs VPC avec Cloud NAT
Les adresses IP peuvent être réutilisées dans les VPC lorsque Cloud NAT pour Network Connectivity Center est activé. Cloud NAT inter-VPC est disponible lorsque les VPC sont connectés à l'aide de spokes VPC Network Connectivity Center. Si les adresses IP du VPC chevauchent des plages dans des réseaux externes, activez Hybrid NAT. Seules les connexions initiées à partir de charges de travail dans Google Cloud vers des réseaux externes sont traduites.
Utiliser des zones DNS privées pour la résolution de noms
Utilisez des zones privées sur Cloud DNS pour autoriser la résolution de vos services avec le DNS de votre réseau VPC en utilisant leurs adresses IP internes sans exposer ce mappage à l'extérieur.
Utilisez le DNS fractionné pour mapper les services à des adresses IP depuis le réseau VPC différentes des adresses IP externes. Par exemple, l'un de vos services peut être exposé via un équilibrage de charge réseau à partir de l'Internet public, mais vous pouvez disposer d'un équilibrage de charge interne qui fournit le même service en utilisant le même nom DNS depuis le réseau VPC.
Accès aux API pour les services gérés par Google
Utilisez la passerelle Internet par défaut si possible.
Ajoutez des routes explicites pour les API Google si vous devez modifier la route par défaut du réseau VPC.
Déployez des instances qui utilisent les API Google sur le même sous-réseau.
Utiliser la passerelle Internet par défaut si possible
L'accès depuis les ressources se trouvant dans le réseau VPC aux API Google suit le saut suivant de la passerelle Internet par défaut. Malgré le nom de la passerelle jusqu'au saut suivant, le chemin du trafic allant des instances aux API Google reste dans le réseau de Google.
Par défaut, seules les instances de VM dotées d'une adresse IP externe peuvent communiquer avec les API et les services Google. Si vous avez besoin d'accéder à des instances dépourvues d'adresse IP externe, configurez les points de terminaison Private Service Connect ou utilisez la fonctionnalité d'accès privé à Google pour chaque sous-réseau. Cela ne ralentit pas les communications pour les API Google.
Google Kubernetes Engine (GKE) active automatiquement l'accès privé à Google sur les sous-réseaux où des nœuds sont déployés. Tous les nœuds de ces sous-réseaux sans adresse IP externe peuvent accéder aux services gérés de Google.
Ajouter des routes explicites pour les API Google si vous devez modifier la route par défaut du réseau VPC
Si vous devez modifier la route par défaut du réseau VPC, ajoutez des routes explicites pour les plages d'adresses IP de destination des API Google.
Dans les environnements où la route par défaut (0.0.0.0/0) n'utilise pas le saut suivant de la passerelle Internet par défaut, configurez des routes explicites pour les plages d'adresses IP de destination utilisées par les API Google. Définissez le saut suivant des routes explicites sur la passerelle Internet par défaut. Ce cas de figure se présente par exemple lorsque vous devez inspecter l'intégralité du trafic via un appareil sur site.
Déployer des instances qui utilisent les API Google sur le même sous-réseau
Déployez des instances nécessitant un accès aux services et API Google sur le même sous-réseau et activez l'accès privé à Google pour les instances sans adresse IP externe. Vous pouvez également configurer des points de terminaison Private Service Connect.
Si vous accédez aux API Google à partir de votre environnement sur site à l'aide de l'accès privé à Google, utilisez la page Configurer l'accès privé à Google pour les hôtes sur site pour accéder à certains services Google via des plages d'adresses IP privées. Vérifiez les services compatibles avant d'activer cette fonctionnalité, car l'accès aux autres API Google par le biais des adresses IP fournies par ce service sera impossible. L'activation de cette fonctionnalité peut nécessiter une configuration DNS supplémentaire, telle que la configuration de vues DNS.
Si vous accédez aux API Google à partir de votre environnement sur site à l'aide de points de terminaison Private Service Connect, consultez la page Accéder au point de terminaison à partir d'hôtes sur site pour en savoir plus.
Journalisation, surveillance et visibilité
Personnalisez la journalisation pour des audiences visées et des cas d'utilisation spécifiques.
Augmentez l'intervalle d'agrégation des journaux pour les réseaux VPC avec des connexions longues.
Utilisez l'échantillonnage des journaux de flux VPC pour réduire le volume.
Supprimez des métadonnées supplémentaires lorsque vous n'avez besoin que de données d'adresse IP et de port. Obtenir des insights sur vos réseaux à l'aide de Network Intelligence Center
Personnaliser la journalisation pour des audiences visées et des cas d'utilisation spécifiques
Utilisez les journaux de flux VPC pour la surveillance du réseau, l'investigation informatique, l'analyse de la sécurité en temps réel et l'optimisation des dépenses. Vous pouvez activer ou désactiver les journaux de flux du réseau VPC au niveau du sous-réseau. S'ils sont activés pour un sous-réseau, ils collectent les données issues de toutes les instances de VM de ce sous-réseau.
Ces journaux enregistrent un échantillon des flux du réseau que les instances de VM envoient et reçoivent. Vos cas d'utilisation de la journalisation permettent de déterminer les sous-réseaux pour lesquels vous décidez d'exiger la journalisation, et pour combien de temps.
Les journaux de flux sont regroupés par connexion, en intervalle de cinq secondes, à partir des VM Compute Engine, puis exportés en temps réel. Vous pouvez consulter les journaux de flux dans Cloud Logging et les exporter vers n'importe quelle destination compatible avec l'exportation de Cloud Logging.
La page relative à l'ingestion de journaux dans Logging suit le volume des journaux dans votre projet, et vous permet de désactiver l'ingestion pour tous les journaux d'ingestion ou d'exclure (de supprimer) les entrées qui ne vous intéressent pas. Vous pouvez ainsi réduire au minimum les frais associés aux journaux par rapport à votre attribution mensuelle.
Les journaux sont essentiels à la réussite des opérations et de la sécurité, mais ils ne sont utiles que si vous les examinez et prenez des mesures en conséquence. Personnalisez les journaux en fonction de leur audience visée, ce qui garantit la réussite des opérations et de la sécurité pour votre réseau VPC.
Pour en savoir plus, consultez Utiliser des journaux de flux VPC.
Augmenter l'intervalle d'agrégation des journaux pour les réseaux VPC avec des connexions longues
Pour les réseaux VPC présentant principalement des connexions à longue durée de vie, définissez l'intervalle d'agrégation des journaux sur 15 minutes afin de réduire considérablement le nombre de journaux générés et de permettre une analyse plus rapide et plus simple.
La surveillance du réseau constitue un exemple de workflow pour lequel l'augmentation de l'intervalle d'agrégation des journaux est appropriée. Ce workflow implique les tâches suivantes :
- Réaliser un diagnostic du réseau
- Filtrer les journaux de flux par VM et par application pour comprendre les évolutions du trafic
- Analyser la croissance du trafic pour prévoir les besoins en capacité
Utiliser l'échantillonnage des journaux de flux VPC pour réduire le volume
Réduisez le volume des journaux de flux VPC en les échantillonnant, tout en conservant la possibilité d'afficher des échantillons de bas niveau et des vues agrégées.
La compréhension de l'utilisation du réseau et l'optimisation des frais liés au trafic réseau constituent un exemple de workflow pour lequel l'utilisation de l'échantillonnage pour réduire le volume est appropriée. Ce workflow implique les tâches suivantes :
- Estimer le trafic d'une région ou d'une zone à une autre
- Estimer le trafic vers certains pays sur Internet
- Identifier les top talkers
Supprimer des métadonnées supplémentaires lorsque vous n'avez besoin que de données d'adresse IP et de port
Dans les cas d'utilisation de la sécurité où seuls les ports et les adresses IP vous intéressent, supprimez les métadonnées supplémentaires afin de réduire le volume de données consommées dans Cloud Logging.
L'investigation du réseau constitue un exemple de workflow pour lequel la suppression de métadonnées est appropriée. Ce workflow implique les tâches suivantes :
- Déterminer les adresses IP impliquées, et avec qui et quand elles ont communiqué
- Identifier les adresses IP compromises, trouvées en analysant les flux du réseau
Obtenir des insights sur vos réseaux à l'aide de Network Intelligence Center
Network Intelligence Center fournit une console unique permettant de gérer la visibilité, la surveillance et le dépannage du réseau Google Cloud . Les sections suivantes fournissent des informations sur les composants de Network Intelligence Center.
Network Topology
Utilisez Network Topology pour visualiser la topologie de votre réseau.
Tests de connectivité
Utilisez les tests de connectivité pour diagnostiquer les problèmes de connectivité avec vos réseaux VPC.
Performance Dashboard
Utilisez le tableau de bord des performances pour vérifier les performances du réseau physique sous-jacent à vos réseaux virtuels VPC.
Firewall Insights
Utilisez Firewall Insights pour mieux comprendre vos règles de pare-feu et leur interaction.
Network Analyzer
Utilisez Network Analyzer pour surveiller les configurations de votre réseau VPC et détecter les erreurs de configuration et les configurations non optimales.
Flow Analyzer
Utilisez l'analyseur de flux pour mieux comprendre les flux de trafic VPC.
Architectures de référence
Cette section présente des architectures illustrant certaines des bonnes pratiques décrites dans ce document.
Un seul projet, un seul réseau VPC
Cette architecture de référence initiale inclut tous les composants nécessaires au déploiement d'architectures à disponibilité élevée dans plusieurs régions, avec une isolation au niveau du sous-réseau et un contrat de niveau de service garantissant une disponibilité de 99,99 % lors de la connexion à vos centres de données sur site.
Un seul projet hôte, plusieurs projets de service, un seul VPC partagé
En s'appuyant sur l'architecture de référence initiale, les projets hôtes de VPC partagé et plusieurs projets de service permettent aux administrateurs de déléguer des responsabilités administratives, comme la création et la gestion d'instances, à des administrateurs de projet de service tout en conservant un contrôle centralisé sur les ressources réseau, telles que les sous-réseaux, les routes et les pare-feu.
Plusieurs projets hôtes, plusieurs projets de service, plusieurs VPC partagés
Le schéma suivant illustre une architecture pour l'isolation des VPC, qui repose sur notre conception à haute disponibilité tout en séparant la production des autres projets. Il existe de nombreuses raisons d'envisager l'isolation des VPC, comme des exigences d'audit (par exemple, la norme PCI), des considérations relatives aux quotas entre les environnements, ou tout simplement un autre niveau d'isolation logique. Vous n'avez besoin que de deux interconnexions (pour la redondance) par emplacement, mais vous pouvez ajouter plusieurs rattachements d'interconnexion à plusieurs réseaux VPC ou régions à partir de celles-ci.
Le recours à l'isolation peut également nécessiter la réplication, car vous décidez où placer les services principaux tels que les proxys, l'authentification et les services d'annuaire. L'utilisation d'un réseau VPC de services partagés peut aider à éviter cette réplication et vous permet de partager ces services avec d'autres réseaux VPC via Network Connectivity Center, tout en centralisant l'administration et le déploiement.
Pare-feu L7 avec état entre les réseaux VPC
Cette architecture comprend plusieurs réseaux VPC liés par un pare-feu nouvelle génération L7 (NGFW, Next-Generation Firewall), qui fonctionne comme une liaison dotée de plusieurs cartes d'interface réseau entre les réseaux VPC.
Un réseau VPC extérieur non approuvé est introduit pour interrompre les interconnexions hybrides et les connexions Internet qui prennent fin sur la branche extérieure du NGFW L7 pour inspection. Il existe de nombreuses variantes de cette conception, mais le principe fondamental est de filtrer le trafic à travers le pare-feu avant qu'il n'atteigne les réseaux VPC approuvés.
Cette conception nécessite que chaque réseau VPC réside dans le projet où vous insérez le NGFW basé sur une VM. Les quotas étant appliqués au niveau du projet, vous devez prendre en compte l'ensemble des ressources VPC.
Plusieurs réseaux VPC interconnectés avec Network Connectivity Center
Cette architecture comporte plusieurs réseaux VPC qui se connectent les uns aux autres à l'aide de Network Connectivity Center. Un réseau VPC de transit est introduit pour mettre fin aux interconnexions hybrides et partager la connectivité hybride avec tous les autres VPC, ce qui évite d'avoir à créer des rattachements de VLAN pour chaque réseau VPC. Cette approche consolide la connectivité externe et les considérations de routage associées. De même, un ou plusieurs réseaux VPC de services partagés peuvent être introduits pour héberger des services communs tels que les services de proxy, d'authentification et d'annuaire. Il existe de nombreuses variantes de cette conception, mais le principe fondamental est de gérer les différents services et types de connexion en tant que spokes d'un hub Network Connectivity Center qui fournit une connectivité tout-à-tout entre eux. Cette architecture de référence est décrite en détail dans Connectivité inter-VPC du réseau multicloud à l'aide de Network Connectivity Center.
Étapes suivantes
- Cross-Cloud Network pour les applications distribuées
- Présentation détaillée de VPC et bonnes pratiques (vidéo Cloud NEXT 2018)
- Topologies de réseaux hybrides et multicloud
- Choisir une hiérarchie de ressources pour votre Google Cloud zone de destination
- Bonnes pratiques pour la sélection des régions Compute Engine
- Google Cloud pour les professionnels des centres de données : réseaux
- Documentation sur les VPC
- Présentation du réseau GKE
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Cloud Architecture Center.