Überlegungen zu Azure Files Netzwerken

✔️ Gilt für: Alle Azure Dateifreigaben

Sie können auf Ihre Azure Dateifreigaben über den öffentlichen Endpunkt zugreifen, auf den zugegriffen werden kann, über einen oder mehrere private Endpunkte in Ihrem Netzwerk(en) oder indem Sie Ihre Azure Dateifreigabe lokal mit Azure-Dateisynchronisierung (nur SMB-Dateifreigaben) zwischenspeichern. Dieser Artikel befasst sich mit der Konfiguration Azure Files für den direkten Zugriff auf öffentliche und/oder private Endpunkte. Informationen dazu, wie Sie Ihre Azure-Dateifreigabe lokal mit Azure-Dateisynchronisierung zwischenspeichern, finden Sie unter Einführung in Azure-Dateisynchronisierung.

Es wird empfohlen, Planning 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-Speicherdienstleistungen, z. B. Blobcontainer oder Warteschlangen.

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 Verschlüsselung während der Übertragung auf Protokollebene gesteuert:

• SMB: Die Einstellung Verschlüsselung während der Übertragung für SMB erzwingen steuert, ob für den SMB-Zugriff Verschlüsselung erforderlich ist. Bei neuen Speicherkonten, die mithilfe des Azure Portals erstellt wurden, ist diese Einstellung standardmäßig aktiviert. Speicherkonten, die mit Azure PowerShell, Azure CLI oder der FileREST-API erstellt wurden, legen diesen Wert als Not selected fest, um die Abwärtskompatibilität sicherzustellen. Bei vorhandenen Speicherkonten steuert die erforderliche Einstellung für die sichere Übertragung weiterhin das SMB-Verschlüsselungsverhalten, bis Sie die SMB-Einstellung pro Protokoll explizit konfigurieren. Wenn die SMB-Verschlüsselung während der Übertragung erforderlich ist, benötigen alle SMB-Dateifreigaben in diesem Speicherkonto das SMB 3.x-Protokoll mit AES-128-CCM, AES-128-GCM oder AES-256-GCM-Verschlüsselungsalgorithmen. Sie können umschalten, welche Algorithmen über die SMB-Sicherheitseinstellungen zulässig sind. Durch Deaktivieren dieser Einstellung werden SMB 2.1- und SMB 3.x-Einbindungen ohne Verschlüsselung möglich.

• NFS: Die "Require Encryption in Transit" für NFS-Einstellung steuert, ob die Verschlüsselung für den NFS-Zugriff erforderlich ist. 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. Bei neuen Speicherkonten, die mithilfe des Azure Portals erstellt wurden, ist diese Einstellung standardmäßig aktiviert. Speicherkonten, die mit Azure PowerShell, Azure CLI oder der FileREST-API erstellt wurden, legen diesen Wert als Not selected fest, um die Abwärtskompatibilität sicherzustellen. Bei vorhandenen Speicherkonten steuert die erforderliche Einstellung für die sichere Übertragung das NFS-Verschlüsselungsverhalten weiterhin, bis Sie die NFS-Einstellung pro Protokoll explizit konfigurieren.

• FileREST: Die erforderliche Einstellung für die sichere Übertragung gilt für REST/HTTPS-Datenverkehr. Wenn diese Option aktiviert ist, kann das FileREST-Protokoll nur mit HTTPS verwendet werden.

Ö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 region Azure 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 Einstellung "Verschlüsselung bei übertragung erforderlich" für SMB muss deaktiviert sein (oder für vorhandene Konten, für die diese Einstellung nicht explizit konfiguriert wurde, muss die erforderliche Einstellung für die sichere Übertragung deaktiviert werden).
  2. Die Anforderung muss aus der Azure-Region kommen. Wie bereits erwähnt, sind verschlüsselte SMB-Anforderungen von überall aus innerhalb oder außerhalb der region Azure 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 Netzwerkebene führt jedoch eine zusätzliche Überprüfung der Anforderung durch, 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 Azure-Speicherfirewalls und virtuelle Netzwerke konfigurieren.

Routing des öffentlichen Endpunktnetzwerks

Azure Files unterstützt mehrere Netzwerkroutingoptionen. Die Standardoption Microsoft Routing funktioniert mit allen Azure Files Konfigurationen. Die Internetroutingoption unterstützt keine AD-Domänenbeitrittsszenarien oder Azure-Dateisynchronisierung.

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 Azure virtuellen 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 einzelner privater Endpunkt ist einem bestimmten Azure virtuellen Netzwerk-Subnetz 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
• Sichern Sie Ihre Azure Dateifreigaben, indem Sie die Firewall des Speicherkontos 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 Configuring private 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 über die lokale Bereitstellung 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 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 ein bestimmter Typ von virtuellem Netzwerkgateway, das verwendet wird, um verschlüsselten Datenverkehr zwischen einem Azure virtuellen Netzwerk und einem alternativen Standort (z. B. lokal) ü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 (P2S) VPNs auf Windows zur Verwendung mit Azure Files und Konfigurieren eines Point-to-Site (P2S) VPNs auf Linux zur Verwendung mit Azure Files.
  • Site-to-Site (S2S) VPN, bei denen 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. Weitere Informationen finden Sie unter Einrichten einer Site-to-Site (S2S)-VPN zur Verwendung mit Azure Files.
• ExpressRoute, mit dem Sie eine definierte Route zwischen Azure und Ihrem lokalen Netzwerk erstellen können, das 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.

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.

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 Azure private DNS-Zone mit dem virtuellen Netzwerk verbunden ist, das den privaten Endpunkt enthält, können Sie die DNS-Konfiguration beobachten, indem Sie das Cmdlet Resolve-DnsName 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. 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 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 zone core.windows.net von Ihren lokalen DNS-Servern an Ihre private DNS-Zone Azure weiter. Der Azure privaten DNS-Host kann über eine spezielle IP-Adresse (168.63.129.16) erreicht werden, auf die nur in virtuellen Netzwerken zugegriffen werden kann, die mit der privaten DNS-Zone Azure verknüpft sind. Um diese Einschränkung zu umgehen, können Sie zusätzliche DNS-Server in Ihrem virtuellen Netzwerk ausführen, die core.windows.net an die private DNS-Zone Azure weiterleiten. Um diese Einrichtung zu vereinfachen, haben wir PowerShell-Cmdlets bereitgestellt, die DNS-Server in Ihrem Azure virtuellen Netzwerk automatisch bereitstellen und wie gewünscht konfigurieren. Informationen zum Einrichten der DNS-Weiterleitung finden Sie unter Configuring DNS with 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-Dateisynchronisierung erhalten, das auf Windows Server ausgeführt wird, wie im folgenden Diagramm gezeigt. Dies bietet Ihnen auch die Möglichkeit, Azure-Dateisynchronisierung 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 Deploy Azure-Dateisynchronisierung und SMB over QUIC.

Siehe auch

• übersicht über Azure Files
• Planung für die Bereitstellung von Azure Files