Vergleich von Aurora MySQL Version 3 und Aurora MySQL Version 8.4

Amazon Aurora MySQL Version 8.4 bietet erhebliche Verbesserungen und Änderungen im Vergleich zu Aurora MySQL Version 3 (kompatibel mit MySQL 8.0). In diesem Leitfaden werden die wichtigsten Unterschiede hervorgehoben, damit Sie besser verstehen, was neu ist und was sich geändert hat.

Authentifizierung und Sicherheit

Verwaltung des Authentifizierungs-Plugins

Aurora MySQL Version 3 verwendet den default_authentication_plugin Parameter, um das Standard-Authentifizierungs-Plugin für neue Datenbankbenutzer zu konfigurieren.

Aurora MySQL Version 8.4 default_authentication_plugin ersetzt den durch den authentication_policy Parameter, der eine flexiblere Authentifizierungskonfiguration bietet.

TLS und Verschlüsselung

Aurora MySQL Version 8.4 setzt strengere Sicherheitsstandards durch:

• Der require_secure_transport Parameter ist ON standardmäßig auf eingestellt, sodass TLS für alle Verbindungen erforderlich ist.

• Unterstützt nur TLS 1.2 und TLS 1.3.

• Erzwingt moderne kryptografische Standards mit eingeschränkten Verschlüsselungssammlungen.

Weitere Informationen finden Sie unter Sicherheit in Amazon Aurora MySQL.

Passwort-Verwaltung

Passwortvalidierung

Aurora MySQL Version 3 unterstützt das validate_password Plugin und die Komponente durch manuelle Installation, beschränkt auf Standardparameter, ohne dass Anpassungen verfügbar sind.

Aurora MySQL Version 8.4 unterstützt die Verwaltung der validate_password Komponente über DB-Cluster-Parameter:

• Neuer Cluster-Parameter: aurora_enable_validate_password_component

• Keine manuelle Installation erforderlich — einfach per Parameter aktivieren oder deaktivieren.

• Die Komponente ist nicht in der mysql.component Tabelle aufgeführt.

• Der Komponentenstatus kann über Cluster-Parametergruppen-APIs oder globale Variablen überprüft aurora_enable_validate_password_component werden.

Aurora MySQL Version 8.4 führt die folgenden Parameter auf Clusterebene für die Anpassung der Passwortvalidierung ein:

• validate_password.check_user_name

• validate_password.length

• validate_password.mixed_case_count

• validate_password.number_count

• validate_password.policy(unterstützt nur die Stufen LOW und MEDIUM)

• validate_password.special_char_count

Weitere Informationen finden Sie unter Passwortrichtlinien und Passwortvalidierung in Aurora MySQL.

Die folgenden nicht änderbaren validate_password Plugin-Parameter auf Instanzebene wurden in Aurora MySQL Version 8.4 entfernt:

• validate-password

• validate_password_dictionary_file

• validate_password_length

• validate_password_mixed_case_count

• validate_password_number_count

• validate_password_policy

• validate_password_special_char_count

Weitere Informationen finden Sie unter Aurora MySQL Konfigurationsparameter.

Passwort-Richtlinien

Aurora MySQL Version 8.4 bietet umfassende Unterstützung für Passwortrichtlinien durch neue Cluster-Parameter:

• default_password_lifetime

• password_history

• password_reuse_interval

• password_require_current

• disconnect_on_expired_password

Diese Parameter sorgen zusammen mit den Passwortrichtlinien pro Konto für eine detaillierte Kontrolle. Weitere Informationen finden Sie unter Passwortrichtlinien und Passwortvalidierung in Aurora MySQL.

Die Standardwerte der Parameter ändern sich

temptable_max_mmap

Aurora MySQL Version 3 verwendet einen festen Standard von 1 GiB (1073741824) für den temptable_max_mmap Parameter in allen Instanzklassen und Speicherkonfigurationen.

Aurora MySQL Version 8.4.7 und höher berechnet den Standard dynamisch auf der Grundlage des zugewiesenen Speichers des Clusters. Die Formel lautet:

LEAST(4294967296, {AllocatedStorage*3/100})

Dies legt den Standardwert auf 3% des zugewiesenen Speichers fest, begrenzt auf maximal 4 GiB. Die Standardeinstellung passt sich der Speicherkapazität an, bleibt aber begrenzt, wodurch Abfragefehler auf Leser-Instances, die die TempTable Speicher-Engine verwenden, reduziert werden.

Den Parameterreferenzeintrag finden Sie unterAurora MySQL Konfigurationsparameter.

Rechte und Rollen

Neue dynamische Rechte

Aurora MySQL Version 8.4 unterstützt neue Rechte, die folgenden Personen gewährt wurdenrds_superuser_role:

• ALLOW_NONEXISTENT_DEFINER

• FLUSH_PRIVILEGES

• OPTIMIZE_LOCAL_TABLE

• SET_ANY_DEFINER

Das SET_USER_ID Privileg wird entfernt, da es durch ALLOW_NONEXISTENT_DEFINER und ersetzt wirdSET_ANY_DEFINER.

Weitere Informationen finden Sie unter Berechtigungen von Hauptbenutzerkonten.

Verhalten von Master-Benutzern

Aurora MySQL Version 3: Der Hauptbenutzer verwendet standardmäßig mysql_native_password das Auth-Plugin für die kennwortbasierte Authentifizierung.

Aurora MySQL Version 8.4: Das Master-Benutzerauthentifizierungs-Plugin ist auf den Standardwert gesetzt, der im authentication_policy Cluster-Parameter definiert ist (standardmäßig caching_sha2_password Plugin).

Beim Zurücksetzen des Masterbenutzer-Passworts über die AWS-Managementkonsole CLI oder API oder durch AWS Secrets Manager Rotation verwendet Aurora automatisch das Authentifizierungs-Plugin, das durch den aktuellen authentication_policy Parameterwert zum Zeitpunkt des Resets definiert ist.

Durchsetzung geschützter Benutzer für rdsproxyadmin

Aurora MySQL Version 3: rdsproxyadmin ist ein reservierter Benutzername für RDS Proxy. Die Engine hindert Sie jedoch nicht daran, einen Datenbankbenutzer mit diesem Namen zu erstellen, zu ändern oder zu löschen.

Aurora MySQL Version 8.4 (ab 8.4.7): rdsproxyadmin ist 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.

Wenn Sie einen rdsproxyadmin Benutzer in einem Cluster der Version 3 erstellt haben, finden Sie Durchsetzung geschützter Benutzer für rdsproxyadmin Anleitungen vor dem Upgrade unter.