O padrão de saída controlada e entrada controlada usa uma combinação de saída controlada e entrada controlada para cenários que exigem a utilização bidirecional de APIs selecionadas entre cargas de trabalho. As cargas de trabalho podem ser executadas no Google Cloud, em ambientes privados no local ou noutros ambientes de nuvem. Neste padrão, pode usar gateways de API, pontos finais do Private Service Connect ou balanceadores de carga para expor APIs específicas e, opcionalmente, fornecer autenticação, autorização e auditorias de chamadas de API.
A principal distinção entre este padrão e o padrão de malha reside na sua aplicação a cenários que requerem apenas a utilização da API bidirecional ou a comunicação com origens e destinos de endereços IP específicos, por exemplo, uma aplicação publicada através de um ponto final do Private Service Connect. Uma vez que a comunicação está restrita às APIs expostas ou a endereços IP específicos, as redes nos ambientes não têm de estar alinhadas no seu design. Os cenários aplicáveis comuns incluem, entre outros:
- Fusões e aquisições.
- Integrações de aplicações com parceiros.
- Integrações entre aplicações e serviços de uma organização com diferentes unidades organizacionais que gerem as suas próprias aplicações e as alojam em diferentes ambientes.
A comunicação funciona da seguinte forma:
- As cargas de trabalho que implementar no Google Cloud podem comunicar com o gateway de API (ou endereços IP de destino específicos) através de endereços IP internos. Não é possível aceder a outros sistemas implementados no ambiente de computação privado.
- Por outro lado, as cargas de trabalho que implementa noutros ambientes de computação podem comunicar com o gateway de API do lado Google Cloud(ou um endereço IP de ponto final publicado específico) através de endereços IP internos. Não é possível contactar outros sistemas implementados em Google Cloud .
Arquitetura
O diagrama seguinte mostra uma arquitetura de referência para o padrão de saída controlada e entrada controlada:
A abordagem de design no diagrama anterior tem os seguintes elementos:
- No Google Cloud lado, implementa cargas de trabalho numa VPC (ou numa VPC partilhada) sem as expor diretamente à Internet.
- A rede do ambiente Google Cloud é expandida para outros ambientes de computação. Esse ambiente pode estar no local ou noutra nuvem. Para expandir o ambiente, use um padrão de comunicação de conetividade híbrida e multinuvem adequado para facilitar a comunicação entre ambientes, para que possam usar endereços IP internos.
- Opcionalmente, ao ativar o acesso a endereços IP de destino específicos, pode usar uma VPC de trânsito para ajudar a adicionar uma camada de segurança de perímetro fora da VPC da aplicação.
- Pode usar a firewall de nova geração do Google Cloud ou os dispositivos virtuais de rede (NVAs) com firewalls de nova geração (NGFWs) na VPC de trânsito para inspecionar o tráfego e permitir ou proibir o acesso a determinadas APIs a partir de origens específicas antes de chegar à VPC da aplicação.
- As APIs devem ser acedidas através de um gateway de API ou de um equilibrador de carga para fornecer uma camada de proxy e uma abstração ou uma fachada para as APIs de serviço.
- Para aplicações consumidas como APIs, também pode usar o Private Service Connect para fornecer um endereço IP interno para a aplicação publicada.
- Todos os ambientes usam um espaço de endereço IP RFC 1918 sem sobreposição.
Uma aplicação comum deste padrão envolve a implementação de back-ends de aplicações (ou um subconjunto de back-ends de aplicações) no Google Cloud , enquanto aloja outros componentes de back-end e front-end em ambientes nas instalações ou noutras nuvens (padrão híbrido em camadas ou padrão multinuvem particionada). À medida que as aplicações evoluem e migram para a nuvem, surgem frequentemente dependências e preferências por serviços na nuvem específicos.
Por vezes, estas dependências e preferências levam à distribuição de aplicações e backends por diferentes fornecedores de nuvem. Além disso, algumas aplicações podem ser criadas com uma combinação de recursos e serviços distribuídos por ambientes nas instalações e vários ambientes na nuvem.
Para aplicações distribuídas, as capacidades de conetividade híbrida e multicloud do Cloud Load Balancing externo podem ser usadas para terminar pedidos de utilizadores e encaminhá-los para front-ends ou back-ends noutros ambientes. Este encaminhamento ocorre através de uma ligação de rede híbrida, conforme ilustrado no diagrama seguinte. Esta integração permite a distribuição gradual de componentes da aplicação em diferentes ambientes. Os pedidos do front-end para os serviços de back-end alojados no Google Cloud comunicamde forma segura através da ligação de rede híbrida estabelecida facilitada por um balanceador de carga interno (ILB no diagrama).
A utilização do Google Cloud design no diagrama anterior ajuda com o seguinte:
- Facilita a comunicação bidirecional entre Google Cloud, nas instalações e outros ambientes na nuvem através de APIs predefinidas em ambos os lados que se alinham com o modelo de comunicação deste padrão.
- Para fornecer front-ends globais para aplicações viradas para a Internet com componentes de aplicações distribuídos (front-ends ou back-ends) e para alcançar os seguintes objetivos, pode usar as capacidades avançadas de equilíbrio de carga e segurança Google Cloud distribuídas em pontos de presença (PoPs):
- Reduza as despesas de capital e simplifique as operações através de serviços geridos sem servidor.
- Otimize as ligações aos back-ends das aplicações a nível global para melhorar a velocidade e a latência.
- Google Cloud A rede entre clouds permite a comunicação entre várias clouds entre componentes de aplicações através de ligações privadas ideais.
- Coloque em cache conteúdo estático de elevada procura e melhore o desempenho das aplicações que usam o Cloud Load Balancing global, fornecendo acesso ao Cloud CDN.
- Proteja os front-ends globais das aplicações viradas para a Internet usando as capacidades do Google Cloud Armor que oferecem distribuição global de firewall de aplicação Web (WAF) e serviços de mitigação de DDoS.
- Opcionalmente, pode incorporar o Private Service Connect no seu design. Ao fazê-lo, permite o acesso privado e detalhado às APIs de serviços ou aos seus serviços publicados a partir de outros ambientes sem atravessar a Internet pública. Google Cloud
Variantes
Os padrões de arquitetura de saída restrita e entrada restrita podem ser combinados com outras abordagens para cumprir diferentes requisitos de design, ao mesmo tempo que consideram os requisitos de comunicação deste padrão. Os padrões oferecem as seguintes opções:
- Gateways de API distribuídos
- Comunicação API bidirecional através do Private Service Connect
- Comunicação bidirecional através de pontos finais e interfaces do Private Service Connect
Gateways de API distribuídos
Em cenários como o baseado no padrão de multicloud particionado, as aplicações (ou os componentes das aplicações) podem ser criadas em diferentes ambientes de nuvem, incluindo um ambiente privado no local. O requisito comum é encaminhar os pedidos do cliente para o front-end da aplicação diretamente para o ambiente onde a aplicação (ou o componente de front-end) está alojada. Este tipo de comunicação requer um equilibrador de carga local ou um gateway de API. Estas aplicações e os respetivos componentes também podem exigir capacidades específicas da plataforma de API para integração.
O diagrama seguinte ilustra como o Apigee e o Apigee Hybrid são concebidos para satisfazer esses requisitos com um gateway de API localizado em cada ambiente. A gestão da plataforma de API está centralizada no Google Cloud. Este design ajuda a aplicar medidas de controlo de acesso rigorosas em que apenas os endereços IP pré-aprovados (APIs de destino e de destino ou endereços IP do ponto final do Private Service Connect) podem comunicar entre si e os outros ambientes. Google Cloud
A lista seguinte descreve os dois caminhos de comunicação distintos no diagrama anterior que usam o gateway de API do Apigee:
- Os pedidos do cliente chegam ao frontend da aplicação diretamente no ambiente que aloja a aplicação (ou o componente de frontend).
- Os gateways de API e os proxies em cada ambiente processam os pedidos de API de clientes e
aplicações em direções diferentes em vários
ambientes.
- A funcionalidade de gateway de API no Google Cloud (Apigee) expõe os componentes da aplicação (frontend ou backend) que estão alojados no Google Cloud.
- A funcionalidade de gateway de API noutro ambiente (híbrido) expõe os componentes de frontend (ou backend) da aplicação alojados nesse ambiente.
Opcionalmente, pode considerar usar uma VPC de trânsito. Uma VPC de trânsito pode oferecer flexibilidade para separar preocupações e realizar inspeção de segurança e conetividade híbrida numa rede VPC separada. Do ponto de vista da acessibilidade do endereço IP, uma VPC de trânsito (onde a conetividade híbrida está anexada) facilita os seguintes requisitos para manter a acessibilidade ponto a ponto:
- Os endereços IP das APIs de destino têm de ser anunciados aos outros ambientes onde os clientes/requisitantes estão alojados.
- Os endereços IP dos anfitriões que precisam de comunicar com as APIs de destino têm de ser anunciados ao ambiente onde a API de destino reside, por exemplo, os endereços IP do requerente da API (o cliente). A exceção ocorre quando a comunicação é feita através de um balanceador de carga, um proxy, um ponto final do Private Service Connect ou uma instância de NAT.
Para estender a conetividade ao ambiente remoto, esta conceção usa o peering de VPC direto com a capacidade de troca de rotas do cliente. O design permite que pedidos de API específicos originários de cargas de trabalho alojadas na VPC da aplicação sejam encaminhados através da VPC de trânsito. Google Cloud Em alternativa, pode usar um ponto final do Private Service Connect na VPC da aplicação associada a um balanceador de carga com um back-end do grupo de pontos finais da rede híbrida na VPC de trânsito. Essa configuração é descrita na secção seguinte: comunicação API bidirecional através do Private Service Connect.
Comunicação API bidirecional através do Private Service Connect
Por vezes, as empresas podem não precisar de usar um gateway de API (como o Apigee) imediatamente ou podem querer adicioná-lo mais tarde. No entanto, podem existir requisitos empresariais para ativar a comunicação e a integração entre determinadas aplicações em diferentes ambientes. Por exemplo, se a sua empresa adquiriu outra empresa, pode ter de expor determinadas aplicações a essa empresa. Podem ter de expor aplicações à sua empresa. Ambas as empresas podem ter as suas próprias cargas de trabalho alojadas em ambientes diferentes (Google Cloud, no local ou noutras nuvens) e têm de evitar a sobreposição de endereços IP. Nesses casos, pode usar o Private Service Connect para facilitar a comunicação eficaz.
Para aplicações consumidas como APIs, também pode usar o Private Service Connect para fornecer um endereço privado para as aplicações publicadas, o que permite o acesso seguro na rede privada em regiões e através da conetividade híbrida. Esta abstração facilita a integração de recursos de diversas nuvens e ambientes nas instalações através de um modelo de conetividade híbrido e de várias nuvens. Também permite a montagem de aplicações em ambientes de várias nuvens e nas instalações. Isto pode satisfazer diferentes requisitos de comunicação, como a integração de aplicações seguras onde não é usado ou não está planeado usar um gateway de API.
Ao usar o Private Service Connect com o Cloud Load Balancing, conforme mostrado no diagrama seguinte, pode alcançar dois caminhos de comunicação distintos. Cada caminho é iniciado a partir de uma direção diferente para um objetivo de conetividade separado, idealmente através de chamadas API.
- Todas as considerações de design e recomendações do Private Service Connect abordadas neste guia aplicam-se a este design.
- Se for necessária uma inspeção de camada 7 adicional, pode integrar NVAs com esta conceção (na VPC de trânsito).
- Este design pode ser usado com ou sem gateways de API.
Os dois caminhos de conetividade representados no diagrama anterior representam ligações independentes e não ilustram a comunicação bidirecional de uma única ligação ou fluxo.
Comunicação bidirecional através de pontos finais e interfaces do Private Service Connect
Conforme abordado no padrão de entrada controlada, uma das opções para ativar a comunicação cliente-serviço é usar um ponto final do Private Service Connect para expor um serviço numa VPC de produção a uma VPC de consumo. Essa conetividade pode ser estendida a um ambiente nas instalações ou até mesmo a outro ambiente de fornecedor de nuvem através de uma conetividade híbrida. No entanto, em alguns cenários, o serviço alojado também pode exigir comunicação privada.
Para aceder a um determinado serviço, como obter dados de origens de dados que podem ser alojados na VPC do consumidor ou fora dela, esta comunicação privada pode ser entre a VPC da aplicação (produtor) e um ambiente remoto, como um ambiente no local.
Neste cenário, as interfaces do Private Service Connect permitem que uma instância de VM de produtor de serviços aceda à rede de um consumidor. Isto é feito através da partilha de uma interface de rede, mantendo a separação das funções de produtor e consumidor. Com esta interface de rede na VPC do consumidor, a VM da aplicação pode aceder aos recursos do consumidor como se estivessem localmente na VPC do produtor.
Uma interface do Private Service Connect é uma interface de rede associada à VPC do consumidor (trânsito). É possível alcançar destinos externos acessíveis a partir da VPC (trânsito) do consumidor à qual a interface do Private Service Connect está anexada. Por conseguinte, esta ligação pode ser estendida a um ambiente externo através de uma conetividade híbrida, como um ambiente no local, conforme ilustrado no seguinte diagrama:
Se a VPC do consumidor for uma organização ou uma entidade externa, como uma organização de terceiros, normalmente, não tem a capacidade de proteger a comunicação com a interface do Private Service Connect na VPC do consumidor. Neste cenário, pode definir políticas de segurança no SO convidado da VM da interface do Private Service Connect. Para mais informações, consulte Configure a segurança para interfaces do Private Service Connect. Em alternativa, pode considerar uma abordagem alternativa se não estiver em conformidade com a conformidade ou as normas de segurança da sua organização.
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 Hybrid como uma solução de gateway de API.
- Esta abordagem também facilita a migração da solução para um ambiente totalmente alojado, mantendo a consistência da plataforma de API (Apigee). Google Cloud
Para minimizar a latência e otimizar os custos para volumes elevados de transferências de dados de saída para os seus outros ambientes quando esses ambientes estão em configurações híbridas ou multicloud permanentes ou de longo prazo, considere o seguinte:
- Use o Cloud Interconnect ou o Cross-Cloud Interconnect.
- Para terminar as ligações de utilizadores no front-end segmentado no ambiente adequado, use o híbrido.
Quando aplicável aos seus requisitos e à arquitetura, use o adaptador do Apigee para o Envoy com uma implementação híbrida com o Kubernetes.
Antes de conceber os caminhos de conetividade e encaminhamento, primeiro tem de identificar que tráfego ou pedidos de API têm de ser direcionados para um gateway de API local ou remoto, juntamente com os ambientes de origem e destino.
Use os VPC Service Controls para proteger os Google Cloud serviços nos seus projetos e mitigar o risco de exfiltração de dados, especificando perímetros de serviço ao nível do projeto ou da rede VPC.
- Pode estender os perímetros de serviço a um ambiente híbrido através de uma VPN autorizada ou do Cloud Interconnect. Para mais informações sobre as vantagens dos perímetros de serviço, consulte a Vista geral dos VPC Service Controls.
Use as regras de firewall da nuvem virtual privada (VPC) ou as 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.
Quando usar uma interface do Private Service Connect, tem de proteger a comunicação com a interface configurando a segurança da interface do Private Service Connect.
Se uma carga de trabalho numa sub-rede privada precisar de acesso à Internet, use o Cloud NAT para evitar atribuir um endereço IP externo à carga de trabalho e expô-la à Internet pública.
- 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.