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 VPCdedicated
, 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 Amazon Aurora. Para obtener más información acerca de la tenencia de VPC
default
ydedicated
, 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
yREVOKE
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
Temas
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
-
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.
-
Importe el certificado en su sistema operativo.
-
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
osslmode=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 enprefer
.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 Grupos de parámetros para Amazon Aurora.
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
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 los parámetros en un grupo de parámetros de clúster de base de datos en Amazon Aurora.
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 | TLS 1.1 | TLS 1.2 | TLS 1.3 |
---|---|---|---|---|
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 |
Sí No No No No No Sí No No Sí No No Sí No |
No Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí |
No No No No No No No No No No No No No No |
10.21, 11.16, 12.11, 13.7, 14.3 y 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 |
Sí No Sí No Sí No Sí No No Sí No Sí No |
Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí |
No No No No No No No No No No No No No |
10.22, 11.17, 12.12, 13.8, 14.5 y 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 |
Sí No No Sí No Sí No No Sí No No Sí No Sí Sí No |
Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí |
No No No No No No No No No No No No No No No No |
11.20, 12.15, 13.11, 14.8, 15.3, 16.1 y versiones posteriores | 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 |
Sí No No Sí No Sí No No Sí No No Sí No Sí Sí No No No |
Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí No No |
No No No No No No No No No No No No No No No No Sí Sí |
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