A arquitetura do padrão de rede de saída restrita baseia-se na exposição de APIs selecionadas do ambiente nas instalações ou de outro ambiente na nuvem a cargas de trabalho implementadas no Google Cloud. Faz isso sem os expor diretamente à Internet pública a partir de um ambiente nas instalações ou de outros ambientes na nuvem. Pode facilitar esta exposição limitada através de um gateway ou um proxy de API, ou um equilibrador de carga que funcione como uma fachada para cargas de trabalho existentes. Pode implementar a funcionalidade de gateway de API num segmento de rede de perímetro isolado, como uma rede de perímetro.
O padrão de rede de saída controlada aplica-se principalmente (mas não se limita) a padrões de arquitetura de aplicações hierárquicas e padrões de arquitetura de aplicações particionadas. Quando implementa cargas de trabalho de back-end numa rede interna, a rede de saída restrita ajuda a manter um nível de segurança mais elevado no seu ambiente de computação no local. O padrão requer que associe ambientes de computação de uma forma que cumpra os seguintes requisitos de comunicação:
- As cargas de trabalho que implementa no Google Cloud podem comunicar com o gateway de API ou o balanceador de carga (ou um ponto final do Private Service Connect) que expõe a aplicação através de endereços IP internos.
- Não é possível aceder a outros sistemas no ambiente de computação privada diretamente a partir de Google Cloud.
- A comunicação do ambiente de computação privado para quaisquer cargas de trabalho implementadas em Google Cloud não é permitida.
- O tráfego para as APIs privadas noutros ambientes só é iniciado a partir do ambiente Google Cloud .
O foco deste guia é em ambientes híbridos e multicloud ligados através de uma rede híbrida privada. Se os requisitos de segurança da sua organização o permitirem, é possível aceder diretamente às chamadas API para APIs de destino remotas com endereços IP públicos através da Internet. No entanto, tem de considerar os seguintes mecanismos de segurança:
- API OAuth 2.0 com Transport Layer Security (TLS).
- Limitação de velocidade.
- Políticas de proteção contra ameaças.
- TLS mútuo configurado para o back-end da sua camada de API.
- Filtragem da lista de autorizações de endereços IP configurada para permitir apenas a comunicação com origens e destinos de API predefinidos de ambos os lados.
Para proteger um proxy de API, considere estes outros aspetos de segurança. Para mais informações, consulte Práticas recomendadas para proteger as suas aplicações e APIs com o Apigee.
Arquitetura
O diagrama seguinte mostra uma arquitetura de referência que suporta os requisitos de comunicação indicados na secção anterior:
Os dados fluem através do diagrama anterior da seguinte forma:
- No Google Cloud lado, pode implementar cargas de trabalho em nuvens privadas virtuais (VPCs). As VPCs podem ser únicas ou múltiplas (partilhadas ou não partilhadas). A implementação deve estar alinhada com os projetos e a estrutura hierárquica de recursos da sua organização.
- As redes VPC do ambiente Google Cloud são expandidas para os outros ambientes de computação. Os ambientes podem estar nas instalações ou noutra nuvem. Para facilitar a comunicação entre ambientes através de endereços IP internos, use uma conetividade de rede híbrida e multicloud adequada.
Para limitar o tráfego que tem origem em endereços IP de VPC específicos e se destina a gateways remotos ou equilibradores de carga, use a filtragem da lista de autorizações de endereços IP. O tráfego de retorno destas ligações é permitido quando usa regras de firewall com estado. Pode usar qualquer combinação das seguintes capacidades para proteger e limitar as comunicações apenas aos endereços IP de origem e de destino permitidos:
Dispositivo virtual de rede (NVA) com capacidades de inspeção de firewall de próxima geração (NGFW) que são colocadas no caminho da rede.
Firewall de nova geração do Google Cloud Enterprise com serviço de prevenção de intrusões (IPS) para implementar a inspeção profunda de pacotes para prevenção de ameaças.
Todos os ambientes partilham um espaço de endereço IP RFC 1918 sem sobreposição.
Variantes
O padrão de arquitetura de saída controlada pode ser combinado com outras abordagens para cumprir diferentes requisitos de design que ainda consideram os requisitos de comunicação deste padrão. O padrão oferece as seguintes opções:
- Use Google Cloud o gateway de API e o frontend global
- Exponha serviços remotos através do Private Service Connect
Use Google Cloud gateway de API e frontend global
Com esta abordagem de design, a exposição e a gestão das APIs residem em Google Cloud. Conforme mostrado no diagrama anterior, pode fazê-lo através da implementação do Apigee como plataforma de API. A decisão de implementar um gateway de API ou um equilibrador de carga no ambiente remoto depende das suas necessidades específicas e da configuração atual. O Apigee oferece duas opções para o aprovisionamento da conetividade:
- Com o intercâmbio de VPCs
- Sem intercâmbio de VPC
Google Cloud As capacidades de front-end globais, como o Cloud Load Balancing, o Cloud CDN (quando acedido através do Cloud Interconnect) e o Cross-Cloud Interconnect, melhoram a velocidade com que os utilizadores podem aceder a aplicações com back-ends alojados nos seus ambientes nas instalações e noutros ambientes na nuvem.
A otimização das velocidades de fornecimento de conteúdo é alcançada através do fornecimento dessas aplicações a partir de Google Cloud pontos de presença (PoP). Google Cloud Os PoPs estão presentes em mais de 180 trocas de Internet e em mais de 160 instalações de interconexão em todo o mundo.
Para ver como os PoPs ajudam a fornecer APIs de elevado desempenho quando usa o Apigee com a CDN da Google Cloud para realizar o seguinte, veja o vídeo Fornecer APIs de elevado desempenho com o Apigee e a CDN da Google Cloud no YouTube:
- Reduzir a latência.
- Alojamento de APIs a nível global.
- Aumente a disponibilidade para o pico de tráfego.
O exemplo de design ilustrado no diagrama anterior baseia-se no Private Service Connect sem intercâmbio de VPC.
A rede de saída neste design é estabelecida através do seguinte:
- Um balanceador de carga (LB no diagrama), onde os pedidos do cliente terminam, processa o tráfego e, em seguida, encaminha-o para um back-end do Private Service Connect.
- Um back-end do Private Service Connect permite que um balanceador de carga envie pedidos de clientes através de uma ligação do Private Service Connect associada a uma associação do serviço do produtor ao serviço publicado (instância de tempo de execução do Apigee) através de grupos de pontos finais da rede (NEGs) do Private Service Connect. Google Cloud
A rede de saída é estabelecida através do seguinte:
- Um ponto final do Private Service Connect que faz referência a uma associação de serviço associada a um balanceador de carga interno (ILB no diagrama) na VPC do cliente.
O ILB é implementado com grupos de pontos finais de rede de conetividade híbrida (NEGs de conetividade híbrida).
Os serviços híbridos são acedidos através do NEG de conetividade híbrida através de uma conetividade de rede híbrida, como uma VPN ou o Cloud Interconnect.
Para mais informações, consulte os artigos Configure um balanceador de carga de rede de proxy interno regional com conetividade híbrida e Padrões de implementação do Private Service Connect.
Exponha serviços remotos através do Private Service Connect
Use a opção Private Service Connect para expor serviços remotos nos seguintes cenários:
- Não está a usar uma plataforma de API ou quer evitar ligar toda a sua rede VPC diretamente a um ambiente externo pelos seguintes motivos:
- Tem restrições de segurança ou requisitos de conformidade.
- Tem uma sobreposição de intervalo de endereços IP, como num cenário de fusão e aquisição.
- Para ativar comunicações unidirecionais seguras entre clientes, aplicações e serviços nos ambientes, mesmo quando tem um prazo curto.
- Pode ter de fornecer conetividade a várias VPCs de consumidor através de uma VPC de produtor de serviços (VPC de trânsito) para oferecer modelos de serviços multi-inquilinos ou de inquilino único altamente escaláveis, para alcançar serviços publicados noutros ambientes.
A utilização do Private Service Connect para aplicações consumidas como APIs fornece um endereço IP interno 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. Pode acelerar a integração de aplicações e expor aplicações em segurança que residam num ambiente no local ou noutro ambiente de nuvem através do Private Service Connect para publicar o serviço com acesso detalhado. Neste caso, pode usar a seguinte opção:
- Uma associação de serviço que faz referência a um
Network Load Balancer de proxy interno regional
ou a um
Application Load Balancer interno.
- O equilibrador de carga usa um grupo de pontos finais de rede híbrida (NEG de conetividade híbrida) numa VPC de produtor que atua neste design como uma VPC de trânsito.
No diagrama anterior, as cargas de trabalho na rede VPC da sua aplicação podem alcançar os serviços híbridos em execução no seu ambiente nas instalações ou noutros ambientes na nuvem através do ponto final do Private Service Connect, conforme ilustrado no diagrama seguinte. Esta opção de design para comunicações unidirecionais oferece uma opção alternativa ao intercâmbio com uma VPC de trânsito.
Como parte do design no diagrama anterior, vários front-ends, back-ends ou pontos finais podem ligar-se à mesma associação de serviços, o que permite que várias redes VPC ou vários consumidores acedam ao mesmo serviço. Conforme ilustrado no diagrama seguinte, pode tornar a aplicação acessível a várias VPCs. Esta acessibilidade pode ajudar em cenários de serviços multiinquilinos em que o seu serviço é consumido por várias VPCs de consumidores, mesmo que os respetivos intervalos de endereços IP se sobreponham.
A sobreposição de endereços IP é um dos problemas mais comuns ao integrar aplicações que residem em ambientes diferentes. A ligação do Private Service Connect no diagrama seguinte ajuda a evitar o problema de sobreposição de endereços IP. Isto é feito sem necessidade de aprovisionamento nem gestão de componentes de rede adicionais, como o Cloud NAT ou uma NVA, para realizar a tradução de endereços IP. Para ver um exemplo de configuração, consulte o artigo Publique um serviço híbrido através do Private Service Connect.
O design tem as seguintes vantagens:
- Evita potenciais dependências de escalabilidade partilhadas e capacidade de gestão complexa em grande escala.
- Melhora a segurança através do controlo detalhado da conetividade.
- Reduz a coordenação de endereços IP entre o produtor e o consumidor do serviço e o ambiente externo remoto.
A abordagem de design no diagrama anterior pode ser expandida em fases posteriores para integrar o Apigee como a plataforma de API através das opções de design de rede abordadas anteriormente, incluindo a opção Private Service Connect.
Pode tornar o ponto final do Private Service Connect acessível a partir de outras regiões através do acesso global do Private Service Connect.
O cliente que se liga ao ponto final do Private Service Connect pode estar na mesma região que o ponto final ou numa região diferente. Esta abordagem pode ser usada para oferecer alta disponibilidade em serviços alojados em várias regiões ou para aceder a serviços disponíveis numa única região a partir de outras regiões. Quando um ponto final do Private Service Connect é acedido por recursos alojados noutras regiões, são aplicadas cobranças de saída inter-regionais ao tráfego destinado a pontos finais com acesso global.
Práticas recomendadas
- Considerar o
Apigee
e o Apigee Hybrid como a sua solução de plataforma de API oferece
várias vantagens. Fornece uma camada de proxy e uma abstração ou fachada para as APIs de serviços de back-end combinadas com capacidades de segurança, limitação de taxas, quotas e estatísticas.
- Use o Apigee Adapter for Envoy com uma arquitetura de implementação do Apigee Hybrid com o Kubernetes, quando aplicável aos seus requisitos e à arquitetura.
- As VPCs e a conceção do projeto Google Cloud devem ser orientadas pela sua hierarquia de recursos e pelos requisitos do modelo de comunicação segura.
- Quando são usadas APIs com gateways de API, também deve usar uma lista de autorizações de endereços IP. Uma lista de autorizações limita as comunicações aos endereços IP específicos de origens e destinos dos consumidores de API e gateways de API que podem estar alojados em ambientes diferentes.
- Use regras de firewall da VPC ou políticas de firewall para controlar o acesso aos recursos do Private Service Connect através do ponto final do Private Service Connect.
- Se uma aplicação estiver exposta externamente através de um balanceador de carga de aplicações, considere usar o Google Cloud Armor como uma camada adicional de segurança para proteção contra DDoS e ameaças de segurança da camada de aplicação.
Se as instâncias precisarem de acesso à Internet, use o Cloud NAT na VPC da aplicação (consumidor) para permitir que as cargas de trabalho acedam à Internet. Desta forma, evita atribuir endereços IP públicos externos a instâncias de VM em sistemas implementados atrás de um gateway de API ou um equilibrador de carga.
- Para o tráfego Web de saída, pode usar o Google Cloud Secure Web Proxy. O proxy oferece várias vantagens.
Reveja as práticas recomendadas gerais para padrões de rede híbridos e multicloud.