Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Sicherheitsüberlegungen für das Upgrade von Aurora MySQL Version 3 auf Version 8.4

Bei der Migration von Aurora MySQL Version 3 (MySQL 8.0-kompatibel) auf Aurora MySQL Version 8.4 erfordern mehrere wichtige sicherheitsrelevante Änderungen eine sorgfältige Planung und Abwägung. In diesem Leitfaden werden die wichtigsten Sicherheitsänderungen beschrieben und Empfehlungen für eine reibungslose Migration gegeben.

Authentifizierungsrichtlinie (neu in 8.4)

Aurora MySQL Version 3 (kompatibel mit MySQL 8.0) verwendet den default_authentication_plugin Parameter, um das Standard-Authentifizierungs-Plugin zu konfigurieren, das beim Erstellen von Datenbankbenutzern verwendet wird. In Aurora MySQL Version 8.4 wird dieser Parameter durch den authentication_policy Parameter ersetzt, der *:caching_sha2_password standardmäßig auf gesetzt ist.

Unterstützte Werte in Aurora MySQL:

Die Upgrade-Vorabprüfung ist veraltet und DefaultAuth warnt, wenn Ihr Quell-Cluster auf eingestellt istdefault_authentication_plugin. mysql_native_password Überprüfen Sie diese Warnung und konfigurieren Sie den authentication_policy Parameter für die Parametergruppe Ihres Ziel-Clusters, wenn Sie ein Upgrade durchführen.

Verhalten von Master-Benutzern

Neue Cluster

Der Masterbenutzer wird mit dem Authentifizierungs-Plugin erstellt, das durch den authentication_policy Parameter bei der Clustererstellung festgelegt wurde. Wenn Sie die Standardparametergruppe verwenden, wird der Master-Benutzer mit dem caching_sha2_password Authentifizierungs-Plugin erstellt. Wenn Sie eine benutzerdefinierte Parametergruppe verwenden, bei der der authentication_policy Parameter auf gesetzt ist*:mysql_native_password, wird der Masterbenutzer mit dem mysql_native_password Authentifizierungs-Plugin erstellt.

Das Masterbenutzer-Passwort wurde zurückgesetzt

Wenn Sie das Masterbenutzer-Passwort zurücksetzen — über die AWS-Managementkonsole CLI (modify-db-cluster --master-user-password) oder die API — verwendet Aurora das aktuelle Standard-Plugin, das zum Zeitpunkt des Resets durch den authentication_policy Parameter definiert wurde.

Secrets Manager und Passwortrotation

Wenn Sie AWS Secrets Manager zur Verwaltung Ihres Masterbenutzer-Passworts den Wert des authentication_policy Parameters aktualisieren, wird bei der nächsten Passwortrotation das Authentifizierungs-Plugin des Masterbenutzers so eingestellt, dass es dem neuen authentication_policy Parameterwert entspricht.

Datenbankbenutzer, die nach dem Upgrade erstellt wurden

Bestehende Datenbankbenutzer, die das mysql_native_password Authentifizierungs-Plugin verwenden, funktionieren auch nach dem Upgrade weiter. Datenbankbenutzer, die Sie nach dem Upgrade ohne Angabe einer IDENTIFIED WITH Klausel erstellen, verwenden das durch den authentication_policy Parameter definierte Authentifizierungs-Plug-In. Wenn der Parameter seinen Standardwert von hat*:caching_sha2_password, werden neue Benutzer mit dem caching_sha2_password Authentifizierungs-Plug-In erstellt.

Um das Standard-Authentifizierungs-Plugin für alle neuen Benutzer zu ändern, aktualisieren Sie den Wert vonauthentication_policy. Weitere Informationen zu unterstützten Werten finden Sie unterAuthentifizierungsrichtlinie (neu in 8.4).

Um einen Benutzer mit einem anderen Authentifizierungs-Plugin als dem Standard-Plugin zu erstellen, geben Sie es explizit in der CREATE USER Anweisung an:

CREATE USER 'username'@'host' IDENTIFIED WITH authentication-plugin BY 'password';

Änderungen bei Verschlüsselung und TLS

Um TLS für alle Benutzerverbindungen zu Ihrem Aurora MySQL-DB-Cluster zu verlangen, verwenden Sie den require_secure_transport DB-Cluster-Parameter. Standardmäßig ist dieser Parameter ON in Aurora MySQL Version 8.4 auf gesetzt.

Aurora MySQL Version 8.4 setzt strengere kryptografische Standards durch, die den neuesten Sicherheitsanforderungen für die DB-Cluster-Parameter ssl_ciphers (TLS 1.2) und tls_ciphersuites (TLS 1.3) entsprechen. Weitere Informationen finden Sie unter Sicherheit in Amazon Aurora MySQL.

Um Verbindungsunterbrechungen zu vermeiden, überprüfen Sie vor der Migration die TLS-Konfigurationen für Ihren MySQL-Client und Ihren Ziel-DB-Cluster.

Migration der Komponenten zur Passwortvalidierung

Aurora MySQL Version 8.4 führt den aurora_enable_validate_password_component Cluster-Parameter ein, um die validate_password Komponente zu aktivieren oder zu deaktivieren, sodass sie nicht manuell installiert oder deinstalliert werden muss. Wenn Sie das validate_password Plugin zuvor installiert hatten und die Komponente nach dem Upgrade aktiviert haben, ist nur die Komponente wirksam — das Plugin wird ignoriert.

Ab Aurora MySQL Version 8.4 können Sie, wenn Sie das validate_password Plugin zuvor über den INSTALL PLUGIN Befehl installiert haben, zur validate_password Komponente migrieren, indem Sie den Parameter aktivieren aurora_enable_validate_password_component und dann das Plugin über den UNINSTALL PLUGIN Befehl auf Ihrer Writer-Instanz entfernen.

Wenn Sie die validate_password Komponente zuvor manuell installiert habenINSTALL COMPONENT 'file://component_validate_password', stellen Sie sicher, dass Sie den aurora_enable_validate_password_component Parameter beim Upgrade in Ihrer Ziel-DB-Cluster-Parametergruppe festgelegt haben. Nach dem Upgrade wird die Komponente nicht mehr in der mysql.component Tabelle aufgeführt. Sie können die aurora_enable_validate_password_component globale Variable verwenden, um den Status der Komponente zu überprüfen.

Beim ersten Start der DB-Engine nach dem Upgrade wird die folgende Meldung in Ihrem MySQL-Fehlerprotokoll angezeigt, falls Sie die Komponente zuvor manuell installiert hatten:

Component 'file://component_validate_password' is being removed from mysql.component table.
validate_password component can be enabled/disabled through 'aurora_enable_validate_password_component' cluster parameter.

Die Upgrade-Precheck-Aurora ValidatePasswordPluginCheck warnt, wenn das validate_password Plugin auf Ihrem Quell-Cluster installiert ist. Diese Warnung blockiert das Upgrade nicht, Sie sollten jedoch planen, nach dem Upgrade auf die Komponente umzusteigen.

Neue dynamische Rechte

Aurora MySQL Version 8.4 unterstützt die folgenden neuen Rechte:

Diese Rechte werden Ihren Master-Benutzerkonten beim Upgrade automatisch gewährt. Berechtigungen von Hauptbenutzerkonten

Durchsetzung geschützter Benutzer für rdsproxyadmin

Ab Aurora MySQL Version 8.4.7 rdsproxyadmin ist er ein geschützter Benutzer. Die Engine lehntCREATE,,DROP, RENAME GRANTREVOKE, und SET PASSWORD Operationen gegen einen beliebigen Host rdsproxyadmin ab. Eine vollständige Liste der abgelehnten Operationen und Beispielfehler finden Sie unterReservierte Benutzer in Aurora MySQL.

Aurora MySQL Version 3 reserviert den rdsproxyadmin Namen nicht. Wenn Sie einen Datenbankbenutzer mit dem Namen rdsproxyadmin in Version 3 erstellt haben (anstatt ihn beim Registrieren eines Proxyziels vom System erstellen zu lassen), lesen Sie diesen Abschnitt, bevor Sie ein Upgrade auf Version 8.4 durchführen.

Vor dem Upgrade

Wenn Sie in Ihrem Version 3-Cluster einen rdsproxyadmin Benutzer erstellt haben, benennen Sie das Konto um oder löschen Sie es, bevor Sie auf Version 8.4 aktualisieren. Sie können eine Verbindung der Version 3 verwenden, um eine der folgenden Anweisungen auszuführen:

-- Rename the existing account to a non-reserved name
RENAME USER 'rdsproxyadmin'@'host' TO 'new_user'@'host';

-- Or drop the account if it is no longer needed
DROP USER 'rdsproxyadmin'@'host';

Aktualisieren Sie alle Anwendungen oder gespeicherten Anmeldeinformationen, die auf den alten Benutzernamen verweisen, bevor Sie das Upgrade starten.

Wenn Sie den Benutzer vor dem Upgrade nicht umbenennen oder löschen

Wenn Sie einen Cluster aktualisieren, der bereits über einen von Ihnen erstellten rdsproxyadmin Benutzer verfügt, wird das Upgrade erfolgreich abgeschlossen. Das Konto wird mit dem vorhandenen Passwort und den vorhandenen Rechten beibehalten, und Sie können weiterhin wie rdsproxyadmin mit dem ursprünglichen Passwort eine Verbindung zum Cluster herstellen.

Nach dem Upgrade können Sie das Konto jedoch nicht ändern. Wenn Sie versuchen, Rechte für zu löschen, umzubenennen, zu ändern oder das Passwort für zu ändernrdsproxyadmin, gibt die Anweisung einen Fehler zurück.

Wenn Sie das Konto nach dem Upgrade entfernen oder den rdsproxyadmin Namen für den RDS-Proxy zurückfordern möchten, wenden Sie sich an den AWS Support. AWS Der Support kann einen bereits vorhandenen rdsproxyadmin Benutzer entfernen, der aus Version 3 übernommen wurde.