Im Vorfeld des Starts eines neuen Kurses Wir haben für Sie die Übersetzung eines nützlichen Artikels vorbereitet.
Transparent Data Encryption (TDE) gibt es seit geraumer Zeit in MySQL. Aber haben Sie sich jemals gefragt, wie es im Hintergrund funktioniert und welche Auswirkungen TDE auf Ihren Server haben kann? In dieser Artikelreihe werden wir untersuchen, wie TDE im Inneren funktioniert. Beginnen wir mit der Schlüsselverwaltung, da sie für jede Verschlüsselung notwendig ist. Anschließend werden wir detailliert erörtern, wie die Verschlüsselung im Percona Server für MySQL/MySQL funktioniert und welche zusätzlichen Möglichkeiten der Percona Server für MySQL bietet.
MySQL Keyring
Keyring sind Plugins, die es dem Server ermöglichen, Schlüssel in einer lokalen Datei (keyring_file) oder auf einem entfernten Server (z. B. in HashiCorp Vault) anzufordern, zu erstellen und zu löschen. Die Schlüssel werden immer lokal zwischengespeichert, um deren Abruf zu beschleunigen.
Die Plugins lassen sich in zwei Kategorien einteilen:
- Lokaler Speicher. Zum Beispiel eine lokale Datei (wir nennen dies ein dateibasiertes Schlüssel-Repository, file-based keyring).
- Entferntes Speicher. Zum Beispiel Vault Server (wir nennen dies ein serverbasiertes Schlüssel-Repository, server-based keyring).
Diese Unterscheidung ist wichtig, da verschiedene Speichertypen sich sowohl bei der Speicherung und dem Abrufen von Schlüsseln als auch beim Starten etwas anders verhalten.
Bei der Verwendung von Dateispeicher 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 eines Serverspeichers (z. B. Vault-Server) werden beim Start nur die key id und der key user geladen, sodass das Abrufen aller Schlüssel den Start nicht verlangsamt. Die Schlüssel werden faul geladen. Das bedeutet, dass der Schlüssel von Vault nur geladen wird, wenn er tatsächlich benötigt wird. Nach dem Laden wird der Schlüssel im Speicher zwischengespeichert, damit in Zukunft keine TLS-Verbindung zum Vault-Server erforderlich ist. Schauen wir uns nun an, welche Informationen im Schlüsselspeicher vorhanden sind.
Die Schlüsselinformationen enthalten Folgendes:
- key id — die Schlüssel-ID, zum Beispiel:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - key type — der Schlüsselt, basierend auf dem verwendeten Verschlüsselungsalgorithmus, mögliche Werte: „AES“, „RSA“ oder „DSA“.
- key length — die Länge des Schlüssels in Bytes, AES: 16, 24 oder 32, RSA 128, 256, 512 und DSA 128, 256 oder 384.
- Benutzer — Eigentümer des Schlüssels. Ist der Schlüssel ein Systemschlüssel, wie zum Beispiel der Master Key, bleibt dieses Feld leer. Wenn der Schlüssel mit keyring_udf erstellt wird, bezeichnet dieses Feld den Eigentümer des Schlüssels.
- der Schlüssel
Der Schlüssel wird eindeutig durch das Paar: key_id, user identifiziert.
Es gibt auch Unterschiede in der Speicherung und Löschung von Schlüsseln.
Das Dateispeicher ist schneller. Man könnte annehmen, dass das Schlüsselspeicher eine einfache einmalige Speicherung eines Schlüssels in einer Datei ist, aber das ist nicht der Fall — hier erfolgen mehr Operationen. Bei jeder Modifikation des Dateispeichers wird zuerst eine Sicherungskopie des gesamten Inhalts erstellt. Angenommen, die Datei heißt my_biggest_secrets, dann wird die Sicherungskopie my_biggest_secrets.backup genannt. Danach wird der Cache geändert (Schlüssel werden hinzugefügt oder gelöscht) und, wenn alles erfolgreich abgeschlossen ist, wird der Cache in die Datei zurückgeschrieben. In seltenen Fällen, wie zum Beispiel bei einem Serverausfall, können Sie diese Sicherungsdatei sehen. Die Sicherungsdatei wird bei der 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 eine Verbindung zum MySQL-Server herstellen und die Befehle „Schlüssel senden“ / „Schlüssellöschung anfordern“ ausführen.
Kommen wir zurück zur Startgeschwindigkeit des Servers. Neben dem Einfluss des Repositorys auf die Startgeschwindigkeit stellt sich auch die Frage, wie viele Schlüssel aus dem Repository beim Start benötigt werden. Dies ist besonders wichtig für Server-Repositories. 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 Repository an. Auf einem „sauberen“ Server mit Master-Key-Verschlüsselung sollte nur ein Master Key vorhanden sein, der aus dem Repository extrahiert werden muss. Es kann jedoch auch erforderlich sein, mehrere Schlüssel zu verwenden, beispielsweise wenn eine Sicherung vom Hauptserver auf einem Backup-Server wiederhergestellt wird. In solchen Fällen sollte eine Rotation des Master Keys in Betracht gezogen werden. Dies wird in zukünftigen Artikeln näher behandelt, aber ich möchte hier erwähnen, dass ein Server, der mehrere Master Keys verwendet, möglicherweise etwas länger zum Starten benötigt, insbesondere bei Verwendung des Serverspeichers für Schlüssel.
Lassen Sie uns jetzt noch etwas über keyring_file sprechen. Bei der Entwicklung von keyring_file habe ich mir ebenfalls Gedanken darüber gemacht, wie man Änderungen am keyring_file während des Serverbetriebs überprüfen kann. In Version 5.7 erfolgte die Überprüfung auf Basis von Datei-Statistiken, was keine ideale Lösung war, und in Version 8.0 wurde sie durch eine SHA256-Prüfziffer ersetzt.
Bei der ersten Ausführung wird die Datei-Statistik und die Prüfziffer für keyring_file berechnet und vom Server gespeichert. Änderungen werden nur angewendet, wenn sie übereinstimmen. Bei einer Änderung der Datei wird die Prüfziffer aktualisiert.
Wir haben bereits viele Fragen zu Schlüsselspeichern behandelt. Es gibt jedoch noch ein weiteres wichtiges Thema, das oft vergessen oder missverstanden wird – die Trennung der Schlüssel nach Servern.
Was meine ich damit? Jeder Server (z.B. der Percona Server) in einem Cluster benötigt einen separaten Platz auf dem Vault-Server, an dem der Percona Server seine Schlüssel speichern kann. Jeder Master Key, der im Speicher abgelegt ist, enthält die GUID des Percona Servers in seiner Kennung. 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 einen 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. Die GUID sorgt jedoch für eine Trennung zwischen den Servern. Warum also über die Trennung von Schlüsseln zwischen Servern sprechen, wenn es bereits eine eindeutige GUID gibt? Es gibt noch ein weiteres 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 z.B. auf dem Server server1 einen Schlüssel erstellt und dann versucht, einen Schlüssel mit derselben Kennung auf server2 zu erstellen, z.B.:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 bedeutet erfolgreichen Abschluss
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Bitte warten. Beide Server verwenden denselben Vault Server; sollte die Funktion keyring_key_store nicht auf Server server2 mit einem Fehler enden? Es ist interessant, dass Sie einen Fehler erhalten, wenn Sie dasselbe auf einem Server versuchen:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Richtig, ROB_1 existiert bereits.
Lassen Sie uns zuerst das zweite Beispiel besprechen. Wie bereits erwähnt, cachen keyring_vault oder andere Speicher-Plugins (keyring) alle Schlüssel-IDs im Speicher. Daher wird, nachdem ein neuer Schlüssel erstellt wurde, ROB_1 auf server1 hinzugefügt, und zusätzlich zur Übermittlung dieses Schlüssels an Vault wird der Schlüssel auch im Cache gespeichert. Jetzt, wenn wir versuchen, denselben Schlüssel ein zweites Mal hinzuzufügen, überprüft keyring_vault, ob dieser Schlüssel im Cache existiert, und gibt einen Fehler aus.
Im ersten Fall ist die Situation anders. Auf den Servern server1 und server2 gibt es separate Caches. Nachdem ROB_1 dem Schlüsselcache auf dem Server server1 und dem Vault-Server hinzugefügt wurde, ist der Schlüsselcache auf server2 nicht synchronisiert. Im Cache auf server2 gibt es keinen Schlüssel ROB_1. Somit wird der Schlüssel ROB_1 im keyring_key_store und auf dem Vault-Server gespeichert, der das vorherige Wert (!) tatsächlich überschreibt. Jetzt hat der Schlüssel ROB_1 auf dem Vault-Server den Wert 543210987654321. Interessant ist, dass der Vault-Server solche Aktionen nicht blockiert und problemlos den alten Wert überschreibt.
Jetzt sehen wir, warum die Trennung nach Servern im Vault wichtig sein kann — wenn Sie keyring_udf verwenden und Schlüssel im Vault speichern möchten. Wie können Sie diese Trennung auf dem Vault-Server sicherstellen?
Es gibt zwei Möglichkeiten, eine Trennung im Vault zu erreichen. Sie können unterschiedliche Mount-Punkte für jeden Server erstellen oder verschiedene Pfade innerhalb eines Mount-Punkts verwenden. Am besten zeigt man dies mit Beispielen. Lassen Sie uns zunächst die separaten Mount-Punkte betrachten:
--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 ist zu sehen, dass server1 und server2 unterschiedliche Punkte für die Montage verwenden. Bei Trennung der Pfade wird 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 Montagepunkt „mount_point“, aber unterschiedliche Pfade. Wenn das erste Secret auf dem Server server1 unter diesem Pfad erstellt wird, erstellt der Vault-Server automatisch das Verzeichnis „server1“. Für server2 ist es analog. Wenn Sie das letzte Secret in mount_point/server1 oder mount_point/server2 löschen, entfernt der Vault-Server auch diese Verzeichnisse. Falls Sie die Trennung der Pfade verwenden, sollten Sie nur einen einzigen Montagepunkt erstellen und die Konfigurationsdateien ändern, damit die Server separate Pfade verwenden. Der Montagepunkt kann über 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 Sie auch Vault-Tools verwenden, um dasselbe zu tun. Aber es ist einfacher, die Erstellung des Einhängepunkts 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
