Role-Based Access Control (RBAC) in MongoDB

Da in der digitalen Ära immer mehr Menschen online sind, wächst der Bedarf, Berechtigungen und Rollen klar zu definieren, um Sicherheit zu gewährleisten und den Zugriff auf Anwendungen und Systeme zu steuern. Role-Based Access Control ist ein Autorisierungsmodell, das den Zugriff auf Ressourcen anhand vordefinierter Rollen der Nutzer regelt. 

Im RBAC-Modell von MongoDB werden Aktionen in Form von Rollen abgebildet, die den passenden Nutzern zugewiesen werden. Anstatt also viele einzelne Berechtigungen zu vergeben, kannst du eine einzige Rolle (z. B. dbAdmin) zuweisen, die automatisch den definierten Satz an Berechtigungen umfasst (z. B. Lesezugriff auf Collections in der Datenbank). Dieses Modell macht das Zugriffsmanagement skalierbar und übersichtlich.

RBAC in MongoDB aktivieren

Im Kernmodell von RBAC ist der Zugriff standardmäßig verweigert. Das heißt: Ohne Rolle haben Nutzer keinen Zugang zu Ressourcen. Nutzern können mehrere Rollen zugewiesen werden, und jede Rolle bringt einen spezifischen Satz an Rechten bzw. Berechtigungen für bestimmte Funktionen mit.

RBAC: Zentrale Konzepte

Hier sind einige der wichtigsten Konzepte, die du zu RBAC kennen solltest:

Nutzer

Im RBAC-Modell ist ein Nutzer eine Entität, der eine oder mehrere Rollen zugewiesen werden, die ihren Zugriff auf Datenbankressourcen und -operationen bestimmen. Ohne Rollen hat ein Nutzer keinen Systemzugang. Um Zugriff zu erhalten, müssen sich Nutzer authentifizieren und mindestens eine Rolle zugewiesen bekommen.

Rollen

MongoDB stellt integrierte Rollen und Berechtigungen sowohl für selbstverwaltete Deployments als auch für MongoDB Atlas bereit. Zu den gängigen integrierten Rollen gehören read, readWrite und dbAdmin/atlasAdmin. Datenbank-Admin-Rollen verfügen über höhere Privilegien als andere Datenbanknutzerrollen, inklusive der Berechtigung, die Privilegien anderer Rollen zu verwalten.

Wenn die integrierten Rollen nicht den gewünschten Berechtigungssatz abdecken, bietet MongoDB Methoden zum Erstellen und Anpassen benutzerdefinierter Rollen.

Eine Rolle ist ein Satz von Privilegien, die einem Nutzer zugewiesen werden.

Beispiel: Eine „read“-Rolle könnte ausschließlich Lesezugriff gewähren, eine „admin“-Rolle Lese- und Schreibrechte, während die „owner“-Rolle Lese-, Schreib- und Löschrechte für ein bestimmtes Objekt (eine Datenbank, ein Dokument usw.) umfassen kann. Eine Rolle gewährt Privilegien, um die festgelegten Aktionen auf Ressourcen auszuführen. Jedes Privileg wird entweder explizit in der Rolle definiert oder von einer anderen Rolle geerbt – oder beides.

Benutzerdefinierte Rollen / Custom Roles

MongoDB bietet zahlreiche integrierte Rollen, mit denen Administratoren den Zugriff auf ein MongoDB-System steuern können. Wenn diese Rollen jedoch nicht die spezifischen Privilegien abbilden, die du brauchst, kannst du in einer Datenbank neue Rollen definieren und Nutzern zuweisen – das sind Custom Roles. Mit Ausnahme von Rollen, die in der admin-Datenbank erstellt werden, kann eine Rolle nur Privilegien für ihre eigene Datenbank enthalten und nur von anderen Rollen in derselben Datenbank erben.

Zum Erstellen einer neuen Rolle verwendest du die Methode db.createRole() und gibst die Privilegien im privileges-Array sowie die geerbten Rollen im roles-Array an.

MongoDB verwendet die Kombination aus Datenbankname und Rollenname, um eine Rolle eindeutig zu definieren, und speichert alle Rolleninformationen in der Collection admin.system.roles der admin-Datenbank.

Beispiel: Dieses Beispiel erstellt eine benutzerdefinierte Rolle (sales_attendant), die ausschließlich Dokumente in die Collection sales innerhalb der Datenbank sales_db einfügen darf.

use sales
db.createRole(
   {
     role: "sales_attendant",
     privileges: [
       {
         resource: { db: "sales_db", collection: "sales" },
         actions: [ "insert" ]
       }
     ],
     roles: []
   }
)

Integrierte Rollen 

Integrierte Rollen sind vordefinierte Rollen, die Nutzern zugewiesen werden und ihnen erlauben, z. B. Lese- und Schreiboperationen auf Collections in einer Datenbank auszuführen. Beispiele für integrierte Rollen sind read, write, readWrite, dbAdmin und readAnyDatabase.

• read und readWrite (datenbankspezifischer Zugriff): Diese Rollen gewähren wahlweise nur Lese- oder Lese-/Schreibzugriff auf alle Nicht-System-Collections innerhalb einer angegebenen Datenbank.
• dbAdmin: Diese Rolle verleiht die administrativen Rechte, die für die Verwaltung einer bestimmten Datenbank nötig sind, etwa zum Erstellen, Löschen und Anpassen von Indizes und Collections. Geeignet für Entwicklungsteams oder Wartungsskripte für Datenbanken.
• clusterAdmin (operativer Zugriff): Diese hochprivilegierte Rolle ist meist dem Operations-Team (DevOps/Ops) vorbehalten. Sie gewährt die Berechtigungen zur Verwaltung der gesamten MongoDB-Umgebung, einschließlich periodischer Backups, Konfiguration von Replica Sets und Sharding.

Privilegien (Berechtigungen)

Privilegien sind eine Menge von Aktionen (z. B. find, insert), die für eine Fähigkeit erlaubt sind.

Beispiel: Wenn die Fähigkeit lautet „Kundinnen und Kunden über ihren aktuellen Kontostand informieren“, dann könnten die Nutzerprivilegien (z. B. am Bankschalter) nur Lesezugriff umfassen. Wenn die Fähigkeit lautet, das Transaktionslimit eines Kontos zu erhöhen, könnten die Privilegien Lesen und Schreiben umfassen.

Geerbte Privilegien

Eine Rolle kann eine oder mehrere bestehende Rollen (inklusive aller Privilegien) einschließen. Eine dbAdmin-Rolle kann zum Beispiel die Rollen read, write und update (die jeweils eigenständig definiert sein können) samt ihrer Privilegien enthalten.

Ressourcen

Eine Ressource ist eine Datenbank, eine Collection, eine Menge von Collections oder der Cluster. 

Das Prinzip der minimalen Rechte umsetzen

In der modernen Datenbanksicherheit ist das Prinzip der minimalen Rechte (PoLP) zentral. Es besagt, dass jeder Nutzer nur die minimal notwendigen Berechtigungen erhalten sollte, um seine Aufgaben zu erfüllen.

Ein Best-Practice-Beispiel: Anstatt einen globalen readWrite-Nutzer zu verwenden, erstellst du anwendungsspezifische Nutzer. Wenn dein Inventory-Service nur mit der Datenbank app_data arbeitet, sollte der Anwendungsnutzer ausschließlich readWrite-Zugriff auf genau diese eine Datenbank erhalten. Diese Kapselung verhindert, dass ein kompromittierter Service unbefugt auf andere Datenbanken (etwa billing oder users) zugreift.

Codebeispiel: 

Erstellen eines Nutzers mit minimalen Rechten. Dieses Beispiel legt einen Nutzer (branch_manager) an, dessen Lese-/Schreibzugriff strikt auf die Datenbank bank_data beschränkt ist.

use admin
db.createUser(
   {
     user: "branch_manager",
     pwd: passwordPrompt(),
     roles: [ 
       { role: "readWrite", db: "bank_data" }
     ]
   }
)

Best Practices

• Rollen und Richtlinien frühzeitig klar definieren und zuweisen.
• Immer dem Prinzip der minimalen Rechte folgen, um Sicherheit hochzuhalten.
• Wenn möglich integrierte Rollen nutzen und zugewiesene Rollen regelmäßig prüfen, um Auffälligkeiten zu erkennen.