PostgreSQL er en af de mest sikre databaser i verden. Databasesikkerhed spiller en afgørende rolle i de virkelige missionskritiske miljøer. Det er vigtigt at sikre, at databaser og data altid er sikret og ikke udsættes for uautoriseret adgang, hvilket kompromitterer datasikkerheden. Mens PostgreSQL tilbyder forskellige mekanismer og metoder til, at brugere kan få adgang til databasen på en sikker måde, kan den også integreres med forskellige eksterne godkendelsessystemer for at sikre, at virksomhedens standarddatabasesikkerhedskrav er opfyldt.
Udover at levere sikrede autentificeringsmekanismer via SSL, MD5, pgpass og pg_ident osv., kan PostgreSQL integreres med forskellige andre populære eksterne autentificeringssystemer i virksomhedskvalitet. Mit fokus i denne blog vil være på LDAP, Kerberos og RADIUS med SSL og pg_ident.
LDAP
LDAP refererer til Lightweight Directory Access Protocol, som er et populært brugt centraliseret autentificeringssystem. Det er et datalager, som gemmer brugeroplysningerne og forskellige andre brugerrelaterede detaljer som navne, domæner, forretningsenheder osv. i form af et hierarki i et tabelformat. Slutbrugerne, der opretter forbindelse til målsystemerne (f.eks. en database), skal først oprette forbindelse til LDAP-serveren for at komme igennem en vellykket godkendelse. LDAP er et af de populære godkendelsessystemer, der i øjeblikket bruges på tværs af organisationer, der kræver høje sikkerhedsstandarder.
LDAP + PostgreSQL
PostgreSQL kan integreres med LDAP. I min kunderådgivningserfaring betragtes dette som en af nøglefunktionerne i PostgreSQL. Da autentificeringen af brugernavnet og adgangskoden finder sted på LDAP-serveren, skal brugerkontoen eksistere i databasen for at sikre, at brugere kan oprette forbindelse til databasen via LDAP. Med andre ord betyder det, at brugerne, når de forsøger at oprette forbindelse til PostgreSQL, bliver dirigeret til LDAP-serveren først og derefter til Postgres-databasen efter vellykket godkendelse. Konfiguration kan foretages i filen pg_hba.conf for at sikre, at forbindelser dirigeres til LDAP-serveren. Nedenfor er et eksempel på pg_hba.conf-indgang -
host all pguser 0.0.0.0/0 ldap ldapserver=ldapserver.example.com ldapprefix="cn=" ldapsuffix=", dc=example, dc=com"
Nedenfor er et eksempel på en LDAP-indgang 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"
Ved brug af ikke-standard ldap-port og TLS:
ldap ldapserver=ldapserver.example.com ldaptls=1 ldapport=5128 ldapprefix="uid=" ldapsuffix=",ou=finance,dc=apix,dc=com"
Forstå ovenstående LDAP-indgang
- LDAP bruger forskellige attributter og terminologier til at gemme/søge efter en brugerpost i dets datalager. Som nævnt ovenfor er brugerindtastninger gemt i hierarki.
- Ovenstående pg_hba.conf ldap-indgange består af attributter kaldet CN (Common Name), OU (Organization Unit) og DC (Domain Component), som betegnes som Relative Distinguished Names (RDN), disse sekvenser af RDN sammen bliver noget kaldet DN (Distinguished Name). DN er det LDAP-objekt baseret, som søgningen udføres i LDAP-datalageret.
- LDAP-attributværdier som CN, DC, OU osv. er defineret i LDAPs objektklasser, som kan leveres af de systemeksperter, der byggede LDAP-miljøet.
Vil det gøre LDAP sikret nok?
Måske ikke. Adgangskoder, der kommunikeres over netværket i et LDAP-miljø, er ikke krypteret, hvilket kan være en sikkerhedsrisiko, da de krypterede adgangskoder kan blive hacket. Der er muligheder for at gøre legitimationsoplysningerne mere sikker.
- Overvej at konfigurere LDAP på TLS (Transport Layer Security)
- LDAP kan konfigureres med SSL, hvilket er en anden mulighed
Tips til at opnå LDAP-integration med PostgreSQL
(til Linux-baserede systemer)
- Installer passende openLDAP-moduler baseret på operativsystemversion
- Sørg for, at PostgreSQL-softwaren er installeret med LDAP-biblioteker
- Sørg for, at LDAP er godt integreret med Active Directory
- Gør dig bekendt med eventuelle eksisterende BUG'er i de openLDAP-moduler, der bruges. Dette kan være katastrofalt og kan kompromittere sikkerhedsstandarderne.
- Windows Active Directory kan også integreres med LDAP
- Overvej at konfigurere LDAP med SSL, som er mere sikkert. Installer passende openSSL-moduler, og vær opmærksom på BUG'er som hjerteblod, der kan afsløre de legitimationsoplysninger, der sendes over netværket.
Kerberos
Kerberos er et industristandard centraliseret godkendelsessystem, der populært bruges i organisationer og giver krypteringsbaseret godkendelsesmekanisme. Adgangskoden er godkendt af en tredjeparts godkendelsesserver kaldet KDC (Key Distribution Centre). Adgangskoderne kan krypteres baseret på forskellige algoritmer og kan kun dekrypteres ved hjælp af delte private nøgler. Dette betyder også, at adgangskoder, der kommunikeres over netværket, er krypteret.
PostgreSQL + Kerberos
PostgreSQL understøtter GSSAPI-baseret godkendelse med Kerberos. Brugere, der forsøger at oprette forbindelse til Postgres-databasen, vil blive dirigeret til KDC-serveren for godkendelse. Denne autentificering mellem klienter og KDC-databasen udføres baseret på delte private nøgler, og efter vellykket godkendelse vil klienterne nu have Kerberos-baserede legitimationsoplysninger. De samme legitimationsoplysninger er underlagt validering mellem Postgres-serveren og KDC, hvilket vil blive gjort baseret på keytab-filen genereret af Kerberos. Denne keytab-fil skal eksistere på databaseserveren med passende tilladelser til brugeren, der ejer Postgres-processen.
Kerberos-konfigurations- og forbindelsesprocessen -
-
Kerberos-baserede brugerkonti skal generere en billet (en forbindelsesanmodning) ved hjælp af kommandoen "kinit".
-
En keytab-fil skal genereres ved hjælp af "kadmin"-kommandoen for en fuldt kvalificeret Kerberos-baseret brugerkonto (principal), og derefter vil Postgres bruge den samme keytab-fil til at validere legitimationsoplysningerne. Principaler kan krypteres og tilføjes til eksisterende keytab-fil ved hjælp af kommandoen "ktadd". Kerberos-kryptering understøtter forskellige industristandardkrypteringsalgoritmer.
Den genererede keytab-fil skal kopieres over til Postgres-serveren, den skal kunne læses af Postgres-processen. Nedenstående postgresql.conf parameter skal konfigureres:
krb_server_keyfile = '/database/postgres/keytab.example.com'
Hvis du er særlig opmærksom på store og små bogstaver, så brug nedenstående parameter
krb_caseins_users which is by default “off” (case sensitive)
-
Der skal foretages en indtastning i pg_hba.conf for at sikre, at forbindelser dirigeres til KDC-serveren
Eksempel pg_hba.conf-indgang
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COM
Eksempel pg_hba.conf-indgang med kortindtastning
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COM map=krb
-
En brugerkonto, der forsøger at oprette forbindelse, skal tilføjes til KDC-databasen, som betegnes som principal, og den samme brugerkonto eller en kortlægningsbrugerkonto skal også eksistere i databasen
Nedenfor er et eksempel på en Kerberos-principal
pguser er brugernavnet, og "example.com" er realm-navnet, der er konfigureret i Kerberos-konfigurationen (/etc/krb5.conf) på KDC-serveren.
I kerberos-verdenen, rektorer er i et e-mail-lignende format ([email protected]), og databasebrugerne kan ikke oprettes i samme format. Dette får DBA'er til at tænke på at oprette en kortlægning af databasebrugernavne i stedet for og sikre, at principalerne forbinder med tilknyttede navne ved hjælp af pg_ident.conf.
Nedenfor er et eksempel på en kortnavnindtastning i pg_ident.conf
# MAPNAME SYSTEM-USERNAME GP-USERNAME mapuser /^(.*)EXAMPLE\.DOMAIN$ admin
Vil det gøre Kerberos sikret nok?
Måske ikke. Brugerlegitimationsoplysninger, der kommunikeres over netværket, kan blive afsløret, hacket. Selvom Kerberos krypterer principperne, kan de blive stjålet, hacket. Dette medfører behovet for at implementere netværkslagssikkerhed. Ja, SSL eller TLS er vejen at gå. Kerberos-godkendelsessystem kan integreres med SSL eller TLS. TLS er efterfølgeren til SSL. Det anbefales at have Kerberos konfigureret med SSL eller TLS, så kommunikationen over netværket er sikret.
TIPS
- Sørg for, at krb*-biblioteker er installeret
- OpenSSL-biblioteker skal være installeret for at konfigurere SSL
- Sørg for, at Postgres er installeret med følgende muligheder
./configure --with-gssapi --with-krb-srvnam --with-openssl
RADIUS
RADIUS er en netværksprotokol for fjerngodkendelsestjeneste, som giver centraliseret
Autentificering, autorisation og regnskab (AAA). Brugernavn/adgangskode-par godkendes på RADIUS-serveren. Denne måde at centraliseret godkendelse på er meget ligetil og enklere sammenlignet med andre godkendelsessystemer som LDAP og Kerberos, som involverer en smule kompleksitet.
RADIUS + PostgreSQL
PostgreSQL kan integreres med RADIUS-godkendelsesmekanisme. Regnskab er ikke understøttet i Postgres endnu. Dette kræver, at der findes databasebrugerkonti i databasen. Forbindelser til databasen er autoriseret baseret på den delte hemmelighed kaldet "radiussecret".
En indgang i pg_hba.conf-konfigurationen er vigtig for at dirigere forbindelserne til radiusserveren for godkendelse.
Eksempel pg_hba.conf-indgang
hostssl all all 0.0.0.0/0 radius radiusserver=127.0.0.1 radiussecret=secretr radiusport=3128
For at forstå ovenstående post -
"radiusserver" er værts-IP-adressen på RADIUS-serveren, hvorfra brugere dirigeres til godkendelse. Denne parameter er konfigureret i /etc/radiusd.conf på RADIUS-serveren.
"radiussecret" værdi er udtrukket fra clients.conf. Dette er den hemmelige kode, som entydigt identificerer radiusklientforbindelsen.
"radiusport" kan findes i filen /etc/radiusd.conf. Dette er porten, hvor radiusforbindelser lytter.
Vigtigheden af SSL
SSL (Secure Socket Layer) spiller en afgørende rolle med eksterne godkendelsessystemer på plads. Det anbefales stærkt at konfigurere SSL med et eksternt autentificeringssystem, da der vil være kommunikation af følsomme oplysninger mellem klienter og servere over netværket, og SSL kan yderligere stramme sikkerheden.
Ydeevnepåvirkning af brug af eksterne godkendelsessystemer
Et effektivt og effektivt sikkerhedssystem går på bekostning af ydeevne. Da de klienter/brugere, der forsøger at oprette forbindelse til databasen, dirigeres til autentificeringssystemer for at etablere forbindelse, kan der være en forringelse af ydeevnen. Der er måder at overvinde præstationshinder på.
- Med ekstern godkendelsesmekanisme på plads kan der være en forsinkelse, når der etableres en forbindelse til databasen. Dette kan være en reel bekymring, når der er et stort antal forbindelser, der etableres til databasen.
- Udviklere skal sikre, at der ikke oprettes et unødvendigt stort antal forbindelser til databasen. Flere applikationsanmodninger, der serveres via én forbindelse, ville være fordelagtige.
- Hvor lang tid hver anmodning tager i databaseenden spiller også en vigtig rolle. Hvis anmodningen tager længere tid at fuldføre, vil efterfølgende anmodninger stå i kø. Ydeevnejustering af processerne og omhyggelig arkitektur af infrastrukturen vil være nøglen!
- Database og infrastruktur skal være effektivt opbygget og tilstrækkeligt kapacitet til at sikre god ydeevne.
- Når du udfører præstationsbenchmarking, skal du sikre dig, at SSL er aktiveret, og at den gennemsnitlige etableringstid for forbindelse derefter skal evalueres.
Integration af eksterne godkendelsessystemer med ClusterControl - PostgreSQL
PostgreSQL-instanser kan bygges og konfigureres automatisk via ClusterControl GUI. Integrering af eksterne godkendelsessystemer med PostgreSQL-forekomster implementeret via ClusterControl er stort set ens sammenlignet med integration med traditionelle PostgreSQL-instanser og er faktisk en smule enklere. Nedenfor er en oversigt over samme -
- ClusterControl installerer PostgreSQL-biblioteker aktiveret med LDAP-, KRB-, GSSAPI- og OpenSSL-funktioner
- Integration med eksterne godkendelsessystemer kræver forskellige parameterkonfigurationsændringer på postgresql-databaseserveren, hvilket kan udføres ved hjælp af ClusterControl GUI.