Conexión con PostgreSQL
El establecimiento de conexiones seguras a Azure Database for PostgreSQL requiere comprender los componentes de cadena de conexión, las opciones de autenticación y la configuración de seguridad de la capa de transporte. En el caso de las aplicaciones de inteligencia artificial que suelen leer y escribir datos, obtener la configuración de conexión directamente desde el principio impide errores de autenticación y vulnerabilidades de seguridad en producción.
Aspectos básicos de la conexión
Las conexiones de PostgreSQL requieren varios parámetros que identifican las credenciales de servidor, base de datos y usuario. Azure Database for PostgreSQL usa un formato de punto de conexión específico y aplica el transporte seguro de forma predeterminada.
El punto de conexión del servidor sigue el patrón <server-name>.postgres.database.azure.com, donde <server-name> es el nombre único que especificó al crear el servidor. El nombre de dominio completo (FQDN) se resuelve en la dirección IP pública del servidor cuando se utiliza acceso público, o en una dirección IP privada cuando se utiliza la integración con la red virtual (VNet).
Una conexión de PostgreSQL requiere estos parámetros principales: el host (FQDN del servidor), el puerto (5432 para conexiones directas o 6432 para PgBouncer), el nombre de base de datos, el nombre de usuario (para la autenticación entra, el formato de uso username@servername ), la contraseña (token estático o Entra) y el modo SSL. Las distintas bibliotecas y herramientas de cliente aceptan estos parámetros en varios formatos, incluidas cadenas de conexión, pares de palabra clave-valor o parámetros individuales.
Métodos de autenticación
Azure Database for PostgreSQL admite dos enfoques de autenticación: la autenticación de Microsoft Entra proporciona una mayor seguridad a través del acceso basado en tokens, mientras que la autenticación nativa de PostgreSQL usa credenciales tradicionales de nombre de usuario y contraseña.
La autenticación de Microsoft Entra usa tokens de OAuth 2.0 en lugar de contraseñas. Este enfoque se integra con la plataforma de identidad de Azure y proporciona administración de identidades centralizada, elimina el almacenamiento de contraseñas (los tokens son de corta duración), admite identidades administradas para aplicaciones hospedadas en Azure y crea pistas de auditoría en los registros de inicio de sesión de Entra. Para usar la autenticación entra, configure un administrador de Microsoft Entra en el servidor (una cuenta de usuario, un grupo o una entidad de servicio). Una vez configuradas, las identidades Entra se conectan obteniendo un token del recurso https://ossrdbms-aad.database.windows.net.
El proceso de conexión funciona de la siguiente manera:
- La aplicación solicita un token de acceso desde el identificador de Microsoft Entra.
- Entra valida la identidad y devuelve un token.
- La aplicación se conecta a PostgreSQL mediante el token como contraseña.
- PostgreSQL valida el token contra el administrador de Entra configurado.
En Python, puede usar la azure-identity biblioteca para obtener tokens:
from azure.identity import DefaultAzureCredential
credential = DefaultAzureCredential()
token = credential.get_token("https://ossrdbms-aad.database.windows.net/.default")
# Use token.token as the password in your connection string
La DefaultAzureCredential clase intenta automáticamente varios métodos de autenticación en orden, incluida la identidad administrada (cuando se ejecuta en Azure), las credenciales de la CLI de Azure (para el desarrollo local) y otras opciones.
La autenticación nativa de PostgreSQL almacena nombres de usuario y contraseñas cifradas en la base de datos. Este enfoque es adecuado cuando las aplicaciones no pueden usar la autenticación Entra (aplicaciones heredadas), es necesario conceder acceso a identidades fuera de tu inquilino de Entra, o si se ejecuta en un entorno sin conectividad de Azure durante el desarrollo. Al usar la autenticación de PostgreSQL, almacene contraseñas en Azure Key Vault en lugar de la configuración de la aplicación, gire las contraseñas periódicamente, use contraseñas seguras generadas aleatoriamente y limite los permisos de cada usuario de base de datos. El nombre de usuario y la contraseña de administrador que especifique durante la creación del servidor usan la autenticación de PostgreSQL.
Configuración de TLS/SSL
Azure Database for PostgreSQL cifra todas las conexiones mediante la seguridad de la capa de transporte (TLS). El servidor requiere TLS de forma predeterminada y admite TLS 1.2 y 1.3. Se rechazan las conexiones que usan versiones anteriores de TLS.
Los clientes de PostgreSQL usan el parámetro para controlar el sslmode cifrado y la validación de certificados. Los modos disponibles son:
- disable: Sin cifrado. Azure rechaza las conexiones mediante este modo.
- conceder: Cifra si el servidor lo requiere, pero no valida los certificados.
- preferir: Cifra si el servidor lo admite, pero no valida los certificados.
- require: Aplica el cifrado, pero no valida los certificados.
- verify-ca: Aplica el cifrado y valida el certificado de servidor en entidades de certificación de confianza.
- verify-full: Aplica el cifrado, valida la ENTIDAD de certificación y confirma que el nombre de host del certificado coincide con el servidor.
En el caso de las aplicaciones de producción, use verify-full para asegurarse de que se conecta al servidor de Azure PostgreSQL original. Este modo valida que el servidor presenta un certificado firmado por una entidad de certificación de confianza y que el nombre alternativo del firmante o el nombre común del certificado coinciden con el nombre de host del servidor.
Los modos verify-ca y verify-full requieren que el cliente tenga acceso a los certificados raíz de la CA que han firmado el certificado del servidor. La mayoría de los sistemas operativos y los entornos de hospedaje de Azure ya incluyen las CA raíz de DigiCert y Microsoft que usa Azure Database for PostgreSQL. Si se produce un error en la validación de certificados, es posible que tenga que descargar los certificados raíz del repositorio PKI de Microsoft y configurar el cliente para usarlos.
Agrupación de conexiones con PgBouncer
Azure Database for PostgreSQL incluye PgBouncer integrado, que puede habilitar a través de la configuración del servidor en Azure Portal o mediante la CLI de Azure. Una vez habilitado, conéctese en el puerto 6432 en lugar de 5432.
Importante
PgBouncer solo está disponible en los niveles de procesamiento de uso general y optimizado para memoria. Si el servidor usa el nivel ampliable, no puede habilitar el PgBouncer integrado.
PgBouncer mantiene un grupo de conexiones con el servidor de bases de datos y multiplexa las conexiones de los clientes en este grupo. Esto reduce la sobrecarga del establecimiento de conexiones, que es útil para las aplicaciones que realizan muchas conexiones de corta duración.
Para habilitar PgBouncer mediante la CLI de Azure:
az postgres flexible-server parameter set \
--resource-group myResourceGroup \
--server-name myserver \
--name pgbouncer.enabled \
--value true
Después de habilitar, actualice la cadena de conexión para usar el puerto 6432:
postgresql://user@myserver.postgres.database.azure.com:6432/mydb?sslmode=require
Las estrategias de optimización de agrupaciones de conexiones, incluidos el ajuste de tamaño del grupo y la transacción frente a los modos de sesión, se tratan en el módulo "Optimización del rendimiento, la indexación y el escalado".
Consideraciones sobre el acceso a la red
Azure Database for PostgreSQL admite dos modelos de red: acceso público con reglas de firewall y acceso privado con integración con red virtual. El equipo de plataforma o operaciones suele configurar estas opciones, pero comprenderlas ayuda a solucionar problemas de conexión.
Con el acceso público, el servidor tiene una dirección IP pública y reglas de firewall que controlan qué direcciones IP de cliente pueden conectarse. Si no puede conectarse desde la máquina de desarrollo, compruebe que la dirección IP está permitida en las reglas de firewall.
Con el acceso privado, el servidor solo tiene una dirección IP privada dentro de una instancia de Azure Virtual Network. Solo puede conectarse desde recursos dentro de la misma red virtual, redes emparejadas o a través de VPN/ExpressRoute. El acceso privado es común en entornos de producción en los que se requiere aislamiento de red.
Ejemplos de cadena de conexión
En los ejemplos siguientes se muestran patrones de cadena de conexión comunes para Azure Database for PostgreSQL.
# Basic connection with SSL required
postgresql://myuser:mypassword@myserver.postgres.database.azure.com/mydb?sslmode=require
# Connection with certificate verification
postgresql://myuser:mypassword@myserver.postgres.database.azure.com/mydb?sslmode=verify-full&sslrootcert=/etc/ssl/certs/ca-certificates.crt
# Connection through PgBouncer (note port 6432)
postgresql://myuser:mypassword@myserver.postgres.database.azure.com:6432/mydb?sslmode=require