Rollenbasierte Zugriffssteuerung für Daten

Unterstützt in:

Die datenbasierte rollenbasierte Zugriffssteuerung (data RBAC) ist ein Sicherheitsmodell, bei dem der Nutzerzugriff auf Daten innerhalb einer Organisation anhand individueller Nutzerrollen eingeschränkt wird. Mit einer RBAC für Daten können Administratoren Bereiche definieren und sie zuweisen. damit die Nutzenden nur auf die für ihre Arbeit notwendigen Daten zugreifen können. Funktionen.

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. Hier wird festgelegt, welche Funktionen für Nutzer auf Grundlage ihrer Rollen verfügbar sind. So hat beispielsweise eine Junior-Analysefachkraft möglicherweise nur Zugriff auf Dashboards, aber nicht, um Erkennungsregeln zu erstellen oder zu ändern. 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. Es legt fest, ob ein Nutzer Daten je nach Rolle ansehen, bearbeiten oder löschen darf. Für In einem CRM-System (Customer-Relationship-Management) kann ein Mitarbeiter Zugriff auf die Kontaktdaten der Kundschaft haben, Finanzdaten, während Finanzmanagende Zugriff auf die Finanzdaten haben. nicht jedoch die Kontaktdaten der Kundschaft.

Daten-RBAC und Feature-RBAC werden häufig zusammen verwendet, um eine umfassende Zugangskontrollsystem. 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

Sehen Sie sich die Liste der Google SecOps an, um die Implementierung zu planen vordefinierte Google SecOps-Rollen und -Berechtigungen Anforderungen Ihrer Organisation abzugleichen. Erstellen Sie eine Strategie, um Bereiche zu definieren, die Ihre Organisation benötigt, und eingehende Daten zu labeln. Identifizieren welche Mitglieder Ihrer Organisation Zugriff auf die Daten haben müssen, um diese Bereiche zu erweitern. 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 einer bestimmten Zugriffsebene haben je nach den zugewiesenen Bereichen eingeschränkten Zugriff auf Daten. Diese Umfänge beschränken ihre Sichtbarkeit und Aktionen auf bestimmte Daten. Die spezifischen Die mit dem eingeschränkten Zugriff verbundenen Berechtigungen sind in der folgenden Tabelle beschrieben.

  • Nutzer mit der Rolle „Global“ haben keine zugewiesenen Bereiche und uneingeschränkten Zugriff auf alle Daten in Google SecOps. Die spezifischen Berechtigungen, die mit globalen erhalten Sie in der folgenden Tabelle.

Data-RBAC-Administratoren können Bereiche erstellen und Nutzern zur Steuerung zuweisen. für den Datenzugriff in Google SecOps. Um einen Nutzer auf bestimmte -Bereichen, müssen Sie ihnen den eingeschränkten Datenzugriff für die Chronicle API zuweisen. (roles/chronicle.restrictedDataAccess) Rolle zusammen mit eine vordefinierte oder eine benutzerdefinierte Rolle. Die Chronicle API-Rolle für eingeschränkten Datenzugriff identifiziert einen Nutzer als Nutzer mit Umfang. 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.
Vordefinierter Lesezugriff Eingeschränkter Datenzugriff auf Chronicle API (roles/chronicle.restrictedDataAccess) und Betrachter von eingeschränktem Datenzugriff in Chronicle API (roles/chronicle.restrictedDataAccessViewer) Chronicle API Restricted Data Access Viewer
Zugriff auf benutzerdefinierte Bereiche Chronicle API Restricted Data Access (roles/chronicle.restrictedDataAccess) und benutzerdefinierte Rolle Benutzerdefinierte Berechtigungen innerhalb von Funktionen
Benutzerdefinierter globaler Zugriff Berechtigung chronicle.globalDataAccessScopes.permit und benutzerdefinierte Rolle Globale Berechtigungen innerhalb von Funktionen

Im Folgenden finden Sie eine Beschreibung der einzelnen Zugriffstypen in der Tabelle:

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 eine oder mehrere Rollen basierend auf den erforderlichen Berechtigungen zuweisen.

Vordefinierter Lesezugriff:Dieser Zugriff ist für Nutzer gedacht, die nur Lesezugriff benötigen. Zugriff haben. Die Rolle „Restricted Data Access“ (Eingeschränkter Datenzugriff) der Chronicle API identifiziert einen Nutzer als Nutzer mit eingeschränktem Zugriff. Die Chronicle API-Rolle „Eingeschränkter Datenzugriff“ gibt Aufschluss darüber, in den Funktionen für Nutzer verfügbar ist.

Zugriff mit benutzerdefiniertem Bereich: Die Rolle „Eingeschränkter Datenzugriff“ der Chronicle API identifiziert einen Nutzer als Nutzer mit begrenztem Zugriff. Die benutzerdefinierte Rolle gibt die Funktionen an, auf die der Nutzer zugreifen kann. Die Bereiche, die dem eingeschränkten Datenzugriff der Chronicle API hinzugefügt wurden gibt an, auf welche Daten die Nutzer in den Funktionen zugreifen können. Damit benutzerdefinierte RBAC-Bereiche korrekt funktionieren, schließen Sie den Parameter chronicle.DataAccessScopes.permit oder chronicle.globalDataAccessScopes.permit Berechtigungen beim Erstellen der benutzerdefinierten Rollen. Diese Berechtigungen können wenn Sie den vordefinierten Chronicle API Editor oder Chronicle API Admin als Administrator für Ihre benutzerdefinierten Rollen.

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

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 definieren, innerhalb des Geltungsbereichs 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 den Umfang und die Daten zu definieren die durch die Bereiche definiert wird.

Datensichtbarkeit mit Zulassungs- und Sperrlabels

Jeder Bereich enthält ein oder mehrere Labels für Zugriff erlauben. Optional: Zugriff verweigern. Mit Labels für den Zugriff gewähren Sie Nutzern Zugriff auf die mit dem Label verknüpften Daten. Labels zum Ablehnen des Zugriffs verweigern Nutzern den Zugriff auf die Daten, die mit dem Label verknüpft ist. 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 zum Ablehnen von Zugriffsrechten werden mit dem ODER-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:

Logtyp: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 Logs, die dem Bereich entsprechen:

  • Zugriffsprotokoll von App1 mit Schweregrad: Warnung
  • Firewall-Log von App1 mit Schweregrad: Warnung

Beispiele für Logs, die nicht dem Bereich entsprechen:

  • Systemprotokoll von App1 mit 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 durch Kontext und Informationen, die über die Logrohdaten hinausgehen. Auf angereicherte Ereignisse kann nur dann innerhalb eines Bereichs zugegriffen werden, wenn auf das zugrunde liegende Ereignis innerhalb des Bereichs zugegriffen werden kann und keines der angereicherten Labels eines der Ablehnungslabels des Bereichs enthält.

Sehen wir uns zum Beispiel ein Rohprotokoll an, das auf einen fehlgeschlagenen Anmeldeversuch von einer IP-Adresse hinweist. Adresse und das angereicherte Label user_risk: high (gibt an, dass es sich um einen Nutzer mit hohem Risiko handelt). Für einen Nutzer mit einem Bereich mit dem Ablehnungslabel „user_risk: high“ ist ein Fehler aufgetreten Anmeldeversuchen von Nutzern mit hohem Risiko.

Auswirkungen der RBAC für Daten auf Google Security Operations-Features

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