Modèles contrôlés

Le modèle gated (clôturé) repose sur une architecture qui expose certaines applications et certains services de manière précise, en fonction d'API ou de points de terminaison spécifiques exposés entre les différents environnements. Ce guide classe ce modèle en trois options possibles, chacune déterminée par le modèle de communication spécifique :

• Sortie contrôlée

• Entrée contrôlée

• Sortie et entrée contrôlées (contrôle bidirectionnel dans les deux sens)

Comme indiqué précédemment dans ce guide, les modèles d'architecture réseau décrits ici peuvent être adaptés à différentes applications présentant des exigences variées. Pour répondre aux besoins spécifiques de différentes applications, votre architecture de zone de destination principale peut intégrer un modèle ou une combinaison de modèles simultanément. Le déploiement spécifique de l'architecture sélectionnée dépend des exigences de communication spécifiques de chaque modèle de contrôle d'accès.

Cette série aborde chaque modèle de contrôle d'accès et ses options de conception possibles. Toutefois, une option de conception courante applicable à tous les modèles contrôlés est l'architecture distribuée zéro confiance pour les applications conteneurisées avec une architecture de microservices. Cette option est basée sur Cloud Service Mesh, Apigee et Apigee Adapter for Envoy (un déploiement léger de passerelle Apigee dans un cluster Kubernetes). L'adaptateur Apigee pour Envoy est un proxy de service et de périphérie Open Source courant, conçu pour les applications cloud first. Cette architecture contrôle les communications de service à service sécurisées autorisées et le sens de la communication au niveau du service. Les règles de communication du trafic peuvent être conçues, affinées et appliquées au niveau du service en fonction du modèle sélectionné.

Les modèles contrôlés permettent de mettre en œuvre Cloud Next Generation Firewall Enterprise avec le service de prévention des intrusions (IPS) pour effectuer une inspection approfondie des paquets afin de prévenir les menaces sans aucune modification de conception ou d'acheminement. Cette inspection dépend des applications spécifiques auxquelles vous accédez, du modèle de communication et des exigences de sécurité. Si les exigences de sécurité exigent une inspection approfondie des paquets et de la couche 7 avec des mécanismes de pare-feu avancés qui dépassent les capacités de Cloud Next Generation Firewall, vous pouvez utiliser un pare-feu centralisé de nouvelle génération (NGFW) hébergé dans un NVA (dispositif virtuel de réseau). Plusieurs partenaires de sécurité Google Cloud proposent des appliances NGFW qui peuvent répondre à vos exigences de sécurité. L'intégration de NVA avec ces modèles de contrôle d'accès peut nécessiter l'introduction de plusieurs zones de sécurité dans la conception du réseau, chacune avec des niveaux de contrôle d'accès distincts.