Guide

Planifier l'adressage IP pour les déploiements à grande échelle ou hybrides dans le cloud.

→Utilisez des VPC en mode personnalisé. Allouez des blocs CIDR RFC 1918 non chevauchants (par exemple, 172.16.0.0/12) pour éviter les conflits avec les systèmes sur site (souvent 10.0.0.0/8). Utilisez 100.64.0.0/10 pour les plages secondaires de pods GKE.

Pourquoi: Évite les conflits d'IP avec les systèmes sur site pour une future connectivité hybride et offre un contrôle total sur l'espace d'adressage, ce qui est essentiel pour la mise à l'échelle et pour éviter des coûts de ré-adressage IP élevés.

Référence↗

Fournir une isolation réseau pour plusieurs locataires/environnements (développement, production) tout en centralisant la gestion du réseau et les services partagés.

→Utilisez le VPC partagé. Le projet hôte contient le VPC, les sous-réseaux, les pare-feu et les interconnexions. Les locataires/environnements sont des projets de service attachés au projet hôte.

Pourquoi: Centralise l'administration réseau dans le projet hôte tout en déléguant la gestion des ressources aux projets de service. Plus évolutif et gouvernable que le peering de VPC pour de nombreux projets au sein d'une organisation.

Référence↗

Planifier l'adressage IP pour les grands clusters GKE utilisant la mise en réseau native VPC.

→Dans un VPC en mode personnalisé, prévoyez trois plages CIDR : une plage primaire pour les nœuds, une plage secondaire pour les Pods et une autre pour les Services. Pour l'expansion, utilisez un CIDR multi-pod non contigu.

Pourquoi: La mise en réseau native VPC nécessite des plages secondaires dédiées et non chevauchantes pour les pods et les services. Un dimensionnement approprié évite l'épuisement des adresses IP, un problème courant et perturbateur dans les grands clusters.

Référence↗

Les VM sans IP externes doivent accéder aux API Google Cloud (par exemple, Cloud Storage, BigQuery).

→Activez l'accès privé à Google sur le sous-réseau. Vous pouvez également configurer le DNS pour résoudre `*.googleapis.com` vers `restricted.googleapis.com` (199.36.153.4/30) afin d'appliquer VPC-SC.

Pourquoi: Dirige le trafic vers les API Google via le réseau interne de Google sans nécessiter d'adresses IP publiques sur les VM. L'utilisation de `restricted.googleapis.com` ajoute une couche de protection contre l'exfiltration de données.

Référence↗

Fournir un accès privé à un service de votre VPC pour les consommateurs (partenaires, autres unités commerciales) dont les VPC ont des plages IP qui se chevauchent.

→Publiez le service (via un équilibreur de charge interne) à l'aide d'une attache de service Private Service Connect (PSC). Les consommateurs créent un point de terminaison PSC dans leur VPC avec une IP de leur propre plage.

Pourquoi: PSC découple les réseaux du producteur et du consommateur, en utilisant la NAT pour gérer les IP qui se chevauchent. Il fournit un accès sécurisé au niveau du service, et non une connectivité réseau complète comme le peering de VPC.

Référence↗

Connecter un grand nombre (50+) de VPC et/ou de sites sur site dans une topologie en étoile pour une gestion et une connectivité centralisées.

→Utilisez Network Connectivity Center. Configurez le hub et attachez les VPC en tant que branches VPC et les connexions sur site (VPN/Interconnect) en tant que branches hybrides.

Pourquoi: NCC est la solution gérée par Google pour les topologies en étoile à grande échelle, simplifiant la gestion des routes et permettant d'aller au-delà de la limite de 25 pairs du peering de VPC.

Déployer un cluster GKE où les nœuds et le plan de contrôle n'ont pas d'adresses IP publiques pour une sécurité renforcée.

→Créez un cluster GKE privé. Cela attribue uniquement des IP internes aux nœuds et crée un point de terminaison privé pour le plan de contrôle. Configurez des réseaux autorisés pour restreindre l'accès au plan de contrôle.

Pourquoi: Un cluster privé retire le plan de contrôle et les nœuds de l'internet public, réduisant considérablement la surface d'attaque. Tout le trafic de gestion et de charge de travail reste sur le réseau privé.

Les charges de travail sans serveur (Cloud Run, Functions) doivent accéder à des ressources (par exemple, Cloud SQL, Memorystore) à l'intérieur d'un VPC.

→Créez un connecteur d'accès VPC sans serveur dans le VPC cible. Configurez le service sans serveur pour qu'il utilise ce connecteur pour le trafic sortant.

Pourquoi: Le connecteur agit comme un proxy, permettant aux services sans serveur (qui s'exécutent dans un environnement géré par Google) d'envoyer du trafic vers un VPC géré par le client en utilisant des adresses IP internes.

Une application (par exemple, HPC, trading financier) nécessite la latence réseau la plus faible possible entre un groupe de VM.

→Créez une politique de placement compact et appliquez-la aux VM. Utilisez des types de machines avec une mise en réseau Tier_1.

Pourquoi: Colloquer les VM dans le même rack réseau minimise les sauts de réseau et la distance physique, réduisant considérablement la latence par rapport au placement standard des VM.

Mettre en œuvre un modèle de sécurité zéro confiance pour les microservices, nécessitant une identité forte, une communication chiffrée (mTLS) et une autorisation granulaire.

→Déployez Anthos Service Mesh. Activez le mTLS automatique pour toutes les communications de service à service. Utilisez les ressources `AuthorizationPolicy` pour définir les communications autorisées.

Pourquoi: Un service mesh découple la sécurité du réseau sous-jacent, fournissant l'identité de la charge de travail, le mTLS transparent et l'autorisation L7, qui sont des principes fondamentaux d'une architecture zéro confiance.

Les charges de travail (VM, pods GKE) sans IP publiques ont besoin d'une adresse IP source stable et prévisible pour les connexions sortantes vers des API externes qui utilisent des listes blanches.

→Déployez Cloud NAT. Utilisez l'option "allocation manuelle d'IP NAT" et attribuez des adresses IP externes statiques réservées à la passerelle NAT.

Pourquoi: Cloud NAT avec allocation manuelle fournit un pool partagé d'IP de sortie statiques. Cela découple la charge de travail de l'IP, permettant la mise à l'échelle sans avoir besoin de mettre à jour les listes blanches externes.

Le peering de VPC est établi mais les VM ne peuvent pas communiquer entre les VPC appairés.

→Vérifiez que les règles de pare-feu dans *les deux* VPC autorisent le trafic entrant depuis la plage d'IP de l'autre VPC. La connexion de peering établit uniquement le routage ; elle ne crée pas implicitement d'autorisations de pare-feu.

Pourquoi: Une erreur courante est de supposer que le peering ouvre les ports du pare-feu. La règle implicite de refus de tout trafic entrant bloque le trafic jusqu'à ce qu'une règle d'autorisation explicite soit créée.

Dans un VPC partagé, accordez à une équipe/un projet de service la permission d'utiliser uniquement un sous-réseau spécifique, et non l'ensemble du VPC.

→Dans le projet hôte, attribuez le rôle IAM `compute.networkUser` à l'identité du projet de service (par exemple, compte de service, groupe) au niveau de la ressource du sous-réseau.

Pourquoi: Les rôles IAM peuvent être définis pour des ressources spécifiques. L'application de `compute.networkUser` au niveau du sous-réseau applique le principe du moindre privilège, permettant l'utilisation de ce seul sous-réseau.

Mettre en œuvre la microsegmentation pour une application multi-niveaux (par exemple, web, application, base de données) sur Compute Engine.

→Attribuez des balises réseau aux VM en fonction de leur niveau (par exemple, `web-server`). Créez des règles de pare-feu qui utilisent ces balises comme spécificateurs de source et de destination.

Pourquoi: Les balises offrent une alternative flexible et évolutive aux règles basées sur IP. La politique de pare-feu est indépendante du nombre ou des IP des VM dans un niveau.

Capturer les métadonnées de trafic pour la conformité/l'audit tout en minimisant le volume de journaux et les coûts de stockage.

→Activez les journaux de flux VPC avec un intervalle d'agrégation plus long (par exemple, 10 minutes), un taux d'échantillonnage réduit (par exemple, 0,5) et un filtrage des métadonnées pour exclure les champs inutiles.

Pourquoi: Les paramètres par défaut génèrent des quantités massives de données. L'ajustement de ces paramètres réduit considérablement les coûts tout en offrant une visibilité suffisante pour la plupart des cas d'utilisation d'audit.

Fournir une application globale avec une faible latence, acheminant les utilisateurs vers le backend sain le plus proche avec basculement automatique.

→Utilisez un équilibreur de charge d'application externe global (ou un équilibreur de charge proxy TCP/SSL pour les non-HTTP). Configurez les services de backend/NEGs dans plusieurs régions. Utilisez la mise en réseau Premium Tier.

Pourquoi: L'IP anycast de l'équilibreur de charge dirige les utilisateurs vers le PoP de périphérie Google le plus proche. Le trafic transite ensuite par le backbone privé de Google vers le backend sain le plus proche pour des performances optimales.

Référence↗

Acheminer le trafic interne en fonction du chemin d'URL ou du nom d'hôte, avec terminaison SSL, accessible uniquement au sein du VPC ou depuis le site local.

→Utilisez un équilibreur de charge d'application interne régional. Configurez une carte d'URL pour diriger le trafic en fonction des règles d'hôte/chemin. Nécessite un sous-réseau uniquement pour les proxys.

Pourquoi: Il s'agit de l'équilibreur de charge interne L7 géré par Google. Il offre des fonctionnalités de routage avancées non disponibles avec l'équilibreur de charge réseau L4 Internal Passthrough.

Utiliser Cloud CDN pour mettre en cache et servir du contenu privé ou spécifique à l'utilisateur sans le rendre public.

→Activez Cloud CDN sur un backend privé (par exemple, un bucket GCS). Générez des URL signées ou des cookies signés Cloud CDN dans votre application pour accorder aux utilisateurs un accès temporaire et authentifié.

Pourquoi: Les URL/cookies signés fournissent un jeton sécurisé que Cloud CDN valide avant de servir un objet mis en cache, tirant parti de la mise en cache en périphérie tout en maintenant un contrôle d'accès strict.

Activer la résolution DNS bidirectionnelle entre un réseau sur site et un VPC GCP.

→1) Sur site résout GCP : Créez une politique de serveur entrant Cloud DNS. Configurez le DNS sur site pour qu'il transfère vers les IP du forwarder entrant. 2) GCP résout sur site : Créez une zone de transfert Cloud DNS qui pointe vers les serveurs DNS sur site.

Pourquoi: Cette configuration standard en deux parties offre une résolution de noms transparente et privée pour les environnements hybrides, un composant essentiel pour l'interopérabilité des applications.

Le taux d'accès au cache de Cloud CDN est faible en raison de variations d'URL inutiles (par exemple, paramètres de suivi).

→Configurez une politique de clé de cache personnalisée pour le service de backend. Excluez les paramètres de requête non essentiels, les cookies et les en-têtes de la clé de cache.

Pourquoi: Par défaut, l'URL complète est la clé de cache. La normalisation de la clé en excluant les paramètres non pertinents empêche la fragmentation du cache et améliore considérablement le taux d'accès.

Résoudre un nom DNS vers une IP interne pour les clients internes et une IP publique pour les clients externes.

→Créez une zone privée Cloud DNS pour le domaine (visible par votre VPC) avec l'enregistrement IP interne. Créez une zone publique Cloud DNS correspondante avec l'enregistrement IP publique.

Pourquoi: Cloud DNS sert automatiquement la réponse de la zone privée aux clients au sein du VPC autorisé, et la réponse de la zone publique à tous les autres.

Une application interne dans une région doit être accessible par des clients (VM, sur site) dans d'autres régions.

→Activez l'option "Accès Global" sur l'équilibreur de charge TCP/UDP interne ou la règle de transfert de l'équilibreur de charge d'application interne.

Pourquoi: Par défaut, les équilibreurs de charge internes sont régionaux. L'Accès Global les rend accessibles depuis n'importe quelle région du réseau VPC, simplifiant les architectures de services internes multi-régions.

Établir une connectivité haute disponibilité (SLA de 99,99 %), à large bande passante (10G+) entre les systèmes sur site et GCP.

→Provisionnez au minimum quatre connexions Dedicated Interconnect, deux dans une métropole et deux dans une autre, chaque paire métropolitaine étant dans des domaines de disponibilité périphériques différents. Configurez BGP.

Pourquoi: La redondance entre différentes zones métropolitaines et domaines de défaillance (domaines de disponibilité de périphérie) est requise pour le SLA de 99,99 %.

Référence↗

Besoin d'une connexion hybride chiffrée, fiable (SLA de 99,9 % ou 99,99 %) et rapidement déployable avec une bande passante modérée (< 6 Gbit/s).

→Utilisez HA VPN avec BGP pour le routage dynamique. Pour un SLA de 99,99 %, utilisez deux passerelles HA VPN. Pour un SLA de 99,9 %, utilisez une seule passerelle avec deux tunnels.

Pourquoi: HA VPN est plus rapide à configurer qu'Interconnect, offre un SLA solide et une bande passante suffisante pour de nombreux cas d'utilisation, ce qui en fait le choix par défaut pour les connexions non physiques.

Chiffrer tout le trafic transitant par une liaison Dedicated ou Partner Interconnect à des fins de conformité.

→Configurez HA VPN sur Interconnect. Créez des tunnels HA VPN qui utilisent les attachements VLAN d'Interconnect comme transport sous-jacent.

Pourquoi: Ce modèle combine la bande passante élevée et la faible latence d'Interconnect avec le chiffrement IPsec de HA VPN, offrant le meilleur des deux mondes.

Établir une connectivité dédiée, privée et à haut débit entre GCP et un autre fournisseur de cloud majeur (AWS, Azure, OCI).

→Utilisez Cross-Cloud Interconnect. Provisionnez une connexion physique dédiée entre le réseau de Google et le réseau de l'autre fournisseur de cloud. Configurez BGP avec Cloud Router.

Pourquoi: Fournit un chemin direct, soutenu par un SLA, à faible latence entre les clouds, évitant l'internet public et les performances variables des VPN.

Un réseau sur site connecté via Interconnect à une région GCP doit accéder aux ressources de toutes les autres régions GCP.

→Activez le mode de routage dynamique "Global" sur le VPC. Le Cloud Router annoncera alors les routes pour tous les sous-réseaux du VPC, et pas seulement ceux de sa région locale.

Pourquoi: Le routage global permet à un point de connexion hybride unique de servir de rampe d'accès à l'ensemble du réseau mondial de Google, simplifiant l'accès multi-régions.

Influencer la sélection du chemin de trafic sur les connexions hybrides redondantes (VPN/Interconnect) en utilisant BGP.

→Pour influencer le trafic de GCP vers sur site, faites en sorte que le système sur site annonce des routes plus spécifiques ou utilise un AS_PATH plus court pour le chemin préféré. Pour influencer le trafic de sur site vers GCP, annoncez depuis Cloud Router avec une valeur MED inférieure pour le chemin préféré.

Pourquoi: La sélection du chemin BGP suit un algorithme clair. La correspondance de préfixe la plus longue est essentielle pour le trafic sortant, tandis que MED influence les décisions du trafic entrant.

Configurer un basculement actif/passif entre une connexion Interconnect dédiée principale et une HA VPN de secours.

→Utilisez BGP sur les deux. Sur Cloud Router, annoncez les routes via Interconnect avec une priorité de base plus faible (par exemple, 100) et via VPN avec une priorité de base plus élevée (par exemple, 200).

Pourquoi: GCP préfère les routes BGP avec une valeur de priorité inférieure (préférence plus élevée). Le trafic utilise l'Interconnect principal. En cas de défaillance, ses routes sont retirées et les routes VPN de secours deviennent actives.

Prévenir l'exfiltration de données depuis les services Google Cloud sensibles (par exemple, BigQuery, GCS), en garantissant l'accès uniquement depuis les réseaux autorisés.

→Implémentez les contrôles de service VPC. Créez un périmètre de service autour des projets contenant des données sensibles. Configurez les niveaux d'accès pour définir les sources autorisées (plages IP, état de l'appareil, identité).

Pourquoi: VPC-SC crée une frontière réseau virtuelle autour des services gérés par Google, bloquant l'accès depuis l'extérieur du périmètre même avec des identifiants valides. Un contrôle essentiel de la gouvernance des données.

Référence↗

Appliquer des règles de pare-feu de base cohérentes et non modifiables au sein d'une organisation, tout en permettant une personnalisation au niveau du projet.

→Implémentez des politiques de pare-feu hiérarchiques au niveau de l'organisation ou du dossier. Placez les règles critiques ici. Utilisez l'action `goto_next` pour déléguer l'évaluation aux politiques de niveau inférieur.

Pourquoi: Les politiques hiérarchiques sont évaluées avant les règles au niveau du VPC et ne peuvent pas être modifiées par les propriétaires de projet, garantissant une gouvernance centralisée. `goto_next` offre de la flexibilité.

Protéger une application web contre les vulnérabilités OWASP Top 10 et appliquer une limitation de débit par IP client.

→Attachez une politique de sécurité Cloud Armor à l'équilibreur de charge d'application externe global. Appliquez les règles WAF préconfigurées (par exemple, `sqli-v3.3-stable`) et ajoutez une règle basée sur le débit.

Pourquoi: Cloud Armor offre une sécurité périphérique. Les règles WAF préconfigurées offrent une protection gérée, tandis que les règles basées sur le débit atténuent les attaques DoS et par force brute.

Mettre en œuvre une sécurité réseau granulaire au niveau des pods au sein d'un cluster GKE basée sur des étiquettes.

→Activez l'application des politiques réseau sur le cluster GKE. Créez des ressources `NetworkPolicy` Kubernetes qui définissent des règles d'entrée/sortie pour les pods en utilisant des sélecteurs d'étiquettes.

Pourquoi: Kubernetes NetworkPolicy est la méthode native pour implémenter la microsegmentation au niveau du pod, offrant une granularité supérieure aux règles de pare-feu VPC qui opèrent au niveau du nœud.

Inspecter tout le trafic inter-VPC ou VPC vers Internet à l'aide d'un pare-feu/NVA tiers centralisé.

→Créez une topologie en étoile. Déployez le ou les NVA dans un VPC hub. Configurez des routes personnalisées dans les branches qui dirigent le trafic vers un équilibreur de charge interne dans le hub comme prochaine saut.

Pourquoi: Ce modèle force le trafic à passer par un point d'inspection central. L'ILB fournit une IP de prochaine saut stable et hautement disponible pour les NVA.

Fournir un accès sécurisé, basé sur l'identité et zéro-confiance aux utilisateurs pour les applications web internes ou les VM sans utiliser de VPN.

→Pour les applications web, activez IAP sur un service de backend d'équilibreur de charge HTTPS externe. Pour SSH/RDP, utilisez IAP pour le transfert TCP. Attribuez les rôles IAM IAP appropriés aux utilisateurs.

Pourquoi: IAP déplace le contrôle d'accès du périmètre réseau vers l'identité de l'utilisateur, authentifiant et autorisant chaque requête. C'est un composant essentiel du modèle zéro-confiance BeyondCorp de Google.

Mettre en œuvre la prévention des menaces (IDS/IPS) pour le trafic inter-VPC ou VPC vers Internet, y compris la détection de logiciels malveillants et l'inspection TLS.

→Utilisez Cloud NGFW. Associez une politique de pare-feu au VPC, créez des règles avec des profils de sécurité pour la prévention des menaces et activez éventuellement l'inspection TLS.

Pourquoi: Cloud NGFW est le service de pare-feu distribué et géré de Google, offrant des capacités d'inspection L7 avancées de Palo Alto Networks, intégré directement dans le VPC.

Inspecter, journaliser et contrôler de manière centralisée tout le trafic sortant du VPC vers Internet à des fins de sécurité et de conformité.

→Déployez Secure Web Proxy. Configurez des politiques de sécurité pour le filtrage d'URL et l'inspection TLS. Acheminer le trafic des sous-réseaux vers le proxy à l'aide de routes personnalisées.

Pourquoi: Il s'agit de la solution gérée de Google pour une sortie sécurisée, offrant une visibilité et un contrôle L7 sans nécessiter de flottes de proxys auto-gérées.

Diagnostiquer rapidement une défaillance de connectivité entre deux points de terminaison au sein de GCP (par exemple, VM-à-VM, VM-à-Cloud SQL).

→Utilisez les tests de connectivité du Network Intelligence Center. Spécifiez la source et la destination, et il analysera l'ensemble du chemin configuré pour détecter les problèmes.

Pourquoi: Cet outil non intrusif fournit une analyse définitive du chemin, identifiant le point exact de défaillance (pare-feu, route, etc.) beaucoup plus rapidement qu'une inspection manuelle.

Une session BGP sur une connexion hybride se réinitialise ("flappe") par intermittence.

→Vérifiez l'absence de désaccord dans les temporisateurs de keepalive/hold BGP. Si les temporisateurs expirent sous charge, augmentez-les (par exemple, 60s keepalive, 180s hold). Vérifiez également les paramètres MTU et activez BFD.

Pourquoi: Des temporisateurs mal appariés ou trop agressifs sont une cause fréquente de "flapping" BGP, car une congestion réseau transitoire peut retarder les paquets keepalive au-delà du temps de maintien.

Enquêter sur les rapports de latence accrue pour le trafic entre les régions GCP.

→Utilisez le tableau de bord de performance du Network Intelligence Center pour afficher les métriques historiques et en temps réel de latence et de perte de paquets entre toutes les paires de zones GCP.

Pourquoi: Cet outil offre une visibilité directe sur les performances du réseau backbone de Google, aidant à distinguer un problème d'application d'un problème d'infrastructure réseau.

Les VM utilisant Cloud NAT rencontrent des échecs de connexion sortante intermittents, et les journaux NAT affichent des rejets `OUT_OF_RESOURCES`.

→Il s'agit probablement d'un épuisement des ports NAT. Augmentez le nombre d'adresses IP NAT allouées, augmentez le "Nombre minimal de ports par instance de VM", et/ou activez l'allocation dynamique de ports.

Pourquoi: Des taux de connexion élevés provenant de nombreuses VM peuvent épuiser le pool de ports source alloué par IP NAT. L'allocation de plus de ressources est la solution requise.