Das Hauptmerkmal von MongoDB ist, dass bei der Installation einer Instanz, die ausgeführt wird, ohne dass eine Authentifizierungsmaßnahme erstellt wurde, der Beginn der Entwicklung erleichtert werden soll. Es kommt jedoch ein Punkt, an dem wir unsere Infrastruktur sicherstellen müssen.

Ein weiterer wichtiger Punkt, der mit dem Thema Sicherheit und Sicherung unserer Daten zu tun hat, ist, wenn wir eine Sicherung eines bestimmten Zeitpunkts durchführen müssen, aber keine Datenverschiebung wünschen, da wir auf diese Weise die Integrität unserer Datenbank und unserer Daten gewährleisten Sammlungen von Dokumenten. In dieser Hinsicht gibt es in MongoDB auch ein Tool, mit dem wir es vorübergehend blockieren können, um sicherzustellen, dass das, was wir kopieren, angemessen ist.

Sicherheit und Authentifizierung

Das Festlegen von Benutzerauthentifizierungsparametern ist für den MongoDB- Betrieb in der Produktion nicht unbedingt erforderlich, da wir den Dienst so installieren können, dass die Geräte, auf denen er ausgeführt wird, über einen Verbindungsfilter verfügen Netzwerk hat keinen Zugriff.

Dieser vereinfachte Ansatz für die Sicherheit ist sehr effektiv, aber nur für Projekte, bei denen der Dienst nicht mit anderen Teams geteilt wird. Wenn wir verschiedene Entwicklungsteams haben, die gegen denselben Server arbeiten, brauchen wir etwas mehr. Hier kommt die Authentifizierung ins Spiel, bei der wir uns auf Wunsch um die Abfrage eines Benutzers und eines Passworts pro Sammlung kümmern, damit wir die Möglichkeit haben, die verschiedenen Instanzen für jedes Team in geeigneter Weise zu trennen.

Beide Sicherheitsmaßnahmen sind nicht exklusiv und wenn wir sie gleichzeitig anwenden möchten, schaffen wir einen viel sichereren Service für unsere Umgebung, entweder in der Produktion, in der Vorproduktion oder in der Entwicklung mehrerer Teams.

Standardauthentifizierung

Die Authentifizierung in ihrer einfachsten Form erfolgt mit dem Befehl createUser , der ausgeführt werden muss, wenn wir die Admin- Datenbank ausgewählt haben , in der sich unsere Benutzer befinden sollten.

Es ist wichtig zu beachten, dass seit Version 2.6 von MongoDB die Methode createUser verwendet wurde. In der Vergangenheit wurde alles durch die Methode addUser gelöst. Die Änderung wurde jedoch vorgenommen, um eine größere Vielseitigkeit beim Vornehmen der Änderungen zu ermöglichen.

Mal sehen, wie wir einen Administratorbenutzer und dann einen Benutzer einrichten können, der nur die Testdatenbank lesen kann.

Die Struktur des Dokuments, das die createUser- Methode empfängt, lautet wie folgt:

 {"Benutzer": "Benutzername", "Kennwort", "Rollen": [{"Rolle": "," Datenbank ":"},]} 

Wie wir bemerkt haben, müssen wir den Namen und das Kennwort für den Benutzer festlegen, den wir erstellen, aber zusätzlich müssen wir auch die Rollen erstellen. Dies ist eine Berechtigungsstruktur, mit der wir die Befugnisse definieren können, die wir dem Benutzer erteilen.

Im folgenden Beispiel erstellen wir einen Administrator, der Zugriff auf alle Datenbanken hat und den Dienst steuern kann. Dazu werden wir die Rollen verwenden :

• clusterAdmin
• readAnyDatabase
• readWrite

Mit diesen drei Parametern können wir bereits unseren ersten Benutzer verwalten. Mal sehen, wie das in der Konsole aussieht:

Damit haben wir unseren Administratorbenutzer bereits erfolgreich angelegt. Jetzt müssen wir uns den Benutzer und das Kennwort in geeigneter Weise merken, da der nächste Schritt darin besteht, die Sicherheit zu aktivieren. Dazu müssen wir den Dienst mit dem Parameter -auth starten .

Durch einen Neustart des Dienstes können wir dann unseren neu erstellten Administratorbenutzer platzieren und als Beweis dafür einen Benutzer erstellen, der nur die Datenbank lesen kann. In den folgenden Schritten erfahren Sie, wie Sie den Dienst neu starten.

Wir müssen es einfach zuerst stoppen, zum Beispiel positionieren wir uns in Windows auf der Konsole, in der es ausgeführt wird, und drücken die Tastenkombination STRG + C. Dann starten wir unseren Dienst normal, übergeben aber am Ende den auth- Parameter, wie in der folgenden Konsole zu sehen ist:

Sobald dies erledigt ist, kehren wir zur MongoDB- Steuerkonsole zurück. In diesem Fall verwenden wir jedoch unseren neu erstellten Benutzer:

 mongo.exe --username = root --password = 123456 admin 

Mit dieser vorherigen Zeile können wir sicher auf unseren Service zugreifen, wir können dies auf dem folgenden Bild sehen:

Es ist wichtig zu bedenken, dass wir in diesem Beispiel ein sichereres Kennwort als “123456” verwenden müssen, um es nur als Beispiel zu verwenden. Dies ist jedoch für eine Produktionsumgebung nicht geeignet.

Da wir überprüft haben, wie mit Authentifizierung zugegriffen werden kann, erstellen wir einen Benutzer, der nur die Testdatenbank lesen kann. Dazu wiederholen wir die Erstellung eines Benutzers, geben jedoch die Rolle an:

 lesen 

Auf diese Weise wird verhindert, dass Benutzer in die Sammlungen schreiben können. Sehen wir uns die Antwort in unserer Konsole an:

Wenn wir nun versuchen, ein Dokument zu schreiben, erhalten wir eine Fehlermeldung:

Wir haben dann gesehen, wie wir unseren Benutzern bereits in angemessener Weise versichert haben, es ist klar, dass diese Arbeit der Benutzerverwaltung ein bisschen komplex ist, aber wenn wir es einmal getan haben, können wir mit großer Sicherheit davon ausgehen, dass wir keinen unbefugten Zugriff auf die Datenbanken haben werden Was schützen wir?

Backup mit Datenblockierung

Eine der komplexesten Aktivitäten bei der Sicherung ist, dass die Integrität der Daten sichergestellt werden muss. Dies führt zu einem Dilemma: Ermitteln Sie die Zeit, in der weniger Benutzer arbeiten, und führen Sie die Sicherung durch, oder tun Sie dies unabhängig von den Daten.

Mit diesen beiden Parametern können wir unsere Datenbank veranlassen, die Schriften abzulehnen, und in diesem Moment können wir die Sicherungen ordnungsgemäß durchführen.

Um diesen Block zu erstellen, müssen wir den folgenden Befehl in unserer Datenbank ausführen:

 db.runCommand ({"fsync": "1", "lock": "1"}); 

Damit wird unsere Datenbank effektiv gegen das Schreiben gesperrt:

Wie wir sehen, ist es recht einfach und effektiv. Wenn wir nun den Block aufbrechen möchten, reicht es aus, den Befehl erneut auszuführen:

 db.fsyncUnlock (); 

Mit diesem letzten haben wir unsere Datenbank mit der Fähigkeit, Schreiben zu erhalten:

Backups vom Slave-Rechner

Obgleich dies eine größere Flexibilität darstellt und uns viel mehr Sicherheit gegen Datenkorruption und Integrität bietet, ist dies keine Praxis, die wir in realen Produktionsumgebungen durchführen müssen.

Ideal ist es, eine Umgebung mit Replikation zu erstellen, in der wir auf eine Kopie der Daten zugreifen und so mit allen Optionen manipulieren können, über die wir die erforderlichen Sicherungen verfügen. Da wir uns in einer Replik der Produktionsdatenbank befinden, können wir diese blockieren oder deaktivieren und die Sicherung so durchführen, dass der Benutzer niemals auf einen Fehler in der Anwendung stößt, da er keinen Datensatz schreiben kann.

Bei Backups wird es komplizierter, da es ratsam ist, Server-Replikate zu verwenden. Aufgrund des Konzepts von MongoDB sind diese Master-Slave-Strukturen jedoch sehr einfach zu implementieren Das Konzept ist das schwierigste, aber seine Anwendung ist für den DBA äußerst freundlich.

Damit beenden wir dieses Tutorial, da wir sehen, dass die Verwaltung von MongoDB ziemlich weit fortgeschritten ist. Wenn wir eine mittelgroße Struktur haben, ist es möglich, dass wir bereits über das Thema Benutzersicherheit nachgedacht haben, obwohl die Erstellung der Benutzer nicht komplex ist. wenn es gut ist, sich hinzusetzen und eine gute Struktur zu definieren, um diese Art von Genehmigungen zu erstellen.