Afdwinging van virtuele netwerken met beveiligingsbeheerdersregels in Azure Virtual Network Manager

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.

Handhaving 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 governance-teams stellen via security admin-regels kaders vast, maar laten afzonderlijke teams nog steeds de ruimte om de beveiliging waar nodig flexibel en nauwkeurig af te stemmen met 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 regels voor beveiligingsbeheerders

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:

  • Dwing regels voor beveiligingsbeheerders af in de hele organisatie.
  • Uitzonderingen toestaan voor het toepassingsteam om SSH-verkeer te verwerken.

Diagram van het afdwingen van beveiligingsbeheerdersregels met netwerkbeveiligingsgroepen in Azure Virtual Network Manager.

Stap 1: Maak een netwerkbeheerinstantie aan

De bedrijfsbeheerder kan een netwerkmanager aanmaken met de hoofdbeheergroep van het bedrijf als bereik van deze netwerkmanagerinstantie.

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

Beveiligingsbeheerdersregels worden in prioriteitsvolgorde geëvalueerd, en een regel met een lager prioriteitsnummer wordt eerst geëvalueerd. In deze stap bevat de beveiligingsbeheerconfiguratie twee beveiligingsbeheerregels:

  • Een beveiligingsbeheerregel die inkomend SSH-verkeer weigert voor de ALLE netwerkgroep met prioriteit 100.
  • Een beveiligingsbeheerregel die inkomend SSH-verkeer toestaat voor de App netwerkgroep op prioriteit 10.

Omdat 10 kleiner is dan 100, wordt de toelaatregel voor de App netwerkgroep geëvalueerd vóór de weigerregel die op elk virtueel netwerk binnen de organisatie geldt.

Stap 4: De configuratie van de beveiligingsbeheerder implementeren

Nadat je de beveiligingsbeheerconfiguratie hebt uitgerold, hebben alle virtuele netwerken in het bedrijf de regel om inkomend SSH te weigeren, afgedwongen door de beveiligingsbeheerregel. Er kan geen afzonderlijk team de regel voor weigeren wijzigen. Alleen de bedrijfsbeheerder kan het definiëren. De virtuele netwerken van de App hebben zowel een regel voor inkomend SSH-verkeer toestaan als een regel voor inkomend SSH-verkeer weigeren (overgenomen van de Regel voor alle netwerkgroepen ). De regel voor inkomend SSH-verkeer voor de App Network Group staat op prioriteit 10, dus die wordt eerst geëvalueerd. Wanneer inkomend SSH-verkeer naar een virtueel netwerk van de App komt, staat de regel op prioriteit 10 het verkeer toe. Aangenomen dat er NSG's zijn op de subnetten van de virtuele netwerken van de applicatie , wordt dit inkomende SSH-verkeer vervolgens geëvalueerd op basis van NSG's die door het applicatieteam zijn ingesteld. Met de hier beschreven methode voor regels voor beveiligingsbeheerders kan de bedrijfsadministrator bedrijfsbeleid effectief afdwingen en flexibele beveiligingskaders voor de hele organisatie creëren die met NSG's werken.

Volgende stappen

  • Last updated on