Este documento faz parte de uma série que descreve as arquiteturas de rede e segurança para empresas que estão a migrar cargas de trabalho de centros de dados para aGoogle Cloud.
A série é composta pelos seguintes documentos:
- Conceber redes para a migração de cargas de trabalho empresariais: abordagens arquitetónicas
- Redes para acesso seguro na nuvem: arquiteturas de referência (este documento)
- Redes para a entrega de aplicações viradas para a Internet: arquiteturas de referência
- Trabalho em rede para cargas de trabalho híbridas e de várias nuvens: arquiteturas de referência
As cargas de trabalho para exemplos de utilização na nuvem residem em redes VPC e têm de se ligar a outros recursos no Google Cloud. Podem consumir serviços fornecidos nativamente na nuvem, como o BigQuery. O perímetro de segurança é fornecido por várias capacidades originais (1P) e de terceiros (3P), como firewalls, VPC Service Controls e dispositivos virtuais de rede.
Em muitos casos, estas cargas de trabalho abrangem várias redes VPC e os limites entre as redes VPC têm de ser protegidos. Google CloudEste documento aborda estas arquiteturas de segurança e conectividade em detalhe.
Arquitetura de lift-and-shift
O primeiro cenário para um exemplo de utilização na nuvem é uma arquitetura de lift-and-shift, em que move cargas de trabalho estabelecidas para a nuvem tal como estão.
Cloud NGFW
Pode ajudar a estabelecer um perímetro seguro configurando a firewall de nova geração do Google Cloud. Pode usar etiquetas, contas de serviço e etiquetas de rede para aplicar regras de firewall detalhadas às VMs. Para ver diretrizes de implementação sobre como gerir o tráfego com Google Cloud regras de firewall, consulte as políticas de firewall de rede no projeto de base empresarial.
Também pode usar o Registo de regras de firewall para auditar e verificar os efeitos da definição de regras de firewall.
Pode usar os registos de fluxo de VPC para análise forense de rede e também transmitir os registos para integração com SIEM. Este sistema geral pode fornecer monitorização em tempo real, correlação de eventos, análise e alertas de segurança.
A Figura 1 mostra como as regras de firewall podem usar etiquetas de rede para ajudar a restringir o tráfego entre VMs numa rede da VPC.
Figura 1. Configuração da firewall de rede que usa etiquetas de rede para aplicar controlo de saída detalhado.
Dispositivo virtual de rede
Um dispositivo virtual de rede (NVA) é uma VM que tem funções de segurança, como firewalls de aplicações Web (WAF) ou firewalls ao nível da aplicação de segurança. As NVAs com várias interfaces de rede podem ser usadas para criar uma ponte entre redes VPC. Pode usar NVAs para implementar funções de segurança no tráfego entre redes VPC, especialmente quando usa uma configuração de hub-spoke, como mostrado na figura 2.
Figura 2. Configuração centralizada do dispositivo de rede numa rede de VPC partilhada.
Cloud IDS
O sistema de deteção de intrusos do Cloud (Cloud IDS) permite-lhe implementar a inspeção de segurança nativa e o registo através da replicação do tráfego de uma sub-rede na sua rede VPC. Ao usar o Cloud IDS, pode inspecionar e monitorizar uma grande variedade de ameaças na camada de rede e na camada de aplicação para análise. Cria pontos finais do Cloud IDS na sua Google Cloud rede VPC. Estes pontos finais monitorizam o tráfego de entrada e saída para e a partir dessa rede, bem como o tráfego de rede intra-VPC, através da funcionalidade de espelhamento de pacotes integrada na Google Cloud pilha de rede. Tem de ativar o acesso a serviços privados para se ligar ao projeto do produtor de serviços (o projeto gerido pela Google) que aloja os processos do Cloud IDS.
Se tiver uma arquitetura de hub e raios, o tráfego de cada um dos raios pode ser espelhado nas instâncias do Cloud IDS, conforme mostrado na figura 3.
Figura 3. Configuração do Cloud IDS para duplicar o tráfego da VPC que usa o acesso a serviços privados.
O Cloud IDS pode ser protegido no perímetro de serviço dos VPC Service Controls através de um passo adicional. Pode ler mais acerca do apoio técnico do VPC Service Controls nos produtos suportados.
Network Connectivity Center
O Network Connectivity Center é uma framework de orquestração que simplifica a conetividade de rede entre recursos ligados a um recurso de gestão central denominado hub. O Network Connectivity Center suporta os seguintes tipos de redes:
- Google Cloud redes VPC
- Redes nas instalações e outras redes de nuvem que usam o Cloud Interconnect ou a VPN de alta disponibilidade
- Ligações encriptadas ancoradas por VMs
O Network Connectivity Center é o plano de controlo da arquitetura. As ligações a redes são denominadas raios. Pode usar o Centro de conectividade de rede para ligar redes entre si numa topologia de malha completa ou de hub e raio.
Intercâmbio de redes da VPC
Para aplicações que abrangem várias redes VPC, quer pertençam ao mesmo Google Cloud projeto ou ao mesmo recurso da organização, o intercâmbio da rede da VPC permite a conetividade entre redes VPC. Esta conetividade permite que o tráfego permaneça na rede da Google para que não atravesse a Internet pública.
Uma arquitetura de hub e spoke é um modelo popular para a conetividade de VPCs. Este modelo é útil quando uma empresa tem várias aplicações que precisam de aceder a um conjunto comum de serviços, como registo ou autenticação. O modelo também é útil se a empresa precisar de implementar um conjunto comum de políticas de segurança para o tráfego que sai da rede através do hub. Para orientações sobre a configuração de uma arquitetura de hub e raios através do intercâmbio da rede da VPC, consulte o artigo Conetividade entre VPCs da rede entre nuvens através do intercâmbio da rede da VPC.
VPC partilhada
Pode usar a VPC partilhada para manter o controlo centralizado sobre os recursos de rede, como sub-redes, trajetos e firewalls em projetos anfitriões. Este nível de controlo permite-lhe implementar a prática recomendada de segurança de privilégios mínimos para a administração de rede, a auditoria e o controlo de acesso, uma vez que pode delegar tarefas de administração de rede a administradores de rede e de segurança. Pode atribuir a capacidade de criar e gerir VMs a administradores de instâncias através de projetos de serviço. A utilização de um projeto de serviço garante que os administradores de VMs só têm a capacidade de criar e gerir instâncias, e que não podem fazer alterações que afetem a rede na rede de VPC partilhada.
Por exemplo, pode fornecer mais isolamento definindo duas redes VPC que estão em dois projetos anfitriões e anexando vários projetos de serviço a cada rede, um para produção e outro para testes. A Figura 6 mostra uma arquitetura que isola um ambiente de produção de um ambiente de teste através da utilização de projetos separados.
Para mais informações sobre as práticas recomendadas para criar redes VPC, consulte o artigo Práticas recomendadas e arquiteturas de referência para o design de VPC.
Figura 6. Configuração de rede VPC partilhada que usa vários anfitriões isolados e projetos de serviço (ambientes de teste e produção).
Arquitetura de serviços híbridos
A arquitetura de serviços híbridos oferece serviços nativos da nuvem adicionais concebidos para lhe permitir ligar e proteger serviços num ambiente de várias VPCs. Estes serviços nativos da nuvem complementam o que está disponível na arquitetura de migração direta e podem facilitar a gestão de um ambiente segmentado por VPC em grande escala.
Private Service Connect
O Private Service Connect permite que um serviço alojado numa rede VPC seja apresentado noutra rede VPC. Não existe nenhum requisito de que os serviços sejam alojados pelo mesmo recurso da organização. Por isso, o Private Service Connect pode ser usado para consumir serviços de forma privada a partir de outra rede VPC, mesmo que esteja anexado a outro recurso da organização.
Pode usar o Private Service Connect de duas formas: para aceder às APIs Google ou para aceder a serviços alojados noutras redes VPC.
Use o Private Service Connect para aceder às APIs Google
Quando usa o Private Service Connect, pode expor APIs Google através de um ponto final do Private Service Connect que faz parte da sua rede VPC, conforme mostrado na figura 7.
Figura 7. Configuração do Private Service Connect para enviar tráfego para as APIs Google através de um ponto final do Private Service Connect privado para a sua rede VPC.
As cargas de trabalho podem enviar tráfego para um pacote de APIs Google globais através de um ponto final do Private Service Connect. Além disso, pode usar um back-end do Private Service Connect para aceder a uma única API Google, o que estende as funcionalidades de segurança dos balanceadores de carga aos serviços de API. A Figura 8 mostra esta configuração.
Figura 8. Configuração do Private Service Connect para enviar tráfego para as APIs Google através de um back-end do Private Service Connect.
Use o Private Service Connect entre redes ou entidades VPC
O Private Service Connect também permite que um produtor de serviços ofereça serviços a um consumidor de serviços noutra rede VPC no mesmo recurso de organização ou num diferente. Uma rede VPC do produtor de serviços pode suportar vários consumidores de serviços. O consumidor pode ligar-se ao serviço de produtor enviando tráfego para um ponto final do Private Service Connect localizado na rede VPC do consumidor. O ponto final 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 gerido através de uma associação do serviço e consumir o serviço através de um ponto final.
Acesso a serviços privados
O Private Service Connect é a forma recomendada para um produtor de serviços fornecer um serviço a um consumidor de serviços. No entanto, o Private Service Connect não suporta todos os serviços. Pode usar o acesso privado aos serviços para aceder a estes serviços indicados.
Conetor de acesso sem servidor à VPC
Um conetor de acesso sem servidor da VPC processa o tráfego entre o seu ambiente sem servidor e a sua rede VPC. Quando cria um conetor no seu Google Cloud projeto, associa-o a uma rede VPC e a uma região específicas. Em seguida, pode configurar os seus serviços sem servidor para usar o conector para tráfego de rede de saída. Pode especificar um conetor através de uma sub-rede ou de um intervalo CIDR. O tráfego enviado através do conector para a rede VPC tem origem na sub-rede ou no intervalo CIDR especificado, conforme mostrado na figura 10.
Figura 10. Configuração do conetor de acesso a VPC sem servidor para aceder Google Cloud a ambientes sem servidor através de endereços IP internos na sua rede VPC.
Os conetores do Acesso a VPC sem servidor são suportados em todas as regiões que suportam o Cloud Run, as funções do Cloud Run ou o ambiente padrão do App Engine. Para mais informações, consulte a lista de serviços suportados e protocolos de rede suportados para usar o conector de acesso sem servidor da VPC.
Saída direta da VPC
A saída direta da VPC permite que o seu serviço do Cloud Run envie tráfego para uma rede VPC sem configurar um conetor do Acesso a VPC sem servidor.
VPC Service Controls
Os VPC Service Controls ajudam a impedir a exfiltração de dados de serviços como o Cloud Storage ou o BigQuery, impedindo acessos autorizados a partir da Internet ou de projetos que não fazem parte de um perímetro de segurança. Por exemplo, considere um cenário em que um erro humano ou uma automatização incorreta faz com que as políticas de IAM sejam definidas incorretamente num serviço como o Cloud Storage ou o BigQuery. Como resultado, os recursos nestes serviços tornam-se acessíveis publicamente. Nesse caso, existe um risco de exposição de dados. Se tiver estes serviços configurados como parte do perímetro dos VPC Service Controls, o acesso de entrada aos recursos é bloqueado, mesmo que as políticas de IAM permitam o acesso.
Os VPC Service Controls podem criar perímetros com base em atributos do cliente, como o tipo de identidade (conta de serviço ou utilizador) e a origem da rede (endereço IP ou rede VPC).
Os VPC Service Controls ajudam a mitigar os seguintes riscos de segurança:
- Acesso a partir de redes não autorizadas que usam credenciais roubadas.
- Exfiltração de dados por parte de utilizadores internos maliciosos ou código comprometido.
- Exposição pública de dados privados causada por políticas de IAM configuradas incorretamente.
A Figura 11 mostra como o VPC Service Controls lhe permite estabelecer um perímetro de serviço para ajudar a mitigar estes riscos.
Figura 11. Perímetro de serviço da VPC expandido para ambientes híbridos através da utilização de serviços de acesso privado.
Ao usar regras de entrada e saída, pode ativar a comunicação entre dois perímetros de serviço, conforme mostrado na figura 12.
Figura 12. Configurar regras de entrada e saída para comunicar entre perímetros de serviço.
Para recomendações detalhadas sobre arquiteturas de implementação dos VPC Service Controls, consulte o artigo Conceba e crie arquiteturas de perímetros de serviço. Para mais informações acerca da lista de serviços suportados pelos controlos de serviços de VPC, consulte o artigo Produtos suportados e limitações.
Arquitetura distribuída de confiança zero
Os controlos 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. As arquiteturas distribuídas de confiança zero baseiam-se no limite do perímetro de rede para aplicação da segurança, mas não dependem exclusivamente dele. Como arquiteturas distribuídas, são compostas por microsserviços com aplicação por serviço da política de segurança, autenticação forte e identidade da carga de trabalho.
Pode implementar arquiteturas distribuídas de confiança zero como serviços geridos pelo Cloud Service Mesh e pelo Cloud Service Mesh.
Cloud Service Mesh
O Cloud Service Mesh oferece uma mTLS malha de microsserviços de arquitetura distribuída de confiança zero pronta a usar, criada com base nos fundamentos do Istio. Configura a malha através de um fluxo integrado. O Managed Cloud Service Mesh, com planos de controlo e dados geridos pela Google, é suportado no GKE. Também está disponível um plano de controlo no cluster, que é adequado para outros ambientes, como o Google Distributed Cloudises ou o GKE Multi-Cloud. O Cloud Service Mesh gere a identidade e os certificados por si, oferecendo um modelo de política de autorização baseado no Istio.
A malha de serviços na nuvem baseia-se em frotas para gerir a configuração de implementação e a identidade do serviço de vários clusters. Tal como acontece com a malha de serviços na nuvem, quando as suas cargas de trabalho operam num ambiente de conetividade de rede VPC simples (ou partilhada), não existem requisitos de conetividade de rede especiais além da configuração da firewall. Quando a sua arquitetura inclui vários clusters do Cloud Service Mesh em redes VPC separadas ou ambientes de rede, como numa ligação do Cloud Interconnect, também precisa de um gateway leste-oeste. As práticas recomendadas para o trabalho em rede do Cloud Service Mesh são as mesmas que estão descritas nas práticas recomendadas para o trabalho em rede do GKE.
O Cloud Service Mesh também se integra com o Identity-Aware Proxy (IAP). O IAP permite-lhe definir políticas de acesso detalhadas para que possa controlar o acesso dos utilizadores a uma carga de trabalho com base nos atributos do pedido de origem, como a identidade do utilizador, o endereço IP e o tipo de dispositivo. Este nível de controlo permite um ambiente de confiança zero ponto a ponto.
Tem de considerar os requisitos do cluster do GKE quando usa o Cloud Service Mesh. Para mais informações, consulte a secção Requisitos na documentação "Instalação de projeto único no GKE".
O que se segue?
- Redes para a entrega de aplicações viradas para a Internet: arquiteturas de referência.
- Redes para cargas de trabalho híbridas e multinuvem: arquiteturas de referência.
- Segurança de rede para aplicações distribuídas na rede entre nuvens.
- A migração para o Google Cloud pode ajudar a planear, conceber 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 ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.