Sécurité réseau pour les applications distribuées dans Cross-Cloud Network

Last reviewed 2024-04-05 UTC

Ce document fait partie d'une série de guides de conception pour Cross-Cloud Network. Dans cette partie, nous allons explorer la couche de sécurité réseau.

Cette série comprend les parties suivantes :

Surfaces de sécurité

Lorsque vous concevez la couche de sécurité pour Cross-Cloud Network, vous devez prendre en compte les surfaces de sécurité suivantes :

  • Sécurité des charges de travail
  • Sécurité du périmètre de domaine

La sécurité des charges de travail contrôle la communication entre les charges de travail à travers et au sein du cloud privé virtuel (VPC). La sécurité des charges de travail utilise des points d'application de mesures sécurité proches des charges de travail dans l'architecture. Dans la mesure du possible, Cross-Cloud Network assure la sécurité des charges de travail à l'aide du pare-feu Cloud Next Generation Firewall de Google Cloud.

La sécurité périmétrique est requise à toutes les limites du réseau. Étant donné que le périmètre interconnecte généralement des réseaux gérés par différentes organisations, des contrôles de sécurité plus stricts sont souvent nécessaires. Vous devez vous assurer que les communications suivantes entre les réseaux sont sécurisées :

  • Communications entre VPC
  • Communications entre connexions hybrides vers d'autres fournisseurs cloud ou centres de données sur site
  • Communications vers Internet

La possibilité d'insérer des dispositifs virtuels de réseau tiers (NVA) dans l'environnement Google Cloud est essentielle pour répondre aux exigences de sécurité périmétrique entre connexions hybrides.

Sécurité des charges de travail dans le cloud

Utilisez des stratégies de pare-feu dans Google Cloud pour sécuriser les charges de travail et fournir des fonctionnalités de pare-feu avec état qui sont évolutives horizontalement et appliquées à chaque instance de VM. La nature distribuée des pare-feu Google Cloud vous aide à implémenter des règles de sécurité pour la microsegmentation du réseau sans nuire aux performances de vos charges de travail.

Utilisez des stratégies de pare-feu hiérarchiques pour améliorer la gestion et renforcer l'application de la conformité pour vos stratégies de pare-feu. Les stratégies de pare-feu hiérarchiques vous permettent de créer et d'appliquer une stratégie de pare-feu homogène au sein de votre organisation. Vous pouvez attribuer des stratégies de pare-feu hiérarchiques à l'organisation ou à des dossiers individuels. En outre, les règles des stratégies de pare-feu hiérarchiques peuvent déléguer l'évaluation à des stratégies de niveau inférieur (stratégies de pare-feu réseau au niveau mondial ou régional) avec une action goto_next.

Les règles de niveau inférieur ne prévalent jamais sur une règle de niveau supérieur dans la hiérarchie des ressources. Cette structure de règles permet aux administrateurs à l'échelle de l'organisation de gérer les règles de pare-feu obligatoires de manière centralisée. Les cas d'utilisation courants des stratégies de pare-feu hiérarchiques comprennent l'accès via un hôte bastion à une organisation ou à plusieurs projets, la possibilité de contrôler des systèmes de sondes ou de vérification d'état centralisés, et l'application d'une limite de réseau virtuel pour une organisation ou un groupe de projets. Pour obtenir d'autres exemples d'utilisation des stratégies de pare-feu hiérarchiques, consultez la section Exemples de stratégies de pare-feu hiérarchiques.

Utilisez des stratégies de pare-feu réseau mondiales et régionales pour définir des règles au niveau d'un réseau VPC individuel, soit pour toutes les régions du réseau (mondial), soit pour une seule région (régional).

Pour obtenir des contrôles plus précis appliqués au niveau de la machine virtuelle (VM), nous vous recommandons d'utiliser des tags gérés par IAM (Identity and Access Management) au niveau de l'organisation ou du projet. Les tags gérés par IAM permettent d'appliquer des règles de pare-feu basées sur l'identité de l'hôte de la charge de travail, et non sur l'adresse IP de l'hôte, et fonctionnent sur plusieurs appairages de réseaux VPC. Les règles de pare-feu déployées à l'aide de tags peuvent fournir une microsegmentation au sein des sous-réseaux, avec une couverture de stratégie qui s'applique automatiquement aux charges de travail quel que soit l'endroit où elles sont déployées, indépendamment de l'architecture réseau.

En plus des capacités d'inspection avec état et la compatibilité des tags, Cloud Next Generation Firewall est également compatible avec Threat Intelligence, les noms de domaine complets (FQDN) et le filtrage par géolocalisation.

Nous vous recommandons de procéder à la migration des règles de pare-feu VPC vers des stratégies de pare-feu. Pour vous aider dans la migration, utilisez l'outil de migration, qui crée une stratégie de pare-feu réseau au niveau mondial et convertit les règles de pare-feu VPC existantes dans la nouvelle stratégie.

Sécurité du périmètre dans le cloud

Dans un environnement réseau multicloud, la sécurité du périmètre est généralement mise en œuvre au niveau de chaque réseau. Par exemple, le réseau sur site possède son propre ensemble de pare-feu de périmètre, tandis que chaque réseau cloud met en œuvre des pare-feu de périmètre distincts.

Comme Cross-Cloud Network est conçu pour servir de hub pour toutes les communications, vous pouvez unifier et centraliser les contrôles de sécurité du périmètre et déployer un ensemble unique de pare-feu de périmètre dans votre réseau Cross-Cloud Network. Pour fournir une pile de sécurité de périmètre intégrée de votre choix, Cross-Cloud Network vous fournit des options flexibles pour insérer des dispositifs virtuels de réseau (NVA).

Dans les conceptions présentées dans les schémas, vous pouvez déployer des NVA tiers dans le VPC de transit du projet de hub.

Les NVA peuvent être déployés sur une seule interface réseau (mode avec carte d'interface réseau unique) ou sur plusieurs interfaces réseau sur plusieurs VPC (mode avec plusieurs cartes d'interface réseau). Pour Cross-Cloud Network, nous vous recommandons un déploiement à carte d'interface réseau unique pour les NVA, car cette option vous permet d'effectuer les opérations suivantes :

  • Insérer les NVA avec des routes basées sur des règles.
  • Éviter de créer des topologies rigides.
  • Déployer dans diverses topologies inter-VPC.
  • Activer l'autoscaling pour les NVA.
  • Évoluer vers de nombreux VPC au fil du temps, sans qu'il soit nécessaire de modifier le déploiement de l'interface NVA.

Si votre conception nécessite plusieurs cartes d'interface réseau, les recommandations sont détaillées dans la section Sécurité du périmètre NVA à plusieurs cartes d'interface réseau.

Pour parvenir à l'orientation du trafic requise pour le déploiement NVA, ce guide recommande l'application sélective de routes statiques et basées sur des règles dans les tables de routage des VPC. Les routes basées sur des règles sont plus flexibles que les routes standards, car elles sont mises en correspondance avec les informations sources et de destination. Ces routes basées sur des règles ne sont également appliquées qu'à des emplacements spécifiques de la topologie du réseau cloud. Ce niveau de précision permet de définir un comportement d'orientation du trafic très spécifique pour des flux de connectivité très spécifiques.

En outre, cette conception permet de faire appel aux mécanismes de résilience requis par les NVA. Les NVA sont appuyés par un équilibreur de charge TCP/UDP interne afin de pouvoir utiliser la redondance des NVA, l'autoscaling pour une meilleure flexibilité, et la symétrie des flux pour assurer le traitement du trafic bidirectionnel avec état.

Sécurité du périmètre de NVA à carte d'interface réseau unique

Dans la conception décrite sur la page Connectivité inter-VPC pour les services centralisés, le VPC de transit agit comme un hub vers les VPC spoke connectés via l'appairage de réseau VPC et le VPN haute disponibilité. Le VPC de transit permet également la connectivité entre les réseaux externes et les VPC spoke.

Pour les besoins de l'insertion de NVA à carte d'interface réseau unique, cette conception combine les deux modèles suivants :

  • Insérer des NVA au niveau d'un hub d'appairage de réseaux VPC avec des connexions hybrides externes
  • Insérer des NVA au niveau d'un hub VPC de VPN haute disponibilité avec des connexions hybrides externes

Le schéma suivant montre les NVA insérés au niveau des hubs pour l'appairage de réseaux VPC et le VPN haute disponibilité :

NVA insérés au niveau des hubs pour l'appairage de réseaux VPC et le VPN haute disponibilité

Le schéma précédent illustre un format combiné :

  • Un VPC de transit qui héberge les rattachements de VLAN Cloud Interconnect fournissant une connectivité hybride ou multicloud. Ce VPC contient également les NVA à carte d'interface réseau unique qui surveillent les connexions hybrides.
  • Des VPC d'application connectés au VPC de transit via l'appairage de réseaux VPC.
  • Un VPC de services centraux connecté au VPC de transit via un VPN haute disponibilité.

Dans cette conception, les spokes connectés à l'aide d'un VPN haute disponibilité utilisent le VPC de transit pour communiquer avec les spokes connectés par l'appairage de réseaux VPC. La communication est orientée via les pare-feu de NVA tiers à l'aide de la combinaison suivante d'équilibrage de charge à stratégie directe, de routes statiques et de routes basées sur des règles :

  1. Pour orienter le trafic du VPN haute disponibilité vers l'équilibreur de charge interne, appliquez des routes basées sur des règles sans tag sur le VPC de transit. Sur ces routes basées sur des règles, utilisez des plages CIDR source et de destination qui vont permettre d'établir la symétrie du trafic.
  2. Pour orienter le trafic entrant vers l'équilibreur de charge réseau interne à stratégie directe, appliquez des routes basées sur des règles aux connexions Cloud Interconnect dans le VPC de transit. Il s'agit de routes régionales.
  3. Pour que le trafic quittant le NVA ne soit pas directement réacheminé vers le NVA, rendez toutes les interfaces de NVA la cible d'une route basée sur des règles à ignorer pour ignorer les autres routes basées sur des règles. Le trafic suit ensuite la table de routage VPC une fois qu'il a été traité par les NVA.
  4. Pour orienter le trafic vers les équilibreurs de charge internes de NVA dans le VPC de transit, appliquez des routes statiques aux VPC d'application. Ceux-ci peuvent être limités au niveau régional à l'aide de tags réseau.

Sécurité du périmètre de NVA à plusieurs cartes d'interface réseau

En mode avec plusieurs cartes d'interface réseau, la topologie est plus statique, car les NVA créent un pont de connectivité entre les différents VPC dans lesquels résident les différentes interfaces réseau.

Lorsque des zones basées sur l'interface sont requises dans un pare-feu, la conception à plusieurs cartes d'interface réseau suivante permet la connectivité externe requise. Cette conception attribue différentes interfaces de pare-feu aux réseaux externes. Les professionnels de la sécurité désignent les réseaux externes comme des réseaux non approuvés et les réseaux internes comme des réseaux approuvés. Pour le déploiement de NVA à plusieurs cartes d'interface réseau, cette conception est mise en œuvre à l'aide de VPC approuvés et non approuvés.

Pour les communications internes, la mise en place d'un pare-feu peut être appliquée à l'aide d'un modèle d'insertion à carte d'interface réseau unique correspondant à un modèle de zone basé sur le CIDR.

Dans cette conception, vous insérez des NVA en configurant les éléments suivants :

  1. Pour orienter le trafic du VPN haute disponibilité vers l'équilibreur de charge interne, appliquez des routes basées sur des règles sans tag sur le VPC approuvé. Sur ces routes basées sur des règles, utilisez des plages CIDR source et de destination qui vont permettre d'établir la symétrie du trafic.
  2. Pour orienter le trafic entrant vers l'équilibreur de charge réseau interne à stratégie directe, appliquez des routes basées sur des règles aux connexions Cloud Interconnect dans le VPC non approuvé. Il s'agit de routes régionales.
  3. Pour que le trafic quittant le NVA ne soit pas directement réacheminé vers le NVA, rendez toutes les interfaces de NVA la cible d'une route basée sur des règles à ignorer pour ignorer les autres routes basées sur des règles. Le trafic suit ensuite la table de routage VPC une fois qu'il a été traité par les NVA.
  4. Pour orienter le trafic vers les équilibreurs de charge internes de NVA dans le VPC approuvé, appliquez des routes statiques aux VPC d'application. Ceux-ci peuvent être limités au niveau régional à l'aide de tags réseau.

Le schéma suivant montre des NVA à plusieurs cartes d'interface réseau insérés entre les réseaux VPC non approuvés et approuvés dans le projet de hub :

NVA pour la communication interne

Étapes suivantes

Contributeurs

Auteurs :

  • Victor Moreno | Responsable produit, Mise en réseau cloud
  • Ghaleb Al-habian | Spécialiste réseau
  • Deepak Michael | Ingénieur client spécialiste en gestion des réseaux
  • Osvaldo Costa | Ingénieur client spécialiste en gestion des réseaux
  • Jonathan Almaleh | Consultant solutions techniques pour le personnel

Autres contributeurs :