PostgreSQL è uno dei database più sicuri al mondo. La sicurezza del database gioca un ruolo fondamentale negli ambienti mission-critical del mondo reale. È importante garantire che i database ei dati siano sempre protetti e non soggetti ad accessi non autorizzati, compromettendo così la sicurezza dei dati. Sebbene PostgreSQL fornisca vari meccanismi e metodi per consentire agli utenti di accedere al database in modo sicuro, può anche essere integrato con vari sistemi di autenticazione esterni per garantire che i requisiti di sicurezza del database standard dell'azienda siano soddisfatti.
Oltre a fornire meccanismi di autenticazione protetti tramite SSL, MD5, pgpass e pg_ident ecc., PostgreSQL può essere integrato con vari altri popolari sistemi di autenticazione esterna di livello aziendale. Il mio focus in questo blog sarà su LDAP, Kerberos e RADIUS con SSL e pg_ident.
LDAP
LDAP si riferisce a Lightweight Directory Access Protocol che è un sistema di autenticazione centralizzato comunemente usato. È un datastore che memorizza le credenziali dell'utente e vari altri dettagli relativi all'utente come nomi, domini, unità aziendali ecc. sotto forma di una gerarchia in formato tabella. Gli utenti finali che si connettono ai sistemi di destinazione (ad es. un database) devono prima connettersi al server LDAP per ottenere un'autenticazione riuscita. LDAP è uno dei più diffusi sistemi di autenticazione attualmente utilizzati dalle organizzazioni che richiedono standard di sicurezza elevati.
LDAP + PostgreSQL
PostgreSQL può essere integrato con LDAP. Nella mia esperienza di consulenza ai clienti, questa è considerata una delle funzionalità chiave di PostgreSQL. Poiché l'autenticazione del nome utente e della password avviene sul server LDAP, per garantire che gli utenti possano connettersi al database tramite LDAP, l'account utente deve esistere nel database. In altre parole, ciò significa che gli utenti quando tentano di connettersi a PostgreSQL vengono prima instradati al server LDAP e poi al database Postgres dopo l'autenticazione riuscita. La configurazione può essere effettuata nel file pg_hba.conf per garantire che le connessioni vengano instradate al server LDAP. Di seguito è riportato un esempio di voce pg_hba.conf -
host all pguser 0.0.0.0/0 ldap ldapserver=ldapserver.example.com ldapprefix="cn=" ldapsuffix=", dc=example, dc=com"Di seguito è riportato un esempio di una voce LDAP in 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"Quando si utilizza una porta ldap non predefinita e TLS:
ldap ldapserver=ldapserver.example.com ldaptls=1 ldapport=5128 ldapprefix="uid=" ldapsuffix=",ou=finance,dc=apix,dc=com"Capire la voce LDAP di cui sopra
- LDAP utilizza vari attributi e terminologie per memorizzare/cercare una voce utente nel suo datastore. Inoltre, come accennato in precedenza, le voci degli utenti sono archiviate in una gerarchia.
- Le voci ldap pg_hba.conf di cui sopra sono costituite da attributi chiamati CN (Nome comune), OU (Unità organizzativa) e DC (Componente di dominio) che, sono definiti come Relative Distinguished Names (RDN), queste sequenze di RDN insieme diventano qualcosa chiamato DN (Distinguished Name). DN è l'oggetto LDAP in base al quale la ricerca viene eseguita nell'archivio dati LDAP.
- I valori degli attributi LDAP come CN, DC, OU ecc. sono definiti nelle classi di oggetti di LDAP, che possono essere fornite dagli esperti di sistemi che hanno creato l'ambiente LDAP.
Questo renderà LDAP sufficientemente protetto?
Forse no. Le password comunicate sulla rete in un ambiente LDAP non sono crittografate, il che può rappresentare un rischio per la sicurezza poiché le password crittografate possono essere violate. Sono disponibili opzioni per rendere più sicura la comunicazione delle credenziali.
- Considera la configurazione di LDAP su TLS (Transport Layer Security)
- LDAP può essere configurato con SSL che è un'altra opzione
Suggerimenti per ottenere l'integrazione LDAP con PostgreSQL
(per sistemi basati su Linux)
- Installa i moduli openLDAP appropriati in base alla versione del sistema operativo
- Assicurati che il software PostgreSQL sia installato con le librerie LDAP
- Assicurati che LDAP sia integrato bene con Active Directory
- Familiarizzare con qualsiasi BUG esistente nei moduli openLDAP utilizzati. Questo può essere catastrofico e può compromettere gli standard di sicurezza.
- Windows Active Directory può anche essere integrato con LDAP
- Considera la configurazione di LDAP con SSL che è più sicuro. Installa i moduli openSSL appropriati e fai attenzione ai BUG come l'emorragia che può esporre le credenziali trasmesse sulla rete.
Kerberos
Kerberos è un sistema di autenticazione centralizzato standard del settore comunemente utilizzato nelle organizzazioni e fornisce un meccanismo di autenticazione basato sulla crittografia. Le password vengono autenticate da un server di autenticazione di terze parti denominato KDC (Key Distribution Center). Le password possono essere crittografate in base a vari algoritmi e possono essere decifrate solo con l'ausilio di chiavi private condivise. Ciò significa anche che le password comunicate sulla rete sono crittografate.
PostgreSQL + Kerberos
PostgreSQL supporta l'autenticazione basata su GSSAPI con Kerberos. Gli utenti che tentano di connettersi al database Postgres verranno indirizzati al server KDC per l'autenticazione. Questa autenticazione tra i client e il database KDC viene eseguita in base a chiavi private condivise e, dopo l'autenticazione riuscita, i client ora manterranno le credenziali basate su Kerberos. Le stesse credenziali sono sottoposte a validazione tra il server Postgres e il KDC che avverrà in base al file keytab generato da Kerberos. Questo file keytab deve esistere sul server del database con le autorizzazioni appropriate per l'utente che possiede il processo Postgres.
Il processo di configurazione e connessione di Kerberos -
-
Gli account utente basati su Kerberos devono generare un ticket (una richiesta di connessione) utilizzando il comando "kinit".
-
Un file keytab deve essere generato utilizzando il comando "kadmin" per un account utente completo basato su Kerberos (principale) e quindi Postgres utilizzerà lo stesso file keytab per convalidare le credenziali. I principali possono essere crittografati e aggiunti al file keytab esistente utilizzando il comando "ktadd". La crittografia Kerberos supporta vari algoritmi di crittografia standard del settore.
Il file keytab generato deve essere copiato sul server Postgres, deve essere leggibile dal processo Postgres. È necessario configurare il parametro postgresql.conf seguente:
krb_server_keyfile = '/database/postgres/keytab.example.com'Se sei particolarmente interessato alla distinzione tra maiuscole e minuscole, utilizza il parametro sottostante
krb_caseins_users which is by default “off” (case sensitive) -
È necessario inserire una voce in pg_hba.conf per garantire che le connessioni vengano instradate al server KDC
Esempio di voce pg_hba.conf
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COMEsempio di voce pg_hba.conf con voce di mappa
# 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 account utente che tenta di connettersi deve essere aggiunto al database KDC che viene definito come principale e lo stesso account utente o un account utente di mappatura deve esistere anche nel database
Di seguito è riportato un esempio di entità Kerberos
pguser è il nome utente e "example.com" è il nome del regno configurato nella configurazione di Kerberos (/etc/krb5.conf) nel server KDC.
Nel mondo kerberos, i principali sono in un formato simile a un'e-mail ([email protected]) e gli utenti del database non possono essere creati nello stesso formato. Questo fa pensare ai DBA di creare una mappatura dei nomi utente del database e assicurarsi che i principal si colleghino con i nomi mappati usando pg_ident.conf.
Di seguito è riportato un esempio di una voce di nome mappa in pg_ident.conf
# MAPNAME SYSTEM-USERNAME GP-USERNAME mapuser /^(.*)EXAMPLE\.DOMAIN$ admin
Questo renderà Kerberos abbastanza sicuro?
Forse no. Le credenziali utente comunicate in rete possono essere esposte, violate. Sebbene Kerberos crittografa i principali, possono essere rubati, hackerati. Ciò comporta la necessità di implementare la sicurezza a livello di rete. Sì, SSL o TLS è la strada da percorrere. Il sistema di autenticazione Kerberos può essere integrato con SSL o TLS. TLS è il successore di SSL. Si consiglia di configurare Kerberos con SSL o TLS in modo che la comunicazione sulla rete sia protetta.
CONSIGLI
- Assicurati che le librerie krb* siano installate
- Le librerie OpenSSL devono essere installate per configurare SSL
- Assicurati che Postgres sia installato con le seguenti opzioni
./configure --with-gssapi --with-krb-srvnam --with-openssl
RAGGIO
RADIUS è un protocollo di rete di servizi di autenticazione remota che fornisce un
centralizzatoAutenticazione, Autorizzazione e Contabilità (AAA). Le coppie nome utente/password vengono autenticate sul server RADIUS. Questo modo di autenticazione centralizzata è molto più diretto e semplice rispetto ad altri sistemi di autenticazione come LDAP e Kerberos, il che comporta un po' di complessità.
RADIUS + PostgreSQL
PostgreSQL può essere integrato con il meccanismo di autenticazione RADIUS. La contabilità non è ancora supportata in Postgres. Ciò richiede che gli account utente del database esistano nel database. Le connessioni al database sono autorizzate in base al segreto condiviso denominato "radiussecret".
Una voce nella configurazione pg_hba.conf è essenziale per instradare le connessioni al server radius per l'autenticazione.
Esempio di voce pg_hba.conf
hostssl all all 0.0.0.0/0 radius radiusserver=127.0.0.1 radiussecret=secretr radiusport=3128Per comprendere la voce di cui sopra -
"radiusserver" è l'indirizzo IP host del server RADIUS a cui gli utenti vengono indirizzati per l'autenticazione. Questo parametro è configurato in /etc/radiusd.conf nel server RADIUS.
Il valore "radiussecret" viene estratto da clients.conf. Questo è il codice segreto che identifica in modo univoco la connessione del client radio.
"radiusport" può essere trovato nel file /etc/radiusd.conf. Questa è la porta su cui saranno in ascolto le connessioni raggio.
Importanza di SSL
SSL (Secure Socket Layer) svolge un ruolo fondamentale con i sistemi di autenticazione esterni in atto. Si consiglia vivamente di configurare SSL con un sistema di autenticazione esterno poiché ci sarà comunicazione di informazioni sensibili tra client e server sulla rete e SSL può rafforzare ulteriormente la sicurezza.
Impatto sulle prestazioni dell'utilizzo di sistemi di autenticazione esterni
Un sistema di sicurezza efficace ed efficiente va a scapito delle prestazioni. Poiché i client/utenti che tentano di connettersi al database vengono instradati ai sistemi di autenticazione per stabilire la connessione, può verificarsi un degrado delle prestazioni. Esistono modi per superare gli ostacoli alle prestazioni.
- Con un meccanismo di autenticazione esterno in atto, potrebbe verificarsi un ritardo nello stabilire una connessione al database. Questa potrebbe essere una vera preoccupazione quando viene stabilito un numero enorme di connessioni al database.
- Gli sviluppatori devono assicurarsi che non venga effettuato un numero elevato di connessioni non necessarie al database. Sarebbe vantaggioso soddisfare più richieste di applicazioni tramite una connessione.
- Inoltre, il tempo impiegato da ciascuna richiesta alla fine del database gioca un ruolo importante. Se la richiesta richiede più tempo per essere completata, le richieste successive si accoderanno. L'ottimizzazione delle prestazioni dei processi e l'architettura meticolosa dell'infrastruttura saranno fondamentali!
- Il database e l'infrastruttura devono essere progettati in modo efficiente e adeguatamente abilitati per garantire buone prestazioni.
- Quando esegui il benchmarking delle prestazioni, assicurati che SSL sia abilitato e che il tempo medio di creazione della connessione debba essere quindi valutato.
Integrazione di sistemi di autenticazione esterni con ClusterControl - PostgreSQL
Le istanze PostgreSQL possono essere create e configurate automaticamente tramite la GUI di ClusterControl. L'integrazione dei sistemi di autenticazione esterni con le istanze PostgreSQL distribuite tramite ClusterControl è molto simile rispetto all'integrazione con le istanze PostgreSQL tradizionali e in effetti è un po' più semplice. Di seguito è riportata una panoramica dello stesso -
- ClusterControl installa le librerie PostgreSQL abilitate con funzionalità LDAP, KRB, GSSAPI e OpenSSL
- L'integrazione con i sistemi di autenticazione esterni richiede varie modifiche alla configurazione dei parametri sul server di database postgresql che possono essere eseguite utilizzando la GUI di ClusterControl.
