Comment Google vérifie les droits d'accès de milliards d'utilisateurs et quel est le lien avec SpiceDB

Lorsqu'un projet dépasse un simple schéma avec des rôles admin et utilisateur, le chaos commence. Dans une architecture de microservices, la vérification des droits se transforme souvent en toile d'araignée inextricable. Un service stocke les rôles dans une base de données, un autre valide les jetons JWT, un troisième exécute des requêtes SQL lourdes avec une douzaine de JOIN. Depuis 2021, l'OWASP qualifie les échecs de contrôle d'accès (Broken Access Control) de menace numéro un pour la sécurité des applications web.

Google a rencontré ce problème il y a de nombreuses années. Pour Google Drive, YouTube et Cloud IAM, l'entreprise a développé un système d'autorisation centralisé unifié appelé Zanzibar. En 2019, des ingénieurs ont publié un article décrivant son architecture, et l'équipe Authzed a repris cette idée pour créer SpiceDB — une base de données open source pour la gestion du contrôle d'accès.

Pourquoi déplacer l'autorisation vers une base de données séparée

Les bases de données classiques sont efficaces pour stocker des entités métier, mais elles peinent avec les graphes de permissions complexes. Imaginez un document placé dans un dossier lui-même contenu dans un autre dossier, partagé avec un groupe d'utilisateurs qui inclut un département d'une autre entreprise. Calculer si un employé spécifique a accès au fichier devient douloureux et lent avec un SGBD standard.

SpiceDB prend cette tâche en charge. Vous envoyez une requête simple à la base de données : « L'utilisateur X peut-il effectuer l'action Y sur la ressource Z ? ». La réponse est une réponse binaire rapide.

Dans le même temps, SpiceDB ne gère que l'autorisation (droits d'accès) et ne sait rien de l'authentification (vérification d'identité). La vérification des mots de passe, la connexion des utilisateurs et l'émission de jetons doivent toujours être gérées par votre fournisseur d'identité comme Keycloak ou Auth0.

Fonctionnement du schéma et du langage de relations

Travailler avec SpiceDB commence par la description d'un schéma. Le schéma définit les types d'objets et les règles de calcul des permissions.

La syntaxe du schéma est lisible et concise :

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
}

Dans cet exemple, l'accès view à un document est automatiquement accordé aux utilisateurs listés directement dans viewer, ainsi qu'à ceux qui ont la permission view sur le dossier parent. La chaîne d'imbrication peut avoir une profondeur quelconque.

Les données réelles sont stockées sous forme de relations. Ce sont des faits simples sur le système, par exemple :

• folder:finance — un objet de type folder avec l'ID finance
• viewer — une relation
• user:mikhail — un sujet

Enregistrer une telle relation signifie que Mikhaïl est devenu lecteur du dossier finance.

ReBAC et attributs : l'expérience de Netflix

Contrairement au RBAC classique (Role-Based Access Control), SpiceDB implémente le ReBAC (Relationship-Based Access Control). L'accès est déterminé par les relations entre les objets d'un graphe.

Mais parfois, les entreprises ont besoin de plus que de savoir qu'un utilisateur fait partie d'une équipe. Elles doivent vérifier une condition contextuelle : par exemple, que la personne accède depuis une adresse IP d'entreprise ou que la requête a été faite pendant les heures de bureau.

Pour de tels scénarios, les ingénieurs de Netflix ont contribué à ajouter un mécanisme de caveats à SpiceDB. Celui-ci combine ReBAC et ABAC (Attribute-Based Access Control). Une fonction contextuelle est attachée à une relation, calculée au moment de la vérification des droits.

Architecture et performances sous charge

SpiceDB est écrit en Go et conçu pour des charges élevées. Les auteurs revendiquent une latence de 5 ms au p95 avec des millions de requêtes par seconde et des milliards de relations dans la base de données.

Comme stockage (datastores), vous pouvez connecter des SGBD familiers :

• PostgreSQL
• CockroachDB
• MySQL (le driver pour MySQL a été écrit par l'équipe d'autorisation de GitHub)
• Google Cloud Spanner

Une fonctionnalité intéressante est la gestion de la cohérence au niveau de chaque requête individuelle. Si un utilisateur vient de modifier les droits d'accès et souhaite voir le résultat immédiatement, l'application envoie une requête nécessitant des données entièrement cohérentes. Cependant, si nous affichons un catalogue public où un délai de quelques secondes n'est pas critique, nous autorisons la mise en cache et réduisons la charge sur la base de données.

SpiceDB peut également répondre à des questions « inverses » : « À quelles ressources l'utilisateur a-t-il accès ? » ou « Qui peut consulter ce document ? ». Pour cela, il utilise en interne des index inversés.

Démarrage rapide avec Docker et curl

Vous pouvez lancer SpiceDB pour des expérimentations avec une seule commande Docker :

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

Après le démarrage, chargez le schéma via l'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 }"
}'

Ajoutez une relation indiquant que l'utilisateur anne peut consulter le dossier 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" } }
            }
        }
    ]
}'

Vérifiez maintenant les droits :

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" } }
}'

Nous recevrons le statut PERMISSIONSHIP_HAS_PERMISSION en réponse.

En plus des API REST et gRPC, les développeurs proposent un utilitaire en ligne de commande zed et un bac à sable accessible depuis le navigateur appelé Playground (play.authzed.com). C'est pratique pour esquisser un modèle de permissions, le peuplé de données de test et tester des hypothèses avant d'écrire du code.

À qui cet outil est destiné

SpiceDB fonctionne déjà en production chez Red Hat, IBM, GitPod et Tubi.

Introduire un tel système dans un petit monolithe où tous les droits se limitent à un panneau d'administration et quelques rôles n'a pas de sens — c'est une complexité d'infrastructure inutile. Cependant, l'outil est parfait lorsque :

• Vous avez une douzaine de microservices, et chacun essaie de vérifier les droits à sa manière.
• La logique de votre produit nécessite le partage de fichiers, des hiérarchies de dossiers complexes ou des comptes d'équipe.
• Vous avez besoin d'un audit de sécurité et d'un point unique de gestion du contrôle d'accès.

Pour le déploiement dans Kubernetes, Authzed fournit un operator officiel. Le projet est en développement actif, et le dépôt GitHub compte déjà près de 7 000 étoiles.