PostgreSQL Verschlüsselung von Instanzen

Dieser PostgreSQL Patch von Cybertec ist derzeit die einzige Möglichkeit Instanzen (Cluster) transparent und auf hohem kryptografischen Level sicher zu verschlüsseln, unabhängig vom Betriebssystem oder der Verschlüsselung des Dateisystems.

Wie funktioniert die Verschlüsselung?

Mit dem Patch werden alle Daten eines PostgreSQL Clusters sicher im verschlüsselten Format auf einer Disk gespeichert (data-at-rest encryption). Wenn Daten von der Disk gelesen werden, werden diese Blocks wieder entschlüsselt. Vorausgesetzt wird, dass die Datenbank auf die Verschlüsselung vorbereitet wird und der Schlüssel zur Initialisierung der Tabelle beim Start vom Server gelesen werden kann. Der Verschlüsselungs-Key kann auf zwei Arten verfügbar gemacht werden: durch eine Umgebungsvariable oder einen speziellen Konfigurationsparameter, der einen benutzerdefinierten Schlüssel bereit stellt. So können auch spezielle Sicherheitsanforderungen berücksichtigt werden.

encryption_ext_web1

Details

Zur Verschlüsselung wird ein 128-Bit-AES-Algorithmus im XTS-Modus verwendet, der manchmal auch als XTS-AES bezeichnet wird. Es handelt sich dabei um einen block cypher mit zusätzlichem Sicherheitsmodul nach IEEE P1619-Standard. Der Schlüssel muss dem Server während jedes Startvorgangs bereitgestellt werden – wenn er nicht übereinstimmt, wird der Server nicht starten. Verschlüsselt wird mehr oder weniger alles – Heap-Dateien (Tabellen, Indizes, Sequenzen), xlog (wenn es auch Daten enthält), Clog, und temporäre Dateien, die während größeren Abfragen generiert werden.

Die durch Verschlüsselung / Entschlüsselung entstandene Performance Penalty hängt stark vom Anwendungsfall ab. Für alle Fälle, in denen die Arbeiten im PostgreSQL Buffer durchgeführt werden können, ist er praktisch vernachlässigbar.

Lizenz

PostgreSQL License

Download

HIER downloaden

FAQ

F: Was wird tatsächlich verschlüsselt?

A: Alles außer pg_stat_statements Erweiterungsdaten und temporäre Puffer für die logische Replikation (falls verwendet). Also Tabellen, Indizes, Transaktionslog (xlog), Clog, temporäre und unlogged Tabellen, Freespace und Sichtbarkeitskarten und TOAST.

 

F: Welche Verschlüsselungsmethode wird angewendet?

A: Industriestandard 128-Bit-XTS-AES-Blockchiffre.

 

F: Kann ich eine andere Verschlüsselungsmethode verwenden?

A: Das ist nicht so einfach. Man müsste dazu einige C-Routinen implementieren. Die Schnittstelle selbst sollte aber ausreichend sein.

 

F: Welche Performance Penalty ist zu erwarten?

A: Auf einem typischen Serversystem (wenn vorhanden) und wenn die Datenbank in den Shared Buffer passt, dann vernachlässigbar (<3%). Ansonten können IO-Operationen bis zu 2-3x langsamer sein. Zukünftige Versionen werden Hardware-Verschlüsselung unterstützen (mit AES-NI) und den Overhead voraussichtlich um ein Vielfaches reduzieren.

 

F: Kann ich eine verschlüsselte Datenbank auf eine neue Hauptversion upgraden?

A: Ja, da der neue Cluster mit dem alten Verschlüsselungsschlüssel initialisiert wird.

 

F: Ist es möglich, nur bestimmte Tabellen / Tablespaces zu verschlüsseln, um die Performance zu steigern?

A: Derzeit nicht. Theoretisch könnte dieses Feature noch hinzugefügt werden, aber da XLOG sowieso vollständig verschlüsselt wird und alle Änderungen normalerweise diesen passieren, wäre es vermutlich nicht nötig.

 

F: Ist es möglich, den Verschlüsselungsschlüssel zu ändern, wenn er kompromittiert wird?

A: Derzeit nicht, man müsste einen neuen Cluster mit Dump / Restore neu initialisieren. Sie können jedoch die Schlüsselsetup-Befehlsschnittstelle verwenden, um einen verschlüsselten Key-Speicher für den Master zu implementieren, in welchem Sie die Keys ändern können, die zum Entsperren des Hauptschlüssels verwendet werden.

 

F: Kann ich es in mein HSM integrieren?

A: Nicht einfach, aber es gibt zwei Möglichkeiten, eine HSM zu integrieren. Wenn das Caching des Schlüssels in der Datenbank ok ist, verwenden Sie die Schlüssel-Setup-Schnittstelle, um PostgreSQL den Key von der HSM mitzuteilen. Für einen besseren Schutz vor Schlüssel-Diebstahl von einem produktiven Datenbank-Server ist es möglich, die komplette Ver- und Entschlüsselung an die HSM zu delegieren. Dazu muss jedoch eine eigene HSM-spezifische C-Erweiterung geschrieben werden.

postsuppbutt1