Rekommendationer för nätverk och anslutning

Artikel
11/15/2023

Gäller för den här checklistan för Azure Well-Architected Framework Security:

SE:06	Isolera, filtrera och kontrollera nätverkstrafik över både inkommande och utgående flöden. Tillämpa principer för skydd på djupet med hjälp av lokaliserade nätverkskontroller vid alla tillgängliga nätverksgränser över både trafik öst-väst och nord-syd.

Den här guiden beskriver rekommendationerna för nätverksdesign. Fokus ligger på säkerhetskontroller som kan filtrera, blockera och identifiera angripare som korsar nätverksgränser på olika djup i din arkitektur.

Du kan stärka dina identitetskontroller genom att implementera nätverksbaserade åtkomstkontrollmått. Tillsammans med identitetsbaserad åtkomstkontroll är nätverkssäkerhet en hög prioritet för att skydda tillgångar. Rätt nätverkssäkerhetskontroller kan ge ett djupskyddselement som kan hjälpa till att identifiera och begränsa hot och förhindra angripare från att komma in i din arbetsbelastning.

Definitioner

Term	Definition
Öst-västlig trafik	Nätverkstrafik som flyttas inom en betrodd gräns.
Utgående flöde	Utgående arbetsbelastningstrafik.
Fientligt nätverk	Ett nätverk som inte distribueras som en del av din arbetsbelastning. Ett fientligt nätverk anses vara en hotvektor.
Inkommande flöde	Inkommande arbetsbelastningstrafik.
Nätverksfiltrering	En mekanism som tillåter eller blockerar nätverkstrafik baserat på angivna regler.
Nätverkssegmentering eller isolering	En strategi som delar upp ett nätverk i små, isolerade segment med säkerhetskontroller som tillämpas vid gränserna. Den här tekniken hjälper till att skydda resurser från fientliga nätverk, till exempel Internet.
Nätverkstransformeringen	En mekanism som muterar nätverkspaket för att dölja dem.
Nord-syd-trafik	Nätverkstrafik som flyttas från en betrodd gräns till externa nätverk som är potentiellt fientliga och vice versa.

Viktiga designstrategier

Nätverkssäkerhet använder dunkelhet för att skydda arbetsbelastningstillgångar från fientliga nätverk. Resurser som ligger bakom en nätverksgräns döljs tills gränskontrollerna markerar trafiken som säker att gå vidare. Nätverkssäkerhetsdesign bygger på tre huvudstrategier:

Segment. Den här tekniken isolerar trafik i separata nätverk genom att lägga till gränser. Till exempel passerar trafik till och från en programnivå en gräns för att kommunicera med andra nivåer, som har olika säkerhetskrav. Segmenteringslager aktualiserar metoden för skydd på djupet.

Den främsta säkerhetsgränsen är nätverksgränsen mellan ditt program och offentliga nätverk. Det är viktigt att tydligt definiera den här perimetern så att du upprättar en gräns för isolering av fientliga nätverk. Kontrollerna på den här gränsen måste vara mycket effektiva, eftersom den här gränsen är din första försvarslinje.

Virtuella nätverk ger en logisk gräns. Ett virtuellt nätverk kan avsiktligt inte kommunicera med ett annat virtuellt nätverk om inte gränsen avsiktligt har brutits genom peering. Din arkitektur bör dra nytta av den här starka säkerhetsåtgärden som tillhandahålls av plattformen.

Du kan också använda andra logiska gränser, till exempel utskurna undernät i ett virtuellt nätverk. En fördel med undernät är att du kan använda dem för att gruppera resurser som ligger inom en isoleringsgräns och har liknande säkerhetsgarantier. Du kan sedan konfigurera kontroller på gränsen för att filtrera trafik.
Filter. Den här strategin hjälper till att säkerställa att trafik som kommer in i en gräns förväntas, tillåts och är säker. Ur ett Zero-Trust-perspektiv verifierar filtrering uttryckligen alla tillgängliga datapunkter på nätverksnivå. Du kan placera regler på gränsen för att söka efter specifika villkor.

På rubriknivå kan reglerna till exempel verifiera att trafiken kommer från en förväntad plats eller har en förväntad volym. Men de här kontrollerna räcker inte. Även om trafiken uppvisar förväntade egenskaper kanske nyttolasten inte är säker. Verifieringskontroller kan visa en SQL-inmatningsattack.
Transformera. Mutera paket vid gränsen som ett säkerhetsmått. Du kan till exempel ta bort HTTP-huvuden för att eliminera risken för exponering. Eller så kan du inaktivera TLS (Transport Layer Security) vid ett tillfälle och återupprätta det vid ett annat hopp med ett certifikat som hanteras mer rigoröst.

Klassificera trafikflödena

Det första steget i att klassificera flöden är att studera en schema för din arbetsbelastningsarkitektur. Från schemat bestämmer du avsikten och egenskaperna för flödet med avseende på funktionsverktyget och driftsaspekterna för din arbetsbelastning. Använd följande frågor för att klassificera flödet:

Vad ska den nödvändiga närheten till dessa nätverk vara om arbetsbelastningen behöver kommunicera med externa nätverk?
Vilka nätverksegenskaper har flödet, till exempel det förväntade protokollet och paketens källa och form? Finns det några efterlevnadskrav på nätverksnivå?

Det finns många sätt att klassificera trafikflöden. I följande avsnitt beskrivs vanliga kriterier.

Synlighet från externa nätverk

Offentlig. En arbetsbelastning är offentlig om dess program och andra komponenter kan nås från det offentliga Internet. Programmet exponeras via en eller flera offentliga IP-adresser och offentliga DNS-servrar (Domain Name System).
Privat. En arbetsbelastning är privat om den bara kan nås via ett privat nätverk, till exempel ett virtuellt privat nätverk (VPN). Den exponeras endast via en eller flera privata IP-adresser och potentiellt via en privat DNS-server.

I ett privat nätverk finns det ingen siktlinje från det offentliga Internet till arbetsbelastningen. För gatewayen kan du använda en lastbalanserare eller brandvägg. De här alternativen kan ge säkerhetsgarantier.

Även med offentliga arbetsbelastningar strävar du efter att hålla så mycket av arbetsbelastningen privat som möjligt. Den här metoden tvingar paket att korsa en privat gräns när de kommer från ett offentligt nätverk. En gateway i den sökvägen kan fungera som en övergångspunkt genom att fungera som en omvänd proxy.

Trafikriktning

Ingress. Inkommande trafik är inkommande trafik som flödar mot en arbetsbelastning eller dess komponenter. Använd den föregående uppsättningen nyckelstrategier för att skydda ingressen. Ta reda på vad trafikkällan är och om den är förväntad, tillåten och säker. Angripare som genomsöker IP-adressintervall för den offentliga molnleverantören kan ta sig in i ditt försvar om du inte checkar ingress eller implementerar grundläggande nätverkssäkerhetsåtgärder.
Utgående. Utgående trafik är utgående trafik som flödar bort från en arbetsbelastning eller dess komponenter. Kontrollera utgående trafik genom att avgöra vart trafiken är på väg och om målet förväntas, tillåts och är säkert. Målet kan vara skadligt eller associerat med dataexfiltreringsrisker.

Du kan också fastställa din exponeringsnivå genom att överväga arbetsbelastningens närhet till det offentliga Internet. Programplattformen hanterar till exempel vanligtvis offentliga IP-adresser. Arbetsbelastningskomponenten är lösningens ansikte utåt.

Påverkansområde

Nord-syd. Trafik som flödar mellan ett arbetsbelastningsnätverk och externa nätverk är nord-syd-trafik. Den här trafiken passerar gränsen för nätverket. Externa nätverk kan vara det offentliga Internet, ett företagsnätverk eller något annat nätverk som inte omfattas av din kontroll.

Både ingress och utgående trafik kan vara trafik mellan nord och syd.

Tänk till exempel på utgående flöde för en nätverkstopologi med nav-eker. Du kan definiera nätverksgränsen för din arbetsbelastning så att hubben är ett externt nätverk. I så fall är utgående trafik från det virtuella nätverket för ekern nord-syd-trafik. Men om du tänker på hubbnätverket inom din kontrollsfär utökas trafiken mellan nord och syd till brandväggen i hubben, eftersom nästa hopp är Internet, vilket är potentiellt fientligt.
Öst-väst. Trafik som flödar inom ett arbetsbelastningsnätverk är trafik mellan öst och väst. Den här typen av trafik resulterar när komponenter i din arbetsbelastning kommunicerar med varandra. Ett exempel är trafik mellan nivåerna i ett n-nivåprogram. I mikrotjänster är service-to-service-kommunikation trafik mellan öst och väst.

För att ge skydd på djupet bör du upprätthålla kontroll från slutpunkt till slutpunkt för säkerhetsanvisningarna som ingår i varje hopp eller som du använder när paket korsar interna segment. Olika risknivåer kräver olika metoder för riskreparation.

Föregående diagram illustrerar nätverksförsvaret på djupet i det privata molnet. I det här diagrammet ligger kantlinjen mellan offentliga och privata IP-adressutrymmen betydligt längre från arbetsbelastningen än i det offentliga molndiagrammet. Flera lager separerar Azure-distributionerna från det offentliga IP-adressutrymmet.

Kommentar

Identitet är alltid den primära perimetern. Åtkomsthantering måste tillämpas på nätverksflöden. Använd hanterade identiteter när du använder rollbaserad åtkomstkontroll i Azure (RBAC) mellan komponenter i nätverket.

När du har klassificerat flöden utför du en segmenteringsövning för att identifiera brandväggsinmatningspunkter på kommunikationsvägarna för dina nätverkssegment. När du utformar ditt nätverksförsvar på djupet i alla segment och alla trafiktyper, förutsätter du ett intrång vid alla tidpunkter. Använd en kombination av olika lokaliserade nätverkskontroller vid alla tillgängliga gränser. Mer information finns i Segmenteringsstrategier.

Tillämpa brandväggar på gränsen

Internet edge-trafik är nord-syd-trafik och inkluderar ingress och utgående trafik. För att identifiera eller blockera hot måste en gränsstrategi minimera så många attacker som möjligt till och från Internet.

För utgående trafik skickar du all Internetbunden trafik via en enda brandvägg som ger förbättrad tillsyn, styrning och kontroll av trafik. För inkommande trafik tvingar du all trafik från Internet att gå via en virtuell nätverksinstallation (NVA) eller en brandvägg för webbprogram.

Brandväggar är vanligtvis singletons som distribueras per region i en organisation. Därför delas de mellan arbetsbelastningar och ägs av ett centralt team. Kontrollera att alla NVA:er som du använder har konfigurerats för att stödja arbetsbelastningens behov.
Vi rekommenderar att du använder inbyggda Azure-kontroller så mycket som möjligt.

Förutom interna kontroller kan du även överväga partner-NVA:er som tillhandahåller avancerade eller specialiserade funktioner. Leverantörsprodukter för partnerbrandvägg och brandvägg för webbprogram är tillgängliga på Azure Marketplace.

Beslutet att använda inbyggda funktioner i stället för partnerlösningar bör baseras på organisationens erfarenhet och krav.

Kompromiss: Partnerfunktioner ger ofta avancerade funktioner som kan skydda mot avancerade, men vanligtvis ovanliga, attacker. Konfigurationen av partnerlösningar kan vara komplex och bräcklig eftersom dessa lösningar inte integreras med molnets infrastrukturkontrollanter. Ur ett kostnadsperspektiv är intern kontroll att föredra eftersom det är billigare än partnerlösningar.

Alla tekniska alternativ som du överväger bör tillhandahålla säkerhetskontroller och övervakning för både inkommande och utgående flöden. Information om vilka alternativ som är tillgängliga för Azure finns i avsnittet Edge-säkerhet i den här artikeln.

Utforma säkerhet för virtuellt nätverk och undernät

Det primära målet med ett privat moln är att dölja resurser från det offentliga Internet. Det finns flera sätt att uppnå det här målet:

Flytta till privata IP-adressutrymmen, vilket du kan åstadkomma med hjälp av virtuella nätverk. Minimera nätverkets siktlinje även i dina egna privata nätverk.
Minimera antalet offentliga DNS-poster som du använder för att exponera mindre av din arbetsbelastning.
Lägg till ingress- och utgående nätverksflödeskontroll. Tillåt inte trafik som inte är betrodd.

Segmenteringsstrategi

Om du vill minimera nätverkssynligheten segmentera du nätverket och börja med nätverkskontroller med lägsta behörighet. Om ett segment inte kan dirigeras kan det inte nås. Bredda omfånget till att endast omfatta segment som behöver kommunicera med varandra via nätverksåtkomst.

Du kan segmentera virtuella nätverk genom att skapa undernät. Kriterierna för uppdelning bör vara avsiktliga. När du samlar tjänster i ett undernät kontrollerar du att tjänsterna kan se varandra.

Du kan basera segmenteringen på många faktorer. Du kan till exempel placera olika programnivåer i dedikerade segment. En annan metod är att planera dina undernät baserat på vanliga roller och funktioner som använder välkända protokoll.

Mer information finns i Segmenteringsstrategier.

Brandväggar för undernät

Det är viktigt att inspektera varje undernäts inkommande och utgående trafik. Använd de tre huvudstrategierna som beskrevs tidigare i den här artikeln i Nyckeldesignstrategier. Kontrollera om flödet är förväntat, tillåtet och säkert. Om du vill verifiera den här informationen definierar du brandväggsregler som baseras på protokollet, källan och målet för trafiken.

I Azure anger du brandväggsregler i nätverkssäkerhetsgrupper. Mer information finns i avsnittet Nätverkssäkerhetsgrupper i den här artikeln.

Ett exempel på en undernätsdesign finns i Azure Virtual Network-undernät.

Använda kontroller på komponentnivå

När du har minimerat nätverkets synlighet kan du mappa ut dina Azure-resurser ur ett nätverksperspektiv och utvärdera flödena. Följande typer av flöden är möjliga:

Planerad trafik eller avsiktlig kommunikation mellan tjänster enligt arkitekturdesignen. Du har till exempel planerad trafik när din arkitektur rekommenderar att Azure Functions hämtar meddelanden från Azure Service Bus.
Hanteringstrafik eller kommunikation som sker som en del av tjänstens funktioner. Den här trafiken är inte en del av din design och du har ingen kontroll över den. Ett exempel på hanterad trafik är kommunikationen mellan Azure-tjänsterna i din arkitektur och Azure-hanteringsplanet.

Genom att skilja mellan planerad trafik och hanteringstrafik kan du skapa lokaliserade kontroller eller kontroller på servicenivå. Ha en god förståelse för källan och målet vid varje hopp. Förstå särskilt hur ditt dataplan exponeras.

Som utgångspunkt avgör du om varje tjänst exponeras för Internet. I så fall planerar du hur du begränsar åtkomsten. Om det inte är det placerar du det i ett virtuellt nätverk.

Tjänstbrandväggar

Om du förväntar dig att en tjänst ska exponeras för Internet kan du dra nytta av den brandvägg på tjänstnivå som är tillgänglig för de flesta Azure-resurser. När du använder den här brandväggen kan du ange regler baserat på åtkomstmönster. Mer information finns i avsnittet Azure-tjänstbrandväggar i den här artikeln.

Kommentar

När komponenten inte är en tjänst använder du en värdbaserad brandvägg utöver brandväggar på nätverksnivå. En virtuell dator (VM) är ett exempel på en komponent som inte är en tjänst.

Anslutning till PaaS-tjänster (plattform som en tjänst)

Överväg att använda privata slutpunkter för att skydda åtkomsten till PaaS-tjänster. En privat slutpunkt tilldelas en privat IP-adress från ditt virtuella nätverk. Med slutpunkten kan andra resurser i nätverket kommunicera med PaaS-tjänsten via den privata IP-adressen.

Kommunikation med en PaaS-tjänst uppnås med hjälp av tjänstens offentliga IP-adress och DNS-post. Kommunikationen sker via Internet. Du kan göra kommunikationen privat.

En tunnel från PaaS-tjänsten till ett av dina undernät skapar en privat kanal. All kommunikation sker från komponentens privata IP-adress till en privat slutpunkt i det undernätet, som sedan kommunicerar med PaaS-tjänsten.

I det här exemplet visar bilden till vänster flödet för offentligt exponerade slutpunkter. Till höger skyddas flödet med hjälp av privata slutpunkter.

Mer information finns i avsnittet Privata slutpunkter i den här artikeln.

Kommentar

Vi rekommenderar att du använder privata slutpunkter tillsammans med tjänstbrandväggar. En tjänstbrandvägg blockerar inkommande Internettrafik och exponerar sedan tjänsten privat för interna användare som använder den privata slutpunkten.

En annan fördel med att använda privata slutpunkter är att du inte behöver öppna portarna i brandväggen för utgående trafik. Privata slutpunkter låser all utgående trafik på porten för det offentliga Internet. Anslutningen är begränsad till resurser i nätverket.

Kompromiss: Azure Private Link är en betaltjänst som har mätare för inkommande och utgående data som bearbetas. Du debiteras också för privata slutpunkter.

Skydda mot DDoS-attacker (Distributed Denial of Service)

En DDoS-attack försöker uttömma ett programs resurser för att göra programmet otillgängligt för legitima användare. DDoS-attacker kan riktas mot alla slutpunkter som kan nås offentligt via Internet.

En DDoS-attack är vanligtvis ett massivt, utbrett, geografiskt utspätt missbruk av systemets resurser som gör det svårt att hitta och blockera källan.

Azure Support för att skydda mot dessa attacker finns i avsnittet Azure DDoS Protection i den här artikeln.

Azure-underlättande

Du kan använda följande Azure-tjänster för att lägga till djupskyddsfunktioner i nätverket.

Azure Virtual Network

Virtuellt nätverk hjälper dina Azure-resurser att kommunicera säkert med varandra, internet och lokala nätverk.

Som standard kan alla resurser i ett virtuellt nätverk delta i utgående kommunikation med Internet. Men inkommande kommunikation är begränsad som standard.

Virtual Network erbjuder funktioner för filtrering av trafik. Du kan begränsa åtkomsten på virtuell nätverksnivå med hjälp av en användardefinierad väg (UDR) och en brandväggskomponent. På undernätsnivå kan du filtrera trafik med hjälp av nätverkssäkerhetsgrupper.

Gränssäkerhet

Som standard flödar inkommande och utgående båda över offentliga IP-adresser. Beroende på tjänsten eller topologin anger du antingen dessa adresser eller så tilldelar Azure dem. Andra ingress- och utgående möjligheter är att skicka trafik via en nat-gateway (load balancer) eller network address translation. Men dessa tjänster är avsedda för trafikdistribution och inte nödvändigtvis för säkerhet.

Följande teknikval rekommenderas:

Azure Firewall. Du kan använda Azure Firewall på nätverksgränsen och i populära nätverkstopologier, till exempel hub-spoke-nätverk och virtuella WAN. Du distribuerar vanligtvis Azure Firewall som en utgående brandvägg som fungerar som den sista säkerhetsgrinden innan trafiken går till Internet. Azure Firewall kan dirigera trafik som använder icke-HTTP- och icke-HTTPS-protokoll, till exempel RDP (Remote Desktop Protocol), Secure Shell Protocol (SSH) och File Transfer Protocol (FTP). Funktionsuppsättningen i Azure Firewall innehåller:
- Målnätverksadressöversättning (DNAT) eller portvidarebefordring.
- Identifiering av intrångsidentifiering och skyddssystem (IDPS).
- Starka regler för layer 3, layer 4 och fullständigt kvalificerade domännamn (FQDN).
Kommentar

De flesta organisationer har en tvingad tunnelprincip som tvingar trafik att flöda genom en NVA.

Om du inte använder en virtuell WAN-topologi måste du distribuera en UDR med en NextHopType av Internet till din NVA:s privata IP-adress. UDR tillämpas på undernätsnivå. Som standard flödar inte trafik från undernät till undernät via NVA.

Du kan också använda Azure Firewall samtidigt för ingress. Den kan dirigera HTTP- och HTTPS-trafik. I SKU:er på högre nivå erbjuder Azure Firewall TLS-avslutning så att du kan implementera inspektioner på nyttolastnivå.

Följande metoder rekommenderas:
- Aktivera diagnostikinställningar i Azure Firewall för att samla in trafikflödesloggar, IDPS-loggar och DNS-begärandeloggar.
- Var så specifik som möjligt i regler.
- Undvik FQDN-tjänsttaggar där det är praktiskt. Men när du använder dem använder du den regionala varianten, som tillåter kommunikation med alla slutpunkter i tjänsten.
- Använd IP-grupper för att definiera källor som måste dela samma regler under IP-gruppens livslängd. IP-grupper bör återspegla segmenteringsstrategin.
- Åsidosätt FQDN-regeln för infrastruktur endast om din arbetsbelastning kräver absolut utgående kontroll. Att åsidosätta den här regeln medför en tillförlitlighetsavvägning eftersom kraven på Azure-plattformen ändras för tjänster.
Kompromiss: Azure Firewall kan påverka dina prestanda. Regelordning, kvantitet, TLS-inspektion och andra faktorer kan orsaka betydande svarstider.

Det kan också påverka arbetsbelastningens tillförlitlighet. Det kan uppstå portöverbelastning för källnätverksadressöversättning (SNAT). Du kan lösa problemet genom att lägga till offentliga IP-adresser efter behov.

Risk: För utgående trafik tilldelar Azure en offentlig IP-adress. Den här tilldelningen kan ha en nedströmspåverkan på den externa säkerhetsgrinden.
Azure Web Application Firewall. Den här tjänsten stöder inkommande filtrering och riktar sig endast mot HTTP- och HTTPS-trafik.

Den erbjuder grundläggande säkerhet för vanliga attacker, till exempel hot som OWASP (Open Worldwide Application Security Project) identifierar i OWASP Top 10-dokumentet. Azure Web Application Firewall innehåller även andra säkerhetsfunktioner som fokuserar på nivå 7, till exempel hastighetsbegränsning, SQL-inmatningsregler och skript för flera webbplatser.

Med Azure Web Application Firewall krävs TLS-avslutning eftersom de flesta kontroller baseras på nyttolaster.

Du kan integrera Azure Web Application Firewall med routrar, till exempel Azure Application Gateway eller Azure Front Door. Implementeringar av Azure Web Application Firewall för den här typen av routrar kan variera.

Azure Firewall och Azure Web Application Firewall är inte ömsesidigt uteslutande alternativ. För din gränssäkerhetslösning finns det olika alternativ. Exempel finns i Brandvägg och Application Gateway för virtuella nätverk.

Nätverkssäkerhetsgrupper

En nätverkssäkerhetsgrupp är en layer 3- och layer 4-brandvägg som du tillämpar på undernäts- eller nätverkskortnivån (NIC). Nätverkssäkerhetsgrupper skapas eller tillämpas inte som standard.

Regler för nätverkssäkerhetsgrupper fungerar som en brandvägg för att stoppa trafik som flödar in och ut i perimetern för ett undernät. En nätverkssäkerhetsgrupp har en standardregeluppsättning som är alltför tillåtande. Standardreglerna anger till exempel inte någon brandvägg ur utgående perspektiv. För inkommande trafik tillåts ingen inkommande Internettrafik.

Börja med standardregeluppsättningen för att skapa regler:

För inkommande trafik eller inkommande trafik:
- Virtuell nätverkstrafik från direkt-, peer-kopplade och VPN-gatewaykällor tillåts.
- Azure Load Balancer-hälsoavsökningar tillåts.
- All annan trafik blockeras.
För utgående trafik eller utgående trafik:
- Virtuell nätverkstrafik för att dirigera, peer-kopplade och VPN-gatewaymål tillåts.
- Trafik till Internet tillåts.
- All annan trafik blockeras.

Tänk sedan på följande fem faktorer:

Protokoll
Källans IP-adress
Källport
Mål-IP-adress
Målport

Bristen på stöd för FQDN begränsar nätverkssäkerhetsgruppens funktioner. Du måste ange specifika IP-adressintervall för din arbetsbelastning och de är svåra att underhålla.

Men för Azure-tjänster kan du använda tjänsttaggar för att sammanfatta käll- och mål-IP-adressintervall. En säkerhetsfördel med tjänsttaggar är att de är ogenomskinliga för användaren och att ansvaret avlastas till Azure. Du kan också tilldela en programsäkerhetsgrupp som måltyp att dirigera trafik till. Den här typen av namngiven grupp innehåller resurser som har liknande behov av inkommande eller utgående åtkomst.

Risk: Tjänsttaggintervallen är mycket breda så att de rymmer så många kunder som möjligt. Uppdateringar av tjänsttaggar släpar efter ändringar i tjänsten.

I föregående bild tillämpas nätverkssäkerhetsgrupper på nätverkskortet. Internettrafik och trafik från undernät till undernät nekas. Nätverkssäkerhetsgrupperna tillämpas med taggen VirtualNetwork . Så i det här fallet har undernäten för peer-kopplade nätverk en direkt siktlinje. Den breda definitionen av taggen VirtualNetwork kan ha en betydande säkerhetspåverkan.

När du använder tjänsttaggar använder du regionala versioner när det är möjligt, till exempel Storage.WestUS i stället för Storage. Genom att använda den här metoden begränsar du omfånget till alla slutpunkter i en viss region.

Vissa taggar är uteslutande för inkommande eller utgående trafik. Andra är för båda typerna. Inkommande taggar tillåter vanligtvis trafik från alla värdarbetsbelastningar, till exempel AzureFrontDoor.Backend, eller från Azure för att stödja tjänstkörningar, till exempel LogicAppsManagement. På samma sätt tillåter utgående taggar trafik till alla värdarbetsbelastningar eller från Azure för att stödja tjänstkörningar.

Omfång för reglerna så mycket som möjligt. I följande exempel anges regeln till specifika värden. Alla andra typer av trafik nekas.

Information	Exempel
Protokoll	Transmission Control Protocol (TCP), UDP
Källans IP-adress	Tillåt ingress till undernätet från <source-IP-address-range>: 4575/UDP
Källport	Tillåt ingress till undernätet från <service-tag>: 443/TCP
Mål-IP-adress	Tillåt utgående från undernätet till <mål-IP-adressintervall>: 443/TCP
Målport	Tillåt utgående från undernätet till <service-tag>: 443/TCP

Sammanfattningsvis:

Var exakt när du skapar regler. Tillåt endast trafik som krävs för att programmet ska fungera. Förneka allt annat. Den här metoden begränsar nätverkslinjen till nätverksflöden som behövs för att stödja driften av arbetsbelastningen. Stöd för fler nätverksflöden än nödvändigt leder till onödiga attackvektorer och utökar ytan.

Att begränsa trafiken innebär inte att tillåtna flöden ligger utanför omfattningen för en attack. Eftersom nätverkssäkerhetsgrupper arbetar i lager 3 och 4 på OSI-stacken (Open Systems Interconnection) innehåller de bara form- och riktningsinformation. Om din arbetsbelastning till exempel behöver tillåta DNS-trafik till Internet använder du en nätverkssäkerhetsgrupp med Internet:53:UDP. I det här fallet kan en angripare exfiltera data via UDP på port 53 till någon annan tjänst.
Förstå att nätverkssäkerhetsgrupper kan skilja sig något från varandra. Det är lätt att bortse från avsikten med skillnaderna. Om du vill ha detaljerad filtrering är det säkrare att skapa extra nätverkssäkerhetsgrupper. Konfigurera minst en nätverkssäkerhetsgrupp.
- Om du lägger till en nätverkssäkerhetsgrupp låss många diagnostikverktyg upp, till exempel flödesloggar och analys av nätverkstrafik.
- Använd Azure Policy för att styra trafik i undernät som inte har nätverkssäkerhetsgrupper.
Om ett undernät stöder nätverkssäkerhetsgrupper lägger du till en grupp, även om den har minimal påverkan.

Azure-tjänstbrandväggar

De flesta Azure-tjänster erbjuder en brandvägg på servicenivå. Den här funktionen inspekterar inkommande trafik till tjänsten från angivna CIDR-intervall (classless inter-domain routing). Dessa brandväggar erbjuder fördelar:

De ger en grundläggande säkerhetsnivå.
Det finns en acceptabel prestandapåverkan.
De flesta tjänster erbjuder dessa brandväggar utan extra kostnad.
Brandväggarna genererar loggar via Azure-diagnostik, vilket kan vara användbart för att analysera åtkomstmönster.

Men det finns också säkerhetsproblem som är associerade med dessa brandväggar, och det finns begränsningar som är associerade med att tillhandahålla parametrar. Om du till exempel använder Microsoft-värdbaserade byggagenter måste du öppna IP-adressintervallet för alla Microsoft-värdbaserade byggagenter. Intervallet är sedan öppet för din byggagent, andra klienter och angripare som kan missbruka din tjänst.

Om du har åtkomstmönster för tjänsten, som kan konfigureras som regeluppsättningar för tjänstens brandvägg, bör du aktivera tjänsten. Du kan använda Azure Policy för att aktivera den. Se till att du inte aktiverar alternativet betrodda Azure-tjänster om det inte är aktiverat som standard. Detta innebär att alla beroende tjänster som ingår i reglernas omfång tas med.

Mer information finns i produktdokumentationen för enskilda Azure-tjänster.

Privata slutpunkter

Med Private Link kan du ge en PaaS-instans en privat IP-adress. Tjänsten kan sedan inte nås via Internet. Privata slutpunkter stöds inte för alla SKU:er.

Tänk på följande rekommendationer när du använder privata slutpunkter:

Konfigurera tjänster som är bundna till virtuella nätverk för att kontakta PaaS-tjänster via privata slutpunkter, även om dessa PaaS-tjänster också behöver erbjuda offentlig åtkomst.
Främja användningen av nätverkssäkerhetsgrupper för privata slutpunkter för att begränsa åtkomsten till privata slutpunkts-IP-adresser.
Använd alltid tjänstbrandväggar när du använder privata slutpunkter.
Om det är möjligt tar du bort DNS-konfigurationen för dess offentliga slutpunkt om det är möjligt en tjänst som endast är tillgänglig via privata slutpunkter.
Överväg körningsproblem när du implementerar privata slutpunkter. Men tänk också på DevOps och övervakningsproblem.
Använd Azure Policy för att framtvinga resurskonfiguration.

Kompromiss: Tjänst-SKU:er med privata slutpunkter är dyra. Privata slutpunkter kan komplicera åtgärder på grund av nätverksdefiniering. Du måste lägga till lokalt installerade agenter, hopprutor, ett VPN och andra komponenter i din arkitektur.

DNS-hantering kan vara komplex i vanliga nätverkstopologier. Du kan behöva introducera DNS-vidarebefordrare och andra komponenter.

Virtuell nätverksinmatning

Du kan använda inmatningsprocessen för virtuella nätverk för att distribuera vissa Azure-tjänster till nätverket. Exempel på sådana tjänster är Azure App Service, Functions, Azure API Management och Azure Spring Apps. Den här processen isolerar programmet från Internet, system i privata nätverk och andra Azure-tjänster. Inkommande och utgående trafik från programmet tillåts eller nekas baserat på nätverksregler.

Azure Bastion

Du kan använda Azure Bastion för att ansluta till en virtuell dator med hjälp av webbläsaren och Azure Portal. Azure Bastion förbättrar säkerheten för RDP- och SSH-anslutningar. Ett vanligt användningsfall omfattar anslutning till en hoppruta i samma virtuella nätverk eller ett peer-kopplat virtuellt nätverk. Om du använder Azure Bastion tar du bort behovet av att den virtuella datorn har en offentlig IP-adress.

Azure DDoS-skydd

Varje egenskap i Azure skyddas av Azure DDoS-infrastrukturskydd utan extra kostnad och utan ytterligare konfiguration. Skyddsnivån är grundläggande, men skyddet har höga tröskelvärden. Den tillhandahåller inte heller telemetri eller aviseringar, och den är arbetsbelastningsagnostisk.

SKU:er med högre nivå för DDoS Protection är tillgängliga men är inte kostnadsfria. Skalning och kapacitet för det globalt distribuerade Azure-nätverket ger skydd mot vanliga nätverksnivåattacker. Tekniker som alltid på trafikövervakning och realtidsreducering ger den här funktionen.

Mer information finns i Översikt över Azure DDoS Protection.

Exempel

Här följer några exempel som visar användningen av nätverkskontroller som rekommenderas i den här artikeln.

IT-miljö

Det här exemplet bygger på den IT-miljö (Information Technology) som upprättats i säkerhetsbaslinjen (SE:01). Den här metoden ger en bred förståelse för nätverkskontroller som tillämpas på olika perimeterer för att begränsa trafiken.

Personas för nätverksattacker. Flera personer kan övervägas i en nätverksattack, inklusive administratörer, anställda, kundens klienter och anonyma angripare.
VPN-åtkomst. En dålig aktör kan komma åt den lokala miljön via ett VPN eller en Azure-miljö som är ansluten till den lokala miljön via ett VPN. Konfigurera med IPSec-protokollet för att aktivera säker kommunikation.
Offentlig åtkomst till programmet. Ha en brandvägg för webbprogram (WAF) framför programmet för att skydda den på Layer 7 i nätverkets OSI-lager.
Operatoråtkomst. Fjärråtkomst via Layer 4 i nätverks-OSI-skikt måste skyddas. Överväg att använda Azure Firewall med IDP/IDS-funktioner.
DDoS-skydd. Ha DDoS-skydd för hela ditt virtuella nätverk.
Nätverkstopologi. En nätverkstopologi, till exempel hub-spoke, är säkrare och optimerar kostnaderna. Hubbnätverket ger centraliserat brandväggsskydd till alla peer-kopplade ekrar.
Privata slutpunkter: Överväg att lägga till offentligt exponerade tjänster i ditt privata nätverk med hjälp av privata slutpunkter. Dessa skapar ett nätverkskort (NIC) i ditt privata virtuella nätverk och binder till Azure-tjänsten.
TLS-kommunikation. Skydda data under överföring genom att kommunicera via TLS.
Nätverkssäkerhetsgrupp (NSG): Skydda segment i ett virtuellt nätverk med NSG, en kostnadsfri resurs som filtrerar TCP/UDP inkommande och utgående kommunikation med tanke på IP- och portintervall. En del av NSG är programsäkerhetsgruppen (ASG) som gör att du kan skapa taggar för trafikregler för enklare hantering.
Log Analytics. Azure-resurser genererar telemetri som matas in i Log Analytics och som sedan används med en SIEM-lösning som Microsoft Sentinel för analys.
Microsoft Sentinel-integrering. Log Analytics är integrerat med Microsoft Sentinel och andra lösningar som Microsoft Defender för molnet.
Microsoft Defender för molnet. Microsoft Defender för molnet levererar många arbetsbelastningsskyddslösningar, inklusive nätverksrekommendationer för din miljö.
Trafikanalys: Övervaka dina nätverkskontroller med Traffic Analytics. Detta konfigureras via Network Watcher, en del av Azure Monitor, och aggregerar inkommande och utgående träffar i dina undernät som samlas in av NSG.

Arkitektur för en containerbaserad arbetsbelastning

Den här exempelarkitekturen kombinerar de nätverkskontroller som beskrivs i den här artikeln. Exemplet visar inte den fullständiga arkitekturen. I stället fokuserar den på ingresskontroller i det privata molnet.

Application Gateway är en lastbalanserare för webbtrafik som du kan använda för att hantera trafik till dina webbprogram. Du distribuerar Application Gateway i ett dedikerat undernät som har nätverkssäkerhetsgruppkontroller och brandväggskontroller för webbprogram på plats.

Kommunikation med alla PaaS-tjänster sker via privata slutpunkter. Alla slutpunkter placeras i ett dedikerat undernät. DDoS Protection hjälper till att skydda alla offentliga IP-adresser som är konfigurerade för en grundläggande eller högre nivå av brandväggsskydd.

Hanteringstrafiken begränsas via Azure Bastion, vilket ger säker och sömlös RDP- och SSH-anslutning till dina virtuella datorer direkt från Azure Portal via TLS. Byggagenter placeras i det virtuella nätverket så att de har en nätverksvy för arbetsbelastningsresurser som beräkningsresurser, containerregister och databaser. Den här metoden hjälper dig att tillhandahålla en säker och isolerad miljö för dina byggagenter, vilket ökar skyddet för din kod och artefakter.

Nätverkssäkerhetsgrupper på undernätsnivå för beräkningsresurserna begränsar utgående trafik. Tvingad tunneltrafik används för att dirigera all trafik via Azure Firewall. Den här metoden hjälper dig att tillhandahålla en säker och isolerad miljö för dina beräkningsresurser, vilket ökar skyddet för dina data och program.

Säkerhetskontrollista

Se den fullständiga uppsättningen rekommendationer.

Säkerhetskontrollista

Dela via

Rekommendationer för nätverk och anslutning