A arquitetura do padrão de entrada restrita baseia-se na exposição de APIs selecionadas de cargas de trabalho em execução no ambiente de computação privado sem as expor à Internet pública. Google Cloud Este padrão é a contrapartida do padrão de saída restrita e é adequado para cenários de híbrido na extremidade, híbrido em camadas e várias nuvens particionadas.
Tal como no padrão de saída controlada, pode facilitar esta exposição limitada através de um gateway de API ou um equilibrador de carga que sirva de fachada para cargas de trabalho ou serviços existentes. Deste modo, torna-o acessível a ambientes de computação privados, ambientes nas instalações ou noutro ambiente de nuvem, da seguinte forma:
- As cargas de trabalho que implementa no ambiente de computação privada ou noutros ambientes de nuvem podem comunicar com o gateway de API ou o balanceador de carga através de endereços IP internos. Não é possível aceder a outros sistemas implementados em Google Cloud .
- A comunicação de Google Cloud para o ambiente de computação privado ou para outros ambientes de nuvem não é permitida. O tráfego só é iniciado a partir do ambiente privado ou de outros ambientes na nuvem para as APIs em Google Cloud.
Arquitetura
O diagrama seguinte mostra uma arquitetura de referência que cumpre os requisitos do padrão de entrada restrita.
A descrição da arquitetura no diagrama anterior é a seguinte:
- No lado Google Cloud , implementa cargas de trabalho numa VPC de aplicação (ou várias VPCs).
- A rede do ambiente Google Cloud estende-se a outros ambientes de computação (nas instalações ou noutra nuvem) através da conetividade de rede híbrida ou multinuvem para facilitar a comunicação entre ambientes.
- Opcionalmente, pode usar uma VPC de trânsito para realizar o seguinte:
- Forneça camadas de segurança de perímetro adicionais para permitir o acesso a APIs específicas fora da VPC da sua aplicação.
- Encaminhe o tráfego para os endereços IP das APIs. Pode criar regras de firewall da VPC para impedir que algumas origens acedam a determinadas APIs através de um ponto final.
- Inspecione o tráfego da camada 7 na VPC de trânsito integrando um dispositivo virtual de rede (NVA).
- Aceda às APIs através de um gateway de API ou de um equilibrador de carga (proxy ou equilibrador de carga da aplicação) para fornecer uma camada de proxy e uma camada de abstração ou fachada para as APIs de serviço. Se precisar de distribuir o tráfego por várias instâncias do gateway de API, pode usar um Network Load Balancer de encaminhamento interno.
- Forneça acesso limitado e detalhado a um serviço publicado através de um ponto final do Private Service Connect usando um balanceador de carga através do Private Service Connect para expor uma aplicação ou um serviço.
- Todos os ambientes devem usar um espaço de endereço IP RFC 1918 sem sobreposição.
O diagrama seguinte ilustra a conceção deste padrão através do Apigee como plataforma de API.
No diagrama anterior, a utilização do Apigee como plataforma de API oferece as seguintes funcionalidades e capacidades para ativar o padrão de entrada controlada:
- Funcionalidade de gateway ou proxy
- Capacidades de segurança
- Limitação de velocidade
- Google Analytics
No design:
- A conetividade de rede no sentido ascendente (para tráfego proveniente de outros ambientes) passa por um ponto final do Private Service Connect na VPC da sua aplicação que está associado à VPC do Apigee.
- Na VPC da aplicação, é usado um balanceador de carga interno para expor as APIs da aplicação através de um ponto final do Private Service Connect apresentado na VPC do Apigee. Para mais informações, consulte o artigo Arquitetura com o peering de VPC desativado.
Configure regras de firewall e filtragem de tráfego na VPC da aplicação. Ao fazê-lo, concede um acesso detalhado e controlado. Também ajuda a impedir que os sistemas alcancem diretamente as suas aplicações sem passar pelo ponto final do Private Service Connect e pela gateway de API.
Além disso, pode restringir o anúncio da sub-rede de endereços IP internos da carga de trabalho de back-end na VPC da aplicação à rede no local para evitar a acessibilidade direta sem passar pelo ponto final do Private Service Connect e pela gateway de API.
Determinados requisitos de segurança podem exigir a inspeção de segurança do perímetro fora da VPC da aplicação, incluindo o tráfego de conetividade híbrida. Nestes casos, pode incorporar uma VPC de trânsito para implementar camadas de segurança adicionais. Estas camadas, como NVAs de firewalls de próxima geração (NGFWs) com várias interfaces de rede ou o firewall de próxima geração do Google Cloud Enterprise com serviço de prevenção de intrusões (IPS), realizam a inspeção profunda de pacotes fora da VPC da sua aplicação, conforme ilustrado no diagrama seguinte:
Conforme ilustrado no diagrama anterior:
- A conetividade de rede no sentido ascendente (para tráfego proveniente de outros ambientes) passa por uma VPC de trânsito separada em direção ao ponto final do Private Service Connect na VPC de trânsito associada à VPC do Apigee.
- Na VPC da aplicação, é usado um balanceador de carga interno (ILB no diagrama) para expor a aplicação através de um ponto final do Private Service Connect na VPC do Apigee.
Pode aprovisionar vários pontos finais na mesma rede VPC, conforme mostrado no diagrama seguinte. Para abranger diferentes exemplos de utilização, pode controlar os diferentes caminhos de rede possíveis através do Cloud Router e das regras de firewall da VPC. Por exemplo, se estiver a ligar a sua rede no local a Google Cloud através de várias ligações de rede híbrida, pode enviar algum tráfego do local para APIs Google específicas ou serviços publicados através de uma ligação e o resto através de outra ligação. Além disso, pode usar o acesso global do Private Service Connect para fornecer opções de comutação por falha.
Variantes
O padrão de arquitetura de entrada restrita pode ser combinado com outras abordagens para cumprir diferentes requisitos de design, ao mesmo tempo que considera os requisitos de comunicação do padrão. O padrão oferece as seguintes opções:
Exponha back-ends de aplicações a outros ambientes através do Private Service Connect
Use uma arquitetura de hub e spoke para expor back-ends de aplicações a outros ambientes
Aceda às APIs Google a partir de outros ambientes
Para cenários que requerem acesso a serviços Google, como o Cloud Storage ou o BigQuery, sem enviar tráfego através da Internet pública, o Private Service Connect oferece uma solução. Conforme mostrado no diagrama seguinte, permite a acessibilidade às APIs Google suportadas e aos serviços (incluindo o Google Maps, o Google Ads e oGoogle Cloud) a partir de ambientes no local ou de outras nuvens através de uma ligação de rede híbrida que usa o endereço IP do ponto final do Private Service Connect. Para mais informações sobre o acesso às APIs Google através de pontos finais do Private Service Connect, consulte o artigo Acerca do acesso às APIs Google através de pontos finais.
No diagrama anterior, a sua rede no local tem de estar ligada à rede VPC de trânsito (consumidor) através de túneis do Cloud VPN ou de uma ligação VLAN do Cloud Interconnect.
As APIs Google podem ser acedidas através de pontos finais ou servidores de back-end. Os pontos finais permitem segmentar um pacote de APIs Google. Os backends permitem segmentar uma API Google regional específica.
Exponha back-ends de aplicações a outros ambientes através do Private Service Connect
Em cenários específicos, conforme realçado pelo padrão híbrido hierárquico, pode ter de implementar back-ends em Google Cloud , ao mesmo tempo que mantém os front-ends em ambientes de computação privados. Embora seja menos comum, esta abordagem é aplicável quando se lida com frontends pesados e monolíticos que podem depender de componentes antigos. Em alternativa, mais frequentemente, quando gere aplicações distribuídas em vários ambientes, incluindo no local e noutras nuvens, que requerem conetividade a back-ends alojados na Google Cloud nuvem híbrida.
Nesta arquitetura, pode usar um gateway de API local ou um equilibrador de carga no ambiente privado nas instalações ou noutros ambientes de nuvem para expor diretamente o frontend da aplicação à Internet pública. A utilização do Private Service Connect no Google Cloud facilita a conetividade privada aos back-ends expostos através de um ponto final do Private Service Connect, idealmente através de APIs predefinidas, conforme ilustrado no diagrama seguinte:
O design no diagrama anterior usa uma implementação do Apigee Hybrid que consiste num plano de gestão no Google Cloud e num plano de tempo de execução alojado no seu outro ambiente. Pode instalar e gerir o plano de execução numa gateway de API distribuída numa das plataformas Kubernetes suportadas no seu ambiente no local ou noutros ambientes de nuvem. Com base nos seus requisitos para cargas de trabalho distribuídas em vários ambientes, pode usar o Apigee no Google Cloud com o Apigee Hybrid. Google Cloud Google Cloud Para mais informações, consulte o artigo Gateways de API distribuídos.
Use uma arquitetura de hub and spoke para expor backends de aplicações a outros ambientes
A exposição de APIs de backends de aplicações alojados em Google Cloud em diferentes redes VPC pode ser necessária em determinados cenários. Conforme ilustrado no diagrama seguinte, uma VPC de hub serve como um ponto central de interligação para as várias VPCs (raios), permitindo a comunicação segura através da conetividade híbrida privada. Opcionalmente, podem ser usadas capacidades de gateway de API local noutros ambientes, como o Apigee Hybrid, para terminar pedidos de clientes localmente onde o front-end da aplicação está alojado.
Conforme ilustrado no diagrama anterior:
- Para oferecer capacidades de inspeção da camada 7 da NGFW adicionais, a NVA com capacidades de NGFW é integrada opcionalmente no design. Pode precisar destas capacidades para agir em conformidade com requisitos de segurança específicos e as normas da política de segurança da sua organização.
Este design pressupõe que as VPCs spoke não requerem comunicação direta de VPC para VPC.
- Se for necessária a comunicação entre raios, pode usar o NVA para facilitar essa comunicação.
- Se tiver diferentes back-ends em diferentes VPCs, pode usar o Private Service Connect para expor estes back-ends à VPC do Apigee.
- Se o intercâmbio de redes da VPC for usado para a conetividade a montante e a jusante entre as VPCs spoke e a VPC hub, tem de considerar a limitação de transitividade da rede da VPC através do intercâmbio de redes da VPC. Para ultrapassar esta limitação, pode usar qualquer uma das seguintes opções:
- Para interligar as VPCs, use uma NVA.
- Quando aplicável, considere o modelo do Private Service Connect.
- Para estabelecer a conetividade entre a VPC do Apigee e os back-ends localizados noutrosGoogle Cloud projetos na mesma organização sem componentes de rede adicionais, use a VPC partilhada.
Se forem necessárias NVAs para a inspeção de tráfego, incluindo o tráfego dos seus outros ambientes, a conetividade híbrida a ambientes nas instalações ou outros ambientes na nuvem deve ser terminada na VPC de trânsito híbrida.
Se o design não incluir a NVA, pode terminar a conetividade híbrida na VPC do hub.
Se forem necessárias determinadas funcionalidades de balanceamento de carga ou capacidades de segurança, como adicionar a proteção DDoS ou o WAF do Google Cloud Armor, pode implementar opcionalmente um balanceador de carga de aplicações externo no perímetro através de uma VPC externa antes de encaminhar pedidos de clientes externos para os back-ends.
Práticas recomendadas
- Para situações em que os pedidos de clientes da Internet têm de ser recebidos localmente por um front-end alojado num ambiente privado no local ou noutro ambiente de nuvem, considere usar o Apigee Hybrid como uma solução de gateway de API. Esta abordagem também facilita uma migração simples da solução para um ambiente totalmente Google Cloudalojado, mantendo a consistência da plataforma de API (Apigee).
- Use o Apigee Adapter para Envoy com uma arquitetura de implementação híbrida do Apigee com o Kubernetes, quando aplicável aos seus requisitos e à arquitetura.
- A conceção de VPCs e projetos no Google Cloud deve seguir os requisitos da hierarquia de recursos e do modelo de comunicação segura, conforme descrito neste guia.
- A incorporação de uma VPC de trânsito neste design oferece a flexibilidade de aprovisionar medidas de segurança de perímetro adicionais e conectividade híbrida fora da VPC da carga de trabalho.
- Use o Private Service Connect para aceder às APIs e aos serviços Google a partir de ambientes no local ou de outros ambientes na nuvem através do endereço IP interno do ponto final numa rede de conetividade híbrida. Para mais informações, consulte o artigo Aceda ao ponto final a partir de anfitriões no local.
- Para ajudar a proteger os serviços nos seus projetos e ajudar a mitigar o risco de exfiltração de dados, use os VPC Service Controls para especificar perímetros de serviço ao nível do projeto ou da rede VPC. Google Cloud
- Quando necessário, pode estender os perímetros de serviço a um ambiente híbrido através de uma VPN ou do Cloud Interconnect. Para mais informações sobre as vantagens dos perímetros de serviço, consulte a vista geral do VPC Service Controls.
- Use regras de firewall da VPC ou políticas de firewall para controlar o acesso ao nível da rede aos recursos do Private Service Connect através do ponto final do Private Service Connect. Por exemplo, as regras de firewall de saída na VPC da aplicação (consumidor) podem restringir o acesso das instâncias de VM ao endereço IP ou à sub-rede dos seus pontos finais. Para mais informações sobre as regras de firewall da VPC em geral, consulte o artigo Regras de firewall da VPC.
- Ao criar uma solução que inclua NVAs, é importante considerar a elevada disponibilidade (HA) das NVAs para evitar um único ponto de falha que possa bloquear toda a comunicação. Siga as orientações de implementação e design de HA e redundância fornecidas pelo fornecedor da NVA.
- Para reforçar a segurança do perímetro e proteger o gateway de API implementado no ambiente respetivo, pode implementar opcionalmente mecanismos de equilíbrio de carga e firewall de aplicações Web no seu outro ambiente de computação (híbrido ou outra nuvem). Implemente estas opções na rede de perímetro que está diretamente ligada à Internet.
- Se as instâncias precisarem de acesso à Internet, use o Cloud NAT na VPC da aplicação para permitir que as cargas de trabalho acedam à Internet. Ao fazê-lo, pode evitar atribuir instâncias de VMs com endereços IP públicos externos em sistemas implementados atrás de um gateway de API ou um equilibrador de carga.
- Para o tráfego Web de saída, use o Secure Web Proxy. O proxy oferece várias vantagens.
- Reveja as práticas recomendadas gerais para padrões de rede híbridos e multicloud.