En el mundo de la seguridad informática y el control de acceso, Google Zanzibar ha surgido como un referente desde la publicación de su whitepaper en 2019. Inspirando a grandes compañías como Airbnb y Carta, Zanzibar ha representado un modelo para construir sistemas internos de autorización alrededor del concepto de relaciones entre objetos y usuarios. Sin embargo, a pesar de su popularidad y reputación, existe un debate creciente sobre la verdadera flexibilidad de este sistema, y por qué, en realidad, no es tan flexible como muchos piensan. Para comprender las limitaciones de Zanzibar, primero debemos entender su arquitectura y modelo de datos. En esencia, Zanzibar representa la autorización mediante la construcción y evaluación de «tuplas de relaciones» que conectan objetos y usuarios.
Estas tuplas contienen tres elementos esenciales: el objeto, la relación y el usuario. Por ejemplo, un documento (objeto) podría tener un propietario (relación) que es un usuario específico. Este modelo se conoce como Control de Acceso Basado en Relaciones (ReBAC) y, aunque es potente para ciertos escenarios, introduce rigideces importantes. El fallo fundamental viene dado por la estricta estructura que impone el sistema. Cada tupla debe cumplir con esa forma concreta, limitando así la gama de relaciones y escenarios que se pueden expresar directamente.
En la práctica, esto significa que ciertas relaciones o permisos más complejos no encajan fácilmente dentro de este modelo. Por ejemplo, otorgar un permiso de administrador global para editar todos los documentos sin especificar uno por uno no es directamente posible. Zanzibar exige identificar cada objeto individualmente para asignar permisos, lo que obliga a la creación de soluciones alternativas y poco elegantes para representar casos comunes y esenciales. Google intentó aliviar este problema introduciendo una excepción en su especificación, permitiendo que algunos objetos en la parte del usuario pudieran no tener relación definida, dando lugar a lo que llaman «usersets» o conjuntos de usuarios. Esto permite expresar relaciones entre objetos (por ejemplo, entre un documento y la carpeta que lo contiene), pero rompe la pureza del modelo original y genera ambigüedad en la interpretación.
Además, sigue sin resolver la dificultad de asignar permisos generalizados sobre un conjunto amplio y dinámico de objetos, una necesidad frecuente en aplicaciones prácticas. La lógica de autorización en Zanzibar se establece mediante lo que denominan «reescrituras de userset». Estas definen cómo un conjunto de usuarios con un tipo de relación puede derivarse a partir de otros conjuntos y relaciones. Así, se pueden formar jerarquías y relaciones compuestas para facilitar la administración de permisos en estructuras complejas, como documentos con propietarios, editores y espectadores. Sin embargo, esta capacidad no elimina el hecho de que el modelo está forzado a pensar en términos de relaciones concretas, lo que suele requerir la replicación excesiva de reglas o la confusión entre permisos y relaciones.
Un problema importante de este sistema es que fuerza a los desarrolladores a hacer una correspondencia casi uno a uno entre las acciones autorizadas (editar, eliminar, transferir, archivar) y las relaciones en Zanzibar (editor, propietario, etc.). Esto genera la necesidad de crear relaciones muy específicas que en realidad funcionan como permisos disfrazados, duplicando la complejidad y obligando a mantener lógica de autorización fuera del servicio. Tal división va en contra del propósito de utilizar una plataforma de autorización centralizada, que debería facilitar y simplificar el control de acceso. Esta rigidez se puede comparar con la estructura fija de un haiku: aunque expresivo, el formato es inflexible e inevitablemente restringe la forma de comunicar el mensaje.
Zanzibar es profundamente expresivo para representar relaciones entre objetos y usuarios, pero esa expresividad proviene de un esquema rígido que no puede adaptarse fácilmente a todas las necesidades reales de autorización. Esto conlleva costos prácticos en proyectos donde la política de acceso no encaja en la estructura predeterminada. Además, este enfoque puede aumentar la carga cognitiva en los equipos que diseñan y mantienen las políticas. La necesidad de traducir requerimientos complejos a un lenguaje basado únicamente en relaciones incrementa la posibilidad de errores, ambigüedades y problemas de seguridad, especialmente cuando el contexto del permiso o las condiciones específicas se vuelven más complicadas. Por otro lado, vale la pena reconocer que Google Zanzibar ha logrado escalar para funcionar en plataformas y productos de enorme tamaño y con alta disponibilidad, una hazaña impresionante.
Su modelo ha permitido mantener la autorización coherente y rápida en diversas aplicaciones. No obstante, su éxito en ese entorno masivo no implica que sea la mejor solución para todos los casos o que su modelo sea el más flexible o mejor adaptado a las necesidades cambiantes de la autorización moderna. En contraste con estos desafíos, existen otras aproximaciones y soluciones en el mercado que buscan ir más allá de las limitaciones de Zanzibar. Algunas permiten definir permisos y políticas con una semántica más directa, sin tener que reinterpretar acciones como relaciones, y ofrecen lenguajes de políticas más expresivos y adaptables. Estas alternativas pueden facilitar la creación, mantenimiento y audición de políticas de acceso, reduciendo el riesgo de errores y la necesidad de lógicas externas.
En resumen, aunque Google Zanzibar es un avance tecnológico significativo y ha impulsado cambios importantes en cómo pensamos la autorización en sistemas distribuidos, no es la proverbial solución flexible para todo escenario. Su modelo ReBAC, basado en tuplas de relaciones, es potente pero restrictivo y puede complicar la implementación de políticas complejas o generales. Para desarrolladores y arquitectos de seguridad, es vital evaluar cuidadosamente las necesidades específicas de acceso y considerar si esta rigidez puede ser una limitación para sus proyectos. La flexibilidad en autorización no debe confundirse solamente con la capacidad expresiva. Lo que la mayoría de las aplicaciones modernas necesitan es una plataforma que permita expresar claramente todos los matices y excepciones de sus políticas de acceso, sin tener que forzar esas políticas dentro de un modelo demasiado estrecho o artificial.
La historia de Zanzibar nos recuerda que incluso las soluciones más robustas y populares pueden no ser la opción más adecuada para cada caso. Por último, la reflexión es clara: diseñar un sistema de autoría sólido y eficaz no es simplemente cuestión de manejar relaciones o permisos aislados. Requiere un lenguaje y un modelo que permitan expresar todo lo que se necesita con claridad y naturalidad, sin curvas torcidas ni compromisos incómodos. Esa es la verdadera esencia de una autorización flexible y confiable.
