Saída controlada

Last reviewed 2025-01-23 UTC

A arquitetura do padrão de rede de saída controlada é baseada na exposição de APIs selecionadas do ambiente local ou de outro ambiente de nuvem para cargas de trabalho implantadas em Google Cloud. Isso é feito sem expor diretamente os dados à Internet pública de um ambiente local ou de outros ambientes de nuvem. É possível facilitar essa exposição limitada por meio de um gateway de API ou proxy ou um balanceador de carga que funciona como uma fachada para cargas de trabalho atuais. É possível implantar a funcionalidade do gateway de API em um segmento de rede de perímetro isolado, como uma rede de perímetro.

O padrão de rede saída de saída controlada se aplica principalmente a (mas não se limita a) padrões de arquitetura de aplicativos em camadas e padrões de arquitetura de aplicativos particionados. Ao implantar cargas de trabalho de back-end em uma rede interna, a rede de saída gerida ajuda a manter um nível mais alto de segurança no ambiente de computação local. O padrão exige que você conecte os ambientes de computação de maneira a atender aos seguintes requisitos de comunicação:

  • As cargas de trabalho implantadas no Google Cloud podem se comunicar com o gateway de API ou o balanceador de carga (ou um endpoint do Private Service Connect) que expõe o aplicativo usando endereços IP internos.
  • Outros sistemas no ambiente de computação particular não podem ser acessados diretamente de dentro do Google Cloud.
  • Não é permitida a comunicação do ambiente de computação particular com nenhuma carga de trabalho implantada no Google Cloud .
  • O tráfego para as APIs particulares em outros ambientes só é iniciado no ambiente Google Cloud .

O foco deste guia é em ambientes híbridos e multicloud conectados por uma rede híbrida privada. Se os requisitos de segurança da sua organização permitirem, as chamadas de API para APIs de destino remotas com endereços IP públicos poderão ser acessadas diretamente pela Internet. No entanto, é necessário considerar os seguintes mecanismos de segurança:

  • API OAuth 2.0 com Transport Layer Security (TLS).
  • Limitação de taxa.
  • Políticas de proteção contra ameaças.
  • TLS mútuo configurado no back-end da camada da API.
  • Filtragem de lista de permissõ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 aspectos de segurança. Para mais informações, consulte Práticas recomendadas para proteger seus aplicativos e APIs usando a Apigee.

Arquitetura

O diagrama a seguir mostra uma arquitetura de referência que oferece suporte aos requisitos de comunicação listados na seção anterior:

Os dados fluem em uma direção de um projeto host em Google Cloud para uma carga de trabalho em um ambiente local.

Os dados fluem pelo diagrama anterior da seguinte maneira:

  • No lado do Google Cloud , é possível implantar cargas de trabalho em nuvens privadas virtuais (VPCs). As VPCs podem ser únicas ou múltiplas (compartilhadas ou não compartilhadas). A implantação precisa estar alinhada com os projetos e o design da hierarquia de recursos da sua organização.
  • As redes VPC do ambiente Google Cloud são estendidas para outros ambientes de computação. Os ambientes podem estar no local ou em outra nuvem. Para facilitar a comunicação entre ambientes usando endereços IP internos, use uma conectividade de rede híbrida e multicloud adequada.
  • Para limitar o tráfego que se origina de endereços IP específicos da VPC e é destinado a gateways remotos ou balanceadores de carga, use a filtragem de lista de permissões de endereços IP. O tráfego de retorno dessas conexões é permitido ao usar regras de firewall stateful. É possível usar qualquer combinação dos recursos a seguir para proteger e limitar as comunicações apenas aos endereços IP de origem e destino permitidos:

  • Todos os ambientes compartilham um espaço de endereços IP RFC 1918 sem sobreposição.

Variações

O padrão de arquitetura de saída controlada pode ser combinado com outras abordagens para atender a diferentes requisitos de design que ainda consideram os requisitos de comunicação desse padrão. O padrão oferece as seguintes opções:

Usar o gateway de API Google Cloud e o front-end global

Os dados fluem em Google Cloud da Apigee para uma VPC do projeto do cliente e depois saem do Cloud para um ambiente local ou outra instância de nuvem.

Com essa abordagem de design, a exposição e o gerenciamento da API ficam em Google Cloud. Conforme mostrado no diagrama anterior, isso pode ser feito com a implementação do Apigee como a plataforma de API. A decisão de implantar um gateway de API ou balanceador de carga no ambiente remoto depende das suas necessidades específicas e da configuração atual. A Apigee oferece duas opções de provisionamento de conectividade:

  • Com peering de VPC
  • Sem peering de VPC

Google Cloud Os recursos globais do front-end, como o Cloud Load Balancing, o Cloud CDN (quando acessados pelo Cloud Interconnect) e a Interconexão entre nuvens aumentam a velocidade com que os usuários podem acessar aplicativos com back-ends hospedados nos seus ambientes locais e em outros ambientes de nuvem.

A otimização das velocidades de entrega de conteúdo é alcançada com a entrega desses aplicativos a partir de Google Cloud pontos de presença (PoPs). Google Cloud Os PoPs estão presentes em mais de 180 pontos de trocas de tráfego de Internet e em mais de 160 instalações de interconexão em todo o mundo.

Para saber como os POPs ajudam a fornecer APIs de alto desempenho ao usar a Apigee com o Cloud CDN para realizar o seguinte, assista Como entregar APIs de alto desempenho com a Apigee e o Cloud CDN no YouTube:

  • reduzir a latência.
  • Hospedar APIs globalmente.
  • Aumente a disponibilidade em momentos de pico de tráfego.

O exemplo de design ilustrado no diagrama anterior é baseado no Private Service Connect sem peering de VPC.

A rede northbound neste design é estabelecida por:

A rede southbound é estabelecida por:

  • Um endpoint do Private Service Connect que faz referência a um anexo de serviço associado a um balanceador de carga interno (ILB no diagrama) na VPC do cliente.
  • O ILB é implantado com grupos de endpoints de rede de conectividade híbrida (NEGs de conectividade híbrida).

  • Os serviços híbridos são acessados pelo NEG de conectividade híbrida em uma conectividade de rede híbrida, como VPN ou Cloud Interconnect.

Para mais informações, consulte Configurar um balanceador de carga de rede de proxy interno regional com conectividade híbrida e Padrões de implantação do Private Service Connect.

Expor serviços remotos usando o Private Service Connect

Dados que fluem de Google Cloud para um ambiente local ou outra nuvem, depois de originarem de uma carga de trabalho em uma VPC e passarem pelo Cloud Load Balancing, um NEG de conectividade híbrida e um Cloud VPN ou interconnect.

Use a opção Private Service Connect para expor serviços remotos nos seguintes cenários:

  • Você não está usando uma plataforma de API ou quer evitar conectar toda a rede VPC diretamente a um ambiente externo pelos seguintes motivos:
    • Você tem restrições de segurança ou requisitos de compliance.
    • Você tem uma sobreposição de intervalo de endereços IP, como em um cenário de fusão e aquisição.
  • Para ativar comunicações unidirecionais seguras entre clientes, aplicativos e serviços em todos os ambientes, mesmo quando você tem um prazo curto.
  • Talvez seja necessário fornecer conectividade a várias VPCs de consumidor por meio de uma VPC de serviço-produtor (VPC de trânsito) para oferecer modelos de serviço multilocatário ou locatário único altamente escalonáveis e alcançar serviços publicados em outros ambientes.

O uso do Private Service Connect para aplicativos consumidos como APIs fornece um endereço IP interno para os aplicativos publicados, permitindo o acesso seguro na rede particular entre regiões e em conectividade híbrida. Essa abstração facilita a integração de recursos locais e de nuvens diversas ambientes em um modelo de conectividade híbrido e de multicloud. É possível acelerar a integração de aplicativos e expor com segurança aplicativos que residem em um ambiente local ou em outro ambiente de nuvem usando o Private Service Connect para publicar o serviço com acesso refinado. Nesse caso, use a das seguintes opções:

No diagrama anterior, as cargas de trabalho na rede VPC do seu aplicativo podem alcançar os serviços híbridos em execução no ambiente local ou em outros ambientes de nuvem pelo endpoint do Private Service Connect, conforme ilustrado no diagrama a seguir. Essa opção de design para comunicações unidirecionais oferece uma opção alternativa ao peering com uma VPC de trânsito.

Os dados fluem por e entre várias VPCs dentro de Google Cloud antes de sair por uma Cloud VPN ou do Cloud Interconnect e chegar a um ambiente local ou a outra nuvem.

Como parte do design no diagrama anterior, vários front-ends, back-ends ou endpoints podem se conectar ao mesmo anexo de serviço, permitindo que várias redes VPC ou vários consumidores acessem o mesmo serviço. Conforme ilustrado no diagrama abaixo, é possível tornar o aplicativo acessível a várias VPCs. Essa acessibilidade pode ajudar em cenários de serviços multilocatários em que o serviço é consumido por várias VPCs de consumidor, mesmo que os intervalos de endereços IP se sobreponham.

A sobreposição de endereços IP é um dos problemas mais comuns ao integrar aplicativos que residem em ambientes diferentes. A conexão do Private Service Connect no diagrama a seguir ajuda a evitar o problema de sobreposição de endereços IP. Isso é feito sem exigir provisionamento ou gerenciamento de outros componentes de rede, como o Cloud NAT ou um NVA, para realizar a conversão de endereços IP. Para conferir um exemplo de configuração, consulte Publicar um serviço híbrido usando o Private Service Connect.

O design tem as seguintes vantagens:

  • Evita possíveis dependências de escalonamento compartilhadas e uma capacidade de gerenciamento complexa.
  • Melhora a segurança com um controle de conectividade mais refinado.
  • Reduz a coordenação do endereço 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 estágios posteriores para integrar a Apigee como a plataforma de API usando as opções de design de rede discutidas anteriormente, incluindo a opção do Private Service Connect.

É possível tornar o endpoint do Private Service Connect acessível de outras regiões usando o acesso global do Private Service Connect.

O cliente que se conecta ao endpoint do Private Service Connect pode estar na mesma região do endpoint ou em uma região diferente. Essa abordagem pode ser usada para fornecer alta disponibilidade em serviços hospedados em várias regiões ou para acessar serviços disponíveis em uma única região de outras regiões. Quando um endpoint do Private Service Connect é acessado por recursos hospedados em outras regiões, as cobranças de saída inter-regionais se aplicam ao tráfego destinado a endpoints com acesso global.

Práticas recomendadas

  • Considere o Apigee e o Apigee Hybrid como sua solução de plataforma de API, que oferece vários benefícios. Ela oferece uma camada de proxy e uma abstração ou fachada para as APIs de serviço de back-end, combinadas com recursos de segurança, limitação de taxa, cotas e análises.
  • O design de VPCs e projetos no Google Cloud precisa ser orientado pela hierarquia de recursos e pelos requisitos do modelo de comunicação segura.
  • Quando APIs com gateways de API são usadas, você também precisa usar uma lista de permissões de endereços IP. Uma lista de permissões limita as comunicações às origens e destinos de endereços IP específicos dos consumidores e gateways de API que podem ser hospedados em ambientes diferentes.
  • Use regras de firewall da VPC ou políticas de firewall para controlar o acesso aos recursos do Private Service Connect pelo endpoint do Private Service Connect.
  • Se um aplicativo for exposto externamente por um balanceador de carga, use o Google Cloud Armor como uma camada extra de segurança para se proteger contra ameaças de segurança da camada do aplicativo e DDoS.
  • Se as instâncias exigirem acesso à Internet, use o Cloud NAT na VPC do aplicativo (consumidor) para permitir que as cargas de trabalho acessem a Internet. Ao fazer isso, você evita atribuir instâncias de VM com endereços IP públicos externos em sistemas implantados por trás de um gateway de API ou um balanceador de carga.

  • Consulte a práticas recomendadas gerais para padrões de rede híbridos e multicloud.