RBACX-Updates: ReBAC und AI-Richtlinien

RBACX nach sechs Monaten: ReBAC, KI-generierte Richtlinien und Batch-Autorisierung

In den letzten sechs Monaten hat sich die RBACX-Bibliothek von einer einfachen RBAC/ABAC-Engine zu einem umfassenden System mit ReBAC und KI-generierten Richtlinien entwickelt. Kritische Sicherheitslücken wurden behoben: Umgehung der Deny-Overrides im Compiler, DoS durch Rekursion in Bedingungen und SSRF in der HTTP-Quelle. Das System erzwingt nun MAX_CONDITION_DEPTH=50, verify_ssl und blockiert private IPs.

Die Batch-Berechtigungsprüfung wurde über die Methoden evaluate_batch_async und evaluate_batch_sync in der Guard-Klasse implementiert. Dies löst das Problem mehrerer Anfragen in UI-Anwendungen, wo parallele Auswertung mit asyncio.gather die Latenz reduziert.

decisions = await guard.evaluate_batch_async([
    (subject, Action("read"),   doc, ctx),
    (subject, Action("write"),  doc, ctx),
    (subject, Action("delete"), doc, ctx),
])

ReBAC: Beziehungsgraphen statt Attribute

Beziehungsbasierte Autorisierung (ReBAC) führt ein "Wer hat wem was gewährt"-Modell ein, ähnlich wie bei Google Drive oder GitHub. Berechtigungen werden durch einen Entitätsgraphen definiert: Ein Dokumentenbesitzer delegiert Zugriff. Integrationen mit OpenFGA und SpiceDB unterstützen synchrone/asynchrone Aufrufe, einschließlich Batch-gRPC für Objektlisten. Ein lokaler Graph eignet sich für Tests.

Die Implementierung erforderte eine Überarbeitung der Richtlinienauswertung basierend auf der Ressourcenspezifität, mit Tests für Äquivalenz zwischen Kompilierungs- und Interpretationspfaden.

Richtliniengenerierung mit LLMs

Das zusätzliche Paket rbacx[ai] fügt AIPolicy hinzu, um die Richtlinienerstellung aus OpenAPI-Schemata zu automatisieren. Die Pipeline: LLM-Generierung → JSON-Schema-Validierung → Wiederholungsversuche → Linter → Kompilierung.

from rbacx.ai import AIPolicy

ai = AIPolicy(api_key="sk-...", model="gpt-4o")
result = await ai.from_schema(openapi_schema)
guard = Guard(result.policy)

Methoden wie refine_policy zur Verfeinerung in natürlicher Sprache und explain_decision erhalten die Determiniertheit der Engine. Unterstützt werden OpenAI, Ollama, Azure und kompatible Anbieter mit Wiederholungslimits.

Die Kurzform roles: ["admin", "editor"] vereinfacht RBAC, ohne Flexibilität zu verlieren. Kombination mit condition via UND, wobei der Linter vor Überschneidungen warnt.

Weitere Leistungsverbesserungen

• Caching mit einem Redis-Adapter (rbacx[cache-redis]) für Multi-Host-Bereitstellungen.
• Async-Adapter für Django ASGI 4.1+.
• Strenger Typmodus: Guard(policy, strict_types=True) deaktiviert implizite Typumwandlungen.
• Entscheidungsverfolgung mit explain=True zum Debuggen von Regelabgleichen.

Diese Änderungen gewährleisten Skalierbarkeit in der Produktion: von PyQt-UI bis zu Microservices.

Wichtigste Erkenntnisse

• Sicherheit zuerst: Behobene Deny-Umgehung, DoS-Rekursion und SSRF; Fail-Closed-Verhalten.
• ReBAC-Integrationen: OpenFGA/SpiceDB mit Batch-gRPC, lokaler Graph für die Entwicklung.
• KI-Automatisierung: Richtlinien aus OpenAPI ohne manuelle DSL, mit Validierung und Wiederholungen.
• Batch-Berechtigungen: Parallele Auswertung für UI und Objektlisten.
• Leistung: Redis-Cache, asynchrones Django, strenge Typisierung.

— Editorial Team