sql >> Database >  >> RDS >> PostgreSQL

PostgreSQL integreren met authenticatiesystemen

PostgreSQL is een van de veiligste databases ter wereld. Databasebeveiliging speelt een cruciale rol in de echte missiekritieke omgevingen. Het is belangrijk om ervoor te zorgen dat databases en de gegevens altijd zijn beveiligd en niet worden onderworpen aan onbevoegde toegang, waardoor de gegevensbeveiliging in gevaar komt. Hoewel PostgreSQL verschillende mechanismen en methoden biedt voor gebruikers om op een beveiligde manier toegang te krijgen tot de database, kan het ook worden geïntegreerd met verschillende externe authenticatiesystemen om ervoor te zorgen dat aan de standaard databasebeveiligingsvereisten van de onderneming wordt voldaan.

Afgezien van het bieden van beveiligde authenticatiemechanismen via SSL, MD5, pgpass en pg_ident enz., kan PostgreSQL worden geïntegreerd met verschillende andere populaire externe authenticatiesystemen op ondernemingsniveau. Mijn focus in deze blog zal liggen op LDAP, Kerberos en RADIUS met SSL en pg_ident.

LDAP

LDAP verwijst naar Lightweight Directory Access Protocol, een veelgebruikt gecentraliseerd authenticatiesysteem. Het is een datastore die de gebruikersreferenties en verschillende andere gebruikersgerelateerde details zoals namen, domeinen, bedrijfseenheden enz. opslaat in de vorm van een hiërarchie in een tabelindeling. De eindgebruikers die verbinding maken met de doelsystemen (bijvoorbeeld een database) moeten eerst verbinding maken met de LDAP-server om een ​​succesvolle authenticatie te doorlopen. LDAP is een van de populaire authenticatiesystemen die momenteel worden gebruikt in organisaties die hoge beveiligingsnormen eisen.

LDAP + PostgreSQL

PostgreSQL kan worden geïntegreerd met LDAP. In mijn ervaring met klantadvies wordt dit beschouwd als een van de belangrijkste mogelijkheden van PostgreSQL. Aangezien de authenticatie van de gebruikersnaam en het wachtwoord plaatsvindt op de LDAP-server, moet het gebruikersaccount in de database bestaan ​​om ervoor te zorgen dat gebruikers verbinding kunnen maken met de database via LDAP. Met andere woorden, dit betekent dat de gebruikers die proberen verbinding te maken met PostgreSQL eerst naar de LDAP-server worden gerouteerd en vervolgens naar de Postgres-database na succesvolle authenticatie. Configuratie kan worden gemaakt in het bestand pg_hba.conf om ervoor te zorgen dat verbindingen naar de LDAP-server worden gerouteerd. Hieronder vindt u een voorbeeld van een pg_hba.conf-item -

host    all    pguser   0.0.0.0/0    ldap ldapserver=ldapserver.example.com ldapprefix="cn=" ldapsuffix=", dc=example, dc=com"

Hieronder ziet u een voorbeeld van een LDAP-item 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"

Bij gebruik van niet-standaard ldap-poort en TLS:

ldap ldapserver=ldapserver.example.com ldaptls=1 ldapport=5128 ldapprefix="uid=" ldapsuffix=",ou=finance,dc=apix,dc=com"

De bovenstaande LDAP-invoer begrijpen

  • LDAP gebruikt verschillende attributen en terminologieën om een ​​gebruikersinvoer in zijn datastore op te slaan/te zoeken. Zoals hierboven vermeld, worden gebruikersinvoeren ook hiërarchisch opgeslagen.
  • De bovenstaande pg_hba.conf ldap-vermeldingen bestaan ​​uit attributen genaamd CN (Common Name), OU (Organization Unit) en DC (Domain Component), die worden aangeduid als Relative Distinguished Names (RDN), deze reeksen van RDN worden samen iets genaamd DN (Distinguished Name). DN is het LDAP-object waarop de zoekopdracht wordt uitgevoerd in de LDAP-gegevensopslag.
  • LDAP-attribuutwaarden zoals CN, DC, OU enz. worden gedefinieerd in de objectklassen van LDAP, die kunnen worden geleverd door de systeemexperts die de LDAP-omgeving hebben gebouwd.

Zal dat LDAP voldoende beveiligd maken?

Misschien niet. Wachtwoorden die via het netwerk in een LDAP-omgeving worden gecommuniceerd, zijn niet versleuteld, wat een veiligheidsrisico kan vormen omdat de versleutelde wachtwoorden kunnen worden gehackt. Er zijn opties om de communicatie met de inloggegevens veiliger te maken.

  1. Overweeg LDAP te configureren op TLS (Transport Layer Security)
  2. LDAP kan worden geconfigureerd met SSL, wat een andere optie is

Tips om LDAP-integratie met PostgreSQL te realiseren

(voor op Linux gebaseerde systemen)

  • Installeer geschikte openLDAP-modules op basis van de versie van het besturingssysteem
  • Zorg ervoor dat PostgreSQL-software is geïnstalleerd met LDAP-bibliotheken
  • Zorg ervoor dat LDAP goed is geïntegreerd met Active Directory
  • Maak kennis met alle bestaande BUG's in de openLDAP-modules die worden gebruikt. Dit kan catastrofaal zijn en de beveiligingsnormen in gevaar brengen.
  • Windows Active Directory kan ook worden geïntegreerd met LDAP
  • Overweeg om LDAP te configureren met SSL, wat veiliger is. Installeer de juiste openSSL-modules en houd rekening met BUG's zoals heart-bleed die de inloggegevens die via het netwerk worden verzonden, kunnen blootleggen.

Kerberos

Kerberos is een gecentraliseerd authenticatiesysteem volgens de industriestandaard dat veel wordt gebruikt in organisaties en biedt een op versleuteling gebaseerd authenticatiemechanisme. De wachtwoorden worden geverifieerd door een externe authenticatieserver die KDC (Key Distribution Center) wordt genoemd. De wachtwoorden kunnen worden versleuteld op basis van verschillende algoritmen en kunnen alleen worden ontsleuteld met behulp van gedeelde privésleutels. Dit betekent ook dat wachtwoorden die via het netwerk worden gecommuniceerd, versleuteld zijn.

PostgreSQL + Kerberos

PostgreSQL ondersteunt op GSSAPI gebaseerde authenticatie met Kerberos. De gebruikers die proberen verbinding te maken met de Postgres-database, worden doorgestuurd naar de KDC-server voor authenticatie. Deze authenticatie tussen clients en de KDC-database wordt uitgevoerd op basis van gedeelde privésleutels en bij succesvolle authenticatie zouden de clients nu op Kerberos gebaseerde referenties hebben. Dezelfde referenties worden onderworpen aan validatie tussen de Postgres-server en de KDC, wat zal worden gedaan op basis van het keytab-bestand dat door Kerberos wordt gegenereerd. Dit keytab-bestand moet op de databaseserver aanwezig zijn met de juiste machtigingen voor de gebruiker die eigenaar is van het Postgres-proces.

Het Kerberos-configuratie- en verbindingsproces -

  • Op Kerberos gebaseerde gebruikersaccounts moeten een ticket (een verbindingsverzoek) genereren met de opdracht "kinit".

  • Een keytab-bestand moet worden gegenereerd met de opdracht "kadmin" voor een volledig gekwalificeerde Kerberos-gebaseerde gebruikersaccount (principaal) en dan zou Postgres hetzelfde keytab-bestand gebruiken om de referenties te valideren. Principals kunnen worden gecodeerd en toegevoegd aan het bestaande keytab-bestand met behulp van de opdracht "ktadd". Kerberos-encryptie ondersteunt verschillende industriestandaardencryptie-algoritmen.

    Het gegenereerde keytab-bestand moet naar de Postgres-server worden gekopieerd en moet leesbaar zijn voor het Postgres-proces. De onderstaande postgresql.conf-parameter moet worden geconfigureerd:

    krb_server_keyfile = '/database/postgres/keytab.example.com'

    Als u bijzonder bent over hoofdlettergevoeligheid, gebruik dan de onderstaande parameter

    krb_caseins_users which is by default “off”  (case sensitive)
  • Er moet een invoer worden gemaakt in de pg_hba.conf om ervoor te zorgen dat verbindingen worden gerouteerd naar de KDC-server

    Voorbeeld pg_hba.conf invoer

    # TYPE DATABASE       USER    CIDR-ADDRESS            METHOD
    host     all                     all         192.168.1.6/32            gss include_realm=1 krb_realm=EXAMPLE.COM

    Voorbeeld pg_hba.conf invoer met kaartinvoer

    # TYPE DATABASE       USER    CIDR-ADDRESS            METHOD
    host     all                     all         192.168.1.6/32            gss include_realm=1 krb_realm=EXAMPLE.COM map=krb
  • Een gebruikersaccount dat probeert verbinding te maken, moet worden toegevoegd aan de KDC-database die als principal wordt genoemd en hetzelfde gebruikersaccount of een mappinggebruikersaccount moet ook in de database bestaan

    Hieronder ziet u een voorbeeld van een Kerberos-principal

    [email protected]

    pguser is de gebruikersnaam en de "example.com" is de realm-naam die is geconfigureerd in de Kerberos-configuratie (/etc/krb5.conf) op de KDC-server.

    In de kerberos-wereld, opdrachtgevers zijn in een e-mailachtige indeling ([email protected]) en de databasegebruikers kunnen niet in dezelfde indeling worden gemaakt. Dit doet DBA's denken aan het maken van een toewijzing van databasegebruikersnamen en om ervoor te zorgen dat principals verbinding maken met toegewezen namen met behulp van pg_ident.conf.

    Hieronder ziet u een voorbeeld van een kaartnaaminvoer in pg_ident.conf

    # MAPNAME           SYSTEM-USERNAME               GP-USERNAME
       mapuser               /^(.*)EXAMPLE\.DOMAIN$      admin

Zal dat Kerberos voldoende beveiligd zijn?

Misschien niet. Gebruikersreferenties die via het netwerk worden gecommuniceerd, kunnen worden blootgesteld, gehackt. Hoewel Kerberos de principals versleutelt, kunnen ze worden gestolen en gehackt. Dit brengt de noodzaak met zich mee om netwerklaagbeveiliging te implementeren. Ja, SSL of TLS is de juiste keuze. Het Kerberos-authenticatiesysteem kan worden geïntegreerd met SSL of TLS. TLS is de opvolger van SSL. Het wordt aanbevolen om Kerberos te configureren met SSL of TLS zodat de communicatie via het netwerk beveiligd is.

TIPS

  • Zorg ervoor dat krb*-bibliotheken zijn geïnstalleerd
  • OpenSSL-bibliotheken moeten zijn geïnstalleerd om SSL te configureren
  • Zorg ervoor dat Postgres is geïnstalleerd met de volgende opties
    ./configure --with-gssapi --with-krb-srvnam --with-openssl
Download de whitepaper vandaag PostgreSQL-beheer en -automatisering met ClusterControlLees wat u moet weten om PostgreSQL te implementeren, bewaken, beheren en schalenDownload de whitepaper

RADIUS

RADIUS is een netwerkprotocol voor authenticatie op afstand dat gecentraliseerde

Authenticatie, autorisatie en boekhouding (AAA). Gebruikersnaam / wachtwoord-paren worden geverifieerd op de RADIUS-server. Deze manier van gecentraliseerde authenticatie is veel rechttoe rechtaan en eenvoudiger in vergelijking met andere authenticatiesystemen zoals LDAP en Kerberos, wat een beetje ingewikkeld is.

RADIUS + PostgreSQL

PostgreSQL kan worden geïntegreerd met het RADIUS-authenticatiemechanisme. Boekhouding wordt nog niet ondersteund in Postgres. Hiervoor moeten databasegebruikersaccounts in de database aanwezig zijn. Verbindingen met de database zijn geautoriseerd op basis van het gedeelde geheim dat "radiussecret" wordt genoemd.

Een vermelding in de pg_hba.conf-configuratie is essentieel om de verbindingen naar de radiusserver te routeren voor authenticatie.

Voorbeeld pg_hba.conf invoer

hostssl             all        all        0.0.0.0/0         radius  radiusserver=127.0.0.1 radiussecret=secretr radiusport=3128

Om de bovenstaande invoer te begrijpen -

"radiusserver" is het host-IP-adres van de RADIUS-server waarnaar gebruikers worden gerouteerd voor authenticatie. Deze parameter wordt geconfigureerd in /etc/radiusd.conf op de RADIUS-server.

"radiussecret" waarde wordt geëxtraheerd uit clients.conf. Dit is de geheime code die de radius-clientverbinding op unieke wijze identificeert.

“radiusport” is te vinden in het bestand /etc/radiusd.conf. Dit is de poort waarop radiusverbindingen zullen luisteren.

Belang van SSL

SSL (Secure Socket Layer) speelt een dwingende rol met externe authenticatiesystemen. Het wordt ten zeerste aanbevolen om SSL te configureren met een extern authenticatiesysteem, omdat er gevoelige informatie tussen clients en de servers via het netwerk wordt gecommuniceerd en SSL de beveiliging verder kan verscherpen.

Prestatie-impact van het gebruik van externe authenticatiesystemen

Een effectief en efficiënt beveiligingssysteem gaat ten koste van de prestaties. Aangezien de clients/gebruikers die proberen verbinding te maken met de database, worden doorgestuurd naar authenticatiesystemen om een ​​verbinding tot stand te brengen, kan er prestatievermindering optreden. Er zijn manieren om prestatiebelemmeringen te overwinnen.

  • Met een extern authenticatiemechanisme kan er een vertraging optreden bij het tot stand brengen van een verbinding met de database. Dit kan een groot probleem zijn als er een groot aantal verbindingen met de database tot stand wordt gebracht.
  • Ontwikkelaars moeten ervoor zorgen dat er niet onnodig veel verbindingen met de database worden gemaakt. Meerdere aanvraagverzoeken die via één verbinding worden afgehandeld, zouden voordelig zijn.
  • Ook hoe lang elk verzoek aan het einde van de database duurt, speelt een belangrijke rol. Als het verzoek langer duurt om te voltooien, komen volgende verzoeken in de rij te staan. Het afstemmen van de prestaties van de processen en het zorgvuldig ontwerpen van de infrastructuur zullen de sleutel zijn!
  • Database en infrastructuur moeten efficiënt worden ontworpen en adequaat worden uitgerust om goede prestaties te garanderen.
  • Zorg er bij het uitvoeren van prestatiebenchmarks voor dat SSL is ingeschakeld en dat de gemiddelde verbindingstijd vervolgens moet worden geëvalueerd.

Externe authenticatiesystemen integreren met ClusterControl - PostgreSQL

PostgreSQL-instanties kunnen automatisch worden gebouwd en geconfigureerd via de ClusterControl GUI. Het integreren van externe authenticatiesystemen met PostgreSQL-instanties die zijn geïmplementeerd via ClusterControl is vrijwel gelijk aan integratie met traditionele PostgreSQL-instanties en is in feite een beetje eenvoudiger. Hieronder is een overzicht van hetzelfde -

  • ClusterControl installeert PostgreSQL-bibliotheken met LDAP-, KRB-, GSSAPI- en OpenSSL-mogelijkheden
  • Integratie met externe authenticatiesystemen vereist verschillende parameterconfiguratiewijzigingen op de postgresql-databaseserver die kunnen worden gedaan met behulp van ClusterControl GUI.

  1. Hoe de LPAD()-functie werkt in MySQL

  2. Kan geen verbinding maken met de postgres-server in een docker vanuit een gedockte app

  3. Hoe DENSE_RANK() werkt in SQL Server

  4. GROUP BY + CASE-instructie