Bonnes pratiques et architectures de référence pour la conception de VPC

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 tutoriel 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 de Google Cloud.

Principes généraux et premières étapes

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 Cloud Identity and Access Management
• Documentation sur les clouds privés virtuels (VPC)

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-1

• Sous-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 le 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-rule

• Syntaxe de la route IP
   :{priority}-{VPC-label}-{tag}-{next hop}
  exemple : 1000-acmeco-hr-dev-vpc-1-int-gw

Adresses et sous-réseaux

Utiliser des réseaux VPC en mode personnalisé

Lorsque vous démarrez votre premier projet, vous commencez par le réseau par défaut, qui est un réseau VPC en mode automatique nommé default. Les réseaux en mode automatique créent automatiquement des sous-réseaux et des routes de sous-réseau correspondantes dont les plages d'adresses IP principales sont des préfixes CIDR /20 dans chaque région Google Cloud, à l'aide d'un ensemble prévisible de plages d'adresses RFC 1918. Le réseau default inclut également automatiquement des règles de pare-feu préremplies.

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é

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 IAM 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 facilement 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é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. Généralement, les limites ne peuvent pas être augmentées facilement, bien que les équipes d'assistance et de ventes de Google Cloud puissent 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 de Google 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). Pour en savoir plus sur la création d'un réseau VPC commun pour les services partagés, consultez la section relative aux services partagés.

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 :

• networkAdmin
• securityAdmin
• networkUser
• networkViewer

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

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
Appairage de réseaux VPC	Facile à configurer. Faibles coûts de gestion. Bande passante élevée. Frais de sortie faibles (identiques à ceux d'un seul réseau VPC). Chaque réseau VPC gère son propre pare-feu distribué. Chaque réseau VPC gère ses propres autorisations et comptes IAM.	Non transitif. Le nombre de scalings est lié au groupe global de réseaux VPC appairés. Cela inclut le nombre de VM, de routes et de règles de transfert internes. Nécessite un espace d'adressage ne présentant pas de chevauchement. Les routes statiques et dynamiques ne sont pas propagées. Les tags sources et les comptes de service sources de la VM émettrice ne sont pas propagés sur l'appairage de réseaux VPC.
Routage externe (adresse IP publique ou passerelle NAT)	Aucune configuration requise. Isolation complète entre les réseaux VPC. Possibilité d'utiliser un espace d'adresses IP présentant des chevauchements. Bande passante élevée.	Les frais de sortie pour les VM situées dans la même zone sont plus élevés que pour d'autres options, telles que l'appairage de réseaux VPC. Les VM doivent être exposées à l'aide d'adresses IP externes. Il n'est pas possible de mettre en place des pare-feu utilisant des adresses IP privées. Les routes statiques et dynamiques ne sont pas propagées. Les tags sources et les comptes de service sources de la VM émettrice ne sont pas reconnus par les réseaux appairés.
Cloud VPN	Cloud VPN active les topologies transitives en étoile. Adaptable via le protocole ECMP. Garantie de disponibilité du service de 99,99 % sur un réseau VPN haute disponibilité.	Coûts de gestion. Facturation au tarif de sortie Internet. Latence légèrement supérieure. Débit limité à 3 Gbit/s par tunnel. MTU inférieure en raison d'encapsulations de tunnel supplémentaires. Les tags sources et les comptes de service sources de la VM émettrice sont perdus dans le tunnel.
Cloud Interconnect – Interconnexion dédiée ou partenaire	Contrats de niveau de service disponibles en fonction de la redondance dans le déploiement : 99,99 % (détails) 99,9 % (détails) La capacité de chaque liaison de Dedicated Interconnect est de 10 Gbit/s ou 100 Gbit/s. Plusieurs liaisons d'interconnexions peuvent être regroupées afin d'augmenter le débit, avec un maximum de 8 circuits de 10 Gbit/s (80 Gbit/s) ou de 2 circuits de 100 Gbit/s (200 Gbit/s) pour chaque connexion Dedicated Interconnect. Possibilité d'utiliser le protocole ECMP sur plusieurs interconnexions afin d'augmenter le débit.	Coûts supplémentaires et frais de sortie pour le trafic envoyé entre des réseaux VPC via une connexion par interconnexion. Le trafic n'est pas chiffré. Latence supplémentaire par rapport aux solutions cloud natives. Les périphériques matériels supplémentaires dans le chemin peuvent échouer.
Plusieurs interfaces réseau (avec plusieurs cartes d'interface réseau)	Adaptables via des groupes d'instances gérés et des routes ECMP sur plusieurs instances. Les VM individuelles ont des [limites de bande passante](/compute/docs/network-bandwidth).	Limite fixée à 8 interfaces par instance. L'équilibreur de charge réseau interne à stratégie directe accepte l'envoi de trafic vers [toute interface](/load-balancing/docs/internal#backend-service-multi-nic) de la VM. Les autres équilibreurs de charge n'acceptent que l'interface réseau par défaut (nic0) d'une VM.

Utiliser l'appairage de réseaux VPC en cas de non-dépassement des limites de ressources

Nous vous recommandons de recourir à l'appairage de réseaux VPC lorsque vous devez connecter des réseaux VPC et que vous ne pouvez pas utiliser un seul VPC partagé, tant que le total des ressources nécessaires pour tous les pairs connectés directement ne dépasse pas les limites de nombre d'instances de VM, de connexions d'appairages et de 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.

L'appairage de réseaux VPC est la méthode de connexion des réseaux VPC recommandée pour les raisons suivantes :

• Aucun goulot d'étranglement au niveau de la passerelle : le trafic est transféré entre les pairs comme si les VM se trouvaient dans le même réseau VPC.
• Facturation : aucuns frais supplémentaires ne sont appliqués, vous êtes facturé de la même manière que lorsque les VM se trouvent dans le même réseau VPC.

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.

Utiliser Cloud VPN pour connecter des réseaux VPC qui, autrement, dépasseraient les limites des groupes d'appairage agrégées

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.

Se servir de Cloud Interconnect pour contrôler le trafic entre les réseaux VPC via un appareil sur site

Cloud Interconnect étend votre réseau sur site au réseau de Google via une connexion hautement disponible et à faible latence. Vous pouvez utiliser une interconnexion dédiée pour vous connecter directement à Google, ou passer par une interconnexion partenaire pour vous connecter à Google via un fournisseur de services compatible.

L'interconnexion dédiée fournit un service L2 haut débit entre Google et un fournisseur de colocation ou un emplacement sur site. Cela vous permet d'établir des routes entre les réseaux VPC à l'aide de l'équipement de routage sur site, ainsi que de filtrer l'intégralité du trafic entre les réseaux VPC au moyen des services de sécurité et d'inspection sur site existants. L'ensemble du trafic entre les deux réseaux VPC présente une latence supplémentaire en raison d'un aller-retour additionnel via le système sur site.

L'interconnexion partenaire offre des fonctionnalités similaires. Elle permet également d'établir un appairage direct avec un fournisseur au niveau L3 et de router le fournisseur entre les réseaux VPC. Vous pouvez ainsi accéder aux adresses IP internes sur votre réseau sur site et à vos réseaux VPC Google Cloud sans passer par un appareil NAT ou un tunnel VPN.

Étant donné que de nombreux dispositifs de sécurité d'entreprise peuvent être utilisés sur Google Cloud à l'aide de VM dotées de plusieurs interfaces réseau, il n'est pas nécessaire d'utiliser Cloud Interconnect pour router le trafic entre les réseaux VPC, sauf dans de très rares cas où les règles d'entreprise imposent le passage de l'ensemble du trafic par un dispositif sur site.

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.

Créer un VPC de services partagés si plusieurs réseaux VPC ont besoin d'accéder à des ressources communes, mais pas les uns aux autres

Un réseau VPC fournit un maillage complet de joignabilité globale. Pour cette raison, les services partagés et les pipelines d'intégration continue résidant dans le même réseau VPC ne nécessitent aucune mesure particulière en matière de connectivité : leur joignabilité est intrinsèque. Le VPC partagé étend ce concept, en permettant aux services partagés de résider dans un projet isolé tout en fournissant une connectivité à d'autres services ou clients.

Les approches applicables aux services partagés incluent Private Service Connect, l'appairage de réseaux VPC et Cloud VPN. Utilisez Private Service Connect, sauf si vous n'êtes pas en mesure de le faire pour une raison quelconque. Vous pouvez utiliser l'appairage de réseaux VPC pour vous connecter à un réseau VPC de services partagés si vous ne dépassez pas les limites de ressources agrégées et que vous ne souhaitez pas configurer de points de terminaison pour chaque service. Vous pouvez également utiliser Cloud VPN pour connecter des réseaux VPC de services partagés qui, autrement, dépasseraient les limites des groupes d'appairage agrégées.

Private Service Connect vous permet de mettre un service hébergé dans un réseau à la disposition des machines virtuelles d'un autre réseau en créant un point de terminaison spécial dans le réseau consommateur. La configuration Private Service Connect canalise ensuite le trafic pour ce service entre les deux réseaux.

Les clients peuvent utiliser leurs propres adresses IP internes pour accéder aux services sans quitter leurs réseaux VPC ou utiliser d'adresses IP externes. Le trafic reste entièrement dans Google Cloud. Private Service Connect fournit un accès orienté services entre clients et producteurs, avec un contrôle précis sur l'accès aux services.

Dans le modèle d'appairage de réseaux VPC, chaque réseau VPC crée une relation d'appairage avec un réseau VPC de services partagés commun pour établir la joignabilité. Le scaling est un facteur à prendre en considération si vous optez pour l'appairage de réseaux VPC, car les limites de scaling s'appliquent à l'utilisation agrégée des ressources de tous les pairs.

L'appairage de réseaux VPC peut également être utilisé avec un accès aux services privés ainsi qu'avec l'API Service Networking. Grâce à cette API, vous pouvez permettre aux clients d'une même organisation ou d'une autre organisation d'utiliser un service que vous fournissez, mais leur laisser choisir la plage d'adresses IP connectée à l'aide de l'appairage de réseaux VPC.

Cloud VPN est une autre alternative. Étant donné qu'il établit la joignabilité via des tunnels IPsec gérés, il n'est pas soumis aux limites agrégées de l'appairage de réseaux VPC. Cloud VPN utilise une passerelle VPN pour la connectivité et ne prend pas en compte l'utilisation agrégée des ressources du pair IPsec. Cloud VPN présente toutefois des inconvénients, par exemple une augmentation des coûts (tunnels VPN et trafic sortant), les frais de gestion supplémentaires associés aux tunnels et l'impact du protocole IPsec sur les performances.

Conception hybride : connecter un environnement sur site

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.

Routage dynamique

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 réseau VPC dédié et appairez-la avec d'autres projets utilisant des routes annoncées personnalisées. Cela permet d'exporter des routes statiques ou apprises de manière dynamique vers des réseaux VPC pairs, afin de fournir une configuration centralisée et de procéder au scaling de votre conception de réseau VPC.

Cette démarche diffère du déploiement classique d'une connectivité hybride, qui utilise un tunnel VPN ou des rattachements de VLAN dans chaque réseau VPC.

Le schéma suivant illustre une connectivité hybride centralisée comportant des routes personnalisées d'appairage de réseau VPC :

Sécurité du réseau

À travers son infrastructure et ses services, Google Cloud fournit des fonctionnalités de sécurité robustes, 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 ressources Google 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 où réside la ressource. 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é 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.

Toutefois, avant de bloquer l'accès à Internet, pensez aux conséquences que cela aura sur vos instances de VM. Le blocage peut réduire les risques d'exfiltration de données, mais il peut également interdire du trafic légitime, y compris du trafic essentiel pour les mises à jour logicielles et les API et services tiers. Sans accès à Internet, vous ne pouvez accéder à vos instances de VM qu'à partir d'un réseau sur site connecté via un tunnel Cloud VPN, une connexion Cloud Interconnect ou Identity-Aware Proxy. Grâce à Cloud NAT, les machines virtuelles peuvent lancer des connexions de sortie à Internet pour du trafic essentiel spécifique, sans exposer les connexions d'entrée publiques.

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 natives Google Cloud

Le VPC Google Cloud comprend un pare-feu avec état L3/L4 à scaling horizontal et appliqué à chaque VM de manière distribuée. Ce pare-feu est configuré à l'aide de stratégies de pare-feu hiérarchiques, de stratégies de pare-feu réseau mondiales et régionales, et de règles de pare-feu VPC. Consultez la Présentation de Cloud Firewall pour en savoir plus.

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 interne à stratégie directe.

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 :

1. Appliquez des règles de pare-feu communes à toutes les VM du réseau VPC.
2. 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.
3. 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 s'appliquent uniquement 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) global Google Cloud 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

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. Les règles de pare-feu Google Cloud sont dites "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.

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

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é

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 concernant 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 la page 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

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 l'appairage de réseaux VPC, 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.

Étape suivante

• 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 zone de destination Google Cloud
• 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 Centre d'architecture cloud.