Freigeben über

Konnektivitäts- und Netzwerkkonzepte für Azure Database for MySQL – Flexible Server

In diesem Artikel werden die Konzepte zum Steuern der Konnektivität mit Ihrer Instanz von Azure Database for MySQL – flexibler Server vorgestellt. Sie erlernen im Detail die Netzwerkkonzepte für Azure Database for MySQL – flexibler Server, die für die Erstellung eines Servers und den sicheren Zugriff darauf in Azure erforderlich sind.

Azure Database for MySQL – flexibler Server unterstützt drei Möglichkeiten zum Konfigurieren der Konnektivität mit Ihren Servern:

Note

Nach der Bereitstellung eines Servers mit öffentlichem oder privatem Zugriff (über die VNet-Integration) können Sie den Verbindungsmodus nicht ändern. Im öffentlichen Zugriffsmodus können Sie jedoch private Endpunkte nach Bedarf aktivieren oder deaktivieren und bei Bedarf auch den öffentlichen Zugriff deaktivieren.

Auswählen einer Netzwerkoption

Wählen Sie die Methoden Öffentlicher Zugriff (zulässige IP-Adressen) und Privater Endpunkt aus, wenn Sie die folgenden Funktionen benötigen:

  • Herstellen einer Verbindung mit Azure-Ressourcen ohne Unterstützung für virtuelle Netzwerke
  • Herstellen einer Verbindung von Azure-externen Ressourcen aus, die weder ein VPN noch ExpressRoute unterstützen
  • Der flexible Server ist über einen öffentlichen Endpunkt zugänglich und kann über autorisierte Internetressourcen aufgerufen werden. Der öffentliche Zugriff kann bei Bedarf deaktiviert werden.
  • Möglichkeit zum Konfigurieren privater Endpunkte für den Zugriff auf den Server über Hosts in einem virtuellen Netzwerk (VNET)

Wählen Sie Privater Zugriff (VNet-Integration) aus, wenn Sie die folgenden Funktionen benötigen:

  • Herstellen einer Verbindung mit Ihrem flexiblen Server über Azure-Ressourcen innerhalb desselben virtuellen Netzwerks oder eines virtuellen Netzwerks mit Peering, ohne dass ein privater Endpunkt konfiguriert werden muss
  • Herstellen einer Verbindung von Azure-externen Ressourcen mit Ihrem flexiblen Server über ein VPN oder eine ExpressRoute-Verbindung
  • Kein öffentlicher Endpunkt

Die folgenden Eigenschaften gelten unabhängig davon, ob Sie den privaten oder den öffentlichen Zugriff wählen:

  • Verbindungen von zugelassenen IP-Adressen müssen bei der Instanz von Azure Database for MySQL – flexibler Server mit gültigen Anmeldeinformationen authentifiziert werden
  • Für den Netzwerkdatenverkehr ist die Verbindungsverschlüsselung verfügbar
  • Der Server verfügt über einen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN). Für die Hostnamenseigenschaft in Verbindungszeichenfolgen wird empfohlen, den FQDN anstelle einer IP-Adresse zu verwenden.
  • Über beide Optionen wird der Zugriff auf Serverebene, nicht auf Datenbank- oder auf Tabellenebene gesteuert. Der Zugriff auf Datenbanken, Tabellen und andere Objekte wird mithilfe der Rolleneigenschaften in MySQL gesteuert.

Unterstützung für benutzerdefinierten Port

Azure MySQL unterstützt jetzt die Möglichkeit, während der Servererstellung einen benutzerdefinierten Port zwischen 250001 und 26000 anzugeben, um eine Verbindung mit dem Server herzustellen. Der Standardport für die Verbindung ist 3306.

  • Es wird nur ein benutzerdefinierter Port pro Server unterstützt.
  • Unterstützte Szenarien für benutzerdefinierten Port: Servererstellung, Wiederherstellung (portübergreifende Wiederherstellung unterstützt), Erstellung von Lesereplikaten, Aktivierung von Hochverfügbarkeit.
  • Aktuelle Einschränkungen:
    • Benutzerdefinierter Port kann nach der Servererstellung nicht aktualisiert werden.
    • Geowiederherstellung und Georeplikateerstellung mit benutzerdefiniertem Port werden nicht unterstützt.

Nicht unterstützte virtuelle Netzwerkszenarios

  • Öffentlicher Endpunkt (oder öffentliche IP-Adresse oder DNS): Für eine in einem virtuellen Netzwerk bereitgestellte Instanz des flexiblen Servers darf kein öffentlicher Endpunkt festgelegt sein.
  • Nachdem die Instanz des flexiblen Servers in einem virtuellen Netzwerk und einem Subnetz bereitgestellt wurde, kann sie nicht in ein anderes virtuelles Netzwerk oder Subnetz verschoben werden.
  • Nachdem der flexible Server bereitgestellt wurde, können Sie das vom flexiblen Server verwendete virtuelle Netzwerk nicht mehr in eine andere Ressourcengruppe oder ein anderes Abonnement verschieben.
  • Die Subnetzgröße (Adressräume) kann nicht erhöht werden, sobald Ressourcen im Subnetz vorhanden sind.
  • Der Umstieg vom öffentlichen auf privaten Zugriff ist nach Erstellen des Servers nicht zulässig. Es wird empfohlen, die Zeitpunktwiederherstellung zu verwenden.

Note

Wenn Sie den benutzerdefinierten DNS-Server verwenden, müssen Sie eine DNS-Weiterleitung verwenden, um den FQDN der Instanz von Azure Database for MySQL – Flexibler Server aufzulösen. Weitere Informationen finden Sie unter Namensauflösung mithilfe Ihres DNS-Servers.

Hostname

Unabhängig von Ihrer Netzwerkoption empfiehlt es sich, beim Herstellen einer Verbindung mit Azure Database for MySQL – flexibler Server den vollqualifizierten Domänennamen (FQDN) <servername>.mysql.database.azure.com in Verbindungszeichenfolgen anzugeben. Es ist nicht gewährleistet, dass die IP-Adresse des Servers statisch bleibt. Mithilfe des FQDN können Sie verhindern, dass Änderungen an der Verbindungszeichenfolge vorgenommen werden.

Ein Beispiel eines FQDN als Hostnamen ist: servername.mysql.database.azure.com. Vermeiden Sie nach Möglichkeit die Verwendung des Hostnamens „10.0.0.4“ (eine private Adresse) oder des Hostnamens „40.2.45.67“ (eine öffentliche Adresse).

Note

Wenn Ihre Azure-Datenbank für MySQL Flexible Server sowohl den öffentlichen Zugriff als auch den privaten Link aktiviert hat, werden öffentliche IPs für Ihre Instanz als Teil der Architekturänderung aktualisiert, um die Netzwerkerfahrung zu verbessern. Wenn Sie solche öffentlichen IPs in Ihrer Verbindungszeichenfolge verwendet haben, müssen Sie vor dem 9. September 2025 durch FQDN ersetzen, um Unterbrechungen in der Serververbindung zu vermeiden. (Hinweis: Private Link-IP oder VNet-Integrations-IP ist nicht betroffen). Erforderliche Aktion : Führen Sie NSLookup aus Ihrem öffentlichen Netzwerk aus, um die öffentliche IP abzurufen, die sich ändert, und Sie sollten den Verweis in der Verbindungszeichenfolge aktualisieren, um stattdessen FQDN zu verwenden.

TLS und SSL

Azure Database for MySQL – flexibler Server unterstützt das Herstellen einer Verbindung zwischen Ihren Clientanwendungen und der Instanz von Azure Database for MySQL – flexibler Server über Secure Sockets Layer (SSL) mit TLS-Verschlüsselung (Transport Layer Security). TLS ist ein Standardprotokoll der Branche, das verschlüsselte Netzwerkverbindungen zwischen dem Datenbankserver und Clientanwendungen gewährleistet, sodass Sie Konformitätsanforderungen einhalten können.

Azure Database for MySQL – flexibler Server unterstützt standardmäßig verschlüsselte Verbindungen mit Transport Layer Security (TLS 1.2), und alle eingehenden Verbindungen mit TLS 1.0 und TLS 1.1 werden standardmäßig verweigert. Die Erzwingung einer verschlüsselten Verbindung oder die TLS-Versionskonfiguration bei Ihrem flexiblen Server kann konfiguriert und geändert werden.

Im Folgenden sind die verschiedenen Konfigurationen von SSL- und TLS-Einstellungen aufgeführt, die Sie bei Ihrem flexiblen Server verwenden können:

Important

Gemäß der Entfernung des Supports für die TLS 1.0- und TLS 1.1-Protokolle haben wir zuvor geplant, TLS 1.0 und 1.1 bis September 2024 vollständig zu beenden. Aufgrund von Abhängigkeiten, die von einigen Kunden identifiziert wurden, haben wir uns jedoch entschieden, die Zeitachse zu erweitern.

  • Ab dem 31. August 2025 beginnen wir das erzwungene Upgrade für alle Server, die weiterhin TLS 1.0 oder 1.1 verwenden. Nach diesem Datum können alle Verbindungen, die auf TLS 1.0 oder 1.1 basieren, jederzeit nicht mehr funktionieren. Um potenzielle Dienstunterbrechungen zu vermeiden, empfehlen wir dringend, dass Kunden ihre Migration zu TLS 1.2 vor dem 31. August 2025 abschließen.
  • Ab September 2024 dürfen keine neuen Server mehr TLS 1.0 oder 1.1 verwenden, und vorhandene Server dürfen diese Versionen nicht herabstufen.

Es wird dringend empfohlen, dass Kunden ihre Anwendungen aktualisieren, um TLS 1.2 so schnell wie möglich zu unterstützen, um Dienstunterbrechungen zu vermeiden.

Scenario Einstellungen für Serverparameter Description
SSL deaktivieren (verschlüsselte Verbindungen) require_secure_transport = OFF Wenn Ihre Legacy-Anwendung keine verschlüsselten Verbindungen mit einer Instanz von Azure Database for MySQL – flexibler Server unterstützt, können Sie die Erzwingung von verschlüsselten Verbindungen mit Ihrem flexiblen Server deaktivieren, indem Sie „require_secure_transport=OFF“ festlegen.
Durchsetzung von SSL mit TLS-Version < 1.2 (wird veraltet im September 2024) require_secure_transport = ON und tls_version = TLS 1.0 oder TLS 1.1 Wenn Ihre Legacy-Anwendung verschlüsselte Verbindungen unterstützt, aber eine TLS-Version < 1.2 erfordert, können Sie verschlüsselte Verbindungen aktivieren, müssen aber Ihren flexiblen Server so konfigurieren, dass Verbindungen mit der von der Anwendung unterstützten TLS-Version (v1.0 oder v1.1) zulässig sind
SSL mit TLS-Version = 1.2 erzwingen (Standardkonfiguration) require_secure_transport = ON und tls_version = TLS 1.2 Dies ist die empfohlene Standardkonfiguration für einen flexiblen Server.
SSL mit TLS-Version = 1.3 erzwingen (unterstützt bei MySQL v8.0 und höher) require_secure_transport = ON und tls_version = TLS 1.3 Dies ist nützlich und wird für die Entwicklung neuer Anwendungen empfohlen

Note

Änderungen an DER SSL-Verschlüsselung auf dem flexiblen Server werden nicht unterstützt. FIPS-Verschlüsselungssuite wird standardmäßig erzwungen, wenn tls_version auf TLS Version 1.2 festgelegt ist. Bei anderen TLS-Versionen als Version 1.2 wird das SSL-Verschlüsselungsverfahren auf die Standardeinstellungen festgelegt, die in der MySQL-Communityinstallation enthalten sind.

Überprüfen Sie die Verbindung mit SSL/TLS , um zu erfahren, wie Sie die verwendete TLS-Version identifizieren.

Verwandte Inhalte

  • Last updated on