Concevoir des réseaux pour migrer des charges de travail d'entreprise : approches architecturales

Last reviewed 2023-11-13 UTC

Cet article vous présente une série de documents décrivant les architectures de mise en réseau et de sécurité destinées aux entreprises qui migrent les charges de travail des centres de données vers Google Cloud. Ces architectures mettent l'accent sur la connectivité avancée, les principes de sécurité "zéro confiance" et la gestion dans un environnement hybride.

Comme décrit dans un document d'accompagnement, Architectures permettant de protéger les plans de données cloud, les entreprises déploient toute une gamme d'architectures prenant en compte les besoins en connectivité et en sécurité dans le cloud. Nous classons ces architectures dans trois modèles architecturaux distincts : la migration Lift and Shift, les services hybrides et le modèle distribué zéro confiance. Le présent document examine différentes approches de sécurité en fonction de l'architecture choisie par une entreprise. Il explique également comment mettre en œuvre ces approches à l'aide des composants de base fournis par Google Cloud. Vous devez suivre ces conseils de sécurité conjointement avec d'autres conseils architecturaux portant sur la fiabilité, la disponibilité, le scaling, les performances et la gouvernance.

Ce document est conçu pour aider les architectes système, les administrateurs réseau et les administrateurs de sécurité qui envisagent de migrer des charges de travail sur site vers le cloud. Il suppose ce qui suit :

  • Vous connaissez les concepts de mise en réseau et de sécurité des centres de données.
  • Vous disposez de charges de travail existantes dans votre centre de données sur site, et vous connaissez leurs tâches et leurs utilisateurs.
  • Vous prévoyez de migrer au moins quelques charges de travail.
  • Vous disposez de connaissances générales sur les concepts décrits sur la page Architectures permettant de protéger les plans de données cloud.

La série comprend les documents suivants :

Ce document récapitule les trois principaux modèles architecturaux et présente les composants de base que vous pouvez utiliser pour créer votre infrastructure. Enfin, il explique comment assembler les composants de base en une série d'architectures de référence correspondant aux modèles. Vous pouvez utiliser ces architectures de référence pour vous aider à concevoir votre propre architecture.

Ce document mentionne les machines virtuelles (VM) comme exemples de ressources de charge de travail. Ces informations s'appliquent à d'autres ressources qui utilisent des réseaux VPC, telles que des instances Cloud SQL et des nœuds Google Kubernetes Engine.

Présentation des modèles architecturaux

En règle générale, les ingénieurs réseau se concentrent sur la création des infrastructures physiques de mise en réseau et de sécurité dans les centres de données sur site.

La transition vers le cloud a changé cette approche, car les constructions de mise en réseau cloud sont définies par logiciel. Dans le cloud, les propriétaires d'applications ont un contrôle limité sur la pile d'infrastructure sous-jacente. Ils ont besoin d'un modèle doté d'un périmètre sécurisé qui isole leurs charges de travail.

Dans cette série, nous allons examiner trois modèles architecturaux courants. Ces modèles s'appuient les uns sur les autres et peuvent être considérés comme un spectre plutôt que comme un choix strict.

Modèle de migration Lift and Shift

Dans le modèle architectural de migration Lift and Shift, les propriétaires d'applications d'entreprise migrent leurs charges de travail vers le cloud sans les refactoriser. Les ingénieurs réseau et de sécurité utilisent des contrôles de couche 3 et de couche 4 pour assurer une protection à l'aide de plusieurs dispositifs virtuels de réseaux qui imitent des appareils physiques sur site et des règles de pare-feu cloud dans le réseau VPC. Les propriétaires de charges de travail déploient leurs services sur des réseaux VPC.

Modèle de services hybrides

Les charges de travail créées à l'aide de la migration Lift and Shift peuvent avoir besoin d'accéder à des services cloud tels que BigQuery ou Cloud SQL. Généralement, l'accès à ces services cloud s'effectue au niveau de la couche 4 et de la couche 7. Dans ce contexte, l'isolation et la sécurité ne peuvent pas être mises en place exclusivement au niveau de la couche 3. Par conséquent, la mise en réseau des services et VPC Service Controls sont utilisés pour assurer la connectivité et la sécurité, en fonction des identités du service auquel vous avez accès et du service qui demande l'accès. Dans ce modèle, il est possible de formuler des stratégies de contrôle d'accès enrichies.

Modèle distribué zéro confiance

Dans une architecture zéro confiance, les applications d'entreprise étendent l'application de la sécurité au-delà des contrôles du périmètre. À l'intérieur du périmètre, les charges de travail ne peuvent communiquer avec d'autres charges de travail que si leur identité IAM dispose d'une autorisation spécifique, qui est refusée par défaut. Dans une architecture distribuée zéro confiance, la confiance est basée sur l'identité et appliquée pour chaque application. Les charges de travail sont conçues sous forme de microservices ayant des identités émises de manière centralisée. De cette façon, les services peuvent valider leurs appelants et prendre des décisions basées sur des règles pour chaque requête afin de savoir si cet accès est acceptable. Cette architecture est souvent mise en œuvre à l'aide de proxys distribués (un maillage de services) au lieu de passerelles centralisées.

Les entreprises peuvent appliquer un accès zéro confiance des utilisateurs et des appareils aux applications d'entreprise en configurant Identity-Aware Proxy (IAP). IAP fournit des contrôles basés sur l'identité et le contexte pour le trafic utilisateur provenant d'Internet ou d'un réseau intranet.

Combiner les modèles

Les entreprises qui créent ou migrent leurs applications métier vers le cloud utilisent généralement une combinaison des trois modèles architecturaux.

Google Cloud propose un portefeuille de produits et de services faisant office de composants de base pour mettre en œuvre le plan de données cloud qui alimente les modèles architecturaux. Nous parlerons de ces composants fondamentaux plus loin dans ce document. La combinaison des contrôles fournis dans le plan de données cloud et des commandes d'administration permettant de gérer les ressources cloud constitue la base d'un périmètre de sécurité de bout en bout. Le périmètre créé par cette combinaison vous permet de gérer, de déployer et d'exploiter vos charges de travail dans le cloud.

Hiérarchie des ressources et commandes d'administration

Cette section présente un résumé des commandes d'administration fournies par Google Cloud en tant que conteneurs de ressources. Les commandes incluent les ressources, les dossiers et les projets d'une organisation Google Cloud qui vous permettent de regrouper et d'organiser de manière hiérarchique les ressources cloud. Cette organisation hiérarchique vous fournit une structure de propriété et des points d'ancrage pour appliquer des règles et des contrôles.

Une ressource Organisation Google est le nœud racine de la hiérarchie et constitue la base de la création de déploiements dans le cloud. Une ressource "Organisation" peut comporter des dossiers et des projets enfants. Un dossier contient des projets ou d'autres dossiers enfants. Toutes les autres ressources cloud sont les enfants des projets.

Vous utilisez des dossiers comme méthode de regroupement des projets. Les projets constituent la base de la création, de l'activation et de l'utilisation de tous les services Google Cloud. Les projets vous permettent de gérer des API, d'activer la facturation, d'ajouter et de supprimer des collaborateurs, et de gérer les autorisations.

Identity and Access Management (IAM) de Google vous permet d'attribuer des rôles, et de définir des stratégies d'accès et des autorisations à tous les niveaux de la hiérarchie des ressources. Les stratégies IAM sont héritées par les ressources de niveau inférieur dans la hiérarchie. Ces stratégies ne peuvent pas être modifiées par les propriétaires de ressources à un niveau inférieur dans la hiérarchie. Dans certains cas, la gestion de l'authentification et des accès est fournie de manière plus précise, par exemple au niveau des objets d'un espace de noms ou d'un cluster, comme dans Google Kubernetes Engine.

Considérations liées à la conception pour les réseaux de cloud privé virtuel Google

Lorsque vous concevez une stratégie de migration vers le cloud, il est important de développer une stratégie concernant l'utilisation des réseaux VPC par votre entreprise. Vous pouvez considérer un réseau VPC comme une version virtuelle de votre réseau physique traditionnel. Il s'agit d'une partition de réseau privée entièrement isolée. Par défaut, les charges de travail ou les services déployés dans un réseau VPC ne peuvent pas communiquer avec les tâches d'un autre réseau VPC. Les réseaux VPC permettent donc d'isoler les charges de travail en créant une limite de sécurité.

Étant donné que chaque réseau VPC dans le cloud est un réseau entièrement virtuel, chacun possède son propre espace d'adresses IP privées. Vous pouvez donc utiliser la même adresse IP dans plusieurs réseaux VPC sans conflit. Un déploiement type sur site peut utiliser une grande partie de l'espace d'adresses IP privées RFC 1918. D'autre part, si vous avez des charges de travail sur site et dans des réseaux VPC, vous pouvez réutiliser les mêmes plages d'adresses dans différents réseaux VPC, à condition que ces réseaux ne soient pas connectés ou appairés, afin d'utiliser l'espace d'adresses IP moins rapidement.

Les réseaux VPC sont mondiaux

Les réseaux VPC de Google Cloud sont mondiaux, ce qui signifie que les ressources déployées dans un projet disposant d'un réseau VPC peuvent communiquer entre elles directement à l'aide du réseau backbone privé de Google.

Comme illustré dans la figure 1, vous pouvez disposer d'un réseau VPC dans votre projet qui contient des sous-réseaux dans différentes régions couvrant plusieurs zones. Les VM de n'importe quelle région peuvent communiquer entre elles en mode privé à l'aide des routes VPC locales.

Mise en œuvre du réseau VPC mondial de Google Cloud avec des sous-réseaux configurés dans différentes régions.

Figure 1 : Mise en œuvre du réseau VPC mondial de Google Cloud avec des sous-réseaux configurés dans différentes régions.

Partager un réseau à l'aide d'un VPC partagé

Un VPC partagé permet à une ressource "Organisation" de connecter plusieurs projets à un réseau VPC commun pour qu'ils puissent communiquer entre eux de manière sécurisée à l'aide d'adresses IP internes du réseau partagé. Les administrateurs réseau de ce réseau partagé appliquent un contrôle centralisé sur les ressources réseau.

Lorsque vous utilisez un VPC partagé, vous désignez un projet en tant que projet hôte et vous lui associez un ou plusieurs projets de service. Les réseaux VPC du projet hôte sont appelés réseaux VPC partagés. Les ressources éligibles des projets de service peuvent utiliser des sous-réseaux du réseau VPC partagé.

Les entreprises utilisent généralement des réseaux VPC partagés lorsqu'elles ont besoin d'administrateurs réseau et de sécurité pour centraliser la gestion des ressources réseau telles que les sous-réseaux et les routes. Dans le même temps, les réseaux VPC partagés permettent aux équipes chargées des applications et du développement de créer et de supprimer des instances de VM, et de déployer des charges de travail dans les sous-réseaux désignés à l'aide des projets de service.

Isoler des environnements à l'aide de réseaux VPC

L'utilisation de réseaux VPC pour isoler les environnements présente de nombreux avantages, mais également certains inconvénients dont vous devez tenir compte. Cette section présente ces compromis et décrit des modèles courants permettant de mettre en œuvre l'isolation.

Motifs d'isolation des environnements

Étant donné que les réseaux VPC représentent un domaine d'isolation, de nombreuses entreprises les utilisent pour conserver des environnements ou des unités commerciales dans des domaines distincts. Voici les principales raisons de créer une isolation au niveau d'un VPC :

  • Une entreprise souhaite établir des communications de refus par défaut entre un réseau VPC et un autre, car ces réseaux représentent une distinction organisationnelle significative. Pour en savoir plus, consultez Modèles courants d'isolation des réseaux VPC plus loin dans ce document.
  • Une entreprise doit disposer de plages d'adresses IP qui se chevauchent en raison d'environnements sur site préexistants, d'acquisitions ou de déploiements dans d'autres environnements cloud.
  • Une entreprise souhaite déléguer le contrôle administratif complet d'un réseau à une partie de l'entreprise.

Inconvénients de l'isolation des environnements

La création d'environnements isolés avec des réseaux VPC peut présenter certains inconvénients. L'utilisation de plusieurs réseaux VPC peut augmenter les frais d'administration liés à la gestion des services couvrant plusieurs réseaux. Ce document présente les techniques que vous pouvez utiliser pour gérer cette complexité.

Modèles courants d'isolation des réseaux VPC

Il existe des modèles courants pour l'isolation des réseaux VPC :

  • Isoler les environnements de développement, de préproduction et de production. Ce modèle permet aux entreprises de séparer complètement leurs environnements de développement, de préproduction et de production. En effet, cette structure conserve plusieurs copies complètes d'applications, avec un déploiement progressif entre chaque environnement. Dans ce modèle, les réseaux VPC sont utilisés comme limites de sécurité. Les développeurs disposent d'un haut niveau d'accès aux réseaux VPC de développement pour effectuer leurs tâches quotidiennes. Une fois le développement terminé, une équipe de production d'ingénierie ou une équipe de contrôle qualité peut migrer les modifications vers un environnement de préproduction, dans lequel elles peuvent être testées de manière intégrée. Lorsque les modifications sont prêtes à être déployées, elles sont envoyées à un environnement de production.
  • Isoler les unités commerciales. Certaines entreprises souhaitent imposer un degré élevé d'isolation entre les unités commerciales, en particulier dans le cas d'unités acquises ou nécessitant un degré élevé d'autonomie et d'isolation. Dans ce modèle, les entreprises créent souvent un réseau VPC pour chaque unité commerciale et délèguent le contrôle de ce VPC aux administrateurs de l'unité commerciale. L'entreprise utilise les techniques décrites plus loin dans ce document pour exposer les services couvrant l'entreprise ou pour héberger des applications destinées aux utilisateurs couvrant plusieurs unités commerciales.

Recommandation pour créer des environnements isolés

Nous vous recommandons de concevoir vos réseaux VPC de sorte qu'ils disposent du domaine le plus étendu conforme aux limites administratives et de sécurité de votre entreprise. Vous pouvez obtenir une isolation supplémentaire entre les charges de travail exécutées sur le même réseau VPC en utilisant des contrôles de sécurité tels que des pare-feu.

Pour en savoir plus sur la conception et la création d'une stratégie d'isolation pour votre organisation, consultez les pages Bonnes pratiques et architectures de référence pour la conception de VPC et Mise en réseau du plan de base d'entreprise de Google Cloud.

Composants fondamentaux de la mise en réseau cloud

Cette section présente les composants de base de la connectivité réseau, de la sécurité réseau, de la mise en réseau des services et de la sécurité des services. La figure 2 décrit la relation entre ces composants de base. Vous pouvez utiliser un ou plusieurs des produits répertoriés sur une ligne donnée.

Composants fondamentaux de la connectivité et de la sécurité des réseaux cloud.

Figure 2 : Composants fondamentaux de la connectivité et de la sécurité des réseaux cloud.

Les sections suivantes décrivent chacun des composants ainsi que les services Google Cloud que vous pouvez utiliser pour chacun d'entre eux.

Connectivité réseau

Le bloc de connectivité réseau se trouve à la base de la hiérarchie. Il est chargé de connecter les ressources Google Cloud à des centres de données sur site ou d'autres clouds. Selon vos besoins, vous n'aurez peut-être besoin que d'un seul de ces produits ou de tous les utiliser pour gérer différents cas d'utilisation.

Cloud VPN

Cloud VPN vous permet de connecter vos succursales à distance ou d'autres fournisseurs cloud à des réseaux VPC Google via une connexion VPN IPsec. Le trafic échangé entre les deux réseaux est chiffré par une passerelle VPN, puis déchiffré par l'autre passerelle VPN, ce qui contribue à protéger les données lors de leur transit par Internet.

Cloud VPN vous permet d'établir une connectivité entre votre environnement sur site et Google Cloud sans avoir à provisionner les connexions croisées physiques requises pour Cloud Interconnect (décrit dans la section suivante). Vous pouvez provisionner un VPN haute disponibilité pour répondre aux exigences d'un contrat de niveau de service garantissant jusqu'à 99,99 % de disponibilité si vous disposez de l'architecture conforme. Vous pouvez envisager d'utiliser Cloud VPN si vos charges de travail ne nécessitent pas une faible latence ou une bande passante élevée. Par exemple, Cloud VPN constitue un bon choix pour les cas d'utilisation non critiques ou pour étendre la connectivité à d'autres fournisseurs cloud.

Cloud Interconnect

Cloud Interconnect fournit une connectivité professionnelle à Google Cloud offrant un débit plus élevé et des performances réseau plus fiables que les VPN ou les entrées Internet. L'interconnexion dédiée fournit une connectivité physique directe au réseau Google à partir de vos routeurs. L'interconnexion partenaire fournit une connectivité dédiée via un vaste réseau de partenaires pouvant offrir une audience plus large ou d'autres options de bande passante qu'une interconnexion dédiée. Cross-Cloud Interconnect fournit une connectivité directe dédiée entre vos réseaux VPC et d'autres fournisseurs cloud. L'interconnexion dédiée nécessite de se connecter à une installation hébergée en colocation dans laquelle Google est présent, mais pas l'interconnexion partenaire. Cross-Cloud Interconnect vous permet de sélectionner des emplacements qui répondent à vos exigences pour établir les connexions. Cloud Interconnect garantit que le trafic entre votre réseau sur site ou un autre réseau cloud et votre réseau VPC ne transite pas par l'Internet public.

Vous pouvez provisionner ces connexions Cloud Interconnect pour répondre aux exigences d'un contrat de niveau de service garantissant jusqu'à 99,99 % de disponibilité si vous provisionnez l'architecture appropriée. Vous pouvez envisager d'utiliser Cloud Interconnect pour gérer des charges de travail nécessitant une faible latence, une bande passante élevée et des performances prévisibles tout en garantissant que tout votre trafic reste privé.

Network Connectivity Center pour les environnements hybrides

Network Connectivity Center fournit une connectivité de site à site entre vos réseaux sur site et d'autres réseaux cloud. Pour ce faire, Google utilise le réseau backbone Google afin de fournir une connectivité fiable entre vos sites.

En outre, vous pouvez étendre votre réseau superposé SD-WAN existant à Google Cloud en configurant une VM ou un appareil de routeur d'un fournisseur tiers en tant que rattachement de spoke logique.

Vous pouvez accéder aux ressources des réseaux VPC à l'aide de l'appareil de routeur, du VPN ou du réseau Cloud Interconnect en tant que rattachements de spoke. Vous pouvez utiliser Network Connectivity Center pour consolider la connectivité entre vos sites sur site, votre présence dans d'autres clouds et sur Google Cloud, et tout gérer depuis une seule vue.

Network Connectivity Center pour les réseaux VPC

Network Connectivity Center vous permet également de créer un réseau maillé entre de nombreux réseaux VPC. Vous pouvez connecter ce réseau maillé à des réseaux sur site ou à d'autres clouds à l'aide de Cloud VPN ou de Cloud Interconnect.

Appairage de réseaux VPC

L'appairage de réseaux VPC vous permet de connecter des réseaux VPC Google afin que les charges de travail de différents réseaux VPC puissent communiquer en interne, qu'elles appartiennent ou non au même projet ou à la même ressource d'organisation. Le trafic reste à l'intérieur du réseau de Google et ne traverse pas l'Internet public.

L'appairage de réseaux VPC nécessite que les réseaux à appairer ne comportent pas d'adresses IP qui se chevauchent.

Sécurité du réseau

Le bloc de sécurité du réseau est situé au-dessus du bloc de connectivité réseau. Il est chargé d'autoriser ou de refuser l'accès aux ressources en fonction des caractéristiques des paquets d'adresses IP.

Règles de pare-feu VPC

Les règles de pare-feu VPC s'appliquent à un réseau donné. Les règles de pare-feu VPC vous permettent d'autoriser ou de refuser les connexions vers ou depuis vos instances de VM en fonction d'une configuration spécifiée. Les règles de pare-feu VPC activées sont toujours appliquées, protégeant vos instances quels que soient leur configuration, le système d'exploitation ou leur état de démarrage.

Chaque réseau privé virtuel (VPC) fonctionne comme un pare-feu distribué. Bien que les règles de pare-feu soient définies au niveau du réseau, les connexions sont autorisées ou interdites pour chaque instance. Les règles de pare-feu existent en quelque sorte entre les instances et les autres réseaux, mais également entre les instances au sein du même réseau.

Stratégies de pare-feu hiérarchiques

Les stratégies de pare-feu hiérarchiques vous permettent de créer et d'appliquer une stratégie de pare-feu cohérente dans votre entreprise. Ces stratégies contiennent des règles qui peuvent explicitement refuser ou autoriser des connexions. Vous pouvez attribuer des stratégies de pare-feu hiérarchiques à l'ensemble d'une organisation ou à des dossiers individuels.

Mise en miroir de paquets

La mise en miroir de paquets clone le trafic de certaines instances spécifiques de votre réseau VPC et le transfère aux collecteurs pour examen. La mise en miroir de paquets permet de capturer toutes les données sur le trafic et les paquets, y compris les charges utiles et les en-têtes. Vous pouvez configurer la mise en miroir pour le trafic entrant et sortant, uniquement pour le trafic d'entrée ou uniquement pour le trafic de sortie. La mise en miroir a lieu sur les instances de VM, et non sur le réseau.

Dispositif virtuel de réseau

Les dispositifs virtuels de réseau vous permettent d'appliquer des contrôles de sécurité et de conformité au réseau virtuel qui sont cohérents avec les contrôles de l'environnement sur site. Pour ce faire, vous déployez des images de VM disponibles dans Google Cloud Marketplace sur des VM ayant plusieurs interfaces réseau, chacune étant associée à un réseau VPC différent, pour effectuer différentes fonctions virtuelles de réseau.

Voici quelques cas d'utilisation courants de dispositifs virtuels :

  • Pare-feu nouvelle génération. Les pare-feu nouvelle génération constituent un ensemble centralisé de pare-feu qui s'exécutent en tant que VM et fournissent des fonctionnalités qui ne sont pas disponibles dans les règles de pare-feu VPC. Les fonctionnalités types des pare-feu nouvelle génération incluent l'inspection approfondie des paquets (DPI) et la protection des pare-feu au niveau de la couche d'application. Certains pare-feu nouvelle génération fournissent également une inspection du trafic TLS/SSL et d'autres fonctions de mise en réseau, comme décrit plus loin dans cette liste.
  • Système de détection des intrusions/de prévention des intrusions (IDS/IPS). Un IDS basé sur le réseau offre une visibilité sur le trafic potentiellement malveillant. Pour prévenir les intrusions, les appareils IPS peuvent empêcher le trafic malveillant d'atteindre sa destination.
  • Passerelle Web sécurisée (SWG). Une passerelle Web sécurisée bloque les menaces provenant d'Internet en laissant les entreprises appliquer des règles d'entreprise au trafic qui transite vers et depuis Internet. Ce processus s'appuie sur le filtrage des URL, la détection de code malveillant et le contrôle des accès.
  • Passerelle de traduction d'adresses réseau (NAT) Une passerelle NAT traduit les adresses IP et les ports. Cela permet, par exemple, d'éviter les chevauchements d'adresses IP. Google Cloud propose Cloud NAT en tant que service géré, mais ce service n'est disponible que pour le trafic vers Internet, et non pour le trafic allant vers des réseaux sur site ou d'autres réseaux VPC.
  • Pare-feu d'application Web (WAF). Un WAF est conçu pour bloquer le trafic HTTP(S) malveillant vers une application Web. Google Cloud propose une fonctionnalité WAF via les règles de sécurité de Google Cloud Armor. La fonctionnalité exacte diffère selon les fournisseurs WAF. Il est donc important de déterminer ce dont vous avez besoin.

Cloud IDS

Cloud IDS est un service de détection des intrusions qui repère les menaces telles que les intrusions, les logiciels malveillants, les logiciels espions et les attaques de commande et de contrôle sur votre réseau. Cloud IDS crée un réseau appairé géré par Google contenant des VM qui recevront le trafic mis en miroir. Le trafic mis en miroir est ensuite inspecté par les technologies de protection contre les menaces Palo Alto Networks pour fournir une détection avancée des menaces.

Cloud IDS vous offre une visibilité complète sur le trafic intra-sous-réseau, ce qui vous permet de surveiller la communication entre VM et de détecter les mouvements latéraux.

Cloud NAT

Cloud NAT est compatible avec la traduction d'adresses réseau entièrement gérée et définie par logiciel pour les applications. Il active la traduction d'adresse réseau source (NAT ou SNAT source) pour le trafic Internet provenant de VM n'ayant pas d'adresses IP externes.

Firewall Insights

Firewall Insights vous aide à comprendre et à optimiser vos règles de pare-feu. Il fournit des données sur l'utilisation de vos règles de pare-feu, expose des erreurs de configuration et identifie les règles pouvant être rendues plus strictes. Il utilise également le machine learning pour prédire l'utilisation future de vos règles de pare-feu afin que vous puissiez prendre des décisions éclairées concernant la suppression ou le renforcement des règles qui semblent trop permissives.

Journalisation réseau

Vous pouvez utiliser plusieurs produits Google Cloud pour enregistrer et analyser le trafic réseau.

La journalisation des règles de pare-feu vous permet de réaliser des audits, des vérifications et des analyses sur les effets de ces règles. Par exemple, vous pouvez déterminer si une règle de pare-feu conçue pour refuser le trafic fonctionne comme prévu. La journalisation des règles de pare-feu est également utile si vous devez déterminer le nombre de connexions affectées par une règle de pare-feu donnée.

Vous activez la journalisation des règles de pare-feu individuellement pour chaque règle de pare-feu dont vous souhaitez journaliser les connexions. Cette option est disponible pour toute règle de pare-feu, indépendamment de l'action de la règle (autorisation ou refus) et de la direction du trafic visé (entrée ou sortie).

Les journaux de flux VPC enregistrent un échantillon de flux réseau envoyés et reçus par les instances de VM, y compris les instances utilisées en tant que nœuds Google Kubernetes Engine (GKE). Ces journaux peuvent être utilisés pour la surveillance et l'investigation des réseaux, l'analyse de la sécurité en temps réel et l'optimisation des dépenses.

Mise en réseau des services

Les blocs de mise en réseau des services sont chargés de fournir des services de recherche qui indiquent aux services où une requête doit aller (DNS, Annuaire des services) et d'acheminer les requêtes au bon endroit (Private Service Connect, Cloud Load Balancing).

Cloud DNS

Les charges de travail sont accessibles à l'aide de noms de domaine. Cloud DNS permet une traduction fiable et à faible latence des noms de domaine en adresses IP situées dans le monde entier. Cloud DNS propose à la fois des zones publiques et des zones DNS gérées privées. Une zone publique est visible depuis l'Internet public, tandis qu'une zone privée est visible uniquement depuis le ou les réseaux VPC que vous spécifiez.

Cloud Load Balancing

Dans Google Cloud, les équilibreurs de charge sont des éléments essentiels, car ils permettent d'acheminer le trafic vers différents services pour garantir la vitesse et l'efficacité, ainsi que pour assurer la sécurité globale du trafic interne et externe.

Nos équilibreurs de charge permettent également d'acheminer et de faire évoluer le trafic sur plusieurs environnements clouds ou hybrides. Cloud Load Balancing est donc une "porte d'entrée" qui permet d'effectuer le scaling de n'importe quelle application, quel que soit l'endroit où elle se trouve ou le nombre d'emplacements dans lesquels elle est hébergée. Google propose différents types d'équilibrage de charge : global et régional, externe et interne, de couches 4 et 7.

Annuaire des services

L'Annuaire des services vous permet de gérer votre inventaire des services, en offrant un emplacement sécurisé où publier, détecter et connecter des services, toutes les opérations basées sur un contrôle des accès basé sur l'identité. Il vous permet d'enregistrer des services nommés et leurs points de terminaison. L'enregistrement peut être manuel ou utiliser des intégrations avec Private Service Connect, GKE et Cloud Load Balancing. La détection de services est possible avec des API HTTP et gRPC explicites, et avec Cloud DNS.

Maillages de services : Cloud Service Mesh et Cloud Service Mesh

Cloud Service Mesh et Cloud Service Mesh sont tous deux conçus pour faciliter l'exécution d'applications distribuées complexes en activant un ensemble complet de règles de gestion du trafic et de sécurité dans les architectures de maillage de services. Les principales différences entre ces produits concernent les environnements compatibles, les API Istio dédiées et leurs capacités d'équilibrage de charge global.

Cloud Service Mesh est idéal pour les déploiements régionaux et mondiaux basés sur Kubernetes, sur Google Cloud et sur site, qui bénéficient d'un produit Istio géré.

Cloud Service Mesh est idéal pour les cas d'utilisation de mise en réseau qui incluent des services déployés à l'échelle mondiale et tenant compte de l'état et de la charge sur Google Cloud. Cloud Service Mesh gère les charges de travail à l'aide de proxys Envoy qui agissent en tant que side-cars ou passerelles, ou à l'aide de charges de travail gRPC sans proxy.

Le tableau suivant récapitule les fonctionnalités de Cloud Service Meshy et de Cloud Service Mesh.

Anthos Service Mesh Traffic Director
Type de déploiement Kubernetes VM, Kubernetes
Environments Google Cloud, sur site, multicloud Google Cloud, sur site, multicloud
Champ d'application du déploiement Régional et régional fédéré Une ressource mondiale
Surface d'API Istio Routage de service (modèle de passerelle Kubernetes)
Connectivité réseau Side-car Envoy Side-car Envoy, gRPC sans proxy
Répartition globale de la charge en fonction de l'état du backend Oui (basé sur Kubernetes) Yes
Répartition globale de la charge en fonction de la charge du backend Non Yes
Identité gérée pour l'authentification mTLS des charges de travail (zéro confiance) Yes Oui (GKE uniquement)

Google a détaillé comment créer un environnement d'architecture distribuée zéro confiance de bout en bout à l'aide de l'architecture BeyondProd. En plus du périmètre réseau et de l'authentification et de l'autorisation des services, BeyondProd explique en détail comment les environnements de calcul approuvés, la provenance du code et les déploiements jouent un rôle dans la mise en œuvre d'une architecture de service zéro confiance distribuée et sécurisée. Vous devez prendre en compte ces préoccupations qui s'étendent au-delà de la mise en réseau lorsque vous adoptez une approche zéro confiance.

Private Service Connect

Private Service Connect crée des abstractions de service en rendant les charges de travail accessibles sur les réseaux VPC via un seul point de terminaison. Cela permet à deux réseaux de communiquer dans un modèle client-serveur qui expose uniquement le service au client, et non l'ensemble du réseau ou la charge de travail elle-même. Un modèle de réseau orienté services permet aux administrateurs réseau de réfléchir aux services qu'ils exposent entre les réseaux plutôt qu'entre les sous-réseaux ou les VPC. Cela permet d'utiliser les services dans un modèle producteur-consommateur, que ce soit pour des services propriétaires ou tiers (SaaS).

Avec Private Service Connect, un VPC de client peut utiliser une adresse IP privée pour se connecter à une API Google ou à un service dans un autre VPC.

Vous pouvez étendre Private Service Connect à votre réseau sur site pour accéder aux points de terminaison qui se connectent aux API Google ou aux services gérés d'un autre réseau VPC. Private Service Connect permet d'utiliser des services au niveau de la couche 4 ou de la couche 7.

Au niveau de la couche 4, Private Service Connect exige que le producteur crée un ou plusieurs sous-réseaux spécifiques à Private Service Connect. Ces sous-réseaux sont également appelés sous-réseaux NAT. Private Service Connect exécute la NAT source à l'aide d'une adresse IP sélectionnée à partir de l'un des sous-réseaux Private Service Connect pour acheminer les requêtes vers un producteur de services. Cette approche vous permet d'utiliser des adresses IP qui se chevauchent entre les consommateurs et les producteurs.

Au niveau de la couche 7, vous pouvez créer un backend Private Service Connect à l'aide d'un équilibreur de charge d'application interne. L'équilibreur de charge d'application interne vous permet de choisir les services disponibles à l'aide d'un mappage d'URL. Pour en savoir plus, consultez la page À propos des backends Private Service Connect.

Accès aux services privés

L'accès aux services privés est une connexion privée entre votre réseau VPC et un réseau appartenant à Google ou à un tiers. Google ou les tiers proposant des services sont appelés producteurs de services. L'accès aux services privés utilise l'appairage de réseaux VPC pour établir la connectivité, et nécessite que les réseaux VPC producteur et client soient appairés entre eux. Cela diffère de Private Service Connect, qui vous permet de projeter une seule adresse IP privée dans votre sous-réseau.

La connexion privée permet aux instances de VM de votre réseau VPC de communiquer avec les services auxquels vous accédez exclusivement à l'aide d'adresses IP internes. Les instances de VM n'ont pas besoin d'accès Internet ni d'adresses IP externes pour accéder aux services disponibles via l'accès aux services privés. L'accès aux services privés peut également être étendu au réseau sur site en utilisant Cloud VPN ou Cloud Interconnect afin de permettre aux hôtes sur site d'accéder au réseau du producteur de services. Pour obtenir la liste des services gérés par Google compatibles avec l'accès aux services privés, consultez la section Services compatibles dans la documentation sur le cloud privé virtuel.

Accès au VPC sans serveur

L'accès au VPC sans serveur vous permet de vous connecter directement à votre réseau VPC à partir de services hébergés dans des environnements sans serveur tels que Cloud Run, App Engine ou Cloud Functions. La configuration de l'accès au VPC sans serveur permet à votre environnement sans serveur d'envoyer des requêtes à votre réseau VPC à l'aide de DNS internes et d'adresses IP internes. Les réponses à ces requêtes utilisent également votre réseau virtuel.

L'accès au VPC sans serveur envoie le trafic interne de votre réseau VPC vers votre environnement sans serveur uniquement lorsque ce trafic est une réponse à une requête envoyée depuis votre environnement sans serveur via le connecteur d'accès au VPC sans serveur.

L'accès au VPC sans serveur présente les avantages suivants :

  • Les requêtes envoyées à votre réseau VPC ne sont jamais exposées à Internet.
  • La communication via l'accès au VPC sans serveur peut avoir moins de latence que la communication sur Internet.

Sécurité des services

Les blocs de sécurité des services contrôlent l'accès aux ressources en fonction de l'identité du demandeur ou en fonction d'une compréhension de niveau supérieur des modèles de paquets au lieu des seules caractéristiques d'un paquet individuel.

Google Cloud Armor pour DDoS/WAF

Google Cloud Armor est un pare-feu d'application Web (WAF) et un service d'atténuation des attaques par déni de service distribué (DDoS) qui vous aide à protéger vos applications et services Web contre différents types de menaces. Ces menaces comprennent les attaques DDoS, les attaques Web telles que les scripts intersites (XSS) et l'injection SQL (SQLi), ainsi que les attaques basées sur la fraude et l'automatisation.

Google Cloud Armor inspecte les requêtes entrantes sur le réseau périphérique mondial de Google. Il dispose d'un ensemble intégré de règles de pare-feu d'application Web permettant d'analyser les attaques Web courantes et d'un système avancé de détection des attaques basé sur le ML qui crée un modèle de trafic satisfaisant, puis détecte le trafic malveillant. Enfin, Google Cloud Armor s'intègre à Google reCAPTCHA pour aider à détecter et arrêter les attaques sophistiquées basées sur la fraude et l'automatisation en utilisant à la fois la télémétrie des points de terminaison et la télémétrie du cloud.

Identity-Aware Proxy (IAP)

Identity-Aware Proxy (IAP) fournit des contrôles d'accès contextuels aux applications cloud et aux VM exécutées sur Google Cloud ou connectées à Google Cloud à l'aide de toutes les technologies de mise en réseau hybride. IAP vérifie l'identité de l'utilisateur et détermine si sa requête provient de sources fiables, en fonction de plusieurs attributs contextuels. IAP est également compatible avec la tunnelisation TCP pour l'accès SSH/RDP des utilisateurs de l'entreprise.

VPC Service Controls

VPC Service Controls vous aide à limiter le risque d'exfiltration de données à partir de services Google Cloud tels que Cloud Storage et BigQuery. VPC Service Controls permet de garantir que vos services Google Cloud ne sont utilisés que dans des environnements approuvés.

VPC Service Controls vous permet de créer des périmètres qui protègent les ressources et les données des services que vous spécifiez en limitant l'accès à des constructions d'identité cloud natives spécifiques, telles que des comptes de service et des réseaux VPC. Une fois le périmètre créé, l'accès aux services Google spécifiés est refusé, sauf si la requête provient du périmètre.

Diffusion de contenu

Les blocs de diffusion de contenu contrôlent l'optimisation de la diffusion des applications et du contenu.

Cloud CDN

Cloud CDN accélère le contenu statique en utilisant le réseau périphérique mondial de Google pour diffuser le contenu à partir du point le plus proche de l'utilisateur. Cela permet de réduire la latence de vos sites Web et applications.

Media CDN

Media CDN est la solution de diffusion multimédia de Google conçue pour les charges de travail de sortie à haut débit.

Observabilité

Les blocs d'observabilité vous offrent une visibilité sur votre réseau et fournissent des insights qui peuvent être utilisés pour documenter, examiner et résoudre les problèmes.

Network Intelligence Center

Network Intelligence Center comprend plusieurs produits abordant divers aspects de l'observabilité réseau. Chaque produit a un objectif différent et fournit des insights détaillés pour informer les administrateurs, les architectes et les professionnels sur l'état et les problèmes du réseau.

Architectures de référence

Les documents suivants présentent des architectures de référence pour différents types de charges de travail : intra-cloud, Web et hybrides. Ces architectures de charge de travail sont basées sur un plan de données cloud réalisé à l'aide des composants de base et des modèles architecturaux décrits dans les sections précédentes de ce document.

Vous pouvez utiliser les architectures de référence pour concevoir des méthodes de migration ou de création de charges de travail dans le cloud. Vos charges de travail s'appuient ensuite sur le plan de données cloud et utilisent les architectures. Bien que ces documents ne fournissent pas un ensemble exhaustif d'architectures de référence, ils couvrent les scénarios les plus courants.

Comme pour les modèles d'architecture de sécurité décrits dans l'article Architectures permettant de protéger les plans de données cloud, les services réels peuvent utiliser une combinaison de ces conceptions. Ces documents décrivent les différents types de charge de travail et les considérations liées à chaque architecture de sécurité.

Étapes suivantes