Conexión de clientes con seguridad TLS a la base de datos

Información general

Las conexiones entre las aplicaciones cliente y el servidor de bases de datos siempre se cifran mediante la seguridad de la capa de transporte estándar del sector (TLS), anteriormente conocida como Capa de sockets seguros (SSL).

Azure Database for PostgreSQL admite conexiones cifradas mediante TLS 1.2 y 1.3. Se deniegan todas las conexiones entrantes que intentan cifrar el tráfico mediante TLS 1.0 y TLS 1.1.

De forma predeterminada, se aplica la conectividad protegida entre el cliente y el servidor. Si desea deshabilitar la aplicación de TLS, lo que permite las comunicaciones de cliente cifradas y sin cifrar, puede cambiar el parámetro require_secure_transport de servidor a OFF. También puede establecer la versión de TLS estableciendo el parámetro de servidor ssl_max_protocol_version. Se recomienda encarecidamente deshabilitar TLS.

Configuración de TLS de cliente

De forma predeterminada, PostgreSQL no realiza ninguna comprobación del certificado de servidor. Por este motivo, es posible suplantar la identidad (spoofing) del servidor (por ejemplo, modificando un registro DNS o tomando el control de la dirección IP del servidor) sin que el cliente lo sepa. Para evitar dicha suplantación de identidad, se debe usar la comprobación del certificado TLS en el cliente.

Hay muchos parámetros de conexión para configurar el cliente para TLS. Estos son algunos de los importantes:

• ssl: conexión mediante TLS. Esta propiedad no necesita un valor asociado. La mera presencia de este especifica una conexión TLS. Para la compatibilidad con versiones futuras, se prefiere el valor true. En este modo, cuando se establece una conexión TLS, el controlador de cliente valida la identidad del servidor para evitar ataques de tipo "man in the middle".

• sslmode: si necesita cifrado y quiere que se produzca un error en la conexión si no se puede cifrar, establezca sslmode=require. Esta configuración garantiza que el servidor está configurado para aceptar conexiones TLS para esta dirección IP o host y que el servidor reconoce el certificado de cliente. Si el servidor no acepta conexiones TLS o no se reconoce el certificado de cliente, se produce un error en la conexión. En la tabla siguiente, se detallan los valores de esta configuración:

  sslmode	Explanation
  disable	No se usa cifrado. Azure Database for PostgreSQL requiere conexiones TLS; por lo tanto, esta configuración no se usará.
  allow	El cifrado se usa si la configuración del servidor la requiere o la aplica. Azure Database for PostgreSQL requiere conexiones TLS; por lo tanto, esta configuración es equivalente a prefer.
  prefer	Se usa cifrado si la configuración del servidor lo permite. Azure Database for PostgreSQL requiere conexiones TLS.
  require	Se usa cifrado. Garantiza que el servidor está configurado para aceptar conexiones TLS.
  verify-ca	Se usa cifrado. Compruebe el certificado de servidor con los certificados raíz de confianza almacenados en el cliente.
  verify-full	Se usa cifrado. Compruebe el certificado de servidor con el certificado almacenado en el cliente. También valida que los certificados de servidor usen el mismo nombre de host que la conexión. Se recomienda esta configuración a menos que los solucionadores DNS privados usen un nombre diferente para hacer referencia al servidor de Azure Database for PostgreSQL.

El modo sslmode predeterminado usado es diferente entre los clientes basados en libpq (como PSQL y JDBC). Los clientes basados en libpq tienen prefer como valor predeterminado. JDBC los clientes tienen como valor predeterminado verify-full.

• sslcert, sslkey y sslrootcert: estos parámetros pueden invalidar la ubicación predeterminada del certificado de cliente, la clave de cliente de PKCS-8 y el certificado raíz. El valor predeterminado es /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8y /defaultdir/root.crt, respectivamente, donde defaultdir está ${user.home}/.postgresql/ en sistemas Linux y %appdata%/postgresql/ en Windows.

Instalar autoridades de certificación raíz de confianza (CAs)

Descarga y conversión de certificados de entidad de certificación raíz

Para los clientes de Windows que utilizan el almacén de certificados del sistema para los certificados raíz de confianza, no se requiere ninguna acción, ya que Windows distribuye nuevos certificados de autoridad certificadora raíz a través de Windows Update.

Para los clientes de Java, la extensión de VS Code y otros clientes (por ejemplo, PSQL, Perl, ...) que no usan el almacén del sistema y los clientes en Linux: debe descargar y combinar los certificados de autoridad certificadora raíz en un archivo PEM. Como mínimo, incluye los siguientes certificados de entidad de certificación raíz:

• Microsoft RSA Root CA 2017 (archivo crt)
• DigiCert Global Root G2 (archivo pem)

Se recomienda encarecidamente incluir todos los certificados de entidad de certificación raíz de Azure para reducir la necesidad de futuras actualizaciones en el archivo combinado si hay cambios en las CA raíz usadas por Azure Database for PostgreSQL. La lista de certificados de la Autoridad de Certificación raíz de Azure se puede encontrar en detalles de la Autoridad de Certificación de Azure.

Para importar certificados a almacenes de certificados de cliente, es posible que tenga que convertir los certificados con formato CRT al formato PEM y concatenar los archivos PEM en un único archivo. Puede usar la utilidad OpenSSL X509 para convertir los archivos CRT en PEM.

openssl x509 -inform DER -in certificate-filename.crt -out certificate-filename.pem -outform PEM

Combinar certificados de Autoridad de Certificación raíz en un único archivo PEM

Para algunos clientes, concatena todos los archivos PEM en un único archivo mediante cualquier editor de texto o herramienta de línea de comandos.

-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----

Para regiones de China, y para clientes con extensiones de rotación:

-----BEGIN CERTIFICATE-----
(Root CA0 content: DigiCertGlobalRootCA.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----

Combinación y actualización de certificados de entidad de certificación raíz para aplicaciones Java

Las aplicaciones Java escritas personalizadas usan un almacén de claves predeterminado, denominado cacerts, que contiene certificados de entidad de certificación (CA) de confianza. Un archivo de certificados denominado cacerts reside en el directorio de propiedades de seguridad, java.home\lib\security, donde java.home es el directorio del entorno en tiempo de ejecución (el directorio jre del SDK o el directorio de nivel superior del entorno en tiempo de ejecución de Java™ 2). Puede usar las siguientes indicaciones para actualizar los certificados de entidad de certificación raíz del cliente para escenarios de asignación de certificados de cliente con PostgreSQL:

1. Compruebe el almacén de claves cacerts de Java para ver si ya contiene certificados necesarios. Puede enumerar certificados en el almacén de claves de Java mediante el comando siguiente:

   keytool -list -v -keystore ..\lib\security\cacerts > outputfile.txt
   

   Si los certificados necesarios no están presentes en el almacén de claves java en el cliente, como se puede comprobar en la salida, debe continuar con las siguientes instrucciones:

2. Realice una copia de seguridad del almacén de claves personalizado.

3. Descargue los archivos de certificado y guárdelos localmente donde puede hacer referencia a ellos.

4. Genere un almacén de certificados de CA combinado con todos los certificados de CA raíz necesarios incluidos. En el siguiente ejemplo se muestra cómo los usuarios de Java pueden utilizar DefaultJavaSSLFactory para PostgreSQL.

   keytool -importcert -alias PostgreSQLServerCACert  -file "DigiCertGlobalRootG2.crt.pem" -keystore truststore -storepass password -noprompt
   
   keytool -importcert -alias PostgreSQLServerCACert2  -file "Microsoft ECC Root Certificate Authority 2017.crt.pem" -keystore truststore -storepass password  -noprompt
   
   ...
   

Actualización de certificados de entidad de certificación raíz en Azure App Services

Para los servicios de aplicaciones de Azure, al conectarse a una instancia de servidor flexible de Azure Database for PostgreSQL, podemos encontrar dos escenarios posibles para la actualización de certificados de cliente, y esto depende de cómo estés utilizando SSL con tu aplicación implementada en Azure App Services.

• Los nuevos certificados se agregan a App Service en el nivel de plataforma antes de que se produzcan cambios en la instancia de servidor flexible de Azure Database for PostgreSQL. Si usa los certificados SSL incluidos en la plataforma de App Service en la aplicación, no es necesario realizar ninguna acción. Para obtener más información, consulte Incorporación y administración de certificados TLS/SSL en Azure App Service, en la documentación de Azure App Service.
• Si incluye explícitamente la ruta de acceso al archivo de certificado SSL en el código, tendrá que descargar el nuevo certificado y actualizar el código para usarlo.

Actualización de certificados de entidad de certificación raíz al usar clientes en Azure Kubernetes Service (AKS)

Si intenta conectarse a Azure Database for PostgreSQL mediante aplicaciones hospedadas en Azure Kubernetes Services (AKS), es similar al acceso desde el entorno host de un cliente dedicado. Consulte las instrucciones detalladas en la documentación de AKS.

Actualización de certificados de entidad de certificación raíz para usuarios de .NET (Npgsql) en Windows

Para los usuarios de .NET (Npgsql) en Windows que se conectan a instancias de servidor flexible de Azure Database for PostgreSQL, asegúrese de que todos los certificados de CA raíz estén incluidos en el Almacén de certificados de Windows, en "Entidades de certificación raíz de confianza". Windows Update mantiene la lista de CA raíz de Azure estándar. Si no se incluyen certificados enumerados en nuestra configuración recomendada , importe los certificados que faltan.

Uso de TLS con validación de certificados

Algunos marcos de trabajo de aplicaciones que usan PostgreSQL para sus servicios de base de datos no habilitan TLS de manera predeterminada durante la instalación. La instancia de Azure Database for PostgreSQL aplica conexiones TLS, pero si la aplicación no está configurada para TLS, es posible que se produzca un error en la aplicación. Consulte la documentación de la aplicación para aprender a habilitar las conexiones TLS.

Conexión mediante PSQL

En el ejemplo siguiente se muestra cómo conectarse al servidor mediante la PSQL interfaz de la línea de comandos. Use la configuración de cadena de conexión sslmode=verify-full o sslmode=verify-ca para aplicar la comprobación del certificado TLS. Pase la ruta de acceso al archivo del certificado local al parámetro sslrootcert.

 psql "sslmode=verify-full sslrootcert=<path-of-pem-file> host=mydemoserver.postgres.database.azure.com dbname=postgres user=myadmin"

Prueba de la conectividad TLS

Antes de intentar acceder al servidor habilitado para TLS desde una aplicación cliente, asegúrese de que puede acceder a él a través de PSQL. Si estableció una conexión TLS, debería ver una salida similar a la del ejemplo siguiente:

psql (14.5)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

También puede cargar la extensión sslinfo y, a continuación, llamar a la ssl_is_used() función para determinar si se usa TLS. La función devuelve t si la conexión usa TLS. De lo contrario, devuelve f.

Obtención de una lista de certificados de confianza en el Almacén de claves de Java mediante programación

De manera predeterminada, Java almacena los certificados de confianza en un archivo especial denominado cacerts que se encuentra dentro de la carpeta de instalación de Java en el cliente. El ejemplo siguiente lee cacerts primero y lo carga en el objeto KeyStore:

private KeyStore loadKeyStore() {
    String relativeCacertsPath = "/lib/security/cacerts".replace("/", File.separator);
    String filename = System.getProperty("java.home") + relativeCacertsPath;
    FileInputStream is = new FileInputStream(filename);
    KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
    String password = "changeit";
    keystore.load(is, password.toCharArray());

    return keystore;
}

La contraseña predeterminada para cacerts es changeit, pero debe ser diferente en el cliente real, ya que los administradores recomiendan cambiar la contraseña inmediatamente después de la instalación de Java. Una vez cargado el objeto KeyStore, podemos usar la clase PKIXParameters para leer los certificados presentes.

public void whenLoadingCacertsKeyStore_thenCertificatesArePresent() {
    KeyStore keyStore = loadKeyStore();
    PKIXParameters params = new PKIXParameters(keyStore);
    Set<TrustAnchor> trustAnchors = params.getTrustAnchors();
    List<Certificate> certificates = trustAnchors.stream()
      .map(TrustAnchor::getTrustedCert)
      .collect(Collectors.toList());

    assertFalse(certificates.isEmpty());
}

Contenido relacionado

• Validación de la configuración del cliente y solución de problemas de errores de conexión
• Documentación de PostgreSQL.