Beveilig je Azure netwerk met NSG's en ASG's

What zijn Azure NSGs (Network Security Groups)? 

Azure Network Security Groups (NSG's) worden gebruikt om netwerkverkeer van en naar Azure resources in een Azure Virtual Network (Vnet) te filteren. Eenvoudig gezegd worden ze gebruikt voor regels die jouw netwerk volgt. 

Een NSG bevat een groep securityregels die inkomend netwerkverkeer naar of uitgaand netwerkverkeer naar Azure-resources beperken of toestaan. Je kunt voor elke rule de source en destination, port en protocol specificeren. 

Waarvoor gebruik je NSGs?

Network Security Groups (NSGs) in Azure gebruik je om netwerk traffic te controleren op TCP/IP-niveau. Ze isoleren specifieke resources in hun container en regelen ook routes, zodat je kan bepalen welk verkeer in- en uitgaat.

Daarnaast zijn ze de eerste verdedigingslaag. Je kan niet alleen vertrouwen op NSGs; je hebt ook een Application Layer Gateway (ALG) nodig om het verkeer dat je via NSGs toestaat verder te inspecteren.

Hoe werken NSGs in Azure?

In Azure kan je network security groups koppelen aan het subnet, het VM-niveau of aan beide. Dit bepaalt hoe verkeer naar je resources stroomt en welk verkeer wordt geblokkeerd.

NSG Placement en Traffic Control

Stel je hebt een standaard Azure Virtual Network (VNet) met drie subnets, die allemaal verkeer van het publieke internet ontvangen.

Je wil geen onbeperkte toegang; aanvallers scannen vaak IP-adressen op open poorten, en je wil niet alles in je netwerk blootstellen.

Om het Azure VNet en je resources te beschermen, kan je NSGs zo instellen dat alleen specifiek verkeer wordt toegestaan, bijvoorbeeld via TCP poort 80. Dit zie je in het diagram hieronder:

• VM1: NSGs zijn gestapeld; NSG 1 zit op Subnet 1 en beoordeelt al het internetverkeer naar dat subnet. NSG 2 zit op VM1 en beoordeelt alleen het verkeer dat NSG 1 heeft doorgelaten.
• VM2: Voor VM2 geldt alleen NSG 1, want de VM zelf heeft geen NSG.
• VM3: VM3 in Subnet 2 heeft NSG 2 gekoppeld op VM-niveau, maar het subnet zelf heeft geen NSG.
• VM4: VM4 is onbeschermd, tenminste vanuit NSG-perspectief. Al het verkeer bereikt direct de VM.

Dit voorbeeld laat zien hoe de plaatsing van NSGs de beveiliging beïnvloedt. Koppel je ze aan subnets, VMs of beide, dan bepaalt dat welk verkeer gefilterd wordt (en welk niet).

Subnets beveiligen met NSGs

Door network security groups per subnet in te richten, kan je traffic tussen verschillende lagen in je netwerk beheren.

Een typische setup bestaat uit drie subnets:

Elk subnet heeft een network security group die bepaalt hoe traffic in- en uitgaat.

1. Web tier: Publiek toegankelijk, zodat klanten je website kunnen bereiken.
2. Business tier: Praat met de web servers. Bijvoorbeeld: als je meerdere VMs hebt voor applicatietaken, wil je niet dat klanten direct toegang hebben. Daarom gebruik je een NSG die alleen verkeer vanaf de web servers toelaat (API-calls of andere business-functies).
3. Data tier: Bevat gevoelige resources zoals SQL databases. Volledig geïsoleerd en alleen bereikbaar via gecontroleerde paden, zoals een Bastion host of jump box.

Hoe je network security groups inricht, hangt af van de business functies.

Bij het ontwerpen van je virtual network is het belangrijk om subnets te maken en resources met dezelfde business functie samen in een subnet te plaatsen.

Volg hierbij een functionele indeling per tier (bijvoorbeeld business tiers alleen voor interne communicatie en data tiers volledig geïsoleerd).

Security Rules van een NSG

Network security groups beschermen resources via de volgende acht properties die je instelt:

Rules worden één voor één verwerkt, volgens hun priority. Zodra een rule matcht, stopt de verwerking. Je kan tot duizend rules maken, maar dit kan snel onoverzichtelijk worden.

Wat zijn Application Security Groups?

Azure Application Security Groups (ASGs) maken het beheren van NSGs een stuk eenvoudiger. Zonder ASGs moet je in je rules handmatig statische IPs toewijzen aan elke server.

Neem opnieuw het scenario van eerder, met een multi-tier setup (met web, business en data tiers).

Vorig voorbeeld

In deze setup laat de uiteindelijke configuratie internet traffic toe naar de web services, terwijl toegang tot de logic server van buitenaf wordt geblokkeerd. Alleen web applications mogen verbinden met de logic server die de business processen afhandelt. Op dezelfde manier wordt internet traffic naar de database server beperkt: alleen de business logic servers mogen verbinden, terwijl directe toegang vanaf de web servers wordt geblokkeerd.

Dit creëert een duidelijke flow: Internet traffic gaat alleen naar de web servers → web servers praten met de business logic servers → business logic servers praten met de database

Maar om dit met NSGs te bereiken heb je statische IPs nodig voor al die machines in elke rule, en dat handmatig beheren kost veel werk. Met Application Security Groups (ASGs) los je dit probleem op.

Met ASGs kan je servers groeperen op rol of functie en daarna die groepen gebruiken in je network security rules in plaats van losse IP-adressen. Dit scheelt veel tijd en handmatig werk.

Hoe creëer je NSGs in Azure?

Hier laat ik je stap voor stap zien hoe je NSGs creëert in de Azure Portal.

1. Ga eerst naar de Azure Portal, zoek op NSG en open het.

2. Klik op create:

3. Selecteer je resource group, geef een naam en kies je regio:

4. Je zou nu het volgende moeten zien:

5. Klik dan op create en je ziet dit scherm:

Dat is alles. Je hebt nu een NSG gemaakt in Azure via de portal.

Om al je NSGs te bekijken, zoek op Network security group en je vindt ze:

Je kan de details van een NSG bekijken:

Koppel nu een subnet aan deze NSG. Klik in het linker menu op Subnets.

Klik op + Associate, kies je virtual network en het specifieke subnet. Klik op OK om de koppeling af te ronden.

NSG Rules aanmaken en configureren

De standaard rules staan toe:

• Inbound traffic van Vnets en Azure load balancers, terwijl alle andere inkomende traffic wordt geblokkeerd.
• Default outbound rules geven toegang tot andere virtual networks en het internet, maar blokkeren de rest.

In veel situaties is dit te ruim ingesteld. We willen meer controle over wie de web VMs kan bereiken. Daarom staan we web traffic toe vanaf het client VNet en blokkeren we alle andere inkomende web traffic.

Daarvoor moeten we de inbound rules aanpassen in dit voorbeeld:

Maak nieuwe rules om inbound web traffic op poorten 80 en 443 toe te laten:

1. Ga naar Inbound Security Rules en klik Add a Rule.
2. Kies een Source IP adres, dit kan een enkel IP zijn of een block van IPs. Voeg het block toe dat aan je client subnet is toegewezen.
3. Laat Source Port Range op any staan. Destination ook op any.
4. Stel Service in op HTTP, dit zet automatisch Destination Port Range op 80.
   
   
5. Laat Action op Allow staan en zet Priority op 1000. Prioriteiten kunnen van 100 tot 4096. Laat ruimte vrij om later extra rules toe te voegen.
6. Geef de rule een naam zoals Allow Client HTTP Inbound, voeg eventueel een beschrijving toe en klik Add.
   

Herhaal dit voor HTTPS (Port 443) met een iets hogere prioriteit, bijvoorbeeld 1010.

Tot nu toe is er nog niks veranderd. Verkeer naar poorten 80 en 443 vanaf ons subnet is technisch gezien al toegestaan door rule 65000, die alle poorten en protocollen tussen v-nets toestaat.

Daarom moeten we nu blocking rules toevoegen:

1. Maak een nieuwe rule.
2. Zet source en destination op Any.
3. Selecteer service HTTP, zet action op Deny, en geef een prioriteit lager dan je allow rules.
   
4. Voeg nog een rule toe voor HTTPS traffic met dezelfde instellingen.

Rules worden van boven naar beneden verwerkt en stoppen zodra er een match is. Met deze setup staat je NSG web traffic toe vanaf het client subnet en blokkeer je de rest. Zonder de deny rules zouden de default rules verkeer van elk VNet toestaan.

Dit voorbeeld laat zien hoe je NSG rules goed kunt prioriteren om traffic toe te laten of juist te blokkeren.

Zie ook Microsoft’s documentatie voor het maken van NSGs in Azure.