Datensicherheit ist in Zeiten von DSGVO, PCI DSS oder HIPPA entscheidend. Um die Vorschriften einzuhalten, muss man äußerst vorsichtig sein, wie die Daten gespeichert und geschützt werden sollten. Daten können typischerweise ruhen oder übertragen werden. Daten während der Übertragung sind die Daten, die von oder zu der Datenbank übertragen werden. An den Client oder die Anwendung gesendete Abfrageergebnisse oder replizierte Daten zwischen Knoten des Clusters sind Beispiele für Fälle, in denen Daten übertragen werden. Wir neigen dazu, Daten in diesem Zustand mit SSL- oder TLS-verschlüsselten Verbindungen zwischen den Datenbankknoten oder der Datenbank und dem Client zu sichern.
Auf der anderen Seite des Spektrums haben wir Daten im Ruhezustand - wir würden sagen, dass die meisten Daten zu einem bestimmten Zeitpunkt im Ruhezustand sind. Wir sprechen hier über Daten, die auf der Festplatte in Tablespaces gespeichert sind, verschiedene Datenstrukturen (gcache-Puffer, Redo-Protokolle) und Protokolle (Binär- und Relaisprotokolle). Werfen wir einen Blick auf die Überlegungen zu diesem Thema in MariaDB.
Was soll in MariaDB verschlüsselt werden?
Idealerweise müssen Sie alles verschlüsseln. Wie oben erwähnt, speichern Datenbanken Daten an verschiedenen Orten und auf unterschiedliche Weise. Der größte Datensatz wird in Tablespaces gespeichert – dies ist der „endgültige“ Ort, an dem die Daten gespeichert werden. Offensichtlich ist es möglich, Tablespaces zu verschlüsseln – sonst wäre das ganze Feature sinnlos. MariaDB kann die Daten in einem gemeinsam genutzten Tablespace speichern, mehrere davon oder jede Tabelle kann in einem separaten Tablespace gespeichert werden - all diese Szenarien werden unterstützt. Benutzer haben ein gewisses Maß an Flexibilität bei der Auswahl, was verschlüsselt werden soll. Sie können alles verschlüsseln, einzelne Tabellen oder alles außer einigen einzelnen Tabellen.
MariaDB InnoDB Redo-Protokoll
Eine weitere Struktur, die die Daten speichert, ist das InnoDB Redo Log. Das InnoDB Redo Log ist ein Ort, an dem Daten geschrieben werden, nachdem eine bestimmte Zeile aktualisiert wurde. Daten aus dem Redo-Log werden schließlich in den Tablespace übertragen, aber für eine gewisse Zeit enthält das InnoDB-Redo-Log alle Änderungen, die kürzlich stattgefunden haben. Wie Sie sich vorstellen können, sind diese Daten ebenfalls kritisch und sollten geschützt werden – MariaDB ermöglicht Ihnen, das InnoDB-Redo-Log zu verschlüsseln.
MariaDB-Binärprotokolle
Binäre Logs (wie auch Relay-Logs) speichern Informationen über ausgeführte Abfragen, die die Daten verändern. Da die enthaltenen Informationen es uns ermöglichen, den aktuellen Zustand einer geänderten Zeile zu rekonstruieren, handelt es sich um eine weitere Form von Daten, die geschützt und verschlüsselt werden sollten. Sowohl Binär- als auch Relay-Logs können in MariaDB verschlüsselt werden.
Galera-Cache
Galera-Cache (gcache) ist ein On-Disk-Puffer im Galera-Cluster, der die Informationen über ausgeführte Änderungen speichert. Es wird im Falle eines Knotenausfalls oder vorübergehender Netzwerkprobleme verwendet, damit Knoten, die dem Cluster beitreten, nur die fehlenden Daten verwenden können, um zu vermeiden, dass der gesamte Datensatz übertragen wird. Ähnlich wie Binärprotokolle oder Redo-Protokolle enthält gcache die Liste der Änderungen und kann daher zum Wiederherstellen und Zusammenstellen von Daten verwendet werden. In der Community-Version von MariaDB Galera Cluster kann gcache nicht verschlüsselt werden. Diese Option wird in der Enterprise-Version von MariaDB Galera Cluster verfügbar.
Was kann in MariaDB nicht verschlüsselt werden?
Es gibt immer noch einige Stellen, an denen Datenstücke auftauchen können, die zumindest derzeit in MariaDB nicht verschlüsselt werden können. Erstens können Fehlerprotokolle Beispiele von Abfragen enthalten, die potenziell einige Daten preisgeben können. Es ist unmöglich, Fehlerprotokolle zu verschlüsseln, aber es ist möglich, das Fehlerprotokoll zum Syslog umzuleiten und einen Schutzmechanismus außerhalb von MariaDB zu implementieren.
Protokolle vom Audit-Plugin
Audit-Plug-in generiert auch ein Protokoll - dieses Protokoll kann vertrauliche Informationen enthalten, einschließlich der genauen Abfragen, die in der Datenbank ausgeführt wurden. Es ist nicht möglich, dieses Protokoll zu verschlüsseln, aber es kann zum Syslog umgeleitet und dort verschlüsselt werden.
Abfrageprotokolle
Allgemeine und langsame Abfrageprotokolle - diese Protokolle enthalten Abfragen (oder zumindest Beispiele davon), die von MariaDB ausgeführt wurden. Derzeit ist es nicht möglich, diese Protokolle zu verschlüsseln.
InnoDB-Pufferpool
Speicher - MariaDB führt die Verschlüsselung nur für die Seiten durch, die auf der Festplatte gespeichert sind. Alle Daten, die im InnoDB-Pufferpool gespeichert sind, werden unverschlüsselt. Der InnoDB-Pufferpool soll die Zeilen speichern, die kürzlich geändert wurden oder auf die durch die SELECT-Abfrage zugegriffen wurde. Diese Zeilen enthalten offensichtlich Datenbeispiele. Derzeit gibt es keine Möglichkeit, den InnoDB-Pufferpool in MariaDB zu verschlüsseln. Bitte bedenken Sie, dass man Zugriff auf das System benötigt, um den Live-Speicher zu lesen. Es ist keine triviale Aufgabe, obwohl sie auch nicht unmöglich zu erfüllen ist.
Bitte denken Sie daran, dass wir die in MariaDB enthaltenen Verschlüsselungsoptionen behandelt haben. Es besteht immer die Möglichkeit, eine andere Verschlüsselungsebene zu verwenden. Wenn Sie beispielsweise den gesamten Speicher verschlüsseln, werden Protokolle für niemanden lesbar, der physischen Zugriff auf die Festplatte hätte. Andererseits werden die Daten nicht vor jemandem geschützt, der sich beim System anmelden kann.
Kompatibilität mit externen Tools
Eine weitere zu berücksichtigende Sache ist die Kompatibilität. Wenn Sie sich entscheiden, Ihre MariaDB zu verschlüsseln, müssen Sie bedenken, dass dies Ihre Arbeitsweise beeinträchtigen kann. Es ist nicht möglich, externe Tools wie XtraBackup oder mysqlbinlog zu verwenden, um die Daten zu verarbeiten und ein Backup zu erstellen oder mit Binärlogs umzugehen. Sie müssen sich an die von MariaDB erstellten Tools (wie Mariabackup) halten, die unter Berücksichtigung des Verschlüsselungsmechanismus geschrieben wurden. Sie können mit den ruhenden Daten umgehen. Die Verschlüsselung ist in MariaDB implementiert.
Planung des Verschlüsselungsprozesses
In diesem Abschnitt wird der Prozess nicht im Detail besprochen, aber es geht darum, was Sie bei der Planung der Verschlüsselung berücksichtigen sollten, wie Ressourcen und Zeit. Die CPU-Auslastung steigt ebenso wie die E/A-Aktivität für die Dauer des Prozesses. Aus Benutzersicht läuft alles auf die Konfigurationseinstellungen hinaus und dann auf die Ausführung von ALTER-Befehlen, um vorhandene Tabellen neu zu erstellen und zu verschlüsseln. Bei großen Datenbanken kann dies allein eine erhebliche Herausforderung darstellen, die eine Planung erfordert. Schemaänderungen können eine ernsthafte Belastung darstellen, und es wird empfohlen, Tools wie pt-online-schema-change zu verwenden, um deren Auswirkungen auf die Produktionssysteme zu verringern und eine bessere Kontrolle über den Prozess zu erlangen.
Abschließende Gedanken
Wie bereits erwähnt, sind Daten für alle Organisationen von entscheidender Bedeutung, und es ist von entscheidender Bedeutung, dass die Daten sicher und geschützt sind. Die Verschlüsselung der gespeicherten Daten ist eines der wichtigen Elemente im Gesamtbild. Wir würden uns freuen, von Ihnen über Ihre Erfahrungen mit der Verschlüsselung von ruhenden Daten in MariaDB zu hören. Wenn Sie Ihre Gedanken teilen möchten, können Sie gerne unten einen Kommentar hinterlassen.
