Azure Files – Überlegungen zum Netzwerkbetrieb

  • Artikel

Sie können auf Ihre Azure-Dateifreigaben zugreifen – entweder über den öffentlichen über das Internet zugänglichen Endpunkt, über einen oder mehrere private Endpunkte in Ihrem Netzwerk oder aber, indem Sie Ihre Azure-Dateifreigabe mit Azure-Dateisynchronisierung lokal zwischenspeichern (nur SMB-Dateifreigaben). In diesem Artikel wird erläutert, wie Sie Azure Files für den direkten Zugriff über öffentliche und/oder private Endpunkte konfigurieren können. Informationen zum Zwischenspeichern Ihrer lokalen Azure-Dateifreigabe mit Azure-Dateisynchronisierung finden Sie in der Einführung in Azure-Dateisynchronisierung.

Wir empfehlen Ihnen, vor diesem Leitfaden den Artikel Planung für eine Azure Files-Bereitstellung zu lesen.

Der direkte Zugriff auf eine Azure-Dateifreigabe erfordert oft 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 Praxis geht auf ältere Sicherheitsempfehlungen im Zusammenhang mit veralteten Versionen des SMB-Protokolls zurück, die nicht internetsicher waren. Auch wenn 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 daher nur über eingeschränkte Netzwerke zugänglich. Die Verwendung einer NFS-Dateifreigabe erfordert immer eine Ebene von Netzwerkkonfiguration.

Öffentliche und private Endpunkte für Azure Files werden im Verwaltungsobjekt der obersten Ebene für Azure Files, dem Azure-Speicherkonto, konfiguriert. Ein Speicherkonto ist ein Verwaltungskonstrukt, das einen gemeinsam genutzten Pool mit Speicherplatz darstellt, in dem Sie mehrere Azure-Dateifreigaben und die Speicherressourcen für andere Azure-Speicherdienste wie Blobcontainer oder Warteschlangen bereitstellen können.

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. In den folgenden Abschnitten finden Sie Links und zusätzlichen Kontext für die 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 SMB NFS
Standard-Dateifreigaben (GPv2), LRS/ZRS Ja Nein
Standard-Dateifreigaben (GPv2), GRS/GZRS Ja Nein
Premium-Dateifreigaben (FileStorage), LRS/ZRS Ja Ja

Sichere Übertragung

Standardmäßig erfordern Azure-Speicherkonten eine sichere Übertragung – unabhängig davon, ob auf Daten über den öffentlichen oder privaten Endpunkt zugegriffen wird. Bei Azure Files wird die Einstellung Vorschreiben einer sicheren Übertragung für alle Protokollzugriffe auf die auf Azure-Dateifreigaben gespeicherten Daten erzwungen, einschließlich SMB, NFS und FileREST. Sie können die Einstellung Vorschreiben einer sicheren Übertragung deaktivieren, um unverschlüsselten Datenverkehr zuzulassen. Im Azure-Portal wird diese Einstellung möglicherweise auch als Sichere Übertragung für REST-API-Vorgänge erforderlich bezeichnet.

Bei den SMB-, NFS- und FileREST-Protokollen gibt es ein etwas anderes Verhalten in Bezug auf die Einstellung Vorschreiben einer sicheren Übertragung:

  • Wenn die Einstellung Vorschreiben einer sicheren Übertragung bei einem Speicherkonto aktiviert wurde, benötigen alle SMB-Dateifreigaben in diesem Konto das SMB 3.x-Protokoll mit AES-128-CCM-, AES-128-GCM- oder AES-256-GCM-Verschlüsselungsalgorithmen – je nach der verfügbaren/erforderlichen Verschlüsselungsaushandlung zwischen dem SMB-Client und Azure Files. Über die SMB-Sicherheitseinstellungen können Sie umschalten, welche SMB-Verschlüsselungsalgorithmen zulässig sind. Das Deaktivieren der Einstellung Vorschreiben einer sicheren Übertragung ermöglicht SMB 2.1- und SMB 3.x-Einbindungen ohne Verschlüsselung.

  • Weil NFS-Dateifreigaben keinen Verschlüsselungsmechanismus unterstützen, müssen Sie Vorschreiben einer sicheren Übertragung für das Speicherkonto deaktivieren, um das NFS-Protokoll für den Zugriff auf eine Azure-Dateifreigabe verwenden zu können.

  • Wenn sichere Übertragung erforderlich ist, kann das FileREST-Protokoll nur mit HTTPS verwendet werden. FileREST wird zurzeit nur bei SMB-Dateifreigaben unterstützt.

Hinweis

Die Kommunikation zwischen einem Client und einem Azure Storage-Konto wird mithilfe der 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 Sicherheitsrisiken verfügbar gemacht wird.

Öffentlicher Endpunkt

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

Die SMB-, NFS- und FileREST-Protokolle können alle den öffentlichen Endpunkt verwenden. Bei jedem Protokoll gibt es jedoch etwas unterschiedliche Regeln für den Zugriff:

  • 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 durch die Anmeldeidentität eines Benutzers autorisiert wurden) auf sichere Weise verwendet werden können – ganz gleich, ob ihr Ursprung innerhalb oder außerhalb der Azure-Region liegt. Wenn SMB 2.1 oder SMB 3.x ohne Verschlüsselung gewünscht wird, müssen zwei Bedingungen erfüllt werden:

    1. Die Einstellung Vorschreiben einer sicheren Übertragung des Speicherkontos muss deaktiviert werden.
    2. Der Ursprung der Anforderung muss innerhalb der Azure-Region liegen. Wie bereits erwähnt, sind verschlüsselte SMB-Anforderungen von überall aus 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 Einstellungen für die Firewall für öffentliche Endpunkte.

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

Firewalleinstellungen für den öffentlichen Endpunkt

Die Firewall des Speicherkontos schränkt den Zugriff auf den öffentlichen Endpunkt für ein Speicherkonto ein. Mithilfe der Firewall des Speicherkontos können Sie den Zugriff auf bestimmte IP-Adressen/IP-Adressbereiche und 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 einschränken, verwenden Sie eine Funktion des virtuellen Netzwerks, die sogenannten Dienstendpunkte. An den Dienstendpunkt von Azure Files geleitete Anforderungen werden weiterhin zur öffentlichen IP-Adresse des Speicherkontos geleitet. Die Netzwerkebene führt jedoch eine zusätzliche Überprüfung der Anforderung durch, um zu überprüfen, ob sie aus einem autorisierten virtuellen Netzwerk stammt. Sowohl das SMB- als auch das NFS- und FileREST-Protokoll unterstützen 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.

Netzwerkrouting für öffentliche Endpunkte

Azure Files unterstützt mehrere Netzwerkroutingoptionen. Die Standardoption, das Microsoft-Routing, kann bei allen Azure Files-Konfigurationen verwendet werden. Die Internetroutingoption unterstützt keine Szenarien mit AD-Domänenbeitritt oder Azure-Dateisynchronisierung.

Private Endpunkte

Neben dem standardmäßigen öffentlichen Endpunkt für ein Speicherkonto ermöglicht Azure Files die Verwendung privater Endpunkte. 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. Dies ist vergleichbar mit einem lokalen Dateiserver oder NAS-Gerät, der bzw. das eine IP-Adresse aus dem dedizierten Adressraum Ihres lokalen Netzwerks erhält.

Ein privater Endpunkt ist einem bestimmten Subnetz des virtuellen Azure-Netzwerks zugeordnet. Ein Speicherkonto kann über private Endpunkte in mehreren virtuellen Netzwerken verfügen.

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. Durch die Erstellung eines privaten Endpunkts werden Verbindungen mit dem öffentlichen Endpunkt nicht standardmäßig blockiert.
  • 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 von privaten Endpunkten 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 lokal verwenden zu können, müssen Sie einen Netzwerktunnel zwischen Ihrem lokalen Netzwerk und Azure einrichten. Ein virtuelles Netzwerk (oder VNet) ist ähnlich wie ein herkömmliches lokales Netzwerk. Ähnlich wie ein Azure-Speicherkonto oder eine Azure-VM ist ein VNET eine Azure-Ressource, die in einer Ressourcengruppe bereitgestellt wird.

Azure Files unterstützt folgende Mechanismen, um Datenverkehr zwischen Ihren lokalen Arbeitsstationen und Servern und 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 in einer Ressourcengruppe zusammen mit einem Speicherkonto oder anderen Azure-Ressourcen bereitgestellt werden kann. VPN-Gateways machen zwei Arten von Verbindungen verfügbar:
  • ExpressRoute ermöglicht die Erstellung einer definierten Route zwischen Azure und Ihrem lokalen Netzwerk, die nicht über das Internet läuft. Da ExpressRoute einen dedizierten Pfad zwischen Ihrem lokalen Rechenzentrum und Azure bereitstellt, kann dieser Dienst sehr nützlich sein, wenn die Netzwerkleistung ein wichtiger Aspekt ist. 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 eine Erweiterung Ihres lokalen Netzwerks in Azure zu unterstützen, ist es technisch möglich, den öffentlichen Endpunkt über die VPN-Verbindung an den öffentlichen Endpunkt weiterzuleiten. Dies erfordert jedoch eine Hartcodierung der IP-Adresse für den öffentlichen Endpunkt des Azure-Speicherclusters, der Ihrem Speicherkonto dient. Weil Speicherkonten jederzeit zwischen Speicherclustern verschoben werden können und neue Cluster häufig hinzugefügt und entfernt werden, erfordert dies regelmäßig eine Hartcodierung aller möglichen IP-Adressen für Azure-Speicher in Ihre Routingregeln.

DNS-Konfiguration

Wenn Sie einen privaten Endpunkt erstellen, wird standardmäßig auch eine private DNS-Zone erstellt, die der Unterdomäne privatelink entspricht, oder es wird eine vorhandene private DNS-Zone entsprechend aktualisiert. Streng genommen ist das Erstellen einer privaten DNS-Zone nicht erforderlich, damit Sie einen privaten Endpunkt für Ihr Speicherkonto verwenden können. 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 Microsoft Azure operated by 21Vianet Cloud – ersetzen Sie einfach die entsprechenden Suffixe für Ihre Umgebung.

In Ihrer privaten DNS-Zone werden ein A-Eintrag für storageaccount.privatelink.file.core.windows.net und ein CNAME-Eintrag für den regulären Namen des Speicherkontos im Format storageaccount.file.core.windows.net erstellt. Weil Ihre private Azure-DNS-Zone mit dem virtuellen Netzwerk verbunden ist, das den privaten Endpunkt enthält, können Sie sich die DNS-Konfiguration ansehen, indem Sie das Cmdlet Resolve-DnsName über PowerShell in einer Azure VM (oder nslookup unter Windows und Linux) aufrufen:

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

In diesem Beispiel wird das Speicherkonto storageaccount.file.core.windows.net in die private IP-Adresse des privaten Endpunkts (192.168.0.4) aufgelöst.

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. Beispielsweise 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, der das Speicherkonto hosten soll:

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 zeigt, dass das Speicherkonto sowohl den öffentlichen Endpunkt als auch einen oder mehrere private Endpunkte verfügbar machen kann. Um sicherzustellen, dass der Speicherkontoname 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 der Datei hosts auf Ihren Clients, damit storageaccount.file.core.windows.net in die private IP-Adresse des gewünschten privaten Endpunkts aufgelöst wird. 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 und Sie nicht jeden einzelnen Client konfigurieren müssen. Diese Lösung ist jedoch ähnlich fehleranfällig wie das Ändern der Hosts-Datei, weil Änderungen nicht angezeigt werden. Für einige Umgebungen ist diese Lösung trotz ihrer Fehleranfälligkeit möglicherweise die beste Wahl.
  • Weiterleiten der Zone core.windows.net von Ihren lokalen DNS-Servern an Ihre private Azure-DNS-Zone: 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. Wenn Sie diese Einschränkung umgehen möchten, können Sie zusätzliche DNS-Server in Ihrem virtuellen Netzwerk ausführen, die core.windows.net an die private Azure-DNS-Zone weiterleiten. Zur Vereinfachung dieser Einrichtung stehen PowerShell-Cmdlets zur Verfügung, die automatisch DNS-Server 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 das neue Transportprotokoll 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 über TCP bereitstellt, während ein zuverlässiger Transportmechanismus weiterhin bereitgestellt wird. Ein wichtiger Vorteil beim SMB-Protokoll ist, statt den Port 445 zu verwenden, wird der gesamte Transport über Port 443 durchgeführt, der zur Unterstützung von HTTPS weit geöffnet ist. Dies bedeutet effektiv, dass SMB über QUIC ein „SMB-VPN“ für die Dateifreigabe über das öffentliche Internet bietet. Im Lieferumfang von Windows 11 ist ein SMB über QUIC-fähiger Client enthalten.

Zu diesem Zeitpunkt unterstützt Azure Files SMB über QUIC nicht direkt. Sie können jedoch auf Azure-Dateifreigaben über Azure-Dateisynchronisierung auf Windows Server wie im folgenden Diagramm zugreifen. Das bietet Ihnen auch die Möglichkeit, Azure-Dateisynchronisierungs-Caches sowohl lokal als auch in verschiedenen Azure-Rechenzentren zu haben, um lokale Caches für eine verteilte Mitarbeiter bereitzustellen. Weitere Informationen zu dieser Option finden Sie unter Azure-Dateisynchronisierung bereitstellen und SMB über QUIC.

Diagramm zum Erstellen eines einfachen Caches Ihrer Azure-Dateifreigaben auf einer Windows Server 2022 Azure Edition VM mithilfe der Azure-Dateisynchronisierung

Weitere Informationen