Dieser Patch von Cybertec ist zur Zeit die einzige verfügbare Möglichkeit, eine PostgreSQL-Instanz (Cluster) vollkommen transparent und kryptographisch sicher zu verschlüsseln, ohne Verschlüsselung auf Betriebssystem- oder Filesystem-Ebene verwenden zu müssen.

Wie funktioniert die Verschlüsselung?

Die Idee dahinter ist, alle Dateien, aus denen ein PostgreSQL-Cluster besteht, sicher verschlüsselt auf Festplatte zu speichern („data-at-rest encryption“) und Datenblöcke beim Lesen zu entschlüsseln. Die einzigen Voraussetzungen dafür sind, dass die Datenbank unter Berücksichtigung der Verschlüsselung angelegt wird und dass der verwendete Schlüssel beim Starten des Servers verfügbar ist.
Der Schlüssel kann auf zweierlei Arten zur Verfügung gestellt werden: durch eine Umgebungsvariable oder – für höhere Sicherheitsansprüche – durch einen besonderen Konfigurationsparameter, mit dem man ein Kommando angeben kann, das den Schlüssel liefert.

Details

Zur Verschlüsselung wird ein 128-Bit AES-Algorithmus im XTS-Modus verwendet, manchmal auch XTS-AES genannt. Das ist eine Block-Chiffre mit einer Modifikation für zusätzliche Sicherheit, die dem IEEE P1619-Standard genügt.
Der Schlüssel muss dem Server beim Systemstart zur Verfügung stehen, sonst startet der Server nicht. Praktisch alles wird verschlüsselt – Daten-Files (Tabellen, Indizes und Sequences), das Transaktions-Log (weil es auch Daten enthält), das Commit-Log und temporäre Dateien, wie sie bei der Ausführung größerer Abfragen erzeugt werden.

Die durch die Verschlüsselung bewirkte Performance-Einbuße hängt stark von der konkreten Anwendung ab. Wenn der verwendete Teil der Datenbank bequem in den Shared-Memory-Puffer passt, ist die Einbuße jedoch fast vernachlässigbar.

Lizenz

PostgreSQL Lizenz

PostgreSQL Verschlüsselung auf Instanz-Ebene Download

Downloaden Sie dieses Tool vollkommen kostenlos.

postgresql-9.6.0-fde.tar

FAQ

Was wird tatsächlich verschlüsselt?
A: Alles außer zwei Dingen: den Daten der Extension pg_stat_statements und temporären Puffern, die für logische Replikation verwendet werden (wenn diese verwendet wird). Verschlüsselt werden also Tabellen, Indizes, das Transaktions-Log, das Commit-Log, temporäre und „unlogged“ Tabellen, Freespace-Map, Visibility-Map und TOAST. Die beiden Ausnahmen könnten auch verschlüsselt werden, aber diese zusätzliche Komplikation wurde bei der ersten Version ausgelassen, weil diese Funktionalitäten im Ausgangszustand sowieso nicht aktiv sind.

F: Welche Verschüsselungsmethode wird verwendet?
A: Eine dem Standard entsprechende 128-bit XTS-AES Block-Chiffre.

F: Kann ich eine andere Verschlüsselungsmethode verwenden?
A: Nicht von vornherein. Dafür müsste man einige Funktionen in C schreiben. Das Interface selbst ist aber recht einfach.

F: Was ist die typische Performance-Einbuße?
A: Auf einem typischen Server-System (wenn es so etwas gibt), wo die Datenbank in den Shared-Memory-Puffer passt, ist die Einbuße vernachlässigbar (<3%). Andernfalls werden Ein/Ausgabe-Operationen bis zu 2-3-Mal langsamer. Als Weiterentwicklung wird Hardware-Verschlüsselung (unter Verwendung von AES-NI) hinzugefügt werden, wodurch wir eine Reduktion des Mehraufwandes um fast eine Größenordnung erwarten. F: Kann ich ein Upgrade einer verschlüsselten Datenbank auf die andere Version durchführen?
A: Ja, wenn der neue Cluster mit dem alten Schlüssel initialisiert wurde.

F: Ist es möglich, nur gewisse Tabellen oder Tablespaces zu verschlüsseln, um bessere Performance zu erhalten?
A: Derzeit nicht. Theoretisch könnten wir das später hinzufügen, aber weil das Transaktions-Log immer verschlüsselt sein wird und normalerweise alle Änderungen in das Transaktions-Log gehen, wäre es wahrscheinlich von beschränktem Nutzen.

F: Ist es möglich, den Schlüssel zu ändern, wenn er nicht mehr sicher ist?
A: Derzeit nicht; man muss einen neuen Cluster anlegen und die Daten durch Export/Import übertragen. Man kann aber das Kommando, das den Schlüssel liefert, dazu verwenden, eine verschlüsselte Schlüsselablage für den eigentlichen Schlüssel zu implementieren, sodass man den Schlüssel ändern kann, mit dem man zum eigentlichen Schlüssel kommt.

F: Gibt es eine Integration mit HSM?
A: Nicht von Vornherein. Man kann ein HSM auf zwei Arten integrieren: Wenn es akzeptabel ist, den Schlüssel in der Datenbank zwischenzuspeichern, kann man das Kommando, das den Schlüsel liefert, dazu verwenden, um PostgreSQL den Schlüssel aus dem HSM zur Verfügung zu stellen. Ein besserer Schutz vor Entwendung des Schlüssels ist es, jede Verschlüsselung und Entschlüsselung an das HSM zu delegieren. Dafür muss man eine spezielle Erweiterung in C schreiben.