overwegingen voor Azure Files netwerken

✔️ Van toepassing op: Alle Azure file shares

Dit artikel beschrijft de netwerkbeslissingen die je moet nemen voordat je Azure Files uitrolt: hoe je data tijdens transport beschermt, hoe clients verbinding maken met een bestandsdeling, en hoe je inkomende en uitgaande toegang kunt beheren. Voor configuratiestappen raadpleegt u Netwerkeindpunten configureren voor Azure-bestandsshares. Voor andere implementatiebeslissingen, zie Plan een Azure Files-implementatie.

De beschikbare opties hangen af van de resource provider die je gebruikt om de file share aan te maken, en van het protocol dat clients gebruiken. Klassieke bestandsshares (Microsoft. Storage) ondersteunen SMB, NFS en FileREST. Bestandsdelingen die met Microsoft.FileShares zijn gemaakt, ondersteunen alleen NFS. Voor andere verschillen tussen de resource providers, zie Azure Files management concepts.

De volgende tabel toont hoe clients een bestandsdeling kunnen bereiken, op basis van clientlocatie en protocol:

• SMB communiceert via TCP-poort 445. Sommige organisaties en internetproviders blokkeren uitgaand verkeer op deze poort. Clients die poort 445 niet kunnen gebruiken, kunnen via een VPN of ExpressRoute verbinding maken, of SMB over QUIC gebruiken via Azure File Sync.
• NFS gebruikt netwerkgebaseerde authenticatie, dus het ondersteunt geen toegang van clients op internet.

Versleuteling tijdens verzending

Versleuteling tijdens transport beschermt data tussen clients en Azure Files tegen onderschepping en wijziging, ook door een man-in-the-middle-aanvaller. Het geldt voor verkeer via zowel publieke als private eindpunten.

• SMB: SMB 3.x beschermt data via SMB-kanaalencryptie. Azure Files ondersteunt AES-128-CCM met SMB 3.0, en AES-128-GCM en AES-256-GCM met SMB 3.1.1. De client en de service komen tot overeenstemming over het algoritme uit de algoritmen die beide toestaan. SMB 2.1 ondersteunt geen kanaalencryptie. Als je de toegestane algoritmes beperkt, kunnen sommige clients niet verbinden. Oudere Windows-clients ondersteunen bijvoorbeeld geen AES-256-GCM.
• NFS: NFS-bestandsdelingen met een van beide resourceproviders ondersteunen encryptie tijdens transport via een TLS-tunnel. De AzNFS-mount-helper gebruikt stunnel om NFS-verkeer via een TLS 1.2- of TLS 1.3-verbinding te vervoeren en valideert het certificaat van de server. Applicaties gebruiken het NFS-protocol zonder wijzigingen. TLS voegt geen gebruikersgebaseerde authenticatie toe aan NFS.
• FileREST: FileREST beschermt data tijdens het transport via HTTPS, met TLS 1.2 of TLS 1.3. Nieuwe opslagaccounts vereisen standaard HTTPS en weigeren niet-versleutelde HTTP-verzoeken. Houd deze vereiste ingeschakeld. Je kunt ook een minimale TLS-versie instellen.

Encryptievereisten en standaardinstellingen hangen af van de resourceprovider. Om ze te bekijken en te wijzigen, zie:

• Klassieke bestandsdelingen: Configureer encryptie tijdens transport voor Azure Files. Om SMB-encryptie-algoritmen te beperken, zie SMB-beveiligingsinstellingen. Om een NFS-bestandsdeling met encryptie te mounten, zie Mount een klassieke NFS-share met behulp van de AzNFS-mounthulp.
• Microsoft. FileShares: Encryptievereisten bij het aanmaken van een bestandsdeling en het bijwerken van bestandsdelingseigenschappen met PowerShell of Azure CLI.

Verbindingspaden

Een client bereikt een bestandsdeling via het publieke eindpunt of via een privé-eindpunt. Beide eindpunten gebruiken dezelfde hostnaam. DNS-resolutie bepaalt welk eindpunt een client gebruikt.

Openbaar eindpunt

Een openbaar eindpunt heeft een publiek IP-adres. Een openbaar adres betekent geen onbeperkte toegang: protocolvereisten, inkomende toegangscontroles en autorisatie bepalen of een verzoek is toegestaan.

Elk protocol heeft zijn eigen limieten voor toegang tot openbare eindpunten, los van de netwerkregels die je instelt:

• SMB: Versleutelde SMB 3.x-verbindingen kunnen afkomstig zijn van clients binnen of buiten Azure. Azure Files beperkt deze alleen door authenticatie en autorisatie. Niet-versleutelde SMB-verbindingen zijn beperkt tot clients in dezelfde Azure-regio en vereisen een configuratie die onversleutelde toegang toestaat. Clients in die regio buiten je virtuele netwerken kunnen ook verbinding maken. Als je onversleutelde SMB toestaat, beperk dan het publieke eindpunt door netwerkregels te gebruiken.
• NFS: Clients kunnen alleen via een service-endpoint toegang krijgen tot het publieke endpoint. De netwerkregels van de file share moeten het subnet van de client toestaan. NFS ondersteunt geen directe toegang vanaf internetclients.
• FileREST: Verzoeken kunnen afkomstig zijn van clients binnen of buiten Azure. Azure Files beperkt de toegang ertoe alleen via authenticatie en autorisatie. Standaard weigert Azure Files ook niet-versleutelde HTTP-verzoeken.

Service-eindpunten

Een service-endpoint stelt clients in een virtueel netwerksubnet in staat het publieke endpoint te gebruiken wanneer netwerkregels het beperken tot geselecteerde subnetten. Verkeer van het subnet gaat naar Azure Files via de Azure-backbone, maar het gebruikt nog steeds het IP-adres van het publieke endpoint. De netwerklaag identificeert het bronsubnet van dit verkeer, zodat Azure Files het subnet kan toetsen aan de netwerkregels. Om een subnet toe te staan, voeg je er een virtuele netwerkregel voor toe.

Netwerkroutering van openbaar eindpunt

Routingvoorkeur is alleen beschikbaar voor klassieke HDD-bestandsdelingen die het pay-as-you-go factureringsmodel gebruiken in StorageV2 opslagaccounts. Het wordt niet ondersteund voor geprovisioneerde bestandsdelingen in FileStorage opslagaccounts of voor Microsoft.FileShares.

Voor deze pay-as-you-go-accounts bepaalt de routeringsvoorkeur hoe het internetverkeer het publieke eindpunt bereikt:

• Microsoft routing (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 ondersteunt Active Directory (AD) domein-joinscenario's en Azure File Sync.
• Internetroutering: Het verkeer gaat zo vroeg mogelijk over het openbare internet. Deze optie ondersteunt geen AD-domein join-scenario's of Azure File Sync.

Om de routeringsvoorkeur te controleren of te wijzigen, zie Routeringsvoorkeur configureren.

Privé-eindpunten

Een privé-endpoint geeft de resource (een opslagaccount of een Microsoft. FileShares file share) een privé IP-adres in een subnet van je virtuele netwerk. Clients kunnen dat adres bereiken vanuit hetzelfde virtuele netwerk, via peered virtuele netwerken en vanuit on-premises netwerken die via een VPN of ExpressRoute verbinding maken met het virtuele netwerk. Om toegang te krijgen vanuit meer virtuele netwerken, kun je meer dan één privé-endpoint voor dezelfde bron aanmaken.

Het publieke eindpunt blijft beschikbaar nadat je een privé-eindpunt hebt aangemaakt. Om toegang alleen via privé-endpoints toe te staan, schakel de toegang tot het publieke netwerk uit. Een privé-endpoint beperkt ook niet waar clients verkeer naartoe kunnen sturen. Voor die controles, zie Uitgaande toegangscontrole.

Zie Een privé-eindpunt maken voor instructies over het creëren van een privé-eindpunt.

Verbinding maken vanuit een lokale omgeving

On-premises clients kunnen een privé-endpoint bereiken via een VPN of ExpressRoute private peeringverbinding. Deze benadering geldt zowel voor MKB's als NFS. SMB- en FileREST-clients kunnen ook het publieke eindpunt bereiken via internet of ExpressRoute Microsoft peering. Als netwerkregels het publieke eindpunt beperken, voeg dan een IP-adresregel toe voor de publieke IP-adressen van de clients.

Voor MKB's werkt een verbinding met het publieke eindpunt vaak niet vanuit on-premises netwerken. Deze beperking bestaat omdat SMB TCP-poort 445 gebruikt, en veel organisaties en internetproviders uitgaand verkeer op deze poort blokkeren. Een VPN- of ExpressRoute-verbinding draagt SMB-verkeer naar het privé-eindpunt binnen de verbinding, dus de blokkade geldt niet. Voor lokale SMB-clients is het belangrijk om een privé-endpoint met een VPN- of ExpressRoute-verbinding te gebruiken, tenzij je bevestigt dat je netwerk uitgaande TCP-poort 445 naar Azure toestaat.

De volgende opties verbinden on-premises clients met Azure:

• Point-to-site VPN: Verbindt een individuele client met een virtueel Azure-netwerk. Het ondersteunt externe gebruikers en apparaten die niet via het sitenetwerk van een organisatie verbonden zijn. Voor installatiestappen, zie Configureer serverinstellingen voor P2S VPN Gateway certificaatauthenticatie.

• Site-to-site VPN: Verbindt het netwerk van een organisatie met een virtueel Azure-netwerk via een VPN-gateway. Clients op het verbonden netwerk delen die verbinding. Voor de opstellingstappen, zie Tutorial: Maak een site-to-site VPN-verbinding aan in het Azure-portaal.

• ExpressRoute: Private peering verbindt een on-premises netwerk met Azure virtuele netwerken zonder via het publieke internet te gaan. ExpressRoute versleutelt standaard geen verkeer. Gebruik versleuteling tijdens transport om bestandsgegevens op de verbinding te beschermen. Voor connectiviteitsopties, zie Wat is Azure ExpressRoute?.

• SMB over QUIC: Draagt SMB-verkeer via UDP-poort 443, dus het werkt wanneer TCP-poort 445 geblokkeerd is. Azure Files ondersteunt SMB niet direct via QUIC. Clients maken verbinding met een Windows Server-cache van een klassieke SMB-bestandsdeling, en Azure File Sync houdt de cache synchroon met de bestandsdeling. De cache kan on-premises of in Azure zijn. De cacheserver levert het QUIC-eindpunt, en clients hebben SMB over QUIC-ondersteuning nodig. Voor meer informatie, zie SMB over QUIC in de Windows Server-documentatie en SMB over QUIC voor Azure File Sync.

  Het volgende diagram toont SMB over QUIC met een Azure File Sync-cache:

  

Om toegang op te zetten voor on-premises clients via een privé-endpoint, volgt u deze stappen:

1. Maak een privé-endpoint aan voor de bestandsdeling. Zie Een privé-eindpunt maken.
2. Verbind het on-premises netwerk of de client met het virtuele netwerk van het privé-endpoint met een van de opties in de vorige lijst.
3. Stel DNS zo in dat on-premises clients de hostnaam van de bestandsdeling omzetten naar het IP-adres van het privé-endpoint. Zie Configure DNS forwarding for Azure Files. Point-to-site clients gebruiken mogelijk je on-premises DNS-servers niet. Voor die clients voeg je de DNS-forwarder of resolver toe als een aangepaste DNS-server in de VPN-client. Zie optionele instellingen voor Azure VPN Client.
4. Controleer of de hostnaam wordt omgezet naar het IP-adres van het privé-endpoint. Zie Verifieer dat DNS-forwarding werkt.
5. Koppel de bestandsshare. Zie SMB Azure-bestandsshare koppelen op Windows, Een Azure-bestandsshare koppelen op macOS, SMB Azure-bestandsshares koppelen op Linux-clients, of NFS Azure-bestandsshares koppelen op Linux.

DNS-resolutie

Clients gebruiken dezelfde hostnaam voor het publieke eindpunt en voor een privé eindpunt. DNS bepaalt naar welk IP-adres de hostnaam wordt omgezet.

• Klassieke bestandsshares: De hostnaam is <storage-account-name>.file.core.windows.net.
• Microsoft. FileShares: Elke bestandsdeling heeft zijn eigen gegenereerde hostnaam, in de hostName eigenschap van de bestandsdeling. De hostnaam staat los van de resourcenaam van de bestandsdeling en van de mountnaam.

Wanneer je een privé-endpoint aanmaakt, wordt het publieke DNS-record voor de hostnaam een alias (CNAME) voor een naam in de privatelink.file.core.windows.net zone. Clients in een virtueel netwerk dat gekoppeld is aan een private DNS-zone met die naam, lossen de alias op naar het IP-adres van het privé-endpoint. Andere clients lossen de alias op naar het IP-adres van het publieke eindpunt. Om de private DNS-zone met het private endpoint aan te maken, zie Een privaat eindpunt maken. Om het resultaat te controleren, zie Connectiviteit verifiëren.

On-premises clients gebruiken standaard geen Azure DNS, dus een VPN- of ExpressRoute-verbinding alleen geeft ze geen privé-resolutie. Stuur hun DNS-queries voor het domein van de bestandsdeling door naar Azure via Azure DNS Private Resolver of een virtuele machine met DNS-forwarder. Voor stappen, zie Configureer DNS forwarding voor Azure Files. Voor andere on-premises DNS-ontwerpen, zie Azure private endpoint DNS-integratie.

De hostnamen en zonenamen in deze sectie zijn voor de publieke Azure-cloud. Andere Azure-clouds gebruiken een ander domein, zoals core.usgovcloudapi.net in Azure Government. Voor de private DNS-zonenamen in elke cloud, zie Azure Private Endpoint private DNS zone-waarden.

Toegangsbeheer voor inkomend verkeer

Inkomende toegangscontroles bepalen welke clients toegang krijgen tot een bestandsdeling:

• Privé-endpointverkeer valt niet onder de publieke netwerktoegangsinstelling, netwerkregels of een netwerkbeveiligingsperimeter.
• Openbaar eindpuntverkeer moet voldoen aan de instelling voor openbare netwerktoegang. Als het opslagaccount is gekoppeld aan een netwerkbeveiligingsperimeter, krijgen de toegangsregels van die perimeter voorrang boven de netwerkregels. Zo niet bepalen de netwerkregels de toegang.
• Autorisatie geldt voor elk verzoek dat de bestandsdeling bereikt, via elk van beide eindpunten.

Openbare netwerktoegang

Je kunt de toegang tot het publieke netwerk uitschakelen, of het ingeschakeld houden en beperken met netwerkregels. Het uitschakelen van openbare netwerktoegang voorkomt ook clienttoegang via service-eindpunten. Toegang tot privé-endpoints is onafhankelijk van deze instelling. Voor klassieke bestandsdelingen blijven bestaande uitzonderingen voor vertrouwde diensten en resource-instanties van kracht nadat je de toegang tot het publieke netwerk hebt uitgeschakeld.

Voor configuratiestappen voor beide resource providers, zie Toegang tot publieke eindpunten beperken.

Netwerkregels

Netwerkregels bepalen welke clients het publieke eindpunt kunnen bereiken. Er zijn twee soorten:

• Virtuele netwerkregels staan clients toe in een subnet met een service-endpoint. Beide resourceproviders ondersteunen virtuele netwerkregels. NFS-clients hebben een service-endpoint nodig, dus virtuele netwerkregels zijn hoe je ze toestaat.
• IP-adresregels staan clients toe op basis van een openbaar IP-adres. Alleen klassieke bestandsdelingen ondersteunen IP-adresregels, voor SMB en FileREST.

Netwerkregels zijn van toepassing op data-toegang via SMB, NFS en FileREST. Ze zijn niet van toepassing op beheeroperaties via Azure Resource Manager, zoals het aanmaken van een bestandsdeling of het wijzigen van de eigenschappen ervan. Wanneer je bestandsgegevens bekijkt in het Azure-portaal, stuurt je browser FileREST-verzoeken naar het eindpunt van de bestandsservice, dus de netwerkregels moeten verkeer vanaf je computer toestaan. Voor de permissies die nodig zijn voor het navigeren in de portal, zie Toegang tot bestandsgegevens autoriseren in het Azure-portaal.

Regels voor virtuele netwerken

Een virtuele netwerkregel staat verkeer toe vanaf een subnet dat een Microsoft.Storage of Microsoft.Storage.Global service-eindpunt heeft. Zowel de Microsoft.Storage- (opslagaccounts) als Microsoft.FileShares-resourceproviders gebruiken deze service-endpointnamen. Houd rekening met deze punten:

• Het subnet kan zich in een andere regio dan de resource bevinden. Voor toegang vanuit andere regio's gebruik je het Microsoft.Storage.Global service-endpoint. Een subnet kan slechts één van deze twee service-eindpunten hebben.
• Het subnet kan in een ander abonnement of in een andere Microsoft Entra-tenant zitten. Om een subnet van een andere tenant toe te voegen, gebruik je Azure PowerShell of Azure CLI. Het Azure-portaal toont geen subnetten in andere tenants.
• Elke bron ondersteunt tot 400 virtuele netwerkregels. Om een regel toe te voegen, heb je de machtiging Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action op het subnet nodig.
• Het verwijderen van een subnet verwijdert het uit de netwerkregels van het opslagaccount. Een nieuw subnet met dezelfde naam krijgt pas toegang als je het toevoegt aan de netwerkregels. (Alleen klassieke bestandsdelingen.)
• Als je van plan bent een geo-redundant opslagaccount te failoveren, maak dan de virtuele netwerken in de secundaire regio voordat je ze nodig hebt. Voeg virtuele netwerkregels toe voor hun subnetten zodat clients in die virtuele netwerken na een failover kunnen verbinden. (Alleen klassieke bestandsdelingen.)

IP-adresregels

Klassieke bestandsdelingen ondersteunen IP-adresregels voor SMB- en FileREST-toegang vanaf het internet. Microsoft. FileShares ondersteunt geen IP-adresregels. Houd rekening met deze punten:

• IP-adresregels accepteren alleen openbare IPv4-adressen. Je kunt geen privéadresbereiken toevoegen, zoals adressen die beginnen met 10, 172.16 tot 172.31 of 192.168.
• Specificeer adresbereiken in CIDR-notatie, zoals 203.0.113.0/24. Bereiken met een /31 of /32 prefix worden niet ondersteund. Voeg deze adressen toe als individuele IP-adresregels.
• IP-adresregels hebben geen effect op verzoeken van clients in dezelfde Azure-regio als het opslagaccount, of van clients in een subnet met een service-endpoint. Gebruik virtuele netwerkregels voor deze clients. De uitzondering is een regel voor het IP-adres van een standaard service-eindpunt.
• Een opslagaccount ondersteunt tot 400 IP-adresregels.
• Om clients in een on-premises netwerk toe te laten, voeg je de publieke IP-adressen toe die het netwerk gebruikt voor internetverkeer. Als je Azure ExpressRoute gebruikt met Microsoft-peering, voeg dan de netwerkadresvertaling (NAT) IP-adressen toe die Microsoft peering gebruikt.

Uitzonderingen voor Azure-diensten

Voor klassieke bestandsdelingen kun je Azure-diensten toestaan die geen virtuele netwerk- of IP-adresregels kunnen gebruiken:

• Vertrouwde services: De uitzondering Vertrouwde Microsoft-services toestaan toegang te krijgen tot deze resource laat services zoals Azure File Sync toe. Schakel dit alleen in wanneer een integratie dit nodig heeft. Raadpleeg Trusted Azure services voor een lijst met services.
• Resource-instanties: Een resource instance rule stelt een specifieke Azure-resource in je Microsoft Entra-tenant in staat het publieke eindpunt te bereiken. De resource heeft nog steeds toestemming nodig om toegang te krijgen tot bestandsgegevens.

Een netwerkbeveiligingsperimeter is de nieuwere manier waarop Azure-diensten kunnen worden toegestaan. Het beheert de toegang tot veel bronnen op één plek. Wij raden een perimeter aan wanneer de diensten die u gebruikt erop zijn onboard. Je hebt deze uitzonderingen misschien nog steeds nodig voor diensten die niet onboarded zijn, zoals Azure Backup, of als je geen perimeter gebruikt.

Microsoft.FileShares ondersteunt deze uitzonderingen niet.

Netwerkbeveiligingsperimeter

Een netwerkbeveiligingsperimeter plaatst PaaS-middelen binnen een logische grens en beheert de openbare netwerktoegang ertoe. Alleen klassieke bestandsshares ondersteunen Network Security Perimeters.

Wanneer je een opslagaccount koppelt aan een perimeter, overrulen de toegangsregels in het perimeterprofiel de netwerkregels van het opslagaccount. De perimeter heeft twee toegangsmodi:

• Overgang: De standaardmodus. Als geen perimeterregel een verbinding toestaat, gelden de eigen netwerkregels van het opslagaccount en uitzonderingen voor Azure-diensten. Door gebruik te maken van diagnostische logs kun je verkeer vinden dat de perimeterregels niet toestaan. Gebruik de Transition-modus alleen als tijdelijke stap.
• Afgedwongen beleid: Alleen perimeterregels zijn van toepassing. De virtuele netwerkregels, IP-adresregels en uitzonderingen voor Azure-diensten van het opslagaccount zijn niet van toepassing. Om een Azure-dienst die niet is opgenomen in de netwerkbeveiligingsperimeter toe te staan, voeg een toegangsregel op basis van inbound subscriptions toe.

Een perimeter bepaalt welke clients het opslagaccount via het publieke eindpunt kunnen bereiken. Het stelt klanten op twee manieren in staat:

• Resource to resource: Andere PaaS-resources in de perimeter en Azure-resources in abonnementen die door een inkomende, op abonnementen gebaseerde regel worden toegestaan. De perimeter identificeert deze clients aan de hand van hun Microsoft Entra-identiteit, die alleen in OAuth-verzoeken wordt meegedragen. Voor Azure Files geldt deze toegang alleen voor FileREST met OAuth.
• Clients op IP-adres: Inbound IP-gebaseerde regels staan clients toe op basis van hun openbare IP-adres.
  • Clients in Azure virtuele netwerken verbinden via een standaard service-endpoint. Een IP-gebaseerde regel voor het IP-adres van het service-endpoint maakt SMB, NFS en FileREST mogelijk. In de Enforced-modus weigert de perimeter verkeer via service-endpoints die geen toegewezen IP-adres hebben.
  • Clients buiten Azure verbinden vanaf hun publieke IP-adres. Een IP-gebaseerde regel voor dat adres maakt SMB en FileREST mogelijk. NFS ondersteunt geen clients buiten Azure.

Privé-endpointverkeer valt niet onder perimeterregels.

De volgende tabel toont welke inkomende regels van toepassing zijn op elk protocol en elke authenticatiemethode:

Controleer deze integraties voordat je een opslagaccount koppelt aan een perimeter:

• Klantbeheerde sleutels: Als de sleutelkluis waarin de klantbeheerde sleutel zich bevindt in een perimeter staat, plaats dan het opslagaccount in dezelfde perimeter. Configureer anders het perimeterprofiel van de sleutelkluis om het opslagaccount toe te staan.
• Azure Backup: Azure Backup is niet onboarded aan de netwerkbeveiligingsperimeter. Gebruik geen perimeter voor opslagaccounts die Azure Backup gebruiken.
• Azure File Sync: Je kunt een Storage Sync Service niet koppelen aan een perimeter. Configureer de Storage Sync Service voor het gebruik van beheerde identiteiten. Voeg vervolgens een inbound abonnementgebaseerde toegangsregel toe waarmee abonnementgebaseerde toegang voor de Storage Sync Service wordt toegestaan.

Om een perimeter te koppelen aan een opslagaccount, zie Overgang naar een netwerkbeveiligingsperimeter in Azure.

Standaard service-uiteinden

Een standaard service-eindpunt is een service-eindpunt dat een openbaar IP-adres toegewezen heeft gekregen. Je maakt het publieke IP-adres aan en wijst het toe aan het Microsoft.Storage service-eindpunt van het subnet. Azure Storage gebruikt dat adres vervolgens om verkeer van het subnet te identificeren. Het adres labelt alleen het verkeer. Verkeer wordt er niet doorheen geleid, en clients gebruiken het niet, dus het eigen publieke IP-adres van een client werkt niet als vervanging daarvoor. De Azure-netwerkdocumentatie noemt dit adres een netwerk-id, en noemt een service-endpoint zonder zo’n een basisservice-endpoint.

Standaard service-endpoints laten clients in virtuele netwerken een opslagaccount bereiken in een netwerkbeveiligingsperimeter zonder een privé-endpoint. Om dit toe te staan, voeg je een inkomende IP-gebaseerde toegangsregel toe voor het IP-adres van het service-eindpunt aan het perimeterprofiel. De regel staat SMB-, NFS- en FileREST-verkeer toe vanuit elk subnet dat het IP-adres gebruikt. Eén IP-adres kan meerdere subnetten en virtuele netwerken in dezelfde regio vertegenwoordigen, inclusief virtuele netwerken in andere abonnementen binnen dezelfde Microsoft Entra-tenant. Wanneer je subnetten toevoegt of verwijdert die het IP-adres gebruiken, hoef je de regels van de perimeter niet te wijzigen.

De IP-adresregels van een opslagaccount kunnen ook het IP-adres van het service-endpoint toestaan, zonder perimeter. Zonder perimeter biedt een basisservice-endpoint met virtuele netwerkregels dezelfde toegang zonder extra kosten.

Houd rekening met deze punten:

• Een standaard service-eindpunt identificeert nog steeds het bronsubnet. Virtuele netwerkregels waardoor het subnet is toegestaan blijven van toepassing nadat je een IP-adres hebt toegewezen, totdat de perimeter in Enforce-modus staat.
• Het toewijzen of wijzigen van het IP-adres reset actieve verbindingen vanuit het subnet. Plan de wijziging in voor een onderhoudsperiode.
• Standaard service-endpoints ondersteunen geen verkeer van on-premises netwerken. Gebruik een privé-endpoint voor on-premises toegang.
• Standaard service-endpoints zijn een betaalde functie die per virtueel netwerk wordt belast. Zie prijzen voor Azure Private Link voor meer informatie.

Clients in een subnet met een standaard service-endpoint kunnen nog steeds toegang krijgen tot een Microsoft. FileShares bestandsdeling als het subnet zich in de toegestane subnetten van de bestandsdeling bevindt.

Om een standaard service-endpoint te configureren, zie Toegang toestaan vanaf een standaard service-endpoint.

Uitgaande toegangscontrole

Netwerkregels voor een bestandsdeling regelen inkomende toegang. Ze beperken de uitgaande bestemmingen van klanten niet. Een client die bijvoorbeeld een bestandsdeling kan lezen, kan data kopiëren naar een andere hulpbron waar hij toestemming voor heeft om naartoe te schrijven.

Beperk uitgaande toegang met service-endpointbeleid

Voor klassieke bestandsdelingen kun je een service-endpointbeleid gebruiken om te beperken welke opslagaccounts clients in een subnet via service-endpoints kunnen benaderen. Het beleid geldt voor alle clients in dat subnet. De netwerkregels en autorisatievereisten van de bestemming blijven van toepassing.

Service-endpointbeleid werkt samen met andere netwerkbesturingselementen:

• Service Endpoint-routes overschrijven door de gebruiker gedefinieerde routes (UDR's) voor de bijbehorende serviceadresprefixen. Verkeer dat via een service-endpoint wordt gerouteerd, gaat niet door de Azure Firewall of een virtueel netwerkapparaat (NVA), dus deze apparaten kunnen het niet inspecteren of loggen. Zie Service-eindpunten voor virtuele netwerken voor meer informatie.
• NSG-regels kunnen servicetags gebruiken, zoals Storage.WestUS, om uitgaand verkeer tot een regio te beperken. Servicetags kunnen het verkeer niet beperken tot een specifiek opslagaccount.

De allowlist van het beleid kan individuele opslagaccounts, resourcegroepen of abonnementen bevatten. Het beleid voorkomt dat clients in het bijbehorende subnet via service-endpoints toegang krijgen tot andere opslagaccounts. Het beperkt andere uitgaande paden vanuit het subnet niet.

Service-endpointbeleid geldt niet voor privé-endpoint verkeer.

Om een service-endpointbeleid te configureren, zie Beperk uitgaande toegang tot specifieke opslagaccounts.

Verwante onderwerpen

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