Elaborar 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: Um constructo de alto nível, que fornece separação alimentada por plataforma entre entidades. Ele destina-se a esculpir limites entre grandes organizações dentro de uma empresa e a comunicação entre recursos em assinaturas diferentes precisa ser explicitamente provisionada.
2. Rede Virtual (VNets): Criado em uma assinatura em espaços de endereço privados. Eles fornecem a contenção de recursos no nível de rede sem tráfego permitido por padrão entre duas redes virtuais. Assim como as assinaturas, qualquer comunicação entre redes virtuais precisa ser explicitamente provisionada.
3. NSG (Grupos de Segurança de Rede): mecanismos de controle de acesso para controlar o tráfego entre recursos em 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. ASGs (Grupos de Segurança do Aplicativo): semelhantes aos NSGs, mas são referenciados com um contexto de aplicativo. Ele permite que você agrupe um conjunto de VMs em uma marca de aplicativo e defina regras de tráfego que são aplicadas a cada uma das VMs subjacentes.
5. Firewall do Azure: um firewall com estado nativo de nuvem como um serviço, que pode ser implantado em sua VNet ou em implantações do hub wan virtual do Azure para filtrar o tráfego que flui entre recursos de nuvem, internet e local. Você cria regras ou políticas (usando o Firewall do Azure ou o Gerenciador de Firewall do Azure) especificando o tráfego de permissão/negação usando controles de camada 3 a camada 7. Você também pode filtrar o tráfego que vai para a Internet usando o Firewall do Azure e terceiros direcionando parte ou todo o tráfego por meio de provedores de segurança de terceiros para filtragem avançada e proteção do usuário.

Padrões de segmentação

Aqui estão alguns padrões comuns para segmentar uma carga de trabalho no Azure de uma perspectiva 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 única

Todos os componentes da carga de trabalho residem em uma única VNet. Esse padrão é apropriado que você esteja 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 NVAs (Dispositivo Virtualizado de Rede) 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. A sub-rede2 tem as cargas de trabalho da Web. Você pode configurar NSGs que permitem que a Sub-rede1 se comunique apenas com a Sub-rede2 e a Sub-rede2 só pode se comunicar com a Internet.

Considere um caso de uso em que você tenha 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 VNets que se comunicam com o emparelhamento

Os recursos são distribuídos ou replicados em várias VNets. As VNets podem se comunicar por meio do 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 com 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 VNets em um modelo de hub e spoke

Uma VNet é designada como um hub em uma determinada região para todas as outras VNets como spokes nessa região. O hub e seus spokes estão conectados por meio do emparelhamento. Todo o tráfego passa pelo hub que pode atuar como um gateway para outros hubs em regiões diferentes. 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 escalonável. Um benefício desse padrão é que, à medida que a topologia de rede cresce, a sobrecarga da postura de segurança não aumenta (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 os fluxos de tráfego usando controles de camada 3 a 7. Você pode definir suas regras de comunicação e aplicá-las consistentemente. Aqui estão 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 acessar a Internet pública, exceto por *.github.com.

Com a versão prévia do Gerenciador de Firewall do Azure, você pode gerenciar centralmente as políticas em vários Firewalls do Azure e habilitar as equipes do DevOps para personalizar 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 spoke. Um roteador de camada 3, como o Firewall do Azure, no hub é necessário para habilitar a conectividade.
Filtragem de tráfego no 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 spoke é negado por padrão. Abra caminhos selecionados para permitir o tráfego por meio da configuração do Firewall do Azure.
Registro em log centralizado	Logs NSG, ASG para a rede virtual.	Agregar logs NSG, 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 de extremidade públicos não intencionais abertos	O DevOps pode abrir acidentalmente um ponto de extremidade público por meio de regras NSG, ASG incorretas.	O mesmo que um padrão 1.	O ponto de extremidade público aberto acidentalmente em um spoke não habilitará o acesso porque o pacote de retorno será removido por meio de firewall com estado (roteamento assimétrico).
Proteção de nível de aplicativo	O NSG ou ASG fornece suporte somente à camada de rede.	O mesmo que o padrão 1.	O Firewall do Azure dá suporte à filtragem de FQDN para HTTP/S e MSSQL para tráfego de saída e entre redes virtuais.