Afdwingen van virtuele netwerken met beveiligingsbeheerdersregels in Azure Virtual Network Manager

  • Artikel

In dit artikel leert u hoe beveiligingsbeheerdersregels flexibele en schaalbare handhaving van beveiligingsbeleid bieden via hulpprogramma's zoals netwerkbeveiligingsgroepen. Eerst leert u de verschillende modellen van het afdwingen van virtuele netwerken. Vervolgens leert u de algemene stappen voor het afdwingen van beveiliging met beveiligingsbeheerdersregels.

Belangrijk

Azure Virtual Network Manager is algemeen beschikbaar voor hub-and-spoke-connectiviteitsconfiguraties en beveiligingsconfiguraties met beveiligingsbeheerdersregels. Mesh-connectiviteitsconfiguraties blijven in openbare preview.

Deze preview-versie wordt aangeboden zonder service level agreement en wordt niet aanbevolen voor productieworkloads. Misschien worden bepaalde functies niet ondersteund of zijn de mogelijkheden ervan beperkt. Zie Aanvullende gebruiksvoorwaarden voor Microsoft Azure-previews voor meer informatie.

Afdwingen van virtueel netwerk

Met netwerkbeveiligingsgroepen (NSG's) alleen, kan wijdverspreide afdwinging van virtuele netwerken in verschillende toepassingen, teams of zelfs hele organisaties lastig zijn. Vaak is er een evenwichtsoefening tussen pogingen tot gecentraliseerde handhaving binnen een organisatie en het overdragen van gedetailleerde, flexibele controle aan teams.

Beveiligingsbeheerdersregels streven ernaar om deze schuifschaal tussen afdwinging en flexibiliteit helemaal te elimineren door de voordelen van elk van deze modellen te consolideren en tegelijkertijd de nadelen van elk model te verminderen. Centrale governanceteams stellen beveiligingsrails vast via beveiligingsbeheerdersregels, terwijl er nog steeds ruimte overblijft voor afzonderlijke teams om de beveiliging flexibel vast te stellen via NSG-regels. Beveiligingsbeheerdersregels zijn niet bedoeld om NSG-regels te overschrijven. In plaats daarvan werken ze met NSG-regels om afdwinging en flexibiliteit binnen uw organisatie te bieden.

Afdwingingsmodellen

Laten we eens kijken naar enkele algemene modellen van beveiligingsbeheer zonder regels voor beveiligingsbeheerders, en de voor- en nadelen:

Model 1 - Centraal governanceteambeheer met NSG's

In dit model beheert een centraal governanceteam binnen een organisatie alle NSG's.

Voordelen Nadelen
Het centrale governanceteam kan belangrijke beveiligingsregels afdwingen. Operationele overhead is hoog omdat beheerders elke NSG moeten beheren, naarmate het aantal NSG's toeneemt, neemt de last toe.

Model 2 - Individueel teambeheer met NSG's

In dit model beheren afzonderlijke teams binnen een organisatie zonder een gecentraliseerd governanceteam hun eigen NSG's.

Voordelen Nadelen
Het individuele team heeft flexibele controle bij het aanpassen van beveiligingsregels op basis van hun servicevereisten. Het centrale governanceteam kan geen kritieke beveiligingsregels afdwingen, zoals het blokkeren van riskante poorten.

Afzonderlijke teams kunnen ook onjuist worden geconfigureerd of vergeten NSG's te koppelen, wat leidt tot blootstelling aan beveiligingsproblemen.

Model 3: NSG's worden gemaakt via Azure Policy en beheerd door afzonderlijke teams.

In dit model beheren afzonderlijke teams nog steeds hun NSG's. Het verschil is dat de NSG's worden gemaakt met behulp van Azure Policy om standaardregels in te stellen. Als u deze regels wijzigt, worden controlemeldingen geactiveerd.

Voordelen Nadelen
Het individuele team heeft flexibele controle bij het aanpassen van beveiligingsregels.

Het centrale governanceteam kan standaardbeveiligingsregels maken en meldingen ontvangen als er regels worden gewijzigd.		 Het centrale governanceteam kan de standaardbeveiligingsregels nog steeds niet afdwingen, omdat NSG-eigenaren in teams ze nog steeds kunnen wijzigen.

Meldingen zouden ook overweldigend zijn om te beheren.

Afdwingen van netwerkverkeer en uitzonderingen met beveiligingsbeheerdersregels

Laten we de concepten toepassen die tot nu toe zijn besproken op een voorbeeldscenario. Een bedrijfsnetwerkbeheerder wil een beveiligingsregel afdwingen om inkomend SSH-verkeer voor het hele bedrijf te blokkeren. Het afdwingen van dit type beveiligingsregel was moeilijk zonder een beveiligingsbeheerderregel. Als de beheerder alle NSG's beheert, is de beheeroverhead hoog en kan de beheerder niet snel reageren op de behoeften van productteams om NSG-regels te wijzigen. Als de productteams echter hun eigen NSG's zonder beveiligingsbeheerdersregels beheren, kan de beheerder geen kritieke beveiligingsregels afdwingen, waardoor potentiële beveiligingsrisico's open blijven. Door zowel beveiligingsbeheerdersregels als NSG's te gebruiken, kan dit dilemma worden opgelost.

In dit geval kan de beheerder een beveiligingsbeheerderregel maken om inkomend SSH-verkeer voor alle virtuele netwerken in het bedrijf te blokkeren. De beheerder kan ook een beveiligingsbeheerderregel maken om inkomend SSH-verkeer toe te staan voor specifieke virtuele netwerken die een uitzondering nodig hebben. De beveiligingsbeheerdersregel wordt afgedwongen in het hele bedrijf en de beheerder kan nog steeds uitzonderingen voor specifieke virtuele netwerken toestaan. Dit wordt gedaan door het gebruik van prioriteitsvolgorde voor elke regel.

In het diagram ziet u hoe de beheerder de volgende doelen kan bereiken:

  • Beveiligingsbeheerdersregels afdwingen in de hele organisatie.
  • Uitzonderingen toestaan voor het toepassingsteam om SSH-verkeer te verwerken.

Diagram van het afdwingen van beveiligingsbeheerdersregels met netwerkbeveiligingsgroepen.

Stap 1: Een netwerkbeheerexemplaren maken

De bedrijfsbeheerder kan een netwerkbeheerder maken met de hoofdbeheergroep van het bedrijf als het bereik van dit netwerkbeheerexemplaren.

Stap 2: Netwerkgroepen maken voor virtuele netwerken

De beheerder maakt twee netwerkgroepen: ALLE netwerkgroepen die bestaan uit alle virtuele netwerken in de organisatie en app-netwerkgroep die bestaat uit virtuele netwerken voor de toepassing die een uitzondering nodig heeft. ALLE netwerkgroep in het bovenstaande diagram bestaat uit VNet 1 naar VNet 5 en app-netwerkgroep heeft VNet 4 en VNet 5. Gebruikers kunnen beide netwerkgroepen eenvoudig definiëren met behulp van dynamisch lidmaatschap.

Stap 3: een configuratie voor een beveiligingsbeheerder maken

In deze stap worden twee beveiligingsbeheerdersregels gedefinieerd met de volgende configuratie van de beveiligingsbeheerder:

  • een beveiligingsbeheerdersregel voor het blokkeren van inkomend SSH-verkeer voor ALLE netwerkgroepen met een lagere prioriteit van 100.
  • een beveiligingsbeheerdersregel om inkomend SSH-verkeer voor app-netwerkgroepen met een hogere prioriteit van 10 toe te staan.

Stap 4: De configuratie van de beveiligingsbeheerder implementeren

Na de implementatie van de configuratie van de beveiligingsbeheerder hebben alle virtuele netwerken in het bedrijf de regel voor binnenkomend SSH-verkeer afgedwongen door de beveiligingsbeheerdersregel. Er kan geen afzonderlijk team de regel voor weigeren wijzigen, alleen de gedefinieerde bedrijfsbeheerder kan. De virtuele netwerken van de app hebben zowel een regel voor binnenkomend SSH-verkeer toestaan als een regel voor binnenkomend SSH-verkeer weigeren (overgenomen van de regel voor alle netwerkgroepen). Met een kleiner prioriteitsnummer voor de regel voor inkomend SSH-verkeer voor app-netwerkgroepen wordt de regel eerst geëvalueerd. Wanneer binnenkomend SSH-verkeer naar een app-VNet komt, staat de beveiligingsbeheerderregel met een hogere prioriteit het verkeer toe. Ervan uitgaande dat er NSG's zijn op de subnetten van de virtuele app-netwerken, wordt dit binnenkomende SSH-verkeer vervolgens geëvalueerd op basis van NSG's die zijn ingesteld door het toepassingsteam. Met de hier beschreven methodologie voor beveiligingsbeheerdersregels kan de bedrijfsbeheerder het bedrijfsbeleid effectief afdwingen en flexibele beveiligingsbeveiligingsrails maken binnen een organisatie die met NSG's werkt.

Volgende stappen