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

Las conexiones entre tus aplicaciones cliente y el servidor de bases de datos siempre utilizan cifrado con Seguridad de la Capa de Transporte (TLS) estándar del sector, conocida anteriormente como Secure Sockets Layer (SSL).

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

De forma predeterminada, el servidor aplica la conectividad segura entre el cliente y el servidor. Para deshabilitar este cumplimiento y permitir las comunicaciones del cliente cifradas y sin cifrar, cambie el parámetro del servidor require_secure_transport a OFF. También puede establecer la versión de TLS estableciendo el parámetro de ssl_max_protocol_version servidor. No deshabilites TLS.

Configuración de TLS de cliente

De forma predeterminada, PostgreSQL no comprueba el certificado de servidor. Debido a este comportamiento predeterminado, el cliente no puede detectar si la identidad del servidor está suplantada (por ejemplo, si alguien modifica un registro DNS o toma el control de la dirección IP del servidor). Para evitar este tipo de suplantación de identidad, habilite la comprobación del certificado TLS en el cliente.

Puede configurar muchos parámetros de conexión para la configuración de TLS del cliente. Algunos importantes incluyen:

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

• sslmode: establezca este parámetro require en si necesita cifrado y desea que se produzca un error en la conexión si no se puede cifrar. Esta configuración garantiza que el servidor esté configurado para aceptar conexiones TLS para este host o dirección IP y que el servidor reconozca 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 que no use esta configuración.
  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 que 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. Use 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 predeterminado sslmode difiere 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, sslkeyy sslrootcert: estos parámetros invalidan la ubicación predeterminada del certificado de cliente, la clave de cliente 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 implementa nuevos certificados de autoridad de certificación 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 para los clientes en Linux: debe descargar y combinar los certificados de CA raíz en un archivo PEM. Como mínimo, incluya los siguientes certificados de entidad de certificación raíz:

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

Incluya 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. Puede encontrar la lista de certificados de entidad de certificación raíz de Azure en los detalles de la entidad 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 personalizadas usan un almacén de claves predeterminado denominado cacerts, que contiene certificados de entidad de certificación (CA) de confianza. El cacerts archivo de certificados reside en el directorio de propiedades de seguridad en java.home\lib\security, donde java.home es el directorio del entorno en tiempo de ejecución (el jre directorio del SDK o el directorio de nivel superior del entorno en tiempo de ejecución de Java™ 2). Para actualizar los certificados raíz de CA del cliente para escenarios de fijación de certificados de cliente con PostgreSQL, siga las siguientes instrucciones:

1. Compruebe el almacén cacerts de claves de Java para ver si ya contiene los 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 de Java en el cliente, como puede comprobar en la salida, continúe con las instrucciones siguientes:

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 combinado de certificados de la entidad certificadora que incluya todos los certificados de la entidad certificadora raíz necesarios. En el siguiente ejemplo se muestra cómo usar DefaultJavaSSLFactory para usuarios de Java de 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 que Azure App Services se conecte a una instancia de servidor flexible de Azure Database for PostgreSQL, existen dos escenarios posibles para actualizar los certificados de cliente. Los escenarios dependen de cómo se usa SSL con la aplicación implementada en Azure App Services.

• Agregue nuevos certificados 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 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 a un archivo de certificado SSL en el código, debe 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 dentro de las 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 la 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 forma 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. En el ejemplo siguiente se lee cacerts y se carga en un 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 un cliente real. Los administradores recomiendan cambiar la contraseña inmediatamente después de la instalación de Java. Una vez cargado el objeto KeyStore , puede 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