Was ist Role-Based Access Control (RBAC)?

Warum RBAC für die Absicherung von Cloud-Infrastruktur entscheidend ist

Cloud-Umgebungen bewegen sich schnell, sind hochdynamisch und entwickeln sich ständig weiter. Ohne geeignete Zugriffskontrolle gerät vieles außer Kontrolle. RBAC steuert die Zugriffskontrolle über vordefinierte Rollen, aus denen Nutzer ihre Berechtigungen direkt erben. RBAC ist unverzichtbar, weil es das Prinzip der geringsten Berechtigung durchsetzt und sicherstellt, dass Nutzer und Dienste nur auf das zugreifen, was sie tatsächlich benötigen. RBAC hält Cloud-Umgebungen zudem konform mit wichtigen Sicherheitsframeworks wie HIPAA, GDPR und SOC 2.

Cloud-Anbieter wie AWS, Azure und GCP bieten native RBAC-Tools. Das Problem? Sie lassen oft Lücken. Fein abgestufte Berechtigungen zu verwalten, Drift zu überwachen und Compliance über Multi-Cloud-Setups hinweg aufrechtzuerhalten ist nicht trivial. Hier kommen Drittanbieterlösungen wie Wiz ins Spiel. Plattformen mit integrierten CIEM-Funktionen bieten tiefere Transparenz, automatisieren die Durchsetzung von Rollen und überwachen kontinuierlich riskante Berechtigungen — so halten Unternehmen den Zugriff nach dem Prinzip der geringsten Berechtigung auch im großen Maßstab aufrecht.

Zentrale Komponenten von RBAC

RBAC hält den Cloud-Zugriff unter Kontrolle, indem es Berechtigungen um Rollen herum strukturiert statt um einzelne Nutzer. Das folgende Diagramm zeigt ein vereinfachtes Bild davon, wie RBAC in Cloud-Umgebungen üblicherweise eingerichtet wird.

• Rollen lassen sich als aufgabenbezogene Berechtigungsgruppen verstehen. Statt Alice und Bob einzeln Berechtigungen zu geben, erstellt man Rollen wie „Developer”, „Ops” und „Security Admin” — jeweils mit dem passenden Zugriffsniveau.

• Berechtigungen legen fest, was eine Rolle darf und was nicht — Daten lesen, Ressourcen bereitstellen, Nutzer verwalten und Ähnliches. Rollen bündeln Berechtigungen logisch, sodass man sie nicht pro Nutzer konfigurieren muss. Eine Berechtigung kann den Zugriff ausdrücklich erlauben oder verweigern. 

• Nutzer sind die Personen (oder Dienste), denen Rollen zugewiesen werden. Statt einzelne Zugriffe zu verwalten, ordnet man einen Nutzer einfach der richtigen Rolle zu und überlässt RBAC den Rest.

• Rollenrichtlinien sind Regeln, die festlegen, wer wann welcher Rolle zugewiesen wird. Diese Richtlinien automatisieren und standardisieren Rollenzuweisungen, statt sich auf spontane Zugriffsfreigaben zu verlassen.

• Die Überprüfung von Rollen ist unverzichtbar, denn mit der Zeit sammeln sich häufig unnötige Berechtigungen an und überprivilegierte Rollen entstehen. CIEM-Tools überwachen die Rollennutzung kontinuierlich, kennzeichnen riskante Berechtigungen und helfen Teams, solchen Berechtigungs-Drift oder zu weit gefasste Rollen zu beheben.

Startet in AWS eine neue Person im Entwicklungsteam, wird sie einer Entwicklerrolle zugewiesen und erbt alle notwendigen Berechtigungen aus dieser Rolle. 

Cloud-native Tools wie AWS IAM Access Analyzer helfen dabei, RBAC in Echtzeit durchzusetzen, und ermöglichen es, eine solide Datenperimeter-Strategie im Unternehmen aufrechtzuerhalten.

RBAC im Vergleich zu anderen Zugriffskontrollmodellen in Cloud-Umgebungen

Beim Verwalten von Zugriffen in Cloud-Umgebungen ist es entscheidend zu verstehen, wie sich RBAC von anderen Zugriffskontrollmodellen unterscheidet. Zu den wichtigsten Modellen gehören:

In Cloud-Umgebungen wird RBAC häufig bevorzugt, weil es einfach ist und sich gut an organisatorische Strukturen anpasst.

RBAC in der Praxis

In Cloud-Umgebungen wird Role-Based Access Control auf jeder Plattform anders umgesetzt. Die folgenden Beispiele zeigen die Unterschiede.

AWS-IAM-Rollen und -Richtlinien

In AWS werden Rollen und Richtlinien über Identity and Access Management (IAM) verwaltet. So können Nutzern Rollen zugewiesen werden, die fein abgestufte Richtlinien umfassen.

Diese AWS-IAM-Richtlinie enthält zwei Anweisungen: Das erste erlaubt der Rolle, alle Buckets im AWS-Konto aufzulisten; das zweite verweigert ausdrücklich die Berechtigung, einen Bucket zu löschen.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowListBuckets",
      "Effect": "Allow",
      "Action": "s3:ListBuckets",
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Sid": "DenyDeleteBuckets",
      "Effect": "Deny",
      "Action": "s3:DeleteBucket",
      "Resource": "arn:aws:s3:::*"
    }
  ]
}

Role-Based Access Control in Azure

Soll ein Nutzer alle Speicherkonten eines Abonnements anzeigen können, lässt sich ihm die Rolle Storage Account Contributor auf Abonnementebene zuweisen.

{
  "properties": {
    "displayName": "Deny Delete Storage Account",
    "policyType": "Custom",
    "mode": "All",
    "description": "This policy denies the deletion of the specified storage account.",
    "metadata": {
      "version": "1.0.0",
      "category": "Storage"
    },
    "parameters": {
      "storageAccountName": {
        "type": "String",
        "metadata": {
          "displayName": "Storage Account Name",
          "description": "The name of the storage account to protect from deletion."
        }
      }
    },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Storage/storageAccounts"
          },
          {
            "field": "name",
            "equals": "[parameters('storageAccountName')]"
          },
          {
            "field": "Microsoft.Resources/deploymentScripts/operation",
            "equals": "delete"
          }
        ]
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

Google Cloud IAM

In Google Cloud wird die Zugriffskontrolle über Identity and Access Management verwaltet, das Nutzern, Gruppen oder Dienstkonten Rollen in verschiedenen Geltungsbereichen zuweist — darunter Projekte, Ordner und Organisationen.

Um das Löschen eines bestimmten Storage-Buckets zu verhindern, lässt sich über eine Organisationsrichtlinie die Berechtigung storage.buckets.delete für diesen Bucket einschränken.

{
  "name": "projects/[PROJECT_ID]/policies/deny-delete-bucket",
  "spec": {
    "rules": [
      {
        "deny": {
          "permissions": ["storage.buckets.delete"],
          "resources": ["projects/[PROJECT_ID]/buckets/[BUCKET_NAME]"]
        }
      }
    ]
  }
}

RBAC in Kubernetes

Kubernetes RBAC steuert den Zugriff auf Ressourcen innerhalb eines Kubernetes-Clusters. 

Zu den zentralen Komponenten von Kubernetes RBAC gehören folgende Elemente:

• Role: Mit einer Role definieren Kubernetes-Administratoren eine Gruppe von Berechtigungen innerhalb eines Namespace.

• RoleBinding: Eine RoleBinding bindet einen Nutzer oder eine Gruppe von Nutzern an eine Role, sodass diese deren Berechtigungen innerhalb eines Namespace erben.

Das folgende Beispiel zeigt, wie sich in Kubernetes eine Role namens pod-reader im Namespace development mit Berechtigungen zum get, list und watch von Pods erstellen lässt.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Anschließend wird ein Nutzer an die Role im selben Namespace gebunden.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader-role
  apiGroup: rbac.authorization.k8s.io

Die RoleBinding read-pods weist die Role pod-reader dem Nutzer jane im selben Namespace zu.

Best Practices für RBAC in der Cloud

Mit diesen Best Practices lässt sich RBAC in der Cloud sicher und effizient verwalten:

• Prinzip der geringsten Berechtigung (PoLP) durchsetzen: Jeder Rolle werden nur die Berechtigungen zugewiesen, die für ihre spezifischen Aufgaben nötig sind. Infrastructure-as-Code-Tools (IaC) wie Terraform oder AWS CloudFormation definieren Rollen und Berechtigungen konsistent und nachvollziehbar.

• Rollenzuweisungen automatisieren: Rollen werden anhand von Nutzerattributen oder Aufgabenbereichen automatisch zugewiesen, was manuelle Fehler und Verwaltungsaufwand reduziert.

• RBAC mit weiteren IAM-Sicherheitsmaßnahmen verbinden: RBAC entfaltet seinen vollen Nutzen im Zusammenspiel mit Multi-Faktor-Authentifizierung (MFA), Identity Federation und weiteren Sicherheitsmaßnahmen.

RBAC sicher skalieren mit Wiz CIEM

Native IAM-Tools der Cloud-Anbieter bilden die Grundlage für RBAC. In Multi-Cloud-Umgebungen stoßen sie jedoch häufig an ihre Grenzen, da sich Rollen, Berechtigungen und Richtlinien je nach Plattform unterscheiden. Genau hier setzen die Funktionen von Wiz für Cloud Infrastructure Entitlement Management (CIEM) an.

Die CIEM-Funktionen von Wiz geben Sicherheitsteams die Transparenz und Kontrolle, um RBAC sicher zu skalieren:

• Effektive Berechtigungen über Clouds hinweg sichtbar machen: Wiz erfasst automatisch, wer über AWS, Azure, GCP und Kubernetes hinweg worauf zugreifen kann — bis auf Ressourcenebene — sodass sich unbeabsichtigte oder riskante Zugriffe erkennen lassen.

• Überprivilegierte Rollen erkennen und beheben: Wiz überwacht kontinuierlich Berechtigungsänderungen und erkennt Privilege Escalation frühzeitig. Es erkennt übermäßige Berechtigungen und hilft Teams, Rollen anhand der tatsächlichen Nutzung passend zuzuschneiden.

• Durchsetzung der geringsten Berechtigung automatisieren: Wiz analysiert die Berechtigungsnutzung über die Zeit und empfiehlt sicherere, engere Richtlinien. Es schlägt sogar das Aufräumen von Rollen vor, um Wildwuchs zu vermeiden.

• Compliance über Umgebungen hinweg sicherstellen: Wiz verfolgt Rollenzuweisungen und Zugriffsänderungen und unterstützt so die Einhaltung von Frameworks wie SOC 2, ISO 27001 und HIPAA.

• Identitäten im Kontext absichern: Wiz verknüpft RBAC-Daten mit Fehlkonfigurationen, offengelegten Secrets und Runtime-Risiken — so lässt sich priorisieren und beheben, was wirklich zählt.

Wiz ersetzt bestehende IAM-Tools nicht — es macht sie intelligenter, sicherer und skalierbarer.

So unterstützt Wiz CIEM die Umsetzung und Durchsetzung von RBAC im Cloud-Maßstab: Jetzt Demo buchen.