Delen via

Overzicht van Azure-netwerkbeveiligingsgroep

U kunt een Azure-netwerkbeveiligingsgroep gebruiken om netwerkverkeer tussen Azure-resources in virtuele Azure-netwerken te filteren. Een netwerkbeveiligingsgroep bevat beveiligingsregels waarmee binnenkomend netwerkverkeer naar, of uitgaand netwerkverkeer van diverse typen Azure-resources kan worden toegestaan of geweigerd.

In dit artikel worden de eigenschappen uitgelegd van een netwerkbeveiligingsgroepregel en de standaardbeveiligingsregels die door Azure worden toegepast. Ook wordt beschreven hoe u regeleigenschappen wijzigt om een uitgebreide beveiligingsregel te maken.

Beveiligingsregels

Een netwerkbeveiligingsgroep bevat naar wens netwerkbeveiligingsregels binnen azure-abonnementslimieten. Elke regel geeft de volgende eigenschappen aan:

Eigendom Uitleg
Naam Een unieke naam binnen de netwerkbeveiligingsgroep. De naam mag maximaal 80 tekens lang zijn. Het moet beginnen met een woordteken en moet eindigen met een woordteken of met _. De naam kan woordtekens, ., - of \_ bevatten.
Prioriteit Een getal tussen 100 en 4096. Regels worden verwerkt in volgorde van prioriteit, waarbij lagere getallen vóór hogere getallen worden verwerkt, omdat lagere getallen een hogere prioriteit hebben. Zodra het verkeer overeenkomt met een regel, wordt de verwerking beëindigd. Als gevolg hiervan worden regels met lagere prioriteiten (hogere getallen) die dezelfde kenmerken hebben als regels met hogere prioriteiten, niet verwerkt.
Standaardbeveiligingsregels van Azure krijgen de laagste prioriteit (hoogste getal) om ervoor te zorgen dat uw aangepaste regels altijd eerst worden verwerkt.
Bron of doel U kunt Any, een afzonderlijk IP-adres, een CIDR-blok (bijvoorbeeld 10.0.0.0/24), een servicetag of een toepassingsbeveiligingsgroep opgeven. Als u een bepaalde Azure-resource wilt opgeven, gebruikt u het privé-IP-adres dat aan de resource is toegewezen. Voor binnenkomend verkeer verwerken netwerkbeveiligingsgroepen verkeer nadat Azure openbare IP-adressen heeft omgezet in privé-IP-adressen. Voor uitgaand verkeer verwerken netwerkbeveiligingsgroepen verkeer voordat privé-IP-adressen worden omgezet in openbare IP-adressen.
Voer een bereik, servicetag of toepassingsbeveiligingsgroep in om het aantal benodigde beveiligingsregels te verminderen. Uitgebreide beveiligingsregels maken het opgeven van meerdere afzonderlijke IP-adressen en bereiken in één regel mogelijk. U kunt echter niet meerdere servicetags of toepassingsgroepen opgeven in één regel. Uitgebreide beveiligingsregels zijn alleen beschikbaar in netwerkbeveiligingsgroepen die zijn gemaakt via het Resource Manager-implementatiemodel. In het klassieke implementatiemodel kunnen meerdere IP-adressen en bereiken niet worden opgegeven in één regel.
Als de bron bijvoorbeeld subnet 10.0.1.0/24 is (waar VM1 zich bevindt) en het doel subnet 10.0.2.0/24 is (waarbij VM2 zich bevindt), filtert de netwerkbeveiligingsgroep verkeer voor VM2. Dit gedrag treedt op omdat de NSG is gekoppeld aan de netwerkinterface van VM2.
protocol TCP, UDP, ICMP, ESP, AH of Alles. De ESP- en AH-protocollen zijn momenteel niet beschikbaar via Azure Portal, maar kunnen worden gebruikt via ARM-sjablonen.
Richting Of de regel van toepassing is op inkomend of uitgaand verkeer.
Poortbereik U kunt een afzonderlijke poort of een poortbereik opgeven. U kunt bijvoorbeeld 80 of 10000-10005 opgeven; of voor een combinatie van afzonderlijke poorten en bereiken kunt u deze scheiden met komma's, zoals 80, 10000-10005. Door bereiken op te geven en komma's als scheiding te gebruiken, kunt u minder beveiligingsregels maken. Uitgebreide beveiligingsregels kunnen alleen worden gemaakt in netwerkbeveiligingsgroepen die zijn gemaakt via het Resource Manager-implementatiemodel. U kunt niet meerdere poorten of poortbereiken opgeven in dezelfde beveiligingsregel in netwerkbeveiligingsgroepen die zijn gemaakt via het klassieke implementatiemodel.
Actie Het opgegeven verkeer toestaan of weigeren.

Beveiligingsregels worden geëvalueerd en toegepast op basis van de informatie over vijf tuples van bron, bronpoort, doel, doelpoort en protocol. U kunt geen twee beveiligingsregels met dezelfde prioriteit en richting maken. Twee beveiligingsregels met dezelfde prioriteit en richting kunnen een conflict veroorzaken in de wijze waarop het systeem verkeer verwerkt. Voor bestaande verbindingen wordt een stroomrecord gemaakt. Communicatie wordt toegestaan of geweigerd op basis van de verbindingsstatus van de stroomrecord. Met het stroomrecord kan een netwerkbeveiligingsgroep stateful zijn. Als u bijvoorbeeld een beveiligingsregel voor uitgaand verkeer opgeeft voor elk adres via poort 80, hoeft u geen beveiligingsregel voor binnenkomend verkeer op te geven voor de reacties op het uitgaande verkeer. U hoeft alleen een beveiligingsregel voor binnenkomend verkeer op te geven als de communicatie extern is gestart. Het tegendeel is waar. Als binnenkomend verkeer via een poort is toegestaan, is het niet nodig om een beveiligingsregel voor uitgaand verkeer op te geven om te reageren op verkeer via die poort.

Wanneer u een beveiligingsregel verwijdert die een verbinding heeft toegestaan, blijven bestaande verbindingen ononderbroken. Regels voor netwerkbeveiligingsgroepen zijn alleen van invloed op nieuwe verbindingen. Nieuwe of bijgewerkte regels in een netwerkbeveiligingsgroep zijn uitsluitend van toepassing op nieuwe verbindingen, waardoor bestaande verbindingen niet worden beïnvloed door de wijzigingen. Als u bijvoorbeeld een actieve SSH-sessie naar een virtuele machine hebt en vervolgens de beveiligingsregel verwijdert die SSH-verkeer toestaat, blijft uw huidige SSH-sessie verbonden en functioneel. Als u echter probeert een nieuwe SSH-verbinding tot stand te brengen na het verwijderen van de beveiligingsregel, wordt deze nieuwe verbindingspoging geblokkeerd.

Er gelden limieten voor het aantal beveiligingsregels dat u kunt maken in een netwerkbeveiligingsgroep en andere eigenschappen van de netwerkbeveiligingsgroep. Zie Netwerkenlimieten voor meer informatie.

Standaardbeveiligingsregels

Azure maakt de volgende standaardregels in elke netwerkbeveiligingsgroep die u maakt:

Inkomend

AllowVNetInBound
Prioriteit Bron Bronpoorten Bestemming Doelpoorten protocol Toegang
65000 VirtualNetwork 0-65535 VirtualNetwork 0-65535 Alle Toestaan
Azure-loadbalancerinvoer toestaan
Prioriteit Bron Bronpoorten Bestemming Doelpoorten protocol Toegang
65001 Azure LoadBalancer 0-65535 0.0.0.0/0 0-65535 Alle Toestaan
DenyAllInbound
Prioriteit Bron Bronpoorten Bestemming Doelpoorten protocol Toegang
65500 0.0.0.0/0 0-65535 0.0.0.0/0 0-65535 Alle Weigeren

Uitgaand

AllowVnetOutBound
Prioriteit Bron Bronpoorten Bestemming Doelpoorten protocol Toegang
65000 VirtualNetwork 0-65535 VirtualNetwork 0-65535 Alle Toestaan
InternetVerkeerToestaan
Prioriteit Bron Bronpoorten Bestemming Doelpoorten protocol Toegang
65001 0.0.0.0/0 0-65535 Internet 0-65535 Alle Toestaan
DenyAllOutBound
Prioriteit Bron Bronpoorten Bestemming Doelpoorten protocol Toegang
65500 0.0.0.0/0 0-65535 0.0.0.0/0 0-65535 Alle Weigeren

In de kolommen Bron en Doel zijn VirtualNetwork, AzureLoadBalancer en Internetservicetags in plaats van IP-adressen. In de kolom Protocol bevat Any TCP, UDP en ICMP. Wanneer u een regel maakt, kunt u TCP, UDP, ICMP of Any opgeven. 0.0.0.0/0 in de kolommen Bron en Doel vertegenwoordigt alle IP-adressen. Clients zoals Azure Portal, Azure CLI of PowerShell kunnen * of Any voor deze expressie gebruiken.

U kunt de standaardregels niet verwijderen, maar u kunt ze overschrijven door regels met hogere prioriteiten te maken.

Uitgebreide beveiligingsregels

Uitgebreide beveiligingsregels vereenvoudigen de beveiligingsdefinitie voor virtuele netwerken, zodat u groter en complexer netwerkbeveiligingsbeleid kunt definiëren met minder regels. U kunt meerdere poorten en meerdere expliciete IP-adressen en -bereiken combineren tot één gemakkelijk te begrijpen beveiligingsregel. U kunt uitgebreide regels gebruiken in de velden voor bron, doel en poort van een regel. Om het onderhoud van de definitie van uw beveiligingsregel te vereenvoudigen, kunt u uitgebreide beveiligingsregels combineren met servicetags of toepassingsbeveiligingsgroepen. Er gelden limieten voor het aantal adressen, bereiken en poorten dat u in een beveiligingsregel kunt opgeven. Zie Netwerkenlimieten voor meer informatie.

Service-tags

Een servicetag vertegenwoordigt een groep IP-adresvoorvoegsels van een bepaalde Azure-service. Het helpt de complexiteit van frequente updates op netwerkbeveiligingsregels te minimaliseren.

Zie Azure-servicetags voor meer informatie. Zie Netwerktoegang tot PaaS-resources beperken voor een voorbeeld van het gebruik van de Storage-servicetag om de netwerktoegang te beperken.

Toepassingsbeveiligingsgroepen

Met behulp van toepassingsbeveiligingsgroepen kunt u netwerkbeveiliging configureren als een natuurlijk verlengstuk van de structuur van een toepassing, waarbij u virtuele machines kunt groeperen en netwerkbeveiligingsbeleid kunt definiëren op basis van die groepen. U kunt het beveiligingsbeleid op grote schaal opnieuw gebruiken zonder handmatig onderhoud van expliciete IP-adressen. Zie Toepassingsbeveiligingsgroepen voor meer informatie.

Beveiligingsadministratieregels

Beveiligingsbeheerdersregels zijn globale netwerkbeveiligingsregels die beveiligingsbeleid afdwingen op virtuele netwerken. Beveiligingsbeheerdersregels zijn afkomstig van Azure Virtual Network Manager, een beheerservice waarmee netwerkbeheerders virtuele netwerken wereldwijd kunnen groeperen, configureren, implementeren en beheren.

Beveiligingsbeheerdersregels hebben altijd een hogere prioriteit dan regels voor netwerkbeveiligingsgroepen en worden daarom eerst geëvalueerd. 'Toestaan'-regels van de beveiligingsbeheerder worden geëvalueerd door deze te vergelijken met regels voor netwerkbeveiligingsgroepen. De beveiligingsbeheerdersregels "Altijd toestaan" en "Weigeren" eindigen echter de verkeersevaluatie zodra de beveiligingsbeheerdersregel is verwerkt. Systeembeheerdersregels "Altijd toestaan" sturen verkeer direct naar de resource, waarbij mogelijk conflicterende netwerkbeveiligingsgroepsregels kunnen worden omzeild. Beveiligingsregels met de status 'weigeren' blokkeren het verkeer zonder het naar de bestemming te sturen. Met deze regels wordt basislijnbeveiligingsbeleid afgedwongen zonder risico op conflict met netwerkbeveiligingsgroepen, onjuiste configuratie of introductie van beveiligingsproblemen. Deze actietypen voor beveiligingsbeheerdersregels kunnen handig zijn voor het afdwingen van de levering van verkeer en het voorkomen van conflicterend of onbedoeld gedrag door regels voor downstreamnetwerkbeveiligingsgroepen.

Dit gedrag is belangrijk om te begrijpen, omdat verkeer dat overeenkomt met beveiligingsregels van de actiesoorten 'Altijd toestaan' of 'Weigeren', geen regels voor netwerkbeveiligingsgroepen bereikt voor verdere evaluatie. Zie Beveiligingsbeheerdersregels voor meer informatie.

Time-out voor stroom

Belangrijk

Stroomlogboeken voor netwerkbeveiligingsgroepen (NSG) worden op 30 september 2027 buiten gebruik gesteld. Na 30 juni 2025 kunt u geen nieuwe NSG-stroomlogboeken meer maken. U wordt aangeraden te migreren naar stroomlogboeken voor virtuele netwerken, waarmee de beperkingen van NSG-stroomlogboeken worden aangepakt. Na de buitengebruikstellingsdatum worden verkeersanalyses die zijn ingeschakeld voor NSG-stroomlogboeken niet meer ondersteund en worden bestaande NSG-stroomlogboekbronnen in uw abonnementen verwijderd. Bestaande NSG-stroomlogboekrecords worden echter niet verwijderd uit Azure Storage en blijven hun geconfigureerde bewaarbeleid volgen. Zie de officiële aankondiging voor meer informatie.

Tijdslimietinstellingen voor gegevensstromen bepalen hoe lang een gegevensstroomrecord actief blijft voordat het verloopt. U kunt deze instelling configureren met behulp van Azure Portal of via de opdrachtregel. Zie het overzicht van NSG-stroomlogboeken voor meer informatie.

Overwegingen bij het Azure-platform

  • Virtueel IP-adres van het hostknooppunt: Basisinfrastructuurservices zoals DHCP, DNS, IMDS en statuscontrole worden geleverd via de gevirtualiseerde host-IP-adressen 168.63.129.16 en 169.254.169.254. Deze IP-adressen zijn van Microsoft en zijn de enige gevirtualiseerde IP-adressen die in alle regio's voor dit doel worden gebruikt. Deze services zijn standaard niet onderworpen aan de geconfigureerde netwerkbeveiligingsgroepen, tenzij deze zijn gericht op servicetags die specifiek zijn voor elke service. Als u deze basisinfrastructuurcommunicatie wilt overschrijven, kunt u een beveiligingsregel maken om verkeer te weigeren met behulp van de volgende servicetags in uw regels voor netwerkbeveiligingsgroepen: AzurePlatformDNS, AzurePlatformIMDS, AzurePlatformLKM. Meer informatie over het diagnosticeren van netwerkverkeerfilters en het diagnosticeren van netwerkroutering.

  • Licentieverlening (Key Management Service): voor alle Windows installatiekopieën die op virtuele machines worden uitgevoerd, is een licentie vereist. Om licenties te garanderen, verzendt het systeem een aanvraag naar de Key Management Service-hostservers die dergelijke query's verwerken. De uitgaande aanvraag wordt gedaan via poort 1688. Voor implementaties die standaardroute 0.0.0.0/0 gebruiken , is deze platformregel uitgeschakeld.

  • Virtuele machines in groepen met gelijke taakverdeling: de bronpoort en het bronadresbereik die worden toegepast, zijn die van de oorspronkelijke computer, niet van de load balancer. De doelpoort en het doeladresbereik zijn die van de doelcomputer, niet van de load balancer.

  • Azure-service-exemplaren: exemplaren van verschillende Azure-services, zoals HDInsight, Application Service Environments en Virtual Machine Scale Sets, worden geïmplementeerd in subnetten van virtuele netwerken. Bekijk een volledige lijst met services die u in virtuele netwerken kunt implementeren. Voordat u een netwerkbeveiligingsgroep toepast op het subnet, moet u vertrouwd raken met de poortvereisten voor elke service. Als u poorten weigert die zijn vereist voor de service, werkt de service niet goed.

  • Uitgaande e-mail verzenden: Microsoft raadt u aan om geverifieerde SMTP-relayservices te gebruiken (doorgaans verbonden via TCP-poort 587, maar ook vaak andere) om e-mail vanaf Azure Virtual Machines te verzenden. SMTP-relayservices zijn gespecialiseerd in de reputatie van de afzender, om de mogelijkheid te minimaliseren dat e-mailproviders van partners berichten weigeren. Dergelijke SMTP-relayservices omvatten, maar zijn niet beperkt tot Exchange Online Protection en SendGrid. Het gebruik van de SMTP-relayservices wordt in Azure op geen enkele wijze beperkt, ongeacht welk type abonnement u hebt.

    Als u vóór 15 november 2017 uw Azure-abonnement hebt gemaakt, kunt u niet alleen SMTP-relayservices gebruiken, maar ook rechtstreeks via TCP-poort 25 e-mail verzenden. Als u uw abonnement na 15 november 2017 hebt gemaakt, kunt u mogelijk geen e-mail rechtstreeks via poort 25 verzenden. Hoe uitgaande communicatie via poort 25 verloopt, hangt als volgt samen met het type abonnement dat u hebt:

    • Enterprise Agreement: Voor VM's die zijn geïmplementeerd in standaard Enterprise Agreement-abonnementen, worden de uitgaande SMTP-verbindingen op TCP-poort 25 niet geblokkeerd. Er is echter geen garantie dat externe domeinen de binnenkomende e-mailberichten van de VM's accepteren. Als externe domeinen e-mailberichten weigeren of filteren, neemt u contact op met de e-mailserviceproviders van de externe domeinen om de problemen op te lossen. Deze problemen worden niet gedekt door ondersteuning voor Azure.

      Voor Enterprise Dev/Test-abonnementen wordt poort 25 standaard geblokkeerd. Het is mogelijk om dit blok te verwijderen. Als u wilt aanvragen dat het blok is verwijderd, gaat u naar de sectie Kan geen e-mail verzenden (SMTP-poort 25) van de pagina Instellingen vaststellen en oplossen voor de Azure Virtual Network-resource in Azure Portal en voert u de diagnose uit. Met deze procedure worden de gekwalificeerde enterprise dev/test-abonnementen automatisch uitgesloten.

      Nadat een abonnement is vrijgesteld van dit blok en de VM's zijn gestopt en opnieuw gestart, zijn vanaf dat moment alle VM's in dat abonnement vrijgesteld. De uitzondering geldt alleen voor het aangevraagde abonnement en alleen voor VM-verkeer dat rechtstreeks naar internet wordt gerouteerd.

    • Betalen naar gebruik: de communicatie via uitgaande poort 25 is voor alle bronnen geblokkeerd. Er kunnen geen aanvragen worden gedaan om de beperking te verwijderen, omdat er geen aanvragen worden verleend. Als u e-mail moet verzenden vanaf uw virtuele machine, dient u een SMTP-relayservice te gebruiken.

    • MSDN, Azure Pass, Azure in Open, Education en Gratis proefversie: Communicatie via uitgaande poort 25 is geblokkeerd voor alle resources. Er kunnen geen aanvragen worden gedaan om de beperking te verwijderen, omdat er geen aanvragen worden verleend. Als u e-mail moet verzenden vanaf uw virtuele machine, dient u een SMTP-relayservice te gebruiken.

    • Cloudserviceprovider: uitgaande communicatie via poort 25 wordt geblokkeerd voor alle resources. Er kunnen geen aanvragen worden gedaan om de beperking te verwijderen, omdat er geen aanvragen worden verleend. Als u e-mail moet verzenden vanaf uw virtuele machine, dient u een SMTP-relayservice te gebruiken.

Volgende stappen

  • Last updated on