Im Vorfeld des Starts eines neuen Kurses setzen wir die Veröffentlichung unserer Artikelreihe über die Verschlüsselung in MySQL fort.
In dem vorherigen Artikel dieser Reihe () haben wir über Schlüsselmanagement gesprochen. In diesem Artikel betrachten wir, wie der Master-Schlüssel verwendet wird und diskutieren die Vor- und Nachteile der Envelope-Verschlüsselung.
Die Idee der Envelope-Verschlüsselung besteht darin, dass die zur Verschlüsselung verwendeten Schlüssel (Tabellenraumschlüssel) mit einem anderen Schlüssel (dem Master-Schlüssel) verschlüsselt werden. Tatsächlich werden für die Verschlüsselung der Daten die Tabellenraumschlüssel verwendet. Grafisch kann man sich das so vorstellen:
Der Master-Schlüssel befindet sich im Schlüsselbund (Keyring), während die Tabellenraumschlüssel in den Überschriften der verschlüsselten Tabellenräume (auf Seite 0 des Tabellenraums) liegen.
In der Abbildung oben:
Tabelle A ist mit Schlüssel 1 (Key 1) verschlüsselt. Schlüssel 1 wird mit dem Master-Schlüssel verschlüsselt und in verschlüsselter Form in der Überschrift von Tabelle A gespeichert.
Tabelle B wird mit Schlüssel 2 (Key 2) verschlüsselt. Schlüssel 2 wird mit dem Hauptschlüssel (masker key) verschlüsselt und in verschlüsselter Form im Header von Tabelle B gespeichert.
Und so weiter.
Wenn der Server Tabelle A entschlüsseln muss, ruft er den Hauptschlüssel aus dem Speicher ab, liest den verschlüsselten Schlüssel 1 aus dem Header von Tabelle A und entschlüsselt Schlüssel 1. Der entschlüsselte Schlüssel 1 wird im Speicher des Servers zwischengespeichert und zur Entschlüsselung von Tabelle A verwendet.
InnoDB
In InnoDB erfolgen die tatsächliche Verschlüsselung und Entschlüsselung auf der Ein-/Ausgabe-Ebene. Das heißt, die Seite wird unmittelbar vor dem Speichern auf die Festplatte verschlüsselt und sofort nach dem Lesen von der Festplatte entschlüsselt.
In InnoDB funktioniert die Verschlüsselung nur auf Ebene der Tablespaces. Standardmäßig werden alle Tabellen in separaten Tablespaces erstellt (). Mit anderen Worten, es wird ein Tablespace erstellt, der nur eine Tabelle enthalten kann. Zwar können Sie auch Tabellen im allgemeinen Tablespace erstellen (). Aber in jedem Fall befindet sich die Tabelle immer in einem bestimmten Tablespace. Und da die Verschlüsselung auf der Ebene des Tablespaces durchgeführt wird, ist sie entweder vollständig verschlüsselt oder nicht. Das bedeutet, dass es im Haupt-Tablespace nicht möglich ist, nur einen Teil der Tabellen zu verschlüsseln.
Wenn aus irgendeinem Grund file-per-table deaktiviert ist, werden alle Tabellen im systemeigenen Tablespace (system tablespace) erstellt. In kann der systemeigenen Tablespace mit der Variablen innodbsystablespaceencrypt oder unter Verwendung von Verschlüsselungsströmen (encryption threads) verschlüsselt werden, aber dies bleibt eine experimentelle Funktion. In MySQL gibt es das nicht.
Bevor wir weitergehen, müssen wir die Struktur der Master Key ID betrachten. Sie besteht aus UUID, KEYID und dem Präfix „INNODBKey“. Es sieht so aus: INNODBKey-UUID-KEYID.
UUID ist die UUID des Servers mit dem verschlüsselten Tablespace. KEYID ist einfach ein ständig wachsender Wert. Bei der Erstgenerierung des Hauptschlüssels beträgt der KEYID 1. Bei der Schlüsselrotation, wenn ein neuer Hauptschlüssel erstellt wird, wird der KEYID = 2 und so weiter. Mehr Details zur Rotation der Hauptschlüssel werden wir in den folgenden Artikeln dieser Serie besprechen.
Jetzt, da wir wissen, wie die Identifikation des Hauptschlüssels aussieht, schauen wir uns den Header des verschlüsselten Tablespaces an. Wenn der Tablespace verschlüsselt ist, wird die Verschlüsselungsinformation dem Header hinzugefügt. Sie sieht folgendermaßen aus:
KEY ID — dies ist der KEYID aus der Identifikation des Hauptschlüssels, die wir bereits diskutiert haben. UUID ist die UUID des Servers, die ebenfalls in der Identifikation des Hauptschlüssels verwendet wird. TABLESPACE KEY — der Key des Tablespaces, der aus 256 Bit besteht und zufällig vom Server generiert wurde. Der Initialisierungsvektor (IV, initialization vector) besteht ebenfalls aus 256 zufällig generierten Bits (obwohl er 128 Bit betragen sollte). IV wird zur Initialisierung der AES-Verschlüsselung und -Entschlüsselung verwendet (von den 256 Bits werden nur 128 verwendet). Am Ende befindet sich eine CRC32-Prüfziffer für den TABLESPACE KEY und den IV.
Während dieser Zeit habe ich es ein wenig vereinfacht, indem ich sagte, dass im Header ein verschlüsselter Schlüssel des Tabellenspeichers vorhanden ist. Tatsächlich werden der Schlüssel des Tabellenspeichers und der Initialisierungsvektor gemeinsam mit dem Hauptschlüssel gespeichert und verschlüsselt. Denken Sie daran, dass vor der Verschlüsselung des Schlüssels des Tabellenspeichers und des Initialisierungsvektors zunächst ein CRC32 berechnet wird.
Warum ist CRC32 wichtig?
Kurz gesagt, um die Gültigkeit des Hauptschlüssels sicherzustellen. Nach der Entschlüsselung des Schlüssels des Tabellenspeichers und des Initialisierungsvektors wird eine Prüfziffer berechnet und mit dem im Header gespeicherten CRC32 verglichen. Wenn die Prüfziffern übereinstimmen, haben wir den korrekten Hauptschlüssel und den Schlüssel des Tabellenspeichers. Andernfalls wird der Tabellenspeicher als nicht vorhanden markiert (wir können ihn trotzdem nicht entschlüsseln).
Sie fragen sich vielleicht: Wann erfolgt die Überprüfung der Schlüssel? Die Antwort lautet: beim Start des Servers. Ein Server mit verschlüsselten Tabellen / Tabellenspeichern liest beim Start die UUID, den KEYDie ID aus dem Header wird verwendet, um einen Hauptschlüssel-Identifikator zu generieren. Anschließend wird der benötigte Hauptschlüssel aus dem Schlüsselverzeichnis (keyring) abgerufen, der Schlüssel des Tabellenraums entschlüsselt und die Prüfziffer überprüft. Wenn die Prüfziffer übereinstimmt, ist alles in Ordnung; wenn nicht, wird der Tabellenraum als nicht vorhanden markiert.
Falls Sie den vorherigen Artikel dieser Serie gelesen haben (), erinnern Sie sich vielleicht, dass beim Einsatz eines serverseitigen Schlüsselverzeichnisses der Server beim Start nur eine Liste von Schlüssel-IDs erhält, genauer gesagt, key id und user id, da dieses Paar den Schlüssel eindeutig identifiziert. Jetzt sage ich jedoch, dass der Server beim Start alle Schlüssel erhält, die er benötigt, um die Möglichkeit der Entschlüsselung der Schlüssel für die Tabellenräume zu überprüfen. Warum werden also beim Initialisieren im Fall des serverseitigen Schlüsselverzeichnisses nur keyid und userid und nicht alle Schlüssel? Denn möglicherweise benötigen Sie nicht alle Schlüssel. Grundsätzlich hängt das mit der Rotation des Hauptschlüssels zusammen. Bei der Rotation des Hauptschlüssels wird im Speicher ein neuer Hauptschlüssel erstellt, während die alten Schlüssel nicht gelöscht werden. So kann es sein, dass sich viele Schlüssel im Serverspeicher befinden, die für den Server nicht erforderlich sind und daher beim Start des Servers nicht abgerufen werden.
Es ist an der Zeit, ein wenig über die Vor- und Nachteile der Verschlüsselung mit einem Hauptschlüssel zu sprechen. Der größte Vorteil liegt darin, dass Sie nur einen Verschlüsselungsschlüssel (den Hauptschlüssel) benötigen, der getrennt von Ihren verschlüsselten Daten aufbewahrt wird. Das macht den Serverstart schnell und der Speicher klein, was das Management erleichtert. Zudem ist der einzige Hauptschlüssel leicht neu zu generieren.
Die Verschlüsselung mit dem Hauptschlüssel hat jedoch einen großen Nachteil: Sobald das Tabellen-Layout mit dem tablespace_key verschlüsselt ist, bleibt es immer mit demselben Schlüssel verschlüsselt. Eine Rotation des Hauptschlüssels hilft hier nicht. Warum ist das ein Nachteil? Wir wissen, dass MySQL Bugs hat, die zu plötzlichen Abstürzen führen und eine core-Datei erzeugen können. Da die core-Datei einen Speicher-Dump des Servers enthält, kann es vorkommen, dass der entschlüsselte Schlüssel des Tabellen-Layouts im Dump enthalten ist. Noch schlimmer ist, dass die entschlüsselten Schlüssel des Tabellen-Layouts im Speicher gehalten werden, der auf die Festplatte gepuffert werden kann. Man könnte sagen, dass dies kein Nachteil ist, da man Root-Rechte benötigt, um auf diese Dateien und den Swap-Bereich zuzugreifen. Ja. Aber Root-Rechte sind nur kurzfristig erforderlich. Sobald jemand Zugriff auf den entschlüsselten Schlüssel des Tabellen-Layouts hat, kann er/sie ihn weiterhin zur Entschlüsselung von Daten verwenden, selbst ohne Root-Rechte. Zudem kann die Festplatte gestohlen werden, und der Swap-Bereich/core-Dateien können mit Drittanbieter-Tools gelesen werden. Das Ziel von TDE ist es, sie unlesbar zu machen, selbst wenn die Festplatte gestohlen wird. Es besteht die Möglichkeit, den Tabellenraum mit neu generierten Schlüsseln erneut zu verschlüsseln. Diese Funktion wird als Encryption Threads bezeichnet und ist zum Zeitpunkt des Schreibens dieses Artikels noch experimentell.
Weiterlesen:
Quelle: habr.com
