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.
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.
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: |
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.
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-portalen – 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.
Mer information om hur du granskar loggarna och aviseringar finns i Diagnostik Instä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.
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.
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.
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.
Om du klickar på regeln och rullar längst ned visas mer information, som du ser här.
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.
Varning
Vi kanske vill flytta dessa till hubbnätverket i stället.
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:
- ctldl.windowsupdate.com
- www.msftconnecttest.com
- 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.
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.
Du behöver följande regler för nätverkssäkerhetsgrupper:
- Tillåter internettrafik till APP GW-undernätet (HTTPS 443).
- Tillåta trafik från APP GW-undernätet till de virtuella datorerna på klientdelsnivån (HTTPS 433).
- Tillåta trafik från de virtuella datorerna på klientdelsnivån till lastbalanseraren på appnivå (HTTPS 443).
- Tillåta trafik från lastbalanseraren på appnivå till de virtuella datorerna på appnivå (HTTPS 443).
- Tillåta trafik från virtuella datorer på appnivå till datanivålastbalanseraren (SQL 1433).
- Tillåter trafik från datanivåns lastbalanserare till de virtuella datorerna på datanivån (SQL 1433).
- 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å.
Efter slutförandet 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.
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.
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.
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 vi nämnde i de andra artiklarna i den här serien är Microsoft Defender för molnet ett CSPM-verktyg (Cloud Security Posture Management) och CWP (Cloud Workload Protection) som erbjuder säkerhets-Rekommendationer, aviseringar och avancerade funktioner som adaptiv nätverkshärdning som hjälper dig under molnsäkerhetsresan. 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 dessa Rekommendationer ytterligare efter MITRE-taktik, resursgrupp osv. Överväg att prioritera lösningen på Rekommendationer som har större inverkan på organisationens säkerhetspoäng.
Här är ett exempel i Microsoft Defender för molnet portalen.
Om du väljer att registrera någon av de Defender för molnet planer som erbjuder Avancerat arbetsbelastningsskydd innehåller det adaptiv nätverkshärdning Rekommendationer för att förbättra dina befintliga regler för nätverkssäkerhetsgrupper. Här följer ett exempel.
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.
Rekommenderad träning
- Skydda dina Azure-resurser med rollbaserad åtkomstkontroll i Azure (Azure RBAC)
- Konfigurera och hantera Azure Monitor
- Konfigurera nätverkssäkerhetsgrupper
- Utforma och implementera nätverkssäkerhet
- Skydda åtkomsten till dina program med hjälp av Azure-identitetstjänster
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:
- Översikt över Azure IaaS
- Azure Virtual Desktop
- Azure Virtual WAN
- IaaS-program i Amazon Web Services
- Microsoft Sentinel och Microsoft Defender XDR
Tekniska illustrationer
Den här affischen innehåller en enkelsidig, snabb överblick över komponenterna i Azure IaaS som referens- och logiska arkitekturer, tillsammans med stegen för att säkerställa att dessa komponenter har principerna "lita aldrig på, verifiera alltid" för Nolltillit modell som tillämpas.
| Objekt | beskrivning |
|---|---|
 PDF | Visio Uppdaterad mars 2024 |
Använd den här bilden tillsammans med den här artikeln: Tillämpa Nolltillit principer på Azure IaaS-översikt Relaterade lösningsguider |
Den här affischen innehåller referens- och logiska arkitekturer och detaljerade konfigurationer av de separata komponenterna i Nolltillit för Azure IaaS. Använd sidorna i den här affischen för separata IT-avdelningar eller specialiteter, eller anpassa diagrammen för infrastrukturen med Microsoft Visio-versionen av filen.
| Objekt | beskrivning |
|---|---|
 PDF | Visio Uppdaterad mars 2024 |
Använd dessa diagram tillsammans med artiklarna som börjar här: Använd Nolltillit principer för Azure IaaS-översikt Relaterade lösningsguider |
Klicka här om du vill ha fler tekniska illustrationer.
Referenser
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för