So verwenden Sie Verschlüsselung zum Schutz Ihrer MongoDB-Daten

Datenbanksicherheit ist ein Schlüsselfaktor, der für jede Anwendung zu berücksichtigen ist, die hochsensible Daten wie Finanz- und Gesundheitsberichte enthält. Datenschutz kann durch Verschlüsselung auf verschiedenen Ebenen erreicht werden, angefangen bei der Anwendung selbst bis hin zu den Dateien, die die Daten enthalten.

Da MongoDB eine nicht relationale Datenbank ist, müssen vor dem Einfügen von Daten keine Spalten definiert werden; und daher können Dokumente in derselben Sammlung unterschiedliche Felder haben.

Andererseits muss man für SQL-DBMS Spalten für die Daten definieren, daher haben alle Zeilen die gleichen Spalten. Man kann entscheiden, einzelne Spalten, ganze Datenbankdateien oder Daten aus der Anwendung zu verschlüsseln, bevor man in den Datenbankprozess eingebunden wird.

Die Verschlüsselung einzelner Spalten wird am meisten bevorzugt, da sie billiger ist und weniger Daten verschlüsselt werden, wodurch die Latenz verbessert wird. Im Allgemeinen wirkt sich die Verschlüsselung auf die Gesamtleistung aus.

Für NoSQL-DBMS wird dieser Ansatz jedoch nicht der beste sein. Da möglicherweise nicht alle Dokumente alle Felder enthalten, die Sie in Ihrer Verschlüsselung verwenden möchten, kann keine Verschlüsselung auf Spaltenebene durchgeführt werden.

Das Verschlüsseln von Daten auf Anwendungsebene ist ziemlich kostspielig und schwierig zu implementieren. Uns bleibt daher die Möglichkeit, Daten auf Datenbankebene zu verschlüsseln.

MongoDB bietet eine native Verschlüsselung, die keine zusätzlichen Kosten für die Sicherung Ihrer sensiblen Daten erfordert.

Daten in MongoDB verschlüsseln

Jede Datenbankoperation beinhaltet eine dieser beiden Datenformen, Data at Rest oder Data in Motion.

Daten in Bewegung sind ein Datenstrom, der sich durch jede Art von Netzwerk bewegt, während Daten im Ruhezustand statisch sind und sich daher nirgendwohin bewegen.

Diese beiden Datentypen sind anfällig für externe Störungen durch anonyme Benutzer, es sei denn, es handelt sich um eine Verschlüsselung. Der Verschlüsselungsprozess beinhaltet:

• Generieren eines Hauptschlüssels für die gesamte Datenbank
• Eindeutige Schlüssel für jede Datenbank generieren
• Verschlüsseln Ihrer Daten mit den von Ihnen generierten Datenbankschlüsseln
• Verschlüsseln der gesamten Datenbank mit dem Hauptschlüssel

Daten während der Übertragung verschlüsseln

Daten werden zwischen MongoDB und der Serveranwendung auf zwei Arten übertragen, nämlich über Transport Layer Security (TLS) und Secure Socket Layer (SSL).

Diese beiden sind die am häufigsten verwendeten Verschlüsselungsprotokolle zum Sichern gesendeter und empfangener Daten zwischen zwei Systemen. Grundsätzlich besteht das Konzept darin, Verbindungen zu den Mongod- und Mongos-Instanzen so zu verschlüsseln, dass der Netzwerkverkehr nur vom beabsichtigten Client gelesen werden kann.

TLS/SSL werden in MongoDB mit einigen Zertifikaten als PEM-Dateien verwendet, die von der Zertifizierungsstelle ausgestellt werden oder ein selbstsigniertes Zertifikat sein können. Letzteres hat eine Einschränkung, da der Kommunikationskanal zwar verschlüsselt ist, es jedoch immer keine Überprüfung der Serveridentität gibt und daher auf halbem Weg anfällig für externe Angriffe ist. Es ist daher ratsam, Zertifikate vertrauenswürdiger Stellen zu verwenden, die es MongoDB-Treibern ermöglichen, auch die Serveridentität zu überprüfen.

Neben der Verschlüsselung kann TLS/SSL bei der Authentifizierung des Clients und internen Authentifizierungen von Mitgliedern von Replikatgruppen und Sharding-Clustern über die Zertifikate verwendet werden.

TLS/SSL-Konfiguration für Clients

Es gibt verschiedene TLS/SSL-Optionseinstellungen, die bei der Konfiguration dieser Protokolle verwendet werden können.

Wenn Sie beispielsweise eine verschlüsselte Verbindung zu einer Mongod-Instanz herstellen möchten, starten Sie Ihre Instanz wie folgt:

mongo --ssl --host example.com --sslCAFile /etc/ssl/ca.pem

--ssl aktiviert die TLS/SSL-Verbindung.

--sslCAFile gibt die PEM-Datei der Zertifizierungsstelle (CA) zur Überprüfung des Zertifikats an, das von Mongod oder Mongos vorgelegt wird. Die Mongo-Shell überprüft daher das von der Mongod-Instanz ausgestellte Zertifikat anhand der angegebenen CA-Datei und des Hostnamens.

Möglicherweise möchten Sie auch eine MongoDB-Instanz verbinden, die ein Client-Zertifikat erfordert. Wir verwenden das folgende Codebeispiel

mongo --ssl --host hostname.example.com --sslPEMKeyFile /etc/ssl/client.pem --sslCAFile /etc/ssl/ca.pem

Die Option --sslPEMKeyFile gibt die .pem-Datei an, die das Mongo-Shell-Zertifikat und einen Schlüssel enthält, der der Mongod- oder Mongos-Instanz präsentiert werden soll. Während des Verbindungsvorgangs:

Die Mongo-Shell überprüft, ob das Zertifikat von der angegebenen Zertifizierungsstelle (--sslCAFile) stammt, und wenn nicht, kann die Shell keine Verbindung herstellen.

Zweitens überprüft die Shell auch, ob der in der Option --host angegebene Hostname mit dem SAN/CN im Zertifikat übereinstimmt, das von Mongod oder Mongos vorgelegt wird. Wenn dieser Hostname mit keinem der beiden übereinstimmt, schlägt die Verbindung fehl.

Wenn Sie keine selbstsignierten Zertifikate verwenden möchten, müssen Sie sicherstellen, dass das Verbindungsnetzwerk vertrauenswürdig ist.

Außerdem müssen Sie die Offenlegung privater Schlüssel reduzieren, insbesondere wenn es sich um Replikatsätze/Shard-Cluster handelt. Dies kann durch die Verwendung verschiedener Zertifikate auf verschiedenen Servern erreicht werden.

Zusätzliche Optionen, die in den Verbindungen verwendet werden können, sind:

requireSSL:Dadurch wird jeder Server darauf beschränkt, nur TLS/SSL-verschlüsselte Verbindungen zu verwenden.

--sslAllowConnectionsWithoutCertificates:Dies ermöglicht die Validierung, wenn nur der Client ein Zertifikat präsentiert, andernfalls wird der Client, wenn kein Zertifikat vorhanden ist, immer noch in einem verschlüsselten Modus verbunden. Zum Beispiel:

mongod --sslMode requireSSL --sslAllowConnectionsWithoutCertificates --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

sslDisabledProtocols:Diese Option verhindert, dass Server eingehende Verbindungen akzeptieren, die bestimmte Protokolle verwenden. Das geht mit:

mongod --sslMode requireSSL --sslDisabledProtocols TLS1_0,TLS1_1 --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

Daten im Ruhezustand verschlüsseln

Ab Version 3.2 führte MongoDB eine native Verschlüsselungsoption für die WiredTiger-Speicher-Engine ein. Der Zugriff auf Daten in diesem Speicher durch Dritte kann nur durch einen Entschlüsselungsschlüssel zum Entschlüsseln der Daten in ein lesbares Format erreicht werden.

Der häufig verwendete Verschlüsselungsalgorithmus in MongoDB ist AES256-GCM. Es verwendet denselben geheimen Schlüssel zum Verschlüsseln und Entschlüsseln von Daten. Die Verschlüsselung kann im FIPS-Modus aktiviert werden, wodurch sichergestellt wird, dass die Verschlüsselung den höchsten Standards und der höchsten Konformität entspricht.

Die gesamten Datenbankdateien werden mit der transparenten Datenverschlüsselung (TDE) auf Speicherebene verschlüsselt.

Immer wenn eine Datei verschlüsselt wird, wird ein eindeutiger privater Verschlüsselungsschlüssel generiert und es ist gut zu verstehen, wie diese Schlüssel verwaltet und gespeichert werden. Alle generierten Datenbankschlüssel werden anschließend mit einem Hauptschlüssel verschlüsselt.

Der Unterschied zwischen den Datenbankschlüsseln und dem Hauptschlüssel besteht darin, dass die Datenbankschlüssel zusammen mit den verschlüsselten Daten selbst gespeichert werden können, aber für den Hauptschlüssel empfiehlt MongoDB, ihn auf einem anderen Server als die verschlüsselten Daten wie den Unternehmensschlüssel eines Drittanbieters zu speichern Verwaltungslösungen.

Bei replizierten Daten werden die Verschlüsselungskriterien nicht an die anderen Knoten weitergegeben, da die Daten nicht nativ über die Leitung verschlüsselt werden. Man kann denselben Schlüssel für die Knoten wiederverwenden, aber am besten ist es, eindeutige individuelle Schlüssel für jeden Knoten zu verwenden.

Rotierende Verschlüsselungsschlüssel

Verwaltete Schlüssel, die zum Entschlüsseln vertraulicher Daten verwendet werden, sollten mindestens einmal im Jahr rotiert oder ersetzt werden. Es gibt zwei Optionen in MongoDB, um die Rotation zu erreichen.

KMIP-Master-Rotation

In diesem Fall wird nur der Hauptschlüssel geändert, da er extern verwaltet wird. Der Vorgang zum Drehen des Schlüssels ist wie unten beschrieben.

1. Der Hauptschlüssel für die sekundären Mitglieder im Replikatsatz wird einzeln rotiert. Dh

   mongod --enableEncryption --kmipRotateMasterKey \ --kmipServerName <KMIP Server HostName> \--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

   Nachdem der Vorgang abgeschlossen ist, wird mongod beendet und Sie müssen den sekundären Server ohne den kmipRotateMasterKey-Parameter neu starten

   mongod --enableEncryption --kmipServerName <KMIP Server HostName> \
     --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

2. Die primäre Replikatgruppe wird heruntergestuft:
   Unter Verwendung der rs.stepDown()-Methode wird die primäre deaktiviert, wodurch eine Wahl einer neuen primären erzwungen wird.

3. Überprüfen Sie den Status der Knoten mit der Methode rs.status(), und wenn der Primärschlüssel anzeigt, dass er heruntergestuft wurde, drehen Sie seinen Hauptschlüssel. Starten Sie das heruntergefahrene Mitglied neu, einschließlich der kmipRotateMasterKey-Option.

   mongod --enableEncryption --kmipRotateMasterKey \
     --kmipServerName <KMIP Server HostName> \
     --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

Protokollierung

MongoDB arbeitet immer mit einer Protokolldatei, um bestimmte Status- oder bestimmte Informationen in unterschiedlichen Intervallen aufzuzeichnen.

Die Protokolldatei wird jedoch nicht als Teil der Speicher-Engine verschlüsselt. Dies birgt das Risiko, dass eine Mongod-Instanz, die mit Protokollierung ausgeführt wird, potenziell sensible Daten an die Protokolldateien ausgeben kann, nur als Teil der normalen Protokollierung.

Ab der MongoDB-Version 3.4 gibt es die Einstellung security.redactClientLogData, die verhindert, dass potenziell sensible Daten im MongoDB-Prozessprotokoll protokolliert werden. Diese Option kann jedoch die Protokolldiagnose erschweren.

Verschlüsselungsleistung in MongoDB

Die Verschlüsselung führt irgendwann zu einer erhöhten Latenz, wodurch die Leistung einer Datenbank beeinträchtigt wird. Dies ist normalerweise der Fall, wenn es sich um eine große Menge an Dokumenten handelt.

Das Verschlüsseln und Entschlüsseln erfordert mehr Ressourcen, daher ist es wichtig, diese Beziehung zu verstehen, um die Kapazitätsplanung entsprechend anzupassen.

In Bezug auf die MongoDB-Tests weist eine verschlüsselte Speicher-Engine bei höchster Last eine Latenz zwischen 10 % und 20 % auf. Dies ist häufig der Fall, wenn ein Benutzer eine große Datenmenge in die Datenbank schreibt, was zu einer verringerten Leistung führt. Bei Lesevorgängen ist der Leistungsabfall vernachlässigbar, etwa 5–10 %.

Für eine bessere Verschlüsselungspraxis in MongoDB wird die WiredTiger-Speicher-Engine aufgrund ihrer hohen Leistung, Sicherheit und Skalierbarkeit am meisten bevorzugt. Darüber hinaus optimiert es die Verschlüsselung von Datenbankdateien auf Seitenebene, was insofern von großem Vorteil ist, als wenn ein Benutzer Daten in die verschlüsselte Datenbank liest oder schreibt, die Durchsatzoperation nur auf die Seite angewendet wird, auf der die Daten gespeichert sind, und nicht auf die gesamte Datenbank.

Dadurch wird die Datenmenge reduziert, die für die Verarbeitung eines einzelnen Datenelements verschlüsselt und entschlüsselt werden muss.

Zusammenfassung

Die Datensicherheit für vertrauliche Informationen ist ein Muss und muss geschützt werden, ohne die Leistung des Datenbanksystems zu beeinträchtigen.

MongoDB bietet ein robustes natives Verschlüsselungsverfahren, das uns helfen kann, unsere Daten sowohl im Ruhezustand als auch in Bewegung zu sichern. Außerdem sollten die Verschlüsselungsverfahren den festgelegten Standards verschiedener Organisationen entsprechen.

Die fortschrittliche WiredTiger-Speicher-Engine bietet aufgrund ihrer damit verbundenen Vorzüge wie hohe Leistung, Skalierbarkeit und Sicherheit eine bessere Option. Beim Verschlüsseln von Daten in Replikatsätzen empfiehlt es sich, für jeden unterschiedliche Hauptschlüssel zu verwenden und sie mindestens einmal im Jahr zu ändern.

Aufgrund der Verfügbarkeit von Verschlüsselungsoptionen von Drittanbietern gibt es jedoch keine Garantie dafür, dass Ihre Bereitstellung in Bezug auf die Skalierbarkeit mit diesen übereinstimmt. Es ist daher sehr sinnvoll, eine Verschlüsselung auf Datenbankebene einzusetzen.