Um grupo de segurança de rede (ou NSG – Network Security Group) contém regras de segurança que permitem ou negam o tráfego de rede de entrada ou de saída em relação a vários tipos de recursos do Azure, permitindo aos administradores organizar, filtrar e rotear facilmente diferentes tipos de tráfego de rede. Então, qualquer rede virtual do Azure pode ser colocada em um grupo de segurança onde diferentes regras de entrada e saída podem ser configuradas para permitir ou negar certos tipos de tráfego. Para cada regra, você pode especificar origem e destino, porta e protocolo.
Quando estamos trabalhando com nuvens públicas e seus serviços, é de suma importância gerenciar bem este recurso de segurança, que de tão útil, por vezes, é chamado de “mini firewall”.
Principais pontos referentes ao NSG:
- Limitar o tráfego de rede aos recursos em uma rede virtual
- Contém uma lista de regras de segurança que permitem ou negam tráfego de rede de entrada ou saída
- Pode ser associado a uma sub-rede ou interface de rede (gravem bem esse ponto!!!)
A criação do recurso é extremamente simples.
No campo de busca do portal do Azure, digite: network security group, o recomendado é escolher a versão mais atual (a clássica não é mais recomendada, salvo em cenários muito específicos)
Clique em “Create”
Caso não tenha um grupo de recursos, crie um, clicando em “Create New” e após isto, informe o nome do NSG (aqui escolhemos “nsg-teste”
Escolha as TAGS (ou deixe em branco)
Após isto, clicar em “Create”
Regras de grupo de segurança de rede
Depois de criar o NSG, você poderá gerenciar suas regras individuais. Uma regra é usada para definir se o tráfego da rede é seguro e deve ser permitido ou negado pela rede.
Uma regra consiste nos seguintes componentes:
- Nome – um nome exclusivo que deve ser fácil para os administradores usarem para encontrar a regra;
- Prioridade – é um número inteiro entre 100 e 4096, que deve ser exclusivo. Este valor define a ordem de processamento da regra, com as regras contendo valores mais baixos (prioridade mais alta) sendo executadas primeiro. Ou seja, se uma regra de prioridade 100 permite acesso à porta 80, mesmo tendo uma regra de prioridade 200, negando acesso à porta 80, o acesso será concedido. Pense na prioridade como um lista com nomes de pessoas que vão entrar em uma festa, se ao olhar a lista, iniciando do primeiro nome e for na sequência, assim que encontrar o nome do convidado, o mesmo será autorizado a entrar na festa e o restante da lista não será mais conferido…seria mais ou menos assim que funciona a prioridade. No caso do exemplo da porta 80, se eu inverter a prioridade, no caso, 100 negando acesso à porta 80 e 200 permitindo acesso à porta 80, o acesso seria negado;
- Origem ou destino – este campo indica para quais aplicativos ou usuários a regra se aplica. Pode ser um endereço IP, intervalo de endereços IP ou recurso do Azure;
- Protocolo – O protocolo TCP, UDP ou ICMP que será analisado;
- Direção – indica se o tráfego é de entrada ou saída;
- Intervalo de portas – especifica para qual porta ou intervalo de portas a regra se aplica;
- Ação – Definir Permitir (o tráfego) ou Negar (e bloquear o tráfego) especificará a ação a ser executada pelo NSG quando o tráfego de rede correspondente à regra for identificado;
A tela inicial do NSG seria essa:
Nestes campos destacados abaixo, podemos inserir as regras de entrada e saída, seguindo as regras mencionadas acima.
No caso abaixo, estamos permitindo a porta 80, conforme exemplo acima.
No geral, configurar as regras é bastante simples, temos apenas que ficar atentos nas prioridades, para que não impacte no cenário real que desejamos.
Após criar o NSG com todas as suas regras, podemos associar o NSG diretamente na interface de rede de uma VM ou em uma sub-rede inteira. ATENÇÃO!! isto geralmente é questão de prova!! as vezes questionam se podemos associar em uma VNET, e não podemos!
Ainda no tema acima, o que ocorre se tivermos um NSG aplicado em uma sub-rede, com duas VMS, e uma destas VMs tenha um outro NSG associado diretamente na interface de rede?
Tráfego de entrada
Em relação ao tráfego de entrada, o Azure processa as regras em um grupo de segurança de rede associado a uma sub-rede em primeiro lugar, se houver uma, e, em seguida, as regras em um grupo de segurança de rede associado ao adaptador de rede, se houver um.
- VM1: as regras de segurança no NSG1 são processadas, já que estão associadas à Subnet1 e a VM1 está na Subnet1. A menos que você tenha criado uma regra que permite a entrada pela porta 80, o tráfego será negado pela regra de segurança padrão DenyAllInbound e nunca será avaliado pelo NSG2, já que o NSG2 está associado ao adaptador de rede. Se NSG1 tem uma regra de segurança que permite a porta 80, o tráfego é processado por NSG2. Para permitir a porta 80 para a máquina virtual, tanto NSG1 quanto NSG2 devem ter uma regra que permite a porta 80 da Internet.
- VM2: as regras no NSG1 são processadas porque a VM2 também está na Subnet1. Já que a VM2 têm um grupo de segurança de rede associado a seu adaptador de rede, ela recebe todo o tráfego permitido pelo NSG1 ou tem todo o tráfego negado por NSG1 também negado. O tráfego é permitido ou negado para todos os recursos na mesma sub-rede quando um grupo de segurança de rede está associado a uma sub-rede.
- VM3: já que não há nenhum grupo de segurança de rede associado à Subnet2, o tráfego é permitido para a sub-rede e processado pelo NSG2, pois o NSG2 está associado ao adaptador de rede anexado à VM3.
- VM4: o tráfego é permitido para a VM4 porque um grupo de segurança de rede não está associado à Subnet3 ou ao adaptador de rede na máquina virtual. Todo o tráfego será permitido por meio de um adaptador de rede e sub-rede se não tiver um grupo de segurança de rede associado a eles.
Tráfego de saída
Em relação ao tráfego de saída, o Azure processa as regras em um grupo de segurança de rede associado a um adaptador de rede em primeiro lugar, se houver um, e, em seguida, as regras em um grupo de segurança de rede associado à sub-rede, se houver uma.
- VM1: as regras de segurança no NSG2 são processadas. A menos que você crie uma regra de segurança que nega a porta 80 de saída para a Internet, o tráfego será permitido pela regra de segurança padrão AllowInternetOutbound tanto no NSG1 quanto no NSG2. Se NSG2 tem uma regra de segurança que nega a porta 80, o tráfego é negado e nunca é avaliado pelo NSG1. Para negar a porta 80 na máquina virtual, um ou ambos os grupos de segurança da rede devem ter uma regra que nega a porta 80 para a Internet.
- VM2: todo o tráfego é enviado por meio do adaptador de rede na sub-rede, uma vez que o adaptador de rede conectado à VM2 não tem um grupo de segurança de rede associado a ele. As regras no NSG1 são processadas.
- VM3: se NSG2 tem uma regra de segurança que nega a porta 80, o tráfego é negado. Se NSG2 tem uma regra de segurança que permite a porta 80, está tem permissão de saída para a Internet, uma vez que um grupo de segurança de rede não está associado à Subnet2.
- VM4: todo o tráfego é permitido da VM4, pois um grupo de segurança de rede não está associado ao adaptador de rede anexado à máquina virtual, ou para a Subnet3.
Então, no caso de NSGs sobrepostos, como no exemplo acima, temos que observar se um deles bloqueia o acesso ou se ambos permitem o acesso…simplificando, seria isso. Por exemplo, no cenário acima: digamos que tenha quatro servidores WEB, na mesma sub-rede, e eu libere a porta 80, no NSG, para esta sub-rede, para que obviamente, consigam acessar o site hospedado nestes quatros servidores. Porém, caso eu queira que apenas um destes servidores para de receber requisições na porta 80, digamos que, para alguma atualização no site, posso implementar um NSG associado diretamente na interface de rede desta VM que hospeda o site, bloqueando a porta 80, e pronto, ninguém terá mais acesso a ela nesta porta.
Abaixo, temos uma questão que pode abordar este tipo de situação:
O cenário acima seria mais ou menos isso (desculpem o desenho):
NSG-Subnet1 contém as regras padrões, que são criadas no momento que criamos o NSG. Veja aqui quais são elas: https://docs.microsoft.com/pt-br/azure/virtual-network/network-security-groups-overview#default-security-rules
NSG-VM1 possui regras específicas, conforme elencado na questão.
A VM1 contém ip público, então, ao final da questão, de acordo com o cenário, questiona-se se será possível acessar a VM pela porta 3389 (RDP).
Verifiquem que a questão altera as regras padrões do NSG-Subnet1, permitindo o acesso à porta 3389 via protocolo TCP. Neste ponto temos as duas regras permitindo acesso à porta 3389, porém, NSG-Subnet1 utilizando o protocolo TCP (ok neste caso), mas o NSG-VM1 utilizando protocolo UDP (o que não daria acesso), então, se a questão encerrasse desta forma, NÃO IRIÁMOS CONSEGUIR ACESSO RDP, via ip público, na VM. Porém, no final da questão, informa que removemos o NSG-VM1 da interface da VM1, logo, teríamos apenas a regra de entrada, via ip externo, do NSG-Subnet1, logo, iríamos conseguir acessar a VM1 via RDP.
*RESPOSTA: SIM*
Adicionando mais uma informação: neste cenário, poderíamos deixar a regra padrão do NSG-Subnet1, e não teríamos acesso via RDP externo (via ip público), porém, caso existisse outra VM (VM2), dentro da mesma subrede, iríamos conseguir o acesso RDP na VM1 sem problemas, pois a regra AllowVnetInBound permite esse acesso. Fiquem espertos!! Isto pode ser questão de prova.
Referência:
https://docs.microsoft.com/pt-br/azure/virtual-network/network-security-groups-overview
https://docs.microsoft.com/pt-br/azure/virtual-network/network-security-group-how-it-works
É isto! Até a próxima!
