Rekommendationer för nätverk och anslutningar

Artikel
11/15/2023

Gäller för denna checklista för Azure Well-Architected Framework Security:

SE:05	Isolera, filtrera och kontrollera nätverkstrafik över både inkommande och utgående flöden. Tillämpa principer för skydd på djupet genom att använda lokaliserade nätverkskontroller vid alla tillgängliga nätverksgränser över både öst-västlig och nord-syd-trafik.

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 åtgärder för åtkomstkontroll. 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 hindra angripare från att komma in i din arbetsbelastning.

Definitioner

Period	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ätverkstransformering	En mekanism som muterar nätverkspaket för att dölja dem.
Nord-sydtrafik	Nätverkstrafik som flyttas från en betrodd gräns till externa nätverk som kan vara fientliga och vice versa.

Viktiga designstrategier

Nätverkssäkerhet använder dunkel 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äkerhetsdesignen bygger på tre huvudstrategier:

Segment. Den här tekniken isolerar trafik i separata nätverk genom att lägga till gränser. Trafik till och från en programnivå passerar till exempel en gräns för att kommunicera med andra nivåer, som har olika säkerhetskrav. Segmenteringslager gör att djupskyddsmetoden kan hanteras.

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 kanten 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.
Filtrera. 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 avslöja en SQL-inmatningsattack.
Transformera. Mutera paket vid gränsen som en säkerhetsåtgärd. Du kan till exempel ta bort HTTP-huvuden för att eliminera risken för exponering. Du kan också 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öden

Det första steget i att klassificera flöden är att studera ett schema för din arbetsbelastningsarkitektur. Från schemat fastställer du avsikten och egenskaperna för flödet med avseende på den funktionella nyttan och driftsaspekterna av din arbetsbelastning. Använd följande frågor för att klassificera flödet:

Om arbetsbelastningen behöver kommunicera med externa nätverk, vad ska den nödvändiga närhetsnivån till dessa nätverk vara?
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 programmet och andra komponenter kan nås från det offentliga Internet. Programmet exponeras via en eller flera offentliga IP-adresser och DNS-servrar (Public 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 bara 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. Dessa alternativ kan ge säkerhetsgarantier.

Även med offentliga arbetsbelastningar bör du sträva efter att hålla så mycket av arbetsbelastningen privat som möjligt. Den här metoden tvingar paket att passera genom en privat gräns när de anländer 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 föregående uppsättning nyckelstrategier för att skydda ingressen. Ta reda på vad trafikkällan är och om den förväntas, tillåts och är säker. Angripare som genomsöker IP-adressintervall för offentliga molnleverantörer 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 är förväntat, tillåtet och säkert. Målet kan vara skadligt eller associerat med dataexfiltreringsrisker.

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

Påverkans omfattning

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.

Ingress och utgående trafik kan båda vara nord-syd-trafik.

Tänk till exempel på utgående flöde för en nätverkstopologi med nav-ekrar. 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 ekerns virtuella nätverk 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 potentiellt är fientligt.
Öst-väst. Trafik som flödar i ett arbetsbelastningsnätverk är öst-västlig trafik. Den här typen av trafik resulterar i att 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 öst-västlig trafik.

Om du vill ge skydd på djupet ska du ha 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 riskreparationsmetoder.

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

Anteckning

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 på alla punkter. Använd en kombination av olika lokaliserade nätverkskontroller vid alla tillgängliga gränser. Mer information finns i Segmenteringsstrategier.

Använda brandväggar vid 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 övervakning, styrning och kontroll av trafik. För ingress 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 är konfigurerade för att stödja behoven i din arbetsbelastning.
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 finns tillgängliga i 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

Segmentera nätverket och börja med nätverkskontroller med lägsta behörighet för att minimera nätverkssynligheten. Om ett segment inte kan dirigeras kan det inte nås. Bredda omfånget så att det endast omfattar 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 sorterar 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 beskrivs tidigare i den här artikeln i Viktiga designstrategier. 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å trafikens protokoll, källa och mål .

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 mappar du ut dina Azure-resurser ur ett nätverksperspektiv och utvärderar 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 ingår inte i 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 dataplanet exponeras.

Som utgångspunkt kan du avgöra 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å servicenivå 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.

Anteckning

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. Slutpunkten gör att andra resurser i nätverket kan kommunicera med PaaS-tjänsten över den privata IP-adressen.

Kommunikation med en PaaS-tjänst uppnås med hjälp av tjänstens offentliga IP-adress och DNS-post. Den 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 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.

Anteckning

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 betald tjä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.

Information om 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 djupgående funktioner i nätverket.

Azure Virtual Network

Virtual Network 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 kommunicera utgående 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.

Edge-säkerhet

Som standard flödar inkommande och utgående båda över offentliga IP-adresser. Beroende på tjänst eller topologi anger du dessa adresser eller så tilldelar Azure dem. Andra ingress- och utgående möjligheter är att skicka trafik via en lastbalanserare eller NAT-gateway (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 FTP (File Transfer Protocol). Funktionsuppsättningen för Azure Firewall innehåller:
- Målnätverksadressöversättning (DNAT) eller portvidarebefordring.
- Identifiering av intrångsidentifiering och skyddssystem (IDPS).
- Starkt lager 3, lager 4 och fullständigt kvalificerade domännamn (FQDN) nätverksregler.
Anteckning

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:erna tillämpas på undernätsnivå. Som standard flödar trafik från undernät till undernät inte 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.
- Om det är praktiskt kan du undvika FQDN-tjänsttaggar. 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å SNAT-portöversättning (network address translation) för källan. 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 tillhandahåller även andra säkerhetsfunktioner som fokuserar på nivå 7, till exempel hastighetsbegränsning, SQL-inmatningsregler och skript mellan platser.

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. Azure Web Application Firewall implementeringar för den 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ätets eller nätverkskortets (NIC)-nivå. 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 en 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 ingress:
- Virtuell nätverkstrafik från direkta, peerkopplade 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 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 inkommande eller utgående åtkomstbehov.

Risk: Tjänsttaggintervallen är mycket breda så att de passar så många kunder som möjligt. Uppdateringar till 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 peerkopplade 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. Med den här metoden begränsar du omfånget till alla slutpunkter i en viss region.

Vissa taggar är exklusivt 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. All annan typ 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 trafik från undernätet till <mål-IP-adressintervall>: 443/TCP
Målport	Tillåt utgående trafik 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ätverkets siktlinje 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 av en attack. Eftersom nätverkssäkerhetsgrupper arbetar i lager 3 och 4 i OSI-stacken (Open Systems Interconnection) innehåller de bara information om form och riktning. Om din arbetsbelastning till exempel behöver tillåta DNS-trafik till Internet använder du en nätverkssäkerhetsgrupp på Internet:53:UDP. I det här fallet kan en angripare exfiltrera 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åse du upp många diagnostikverktyg, 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 har 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 kopplade till 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 brandväggsregeluppsättningar för tjänsten, bör du aktivera tjänsten. Du kan använda Azure Policy för att aktivera det. Se till att du inte aktiverar alternativet betrodda Azure-tjänster om det inte är aktiverat som standard. På så sätt tas alla beroende tjänster som ingår i reglernas omfång.

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

Privata slutpunkter

Private Link ger dig ett sätt att 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 du har en tjänst som endast är tillgänglig via privata slutpunkter.
Överväg körningsrelaterade problem 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 Protection

Varje egenskap i Azure skyddas av Azure DDoS-infrastrukturskydd utan extra kostnad och utan någon tillagd 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. Skalan och kapaciteten för det globalt distribuerade Azure-nätverket ger skydd mot vanliga attacker på nätverksnivå. 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å it-miljön (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 perimeterr 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-protokoll för att aktivera säker kommunikation.
Offentlig åtkomst till programmet. Ha en brandvägg för webbaserade program (WAF) framför programmet för att skydda den på Layer 7 i nätverkets OSI-lager.
Operatörsåtkomst. Fjärråtkomst via Layer 4 i nätverkets OSI-lager 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 som hub-spoke är säkrare och optimerar kostnaderna. Hubbnätverket ger centraliserat brandväggsskydd till alla peerkopplade 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 inom ett virtuellt nätverk med NSG, en kostnadsfri resurs som filtrerar inkommande och utgående TCP/UDP-kommunikation med hänsyn till 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 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 lösningar för arbetsbelastningsskydd, inklusive nätverksrekommendationer för din miljö.
Trafikanalys: Övervaka dina nätverkskontroller med Trafikanalys. 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 kontroller för nätverkssäkerhetsgrupper och brandväggskontroller för webbaserade program 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 till 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 genom Azure Firewall. Med den här metoden får du 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

Rekommendationer för nätverk och anslutningar