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.
Viktigt!
Azure Virtual Network Manager är allmänt tillgängligt för konfigurationer av hub-and-spoke-anslutningar och säkerhetskonfigurationer med säkerhetsadministratörsregler. Mesh-anslutningskonfigurationer finns kvar i den offentliga förhandsversionen.
Den här förhandsversionen tillhandahålls utan serviceavtal och rekommenderas inte för produktionsarbetsbelastningar. Vissa funktioner kanske inte stöds eller kan vara begränsade. Mer information finns i Kompletterande villkor för användning av Microsoft Azure-förhandsversioner.
Tillämpning av virtuellt nätverk
Med enbart nätverkssäkerhetsgrupper (NSG:er) kan det vara svårt att använda omfattande tillämpning i virtuella nätverk i flera program, 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.
Tvingande modeller
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.
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
I det här steget definieras två säkerhetsadministratörsregler med följande konfiguration av säkerhetsadministratör:
- en säkerhetsadministratörsregel för att blockera inkommande SSH-trafik för ALLA nätverksgrupper med en lägre prioritet på 100.
- en säkerhetsadministratörsregel för att tillåta inkommande SSH-trafik för appnätverksgrupp med en högre prioritet på 10.
Steg 4: Distribuera konfigurationen av säkerhetsadministratören
Efter distributionen av säkerhetsadministratörskonfigurationen har alla virtuella nätverk i företaget regeln neka inkommande SSH-trafik som tillämpas av säkerhetsadministratörsregeln. Inget enskilt team kan ändra neka-regeln, endast den definierade företagsadministratören kan göra det. De virtuella appnätverken har både en regel för tillåten inkommande SSH-trafik och en regel för nekande av inkommande SSH-trafik (ärvd från regeln Alla nätverksgrupper). Med ett mindre prioritetsnummer på regeln tillåt inkommande SSH-trafik för appnätverksgrupp utvärderas regeln först. När inkommande SSH-trafik kommer till ett app-VNet tillåter säkerhetsadministratörsregeln med högre prioritet trafiken. Förutsatt att det finns NSG:er i undernäten för de virtuella appnätverken utvärderas nästa inkommande SSH-trafik baserat på NSG:er som angetts av programteamet. 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
Lär dig hur du blockerar högriskportar med säkerhetsadministratörsregler
Läs vanliga frågor och svar om Azure Virtual Network Manager