Planejar a segmentação da rede da zona de pouso
Esta seção explora as principais recomendações para oferecer segmentação de rede interna altamente segura dentro de uma zona de aterrissagem para impulsionar uma implementação de Zero Trust de rede.
Considerações de design
O modelo Zero Trust assume um estado violado e verifica cada solicitação como se fosse originária de uma rede não controlada.
Uma implementação avançada de rede Zero Trust emprega microperímetros de entrada e saída de nuvem totalmente distribuídos e microssegmentação mais profunda.
Os NSGs (grupos de segurança de rede) podem usar marcas de serviço do Azure para facilitar a conectividade com soluções de plataforma como serviço (PaaS) do Azure.
Os grupos de segurança de aplicativos (ASGs) não abrangem nem fornecem proteção em redes virtuais.
Use os logs de fluxo do NSG para inspecionar o tráfego que flui através de um ponto de rede com um NSG conectado.
Os logs de fluxo de rede virtual fornecem recursos semelhantes aos logs de fluxo NSG, mas abrangem uma gama mais ampla de casos de uso. Eles também simplificam o escopo do monitoramento de tráfego porque você pode habilitar o registro em log no nível da rede virtual.
Recomendações de design
Delegue a criação de sub-redes ao proprietário da zona de destino. Isso permitirá que eles definam como segmentar cargas de trabalho entre sub-redes (por exemplo, uma única sub-rede grande, aplicativo multicamada ou aplicativo injetado em rede). A equipe da plataforma pode usar a Política do Azure para garantir que um NSG com regras específicas (como negar SSH ou RDP de entrada da Internet ou permitir/bloquear tráfego em zonas de aterrissagem) esteja sempre associado a sub-redes que tenham políticas somente de negação.
Use NSGs para ajudar a proteger o tráfego entre sub-redes, bem como o tráfego leste/oeste na plataforma (tráfego entre zonas de pouso).
A equipe do aplicativo deve usar grupos de segurança de aplicativos nos NSGs de nível de sub-rede para ajudar a proteger VMs de várias camadas dentro da zona de aterrissagem.
Use NSGs e grupos de segurança de aplicativos para microsegmentar o tráfego dentro da zona de aterrissagem e evite usar um NVA central para filtrar fluxos de tráfego.
Habilite logs de fluxo de rede virtual e use a análise de tráfego para obter informações sobre os fluxos de tráfego de entrada e saída. Habilite logs de fluxo em todas as redes virtuais e sub-redes críticas em suas assinaturas, por exemplo, redes virtuais e sub-redes que contenham controladores de domínio do Ative Directory do Windows Server ou armazenamentos de dados críticos. Além disso, você pode usar logs de fluxo para detetar e investigar possíveis incidentes de segurança, conformidade e monitoramento, além de otimizar o uso.
Use NSGs para permitir seletivamente a conectividade entre zonas de pouso.
Para topologias de WAN Virtual, roteie o tráfego entre zonas de aterrissagem por meio do Firewall do Azure se sua organização precisar de recursos de filtragem e registro em log para o tráfego que flui entre zonas de aterrissagem.
Se sua organização decidir implementar o túnel forçado (anunciar rota padrão) no local, recomendamos incorporar as seguintes regras NSG de saída para negar o tráfego de saída de VNets diretamente para a Internet caso a sessão BGP caia.
Nota
As prioridades das regras precisarão ser ajustadas com base no conjunto de regras NSG existente.
| Prioridade | Nome | Origem | Destino | Serviço | Ação | Observação |
|---|---|---|---|---|---|---|
| 100 | AllowLocal |
Any |
VirtualNetwork |
Any |
Allow |
Permitir o tráfego durante as operações normais. Com o túnel forçado habilitado, 0.0.0.0/0 é considerado parte da tag desde que o VirtualNetwork BGP esteja anunciando-o para o ExpressRoute ou VPN Gateway. |
| 110 | DenyInternet |
Any |
Internet |
Any |
Deny |
Negar tráfego diretamente para a Internet se a 0.0.0.0/0 rota for retirada das rotas anunciadas (por exemplo, devido a uma interrupção ou configuração incorreta). |
Atenção
Os serviços PaaS do Azure que podem ser injetados em uma rede virtual talvez não sejam compatíveis com o túnel forçado. As operações do plano de controle ainda podem exigir conectividade direta com endereços IP públicos específicos para que o serviço funcione corretamente. É recomendável verificar a documentação de serviço específica para requisitos de rede e, eventualmente, isentar a sub-rede de serviço da propagação de rota padrão. As etiquetas de serviço no UDR podem ser usadas para ignorar a rota padrão e redirecionar o tráfego do plano de controle somente se a etiqueta de serviço específica estiver disponível.