A arquitetura do padrão de entrada controlada é baseada na exposição de dados APIs de cargas de trabalho em execução no Google Cloud para o ambiente de computação particular sem expô-los à Internet pública. Esse padrão é a contraparte as padrão de saída controlada e é adequada para híbrido de borda, híbrido em camadas, e multicloud particionada para cenários de direção reais.
Assim como no padrão de saída controlada, é possível facilitar essa exposição limitada. por um gateway de API ou balanceador de carga funciona como fachada para cargas de trabalho ou serviços atuais. Ao fazer isso, eles ficam acessíveis para aplicativos de computação em nuvem, ambientes no local ou em outro ambiente de nuvem, da seguinte forma:
- as cargas de trabalho implantadas no ambiente de computação particular ou em outros ambientes de nuvem são capazes de se comunicar com o gateway de API ou carregar do balanceador de carga usando endereços IP internos. Outros sistemas implantados em Não é possível acessar o Google Cloud.
- Comunicação do Google Cloud com a computação particular ou para outros ambientes de nuvem. O tráfego é apenas iniciadas do ambiente privado ou de outros ambientes de nuvem para o APIs no Google Cloud.
Arquitetura
O diagrama a seguir mostra uma arquitetura de referência que atende ao do padrão de entrada controlado.
A descrição da arquitetura no diagrama anterior é a seguinte:
- No lado do Google Cloud, você implanta cargas de trabalho em um VPC do aplicativo (ou várias).
- A rede do ambiente do Google Cloud se estende a outras instâncias ambientes (no local ou em outra nuvem) usando modelos de várias nuvens para facilitar a comunicação entre do Google Cloud.
- Também é possível usar uma VPC de trânsito para fazer o seguinte:
- Oferecer camadas de segurança de perímetro extras para permitir acesso fora da VPC do seu aplicativo.
- Encaminhar o tráfego para os endereços IP das APIs. Você pode criar Regras de firewall da VPC para impedir que algumas origens acessem determinadas APIs por um endpoint.
- Inspecione o tráfego da camada 7 na VPC de trânsito integrando um o dispositivo virtual de rede (NVA, na sigla em inglês).
- Acessar as APIs por meio de um gateway de API ou balanceador de carga (proxy ou balanceador de carga de aplicativo) para fornecer uma camada de proxy e uma abstração ou fachada das suas APIs de serviço. Se você precisar distribuir o tráfego em várias instâncias de gateway de API, use um Balanceador de carga de rede de passagem interna.
- fornecem acesso limitado e refinado a um serviço por meio de um endpoint do Private Service Connect usando um balanceador de carga pelo Private Service Connect para expor um aplicativo ou serviço.
- Todos os ambientes devem usar um espaço de endereços IP RFC 1918 sem sobreposição.
O diagrama a seguir ilustra o design desse padrão usando Apigee como a plataforma da API.
No diagrama anterior, usar a Apigee como plataforma de API mostra as os seguintes recursos para permitir o padrão de entrada controlada:
- Funcionalidade de gateway ou proxy
- Recursos de segurança
- Limitação de taxa
- Análise
No design:
- A conectividade de rede no sentido norte (para o tráfego proveniente de outros ambientes) passa por uma instância do Private Service Connect endpoint na VPC do seu aplicativo que é associados à VPC da Apigee.
- Na VPC do aplicativo, um balanceador de carga interno é usado para expor as APIs de aplicativo por meio de um endpoint do Private Service Connect apresentados na VPC da Apigee. Para mais informações, consulte Arquitetura com o peering de VPC desativado.
Configurar regras de firewall e filtragem de tráfego na VPC do aplicativo. Assim, você tem acesso controlado e refinado. Isso também ajuda a parar os sistemas cheguem aos aplicativos sem passar pelo no endpoint do Private Service Connect e no gateway de API.
Além disso, é possível restringir a divulgação do endereço IP encaminhar a sub-rede da carga de trabalho de back-end na VPC do aplicativo ao rede no local para evitar a acessibilidade direta sem passar usando o endpoint do Private Service Connect e a API gateway de gateway de borda.
Certos requisitos de segurança podem exigir inspeção de segurança de perímetro fora da VPC do aplicativo, incluindo o tráfego de conectividade híbrida. Em tal casos, é possível incorporar uma VPC de trânsito para implementar mais medidas camadas. Essas camadas, como NVAs com firewalls de próxima geração (NGFWs, na sigla em inglês) com várias interfaces de rede, ou Cloud Next Generation Firewall Enterprise serviço de prevenção de intrusões (IPS), realize uma inspeção profunda de pacotes fora da sua VPC do aplicativo, conforme ilustrado no diagrama a seguir:
Conforme ilustrado no diagrama anterior:
- A conectividade de rede no sentido norte (para o tráfego proveniente de outros ambientes) passa por uma VPC de trânsito separada Endpoint do Private Service Connect na VPC de trânsito associada à VPC da Apigee.
- Na VPC do aplicativo, um balanceador de carga interno (ILB no diagrama) é usada para expor o aplicativo por uma Endpoint do Private Service Connect na Apigee VPC.
É possível provisionar vários endpoints na mesma rede VPC, como mostrado no no diagrama a seguir. Para abordar diferentes casos de uso, é possível controlar os diferentes caminhos de rede possíveis com o Cloud Router e às regras de firewall da VPC. Por exemplo, se você conectar uma rede no local no Google Cloud usando várias conexões de rede híbrida, enviar algum tráfego do local para APIs ou serviços publicados específicos do Google em uma conexão e o restante em outra. Além disso, é possível usar Acesso global ao Private Service Connect para fornecer opções de failover.
Variações
O padrão de arquitetura de entrada controlada pode ser combinado com outras abordagens atender a diferentes requisitos de design, mas sem deixar de considerar a comunicação do padrão. O padrão oferece as seguintes opções:
Exponha back-ends de aplicativos a outros ambientes usando o Private Service Connect
Usar uma arquitetura hub e spoke para expor back-ends de aplicativos a outros ambientes
Acessar as APIs do Google em outros ambientes
Para cenários que exigem acesso a serviços do Google, como Cloud Storage ou o BigQuery sem enviar tráfego pela Internet pública, O Private Service Connect oferece uma solução. Conforme no diagrama a seguir, permite a acessibilidade ao APIs do Google compatíveis e serviços (incluindo Google Maps, Google Ads e Google Cloud) de ambientes locais ou outros ambientes de nuvem por uma conexão de rede híbrida usando o endereço IP do endpoint do Private Service Connect. Para mais informações sobre acessar as APIs do Google pelos endpoints do Private Service Connect ver Sobre o acesso às APIs do Google por endpoints
No diagrama anterior, sua rede local precisa estar conectada à rede VPC de trânsito (consumidor) usando túneis do Cloud VPN ou um Anexo da VLAN do Cloud Interconnect.
As APIs do Google podem ser acessadas usando endpoints ou back-ends. Com os endpoints, você segmenta um pacote de APIs do Google. Os back-ends permitem segmentar uma API regional do Google.
Expor back-ends de aplicativos a outros ambientes usando o Private Service Connect
Em cenários específicos, como destacado pelo padrão híbrido em camadas, é possível implantar back-ends no Google Cloud e manter os front-ends em em ambientes computacionais particulares. Embora menos comum, essa abordagem ao lidar com front-ends monolíticos e pesados que dependem de recursos componentes. Ou, mais comumente, ao gerenciar aplicativos distribuídos em vários ambientes, inclusive ambientes locais e outras nuvens, a conectividade com back-ends hospedados no Google Cloud em uma rede híbrida.
Nessa arquitetura, é possível usar um gateway de API local ou um balanceador de carga no no local particular ou outros ambientes de nuvem para expor diretamente o front-end do aplicativo para a Internet pública. Usando O Private Service Connect no Google Cloud facilita a conectividade com os back-ends que são expostos por meio de uma endpoint do Private Service Connect, de preferência com APIs predefinidas, conforme ilustrado no diagrama a seguir:
O design no diagrama anterior usa uma Apigee híbrida que consiste em um plano de gerenciamento no Google Cloud e um ambiente de execução hospedado no outro ambiente. Instale e gerencie o ambiente de execução em um gateway de API distribuído em um dos locais com Plataformas do Kubernetes no ambiente local ou em outros ambientes de nuvem. Com base em suas para cargas de trabalho distribuídas no Google Cloud e em outros ambientes, é possível usar a Apigee no Google Cloud com a Apigee híbrida. Para mais informações, consulte Gateways de API distribuídos:
Usar uma arquitetura de hub e spoke para expor back-ends de aplicativos a outros ambientes
Como expor APIs de back-ends de aplicativos hospedados no Google Cloud diferentes redes VPC podem ser necessárias em determinados cenários. Conforme ilustrado em no diagrama a seguir, uma VPC hub serve como ponto central de interconexão para as várias VPCs (spokes), permitindo uma comunicação segura por e conectividade. Opcionalmente, recursos de gateway de API local em outros ambientes, como Apigee híbrida pode ser usada para encerrar solicitações de clientes localmente onde o front-end do aplicativo está hospedada.
Conforme ilustrado no diagrama anterior:
- Para fornecer capacidades de inspeção de NGFW adicionais na camada 7, o NVA com Os recursos de NGFW têm a opção de ser integrados ao design. Você pode exigem que essas habilidades obedeçam a requisitos de segurança e os padrões de políticas de segurança da sua organização.
O modelo pressupõe que as VPCs spoke não exigem VPC direta para VPC da comunicação entre serviços.
- Se a comunicação spoke-to-spoke for necessária, use a função NVA para facilitar essa comunicação.
- Se você tiver back-ends diferentes em VPCs diferentes, será possível usar Private Service Connect para expor esses back-ends à VPC da Apigee.
- Se o peering de VPC for usado nos sentidos norte e sul
entre as VPCs spoke e a VPC hub, precisa considerar
limitação de transitividade
da rede VPC sobre peering de VPC. Para superar essa limitação, você
pode usar qualquer uma das seguintes opções:
- Para interconectar as VPCs, use um NVA (em inglês).
- Quando aplicável, use o Private Service Connect modelo do PyTorch.
- Para estabelecer a conectividade entre as a VPC da Apigee e os back-ends que estão localizados em outras projetos do Google Cloud na mesma organização, outros componentes de rede, use VPC compartilhada:
Se os NVAs forem necessários para a inspeção de tráfego, incluindo o tráfego da sua em outros ambientes, ou seja, a conectividade híbrida com ambientes devem ser encerrados na VPC de trânsito híbrido.
Se o design não incluir o NVA, encerre o ambiente e conectividade na VPC do hub.
Se certas funcionalidades de balanceamento de carga ou recursos de segurança estiverem necessários, como adicionar a proteção contra DDoS do Google Cloud Armor, ou WAF, um balanceador de carga de aplicativo externo no perímetro pode ser implantado por um antes de rotear solicitações de clientes externos para os back-ends.
Práticas recomendadas
- Para situações em que as solicitações de clientes da Internet precisam ser recebidos localmente por um front-end hospedado em uma rede local de nuvem híbrida, use a Apigee híbrida como API de gateway de borda. Essa abordagem também facilita a migração a solução para um ambiente completamente hospedado no Google Cloud e, ao mesmo tempo, e manter a consistência da plataforma de API (Apigee).
- Use o adaptador da Apigee para Envoy com um Implantação da Apigee híbrida com o Kubernetes arquitetura, quando aplicável aos seus requisitos e à arquitetura.
- O design de VPCs e projetos no Google Cloud deve seguir os a hierarquia de recursos e aos requisitos do modelo de comunicação seguro, descritas neste guia.
- A incorporação de uma VPC de trânsito nesse design oferece a flexibilidade de provisionar mais medidas de segurança de perímetro e conectividade híbrida fora da VPC de carga de trabalho.
- Usar o Private Service Connect para acessar as APIs e e serviços em ambientes locais ou em outros ambientes de nuvem usando o endereço IP interno o endpoint em uma rede de conectividade híbrida. Para mais informações, consulte Acessar o endpoint de hosts locais.
- Ajudar a proteger os serviços do Google Cloud nos projetos e auxiliar
mitigar o risco de exfiltração de dados, usar o VPC Service Controls para especificar
perímetros de serviço no nível do projeto ou da rede VPC.
- Quando necessário, é possível estender perímetros de serviço para um ambiente híbrido usando uma VPN ou o Cloud Interconnect. Para mais informações sobre os benefícios dos perímetros de serviço, consulte Visão geral do VPC Service Controls.
- Usar Regras de firewall da VPC ou políticas de firewall para controlar o acesso no nível da rede aos recursos do Private Service Connect usando o endpoint do Private Service Connect. Por exemplo: regras de firewall de saída na VPC do aplicativo (consumidor) pode restringir o acesso das instâncias de VM o endereço IP ou a sub-rede dos endpoints. Para mais informações sobre regras de firewall da VPC em geral, consulte Regras de firewall da VPC.
- Ao projetar uma solução que inclua NVAs, é importante considerar a alta disponibilidade (HA) dos NVAs para evitar um ponto único de falha que possam bloquear toda a comunicação. Siga o design de alta disponibilidade e redundância as orientações de implementação fornecidas pelo fornecedor do NVA. Para mais informações, sobre alcançar alta disponibilidade entre appliances virtuais, consulte a Seção de opções de arquitetura dos dispositivos de rede centralizados no Google Cloud.
- Para reforçar a segurança do perímetro e proteger seu gateway de API implantados no respectivo ambiente, é possível implementar o balanceamento de balanceamento de carga e de aplicativos da Web nos outros sistemas (ambiente híbrido ou outra nuvem). Implemente essas opções no do perímetro de serviço diretamente conectada à Internet.
- Se as instâncias exigirem acesso à Internet, use Cloud NAT na VPC do aplicativo para que as cargas de trabalho acessem a Internet. Ao fazer isso evita a atribuição de instâncias de VM com endereços IP públicos externos implantados por trás de um gateway de API ou balanceador de carga.
Para tráfego de saída da Web, use Proxy seguro da Web. O proxy oferece vários benefícios.
Consulte a práticas recomendadas gerais para padrões de rede híbridos e multicloud.