Sicherheit in Amazon Aurora PostgreSQL

Eine allgemeine Übersicht über die Aurora-Sicherheit finden Sie unter Sicherheit in Amazon Aurora. Sie können die Sicherheit für Amazon Aurora PostgreSQL auf mehreren Ebenen verwalten:

• Um zu steuern, wer Verwaltungsaktionen in Amazon RDS für Aurora-DB-Cluster und PostgreSQL-DB-Instances ausführen darf, verwenden Sie AWS Identity and Access Management (IAM). IAM übernimmt die Authentifizierung der Benutzeridentität, bevor der Benutzer auf den Service zugreifen kann. Außerdem übernimmt IAM auch die Autorisierung, d. h., ob der Benutzer für die Vorgänge berechtigt ist, die er versucht auszuführen. Die IAM-Datenbankauthentifizierung ist eine zusätzliche Authentifizierungsmethode, die Sie beim Erstellen Ihres Aurora-PostgreSQL-DB-Clusters auswählen können. Weitere Informationen finden Sie unter Identity and Access Management für Amazon Aurora.

  Wenn Sie IAM mit Ihrem Aurora-PostgreSQL-DB-Cluster verwenden, melden Sie sich bei der AWS Management Console zuerst mit Ihren IAM-Anmeldeinformationen an, bevor Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/ aufrufen.

• Stellen Sie sicher, dass Sie Aurora-DB-Cluster in einer Virtual Private Cloud (VPC) basierend auf dem Amazon-VPC-Service erstellen. Mithilfe einer VPC-Sicherheitsgruppe können Sie steuern, welche Geräte und Amazon EC2-Instances Verbindungen zum Endpunkt und Port der DB-Instance für Aurora-DB-Cluster in einer VPC herstellen können. Sie können diese Endpunkt- und Portverbindungen mithilfe von Secure Sockets Layer (SSL) herstellen. Zusätzlich können Firewall-Regeln in Ihrem Unternehmen steuern, ob in Ihrem Unternehmen verwendete Geräte Verbindungen mit einer DB-Instance herstellen dürfen. Weitere Informationen zu VPCs finden Sie unter Amazon VPC und Amazon Aurora.

  Die unterstützte VPC-Tenancy hängt von der DB-Instance-Klasse ab, die von Ihren Aurora-PostgreSQL-DB-Clustern verwendet wird. Mit default-VPC-Tenancy, läuft der DB-Cluster auf gemeinsam genutzter Hardware. Mit dedicated-VPC-Tenancy läuft der DB-Cluster auf einer dedizierten Hardware-Instance. Die DB-Instance-Klassen mit Spitzenlastleistung unterstützen nur die Standard-VPC-Tenancy. Die DB-Instance-Klassen mit Spitzenlastleistung umfassen die DB-Instance-Klassen db.t3 und db.t4g. Alle anderen Aurora-PostgreSQL-DB-Instance-Klassen unterstützen sowohl die Standard- als auch die dedizierte VPC-Tenancy.

  Weitere Informationen zu Instance-Klassen finden Sie unter DB-Instance-Klassen von Amazon Aurora. Weitere Informationen über die default- und dedicated-VPC-Tenancy finden Sie unter Dedicated Instances im Amazon Elastic Compute Cloud-Benutzerhandbuch.

• Wenn Sie den PostgreSQL-Datenbanken, die auf Ihrem Amazon-Aurora-DB-Cluster ausgeführt werden, Berechtigungen erteilen möchten, können Sie den gleichen allgemeinen Ansatz wie bei eigenständigen Instances von PostgreSQL verwenden. Befehle wie CREATE ROLE, ALTER ROLE, GRANT und REVOKE funktionieren genau wie auf On-Premises-Datenbanken. Gleiches gilt für das direkte Ändern von Datenbanken, Schemas und Tabellen.

  PostgreSQL verwaltet Berechtigungen mithilfe von Rollen. Die Rolle rds_superuser ist die Rolle mit den meisten Berechtigungen in einem Aurora-PostgreSQL-DB-Cluster. Diese Rolle wird automatisch erstellt und dem Benutzer gewährt, der den DB-Cluster erstellt (das Hauptbenutzerkonto, standardmäßig postgres). Weitere Informationen hierzu finden Sie unter Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen.

Alle verfügbaren Aurora-PostgreSQL-Versionen, einschließlich Version 10, 11, 12, 13, 14 und höher, unterstützen den Salted Challenge Response Authentication Mechanism (SCRAM) für Passwörter als Alternative zu Message Digest (MD5). Wir empfehlen Ihnen, SCRAM zu verwenden, da dies sicherer ist als MD5. Weitere Informationen einschließlich Migration von Passwörtern für Datenbankbenutzer von MD5 nach SCRAM finden Sie unter Verwenden von SCRAM für die PostgreSQL-Passwortverschlüsselung.

Sicherung von Aurora-PostgreSQL-Daten mit SSL/TLS

Amazon RDS unterstützt Secure Socket Layer (SSL) und Transport Layer Security (TLS) Verschlüsselung für Aurora PostgreSQL DB-Cluster. Mit SSL/TLS können Sie eine Verbindung zwischen Ihren Anwendungen und Ihren Aurora PostgreSQL DB-Clustern verschlüsseln. Sie können auch erzwingen, dass alle Verbindungen zu Ihrem Aurora PostgreSQL DB-Cluster SSL/TLS verwenden. Amazon Aurora PostgreSQL unterstützt jetzt Transport Layer Security (TLS) in den Versionen 1.1 und 1.2. Wir empfehlen die Verwendung von TLS 1.2 für verschlüsselte Verbindungen. Wir haben Unterstützung für TLSv1.3 für die folgenden Versionen von Aurora PostgreSQL hinzugefügt:

• 15.3 und alle höheren Versionen

• 14.8 und höhere 14-Versionen

• 13.11 und höhere 13-Versionen

• 12.15 und höhere 12-Versionen

• 11.20 und höhere 11-Versionen

Allgemeine Informationen über SSL/TLS-Unterstützung und PostgreSQL-Datenbanken finden Sie unter SSL-Unterstützung in der PostgreSQL-Dokumentation. Informationen zur Verwendung einer SSL/TLS-Verbindung über JDBC finden Sie unter Konfiguration des Clients in der PostgreSQL-Dokumentation.

SSL/TLS-Unterstützung ist in allen AWS Regionen für Aurora PostgreSQL verfügbar. Amazon RDS erstellt ein SSL/TLS-Zertifikat für Ihren Aurora PostgreSQL DB-Cluster, wenn der DB-Cluster erstellt wird. Wenn Sie die SSL/TLS-Zertifikatsprüfung aktivieren, enthält das SSL/TLS-Zertifikat den DB-Cluster-Endpunkt als Common Name (CN) für das SSL/TLS-Zertifikat, um Spoofing-Angriffe zu verhindern.

Um sich mit einem Aurora PostgreSQL DB-Cluster über SSL/TLS zu verbinden

1. Laden Sie das Zertifikat herunter.

   Informationen zum Herunterladen von Zertifikaten finden Sie unter Wird verwendet SSL/TLS , um eine Verbindung zu einer zu verschlüsseln.

2. Importieren Sie das Zertifikat in Ihr Betriebssystem.

3. Verbinden Sie sich mit Ihrem Aurora PostgreSQL DB-Cluster über SSL/TLS.

   Wenn Sie eine Verbindung über SSL/TLS herstellen, kann Ihr Client wählen, ob er die Zertifikatskette überprüfen möchte oder nicht. Wenn Ihre Verbindungsparameter sslmode=verify-ca oder sslmode=verify-full angeben, verlangt Ihr Client, dass sich die RDS CA-Zertifikate im Trust Store befinden oder von der Verbindungs-URL referenziert werden. Diese Anforderung dient zur Prüfung der Zertifikatskette, die Ihr Datenbankzertifikat signiert.

   Wenn ein Client, z. B. psql oder JDBC, mit SSL/TLS-Unterstützung konfiguriert ist, versucht der Client zunächst, eine Verbindung zur Datenbank mit SSL/TLS herzustellen. Wenn der Client keine Verbindung mit SSL/TLS herstellen kann, greift er auf eine Verbindung ohne SSL/TLS zurück. Standardmäßig ist die sslmode-Option für JDBC- und libpq-basierte Clients auf prefer festgelegt.

   Verwenden Sie den Parameter sslrootcert, um auf das Zertifikat zu verweisen, beispielsweise sslrootcert=rds-ssl-ca-cert.pem.

Das folgende Beispiel zeigt psql zur Herstellung einer Verbindung mit einem Aurora-PostgreSQL-DB-Cluster:

$ psql -h testpg.cdhmuqifdpib.us-east-1.rds.amazonaws.com -p 5432 \
    "dbname=testpg user=testuser sslrootcert=rds-ca-2015-root.pem sslmode=verify-full"

Erfordernis einer SSL/TLS-Verbindung zu einem Aurora PostgreSQL DB-Cluster

Zum Erzwingen von SSL/TLS-Verbindungen zu Ihrem DB-Cluster von Aurora PostgreSQL verwenden Sie den Parameter rds.force_ssl.

• Zum Erzwingen von SSL/TLS-Verbindungen setzen Sie den Wert des Parameters rds.force_ssl auf 1 (on).

• Zum Deaktivieren erzwungener SSL/TLS-Verbindungen setzen Sie den Wert des Parameters rds.force_ssl auf 0 (off).

Der Standardwert dieses Parameters hängt von der Aurora-PostgreSQL-Version ab:

• Für Aurora-PostgreSQL-Versionen 17 und höher: Der Standardwert ist 1 (on).

• Für Aurora-PostgreSQL-Versionen 16 und niedriger: Der Standardwert ist 0 (off).

Anmerkung

Wenn Sie ein Hauptversions-Upgrade von Aurora-PostgreSQL-Version 16 oder früher auf Version 17 oder höher durchführen, ändert sich der Standardwert des Parameters von 0 (off) auf 1 (on). Diese Änderung kann zu Verbindungsfehlern bei Anwendungen führen, die nicht für SSL konfiguriert sind. Sie können zum vorherigen Standardverhalten zurückkehren, indem Sie diesen Parameter auf 0 (off) setzen.

Weitere Informationen zur Handhabung von Parametern finden Sie unter Parametergruppen für Amazon Aurora.

Die Aktualisierung des Parameters rds.force_ssl setzt auch den PostgreSQL-Parameter ssl auf 1 (on) und modifiziert die Datei Ihres DB-Clusters pg_hba.conf, um die neue SSL/TLS-Konfiguration zu unterstützen.

Wenn der Parameter rds.force_ssl für einen DB-Cluster auf 1 gesetzt ist, wird beim Verbindungsaufbau eine Ausgabe ähnlich der folgenden angezeigt, die darauf hinweist, dass SSL/TLS jetzt erforderlich ist:

$ psql postgres -h SOMEHOST.amazonaws.com -p 8192 -U someuser
psql (9.3.12, server 9.4.4)
WARNING: psql major version 9.3, server major version 9.4.
Some psql features might not work.
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.

postgres=>                    
                

Ermitteln des SSL/TLS-Verbindungsstatus

Der Verschlüsselungsstatus Ihrer Verbindung wird auf dem Anmelde-Banner angezeigt, wenn Sie sich mit dem DB-Cluster verbinden:

Password for user master: 
psql (9.3.12) 
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) 
Type "help" for help.   

postgres=> 

Sie können auch die Erweiterung sslinfo laden und dann die Funktion ssl_is_used() aufrufen, um festzustellen, ob SSL/TLS verwendet wird. Die Funktion gibt t zurück, wenn die Verbindung SSL/TLS verwendet, andernfalls gibt sie f zurück.

postgres=> create extension sslinfo;
CREATE EXTENSION

postgres=> select ssl_is_used();
 ssl_is_used
---------
t
(1 row) 

Sie können den Befehl select ssl_cipher() verwenden, um die SSL/TLS-Verschlüsselung zu bestimmen:

postgres=> select ssl_cipher();
ssl_cipher
--------------------
DHE-RSA-AES256-SHA
(1 row)
                

Wenn Sie set rds.force_ssl aktivieren und Ihren DB-Cluster neu starten, werden Nicht-SSL-Verbindungen abgelehnt, und die folgende Mitteilung wird angezeigt:

$ export PGSSLMODE=disable
$ psql postgres -h SOMEHOST.amazonaws.com -p 8192 -U someuser
psql: FATAL: no pg_hba.conf entry for host "host.ip", user "someuser", database "postgres", SSL off
$

Informationen zur Option sslmode finden Sie unter Datenbankverbindung-Steuerungsfunktionen in der PostgreSQL-Dokumentation.

Konfigurieren von Chiffrier-Suiten für Verbindungen mit Aurora-PostgreSQL-DB-Clustern

Durch die Verwendung von konfigurierbaren Chiffrier-Suiten können Sie mehr Kontrolle über die Sicherheit Ihrer Datenbankverbindungen haben. Sie können eine Liste von Chiffrier-Suiten angeben, die Sie zum Sichern von SSL/TLS-Verbindungen zu Ihrer Datenbank des Clients zulassen möchten. Mit konfigurierbaren Chiffrier-Suiten können Sie die Verbindungsverschlüsselung steuern, die Ihr Datenbankserver akzeptiert. Dies hilft, die Verwendung von unsicheren oder veralteten Chiffren zu verhindern.

Konfigurierbare Chiffrier-Suiten werden in Aurora PostgreSQL Version 11.8 und höher unterstützt.

Um die Liste der zulässigen Chiffren für die Verschlüsselung von Verbindungen anzugeben, ändern Sie die ssl_ciphers-Cluster-Parameter. Legen Sie den Parameter ssl_ciphers mithilfe der AWS Management Console, der AWS CLI oder der RDS-API auf eine Zeichenfolge von kommagetrennten Verschlüsselungswerten in einer Cluster-Parametergruppe fest. Um Cluster-Parameter festzulegen, siehe Ändern von Parametern in einer DB-Cluster-Parametergruppe in Amazon Aurora.

Die folgende Tabelle zeigt die unterstützten Verschlüsselungen für die gültigen Versionen der Aurora-PostgreSQL-Engine.

Engine-Versionen für Aurora PostgreSQL	Unterstützte Verschlüsselungen	TLS 1.1	TLS 1.2	TLS 1.3
9.6, 10.20 und niedriger, 11.15 und niedriger, 12.10 und niedriger, 13.6 und niedriger	DHE-RSA-AES128-SHA DHE-RSA-AES128-SHA256 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-SHA DHE-RSA-AES256-SHA256 DHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES256-GCM-SHA384	Ja Nein Nein Nein Nein Nein Ja Nein Nein Ja Nein Nein Ja Nein	Nein Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja	Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein
10.21, 11.16, 12.11, 13.7, 14.3 und 14.4	ECDHE-RSA-AES128-SHATLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256	Ja Nein Ja Nein Ja Nein Ja Nein Nein Ja Nein Ja Nein	Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja	Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein
10.22, 11.17, 12.12, 13.8, 14.5 und 15.2	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256	Ja Nein Nein Ja Nein Ja Nein Nein Ja Nein Nein Ja Nein Ja Ja Nein	Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja	Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein
11.20, 12.15, 13.11, 14.8, 15.3, 16.1 und höher	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384	Ja Nein Nein Ja Nein Ja Nein Nein Ja Nein Nein Ja Nein Ja Ja Nein Nein Nein	Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Nein Nein	Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Ja Ja

Sie können auch den describe-motor-default-cluster-parameters-CLI-Befehl verwenden, um festzustellen, welche Chiffrier-Suiten derzeit für eine bestimmte Parametergruppenfamilie unterstützt werden. Im folgenden Beispiel wird veranschaulicht, wie Sie die zulässigen Werte für ssl_cipher-Cluster-Parameter für Aurora PostgreSQL 11 abrufen.

aws rds describe-engine-default-cluster-parameters --db-parameter-group-family aurora-postgresql11
                
    ...some output truncated...
	{
		"ParameterName": "ssl_ciphers",
		"Description": "Sets the list of allowed TLS ciphers to be used on secure connections.",
		"Source": "engine-default",
		"ApplyType": "dynamic",
		"DataType": "list",
		"AllowedValues": "DHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA256,DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-SHA,DHE-RSA-AES256-SHA256,DHE-RSA-AES256-GCM-SHA384,
		ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-SHA384,ECDHE-RSA-AES256-GCM-SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,
		TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
		TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
		"IsModifiable": true,
		"MinimumEngineVersion": "11.8",
		"SupportedEngineModes": [
			"provisioned"
		]
	},
    ...some output truncated...

Der Parameter ssl_ciphers ist standardmäßig auf alle zulässigen Verschlüsselungssuites eingestellt. Weitere Informationen zu Chiffren finden Sie in der ssl_ciphers-Variablen in der PostgreSQL-Dokumentation.