Projetar soluções para segmentação de rede

Concluído

Recursos do Azure para segmentação

Ao operar no Azure, você tem muitas opções de segmentação.

1. Assinatura: uma construção de alto nível, que fornece separação alimentada por plataforma entre entidades. Destina-se a estabelecer limites entre grandes organizações dentro de uma empresa e a comunicação entre recursos em diferentes assinaturas precisa ser explicitamente provisionada.
2. Rede Virtual (VNets): criada dentro de uma assinatura em espaços de endereço privados. Eles fornecem contenção de recursos no nível de rede sem tráfego permitido por padrão entre quaisquer duas redes virtuais. Como as assinaturas, qualquer comunicação entre redes virtuais precisa ser explicitamente provisionada.
3. Grupos de Segurança de Rede (NSG): Um mecanismo de controle de acesso para controlar o tráfego entre recursos dentro de uma rede virtual e também com redes externas, como a internet, outras redes virtuais. Os NSGs podem levar sua estratégia de segmentação a um nível granular criando perímetros para uma sub-rede, uma VM ou um grupo de VMs. Para obter informações sobre possíveis operações com sub-redes no Azure, consulte Sub-redes (Redes Virtuais do Azure).
4. Grupos de segurança de aplicativos (ASGs): semelhantes aos NSGs, mas são referenciados com um contexto de aplicativo. Ele permite agrupar um conjunto de VMs em uma marca de aplicativo e definir regras de tráfego que são aplicadas a cada uma das VMs subjacentes.
5. Firewall do Azure: um Firewall como serviço stateful nativo da nuvem, que pode ser implantado em sua VNet ou em implantações de hub WAN Virtual do Azure para filtrar o tráfego que flui entre recursos de nuvem, a Internet e no local. Você cria regras ou políticas (usando o Firewall do Azure ou o Gerenciador de Firewall do Azure) especificando permitir/negar tráfego usando controles de camada 3 a camada 7. Também pode filtrar o tráfego que vai para a Internet utilizando a Firewall do Azure e terceiros, direcionando parte ou todo o tráfego através de fornecedores de segurança de terceiros para filtragem avançada e proteção do utilizador.

Padrões de segmentação

Aqui estão alguns padrões comuns para segmentar uma carga de trabalho no Azure de uma perspetiva de rede. Cada padrão fornece um tipo diferente de isolamento e conectividade. Escolha um padrão com base nas necessidades da sua organização.

Padrão 1: VNet único

Todos os componentes da carga de trabalho residem em uma única VNet. Esse padrão é apropriado para você estar operando em uma única região porque uma VNet não pode abranger várias regiões.

Maneiras comuns de proteger segmentos, como sub-redes ou grupos de aplicativos, são usando NSGs e ASGs. Você também pode usar um Network Virtualized Appliance (NVAs) do Azure Marketplace ou do Firewall do Azure para impor e proteger essa segmentação.

Nesta imagem, Subnet1 tem a carga de trabalho do banco de dados. Subnet2 tem as cargas de trabalho da web. Você pode configurar NSGs que permitem que a Subnet1 se comunique apenas com a Subnet2 e a Subnet2 só pode se comunicar com a Internet.

Considere um caso de uso em que você tem várias cargas de trabalho que são colocadas em sub-redes separadas. Você pode colocar controles que permitirão que uma carga de trabalho se comunique com o back-end de outra carga de trabalho.

Padrão 2: Várias redes virtuais que se comunicam com emparelhamento

Os recursos são distribuídos ou replicados em várias VNets. As redes virtuais podem se comunicar por meio de emparelhamento. Esse padrão é apropriado quando você precisa agrupar aplicativos em VNets separadas. Ou, você precisa de várias regiões do Azure. Um benefício é a segmentação interna porque você precisa emparelhar explicitamente uma VNet para outra. O emparelhamento de rede virtual não é transitivo. Você pode segmentar ainda mais dentro de uma VNet usando NSGs e ASGs, conforme mostrado no padrão 1.

Padrão 3: Várias redes virtuais em um modelo de hub e spoke

Uma VNet é designada como um hub em uma determinada região para todas as outras VNets como porta-vozes nessa região. O hub e seus raios são conectados através de peering. Todo o tráfego passa pelo hub que pode atuar como um gateway para outros hubs em diferentes regiões. Nesse padrão, os controles de segurança são configurados nos hubs para que eles possam segmentar e controlar o tráfego entre outras VNets de forma escalável. Um benefício desse padrão é que, à medida que sua topologia de rede cresce, a sobrecarga da postura de segurança não cresce (exceto quando você expande para novas regiões).

A opção nativa recomendada é o Firewall do Azure. Essa opção funciona em VNets e assinaturas para controlar fluxos de tráfego usando controles de camada 3 a camada 7. Você pode definir suas regras de comunicação e aplicá-las de forma consistente. Seguem-se alguns exemplos:

• A VNet 1 não pode se comunicar com a VNet 2, mas pode comunicar a VNet 3.
• A VNet 1 não pode aceder à Internet pública, exceto para *.github.com.

Com a visualização do Gerenciador de Firewall do Azure, você pode gerenciar centralmente políticas em vários Firewalls do Azure e permitir que as equipes de DevOps personalizem ainda mais as políticas locais.

Comparação de padrões

Considerações	Padrão 1	Padrão 2	Padrão 3
Conectividade/roteamento: como cada segmento se comunica entre si	O roteamento do sistema fornece conectividade padrão para qualquer carga de trabalho em qualquer sub-rede.	O mesmo que um padrão 1.	Nenhuma conectividade padrão entre redes faladas. Um roteador de camada 3, como o Firewall do Azure, no hub é necessário para habilitar a conectividade.
Filtragem de tráfego ao nível da rede	O tráfego é permitido por padrão. Use NSG, ASG para filtrar o tráfego.	O mesmo que um padrão 1.	O tráfego entre redes virtuais faladas é negado por padrão. Abra os caminhos selecionados para permitir o tráfego por meio da configuração do Firewall do Azure.
Registo centralizado	NSG, logs ASG para a rede virtual.	Agregar logs NSG e ASG em todas as redes virtuais.	O Firewall do Azure registra todo o tráfego aceito/negado enviado pelo hub. Exiba os logs no Azure Monitor.
Pontos finais públicos abertos não intencionais	O DevOps pode abrir acidentalmente um ponto de extremidade público por meio de regras NSG e ASG incorretas.	O mesmo que um padrão 1.	O ponto de extremidade público aberto acidentalmente em um spoke não permitirá o acesso porque o pacote de retorno será descartado através do firewall stateful (roteamento assimétrico).
Proteção ao nível da aplicação	NSG ou ASG fornece suporte apenas à camada de rede.	O mesmo que um padrão 1.	O Firewall do Azure dá suporte à filtragem FQDN para HTTP/S e MSSQL para tráfego de saída e em redes virtuais.