RDS-Sicherheit: Verschlüsselung und Parametergruppen

RDS unterstützt die Verschlüsselung ruhender Daten mithilfe des AWS Key Management Service (KMS). Wenn Sie die Verschlüsselung beim Erstellen der DB-Instance aktivieren, werden alle Daten auf den zugrunde liegenden EBS-Volumes, automatisierte Backups, Snapshots und Read Replicas mit dem angegebenen KMS-Schlüssel verschlüsselt.

Die Verschlüsselung muss zum Zeitpunkt der Erstellung aktiviert werden—eine vorhandene unverschlüsselte Instance kann nicht nachträglich direkt verschlüsselt werden. Als Umgehungslösung erstellen Sie einen unverschlüsselten Snapshot, kopieren ihn mit aktivierter Verschlüsselung und stellen die Instance aus dem verschlüsselten Snapshot wieder her. Der KMS-Schlüssel kann ein von AWS verwalteter Schlüssel oder ein Customer-Managed Key (CMK) für zusätzliche Kontrolle und Auditing sein.

Da Sie die Verschlüsselung für eine vorhandene Instance nicht aktivieren können, gehen Sie bei der Migration wie folgt vor:

1. Erstellen Sie einen manuellen Snapshot der unverschlüsselten Instance
2. Kopieren Sie den Snapshot und aktivieren Sie während des Kopiervorgangs die Verschlüsselung, indem Sie einen KMS-Schlüssel angeben
3. Stellen Sie aus dem verschlüsselten Snapshot eine neue DB-Instance wieder her
4. Aktualisieren Sie den Endpunkt Ihrer Anwendung auf die neue Instance
5. Löschen Sie die alte unverschlüsselte Instance

Bei diesem Vorgehen kommt es zu einer gewissen Ausfallzeit, sofern Sie nicht DMS verwenden, um die neue verschlüsselte Instance vor der Umschaltung synchron zu halten.

RDS verschlüsselt Daten während der Übertragung mithilfe von SSL/TLS. Jede Engine stellt ein herunterladbares CA-Zertifikat bereit, mit dem Ihr Client-Treiber die Identität des Servers überprüft. Um SSL-Verbindungen zu erzwingen, konfigurieren Sie die Datenbank-Engine so, dass sie unverschlüsselte Verbindungen ablehnt.

Setzen Sie für MySQL den Parameter require_secure_transport = ON in der Parametergruppe. Setzen Sie für PostgreSQL ssl = 1 und optional rds.force_ssl = 1, um Nicht-SSL-Verbindungen vollständig abzulehnen. Viele Java- und Python-Datenbanktreiber akzeptieren außerdem den Verbindungszeichenfolgenparameter sslmode=require.

Parametergruppen sind benannte Sammlungen von Konfigurationseinstellungen der Engine, die Sie einer RDS-Instance zuordnen. Sie entsprechen bei RDS dem Bearbeiten von my.cnf unter MySQL oder postgresql.conf unter PostgreSQL, werden jedoch von AWS verwaltet und pro Engine-Familie versioniert.

AWS stellt für jede Engine-Version eine Standardparametergruppe bereit, deren Einstellungen jedoch nicht bearbeitet werden können. Um Parameter anzupassen, erstellen Sie eine benutzerdefinierte Parametergruppe, ändern die gewünschten Parameter und ordnen sie Ihrer DB-Instance zu. Änderungen an statischen Parametern erfordern einen Neustart; dynamische Parameter werden sofort wirksam.

Nach dem Erstellen einer benutzerdefinierten Parametergruppe ändern Sie einzelne Parameter mit dem CLI-Befehl modify-db-parameter-group oder über die Konsole. Parameter verfügen über eine Anwendungsmethode: immediate (wird ohne Neustart wirksam) oder pending-reboot (wird erst nach dem nächsten Neustart der Instance wirksam).

Für die Prüfung wichtige Parameter sind: max_connections (begrenzt gleichzeitige Verbindungen), innodb_buffer_pool_size (Größe des In-Memory-Caches von MySQL), log_bin_trust_function_creators (erlaubt gespeicherte Funktionen, die in das Binärprotokoll schreiben) und rds.force_ssl (erzwingt SSL für PostgreSQL).

Optionsgruppen ähneln Parametergruppen, steuern jedoch Erweiterungsfunktionen der Datenbank-Engine statt der Konfigurationsoptimierung. Sie werden hauptsächlich mit Oracle und SQL Server verwendet, um Funktionen wie Oracle Application Express (APEX), SQL Server Transparent Data Encryption (TDE) oder die SQL-Server-Authentifizierung über Active Directory zu aktivieren.

Jede Option in einer Optionsgruppe kann eigene Einstellungen haben. Optionsgruppen werden pro Engine-Familie versioniert und müssen der DB-Instance zugeordnet werden. Für die meisten Open-Source-Engines (MySQL, PostgreSQL, MariaDB) werden benutzerdefinierte Optionsgruppen nur selten benötigt.

RDS unterstützt die IAM-Datenbankauthentifizierung für MySQL- und PostgreSQL-Engines. Statt eines statischen Benutzernamens und Passworts übernimmt Ihre Anwendung eine IAM-Rolle und erzeugt mithilfe des AWS-CLI-Befehls oder SDK-Aufrufs generate-db-auth-token ein temporäres Authentifizierungstoken, das 15 Minuten gültig ist.

Zu den Vorteilen gehören der Verzicht auf langlebige Datenbankpasswörter, die automatische Anmeldedatenrotation über IAM-Richtlinien und eine zentralisierte Zugriffskontrolle. Für diese Funktion müssen Sie --enable-iam-database-authentication für die Instance aktivieren und einen Datenbankbenutzer erstellen, der einer IAM-Rolle zugeordnet ist.

AWS Secrets Manager kann das RDS-Masterpasswort und die Anmeldedaten der Anwendung speichern und automatisch rotieren. Wenn die Rotation aktiviert ist, ruft Secrets Manager eine Lambda-Funktion auf, die das Datenbankpasswort aktualisiert und den neuen Wert im Secret speichert. Ihre Anwendung ruft den aktuellen Secret-Wert über die Secrets-Manager-API ab und verfügt dadurch stets über gültige Anmeldedaten.

Beim Erstellen einer RDS-Instance über die Konsole können Sie die Verwaltung der Master-Anmeldedaten durch Secrets Manager aktivieren. Dadurch entfallen fest im Code oder in Umgebungsvariablen hinterlegte Passwörter.

RDS-Instances werden innerhalb einer VPC ausgeführt und verwenden DB-Subnetzgruppen, um festzulegen, in welchen Subnetzen (über mehrere AZs hinweg) die Instance platziert werden kann. Es empfiehlt sich, RDS in privaten Subnetzen ohne direkten Internetzugriff zu platzieren.

Sicherheitsgruppen steuern, welche IP-Adressen und anderen Sicherheitsgruppen den DB-Port erreichen können (z. B. TCP 3306 für MySQL). Die Sicherheitsgruppe der Anwendungsebene sollte die einzige zulässige Quelle in der RDS-Sicherheitsgruppe sein, um das Prinzip der geringsten Berechtigung auf Netzwerkebene durchzusetzen. Konfigurieren Sie niemals 0.0.0.0/0 (den gesamten Datenverkehr) als eingehende Regel in einer RDS-Sicherheitsgruppe.

Enhanced Monitoring veröffentlicht Metriken auf Betriebssystemebene (CPU, Arbeitsspeicher, Dateisystem, Festplatten-I/O) alle 1–60 Sekunden in CloudWatch Logs und bietet damit eine feinere Granularität als die standardmäßigen CloudWatch-Metriken im 60-Sekunden-Intervall. Dazu wird ein Agent auf dem DB-Host ausgeführt. Verfügbar ist diese Funktion für alle Engines außer im SQL-Server-Spiegelungsmodus.

Datenbank-Audit-Protokolle (allgemeines Abfrageprotokoll und Protokoll langsamer Abfragen für MySQL; pgaudit für PostgreSQL) können zur Compliance-Analyse in CloudWatch Logs veröffentlicht werden. Aktivieren Sie diese über Parametergruppen und konfigurieren Sie anschließend die Protokollexporte in der RDS-Konsole unter Log exports.

Wichtige bewährte RDS-Sicherheitsverfahren für die Prüfung SAA-C03:

• Aktivieren Sie beim Erstellen der Instance die Verschlüsselung im Ruhezustand mit einem KMS-CMK
• Erzwingen Sie SSL/TLS während der Übertragung über die Einstellungen der Parametergruppe
• Platzieren Sie Instances in privaten Subnetzen mit restriktiven Sicherheitsgruppen
• Verwenden Sie die IAM-Datenbankauthentifizierung oder Secrets Manager, um statische Passwörter zu vermeiden
• Aktivieren Sie CloudTrail, um RDS-API-Aufrufe zu protokollieren, sowie CloudWatch Logs für Datenbank-Audit-Protokolle
• Verwenden Sie AWS-Config-Regeln (z. B. rds-instance-public-access-check), um Fehlkonfigurationen zu erkennen

Testen Sie Ihr Verständnis der Konzepte für AWS Solutions Architect (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Die RDS-Verschlüsselung im Ruhezustand verwendet KMS und muss beim Erstellen aktiviert werden; Parametergruppen steuern die Konfiguration der Engine und können unter anderem SSL/TLS während der Übertragung erzwingen; außerdem machen die IAM-Datenbankauthentifizierung und Secrets Manager statische Datenbankpasswörter überflüssig. Als Nächstes befassen wir uns mit DynamoDB-Tabellen, -Elementen und dem Design primärer Schlüssel.