PostgreSQL ist eine der sichersten Datenbanken der Welt. Die Datenbanksicherheit spielt in realen, unternehmenskritischen Umgebungen eine zwingende Rolle. Es ist wichtig sicherzustellen, dass Datenbanken und Daten immer gesichert sind und keinem unbefugten Zugriff ausgesetzt sind, wodurch die Datensicherheit gefährdet wird. Während PostgreSQL verschiedene Mechanismen und Methoden für Benutzer bereitstellt, um auf sichere Weise auf die Datenbank zuzugreifen, kann es auch in verschiedene externe Authentifizierungssysteme integriert werden, um sicherzustellen, dass die Datenbanksicherheitsanforderungen des Unternehmensstandards erfüllt werden.
Abgesehen von der Bereitstellung sicherer Authentifizierungsmechanismen über SSL, MD5, pgpass und pg_ident usw. kann PostgreSQL in verschiedene andere beliebte externe Authentifizierungssysteme für Unternehmen integriert werden. Mein Fokus in diesem Blog liegt auf LDAP, Kerberos und RADIUS mit SSL und pg_ident.
LDAP
LDAP bezieht sich auf Lightweight Directory Access Protocol, ein weit verbreitetes zentralisiertes Authentifizierungssystem. Es ist ein Datenspeicher, der die Benutzeranmeldeinformationen und verschiedene andere benutzerbezogene Details wie Namen, Domänen, Geschäftseinheiten usw. in Form einer Hierarchie in einem Tabellenformat speichert. Die Endbenutzer, die sich mit den Zielsystemen (z. B. einer Datenbank) verbinden, müssen sich zuerst mit dem LDAP-Server verbinden, um eine erfolgreiche Authentifizierung zu erhalten. LDAP ist eines der beliebtesten Authentifizierungssysteme, das derzeit von Organisationen verwendet wird, die hohe Sicherheitsstandards fordern.
LDAP + PostgreSQL
PostgreSQL kann mit LDAP integriert werden. In meiner Kundenberatungserfahrung wird dies als eine der Schlüsselfunktionen von PostgreSQL angesehen. Da die Authentifizierung des Benutzernamens und des Passworts am LDAP-Server stattfindet, muss das Benutzerkonto in der Datenbank vorhanden sein, damit Benutzer sich über LDAP mit der Datenbank verbinden können. Mit anderen Worten bedeutet dies, dass die Benutzer beim Versuch, eine Verbindung zu PostgreSQL herzustellen, zuerst zum LDAP-Server und dann nach erfolgreicher Authentifizierung zur Postgres-Datenbank geleitet werden. In der Datei pg_hba.conf kann eine Konfiguration vorgenommen werden, um sicherzustellen, dass Verbindungen zum LDAP-Server geleitet werden. Unten ist ein Beispiel für einen pg_hba.conf-Eintrag -
host all pguser 0.0.0.0/0 ldap ldapserver=ldapserver.example.com ldapprefix="cn=" ldapsuffix=", dc=example, dc=com"Unten sehen Sie ein Beispiel für einen LDAP-Eintrag 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"Bei Verwendung eines nicht standardmäßigen LDAP-Ports und TLS:
ldap ldapserver=ldapserver.example.com ldaptls=1 ldapport=5128 ldapprefix="uid=" ldapsuffix=",ou=finance,dc=apix,dc=com"Den obigen LDAP-Eintrag verstehen
- LDAP verwendet verschiedene Attribute und Terminologien, um einen Benutzereintrag in seinem Datenspeicher zu speichern/zu suchen. Außerdem werden, wie oben erwähnt, Benutzereinträge hierarchisch gespeichert.
- Die obigen LDAP-Einträge in pg_hba.conf bestehen aus Attributen namens CN (Common Name), OU (Organization Unit) und DC (Domain Component), die als Relative Distinguished Names (RDN) bezeichnet werden. Diese Sequenz von RDN ergibt zusammen etwas genannt DN (Distinguished Name). DN ist das LDAP-Objekt, auf dessen Basis die Suche im LDAP-Datenspeicher durchgeführt wird.
- LDAP-Attributwerte wie CN, DC, OU usw. werden in den Objektklassen von LDAP definiert, die von den Systemexperten bereitgestellt werden können, die die LDAP-Umgebung aufgebaut haben.
Wird das LDAP sicher genug machen?
Vielleicht nicht. Passwörter, die über das Netzwerk in einer LDAP-Umgebung kommuniziert werden, sind nicht verschlüsselt, was ein Sicherheitsrisiko darstellen kann, da die verschlüsselten Passwörter gehackt werden können. Es gibt Optionen, um die Kommunikation mit Anmeldeinformationen sicherer zu machen.
- Erwägen Sie die Konfiguration von LDAP auf TLS (Transport Layer Security)
- LDAP kann mit SSL konfiguriert werden, was eine weitere Option ist
Tipps zur Erzielung einer LDAP-Integration mit PostgreSQL
(für Linux-basierte Systeme)
- Installieren Sie geeignete openLDAP-Module basierend auf der Betriebssystemversion
- Stellen Sie sicher, dass die PostgreSQL-Software mit LDAP-Bibliotheken installiert ist
- Stellen Sie sicher, dass LDAP gut in Active Directory integriert ist
- Machen Sie sich mit allen vorhandenen BUGs in den verwendeten openLDAP-Modulen vertraut. Dies kann katastrophale Folgen haben und Sicherheitsstandards gefährden.
- Windows Active Directory kann auch mit LDAP integriert werden
- Ziehen Sie in Erwägung, LDAP mit SSL zu konfigurieren, da dies sicherer ist. Installieren Sie geeignete openSSL-Module und achten Sie auf BUGs wie Heart-Bleed, die die über das Netzwerk übertragenen Anmeldeinformationen offenlegen können.
Kerberos
Kerberos ist ein branchenübliches zentralisiertes Authentifizierungssystem, das häufig in Organisationen verwendet wird und einen auf Verschlüsselung basierenden Authentifizierungsmechanismus bereitstellt. Die Passwörter werden von einem Drittanbieter-Authentifizierungsserver namens KDC (Key Distribution Centre) authentifiziert. Die Passwörter können auf Basis verschiedener Algorithmen verschlüsselt und nur mit Hilfe gemeinsamer privater Schlüssel entschlüsselt werden. Das bedeutet auch, dass über das Netzwerk übermittelte Passwörter verschlüsselt werden.
PostgreSQL + Kerberos
PostgreSQL unterstützt GSSAPI-basierte Authentifizierung mit Kerberos. Die Benutzer, die versuchen, eine Verbindung zur Postgres-Datenbank herzustellen, werden zur Authentifizierung an den KDC-Server weitergeleitet. Diese Authentifizierung zwischen Clients und der KDC-Datenbank wird basierend auf gemeinsam genutzten privaten Schlüsseln durchgeführt, und nach erfolgreicher Authentifizierung würden die Clients nun über Kerberos-basierte Anmeldeinformationen verfügen. Dieselben Anmeldeinformationen werden zwischen dem Postgres-Server und dem KDC validiert, was auf der Grundlage der von Kerberos generierten Keytab-Datei erfolgt. Diese Keytab-Datei muss auf dem Datenbankserver mit entsprechenden Berechtigungen für den Benutzer vorhanden sein, dem der Postgres-Prozess gehört.
Der Kerberos-Konfigurations- und Verbindungsprozess -
-
Kerberos-basierte Benutzerkonten müssen mit dem Befehl „kinit“ ein Ticket (eine Verbindungsanfrage) generieren.
-
Eine Keytab-Datei muss mit dem Befehl „kadmin“ für ein vollqualifiziertes Kerberos-basiertes Benutzerkonto (Principal) generiert werden, und Postgres würde dann dieselbe Keytab-Datei verwenden, um die Anmeldeinformationen zu validieren. Prinzipale können verschlüsselt und mit dem Befehl „ktadd“ zu einer vorhandenen Keytab-Datei hinzugefügt werden. Die Kerberos-Verschlüsselung unterstützt verschiedene branchenübliche Verschlüsselungsalgorithmen.
Die generierte Keytab-Datei muss auf den Postgres-Server kopiert werden, sie muss für den Postgres-Prozess lesbar sein. Der folgende postgresql.conf-Parameter muss konfiguriert werden:
krb_server_keyfile = '/database/postgres/keytab.example.com'Wenn Sie besonders auf Groß- und Kleinschreibung achten, verwenden Sie den folgenden Parameter
krb_caseins_users which is by default “off” (case sensitive) -
In der pg_hba.conf muss ein Eintrag gemacht werden, damit Verbindungen zum KDC-Server geroutet werden
Beispiel für einen pg_hba.conf-Eintrag
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COMBeispiel pg_hba.conf-Eintrag mit map-Eintrag
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COM map=krb -
Ein Benutzerkonto, das versucht, eine Verbindung herzustellen, muss der KDC-Datenbank hinzugefügt werden, die als Prinzipal bezeichnet wird, und dasselbe Benutzerkonto oder ein Mapping-Benutzerkonto muss auch in der Datenbank vorhanden sein
Unten sehen Sie ein Beispiel für einen Kerberos-Principal
pguser ist der Benutzername und „example.com“ ist der Bereichsname, der in der Kerberos-Konfiguration (/etc/krb5.conf) auf dem KDC-Server konfiguriert ist.
In der Kerberos-Welt Principals haben ein E-Mail-ähnliches Format ([email protected]) und die Datenbankbenutzer können nicht im selben Format erstellt werden. Dies veranlasst DBAs, stattdessen eine Zuordnung von Datenbankbenutzernamen zu erstellen und sicherzustellen, dass Prinzipale sich mit zugeordneten Namen unter Verwendung von pg_ident.conf verbinden.
Unten sehen Sie ein Beispiel für einen Map-Namenseintrag in pg_ident.conf
# MAPNAME SYSTEM-USERNAME GP-USERNAME mapuser /^(.*)EXAMPLE\.DOMAIN$ admin
Wird Kerberos dadurch sicher genug?
Vielleicht nicht. Über das Netzwerk übermittelte Benutzeranmeldeinformationen können offengelegt und gehackt werden. Obwohl Kerberos die Prinzipale verschlüsselt, können sie gestohlen oder gehackt werden. Dies bringt die Notwendigkeit mit sich, Netzwerkschichtsicherheit zu implementieren. Ja, SSL oder TLS ist der richtige Weg. Das Kerberos-Authentifizierungssystem kann mit SSL oder TLS integriert werden. TLS ist der Nachfolger von SSL. Es wird empfohlen, Kerberos mit SSL oder TLS zu konfigurieren, damit die Kommunikation über das Netzwerk gesichert ist.
TIPPS
- Stellen Sie sicher, dass krb*-Bibliotheken installiert sind
- OpenSSL-Bibliotheken müssen installiert sein, um SSL zu konfigurieren
- Stellen Sie sicher, dass Postgres mit den folgenden Optionen installiert ist
./configure --with-gssapi --with-krb-srvnam --with-openssl
RADIUS
RADIUS ist ein Remote-Authentifizierungsdienst-Netzwerkprotokoll, das zentralisierte
bereitstelltAuthentifizierung, Autorisierung und Abrechnung (AAA). Benutzername/Passwort-Paare werden beim RADIUS-Server authentifiziert. Diese Art der zentralisierten Authentifizierung ist viel geradliniger und einfacher im Vergleich zu anderen Authentifizierungssystemen wie LDAP und Kerberos, die etwas komplexer sind.
RADIUS + PostgreSQL
PostgreSQL kann in den RADIUS-Authentifizierungsmechanismus integriert werden. Buchhaltung wird in Postgres noch nicht unterstützt. Dazu müssen Datenbankbenutzerkonten in der Datenbank vorhanden sein. Verbindungen zur Datenbank werden auf der Grundlage des gemeinsamen Geheimnisses autorisiert, das als „Radiussecret“ bezeichnet wird.
Ein Eintrag in der pg_hba.conf-Konfiguration ist unerlässlich, um die Verbindungen zum Radius-Server zur Authentifizierung zu leiten.
Beispiel für einen pg_hba.conf-Eintrag
hostssl all all 0.0.0.0/0 radius radiusserver=127.0.0.1 radiussecret=secretr radiusport=3128Um den obigen Eintrag zu verstehen -
„radiusserver“ ist die Host-IP-Adresse des RADIUS-Servers, an den Benutzer zur Authentifizierung weitergeleitet werden. Dieser Parameter wird in der /etc/radiusd.conf im RADIUS-Server konfiguriert.
Der Wert „radiussecret“ wird aus der client.conf extrahiert. Dies ist der Geheimcode, der die Radius-Client-Verbindung eindeutig identifiziert.
„radiusport“ kann in der Datei /etc/radiusd.conf gefunden werden. Dies ist der Port, auf dem Radius-Verbindungen lauschen.
Bedeutung von SSL
SSL (Secure Socket Layer) spielt bei externen Authentifizierungssystemen eine zwingende Rolle. Es wird dringend empfohlen, SSL mit einem externen Authentifizierungssystem zu konfigurieren, da vertrauliche Informationen zwischen Clients und Servern über das Netzwerk ausgetauscht werden und SSL die Sicherheit weiter erhöhen kann.
Auswirkungen der Verwendung externer Authentifizierungssysteme auf die Leistung
Ein effektives und effizientes Sicherheitssystem geht zu Lasten der Leistung. Da die Clients/Benutzer, die versuchen, eine Verbindung zur Datenbank herzustellen, zu Authentifizierungssystemen geleitet werden, um eine Verbindung herzustellen, kann es zu Leistungseinbußen kommen. Es gibt Möglichkeiten, Leistungshürden zu überwinden.
- Wenn ein externer Authentifizierungsmechanismus vorhanden ist, kann es beim Herstellen einer Verbindung zur Datenbank zu Verzögerungen kommen. Dies kann ein echtes Problem sein, wenn eine große Anzahl von Verbindungen zur Datenbank hergestellt wird.
- Entwickler müssen sicherstellen, dass nicht unnötig viele Verbindungen zur Datenbank hergestellt werden. Es wäre vorteilhaft, mehrere Anwendungsanfragen über eine Verbindung zu bedienen.
- Auch wie lange jede Anfrage am Datenbankende dauert, spielt eine wichtige Rolle. Wenn die Anforderung länger dauert, werden nachfolgende Anforderungen in die Warteschlange gestellt. Die Leistungsoptimierung der Prozesse und die sorgfältige Architektur der Infrastruktur werden der Schlüssel sein!
- Datenbank und Infrastruktur müssen effizient gestaltet und angemessen ausgestattet sein, um eine gute Leistung zu gewährleisten.
- Stellen Sie beim Leistungsbenchmarking sicher, dass SSL aktiviert ist, und die durchschnittliche Verbindungsaufbauzeit muss dann ausgewertet werden.
Integrieren externer Authentifizierungssysteme mit ClusterControl - PostgreSQL
PostgreSQL-Instanzen können automatisch über die ClusterControl-GUI erstellt und konfiguriert werden. Die Integration externer Authentifizierungssysteme mit PostgreSQL-Instanzen, die über ClusterControl bereitgestellt werden, ist im Vergleich zur Integration mit herkömmlichen PostgreSQL-Instanzen ziemlich ähnlich und tatsächlich etwas einfacher. Unten finden Sie eine Übersicht darüber -
- ClusterControl installiert PostgreSQL-Bibliotheken, die mit LDAP-, KRB-, GSSAPI- und OpenSSL-Funktionen aktiviert sind
- Die Integration mit externen Authentifizierungssystemen erfordert verschiedene Parameterkonfigurationsänderungen auf dem Postgresql-Datenbankserver, die mit der ClusterControl-GUI durchgeführt werden können.
