overwegingen voor Azure Files netwerken

✔️ Van toepassing op: Alle Azure file shares

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

Lees Planning for a Azure Files deployment voordat je deze gids leest.

Voor het rechtstreeks openen van een Azure bestandsshare is vaak extra gedachte nodig 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 benaderen van een SMB-bestandsshare vaak extra netwerkconfiguratie voor gebruik buiten Azure.

• 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.

Je configureert publieke en private eindpunten voor Azure Files op het top-level beheerobject 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.

Veilige overdracht

Voor Azure opslagaccounts is standaard beveiligde overdracht vereist, ongeacht of gegevens worden geopend via het openbare of privé-eindpunt. Voor Azure Files wordt versleuteling tijdens overdracht beheerd op protocolniveau:

Versleuteling in transit voor MKB's

De instelling 'Require Encryption in Transit for SMB' bepaalt of versleuteling vereist is voor SMB-toegang. Voor nieuwe opslagaccounts die zijn gemaakt met behulp van de Azure-portal, is deze instelling standaard ingeschakeld. Opslagaccounts die zijn gemaakt met behulp van Azure PowerShell, Azure CLI of de FileREST-API, stellen deze waarde in op Not selected om compatibiliteit met eerdere versies te garanderen. Voor bestaande opslagaccounts blijft de Secure transfer vereist instelling SMB-versleuteling te beheren totdat u de SMB-instelling per protocol expliciet configureert. Wanneer SMB-versleuteling tijdens overdracht is vereist, vereisen alle SMB-bestandsshares in dat opslagaccount het SMB 3.x-protocol met AES-128-CCM, AES-128-GCM of AES-256-GCM-versleutelingsalgoritmen. U kunt in-/uitschakelen welke algoritmen zijn toegestaan via de SMB-beveiligingsinstellingen. Als u deze instelling uitschakelt, worden SMB 2.1 en SMB 3.x-koppelingen zonder versleuteling ingeschakeld.

Versleuteling tijdens overdracht voor NFS

De instelling 'Require Encryption in Transit for NFS ' bepaalt of versleuteling vereist is voor NFS-toegang. NFS Azure bestandsshares maken gebruik van het AZNFS-hulpprogrammapakket om versleutelde koppelingen te vereenvoudigen door Stunnel (een opensource TLS-wrapper) op de client te installeren en in te stellen. Zie Encryptie tijdens overdracht van NFS Azure-bestanden. Voor nieuwe opslagaccounts die zijn gemaakt met behulp van de Azure-portal, is deze instelling standaard ingeschakeld. Opslagaccounts die zijn gemaakt met behulp van Azure PowerShell, Azure CLI of de FileREST-API, stellen deze waarde in op Not selected om compatibiliteit met eerdere versies te garanderen. Voor bestaande opslagaccounts blijft de vereiste instelling voor veilige overdracht het gedrag van NFS-versleuteling beheren totdat u de NFS-instelling per protocol expliciet configureert.

Versleuteling tijdens het verzenden voor FileREST

De instelling Secure transfer required geldt voor REST/HTTPS-verkeer. Wanneer dit is ingeschakeld, mag het FileREST-protocol alleen worden gebruikt met HTTPS.

Openbaar eindpunt

Het openbare eindpunt voor de Azure bestandsshares binnen 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 Versleuteling in transit vereisen voor SMB moet zijn uitgeschakeld (of voor bestaande accounts waarvoor deze instelling niet expliciet is geconfigureerd, moet de instelling Veilige overdracht zijn 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, alleen als het openbare eindpunt van het opslagaccount beperkt is 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. Je kunt de toegang beperken tot bepaalde IP-adressen of IP-adresbereiken, tot specifieke virtuele netwerken, of het publieke eindpunt volledig uitschakelen.

Wanneer je het publieke eindpunt beperkt tot één of meer netwerken, gebruik je een mogelijkheid van het virtuele netwerk genaamd service-eindpunten. Verzoeken gericht op het service-endpoint van Azure Files gaan nog steeds naar het publieke IP-adres van het opslagaccount. De netwerklaag voert echter extra verificatie uit van het verzoek om te valideren dat het 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-bestandsdelingen echter alleen worden benaderd door het publieke eindpunt te gebruiken via een service-endpoint.

Toegang tot Azure Portal en de firewall van het opslagaccount

Wanneer u toegang hebt tot Azure-bestandsshares via De Azure-portal, treden er twee afzonderlijke aanvragen op:

1. Een aanvraag van uw browser naar de gebruikersinterface van Azure Portal (https://portal.azure.com).
2. Een aanvraag van uw browser rechtstreeks naar het eindpunt van de Azure Files-gegevenslaag (bijvoorbeeld https://<storage-account-name>.file.core.windows.net), meestal met behulp van een SAS-token dat is uitgegeven voor gebruik in het portaal.

De firewall van het opslagaccount evalueert alleen de directe aanvraag naar het Azure Files-gegevensvlakeindpunt, niet de aanvraag naar portal.azure.com. Zelfs als u zonder problemen toegang hebt tot De Azure-portal, krijgt u mogelijk een fout 403 (Verboden) bij het browsen van gegevens over bestandsshares als het openbare IP-adres voor uitgaand verkeer op de browser-naar-opslagaanvraag niet is toegestaan door de firewall. Deze beperking geldt alleen voor FileREST/HTTPS-verkeer, niet voor SMB of NFS. Voor meer informatie, zie Toegang autoriseren tot bestandsgegevens in het Azure-portaal.

Netwerkroutering van openbaar eindpunt

Azure Files ondersteunt twee netwerkrouteringsopties:

• Microsoft-routering (standaard): Verkeer tussen de client en het opslagaccount reist zo lang mogelijk via de wereldwijde netwerkbackbone van Microsoft voordat het naar het internet gaat. Deze optie werkt met alle Azure Files-configuraties, inclusief Active Directory (AD) domeinjoin-scenario's en Azure File Sync.
• Internetroutering: Verkeer wordt zo vroeg mogelijk via het openbare internet geleid. Deze optie biedt geen ondersteuning voor scenario's voor domeindeelname aan Active Directory (AD) of voor 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 hebben. Een privé-eindpunt is een eindpunt dat alleen toegankelijk is binnen een Azure virtueel netwerk. Wanneer u een privé-eindpunt voor uw opslagaccount maakt, krijgt uw opslagaccount een privé-IP-adres in de adresruimte van uw virtuele netwerk, net zoals hoe een on-premises bestandsserver of NAS-apparaat een IP-adres ontvangt binnen de toegewezen adresruimte van uw on-premises netwerk.

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

Met behulp van privé-eindpunten met Azure Files kunt u het volgende doen:

• Maak veilig verbinding met uw Azure bestandsshares vanuit on-premises netwerken met behulp van een VPN- of ExpressRoute-verbinding met privé-peering.
• Beveilig uw Azure bestandsshares door de firewall van het opslagaccount te configureren om alle verbindingen op het openbare eindpunt te blokkeren. 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 om een privé-eindpunt te maken.

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 lijkt op een traditioneel on-premises netwerk. Net als een Azure-opslagaccount of een Azure VM is een virtueel netwerk een Azure-resource die je in een resourcegroep uitrolt.

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

Punt naar site VPN

Azure VPN-gateway ondersteunt point-to-site VPN-verbindingen, dat zijn VPN-verbindingen tussen Azure en een individuele client. Deze oplossing is voornamelijk handig voor apparaten die geen deel uitmaken van het on-premises netwerk van uw organisatie. Een veelvoorkomend toepassingsvoorbeeld is voor thuiswerkers die hun Azure-bestandsshares thuis, in een café of hotel willen koppelen terwijl ze onderweg zijn. Om een point-to-site VPN-verbinding met Azure Files te gebruiken, moet je voor elke client die wil verbinden een Point-to-Site VPN-verbinding configureren. Zie Configureer een Point-to-Site VPN op Windows voor gebruik met Azure Files en Configureer een Point-to-Site VPN op Linux voor gebruik met Azure Files.

Site - naar - site VPN

Azure VPN-gateway ondersteunt ook site-to-site VPN-verbindingen, dat zijn VPN-verbindingen tussen Azure en het netwerk van uw organisatie. Een site-to-site VPN-verbinding stelt je in staat om één keer een VPN-verbinding te configureren voor een VPN-server of apparaat dat op het netwerk van je organisatie wordt gehost, in plaats van een verbinding te configureren voor elk clientapparaat dat toegang nodig heeft tot je Azure-bestandsdeling. Zie Configureer een Site-to-Site VPN voor gebruik met Azure Files.

ExpressRoute

ExpressRoute stelt je in staat om een gedefinieerde route te maken tussen Azure en je on-premises netwerk die niet over het internet loopt. Omdat ExpressRoute een toegewezen 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.

DNS-configuratie

Wanneer je een privé-endpoint aanmaakt, creëert of werkt Azure ook een private DNS-zone aan 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 sterk aanbevolen en is expliciet vereist bij het mounten van je Azure-bestandsdeling met een Active Directory-gebruikersprincipe of bij het openen ervan via de FileREST API.

In je private DNS-zone maakt Azure een A-record aan voor storageaccount.privatelink.file.core.windows.net en een CNAME-record voor de reguliere naam van het opslagaccount, wat het patroon storageaccount.file.core.windows.netvolgt. Omdat uw Azure privé-DNS-zone is verbonden met het virtuele netwerk met het privé-eindpunt, kunt u de DNS-configuratie observeren door de cmdlet Resolve-DnsName aan te roepen vanuit PowerShell in een Azure VM (alternatief 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     storageaccount.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. storageaccount.file.core.windows.net is bijvoorbeeld een CNAME-record voor storageaccount.privatelink.file.core.windows.net. Dit is op zijn beurt een CNAME-record 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

Deze configuratie weerspiegelt dat het opslagaccount zowel het publieke eindpunt als één of meer privé-eindpunten kan blootstellen. 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. U kunt dit op verschillende manieren doen:

• 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 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.
• Stuur de core.windows.net zone van uw on-premises DNS-servers door naar uw Azure privé-DNS-zone. De Azure privé-DNS-host kan worden bereikt via een speciaal IP-adres (168.63.129.16) dat alleen toegankelijk is binnen virtuele netwerken die zijn gekoppeld aan de Azure privé-DNS-zone. Om deze beperking te omzeilen, kun je extra DNS-servers binnen je virtuele netwerk draaien die doorsturen core.windows.net naar de Azure private DNS-zone. Om deze opzet te vereenvoudigen, biedt Microsoft PowerShell-cmdlets aan die DNS-servers automatisch in je Azure-virtueel netwerk uitrollen en deze naar wens configureren. Zie Dns configureren met Azure Files voor meer informatie over het instellen van DNS-doorsturen.

SMB via QUIC

Windows Server 2022 Azure Edition ondersteunt een transportprotocol genaamd QUIC voor de SMB-server die wordt geleverd door de File Server-rol. QUIC is een vervanger van TCP die bovenop UDP is gebouwd en biedt tal van voordelen ten opzichte van TCP terwijl het toch 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. Deze configuratie betekent in feite dat SMB via QUIC een "SMB VPN" biedt voor bestandsdeling via het publieke internet. Windows 11 wordt geleverd met een client die compatibel is met SMB via QUIC.

Momenteel ondersteunt Azure Files SMB niet boven QUIC. Je kunt echter toegang krijgen tot Azure-bestandsdelingen via Azure File Sync die draait op Windows Server, zoals in het onderstaande diagram. Deze configuratie geeft je ook de mogelijkheid om Azure File Sync zowel on-premises als in verschillende Azure-datacenters te laten cachen om lokale caches te bieden voor een gedistribueerd personeel. Voor meer informatie over deze optie, zie de Windows Server-documentatie. Voor netwerkdetails specifiek voor Azure File Sync, zie SMB over QUIC.

Zie ook

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