Transparente Datenverschlüsselung (TDE) gibt es in Percona Server für MySQL und MySQL schon lange. Aber haben Sie sich jemals gefragt, wie es unter der Haube funktioniert und welche Auswirkungen TDE auf Ihren Server haben kann? In dieser Artikelserie sehen wir uns an, wie TDE intern funktioniert. Beginnen wir mit der Speicherung von Schlüsseln, da dies erforderlich ist, damit eine Verschlüsselung funktioniert. Anschließend werden wir uns genauer ansehen, wie die Verschlüsselung in Percona Server für MySQL / MySQL funktioniert und welche zusätzlichen Funktionen in Percona Server für MySQL verfügbar sind.
MySQL-Schlüsselring
Schlüsselbunde sind Plugins, mit denen der Server Schlüssel in einer lokalen Datei (keyring_file) oder auf einem Remote-Server (z. B. in HashiCorp Vault) abfragen, erstellen und löschen kann. Schlüssel werden immer lokal zwischengespeichert, um das Abrufen zu beschleunigen.
Plugins können in zwei Kategorien unterteilt werden:
- Lokaler Speicher. Zum Beispiel eine lokale Datei (wir nennen dies einen dateibasierten Schlüsselring).
- Remote-Speicher. Zum Beispiel Vault Server (wir nennen diesen serverbasierten Schlüsselring).
Diese Trennung ist wichtig, da sich verschiedene Speichertypen nicht nur beim Speichern und Abrufen von Schlüsseln, sondern auch beim Starten geringfügig unterschiedlich verhalten.
Bei Verwendung eines Dateispeichers wird beim Start der gesamte Inhalt des Speichers in den Cache geladen: Schlüssel-ID, Schlüsselbenutzer, Schlüsseltyp und der Schlüssel selbst.
Bei einem Back-End-Tresor (z. B. einem Tresorserver) werden beim Start nur die Schlüssel-ID und der Schlüsselbenutzer geladen, sodass das Abrufen aller Schlüssel den Start nicht verlangsamt. Schlüssel werden träge geladen. Das heißt, der Schlüssel selbst wird nur dann aus Vault geladen, wenn er tatsächlich benötigt wird. Nach dem Laden wird der Schlüssel im Speicher zwischengespeichert, sodass in Zukunft kein Zugriff mehr über TLS-Verbindungen zum Vault-Server erforderlich ist. Schauen wir uns als nächstes an, welche Informationen im Schlüsselspeicher vorhanden sind.
Die Schlüsselinformationen enthalten Folgendes:
- key id — , :
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - key type — , , : «AES», «RSA» «DSA».
- key length — , AES: 16, 24 32, RSA 128, 256, 512 DSA 128, 256 384.
- user — . , , Master Key, . keyring_udf, .
Der Schlüssel wird durch das Paar eindeutig identifiziert: key_id, user.
Es gibt auch Unterschiede bei der Lagerung und Entsorgung von Schlüsseln.
Die Dateispeicherung ist schneller. Man könnte annehmen, dass ein Schlüsselspeicher ein einfaches einmaliges Schreiben eines Schlüssels in eine Datei ist, aber nein - hier werden weitere Vorgänge ausgeführt. Bei jeder Änderung des Dateispeichers wird zunächst eine Sicherungskopie aller Inhalte erstellt. Angenommen, die Datei heißt my_biggest_secrets, dann lautet die Sicherung my_biggest_secrets.backup. Als nächstes wird der Cache geändert (Schlüssel werden hinzugefügt oder entfernt), und wenn alles erfolgreich ist, wird der Cache in eine Datei geleert. In seltenen Fällen, z. B. bei einem Serverabsturz, wird diese Sicherungsdatei möglicherweise angezeigt. Die Sicherungsdatei wird beim nächsten Laden der Schlüssel gelöscht (normalerweise nach einem Neustart des Servers).
Beim Speichern oder Löschen eines Schlüssels im Server-Repository muss das Repository mit den Befehlen "Schlüssel senden" / "Schlüssel löschen löschen" eine Verbindung zum MySQL-Server herstellen.
Kehren wir zur Startgeschwindigkeit des Servers zurück. Neben der Tatsache, dass der Speicher selbst die Startgeschwindigkeit beeinflusst, stellt sich auch die Frage, wie viele Schlüssel aus dem Speicher Sie beim Start benötigen. Dies ist natürlich besonders wichtig für die Back-End-Speicherung. Beim Start prüft der Server, welcher Schlüssel für verschlüsselte Tabellen / Tablespaces erforderlich ist, und fordert den Schlüssel aus dem Speicher an. Auf einem "sauberen" Server mit Hauptschlüsselverschlüsselung muss ein Hauptschlüssel vorhanden sein, der aus dem Speicher abgerufen werden muss. Es können jedoch weitere Schlüssel erforderlich sein, beispielsweise beim Wiederherstellen einer Sicherung vom Primärserver auf einem Sicherungsserver. In solchen Fällen sollte eine Hauptschlüsselrotation bereitgestellt werden. Dies wird in zukünftigen Artikeln ausführlicher besprochen, obwohl ich hier darauf hinweisen möchte, dass der Server,Die Verwendung mehrerer Hauptschlüssel kann etwas länger dauern, insbesondere bei Verwendung eines serverseitigen Schlüsselspeichers.
Lassen Sie uns nun etwas mehr über keyring_file sprechen. Bei der Entwicklung von keyring_file war ich auch besorgt darüber, wie ich bei laufendem Server nach Änderungen an keyring_file suchen kann. In 5.7 wurde die Prüfung auf der Grundlage von Dateistatistiken durchgeführt, was keine ideale Lösung war, und in 8.0 wurde sie durch eine SHA256-Prüfsumme ersetzt.
Wenn Sie keyring_file zum ersten Mal ausführen, werden die Dateistatistiken und die Prüfsumme vom Server berechnet und gespeichert. Die Änderungen werden nur angewendet, wenn sie übereinstimmen. Die Prüfsumme wird aktualisiert, wenn die Datei geändert wird.
Wir haben bereits viele Fragen zu Keystores behandelt. Es gibt jedoch ein anderes wichtiges Thema, das häufig vergessen oder missverstanden wird - die gemeinsame Nutzung von Schlüsseln zwischen Servern.
Was ich meine? Jeder Server (z. B. Percona Server) im Cluster muss einen separaten Speicherort auf dem Vault-Server haben, auf dem der Percona Server seine Schlüssel speichern muss. Jeder im Repository gespeicherte Hauptschlüssel enthält die GUID des Percona-Servers in seiner Kennung. Warum ist es wichtig? Stellen Sie sich vor, Sie haben nur einen Vault-Server und alle Percona-Server im Cluster verwenden diesen einzelnen Vault-Server. Das Problem scheint offensichtlich. Wenn alle Percona-Server den Hauptschlüssel ohne eindeutige Kennungen wie id = 1, id = 2 usw. verwenden würden, würden alle Server im Cluster denselben Hauptschlüssel verwenden. Dies bietet die GUID - die Unterscheidung zwischen Servern. Warum dann über die gemeinsame Nutzung von Schlüsseln zwischen Servern sprechen, wenn bereits eine eindeutige GUID vorhanden ist? Es gibt noch ein Plugin - keyring_udf.Mit diesem Plugin kann Ihr Serverbenutzer seine Schlüssel auf dem Vault-Server speichern. Das Problem tritt auf, wenn ein Benutzer beispielsweise auf Server1 einen Schlüssel erstellt und dann versucht, auf Server2 einen Schlüssel mit derselben ID zu erstellen, z. B.:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Warten. Beide Server verwenden denselben Vault-Server. Sollte die Funktion keyring_key_store auf Server2 nicht fehlschlagen? Interessanterweise erhalten Sie eine Fehlermeldung, wenn Sie versuchen, dasselbe auf demselben Server zu tun:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Das stimmt, ROB_1 existiert bereits.
Lassen Sie uns zuerst das zweite Beispiel diskutieren. Wie bereits erwähnt, werden mit keyring_vault oder einem anderen Keyring-Plugin alle Schlüssel-IDs im Speicher zwischengespeichert. Nach dem Erstellen eines neuen Schlüssels wird ROB_1 zu Server1 hinzugefügt, und neben dem Senden dieses Schlüssels an Vault wird der Schlüssel auch dem Cache hinzugefügt. Wenn wir nun versuchen, denselben Schlüssel ein zweites Mal hinzuzufügen, prüft keyring_vault, ob dieser Schlüssel im Cache vorhanden ist, und gibt einen Fehler aus.
Im ersten Fall ist die Situation anders. Server1 und Server2 haben separate Caches. Nach dem Hinzufügen von ROB_1 zu den Schlüsselcaches auf Server1 und Vault sind die Schlüsselcaches auf Server2 nicht synchron. Es gibt keinen ROB_1-Schlüssel im Cache auf Server2. Daher wird der ROB_1-Schlüssel in den keyring_key_store und in den Vault-Server geschrieben, der den vorherigen Wert tatsächlich überschreibt (!). Jetzt lautet der Schlüssel ROB_1 auf dem Vault-Server 543210987654321. Interessanterweise blockiert der Vault-Server solche Aktionen nicht und überschreibt den alten Wert leicht.
Wir können jetzt sehen, warum die Aufteilung auf Server in einem Tresor wichtig sein kann - wenn Sie keyring_udf verwenden und Schlüssel in einem Tresor speichern möchten. Wie stellen Sie diese Trennung auf dem Vault-Server bereit?
Es gibt zwei Möglichkeiten, sich in Vault aufzuteilen. Sie können für jeden Server unterschiedliche Einhängepunkte erstellen oder unterschiedliche Pfade innerhalb desselben Einhängepunkts verwenden. Dies lässt sich am besten anhand von Beispielen veranschaulichen. Schauen wir uns also zuerst die einzelnen Einhängepunkte an:
--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)Hier können Sie sehen, dass Server1 und Server2 unterschiedliche Einhängepunkte verwenden. Beim Aufteilen von Pfaden sieht die Konfiguration folgendermaßen aus:
--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)In diesem Fall verwenden beide Server denselben mount_point, jedoch unterschiedliche Pfade. Wenn das erste Geheimnis auf Server1 entlang dieses Pfads erstellt wird, erstellt der Tresor automatisch das Verzeichnis "Server1". Für Server2 ist alles gleich. Wenn Sie das letzte Geheimnis in mount_point / server1 oder mount_point / server2 entfernen, entfernt der Vault-Server auch diese Verzeichnisse. Wenn Sie die Pfadaufteilung verwenden, müssen Sie nur einen Einhängepunkt erstellen und die Konfigurationsdateien so ändern, dass die Server separate Pfade verwenden. Ein Einhängepunkt kann mithilfe einer HTTP-Anforderung erstellt werden. Mit CURL geht das folgendermaßen:
curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTAlle Felder (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) entsprechen den Parametern in der Konfigurationsdatei. Sie können natürlich auch die Vault-Dienstprogramme verwenden, um dasselbe zu tun. Dies erleichtert jedoch die Automatisierung der Erstellung des Einhängepunkts. Ich hoffe, Sie finden diese Informationen hilfreich und wir sehen uns in den nächsten Artikeln dieser Reihe.
Weiterlesen: