Tillämpa Nolltillit principer på ett virtuellt ekernätverk i Azure

Sammanfattning: Om du vill tillämpa Nolltillit principer på ett virtuellt ekernätverk i Azure måste du använda rollbaserad åtkomstkontroll (RBAC), isolera undernät och virtuella datorer (resursgrupper, nätverkssäkerhetsgrupper och programsäkerhetsgrupper), skydda trafik och resurser i program för virtuella nätverk och virtuella datorer och aktivera avancerad hotidentifiering, aviseringar och skydd.

Den här artikeln hjälper dig att tillämpa principerna för Nolltillit på ett virtuellt ekernätverk (VNet) för IaaS-arbetsbelastningar i Azure på följande sätt:

Nolltillit princip Definition Uppfylld av
Verifiera explicit Autentisera och auktorisera alltid baserat på alla tillgängliga datapunkter. Använd programsäkerhetsgrupper för att kontrollera att enskilda nätverkskort har behörighet att kommunicera via specifika kanaler.
Använd minst privilegierad åtkomst Begränsa användaråtkomst med JUST-In-Time och Just-Enough-Access (JIT/JEA), riskbaserade adaptiva principer och dataskydd. Aktivera inte 3389/RDP-åtkomst som standard på någon kanal. Använd rätt rollbehörigheter för ekerkontexten.
Anta intrång Minimera explosionsradie och segmentåtkomst. Verifiera kryptering från slutpunkt till slutpunkt och använd analys för att få synlighet, driva hotidentifiering och förbättra skyddet. Begränsa onödig kommunikation mellan resurser. Se till att du kan logga in på nätverkssäkerhetsgrupper och att du har rätt insyn i avvikande trafik. Spåra ändringar i nätverkssäkerhetsgrupper.

Den här artikeln är en del av en serie artiklar som visar hur du tillämpar principerna för Nolltillit i en miljö i Azure som innehåller ett virtuellt ekernätverk som är värd för en virtuell datorbaserad arbetsbelastning. Mer information finns i Översikt över tillämpa Nolltillit på Azure IaaS.

Referensarkitektur

Följande diagram visar en gemensam referensarkitektur för IaaS-baserade arbetsbelastningar.

Diagram över referensarkitekturen för komponenterna i ett typiskt program med tre nivåer som körs på virtuella datorer i ett virtuellt Azure-ekernätverk.

I diagrammet:

  • Ett virtuellt ekernätverk innehåller komponenter som stöder ett IaaS-program som består av virtuella datorer.
  • IaaS-programmet är ett program med tre nivåer som består av två virtuella datorer för varje nivå: klientdel, program och data.
  • Varje nivå finns i ett dedikerat undernät med en dedikerad nätverkssäkerhetsgrupp.
  • Varje virtuell datorroll tilldelas en programsäkerhetsgrupp som motsvarar dess roll.
  • Åtkomst till programmet tillhandahålls via en Application Gateway som finns i ett eget undernät.

Programmet som visas i referensarkitekturen följer arkitekturformatet N-nivå

Följande diagram visar komponenterna i en resursgrupp för ett eker-VNet i en Azure-prenumeration som är separat från prenumerationen för det virtuella hubbnätverket.

Diagram över den logiska arkitekturen för att tillämpa Nolltillit på ett virtuellt Azure-ekernätverk som visar prenumerationer, resursgrupper och Azure-komponenter i en Microsoft Entra-ID-klientorganisation.

I diagrammet finns alla komponenter i det virtuella ekernätverket i en dedikerad resursgrupp:

  • Ett virtuellt nätverk
  • En Azure Application Gateway (App GW), inklusive en brandvägg för webbprogram (WAF)
  • Tre nätverkssäkerhetsgrupper, en för varje programnivå
  • Tre programsäkerhetsgrupper, en för varje programnivå

Vad finns i den här artikeln

Nolltillit principer tillämpas i hela arkitekturen, från klient- och katalognivå till tilldelning av virtuella datorer till programsäkerhetsgrupper. I följande tabell beskrivs rekommendationerna för att skydda den här arkitekturen.

Steg Aktivitet Nolltillit principer som tillämpas
1 Använd rollbaserad åtkomstkontroll i Microsoft Entra (RBAC) eller konfigurera anpassade roller för nätverksresurser. Använd minst privilegierad åtkomst
2 Isolera infrastrukturen till en egen resursgrupp. Anta intrång
3 Skapa en nätverkssäkerhetsgrupp för varje undernät. Använd minst privilegierad åtkomst
Anta intrång
4 Skapa en programsäkerhetsgrupp för varje virtuell datorroll. Verifiera explicit
Använd minst privilegierad åtkomst
Anta intrång
5 Skydda trafik och resurser i det virtuella nätverket:
  • Distribuera regler för att neka baslinje för nätverkssäkerhetsgrupper
  • Distribuera programspecifika regler för programsäkerhetsgrupper
  • Planera för hanteringstrafik till det virtuella nätverket
  • Distribuera flödesloggning för nätverkssäkerhetsgrupp
  • Skydda inkommande webbtrafik med IDPS
  • Verifiera explicit
    Använd minst privilegierad åtkomst
    Anta intrång
    6 Säker åtkomst till det virtuella nätverket och programmet. Använd minst privilegierad åtkomst
    Anta intrång
    7 Aktivera avancerad hotidentifiering, avisering och skydd. Anta intrång

    Steg 1: Använd Microsoft Entra RBAC eller konfigurera anpassade roller för nätverksresurser

    Du kan använda inbyggda roller i Microsoft Entra RBAC för nätverksdeltagare. En annan metod är dock att använda anpassade roller. Ekernätverkshanterare behöver inte fullständig åtkomst till nätverksresurser som beviljats av rollen Microsoft Entra RBAC-nätverksdeltagare, men behöver fler behörigheter än andra vanliga roller. Du kan använda en anpassad roll för att begränsa åtkomsten till precis det som behövs.

    Ett enkelt sätt att implementera detta är att distribuera de anpassade rollerna som finns i referensarkitekturen för Azure Landing Zone.

    Den specifika rollen är den anpassade rollen Nätverkshantering har följande behörigheter:

    • Läs allt i omfånget
    • Alla åtgärder med nätverksprovidern
    • Alla åtgärder med supportleverantören
    • Åtgärder med resursprovidern

    Du kan skapa den här rollen med hjälp av skripten för de anpassade rollerna eller via Microsoft Entra-ID med den process som beskrivs i Anpassade Azure-roller – Azure RBAC.

    Steg 2: Isolera infrastrukturen i en egen resursgrupp

    Genom att isolera nätverksresurser från beräknings-, data- eller lagringsresurser minskar du sannolikheten för utfall av behörigheter. Genom att se till att alla relaterade resurser finns i en resursgrupp kan du dessutom göra en säkerhetstilldelning och bättre hantera loggning och övervakning av dessa resurser.

    I stället för att ha ekernätverksresurserna tillgängliga i flera kontexter i en delad resursgrupp skapar du en dedikerad resursgrupp för den. Referensarkitekturen som den här artikeln stöder illustrerar det här konceptet.

    Diagram över den logiska arkitekturen som visar en dedikerad resursgrupp och dess komponenter för ett eker-VNet med Nolltillit principer som tillämpas.

    I bilden är resurser och komponenter i referensarkitekturen indelade i dedikerade resursgrupper för virtuella datorer, lagringskonton, hubb-VNet-resurser och virtuella ekerresurser.

    Med en dedikerad resursgrupp kan du tilldela en anpassad roll med hjälp av följande process: Självstudie: Bevilja en användare åtkomst till Azure-resurser med hjälp av Azure Portal – Azure RBAC.

    Ytterligare rekommendationer:

    • Referera till en säkerhetsgrupp för rollen i stället för namngivna individer.
    • Hantera åtkomsten till säkerhetsgruppen via dina mönster för hantering av företagsidentiteter.

    Om du inte använder principer som framtvingar vidarebefordring av loggar för resursgrupper konfigurerar du detta i aktivitetsloggen för resursgruppen: Navigera till aktivitetsloggen > Exportera aktivitetsloggar och välj sedan + Lägg till diagnostikinställning.

    På skärmen Diagnostikinställning väljer du alla loggkategorier (särskilt Säkerhet) och skickar dem till lämpliga loggningskällor, till exempel en Log Analytics-arbetsyta för observerbarhet eller ett lagringskonto för långsiktig lagring.

    Prenumerationsdemokratisering

    Även om det inte är direkt relaterat till nätverk bör du planera din prenumerations-RBAC på ett liknande sätt. Förutom att isolera resurser logiskt efter resursgrupp bör du även isolera prenumerationen baserat på affärsområden och portföljägare. Prenumerationen som en hanteringsenhet bör begränsas.

    Mer information om prenumerationsdemokratisering finns i Designprinciper för Azure-landningszoner – Cloud Adoption Framework.

    Du konfigurerar diagnostik från kategorin Säkerhet för diagnostikinställning i Azure Monitor, som du ser här.

    Skärmbild av diagnostikinställningar för säkerhet i Azure Monitor.

    Mer information om hur du granskar loggarna och aviseringar finns i Diagnostikinställningar .

    Steg 3: Skapa en nätverkssäkerhetsgrupp för varje undernät

    Azure-nätverkssäkerhetsgrupper används för att filtrera nätverkstrafik mellan Azure-resurser i ett virtuellt Azure-nätverk. Vi rekommenderar att du tillämpar en nätverkssäkerhetsgrupp på varje undernät, som tillämpas via Azure-principen som standard när du distribuerar Azure-landningszoner. En nätverkssäkerhetsgrupp innehåller säkerhetsregler som tillåter eller nekar inkommande nätverkstrafik till, eller utgående nätverkstrafik från, flera typer av Azure-resurser. För varje regel kan du ange källa och mål, port och protokoll.

    För ett virtuellt datorbaserat program med flera nivåer rekommenderar vi att du skapar en dedikerad nätverkssäkerhetsgrupp (NSG i följande bild) för varje undernät som är värd för en virtuell datorroll.

    Diagram över en exempelreferensarkitektur för dedikerade nätverkssäkerhetsgrupper för varje undernät som är värd för en virtuell datorroll.

    I diagrammet:

    • Varje nivå i programmet finns i ett dedikerat undernät, till exempel klientdelsnivå, appnivå och datanivå.
    • En nätverkssäkerhetsgrupp konfigureras för vart och ett av dessa undernät.

    Om du konfigurerar nätverkssäkerhetsgrupper på ett annat sätt än vad som visas i bilden kan det leda till felaktig konfiguration av vissa eller alla nätverkssäkerhetsgrupper och kan skapa problem i felsökningen. Det kan också göra det svårt att övervaka och logga.

    Skapa en nätverkssäkerhetsgrupp med den här processen: Skapa, ändra eller ta bort en Azure-nätverkssäkerhetsgrupp

    Se nätverkssäkerhetsgrupper för att förstå hur du kan använda dem för att skydda miljön.

    Steg 4: Skapa en programsäkerhetsgrupp för varje virtuell datorroll

    Med programsäkerhetsgrupper kan du konfigurera nätverkssäkerhet som ett naturligt tillägg till ett programs struktur, så att du kan gruppera virtuella datorer och definiera nätverkssäkerhetsprinciper baserat på dessa grupper. Du kan återanvända din säkerhetsprincip i stor skala utan manuellt underhåll av explicita IP-adresser. Plattformen hanterar komplexiteten med explicita IP-adresser och flera regeluppsättningar så att du kan fokusera på affärslogik.

    Identifiera de specifika rollerna för virtuella datorer i din arbetsbelastning. Skapa sedan en programsäkerhetsgrupp för varje roll. I referensarkitekturen representeras tre programsäkerhetsgrupper.

    Diagram över en exempelreferensarkitektur för separata programsäkerhetsgrupper för olika roller för virtuella datorer.

    I diagrammet:

    • Tre programsäkerhetsgrupper skapas för att stödja den här appen, en för varje nivå: klientdel, app och data.
    • Varje virtuell dator tilldelas motsvarande programsäkerhetsgrupp för sin roll (röd text i diagrammet).

    Mer information om programsäkerhetsgrupper och hur du tilldelar dessa till virtuella datorer finns i Översikt över Azure-programsäkerhetsgrupper.

    Kommentar

    Om du använder lastbalanserare måste du använda IP-adressen för lastbalanseraren i nätverkssäkerhetsgrupperna eftersom programsäkerhetsgrupper inte kan begränsa en lastbalanserare.

    Steg 5: Skydda trafik och resurser i det virtuella nätverket

    Det här avsnittet beskriver följande rekommendationer:

    • Distribuera regler för att neka baslinje för nätverkssäkerhetsgrupper
    • Distribuera programspecifika regler för programsäkerhetsgrupper
    • Planera för hanteringstrafik i det virtuella nätverket
    • Distribuera flödesloggning för nätverkssäkerhetsgrupp

    Distribuera regler för att neka baslinje för nätverkssäkerhetsgrupper

    En viktig del av Nolltillit är att använda den lägsta åtkomstnivå som krävs. Som standard har nätverkssäkerhetsgrupper tillåtna regler. Genom att lägga till en baslinje för neka-regler kan du framtvinga den lägsta åtkomstnivån.

    När du har etablerat skapar du en neka alla-regel i var och en av de inkommande och utgående reglerna, med prioriteten 4096. Det här är den senaste anpassade prioriteten som är tillgänglig, vilket innebär att du fortfarande har det återstående omfånget för att konfigurera Tillåt åtgärder.

    I nätverkssäkerhetsgruppen går du till Utgående säkerhetsregler och väljer Lägg till. Fyll i följande:

    • Källa: Alla
    • Källportintervall: *
    • Destination: Alla
    • Tjänst: Anpassad
    • Målportintervall: *
    • Protokoll: Valfritt
    • Åtgärd: Neka
    • Prioritet: 4096
    • Namn: DenyAllOutbound
    • Beskrivning: Nekar all utgående trafik om inte uttryckligen tillåts.

    Här följer ett exempel.

    Skärmbild av ett exempel på utgående säkerhetsregel.

    Upprepa den här processen med regler för inkommande trafik och justera namnet och beskrivningen efter behov. Du kommer att märka att det finns en varningsskylt på regeln på fliken Inkommande säkerhetsregler , som du ser här.

    Skärmbild av exempel på inkommande säkerhetsregler.

    Om du klickar på regeln och rullar längst ned visas mer information, som du ser här.

    Skärmbild av exempel på regelinformation.

    Det här meddelandet ger följande två varningar:

    • Azure Load Balancers kommer som standard inte att kunna komma åt resurser med hjälp av den här nätverkssäkerhetsgruppen.
    • Andra resurser i det här virtuella nätverket kommer som standard inte att kunna komma åt resurser med hjälp av den här nätverkssäkerhetsgruppen.

    För vårt syfte i Nolltillit är det så här det ska vara. Det innebär att bara för att något finns på det här virtuella nätverket betyder det inte att det har omedelbar åtkomst till dina resurser. För varje trafikmönster måste du skapa en regel som uttryckligen tillåter det och du bör göra det med minsta möjliga behörighet. Om du har specifika utgående anslutningar för hantering , till exempel till domänkontrollanter för Active Directory-domän Services (AD DS), privata virtuella DNS-datorer eller specifika externa webbplatser, måste de därför kontrolleras här.

    Alternativ neka regler

    Om du använder Azure Firewall för att hantera dina utgående anslutningar kan du i stället för att neka utgående alla lämna alla utgående anslutningar öppna. Som en del av Azure Firewall-implementeringen konfigurerar du en routningstabell som skickar standardvägen (0.0.0.0/0) till brandväggen, som hanterar trafik utanför det virtuella nätverket.

    Du kan sedan antingen skapa en neka alla utgående VNet eller i stället tillåta alla utgående (men säkra objekt med sina inkommande regler).

    Läs mer om Azure Firewall och Routningstabeller för att förstå hur du kan använda dem för att ytterligare öka säkerheten i miljön.

    Hanteringsregler för virtuella datorer

    Om du vill konfigurera virtuella datorer med Microsoft Entra Login, Anti-Malware och automatiska uppdateringar aktiverade måste du tillåta följande utgående anslutningar. Många av dessa är efter FQDN, vilket innebär att antingen Azure Firewall behövs för FQDN-regler, eller så gör du en mer komplex plan. Azure Firewall rekommenderas.

    De utgående anslutningarna är:

    • På port 443:
      • enterpriseregistration.windows.net
      • settings-win.data.microsoft.com
      • sls.update.microsoft.com
      • v10.events.data.microsoft.com
      • login.microsoftonline.com
      • pas.windows.net
      • 169.254.169.254
    • På port 80:
    • På port 123:
      • time.windows.com
    • På port 1688:
      • Azkms.core.windows.net

    Distribuera programspecifika regler för programsäkerhetsgrupper

    Definiera trafikmönster med minst antal behörigheter och följ endast uttryckligen tillåtna sökvägar. Här är ett exempeldiagram över hur du använder programsäkerhetsgrupper för att definiera nätverkstrafikmönster i nätverkssäkerhetsgrupperna för ett eker-VNet som används tillsammans med ett virtuellt hubbnätverk. Det här är den rekommenderade konfigurationen.

    Diagram över den rekommenderade konfigurationen av nätverksmönster för ett webbprogram med tre nivåer i en hub-spoke-konfiguration.

    Som ett annat exempel är här en konfiguration för ett fristående virtuellt ekernätverk där brandväggen för webbprogram placeras i Application Gateway-undernätet för det virtuella ekernätverket.

    Diagram över den rekommenderade konfigurationen av nätverksmönster för ett webbprogram med tre nivåer i en fristående ekerkonfiguration.

    Du behöver följande regler för nätverkssäkerhetsgrupper:

    1. Tillåter internettrafik till APP GW-undernätet (HTTPS 443).
    2. Tillåta trafik från APP GW-undernätet till de virtuella datorerna på klientdelsnivån (HTTPS 433).
    3. Tillåta trafik från de virtuella datorerna på klientdelsnivån till lastbalanseraren på appnivå (HTTPS 443).
    4. Tillåta trafik från lastbalanseraren på appnivå till de virtuella datorerna på appnivå (HTTPS 443).
    5. Tillåta trafik från virtuella datorer på appnivå till datanivålastbalanseraren (SQL 1433).
    6. Tillåter trafik från datanivåns lastbalanserare till de virtuella datorerna på datanivån (SQL 1433).
    7. Tillåta trafik mellan virtuella datorer på datanivå (SQL 1433)

    Konfigurera SQL-mönstret först och upprepa sedan processen med de återstående nivåerna. Följande avsnitt är konfigurationerna för de regler som begränsar nätverkstrafiken för en enda programnivå.

    Regel 5 – Tillåt trafik från virtuella datorer på appnivå till datanivåns lastbalanserare (SQL 1433)

    I nätverkssäkerhetsgruppen för undernätet på appnivå går du till Inkommande säkerhetsregler och väljer Lägg till. Fyll i listan med följande:

    • Källa: Programsäkerhetsgrupp
    • Säkerhetsgrupper för källprogram: Välj din programsäkerhetsgrupp på affärsnivå
    • Källportintervall: 1433 (Ibland kan källtrafik komma från olika portar och om det här mönstret inträffar kan du lägga till källportintervall till * för att tillåta alla källportar. Målporten är viktigare och vissa rekommendationer är att alltid använda * för källporten)
    • Mål: IP-adresser
    • Mål-IP-adresser/CIDR-intervall: lastbalanserarens explicita IP-adress
      • Du måste använda den explicita IP-adressen här eftersom du inte kan associera en lastbalanserare med en programsäkerhetsgrupp.
      • Du kan planera ditt IP-schema eller distribuera lastbalanseraren och referera till den IP-adress som den har tilldelats.
    • Tjänst: MS SQL
    • Målportintervall: Detta fylls automatiskt i för port 1433
    • Protokoll: Detta väljs automatiskt för TCP
    • Åtgärd: Tillåt
    • Prioritet: Ett värde mellan 100 och 4096. Du kan börja med 105.
    • Namn: Allow-App-Tier-to-Data-LB-Inbound
    • Beskrivning: Tillåter inkommande åtkomst från datanivåns lastbalanserare till de virtuella datorerna på appnivå.

    När du är klar ser du att det finns en blå ikon för informationsaviseringar om regeln. När du klickar på regeln visas följande meddelande:

    • "Regler som använder programsäkerhetsgrupper kan endast tillämpas när programsäkerhetsgrupperna är associerade med nätverksgränssnitt i samma virtuella nätverk."

    Här följer ett exempel.

    Skärmbild av en exempelinformationsavisering.

    Regeln gäller endast när den här programsäkerhetsgruppen används i det här nätverket.

    Slutligen går du till Utgående säkerhetsregler i samma nätverkssäkerhetsgrupp och väljer Lägg till. Fyll i listan som liknar exemplet och ändra Inkommande till Utgående.

    Regel 6 – Tillåt trafik från datanivålastbalanserare till virtuella datorer på datanivå (SQL 1433)

    I nätverkssäkerhetsgruppen för datanivåundernätet går du till Inkommande säkerhetsregler och väljer Lägg till. Fyll i listan med följande:

    • Källa: IP-adress
    • Källans IP-adress: Lastbalanserarens IP-adress
    • Källportintervall: 1433
    • Mål: Programsäkerhetsgrupp
    • Målprogramsäkerhetsgrupper: Välj programsäkerhetsgrupp på datanivå
    • Tjänst: MS SQL
    • Målportintervall: Detta fylls automatiskt i för port 1433.
    • Protokoll: Detta väljs automatiskt för TCP.
    • Åtgärd: Tillåt
    • Prioritet: Ett värde mellan 100 och 4096. Du kan börja med 105.
    • Namn: Allow-SQL-LB-to-SQL-VMs-Inbound
    • Beskrivning: Tillåter inkommande åtkomst till virtuella DATORER på SQL-baserad datanivå från lastbalanseraren på datanivå.

    I samma nätverkssäkerhetsgrupp går du till Utgående säkerhetsregler och väljer Lägg till. Fyll i listan enligt exemplet och ändra Inkommande till Utgående.

    Regel 7 – Tillåt trafik mellan virtuella datorer på datanivå (SQL 1433)

    I nätverkssäkerhetsgruppen för datanivåundernätet går du till Inkommande säkerhetsregler och väljer Lägg till. Fyll i listan med följande:

    • Källa: Programsäkerhetsgrupp
    • Målprogramsäkerhetsgrupper: Välj programsäkerhetsgrupp på datanivå
    • Källportintervall: 1433
    • Mål: Programsäkerhetsgrupper
    • Målprogramsäkerhetsgrupper: Välj programsäkerhetsgrupp på datanivå
    • Tjänst: MS SQL
    • Målportintervall: Detta fylls automatiskt i för port 1433.
    • Protokoll: Detta väljs automatiskt för TCP.
    • Åtgärd: Tillåt
    • Prioritet: Ett värde mellan 100 och 4096. Du kan börja med 105.
    • Namn: Allow-SQL-VM-to-SQL-VM-Inbound
    • Beskrivning: Tillåter inkommande åtkomst mellan virtuella DATORER på SQL-baserad datanivå.

    I samma nätverkssäkerhetsgrupp går du till Utgående säkerhetsregler och väljer Lägg till. Fyll i listan som föregående lista och ändra Inkommande till Utgående.

    Med dessa tre regler har du definierat Nolltillit anslutningsmönster för en enda programnivå. Du kan upprepa den här processen efter behov för ytterligare flöden.

    Planera för hanteringstrafik i det virtuella nätverket

    Förutom programspecifik trafik måste du planera för hanteringstrafik. Hanteringstrafiken kommer dock vanligtvis utanför det virtuella ekernätverket. Ytterligare regler krävs. Först måste du förstå de specifika portar och källor som hanteringstrafiken kommer från. I allmänhet bör all hanteringstrafik flöda från en brandvägg eller annan NVA som finns i hubbnätverket för ekern.

    Se den fullständiga referensarkitekturen i artikeln Tillämpa Nolltillit principer på Azure IaaS-översikt.

    Detta varierar beroende på dina specifika hanteringsbehov. Regler för brandväggsinstallationer och regler i nätverkssäkerhetsgruppen bör dock användas för att uttryckligen tillåta anslutningar på både plattformsnätverkssidan och nätverkssidan för arbetsbelastningen.

    Distribuera flödesloggning för nätverkssäkerhetsgrupp

    Även om nätverkssäkerhetsgruppen blockerar onödig trafik betyder det inte att dina mål uppfylls. Du måste fortfarande observera trafiken som inträffar utanför dina explicita mönster, så att du vet om en attack inträffar.

    Om du vill aktivera flödesloggning för nätverkssäkerhetsgrupp kan du följa självstudien : Logga nätverkstrafikflödet till och från en virtuell dator mot den befintliga nätverkssäkerhetsgrupp som skapas.

    Kommentar

    • Lagringskontot bör följa riktlinjerna för Nolltillit lagringskonto.
    • Åtkomsten till loggarna bör begränsas efter behov.
    • De bör också flöda in i Log Analytics och Sentinel efter behov.

    Skydda inkommande webbtrafik med IDPS

    Förutom kontrollerna i det virtuella ekernätverket kan du också använda en Azure Firewall för att utföra ytterligare kontroll. Även om funktionen Brandvägg för webbprogram för Azure Front Door och Application Gateway inspekterar trafik för vanliga webbattacker, kan användning av Azure Firewall ge en djupare kontrollnivå.

    Om du vill använda varje tillgänglig signal och upprätthålla central insyn i nätverkstrafiken rekommenderar vi att du dirigerar trafik från Application Gateway till Azure Firewall. Den kan sedan inspektera trafiken efter ytterligare signaler och avbilda beteendet i loggarna. Du kan läsa mer om den här konfigurationen i artikeln Nollförtroendenätverk för webbprogram med Azure Firewall och Application Gateway. Mer information om hur du konfigurerar det här beteendet finns i Konfigurera Azure Firewall Premium för Nolltillit.

    Steg 6: Säker åtkomst till det virtuella nätverket och programmet

    Att skydda åtkomsten till det virtuella nätverket och programmet omfattar:

    • Skydda trafik i Azure-miljön till programmet.
    • Använda multifaktorautentisering och principer för villkorlig åtkomst för användaråtkomst till programmet.

    Följande diagram visar båda dessa åtkomstlägen i referensarkitekturen.

    Diagram över referensarkitekturen som visar hur åtkomst skyddas i ett virtuellt ekernätverk.

    Skydda trafik i Azure-miljön för det virtuella nätverket och programmet

    Mycket av säkerhetstrafiken i Azure-miljön är redan slutförd. Säkra anslutningar mellan lagringsresurser och de virtuella datorerna konfigureras i Tillämpa Nolltillit principer för Azure Storage.

    Information om hur du skyddar åtkomsten från hubbresurser till det virtuella nätverket finns i Tillämpa Nolltillit principer på ett virtuellt hubbnätverk i Azure.

    Använda multifaktorautentisering och principer för villkorsstyrd åtkomst för användaråtkomst till programmet

    I artikeln Tillämpa Nolltillit principer på virtuella datorer rekommenderar vi hur du skyddar åtkomstbegäranden direkt till virtuella datorer med multifaktorautentisering och villkorlig åtkomst. Dessa begäranden kommer troligen från administratörer och utvecklare. Nästa steg är att skydda åtkomsten till programmet med multifaktorautentisering och villkorlig åtkomst. Detta gäller för alla användare som har åtkomst till appen.

    Om programmet ännu inte är integrerat med Microsoft Entra-ID kan du läsa Programtyper för Microsofts identitetsplattform.

    Lägg sedan till programmet i omfånget för dina identitets- och enhetsåtkomstprinciper.

    När du konfigurerar multifaktorautentisering med villkorlig åtkomst och relaterade principer använder du den rekommenderade principuppsättningen för Nolltillit som en guide. Detta inkluderar "Startpunkt"-principer som inte kräver hantering av enheter. Helst hanteras de enheter som har åtkomst till dina virtuella datorer och du kan implementera "Enterprise"-nivån, vilket rekommenderas för Nolltillit. Mer information finns i Vanliga Nolltillit identitets- och enhetsåtkomstprinciper.

    Följande diagram visar de rekommenderade principerna för Nolltillit.

    Diagram över Nolltillit principer för identitets- och enhetsåtkomst för tre skyddsnivåer: Startpunkt, Enterprise och Specialiserad säkerhet.

    Steg 7: Aktivera avancerad hotidentifiering och skydd

    Ditt virtuella ekernätverk som bygger på Azure kanske redan skyddas av Microsoft Defender för molnet (MDC) eftersom andra resurser från din IT-företagsmiljö som körs i Azure eller lokalt också kan skyddas.

    Som nämnts i de andra artiklarna i den här serien är Microsoft Defender för molnet ett CSPM- och CWP-verktyg (Cloud Security Posture Management) som erbjuder säkerhetsrekommendationer, aviseringar och avancerade funktioner som adaptiv nätverkshärdning som hjälper dig när du går vidare i din molnsäkerhetsresa. Information om hur du bättre visualiserar var Defender för molnet passar in i microsofts större säkerhetslandskap finns i Referensarkitekturer för Microsoft Cybersecurity.

    Den här artikeln beskriver inte Microsoft Defender för molnet i detalj, men det är viktigt att förstå att Microsoft Defender för molnet fungerar baserat på Azure-principer och loggar som matas in på en Log Analytics-arbetsyta. När du har aktiverat prenumerationerna med ditt virtuella ekernätverk och associerade resurser kan du se rekommendationer för att förbättra deras säkerhetsstatus. Du kan filtrera rekommendationerna ytterligare efter MITRE-taktik, resursgrupp osv. Överväg att prioritera lösningen av rekommendationer som har större inverkan på organisationens säkerhetspoäng.

    Här är ett exempel i Microsoft Defender för molnet portalen.

    Skärmbild av exempel Microsoft Defender för molnet rekommendationer.

    Om du väljer att registrera någon av de Defender för molnet planer som erbjuder Avancerat arbetsbelastningsskydd innehåller den adaptiva rekommendationer för nätverkshärdning för att förbättra dina befintliga regler för nätverkssäkerhetsgrupper. Här följer ett exempel.

    Skärmbild av exempel på rekommendationer för nätverkshärdning.

    Du kan acceptera rekommendationen genom att välja Framtvinga, vilket antingen skapar en ny regel för nätverkssäkerhetsgrupp eller ändrar en befintlig regel.

    Tekniska illustrationer

    Dessa illustrationer är repliker av referensillustrationerna i dessa artiklar. Ladda ned och anpassa dessa för din egen organisation och dina kunder. Ersätt Contoso-logotypen med din egen.

    Objekt beskrivning
    miniatyrbild 1Ladda ned Visio
    Uppdaterad oktober 2024
    Tillämpa Nolltillit principer på Azure IaaS
    Använd följande illustrationer med följande artiklar:
    - Översikt
    - Azure Storage
    - Virtuella datorer
    - Virtuella Azure-ekernätverk
    - Virtuella Azure Hub-nätverk
    miniatyrbild 2Ladda ned Visio
    Uppdaterad oktober 2024
    Tillämpa Nolltillit principer på Azure IaaS – en sidaffisch
    En ensidesöversikt över processen för att tillämpa principerna för Nolltillit på Azure IaaS-miljöer.

    Ytterligare tekniska illustrationer finns i Nolltillit illustrationer för IT-arkitekter och implementerare.

    Mer utbildning om säkerhet i Azure finns i dessa resurser i Microsoft-katalogen:
    Säkerhet i Azure | Microsoft Learn

    Nästa steg

    Se de här ytterligare artiklarna om hur du tillämpar Nolltillit principer på Azure:

    Referenser