MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

MongoDB-Unsicherheitsstufen und wie man sie vermeidet

Die meisten Datenbankverwaltungssysteme verfügen über mehrere Techniken, um ihre Daten vor einem Außenstehenden oder einer nicht autorisierten Person oder Anwendung zu schützen. Die Techniken verhindern, dass Ihre Daten ohne Zustimmung des Benutzers gelesen oder kopiert werden.

MongoDB ist nicht anders, da es einige Unsicherheitsstufen aufweist. In diesem Blogbeitrag werden wir die Unsicherheitsstufen in MongoDB erörtern und erläutern, wie Sie diese vermeiden können, damit Sie Ihre MongoDB-Installation schützen können.

Zur Sicherheit Ihrer MongoDB sind die folgenden Sicherheitsmaßnahmen unbedingt zu beachten:
 

  1. Authentifizierung von Benutzerverbindungen.

  2. Autorisierung/ Rollenbasierte Zugriffskontrolle.

  3. Netzwerkverschlüsselung/ Transportverschlüsselung.

  4. Speicherverschlüsselung/Verschlüsselung im Ruhezustand.

  5. Prüfung.

In diesem Artikel werden wir uns die oben genannten Sicherheitsmaßnahmen im Detail ansehen, wobei der Schwerpunkt auf Authentifizierung und Autorisierung liegt.

Authentifizierung und Autorisierung

Authentifizierung und Autorisierung müssen gemeinsam aktiviert werden. Sie können jedoch unabhängig voneinander verwendet werden. Die Authentifizierung verhindert, dass eine unbekannte Person, die Netzwerkzugriff auf den Datenbankserver hat, die Datenbankdaten kopiert oder beschädigt. Für die Authentifizierung müssen alle Clients und Server gültige Anmeldeinformationen bereitstellen, bevor sie eine Verbindung zum System herstellen können. Die Autorisierung hingegen hindert eine Anwendung oder einen Benutzer daran, Daten anders als vorgesehen zu lesen, zu ändern oder zu löschen.

Um die rollenbasierte Zugriffskontrolle zu konfigurieren;

  1. Erstellen Sie zuerst einen Benutzeradministrator.

  2. Weitere Benutzer erstellen.

  3. Erstellen Sie dann einen eindeutigen MongoDB-Benutzer für jede Person/Anwendung, die auf das System zugreift.

  4. Indem Sie dem Prinzip der geringsten Rechte folgen, sollten Sie Rollen erstellen, die genau die Zugriffsrechte definieren, die von einem Satz benötigt werden der Benutzer.

  5. Weisen Sie den Benutzern dann nur die Rollen zu, die sie in ihrem Betrieb erfüllen müssen. Ein Benutzer kann eine Clientanwendung oder eine Person sein.

Sie sollten beachten, dass ein Benutzer Berechtigungen für verschiedene oder mehrere Datenbanken haben kann. Anstatt einen Benutzer in diesem Szenario mehrmals in verschiedenen Datenbanken zu erstellen, erstellen Sie einen einzelnen Benutzer mit Rollen, die entsprechende Datenbankberechtigungen gewähren.

Meistens werden diese beiden Sicherheitsmaßnahmen mit der gleichen Bedeutung verwechselt. In einigen Szenarien sind sie einander ähnlich, aber sie sind auch unterschiedlich.

Ähnlichkeiten zwischen Authentifizierung und Autorisierung

  • Beide sind gewissermaßen eine Einheit, denn wenn Sie die Authentifizierung aktivieren, wird die Autorisierung automatisch aktiviert. Die Autorisierung wird zusammen mit der Authentifizierung aktiviert, daher haben Verbindungen von unbekannten Benutzern keine Berechtigung, auf Datenbankdaten zuzugreifen. Die Autorisierung erfordert auch, dass der Benutzername von der Authentifizierung überprüft wird, um zu wissen, welche Berechtigungen für die Anforderungen einer Verbindung gelten. Daher kann es auch nicht unabhängig voneinander aktiviert werden.

  • Sie ähneln sich auch in der unglücklichen, veralteten Benennung von Konfigurationsoptionen. Die Konfigurationsdateioption für die Authentifizierung ist security.authorization anstelle von security authentication, wie es zu erwarten wäre. Wenn Sie den Befehl verwenden, wird die Authentifizierung jedoch zuerst aktiviert und die Autorisierung wird erst als Nachwirkung aktiviert. „-auth“ ist das Befehlszeilenargument zum Aktivieren der Authentifizierung, wodurch automatisch auch die Autorisierung erzwungen wird.

Unterschiede zwischen Authentifizierung und Autorisierung

  • Diese beiden sind unterschiedlich, weil sie zwei Teile der Software sind, die unterschiedliche Funktionen haben.

Authentifizierung ==Benutzeridentität durch Überprüfung der Anmeldeinformationen.

Autorisierung ==Zuweisung und Durchsetzung von Berechtigungen für DB-Objekte und DB-Befehle.

  • Während der Ersteinrichtung ist die Authentifizierung für Localhost-Verbindungen deaktiviert. Dies ist jedoch kurz, da Sie eine Gelegenheit erhalten, den ersten Benutzer zu erstellen, dann wird die Ausnahmeberechtigung (zur Authentifizierungs- und Autorisierungsregel zusammen) gelöscht.

So überprüfen Sie, ob Authentifizierung und Autorisierung aktiviert sind oder nicht

Die ersten Versionen von MongoDB hatten standardmäßig „- auth“ gesetzt und dies wird weithin als schlechter Schachzug angesehen. Selbst in Version 4.0 war es immer noch standardmäßig deaktiviert. Eine leere Konfiguration bedeutet immer noch, dass die Autorisierung deaktiviert ist, obwohl es Startwarnungen und verschiedene Gefährdungsreduzierungen gibt, z. B. dass localhost das einzige standardmäßig gebundene Netzwerkgerät in MongoDB v3.6 wird.

Sie verwenden keine Authentifizierung oder haben die Authentifizierung nicht aktiviert, wenn die Mongod-Konfigurationsdateien dies nicht tun:

  1. Legen Sie die security.authorization auf „aktiviert“ fest.

  2. Füge eine security.keyfile hinzu.

  3. Fügen Sie eine security.clusterAuthMode-Einstellung hinzu, die die Aktivierung der Authentifizierung erzwingt.

Um zu überprüfen, ob Authentifizierung und Autorisierung aktiviert sind oder nicht, können Sie diesen schnellen Mongo-Shell-Einzeiler ausprobieren (ohne festgelegte Argumente für Benutzeranmeldeinformationen):

mongo --host : --quiet --eval 'db.adminCommand({listDatabases:1})'

Die Antwort, die Sie erhalten sollten, ist ein „nicht autorisierter“ Fehler. Wenn Sie jedoch andererseits eine Liste mit Datenbanknamen erhalten, bedeutet dies automatisch, dass Sie eine nackte MongoDB-Bereitstellung haben.

Externe Authentifizierung

Wie der Name schon sagt, geht es bei der externen Authentifizierung darum, dass Benutzer in einem externen Dienst authentifiziert werden können. Als Ausnahme kann es nicht für den internen mongodb __-Systembenutzer verwendet werden, aber die Verwendung für jeden echten menschlichen Benutzer oder Client-Anwendungsdienstkonto ist perfekt geeignet.

Der externe Authentifizierungsdienst ist einfach ein Kerberos-KDC oder ein ActiveDirectory- oder OpenLDAP-Server. Beachten Sie, dass die Verwendung einer externen Authentifizierung Sie nicht daran hindert, gleichzeitig normale MongoDB-Benutzerkonten zu haben.

Interne Authentifizierung

Im Gegenteil, MongoDB-interne Authentifizierung bedeutet nicht das Gegenteil von externer Authentifizierung. Dies liegt daran, dass ein Mongod-Knoten, der mit aktivierter Authentifizierung ausgeführt wird, nicht darauf vertraut, dass ein TCP-Peer ein anderer Mongod- oder Mongos-Knoten ist, nur weil er wie einer kommuniziert. Vielmehr erfordert es, dass sich der Peer durch den Nachweis des gemeinsamen Geheimnisses authentifiziert.

Es gibt zwei Arten von internen Authentifizierungsmechanismen in MongoDB:

  1. Interne Schlüsseldatei-Authentifizierung.

  2. interne SCRAM- oder x.509-Authentifizierung.

Interne Schlüsseldatei-Authentifizierung

Dies ist der standardmäßige interne Authentifizierungsmechanismus in MongoDB. Der Begriff „Schlüssel“ bezeichnet einen asymmetrischen Verschlüsselungsschlüssel, aber im eigentlichen Sinne ist es nur ein Passwort, egal wie Sie es generiert haben. Die Schlüsseldatei wird in einer identischen Datei gespeichert, die an jeden Mongod- und Mongos-Knoten im Cluster verteilt wird. In dem Szenario, in dem das Passwort erfolgreich verwendet wird, lässt ein Mongod-Knoten zu, dass Befehle, die vom authentifizierten Peer kommen, als Superuser „_ _ system“ ausgeführt werden.

Wenn jemand eine Kopie der Schlüsseldatei hat, kann er einfach Kontroll- und nicht druckbare Zeichen aus der Schlüsseldatei entfernen, um die Passwortzeichenfolge zu erstellen, die es ihm ermöglicht, sich als Benutzer „_ _ system“ zu verbinden.

Wenn dies jedoch passiert und Sie den folgenden Befehl als Benutzer mongod (oder root) auf einem Ihrer MongoDB-Server ausführen und erfolgreich sind, sollten Sie sich keine Sorgen machen, da keine versehentlichen Leseberechtigungen verloren gehen . Dies liegt daran, dass der Mongod beim Start abbricht, wenn sich die Schlüsseldatei in einem anderen Dateiberechtigungsmodus als 400 (oder 600) befindet.

mongo --authenticationDatabase local -u __system -p "$(tr -d '\011-\015\040' < /path/to/keyfile)"

Das versehentliche Speichern der Schlüsseldatei in Ihrer allgemein lesbaren Quellcodeverwaltung kann es Benutzern, die keine DBAs sind (oder den Serveradministratoren mit Root), ermöglichen, eine Kopie der Schlüsseldatei zu lesen. Dies wird als Sicherheitsfehler angesehen.

Ein extremes Risiko steigt, wenn die Schlüsseldatei mit Mongos-Knoten verteilt wird, die einem der Unix-Benutzer des Anwendungsteams gehören und als dieser ausgeführt werden, anstatt als „mongod“ oder ein anderer Unix-Benutzer im Besitz des DBA-Teams.

SCRAM oder interne x.509-Authentifizierung

Der interne x.509-Authentifizierungsmechanismus verwendet tatsächlich asymmetrische private oder öffentliche Schlüssel und muss zusammen mit TLS/SSL verwendet werden. Dieser Mechanismus kann sowohl für Clientverbindungen als auch für die interne Authentifizierung verwendet werden.

Der x.509- oder SCRAM-Mechanismus hat einen Vorteil gegenüber dem Keyfile-Mechanismus, da es beim x.509-Mechanismus weniger wahrscheinlich ist, dass einer der Schlüssel, die mit Mongod- und Mongos-Knoten bereitgestellt werden, von einem missbraucht werden kann Eindringling, der eine Kopie davon erhält. Dies hängt jedoch davon ab, wie streng die x.509-Zertifikate eingerichtet sind. Um maximale Sicherheit durch diesen Mechanismus zu genießen, sollten Sie ein dediziertes Sicherheitsteam haben, das die x.509-Konzepte und Best Practices versteht. Zu diesen Best Practices gehören die Festlegung, auf welchen Hosts es funktioniert, und die Möglichkeit, Zertifikate zu widerrufen und zu verlängern.

Netzwerkverschlüsselung/ Transportverschlüsselung

Die Netzwerkverschlüsselung verhindert, dass jemand die Daten kopiert, die über eine Netzwerkverbindung irgendwo zwischen zwei Servern übertragen werden. Die Netzwerkverschlüsselung erfordert wenig oder gar keine Überlegungen, wenn es darum geht, ob sie verwendet werden soll, da sie von entscheidender Bedeutung ist. Aber wenn sich beispielsweise Ihr MongoDB-Cluster und alle seine Clients in einem virtuellen privaten Netzwerk befinden, von dem Sie glauben, dass es keine Löcher in seiner Firewall und kein Risiko einer Rechteausweitung durch andere Apps gibt, dann brauchen Sie keine Netzwerkverschlüsselung.

Für die Netzwerkverschlüsselung sollten Sie MongoDB so konfigurieren, dass TLS/SSL für alle ausgehenden und eingehenden Verbindungen verwendet wird. Verschlüsseln Sie die Kommunikation zwischen Mongod- und Mongos-Komponenten einer MOngoDB-Bereitstellung sowie zwischen allen Anwendungen und MongoDB mit TLS/SSL.

Ab Version 4.0; MongoDB deaktiviert die Unterstützung für TLS 1.0-Verschlüsselung auf Systemen, auf denen TLS 1.1+ verfügbar ist, und verwendet außerdem die folgenden nativen TLS/SSL-Bibliotheken:

  1. Windows – Sicherer Kanal (Schannel).

  2. Linux/BSD - OpenSSL.

  3. macOS – Sicherer Transport.

Netzwerkbelastung begrenzen

Sie sollten sicherstellen, dass MongoDB in einer vertrauenswürdigen Netzwerkumgebung ausgeführt wird, und außerdem Firewall- oder Sicherheitsgruppen konfigurieren, um den ein- und ausgehenden Datenverkehr für Ihre MongoDB-Instanzen zu steuern. Konfigurieren Sie außerdem so, dass nur vertrauenswürdige Clients auf die Netzwerkschnittstellen und Ports zugreifen können, auf denen MongoDB-Instanzen verfügbar sind. Verwenden Sie beispielsweise IP-Whitelists, um den Zugriff von vertrauenswürdigen IP-Adressen zuzulassen.

MongoDB mit sicheren Konfigurationsoptionen ausführen

MongoDB unterstützt die Ausführung von JavaScript-Code für die folgenden serverseitigen Operationen:

  1. mapReduce.

  2. $wo.

  3. $akkumulator.

  4. $function.

Verwenden Sie die Option --noscripting in der Befehlszeile, um das serverseitige Scripting zu deaktivieren, wenn Sie die oben genannten Operationen nicht verwenden. Lassen Sie die Eingabevalidierung aktiviert, obwohl MongoDB die Eingabevalidierung standardmäßig durch die net.wireObjectCheck-Einstellung aktiviert. Dadurch wird sichergestellt, dass alle von der Mongod-Instanz gespeicherten Dokumente gültige BSON sind.

MongoDB-Speicherverschlüsselung/Verschlüsselung im Ruhezustand

Speicherverschlüsselung verhindert, dass jemand eine Kopie der zugrunde liegenden Datenbankdateien erhält. Dies kann passieren, wenn jemand in Ihr Rechenzentrum einbricht und die Festplatte Ihres Servers stiehlt. MongoDB-Daten umfassen Datendateien, Konfigurationsdateien, Überwachungsprotokolle und Schlüsseldateien.

Ab MongoDB Enterprise 3.2 können Sie Daten in der Speicherschicht mit der nativen Verschlüsselung im Ruhezustand der WiredTiger-Speicher-Engine verschlüsseln. MongoDB-Daten sollten auf jedem Host mit Dateisystem-, Geräte- oder physischer Verschlüsselung verschlüsselt werden, wenn die Verschlüsselung im Ruhezustand von WiredTiger nicht verwendet wird. Außerdem sollten Sie Protokolle in einem zentralen Protokollspeicher sammeln, da diese Protokolle DB-Authentifizierungsversuche einschließlich der Quell-IP-Adresse enthalten. Die Speicherverschlüsselung hat jedoch geringfügige Leistungseinbußen.

Prüfung

Auditing hilft bei der Verfolgung eines Datenbankbenutzers, der weiß, wie er seine Spuren verwischen kann, nachdem er Datenbankdaten geändert oder verändert hat. Grundsätzlich verfolgt das Auditing Zugriffe und Änderungen an Datenbankkonfigurationen und Daten. MongoDB Enterprise verfügt über eine Prüfsystemeinrichtung, die Systemereignisse wie Benutzervorgänge und Verbindungsereignisse auf einer MongoDB-Instanz aufzeichnen kann.

Diese Audit-Aufzeichnungen helfen bei der forensischen Analyse und ermöglichen es Administratoren, die ordnungsgemäßen Kontrollen zu überprüfen. Auditing ist für einige Benutzer von hohem Wert, kann dies aber nur sein, wenn bestimmte andere Risiken eliminiert werden. Beispielsweise kann ein Angreifer keinen Unix-Root-Zugriff auf die Server erlangen, während er die Live-Mongod-Knoten ausführt.

Vorwärts bewegen

Sie können Filter einrichten, um bestimmte Ereignisse wie Authentifizierungsereignisse aufzuzeichnen. Aber seien Sie vorsichtig, denn wenn die Prüffilter zu weit gefasst sind, wird ihre Leistung schnell gedrosselt, was zu hohen Leistungskosten führt. Wenn die Prüfung jedoch angemessen eingesetzt wird, entstehen keine großen Leistungskosten.