Aandachtspunten voor Azure Files-netwerken

U hebt toegang tot uw Azure-bestandsshares via het openbare internet, via een of meer privé-eindpunten in uw netwerk(en) of door uw Azure-bestandsshare on-premises in de cache op te slaan met alleen SMB-bestandsshares (Azure File Sync). In dit artikel wordt uitgelegd hoe u Azure Files configureert voor directe toegang via openbare en/of privé-eindpunten. Zie Inleiding tot Azure File Sync voor informatie over het opslaan van uw on-premises Azure-bestandsshare in de cache met Azure File Sync.

Het is raadzaam planning voor een Azure Files-implementatie te lezen voordat u deze handleiding leest.

Het rechtstreeks openen van een Azure-bestandsshare vereist vaak aanvullende gedachten met betrekking tot netwerken:

• SMB-bestandsshares communiceren via poort 445, die veel organisaties en internetproviders (ISP's) blokkeren voor uitgaand verkeer (internet). Deze procedure is afkomstig van verouderde beveiligingsrichtlijnen over afgeschafte en niet-internetveilige versies van het SMB-protocol. Hoewel SMB 3.x een internetveilig protocol is, is het mogelijk dat organisatie- of internetproviderbeleid niet kan worden gewijzigd. Daarom vereist het koppelen van een SMB-bestandsshare vaak aanvullende netwerkconfiguratie die buiten Azure moet worden gebruikt.

• NFS-bestandsshares zijn afhankelijk van verificatie op netwerkniveau en zijn daarom alleen toegankelijk via beperkte netwerken. Voor het gebruik van een NFS-bestandsshare is altijd een netwerkconfiguratie vereist.

Het configureren van openbare en privé-eindpunten voor Azure Files vindt plaats op het beheerobject op het hoogste niveau voor Azure Files, het Azure-opslagaccount. Een opslagaccount is een beheerconstructie die een gedeelde opslaggroep vertegenwoordigt waarin u meerdere Azure-bestandsshares kunt implementeren, evenals de opslagbronnen voor andere Azure-opslagservices, zoals blobcontainers of wachtrijen.

Deze video is een handleiding en demo voor het veilig beschikbaar maken van Azure-bestandsshares rechtstreeks aan informatiewerkers en apps in vijf eenvoudige stappen. De onderstaande secties bevatten koppelingen en aanvullende context naar de documentatie waarnaar in de video wordt verwezen. Houd er rekening mee dat Azure Active Directory nu Microsoft Entra ID is. Zie Nieuwe naam voor Azure AD voor meer informatie.

Van toepassing op

Bestands sharetype	SMB	NFS
Standaardbestandsshares (GPv2), LRS/ZRS
Standaardbestandsshares (GPv2), GRS/GZRS
Premium bestandsshares (FileStorage), LRS/ZRS

Veilige overdracht

Azure-opslagaccounts vereisen standaard beveiligde overdracht, ongeacht of gegevens worden geopend via het openbare of privé-eindpunt. Voor Azure Files wordt de instelling voor veilige overdracht afgedwongen voor alle protocoltoegang tot de gegevens die zijn opgeslagen op Azure-bestandsshares, waaronder SMB, NFS en FileREST. U kunt de instelling veilige overdracht vereisen uitschakelen om niet-versleuteld verkeer toe te staan. In De Azure-portal ziet u mogelijk ook deze instelling die is gelabeld als veilige overdracht vereist voor REST API-bewerkingen.

De SMB-, NFS- en FileREST-protocollen hebben iets ander gedrag met betrekking tot de instelling voor veilige overdracht :

• Wanneer beveiligde overdracht is ingeschakeld voor een opslagaccount, is voor alle SMB-bestandsshares in dat opslagaccount het SMB 3.x-protocol met AES-128-CCM, AES-128-GCM of AES-256-GCM-versleutelingsalgoritmen vereist, afhankelijk van de beschikbare/vereiste versleutelingsonderhandelingen tussen de SMB-client en Azure Files. U kunt in-/uitschakelen welke SMB-versleutelingsalgoritmen zijn toegestaan via de SMB-beveiligingsinstellingen. Als u de instelling veilige overdracht wilt uitschakelen, worden SMB 2.1 en SMB 3.x-koppelingen zonder versleuteling ingeschakeld.

• NFS-bestandsshares bieden geen ondersteuning voor een versleutelingsmechanisme. Als u het NFS-protocol wilt gebruiken voor toegang tot een Azure-bestandsshare, moet u veilige overdracht voor het opslagaccount uitschakelen.

• Wanneer beveiligde overdracht is vereist, mag het FileREST-protocol alleen worden gebruikt met HTTPS. FileREST wordt momenteel alleen ondersteund op SMB-bestandsshares.

Notitie

Communicatie tussen een client en een Azure-opslagaccount wordt versleuteld met TLS (Transport Layer Security). Azure Files is afhankelijk van een Windows-implementatie van SSL die niet is gebaseerd op OpenSSL en wordt daarom niet blootgesteld aan aan OpenSSL-gerelateerde beveiligingsproblemen.

Openbaar eindpunt

Het openbare eindpunt voor de Azure-bestandsshares in een opslagaccount is een eindpunt dat via internet beschikbaar is. Het openbare eindpunt is het standaardeindpunt voor een opslagaccount, maar het kan desgewenst worden uitgeschakeld.

De protocollen SMB, NFS en FileREST kunnen allemaal gebruikmaken van het openbare eindpunt. Elk heeft echter iets andere regels voor toegang:

• SMB-bestandsshares zijn overal ter wereld toegankelijk via het openbare eindpunt van het opslagaccount met SMB 3.x met versleuteling. Dit betekent dat geverifieerde aanvragen, zoals aanvragen die zijn geautoriseerd door de aanmeldingsidentiteit van een gebruiker, veilig kunnen ontstaan vanuit of buiten de Azure-regio. Als SMB 2.1 of SMB 3.x zonder versleuteling gewenst is, moet aan twee voorwaarden worden voldaan:

  1. De instelling voor veilige overdracht van het opslagaccount moet worden uitgeschakeld.
  2. De aanvraag moet afkomstig zijn van binnen de Azure-regio. Zoals eerder vermeld, zijn versleutelde SMB-aanvragen vanaf elke locatie, binnen of buiten de Azure-regio toegestaan.

• NFS-bestandsshares zijn toegankelijk vanaf het openbare eindpunt van het opslagaccount als en alleen als het openbare eindpunt van het opslagaccount is beperkt tot specifieke virtuele netwerken met behulp van service-eindpunten. Zie de firewallinstellingen voor openbare eindpunten voor aanvullende informatie over service-eindpunten.

• FileREST is toegankelijk via het openbare eindpunt. Als beveiligde overdracht is vereist, worden alleen HTTPS-aanvragen geaccepteerd. Als beveiligde overdracht is uitgeschakeld, worden HTTP-aanvragen geaccepteerd door het openbare eindpunt, ongeacht de oorsprong.

Firewallinstellingen voor openbare eindpunten

De firewall van het opslagaccount beperkt de toegang tot het openbare eindpunt voor een opslagaccount. Met behulp van de firewall van het opslagaccount kunt u de toegang tot bepaalde IP-adressen/IP-adresbereiken beperken tot specifieke virtuele netwerken of het openbare eindpunt volledig uitschakelen.

Wanneer u het verkeer van het openbare eindpunt beperkt tot een of meer virtuele netwerken, gebruikt u een mogelijkheid van het virtuele netwerk dat service-eindpunten wordt genoemd. Aanvragen die zijn gericht op het service-eindpunt van Azure Files, gaan nog steeds naar het openbare IP-adres van het opslagaccount; De netwerklaag voert echter aanvullende verificatie uit van de aanvraag om te controleren of deze afkomstig is van een geautoriseerd virtueel netwerk. De SMB-, NFS- en FileREST-protocollen ondersteunen allemaal service-eindpunten. In tegenstelling tot SMB en FileREST kunnen NFS-bestandsshares echter alleen worden geopend met het openbare eindpunt via het gebruik van een service-eindpunt.

Zie Firewalls en virtuele netwerken voor Azure Storage configureren voor meer informatie over het configureren van de firewall voor het opslagaccount.

Netwerkroutering van openbaar eindpunt

Azure Files ondersteunt meerdere netwerkrouteringsopties. De standaardoptie, Microsoft-routering, werkt met alle Azure Files-configuraties. De optie voor internetroutering biedt geen ondersteuning voor ad-domeindeelnamescenario's of Azure File Sync.

Privé-eindpunten

Naast het standaard openbare eindpunt voor een opslagaccount, biedt Azure Files de mogelijkheid om een of meer privé-eindpunten te configureren. Een privé-eindpunt is een eindpunt dat alleen toegankelijk is binnen een virtueel Azure-netwerk. Wanneer u een privé-eindpunt voor uw opslagaccount maakt, ontvangt uw opslagaccount een privé-IP-adres in de adresruimte van uw virtuele netwerk, zoals een on-premises bestandsserver of NAS-apparaat een IP-adres ontvangt binnen de toegewezen adresruimte van uw on-premises netwerk.

Een privé-eindpunt is gekoppeld aan een specifiek subnet van het virtuele Azure-netwerk. Een opslagaccount kan privé-eindpunten hebben in meer dan één virtueel netwerk.

Door gebruik te maken van privé-eindpunten met Azure Files kunt u het volgende doen:

• Veilig verbinding maken met uw Azure-bestandsshares vanuit on-premises netwerken met behulp van een VPN- of ExpressRoute-verbinding met privé-peering.
• Uw Azure-bestandsshares beveiligen door de firewall van het opslagaccount zodanig te configureren dat alle verbindingen op het openbare eindpunt worden geblokkeerd. Het maken van een privé-eindpunt blokkeert standaard geen verbindingen met het openbare eindpunt.
• De beveiliging voor het virtuele netwerk verbeteren door gegevensoverdracht van het virtuele netwerk (en de grenzen van peering) te blokkeren.

Zie Privé-eindpunten configureren voor Azure Files voor het maken van een privé-eindpunt.

Verkeer tunnelen via een virtueel particulier netwerk of ExpressRoute

Als u privé-eindpunten wilt gebruiken voor toegang tot SMB- of NFS-bestandsshares vanaf on-premises, moet u een netwerktunnel tot stand brengen tussen uw on-premises netwerk en Azure. Een virtueel netwerk of VNet is vergelijkbaar met een traditioneel on-premises netwerk. Net zoals een Azure-opslagaccount of een Azure-VM, is een VNet een Azure-resource die in een resourcegroep is geïmplementeerd.

Azure Files ondersteunt de volgende mechanismen om verkeer te tunnelen tussen uw on-premises werkstations en servers en Azure SMB/NFS-bestandsshares:

• Azure VPN Gateway: een VPN-gateway is een specifiek type virtuele netwerkgateway dat wordt gebruikt om versleuteld verkeer tussen een virtueel Azure-netwerk en een alternatieve locatie (zoals on-premises) via internet te verzenden. Een Azure VPN Gateway is een Azure-resource die kan worden geïmplementeerd in een resourcegroep naast een opslagaccount of andere Azure-resources. VPN-gateways maken twee verschillende soorten verbindingen beschikbaar:
  • Punt-naar-site-VPN-gatewayverbindingen. Dit zijn VPN-verbindingen tussen Azure en een afzonderlijke client. Deze oplossing is voornamelijk handig voor apparaten die geen deel uitmaken van het on-premises netwerk van uw organisatie. Een veelvoorkomende use-case is voor telecommuters die hun Azure-bestandsshare thuis, een café of hotel willen kunnen koppelen terwijl ze onderweg zijn. Als u een P2S VPN-verbinding met Azure Files wilt gebruiken, moet u een P2S VPN-verbinding configureren voor elke client die verbinding wil maken. Zie Een punt-naar-site-VPN (P2S) configureren in Windows voor gebruik met Azure Files en een punt-naar-site-VPN (P2S) configureren op Linux voor gebruik met Azure Files.
  • Site-naar-site-VPN. Dit zijn VPN-verbindingen tussen Azure en het netwerk van uw organisatie. Met een S2S VPN-verbinding kunt u één keer een VPN-verbinding configureren voor een VPN-server of apparaat dat wordt gehost in het netwerk van uw organisatie, in plaats van een verbinding te configureren voor elk clientapparaat dat toegang nodig heeft tot uw Azure-bestandsshare. Zie Een site-naar-site-VPN (S2S) configureren voor gebruik met Azure Files.
• ExpressRoute. Hiermee kunt u een gedefinieerde route tussen Azure en uw on-premises netwerk maken die niet via internet loopt. Omdat ExpressRoute een speciaal pad biedt tussen uw on-premises datacenter en Azure, kan ExpressRoute handig zijn wanneer de netwerkprestaties een overweging zijn. ExpressRoute is ook een goede optie wanneer een deterministisch pad naar uw resources in de cloud vereist is vanwege het beleid of de wettelijke vereisten van uw organisatie.

Notitie

Hoewel het raadzaam is om privé-eindpunten te gebruiken om uw on-premises netwerk uit te breiden naar Azure, is het technisch mogelijk om via de VPN-verbinding naar het openbare eindpunt te routeren. Hiervoor moet het IP-adres echter hard worden gecodeerd voor het openbare eindpunt voor het Azure-opslagcluster dat uw opslagaccount dient. Omdat opslagaccounts op elk gewenst moment tussen opslagclusters kunnen worden verplaatst en nieuwe clusters regelmatig worden toegevoegd en verwijderd, moet u hiervoor regelmatig alle mogelijke IP-adressen van Azure Storage in uw routeringsregels coderen.

DNS-configuratie

Wanneer u een privé-eindpunt maakt, wordt standaard ook een privé-DNS-zone gemaakt (of een bestaande privé-DNS-zone bijgewerkt) die overeenkomt met het privatelink-subdomein. Het maken van een privé-DNS-zone is strikt genomen niet vereist voor het gebruik van een privé-eindpunt voor uw opslagaccount. Het wordt echter in het algemeen ten zeerste aanbevolen en is expliciet vereist bij het koppelen van uw Azure-bestandsshare met een Active Directory-gebruikersprincipaal of het openen ervan vanuit de FileREST-API.

Notitie

In dit artikel wordt het DNS-achtervoegsel voor opslagaccounts gebruikt voor de openbare regio's van Azure, te weten core.windows.net. Dit commentaar is ook van toepassing op Onafhankelijke Azure-clouds, zoals de Azure US Government-cloud en de Microsoft Azure-cloud die wordt beheerd door 21Vianet-cloud. Vervang gewoon de juiste achtervoegsels voor uw omgeving.

In uw privé-DNS-zone maken we een A-record voor storageaccount.privatelink.file.core.windows.net en een CNAME-record voor de reguliere naam van het opslagaccount, met het patroon storageaccount.file.core.windows.net. Omdat uw privé-DNS-zone van Azure is verbonden met het virtuele netwerk met het privé-eindpunt, kunt u de DNS-configuratie observeren door de Resolve-DnsName cmdlet aan te roepen vanuit PowerShell in een Azure-VM (ook nslookup in Windows en Linux):

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

In dit voorbeeld wordt het opslagaccount storageaccount.file.core.windows.net omgezet in het privé-IP-adres van het privé-eindpunt. Dit gebeurt 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

Als u dezelfde opdracht uitvoert vanaf on-premises, ziet u dat dezelfde naam van het opslagaccount wordt omgezet in het openbare IP-adres van het opslagaccount. Is bijvoorbeeld storageaccount.file.core.windows.net een CNAME-record waarvoor storageaccount.privatelink.file.core.windows.netop zijn beurt een CNAME-record is voor het Azure-opslagcluster dat als host fungeert voor het opslagaccount:

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

Dit weerspiegelt het feit dat het opslagaccount zowel het openbare eindpunt als een of meer privé-eindpunten beschikbaar kan stellen. Om ervoor te zorgen dat de naam van het opslagaccount wordt omgezet in het privé-IP-adres van het privé-eindpunt, moet u de configuratie op uw on-premises DNS-servers wijzigen. Dit kan op verschillende manieren worden gerealiseerd:

• Het hosts-bestand op uw clients wijzigen om storageaccount.file.core.windows.net het gewenste privé-IP-adres van het privé-eindpunt op te lossen. Dit wordt sterk afgeraden voor productieomgevingen, omdat u deze wijzigingen moet aanbrengen aan elke client die uw Azure-bestandsshares wil koppelen en wijzigingen in het opslagaccount of privé-eindpunt niet automatisch worden verwerkt.
• Een A-record maken voor storageaccount.file.core.windows.net in uw on-premises DNS-servers. Dit heeft het voordeel dat clients in uw on-premises omgeving het opslagaccount automatisch kunnen oplossen zonder dat elke client hoeft te worden geconfigureerd. Deze oplossing is echter vergelijkbaar met het wijzigen van het hosts-bestand , omdat wijzigingen niet worden weerspiegeld. Hoewel deze oplossing broos is, kan het de beste keuze zijn voor sommige omgevingen.
• De zone core.windows.net doorsturen van uw on-premises DNS-servers naar uw privé-DNS-zone van Azure. De privé-DNS-host van Azure kan worden bereikt via een speciaal IP-adres (168.63.129.16) dat alleen toegankelijk is in virtuele netwerken die zijn gekoppeld aan de privé-DNS-zone van Azure. U kunt deze beperking omzeilen door extra DNS-servers in uw virtuele netwerk uit te voeren die worden doorgestuurd core.windows.net naar de privé-DNS-zone van Azure. Om deze configuratie te vereenvoudigen, hebben we PowerShell-cmdlets opgegeven waarmee DNS-servers automatisch worden geïmplementeerd in uw virtuele Azure-netwerk en deze naar wens configureren. Zie DNS configureren met Azure Files voor meer informatie over het instellen van DNS-doorschakeling.

SMB via QUIC

Windows Server 2022 Azure Edition ondersteunt een nieuw transportprotocol met de naam QUIC voor de SMB-server die wordt geleverd door de bestandsserverfunctie. QUIC is een vervanging voor TCP die is gebouwd op basis van UDP, wat talloze voordelen biedt via TCP en tegelijkertijd een betrouwbaar transportmechanisme biedt. Een belangrijk voordeel voor het SMB-protocol is dat in plaats van poort 445 al het transport wordt uitgevoerd via poort 443, dat algemeen uitgaand is voor ondersteuning van HTTPS. Dit betekent dat SMB via QUIC een 'SMB VPN' biedt voor het delen van bestanden via het openbare internet. Windows 11 wordt geleverd met een SMB via QUIC-compatibele client.

Op dit moment biedt Azure Files geen rechtstreekse ondersteuning voor SMB via QUIC. U kunt echter toegang krijgen tot Azure-bestandsshares via Azure File Sync die wordt uitgevoerd op Windows Server, zoals in het onderstaande diagram. Dit biedt u ook de mogelijkheid om Azure File Sync-caches on-premises of in verschillende Azure-datacenters te laten gebruiken om lokale caches te bieden voor gedistribueerd personeel. Zie Azure File Sync en SMB implementeren via QUIC voor meer informatie over deze optie.

Zie ook

• Overzicht van Azure Files
• Een Azure Files-implementatie plannen