Mysql
 sql >> Datenbank >  >> RDS >> Mysql

So sichern Sie eine verschlüsselte Datenbank mit Percona Server für MySQL 8.0

Produktionsunterbrechungen werden fast garantiert irgendwann vorkommen. Wir wissen es, also planen wir Backups, erstellen Recovery-Standby-Datenbanken und konvertieren einzelne Instanzen in Cluster.

Da wir die Notwendigkeit eines angemessenen Wiederherstellungsszenarios zugeben, müssen wir den möglichen Notfallzeitplan und Ausfallszenarien analysieren und Schritte implementieren, um Ihre Datenbank zum Laufen zu bringen. Die geplante Ausführung eines Ausfalls kann bei der Vorbereitung, Diagnose und Wiederherstellung des nächsten Ausfalls helfen. Um die Auswirkungen von Ausfallzeiten abzumildern, benötigen Unternehmen einen geeigneten Wiederherstellungsplan, der alle Faktoren umfasst, die erforderlich sind, um den Service zum Leben zu erwecken.

Das Backup-Management ist nicht so mild wie das einfache Planen eines Backup-Jobs. Es gibt viele Faktoren zu berücksichtigen, wie z. B. Aufbewahrung, Speicherung, Überprüfung und ob die von Ihnen erstellten Backups physisch oder logisch sind, und was leicht übersehen werden kann Sicherheit.

Viele Organisationen variieren ihren Backup-Ansatz und versuchen, eine Kombination aus Server-Image-Backups (Snapshots), logischen und physischen Backups an mehreren Orten zu speichern. Es dient dazu, lokale oder regionale Katastrophen zu vermeiden, die unsere Datenbanken und Sicherungen, die im selben Rechenzentrum gespeichert sind, löschen würden.

Wir wollen es sicher machen. Daten und Backups sollten verschlüsselt werden. Aber es gibt viele Implikationen, wenn beide Optionen vorhanden sind. In diesem Artikel werfen wir einen Blick auf Sicherungsverfahren, wenn es um verschlüsselte Datenbanken geht.

Encryption-at-Rest für Percona Server für MySQL 8.0

Ab MySQL 5.7.11 begann die Community-Version von MySQL mit der Unterstützung der InnoDB-Tablespace-Verschlüsselung. Es wird als transparente Tablespace-Verschlüsselung bezeichnet oder als Encryption-at-Rest bezeichnet.

Der Hauptunterschied zur Enterprise-Version ist die Art und Weise, wie die Schlüssel gespeichert werden – Schlüssel befinden sich nicht in einem sicheren Tresor, was für die Einhaltung gesetzlicher Vorschriften erforderlich ist. Gleiches gilt für Percona Server, ab Version 5.7.11 ist es möglich, InnoDB-Tablespace zu verschlüsseln. In Percona Server 8.0 wurde die Unterstützung für die Verschlüsselung von Binärprotokollen stark erweitert. Version 8.0 hinzugefügt 

(Pro Versionsdokument von Percona 8.0):

  • Temporäre Dateiverschlüsselung
  • InnoDB Tablespace-Verschlüsselung rückgängig machen
  • InnoDB-System-Tablespace-Verschlüsselung (InnoDB-System-Tablespace-Verschlüsselung)
  • default_table_encryption  =OFF/ON (Allgemeine Tablespace-Verschlüsselung)
  • table_encryption_privilege_check =OFF/ON (Überprüfen der Verschlüsselungseinstellungen)
  • InnoDB-Redo-Log-Verschlüsselung (nur für Master-Key-Verschlüsselung) (Redo-Log-Verschlüsselung)
  • Verschlüsselung der InnoDB-Zusammenführungsdatei (Überprüfen der Verschlüsselungseinstellung)
  • Percona Parallel Doublewrite Buffer Encryption (InnoDB Tablespace Encryption)

Für diejenigen, die an einer Migration von der MySQL-Enterprise-Version zu Percona interessiert sind:Es ist auch möglich, den Hashicorp-Vault-Server über ein keyring_vault-Plug-in zu integrieren, das den Funktionen entspricht, die in der MySQL-Enterprise-Edition von Oracle verfügbar sind.

Die Data-at-Rest-Verschlüsselung erfordert ein Schlüsselbund-Plugin. Hier gibt es zwei Möglichkeiten:

  • keyring_file - eine flache Datei mit einem Verschlüsselungsschlüssel
  • Keyring Vault-Plug-in – ein Dienst

So aktivieren Sie die Tablespace-Verschlüsselung

Um die Verschlüsselung zu aktivieren, starten Sie Ihre Datenbank mit der Option --early-plugin-load:

entweder von Hand:

$ mysqld --early-plugin-load="keyring_file=keyring_file.so"

oder durch Ändern der Konfigurationsdatei:

[mysqld]

early-plugin-load=keyring_file.so

Beim Starten von Percona Server 8.0 können zwei Arten von Tablespaces verschlüsselt werden. Allgemeiner Tablespace und System-Tablespace. Der Sys-Tablespace wird über den Parameter innodb_sys_tablespace_encrypt gesteuert. Standardmäßig ist der sys-Tablespace nicht verschlüsselt, und wenn Sie bereits einen haben, ist es nicht möglich, ihn in den verschlüsselten Zustand zu konvertieren, es muss eine neue Instanz erstellt werden (starten Sie eine Instanz mit der Option --bootstrap).

Allgemeiner Tablespace unterstützt die Verschlüsselung entweder aller Tabellen im Tablespace oder keiner. Es ist nicht möglich, die Verschlüsselung im gemischten Modus auszuführen. Um einen Tablespace mit Verschlüsselung zu erstellen, verwenden Sie das Flag ENCRYPTION='Y/N'.

Beispiel:

mysql> CREATE TABLESPACE severalnines ADD DATAFILE 'severalnines.ibd' ENCRYPTION='Y';

Eine verschlüsselte Datenbank sichern

Wenn Sie verschlüsselte Tablespaces hinzufügen, ist es notwendig, die Schlüsselbunddatei in den xtrabackup-Befehl aufzunehmen. Dazu müssen Sie den Pfad zu einer Schlüsselbunddatei als Wert der Option --keyring-file-data angeben.

$ xtrabackup --backup --target-dir=/u01/mysql/data/backup/ --user=root --keyring-file-data=/u01/secure_location/keyring_file

Achten Sie darauf, die Schlüsselbunddatei an einem sicheren Ort zu speichern. Stellen Sie außerdem sicher, dass Sie immer eine Sicherungskopie der Datei haben. Xtrabackup kopiert die Schlüsselbunddatei nicht in das Sicherungsverzeichnis. Um die Sicherung vorzubereiten, müssen Sie selbst eine Kopie der Schlüsselbunddatei erstellen.

Vorbereitung der Sicherung

Sobald wir unsere Sicherungsdatei haben, sollten wir sie für die Wiederherstellung vorbereiten. Hier müssen Sie auch die Schlüsselbund-Dateidaten angeben.

$ xtrabackup --prepare --target-dir=/u01/mysql/data/backup/ --keyring-file-data=/u01/secure_location/keyring_file

Das Backup ist nun vorbereitet und kann mit der Option --copy-back wiederhergestellt werden. Falls der Schlüsselbund rotiert wurde, müssen Sie den Schlüsselbund wiederherstellen (der zum Erstellen und Vorbereiten der Sicherung verwendet wurde).

Um das Backup xtrabackup vorzubereiten, benötigen wir Zugriff auf den Schlüsselbund. Xtrabackup kommuniziert nicht direkt mit dem MySQL-Server und liest die standardmäßige my.cnf-Konfigurationsdatei während der Vorbereitung nicht, geben Sie die Schlüsselbundeinstellungen über die Befehlszeile an:

$ xtrabackup --prepare --target-dir=/data/backup --keyring-vault-config=/etc/vault.cnf

Das Backup ist nun vorbereitet und kann mit der Option --copy-back wiederhergestellt werden:

$ xtrabackup --copy-back --target-dir=/u01/backup/ --datadir=/u01/mysql/data/

Durchführen inkrementeller Backups

Der Vorgang des Erstellens inkrementeller Backups mit InnoDB-Tablespace-Verschlüsselung ähnelt dem Erstellen derselben inkrementellen Backups mit einem unverschlüsselten Tablespace.

Um eine inkrementelle Sicherung zu erstellen, beginnen Sie mit einer vollständigen Sicherung. Die xtrabackup-Binärdatei schreibt eine Datei namens xtrabackup_checkpoints in das Zielverzeichnis des Backups. Diese Datei enthält eine Zeile, die die to_lsn anzeigt, die die LSN der Datenbank am Ende der Sicherung ist.

Zunächst müssen Sie mit dem folgenden Befehl eine vollständige Sicherung erstellen:

$ xtrabackup --backup --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

Da Sie nun eine vollständige Sicherung haben, können Sie darauf basierend eine inkrementelle Sicherung erstellen. Verwenden Sie einen Befehl wie den folgenden:

$ xtrabackup --backup --target-dir=/data/backups/inc1 \

--incremental-basedir=/data/backups/base \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Das /data/backups/inc1/-Verzeichnis sollte jetzt Delta-Dateien wie ibdata1.delta und test/table1.ibd.delta enthalten.

Die Bedeutung sollte selbstverständlich sein. Es ist jetzt möglich, dieses Verzeichnis als Basis für ein weiteres inkrementelles Backup zu verwenden:

$ xtrabackup --backup --target-dir=/data/backups/inc2 \

--incremental-basedir=/data/backups/inc1 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Inkrementelle Backups vorbereiten

Bisher ähnelt der Prozess der Sicherung der Datenbank einer normalen Sicherung, mit Ausnahme des Flags, bei dem wir den Speicherort der Schlüsselbunddatei angegeben haben.

Leider ist der Schritt --prepare für inkrementelle Backups nicht derselbe wie für normale Backups.

Bei normalen Sicherungen werden zwei Arten von Vorgängen durchgeführt, um die Datenbank konsistent zu machen:Festgeschriebene Transaktionen werden aus der Protokolldatei gegen die Datendateien wiedergegeben, und nicht festgeschriebene Transaktionen werden rückgängig gemacht. Sie müssen das Rollback nicht festgeschriebener Transaktionen beim Vorbereiten einer Sicherung überspringen, da Transaktionen, die zum Zeitpunkt Ihrer Sicherung noch nicht festgeschrieben waren, möglicherweise ausgeführt werden und wahrscheinlich in der nächsten inkrementellen Sicherung festgeschrieben werden. Sie sollten die Option --apply-log-only verwenden, um die Rollback-Phase zu verhindern.

Wenn Sie nicht die Option --apply-log-only verwenden, um die Rollback-Phase zu verhindern, sind Ihre inkrementellen Backups nutzlos. Nachdem Transaktionen zurückgesetzt wurden, können keine weiteren inkrementellen Sicherungen angewendet werden.

Beginnend mit der von Ihnen erstellten vollständigen Sicherung können Sie diese vorbereiten und dann die inkrementellen Unterschiede darauf anwenden. Denken Sie daran, dass Sie die folgenden Backups haben:

/data/backups/base

/data/backups/inc1

/data/backups/inc2

Um das Basis-Backup vorzubereiten, müssen Sie --prepare wie gewohnt ausführen, aber die Rollback-Phase verhindern:

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

Um die erste inkrementelle Sicherung auf die vollständige Sicherung anzuwenden, sollten Sie den folgenden Befehl verwenden:

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base \

--incremental-dir=/data/backups/inc1 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Wenn der Schlüsselbund zwischen der Basis- und der inkrementellen Sicherung gewechselt wurde, müssen Sie den Schlüsselbund verwenden, der verwendet wurde, als die erste inkrementelle Sicherung erstellt wurde.

Das Vorbereiten der zweiten inkrementellen Sicherung ist ein ähnlicher Vorgang

$ xtrabackup --prepare --target-dir=/data/backups/base \

--incremental-dir=/data/backups/inc2 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Hinweis; --apply-log-only sollte verwendet werden, wenn alle Inkremente außer dem letzten zusammengeführt werden. Aus diesem Grund enthält die vorherige Zeile nicht die Option --apply-log-only. Selbst wenn im letzten Schritt --apply-log-only verwendet wurde, wäre die Sicherung immer noch konsistent, aber in diesem Fall würde der Server die Rollback-Phase durchführen.
Der letzte Schritt ist die Wiederherstellung mit --copy-back Möglichkeit. Falls der Schlüsselbund rotiert wurde, müssen Sie den Schlüsselbund wiederherstellen, der zum Erstellen und Vorbereiten der Sicherung verwendet wurde.

Während die beschriebene Wiederherstellungsmethode funktioniert, erfordert sie einen Zugriff auf denselben Schlüsselbund, den der Server verwendet. Es ist möglicherweise nicht möglich, wenn die Sicherung auf einem anderen Server oder zu einem viel späteren Zeitpunkt erstellt wird, wenn Schlüssel im Schlüsselbund gelöscht werden oder im Falle einer Fehlfunktion, wenn der Schlüsselbund-Vault-Server überhaupt nicht verfügbar ist.

Die Option --transition-key= sollte verwendet werden, damit xtrabackup die Sicherung ohne Zugriff auf den Schlüsselbund-Vault-Server verarbeiten kann. In diesem Fall leitet xtrabackup den AES-Verschlüsselungsschlüssel von der angegebenen Passphrase ab und verwendet ihn, um die Tabellenbereichsschlüssel der zu sichernden Tabellenbereiche zu verschlüsseln.

Erstellen eines Backups mit einer Passphrase

Das folgende Beispiel zeigt, wie das Backup in diesem Fall erstellt werden kann:

$ xtrabackup --backup --user=root -p --target-dir=/data/backup \

--transition-key=MySecetKey

Wiederherstellen der Sicherung mit einem generierten Schlüssel

Beim Wiederherstellen einer Sicherung müssen Sie einen neuen Hauptschlüssel generieren. Hier ist das Beispiel für keyring_file:

$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \

--transition-key=MySecetKey --generate-new-master-key \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Im Fall von keyring_vault sieht es so aus:

$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \

--transition-key=MySecetKey --generate-new-master-key \

--keyring-vault-config=/etc/vault.cnf