RBAC und ABAC

Einfach erklärt

RBAC und ABAC steuern, wer auf was zugreifen darf.

RBAC (Role-Based):
User → Role → Permissions
├── Alice → Admin → [read, write, delete]
├── Bob → Editor → [read, write]
└── Carol → Viewer → [read]

ABAC (Attribute-Based):
IF user.department == "Finance"
   AND resource.type == "Report"
   AND time.hour BETWEEN 9 AND 17
   AND user.device == "Corporate"
THEN allow

Technischer Deep Dive

RBAC Implementation

class RBAC:
    def __init__(self):
        self.roles = {
            "admin": ["read", "write", "delete", "admin"],
            "editor": ["read", "write"],
            "viewer": ["read"]
        }
        self.user_roles = {}
    
    def assign_role(self, user_id, role):
        self.user_roles[user_id] = role
    
    def has_permission(self, user_id, permission):
        role = self.user_roles.get(user_id)
        return permission in self.roles.get(role, [])

ABAC mit OPA

# policy.rego
package authz

default allow = false

allow {
    input.user.role == "admin"
}

allow {
    input.user.department == input.resource.department
    input.action == "read"
}

RBAC und ABAC im direkten Vergleich

Kriterium	RBAC	ABAC
Grundprinzip	Statische Rollen	Dynamische Regeln über Attribute
Komplexität	Niedrig, leicht verständlich	Höher, mächtiger
Kontext (Zeit, Ort, Gerät)	Nicht abbildbar	Kernstärke
Auditierbarkeit	Einfach (“Wer hat Rolle X?”)	Schwieriger (“Welche Regel griff wann?”)
Skalierung	Gefahr der Rollen-Explosion	Wenige Policies decken viele Fälle ab
Typischer Einsatz	Interne Tools, klare Hierarchien	Multi-Tenant, Zero Trust, feingranulare Kontrolle

In der Praxis ist die Kombination Standard: RBAC definiert die Grundrechte (“Editor darf schreiben”), ABAC verfeinert sie kontextabhängig (“aber nur Dokumente des eigenen Mandanten, nur vom verwalteten Gerät”).

Zugriffssteuerung in KI- und LLM-Systemen

Autorisierungsmodelle bekommen durch KI-Anwendungen neue Einsatzfelder:

• RAG mit Berechtigungsprüfung: Wenn ein Retrieval-System Dokumente in den Modellkontext lädt, müssen die Rechte des anfragenden Nutzers durchgesetzt werden – sonst fasst das Modell Inhalte zusammen, die der Nutzer nie öffnen dürfte. Die Filterung muss vor der Übergabe an das Modell geschehen, nicht per Prompt-Anweisung.
• KI-Agenten als eigene Prinzipale: Ein Agent mit Tool-Zugriff braucht eine eigene Rolle mit minimalen Rechten. ABAC erlaubt zusätzlich kontextabhängige Einschränkungen, etwa “nur lesend außerhalb der Geschäftszeiten” oder “Schreibzugriff nur nach menschlicher Freigabe”.
• Modell- und Feature-Zugriff: Wer darf welche Modelle aufrufen, welche Budgets nutzen, welche Features (z. B. Fine-Tuning) verwenden? Auch das ist klassische Autorisierung – oft als RBAC auf Plattformebene umgesetzt.
• Autorisierung ist kein Prompt: Anweisungen wie “Antworte nur Admins” im System-Prompt sind keine Zugriffskontrolle – sie lassen sich durch Prompt Injection umgehen. Durchsetzung gehört in die Anwendungsschicht.

Typische Stolperfallen

Fehler	Folge	Besser
Rollen-Explosion	Hunderte Spezialrollen, niemand blickt durch	Wenige Basisrollen + ABAC für Ausnahmen
Rechte direkt an Nutzer vergeben	Umgeht das Rollenmodell, kein Überblick	Rechte ausschließlich über Rollen/Policies
Autorisierung im Client	Lässt sich durch API-Aufrufe umgehen	Durchsetzung serverseitig, Client nur zur Anzeige
Keine Access Reviews	Verwaiste Rollen und Permission Creep	Regelmäßige Überprüfung und Entzug
ABAC-Policies ohne Tests	Fehlerhafte Regeln sperren aus oder öffnen zu viel	Policies wie Code behandeln: Versionierung, Tests

Abgrenzung zu verwandten Begriffen

• IAM ist das Gesamtsystem aus Identitäten, Authentifizierung und Autorisierung – RBAC und ABAC sind seine Autorisierungsmodelle.
• ReBAC (Relationship-Based Access Control) leitet Rechte aus Beziehungen ab (“Besitzer des Dokuments”, “Mitglied des Teams”) – verbreitet in kollaborativen Anwendungen.
• ACLs (Access Control Lists) hängen Berechtigungen direkt an einzelne Ressourcen – einfach, aber bei vielen Nutzern und Ressourcen schwer zu pflegen.