Elaborar soluções para segmentação de rede
Recursos do Azure para segmentação
Quando opera no Azure, você tem muitas opções de segmentação.
- Assinatura: um constructo de alto nível que separa as entidades de acordo com a plataforma. Tem a finalidade de definir limites entre as grandes organizações de uma empresa, e a comunicação entre recursos em assinaturas diferentes precisa ser provisionada explicitamente.
- VNets (Redes Virtuais): criadas em uma assinatura em espaços de endereço privados. Fornecem contenção de recursos no nível da rede sem tráfego permitido por padrão entre duas redes virtuais. Assim como as assinaturas, qualquer comunicação entre redes virtuais precisa ser provisionada explicitamente.
- NSGs (Grupos de Segurança de Rede): um mecanismo de controle de acesso para controlar o tráfego entre os recursos em uma rede virtual e também com redes externas, como a Internet e outras redes virtuais. Os NSGs podem levar a 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 as operações possíveis com as sub-redes no Azure, confira Sub-redes (Redes Virtuais do Azure).
- ASGs (Grupos de Segurança de Aplicativo): semelhantes aos NSGs, mas no contexto do aplicativo. Permitem agrupar um conjunto de VMs com uma marca de aplicativo e definir regras de tráfego que são aplicadas a cada uma das VMs subjacentes.
- Firewall do Azure: um Firewall como serviço, com estado e nativo de nuvem que pode ser implantado em sua VNet ou em implantações de hub da WAN Virtual do Azure para filtrar o tráfego que flui entre os recursos de nuvem, a Internet e os locais. Você cria regras ou políticas (usando o Firewall do Azure ou o Gerenciador de firewall do Azure) especificando o tráfego de permitir/negar usando os controles de camada 3 a camada 7. Você também pode filtrar o tráfego que vai para a internet usando tanto o Firewall do Azure quanto de terceiros ao direcionar parte ou todo o tráfego por meio de provedores de segurança de terceiros para uma filtragem avançada e proteção do usuário.
Padrões de segmentação
Conheça alguns padrões comuns para segmentar uma carga de trabalho no Azure da perspectiva da rede. Cada padrão fornece um tipo diferente de isolamento e conectividade. Escolha um deles com base nas necessidades da organização.
Padrão 1: VNet única
Todos os componentes da carga de trabalho residem em uma só VNet. Esse padrão é apropriado quando você está operando em uma só região porque uma VNet não pode abranger várias regiões.
Usar NSGs e ASGs são maneiras comuns de proteger os segmentos, como sub-redes ou grupos de aplicativos. Você também pode usar uma NVA (Solução de virtualização de rede) do Azure Marketplace ou o Firewall do Azure para impor e proteger essa segmentação.
Nesta imagem, a Sub-rede 1 tem a carga de trabalho de banco de dados. A Sub-rede2 tem as cargas de trabalho da Web. Você pode configurar NSGs que permitam que a Sub-rede 1 se comunique apenas com a Sub-rede 2 e a Sub-rede 2 se comunique apenas com a Internet.
Considere um caso de uso em que você tem várias cargas de trabalho em sub-redes separadas. Você pode definir 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 por emparelhamento
Os recursos são distribuídos ou replicados em várias VNets. As VNets podem se comunicar por emparelhamento. Esse padrão é apropriado quando você precisa agrupar aplicativos em VNets separadas. Ou quando 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 em uma VNet usando NSGs e ASGs, conforme mostrado no padrão 1.
Padrão 3: várias VNets em um modelo hub e spoke
Uma VNet é designada como um hub em uma determinada região para todas as outras VNets que são spokes nessa região. O hub e seus spokes são conectados por 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 definidos nos hubs para que eles segmentem e controlem o tráfego entre outras VNets de maneira 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. Ele funciona em VNets e assinaturas para controlar fluxos de tráfego usando controles de camada 3 a 7. Você pode definir as regras de comunicação e aplicá-las de modo consistente. Estes sã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 políticas centralmente entre vários Firewalls do Azure e habilitar as equipes de DevOps a personalizarem 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 as redes spoke. Um roteador de camada 3, como o Firewall do Azure, é necessário no hub para habilitar a conectividade. |
Filtragem de tráfego no nível da rede | O tráfego é permitido por padrão. Usar NSG e ASG para filtrar o tráfego. | O mesmo que um padrão 1. | O tráfego entre redes virtuais spoke é negado por padrão. Abrir os caminhos selecionados para permitir o tráfego por meio da configuração do Firewall do Azure. |
Registro em log centralizado | Logs de NSG e ASG para a rede virtual. | Agregar logs do NSG e ASG em todas as redes virtuais. | O Firewall do Azure registra todo o tráfego aceito/negado enviado pelo hub. Veja 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 incorretas de NSG e ASG. | 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 do firewall com estado (roteamento assimétrico). |
Proteção de nível de aplicativo | O NSG ou ASG dá suporte apenas à camada de rede. | O mesmo que um 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. |