Seguridad con Amazon Aurora PostgreSQL - Amazon Aurora
Protección de los datos de Aurora PostgreSQL con SSL/TLS

Seguridad con Amazon Aurora PostgreSQL

Para obtener información general de la seguridad de Aurora, consulte Seguridad en Amazon Aurora. Puede administrar la seguridad de Amazon Aurora PostgreSQL en varios niveles diferentes:

  • Utilice AWS Identity and Access Management (IAM) para controlar quién puede realizar acciones de administración de Amazon RDS en clústeres de base de datos e instancias de base de datos de Aurora PostgreSQL. IAM gestiona la autenticación de la identidad del usuario antes de que el usuario pueda acceder al servicio. También se encarga de la autorización, es decir, si el usuario puede hacer lo que está intentando hacer. La autenticación de bases de datos de IAM es un método de autenticación adicional que puede elegir al crear el clúster de base de datos Aurora PostgreSQL. Para obtener más información, consulte Administración de la identidad y el acceso en Amazon Aurora.

    Si utiliza IAM con el clúster de bases de datos de Aurora PostgreSQL, inicie sesión en la AWS Management Console con sus credenciales de IAM primero, antes de abrir la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

  • Asegúrese de crear clústeres de base de datos de Aurora en una nube privada virtual (VPC) basada en el servicio Amazon VPC. Utilice un grupo de seguridad de VPC para controlar qué dispositivos e instancias de Amazon EC2 pueden abrir conexiones con el punto de conexión y el puerto de la instancia de base de datos para los clústeres de base de datos de Aurora en una VPC. Puede realizar estas conexiones de puntos de conexión y puertos mediante el uso de capa de sockets seguros (SSL). Además, las reglas del firewall de su compañía pueden controlar si los dispositivos que se ejecutan en ella pueden abrir conexiones a una instancia de base de datos. Para obtener más información acerca de las VPC, consulte VPC de Amazon y Amazon Aurora.

    La tenencia de VPC admitida depende de la clase de instancia de base de datos que utilicen los clústeres de base de datos de Aurora PostgreSQL. En el caso de la tenencia de VPC default, el clúster de base de datos se ejecuta en hardware compartido. En el caso de la tenencia de una VPC dedicated, el clúster de base de datos se ejecuta en una instancia de hardware dedicada. Las clases de instancia de base de datos de rendimiento ampliable solo admiten el arrendamiento de VPC predeterminado. Las clases de instancia de base de datos de rendimiento ampliable incluyen las clases de instancia de base de datos db.t3 y db.t4g. Todas las demás clases de instancia de base de datos de Aurora PostgreSQL admiten la tenencia de VPC predeterminada y dedicada.

    Para obtener más información sobre las clases de instancias, consulte Clases de instancia de base de datos de Aurora. Para obtener más información acerca de la tenencia de VPC default y dedicated, consulte Instancias dedicadas en la Guía del usuario de Amazon Elastic Compute Cloud.

  • Para conceder permisos a las bases de datos PostgreSQL que se ejecutan en el clúster de bases de datos Amazon Aurora, puede seguir el mismo procedimiento general que con las instancias independientes de PostgreSQL. Los comandos como CREATE ROLE, ALTER ROLE, GRANT y REVOKE funcionan de la misma forma que en las bases de datos en las instalaciones, al igual que la modificación directa de las tablas de los esquemas de las bases de datos.

    PostgreSQL administra los privilegios utilizando roles. El rol rds_superuser es el rol más privilegiado de un clúster de base de datos de Aurora PostgreSQL. Este rol se crea automáticamente y se otorga al usuario que crea el clúster de base de datos (la cuenta de usuario principal, postgres de forma predeterminada). Para obtener más información, consulte Descripción de los roles y permisos de PostgreSQL.

Todas las versiones de Aurora PostgreSQL, incluidas las versiones 10, 11, 12, 13, 14 y las versiones posteriores, admiten el mecanismo de autenticación mediante desafío-respuesta discontinuo (SCRAM) para las contraseñas como alternativa al resumen de mensajes (MD5). Le recomendamos que utilice SCRAM porque es más seguro que MD5. Para obtener más información, incluida la forma de migrar las contraseñas de los usuarios de base de datos de MD5 a SCRAM, consulte Uso de SCRAM para el cifrado de contraseñas de PostgreSQL.

Protección de los datos de Aurora PostgreSQL con SSL/TLS

Amazon RDS admite el cifrado mediante Capa de conexión segura (SSL) y Transport Layer Security (TLS) para los clústeres de base de datos de Aurora PostgreSQL. Con SSL/TLS, puede cifrar conexiones entre sus aplicaciones y sus clústeres de base de datos de Aurora PostgreSQL. También puede obligar a todas las conexiones con su clúster de base de datos de Aurora PostgreSQL a usar SSL/TLS. Amazon Aurora PostgreSQL admite Transport Layer Security (TLS), versiones 1.1 y 1.2. Se recomienda utilizar TLS 1.2 para conexiones cifradas. Se ha agregado compatibilidad con TLSv1.3 para las siguientes versiones de Aurora PostgreSQL:

  • Versión 15.3 y versiones posteriores

  • Versión 14.8 y versiones posteriores a la 14

  • Versión 13.11 y versiones posteriores a la 13

  • Versión 12.15 y versiones posteriores a la 12

  • Versión 11.20 y versiones posteriores a la 11

Para obtener la información general acerca de la compatibilidad con SSL/TLS y las bases de datos de PostgreSQL, consulte Compatibilidad con SSL en la documentación de PostgreSQL. Para obtener información sobre el uso de una conexión SSL/TLS a través de JDBC, consulte Configuración del cliente en la documentación de PostgreSQL.

La compatibilidad con SSL/TLS está disponible en todas las regiones de AWS para Aurora PostgreSQL. Amazon RDS crea un certificado SSL/TLS destinado al clúster de base de datos de Aurora PostgreSQL cuando se crea el clúster de base de datos. Si se habilita la verificación con certificado SSL/TLS, el certificado incluye el punto de enlace del clúster de base de datos como nombre común (CN) que el certificado de SSL/TLS debe proteger frente a los ataques de suplantación.

Para conectar con un clúster de base de datos de Aurora PostgreSQL a través de SSL/TLS

  1. Descargue el certificado.

    Para obtener más información acerca de cómo descargar certificados, consulte Uso de SSL/TLS para cifrar una conexión a un clúster de base de datos.

  2. Importe el certificado en su sistema operativo.

  3. Conéctese a su clúster de base de datos de Aurora PostgreSQL a través de SSL/TLS.

    Cuando se conecte mediante SSL/TLS, su cliente podrá elegir verificar la cadena de certificados o no. Si sus parámetros de conexión especifican sslmode=verify-ca o sslmode=verify-full, su cliente precisa que los certificados de CA de RDS estén en su almacén de confianza o se haga referencia a ellos en la URL de conexión. Este requisito es para verificar la cadena de certificados que firma su certificado de base de datos.

    Cuando un cliente, como psql o JDBC, está configurado con soporte de SSL/TLS, primero el cliente intenta conectarse a la base de datos con SSL/TLS de forma predeterminada. Si el cliente no puede conectarse mediante SSL/TLS, vuelve a la conexión sin SSL/TLS. De forma predeterminada, la opción sslmode para los clientes basados en JDBC y libpq está establecida en prefer.

    Use el parámetro sslrootcert para hacer referencia al certificado, por ejemplo: sslrootcert=rds-ssl-ca-cert.pem.

A continuación, aparece un ejemplo de cómo usar psql para conectarse a un clúster de base de datos de Aurora PostgreSQL.

$ 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"

Requerir una conexión SSL/TLS a un clúster de base de datos de Aurora PostgreSQL

Puede exigir que las conexiones al clúster de base de datos de Aurora PostgreSQL utilicen SSL/TLS por medio del parámetro rds.force_ssl. De forma predeterminada, el parámetro rds.force_ssl tiene el valor 0 (desactivado). Puede definir el parámetro rds.force_ssl en 1 (activado) fin de imponer SSL/TLS para las conexiones al clúster de base de datos. Al actualizar el parámetro rds.force_ssl, se define también el parámetro ssl de PostgreSQL como 1 (activado) y se modifica el archivo pg_hba.conf del clúster de base de datos para permitir la nueva configuración de SSL/TLS.

Puede definir el valor del parámetro rds.force_ssl actualizando el grupo de parámetros de su clúster de base de datos para su clúster de base de datos. Si el grupo de parámetros de su clúster de base de datos no es el grupo de parámetros predeterminado y el parámetro ssl ya se ha definido en 1 al configurar el parámetro rds.force_ssl como 1, no es necesario reiniciar el clúster de base de datos. De lo contrario, tendrá que reiniciar el clúster de base de datos para que el cambio tenga efecto. Para obtener más información acerca de los grupos de parámetros, consulte Working with parameter groups (Trabajar con grupos de parámetros).

Cuando el parámetro rds.force_ssl se haya definido en 1 para un clúster de base de datos, al conectarse verá una salida similar a la siguiente, que indica que ahora se requiere SSL/TLS:


$ 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=>

Determinar el estado de la conexión SSL/TLS

El estado cifrado de su conexión se muestra en el banner de inicio de sesión al establecer conexión con el clúster de base de datos.

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

postgres=>

También puede cargar la extensión sslinfo y llamar después a la función ssl_is_used() para determinar si se está utilizando SSL/TLS. La función devuelve t si la conexión usa SSL/TLS; de lo contrario, devuelve f.


postgres=> create extension sslinfo;
CREATE EXTENSION

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

Puede utilizar el comando select ssl_cipher() para determinar el cifrado SSL/TLS:


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

Si habilita set rds.force_ssl y reinicia el clúster de la base de datos, las conexiones que no usen SSL se rechazarán con el siguiente mensaje:


$ 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
$

Para obtener información acerca de la opción sslmode, consulte Funciones de control de conexión de la base de datos en la documentación de PostgreSQL.

Configuración de conjuntos de cifrado para conexiones a clústeres de base de datos de Aurora PostgreSQL

Mediante el uso de conjuntos de cifrado configurables, puede tener más control sobre la seguridad de las conexiones de su base de datos. Puede especificar una lista de conjuntos de cifrado que desea permitir para proteger las conexiones SSL/TLS del cliente a su base de datos. Con conjuntos de cifrado configurables, puede controlar el cifrado de conexión que acepta el servidor de base de datos. Esto ayuda a evitar el uso de cifrados inseguros o obsoletos.

Los conjuntos de cifrado configurables son compatibles con las versiones 11.8 y posteriores de Aurora PostgreSQL.

Con el fin de especificar la lista de cifrados permitidos para cifrar conexiones, modifique el parámetro del clúster ssl_ciphers. Establezca el parámetro ssl_ciphers en una cadena de valores de cifrado separados por comas en un grupo de parámetros de clúster mediante la AWS Management Console, la AWS CLI o la API de RDS. Para configurar los parámetros de clúster, consulte Modificación de parámetros de un grupo de parámetros de clúster de base de datos.

En la tabla siguiente, se muestran los cifrados compatibles para las versiones de motor válidas de Aurora PostgreSQL.

Versiones del motor de Aurora PostgreSQL Cifrados compatibles

9.6, 10.20 y versiones anteriores, 11.15 versiones anteriores, 12.10 versiones anteriores, 13.6 versiones anteriores

  • 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

10.21, 11.16, 12.11, 13.7, 14.3 y 14.4

  • 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-GCM-SHA256

  • ECDHE-RSA-AES256-SHA

  • ECDHE-RSA-AES256-GCM-SHA384

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_ECDSA_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

10.22 y versiones posteriores, 11.17 y versiones posteriores, 12.12 y versiones posteriores, 13.8 y versiones posteriores, 14.5 y versiones posteriores, y 15.2 y versiones posteriores

  • 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

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_ECDSA_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

15.3, 14.8, 13.11, 12.15 y 11.20

  • 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

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_ECDSA_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

También puede utilizar el comando de la CLI describe-motor-default-cluster-parameters para determinar qué conjuntos de cifrado se admiten actualmente para una familia de grupos de parámetros específica. El siguiente ejemplo muestra cómo obtener los valores permitidos para el parámetro ssl_cipher de clúster para Aurora PostgreSQL 11.

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...

El parámetro ssl_ciphers se establece de forma predeterminada en todos los conjuntos de cifrado permitidos. Para obtener más información sobre los cifrados, consulte la variable ssl_ciphers en la documentación de PostgreSQL.