PostgreSQL är en av de säkraste databaserna i världen. Databassäkerhet spelar en avgörande roll i verkliga uppdragskritiska miljöer. Det är viktigt att säkerställa att databaser och data alltid är säkrade och inte utsätts för obehörig åtkomst, vilket äventyrar datasäkerheten. Även om PostgreSQL tillhandahåller olika mekanismer och metoder för användare att komma åt databasen på ett säkert sätt, kan den också integreras med olika externa autentiseringssystem för att säkerställa att säkerhetskraven för företagets standarddatabas uppfylls.
Förutom att tillhandahålla säkra autentiseringsmekanismer via SSL, MD5, pgpass och pg_ident etc., kan PostgreSQL integreras med olika andra populära externa autentiseringssystem för företag. Mitt fokus i den här bloggen kommer att ligga på LDAP, Kerberos och RADIUS med SSL och pg_ident.
LDAP
LDAP hänvisar till Lightweight Directory Access Protocol som är ett populärt använt centraliserat autentiseringssystem. Det är ett datalager som lagrar användaruppgifterna och diverse andra användarrelaterade detaljer som namn, domäner, affärsenheter etc. i form av en hierarki i ett tabellformat. Slutanvändarna som ansluter till målsystemen (t.ex. en databas) måste först ansluta till LDAP-servern för att få igenom en framgångsrik autentisering. LDAP är ett av de populära autentiseringssystemen som för närvarande används i organisationer som kräver höga säkerhetsstandarder.
LDAP + PostgreSQL
PostgreSQL kan integreras med LDAP. Enligt min kundkonsulterfarenhet anses detta vara en av nyckelfunktionerna hos PostgreSQL. Eftersom autentiseringen av användarnamnet och lösenordet sker på LDAP-servern, för att säkerställa att användare kan ansluta till databasen via LDAP, måste användarkontot finnas i databasen. Med andra ord betyder detta att användarna när de försöker ansluta till PostgreSQL dirigeras till LDAP-servern först och sedan till Postgres-databasen vid framgångsrik autentisering. Konfiguration kan göras i filen pg_hba.conf för att säkerställa att anslutningar dirigeras till LDAP-servern. Nedan är ett exempel på pg_hba.conf-post -
host all pguser 0.0.0.0/0 ldap ldapserver=ldapserver.example.com ldapprefix="cn=" ldapsuffix=", dc=example, dc=com"Nedan är ett exempel på en LDAP-post i 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"När du använder icke-standard ldap-port och TLS:
ldap ldapserver=ldapserver.example.com ldaptls=1 ldapport=5128 ldapprefix="uid=" ldapsuffix=",ou=finance,dc=apix,dc=com"Förstå LDAP-posten ovan
- LDAP använder olika attribut och terminologier för att lagra/söka efter en användarpost i dess datalager. Dessutom, som nämnts ovan, lagras användarposter i hierarki.
- Ovanstående pg_hba.conf ldap-poster består av attribut som kallas CN (Common Name), OU (Organization Unit) och DC (Domain Component) som kallas Relative Distinguished Names (RDN), dessa sekvenser av RDN tillsammans blir något kallad DN (Distinguished Name). DN är det LDAP-objekt baserat som sökningen utförs i LDAP-datalagret.
- LDAP-attributvärden som CN, DC, OU etc. definieras i LDAP:s objektklasser, som kan tillhandahållas av systemexperterna som byggde LDAP-miljön.
Kommer det att göra LDAP tillräckligt säker?
Kanske inte. Lösenord som kommuniceras över nätverket i en LDAP-miljö är inte krypterade, vilket kan vara en säkerhetsrisk eftersom de krypterade lösenorden kan hackas. Det finns alternativ för att göra referenskommunikationen säkrare.
- Överväg att konfigurera LDAP på TLS (Transport Layer Security)
- LDAP kan konfigureras med SSL vilket är ett annat alternativ
Tips för att uppnå LDAP-integration med PostgreSQL
(för Linux-baserade system)
- Installera lämpliga openLDAP-moduler baserat på operativsystemversion
- Se till att PostgreSQL-programvaran är installerad med LDAP-bibliotek
- Se till att LDAP är väl integrerat med Active Directory
- Bekanta dig med alla befintliga BUGgar i de openLDAP-moduler som används. Detta kan vara katastrofalt och kan äventyra säkerhetsstandarderna.
- Windows Active Directory kan också integreras med LDAP
- Överväg att konfigurera LDAP med SSL som är säkrare. Installera lämpliga openSSL-moduler och var medveten om BUGgar som hjärtblod som kan avslöja de referenser som sänds över nätverket.
Kerberos
Kerberos är ett centraliserat autentiseringssystem av industristandard som ofta används i organisationer och tillhandahåller krypteringsbaserad autentiseringsmekanism. Lösenorden autentiseras av en tredje parts autentiseringsserver som kallas KDC (Key Distribution Centre). Lösenorden kan krypteras utifrån olika algoritmer och kan endast dekrypteras med hjälp av delade privata nycklar. Detta betyder också att lösenord som kommuniceras över nätverket är krypterade.
PostgreSQL + Kerberos
PostgreSQL stöder GSSAPI-baserad autentisering med Kerberos. Användare som försöker ansluta till Postgres-databasen kommer att dirigeras till KDC-servern för autentisering. Denna autentisering mellan klienter och KDC-databasen utförs baserat på delade privata nycklar och efter framgångsrik autentisering skulle klienterna nu ha Kerberos-baserade autentiseringsuppgifter. Samma referenser utsätts för validering mellan Postgres-servern och KDC, vilket kommer att göras baserat på keytab-filen som genereras av Kerberos. Denna keytab-fil måste finnas på databasservern med lämpliga behörigheter för användaren som äger Postgres-processen.
Kerberos-konfigurations- och anslutningsprocessen -
-
Kerberos-baserade användarkonton måste generera en biljett (en anslutningsbegäran) med kommandot "kinit".
-
En keytab-fil måste genereras med kommandot "kadmin" för ett fullt kvalificerat Kerberos-baserat användarkonto (principal) och sedan skulle Postgres använda samma keytab-fil för att validera referenserna. Principal kan krypteras och läggas till i befintlig keytab-fil med kommandot "ktadd". Kerberos-kryptering stöder olika industristandardkrypteringsalgoritmer.
Den genererade keytab-filen måste kopieras till Postgres-servern, den måste vara läsbar av Postgres-processen. Nedanstående postgresql.conf-parameter måste konfigureras:
krb_server_keyfile = '/database/postgres/keytab.example.com'Om du är särskilt intresserad av skiftlägeskänslighet, använd då parametern nedan
krb_caseins_users which is by default “off” (case sensitive) -
En post måste göras i pg_hba.conf för att säkerställa att anslutningar dirigeras till KDC-servern
Exempel pg_hba.conf-post
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COMExempel pg_hba.conf-post med kartpost
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COM map=krb -
Ett användarkonto som försöker ansluta måste läggas till i KDC-databasen som kallas principal och samma användarkonto eller ett mappningsanvändarkonto måste också finnas i databasen
Nedan är ett exempel på en Kerberos-principal
pguser är användarnamnet och "example.com" är sfärnamnet konfigurerat i Kerberos-konfigurationen (/etc/krb5.conf) i KDC-servern.
I kerberosvärlden, rektorer är i ett e-postformat ([email protected]) och databasanvändarna kan inte skapas i samma format. Detta får DBA:er att tänka på att skapa en mappning av databasanvändarnamn istället och se till att principaler ansluter till mappade namn med hjälp av pg_ident.conf.
Nedan är ett exempel på ett kartnamn i pg_ident.conf
# MAPNAME SYSTEM-USERNAME GP-USERNAME mapuser /^(.*)EXAMPLE\.DOMAIN$ admin
Kommer det att göra Kerberos tillräckligt säkrat?
Kanske inte. Användaruppgifter som kommuniceras över nätverket kan avslöjas, hackas. Även om Kerberos krypterar rektorerna kan de bli stulna, hackade. Detta medför behovet av att implementera nätverkslagersäkerhet. Ja, SSL eller TLS är vägen att gå. Kerberos autentiseringssystem kan integreras med SSL eller TLS. TLS är efterföljaren till SSL. Det rekommenderas att Kerberos konfigureras med SSL eller TLS så att kommunikationen över nätverket är säker.
TIPS
- Se till att krb*-biblioteken är installerade
- OpenSSL-bibliotek måste installeras för att konfigurera SSL
- Se till att Postgres är installerat med följande alternativ
./configure --with-gssapi --with-krb-srvnam --with-openssl
RADIUS
RADIUS är ett nätverksprotokoll för fjärrautentiseringstjänst som tillhandahåller centraliserad
Autentisering, auktorisering och redovisning (AAA). Användarnamn/lösenordspar är autentiserade på RADIUS-servern. Det här sättet för centraliserad autentisering är mycket direkt och enklare jämfört med andra autentiseringssystem som LDAP och Kerberos, vilket innebär lite komplexitet.
RADIUS + PostgreSQL
PostgreSQL kan integreras med RADIUS-autentiseringsmekanism. Bokföring stöds inte i Postgres ännu. Detta kräver att databasanvändarkonton finns i databasen. Anslutningar till databasen är auktoriserade baserat på den delade hemligheten som kallas "radiussecret".
En post i pg_hba.conf-konfigurationen är nödvändig för att dirigera anslutningarna till radiusservern för autentisering.
Exempel pg_hba.conf-post
hostssl all all 0.0.0.0/0 radius radiusserver=127.0.0.1 radiussecret=secretr radiusport=3128För att förstå posten ovan -
"radiusserver" är värd-IP-adressen för RADIUS-servern dit användarna dirigeras för autentisering. Denna parameter är konfigurerad i /etc/radiusd.conf på RADIUS-servern.
"radiussecret"-värdet extraheras från clients.conf. Detta är den hemliga koden som unikt identifierar radieklientanslutningen.
"radiusport" kan hittas i filen /etc/radiusd.conf. Detta är porten på vilken radieanslutningar kommer att lyssna.
Vikten av SSL
SSL (Secure Socket Layer) spelar en avgörande roll med externa autentiseringssystem på plats. Det rekommenderas starkt att konfigurera SSL med ett externt autentiseringssystem eftersom det kommer att finnas kommunikation av känslig information mellan klienter och servrarna över nätverket och SSL kan ytterligare skärpa säkerheten.
Prestandapåverkan av att använda externa autentiseringssystem
Ett effektivt och effektivt säkerhetssystem går på bekostnad av prestanda. Eftersom klienter/användare som försöker ansluta till databasen dirigeras till autentiseringssystem för att upprätta anslutning, kan det förekomma försämring av prestanda. Det finns sätt att övervinna prestationshinder.
- Med extern autentiseringsmekanism på plats kan det bli en fördröjning när en anslutning till databasen upprättas. Detta kan vara ett verkligt problem när det finns ett stort antal anslutningar som upprättas till databasen.
- Utvecklare måste se till att onödigt många anslutningar inte görs till databasen. Flera programförfrågningar som serveras via en anslutning skulle vara fördelaktigt.
- Också hur lång tid varje begäran tar i databasens ände spelar en viktig roll. Om begäran tar längre tid att slutföra, kommer efterföljande förfrågningar att stå i kö. Prestandajustering av processerna och noggrann utformning av infrastrukturen kommer att vara nyckeln!
- Databas och infrastruktur måste vara effektivt utformade och tillräckligt kapaciterade för att säkerställa god prestanda.
- När du gör prestandabenchmarking, se till att SSL är aktiverat och den genomsnittliga etableringstiden för anslutning måste sedan utvärderas.
Integration av externa autentiseringssystem med ClusterControl - PostgreSQL
PostgreSQL-instanser kan byggas och konfigureras automatiskt via ClusterControl GUI. Att integrera externa autentiseringssystem med PostgreSQL-instanser som distribueras via ClusterControl är ganska likt jämfört med integration med traditionella PostgreSQL-instanser och är faktiskt lite enklare. Nedan finns en översikt över samma -
- ClusterControl installerar PostgreSQL-bibliotek aktiverade med LDAP-, KRB-, GSSAPI- och OpenSSL-funktioner
- Integration med externa autentiseringssystem kräver olika parameterkonfigurationsändringar på postgresql-databasservern, vilket kan göras med ClusterControl GUI.