Cómo Google Verifica los Permisos de Acceso para Miles de Millones de Usuarios y Qué Tiene que Ver SpiceDB con Esto

Cuando un proyecto supera un esquema simple con roles de administrador y usuario, comienza el caos. En una arquitectura de microservicios, la verificación de permisos a menudo se convierte en una maraña. Un servicio almacena roles en una base de datos, otro valida tokens JWT, un tercero ejecuta consultas SQL pesadas con una docena de JOINs. Desde 2021, OWASP ha estado denominando a los fallos de control de acceso (Broken Access Control) como la principal amenaza para la seguridad de las aplicaciones web.

Google se enfrentó a este problema hace muchos años. Para Google Drive, YouTube y Cloud IAM, la empresa desarrolló un sistema centralizado de autorización llamado Zanzibar. En 2019, los ingenieros publicaron un artículo describiendo su arquitectura, y el equipo de Authzed tomó esta idea y creó SpiceDB — una base de datos de código abierto para la gestión del control de acceso.

Por Qué Mover la Autorización a una Base de Datos Separada

Las bases de datos regulares son buenas almacenando entidades de negocio, pero tienen dificultades con grafos de permisos complejos. Imagina un documento que está en una carpeta que a su vez está dentro de otra carpeta, compartida con un grupo de usuarios que incluye un departamento separado de la empresa. Calcular si un empleado específico tiene acceso al archivo se vuelve doloroso y lento usando un DBMS estándar.

SpiceDB se encarga de esta tarea por ti. Envías una consulta simple a la base de datos: "¿Puede el usuario X realizar la acción Y en el recurso Z?". La respuesta es una rápida respuesta binaria.

Al mismo tiempo, SpiceDB maneja únicamente la autorización (permisos de acceso) y no sabe nada sobre la autenticación (verificación de identidad). Verificar contraseñas, iniciar sesión de usuarios y emitir tokens debe seguir siendo manejado por tu proveedor de identidad como Keycloak o Auth0.

Cómo Funciona el Esquema y el Lenguaje de Relaciones

Trabajar con SpiceDB comienza describiendo un esquema. El esquema define los tipos de objetos y las reglas para calcular permisos.

La sintaxis del esquema se ve legible y concisa:

definition user {}

definition folder {
    relation parent: folder
    relation viewer: user

    permission view = viewer + parent->view
}

definition document {
    relation folder: folder
    relation viewer: user

    permission view = viewer + folder->view
}

En este ejemplo, el acceso view a un documento se otorga automáticamente a los usuarios listados directamente en viewer, así como a aquellos que tienen el permiso view en la carpeta padre. La cadena de anidamiento puede tener cualquier profundidad.

Los datos reales se almacenan como relaciones. Estos son hechos simples sobre el sistema, por ejemplo:

• folder:finance — un objeto de tipo folder con ID finance
• viewer — una relación
• user:mikhail — un sujeto

Registrar esta relación significa que Mijaíl se convirtió en lector de la carpeta finance.

ReBAC y Atributos: La Experiencia de Netflix

A diferencia del RBAC clásico (Control de Acceso Basado en Roles), SpiceDB implementa ReBAC (Control de Acceso Basado en Relaciones). El acceso se determina a través de relaciones entre objetos en un grafo.

Pero a veces las empresas necesitan más que saber que un usuario es parte de un equipo. Necesitan verificar una condición contextual: por ejemplo, que la persona esté accediendo desde una dirección IP corporativa o que la solicitud se haya realizado durante horario laboral.

Para tales escenarios, los ingenieros de Netflix ayudaron a agregar un mecanismo de caveats a SpiceDB. Esto combina ReBAC y ABAC (Control de Acceso Basado en Atributos). Una función contextual se adjunta a una relación, calculada en el momento de la verificación de permisos.

Arquitectura y Rendimiento Bajo Carga

SpiceDB está escrito en Go y diseñado para cargas elevadas. Los autores afirman una latencia de 5ms en el percentil 95 con millones de consultas por segundo y miles de millones de relaciones en la base de datos.

Como almacenamiento (datastores), puedes conectar DBMSs familiares:

• PostgreSQL
• CockroachDB
• MySQL (el driver para MySQL fue escrito por el equipo de autorización de GitHub)
• Google Cloud Spanner

Una característica interesante es la gestión de consistencia a nivel de consulta individual. Si un usuario acaba de cambiar los permisos de acceso y quiere ver el resultado inmediatamente, la aplicación envía una solicitud que requiere datos completamente consistentes. Sin embargo, si estamos renderizando un catálogo público donde un par de segundos de retraso no es crítico, permitimos el almacenamiento en caché y reducimos la carga en la base de datos.

SpiceDB también puede responder preguntas "inversas": "¿A qué recursos tiene acceso el usuario?" o "¿Quién puede ver este documento?". Para esto, utiliza índices inversos internamente.

Inicio Rápido con Docker y curl

Puedes levantar SpiceDB para experimentos con un solo comando Docker:

docker run --rm -p 50051:50051 -p 8443:8443 \
  authzed/spicedb serve \
  --http-enabled true \
  --grpc-preshared-key "somerandomkeyhere"

Después del inicio, carga el esquema a través de la API HTTP:

curl --location 'http://localhost:8443/v1/schema/write' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer somerandomkeyhere' \
--data '{
    "schema": "definition user {} \n definition folder { \n relation viewer: user \n permission view = viewer \n }"
}'

Agrega una relación indicando que el usuario anne puede ver la carpeta budget:

curl --location 'http://localhost:8443/v1/relationships/write' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer somerandomkeyhere' \
--data '{
    "updates": [
        {
            "operation": "OPERATION_TOUCH",
            "relationship": {
                "resource": { "objectType": "folder", "objectId": "budget" },
                "relation": "viewer",
                "subject": { "object": { "objectType": "user", "objectId": "anne" } }
            }
        }
    ]
}'

Ahora verifica los permisos:

curl --location 'http://localhost:8443/v1/permissions/check' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer somerandomkeyhere' \
--data '{
  "resource": { "objectType": "folder", "objectId": "budget" },
  "permission": "view",
  "subject": { "object": { "objectType": "user", "objectId": "anne" } }
}'

Recibiremos el estado PERMISSIONSHIP_HAS_PERMISSION en respuesta.

Además de las APIs REST y gRPC, los desarrolladores ofrecen una utilidad de línea de comandos zed y un sandbox basado en navegador llamado Playground (play.authzed.com). Es conveniente para diseñar un modelo de permisos, poblarlo con datos de prueba y probar hipótesis antes de escribir cualquier código.

Para Quién Es Esta Herramienta

SpiceDB ya está funcionando en producción en Red Hat, IBM, GitPod y Tubi.

Introducir un sistema así en un monolito pequeño donde todos los permisos se limitan a un panel de administración y un par de roles no tiene mucho sentido — es una complejidad de infraestructura innecesaria. Sin embargo, la herramienta es perfecta cuando:

• Tienes una docena de microservicios, y cada uno intenta verificar permisos a su manera.
• La lógica de tu producto requiere compartir archivos, jerarquías de carpetas complejas o cuentas de equipo.
• Necesitas una auditoría de seguridad y un punto único de gestión del control de acceso.

Para el despliegue en Kubernetes, Authzed proporciona un operador oficial. El proyecto se está desarrollando activamente, y el repositorio de GitHub ya tiene casi 7.000 estrellas.