PostgreSQL Transparent Data Encryption (TDE) 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 (Data Encryption)?
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 Data Encryption
Daten auf der Disk werden normalerweise direkt unmodifiziert und auf der Disk gespeichert. Diese Vorgehensweise bietet natürlich ein gewisses Risiko. Aus diesem Grund halten wir uns an die Erkenntnisse der „Disk Encryption Theory„. Für jede Art von File verwenden wir den korrekten AES-Mechanismus, der die Verschlüsselung auf 8k-Block Ebene vornimmt (beim Lesen und beim Schreiben). Das hat den Vorteil, dass die Daten auf der Disk sicher sind.
Intel / AMD bieten Hardware Support für AES Encryption – dadurch wird sichergestellt, dass die Auswirkungen von PostgreSQL TDE auf die Leistung minimal sind. Benchmarks haben gezeigt, dass der Impact im realen Betrieb quasi zu vernachlässigen ist.
Verschlüsselung des gesamten Datenbank-Ökosystems
Sicherheit ist kein isoliertes Thema. Um ein System wirklich zu sichern, müssen viele Ebenen berücksichtigt werden und es muss sichergestellt sein, dass alle Komponenten abgedeckt sind. PostgreSQL TDE ist daher die ideale Lösung für Ihre Infrastruktur.
PostgreSQL TDE bietet nicht nur eine Verschlüsselung der Daten auf der Disk, sondern stellt auch die Verschlüsselung des gesamten Ökosystems sicher, einschließlich…..
- Transportverschlüsselung (Client / Server) über SSL
- Verschlüsselte Replikation
- Vollständig gesicherte Replikate
PostgreSQL TDE lässt sich perfekt in SELinux integrieren und bietet eine solide Grundlage für Ihre gesamte Infrastruktur. Darüber hinaus stehen alle Funktionen des Standard-PostgreSQL zur Verfügung.
PostgreSQL TDE performance
Check out the performnce analysis that compares PostgreSQL v13 with PostgreSQL Transparent Data Encryption.
PostgreSQL Performance: encrypted vs. unencrypedFAQ
F: 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 AES-CTR 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.
F: Gibt es TDE auch für PostgreSQL Version 12 & 13?
A: Ja, TDE ist nun auch für PostgreSQL Version 12.3 & 13.4 verfügbar. Gerne erstellt Ihnen unser Sales-Team ein unverbindliches Angebot!
F: Ich habe einen Bug gefunden. Wohin darf ich mich wenden?
A: Bitte jegliche Bugs und Probleme mit TDE direkt an bugs-tde@cybertec.at richten.
PostgreSQL Verschlüsselung auf Instanz-Ebene Download
Für die neusten Versionen erstellt Ihnen unser Sales-Team gerne ein unverbindliches Angebot!
Jetzt anfragen!