PostgreSQL es una de las bases de datos más seguras del mundo. La seguridad de la base de datos juega un papel imperativo en los entornos de misión crítica del mundo real. Es importante garantizar que las bases de datos y los datos estén siempre protegidos y que no estén sujetos a accesos no autorizados, lo que compromete la seguridad de los datos. Si bien PostgreSQL proporciona varios mecanismos y métodos para que los usuarios accedan a la base de datos de manera segura, también se puede integrar con varios sistemas de autenticación externos para garantizar que se cumplan los requisitos de seguridad de la base de datos estándar de la empresa.
Además de proporcionar mecanismos de autenticación seguros a través de SSL, MD5, pgpass y pg_ident, etc., PostgreSQL se puede integrar con varios otros sistemas de autenticación externos populares de nivel empresarial. Mi enfoque en este blog estará en LDAP, Kerberos y RADIUS con SSL y pg_ident.
LDAP
LDAP se refiere al Protocolo ligero de acceso a directorios, que es un sistema de autenticación centralizado de uso popular. Es un almacén de datos que almacena las credenciales del usuario y varios otros detalles relacionados con el usuario, como nombres, dominios, unidades comerciales, etc. en forma de jerarquía en formato de tabla. Los usuarios finales que se conectan a los sistemas de destino (por ejemplo, una base de datos) primero deben conectarse al servidor LDAP para obtener una autenticación exitosa. LDAP es uno de los sistemas de autenticación populares que se utilizan actualmente en las organizaciones que exigen altos estándares de seguridad.
LDAP + PostgreSQL
PostgreSQL se puede integrar con LDAP. En mi experiencia de consultoría de clientes, esto se considera una de las capacidades clave de PostgreSQL. Dado que la autenticación del nombre de usuario y la contraseña se lleva a cabo en el servidor LDAP, para garantizar que los usuarios puedan conectarse a la base de datos a través de LDAP, la cuenta de usuario debe existir en la base de datos. En otras palabras, esto significa que los usuarios cuando intentan conectarse a PostgreSQL son enrutados primero al servidor LDAP y luego a la base de datos de Postgres luego de una autenticación exitosa. La configuración se puede realizar en el archivo pg_hba.conf para garantizar que las conexiones se enruten al servidor LDAP. A continuación se muestra una entrada de pg_hba.conf de muestra -
host all pguser 0.0.0.0/0 ldap ldapserver=ldapserver.example.com ldapprefix="cn=" ldapsuffix=", dc=example, dc=com"A continuación se muestra un ejemplo de una entrada LDAP en pg_hba.conf:
host all pguser 0.0.0.0/0 ldap ldapserver=ldapserver.example.com ldapprefix="cn=" ldapsuffix=", ou=finance, dc=example, dc=com"Al usar un puerto ldap no predeterminado y TLS:
ldap ldapserver=ldapserver.example.com ldaptls=1 ldapport=5128 ldapprefix="uid=" ldapsuffix=",ou=finance,dc=apix,dc=com"Comprender la entrada LDAP anterior
- LDAP utiliza varios atributos y terminologías para almacenar/buscar una entrada de usuario en su almacén de datos. Además, como se mencionó anteriormente, las entradas de los usuarios se almacenan en jerarquía.
- Las entradas pg_hba.conf ldap anteriores consisten en atributos llamados CN (Nombre común), OU (Unidad organizativa) y DC (Componente de dominio) que, se denominan Nombres distintivos relativos (RDN), esta secuencia de RDN juntos se convierte en algo llamado DN (Nombre Distinguido). DN es el objeto LDAP basado en el cual, la búsqueda se realiza en el almacén de datos LDAP.
- Los valores de atributos de LDAP como CN, DC, OU, etc. se definen en las clases de objetos de LDAP, que pueden proporcionar los expertos en sistemas que crearon el entorno de LDAP.
¿Eso hará que LDAP sea lo suficientemente seguro?
Tal vez no. Las contraseñas comunicadas a través de la red en un entorno LDAP no están encriptadas, lo que puede ser un riesgo de seguridad ya que las contraseñas encriptadas pueden ser pirateadas. Hay opciones para hacer que la comunicación de credenciales sea más segura.
- Considere configurar LDAP en TLS (Transport Layer Security)
- LDAP se puede configurar con SSL, que es otra opción
Consejos para lograr la integración de LDAP con PostgreSQL
(para sistemas basados en Linux)
- Instalar los módulos openLDAP apropiados según la versión del sistema operativo
- Asegúrese de que el software PostgreSQL esté instalado con bibliotecas LDAP
- Asegúrese de que LDAP esté bien integrado con Active Directory
- Familiarícese con cualquier BUG existente en los módulos openLDAP que se utilizan. Esto puede ser catastrófico y puede comprometer los estándares de seguridad.
- Windows Active Directory también se puede integrar con LDAP
- Considere configurar LDAP con SSL, que es más seguro. Instale los módulos openSSL apropiados y tenga cuidado con los BUG como heart-bleed que pueden exponer las credenciales transmitidas a través de la red.
Kerberos
Kerberos es un sistema de autenticación centralizado estándar de la industria que se usa popularmente en organizaciones y proporciona un mecanismo de autenticación basado en cifrado. Las contraseñas son autenticadas por un servidor de autenticación de terceros denominado KDC (Centro de distribución de claves). Las contraseñas se pueden cifrar en función de varios algoritmos y solo se pueden descifrar con la ayuda de claves privadas compartidas. Esto también significa que las contraseñas comunicadas a través de la red están encriptadas.
PostgreSQL + Kerberos
PostgreSQL admite la autenticación basada en GSSAPI con Kerberos. Los usuarios que intenten conectarse a la base de datos de Postgres serán enrutados al servidor KDC para la autenticación. Esta autenticación entre los clientes y la base de datos de KDC se realiza en base a claves privadas compartidas y, tras una autenticación exitosa, los clientes ahora tendrían credenciales basadas en Kerberos. Las mismas credenciales están sujetas a validación entre el servidor de Postgres y el KDC, que se realizará en función del archivo keytab generado por Kerberos. Este archivo keytab debe existir en el servidor de la base de datos con los permisos apropiados para el usuario propietario del proceso de Postgres.
El proceso de configuración y conexión de Kerberos -
-
Las cuentas de usuario basadas en Kerberos deben generar un ticket (una solicitud de conexión) mediante el comando "kinit".
-
Se debe generar un archivo keytab usando el comando "kadmin" para una cuenta de usuario basada en Kerberos completamente calificada (principal) y luego Postgres usaría el mismo archivo keytab para validar las credenciales. Los principales se pueden cifrar y agregar al archivo keytab existente usando el comando "ktadd". El cifrado Kerberos es compatible con varios algoritmos de cifrado estándar de la industria.
El archivo keytab generado debe copiarse en el servidor de Postgres, debe ser legible por el proceso de Postgres. Se debe configurar el siguiente parámetro postgresql.conf:
krb_server_keyfile = '/database/postgres/keytab.example.com'Si le interesa la distinción entre mayúsculas y minúsculas, utilice el siguiente parámetro
krb_caseins_users which is by default “off” (case sensitive) -
Se debe realizar una entrada en pg_hba.conf para garantizar que las conexiones se enruten al servidor KDC
Ejemplo de entrada pg_hba.conf
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COMEjemplo de entrada pg_hba.conf con entrada de mapa
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COM map=krb -
Se debe agregar una cuenta de usuario que intente conectarse a la base de datos de KDC, que se denomina principal y la misma cuenta de usuario o una cuenta de usuario de asignación también debe existir en la base de datos
A continuación se muestra un ejemplo de un principal de Kerberos
pguser es el nombre de usuario y “example.com” es el nombre de dominio configurado en la configuración de Kerberos (/etc/krb5.conf) en el servidor KDC.
En el mundo de Kerberos, directores están en formato de correo electrónico ([email protected]) y los usuarios de la base de datos no se pueden crear en el mismo formato. Esto hace que los administradores de bases de datos piensen en crear una asignación de nombres de usuario de la base de datos y se aseguren de que los directores se conecten con los nombres asignados mediante pg_ident.conf.
A continuación se muestra un ejemplo de una entrada de nombre de mapa en pg_ident.conf
# MAPNAME SYSTEM-USERNAME GP-USERNAME mapuser /^(.*)EXAMPLE\.DOMAIN$ admin
¿Eso hará que Kerberos sea lo suficientemente seguro?
Tal vez no. Las credenciales de usuario comunicadas a través de la red pueden exponerse, piratearse. Aunque Kerberos encripta los principales, pueden ser robados o pirateados. Esto trae consigo la necesidad de implementar la seguridad de la capa de red. Sí, SSL o TLS es el camino a seguir. El sistema de autenticación Kerberos se puede integrar con SSL o TLS. TLS es el sucesor de SSL. Se recomienda tener Kerberos configurado con SSL o TLS para que la comunicación a través de la red sea segura.
CONSEJOS
- Asegúrese de que las bibliotecas krb* estén instaladas
- Las bibliotecas OpenSSL deben estar instaladas para configurar SSL
- Asegúrese de que Postgres esté instalado con las siguientes opciones
./configure --with-gssapi --with-krb-srvnam --with-openssl
RADIO
RADIUS es un protocolo de red de servicio de autenticación remota que proporciona
Autenticación, Autorización y Contabilidad (AAA). Los pares de nombre de usuario/contraseña se autentican en el servidor RADIUS. Esta forma de autenticación centralizada es mucho más directa y simple en comparación con otros sistemas de autenticación como LDAP y Kerberos, lo que implica un poco de complejidad.
RADIO + PostgreSQL
PostgreSQL se puede integrar con el mecanismo de autenticación RADIUS. La contabilidad aún no es compatible con Postgres. Esto requiere que existan cuentas de usuario de base de datos en la base de datos. Las conexiones a la base de datos están autorizadas en base al secreto compartido denominado "radiussecret".
Una entrada en la configuración pg_hba.conf es esencial para enrutar las conexiones al servidor Radius para la autenticación.
Ejemplo de entrada pg_hba.conf
hostssl all all 0.0.0.0/0 radius radiusserver=127.0.0.1 radiussecret=secretr radiusport=3128Para entender la entrada anterior -
“radiusserver” es la dirección IP del host del servidor RADIUS donde se enrutan los usuarios para la autenticación. Este parámetro se configura en /etc/radiusd.conf en el servidor RADIUS.
El valor "radiussecret" se extrae de clients.conf. Este es el código secreto que identifica de forma única la conexión del cliente Radius.
“radiusport” se puede encontrar en el archivo /etc/radiusd.conf. Este es el puerto en el que escucharán las conexiones de radio.
Importancia de SSL
SSL (Secure Socket Layer) juega un papel imperativo con los sistemas de autenticación externos implementados. Se recomienda encarecidamente configurar SSL con un sistema de autenticación externo, ya que habrá comunicación de información confidencial entre los clientes y los servidores a través de la red y SSL puede reforzar aún más la seguridad.
Impacto en el rendimiento del uso de sistemas de autenticación externos
Un sistema de seguridad eficaz y eficiente se logra a expensas del rendimiento. Como los clientes/usuarios que intentan conectarse a la base de datos se enrutan a los sistemas de autenticación para establecer la conexión, puede haber una degradación del rendimiento. Hay formas de superar los obstáculos de rendimiento.
- Con un mecanismo de autenticación externo implementado, podría haber un retraso al establecer una conexión con la base de datos. Esto podría ser una preocupación real cuando se establece una gran cantidad de conexiones a la base de datos.
- Los desarrolladores deben asegurarse de que no se realice una gran cantidad de conexiones innecesarias a la base de datos. Sería ventajoso atender varias solicitudes de aplicaciones a través de una conexión.
- Además, el tiempo que demora cada solicitud al final de la base de datos juega un papel importante. Si la solicitud tarda más en completarse, las solicitudes posteriores se pondrán en cola. ¡El ajuste del rendimiento de los procesos y la arquitectura meticulosa de la infraestructura serán clave!
- La base de datos y la infraestructura deben tener una arquitectura eficiente y estar adecuadamente capacitadas para garantizar un buen rendimiento.
- Al realizar evaluaciones comparativas de rendimiento, asegúrese de que SSL esté habilitado y luego se debe evaluar el tiempo promedio de establecimiento de la conexión.
Integración de sistemas de autenticación externos con ClusterControl - PostgreSQL
Las instancias de PostgreSQL se pueden construir y configurar automáticamente a través de la GUI de ClusterControl. La integración de sistemas de autenticación externos con instancias de PostgreSQL implementadas a través de ClusterControl es bastante similar en comparación con la integración con instancias de PostgreSQL tradicionales y, de hecho, es un poco más simple. A continuación se muestra una descripción general de la misma -
- ClusterControl instala bibliotecas PostgreSQL habilitadas con capacidades LDAP, KRB, GSSAPI y OpenSSL
- La integración con sistemas de autenticación externos requiere varios cambios de configuración de parámetros en el servidor de base de datos postgresql que se pueden realizar mediante la interfaz gráfica de usuario de ClusterControl.
