Kurz vor Beginn des neuen Kurses wir setzen die Veröffentlichung einer Reihe von Artikeln zur Verschlüsselung in MySQL fort.
Im vorherigen Artikel dieser Reihe () haben wir über Schlüsselverwaltungen gesprochen. In diesem Artikel betrachten wir, wie der Masterkey 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 (Tablespace-Schlüssel) mit einem anderen Schlüssel (Masterkey) verschlüsselt werden. Für die Verschlüsselung der Daten werden tatsächlich die Tablespace-Schlüssel verwendet. Grafisch kann dies so dargestellt werden:
Der Masterkey befindet sich in der Schlüsselverwaltung (Keyring), und die Tablespace-Schlüssel sind in den Kopfzeilen der verschlüsselten Tablespaces (auf Seite 0 des Tablespaces).
Im obigen Bild:
Tabelle A ist mit Schlüssel 1 (Key 1) verschlüsselt. Schlüssel 1 wird mit dem Masterkey verschlüsselt und in verschlüsselter Form im Kopf von Tabelle A gespeichert.
Tabelle B ist mit Schlüssel 2 (Key 2) verschlüsselt. Schlüssel 2 wird mit dem Masterkey verschlüsselt und in verschlüsselter Form im Kopf von Tabelle B gespeichert.
Und so weiter.
Wenn der Server Tabelle A entschlüsseln muss, ruft er den Masterkey aus der Verwaltung ab, liest den verschlüsselten Schlüssel 1 aus dem Kopf 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 erfolgt die tatsächliche Verschlüsselung und Entschlüsselung auf der Eingabe-/Ausgabeebene. Das bedeutet, dass die Seite direkt vor dem Schreiben auf die Festplatte verschlüsselt und sofort nach dem Lesen von der Festplatte entschlüsselt wird.
In InnoDB funktioniert die Verschlüsselung nur auf der 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. Obwohl Sie Tabellen auch im allgemeinen Tablespace erstellen können (). Aber auf jeden Fall befindet sich der Raum 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 innerhalb des systemeigenen Tablespaces (system tablespace) erstellt. In kann das systemeigene Tablespace mit der Variablen innodbsystablespaceencrypt oder durch Verwendung von Verschlüsselungsströmen (encryption threads) verschlüsselt werden, aber dies ist immer noch eine experimentelle Funktion. In MySQL gibt es das nicht.
Bevor wir weitermachen, müssen wir die Struktur der Hauptschlüssel-ID (master key ID) betrachten. Sie besteht aus UUID, KEYID und dem Präfix „INNODBKey“. Das sieht so aus: INNODBKey-UUID-KEYID.
UUID ist die UUID des Servers mit dem verschlüsselten Tablespace. KEYID ist einfach ein ständig wachsendes Wert. Bei der anfänglichen Erstellung des Hauptschlüssels beträgt KEYID 1. Bei der Rotation des Schlüssels, wenn ein neuer Hauptschlüssel erstellt wird, beträgt KEYID = 2 und so weiter. Detaillierter werden wir über die Rotation der Hauptschlüssel in den kommenden Artikeln dieser Serie sprechen.
Jetzt, da wir wissen, wie die Hauptschlüssel-ID aussieht, schauen wir uns die Kopfzeile des verschlüsselten Tablespaces an. Wenn der Tablespace verschlüsselt wird, werden Informationen zur Verschlüsselung zur Kopfzeile hinzugefügt. Das sieht folgendermaßen aus:
KEY ID ist die KEYID aus der Hauptschlüssel-ID, die wir bereits besprochen haben. UUID ist die UUID des Servers, die ebenfalls in der Hauptschlüssel-ID verwendet wird. TABLESPACE KEY ist der Tablespace-Schlüssel, der aus 256 Bit besteht und zufällig vom Server generiert wird. Der Initialisierungsvektor (IV, initialization vector) besteht ebenfalls aus 256 zufällig generierten Bit (obwohl er 128 Bit haben sollte). IV wird zur Initialisierung der AES-Verschlüsselung und -Entschlüsselung verwendet (von den 256 Bit werden nur 128 verwendet). Am Ende befindet sich eine CRC32-Prüfziffer für TABLESPACE KEY und IV.
Während dieser ganzen Zeit habe ich es etwas vereinfacht gesagt, dass im Header ein verschlüsselter Schlüssel des Tabellenraums vorhanden ist. Tatsächlich werden der Schlüssel des Tabellenraums und der Initialisierungsvektor zusammen mit dem Hauptschlüssel gespeichert und verschlüsselt. Denken Sie daran, dass vor der Verschlüsselung des Schlüssels des Tabellenraums und des Initialisierungsvektors eine CRC32-Prüfziffer berechnet wird.
Warum ist CRC32 notwendig?
Kurz gesagt, um die Gültigkeit des Hauptschlüssels zu überprüfen. Nach der Entschlüsselung des Schlüssels des Tabellenraums und des Initialisierungsvektors wird eine Prüfziffer berechnet und mit der im Header gespeicherten CRC32 verglichen. Wenn die Prüfziffern übereinstimmen, haben wir den richtigen Hauptschlüssel und den Schlüssel des Tabellenraums. Andernfalls wird der Tabellenraum als fehlend gekennzeichnet (wir können ihn sowieso nicht entschlüsseln).
Sie fragen sich vielleicht: Wann erfolgt die Überprüfung der Schlüssel? Die Antwort ist: beim Start des Servers. Der Server mit verschlüsselten Tabellen / Tabellenräumen liest beim Start die UUID, den KEYID aus dem Header und generiert die ID des Hauptschlüssels. Dann erhält er den erforderlichen Hauptschlüssel aus dem Speicher (Keyring), entschlüsselt den Schlüssel des Tabellenraums und überprüft die Prüfziffer. Noch einmal, wenn die Prüfziffer übereinstimmt, dann ist alles in Ordnung, wenn nicht – wird der Tabellenraum als fehlend markiert.
Wenn Sie den vorherigen Artikel dieser Serie gelesen haben (), erinnern Sie sich vielleicht daran, dass beim Einsatz eines serverseitigen Schlüsselbundes 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. Und jetzt sage ich, dass der Server beim Start alle Schlüssel erhält, die er zur Überprüfung der Entschlüsselungsfähigkeit der Schlüssel der Tabellenräume benötigt. Warum also werden beim Initialisieren des serverseitigen Speichers nur keyid und userid geladen und nicht alle Schlüssel? Weil Sie möglicherweise nicht alle Schlüssel benötigen. Dies hängt hauptsächlich mit der Rotation des Hauptschlüssels zusammen. Bei der Rotation des Hauptschlüssels wird ein neuer Hauptschlüssel im Speicher erstellt, aber die alten Schlüssel werden nicht gelöscht. Daher können in dem serverseitigen Schlüsselbund viele Schlüssel vorhanden sein, die der Server nicht benötigt und die daher beim Start des Servers nicht abgerufen werden.
Es ist an der Zeit, ein wenig über die Vorzüge und Nachteile der Verschlüsselung mit einem Master Key zu sprechen. Der größte Vorteil besteht darin, dass Sie nur einen Verschlüsselungsschlüssel (den Master Key) benötigen, der separat von Ihren verschlüsselten Daten gespeichert wird. Dies ermöglicht einen schnellen Serverstart und eine kleine Speichergröße, was die Verwaltung erleichtert. Zudem lässt sich der einzige Master Key leicht regenerieren.
Allerdings hat die Verschlüsselung mit einem Master Key einen großen Nachteil: Sobald der Tablespace mit dem tablespace_key verschlüsselt ist, bleibt er immer mit demselben Schlüssel verschlüsselt. Eine Rotation des Master Keys hilft hier nicht. Warum ist das ein Nachteil? Wir wissen, dass es in MySQL Bugs gibt, die zu plötzlichen Abstürzen und zur Erstellung von Core-Dumps führen können. Da der Core-Dump einen Speicherabbild des Servers enthält, kann es passieren, dass der entschlüsselte Schlüssel des Tablespaces im Dump enthalten ist. Noch schlimmer ist, dass entschlüsselte Schlüssel des Tablespaces im Speicher gehalten werden, der auf die Festplatte swappt. Man könnte sagen, dass dies kein Nachteil ist, da für den Zugriff auf diese Dateien und den Swap-Bereich Root-Rechte erforderlich sind. Ja. Aber Root wird nur für eine gewisse Zeit benötigt. Sobald jemand Zugriff auf den entschlüsselten Schlüssel des Tablespaces hat, kann er/sie ihn weiterhin zur Entschlüsselung von Daten verwenden, selbst ohne Root-Rechte. Außerdem könnte die Festplatte gestohlen werden, und der Swap-Bereich/Core-Dumps können mit externen Tools gelesen werden. Das Ziel von TDE ist es, dies unlesbar zu machen, selbst wenn die Festplatte gestohlen wird. Es besteht die Möglichkeit, den Tablespace mit neu generierten Schlüsseln erneut zu verschlüsseln. Diese Funktion wird als Verschlüsselungs-Threads (encryption threads) bezeichnet und ist zum Zeitpunkt der Erstellung dieses Artikels noch experimentell.
Weiterlesen:
Quelle: habr.com
