Tillämpning av virtuellt nätverk med säkerhetsadministratörsregler i Azure Virtual Network Manager

I den här artikeln får du lära dig hur säkerhetsadministratörsregler ger flexibel och skalbar tillämpning av säkerhetsprinciper över verktyg som nätverkssäkerhetsgrupper. Först lär du dig de olika modellerna för tillämpning av virtuella nätverk. Sedan får du lära dig de allmänna stegen för att framtvinga säkerhet med säkerhetsadministratörsregler.

Tillämpning av virtuellt nätverk

Med enbart nätverkssäkerhetsgrupper (NSG:er) kan det vara svårt att upprätthålla en bred tillämpning i virtuella nätverk i flera applikationer, team eller till och med hela organisationer. Ofta finns det en balansgång mellan försök till centraliserad tillämpning i en organisation och överlämnande av detaljerad, flexibel kontroll till team.

Säkerhetsadministratörsregler syftar till att eliminera den här glidande skalan mellan tillämpning och flexibilitet helt och hållet genom att konsolidera fördelarna med var och en av dessa modeller samtidigt som nackdelarna med var och en minskas. Centrala styrningsteam upprättar skyddsräcken genom säkerhetsadministratörsregler, samtidigt som de lämnar utrymme för enskilda team att flexibelt hitta säkerhet efter behov via NSG-regler. Säkerhetsadministratörsregler är inte avsedda att åsidosätta NSG-regler. I stället arbetar de med NSG-regler för att ge efterlevnad och flexibilitet i hela organisationen.

Verkställighetsmodeller

Låt oss titta på några vanliga modeller för säkerhetshantering utan säkerhetsadministratörsregler och deras för- och nackdelar:

Modell 1 – Central styrningsteamhantering med NSG:er

I den här modellen hanterar ett centralt styrningsteam inom en organisation alla NSG:er.

Fördelar Nackdelar
Det centrala styrningsteamet kan framtvinga viktiga säkerhetsregler. Driftkostnaderna är höga eftersom administratörerna behöver hantera varje NSG, eftersom antalet NSG:er ökar, och belastningen ökar.

Modell 2 – Individuell teamhantering med NSG:er

I den här modellen hanterar enskilda team i en organisation utan ett centraliserat styrningsteam sina egna NSG:er.

Fördelar Nackdelar
Det enskilda teamet har flexibel kontroll när det gäller att skräddarsy säkerhetsregler baserat på deras tjänstkrav. Det centrala styrningsteamet kan inte framtvinga kritiska säkerhetsregler, till exempel blockera riskfyllda portar.

Enskilda team kan också felkonfigurera eller glömma att koppla NSG:er, vilket leder till sårbarhetsexponeringar.

Modell 3 – NSG:er skapas via Azure Policy och hanteras av enskilda team.

I den här modellen hanterar enskilda team fortfarande sina NSG:er. Skillnaden är att NSG:erna skapas med hjälp av Azure Policy för att ange standardregler. Om du ändrar dessa regler utlöses granskningsmeddelanden.

Fördelar Nackdelar
Det enskilda teamet har flexibel kontroll när det gäller att skräddarsy säkerhetsregler.

Det centrala styrningsteamet kan skapa standardsäkerhetsregler och ta emot meddelanden om reglerna ändras.		 Det centrala styrningsteamet kan fortfarande inte tillämpa standardsäkerhetsreglerna eftersom NSG-ägare i team fortfarande kan ändra dem.

Meddelanden skulle också vara överväldigande att hantera.

Tillämpning av nätverkstrafik och undantag med säkerhetsadministratörsregler

Nu ska vi tillämpa de begrepp som diskuterats hittills på ett exempelscenario. En företagsnätverksadministratör vill framtvinga en säkerhetsregel för att blockera inkommande SSH-trafik för hela företaget. Det var svårt att genomdriva den här typen av säkerhetsregel utan en säkerhetsadministratörsregel. Om administratören hanterar alla NSG:er är hanteringskostnaderna höga och administratören kan inte snabbt svara på produktteamens behov av att ändra NSG-regler. Om produktteamen å andra sidan hanterar sina egna NSG:er utan säkerhetsadministratörsregler kan administratören inte tillämpa kritiska säkerhetsregler, vilket lämnar potentiella säkerhetsrisker öppna. Att använda både säkerhetsadministratörsregler och NSG:er kan lösa det här dilemmat.

I det här fallet kan administratören skapa en säkerhetsadministratörsregel för att blockera inkommande SSH-trafik för alla virtuella nätverk i företaget. Administratören kan också skapa en säkerhetsadministratörsregel för att tillåta inkommande SSH-trafik för specifika virtuella nätverk som behöver ett undantag. Säkerhetsadministratörsregeln tillämpas i hela företaget och administratören kan fortfarande tillåta undantag för specifika virtuella nätverk. Detta görs med hjälp av prioritetsordning för varje regel.

Diagrammet visar hur administratören kan uppnå följande mål:

  • Framtvinga säkerhetsadministratörsregler i hela organisationen.
  • Tillåt undantag för programteamet att hantera SSH-trafik.

Diagram över efterlevnad av säkerhetsadministratörsregler med nätverkssäkerhetsgrupper i Azure Virtual Network Manager.

Steg 1: Skapa en instans av nätverkshanteraren

Företagsadministratören kan skapa en nätverkshanterare med rothanteringsgruppen för företaget som omfång för den här nätverkshanterarinstansen.

Steg 2: Skapa nätverksgrupper för virtuella nätverk

Administratören skapar två nätverksgrupper – ALLA nätverksgrupper som består av alla virtuella nätverk i organisationen och appnätverksgruppen som består av virtuella nätverk för programmet som behöver ett undantag. ALLA nätverksgrupper i diagrammet ovan består av VNet 1 till VNet 5 och appnätverksgruppen har VNet 4 och VNet 5. Användare kan enkelt definiera båda nätverksgrupperna med dynamiskt medlemskap.

Steg 3: Skapa en konfiguration för säkerhetsadministratör

Säkerhetsadministratörsregler utvärderas i prioritetsordning, och en regel med ett lägre prioritetsnummer utvärderas först. I detta steg innehåller säkerhetsadministratörskonfigurationen två säkerhetsadministratörsregler:

  • En säkerhetsadministratörsregel som nekar inkommande SSH-trafik för ALL nätverksgrupp med prioritet 100.
  • En säkerhetsadministratörsregel som tillåter inkommande SSH-trafik för App-nätverksgruppen med prioritet 10.

Eftersom 10 är mindre än 100 utvärderas tillåtningsregeln för App-nätverksgruppen före den nekade regeln som gäller för varje virtuellt nätverk i organisationen.

Steg 4: Distribuera konfigurationen av säkerhetsadministratören

Efter att du har distribuerat säkerhetsadministratörskonfigurationen har alla virtuella nätverk i företaget regeln om att neka inkommande SSH-trafik som upprätthålls av säkerhetsadministratörsregeln. Inget enskilt team kan ändra neka-regeln. Endast företagsadministratören kan definiera det. Appens virtuella nätverk har både en tillåt inkommande SSH-trafikregel och en neka inkommande SSH-trafikregel (ärvd från All network group rule). Regeln för tillåtande inkommande SSH-trafik för App-nätverksgruppen har prioritet 10, så den utvärderas först. När inkommande SSH-trafik kommer till ett virtuellt nätverk i appen tillåter regeln på prioritet 10 trafiken. Om det finns NSG:er på subnäten i App-nätverken , utvärderas denna inkommande SSH-trafik därefter baserat på NSG:er som applikationsteamet har satt. Med metodiken för säkerhetsadministratörsregler som beskrivs här kan företagsadministratören effektivt tillämpa företagsprinciper och skapa flexibla skyddsräcken i en organisation som arbetar med nätverkssäkerhetsgrupper.

Nästa steg

  • Last updated on