PostgreSQL est l'une des bases de données les plus sécurisées au monde. La sécurité des bases de données joue un rôle impératif dans les environnements critiques du monde réel. Il est important de s'assurer que les bases de données et les données sont toujours sécurisées et ne sont pas soumises à un accès non autorisé, compromettant ainsi la sécurité des données. Alors que PostgreSQL fournit divers mécanismes et méthodes permettant aux utilisateurs d'accéder à la base de données de manière sécurisée, il peut également être intégré à divers systèmes d'authentification externes pour garantir le respect des exigences de sécurité de base de données standard de l'entreprise.
En plus de fournir des mécanismes d'authentification sécurisés via SSL, MD5, pgpass et pg_ident, etc., PostgreSQL peut être intégré à divers autres systèmes d'authentification externes populaires de niveau entreprise. Dans ce blog, je me concentrerai sur LDAP, Kerberos et RADIUS avec SSL et pg_ident.
LDAP
LDAP fait référence à Lightweight Directory Access Protocol qui est un système d'authentification centralisé couramment utilisé. Il s'agit d'un magasin de données qui stocke les informations d'identification de l'utilisateur et divers autres détails liés à l'utilisateur tels que les noms, les domaines, les unités commerciales, etc. sous la forme d'une hiérarchie dans un format de tableau. Les utilisateurs finaux se connectant aux systèmes cibles (par exemple, une base de données) doivent d'abord se connecter au serveur LDAP pour passer une authentification réussie. LDAP est l'un des systèmes d'authentification populaires actuellement utilisés dans les organisations exigeant des normes de sécurité élevées.
LDAP + PostgreSQL
PostgreSQL peut être intégré à LDAP. Dans mon expérience de conseil client, cela est considéré comme l'une des fonctionnalités clés de PostgreSQL. Comme l'authentification du nom d'utilisateur et du mot de passe a lieu sur le serveur LDAP, pour s'assurer que les utilisateurs peuvent se connecter à la base de données via LDAP, le compte d'utilisateur doit exister dans la base de données. En d'autres termes, cela signifie que les utilisateurs qui tentent de se connecter à PostgreSQL sont d'abord acheminés vers le serveur LDAP, puis vers la base de données Postgres une fois l'authentification réussie. La configuration peut être effectuée dans le fichier pg_hba.conf pour s'assurer que les connexions sont acheminées vers le serveur LDAP. Vous trouverez ci-dessous un exemple d'entrée pg_hba.conf -
host all pguser 0.0.0.0/0 ldap ldapserver=ldapserver.example.com ldapprefix="cn=" ldapsuffix=", dc=example, dc=com"Ci-dessous un exemple d'entrée LDAP dans 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"Lors de l'utilisation d'un port ldap et de TLS autres que ceux par défaut :
ldap ldapserver=ldapserver.example.com ldaptls=1 ldapport=5128 ldapprefix="uid=" ldapsuffix=",ou=finance,dc=apix,dc=com"Comprendre l'entrée LDAP ci-dessus
- LDAP utilise divers attributs et terminologies pour stocker/rechercher une entrée d'utilisateur dans son magasin de données. De plus, comme mentionné ci-dessus, les entrées des utilisateurs sont stockées dans la hiérarchie.
- Les entrées pg_hba.conf ldap ci-dessus se composent d'attributs appelés CN (nom commun), OU (unité d'organisation) et DC (composant de domaine) qui sont appelés noms distinctifs relatifs (RDN), ces séquences de RDN deviennent ensemble quelque chose appelé DN (nom distinctif). DN est l'objet LDAP sur la base duquel la recherche est effectuée dans le magasin de données LDAP.
- Les valeurs d'attribut LDAP telles que CN, DC, OU, etc. sont définies dans les classes d'objets LDAP, qui peuvent être fournies par les experts système qui ont créé l'environnement LDAP.
Cela rendra-t-il suffisamment sécurisé LDAP ?
Peut être pas. Les mots de passe communiqués sur le réseau dans un environnement LDAP ne sont pas cryptés, ce qui peut constituer un risque pour la sécurité car les mots de passe cryptés peuvent être piratés. Il existe des options pour rendre la communication des informations d'identification plus sécurisée.
- Envisagez de configurer LDAP sur TLS (Transport Layer Security)
- LDAP peut être configuré avec SSL qui est une autre option
Conseils pour réaliser l'intégration LDAP avec PostgreSQL
(pour les systèmes basés sur Linux)
- Installez les modules openLDAP appropriés en fonction de la version du système d'exploitation
- Assurez-vous que le logiciel PostgreSQL est installé avec les bibliothèques LDAP
- Assurez-vous que LDAP est bien intégré à Active Directory
- Familiarisez-vous avec tous les bogues existants dans les modules openLDAP utilisés. Cela peut être catastrophique et compromettre les normes de sécurité.
- Windows Active Directory peut également être intégré à LDAP
- Envisagez de configurer LDAP avec SSL, qui est plus sécurisé. Installez les modules openSSL appropriés et soyez conscient des bogues comme heart-bleed qui peuvent exposer les informations d'identification transmises sur le réseau.
Kerberos
Kerberos est un système d'authentification centralisé standard de l'industrie couramment utilisé dans les organisations et fournit un mécanisme d'authentification basé sur le chiffrement. Les mots de passe sont authentifiés par un serveur d'authentification tiers appelé KDC (Key Distribution Center). Les mots de passe peuvent être chiffrés sur la base de divers algorithmes et ne peuvent être déchiffrés qu'à l'aide de clés privées partagées. Cela signifie également que les mots de passe communiqués sur le réseau sont cryptés.
PostgreSQL + Kerberos
PostgreSQL prend en charge l'authentification basée sur GSSAPI avec Kerberos. Les utilisateurs tentant de se connecter à la base de données Postgres seront acheminés vers le serveur KDC pour authentification. Cette authentification entre les clients et la base de données KDC est effectuée sur la base de clés privées partagées et une fois l'authentification réussie, les clients détiennent désormais les informations d'identification basées sur Kerberos. Les mêmes informations d'identification sont soumises à une validation entre le serveur Postgres et le KDC qui se fera sur la base du fichier keytab généré par Kerberos. Ce fichier keytab doit exister sur le serveur de base de données avec les autorisations appropriées pour l'utilisateur propriétaire du processus Postgres.
Le processus de configuration et de connexion Kerberos -
-
Les comptes d'utilisateurs basés sur Kerberos doivent générer un ticket (une demande de connexion) à l'aide de la commande "kinit".
-
Un fichier keytab doit être généré à l'aide de la commande "kadmin" pour un compte d'utilisateur entièrement qualifié basé sur Kerberos (principal), puis Postgres utilisera le même fichier keytab pour valider les informations d'identification. Les principaux peuvent être chiffrés et ajoutés au fichier keytab existant à l'aide de la commande "ktadd". Le chiffrement Kerberos prend en charge divers algorithmes de chiffrement standard de l'industrie.
Le fichier keytab généré doit être copié sur le serveur Postgres, il doit être lisible par le processus Postgres. Le paramètre postgresql.conf ci-dessous doit être configuré :
krb_server_keyfile = '/database/postgres/keytab.example.com'Si vous êtes particulièrement sensible à la casse, utilisez le paramètre ci-dessous
krb_caseins_users which is by default “off” (case sensitive) -
Une entrée doit être faite dans pg_hba.conf pour s'assurer que les connexions sont acheminées vers le serveur KDC
Exemple d'entrée pg_hba.conf
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COMExemple d'entrée pg_hba.conf avec entrée de carte
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COM map=krb -
Un compte d'utilisateur tentant de se connecter doit être ajouté à la base de données KDC qui est appelée principal et le même compte d'utilisateur ou un compte d'utilisateur de mappage doit également exister dans la base de données
Vous trouverez ci-dessous un exemple de principal Kerberos
pguser est le nom d'utilisateur et "example.com" est le nom de domaine configuré dans la configuration Kerberos (/etc/krb5.conf) sur le serveur KDC.
Dans le monde Kerberos, les principaux sont dans un format de type e-mail ([email protected]) et les utilisateurs de la base de données ne peuvent pas être créés dans le même format. Cela incite les DBA à penser à créer un mappage des noms d'utilisateur de la base de données à la place et à s'assurer que les principaux se connectent avec les noms mappés à l'aide de pg_ident.conf.
Vous trouverez ci-dessous un exemple d'entrée de nom de carte dans pg_ident.conf
# MAPNAME SYSTEM-USERNAME GP-USERNAME mapuser /^(.*)EXAMPLE\.DOMAIN$ admin
Cela rendra-t-il suffisamment sécurisé Kerberos ?
Peut être pas. Les informations d'identification des utilisateurs communiquées sur le réseau peuvent être exposées, piratées. Bien que Kerberos chiffre les principaux, ils peuvent être volés, piratés. Cela entraîne la nécessité de mettre en œuvre la sécurité de la couche réseau. Oui, SSL ou TLS est la voie à suivre. Le système d'authentification Kerberos peut être intégré à SSL ou TLS. TLS est le successeur de SSL. Il est recommandé de configurer Kerberos avec SSL ou TLS afin que la communication sur le réseau soit sécurisée.
CONSEILS
- Assurez-vous que les bibliothèques krb* sont installées
- Les bibliothèques OpenSSL doivent être installées pour configurer SSL
- Assurez-vous que Postgres est installé avec les options suivantes :
./configure --with-gssapi --with-krb-srvnam --with-openssl
RAYON
RADIUS est un protocole réseau de service d'authentification à distance qui fournit une
centraliséeAuthentification, autorisation et comptabilité (AAA). Les paires nom d'utilisateur/mot de passe sont authentifiées sur le serveur RADIUS. Cette méthode d'authentification centralisée est beaucoup plus directe et plus simple que d'autres systèmes d'authentification comme LDAP et Kerberos, ce qui implique un peu de complexité.
RAYON + PostgreSQL
PostgreSQL peut être intégré au mécanisme d'authentification RADIUS. La comptabilité n'est pas encore prise en charge dans Postgres. Cela nécessite que des comptes d'utilisateurs de base de données existent dans la base de données. Les connexions à la base de données sont autorisées sur la base du secret partagé appelé "radiussecret".
Une entrée dans la configuration pg_hba.conf est essentielle pour acheminer les connexions vers le serveur radius pour l'authentification.
Exemple d'entrée pg_hba.conf
hostssl all all 0.0.0.0/0 radius radiusserver=127.0.0.1 radiussecret=secretr radiusport=3128Pour comprendre l'entrée ci-dessus -
"radiusserver" est l'adresse IP hôte du serveur RADIUS où les utilisateurs sont acheminés pour l'authentification. Ce paramètre est configuré dans le fichier /etc/radiusd.conf du serveur RADIUS.
La valeur « radiussecret » est extraite de clients.conf. Il s'agit du code secret qui identifie de manière unique la connexion client radius.
"radiusport" se trouve dans le fichier /etc/radiusd.conf. Il s'agit du port sur lequel les connexions Radius seront à l'écoute.
Importance de SSL
SSL (Secure Socket Layer) joue un rôle impératif avec les systèmes d'authentification externes en place. Il est fortement recommandé de configurer SSL avec un système d'authentification externe car il y aura communication d'informations sensibles entre les clients et les serveurs sur le réseau et SSL peut encore renforcer la sécurité.
Impact sur les performances de l'utilisation de systèmes d'authentification externes
Un système de sécurité efficace et efficient se fait au détriment de la performance. Comme les clients/utilisateurs tentant de se connecter à la base de données sont acheminés vers des systèmes d'authentification pour établir la connexion, il peut y avoir une dégradation des performances. Il existe des moyens de surmonter les obstacles de performance.
- Avec un mécanisme d'authentification externe en place, il peut y avoir un retard lors de l'établissement d'une connexion à la base de données. Cela peut être un réel problème lorsqu'un grand nombre de connexions sont établies avec la base de données.
- Les développeurs doivent s'assurer qu'un nombre inutilement élevé de connexions ne sont pas établies avec la base de données. Plusieurs demandes d'application traitées via une seule connexion seraient avantageuses.
- En outre, la durée de chaque requête au niveau de la base de données joue un rôle important. Si la demande prend plus de temps à se terminer, les demandes suivantes seront mises en file d'attente. L'optimisation des performances des processus et l'architecture méticuleuse de l'infrastructure seront essentielles !
- La base de données et l'infrastructure doivent être conçues de manière efficace et dotées de capacités adéquates pour garantir de bonnes performances.
- Lors de l'analyse comparative des performances, assurez-vous que SSL est activé et que le temps moyen d'établissement de la connexion doit ensuite être évalué.
Intégration de systèmes d'authentification externes avec ClusterControl - PostgreSQL
Les instances PostgreSQL peuvent être créées et configurées automatiquement via l'interface graphique ClusterControl. L'intégration de systèmes d'authentification externes avec des instances PostgreSQL déployées via ClusterControl est à peu près similaire à l'intégration avec des instances PostgreSQL traditionnelles et est en fait un peu plus simple. Vous trouverez ci-dessous un aperçu de la même -
- ClusterControl installe les bibliothèques PostgreSQL activées avec les fonctionnalités LDAP, KRB, GSSAPI et OpenSSL
- L'intégration avec des systèmes d'authentification externes nécessite diverses modifications de la configuration des paramètres sur le serveur de base de données postgresql, qui peuvent être effectuées à l'aide de l'interface graphique de ClusterControl.
