Ü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.

Lesen Sie vor der Lektüre dieses Leitfadens den Artikel Planen einer Azure Files-Bereitstellung.

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.

Du konfigurierst öffentliche und private Endpunkte für Azure Files auf dem obersten Management-Objekt für Azure Files: dem 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:

Verschlüsselung im Transit für KMU

Die Einstellung "Require Encryption in Transit for SMB" steuert, ob Verschlüsselung für den SMB-Zugriff 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.

Verschlüsselung im Transit für NFS

Die Einstellung "Require Encryption in Transit for NFS " steuert, ob 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.

Verschlüsselung im Transit für FileREST

Die Einstellung Secure Transfer required gilt für REST/HTTPS-Verkehr. 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. Man kann den Zugriff auf bestimmte IP-Adressen oder IP-Adressbereiche, auf bestimmte virtuelle Netzwerke beschränken oder den öffentlichen Endpunkt komplett deaktivieren.

Wenn Sie den öffentlichen Endpunkt auf ein oder mehrere Netzwerke beschränken, nutzen Sie eine Funktion des virtuellen Netzwerks, die Service Endpoints genannt wird. Anfragen, die an den Service-Endpunkt von Azure Files gerichtet sind, gehen weiterhin an die öffentliche IP-Adresse des Speicherkontos. Allerdings führt die Netzwerkschicht eine zusätzliche Überprüfung der Anfrage durch, um zu bestätigen, dass sie von einem autorisierten virtuellen Netzwerk stammt. Die SMB-, NFS- und FileREST-Protokolle unterstützen alle Dienstendpunkte. Im Gegensatz zu SMB und FileREST kann jedoch auf NFS-Dateifreigaben nur über den öffentlichen Endpunkt mithilfe eines Dienstendpunkts zugegriffen werden.

Azure-Portalzugriff und die Speicherkontofirewall

Wenn Sie über das Azure-Portal auf Azure-Dateifreigaben zugreifen, treten zwei separate Anforderungen auf:

1. Eine Anforderung von Ihrem Browser an die Azure-Portal-UI (https://portal.azure.com).
2. Eine Anforderung von Ihrem Browser direkt an den Endpunkt der Datenebene von Azure Files (z. B. https://<storage-account-name>.file.core.windows.net), in der Regel mithilfe eines SAS-Tokens, das für die Portalerfahrung ausgestellt wurde.

Die Speicherkontofirewall wertet nur die direkte Anforderung an den Azure Files-Datenebenenendpunkt aus, nicht die Anforderung an portal.azure.com. Selbst wenn Sie problemlos auf das Azure-Portal zugreifen können, kann es passieren, dass Sie beim Durchsuchen der Dateifreigabedaten den Fehler 403 (Unzulässig) erhalten, wenn die ausgehende öffentliche IP-Adresse in der Anfrage vom Browser zum Speicher von der Firewall nicht zugelassen wird. Diese Einschränkung gilt nur für FileREST/HTTPS-Verkehr, nicht für SMB oder NFS. Weitere Informationen finden Sie unter Zugriff auf Dateidaten autorisieren im Azure-Portal.

Routing des öffentlichen Endpunktnetzwerks

Azure Files unterstützt zwei Netzwerk-Routing-Optionen:

• 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 funktioniert mit allen Azure Files-Konfigurationen, einschließlich Active Directory (AD)-Domänenjoin-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.

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 ähnelt einem traditionellen lokalen Netzwerk. Wie ein Azure-Speicherkonto oder eine Azure-VM ist ein virtuelles Netzwerk eine Azure-Ressource, die Sie in einer Ressourcengruppe bereitstellen.

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

Point-to-Site-VPN

Azure VPN Gateway unterstützt Punkt-zu-Standort-VPN-Verbindungen, also VPN-Verbindungen zwischen Azure und einem einzelnen Client. 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 Point-to-Site-VPN-Verbindung mit Azure Files zu nutzen, müssen Sie für jeden Client, der sich verbinden möchte, eine Point-to-Site-VPN-Verbindung konfigurieren. Informationen hierzu finden Sie unter Konfigurieren eines Point-to-Site-VPN unter Windows zur Verwendung mit Azure Files und Konfigurieren eines Point-to-Site-VPN unter Linux zur Verwendung mit Azure Files.

Standort-zu-Standort-VPN-Verbindung

Azure VPN Gateway unterstützt außerdem Site-to-Site-VPN-Verbindungen, also VPN-Verbindungen zwischen Azure und dem Netzwerk Ihrer Organisation. Eine Site-to-Site-VPN-Verbindung ermöglicht es Ihnen, eine VPN-Verbindung einmal für einen VPN-Server oder ein Gerät zu konfigurieren, das im Netzwerk Ihrer Organisation gehostet wird, anstatt für jedes Client-Gerät, das auf Ihre Azure-Dateifreigabe zugreifen muss, eine Verbindung zu konfigurieren. Siehe Konfigurieren eines Site-to-Site-VPNs zur Verwendung mit Azure Files.

ExpressRoute

ExpressRoute ermöglicht es Ihnen, eine definierte Route zwischen Azure und Ihrem lokalen Netzwerk zu erstellen, die nicht über das Internet führt. 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, erstellt oder aktualisiert Azure auch eine private DNS-Zone, die der privatelink Subdomain 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 sehr empfohlen und ist ausdrücklich erforderlich, wenn du deine Azure-Dateifreigabe mit einem Active Directory-Benutzerprinzip mountest oder über die FileREST-API darauf zugreifst.

In Ihrer privaten DNS-Zone erstellt Azure 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.netfolgt. 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     storageaccount.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

Diese Konfiguration spiegelt wider, dass das Speicherkonto sowohl den öffentlichen Endpunkt als auch einen oder mehrere private Endpunkte offenlegen 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. Dafür gibt es mehrere 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 innerhalb Ihres virtuellen Netzwerks betreiben, die auf die private DNS-Zone von Azure weiterleitencore.windows.net. Um diese Einrichtung zu vereinfachen, stellt Microsoft PowerShell-CMDLETS bereit, die DNS-Server automatisch in Ihrem virtuellen Azure-Netzwerk bereitstellen und nach Belieben 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 Transportprotokoll namens QUIC für den SMB-Server, der von der File Server-Rolle bereitgestellt wird. QUIC ist ein Ersatz für TCP, der auf UDP basiert und zahlreiche Vorteile gegenüber TCP bietet und dennoch einen zuverlässigen Transportmechanismus bietet. 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. Diese Konfiguration bedeutet im Wesentlichen, 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 nicht über QUIC. Allerdings können Sie über Azure-Dateisynchronisierung, das auf Windows Server läuft, wie im folgenden Diagramm gezeigt, auf Azure-Dateifreigaben zugreifen. Diese Konfiguration bietet Ihnen außerdem die Möglichkeit, Azure-Dateisynchronisierung sowohl lokal als auch in verschiedenen Azure-Rechenzentren zu cachen, um lokale Caches für eine verteilte Belegschaft bereitzustellen. Um mehr über diese Option zu erfahren, siehe die 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