Este documento faz parte de uma série que descreve arquiteturas de rede e segurança para empresas que estão migrando cargas de trabalho de data center para o Google Cloud.
A série inclui os documentos a seguir:
- Como projetar redes para migrar cargas de trabalho empresariais: abordagens de arquitetura
- Rede para acesso intranuvem seguro: arquiteturas de referência (este documento)
- Rede para entrega de aplicativos voltados à Internet: arquiteturas de referência
- Rede para cargas de trabalho híbridas e em várias nuvens: arquiteturas de referência
Cargas de trabalho para casos de uso intranuvem residem em redes VPC e precisam se conectar a outros recursos no Google Cloud. Elas podem consumir serviços fornecidos de maneira nativa na nuvem, como o BigQuery. O perímetro de segurança é fornecido por uma variedade de recursos primários e de terceiros, como firewalls, VPC Service Controls e dispositivos virtuais de rede.
Em muitos casos, essas cargas de trabalho abrangem várias redes VPC do Google Cloud, e os limites entre as redes VPC precisam ser protegidos. Este documento aborda essas arquiteturas de segurança e conectividade em detalhes.
Arquitetura de migração lift-and-shift
O primeiro cenário de um caso de uso intranuvem é uma arquitetura de migração lift-and-shift em que você move cargas de trabalho estabelecidas para a nuvem no estado em que se encontram.
Firewall
Para ajudar a estabelecer um perímetro seguro, configure regras de firewall.
Use tags de rede para aplicar regras de firewall refinadas a uma coleção de VMs. Uma tag é um atributo arbitrário formado por uma string de caracteres adicionada ao campo tags da VM no momento da criação dela.
É possível atribuir uma tag mais tarde pela edição da VM. Para ver as diretrizes de implementação sobre como gerenciar o tráfego com as regras de firewall do Google Cloud, consulte Políticas de firewall de rede no blueprint de fundação empresarial.
Também é possível usar a geração de registros de firewall para auditar e verificar os efeitos da configuração da regra de firewall.
É possível usar registros de fluxo da VPC para análise forense de rede e transmitir os registros para fazer a integração com o SIEM. Esse sistema geral fornece monitoramento em tempo real, correlação de eventos, análises e alertas de segurança.
A figura 1 mostra como as regras de firewall podem usar tags de VM para ajudar a restringir o tráfego entre as VMs em uma rede VPC.
Figura 1. Configuração de firewall de rede que usa tags de rede para aplicar controle de saída detalhado.
Dispositivo virtual de rede
Um dispositivo virtual de rede (NVA, na sigla em inglês) é uma VM com várias interfaces de rede. O NVA permite que você se conecte diretamente a várias redes VPC. As funções de segurança, como firewalls de aplicativos da Web (WAF) e firewalls de nível de aplicativo de segurança, podem ser implementadas nas VMs. É possível usar NVAs para implementar funções de segurança para o tráfego de leste-oeste, especialmente quando você estiver usando uma configuração hub-spoke, como mostrado na figura 2.
Para diretrizes de implementação sobre como usar NVAs no Google Cloud, consulte Dispositivos de rede centralizados no Google Cloud.
Figura 2. Configuração de dispositivo de rede centralizada em uma rede VPC compartilhada.
Cloud IDS
Com o Cloud Intrusion Detection System (Cloud IDS), é possível implementar a geração de registros e a inspeção de segurança nativa pelo espelhamento do tráfego de uma sub-rede na rede VPC. Ao usar o Cloud IDS, é possível inspecionar e monitorar uma ampla variedade de ameaças na camada de rede e na camada do aplicativo para análise. Você cria endpoints do Cloud IDS na rede VPC associada ao projeto do Google Cloud. Esses endpoints monitoram o tráfego de entrada e saída dessa rede, assim como o tráfego de rede intra-VPC, usando a funcionalidade de espelhamento de pacotes integrada na pilha de rede do Google Cloud. Ative o acesso a serviços particulares para se conectar ao projeto do produtor de serviço (o projeto gerenciado pelo Google) que hospeda os processos do Cloud IDS.
Se você tiver uma arquitetura hub-and-spoke, o tráfego de cada um dos spokes poderá ser espelhado às instâncias do Cloud IDS, como mostrado na figura 3.
Figura 3. Configuração do Cloud IDS para espelhar o tráfego da VPC que usa o acesso a serviços particulares.
O Cloud IDS pode ser protegido no perímetro de serviço do VPC Service Controls usando uma etapa adicional. Leia mais sobre o suporte do VPC Service Controls em produtos compatíveis.
Peering de rede VPC
Para aplicativos que abrangem várias redes VPC, sejam elas do mesmo projeto do Google Cloud ou do mesmo recurso da organização, o peering de rede VPC permite a conectividade entre redes VPC. Essa conectividade permite que o tráfego permaneça na rede do Google para que não atravesse a Internet pública.
Há dois modelos para usar o peering de rede VPC em uma arquitetura de migração lift-and-shift. Um deles tem uma arquitetura hub-and-spoke "pura", e o outro tem uma arquitetura hub-and-spoke com transitividade, em que o tráfego de um spoke pode alcançar outro spoke. As seções a seguir fornecem detalhes sobre como usar o peering de rede VPC com essas diferentes arquiteturas.
Arquitetura hub-and-spoke
Uma arquitetura hub-e-spoke é um modelo conhecido de conectividade de VPC que usa o peering de rede VPC. Esse modelo é útil quando uma empresa tem vários aplicativos que precisam acessar um conjunto comum de serviços, como geração de registros ou autenticação. O modelo também é útil se a empresa precisa implementar um conjunto comum de políticas de segurança para o tráfego que sai da rede pelo hub. Em um modelo hub-and-spoke puro, a troca de tráfego entre os spokes (conhecido como tráfego transitivo) não é permitida. A figura 4 mostra uma arquitetura hub-and-spoke pura que usa o peering de rede VPC para conectar os spokes ao hub. Para ver as diretrizes de implementação sobre a criação de redes hub e spoke, consulte Topologia de rede hub e spoke no blueprint de fundação empresarial.
No entanto, se você não precisar da separação no nível da VPC, use uma arquitetura de VPC compartilhada, que pode fornecer um modelo mais simples para algumas empresas que estão apenas começando no Google Cloud.
Figura 4. Arquitetura de rede hub-and-spoke que usa peering de rede VPC para isolamento de rede e conectividade não transitiva.
Hub e spoke com transitividade
Para ativar hub-and-spoke com transitividade (o tráfego de um spoke pode alcançar outros spokes pelo hub), há várias abordagens que usa o peering de rede VPC. É possível usar o peering de rede VPC em uma topologia de malha completa, em que todas as redes VPC fazem peering direto com todas as outras redes VPC que precisam alcançar.
Outra possibilidade é usar um NVA para conectar o hub e os spokes. Assim, o NVA reside atrás dos balanceadores de carga internos, que são usados como o próximo salto do tráfego dos spokes da VPC. A figura 5 mostra essas duas opções.
Além disso, é possível usar VPNs para conexão entre redes VPC do hub e do spoke. Essa disposição permite acessibilidade em conexões spoke-spoke, o que proporciona transitividade em toda a rede VPC do hub.
Figura 5. Configuração de rede hub-and-spoke que usa o Cloud VPN para isolamento de rede e conectividade transitiva.
VPC compartilhada
Use a VPC compartilhada para manter o controle centralizado de recursos de rede, como sub-redes, rotas e firewalls em projetos host. Com esse nível de controle, você consegue implementar a prática recomendada de segurança de privilégio mínimo para administração da rede, auditoria e controle de acesso já que é possível delegar tarefas de administração da rede a administradores de rede e segurança. É possível atribuir a capacidade de criar e gerenciar VMs para administradores de instância usando projetos de serviço. O uso de um projeto de serviço garante que os administradores de VM só possam criar e gerenciar instâncias e que não tenham permissão para fazer qualquer alteração que afete a rede VPC compartilhada.
Por exemplo, é possível fornecer mais isolamento definindo duas redes VPC que estão em dois projetos host e anexando vários projetos de serviço a cada rede, uma para produção e outra para teste. A figura 6 mostra uma arquitetura que isola um ambiente de produção de um ambiente de teste usando projetos separados.
Para mais informações sobre práticas recomendadas para a criação de redes VPC, consulte Práticas recomendadas e arquiteturas de referência para projetar VPC.
Figura 6. Configuração de rede VPC compartilhada que usa vários projetos de serviços e hosts isolados (ambientes de produção e teste).
Arquitetura de serviços híbridos
A arquitetura de serviços híbridos oferece mais serviços nativos da nuvem, projetados para permitir que você conecte e proteja serviços em um ambiente de várias VPCs. Esses serviços nativos da nuvem complementam o que está disponível na arquitetura de migração lift-and-shift e podem facilitar o gerenciamento de um ambiente segmentado de VPC em escala.
Private Service Connect
O Private Service Connect permite que um serviço hospedado em uma rede VPC seja exibido em outra rede VPC. Não há requisitos para que os serviços sejam hospedados pelo mesmo recurso da organização. Portanto, o Private Service Connect pode ser usado para consumir serviços particulares de outra rede VPC, mesmo que esteja anexado a outro recurso da organização.
É possível usar o Private Service Connect de duas maneiras: para acessar as APIs do Google ou para acessar serviços hospedados em outras redes VPC.
Usar o Private Service Connect para acessar APIs do Google
Ao usar o Private Service Connect, você pode expor APIs do Google usando um endpoint do Private Service Connect que faz parte da sua rede VPC, como mostrado na figura 7.
Figura 7. Configuração do Private Service Connect para enviar tráfego às APIs do Google usando um endpoint do Private Service Connect particular à sua rede VPC.
As cargas de trabalho podem enviar tráfego para um pacote de APIs globais do Google usando um endpoint do Private Service Connect. Além disso, é possível usar um back-end do Private Service Connect para acessar uma única API do Google, estendendo os recursos de segurança dos balanceadores de carga para os serviços da API. A figura 8 mostra essa configuração.
Figura 8. Configuração do Private Service Connect para enviar tráfego às APIs do Google usando um back-end do Private Service Connect.
Usar o Private Service Connect entre redes VPC ou entidades
O Private Service Connect também permite que um produtor de serviços ofereça serviços a um consumidor de serviço em outra rede VPC no mesmo recurso da organização ou em um recurso diferente. Uma rede VPC do produtor de serviços pode ser compatível com vários consumidores de serviços. O consumidor pode se conectar ao serviço de produtor enviando tráfego para um endpoint do Private Service Connect localizado na rede VPC do consumidor. O endpoint encaminha o tráfego para a rede VPC que contém o serviço publicado.
Figura 9. Configuração do Private Service Connect para publicar um serviço gerenciado por meio de um anexo de serviço e consumir o serviço por um endpoint.
Conector de acesso VPC sem servidor
Um conector de acesso VPC sem servidor gerencia o tráfego entre o ambiente sem servidor e a rede VPC. Ao criar um conector no seu projeto do Google Cloud, anexe-o a uma rede VPC e região específicas. Em seguida, configure os serviços sem servidor para usar o conector em tráfego de rede de saída. É possível especificar um conector usando uma sub-rede ou um intervalo CIDR. O tráfego enviado pelo conector para a rede VPC tem origem na sub-rede ou no intervalo CIDR especificado, como mostrado na figura 10.
Figura 10. Configuração do conector de acesso VPC sem servidor para acessar ambientes sem servidor do Google Cloud usando endereços IP internos na sua rede VPC.
Os conectores de acesso VPC sem servidor são compatíveis com todas as regiões compatíveis com o ambiente padrão do Cloud Run, do Cloud Functions ou do App Engine. Para mais informações, consulte a lista de Serviços com suporte e protocolos de rede compatíveis para usar o conector de acesso VPC sem servidor.
VPC Service Controls
O VPC Service Controls ajuda a evitar a exfiltração de dados de serviços como o Cloud Storage ou o BigQuery, impedindo acessos autorizados da Internet ou de projetos que não fazem parte de um perímetro de segurança. Por exemplo, imagine um cenário em que erros humanos ou automações incorretas fazem com que as políticas do IAM sejam definidas incorretamente em um serviço como o Cloud Storage ou o BigQuery. Por consequência, os recursos nesses serviços tornam-se publicamente acessíveis. Nesse caso, há o risco de exposição dos dados. Se você tiver esses serviços configurados como parte do perímetro do VPC Service Controls, o acesso de entrada aos recursos será bloqueado, mesmo que as políticas do IAM permitam o acesso.
O VPC Service Controls pode criar perímetros com base nos atributos do cliente, como o tipo de identidade (conta de serviço ou usuário) e a origem da rede (endereço IP ou rede VPC).
O VPC Service Controls ajuda a mitigar os seguintes riscos de segurança:
- Acesso de redes não autorizadas que usam credenciais roubadas.
- Exfiltração de dados por pessoas maliciosas com informações privilegiadas ou código comprometido.
- Exposição pública de dados particulares causada por políticas do IAM configuradas incorretamente.
A figura 11 mostra como o VPC Service Controls permite estabelecer um perímetro de serviço para ajudar a mitigar esses riscos.
Figura 11. Perímetro de serviço da VPC estendido para ambientes híbridos usando serviços de acesso particular.
Usando regras de entrada e saída, é possível ativar a comunicação entre dois perímetros de serviço, como mostrado na figura 12.
Figura 12. Configuração de regras de entrada e saída para comunicação entre perímetros de serviço.
Para ver recomendações detalhadas de arquiteturas de implantação do VPC Service Controls, consulte Projetar e arquitetar perímetros de serviço. Para mais informações sobre a lista de serviços compatíveis com o VPC Service Controls, consulte Limitações e produtos compatíveis.
Arquitetura distribuída de confiança zero
Os controles de segurança do perímetro de rede são necessários, mas não suficientes para suportar os princípios de segurança de privilégio mínimo e defesa em profundidade. Para aplicação da segurança, as arquiteturas distribuídas de confiança zero são baseadas na borda do perímetro de rede, mas não dependem apenas dela. Como arquiteturas distribuídas, elas são compostas por microsserviços com aplicação de política de segurança por serviço, autenticação forte e identidade da carga de trabalho.
É possível implementar arquiteturas distribuídas de confiança zero como serviços gerenciados pelo Traffic Director e pelo Anthos Service Mesh.
Traffic Director
É possível configurar o Traffic Director para fornecer uma malha de microsserviço de arquitetura distribuída de confiança zero dentro de um cluster do GKE usando a segurança do serviço. Nesse modelo, todos os serviços do GKE que têm arquivos secundários Envoy ou identidade, certificados, política de autorização e gRPC sem proxy são gerenciados por todos estes elementos: Traffic Director, identidade da carga de trabalho, Certificate Authority Service e IAM. O gerenciamento de certificados e a nomenclatura segura são fornecidos pela plataforma, e toda a comunicação do serviço está sujeita à segurança de transporte mTLS. A figura 13 mostra um cluster com essa configuração.
Figura 13. Malha de arquitetura distribuída de confiança zero de cluster único que usa o Traffic Director.
Uma política de autorização especifica como um servidor autoriza solicitações de entrada ou RPCs. É possível configurar a política de autorização para permitir ou negar uma solicitação de entrada ou RPC com base em vários parâmetros, como a identidade do cliente que enviou a solicitação, o host, os cabeçalhos e outros atributos HTTP. As diretrizes de implementação estão disponíveis para configurar políticas de autorização em malhas baseadas em gRPC e no Envoy.
Na figura 13, a arquitetura tem um único cluster e uma rede simples (espaço de endereço IP compartilhado). Normalmente, vários clusters são usados em uma arquitetura distribuída de confiança zero para isolamento, local e escala.
Em ambientes mais complexos, vários clusters podem compartilhar identidade gerenciada quando os clusters são agrupados usando frotas. Nesse caso, é possível configurar a conectividade de rede em redes VPC independentes usando o Private Service Connect. Essa abordagem é semelhante àquela de conectividade de rede de vários clusters de acesso híbrido, como descrito mais adiante neste documento.
Para informações sobre o controle refinado do modo de processamento do tráfego com o Traffic Director, consulte Visão geral do gerenciamento de tráfego avançado.
Anthos Service Mesh
O Anthos Service Mesh fornece uma malha de microsserviço de arquitetura distribuída de confiança zero mTLS pronta para uso criada com base nos fundamentos do Istio. É possível configurar a malha usando um fluxo integrado. O Anthos Service Mesh gerenciado, com planos de controle e dados gerenciados pelo Google, é compatível com o GKE. Um plano de controle no cluster também está disponível, o que é adequado para outros ambientes, como Google Distributed Cloud Virtualises ou GKE Várias nuvens. O Anthos Service Mesh gerencia a identidade e os certificados para você, fornecendo um modelo de política de autorização baseado no Istio.
O Anthos Service Mesh depende de frotas para gerenciar a configuração e a identidade da implantação do serviço de vários clusters. Assim como no Traffic Director, quando suas cargas de trabalho operam em um ambiente de conectividade de rede VPC simples (ou compartilhada), não há requisitos especiais de conectividade de rede além da configuração do firewall. Quando a arquitetura incluir vários clusters do Anthos Service Mesh em redes VPC ou ambientes de rede separados, como em uma conexão do Cloud Interconnect, você também precisará de um gateway leste-oeste. As práticas recomendadas para redes do Anthos Service Mesh são as mesmas descritas em Práticas recomendadas para redes do GKE.
O Anthos Service Mesh também é integrado ao Identity-Aware Proxy (IAP). Com o IAP, você define políticas de acesso refinadas para controlar o acesso do usuário a uma carga de trabalho com base em atributos da solicitação de origem, como identidade do usuário, endereço IP e tipo de dispositivo. Esse nível de controle permite um ambiente de confiança zero de ponta a ponta.
Ao usar o Anthos Service Mesh, é preciso considerar os requisitos do cluster do GKE. Para mais informações, consulte a seção Requisitos na documentação "Instalação de projeto único no GKE".
A seguir
- Rede para entrega de aplicativos voltados à Internet: arquiteturas de referência.
- Rede para cargas de trabalho híbridas e em várias nuvens: arquiteturas de referência.
- A migração para o Google Cloud pode ajudar você a planejar, projetar e implementar o processo de migração das suas cargas de trabalho para o Google Cloud.
- O design da zona de destino no Google Cloud tem orientações para criar uma rede de zona de destino.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.