Google Zanzibar gilt seit seiner Veröffentlichung 2019 als bahnbrechendes Konzept im Bereich der Autorisierung. Sein Whitepaper inspirierte große Unternehmen wie AirBnB und Carta dazu, eigene, auf Zanzibar basierende Autorisierungssysteme zu entwickeln. Diese Systeme setzen auf Relationship-Based Access Control (ReBAC) und nutzen ein Modell, das auf den Beziehungen zwischen Objekten und Nutzern basiert. Obwohl Zanzibar wegen seiner Ausdrucksstärke und Skalierbarkeit oft gelobt wird, wird es häufig missverstanden oder idealisiert – insbesondere was seine Flexibilität betrifft. Tatsächlich ist dieses System weniger flexibel als vielfach angenommen, was erhebliche Auswirkungen auf Entwickler und Unternehmen hat, die es nutzen oder mitdenken wollen.
Der Kern von Zanzibar ist die relationale Struktur, die durch sogenannte Relationstupel dargestellt wird. Jedes Tupel besteht aus einem Objekt, einer Relation und einem Nutzer beziehungsweise einer Nutzergruppe. Das klingt zunächst simpel und elegant – doch dieser Ansatz hat eine harte Grenze: Er zwingt die Nutzer dazu, jede Autorisierungsregel in Form einer Relation zwischen genau einem Objekt und einem Nutzer oder einer fest definierten Nutzergruppe auszudrücken. Die Tatsache, dass dies so strikt vorgegeben ist, limitiert die Möglichkeiten erheblich. Vergleichbar ist dies mit einer Haiku-Struktur in der Dichtung, die zwar ausdrucksstark sein kann, dabei aber strengen Regeln folgt und eben gerade deshalb nicht beliebig flexibel ist.
Diese Strenge zeigt sich besonders im Umgang mit Berechtigungen, die auf allen Objekten eines Typs gelten sollen, also universelle Zugriffe beispielsweise für Administratoren. Zanzibar erlaubt keine Relation, die einfach „für alle Dokumente“ gilt – stattdessen müssen Berechtigungen einzeln auf jedes Objekt angewendet werden. Dies ist nicht nur ineffizient, sondern führt auch zu komplexen, gefährlichen Workarounds. Entwickler müssen umständliche Mechanismen implementieren, um eine solche globale Berechtigung überhaupt abzubilden. Diese Einschränkung hat praktische Bedeutung, wenn es um die Verwaltung von Berechtigungen in großen oder dynamischen Systemen geht, in denen Objekte häufig erstellt, gelöscht oder verändert werden.
Ein weiterer Aspekt, der die Flexibilität begrenzt, ist die Art und Weise, wie Zanzibar Autorisierungslogik umsetzt. Anstatt direkt zu fragen, ob ein Nutzer eine bestimmte Aktion ausführen darf, wird die Frage in Relation zu einer Benutzerrolle oder Gruppe gestellt. Diese Übersetzung von „Berechtigungen“ auf „Relationen“ ist jedoch nicht 1:1 möglich. Das bedeutet, dass Entwickler für jede einzelne Aktion eigene Relationstypen erstellen müssen. Wenn beispielsweise zwischen den Aktionen „Löschen“, „Archivieren“ oder „Besitzer übertragen“ unterschieden werden soll, müssen auch separate Relationen wie „can_delete“ oder „can_archive“ definiert werden, obwohl diese eigentlich Berechtigungen und keine reinen Relationen sind.
Dies verfälscht die eigentliche Bedeutung der Relationen und führt zu einem erhöhten kognitiven Aufwand bei der Modellierung und Pflege der Autorisierungslogik. Diese Eigenheit führt dazu, dass Zanzibar zwar Ausdrucksvielfalt bietet, aber eben keine echte Flexibilität. Es ist möglich, viele Szenarien mittels der erzwungenen Relationen darzustellen, doch es kostet viel Aufwand und erfordert teils komplexe Umwege. Die Tatsache, dass Entwickler oft gezwungen sind, Berechtigungen als Relationen zu maskieren, belegt, dass das System nicht ideal auf die komplexen Bedürfnisse moderner Anwendungen zugeschnitten ist. Eine technisch tiefere Betrachtung zeigt dies beispielhaft bei der sogenannten Userset-Rewrite-Funktion.
Sie erlaubt es, Relationen aus anderen Relationen zusammensetzen, etwa eine „Editor“-Relation, die neben den explizit als Editor definierten Nutzern auch jene einschließt, die Eigentümer des Dokuments sind. Dadurch werden Berechtigungen von einer Relation auf andere übertragen, was die Pflege erleichtern soll. Dennoch ist die zugrundeliegende Struktur strikt vordefiniert und lässt keine freien Kombinationen von Bedingungen zu, die über das Relation-Objekt-Nutzer-Dreieck hinausgehen. Für komplexe, dynamische Berechtigungsmodelle bedeutet dies eine erhebliche Einschränkung. Diese Limitierungen zeigen sich besonders deutlich, wenn man Zanzibar mit anderen Ansätzen vergleicht, beispielsweise mit Attributbasierter Zugriffskontrolle (ABAC) oder anderen flexiblen, regelbasierten Systemen.
Dort können Bedingungen viel freier formuliert werden, komplexe Zusammenhänge wie Zeitbeschränkungen, Rollen-Hierarchien oder polymorphe Regeln sind leichter umsetzbar. Zanzibar hingegen bleibt hierbei ziemlich starr und zwingt die implementierende Software dazu, deutlich mehr Komplexität außerhalb des Systems zu verwalten. Dabei sollte jedoch nicht vergessen werden, dass Zanzibar durchaus beeindruckende Stärken besitzt. Es wurde für den Einsatz in extrem großen Umgebungen wie bei Google entwickelt, wo die Anzahl der Objekte, Nutzer und Relationen in unglaublichem Maße skaliert. Auch die Verfügbarkeit und Performance des Systems sind bemerkenswert und setzen Branchenstandards.
Für Unternehmen, die eine bewährte, skalierbare und hochverfügbare Lösung zur Verwaltung von Beziehungen in ihren Zugriffsrechten suchen, bringt Zanzibar daher echte Vorteile. Für viele moderne Anwendungen jedoch, insbesondere in der schnelllebigen Welt der Startups oder bei individuellen Anwendungen mit komplexen Autorisierungslogiken, reicht die Ausdruckskraft von Zanzibar nicht aus. Die fehlende Flexibilität kann dazu führen, dass Sicherheitspolitiken nicht exakt abgebildet werden können oder schwer wartbar sind. Fehler in der Zugriffskontrolle haben dann direkte Auswirkungen auf die Sicherheit der Anwendung und die Vertraulichkeit der Daten. Zusammengefasst lässt sich sagen, dass Google Zanzibar zwar ein ausgedrücktes Maß an Ausdruckskraft für ReBAC bietet und technisch sehr leistungsfähig ist, jedoch nicht die Flexibilität besitzt, die man von einem modernen, universellen Autorisierungssystem erwarten würde.
