Tillämpa Nolltillit principer för kryptering av Azure-baserad nätverkskommunikation

Den här artikeln innehåller vägledning om hur du tillämpar principerna för Nolltillit för kryptering av nätverkskommunikation till, från och mellan Azure-miljöer på följande sätt.

Nolltillit princip Definition Uppfylld av
Verifiera explicit Autentisera och auktorisera alltid baserat på alla tillgängliga datapunkter. Använda principer för villkorlig åtkomst för dina Azure VPN Gateway-anslutningar och Secure Shell (SSH) och RDP (Remote Desktop Protocol) för dina anslutningar mellan användare och virtuella datorer.
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. Konfigurera dina Microsoft Enterprise Edge-enheter (MSEE) till att använda en statisk anslutningsassociationsnyckel (CAK) för Azure ExpressRoute med direktportar och använda hanterad identitet för att autentisera ExpressRoute-kretsresurser.
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. Skydda nätverkstrafiken med krypteringsmetoder och protokoll som ger konfidentialitet, integritet och äkthet för dina data under överföring.

Använda Azure Monitor för att tillhandahålla prestandamått och aviseringar för ExpressRoute-nätverk.

Använda Azure Bastion för att hantera enskilda sessioner från Bastion-tjänsten och ta bort eller tvinga fram en frånkoppling.

Krypteringsnivåer för nätverkstrafik är:

  • Kryptering på nätverksnivå

    • Skydda och verifiera kommunikationen från Internet eller ditt lokala nätverk till virtuella Azure-nätverk och virtuella datorer

    • Skydda och verifiera kommunikationen inom och över virtuella Azure-nätverk

  • Kryptering på programnivå

    • Skydd för Azure-webbprogram
  • Skydd för arbetsbelastningar som körs på virtuella Azure-datorer

Referensarkitektur

Följande diagram visar referensarkitekturen för den här Nolltillit vägledning för krypterad kommunikation mellan användare och administratörer lokalt eller på Internet och komponenter i Azure-miljön för de steg som beskrivs i den här artikeln.

Referensarkitekturen för Azure-nätverkskomponenter med kryptering och Nolltillit principer som tillämpas.

I diagrammet motsvarar siffrorna stegen i följande avsnitt.

Vad finns i den här artikeln?

Nolltillit principer tillämpas i referensarkitekturen, från användare och administratörer på Internet eller ditt lokala nätverk till och i Azure-molnet. I följande tabell beskrivs rekommendationerna för att säkerställa kryptering av nätverkstrafik i den här arkitekturen.

Steg Aktivitet Nolltillit principer som tillämpas
1 Implementera kryptering på nätverksnivå. Verifiera explicit
Använd minst privilegierad åtkomst
Anta intrång
2 Skydda och verifiera kommunikationen från ett lokalt nätverk till virtuella Azure-nätverk. Verifiera explicit
Anta intrång
3 Skydda och verifiera kommunikationen inom och över virtuella Azure-nätverk. Anta intrång
4 Implementera kryptering på programnivå. Verifiera explicit
Anta intrång
5 Använd Azure Bastion för att skydda virtuella Azure-datorer. Anta intrång

Steg 1: Implementera kryptering på nätverksnivå

Kryptering på nätverksnivå är viktigt när du använder Nolltillit principer för din lokala miljö och Azure-miljö. När nätverkstrafiken går via Internet bör du alltid anta att det finns en risk för trafikavlyssning av angripare och att dina data kan exponeras eller ändras innan de når målet. Eftersom tjänsteleverantörer styr hur data dirigeras via Internet vill du se till att sekretessen och integriteten för dina data bevaras från det ögonblick det lämnar ditt lokala nätverk hela vägen till Microsofts moln.

Följande diagram visar referensarkitekturen för implementering av nätverksskiktskryptering.

Referensarkitekturen för implementering av nätverksskiktskryptering för Azure-nätverk.

I de kommande två avsnitten diskuterar vi Internet Protocol Security (IPsec) och Media Access Control Security (MACsec), vilka Azure-nätverkstjänster som stöder dessa protokoll och hur du kan se till att de används.

IPsec

IPsec är en grupp protokoll som tillhandahåller säkerhet för IP-kommunikation (Internet Protocol). Den autentiserar och krypterar nätverkspaket med hjälp av en uppsättning krypteringsalgoritmer. IPSec är säkerhetssammankapslingsprotokollet som används för att upprätta virtuella privata nätverk (VPN). En IPsec VPN-tunnel består av två faser, fas 1 som kallas huvudläge och fas 2 som kallas snabbläge.

Fas 1 av IPsec är tunneletablering, där peer-datorer förhandlar om parametrar för IKE-säkerhetsassociationen (Internet Key Exchange), till exempel kryptering, autentisering, hashning och Diffie-Hellman-algoritmer. För att verifiera sina identiteter utbyter peer-datorer en i förväg delad nyckel. Fas 1 av IPsec kan köras i två lägen: huvudläge eller aggressivt läge. Azure VPN Gateway stöder två versioner av IKE, IKEv1 och IKEv2, och fungerar endast i huvudläge. Huvudläget säkerställer kryptering av identiteten för anslutningen mellan Azure VPN Gateway och den lokala enheten.

I fas 2 av IPsec förhandlar peer-datorer om säkerhetsparametrar för dataöverföring. I den här fasen är båda peer-datorerna överens om krypterings- och autentiseringsalgoritmerna, livslängdsvärdet för säkerhetsassociationen (SA) och trafikväljare (TS) som definierar vilken trafik som krypteras via IPsec-tunneln. Tunneln som skapades i fas 1 fungerar som en säker kanal för den här förhandlingen. IPsec kan skydda IP-paket med hjälp av autentiseringshuvudprotokollet (AH) eller ESP-protokollet (Encapsulating Security Payload). AH tillhandahåller integritet och autentisering, medan ESP även tillhandahåller konfidentialitet (kryptering). IPsec fas 2 kan köras i antingen transportläge eller tunnelläge. I transportläge krypteras bara nyttolasten för IP-paketet, medan hela IP-paketet krypteras i tunnelläge och ett nytt IP-huvud läggs till. IPsec fas 2 kan upprättas ovanpå antingen IKEv1 eller IKEv2. Den aktuella IPsec-implementeringen av Azure VPN Gateway stöder endast ESP i tunnelläge.

Några av de Azure-tjänster som stöder IPsec är:

  • Azure VPN Gateway

    • Plats-till-plats-VPN-anslutningar

    • Anslutningar mellan virtuella nätverk

    • Punkt-till-plats-anslutningar

  • Azure Virtual WAN

    • VPN-webbplatser

    • Vpn-konfigurationer för användare

Det finns inga inställningar som du behöver ändra för att aktivera IPsec för dessa tjänster. De är aktiverade som standard.

MACsec och Azure Key Vault

MACsec (IEEE 802.1AE) är en nätverkssäkerhetsstandard som tillämpar principen Anta intrång Nolltillit på datalänklagret genom att tillhandahålla autentisering och kryptering via en Ethernet-länk. MACsec förutsätter att all nätverkstrafik, även i samma lokala nätverk, kan komprometteras eller fångas upp av skadliga aktörer. MACsec verifierar och skyddar varje bildruta med hjälp av en säkerhetsnyckel som delas mellan två nätverksgränssnitt. Den här konfigurationen kan bara utföras mellan två MACsec-kompatibla enheter.

MACsec konfigureras med anslutningsassociationer, som är en uppsättning attribut som nätverksgränssnitt använder för att skapa inkommande och utgående säkerhetskanaler. När den har skapats utbyts trafik via dessa kanaler över två MACsec-skyddade länkar. MACsec har två anslutningsassocieringslägen:

  • Cak-läge (Static Connectivity Association Key): MACsec-skyddade länkar upprättas med hjälp av en i förväg delad nyckel som innehåller ett namn på anslutningsassociationens nyckel (CKN) och den tilldelade CAK:en. Dessa nycklar konfigureras i båda ändar av länken.
  • Dynamiskt CAK-läge: Säkerhetsnycklarna genereras dynamiskt med autentiseringsprocessen 802.1x, som kan använda en centraliserad autentiseringsenhet, till exempel en RADIUS-server (Remote Authentication Dial-In User Service).

Microsoft Enterprise Edge-enheter (MSEE) stöder statisk CAK genom att lagra CAK och CKN i ett Azure Key Vault när du konfigurerar Azure ExpressRoute med direktportar. Om du vill komma åt värdena i Azure Key Vault konfigurerar du hanterad identitet för att autentisera ExpressRoute-kretsresursen. Den här metoden följer principen Använd minst privilegierad åtkomst Nolltillit eftersom endast auktoriserade enheter kan komma åt nycklarna från Azure Key Vault. Mer information finns i Konfigurera MACsec på ExpressRoute Direct-portar.

Steg 2: Skydda och verifiera kommunikationen från ett lokalt nätverk till virtuella Azure-nätverk

I takt med att molnmigreringen blir vanligare för företag med olika skalning spelar hybridanslutningar en viktig roll. Det är viktigt att inte bara skydda och skydda, utan även att verifiera och övervaka nätverkskommunikationen mellan ditt lokala nätverk och Azure.

Följande diagram visar referensarkitekturen för att skydda och verifiera kommunikation från ett lokalt nätverk till virtuella Azure-nätverk.

Referensarkitekturen för att skydda och verifiera kommunikationen från ett lokalt nätverk till virtuella Azure-nätverk.

Azure har två alternativ för att ansluta ditt lokala nätverk till resurser i ett virtuellt Azure-nätverk:

  • Med Azure VPN Gateway kan du skapa en plats-till-plats-VPN-tunnel med hjälp av IPsec för att kryptera och autentisera nätverkskommunikation mellan nätverket på centrala eller fjärranslutna kontor och ett virtuellt Azure-nätverk. Det gör också att enskilda klienter kan upprätta en punkt-till-plats-anslutning för att komma åt resurser i ett virtuellt Azure-nätverk utan EN VPN-enhet. För Nolltillit efterlevnad konfigurerar du Entra ID-autentisering och principer för villkorsstyrd åtkomst för dina Azure VPN Gateway-anslutningar för att verifiera identiteten och efterlevnaden för de anslutande enheterna. Mer information finns i Använda Microsoft Tunnel VPN-gateway med principer för villkorsstyrd åtkomst.

  • Azure ExpressRoute tillhandahåller en privat anslutning med hög bandbredd som gör att du kan utöka ditt lokala nätverk till Azure med hjälp av en anslutningsleverantör. Eftersom nätverkstrafiken inte färdas via det offentliga Internet krypteras inte data som standard. Konfigurera en IPsec-tunnel för att kryptera trafiken via ExpressRoute. Tänk dock på att när du kör IPsec-tunnlar via ExpressRoute är bandbredden begränsad till tunnelbandbredden och du kan behöva köra flera tunnlar för att matcha ExpressRoute-kretsens bandbredd. Mer information finns i Plats-till-plats-VPN-anslutningar via privat ExpressRoute-peering – Azure VPN Gateway.

    Om du använder ExpressRoute Direct-portar kan du öka nätverkssäkerheten genom att aktivera autentisering när du upprättar BGP-peer-datorer eller konfigurerar MACsec för säker layer 2-kommunikation. MACsec tillhandahåller kryptering för Ethernet-ramar, vilket säkerställer datasekretess, integritet och äkthet mellan gränsroutern och Microsofts gränsrouter.

    Azure ExpressRoute har också stöd för Azure Monitor för prestandamått och aviseringar för nätverk.

Kryptering kan skydda dina data från obehörig avlyssning, men det ger också ett extra lager av bearbetning för kryptering och dekryptering av nätverkstrafik som kan påverka prestanda. Nätverkstrafik som går via Internet kan också vara oförutsägbar eftersom den måste färdas via flera nätverksenheter som kan introducera nätverksfördröjning. För att undvika prestandaproblem rekommenderar Microsoft att du använder ExpressRoute eftersom det erbjuder tillförlitlig nätverksprestanda och bandbreddsallokering som du kan anpassa för din arbetsbelastning.

När du bestämmer dig mellan Azure VPN Gateway eller ExpressRoute bör du tänka på följande frågor:

  1. Vilka typer av filer och program har du åtkomst till mellan ditt lokala nätverk och Azure? Behöver du konsekvent bandbredd för överföring av stora mängder data?
  2. Behöver du konsekvent och låg svarstid för att dina program ska fungera optimalt?
  3. Behöver du övervaka nätverksprestanda och hälsotillstånd för din hybridanslutning?

Om du svarade ja på någon av dessa frågor bör Azure ExpressRoute vara den primära metoden för att ansluta ditt lokala nätverk till Azure.

Det finns två vanliga scenarier där ExpressRoute och Azure VPN Gateway kan samexistera:

  • Azure VPN Gateway kan användas för att ansluta dina avdelningskontor till Azure samtidigt som huvudkontoret är anslutet med ExpressRoute.
  • Du kan också använda Azure VPN Gateway som en säkerhetskopieringsanslutning till Azure för ditt centrala kontor om ExpressRoute-tjänsten har ett avbrott.

Steg 3: Skydda och verifiera kommunikationen inom och över virtuella Azure-nätverk

Trafiken i Azure har en underliggande krypteringsnivå. När trafiken flyttas mellan virtuella nätverk i olika regioner använder Microsoft MACsec för att kryptera och autentisera peeringtrafik på datalänklagret.

Följande diagram visar referensarkitekturen för att skydda och verifiera kommunikationen inom och över virtuella Azure-nätverk.

Referensarkitekturen för att skydda och verifiera kommunikation inom och mellan virtuella Azure-nätverk.

Enbart kryptering räcker dock inte för att säkerställa Nolltillit. Du bör också verifiera och övervaka nätverkskommunikationen inom och över virtuella Azure-nätverk. Ytterligare kryptering och verifiering mellan virtuella nätverk är möjliga med hjälp av Azure VPN Gateway eller virtuella nätverksinstallationer (NVA) men det är inte vanligt. Microsoft rekommenderar att du utformar nätverkstopologin så att den använder en centraliserad trafikkontrollmodell som kan framtvinga detaljerade principer och identifiera avvikelser.

Om du vill minska kostnaderna för att konfigurera en VPN-gateway eller virtuell installation aktiverar du VNet-krypteringsfunktionen för vissa storlekar på virtuella datorer för att kryptera och verifiera trafik mellan virtuella datorer på värdnivå, inom ett VNet och mellan VNet-peerings.

Steg 4: Implementera kryptering på programnivå

Kryptering på programnivå spelar en nyckelfaktor för Nolltillit som kräver att alla data och all kommunikation krypteras när användare interagerar med webbprogram eller enheter. Kryptering på programnivå säkerställer att endast verifierade och betrodda entiteter kan komma åt webbprogram eller enheter.

Följande diagram visar referensarkitekturen för implementering av kryptering på programnivå.

Referensarkitekturen för att implementera kryptering på programnivå.

Ett av de vanligaste exemplen på kryptering på programlagret är Hypertext Transfer Protocol Secure (HTTPS), som krypterar data mellan en webbläsare och en webbserver. HTTPS använder TLS-protokollet (Transport Layer Security) för att kryptera klient-serverkommunikation och använder ett digitalt TLS-certifikat för att verifiera identiteten och pålitligheten för webbplatsen eller domänen.

Ett annat exempel på säkerhet på programnivå är Secure Shell (SSH) och Remote Desktop Protocol (RDP) som krypterar data mellan klienten och servern. Dessa protokoll stöder även multifaktorautentisering och principer för villkorsstyrd åtkomst för att säkerställa att endast auktoriserade och kompatibla enheter eller användare kan komma åt fjärrresurser. Se Steg 5 för information om hur du skyddar SSH- och RDP-anslutningar till virtuella Azure-datorer.

Skydd för Azure-webbprogram

Du kan använda Azure Front Door eller Azure Application Gateway för att skydda dina Azure-webbprogram.

Azure Front Door

Azure Front Door är en global distributionstjänst som optimerar innehållsleveransen till slutanvändare via Microsofts gränsplatser. Med funktioner som Web Application Firewall (WAF) och Private Link-tjänsten kan du identifiera och blockera skadliga attacker på dina webbprogram i utkanten av Microsoft-nätverket när du har privat åtkomst till ditt ursprung med hjälp av Microsofts interna nätverk.

För att skydda dina data skyddas trafik till Azure Front Door-slutpunkter med HTTPS med TLS från slutpunkt till slutpunkt för all trafik som går till och från dess slutpunkter. Trafiken krypteras från klienten till ursprunget och från ursprunget till klienten.

Azure Front Door hanterar HTTPS-begäranden och avgör vilken slutpunkt i profilen som har det associerade domännamnet. Sedan kontrollerar den sökvägen och avgör vilken routningsregel som matchar sökvägen för begäran. Om cachelagring är aktiverat kontrollerar Azure Front Door cacheminnet för att se om det finns ett giltigt svar. Om det inte finns något giltigt svar väljer Azure Front Door det bästa ursprunget som kan hantera det begärda innehållet. Innan begäran skickas till ursprunget kan en regeluppsättning tillämpas på begäran för att ändra huvudet, frågesträngen eller ursprungsmålet.

Azure Front Door stöder både klientdels- och serverdels-TLS. Klientdelens TLS krypterar trafiken mellan klienten och Azure Front Door. Backend-TLS krypterar trafiken mellan Azure Front Door och ursprunget. Azure Front Door stöder TLS 1.2 och TLS 1.3. Du kan konfigurera Azure Front Door till att använda ett anpassat TLS-certifikat eller använda ett certifikat som hanteras av Azure Front Door.

Kommentar

Du kan också använda funktionen Private Link för anslutning till NVA:er för ytterligare paketgranskning.

Azure Application Gateway

Azure Application Gateway är en regional lastbalanserare som fungerar på Layer 7. Den dirigerar och distribuerar webbtrafik baserat på HTTP-URL-attribut. Den kan dirigera och distribuera trafik med tre olika metoder:

  • Endast HTTP: Application Gateway tar emot och dirigerar inkommande HTTP-begäranden till rätt mål i okrypterat format.
  • SSL-avslutning: Application Gateway dekrypterar inkommande HTTPS-begäranden på instansnivå, inspekterar dem och dirigerar dem okrypterade till målet.
  • TLS från slutpunkt till slutpunkt: Application Gateway dekrypterar inkommande HTTPS-begäranden på instansnivå, inspekterar dem och krypterar dem igen innan de dirigeras till målet.

Det säkraste alternativet är TLS från slutpunkt till slutpunkt, vilket möjliggör kryptering och överföring av känsliga data genom att kräva användning av autentiseringscertifikat eller betrodda rotcertifikat. Det kräver också att dessa certifikat laddas upp till serverdelsservrarna och att dessa serverdelsservrar är kända för Application Gateway. Mer information finns i Konfigurera TLS från slutpunkt till slutpunkt med hjälp av Application Gateway.

Dessutom kan lokala användare eller användare på virtuella datorer i ett annat virtuellt nätverk använda den interna klientdelen av Application Gateway med samma TLS-funktioner. Tillsammans med kryptering rekommenderar Microsoft att du alltid aktiverar WAF för mer klientdelsskydd för dina slutpunkter.

Steg 5: Använda Azure Bastion för att skydda virtuella Azure-datorer

Azure Bastion är en hanterad PaaS-tjänst som gör att du på ett säkert sätt kan ansluta till dina virtuella datorer via en TLS-anslutning. Den här anslutningen kan upprättas från Azure-portalen eller via en intern klient till den privata IP-adressen på den virtuella datorn. Fördelarna med att använda Bastion är:

  • Virtuella Azure-datorer behöver ingen offentlig IP-adress. Anslut joner finns över TCP-port 443 för HTTPS och kan passera de flesta brandväggar.
  • Virtuella datorer skyddas mot portgenomsökning.
  • Azure Bastion-plattformen uppdateras ständigt och skyddas mot nolldagsexploateringar.

Med Bastion kan du styra RDP- och SSH-anslutningen till den virtuella datorn från en enda startpunkt. Du kan hantera enskilda sessioner från Bastion-tjänsten i Azure-portalen. Du kan också ta bort eller tvinga en frånkoppling av en pågående fjärrsession om du misstänker att en användare inte ska ansluta till den datorn.

Följande diagram visar referensarkitekturen för att använda Azure Bastion för att skydda virtuella Azure-datorer.

Referensarkitekturen för att använda Azure Bastion för att skydda virtuella Azure-datorer.

För att skydda din virtuella Azure-dator distribuerar du Azure Bastion och börjar använda RDP och SSH för att ansluta till dina virtuella datorer med sina privata IP-adresser.

Nästa steg

Mer information om hur du tillämpar Nolltillit på Azure-nätverk finns i:

Referenser

Se de här länkarna om du vill veta mer om de olika tjänster och tekniker som nämns i den här artikeln.