Tillämpa Nolltillit principer på ett virtuellt ekernätverk med Azure PaaS Services

Den här artikeln hjälper dig att tillämpa principerna för Nolltillit säkerhetsmodellen på en PaaS-arbetsbelastning med hjälp av virtuella Azure-nätverk (VNet) och privata slutpunkter på följande sätt:

Nolltillit princip	Definition	Uppfylld av
Verifiera explicit	Autentisera och auktorisera alltid baserat på alla tillgängliga datapunkter.	Använd hotidentifiering i Azure Firewall och Azure Application Gateway för att verifiera trafik och för att kontrollera om trafiken är acceptabel.
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.	Minska ingressen till och utgående från Azure-tjänster till ditt privata nätverk. Använd nätverkssäkerhetsgrupper för att endast tillåta specifika ingresser från ditt virtuella nätverk. Använd en central Azure Firewall-instans för att bevilja icke-VNet-trafikåtkomst till Azure-tjänsten.
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 loggar från nätverkssäkerhetsgrupper och att du har rätt insyn i avvikande trafik. Spåra ändringar i nätverkssäkerhetsgrupper.

Mer information om hur du tillämpar principerna för Nolltillit i en Azure IaaS-miljö finns i översikten Tillämpa Nolltillit principer på Azure IaaS.

Nolltillit fristående eller ekernätverk för Azure PaaS-tjänster

Många PaaS-tjänster innehåller sina egna, tjänstbaserade funktioner för ingress- och utgående kontroll. Du kan använda dessa kontroller för att skydda nätverksåtkomsten till PaaS-tjänstresurser utan att behöva infrastruktur, till exempel virtuella nätverk. Till exempel:

• Azure SQL Database har en egen brandvägg som kan användas för att tillåta specifika klient-IP-adresser som behöver åtkomst till databasservern.
• Azure Storage-konton har ett konfigurationsalternativ som tillåter anslutningar från ett specifikt virtuellt nätverk eller för att blockera åtkomst till offentliga nätverk.
• Azure App Service stöder åtkomstbegränsningar för att definiera en prioritetsbeställd lista över tillåt/neka som styr nätverksåtkomsten till din app.

För Nolltillit guidade implementeringar räcker det dock inte med de här tjänstbaserade åtkomstkontrollerna. Detta skapar en spridning av åtkomstkontroller och loggning som kan öka hanteringen och minska synligheten.

Dessutom kan PaaS-tjänster använda fullständigt kvalificerade domännamn (FQDN) som matchar en dynamiskt tilldelad offentlig IP-adress som allokeras från en pool med offentliga IP-adresser i en viss region för en typ av tjänst. Därför kan du inte tillåta trafik från eller till en specifik PaaS-tjänst med hjälp av deras offentliga IP-adress, vilket kan ändras.

Microsoft rekommenderar att du använder privata slutpunkter. En privat slutpunkt är ett VNet-gränssnitt som använder en privat IP-adress från ditt virtuella nätverk. Med det här nätverksgränssnittet får du privat och säker anslutning till en tjänst som drivs av Azure Private Link. Genom att aktivera en privat slutpunkt tar du med tjänsten till ditt virtuella nätverk.

Beroende på ditt lösningsscenario kan du fortfarande behöva offentlig inkommande åtkomst till dina PaaS-tjänster. Men om du inte gör det rekommenderar Microsoft att all trafik förblir privat för att eliminera potentiella säkerhetsrisker.

Den här guiden innehåller instruktioner för en specifik referensarkitektur, men principerna och metoderna kan tillämpas på andra arkitekturer efter behov.

Referensarkitektur

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

I diagrammet:

• Ett virtuellt ekernätverk innehåller komponenter som stöder ett PaaS-program.
• PaaS-programmet är ett program med två nivåer som använder Azure Application Services för en webbapp/klientdel och en Azure SQL Database för relationsdatabaser.
• Varje nivå finns i ett dedikerat undernät för ingress med en dedikerad nätverkssäkerhetsgrupp.
• Webbnivån innehåller ett dedikerat undernät för utgående trafik.
• Åtkomst till programmet tillhandahålls via en Application Gateway som finns i ett eget undernät.

Följande diagram visar den logiska arkitekturen för dessa komponenter i en Azure-prenumeration.

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 (med namnet "NSG" i diagrammet) för databas-, program- och klientdelsnivåer
• Två programsäkerhetsgrupper (med namnet "ASG" i diagrammet)
• Två privata slutpunkter

Dessutom distribueras resurser för det virtuella hubbnätverket i lämplig anslutningsprenumeration.

Vad finns i den här artikeln

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

Steg	Aktivitet
1	Använd Microsoft Entra RBAC eller konfigurera anpassade roller för nätverksresurser.
2	Isolera infrastrukturen till en egen resursgrupp.
3	Skapa en nätverkssäkerhetsgrupp för varje undernät.
4	Skydda trafik och resurser i det virtuella nätverket: Distribuera regler för att neka baslinje för nätverkssäkerhetsgrupper. Planera för hanteringstrafik till det virtuella nätverket. Distribuera flödesloggning för nätverkssäkerhetsgrupp.
5	Säker ingress och utgående trafik för Azure PaaS-tjänster.
6	Säker åtkomst till det virtuella nätverket och programmet.
7	Aktivera avancerad hotidentifiering, avisering och skydd.

Den här guiden förutsätter att du redan har en Azure Application Service och Azure SQL Database distribuerad i sina egna resursgrupper.

Steg 1: Utnyttja 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 utnyttja anpassade roller. Spoke VNet-nätverkshanterare behöver inte fullständig åtkomst till nätverksresurser som beviljats av rollen Microsoft Entra RBAC Network Contributor men behöver fler behörigheter än andra vanliga roller. En anpassad roll kan användas 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 roll som kan användas är den anpassade rollen Nätverkshantering , som 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

Den här rollen kan skapas med hjälp av skripten i GitHub-lagringsplatsen för Azure Landing Zone Reference Architecture eller skapas via Microsoft Entra-ID med anpassade Azure-roller.

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.

Skapa en dedikerad resursgrupp i stället för att ha ekernätverksresurserna tillgängliga i flera kontexter i en delad resursgrupp. Följande arkitekturdiagram visar den här konfigurationen.

I diagrammet är resurser och komponenter i referensarkitekturen indelade i dedikerade resursgrupper för programtjänster, Azure SQL-databaser, lagringskonton, hubb-VNet-resurser och virtuella ekernätverksresurser.

Med en dedikerad resursgrupp kan du tilldela en anpassad roll med hjälp av självstudien Bevilja en användare åtkomst till Azure-resurser med hjälp av azure-portalen .

Ytterligare rekommendationer:

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

Om du inte använder principer som tillämpar loggvidarebefordring på resursgrupper konfigurerar du detta i aktivitetsloggen för resursgruppen:

1. Hitta resursgruppen i Azure-portalen.
2. Gå till Aktivitetslogg –> Exportera aktivitetsloggar och välj sedan + Lägg till diagnostikinställning.
3. 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. Här är ett exempel:

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

Demokratisering av prenumeration

Ä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 finns i Designprinciper för Azure-landningszoner .

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. Detta tillämpas som standard via Azure-principen 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äll- och mål-IP-adresser, ett protokoll (till exempel TCP eller UDP) och en port.

För program med flera nivåer rekommenderar vi att du skapar en dedikerad nätverkssäkerhetsgrupp ("NSG" i följande diagram) för varje undernät som är värd för en nätverkskomponent.

I diagrammet:

• Varje nivå i programmet har ett dedikerat inkommande undernät, till exempel ett för webbnivån och ett annat för datanivån.
• Azure Application Services har ett dedikerat utgående undernät för en specifik programtjänst.
• 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 i diagrammet 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.

Se Skapa, ändra eller ta bort en Azure-nätverkssäkerhetsgrupp för att hantera inställningarna för dina nätverkssäkerhetsgrupper.

Läs mer om nätverkssäkerhetsgrupper för att förstå hur de kan användas för att skydda dina miljöer.

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

I det här avsnittet beskrivs följande rekommendationer:

• Distribuera regler för att neka baslinje för nätverkssäkerhetsgrupper
• Distribuera programspecifika regler
• 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åtna åtgärder.

Det gör du genom att gå till Utgående säkerhetsregler i nätverkssäkerhetsgruppen och välja 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.

Fliken Inkommande säkerhetsregler visar varningstecken på regeln. Här följer ett exempel.

Klicka på regeln och rulla längst ned för att se mer information. Här är ett exempel:

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 kommer att ha omedelbar åtkomst till dina resurser. För varje trafikmönster skapar du 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 domänkontrollanter för Active Directory-domän Services (AD DS), privata virtuella DNS-datorer eller specifika externa webbplatser, måste de kontrolleras här.

Alternativ neka regler

Kommentar

Rekommendationerna i det här avsnittet gäller endast för undernätet web-egress.

Om du använder Azure Firewall för att hantera dina utgående anslutningar kan du skapa alternativa regler för utgående anslutningar i stället för att utföra en neka utgående anslutning. Som en del av Azure Firewall-implementeringen konfigurerar du en routningstabell som skickar standardvägstrafik (0.0.0.0/0) till brandväggen. Detta hanterar trafik utanför det virtuella nätverket.

Du kan sedan antingen skapa en regel för att neka alla utgående VNet-nätverk eller en tillåt alla utgående regler men säkra objekt med sina regler för inkommande trafik.

Se Azure Firewall och Routningstabeller för att förstå hur de kan användas för att ytterligare öka säkerheten i miljön.

Distribuera programspecifika regler

Definiera trafikmönster med minst antal behörigheter och följ endast uttryckligen tillåtna sökvägar. Använd undernät som källor och definiera nätverksmönster i nätverkssäkerhetsgrupperna. Här följer ett exempel.

Använd hantera nätverkssäkerhetsgrupper: Skapa en säkerhetsregelprocess för att lägga till regler i dina nätverkssäkerhetsgrupper.

Lägg till följande regler för att skydda det här scenariot:

Nätverkssäkerhetsgrupp för undernät	Riktning	Källa	Källinformation	Källport	Mål	Målinformation	Tjänst	Namn på nätverkssäkerhetsgrupp	Beskrivning av nätverkssäkerhetsgrupp
App Service-undernät	Inkommande	IP-adresser	Ditt Application Gateway-undernäts privata IP-adressintervall	443	IP-adresser	Den explicita IP-adressen för din App Services privata slutpunkt	MS SQL	AllowGWtoAppInbound	Tillåter inkommande åtkomst till App Service från Application Gateway.
Undernät för App Service-integrering	Utgående	IP-adresser	Ip-adressintervall för Ditt App Service-integrationsundernät	1433	IP-adresser	Den explicita IP-adressen för din SQL DB:s privata slutpunkt	MS SQL	AllowApptoSQLDBOutbound	Tillåter utgående åtkomst till den privata SQL-slutpunkten från App Service Integration-undernätet.
Azure SQL-undernät	Inkommande	IP-adresser	Ip-adressintervall för Ditt App Service-integrationsundernät	1433	IP-adresser	Den explicita IP-adressen för din SQL DB:s privata slutpunkt	MS SQL	AllowApptoSQLDBInbound	Tillåter inkommande åtkomst till den privata SQL-slutpunkten från App Service Integration-undernätet.

Kommentar

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.

Kommentar

För prioritet använder du ett värde mellan 100 och 4 000. Du kan börja vid 105.

Detta är utöver reglerna för nätverkssäkerhetsgruppen i application gateway-undernätet.

Med dessa 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

Utöver den programspecifika trafiken planerar du för hanteringstrafik. Eftersom hanteringstrafiken vanligtvis kommer utanför det virtuella ekernätverket krävs dock fler regler. Börja med att förstå de specifika portar och källor som hanteringstrafiken kommer från. Normalt bör all hanteringstrafik flöda från en brandvägg eller annan virtuell nätverksinstallation (NVA) som finns i hubbnätverket för ekern.

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

Konfigurationen varierar beroende på dina specifika hanteringsbehov. Du bör dock använda regler för brandväggsenheter och regler i nätverkssäkerhetsgruppen för att uttryckligen tillåta anslutningar på både plattformsnätverks- och arbetsbelastningsnätverkssidan.

Planera för distributioner

Eftersom dina programtjänster och databaser nu använder privata nätverk ska du planera för hur distributioner av kod och data till dessa resurser fungerar. Lägg till regler som gör att dina privata byggservrar kan komma åt dessa slutpunkter.

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. För att identifiera en attack måste du fortfarande observera trafiken som inträffar utanför dina explicita mönster.

Trafiken till de privata slutpunkterna loggas inte , men om andra tjänster distribueras till undernäten senare kommer den här loggen att hjälpa dig att identifiera aktiviteterna.

Om du vill aktivera flödesloggning för nätverkssäkerhetsgrupp följer du Självstudie: Logga nätverkstrafikflöde till och från en virtuell dator för den befintliga nätverkssäkerhetsgruppen för de privata slutpunkterna.

Kommentar

Tänk på följande rekommendationer:

• Du bör begränsa åtkomsten till loggarna efter behov.

• Loggar bör flöda till Log Analytics och Microsoft Sentinel efter behov.

Steg 5: Säker ingress och utgående trafik för Azure PaaS-tjänster

Det här avsnittet innehåller två steg som krävs för att skydda inkommande och utgående trafik för dina PaaS-tjänster:

• Distribuera privata slutpunkter för ingress till dina tjänster.
• Distribuera VNet-integrering så att programtjänsten kan kommunicera med ditt virtuella nätverk.

Dessutom bör du även överväga dns-konfigurationen för att tillåta namnmatchning.

Distribuera privata slutpunkter för inkommande

Många tjänster gör att du kan skapa privata slutpunkter från det resursspecifika bladet i Azure-portalen, men en mer konsekvent upplevelse är att skapa en privat slutpunkt från att skapa en egen resurs. För att göra det bör resurser redan distribueras. När du har distribuerat den kan du skapa den privata slutpunkten.

När du distribuerar de privata slutpunkterna konfigurerar du dem på följande sätt:

• Placera dem i den specifika resursgrupp som innehåller de överordnade resurserna för att hålla ihop resurser med en liknande livscykel och för att ge central åtkomst.
• Placera dem i lämpligt undernät i det virtuella nätverket baserat på deras roll.
• För Azure Application Service kan du konfigurera privata slutpunkter både för dess normala klientdel och dess SCM-slutpunkt, som används för distributioner och hantering.

Som en del av den här distributionen bör du också se till att den tjänstspecifika brandväggen är inställd på att neka inkommande trafik. Detta nekar alla försök till offentlig ingress.

För Azure SQL-databasen hanterar du dess IP-brandväggsregler på servernivå. Kontrollera att Åtkomst till offentligt nätverk är inställt på Inaktivera från nätverkspanelen i Azure-portalen.

För Azure Application Service anger tillägg av den privata slutpunkten brandväggen på tjänstnivå för att blockera inkommande åtkomst som standard. Mer information finns i Använda privata slutpunkter för App Service-appar.

Distribuera VNet-integrering för utgående trafik

Förutom de privata slutpunkterna för ingress aktiverar du VNet-integrering. Varje App Service-plan kan ha VNet-integrering aktiverat och på så sätt allokeras ett helt undernät för App Service. Mer information finns i Integrera din app med ett virtuellt Azure-nätverk.

Information om hur du konfigurerar din App Service finns i Aktivera VNet-integrering i Azure App Service. Se till att du placerar den i ditt undernät som är avsett för utgående trafik.

DNS-överväganden

Som en del av användningen av privata slutpunkter aktiverar du DNS-matchning av resursernas FQDN till deras nya privata IP-adresser. Anvisningar för hur du implementerar detta på flera olika sätt finns i DNS-konfiguration för privat slutpunkt.

Kommentar

DNS-matchning måste gälla för all trafik. Resurser i samma virtuella nätverk kan inte lösas om de inte använder rätt DNS-zoner.

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

Att skydda åtkomsten till det virtuella nätverket och programmen är:

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

Följande diagram visar båda åtkomstlägena 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. Se Tillämpa Nolltillit principer på Azure Storage för att konfigurera säkra anslutningar mellan lagringsresurser och de virtuella datorerna.

Se Tillämpa Nolltillit principer på ett virtuellt hubbnätverk i Azure för att skydda åtkomsten från hubbresurser till det virtuella nätverket.

Använda principer för MFA och villkorsstyrd åtkomst för användaråtkomst till program

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

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 MFA med villkorlig åtkomst och relaterade principer använder du den rekommenderade principuppsättningen för Nolltillit som en guide. Detta inkluderar startpunktsprinciper 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 kan skyddas av Microsoft Defender för molnet 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 Defender för molnet ett CSPM- och CWP-verktyg (Cloud Security Posture Management) som erbjuder säkerhetsrekommendationer, aviseringar och avancerade funktioner som anpassningsbar nätverkshärdning som hjälper dig när du går vidare med molnsäkerhetsresan.

Den här artikeln beskriver inte Defender för molnet i detalj, men det är viktigt att förstå att 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 och andra. Överväg att prioritera för att lösa rekommendationer som har större inverkan på organisationens säkerhetspoäng. Här följer ett exempel.

Det finns Defender för molnet planer som erbjuder avancerade arbetsbelastningsskydd som innehåller rekommendationer för anpassningsbar nätverkshärdning 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
• Utforma och implementera privat åtkomst till Azure Services

Nästa steg

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

• För Azure IaaS:
  • Översikt
  • Azure Storage
  • Virtuella datorer
  • Virtuella ekernätverk
  • Virtuella hubbnätverk
• Azure Virtual Desktop
• Azure Virtual WAN
• IaaS-program i Amazon Web Services
• Microsoft Sentinel och Microsoft Defender XDR

Referenser

• Hantera proaktiv säkerhet med Nolltillit
• Skydda nätverk med Nolltillit
• Nätverk med noll förtroende för webbprogram med Azure Firewall och Application Gateway
• Principer för Azure-landningszon
• Vanliga Nolltillit identitet och enhet mellan principer
• Vad är en privat slutpunkt?
• DNS-konfiguration för privat slutpunkt
• Integrera din app med ett virtuellt Azure-nätverk
• Använda privata slutpunkter för App Service-appar
• Anslut till en Azure SQL-server med en privat Azure-slutpunkt