Este documento faz parte de uma série de guias de design para o Cross-Cloud Network. Nesta parte, vamos conhecer a camada de segurança de rede.
A série consiste nas partes a seguir:
- Cross-Cloud Network para aplicativos distribuídos
- Segmentação de rede e conectividade para aplicativos distribuídos no Cross-Cloud Network
- Rede de serviços para aplicativos distribuídos no Cross-Cloud Network
- Segurança de rede para aplicativos distribuídos no Cross-Cloud Network (este documento)
Plataformas de segurança
Ao projetar a camada de segurança para o Cross-Cloud Network, considere as seguintes superfícies de segurança:
- Segurança de cargas de trabalho
- Segurança do perímetro de domínio
A segurança da carga de trabalho controla a comunicação entre cargas de trabalho entre e dentro da nuvem privada virtual (VPC). A segurança da carga de trabalho usa pontos de aplicação de segurança próximos das cargas de trabalho na arquitetura. Sempre que possível, o Cross-Cloud Network fornece segurança de carga de trabalho usando o firewall de última geração do Google Cloud.
A segurança do perímetro é necessária em todos os limites da rede. Como o perímetro geralmente interconecta redes gerenciadas por organizações diferentes, geralmente são necessários controles de segurança mais rígidos. Verifique se as seguintes comunicações nas redes estão protegidas:
- Comunicações entre VPCs
- Comunicações por meio de conexões híbridas com outros provedores de nuvem ou data centers no local
- Comunicações com a Internet
A capacidade de inserir dispositivos virtuais de rede (NVAs) de terceiros no ambiente do Google Cloud é fundamental para atender aos requisitos de segurança de perímetro em conexões híbridas.
Segurança da carga de trabalho na nuvem
Use políticas de firewall no Google Cloud para proteger cargas de trabalho e fornecer recursos de firewall com estado que são escalonáveis horizontalmente e aplicados a cada instância de VM. A natureza distribuída dos firewalls do Google Cloud ajuda a implementar políticas de segurança para microssegmentação de rede sem afetar negativamente o desempenho das cargas de trabalho.
Use políticas hierárquicas de firewall para
melhorar a capacidade de gerenciamento e impor compliance de postura com suas políticas
de firewall. As políticas hierárquicas de firewall permitem criar e aplicar uma política
consistente em toda a organização. É possível atribuir
políticas hierárquicas de firewall à organização ou a pastas individuais.
Além disso, as regras de políticas hierárquicas de firewall podem delegar a avaliação a
políticas de nível inferior (políticas de firewall de rede globais ou regionais) com uma
ação goto_next
.
As regras de nível inferior não substituem uma regra de um nível mais alto na hierarquia de recursos. Essa estrutura de regras permite que os administradores de toda a organização gerenciem regras de firewall obrigatórias em um só lugar. Casos de uso comuns para políticas hierárquicas de firewall incluem acesso a um Bastion Host de vários projetos ou organização, permissão de sistemas centralizados de sondagem ou verificação de integridade e a aplicação de um limite de rede virtual em uma organização ou grupo de projetos. Para ver outros exemplos de uso de políticas hierárquicas de firewall, consulte Exemplos de políticas hierárquicas de firewall.
Use políticas de firewall de rede global e regional para definir regras em uma rede VPC individual, seja para todas as regiões da rede (global) ou uma única região (regional).
Para ter controles mais granulares aplicados no nível da máquina virtual (VM), recomendamos que você use tags administradas pelo Identity and Access Management (IAM) no nível da organização ou do projeto. As tags controladas pelo IAM permitem aplicar regras de firewall com base na identidade do host da carga de trabalho, em oposição ao endereço IP do host, e funcionam por meio do peering de rede VPC. As regras de firewall implantadas usando tags podem fornecer microssegmentação intra-sub-rede com cobertura de política que se aplica automaticamente a cargas de trabalho onde quer que elas estejam implantadas, independentemente da arquitetura de rede.
Além dos recursos de inspeção com estado e do suporte a tags, o Cloud Next Generation Firewall também oferece suporte a Threat Intelligence, FQDN e filtragem de geolocalização.
Recomendamos que você migre das regras de firewall da VPC para as políticas de firewall. Para ajudar na migração, use a ferramenta de migração, que cria uma política de firewall de rede global e converte as regras de firewall de VPC existentes na nova política.
Segurança do perímetro na nuvem
Em um ambiente de rede com várias nuvens, a segurança do perímetro geralmente é implementada em cada rede. Por exemplo, a rede local tem o próprio conjunto de firewalls de perímetro, enquanto cada rede em nuvem implementa firewalls de perímetro separados.
Como o Cross-Cloud Network foi projetado para ser o hub de todas as comunicações, é possível unificar e centralizar os controles de segurança do perímetro e implantar um único conjunto de firewalls de perímetro no seu Cross-Cloud Network. Para oferecer uma pilha de segurança de perímetro integrada de escolha, o Cross-Cloud Network oferece opções flexíveis para inserir NVAs.
Nos designs mostrados nos diagramas, é possível implantar NVAs de terceiros na VPC de trânsito no projeto hub.
Os NVAs podem ser implantados em uma única interface de rede (modo de NIC única) ou em várias interfaces de rede em várias VPCs (modo multi-NIC). Para o Cross-Cloud Network, recomendamos uma implantação de NIC única para NVAs, porque essa opção permite fazer o seguinte:
- Inserir os NVAs com rotas baseadas em política.
- Evite criar topologias rígidas.
- Implante em várias topologias entre VPCs.
- Ative o escalonamento automático para os NVAs.
- Escalone para várias VPCs ao longo do tempo, sem precisar alterar a implantação da interface do NVA.
Se o projeto exigir várias NICs, as recomendações estão detalhadas em Segurança do perímetro de NVA de multi-NIC.
Para realizar o direcionamento de tráfego necessário para a implantação do NVA, este guia recomenda a aplicação seletiva de rotas estáticas e com base em políticas nas tabelas de roteamento de VPC. As rotas com base em políticas são mais flexíveis do que as padrão porque as rotas com base em políticas correspondem às informações de origem e destino. Essas rotas com base em políticas também são aplicadas apenas em locais específicos na topologia de rede da nuvem. Essa granularidade permite a definição de um comportamento de direcionamento de tráfego muito específico para fluxos de conectividade muito específicos.
Além disso, esse design possibilita os mecanismos de resiliência exigidos pelos NVAs. Os NVAs são liderados por um balanceador de carga TCP/UDP interno para permitir redundância de NVA, escalonamento automático para capacidade elástica e simetria de fluxo para oferecer suporte ao processamento de tráfego bidirecional com estado.
Segurança de perímetro de NVA de NIC única
No design descrito em Conectividade entre VPCs para serviços centralizados, a VPC de trânsito atua como um hub para as VPCs spoke conectadas usando a rede VPC Peering e VPN de alta disponibilidade. A VPC de trânsito também permite conectividade entre as redes externas e as VPCs spoke.
Para fins de inserção de NVA de NIC única, este design combina os dois padrões a seguir:
- Inserir NVAs em um hub de peering de rede VPC com conexões híbridas externas
- Inserir NVAs em um hub VPC de VPN de alta disponibilidade com conexões híbridas externas
O diagrama a seguir mostra NVAs inseridos nos hubs para peering de rede VPC e VPN de alta disponibilidade:
O diagrama anterior ilustra um padrão combinado:
- Uma VPC de trânsito que hospeda os anexos da VLAN do Cloud Interconnect que fornecem conectividade híbrida ou de várias nuvens. Essa VPC também contém os NVAs de NIC única que monitoram as conexões híbridas.
- VPCs de aplicativo conectadas à VPC de trânsito por peering de rede VPC.
- VPC de serviços centrais conectada à VPC de trânsito pela VPN de alta disponibilidade.
Neste design, os spokes conectados usando a VPN de alta disponibilidade usam a VPC de trânsito para se comunicar com os spokes conectados pelo peering de rede VPC. A comunicação é direcionada pelos firewalls de NVA de terceiros usando a seguinte combinação de balanceamento de carga de passagem, rotas estáticas e rotas baseadas em políticas:
- Para direcionar o tráfego da VPN de alta disponibilidade para o balanceador de carga interno, aplique rotas com base em políticas sem tags à VPC do Google Transit. Nestes roteamentos com base na política, use intervalos CIDR de origem e destino que forneçam simetria de tráfego.
- Para direcionar o tráfego de entrada para o balanceador de carga de rede de passagem interna, aplique rotas com base em políticas às conexões do Cloud Interconnect na VPC de trânsito. Essas rotas são regionais.
- Para que o tráfego que sai do NVA não seja roteado diretamente de volta para o NVA, torne todas as interfaces do NVA o destino de uma rota com base em política de ignorar para ignorar outras rotas com base em política. Em seguida, o tráfego segue a tabela de roteamento de VPC depois de ser processado pelos NVAs.
- Para direcionar o tráfego para os balanceadores de carga internos do NVA na VPC de trânsito, aplique rotas estáticas às VPCs do aplicativo. O escopo pode ser definido regionalmente usando tags de rede.
Segurança de perímetro de NVA de multi-NIC
No modo multi-NIC, a topologia é mais estática porque os NVAs vinculam a conectividade entre as diferentes VPCs em que as diferentes interfaces de rede residem.
Quando zonas baseadas em interface são necessárias em um firewall, o design com várias NICs a seguir ativa a conectividade externa necessária. Esse design atribui interfaces de firewall diferentes às redes externas. As redes externas são chamadas por profissionais de segurança de redes não confiáveis e as internas são conhecidas como redes confiáveis. Para a implantação do NVA com várias NICs, esse design é implementado usando VPCs confiáveis e não confiáveis.
Nas comunicações internas, o firewall pode ser aplicado usando um modelo de inserção de NIC única que corresponde a um modelo de zona baseado em CIDR.
Neste projeto, você insere NVAs configurando o seguinte:
- Para direcionar o tráfego da VPN de alta disponibilidade para o balanceador de carga interno, aplique rotas com base em políticas sem tags à VPC confiável. Nestes roteamentos com base na política, use intervalos CIDR de origem e destino que forneçam simetria de tráfego.
- Para direcionar o tráfego de entrada para o balanceador de carga de rede de passagem interna, aplique rotas com base em políticas às conexões do Cloud Interconnect na VPC não confiável. Essas rotas são regionais.
- Para que o tráfego que sai do NVA não seja roteado diretamente de volta para o NVA, torne todas as interfaces do NVA o destino de uma rota com base em política de ignorar para ignorar outras rotas com base em política. Em seguida, o tráfego segue a tabela de roteamento de VPC depois de ser processado pelos NVAs.
- Para direcionar o tráfego aos balanceadores de carga internos do NVA na VPC confiável, aplique rotas estáticas às VPCs do aplicativo. O escopo pode ser definido regionalmente usando tags de rede.
O diagrama a seguir mostra NVAs multi-NIC inseridos entre as redes VPC não confiáveis e confiáveis no projeto hub:
A seguir
- Saiba mais sobre os produtos do Google Cloud usados neste guia de design:
- Para informações sobre como implantar NVAs de firewall, consulte Dispositivos de rede centralizados no Google Cloud.
- Para mais arquiteturas de referência, guias de design e práticas recomendadas, confira o Centro de arquitetura do Cloud.
Colaboradores
Autores:
- Victor Moreno | Gerente de produtos, Cloud Networking
- Ghaleb Al-habian | Especialista em rede
- Deepak Michael | Engenheiro de clientes especialista em rede
- Osvaldo Costa | Engenheiro de clientes especialista em rede
- Jonathan Almaleh | Consultor de soluções técnicas da equipe
Outros colaboradores:
- Zach Seils | Especialista em rede
- Christopher Abraham | Engenheiro de clientes especialista em rede
- Emanuele Mazza | Especialista em produtos de rede
- Aurélien Legrand | Engenheiro de nuvem estratégico
- Eric Yu | Engenheiro de clientes especialista em rede
- Kumar Dhanagopal | Desenvolvedor de soluções para vários produtos
- Mark Schlagenhauf | Redator técnico, Rede
- Marwan Al Shawi | Engenheiro de clientes do parceiro
- Ammett Williams | Engenheiro de relações com desenvolvedores