Überlegungen zum Netzwerk von Azure Files

Sie können auf Ihre Azure-Dateifreigaben über den öffentlichen Internetzugriffsendpunkt, über einen oder mehrere private Endpunkte in Ihrem Netzwerk oder durch Zwischenspeichern Ihrer lokalen Azure-Dateifreigabe mit Azure File Sync (nur SMB-Dateifreigaben) zugreifen. Dieser Artikel befasst sich mit der Konfiguration von Azure Files für den direkten Zugriff auf öffentliche und/oder private Endpunkte. Informationen dazu, wie Sie Ihre Azure-Dateifreigabe vor Ort mit Azure File Sync zwischenspeichern, finden Sie in Einführung in Azure File Sync.

Es wird empfohlen, die Planung für eine Azure Files-Bereitstellung vor dem Lesen dieses Handbuchs zu lesen.

Der direkte Zugriff auf eine Azure-Dateifreigabe erfordert häufig zusätzliche Überlegungen in Bezug auf netzwerke:

• SMB-Dateifreigaben kommunizieren über Port 445, den viele Organisationen und Internetdienstanbieter (Internet Service Providers, ISPs) für ausgehenden (Internet-) Datenverkehr blockieren. Diese Praktik stammt aus früheren Sicherheitsempfehlungen zu veralteten und nicht internetsicheren Versionen des SMB-Protokolls. Obwohl SMB 3.x ein internetsicheres Protokoll ist, können Organisations- oder ISP-Richtlinien möglicherweise nicht geändert werden. Deshalb erfordert das Einbinden einer SMB-Dateifreigabe oft eine zusätzliche Netzwerkkonfiguration, die außerhalb von Azure verwendet wird.

• NFS-Dateifreigaben basieren auf der Authentifizierung auf Netzwerkebene und sind deshalb nur über eingeschränkte Netzwerke zugänglich. Die Verwendung einer NFS-Dateifreigabe erfordert immer eine Ebene von Netzwerkkonfiguration.

Das Konfigurieren öffentlicher und privater Endpunkte für Azure Files erfolgt im Verwaltungsobjekt der obersten Ebene für Azure Files, das Azure-Speicherkonto. Ein Speicherkonto ist ein Verwaltungskonstrukt, das einen freigegebenen Speicherpool darstellt, in dem Sie mehrere Azure-Dateifreigaben bereitstellen können, sowie die Speicherressourcen für andere Azure-Speicherdienste, z. B. Blobcontainer oder Warteschlangen.

Dieses Video ist eine Anleitung und Demo dazu, wie Azure-Dateifreigaben in fünf einfachen Schritte für Information-Worker und Apps auf sichere Weise direkt verfügbar gemacht werden können. Die folgenden Abschnitte enthalten Links und zusätzlichen Kontext zu der Dokumentation, auf die im Video verwiesen wird. Beachten Sie, dass Azure Active Directory jetzt Microsoft Entra ID ist. Weitere Informationen finden Sie unter Neuer Name für Azure AD.

Gilt für:

Dateifreigabetyp	KMU	NFS
Standard-Dateifreigaben (GPv2), LRS/ZRS
Standard-Dateifreigaben (GPv2), GRS/GZRS
Premium-Dateifreigaben (FileStorage), LRS/ZRS

Sichere Übertragung

Standardmäßig erfordern Azure-Speicherkonten eine sichere Übertragung, unabhängig davon, ob über den öffentlichen oder privaten Endpunkt auf Daten zugegriffen wird. Für Azure Files wird die erforderliche Einstellung für die sichere Übertragung für den gesamten Protokollzugriff auf die auf Azure-Dateifreigaben gespeicherten Daten erzwungen, einschließlich SMB, NFS und FileREST. Sie können die erforderliche Einstellung für die sichere Übertragung deaktivieren, um unverschlüsselten Datenverkehr zuzulassen.

Die SMB-, NFS- und FileREST-Protokolle weisen ein geringfügig anderes Verhalten im Hinblick auf die erforderliche Einstellung für die sichere Übertragung auf:

• Wenn sichere Übertragung erforderlich für ein Speicherkonto aktiviert ist, müssen alle SMB-Dateifreigaben in diesem Speicherkonto das SMB 3.x-Protokoll mit AES-128-CCM-, AES-128-GCM- oder AES-256-GCM-Verschlüsselungsalgorithmen verwenden, abhängig von der verfügbaren bzw. erforderlichen Verschlüsselungsverhandlung zwischen dem SMB-Client und Azure Files. Sie können umschalten, welche SMB-Verschlüsselungsalgorithmen über die SMB-Sicherheitseinstellungen zulässig sind. Durch Deaktivieren der Einstellung Sichere Übertragung erforderlich werden SMB 2.1- und SMB 3.x-Einbindungen ohne Verschlüsselung ermöglicht.

• NFS Azure-Dateifreigaben verwenden das AZNFS-Hilfsprogrammpaket, um verschlüsselte Bereitstellungen zu vereinfachen, indem Stunnel (ein Open-Source-TLS-Wrapper) auf dem Client installiert und eingerichtet wird. Siehe Verschlüsselung im Transit für NFS Azure-Dateifreigaben.

• Wenn eine sichere Übertragung erforderlich ist, kann das FileREST-Protokoll nur mit HTTPS verwendet werden.

Hinweis

Die Kommunikation zwischen einem Client und einem Azure-Speicherkonto wird mit Transport Layer Security (TLS) verschlüsselt. Azure Files basiert auf einer Windows-Implementierung von SSL, die nicht auf OpenSSL basiert und daher nicht für OpenSSL-bezogene Schwachstellen anfällig ist. Benutzer, die die Flexibilität zwischen TLS- und Nicht-TLS-Verbindungen auf demselben Speicherkonto bevorzugen, sollten die erforderliche sichere Übertragung deaktivieren.

Öffentlicher Endpunkt

Der öffentliche Endpunkt für die Azure-Dateifreigaben innerhalb eines Speicherkontos ist ein internet verfügbar gemachter Endpunkt. Der öffentliche Endpunkt ist der Standardendpunkt für ein Speicherkonto, kann jedoch bei Bedarf deaktiviert werden.

Die Protokolle SMB, NFS und FileREST können alle den öffentlichen Endpunkt verwenden. Für den Zugriff gelten jedoch geringfügig unterschiedliche Regeln:

• Auf SMB-Dateifreigaben kann von überall in der Welt aus über den öffentlichen Endpunkt des Speicherkontos mit SMB 3.x mit Verschlüsselung zugegriffen werden. Dies bedeutet, dass authentifizierte Anforderungen, z. B. Anforderungen, die von der Anmeldeidentität eines Benutzers autorisiert wurden, sicher von innerhalb oder außerhalb der Azure-Region stammen können. Wenn SMB 2.1 oder SMB 3.x ohne Verschlüsselung erwünscht ist, müssen zwei Bedingungen erfüllt sein:

  1. Die erforderliche Einstellung für die sichere Übertragung des Speicherkontos muss deaktiviert werden.
  2. Die Anforderung muss aus der Azure-Region stammen. Wie bereits erwähnt, sind verschlüsselte SMB-Anforderungen von überall, innerhalb oder außerhalb der Azure-Region zulässig.

• Auf NFS-Dateifreigaben wird über den öffentlichen Endpunkt des Speicherkontos zugegriffen, wenn (und nur, wenn) der dieser Endpunkt mithilfe von Dienstendpunkten auf bestimmte virtuelle Netzwerke eingeschränkt wird. Weitere Informationen zu Dienstendpunkten finden Sie unter den Einstellungen für die Firewall für öffentliche Endpunkte.

• Auf FileREST kann über den öffentlichen Endpunkt zugegriffen werden. Wenn eine sichere Übertragung erforderlich ist, werden nur HTTPS-Anforderungen akzeptiert. Wenn die sichere Übertragung deaktiviert ist, werden HTTP-Anforderungen unabhängig vom Ursprung vom öffentlichen Endpunkt akzeptiert.

Firewall-Einstellungen für öffentliche Endpunkte

Die Firewall des Speicherkontos beschränkt den Zugriff auf den öffentlichen Endpunkt für ein Speicherkonto. Mithilfe der Firewall des Speicherkontos können Sie den Zugriff auf bestimmte IP-Adressen/IP-Adressbereiche, bestimmte virtuelle Netzwerke einschränken oder den öffentlichen Endpunkt vollständig deaktivieren.

Wenn Sie den Datenverkehr des öffentlichen Endpunkts auf ein oder mehrere virtuelle Netzwerke beschränken, verwenden Sie eine Funktion des virtuellen Netzwerks, das als Dienstendpunkte bezeichnet wird. Anforderungen, die an den Dienstendpunkt von Azure Files weitergeleitet werden, werden weiterhin zur öffentlichen IP-Adresse des Speicherkontos geleitet. Die Netzwerkschicht überprüft die Anforderung jedoch zusätzlich, um zu überprüfen, ob sie von einem autorisierten virtuellen Netzwerk stammt. Die SMB-, NFS- und FileREST-Protokolle unterstützen alle Dienstendpunkte. Im Gegensatz zu SMB und FileREST kann auf NFS-Dateifreigaben jedoch nur mithilfe eines Dienstendpunkts mit dem öffentlichen Endpunkt zugegriffen werden.

Weitere Informationen zum Konfigurieren der Speicherkontofirewall finden Sie unter Konfigurieren von Azure Storage Firewalls und virtuellen Netzwerken.

Routing des öffentlichen Endpunktnetzwerks

Azure Files unterstützt mehrere Netzwerkroutingoptionen. Die Standardoption, das Microsoft-Routing, kann bei allen Azure Files-Konfigurationen verwendet werden. Die Internetroutingoption unterstützt keine AD-Domänenbeitrittsszenarien oder Azure File Sync.

Private Endpunkte

Zusätzlich zum standardmäßigen öffentlichen Endpunkt für ein Speicherkonto bietet Azure Files die Möglichkeit, einen oder mehrere private Endpunkte zu haben. Ein privater Endpunkt ist ein Endpunkt, auf den nur innerhalb eines virtuellen Azure-Netzwerks zugegriffen werden kann. Wenn Sie einen privaten Endpunkt für Ihr Speicherkonto erstellen, erhält Ihr Speicherkonto eine private IP-Adresse aus dem Adressraum Ihres virtuellen Netzwerks, ähnlich wie ein lokaler Dateiserver oder NAS-Gerät eine IP-Adresse innerhalb des dedizierten Adressraums Ihres lokalen Netzwerks empfängt.

Ein privater Endpunkt ist einem bestimmten Subnetz des virtuellen Azure-Netzwerks zugeordnet. Ein Speicherkonto verfügt möglicherweise über private Endpunkte in mehr als einem virtuellen Netzwerk.

Die Verwendung privater Endpunkte mit Azure Files ermöglicht Folgendes:

• Herstellen einer sicheren Verbindung mit Ihren Azure-Dateifreigaben aus lokalen Netzwerken über eine VPN- oder ExpressRoute-Verbindung mit privatem Peering
• Schützen Ihrer Azure-Dateifreigaben, indem Sie die Speicherkontofirewall so konfigurieren, dass alle Verbindungen am öffentlichen Endpunkt blockiert werden. Standardmäßig blockiert das Erstellen eines privaten Endpunkts keine Verbindungen mit dem öffentlichen Endpunkt.
• Erhöhen der Sicherheit für das virtuelle Netzwerk durch die Möglichkeit zum Blockieren der Exfiltration von Daten aus dem virtuellen Netzwerk (und Peeringgrenzen)

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

Tunneln von Datenverkehr über ein virtuelles privates Netzwerk oder über ExpressRoute

Um private Endpunkte für den Zugriff auf SMB- oder NFS-Dateifreigaben von der lokalen Bereitstellung aus zu verwenden, müssen Sie einen Netzwerktunnel zwischen Ihrem lokalen Netzwerk und Azure einrichten. Ein virtuelles Netzwerk oder VNet ähnelt einem herkömmlichen lokalen Netzwerk. Wie ein Azure-Speicherkonto oder eine Azure-VM ist ein VNet eine Azure-Ressource, die in einer Ressourcengruppe bereitgestellt wird.

Azure Files unterstützt die folgenden Mechanismen, um den Datenverkehr zwischen Ihren lokalen Arbeitsstationen und Servern sowie den SMB/NFS-Dateifreigaben in Azure zu tunneln:

• Azure VPN Gateway: Ein VPN-Gateway ist eine spezielle Art von Gateway für virtuelle Netzwerke, das verwendet wird, um verschlüsselten Datenverkehr zwischen einem virtuellen Azure-Netzwerk und einem anderen Standort (beispielsweise einer lokalen Umgebung) über das Internet zu senden. Ein Azure-VPN-Gateway ist eine Azure-Ressource, die zusammen mit einem Speicherkonto oder anderen Azure-Ressourcen in einer Ressourcengruppe bereitgestellt werden kann. VPN-Gateways machen zwei verschiedene Arten von Verbindungen verfügbar:
  • Point-to-Site(P2S)-VPN-Gatewayverbindungen , bei denen es sich um VPN-Verbindungen zwischen Azure und einem einzelnen Client handelt. Diese Lösung ist in erster Linie für Geräte nützlich, die nicht Teil des lokalen Netzwerks Ihrer Organisation sind. Ein häufiger Anwendungsfall sind Telearbeiter, die ihre Azure-Dateifreigabe von zuhause, einem Café oder Hotel aus einbinden möchten. Um eine P2S-VPN-Verbindung mit Azure Files zu verwenden, müssen Sie eine P2S-VPN-Verbindung für jeden Client konfigurieren, der eine Verbindung herstellen möchte. Siehe Konfigurieren eines Point-to-Site-VPN (P2S) unter Windows für die Verwendung mit Azure Files und Konfigurieren eines Point-to-Site-VPN (P2S) unter Linux für die Verwendung mit Azure Files.
  • Standort-zu-Standort-VPN (S2S), bei dem es sich um VPN-Verbindungen zwischen Azure und dem Netzwerk Ihrer Organisation handelt. Mit einer S2S-VPN-Verbindung können Sie eine VPN-Verbindung einmal für einen VPN-Server oder ein Gerät konfigurieren, der im Netzwerk Ihrer Organisation gehostet wird, anstatt eine Verbindung für jedes Clientgerät zu konfigurieren, das auf Ihre Azure-Dateifreigabe zugreifen muss. Siehe Konfigurieren eines Site-to-Site(S2S)-VPN für die Verwendung mit Azure Files.
• ExpressRoute, mit dem Sie eine definierte Route zwischen Azure und Ihrem lokalen Netzwerk erstellen können, die das Internet nicht durchläuft. Da ExpressRoute einen dedizierten Pfad zwischen Ihrem lokalen Rechenzentrum und Azure bereitstellt, kann ExpressRoute nützlich sein, wenn die Netzwerkleistung berücksichtigt wird. ExpressRoute ist auch dann eine gute Option, wenn die Richtlinie Ihrer Organisation oder gesetzliche Vorschriften einen deterministischen Pfad zu den Ressourcen in der Cloud erfordern.

Hinweis

Obwohl wir empfehlen, private Endpunkte zu verwenden, um die Erweiterung Ihres lokalen Netzwerks in Azure zu unterstützen, ist es technisch möglich, über die VPN-Verbindung an den öffentlichen Endpunkt weiterzuleiten. Dies erfordert jedoch eine harte Codierung der IP-Adresse für den öffentlichen Endpunkt für den Azure-Speichercluster, der Ihr Speicherkonto bedient. Da Speicherkonten jederzeit zwischen Speicherclustern verschoben werden und neue Cluster häufig hinzugefügt und entfernt werden, erfordert dies regelmäßig eine feste Codierung aller möglichen Azure-Speicher-IP-Adressen in Ihre Routingregeln.

DNS-Konfiguration

Wenn Sie einen privaten Endpunkt erstellen, wird standardmäßig auch eine private DNS-Zone erstellt (oder aktualisiert), die der privatelink Unterdomäne entspricht. Streng genommen ist das Erstellen einer privaten DNS-Zone nicht erforderlich, um einen privaten Endpunkt für Ihr Speicherkonto zu verwenden. Es wird jedoch allgemein dringend empfohlen und ist explizit erforderlich, wenn Sie Ihre Azure-Dateifreigabe mit einen Active Directory-Benutzerprinzipal einbinden oder über die FileREST-API darauf zugreifen.

Hinweis

In diesem Artikel wird das Speicherkonto-DNS-Suffix für die öffentlichen Azure-Regionen (core.windows.net) verwendet. Dieser Kommentar gilt auch für Azure Sovereign-Clouds wie die Azure US Government-Cloud und die Von 21Vianet-Cloud betriebene Microsoft Azure – ersetzen Sie einfach die entsprechenden Suffixe für Ihre Umgebung.

In Ihrer privaten DNS-Zone erstellen wir einen A-Eintrag für storageaccount.privatelink.file.core.windows.net und einen CNAME-Eintrag für den regulären Namen des Speicherkontos, der dem Muster storageaccount.file.core.windows.net folgt. Da Ihre private Azure-DNS-Zone mit dem virtuellen Netzwerk verbunden ist, das den privaten Endpunkt enthält, können Sie die DNS-Konfiguration beobachten, indem Sie das Resolve-DnsName Cmdlet von PowerShell in einer Azure-VM aufrufen (alternativ nslookup in Windows und Linux):

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

In diesem Beispiel wird das Speicherkonto storageaccount.file.core.windows.net der privaten IP-Adresse des privaten Endpunkts zugeordnet, die 192.168.0.4 lautet.

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

Wenn Sie denselben Befehl lokal ausführen, wird angezeigt, dass derselbe Speicherkontoname stattdessen in die öffentliche IP-Adresse des Speicherkontos aufgelöst wird. Ein Beispiel ist storageaccount.file.core.windows.net, ein CNAME-Eintrag für storageaccount.privatelink.file.core.windows.net, der wiederum ein CNAME-Eintrag für den Azure-Speichercluster ist, welcher das Speicherkonto beherbergt.

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

Dies spiegelt die Tatsache wider, dass das Speicherkonto sowohl den öffentlichen Endpunkt als auch einen oder mehrere private Endpunkte verfügbar machen kann. Um sicherzustellen, dass der Name des Speicherkontos in die private IP-Adresse des privaten Endpunkts aufgelöst wird, müssen Sie die Konfiguration auf Ihren lokalen DNS-Servern ändern. Hierzu gibt es verschiedene Möglichkeiten:

• Ändern Sie die Hosts-Datei auf Ihren Clients, um storageaccount.file.core.windows.net auf die private IP-Adresse des gewünschten privaten Endpunkts zu verweisen. Hiervon wird in Produktionsumgebungen dringend abgeraten, weil Sie diese Änderungen bei jedem Client vornehmen müssen, von dem Ihre Azure-Dateifreigaben eingebunden werden sollen, und weil Änderungen am Speicherkonto oder am privaten Endpunkt nicht automatisch verarbeitet werden.
• Erstellen eines A-Eintrags für storageaccount.file.core.windows.net auf Ihren lokalen DNS-Servern. Dies hat den Vorteil, dass Clients in Ihrer lokalen Umgebung das Speicherkonto automatisch auflösen können, ohne jeden Client konfigurieren zu müssen. Diese Lösung ist jedoch ähnlich anfällig wie das Ändern der Hostdatei, weil Änderungen nicht berücksichtigt werden. Für einige Umgebungen ist diese Lösung trotz ihrer Fehleranfälligkeit möglicherweise die beste Wahl.
• Leiten Sie die core.windows.net Zone von Ihren lokalen DNS-Servern an Ihre private Azure-DNS-Zone weiter. Der private Azure-DNS-Host ist über eine spezielle IP-Adresse (168.63.129.16) erreichbar, auf die nur innerhalb von virtuellen Netzwerken zugegriffen werden kann, die mit der privaten Azure-DNS-Zone verknüpft sind. Um diese Einschränkung zu umgehen, können Sie zusätzliche DNS-Server innerhalb Ihres virtuellen Netzwerks ausführen, die an die private Azure-DNS-Zone weitergeleitet core.windows.net werden. Um diese Einrichtung zu vereinfachen, haben wir PowerShell-Cmdlets bereitgestellt, die DNS-Server automatisch in Ihrem virtuellen Azure-Netzwerk bereitstellen und wie gewünscht konfigurieren. Informationen zum Einrichten der DNS-Weiterleitung finden Sie unter Konfigurieren von DNS mit Azure Files.

SMB über QUIC

Windows Server 2022 Azure Edition unterstützt ein neues Transportprotokoll namens QUIC für den SMB-Server, der von der Dateiserverrolle bereitgestellt wird. QUIC ist ein Ersatz für TCP, der auf UDP basiert und zahlreiche Vorteile gegenüber TCP bietet und gleichzeitig einen zuverlässigen Transportmechanismus bereitstellt. Ein wichtiger Vorteil für das SMB-Protokoll besteht darin, dass anstelle von Port 445 der gesamte Transport über Port 443 erfolgt, was weit offen für die Unterstützung von HTTPS ist. Dies bedeutet effektiv, dass SMB über QUIC ein „SMB-VPN“ für die Dateifreigabe über das öffentliche Internet bietet. Windows 11 wird mit einem SMB über QUIC-fähigen Client ausgeliefert.

Derzeit unterstützt Azure Files SMB über QUIC nicht direkt. Sie können jedoch Zugriff auf Azure-Dateifreigaben über Azure File Sync unter Windows Server erhalten, wie im folgenden Diagramm dargestellt. Dies bietet Ihnen auch die Möglichkeit, Azure File Sync-Caches sowohl lokal als auch in verschiedenen Azure-Rechenzentren bereitzustellen, um lokale Caches für eine verteilte Belegschaft bereitzustellen. Weitere Informationen zu dieser Option finden Sie unter Bereitstellen von Azure File Sync und SMB over QUIC.

Siehe auch

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