Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Last reviewed 2023-12-14 UTC
O padrão controlado é baseado em uma arquitetura que expõe
serviços aplicativos de seleção de maneira refinada, com base em APIs ou endpoints específicos expostos
entre diferentes ambientes. Neste guia, categorizamos
esse padrão em três opções possíveis, cada uma determinada pelo
modelode comunicação específico:
Conforme mencionado anteriormente neste guia, os padrões de arquitetura de rede
descritos podem ser adaptados a várias aplicações com requisitos diversos.
Para atender às necessidades específicas de diferentes aplicativos, sua arquitetura de zona de destino principal
pode incorporar um padrão ou uma combinação de padrões
simultaneamente. A implantação específica da arquitetura selecionada é
determinada pelos requisitos de comunicação específicos de cada padrão controlado.
Confira nesta série os padrões controlados e as possíveis opções de design.
No entanto, uma opção de design comum aplicável a todos os padrões fechados é a
Arquitetura distribuída de confiança zero
para aplicativos conteinerizados com arquitetura de microsserviços. Essa opção conta com
a tecnologia do
Cloud Service Mesh
Apigee e
Adaptador da Apigee para Envoy: uma
implantação leve de gateway da Apigee em um cluster do Kubernetes.
O adaptador da Apigee para Envoy é um proxy de serviço e borda de código aberto conhecido
desenvolvido para aplicativos com priorização da nuvem. Os controles de arquitetura permitem
comunicações entre serviços protegidas e a direção da comunicação
no nível do serviço. As políticas de comunicação de tráfego podem ser criadas, ajustadas e
aplicadas no nível de serviço com base no padrão selecionado.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2023-12-14 UTC."],[[["\u003cp\u003eThe gated pattern provides fine-grained control over the exposure of applications and services through specific APIs or endpoints, and is categorized into gated egress, gated ingress, and bidirectional gated patterns.\u003c/p\u003e\n"],["\u003cp\u003eThe networking architecture patterns can be customized to fit different applications' needs, allowing for single or combined pattern use within a main landing zone architecture based on the communication requirements.\u003c/p\u003e\n"],["\u003cp\u003eA common design option for all gated patterns is the Zero Trust Distributed Architecture for containerized applications with microservices, utilizing Cloud Service Mesh, Apigee, and Apigee Adapter for Envoy to secure service-to-service communications.\u003c/p\u003e\n"],["\u003cp\u003eGated patterns can integrate Cloud Next Generation Firewall Enterprise with intrusion prevention service (IPS) for deep packet inspection or can be implemented with centralized next generation firewall (NGFW) hosted in a network virtual appliance (NVA) for more advanced security.\u003c/p\u003e\n"]]],[],null,["# Gated patterns\n\nThe *gated* pattern is based on an architecture that exposes select\napplications and services in a fine-grained manner, based on specific exposed\nAPIs or endpoints between the different environments. This guide categorizes\nthis pattern into three possible options, each determined by the specific\ncommunication model:\n\n- [Gated egress](/architecture/hybrid-multicloud-secure-networking-patterns/gated-egress)\n- [Gated ingress](/architecture/hybrid-multicloud-secure-networking-patterns/gated-ingress)\n\n- [Gated egress and ingress](/architecture/hybrid-multicloud-secure-networking-patterns/gated-egress-ingress)\n (bidirectional gated in both directions)\n\nAs previously mentioned in this guide, the networking architecture patterns\ndescribed here can be adapted to various applications with diverse requirements.\nTo address the specific needs of different applications, your main landing zone\narchitecture might incorporate one pattern or a combination of patterns\nsimultaneously. The specific deployment of the selected architecture is\ndetermined by the specific communication requirements of each gated pattern.\n| **Note:** In general, the *gated* pattern can be applied or incorporated with the landing zone design option that exposes the services in a [consumer-producer model](/architecture/landing-zones/decide-network-design#option-4).\n\nThis series discusses each gated pattern and its possible design options.\nHowever, one common design option applicable to all gated patterns is the\n[Zero Trust Distributed Architecture](/architecture/network-hybrid-multicloud#zero_trust_distributed_architecture)\nfor containerized applications with microservice architecture. This option is\npowered by\n[Cloud Service Mesh](/anthos/service-mesh),\nApigee, and\n[Apigee Adapter for Envoy](/apigee/docs/api-platform/envoy-adapter/v2.0.x/concepts)---a\nlightweight Apigee gateway deployment within a Kubernetes cluster.\nApigee Adapter for Envoy is a popular, open source edge and service proxy that's\ndesigned for cloud-first applications. This architecture controls allowed secure\nservice-to-service communications and the direction of communication at a\nservice level. Traffic communication policies can be designed, fine-tuned, and\napplied at the service level based on the selected pattern.\n\nGated patterns allow for the implementation of Cloud Next Generation Firewall Enterprise\nwith\n[intrusion prevention service (IPS)](/firewall/docs/about-intrusion-prevention)\nto perform deep packet inspection for threat prevention without any design\nor routing modifications. That inspection is subject to the specific\napplications being accessed, the communication model, and the security\nrequirements. If security requirements demand Layer 7 and deep packet inspection\nwith advanced firewalling mechanisms that surpass the capabilities of\nCloud Next Generation Firewall, you can use a centralized next generation firewall (NGFW)\n[hosted in a network virtual appliance (NVA)](/architecture/network-secure-intra-cloud-access#network_virtual_appliance).\nSeveral Google Cloud\n[security partners](/security/partners)\noffer NGFW appliances that can meet your security requirements. Integrating NVAs\nwith these gated patterns can require introducing multiple security zones within\nthe network design, each with distinct access control levels."]]
