Kurz vor Beginn des neuen Kurses Wir haben für Sie die Übersetzung eines nützlichen Artikels vorbereitet.
Transparente Datenverschlüsselung (Transparent Data Encryption, TDE) gibt es seit und MySQL schon seit geraumer Zeit. Aber haben Sie sich jemals gefragt, wie es funktioniert und welchen Einfluss TDE auf Ihren Server haben kann? In dieser Artikelreihe werden wir untersuchen, wie TDE im Hintergrund funktioniert. Wir beginnen mit der Schlüsselverwaltung, da diese für jede Verschlüsselung erforderlich ist. Danach betrachten wir im Detail, wie die Verschlüsselung in Percona Server für MySQL/MySQL funktioniert und welche zusätzlichen Funktionen Percona Server für MySQL bietet.
MySQL Keyring
Keyring ist ein Plugin, das es dem Server ermöglicht, Schlüssel in einer lokalen Datei (keyring_file) oder auf einem Remote-Server (z. B. in HashiCorp Vault) anzufordern, zu erstellen und zu löschen. Die Schlüssel werden immer lokal zwischengespeichert, um ihre Abholung zu beschleunigen.
Die Plugins lassen sich in zwei Kategorien unterteilen:
- Lokale Speicherung. Zum Beispiel eine lokale Datei (wir nennen dies schlüsseldatenbasierte Speicherung, file-based keyring).
- Remote Speicherung. Zum Beispiel Vault Server (wir nennen dies serverbasierte Speicherung, server-based keyring).
Diese Unterscheidung ist wichtig, da sich verschiedene Speicherkategorien bei der Speicherung und Abholung von Schlüsseln sowie beim Starten etwas unterschiedlich verhalten.
Bei Verwendung der schlüsseldatenbasierten Speicherung wird beim Starten der gesamte Inhalt des Speichers in den Cache geladen: key id, key user, key type und der Schlüssel selbst.
Im Fall der serverbasierten Speicherung (z. B. Vault-Server) werden beim Start nur key id und key user geladen, sodass das Abrufen aller Schlüssel den Start nicht verlangsamt. Die Schlüssel werden faul geladen. Das bedeutet, der Schlüssel wird nur von Vault geladen, wenn er tatsächlich benötigt wird. Nach dem Laden wird der Schlüssel im Speicher zwischengespeichert, sodass er in Zukunft nicht mehr über TLS-Verbindungen zum Vault Server abgerufen werden muss. Schauen wir uns nun an, welche Informationen im Schlüsseldaten gespeichert sind.
Die Schlüsselinformation enthält Folgendes:
- key id — der Schlüssel-Identifikator, beispielsweise:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - key type — der Schlüsseltyp, basierend auf dem verwendeten Verschlüsselungsalgorithmus, mögliche Werte: „AES“, „RSA“ oder „DSA“.
- key length — die Schlüssellänge in Bytes, AES: 16, 24 oder 32, RSA 128, 256, 512 und DSA 128, 256 oder 384.
- Benutzer — der Schlüsselinhaber. Wenn der Schlüssel ein Systemschlüssel ist, wie z. B. der Master Key, ist dieses Feld leer. Wenn der Schlüssel mit Hilfe von keyring_udf erstellt wird, bezeichnet dieses Feld den Schlüsselinhaber.
- der Schlüssel selbst
Der Schlüssel wird eindeutig durch ein Paar identifiziert: key_id, user.
Es gibt auch Unterschiede beim Speichern und Löschen von Schlüsseln.
Der Datei-Speicher arbeitet schneller. Man könnte annehmen, dass das Schlüsselspeicher einfach eine einmalige Speicherung des Schlüssels in einer Datei ist, aber das ist nicht der Fall – hier erfolgen mehr Operationen. Bei jeder Modifikation des Datei-Speichers wird zunächst ein Backup des gesamten Inhalts erstellt. Angenommen, die Datei heißt my_biggest_secrets, dann wird das Backup my_biggest_secrets.backup heißen. Anschließend wird der Cache geändert (Schlüssel werden hinzugefügt oder entfernt) und, wenn alles erfolgreich abgeschlossen ist, wird der Cache in die Datei zurückgeschrieben. In seltenen Fällen, wie z.B. bei einem Serverausfall, können Sie diese Backup-Datei sehen. Die Backup-Datei wird beim nächsten Laden der Schlüssel gelöscht (normalerweise nach einem Serverneustart).
Beim Speichern oder Löschen eines Schlüssels im Server-Speicher muss das Speichergerät mit dem MySQL-Server über die Kommandos „Schlüssel senden“ / „Anforderung zur Schlüsselentfernung“ verbunden werden ("send the key" / "request key deletion").
Lassen Sie uns zur Startgeschwindigkeit des Servers zurückkehren. Neben dem Einfluss des Speichers auf die Startgeschwindigkeit gibt es auch die Frage, wie viele Schlüssel aus dem Speicher beim Start benötigt werden. Das ist insbesondere für Serverspeicher wichtig. Beim Start prüft der Server, welcher Schlüssel für die verschlüsselten Tabellen / Tablespaces benötigt wird, und fordert den Schlüssel aus dem Speicher an. Auf einem "sauberen" Server mit Master Key – Verschlüsselung sollte es einen Master Key geben, der aus dem Speicher abgerufen werden muss. Es können jedoch auch mehr Schlüssel erforderlich sein, z.B. wenn auf einem Backup-Server ein Backup vom Hauptserver wiederhergestellt wird. In solchen Fällen sollte eine Rotation des Master Keys eingeplant werden. Dies wird in zukünftigen Artikeln ausführlicher behandelt, aber ich möchte hier anmerken, dass ein Server, der mehrere Master Keys verwendet, etwas länger zum Starten benötigen kann, insbesondere bei der Verwendung eines Server-Schlüsselspeichers.
Lassen Sie uns nun noch etwas über keyring_file sprechen. Als ich keyring_file entwickelte, machte ich mir auch Sorgen darüber, wie man die Änderung von keyring_file während des Serverbetriebs überprüfen kann. In 5.7 wurde dies auf Basis der Dateistatistik überprüft, was keine ideale Lösung war, und wurde in 8.0 durch eine SHA256-Prüfziffer ersetzt.
Beim ersten Start von keyring_file werden die Dateistatistiken und die Prüfziffer berechnet, die vom Server gespeichert werden, und Änderungen werden nur angewendet, wenn sie übereinstimmen. Bei Änderungen der Datei wird die Prüfziffer aktualisiert.
Wir haben bereits viele Fragen zu Schlüsselspeichern behandelt. Dennoch gibt es ein weiteres wichtiges Thema, das oft vergessen oder missverstanden wird – die Trennung von Schlüsseln nach Servern.
Was meine ich damit? Jeder Server (z.B. Percona Server) in einem Cluster sollte einen eigenen Platz auf dem Vault-Server haben, wo Percona Server seine Schlüssel speichern kann. Jeder Master Key, der im Speicher gesichert wird, enthält die GUID des Percona Servers innerhalb seiner Identifikation. Warum ist das wichtig? Stellen Sie sich vor, Sie haben nur einen Vault-Server und alle Percona Server im Cluster nutzen diesen einzigen Vault-Server. Das Problem scheint offensichtlich. Wenn alle Percona Server den Master Key ohne eindeutige Identifikatoren verwenden würden, z.B. id = 1, id = 2 usw., würden alle Server im Cluster denselben Master Key verwenden. Was die GUID ermöglicht – die Abgrenzung zwischen den Servern. Warum also über die Trennung von Schlüsseln zwischen den Servern sprechen, wenn bereits eine eindeutige GUID existiert? Es gibt noch ein anderes Plugin – keyring_udf. Mit diesem Plugin kann der Benutzer Ihres Servers seine Schlüssel auf dem Vault-Server speichern. Das Problem tritt auf, wenn der Benutzer einen Schlüssel auf server1 erstellt und dann versucht, einen Schlüssel mit derselben Identifikation auf server2 zu erstellen, zum Beispiel:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 bedeutet, dass die Ausführung erfolgreich war
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Warten Sie. Beide Server verwenden denselben Vault-Server, sollte die Funktion keyring_key_store nicht mit einem Fehler auf server2 enden? Interessanterweise erhalten Sie, wenn Sie dasselbe auf demselben Server versuchen, eine Fehlermeldung:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Richtig, ROB_1 existiert bereits.
Lass uns zuerst das zweite Beispiel besprechen. Wie bereits erwähnt, speichert keyring_vault oder ein anderer Speicher-Plugin (keyring) alle Schlüssel-IDs im Speicher. Nach der Erstellung eines neuen Schlüssels wird ROB_1 auf server1 hinzugefügt. Neben dem Senden dieses Schlüssels an Vault wird der Schlüssel auch im Cache gespeichert. Wenn wir nun versuchen, denselben Schlüssel ein zweites Mal hinzuzufügen, überprüft keyring_vault, ob dieser Schlüssel im Cache bereits vorhanden ist, und gibt einen Fehler aus.
Im ersten Fall ist die Situation eine andere. Auf den Servern server1 und server2 gibt es separate Caches. Nachdem ROB_1 im Schlüssel-Cache auf server1 und dem Vault-Server hinzugefügt wurde, ist der Schlüssel-Cache auf server2 nicht synchronisiert. Im Cache auf server2 ist der Schlüssel ROB_1 nicht vorhanden. Daher wird der Schlüssel ROB_1 im keyring_key_store und auf dem Vault-Server gespeichert, wodurch der vorherige Wert tatsächlich überschrieben wird (!). Jetzt entspricht der Schlüssel ROB_1 auf dem Vault-Server 543210987654321. Interessanterweise blockiert der Vault-Server solche Aktionen nicht und überschreibt einfach den alten Wert.
Jetzt sehen wir, warum die Trennung nach Servern im Vault wichtig sein kann — insbesondere wenn Sie keyring_udf verwenden und Schlüssel im Vault speichern möchten. Wie kann man eine solche Trennung auf dem Vault-Server gewährleisten?
Es gibt zwei Möglichkeiten, eine Trennung im Vault zu erreichen. Man kann für jeden Server unterschiedliche Mount-Punkte erstellen oder unterschiedliche Pfade innerhalb eines Mount-Punkts verwenden. Am besten lässt sich das mit Beispielen zeigen. Schauen wir uns zunächst die separaten Mount-Punkte 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 = server2_mount
token = (...)
vault_ca = (...)Hier sehen wir, dass server1 und server2 unterschiedliche Mount-Punkte verwenden. Bei der Trennung der Pfade würde die Konfiguration wie folgt aussehen:
--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/server2
token = (...)
vault_ca = (...)In diesem Fall verwenden beide Server denselben Mount-Punkt «mount_point», aber unterschiedliche Pfade. Bei der Erstellung des ersten Secrets auf dem Server server1 an diesem Pfad erstellt der Vault-Server automatisch das Verzeichnis «server1». Für server2 ist alles ähnlich. Wenn Sie das letzte Secret in mount_point/server1 oder mount_point/server2 löschen, entfernt der Vault-Server ebenfalls diese Verzeichnisse. Falls Sie die Pfade trennen, müssen Sie nur einen einzigen Mount-Punkt erstellen und die Konfigurationsdateien ändern, damit die Server separate Pfade verwenden. Der Mount-Punkt kann durch eine HTTP-Anfrage erstellt werden. Mit CURL geht das wie folgt:
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 der Konfigurationsdatei. Natürlich können auch Vault-Utilities verwendet werden, um dasselbe zu tun. Aber so ist es einfacher, die Erstellung des Mount-Punkts zu automatisieren. Ich hoffe, diese Informationen sind für Sie nützlich, und wir sehen uns in den nächsten Artikeln dieser Serie.
Weiterlesen:
Quelle: habr.com
