Demesne

Ce qu'il fait

Une spécification Demesne décrit quatre choses : la forme de votre multi-tenancy, les types d'utilisateurs et de identifiants qui agissent, les tables sur lesquelles ils agissent, et les relations qui les relient, comme la propriété, les rôles, le partage et l'appartenance à un groupe.

À partir de ce fichier, le compilateur génère les politiques de sécurité au niveau des lignes et les fonctions de base de données qu'elles appellent. Il génère aussi une carte des permissions pour Go et TypeScript, pour les questions qui ne portent pas sur des lignes (« cet utilisateur peut-il publier ? »), ainsi que les claims qu'une session doit porter. Modifiez la spécification et régénérez : la base de données et le code applicatif évoluent ensemble.

Pourquoi les règles vivent dans la base de données

L'autorisation se trouve d'ordinaire dans le code applicatif : un service que vous appelez, ou des vérifications dispersées dans les gestionnaires de requêtes. Dans les deux cas, elle ne protège que les chemins qui pensent à la demander. Une tâche d'arrière-plan, un nouveau endpoint ou une requête saisie dans une console de base de données la contournent.

Demesne place la décision sur les données. La même politique filtre chaque requête, quel que soit le code qui l'a envoyée, de sorte qu'un chemin qui oublie de vérifier ne récupère que les lignes que son appelant avait le droit de voir.

Pourquoi nous avons écrit un compilateur

La sécurité au niveau des lignes est le bon endroit pour une règle, mais elle est pénible à écrire à la main. Un produit multi-tenant a besoin de propriété, de rôles, de groupes imbriqués et de partage, répétés sur chaque table, et ces motifs sont faciles à se tromper subtilement.

Les moteurs qui partagent le modèle de Demesne, Zanzibar de Google et les projets open source qui l'ont suivi, fonctionnent comme un service distinct. Votre application doit appeler ce service pour chaque décision et maintenir sa copie des relations en phase avec vos données. Nous voulions le modèle sans le service : les règles de Demesne lisent donc vos tables existantes dans la même transaction que la requête.

Comment sa sortie est vérifiée

La construction de Demesne compare chaque fichier généré, octet par octet, à une copie versionnée. Chaque vérification de permission côté application porte telle quelle la condition de la politique correspondante, de sorte que le code ne peut pas dériver de la base de données sans faire échouer la construction. Exécutée sur un vrai Postgres, la suite de tests installe les fonctions générées et confirme, cas par cas, que le SQL concorde avec les versions Go et TypeScript.

Pour une base de données déjà déployée, demesne diff signale toute différence entre la spécification et les politiques en vigueur.

Pourquoi il est open source

Le composant qui décide qui peut lire vos données est celui que vous devriez pouvoir inspecter. N'importe quelle plateforme peut affirmer que ses tenants sont isolés. Avec Demesne, vous pouvez lire le compilateur qui écrit nos politiques, les tests qu'il doit passer et le SQL qu'il produit, et vous pouvez tout exécuter vous-même.

Rien dans Demesne n'est propre à Fóir. Il fonctionne avec n'importe quelle base Postgres et lit la session que délivre votre propre fournisseur de connexion, et le guide du dépôt explique comment l'adopter sur un schéma existant. Une équipe sans aucun intérêt pour notre plateforme peut l'utiliser, ce qui est le meilleur test que nous connaissions pour savoir si le modèle tient la route.

Ce que cela signifie sur Fóir

Le modèle d'accès de Fóir est une seule spécification Demesne, qui régit à l'heure où nous écrivons environ une centaine de tables. Un test liste chaque table de notre schéma et échoue pour toute table ajoutée sans qu'une décision consignée précise comment elle est protégée.

Les règles que vous définissez pour votre propre projet, comme qui possède un enregistrement et quels rôles peuvent lire un modèle, sont des données que ces politiques lisent : elles prennent donc effet aussi à l'intérieur de la base de données. Appliqué dans la base de données décrit comment les politiques sont générées, forcées et testées.

Cela repart avec vous

Un export Postgres de votre projet inclut des politiques de sécurité au niveau des lignes qui reproduisent les lignes que chacun de vos utilisateurs pouvait lire, prêtes à être appliquées à la base de données dont vous êtes désormais propriétaire. Si vous voulez le modèle entier sur votre propre infrastructure, le moteur est là, sous une licence qui l'autorise.

Là où ce n'est pas le bon outil

Demesne ne fonctionne qu'avec Postgres. C'est une bibliothèque et un outil en ligne de commande, sans service hébergé à appeler. Chaque règle doit pouvoir s'exprimer comme une condition SQL, et les questions posées dans l'autre sens (« qui peut voir cet enregistrement ? ») reçoivent une réponse prudente. Le dépôt contient une comparaison avec Zanzibar, Ory Keto, OpenFGA, Cerbos et Oso qui indique dans quels cas chacun d'eux est le meilleur choix.