Rollenbasierte Zugriffssteuerung für Daten

Unterstützt in:

Die rollenbasierte Zugriffssteuerung für Daten (data RBAC) ist ein Sicherheitsmodell, bei dem der Nutzerzugriff auf Daten innerhalb einer Organisation anhand individueller Nutzerrollen eingeschränkt wird. Mit der datenbasierten RBAC können Administratoren Bereiche definieren und Nutzern zuweisen, damit Nutzer nur auf die Daten zugreifen können, die für ihre berufliche Tätigkeit erforderlich sind.

Auf dieser Seite finden Sie einen Überblick über die RBAC für Daten und erfahren, wie Labels und Bereiche zusammenwirken, um Berechtigungen für den Datenzugriff zu definieren.

Unterschied zwischen RBAC für Daten und RBAC für Funktionen

Die datenbasierte und die funktionsbasierte RBAC sind beide Methoden zur Zugriffssteuerung innerhalb eines Systems, die sich jedoch auf unterschiedliche Aspekte konzentrieren.

Mit der Feature-RBAC wird der Zugriff auf bestimmte Funktionen innerhalb eines Systems gesteuert. Sie legen damit fest, welche Funktionen für Nutzer auf Grundlage ihrer Rollen verfügbar sind. Ein Junior-Analyst kann beispielsweise nur Dashboards aufrufen, aber keine Erkennungsregeln erstellen oder ändern. Ein Senior-Analyst hat dagegen die Berechtigungen zum Erstellen und Verwalten von Erkennungsregeln. Weitere Informationen zur rollenbasierten Zugriffssteuerung für Funktionen finden Sie unter Zugriffssteuerung für Funktionen mit IAM konfigurieren.

Mit der datenbasierten RBAC wird der Zugriff auf bestimmte Daten oder Informationen innerhalb eines Systems gesteuert. Damit wird festgelegt, ob ein Nutzer Daten basierend auf seinen Rollen ansehen, bearbeiten oder löschen kann. In einem CRM-System (Customer Relationship Management) hat ein Vertriebsmitarbeiter beispielsweise Zugriff auf Kundenkontaktdaten, aber nicht auf Finanzdaten, während ein Finanzmanager Zugriff auf die Finanzdaten, aber nicht auf die Kundenkontaktdaten hat.

Die datenbasierte und die funktionsbasierte RBAC werden häufig zusammen verwendet, um ein umfassendes Zugriffssteuerungssystem bereitzustellen. So kann einem Nutzer beispielsweise der Zugriff auf eine bestimmte Funktion (funktionsbasierte RBAC) gewährt werden, innerhalb dieser Funktion kann sein Zugriff auf bestimmte Daten jedoch basierend auf seiner Rolle eingeschränkt werden (datenbasierte RBAC).

Implementierung planen

Vergleichen Sie zur Planung Ihrer Implementierung die Liste der vordefinierten Google SecOps-Rollen und ‑Berechtigungen mit den Anforderungen Ihrer Organisation. Erstellen Sie eine Strategie, um Bereiche zu definieren, die Ihre Organisation benötigt, und eingehende Daten zu labeln. Legen Sie fest, welche Mitglieder Ihrer Organisation Zugriff auf die mit diesen Bereichen verknüpften Daten haben müssen. Wenn Ihre Organisation IAM-Richtlinien benötigt, die sich von den vordefinierten Google SecOps-Rollen unterscheiden, erstellen Sie benutzerdefinierte Rollen, um diese Anforderungen zu erfüllen.

Nutzerrollen

Nutzer können entweder auf Daten mit begrenztem Zugriff (Nutzer mit begrenztem Zugriff) oder auf globale Daten (globale Nutzer) zugreifen.

  • Nutzer mit Bereichszugriff haben je nach zugewiesenem Bereich eingeschränkten Zugriff auf Daten. Diese Bereiche beschränken die Sichtbarkeit und Aktionen auf bestimmte Daten. Die spezifischen Berechtigungen für den Zugriff mit Begrenzung sind in der folgenden Tabelle aufgeführt.

  • Globale Nutzer haben keine zugewiesenen Bereiche und uneingeschränkten Zugriff auf alle Daten in Google SecOps. Die spezifischen Berechtigungen für den globalen Zugriff sind in der folgenden Tabelle aufgeführt.

Administratoren der datenbasierten RBAC können Bereiche erstellen und Nutzern zuweisen, um ihren Datenzugriff in Google SecOps zu steuern. Wenn Sie einen Nutzer auf bestimmte Bereiche beschränken möchten, müssen Sie ihm die Rolle „Eingeschränkter Datenzugriff der Chronicle API“ (roles/chronicle.restrictedDataAccess) sowie eine vordefinierte oder benutzerdefinierte Rolle zuweisen. Die Rolle „Restricted Data Access“ der Chronicle API identifiziert einen Nutzer als Nutzer mit eingeschränktem Zugriff. Sie müssen Nutzern, die globalen Datenzugriff benötigen, nicht die Rolle „Eingeschränkter Datenzugriff für Chronicle“ zuweisen.

Nutzern können die folgenden Rollen zugewiesen werden:

Zugriffstyp Rollen Berechtigungen
Vordefinierter globaler Zugriff Globalen Nutzern kann eine beliebige der vordefinierten IAM-Rollen zugewiesen werden.
Lesezugriff mit vordefiniertem Umfang Der eingeschränkte Datenzugriff für die Chronicle API (roles/chronicle.restrictedDataAccess) und der Chronicle API Restricted Data Access Viewer (roles/chronicle.restrictedDataAccessViewer) Chronicle API Restricted Data Access Viewer
Zugriff auf benutzerdefinierte Bereiche Der eingeschränkte Datenzugriff für die Chronicle API (roles/chronicle.restrictedDataAccess) und eine benutzerdefinierte Rolle Benutzerdefinierte Berechtigungen innerhalb von Funktionen
Benutzerdefinierter globaler Zugriff chronicle.globalDataAccessScopes.permit-Berechtigung und benutzerdefinierte Rolle Globale Berechtigungen innerhalb von Funktionen

Im Folgenden werden die einzelnen Zugriffstypen in der Tabelle beschrieben:

Vordefinierter globaler Zugriff:Dieser Zugriff ist in der Regel für Nutzer erforderlich, die Zugriff auf alle Daten benötigen. Sie können einem Nutzer je nach erforderlichen Berechtigungen eine oder mehrere Rollen zuweisen.

Lesezugriff mit vordefiniertem Umfang:Dieser Zugriff ist für Nutzer gedacht, die Lesezugriff benötigen. Die Rolle „Restricted Data Access“ der Chronicle API identifiziert einen Nutzer als Nutzer mit eingeschränktem Zugriff. Die Rolle „Chronicle API Restricted Data Access Viewer“ gewährt Nutzern Lesezugriff auf ihre Funktionen.

Zugriff mit benutzerdefiniertem Bereich:Die Rolle „Eingeschränkter Datenzugriff“ der Chronicle API identifiziert einen Nutzer als Nutzer mit begrenztem Zugriff. Die benutzerdefinierte Rolle gibt an, auf welche Funktionen der Nutzer zugreifen kann. Die Bereiche, die der Rolle „Eingeschränkter Datenzugriff für die Chronicle API“ hinzugefügt wurden, geben an, auf welche Daten die Nutzer in den Funktionen zugreifen können. Damit benutzerdefinierte RBAC-Bereiche ordnungsgemäß funktionieren, dürfen Sie beim Erstellen der benutzerdefinierten Rollen die Berechtigungen chronicle.DataAccessScopes.permit oder chronicle.globalDataAccessScopes.permit nicht angeben. Diese Berechtigungen sind möglicherweise enthalten, wenn Sie die vordefinierte Rolle „Chronicle API Editor“ oder „Chronicle API Admin“ als Ausgangspunkt für Ihre benutzerdefinierten Rollen verwendet haben.

Benutzerdefinierter globaler Zugriff:Dieser Zugriff ist für Nutzer gedacht, die innerhalb ihrer zugewiesenen Funktionen uneingeschränkte Berechtigungen benötigen. Wenn Sie einem Nutzer benutzerdefinierten globalen Zugriff gewähren möchten, müssen Sie zusätzlich zur benutzerdefinierten Rolle, die dem Nutzer zugewiesen ist, die Berechtigung chronicle.globalDataAccessScopes.permit angeben.

Zugriffssteuerung mit Bereichen und Labels

Mit Google SecOps können Sie den Datenzugriff für Nutzer mithilfe von Bereichen steuern. Bereiche werden mithilfe von Labels definiert, die die Daten festlegen, auf die ein Nutzer innerhalb des Bereichs Zugriff hat. Bei der Datenaufnahme werden den Daten Metadaten in Form von Labels zugewiesen, z. B. Namespace (optional), Metadaten zur Datenaufnahme (optional) und Protokolltyp (erforderlich). Dies sind Standardlabels, die bei der Datenaufnahme auf Daten angewendet werden. Außerdem können Sie benutzerdefinierte Labels erstellen. Sie können sowohl Standard- als auch benutzerdefinierte Labels verwenden, um die Bereiche und die Datenzugriffsebene zu definieren, die die Bereiche definieren.

Datensichtbarkeit mit Labels für Zulassen und Verbieten

Jeder Bereich enthält ein oder mehrere Labels vom Typ Zugriff zulassen und optional Labels vom Typ Zugriff verweigern. Mit Labels für den Zugriff gewähren Sie Nutzern Zugriff auf die mit dem Label verknüpften Daten. Mit Labels für den Zugriffsverweigerung wird Nutzern der Zugriff auf die mit dem Label verknüpften Daten verweigert. Labels für den Zugriffsverweigerung überschreiben die Labels für den Zugriffszugriff, um den Nutzerzugriff einzuschränken.

In einer Bereichsdefinition werden Zutrittslabels desselben Typs (z. B. Protokolltyp) mit dem OR-Operator kombiniert, während Labels verschiedener Typen (z. B. Protokolltyp und benutzerdefiniertes Label) mit dem AND-Operator kombiniert werden. Labels für den Zugriffsverweigerung werden mit dem OR-Operator kombiniert. Wenn in einem Bereich mehrere Labels zum Verweigern des Zugriffs angewendet werden, wird der Zugriff verweigert, wenn eine Übereinstimmung mit EINEM dieser Labels vorliegt.

Angenommen, Sie haben ein Cloud Logging-System, das Protokolle mit den folgenden Labeltypen kategorisiert:

Protokolltyp:Zugriff, System, Firewall

Namespace:App1, App2, Datenbank

Schweregrad:Kritisch, Warnung

Angenommen, Sie haben einen Bereich namens „Eingeschränkte Protokolle“ mit folgendem Zugriff:

Labeltyp Zulässige Werte Abgelehnte Werte
Logtyp Zugriff, Firewall System
Namespace App1 App2, Datenbank
Schweregrad Warnung Kritisch

Die Definition des Gültigkeitsbereichs sieht so aus:

Zulassen:(Log type: "Access" OR "Firewall") AND (Namespace: "App1") AND (Severity: "Warning")

Ablehnen:Log type: "System" OR Namespace: App2 OR Namespace: Database OR Severity: "Critical"

Beispiele für Protokolle, die dem Umfang entsprechen:

  • Zugriffsprotokoll von App1 mit dem Schweregrad „Warnung“
  • Firewall-Log von App1 mit dem Schweregrad „Warnung“

Beispiele für Logs, die nicht in den Geltungsbereich fallen:

  • Systemprotokoll von App1 mit dem Schweregrad „Warnung“
  • Zugriffsprotokoll aus Datenbank mit „Schweregrad: Warnung“
  • Firewall-Log von App2 mit dem Schweregrad „Kritisch“

Datensichtbarkeit in angereicherten Ereignissen

Angereicherte Ereignisse sind Sicherheitsereignisse, die über die Rohprotokolldaten hinaus mit zusätzlichem Kontext und Informationen ergänzt wurden. Auf angereicherte Ereignisse kann nur dann im jeweiligen Bereich zugegriffen werden, wenn auf das zugrunde liegende Ereignis im jeweiligen Bereich zugegriffen werden kann und keine der angereicherten Labels eines der Ablehnungslabels des Bereichs enthält.

Angenommen, ein Rohprotokoll enthält einen fehlgeschlagenen Anmeldeversuch von einer IP-Adresse und das angereicherte Label user_risk: high (für einen Nutzer mit hohem Risiko). Ein Nutzer mit einem Gültigkeitsbereich mit dem Label „Deny“ user_risk: high kann keine fehlgeschlagenen Anmeldeversuche von Nutzern mit hohem Risiko sehen.

Auswirkungen der RBAC für Daten auf die Funktionen von Google Security Operations

Nachdem die RBAC für Daten konfiguriert wurde, sehen Nutzer in den Google Security Operations-Funktionen gefilterte Daten. Die Auswirkungen hängen davon ab, wie die Funktion in die zugrunde liegenden Daten eingebunden ist. Informationen dazu, wie sich die datenbasierte RBAC auf die einzelnen Funktionen auswirkt, finden Sie unter Auswirkungen der datenbasierten RBAC auf Google SecOps-Funktionen.

Nächste Schritte