PostgreSQL- Datenbank der Zukunft? NEUE REIHE: Teil I

PostgreSQL Enterprise Features

dvz postgreSQL

Open-Source-Datenbanken wie PostgreSQL haben am Markt einen schweren Stand. Eine oft missverstandene Eigenart ist, dass viele der erweiterten Features, die ein kommerzielles RDBMS ausmachen, dort nicht oder nur rudimentär umgesetzt seien. Tatsächlich stellt PostgreSQL eine Vielzahl von Features bereit, die denen in kommerziellen RDBMS gleichkommen. Einige dieser Features wollen wir Ihnen in diesem Artikel aufzeigen. In den kommenden Ausgaben werden diese Eigenschaften dann mit größerer Ausführlichkeit beleuchtet.

Hochverfügbarkeit (High Availability)

In kommerziellen RDBMS ist oft eine HA-Variante implementiert, bei der neben dem regulären Datenbankserver ein zweites System parallel läuft, welches ein 1:1-Abbild des ersten darstellt. Das Ausfallsystem läuft dabei in einem Modus der ständigen Wiederherstellung von Archivdaten des Primärsystems.

Oft ist das Zweitsystem auch in einer lesenden Variante verfügbar, also für reine Abfragen ohne Datenänderung. Sollte das Primärsystem - geplant oder ungeplant - nicht verfügbar sein, so existiert eine Möglichkeit, das Zweitsystem zum Primärsystem zu machen und den produktiven Betrieb weiter laufen zu lassen. Bei Oracle ist diese Lösung als Dataguard bekannt, bei IBM Db2 und Informix als HADR bzw. HDR. Die PostgreSQL-Variante hiervon lautet Log Shipping Standby Server und der Funktionsumfang ist standardmäßig Teil der normalen PostgreSQL-Installation.

Wie bei den anderen RDBMS verwendet auch PostgreSQL das gleiche Prinzip. Basierend auf einem Backup vom Hauptsystem werden Datenänderungen über Archive auf das Zweitsystem übertragen. Ein solches Backup hat unter PostgreSQL zudem bereits den Vorteil, dass es sich mit wenigen Einstellungen zu einer lauffähigen Variante und somit zu einem Abbild des primären Datenbankservers umfunktionieren lässt. Ein weiterer Vorteil ist zudem, dass sich das zweite System ohne zusätzliche Kosten in den Lesemodus versetzen lässt, was unter kommerziellen Datenbanksystemen wie Oracle mit Zusatzkosten zu Buche schlägt.

Bei PostgreSQL gibt es hierbei zwei Varianten:

Die erste ist das Wiederherstellen der WALs auf dem Standby-System. Diese Variante ist naturgemäß asynchron, da ein WAL-Archiv erst wiederhergestellt werden kann, wenn es abgeschlossen und auf das Standby-System transferiert wurde. Das Risiko eines Datenverlustes ist zwar relativ gering, aber doch  vorhanden, da bei einem Totalausfall des Primärsystems kein solch abschließender Transfer mehr erfolgen kann. Transaktionsinformationen, die im letzten WAL vorhanden waren, können daher unter Umständen verloren sein. Um dieses Risiko weitestgehend zu minimieren, kann das Verfahren so abgeändert werden, dass nach Ablauf des bestimmten Zeitintervalls automatisch ein Transfer eingeleitet wird.

Die zweite Variante nennt sich Streaming Replication. Dabei werden Transaktionen über das Streaming-Replication-Protokoll vom Primärsystem auf das Standby-System gesendet, sobald die Bestätigung zur Datenänderung (Commit) gesendet wird. Sollte das Primärsystem ausfallen, sind so allenfalls die Änderungen im Puffer nicht mehr übertragen worden.

Streaming Replication kann auch synchron eingestellt werden. In synchronen Fall ist das Risiko des Datenverlustes noch geringer als im asynchronen Fall: Zu einem Datenverlust kann es nur dann kommen, wenn beide Systeme gleichzeitig versagen. Aus diesem Grund sind einzelne HA-Server immer in getrennten Rechenzentren unterzubringen. Sind allerdings die Netzwerkantwortzeiten zwischen den Systemen zu groß, so kann es bei synchroner Replikation zu Performance-Einbrüchen kommen, da das Primärsystem immer auf Antworten vom Standby wartet.

Passwortverschlüsselung

Da PostgreSQL seine Benutzer intern verwaltet, müssen zugriffsberechtigte Benutzer über ein Passwort verfügen. Diese werden automatisch verschlüsselt und im Cluster gespeichert. Da der bis zur Version 9.6 verwendete Verschlüsselungsalgorithmus MD5 mittlerweile als zu unsicher gilt, wurde ab Version 10 der SCRAM-SHA-256-Algorithmus integriert.

Auch wenn keine SSL-Verschlüsselung verwendet wird, ist es möglich, zumindest die Passwörter nicht unverschlüsselt über das Netzwerk zu versenden, was mit entsprechenden Einträgen in der pg_hba.conf leicht zu erreichen ist.

Passwörter, die noch im MD5-Modus in neuere Versionen übernommen wurden, können etwa durch die Definition eines Ablaufdatums für den User auch in die neue Variante überführt werden.

Netzwerkverschlüsselung

PostgreSQL unterstützt nativ SSL-Verschlüsselung für Datenbankzugriffe über das Netzwerk. Hierzu kann sowohl ein CA-signiertes als auch ein selbst erstelltes Zertifikat verwendet werden. Benutzer und Clients müssen, wie bei PostgreSQL allgemein üblich, autorisiert werden, um eine verschlüsselte Verbindung zu verwenden und können diese dann benutzen.

Netzwerkverschlüsselung kann auch für eine verschlüsselte Replikationslösung verwendet werden, da für den Datentransfer über das Netzwerk ein Zugriff über einen speziellen Replikationsbenutzer benötigt wird. Dieser Benutzer muss zwar nicht zwingend vorhanden sein, ist aber aus Sicherheitsgründen empfehlenswert.

Datenverschlüsselung

PostgreSQL stellt über seine mitgelieferten Erweiterungen eine Vielzahl von Verschlüsselungsmethoden zur Verfügung, um sensible Daten vor unbefugtem Zugriff zu schützen.

Zur verschlüsselten Ablage von Passwörtern innerhalb der Datenbank (gemeint ist hier kein Datenbankpasswort für PostgreSQL, sondern z.B. Passwörter für ein externes Programm) existieren bereits vorgefertigte Hashing-Funktionen. Diese Funktionen verfügen über einige Sicherheitsmechanismen, etwa:

  • unterschiedliche Verschlüsselung gleicher Passwörter (zufällige Salt-Zeichenfolge)
  • verschlüsselte Passwörter können aus unterschiedlichen Algorithmen berechnet werden und trotzdem nebeneinander existieren
  • Steuerung der Schnelligkeit des genannten Algorithmus' (durch Erhöhung der Iterationen), eventuelle Angreifer benötigen aus diesem Grund ebenfalls länger, um ein Passwort durch Brute-Force-Angriffe herauszufinden.

Zur verschlüsselten Ablage von Daten, die wieder unverschlüsselt ausgelesen werden müssen, stellt PostgreSQL PGP- und RAW-Verschlüsselung zur Verfügung. Das stellt sicher, dass nur Benutzer, welche über den korrekten Schlüssel verfügen, in der Lage sind, im Klartext auf die Daten zuzugreifen.

Externe Authentifizierung über LDAP

Für die Anmeldung an PostgreSQL können auch LDAP User verwendet werden. Voraussetzung dafür ist, dass sie in der Datenbank als lokale User angelegt werden. In der Konfiguration des Datenbank-Clusters kann mit Optionen, die ähnlich einem LDAP-Connection-String aufgebaut sind, eine Authentifizierung des Users über das LDAP stattfinden.

Der Vorteil hierbei: Die Passwörter von Datenbank-Usern müssen nicht separat gepflegt werden und weichen auch nicht von denen der LDAP-User ab.

Bei dieser Zugriffsmethode wird momentan noch keine ldaps-URL zum verschlüsselten Zugriff auf das LDAP unterstützt. Um dennoch eine sichere Verbindung über das Netzwerk aufzubauen, muss, wie oben beschrieben, die Netzwerkverschlüsselung über SSL verwendet werden.

Auditing

Nativ unterstützt PostgreSQL schon von vornherein das Tracing von SQL-Statements und deren Laufzeiten sowie von An- und Abmeldungen der User am Cluster.

Zudem lebt PostgreSQL sehr stark von seinen zahlreichen Erweiterungen, die zum Teil zur Installation hinzugehören. Eines davon ist die Extension pgaudit. Hiermit lassen sich auch Datenänderungen oder -zugriffe auf Tabellen überwachen. Auch ganz bestimmte User können auf diese Weise überwacht werden. Die Installation des Moduls erfolgt, wie fast immer unter PostgreSQL, pro Datenbank und wird beim Neustart des Clusters aktiv.

Komprimierung

PostgreSQL verwendet ein Konzept zu Speicherung von Daten, die nicht in eine Standard-Page passen. Dabei ist es möglich, die Daten sowohl direkt als auch komprimiert zu speichern. Das unter dem Namen TOAST bekannte Verfahren kommt nur für Datentypen mit variabler Länge zum Tragen. Dabei kann der Wert innerhalb der Tabelle als auch transparent für den User in eine externe Untertabelle ausgelagert werden.

Die Speicherung mit TOAST findet automatisch statt, sobald die Länge des zu speichernden Werts einen bestimmten Schwellwert überschreitet. Der DBA kann einstellen, ob der Wert zusätzlich komprimiert werden soll. Für die meisten Datentypen, für die TOAST angewendet werden kann, wird standardmäßig sowohl ausgelagert als auch komprimiert.

Dennis Vinueza ()