Überlegungen zu Azure Files Netzwerken

✔️ Gilt für: Alle Azure Dateifreigaben

Azure-Dateifreigaben haben öffentliche Endpunkte und können ein oder mehrere private Endpunkte besitzen. Die für die Clients verfügbaren Netzwerkpfade hängen vom Protokoll und den Netzwerkregeln ab. Dieser Artikel behandelt sowohl klassische Dateifreigaben (Microsoft.Storage) als auch Dateifreigaben, die mit Microsoft.FileShares erstellt wurden. Azure-Dateisynchronisierung bietet eine Caching-Option für klassische SMB-Dateifreigaben. Weitere Informationen finden Sie unter Introduction to Azure-Dateisynchronisierung.

Für umfassendere Überlegungen zur Bereitstellung siehe Bereitstellen von Azure Files planen. Für Konfigurationsschritte siehe Netzwerk-Endpunkte konfigurieren für Azure-Dateifreigaben.

Zwei Protokollunterschiede betreffen das Netzwerkdesign:

• SMB verwendet TCP-Port 445, den einige Organisationen und Internetdienstanbieter für ausgehenden Datenverkehr blockieren. Private Verbindung über VPN oder ExpressRoute bietet einen alternativen Weg.

• NFS verwendet netzwerkbasierte Authentifizierung. Clients verbinden sich über private Endpunkte oder über Service-Endpunkte aus zulässigen Subnetzen virtueller Netzwerke.

Klassische Dateifreigaben unterstützen SMB und NFS. Microsoft. FileShares unterstützt derzeit NFS. Beide Ressourcenanbieter unterstützen öffentliche und private Endpunkte. Für Unterschiede im Ressourcenbesitz und -management siehe Azure Files Management Concepts.

Verschlüsselung während der Übertragung

Die Verschlüsselung während des Transits schützt die Vertraulichkeit und Integrität der Daten zwischen Clients und Azure Files, einschließlich Schutz vor Abfangen oder Änderungen durch einen Man-in-the-Middle-Angreifer. Dieser Schutz gilt sowohl für öffentliche als auch für private Endpunkte. Verschlüsselungs- und Netzwerkzugriffsregeln haben getrennte Zwecke: Verschlüsselung schützt die Verbindung, während Netzwerkregeln bestimmen, welche Clients den Dienst erreichen können.

Verschlüsselung während des Transports für SMB

SMB 3.x schützt Daten durch SMB-Kanalverschlüsselung. Azure Files unterstützt AES-128-CCM mit SMB 3.0 sowie AES-128-GCM und AES-256-GCM mit SMB 3.1.1. Der Verschlüsselungsalgorithmus hängt von den Fähigkeiten des Clients und den vom Dienst erlaubten Algorithmen ab. SMB 2.1 unterstützt keine Kanalverschlüsselung.

Die Einschränkung der erlaubten Algorithmen kann die Client-Kompatibilität beeinträchtigen. Zum Beispiel unterstützen ältere Windows-Clients AES-256-GCM nicht. Kanalverschlüsselung schützt Dateidaten auf der Verbindung; Kerberos-Ticketverschlüsselung schützt Authentifizierungstickets. Das sind separate Bedienelemente. Für Kundensupport und Konfiguration siehe SMB-Sicherheitseinstellungen.

Verschlüsselung im Transit für NFS

NFS-Dateifreigaben mit jedem der beiden Ressourcenanbieter unterstützen Verschlüsselung durch TLS-Tunneling. Der AZNFS-Mount-Helfer verwendet Stunnel, um NFS-Verkehr durch eine verschlüsselte Verbindung zwischen dem Client und Azure Files zu transportieren. AZNFS unterstützt TLS 1.2 und TLS 1.3 und validiert das Zertifikat des Servers. Anwendungen verwenden weiterhin das NFS-Protokoll, ohne TLS selbst zu implementieren.

TLS schützt Daten während der Übertragung, fügt aber keine benutzerbasierte Authentifizierung zum NFS hinzu. Netzwerkzugriffsregeln und Dateiberechtigungen steuern weiterhin den Zugriff. Für verschlüsselte Mount-Anweisungen siehe Daten während der Übertragung für NFS-Freigaben verschlüsseln.

Verschlüsselung im Transit für FileREST

FileREST schützt Daten während der Übertragung über HTTPS. Azure Files unterstützt TLS 1.2 und TLS 1.3 für HTTPS-Verbindungen. Die Anforderung von HTTPS lehnt unverschlüsselte HTTP-Anfragen ab; eine Mindestanforderung an die TLS-Version bestimmt, welche TLS-Versionen Clients verwenden können.

FileREST-Datenzugriff ist für klassische Dateifreigaben verfügbar. Microsoft. FileShares unterstützt derzeit keinen Zugriff auf FileREST-Daten.

Verschlüsselungskonfigurationsanleitungen

Verschlüsselungsanforderungen und Standardeinstellungen hängen vom Ressourcenanbieter und Protokoll ab. Die folgenden Anleitungen beschreiben, wie man sie anzeigt und ändert:

• Microsoft. FileShares: Verschlüsselungsanforderungen beim Erstellen einer Dateifreigabe und Aktualisierung der Dateifreigabeeigenschaften mit PowerShell oder Azure CLI.
• Klassische Dateifreigaben: SMB-Verschlüsselung, NFS-Verschlüsselung und HTTPS-Anforderungen für FileREST.

Öffentlicher Endpunkt

Ein öffentlicher Endpunkt hat eine öffentliche IP-Adresse. Eine öffentliche Adresse bedeutet keinen uneingeschränkten Zugriff: Protokollanforderungen, Netzwerkregeln und Autorisierung bestimmen, ob eine Anfrage erlaubt ist.

Die Protokolle haben unterschiedliche Regeln für den Zugriff auf öffentliche Endpunkte. SMB und FileREST gelten für klassische Dateifreigaben. NFS gilt für beide Ressourcenanbieter:

• SMB: Verschlüsselte SMB 3.x-Verbindungen können innerhalb oder außerhalb von Azure ausgehen, vorbehaltlich Netzwerkregeln und Autorisierungen. Unverschlüsselte SMB-Verbindungen sind auf Clients in derselben Azure-Region beschränkt und erfordern eine Konfiguration, die unverschlüsselten Zugriff erlaubt.

• NFS: Clients können nur über einen Service-Endpunkt aus einem erlaubten Subnetz auf den öffentlichen Endpunkt zugreifen. NFS unterstützt keinen direkten Zugriff von Internet-Clients.

• FileREST: Clients greifen über REST-Anfragen auf Dateidaten zu. HTTPS schützt diese Anfragen während der Übertragung. Netzwerkregeln und -autorisierungen gelten unabhängig davon, ob HTTPS erforderlich ist.

Eingehender Netzwerkzugriff

Netzwerkregeln steuern den eingehenden Zugriff auf den öffentlichen Endpunkt. Beide Ressourcenanbieter unterstützen den Zugriff aus ausgewählten Subnetzen virtueller Netzwerke. Der klassische SMB- und FileREST-Zugriff kann ebenfalls IP-Adressregeln verwenden. NFS-Zugriff erfordert Service-Endpunkte und erlaubte Subnetze.

Ein Service-Endpunkt transportiert den Datenverkehr von einem virtuellen Netzwerksubnetz über das Azure-Backbone zu Azure Files. Der Datenverkehr nutzt weiterhin die IP-Adresse des öffentlichen Endpunkts. Die Netzwerkschicht identifiziert das Quellsubnetz, sodass der Dienst es mit den erlaubten Netzwerken vergleichen kann.

Das Deaktivieren des öffentlichen Netzwerkzugriffs verhindert außerdem den Client-Zugriff über Service-Endpunkte. Der private Endpunktzugriff ist unabhängig von dieser Einstellung. Für klassische Dateifreigaben können bestehende Ausnahmen für vertrauenswürdige Dienste weiterhin in Kraft bleiben.

Für Konfigurationsschritte für beide Ressourcenanbieter siehe Zugriff auf öffentliche Endpunkte einschränken.

Ausgehenden Zugriff mit Dienstendpunktrichtlinien einschränken

Netzwerkregeln für eine Dateifreigabe regeln den eingehenden Zugriff. Sie schränken die ausgehenden Ziele der Kunden nicht ein. Zum Beispiel könnte ein Client, der eine Dateifreigabe lesen kann, Daten auf eine andere Ressource kopieren, auf die er schreiben darf.

Für klassische Dateifreigaben kann man optional eine Service-Endpunkt-Richtlinie verwenden, um zu begrenzen, auf welche Speicherkonten Clients in einem Subnetz über Service-Endpunkte zugreifen können. Die Richtlinie gilt für alle Clients in diesem Subnetz. Die Netzwerkregeln und Autorisierungsanforderungen des Ziels gelten weiterhin.

Service-Endpunkt-Richtlinien werden zusammen mit anderen Netzwerksteuerungen verwendet:

• Service-Endpunkt-Routen überschreiben benutzerdefinierte Routen (UDRs) für die passenden Serviceadresspräfixe. Datenverkehr, der über einen Service-Endpunkt geleitet wird, läuft nicht über die Azure Firewall oder eine Netzwerk-Virtual-Appliance (NVA), daher können diese Geräte ihn nicht inspizieren oder protokollieren. Weitere Informationen finden Sie unter VNET-Dienstendpunkte.
• Netzwerksicherheitsgruppenregeln (NSG) können Service-Tags verwenden, Storage.WestUS um ausgehenden Datenverkehr auf eine Region zu beschränken. Service-Tags können den Datenverkehr nicht auf ein bestimmtes Speicherkonto beschränken.

Die Erlaubnisliste der Richtlinie kann einzelne Speicherkonten, Ressourcengruppen oder Abonnements enthalten. Die Richtlinie blockiert Clients im zugehörigen Subnetz daran, über Service-Endpunkte auf andere Speicherkonten zuzugreifen. Es schränkt andere ausgehende Pfade vom Subnetz nicht ein.

Service-Endpunkt-Richtlinien gelten nicht für den Datenverkehr über private Endpunkte.

Um eine Service-Endpunkt-Richtlinie zu konfigurieren, siehe Einschränken des ausgehenden Zugriffs auf bestimmte Speicherkonten.

Azure-Portalzugriff

Das Öffnen einer Ressource im Azure-Portal und der Zugriff auf ihre Dateidaten sind getrennte Operationen. Für klassische Dateifreigaben sendet das Durchsuchen von Daten FileREST-Anfragen vom Browser an den Endpunkt des Dateidienstes. Diese Anfragen unterliegen den Netzwerkregeln des Speicherkontos. Allein der Zugriff auf das Portal gewährt keinen Netzwerkzugang zu Dateidaten.

Microsoft.FileShares unterstützt derzeit keinen Zugriff auf FileREST-Daten. Für klassische Anforderungen an das Browsing von Dateifreigaben und Fehlerbehebung siehe Zugriff auf Dateidaten autorisieren im Azure-Portal.

Routing des öffentlichen Endpunktnetzwerks

Routing-Präferenz ist nur für klassische HDD-Dateifreigaben verfügbar, die das Pay-as-you-go-Abrechnungsmodell in StorageV2-Speicherkonten verwenden. Es wird nicht für bereitgestellte Dateifreigaben in FileStorage Speicherkonten oder für Microsoft.FileShares unterstützt.

Für diese Pay-as-you-go-Konten bestimmt die Routing-Präferenz, wie der Internetverkehr den öffentlichen Endpunkt erreicht:

• Microsoft-Routing (Standard): Der Datenverkehr zwischen Client und Speicherkonto bewegt sich so lange wie möglich über das globale Netzwerk-Backbone von Microsoft, bevor er ins Internet austritt. Diese Option unterstützt Active Directory (AD) Domänen-Join-Szenarien und Azure-Dateisynchronisierung.
• Internet-Routing: Der Verkehr wird so früh wie möglich über das öffentliche Internet geleitet. Diese Option unterstützt weder Active Directory (AD) Domain-Join-Szenarien noch Azure-Dateisynchronisierung.

Für Konfigurationsschritte siehe Präferenz für Netzwerkrouting konfigurieren.

Private Endpunkte

Ein privater Endpunkt stellt eine private IP-Adresse in Ihrem virtuellen Netzwerk bereit, um auf eine Dateifreigabe zuzugreifen.

Jeder private Endpunkt ist mit einem virtuellen Netzwerk-Subnetz verbunden. Mehrere private Endpunkte können Zugriff auf dieselbe Dateifreigabe von verschiedenen virtuellen Netzwerken bieten.

Clients können einen privaten Endpunkt über das zugehörige virtuelle Netzwerk, gepeerte virtuelle Netzwerke oder verbundene lokale Netzwerke erreichen.

Private und öffentliche Endpunkte können koexistieren. Das Erstellen eines privaten Endpunkts deaktiviert den öffentlichen Zugriff nicht und schränkt auch andere ausgehende Pfade von Clients nicht ein.

Informationen zum Erstellen eines privaten Endpunkts finden Sie unter Configuring private Endpunkte für Azure Files.

Private Konnektivität aus lokalen Umgebungen

VPN und ExpressRoute bieten eine Verbindung zwischen lokalen Clients und privaten Endpunkten in einem virtuellen Azure-Netzwerk. Dieser Ansatz gilt sowohl für SMB als auch für NFS.

Die Verbindungsoptionen unterscheiden sich in Umfang und Transport:

Point-to-Site-VPN

Ein Point-to-Site-VPN verbindet einen einzelnen Client mit einem virtuellen Azure-Netzwerk. Es unterstützt entfernte Benutzer und Geräte, die nicht über das Standortnetzwerk einer Organisation verbunden sind. Für unterstützte Protokolle und Einrichtungsanleitungen siehe Informationen zu Point-to-Site-VPN.

Standort-zu-Standort-VPN-Verbindung

Ein Site-to-Site-VPN verbindet das Netzwerk einer Organisation über ein VPN-Gateway mit einem virtuellen Azure-Netzwerk. Clients im verbundenen Netzwerk teilen sich diese Verbindung. Für Architektur- und Einrichtungsanleitungen, siehe Site-to-site VPN.

ExpressRoute

ExpressRoute Private Peering verbindet ein On-Premises-Netzwerk mit Azure-virtuellen Netzwerken, ohne das öffentliche Internet zu durchqueren. Es bietet eine private Konnektivitätsoption für Arbeitslasten mit Anforderungen an die Netzwerkleistung oder an die Organisation. Die Verschlüsselung auf Anwendungsebene bleibt eine eigenständige Überlegung. Für Verbindungsoptionen und Einrichtungsanleitungen siehe ExpressRoute-Übersicht.

DNS-Auflösung

DNS bestimmt, ob der Hostname einer Dateifreigabe auf eine öffentliche oder private IP-Adresse aufgelöst wird. Clients verwenden denselben Hostnamen für jeden der beiden Pfade. Innerhalb eines Netzwerks, das private DNS für die Freigabe verwendet, wird der Name auf die IP-Adresse des privaten Endpunkts aufgelöst. Clients, die öffentliche DNS verwenden, lösen es stattdessen auf den öffentlichen Endpunkt auf.

Klassische Dateifreigaben verwenden den Hostnamen des Dateidiensts des Speicherkontos. Microsoft. FileShares weist jedem Dateishare einen generierten Hostnamen zu. Dieser generierte Name ist getrennt vom Ressourcennamen der Dateifreigabe.

In der öffentlichen Azure-Cloud nutzen beide Ressourcenanbieter die private DNS-Zoneprivatelink.file.core.windows.net. On-Premises-Clients benötigen Zugriff auf die privaten DNS-Datensätze sowie eine Netzwerkroute zum privaten Endpunkt. Eine VPN- oder ExpressRoute-Verbindung allein bietet keine private DNS-Auflösung. DNS-Weiterleitung oder Azure DNS Private Resolver können diese Auflösung bieten.

Für Konfiguration und Verifikation siehe:

• Erstellen Sie einen privaten Endpunkt mit DNS-Integration und überprüfen Sie die Konnektivität für beide Ressourcenanbieter.
• Azure Private Endpoint DNS-Integration für On-Premises-DNS-Designs.
• Konfigurieren Sie DNS-Weiterleitung für klassische Dateifreigaben; Azure Files-spezifische Beispiele finden Sie unter Konfigurieren Sie DNS-Weiterleitung für klassische Dateifreigaben.

SMB über QUIC

SMB über QUIC transportiert SMB-Verkehr über UDP-Port 443 und bietet eine Alternative, wenn TCP-Port 445 nicht verfügbar ist. Ein kompatibler Windows Server-Dateiserver stellt den QUIC-Endpunkt bereit, und Clients benötigen SMB-over-QUIC-Unterstützung.

Derzeit unterstützt Azure Files SMB nicht direkt über QUIC. Sie können über Azure-Dateisynchronisierung, wie im folgenden Diagramm gezeigt, auf einen Windows Server-Cache einer klassischen SMB-Dateifreigabe zugreifen. Diese Option gilt nicht für NFS oder Microsoft. FileShares. Sie können Azure-Dateisynchronisierung-Caches on-premises oder in Azure-Rechenzentren bereitstellen. Weitere Informationen finden Sie in der Windows Server-Dokumentation. Für Azure-Dateisynchronisierung-spezifische Netzwerkdetails siehe SMB over QUIC.

Siehe auch

• übersicht über Azure Files
• Planung für eine Azure Files-Bereitstellung