Este documento faz parte de uma série de guias de design para a rede entre nuvens. Esta parte explora a camada de segurança da rede.
A série é composta pelas seguintes partes:
- Rede entre nuvens para aplicações distribuídas
- Segmentação de rede e conetividade para aplicações distribuídas na rede entre nuvens
- Redes de serviços para aplicações distribuídas na rede entre clouds
- Segurança de rede para aplicações distribuídas na rede entre nuvens (este documento)
Superfícies de segurança
Quando cria a camada de segurança para a rede entre nuvens, tem de considerar as seguintes superfícies de segurança:
- Segurança da carga de trabalho
- Segurança do perímetro do domínio
A segurança da carga de trabalho controla a comunicação entre cargas de trabalho em toda a nuvem virtual privada (VPC) e dentro desta. A segurança de cargas de trabalho usa pontos de aplicação de segurança próximos das cargas de trabalho na arquitetura. Sempre que possível, a rede entre nuvens oferece segurança de cargas de trabalho através da utilização do firewall de nova geração do Google Cloud Google Cloud.
A segurança perimetral é obrigatória em todos os limites da rede. Uma vez que o perímetro interliga normalmente redes geridas por diferentes organizações, são frequentemente necessários controlos de segurança mais rigorosos. Tem de garantir que as seguintes comunicações entre redes estão seguras:
- Comunicações entre VPCs
- Comunicações através de ligações híbridas a outros fornecedores de nuvem ou centros de dados nas instalações
- Comunicações para a Internet
A capacidade de inserir dispositivos virtuais (NVAs) de rede de terceiros no ambienteGoogle Cloud é fundamental para satisfazer os requisitos de segurança do perímetro em ligações híbridas.
Segurança de cargas de trabalho na nuvem
Use políticas de firewall no Google Cloud para proteger cargas de trabalho e fornecer capacidades de firewall com estado que são horizontalmente escaláveis e aplicadas a cada instância de VM. A natureza distribuída das firewalls ajuda a implementar políticas de segurança para a microsegmentação de rede sem afetar negativamente o desempenho das suas cargas de trabalho. Google Cloud
Use políticas de firewall hierárquicas para
melhorar a capacidade de gestão e aplicar a conformidade da postura para as suas
políticas de firewall. As políticas de firewall hierárquicas permitem-lhe criar e aplicar uma política de firewall consistente em toda a sua organização. Pode atribuir políticas de firewall hierárquicas à organização ou a pastas individuais.
Além disso, as regras das políticas de firewall hierárquicas podem delegar a avaliação em 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 podem substituir uma regra de um nível superior na hierarquia de recursos. Esta estrutura de regras permite que os administradores de toda a organização façam a gestão de regras de firewall obrigatórias num único local. Os exemplos de utilização comuns das políticas de firewall hierárquicas incluem o acesso de anfitriões bastion de vários projetos ou da organização, a permissão de sistemas de sondagem ou verificação de estado centralizados e a aplicação de um limite de rede virtual numa organização ou num grupo de projetos. Para ver exemplos adicionais de utilização de políticas de firewall hierárquicas, consulte os exemplos de políticas de firewall hierárquicas.
Use políticas de firewall de rede globais e regionais para definir regras com base numa rede de VPC individual, quer para todas as regiões da rede (global) quer para uma única região (regional).
Para alcançar controlos mais detalhados aplicados ao nível da máquina virtual (VM), recomendamos que use etiquetas regidas pela gestão de identidade e acesso (IAM) ao nível da organização ou do projeto. As etiquetas regidas pela IAM permitem aplicar regras de firewall com base na identidade do anfitrião da carga de trabalho, em vez do endereço IP do anfitrião, e funcionam no peering de rede VPC. As regras de firewall implementadas através de etiquetas podem fornecer microsegmentação intrasub-rede com cobertura de políticas que se aplica automaticamente às cargas de trabalho onde quer que sejam implementadas, independentemente da arquitetura de rede.
Além das capacidades de inspeção com estado e do suporte de etiquetas, o firewall de nova geração do Google Cloud também suporta inteligência contra ameaças, FQDN e filtragem de geolocalização.
Recomendamos que migre das regras de firewall da VPC para as políticas de firewall. Para ajudar com a migração, use a ferramenta de migração, que cria uma política de firewall de rede global e converte as regras de firewall da VPC existentes na nova política.
Segurança de perímetro na nuvem
Num ambiente de rede multicloud, a segurança do perímetro é normalmente implementada em cada rede. Por exemplo, a rede no local tem o seu próprio conjunto de firewalls de perímetro, enquanto cada rede na nuvem implementa firewalls de perímetro separados.
Uma vez que a rede entre nuvens foi concebida para ser o hub de todas as comunicações, pode unificar e centralizar os controlos de segurança do perímetro e implementar um único conjunto de firewalls de perímetro na sua rede entre nuvens. Para oferecer uma pilha de segurança de perímetro integrada à sua escolha, a rede entre nuvens oferece opções flexíveis para inserir NVAs.
Nos designs apresentados nos diagramas, pode implementar NVAs de terceiros na VPC de trânsito no projeto do hub.
As NVAs podem ser implementadas através de uma única interface de rede (modo de NIC único) ou de várias interfaces de rede em várias VPCs (modo de NIC múltiplo). Para a rede entre nuvens, recomendamos uma implementação de NIC único para NVAs, porque esta opção permite-lhe fazer o seguinte:
- Insira os NVAs com rotas baseadas em políticas.
- Evite criar topologias rígidas.
- Implemente numa variedade de topologias entre VPCs.
- Ative o dimensionamento automático para as NVAs.
- Escale para muitas VPCs ao longo do tempo, sem alterações necessárias à implementação da interface do NVA.
Se o seu design exigir várias NICs, as recomendações são detalhadas no artigo Segurança do perímetro da NVA com várias NICs.
Para realizar o encaminhamento de tráfego necessário para a implementação da NVA, este guia recomenda a aplicação seletiva de rotas estáticas e baseadas em políticas nas tabelas de encaminhamento da VPC. Os encaminhamentos baseados em políticas são mais flexíveis do que os encaminhamentos padrão, porque os encaminhamentos baseados em políticas correspondem às informações de origem e destino. Estas rotas baseadas em políticas também são aplicadas apenas em locais específicos na topologia da rede na nuvem. Este nível de detalhe permite a definição de um comportamento de encaminhamento de tráfego muito específico para fluxos de conetividade muito específicos.
Além disso, este design permite os mecanismos de resiliência exigidos pelas NVAs. As NVAs são apresentadas por um balanceador de carga de TCP/UDP interno para ativar a redundância da NVA, o dimensionamento automático para capacidade elástica e a simetria de fluxo para suportar o processamento de tráfego bidirecional com estado.
Segurança de perímetro de NVA com uma única NIC
No design descrito em Conetividade entre VPCs para serviços centralizados, a VPC de trânsito funciona como um hub para as VPCs spoke que estão ligadas através do peering de redes VPC e da VPN de alta disponibilidade. A VPC de trânsito também permite a conetividade entre as redes externas e as VPCs spoke.
Para efeitos da inserção de NVAs com uma única NIC, este design combina os seguintes dois padrões:
- Insira NVAs num hub de intercâmbio da rede da VPC com ligações híbridas externas
- Insira NVAs num hub de VPC de VPN de HA com ligações híbridas externas
O diagrama seguinte mostra NVAs inseridas nos hubs para intercâmbio da rede da VPC e VPN de alta disponibilidade:
O diagrama anterior ilustra um padrão combinado:
- Uma VPC de trânsito que aloja as associações de VLAN do Cloud Interconnect que fornecem conetividade híbrida ou de várias nuvens. Esta VPC também contém as NVAs de NIC único que monitorizam as ligações híbridas.
- VPCs de aplicações ligadas à VPC de trânsito através do intercâmbio da rede da VPC.
- Uma VPC de serviços central ligada à VPC de trânsito através de uma VPN de HA.
Neste design, os raios ligados através da VPN de alta disponibilidade usam a VPC de trânsito para comunicar com os raios ligados através do intercâmbio das redes da VPC. A comunicação é encaminhada através das firewalls da 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 baseadas em políticas não etiquetadas à VPC de trânsito. Nestas rotas baseadas em políticas, use intervalos CIDR de origem e destino que proporcionem simetria de tráfego.
- Para direcionar o tráfego de entrada para o Network Load Balancer de passagem interno, aplique rotas baseadas em políticas às ligações do Cloud Interconnect na VPC de trânsito. Estes são trajetos regionais.
- Para que o tráfego que sai da NVA não seja encaminhado diretamente de volta para a NVA, torne todas as interfaces da NVA o destino de uma rota baseada em políticas de ignorar para ignorar outras rotas baseadas em políticas. Em seguida, o tráfego segue a tabela de encaminhamento da VPC assim que for processado pelas NVAs.
- Para direcionar o tráfego para os balanceadores de carga internos da NVA na VPC de trânsito, aplique rotas estáticas às VPCs de aplicações. Estas podem ser definidas ao nível regional através de etiquetas de rede.
Segurança do perímetro da NVA com várias NICs
No modo multi-NIC, a topologia é mais estática porque as NVAs estabelecem uma ponte entre a conetividade das diferentes VPCs nas quais residem as diferentes interfaces de rede.
Quando são necessárias zonas baseadas em interfaces numa firewall, a seguinte conceção com várias NICs permite a conetividade externa necessária. Este design atribui diferentes interfaces de firewall às redes externas. As redes externas são denominadas redes não fidedignas pelos profissionais de segurança, e as redes internas são conhecidas como redes fidedignas. Para a implementação de NVA com vários NICs, esta arquitetura é implementada usando VPCs fidedignas e não fidedignas.
Para comunicações internas, é possível aplicar firewalls através de um modelo de inserção de uma única NIC que corresponda a um modelo de zona baseado em CIDR.
Neste design, insere NVAs configurando o seguinte:
- Para direcionar o tráfego da VPN de alta disponibilidade para o balanceador de carga interno, aplique rotas baseadas em políticas não etiquetadas à VPC fidedigna. Nestas rotas baseadas em políticas, use intervalos CIDR de origem e destino que proporcionem simetria de tráfego.
- Para direcionar o tráfego de entrada para o balanceador de carga de rede de passagem interno, aplique rotas baseadas em políticas às ligações do Cloud Interconnect na VPC não fidedigna. Estes são trajetos regionais.
- Para que o tráfego que sai da NVA não seja encaminhado diretamente de volta para a NVA, torne todas as interfaces da NVA o destino de uma rota baseada em políticas de ignorar para ignorar outras rotas baseadas em políticas. Em seguida, o tráfego segue a tabela de encaminhamento da VPC assim que for processado pelas NVAs.
- Para direcionar o tráfego para os balanceadores de carga internos da NVA na VPC fidedigna, aplique rotas estáticas às VPCs da aplicação. Estas podem ser definidas ao nível regional através de etiquetas de rede.
O diagrama seguinte mostra NVAs com várias NICs inseridas entre as redes da VPC não fidedignas e fidedignas no projeto do hub:
O que se segue?
- Saiba mais sobre os Google Cloud produtos usados neste guia de design:
- Para ver mais arquiteturas de referência, guias de design e práticas recomendadas, explore o Centro de arquitetura na nuvem.
Colaboradores
Autores:
- Victor Moreno | Gestor de produtos, redes na nuvem
- Ghaleb Al-habian | Especialista em redes
- Deepak Michael | Customer Engineer especialista em redes
- Osvaldo Costa | Customer Engineer especialista em redes
- Jonathan Almaleh | Staff Technical Solutions Consultant
Outros colaboradores:
- Zach Seils | Especialista em redes
- Christopher Abraham | Networking Specialist Customer Engineer
- Emanuele Mazza | Especialista em produtos de rede
- Aurélien Legrand | Strategic Cloud Engineer
- Eric Yu | Customer Engineer especialista em redes
- Kumar Dhanagopal | Cross-Product Solution Developer
- Mark Schlagenhauf | Redator técnico, redes
- Marwan Al Shawi | Partner Customer Engineer
- Ammett Williams | Developer Relations Engineer