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.
**Topics**
+ [Authentifizierungsrichtlinie (neu in 8.4)](#AuroraMySQL.Upgrade-v3-v84-security.auth-policy)
+ [Verhalten von Master-Benutzern](#AuroraMySQL.Upgrade-v3-v84-security.master-user)
+ [Änderungen bei Verschlüsselung und TLS](#AuroraMySQL.Upgrade-v3-v84-security.tls)
+ [Migration der Komponenten zur Passwortvalidierung](#AuroraMySQL.Upgrade-v3-v84-security.validate-password)
+ [Neue dynamische Rechte](#AuroraMySQL.Upgrade-v3-v84-security.new-privileges)
+ [Durchsetzung geschützter Benutzer für `rdsproxyadmin`](#AuroraMySQL.Upgrade-v3-v84-security.rdsproxyadmin)
## 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:
+ `*:caching_sha2_password`(Standardwert. Erlaubt jedes Ein-Faktor-Authentifizierungs-Plug-In, `caching_sha2_password` sofern keines angegeben ist)
+ `*:mysql_native_password`(Erlaubt jedes Ein-Faktor-Authentifizierungs-Plugin, `mysql_native_password` wenn keines angegeben ist)
**Anmerkung**
Multi-factor Authentifizierungskonfigurationen werden in Aurora MySQL Version 8.4 nicht unterstützt.
Die [Upgrade-Vorabprüfung ist veraltet](AuroraMySQL.upgrade-prechecks.descriptions.md#deprecatedDefaultAuth) und DefaultAuth warnt, wenn Ihr Quell-Cluster auf eingestellt ist`default_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 von`authentication_policy`. Weitere Informationen zu unterstützten Werten finden Sie unter[Authentifizierungsrichtlinie (neu in 8.4)](#AuroraMySQL.Upgrade-v3-v84-security.auth-policy).
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](AuroraMySQL.Security.md).
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 haben`INSTALL 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](AuroraMySQL.upgrade-prechecks.descriptions.md#auroraValidatePasswordPluginCheck) 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:
+ `ALLOW_NONEXISTENT_DEFINER`
+ `FLUSH_PRIVILEGES`
+ `OPTIMIZE_LOCAL_TABLE`
+ `SET_ANY_DEFINER`
Diese Rechte werden Ihren Master-Benutzerkonten beim Upgrade automatisch gewährt. [Berechtigungen von Hauptbenutzerkonten](UsingWithRDS.MasterAccounts.md)
## Durchsetzung geschützter Benutzer für `rdsproxyadmin`
Ab Aurora MySQL Version 8.4.7 `rdsproxyadmin` ist er ein geschützter Benutzer. Die Engine lehnt`CREATE`,,`DROP`, `RENAME` `GRANT``REVOKE`, und `SET PASSWORD` Operationen gegen einen beliebigen Host `rdsproxyadmin` ab. Eine vollständige Liste der abgelehnten Operationen und Beispielfehler finden Sie unter[Reservierte Benutzer in Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.ReservedUsers).
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 ändern`rdsproxyadmin`, 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](https://aws.amazon.com/premiumsupport/). AWS Der Support kann einen bereits vorhandenen `rdsproxyadmin` Benutzer entfernen, der aus Version 3 übernommen wurde.