Nätverksöverväganden för Azure Files

  • Artikel

Du kan komma åt dina Azure-filresurser via den offentliga internettillgängliga slutpunkten, över en eller flera privata slutpunkter i dina nätverk eller genom att cachelagra din Azure-filresurs lokalt med Azure File Sync (endast SMB-filresurser). Den här artikeln fokuserar på hur du konfigurerar Azure Files för direkt åtkomst via offentliga och/eller privata slutpunkter. Information om hur du cachelagrar din Azure-filresurs lokalt med Azure File Sync finns i Introduktion till Azure File Sync.

Vi rekommenderar att du läser Planera för en Azure Files-distribution innan du läser den här guiden.

Direktåtkomst till en Azure-filresurs kräver ofta ytterligare eftertanke när det gäller nätverk:

  • SMB-filresurser kommunicerar via port 445, som många organisationer och Internetleverantörer blockerar för utgående trafik (Internet). Den här metoden kommer från äldre säkerhetsvägledning om inaktuella och icke-internetsäkra versioner av SMB-protokollet. Även om SMB 3.x är ett internetsäkert protokoll kanske organisationens eller Internetleverantörens principer inte kan ändras. Därför kräver montering av en SMB-filresurs ofta ytterligare nätverkskonfiguration för användning utanför Azure.

  • NFS-filresurser förlitar sig på autentisering på nätverksnivå och är därför endast tillgängliga via begränsade nätverk. Att använda en NFS-filresurs kräver alltid en viss nivå av nätverkskonfiguration.

Konfigurationen av offentliga och privata slutpunkter för Azure Files görs på det översta hanteringsobjektet för Azure Files, Azure Storage-kontot. Ett lagringskonto är en hanteringskonstruktion som representerar en delad lagringspool där du kan distribuera flera Azure-filresurser samt lagringsresurser för andra Azure-lagringstjänster, till exempel blobcontainrar eller köer.

Den här videon är en guide och demo för hur du på ett säkert sätt exponerar Azure-filresurser direkt för informationsarbetare och appar i fem enkla steg. Avsnitten nedan innehåller länkar och ytterligare kontext till dokumentationen som refereras i videon. Observera att Azure Active Directory nu är Microsoft Entra-ID. Mer information finns i Nytt namn för Azure AD.

Gäller för

Typ av filresurs SMB NFS
Standardfilresurser (GPv2), LRS/ZRS Ja Inga
Standardfilresurser (GPv2), GRS/GZRS Ja Inga
Premiumfilresurser (FileStorage), LRS/ZRS Ja Ja

Säker överföring

Som standard kräver Azure Storage-konton säker överföring, oavsett om data nås via den offentliga eller privata slutpunkten. För Azure Files tillämpas inställningen kräv säker överföring för all protokollåtkomst till data som lagras på Azure-filresurser, inklusive SMB, NFS och FileREST. Du kan inaktivera inställningen Kräv säker överföring för att tillåta okrypterad trafik. I Azure-portalen kan du också se den här inställningen märkt som kräver säker överföring för REST API-åtgärder.

SMB-, NFS- och FileREST-protokollen har något annorlunda beteende när det gäller inställningen Kräv säker överföring :

  • När kräv säker överföring är aktiverat på ett lagringskonto kräver alla SMB-filresurser i lagringskontot SMB 3.x-protokollet med AES-128-CCM, AES-128-GCM eller AES-256-GCM-krypteringsalgoritmer, beroende på den tillgängliga/nödvändiga krypteringsförhandlingen mellan SMB-klienten och Azure Files. Du kan växla vilka SMB-krypteringsalgoritmer som tillåts via SMB-säkerhetsinställningarna. Om du inaktiverar inställningen Kräv säker överföring aktiveras SMB 2.1- och SMB 3.x-monteringar utan kryptering.

  • NFS-filresurser stöder inte någon krypteringsmekanism, så om du vill använda NFS-protokollet för att få åtkomst till en Azure-filresurs måste du inaktivera säker överföring för lagringskontot.

  • När säker överföring krävs kan FileREST-protokollet endast användas med HTTPS. FileREST stöds bara på SMB-filresurser i dag.

Kommentar

Kommunikationen mellan en klient och ett Azure Storage-konto krypteras med hjälp av TLS (Transport Layer Security). Azure Files förlitar sig på en Windows-implementering av SSL som inte baseras på OpenSSL och därför inte exponeras för OpenSSL-relaterade säkerhetsrisker.

Offentlig slutpunkt

Den offentliga slutpunkten för Azure-filresurserna i ett lagringskonto är en internetexponerad slutpunkt. Den offentliga slutpunkten är standardslutpunkten för ett lagringskonto, men den kan inaktiveras om du vill.

Protokollen SMB, NFS och FileREST kan alla använda den offentliga slutpunkten. Var och en har dock lite olika regler för åtkomst:

  • SMB-filresurser är tillgängliga var som helst i världen via lagringskontots offentliga slutpunkt med SMB 3.x med kryptering. Det innebär att autentiserade begäranden, till exempel begäranden som godkänts av en användares inloggningsidentitet, kan komma från azure-regionen på ett säkert sätt. Om SMB 2.1 eller SMB 3.x utan kryptering önskas måste två villkor uppfyllas:

    1. Lagringskontots inställning för säker överföring måste vara inaktiverad.
    2. Begäran måste komma inifrån Azure-regionen. Som tidigare nämnts tillåts krypterade SMB-begäranden var som helst, inom eller utanför Azure-regionen.

  • NFS-filresurser är tillgängliga från lagringskontots offentliga slutpunkt om och endast om lagringskontots offentliga slutpunkt är begränsad till specifika virtuella nätverk som använder tjänstslutpunkter. Mer information om tjänstslutpunkter finns i Brandväggsinställningar för offentliga slutpunkter.

  • FileREST är tillgängligt via den offentliga slutpunkten. Om säker överföring krävs godkänns endast HTTPS-begäranden. Om säker överföring är inaktiverad godkänns HTTP-begäranden av den offentliga slutpunkten oavsett ursprung.

Brandväggsinställningar för offentlig slutpunkt

Brandväggen för lagringskontot begränsar åtkomsten till den offentliga slutpunkten för ett lagringskonto. Med hjälp av brandväggen för lagringskontot kan du begränsa åtkomsten till vissa IP-adresser/IP-adressintervall, till specifika virtuella nätverk eller inaktivera den offentliga slutpunkten helt.

När du begränsar trafiken för den offentliga slutpunkten till ett eller flera virtuella nätverk använder du en funktion för det virtuella nätverket som kallas tjänstslutpunkter. Begäranden som riktas till tjänstslutpunkten för Azure Files går fortfarande till lagringskontots offentliga IP-adress. Nätverksskiktet utför dock ytterligare verifiering av begäran för att verifiera att den kommer från ett auktoriserat virtuellt nätverk. Protokollen SMB, NFS och FileREST stöder alla tjänstslutpunkter. Till skillnad från SMB och FileREST kan dock NFS-filresurser endast nås med den offentliga slutpunkten med hjälp av en tjänstslutpunkt.

Mer information om hur du konfigurerar brandväggen för lagringskontot finns i konfigurera Azure Storage-brandväggar och virtuella nätverk.

Routning av offentligt slutpunktsnätverk

Azure Files stöder flera alternativ för nätverksroutning. Standardalternativet Microsoft-routning fungerar med alla Azure Files-konfigurationer. Internetroutningsalternativet stöder inte scenarier för AD-domänanslutning eller Azure File Sync.

Privata slutpunkter

Utöver den offentliga standardslutpunkten för ett lagringskonto ger Azure Files alternativet att ha en eller flera privata slutpunkter. En privat slutpunkt är en slutpunkt som endast är tillgänglig i ett virtuellt Azure-nätverk. När du skapar en privat slutpunkt för ditt lagringskonto får ditt lagringskonto en privat IP-adress inifrån adressutrymmet för det virtuella nätverket, ungefär som hur en lokal filserver eller NAS-enhet tar emot en IP-adress inom det dedikerade adressutrymmet i ditt lokala nätverk.

En enskild privat slutpunkt är associerad med ett specifikt undernät för ett virtuellt Azure-nätverk. Ett lagringskonto kan ha privata slutpunkter i mer än ett virtuellt nätverk.

Med privata slutpunkter med Azure Files kan du:

  • Anslut säkert till dina Azure-filresurser från lokala nätverk med hjälp av en VPN- eller ExpressRoute-anslutning med privat peering.
  • Skydda dina Azure-filresurser genom att konfigurera brandväggen för lagringskontot för att blockera alla anslutningar på den offentliga slutpunkten. Som standard blockerar inte skapandet av en privat slutpunkt anslutningar till den offentliga slutpunkten.
  • Öka säkerheten för det virtuella nätverket genom att aktivera att du kan blockera exfiltrering av data från det virtuella nätverket (och peeringgränser).

Information om hur du skapar en privat slutpunkt finns i Konfigurera privata slutpunkter för Azure Files.

Tunneltrafik över ett virtuellt privat nätverk eller ExpressRoute

Om du vill använda privata slutpunkter för att komma åt SMB- eller NFS-filresurser från en lokal plats måste du upprätta en nätverkstunnel mellan ditt lokala nätverk och Azure. Ett virtuellt nätverk, eller ett virtuellt nätverk, liknar ett traditionellt lokalt nätverk. Precis som ett Azure Storage-konto eller en virtuell Azure-dator är ett virtuellt nätverk en Azure-resurs som distribueras i en resursgrupp.

Azure Files har stöd för följande mekanismer för att tunneltrafik mellan dina lokala arbetsstationer och servrar och Azure SMB/NFS-filresurser:

  • Azure VPN Gateway: En VPN-gateway är en specifik typ av virtuell nätverksgateway som används för att skicka krypterad trafik mellan ett virtuellt Azure-nätverk och en alternativ plats (till exempel lokalt) via Internet. En Azure VPN Gateway är en Azure-resurs som kan distribueras i en resursgrupp tillsammans med ett lagringskonto eller andra Azure-resurser. VPN-gatewayer exponerar två olika typer av anslutningar:
  • ExpressRoute, som gör att du kan skapa en definierad väg mellan Azure och ditt lokala nätverk som inte passerar Internet. Eftersom ExpressRoute tillhandahåller en dedikerad sökväg mellan ditt lokala datacenter och Azure kan ExpressRoute vara användbart när nätverksprestanda är ett övervägande. ExpressRoute är också ett bra alternativ när organisationens policy- eller regelkrav kräver en deterministisk väg till dina resurser i molnet.

Kommentar

Även om vi rekommenderar att du använder privata slutpunkter för att utöka ditt lokala nätverk till Azure, är det tekniskt möjligt att dirigera till den offentliga slutpunkten via VPN-anslutningen. Detta kräver dock hårdkodning av IP-adressen för den offentliga slutpunkten för Azure Storage-klustret som hanterar ditt lagringskonto. Eftersom lagringskonton kan flyttas mellan lagringskluster när som helst och nya kluster läggs till och tas bort ofta, kräver detta att du regelbundet hårdkodar alla möjliga Ip-adresser för Azure Storage i dina routningsregler.

DNS-konfiguration

När du skapar en privat slutpunkt skapar vi som standard också en (eller uppdaterar en befintlig) privat DNS-zon som motsvarar underdomänen privatelink . Strikt sett krävs det inte att du skapar en privat DNS-zon för att använda en privat slutpunkt för ditt lagringskonto. Det rekommenderas dock starkt i allmänhet, och det krävs uttryckligen när du monterar din Azure-filresurs med ett Active Directory-användarhuvudnamn eller kommer åt den från FileREST-API:et.

Kommentar

Den här artikeln använder DNS-suffixet för lagringskontot för de offentliga Azure-regionerna, core.windows.net. Den här kommentaren gäller även för Azure Sovereign-moln som Azure US Government-molnet och Microsoft Azure som drivs av 21Vianet-molnet – ersätt bara lämpliga suffix för din miljö.

I din privata DNS-zon skapar vi en A-post för storageaccount.privatelink.file.core.windows.net och en CNAME-post för lagringskontots vanliga namn, som följer mönstret storageaccount.file.core.windows.net. Eftersom din privata Dns-zon i Azure är ansluten till det virtuella nätverket som innehåller den privata slutpunkten kan du observera DNS-konfigurationen genom att anropa cmdleten Resolve-DnsName från PowerShell på en virtuell Azure-dator (alternativt nslookup i Windows och Linux):

Resolve-DnsName -Name "storageaccount.file.core.windows.net"

I det här exemplet matchar lagringskontot storageaccount.file.core.windows.net den privata IP-adressen för den privata slutpunkten, som råkar vara 192.168.0.4.

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  29    Answer     csostoracct.privatelink.file.core.windows.net
net

Name       : storageaccount.privatelink.file.core.windows.net
QueryType  : A
TTL        : 1769
Section    : Answer
IP4Address : 192.168.0.4


Name                   : privatelink.file.core.windows.net
QueryType              : SOA
TTL                    : 269
Section                : Authority
NameAdministrator      : azureprivatedns-host.microsoft.com
SerialNumber           : 1
TimeToZoneRefresh      : 3600
TimeToZoneFailureRetry : 300
TimeToExpiration       : 2419200
DefaultTTL             : 300

Om du kör samma kommando lokalt ser du att samma lagringskontonamn matchar lagringskontots offentliga IP-adress i stället. Är till exempel storageaccount.file.core.windows.net en CNAME-post för storageaccount.privatelink.file.core.windows.net, som i sin tur är en CNAME-post för Azure Storage-klustret som är värd för lagringskontot:

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  60    Answer     storageaccount.privatelink.file.core.windows.net
net
storageaccount.privatelink.file.c CNAME  60    Answer     file.par20prdstr01a.store.core.windows.net
ore.windows.net

Name       : file.par20prdstr01a.store.core.windows.net
QueryType  : A
TTL        : 60
Section    : Answer
IP4Address : 52.239.194.40

Detta återspeglar det faktum att lagringskontot kan exponera både den offentliga slutpunkten och en eller flera privata slutpunkter. För att säkerställa att lagringskontonamnet matchar den privata slutpunktens privata IP-adress måste du ändra konfigurationen på dina lokala DNS-servrar. Detta kan göras på flera sätt:

  • Ändra värdfilen på dina klienter för att matcha storageaccount.file.core.windows.net den önskade privata slutpunktens privata IP-adress. Detta rekommenderas inte för produktionsmiljöer eftersom du måste göra dessa ändringar i varje klient som vill montera dina Azure-filresurser, och ändringar i lagringskontot eller den privata slutpunkten hanteras inte automatiskt.
  • Skapa en A-post för storageaccount.file.core.windows.net på dina lokala DNS-servrar. Detta har fördelen att klienter i din lokala miljö automatiskt kan lösa lagringskontot utan att behöva konfigurera varje klient. Den här lösningen är dock lika spröd som att ändra värdfilen eftersom ändringarna inte återspeglas. Även om den här lösningen är skör kan det vara det bästa valet för vissa miljöer.
  • core.windows.net Vidarebefordra zonen från dina lokala DNS-servrar till din privata DNS-zon i Azure. Den privata DNS-värden i Azure kan nås via en särskild IP-adress (168.63.129.16) som endast är tillgänglig i virtuella nätverk som är länkade till den privata DNS-zonen i Azure. Om du vill kringgå den här begränsningen kan du köra ytterligare DNS-servrar i ditt virtuella nätverk som vidarebefordras core.windows.net till den privata DNS-zonen i Azure. För att förenkla den här konfigurationen har vi tillhandahållit PowerShell-cmdletar som automatiskt distribuerar DNS-servrar i ditt virtuella Azure-nätverk och konfigurerar dem efter behov. Information om hur du konfigurerar DNS-vidarebefordran finns i Konfigurera DNS med Azure Files.

SMB över QUIC

Windows Server 2022 Azure Edition stöder ett nytt transportprotokoll med namnet QUIC för SMB-servern som tillhandahålls av filserverrollen. QUIC är en ersättning för TCP som bygger på UDP, vilket ger många fördelar jämfört med TCP samtidigt som det ger en tillförlitlig transportmekanism. En viktig fördel för SMB-protokollet är att i stället för att använda port 445 sker all transport via port 443, som är allmänt öppen utgående för att stödja HTTPS. Det innebär i praktiken att SMB via QUIC erbjuder ett "SMB VPN" för fildelning via det offentliga Internet. Windows 11 levereras med en SMB över QUIC-kompatibel klient.

För närvarande har Azure Files inte direkt stöd för SMB via QUIC. Du kan dock få åtkomst till Azure-filresurser via Azure File Sync som körs på Windows Server som i diagrammet nedan. Detta ger dig också möjlighet att ha Azure File Sync-cacheminnen både lokalt eller i olika Azure-datacenter för att tillhandahålla lokala cacheminnen för en distribuerad personal. Mer information om det här alternativet finns i Distribuera Azure File Sync och SMB via QUIC.

Diagram för att skapa en enkel cache av dina Azure-filresurser på en Windows Server 2022 Azure Edition V M med Azure File Sync.

Se även